Something else I just recently came across release notes from SXI2 (might be in other release notes as well with differing information) in regard to BFD and SSO:
When evaluating BFD SSO for the network, the customer should note the following considerations. . Cisco Catalyst 6500 series switches typically support upto 128 BFD sessions with hello interval of 50ms or higher and multiplier of 3 or higher. When configured with dual sups in SSO mode, the number of sessions supported is 50 with timers of 500ms or higher and multiplier of 3 or higher. This scale ensures that BFD Sessions don't flap during the time it takes for the system to failover to the secondary supervisor. . BFD SSO is supported on Cisco Catalyst 6500 Series E-chassis and 67xx Line Cards only. Centralized Forwarding Cards (CFC) are not supported. . During the ISSU cycle the line Cards are reset which causes a routing flap in the BFD session. . For EIGRP, the number of BFD sessions supported under BFD SSO is reduced to 30. Vinny Abello Network Engineer Dell | Physician Services office +1 973 940 6125 mobile +1 973 868 0610 [email protected] -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Justin Krejci Sent: Monday, November 01, 2010 1:11 PM To: Phil Mayers Cc: [email protected] Subject: Re: [c-nsp] Best practices for Cat6500 With regards to SSO-NSF and HSRP I've read documents on ciscos site that conflict when discussing the use of NSF. One indicates do not use HSRP and NSF together on the same box. http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fsnsf20s.html#wp1467 556 http://www.cisco.com/en/US/customer/docs/switches/lan/catalyst6500/ios/12.2S X/configuration/guide/nsfsso.html#wp1112624 I've read in another article (sorry, don't have the URL handy at the moment but I think I saw in a PDF from cisco.com) that either implied the use of NSF and HSRP together was OK thru config examples or something or else explicitly stated the use of the to together is OK. Can anyone comment on this conflict? Also does this conflict with NSF also apply to GLBP which can be configured in a way to behave similar to that of HSRP? The second link above makes comment of GLBP but the first one does not. Is GLBP newer than the first article? Thanks. On Mon, 2010-11-01 at 11:59 +0000, Phil Mayers wrote: > On 01/11/10 10:00, Robert Hass wrote: > > > > 1) mls rate-limit > > > > My current configuration only consist few rate-limiters: > > > > mls rate-limit unicast ip rpf-failure 300 30 > > mls rate-limit unicast ip icmp unreachable no-route 300 30 > > mls rate-limit unicast ip icmp unreachable acl-drop 300 30 > > mls rate-limit unicast ip errors 300 30 > > > > Should I consider to configure more mls rate-limiters ? > > Search the archives for truly extensive discussion on these issues. > > Suffice to say that some of the more useful looking rate-limiters > (glean, receive) have gotchas either in terms of bugs in certain > hardware (glean limiter subject to output ACL of input interface on some > PFC/DFC versions) or just sub-optimal behaviour. > > We use these, in addition to what you've got, which I believe to be > relatively safe: > > mls rate-limit all ttl-failure 100 10 > mls rate-limit all mtu-failure 100 10 > > > > > > I would like to implement 'mls rate-limit layer2 pdu'. How I can check > > how many layer2 pdu packets are coming to RP ? And SNMP Oid or CLI > > command to show this ? > > Personally I would avoid that, and instead ensure layer2 PDUs are > filtered on untrusted ports. > > > 3) Automatic BGP refresh > > > > When I change something in route-map for inbound BGP prefixes I > > noticed that Cat6500 automatically refresh inbound BGP router > > (automatically doing something like clear ip bgp x.x.x.x in). Is is > > new feature in SXI4a ? > > Really? Are you sure? > > > > > 4) NetFlow only for packets going to RP/SP > > > > Is any way to export NetFlow (v5 or v9) information for packets coming > > to RP/SP only ? I would like to check whats coming to software > > switching by RP/SP for develop control-plane policing are decrease CPU > > usage for eg. ICMP traffic. > > Not sure about that, but you can use SPAN to monitor the SP/RP: > > mon sess 1 type ... > source cpu rp > source cpu sp > > ...etc. > > > > > 5) Supervisor Redundancy > > > > I would like to add redundant Sup720. Is IOS automatically will switch > > to second Supervisor when primary : > > a) Will crash (software error/bug) > > b) Will fail (hardware failure) > > Not automatically - you need to configure it: > > redundancy > main-cpu > auto-sync running-config > mode sso > > When configured, it is supposed to protect against many failures. It > works most of the time; however in early versions of SXI we saw a couple > of crashes where the primary sup crashed, and the SSO caused the > secondary to crash, dropping both to ROMMON :o( > > But we have also seen successful SSO. > > Beware: SSO alone might not be sufficient. You might need NSF, and > routing neighbours (e.g. BGP, OSPF) that support NSF, in order to > recover "instantly". > > > > > In my configuration I'm using old classic bus cards (3 x WS-X6408A-GBIC). > > I'm not sure if SSO supports classic bus cards; read the docs. > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
