Brocade Multi-Service IronWare Multiprotocol Label Switch (MPLS) Configuration Guide (Supporting R05.6.00) User Manual
Page 489
Multi-Service IronWare Multiprotocol Label Switch (MPLS) Configuration Guide
465
53-1003031-02
Configuring VPLS instances
3
•
When the original packet has an I-component Service Identifier (ISID) tag, the payload tag is
the unmodified ISID tag
For more information about CoS behavior for VPLS tagged mode, see
VPLS tagged mode must be enabled on both sides of the communicating edge routers. When the
VPLS VC type does not match, the remote peer does not transition into operational state. Because
each remote peer has its own operational state, the impact may differ from one remote peer to
another, depending on its current state. The remote peer state can be categorized into two general
categories, as follows:
•
Remote peer in operational state – When the remote peer is in operational state, a VC
withdraw message and a new VC bind message is sent to the remote peer to tear down the
current VC binding and to communicate the new VC type, respectively. This scenario assumes
that the remote router is also a Brocade device running the same code level. The VC tear-down
and re-bind should cause the remote peer to transition its peer state to “VC Parameter Check”
state, because its own VC type is now mismatched with that of the new VC type received. Once
the same tagged mode configuration is also applied to the remote router, the peer state for
both routers should transition into operational state. As part of the VC tear-down, the hardware
forwarding entries on the Interface module (LP) is cleaned up. When the peer transitions to
operational state, its hardware forwarding entries is reprogrammed based on its tagged mode
setting.
•
Remote peer not in operational state – The category indicates that the VC has not yet been
formed with the VPLS peer on the remote router. Remote peers may be in this category for
many reasons (for example, “No local port defined”, “No Tunnel”, “No LDP Session”, “VC
Parameter Check”, and so on). In this scenario, there is no need to tear down the VC binding.
When the VPLS tagged mode configuration changes, most of the peers in this category does
not change their operational state or perform any actions triggered by this configuration
change. For remote peers that are in the state “VC Parameter Check” state because of a VC
type mismatch, the configuration change triggers the sending of a VC bind message with the
new VC type to the remote router. When the remote peer’s VC type becomes compatible due to
this configuration change and there is no other VC parameter mismatch, then the state of the
remote peer transitions to the operational state.
To enable VPLS tagged mode, see
“Configuring VPLS tagged mode”
.
CoS behavior for VPLS tagged mode
NOTE
This section assumes that the user understands how QoS works.
describes the expected Class of Service (CoS) behavior for VPLS packets when VPLS
tagged mode is enabled.