load balancing with a failover

"backup interface" and dialer dtr should do it. Dialer DTR may or may not be an option, depending on your physical hardware. If you don't have it, then you may have to use something exotic like IP SLAs.

Here I assume that you mean for the backup link truly to go up or down automatically according to your policy. If all you are concerned about is the path your IP forwarding should take (and you don't REALLY need to bring links up/down at a lower layer), then is a simple job for EIGRP metrics or floating statics or whatever floats your boat.

Aaron

you could use 'backup interface ' command in primary interface configuration. Here is what happens:

CE-2.LAB(config)#in se 0/0:0 CE-2.LAB(config-if)#backup interface atm0/1

*Sep 6 13:24:43.174: %LINK-5-CHANGED: Interface ATM0/1, changed state to standby mode

Unfortunately this is 1:1 redundancy, i.e. you can't specify the same backup interface for two primary interfaces. However, if all of your three lines are of the same bandwidth and connected to the same routers, why don't you just bundle them into multi-link PPP or do per-packet load-balancing across all three lines?

Kind regards, iLya

its a cost thing they dont want to load balance the 3rd line and only want it as a backup solution.

One semi-workaround to this problem with using one interface to backup two other interface might be to use the "backup load" command in addition to specifying the backup interface for one of the interfaces. That way, if the interface in the pair not being backed up went down, it would cause an increase in the load of the interface that does have a backup (but which is still up) and thus result in the the backup interface to come up for load reasons rather than for link failure if the threshold is set correctly.

You would have to choose a somewhat high threshold for the load backup and decide the actual value based on heuristics from your knowledge of how heavily the two links are loaded on average. One problem might be that the backup interface might come up even if the other two interfaces are up but heavily loaded. Anyway, as mentioned, this is just a semi-workaround ...

Cisco da Gama

ok, then the only solution I see is to use GRE tunnel between loopbacks of two routers, run EIGRP _only_ over the tunnel and have RTR tracker to setup route to the remote loopback over thirds interface only if one of the two "primary" links goes down. There will be slight overhead of GRE encapsulation and your routers CPU will be penalized, but at the moment I can't think of any alternative.

I'm sorry, gotta go now. If you don't solve this issue during the weekend, I'll post configs with GRE on monday.

Kind regards, iLya

C-d-G, this is neat workaround. I didn't notice that now there is 'load' option now (used backup really long ago). If you don't mind I'd add some bits to your proposal - instead of backing up individual interface, get them into MLP bundle (only two links) and then backup will be for the whole bundle. I just tried - the backup command can be applied to Multilink interface, but I can't test until monday if it actually going to work. Though still as you've said choosing threshold values will require good quality crystal ball.

Kind regards, iLya

If it's still relevant, below is simplest version of possible config. Assume you have serial0/0:0 (IP: 192.168.0.2/30 on your side) and serial0/1:0 (IP:

192.168.0.6/30) as two primary interfaces and serial1/0:0 is the backup interface (IP: 192.168.0.10/30); IP of the loopback (source of GRE tunnel) on the remote side is 192.168.1.1/32. The tunnel interfaces have addresses from other network though (say 192.168.130.0/30)

! track 100 interface Serial0/0:0 line-protocol ! track 101 interface Serial0/0:0 line-protocol ! track 102 list boolean or object 100 not object 101 not ! int lo0 ip addr 192.168.1.2 255.255.255.255 ! int tun0 ip addr 192.168.130.2 255.255.255.252 tun mode gre tun source lo0 tun dest 192.168.1.1 ! ip route 192.168.1.1 255.255.255.255 192.168.0.9 track 102 ! router eigrp 1 network 192.168.130.0 0.0.0.3 no auto-summary !

CE-2.LAB#sh ip eigrp topology IP-EIGRP Topology Table for AS(1)/ID(192.168.129.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status

P 192.168.130.0/30, 1 successors, FD is 297244416 via Connected, Tunnel0

Add whatever other networks you have on these routers, but do NOT run EIGRP on serial interfaces (important!). The other side should configured in the similar fashion. If you want to have more reliable solution you just need to replace tracking interfaces with RTR ping probe of remote address like in this document -

I didn't have enough time to rebuild physical setup in the lab to represent the scenario, but here is some debug output that will give you an idea what's going on (disregard the addresses just watch out what's going on):

CE-2.LAB# deb ip routing IP routing debugging is on CE-2.LAB#sh ip rou 192.168.1.1 % Network not in table CE-2.LAB#conf t Enter configuration commands, one per line. End with CNTL/Z. CE-2.LAB(config)#int se0/0:0 CE-2.LAB(config-if)#shut CE-2.LAB(config-if)#

1w0d: is_up: 0 state: 6 sub state: 1 line: 0 has_route: True 1w0d: RT: interface Serial0/0:0 removed from routing table 1w0d: RT: del 192.168.128.20/30 via 0.0.0.0, connected metric [0/0] 1w0d: RT: delete subnet route to 192.168.128.20/30 1w0d: RT: NET-RED 192.168.128.20/30 1w0d: RT: delete network route to 192.168.128.0 1w0d: RT: NET-RED 192.168.128.0/24 1w0d: RT: SET_LAST_RDB for 192.168.1.1/32 NEW rdb: via 192.168.0.5

1w0d: RT: add 192.168.1.1/32 via 192.168.0.5, static metric [1/0]

1w0d: RT: NET-RED 192.168.1.1/32 1w0d: RT: del 0.0.0.0 via 192.168.128.21, static metric [1/0] 1w0d: RT: delete network route to 0.0.0.0 1w0d: RT: NET-RED 0.0.0.0/0 1w0d: RT: NET-RED 0.0.0.0/0 *Sep 9 08:44:40.670: %LINK-5-CHANGED: Interface Serial0/0:0, changed state to administratively down 1w0d: is_up: 0 state: 6 sub state: 1 line: 0 has_route: False *Sep 9 08:44:41.670: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0:0, changed state to down 1w0d: is_up: 0 state: 6 sub state: 1 line: 0 has_route: False^Z CE-2.LAB#sh ip rou 192.168.1.1 *Sep 9 08:44:47.862: %SYS-5-CONFIG_I: Configured from console by console Routing entry for 192.168.1.1/32 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 192.168.0.5 Route metric is 0, traffic share count is 1

CE-2.LAB#conf t Enter configuration commands, one per line. End with CNTL/Z. CE-2.LAB(config)#int se0/0:0 CE-2.LAB(config-if)#no shut CE-2.LAB(config-if)#

1w0d: is_up: 0 state: 4 sub state: 1 line: 0 has_route: False^Z CE-2.LAB# *Sep 9 08:45:02.778: %SYS-5-CONFIG_I: Configured from console by console *Sep 9 08:45:02.910: %LINK-3-UPDOWN: Interface Serial0/0:0, changed state to up 1w0d: is_up: 1 state: 4 sub state: 1 line: 0 has_route: False 1w0d: RT: SET_LAST_RDB for 192.168.128.20/30 NEW rdb: is directly connected

1w0d: RT: add 192.168.128.20/30 via 0.0.0.0, connected metric [0/0]

1w0d: RT: NET-RED 192.168.128.20/30 1w0d: RT: interface Serial0/0:0 added to routing table 1w0d: is_up: 1 state: 4 sub state: 1 line: 0 has_route: True 1w0d: RT: del 192.168.1.1/32 via 192.168.0.5, static metric [1/0] 1w0d: RT: delete subnet route to 192.168.1.1/32 1w0d: RT: NET-RED 192.168.1.1/32 1w0d: RT: delete network route to 192.168.1.0 1w0d: RT: NET-RED 192.168.1.0/24 *Sep 9 08:45:04.074: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0:0, changed state to up

Hope this helps.

Kind regards, iLya

~ >

~ > i have a router with 3 t1 links. im doing per packet load balancing on ~ > the 1st 2 with the 3rd one being in admin down state and i only bring ~ > it up when they need additional bandwidth. ~ >

~ > i want to conver this 3rd line into a fail over link, so that when one ~ > of the 2 active load balancing lines goes down, the 3rd line will do ~ > load balancing with the line that did not go down. ~ >

~ ~ you could use 'backup interface ' command in ~ primary interface configuration. Here is what happens: ~ ~ CE-2.LAB(config)#in se 0/0:0 ~ CE-2.LAB(config-if)#backup interface atm0/1 ~ *Sep 6 13:24:43.174: %LINK-5-CHANGED: Interface ATM0/1, changed state to ~ standby mode ~ ~ Unfortunately this is 1:1 redundancy, i.e. you can't specify the same backup ~ interface for two primary interfaces. However, if all of your three lines ~ are of the same bandwidth and connected to the same routers, why don't you ~ just bundle them into multi-link PPP or do per-packet load-balancing across ~ all three lines? ~ ~ Kind regards, ~ iLya ~

One dialer profile can serve as a backup interface to multiple primary interfaces.

Aaron,

True, but in my experience Dialer profile does not go down, which then just replaces one problem with another. Dialer staying always up was the reason, why we started to use RTR-based tracking for setting up static routes conditionally. I haven't tried though Dialer with leased-line type interfaces.

Kind regards, iLya

~ > One dialer profile can serve as a backup interface to multiple ~ > primary interfaces. ~ ~ Aaron, ~ ~ True, but in my experience Dialer profile does not go down, which then just ~ replaces one problem with another. Dialer staying always up was the reason, ~ why we started to use RTR-based tracking for setting up static routes ~ conditionally. I haven't tried though Dialer with leased-line type ~ interfaces. ~ ~ Kind regards, ~ iLya

Agreed, IP SLAs (nee RTR) is the most flexible approach.

The original poster implied that he wanted to have his backup interface

*down* (rather than just not transmitting traffic), which is why I was thinking dialers. I'm not sure if my inference was correct though ...

I hope you didn't get me wrong. I didn't mean to dismiss your proposed solution, neither to pretend that I understood original requirement correctly (importance whether actual state of the interface matters or only traffic mustn't pass). In fact now after re-reading your previous post it's obvious that you proposed to use dialer attached to the backup interface as opposed to binding several primary interface and then specify backup for dialer. Sorry for confusion.

Kind regards, iLya