BGP free core and the internet route table

[gregsamadams]

Hi,

I'm hoping to get some guidance on how to connect IX and transit data into a network in a way that scales.

The existing network has a BGP free core which works really well.  I'm going to be setting up some dedicated border routers that just "talk" to IX points and also transit providers.

I'm just not sure how to distribute this data to other parts of the BGP free core.  I could run MPLS on the border routers, but, if we decide to take a full route table, MPLS will assign a local label to each received prefix, which is around 850k at this stage (maybe more).  The routers we have (ASR 9ks) I believe support up to 1m - so this won't scale if the table continues to grow.

What are my options for distributing prefixes around the network - I've seen suggestions of using GRE tunnels - is this a viable option?  Are there better approaches?

Thanks,

Greg

[pigallo]

Hello @gregsamadams ,

---

I'm just not sure how to distribute this data to other parts of the BGP free core.  I could run MPLS on the border routers, but, if we decide to take a full route table, MPLS will assign a local label to each received prefix, which is around 850k at this stage (maybe more).  The routers we have (ASR 9ks) I believe support up to 1m - so this won't scale if the table continues to grow.

What are my options for distributing prefixes around the network - I've seen suggestions of using GRE tunnels - is this a viable option?  Are there better approaches?

Thanks,

Greg

---

If you want to leverage MPLS switching capabilities you may implement per-ce resilient label allocation which avoid label space exhaustion in case of massive label utilization.

Resilient allocation should also supports multipath and PIC edge in case you need, so you can take advantage of it to achieve fast restoration or load sharing into your network.

Kind regards

[loris.marcellini]

Greg, interesting topic.

Question

Why would you want to have all the routers in your core to hold the full BGP routing table?

Proposed Solution

Based on the assumption you should not have full routing table in the core, here's few things

1. Assumption
   1. ]Traditional MPLS LDP labels assignments occurs for IGP learned prefixes only for a reason, you should never even think about assigning labels to the full BGP table :) (there are exception in which BGP is used to assign labels but this is not the case IMHO).
2. Design
   1. Traditional MPLS Option
      1. enable MPLS across loopbacks in the core
      2. configure BGP on the routers connecting to the IXs and redistribute a default route or short prefixes into the IGP domain (you can play around with different exit point by leveraging BGP attributes)
   2. MPLS L3VPN Option
      1. enable MPLS across loopbacks in the core
      2. create an internet VRF on the border routers and assign that to the link connecting to the IX
      3. configure BGP on the routers connecting to the IXs and leak a default route or short prefixes into the global routing table (you can play around with different exit point by leveraging BGP attributes).
   3. Result
      1. The core will have reachability to the border router and at the same time internet access. The border routers won't assign labels to every destination in the BGP table but only core loopbacks and  prefixes you decide to leak will have a label assigned.
      2. MPLS in the core ensures border routers (or Internet Routers) reachability through their loopbacks and internet access via route redistribution.route-leaking.
   4.  Documentation
      1. Actual Cisco canonical doc 
         1. https://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/multiprotocol-label-switching-vpns-mpls-vpns/47807-routeleaking.html
      2. An old post from myself
         1. https://community.cisco.com/t5/mpls/default-routes-mpls-vpn/td-p/2781448

Hope this helps.

Thanks, l.

[Adam Vitkovsky]

I always use per-ce label allocation mode.

Once you enable label mode per-ce, you’ll end up with just a few next-hop labels for your INTERENET VRF as opposed to ~850K labels.

(btw the limit of ~1M is not routing platform specific, but rather result of the fact that the label field in the header is 20bits wide)

The “label mode per-ce” -in comparison with “label mode per-vrf” –the per-ce variant also allows you to use BGP PIC for fast reroute cause it forwards traffic to CE based on label lookup rather than IP lookup.

[gregsamadams]

Thank you all for your replies.

Adam, I'm trying to see how this would work in our setup.  We only run VRF's for L3VPN customers which often don't have external access.

Our ASR9k which is doing the IX and transit is accepting all of the routes into the global routing table.  We're then distributing data throughout the network - through the BGP free core mpls to other sides of the network.

The P routers in our setup don't see the global route table (as expected), however, I'm concerned with how the border routers will cope with the label assignment to each of the prefixes in the global routing table. 

Perhaps I've mis-understood what you have suggested doing.

Thanks,

Greg 

[patoh]

hi Greg,

I think it wasn't clear from beginning that you are running Internet table in GRT.

to your concern:

---

 I'm concerned with how the border routers will cope with the label assignment to each of the prefixes in the global routing table.

---

I think this should not be a problem in your case as GRT is used, and also for LDP (by default it's not allocating labels for BGP prefixes see link)

example topology: Interent --- border PE (bPE) --- P --- PE

1) PE will learn internet prefix via BGP (from RR or bPE), do lookup and find next-hop of bPE with associated label sent by P

2) P does not know about BGP prefixes, forwarding is done based on label, in this case pop the label and send IP packet to bPE

3) bPE receives IP packet, perform lookup and send it to peer

i think this is how it should work but it should be tested in lab