iBGP Lab

Introduction

The second step of this workshop lab will set up the iBGP so that our routers can exchange internal and external prefixes with each other.

Configuring iBGP

The next step is to configure iBGP mesh between the four routers in each autonomous system. We’ll use a route-reflector set up to handle this, as this is very common practice today, and full mesh iBGP does not scale, as was covered in the presentations.

We will make the core router the route reflector, as is standard practice. The border router will be a client, the access router will be a client, and the peering router will be another client. Before setting up the iBGP route reflector, we need to consider the following:

the border routers connect to transit ISPs, so can in theory receive the entire global routing table from the upstream (either as a default route, or as every individual announced prefix).
the peering routers connect to private and public peers - the peering router should only hear routes that the peers should be able to receive. A common mistake is for peering routers in service provider backbones to carry the full Internet routing table, resulting in bandwidth hijack, misrouted traffic, and so on.
the access routers only connect to end user customers. The router typically does not need to carry the full BGP table from the Internet. All it needs is a default route pointing to the core, and some visibility of the prefixes originated within the rest of the autonomous system.

iBGP Basics

We will initialise BGP on all the routers in our autonomous system, changing the Cisco defaults to those which are considered industry best practices.

These will enable multi-protocol BGP, set metric calculation to be deterministic¹, and fix the BGP default protocol distance so that it is much higher (i.e. less important) than any other routing protocol.

Also note that Cisco IOS assumes that all peers will exchange IPv4 prefixes even if they are running another IP protocol - of course this makes no sense, so we will turn off that assumption too.

router bgp X0
 bgp log-neighbor-changes
 bgp deterministic-med
 no bgp default ipv4-unicast
!
 address-family ipv4
  distance bgp 200 200 200
!
 address-family ipv6
  distance bgp 200 200 200
!

Peer-groups on the Core Router

Focusing now on the core router, we will create two peer groups, one for the standard iBGP mesh (passing full routes), the other for use with peering and access routers (passing only local AS routes). As discussed in the presentation, make sure you enter all the IPv4 neighbour configuration under the IPv4 address family, and all the IPv6 neighbour configuration under the IPv6 address family. Cisco IOS will sort out whether the configuration should fit under the preamble or under the relevant address family itself.

Let’s set up the full routes peer-group first - this one passes on all routes it hears from all BGP neighbours, even those from outside our autonomous system. First for IPv4:

router bgp X0
!
 address-family ipv4
  neighbor ibgp-full peer-group
  neighbor ibgp-full description Full Routes
  neighbor ibgp-full remote-as X0
  neighbor ibgp-full update-source loopback0
  neighbor ibgp-full next-hop-self
  neighbor ibgp-full password BGPlab
  neighbor ibgp-full send-community
  neighbor ibgp-full route-reflector-client
!

And then for IPv6 - notice that we use the same name for the peer-group as we did for IPv4, but with the addition of “v6”. This makes it easier to identify peer-groups with the same function but applying to different address families.

router bgp X0
!
 address-family ipv6
  neighbor ibgpv6-full peer-group
  neighbor ibgpv6-full description Full Routes
  neighbor ibgpv6-full remote-as X0
  neighbor ibgpv6-full update-source loopback0
  neighbor ibgpv6-full next-hop-self
  neighbor ibgpv6-full password BGPlab
  neighbor ibgpv6-full send-community
  neighbor ibgpv6-full route-reflector-client
!

Next we set up the partial routes peer-group - this one only passes on routes which are local to the autonomous system. We accomplish this by creating an AS-PATH filter to only allow prefixes originated by the local AS:

ip as-path access-list 10 permit ^$

This filter says to allow any prefix which does not have the AS-PATH attribute set - ^$ means empty AS-PATH.

Then we will set up the peer-group. It is identical to the full routes peer-group, save for the addition of the line including the filter-list. First for IPv4:

router bgp X0
!
 address-family ipv4
  neighbor ibgp-partial peer-group
  neighbor ibgp-partial description Local Routes only
  neighbor ibgp-partial remote-as X0
  neighbor ibgp-partial update-source loopback0
  neighbor ibgp-partial next-hop-self
  neighbor ibgp-partial password BGPlab
  neighbor ibgp-partial send-community
  neighbor ibgp-partial route-reflector-client
  neighbor ibgp-partial filter-list 10 out
!

and then for IPv6 (noting that the AS-PATH filter can be used in both IPv4 and IPv6 peer-groups):

router bgp X0
!
 address-family ipv6
  neighbor ibgpv6-partial peer-group
  neighbor ibgpv6-partial description Local Routes only
  neighbor ibgpv6-partial remote-as X0
  neighbor ibgpv6-partial update-source loopback0
  neighbor ibgpv6-partial next-hop-self
  neighbor ibgpv6-partial password BGPlab
  neighbor ibgpv6-partial send-community
  neighbor ibgpv6-partial route-reflector-client
  neighbor ibgpv6-partial filter-list 10 out
!

Finally we apply the newly created peer-groups to the iBGP peers of the core router. First we do this for IPv4:

router bgp X0
!
 address-family ipv4
  neighbor 100.68.X.1 peer-group ibgp-full
  neighbor 100.68.X.1 description iBGP with Border
  neighbor 100.68.X.1 activate
  neighbor 100.68.X.3 peer-group ibgp-partial
  neighbor 100.68.X.3 description iBGP with Peering
  neighbor 100.68.X.3 activate
  neighbor 100.68.X.4 peer-group ibgp-partial
  neighbor 100.68.X.4 description iBGP with Access
  neighbor 100.68.X.4 activate
!

and then we do it for IPv6:

router bgp X0
!
 address-family ipv6
  neighbor 2001:DB8:X::1 peer-group ibgpv6-full
  neighbor 2001:DB8:X::1 description iBGP with Border
  neighbor 2001:DB8:X::1 activate
  neighbor 2001:DB8:X::3 peer-group ibgpv6-partial
  neighbor 2001:DB8:X::3 description iBGP with Peering
  neighbor 2001:DB8:X::3 activate
  neighbor 2001:DB8:X::4 peer-group ibgpv6-partial
  neighbor 2001:DB8:X::4 description iBGP with Access
  neighbor 2001:DB8:X::4 activate
!

The only difference between the peer-group ibgp-partial and the peer-group ibgp-full is that the former has that one additional line only permitting prefixes originated by the local AS to go to that router. So if the upstream provider sends a default route, or any prefixes from the global BGP table, they will now not make their way to the peering router. While we have used an AS-path filter here, we could also use BGP communities (much more scalable!).

Configuring iBGP on the Border, Access and Peering Routers

We now turn to the border, access and peering routers, and will configure iBGP on those as well. We’ll follow the same ideas as we used for the Core router, only the border, access and peering routers are route reflector clients. Here is a configuration example (applicable to any of the border, access or peering routers).

First off we set up and apply the IPv4 peer-group:

router bgp X0
!
 address-family ipv4
  neighbor ibgp-rr peer-group
  neighbor ibgp-rr description iBGP with RR
  neighbor ibgp-rr remote-as X0
  neighbor ibgp-rr update-source loopback0
  neighbor ibgp-rr next-hop-self
  neighbor ibgp-rr password BGPlab
  neighbor ibgp-rr send-community
!
  neighbor 100.68.X.2 peer-group ibgp-rr
  neighbor 100.68.X.2 description iBGP with Core
!

And then we set up and apply the IPv6 peer-group - use the same principle as we did earlier on the Core Router: use the same peer-group name, just add in v6 to distinguish the two address families:

router bgp X0
!
 address-family ipv6
  neighbor ibgpv6-rr peer-group
  neighbor ibgpv6-rr description iBGP with RR
  neighbor ibgpv6-rr remote-as X0
  neighbor ibgpv6-rr update-source loopback0
  neighbor ibgpv6-rr next-hop-self
  neighbor ibgpv6-rr password BGPlab
  neighbor ibgpv6-rr send-community
!
  neighbor 2001:DB8:X::2 peer-group ibgpv6-rr
  neighbor 2001:DB8:X::2 description iBGP with Core
!

Originating Aggregates from the Core Router

We will now originate our prefixes into iBGP. We will only do this on the core router (common practice is to originate prefixes on the core routers in a network operator’s backbone, never on the peering or border routers). We now add in network statements to cover our IPv4 and IPv6 address blocks. Here is an example of the configuration needed:

router bgp X0
!
 address-family ipv4
  network 100.68.X.0 mask 255.255.255.0
!
 address-family ipv6
  network 2001:DB8:X::/48
!
ip route 100.68.X.0 255.255.255.0 Null0
ipv6 route 2001:DB8:X::/48 Null0

Don’t forget the pull up routes for the aggregate - the network statement in Cisco IOS only tells BGP to put that address block into BGP if the matched block is in the global RIB - and the simplest way to install it in the global RIB is to set up a static route pointing to the Null0 interface.

Originating Server network from the Core Router

We also need to originate the server subnet from the core router. We could have done this using IS-IS, but if we follow the best practice of minimising the number of prefixes carried in IS-IS, we can just as easily carry the prefix around in iBGP.

We now add the necessary network statement to cover the IPv4 and IPv6 subnet used for the server appliance. Here is an example of the configuration needed:

router bgp X0
!
 address-family ipv4
  network 100.68.X.28 mask 255.255.255.252
!
 address-family ipv6
  network 2001:DB8:X:21::/64
!

Improving Routing Security on the Peering Router

The peering router is just that, a router that peers with other network operators. It does not provide any transit. The peers should only see the routes that you want them to see (basically what you originate from your AS and any customers). We’ve made sure of this by putting in a route filter on the core router route-reflector so that the peering router can only see locally originated routes.

It is also a good idea to null route the default route, as we will soon be distributing a default route around the AS using IS-IS. So on the peering router we now do:

ip route 0.0.0.0 0.0.0.0 null0
ipv6 route ::/0 null0

Now, once we set up the IXP connectivity later on in the workshop, if any of the IXP participants point a default route to the local network, the traffic will simply be dumped in the Null interface of the peering router. Only traffic for specific destinations which are available in the routing table on the IXP peering router will be forwarded to the rest of the network. This is a very important network security requirement.

Adding a customer route on the Access Router

We will now set up static routes on the Access Router pointing towards the Customer router and have those routes announced by IBGP so that the rest of our AS can see the Customer router (and vice-versa), something that has not been possible up to now.

Take the address subnets assigned for the “End User Space 1” (a /26 for IPv4 and a /52 for IPv6) and on the Access router, point static routes to the Customer router point-to-point link address. And then put the same address subnets into BGP via a network statement - once the static route is functional (the other end of the link is reachable), BGP will announce the subnets.

Here is an example configuration for the Access router.

ip route 100.68.X.64 255.255.255.192 100.68.X.35
ipv6 route 2001:DB8:X:4000::/52 2001:DB8:X:31::1
!
router bgp X0
 address-family ipv4
  network 100.68.X.64 mask 255.255.255.192
!
 address-family ipv6
  network 2001:DB8:X:4000::/52
!

Once this has been configured you should then see the customer IPv4 /26 and IPv6 /52 visible in the iBGP across the whole AS. Check on the Border, Peering and Core routers, and make sure the prefix is visible. Use these commands:

show ip bgp
show bgp ipv6 unicast

Default route on Customer Router

To complete the connectivity for the customer end-site we need to set up a static default route (IPv4 and IPv6) on the Customer router pointing to the Access router. In an earlier lab, we already created a source anchor point for the address space we have assigned to the customer using a Loopback interface.

All we need to do now is point the entire IPv4 and IPv6 blocks to the Null0 interface. We have a target to test connectivity to, as well as following best practices by Null routing any address space which is not in use.

Here is an example for the Customer router:

ip route 0.0.0.0 0.0.0.0 100.68.X.34
ip route 100.68.X.64 255.255.255.192 Null0
!
ipv6 route ::/0 2001:DB8:X:31::
ipv6 route 2001:DB8:X:4000::/52 Null0
!

Testing

Once this has been completed, test the connectivity across the routers in your AS again. Can you reach them all still? Also check that the customer routes and the AS’s aggregate are known within iBGP as well. Do you remember the IPv4 and IPv6 BGP commands you need to use?

Please consult the BGP Attributes presentation for background on what “Deterministic MED” is and why it is important to set it.↩