7.5 HSRP

This taks may use some rewording:

  • Configure HSRP blah blah
  • These hosts blah blah
  • R1 should be the preferred gateway unless it loses its connection to the Frame Relay cloud
  • Do not use object-tracking to accomplish this



interface Tunnel0
blah blah
interface FastEthernet0/0
blah blah
standby 1 track Tunnel0 20

I'm sorry... but this is object-tracking, which we are not allowed to use according to the task description.



    I think object-tracking is an independent feature that can be called by it's number for different purposes (like pulling out a static route).


    although the command: "standby 1 track Tunnel0 20" Misleadingly contains the word "track", it's just a limited built in feature of HSRP.


    if you were to use the object-tracking feature to accomplish this same task, it would be something like:


    #track 10 interface Tunnel0 line-protocol 

    #int f0/0

    #standby 1 track 10 decrement 20 


  • Thanks for your response, but I still think that the task needs rewording.

    The Cisco Doc CD refers to the track option in HSRP as object-tracking and that was why I couldn't figure out an alternative way to configure this.

    The task should read something like Do not track the status of the Frame Relay circuit to accomplish this...

  • Yep, it needs rewording and be more specific on what can or can not be tracked.

  • Using this wording, we can simply track S0/0 state.

    "unless it loses its connection to the Frame Relay cloud".

    The tasks do sth else, it make sure, that we have active connection to R3. Our connection to R3 mail fail, but connection to FR clout will still be okay.

    Anyway, great example of using things to achieve goals which are not supposed to be achieved by using those things. :-)


  • right, I went ahead and asked the proctor on this one...ahem...me...and determined they were referring to a tracked object as in:

    track 1 interface ser0/0 line-protcol

    int fa0/0

    standby 1 track 1

    so I went ahead and just applied the config like so:

    int fa0/0

    standby 1 track ser0/0


    I do agree...the task needs to be reworded to something like "R1 should be the primary unless it loses connectivity to the R1-2-3 frame cloud (there are 2 frame clouds on R1).  You cannot directly track the serial 0/0 interface to do so."  Or something to that end....

  • IMO, a tracked interface and a tracked object ARE different.  I think that is because other questions have said 'do not use interface tracking' so I know how the test authors view it.  However, that wasn't the problem I had with this question.


    There was no wording that required end-to-end tracking.  It said lost conenctivity TO the cloud, not THROUGH the cloud.  This tells me that tracking s0/0 is adequate.  In a real lab I would likely have asked the proctor on this since I am not a fan of building tunnels all over the place.

  • In addition to the confusion on what oject tracking is. There is nothing that says we can create an additional interface to complete the task.

  • From the documentation:

    HSRP Object Tracking

    Object tracking separates the tracking mechanism from HSRP and creates a
    separate standalone tracking process that can be used by any other process as
    well as HSRP. The priority of a device can change dynamically when it has been
    configured for object tracking and the object that is being tracked goes down.
    Examples of objects that can be tracked are the line protocol state of an
    interface or the reachability of an IP route. If the specified object goes down,
    the HSRP priority is reduced.

  • In addition to the confusion on what oject tracking is. There is nothing that says we can create an additional interface to complete the task.


    Object tracking is explained here very well, give some more attention on it.


    One common example of HSRP object tracking is: You have two routers R1 and R2 connected to different ISP, R1 is primary so Active on HSRP group and R2 is secondary and standby on HSRP group. If you don't track the connectivity towards ISP, always R1 will be active which couldn't send traffic to ISP and packets gets dropped. If you enable object tracking (IP SLA or route tracking or interface), it sends packets frequently and checks the availability. If object tracking returned fail, the priority of HSRP will be down and R2 will be active so all traffic goes via R2 to secondary ISP:

    You cant track those objects:

    R1(config)#track 1 ?
      application  Application
      interface    Select an interface to track
      ip           IP protocol
      list         Group objects in a list
      stub-object  Stub tracking object

    R1(config)#track 1 ip ?
      route  IP route
      sla    IP Service Level Agreement

    Good Luck


  • No matter which way you slice it, the wording on this task is atrocious. If the goal was to avoid tracking the serial interface, it needs to say so. I do not understand the purpose of tracking a tunnel interface instead of tracking a serial interface, they're basically the same thing - if 149.x.123.1 leaves the routing table, give up the active role.

    The only way I could figure to do this without tracking an interface was via EEM, look for the line protocol of the serial interface going down, and then have it adjust the priority on the interface below R2's, and when it comes back up, put it higher, which is a needlessly complicated method. 

    The lack of explanation in the study guide as to *WHY* it should be done in the suggested way is an incredible source of frustration with me when it comes to INE's workbooks.


Sign In or Register to comment.