cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1259
Views
0
Helpful
4
Replies

Why an LSP broken path results in some applications not working and some yes?

Vadym Belyayev
Level 1
Level 1

Hello guys,

I could never completely understand this point. This seems a bit contradictory for me.

1. On one hand there is an affirmation that "At a minimum, the LSP must never be interrupted; this means that the LSP must always have an incoming label and an outgoing label in the LFIB pointing to the correct next-hop label switching router (LSR)"
I dont understand, does this affirmation refer to a situation when you have 1 portion of the network which does not know how to reach another portion of the network except of by using an LSP created by MPLS?

2. For example I do have a network that is converged using OSPF and I created some RSVP tunnels (not full mesh of RSVP tunnel as the book suggests, otherwise it would not work) and I had many implicit-null situations, which resulted in traffic being blackholed (this term also confuses me, what is it?) When I enabled LDP over my RSVP tunnels, everything started to work correctly and as far as I understand this happens because of the complete labeling process along the whole path from the source to destination

I still do not understand this though, if there is a mandatory condition that every packet should be labeled across the LSP, why the implicit-null stuff exists after all if it causes some packets not being able to reach their destination, and what are the situations/scenarios when

a) I can definetly say that my problem is that my traffic is not being tagged across the path and thats why it is being lost

b) I can leave some portion of the network with tagging and another without?

****It is a bit difficult for me, because I have never seen a real ISP network, I have a moderate size MAN network, where every customer is visible to one another, so there is no need to hide customers networks.

4 Replies 4

Nagendra Kumar Nainar
Cisco Employee
Cisco Employee

Hi,

1. On one hand there is an affirmation that "At a minimum, the LSP must never be interrupted; this means that the LSP must always have an incoming label and an outgoing label in the LFIB pointing to the correct next-hop label switching router (LSR)"
I dont understand, does this affirmation refer to a situation when you have 1 portion of the network which does not know how to reach another portion of the network except of by using an LSP created by MPLS?

<Nagendra> One of the main characteristics that made MPLS very successful is - the transit core nodes does not require to understand or support the MPLS service. For example, L3VPN - Only the edge nodes are required to understand the customer prefixes and the VRF to whcih it belongs to. But the transit/core node does not require to understand or populate its forwarding table with customer prefix details. This requires that ingress PE will use the label that egress PE assigns for the customer prefix (which is not known to the core) and on top of it, it will use the label to reach egress PE (whcih is known to the transit nodes). But if the LSP to reach egress PE is not end-to-end (In other words, the LSP is broken in between), a transit node cannot use the bottom label or the IP address in the IP header to forward it to the right customer premises. Same holds true for other MPLS services like L2VPN. So the basic requirement for successful MPLS service is, the LSP between PE should be end-to-end.

2. For example I do have a network that is converged using OSPF and I created some RSVP tunnels (not full mesh of RSVP tunnel as the book suggests, otherwise it would not work) and I had many implicit-null situations, which resulted in traffic being blackholed (this term also confuses me, what is it?) When I enabled LDP over my RSVP tunnels, everything started to work correctly and as far as I understand this happens because of the complete labeling process along the whole path from the source to destination

<Nagendra> I remember seeing some discussion around this from you in earlier post. If the RSVP tunnel is established between PE (ingress to egress), you may not need LDP to be established over the TE tunnel (assuming you use MP-BGP to exchange the VPN label informations for customer prefixes). But if the tunnel is terminating on any transit node, then it requires to have LDP established. 

I still do not understand this though, if there is a mandatory condition that every packet should be labeled across the LSP, why the implicit-null stuff exists after all if it causes some packets not being able to reach their destination, and what are the situations/scenarios when

<Nagendra> imp-null is still part of MPLS forwarding. It happens only when the nexthop is the originator of the prefix. This avoids the last hop node to perform additional label POPs. But it does not break the end-to-end LSP.

a) I can definetly say that my problem is that my traffic is not being tagged across the path and thats why it is being lost

b) I can leave some portion of the network with tagging and another without?

<Nagendra> It depends on what type of service you want to provide. If MPLS is used only for label switching the packets and still all transit nodes will have the prefix information of all customers, you can have it in a way that some portion of network are labelled and others are not. But you may not have any value add with such design> But you could use it as a kind of incremental upgrade if some nodes support MPLS while others doesnot and you plan to upgrade those at later point in time. On the same line, if the service you provide (or plan to provide over this MPLS network) is L3VPN or L2VPN, end-to-end LSP is required.

HTH,

Nagendra

Nagendra, thank you. I will separate my questions with number if you dont mind

1. My topology is like on the screenshot. To avoid tedious tunnel creation when I add or remove a node, I decided to create point to point RSVP TE tunnels with LDP, so theoretically my labeing process should be like this: I think I will have 2 labels stack, the outest is RSVP and the bottommost is LDP label. Since tunnels are between directly connected routers, both of these labels will be swapped at every router till it reached the destination.. I still however do not understand the scenario here. If I have direct tunnels, can I end up in a situations where I will  have RSVP imp-null and LDP imp-null for some prefix that terminate on any of the directly connected routers which could result in my label path to be broken?

For example     Lan1----Router1--------announces imp null via LDP and imp-null RSVP---- Router2

Here is seems like the LSP is broken... (with RSVP it looks like it is, but enabling LDP it does work)

2. I do not have PEs or Ps, I have my OSPF domain of 30 routers and for now I enable MPLS TE on only 6 of them (the core), all the routers know all networks, there is no need to hide any portions of the network. Under this scenario, do I still have what you call a transit node?

Hi,

1. My topology is like on the screenshot. To avoid tedious tunnel creation when I add or remove a node, I decided to create point to point RSVP TE tunnels with LDP, so theoretically my labeing process should be like this: I think I will have 2 labels stack, the outest is RSVP and the bottommost is LDP label. Since tunnels are between directly connected routers, both of these labels will be swapped at every router till it reached the destination.. I still however do not understand the scenario here. If I have direct tunnels, can I end up in a situations where I will  have RSVP imp-null and LDP imp-null for some prefix that terminate on any of the directly connected routers which could result in my label path to be broken?

For example     Lan1----Router1--------announces imp null via LDP and imp-null RSVP---- Router2

Here is seems like the LSP is broken... (with RSVP it looks like it is, but enabling LDP it does work)

<Nagendra> Ok. When you have tunnel between directly connected routers, normally it will be imp-null and so no label will be pushed for tunnel. Consider the below simplified topology:

10.1.1.1---R1-----R2-----R3----10.1.3.3

Assume you have 1-hop tunnel between each routers. IOW, there is a TE tunnel between R1-R2 and another tunnel between R2-R3. You also have LDP enabled on these tunnels.

So R3 will advertise imp-null for RSVP tunnel from R2-to-R3. It also advertises imp-null for 10.1.3.3 over LDP session over R2-R3-TE-tunnel.

R2 will advertise imp-null to R1 for R1-R2-TE-tunnel. But it assign a label for 10.1.3.3 (assume it as 200) and advertise to R1 over LDP session over R1-R2-TE-tunnel.

If R1 is sending traffic to 10.1.3.3, it pushes 200 to the label stack and check the tunnel. SInce the tunnel label received from R2 is imp-null, no label will be pushed and forward to R2.

R2 will receive with top label as 200 that have a local forwarding semantic as POP (as it received imp-null from R3). NOw the egress interface is R2-R3-TE-tunnel. So it check the tunnel to see if any label is to pushed and observe it as imp-null. so labels will be pushed and the packet will be forwarded to R3.

As mentioned earlier, imp-null doesnt implies that the LSP is broken. It basically means a forwarding decision is taken based on the top label whcih have a semantic of POP. It does not 

2. I do not have PEs or Ps, I have my OSPF domain of 30 routers and for now I enable MPLS TE on only 6 of them (the core), all the routers know all networks, there is no need to hide any portions of the network. Under this scenario, do I still have what you call a transit node?

<Nagendra> PE and P are terminologies applicable for any network enabled with MPLS. A node that receives IP packet and pushes label is PE nodes (IP2MPLS). A node that receives label packet and forward out as IP packet is also PE nodes (MPLS2IP). They are edge nodes connecting IP and MPLS domain. A node that receive label packet and forward out as label packet is a P router.

In your scenario, all routers are aware of all prefixes. so even if you apply LDP to some nodes and not to others, nothing should break.

-Nagendra

Nagendra, thank you, but I mentioned a different scenario in my case. I do not have R1, R2 and R3, so I do not have anyone to send me a label. I have imp-null everywhere. Let me explain you better. 10.1.1.1---R1-----R2----10.1.3.3 It is imp-null everywhere. We do not have a continious labeling scenario here. With RSVP it works partially (creating full mesh of tunnels from R2 to any routers behind R1 is necessary, otherwise it does not work, can you explain why?), but enabling LDP over this tunnel fixes everything without extending RSVP tunnels to any other routers. It is still imp-null, what have changed?