How to Advertise Routes from an IBGP Peer to another using Route Reflector

How to Advertise Routes from an IBGP Peer to another using Route Reflector

25179
Created On 09/25/18 19:50 PM - Last Modified 04/20/20 23:58 PM


Resolution

 

This article discusses the scenario where routes learned from an IBGP peer are not advertised to another
IBGP due to the split horizon rule and how to advertise these routes using the Palo Alto Networks firewall as a route reflector.


The following topology is used for illustrative purposes:

 

 2016-04-12_10-21-45.png

 

  • B1 and B3 are IBGP peers of B2.
  • IBGP peering is in established state between B1-B2 and B2-B3.
  • B1 and B3 are advertising the routes 5.5.5.0/24 and 8.8.8.0/24 respectively to B2.
     

 

 

 BGP routes are present in the local BGP RIB of B2:

 

admin@B1> show routing protocol bgp loc-rib
 VIRTUAL ROUTER: B1 (id 22)
==========
Prefix             Nexthop         Peer       Weight   LocPrf    Org     MED    flap      AS-Path
*5.5.5.0/24                        Local        0       100      i/c      0      0
 
total routes shown: 1

 

 

admin@B2> show routing protocol bgp loc-rib
 VIRTUAL ROUTER: B2 (id 23)
==========
Prefix             Nexthop         Peer       Weight   LocPrf      Org     MED   flap     AS-Path
*5.5.5.0/24         1.1.1.1         B1           0      100     i/c       0     0
*8.8.8.0/24         3.3.3.2         B3           0      100     i/c       0     0
 
total routes shown: 2

 

B2 contains the routes advertised from B1 and B3  in its local RIB

 

 

admin@B3> show routing protocol bgp loc-rib
 VIRTUAL ROUTER: B3 (id 24)
==========
Prefix             Nexthop         Peer       Weight   LocPrf   Org     MED    flap   AS-Path
*8.8.8.0/24                         Local       0       100     i/c      0      0
 
total routes shown: 1

 

 

 

Problem:

 

No routes are advertised by B2 due to the split horizon rule:

 

admin@B1> show routing protocol bgp rib-out
VIRTUAL ROUTER: B1 (id 22)
==========
Prefix             Nexthop         Peer       Originator       Adv Status   Aggr       Status            AS-Path
5.5.5.0/24         1.1.1.1         B1-B2     0.0.0.0         advertised    no       aggregation
 
total routes shown: 1

 

 

admin@B2> show routing protocol bgp rib-out
VIRTUAL ROUTER: B2 (id 23)
==========
Prefix             Nexthop         Peer       Originator       Adv Status Aggr Status     AS-Path
 
total routes shown: 0

 

 B2 is not advertising any routes to either B1 or B3 even though B2 contains the advertised routes in its local RIB

 

 

admin@B3> show routing protocol bgp rib-out
VIRTUAL ROUTER: B3 (id 24)
==========
Prefix             Nexthop         Peer       Originator       Adv Status            Aggr       Status          AS-Path
8.8.8.0/24         3.3.3.2         B3-B2     0.0.0.0         advertised             no       aggregation
 
total routes shown: 1

 

 

 

 

Solution:

 

To enable B2 to advertise the routes learnt from IBGP peers to other IBGP peers, make it a route reflector.

No configuration is required on the peers themselves ,but only the device, which will be acting as a route reflector.

This requires the IBGP peers to be configured as client/non-client on B2:

 

Consider the following  aspects of advertisement while configuring the peers as client/non-client :

 

  •   A route learned from a client can be forwarded to another EBGP neighbor, client and non-client.
  •   A route learned from a non-client can be forwarded to another EBGP neighbor and client, but not to a non-client.

 

 

Note:  If both  peers are configured as 'Non-Clients,' then no routes are advertised.

             'Non-Clients' is the default setting for the peer, hence route reflector is disabled by default.

 

 

In this example, both peers B1 and B3 are configured as route reflector clients and B2 is configured as a route reflector server:

 

 

B1.png

 

B3.png

 

Configure the following attributes for the route reflector, which are used for loop prevention:

 

Reflector Cluster ID - used as Cluster ID

Router ID -  used as Originator ID

 

CID_OID.png

 

Optionally, the Next Hop attribute can be selected as Original or Self for the routes advertised by the route reflector:

 

self hop.png

 

Routes are now being adverstised by B2:

 

admin@B1> show routing protocol bgp rib-out
VIRTUAL ROUTER: B1 (id 22)
==========
Prefix             Nexthop         Peer       Originator       Adv Status        Aggr Status         AS-Path
5.5.5.0/24         1.1.1.1         B1-B2     0.0.0.0       advertised     no aggregation
 
total routes shown: 1

 

 

admin@B2> show routing protocol bgp rib-out
VIRTUAL ROUTER: B2 (id 23)
==========
Prefix             Nexthop         Peer       Originator       Adv Status             Aggr Status             AS-Path
8.8.8.0/24         3.3.3.2         B1         3.3.3.2            advertised           no aggregation
5.5.5.0/24         1.1.1.1         B3         1.1.1.1            advertised           no aggregation
 
total routes shown: 2

 

Both 8.8.8.0/24  and  5.5.5.0/24 are now being advertised by B2

 

 

admin@B3> show routing protocol bgp rib-out
VIRTUAL ROUTER: B3 (id 24)
==========
Prefix             Nexthop         Peer       Originator       Adv Status             Aggr Status       AS-Path
8.8.8.0/24         3.3.3.2         B3-B2     0.0.0.0         advertised            no aggregation
 
total routes shown: 1

 

 

Routes can be seen in the BGP local RIB of B1 and B2:

 

admin@B1> show routing protocol bgp loc-rib
VIRTUAL ROUTER: B1 (id 22)
==========
Prefix             Nexthop         Peer       Weight   LocPrf      Org     MED flap AS-Path
8.8.8.0/24         3.3.3.2         B1-B2         0     100         i/c        0        0
*5.5.5.0/24                       Local          0     100         i/c        0        0
 
total routes shown: 2

 

Route 8.8.8.0/24 is now in local-rib of B1

 

 

admin@B2> show routing protocol bgp loc-rib
VIRTUAL ROUTER: B2 (id 23)
==========
Prefix             Nexthop         Peer       Weight   LocPrf Org             MED flap AS-Path
*5.5.5.0/24         1.1.1.1         B1           0     100        i/c              0   0
*8.8.8.0/24         3.3.3.2         B3          0     100        i/c              0   0
 
total routes shown: 2

 

 

admin@B3> show routing protocol bgp loc-rib
VIRTUAL ROUTER: B3 (id 24)
==========
Prefix             Nexthop         Peer      Weight   LocPrf Org     MED flap AS-Path
5.5.5.0/24         1.1.1.1         B3-B2     0     100     i/c      0   0
*8.8.8.0/24                       Local      0     100     i/c      0   0
 
total routes shown: 2

 

Route 5.5.5.0/24 is now in local-rib of B3

 

 

 

The following mechanisms are used to avoid loops using the Cluster ID and Originator ID attributes:

 

  • When a BGP router receives a route from an iBGP neighbor in the incoming update and detects the presence of its own Router-ID in the Originator-ID attribute, it will reject the update.
  • When a BGP router receives a route from an iBGP neighbor that's configured to operate as a route reflector, and in the incoming update, detects the presence of its own Cluster-ID in the Cluster-list attribute, it will reject the update.

 

 



Attachments
Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClfrCAC&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Attachments
Choose Language