On our main MPLS network at work we do nothing but static routes to send out all our traffic. Which sometimes is nice, but sometimes not having the control is not so nice. We have a backup frame relay network at the moment that sits idle unless hsrp kicks in and makes the frame relay routers the main exit point of the network. I have hsrp monitoring the multilink interfaces of the MPLS routers at our corporate office and our spoke offices. Now my issue has always been if something were to go down in the isp cloud and not affect the interface status hsrp would never kick in to forward the packets out of the backup router. Why would it right? It would see the multilink interface still showing up/up. Also since there is no dynamic routing protocol to take the route out of the routing table it seemed I was stuck just monitoring the multilink interface.

So I got the bright idea to create multiple tunnel interfaces with our hub router and all the spokes. I was thinking hey I finally put some of my CCIE studies to good use here! So I configured 6 tunnel links and was cheerfully setting hsrp to monitor the tunnel interface on the spoke routers. No matter if the link went down on our end or in the ISP cloud the tunnel would drop and hsrp would send the traffic out the backup network.

As long as the main router doesn’t know to send traffic out of the backup network the tunnel interface should stay down. Since all the spokes iniate all the remote traffic and traffic will be sent out the path from which it came this should not be an issue really.

***Update***

Well this idea is not going to work the way I have it configured. I noticed the tunnel interfaces I was creating were coming right up to a up/up state. So I configured a quick test tunnel on a spoke router with the destination address set to a non-exsistant ip address on our network.

Tunnel2 unassigned YES manual up up

As you can see it is still showing up/up even though the destination doesn’t exsist. So the tunnel thinks it can get out no matter what the destination ip address is. Then I found this on the Doc CD:

“It is not possible to use the HSRP configuration to track the GRE tunnel interface. However, the tunnel interface never goes down and the track never triggers failover.”

Looks like I am going to have to read into standby tracking object “#”. Just wondering if I can create a tracking group to the end ip address of the tunnel…

***Update part 2***

Well I am able to use an enhance object tracker to accomplish this

track 1 ip route 10.1.20.0/24 reachability
standby 1 track 1 decrement 50

What I did was create the tunnel interfaces on both ends

Enable EIGRP and enable the process on the tunnel ip addresses

Then I created a loopback interface and advertised that into EIGRP

Now I can track the route so if the main interface would drop the tunnel would still show up/up but would drop its EIGRP adjacency which would drop the route.

The question is do I want to do all this? I can always just track the multilink interface and if something ever went down in the isp cloud I would just vpn in and down the interface manually.

Enhanced Object Tracking

***Last Update***

I just got an email from Mike Litka which helped a ton and will make this easier.

“…Once keepalives are enabled on the interface they will report down if the other end is unreachable.

int t0
  keepalive 

Let me know if that helps..."

Jun 10 17:35:51.043: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down

Good show!

Comments

5 Responses to “HSRP and You Johnny!”

  1. HSRP and You Johnny Update | CCIE Journey on July 16th, 2008 9:22 am

    […] anyone remembers my original post on our HSRP setup I wasn’t able to fully test it at that time. Well last night the routing in our MPLS […]

  2. andrew teslicko on February 24th, 2009 2:21 pm

    why not just put keep alives on the serial interface then ?? Because it is technically just monitoring the PE switch??

  3. CCIE Journey on February 24th, 2009 2:38 pm

    It got to the point where I just enabled and configured BGP for the MPLS links so if the connection dropped between the two everything was automatic.

  4. andrew teslicko on February 24th, 2009 2:44 pm

    but then there is also by default a 60 and 180 hold down time etc. which can be adjusted in conjunction with your provider..but even adjusted down to 12 and 36 ..you are still looking at the other end of the failure not knowing of the failure and black hole routing…for anywer from 25-36 seconds…not good for telnet sessions etc. So I have been considering the GRE tunneling but did not have the “keep alive” peice of the puzzle..i thought that eigrp would just use it’s own two second keepalives.

  5. Jack on June 18th, 2010 7:36 pm

    Augment your igp peering with BFD and your topology changes will be detected much faster. Then, point HSRP at your route tracking object like you stated above. IIRC, GRE keeps aren’t applicable to multipoint GRE tunnels because missing a keepalive on the MP interface would be death to the cloud.

Leave a Reply