R&S v5 Adv TS lab 3 ticket 4

***SPOILER ALERT***

 

Just wondering if anyone knew a troublshooting cmd/logic to determine that the loopback interface of R2 was a /24 rather than the required /32?

 

When running through the tickets I try to assertain the necessary cmds I could use to diagnose this issue, rather than manually checking  using 'show run' if at all possible. e.g. debug ppp negotiation etc or show bgp vpnv4 unicast all summary

 

With this ticket I managed to reach a point where the BGP VPNV4 adjacencies had established and exchanged routes which had been installed in the various VRF RTs.  Each loopback was pingable across the network & correct /32 routes were seen at each peer (due to the LOs being treated by default as stub networks by OSPF). Even the show mpls forwarding-table seemed to look OK on a subset of routers I checked.

 

Is there any obvious show/debug cmd I could/should have used to determine this fault, or, in similar instances is it just best to check manually?

 

Cheers


G

 

 

 

Comments

  • Hi GraemeS and All,

    Is this lab 3 TS ticket 4 from Dave Smith's course?  Looked at Dave Smith video and the tickets don't match up.

    With this ticket I managed to reach a point where the BGP VPNV4 adjacencies had established and exchanged routes which had been installed in the various VRF RTs.  Each loopback was pingable across the network & correct /32 routes were seen at each peer (due to the LOs being treated by default as stub networks by OSPF). Even the show mpls forwarding-table seemed to look OK on a subset of routers I checked.

    To check for an LSP between two PE routers, you could do an mpls ping.  Not sure if this method saves on time.

    For example, where 4.4.4.4 is the mp-bgp peering address:

    R6#ping mpls ipv4 4.4.4.4/32 verbose

    Type escape sequence to abort.

    !    size 100, reply addr 10.1.45.4, return code 3

    !    size 100, reply addr 10.1.45.4, return code 3

    !    size 100, reply addr 10.1.45.4, return code 3

    !    size 100, reply addr 10.1.45.4, return code 3

    !    size 100, reply addr 10.1.45.4, return code 3

    Success rate is 100 percent (5/5), round-trip min/avg/max = 32/55/112 ms

    And if the LSP is broken (/24 vice /32 loopback)

    R6#ping mpls ipv4 4.4.4.4/32 verbose

    Sending 5, 100-byte MPLS Echos to 4.4.4.4/32,

         timeout is 2 seconds, send interval is 0 msec:

    Type escape sequence to abort.

    B    size 100, reply addr 10.1.56.5, return code 9

    B    size 100, reply addr 10.1.56.5, return code 9

    B    size 100, reply addr 10.1.56.5, return code 9

    B    size 100, reply addr 10.1.56.5, return code 9

    B    size 100, reply addr 10.1.56.5, return code 9

    Success rate is 0 percent (0/5)

    //Cheers

  • Cheers Randy. The exact cmd I was looking for :-)

     

    @Martinl -- Sorry for the confusion - I was refering to the v5 wb adv ts labs. 

  • INE R&S wb v5 for this particular example

    Cheers

  • Perfect! Exactly the cmd I was looking for

    Thanks

  • Here is Petr's article on mpls traceroute

    http://blog.ine.com/2008/11/24/mpls-ping-and-traceroute/

    Here with my follow up question:

    Ticket 4 looks complex.  Looking at topology, it appears that there are redundant paths 9-7-1-2 and 9-8-1-2 to check.  I'ld follow up with traceroute; or test both paths in turn by shutting interfaces.

    1) test connectivity with mpls ping

    3) check for redundant paths

    For cisco lab, do we ignore any redundancy?  Experts chime in!


  • I
    believe in this instance although a redundant link exists between r9
    and the two PEs, my traceroutes always directed me via R7.  Normal
    traceroutes from the PE followed the same path R7 - R3 - R4 - R2.


    A
    standard ping  uncovers R2 interfaces were not participating in
    LDP. This was another fix required for the ticket. Once solved the
    full LSP was complete and routes could be negotiated via VPNv4.  


    This
    made the scenario simpler though there is definite scope for adding
    the redundancy issue. My only though would be the labs would be setup
    so that in all instances the test output they provide "R9#ping
    192.122.3.10 source loopback0" MUST work. If ECMP was introduced
    and an issue setup which was only intermittently apparent it may not
    be immediately obvious.


    In
    real-life/production yes its something I'd want to check. In the lab
    though I personally wouldn't bother given the time pressures [:)]


     



     

     

Sign In or Register to comment.