Routing

 View Only
last person joined: 6 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.  MPLS-TE: LSP not brought down immediately when transit hop goes down

    Posted 07-16-2010 02:44

    Hi,

          I'm new to Junos but have a decent understanding of other vendor's MPLS-TE configurations.

          I've configured an Ingress LSP on Junos with OSPF as IGP [Traffic-engineering enabled]. The destinaion is 3 hops away.

     

    Sample config:

    [edit protocols mpls]
    root@mp-m7-1# show
    label-switched-path test2 {
        from 100.2.1.17;
        to 192.168.20.2;
        bandwidth 100m;
        primary pri_link1;
    }
    path pri_link1 {
        192.168.10.2 strict;
        192.168.20.2 strict;
        172.16.20.2 strict;
    }
    interface ge-0/0/0.0;
    interface ge-0/1/0.0;

    [edit protocols mpls]
    root@mp-m7-1#

     

    After the LSP is up, if the link with ip "192.168.20.2" goes down, the LSP is not brought down immediately. Ingress continues to send refresh message eventhough downstream rejects it with PATH_ERROR. After ~3 minutes, the LSP times-out & is brought down.

     

    Is there any cli that needs to be configured to make the LSP go down immediately on receiving PATH_ERROR from downstream LSR?

     

    For the same case on one of the MPLS-TE vendor as ingress[Cisco], the tunnel is brought down immediately.

     

    Thanks,

    VijayKumar Arumugam


    #MPLS
    #rsvp
    #cspf


  • 2.  RE: MPLS-TE: LSP not brought down immediately when transit hop goes down

    Posted 07-17-2010 09:39

    Hello,

    Do you have a firewall filter assigned to Your mp-m7-1 lo0.0?

    It looks like PathErr packets are not actually received by ingress LSR.

    HTH

    Regards

    Alex

     



  • 3.  RE: MPLS-TE: LSP not brought down immediately when transit hop goes down

    Posted 07-19-2010 05:01

    Hi Alex,

             I've not configured any firewall filters.

             Please check the below o/p where the ingress receives PATH_ERROR repeatedly from downstream router. I'm not sure why it signals LSP eventhough CSPF computation has failed.

     

    [scenario - Bring up LSP & later reduce bandwidth on transit link so that it doesn't match LSPs requested bandwidth].

     

    root@mp-m7-1# run show mpls lsp extensive    
    Ingress LSP: 1 sessions

    192.168.20.2
      From: 100.2.1.17, State: Up, ActiveRoute: 0, LSPname: test2
      ActivePath: pri_link1 (primary)
      LSPtype: Static Configured
      LoadBalance: Random
      Encoding type: Packet, Switching type: Packet, GPID: IPv4
     *Primary   pri_link1        State: Up
        Priorities: 7 0
        Bandwidth: 100Mbps
        SmartOptimizeTimer: 180
        Reoptimization in 111 second(s).
        Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 2)
     192.168.10.2 S 192.168.20.2 S
        Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
              192.168.10.2 192.168.20.2
       16 Jul 17 06:13:03.414 CSPF failed: no route toward 192.168.20.2
       15 Jul 17 06:13:03.400 100.2.1.1: Requested bandwidth unavailable[3 times]
       14 Jul 17 06:12:50.182 CSPF failed: no route toward 192.168.20.2
       13 Jul 17 06:12:50.182 100.2.1.1: Requested bandwidth unavailable[4 times]
       12 Jul 17 06:12:34.501 CSPF failed: no route toward 192.168.20.2
       11 Jul 17 06:12:30.973 100.2.1.1: Requested bandwidth unavailable[2 times]
       10 Jul 17 06:12:21.345 CSPF failed: no route toward 192.168.20.2
        9 Jul 17 06:12:21.344 100.2.1.1: Requested bandwidth unavailable
        8 Jul 17 06:12:04.540 CSPF failed: no route toward 192.168.20.2[2 times]
        7 Jul 17 06:11:36.784 100.2.1.1: No Route toward dest
        6 Jul 17 06:07:41.876 Selected as active path
        5 Jul 17 06:07:41.864 Record Route:  192.168.10.2 192.168.20.2
        4 Jul 17 06:07:41.842 Up
        3 Jul 17 06:07:41.585 Originate Call
        2 Jul 17 06:07:41.585 CSPF: computation result accepted  192.168.10.2 192.168.20.2
        1 Jul 17 06:07:12.294 CSPF failed: no route toward 192.168.10.2[4 times]
      Created: Sat Jul 17 06:05:41 2010
    Total 1 displayed, Up 1, Down 0
    Egress LSP: 0 sessions
    Total 0 displayed, Up 0, Down 0

    Transit LSP: 0 sessions
    Total 0 displayed, Up 0, Down 0

    [edit]
    root@mp-m7-1#

    Thanks,

    Vijaykumar Arumugam



  • 4.  RE: MPLS-TE: LSP not brought down immediately when transit hop goes down

    Posted 07-19-2010 07:18

    Hello,

    What "show rsvp statistics" tell You about PathErr messages?

    I doubt You will receive any PathErr if BW is reduced but Path and Resv Refresh are still getting thru OK. In this case, by default, in 180 secs the LSP will attempt to reoptimise and probably fail if You have no backup path.

    HTH

    Regards

    Alex



  • 5.  RE: MPLS-TE: LSP not brought down immediately when transit hop goes down

    Posted 07-19-2010 11:23

    Hi Alex,

             As you mentioned, Juniper doesn't send PathErr for bandwidth reduction [never knew about this]. I checked Cisco IOS behavior & they seem to send PathErr.

     

    [Off Topic] I was wondering what would JunOS do for the below case:

    LAG/Port-channel with say 10 members and assume that it has 1000 RSVP reservations [each member can support 100 reservations]. If 4 member links goes down, will Juniper send PathErr to the 400 affected reservations or do nothing?

     

    [Back to Topic]

    I was under the impression that if reoptimization fails, the LSP will not be signaled. The issue that i mentioned is not seen if Cisco is used as Transit. The only difference that i see between this non-cisco-vendor and cisco is, ResvTear is not sent by this non-cisco-vendor & it only sends PathErr [whereas cisco sends both PathErr & ResvTear]. Have to look at RSVP RFC to see what it recommends for this scenario.

     

    Thanks,

    VijayKumar Arumugam



  • 6.  RE: MPLS-TE: LSP not brought down immediately when transit hop goes down

    Posted 07-19-2010 13:20

    Hello there,

    To answer your off-topic question:

    -- if 4 members of 10-member LAG go down, the total link bandwidth and available link bandwidth will be adjusted down in TED.

    And when reoptimization timer fires, the ingress LSR will attempt to resignal LSP along more suitable route provided it exists.

    You can play with timers and optimize-aggressive knob to achieve better convergence. 

    HTH

    Regards

    Alex



  • 7.  RE: MPLS-TE: LSP not brought down immediately when transit hop goes down

    Posted 07-20-2010 01:56

    Thanks Alex for answering the off-topic question.

     

    I searched through RSVP RFCs and found this...

    http://www.ietf.org/rfc/rfc5711.txt
    Node Behavior upon Originating and Receiving Resource Reservation
                      Protocol (RSVP) Path Error Messages
    
    
    2.2.  Behavior at Receiving Nodes
    
       Nodes that receive PathErr messages are all of the nodes along the
       path of the TE LSP upstream of the node that detected the error.
       This includes the head-end node.  In accordance with Section 3.7.1 of
       [RFC2205], a node receiving a PathErr message takes no action upon
       it, and consequently the node must not clear Path or Resv control-
       plane or data-plane state.  This is true regardless of whether the
       error condition reported by the PathErr is fatal or non-fatal.  RSVP
       states should only be affected upon receiving a PathTear or ResvTear
       message, or in the event of a Path or Resv state timeout.  Further
       discussion of the processing of these events is outside the scope of
       this document.
    
       Note that [RFC3473] defines a Path_State_Removed flag in the
       ERROR_SPEC object carried on a PathErr message.  This field may be
       set to change the behavior of upstream nodes that receive the PathErr
       message.  When set, the flag indicates that the message sender has
       removed Path state (and any associated Resv and data-plane state) for
       the TE LSP.  The message receiver should do likewise before
       forwarding the message, but may retain state and clear the flag
       before forwarding the message.
    
    

     

    It seems that the non-cisco-vendor is sending PathErr with 'Path_State_Removed' flag set which is sufficient to clear reservations along the path [thats why it didn't send ResvTear]. Is there a way to check whether Junos officially support this RFC [or parts of this RFC]?.

     

     

    Thanks,

    VijayKumar Arumugam



  • 8.  RE: MPLS-TE: LSP not brought down immediately when transit hop goes down
    Best Answer

    Posted 07-20-2010 03:42

    There is a section in Juniper techdocs titled "Hierarchy and standards reference"

    Direct link to JUNOS 10.2 release Hierarchy and standards reference

    http://www.juniper.net/techpubs/en_US/junos10.2/information-products/topic-collections/reference-hierarchy/noframes-collapsedTOC.html

    If you drill down to MPLS standards, then to RSVP standards, you will see that RFC5711 is not listed.

    And this means "not supported". Conversely, what is listed is supported (with caveats explicitly described if any).

    HTH

    Regards

    Alex



  • 9.  RE: MPLS-TE: LSP not brought down immediately when transit hop goes down

    Posted 07-20-2010 12:11

    Thanks Alex, appreciate your help.

     

    Regards,

    VijayKumar Arumugam



  • 10.  RE: MPLS-TE: LSP not brought down immediately when transit hop goes down

    Posted 07-22-2010 16:52

     

     

    I don’t know if this is helpful but you might look at the rsvp-error-hold-time configuration statement.

     

    When you configure the rsvp-error-hold-time statement, two categories of PathErr

    messages, which specifically represent link failures, are examined.

     

    Here is a link to the Juniper documentation describing this.

     

    http://www.juniper.net/techpubs/en_US/junos9.6/information-products/topic-collections/config-guide-mpls-applications/mpls-improving-ted-accuracy-with-rsvp-patherr-messages.html#jd0e7072

     

    Regards

    Roy