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.
what is MP-iBGP? Is this similar to normal BGP Route Reflector setup? If not where is that differ?
So MP-iBGP & MP-BGP both are same. There is no difference.
implicit null & explicit null concept.
So how PHP router understand that it needs to POP the label?
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.
It P Router doesnât pop the label then it will go to PE router as label packet and then PE router needs to do two time lookup. Why it does so? Where is the benefit of doing so?
Per Rene, if there is QOS configured then PE router sends explicit NULL label which has a value of 0 to P router to stop popping the label. Am I correct?
what will happen if LDP/IGP/MPLS DOESNâT synchronize?
My Bad. I missed one word in between to mention.
What will happen if LDP/IGP/MPLS Router ID DOESNâT synchronize or they are different?
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.
While doing Route Leaking (import/Export) what if RED and BLUE Customer has same subnets. How will it differentiate and store in routing table ? will it store or ignore ?
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.
Thanks for pointing this out. Every suggestion helps us to create content that is truly useful, so we appreciate your feedback.
When Rene introduces RD and RT in the MPLS Layer 3 VPN Explained lesson, he makes the following statement:
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
Route-map yy_TO_xx_RT
match ip address prefix-list yy_TO_xx
set extcommunity RT::11111:2100 additive
â
** the first prefix gets the community but the second one doesnât. Each prefix already has an existing standard community & excommunity, per my bgp table
The prefixes that arenât getting the additive community arenât getting leaked into the target vrf
Would appreciate some insight as to what the issue might be , from your experiences with BGP communities and vrf leaking .
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.
I found a way to mitigate this behavior, I applied the âcontinueâ command so that it can continue processing the route-map. By doing so, I now have prefixes that are being tagged with two communities.
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!