Lab - Configure BGP Route Reflector

Topology

---

Addressing Table

---

Objectives

In this lab, you will learn how to use policy-based routing to influence path section.

• Part 1: Configure Basic Device Settings and Interface Addressing
• Part 2: Examine and Verify OSPFv3 and BGP Reachability
• Part 3: Configure R2 as a BGP Route Reflector
• Part 4: Verify BGP Adjacencies and Tables
• Part 5: Verify IP Routing Tables

---

Background / Scenario

In this lab, AS 65000 uses OSPFv3 as its Interior Gateway Protocol (IGP) to provide internal reachability for both IPv4 and IPv6. OSPFv3 is configured with separate address families, allowing a single IGP to support dual-stack operation. Loopback interfaces are used to represent internal IPv4 and IPv6 prefixes within AS 65000. These prefixes simulate customer or internal networks and are later advertised into BGP.

AS 65000 runs BGP using address families (AFs) for both IPv4 and IPv6, enabling a unified BGP process to handle dual-stack routing. External autonomous systems AS 65001 and AS 65002 use traditional BGP for IPv4 and the IPv6 unicast address family for IPv6. Because IPv6 routing in BGP is supported only through address families, all IPv6 BGP configuration and route exchange in this lab occurs within the IPv6 AF context.

Although routers R1, R2, and R3 in AS 65000 are already configured for BGP, no internal BGP (iBGP) neighbor adjacencies have been configured between them at this point in the lab. In a traditional iBGP design, these routers would form a full-mesh of iBGP sessions to ensure that all BGP routes are shared within the autonomous system. However, full-mesh iBGP does not scale well as the number of routers increases. In this lab, instead of configuring a full mesh, R2 will be deployed as a BGP route reflector, allowing R1 and R3 to exchange BGP routing information through R2 using a scalable route reflector design.

Routers D1 and D2 are already configured for BGP and maintain eBGP adjacencies with routers R1 and R3, respectively. These routers originate their local prefixes into BGP and represent external autonomous systems connected to AS 65000.

Note: Although the BGP standards (e.g., RFC 4271) define the abbreviations as EBGP and IBGP, modern vendor documentation often uses the lower-case forms eBGP and iBGP to visually distinguish “external” or “internal” from the core BGP protocol name. We will use lower case e and i to make is easier to visually distinguish these two protocols.

---

Required Resources - Sergio Jiménez's Version

For this lab I am using GNS3, where I have deployed:

• 3 Routers (Cisco IOSv)
  
• 2 Switches (Cisco IOSvL2)

---

Instructions

Part 1: Configure Basic Device Settings and Interface Addressing

BGP-RR-R1

conf t
hostname BGP-RR-R1
!
no ip domain lookup
line con 0
 exec-timeout 0 0
 logging sync
!
ipv6 unicast-routing
!
router ospfv3 1
 !
 address-family ipv4 unicast
  router-id 1.1.1.1
 exit-address-family
 !
 address-family ipv6 unicast
  router-id 1.1.1.1
 exit-address-family
!
interface GigabitEthernet0/0
 ip address 10.0.0.2 255.255.255.252
 ipv6 address 2001:db8:feed:1::2/64
 ipv6 address fe80::1:1 link-local
 ospfv3 network point-to-point
 ospfv3 1 ipv6 area 0
 ospfv3 1 ipv4 area 0
 no shutdown
 exit
!
interface GigabitEthernet0/1
 ip address 209.165.200.5 255.255.255.252
 ipv6 address 2001:db8:209:4::5/64
 ipv6 address fe80::1:2 link-local
 no shutdown
 exit
!
router bgp 65000
 bgp log-neighbor-changes
 neighbor 2001:DB8:209:4::6 remote-as 65001
 neighbor 209.165.200.6 remote-as 65001
 !
 address-family ipv4
  neighbor 209.165.200.6 activate
 exit-address-family
 !
 address-family ipv6
  neighbor 2001:DB8:209:4::6 activate
 exit-address-family
!
end
wr mem
!

BGP-RR-R2

conf t
hostname BGP-RR-R2
!
no ip domain lookup
line con 0
 exec-timeout 0 0
 logging sync
!
ipv6 unicast-routing
!
router ospfv3 1
 !
 address-family ipv4 unicast
  router-id 2.2.2.2
 exit-address-family
 !
 address-family ipv6 unicast
  router-id 2.2.2.2
 exit-address-family
!
interface GigabitEthernet0/0
 ip address 10.0.0.1 255.255.255.252
 ipv6 address 2001:db8:feed:1::1/64
 ipv6 address fe80::2:1 link-local
 ospfv3 network point-to-point
 ospfv3 1 ipv6 area 0
 ospfv3 1 ipv4 area 0
 no shutdown
 exit
!
interface GigabitEthernet0/1
 ip address 10.0.0.5 255.255.255.252
 ipv6 address 2001:db8:feed:2::5/64
 ipv6 address fe80::2:2 link-local
 ospfv3 network point-to-point
 ospfv3 1 ipv6 area 0
 ospfv3 1 ipv4 area 0
 no shutdown
 exit
!
interface loopback0
 ip address 172.16.1.1 255.255.255.0
 ipv6 enable
 ospfv3 1 ipv4 area 0
 ospfv3 network point-to-point
 no shutdown
 exit
!
interface loopback1
 ip address 172.16.2.1 255.255.255.0
 ipv6 enable
 ospfv3 1 ipv4 area 0
 ospfv3 network point-to-point
 no shutdown
 exit
!
interface loopback2
 ipv6 address 2001:db8:a001:1::1/64
 ospfv3 1 ipv6 area 0
 ospfv3 network point-to-point
 no shutdown
 exit
!
interface loopback3
 ipv6 address 2001:db8:a002:1::1/64
 ospfv3 1 ipv6 area 0
 ospfv3 network point-to-point
 no shutdown
 exit
!
router bgp 65000
 bgp log-neighbor-changes
 !
 address-family ipv4
  network 172.16.0.0 mask 255.255.0.0
 exit-address-family
 !
 address-family ipv6
  network 2001:DB8:A000::/36
 exit-address-family
!
ip route 172.16.0.0 255.255.0.0 Null0
ipv6 route 2001:db8:a000::/36 Null0
!
end
wr mem
!

BGP-RR-R3

conf t
hostname BGP-RR-R3
!
no ip domain lookup
line con 0
 exec-timeout 0 0
 logging sync
!
ip routing
ipv6 unicast-routing
!
router ospfv3 1
 !
 address-family ipv4 unicast
  router-id 3.3.3.3
 exit-address-family
 !
 address-family ipv6 unicast
  router-id 3.3.3.3
 exit-address-family
!
interface GigabitEthernet0/0
 ip address 10.0.0.6 255.255.255.252
 ipv6 address 2001:db8:feed:2::6/64
 ipv6 address fe80::3:1 link-local
 ospfv3 network point-to-point
 ospfv3 1 ipv6 area 0
 ospfv3 1 ipv4 area 0
 no shutdown
 exit
!
interface GigabitEthernet0/1
 ip address 209.165.200.9 255.255.255.252
 ipv6 address 2001:db8:209:8::9/64
 ipv6 address fe80::3:2 link-local
 no shutdown
 exit
!
router bgp 65000
 bgp log-neighbor-changes
 neighbor 2001:DB8:209:8::10 remote-as 65002
 neighbor 209.165.200.10 remote-as 65002
 !
 address-family ipv4
  neighbor 209.165.200.10 activate
 exit-address-family
 !
 address-family ipv6
  neighbor 2001:DB8:209:8::10 activate
 exit-address-family
!
end
wr mem
!

BGP-RR-D1

conf t
hostname BGP-RR-D1
!
no ip domain lookup
line con 0
 exec-timeout 0 0
 logging sync
!
ip routing
ipv6 unicast-routing
!
interface GigabitEthernet1/1
 no switchport
 ip address 209.165.200.6 255.255.255.252
 ipv6 address 2001:db8:209:4::6/64
 ipv6 address fe80::d1:1 link-local
 no shutdown
 exit
!
interface loopback0
 ip address 192.168.1.1 255.255.255.0
 ! ipv6 enable
 no shutdown
 exit
!
interface loopback1
 ip address 192.168.2.1 255.255.255.0
 ! ipv6 enable
 no shutdown
 exit
!
interface loopback2
 ipv6 address 2001:db8:cab::1/48
 no shutdown
 exit
!
router bgp 65001
 bgp log-neighbor-changes
 neighbor 2001:DB8:209:4::5 remote-as 65000
 neighbor 209.165.200.5 remote-as 65000
 !
 address-family ipv4
  network 192.168.1.0 mask 255.255.255.0
  network 192.168.2.0 mask 255.255.255.0
  neighbor 209.165.200.5 activate
 exit-address-family
 !
 address-family ipv6
  network 2001:DB8:CAB::/48
  neighbor 2001:DB8:209:4::5 activate
 exit-address-family
!
end
wr mem
!

BGP-RR-D2

conf t
hostname BGP-RR-D2
!
no ip domain lookup
line con 0
 exec-timeout 0 0
 logging sync
!
ip routing
ipv6 unicast-routing
!
interface GigabitEthernet1/1
 no switchport
 ip address 209.165.200.10 255.255.255.252
 ipv6 address 2001:db8:209:8::10/64
 ipv6 address fe80::d2:1 link-local
 no shutdown
 exit
!
interface loopback0
 ip address 192.168.10.1 255.255.255.0
 ! ipv6 enable
 no shutdown
 exit
!
interface loopback1
 ip address 192.168.20.1 255.255.255.0
 ! ipv6 enable
 no shutdown
 exit
!
interface loopback2
 ipv6 address 2001:db8:acad::1/48
 no shutdown
 exit
!
router bgp 65002
 bgp log-neighbor-changes
 neighbor 2001:DB8:209:8::9 remote-as 65000
 neighbor 209.165.200.9 remote-as 65000
 !
 address-family ipv4
  network 192.168.10.0 mask 255.255.255.0
  network 192.168.20.0 mask 255.255.255.0
  neighbor 209.165.200.9 activate
 exit-address-family
 !
 address-family ipv6
  network 2001:DB8:ACAD::/48
  neighbor 2001:DB8:209:8::9 activate
 exit-address-family
!
end
wr mem
!

---

Part 2: Examine and Verify OSPFv3 and BGP Reachability

In the configurations in Part 1, OSPFv3 provides the internal routing foundation for AS 65000, enabling full IPv4 and IPv6 reachability between routers R1, R2, and R3. Each router in AS 65000 can reach every other router at the IP layer. At this stage, OSPFv3 is functioning strictly as the underlay protocol, providing transport reachability for BGP sessions and next hops within the autonomous system.

External connectivity is provided using eBGP. R1 peers with D1 in AS 65001, and R3 peers with D2 in AS 65002. As a result, R1 is receiving IPv4 prefixes (192.168.1.0/24 and 192.168.2.0/24) and the IPv6 prefix (2001:db8:cab::/48) originated by AS 65001, and R3 is receiving IPv4 prefixes (192.168.10.0/24 and 192.168.20.0/24) and the IPv6 prefix (2001:db8:acad::/48) originated by AS 65002.

However, no iBGP neighbor relationships have been configured within AS 65000. Because of this, the BGP routes learned via eBGP on R1 and R3 are not propagated to the rest of the autonomous system. Although router R2 has been configured to advertise aggregate IPv4 prefix (172.16.0.0/16) and IPv6 prefix (2001:db8:cab::/48), it currently has no iBGP neighbors and therefore does not exchange BGP routing information with R1 or R3.

In this part of the lab, you will verify OSPFv3 reachability within AS 65000 and confirm the current BGP routing state.

Step 1: Verify IP routing tables on R1, R2, and R3.

1. Examine the IPv4 and IPv6 routing tables on R1.
   
   On R1, the OSPF route to the 10.0.0.4/30 network provides reachability to R3 through R2, confirming that OSPFv3 is successfully exchanging internal routing information within AS 65000. This internal OSPF connectivity allows R1 to reach all routers in the autonomous system at the IP layer.
   
   The 172.16.1.0/24 and 172.16.2.0/24 networks are also learned via OSPFv3 from R2. These networks originate from loopback interfaces on R2 and are advertised individually into OSPFv3. Although R2 has been configured to advertise the summarized prefix 172.16.0.0/16 into BGP, R1 does not see this aggregate route in its routing table because there is no iBGP adjacency between R1 and R2. As a result, BGP routing information generated by R2 is not exchanged within AS 65000 at this time.
   
   R1 does see the 192.168.1.0/24 and 192.168.2.0/24 networks in its routing table as BGP routes, learned via eBGP from D1 in AS 65001. These routes are present only on R1 because they were learned from an external neighbor and have not been propagated to other routers within AS 65000.
   
   This is similar for the information in R3's IPv6 routing table.
   
   
2. Examine the IP routing tables on R3.
3. Examine the IP routing tables on R2.
   
   In this lab, R2 is the single origination point for the aggregated prefixes to simplify the configuration and highlight the role of iBGP. The network 172.16.0.0/16 is an aggregation all subnets such as Loopback0 172.16.1.0/24 and Loopback1 172.16.2.0/24 networks. In production networks, these summaries are often originated on multiple routers to avoid a single point of failure.
   
   When an AS advertises only an aggregate prefix to its external BGP peers, internal routing changes do not trigger external BGP updates, as long as some route within the aggregate remains reachable. AS 65001 advertises aggregated prefixes so that internal routing changes do not trigger external BGP updates, which reflects real-world design practices used to improve stability and reduce BGP churn on the Internet. Traffic will be forwarded to AS then dropped if prefix is not present.
   
   On R2, there are no OSPF-learned routes in the routing tables because, from R2’s perspective, there are no remote OSPF networks to learn. Its OSPF-enabled interfaces and loopbacks are all directly connected. 
   
   At this stage, no iBGP neighbor adjacencies are configured, so R2 has no BGP routes in either the IPv4 or IPv6 routing tables. 
   
   The static routes to Null0 ensure that the aggregate prefixes 172.16.0.0/16 and 2001:DB8:A000::/36 exist in R2’s routing tables, because BGP will only advertise a network when an exact match exists in the routing table. Using Null0 is a safe way to advertise aggregate routes and prevent traffic from being forwarded if no more-specific route exists.
   

Step 2: Verify IP routing tables on D1 and D2.

1. Examine the IP routing tables on D1.
   
   On D1, the IPv4 and IPv6 routing tables currently contain only directly connected and local routes. These include the loopback networks 192.168.1.0/24, 192.168.2.0/24, and 2001:DB8:CAB::/48, as well as the directly connected link to R1.
   
   Although an eBGP session is established with R1 in AS 65000, D1 is not receiving any BGP routes from R1 at this time. This is expected because R1 is not advertising any BGP-learned or internal routes back toward D1. As a result, D1 has no BGP routes installed in its routing tables.
   
   
2. Examine similar output for the IP routing tables on D2.

Step 3: Examine BGP adjacencies and tables for eBGP on R1/D1 and R3/D2.

The eBGP adjacencies between R1 and D1, and between R3 and D2, have already been indirectly verified in the previous section by observing that R1 and R3 have installed IPv4 and IPv6 BGP routes learned from AS 65001 and AS 65002, respectively. The presence of these routes in the IP routing tables confirms that the eBGP sessions are established and operational.

The following commands are provided for reference and optional verification. To keep the lab concise, command output is omitted.

BGP Adjacencies

• show ip bgp summary
• show bgp ipv6 unicast summary

BGP Tables

• show bgp ipv4 unicast
• show bgp ipv6 unicast

These commands allow you to confirm the state of the eBGP sessions and view the BGP routing information exchanged with the external autonomous systems.

Step 4: Examine BGP adjacencies for iBGP on R1, R2, and R3.

1. Examine the BGP adjacencies on R1. Router R1 has an established eBGP adjacency with D1 in AS 65001 for both IPv4 and IPv6. The BGP summary output confirms that the sessions are stable and operational. R1 is receiving two IPv4 prefixes and one IPv6 prefix from its eBGP neighbor, which correspond to the networks originated by D1. This confirms that R1 is successfully learning external routes from AS 65001 and installing them into its BGP table.
   
   R1 currently has no iBGP adjacencies because iBGP neighbor adjacencies have not yet been configured at this stage of this lab.
   
   
2. Examine the BGP adjacencies on R3 to see similar output.
3. Router R2 is internal to AS 65000 and is intended to participate in iBGP only. Because no iBGP neighbor adjacencies have been configured at this stage of the lab, R2 has no BGP adjacencies for either IPv4 or IPv6, and therefore no BGP routing information is exchanged or displayed.

---

Part 3: Configure R2 as a BGP Route Reflector

At this point in the lab, a full-mesh iBGP topology could be configured between routers R1, R2, and R3, requiring iBGP neighbor adjacencies between R1–R2, R2–R3, and R1–R3. While this approach works in small networks, it does not scale well as the number of routers increases. A full mesh requires n(n−1)/2 iBGP neighbor relationships, which increases configuration complexity, operational overhead, and the likelihood of configuration errors.

To address these scalability challenges, BGP route reflectors can be used. In this lab, R2 will be configured as a route reflector server, while R1 and R3 will be configured as route reflector clients. Each route reflector client establishes a single iBGP adjacency with the route reflector. The route reflector then reflects eligible BGP routes between its clients, allowing routes learned from one client to be advertised to other clients without requiring a full-mesh of iBGP sessions.

This changes how BGP routes are distributed but does not change how packets are forwarded. Once routes are learned via BGP, packet forwarding still relies on the underlying IGP (OSPFv3 in this lab) to resolve next hops and provide end-to-end connectivity between routers. Packet forwarding continues to rely on the IGP (e.g. OSPFv3) and next-hop reachability.

This design significantly reduces the number of iBGP neighbor configurations, simplifies troubleshooting, and improves scalability, while preserving correct BGP behavior within the autonomous system. Route reflection is therefore a common and essential technique in larger enterprise and service provider networks.

Note: While BGP route reflectors greatly improve scalability, they can also introduce a single point of failure if only one route reflector is deployed. To mitigate this risk in production networks, it is common to deploy multiple route reflectors and configure each client to peer with two or more route reflectors. This design maintains route visibility and resiliency while preserving the scalability benefits of route reflection.

Step 1: Configure R2 as the route reflector.

R2 will function as the route reflector for AS 65000. It will maintain iBGP sessions with R1 and R3 and reflect eligible BGP routes between them.

Cluster IDs are used to prevent routing loops between route reflectors. They are especially important when multiple route reflectors are deployed. Although only one route reflector is used in this lab, the cluster ID is included for completeness and realism. 

These commands are identical to standard iBGP neighbor configurations, with the exception of the routereflector-client statements:

• neighbor 10.0.0.2 route-reflector-client
• neighbor 10.0.0.6 route-reflector-client
  
• neighbor 2001:db8:feed:1::2 route-reflector-client
• neighbor 2001:db8:feed:2::6 route-reflector-client

The statements tell R2 that these neighbors are clients, so R2 is allowed to reflect (re-advertise) routes learned from one client to the other client(s). This behavior overrides the iBGP split-horizon rule, allowing the route reflector to advertise iBGP-learned routes between its clients and eliminating the need for a full-mesh iBGP configuration.

Router R2, acting as the iBGP route reflector, is responsible for advertising the aggregated IPv4 and IPv6 prefixes for AS 65000 into BGP. Because these prefixes are originated on R2, any BGP client that establishes an iBGP adjacency with R2 will receive these route updates. This ensures that all internal BGP routers have consistent visibility of the autonomous system’s aggregated prefixes without requiring a full-mesh iBGP configuration.

Step 2: Configure R1 as a route reflector client.

R1 is configured as a route reflector client by establishing iBGP adjacencies with R2 for both IPv4 and IPv6. Because R1 learns routes via eBGP from AS 65001, the next-hop-self command is used so that routes reflected within AS 65000 have a reachable next hop.

From the route reflector client’s perspective, the BGP configuration is identical to a normal iBGP configuration. The only difference is that the client forms iBGP adjacencies only with the route reflector, rather than with every other iBGP router in the autonomous system.

Step 3: Configure R3 as a route reflector client.

R3 is configured in the same manner as R1. 

---

Part 4: Verify BGP Adjacencies and Tables

At this point, R1 and R3 have established iBGP adjacencies with the route reflector R2. With route reflection enabled, BGP updates learned by any router within AS 65000 are now shared throughout the autonomous system without requiring a full-mesh iBGP configuration. In this section, you will verify that the iBGP adjacencies are established and that IPv4 and IPv6 BGP routes are visible on R1, R2, and R3.

A route reflector client may form iBGP adjacencies with one or more route reflectors, and it may also form iBGP adjacencies with non-route reflector routers if required by the network design. Similarly, a route reflector may form iBGP adjacencies with both route reflector clients and non-client routers, depending on the network design. Route reflection reduces the need for a full-mesh iBGP topology, but it does not prohibit additional iBGP adjacencies when they are operationally or architecturally necessary. 

Step 1: Verify R1's iBGP adjacency with router reflector R2.

On R1, the only iBGP adjacency is with the route reflector R2, through which R1 receives all internal BGP route updates for AS 65000. The neighbor 10.0.0.1 (AS 65000) represents R2, and the PfxRcd value indicates that R1 is now receiving three IPv4 prefixes via iBGP from the route reflector. This confirms that R2 is reflecting BGP routes learned within AS 65000 to R1.

Similarly, the IPv6 BGP summary shows an established iBGP adjacency with R2 at 2001:DB8:FEED:1::1 (AS 65000), with two IPv6 prefixes received. This verifies that IPv6 BGP route reflection is also functioning correctly.

Step 2: Verify R2's iBGP adjacency with router reflector R2.

The BGP summary output on R3 shows similar behavior to R1.

Step 3: Verify route reflector R2's iBGP adjacencies with clients R1 and R3.

The BGP summary output on R2, acting as the route reflector, shows established iBGP adjacencies with both route reflector clients, R1 and R3. R2 is receiving BGP prefixes from each client for both IPv4 and IPv6, confirming that the route reflector is successfully exchanging routing information with all clients. This verifies that R2 is positioned to reflect BGP routes between R1 and R3 within AS 65000. R2 functions solely as an internal BGP router within AS 65000 and has no eBGP neighbor relationships.

Step 4: Verify Routers as route reflector clients on R2.

The show ip bgp neighbor command on R2 explicitly identifies R1 and R3 as route reflector clients, as indicated by the “Route-Reflector Client” field in the neighbor output.

---

Part 5: Verify IP Routing Tables

In this part, you will examine the IP routing tables on each router to validate that the route reflector configuration is working as expected. The routing tables should now reflect consistent IPv4 and IPv6 reachability across AS 65000, confirming that BGP routes are being successfully shared through the route reflector.

Step 1: Examine the IP routing tables on route reflector client R1.

The BGP routing tables on R1 now show all BGP-originated routes from AS 65000, AS 65001, and AS 65002, confirming that the route reflector configuration is working correctly. Routes learned from AS 65002 are installed with R3 as the next hop, indicating that R1 is receiving these routes via iBGP reflection through R2 and that next-hop reachability has been preserved.

Step 2: Examine the IP routing tables on route reflector client R3.

Similar to R1, the BGP routing tables on R3 show all BGP-originated routes from AS 65000, AS 65001, and AS 65002, confirming full route visibility within AS 65000.

Step 3: Examine the IP routing tables on route reflector R2.

The BGP routing tables on R2, acting as the iBGP-only route reflector, show BGP routes learned from both R1 and R3. As the route reflector, R2 uses this information to reflect BGP routes between R1 and R3, providing full BGP route visibility within AS 65000.

Step 4: Examine the IP routing tables on edge routers D1 and D2.

The BGP routing tables on D1 and D2 show that they are now receiving routes from both AS 65001 and AS 65002 via AS 65000, confirming that the internal BGP configuration in AS 65000 is functioning correctly. The presence of these routes indicates that AS 65000 is operating as a transit autonomous system, successfully advertising learned BGP routes between external autonomous systems.