Routing to Vendor network and tracking interface failure

Unanswered Question
Mar 24th, 2009

Please see attached diagram for more details.


You have a connection to vendor/business partner. You have two connections to this business partner. You are runing EIGRP on your internal network and with your routers and core switches. You don't know and don't care what IGP's the vendor is running. They are most likely doing statics. The vendor has two circuits from their routers to their network. If one of the vendors circuits goes down their equipment will failover to using their seconday circuit and equipment.

NOW the BIG question:

How can you configure your company primary router to notice when the vendor primary fails over and instruct your secondary router to take over as the primary path to the vendor network. Your company routers are using HSRP over a L2 link and the primary has static routes pointing to the failover ASA HSRP address of the Vendors ASAs.

I think you will have to do some sort of interface tracking, but not 100% sure.



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
lamav Tue, 03/24/2009 - 06:56

His ASA HSRP VIP address and your router's HSRP VIP address should be on the same subnet and you should be pointing your outbound traffic to his VIP address, and the vendor should be pointing his outbound traffic to your HSRP VIP. This way it doesnt matter which one of his routers is active.

It's either that, or you use BGP peering with the vendor to withdraw routes and do things dynamically.



mbroberson1 Tue, 03/24/2009 - 07:16

Hi Victor,

This is the case with the addressing. His ASA HSRP VIP is on the same subnet as my router's HSRP address. We are pointing outbound traffic with static rotues to his VIP address. The same case is for the vendor. Can you kindly give a brief config example of what this would look like from the company primary and secondary routers? Would I use floating statics on the secondary? If not what would you suggest?

Kind Regards,


lamav Tue, 03/24/2009 - 07:27

Hey, brandon:

Im a bit confused. It seems like this set up is already in place, but then you ask about what the configs on your routers should look like....

Anyway, yes, you're right. A static on primary and a floating static on the secondary, both redistributed back to your core.

mbroberson1 Tue, 03/24/2009 - 07:29

Hi Lamav,

This is way it is setup, but when the vendor test failover it doesn't seem to work. Perhaps I need to re-check the HSRP config on the routers. I'll see about posting the HSRP congigs.


lamav Tue, 03/24/2009 - 07:50

Yes, well, thats exactly the point. If you're pointing traffic to the vendor's HSRP VIP, why would you care about anything happening on the vendor side? The vendor's failover will be transparent to you.

That goes back to what I was saying about tracking. What does tracking buy you? No matter what, the address you send traffic to will never change.

mbroberson1 Tue, 03/24/2009 - 07:59

So on the HSRP tracking my question is from a routing table topology perspective how does the path in the routing table know to change from primary to secondary if a failover happens on the vendor side. The statics will still be redistributed into the table from the primary, but how does when the failover occurs does the secondary router install the routes and start using the floating statics? I hope I am making sense.



lamav Tue, 03/24/2009 - 08:56


Maybe I am missing something....

If the vendor fails over to a secondary path, why should you want to change the route that your company takes to get to them?

If you're forwarding traffic to their ASA's VIP (by the way, before I was typing "ASA HSRP VIP" by mistake - ASAs do not run HSRP. I meant its failover VIP), then that should be enough. Whichever ASA is processing the incoming traffic will forward it accordingly within the vendor's domain.

Am I not understanding something?

Is the vendor telling you that you MUST failover to your secondary router if they failover to their secondary ASA for stateful connection purposes?

mbroberson1 Tue, 03/24/2009 - 09:03

Hi Lamav,

I think you pretty much have the understanding. What I am not understanding is on the secondary router if I am using floating statics to the vendor ASA VIP address, how will that secondary router (and most importantly network traffic on the company side) know to use the secondary router path to reach the vendor network(s)?



lamav Tue, 03/24/2009 - 09:15


Lets walk through this step by step.

R1 advertises a static route to the vendor network back to the company's core.

All router's in the eigrp routing domain will receive that route.

R2 will redistribute a comparable static route to the vendor's network, but with an AD of 220.

All routers in the eigrp domain will receive that route, but will NOT place it in the routing table because R1's static has a lower AD.

If R1 fails, or R1's vendor-facing interface fails or goes "down," it will lose its next hop to the vendor network.

R1 will then withdraw the route from its routing table and NOT redistirbute it back to the core. Therefore, the only route left to the vendor network is R2s route, and therefore, company traffic will be forwarded to R2.

Keep in mind that the ONLY time your company would need to forward traffic to R2 is if R1s route to the vendor ceases to exist, otherwise there is no reason why R1 should have a healthy route to the vendor, but nonetheless force a failover to R2.

mbroberson1 Tue, 03/24/2009 - 10:24

I think I am starting understanding this now?

So for the configuration you have seen our "the company side" looks like it is already setup properly?



mbroberson1 Tue, 03/24/2009 - 10:41

So the interface on the primary company router will have to do down/down or can it be up/down in order for the healthy routes advertised by the primary to go away from the table forcing the floating statics from the secondary to be injected?



lamav Tue, 03/24/2009 - 10:44


Once the exit interface, and therefore the next hop, for a route is no longer available (up/down, down/down), the route is removed from the routing table.

mbroberson1 Tue, 03/24/2009 - 11:35

This may be the question I was looking to have answered that started this post?

So even though the company primary router (outside interface) is connected to a switch it will still be able to go up/down or down/down when a failover on the vendor side occurs?

I think this is the question/answer I am after?



lamav Tue, 03/24/2009 - 07:57

HSRP configs look fine. Show me the statics and the routing protocol configs.

Also, when the vendor tests failover, exactly what does he fail to create the failover?

mbroberson1 Tue, 03/24/2009 - 08:21

Hi Lamav,

Please see attached.

when the vendor fails over they will usually failover their ASA form ther primary to ther secondary causing traffic to go over their secondary equipment and circuit.



lamav Tue, 03/24/2009 - 08:45

"when the vendor fails over they will usually failover their ASA form ther primary to ther secondary causing traffic to go over their secondary equipment and circuit."

And this is supposed to effect you, how?

Make sure the vendor is pointing to your HSRP VIP.

lamav Tue, 03/24/2009 - 07:03

"You can create an IP SLA to track reachability via ICMP to the vendor's circuit."

I seriously doubt that the vendor is going to allow him to PING his ASA to death. Most likely that ASA will be blocking all ICMP.

Edison Ortiz Tue, 03/24/2009 - 07:06


We are not pinging the ASA, we are pinging the vendor's router WAN interface.



lamav Tue, 03/24/2009 - 07:08

Understood. But I doubt the vendor is going to allow PINGs through his ASA. If so, that'll be a first for me.

mbroberson1 Tue, 03/24/2009 - 07:08

Hi Edison,

Could you kindly give a config example of what this would look like on both the company primay and company secondary routers?



Edison Ortiz Tue, 03/24/2009 - 07:18


Per your requirements, it seems they want you to draw traffic to your secondary router from your LAN segment and currently they are using HSRP to do that.

Your primary router is the active HSRP router so you need to decrement its value based on a tracked event.

The only router that needs to be modified will be your company primary router.

Note.- I don't have any equipment at the moment, this was taken from the documentation:

1) Create a tracked object:

ip sla monitor 1

type icmp-echo dest-ipaddr [wan-circuit-ip]

ip sla monitor schedule 1 start now life forever

(More information at:

2) Associate the track to the HSRP config:

standby 1 preempt

standby 1 priority 105

standby 1 track 1 decrement 10

On the secondary router, make sure you have:

standby 1 preempt




mbroberson1 Tue, 03/24/2009 - 07:23

Hi Edison,

So the [wan-circuit-ip] would be the address of the vendor primary's "far-remote-side", or the local side?



Edison Ortiz Tue, 03/24/2009 - 07:33

Good question. It's up to you how far out you want the ICMP packet to travel. Keep in mind to modify the timeout and frequency within the SLA monitor and try not to be too aggressive on those parameters.

Edison Ortiz Wed, 03/25/2009 - 06:20

VRRP and HSRP have the same features.

The main difference between HSRP and VRRP is that HSRP is Cisco proprietary while VRRP is industry standards.



Edison Ortiz Wed, 03/25/2009 - 06:47

See if this would be a valid configuration?

No, it's not.

If the interface goes down, HSRP will give control to another HSRP router. The track command has no usability there.



mbroberson1 Wed, 03/25/2009 - 06:59

Hi Edison,

Then if the internals on each router is on a different subnet and you wanted to use the HSRP way what best method would you propose? Something other than the IP SLA method.



Edison Ortiz Wed, 03/25/2009 - 07:15


Honestly, I lost track of what was said on this thread.

A quick read on this thread shows that we don't have an exact set of requirements from you and we are grasping at straws.

My suggestion; bring someone on-site that sits with you and customer one-on-one to come up with the proper solution|implementation for your network.

Forums are useful when you need to reaffirm your design. Also if you have a set of requirements *and* understanding about your network.

With all due respect, I don't think you have that and I'm afraid to suggest anything here that ultimately may affect your network.




This Discussion