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 [[email protected]] Sent: Thursday, November 07, 2013 8:32 AM To: Justin Krejci Cc: [email protected] 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 ([email protected]) 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 [[email protected]] > Received: Wednesday, 06 Nov 2013, 4:01pm > To: [email protected] [[email protected]] > 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 [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
