![cisco ios show mac address table cisco ios show mac address table](https://sites.google.com/site/redesintroduccion/_/rsrc/1487952038962/5-2-1-7-lab---viewing-the-switch-mac-address-table/33.png)
Group Port-Channel Type Protocol Member Ports I - Individual H - Hot-standby (LACP only) So, to find the physical interfaces included in that port-channel, I ran:įlags: D - Down P - Up in port-channel (members) Guess what? The MAC was found on a port-channel. Once the originating switch and port was identified, I could begin looking for the path to the destination. VLAN MAC Address Type age Secure NTFY Ports However, before jumping in, I needed the source and destination MAC addresses, as well as source and destination IP address (more on this later). Once the sever team provided all these, I began by finding the exact source switch and interface: The command mac address-table alone was not going to cut it, as sometimes the switch would see the MAC address over a port-channel, and I’d need to know which interface in the port channel had forwarded the packet. It was going to be tricky though, since the core switches were using both port-channels and virtual port-channels.
#CISCO IOS SHOW MAC ADDRESS TABLE MANUAL#
So, what was left was a manual Layer 2 trace, which means manually searching through the mac address-tables. It’s been around since 12.2(18) and you can use either MAC address or IP address to run the trace.
#CISCO IOS SHOW MAC ADDRESS TABLE SERIES#
Turns out Cisco does offer a Layer 2 traceroute utility for IOS on both the Cisco 7600 series routers and Catalyst 3560 series switches. What I needed was a layer 2 traceroute tool. In a routed environment, this would be a no-brainer: traceroute would have your answer. So the crucial first question is “what is the path?”
![cisco ios show mac address table cisco ios show mac address table](https://c1.neweggimages.com/ProductImage/33-316-416-01.jpg)
If just one interface in the path doesn’t allow jumbo frames, the conversation breaks. Either every device in the forwarding path allows jumbo packets, or they don’t. In my experience, troubleshooting jumbo frames begins simply. The network team went to some effort to prove our innocence, and there was the usual veiled finger-pointing by everyone else, “I’m not saying it’s a network problem, but…” Yeah, yeah, we know: the network is assumed guilty until proven innocent. Some vlans that used jumbo frames worked fine, but one vlan simply wouldn’t work. During the first week, we ran into a problem forwarding jumbo frames. The core is almost completely Layer 2, with most routing pushed to the distribution layer. I’ve recently been working in a data center environment with Nexus 70 switches in the core. Here’s how I solved the problem without fancy Layer 2 traceroute tools. Ever been stuck trying to figure out the exact switching path that packets take through your network? Me too.