5.9. 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.10. Basic Configuration

The following fields require specific input (there are no defaults) to configure a basic VPLS service:

  1. customer ID (refer to Configuring Customer Accounts)
  2. for a local service, configure two SAPs, specifying local access ports and encapsulation values
  3. 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.

*A:ALU-1>config>service>vpls# info
----------------------------------------------
...
    vpls 9001 customer 6 create
        description "Local VPLS"
        sap 1/2/2:0 create
            description "SAP for local service"
        exit
        sap 1/1/5:0 create
            description "SAP for local service"
        exit
        no shutdown
----------------------------------------------
*A:ALU-1>config>service>vpls#

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.

*A:ALU-1>config>service# info
----------------------------------------------
...
    vpls 9000 customer 6 create
        shutdown
        description "This is a distributed VPLS."
        sap 1/1/5:16 create
            description "VPLS SAP"
        exit
        spoke-sdp 2:22 create
        exit
        mesh-sdp 7:9000 create
        exit
    exit
...
----------------------------------------------
*A:ALU-1>config>service#
 
 
 
 
 
 
*A:ALU-2>config>service# info
----------------------------------------------
...
    vpls 9000 customer 6 create
        description "This is a distributed VPLS."
        sap 1/1/5:16 create
            description "VPLS SAP"
        exit
        spoke-sdp 2:22 create
        exit
        mesh-sdp 8:9000 create
        exit
        no shutdown
    exit
...
----------------------------------------------
*A:ALU-2>config>service#
*A:ALU-3>config>service# info
----------------------------------------------
...
    vpls 9000 customer 6 create
        description "This is a distributed VPLS."
        sap 1/1/3:33 create
            description "VPLS SAP"
        exit
        spoke-sdp 2:22 create
        exit
        mesh-sdp 8:9000 create
        exit
        no shutdown
    exit
...
----------------------------------------------
*A:ALU-3>config>service#

5.11. 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:

  1. Associate a VPLS service with a customer ID. For management VPLS, include the m-vpls keyword when creating the VPLS.
  2. Define SA­­Ps:
    1. Select nodes and ports
    2. (optional) Select QoS policies other than the default (configured in the config>qos context)
    3. (optional) Select filter policies (configured in the config>filter context)
    4. (optional) Select accounting policy (configured in the config>log context)
  3. Associate SDPs (for distributed services).
  4. (optional) Modify STP default parameters (see VPLS and Spanning Tree Protocol).
  5. Enable the service.

5.12. Configuring VPLS Components

Topics in this section include:

5.12.1. Creating a VPLS Service

Use the following CLI syntax to create a VPLS service:

CLI Syntax:
config>service#
vpls service-id [customer customer-id] [m-vpls] [create]
description description-string
no shutdown

The following example displays a VPLS configuration:

*A:ALU-1>config>service>vpls# info
----------------------------------------------
...
    vpls 9000 customer 6 create
        description "This is a distributed VPLS."
        shutdown
        exit
    exit
...
----------------------------------------------
*A:ALU-1>config>service>vpls#

5.12.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.

CLI Syntax:
config>service>vpls#
split-horizon-group group-name [residential-group] [create]

The following example displays a VPLS configuration:

*A:ALU-1>config>service>vpls# info
----------------------------------------------
...
    vpls 9000 customer 6 create
        description "VPLS with split horizon"
        split-horizon-group “SHG-group1” residential-group create
            description "Residential Split horizon group"
        exit
        no shutdown
    exit
...
----------------------------------------------

5.12.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:

CLI Syntax:
config>service
vpls service-id [customer customer-id] [m-vpls] [create]
mac-move
primary-ports
spoke-sdp spoke-id
cumulative-factor cumulative-factor
exit
secondary-ports
spoke-sdp spoke-id
sap sap-id
exit
move-frequency frequency
retry-timeout timeout
no shutdown

The following example displays a MAC move configuration:

*A:ALU-2009>config>service>vpls>mac-move# show service id 500 mac-move
===============================================================================
Service Mac Move Information
===============================================================================
Service Id         : 500                       Mac Move         :Enabled
Primary Factor     : 4                         Secondary Factor : 2
Mac Move Rate      : 2                         Mac Move Timeout : 10
Mac Move Retries   : 3
-------------------------------------------------------------------------------
SAP Mac Move Information: 1/1/3:501
-------------------------------------------------------------------------------
Admin State        : Up                        Oper State       : Down
Flags              : RelearnLimitExceeded  
Time to come up    : 1 seconds                 Retries Left     : 1
Mac Move           : Blockable                 Blockable Level  : Tertiary
-------------------------------------------------------------------------------
SAP Mac Move Information: 1/1/3:502
-------------------------------------------------------------------------------
Admin State        : Up                        Oper State       : Up
Flags              : None
Time to RetryReset : 267 seconds               Retries Left     : none
Mac Move           : Blockable                 Blockable Level  : Tertiary
-------------------------------------------------------------------------------
SDP Mac Move Information: 21:501
-------------------------------------------------------------------------------
Admin State        : Up                        Oper State       : Up
Flags              : None
Time to RetryReset : never                     Retries Left    : 3
Mac Move           : Blockable                 Blockable Level : Secondary
-------------------------------------------------------------------------------
SDP Mac Move Information: 21:502
-------------------------------------------------------------------------------
Admin State        : Up                        Oper State      : Down
Flags              : RelearnLimitExceeded
Time to come up    : never                     Retries Left    : none
Mac Move           : Blockable                 Blockable Level : Tertiary
===============================================================================
*A:*A:ALU-2009>config>service>vpls>mac-move#

5.12.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.12.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.

CLI Syntax:
config>service>vpls service-id# stp
no shutdown

5.12.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.

CLI Syntax:
config>service>vpls service-id# stp
mode {rstp}
Default: rstp

5.12.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.

CLI Syntax:
config>service>vpls service-id# stp
priority bridge-priority
Range: 1 to 65535
Default: 32768
Restore Default: no priority

5.12.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.

CLI Syntax:
config>service>vpls service-id# stp
hello-time hello-time
Range: 1 to 10 seconds
Default: 2 seconds
Restore Default: no hello-time

5.12.4.5. Hold Count

The hold-count command configures the peak number of BPDUs that can be transmitted in a period of one second.

CLI Syntax:
config>service>vpls service-id# stp
hold-count count-value
Range: 1 to 10
Default: 6
Restore Default: no hold-count

5.13. 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.13.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:

*A:ALU-1>config>service# info
----------------------------------------------
...
    vpls 9000 customer 6 create
        description "Local VPLS"
        sap 1/2/2:0 create
            description "SAP for local service"
        exit
        sap 1/1/5:0 create
            description "SAP for local service"
        exit
        no shutdown
    exit
----------------------------------------------
*A:ALU-1>config>service#

5.13.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:

*A:ALU-1>config>service# info
--------------------------------------------
...
    vpls 9000 customer 6 create
        description "Distributed VPLS services."
        shutdown
        exit
        sap 1/2/5:0 create
            description "VPLS SAP"
        exit
...
--------------------------------------------
*A:ALU-1>config>service#
*A:ALU-2>config>service# info
--------------------------------------------
...
    vpls 9000 customer 6 create
        description "Distributed VPLS services."
        shutdown
        exit
        sap 1/1/2:22 create
            description "VPLS SAP"
        exit
...
--------------------------------------------
*A:ALU-2>config>service#
*A:ALU-3>config>service# info
----------------------------------------------
...
    vpls 9000 customer 6 create
        description "Distributed VPLS services."
        shutdown
        exit
        sap 1/1/3:33 create
            description "VPLS SAP"
        exit
...
----------------------------------------------
*A:ALU-3>config>service#

5.13.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.13.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:

  1. SAP Admin Up
    The 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.
  2. SAP Admin Down
    An 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.

CLI Syntax:
config>service>vpls>sap>stp#
[no] shutdown
Range: shutdown or no shutdown
Default: no shutdown (SAP admin up)

5.13.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.

CLI Syntax:
config>service>vpls>sap# stp
port-num number
Range: 1 to 2047
Default: (automatically generated)
Restore Default: no port-num

5.13.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.

CLI Syntax:
config>service>vpls>sap>stp#
priority stp-priority
Range: 0 to 255 (240 largest value, in increments of 16)
Default: 128
Restore Default: no priority

5.13.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.

CLI Syntax:
config>service>vpls>sap>stp#
path-cost sap-path-cost
Range: 1 to 200000000
Default: 10
Restore Default: no path-cost

5.13.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.

CLI Syntax:
config>service>vpls>sap>stp#
[no] edge-port
Default: no edge-port

5.13.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.

CLI Syntax:
config>service>vpls>sap>stp#
[no] auto-edge
Default: auto-edge

5.13.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.

CLI Syntax:
config>service>vpls>sap>stp#
link-type {pt-pt|shared}
Default: link-type pt-pt
Restore Default: no link-type

5.13.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.13.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:

  1. VPLS state administratively down
  2. SAP state administratively down
  3. 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.13.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.13.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.13.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.13.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:

*A:ALU-1>config>service# info
----------------------------------------------
...
    vpls 800 customer 6001 create
        description "VPLS with split horizon for DSL"
        sap 1/1/3:1/100 split-horizon-group “DSL-group1” create
            description "SAP for residential bridging"
        exit
        sap 1/1/3:1/200 split-horizon-group “DSL-group1” create
            description "SAP for residential bridging"
        exit
        split-horizon-group “DSL-group1” residential-group create 
            description "Split horizon group for DSL"
        exit
        no shutdown
    exit
...
----------------------------------------------
*A:ALU-1>config>service#

5.14. 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 90 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 90:  SDPs—Unidirectional Tunnels 

5.14.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:

CLI Syntax:
 config>service# vpls service-id
mesh-sdp sdp-id[:vc-id] [vc-type {ether | vlan}]
egress
vc-label egress-vc-label
ingress
filter {ip ip-filter-id | mac mac-filter-id}
vc-label ingress-vc-label
no shutdown
static-mac ieee-address
vlan-vc-tag 0..4094

5.14.2. Configuring Spoke SDP

Topics in this section include:

5.14.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:

CLI Syntax:
config>service# vpls service-id
spoke-sdp sdp-id:vc-id [vc-type {ether | vlan}] [split-horizon-group group-name]
egress
vc-label egress-vc-label
ingress
filter {ip ip-filter-id | mac mac-filter-id}
vc-label ingress-vc-label
limit-mac-move [non-blockable]
no shutdown
static-mac ieee-address
vlan-vc-tag [0..4094]

The following displays SDP binding configurations for ALU-1, ALU-2, and ALU-3 for VPLS service ID 9000 for customer 6:

*A:ALU-1>config>service# info
----------------------------------------------
    vpls 9000 customer 6 create
        description "This is a distributed VPLS."
        sap 1/2/5:0 create
        exit
        spoke-sdp 2:22 create
        exit
        mesh-sdp 5:9000 create
        exit
        mesh-sdp 7:9000 create
        exit
        no shutdown
    exit
----------------------------------------------
*A:ALU-1>config>service#
*A:ALU-2>config>service# info
----------------------------------------------
...
    vpls 9000 customer 6 create
        description "This is a distributed VPLS."
        sap 1/1/2:22 create
        exit
        spoke-sdp 2:22 create
        exit
        mesh-sdp 5:9000 create
        exit
        mesh-sdp 7:9000 create
        exit
        no shutdown
13.0 is     exit
----------------------------------------------
*A:ALU-3>config>service# info
----------------------------------------------
...
    vpls 9000 customer 6 create
        description "This is a distributed VPLS."
        sap 1/1/3:33 create
        exit
        spoke-sdp 2:22 create
        exit
        mesh-sdp 5:9000 create
        exit
        mesh-sdp 7:9000 create
        exit
        no shutdown
    exit
----------------------------------------------
*A:ALU-3>config>service#

5.14.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.14.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:

  1. spoke SDP admin up
    The 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.
  2. spoke SDP admin down
    An 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.

CLI Syntax:
config>service>vpls>spoke-sdp>stp#
[no] shutdown

5.14.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.

CLI Syntax:
config>service>vpls>spoke-sdp# stp
port-num virtual-port-number

5.14.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.

CLI Syntax:
config>service>vpls>spoke-sdp>stp#
priority stp-priority

5.14.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.

CLI Syntax:
config>service>vpls>spoke-sdp>stp#
path-cost stp-path-cost

5.14.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.

CLI Syntax:
config>service>vpls>spoke-sdp>stp#
[no] edge-port

5.14.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.

CLI Syntax:
config>service>vpls>spoke-sdp>stp#
[no] auto-edge

5.14.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.

CLI Syntax:
config>service>vpls>spoke-sdp>stp#
link-type {pt-pt|shared}

5.14.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:

*A:ALU-1>config>service# info
----------------------------------------------
...
    vpls 800 customer 6001 create
        description "VPLS with split horizon for DSL"
        spoke-sdp 51:15 split-horizon-group “DSL-group1” create
        exit
        split-horizon-group “DSL-group1”
            description "Split horizon group for DSL"
        exit
        no shutdown
    exit
...
----------------------------------------------
*A:ALU-1>config>service#

5.14.4. Configuring Selective MAC Flush

Use the following CLI syntax to enable selective MAC flush in a VPLS instance:

CLI Syntax:
config>service# vpls service-id
send-flush-on-failure

Use the following CLI syntax to disable selective MAC flush in a VPLS instance:

CLI Syntax:
config>service# vpls service-id
no send-flush-on-failure

5.15. 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:

CLI Syntax:
config>service# vpls service-id
allow-ip-int-binding
service-name service-name

Use the following CLI syntax to bind an IES or VPRN interface to the routed VPLS instance and to configure an override filter:

CLI Syntax:
config>service>ies# interface ip-interface-name [create]
vpls service-name
ingress
v4-routed-override-filter ipv4-filter-id
v6-routed-override-filter ipv6-filter-id
CLI Syntax:
config>service>vprn# interface ip-interface-name [create]
vpls service-name
ingress
v4-routed-override-filter ipv4-filter-id
v6-routed-override-filter ipv6-filter-id

5.16. 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:

*A:ALU-1>config>service>vpls# info 
----------------------------------------------
            description "Default tls description for service id 1"
            service-mtu 1400
            stp
                shutdown
            exit
            igmp-snooping
                no shutdown
            exit
            service-name "snooper"
            sap 1/1/5:12 create
                description "Default sap description for service id 1"
            exit
            sap 1/1/5:34 create
                description "Default sap description for service id 1"
            exit
            mesh-sdp 21:1 create
                no shutdown
            exit
            spoke-sdp 23:1 create
                no shutdown
            exit
            no shutdown
----------------------------------------------
*A:ALU-1>config>service>vpls#

5.17. 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.

  1. Create an r-VPLS by using the vpls>allow-ip-int-binding command and the ies>interface>vpls service-name command.
  2. Configure IGMP or MLD on IES to form the link between Layer 3 and Layer 2.
  3. Configure PIM on a network interface to allow the propagation of multicast join messages into the network.
  4. (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:

*A:ALU-1>config>service>vpls# info 
----------------------------------------------
            description "Default tls description for service id 1"
            service-mtu 1400
            allow-ip-int-binding
            stp
                shutdown
            exit
            igmp-snooping
                no shutdown
            exit
            service-name "snooper"
            sap 1/1/5:12 create
                description "Default sap description for service id 1"
            exit
            sap 1/1/5:34 create
                description "Default sap description for service id 1"
            exit
            mesh-sdp 21:1 create
                no shutdown
            exit
            spoke-sdp 23:1 create
                no shutdown
            exit
            no shutdown
----------------------------------------------
*A:ALU-1>config>service>vpls#
*A:ALU-1>config>service>ies# info 
----------------------------------------------
            description "Default Ies description for service id 2"
            interface "rvpls_ies" create
                address 19.77.0.77/24
                ipv6
                    address fc77::77/64 
                exit
                vpls "snooper"
                exit
            exit
            service-name "XYZ Ies 2"
            no shutdown
----------------------------------------------
*A:ALU-1>config>service>ies#

To link Layer 3 and Layer 2:

*A:ALU-1>config>router>igmp# info 
----------------------------------------------
            interface "rvpls_ies"
                no shutdown
            exit
            no shutdown
----------------------------------------------
*A:ALU-1>config>router>igmp#

To configure PIM on a network interface:

*A:ALU-1>config>router>pim# info 
----------------------------------------------
            no ipv6-multicast-disable
            interface "PimtoDut4"
            exit
            rp
            exit
            no shutdown
----------------------------------------------
*A:ALU-1config>router>pim#

5.18. 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.

  1. 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.
  2. 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.
  3. A static multicast group can be configured on a SAP or SDP (see Configuring a Static Multicast Group).
  4. 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.

CLI Syntax:
config>service>vpls# igmp-snooping
query-interval seconds
query-src-ip ip-address
report-src-ip ip-address
robust-count robust-count

The following displays IGMP snooping configuration for a VPLS service:

*A:ALU-1>config>service>vpls>igmp-snooping# info detail
----------------------------------------------
                no shutdown
                query-interval 125
                robust-count 2
                report-src-ip 0.0.0.0
                no query-src-ip
----------------------------------------------
*A:ALU-1>config>service>vpls>igmp-snooping# 

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.

CLI Syntax:
config>service>vpls# sap sap-id
config>service>vpls>sap# igmp-snooping
config>service>vpls>sap>igmp-snooping#
[no] disable-router-alert-check
[no] fast-leave
[no] import policy-name
[no] last-member-query-interval interval
[no] max-num-groups max-num-groups
[no] max-num-grp-sources max-num-grp-sources
[no] max-num-sources max-num-sources
[no] mrouter-port
[no] query-interval seconds
[no] query-response-interval seconds
[no] robust-count robust-count
[no] send-queries
[no] static
[no] group grp-ip-address
[no] source ip-address
[no] starg
[no] version version

The following displays IGMP snooping configuration for a VPLS service:

*A:ALU-1>config>service>vpls>sap>igmp-snooping# info detail
----------------------------------------------
                    no fast-leave
                    no import
                    no max-num-groups
                    no max-num-sources
                    no max-num-grp-sources
                    last-member-query-interval 10
                    mrouter-port
                    query-interval 125
                    query-response-interval 10
                    robust-count 2
                    version 3
                    no send-queries
                    no disable-router-alert-check
----------------------------------------------
*A:ALU-1>config>service>vpls>sap>igmp-snooping#

5.19. 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.

CLI Syntax:
config>service>vpls>sap# igmp-snooping
config>service>vpls>sap>igmp-snooping#
[no] static
[no] group grp-ip-address
[no] source ip-address
[no] starg

The following displays a static group configuration for IGMP snooping on a VPLS SAP (multiple groups and multiple sources):

*A:ALU-1>config>service>vpls>sap>igmp-snooping# info
----------------------------------------------
                    send-queries
                    static
                        group 225.0.0.2
                            starg
                        exit
                        group 225.0.0.3
                            source 11.12.12.12
                            source 11.12.13.13
                        exit
                    exit
----------------------------------------------
*A:ALU-1>config>service>vpls>sap>igmp-snooping#

5.20. 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.

CLI Syntax:
config>service>vpls#
pim-snooping
[no] group-policy grp-policy-name [grp-policy-name....up to 5 max]
[no] hold-time seconds
[no] ipv4-multicast-disable
[no] ipv6-multicast-disable
mode [snoop | proxy]
CLI Syntax:
config>service>vpls>sap#
pim-snooping
[no] max-num-groups max-num-groups
CLI Syntax:
config>service>vpls>spoke-sdp#
pim-snooping
[no] max-num-groups max-num-groups

The following displays a VPLS configuration with PIM snooping.

*A:ALU>config>service>vpls>pim-snooping# info detail
----------------------------------------------
                mode proxy
                hold-time 90
                no group-policy
                no ipv4-multicast-disable
                ipv6-multicast-disable
----------------------------------------------
*A:ALU>config>service>vpls>pim-snooping#
*A:ALU>config>service>vpls>sap>pim-snooping# info detail
----------------------------------------------
                    no max-num-groups
----------------------------------------------
*A:ALU>config>service>vpls>sap>pim-snooping#

5.21. Service Management Tasks

This section discusses the following service management tasks:

5.21.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:

*A:ALU-1>config>service>vpls# info
----------------------------------------------
    description "This is a different description."
    disable-learning
    disable-aging
    discard-unknown
    local-age 500
    remote-age 1000
    stp
         shutdown
    exit
    sap 1/1/5:22 create
        description "VPLS SAP"
    exit
    spoke-sdp 2:22 create
    exit
    no shutdown
----------------------------------------------
*A:ALU-1>config>service>vpls#

5.21.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.

CLI Syntax:
config>service# vpls service-id
sap sap-id
managed-vlan-list
[no] range vlan-range

5.21.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:

CLI Syntax:
config>service
[no] vpls service-id
shutdown
[no] sap sap-id
shutdown

5.21.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.

CLI Syntax:
config>service
vpls service-id
shutdown
Example:
config>service# vpls 1
config>service>vpls# shutdown
config>service>vpls# exit

5.21.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:

CLI Syntax:
config>service
[no] vpls service-id
shutdown
[no] mesh-sdp sdp-id
shutdown
sap sap-id [split-horizon-group group-name]
no sap sap-id
shutdown

5.21.6. Disabling a VPLS Service

Use the following CLI syntax to shut down a VPLS service without deleting the service parameters:

CLI Syntax:
config>service> vpls service-id
[no] shutdown
Example:
config>service# vpls 1
config>service>vpls# shutdown
config>service>vpls# exit

5.21.7. Re-enabling a VPLS Service

To re-enable a VPLS service that was shut down:

CLI Syntax:
config>service> vpls service-id
[no] shutdown
Example:
config>service# vpls 1
config>service>vpls# no shutdown
config>service>vpls# exit