BGP-Free Service Provider Core in Pictures


Imagine a small ISP with a customer-facing PE-router (A), two PE-routers providing upstream connectivity (B and D), a core router (C), and a route reflector (R). The ISP is running IPv4 and IPv6 natively (no MPLS).

When an end-customer sends a packet toward an Internet destination (a Facebook server, for example), each router in the ISP network has to examine the packet, perform destination address lookup in its forwarding table (FIB), and forward the packet toward the next hop.

Assuming the ISP is not running BGP on the core router, the core router is not aware of any destination outside of its own AS, and thus drops the packet sent toward Facebook.

You can use default routing as a problem-solving kludge (B and D advertise default routes into the ISP’s network), or deploy BGP on the core router (C).

After a BGP session between C and R is configured, C receives all global BGP routes, and is able to forward packets toward external destinations:

There is another solution: if you deploy MPLS in the network, LDP automatically builds virtual circuits (Label Switched Paths – LSP) between any two routers.

Cisco IOS builds LSPs for all IGP destinations, Junos only for the loopback interfaces. More details in Junos and Cisco IOS: MPLS and LDP, and Junos Day One: MPLS behind the scenes.

Ingress PE-routers use LSPs toward BGP next hops to send packets toward external destinations learned through BGP. The core router (C) thus receives labeled packet that it can switch toward the next hop without inspecting the destination IPv4 or IPv6 address, and thus there is no need to run BGP on C.

The last core router might send labeled or unlabeled IP packet (due to penultimate hop popping) to the egress PE-router. You can influence this behavior with mpls ldp explicit- null configuration command.

Need help?

If you need a second opinion or a review of your MPLS or BGP design, check out the ExpertExpress service. You could also engage our professional services team in a full-blown network design/implementation project or customized on-site training/design workshop.


  1. Hello Ivan,

    It is common inside any ISP core network to use at least one RR?

    Can you share with us, why is that?

  2. Alex White-Robinson11 January, 2012 22:56

    Articles like this are why I subscribed to this blog in the first place. This was fantastic, cheers Ivan.

  3. Scaling IBGP. Without a RR, you need a full mesh of IBGP sessions (between every pair of BGP-speaking routers).

  4. So this will be required ONLY if iBGP is running inside core?

  5. Christophe Lemaire20 January, 2012 18:12

    Without RR you would need #PE x (#PE - 1) / z iBGP sessions
    With two RR (for redundancy) you would need 2 x #PE +1 iBGP sessions

    #PE being the number of PE in your network... So if you have 6 or more PE, RR decrease the number of iBGP sessions required...


