MPLS-TP tunnels are configured using the mpls-tp LSP type at an LER under the LSP configuration, using the following CLI tree.
config
router
mpls
lsp <xyz> [bypass-only|mpls-tp <src-tunnel-num>]
to node-id {<a.b.c.d> | <1.. .4,294,967,295>}
dest-global-id <global-id>
dest-tunnel-number <tunnel-num>
[no] working-tp-path
lsp-num <lsp-num>
in-label <in-label>
out-label <out-label> out-link <if-name>
[next-hop <ipv4-address>]
[no] mep
[no] oam-template <name>
[no] bfd-enable [cc | cc_cv] // defaults to cc
[no] shutdown
exit
[no] shutdown
exit
[no] protect-tp-path
lsp-num <lsp-num>
in-label <in-label>
out-label <out-label> out-link <if-name>
[next-hop <ipv4-address> ]
[no] mep
[no] protection-template <name>
[no] oam-template <name>
[no] bfd-enable [cc | cc_cv] //defaults to cc
[no] shutdown
exit
[no] shutdown
exit
<if-name> could be numbered or unnumbered interface using an Ethernet port.
<src-tunnel-num> is a mandatory create time parameter for mpls-tp tunnels, and has to be assigned by the user based on the configured range of tunnel ids. The src-global-id used for the LSP ID is derived from the node-wide global-id value configured under config>router>mpls>mpls-tp. A tunnel cannot be put in the no shutdown state unless the global-id is configured.
The from address of an LSP to be used in the tunnel identifier is taken to be the local node’s node-id/global-id, as configured under config>router>mpls>mpls-tp. If that is not explicitly configured, the default value of the system interface IPv4 address is used
The to node-id address may be entered in 4-octet IPv4 address format or unsigned 32-bit format. This is the far-end node-id for the LSP, and does do need to be IP addresses.
The from and to addresses are used as the from and to node-id in the MPLS-TP Tunnel Identifier used for the MEP ID.
Each LSP consists of a working-tp-path and, optionally, a protect-tp-path. The protect-tp-path provides protection for the working-tp-path is 1:1 linear protection is configured (see below). Proactive OAM, such as BFD, is configured under the MEP context of each path. Protection for the LSP is configured under the protect-tp-path mep context.
The ‛to’ global-id is an optional parameter. If it is not entered, then the dest global ID takes the default value of 0. Global ID values of 0 are allowed and indicate that the node’s configured Global ID should be used. If the local global ID value is 0, then the remote ‛to’ global ID must also be 0. The ‛to’ global ID value cannot be changed if an LSP is in use by an SDP.
The ‛to’ tunnel number is an optional parameter. If it is not entered, then it is taken to be the same value as the source tunnel number.
LSPs are assumed to be bidirectional and co-routed. Therefore, the system will assume that the incoming interface is the same as the out-link.
The next-hop <ip-address> can only be configured if the out-link if-name refers to a numbered IP interface. In this case, the system will determine the interface to use to reach the configured next-hop, but will check that the user-entered value for the out-link corresponds to the link returned by the system. If they do not correspond, then the path will not come up. Note that if a user changes the physical port referred to in the interface configuration, then BFD, if configured on the LSP, will go down. Users should therefore ensure that an LSP is moved to a different interface with a different port configuration to change the port that it uses. This is enforced by blocking the next-hop configuration for an unnumbered interface.
There is no check made that a valid ARP entry exists before allowing a path to come up. Therefore, a path will only be held down if BFD is down. If static ARP is not configured for the interface, then it is assumed that dynamic ARP is used. The result is that if BFD is not configured, a path can come up before ARP resolution has completed for an interface. If BFD is not used, then it is recommended that the connectivity of the path is explicitly checked using on-demand CC/CV before sending user traffic on it.
The following is a list of additional considerations for the configuration of MPLS-TP LSPs and paths:
The working-tp-path must be configured before the protect-tp-path.
Likewise, the protect-tp-path has to be deleted first before the working-tp-path.
The lsp-num parameter is optional. Its default value is ‛1’ for the working-tp-path and ‛2’ for protect-tp-path.
The mep context must be deleted before a path can be deleted.
An MPLS interface needs to be created under config>router>mpls>interface before using/specifying the out-label/out-link in the Forward path for an MPLS-TP LSP. Creation of the LSP will fail if the corresponding MPLS interface does not exist even though the specified router interface may be valid.
The system will program the MPLS-TP LSP information upon a 'no shutdown' of the TP-Path only on the very first no shutdown. The Working TP-Path is programmed as the Primary and the Protection TP-Path is programmed as the 'backup'.
The system will not deprogram the IOM on an 'admin shutdown' of the MPLS-TP path. Traffic will gracefully move to the other TP-Path if valid, as determined by the proactive MPLS-TP OAM. This should not result in traffic loss. However it is recommended that the user does moves traffic to the other TP-Path through a tools command before doing 'admin shut' of an Active TP-Path.
Deletion of the out-label/out-link sub-command under the MPLS-TP Path is not allowed after being configured. These can only be modified.
MPLS will allow the deletion of an 'admin shutdown' TP-Path. This will cause MPLS to deprogram the corresponding TP-Path forwarding information from IOM. This can cause traffic loss for users that are bound to the MPLS-TP LSP.
MPLS will not deprogram the IOM on a specific interface admin shut/clear unless the interface is a System Interface. However, if MPLS informs the TP-OAM module that the MPLS interface has gone down, then it triggers a switch to the standby tp-path if the associated interface went down and if it is valid.
If a MEP is defined and shut down, then the corresponding path is also operationally down. The MEP administrative state is applicable only when a MEP is created from an MPLS-TP path.
It is not mandatory to configure BFD or protection on an MPLS-TP path to bring the LSP up.
If bfd-enable cc is configured, then CC-only mode using ACh channel 0x07 is used. If bfd-enable cc_v is configured, then BFD CC packets use channel 0x22 and CV packets use channel 0x23.
The protection template is associated with a LSP as a part of the MEP on the protect path. If only a working path is configured, then the protection template is not configured.
BFD cannot be enabled under the MEP context unless a named BFD template is configured.