[c-nsp] Reaction to forwarding failure...

rwcrowe at comcast.net rwcrowe at comcast.net
Thu Oct 7 10:59:51 EDT 2004


Very nice.

--
Rob Crowe 
rwcrowe at comcast.net

-------------- Original message -------------- 

> We are going to create a new track object that the 
> higher layer protocols can hook on to as the singal. 
> That way HSRP could failover and the routing 
> protocols could listen to the notification and just 
> make the interfaces passive to the routing protocol. 
> 
> CSCef21445 
> Externally found enhancement defect: New (N) 
> Request for a new tracking object to monitor for CEF disable event 
> 
> While I haven't tried this yet I think you could 
> do the same thing already with EEM and watch the syslog for 
> the FIBDISABLE message and then just either shut down 
> the BGP peers or make the interfaces for the IGP passive. 
> 
> http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide091 
> 86a00801d2d26.html 
> http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_guide091 
> 86a008025951e.html 
> 
> EEM with the TCL scripting has the capability to be flexible 
> for a lot of scenarios like this as well as troubleshooting. 
> 
> It's pretty new. 
> 
> Rodney 
> 
> On Wed, Sep 15, 2004 at 06:08:19PM +0000, rwcrowe at comcast.net wrote: 
> > I for one would love this feature. I see alot of designs where L3A and L3B are 
> setup as you have shown or they are dual-homed to CoreA and CoreB. But as you 
> said if a PFC or some forwarding engine fails you are stuck with process 
> switching and your performance goes into the toilet. 
> > 
> > 
> > -- 
> > rwcrowe at comcast.net 
> > 
> > 
> > -------------- Original message -------------- 
> > 
> > > I had an idea and wondered how common this would 
> > > be and how much customers would like it. 
> > > 
> > > The idea is how to react on a known failure 
> > > type for a redundant design. 
> > > 
> > > Let's say you have this: 
> > > 
> > > COREA COREB 
> > > | | 
> > > L3A L3B 
> > > | | (HSRP) 
> > > Access layer switches 
> > > 
> > > 
> > > 
> > > Pretty typical design if you are not doing L3 all the way to 
> > > the access. Now let's say you have some form of hardware 
> > > forwarding failure on the L3A (l3 switch) switch. With the 
> > > failure there is a chance you punt the packet to process 
> > > level and overrun the CPU. Assume L3A is HSRP primary. 
> > > 
> > > What about if there were a configurable option that for 
> > > known failure conditions you could have all routing 
> > > disabled for the routing protocols and also have HSRP 
> > > disable itself? That way you would failover to the 
> > > redundant path both ingress/egress to the core. 
> > > 
> > > Clearly this doesn't apply to all designs. If you only 
> > > have a single path you would want that path to continue 
> > > to pass the traffic that it can. You could still reach 
> > > L3A from COREA by telnetting to the directly connected 
> > > ip address. 
> > > 
> > > Thoughts? 
> > > 
> > > Rodney 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > _______________________________________________ 
> > > 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