Facts to remember about BGP - Part 1

iBGP loop prevention is achieved simply by not advertising routes learned from one iBGP neighbor to another

Multihop EBGP Peerings
The default TTL for EBGP peers is 1. This means that non-directly connected EBGP peers cannot be established, because the TTL will expire in transit. By issuing the ebgp-multihop [ttl] command, the TTL can be increased to support this type of design

R8:
router bgp 100
 neighbor 155.1.79.9 remote-as 54
 neighbor 155.1.79.9 ebgp-multihop 255
 neighbor 155.1.79.9 update-source Loopback1

R9:
router bgp 54
 neighbor 204.12.8.8 remote-as 100
 neighbor 204.12.8.8 ebgp-multihop 255

Neighbor Disable-Connected-Check
EBGP can be form only on directed connected neighbors, but this feature allows to form ebgp sessions even if neighbors are not directly connected. The TTL remains 1 so there will not be neighborship if the peers are not back to back

R4:
router bgp 200
 neighbor 150.1.5.5 remote-as 100
 neighbor 150.1.5.5 disable-connected-check
 neighbor 150.1.5.5 update-source Loopback0
!
R5:
router bgp 100
 neighbor 150.1.4.4 remote-as 200
 neighbor 150.1.4.4 disable-connected-check
 neighbor 150.1.4.4 update-source Loopback0

Authenticating BGP Peerings
It uses the MD5 hash. Configuration is very straightforward and requires only the additional neighbor statement with the password option. If BGP peering occurs, authentication is successful:

R1:
router bgp 100
 neighbor 155.1.13.3 remote-as 300
 neighbor 155.1.13.3 password CISCO


R3:
router bgp 300
 neighbor 155.1.13.1 remote-as 100
 neighbor 155.1.13.1 password CISCO

Route reflectors, are used to reduce the need for fully meshed iBGP peerings in large-scale deployments. The main idea is routers clients peering only with RR which receives and distributes the client routes


iBGP Route Reflection
A route reflector can have 3 types of peers:

• EBGP peers     : Neighbors with different AS number including peers in different Sub-ASs in confederation
• Client peers   :    iBGP neighbors that have the route-reflector-client statement configured
• Non-client peers:  Normal iBGP peers that do not have the route-reflector-client statement configured.

 Routing advertisements sent from the route reflector must conform to the following 3 rules:

• Routes learned from EBGP peers can be sent to other EBGP peers, clients, and non-clients.
• Routes learned from client peers can be sent to EBGP peers, other client peers, and non-clients.
• Routes learned from non-client peers can be sent to EBGP peers, and client peers, but not other non-clients

When a route is advertised or reflected 2 new fields also checked for loop prevention:

• Originator ID: When a client learns a route from a RR, and the Originator ID is equal to its BGP Router-id, the client discard the route. (Client Loop prevention)
• Cluster-list: When a route-reflector learns a route from an iBGP peer, check in the Cluster List  for its own Cluster-ID, if it is found the RR discard the route.(RR Loop prevention)

To check from RR the reflected routes to a client:
  show ip bgp neighbors "client ip address" advertised-routes
To check from client the Originator ID or Cluster-list parameters
  show ip bgp "advertised route" "mask" 


iBGP route reflection configuration example: (R1 is RR and R2, R3 iBGP clients)

R1:
router bgp 100
 network 150.1.1.1 mask 255.255.255.255
 neighbor 155.1.0.2 remote-as 100
 neighbor 155.1.0.3 remote-as 100
 neighbor 155.1.0.2 route-reflector-client
 neighbor 155.1.0.3 route-reflector-client

R2:
router bgp 100
 network 150.1.2.2 mask 255.255.255.255
 neighbor 155.1.0.1 remote-as 100

R3:
router bgp 100
 network 150.1.3.3 mask 255.255.255.255
 neighbor 155.1.0.1 remote-as 100

Large-Scale iBGP Route Reflection with Clusters
The term “cluster” refers to a route-reflector and its clients, or multiple route-reflectors that service the same clients

• Inter-cluster peerings non-client: Could cause traffic black holes, even though there were alternate viable paths to the destinations (sacrifices redundancy)
• Inter-cluster peerings client: Each update message sent out results in a feedback loop of update messages received back in

This is a configuration of 3 RR with Inter-cluster peerings non-client between them

R1:
router bgp 100
 bgp cluster-id 150.1.1.1
 network 150.1.1.1 mask 255.255.255.255
 neighbor 155.1.146.4 remote-as 100
 neighbor 155.1.146.6 remote-as 100
 neighbor 155.1.146.4 route-reflector-client
 neighbor 155.1.146.6 route-reflector-client
 neighbor 155.1.0.5 remote-as 100
 neighbor 155.1.13.3 remote-as 100

R3:
router bgp 100
 bgp cluster-id 150.1.3.3
 network 150.1.3.3 mask 255.255.255.255
 neighbor 155.1.37.7 remote-as 100
 neighbor 155.1.79.9 remote-as 100
 neighbor 155.1.37.7 route-reflector-client
 neighbor 155.1.79.9 route-reflector-client
 neighbor 155.1.13.1 remote-as 100
 neighbor 155.1.0.5 remote-as 100
 neighbor 155.1.23.2 remote-as 200

R5:
router bgp 100
 bgp cluster-id 150.1.5.5
 network 150.1.5.5 mask 255.255.255.255
 neighbor 155.1.58.8 remote-as 100
 neighbor 155.1.58.8 route-reflector-client
 neighbor 155.1.0.1 remote-as 100
 neighbor 155.1.0.3 remote-as 100
 neighbor 155.1.0.2 remote-as 200




iBGP Confederation

• Like route reflector reduce the need for fully meshed iBGP peerings
• In confederation, a public AS is split into smaller Sub Autonomous Systems (Sub-ASs), 
• Inside Sub-AS fully meshed peering or route reflection applies
• Between Sub-ASs, EBGP advertisement rules apply
• Confederation EBGP peers are listed in bgp confederation peers statement
• bgp confederation identifier is the public AS #, tells the router is a confederation member
• Members inside a Sub-As still can have eBGP neighbors
• Confederation introduces a new BGP attribute known as the AS_CONFED_SET. The confederation set, or simply confed set, is an unordered list of Sub-ASs that is prepended onto the normal AS-Path of a BGP prefix as it is passed between Sub-ASs. The confed set, however, is stripped and replaced by the confederation identifier when a prefix is advertised to a true EBGP peer. 

In this example R1, R3 and R5 are Confederation EBGP peers, they peer with neighbors in the same Sub-AS. Only R1 and R3 configuration is show. The iBGP confederation members inside each Sub-AS miss the bgp confederation peers statement

R1:
router bgp 65146
 bgp confederation identifier 100
 bgp confederation peers 65379 65508 
 network 150.1.1.1 mask 255.255.255.255
 neighbor 155.1.13.3 remote-as 65379
 neighbor 155.1.146.4 remote-as 65146
 neighbor 155.1.146.6 remote-as 65146

R3:
router bgp 65379
 bgp confederation identifier 100
 bgp confederation peers 65146 65508 
 network 150.1.3.3 mask 255.255.255.255
 neighbor 155.1.0.5 remote-as 65508
 neighbor 155.1.13.1 remote-as 65146
 neighbor 155.1.23.2 remote-as 200
 neighbor 155.1.37.7 remote-as 65379
 neighbor 155.1.79.9 remote-as 65379