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

[Justin Krejci]

Thanks Dale, removing "switchport block multicast" from the ports magically allows ARP to work correctly again.
However it also required me to bounce the interface (shutdown / no shutdown) before the "no switchport block multicast" actually seemed to take affect on the port in the same way as "no switchport block unicast" does as well. Seems like a bizarre and unfortunate problem but at least there it can be made to work.

Thanks again!


________________________________________
From: Dale W. Carder [dwcarder at wisc.edu]
Sent: Thursday, November 07, 2013 8:32 AM
To: Justin Krejci
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] 6509 "switchport block unicast" wrongly filtering  ARP broadcasts

It's the multicast block that's causing your problems.  On cat6k/720 the
multicast block impacts ARP and ipv6 ND, thus rendering that command
absolutely maleficent in any typical production environment.

Dale


Thus spake Justin Krejci (JKrejci at usinternet.com) on Thu, Nov 07, 2013 at 02:01:18PM +0000:
> 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/
> _______________________________________________
> 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/