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

Rodney Dunn rodunn at cisco.com
Sun Jul 10 23:10:08 EDT 2005


On Tue, Jul 05, 2005 at 05:04:17PM -0400, FILYURIN, YAN wrote:
> Also can you give an example of when you say:
> "
> 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.
> "
> 
> Support of course is a problem, but this is about a 1 month solution.
> So with CEF it would not work if n2 and mask2 would be 0.0.0.0? 

Today you can't enter a static route that points at a nexthop network
and mask combination but only a nexthop. The problem comes with
the collision between 0.0.0.0/32 which is treated as a receive fib
entry vs. the next hop of 0.0.0.0 for recursion. Today CEF does
not support that.

>  
> 
> Thanks
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of FILYURIN, YAN
> Sent: Tuesday, July 05, 2005 9:33 AM
> To: Rodney Dunn
> Cc: cisco-nsp at puck.nether.net
> Subject: RE: [c-nsp] Static routes on frame relay interfaces pointing to
> interface and next hop
> 
> Can you elaborate on C a little bit more, possibly with an example? 
> 
> -----Original Message-----
> From: Rodney Dunn [mailto:rodunn at cisco.com]
> Sent: Thursday, June 30, 2005 3:50 PM
> To: FILYURIN, YAN
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Static routes on frame relay interfaces pointing to
> interface and next hop
> 
> 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/
> 
> 
> _______________________________________________
> 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