Extreme Networks ExtremeWare 7.3.0, Command Reference Manual

Page: 1951 / 2254

configure mpls vpls add peer
ExtremeWare Software 7.3.0 Command Reference Guide 1951
node and up to two secondary core nodes may be added to
vpls_name.
The configured core node
defaults to primary when no primary core node has been configured and defaults to secondary if a
primary core node has previously been configured for vpls_name. Configuration of the primary core
node is not required. All configured primary and secondary core nodes for the vpls_name must be
configured with a different endpoint IP address. Adding a secondary core node designates the node as a
hot-standby redundant H-VPLS core node. A backup VC-LSP is established but is not used. Packets
received on the backup VC-LSP are discarded. In the event that a VC-LSP cannot be established or the
active VC-LSP fails, the VC-LSP to one of the secondary core nodes becomes the active VC-LSP. When a
fail-over occurs, all secondary core nodes have equal preference; the first one available is chosen. If at
any time the VC-LSP to the primary core node is re-established, the switch immediately terminates the
VC-LSP to the secondary core node and begins using the VC-LSP to the primary core node. The VC-LSP
to the secondary core node is re-established and returns to hot-standby state. Dropping the VC-LSP to
the secondary core node forces the core node to flush its MAC FDB relative to the terminated VC-LSP
and to propagate this information throughout the H-VPLS network. If the VC-LSP to the secondary core
node fails while in-use, the VC-LSP to the remaining configured secondary core node becomes the
active VC-LSP. The VC-LSP to the secondary core node remains the active VC-LSP unless the primary
VC-LSP is re-established.
A VPLS peer relationship defined as
core-to-spoke
specifies the spoke connectivity from the core node
to the spoke node. Flood traffic received from a spoke node by the core node is forwarded to all
core-node and spoke-node peers. The
core-to-spoke
may be optionally qualified with the VC-LSP
signaling mode. The VC-LSP between the core and spoke may be signaled as
vpls
,
tls
, or
tps
.
VC-LSPs established to a tls configured spoke are signaled using the martini-draft VLAN FEC. Martini
tls VC-LSPs carry traffic for a single VLAN. Thus, tls core-to-spoke VC-LSPs are incompatible with local
egress VPLS port interfaces (i.e., tls VC-LSPs and local egress ports can not be configured for the same
vpls). VC-LSPs established to an tps configured spoke are signaled using the martini-draft Ethernet
FEC. Martini tps VC-LSPs carry traffic for a set of ports (i.e., port-list). Thus, tps core-to-spoke VC-LSPs
are incompatible with local egress VPLS VLAN interfaces (i.e., tps VC-LSPs and a local egress VLAN
can not be configured for the same vpls). The vcid of the martini VC-LSP can be optionally specified for
either tls or tps. If the vcid is not specified, the configured VPLS VPN ID is used to signal the vcid.
VC-LSPs established to a vpls configured spoke are signaled using the VPLS FEC. The spoke node must
use the VC-LSP signaling method configured on the core node or the VC-LSP will not be established. If
the VC-LSP signaling mode is not specified when the core-to-spoke keyword is specified, vpls signaling
is selected by default. VPLS spoke nodes support additional features that are not defined in the
martini-drafts. These features are automatically enabled when vpls is signaled and are disabled when tls
or tps is signaled. These features include support for MAC Address Withdraw TLV, VPLS OAM packets,
and purging looping packets based on the VC-FEC TTL.
Packets are never forwarded onto a VC-LSP from which the packet was received.
Optionally, the peer VC-LSP connection can be configured to use a specific RSVP-TE LSP. The lsp
keyword specifies which LSP to use. The LSP must have previously been configured. If the lsp is
configured and the LSP specified by
lsp_name
terminates, VPN connectivity to the VPLS peer also
terminates. (To protect the LSP, backup paths can be configured to provide alternate paths to the peer
ipaddress. See Add a Path to a Traffic Engineered LSP on page 3.) If the lsp keyword is omitted, the
VC-LSP will use the best-routed path LSP to the peer ipaddress. If the best-routed path LSP fails, the
next best routed path LSP will be used. In this case, failing over to the next best-routed path LSP will
most likely require a route topology convergence.
Example
None.