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

[FILYURIN, YAN]

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/