Reliable Static Routing with Enhanced Object Tracking

Hello everyone,

I am just starting to go thought the new v5 lab book and I noticed some of my output is not the same as the verification tasks / screens in the workbook.  I am not sure how important it is to make sure my output matches 100%.  The reason I ask is that in the Reliable Static Routing with Enhanced Object Tracking verfication section is that when I do a traceroute I don't get all the results I expected?

I know it little thing but I thought I would share:

Under the section in which you shutdown the port gi1.146 on R1 so the route changes to go via R5 then to R1 - As shown below

R4#traceroute 150.1.1.1 source 150.1.4.4

 

Type escape sequence to abort.

Tracing the route to 150.1.1.1

 

  1 155.1.0.5 28 msec 28 msec 28 msec

  2 155.1.0.1 56 msec *  56 msec

!

R4#show ip route 150.1.1.1

Routing entry for 150.1.1.1/32

  Known via "static", distance 2, metric 0

  Routing Descriptor Blocks:

  * 155.1.0.1

      Route metric is 0, traffic share count is 1

 

However my results do not show the trace going via R5 but CEF and the RT table does

 

Before the port shut - CEF output

 

R4#sh ip cef 150.1.1.1

150.1.1.1/32

  nexthop 155.1.146.1 GigabitEthernet1.146

R4#

 

After port shut - CEF output

 

R4#sh ip cef 150.1.1.1

150.1.1.1/32

  nexthop 155.1.0.1 Tunnel0

R4#

 

So I can see it is going the right way

      150.1.0.0/32 is subnetted, 2 subnets

S        150.1.1.1 [2/0] via 155.1.0.1

 

However my trace is not the same - This is the workbook version

 

R4#traceroute 150.1.1.1 source 150.1.4.4

 

Type escape sequence to abort.

Tracing the route to 150.1.1.1

 

  1 155.1.0.5 28 msec 28 msec 28 msec

  2 155.1.0.1 56 msec *  56 msec

!

And this is my results - It seems it is dropping the first trace?

 

R4#traceroute 150.1.1.1 so 150.1.4.4

Type escape sequence to abort.

Tracing the route to 150.1.1.1

VRF info: (vrf in name/id, vrf out name/id)

  1  * 

    155.1.0.1 7 msec * 

R4#

 

Everything else works fine - So should I worry about things like this?

Many thanks

 

John [:)]

Comments

  • Hi,

    The following traceroute test looks fine (copy-pasted from your post) :

    R4#traceroute 150.1.1.1 source 150.1.4.4

     

    Type escape sequence to abort.

    Tracing the route to 150.1.1.1

     

      1 155.1.0.5 28 msec 28 msec 28 msec

      2 155.1.0.1 56 msec *  56 msec

    but for this one I am not sure :

    R4#traceroute 150.1.1.1 so 150.1.4.4

    Type escape sequence to abort.

    Tracing the route to 150.1.1.1

    VRF info: (vrf in name/id, vrf out name/id)

      1  * 

        155.1.0.1 7 msec * 

    R4#

    Did the 2nd traceroute act like this just once or was it constantly showing only R1's tunnel0 address ?

    Did your question/post refer to 2nd traceroute ?

     

  • Hi Ciprian,

     

    It's my traceroute in the 2nd output - Which is incorrect - I am unsure as to why? - The 1st Trace is from the workbook - They don't match - I am unsure why?  - Mine are always the same

  • Hi John,

    I am unsure of why the first hop is not appearing in the traceroute output, there may be some sort of icmp/udp filtering on R5 ?

    However, we have some tools available at our disposal to check whether traffic is reaching the proper destination : 

     

    • debug ip icmp on R1,R4 and R5
    • debug ip packet detail on the same 
    After enabling the debug commands just ping command for final destination, with only 1 packet repeat count - easier to read the debug.


    Also, debug ip packet detail should provide good info on when issuing traceroute for final destination.



     

  • Hi,

    My solution is a bit different.

    - Why is there a threshold configured in the solution? I assume that we can set the threshold to an arbitrary number since it was not mentioned in the task description?

    - I used the following config to track the reachability: "track 1 ip sla 1 reachability". The command reference states the following:

    State

    OK

    (all other return codes)

    Up

    Down

    Reachability

    OK or over threshold

    (all other return codes)

    Up

    Down

    With the proposed solution from INE the over threshold return code would result in the "Down" state. The task description asks for ICMP reachability and does not mention RTT threshold.

    http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp/command/iap-cr-book/iap-t1.html#wp3115224200

    I think that either task description, or solution should be changed or did I oversee anything?

  • Florian: I am also puzzled on the usage of the "threshold 2000" command for the ip sla in which the workbook task did not specify to use this. Could this supposed to be an optional parameter or typo?

    All: The following task mentioned to use Ethernet connection but solution given in workbook is source interface and not source ip? If I am using source-ip command it is also deemed to be correct right? Need advise please.

    Workbook task:
    use SLA and Object Tracking to ensure the route is valid as long as ICMP connectivity exists between R1 and R4's Ethernet connection.

    Workbook solution:
    icmp-echo 155.1.146.1 source-interface GigabitEthernet1.146

    My own solution:
    icmp-echo 155.1.146.1 source-ip 155.1.146.4

Sign In or Register to comment.