1. Home
  2. Cisco Systems
  3. TCL scripting or "dialer-watch" equivalent for GRE tunnels?

TCL scripting or "dialer-watch" equivalent for GRE tunnels?

I've been fighting the crux of this problem for months, but I'll try to keep it short here. I need some advice.

I have an MPLS network through my provider with about 20 sites. We are fully meshed. Most sites have a 2811 router and our routing protocol is OSPF. I cannot use EIGRP with my provider, which is a shame, because I think it would solve all my problems.

I've installed a second router at some of my remote MPLS sites that have their own Internet connection. I want to use a GRE/IPSEC (or DMVPN) tunnel to backup the MPLS network with a tunnel back to Corporate. I have the tunnel interface Shutdown at the moment, and manually bring it up when there is an MPLS outage, because.......

If I leave the tunnel up, OSPF works through it as designed. However,

*NO* amount of playing with the metrics nor the TAC can help me with this problem.

When the tunnel and MPLS are both up, some routes simply prefer the tunnel over the MPLS link. I want my MPLS T1 to be preferred in all cases unless it is down. Because the tunnel connects directly to my datacenter, and depending on whether the OSPF routes are external, intra-area or inter-area, some routes always see the tunnel as closer.

After weeks of working on it with the TAC, I've decided to pursue a different tactic. What if I just leave the tunnel interface shutdown until such a time when my MPLS circuit dies and automate it to come up? Is this possible? I'm okay with a few seconds of outage to bring up the tunnel.

Dialer-watch does not work with tunnel interfaces. So I was wondering if I could make use of the TCL scripting language, or some other such new 12.3/12.4 feature that behaves in the same way.

Question: Is there a way to make an IOS router check for the presence of a route learned from another local router in OSPF, and when it is missing, change the status of an interface from shutdown to 'no shutdown'? And of course, put it back to 'shutdown' when the route comes back after being advertised by the MPLS router?

-Robert

Reply to
Robert
Loading thread data ...

You're looking for EEM, I believe.

Aaron

Reply to
Aaron Leonard

EEM. Yes, that's it. I read about it in Packet Magazine awhile ago but couldn't remember the name of it.

Thanks. Robert

Reply to
Robert

Not the answer to your problem, but the reason the GRE tunnel is preferred is because the routes on it are INTERNAL routes, and the ones coming from your provider are flagged as EXTERNAL. Even though your provider is talking OSPF to you, they use BGP on their MPLS network. Your routes go from OSPF to BGP and then back to OSPF. When they go back to OSPF they are no longer OSPF internal routes, but external ones. We are an EIGRP shop and run BGP directly with the carrier (this way we are able to directly control the redistribution of routes between BGP and EIGRP instead of the carrier.) We had a similar problem with dialbackup (we use ISDN instead of GRE tunnel over the internet) and after the ISDN came up it would stay up because we ran EIGRP over the ISDN. After it came up the ISDN would be the preferred route and used for all traffic and the ISDN idle timer never kicked in. We resolved this by using a different routing process for EIGRP on the ISDN dialbackup routers and then redistributed between the two EIGRP processes. This made the routes from the MPLS network (BGP) and ISDN all external routes, plus playing with the metrics on the EIGRP to EIGRP redistribution on the ISDN dial-in routers to make the MPLS network routes preferred.

Reply to
Thrill5

I thought about this too, and that is the problem for 90% of my routes. Since the GRE tunnel connects directly to the datacenter, I do have some internal (datacenter) routes that are still preferred over the tunnel - metrics notwithstanding. I have some External routes in both directions that don't seem to follow any rhyme or reason.

I could see if its possible if my provider could advertise all my OSPF (BGP) routes as internal, but there is a chance that wouldn't completely fix it. The idea of using EEM (or another routing protocol solely over the Tunnel) sounds like the quickest fix.

Robert

Reply to
Robert

If provider is indeed doing BGPOSPF redistribution, nothing they can do to make routes internal. Running different OSPF process or different IGP on tunnel interfaces is pretty much the only solution (in some cases you can get away with sending summary routes over GRE, not with 20 sites though).

Regards, Andrey.

Reply to
Andrey Tarasov

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.