ARP issues

[spencedavid21]

I have 2 6500 running hsrp over a dot1q trunk on vlan 1. A 3550 is then connected to switch 2 over a LES 100 link which is set up as a trunk at both ends. A 2950 then hangs off the 3550. The issue is that the 2950 can't ping the addresses on the 6500's due to missing arp entries. When sniffing the network I can see the arp requests at the 6500 from the 2950 and then the reply going back across the LES. The physical arp entries are in the 3550 not the stby address. How ever the physical Mac addresses for hsrp on VLAN 1 also has the same entries for other Vlans i.e. Vlan24 on the 3550.

The Mac address for VLAN 1 ip .250 also is against Vlan 24 ip .61 .

Can someone please explain this and is there a reason why the 2950 can't get arp entries for 249, 250 and 254.

Adding static ARP entries does resolve the issue but the customer requires that ARP is learned dynamically.

There are other devices hanging off the 3550 with the same issues ie Cisco Router and an F5 bigip

Refer to drawing for information.

[m.mcconnell]

2 things. Your drawing has expired and I cannot download it - could you repost?

It sounds like a mismatched configuration on one of the trunk ports. Would you be able to post the configs for your trunk ports?

A couple things to watch/check:

Did you change the native VLAN? If so make sure it is the same on bothe ends of the trunk.

Do you have CDP running? If so do CDP neighbors show where you expect to see them?

On the 2950 and 3550 do a show interface trunk and a

show interface switchport to make sure everything is configured and operating the same.

-Mark

[spencedavid21]

Hi Mark,

It looks as if RSPAN accross the LES trunk was causing the issue. Once the customer removed the RSPAN vlan arp started working and the 3550 got the entries for the HSRP addresses (VLAN1) which were on the 6509's. Not sure why the RSPAN vlan would cause this issue for VLAN1 (native for the LES trunk). I have raised a TAC case and am awaiting feedback.

The duplicate MAC addresses were a red herring in this case.

This has only ever affected VLAN 1. All other VLANs accross the trunk worked OK. I have re-attached the drawing fyi. Cheers.