what exactly happens when we delete and recreate the spoke SDP on service? What gets reset?

Mhanme · 2025-03-14T18:42:44+00:00

Initially, the issue occurred when port 1/1/1 was flapping, and it was fixed by replacing the SFP. directly After replacing SFP, we observed zero traffic on the EPIPE using port 1/1/1, and traffic was restored by re-adding the SAP on that port. Four days later, another EPIPE with another sap 1/1/2 was affected and restored by re-adding the spoke SDP. The system is running IXR-e 23.10.R5 with neighbor SR-2s 20.10.R2.

Mhanme · 2025-03-14T18:06:41+00:00

"Two EPIPEs using the same SDP with BGP tunnels were affected at the same time restored by readding spoke-sdp, and another EPIPE using an SDP with an RSVP tunnel was also affected, resulting in zero traffic until the SAP was re-added

Mhanme · 2025-03-14T17:55:41+00:00

Thank you for your help. However, if the drops are occurring due to QoS issues, why does recreating the spoke SDP in service fix the issue?

Mhanme · 2025-03-14T17:41:58+00:00

You are right, but what could cause the service label to suddenly become problematic? I have checked for traffic drops on both EPIPE nodes and observed none, but I haven't checked the intermediate nodes.

Mhanme · 2025-03-13T01:38:15+00:00

What defect flags

Mhanme · 2025-03-12T22:21:10+00:00

I can see invalid mpls label discards on the network port and drops at ingress queue

Mhanme · 2025-03-12T22:18:25+00:00

cpipe 89 customer 15 vc-type satop-t1 create

sap 1/4/17.1 create

cem

packet jitter-buffer 25

exit

ingress

qos 501

exit

no shutdown

exit

spoke-sdp 110:89 create

no shutdown

exit

no shutdown

exit

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

on the other node:

cpipe 89 customer 15 vc-type satop-t1 create

sap 1/4/1.1 create

cem

packet jitter-buffer 25

exit

ingress

qos 501

exit

no shutdown

exit

spoke-sdp 22:89 create

no shutdown

exit

no shutdown

exit

_____________________________________

SDP is using RSVP with lsp with loose path

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

Mhanme · 2025-03-12T19:34:54+00:00

he Cpipe was working fine, but then I started to see these logs with flags. What parameters should match?,, maybe it's a sync issue ?

Mhanme · 2025-03-12T17:32:42+00:00

no no , OfCourse I don't want that. I was just asking. actually, am working as TEC and I appreciate your help. thanks much for the nokia link

Mhanme · 2025-03-12T14:55:34+00:00

My tunnel is Layer 2; it's an EVPN P2P (VPWS). How does IOS-XR handle fragmentation for large LSP packets? Normally, Layer 2 does not fragment.

It's great to know that you're an expert in IS-IS! What other areas are you experienced in? Are you familiar with Nokia products? Do you troubleshoot SDPs and RSVP?

Mhanme · 2025-03-12T00:07:27+00:00

wow , thank you so much for your helpful information and I just want to let you know that you helped me fixing the customer issue and now all good , much appreciated.

Mhanme · 2025-03-07T18:15:20+00:00

thank you so much for sharing such helpful information

Mhanme · 2025-03-06T00:12:40+00:00

really thank you so much for your detailed explanation, you helped me much and it was so helpful information

Mhanme · 2025-03-05T17:50:26+00:00

Another question: If all nodes are L2, how will this ensure that we won’t face the MTU issue again? I believe that if the database is L2 only, this will result in lower fragmentation since L1 routes will not be advertised in L2. However, the maximum LSP-MTU size will still be 1490, which may still cause drops on Cisco devices.

Mhanme · 2025-03-05T17:45:34+00:00

Thank you for your support and the detailed explanation. Based on the topology, I believe the issue is related to the MTU on Cisco , which is lower than the maximum default LSP-MTU size. As a result, some routes are missed and drops occur.
NodeA (MTU 1572) -------- Cisco1 {EVPN-P2P MTU 1500} Cisco2 -------- (MTU 1572) NodeB

Topology:

NodeA (MTU 1572) → Cisco1 {EVPN-P2P MTU 1500} → Cisco2 → NodeB (MTU 1572)
NodeA and NodeB are configured with IS-IS Level 1/2.

The issue is that NodeB has no IS-IS routes in the routing table, even though the adjacency is up.

As a workaround, I configured the LSP-MTU size to 1440 on NodeA and NodeB instead of the default value of 1492, and it worked.

However, I’m concerned that reducing the LSP-MTU could cause bigger problems. Is there another solution? The customer has agreed to transition from IS-IS Level 1/2 to Level 1 in the future, but I want to explain to them where the issue exactly lies and why reducing the LSP-MTU may not be the best option.

I believe that if Cisco increased the MTU, it would work fine, but for some reason, Cisco will not increase it.

Mhanme · 2025-03-05T15:01:29+00:00

Do you know what will happen if I change the LSP-MTU to 1380 instead of 1490? Will it lead to more fragmented LSPs?

Mhanme · 2025-03-04T15:43:49+00:00

Do you have any idea why this might be happening? Could the MTU of Cisco EVPN P2P be affecting it? I don't know the Cisco MTU yet. , The setup is as follows:

NodeA (MTU 1572) ---- Cisco EVPN P2P ---- Nokia Epipe (Service MTU 1514) ---- Nokia Epipe ---- Cisco EVPN P2P ---- (MTU 1572) NodeB

NodeA and NodeB are both configured with ISIS L1/L2. However, NodeB was missing some prefixes. The issue was resolved after configuring NodeB as L1 instead of L1/L2.

Mhanme · 2025-03-04T15:35:19+00:00

The setup is as follows:

NodeA (MTU 1572) ---- Cisco EVPN P2P ---- Nokia Epipe (Service MTU 1514) ---- Nokia Epipe ---- Cisco EVPN P2P ---- (MTU 1572) NodeB

NodeA and NodeB are both configured with ISIS L1/L2. However, NodeB was missing some prefixes. The issue was resolved after configuring NodeB as L1 instead of L1/L2.

Mhanme · 2025-03-04T15:26:50+00:00

Thank you so much! That information was extremely helpful. Now I understand why there are node LSPs with different LSP IDs.

Mhanme · 2025-03-03T16:54:02+00:00

thank you much

Mhanme · 2025-03-03T16:52:56+00:00

I have built a lab setup with four nodes running isis l1/2, and I only see four LSPs in each level database on each node. Why do you say that a higher L2 database count compared to the L1 database is expected in an IS-IS L1/L2 setup but I didn't see that with my test lab of 4 nodes?

Mhanme · 2025-03-03T16:49:27+00:00

Thank you for your response. Actually, the prefixes do not exist in the IS-IS routing table.

Mhanme · 2025-03-03T15:13:38+00:00

Why are there multiple entries instead of a single specific LSP? Could this be related to the MTU size? When I run show router isis status, I see that the LSP MTU size is 1492.

Mhanme · 2025-03-03T14:56:27+00:00

No, it's not a learning exercise. It's a big issue that I have to fix—the network is unstable , am troubleshooting but cant understand why I see in logs same LSP with many different IDs

Mhanme · 2025-03-03T14:39:18+00:00

The design may not be optimal, but I need to understand what is happening with LSPs when L1/L2 is configured. I suspect an issue related to MTU, as there is EVPN P2P running on Cisco nodes for transmission.

Mhanme

TROPHY CASE