Hi everyone, JP here. You know as CCIE candidates, we are faced with one of the most difficult, and grueling, exams the networking world has to offer – the CCIE lab exam. As you may or may not be aware, Frame-Relay was replaced with L3VPN and DMVPN in the R&S Version 5 blueprint update. This means not only will we need to understand our IGP’s, MPLS, and VRF Lite, but we will need to fully understand how to configure MPBGP in order to transport our VPN labels and prefixes across the service provider’s network.
Using a topology from one of our mock labs, let’s have a look into the configuration of MP-BGP and make sure we understand it. Preview the diagram in HD here.
![JP_Blog_082015_1]()
In a Layer 3 VPN we are driven by the need to advertise customer prefixes across a service provider network, while keeping these customers isolated from one another. To do this using L3VPN, we need to carry more than just the IPv4 unicast address, which is all standard BGP is capable of. Additional information like the MPLS label, VPN label, and route-distinguisher need to be carried from one point of the network to the other. Let’s imagine for a second that we have 2 customers. In our above diagram they are Brand Office 1 and Acquisition 2. Let’s say that both of these customers use the 10.10.1.0/24 address space. How do we distinguish between these 2 different customers when these routes arrive on our PE? The route-distinguisher is the answer to that question.
The RD is an extended BGP community that creates a unique address by prepending a unique 8-octet field to our existing 4-octet IP address. This new 8-byte field will consist of a 2-byte type field followed by a 6-byte value field. For example, our 10.10.1.0/24 network might become 150:150:10.10.1.0 for the Branch Office, while Acquisition 2 might become 250:250:10.10.1.0. Now, when both customer routes reach our PE, while they are using same IPv4 address space, the addresses are globally unique per customer. It is important to understand that the RD is only used to make our addresses unique; it does not control any route redistribution. For this, we need what is known as the RT or Route-Target. The RT is used to identify which prefixes we want to import into our VRF. When we create a VRF we are going to give it two values. The RT-Import is going to look for any inbound prefixes with that route-target and then install them into our BGP VRF. The RT-Export is going to use this value for any prefix leaving our BGP VRF. The MPBGP VPN is then going to carry these prefixes and values from one PE to the other. Let’s just have a look.
![JP_Blog_082015_2]()
So we have created a VRF using the values above. We are going to receive any VRF prefixes that were exported with the value of 150:150. Likewise, we are going to send our prefixes with a value of 150:150. Now how do we assign and carry customer routes across a provider network with this new information added to the IP header? Classic BGP only supports standard IPv4 unicast addresses, so there is no way it can handle this new 150:150:10.10.1.0/24 prefix, because it is no longer a IPv4 prefix. If we tried to use BGP it just wouldn’t work because it would ignore the additional bytes. This is where MP-BGP, or Multi-Protocol BGP comes in. MP-BGP gives us the ability to carry multiple different types of addresses simultaneously through what are called address-families. In this case we are interested specifically in the VPNv4 address-family, as well as the IPv4 VRF address-family. These new address-families between our PE routers are going to carry and assign information, such as the RD, that we need to make this work. Keep in mind that in addition to our RD and RT we are going to have our transport label, used to reach the next PE router, and the VPN label which will tell the PE which customer, or CE, the routes belong to.
Now just a quick note here. Our network is already setup with LDP peering’s between all our required P and PE routers, so we aren’t going to address the MPLS requirements. Our customer devices are already setup with BGP facing our PE with redistribution so we aren’t going to need to take care of anything there, but let’s have a look at that configuration.
![JP_Blog_082015_3]()
R11 has a standard BGP configuration and mutual redistribution with OSPF. OSPF is being used as our IGP facing into our network. BGP is the EGP being used to advertise our prefixes out to our PE. That is the reason for the mutual redistribution. As we receive routes from our PE we need to inject them into OSPF, likewise as we receive OSPF prefixes from our internal neighbors, we need to inject them in BGP. Notice when we redistribute from OSPF into BGP we make sure to match type 1 and type 2 prefixes. By default, BGP is only going to redistribute intra area routes from OSPF. This is why we need to make it a habit of ensuring we match all types.
As we go through this configuration it is important to note that we only perform these steps on the PE routers. The rest of the provider cloud does not get any of this special treatment. Now, by default BGP will automatically enable the transport of IPv4 unicast addresses. When dealing with L3VPN and MPBGP I recommended that we disable this to give ourselves a little bit more control of IPv4 peering’s to avoid problems. Let’s go ahead and configure standard BGP with ipv4 unicast disabled.
![JP_Blog_082015_4]()
![JP_Blog_082015_5]()
At this point we have our standard BGP configured, but we have no peering’s established. This is due to the fact that we have disabled the default ipv4-unicast setting within BGP. We need to tell BGP how we want it to peer with the neighbor we have configured. So now we jump into creating our first address-family. If we issue the address-family command followed by the “?” we can see our available options:
![JP_Blog_082015_6]()
For this particular piece of our configuration we are going to need the IPv4 option. As we create our address-family, I usually make it a habit of adding the send-community extended command. This is habit for me and is going to allow me to send any extended community values I want to send later on down the road. It is not required for this particular implementation.
![JP_Blog_082015_7]()
![JP_Blog_082015_8]()
Good, we have our IPv4 unicast peering up and running. Now take a note that we are peering with the loopback addresses. We already have full reachability due to OSPF being configured in our provider cloud for LDP. Up to this point we have not done anything out of the ordinary of what we do in a standard BGP configuration, except for the creation of the address-family to support ipv4 unicast traffic. Any BGP peer not participating in this PE-to-PE VPN will now be configured under this ipv4 address-family. Peers that are configured under this address family will have prefixes added to the global routing table. For example, if we created a loopback interface and R2 and advertised it into BGP we would see it in the global routing table of ISP3. Let’s have a look at that.
![JP_Blog_082015_9]()
![JP_Blog_082015_10]()
As we expected, we see this 2.2.2.2/32 route in our global routing table on ISP3. So everything is working perfect up to this point.
Our next step is to create the VPNv4 address-family for the use of carrying our customer prefixes across the network to the other PE. We do this the same way we created our last address-family except we use the VPNv4 key word instead of IPv4. Just as with our IPv4 address family, we need to activate our neighbor. Notice the additional send-community extended command. This option enables us to send the extended communities to our neighbor. If this option is not added to our configuration we will not have the capability to carry the attributes we discussed earlier when configuring our VRF.
![JP_Blog_082015_11]()
![JP_Blog_082015_12]()
Once we enable our VPNv4 address family our standard peering is reset. BGP tells us it is because the capabilities have changed. Nothing to be alarmed about, this is completely normal. The one thing we need to be aware of however is that it will reset our peering. If we do this in a production environment we might want to do it off hours, even though it’s only for a brief moment. I want to take a moment to introduce you to a new command that we are going to need to be aware of. We now have 2 different types of BGP peering’s between our PE routers. We have our standard IPv4 unicast peering and our VPNv4 peering. Let’s verify that both are up and running, and take a mental note to the different commands required to perform this action.
IPv4 Unicast Peering:
![JP_Blog_082015_13]()
VPNv4 Unicast Peering:
![JP_Blog_082015_14]()
Lastly we need to configure our VRF address-family with our CE routers. This is how our PE routers will actually receive the internal prefixes from the customer. Remember that our VRF has already been configured and placed on the proper interfaces. We already have LDP configured and have our peering’s. For example, have a look at our configuration on ISP3:
![JP_Blog_082015_15]()
![JP_Blog_082015_16]()
Once we configure this VRF address family, our MP-BGP is going to come together with our MPLS and give us some magic. We have already applied our VRF’s to the appropriate interfaces using the ip vrf forwarding command. As shown above we have our LDP neighbors. In theory, this is all we should need to do in order to route between our 2 offices over our MPLS VPN.
![JP_Blog_082015_17]()
![JP_Blog_082015_18]()
As soon as we activate our PE neighbor we instantly see our peering come up for the VRF iPexpert. Now remember the nature of a VRF. At this point our PE routers now have 2 routing tables, as well as 2 BGP tables. One is global to the PE, as seen below. Notice we have no prefixes to our customers.
![JP_Blog_082015_19]()
![JP_Blog_082015_20]()
Now if we look at our L3VPN output, we are going to see something much different.
We start out by issuing the same ip route command we would always use however, now we append what vrf RIB we want to view.
![JP_Blog_082015_21]()
Ok, we are receiving our prefixes from the other PE and they are being installed into our vrf RIB for iPexpert. Notice we have the 172.16.70.0 prefixes and we also have the 172.16.8.8/32 prefix, which is the loopback 0 interface of R8 in our Acquisition office. Now let’s move into taking a look at our BGP table for our VPN.
![JP_Blog_082015_22]()
Here we can see all of our prefixes coming into the PE from both directions. We see our 172.16.60.0 prefixes coming from our Branch Office. Remember this is being redistributed from OSPF running as the IGP in the office. We also see the prefixes coming from the other PE, which is R2. BGP even is nice enough to tell us what our RD is, before giving us any of our networks.
Finally, let’s verify our reachability and make sure that we did our job properly. When it comes time to take the lab, verification is going to be something that makes you or breaks you. We absolutely must verify that we have done our job correctly.
![JP_Blog_082015_23]()
From our R13 customer device inside of our Branch Office, we are able to successfully reach the loopback 0 interface of R8, which is the CE router in the Acquisition 2 office. This is exactly what we expected.
I hope you enjoyed reading, keep studying!
J.P. Cedeno
Routing & Switching Instructor
![]()
