Hi Lou, Although I've never seen this myself, it would (obviously ;-) ) appear to be a problem with the Linux IP stack. The workaround surely would be to create a static arp entry for the default gateway.
Regards, Andy Middlehurst -----Original Message----- From: Lou H. Goddard [mailto:[email protected]] Sent: 27 August 2009 15:35 To: Enterasys Customer Mailing List Subject: [enterasys] Odd ARP Behavior Greetings, This isn't specifically an Enterasys question. I'm addressing this list since there are several skilled individuals that participate daily. It's an interesting problem that may prove entertaining for you. I'm having a rather strange issue involving a Cisco router and a multi-homed Linux box. The Cisco is connected to four segments: 180/24,181/24,182/24,183/24. Cisco is numbered as follows: 180.12,181.12,182.12,183.12. The Linux host is connected to all four segments with unique addresses: 180.3,181.3,182.3,183.3. The Linux host has a default route of 205.153.180.12 and does not routinely communicate to non local networks. After a period of inactivity, the ARP entry for the default route will expire on the Linux host. A non-local host, 10.205.148.5 for example, will try to communicate with the Linux host on the 205.153.182.3 address. The inbound SYN to 182.3 entices the Linux host to respond with a SYNACK: 205.153.182.3 ---> 10.205.148.5. The SYNACK is never seen anywhere on the network because the lower down encapsulation never succeeds. Now that the stage is set, here's the issue with ARP. The Linux host needs to fill its ARP table with the MAC address for its default gateway. When the trigger traffic is destined to 181.3, 182.3, or 183.3 the host generates a rather odd ARP packet. 11:09:38.499539 00:15:17:76:01:1c > Broadcast, ethertype ARP (0x0806), length 42: arp who-has 205.153.180.12 tell 205.153.182.3 11:09:39.499556 00:15:17:76:01:1c > Broadcast, ethertype ARP (0x0806), length 42: arp who-has 205.153.180.12 tell 205.153.182.3 That packet leaves the Linux host's interface that is physically connected to the 180/24 network. The Cisco rejects this ARP with the following line: IP ARP req filtered src 205.153.182.3 0015.1776.011c, dst 205.153.180.12 0000.0000.0000 wrong cable, interface FastEthernet0/0 Since ARP cannot succeed the Linux host never generates the return traffic. If the ARP table already has the entry for the default route there is no issue with communication. The issue only appears when the Linux host does not have the ARP entry and the inbound communication is destined to one of its 181, 182, or 183 interfaces. Has anyone else seen odd ARP behavior similar to this with multihomed machines? Thanks, Lou Goddard ------------------ CONFIDENTIALITY NOTICE --------------- This message, including any attachments, is for the sole use of the intended recipient(s) and may contain privileged confidential information protected by law. Any unauthorized review, use, disclosure or distribution of this message is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of this message. ------------------ CONFIDENTIALITY NOTICE --------------- -------- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --- To unsubscribe from enterasys, send email to [email protected] with the body: unsubscribe enterasys [email protected] --- To unsubscribe from enterasys, send email to [email protected] with the body: unsubscribe enterasys [email protected]
