Prev: Reason 401: An unrecognized error occurred while establishing the VPN connection.
Next: Cisco 1841 dual adsl setup
From: Aaron Leonard on 3 Mar 2006 14:22
"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

---

~ ok, im not sure if this is possible but if it is im sure someone here
~ knows how to get this working.
~
~
~ 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.
~
~ is this possible and how can i go about it. fyi im using eigrp routing
~ and per packet loading.
~
~
~ Thanks P

From: Charlie Root on 6 Mar 2006 12:00
"Charlie Root" <root(a)localhost.example.com> wrote in message
news:duaim1$103q$1(a)citadel.nobulus.com...
> <yo> wrote in message news:9rdh02drpjnvq7j0m4l63hgcoafkif1rov(a)4ax.com...
>>
>> its a cost thing they dont want to load balance the 3rd line and only
>> want it as a backup solution.
>>
>
> 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.
>

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 -
http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps5413/products_feature_guide09186a00801d862d.html.

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


From: Aaron Leonard on 6 Mar 2006 12:50
On Fri, 3 Mar 2006 22:09:17 +0100, "Charlie Root" <root(a)localhost.example.com> wrote:

~ <yo> wrote in message news:70rg02td6bo3p6n7b7sd71aifkaelbj21h(a)4ax.com...
~ > ok, im not sure if this is possible but if it is im sure someone here
~ > knows how to get this working.
~ >
~ >
~ > 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 <name_of_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.
From: Charlie Root on 6 Mar 2006 13:26
"Aaron Leonard" <Aaron(a)Cisco.COM> wrote in message
news:tgto021fogo5k1tf0eo4thtt7sb8vfd7e7(a)4ax.com...
> On Fri, 3 Mar 2006 22:09:17 +0100, "Charlie Root"
> <root(a)localhost.example.com> wrote:
>
> ~ <yo> wrote in message news:70rg02td6bo3p6n7b7sd71aifkaelbj21h(a)4ax.com...
> ~ > ok, im not sure if this is possible but if it is im sure someone here
> ~ > knows how to get this working.
> ~ >
> ~ >
> ~ > 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 <name_of_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


From: Aaron Leonard on 7 Mar 2006 13:05

~ > 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 ...
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Reason 401: An unrecognized error occurred while establishing the VPN connection.
Next: Cisco 1841 dual adsl setup