CCNP Route Lab 6-3, Configuring IBGP and EBGP Sessions, Local Preference, and MED

CCNP Route Lab 6-3, Configuring IBGP and EBGP Sessions, Local Preference, and MED




  • For IBGP peers to correctly exchange routing information, use the next-hop-self command with the
     Local-Preference and MED attributes.
  • Ensure that the flat-rate, unlimited-use T1 link is used for sending and receiving data to and from the AS 200 on ISP and that the metered T1 only be used in the event that the primary T1 link has failed.

The International Travel Agency runs BGP on its SanJose1 and SanJose2 routers externally with the ISP router in AS 200. IBGP is run internally between SanJose1 and SanJose2. Your job is to configure both EBGP and IBGP for this internetwork to allow for redundancy. The metered T1 should only be used in the event that the primary T1 link has failed. Traffic sent across the metered T1 link offers the same bandwidth of the primary link but at a huge expense. Ensure that this link is not used unnecessarily.

Note: This lab uses Cisco 1 841 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 2801 or 2811) and Cisco IOS Software versions if they have comparable capabilities and features. Depending on the router 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.

Step 2: Configure the hostname and interface addresses.
a. You can copy and paste the following configurations into your routers to begin.

Router R1 (hostname ISP)

Router R2 (hostname SanJose1)

Router R3 (hostname SanJose2)

b. Use ping to test the connectivity between the directly connected routers. Both SanJose routers should be able to ping each other and their local ISP serial link IP address. The ISP router cannot reach the segment between SanJose1 and SanJose2.

Step 3: Configure EIGRP.

Configure EIGRP between the SanJose1 and SanJose2 routers.

Step 4: Configure IBGP and verify BGP neighbors.
a. Configure IBGP between the SanJose1 and SanJose2 routers. On the SanJose1 router, enter the following configuration.

If multiple pathways to the BGP neighbor exist, the router can use multiple IP interfaces to communicate with the neighbor. The source IP address therefore depends on the outgoing interface. The updatesource lo0 command instructs the router to use the IP address of the interface Loopback0 as the source IP address for all BGP messages sent to that neighbor.

b. Complete the IBGP configuration on SanJose2 using the following commands.

c. Verify that SanJose1 and SanJose2 become BGP neighbors by issuing the show ip bgp neighbors command on SanJose1. View the following partial output. If the BGP state is not established, troubleshoot the connection.

The link between SanJose1 and SanJose2 should be identified as an internal link, as shown in the output.

Step 5: Configure EBGP and verify BGP neighbors.
a. Configure ISP to run EBGP with SanJose1 and SanJose2. Enter the following commands on ISP.

Because EBGP sessions are almost always established over point-to-point links, there is no reason to use the update-source keyword in this configuration. Only one path exists between the peers. If this path goes down, alternative paths are not available.

b. Configure SanJose1 as an EBGP peer to ISP.

c. Use the show ip bgp neighbors command to verify that SanJose1 and ISP have reached the established state. Troubleshoot if necessary.

You should also see an informational message indicating the establishment of the BGP neighbor relationship.

d. Configure SanJose2 as an EBGP peer to ISP.

Step 6: View BGP summary output.
In Step 5, the show ip bgp neighbors command was used to verify that SanJose1 and ISP had reached the established state. A useful alternative command is show ip bgp summary. The output should be similar to the following.

Step 7: Verify which path the traffic takes.
a. Clear the IP BGP conversation with the clear ip bgp * command on ISP. Wait for the conversations to reestablish with each SanJose router.

b. Test whether ISP can ping the loopback 0 address of on SanJose1 and the serial link between SanJose1 and SanJose2,

c. Now ping from ISP to the loopback 0 address of on SanJose2 and the serial link between SanJose1 and SanJose2,

You should see successful pings to each IP address on SanJose2 router. Ping attempts to and should fail. Why does this happen?
The ping fails because SanJose1 does not have a route back to the source. The source is ISP’s closest connected interface according to BGP, which in this case is the s0/0/0 link to SanJose1 . The route to network from ISP is via SanJose2, so ISP can ping the directly-connected SanJose2 interfaces but not the directly-connected SanJose1 interfaces.

d. Issue the show ip bgp command on ISP to verify BGP routes and metrics.

Notice that ISP has two valid routes to the network, as indicated by the *. However, the link to SanJose2 has been selected as the best path. Why did the ISP prefer the link to SanJose2 over SanJose1?
Because all other metrics were the same, the route advertised by the neighbor with the lower BGP router ID won the BGP route selection process.

Would changing the bandwidth metric on each link help to correct this issue? Explain.
No, because BGP does not check link bandwidth in its route selection process.

BGP operates differently than all other protocols. Unlike other routing protocols that use complex algorithms involving factors such as bandwidth, delay, reliability, and load to formulate a metric, BGP is policy-based. BGP determines the best path based on variables, such as AS path, weight, local preference, MED, and so on. If all things are equal, BGP prefers the route leading to the BGP speaker with the lowest BGP router ID. The SanJose2 router with BGP router ID was preferred to the higher BGP router ID of the SanJose1 router (

e. At this point, the ISP router should be able to get to each network connected to SanJose1 and SanJose2 from the loopback address Use the extended ping command and specify the source address of ISP Lo0 to test.

You can also use the extended ping dialogue to specify the source address, as shown in this example.

Complete reachability has been demonstrated between the ISP router and both SanJose1 and SanJose2.

Step 8: Configure the BGP next-hop-self feature.
SanJose1 is unaware of the link between ISP and SanJose2, and SanJose2 is unaware of the link between ISP and SanJose1. Before ISP can successfully ping all the internal serial interfaces of AS 64512, these serial links should be advertised via BGP on the ISP router. This can also be resolved via EIGRP on each SanJose router. The preferred method is for ISP to advertise these links.

a. Issue the following commands on the ISP router.

b. Issue the show ip bgp command to verify that the ISP is correctly injecting its own WAN links into BGP.

c. Verify on SanJose1 and SanJose2 that the opposite WAN link is included in the routing table. The output
from SanJose2 is as follows.

The next issue to consider is BGP policy routing between autonomous systems. The next-hop attribute of a route in a different AS is set to the IP address of the border router in the next AS toward the destination, and this attribute is not modified by default when advertising this route through IBGP. Therefore, for all IBGP peers, it is either necessary to know the route to that border router (in a different neighboring AS), or our own border router needs to advertise the foreign routes using the next-hop-self feature, overriding the next-hop address with its own IP address. The SanJose2 router is passing a policy to SanJose1 and vice versa. The policy for routing from AS 64512 to AS 200 is to forward packets to the interface. SanJose1 has a similar yet opposite policy: it forwards requests to the interface. If either WAN link fails, it is critical that the opposite router become a valid gateway. This is achieved if the next-hop-self command is configured on SanJose1 and SanJose2.

d. View the output before the next-hop-self command is issued.

e. Issue the next-hop-self command on SanJose1 and SanJose2.

f. Reset BGP operation on either router with the clear ip bgp * soft command.

g. After the routers have returned to established BGP speakers, issue the show ip bgp command to validate that the next hop has also been corrected.

Step 9: Set BGP local preference.
At this point, everything looks good, with the exception of default routes, the outbound flow of data, and inbound packet flow.

a. Because the local preference value is shared between IBGP neighbors, configure a simple route map that references the local preference value on SanJose1 and SanJose2. This policy adjusts outbound traffic to prefer the link off the SanJose1 router instead of the metered T1 off SanJose2.

b. Use the clear ip bgp * soft command after configuring this new policy. When the conversations have been reestablished, issue the show ip bgp command on SanJose1 and SanJose2.

This now indicates that routing to the loopback segment for ISP 192.1 68.100.0 /24 can be reached only through the link common to SanJose1 and ISP.

Step 10: Set BGP MED.
How will traffic return from network /24? Will it be routed through SanJose1 or SanJose2?
Return traffic will still follow the path to the router with the lowest BGP router ID. The routes being advertised
to ISP have the same characteristics, so ISP chooses the route through the neighbor with the lower BGP
router ID.

The simplest solution is to issue the show ip bgp command on the ISP router. What if access was not given to the ISP router? Traffic returning from the Internet should not be passed across the metered T1. Is there a simple way to verify before receiving the monthly bill? How can it be checked instantly?
As described below, you can use a special type of extended ping in this situation. You can also look at which interface packets are coming in using the debug ip packet command (do this only in lab environments).

a. Use an extended ping command in this situation. Specify the record option and compare your output to the following.

If you are unfamiliar with the record option, the important thing to note is that each IP address in brackets
is an outgoing interface. The output can be interpreted as follows:

  1. A ping that is sourced from exits SanJose2 through s0/0/1, It then arrives at the s0/0/1 interface for SanJose1.
  2. SanJose1 S0/0/0,, routes the packet out to arrive at the S0/0/0 interface of ISP.
  3. The target of is reached:
  4. The packet is next forwarded out the S0/0/1, interface for ISP and arrives at the S0/0/0 interface for SanJose2.
  5. SanJose2 then forwards the packet out the last interface, loopback 0,

Although the unlimited use of the T1 from SanJose1 is preferred here, ISP currently takes the link from SanJose2 for all return traffic.

b. Create a new policy to force the ISP router to return all traffic via SanJose1. Create a second route map utilizing the MED (metric) that is shared between EBGP neighbors.

c. Use the clear ip bgp * soft command after issuing this new policy. Issuing the show ip bgp command as follows on SanJose1 or SanJose2 does not indicate anything about this newly defined policy.

d. Reissue an extended ping command with the record command.

Does the output look correct? Does the above mean that the ISP now prefers SanJose1 forreturn traffic?
Yes. Now ISP prefers SanJose1 to send its return traffic to.

There might not be a chance to use Telnet to the ISP router and to issue the show ip bgp command.However, the command on the opposite side of the newly configured policy MED is clear, showing thatthe lower value is considered best. The ISP now prefers the route with the lower MED value to AS 64512.This is just opposite from the local-preference command configured earlier.

Step 11: Establish a default network.
The final step is to establish a default route that uses a policy statement that adjusts to changes in the network. Configure both SanJose1 and SanJose2 to use the /24 network as the default network. The following steps configure the SanJose1 router. Do the same on the SanJose2 router.

a. View the routing table prior to issuing the ip default-network statement.

b. Configure the default network.

Note: The above command works well only with remotely-learned classful networks. It should not be used with classless networks. An alternative to using the ip default-network command on SanJose1 is issuing the neighbor X.X.X.X default-originate configuration on the ISP router.

c. View the routing table after issuing the ip default-network statement.

What would be required to add a future T3 link on SanJose2 and for it to have preference for incoming and outgoing traffic?
Create route maps on SanJose1 to adjust the local preference on incoming routes and MED on outgoing routes.

A newly added route is as easy as adding another route map for local preference with a value of 175 and a route map referencing a MED (metric) value of 35.

NOTE: By default, the MED is compared only when the route is being received from the same neighboring AS, although advertised by different border routers. The nondefault behavior of comparing the MED regardless of the AS advertising the route can be activated using the bgp always-comparemed command, however, the results of this command have to be carefully considered .

NOTE: Because the MED is an optional attribute, it might not be present in BGP updates. RFC 4271 requires that a missing MED is equivalent to having the MED set to 0. However, a missing MED can also be considered to be the worst possible MED, which is activated using the bgp bestpath med missingas-worst command.

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

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 ISP

Router SanJose1

Router SanJose2

More Resources

About the author


Leave a Comment