Network Outage: %ETHCNTR-3-LOOP_BACK_DETECTED

The network is performing well, unfortunately we received a call that the few of the directly connected to each other are not working and the links attached to the switches were also not working. After logging on to the switches, we saw a weird error message "%ETHCNTR-3-LOOP_BACK_DETECTED: Keepalive packet loop-back detected on FastEthernet0/1". Fa0/1 was uplink to another switch and the port state was showing error disabled. The switch port goes in error disable mode if it detects any error situation on the port. The port is shut down and need to enable manually or automatically if configured. By default, all the cisco switches and routers send loopback frames (ethertype 0x9000) with SA=DA=It’s own mac-address. If the Keepalive packet is received on the same port it was sent from, then a loop exists which even cannot be detected by spanning tree protocol. This is likely the same as of split horizon technique in layer three devices. The problem most likely arises because of unmanaged switches or hubs connected to the switches.
To overcome the problem, we need to add “no keepalive” command under interface which prevents the port from being disabled. This issue is documented in Cisco bug ID CSCea46385.

Disable "no errdisable detect cause loopback" command is another way to handle the problem. By doing this when the switch detects the error disable message of loopback, it will not take any action.

Click Here To Read Rest Of The Post...

Auto Negotiation Myth

The debate on auto negotiation is still on. I have faced the lot of outages because of auto negotiation. Sometimes you find that the working link with auto negotiation configured come up with half duplex consequences packet drops which may lead to the various outages. According to the IEEE 802.3u clause number 28, 802.3z clause number 37 standards the auto negotiation should be enabled on devices. This is optional but always recommended. The best is to read the SUN’s Ethernet Auto Negotiation Best Practises.
But I used to prefer to disable the auto negotiation and forcefully set the all capabilities. But after reading this paper, I come to know that after disabling auto negotiation we are not able to detect the following problems:-
1. Bad Cable Problem
2. Link failures
3. Link Partner Capabilities
4. Performance Issues
5. Pause Frames or Flow Control
If we are facing problems by enabling auto negotiation, In that case we need to talk to the vendors rather than disabling it.

Click Here To Read Rest Of The Post...

MPLS Works Without LDP/RSVP/CEF

Yesterday, I was troubleshooting one of the customer call and checking the forwarding table on each and every hop. surprisingly, one of the router was showing "Tag switching is not operational", "CEF or TAG switching has not been enabled.

Figure 1

I had checked all the configuration and seem to be fined as usual. After that enabled ip cef and was able to see the forwardng table entries. According to the perception, it may be a cef hang issue but the srange thing is that after 5 minutes I rolled back to the previous condition. No cef and tag switching was working but MPLS LDP peering was up with the adjacent neighbors.

The next output astonished me after seeing the ping received from other PE routers of the local vrf created on the router. All the vpnv4 labels were properly advertising to the MPLS cloud. I thought may be I was not seeing anything but everything working fine in the background. So I checked the PHP behaviour of loopback to the adjacent routers.

Figure 2

The adjacent routers showing untagged instead of pop tag. The ios was spservicesk9-mz.123-14.YT1.bin.

Below depicted is the output of vrf and ping from the other PE router.

Figure 3

Figure 4

End to end MPLS was working fine without cef,ldp and rsvp. But we cannot live with this situtaion so need to change the IOS.

Click Here To Read Rest Of The Post...

How To Calculate Memory Of Processes

We know that every process in cisco router requires memory to store its attributes ot data and we always excite to see the memory used by the process. Given is the command which helps to know about the process id of the process.

show processes memory sorted
PID TTY Allocated Freed Holding Getbufs Retbufs Process
0 0 64551468 7466932 49502136 0 0 *Init*
226 0 1263113088 1362187140 44258324 136024 0 BGP Router
The above mentioned output states that process id used by bgp is 226. Now run the given command to see the memory occupied by bgp process.

show processes memory 226Process ID: 226
Process Name: BGP Router
Total Memory Held: 44310980 bytes (48 Mb)

These commands help to troubleshoot memory related issues very fastly.

Click Here To Read Rest Of The Post...