Configuring a VPLS Service with CLI
This section provides information to configure VPLS services using the command line interface.
Topics in this section include:
Basic Configuration
The following fields require specific input (there are no defaults) to configure a basic VPLS service:
- customer ID (refer to Configuring Customer Accounts)
- for a local service, configure two SAPs, specifying local access ports and encapsulation values
- for a distributed service, configure a SAP and an SDP for each far-end node
The following example displays a configuration of a local VPLS service on ALU-1.
The following example displays a configuration of a distributed VPLS service between ALU-1, ALU-2, and ALU-3. The vc-id for all mesh SDPs must match the service-id.
Common Configuration Tasks
This section provides a brief overview of the tasks that must be performed to configure both local and distributed VPLS services and provides the CLI commands.
For VPLS services:
- Associate a VPLS service with a customer ID. For management VPLS, include the m-vpls keyword when creating the VPLS.
- Define SAPs:
- Select node(s) and port(s)
- (optional) Select QoS policies other than the default (configured in config>qos context)
- (optional) Select filter policies (configured in config>filter context)
- (optional) Select accounting policy (configured in config>log context)
- Associate SDPs (for distributed services).
- (optional) Modify STP default parameters (see VPLS and Spanning Tree Protocol).
- Enable the service.
Configuring VPLS Components
Topics in this section include:
Creating a VPLS Service
Use the following CLI syntax to create a VPLS service:
The following example displays a VPLS configuration:
Creating a Split Horizon Group
Use the following CLI syntax to create a split horizon group for a VPLS instance. Including the residential-group parameter creates a residential split horizon group.
The following example displays a VPLS configuration:
Enabling MAC Move
The MAC move feature is useful to protect against undetected loops in the VPLS topology as well as the presence of duplicate MACs in a VPLS service. For example, if two clients in the VPLS have the same MAC address, the VPLS will experience a high relearn rate for the MAC and will shut down the SAP or spoke SDP when the threshold is exceeded.
Use the following CLI syntax to configure MAC move parameters:
The following example displays a MAC move configuration:
Configuring STP Bridge Parameters in a VPLS
Modifying some of the STP parameters allows the operator to balance STP between resiliency and speed of convergence extremes.
The following STP parameters can be modified at the VPLS level:
STP always uses the locally configured values for the first three parameters (Admin State, Mode and Priority).
For the parameters Hello Time and Hold Count, the locally configured values are only used when this bridge has been elected root bridge in the STP domain; otherwise, the values received from the root bridge are used. The exception to this rule is that Hello Time is always taken from the locally configured parameter.
Bridge STP Admin State
The administrative state of STP at the VPLS level is controlled by the shutdown command.For SAPs, if STP on the VPLS is administratively disabled, any BPDUs are forwarded transparently through the 7705 SAR. If STP on the VPLS is administratively enabled, but the administrative state of a SAP is down, BPDUs received on such a SAP are discarded.
The 7705 SAR does not support BPDU extraction over spoke SDPs. If STP on the VPLS instance is disabled, BPDUs are forwarded transparently over the spoke SDP. If STP is enabled, the spoke SDP discards all BPDUs received.
Mode
The 7705 SAR operates in the Rapid Spanning Tree Protocol (RSTP) mode and is compliant with IEEE 802.1D-2004 - default mode.
Bridge Priority
The bridge-priority command is used to populate the priority portion of the bridge ID field within outbound BPDUs (the most significant 4 bits of the bridge ID). It is also used as part of the decision process when determining the best BPDU between messages received and sent.
All values will be truncated to multiples of 4096, conforming with IEEE 802.1t and 802.1D-2004.
Hello Time
The hello-time command configures the STP hello time for the VPLS STP instance.
The seconds parameter defines the default timer value that controls the sending interval between BPDU configuration messages by this bridge, on ports where this bridge assumes the designated role.
On the 7705 SAR, the hello time for the spanning tree is determined by the locally configured parameter.
Hold Count
The hold-count command configures the peak number of BPDUs that can be transmitted in a period of one second.
Configuring a VPLS SAP
A default QoS policy is applied to each ingress and egress SAP. Additional QoS policies can be configured in the config>qos context. There are no default filter policies. Filter policies are configured in the config>filter context and must be explicitly applied to a SAP.
Topics in this section include:
Local VPLS SAPs
To configure a local VPLS service, enter the sap sap-id command twice with different port IDs in the same service configuration.
All supported service types and corresponding uplink SAPs are specified in the following examples.
The following example displays a local VPLS configuration:
Distributed VPLS SAPs
To configure a distributed VPLS service, you must configure service entities on originating and far-end nodes. You must use the same service ID on all ends (for example, create a VPLS service ID 9000 on ALU-1, ALU-2, and ALU-3). A distributed VPLS consists of a SAP on each participating node and an SDP bound to each participating node.
For SDP configuration information, see Configuring an SDP. For SDP binding information, see Configuring SDP Bindings.
The following example displays a configuration of VPLS SAPs configured for ALU-1, ALU-2, and ALU-3:
Configuring SAP-Specific STP Parameters
When a VPLS has STP enabled, each SAP within the VPLS has STP enabled by default. The operation of STP on each SAP is governed by:
SAP STP Administrative State
The administrative state of STP within a SAP controls how BPDUs are transmitted and handled when received. The allowable states are:
- SAP Admin UpThe default administrative state is up for STP on a SAP. BPDUs are handled in the normal STP manner on a SAP that is administratively up.
- SAP Admin DownAn administratively down state allows a service provider to prevent a SAP from becoming operationally blocked. BPDUs will not originate out the SAP towards the customer.If STP is enabled on the VPLS level, but disabled on the SAP, received BPDUs are discarded. Discarding the incoming BPDUs allows STP to continue to operate normally within the VPLS service while ignoring the down SAP. The specified SAP will always be in an operationally forwarding state.
 | Note:
The administratively down state allows a loop to form within the VPLS. |
SAP Virtual Port Number
The virtual port number uniquely identifies a SAP within configuration BPDUs. The internal representation of a SAP is unique to a system and has a reference space much bigger than the 12 bits definable in a configuration BPDU. STP takes the internal representation value of a SAP and identifies it with its own virtual port number, which is unique to every other SAP defined on the VPLS. The virtual port number is assigned at the time that the SAP is added to the VPLS.
Since the order in which SAPs are added to the VPLS is not preserved between reboots of the system, the virtual port number may change between restarts of the STP instance. To achieve consistency after a reboot, the virtual port number can be specified explicitly.
SAP Priority
SAP priority allows a configurable “tie-breaking” parameter to be associated with a SAP. When configuration BPDUs are being received, the configured SAP priority will be used in some circumstances to determine whether a SAP will be designated or blocked.
In traditional STP implementations (802.1D-1998), this field is called the port priority and has a value of 0 to 255. This field is coupled with the port number (0 to 255 also) to create a 16-bit value.
In the latest STP standard (802.1D-2004), only the upper 4 bits of the port priority field are used to encode the SAP priority. The remaining 4 bits are used to extend the port ID field into a 12-bit virtual port number field. The virtual port number uniquely references a SAP within the STP instance. See SAP Virtual Port Number for details on the virtual port number.
STP computes the actual SAP priority by taking the configured priority value and masking out the lower four bits. The result is the value that is stored in the SAP priority parameter. For example, if a value of 0 was entered, masking out the lower 4 bits would result in a parameter value of 0. If a value of 255 was entered, the result would be 240.
The default value for SAP priority is 128. This parameter can be modified within a range of 0 to 255, 0 being the highest priority. Masking causes the values actually stored and displayed to be 0 to 240, in increments of 16.
SAP Path Cost
The SAP path cost is used by STP to calculate the path cost to the root bridge. The path cost in BPDUs received on the root port is incremented with the configured path cost for that SAP. When BPDUs are sent out other egress SAPs, the newly calculated root path cost is used.
STP suggests that the path cost is defined as a function of the link bandwidth. Since SAPs are controlled by complex queuing dynamics, in the 7705 SAR the STP path cost is a purely static configuration.
The default value for SAP path cost is 10. This parameter can be modified within a range of 1 to 200000000, 1 being the lowest cost.
SAP Edge Port
The SAP edge-port command is used to reduce the time it takes a SAP to reach the forwarding state when the SAP is on the edge of the network, and thus has no further STP bridge to handshake with.
The edge-port command is used to initialize the internal OPER_EDGE variable. At any time, when OPER_EDGE is false on a SAP, the normal mechanisms are used to transition to the forwarding state. When OPER_EDGE is true, STP assumes that the remote end agrees to transition to the forwarding state without actually receiving a BPDU with an agreement flag set.
The OPER_EDGE variable will dynamically be set to false if the SAP receives BPDUs (the configured edge-port value does not change). The OPER_EDGE variable will dynamically be set to true if auto-edge is enabled and STP concludes there is no bridge behind the SAP.
When STP on the SAP is administratively disabled and re-enabled, the OPER_EDGE is reinitialized to the value configured for edge-port.
Valid values for SAP edge-port are enabled and disabled with disabled being the default.
SAP Auto Edge
The SAP auto-edge command is used to instruct STP to dynamically decide whether the SAP is connected to another bridge.
If auto-edge is enabled, and STP concludes there is no bridge behind the SAP, the OPER_EDGE variable will dynamically be set to true. If auto-edge is enabled and a BPDU is received, the OPER_EDGE variable will dynamically be set to false (see SAP Edge Port).
Valid values for SAP auto-edge are enabled and disabled, with enabled being the default.
SAP Link Type
The SAP link-type parameter instructs STP on the maximum number of bridges behind this SAP.
If there is only a single bridge, transitioning to the forwarding state will be based on handshaking (fast transitions). If more than two bridges are connected by a shared media, their SAPs should all be configured as shared, and timer-based transitions are used.
Valid values for SAP link-type are shared and pt-pt, with pt-pt being the default.
STP SAP Operational States
The operational state of STP within a SAP controls how BPDUs are transmitted and handled when received. Defined states are:
Operationally Disabled
Operationally disabled is the normal operational state for STP on a SAP in a VPLS that has any of the following conditions:
- VPLS state administratively down
- SAP state administratively down
- SAP state operationally down
If the SAP enters the operationally up state with the STP administratively up and the SAP STP state is up, the SAP will transition to the STP SAP discarding state.
When, during normal operation, the router detects a downstream loop behind a SAP, BPDUs can be received at a very high rate. To recover from this situation, STP will transition the SAP to the disabled state for the forward-delay duration of 15 s.
Operationally Discarding
A SAP in the discarding state only receives and sends BPDUs, building the local proper STP state for each SAP while not forwarding actual user traffic.
| Note:
In previous versions of the STP standard, the discarding state was called a blocked state. |
Operationally Learning
The learning state allows for the population of the MAC forwarding table before entering the forwarding state. In this state, no user traffic is forwarded.
Operationally Forwarding
Configuration BPDUs are sent out a SAP in the forwarding state. Layer 2 frames received on the SAP are source-learned and destination-forwarded according to the FIB. Layer 2 frames received on other forwarding interfaces and destined for the SAP are also forwarded.
Configuring VPLS SAPs with Split Horizon
To configure a VPLS service with a split horizon group, add the split-horizon-group parameter when creating the SAP. Traffic arriving on a SAP within a split horizon group will not be copied to other SAPs in the same split horizon group.
The following example displays a VPLS configuration with split horizon enabled:
Configuring SDP Bindings
This section contains the following topics:
VPLS provides scaling and operational advantages. A hierarchical configuration eliminates the need for a full mesh of VCs between participating devices. Hierarchy is achieved by enhancing the base VPLS core mesh of VCs with access VCs (spoke) to form two tiers. Spoke SDPs are generally created between Layer 2 switches and placed at the Multi-Tenant Unit (MTU). The PE routers are placed at the service provider's Point of Presence (POP). Signaling and replication overhead on all devices is considerably reduced.
A spoke SDP is treated like the equivalent of a traditional bridge port, where flooded traffic received on the spoke SDP is replicated on all other “ports” (other spoke and mesh SDPs or SAPs) and not transmitted on the port it was received on (unless a split horizon group was defined on the spoke SDP; see Configuring VPLS Spoke SDPs with Split Horizon).
A spoke SDP connects a VPLS service between two sites and, in its simplest form, could be a single tunnel LSP. A set of ingress and egress VC labels are exchanged for each VPLS service instance to be transported over this LSP. The PE routers at each end treat this as a virtual spoke connection for the VPLS service in the same way as the PE-MTU connections. This architecture minimizes the signaling overhead and avoids a full mesh of VCs and LSPs between the two metro networks.
A mesh SDP bound to a service is logically treated like a single bridge “port” for flooded traffic, where flooded traffic received on any mesh SDP on the service is replicated to other “ports” (spoke SDPs and SAPs) and not transmitted on any mesh SDPs.
A VC-ID can be specified with the SDP-ID. The VC-ID is used instead of a label to identify a virtual circuit. The VC-ID is significant between peer 7705 SAR routers on the same hierarchical level. The value of a VC-ID is conceptually independent from the value of the label or any other datalink-specific information of the VC.
Figure 82 displays an example of a distributed VPLS service configuration of spoke and mesh SDPs (unidirectional tunnels) between 7750 SR routers and 7705 SAR MTUs.
Figure 82: SDPs—Unidirectional Tunnels
Configuring Mesh SDP Bindings
Use the following CLI syntax to create a mesh SDP binding with a distributed VPLS service. SDPs must be configured prior to binding. Refer to Configuring an SDP for information about creating SDPs.
Use the following CLI syntax to configure mesh SDP bindings:
Configuring Spoke SDP Bindings
Use the following CLI syntax to create a spoke SDP binding with a distributed VPLS service. SDPs must be configured prior to binding. Refer to Configuring an SDP for information about creating SDPs.
Use the following CLI syntax to configure spoke SDP bindings:
The following displays SDP binding configurations for ALU-1, ALU-2, and ALU-3 for VPLS service ID 9000 for customer 6:
Configuring VPLS Spoke SDPs with Split Horizon
To configure spoke SDPs with a split horizon group, add the split-horizon-group parameter when creating the spoke SDP. Traffic arriving on a SAP or spoke SDP within a split horizon group will not be copied to other SAPs or spoke SDPs in the same split horizon group.
The following example displays a VPLS configuration with split horizon enabled:
Configuring Selective MAC Flush
Use the following CLI syntax to enable selective MAC flush in a VPLS instance:
Use the following CLI syntax to disable selective MAC flush in a VPLS instance:
Service Management Tasks
This section discusses the following service management tasks:
Modifying VPLS Service Parameters
You can change existing service parameters. The changes are applied immediately.
To display a list of services, use the show service service-using vpls command. Enter the parameters such as description, SAP, SDP, and/or service-MTU command syntax, and then enter the new information.
The following displays a modified VPLS configuration:
Modifying Management VPLS Parameters
To modify the range of VLANs on an access port that are to be managed by an existing management VPLS, first the new range should be entered and then the old range removed. If the old range is removed before a new range is defined, all customer VPLS services in the old range will become unprotected and may be disabled.
Deleting a Management VPLS
As with normal VPLS service, a management VPLS cannot be deleted until SAPs are unbound (deleted), interfaces are shut down, and the service is shut down on the service level.
Use the following CLI syntax to delete a management VPLS service:
Disabling a Management VPLS
You can shut down a management VPLS without deleting the service parameters.When a management VPLS is disabled, all associated user VPLS services are also disabled (to prevent loops). If this is not desired, first un-manage the user’s VPLS service by removing them from the managed-vlan-list.
Deleting a VPLS Service
A VPLS service cannot be deleted until SAPs and SDPs are unbound (deleted), interfaces are shut down, and the service is shut down on the service level.
Use the following CLI syntax to delete a VPLS service:
Disabling a VPLS Service
Use the following CLI syntax to shut down a VPLS service without deleting the service parameters:
Re-enabling a VPLS Service
To re-enable a VPLS service that was shut down: