Sorry I gave the same info for "eth0" twice. "eth1" is:
eth1 Link encap:Ethernet HWaddr 00:D0:B7:44:2D:41
inet addr:172.16.130.79 Bcast:172.16.131.255
Mask:255.255.254.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1810 errors:0 dropped:0 overruns:0 frame:0
TX packets:207 errors:21 dropped:0 overruns:4 carrier:0
collisions:0 txqueuelen:100
Interrupt:28 Base address:0xf000
Thanks,
- Matt
Matt Fahrner wrote:
>
> Ok, well I have more information now (so I'm hoping this will jog
> someone's memory about the same issue)...
>
> I'll summarize first and then explain more. What appears to be happening
> is if we're trying to reply to a packet that came in from an interface
> that isn't the default route to a host that would require using the
> default route to get back to it, then we generate the source address of
> the packet out the default route interface with the address of the
> interface the packet came in on!!!! This is completely repeatable on my
> 6.2 kernel.
>
> So if you have setup like:
>
> +-------------+
> | |
> -------------A+ Linux |
> | Box |
> -------------B+ |
> | |
> +-------------+
>
> If your default route is out interface "A", and a packet comes in on
> interface "B" from a host that requires the default route to reply to it
> (that is, not sharing either net "A" or "B") then even though the return
> packets come out interface "A" (the default) they have the source
> address from interface "B"!
>
> Unfortunately because of our fancy Xylan/Alcatel switch they get
> delivered, but it can cause problems with other things later.
>
> So on our box where interface "A" would be:
>
> eth0 Link encap:Ethernet HWaddr 00:B0:D0:21:A3:7F
> inet addr:172.16.128.79 Bcast:172.16.129.25
> Mask:255.255.254.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:4957 errors:0 dropped:0 overruns:0 frame:0
> TX packets:1566 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> Interrupt:16 Base address:0xd000
>
> and "B" would be:
>
> eth0 Link encap:Ethernet HWaddr 00:B0:D0:21:A3:7F
> inet addr:172.16.128.79 Bcast:172.16.129.255
> Mask:255.255.254.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:4957 errors:0 dropped:0 overruns:0 frame:0
> TX packets:1566 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> Interrupt:16 Base address:0xd000
>
> and the default is:
>
> Destination Gateway Genmask Flags MSS Window irtt Iface
> 0.0.0.0 172.16.128.1 0.0.0.0 UG 0 0 0 eth0
>
> Then this "tcpdump" which should show no packets:
>
> tcpdump -l -n -i eth0 host 172.16.130.79
>
> as the IP is for "eth1" not "eth0". Instead shows stuff like:
>
> 10:47:15.078228 > 172.16.130.79 > 164.153.17.14: icmp: echo reply
> 12:08:00.070220 > 172.16.130.79 > 172.16.128.196: icmp:
> 172.16.130.79 udp port snmp unreachable [tos 0xc0]
> 12:08:01.157990 > 172.16.130.79 > 172.16.128.196: icmp:
> 172.16.130.79 udp port snmp unreachable [tos 0xc0]
>
> which is stuff bound out the default route (eth0) but the originating
> packet came in on "eth1". Note it only shows outbound (we don't see
> anything coming in for the wrong address which makes some sense).
>
> Anyone seen this or a fix. It looks like a major bug to me.
>
> Thanks,
>
> - Matt
>
> Matt Fahrner wrote:
> >
> > You're probably going to just tell me to upgrade but...
> >
> > Anyone seen this?
> >
> > We have a RedHat 6.2 system with stock kernel with two Intel
> > Etherexpress Pro 10/100 cards:
> >
> > alias eth0 eepro100
> > alias eth1 eepro100
> >
> > "eth0" has the IP and MAC address of:
> >
> > 172.16.128.79 00:B0:D0:21:A3:7F
> >
> > and "eth1":
> >
> > 172.16.130.79 00:D0:B7:44:2D:41
> >
> > Note the mask is 255.255.254.0 so they're on different subnets.
> >
> > The weird thing we're getting is that sometimes somehow our Cisco which
> > is connected to both subnets is learning both IP addresses against the
> > MAC of "eth0", eg (from "show arp"):
> >
> > Internet 172.16.128.79 1 00b0.d021.a37f ARPA FastEthernet3/1
> > Internet 172.16.130.79 190 00b0.d021.a37f ARPA FastEthernet3/0
> > ^^^^^^^^^^^^^^
> > ||||||||||||||
> >
> > Wrong! Should be: 00d0.b744.2d41!
> >
> > meaning packets that should be bound out "eth1" must somehow be leaking
> > out "eth0" and causing the Cisco ARP table to get maligned. Since most
> > hosts off-net of either of these nets use the same Cisco to route to
> > this host (and the host is multihomed in the DNS), the Cisco when
> > forwarding the routed packets wrongly thinks it knows the correct arp
> > for the 172.16.130.79 (eth1) address and then doesn't try to arp up the
> > address. This in turn causes it to forward the packets against the wrong
> > MAC which are then ignored since they don't show up against the correct
> > interface/MAC combination.
> >
> > The only guess I have is something to do with interface naming confusion
> > (which I vaguely remember reading about somewhere) or a kernel bug.
> >
> > Any guesses, advice, etc?
> >
> > Thanks,
> >
> > - Matt
> >
> > --
> > ---------------------------------------------------------------------
> > Matt Fahrner 2 South Park St.
> > Manager of Networking Willis House
> > Burlington Coat Factory Warehouse Lebanon, N.H. 03766
> > TEL: (603) 448-4100 xt 5150 USA
> > FAX: (603) 443-6190 [EMAIL PROTECTED]
> > ---------------------------------------------------------------------
> >
> > _______________________________________________
> > Redhat-devel-list mailing list
> > [EMAIL PROTECTED]
> > https://listman.redhat.com/mailman/listinfo/redhat-devel-list
>
> --
> ---------------------------------------------------------------------
> Matt Fahrner 2 South Park St.
> Manager of Networking Willis House
> Burlington Coat Factory Warehouse Lebanon, N.H. 03766
> TEL: (603) 448-4100 xt 5150 USA
> FAX: (603) 443-6190 [EMAIL PROTECTED]
> ---------------------------------------------------------------------
--
---------------------------------------------------------------------
Matt Fahrner 2 South Park St.
Manager of Networking Willis House
Burlington Coat Factory Warehouse Lebanon, N.H. 03766
TEL: (603) 448-4100 xt 5150 USA
FAX: (603) 443-6190 [EMAIL PROTECTED]
---------------------------------------------------------------------
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
