[c-nsp] MPLS interface continuity and OSPF configuration ME-3600X

[Daniel Dib]

Yeah, what I meant was that path from R1 to R4 does not have to be the same as R4 to R1, there could be asymmetric routing depending on the IGP cost of the interfaces.

 

Maybe you could help develop a checklist for the NOC? If they don’t have one already. Check the current best path, do a traceroute, what labels are used. Verify that new interface comes up, MPLS is enabled, do a traceroute, verify new labels and so on.

 

 

From: Eric Louie [mailto:elouie at techintegrity.com] 
Sent: den 2 maj 2015 02:12
To: Daniel Dib
Cc: CiscoNSP
Subject: Re: [c-nsp] MPLS interface continuity and OSPF configuration ME-3600X

 

1. The NOC is always bringing up new circuits.  However, they were not aware that MPLS needed to be enabled on this new circuit (apparently - however, they are now aware that any 3600-3600 link needs to have mpls enabled on both sides)

 

2. I might have mis-stated - mpls ip was not configured on either side of the link, but even if was configured on one side, a "show mpls int" would not have shown that as an MPLS link with Operational Status = yes

 

3.  That was what I was looking for - the relation between the IGP label for the MPLS switched traffic, and the OSPF cost of the preferred route.  That's why the traffic "dead-ended" instead of going through the MPLS-enabled circuit that was still available but had a higher OSFF cost.  (Actually, the old circuit was still up and the OSPF neighbors were still active, even though it was costed higher)

 

On Fri, May 1, 2015 at 1:37 PM, Daniel Dib <daniel.dib at reaper.nu> wrote:

1. Why is your NOC doing changes to your MPLS network?
2. MPLS LSPs are unidirectional so you can have this behaviour in one
direction and not the other.
3. You broke the LSP when you lowered the metric which created a better path
but you did not have MPLS on the interfaces so there was no IGP label for
MPLS switched traffic. The RIB and FIB is what creates the LFIB.

Best regards,

Daniel Dib
Senior Network Architect
CCIE #37149


-----Original Message-----
From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Eric
Louie
Sent: den 1 maj 2015 21:10
To: CiscoNSP
Subject: [c-nsp] MPLS interface continuity and OSPF configuration ME-3600X

I had a strange anomaly happen yesterday

We have 2 ME-3600's as part of an MPLS network.  There are MPLS interfaces
on both sides of them and between them.  so, like this

R1 ---- R2 ---- R3 ---- R4

and all the links between are MPLS IP

My NOC enabled a new circuit between R2 and R3, and "forgot" to use mpls ip
on both interfaces.  When they decreased the OSPF cost on the two interfaces
(as the preferred route), traffic from R1 to R4 stopped at R2.
 (I didn't get the corresponding result R4 to R1, but our monitoring server
is behind R4, and could not reach any devices connected to R1)  The old MPLS
circuit was still connected and enabled, just costed out via OSPF.

So, it "appears" that when the new link was costed in, because it was not an
MPLS link, the traffic didn't know how to get through the new R2-R3 link,
since the MPLS link was now costed out by MPLS.

making the new link an MPLS link solved the problem.

My questions are:
Is this "by design"?  In other words, if we have MPLS links on both sides of
a pair of routers, does that MPLS configuration need to be contiguous
throughout?

Is this a condition of configuring MPLS, that all intermediate paths need to
be either tunnelled or configured?  (something that I might have missed in
my MPLS learning)

Did we run into a bug?  IOS 15.2(4)S

Is this a TAC question?

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/