Interface Is Down

The interface with the IP address that is being used to form BGP neighbor relationships must be up/up. 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, if a local physical interface goes down—the neighbor relationship is still 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 must be up/up, and so must 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 in this book, you can verify the status of an interface by using the show ip interface brief command.

Layer 3 Connectivity Is Broken

You do not have to be directly connected or in the same subnet to form a BGP neighbor relationship; however, you do need 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 points 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 14-2, notice that the State/PfxRcd field says Idle. This state occurs when the local router is not able to make a TCP connection with the neighbor. In this example, the neighbor is the router at 2.2.2.2 with which R5 is trying to form an adjacency. 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 14-3, proves that Layer 3 connectivity does not exist. It is a good idea to specify the source when pinging. The source is the IP address of the local device you plan on making the BGP peering with.

Example 14-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 14-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 the Neighbor Is Through the Default Route

Continuing with the previous discussion on Layer 3 connectivity being broken, Example 14-4 shows that no route to 2.2.2.2 exists; however, a 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 14-5.

Example 14-4 No Route to Neighbor, but 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:
Packet sent with a source address of 5.5.5.5
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 84/91/104 ms

Example 14-5 Verifying That the Default Route Exists in the 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 you can reach the neighbor by using the default route, BGP does not consider it a valid route for forming an adjacency. Look at the output of show bgp ipv4 unicast summary on R5 in Example 14-6 and notice that the state is Idle, which indicates that you cannot form a TCP session.

Example 14-6 Verifying the BGP State on R5 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

Neighbor Does Not Have a Route to the Local Router

You have seen that the local router displays the state Idle when it does not have a route to the IP address it is trying to peer with. However, Idle also appears on a router when the neighbor does not have a route back to the local router. In Example 14-7, you can see that R2, which is trying to form a BGP peering with R5, also displays the state Idle even though it has a route to 5.5.5.5, as shown in Example 14-7. The Idle state appears because the routers cannot form the TCP session.

Example 14-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 14-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 remote-as 65502 matches the local ASN used to create the BGP process (router bgp 65502). The eBGP peering is established because remote-as 65501 is different from the local ASN used to create the BGP process (router bgp 65502).

Example 14-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: the address of the peer with which you form the peering and the autonomous system that the peer is in. If you make a mistake with either of these, you see either the Active or Idle state.

As discussed earlier, if there is no route for the IP address you specify, the state is 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 is Active.

If the ASN specified does not match the peer’s ASN, the state toggles between Idle and Active.

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

Example 14-9 Verifying the 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 the Wrong IP Address

In a redundant topology, a BGP router has multiple active IP addresses configured across its various interfaces. Figure 14-1 shows 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 through R3.

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 has a source IP address, and the source IP address is compared with the address in the local neighbor ip_address remote-as as_number command. If they match, a BGP peering is formed; if not, no BGP peering is formed. By default, 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 address of Gi0/0, but R4’s neighbor 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 14-10 shows the output of show run | section router bgp on R2. Notice that 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 use the IP address of Loopback 0, which is 2.2.2.2, as shown in Example 14-10 as well.

Example 14-10 Verifying the Neighbor Statements and Loopback IP Address on R2

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 be configured appropriately. In this case, R4 needs to have a neighbor remote-as statement using R2’s address 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 14-11 shows the appropriate configuration on R4 to ensure that a BGP peering is successful.

Example 14-11 Verifying That R4’s BGP Configuration Mirrors That of 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. A TCP session is then used to form a BGP peering. If an access control list (ACL) is blocking TCP port 179 anywhere in the path between the routers attempting to form a BGP peering, the peering does not happen. In Example 14-12, R4 (refer to Figure 14-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 related to BGP port 179 are being denied. At the bottom of Example 14-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 14-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 14-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, what if the entry were deny tcp any any eq bgp only 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 server/client relationships. One router is using port 179 (server), and the other router is using an ephemeral port (client). By default, both routers try to establish a TCP session using the three-way handshake because both routers 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 be only one. This situation is called a BGP connection collision, and BGP sorts it out automatically. In a nutshell, the router with the higher BGP RID becomes the server.

If you want to avoid BGP connection collisions, 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 indicate 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.

The output of the command show bgp ipv4 unicast neighbors shows 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 14-13, the command show bgp ipv4 unicast neighbors | i ^BGP neighbor|Local port|Foreign port is used to just display R2’s neighbors along with the local port number and the foreign port number. Notice that 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 179.

Example 14-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

The TTL of the 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 1 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 14-14 shows the output of show bgp ipv4 unicast neighbors | include BGP neighbor|TTL, which indicates 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 14-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 is discarded. As an example, try to form an eBGP peering between R1 and R2 in Figure 14-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 over a default route.

Example 14-15 shows the configuration of R1 and R2. Notice that R1 is peering with R2, using the neighbor address 2.2.2.2 (R2 loopback) and the 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, you can expect the peering to fail.

Example 14-15 Verifying the BGP Configurations 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

The output of show bgp ipv4 unicast summary, as shown in Example 14-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 14-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 by using the neighbor ip_address ebgp-multihop [TTL] command. In this case, 2 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 14-17, the output now states on R2 that neighbor 1.1.1.1 can be up to two hops away, and the peering is established, as shown in the output of show bgp ipv4 unicast summary. A trick to finding the number of hops is to use traceroute (as long as it’s not being blocked by ACLs).

Example 14-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. As is typical with authentication, if any of the parameters do not match, a peering does not form. If you have syslog messaging turned on, a BGP authentication mismatch generates a syslog message like the following from the TCP facility:

Click here to view code image

%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 is Idle, as shown in Example 14-18.

Example 14-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 builds a separate update for each of its neighbors. When a router has a large number of BGP neighbors, this can have a significant impact on the router’s 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 must occur on a per-neighbor basis. In addition to saving CPU cycles, peer groups allow you to type or copy and paste less. Example 14-19 shows a sample peer group configuration.

When troubleshooting peer group issues, you need to look for the following possible culprits:

• You forgot to associate the neighbor ip address with the peer group: After 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 configurations in the peer group. It instead uses the BGP configurations 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 using 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 they produce the desired results for all neighbors in the peer group.

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

Example 14-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 ENARSI_IBGP_NEIGHBORS peer-group
 neighbor ENARSI_IBGP_NEIGHBORS transport connection-mode passive
 neighbor ENARSI_IBGP_NEIGHBORS update-source Loopback0
 neighbor ENARSI_IBGP_NEIGHBORS next-hop-self
 neighbor ENARSI_IBGP_NEIGHBORS route-map ENARSI_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 ENARSI_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 ENARSI_IBGP_NEIGHBORS
 neighbor 5.5.5.5 remote-as 65502
 neighbor 5.5.5.5 peer-group ENARSI_IBGP_NEIGHBORS

Timers

To be clear, BGP timers do not have to match. This is because BGP uses the lowest timers set between the two neighbors. For example, 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 14-20.

Notice in Example 14-20 that R3 is configured with a minimum hold time of 90 seconds; this ensures that if a neighbor is using aggressive timers, those timers will not be used. However, the situation is far worse than the timers simply not being used. The neighbor relationship does not form at all. Refer to Example 14-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, R3 does not agree with the 30-second hold time set by R1, and the neighbor relationship fails. You can see in the output that a BGP notification states that the hold time is not acceptable.

Example 14-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 14-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 do not have to match, but if the minimum hold time is set, the lowest timers must not be less than the minimum; if the lowest timers are less than the minimum, a neighbor relationship does not form.

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 network/prefix you want to advertise with BGP must 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 is not advertised. To practice identifying these requirements, review Example 14-24 and determine whether the 10.1.1.0/26 network is advertised.

Example 14-24 Determining Whether the 10.1.1.0/26 Network Is 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 14-24, the 10.1.1.0/26 network is advertised because there is an exact match of the network mask command in the routing table.

Now review Example 14-25. Does the network mask command successfully advertise the route indicated here?

Example 14-25 Determining Whether the Network Is 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 be 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 be learning, and you trace it all the way back to the source, review the running configuration to see whether there is a network 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 14-26 shows the output of show bgp ipv4 unicast on R5. Focus on network 10.1.1.0/26. Notice that there is no > symbol after the *. The * > symbols indicate a valid best path to reach the network that has been installed in the routing table. In this case, the path is valid but not the best, and as a result, it is not placed in the routing table.

Example 14-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 the path in Example 14-26 is not being used is that the next-hop address is not reachable. In Example 14-27, the ping 1.1.1.1 command fails, proving that the next hop is not reachable.

Example 14-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)

In Figure 14-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 (AS) 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 AS-by-AS 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 AS.

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 are a few examples:

• Create a static default route on R2 and R3 and advertise it into the Interior Gateway Protocol (IGP) routing protocol.

• Create a static default route on R5.

• Create a static route on R5.

• Advertise the next-hop address into the 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 14-28, R2 is configured with the neighbor 5.5.5.5 next-hop-self command, which changes the next hop to 2.2.2.2 when R2 advertises routes to R5. Example 14-29 shows 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 path and is installed in the routing table.

Example 14-28 Modifying the 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 14-29 Verifying the Next-Hop Address in the BGP Table

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 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 from 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 14-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 from an iBGP peering. Because R4 and R5 are iBGP peers, R4 does not advertise the 10.1.1.0/26 network to R5 because of 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. Figure 14-5 indicates what the iBGP peerings should be to ensure that both R4 and R5 learn about 10.1.1.0/26 (as well as the other networks). This setup also ensures that redundancy is optimized in the BGP AS.

Using show bgp ipv4 unicast summary on all the routers to identify peerings and then drawing your peerings on paper can give you an idea of whether the BGP split-horizon rule is causing the missing routes, as long as you remember this: A BGP router that receives a BGP route from 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 (AD) of 20, and routes learned from iBGP peers have an AD of 200. Why the huge difference? BGP is designed to share routes between different ASs. Therefore, if you learn a route from another AS through 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 14-5. R1 advertises 10.1.1.0/26 to R2 using eBGP and to R3 using eBGP. R3, because it has an iBGP peering with R2, advertises it to R2 using iBGP. In addition, let’s say that on R3 you redistribute the 10.1.1.0/26 eBGP-learned route into EIGRP and that R2 learns it from an EIGRP update. Now, R2 knows about the same network from three different sources: eBGP (20), iBGP (200), and EIGRP (170). The eBGP path is chosen because it has the lowest AD. If it were not for eBGP having the lowest AD, you would end up with suboptimal routing as a different source would be used, and traffic would have to go to R3 first before leaving the network instead of going directly from R2 to R1.

Example 14-30 shows the output of the IPv4 unicast BGP table on R5, using the show bgp ipv4 unicast command. In the table, 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 Routing Information Base (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. However, in this case, the route in the routing table is from a better source.

Example 14-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 ?

The output of the command show ip route 10.1.5.0 255.255.255.0, as shown in Example 14-31, indicates that 10.1.5.0/24 is learned from a connected source. 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 from EIGRP. A connected source 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 14-32 indicates that it was learned from R2 and R3 using iBGP (internal), which has an AD of 200—much higher than EIGRP’s AD.

Example 14-31 Verifying the AD of Routes in the 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 14-32 Verifying Details of the 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 by using the show bgp ipv4 unicast rib-failure command, as shown in Example 14-33. In this example, all three RIB failures are due to the BGP route having a higher AD.

Example 14-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, as you saw in Chapter 12, “Advanced BGP” and Chapter 13, “BGP Path Selection.” When troubleshooting missing routes, you want to be able to determine whether a route filter is applied and whether it is the cause of the missing routes. Example 14-34 shows the BGP table on R5 in the output of the show bgp ipv4 unicast command. Notice that there is no entry for 10.1.13.0/24.

Example 14-34 Verifying Missing Routes on R5

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 ?

You can see whether you are receiving the route from R2 or R3 by using the show bgp ipv4 unicast neighbors ip_address routes command, as shown in Example 14-35. The output clearly shows that you are not learning 10.1.13.0/24. But wait, this command displays routes learned after local filters have been applied. Therefore, you should check to see whether R2 or R3 is advertising the 10.1.13.0/24 route before filters are applied. As shown in Example 14-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 14-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 14-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

The show ip protocols command, as shown in Example 14-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 14-37. As also shown in Example 14-37, the prefix list is denying 10.1.13.0/24 and permitting all other routes.

Example 14-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

This example focuses on a filter that applies to the entire BGP process. Therefore, no matter which router you receive the route 10.1.13.0/24 from, it is denied. However, you can apply a filter directly to a neighbor by 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 can verify the route filters with the same show commands as before. Now, however, you look in a different spot in the output. In Example 14-38, 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. If you then review the running configuration, you see that the distribute list is using the ACL named FILTER_10.1.13.0/24. The output of the show ip access-list command confirms that the router is denying the 10.1.13.0/24 network from 2.2.2.2 but allowing all other networks.

Example 14-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 apply a route map, a prefix list, and a filter list directly to the neighbor command. The filter list appears under the FiltIn and FiltOut columns in the output of show ip protocols, and the route map appears under the RouteMap column in the 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 need to review the output of show bgp ipv4 unicast neighbors. However, recall that it is provides extremely verbose output. Therefore, you might want to use this shortcut for troubleshooting route filters:

Click here to view code image

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

Example 14-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 called FILTER_10.1.13.0/24 applied directly to neighbor 3.3.3.3; 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 (that is, distribute list) applied to the neighbor statement that is using the ACL called FILTER_10.1.13.0/24, and there is also an inbound autonomous system path ACL called 25.

Example 14-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

Understanding the Best-Path Decision-Making Process

Cisco routers review BGP attributes in the following order when deciding which path is the best:

1. Prefer the highest weight

2. Prefer the highest local preference

3. Prefer the route originated by the local router

4. Prefer the path with the shorter Accumulated Interior Gateway Protocol (AIGP) metric attribute

5. Prefer the shortest AS_Path

6. Prefer the lowest origin code

7. Prefer the lowest multi-exit discriminator (MED)

8. Prefer an external path over an internal path

9. Prefer the path through the closest IGP neighbor

10. Prefer the oldest route for eBGP paths

11. Prefer the path with the lowest neighbor BGP RID

12. Prefer the path with the lowest neighbor IP address

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

Example 14-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

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

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

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

Step 3. The router checks whether it generated the BGP route (that is, has a next hop of 0.0.0.0). If it did, it is preferred. In Example 14-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.

Step 4. AIGP is checked next only if it’s configured to be used. In this case, it is not configured as there is no AIGP metric listed in the output of Example 14-40. Therefore, the next attribute is checked.

Step 5. AS_Path is checked next. The shortest path is preferred. In Example 14-40, AS_Path is 65501 for both routes. Therefore, the AS_Path is tied, and the next attribute is checked.

Step 6. 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 14-40, the origin is IGP for both routes, which means the next attribute is checked.

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

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

Step 9. The IGP path to the neighbor is compared now. In Example 14-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.

Step 10. If they are eBGP paths, the ages of the routes are checked. In Example 14-40, both paths are iBGP paths. Therefore, you skip this attribute and move on to the next attribute.

Step 11. The BGP RIDs are now compared. Lower is better. In Example 14-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, and the path through the neighbor with the lowest neighbor IP address wins.

Now it is your turn! Try the following on your own, and then let’s walk through it. Based on Figure 14-7 and Example 14-41, determine which attribute R2 is using to choose the best path to reach 10.1.1.128.

Example 14-41 Practicing the BGP Best-Path Decision-Making 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

Here’s an examination of the process in this example:

1. The weight is tied, so continue evaluating.

2. The local preference is tied, so continue evaluating.

3. No route was originated by the local router, so continue evaluating.

4. The AIGP metric is not being used, so continue evaluating.

5. AS_Path is the same at 65501, so continue evaluating.

6. The origin code is the same, so continue evaluating.

7. The MED metric is tied at 0, so continue evaluating.

8. 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 if you are not getting 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 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 ASNs also have a private range. The 2-byte AS range is 64,512 to 65,534, and the 4-byte AS range is 4,200,000,000 to 4,294,967,294. These ASNs can be used for networks that are single-homed or dual-homed to the same ISP, thereby preserving the public ASNs for networks that are multihomed to multiple ISPs.

Although the private ASNs can be used in a customer’s network, it is imperative that the ASN not be in the AS_Path attribute when the routes are advertised to the Internet (in the global BGP table) because multiple ASs could be using the same private ASN, which would cause issues on the Internet.

If private ASNs are being sent into the global BGP table, they need to be stopped. You can accomplish this by using the neighbor ip_address remove-private-as command.

Using debug Commands

The majority of changes that occur with BGP generate syslog messages in real time. Therefore, you are notified through syslog if any neighbor issues occur. So, unless you really need to, you should avoid using the large number of debugs that are available because they place a lot of pressure on the routers’ resources. Only use as a last resort! This section presents a few debug commands that might be useful. However, you can use all the show commands covered so far and your knowledge to determine the same thing.

Example 14-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 IP address 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. You can use the debug ip routing command with routing processes other than BGP.

Example 14-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 14-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 IP address 172.16.1.1.

Example 14-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 14-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 14-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...

Trouble Ticket 14-1

Problem: You are the administrator for BGP AS 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 AS 65501. However, that did not occur while you were away. Your co-worker had to restore connectivity between R1 and R2, and 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. As Example 14-53 shows, 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 doing so would disrupt the network users. Therefore, you need to be creative with your troubleshooting efforts.

Example 14-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 AS 65501, those networks have to be advertised to R5. 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. Example 14-54 shows the output of show bgp ipv4 unicast. As you can see from the Next Hop column, all valid routes to the 10.1.1.x/26 networks are through the next hop 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 14-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 commands 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 against what is being advertised from R3. The output in Example 14-55 clearly shows that R5 is not receiving any routes about the 10.1.1.x/26 networks from R3. This is the reason network connectivity was lost when the link between R1 and R2 went down: R5 does not have any route information from R3.

Example 14-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 command show bgp ipv4 unicast neighbors 5.5.5.5 advertised-routes to determine which routes, if any, R3 is sending to R5. In Example 14-56, you can see that no routes related to the 10.1.1.x/26 networks are being advertised to R5. So does R3 even know about the networks?

Example 14-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 14-57, and confirm that the networks are learned from 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 through 2.2.2.2, which is R2. The AD should be 20 for eBGP, and the next hop should be R1’s IP address in this case.

Example 14-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. Based on the output, as shown in Example 14-58, only R2 and R4 are next hops for routes. R1 is not a next hop for any of them.

Example 14-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 ?

The output of 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 14-59.

Example 14-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 AS, you cannot access it for troubleshooting purposes. Therefore, you need to call the admin in AS 65501. However, you should not do that just yet. You 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 14-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 14-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 14-60 to your network documentation (refer to Figure 14-9), you notice that the ASN is incorrect for 10.1.13.1. It is listed as 65510, but 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 14-61. After the changes are made, the neighbor relationship is up.

Example 14-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 14-62. Issue solved. Afterhours, you will bring down the link between R1 and R2 and confirm that traffic successfully flows between R3 and R1.

Example 14-62 Confirming That 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
 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 old log files from R3. You notice the following BGP message listed many times:

Click here to view code image

%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 AS. Never forget to check your log files as part of troubleshooting. It can save you valuable time.

Trouble Ticket 14-2

Problem: You are the administrator for BGP AS 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 14-63, the pings fail.

Example 14-63 Verifying the Issue with Pings

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 14-64, that there is a route to 10.1.5.5 through R2 that is learned from BGP.

Example 14-64 Confirming That 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 in an attempt to gather some additional information. In Example 14-65, you can see that the trace is failing at the next-hop router (R2).

Example 14-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 from 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 14-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 14-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 14-67, you confirm that both R2 and R3 are BGP neighbors because there is a number in the PfxRcd column.

Example 14-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 14-68, no routes are being advertised to the neighbors.

Example 14-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 AS. As shown in Example 14-69, no filter is applied.

Example 14-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 ENARSI studies (earlier in this chapter) 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 14-70, you can see the same prefix list called BGP_FILTER applied twice in the outbound direction.

Example 14-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 14-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 14-71 Verifying the 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 14-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 AS 65502, which this prefix list accomplishes.

Example 14-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 to R1, as shown in Example 14-73, you can 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 14-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-routes to confirm that routes are now being advertised to R1’s neighbors. The output shown in Example 14-74 confirms that 10.1.1.0/26 and 10.1.1.64/26 are now being advertised.

Example 14-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 that 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 that 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 14-75, the problem is solved.

Example 14-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 14-3

Problem: You are the administrator for BGP AS 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 14-76, the trace to 10.1.1.1 and 10.1.1.65 goes through R3 to get to AS 65501.

Example 14-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 the show ip route 10.1.1.65 command to verify the routes. As shown in Example 14-77, the routes are learned via iBGP and are reachable through 3.3.3.3, which is R3.

Example 14-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 14-78, 10.1.1.0/26 and 10.1.1.64/26 are both learned from 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, the output of the command show ip route 2.2.2.2, as shown in Example 14-79, confirms that 2.2.2.2 is reachable as well. This is important because a path can never be used if the next hop is not reachable.

Next, you examine weight, as shown in Example 14-78. It is 0 for both the path using 2.2.2.2 and the path using 3.3.3.3. A tie means you need to check the next attribute, which is local preference. In this case, the path using 2.2.2.2 is 50, and the path using 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 that the path using 2.2.2.2 had its local preference modified either when it was advertised by R2 or when it was received by R5.

Example 14-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 14-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 14-80, there is no indication that the local preference is being modified. If there were, you would see a route map applied to the neighbor statement of 2.2.2.2.

Example 14-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 ENARSI_BGP_FILTER applied in the outbound direction for the peer group called ENARSI_IBGP_NEIGHBORS, as shown in Example 14-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 ENARSI_BGP_FILTER. As shown in Example 14-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 14-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 ENARSI_IBGP_NEIGHBORS peer-group
 neighbor ENARSI_IBGP_NEIGHBORS transport connection-mode passive
 neighbor ENARSI_IBGP_NEIGHBORS update-source Loopback0
 neighbor ENARSI_IBGP_NEIGHBORS next-hop-self
 neighbor ENARSI_IBGP_NEIGHBORS route-map ENARSI_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 ENARSI_IBGP_NEIGHBORS
 neighbor 4.4.4.4 remote-as 65502
 neighbor 4.4.4.4 peer-group ENARSI_IBGP_NEIGHBORS
 neighbor 5.5.5.5 remote-as 65502
 neighbor 5.5.5.5 peer-group ENARSI_IBGP_NEIGHBORS

Example 14-82 Examining R2’s Route Map

R2# show route-map ENARSI_BGP_FILTER
route-map ENARSI_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 14-83, to solve the issue. You confirm that the changes were applied by using the command show route-map ENARSI_BGP_FILTER. The local preference has been successfully modified to 150. To speed up the BGP changes, you issue the command clear bgp ipv4 unicast * soft out.

Example 14-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 ENARSI_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 ENARSI_BGP_FILTER
route-map ENARSI_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 14-84.

Example 14-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

Trouble Ticket 14-4

Problem: You are an administrator of BGP AS 65501. Another administrator in your AS has asked you for help. The default route from your ISP is not being learned by your router (R1) using BGP. As a result, no one in your AS is able to reach the Internet.

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

Example 14-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 the following snippet:

Click here to view code image

R1# show bgp ipv6 unicast
R1#

There is nothing in the IPv6 BGP table.

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 the following snippet:

Click here to view code image

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 14-86, the neighbor 2001:DB8::2 remote-as 65502 command is specified. The address is correct, and the remote AS 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 you are dealing with IPv6. Therefore, you need to activate the neighbor in the IPv6 AF. If you look closely, you see that there is no IPv6 AF specified, and as a result, the neighbor 2001:DB8::2 is not activated.

Example 14-86 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 14-87. After you activate the neighbor, the adjacency comes up.

Example 14-87 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 by using the show bgp ipv6 unicast command and notice that the default route is now listed, as shown in Example 14-88. The routing table, as shown in Example 14-89, also indicates the default route. Problem solved!

Example 14-88 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 14-89 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 choices for exam preparation: the exercises here, Chapter 24, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep software. The questions that follow present a bigger challenge than the exam itself because they use an open-ended question format. By using this more difficult format, you can exercise your memory better and prove your conceptual and factual knowledge of this chapter. You can find the answers to these questions in the appendix.