Geek Fight at Work

Ok, a colleague and I, at work, had a discussion on black holes in an MPLS network. The scenario is this: PE router with 2 trunks to the MPLS cloud loses OSPF.

[PE] GE 1/0

(Core router 1)

{MPLS Cloud}
GE 2/0

(Core router 2)

{MPLS Cloud}

OSPF down on both links
LDP and BGP stayed up

My Argument:
If OSPF goes down, and LDP neighbor stays up, customer traffic will be black holed because BGP will have a label to a FEC that does not exist in the routing table. LDP will also have an IP binding to an address that is not in the routing table, thus leaving the router to believe a forwarding path exists across an LSP.

My ENEMIES argument:

IGP has a path. It goes to Label base and says, give me a label for this path. It then gives it to FIB to install for forwarding.
IGP path goes away, path gets removed from LFIB. LFIB takes it away from FIB. Path won’t be picked to forward.

I need to have this concept down before I continue. I cannot go forward if my understanding and interpretation of what I read is wrong.

What say you?

Find more posts tagged with

Comments

KGhaleon

adriansizemore wrote: »

Ok, a colleague and I, at work, had a discussion on black holes in an MPLS network. The scenario is this: PE router with 2 trunks to the MPLS cloud loses OSPF.

[PE] GE 1/0
(Core router 1)
{MPLS Cloud}
GE 2/0
(Core router 2)
{MPLS Cloud}

OSPF down on both links

LDP and BGP stayed up

My Argument:
If OSPF goes down, and LDP neighbor stays up, customer traffic will be black holed because BGP will have a label to a FEC that does not exist in the routing table. LDP will also have an IP binding to an address that is not in the routing table, thus leaving the router to believe a forwarding path exists across an LSP.

My ENEMIES argument:

IGP has a path. It goes to Label base and says, give me a label for this path. It then gives it to FIB to install for forwarding.
IGP path goes away, path gets removed from LFIB. LFIB takes it away from FIB. Path won’t be picked to forward.

I need to have this concept down before I continue. I cannot go forward if my understanding and interpretation of what I read is wrong.

What say you?

<_< >_>

My idea of a Geek fight is unscrewing the drawers on his desk, removing his laptop, taking the hard drive out and decrypting the hard drive, reseting and placing a new password on his BIOS, and rick roll his hard drive to the point where it plays everytime he clicks a button.

rossonieri#1

hi adrian,

IMHO, CMIIW, i think both of you are *correct*, but you two viewed it from a different angle. the point is that you lead to the same destination - BGP still have the LSP hence black hole (connections were up but no forwarding), and if the IGP/OSPF down (L3 information) hence the FIB routes are removed hence no forwarding.

EdTheLad

I'm sorry, i'm a stupid guy as i cant understand your problem description.

cisco_trooper

Lots of things to consider here. When you say BGP stayed up, what exactly are you saying? Are you saying the BGP routes are in the routing table, or they are simply in the BGP table?

Don't forget MPLS reliance on the FIB. Your enemies argument makes more sense to me. May I ask what you read, what book and what page? I am not familiar yet with how BGP and MPLS play together, so I can't discount either point of view at this point. I have been working on MPLS anyway, so I think you just gave me my next lab.

cisco_trooper

EdTheLad wrote: »

I'm sorry, i'm a stupid guy as i cant understand your problem description.

This is good stuff right here....

dynamik

Ultimate geek fight: Lightsaber Underwear Chick Fight [HD]

adriansizemore

You are right, I misspoke. I meant to only imply LDP. BGP is back to the customer CE, which would not be affected. Now, what I dont know is what CEF had as the NH, if any at all. So, my basic argument is this: If you lose both of those links to the cloud, but your LDP neighbor remains up, a label binding still exists to a NH neighbor that is not not in the routing table. If there is an LDP neighbor, which implies a label exchange and FEC binding exists, and there are no routes in the routing table to a next hop address, how will VRFs send data across an LSP when no routes exist? Would CEF know this and simpy not forward the data since it cant get a next hop address?

joey74055

dynamik wrote: »

Ultimate geek fight: Lightsaber Underwear Chick Fight [HD]

Dude! That fight is awesome. You just made my day.

cisco_trooper

adriansizemore wrote: »

You are right, I misspoke. I meant to only imply LDP. BGP is back to the customer CE, which would not be affected. Now, what I dont know is what CEF had as the NH, if any at all. So, my basic argument is this: If you lose both of those links to the cloud, but your LDP neighbor remains up, a label binding still exists to a NH neighbor that is not not in the routing table. If there is an LDP neighbor, which implies a label exchange and FEC binding exists, and there are no routes in the routing table to a next hop address, how will VRFs send data across an LSP when no routes exist? Would CEF know this and simpy not forward the data since it cant get a next hop address?

Are you saying you are losing the physical links, or are we still talking about losing the OSPF neighborships, and any resultant routes? I assume we are talking about losing the OSPF neighbors as in your original post. The LFIB depends of the FIB, so if you lose your layer 3 routing information, those next hops get removed from the FIB, and consequently the label bindings should be removed from the LFIB. That is my limited understanding of MPLS at this point.

APA

I'm still not following your explanation.... are you implying that LDP is establishing\remaining up to a LDP neighbour....when the IGP doesn't have a route to that LDP neighbour?

I think in this situation your 'enemy' is correct..... As trooper mentioned the LFIB relies on the FIB information......

networker050184

cisco_trooper wrote: »

Are you saying you are losing the physical links, or are we still talking about losing the OSPF neighborships, and any resultant routes? I assume we are talking about losing the OSPF neighbors as in your original post. The LFIB depends of the FIB, so if you lose your layer 3 routing information, those next hops get removed from the FIB, and consequently the label bindings should be removed from the LFIB. That is my limited understanding of MPLS at this point.

That would be my assumption as well, but if you want to know for sure just lab it up.

adriansizemore

I guess therein lies the question, do you lose your ldp neighbor peer when you lose the IGP?

From my observations of the network layout, the physical links did not go down, they just took heavy errors, the LDP neighbors remained up while the IGP remained down for over 30 seconds. Now, I wont throw in timers and things like that, just speaking from a protocol point of view, shouldn't the LDP lose it's neighbors if IGP goes down? If LDP remains up, and IGP goes down, does CEF continue to forward because it thinks there is a label to a FEC becuase LDP still has a binding? Or, in the time span of 30 seconds, will CEF detect the loss of IGP neighbors and withdraw any top labels to that next hop?

adriansizemore

or do i have the concepts so fowled up, i am speaking crazy talk?

networker050184

adriansizemore wrote: »

I guess therein lies the question, do you lose your ldp neighbor peer when you lose the IGP?

From my observations of the network layout, the physical links did not go down, they just took heavy errors, the LDP neighbors remained up while the IGP remained down for over 30 seconds. Now, I wont throw in timers and things like that, just speaking from a protocol point of view, shouldn't the LDP lose it's neighbors if IGP goes down? If LDP remains up, and IGP goes down, does CEF continue to forward because it thinks there is a label to a FEC becuase LDP still has a binding? Or, in the time span of 30 seconds, will CEF detect the loss of IGP neighbors and withdraw any top labels to that next hop?

Weather the LDP neighbor goes down would depend on how the route to the LDP neighbors address is learned. Most likely it will be a loopback so the LDP neighbor will go down when the IGP goes down unless you have static routes in place.

Like stated earlier the LFIB is built from the FIB. So when the IGP goes down, the routes are removed from the FIB and therefore removed from the LFIB. I'm not sure about the exact time it will take, but it should take less than 30 seconds for the whole process to update. I'm sure during the reconvergance some traffic will be black holed though.

rossonieri#1

hi adrian,

i've found this for reading, perhaps it can help you a little bit :
MPLS Label Distribution Protocol (LDP) - Cisco Systems

APA

adriansizemore wrote: »

I guess therein lies the question, do you lose your ldp neighbor peer when you lose the IGP?

From my observations of the network layout, the physical links did not go down, they just took heavy errors, the LDP neighbors remained up while the IGP remained down for over 30 seconds. Now, I wont throw in timers and things like that, just speaking from a protocol point of view, shouldn't the LDP lose it's neighbors if IGP goes down? If LDP remains up, and IGP goes down, does CEF continue to forward because it thinks there is a label to a FEC becuase LDP still has a binding? Or, in the time span of 30 seconds, will CEF detect the loss of IGP neighbors and withdraw any top labels to that next hop?

As networker explained - depends on the topology of your network.... by your quick text diagram it doesn't look like you have multiple paths for the ldp neighbours...so when the IGP drops your LDP neighbours should drop as well, maybe not immediately but they should drop.... (Unless they are directly connected... which I doubt...)

Without a route to the LDP neighbour the LDP peering is irrelevant as they have no path to talk over...