BGP Route Reflectors

Module Introduction

Before you start the hands-on part of this module, you should load the appropriate configuration and verify that the testbed is up and running by executing the corresponding robot file:

student@tour:~/trainings_resources/robot$ robot bgp_rr/bgp_rr_setup.robot

BGP Route Reflection

We have learned in the last module that BGP peers do not advertise prefixes learned from one internal neighbor to another internal neighbor in order to avoid loops.

As a consequence, all internal BGP peers need to peer with all other internal BGP peers resulting in a full-mesh of BGP peerings. With n routers within an autonomous system, this results in n*(n-1)/2 BGP sessions which need to be maintained.

A special internal BGP peer called a route reflector was defined in RFC 4456 which allows to re-advertised iBGP learned routes to certain iBGP peers called route reflector clients in the following way:

  • A route learned from a non-client iBGP peer is advertised (reflected) to all client peers.

  • A route learned from a client iBGP peer is advertised (reflected) to all non-client and client peers.

Two new BGP attributes are introduced to avoid routing loops: the originator-id and the cluster-list. Each route reflector is assigned a cluster-id which is prepended to the cluster-list. If a route reflector learns a route that already has his own cluster-id in the cluster-list, it detects the loop.

The route reflector properties are configured within the peer-group on a per address-family basis.

The route reflector client is not aware of the fact that is part of a route reflector cluster, i.e., configuration is only done on the route reflector.

We use the following setup:

ibgp rr lab
Figure 1. iBGP Route Reflector Lab Setup
Exercise 1: BGP Route Reflector

Configure R1 to be a route reflector with clients R2 (192.168.0.2) and R3 (192.168.0.3). The cluster-id should be set to 1.1.1.1.

Click to reveal the answer
cfg> set instance default protocol bgp hostname R1
cfg> set instance default protocol bgp local-as 65000
cfg> set instance default protocol bgp router-id 192.168.0.1
cfg> set instance default protocol bgp address-family ipv4 unicast
cfg> set instance default protocol bgp peer ipv4 192.168.0.2 192.168.0.1
cfg> set instance default protocol bgp peer ipv4 192.168.0.2 192.168.0.1 peer-group INTERNAL
cfg> set instance default protocol bgp peer ipv4 192.168.0.3 192.168.0.1
cfg> set instance default protocol bgp peer ipv4 192.168.0.3 192.168.0.1 peer-group INTERNAL
cfg> set instance default protocol bgp peer-group INTERNAL
cfg> set instance default protocol bgp peer-group INTERNAL remote-as 65000
cfg> set instance default protocol bgp peer-group INTERNAL address-family ipv4 unicast
cfg> set instance default protocol bgp peer-group INTERNAL address-family ipv4 unicast route-reflect-client true
cfg> set instance default protocol bgp cluster-id 1.1.1.1
cfg> show bgp rib-in ipv4 unicast peer R2
Instance: default, AFI: ipv4, SAFI: unicast
 Hostname: R2, Peer IP: 192.168.0.2, Source IP: 192.168.0.1, Received routes: 1
    Prefix                    Next Hop                  MED        Local Preference  AS Path    Status
    192.168.0.100/32          192.168.0.2               0          100               65100      Valid
cfg> show bgp rib-out ipv4 unicast peer R3
Instance: default, AFI: ipv4, SAFI: unicast
  Peer: R3, Sent routes: 2
    Prefix                 MED         Local Preference  Origin          Next Hop         AS Path
    192.168.0.100/32       0           100               Incomplete      192.168.0.2      65100
    192.168.0.200/32       0           100               Incomplete      192.168.0.3      65200
Do not use the nexthop-self option on the route reflector.

Looking at the reflected routes in more detail, we can see the new attributes cluster-list and originator-id. The originator-id is set to the client from which the route was received.

cfg> show bgp rib-out ipv4 unicast peer R3 192.168.0.100/32
Instance: default, AFI: ipv4, SAFI: unicast
  Peer: R3, Sent routes: 1
    Prefix: 192.168.0.100/32, RD: None, Send path ID: 0, Next hop: 192.168.0.2
      Peer: -, Peer domain: -, Route source: -, Received path ID: None, Path hash: 41037a0c202a0ee57836c069af3f707025d4b5c9cd21cfb4
      AS path: 65100, Originator ID: 192.168.0.2, Origin: Incomplete
      Community: None, Extended community: None, Large community: None
      Cluster list: ['1.1.1.1']
      IGP metric: None, Local preference: 100, Multi exit discriminator: 0
      Preference: None, External route: None, Readvertised route: None
      Label: -, Last update: 0d:00h:12m:12s

Summary

If you have completed the exercise, you can check the results by executing

student@tour:~/trainings_resources/robot$ robot bgp_rr/bgp_rr_verify.robot