Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Troubleshooting BGP Sessions

 

Checklist for Verifying the BGP Protocol and Peers

Purpose

Table 1 provides links and commands for verifying whether the Border Gateway Protocol (BGP) is configured correctly on a Juniper Networks router in your network, the internal Border Gateway Protocol (IBGP) and exterior Border Gateway Protocol (EBGP) sessions are properly established, the external routes are advertised and received correctly, and the BGP path selection process is working properly.

Action

 

Table 1: Checklist for Verifying the BGP Protocol and Peers

Tasks

Command or Action

Verify BGP Peers
  1. Verify BGP on an Internal Router

show configuration

  1. Verify BGP on a Border Router

show configuration

  1. Verify Advertised BGP Routes

show route advertising-protocol bgp neighbor-address

  1. Verify That a Particular BGP Route Is Received on Your Router

show route receive-protocol bgp neighbor-address

Examine BGP Routes and Route Selection 
  1. Examine the Local Preference Selection

show route destination-prefix < detail >

  1. Examine the Multiple Exit Discriminator Route Selection

show route destination-prefix < detail >

  1. Examine the EBGP over IBGP Selection

show route destination-prefix < detail >

  1. Examine the IGP Cost Selection

show route destination-prefix < detail >

Examine Routes in the Forwarding Table

show route forwarding-table

Verify BGP Peers

Purpose

Assuming that all the routers are correctly configured for BGP, you can verify if IBGP and EBGP sessions are properly established, external routes are advertised and received correctly, and the BGP path selection process is working properly.

Figure 1 illustrates an example BGP network topology used in this topic.

Figure 1: BGP Network Topology
BGP Network Topology

The network consists of two directly connected ASs consisting of external and internal peers. The external peers are directly connected through a shared interface and are running EBGP. The internal peers are connected through their loopback (lo0) interfaces through IBGP. AS 65001 is running OSPF and AS 65002 is running IS-IS as its underlying IGP. IBGP routers do not have to be directly connected, the underlying IGP allows neighbors to reach one another.

The two routers in AS 65001 each contain one EBGP link to AS 65002 (R2 and R4) over which they announce aggregated prefixes: 100.100.1.0, 100.100.2.0, 100.100.3.0, and 100.100.4.0. Also, R1 and R5 are injecting multiple exit discriminator (MED) values of 5 and 10, respectively, for some routes.

The internal routers in both ASs are using a full mesh IBGP topology. A full mesh is required because the networks are not using confederations or route reflectors, so any routes learned through IBGP are not distributed to other internal neighbors. For example, when R3 learns a route from R2, R3 does not distribute that route to R6 because the route is learned through IBGP, so R6 must have a direct BGP connection to R2 to learn the route.

In a full mesh topology, only the border router receiving external BGP information distributes that information to other routers within its AS. The receiving router does not redistribute that information to other IBGP routers in its own AS.

From the point of view of AS 65002, the following sessions should be up:

  • The four routers in AS 65002 should have IBGP sessions established with each other.

  • R2 should have an EBGP session established with R1.

  • R4 should have an EBGP session established with R5.

To verify BGP peers, follow these steps:

  1. Verify BGP on an Internal Router

  2. Verify BGP on a Border Router

  3. Verify Advertised BGP Routes

  4. Verify That a Particular BGP Route Is Received on Your Router

Verify BGP on an Internal Router

Purpose

To verify the BGP configuration of an internal router.

Action

To verify the BGP configuration of an internal router, enter the following Junos OS command-line interface (CLI) command:

The following sample output is for a BGP configuration on R3:

Sample Output

Meaning

The sample output shows a basic BGP configuration on routers R3 and R6. The local AS (65002) and one group (internal) are configured on both routers. R3 has three internal peers—10.0.0.2, 10.0.0.4, and 10.0.0.6—included at the [protocols bgp group group] hierarchy level. R6 also has three internal peers: 10.0.0.2, 10.0.0.3, and 10.0.0.4. The underlying IGP protocol is Intermediate System-to-Intermediate System (IS-IS), and relevant interfaces are configured to run IS-IS.

Note that in this configuration the router ID is manually configured to avoid any duplicate router ID problems.

Verify BGP on a Border Router

Purpose

To verify the BGP configuration of a border router.

Action

To verify the BGP configuration of a border router, enter the following Junos OS CLI operational mode command:

Sample Output

The following sample output is for a BGP configuration on two border routers, R2 and R4 from AS 65002:

Meaning

The sample output shows a basic BGP configuration on border routers R2 and R4. Both routers have the AS (65002) included at the [routing-options] hierarchy level. Each router has two groups included at the [protocols bgp group group] hierarchy level. External peers are included in the external group, either toR1 or toR5, depending on the router. Internal peers are included in the internal group. The underlying IGP protocol is IS-IS on both routers, and relevant interfaces are configured to run IS-IS.

Note that in the configuration on both routers, the router ID is manually configured to avoid duplicate router ID problems, and the next-hop-self statement is included to avoid any BGP next-hop reachability problems.

Verify Advertised BGP Routes

Purpose

You can determine if a particular route that you have configured is being advertised to a neighbor.

Action

To verify the routing information as it has been prepared for advertisement to the specified BGP neighbor, enter the following Junos OS CLI operational mode command:

Sample Output

user@R2> show route advertising-protocol bgp 10.0.0.4\

Meaning

The sample output shows the BGP routes advertised from R2 to its neighbor, 10.0.0.4 (R4). Out of 22 total routes in the inet.0 routing table, 20 are active destinations . No routes are hidden or in the hold-down state. Routes reside in the hold-down state prior to being declared active, and routes rejected by a routing policy can be placed into the hidden state. The information displayed reflects the routes that the routing table exported to the BGP routing protocol.

Verify That a Particular BGP Route Is Received on Your Router

Purpose

Display the routing information as it is received through a particular BGP neighbor and advertised by the local router to the neighbor.

Action

To verify that a particular BGP route is received on your router, enter the following Junos OS CLI operational mode command:

Sample Output

user@R6> show route receive-protocol bgp 10.0.0.2

Meaning

The sample output shows four BGP routes from R2 and two from R4. Of the four routes from R2, only two are active in the routing table, as indicated by the asterisk (*), while both routes received from R4 are active in the routing table. All BGP routes came through AS 65001.

Examine BGP Routes and Route Selection

Purpose

You can examine the BGP path selection process to determine the single, active path when BGP receives multiple routes to the same destination prefix.

Figure 2: BGP Network Topology
BGP Network Topology

The network in Figure 2 shows that R1 and R5 announce the same aggregate routes to R2 and R4, which results in R2 and R4 receiving two routes to the same destination prefix. The route selection process on R2 and R4 determines which of the two BGP routes received is active and advertised to the other internal routers (R3 and R6).

Before the router installs a BGP route, it must make sure that the BGP next-hop attribute is reachable. If the BGP next hop cannot be resolved, the route is not installed. When a BGP route is installed in the routing table, it must go through a path selection process if multiple routes exist to the same destination prefix. The BGP path selection process proceeds in the following order:

  1. Route preference in the routing table is compared. For example, if an OSPF and a BGP route exist for a particular destination, the OSPF route is selected as the active route because the OSPF route has a default preference of 110, while the BGP route has a default preference of 170.

  2. Routes are compared for local preference. The route with the highest local preference is preferred. For example, see Examine the Local Preference Selection.

  3. The AS path attribute is evaluated. The shorter AS path is preferred.

  4. The origin code is evaluated. The lowest origin code is preferred ( I (IGP) < E (EGP) < ? (Incomplete)).

  5. The MED value is evaluated. By default, if any of the routes are advertised from the same neighboring AS, the lowest MED value is preferred. The absence of a MED value is interpreted as a MED of 0. For an example, see Examine the Multiple Exit Discriminator Route Selection.

  6. The route is evaluated as to whether it is learned through EBGP or IBGP. EBGP learned routes are preferred to IBGP learned routes. For an example, see Examine the EBGP over IBGP Selection

  7. If the route is learned from IBGP, the route with the lowest IGP cost is preferred. For an example, see Examine the IGP Cost Selection. The physical next hop to the IBGP peer is installed according to the following three rules:

      1. After BGP examines the inet.0 and inet.3 routing tables, the physical next hop of the route with the lowest preference is used.

      1. If the preference values in the inet.0 and the inet.3 routing tables are a tie, the physical next hop of the route in the inet.3 routing table is used.

      1. When a preference tie exists in the same routing table, the physical next hop of the route with more paths is installed.

  8. The route reflection cluster list attribute is evaluated. The shortest length cluster list is preferred. Routes without a cluster list are considered to have a cluster list length of 0.

  9. The router ID is evaluated. The route from the peer with the lowest router ID is preferred (usually the loopback address).

  10. The peer address value is examined. The peer with the lowest peer IP address is preferred.

To determine the single, active path when BGP receives multiple routes to the same destination prefix, enter the following Junos OS CLI operational mode command:

The following steps illustrate the inactive reason displayed when BGP receives multiple routes to the same destination prefix and one route is selected as the single, active path:

  1. Examine the Local Preference Selection

  2. Examine the Multiple Exit Discriminator Route Selection

  3. Examine the EBGP over IBGP Selection

  4. Examine the IGP Cost Selection



Examine the Local Preference Selection

Purpose

To examine a route to determine if local preference is the selection criteria for the single, active path.

Action

To examine a route to determine if local preference is the selection criteria for the single, active path, enter the following Junos OS CLI operational mode command:

Sample Output

user@R4> show route 100.100.1.0 detail

Meaning

The sample output shows that R4 received two instances of the 100.100.1.0 route: one from 10.0.0.2 (R2) and one from 10.1.45.2 (R5). R4 selected the path from R2 as its active path, as indicated by the asterisk (*). The selection is based on the local preference value contained in the Localpref field. The path with the highest local preference is preferred. In the example, the path with the higher local preference value is the path from R2, 200.

The reason that the route from R5 is not selected is in the Inactive reason field, in this case, Local Preference.

Note that the two paths are from the same neighboring network: AS 65001.



Examine the Multiple Exit Discriminator Route Selection

Purpose

To examine a route to determine if the MED is the selection criteria for the single, active path.

Action

To examine a route to determine if the MED is the selection criteria for the single, active path, enter the following Junos OS CLI operational mode command:

Sample Output

user@R4> show route 100.100.2.0 detail

Meaning

The sample output shows that R4 received two instances of the 100.100.2.0 route: one from 10.0.0.2 (R2), and one from 10.1.45.2 (R5). R4 selected the path from R2 as its active route, as indicated by the asterisk (*). The selection is based on the MED value contained in the Metric: field. The path with the lowest MED value is preferred. In the example, the path with the lowest MED value (5) is the path from R2. Note that the two paths are from the same neighboring network: AS 65001.

The reason that the inactive path is not selected is displayed in the Inactive reason: field, in this case, Not Best in its group. The wording is used because the Junos OS uses the process of deterministic MED selection, by default.



Examine the EBGP over IBGP Selection

Purpose

To examine a route to determine if EBGP is selected over IBGP as the selection criteria for the single, active path.

Action

To examine a route to determine if EBGP is selected over IBGP as the selection criteria for the single, active path, enter the following Junos OS CLI operational mode command:

Sample Output

user@R4> show route 100.100.3.0 detail

Meaning

The sample output shows that R4 received two instances of the 100.100.3.0 route: one from 10.1.45.2 (R5) and one from 10.0.0.2 (R2). R4 selected the path from R5 as its active path, as indicated by the asterisk (*). The selection is based on a preference for routes learned from an EBGP peer over routes learned from an IBGP. R5 is an EBGP peer.

You can determine if a path is received from an EBGP or IBGP peer by examining the Local As and Peer As fields. For example, the route from R5 shows the local AS is 65002 and the peer AS is 65001, indicating that the route is received from an EBGP peer. The route from R2 shows that both the local and peer AS is 65002, indicating that it is received from an IBGP peer.

The reason that the inactive path is not selected is displayed in the Inactive reason field, in this case, Interior > Exterior > Exterior via Interior. The wording of this reason shows the order of preferences applied when the same route is received from two routers. The route received from a strictly internal source (IGP) is preferred first, the route received from an external source (EBGP) is preferred next, and any route which comes from an external source and is received internally (IBGP) is preferred last. Therefore, EBGP routes are selected over IBGP routes as the active path.



Examine the IGP Cost Selection

Purpose

To examine a route to determine if EBGP is selected over IBGP as the selection criteria for the single, active path.

Action

To examine a route to determine if EBGP is selected over IBGP as the selection criteria for the single, active path, enter the following Junos OS CLI operational mode command:

Sample Output

user@R6> show route 100.100.4.0 detail

Meaning

The sample output shows that R6 received two instances of the 100.100.4.0 route: one from 10.0.0.4 (R4) and one from 10.0.0.2 (R2). R6 selected the path from R4 as its active route, as indicated by the asterisk (*). The selection is based on the IGP metric, displayed in the Metric2 field. The route with the lowest IGP metric is preferred. In the example, the path with the lowest IGP metric value is the path from R4, with an IGP metric value of 10, while the path from R2 has an IGP metric of 20. Note that the two paths are from the same neighboring network: AS 65001.

The reason that the inactive path was not selected is displayed in the Inactive reason field, in this case, IGP metric.

Checklist for Checking the BGP Layer

Problem

Description: This checklist provides the steps and commands for checking the BGP configuration of the Multiprotocol Label Switching (MPLS) network. The checklist provides links to an overview of the BGP configuration and more detailed information about the commands used to configure BGP. (See Table 2.)

Solution

Table 2: Checklist for Checking the BGP Layer

Tasks

Command or Action

Checking the BGP Layer 
  1. Check That BGP Traffic Is Using the LSP

traceroute hostname

  1. Check BGP Sessions

show bgp summary

  1. Verify the BGP Configuration

show configuration

  1. Examine BGP Routes

show route destination-prefix detail

  1. Verify Received BGP Routes

show route receive protocol bgp neighbor-address

  1. Taking Appropriate Action for Resolving the Network Problem

The following sequence of commands addresses the specific problem described in this topic:

[edit]

edit protocols bgp

[edit protocols bgp]

show

set local-address 10.0.0.1

delete group internal neighbor 10.1.36.2

show

commit

  1. Check That BGP Traffic Is Using the LSP Again

traceroute hostname

Checking the BGP Layer

Purpose

After you have configured the label-switched path (LSP) and determined that it is up, and configured BGP and determined that sessions are established, ensure that BGP is using the LSP to forward traffic.

Figure 3 illustrates the BGP layer of the layered MPLS model.

Figure 3: Checking the BGP Layer
Checking the BGP Layer

When you check the BGP layer, you verify that the route is present and active, and more importantly, you ensure that the next hop is the LSP. There is no point in checking the BGP layer unless the LSP is established, because BGP uses the MPLS LSP to forward traffic. If the network is not functioning at the BGP layer, the LSP does not work as configured.

Figure 4 illustrates the MPLS network used in this topic.

Figure 4: MPLS Network Broken at the BGP Layer
MPLS Network Broken at the BGP Layer

The network shown in Figure 4 is a fully meshed configuration where every directly connected interface can receive and send packets to every other similar interface. The LSP in this network is configured to run from ingress router R1, through transit router R3, to egress router R6. In addition, a reverse LSP is configured to run from R6 through R3 to R1, creating bidirectional traffic.

The cross shown in Figure 4 indicates where BGP is not being used to forward traffic through the LSP. Possible reasons for the LSP not working correctly are that the destination IP address of the LSP does not equal the BGP next hop or that BGP is not configured properly.

To check the BGP layer, follow these steps:

  1. Check That BGP Traffic Is Using the LSP

  2. Check BGP Sessions

  3. Verify the BGP Configuration

  4. Examine BGP Routes

  5. Verify Received BGP Routes

  6. Taking Appropriate Action for Resolving the Network Problem

  7. Check That BGP Traffic Is Using the LSP Again

Check That BGP Traffic Is Using the LSP

Purpose

At this level of the troubleshooting model, BGP and the LSP may be up, however BGP traffic might not be using the LSP to forward traffic.

Action

To verify that BGP traffic is using the LSP, enter the following Junos OS command-line interface (CLI) operational mode command from the ingress router:

Sample Output

Meaning

The sample output shows that BGP traffic is not using the LSP, consequently MPLS labels do not appear in the output. Instead of using the LSP, BGP traffic is using the interior gateway protocol (IGP) to reach the BGP next-hop LSP egress address for R6 and R1. The Junos OS default is to use LSPs for BGP traffic when the BGP next hop equals the LSP egress address.

Check BGP Sessions

Purpose

Display summary information about BGP and its neighbors to determine if routes are received from peers in the autonomous system (AS). When a BGP session is established, the peers are exchanging update messages.

Action

To check that BGP sessions are up, enter the following Junos OS CLI operational mode command from the ingress router:

Sample Output 1

Sample Output 2

Meaning

Sample Output 1 shows that one peer (egress router 10.0.0.6 ) is not established, as indicated by the Down Peers: 1 field. The last column (State|#Active/Received/Damped) shows that peer 10.0.0.6 is active, indicating that is it not established. All other peers are established as indicated by the number of active, received, and damped routes. For example, 0/0/0 for peer 10.0.0.2 indicates that no BGP routes were active or received in the routing table, and no BGP routes were damped; 1/1/0 for peer 10.1.36.2 indicates that one BGP route was active and received in the routing table, and no BGP routes were damped.

If the output of the show bgp summary command of an ingress router shows that a neighbor is down, check the BGP configuration. For information on checking the BGP configuration, see Verify the BGP Configuration.

Sample Output 2 shows output from ingress router R1 after the BGP configurations on R1 and R6 were corrected in Taking Appropriate Action for Resolving the Network Problem.. All BGP peers are established and one route is active and received. No BGP routes were damped.

If the output of the show bgp summary command shows that a neighbor is up but packets are not being forwarded, check for received routes from the egress router. For information on checking the egress router for received routes, see Verify Received BGP Routes.

Verify the BGP Configuration

Purpose

For BGP to run on the router, you must define the local AS number, configure at least one group, and include information about at least one peer in the group (the peer's IP address and AS number). When BGP is part of an MPLS network, you must ensure that the LSP is configured with a destination IP address equal to the BGP next hop in order for BGP routes to be installed with the LSP as the next hop for those routes.

Action

To verify the BGP configuration, enter the following Junos OS CLI operational mode command:

Sample Output 1

Sample Output 2

Meaning

The sample output shows the BGP configurations on ingress router R1 and egress router R6. Both configurations show the local AS (65432), one group (internal), and six peers configured. The underlying interior gateway protocol is IS-IS, and the relevant interfaces are configured to run IS-IS.

Note

In this configuration, the RID is manually configured to avoid any duplicate RID problems, and all interfaces configured with BGP include the family inet statement at the [edit interfaces type-fpc/pic/port unit logical-unit-number] hierarchy level.

Sample output for ingress router R1 and egress router R6 shows that the BGP protocol configuration is missing the local-address statement for the internal group. When the local-address statement is configured, BGP packets are forwarded from the local router loopback (lo0) interface address, which is the address to which BGP peers are peering. If the local-address statement is not configured, BGP packets are forwarded from the outgoing interface address, which does not match the address to which BGP peers are peering, and BGP does not come up.

On the ingress router, the IP address (10.0.0.1) in the local-address statement should be the same as the address configured for the LSP on the egress router (R6) in the to statement at the [edit protocols mpls label-switched-path lsp-path-name] hierarchy level. BGP uses this address, which is identical to the LSP address, to forward BGP traffic through the LSP.

In addition, the BGP configuration on R1 includes two IP addresses for R6, an interface address (10.1.36.2) and a loopback (lo0) interface address (10.0.0.6), resulting in the LSP destination address (10.0.0.6) not matching the BGP next-hop address (10.1.36.2). The BGP configuration on R6 also includes two IP addresses for R1, an interface address (10.1.13.1) and a loopback (lo0) interface address, resulting in the reverse LSP destination address (10.0.0.1) not matching the BGP next-hop address (10.1.13.1).

In this instance, because the local-address statement is missing in the BGP configurations of both routers and the LSP destination address does not match the BGP next-hop address, BGP is not using the LSP to forward traffic.

Examine BGP Routes

Purpose

You can examine the BGP path selection process to determine the single, active path when BGP receives multiple routes to the same destination. In this step, we examine the reverse LSP R6-to-R1, making R6 the ingress router for that LSP.

Action

To examine BGP routes and route selection, enter the following Junos OS CLI operational mode command:

Sample Output 1

user@R6> show route 100.100.1.1 detail

Sample Output 2

user@R6> show route 100.100.1.1 detail

Meaning

Sample Output 1 shows that the BGP next hop (10.1.13.1) does not equal the LSP destination address (10.0.0.1) in the to statement at the [edit protocols mpls label-switched-path label-switched-path-name] hierarchy level when the BGP configuration of R6 and R1 is incorrect.

Sample Output 2, taken after the configurations on R1 and R6 are corrected, shows that the BGP next hop (10.0.0.1) and the LSP destination address (10.0.0.1) are the same, indicating that BGP can use the LSP to forward BGP traffic.

Verify Received BGP Routes

Purpose

Display the routing information received on router R6, the ingress router for the reverse LSP R6-to-R1.

Action

To verify that a particular BGP route is received on the egress router, enter the following Junos OS CLI operational mode command:

Sample Output 1

user@R6> show route receive-protocol bgp 10.0.0.1

Sample Output 2

user@R6> show route receive-protocol bgp 10.0.0.1

Meaning

Sample Output 1 shows that ingress router R6 (reverse LSP R6-to-R1) does not receive any BGP routes into the inet.0 routing table when the BGP configurations of R1 and R6 are incorrect.

Sample Output 2 shows a BGP route installed in the inet.0 routing table after the BGP configurations on R1 and R6 are corrected using Taking Appropriate Action for Resolving the Network Problem.

Taking Appropriate Action for Resolving the Network Problem

Problem

Description: The appropriate action depends on the type of problem you have isolated. In this example, a static route configured on R2 is deleted from the [routing-options] hierarchy level. Other appropriate actions might include the following:

Solution

  • Check the local router’s configuration and edit it if appropriate.

  • Troubleshoot the intermediate router.

  • Check the remote host configuration and edit it if appropriate.

  • Troubleshoot routing protocols.

  • Identify additional possible causes.

To resolve the problem in this example, enter the following Junos OS CLI commands:

Sample Output

Meaning

The sample output shows the static route deleted from the [routing-options] hierarchy and the new configuration committed. The output for the show route command now shows the BGP route as the preferred route, as indicated by the asterisk (*).

Check That BGP Traffic Is Using the LSP Again

Purpose

After taking the appropriate action to correct the error, the LSP needs to be checked again to confirm that BGP traffic is using the LSP and that the problem in the BGP layer has been resolved.

Action

To verify that BGP traffic is using the LSP, enter the following Junos OS CLI operational mode command from the ingress router:

Sample Output

Meaning

The sample output shows that MPLS labels are used to forward packets through the LSP. Included in the output is a label value (MPLS Label=100016), the time-to-live value (TTL=1), and the stack bit value (S=1).

The MPLS Label field is used to identify the packet to a particular LSP. It is a 20-bit field, with a maximum value of (2^^20-1), approximately 1,000,000.

The time-to-live (TTL) value contains a limit on the number of hops that this MPLS packet can travel through the network (1). It is decremented at each hop, and if the TTL value drops below one, the packet is discarded.

The bottom of the stack bit value (S=1) indicates that is the last label in the stack and that this MPLS packet has one label associated with it. The MPLS implementation in the Junos OS supports a stacking depth of 3 on the M-series routers and up to 5 on the T-series routing platforms. For more information on MPLS label stacking, see RFC 3032, MPLS Label Stack Encoding.

MPLS labels appear in the sample output because the traceroute command is issued to a BGP destination where the BGP next hop for that route is the LSP egress address. The Junos OS by default uses LSPs for BGP traffic when the BGP next hop equals the LSP egress address.

If the BGP next hop does not equal the LSP egress address, the BGP traffic does not use the LSP, and consequently MPLS labels do not appear in the output for the traceroute command, as indicated in the sample output in Check BGP Sessions.

Display Sent or Received BGP Packets

Action

To configure the tracing for sent or received BGP protocol packets, follow these steps:

  1. In configuration mode, go to the following hierarchy level:

  2. Configure the flag to display sent, received, or both sent and received packet information:

    or

    or

  3. Verify the configuration:

    For example:

    or

    or

  4. Commit the configuration:

  5. View the contents of the file containing the detailed messages:

    For example:

Understanding Hidden Routes

Hidden routes are routes that the device cannot use for reasons such as an invalid next hop or a routing policy that rejects the routes.

Note

If a route is completely invalid, the route is not placed into the routing table as a candidate route and does not even appear as hidden.

Following are some useful commands for viewing and troubleshooting hidden routes:

Routes can be hidden for the following reasons:

  • An import policy rejects the route.

  • The next hop cannot be resolved using the current indirect next hop resolution rule. Because routing protocols such as internal BGP (IBGP) can send routing information about indirectly connected routes, Junos OS relies on routes from intra-AS routing protocols (OSPF, IS-IS, RIP, and static) to resolve the best directly connected next hop. The Routing Engine performs route resolution to determine the best directly connected next hop and installs the route to the Packet Forwarding Engine.

  • A damping policy suppresses the route.

  • The AS path contains illegal or invalid confederation attributes.

  • The next hop address is the address of the local routing device.

  • The AS path contains illegal or invalid transitive attributes.

  • The AS path is empty. This only applies to EBGP. For IBGP, an empty AS path is normal.

  • The AS path contains a zero.

  • The next hop address is a multicast address.

  • The next hop address is an IPv6 link-local address.

  • The route prefix or the route next hop is a martian address.

  • The LDP (Label Distribution Protocol) session fails. The received routes are not installed in the routing table until the peer router reestablishes the LDP session.

Examine Routes in the Forwarding Table

Purpose

When you run into problems, such as connectivity problems, you may need to examine routes in the forwarding table to verify that the routing protocol process has relayed the correct information into the forwarding table.

Action

To display the set of routes installed in the forwarding table, enter the following Junos OS CLI operational mode command:

Sample Output

user@R2> show route forwarding-table

Meaning

The sample output shows the network-layer prefixes and their next hops installed in the forwarding table. The output includes the same next-hop information as in the show route detail command (the next-hop address and interface name). Additional information includes the destination type, the next-hop type, the number of references to this next hop, and an index into an internal next-hop database. (The internal database contains additional information used by the Packet Forwarding Engine to ensure proper encapsulation of packets sent out an interface. This database is not accessible to the user.

For detailed information about the meanings of the various flags and types fields, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide.

Example: Overriding the Default BGP Routing Policy on PTX Series Packet Transport Routers

This example shows how to override the default routing policy on packet transport routers, such as the PTX Series Packet Transport Routers.

Requirements

This example requires Junos OS Release 12.1 or later.

Overview

By default, the PTX Series routers do not install BGP routes in the forwarding table.

For PTX Series routers, the configuration of the from protocols bgp condition with the then accept action does not have the usual result that it has on other Junos OS routing devices. With the following routing policy on PTX Series routers, BGP routes do not get installed in the forwarding table.

user@host> show route forwarding-table

No BGP routes are installed in the forwarding table. This is the expected behavior.

This example shows how to use the then install-to-fib action to effectively override the default BGP routing policy.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Installing Selected BGP Routes in the Forwarding Table

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To install selected BGP routes in the forwarding table:

  1. Configure a list of prefixes to install in the forwarding table.
  2. Configure the routing policy, applying the prefix list as a condition.
  3. Apply the routing policy to the forwarding table.

Results

From configuration mode, confirm your configuration by entering the show policy-options and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying That the Selected Route Is Installed in the Forwarding Table

Purpose

Make sure that the configured policy overrides the default policy.

Action

From operational mode, enter the show route forwarding-table command.

user@host> show route forwarding-table destination 66.0.0.1

Meaning

This output shows that the route to 66.0.0.1/32 is installed in the forwarding table.

Log BGP State Transition Events

Purpose

Border Gateway Protocol (BGP) state transitions indicate a network problem and need to be logged and investigated.

Action

To log BGP state transition events to the system log, follow these steps:

  1. In configuration mode, go to the following hierarchy level:

  2. Configure the system log:

  3. Verify the configuration:

  4. Commit the configuration:

Meaning

Log messages from BGP state transition events are sufficient to diagnose most BGP session problems. Table 3 lists and describes the six states of a BGP session.

Table 3: Six States of a BGP Session

BGP State

Description

Idle

This is the first state of a connection. BGP waits for a start event initiated by an administrator. The start event might be the establishment of a BGP session through router configuration or the resetting of an existing session. After the start event, BGP initializes its resources, resets a connect-retry timer, initiates a TCP transport connection, and starts listening for connections initiated by remote peers. BGP then transitions to a Connect state.

If there are errors, BGP falls back to the Idle state.

Connect

BGP waits for the transport protocol connection to complete. If the TCP transport connection is successful, the state transitions to OpenSent.

If the transport connection is not successful, the state transitions to Active.

If the connect-retry timer has expired, the state remains in the Connect state, the timer is reset, and a transport connection is initiated.

With any other event, the state goes back to Idle.

Active

BGP tries to acquire a peer by initiating a transport protocol connection.

If it is successful, the state transitions to OpenSent.

If the connect-retry timer expires, BGP restarts the connect timer and falls back to the Connect state. BGP continues to listen for a connection that may be initiated from another peer. The state may go back to Idle in case of other events, such as a stop event.

In general, a neighbor state flip-flopping between Connect and Active is an indication that there is a problem with the TCP transport connection. Such a problem might be caused by many TCP retransmissions or the inability of a neighbor to reach the IP address of its peer.

OpenSent

BGP receives an open message from its peer. In the OpenSent state, BGP compares its autonomous system (AS) number with the AS number of its peer and recognizes whether the peer belongs to the same AS (internal BGP) or to a different AS (external BGP).

The open message is checked for correctness. In case of errors, such as a bad version number of an unacceptable AS, BGP sends an error-notification message and goes back to Idle.

For any other errors, such as expiration of the hold timer or a stop event, BGP sends a notification message with the corresponding error code and falls back to the Idle state.

If there are no errors, BGP sends keepalive messages and resets the keepalive timer. In this state, the hold time is negotiated. If the hold time is 0, the hold and keepalive timers are not restarted.

When a TCP transport disconnect is detected, the state falls back to Active.

OpenConfirm

BGP waits for a keepalive or notification message.

If a keepalive is received, the state becomes Established, and the neighbor negotiation is complete. If the system receives an update or keepalive message, it restarts the hold timer (assuming that the negotiated hold time is not 0).

If a notification message is received, the state falls back to Idle.

The system sends periodic keepalive messages at the rate set by the keepalive timer. In case of a transport disconnect notification or in response to a stop event, the state falls back to Idle. In response to other events, the system sends a notification message with a finite state machine (FSM) error code and goes back to Idle.

Established

This is the final state in the neighbor negotiation. In this state, BGP exchanges update ackets with its peers and the hold timer is restarted at the receipt of an update or keepalive message when it is not set to zero.

If the system receives a notification message, the state falls back to Idle.

Update messages are checked for errors, such as missing attributes, duplicate attributes, and so on. If errors are found, a notification is sent to the peer, and the state falls back to Idle.

BGP goes back to Idle when the hold timer expires, a disconnect notification is received from the transport protocol, a stop event is received, or in response to any other event.

For more detailed BGP protocol packet information, configure BGP-specific tracing. See Checklist for Tracking Error Conditions for more information.

Configure BGP-Specific Options

Purpose

When unexpected events or problems occur, or if you want to diagnose BGP establishment issues, you can view more detailed information by configuring options specific to BGP. You can also configure tracing for a specific BGP peer or peer group. For more information, see the Junos System Basics Configuration Guide.

  1. Display Detailed BGP Protocol Information

  2. Diagnose BGP Session Establishment Problems



Display Detailed BGP Protocol Information

Action

To display BGP protocol information in detail, follow these steps:

  1. In configuration mode, go to the following hierarchy level:

  2. Configure the flag to display detailed BGP protocol messages:

  3. Verify the configuration:

    For example:

  4. Commit the configuration:

  5. View the contents of the file containing the detailed messages:

    For example:

Meaning

Table 4 lists tracing flags specific to BGP and presents example output for some of the flags. You can also configure tracing for a specific BGP peer or peer group. For more information, see the Junos System Basics Configuration Guide.

Table 4: BGP Protocol Tracing Flags

Tracing Flags

Description

Example Output

aspath

AS path regular expression operations

Not available.

damping

Damping operations

Nov 28 17:01:12 bgp_damp_change: Change event

Nov 28 17:01:12 bgp_dampen: Damping 10.10.1.0

Nov 28 17:01:12 bgp_damp_change: Change event

Nov 28 17:01:12 bgp_dampen: Damping 10.10.2.0

Nov 28 17:01:12 bgp_damp_change: Change event

Nov 28 17:01:12 bgp_dampen: Damping 10.10.3.0

keepalive

BGP keepalive messages

Nov 28 17:09:27 bgp_send: sending 19 bytes to 10.217.5.101 (External AS 65471)

Nov 28 17:09:27

Nov 28 17:09:27 BGP SEND 10.217.5.1+179 -> 10.217.5.101+52162

Nov 28 17:09:27 BGP SEND message type 4 (KeepAlive) length 19

Nov 28 17:09:28

Nov 28 17:09:28 BGP RECV 10.217.5.101+52162 -> 10.217.5.1+179

Nov 28 17:09:28 BGP RECV message type 4 (KeepAlive) length 19

open

BGP open packets

Nov 28 18:37:42 bgp_send: sending 37 bytes to 10.217.5.101 (External AS 65471)

Nov 28 18:37:42

Nov 28 18:37:42 BGP SEND 10.217.5.1+179 -> 10.217.5.101+38135

Nov 28 18:37:42 BGP SEND message type 1 (Open) length 37

packets

All BGP protocol packets

Sep 27 17:45:31 BGP RECV 10.0.100.108+179 -> 10.0.100.105+1033

Sep 27 17:45:31 BGP RECV message type 4 (KeepAlive) length 19

Sep 27 17:45:31 bgp_send: sending 19 bytes to 10.0.100.108 (Internal AS 100)

Sep 27 17:45:31 BGP SEND 10.0.100.105+1033 -> 10.0.100.108+179

Sep 27 17:45:31 BGP SEND message type 4 (KeepAlive) length 19

Sep 27 17:45:31 bgp_read_v4_update: receiving packet(s) from 10.0.100.108 (Internal AS 100)

update

Update packets

Nov 28 19:05:24 BGP SEND 10.217.5.1+179 -> 10.217.5.101+55813

Nov 28 19:05:24 BGP SEND message type 2 (Update) length 53

Nov 28 19:05:24 bgp_send: sending 65 bytes to 10.217.5.101 (External AS 65471)

Nov 28 19:05:24

Nov 28 19:05:24 BGP SEND 10.217.5.1+179 -> 10.217.5.101+55813

Nov 28 19:05:24 BGP SEND message type 2 (Update) length 65

Nov 28 19:05:24 bgp_send: sending 55 bytes to 10.217.5.101 (External AS 65471)



Diagnose BGP Session Establishment Problems

Purpose

To trace BGP session establishment problems.

Action

To trace BGP session establishment problems, follow these steps:

  1. In configuration mode, go to the following hierarchy level:

  2. Configure BGP open messages:

  3. Verify the configuration:

    For example:

  4. Commit the configuration:

  5. View the contents of the file containing the detailed messages:

    For example:

    Sep 17 17:13:14 trace_on: Tracing to "/var/log/bgplog" started

    Sep 17 17:13:14 bgp_read_v4_update: done with 201.0.0.2 (Internal AS 10458) received 19 octets 0 updates 0 routes

    Sep 17 17:13:15 bgp_read_v4_update: receiving packet(s) from 201.0.0.3 (Internal AS 10458)

    Sep 17 17:13:15 bgp_read_v4_update: done with 201.0.0.3 (Internal AS 10458) received 19 octets 0 updates 0 routes

    Sep 17 17:13:44 bgp_read_v4_update: receiving packet(s) from 201.0.0.2 (Internal AS 10458)

    [...Output truncated...]

Configure IS-IS-Specific Options

Purpose

When unexpected events or problems occur, or if you want to diagnose IS-IS adjacency establishment issues, you can view more detailed information by configuring options specific to IS-IS.

To configure IS-IS options, follow these steps:

  1. Displaying Detailed IS-IS Protocol Information

  2. Displaying Sent or Received IS-IS Protocol Packets

  3. Analyzing IS-IS Link-State PDUs in Detail



Displaying Detailed IS-IS Protocol Information

Action

To trace IS-IS messages in detail, follow these steps:

  1. Configure the flag to display detailed IS-IS protocol messages.

  2. Verify the configuration.

    For example:

  3. Commit the configuration.

  4. View the contents of the file containing the detailed messages.

    For example:

Meaning

Table 5 lists tracing flags that can be configured specific to IS-IS and presents example output for some of the flags.

Table 5: IS-IS Protocol Tracing Flags

Tracing Flags

Description

Example Output

csn

Complete sequence number PDU (CSNP)

Nov 28 20:02:48 Sending L2 CSN on interface so-1/1/0.0Nov 28 20:02:48 Sending L2 CSN on interface so-1/1/1.0

With the detail option.

Nov 28 20:06:08 Sending L2 CSN on interface so-1/1/1.0Nov 28 20:06:08 LSP abc-core-01.00-00 lifetime 1146Nov 28 20:06:08 sequence 0x1c4f8 checksum 0xa1e9Nov 28 20:06:08 LSP abc-core-02.00-00 lifetime 411Nov 28 20:06:08 sequence 0x7435 checksum 0x5424Nov 28 20:06:08 LSP abc-brdr-01.00-00 lifetime 465Nov 28 20:06:08 sequence 0xf73 checksum 0xab10Nov 28 20:06:08 LSP abc-edge-01.00-00 lifetime 1089Nov 28 20:06:08 sequence 0x1616 checksum 0xdb29Nov 28 20:06:08 LSP abc-edge-02.00-00 lifetime 1103Nov 28 20:06:08 sequence 0x45cc checksum 0x6883

hello

Hello packet

Nov 28 20:13:50 Sending PTP IIH on so-1/1/1.0Nov 28 20:13:50 Received PTP IIH, source id abc-core-01 on so-1/1/0.0Nov 28 20:13:53 Received PTP IIH, source id abc-core-02 on so-1/1/1.0Nov 28 20:13:57 Sending PTP IIH on so-1/1/0.0Nov 28 20:13:58 Received PTP IIH, source id abc-core-01 on so-1/1/0.0Nov 28 20:13:59 Sending PTP IIH on so-1/1/1.0

lsp

Link-state PDUs (LSPs)

Nov 28 20:15:46 Received L2 LSP abc-edge-01.00-00, interface so-1/1/0.0Nov 28 20:15:46 from abc-core-01Nov 28 20:15:46 sequence 0x1617, checksum 0xd92a, lifetime 1197Nov 28 20:15:46 Updating L2 LSP abc-edge-01.00-00 in TEDNov 28 20:15:47 Received L2 LSP abc-edge-01.00-00, interface so-1/1/1.0Nov 28 20:15:47 from abc-core-02Nov 28 20:15:47 sequence 0x1617, checksum 0xd92a, lifetime 1197

lsp-generation

Link-state PDU generation packets

Nov 28 20:21:24 Regenerating L1 LSP abc-edge-03.00-00, old sequence 0x682Nov 28 20:21:27 Rebuilding L1, fragment abc-edge-03.00-00Nov 28 20:21:27 Rebuilt L1 fragment abc-edge-03.00-00, size 59Nov 28 20:31:52 Regenerating L2 LSP abc-edge-03.00-00, old sequence 0x689Nov 28 20:31:54 Rebuilding L2, fragment abc-edge-03.00-00Nov 28 20:31:54 Rebuilt L2 fragment abc-edge-03.00-00, size 256Nov 28 20:34:05 Regenerating L1 LSP abc-edge-03.00-00, old sequence 0x683Nov 28 20:34:08 Rebuilding L1, fragment abc-edge-03.00-00Nov 28 20:34:08 Rebuilt L1 fragment abc-edge-03.00-00, size 59

packets

All IS-IS protocol packets

Not available.

psn

Partial sequence number PDU (PSNP) packets

Nov 28 20:40:39 Received L2 PSN, source abc-core-01, interface so-1/1/0.0Nov 28 20:40:39 Received L2 PSN, source abc-core-02, interface so-1/1/1.0Nov 28 20:41:36 Sending L2 PSN on interface so-1/1/1.0Nov 28 20:41:36 Sending L2 PSN on interface so-1/1/0.0Nov 28 20:42:35 Received L2 PSN, source abc-core-02, interface so-1/1/1.0Nov 28 20:42:35 LSP abc-edge-03.00-00 lifetime 1196Nov 28 20:42:35 sequence 0x68c checksum 0x746dNov 28 20:42:35 Received L2 PSN, source abc-core-01, interface so-1/1/0.0Nov 28 20:42:35 LSP abc-edge-03.00-00 lifetime 1196Nov 28 20:42:35 sequence 0x68c checksum 0x746dNov 28 20:42:49 Sending L2 PSN on interface so-1/1/1.0Nov 28 20:42:49 LSP abc-core-01.00-00 lifetime 1197Nov 28 20:42:49 sequence 0x1c4fb checksum 0x9becNov 28 20:42:49 Sending L2 PSN on interface so-1/1/0.0Nov 28 20:42:49 LSP abc-core-01.00-00 lifetime 1197Nov 28 20:42:49 sequence 0x1c4fb checksum 0x9bec

spf

Shortest-path-first (SPF) calculations

Nov 28 20:44:01 Scheduling SPF for L1: ReconfigNov 28 20:44:01 Scheduling multicast SPF for L1: ReconfigNov 28 20:44:01 Scheduling SPF for L2: ReconfigNov 28 20:44:01 Scheduling multicast SPF for L2: ReconfigNov 28 20:44:02 Running L1 SPFNov 28 20:44:02 L1 SPF initialization complete: 0.000099s cumulative timeNov 28 20:44:02 L1 SPF primary processing complete: 0.000303s cumulative timeNov 28 20:44:02 L1 SPF result postprocessing complete: 0.000497s cumulative timeNov 28 20:44:02 L1 SPF RIB postprocessing complete: 0.000626s cumulative timeNov 28 20:44:02 L1 SPF routing table postprocessing complete: 0.000736s cumulative time



Displaying Sent or Received IS-IS Protocol Packets

To configure the tracing for only sent or received IS-IS protocol packets, follow these steps:

  1. Configure the flag to display sent, received, or both sent and received packets.

    or

    or

  2. Verify the configuration.

    For example:

    or

    or

  3. Commit the configuration.

  4. View the contents of the file containing the detailed messages.

    For example:



Analyzing IS-IS Link-State PDUs in Detail

To analyze IS-IS link-state PDUs in detail, follow these steps:

  1. Configure IS-IS open messages.

  2. Verify the configuration.

    For example:

  3. Commit the configuration.

  4. View the contents of the file containing the detailed messages.

    For example:

Configure OSPF-Specific Options

Purpose

When unexpected events or problems occur, or if you want to diagnose OSPF neighbor establishment issues, you can view more detailed information by configuring options specific to OSPF.

To configure OSPF options, follow these steps:

  1. Diagnose OSPF Session Establishment Problems

  2. Analyze OSPF Link-State Advertisement Packets in Detail



Diagnose OSPF Session Establishment Problems

Action

To trace OSPF messages in detail, follow these steps:

  1. In configuration mode, go to the following hierarchy level:

  2. Configure OSPF hello messages:

  3. Verify the configuration:

    For example:

    [edit protocols ospf traceoptions]

    user@host# show

    file ospf size 5m world-readable;

    flag hello detail;
  4. Commit the configuration:

  5. View the contents of the file containing the detailed messages:

    For example:

    Dec 2 16:14:24 Version 2, length 44, ID 10.0.0.6, area 1.0.0.0

    Dec 2 16:14:24 checksum 0xf01a, authtype 0

    Dec 2 16:14:24 mask 0.0.0.0, hello_ivl 10, opts 0x2, prio 128

    Dec 2 16:14:24 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0

    Dec 2 16:14:24 OSPF sent Hello (1) -> 224.0.0.5 (so-1/1/2.0)

    Dec 2 16:14:24 Version 2, length 44, ID 10.0.0.6, area 1.0.0.0

    Dec 2 16:14:24 checksum 0xf01a, authtype 0

    Dec 2 16:14:24 mask 0.0.0.0, hello_ivl 10, opts 0x2, prio 128

    Dec 2 16:14:24 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0

    Dec 2 16:14:26 OSPF rcvd Hello 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0)

    Dec 2 16:14:26 Version 2, length 48, ID 10.10.134.12, area 0.0.0.0

    Dec 2 16:14:26 checksum 0x99b8, authtype 0Dec 2 16:14:26 mask 255.255.255.252, hello_ivl 10, opts 0x2, prio 1

    ec 2 16:14:26 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0

    Dec 2 16:14:29 OSPF rcvd Hello 10.10.10.29 -> 224.0.0.5 (so-1/1/0.0)

    Dec 2 16:14:29 Version 2, length 48, ID 10.108.134.11, area 0.0.0.0

    Dec 2 16:14:29 checksum 0x99b9, authtype 0Dec 2 16:14:29 mask 255.255.255.252, hello_ivl 10, opts 0x2, prio 1

    Dec 2 16:14:29 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0

Meaning

Table 6 lists OSPF tracing flags and presents example output for some of the flags.

Table 6: OSPF Protocol Tracing Flags

Tracing Flags

Description

Example Output

database-descripttion

All database description packets

Dec 2 15:44:51 RPD_OSPF_NBRDOWN: OSPF neighbor 10.10.10.29 (so-1/1/0.0) state changed from Full to Down

Dec 2 15:44:51 RPD_OSPF_NBRDOWN: OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Full to Down

Dec 2 15:44:55 RPD_OSPF_NBRUP: OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Init to ExStart

Dec 2 15:44:55 OSPF sent DbD (2) -> 224.0.0.5 (so-1/1/1.0)

Dec 2 15:44:55 Version 2, length 32, ID 10.0.0.6, area 0.0.0.0

Dec 2 15:44:55 checksum 0xf76b, authtype 0

Dec 2 15:44:55 options 0x42, i 1, m 1, ms 1, seq 0xa009eee, mtu 4470

Dec 2 15:44:55 OSPF rcvd DbD 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0)

Dec 2 15:44:55 Version 2, length 32, ID 10.10.134.12, area 0.0.0.0

Dec 2 15:44:55 checksum 0x312c, authtype 0

Dec 2 15:44:55 options 0x42, i 1, m 1, ms 1, seq 0x2154, mtu 4470

error

OSPF errored packets

Dec 2 15:49:34 OSPF packet ignored: no matching interface from 172.16.120.29

Dec 2 15:49:44 OSPF packet ignored: no matching interface from 172.16.120.29

Dec 2 15:49:54 OSPF packet ignored: no matching interface from 172.16.120.29

Dec 2 15:50:04 OSPF packet ignored: no matching interface from 172.16.120.29

Dec 2 15:50:14 OSPF packet ignored: no matching interface from 172.16.120.29

event

OSPF state transitions

Dec 2 15:52:35 OSPF interface ge-2/2/0.0 state changed from DR to DR

Dec 2 15:52:35 OSPF interface ge-3/1/0.0 state changed from DR to DR

Dec 2 15:52:35 OSPF interface ge-3/2/0.0 state changed from DR to DR

Dec 2 15:52:35 OSPF interface ge-4/2/0.0 state changed from DR to DR

Dec 2 15:53:21 OSPF neighbor 10.10.10.29 (so-1/1/0.0) state changed from Full to Down

Dec 2 15:53:21 RPD_OSPF_NBRDOWN: OSPF neighbor 10.10.10.29 (so-1/1/0.0) state changed from Full to Down

Dec 2 15:53:21 OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Full to Down

Dec 2 15:53:21 RPD_OSPF_NBRDOWN: OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Full to Down

Dec 2 15:53:25 OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Down to Init

Dec 2 15:53:25 OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Init to ExStart

Dec 2 15:53:25 RPD_OSPF_NBRUP: OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Init to ExStart

Dec 2 15:53:25 OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from ExStart to Exchange

Dec 2 15:53:25 OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Exchange to Full

Dec 2 15:53:25 RPD_OSPF_NBRUP: OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Exchange to Full

flooding

Link-state flooding packets

Dec 2 15:55:21 OSPF LSA Summary 10.218.0.0 10.0.0.6 flooding on so-1/1/0.0

Dec 2 15:55:21 OSPF LSA Summary 10.218.0.0 10.0.0.6 flooding on so-1/1/1.0

Dec 2 15:55:21 OSPF LSA Summary 10.218.0.0 10.0.0.6 on no so-1/1/2.0 rexmit lists, no flood

Dec 2 15:55:21 OSPF LSA Summary 10.218.0.0 10.0.0.6 on no so-1/1/3.0 rexmit lists, no flood

Dec 2 15:55:21 OSPF LSA Summary 10.245.0.1 10.0.0.6 on no so-1/1/2.0 rexmit lists, no flood

Dec 2 15:55:21 OSPF LSA Summary 10.245.0.1 10.0.0.6 on no so-1/1/3.0 rexmit lists, no flood

hello

Hello packets

Dec 2 15:57:25 OSPF sent Hello (1) -> 224.0.0.5 (ge-3/1/0.0)

Dec 2 15:57:25 Version 2, length 44, ID 10.0.0.6, area 2.0.0.0

Dec 2 15:57:25 checksum 0xe43f, authtype 0

Dec 2 15:57:25 mask 255.255.0.0, hello_ivl 10, opts 0x2, prio 128

Dec 2 15:57:25 dead_ivl 40, DR 10.218.0.1, BDR 0.0.0.0

Dec 2 15:57:25 OSPF rcvd Hello 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0)

Dec 2 15:57:25 Version 2, length 48, ID 10.10.134.12, area 0.0.0.0

Dec 2 15:57:25 checksum 0x99b8, authtype 0

Dec 2 15:57:25 mask 255.255.255.252, hello_ivl 10, opts 0x2, prio 1

Dec 2 15:57:25 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0

Dec 2 15:57:27 OSPF sent Hello (1) -> 224.0.0.5 (ge-3/2/0.0)

Dec 2 15:57:27 Version 2, length 44, ID 10.0.0.6, area 2.0.0.0

Dec 2 15:57:27 checksum 0xe4a5, authtype 0

Dec 2 15:57:27 mask 255.255.0.0, hello_ivl 10, opts 0x2, prio 128

Dec 2 15:57:27 dead_ivl 40, DR 10.116.0.1, BDR 0.0.0.0

Dec 2 15:57:28 OSPF rcvd Hello
10.10.10.29 -> 224.0.0.5 (so-1/1/0.0)

Dec 2 15:57:28 Version 2, length 48, ID
10.10.134.11, area 0.0.0.0

Dec 2 15:57:28 checksum 0x99b9, authtype 0

Dec 2 15:57:28 mask 255.255.255.252, hello_ivl 10, opts 0x2, prio 1

Dec 2 15:57:28 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0

lsa-ack

Link-state acknowledgment packets

Dec 2 16:00:11 OSPF rcvd LSAck 10.10.10.29 -> 224.0.0.5 (so-1/1/0.0)

Dec 2 16:00:11 Version 2, length 44, ID
10.10.134.11, area 0.0.0.0

Dec 2 16:00:11 checksum 0xcdbf, authtype 0

Dec 2 16:00:11 OSPF rcvd LSAck 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0)

Dec 2 16:00:11 Version 2, length 144, ID
10.10.134.12, area 0.0.0.0

Dec 2 16:00:11 checksum 0x73bc, authtype 0

Dec 2 16:00:16 OSPF rcvd LSAck 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0)

Dec 2 16:00:16 Version 2, length 44, ID
10.10.134.12, area 0.0.0.0

Dec 2 16:00:16 checksum 0x8180, authtype 0

lsa-request

Link-state request packets

Dec 2 16:01:38 OSPF rcvd LSReq 10.10.10.29 -> 224.0.0.5 (so-1/1/0.0)

Dec 2 16:01:38 Version 2, length 108, ID
10.10.134.11, area 0.0.0.0

Dec 2 16:01:38 checksum 0xe86, authtype 0

lsa-update

Link-state update packets

Dec 2 16:09:12 OSPF built router LSA, area 0.0.0.0

Dec 2 16:09:12 OSPF built router LSA, area 1.0.0.0

Dec 2 16:09:12 OSPF built router LSA, area 2.0.0.0

Dec 2 16:09:13 OSPF sent LSUpdate (4) -> 224.0.0.5 (so-1/1/0.0)

Dec 2 16:09:13 Version 2, length 268, ID 10.0.0.6, area 0.0.0.0

Dec 2 16:09:13 checksum 0x8047, authtype 0

Dec 2 16:09:13 adv count 7

Dec 2 16:09:13 OSPF sent LSUpdate (4) -> 224.0.0.5 (so-1/1/1.0)

Dec 2 16:09:13 Version 2, length 268, ID 10.0.0.6, area 0.0.0.0

Dec 2 16:09:13 checksum 0x8047, authtype 0

Dec 2 16:09:13 adv count 7

packets

All OSPF packets

Not available.

packet-dump

Dump the contents of selected packet types

Not available.

spf

SPF calculations

Dec 2 16:08:03 OSPF full SPF refresh scheduled

Dec 2 16:08:04 OSPF SPF start, area 1.0.0.0

Dec 2 16:08:04 OSPF add LSA Router 10.0.0.6 distance 0 to SPF list

Dec 2 16:08:04 SPF elapsed time 0.000525s

Dec 2 16:08:04 Stub elapsed time 0.000263s

Dec 2 16:08:04 OSPF SPF start, area 2.0.0.0

Dec 2 16:08:04 OSPF add LSA Router 10.0.0.6 distance 0 to SPF list

Dec 2 16:08:04 SPF elapsed time 0.000253s

Dec 2 16:08:04 Stub elapsed time 0.000249s

Dec 2 16:08:04 OSPF SPF start, area 0.0.0.0

Dec 2 16:08:04 OSPF add LSA Router 10.0.0.6 distance 0 to SPF list

Dec 2 16:08:04 OSPF add LSA Router
10.10.134.11 distance 1 to SPF list

Dec 2 16:08:04 IP nexthop so-1/1/0.0 0.0.0.0

Dec 2 16:08:04 OSPF add LSA Router
10.10.134.12 distance 1 to SPF list

Dec 2 16:08:04 IP nexthop so-1/1/1.0 0.0.0.0



Analyze OSPF Link-State Advertisement Packets in Detail

Action

To analyze OSPF link-state advertisement packets in detail, follow these steps:

  1. In configuration mode, go to the following hierarchy level:

  2. Configure OSPF link-state packages:

  3. Verify the configuration:

    For example:

    [edit protocols ospf traceoptions]

    user@host# show

    file ospf size 5m world-readable;

    flag hello detail;

    flag lsa-update detail;
  4. Commit the configuration:

  5. View the contents of the file containing the detailed messages:

    For example:

    Dec 2 16:23:47 OSPF sent LSUpdate (4) -> 224.0.0.5 (so-1/1/0.0) ec 2 16:23:47 Version 2, length 196, ID 10.0.0.6, area 0.0.0.0

    Dec 2 16:23:47 checksum 0xcc46, authtype 0

    Dec 2 16:23:47 adv count 6 Dec 2 16:23:47 OSPF sent LSUpdate (4) -> 224.0.0.5 (so-1/1/1.0)

    Dec 2 16:23:47 Version 2, length 196, ID 10.0.0.6, area 0.0.0.0 Dec 2 16:23:47 checksum 0xcc46, authtype 0

    Dec 2 16:23:47 adv count 6