Two static routes to same destination in routing table possible?

[ssajiby2k]

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,

[Georg Pauwen]

Hello,

not really sure what you are after, but maybe you can try the below.

First, create two static routes using fake default gateways:

ip route 10.0.1.1 255.255.255.255 192.168.1.2 --> ISP1
ip route 10.0.2.1 255.255.255.255 192.168.2.2 --> ISP2

Now, since the gateways are different you can create two routes to the same destination, but using different gateways:

ip route 0.0.0.0 0.0.0.0 10.0.1.1
ip route 0.0.0.0 0.0.0.0 10.0.2.1

[ssajiby2k]

@Georg Pauwen 

With your solution I cannot stop data traffic flowing through for example ISP2 which is backup only or router own initiated traffic.

[Heriberto Diaz]

Hi

Try to configure the 2 static route and cofigure on the interface the command "ip load-sharing per-packet" and also you can configure a IP SLA (icmp-echo) just to monitor if the next-hop is reached. If not then with a route-map modify the next hop to not lose packets.

Regards.

[ssajiby2k]

Hi,

Thanks for your reply. You guys are not understanding my problem.

Let's say - Branch has two ISP line. Line 1 is 1.0.0.0/30 and gateway being 1.0.0.1. Line 2 is 1.0.0.4/30 and gateway being 1.0.0.5. My constraints - for data traffic from clients behind branch router under no condition allowed to use line2. Line2 sole purpose is backup, except for router own initiated traffic. For router own initiated traffic if the traffic is initiated from line1 it goes to default gateway of line1 and also trafic initiated from line2, goes to default gateway in line2.

Now for example I have hub router located at 3.3.3.3. There I want to run IPSec in tunnel mode and routing over OSPF. Both IPSec tunnels from branch will be active to same IP adress in hub (3.3.3.3).  I will just manipulate tunnel created over line2 with higher cost. So, IPSec over line 2 will become neighbors already. Just routes will not come to OSPF because of cost. No funny stuffs like IP SLA to monitor one interface then turn up the other when primary goes down. Both tunnels will be active, just one will be used and manipulated by OSPF routing protocol itself. 

To create this IPSec setup I need two routes to 3.3.3.3 in branch over respective lines.

But Cisco does not allow this. Only one route to 3.3.3.3 be active in routing table.

Let's see what happens when a ping is sourced from branch IP 10.0.0.6 (line 2), because of routing table the packet cannot exit out the same interface. it will exit through wrong interface line1. But come back through line2. So what just happened asymmetric routing. 

Why this behavior?

In my other vendor equipment I just declare -

3.3.3.3/32 GW 1.0.0.1 interface line1 distance 5 priority 5

3.3.3.3/32 GW 1.0.0.5 interface line2 distance 5 priority 10

Because of this priority, both gets installed into the routing table. But lower priority valued route is used when traffic is flowing through it. But for it's own generated traffic it sees I have a default route out also for line2, so traffic goes via that line and comes via the same line. So asymmetric stuffs.

[Georg Pauwen]

Hello,

the tricky part seems to be this:

--> For router own initiated traffic if the traffic is initiated from line1 it goes to default gateway of line1 and also trafic initiated from line2, goes to default gateway in line2.

What kind of traffic is that, how does the router 'initiate' that traffic ?

[Georg Pauwen]

Hello,

actually, I don't see any other way than getting the two routes installed using the 'fake gateway' method, and then configure policy routing.

[ssajiby2k]

@Georg Pauwen 

Branch will create two IPSec tunnel to same remote Ip 3.3.3.3. At least from the source - Branch I want to avoid asymmetric routing. Ipsec source from line1 should be created over by sending packets through that interface. The same applies for line2.

Let's do more fun - I want both line1 and line2 register their dhcp adress in a ddns service through their respective IP adress and packet should go out respective interfaces.

These are some examples of router's own traffic.

[Georg Pauwen]

Hello,

can you do a 'debug ip packet' to get a picture of which source and destination you need to match for the policy routing ?

[Jon Marshall]

Assuming global routing table, no in answer to your question and don't use Cisco as a solution. 

Jon

[Heriberto Diaz]

Hi

If you are using OSPF throught IPSec tunnel I think you need to play with calculate the cost OSPF on your topology to avoid asymetric routing between your branch and hub.

Regards

[mlund]

Hi

My understanding of this is that you want to build 2 tunnels to the same destination. And then run ospf over the tunnels.

If that understanding is correct, then it seems to me that the easiest way is to use one extra ip address at the hub site. For example 3.3.3.4. Then you can have one route for 3.3.3.3 to 1.0.0.1 and one route for 3.3.3.4 to 1.0.0.5. With that set up you can now set up tunnel1 with source 1.0.0.2 dest 3.3.3.3 and tunnel 2 sou 1.0.0.6 dest 3.3.3.4

/Mikael

[paul driver]

Hello
1x branch rtr with two isp connections
1x hub rtr reachable by both ISP's

Maybe i am not totlaly understanding, but if the above is correct what’s is the issue?
The Hub rtr will be reachable via both ISPs, So you could create dual gre/ipsec tunnels sourced from either of the branch rtrs ISP interfaces towards the hub rtr routable address and the run ospf over those tunnel to advertise whatever subnet networks you wish?

[Joseph W. Doherty]

That might not be possible on Cisco equipment, because, as far as I know, multiple entries in Cisco's routing table are all actively used. The closest you might come to this, is using EIGRP, which, in some conditions, will retain a backup path, i.e. feasible successor, that can be immediately used if the primary path (the one shown in the route table) is lost.

[Joseph W. Doherty]

Assuming I'm correct, i.e. Cisco doesn't support what you're trying to do, could you clarify the underlying problem/issue you're trying to address? From what you describe, you mention another vendor has a way to "install" to static routes, where both appear in the routing table, but one has priority over the other, for active usage, and the other route only is used if the primary cannot be. Unclear where having both routes shown in the routing table is, as described, different from using static floating routes, except you cannot "see" the backup floating route. (My mention of EIGRP's FS, was because I believe, with the correct EIGRP commands, you can "see" such.)

In your OP you mention the problem of having the default route, for general Internet access, and across an IPSec tunnel too, also across the Internet. Unsure I fully understand your topology, but years ago I had a somewhat similar problem of wanting to use Internet, with a default route, going out to many remote routers, providing tunnels (DMVPN), for an internal network, that also used default route. The two defaults had completely different gateways.

In my case, I solved the problem by using VRFs. I kept the tunnel hub interface within the internal network's global VRF, and assigned the outside physical Interface to a different VRF. This allowed be to have two default routes, although logically in different L3 topologies. Unclear whether this might work for you, as the two defaults were active, although not sharing the same traffic.