CCNP Routing and Switching TSHOOT 300-135 Official Cert Guide (2015)

Part III. Troubleshooting Router Features

Chapter 18. Troubleshooting BGP

This chapter covers the following topics:

Troubleshooting BGP Neighbor Adjacencies: This section examines issues that may prevent a BGP neighbor relationship from forming, how you can recognize them, and how you can troubleshoot them. Although it centers primarily on IPv4 unicast BGP, the same issues will arise with IPv6 unicast BGP neighbor relationships.

Troubleshooting BGP Routes: This section focuses on issues that may prevent BGP routes from being learned or advertised, how you can recognize them, and how you can troubleshoot them. Although it focuses mostly on IPv4 unicast BGP, the same issues will arise with IPv6 unicast BGP routes as well.

Troubleshooting BGP Path Selection: This section explains how BGP determines the best path to reach a destination network and the importance of understanding how this process works for troubleshooting purposes.

Troubleshooting BGP for IPv6: This section discusses the methods needed to successfully troubleshoot additional issues related to BGP for IPv6 that are not seen with BGP for IPv4.

BGP Trouble Tickets: This section provides trouble tickets that demonstrate how you can use a structured troubleshooting process to solve a reported problem.

MP-BGP Trouble Tickets: This section provides trouble tickets that demonstrate how you can use a structured troubleshooting process to solve a reported problem.

Border Gateway Protocol (BGP) is the protocol of the Internet. It has been designed to exchange routing information between different autonomous systems (networks under different administrative control). That is why it is classified as an Exterior Gateway Protocol (EGP). It makes best path decisions based on attributes such as local preference, length of autonomous system path, and even BGP router ID (RID), instead of bandwidth like Open Shortest Path First (OSPF), bandwidth and delay like Enhanced Interior Gateway Routing Protocol (EIGRP), or router hops like Routing Information Protocol (RIP). BGP is the most scalable, robust, controllable protocol. However, with that comes a price. That price is mistakes that lead to issues that you have to troubleshoot.

BGP will primarily be used by organizations to connect to their Internet service provider (ISP). If not, static routes are used. However, ISPs use BGP extensively to share Internet routes with each other. The 300-135 TSHOOT exam is not based on ISP-to-ISP BGP connectivity. It is based on enterprise-to-ISP connectivity. Therefore, you need to focus your efforts on troubleshooting the basics of BGP for IPv4 and IPv6 connectivity and route advertising.

In this chapter, you learn the various issues that you may face when trying to establish an IPv4 and IPv6 External Border Gateway Protocol (eBGP) and Internal Border Gateway Protocol (iBGP) neighbor adjacency and how you can identify them and troubleshoot them. The chapter also covers issues that may arise when exchanging IPv4 and IPv6 eBGP and iBGP routes and how you can recognize them and troubleshoot them successfully. Because BGP is classified as a path vector protocol and its decisions are based on attributes, you need to be very familiar with the decision-making process that BGP uses to be an efficient troubleshooter. Therefore, you will spend time exploring this process in the chapter as well.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 18-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes.”

Table 18-1 “Do I Know This Already?” Section-to-Question Mapping

Caution

The goal of self-assessment is to gauge your mastery of the topics in this chapter. If you do not know the answer to a question or are only partially sure of the answer, you should mark that question as wrong for purposes of the self-assessment. Giving yourself credit for an answer that you correctly guess skews your self-assessment results and might provide you with a false sense of security.

1. Which commands enable you to identify the IPv4 unicast BGP neighbor adjacencies that have been formed? (Choose two answers.)

a. show ip route bgp

b. show bgp ipv4 unicast

c. show bgp ipv4 unicast summary

d. show bgp ipv4 unicast neighbors

2. In the output of show bgp ipv4 unicast summary, how can you determine whether a neighbor relationship is successfully established?

a. The neighbor is listed in the output.

b. The version column has a 4 in it.

c. The State/PfxRcd column has a number in it.

d. The State/PfxRcd column has the word Active in it.

3. Which of the following are reasons as to why a BGP neighbor relationship might not form? (Choose two answers.)

a. The BGP timers are mismatched.

b. The BGP packets are sourced from wrong IP.

c. The neighbor is reachable via a default route.

d. The network command is misconfigured.

4. Which TCP port number is used to form BGP sessions?

a. 110

b. 123

c. 179

d. 443

5. What is the BGP state of a neighbor if a TCP session cannot be formed?

a. Open

b. Idle

c. Active

d. Established

6. What could prevent a route from being advertised to another BGP router? (Choose three answers.)

a. Mismatched timers

b. Split-Horizon rule

c. Missing network mask command

d. Route Filtering

7. Which command enables you to verify the IPv4 BGP routes that have been learned from all BGP neighbors?

a. show ip route bgp

b. show bgp ipv4 unicast

c. show bgp ipv4 unicast summary

d. show bgp ipv4 unicast neighbors

8. What occurs when the next hop of a BGP-learned route is not reachable?

a. The route is discarded.

b. The route is placed in the BGP table and advertised to other neighbors.

c. The route is placed in the BGP table and not marked as valid.

d. The route is placed in the BGP table and the routing table.

9. Which successfully describes the BGP split-horizon rule?

a. A BGP router that receives a BGP route via an iBGP peering shall not advertise that route to another router that is an iBGP peer.

b. A BGP router that receives a BGP route via an eBGP peering shall not advertise that route to another router that is an iBGP peer.

c. A BGP router that receives a BGP route via an eBGP peering shall not advertise that route to another router that is an eBGP peer.

d. A BGP router that receives a BGP route via an iBGP peering shall discard the route.

10. Which administrative distances are correct? (Choose two answers.)

a. 20 for eBGP

b. 20 for iBGP

c. 200 for eBGP

d. 200 for iBGP

11. Which of the following correctly identify the order of BGP attributes for the best path decision process?

a. Weight, local preference, route origin, autonomous system Path, Origin Code, MED

b. Autonomous system path, origin code, MED, weight, local preference, route origin

c. Local preference, weight, route origin, autonomous system path, origin code, MED

d. Weight, local preference, route origin, autonomous system path, MED, origin code

12. What must be done when using MP-BGP? (Choose two answers.)

a. The IPv6 neighbors need to be activated in address family configuration mode.

b. The IPv6 neighbors need to be activated in router configuration mode.

c. The IPv6 neighbors need to be defined in router configuration mode.

d. The IPv6 neighbors need to be defined in address family configuration mode.

13. Which command enables you to verify the IPv6 unicast BGP routes that have been learned?

a. show bgp ipv6 unicast

b. show bgp ipv6 unicast summary

c. show bgp ipv6 unicast neighbor

d. show ipv6 route bgp

Foundation Topics

Troubleshooting BGP Neighbor Adjacencies

BGP establishes neighbor adjacencies manually. This is unlike EIGRP and OSPF, where you enable the process on an interface and neighbor adjacencies are formed dynamically. As a result, BGP configuration is more prone to human error, which leads to greater efforts during the troubleshooting process. In addition, there are two flavors of BGP, Internal BGP (iBGP) and External BGP (eBGP). Being able to understand the differences between the two and recognize issues related to each is important for troubleshooting.

This section covers how BGP neighbor relationships are formed and how to recognize issues that would prevent the neighbor relationships from forming.

To verify IPv4 unicast BGP neighbors, you can use two show commands: show bgp ipv4 unicast summary (which is the same as using the old show ip bgp summary command), and show bgp ipv4 unicast neighbors (which is the same as using the old show ip bgp neighbors command). For initial verification of neighbors, it is best to use show bgp ipv4 unicast summary because it provides a condensed output. The output of show bgp ipv4 unicast neighbors is very verbose and is not needed for initial neighbor verification. Example 18-1, which is a sample output of theshow bgp ipv4 unicast summary command, indicates that R1 has two BGP neighbors. One is at IP address 10.1.12.2 and the other is at 10.1.13.3. They are both eBGP neighbors because their autonomous system number does not match the local autonomous system number. Focus your attention on the State/PfxRcd column. If there is a number in this column (as in this case), it means that we have successfully established a BGP neighbor relationship. If you see Idle or Active, there is a problem forming the neighbor relationship.

Example 18-1 Verifying BGP Neighbors with show bgp ipv4 unicast summary

In addition, when a neighbor relationship is formed, a syslog message is generated similar to the following:

%BGP-5-ADJCHANGE: neighbor 10.1.12.2 Up

Here is a listing of reasons why a BGP neighbor relationship might not form:

Interface is down: The interface has to be up/up.

Layer 3 connectivity is broken: You need to be able to reach the IP address you are trying to form the adjacency with.

Path to neighbor is via default route: You must be able to reach the neighbor using a route other than the default route.

Neighbor does not have a route to the local router: Both routers forming a BGP peering must have routes to each other.

Incorrect neighbor statement: The IP address and autonomous system number in the neighbor ip_address remote-as as_number statement must be accurate.

ACLs: An access control list (ACL) or a firewall is blocking TCP port 179.

BGP packets sourced from wrong IP address: The source IP of an inbound BGP packet must match the local neighbor statement.

TTL of BGP packet expires: Peer is further away than permitted

Mismatched Authentication: Both routers must agree on authentication parameters

Misconfigured Peer Group: Peer groups simplify repetitive BGP configurations; however, if not carefully implemented can prevent neighbor relationships from forming or routes from being learned.

Timers: Timers do not have to match; however, if the minimum holddown from neighbor option is set, this could prevent a neighbor adjacency.

When troubleshooting BGP neighbor adjacencies, you need to be able to identify these different issues and understand the reasons why they occur. Let’s look at them individually.

Interface Is Down

The interface with the IP address that is being used to form BGP neighbor relationships must be up/up. Let’s be clear: This could be a physical or logical interface. Remember that you can use a loopback interface to source BGP packets. This practice is popular when you have redundant paths between neighbors. In such a case, if one path fails, for example a local physical interface goes down, the neighbor relationship will still be available using another local physical interface since a loopback interface is the source and destination of the packets. Therefore, if you are sourcing BGP packets with the IP address of Loopback 0, the loopback interface has to be up/up as well as any physical interface that can get you to the IP address you are trying to form the neighbor relationship with. As you have seen numerous times, you can verify the status of an interface with theshow ip interface brief command.

Layer 3 Connectivity Is Broken

You do not have to be directly connected to form a BGP neighbor relationship or in the same subnet; however, you do have to have Layer 3 connectivity. To verify Layer 3 connectivity, you use the ping command. If the ping is successful, you have Layer 3 connectivity. Note that for a router to have Layer 3 connectivity, it needs to have a route in the routing table that will point it in the right direction. If no route to the neighbor exists, a neighbor relationship cannot form.

When reviewing the output of show bgp ipv4 unicast summary in Example 18-2, you can see in the State/PfxRcd field it states Idle. This state occurs when the local router is not able to make a TCP connection with the neighbor. In this example, it is the router at 2.2.2.2 R5 is trying to form an adjacency with. Reviewing the routing table on R5 with the show ip route 2.2.2.2 255.255.255.255 command and pinging 2.2.2.2 from R5, as shown in Example 18-3, proves that Layer 3 connectivity does not exist. It is a good idea to specify the source when pinging. The source will be the IP address of the local device you plan on making the BGP peering with.

Example 18-2 Verifying BGP State with show bgp ipv4 unicast summary

R5#show bgp ipv4 unicast summary
BGP router identifier 10.1.45.5, local AS number 65502
BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 65502 0 0 1 0 0 never Idle

Example 18-3 Verifying Whether a Route Exists to the Neighbor and Whether a Ping Is Successful

R5#show ip route 2.2.2.2 255.255.255.255
% Network not in table

R5#ping 2.2.2.2 source 5.5.5.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Path to Neighbor Is via Default Route

Continuing with the previous discussion on Layer 3 connectivity being broken, Example 18-4 shows that no route to 2.2.2.2 exists; however, the ping to 2.2.2.2 is successful. This is because there is a default route in the routing table on R5, as shown in Example 18-5.

Example 18-4 No Route to Neighbor, but Ping Is Successful

Example 18-5 Verifying Default Route Exists in Routing Table

R5#show ip route
...output omitted...

Gateway of last resort is 10.1.45.4 to network 0.0.0.0

D*EX 0.0.0.0/0 [170/3328] via 10.1.45.4, 00:08:37, GigabitEthernet1/0
3.0.0.0/32 is subnetted, 1 subnets
D 3.3.3.3 [90/131072] via 10.1.45.4, 00:53:34, GigabitEthernet1/0
4.0.0.0/32 is subnetted, 1 subnets
D 4.4.4.4 [90/130816] via 10.1.45.4, 00:53:19, GigabitEthernet1/0
...output omitted...

Even though we can reach the neighbor via the default route, BGP does not consider it a valid route to form an adjacency. When looking at the output of show bgp ipv4 unicast summary on R5, in Example 18-6, you can see that the state is Idle, which indicates that we cannot form a TCP session.

Example 18-6 Verifying BGP State on R5 with show bgp ipv4 unicast summary

Neighbor Does Not Have a Route to the Local Router

So far, we have seen that the local router will display a state of idle when it does not have a route to the IP address they are trying to peer with. However, idle will also appear on a router when the neighbor does not have a route back to the local router. In Example 18-7, you can see that the router trying to form a BGP peering with R5 (it is R2) also displays a state of idle even though it has a route to 5.5.5.5, as shown in Example 18-7 also. The idle state is because the routers cannot form the TCP session.

Example 18-7 Verifying BGP State on R2 and Route to 5.5.5.5

R2#show bgp ipv4 unicast summary
BGP router identifier 2.2.2.2, local AS number 65502
BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
5.5.5.5 4 65502 0 0 1 0 0 00:00:13 Idle
10.1.12.1 4 65501 2 2 1 0 0 00:00:12 0

R2#show ip route 5.5.5.5 255.255.255.255
Routing entry for 5.5.5.5/32
Known via "eigrp 100", distance 90, metric 131072, type internal
Redistributing via eigrp 100
Last update from 10.1.24.4 on GigabitEthernet2/0, 00:23:58 ago
Routing Descriptor Blocks:
* 10.1.24.4, from 10.1.24.4, 00:23:58 ago, via GigabitEthernet2/0
Route metric is 131072, traffic share count is 1
Total delay is 5020 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2

Incorrect neighbor Statement

To form a BGP peering, you use the neighbor ip_address remote-as as_number command in BGP configuration mode. Example 18-8 displays two neighbor remote-as commands on R2. The neighbor 5.5.5.5 remote-as 65502 command forms an iBGP peering, and neighbor 10.1.12.1 remote-as 65501 forms an eBGP peering. The iBGP peering is established because the remote-as 65502 matches the local autonomous system number used to create the BGP process (router bgp 65502). The eBGP peering is established because the remote-as 65501 is different from the local autonomous system number used to create the BGP process (router bgp 65502).

Example 18-8 Verifying neighbor remote-as Commands on R2

R2#show run | s router bgp
router bgp 65502
bgp log-neighbor-changes
neighbor 5.5.5.5 remote-as 65502
neighbor 5.5.5.5 update-source Loopback0
neighbor 10.1.12.1 remote-as 65501

There are two very important parts to this command: 1) the address of the peer you will form the peering with; 2) the autonomous system that the peer is in. If you make a mistake with either of these, you will see either the active or idle state.

As we have discussed, if there is no route for the IP address you specify, the state will be idle. However, if a route is found and a three-way TCP handshake is complete, an open message is sent. If there is no response to the open message, the state will be active.

If the autonomous system number specified does not match the peer’s autonomous system number, the state will toggle between idle and active.

You can verify the state of the TCP session on the routers using the show tcp brief all command. In Example 18-9, you can see that R2 has an established TCP session with a device at 5.5.5.5 and another device at 10.1.12.1.

Example 18-9 Verifying State of TCP Sessions

R2#show tcp brief all
TCB Local Address Foreign Address (state)
68DD357C 10.1.12.2.179 10.1.12.1.35780 ESTAB
68DD24DC 2.2.2.2.179 5.5.5.5.45723 ESTAB

BGP Packets Sourced from Wrong IP Address

In a redundant topology, a BGP router will have multiple active IP addresses configured across its various interfaces. Figure 18-1 displays two BGP autonomous systems. Notice that R2, R3, and R4 could form a BGP peering with each other using any physical interface because of the multiple paths. For example, R2 could form a peering with R4 over the direct connection or through the connection via R3.

Figure 18-1 Sample BGP autonomous system with redundancy

When you issue the neighbor ip_address remote-as as_number command on a router, the address specified is used by the router to determine whether the BGP open message came from a router it should establish a BGP peering with. The BGP open message will have a source IP address, and the source IP address is compared with the address in the local neighbor remote-as command. If they match, a BGP peering is formed, if not, no BGP peering is formed. The source address is based on the exit interface of the router sending the BGP open message. Therefore, if R2 sends the BGP open message from Gi2/0 to R4, R4 needs to have a neighbor statement with R2’s Gi2/0 IP address. Now, if the link between R2 and R4 fails, R2 and R4 can still peer using the links through R3. However, now R2 sends the BGP open message with the source IP of Gi0/0, but R4’sneighbor remote-as statement is using the Gi2/0 IP address of R2 still, and as a result, no BGP peering is formed because the BGP packets are sourced from the wrong IP address.

To control the IP address that is used when sending BGP messages, you use the neighbor ip_address update-source interface_type interface_number command. Example 18-10 displays the output of show run | section router bgp on R2. Notice how the peering with R4 is using the address 4.4.4.4 (which is a loopback interface on R4) and all BGP messages sent to 4.4.4.4 will use the IP address of loopback 0 which is 2.2.2.2, as shown in Example 18-10 as well.

Example 18-10 Verifying State of TCP Sessions

R2#show run | section router bgp
router bgp 65502
bgp log-neighbor-changes
neighbor 4.4.4.4 remote-as 65502
neighbor 4.4.4.4 update-source Loopback0
neighbor 10.1.12.1 remote-as 65501

R2#show ip interface brief | include Loopback
Loopback0 2.2.2.2 YES manual up up

It is imperative that R4 is configured appropriately as well. In this case, R4 would need to have a neighbor remote-as statement using R2’s address of 2.2.2.2 in addition to a neighbor statement with the update-source option that allows it to control the source address of BGP messages sent to R2. Example 18-11 displays the appropriate configuration on R4 to ensure that a BGP peering is successful.

Example 18-11 Verifying that R4’s BGP Configuration Mirrors R2

R4#show run | section router bgp
router bgp 65502
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 65502
neighbor 2.2.2.2 update-source Loopback0

R4#show ip interface brief | include Loopback
Loopback0 4.4.4.4 YES manual up up

ACLs

BGP uses TCP port 179 to establish TCP sessions. The TCP session is then used to form the BGP peering. If there is an access control list (ACL) configured that blocks TCP port 179 anywhere in the path between the routers attempting to form a BGP peering, the peering will not happen. InExample 18-12, R4 (refer to Figure 18-1) has ACL 100 attached to interface Gig0/0, which denies packets sourced or destined to port 179 (BGP). As a result, a BGP peering between R2 and R5 is not possible as the packets relating to BGP port 179 are being denied. At the bottom of Example 18-12, the state is idle on R5 because the TCP session cannot be established with the neighbor at 2.2.2.2 because R4 is denying TCP traffic related to port 179.

Example 18-12 Verifying ACLs Blocking BGP Packets and the State of R5’s Neighbor Relationship

R4#show access-lists
Extended IP access list 100
10 deny tcp any any eq bgp
20 deny tcp any eq bgp any
30 permit ip any any

R4#show ip interface gigabitEthernet 0/0 | include access list
Outgoing access list is 100
Inbound access list is not set

R5#show bgp ipv4 unicast summary
BGP router identifier 10.1.45.5, local AS number 65502
BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 65502 0 0 1 0 0 00:02:24 Idle

In Example 18-12, the access list is denying BGP packets sourced or destined to port 179. However, what if the ACL were only blocking BGP port 179 packets in one direction? For example, the entry was only deny tcp any any eq bgp while still being applied to Gig0/0 outbound. This means that only packets destined to port 179 outbound on Gig0/0 will be blocked. What if they were sourced from 179 going outbound instead? They would no longer be blocked. So, in this case, if you could control who the server and clients are for the BGP TCP sessions, you could still form the BGP TCP session.

That’s right, BGP sessions are a server/client relationship. One router is using port 179 (server), and the other router is using an ephemeral port (client). By default, both routers will try to establish a TCP session using the three-way handshake because both routers will send a TCP syn packet sourced from an ephemeral port and destined to port 179. They both respond with a syn/ack sourced from 179 destined to the ephemeral port, and then both send an ack sourced from the ephemeral port destined to port 179. This causes two BGP sessions between the devices when there can only be one. This situation is called a BGP connection collision, and BGP will sort it out automatically. In a nutshell, the router with the higher BGP RID becomes the server.

If you want to avoid this issue, you can control who the server and client are right from the start by using the neighbor ip_address transport connection-mode {active | passive} command. By specifying active, you are indicating that you want the router to actively initiate the TCP session; therefore, active means client. By specifying passive, you are indicating that you want the router to passively wait for another router to initiate the TCP session; therefore, passive means server.

Using the command show bgp ipv4 unicast neighbor will show the local and remote port numbers that are being used. If the local port is port 179 and the remote port is an ephemeral port, the local router is the server. If the remote port is 179 and the local port is an ephemeral port, the local router is the client. In Example 18-13, the command show bgp ipv4 unicast neighbors | i ^BGP neighbor|Local port|Foreign port was used to just display R2’s neighbors along with the local port number and the foreign port number. Notice how R2 is the client for the TCP sessions with R1 (1.1.1.1), R4 (4.4.4.4), and R5 (5.5.5.5) because the local port is a random port number. R2 is the server for the TCP session with R3 because the local port is the BGP port number of 179.

Example 18-13 Verifying Local and Foreign BGP Port Numbers

R2#show bgp ipv4 unicast neighbors | i ^BGP neighbor|Local port|Foreign port
BGP neighbor is 1.1.1.1, remote AS 65501, external link
Local host: 2.2.2.2, Local port: 23938
Foreign host: 1.1.1.1, Foreign port: 179
BGP neighbor is 3.3.3.3, remote AS 65502, internal link
Local host: 2.2.2.2, Local port: 179
Foreign host: 3.3.3.3, Foreign port: 45936
BGP neighbor is 4.4.4.4, remote AS 65502, internal link
Local host: 2.2.2.2, Local port: 34532
Foreign host: 4.4.4.4, Foreign port: 179
BGP neighbor is 5.5.5.5, remote AS 65502, internal link
Local host: 2.2.2.2, Local port: 49564
Foreign host: 5.5.5.5, Foreign port: 179

TTL of BGP Packet Expires

By default, an eBGP peering occurs between directly connected routers. This means the routers forming the eBGP peering are expected to be within one router hop of each other. With an iBGP peering, the routers can be up to 255 router hops from each other and still form a peering. Example 18-14 shows the output of show bgp ipv4 unicast neighbors | include BGP neighbor|TTL, which displays that the eBGP neighbor at 10.1.12.1 must be reachable in 1 router hop, and the iBGP neighbor at 5.5.5.5 can be up to 255 hops away. If the neighbor is not reachable in the number of hops listed, the BGP packet expires, and no neighbor relationship is formed.

Example 18-14 Verifying the TTLs of eBGP and iBGP Packets

R2#show bgp ipv4 unicast neighbors | include BGP neighbor|TTL
BGP neighbor is 5.5.5.5, remote AS 65502, internal link
Minimum incoming TTL 0, Outgoing TTL 255
BGP neighbor is 10.1.12.1, remote AS 65501, external link
Minimum incoming TTL 0, Outgoing TTL 1

If the TTL is not large enough to support the distance required to form a BGP peering, the packet will be discarded. For example, let’s form an eBGP peering between R1 and R2 in Figure 18-2 using their loopback interfaces. R1 has a loopback interface of 1.1.1.1, and R2 has a loopback interface of 2.2.2.2. Layer 3 connectivity has been tested with a ping, and it is successful. It is also not via a default route.

Figure 18-2 Forming BGP Peering Between R1 and R2 Using Loopback Interfaces

Example 18-15 displays the configuration of R1 and R2. Notice that R1 is peering with R2 using the neighbor address 2.2.2.2 (R2 loopback) and that source address of loopback 0 (1.1.1.1). R2 is peering with R1 using the neighbor address 1.1.1.1 (R1 loopback) and source address of loopback 0 (2.2.2.2). Note that these loopback interfaces are not directly connected (one hop away), and because it is an eBGP neighbor relationship, we expect the peering to fail.

Example 18-15 Verifying BGP Configuration on R1 and R2

R1#show run | s router bgp
router bgp 65501
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 65502
neighbor 2.2.2.2 update-source Loopback0
neighbor 10.1.13.3 remote-as 65502

R2#show run | s router bgp
router bgp 65502
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 65501
neighbor 1.1.1.1 update-source Loopback0
neighbor 5.5.5.5 remote-as 65502
neighbor 5.5.5.5 update-source Loopback0

Reviewing the output of show bgp ipv4 unicast summary, as shown in Example 18-16, clearly indicates that the peering is not forming as both routers are in the idle state. This is a result of the eBGP peers addresses not being directly connected (one router hop).

Example 18-16 Verifying BGP States on R1 and R2

R1#show bgp ipv4 unicast summary
BGP router identifier 10.1.13.1, local AS number 65501
BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 65502 0 0 1 0 0 never Idle
10.1.13.3 4 65502 36 35 1 0 0 00:29:49 0

R2#show bgp ipv4 unicast summary
BGP router identifier 2.2.2.2, local AS number 65502
BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 65501 0 0 1 0 0 never Idle
5.5.5.5 4 65502 27 26 1 0 0 00:20:52 0

To solve this issue with eBGP neighbors, you can modify the TTL of eBGP packets using the neighbor ip_address ebgp-multihop [TTL] command. In this case, two would be enough to solve the issue. Therefore, on R1, you can type neighbor 2.2.2.2 ebgp-multihop 2, and on R2, you can type neighbor 1.1.1.1 ebgp-multihop 2. As you can see in Example 18-17, it now states on R2 that neighbor 1.1.1.1 can be up to two hops away and that the peering is established, as shown in the output of show bgp ipv4 unicast summary.

Example 18-17 Verifying Modified TTLs of eBGP Packets

R2#show bgp ipv4 unicast neighbors | include BGP neighbor|TTL
BGP neighbor is 1.1.1.1, remote AS 65501, external link
External BGP neighbor may be up to 2 hops away.
BGP neighbor is 5.5.5.5, remote AS 65502, internal link
Minimum incoming TTL 0, Outgoing TTL 255

R2#show bgp ipv4 unicast summary
BGP router identifier 2.2.2.2, local AS number 65502
BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 65501 2 4 1 0 0 00:00:04 0
5.5.5.5 4 65502 38 37 1 0 0 00:30:57 0

Mismatched Authentication

BGP supports message digest 5 (MD5) authentication between peers. Like all discussions on authentication, if any of the parameters do not match, a peering will not form. If you have syslog messaging turned on, a BGP authentication mismatch will generate a syslog message from the TCP facility, as follows:

%TCP-6-BADAUTH: No MD5 digest from 2.2.2.2(179) to 1.1.1.1(45577) tableid – 0

In addition, the BGP state will be idle, as shown in Example 18-18.

Example 18-18 Verifying Neighbor State With Mismatched Authentication

R1#show bgp ipv4 unicast summary
BGP router identifier 1.1.1.1, local AS number 65501
BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 65502 0 0 1 0 0 00:02:49 Idle
10.1.13.3 4 65502 7 5 1 0 0 00:02:48 0

Misconfigured Peer Groups

When a BGP-enabled router needs to send updates, it will build a separate update for each of the neighbors it has. When a router has a large number of BGP neighbors, this can have a significant impact on the routers CPU. To conserve processing power, you can implement BGP peer groups. With BGP peer groups, the router only has to run the BGP update for the entire group instead of on a neighbor-by-neighbor basis. However, even though the update is run only once, the TCP transmission has to occur on a per-neighbor basis. In addition to saving CPU cycles, peer groups allow you to type or copy and paste less. Example 18-19 displays a sample peer group configuration. When troubleshooting peer group issues, you need to look out for a few general things:

You forgot to associate the neighbor ip address with the peer group: Once the peer group is created, you need to use the neighbor ip_address peer-group peer_group_name command to associate the neighbor with the configurations in the peer group. If you forget to do this, the neighbor IP address is not using the configs in the peer group. It will be using the BGP configs outside the peer group, which could prevent a neighbor relationship from forming.

The peer group is not configured correctly: It is possible that you overlooked the fact that what works for one neighbor might not work for the other. For example, using an update source of Loopback 0 may work well for the iBGP peer but not for the eBGP peer.

The route filter applied to the group is not appropriate for all the peers: The filter applied via a route map or any other means may not provide the result you expect on all the routers. Be careful with filters and make sure that they produce the desired result for all neighbors in the peer group.

Order of operations produces undesired result: If there are conflicting entries between the peer group and a specific neighbor statement, the neighbor statement wins. In Example 18-19, the peer group states the update source is Loopback 0. However, for neighbor 3.3.3.3, it states specifically that Loopback 1 will be used with the command neighbor 3.3.3.3 update-source Loopback1. This specific neighbor statement overrides the peer group.

Example 18-19 Peer Group Configuration Example

R2#show run | section router bgp
router bgp 65502
bgp log-neighbor-changes
network 10.1.5.0 mask 255.255.255.0
neighbor TSHOOT_IBGP_NEIGHBORS peer-group
neighbor TSHOOT_IBGP_NEIGHBORS transport connection-mode passive
neighbor TSHOOT_IBGP_NEIGHBORS update-source Loopback0
neighbor TSHOOT_IBGP_NEIGHBORS next-hop-self
neighbor TSHOOT_IBGP_NEIGHBORS route-map TSHOOT_BGP_FILTER out
neighbor 1.1.1.1 remote-as 65501
neighbor 1.1.1.1 password CISCO
neighbor 1.1.1.1 ebgp-multihop 2
neighbor 1.1.1.1 update-source Loopback0
neighbor 3.3.3.3 remote-as 65502
neighbor 3.3.3.3 peer-group TSHOOT_IBGP_NEIGHBORS
neighbor 3.3.3.3 update-source Loopback1
neighbor 4.4.4.4 remote-as 65502
neighbor 4.4.4.4 peer-group TSHOOT_IBGP_NEIGHBORS
neighbor 5.5.5.5 remote-as 65502
neighbor 5.5.5.5 peer-group TSHOOT_IBGP_NEIGHBORS

Timers

Let’s be clear, BGP timers do not have to match. This is because BGP will use the lowest timers set between the two neighbors. If R1 is configured with a default hello of 60 and hold time of 180 and R3 is configured with a hello of 30 and hold time of 90, a hello of 30 and hold time of 90 will be used between the two neighbors, as shown in Example 18-20.

Notice how R3 was configured with a minimum hold-time of 90 seconds; this is done to ensure that if a neighbor is using aggressive timers, they will not be used. However, it is far worse than the timers simply not being used. The neighbor relationship will not form at all. Refer to Example 18-21. In this case, R1 has a hello interval set to 10 and hold time set to 30. R3 has the minimum hold time set to 90 seconds. Therefore, it will not agree with the 30-second hold time set by R1, and the neighbor relationship fails. You can see in the output a BGP notification is received stating that the hold time is not acceptable.

Example 18-20 Verifying BGP Timers

R1#show bgp ipv4 unicast neighbors 10.1.13.3 | include hold time|holdtime
Last read 00:00:02, last write 00:00:29, hold time is 90, keepalive interval is 30
seconds
R3#show bgp ipv4 unicast neighbors 10.1.13.1 | include hold time|holdtime
Last read 00:00:10, last write 00:00:23, hold time is 90, keepalive interval is 30
seconds
Configured hold time is 90, keepalive interval is 30 seconds
Minimum holdtime from neighbor is 90 seconds

Example 18-21 Modifying BGP Timers to Values That Are Not Acceptable on R1

R1#config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router bgp 65501
R1(config-router)#neighbor 10.1.13.3 timers 10 30
R1(config-router)#do clear ip bgp 10.1.13.3
R1(config-router)#
%BGP-5-ADJCHANGE: neighbor 10.1.13.3 Down User reset
%BGP_SESSION-5-ADJCHANGE: neighbor 10.1.13.3 IPv4 Unicast topology base removed from
session User reset
%BGP-3-NOTIFICATION: received from neighbor 10.1.13.3 active 2/6 (unacceptable hold
time) 0 bytes
R1(config-router)#
%BGP-5-NBR_RESET: Neighbor 10.1.13.3 active reset (BGP Notification received)
%BGP-5-ADJCHANGE: neighbor 10.1.13.3 active Down BGP Notification received
%BGP_SESSION-5-ADJCHANGE: neighbor 10.1.13.3 IPv4 Unicast topology base removed from
session BGP Notification received
R1(config-router)#
%BGP-3-NOTIFICATION: received from neighbor 10.1.13.3 active 2/6 (unacceptable hold
time) 0 bytes
R1#

To summarize timers, they do not have to match, but if the minimum hold time is set, the lowest timers must not be less than the minimum; otherwise, a neighbor relationship will not form.

Troubleshooting BGP Routes

Once a BGP adjacency is formed, BGP routers exchange their BGP routes with each other. However, there are various reasons as to why BGP routes might be missing from either the BGP table or the routing table. This section explains those reasons and how we can identify them using our troubleshooting methods.

As discussed already, peers are the foundation for BGP information sharing. If we have no peers, we will not learn BGP routes. So, besides the lack of peers, what would be reasons for missing routes in a BGP network? Following is a listing of some common reasons as to why BGP routes might be missing either in the BGP table or the routing table:

Missing or bad network mask command: An accurate network command is needed to advertise routes.

Next-hop router not reachable: To use a BGP route, the next hop must be reachable.

BGP split-horizon rule: A router that learns BGP routes through an iBGP peering will not share those routes with another iBGP peer.

Better source of information: If the exact same network is learned from a more reliable source, it is used instead of the BGP-learned information.

Route filtering: A filter might be set up that prevents a route from being shared with neighbors or learned from neighbors.

To verify the IPv4 unicast BGP-learned routes or routes locally injected into the BGP table, you use the show bgp ipv4 unicast command (which is the same as the old show ip bgp command), as shown in Example 18-22. Routes will appear in this table for the following reasons:

Another BGP router advertises them to the local router.

The network mask command matches a route in the local routing table.

A redistribute command is used to import the route from another local source.

The summary-address command is used to create a summary route.

It is not easy to determine the exact sources for all of the networks by looking only at the BGP table. Reviewing the commands in the running configuration along with the output of the BGP table will give you the most accurate information. However, in the BGP table, a network with a next hop other than 0.0.0.0 indicates the router learned it from a peer. If the next hop is 0.0.0.0, it means that the local router originated the route. If the Path column ends in ?, you can conclude that it was redistributed into the BGP process at some point. If the Path column ends in i, it means that the route was injected with the summary-address command or the network mask command.

Example 18-22 Examining the BGP Table

R1#show bgp ipv4 unicast
BGP table version is 10, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 ?
*> 10.1.1.0/26 0.0.0.0 0 32768 i
*> 10.1.1.0/24 0.0.0.0 32768 i
*> 10.1.1.64/26 0.0.0.0 0 32768 i
*> 10.1.1.128/26 0.0.0.0 0 32768 i
*> 10.1.1.192/26 0.0.0.0 0 32768 i
* 10.1.5.0/24 10.1.13.3 3328 0 65502 i
*> 2.2.2.2 3328 0 65502 i
*> 10.1.12.0/24 0.0.0.0 0 32768 ?
*> 10.1.13.0/24 0.0.0.0 0 32768 ?

To display the routing table, use the show ip route command. To view only the BGP routes, issue the command show ip route bgp, as shown in Example 18-23. All BGP routes appear with the code B at the beginning of the entry.

Example 18-23 Examining the BGP Routes in the Routing Table

R2#show ip route bgp
...output omitted...

Gateway of last resort is 10.1.12.1 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 15 subnets, 3 masks
B 10.1.1.0/24 [20/0] via 1.1.1.1, 00:19:11
B 10.1.1.0/26 [20/0] via 1.1.1.1, 00:41:04
B 10.1.1.64/26 [20/0] via 1.1.1.1, 00:36:45
B 10.1.1.128/26 [20/0] via 1.1.1.1, 00:36:15
B 10.1.1.192/26 [20/0] via 1.1.1.1, 00:36:15
B 10.1.13.0/24 [20/0] via 1.1.1.1, 00:20:23

Let’s take a look at each of the reasons individually and identify how we can recognize them during the troubleshooting process.

Missing or Bad network mask Command

The network mask command is used to advertise routes into BGP. If you only remember one thing about this command, remember that it is extremely picky. The following list describes why the command is picky:

The network/prefix you want to advertise with BGP has to be in the routing table from some other source (connected, static, or some other routing protocol).

The network mask command must be a perfect match to the network/prefix listed in the routing table.

If these two requirements are not met, the prefix/network will not be advertised. Review Example 18-24 and determine whether the 10.1.1.0/26 network will be advertised.

Example 18-24 Determining Whether the 10.1.1.0/26 Network Will Be Advertised

R1#config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router bgp 65501
R1(config-router)#network 10.1.1.0 mask 255.255.255.192
R1(config-router)#end
R1#show ip route
...output omitted...

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
2.0.0.0/32 is subnetted, 1 subnets
S 2.2.2.2 [1/0] via 10.1.12.2
10.0.0.0/8 is variably subnetted, 12 subnets, 3 masks
C 10.1.1.0/26 is directly connected, GigabitEthernet0/0.1
L 10.1.1.1/32 is directly connected, GigabitEthernet0/0.1
C 10.1.1.64/26 is directly connected, GigabitEthernet0/0.2
L 10.1.1.65/32 is directly connected, GigabitEthernet0/0.2
C 10.1.1.128/26 is directly connected, GigabitEthernet0/0.3
L 10.1.1.129/32 is directly connected, GigabitEthernet0/0.3
C 10.1.1.192/26 is directly connected, GigabitEthernet0/0.4
L 10.1.1.193/32 is directly connected, GigabitEthernet0/0.4
C 10.1.12.0/24 is directly connected, GigabitEthernet1/0
L 10.1.12.1/32 is directly connected, GigabitEthernet1/0
C 10.1.13.0/24 is directly connected, GigabitEthernet2/0
L 10.1.13.1/32 is directly connected, GigabitEthernet2/0

In Example 18-24, the 10.1.1.0/26 network will be advertised because there is an exact match of the network command in the routing table.

Now review Example 18-25. Will the network mask command successfully advertise the route indicated?

Example 18-25 Determining Whether the Network Will Be Advertised

R1#config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router bgp 65501
R1(config-router)#network 10.1.1.0 mask 255.255.255.0
R1(config-router)#end
R1#show ip route
...output omitted...

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
2.0.0.0/32 is subnetted, 1 subnets
S 2.2.2.2 [1/0] via 10.1.12.2
10.0.0.0/8 is variably subnetted, 12 subnets, 3 masks
C 10.1.1.0/26 is directly connected, GigabitEthernet0/0.1
L 10.1.1.1/32 is directly connected, GigabitEthernet0/0.1
C 10.1.1.64/26 is directly connected, GigabitEthernet0/0.2
L 10.1.1.65/32 is directly connected, GigabitEthernet0/0.2
C 10.1.1.128/26 is directly connected, GigabitEthernet0/0.3
L 10.1.1.129/32 is directly connected, GigabitEthernet0/0.3
C 10.1.1.192/26 is directly connected, GigabitEthernet0/0.4
L 10.1.1.193/32 is directly connected, GigabitEthernet0/0.4
C 10.1.12.0/24 is directly connected, GigabitEthernet1/0
L 10.1.12.1/32 is directly connected, GigabitEthernet1/0
C 10.1.13.0/24 is directly connected, GigabitEthernet2/0
L 10.1.13.1/32 is directly connected, GigabitEthernet2/0

The network mask command in this case is 10.1.1.0/24. Although 10.1.1.0/24 as a summary would include 10.1.1.0/26, 10.1.1.64/26, 10.1.1.128/26, and 10.1.1.192/26, the network mask command states advertise this network (10.1.1.0/24). Because 10.1.1.0/24 is not in the routing table, nothing is advertised.

It is important that you are able to recognize a bad or missing network mask command as being the reason for missing routes. If a router is not learning a BGP route that it should and you trace it all the way back to the source, review the running configuration to see whether there is anetwork mask command advertising the network and whether there is a matching route in the routing table.

Next-Hop Router Not Reachable

If you are seeing BGP routes in the BGP table, but they are not appearing in the routing table, the router might not be able to reach the next hop. For a BGP router to install a BGP route in the routing table, it must be able to reach the next-hop address listed for the network. Example 18-26shows the output of show bgp ipv4 unicast on R5. Let’s focus on network 10.1.1.0/26. Notice how there is no > symbol after the *. The * > symbols indicate that it is a valid best path to reach that network and has been installed in the routing table. In this case, the path is valid but not the best, and as a result, not placed in the routing table.

Example 18-26 Identifying BGP Next-Hop Issues

R5#show bgp ipv4 unicast
BGP table version is 2, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
* i 1.1.1.1/32 1.1.1.1 0 100 0 65501 ?
* i 10.1.1.0/26 1.1.1.1 0 100 0 65501 i
* i 10.1.1.0/24 1.1.1.1 0 100 0 65501 i
* i 10.1.1.64/26 1.1.1.1 0 100 0 65501 i
* i 10.1.1.128/26 1.1.1.1 0 100 0 65501 i
* i 10.1.1.192/26 1.1.1.1 0 100 0 65501 i
r>i 10.1.5.0/24 10.1.24.4 3328 100 0 i
* i 10.1.12.0/24 1.1.1.1 0 100 0 65501 ?
* i 10.1.13.0/24 1.1.1.1 0 100 0 65501 ?

The reason why it is not being used is because the next-hop address is not reachable. In Example 18-27, the ping 1.1.1.1 command fails proving that the next hop is not reachable.

Example 18-27 Verifying Next-Hop Reachability

R5#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Refer to Figure 18-3. Notice where the next-hop address 1.1.1.1 is compared to R5. The next hop for BGP routes outside an autonomous system is the IP address of the router advertising the route to the local autonomous system. The router receiving the advertisement (R2 in this case) does not change the next hop by default because BGP is based on autonomous system-by-autonomous system hops, not on router-by-router hops. Therefore, the next hop is the IP address of the router advertising the network from the next-hop autonomous system.

Figure 18-3 Troubleshooting Next-Hop Address Behavior

There are many different ways to solve this problem. The key is to train R5 about how to get to the next hop. The following list contains a few examples:

Create a static default route on R2 and R3; advertise it into the IGP routing protocol

Create a static default route on R5

Create a static route on R5

Advertise the next-hop address into the Interior Gateway Protocol (IGP) routing protocol

In addition, BGP has a built-in option you can take advantage of. It is the neighbor ip_address next-hop-self command. This command allows, for example, R2 to change the next-hop address to its own address before advertising the route to the peer. In Example 18-28, R2 has been configured with the neighbor 5.5.5.5 next-hop-self command that changes the next hop to 2.2.2.2 when R2 advertises routes to R5. Example 18-29 displays the BGP table on R5, which now has 2.2.2.2 as the next hop for 10.1.1.0/26, and it now has a > symbol, so it is the best and installed in the routing table.

Example 18-28 Modifying Next-Hop Address

R2#config t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#router bgp 65502
R2(config-router)#neighbor 5.5.5.5 next-hop-self

Example 18-29 Verifying Next-Hop Address in BGP Table

R5#show bgp ipv4 unicast
BGP table version is 13, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.1/32 2.2.2.2 0 100 0 65501 ?
*>i 10.1.1.0/26 2.2.2.2 0 100 0 65501 i
*>i 10.1.1.0/24 2.2.2.2 0 100 0 65501 i
*>i 10.1.1.64/26 2.2.2.2 0 100 0 65501 i
*>i 10.1.1.128/26 2.2.2.2 0 100 0 65501 i
*>i 10.1.1.192/26 2.2.2.2 0 100 0 65501 i
r>i 10.1.5.0/24 2.2.2.2 3328 100 0 i
r>i 10.1.12.0/24 2.2.2.2 0 100 0 65501 ?
r>i 10.1.13.0/24 2.2.2.2 0 100 0 65501 ?

BGP Split-Horizon Rule

The BGP split-horizon rule states that a BGP router that receives a BGP route via an iBGP peering shall not advertise that route to another router that is an iBGP peer. It is important that you commit this rule to memory. By doing so, you will be able to recognize when this is the reason for missing routes. Figure 18-4 shows the current BGP peerings. Notice that R2 has an iBGP peering with R4 and that R4 has an iBGP peering with R5. When R2 advertises the 10.1.1.0/26 network (as an example) to R4, it is via an iBGP peering. Because R4 and R5 are iBGP peers, R4 will not advertise the 10.1.1.0/26 network to R5 because of the BGP split-horizon rule.

Figure 18-4 BGP Peerings Enforcing the BGP Split-Horizon Rule

For R5 to learn about the 10.1.1.0/26 network, it has to be an iBGP peer with the router that learned about the route from an eBGP peer or it has to be a peer with a route reflector, which is beyond the scope of this book. Figure 18-5 indicates how the iBGP peerings should be to ensure both R4 and R5 learn about 10.1.1.0/26 (as well as the other networks). It also ensures redundancy is optimized in the BGP AS.

Figure 18-5 Proper BGP Peerings to Avoid the BGP Split-Horizon Rule

Using show bgp ipv4 unicast summary on all the routers to identify peerings and then drawing your peerings on paper will give you an idea if the BGP split-horizon rule is causing the missing routes, as long as you remember this: A BGP router that receives a BGP route via an iBGP peering shall not advertise that route to another router that is an iBGP peer.

Better Source of Information

Routes learned from eBGP peers have an administrative distance of 20, and routes learned from iBGP peers have an administrative distance of 200. Why the huge difference? BGP is designed to share routes between different autonomous systems. Therefore, if you learn a route from another autonomous system via eBGP, iBGP, or EIGRP sources, you want the eBGP-learned route to be the best source of information over all the other dynamic routing protocols. For example, refer to Figure 18-5 again. R1 advertises 10.1.1.0/26 to R2 using eBGP and R3 using eBGP. R3, because it has an iBGP peering with R2, advertises it to R2 using iBGP. In addition, let’s say on R3 we redistribute the 10.1.1.0/26 eBGP-learned route into EIGRP and that R2 learns it via an EIGRP update. Now, R2 knows about the same network from three different sources: eBGP(20), iBGP(200), and EIGRP(170). As a result, the eBGP path is chosen because it has the lower AD. If it was not for eBGP having the lower AD, we would end up with suboptimal routing as a different source is used, and traffic would have to go to R3 first before it leaves the network, instead of directly from R2 to R1.

Example 18-30 displays the output of the IPv4 unicast BGP table on R5 using the show bgp ipv4 unicast command. In the table, you will notice that the 10.1.5.0/24, 10.1.12.0/24, and 10.1.13.0/24 networks are best (installed in routing table), as indicated by the > symbol; however, they are not valid. They are listed as having a RIB failure, as indicated by the r. A RIB failure means that the BGP route was not able to be installed in the routing table; however, you can clearly see that the route is in the routing table because of the > symbol. Be careful here. In this case, the route in the routing table is from a better source.

Example 18-30 Verifying BGP Routes

R5#show bgp ipv4 unicast
BGP table version is 10, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
* i 1.1.1.1/32 3.3.3.3 0 100 0 65501 ?
*>i 2.2.2.2 0 100 0 65501 ?
* i 10.1.1.0/26 3.3.3.3 0 100 0 65501 i
*>i 2.2.2.2 0 100 0 65501 i
* i 10.1.1.0/24 3.3.3.3 0 100 0 65501 i
*>i 2.2.2.2 0 100 0 65501 i
* i 10.1.1.64/26 3.3.3.3 0 100 0 65501 i
*>i 2.2.2.2 0 100 0 65501 i
* i 10.1.1.128/26 3.3.3.3 0 100 0 65501 i
*>i 2.2.2.2 0 100 0 65501 i
* i 10.1.1.192/26 3.3.3.3 0 100 0 65501 i
*>i 2.2.2.2 0 100 0 65501 i
r i 10.1.5.0/24 3.3.3.3 3328 100 0 i
r>i 2.2.2.2 3328 100 0 i
r i 10.1.12.0/24 3.3.3.3 0 100 0 65501 ?
r>i 2.2.2.2 0 100 0 65501 ?
r i 10.1.13.0/24 3.3.3.3 0 100 0 65501 ?
r>i 2.2.2.2 0 100 0 65501 ?

Using the command show ip route 10.1.5.0 255.255.255.0, as shown in Example 18-31, indicates that 10.1.5.0/24 is learned via connected. In the same example, you can also see the output of show ip route 10.1.12.0 255.255.255.0, which indicates that it was learned via EIGRP. Connected is always the most trustworthy; therefore, it is always used over other routing information. With regard to the 10.1.12.0/24 network, the output of show bgp ipv4 unicast 10.1.12.0 in Example 18-32 indicates that it was learned from R2 and R3 using iBGP (internal), which has an AD of 200, much higher than EIGRP.

Example 18-31 Verifying AD of Routes in Routing Table

R5#show ip route 10.1.5.0 255.255.255.0
Routing entry for 10.1.5.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
...output omitted...

R5#show ip route 10.1.12.0 255.255.255.0
Routing entry for 10.1.12.0/24
Known via "eigrp 100", distance 90, metric 3328, type internal
...output omitted...

Example 18-32 Verifying Details of BGP Routes

R5#show bgp ipv4 unicast 10.1.12.0
BGP routing table entry for 10.1.12.0/24, version 50
Paths: (2 available, best #2, table default, RIB-failure(17))
Not advertised to any peer
Refresh Epoch 2
65501
3.3.3.3 (metric 131072) from 3.3.3.3 (3.3.3.3)
Origin incomplete, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Refresh Epoch 2
65501
2.2.2.2 (metric 131072) from 2.2.2.2 (2.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0

You can verify why a route is experiencing a RIB failure with the show bgp ipv4 unicast rib-failure command, as shown in Example 18-33. In this example, all three RIB failures are due to the BGP route having a higher AD.

Example 18-33 Verifying RIB Failures

R5#show bgp ipv4 unicast rib-failure
Network Next Hop RIB-failure RIB-NH Matches
10.1.5.0/24 2.2.2.2 Higher admin distance n/a
10.1.12.0/24 2.2.2.2 Higher admin distance n/a
10.1.13.0/24 2.2.2.2 Higher admin distance n/a

Route Filtering

The amount of control you have over routes in BGP is incredible—so much so, that we could dedicate an entire chapter to controlling BGP routes. However, that would be beyond the scope of the book and the TSHOOT exam. What we want to be able to do while troubleshooting missing routes is determine whether there is a route filter applied and if it is the cause of the missing routes. Example 18-34 displays the BGP table on R5 using the show bgp ipv4 unicast command. Notice that there is no entry for 10.1.13.0/24.

Example 18-34 Verifying Missing Routes on R5

However, let’s see whether we are receiving the route from R2 or R3 using the show bgp ipv4 unicast neighbors ip_address routes command, as shown in Example 18-35. The output clearly shows that we are not learning 10.1.13.0/24. But wait, this command displays routes learned after local filters have been applied. Therefore, let’s check to see whether R2 or R3 are advertising the 10.1.13.0/24 route before we check for filters. As shown in Example 18-36, which displays the output of the show bgp ipv4 unicast neighbors ip_address advertised-routes command, R2 and R3 are advertising the 10.1.13.0/24 network to R5.

Example 18-35 Verifying Whether Routes Are Being Received on R5

R5#show bgp ipv4 unicast neighbors 2.2.2.2 routes
BGP table version is 9, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.1/32 2.2.2.2 0 100 0 65501 ?
*>i 10.1.1.0/26 2.2.2.2 0 100 0 65501 i
*>i 10.1.1.0/24 2.2.2.2 0 100 0 65501 i
*>i 10.1.1.64/26 2.2.2.2 0 100 0 65501 i
*>i 10.1.1.128/26 2.2.2.2 0 100 0 65501 i
*>i 10.1.1.192/26 2.2.2.2 0 100 0 65501 i
r>i 10.1.5.0/24 2.2.2.2 3328 100 0 i
r>i 10.1.12.0/24 2.2.2.2 0 100 0 65501 ?

Total number of prefixes 8
R5#show bgp ipv4 unicast neighbors 3.3.3.3 routes
BGP table version is 9, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
* i 1.1.1.1/32 3.3.3.3 0 100 0 65501 ?
* i 10.1.1.0/26 3.3.3.3 0 100 0 65501 i
* i 10.1.1.0/24 3.3.3.3 0 100 0 65501 i
* i 10.1.1.64/26 3.3.3.3 0 100 0 65501 i
* i 10.1.1.128/26 3.3.3.3 0 100 0 65501 i
* i 10.1.1.192/26 3.3.3.3 0 100 0 65501 i
r i 10.1.5.0/24 3.3.3.3 3328 100 0 i
r i 10.1.12.0/24 3.3.3.3 0 100 0 65501 ?

Total number of prefixes 8

Example 18-36 Verifying Whether Routes Are Being Sent to R5

R2#show bgp ipv4 unicast neighbors 5.5.5.5 advertised-routes
BGP table version is 10, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
r> 1.1.1.1/32 1.1.1.1 0 0 65501 ?
*> 10.1.1.0/26 1.1.1.1 0 0 65501 i
*> 10.1.1.0/24 1.1.1.1 0 0 65501 i
*> 10.1.1.64/26 1.1.1.1 0 0 65501 i
*> 10.1.1.128/26 1.1.1.1 0 0 65501 i
*> 10.1.1.192/26 1.1.1.1 0 0 65501 i
*> 10.1.5.0/24 10.1.24.4 3328 32768 i
r> 10.1.12.0/24 1.1.1.1 0 0 65501 ?
*> 10.1.13.0/24 1.1.1.1 0 0 65501 ?

Total number of prefixes 9

R3#show bgp ipv4 unicast neighbors 5.5.5.5 advertised-routes
BGP table version is 10, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 10.1.13.1 0 0 65501 ?
*> 10.1.1.0/26 10.1.13.1 0 0 65501 i
*> 10.1.1.0/24 10.1.13.1 0 0 65501 i
*> 10.1.1.64/26 10.1.13.1 0 0 65501 i
*> 10.1.1.128/26 10.1.13.1 0 0 65501 i
*> 10.1.1.192/26 10.1.13.1 0 0 65501 i
*> 10.1.5.0/24 10.1.34.4 3328 32768 i
*> 10.1.12.0/24 10.1.13.1 0 0 65501 ?
r> 10.1.13.0/24 10.1.13.1 0 0 65501 ?

Total number of prefixes 9

Issuing the show ip protocols command as shown in Example 18-37 displays the incoming filter applied to the BGP autonomous system. It is a distribute list using the prefix list called FILTER_10.1.13.0/24, as shown in Example 18-37. The prefix list, as also shown in Example 18-37, is denying 10.1.13.0/24 and permitting all other routes.

Example 18-37 Verifying Whether Filters Are Applied to R5

R5#show ip protocols
...output omitted...

Routing Protocol is "bgp 65502"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is (prefix-list) FILTER_10.1.13.0/24
IGP synchronization is disabled
Automatic route summarization is disabled
Neighbor(s):
Address FiltIn FiltOut DistIn DistOut Weight RouteMap
2.2.2.2
3.3.3.3
Maximum path: 1
Routing Information Sources:...output omitted...

R5#show ip prefix-list
ip prefix-list FILTER_10.1.13.0/24: 2 entries
seq 5 deny 10.1.13.0/24
seq 10 permit 0.0.0.0/0 le 32

R5#show run | include bgp 65502|distribute-list
router bgp 65502
distribute-list prefix FILTER_10.1.13.0/24 in

The example we just reviewed focused on a filter that applied to the entire BGP process. Therefore, no matter which router we receive the route 10.1.13.0/24 from, it would be denied. However, you could apply a filter directly to a neighbor using any one of the following commands:

neighbor ip_address distribute-list access_list_number {in | out}

neighbor ip_address prefix-list prefix_list_name {in | out}

neighbor ip_address route-map map_name {in | out}

neighbor ip_address filter-list access_list_number {in | out}

How do you verify whether a route filter is applied specifically to a neighbor? You would verify the route filters with the same show commands as before. You just have to look in a different spot in the output. Refer to Example 18-38. In this example, an inbound distribute list is applied directly to the neighbor 2.2.2.2, as shown in the show ip protocols output. Notice that only the first six characters of the ACL are identified. We then review the running configuration and see that the distribute list is using the ACL named FILTER_10.1.13.0/24. Using the show ip access-listcommand confirms that the router is denying the 10.1.13.0/24 network from 2.2.2.2 but allowing all other networks.

Example 18-38 Verifying a Distribute List Applied to a Neighbor

R5#show ip protocols
...output omitted...

Routing Protocol is "bgp 65502"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
IGP synchronization is disabled
Automatic route summarization is disabled
Neighbor(s):
Address FiltIn FiltOut DistIn DistOut Weight RouteMap
2.2.2.2 FILTER
3.3.3.3
Maximum path: 1
Routing Information Sources:
...output omitted...

R5#show run | include bgp 65502|distribute-list
router bgp 65502
neighbor 2.2.2.2 distribute-list FILTER_10.1.13.0/24 in

R5#show ip access-lists
Standard IP access list FILTER_10.1.13.0/24
10 deny 10.1.13.0, wildcard bits 0.0.0.255
20 permit any

As noted earlier, you can also apply a route map, a prefix list, and a filter list directly to the neighbor command. The filter list will appear under the FiltIn and FiltOut column in show ip protocols, and the route map will appear under the RouteMap column in show ip protocols output. If the prefix list is applied directly to a neighbor statement, it does not appear in the output of show ip protocols. You will need to review the output of show bgp ipv4 unicast neighbors. However, as you recall, it is an extremely verbose output. Therefore, here is a shortcut that you might want to remember for troubleshooting route filters:

show bgp ipv4 unicast neighbors ip_address | include prefix|filter|Route map

Example 18-39 shows a sample of what would appear in the output of show bgp ipv4 unicast neighbors on R5 based on different filters applied to and from neighbors R2 and R3. In the output, you can see that there is an inbound prefix list applied directly to neighbor 3.3.3.3 called FILTER_10.1.13.0/24; there is also an outbound route map called FILTER_10.1.5.0/24 for routes sent to neighbor 3.3.3.3. With regard to neighbor 2.2.2.2, there is an inbound “network filter” (distribute list) applied to the neighbor statement that is using the ACL called FILTER_10.1.13.0/24, and also an inbound autonomous system path ACL called 25.

Example 18-39 Verifying Filters Applied to the neighbor Statements

R5#show bgp ipv4 unicast neighbors 3.3.3.3 | include prefix|filter|Route map
Incoming update prefix filter list is FILTER_10.1.13.0/24
Route map for outgoing advertisements is FILTER_10.1.5.0/24
R5#show bgp ipv4 unicast neighbors 2.2.2.2 | include prefix|filter|Route map
Incoming update network filter list is FILTER_10.1.13.0/24
Incoming update AS path filter list is 25

Troubleshooting BGP Path Selection

Unlike OSPF and EIGRP, BGP does not consider a link’s bandwidth when making a route decision. Instead, BGP uses various attributes when deciding which path is the best. When troubleshooting BGP paths, you need to have a solid understanding of all the attributes to fully comprehend why BGP made the decision it made. This section discusses the BGP best path decision-making process. In addition, we examine private autonomous system numbers.

Understanding the Best Path Decision-Making Process

The following list presents the order that BGP reviews the attributes when deciding which path is the best:

1. Prefer highest weight

2. Prefer highest local preference

3. Prefer route originated by the local router

4. Prefer shortest autonomous system path

5. Prefer lowest origin code

6. Prefer lowest MED (metric)

7. Prefer external over internal path

8. Prefer path through closest IGP neighbor

9. Prefer oldest route for eBGP paths

10. Prefer path with the lowest neighbor BGP RID

11. Prefer path with the lowest neighbor IP address

As you go through the BGP best path decision-making process, refer to Figure 18-6 and the output of show bgp ipv4 unicast 10.1.1.0 on R5 in Example 18-40.

Figure 18-6 Understanding the BGP Best Path Decision Process Topology

Example 18-40 Verifying the BGP Table on Router R5 for Network 10.1.1.0

R5#show bgp ipv4 unicast 10.1.1.0
BGP routing table entry for 10.1.1.0/26, version 46
Paths: (2 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 4
65501
2.2.2.2 (metric 131072) from 2.2.2.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
65501
3.3.3.3 (metric 131072) from 3.3.3.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0

Once BGP finds a match, it stops and uses that attribute as the reason for choosing the path as the best. It looks no further. In addition, if the next-hop IP address is not reachable, the router does not even go through this process because it considers the next-hop inaccessible:

1. BGP first looks at weight. Higher is better. In Example 18-40, no weight is listed because both paths are using the default value of 0. Therefore, weight is tied and the next attribute is checked.

2. Local preference is checked next. Higher is better. In Example 18-40, localpref is 100 (default) for both paths; therefore, local preference is tied and the next attribute is checked.

3. The router checks whether it generated the BGP route (has a next hop of 0.0.0.0). If it did, it is preferred. In Example 18-40, the next hops are 2.2.2.2 and 3.3.3.3 on the far left of the output. Therefore, R5 did not generate any of the routes, and the next attribute is checked.

4. The autonomous system path is checked next. The shortest path is preferred. In Example 18-40, the autonomous system path is 65501 for both. Therefore, the autonomous system path is tied, and the next attribute is checked.

5. The origin code is checked next. IGP is better than EGP, which is better than incomplete. Note that this is not related to iBGP versus eBGP, which is covered later. IGP means the route was generated with the network mask or summary-address command, and incomplete means the route was redistributed into BGP. EGP means it was generated from EGP, the predecessor to BGP. In Example 18-40, the origin is IGP for both which means that the next attribute will be checked.

6. MED (metric) is next. Lower is better. In Example 18-40, the MED (metric) is the same for both (0). Therefore, the next attribute has to be checked.

7. Now eBGP is preferred over iBGP. In Example 18-40, they are both learned via iBGP (internal). Therefore, this attribute is tied as well and the next will have to be checked.

8. The IGP path to the neighbor is compared now. In Example 18-40, the IGP path to 2.2.2.2 has a metric of 131072, and the IGP path to 3.3.3.3 has a metric of 131072. They are tied. Therefore, the next attribute has to be checked.

9. If they are eBGP paths, the age of the routes are checked. In Example 18-40, both paths are iBGP paths. Therefore, we skip this attribute and move on to the next attribute.

10. The BGP RIDs are now compared. Lower is better. In Example 18-40, neighbor 2.2.2.2 has a RID of 2.2.2.2 (as displayed in the brackets), and neighbor 3.3.3.3 has a RID of 3.3.3.3 (as displayed in the brackets). Which RID is lower? 2.2.2.2 Therefore, the route provided by the neighbor with the RID of 2.2.2.2 is considered the best path. If the RID happens to be tied, the neighbor IP address is used to break the tie.

Now it is your turn! Try the following on your own, and then we will walk you through it. Refer to Figure 18-7 and Example 18-41 and determine which attribute R2 is using to choose the best path to reach 10.1.1.128.

Figure 18-7 Practicing the BGP Best Path Decision Process Topology

Example 18-41 Practicing the BGP Best Path Decision Process

R2#show bgp ipv4 unicast 10.1.1.128
BGP routing table entry for 10.1.1.128/26, version 6
Paths: (2 available, best #2, table default)
Advertised to update-groups:
2
Refresh Epoch 2
65501
3.3.3.3 (metric 131072) from 3.3.3.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Refresh Epoch 3
65501
1.1.1.1 from 1.1.1.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0

Alright, let’s walk through it together:

1. Prefer highest weight Tied

2. Prefer highest local preference Tied

3. Prefer route originated by the local router None

4. Prefer shortest autonomous system path Same at 65501

5. Prefer lowest origin code Same

6. Prefer lowest MED (Metric) Tied at 0

7. Prefer external (eBGP) over internal (iBGP) path Not Tied Stop

The path learned from neighbor 1.1.1.1 is external (eBGP) and the path learned from neighbor 3.3.3.3 is internal (iBGP). Therefore, the path learned from neighbor 1.1.1.1 is preferred because external is preferred over internal.

If you are not getting desired paths, or the paths you expect to be used as best, you need to be able to walk through this process while troubleshooting to figure out why the current best path was chosen as such. There may have been an attribute that was modified locally or remotely at some point that is influencing the decision that is being made. You need to be able to recognize this and then manipulate the paths in your favor by modifying the necessary attributes.

Private Autonomous System Numbers

Like IPv4 addresses, BGP autonomous system numbers also have a private range. In the 2-byte autonomous system range it is 64,512 to 65,534, and for the 4-byte autonomous system range, it is 4,200,000,000 to 4,294,967,294. These autonomous system numbers can be used for networks that are single-homed or dual-homed to the same ISP, thereby preserving the public autonomous system numbers for those networks that are multihomed to multiple ISPs.

Although the private autonomous system numbers can be used in the customer’s network, it is imperative that the autonomous system number is not in the AS_PATH attribute when the routes are advertised to the Internet (global BGP table) because multiple autonomous systems could be using the same private autonomous system number which would then cause issues on the Internet.

If private autonomous system numbers are being sent into the global BGP table, they need to be stopped. You can accomplish this with the neighbor ip_address remove-private-as command.

Using debug Commands

The majority of changes that occur with BGP will generate syslog messages in real time. Therefore, you will be notified via syslog if any neighbor issues occur. So, unless you really need to, avoid using the large number of debugs that are available because they place a large amount of pressure on the routers’ resources. Only use as a last resort! Following you will find a few debug commands that might be useful. However, up to this point, all the show commands we have covered and your knowledge can determine the same thing.

Example 18-42 provides sample output from the debug ip routing command. The output from this command shows updates to a router’s IP routing table. In this example, the Loopback 0 interface (with an IP address of 10.3.3.3) of a neighboring router was administratively shut down and then administratively brought back up. As the 10.3.3.3/32 network became unavailable and then once again became available, you can see that the 10.3.3.3/32 route was deleted and then added to this router’s IP routing table. Notice that this output is not specific to BGP. Therefore, you can use the debug ip routing command with routing processes other than BGP.

Example 18-42 debug ip routing Command Output

R2#debug ip routing
IP routing debugging is on
RT: 10.3.3.3/32 gateway changed from 172.16.1.1 to 172.16.2.2
RT: NET-RED 10.3.3.3/32
RT: del 10.3.3.3/32 via 172.16.2.2, bgp metric [20/0]
RT: delete subnet route to 10.3.3.3/32
RT: NET-RED 10.3.3.3/32
RT: SET_LAST_RDB for 10.3.3.3/32
NEW rdb: via 172.16.1.1

RT: add 10.3.3.3/32 via 172.16.1.1, bgp metric [20/0]
RT: NET-RED 10.3.3.3/32

Example 18-43 provides sample output from the debug ip bgp command. The output of this command does not show the contents of BGP updates; however, this command can be useful in watching real-time state changes for IPv4 BGP peering relationships. In this example, you can see a peering session being closed for the neighbor with an IP address of 172.16.1.1.

Example 18-43 debug ip bgp Command Output

R2#debug ip bgp
BGP debugging is on for address family: IPv4 Unicast
*Mar 1 00:23:26.535: BGP: 172.16.1.1 remote close, state CLOSEWAIT
*Mar 1 00:23:26.535: BGP: 172.16.1.1 -reset the session
*Mar 1 00:23:26.543: BGPNSF state: 172.16.1.1 went from nsf_not_active to
nsf_not_active
*Mar 1 00:23:26.547: BGP: 172.16.1.1 went from Established to Idle
*Mar 1 00:23:26.547: %BGP-5-ADJCHANGE: neighbor 172.16.1.1 Down Peer closed the
session
*Mar 1 00:23:26.547: BGP: 172.16.1.1 closing
*Mar 1 00:23:26.651: BGP: 172.16.1.1 went from Idle to Active
*Mar 1 00:23:26.663: BGP: 172.16.1.1 open active delayed 30162ms (35000ms max,
28% jitter)

Example 18-44 provides sample output from the debug ip bgp updates command. This command produces more detailed output than the debug ip bgp command. Specifically, you can see the content of IPv4 BGP updates. In this example, you see a route of 10.3.3.3/32 being added to a router’s IP routing table.

Example 18-44 debug ip bgp updates Command Output

R2#debug ip bgp updates
BGP updates debugging is on for address family: IPv4 Unicast
*Mar 1 00:24:27.455: BGP(0): 172.16.1.1 NEXT_HOP part 1 net 10.3.3.3/32, next
172.16.1.1
*Mar 1 00:24:27.455: BGP(0): 172.16.1.1 send UPDATE (format) 10.3.3.3/32, next
172.16.1.1, metric 0, path 65002
*Mar 1 00:24:27.507: BGP(0): 172.16.1.1 rcv UPDATE about 10.3.3.3/32 — withdrawn
*Mar 1 00:24:27.515: BGP(0): Revise route installing 1 of 1 routes for
10.3.3.3/32 -> 172.16.2.2(main) to main IP table
*Mar 1 00:24:27.519: BGP(0): updgrp 1 - 172.16.1.1 updates replicated for
neighbors: 172.16.2.2
*Mar 1 00:24:27.523: BGP(0): 172.16.1.1 send UPDATE (format) 10.3.3.3/32, next
172.16.1.2, metric 0, path 65003 65002
*Mar 1 00:24:27.547: BGP(0): 172.16.2.2 rcvd UPDATE w/ attr: nexthop 172.16.2.2,
origin i, path 65003 65002
*Mar 1 00:24:27.551: BGP(0): 172.16.2.2 rcvd 10.3.3.3/32...duplicate ignored
*Mar 1 00:24:27.555: BGP(0): updgrp 1 - 172.16.1.1 updates replicated for
neighbors: 172.16.2.2
*Mar 1 00:24:27.675: BGP(0): 172.16.2.2 rcv UPDATE w/ attr: nexthop 172.16.2.2,
origin i, originator 0.0.0.0, path 65003 65001 65002, community, extended
community
*Mar 1 00:24:27.683: BGP(0): 172.16.2.2 rcv UPDATE about 10.3.3.3/32 — DENIED
due to: AS-PATH contains our own AS;
...OUTPUT OMITTED...

Troubleshooting BGP for IPv6

BGP for IPv4 and BGP for IPv6 are configured in the same BGP autonomous system configuration mode. This is known as Multiprotocol BGP, or MP-BGP for short. Implementing BGP for IPv4 and IPv6 on the same router requires the use of address families and the activation of neighbors for those address families. This section examines the additional issues (on top of what was already covered thus far in the chapter) that you may encounter when using MP-BGP with IPv4 and IPv6 unicast routes. Refer to Figure 18-8 while reviewing this section.

Figure 18-8 MP-BGP Topology

There are two different ways to exchange IPv6 routes with BGP. You can exchange them over IPv4 TCP sessions or IPv6 TCP sessions. Example 18-45 displays a sample BGP configuration where IPv6 routes are exchanged over an IPv4 TCP session.

Notice how there are two address families: one for IPv4 unicast, and one for IPv6 unicast. The neighbors and remote autonomous system numbers are identified outside of the address family (AF) configuration. You then activate the neighbor within the AF with the neighbor ip_addressactivate command. In this example, the IPv6 AF is using an IPv4 neighbor address to establish the TCP session. Therefore, the TCP session will be IPv4 based. Reviewing the output of show bgp ipv6 unicast summary, as shown in Example 18-46, shows the IPv6 unicast AF neighbor adjacency that has been formed with router 2.2.2.2. Notice that the adjacency has been formed with an IPv4 unicast address. It also states that one IPv6 prefix has been learned from the neighbor.

Example 18-45 MP-BGP Configuration for IPv6 Routes Over IPv4 TCP Session

R1#show run | s router bgp
router bgp 65501
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 65502
neighbor 2.2.2.2 ebgp-multihop 2
neighbor 2.2.2.2 password CISCO
neighbor 2.2.2.2 update-source Loopback0
!
address-family ipv4
network 10.1.1.0 mask 255.255.255.192
network 10.1.1.64 mask 255.255.255.192
network 10.1.1.128 mask 255.255.255.192
network 10.1.1.192 mask 255.255.255.192
aggregate-address 10.1.1.0 255.255.255.0
redistribute connected
neighbor 2.2.2.2 activate
exit-address-family
!
address-family ipv6
network 2001:DB8:1::/64
neighbor 2.2.2.2 activate
exit-address-family

Example 18-46 Verifying MP-BGP IPv6 Unicast Neighbor Adjacencies

R1#show bgp ipv6 unicast summary
BGP router identifier 1.1.1.1, local AS number 65501
BGP table version is 2, main routing table version 2
2 network entries using 336 bytes of memory
2 path entries using 208 bytes of memory
2/1 BGP path/bestpath attribute entries using 272 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 840 total bytes of memory
BGP activity 11/0 prefixes, 18/6 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 65502 25 25 2 0 0 00:12:02 1

To verify the IPv6 unicast routes that have been learned from all neighbors, you can issue the show bgp ipv6 unicast command, as shown in Example 18-47. This displays the IPv6 BGP table. The route 2001:db8:1::/64 is locally originated because of the next hop ::, and it is in the routing table as indicated by the *> at the beginning of the entry. Examine the 2001:db8:2::/64 route. This is the route that was learned from R2 (the 2.2.2.2 neighbor). It is not installed in the routing table as indicated by the absence of the *>. The reason is because the next hop is not reachable. The address ::FFFF:2.2.2.2 is a dynamically generated next hop that was created to replace the original next hop of 2.2.2.2. This occurs because an IPv6 route cannot have an IPv4 next-hop address. Why was the next hop an IPv4 address? This is because the adjacency is an IPv4 adjacency for the IPv6 AF.

Example 18-47 Verifying MP-BGP IPv6 Unicast Routes in the IPv6 BGP Table

R1#show bgp ipv6 unicast
BGP table version is 2, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*> 2001:DB8:1::/64 :: 0 32768 i
* 2001:DB8:2::/64 ::FFFF:2.2.2.2 0 0 65502 i

To solve this issue, you need to create a route map that will change the next hop to a valid IPv6 address and attach it to the neighbor statement. Now, be very careful with this. It has to be done on the router advertising the route, not receiving the route. In Example 18-48, a route map is configured on R2 that changes the next-hop address to 2001:db8:12::2. The route map is then attached to the neighbor 1.1.1.1 outbound.

Example 18-48 Modifying the BGP Next Hop

R2#config t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#route-map CHANGE_NH permit 10
R2(config-route-map)#set ipv6 next-hop 2001:db8:12::2
R2(config-route-map)#exit
R2(config)#router bgp 65502
R2(config-router)#address-family ipv6 unicast
R2(config-router-af)#neighbor 1.1.1.1 route-map CHANGE_NH out

When you examine the output of show bgp ipv6 unicast again in Example 18-49, the next hop is now a valid hop, and the route is installed in the table.

Example 18-49 Verifying the BGP Next Hop

R1#show bgp ipv6 unicast
BGP table version is 3, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*> 2001:DB8:1::/64 :: 0 32768 i
*> 2001:DB8:2::/64 2001:DB8:12::2 0 0 65502 i

When forming IPv6 TCP sessions and neighbor relationships, you do not have to worry about the issue just described. However, you have to make sure that you define the IPv6 neighbor and activate it. Take a look at Example 18-50. To form the IPv6 TCP session, you define the neighbor with the neighbor ipv6_address remote-as autonomous_system_number command outside of the AF configuration, and then you activate the neighbor in the IPv6 AF configuration with the neighbor ipv6_address activate command.

Example 18-50 MP-BGP Configuration for IPv6 Routes over IPv6 TCP Session

R1#show run | section router bgp
router bgp 65501
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 65502
neighbor 2.2.2.2 ebgp-multihop 2
neighbor 2.2.2.2 password CISCO
neighbor 2.2.2.2 update-source Loopback0
neighbor 10.1.13.3 remote-as 65502
neighbor 2001:DB8:12::2 remote-as 65502
!
address-family ipv4
network 10.1.1.0 mask 255.255.255.192
network 10.1.1.64 mask 255.255.255.192
network 10.1.1.128 mask 255.255.255.192
network 10.1.1.192 mask 255.255.255.192
aggregate-address 10.1.1.0 255.255.255.0
redistribute connected
neighbor 2.2.2.2 activate
neighbor 10.1.13.3 activate
no neighbor 2001:DB8:12::2 activate
exit-address-family
!
address-family ipv6
network 2001:DB8:1::/64
neighbor 2001:DB8:12::2 activate
exit-address-family

The output of show bgp ipv6 unicast summary as shown in Example 18-51 shows that R1 has formed an IPv6 BGP neighbor adjacency with the device at 2001:db8:12::2 using an IPv6 TCP session, and one prefix has been received. The IPv6 BGP table, as displayed in the output of show bgp ipv6 unicast command in Example 18-52, indicates that 2001:DB8:2::/64 can be reached with a next hop of 2001:DB8:12::2 and that it is installed in the routing table, as indicated by the *>.

Example 18-51 MP-BGP Adjacencies with IPv6 TCP Sessions

R1#show bgp ipv6 unicast summary
BGP router identifier 1.1.1.1, local AS number 65501
BGP table version is 5, main routing table version 5
2 network entries using 336 bytes of memory
2 path entries using 208 bytes of memory
2/2 BGP path/bestpath attribute entries using 272 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 840 total bytes of memory
BGP activity 12/1 prefixes, 22/10 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2001:DB8:12::2 4 65502 5 5 4 0 0 00:00:05 1

Example 18-52 Verifying IPv6 BGP Table

R1#show bgp ipv6 unicast
BGP table version is 5, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*> 2001:DB8:1::/64 :: 0 32768 i
*> 2001:DB8:2::/64 2001:DB8:12::2 0 0 65502 i

BGP Trouble Tickets

This section presents various trouble tickets relating to the topics discussed earlier in the chapter. The purpose of these trouble tickets is to give a process that you can follow when troubleshooting in the real world or in an exam environment. All trouble tickets in this section are based on the topology depicted in Figure 18-9.

Figure 18-9 BGP Trouble Tickets Topology

Trouble Ticket 18-1

Problem: You are the administrator for BGP autonomous system 65502. While you were away on vacation, the link between R1 and R2 failed. When the link between R1 and R2 fails, the link between R1 and R3 is supposed to forward traffic to BGP autonomous system 65501. However, that did not occur while you were away. Your co-worker had to restore connectivity between R1 and R2 while complaints kept flowing in from the users in 10.1.5.0/24 about connectivity to the 10.1.1.0/24 networks being down.

At this point, connectivity is fine. You confirm this by pinging from a PC in 10.1.5.0/24 to 10.1.1.10. In Example 18-53, the ping is successful. Because it is the middle of the day, you cannot bring down the link between R1 and R2 to re-create the issue because it will disrupt the network users. Therefore, you need to be creative with your troubleshooting efforts.

Example 18-53 Verifying Connectivity

C:\>ping 10.1.1.10

Pinging 10.1.1.10 with 32 bytes of data:

Reply from 10.1.1.10: bytes=32 time 1ms TTL=128
Reply from 10.1.1.10: bytes=32 time 1ms TTL=128
Reply from 10.1.1.10: bytes=32 time 1ms TTL=128
Reply from 10.1.1.10: bytes=32 time 1ms TTL=128

Ping statistics for 10.1.1.10:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

For router R5 to know about the networks in autonomous system 65501, they have to be advertised to it. The best place to see whether R5 is learning about the routes is R5’s BGP table. Based on the network topology, R5 should be learning about the networks from R2 and R3. In Example 18-54, the output of show bgp ipv4 unicast is displayed. As you can see from the next-hop column, all valid routes to the 10.1.1.x/26 networks are via the next hop of 2.2.2.2, which is R2. There are no entries for R3 at 3.3.3.3 that are valid for those networks.

Example 18-54 Examining R5’s BGP Table

R5#show bgp ipv4 unicast
BGP table version is 56, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.1/32 2.2.2.2 0 100 0 65501 ?
*>i 10.1.1.0/26 2.2.2.2 0 100 0 65501 i
*>i 10.1.1.64/26 2.2.2.2 0 100 0 65501 i
*>i 10.1.1.128/26 2.2.2.2 0 100 0 65501 i
*>i 10.1.1.192/26 2.2.2.2 0 100 0 65501 i
r>i 10.1.5.0/24 2.2.2.2 3328 100 0 i
r i 3.3.3.3 3328 100 0 i
r>i 10.1.12.0/24 2.2.2.2 0 100 0 65501 ?
r>i 10.1.13.0/24 2.2.2.2 0 100 0 65501 ?

Next you want to confirm whether R5 is even receiving the routes from R3. Therefore, you issue the command show bgp ipv4 unicast neighbors 2.2.2.2 routes and show bgp ipv4 unicast neighbors 3.3.3.3 routes to determine which routes are being received and to compare what is being advertised from R2 versus R3. The output in Example 18-55 clearly shows that R5 is not receiving any routes about the 10.1.1.x/26 networks from R3. This is the reason why network connectivity was lost when the link between R1 and R2 went down. R5 does not have any route information from R3.

Example 18-55 Examining Routes Received from R2 and R3

R5#show bgp ipv4 unicast neighbors 2.2.2.2 routes
BGP table version is 56, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.1/32 2.2.2.2 0 100 0 65501 ?
*>i 10.1.1.0/26 2.2.2.2 0 100 0 65501 i
*>i 10.1.1.64/26 2.2.2.2 0 100 0 65501 i
*>i 10.1.1.128/26 2.2.2.2 0 100 0 65501 i
*>i 10.1.1.192/26 2.2.2.2 0 100 0 65501 i
r>i 10.1.5.0/24 2.2.2.2 3328 100 0 i
r>i 10.1.12.0/24 2.2.2.2 0 100 0 65501 ?
r>i 10.1.13.0/24 2.2.2.2 0 100 0 65501 ?

Total number of prefixes 8
R5#show bgp ipv4 unicast neighbors 3.3.3.3 routes
BGP table version is 56, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
r i 10.1.5.0/24 3.3.3.3 3328 100 0 i

Total number of prefixes 1

You access R3 and issue the show bgp ipv4 unicast neighbors 5.5.5.5 advertised-routes command to determine which routes, if any, R3 is sending to R5. In Example 18-56 you can see that there are no routes related to the 10.1.1.x/26 networks being advertised to R5. So, that raises the question, does R3 even know about the networks?

Example 18-56 Examining Routes Sent from R3 to R5

R3#show bgp ipv4 unicast neighbors 5.5.5.5 advertised-routes
BGP table version is 108, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*> 10.1.5.0/24 10.1.34.4 3328 32768 i

Total number of prefixes 1

On R3, you issue the command show ip route 10.1.1.0 255.255.255.0 longer-prefixes, as shown in Example 18-57, and confirm that the networks are learned via BGP. However, you also notice something else that is strange. The AD is 200, which is the value associated with iBGP-learned routes and the next hop is via 2.2.2.2, which is R2. The AD should be 20 for eBGP, and the next hop should be R1’s IP in this case.

Example 18-57 Examining BGP Routes in R3’s Routing Table

R3#show ip route 10.1.1.0 255.255.255.0 longer-prefixes
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 14 subnets, 3 masks
B 10.1.1.0/26 [200/0] via 2.2.2.2, 00:09:07
B 10.1.1.64/26 [200/0] via 2.2.2.2, 00:09:07
B 10.1.1.128/26 [200/0] via 2.2.2.2, 00:09:07
B 10.1.1.192/26 [200/0] via 2.2.2.2, 00:09:07

You issue the command show bgp ipv4 unicast on R3 to check the BGP table, as shown in Example 18-58. Based on the output, only R2 and R4 are next hops for routes. R1 is not a next hop for any of them.

Example 18-58 Examining BGP Routes in R3’s BGP Table

R3#show bgp ipv4 unicast
BGP table version is 108, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.1/32 2.2.2.2 0 100 0 65501 ?
*>i 10.1.1.0/26 2.2.2.2 0 100 0 65501 i
*>i 10.1.1.0/24 2.2.2.2 0 100 0 65501 i
*>i 10.1.1.64/26 2.2.2.2 0 100 0 65501 i
*>i 10.1.1.128/26 2.2.2.2 0 100 0 65501 i
*>i 10.1.1.192/26 2.2.2.2 0 100 0 65501 i
* i 10.1.5.0/24 2.2.2.2 3328 100 0 i
*> 10.1.34.4 3328 32768 i
r>i 10.1.12.0/24 2.2.2.2 0 100 0 65501 ?
r>i 10.1.13.0/24 2.2.2.2 0 100 0 65501 ?

Issuing the show bgp ipv4 unicast neighbors 10.1.13.1 routes command on R3 confirms that no routes are being received from R1, as shown in Example 18-59.

Example 18-59 Verifying Routes Learned from R1

R3#show bgp ipv4 unicast neighbors 10.1.13.1 routes

Total number of prefixes 0

Because R1 is not in your autonomous system, you cannot access it for troubleshooting purposes. Therefore, you will need to call the admin in autonomous system 65501. However, do not do that just yet. We can check many more items on R3. For example, to learn BGP routes, you need a BGP adjacency. To confirm that R3 is a neighbor with R1, you issue the show bgp ipv4 unicast summary command, as shown in Example 18-60. Based on the output, R1 and R3 are not neighbors because the state is listed as idle. You think you have found the issue.

Example 18-60 Verifying Neighbor Adjacency Between R1 and R3

R3#show bgp ipv4 unicast summary
BGP router identifier 3.3.3.3, local AS number 65502
BGP table version is 108, main routing table version 108
9 network entries using 1296 bytes of memory
10 path entries using 800 bytes of memory
5/4 BGP path/bestpath attribute entries using 680 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 2800 total bytes of memory
BGP activity 17/8 prefixes, 71/61 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/
PfxRcd
2.2.2.2 4 65502 34 34 108 0 0 00:24:29 9
4.4.4.4 4 65502 47 48 108 0 0 00:39:00 0
5.5.5.5 4 65502 5 6 108 0 0 00:00:18 0
10.1.13.1 4 65510 0 0 1 0 0 never Idle

Comparing the output in Example 18-60 to your network documentation (Figure 18-9), you notice that the autonomous system number is incorrect for 10.1.13.1. It is listed as 65510 when it should be 65501. To fix the issue, you remove the current neighbor remote-as statement and add the correct one, as shown in Example 18-61. Once the changes are made, the neighbor relationship is up.

Example 18-61 Modifying the neighbor remote-as Statement

R3#config t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#router bgp 65502
R3(config-router)#no neighbor 10.1.13.1 remote-as 65510
R3(config-router)#neighbor 10.1.13.1 remote-as 65501
%BGP-5-ADJCHANGE: neighbor 10.1.13.1 Up
R3(config-router)#

To confirm that everything is fine, you access R5 and issue the show bgp ipv4 unicast command and confirm that routes from R2 and R3 are now listed in the BGP table, as shown in Example 18-62. Issue solved. After hours, you will bring down the link between R1 and R2 and confirm that traffic successfully flows between R3 and R1.

Example 18-62 Confirming R5 Knows Routes from R2 and R3

R5#show bgp ipv4 unicast
BGP table version is 56, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
* i 1.1.1.1/32 3.3.3.3 0 100 0 65501 ?
*>i 2.2.2.2 0 100 0 65501 ?
* i 10.1.1.0/26 3.3.3.3 0 100 0 65501 i
*>i 2.2.2.2 0 100 0 65501 i
* i 10.1.1.64/26 3.3.3.3 0 100 0 65501 i
*>i 2.2.2.2 0 100 0 65501 i
* i 10.1.1.128/26 3.3.3.3 0 100 0 65501 i
*>i 2.2.2.2 0 100 0 65501 i
* i 10.1.1.192/26 3.3.3.3 0 100 0 65501 i
*>i 2.2.2.2 0 100 0 65501 i
r i 10.1.5.0/24 3.3.3.3 3328 100 0 i
r>i 2.2.2.2 3328 100 0 i
Network Next Hop Metric LocPrf Weight Path
r i 10.1.12.0/24 3.3.3.3 0 100 0 65501 ?
r>i 2.2.2.2 0 100 0 65501 ?
r i 10.1.13.0/24 3.3.3.3 0 100 0 65501 ?
r>i 2.2.2.2 0 100 0 65501 ?

With a little bit of spare time on your hands, you decide to check the log files from R3. You notice the following BGP message listed many times:

%BGP-3-NOTIFICATION: sent to neighbor 10.1.13.1 passive 2/2 (peer in wrong AS) 2 bytes FFDD

The syslog message clearly states that the peer is in the wrong autonomous system. Never forget to check your log files before you troubleshoot. It can save you valuable time.

Trouble Ticket 18-2

Problem: You are the administrator for BGP autonomous system 65501. Users in the 10.1.1.0/26 and 10.1.1.64/26 networks have indicated that they are not able to access resources located at 10.1.5.5. However, they can access resources locally.

You begin troubleshooting by issuing two pings on R1 to 10.1.5.5 and sourcing them from 10.1.1.1 and 10.1.1.65. As shown in Example 18-63, the pings fail.

Example 18-63 Verifying Issue with a Ping

R1#ping 10.1.5.5 source 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.5.5, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
.....
Success rate is 0 percent (0/5)
R1#ping 10.1.5.5 source 10.1.1.65
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.5.5, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.65
.....
Success rate is 0 percent (0/5)

You confirm with the command show ip route 10.1.5.5 on R1, as shown in Example 18-64, that there is a route to 10.1.5.5 via R2 learned via BGP.

Example 18-64 Confirming R1 Has a Route to 10.1.5.5

R1#show ip route 10.1.5.5
Routing entry for 10.1.5.0/24
Known via "bgp 65501", distance 20, metric 3328
Tag 65502, type external
Last update from 2.2.2.2 00:12:35 ago
Routing Descriptor Blocks:
* 2.2.2.2, from 2.2.2.2, 00:12:35 ago
Route metric is 3328, traffic share count is 1
AS Hops 1
Route tag 65502
MPLS label: none

You would like to see how far the packets are traveling to get a rough idea of where they might be failing. Therefore, you decide to issue an extended traceroute to hopefully gather some additional information. In Example 18-65, you can see that the trace is failing at the next hop router (R2).

Example 18-65 Identifying How Far Packets Are Traveling Before They Fail

R1#traceroute 10.1.5.5 source 10.1.1.1
Type escape sequence to abort.
Tracing the route to 10.1.5.5
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.12.2 40 msec 44 msec 28 msec
2 * * *
3 * * *
4 * * *
...output omitted...
R1#traceroute 10.1.5.5 source 10.1.1.65
Type escape sequence to abort.
Tracing the route to 10.1.5.5
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.12.2 44 msec 48 msec 36 msec
2 * * *
3 * * *
4 * * *
...output omitted...

You are a bit confused, so you sit back and review what you know. You have confirmed that R1 knows about 10.1.5.5 via R2. Therefore, R1 can route packets toward that address. However, the trace that was executed is failing at R2. Is it possible that R2 does not know how to reach 10.1.1.0/26 or 10.1.1.64/26 to respond to the trace? Is it possible that 10.1.5.5 does not know about the networks either and cannot respond to the ping? You decide to focus on your thoughts about R2. R2 needs to know about the routes 10.1.1.0/26 and 10.1.1.64/26 to successfully respond to the trace. Therefore, R1 needs to be advertising the networks with the BGP network mask command. On R1, you issue the command show bgp ipv4 unicast to verify whether 10.1.1.0/26 and 10.1.1.64/26 are in the BGP table. As shown in Example 18-66, they are. Because they are in the BGP table and they are listed as valid and best, they can be advertised to the neighbors.

Example 18-66 Verifying R1’s BGP Table

R1#show bgp ipv4 unicast
BGP table version is 10, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 ?
*> 10.1.1.0/26 0.0.0.0 0 32768 i
*> 10.1.1.64/26 0.0.0.0 0 32768 i
*> 10.1.1.128/26 0.0.0.0 0 32768 i
*> 10.1.1.192/26 0.0.0.0 0 32768 i
* 10.1.5.0/24 10.1.13.3 3328 0 65502 i
*> 2.2.2.2 3328 0 65502 i
*> 10.1.12.0/24 0.0.0.0 0 32768 ?
*> 10.1.13.0/24 0.0.0.0 0 32768 ?

You issue the command show bgp ipv4 unicast summary to verify the BGP neighbors. Based on the output in Example 18-67, you confirm that both R2 and R3 are BGP neighbors because there is a number in the PfxRcd column.

Example 18-67 Verifying R1’s BGP Neighbors

R1#show bgp ipv4 unicast summary
BGP router identifier 1.1.1.1, local AS number 65501
BGP table version is 10, main routing table version 10
9 network entries using 1296 bytes of memory
10 path entries using 800 bytes of memory
4/4 BGP path/bestpath attribute entries using 544 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 2664 total bytes of memory
BGP activity 19/10 prefixes, 54/44 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 65502 38 39 10 0 0 00:30:05 1
10.1.13.3 4 65502 7 6 10 0 0 00:02:06 1

Next you issue the show bgp ipv4 unicast neighbors 2.2.2.2 advertised-routes command and the show bgp ipv4 unicast neighbors 10.1.13.3 advertised-routes command to verify which routes are being advertised to R2 and R3. As verified in Example 18-68, no routes are being advertised to the neighbors.

Example 18-68 Verifying R1’s Advertised Routes

R1#show bgp ipv4 unicast neighbors 2.2.2.2 advertised-routes

Total number of prefixes 0
R1#show bgp ipv4 unicast neighbors 10.1.13.3 advertised-routes

Total number of prefixes 0

What could prevent a route that is valid and best in the BGP table from being advertised to an eBGP neighbor? A filter? You decide to check the output of show ip protocols to determine whether a filter is applied to the BGP autonomous system. As shown in Example 18-69, no filter is applied.

Example 18-69 Verifying Whether R1 Has Any BGP Filters.

R1#show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "bgp 65501"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
IGP synchronization is disabled
Automatic route summarization is disabled
Redistributing: connected
Unicast Aggregate Generation:
10.1.1.0/24
Neighbor(s):
Address FiltIn FiltOut DistIn DistOut Weight RouteMap
2.2.2.2
10.1.13.3
Maximum path: 1
Routing Information Sources:
Gateway Distance Last Update
2.2.2.2 20 00:37:02
10.1.13.3 20 21:12:13
Distance: external 20 internal 200 local 200

But wait, you remember from your TSHOOT studies that a prefix list filter does not show up in the output of show ip protocols. It shows up only in the BGP neighbor output. Therefore, you issue the command show bgp ipv4 unicast neighbors | i prefix to see whether there is any prefix list applied at all. In the output of Example 18-70, you can see the same prefix list called BGP_FILTER applied twice in the outbound direction.

Example 18-70 Verifying Whether R1 Has Any BGP Prefix List Filters

R1#show bgp ipv4 unicast neighbors | i prefix
Outgoing update prefix filter list is BGP_FILTER
prefix-list 27 0
Outgoing update prefix filter list is BGP_FILTER
prefix-list 27 0

Now you feel like you are on the right track. Therefore, you issue the show run | section router bgp command, as shown in Example 18-71, to examine the BGP configuration on R1 and look for the culprit. You immediately notice that the prefix list BGP_FILTER is applied to neighbor 2.2.2.2 and 10.1.13.3 in the outbound direction.

Example 18-71 Verifying BGP Configuration on R1

R1#show run | section router bgp
router bgp 65501
bgp log-neighbor-changes
network 10.1.1.0 mask 255.255.255.192
network 10.1.1.64 mask 255.255.255.192
network 10.1.1.128 mask 255.255.255.192
network 10.1.1.192 mask 255.255.255.192
aggregate-address 10.1.1.0 255.255.255.0
redistribute connected
neighbor 2.2.2.2 remote-as 65502
neighbor 2.2.2.2 password CISCO
neighbor 2.2.2.2 ebgp-multihop 2
neighbor 2.2.2.2 update-source Loopback0
neighbor 2.2.2.2 prefix-list BGP_FILTER out
neighbor 10.1.13.3 remote-as 65502
neighbor 10.1.13.3 prefix-list BGP_FILTER out

Now you want to examine the prefix list, so you issue the command show ip prefix-list BGP_FILTER, as shown in Example 18-72. You immediately notice that 10.1.1.128/26 and 10.1.1.192/26 are being denied. Therefore, they are not being advertised to R2 or R3. You check your documentation, and it states that 10.1.1.128/26 and 10.1.1.192/26 should not be advertised to BGP autonomous system 65502, which this prefix list accomplishes.

Example 18-72 Verifying a Prefix List on R1

R1#show ip prefix-list BGP_FILTER
ip prefix-list BGP_FILTER: 2 entries
seq 5 deny 10.1.1.128/26
seq 10 deny 10.1.1.192/26

You think about this issue a bit more, and then it hits you. The implicit deny all at the end of the prefix list is denying all other routes. You propose that by adding the entry ip prefix-list BGP_FILTER permit 0.0.0.0/0 le 32, as shown in Example 18-73, to R1 will permit all other routes, which in this case are 10.1.1.0/26 and 10.1.1.64/26. The command show ip prefix-list BGP_FILTER confirms that it has been added.

Example 18-73 Modifying a Prefix List on R1

R1#config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#ip prefix-list BGP_FILTER permit 0.0.0.0/0 le 32
R1(config)#end
%SYS-5-CONFIG_I: Configured from console by console
R1#show ip prefix-list BGP_FILTER
ip prefix-list BGP_FILTER: 3 entries
seq 5 deny 10.1.1.128/26
seq 10 deny 10.1.1.192/26
seq 15 permit 0.0.0.0/0 le 32

To force a refresh of the BGP information being sent to R1’s neighbors, you issue the clear bgp ipv4 unicast * soft out command. You then issue the commands show bgp ipv4 unicast neighbors 2.2.2.2 advertised-routes and show bgp ipv4 unicast neighbors 10.1.13.3 advertised-routesto confirm that routes are now being advertised to R1’s neighbors. The output of Example 18-74 confirms that 10.1.1.0/26 and 10.1.1.64/26 are now being advertised.

Example 18-74 Verifying Routes Advertised to R1’s Neighbors

R1#show bgp ipv4 unicast neighbors 2.2.2.2 advertised-routes
BGP table version is 10, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 ?
*> 10.1.1.0/26 0.0.0.0 0 32768 i
*> 10.1.1.64/26 0.0.0.0 0 32768 i
...output omitted...
R1#show bgp ipv4 unicast neighbors 10.1.13.3 advertised-routes
BGP table version is 10, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 ?
*> 10.1.1.0/26 0.0.0.0 0 32768 i
*> 10.1.1.64/26 0.0.0.0 0 32768 i
...output omitted...

However, you still want to confirm the problem is solved. Can users in 10.1.1.0/26 and 10.1.1.64/26 reach 10.1.5.5? To confirm the problem is solved, you ping 10.1.5.5 from 10.1.1.1 and 10.1.1.65 again. As shown in Example 18-75, it is solved.

Example 18-75 Verifying That the Problem Is Solved

R1#ping 10.1.5.5 source 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.5.5, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/58/68 ms
R1#ping 10.1.5.5 source 10.1.1.65
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.5.5, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.65
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/48/80 ms

Trouble Ticket 18-3

Problem: You are the administrator for BGP autonomous system 65502. Traffic reports indicate that all traffic out of the autonomous system is flowing through R3 and across the backup link. This is undesirable unless the link between R2 and R1 fails.

To verify the issue, you use traceroute from R5. As shown in Example 18-76, the trace to 10.1.1.1 and 10.1.1.65 goes through R3 to get to autonomous system 65501.

Example 18-76 Verifying the Issue

R5#traceroute 10.1.1.1 source 10.1.5.5
Type escape sequence to abort.
Tracing the route to 10.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.45.4 48 msec 40 msec 28 msec
2 10.1.34.3 64 msec 32 msec 60 msec
3 10.1.13.1 [AS 65501] 72 msec 52 msec 48 msec
R5#traceroute 10.1.1.65 source 10.1.5.5
Type escape sequence to abort.
Tracing the route to 10.1.1.65
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.45.4 48 msec 40 msec 28 msec
2 10.1.34.3 64 msec 32 msec 60 msec
3 10.1.13.1 [AS 65501] 72 msec 52 msec 48 msec

On R5, you issue the show ip route 10.1.1.1 command and show ip route 10.1.1.65 command to verify the routes. As shown in Example 18-77, the routes were learned via iBGP and are reachable via 3.3.3.3, which is R3.

Example 18-77 Verifying the Routes on R5

R5#show ip route 10.1.1.1
Routing entry for 10.1.1.0/26
Known via "bgp 65502", distance 200, metric 0
Tag 65501, type internal
Last update from 3.3.3.3 00:01:09 ago
Routing Descriptor Blocks:
* 3.3.3.3, from 3.3.3.3, 00:01:09 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 65501
MPLS label: none
R5#show ip route 10.1.1.65
Routing entry for 10.1.1.64/26
Known via "bgp 65502", distance 200, metric 0
Tag 65501, type internal
Last update from 3.3.3.3 00:02:10 ago
Routing Descriptor Blocks:
* 3.3.3.3, from 3.3.3.3, 00:02:10 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 65501
MPLS label: none

Are the routes being learned from R2? You issue the show bgp ipv4 unicast command to examine the BGP table. According to the BGP table in Example 18-78 10.1.1.0/26 and 10.1.1.64/26 are both learned via R2 as well. So, why is R5 preferring R3 as the best path? You must now examine the BGP path selection process between the next hops 2.2.2.2 and 3.3.3.3.

First of all, can R5 reach 2.2.2.2 and 3.3.3.3? Obviously, 3.3.3.3 is reachable because R5 is using it at the moment. However, using the command show ip route 2.2.2.2, as shown in Example 18-79, confirms that 2.2.2.2 is reachable as well. This is important because a path will never be used if the next hop is not reachable.

Next you examine weight as shown in Example 18-78. It is 0 for both the path via 2.2.2.2 and 3.3.3.3. Therefore, a tie means check the next attribute, which is local preference. In this case, the path via 2.2.2.2 is 50, and the path via 3.3.3.3 is 100. Local preference has a default value of 100, and higher is better. That is why 3.3.3.3 is preferred. It has the higher local preference. It appears the path via 2.2.2.2 had its local preference modified either when it was advertised by R2 or when it was received by R5.

Example 18-78 Examining R5’s BGP Table

R5#show bgp ipv4 unicast
BGP table version is 613, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.1/32 3.3.3.3 0 100 0 65501 ?
* i 2.2.2.2 0 50 0 65501 ?
*>i 10.1.1.0/26 3.3.3.3 0 100 0 65501 i
* i 2.2.2.2 0 50 0 65501 i
*>i 10.1.1.64/26 3.3.3.3 0 100 0 65501 i
* i 2.2.2.2 0 50 0 65501 i
r>i 10.1.5.0/24 3.3.3.3 3328 100 0 i
r i 2.2.2.2 3328 50 0 i
r>i 10.1.12.0/24 3.3.3.3 0 100 0 65501 ?
r i 2.2.2.2 0 50 0 65501 ?
r>i 10.1.13.0/24 3.3.3.3 0 100 0 65501 ?
r i 2.2.2.2 0 50 0 65501 ?

Example 18-79 Confirming That 2.2.2.2 Is Reachable

R5#show ip route 2.2.2.2
Routing entry for 2.2.2.2/32
Known via "eigrp 100", distance 90, metric 131072, type internal
Redistributing via eigrp 100
Last update from 10.1.45.4 on GigabitEthernet1/0, 22:33:44 ago
Routing Descriptor Blocks:
* 10.1.45.4, from 10.1.45.4, 22:33:44 ago, via GigabitEthernet1/0
Route metric is 131072, traffic share count is 1
Total delay is 5020 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2

You examine R5’s BGP configuration with the show run | section router bgp command. As shown in Example 18-80, there is no indication that the local preference is being modified. If there were, we would see a route map applied to the neighbor statement of 2.2.2.2.

Example 18-80 Examining R5’s BGP Configuration

R5#show run | section router bgp
router bgp 65502
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 65502
neighbor 2.2.2.2 update-source Loopback0
neighbor 3.3.3.3 remote-as 65502
neighbor 3.3.3.3 update-source Loopback0

Next you move to R2 and issue the show run | section router bgp command. Immediately you notice a route map called TSHOOT_BGP_FILTER applied in the outbound direction for the peer group called TSHOOT_IBGP_NEIGHBORS, as shown in Example 18-81. You also notice that R5 is part of the peer group. Therefore, the route map applies to R5. You need to dig into the route map now, so you issue the command show route-map TSHOOT_BGP_FILTER. As shown in Example 18-82, the route map is setting the local preference to 50. You examine the network documentation, and it states that the local preference should be 150.

Example 18-81 Examining R2’s BGP Configuration

R2#show run | section router bgp
router bgp 65502
bgp log-neighbor-changes
network 10.1.5.0 mask 255.255.255.0
neighbor TSHOOT_IBGP_NEIGHBORS peer-group
neighbor TSHOOT_IBGP_NEIGHBORS transport connection-mode passive
neighbor TSHOOT_IBGP_NEIGHBORS update-source Loopback0
neighbor TSHOOT_IBGP_NEIGHBORS next-hop-self
neighbor TSHOOT_IBGP_NEIGHBORS route-map TSHOOT_BGP_FILTER out
neighbor 1.1.1.1 remote-as 65501
neighbor 1.1.1.1 password CISCO
neighbor 1.1.1.1 ebgp-multihop 2
neighbor 1.1.1.1 update-source Loopback0
neighbor 3.3.3.3 remote-as 65502
neighbor 3.3.3.3 peer-group TSHOOT_IBGP_NEIGHBORS
neighbor 4.4.4.4 remote-as 65502
neighbor 4.4.4.4 peer-group TSHOOT_IBGP_NEIGHBORS
neighbor 5.5.5.5 remote-as 65502
neighbor 5.5.5.5 peer-group TSHOOT_IBGP_NEIGHBORS

Example 18-82 Examining R2’s Route Map

R2#show route-map TSHOOT_BGP_FILTER
route-map TSHOOT_BGP_FILTER, permit, sequence 10
Match clauses:
Set clauses:
local-preference 50
Policy routing matches: 0 packets, 0 bytes

You modify the route map on R2, as shown in Example 18-83, to solve the issue. You confirm the changes were applied by using the command show route-map TSHOOT_BGP_FILTER. The local preference has been successfully modified to 150. To speed up the BGP changes, you issue the clear bgp ipv4 unicast * soft out command.

Example 18-83 Modifying the Local Preference Value in the Route Map

R2#config t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#route-map TSHOOT_BGP_FILTER 10
R2(config-route-map)#set local-preference 150
R2(config-route-map)#end
%SYS-5-CONFIG_I: Configured from console by console
R2#show route-map TSHOOT_BGP_FILTER
route-map TSHOOT_BGP_FILTER, permit, sequence 10
Match clauses:
Set clauses:
local-preference 150
Policy routing matches: 0 packets, 0 bytes

You go back to R5 and issue a trace and confirm that the path through R2 is now being used, as shown in Example 18-84.

Example 18-84 Confirming That the Issue Is Solved

R5#traceroute 10.1.1.1 source 10.1.5.5
Type escape sequence to abort.
Tracing the route to 10.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.45.4 28 msec 44 msec 8 msec
2 10.1.24.2 40 msec 40 msec 40 msec
3 10.1.12.1 [AS 65501] 64 msec 56 msec 100 msec
R5#traceroute 10.1.1.65 source 10.1.5.5
Type escape sequence to abort.
Tracing the route to 10.1.1.65
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.45.4 28 msec 44 msec 24 msec
2 10.1.24.2 32 msec 56 msec 48 msec
3 10.1.12.1 [AS 65501] 68 msec 36 msec 56 msec

MP-BGP Trouble Tickets

Figure 18-10 MP-BGP Trouble Tickets Topology

Trouble Ticket 18-4

Problem: You are an administrator of BGP autonomous system 65501. You have been asked by another administrator in your autonomous system for help. The default route from your ISP is not being learned by your router (R1) via BGP. As a result of this, no one in your autonomous system is able to reach the Internet.

You start by confirming the issue by using the show ipv6 route command on R1. In Example 18-85, no default route is present. The default route is supposed to be learned from the ISP router via MP-eBGP.

Example 18-85 Verifying the Problem

R1#show ipv6 route
IPv6 Routing Table - default - 5 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP
C 2001:DB8::/64 [0/0]
via GigabitEthernet1/0, directly connected
L 2001:DB8::1/128 [0/0]
via GigabitEthernet1/0, receive
C 2001:DB8:1::/64 [0/0]
via GigabitEthernet0/0, directly connected
L 2001:DB8:1::1/128 [0/0]
via GigabitEthernet0/0, receive
L FF00::/8 [0/0]
via Null0, receive

You issue the command show bgp ipv6 unicast to verify the contents of the IPv6 BGP table, as shown in Example 18-86. There is nothing in the IPv6 BGP table.

Example 18-86 Viewing the IPv6 BGP Table

R1#show bgp ipv6 unicast
R1#

Next you verify whether there are any IPv6 unicast BGP neighbors on R1. The output of show bgp ipv6 unicast summary indicates that there are no neighbors, as shown in Example 18-87.

Example 18-87 Viewing the IPv6 Unicast BGP Neighbors

R1#show bgp ipv6 unicast summary
R1#

You have a feeling that there is an error in the BGP configuration on R1. Therefore, you issue the show run | section router bgp command to verify R1’s BGP configuration. As shown in Example 18-88, the neighbor 2001:DB8::2 remote-as 65502 command is specified. The address is correct, and the remote autonomous system is correct. However, you notice the command no neighbor 2001:DB8::2 activate, which means that the neighbor is not activated in the AF. However, be careful here. This is the IPv4 AF, and we are dealing with IPv6. Therefore, we need to activate the neighbor in the IPv6 AF. Upon closer look, there is no IPv6 AF specified, and as a result, the neighbor 2001:DB8::2 is not activated.

Example 18-88 Viewing the BGP Configuration on R1

R1#show run | section router bgp
router bgp 65501
bgp router-id 1.1.1.1
bgp log-neighbor-changes
neighbor 2001:DB8::2 remote-as 65502
!
address-family ipv4
no neighbor 2001:DB8::2 activate
exit-address-family

To solve this issue, you need to activate the neighbor with the neighbor 2001:DB8::2 activate command in IPv6 AF configuration mode, as shown in Example 18-89. After you activate the neighbor, the adjacency comes up.

Example 18-89 Activating the Neighbor in Address Family Configuration Mode

R1#config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router bgp 65501
R1(config-router)#address-family ipv6 unicast
R1(config-router-af)#neighbor 2001:db8::2 activate
R1(config-router-af)#
%BGP-5-ADJCHANGE: neighbor 2001:DB8::2 Up

You examine the IPv6 BGP table on R1 again with the show bgp ipv6 unicast command and notice that the default route is now listed in Example 18-90. The routing table, as shown in Example 18-91, also shows the default route. Problem solved!

Example 18-90 Verifying That the Default Route Is in the IPv6 BGP Table on R1

R1#show bgp ipv6 unicast
BGP table version is 4, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*> ::/0 2001:DB8::2 0 0 65502 i

Example 18-91 Verifying That the Default Route Is in the IPv6 Routing Table on R1

R1#show ipv6 route
IPv6 Routing Table - default - 6 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP
B ::/0 [20/0]
via FE80::C836:17FF:FEE8:1C, GigabitEthernet1/0
C 2001:DB8::/64 [0/0]
via GigabitEthernet1/0, directly connected
L 2001:DB8::1/128 [0/0]
via GigabitEthernet1/0, receive
C 2001:DB8:1::/64 [0/0]
via GigabitEthernet0/0, directly connected
L 2001:DB8:1::1/128 [0/0]
via GigabitEthernet0/0, receive
L FF00::/8 [0/0]
via Null0, receive

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a couple of choices for exam preparation: the exercises here; Chapter 22, “Final Preparation;” and the exam simulation questions on the CD-ROM.

Review All Key Topics

Review the most important topics in this chapter, noted with the Key Topic icon in the outer margin of the page. Table 18-2 lists a reference of these key topics and the page numbers on which each is found.

Table 18-2 Key Topics for Chapter 18

Define Key Terms

Define the following key terms from this chapter and check your answers in the glossary:

BGP

EGP

eBGP

iBGP

MP-BGP

ISP

address family

TTL

peer group

split-horizon rule (iBGP)

weight

local preference

autonomous system path

MED

Command Reference to Check Your Memory

This section includes the most important show and debug commands covered in this chapter. It might not be necessary to memorize the complete syntax of every command, but you should be able to remember the basic keywords that are needed.

To test your memory of the commands, cover the right side of Table 18-3 with a piece of paper, read the description on the left side, and then see how much of the command you can remember.

Table 18-3 show and debug Commands

The 300-135 TSHOOT exam focuses on practical, hands-on skills that are used by a networking professional. Therefore, you should be able to identify the commands needed to successfully identify and troubleshoot the issues presented in this chapter.

Note

The command show ip bgp will display the same output as show bgp ipv4 unicast. The command show ip bgp summary will display the same output as show bgp ipv4 unicast summary. The command show ip bgp neighbors will display the same output as show bgp ipv4 unicast neighbors.