Static LSPs are label switched paths that are manually configured at
each LSR in the prospective path. Static LSPs are too labor intensive for building complex
network topologies, but they can be useful for defining simple one-hop LSPs to MTUs that
might not have the CPU power necessary to support routing and label distribution
protocols.
Static LSP Example shows two static LSPs
configured between VLAN A and VLAN B. The dashed line shows the static LSP for
unidirectional communications from VLAN A to VLAN B. The solid line shows the static LSP for
communications in the reverse direction.
The
path that an LSP takes and the labels the LSP uses at every hop
do not change when the network topology changes due to links and
nodes going up or down. Once enabled, a static LSP remains administratively
up until it is manually disabled.
Static LSP configuration
is different for ingress, transit, and egress LSRs. At the ingress
LER, only an egress label is defined. At transit LSRs, both ingress
and egress labels must be defined, and at the egress LER, only the
ingress label is defined. During configuration, you must ensure that
the egress label number for each LSR matches the ingress label number
for the downstream LSR.
When creating static LSPs, consider
the following guidelines:
It is your responsibility to ensure that the egress
label of an LSR matches the ingress label of the downstream LSR. The software does not
detect or report label mismatches. Mismatches result in dropped or mis-routed
packets.
The operational state of the LSP is set to down at the
head-end on local failures. However, there is no mechanism to detect the LSP going down
when a failure occurs on a downstream node. When a failure occurs at a downstream node,
traffic may be black-holed for the duration of the failure.
The traffic profile for static LSPs is not configurable
in this release. All static LSPs are given best effort treatment.
The maximum number of static LSPs configurable on any
given node is 1024. The maximum number of ingress static LSPs that are used to forward
traffic to a single destination is 16 (as limited by ECMP).
When multiple LSPs exist for the same destination,
unless forced otherwise, signaled LSPs are preferred to static LSPs. When choosing an
LSP for a FEC, the software prefers RSVP-TE LSPs first, LDP next, and finally static
LSPs.
Since the software has no knowledge of the cost or
hop-count associated with each static LSP, all static LSPs to the same destination are
equally preferred by IP routing.
We recommend that the same LSP name be used on every LSR
along the path of the static LSP. The software does not check for naming consistency
across LSRs. However the switch does report an error when the configured name is not
unique to the LSP on that LSR.
To configure a static LSP,
use the following procedure at each node on the path:
Create a namespace for the LSP using the following
command:
Enable the static LSP for operation using the following
command:
enable mpls
static lsp {lsp_name | all }
When the configuration is complete, you can view the
static LSP configuration with the following command:
show mpls
static lsp {summary | {lsp_name} {detail}}
Clear the counters for the static LSP using the
command:
clear
counters mpls static lsp {lsp_name | all }
Once the static LSP is created on all path nodes, you
can configure a default route, an IP route, or a VPN route to use
the LSP. To configure a default or IP route to use the LSP, use
the following command: