cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
20083
Views
5
Helpful
19
Replies

Two static routes to same destination in routing table possible?

ssajiby2k
Level 1
Level 1

I know about floating static routes and how they works.

 

I want to have default or static route to same destination over two different interfaces towards different gateway. One will be active and other will be passive. But both needs to be in routing table.

 

Floating routes does not work because route with higher admin distance does not inserted into routing table.

 

I am using another non Cisco product when I can configure two static routes to same destination but with different priorities. Because admin distance is same, both routes come into routing table, but only one is used which has lower priority value.

 

Does Cisco have something similar?

Not looking for any solution through policy routing.

 

For example remote end has two internet connection. That remote side runs ipsec tunnel mode towards a central side which has one  public IP address. Remote take two default route from ISP. But remote will connect to same public IP of central side. Then without both routes to central ip through different interfaces in remote router routing table, I cannot even start ipsec negotiation.

 

Regards,

19 Replies 19

Hi,

 

Many thanks for your reply.

More example,

 

Two default routes from two internet facing interface. The backup internet line is using default route with higher admin distance so not in routing table.

 

Now try a ping to 8.8.8.8 sourced from backup interface ip. What Cisco router will do,

Internally switch that packet from backup interface to primary interface and exit out. Asymmetric routing even though there is default route out through backup line.

 

From home you want to reach the backup line ip. Traffic enters through backup line interface, but reply exit through primary interface, as there is not default route through backup interface entered into routing table.

 

This is my problem at least for traffic to or from router own ip adress which is backup.

 

I want to achieve traffic addressed to router own ip in backup line enters and exit same interface, not through that primary interface.

 

Regards.

 

 

Ah, so you're saying, on these other brand routers, traffic that enters on the WAN link, pinging router's WAN interface's IP, will, because of "secondary" (default) route (on these routers) be sent back out the secondary WAN interface? Does this also apply to traffic entering this router from other interfaces, or only on the WAN link? Also, how does the Internet know of the router's WAN facing IP, and/or other internal IPs via the "backup" path? I.e. are both links used, for ingress traffic, all the time? If so, wouldn't some traffic be asymmetrical returning to the Internet?

If the only issue was pings to the WAN router's WAN interface's IP, coming in on the WAN link, PBR, might deal with that. Of course, for traffic targeted further "inside", the problem expands, but possibly so does "asymmetrical" routing issues. And, on the subject of "asymmetrical" routing, could you clarify why that's a problem, in this case, or that Cisco's approach is asymmetrical (i.e. if traffic enter/leaves via primary path, it's not asymmetrical, correct)?

I'm trying to understand, fully, what you would like to accomplish, and if not possible on Cisco, why it's a problem. Your description of pinging 8.8.8.8 helps, but again, how/why traffic uses the "secondary", from Internet, possibly means your primary/secondary is only for traffic to the Internet, and if so, your concerns about asymmetric routing appears to not apply to secondary inbound traffic that uses primary going back to Internet(?).

@Joseph W. Doherty 

 

When traffic comes from internet through primary line, but destination is backup line Ip adress - there is nothing I can do. This is the source's ISP responsibility. But for me, I will send out reply through backup interface, as the traffic is addressed to the router itself and I have two default route in the routing table. Even through backup line default route has low priority, it will be used because the traffic is to the router itself and to it's backup IP and there is a default route through that interface in the routing table.

 

Cisco's solution of floating route solves most of the problem, user data will always go through the primary line. But from me it is most important the traffic addressed to the router itself from or to internet.

 

Somebody here in the forum mentioned to be, give HUB another IP to run two IPsec towards it. Why would I do that if my setup looks like this -

 

I am running BGP with two different routers with two upstream ISPs. I am announcing my IPV4 routes through BGP. Those two routers are already taking care of my network redundancy. Behind those I have two firewalls in active/passive and they are running IPSec with branches over single IP.  There is no need to taking another public IP just for creating IPSec backup tunnels.

 

With Cisco solution of floating routes IKE/IPSec negotiation happens over always primary line, even though it is sourced from backup line's IP.

 

But with my other device, primary ipsec is sourced from  primary interface and secondary IPSec is sourced from secondary interface. But users who are sitting behind firewall, their data never goes out via backup line, as long as the primary line is active.

 

 

It looks like in Cisco I can  only achieve that by using local policy routing.

 

Traffic addressed to / from backup ip will use local policy routing. This solves problem of the traffic for the router itself.

 

And backup line will have a floating static route which will take care of user data, when primary link goes down.

 

Many thanks others for their inputs.

 

Ok, I understand. Interesting difference in other vendor's approach. I think I prefer Cisco's approach, because, philosophically, if secondary router is a part of a topology that for all traffic preferred path is via primary, unclear why there should be an exception for IPs on the secondary device.

An example of why Cisco's approach might be better, consider if the secondary path had an added cost to utilize. (Often a good reason why secondary is a "backup" path.) Then, suppose you're running SNMP queries against that device. Do you want that stream of data running up a "backup" extra usage cost bill?

BTW, I once designed and managed a build-out for a large call center. We had two gig (or was it dual 10g?) primary/dedicated links, and a secondary path, using a tunnel, also gig capacity, across the internet. The latter had very costly usage charges, which were, of course, acceptable, if that path was the only way to keep the whole call center on-line. That said, we still ran up some usage on that link, as we were using dynamic routing (including passing the default route) across the tunnel. Those too were acceptable, but no other traffic, normally, used that path.

So, just being curious, what's the benefit, to you, for it to work the way it does on the other vendor's device?

BTW, perhaps the closest Cisco would work like that, using the secondary path while primary is active, if the other side used IPs (source and destination) on the shared WAN link. The connected route would take precedence.

Review Cisco Networking for a $25 gift card