I have two 6509 switches trunked together and configured with HSRP. These switches are our collapsed core in the Main Branch Site. 6509s have numerous layer 2 VLANs configured, each VLAN has an SVI configured for default gateway for each respective VLAN.
This is all standard config.
We have a device plugged into a switchport in one of the VLANs. This device is a Windows box, but currently is not communicating with anything, not even the default gateway of the SVI configured for it. The box is in the same VLAN as the SVI. IP stack is configured and working on this box, it can ping itself with ip address configured.
This is a new device being installed and I believe there is a firewall configured that is preventing the communication, but I don't understand what is going on here and I want to.
I can see the switchport is populated with a mac-address from the device, I can also see an arp entry in the 6509s for it, and it is the ip address configured within the Windows config.
What I don't see, is how are the mac-address and arp tables are getting populated from this device if it cannot communicate with anything?
It seems in order for the ARP table to be populated, this box would have to respond to an ARP from something.
I have an access list configured and applied inbound to the SVI on both 6509s to see if there is any traffic hitting the SVI from this host. I see no hits to\from the device, but the ARP and the mac-address tables continually get populated from the device on the port, after clearing them on both switches.
Anyone have any thoughts on this?
I guess my questions are, what exactly causes the mac-address and ARP table population on a layer three switch?
According to Cisco:
"When you connect a device, communication, i,e packet needs to be transferred between the device and switch in order to populate its mac-address-table. This transfer is initiated in form of ARP/ICMP request/reply. However, ARP doesn’t necessarily mean layer 3 communication. The ip address in an ARP packet is in the payload. The header contains the source MAC. So, even if you see an “incomplete” ARP, you will see the mac-address against it. Also, its regardless of any platform."
the CAM table is populated by learning source MAC address on frames received on the switchport to which the windows box is connected. These frames are ethernet frames and they don't need to carry an IP packet in the payload.
The ARP table is populated by ARP replies or gratuitous ARP replies (in some cases by ARP gleaning learning by user traffic)
I would say that the firewall is likely blocking all IP communication but ARP is not IP based it is its own protocol over ethernet (different ethertype ARP 0x0806, IPv4 0x0800)) so for this reason you see the entries in the CAM table and in the ARP table even if IP communication is not possible.
As the previous reply explains, the MAC and ARP entries are independent of the L3 communications . We always tend to set static entries on the devices to execlude these possibilties during troubleshooting connectivity problems.
Would suggest th following as the next step;
1) doublecheck the switch interface for any abnormal counter in the "show interface" output
2) test with basic config on the physical and Vlan interface (remove all fancy configs, test with the real address rather than the HSRP, or connect to the active HSRP switch and see the result - dont forget to set the STP ROOT to match the HSRP ACTIVE)
3) see if the problem is protocol specific (icmp, tcp .. Etc)
4) capture trafic on the switchport and the host(wireshark) to inspect requests and replies.
5) double check the MAC/ARP on line card and the SUP and see if they match( use "att " to connect to the linecard. If they dont match, try to force a HW reconfig by a "no switchport/switchport", shut unshut, switchover(non-sso) etc.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...