CCNP Route Lab 6-4, BGP Route Reflectors and Route Filters

CCNP Route Lab 6-4, BGP Route Reflectors and Route Filters




  • Configure IBGP routers to use a route reflector and a simple route filter.

The International Travel Agency maintains a full-mesh IBGP network that has quickly scaled beyond 100 routers. The company wants to implement route reflectors to work around the full-mesh IBGP requirement. Configure a small cluster and observe how BGP operates in this configuration. Use IP prefix filters to control the updates between IBGP peers.

Note: This lab uses Cisco 1841 routers with Cisco IOS Release 12.4(24)T1 and the Advanced IP Services image c1841 -advipservicesk9-mz.124-24.T1 .bin. You can use other routers (such as a 2801 or 2811) and Cisco IOS Software versions if they have comparable capabilities and features. Depending on the router or switch model and Cisco IOS Software version, the commands available and output produced might vary from what is shown in this lab.

Required Resources

  • 3 routers (Cisco 1841 with Cisco IOS Release 12.4(24)T1 Advanced IP Services or comparable)
  • Serial and console cables

Step 1: Prepare the routers for the lab.
Cable the network as shown in the topology diagram. Erase the startup configuration and reload each router to clear previous configurations. Do not configure Loopback 0 on SanJose3 at this time.

Step 2: Configure the hostname and interface addresses.

You can copy and paste the following configurations into your routers to begin.

Router R1 (hostname SanJose1)

Router R2 (hostname SanJose2)

Router R3 (hostname SanJose3)

Note: Do not configure R3 (SanJose3) with loopback 0 at this time. That will be done in a later step.

Step 3: Configure RIPv2.
a. Build and configure the network according to the diagram. Use RIPv2 as the IGP. Do not configure the network under the RIP process.

b. Issue the show ip route command on the routers to verify that each router has a complete routing table.

c. Run the following Tcl script on all routers to verify connectivity.

Step 4: Configure IBGP peers and route reflectors.
In this lab, you will configure a route reflector. By default, a router that receives an EBGP route advertises it to its EBGP and IBGP peers. However, if it receives it through IBGP, it does not advertise it to its IBGP peers, as a loop prevention mechanism. To maintain loop prevention, a route reflector adds two optional, nontransitive BGP attributes to each reflected route, the ORIGINATOR_ID and CLUSTER_LIST. It uses these attributes in a similar way to AS_PATH list to prevent routing loops from occurring. See for more information.

However, because of this behavior, the only way for all IBGP routers to receive a route after it is originated into the AS is to have a full mesh of IBGP peers. This can get complex with a large number of peers. A route reflector allows a topology to get around the IBGP limitation of having to have a full mesh. To do this, a route reflector specifies some of its neighbors as route reflector clients. When a route reflector receives an update from a route reflector client, it can pass it on to its other clients. The route reflector would also pass that client learned route on to its other non-client peers (both IBGP and EBGP peers). Similarly, a route learned from a non-client peer (again, from either an IBGP or EBGP peer) would be passed on to its client peers. This greatly simplifies configuration because only the route reflector needs to know all the other peers. The clients do not even know that they are clients. To them, it is just a normal IBGP peering relationship. You can even set up multiple route reflectors in a more advanced configuration for redundancy.

a. Configure the IBGP peers for BGP. Later, you will configure SanJose2 as the route reflector. However, first configure it to peer with both of the other routers.

After SanJose2 is configured, configure the other two routers as route reflector clients. Remember that to set up clients simply, configure peering between the client and the server. IBGP does not need to be configured in a full mesh.

b. Issue the following commands on SanJose1:

c. Issue the following commands on SanJose3:

d. Use the show ip bgp neighbors command to verify that SanJose2 has established a peering relationship with both SanJose1 and SanJose3. Troubleshoot as necessary.

SanJose1 and SanJose3 should not have established a connection. Why?
No neighbor statements were created for that adjacency. Therefore, the routers will not attempt to bring up that adjacency.

SanJose1 and SanJose3 were not configured with the appropriate BGP neighbor command. As route reflector clients, SanJose1 and SanJose3 do not need to reach an established state.

Step 5: Inject a network into BGP.
a. To observe the full effect of using a route reflector, configure SanJose3 to inject external routing information into BGP.

This configuration forces SanJose3 to inject the external route into BGP. Use the show ip route command to check if SanJose2 has picked up this route through BGP. SanJose2 should have a route to

What is the next hop for this route? Explain.
The next hop is because that is the source IP address used on SanJose3 to establish BGP
adjacency with SanJose2.

b. Verify that you can ping from SanJose2. If not, troubleshoot.

c. Check the routing table of SanJose1. There should not be a route to Why?
The default behavior of IBGP is to not advertise routes received through IBGP to other IBGP peers.

d. Remember that SanJose1 is not configured to peer with SanJose3. To eliminate the need for a full IBGP mesh, SanJose2 must be configured as a route reflector. Issue the following commands on SanJose2:

e. Verify that an IBGP cluster was successfully created by issuing the show ip protocols command on SanJose2. The output of this command should indicate that SanJose2 is a route reflector.

How many clients does SanJose2 have?
SanJose2 has two clients.

f. Issue the show ip protocols command on SanJose1. The output of this command does not include information about route reflectors. Remember that SanJose1 is a client and not a route reflector server, so it is unaware of route reflection.

g. Finally, verify that route reflection is working by checking the routing table on SanJose1. SanJose1 will have a route to network

Is the IP address of the next hop of this route on the SanJose1 table? Explain.
Yes, because the default behavior of IBGP is to not change the next-hop address.

Notice that SanJose1 is not directly connected to the IP network for the next hop. Why?
Hint: From which router did SanJose1 learn the route?
The default behavior of IBGP is to not change the next-hop address. The actual next hop is R2 S0/0/0

h. Ping from SanJose1. This ping should be successful.
Notice that SanJose1 pings to R3 are successful even though the next-hop address is not on a directly-connected network. For example, the next-hop address could be 1 on R2 if it were not for the behavior of IBGP.

Step 6: Inject a summary address into BGP.
a. For the purpose of this lab, configure SanJose3 to inject a summary address into BGP.

Note: By default, BGP on Cisco routers advertises both aggregate routes and the individual component routes. If only the aggregate route is to be advertised, use the aggregate-address network mask summary-only command.

b. On SanJose2, issue the following command:

According to the output of this command, which address aggregated this route?
The address that aggregated the route is

What indicates that route reflection is involved in this process?
The output states that it was received from a route reflector client.

Is there an indication that the ATOMIC_AGGREGATE attribute has been set?
Yes. In the list of attributes at the end of the output, the tag atomic-aggregate appears.

c. SanJose2 should, in turn, reflect this route to SanJose1. Check both the routing table and BGP table on SanJose1 to be sure. Both the route to and the supernet route should be installed in the SanJose1 routing table and the BGP table.

The International Travel Agency has decided to filter specific routes to the address space. Configure a route filter to prevent SanJose2 from sending the route to its other clients, in this case to SanJose1.

d. Issue the following commands on SanJose2:

e. Return to SanJose1, issue the clear ip bgp * soft command, and verify that the prefix list has done its job by issuing a show ip bgp command. Troubleshoot as necessary.

Unlike before, where routes to and were present, now only one route to in the routing and BGP tables should be seen. Troubleshoot as necessary.

f. Run the following Tcl script on all routers to verify full connectivity. All pings should be successful.

Router Interface Summary Table

Router Interface Summary
Router Model Ethernet Interface
Ethernet Interface
Serial Interface
Serial Interface
1700 Fast Ethernet 0
Fast Ethernet 1
Serial 0 (S0) Serial 0/0/1
1800 Fast Ethernet 0/0
Fast Ethernet 0/1
Serial 0/0/0
Serial 0/0/1
2600 Fast Ethernet 0/0
Fast Ethernet 0/1
Serial 0/0 (S0/0) Serial 0/1 (S0/1)
2800 Fast Ethernet 0/0
Fast Ethernet 0/1
Serial 0/0/0
Serial 0/0/1
Note: To find out how the router is configured, look at the interfaces to identify the type of router and how many interfaces the router has. Rather than list all combinations of configurations for each router class, this table includes identifiers for the possible combinations of Ethernet and serial interfaces in the device. The table does not include any other type of interface, even though a specific router might contain one. For example, for an ISDN BRI interface, the string in parenthesis is the legal abbreviation that can be used in Cisco IOS commands to represent the interface.

Device Configurations (Instructor version)

Router SanJose1 (R1)

Router SanJose2 (R2)

Router SanJose3 (R3)

More Resources

About the author


Leave a Comment