Cisco Crosswork Planning Design 7.2.x User Guide

PDF

Cisco Crosswork Planning Design 7.2.x User Guide

Unresolved LSP destinations and hops

Updated: August 14, 2026

Want to summarize with AI?

Log in

Details how unresolved LSP destinations and hops appear after discovery and how they affect RSVP-TE LSP configuration review and cleanup.

RSVP-TE LSP configurations and state are read using network discovery from the source node of the LSP, through SNMP, the Parse config tool, or other methods. These configurations might reference nodes or interfaces that do not exist in the plan file, so they are referred to as being unresolved. For example, the LSP destination node, read from the configuration on the source, might not be in the plan file.

There are several reasons for these differences:

  • The plan file was modified to contain fewer nodes than are in the IGP.

  • Cisco Crosswork Planning cannot read all the nodes, or cannot obtain the IP addresses of all the nodes.

  • The LSPs themselves are not configured correctly.

References that might not be resolved include:

  • Destination nodes of the LSPs.

  • Hops in named paths configured on the source node.

  • Hops in the actual paths read from the source node.

Cisco Crosswork Planning tries to resolve as many of these references as possible. Tables and columns are updated:

  • If the LSP destinations are resolved, they are updated in the Destination column of the LSPs table. If they are not resolved, the column remains empty. The original IP address remains in the NetInt Destination column regardless of whether the destination is resolved or not.

  • If the hops are resolved, they are updated in the Node and Interface columns in the Named Path Hops and Actual Path Hops tables. If they are not resolved, the columns remain empty. The original IP address remains in the NetIntHop column regardless of whether the destination is resolved.

Cisco Crosswork Planning does not make further attempts to resolve these references unless you explicitly make the request. There are special cases in which this might be useful. For example, if additional nodes are added to a network from a second network discovery procedure and if LSPs in the original network have unresolved references to these nodes, it is useful to resolve the LSPs again.