notes: iBGP Sessions

- Cisco AD (Administrative Distance) for IBGP peers are 200.
- Has no next-hop modification by default. Thus a fully meshed iBGP between routers are required for full reachability.
- Because iBGP sessions are usually logical, it is recommended to setup iBGP sessions between loopbacks.
- iBGP loop prevention is done via route suppression/BGP split horizon
- iBGP learned routes cannot be advertised onto another iBGP neighbors.
This rule implies
>> Fully meshed iBGP peerings (n*(n-1)/2) OR
>> Route-reflection OR
>> Confederations


RR (Route-Reflectors)
*-----------------------*
- one router is incharge of reflecting a route and sending them out to other peer.
- Modifies the iBGP split-horizon rule.- Depending on the design, actual traffic is not required to go through the RR, only the updates.

- All cost to cluster RR will be equal lowest RID will be preferred.

configuration:
@ RR - complicated.

  - Configures an iBGP neighbor to be a client of this route-reflector

router bgp {asn} 

neighbor {ip-address} route-reflector-client

 
Note:  configuring rr-client will reset the ibgp peering.



- Optionally assigns a cluster-ID to the route reflector
- Cluster-ID is a 4-byte value
- Required only for clusters with redundant reflectors
- Cluster-ID cannot be changed after the first client is configured

bgp cluster-id {cluster-id}

verification:

show ip bgp neighbors

 RR (Route-Reflectors) have different clients:
1. eBGP neighbors
   - Are normal eBGP neighbors.
   - Received updates will be advertised to other eBGP neighbors, RR clients, and non-clients.

2. RR Clients
    - Are configured with "neighbor route-reflector-client" on the RR.
    - Received updates will be advertised to eBGP neighbors, other RR clients, and non-clients.

3.  Non-Client peers
     - Are normal iBGP neighbors, (non RR clients).
     - Received updates will be advertised to eBGP neighbors and RR clients.

 - RR Configuration is done only on route reflectors. RR clients use normal peering configuration but only to the RR.
 - Always configure a cluster-ID on route reflectors when the RR's are in redundant clusters.
 - The default value of the cluster-ID if not configured is the BGP router-ID on the route reflector.
        (Not necessary in non-redundant clusters, as the BGP router-ID is unique)
 - Cluster-ID will be use to determine where the routes coming from.

LAB Scenario:
prefer this router over the one with lowest RID, we can change this by using the lowest Cluster-ID.

Standby Router 
or other scenario:  establish to allow redundancy in  the failure of one peer.

@ one of the routers (standby)
- disable client to  client reflection.

no bgp client-to-client-reflection

Confederations

- Breaks an autonomous system up into smaller confederations/sub autonomous systems.
- Confederations modify the iBGP next-hop processing rule.
- It is generally recommended to use private ASN's (64512-65535).
- Neighbors inside a confederation AS must still be fully-meshed or route-reflectors must be used.
- Always start the BGP process with the sub-AS number.
- Then specify a real AS number.
- And lastly list the connected sub-AS numbers in the confederation.

configuration:

router bgp 65001

bgp confederation identifier 123

bgp confederation peers 65002 65003 - Confederation peer AS-numbers

 !

neighbor 10.1.1.4 remote-as 65001 - iBGP neighbor
neighbor 10.1.1.2 remote-as 65002 - eBGP with intra-confederation AS 
neighbor 10.1.1.3 remote-as 65003 - eBGP with intra-confederation AS
neighbor 145.1.1.2 remote-as 102 - Real eBGP session