23 Label Distribution Protocol LDP

[Music] so we talked about MPLS in general we talked about what are the different components how are alternately they going to fit together in terms of the device roles now we're going to look at the specific label allocation technique using the label distribution protocol which by far is going to be the most common way to do label bindings in the MPLS core now again we will see other mechanisms later when we're doing either bgb labeling or RSVP before traffic engineering but what we're mainly going to be focusing on here is the core of the network which in our case is gonna be built with XR 1 XR 2 and X are three and then router 1 or router 2 and router 3 now one of the reasons that LDP is going to be a very common labeling protocol is that from a control playing point of view it's essentially going to be plug-and-play that we'll see that when we configure the protocol LDP is automatically going to discover what are the neighbors that we want to run the protocol with it's automatically going to form a Jason C's it's automatically going to do the label distribution and then we should have a full mesh of connectivity for any of our IGP learned routes whether these are OSPF routes or is-is routes within the MPLS core so we'll see that from a configuration point of view LDP is very very simple we can basically just use one or two commands in order to turn everything on and then from a verification point of view we'll see that this is very similar between the the i/os XR configuration as well as the the regular iOS configuration so first and foremost before we can run LDP we need to make sure that we have the underlying transport and we'll see that LDP is going to use two different transports it uses UDP multicast to find its neighbors and then it uses TCP unicast in order to do the actual label exchange so specifically when we turn the protocol on it's going to be sending packets to the UDP destination to 2400 to at UDP port 646 both the source and the the destination so assuming that we don't have any type of underlying transport problems like maybe we have some sort of data plane filter or we have some sort of nvm a network like dmvpn or a legacy frame with a legacy a TM that we have a problem with transporting multicast traffic over and in our case since we're typically dealing with point-to-point Ethernet it normally butan means that the transport is not going to be an issue that we simply enable LDP on the interfaces other routers are automatically going to discover each other by using this multicast address and once they do this they're then going to exchange what they call the TCP transport address or the ipv4 transport address and then it's going to be used to establish the TCP session between them now we'll see that there can be some problem cases that relate to transport of LDPE that if we're either not advertising whatever the ipv4 transport address is or for some reason it's been modified to a link that we don't have reach ability to that we would not be able to to form the adjacency but in typical cases where IGP is running everywhere and LDP is running everywhere that we should not have any problems with actually forming the the adjacency between them now once we discover the neighbors we're gonna see that LDP is going to form a unicast TCP adjacency so similar to how BGP does or MSTP does where we have LDP as a standard TCP application and this means the client is going to initiate the connection going to the well-known port which in this case is 646 the TCP server is going to reply with the source port of 646 and then we're gonna have our our three-way handshake complete and then ultimately do the label exchange now again we'll we'll see that the main caveat with this is that since we're using TCP for transport it implies that we have to have reach ability beforehand before we can actually establish the adjacency and do the LDP label exchange so in other words we have to have routes to the loop backs between the neighbors before we before we can actually advertise the labels now we'll see from a configuration point of view we can to modify what this transport address is but typically you don't need to do this so like in the case of IGP you are like in the case of BGP it is a recommendation that you would statically define your LDP identifier your LDP router ID to be the loopback interface and that the loopback interface should be advertised into our interior gateway routing protocol so either typically OSPF or ISDN is so let's go ahead and take a look at this from the from a configuration point of view and specifically in terms of the config we'll see it's fairly straightforward for iOS and for iOS XR we're in regular iOS a first step is we need to make sure that Cisco Express forwarding that Ceph is enabled but typically Seth is going to be on by default and in most platforms that run MPLS you cannot disable SEF it's always going to be there okay then we're gonna specifying what label protocol that we're going to be using this already should be defaulting to label distribution protocol but technically there is a legacy precursor to this called the tag a tag distribution protocol or TDP and if one side is running TDP the other side is running LDP then they won't be able to form an adjacency because it's a separate control plane protocol okay then we would typically want to set the router ID so globally in iOS this is the MPLS LDP router ID you tip you know you technically don't need to do this though because it's gonna choose whatever the highest loopback address is for the router ID which ultimately becomes the TCP transport source address then last but not least we're going to enable the protocol so we say MPLS IP on the interface level or we're gonna say MPLS LDP Auto config under the igb prop you six are ones point of view likewise if we say to route ipv4 we're looking for the one-one-one-one address which is router ones the pack and we need to make sure that we have IP connectivity when we ping router ones the back and sourcing the traffic from our own local loopback and you could think of this is the same logic as a BGP peering that if my update sources my loopback your update sources your loopback it implies that we both have IP reach ability to those addresses before we can establish the TCP transport so in our particular case here if we look at the IGP config and show run router is is we're basically enabling is is on every interface and in this case we're focusing on ipv4 connectivity we're not yet looking at any of the the ipv6 over MPLS routing so likewise on router 1 if we look at the show run section is is or interfaces so at the link level we have IP router is is under the global process we have passive interface lebesgue 0 this is with advertising the loop back into the LDP process there's going to be into the is is process ok so next let's go ahead and do a packet capture while we're forming the LDP adjacencies and for clarity I'm going to exclude some of these protocols so let's say let's get rid of is is so not selected and then I'm also going to say no ipv6 and then this is this is an Ethernet live back okay so we're basically looking at just ipv4 packets for now in general okay so next up I'm router one and we're gonna go to global config and we're gonna say the MPLS router ID or the MPLS LDP router ID is going to be our loop X 0 and again you technically don't need to do this because it is going to choose it by default but it's the same case as an OSPF or BGP you want to make sure that this address doesn't change if for some reason you add another loop back later and it has a higher IP address it could impact the LDP process or could impact igb BGP etc so just as best practices you would say you always want to set this ok then we go to the link level in this case it is interface gig 1 dot 1 1 1 and we enable the process MPLS LDP or excuse me MPLS IP if we look at now from a packet capture point of view we should see that router 1 is now generating these LDP hello messages and specifically these are UDP packets source and destination is port 646 from an IP transport point of view these are multi guess it's going to to 2400 to the source address is coming from the interface that is assigned to that link so in this case gig 1.1 1 1 1 it has the IP address 10.1 11.1 now inside the actual LDP payload in the hello message what is going to be important about this is this ipv4 transport address and it says from router 1 it's advertising the transport address is 1 1 1 1 or in other words that loop back that we had configured as the LDP router ID so what this now means from any devices that we discover on our connected segments is that when they go to form the LDV adjacency with router 1 we're more specifically the TCP session the destination address needs to go to the IP 1.1.1 at 1 so again from a routing point of view for some reason we did not have a route to the loopback then we won't be able to actually form the session okay same is true under iOS XR Center iOS XR we're going to go to global config turn MPLS LDB on will set the router ID to you our loop back so the back zero and then we'll say that under is it the MPLS let's see the I think the router idea is global in the case of X are let's say show config and then we'll say that the what interfaces are we running the process on so let's say show IP interface brief and in this case it's gonna be on the link to router one so we'll say interface is gig 0 0 0 0 dot 1 1 1 and if we show config this is the equivalent in regular iOS if go to going to the interface level and saying MPLS IP so next we commit our config if we look back at our cap packet capture we should now see that XR 1 is also going to be generating these hello messages so we see the the packets going to to 2400 2 once both router 1 in XR 1 find each other and then we go to form the TCP session and notice here this is the first portion of the three-way handshake it's coming from coming from XR 1 and so this is an IP packet from 1111 1111 going to one on on one inside the TCP header we see that this is the sin so this is the opening of the session the destination port is the well-known port of 646 source port is going to be a random port that they're negotiating then likewise on the reverse way from one back to 11 the source port is now going to be 6 to 46 and then the destination is going to be whatever the negotiated port is so in other words this works like a normal TCP session like web browsing telnet SSH etcetera that the client is going to initiate the session the server responds and the ports are going to be swapped between the two of them so this means from a data plane filtering point of view if for some reason your access between the the neighbors you need to match LDP both on the source and destination ports and you don't know what the the negotiated port is going to be between other two of them so let's say from router ones example from router ones point of view if we wanted to permit the session only between router one and X are one just for LD P an access list would look something like this will say IP access list extended LD P it would permit UDP in e equal to 646 going to to 2400 to 2 equal to 646 so this would be the hello then we would permit TCP in e and e equal to 646 and permit TCP in e equal to 646 any so if we go ahead and apply this to our interface on gig 1 1 1 1 IP access group L DP in and then look at the show access list we should see that we're gonna get hits on the first entry for the hellos and then if we were to clear MPLS l DP neighbors so we'll reset the session and depending on who was the client who was the server we should see that we're gonna get hits on one of these and in this case it means that router one was the TCP server router 11 or XR 1 was the TCP client now ultimately just like in the case of BGP it shouldn't really really matter who was initiating the session as long as the TCP session comes up that's really all that we care about now once we get to this point in terms of the neighbors are supposed to a form the adjacency the next thing that we want to do from a verification point of view is to see did the neighbors actually form so we show MPLS LD P neighbors this is going to see did the TCP session actually correctly form once it is up then we would look at what are the labels that we actually bound between the neighbors this is going to be the show MPLS forwarding table this is the equivalent of the show IP route for MPLS now beyond this there are other verifications in terms of the label in a base to label database where we can say show MPLS LDP bindings this would be the equivalent of say show IP ospf database or the show IP BGP because before these protocols send their best routes to the routing table they might have multiple candidate routes that they have to make a decision between and same thing is true with LDP so we might receive be receiving multiple label numbers for the same destination but based on the intersection of the IP routing table plus the label information base we combine these two together and this is what becomes the label forwarding information base so nine times out of ten we're gonna look at show MPLS forwarding table that's gonna tell us and that the binding did occur and what is our actual active label that we're using towards that particular destination so in this particular case if we look at the show MPLS forwarding table we see that most of these destinations we do not currently yet have a label for this is because we're not running label switching on these interfaces that we're using to route towards the destinations now if we look at the show MPLS LDPE bindings we will see that we are receiving label numbers for essentially all of the destinations but since those destinations are not installed in the routing table out those particular links it means that we cannot be using those particular label numbers so what I mean by this is let's say that we were to look at the the show and be this forwarding table and let's say we're looking at router threes loopback okay router threes loopback it says I have two possible ways to get to this from router ones point of view I can be going that way or I can be going this way because from is-is-is point of view since the metric is equal on all interfaces we're essentially using the metric as a hop count so router one is saying I have one two hops to go through xr2 or I have one two hops to go through router two so specifically the interfaces we should be using our gig one one one two and gig one - however if we look at these show MPLS LD be bindings we should see that we're learning a label 4 3 3 3 3 and it says the label switch router or in other words the the the P router the MPLS router is 11 11 11 11 or in other words XR 1 so this says that if we were going to send traffic towards 3 3 3 3 via XR 1 we would be using the outgoing label number 16 thousand and eleven but since the interface that we're using to reach 3 3 3 3 is not the same one that we use to reach XR 1 it means that this label doesn't actually get installed into the forwarding table now we'll see what this means from a troubleshooting point of view is that one of the common misconception see is going a different way and then ultimately you're not able to use a label for that particular destination now we'll see you in more detail later what are some of the ways that we can troubleshoot this problem but in general when you simply look at the show MPLS forwarding table if you ever see that the output says no label this generally indicates a problem in label switching now this is different from either the pop label or the pop tag output this means that we're using the implicit no label or in other words whoever is advertising this particular route is the same neighbor that we are directly connected to so this is sometimes also referred to as the penultimate hop hopping or the PHP process and this is when I go to send a packet to the device that actually owns that IP address I'm going to remove the topmost MPLS label to save them from having to do an additional lookup now this will make a little bit more sense later when we get into the details of l2 VPN and l3 VPN but it's basically an optimization of the the label lookup process on the last hop PE but otherwise when we see no label here that's not the output that we want to see

Channel: Boneless Man

Views: 6,546

Rating: 4.647059 out of 5

Keywords:

Id: 8Bsj0EVenV8

Length: 20min 21sec (1221 seconds)

Published: Mon Apr 23 2018