[c-nsp] SSO with ISIS NSF (IETF vs Cisco)

Tue Jan 15 11:34:52 EST 2008

Can you provide the complete config and a sh hardware for P2 (offlist if
necessary)
and I'll see what I can tell from them.

There should be no difference in switchover behavior between different
RP slots.

Ken

________________________________

From: Atif Sid [mailto:guru6111 at gmail.com] 
Sent: Tuesday, January 15, 2008 11:26 AM
To: Ken Weissner (kweissne)
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] SSO with ISIS NSF (IETF vs Cisco)

another interesting this i just noticed is that

Failover from RP8 to RP9 takes 30 Sec
while  from RP9 to RP8 is 8 secs

could there be config sync issue?

FAILOVER FROM RP8 TO RP9: (it reloads)

P2#redundancy force-switchover 
Proceed with switchover? [confirm]
System Bootstrap, Version 12.0(20040128:214555) [assafb-PRP1P_20040101
1.8dev(2.83)] DEVELOPMENT SOFTWARE
Copyright (c) 1994-2004 by cisco Systems, Inc. 

DRAM DIMM Slot 1: 2048M found, Slot 2: Empty 
MPC7457 platform with 2097152 Kbytes of main memory

Self decompressing the image :
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBB [OK] 

while RP9 to RP8:

P2#redundancy force-switchover 
Proceed with switchover? [confirm]
Switching roles - Standby to Active

SEC  8:*Jan 15 11:30:47.913 EST: %MBUS-6-SWITCHOVER: Switchover
initiated by active in slot 9, management request
SEC  8:*Jan 15 11:30:47.953 EST: %RP-5-NEWPRIMARY: Switchover to new RP
*Jan 15 11:30:47.973 EST: %LINK-3-UPDOWN: Interface Ethernet0, changed
state to up 
*Jan 15 11:30:47.977 EST: %LINK-5-CHANGED: Interface Ethernet1, changed
state to administratively down
*Jan 15 11:30:47.981 EST: %LINEPROTO-5-UPDOWN: Line protocol on
Interface , changed state to up
*Jan 15 11:30: 47.985 EST: %TAGCON-3-LCLTAG_ALLOC: Cannot allocate local
tag
*Jan 15 11:30:48.974 EST: %LINEPROTO-5-UPDOWN: Line protocol on
Interface Ethernet0, changed state to up
*Jan 15 11:30:48.978 EST: %LINEPROTO-5-UPDOWN: Line protocol on
Interface Ethernet1, changed state to down 
*Jan 15 11:30:48.982 EST: %LINEPROTO-5-UPDOWN: Line protocol on
Interface Ethernet2, changed state to down
*Jan 15 11:30:49.610 EST: %MBUS-6-RP_STATUS: RP in Slot 8 Mode = MBUS
Active

and i see sessions are UP within 8 seconds. 

IETF were both 30 Seconds.

On 1/15/08, Atif Sid <guru6111 at gmail.com> wrote: 

	Ok. and this was what I exptected but testing shows that when I
use IETF mode and failover it takes ~ 30 sec  + to  repair while in
Cisco mode it can converge in 8 seconds.

	Here is a test:

	3 routers: cisco 12410/PRP, IOS: 12.0(32)SY3

	P1 --> P2 --> P3

	* Pinging from p1 to p3 with timout set to 1 sec , all three
routers are in NSF Cisco. 
	* force a RP failover on P2, 

	P1#ping
	Protocol [ip]: 
	Target IP address: p3
	Repeat count [5]: 10000
	Datagram size [100]: 
	Timeout in seconds [2]: 1
	Extended commands [n]: 
	Sweep range of sizes [n]: 
	Type escape sequence to abort. 
	Sending 10000, 100-byte ICMP Echos to x.x.x.x, timeout is 1
seconds:

	Success rate is 99 percent (9992/10000), round-trip min/avg/max
= 1/1/4 ms
	P1#

	On 1/15/08, Ken Weissner (kweissne) <kweissne at cisco.com > wrote:

		Hello,

		I've just joined this list, so didnt have a copy of the
original email
		to reply to, which was forwarded by a colleague. 

		>My observation is that Cisco mode is faster then IETF,
in fact IETF
		has as delay as being in RPR+ mode?
		>Is IETF a GR? vs Cisco a SSO?

		There should be no difference in length of outage if
both these modes 
		are functioning properly.
		IETF is GR mode, ie RFC3847.   "Cisco" mode is a
"Non-Stop Routing" mode
		that doesnt require
		interaction with the peer to recover from the processor
failure due to 
		the transfer of all state information to the standby.

		A "RPR+" like delay could be that the peer to the
switching over router
		doesnt have helper capability.

		Thanks,
		Ken Weissner

		_______________________________________________ 
		cisco-nsp mailing list  cisco-nsp at puck.nether.net
		https://puck.nether.net/mailman/listinfo/cisco-nsp
		archive at http://puck.nether.net/pipermail/cisco-nsp/ 