Troubleshooting BGP
Enterprise networks might use the Border Gateway Protocol (BGP) to exchange routing information in a controlled fashion with external parties such as Internet service providers or other providers of IP-based services. BGP can also be used to exchange routing information between different regions (within the enterprise network) that are managed and administered by different organizational groups. BGP offers a toolkit to implement routing policies and control the flow of traffic to and from external parties such as service providers, or between the different regions of the network. BGP is an inter-autonomous (inter-AS) or exterior gateway protocol (EGP) ofter used in combination with an intra-autonomous system (intra-AS) or interior gateway protocol (IGP) such as EIGRP, IS-IS, or the OSPF routing protocol. Understanding the mechanics of BGP and its interaction with IGPs is essential for troubleshooting complex networks that deploy BGP. A network support engineer must know the data structures used by BGP and the flow of routing information between routers running the BGP protocol. Network support engineers must also be familiar with the processing of routing information inside the router. Finally, a support staff must know the Cisco IOS commands to gather information from the BGP data structures and routing processes to perform structured troubleshooting.
BGP Route Processing and Data Structures
BGP is classified as an EGP or an inter-autonomous-system routing protocol. BGP fulfills a different role in enterprise networks when compared to IGPs, such as EIGRP or the OSPF routing protocols. BGP is not used to find the best paths within the enterprise network based on metrics such as bandwidth, delay, or path cost, but it is used to exchange routing information with external networks (other autonomous systems), such as Internet service providers, and to implement routing policies to control the flow of traffic to and from those external networks. Although its purpose is different from IGPs, BGP is still a routing protocol in the sense that it exchanges information about reachability of prefixes with other BGP routers, selects the best path for each of the prefixes that it has learned about, and offers the best paths to the routing table.
Similar to other routing protocols, the following elements must be discerned about BGP:
-
Reception of routing information from neighbors: One of the major differences between BGP and IGPs is that for BGP, its neighbors need not be directly connected. Neighbors are manually configured, not automatically discovered through a hello protocol. A TCP session is established between the predefined neighbors to exchange routing information, and this TCP session can span multiple router hops if necessary. Because the term neighbor inherently implies a sense of close proximity, an alternative commonly used term for two BGP routers that exchange information is peer. The terms peer and neighbor are used interchangeably within the BGP context. Cisco IOS command outputs use the term neighbor.
-
Routing protocol data structures: BGP has two main data structures. The first one is a neighbor table to keep track of the state of configured neighbors. The second is BGP’s main data structure, the BGP table, which BGP uses to store all the prefixes, including those received from the neighbors.
-
Route injection or redistribution: BGP does not automatically inject any routes into the BGP table. Routes learned from neighbors are placed in the BGP table and can be advertised out to other BGP neighbors. Routes learned from internal (IBGP) neighbors are subject to the synchronization rule, unless synchronization is off. There are two methods to inject prefixes into the BGP table and advertise them to BGP neighbors:
-
The prefixes must be specifically configured under the BGP routing process (using the network statement).
-
The prefixes must be redistributed into BGP (from connected, static, or another interior routing protocol).
In both cases, a prefix needs to be present in the IP routing table before it can be advertised to BGP neighbors. Because conditional route injection is beyond the scope of this book, it is not discussed here.
-
Route selection and installation: BGP has a complex decision algorithm to compare paths received from different neighbors and select the best one for each prefix. Similar to other routing protocols, BGP offers the paths that it selects as best to the IP routing table. On Cisco routers, BGP routes have an administrative distance of 200, unless they are learned from external BGP neighbors (those with different autonomous system numbers); in which case, the administrative distance is 20.
-
Transmission of routing information to neighbors: Paths that are selected as best in the BGP table can be advertised to other BGP routers. Several rules, such as the one commonly referred to as IBGP split-horizon rule, govern the advertisement of BGP routes to neighbors. Also, access lists, prefix lists, and route maps may be applied to filter and manipulate the prefixes and their attributes before exchanging them with a neighbor. This type of filtering and manipulation can be performed either before transmitting the information to a neighbor or when receiving information from a neighbor.
BGP uses two main data structures to store its operational data, configured parameters, and statistics:
-
Neighbor table: This table lists all neighbors that have been configured on a router. This table stores valuable information such as the configured autonomous system number of the neighbor, whether the neighbor is an internal or an external peer, the state of the session, how long the neighbor has been up/down for (uptime), and how many prefixes were exchanged with the neighbor.
-
BGP table: This table, sometimes called the BGP Routing Information Base (RIB), stores all the locally injected routes, plus all routes that were received from all the router’s peers, together with all the BGP attributes that are associated with each route, such as the next hop, autonomous system path, local preference, origin, multi-exit discriminator (MED) or metric, origin code, and community attributes. For each prefix, the BGP best path selection algorithm assesses the usability of the available paths and, if one or more usable paths exist, selects one of the paths as the best path. The best path is subsequently advertised to other BGP peers, and BGP attempts to install this route in the routing table (offers it to the IP routing table). One of the tests that the BGP best path selection algorithm performs is validating the reachability of the next-hop attribute of a path. If the next-hop IP address is reachable as per the IP routing table’s content, the path may be considered as a best path candidate. If no match can be found in the routing table for the next-hop address, the path is not considered usable, and it will not be considered as a best path candidate. By default, BGP will select only one best path for each prefix. The BGP Multipath feature allows additional paths to be installed in the IP routing table.
BGP Routing Information Flow
Unlike interior routing protocols, BGP neighbors are explicitly configured, not automatically discovered based on a hello protocol. A BGP neighbor is configured manually by specifying its IP address and autonomous system number within BGP router configuration. A BGP router attempts to establish a TCP session to the neighbor IP address on TCP port 179. Alternatively, it will accept incoming TCP sessions to port 179, as long as the source IP address matches one of its configured neighbor IP addresses. After a TCP session has been successfully established with the neighbor, the two routers send BGP OPEN messages to exchange basic parameters and capabilities, such as autonomous system number, router ID, hold time, and supported address families. During this phase, each router compares the neighbor’s claimed autonomous system number to the autonomous system number its administrator has entered for the neighbor. If these numbers do not match, the session is reset, and the relation is not established.
As a result of this process, the following issues are common causes for failure of BGP peering establishment:
-
There is no IP connectivity between the local BGP router and the configured peer’s IP addresses. Because BGP peers are not necessarily directly connected, both routers need to have an IP path to the configured neighbor IP address in their routing table.
-
The source IP address used by the router that initiates the session does not match the configured neighbor IP address on the receiving router.
-
The autonomous system number of a BGP router (specified in its HELLO or OPEN message) does not match the autonomous system number its neighbor has configured for it (and expects from it).
After the TCP session has been established and OPEN messages have been successfully exchange and accepted, BGP starts exchanging update messages over the established TCP session. BGP uses an incremental update process. When a BGP peer relationship is first established, each of the peers advertises its best route for each prefix to its peer. Both peers subsequently install the received routes in the BGP table and execute the BGP best path selection algorithm to select the best path for each prefix based on the newly received information. Each time a new best path for a prefix is selected in the BGP table, an update for that prefix is sent to all relevant peers. When a prefix is removed from the BGP table, a WITHDRAW message for the prefix is sent to all relevant peers. To determine which peers need to be updated, the router applies rules such as the IBGP split-horizon rule or any administratively configured filters. BGP updates are commonly filtered or manipulated by use of access lists, prefix lists, or route maps. These tools can either be applied at the time updates are received, before the prefixes are installed in the BGP table, or at the time updates are transmitted to a peer.
Cisco IOS BGP Commands
The following commands enable you to gather information from the BGP data structures:
-
show ip bgp summary: This command displays essential BGP parameters, such as the router ID and autonomous system number of the router, statistics on the memory usage of the BGP process, and a brief overview of the configured neighbors and the state of the relationship with each of the configured neighbors. This command is often used to quickly check the status of the relationship with one or more neighbors or how long the relation has been down/up.
-
show ip bgp neighbors: This command lists all configured neighbors and their current operational state, configured parameters, and extensive statistics for each neighbor. The output of this command can be limited to a specific neighbor by using the show ip bgp neighbors ip-address command. This command provides more detail about the neighbor than the show ip bgp summary command.
-
show ip bgp: This command displays the content of the BGP table. To select a specific entry from the table, the network and mask of the selected prefix can be provided as an option to the command. This command is useful during troubleshooting to see which paths are present, what their attributes are, and why certain paths are selected as best. Note that this command does not reveal all the attributes of the BGP paths. To see all the attributes, you must display one BGP prefix at a time using the show ip bgp prefix command.
The following debugs can be used to observe the transmission and reception of BGP packets and the exchange of routing information:
-
debug ip bgp: This debug displays significant BGP-related events, most notably the subsequent phases of establishing a BGP peering relationship. This command does not display the content of the BGP updates and is a relatively safe to use. This command is useful during fact gathering.
-
debug ip bgp updates: This debug displays the transmission and reception of BGP updates. The output of this debug can be limited to a specific neighbor and specific prefixes by use of extra options. Issuing the command debug ip bgp ip-address updates access-list limits the output of the command to only updates received from or sent to the neighbor specified by the ip-address option and only for those networks that match the access list specified by the access-list option. If no restrictions are imposed by use of the access-list or neighbor options, this command can generate a large amount of output and affect the router’s performance. During troubleshooting, this proves useful because you can see which router is or is not sending which updates.
Troubleshooting Example: Routing Problem in a BGP Network
The purpose of this troubleshooting example is to illustrate how you can leverage knowledge of BGP data structures, update processes, and Cisco IOS commands for BGP troubleshooting. The enterprise network shown in Figure 5-7 uses BGP to exchange routing information with two different Internet service providers (ISPs). When a traceroute command is executed on router IRO1 to determine the path that is used to reach IP address 192.168.224.1, which belongs to an IP address block that is owned by ISP1, it turns out that the traffic path goes through router IRO2, as shown in Example 5-24.
Example 5-24: traceroute Results Show Packets Going Through IRO1 Toward ISP1
IRO1# trace 192.168.224.1
Type escape sequence to abort.
Tracing the route to 192.168.224.1
1 10.1.192.20 4 msec 0 msec 0 msec
2 172.24.244.86 [AS 64566] 4 msec 0 msec 4 msec
3 192.168.100.1 [AS 65486] 0 msec 4 msec 0 msec
4 192.168.224.1 [AS 65525] 0 msec * 0 msec
This behavior is worth investigating because it is expected that traffic destined for a network that is advertised by Internet service provider 1 would go directly to ISP1 and not through Internet service provider 2. To verify whether this problem is caused by an underlying Layer 1, Layer 2, or Layer 3 problem, a ping command is executed to test the Layer 3 connectivity to the access router of ISP1, as demonstrated in Example 5-25.
Example 5-25: ping Command Results Show That the Link to ISP1 Access Router Is Up
IRO1# ping 192.168.224.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.224.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
The successful ping to ISP1’s access router verifies that the link between router IRO1 and ISP1 access router is operational at Layers 3 and below. Given that the link to ISP1 is functional, but is not used to route the packets to ISP1, this is a routing problem. Because BGP is used for external routing, investigation of the BGP operation is in order. There are various different methods to troubleshoot this problem. The objective is to find out why the direct path to Internet service provider 1 is not being used to route traffic to IP address 192.168.224.1. There are two likely reasons why the traffic is routed through router IRO2 instead of directly to Internet service provider 1:
-
Router IRO1 has not learned about the prefix directly from ISP1 at all.
-
Router IRO1 router has learned about the route, but it incorrectly prefers the path through router IRO2.
To start the investigation, a good first step is to confirm that the path used to route the traffic to 192.168.224.1 is indeed the BGP route learned from router IRO2 and not a route obtained from some other source. The output of Example 5-26 shows that the route to network 192.168.224.0/19 is the best match for destination IP address 192.168.224.1 and that this route is an internal BGP path and its source is the router with IP address 10.1.220.4, which is IRO2.
Example 5-26: Within IP Routing Table, What Protocol Is the Source of the Path to 192.168.224.0/19?
IRO1# show ip route 192.168.224.1
Routing entry for 192.168.224.0/19, supernet
Known via "bgp 64568", distance 200, metric 0
Tag 64566, type internal
Redistributing via eigrp 1
Last update from 172.24.244.86 00:24:22 ago
Routing Descriptor Blocks:
* 172.24.244.86, from 10.1.220.4, 00:24:22 ago
Route metric is 0, traffic share count is 1
AS Hops 2
Route tag 64566
After verifying the routing table, it is clear that prefix 192.168.224.0/19 was learned through BGP and installed in the IP routing table. However, the IP routing table does not show whether the path through IRO2 is used because no other path is available or simply because the path through IRO2 was selected as the best path. This information can be obtained from the BGP table. The output of Example 5-27 shows that only the path through router IRO2 is present in the BGP table and no other BGP-learned paths are available.
Example 5-27: BGP Table Shows Only One Path to 192.168.224.0/19
IRO1# show ip bgp 192.168.224.1
BGP routing table entry for 192.168.224.0/19, version 12
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
64566 65525
172.24.244.86 (metric 30720) from 10.1.220.4 (10.1.220.4)
Origin IGP, metric 0, localpref 100, valid, internal, best
The fact that the path through Internet service provider 1 is not present in the BGP table can have several different causes. ISP1 might not advertise the route, or ISP1 advertises it, but router IRO1 rejects or ignores the advertisement, or possibly router IRO1 and ISP1 have not successfully established a peering relationship and no routes have been exchanged at all. At this point, a good next step is to start with the third option and investigate whether a neighbor relationship has been established between routers IRO1 and the ISP1 router. Example 5-28 displays the output of the show ip bgp summary command executed on IRO1 router.
Example 5-28: BGP Neighbor 192.168.224.244 (ISP1 Access Router) Is in Active State
IRO1# show ip bgp summary
BGP router identifier 10.1.220.3, local AS number 64568
BGP table version is 14, main routing table version 14
6 network entries using 702 bytes of memory
7 path entries using 364 bytes of memory
6/4 BGP path/bestpath attribute entries using 744 bytes of memory
3 BGP AS-PATH entries using 72 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 1882 total bytes of memory
BGP activity 6/0 prefixes, 13/6 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.220.4 4 64568 82 80 14 0 0 01:12:02 6
192.168.224.244 4 65525 0 0 0 0 0 never Active
The output shown on Example 5-28 reveals that the peering to IP address 10.1.220.4 (IRO2) has been established and six prefixes have been received from the neighbor, while the peering to IP address 192.168.224.244 is in the Active state. This means that this router is trying to establish a TCP session to neighbor 192.168.224.244, but has not succeeded yet. Executing a ping command to IP address 192.168.224.244 yields the result shown in Example 5-29.
Example 5-29: ping Command to the Configured Neighbor’s Address Fails
IRO1# ping 192.168.224.244
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.224.244, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
The earlier ping to the directly connected interface of ISP1 (192.168.224.254) was successful, yet the ping to the IP address 192.168.224.244, which is the configured neighbor address for ISP1, fails. This might lead to the conjecture that IP address 192.168.224.244 is not the correct IP address and IP address 192.168.224.254 should have been used for the peering to ISP1 instead. After the IP address in the neighbor statement is changed to IP address 192.168.224.254 to test the hypothesis that the misconfigured IP address was the cause of the problem, the results must be examined. Strictly speaking, the only test that you need to perform to confirm you have solved the problem is to execute the traceroute command again to confirm that packets traveling to IP address 192.168.224.1 are now sent directly to ISP1, instead of taking the longer path through router IRO2 and ISP2. However, to show the impact of the change on all the BGP data structures, the changes in the output of the show commands that were used earlier to diagnose the problem are displayed in Example 5-30.
Example 5-30: After the Correction Was Made, the Neighbor State for 192.168.224.254 Is Established, and a Path to 192.168.224.0/19 Is Received from This Neighbor
IR01(config)# router bgp 64568
IR01(config-router)# no neighbor 192.168.224.244
IR01(config-router)# neighbor 192.168.224.254 remote-as 65525
IR01(config-router)# end
IRO1# show ip bgp summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.220.4 4 64568 146 146 19 0 0 02:15:17 5
192.168.224.254 4 65525 14 12 19 0 0 00:03:23 5
IRO1# show ip bgp 192.168.224.0
BGP routing table entry for 192.168.224.0/19, version 17
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
2
65525
192.168.224.254 from 192.168.224.254 (192.168.100.1)
Origin IGP, metric 0, localpref 100, valid, external, best
As the output in Example 5-30 shows, the peering to ISP1 router has now been successfully established, and five prefixes were received from neighbor 192.168.224.254. Verification of the BGP table on router IRO1 shows that the path to prefix 192.168.224.0/19 via neighbor 192.168.224.254 to autonomous system 65525 has now been selected as the best path. It is interesting to note that the path to 192.168.224.0/19 through router IRO2 is no longer displayed in IRO1’s BGP table. You might expect to see that path displayed as an alternative path to reach prefix 192.168.224.0/19, but it is not present in IRO’s BGP table at all.
To answer this question, you need to examine the BGP table on router IRO2, as shown in Example 5-31.
Example 5-31: IRO2’s BGP Table Shows Two Paths to 192.168.224.0/19
IRO2# show ip bgp 192.168.224.0
BGP routing table entry for 192.168.224.0/19, version 24
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
1
65525
192.168.224.254 (metric 30720) from 10.1.220.3 (10.1.220.3)
Origin IGP, metric 0, localpref 100, valid, internal, best
64566 65525
172.24.244.86 from 172.24.244.86 (172.24.240.1)
Origin IGP, localpref 100, valid, external
Example 5-31 shows that router IRO2 has received a path to 192.168.224.0/19 from router IRO1 and installed it in its BGP table. After executing the BGP best path selection algorithm for prefix 192.168.224.0/19, IRO2 selects the path through (learned from) IRO1 as the best path to prefix 192.168.22.0/19 in autonomous system 65525. The less-attractive alternative is through ISP2 with two items in the AS-Path. Because BGP on IRO2 has changed its best path to this prefix, it now withdraws the old path that it has previously advertised, and subsequently it advertises the new best path to prefix 192.168.224.0/19 to all relevant neighbors. After IRO2 withdraws its old path from its neighbors, IRO1 remains with a single path to 192.168.224.0/19, which is through ISP1. You can see this in the output shown in Example 5-32. You should also notice that IRO1 is now showing five prefixes received from IRO2 as shown in Example 5-30 instead of six as shown in Example 5-28.
Example 5-32: IRO1’s BGP Table Has One Path to 192.168.224.0/19, Through ISP1
IRO1# show ip route 192.168.224.1
Routing entry for 192.168.224.0/19, supernet
Known via "bgp 64568", distance 20, metric 0
Tag 65525, type external
Redistributing via eigrp 1
Last update from 192.168.224.254 00:49:55 ago
Routing Descriptor Blocks:
* 192.168.224.254, from 192.168.224.254, 00:49:55 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 65525
IRO1# traceroute 192.168.224.1
Type escape sequence to abort.
Tracing the route to 192.168.224.1
1 192.168.224.254 [AS 65525] 0 msec 0 msec 4 msec
2 192.168.224.1 [AS 65525] 0 msec 0 msec *
The output shown in Example 5-32 confirms that the path through neighbor 192.168.224.254 (ISP1) has been installed in the routing table, and the result of the traceroute command, also shown in Example 5-32, confirms that this path is now used to route packets to IP address 192.168.224.1. This troubleshooting example illustrates the use of the Cisco IOS show commands to display the content of the BGP data structures. It also illustrates how you can leverage knowledge of these data structures and the flow of BGP routing information to diagnose and resolve BGP routing problems.
| Note | At Cisco.com, you can find an extremely helpful flowchart for troubleshooting BGP issues. Assuming you have a Cisco.com login, you can find this information at http://www.cisco.com/en/US/customer/tech/tk365/technologies_tech_note09186a008009478a.shtml. |
Summary
There are several variations of the show ip route command, with different options. These variations reveal different amounts of information. During troubleshooting, you might find one or more of these options more useful than the generic command:
-
show ip route ip-address: Causes the router to perform a routing table lookup for that IP address and display the best route that matches the address and all associated control plane details.
-
show ip route network mask: Searches the routing table for an exact match for that network and mask, and if it is found, this entry is displayed with all of its associated control plane details.
-
show ip route network mask longer-prefixes: Using the longer-prefixes option will cause the router to display all prefixes in the routing table that fall within the prefix specified by the network and mask parameters. This command can be very useful to diagnose problems related to route summarization.
There are several variations of the show ip cef command, with different options. These variations reveal different amounts of information. During troubleshooting, you might find one or more of these options more useful than the generic command:
-
show ip cef ip-address: Searches the FIB for the prefix and displays no routing protocol related information, but only the information that is necessary to forward packets
-
show ip cef network mask: Searches the FIB table for an exact match for that network and mask, and if it is found, displays the entry
-
show ip cef exact-route source destination: Displays the exact adjacency that will be used to forward a packet with source and destination IP addresses as specified by the source and destination parameters
Two examples of commands that can be used to verify the Layer 3 to Layer 2 mappings are as follows:
-
show ip arp: Verifies the dynamic IP address to Ethernet MAC address mappings that were resolved by the Address Resolution Protocol.
-
show frame-relay map: Lists all the mappings of next-hop IP addresses on multipoint (sub-) interfaces to the DLCI of the corresponding PVC. It also lists any DLCIs that were manually associated to specific point-to-point subinterfaces.
Virtually all routing protocols include the following elements and processes:
-
Reception of routing information from neighbors
-
Routing protocol data structures
-
Route injection or redistribution
-
Route selection and installation
-
Transmission of routing information to neighbors
EIGRP stores its operational data, configured parameters, and statistics in three main data structures:
-
Interface table
-
Neighbor table
-
Topology table
You can use the following commands to gather information from the EIGRP data structures:
-
show ip eigrp interfaces: Displays the list of interfaces that have been activated for EIGRP
-
show ip eigrp neighbors: Lists all neighbors that have been discovered by the local router
-
show ip eigrp topology: Displays the content of the EIGRP topology table
The following debug commands enable you to observe the transmission and reception of packets and the exchange of EIGRP routing information:
-
debug ip routing
(This is a generic IP debugging command that displays any changes that are made to the routing table, such as installation or removal of routes. This can be useful to diagnose routing protocol instabilities)
-
debug eigrp packets
-
debug ip eigrp
-
debug ip eigrp neighbor as-number ip-address
-
debug ip eigrp as-number network mask
OSPF stores its operational data, configured parameters, and statistics in four main data structures:
-
Interface table: This table lists all interfaces that have been enabled for OSPF.
-
Neighbor table: This table is used to keep track of all active OSPF neighbors.
-
Link-state database: This is the main data structure that OSPF uses to store all its network topology information. This database contains full topology information for the areas that a router connects to, and information about the paths that are available to reach networks and subnets in other areas or other autonomous systems.
-
Routing Information Base: After executing the SPF algorithm, the results of this calculation are stored in the RIB. This information includes the best routes to each individual prefix in the OSPF network and their associated path costs.
Two routers will become neighbors only if the following parameters match in the Hello packets:
Once two OSPF routers are enabled to operated on a network, their neighbor relationship state goes through the following states: init, 2-way, exstart, exchange, loading, and full. Attempt state is only encountered when unicast Hellos are used and a neighbor has been explicitly configured. When the router has sent a Hello to the configured neighbor, but not received any Hello from the neighbor yet, the neighbor relationship is in the attempt state. This state is not used on point-to-point or broadcast type networks, which use multicast Hellos instead of unicast Hellos.
The following commands can be used to gather information from the OSPF data structures:
-
show ip ospf interface: Displays the interfaces that have been activated for OSPF.
-
show ip ospf neighbor: Lists all neighbors that have been discovered by this router on its active OSPF interfaces and shows their current state.
-
show ip ospf database: Displays the content of the OSPF link-state database.
-
show ip ospf statistics: Shows how often and when the SPF algorithm was last executed. This command can be helpful when diagnosing routing instability.
The following debug commands enable you to observe the transmission and reception of packets and the exchange of routing information:
-
debug ip routing: Displays any changes that are made to the routing table
-
debug ip ospf packet: Displays the transmission and reception of OSPF packets
-
debug ip ospf events: Displays OSPF events
-
debug ip ospf adj: Displays events that are related to the adjacency building process
-
debug ip ospf monitor: Monitors when the SPF algorithm is scheduled to run and displays the triggering LSA and a summary of the results after the SPF algorithm has completed
There are two ways for routes to be injected in a routing protocol:
-
Directly connected: These subnets can be injected by enabling the routing protocol on an interface. These routes are considered internal by the routing protocol.
-
External: These are subnets from a different source and can be redistributed into the routing protocol’s data structure. Because these routes were not originated by the routing protocol, they are considered external.
Two important conditions must be met for a prefix learned from one protocol (using redistribution) to be successfully advertised through another protocol:
A feature that can be helpful in diagnosing suspected route instability is the route-profiling feature. Entering the ip route profile command in global configuration mode enables this feature. After you enable this feature, the router tracks the number of routing table changes that occur over 5-second sampling intervals. The show ip route profile command displays the results gathered by this feature. The output can give you an indication of the overall stability of the routing table, without the need to enable a debug command.
BGP uses two main data structures to store its operational data, configured parameters, and statistics:
-
Neighbor table: This table lists all neighbors that have been configured on a router. This table stores valuable information such as the configured autonomous system number of the neighbor, whether the neighbor is an internal or an external peer, the state of the session, how long the neighbor has been up/down for (uptime), and how many prefixes were exchanged with the neighbor.
-
BGP table: This table, sometimes called the BGP Routing Information Base (RIB), stores all the locally injected routes, plus all routes that were received from all the router’s peers, together with all the BGP attributes that are associated with each route, such as the next hop, autonomous system path, local preference, origin, multi-exit discriminator (MED) or metric, origin code, and community attributes. For each prefix, the BGP best path selection algorithm assesses the usability of the available paths and, if one or more usable paths exist, selects one of the paths as the best path. The best path is subsequently advertised to other BGP peers, and BGP attempts to install this route in the IP routing table (offers it to the IP routing table).
The following issues are common causes for failure of BGP peering establishment:
-
There is no IP connectivity between the local BGP router and the configured peer’s IP addresses. Because BGP peers are not necessarily directly connected, both routers need to have an IP path to the configured neighbor IP address in their routing table.
-
The source IP address used by the router that initiates the session does not match the configured neighbor IP address on the receiving router.
-
The autonomous system number of a BGP router (specified in its HELLO or OPEN message) does not match the autonomous system number its neighbor has configured for it (and expects from it).
The following commands can be used to gather information from the BGP data structures:
-
show ip bgp summary: Displays essential BGP parameters, such as the router ID and autonomous system number of the router, statistics on the memory usage of the BGP process, and a brief overview of the configured neighbors and the state of the relationship with each of the configured neighbors.
-
show ip bgp neighbors: Lists all configured neighbors and their current operational state, configured parameters, and extensive statistics for each neighbor. The output of this command can be limited to a specific neighbor by using the show ip bgp neighbors ip-address command.
-
show ip bgp: Displays the content of the BGP table. To select a specific entry from the table, the network and mask of the selected prefix can be provided as an option to the command.
The following debug commands enable you to observe the transmission and reception of BGP packets and the exchange of routing information:
-
debug ip bgp: Displays significant BGP-related events, most notably the subsequent phases of establishing a BGP peering relationship. This command does not display the content of the BGP updates and is a relatively safe to use.
-
debug ip bgp updates: Displays the transmission and reception of BGP updates. The output of this debug can be limited to a specific neighbor and specific prefixes by use of extra options.
0 comments
Post a Comment