This feature enables the automatic creation of an RSVP-TE point-to-point LSP to a destination node whose router ID matches a prefix in the specified peer prefix policy. This LSP type is referred to as an auto-created LSP mesh. To start the process of automatically creating an RSVP-TE LSP mesh, the user must create a route policy referencing a prefix list. This prefix list contains the system addresses of all nodes that are required to be in the mesh, and can be entered as a series of /32 addresses, or simply as a range.
After the route policy is created, the user must create an LSP template containing the common parameters that are used to establish all point-to-point LSPs within the mesh. The template must be created with the keyword mesh-p2p:
config>router>mpls>lsp-template template-name mesh-p2p
Upon creation of the template, CSPF is automatically enabled and cannot be disabled. The template must also reference a default path before it can be placed in a no shutdown state.
Next, the user must associate the LSP template with the previously defined route policy, and this is accomplished using the auto-lsp lsp-template command:
config>router>mpls>auto-lsp lsp-template template-name policy peer-prefix-policy
Once the auto-lsp lsp-template command is entered, the system starts the process of establishing the point-to-point LSPs. The prefixes defined in the prefix list are checked, and if a prefix corresponds to a router ID that is present in the Traffic Engineering (TE) database, the system instantiates a CSPF-computed primary path to that prefix using the parameters specified in the LSP template.
Multiple templates can be associated with the same or different peer prefix policies. Each application of an LSP template with a given prefix in the prefix list results in the instantiation of a single CSPF-computed LSP primary path using the LSP template parameters, as long as the prefix corresponds to a router ID for a node in the TE database. Auto LSP does not support the automatic signaling of a secondary path for an LSP. If the signaling of multiple LSPs to the same destination node is required, a separate LSP template must be associated with a prefix list that contains the same destination node address. Each instantiated LSP will have a unique LSP ID and a unique tunnel ID.
The auto-created LSP is installed in the Tunnel Table Manager (TTM) and is available to applications such as resolution of BGP label routes, and resolution of BGP, IGP, and static routes. The auto-created LSP can also be used for auto-binding by a VPRN service. The auto-created LSP cannot be used as a provisioned SDP for explicit binding by services.
The auto-created LSP mesh can be signaled over both numbered and unnumbered RSVP-TE interfaces.
Up to five peer prefix policies can be associated with an LSP template. Every time the user executes the auto-lsp command with the same or different prefix policy associations or changes the prefix policy associated with an LSP template, the system re-evaluates the prefix policy. The outcome of the re-evaluation indicates to MPLS whether an existing LSP must be torn down or a new LSP must be signaled to a destination address that is already in the TE database.
If a /32 prefix is added to or removed from a prefix list associated with an LSP template, or if a prefix range is expanded or narrowed, the prefix policy re-evaluation is performed. Whether the prefix list contains one or more specific /32 addresses or a range of addresses, MPLS requires an external trigger to instantiate an LSP to a node whose address matches an entry in the prefix list. The external trigger is when the router with a router ID matching an address in the prefix list appears in the TE database. The TE database provides the trigger to MPLS.
The user must perform a no shutdown of the template before it takes effect. When a template is in use, the user must shut down the template before changing any parameters except for those LSP parameters for which the change can be handled with the Make-Before-Break (MBB) procedures (see Make-Before-Break (MBB) Procedures for LSP and Path Parameter Configuration Changes). When the template is shut down and parameters are added, removed, or modified, the existing instances of the LSP using this template are torn down and resignaled.
MBB procedures for manual and timer-based resignaling of the LSP, and for TE graceful shutdown, are supported.
The tools>perform>router>mpls>update-path command is not supported for mesh LSPs.
The one-to-one option under the fast-reroute command is also not supported.
If the TE database loses the router ID while the LSP is up, it will perform an update to the MPLS that states that the router ID is no longer in the TE database. This occurs whether the bypass backup path is activated or not. This will cause MPLS to tear down all mesh LSPs to this router ID. However, if the destination router is not a neighbor of the ingress LER and the user shuts down the IGP instance on the destination router, the router ID corresponding to the IGP instance will only be deleted from the TE database on the ingress LER after the LSA/LSP times out. If the user brings the IGP instance back up before the LSA/LSP times out, the ingress LER will delete and reinstall the same router ID at the receipt of the updated LSA/LSP. The RSVP-TE LSPs destined for this router ID will be deleted and re-established. All other failure conditions will cause the LSP to activate the bypass backup LSP or to go down without being deleted.