BGP Synchronization and MPLS



    I have the following small topology currently setup. But I can I understand how could this be working. R11, R12, and R13 are all running IS-IS as their IGP. R11 and R13 have an I-BGP session between themselves and they are both adverting a remote prefix that lives behind each of them. Since R12 is not running BGP it will drop the packet do to synchronization issue between the BGP and IGP. So to fix this issue I decided to use MPLS. So I enabled MPLS on all three routers which will then fix the issue since R13 is imposing a label and R12 does not have to route the packet but instead switch the packet based on the label so it won't drop it. However, what I don't understand is how does R13 no what label to impose when forwarding the packet towards R12. Is it just imposing label 16 for all the prefixes behind R11 since thats the same label it's using to reach the peering ip on R11. Below is some output from each of the devices. If you need more please let me know.


Thank you





  • peetypeety ✭✭

    MPLS knows to only assign labels to IGP next hops. BGP uses its "next hop" field as a "last hop" - if you look at the BGP table on R11, you'll see an address on R13 (depending on if/how you configured the BGP update-source). CEF then gives you "recursive routing", whereby that last hop is recursively routed to a next hop (which in this case includes a label).

    Explained in a different "order", let's imagine that R13 boots up, and at least one interface (loopback, perhaps) transitions to UP. When it does, an entry is created in the RIB, which creates an entry in the FIB, and a label is assigned (once you've enabled MPLS as a feature with 'mpls ip' on interfaces). As other connected, static, and IGP routes go into the RIB, they go into the FIB and labels are assigned in the LFIB. As soon as an LDP neighbor is established (R13 to R12 in this example), R13 tells R12 "my label table looks like this: bleeeeeech" (and pukes its label table over the LDP session). R12 should have a reasonably similar RIB/FIB/LFIB, and now adds entries in the LFIB to essentially say "my label for prefix x/y is 32, and R13's label is 73". When that process repeats in the R12->R11 direction, R11 now knows R13's routes, assigns its own label, and knows R12's label equivalents for those prefixes. It can now send packets destined for R13's interfaces with R12's desired label, which can then swap (if transiting R13) or pop (if R13 is the "ultimate" hop, making R12 the penultimate hop) the label so it's forwarded correctly.

  • Peety,

         Thank you for your explanation.


Sign In or Register to comment.