Extreme Networks ExtremeWare Command Reference Manual page 1969

configure mpls vpls add peer
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 or tls. 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). The vcid of the martini VC-LSP can be optionally specified as tls. 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 is signaled. These features include support for
MAC Address Withdraw TLV, VPLS OAM packets, and purging looping packets based on the VC-FEC
TTL.
The optional dot1q keyword may be used to specify the ethertype used on the customer traffic sent
across the VC-LSP. By default, the configured switch ethertype is used. If configured, the ethertype in
the outer 802.1q field of the customer packet is overwritten using the configured per VC-LSP ethertype.
The ethertype value is ignored on receipt.
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 92.) 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.
ExtremeWare Software 7.3.0 Command Reference Guide 1969