Monday, August 24, 2009

Router Local Ping Strange

hi all,
When I ping any of routers local interface (incl lan and wan IPs), I am getting delays in 800-1500 ms, but at the same time if i ping to any machine on this routers lan, I am getting reply in 100-200 ms. Why is this so ? there is only one link to this router so there is no possibility of asymmetric routing. What I am feeling is that router is not responding properly to its local traffic but behaving properly for transient traffic ? what can be the issue. I have checked and cpu utilization is also like 5%-6%. On serial interface reliability is perfect but I am seeing some CRC but again why only router self packets are suffering ?

Above is the question which I was struggling with finally I was able to resolve this doubt in the following manner,



Hi,

It seems, what you are facing is a desirable behavior.

The reason could lie in the fact that router is a routing device. That means, it is designed to route and switch but not to act as a host.

Now needless to mention that some of the considerate in context to delay in this scenarios are as follows:

1. Packet across the router to the host are cef or fast switched VS packet destined to router which is process switched.

2. ICMP is a reachability test tool, rather than delay calculator. If you are concerned about the delay we may use "IP SLA". Though, I understand your aspiration is to find why delay difference rather then delay computation...

3. In the protocol stack of these networking devices the priority to the ICMP is extremely low. This might also be contributing to the delay. Though I read that your processors utilization is 5 odd %. I need to investigate the idle process is reflected at all in the cpu computation or not and we will have to see the priority of idle process verses ICMP process.


So to summerise the behavior- process switched vs CEF/fast switched. Priority of ICMP process.

therefore I would suggest do a packet capture on telnet session or an HTTP session to your router and look at the delta.

I am pretty confident that you would receive very encouraging values there.

Do kindly let me know if this makes any sense.

Regards..

Thursday, August 20, 2009

UDLD Behaviour


This is a discussion over a condition where in we have one way traffic between two switches. This is possible when either Rx or Tx goes bad. Either due to cable connector or transceiver malfunction. Now, indeed this is more relevant in context to fibre as compared to copper, which "usually" has two strands carrying Rx and Tx if cable type is the only consideration.

Now lets See how failure of or a condition of unidirectional communication can lead to loop.


Refer to the figure attached to the document where in STP has converged and the blocked port is SW3's e0/0."lost election to SW2 on the basis of BID - SW2 < SW3".


Now lets assume that the Rx of SW3 towards sw1 has failed - please be considerate of the fact that sw3 is still sending data to SW1 through its Tx.


Action:
Now under the above stated condition, if a host connected to sw2 or SW1 or SW3 generates an APR, lets assume a host on SW3, SW3 forwards it out e0/0 and e0/1. Just follow this frame and you will find that it loops forever.
WHY:
Because, the moment Rx of SW3 on e0/1 went bad, SW3 stopped receiving BPDU from root sw1 it transitions it's blocked(e0/0) port to RP and as it is not receiving any BPDU on e0/1 , it will assume that its host/edge port.

Henceforth UDLD is the protocol which ensures that if a unidirectional link is formed the interface be put to inconsistent state. I am not sure how this is achieved as this is prop to cisco I missed it somewhere but meeting this goal isn't that tough. It would be something similar on the lines of PPP magic number. Needless to mention that you need to enable UDLD on both the ends. One send the value and expects the same on its Rx in the absence of the same, the port is transitioned to inconsistent state.