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

[Jeff Aitken]

Instead of autoconfig, I've always used LDP/IGP synchronization.  This prevents the exact problem you are running into by setting the IGP metric to the max value if the IGP and LDP aren't in sync (e.g., if you've forgotten to enable MPLS on an interface).  See http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_ldp/configuration/15-sy/mp-ldp-15-sy-book/mp-ldp-igp-synch.html for more info.

Peer-review of configs is obviously a great idea, but you will still run into cases where this might help.  For example, your NOC might be troubleshooting link issues and try removing parts of the config or perhaps moving configs to a new interface, etc.  If you end up with IP but no MPLS enabled, and you've got synchronization enabled, the link simply doesn't get used unless there are no other possible paths, which usually helps highlight the problem.


--Jeff

Sent from my iPad

> On May 1, 2015, at 20:14, Eric Louie <elouie at techintegrity.com> wrote:
> 
> I'll just review the configs before they're implemented from now on.
> Auto-config seems to be a little too dangerous, and still requires
> configuration, which mpls ip does when they add it to both sides.
> 
>> On Fri, May 1, 2015 at 1:50 PM, Andrew Brant <andrew.brant at me.com> wrote:
>> 
>> 
>> http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/5_x/nx-os/mpls/configuration/guide/mpls_cg/mp_ldp_autoconfig.html
>> 
>> I'd look into enabling the OSPF LDP auto-config feature to prevent another
>> NOC induced outage
>> 
>> Sent from my iPhone
>> 
>>> On May 1, 2015, at 14:09, Eric Louie <elouie at techintegrity.com> wrote:
>>> 
>>> 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/
> _______________________________________________
> 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/