Lab 93 - IBGP Route-Reflector

Prerequisites: CCNP level skills.

Topology

Note!
Use the Lab 92 configuration.

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Ensure reachability between 172.16.102.0/24 and 172.16.105.0/24.

Lab Solution

Task 1

Ensure reachability between 172.16.102.0/24 and 172.16.105.0/24.

Since IBGP Split-Horizon rule forbids to advertise prefixes learned from IBGP peer to another IBGP peer, R1 does not forward 172.16.102.0/24 to R5 and 172.16.105.0/24 to R2. There are two solutions to this problem:

• Route-Reflector configuration on R1 (disabling IBGP Split-Horizon)
• Configure BGP Confederations

Pic. 2 - R3's BGP Table.

Notice!

R3 does not receive 172.16.102.0/24 from R1.

Pic. 3 - R4's BGP Table.

Notice!

R4 does not receive 172.16.105.0/24 from R1.

R1 Configuration:

!

router bgp 134
 no synchronization
 bgp router-id 172.16.101.1
 bgp log-neighbor-changes
 network 172.16.101.0 mask 255.255.255.0
 neighbor 10.1.13.3 remote-as 134
 neighbor 10.1.13.3 route-reflector-client
 neighbor 10.1.14.4 remote-as 134
 neighbor 10.1.14.4 route-reflector-client
 no auto-summary

!

Verfication:

Pic. 4 - Ping Test.

The rules with route-reflectors are as in below:

Pic.5 - Route-Reflector-Rules

Prefixes are getting propagated this time since R1 receives them from route-reflector-clients and passes them to other clients.

Pic. 6 - Prefixes from Route-Reflector-Clients.

Once Route-Reflectors are configured, two additional attributes begin to play a major role when Route-Reflector Clusters are in place (multiple route-reflectors for redundancy purposes).

Pic. 7 - Route Originator and Cluster List.

If the design is not done correctly a router can receive the prefix it originated itself. The originator address will help discover this and reject the update. Also, if route-reflector receives the prefix with its own address in the cluster list it will ignore it.