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]
---------------------------------------------------------------------
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
