How to Advertise Routes from an IBGP Peer to another using Route Reflector
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:
-
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:
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
Optionally, the Next Hop attribute can be selected as Original or Self for the routes advertised by the route reflector:
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.