NetNotes

Sample transit BGP core configuration

I will be doing a a series of labs exploring BGP and MPLS, how they could or could not work together, what problems MPLS solves and causes, and how its configuration and maintenance are done. I will start with a simulated segment of a sample ISP, running BGP on all routers, and will move to an environment running MPLS on the core devices and BGP on the provider edges. I will further explore the different options presented after the MPLS migration, like VPNs, Traffic Engineering and VPLS.

This post covers the first lab, about bringing the sample BGP core up, and will give me an option to practice some BGP related stuff, including hierrarchical route reflectors with (just a bit of ) redundancy, route filtering with prefix-lists, as-paths and route-maps, and some very basic stuff with BGP communities.

Contents

Topology
Addressing
Configuration
- Internal routing within ISP1
- iBGP sessions
- eBGP sessions and route filters
- Inbound route filters
- Outbound route filters
- Route tagging with BGP community strings
- BGP configuration on PE devices
- Complete configurations

This is the simple topology we are starting with:

We have a sample ISP environment, significantly simplified for lab purposes (that was the total number of routers I was able to run in dynamips in my current configuration). The provider is running BGP on all devices, for AS65001. The physical links in the toplogy could change as we go along, and at the start are exactly following the BGP sessions - we are running a pair of redundant core route reflectors in the backbone (Core_RR1 and Core_RR2), to reflect routes between the POPs. There are a total of three POPs - two for customer connectivity and one, called IXP, to represent an external peering point, similar to a real-world Internet Exchange Point. To limit the number of devices we need to run in dynamips, the BGP design is significantly simplified - each client POP is consisting of a single POP route reflector (POP_RRCS), fully meshed with iBGP to the core route reflectors, and running iBGP sessions to the PE routers in the POP. The POP route reflector routers are clients to the core route reflectors and servers for the PE routers. The PE routers are running eBGP to the customers - there are two customers, each of them having two locations, each of which is connected to a different POP. We will use this further to run MPLS VPNs between the individual customer locations. To limit the number of devices we need to run on dynamips, the IXP POP is consisting of a single edge router only, running iBGP as a client to the core route reflectors and eBGP to the external peer EXT_PE in AS65002.

In the real world, and depending on the scale of the provider network, such a design could be much more redundant, with a pair of route reflectors in each POP, including the IXP POPs, or running confederations in some places, instead of hierrarchical route reflectors. However, the presented limited topology should be enough to illustrate the main things MPLS is used for in an ISP core environment.

The addressing scheme is documented in the topology, including the addresses for the internal core interconnections, the address space delegated to each POP, and the address space used by the customers internally. Loopbacks on the customer edge routers are used to inject some customer routes from both locations into the network, simulating some internal customer network connectivity. › Continue reading

Tags: as-path filters, BGP, BGP Communities, eBGP, iBGP, prefix-lists, route reflectors, route-maps