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

BGP RIB-Failure

BGP RIB-Failure is a situation where some routes from the BGP process cannot be installed in the main routing table due to different reasons::

• A route with a better administrative distance is already installed in the routing table (i.e. a static route/route from an IGP with a better administrative distance);
• The route in question is a directly connected network (special case of the previous point with the lower administrative distance);
• The route is for a host IP address configured on the receiving BGP speaker;
• Installing the route in the routing table will cause the configured route-limit for a particular VRF to be exceeded (when using VRF);
• A memory problem on the BGP speaker prevents the route from getting installed in the RIB;

In such cases, the failed routes are marked with an r> in the list of BGP routes:

R1#sh ip bgp
BGP table version is 9, local router ID is 192.168.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
r>i192.168.0.1/32   192.168.1.1              0    100      0 i
r>i192.168.1.0/30   192.168.1.1              0    100      0 i
*>i192.168.10.0     192.168.1.1              0    100      0 i
r>i192.168.30.0     192.168.1.1              0    100      0 i
R1#

We can check all RIB-Failure routes on our BGP router with show ip bgp rib-failure :

R1#sh ip bgp rib-failure
Network Next Hop RIB-failure RIB-NH Matches
192.168.0.1/32 192.168.1.1 Own IP address n/a
192.168.1.0/30 192.168.1.1 Higher admin distance n/a
192.168.30.0 192.168.1.1 Higher admin distance n/a
R1#

If we have a look at the show ip bgp information for each of these network, we will see the individual RIB-Failure code but not much else:

R1#sh ip bgp 192.168.0.1/32
BGP routing table entry for 192.168.0.1/32, version 6
Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(4) - next-hop mismatch)
Advertised to update-groups:
1
Local, (received & used)
192.168.1.1 from 192.168.1.1 (192.168.10.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
R1#sh ip bgp 192.168.1.0/30
BGP routing table entry for 192.168.1.0/30, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(17))
Advertised to update-groups:
1
Local, (received & used)
192.168.1.1 from 192.168.1.1 (192.168.10.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
R1#sh ip bgp 192.168.30.0
BGP routing table entry for 192.168.30.0/24, version 9
Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(17))
Advertised to update-groups:
1
Local, (received & used)
192.168.1.1 from 192.168.1.1 (192.168.10.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
R1#

If we have a look at the routing table as far as each of these networks is concerned, we can find out th reason for the RIB-Failure:

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

D    192.168.30.0/24 [90/156160] via 192.168.1.9, 01:40:21, FastEthernet2/0
B    192.168.10.0/24 [200/0] via 192.168.1.1, 01:46:46
C    192.168.255.0/24 is directly connected, FastEthernet1/0
192.168.0.0/32 is subnetted, 1 subnets
C       192.168.0.1 is directly connected, Loopback0
192.168.1.0/30 is subnetted, 3 subnets
C       192.168.1.8 is directly connected, FastEthernet2/0
C       192.168.1.0 is directly connected, FastEthernet0/0
C       192.168.1.4 is directly connected, FastEthernet0/1
R1#

Each of the three routes is present in the routing table, but one of them is R1’s own IP address on Loopback0, the other one is learnt via EIGRP and is thus with a better admin distance, and the the third one is a directly connected network via Fa0/0. Even though the routes are set to RIB-Failure status, they are actually being advertised to R1’s  eBGP peer, which differs a bit from what is mentioned in Cisco’s BGP FAQ document. The lab topology is shown below for illustration.

In our test scenario R0 is announcing the three relevant networks into the iBGP process to R1, but R1 has better routes already present for all of them - either from EIGRP (.30.0/24), or a directly connected one (.1.0./30), or is it a route to its own IP address (.0.1/32). R1 itself has an eBGP peering session with R2. Let’s have a look at what R2 is receiving over this eBGP session and whether the RIB-Failure routes are being advertised and accepted over it:

R2#sh ip bgp
BGP table version is 5, local router ID is 192.168.20.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.0.1/32   192.168.1.5                            0 100 i
*> 192.168.1.0/30   192.168.1.5                            0 100 i
*> 192.168.10.0     192.168.1.5                            0 100 i
*> 192.168.30.0     192.168.1.5                            0 100 i
R2#

As we can see, all the RIB-Failure routes are being advertised and accepted normally over the eBGP peering regardless of their RIB-Failure state. They are not flagged as RIB-Failure routes on R2 and they are installed in the routing table at R2:

R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

B    192.168.30.0/24 [20/0] via 192.168.1.5, 02:27:02
B    192.168.10.0/24 [20/0] via 192.168.1.5, 02:27:02
C    192.168.20.0/24 is directly connected, Loopback0
192.168.0.0/32 is subnetted, 1 subnets
B       192.168.0.1 [20/0] via 192.168.1.5, 02:27:02
192.168.1.0/30 is subnetted, 2 subnets
B       192.168.1.0 [20/0] via 192.168.1.5, 02:27:02
C       192.168.1.4 is directly connected, FastEthernet0/0
R2#

Tags: BGP, eBGP, iBGP, RIB-Failure

VRF Lite - VRFs without MPLS

MPLS VRFs are both a popular and widely advertised solution for provider VPNs and for segregating traffic through a backbone network, and they provide and rely on a few features to sell well

• Segmentation of the network traffic from different client devices on both sides of a cloud, usually a provider cloud;
• The option of keeping the clients routing information intact while carrying it through the cloud to another client device;
• The option for the provider to carry several client routing tables through its cloud in parallel, even if they contain overlapping address spaces, including overlapping RFC1918 addressing;

The traditional solution for such a situation, based on MPLS VPNs with separate VRF instances for each client, provides all of the features mentioned above, on the basis of a few technical items:

• A routing relationship between the client (Customer Edge, aka CE) router and the border router of the provider - Provider Edge aka PE router, using the clients routing protocol of choice ;
• The advertisement of all client networks over this routing relationship, just in the same way as if the PE router were part of the client network itself ;
• The existence of at least one VRF instance per client;
• Marking on behalf of the PE device of all client routes with a specific Route Distinguisher, aka RD tag, thus forming the so-called VPNv4 address;
• Redistribution, done by the PE device, of all client routes from the client routing protocol of choice into MP-iBGP, running only between the PE devices on both sides of the provider cloud;
• The existence of a stable IGP, sustaining the internal routing in the provider cloud, and consequently the MPLS core and MP-iBGP;
• The existence of a stable and scalable MPLS core;

All this is great if you are an ISP having a ready and stable MPLS core. However, if you are trying to develop a custom solution for your specific corporate network needs, there are a few challengfes you will face in terms of MPLS VPNs. Most of these challenges are related to device resource planning:

• You need 3 routing protocols on every PE device in your network (protocol that the client is running, MP-iBGP and a separate internal routing protocol to hold your own core network together);
• The PE devices need to be powerful and reliable enough to run and scale the 3 routing protocols needed, as well as the required number of VRFs or parallel routing tables;
• The core MPLS routers need to be powerful and scalable enough themselves;;

What the VRF Lite feature can offer is VRF functionality without the need for MPLS and its inherent complexity and resource usage, and without the need of multiple routing protocols on the PE devices. This way we can successfully carry several routing tables in parallel through a cloud without having MPLS inside it.

Using VRFs with MPLS implies that the segregation of the different client routing tables is achieved through using a separate protocol between the PE devices, carryng these client routing tables, tagged accordingly with the right RD tag.  In order to enable the same segregation of routing tables with VRF Lite, that is without MPLS, we need to have separate connectivity over which to run multiple routing neighborships between our devices, with each neighborship only carrying a single VRFs routing table.

We can use the following two lab scenarios to illustrate the differences between the two VRF configurations.

› Continue reading

Tags: BGP, EIGRP, metro ethernet, MP-iBGP, MPLS, OSPF, Routing, VRF, VRF Lite