Weird network problem - Second NIC lags terribly when first NIC uses a gateway - Help...?

Weird network problem - Second NIC lags terribly when first NIC uses a gateway - Help...?

Post by Joshua Gustafso » Sat, 28 Jul 2001 08:57:39



Here's a really strange network problem for those of you who've been around
the linux networking block longer than I:

I have a linux machine setup as a firewall & masquerader for a small home
network of windows machines.  I've had everything (firewall, masquerade,
DNS, samba, web/ftp/mail servers, etc) working as it should for months.
Then, two days ago, for no cause I can currently identify (I don't recall
changing anything and nobody else has access to the server), it started
having the following problem.  Whenever eth0 (my external connection,
usually configured by DHCP) is up and running, eth1 (my internal connection)
becomes very very lagged, especially on establishing connections.  It takes
around 30 seconds just to open a telnet session.  No data appears to be
_lost_, it's just very lagged.  ICMP pings are unaffected, however.  I can
still connect to _outside_ servers at normal speeds from the internal
network, as well; it's only connecting to my linux box that's lagged.  Also,
from the linux box itself, I can connect to eth0 or lo at full speed, but
connecting to eth1 from the linux box itself is lagged.  If I take eth0 down
('ifdown eth0') then eth1 works perfectly in all cases.  If I unplug eth0
from the cable modem and configure it as a dummy local network of its own,
then both interfaces work fine at full speed.  If I manually configure eth0
with the parameters that the DHCP server would normally give it (I've got a
static IP anyway), EXCEPT for the gateway setting, then everything works
fine, except of course that I can't connect to the internet without the
gateway.

So, if eth0 is setup to know its gateway, then eth1 becomes very lagged.  If
eth0 is not set up to know its gateway, then eth1 works perfectly.

Does anyone have any clue what might be causing this or how to fix it?  It's
getting really frustrating, not to mention the hours of work I'm loosing
until I get it fixed.  (Long story, but fast remote access to my server is
crucial for my work.)

Machine specs: (lemme know if there's anything I'm forgetting that would
help to know)
RedHat 7.1 (kernel 2.4.2-2) on an Intel Celeron 633, 256mb ram, all the
latest non-kernel updates from RHN

/etc/sysconfig/network-scripts/ifcfg-eth0:
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
DHCP_HOSTNAME=(My ISP-assigned hostname)

/etc/sysconfig/network-scripts/ifcfg-eth1:
DEVICE=eth1
BROADCAST=192.168.0.255
IPADDR=192.168.0.1
NETMASK=255.255.255.0
NETWORK=192.168.0.0
ONBOOT=yes

/etc/sysconfig/hwconf:
...
-
class: NETWORK
bus: PCI
detached: 0
device: eth
driver: 8139too
desc: "Realtek|RTL-8139"
vendorId: 10ec
deviceId: 8139
subVendorId: 10ec
subDeviceId: 8139
pciType: 1
-
class: NETWORK
bus: PCI
detached: 0
device: eth
driver: tulip
desc: "DEC|DECchip 21041 [Tulip Pass 3]"
vendorId: 1011
deviceId: 0014
subVendorId: 10b8
subDeviceId: 2008
pciType: 1
-
...

/etc/sysctl.conf:
# Disables packet forwarding
#net.ipv4.ip_forward = 0
net.ipv4.ip_forward = 1
net.ipv4.ip_always_defrag = 1
# Enables source route verification
net.ipv4.conf.all.rp_filter = 1
# Disables the magic-sysrq key
kernel.sysrq = 0

'lsmod':
Module                  Size  Used by
agpgart                23392   7  (autoclean)
autofs                 11264   1  (autoclean)
ipt_MASQUERADE          1712   1  (autoclean)
ipt_state               1200   2  (autoclean)
iptable_mangle          2272   0  (autoclean) (unused)
8139too                16480   1  (autoclean)
tulip                  38544   1  (autoclean)
iptable_filter          2304   0  (autoclean) (unused)
iptable_nat            16160   0  [ipt_MASQUERADE]
ip_conntrack           15824   2  [ipt_MASQUERADE ipt_state iptable_nat]
ip_tables              11072   7  [ipt_MASQUERADE ipt_state iptable_mangle
iptable_filter iptable_nat]
usb-uhci               20720   0  (unused)
usbcore                49664   1  [usb-uhci]
raid0                   3856   3

 
 
 

Weird network problem - Second NIC lags terribly when first NIC uses a gateway - Help...?

Post by Michael F » Sat, 28 Jul 2001 12:24:12


Stab in the dark, what does /etc/resolv.conf on your linux box say?
and is the server listed an valid dns server? if not change it and see
how things run.

-
Michael

On Thu, 26 Jul 2001 23:57:39 GMT, "Joshua Gustafson"


>Here's a really strange network problem for those of you who've been around
>the linux networking block longer than I:

>I have a linux machine setup as a firewall & masquerader for a small home
>network of windows machines.  I've had everything (firewall, masquerade,
>DNS, samba, web/ftp/mail servers, etc) working as it should for months.
>Then, two days ago, for no cause I can currently identify (I don't recall
>changing anything and nobody else has access to the server), it started
>having the following problem.  Whenever eth0 (my external connection,
>usually configured by DHCP) is up and running, eth1 (my internal connection)
>becomes very very lagged, especially on establishing connections.  It takes
>around 30 seconds just to open a telnet session.  No data appears to be
>_lost_, it's just very lagged.  ICMP pings are unaffected, however.  I can
>still connect to _outside_ servers at normal speeds from the internal
>network, as well; it's only connecting to my linux box that's lagged.  Also,
>from the linux box itself, I can connect to eth0 or lo at full speed, but
>connecting to eth1 from the linux box itself is lagged.  If I take eth0 down
>('ifdown eth0') then eth1 works perfectly in all cases.  If I unplug eth0
>from the cable modem and configure it as a dummy local network of its own,
>then both interfaces work fine at full speed.  If I manually configure eth0
>with the parameters that the DHCP server would normally give it (I've got a
>static IP anyway), EXCEPT for the gateway setting, then everything works
>fine, except of course that I can't connect to the internet without the
>gateway.

>So, if eth0 is setup to know its gateway, then eth1 becomes very lagged.  If
>eth0 is not set up to know its gateway, then eth1 works perfectly.

>Does anyone have any clue what might be causing this or how to fix it?  It's
>getting really frustrating, not to mention the hours of work I'm loosing
>until I get it fixed.  (Long story, but fast remote access to my server is
>crucial for my work.)

>Machine specs: (lemme know if there's anything I'm forgetting that would
>help to know)
>RedHat 7.1 (kernel 2.4.2-2) on an Intel Celeron 633, 256mb ram, all the
>latest non-kernel updates from RHN

>/etc/sysconfig/network-scripts/ifcfg-eth0:
>DEVICE=eth0
>BOOTPROTO=dhcp
>ONBOOT=yes
>DHCP_HOSTNAME=(My ISP-assigned hostname)

>/etc/sysconfig/network-scripts/ifcfg-eth1:
>DEVICE=eth1
>BROADCAST=192.168.0.255
>IPADDR=192.168.0.1
>NETMASK=255.255.255.0
>NETWORK=192.168.0.0
>ONBOOT=yes

>/etc/sysconfig/hwconf:
>...
>-
>class: NETWORK
>bus: PCI
>detached: 0
>device: eth
>driver: 8139too
>desc: "Realtek|RTL-8139"
>vendorId: 10ec
>deviceId: 8139
>subVendorId: 10ec
>subDeviceId: 8139
>pciType: 1
>-
>class: NETWORK
>bus: PCI
>detached: 0
>device: eth
>driver: tulip
>desc: "DEC|DECchip 21041 [Tulip Pass 3]"
>vendorId: 1011
>deviceId: 0014
>subVendorId: 10b8
>subDeviceId: 2008
>pciType: 1
>-
>...

>/etc/sysctl.conf:
># Disables packet forwarding
>#net.ipv4.ip_forward = 0
>net.ipv4.ip_forward = 1
>net.ipv4.ip_always_defrag = 1
># Enables source route verification
>net.ipv4.conf.all.rp_filter = 1
># Disables the magic-sysrq key
>kernel.sysrq = 0

>'lsmod':
>Module                  Size  Used by
>agpgart                23392   7  (autoclean)
>autofs                 11264   1  (autoclean)
>ipt_MASQUERADE          1712   1  (autoclean)
>ipt_state               1200   2  (autoclean)
>iptable_mangle          2272   0  (autoclean) (unused)
>8139too                16480   1  (autoclean)
>tulip                  38544   1  (autoclean)
>iptable_filter          2304   0  (autoclean) (unused)
>iptable_nat            16160   0  [ipt_MASQUERADE]
>ip_conntrack           15824   2  [ipt_MASQUERADE ipt_state iptable_nat]
>ip_tables              11072   7  [ipt_MASQUERADE ipt_state iptable_mangle
>iptable_filter iptable_nat]
>usb-uhci               20720   0  (unused)
>usbcore                49664   1  [usb-uhci]
>raid0                   3856   3


 
 
 

Weird network problem - Second NIC lags terribly when first NIC uses a gateway - Help...?

Post by Joshua Gustafso » Sat, 28 Jul 2001 14:02:03


My resolv.conf is generated by dhcpcd (or pump, the same problem happens
either way) and contains the correct info for my ISP's primary and secondary
name servers.  I can correctly resolve any hostname I like.

But, that shouldn't matter anyway, because none of my problems involve name
resolution; for example, my test case of telnetting to the internal
interface is done simply with 'telnet 192.168.0.1'.

-Josh


> Stab in the dark, what does /etc/resolv.conf on your linux box say?
> and is the server listed an valid dns server? if not change it and see
> how things run.

> -
> Michael

> On Thu, 26 Jul 2001 23:57:39 GMT, "Joshua Gustafson"

> >Here's a really strange network problem for those of you who've been
around
> >the linux networking block longer than I:

> >I have a linux machine setup as a firewall & masquerader for a small home
> >network of windows machines.  I've had everything (firewall, masquerade,
> >DNS, samba, web/ftp/mail servers, etc) working as it should for months.
> >Then, two days ago, for no cause I can currently identify (I don't recall
> >changing anything and nobody else has access to the server), it started
> >having the following problem.  Whenever eth0 (my external connection,
> >usually configured by DHCP) is up and running, eth1 (my internal
connection)
> >becomes very very lagged, especially on establishing connections.  It
takes
> >around 30 seconds just to open a telnet session.  No data appears to be
> >_lost_, it's just very lagged.  ICMP pings are unaffected, however.  I
can
> >still connect to _outside_ servers at normal speeds from the internal
> >network, as well; it's only connecting to my linux box that's lagged.
Also,
> >from the linux box itself, I can connect to eth0 or lo at full speed, but
> >connecting to eth1 from the linux box itself is lagged.  If I take eth0
down
> >('ifdown eth0') then eth1 works perfectly in all cases.  If I unplug eth0
> >from the cable modem and configure it as a dummy local network of its
own,
> >then both interfaces work fine at full speed.  If I manually configure
eth0
> >with the parameters that the DHCP server would normally give it (I've got
a
> >static IP anyway), EXCEPT for the gateway setting, then everything works
> >fine, except of course that I can't connect to the internet without the
> >gateway.

> >So, if eth0 is setup to know its gateway, then eth1 becomes very lagged.
If
> >eth0 is not set up to know its gateway, then eth1 works perfectly.

> >Does anyone have any clue what might be causing this or how to fix it?
It's
> >getting really frustrating, not to mention the hours of work I'm loosing
> >until I get it fixed.  (Long story, but fast remote access to my server
is
> >crucial for my work.)

> >Machine specs: (lemme know if there's anything I'm forgetting that would
> >help to know)
> >RedHat 7.1 (kernel 2.4.2-2) on an Intel Celeron 633, 256mb ram, all the
> >latest non-kernel updates from RHN

> >/etc/sysconfig/network-scripts/ifcfg-eth0:
> >DEVICE=eth0
> >BOOTPROTO=dhcp
> >ONBOOT=yes
> >DHCP_HOSTNAME=(My ISP-assigned hostname)

> >/etc/sysconfig/network-scripts/ifcfg-eth1:
> >DEVICE=eth1
> >BROADCAST=192.168.0.255
> >IPADDR=192.168.0.1
> >NETMASK=255.255.255.0
> >NETWORK=192.168.0.0
> >ONBOOT=yes

> >/etc/sysconfig/hwconf:
> >...
> >-
> >class: NETWORK
> >bus: PCI
> >detached: 0
> >device: eth
> >driver: 8139too
> >desc: "Realtek|RTL-8139"
> >vendorId: 10ec
> >deviceId: 8139
> >subVendorId: 10ec
> >subDeviceId: 8139
> >pciType: 1
> >-
> >class: NETWORK
> >bus: PCI
> >detached: 0
> >device: eth
> >driver: tulip
> >desc: "DEC|DECchip 21041 [Tulip Pass 3]"
> >vendorId: 1011
> >deviceId: 0014
> >subVendorId: 10b8
> >subDeviceId: 2008
> >pciType: 1
> >-
> >...

> >/etc/sysctl.conf:
> ># Disables packet forwarding
> >#net.ipv4.ip_forward = 0
> >net.ipv4.ip_forward = 1
> >net.ipv4.ip_always_defrag = 1
> ># Enables source route verification
> >net.ipv4.conf.all.rp_filter = 1
> ># Disables the magic-sysrq key
> >kernel.sysrq = 0

> >'lsmod':
> >Module                  Size  Used by
> >agpgart                23392   7  (autoclean)
> >autofs                 11264   1  (autoclean)
> >ipt_MASQUERADE          1712   1  (autoclean)
> >ipt_state               1200   2  (autoclean)
> >iptable_mangle          2272   0  (autoclean) (unused)
> >8139too                16480   1  (autoclean)
> >tulip                  38544   1  (autoclean)
> >iptable_filter          2304   0  (autoclean) (unused)
> >iptable_nat            16160   0  [ipt_MASQUERADE]
> >ip_conntrack           15824   2  [ipt_MASQUERADE ipt_state iptable_nat]
> >ip_tables              11072   7  [ipt_MASQUERADE ipt_state
iptable_mangle
> >iptable_filter iptable_nat]
> >usb-uhci               20720   0  (unused)
> >usbcore                49664   1  [usb-uhci]
> >raid0                   3856   3

 
 
 

Weird network problem - Second NIC lags terribly when first NIC uses a gateway - Help...?

Post by Joshua Gustafso » Sat, 28 Jul 2001 14:28:56


For the TCP/IP gurus (which I'm not, unfortunately) the following is tcpdump
output of the packets sent when a machine on my internal network
(192.168.0.2) tries to telnet to the internal interface of my linux server
(192.168.0.1):

23:20:30.436795 < 192.168.0.2.1709 > 192.168.0.1.telnet: S
3931475325:3931475325(0) win 16384 <mss 1460,nop,nop,sackOK> (DF) (ttl 128,
id 28909)
23:20:30.436795 > 192.168.0.1.telnet > 192.168.0.2.1709: S
4291065084:4291065084(0) ack 3931475326 win 5840 <mss 1460,nop,nop,sackOK>
(DF) (ttl 64, id 0)
23:20:30.436795 < 192.168.0.2.1709 > 192.168.0.1.telnet: . 1:1(0) ack 1 win
17520 (DF) (ttl 128, id 28910)
23:20:30.436795 < 192.168.0.2.1709 > 192.168.0.1.telnet: P 1:4(3) ack 1 win
17520 (DF) (ttl 128, id 28911)
23:20:30.436795 > 192.168.0.1.telnet > 192.168.0.2.1709: . 1:1(0) ack 4 win
5840 (DF) (ttl 64, id 49742)
23:20:30.436795 < 192.168.0.2.1709 > 192.168.0.1.telnet: P 4:22(18) ack 1
win 17520 (DF) (ttl 128, id 28912)
23:20:30.436795 > 192.168.0.1.telnet > 192.168.0.2.1709: . 1:1(0) ack 22 win
5840 (DF) (ttl 64, id 49743)
23:20:50.486795 > 192.168.0.1.telnet > 192.168.0.2.1709: P 1:13(12) ack 22
win 5840 (DF) [tos 0x10]  (ttl 64, id 49744)
23:20:50.486795 < 192.168.0.2.1709 > 192.168.0.1.telnet: P 22:25(3) ack 13
win 17508 (DF) (ttl 128, id 28913)
23:20:50.486795 > 192.168.0.1.telnet > 192.168.0.2.1709: P 13:25(12) ack 25
win 5840 (DF) [tos 0x10]  (ttl 64, id 49745)
23:20:50.486795 < 192.168.0.2.1709 > 192.168.0.1.telnet: P 25:34(9) ack 25
win 17496 (DF) (ttl 128, id 28914)
23:20:50.486795 > 192.168.0.1.telnet > 192.168.0.2.1709: P 25:43(18) ack 34
win 5840 (DF) [tos 0x10]  (ttl 64, id 49746)
23:20:50.486795 < 192.168.0.2.1709 > 192.168.0.1.telnet: P 34:51(17) ack 43
win 17478 (DF) (ttl 128, id 28915)
23:20:50.526795 > 192.168.0.1.telnet > 192.168.0.2.1709: . 43:43(0) ack 51
win 5840 (DF) [tos 0x10]  (ttl 64, id 49747)
23:20:50.526795 < 192.168.0.2.1709 > 192.168.0.1.telnet: P 51:68(17) ack 43
win 17478 (DF) (ttl 128, id 28916)
23:20:50.526795 > 192.168.0.1.telnet > 192.168.0.2.1709: . 43:43(0) ack 68
win 5840 (DF) [tos 0x10]  (ttl 64, id 49748)
23:20:50.526795 > 192.168.0.1.telnet > 192.168.0.2.1709: P 43:52(9) ack 68
win 5840 (DF) [tos 0x10]  (ttl 64, id 49749)
23:20:50.526795 < 192.168.0.2.1709 > 192.168.0.1.telnet: P 68:71(3) ack 52
win 17469 (DF) (ttl 128, id 28917)
23:20:50.526795 > 192.168.0.1.telnet > 192.168.0.2.1709: P 52:118(66) ack 71
win 5840 (DF) [tos 0x10]  (ttl 64, id 49750)
23:20:50.526795 < 192.168.0.2.1709 > 192.168.0.1.telnet: P 71:77(6) ack 118
win 17403 (DF) (ttl 128, id 28918)
23:20:50.536795 > 192.168.0.1.telnet > 192.168.0.2.1709: P 118:125(7) ack 77
win 5840 (DF) [tos 0x10]  (ttl 64, id 49751)
23:20:50.666795 < 192.168.0.2.1709 > 192.168.0.1.telnet: . 77:77(0) ack 125
win 17396 (DF) (ttl 128, id 28919)


Quote:> Here's a really strange network problem for those of you who've been
around
> the linux networking block longer than I:

> I have a linux machine setup as a firewall & masquerader for a small home
> network of windows machines.  I've had everything (firewall, masquerade,
> DNS, samba, web/ftp/mail servers, etc) working as it should for months.
> Then, two days ago, for no cause I can currently identify (I don't recall
> changing anything and nobody else has access to the server), it started
> having the following problem.  Whenever eth0 (my external connection,
> usually configured by DHCP) is up and running, eth1 (my internal
connection)
> becomes very very lagged, especially on establishing connections.  It
takes
> around 30 seconds just to open a telnet session.  No data appears to be
> _lost_, it's just very lagged.  ICMP pings are unaffected, however.  I can
> still connect to _outside_ servers at normal speeds from the internal
> network, as well; it's only connecting to my linux box that's lagged.
Also,
> from the linux box itself, I can connect to eth0 or lo at full speed, but
> connecting to eth1 from the linux box itself is lagged.  If I take eth0
down
> ('ifdown eth0') then eth1 works perfectly in all cases.  If I unplug eth0
> from the cable modem and configure it as a dummy local network of its own,
> then both interfaces work fine at full speed.  If I manually configure
eth0
> with the parameters that the DHCP server would normally give it (I've got
a
> static IP anyway), EXCEPT for the gateway setting, then everything works
> fine, except of course that I can't connect to the internet without the
> gateway.

> So, if eth0 is setup to know its gateway, then eth1 becomes very lagged.
If
> eth0 is not set up to know its gateway, then eth1 works perfectly.

> Does anyone have any clue what might be causing this or how to fix it?
It's
> getting really frustrating, not to mention the hours of work I'm loosing
> until I get it fixed.  (Long story, but fast remote access to my server is
> crucial for my work.)

> Machine specs: (lemme know if there's anything I'm forgetting that would
> help to know)
> RedHat 7.1 (kernel 2.4.2-2) on an Intel Celeron 633, 256mb ram, all the
> latest non-kernel updates from RHN

> /etc/sysconfig/network-scripts/ifcfg-eth0:
> DEVICE=eth0
> BOOTPROTO=dhcp
> ONBOOT=yes
> DHCP_HOSTNAME=(My ISP-assigned hostname)

> /etc/sysconfig/network-scripts/ifcfg-eth1:
> DEVICE=eth1
> BROADCAST=192.168.0.255
> IPADDR=192.168.0.1
> NETMASK=255.255.255.0
> NETWORK=192.168.0.0
> ONBOOT=yes

> /etc/sysconfig/hwconf:
> ...
> -
> class: NETWORK
> bus: PCI
> detached: 0
> device: eth
> driver: 8139too
> desc: "Realtek|RTL-8139"
> vendorId: 10ec
> deviceId: 8139
> subVendorId: 10ec
> subDeviceId: 8139
> pciType: 1
> -
> class: NETWORK
> bus: PCI
> detached: 0
> device: eth
> driver: tulip
> desc: "DEC|DECchip 21041 [Tulip Pass 3]"
> vendorId: 1011
> deviceId: 0014
> subVendorId: 10b8
> subDeviceId: 2008
> pciType: 1
> -
> ...

> /etc/sysctl.conf:
> # Disables packet forwarding
> #net.ipv4.ip_forward = 0
> net.ipv4.ip_forward = 1
> net.ipv4.ip_always_defrag = 1
> # Enables source route verification
> net.ipv4.conf.all.rp_filter = 1
> # Disables the magic-sysrq key
> kernel.sysrq = 0

> 'lsmod':
> Module                  Size  Used by
> agpgart                23392   7  (autoclean)
> autofs                 11264   1  (autoclean)
> ipt_MASQUERADE          1712   1  (autoclean)
> ipt_state               1200   2  (autoclean)
> iptable_mangle          2272   0  (autoclean) (unused)
> 8139too                16480   1  (autoclean)
> tulip                  38544   1  (autoclean)
> iptable_filter          2304   0  (autoclean) (unused)
> iptable_nat            16160   0  [ipt_MASQUERADE]
> ip_conntrack           15824   2  [ipt_MASQUERADE ipt_state iptable_nat]
> ip_tables              11072   7  [ipt_MASQUERADE ipt_state iptable_mangle
> iptable_filter iptable_nat]
> usb-uhci               20720   0  (unused)
> usbcore                49664   1  [usb-uhci]
> raid0                   3856   3

 
 
 

Weird network problem - Second NIC lags terribly when first NIC uses a gateway - Help...?

Post by Enriqu » Sat, 28 Jul 2001 17:39:57



> My resolv.conf is generated by dhcpcd (or pump, the same problem happens
> either way) and contains the correct info for my ISP's primary and
> secondary
> name servers.  I can correctly resolve any hostname I like.

> But, that shouldn't matter anyway, because none of my problems involve
> name resolution; for example, my test case of telnetting to the internal
> interface is done simply with 'telnet 192.168.0.1'.

It's weird, this.

Seems an idea to find out what the computer spends the time at during the
20 seconds gap:

23:20:30.436795 < 192.168.0.2.1709 > 192.168.0.1.telnet: P 4:22(18) ack 1
win 17520 (DF) (ttl 128, id 28912)
23:20:30.436795 > 192.168.0.1.telnet > 192.168.0.2.1709: . 1:1(0) ack 22 win
5840 (DF) (ttl 64, id 49743)
23:20:50.486795 > 192.168.0.1.telnet > 192.168.0.2.1709: P 1:13(12) ack 22
win 5840 (DF) [tos 0x10]  (ttl 64, id 49744)

Clearly, the telnet connection is established, maybe there are some telnet
options negotiations going on. No firewall issues here.

I dear not swear there are no name resolution issues going on, even if your
argument seems plausible.

How did you start tcpdump? make sure it says
"tcpdump: listening on all devices" when it starts. That will tell if
something is going on on the other interfece(s) during that time.

It would also be nice to know what are the 18 bytes sent from client to
server just before the delay. Not very likely to give much cues, but having
little better to do, we might try to decipher some telnet option
negotiation, if that is what is going on.

Could you run tcpdump with -s 1550 -x ?
That will include a hex dump of the ip packages. (warning: that may reveal
passwords! You might want to temporarily change some passwords before doing
the test.

I do not know to what degree the timing might be altered by running
tcpdump. In any case, the ascii output from tcpdump makes tcpdump try to
look up the names of all ip addresses, so make sure this does not happen
while you are collecting packages. Use the -w outfile option, that saves
the data in a fairly raw format. Once the measurement is over, you decipher
the file using tcpdump again, this time with the option -r inputfile.

If things get hard, maybe you should arrange to run the telnet daemon under
strace. Then we can see what system calls telnetd is doing, and to some
degree, whith what parameters.

Normally telnetd is started by xinetd. maybe it is possible to manipulate
the file /etc/xinetd.d/telnet so it starts /usr/bin/strace -o outputfile
/usr/sbin/in.telnetd rather than just /usr/sbin/in.telnetd. If that does
not work, perhaps you should disable telnet in xinetd and start it manually
as a standalone daemon. In this case include the -f option to strace so it
follows the child processes as well. (When starting in.telnetd manually,
give it the -debug flag so it knows to behave like a server, listening to
the telnet port etc.) Remember to restart xinetd each time you change its
configuration.

Enrique

 
 
 

Weird network problem - Second NIC lags terribly when first NIC uses a gateway - Help...?

Post by Dean Thompso » Sat, 28 Jul 2001 21:52:18


Hi!,

Quote:> > My resolv.conf is generated by dhcpcd (or pump, the same problem happens
> > either way) and contains the correct info for my ISP's primary and
> > secondary
> > name servers.  I can correctly resolve any hostname I like.

> > But, that shouldn't matter anyway, because none of my problems involve
> > name resolution; for example, my test case of telnetting to the internal
> > interface is done simply with 'telnet 192.168.0.1'.

> It's weird, this.

> Seems an idea to find out what the computer spends the time at during the
> 20 seconds gap:

> 23:20:30.436795 < 192.168.0.2.1709 > 192.168.0.1.telnet: P 4:22(18) ack 1
> win 17520 (DF) (ttl 128, id 28912)
> 23:20:30.436795 > 192.168.0.1.telnet > 192.168.0.2.1709: . 1:1(0) ack 22
> win 5840 (DF) (ttl 64, id 49743)
> 23:20:50.486795 > 192.168.0.1.telnet > 192.168.0.2.1709: P 1:13(12) ack 22
> win 5840 (DF) [tos 0x10]  (ttl 64, id 49744)

> Clearly, the telnet connection is established, maybe there are some telnet
> options negotiations going on. No firewall issues here.

> I dear not swear there are no name resolution issues going on, even if your
> argument seems plausible.

Of course, make sure that the telnet server is not trying to perform a reverse
DNS lookup on the incoming connection.  What happens if both 192.168.0.2 and
192.168.0.1 are listed in the /etc/hosts file ?

See ya

Dean Thompson

--
+____________________________+____________________________________________+

| Bach. Computing (Hons)     | ICQ     - 45191180                         |
| PhD Student                | Office  - <Off-Campus>                     |
| School Comp.Sci & Soft.Eng | Phone   - +61 3 9903 2787 (Gen. Office)    |
| MONASH (Caulfield Campus)  | Fax     - +61 3 9903 1077                  |
| Melbourne, Australia       |                                            |
+----------------------------+--------------------------------------------+

 
 
 

Weird network problem - Second NIC lags terribly when first NIC uses a gateway - Help...?

Post by Joshua Gustafso » Mon, 30 Jul 2001 01:53:23


The problem has been solved!  :-)

I ran the strace dump and examined the system calls, and it turns out that
the telnet daemon was indeed connecting to my DNS servers during those 20
seconds of downtime.  I could only assume that it was trying to do a reverse
DNS lookup for 192.168.0.2, the internal PC trying to telnet to the server.
Naturally, the external DNS servers would have no valid response for such a
query; my guess is that my ISP recently changed software or settings on the
DNS servers, where before they quickly replied with no valid name, but now
take 20 seconds to reply, or something along those lines.  At any rate, I
had assumed that the DHCP daemon I run for the internal network would add an
entry in /etc/hosts for machines on the internal network when they obtain a
lease; apparently that assumption was mistaken.  I added entries manually
for all the internal machines, eliminating the reverse-DNS calls to the
external DNS servers, and now everything works fine.

Props to Enrique for pointing out the existence of strace to me, and really
big props to Dean Thompson for hitting the nail right on the head (although
I didn't read his message until I'd figured it out myself, the hard way -
D'oh!)

-Josh



> > My resolv.conf is generated by dhcpcd (or pump, the same problem happens
> > either way) and contains the correct info for my ISP's primary and
> > secondary
> > name servers.  I can correctly resolve any hostname I like.

> > But, that shouldn't matter anyway, because none of my problems involve
> > name resolution; for example, my test case of telnetting to the internal
> > interface is done simply with 'telnet 192.168.0.1'.

> It's weird, this.

> Seems an idea to find out what the computer spends the time at during the
> 20 seconds gap:

> 23:20:30.436795 < 192.168.0.2.1709 > 192.168.0.1.telnet: P 4:22(18) ack 1
> win 17520 (DF) (ttl 128, id 28912)
> 23:20:30.436795 > 192.168.0.1.telnet > 192.168.0.2.1709: . 1:1(0) ack 22
win
> 5840 (DF) (ttl 64, id 49743)
> 23:20:50.486795 > 192.168.0.1.telnet > 192.168.0.2.1709: P 1:13(12) ack 22
> win 5840 (DF) [tos 0x10]  (ttl 64, id 49744)

> Clearly, the telnet connection is established, maybe there are some telnet
> options negotiations going on. No firewall issues here.

> I dear not swear there are no name resolution issues going on, even if
your
> argument seems plausible.

> How did you start tcpdump? make sure it says
> "tcpdump: listening on all devices" when it starts. That will tell if
> something is going on on the other interfece(s) during that time.

> It would also be nice to know what are the 18 bytes sent from client to
> server just before the delay. Not very likely to give much cues, but
having
> little better to do, we might try to decipher some telnet option
> negotiation, if that is what is going on.

> Could you run tcpdump with -s 1550 -x ?
> That will include a hex dump of the ip packages. (warning: that may reveal
> passwords! You might want to temporarily change some passwords before
doing
> the test.

> I do not know to what degree the timing might be altered by running
> tcpdump. In any case, the ascii output from tcpdump makes tcpdump try to
> look up the names of all ip addresses, so make sure this does not happen
> while you are collecting packages. Use the -w outfile option, that saves
> the data in a fairly raw format. Once the measurement is over, you
decipher
> the file using tcpdump again, this time with the option -r inputfile.

> If things get hard, maybe you should arrange to run the telnet daemon
under
> strace. Then we can see what system calls telnetd is doing, and to some
> degree, whith what parameters.

> Normally telnetd is started by xinetd. maybe it is possible to manipulate
> the file /etc/xinetd.d/telnet so it starts /usr/bin/strace -o outputfile
> /usr/sbin/in.telnetd rather than just /usr/sbin/in.telnetd. If that does
> not work, perhaps you should disable telnet in xinetd and start it
manually
> as a standalone daemon. In this case include the -f option to strace so it
> follows the child processes as well. (When starting in.telnetd manually,
> give it the -debug flag so it knows to behave like a server, listening to
> the telnet port etc.) Remember to restart xinetd each time you change its
> configuration.

> Enrique

 
 
 

Weird network problem - Second NIC lags terribly when first NIC uses a gateway - Help...?

Post by Markus Scataclism » Sat, 04 Aug 2001 19:43:20


Hi Joshua,
        I am writing to you because I posted a similar message for a similar
trouble I have. I also know other 4 people to whom the same problem we are
experiencing appeared recently: about a month or so. I wonder if you
resolved the problem anyhow. Or maybe we are in front of a Linux epidemic.
for your reference the title of my post is "weird telnet FTP problem..." and
is just one day after your. here follows are the reply I received:

First Reply
_____________________________________________________________-

Hi!,

> 1. I have a Red Hat 6.1 box that I user for firewall and NAT
> 2. It has two ethercards (eth0 and eth1).
> 3. eth0 IP is the classic 192.168.0.1 for the internal network connected
to
> a 8 port switch (where other internal network computers also connect).
> 4. eth1 IP is given with pump through the cable modem.

> Both card are up and running for years now; I can Browse, FTP, IRC and all
> the other beautiful thing to any outside site; from outside I can telnet
> and FTP in the box using the eth1 IP address.

> Now here is the problem: lately I cannot telnet or FTP to the box from the
> internal network using any of the two ethercard IP addresses.
> And on top of it from the box console I can telnet or FTP the eth1 card
> (the external network one) all the time, but I can do the same to eth0
card
> (the internal network one) only 10% of the time.

Check to make sure that all the network devices are using the same network
speed.  Apart from that, you might like to check to make sure that there has
been no sudden firewall added to the system which would cause a number of
problems.  Apart from that, you haven't added a domain name server which
might
be causing complications for reverse lookups.

Finally, if none of those look, check the cabling, network cards and
possibly
put a packet sniffer on the network and see whether or not you can identify
the cause of the lost/missing packets.

See ya

Dean Thompson

--
+____________________________+____________________________________________+
| Dean Thompson              | E-mail  - Dean.Thomp...@csse.monash.edu.au |
| Bach. Computing (Hons)     | ICQ     - 45191180                         |
| PhD Student                | Office  - <Off-Campus>                     |
| School Comp.Sci & Soft.Eng | Phone   - +61 3 9903 2787 (Gen. Office)    |
| MONASH (Caulfield Campus)  | Fax     - +61 3 9903 1077                  |
| Melbourne, Australia       |                                            |
+----------------------------+--------------------------------------------+

Second Reply
_________________________________________________________________________-
Hi!,

> It is almost not possible from inside network to telnet or FTP to any of
> the two card: 98%
> It is possible from either the Linux box and any machine from the inside
> network to browse the web, FTP, Telnet and all the rest to the outside.

> It is possible from the box to telnet and FTP the eth1 card IP, but not
the
> eth0 card IP.
> It is possible from the outside (internet) telnet and FTP to eth1 with no
> problem.
> It is possible from the inside network to Samba, NFS and Browse the box if
> those services are up on it, but still no telnet or FTP.

It sounds two me along with the gab in the tcpdump that it is a reverse DNS
lookup problem.

See ya

Dean Thompson

--
+____________________________+____________________________________________+
| Dean Thompson              | E-mail  - Dean.Thomp...@csse.monash.edu.au |
| Bach. Computing (Hons)     | ICQ     - 45191180                         |
| PhD Student                | Office  - <Off-Campus>                     |
| School Comp.Sci & Soft.Eng | Phone   - +61 3 9903 2787 (Gen. Office)    |
| MONASH (Caulfield Campus)  | Fax     - +61 3 9903 1077                  |
| Melbourne, Australia       |                                            |
+----------------------------+--------------------------------------------+

___________________________________________________________________
Let me know if you have more infos...
___________________________________________________________________

"Joshua Gustafson" <j...@timsh.dhs.org> wrote in message

news:T7287.2043$Kd7.1509048@news1.rdc1.sfba.home.com...

- Show quoted text -

> Here's a really strange network problem for those of you who've been
around
> the linux networking block longer than I:

> I have a linux machine setup as a firewall & masquerader for a small home
> network of windows machines.  I've had everything (firewall, masquerade,
> DNS, samba, web/ftp/mail servers, etc) working as it should for months.
> Then, two days ago, for no cause I can currently identify (I don't recall
> changing anything and nobody else has access to the server), it started
> having the following problem.  Whenever eth0 (my external connection,
> usually configured by DHCP) is up and running, eth1 (my internal
connection)
> becomes very very lagged, especially on establishing connections.  It
takes
> around 30 seconds just to open a telnet session.  No data appears to be
> _lost_, it's just very lagged.  ICMP pings are unaffected, however.  I can
> still connect to _outside_ servers at normal speeds from the internal
> network, as well; it's only connecting to my linux box that's lagged.
Also,
> from the linux box itself, I can connect to eth0 or lo at full speed, but
> connecting to eth1 from the linux box itself is lagged.  If I take eth0
down
> ('ifdown eth0') then eth1 works perfectly in all cases.  If I unplug eth0
> from the cable modem and configure it as a dummy local network of its own,
> then both interfaces work fine at full speed.  If I manually configure
eth0
> with the parameters that the DHCP server would normally give it (I've got
a
> static IP anyway), EXCEPT for the gateway setting, then everything works
> fine, except of course that I can't connect to the internet without the
> gateway.

> So, if eth0 is setup to know its gateway, then eth1 becomes very lagged.
If
> eth0 is not set up to know its gateway, then eth1 works perfectly.

> Does anyone have any clue what might be causing this or how to fix it?
It's
> getting really frustrating, not to mention the hours of work I'm loosing
> until I get it fixed.  (Long story, but fast remote access to my server is
> crucial for my work.)

> Machine specs: (lemme know if there's anything I'm forgetting that would
> help to know)
> RedHat 7.1 (kernel 2.4.2-2) on an Intel Celeron 633, 256mb ram, all the
> latest non-kernel updates from RHN

> /etc/sysconfig/network-scripts/ifcfg-eth0:
> DEVICE=eth0
> BOOTPROTO=dhcp
> ONBOOT=yes
> DHCP_HOSTNAME=(My ISP-assigned hostname)

> /etc/sysconfig/network-scripts/ifcfg-eth1:
> DEVICE=eth1
> BROADCAST=192.168.0.255
> IPADDR=192.168.0.1
> NETMASK=255.255.255.0
> NETWORK=192.168.0.0
> ONBOOT=yes

> /etc/sysconfig/hwconf:
> ...
> -
> class: NETWORK
> bus: PCI
> detached: 0
> device: eth
> driver: 8139too
> desc: "Realtek|RTL-8139"
> vendorId: 10ec
> deviceId: 8139
> subVendorId: 10ec
> subDeviceId: 8139
> pciType: 1
> -
> class: NETWORK
> bus: PCI
> detached: 0
> device: eth
> driver: tulip
> desc: "DEC|DECchip 21041 [Tulip Pass 3]"
> vendorId: 1011
> deviceId: 0014
> subVendorId: 10b8
> subDeviceId: 2008
> pciType: 1
> -
> ...

> /etc/sysctl.conf:
> # Disables packet forwarding
> #net.ipv4.ip_forward = 0
> net.ipv4.ip_forward = 1
> net.ipv4.ip_always_defrag = 1
> # Enables source route verification
> net.ipv4.conf.all.rp_filter = 1
> # Disables the magic-sysrq key
> kernel.sysrq = 0

> 'lsmod':
> Module                  Size  Used by
> agpgart                23392   7  (autoclean)
> autofs                 11264   1  (autoclean)
> ipt_MASQUERADE          1712   1  (autoclean)
> ipt_state               1200   2  (autoclean)
> iptable_mangle          2272   0  (autoclean) (unused)
> 8139too                16480   1  (autoclean)
> tulip                  38544   1  (autoclean)
> iptable_filter          2304   0  (autoclean) (unused)
> iptable_nat            16160   0  [ipt_MASQUERADE]
> ip_conntrack           15824   2  [ipt_MASQUERADE ipt_state iptable_nat]
> ip_tables              11072   7  [ipt_MASQUERADE ipt_state iptable_mangle
> iptable_filter iptable_nat]
> usb-uhci               20720   0  (unused)
> usbcore                49664   1  [usb-uhci]
> raid0                   3856   3

 
 
 

Weird network problem - Second NIC lags terribly when first NIC uses a gateway - Help...?

Post by Joshua Gustafso » Sun, 05 Aug 2001 11:06:49


I _did_ resolve the problem, actually, and posted the solution, but it seems
not to have made it to my news server and I can only assume that the post
didn't get any farther that that.  At any rate, though, to make a long
stoary short, after tracing network packets and system calls and such, I
traced my problem to reverse domain name lookups:

- A machine on the internal net would attempt a connection to the server
- The daemon on the server sould decide that, in addition to the IP of the
internal machine attempting the connection (say 192.168.0.2), it would like
the domain name as well
- The daemon would check /etc/hosts for "192.168.0.2".  No luck, it's not
there.
- The daemon then asks the primary DNS server (configured through dhcp and
therfore "out there" on the real internet) for the domain name of
"192.168.0.2".  The DNS server doesn't know.  For some reason, this takes a
full ten seconds.
- The daemon then asks the secondary DNS server.  Now a 20 second total lag.
- The daemon gives up and contents itself with just the IP and no domain
name

Now, that 20 second lag is what killed me.  So, I cut it off at the pass; I
added entries to /etc/hosts for each machine on the internal network.  Now
192.168.0.2 reverse-resolves to "private2", with no need to query the
external DNS servers.

The interesting thing is, that my setup worked fine for months without those
entries in /etc/hosts.  I can only assume that the calls to the external DNS
servers were being made all along, but that the failure didn't cause a 10
second delay.  I would guess that my ISP changed some aspect of their DNS
servers which introduced that delay on failure.  Weird, huh?

-Josh

"Markus Scataclisma" <atlant...@earthlink.net> wrote in message

news:cfva7.1179$xY6.127937@newsread2.prod.itd.earthlink.net...
> Hi Joshua,
>         I am writing to you because I posted a similar message for a
similar
> trouble I have. I also know other 4 people to whom the same problem we are
> experiencing appeared recently: about a month or so. I wonder if you
> resolved the problem anyhow. Or maybe we are in front of a Linux epidemic.
> for your reference the title of my post is "weird telnet FTP problem..."
and
> is just one day after your. here follows are the reply I received:

> First Reply
> _____________________________________________________________-

> Hi!,

> > 1. I have a Red Hat 6.1 box that I user for firewall and NAT
> > 2. It has two ethercards (eth0 and eth1).
> > 3. eth0 IP is the classic 192.168.0.1 for the internal network connected
> to
> > a 8 port switch (where other internal network computers also connect).
> > 4. eth1 IP is given with pump through the cable modem.

> > Both card are up and running for years now; I can Browse, FTP, IRC and
all
> > the other beautiful thing to any outside site; from outside I can telnet
> > and FTP in the box using the eth1 IP address.

> > Now here is the problem: lately I cannot telnet or FTP to the box from
the
> > internal network using any of the two ethercard IP addresses.
> > And on top of it from the box console I can telnet or FTP the eth1 card
> > (the external network one) all the time, but I can do the same to eth0
> card
> > (the internal network one) only 10% of the time.

> Check to make sure that all the network devices are using the same network
> speed.  Apart from that, you might like to check to make sure that there
has
> been no sudden firewall added to the system which would cause a number of
> problems.  Apart from that, you haven't added a domain name server which
> might
> be causing complications for reverse lookups.

> Finally, if none of those look, check the cabling, network cards and
> possibly
> put a packet sniffer on the network and see whether or not you can
identify
> the cause of the lost/missing packets.

> See ya

> Dean Thompson

> --

+____________________________+____________________________________________+
> | Dean Thompson              | E-mail  - Dean.Thomp...@csse.monash.edu.au
|
> | Bach. Computing (Hons)     | ICQ     - 45191180
|
> | PhD Student                | Office  - <Off-Campus>
|
> | School Comp.Sci & Soft.Eng | Phone   - +61 3 9903 2787 (Gen. Office)
|
> | MONASH (Caulfield Campus)  | Fax     - +61 3 9903 1077
|
> | Melbourne, Australia       |
|

+----------------------------+--------------------------------------------+

- Show quoted text -

> Second Reply
> _________________________________________________________________________-
> Hi!,

> > It is almost not possible from inside network to telnet or FTP to any of
> > the two card: 98%
> > It is possible from either the Linux box and any machine from the inside
> > network to browse the web, FTP, Telnet and all the rest to the outside.

> > It is possible from the box to telnet and FTP the eth1 card IP, but not
> the
> > eth0 card IP.
> > It is possible from the outside (internet) telnet and FTP to eth1 with
no
> > problem.
> > It is possible from the inside network to Samba, NFS and Browse the box
if
> > those services are up on it, but still no telnet or FTP.

> It sounds two me along with the gab in the tcpdump that it is a reverse
DNS
> lookup problem.

> See ya

> Dean Thompson

> --

+____________________________+____________________________________________+
> | Dean Thompson              | E-mail  - Dean.Thomp...@csse.monash.edu.au
|
> | Bach. Computing (Hons)     | ICQ     - 45191180
|
> | PhD Student                | Office  - <Off-Campus>
|
> | School Comp.Sci & Soft.Eng | Phone   - +61 3 9903 2787 (Gen. Office)
|
> | MONASH (Caulfield Campus)  | Fax     - +61 3 9903 1077
|
> | Melbourne, Australia       |
|

+----------------------------+--------------------------------------------+

- Show quoted text -

> ___________________________________________________________________
> Let me know if you have more infos...
> ___________________________________________________________________

> "Joshua Gustafson" <j...@timsh.dhs.org> wrote in message
> news:T7287.2043$Kd7.1509048@news1.rdc1.sfba.home.com...
> > Here's a really strange network problem for those of you who've been
> around
> > the linux networking block longer than I:

> > I have a linux machine setup as a firewall & masquerader for a small
home
> > network of windows machines.  I've had everything (firewall, masquerade,
> > DNS, samba, web/ftp/mail servers, etc) working as it should for months.
> > Then, two days ago, for no cause I can currently identify (I don't
recall
> > changing anything and nobody else has access to the server), it started
> > having the following problem.  Whenever eth0 (my external connection,
> > usually configured by DHCP) is up and running, eth1 (my internal
> connection)
> > becomes very very lagged, especially on establishing connections.  It
> takes
> > around 30 seconds just to open a telnet session.  No data appears to be
> > _lost_, it's just very lagged.  ICMP pings are unaffected, however.  I
can
> > still connect to _outside_ servers at normal speeds from the internal
> > network, as well; it's only connecting to my linux box that's lagged.
> Also,
> > from the linux box itself, I can connect to eth0 or lo at full speed,
but
> > connecting to eth1 from the linux box itself is lagged.  If I take eth0
> down
> > ('ifdown eth0') then eth1 works perfectly in all cases.  If I unplug
eth0
> > from the cable modem and configure it as a dummy local network of its
own,
> > then both interfaces work fine at full speed.  If I manually configure
> eth0
> > with the parameters that the DHCP server would normally give it (I've
got
> a
> > static IP anyway), EXCEPT for the gateway setting, then everything works
> > fine, except of course that I can't connect to the internet without the
> > gateway.

> > So, if eth0 is setup to know its gateway, then eth1 becomes very lagged.
> If
> > eth0 is not set up to know its gateway, then eth1 works perfectly.

> > Does anyone have any clue what might be causing this or how to fix it?
> It's
> > getting really frustrating, not to mention the hours of work I'm loosing
> > until I get it fixed.  (Long story, but fast remote access to my server
is
> > crucial for my work.)

> > Machine specs: (lemme know if there's anything I'm forgetting that would
> > help to know)
> > RedHat 7.1 (kernel 2.4.2-2) on an Intel Celeron 633, 256mb ram, all the
> > latest non-kernel updates from RHN

> > /etc/sysconfig/network-scripts/ifcfg-eth0:
> > DEVICE=eth0
> > BOOTPROTO=dhcp
> > ONBOOT=yes
> > DHCP_HOSTNAME=(My ISP-assigned hostname)

> > /etc/sysconfig/network-scripts/ifcfg-eth1:
> > DEVICE=eth1
> > BROADCAST=192.168.0.255
> > IPADDR=192.168.0.1
> > NETMASK=255.255.255.0
> > NETWORK=192.168.0.0
> > ONBOOT=yes

> > /etc/sysconfig/hwconf:
> > ...
> > -
> > class: NETWORK
> > bus: PCI
> > detached: 0
> > device: eth
> > driver: 8139too
> > desc: "Realtek|RTL-8139"
> > vendorId: 10ec
> > deviceId: 8139
> > subVendorId: 10ec
> > subDeviceId: 8139
> > pciType: 1
> > -
> > class: NETWORK
> > bus: PCI
> > detached: 0
> > device: eth
> > driver: tulip
> > desc: "DEC|DECchip 21041 [Tulip Pass 3]"
> > vendorId: 1011
> > deviceId: 0014
> > subVendorId: 10b8
> > subDeviceId: 2008
> > pciType: 1
> > -
> > ...

> > /etc/sysctl.conf:
> > # Disables packet forwarding
> > #net.ipv4.ip_forward = 0
> > net.ipv4.ip_forward = 1
> > net.ipv4.ip_always_defrag = 1
> > # Enables source route verification
> > net.ipv4.conf.all.rp_filter = 1
> > # Disables the magic-sysrq key
> > kernel.sysrq = 0

> > 'lsmod':
> > Module                  Size  Used by
> > agpgart                23392   7  (autoclean)
> > autofs                 11264   1  (autoclean)
> > ipt_MASQUERADE          1712   1  (autoclean)
> > ipt_state               1200   2  (autoclean)
> > iptable_mangle          2272   0  (autoclean) (unused)
> > 8139too                16480   1  (autoclean)
> > tulip                  38544   1  (autoclean)
> > iptable_filter          2304   0  (autoclean) (unused)
> > iptable_nat      

...

read more »

 
 
 

1. two routers (two wans) connecting to one lan using two nics.

Hello,
Let me try reposting this once more maybe I wasn't too clear in my
previous post.
I have a Linux RH7.3 server running ssh service. I want clients to log
in using ssh from two different Wans.

Wan1: Frame relay router (closed network with another frame relay
router)
Wan2:DSL router allowing clients to login from the internet.

The ip of the frame relay router is 192.168.100.254
The ip of the dsl router is 192.168.10.254

The fr relay is associated with eth0:192.168.100.10 defaultgw
192.168.100.254
The dsl is associated with eth1:192.168.10.10 defaultgw 192.168.10.254

Our GUI network configurator is not working due to bugzilla reports.
However it worked during the initial install and setup of these two
cards. But now we cannot access the tool.
We tried linuxconf but that only allows us one default gw to be
configured. Only one network works at a time.

Is it possible to have two default gateways (one per interface) and
have the box recognize and negotiate them both at the same time?
Which config files can I vi to achieve the desired result of two
gateways without using the gui tool?
If we are only allowed one default gateway per machine, how will the
box know
that the other router exists?
If static routes is the answer, then it is not clear to me how this
will work.
route -net add 192.168.10.0 255.255.255.0 eth1
Remember someone coming over the internet will have a private ip of
192.168.20.1 nat'ed through some pubic ip 68.1.1.10 for example trying
to ssh to
my public ip 68.1.10.20 conecting to my eth1:192.168.10.10.

        |--?------eth1---dsl router--------internet      
server--|                            
        |--defgw--eth0---frame router1--|--frame router2

Any suggestions?

Thanks guys.

2. Sendmail and ISP

3. Two IP's over one NIC and two gateways

4. IDE rwproc field

5. one NIC, two Gateway, Cable + DSL, very complex routing problem...

6. Red Hat ftp upgrade

7. One NIC-two gateways. route help

8. select and blocking

9. routing - 3comps - one dualport-nic & two "normal" nics

10. two IP's on one machine using two differnet NIC's

11. Can't telnet to ONE of TWO NICs on Dual NIC System.

12. One system, one NIC, two network addresses?

13. How to specify/detect an NIC when using two or more NIC