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

Atif Sid guru6111 at gmail.com
Tue Jan 15 11:26:12 EST 2008


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 :
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
[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/
> >
>
>


More information about the cisco-nsp mailing list