12-02-2020 11:42 AM
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?
12-02-2020 04:48 PM
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,
12-02-2020 05:16 PM
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.
12-16-2020 03:07 PM - edited 12-16-2020 03:11 PM
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
12-16-2020 03:37 PM - edited 12-16-2020 03:38 PM
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.
12-16-2020 04:09 PM
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.
12-08-2020 01:23 AM
Hi,
Have you configured MPLS-TE attributes in your MPLS core interfaces?
12-08-2020 09:06 AM
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.
12-08-2020 08:57 PM
PCERep should specify why the path couldn't be determined. Is there anything in logs? or turn on debug and I see details there.
12-09-2020 09:21 AM
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?
12-16-2020 01:26 PM
@Abzal, would you be able to offer any advice about which logs or debugging I should look at for the PCEP module?
12-16-2020 06:26 PM - edited 12-17-2020 09:14 AM
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.
12-21-2020 02:47 PM - edited 12-21-2020 02:48 PM
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.
01-05-2021 10:52 AM
Any comment on BW/LSP/LSPA objects in the PCRep message?
03-25-2021 03:12 PM
Hello,
I use below command useful to validate if PCC can establish a session with PCE :
show segment-routing traffic-eng pcc ipv4 peer
In my virtual lab, here is an example :
RP/0/0/CPU0:A1-XR22#show segment-routing traffic-eng pcc ipv4 peer
Thu Mar 25 22:08:04.976 UTC
PCC's peer database:
--------------------
Peer address: 10.10.10.10, Precedence: 255, (best PCE)
State up
Capabilities: Stateful, Update, Segment-Routing, Instantiation
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: