{"id":1023,"date":"2022-08-07T17:02:46","date_gmt":"2022-08-07T16:02:46","guid":{"rendered":"https:\/\/www.labtinker.net\/?p=1023"},"modified":"2022-08-07T17:02:46","modified_gmt":"2022-08-07T16:02:46","slug":"mpls-and-mp-bgp","status":"publish","type":"post","link":"http:\/\/18.135.13.153\/?p=1023","title":{"rendered":"MPLS and MP-BGP"},"content":{"rendered":"\n

To me MPLS has always been a cloud on a network diagram that was someone else’s problem. But I decided to lab it up and see how it worked. Happily, I found someone who had described how to set up the lab to do just this:<\/p>\n\n\n\n

https:\/\/packetlife.net\/blog\/2011\/may\/16\/creating-mpls-vpn\/<\/a><\/p>\n\n\n\n

The rest of the post assumes you have read this link but I will repeat or emphasise relevant aspects of it. Firstly, kudos to Jeremy Stretch for creating this lab. Having set up the lab, I determined to try and work out in more detail exactly how a packet got from one end of the toplogy to the other.<\/p>\n\n\n\n

If you haven’t read the link above (and I urge you to as this post will only make limited sense without it): MPLS is a protocol which inserts a label into a packet and particpating devices use said label to forward said packet rather than an ip address. The MP is for Multi-Protocol so it doesn’t have to be IP. The lab above recreates how it can be used in conjunction with MP-BGP to forward traffic for different customers across a WAN whilst keeping that traffic separate (to the extent that different customers can use the same prefixes on their networks without interfering with each other. For different customers, think different VRFs)<\/p>\n\n\n\n

This is the topology, indentical to the one outlined in the link above:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

I set out to ping from CE1A to an interface on CE2A (routers that belong to the same Cusomer\/VRF) and work out how the packet got there. A word of warning, please do not consider my words authorative: it’s just my interpretation of what I believe is going on after consulting several sources. (If anyone wishes to comment please do so by email: I disabled comments as they were being filled with links to vape, CDB and erotic websites.)<\/p>\n\n\n\n

Let’s check the interfaces on both routers (I use an alias I’d defined so the command ‘sib = show ip int brief’)<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

So from CE1A, let’s use traceroute to tell us how to get to 172.16.2.1.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The first hop is to 10.0.1.1 and is using good old fashioned ip routing to PE1. <\/p>\n\n\n\n

\"\"
On PE1<\/figcaption><\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

So from hereon we see from our traceroute that we are using labels to foward the traffic. Let’s see which labels are attached to which prefixes:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

We are interested in the prefix 172.16.2.1 and we immediately see the outgoing label for that is 21 which is what we saw in the traceroute: so far, so good. But the traceroute also had the label 19 in there as well – where did that that come from? Well, before we answer that, let’s consider where we learnt about 172.16.2.1. The ‘V’ in brackets tells us – this stands for VPN – the prefix was learnt over a VPN that exists between PE1 and PE2. So let’s get more information on this VPN:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Now we see 172.16.2.1. has a next hop of 10.0.0.4 (the loopback address of the router which terminates the other end of the VPN. The VPN here is explained in the link above). If you refer back to the MPLS forward table you’ll see the label for the prefix 10.0.0.4 is 19. So it seems to make sense that that label gets inserted into our packet to get it to PE2. Let’s capture the traffic between PE1 and P1<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

To those unfamiliar with GNS3, a magnifying glass denotes a Wireshark capture. And the MPLS label from this capture reaffirms what was seen in our traceroute output and what I discerned above.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

So now the packet arrives at P1. This is using MPLS and its forwarding table is as follows:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

So P1 reads the label 19 (incoming) and replaces this with the label 16 (outgoing) and sends it out of gi0\/0. Let’s have a look…<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Notice, it hasn’t touched the other label. So now let’s take a look at P2.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

For the incoming label of 16, we’re going to pop (remove) the label. How does P1 know to pop the label if it’s not bottom of stack? I have not read this explicitly but my surmise is that the router ‘recognises’ that address as belonging to its LDP neighbour so that the label to get the packet to 10.0.0.4 will be redundant or irrelevant to the next router so there’s no point sending it. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

This means the remaining label is 21.<\/p>\n\n\n\n

Anyway, let’s have another look at the packet from PE2 to P2<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

The ‘bottom of stack’ flag tells the next router this label is the er.. the bottom of the label stack and if this is removed then the packet has to be fowarded using ipv4 (as the protocol we’re using with MPLS) . As we see on PE2 the MPLS forwarding table has removed the final label for 172.16.2.1<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

So let’s check the routing table for our VRF<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

And there it is, the next hop is 10.0.2.2 which is CE2, the final destination.<\/p>\n\n\n\n

Below are the configurations of the the routers involved in the lab.<\/p>\n\n\n\n

CE1A<\/a>Download<\/a><\/div>\n\n\n\n
CE1B<\/a>Download<\/a><\/div>\n\n\n\n
PE1<\/a>Download<\/a><\/div>\n\n\n\n
P1<\/a>Download<\/a><\/div>\n\n\n\n
P2<\/a>Download<\/a><\/div>\n\n\n\n
PE2<\/a>Download<\/a><\/div>\n\n\n\n
CE2A<\/a>Download<\/a><\/div>\n\n\n\n
CE2B<\/a>Download<\/a><\/div>\n","protected":false},"excerpt":{"rendered":"

To me MPLS has always been a cloud on a network diagram that was someone else’s problem. But I decided to lab it up and see how it worked. Happily, I found someone who had described how to set up the lab to do just this: https:\/\/packetlife.net\/blog\/2011\/may\/16\/creating-mpls-vpn\/ The rest of the post assumes you have […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[9],"tags":[],"class_list":["post-1023","post","type-post","status-publish","format-standard","hentry","category-networking"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"http:\/\/18.135.13.153\/index.php?rest_route=\/wp\/v2\/posts\/1023","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/18.135.13.153\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/18.135.13.153\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/18.135.13.153\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/18.135.13.153\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1023"}],"version-history":[{"count":0,"href":"http:\/\/18.135.13.153\/index.php?rest_route=\/wp\/v2\/posts\/1023\/revisions"}],"wp:attachment":[{"href":"http:\/\/18.135.13.153\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1023"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/18.135.13.153\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1023"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/18.135.13.153\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1023"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}