Routing

last person joined: 5 days ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  rsvp and cspf

    Posted 04-10-2012 03:06
      |   view attached

    Hi guys!


    I have a question about rsvp when one router set up a LSP.

    Here is a example

    IGP is isis and all the routers have all the routes. The family mpls is configured on the interfaces, but only the red links in the topology was configured under [protocol mpls] and [protocol rsvp]

     

    I set up a LSP from r1 to r5 and use a no-cspf option on R1.
    The LSP is not established succeefully.
    Here is the error information from traceoption on R1:
    Apr 4 18:21:13.605729 RSVP PathErr to client
    Apr 4 18:21:58.607909 RSVP PathErr to client
    Apr 4 18:22:43.608813 RSVP PathErr to client
    Apr 4 18:23:28.611029 RSVP PathErr to client
    Apr 4 18:24:13.612339 RSVP PathErr to client
    Apr 4 18:24:58.613559 RSVP PathErr to client
    Apr 4 18:25:43.614860 RSVP PathErr to client
    Apr 4 18:26:28.617088 RSVP PathErr to client
    Apr 4 18:27:13.618841 RSVP PathErr to client

     


    now i configured a named path test on R1
    it constains two strict nodes
    R3 strict
    R5 strict


    what i see now is R1 can send Path message to R3, R3 forwarded it to R4, then the problem occurs , because the address in ERO is not one of R4's address, so R4 send a PattErr massage.

     

    what confused me is:
    why R3 forwarded the Path packet to R4, it should forward the packet to R5 based on its igp routing table even though the link between r4 and r5 is not configured under mpls and rsvp.

     

     

    ThankS!



  • 2.  RE: rsvp and cspf

    Posted 04-11-2012 00:22

    Are you sure if R3 is forwarding path message to R4?
    I just cheked in lab and not seeing this behavior.

    In lab, since interface to R5 is not part of rsvp/mpls, R3 itself is sending back the error.

    1. From tcpdump , no rsvp path message to R4.

     

    lab@Haf-Arun-re1# run monitor traffic interface fe-1/0/2.30 size 1500    
    verbose output suppressed, use <detail> or <extensive> for full protocol decode
    Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
    Address resolution timeout is 4s.
    Listening on fe-1/0/2.30, capture size 1500 bytes
    
    Reverse lookup for 224.0.0.5 failed (check DNS reachability).
    Other reverse lookup failures will not be reported.
    Use <no-resolve> to avoid reverse lookups on IP addresses.
    
    06:24:41.067950  In IP 30.30.30.1 > 224.0.0.5: OSPFv2, LS-Update, length 92
    06:24:41.756728 Out IP 30.30.30.2 > 224.0.0.5: OSPFv2, Hello, length 48
    06:24:42.070981 Out IP 30.30.30.2 > 224.0.0.5: OSPFv2, LS-Ack, length 44
    06:24:43.030094 Out IP 30.30.30.2 > 224.0.0.5: OSPFv2, LS-Update, length 60
    06:24:44.033464  In IP 30.30.30.1 > 224.0.0.5: OSPFv2, LS-Ack, length 44
    06:24:45.331681  In IP 30.30.30.1 > 224.0.0.5: OSPFv2, Hello, length 48
    06:24:49.431532 Out IP 30.30.30.2 > 224.0.0.5: OSPFv2, Hello, length 48
    06:24:53.563404  In IP 30.30.30.1 > 224.0.0.5: OSPFv2, Hello, length 48
    06:24:59.418963 Out IP 30.30.30.2 > 224.0.0.5: OSPFv2, Hello, length 48
    06:25:02.268963  In IP 30.30.30.1 > 224.0.0.5: OSPFv2, Hello, length 48
    06:25:08.991457 Out IP 30.30.30.2 > 224.0.0.5: OSPFv2, Hello, length 48
    06:25:11.278604  In IP 30.30.30.1 > 224.0.0.5: OSPFv2, Hello, length 48
    06:25:17.749075 Out IP 30.30.30.2 > 224.0.0.5: OSPFv2, Hello, length 48
    06:25:19.232007  In IP 30.30.30.1 > 224.0.0.5: OSPFv2, Hello, length 48
    06:25:27.198653  In IP 30.30.30.1 > 224.0.0.5: OSPFv2, Hello, length 48
    06:25:27.379556 Out IP 30.30.30.2 > 224.0.0.5: OSPFv2, Hello, length 48
    06:25:36.329655  In IP 30.30.30.1 > 224.0.0.5: OSPFv2, Hello, length 48
    06:25:37.135011 Out IP 30.30.30.2 > 224.0.0.5: OSPFv2, Hello, length 48

     2. Bad strict route reported by R3

     

    lab@Haf-Arun-re1# run show mpls lsp logical-system 1HLR extensive 
    Apr 11 06:24:24
    Ingress LSP: 1 sessions
    
    4.4.4.4
      From: 1.1.1.1, State: Dn, ActiveRoute: 0, LSPname: test
      ActivePath: (none)
      LSPtype: Static Configured
      LoadBalance: Random
      Encoding type: Packet, Switching type: Packet, GPID: IPv4
      Primary   test             State: Dn
        Priorities: 7 0
        SmartOptimizeTimer: 180
        2 Apr 11 06:24:02.740 20.20.20.2: Explicit Route: bad strict route[7 times] >>>> By R3
        1 Apr 11 06:21:38.728 Originate Call
      Created: Wed Apr 11 06:21:38 2012

     


    Can you please enable traceoptions in R3/R4 and check?
    Also check "show mpls lsp extensive" on ingress router?


    - Arun Kumar S



  • 3.  RE: rsvp and cspf

    Posted 04-11-2012 00:49

    Hi,

     

    Agree with Arun I think R3 will send traffic directly to R5 not R4. Could you confirm by using the following command on R1

     

    show mpls lsp ingress detail

     

    it will display the path exactly check every IP in the path to confirm is R3 send traffic to R5 directly or to R4

     

    Regards,

     

    Mohamed Elhariry

     

    JNCIE-M/T # 1059, CCNP & CCIP

     

    ----------------------------------------------------------------------------------------------------------------------------------------

    If this post was helpful, please mark this post as an "Accepted Solution".Kudos are always appreciated!

     



  • 4.  RE: rsvp and cspf

    Posted 04-11-2012 02:12

    Hi Mohamed Elhariry

     

    R3 will not send to R5 as rsvp/mpls is not enabled on that link , instead R3 should send back an error...

     

    - Arun



  • 5.  RE: rsvp and cspf

    Posted 04-11-2012 02:49

    Hi Arun,

     

    What I believe R3 will send directly to R5 based on IGP and as per Krenjt he mentioned R4 send the error which suppose no traffic passed from R3 to R4

     

    To make it work just configure ERO to R3 either loose or strict then R4 or adjust IGP cost to grantee in the traceroute from R1 to R5 will take the expected path (R1--> R3--> R4 --> R5)

     

    BR

    Mohamed Elhariry



  • 6.  RE: rsvp and cspf

    Posted 04-12-2012 18:52
      |   view attached

    Thank you guys, sorry for replying so late


    First i want to say, i did the test on olive not a real router.

     

    The attachment is the traceoption from R4 and show mpls lsp ingress extensive on R1
    obviously, R4 received a Path message from R3 and it sent a PathErr to R3.

    Attachment(s)

    txt
    output.txt   2 KB 1 version


  • 7.  RE: rsvp and cspf
    Best Answer

    Posted 04-13-2012 06:03
    Hi I think it is routing problem could you try to do trace route from R1 to R5 egress IP in the LSP or do show route for the R5 egress IP at R3 itself and see the result


  • 8.  RE: rsvp and cspf

    Posted 04-13-2012 08:02
    Hi,thank you very much, you are right. a wrong interface was configured under protocol Isis on r5, so r3 did not establish a adjacency with r5 and r3 chooses r4 as its next hop to r5. As jstar mentioned, r3 sent a patherr to r1. Thanks.