[c-nsp] Static routes on frame relay interfaces pointing to interface and next hop

[Rodney Dunn]

I'll admit I didn't spend the time needed to understand fully
how and where all these routing protocols are running.
If someone tells me they are running more than 2 I usually
say they need some redesign.  But anyway...


Two things:

For FR PVCs you have a couple options to trigger failure and
routing reconvergence:

a) end to end LMI
b) Frame-relay keepalives
c) static routes with object tracking
d) routing protocol over the links

 

On Thu, Jun 30, 2005 at 03:19:18PM -0400, FILYURIN, YAN wrote:
> Hello and thank you in advance for reading my email  I was wondering if
> it is possible to do a static route and point that static route to
> 0.0.0.0 address and here is how I came to this question:  I have a set
> up where I have an a remote site and two remote site routers each having
> two frame relay connections and a PVC on each connection going to a
> central site device.  The devices at the central site summarize a
> 0.0.0.0/0 route to the remote site.  The remote site runs OSPF and
> another similar set up I have is BGP.  I can certainly advertise OSPF
> into EIGRP and can originate a default in OSPF, but the OSPF AS in the
> remote sites already has a default route which can't be touched (in
> fact, I have a distributed list for OSPF that blocks it), so I need to
> create a bunch of specific static routes on the remote site routers and
> redistribute them into OSPF.  My other requirement is that I can't touch
> the central site routers.  So my question is, how could I make it
> perfectly dynamic to take advantage of all that redundancy?  Here is my
> thought process so far (all routers are 12.2.15(T5) and CEF is enabled
> with default settings)
> 
> 1)I can create static routes on the remote site router pointing the
> frame relay subinterface and redistribute them into OSPF.  I would
> create 2 sets of static routes on each remote site router for each frame
> relay subinterfance.  The problem is that in certain case when a frame
> relay interface goes down like when the PVC goes bad, the interface will
> not go down and the static routes will still stay blackholing the
> traffic.

(b) above would fix this.

> 
> 2)I can do the same as above and point the static routes to both of the
> subinterfaces and the next hop IP address.  In theory it should work but
> I am not 100 % sure if the route would withdraw if the something at the
> frame relay level will go down (the interface will still stay up/up).
> It would work great on regular HDLC or PPP,  I am sure.

You never need (although I recommend it) an interface and next hop in a static
route at a P2P interface type. I never point a static route at an interface
unless it's doing ip unnumbered.

> 
> 3)Based on the above Cisco would remove static route if the next hop
> address would not be available through the interface and at this time
> all interfaces are learning the 0/0 through EIGRP and then I've heard
> that you can point a static route to 0 address.  I've never seen it
> documented or shown anywhere, so what better place to ask then this
> list.  What I would get out of it that I would get special recursion
> where first I would have something point to 0.0.0.0 and then this
> 0.0.0.0 would be inspected and found as EIGRP route and that in turn
> would be sent to the next hop address on the right interfaces be it
> either of the frame relay interfaces or a crossover cable between two
> router FastE interfaces and I would get the redundancy.  I could even
> avoid using the interface in my ip route command.

No. You can not do this. It's a long story. It will work with fastswitching
but no with CEF because of the way cef handles the 0.0.0.0/32 entry.

The solution would be to have the ability to do recursion like this:
ip route <n1> <mask1> <n2> <mask2> 
but we do not support this.

> Does it sound reasonable, or am I just making this stuff up? 
> 
> Thank you and let me know if you need more details. 
> 
> 
> Yan Filyurin
> Electronic Data Systems, Bank of America Account Network Design and
> Fleet WAN Transformation
> Phone:  781-788-2207 
> Cell:       617-875-4862 
> Yan.Filyurin at bankofamerica.com
> Yan.Filyurin at eds.com 
> 
> 
> _______________________________________________
> 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/