Unix workstations and HSRP virtual as default gateway?

Unanswered Question

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Jon Marshall Thu, 11/06/2008 - 13:06

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

cisco24x7 Thu, 11/06/2008 - 14:09

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:


[[email protected]]#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

[[email protected]]# 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

[[email protected]]#


Easy right?

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.

Actions

This Discussion