Cisco HOW-TO‎ > ‎

Interesting Situations

Just ran into a situation involving Cisco 3560E switches.  These switches come with an out-of-band Ethernet management port and this was at the root of the situation.  All our switches plug their Ethernet management port into another switch.  This way they can be reached in most adverse situations.  The In addition to all the Ethernet management ports on this subnet, there is also a Linux server used for network services such as TFTP.  Every switch can ping the Linux server except for one. 


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 0 percent (0/5)

After looking into the issue further it was discovered that the switch that could not ping the Linux server was the very switch into which the Linux server was connected.  After examining packet dumps, pings and ARPs, I determined that the Ethernet management port could send traffic to the Linux server but packets from the Linux server could not successfully make it back to the Ethernet port.  When examining the switch's ARP table for it's Ethernet management port MAC address, it showed what was expected...the MAC address on FastEthernet 0.

switch#show arp | i
Internet             -   0024.c41e.39b7  ARPA   FastEthernet0

switch#show arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet             -   0024.c41e.39b7  ARPA   FastEthernet0

After gathering all this information, I determined that the 48 port switch fabric could see the management port's MAC address in the ARP table but did not realize it was also through the switch trunk.  (Perhaps the switch trunk wasn't dynamically remembering the management port's MAC?)  After manually adding a static mac entry for the management port through the trunk port, everything worked.

switch#mac-address-table static 0024.c41e.39b7 vlan 100 interface gig0/48

switch#show mac-address-table | i 0024.c41e.39b7
 100    0024.c41e.39b7    STATIC      Gi0/48