In our last blog (MPLS Fun in the Lab: Connect a Customer – Part 2) we added a customer to our MPLS cloud and we got a ping successfully across.

Now?  Now we Follow the Labels of that successful ping. Well… actually that kinda seems boring. So let’s have a little bit of fun while we are at it.

Let’s go full Network Detective and try to figure out where the above sniffer capture was taken.  🙂

Where was the Sniffer During the Ping?

The above sniffer capture, of the successful customer ping, was taken somewhere inside the MPLS cloud.  But where?

Since I love troubleshooting… and I think that approach will be a LOT more fun then just showing you labels and following them….  we shall reverse engineer, together, where the sniffer had to be during the ping. We shall apply to the mystery the same “Techniques of a Network Detective” I would use if I were to approach a “who done it” in the Network.

MPLS Part2 Zip    <—- config snippets w/ explicit-null enabled

Ready to begin?   Okay…. So During the ping……let’s put our Network Detective Badge on and figure out…..

Where was the Sniffer During the Ping?

Let’s start first with the customer ping we caught in the sniffer trace. This will have facts and clues in it.  What is the difference between a fact and a clue?   Knowledge.  Of course, if you have knowledge of what an explicit-null even is… then you already know EXACTLY where the sniffer had to be.

Gather the Facts/Collect the Clues

1. The ICMP echo request went from left to right thru the MPLS cloud and had
   1. outer label 24000
   2. inner label 29
2. The ICMP echo reply went from right to left thru the MPLS cloud and had
   1. outer label Explicit-Null
   2. inner label 25

Let’s focus ONLY on the ICMP Echo request.

Two labels as we can see above.

• outer label 24000
• inner label 29

Where Did the Labels Come From?

But where did those labels come from? Which “protocol” created those labels?  When I ask this… it is not uncommon people newer to MPLS L3VPN wonder “what does she mean which protocol?” A lot of people new to MPLS think there is just 1 protocol that creates labels: LDP. Of course, it probably wouldn’t be called multiprotocol label switching if that were the case.

A label-switched path (LSP) is a path through an MPLS network, set up by a signaling protocol such as LDP, RSVP-TE, BGP or CR-LDP.

– https://en.wikipedia.org/wiki/Multiprotocol_Label_Switching

As far as the 2 labels on our sniffer trace for the ICMP echo request, the inner label was created by BGP, and the outer label via LDP.   Actually…. in this specific environment… with the configs I have given to you…. it will be BGP vpnv4 for all the inner labels for the customers hanging off of VRFs…. and the outer labels (when there are outer labels) will be created by LDP.

Interview the Witnesses

So let’s “interview the witnesses”.  Who is a witness?  Well I told you that the inner label was created by BGP VPNv4.  Since there is NO BGP in Rogue…  That reduces our pool to Cheddar, Brie, and Feta.  Let’s start color coding Cheddar and Feta and the labels they create and advertise.

So let’s go to Cheddar and see if anyone has told it about using label 29 to get to 10.11.0.0/16.

Looks like 14.100.100.201, Feta, is the one who told Cheddar about label 29.  So we will color code the label 29 green since Feta is the one who created that label.

Cheddar’s instructions are –

• if you want to get to 10.11.0.0/16,
• come to “me”, 14.100.100.201
• and use label 29

Let’s go check Feta. Yup.  There we go.

So Feta is the one advertising the label 29 inside of BGP VPNv4.  Since it is advertising the label it needs to know where it is going to label switch it to.  So let’s look at the mpls forwarding table for Feta.  As we can see below Feta’s mpls forwarding table shows that if a label comes into it a value of 29 it is supposed to go out gig0/0/0 towards next hop 10.11.14.2 (String) with no label.

Remember, in our environment I had configured String to advertise the subnet 10.11.101.0/24 via its IPv4 BGP (eBGP) neighbor with Feta.  Right?  So first Feta learned about the prefix 10.11.101.0/24 via String.  Feta knows it is in a VRF and is configured to advertise the prefix and the corresponding label to its BGP VPNv4 RR, Brie. 

Brie is configured as a BGP VPNv4 Route Reflector for both Feta and Cheddar.  As a good RR Brie will then reflect Feta’s advertisement (prefix, attributes, and label) to Cheddar.

If you open up the sniffer trace I put up at the beginning of this blog and jump to frame 61 you can see Brie reflecting 10.11.0.0/16 and the corresponding label 29 to Cheddar.  Of course you can also see all the attributes and the RT and RD as well.  But for right now let’s just look at the prefix 10.11.0.0/16 and the label, 29, that Feta advertised to Brie and is getting (in this sniffer trace) sent from Brie to Cheddar via an update.

Okay… so we can see how Cheddar was told what it was told.

So, again, we know that Cheddar was told

• if you want to get to 10.11.0.0/16,
• come to “me”, 14.100.100.201
• and use label 29

So is that all Cheddar needs to do?  Slap a label 29 onto the ICMP Echo request and send it to Rogue?  Like the below?  Only 1 label?

Remember… and this is VERY important.  That 29 label was created by Feta and advertised out via BGP VPNv4.  Rogue does NOT speak BGP.   In last blog we established that Rogue doesn’t have 10.11.0.0/16 in its routing table.  AND…. it is important to know that Rogue’s label forwarding has no instructions as to what to do with a packet with a  label 29.

So, obviously then, Cheddar needs to do something more than just slap a label of 29 onto the frame and send it out to Rogue.

Let’s go back to what EXACTLY Cheddar was told

• if you want to get to 10.11.0.0/16,
• come to “me”, 14.100.100.201
• and use label 29

Oh. Okay. So label 29 will mean something once we get to 14.100.100.201.  And not until then.

Okay… so Cheddar needs another label.  Why? Well it needs to

• push the label 29 on
• and then push another label just to get through the MPLS cloud to GET to 14.100.100.201 where label 29 will then make sense

Enter the label created by LDP.

Okay, so Cheddar needs to push an outer label onto the packet and send it to Rogue.  Cheddar learns this label to get to 14.100.100.201 via Rogue.  How?

Rogue will

• create a local label for 14.100.100.201
• put it in its mpls forwarding table in the local label column
• advertise via LDP to Cheddar to use this label to get to 14.100.100.201

Rogue’s mpls forwarding table shows that it has created local label 24000 for 14.100.100.201/32 and has put it in its mpls forwarding table with the instruction that if a packet comes into it with a label of 24000 that it is supposed to swap the label 24000 with an explicit-null and send the packet out ten0/0/0/3 to next hop address 14.201.150.2.

Let’s go to Cheddar and make sure that it sees the Rogue advertised label 24000 as an outbound label for 14.100.100.201/32.  Yup yup.  Looks good.

Hey wait…. doesn’t that 24000 number ring a bell?   Wasn’t that what we saw in the sniffer trace?  24000 as the outer label and 29 as the inner label?

Yup!  Sure was!  Okay…. so does this mean we have solve the mystery of where the sniffer was at the time of the ping?

Woot!  Mystery solved!  The sniffer was between Cheddar and Rogue!

Ready to add Multicast?  🙂

mVPN Fun in the Lab: Add the Multicast at the Customer – Part 4 of 6