Skip to main content
oarslan
Staff
oarslan
Staff
May 20, 2020

Technical Tip: Configuring BGP route reflector

  • May 20, 2020
  • 0 replies
  • 37987 views

Description

 

This article describes how to configure a BGP route reflector to reduce the number of connections required in an AS.

 

The BGP split horizon rule in iBGP prevents route updates received from one iBGP neighbor from being sent to another, thus avoiding loops within the autonomous system. Available solutions for this challenge (the iBGP split horizon rule's impact on route propagation) include:

  1. Establish a full mesh of iBGP neighbor relationships where every BGP peer within the AS forms a direct neighborship with all other BGP peers.
  2. A more scalable solution is to designate one or two routers (for redundancy) as route reflectors.


The purpose of the route reflector is concentrate BGP sessions.
Multiple BGP routers can peer with a central point called a route reflector rather than peer with every other router in a full mesh.
All the other IBGP routers become route reflector clients.

 

Scope

 

FortiGate.

Solution

 

IBGP requires a full mesh between all BGP-speaking routers. This can cause:

 

  1. A large number of TCP sessions: (n * (n – 1)) / 2 IBGP sessions are required (where n is BGP speakers within AS).
  2. Unnecessary duplicate routing traffic.

A design like below will require (5 * 4) / 2  = 10 iBGP sessions:

 
One solution for reducing the number of BGP peers within an AS is route reflection.
Rather than each BGP system having to peer with every other BGP system with the AS, each BGP speaker instead peers with a router reflector.
 
Routing advertisements sent to the route reflector are then reflected out to all of the other BGP speakers.
In summary, route reflectors modify IBGP split-horizon rules.

When a route-reflector is used, the BGP peering sessions will appear as below:
 
 
In this case, 'FGT-2', 'FGT-3', 'FGT-4', and 'FGT-5' will only peer with 'FGT-1' (Route Reflector). For example 'FGT-2' BGP neighbor config will be as below.
 
config router bgp
    config neighbor
        edit "172.16.10.1"
            set next-hop-self enable
            set remote-as 101
            set update-source "Loop_FGT2"
        next
end
end
 
Route reflector ('FGT-1') peers with each FortiGate within AS 101 and configuration needs CLI as explained below.
 
config router bgp
config neighbor
    edit "172.16.10.2"
        set next-hop-self enable
        set remote-as 101
        set update-source "Loop_FGT1"
        set route-reflector-client enable
    next
    edit "172.16.10.3"
        set next-hop-self enable
        set remote-as 101
        set update-source "Loop_FGT1"
        set route-reflector-client enable
    next
    edit "172.16.10.4"
        set next-hop-self enable
        set remote-as 101
        set update-source "Loop_FGT1"
        set route-reflector-client enable
    next
    edit "172.16.10.5"
        set next-hop-self enable
        set remote-as 101
        set update-source "Loop_FGT1"
        set route-reflector-client enable
next
end

end

 

Note:

A Route Reflector does not modify any existing BGP attributes including NEXT_HOP, AS_PATH, LOCAL_PREF, and MED for a reflected route advertised to a Route-Reflector client, see the article 'Technical Tip: FortiGate as BGP Route Reflector does not modify attributes for reflected routes'. This is to avoid potential routing loops.

By default, a route reflector is used to reduce the full mesh requirements of IBGP, not to enforce a hub-and-spoke or 'star' network design for data traffic.

 

In v6.4.2 and later a route reflector can modify NEXT_HOP of all reflected routes by enabling 'next-hop-self-rr', see the article 'Technical Tip: How to modify BGP next hop for route reflector peering'.

Terms & ConditionsAccessibility statement