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