BGP Routes Analysis
BGP routing is a complex process because it involves numerous attributes. Analyzing BGP routes helps the network planner to understand their network better (e.g., to find out where the bottlenecks are). The BGP Module provides the users techniques to investigate BGP routes. In general, BGP routes can be analyzed by investigating point-to-point routing or by generating demands and then examining the ways that demands get routed.
To use demands to observe routes, navigate to the Demands tab. From the Damands tab on the Network Info table you can view how they are routed or why they are unplaced.
The following figure shows the demands in the network. Notice that some demands are routed while others are not, as indicated by an empty Current Route column.
Highlight a demand and click on the Show Path button in the Demands window. The routing of the highlighted demand would be shown on the map.
Check the Console window for details regarding the BGP next hops chosen along the path that are indicated after the arrow “->”. The sample console output below of a path analysis from RTRA to 10.2.1.3 (RTRC) indicates that RTRA chooses BGP next hop 10.2.1.2 on RTRB1 which is directly connected. RTRB1 subsequently chooses BGP next hop 10.2.1.3 (RTRC) which is reached via the IGP next hop of 10.2.1.20 (RTRB2) found by recursive lookup.
RTRA->10.2.1.2(RTRB1) RTRB1->10.2.1.3(RTRC) via 10.2.1.20(RTRB2)
Looking at unplaced demands will help you to determine where the bottlenecks are and why. From the Demands window, find an unplaced demand and then click on the Bottlenecks button. Examine the main topology map as well as the console to help you to determine the reason for the unplaced demand, e.g. a missing BGP routing table entry or being blocked by a policy.
You can investigate the originating nodes of unplaced demands to determine the reasons for the bottlenecks. For example, it may be because the status of a peering relationship is down or because a community list is denied. The console window can provide details about why a demand failed. For example, it can indicate at which step the route was blocked due to out policies or in policies when troubleshooting why a BGP next hop was not found.