As I mentioned in the previous blog (Building a MPLS L3VPN Unicast and Mcast Cloud – Overview) what we are going to do first and foremost is create the MPLS core.
Want some snippets of the configs?
Above is a zip file of all the configs for Brie (RR), Cheddar (PE1), Feta (PE3) and Rogue (P). Brie, Cheddar and Feta are all ASR1Ks running IOS XE (3.16.3). Rogue is a ASR9001 running IOS XR (5.3.3)
Create the MPLS Cloud
Time to create the MPLS cloud and prep it for MPLS L3VPN Unicast for One L3VPN Customer. We will do this in 3 steps and also have some additional fun throughout looking at show commands and sniffer traces. 🙂
- Deploy OSPF in the cloud
- Build MPLS LDP neighbors between the PEs and the P
- Configure BGP VPNv4 peers from all PEs to the VPNv4 Route Reflector
Step 1: Deploy OSPF area 0
First things first… let’s configure the core routing in the cloud for the labels to ride on top of. For this I want –
- all 4 routers in OSPF area 0
- network type point-to-point for physical links between the routers
- advertise Loopback0
- passive interface Loopback 0
- OSPF router-id locked in and configured to be loopback0 for each device
For IOS XE this looks like
For IOS XR this looks like
Lets go to Rogue since it is in the middle and will give us a one stop place to see if it sees all 5 routers as OSPF neighbors and has their corresponding loopback address in its RIB.
Yup! Looks good. Okay… so OSPF? Check!
Step 2: Build MPLS LDP neighbors between the PEs and the P
While we are doing this step… there is something very important about MPLS LDP neighbors I want you to understand. Because of this we are going to break this part down into 3 subsections.
- show configs for MPLS LDP
- Disable Cheddar and Rogue from advertising their loopback0s with each other – see that MPLS LDP neighbor doesn’t come up.
- Enable Cheddar and Rogue to advertise their loopback0s with each other – see that the MPLS LDP neighbor comes up.
MPLS Configs
For IOS XE this looks like
For IOS XR this looks like
Don’t Advertise Loopback0s – MPLS LDP Neighbors Do NOT Come Up
- Shut down the interface on Cheddar towards Rogue
- reconfigure both Cheddar and Rogue to NOT advertise their loopback 0s to each other via OSPF
- Setup a sniffer capture on the wire between Cheddar and Rogue
- No shut the interface on Cheddar towards Rogue.
- Show how the MPLS LDP neighbor is NOT coming up
- Look at my favorite command which shows why (show mpls ldp discovery)
- Look at the sniffer trace
Okay… so… I’m lazy. 🙂 Steps 1 thru 4 have been done. 🙂 You will just have to trust me on this.
So let’s just hop to step 5 – Show how the MPLS LDP neighbor is NOT coming up.
Since many of you are probably more familiar with IOS and IOS XE than IOS XR…. let’s just use Cheese (IOS XE) to look at some commands and see what is going on.
- show mpls ldp neighbor – returns the cheddar prompt. We have no neighbors.
- show mpls interface – shows us that interface Ten0/1/0 is configured for ldp and is operational
- show mpls ldp discovery – shows that Cheddars local LDP identifier (it’s MPLS LDP router-id) is its loopback0 (14.100.100.101). It also shows that on Ten0/1/0 we have sent (xmit) AND received (recv) LDP hellos messages. AND it shows that we have learned about a device out there with an LDP identifier of 14.100.100.150.. But then we see something that doesn’t really look good “no route”
You might look at this and be confused. That’s just cause what you don’t know is that the MPLS LDP neighbor is formed TCP between the LDP Identifiers. Which we made the loopbacks. And which… as I mentioned… I removed from being advertised in OSPF between Cheddar and Rogue.
Sniffer Trace: no_mpls_ldp_neighbor.pcap
Advertise Loopback0s – MPLS LDP Neighbors Come Up
- Shut down the interface on Cheddar towards Rogue
- reconfigure both Cheddar and Rogue to advertise their loopback 0s to each other via OSPF
- Setup a sniffer capture on the wire between Cheddar and Rogue
- No shut the interface on Cheddar towards Rogue.
- Show how the MPLS LDP neighbor is coming up
- Look at my favorite command which shows why
- Look at the sniffer trace
Steps 1 thru 4 have been done. So let’s just hop to step 5 – Show how the MPLS LDP neighbor is coming up.
- show mpls ldp neighbor – Woot! Neighbor between Cheddar and Rogue! See that “TCP Connection” line in there also? Port 646.
- show mpls ldp discovery – Looks good!
- show tcp brief – See that port 646? 🙂 LDP, baby!
Here is the sniffer trace of that coming up for you to download and look at.
Sniffer Trace: mpls_ldp_neighbor.pcap
🙂 I do so love me a good sniffer trace! I really learn so much from them.
Step 3: Configure BGP VPNv4 peers from all PEs to the VPNv4 Route Reflector
Only the PE devices will need BGP vpnv4 peers. With the concept of “build today with tomorrow in mind” even though we will ultimately only have 4 routers…. we will go ahead and use a BGP VPNv4 route reflector.
So let’s check out the BGP configs for Cheddar (PE1) and Brie (our VPNv4 RR)
First — let’s look at Cheddar. So it kinda looks like what we might think of as “normal looking ” IPv4 BGP. I mean… there is a neighbor and a peer-group definition. Remote-AS is in their… update source loopback0. And then applying the peer-group to a neighbor. I mean… except for the face that we have everything else listed under the vpnv4 address-family. Looks very similar to IPv4 BGP. Hmmmm…. except for that “send-community both” thing.
Okay… so let’s look at Brie, the vpnv4 RR. Okay… again… “okay readable” for someone who is already family with IPv4 BGP. Just address-family vpnv4 again and that “send community both” again.
What does that “send-community both” mean? 🙂 Next blog.
For now we can see in Brie, the BGP VPNv4 RR, that it has a vpnv4 neighbor relationship with all 4 of the PEs. Ooooooooo… and look! 🙂 PE1 and PE3 are already advertising stuff. 🙂
🙂
Next? Connecting the CEs and following the labels. 🙂
mVPN Fun in the Lab: Connect a Customer – Part 2 of 6
Categories: Fun in the Lab
Hi Fish, this does look fun, do you think this can be done with VIRL?
Absolutely can be done with VIRL!