• Eliminates need for full mesh
    • Peering is only needed to RR
    • Similar to OSPF DR
      • Minimizes prefix replication.
      • One update to RR, RR sends to clients.
      • No modification of attributes when reflecting routes.
  • Loop Prevention:
    • Performed through Cluster ID.
      • Discards routes received from its own cluster ID.
    • Sets originator ID attribute to the router-id of RR client on routes.
      • Originator ID received from client and client uses for loop prevention.
  • RR Peering
    • EBGP Peers
    • iBGP Client Peers
    • iBGP Non-Client Peers
  • RR Updates
    • Processes differently depending on type of neighbor/peer.
    • EBGP
      • Passes to EBGP peers, clients, & non-clients.
    • Client learned routes
      • Pass to EBGP Peers, clients, & non-clients.
    • Non-Client learned routes
      • Pass to EBGP Peers and clients.

Large Design

  • Should not use single RR
  • RR Cluster allows for redundancy and hierarchy
  • RRs in same cluster use same cluster-id.
  • Performed via address family
    • no fate sharing
      • ex. IPv4 RR vs. IPv6 RR
  • Inter-cluster peering
    • Can be client or non-client peerings
      • Depends on design
  • Cluster-ID
    • Based on router-id
    • Default is all RR in separate cluster.

Virtual Route Reflectors:

  • RR does not need to be in data-path
    • No need to forward through RR necessarily, sometimes there for only NLRI.
  • No need to install routes in RIB/FIB if not in data path.
  • Selective RIB
    • Prevents NLRI from being installed in RIB and FIB.
    • ‘table-map <route-map> filter’
    • Can scale to millions of VPNv4 routes.
    • Reflection is occurring, no routing table install.

BGP Confederation:

  • Minimizes iBGP full mesh because it splits autonomous system into multiple autonomous systems.
    • Full mesh remains within sub-AS.
    • Sub-AS to Sub-AS acts like eBGP.
  • Confederation unknown to devices outside of confederation.
  • Typically uses private AS
  • Can use different IGPs within each Sub-AS.
  • Next-hop, Local-pref, and MED are kept across Sub-AS EBGP peerings.
  • Confederation Loop Prevention
    • AS_CONFED_SEQUENCE
    • AS_CONFED_SET
    • Never leaves confederation

RR vs. Confederation:

  • Both accomplish same thing.
  • Migration paths are different.
    • To confederation difficult.
      • Greenfield confederation is much easier.
    • Migration to RR is easy, add peers and remove old ones.

Basic Route Reflector Config:

Below is a set of routers all running as iBGP peers to R5 in AS 100.

Each router has a loopback IP associated with their hostname.

R5 = 5.5.5.5/24
R1 = 1.1.1.1/24
R2 = 2.2.2.2/24
R3 = 3.3.3.3/24
R4 = 4.4.4.4/24
R6 = 6.6.6.6/24

R3 is connected to R4 with the subnet 172.34.0.0/24 and it’s being advertised into BGP, and R5 is receiving that route (ignore RIB failure, ospf is running in background which is preferred over iBGP).

All of the other iBGP peers will not receive this route because of the default rules and loop preventions mechanisms. To allow R5 to pass on these routes to additional iBGP peers, we’ll need to make it function as a Route-Reflector.

After adding the following command, ‘neighbor <neighbor ip> route-reflector-client’, the routers neighboring with R5 are now receiving the advertised route from R3.

R2 receiving route advertised from R3:

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s