From: Ben (bmunyao@gmail.com)
Date: Tue Jul 31 2007 - 12:46:10 ART
Hi Antonio
You have no idea how much time I wasted looking for this.
Thank you so much.
Ben
PS: Perhaps cisco plans to do away with some of these features. Else it
doesn't make sense for them to leave them out of newer documentation. Just a
thought.
On 7/31/07, Antonio Soares <amsoares@netcabo.pt> wrote:
>
> Hi Ben,
>
> I had the same problem when trying to locate this feature. It seems they
> forgot to add it to later releases documentation:
>
>
>
>
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122
> t/122t2/ft1csaa.htm
>
>
> Regards,
>
> Antonio Soares
> CCIE #18473, CCNP, CCIP
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Ben
> Sent: terga-feira, 31 de Julho de 2007 13:49
> To: Djerk Geurts
> Cc: Cisco certification
> Subject: Re: HSRP and tracking FR interface
>
> Thanks Antonio, Djerk for your feedback.
>
> The options then appear to be
>
> 1. EEK if using a P2P subinterface, or MP subinterface with a single PVC.
>
> 2. GRE with keepalive
>
> 3. IP SLA type FR (responder req'd on remote end)
>
> 4. IP SLA type icmpecho (responder no req'd)
>
> 5. PPPoFR, depending on the task and its dependencies with other tasks
>
> Having some difficulty tracing IP SLA FR in Doccd. I would appreciate a
> URL
> if anyone has located it.
>
>
> Thanks once again
>
> Ben
>
>
>
>
> On 7/31/07, Djerk Geurts <djerk@djerk.nl> wrote:
> >
> > Antonio,
> >
> > Thank you didn't know they added FR support into IP SLA. Tested and
> > works like a charm. Though you do need to add the responder to the
> > other side of the pvc. Not tested to see whether it ignores the IP
> > side of things like a misconfigured IP address.
> >
> > Another nice question for a proctor imho :)
> >
> > Djerk
> >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > > Of Antonio Soares
> > > Sent: dinsdag 31 juli 2007 13:30
> > > To: 'Ben'; 'Cisco certification'
> > > Subject: RE: HSRP and tracking FR interface
> > >
> > > Hello Ben,
> > >
> > > The best solution i know for this kind of problem is using IP SLA.
> > > Something like this:
> > >
> > > R6:
> > > +++++++++++++++++++++++
> > > !
> > > ip sla monitor 1
> > > type frame-Relay interface Serial1/0 dlci 601 timeout 500
> > > frequency 1 !
> > > track 1 rtr 1
> > > !
> > > interface FastEthernet0/0
> > > ip address 6.6.6.6 255.255.255.0
> > > duplex auto
> > > speed auto
> > > standby ip 6.6.6.254
> > > standby preempt
> > > standby track 1
> > > !
> > > interface Serial1/0
> > > ip address 10.10.10.6 255.255.255.0 encapsulation frame-relay
> > > serial restart-delay 0 frame-relay map ip 10.10.10.1 601 broadcast
> > > no frame-relay inverse-arp frame-relay lmi-type cisco !
> > >
> > > R1:
> > > +++++++++++++++++++++++
> > > ip sla monitor responder
> > >
> > >
> > > Regards,
> > >
> > > Antonio Soares
> > > CCIE #18473, CCNP, CCIP
> > >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > > Of Ben
> > > Sent: terga-feira, 31 de Julho de 2007 11:00
> > > To: Cisco certification
> > > Subject: HSRP and tracking FR interface
> > >
> > > 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
> >
> > ______________________________________________________________________
> > _ 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 Aug 18 2007 - 08:17:42 ART