[c-nsp] MPLS interface continuity and OSPF configuration ME-3600X
Eric Louie
elouie at techintegrity.com
Fri May 1 20:12:15 EDT 2015
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/
>
>
More information about the cisco-nsp
mailing list