First of all, it is difficult to dive right into a topology that has many different things going on at the same time. It is also difficult to troubleshoot by reviewing ten different configuration files without having the devices available to issue show and other verification commands. For this reason, I suggest you begin by creating topologies that build-up to this big one. For example:
Begin by creating a topology with two PEs, two CEs, and one P and practice route leaking without adding anything else.
Next, you can add an RR to the mix and see how that goes. Get it working and do extensive experimentation first, before you go on to the next step.
Next you can disable IPv4 unicast and enable only VPNv4 address family on the same topology.
Next add two more CEs and try some more complex route leaking scenarios
Finally, build the whole topology and apply everything at the same time.
Doing it this way will ensure that you understand each concept and have implemented it successfully before incorporating it into a topology with additional features. It takes a long time, but it is the most effective. The important thing to understand is that the goal is not to make this particular topology work but to gain an understanding of the processes involved. Some lessons that will help you along the way include:
Rene doesn’t have a lesson where the RR is being implemented in an MPLS environment, but it should be helpful for you to apply. Some help for using an RR only for VPNv4 is found below:
router bgp 1
no bgp default ipv4-unicast
no neighbor x.x.x.x activate
neighbor x.x.x.x route-reflector-client
This configuration will disable IPv4 unicast and will activate the RR for VPNv4 only.
Finally, about the “twist”, you can only import and export routes for the whole AS. If you want to limit traffic to a particular host, you will have to use ACLs.
Regular BGP supports IPv4 unicast prefixes. MP-BGP is multi-protocol BGP, and it is an implementation of BGP that supports multiple protocols such as IPv4 unicast, IPv4 multicast, IPv6 unicast, and IPv6 multicast.
It is also used extensively with MPLS VPN in order to be able to share information from VRFs and VPNv4 routes. MP-BGP in simple terms includes fields in the BGP header where info about these things (VRFs, VPNv4 routes etc) can be shared, enabling MPLS VPN implementations.
More info about this can be found here:
Implicit null occurs by default. This is a situation where the penultimate router pops the label and sends the plain IP packet to the last hop router. Explicit null if configured, will not have the penultimate router pop the label, but sends a label value of 0 and keeps other fields intact. This allows the other fields that may contain QoS information, to be processed as well. More info about these concepts can be found at the following Cisco link:
You can also get some more info about this from the following post by Rene:
I’m not sure what you mean exactly. Do you mean if these protocols don’t converge? If an IGP doesn’t converge, then there is a problem in the topology or the configuration, and routing will not function correctly. Similarly, if LDP doesn’t exchange label information correctly, incorrect routing will take place.
Actually, MP-iBGP is not a term you see very often. Some vendors use it, and I have seen it in a few texts of documentation, but it is by no means an official term. I guess it refers to the use of MP-BGP for iBGP peerings.
Each PE or LER will know what prefixes belong to which customer routers that are connected to it.
For these prefixes, the PE router will advertise an implicit null label to its neighbor. This indicates to the neighbor (the penultimate hop router) that for that particular prefix, penultimate hop popping should take place before sending the packet to the PE router.
If there is QoS information in the MPLS header, then we need to keep that header for the PE router to read. Yes you are correct, the PE router informs the P router with the explicit null so that this can be achieved.
Router IDs are used to uniquely identify routers using a particular routing protocol. These should always be unique. This is the same for IGPs, BGP, and MPLS. If they are the same, then it could result in failed neighbor peerings, and incorrect routing.
This is an excellent question. Since the routes of the other VRFs will be leaked into the routing table, it is necessary that you ensure that the addresses being leaked are indeed unique. There is no way to differentiate them within the routing table. However, if two enterprises do indeed have overlapping address spaces, you can resolve this by using NAT. This will make the addresses unique once again.
What I find very annoying with people teaching MPLS is why do they keep using the same value for the RD and RT?
They are not the same thing, so why does everyone teaching it keeps giving them the same value.
With this topic with importing and exporting routes. If the RD and RT had different values, the students wouldn’t have to think or second guess themselves if they are using the RD or RT value.
I’m sure there are going to be people who already understand MPLS will rubbish my comment. I am dyslexic and things like this can be confusing when it could have been put in an easier format.
Since the RD and RT use the same format, many students confuse these two. Normally we use the same value for these two but to emphasize that the RD and RT are two different things, I used 123:10 for the RD and 123:1 for the RT.
However, it may be worth making the values different in other lessons as well. I will let Rene know about your comment so that he can consider making any changes that would help.
I agree that using different values could be helpful, especially when you are new to MPLS. If I had to recreate my material, I think I would use different values. Changing it for the current material would be too much work because I use these RD/RT values in many scenarios, including our videos.
In VRF leaking between two Routing domains on the same physical switch with no BGP peering, if I were to create an export-map and have a route-map that denies a set of prefixes as my first line, but the next seq is exporting those same set of prefixes with a second match statement that’s set to allow with a new community attribute defined with “send-community-additive” , would the prefixes still get exported if I were to import the RT in the target VRF? or would the initial Deny statement in the route-map prevent it from happening all together
One of the responses I received is the following & am hoping you can confirm it’s accurate…
"It depends on the order of operations for the export and import processes in your network. If the export-map with the route-map is applied before the import process in the target VRF, then the prefixes will be exported and imported into the target VRF, despite the deny statement in the route-map. This is because the second match statement with the allow action will match the prefixes and send them with the new community attribute.
However, if the import process in the target VRF is applied before the export-map with the route-map, then the deny statement in the route-map will prevent the prefixes from being exported in the first place, and they will not be imported into the target VRF.
It’s important to carefully consider the order of operations in your network to ensure that the desired policies and configurations are applied correctly. "
The response that you got to your question seems to be correct. Of course, the only way to verify it is to actually go in and lab it up, and it would actually be an excellent exercise to attempt. I suggest you do so if you are so inclined, and if you do, please let us know of your results!
Thanks for the response as a matter of fact I have a lab setup and encountering a weird issue
I’m leaking between two VRFs on the same nexus switch ( no bgp peer)
Basically what’s going is when exporting prefixes that exist already in my BGP table to a target VRF and giving it a new extcommunity , for whatever reason not all the prefixes are getting the community that they’ve been specified for. I’m using “send-community additive” in the route-map
When a route-map is processing a prefix list with multiple statements, it will evaluate the statements in the prefix list sequentially based on their sequence numbers. If a match is found, the route-map will stop processing the rest of the statements in the prefix list and will apply the corresponding action (permit or deny) defined in the route-map.
If you use the set command after the match statement in a route-map, as you have done, the set command will be applied only to the prefix that matches the first matched statement in the prefix list. Once a match is found, the route-map will apply the corresponding action of the set command, then stop processing the rest of the statements in the prefix list.
The result is that the first prefix, which is matched, gets the community, but the second doesn’t. So this behavior is not an issue related to VRFs or BGP, but to the way that route-maps interact with prefix lists.
The continue clause introduces the ability to execute additional entries in a route map after an entry is executed with successful match and set clauses. Continue clauses allow you to configure and organize more modular policy definitions so that specific policy configurations need not be repeated within the same route map. Before the continue clause was introduced, route map configuration was linear and did not allow any control over the flow of a route map.
It is something that was specifically introduced into BGP route map configurations. Thanks for sharing that, it’s great information!