cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
511
Views
0
Helpful
13
Replies
Highlighted
Beginner

Unable to set up tunnel via PCE

Hi,

I am trying to set up a tunnel on a "Cisco IOS XR Software, Version 6.5.1" router using PCEP.

 

The relevant config pieces are:

interface tunnel-te2000
 ipv4 unnumbered Loopback0
 destination 122.122.122.122
 path-option 1 dynamic pce address ipv4 192.168.2.150
!
...
mpls traffic-eng
 interface GigabitEthernet0/0/0/1
 !
 interface GigabitEthernet0/0/0/2
 !
 pce
  peer source ipv4 10.64.7.3
  peer ipv4 192.168.2.150
  !
 !
!

10.64.7.3 is the router, 192.168.2.150 is a custom PCE implementation.

 

I am able to get the PCEP session set up:

RP/0/RP0/CPU0:SFO-PE-103#show mpls traffic-eng pce peer 
Wed Dec  2 19:39:45.965 UTC
        Address   Precedence        State         Learned From
--------------- ------------ ------------ --------------------
  192.168.2.150          255           Up        Static config

And I am able to send PCReq messages and get back PCRep messages:

RP/0/RP0/CPU0:SFO-PE-103#show mpls traffic-eng pce peer all 
Wed Dec  2 19:41:25.556 UTC

PCE Address 192.168.2.150
State Up
  PCEP has been up for: 00:25:00
Precedence 255
Learned through: 
  Static Config
Sending KA every 30 s
Time out peer if no KA received for 120 s
Tolerance: Minimum KA 10 s

Stateless


KA messages rxed 1944 txed 104
PCEReq messages rxed 0, txed 2840
PCERep messages rxed 2379, txed 0
PCEErr messages rxed 0, txed 0
  Last error received:  None
  Last error sent:  None
PCE OPEN messages: rxed 33, txed 33
PCEP session ID: local 32, remote 0

Average reply time from peer: 0 ms
Minimum reply time from peer: 0 ms
Maximum reply time from peer: 0 ms
0 requests timed out with this peer

However, the tunnel has an issue with being held down:

RP/0/RP0/CPU0:SFO-PE-103#show mpls traffic-eng tunnels 2000
Wed Dec  2 19:40:04.363 UTC


Name: tunnel-te2000  Destination: 122.122.122.122  Ifhandle:0xbc 
  Signalled-Name: SFO-PE-103_t2000
  Status:
    Admin:    up Oper: down   Path: not valid   Signalling: Down

    path option 1,  type dynamic pce 192.168.2.150
    Last PCALC Error: Wed Dec  2 19:17:37 2020
      Info: Path-option is skipped because it is held down
    G-PID: 0x0800 (derived from egress interface properties)
    Bandwidth Requested: 0 kbps  CT0
    Creation Time: Fri Nov  6 21:40:19 2020 (3w4d ago)
  Config Parameters:
    Bandwidth:        0 kbps (CT0) Priority:  7  7 Affinity: 0x0/0xffff
    Metric Type: TE (global)
    Path Selection:
      Tiebreaker: Min-fill (default)
    Hop-limit: disabled
    Cost-limit: disabled
    Delay-limit: disabled
    Path-invalidation timeout: 10000 msec (default), Action: Tear (default)
    AutoRoute: disabled  LockDown: disabled   Policy class: not set
    Forward class: 0 (not enabled)
    Forwarding-Adjacency: disabled
    Autoroute Destinations: 0
    Loadshare:          0 equal loadshares
    Auto-bw: disabled
    Auto-Capacity: Disabled:
    Fast Reroute: Disabled, Protection Desired: None
    Path Protection: Not Enabled
    BFD Fast Detection: Disabled
    Reoptimization after affinity failure: Enabled
    Soft Preemption: Disabled
Displayed 1 (of 11) heads, 0 (of 0) midpoints, 0 (of 1) tails
Displayed 0 up, 1 down, 0 recovering, 0 recovered heads

I am unfamiliar with that error; is it possible that my PCRep may be missing something?

13 REPLIES 13
Highlighted
Cisco Employee

Hi Todd,

 

Can you check if the PCE can properly calculate the path between the head end and tail end using the following command.

 

sh pce ipv4 path source  <head-end loopback address> destination 122.122.122.122

 

Regards,

 

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
Highlighted
Beginner

I basically get an empty response:

RP/0/RP0/CPU0:SFO-PE-103#show pce ipv4 path source 103.103.103.103 destination 122.122.122.122
Thu Dec  3 01:14:26.186 UTC

I think that may be because of this?

RP/0/RP0/CPU0:SFO-PE-103#show pce ipv4 peer 
Thu Dec  3 01:15:02.524 UTC
PCE process may not be running

I only have the PCE configured in mpls traffic-eng.

Highlighted

this is a long walk, but we shall get there

 

I think SF-103 is your PE (PCC client) that is why you are getting

PCE process may not be running

"show PCE .." commands must be executed on PCE server console (192.168.1.150), also can you verify ipv4 topology table "show pce ipv4 topo", if you have proper path information, then standard rsvp/te troubleshooting applies afterwards.

 

If this is for your self-learning, I would suggest SR/PCE/SR-Policy as these are the current technology blocks everyone is learning about 

 

EDIT: Can you get the lsp working by giving explicit paths instead of PCE ?, so we verify that TE related configuration is fine 

 

Regards

Sanjeewa

 

Highlighted

Yes, SF-103 (10.64.7.3) is the PCC in this case and is an IOS-XR router.

The PCE (192.168.2.150) in this case is a custom PCE and not a Cisco device.

So ultimately I am trying to use the IOS-XR device as a PCC and not as a PCE; that might be why the "show pce" commands do not work.  But I would be interested in knowing what additional debug/logging is available as a PCC on the IOS-XR device.

 

I can confirm if I remove the "pce" part of the path option that it correctly finds and brings up the tunnel:

interface tunnel-te2000
 ipv4 unnumbered Loopback0
 destination 122.122.122.122
 path-option 1 dynamic
!
RP/0/RP0/CPU0:SFO-PE-103#show mpls traffic-eng tunnels 2000 brief 
Wed Dec 16 23:35:06.596 UTC

                     TUNNEL NAME         DESTINATION      STATUS  STATE
                   tunnel-te2000     122.122.122.122          up  up
Displayed 1 (of 14) heads, 0 (of 0) midpoints, 0 (of 1) tails
Displayed 1 up, 0 down, 0 recovering, 0 recovered heads

It is once I change the path-option line to "path-option 1 dynamic pce address ipv4 192.168.2.150" that the tunnel does not come up.

 

As mentioned elsewhere, my PCE is able to find the path and returns a PCRep message to the PCC.  But I am wondering if something is missing from that PCRep that the IOS-XR PCC requires; there are a number of objects that are optional for the PCRep message in the RFC that may be required by IOS-XR.


Highlighted

Yes, SF-103 (10.64.7.3) is the PCC in this case and is an IOS-XR router.

The PCE (192.168.2.150) in this case is a custom PCE and not a Cisco device.

So ultimately I am trying to use the IOS-XR device as a PCC and not as a PCE; that might be why the "show pce" commands do not work.  But I would be interested in knowing what additional debug/logging is available as a PCC on the IOS-XR device.

 

I can confirm if I remove the "pce" part of the path option that it correctly finds and brings up the tunnel:

interface tunnel-te2000
 ipv4 unnumbered Loopback0
 destination 122.122.122.122
 path-option 1 dynamic
!
RP/0/RP0/CPU0:SFO-PE-103#show mpls traffic-eng tunnels 2000 brief 
Wed Dec 16 23:35:06.596 UTC

                     TUNNEL NAME         DESTINATION      STATUS  STATE
                   tunnel-te2000     122.122.122.122          up  up
Displayed 1 (of 14) heads, 0 (of 0) midpoints, 0 (of 1) tails
Displayed 1 up, 0 down, 0 recovering, 0 recovered heads

It is once I change the path-option line to "path-option 1 dynamic pce address ipv4 192.168.2.150" that the tunnel does not come up.

 

As mentioned elsewhere, my PCE is able to find the path and returns a PCRep message to the PCC.  But I am wondering if something is missing from that PCRep that the IOS-XR PCC requires; there are a number of objects that are optional for the PCRep message in the RFC that may be required by IOS-XR.

Highlighted
Rising star

Hi,

 

Have you configured MPLS-TE attributes in your MPLS core interfaces?

Best regards,
Abzal
Highlighted

Yes, all of the core interface have the correct settings.  I am able to bring up tunnels if I manually create the explicit path or use the normal dynamic option.  The error appears to come about once I make it use the PCE to get the tunnel path.

Highlighted
Rising star

PCERep should specify why the path couldn't be determined. Is there anything in logs? or turn on debug and I see details there.

Best regards,
Abzal
Highlighted
Beginner

I am running my own PCE on the other end, so I see there that the path is successful.  I am returning a PCRep message with RP, ERO, LSPA, and BANDWIDTH objects.  It is possible I am missing some other required objects.

Which logs should I look in, or what debugging should I turn on, to see more details on the PCC side for why the response is not sufficient?

Highlighted
Beginner

@Abzal, would you be able to offer any advice about which logs or debugging I should look at for the PCEP module?

Highlighted
Beginner

I think a couple of my replies have been erased.  @Sanjeewa Alahakone , were you able to see the responses to your post?

 

Edit: I see my replies now.  Apologies for the double-post above.

Highlighted
Beginner

I think I may have figured it out.  I found the "show mpls traffic-eng pce trace" command, which let me look at the PCEP logs, and I saw the message "P flag [0] should be set for RP object".  It turns out in my PCRep that P-flag for the RP object was still 0; flipping that to 1 solved that issue.

After that change, I still see errors along the lines of "Received unexpected object class [5]".  In that case, it is complaining about the BW object; I also see it for the LSP and LSPA objects; basically it apparently wants the PCRep to only have the RP and ERO objects.  Once I remove all but those objects, I am able to see the path correctly up.

Is there a reason it will not accept a PCRep message with BW/LSP/LSPA objects?  From the RFC, it looks like those objects are allowed to be in a reply.

Highlighted

Any comment on BW/LSP/LSPA objects in the PCRep message?

Content for Community-Ad