Routing

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

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

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

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

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

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

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

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

Thanks Alex, appreciate your help.

Regards,

VijayKumar Arumugam

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