5.8. Configuring a VPLS Service with CLI
This section provides information to configure VPLS services using the command line interface.
Topics in this section include:
5.9. 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.
5.10. 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 nodes and ports
- (optional) Select QoS policies other than the default (configured in the config>qos context)
- (optional) Select filter policies (configured in the config>filter context)
- (optional) Select accounting policy (configured in the config>log context)
- Associate SDPs (for distributed services).
- (optional) Modify STP default parameters (see VPLS and Spanning Tree Protocol).
- Enable the service.
5.11. Configuring VPLS Components
Topics in this section include:
5.11.1. Creating a VPLS Service
Use the following CLI syntax to create a VPLS service:
The following example displays a VPLS configuration:
5.11.2. 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:
5.11.3. 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:
5.11.4. 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.
5.11.4.1. 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.
5.11.4.2. Mode
The 7705 SAR operates in the Rapid Spanning Tree Protocol (RSTP) mode and is compliant with IEEE 802.1D-2004 - default mode.
5.11.4.3. 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.
5.11.4.4. 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.
5.11.4.5. Hold Count
The hold-count command configures the peak number of BPDUs that can be transmitted in a period of one second.
5.12. 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:
5.12.1. 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:
5.12.2. 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:
5.12.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:
5.12.3.1. 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. |
5.12.3.2. 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.
5.12.3.3. 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.
5.12.3.4. 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.
5.12.3.5. 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.
5.12.3.6. 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.
5.12.3.7. 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.
5.12.4. STP SAP Operational States
The operational state of STP within a SAP controls how BPDUs are transmitted and handled when received. Defined states are:
5.12.4.1. 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.
5.12.4.2. 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. |
5.12.4.3. 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.
5.12.4.4. 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.
5.12.5. 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:
5.13. 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 95 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 95: SDPs—Unidirectional Tunnels
5.13.1. 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:
5.13.2. Configuring Spoke SDP
Topics in this section include:
5.13.2.1. Configuring Spoke SDP Binding
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:
5.13.2.2. Configuring Spoke SDP-Specific STP Parameters
When a VPLS has STP enabled, each spoke SDP within the VPLS has STP enabled by default. The operation of STP on each spoke SDP is governed by:
5.13.2.2.1. Spoke SDP STP Administrative State
The administrative state of STP within a spoke SDP controls how BPDUs are transmitted and handled when received. The allowable states are:
- spoke SDP admin upThe default administrative state is up for STP on a spoke SDP. BPDUs are handled in the normal STP manner on a spoke SDP that is administratively up.
- spoke SDP admin downAn administratively down state allows a service provider to prevent a spoke SDP from becoming operationally blocked. BPDUs will not originate out the spoke SDP towards the customer.If STP is enabled on the VPLS level, but disabled on the spoke SDP, received BPDUs are discarded. Discarding the incoming BPDUs allows STP to continue to operate normally within the VPLS service while ignoring the down spoke SDP. The specified spoke SDP will always be in an operationally forwarding state.
| Note: The administratively down state allows a loop to form within the VPLS. |
5.13.2.2.2. Spoke SDP Virtual Port Number
The virtual port number uniquely identifies a spoke SDP within configuration BPDUs. The internal representation of a spoke SDP is unique to a system and has a reference space much larger than the 12 bits definable in a configuration BPDU. STP takes the internal representation value of a spoke SDP and identifies it with its own virtual port number, which is unique to any other spoke SDP defined on the VPLS. The virtual port number is assigned at the time that the spoke SDP is added to the VPLS.
Since the order in which spoke SDPs 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.
5.13.2.2.3. Spoke SDP Priority
Spoke SDP priority allows a configurable “tie-breaking” parameter to be associated with a spoke SDP. When configuration BPDUs are being received, the configured spoke SDP priority will be used in some circumstances to determine whether a spoke SDP 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 (also 0 to 255) 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 spoke SDP 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 spoke SDP within the STP instance. See Spoke SDP Virtual Port Number for details on the virtual port number.
STP computes the actual spoke SDP priority by taking the configured priority value and masking out the lower 4 bits. The result is the value that is stored in the spoke SDP 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 spoke SDP priority is 128. This parameter can be configured within a range of 0 to 255, with 0 being the highest priority. Masking causes the values actually stored and displayed to be 0 to 240, in increments of 16.
5.13.2.2.4. Spoke SDP Path Cost
The spoke SDP 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 spoke SDP. When BPDUs are sent out other egress spoke SDPs, the newly calculated root path cost is used.
STP suggests that the path cost is defined as a function of the link bandwidth. Since spoke SDPs are controlled by complex queuing dynamics, in the 7705 SAR the STP path cost is a purely static configuration.
The default value for spoke SDP path cost is 10. This parameter can be configured within a range of 1 to 200000000, with 1 being the lowest cost.
5.13.2.2.5. Spoke SDP Edge Port
The spoke SDP edge-port command is used to reduce the time it takes a spoke SDP to reach the forwarding state when the spoke SDP 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 spoke SDP, 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 spoke SDP 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 spoke SDP.
When STP on the spoke SDP is administratively disabled and re-enabled, the OPER_EDGE is reinitialized to the value configured for edge-port.
Valid values for spoke SDP edge-port are enabled and disabled, with disabled being the default.
5.13.2.2.6. Spoke SDP Auto Edge
The spoke SDP auto-edge command is used to instruct STP to dynamically decide whether the spoke SDP is connected to another bridge.
If auto-edge is enabled, and STP concludes there is no bridge behind the spoke SDP, 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 Spoke SDP Edge Port).
Valid values for spoke SDP auto-edge are enabled and disabled, with enabled being the default.
5.13.2.2.7. Spoke SDP Link Type
The spoke SDP link-type parameter instructs STP on the maximum number of bridges behind this spoke SDP.
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 spoke SDPs should all be configured as shared, and timer-based transitions are used.
Valid values for spoke SDP link-type are shared and pt-pt, with pt-pt being the default.
5.13.3. 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:
5.13.4. 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:
5.14. Configuring Routed VPLS
To establish routed VPLS, a VPLS service must be bound to a standard IP interface within an IES or VPRN service. This is done by giving the VPLS a service-name and setting the VPLS allow-ip-int-binding flag. The binding is completed when the IES or VPRN interface is associated with the VPLS service-name. See Routed VPLS for details.
A VPLS service only supports binding for a single IP interface.
Additionally, an ingress IPv4 or IPv6 filter can be assigned to the VPLS SAP and the IES or VPRN interface. Use the v4- and v6-routed-override-filter commands to give the IP interface filter precedence over the VPLS SAP filter. See IES Command Reference and VPRN Services Command Reference for command descriptions.
Use the following CLI syntax to set up routed VPLS in a VPLS instance:
Use the following CLI syntax to bind an IES or VPRN interface to the routed VPLS instance and to configure an override filter:
5.15. Configuring IP Multicast in VPLS
Use the config>service>vpls>igmp-snooping (or mld-snooping) command to enable IP multicast in VPLS. The igmp-snooping and mld-snooping commands stop the default flooding of multicast traffic and allow the creation of a multicast forwarding database (MFIB) on a per-port basis.
The following displays a VPLS configuration with IGMP snooping. Configuring MLD snooping is similar except that the mld-snooping command and IPv6 addresses are used instead of the igmp-snooping command and IPv4 addresses:
5.16. Configuring IP Multicast in r-VPLS
Configuring IP multicast in a routed VPLS requires several steps.
Creating a Layer 2 multicast service in the context of an r-VPLS with PIM translation configured on the r-VPLS Layer 3 interface creates two multicast groups: one Layer 2 multicast group and one Layer 3 multicast group. Creating the Layer 2 multicast group automatically creates the Layer 3 group. It is not necessary to create both groups. The 7705 SAR uses one Layer 3 multicast group per source, and one Layer 2 multicast group per source per VPLS. See IP Multicast in r-VPLS for details.
Perform the following steps to create Layer 2 and Layer 3 multicast groups on a SAP or SDP.
- Create an r-VPLS by using the vpls>allow-ip-int-binding command and the ies>interface>vpls service-name command.
- Configure IGMP or MLD on IES to form the link between Layer 3 and Layer 2.
- Configure PIM on a network interface to allow the propagation of multicast join messages into the network.
- (Optional) Configure the Layer 2 multicast service parameters, as described in Configuring Multicast Parameters for VPLS and r-VPLS.
The following displays illustrate step 1 to step 3 for an r-VPLS configuration with IGMP snooping. Configuring MLD snooping is similar except that the mld-snooping command and IPv6 addresses are used instead of the igmp-snooping command and IPv4 addresses.
To create the r-VPLS:
To link Layer 3 and Layer 2:
To configure PIM on a network interface:
5.17. Configuring Multicast Parameters for VPLS and r-VPLS
The 7705 SAR supports multicast for VPLS and r-VPLS through IGMP and MLD snooping at the VPLS service level, as well as at the VPLS SAP and SDP (mesh and spoke) levels. Note the following considerations for IGMP and MLD snooping on a SAP or SDP.
- A filter policy can be imported on a SAP or SDP. Import policies are defined in the config>router>policy-options context. Refer to the “Filter Policies” section in the 7705 SAR Router Configuration Guide for details.
- A SAP or SDP can be configured as a multicast router port (mrouter-port), meaning that a multicast router is attached to this port. However, the mrouter-port and the send-queries commands are mutually exclusive commands.
- A static multicast group can be configured on a SAP or SDP (see Configuring a Static Multicast Group).
- The send-queries command must be enabled for the following commands to be operational: query-interval, query-response-interval, robust-count, and version.
Use the following CLI syntax to configure IGMP snooping parameters for VPLS and r-VPLS. Configuring MLD snooping parameters is similar except that the mld-snooping command and IPv6 addresses are used instead of the igmp-snooping command and IPv4 addresses.
The following displays IGMP snooping configuration for a VPLS service:
Use the following CLI syntax to configure IGMP snooping on a SAP. Configuring IGMP snooping on an SDP is similar. Configuring MLD snooping on a SAP or SDP is also similar, except that the mld-snooping command and IPv6 addresses are used instead of the igmp-snooping command and IPv4 addresses, and the max-num-grp-sources and max-num-sources commands do not apply.
The following displays IGMP snooping configuration for a VPLS service:
5.18. Configuring a Static Multicast Group
A static multicast group is not created until the source or starg—(*,G)—is specified. More than one group can be created per SAP or SDP, and more than one source can be added to a group. A static source cannot be added to a group if a starg already exists in the group.
Use the following CLI syntax to configure a static group for IGMP snooping on a VPLS SAP. Configuring a static group for IGMP snooping on an SDP is similar. Configuring a static group for MLD snooping on a SAP or SDP is also similar, except that the mld-snooping command and IPv6 addresses are used instead of the igmp-snooping command and IPv4 addresses.
The following displays a static group configuration for IGMP snooping on a VPLS SAP (multiple groups and multiple sources):
5.19. Configuring PIM Snooping for VPLS
Use the pim-snooping command to connect a source in a Layer 2 access network to the host in a Layer 3 core network.
Use the following CLI syntax to configure PIM snooping for VPLS and to configure the maximum number of multicast groups for PIM snooping for VPLS SAPs and spoke SDPs.
The following displays a VPLS configuration with PIM snooping.
5.20. Service Management Tasks
This section discusses the following service management tasks:
5.20.1. 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:
5.20.2. 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.
5.20.3. 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:
5.20.4. 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 unmanage the user’s VPLS service by removing them from the managed-vlan-list.
5.20.5. 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:
5.20.6. Disabling a VPLS Service
Use the following CLI syntax to shut down a VPLS service without deleting the service parameters:
5.20.7. Re-enabling a VPLS Service
To re-enable a VPLS service that was shut down: