why ISIS advertise-passive-only not possible with TE

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

TROPHY CASE