11-06-2008 12:52 PM - edited 03-06-2019 02:21 AM
Got an odd situation, I'm hoping someone with some unix / linux experience can weigh in here.
I have a topology with 2 Layer 3 3560s acting as my HSRP routers. Each 3560 has a HSRP instance running on a physical (non - SVI) interface. These interfaces are connected into a Layer 2 switch, as is the Linux server. The physical interfaces are .2 and .3, the hsrp virtual is .1
When I point the linux default GW to .1, I can not access the network. When I point it to .2 or .3, all is well. All my other non-linux hosts are just fine. We have disabled the firewall and security svcs on the linux server and it still does not work when pointed to the .1 gateway. Any thoughts?
TIA
James Hatfield, CCIE Voice #14896
11-06-2008 01:06 PM
James
Yes that is odd :-)
So your 3750 ports are routed interfaces both connecting to the same L2 switch ?
When you ping the .1 address from the Linux machine what does the arp cache show.
Most versions of linux have some sort of packet sniffer on them like tcpdump. Could you run a tcpdump and ping one of the physical addresses and then ping the virtual IP address so we can compare.
What would also be useful is to post the arp cache from a functional windows machine as well.
Jon
11-06-2008 02:09 PM
1- do you have sticky arp enable on the switch?
2- do "arp -an" on the linux box and see if
the mac addresses for .1, .2 and .3 match
what you see on the switch/router
3- perform "service network restart", that will
clear out the arp cache on the linux box,
last but not least, run tcpdump like this:
"tcpdump -nnn -e -i eth0 icmp and host x.x.x.x or host x.x.x.x"
That will tell you if you have arp issue or sticky arp issue. The "-e" option tells you
the MAC address that receives:
[Expert@P1-NGx]#tcpdump -nnn -e -i eth2 icmp and net 10.109.114
22:07:33.665279 0:b0:d0:b0:f3:42 0:0:c:7:ac:f 0800 98: 10.109.114.9 > 10.109.114.1: icmp: echo request (DF)
22:07:33.665739 0:5:0:7b:80:1 0:b0:d0:b0:f3:42 0800 98: 10.109.114.1 > 10.109.114.9: icmp: echo reply (DF)
22:07:36.305684 0:b0:d0:b0:f3:42 0:5:0:7b:80:1 0800 98: 10.109.114.9 > 10.109.114.2: icmp: echo request (DF)
22:07:36.306080 0:5:0:7b:80:1 0:b0:d0:b0:f3:42 0800 98: 10.109.114.2 > 10.109.114.9: icmp: echo reply (DF)
31 packets received by filter
0 packets dropped by kernel
[Expert@P1-NGx]# arp -an
? (10.109.114.1) at 00:00:0C:07:AC:0F [ether] on eth2
? (10.109.114.2) at 00:05:00:7B:80:01 [ether] on eth2
[Expert@P1-NGx]#
Easy right?
11-10-2008 04:35 AM
Thanks to both of you for the helpful advice, in the end it was this and Wireshark that helped me nail this down.
For some reason the client has a Ricoh printing appliance that was RIP advertising itself as the .1 default gateway. Once we determined the default gateway mac address in the unix arp table was wrong, we used wireshark to track down the offender.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide