[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