[c-nsp] 6509 "switchport block unicast" wrongly filtering ARP broadcasts

[Justin Krejci]

To be clear this is just a simplified version of a live network that has many more vlans and networks with routing beyond the 6509. I reduced the topology to just the area where I've identified the problem and can still reproduce the problem.

Am I missing something? I thought "switchport block unicast" should only filter out unicast packets that it wants to flood, not broadcast packets that it wants to flood.




-----Original Message-----
From: Justin Krejci [JKrejci at usinternet.com]
Received: Wednesday, 06 Nov 2013, 4:01pm
To: cisco-nsp at puck.nether.net [cisco-nsp at puck.nether.net]
Subject: [c-nsp] 6509 "switchport block unicast" wrongly filtering ARP broadcasts

I have a relatively simple hardware configuration and topology

6509-E (tried on 2 different units)
Sup720 (also tried Sup720-3B)
WS-6548-GE-TX
WS-6748-GE-TX


IOS Version 12.2(33)SXI6


int g1/1
 switchport
 switchport access vlan 900
 switchport mode access
 switchport block multicast
 switchport block unicast
 no cdp enable
 spanning-tree portfast edge
 spanning-tree guard root

int vlan 900
 ip address 10.21.3.2 255.255.255.0
 standby 1 ip 10.21.3.1

monitor session 1 source interface g1/1 both
monitor session 1 destin interface g1/25

No other non-default vlans or IP addresses are defined anywhere on the 6509.


"laptop 1" plugged into port g1/1 with 10.21.3.129/24 assigned and is running tcpdump
"laptop 2" plugged into port g1/25 running tcpdump

To start out
6509 has no ARP entries for 10.21.3.129
6509 has no MAC entries for "laptop 1"

Initiate a ping from the 6509 and the "laptop 2" tcpdump shows the arp request from the 6509 source MAC address with destination MAC address FF:FF:FF:FF:FF:FF.
The "laptop 1" never sees the ARP packet at all.
The 6509 then inserts an Incomplete ARP entry for 10.21.3.129 for a short while.
No MAC table entries for "laptop 1" show up on the 6509 of course.
Then initiate a ping from "laptop 1" to 10.21.3.2 and everything works as expected, "laptop 1" sends ARP request and the ICMP echo and reply packets work correctly.
If I now clear the 6509 MAC entry for "laptop 1" and the ARP entry for 10.21.3.129 I am back to the 6509 sending broadcast ARP packets as seen in the port mirror on "laptop 2" but they never arrive to "laptop 1"

I stop my ping from "laptop 1" to the 6509.
If I then remove "switchport block unicast" from g1/1 this does not immediately resolve the problem, the ARP broadcast still does not get sent out port g1/1 toward "laptop 1" but do still see it on "laptop 2" via the port mirror. If I then re-initiate a ping from "laptop 1" to 10.21.3.2 again everything works as expected as before. If I stop the ping from "laptop 1" then I clear the 6509 MAC table entry and ARP entry the 6509 then sends another ARP broadcast for 10.21.3.129 and its sent out port g1/1 toward "laptop 1" and normal communication works as expected from that point on.

A similar configuration on a routing Catalyst 3560 with "switchport block unicast" on does not suffer from a similar ARP filtering problem, though I have not specifically captured the packets and done a close inspection, primarily because it appears to be working as designed.

So it appears to me there are two problems in this hardware/platform or IOS
1 - "switchport block unicast" is incorrectly filtering ARP broadcast packets
2 - removing "switchport block unicast" does not immediately stop filtering ARP broadcast packets

It sounds like IOS bug to me.
Has anyone run into this behaviour before?
Any thoughts?

TIA


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/