BGP iBGP Flashcards
iBGP Full Mesh Requirement
AS_Path as a loop detection and prevention mechanism.
AS_Path can be used for detecting loops for eBGP neighbors because the ASN is prepended when advertising to another AS.
However, iBGP peers do not prepend their ASN to AS_Path because the NLRI would fail the validity check and would not install the prefix into the IP routing table.
No other method exists for detecting loops with iBGP sessions, and RFC 4271 prohibits the advertisement of an NLRI received from an iBGP peer to another iBGP peer.
RFC 4271 states that all BGP routers in a single AS must be fully meshed to provide a complete loop-free routing table and prevent traffic blackholing.
iBGP Prefix Advertisement Behavior
R1, R2, and R3 are all within AS 65100.
R1 has an iBGP session with R2, and R2 has an iBGP session with R3.
R1 advertises the 10.1.1.0/24 prefix to R2, which is processed and inserted into R2’s BGP table.
R2 does not advertise the 10.1.1.0/24 NLRI to R3 because it received the prefix from an iBGP peer.
To resolve this issue, R1 must form a multi-hop iBGP session so that R3 can receive the 10.1.1.0/24 prefix directly from R1.
R1 and R3 need a static route to the remote peering link, or R2 needs to advertise the 10.12.1.0 /24 and 10.23.1.0/24 networks into BGP.
iBGP Scalability Enhancements
The inability of BGP to advertise a prefix learned from one iBGP peer to another iBGP peer can lead to scalability issues within an AS.
The formula n(n - 1)/2 provides the number of sessions required, where n represents the number of routers. A full mesh topology of 5 routers requires 10 sessions, and a topology of 10 routers requires 45 sessions. iBGP scalability becomes an issue for large networks.
Route Reflectors
RFC 1966 introduces the idea that an iBGP peering can be configured so that it reflects routes to another iBGP peer.
The router that is reflecting routes is known as a route reflector (RR), and the router that is receiving reflected routes is a route reflector client.
Route Reflector Rules
Rule 1
Rule 1: A route learned from non-client can be forwarded to another eBGP and client, but not to a non-client.
This rule make sense, this is our normal iBGP split-horizon behaviour.
Route Reflector Rules
Rule 2
Rule 2: A route learned from a client can be forwarded to another eBGP peer, client and non-client.
Even the RR client that sent the advertisement receives a copy of the route, but it discards the NLRI because it sees itself as the route originator.
Route Reflector Rules
Rule 3
Rule 3: A route learned from an eBGP neighbor can be forwarded to another eBGP neighbor, a client and non-client.
Loop Prevention in RR
Removing the full mesh requirements in an iBGP topology introduces the potential for routing loops.
When RFC 1966 was drafted, two other BGP route reflector–specific attributes were added to prevent loops.
- ORIGINATOR_ID
- CLUSTER_LIST
ORIGINATOR_ID
This optional non-transitive BGP attribute is created by the first route reflector and sets the value to the RID of the router that injected/advertised the route into the AS.
If the ORIGINATOR-ID is already populated on an NLRI, it should not be overwritten.
If a router receives an NLRI with its RID in the Originator attribute, the NLRI is discarded.
CLUSTER_LIST
This non-transitive BGP attribute is updated by the route reflector.
This attribute is appended (not overwritten) by the route reflector with its cluster ID.
By default, this is the BGP identifier.
If a route reflector receives an NLRI with its cluster ID in the Cluster List attribute, the NLRI is discarded.
Out-of-Band Route Reflector
