[c-nsp] SSO on 65 support mcast?

[Tim Stevenson]

At 07:28 AM 9/29/2005, christian.macnevin at uk.bnpparibas.com pronounced:

>Ok, this from 
>http://www.cisco.com/en/US/customer/products/hw/switches/ps708/products_white_paper0900aecd801c5cd7.shtml 
>:
>
>  "MMLS NSF with SSO enables the system to maintain multicast 
> forwarding state in the PFC3 and DFC3 hardware during a 
> supervisor-engine switchover, minimizing multicast service 
> interruption. Prior to MMLS NSF with SSO, the multicast forwarding 
> entries were not synchronized to the standby supervisor engine. The 
> NSF with SSO switchover time is 0 to 3 seconds for Layer 2-4 
> unicast or multicast traffic."
>
>The 'maintain multicast forwarding state' makes it sound like it's 
>normal NSF, with 0 to 3 seconds before the table's recalculated and 
>verified by the new master. Is my understanding flawed here? And if 
>so, then what failover time am I expecting with PIM-SM and IGMPv2 on 
>default timers?

So the 1st problem is the general confusion around the 2 terms, "NSF" 
and "SSO". Ask 10 different people what they are and you'll end up 
with 10 different definitions.

My answer is platform specific, ie, 6500, cuz I don't know the 
details of all the other platforms: SSO is the act of maintaining the 
critical hardware fwding information across a sup switchover. So FIB, 
ADJ, L2 tables, ACL/QoS TCAM, etc. (ie, most everything in the 
PFC/DFCs). In 6500, this also includes some s/w data structures as 
well (various software copies of tables). Most of what we do there is 
a function of what IOS does generically.

NSF on the other hand (again, IMO) refers to the "graceful restart" 
capabilities in the routing protocols. So the ability to inform your 
routing peers that a s/o happened so don't tear down the old 
adjacency and please update me ASAP with all the latest & greatest info.

So for multicast, we have SSO per the above definition, but not NSF 
(there is no specific new interbox communication here, we just rely 
on all the usual periodic stuff like PIM hellos, joins/prunes, IGMP 
joins/leaves, etc to rebuild state). All the multicast FIB & ADJ & 
MET & snooping stuff is kept in the h/w & we keep on fwding using that.

But at the s/w level, the state is pretty much completely recreated 
from scratch. That's the holdtime that I mentioned - the time we wait 
to make sure mcast state is fully restored. Then we start refreshing 
the h/w fwding entries.

But the failover time is still 0-3 seconds, same as unicast.


>Also, if you're aware, what's the likely difference between this and 
>the 3750's implementation of NSF? I realise that's only capable of 
>RPR+, meaning any routing updates should be ignored for 30-60 
>seconds, but does it (also?) experience outage with the mcast 
>forwarding table?


So I don't know much about this platform (well I know more than I let 
on but I don't like to pretend to be an authority here... ;), but a 
quick google search turns up this phrase, "NSF awareness", and that 
is code for - "capable of 'refreshing' another NSF router with the 
latest & greatest info (as above), but NOT having redundant sups or 
processors where you can do a stateful switchover and maintain fwding 
after the failure." To put it another way, the RPs are graceful 
restart aware so if a 6500 or other router signals a NSF/SSO 
switchover, the 3750 can update the new sup w/the latest info. Which 
is something not every router can do.

HTH,
Tim



>Thanks (hopefully)
>Christian
>
>
>
>
>Internet
>tstevens at cisco.com
>
>28/09/2005 21:27
>To
>Christian MACNEVIN, cisco-nsp
>cc
>Subject
>Re: [c-nsp] SSO on 65 support mcast?
>
>
>
>
>Multicast is supported for SSO in 18SXD and later. It is a "single
>box" solution - NOT like NSF for unicast. There are no triggered PIM
>joins or other interbox facilities associated with it. Also, there is
>a "hold time" after the switchover where any new multicast streams
>will be switched by software not hardware (existing streams continue
>getting h/w switching, and host joins/leaves are still processed via
>igmp snooping).
>
>The feature name is "MMLS NSF/SSO". Don't let the "NSF" part fool you
>though, per the above.
>
>Tim
>
>At 02:21 AM 9/28/2005, christian.macnevin at uk.bnpparibas.com pronounced:
> >Hi,
> >Is anyone aware of a feature support matrix for SSO on the 6500? The
> >reason I ask is that I was forced to use RPR+ to support MPLS switchover
> >roughly a year ago, so I'm not sure how fully implemented the feature is.
> >It's multicast I'm worried about this time round.
> >Cheers
> >Christian.
> >
> >This message and any attachments (the "message") is
> >intended solely for the addressees and is confidential.
> >If you receive this message in error, please delete it and
> >immediately notify the sender. Any use not in accord with
> >its purpose, any dissemination or disclosure, either whole
> >or partial, is prohibited except formal approval. The internet
> >can not guarantee the integrity of this message.
> >BNP PARIBAS (and its subsidiaries) shall (will) not
> >therefore be liable for the message if modified.
> >
> >******************************************************************* 
> ***************************
> >
> >BNP Paribas Private Bank London Branch is authorised
> >by CECEI & AMF and is regulated by the Financial Services
> >Authority for the conduct of its investment business in the
> >United Kingdom.
> >
> >BNP Paribas Securities Services London Branch is authorised
> >by CECEI & AMF and is regulated by the Financial Services
> >Authority for the conduct of its investment business in the
> >United Kingdom.
> >
> >BNP Paribas Fund Services UK Limited is authorised and
> >regulated by the Financial Services Authority.
> >
> >_______________________________________________
> >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/
>
>
>
>Tim Stevenson, tstevens at cisco.com
>Routing & Switching CCIE #5561
>Technical Marketing Engineer, Catalyst 6500
>Cisco Systems, http://www.cisco.com
>IP Phone: 408-526-6759
>********************************************************
>The contents of this message may be *Cisco Confidential*
>and are intended for the specified recipients only.
>
>
>
>This message and any attachments (the "message") is
>intended solely for the addressees and is confidential.
>If you receive this message in error, please delete it and
>immediately notify the sender. Any use not in accord with
>its purpose, any dissemination or disclosure, either whole
>or partial, is prohibited except formal approval. The internet
>can not guarantee the integrity of this message.
>BNP PARIBAS (and its subsidiaries) shall (will) not
>therefore be liable for the message if modified.
>
>**********************************************************************************************
>
>BNP Paribas Private Bank London Branch is authorised
>by CECEI & AMF and is regulated by the Financial Services
>Authority for the conduct of its investment business in the
>United Kingdom.
>
>BNP Paribas Securities Services London Branch is authorised
>by CECEI & AMF and is regulated by the Financial Services
>Authority for the conduct of its investment business in the
>United Kingdom.
>
>BNP Paribas Fund Services UK Limited is authorised and
>regulated by the Financial Services Authority.



Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Catalyst 6500
Cisco Systems, http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.