cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2039
Views
50
Helpful
25
Replies

Best Way to Configure Backup T1 Interface

Patrick McHenry
Level 3
Level 3

Hi,

I was wondering what was the best practice is for configuring a backup T1 interface? The primary interface is a DS3 to HQ.

Could it be possible with a DS3 to have an interface show as up but the DS3 not function?

I was thinking if this is the case - maybe I should configure a IP SLA pinging the other side and when that fails, I could run an EEM script to bring up the T1 and when the pings come back I could shut the T1.

Any ideas or docs on how to set up?

Also, any docs on how to set up the T1 interface?

Thank you, Pat.

25 Replies 25

If you're using strictly eigrp, you won't need floating statics unless your needs call for it. Floating routes are mainly a backup route that's not put into the table unless an exact route that has a lower AD is removed from the routing table. For example:

ip route 0.0.0.0 0.0.0.0 192.168.1.1

ip route 0.0.0.0 0.0.0.0 192.168.2.1 254

The default route above pointing to 192.168.1.1 has a lower admin distance than the exact route with an AD of 254. The default route in the routing table will be the one that points to 192.168.1.1 unless the interface that's used to get to that route (usually connected) goes down. If that happens, the 192.168.2.1 route will be inserted into the table.

HTH,
John

*** Please rate all useful posts ***

HTH, John *** Please rate all useful posts ***

John -

So why wouldn't I want to use this? This could work for me. I need a default route and the next hop will change if the DS3 goes down so, I think this would work.

Thanks, Pat.

If you're using eigrp with redundant paths you shouldn't need this, but if you're using statics, there's no reason why you shouldn't use it. The thing with static is that it doesn't change regardless of the next hop is up or not. With a dynamic routing protocol, it can change depending on conditions. The floating static route gives you somewhat of a method to take into consideration another route albeit static as well. I have some routes that I have static to override what I learn from bgp, but should that next-hop fail I have my bgp route to fall back on. There are really many different scenarios as to when you need this and when you don't. It really goes back on if eigrp can see all of your topology and you're not having to fill in 'holes' so to speak with static routes.

HTH,
John

*** Please rate all useful posts ***

HTH, John *** Please rate all useful posts ***

John -

What other method could I use? Don't I still need a default route for networks the Branch router doesn't know?

Thank you.

You do need a default route and this would work fine, but again if you're networks are known via eigrp that should be the only method you'd need outside of the default. You could still do the two defaults with the floating static though.

HTH,
John

*** Please rate all useful posts ***

HTH, John *** Please rate all useful posts ***

John,

I feel like I might be missing something. All the routes are learned via EIGRP in this environment but, I must have a default route for each WAN link, correct? One for the DS3 link (to the address on the other side of that link) and one for the T1 link(to the address on the other side of that link). There is no other way, is there? I could point the default to the WAN interface of the Branch router or use default information-originate but, other than that, is there another way?

Thank you, Pat

Pat,

Maybe I'm not explaining myself well enough

You have a branch router and a router at HQ. My understanding, taking these 2 sites alone, is that you run eigrp between these two locations. Assuming that you're advertising every subnet between the two locations, then a default route would be needed on the branch router pointing to HQ (assuming that you are providing an egress point for internet access for the remote branch). But all of the other routes are eigrp learned, so for the failover to happen, eigrp is smart enough to know that the link it was using to get to the HQ site is now down and it will have to route over the T1. The default route that you'll install on the remote site though would point toward your ds3 circuit and then you would do a floating route for the same route pointing to the t1. If the ds3 were to go down, all of your routes that were eigrp learned and the floating default will traverse the t1 now:

R1 = branch

R2 = HQ

R1 ----- R2

R1#sh run | in ip route

ip route 0.0.0.0 0.0.0.0 172.12.0.2

ip route 0.0.0.0 0.0.0.0 192.168.12.2 254  <--- Floating default route

R1#sh run | s router eigrp

router eigrp 100

network 172.12.0.1 0.0.0.0

network 192.168.12.1 0.0.0.0

no auto-summary

Below is the topology table. Notice I have 2 paths for each route. S0/1 is set at 45Mb (DS3) and S0/0 is 1544 (T1) S0/1 is the successor at a FD of 696832 for 2.2.2.0/24 (meaning it wins the right to be in the routing table):

R1#sh ip eigrp top

IP-EIGRP Topology Table for AS(100)/ID(192.168.12.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

       r - reply Status, s - sia Status

P 2.2.2.0/24, 1 successors, FD is 696832

        via 172.12.0.2 (696832/128256), Serial0/1

        via 192.168.12.2 (2297856/128256), Serial0/0

P 22.22.22.0/24, 1 successors, FD is 696832

        via 172.12.0.2 (696832/128256), Serial0/1

        via 192.168.12.2 (2297856/128256), Serial0/0

The routing table on R1. Notice there is only 1 route pointing to s0/1 (DS3) because of it being the successor. Also notice the static route for the default pointing to 172.12.0.2: (The 2 bolded routes are the ones that we'll focus on.)

C    192.168.12.0/24 is directly connected, Serial0/0

     2.0.0.0/24 is subnetted, 1 subnets

D       2.2.2.0 [90/696832] via 172.12.0.2, 00:07:48, Serial0/1

     172.12.0.0/24 is subnetted, 1 subnets

C       172.12.0.0 is directly connected, Serial0/1

     22.0.0.0/24 is subnetted, 1 subnets

D       22.22.22.0 [90/696832] via 172.12.0.2, 00:07:48, Serial0/1

S*   0.0.0.0/0 [1/0] via 172.12.0.2

I'll shut the DS3 interface to simulate a failure:

R1(config)#int s0/1

R1(config-if)#shut

R1(config-if)#

*Mar  1 00:15:35.979: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.12.0.2 (Serial0/1) is down: interface down

R1(config-if)#

*Mar  1 00:15:37.959: %LINK-5-CHANGED: Interface Serial0/1, changed state to administratively down

*Mar  1 00:15:38.959: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to down

R1(config-if)#

Now look at the routing table:

R1#sh ip route

Gateway of last resort is 192.168.12.2 to network 0.0.0.0

C    192.168.12.0/24 is directly connected, Serial0/0

     2.0.0.0/24 is subnetted, 1 subnets

D       2.2.2.0 [90/2297856] via 192.168.12.2, 00:00:55, Serial0/0

     22.0.0.0/24 is subnetted, 1 subnets

D       22.22.22.0 [90/2297856] via 192.168.12.2, 00:00:55, Serial0/0

S*   0.0.0.0/0 [254/0] via 192.168.12.2

So when the interface goes down, the floating default will get put in the routing table because the next hop that it was originally pointing to is no longer available due to the interface that it would use to get to it being down. Also notice that 2.2.2.0 is now pointing to the other interface s0/0 (T1). If you look at the topology table for eigrp now, you'll see that the original route is no longer in the table:

P 2.2.2.0/24, 1 successors, FD is 696832

        via 192.168.12.2 (2297856/128256), Serial0/0

P 22.22.22.0/24, 1 successors, FD is 696832

        via 192.168.12.2 (2297856/128256), Serial0/0

P 192.168.12.0/24, 1 successors, FD is 2169856

        via Connected, Serial0/0

But, when I bring that interface back up it will get reentered into the table and it's preferred again:

R1#sh ip eigrp top

IP-EIGRP Topology Table for AS(100)/ID(192.168.12.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

       r - reply Status, s - sia Status

P 2.2.2.0/24, 1 successors, FD is 696832

        via 172.12.0.2 (696832/128256), Serial0/1

        via 192.168.12.2 (2297856/128256), Serial0/0

P 22.22.22.0/24, 1 successors, FD is 696832

        via 172.12.0.2 (696832/128256), Serial0/1

        via 192.168.12.2 (2297856/128256), Serial0/0

Oh, and just to show you the floating route concept, you'll also notice that since I brought that interface back up, the floating default that we had is now no longer the default route; it's the original one that we had at first pointing to 172.12.0.2 because of its lower AD (1 vs 254):

R1#sh ip route | inc 0.0.0.0

Gateway of last resort is 172.12.0.2 to network 0.0.0.0

S*   0.0.0.0/0 [1/0] via 172.12.0.2

HTH,

John

*** Please rate all useful posts ***

HTH, John *** Please rate all useful posts ***

You deserve 50 points fro the explaination. This is how I understood it, It just seemed to me you were suggesting that there was a alternative way. It was probably my misunderstanding.

BTY how long did it take for your route to change over to the T1? I did a similiar lab in GNS and it took about 35 seconds for traffic to start going over the T1 after I shut the DS3 interface?

Is this what is to be expected?

Thanks, Pat.

It only took about a second for mine to fail over. Thirty-five seconds seems long, but I wouldn't compare what you see in gns to the real world though. It will fail over faster than you'll notice in the real world if you set it up exactly like this. While gns is good, it still has some weird quirks. If you want to shoot your configs that you used over I can lab them up here and see if it does the same thing with me.

HTH,
John

*** Please rate all useful posts ***

HTH, John *** Please rate all useful posts ***

John,


I did the lab today with new configs and when I pinged the Lo0 interface of HQ (pretend Internet Address) from the Host Router, the pings only dropped momentarily. the Line protocol on Interface Serial0/0 of  the Branch was down but, the s0/0 interface of the HQ stayed up for a bit.

Weird thing: when I manually shut the DS3 interface on the Branch, the pings only dropped momentarily but, the default route was still pointing to the DS3, then the s0/0 interface on HQ went down after about a minute and then the default route would be the T1 and the pings would stop for a 10 secs and then carry on.

Gateway of last resort is 172.20.1.61 to network 0.0.0.0

     172.20.0.0/30 is subnetted, 1 subnets
C       172.20.1.68 is directly connected, Serial0/1
C    192.168.1.0/24 is directly connected, FastEthernet0/0
S*   0.0.0.0/0 [1/0] via 172.20.1.61 (the DS3 interface)

Could I attribute this to GNS behavior?

HQ#sh run br
Building configuration...

Current configuration : 1253 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname HQ
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
ip cef
!
!
!
!
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
no ip address
!
interface Loopback1
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
no ip address
shutdown
duplex auto
speed auto
!
interface Serial0/0
description DS3 WAN Link
bandwidth 44210
ip address 172.20.1.61 255.255.255.252
clock rate 2000000
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
interface Serial0/1
description T1 WAN Link
bandwidth 1544
ip address 172.20.1.69 255.255.255.252
clock rate 2000000
!
interface Serial0/2
no ip address
shutdown
clock rate 2000000
!
interface Serial0/3
no ip address
shutdown
clock rate 2000000
!
router eigrp 99
network 172.20.1.60 0.0.0.3
network 172.20.1.68 0.0.0.3
no auto-summary
!
ip forward-protocol nd
!
!
ip http server
no ip http secure-server
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
login
!
!
end

HQ#

Branch#sh run b
*Mar  1 00:35:47.211: %SYS-5-CONFIG_I: Configured from console by consoler
Building configuration...

Current configuration : 1259 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Branch
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
ip cef
!
!
!
!
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.0
duplex auto
speed auto
!
interface Serial0/0
description DS3 WAN Link
bandwidth 44210
ip address 172.20.1.62 255.255.255.252

clock rate 2000000
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
interface Serial0/1
description T1 WAN Link
bandwidth 1544
ip address 172.20.1.70 255.255.255.252
clock rate 2000000
!
interface Serial0/2
no ip address
shutdown
clock rate 2000000
!
interface Serial0/3
no ip address
shutdown
clock rate 2000000
!
router eigrp 99
network 172.20.1.60 0.0.0.3
network 172.20.1.68 0.0.0.3
network 192.168.1.0
no auto-summary
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 172.20.1.61
ip route 0.0.0.0 0.0.0.0 172.20.1.69 254
!
!
ip http server
no ip http secure-server
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
login
!
!
end

Branch#

Host#sh run br
Building configuration...

Current configuration : 742 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Host
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
ip cef
!
!
!
!
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface FastEthernet0/0
ip address 192.168.1.10 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
ip default-gateway 192.168.1.1
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 192.168.1.1
!
!
ip http server
no ip http secure-server
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
login
!
!
end

Host#

Thanks, Pat

I do believe it's GNS. Your real world experience is going to be much faster when the router notices that the link is down.

HTH,
John

*** Please rate all useful posts ***

HTH, John *** Please rate all useful posts ***
Review Cisco Networking products for a $25 gift card