Re: HSRP and tracking FR interface

From: Bit Gossip (bit.gossip@chello.nl)
Date: Sat Aug 04 2007 - 14:41:04 ART


Is it possible to have SLA to bring down an interface in case of failure
instead of changing HSRP status.
And if it is, how?
Thanks,
Luca.

----- Original Message -----
From: "Djerk Geurts" <djerk@djerk.nl>
To: "'Ben'" <bmunyao@gmail.com>; "'Cisco certification'"
<ccielab@groupstudy.com>
Sent: Tuesday, July 31, 2007 1:30 PM
Subject: RE: HSRP and tracking FR interface

> There are two other options:
>
> - Using PPP as PPPoFR, PPP maintains end-to-end connectivity so a broken
> pvc
> would brind own the interface.
> - Using rtr tracking, while making sure that the IP address you're pinging
> is only reachable via the FR link. An ideal address to ping would be the
> remote end of the pvc as if the FR interface doesn't go down then the
> router
> will try to reach this IP through the FR interface despite the pvc being
> broken:
>
> ip sla monitor 1
> type echo protocol ipIcmpEcho 1.1.1.1
> !
> track 1 rtr 1 reachability
>
> Djerk
>
>
>> -----Original Message-----
>> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
>> Behalf Of Ben
>> Sent: dinsdag 31 juli 2007 12:33
>> To: Cisco certification
>> Subject: Re: HSRP and tracking FR interface
>>
>> Hi
>>
>> Is the following the only way to do this?
>>
>> R3 (FR Spoke site)
>> int tu35
>> ip add 124.1.35.3 255.255.255.0
>> tunnel sour lo0
>> tunnel dest 150.1.5.5
>> keepalive 3 5
>> track 1 int tu35 line-protocol
>> int f0/0
>> ip add 10.10.1.3 255.255.255.0
>> stand 1 priority 105
>> stand 1 preempt
>> stand 1 track 1
>> stand 1 ip 10.10.1.254
>>
>> R5 (FR Hub site)
>> int tu35
>> ip add 124.1.35.5 255.255.255.0
>> tunnel sour lo0
>> tunnel dest 150.1.3.3
>> keepalive 3 5
>>
>> TIA
>> Ben
>>
>>
>> On 7/31/07, Ben <bmunyao@gmail.com> wrote:
>> >
>> > Hi
>> >
>> > When a question requires HSRP on LAN with R3 and R4 as
>> active/backup, and
>> > R4 taking over when R3 looses FR connection, how can you
>> track the FR
>> > interface?
>> >
>> > Here is an example:
>> >
>> > .3
>> > |-------------------------------R3 \
>> > | \
>> > |10.10.1.0/24 FR cloud
>> > | /
>> > |-------------------------------R4 /
>> >
>> > Assume FR is configured on physical interface. Would the
>> following qualify
>> > as a solution?
>> >
>> > R3
>> > int f0/0
>> > ip add 10.10.1.3 255.255.255.0
>> > stand 1 priority 105
>> > stand 1 preempt
>> > stand 1 track s0/0
>> > stand 1 ip 10.10.1.254
>> >
>> > R4
>> > int f0/0
>> > ip add 10.10.1.4 255.255.255.0
>> > stand 1 preempt
>> > stand 1 ip 10.10.1.254
>> >
>> > I presume this use of the track keyword only tracks the
>> line-protocol on
>> > s0/0, and will therefore not detect when R3 looses IP
>> connectivity to the
>> > other end of its DLCI. A variation of the stand 1 track
>> s0/0 on R3 would be
>> >
>> > track 1 interface s0/0 line-protocol
>> > int f0/0
>> > stand 1 track 1
>> >
>> >
>> > Another recent discussion on EEK indicated that EEK will
>> not bring down
>> > the interface when the other end is not reachable. How can
>> we then meet the
>> > requirements of the question? Do we have do use a GRE
>> tunnel with keepalive
>> > over the FR link, and track that? Is there any other alternative?
>> >
>> > TIA
>> > Ben
>>
>> ______________________________________________________________
>> _________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html



This archive was generated by hypermail 2.1.4 : Sat Sep 01 2007 - 11:32:09 ART