Configuring VPLS

The following sections show the configuration steps necessary to implement VPLS :

• Required Configurations for VPLS
• VPLS Options for BGP Signaling
• VPLS Options for BGP and LDP Signaling

Required Configurations for VPLS

You must take the following steps to configure VPLS:

• Configuring Routing Protocols on the PE and Core Routers
• Configuring VPLS Encapsulation on CE-Facing Interfaces
• Configuring a Signaling Protocol for VPLS

Configuring Routing Protocols on the PE and Core Routers

At a fundamental level, VPLS is a type of Layer 2 VPN. All forms of Layer 2 VPNs require you to configure network protocols to handle intradomain routing (an interior gateway protocol [IGP], such as Open Shortest Path First [OSPF] or Intermediate System-to-Intermediate System [IS-IS]), interdomain routing (Border Gateway Protocol [BGP]), label switching (Multiprotocol Label Switching [MPLS]), and path signaling (Resource Reservation Protocol [RSVP] or Label Distribution Protocol [LDP]). For more information about these protocols and examples of how to configure these protocols to support a Layer 2 VPN, see the JUNOS VPNs Configuration Guide.

Note: The 8-port, 12-port, and 48-port dense Fast Ethernet Physical Interface Cards (PICs) cannot push more than two labels onto an MPLS packet. Because of this, we do not recommend that you configure these PICs as core-facing or equivalent interfaces.

Configuring VPLS Encapsulation on CE-Facing Interfaces

There are four types of VPLS interface encapsulation: Ethernet VPLS, Ethernet VPLS over ATM LLC, VLAN VPLS, and extended VLAN VPLS. When one of these encapsulations is applied to an interface, a family type of VPLS is enabled by default. The encapsulation types are:

• ether-vpls-over-atm-llc—Use Ethernet VPLS over ATM LLC encapsulation on ATM2 IQ logical interfaces. Use this encapsulation type to support IEEE 802.1p classification binding on ATM VCs. This encapsulation type enables a VPLS instance to support bridging between Ethernet interfaces and ATM interfaces, as described in RFC 2684, Multiprotocol Encapsulation over ATM Adaptation Layer 5. When you use this encapsulation type, you configure it on logical interfaces only and you cannot configure multipoint interfaces.
• extended-vlan-vpls—Use extended VLAN VPLS encapsulation on Ethernet interfaces that have VLAN 802.1Q tagging and VPLS enabled and that must accept packets carrying TPIDs 0x8100, 0x9100, and 0x9901.

  Note: The built-in Gigabit Ethernet PIC on the M7i router does not support MPLS.

• ethernet-vpls—Use Ethernet VPLS encapsulation on Ethernet interfaces that have VPLS enabled and must accept packets carrying standard Tag Protocol ID (TPID) values.
• vlan-vpls—Use VLAN VPLS encapsulation on Ethernet interfaces with VLAN tagging enabled. VLAN VPLS encapsulation supports TPID 0x8100 only. You must configure this encapsulation type on both the physical interface and the logical interface.
• flexible-ethernet-services—Use flexible Ethernet services encapsulation when you want to configure multiple per-unit Ethernet encapsulations. This encapsulation type allows you to configure any combination of route, TCC, CCC, and VPLS encapsulations on a single physical port. Aggregated Ethernet bundles cannot use this encapsulation type.

Use the following guidelines to configure a VPLS interface:

• For encapsulation type vlan-vpls, VLAN IDs 1 through 511 are reserved for normal Ethernet VLANs, IDs 512 through 1023 are reserved for VPLS VLANs on Fast Ethernet interfaces, and IDs 512 through 4094 are reserved for VPLS VLANs on Gigabit Ethernet interfaces. For encapsulation type extended-vlan-vpls, all VLAN IDs from 1 through 1023 are valid for VPLS VLANs on Fast Ethernet interfaces, and all VLAN IDs from 1 through 4094 are valid for VPLS VLANs on Gigabit Ethernet interfaces. VLAN ID 0 is reserved for priority tagging. For encapsulation type flexible-ethernet-services, VLAN IDs from 1 through 511 are no longer reserved for normal VLANs.

To configure VPLS interface encapsulation for an Ethernet interface, include the encapsulation statement at the [edit interfaces interface-fpc/pic/port] hierarchy level and select ethernet-vpls, vlan-vpls, extended-vlan-vpls, flexible-ethernet-services or ether-vpls-over-atm-llc as the encapsulation type. If you select the VLAN VPLS encapsulation, also include the vlan-vpls statement at the [edit interfaces ethernet-interface-fpc/pic/port unit unit-number encapsulation] logical interface hierarchy level. When using either VLAN VPLS or extended VLAN VPLS encapsulations, include the vlan-tagging statement at the [edit interfaces ethernet-interface-fpc/pic/port] hierarchy level.

To configure VPLS interface encapsulation for an ATM2 IQ interface, include the encapsulation statement at the [edit interfaces at-fpc/pic/port] hierarchy level and select ether-vpls-over-atm-llc as the encapsulation type. To configure VPLS interface encapsulation for a gigabit Ethernet IQ interface or gigabit Ethernet PICs with small form-factor pluggable transceivers (SFPs), include the encapsulation statement at the [edit interfaces ge-fe/pic/port] hierarchy level and select flexible-ethernet-services as the encapsulation type.

Configuring a Signaling Protocol for VPLS

Like other Layer 2 VPNs, you must enable a VPLS instance to isolate VPLS traffic from other network traffic. An important element of a VPLS instance is the signaling protocol. You can configure BGP signaling, LDP signaling, or both BGP and LDP signaling in a VPLS instance:

• Configuring LDP Signaling for VPLS
• Configuring a VPLS Instance with BGP Signaling
• Configuring Interworking between BGP Signaling and LDP Signaling in VPLS Instances
• Configuring Multihoming on a VPLS Border Router

Configuring LDP Signaling for VPLS

To configure LDP signaling, you must first enable a VPLS instance to isolate VPLS traffic from other network traffic. To configure, include the instance-type vpls statement at the [edit routing-instances instance-name] hierarchy level. To configure LDP signaling within the instance, identify the virtual circuit with the vpls-id statement and specify the PE routers participating in the instance with the neighbor statement:

To fully enable LDP signaling on a PE in a VPLS instance, you must also enable ldp on the loopback interface of the router. To configure, include the interface lo0.0 statement at the [edit protocols ldp] hierarchy level:

For LDP signaling within a VPLS routing instance, the JUNOS software supports the following values only:

• FEC—FEC 128
• Control bit—0
• Ethernet pseudowire type—hexadecimal 0x0005

Configuring a VPLS Instance with BGP Signaling

You must enable a VPLS instance to isolate VPLS traffic from other network traffic. To configure, include the instance-type vpls statement at the [edit routing-instances instance-name] hierarchy level.

Within the instance, you can define the maximum number of sites that can participate in this VPLS instance, a local site name, and a local site identifier. To configure the maximum number of sites, include the site-range statement at the [edit routing-instances instance-name protocols vpls] hierarchy level. The maximum number of sites is 65,535.

Note: The site ID must be less than the site range. If you specify a site ID that is greater than the site range, your connections do not come up, even though the commit operation succeeds.

To configure a site name, include the site statement at the [edit routing-instances instance-name protocols vpls] hierarchy level. To configure the site ID, include the site-identifier statement at the [edit routing-instances instance-name protocols vpls site name] hierarchy level.

To complete the configuration, you must configure the Layer 2 VPN family for BGP by including the signaling statement at the [edit protocols bgp family l2vpn] hierarchy level:

Configuring Interworking between BGP Signaling and LDP Signaling in VPLS Instances

If you want to configure a VPLS instance with both BGP and LDP-signaled pseudowires, you must configure a VPLS border router. Without a VPLS border router, LDP-signaled PEs and BGP-signaled PEs will be unaware of one another and the VPLS instance will not be fully meshed.

Note: Interworking between BGP signaling and LDP signaling in VPLS instances is supported only on MX-series and M320 routers.

To enable interworking between BGP-signaled PE routers and LDP-signaled PE routers, you configure a border router to interconnect both sets of routers within the same VPLS routing instance. You also need to configure mesh groups on the border router to group the sets of PE routers that are fully meshed and which share the same signaling protocol, either BGP or LDP. You can configure multiple mesh groups to map each fully meshed LDP-signaled or BGP-signaled VPLS domain to a mesh group. In the data plane, the border router maintains a common MAC table used to forward traffic between the LDP-signaled and BGP-signaled mesh groups. When forwarding any VPLS traffic received over a PE router pseudowire, the border router ensures that traffic is not forwarded back to the PE routers, which are in same mesh group as the originating PE router.

There is always just one BGP mesh group in a VPLS instance, and it is created automatically when you configure BGP signaling for that instance. You can configure one or more LDP mesh groups. MX-series routers support up to 15 PE mesh groups (including the default BGP mesh group), and M-series and T-series routers support up to 127 PE mesh groups (including the default BGP mesh group).

In Figure 90, Routers PE1 and PE2 are in the LDP-signaled mesh group “LDP-1”. Routers PE3, PE4, and PE5 are in the LDP-signaled mesh group “LDP-2”. Routers PE6, PE7, and PE8 are in the BGP-signaled mesh group “BGP-default”. As you can see, the border router is acting as a traditional PE (by connecting to CEs) in addition to being a border router. Every router shown in the topology below is in the same VPLS instance, bgp-ldp-mesh1.

When router CE1 sends a frame whose destination MAC address is CE9, PE1 receives the frame and performs a MAC address lookup. The MAC address is not in the PE1 MAC table and so PE1 floods the frame to the other PEs in the LDP-1 mesh group (PE2 and Router B), which from the perspective of PE1, are the only members of the VPLS network. When Router B receives the data from PE1, it does not find the MAC address in its MAC table and so it floods the frame to PE3, PE4, PE5, PE6, PE7, and PE8, but not back to PE1 or PE2. The PE routers then perform a MAC table lookup and flood the data to their CE routers.

Figure 90: Topology for BGP/LDP Interworking in a VPLS Instance

In this topology, you configure routers PE6, PE7, and PE8 as you traditionally configure BGP-signaled VPLS routers. You configure routers PE1, PE2, PE3, PE4, and PE5 as you traditionally configure LDP-signaled VPLS routers. In addition, you create the mesh group LDP-1 for Routers PE1 and PE2 and mesh group LDP-2 for Routers PE3, PE4, and PE5 by including the mesh-group mesh-group-name statement at the [edit routing-instances routing-instance-name protocols vpls] hierarchy level.

Note: The border router can act as a normal PE in addition to being a border router and can support local CE-facing interfaces.

To enable interworking between VPLS mesh groups, configure the border router by including the site site-name statement at the [edit routing instances routing-instance-name protocols] hierarchy level:

Configure LDP signaling with the vpls-id and neighbor neighbor-id statements. You can configure mesh groups LDP-1 and LDP-2 by including the mesh-group statement at the [edit routing instances routing-instance-name protocols vpls vpls vpls-id and including the neighbor neighbor-id statement at the [edit routing-instances routing-instance-name protocols vpls mesh-group mesh-group-name] hierarchy level:

Note: When you configure BGP signaling to interoperate with LDP signaling in a VPLS network, the following features are not supported: Point-to-multipoint VPLS Integrated routing and bridging

Configuring Multihoming on a VPLS Border Router

Configuring multihoming on VPLS border routers ensures that if one border router is unreachable, BGP/LDP PE connectivity is maintained through the other VPLS border router. With multihoming, one border router is chosen as the designated forwarder for each mesh group. The designated forwarder is chosen through either the BGP or VPLS path-selection procedure. If the designated forwarder loses connectivity with a mesh group, the alternate border router then takes over as designated forwarder for that mesh group. A VPLS instance must be configured with BGP signaling in order for multihoming to work.

Figure 91 shows a simplified example of how multihoming works with VPLS border routers. In this example, B1 is the designated forwarder and B2 is the alternate forwarder. If CE1 wanted to send data to CE9, the data would travel from CE1 to PE1, which is part of the LDP-1 mesh group. PE1 would then flood the data to B1 (the designated forwarder) which would forward the data to PE2. It would not send the data to Router B2. PE2 would then send the data to its destination, CE9. If B1 lost connectivity with the LDP-1 mesh group then B2 would become the designated forwarder. In this case, PE1 would send the data through B2, not through B1.

Figure 91: Multihoming for Border Area Routers

You configure multihoming on border routers by including the site-identifier and multi-homing statement at the [edit routing-instances routing-instance-name protocols] hierarchy level. The designated forwarder and alternate forwarder must be configured with the same site identifier.

Router B1

Router B2

For more information on multihoming, see Option: Configuring VPLS Multihoming with BGP Signaling.

VPLS Options for BGP Signaling

The following configuration options are only available if the VPLS instance is configured for BGP signaling:

• Option: Selecting an LSP for the VPLS Routing Instance to Traverse
• Option: Configuring VPLS Multihoming with BGP Signaling
• Option: Configuring VPLS Traffic Flooding over a Point-to-Multipoint LSP
• Option: Configuring Automatic Site Selection

Option: Selecting an LSP for the VPLS Routing Instance to Traverse

If you have two or more equal-cost-path LSPs between your VPLS PE router sites, you can select an LSP over which the VPLS traffic will travel. To select an LSP for VPLS traffic, assign the VPLS instance to a BGP community, define a policy that directs community traffic over a specified LSP, and then apply the policy to the forwarding table.

To configure a BGP community, include the community community-name statement at the [edit policy-options] hierarchy level. Be sure to specify the vrf-export or vrf-target values from the VPLS routing instance as community identifiers with the members community-ids statement at the [edit policy-options community community-name] hierarchy level.

To create a policy that sends community traffic over a specific LSP, include the community community-name statement at the [edit policy-options policy-statement policy-name term term-name from] hierarchy level and the install-nexthop lsp lsp-name statement at the [edit policy-options policy-statement policy-name term term-name then] hierarchy level. To apply the policy to the forwarding table, include the export policy-name statement at the [edit routing-options forwarding-table] hierarchy level.

Option: Configuring VPLS Multihoming with BGP Signaling

With VPLS multihoming, you can connect multiple PE router interfaces to one customer site. This feature provides VPLS redundancy should a PE router or PE router interface fail.

To configure multihoming, you must configure the same site IDs on all PE routers and router interfaces that are connected to the same customer site, You must also specify on each PE router which interfaces are connected to the customer site. We recommend that you configure distinct route distinguishers for each multihomed router. Configuring distinct route distinguishers helps with faster convergence when the connection to a primary router goes down. It also requires the other PE routers to maintain additional state information.

To configure a route distinguisher, include the route-distinguisher statement at the [edit routing-instances instance-name] hierarchy level. To assign a site ID, include the site-identifier statement at the [edit routing-instances instance-name protocols vpls site name] hierarchy level. To specify the interfaces associated with a site, include the interface statement at the [edit routing-instances instance-name protocols vpls site name] hierarchy level.

To connect multiple PE routers to one customer site, you must configure multihoming on each PE router connected to that site. This will prevent routing loops should BGP connectivity fail. BGP automatically determines the primary and backup routers. Alternatively, you can statically configure a primary PE router and backup PE routers for a customer site by specifying the preference value. BGP uses preference values to determine routing paths.

Note: Multihoming relies on full BGP connectivity to all other PEs. Configure a dual router reflector topology to provide redundant PE-to-PE BGP connectivity.

To configure multihoming, include the multi-homing statement at the [edit routing-instances instance-name protocols vpls site name] hierarchy level. To configure preference value, include the preference-value statement at the [edit routing-instances instance-name protocols vpls site name] hierarchy level. You can configure the preference value as primary or backup, or you can specify a preference number. When specifying preference numbers, configure the primary interface with a preference value of 65,535 and any backup interfaces with a number from 1 to 65,534.

When multiple PE router interfaces on a single PE router are connected to one customer site, you must configure an active interface. All traffic will pass through the active interface unless this interface fails, in which case a backup interface will become the active interface.

To specify a multihomed interface as the primary interface for a site, include the active-interface statement at the [edit routing-instances instance-name protocols vpls site name] hierarchy level. The interface that you specify is called the primary interface. If the primary interface goes down, an alternate interface becomes the active interface. Once the primary interface comes back up, the primary interface becomes the active interface once again and the alternate interface becomes inactive.

If you do not want to specify a primary multihomed interface, you can use the any option. With the any option, the router dynamically chooses an active interface. If the active interface goes down, an alternate interface becomes the active interface. Once the down interface comes back up, it stays inactive.

If no active interfaces are configured at the site level, it is assumed that all traffic for a VPLS site travels through a single, nonmultihomed PE router.

Note: If you add a direct connection between CE devices that are multihomed to the same VPLS site on different PE routers, traffic loops and loss of connectivity might occur. We do not recommend this topology.

The following example shows a multihoming configuration with two PE routers that are connected to a single customer site. Note in the configuration that PE1 is the primary router and PE2 is the backup router.

Router PE1

Router PE2

The following example shows a multihoming configuration with one PE router with multiple interfaces that are connected to a single customer site.

Router PE3

For more information on VPLS multihoming, see the JUNOS VPNs Configuration Guide.

Option: Configuring VPLS Traffic Flooding over a Point-to-Multipoint LSP

In each VPLS routing instance, you can configure a dedicated point-to-multipoint LSP to carry all unknown unicast, broadcast, and multicast traffic. Enabling this feature increases the efficiency of your network because duplicate copies of flooded traffic do not have to be created for each PE router in the VPLS routing instance. Figure 92 shows how flooded traffic reaches PE routers in a VPLS routing instance when a point-to-multipoint LSP is not configured for flooding. Figure 93 shows an example of a VPLS routing instance configured with point-to-multipoint LSP flooding.

Note: You cannot configure point-to-multipoint LSP flooding if your VPLS network is configured for interoperability between BGP and LDP signaling.

Figure 92: Traditional Flooding in a VPLS Routing Instance

Figure 93: VPLS Routing Instance with Point-to-Multipoint LSP Flooding

You have three options when configuring a point-to-multipoint LSP for flooding:

• Static point-to-multipoint LSP—Configure this option to control which path each PE sub-LSP takes. When using this option, ensure that all PEs within the VPLS routing instance are part of the static point-to-multipoint LSP. When you add PEs to the VPLS routing instance, you must configure a sub-LSP for the new PE and add the sub-LSP to the static point-to-multipoint LSP. To configure a static point-to-multipoint LSP, include the label-switched-path path-name statement at the [edit protocols mpls] hierarchy level.
• Dynamic point-to-multipoint LSP with a preconfigured template—Configure this option to create a dynamic point-to-multipoint LSP with specific parameters such as link protection and optimized time. With this option, newly added PEs are automatically added to the point-to-multipoint LSP. To configure the preconfigured template, include the template statement at the [edit protocols mpls label-switch-path path-name] hierarchy level.
• Dynamic point-to-multipoint LSP with a default template—Configure this option to automatically create a dynamic point-to-multipoint LSP with default parameters. With this option, newly added PEs are automatically added to the point-to-multipoint LSP. To configure a default template, include the default-template statement at the [edit routing-instances routing-instance-name provider-tunnel rsvp-te label-switched-path-template] hierarchy level.

To define the parameters for a static point-to-multipoint LSP, include the label-switched-path path-name statement at the [edit protocols mpls] hierarchy level:

To add a new PE router to the static p2mp LSP, include the label-switched-path sub-path-name statement at the [edit protocols mpls] hierarchy level:

For more information on configuring static and dynamic point-to-multipoint LSPs, see the JUNOS MPLS Applications Configuration Guide.

To enable this feature, configure either the static or label-switched-path-template options for the rsvp-te statement at the [edit routing-instance routing-instance-name provider-tunnel] hierarchy level:

To verify your work, enter the show vpls connection extensive command:

Option: Configuring Automatic Site Selection

You can configure BGP-signaled VPLS instances to automatically specify the site IDs for the routers participating in the VPLS domain. Site IDs help to minimize label usage in VPLS instances with numerous PE routers.

The automatic-site-id statement includes the following options:

• startup-wait-time—Time to wait at startup to receive all VPLS information for configured route targets from other PE routers.
• new-site-wait-time—Time to wait to receive VPLS information from a newly configured routing instance or a new site. Effectively, it is the time to wait before a site makes an attempt to locate an unused site ID for its claim advertisement.
• collision-detect-time—Time to wait after issuing a claim advertisement before the PE router can start using the site ID if it does not receive a competing claim. If the PE router receives a competing claim within this time interval, it runs a collision resolution procedure. Explicitly configured site IDs always take precedence over automatically generated site IDs.
• reclaim-wait-time—Time to wait before attempting to claim a site ID after a collision. There are default values for all of these options, so they do not need to be explicitly configured.

To configure VPLS automatic site ID, include the automatic-site-id statement at the [edit routing-instances routing-instance-name protocols vpls site site-name] hierarchy level:

VPLS Options for BGP and LDP Signaling

This section describes the following options that are available with both BGP and LDP signaling:

• Option: Configuring VPLS to Use LSI Interfaces
• Option: Configuring Tunnel Services on MX-series Routers
• Optional: Configuring Integrated Routing and Bridging in a VPLS Instance (MX-series Routers Only)
• Optional: Configuring VLAN IDs in a VPLS Instance (MX-series Routers Only)
• Option: Applying VPLS Policers and Filters
• Option: Enabling VPLS Class of Service
• Option: Enabling VPLS Graceful Restart
• Option: Clearing MAC Addresses and Modifying the VPLS Table Timeout Interval
• Option: Configuring VPLS Interinstance Bridging and Routing
• Option: Selecting Interfaces to Process VPLS Traffic
• Option: Limiting the Number of MAC Addresses Learned on an Interface
• Option: Optimizing VPLS Traffic Flows
• Option: Aggregated Interfaces for VPLS
• Option: Configuring VPLS Graceful Routing Engine Switchover
• Option: Configuring VPLS Nonstop Active Routing
• Option: Configuring the Spanning Tree Protocol and VPLS on MX-series Routers
• Filtering Layer 2 Packets in a VPLS Instance (MX-series Routers Only)

Option: Configuring VPLS to Use LSI Interfaces

On M-series and T-series routing platforms, VPLS uses tunnel-based PICs to create virtual ports on vt interfaces. If you do not have a tunnel-based PIC installed on your M-series or T-series routing platform, you can still configure VPLS by using label-switched interfaces (LSIs) to support the virtual ports. Use of LSI interfaces requires the use of Ethernet-based PICs installed in an Enhanced FPC.

Note: On MX-series routers, when using VPLS with an LSI interface, for traffic flowing from the core to the egress CE, classification does not work on the egress PE.

To use LSI interfaces for VPLS instead of vt interfaces, include the no-tunnel-services statement at the [edit routing-instances instance-name protocols vpls] hierarchy level.

Note: The following interface types do not support the use of LSI interfaces with VPLS: Aggregated SONET/SDH interfaces (cannot be used as the core-facing interface) Channelized interfaces (cannot be used as the core-facing interface) ATM1 interfaces

Option: Configuring Tunnel Services on MX-series Routers

MX-series routers use Dense Port Concentrators (DPCs) with built-in physical ports, which means that you do not insert PICs on the router. Instead, you configure tunnel interfaces on one of the four Packet Forwarding Engines (PFEs) that are on each DPC.

To create tunnel interfaces on a MX-series router, include the tunnel-services statement at the [edit chassis fpc slot-number pic number] hierarchy level. To configure the bandwidth for a tunnel interface, include the bandwidth statement at the [edit chassis fpc slot-number pic number] hierarchy level.

The following example shows a tunnel interface with 1 Gbps of bandwidth configured on PFE 1 of the DPC installed in slot 4 of an MX-series router:

Once you have configured a tunnel interface on a PFE, you can treat this interface as a standard tunnel interface and proceed with a standard VPLS configuration. For more information, see the JUNOS System Basics Configuration Guide.

Optional: Configuring Integrated Routing and Bridging in a VPLS Instance (MX-series Routers Only)

Integrated routing and bridging (IRB) over VPLS cannot be used in conjunction with the vlan-id all statement. One or more Layer 2 logical interfaces must be configured inside the instance in order for IRB to function properly.

To configure IRB within a VPLS instance, include the routing-interface irb-interface-name statement at the [edit routing-instances routing-instance-name instance-type vpls] hierarchy level:

Optional: Configuring VLAN IDs in a VPLS Instance (MX-series Routers Only)

You can configure VLAN identifiers for a VPLS instance in the following ways:

• By using the input-vlan-map and the output-vlan-map statements at the [edit interfaces] hierarchy level. For more information, see the JUNOS Network Interfaces Configuration Guide and JUNOS Class of Service Configuration Guide.
• By using the vlan-id or vlan-tags statements at the [edit routing-instances routing-instance-name instance-type vpls] hierarchy level.

The vlan-id and vlan-tags statements are used to perform the following functions:

• Translate, or normalize, the VLAN tags of received packets received into a learn VLAN identifier.
• Create multiple learning domains that each contain a learn VLAN identifier. A learning domain is a MAC address database to which MAC addresses are added based on the learn VLAN identifier.

For more information about how VLAN tags are processed and translated, see the JUNOS MX-series Layer 2 Configuration Guide.

To configure VLAN identifiers for a VPLS instance, include the vlan-id or vlan-tags statement at the [edit routing-instances routing-instance-name instance-type vpls] hierarchy level.

Note: You cannot configure VLAN mapping using the input-vlan-map and output-vlan-map statements if you configure a learn VLAN identifier for a VPLS instance using the vlan-id or vlan-tags statements.

Option: Applying VPLS Policers and Filters

You can configure filters, policers, and broadcast/unknown filters to determine which kind of traffic is allowed into and out of a VPLS domain. You can apply these filters and policers to CE-facing interfaces only.

Note: Keep the following rules in mind when configuring filters on an MX-series router: If an IRB interface is configured as part of a VPLS routing instance, VPLS filters might not filter packets that are destined to the IRB interface. This can be configured by installing filters that match Layer 3 fields for the the IRB interface. If you apply a firewall filter to discard a source MAC address, the MAC address is not deleted from the MAC address table.

VPLS Policers

To process traffic as it enters a VPLS domain, you can define a firewall policer and apply it to the input interface. To define policer characteristics for incoming VPLS traffic, include the bandwidth-limit and burst-size-limit statements at the [edit firewall policer policer-name if-exceeding] hierarchy level. Then, specify statements to implement the desired action (for example, discard) for the policed traffic at the [edit firewall policer policer-name then] hierarchy level. To apply the policer to a CE-facing interface, include the input or output statements and the name of the policer at the [edit interfaces interface-name unit unit-number family vpls policer] hierarchy level.

VPLS Filters

To process traffic as it exits a VPLS domain, you can define a firewall filter and apply it to the output interface. To configure match conditions for a firewall filter, include the interface-group, source-mac-address, destination-mac-address, ethernet-type, or vlan-ethernet-type statements at the [edit firewall family vpls filter filter-name term term-name from] hierarchy level. Then, implement the desired action (for example, discard) for the traffic at the [edit firewall family vpls filter filter-name term term-name then] hierarchy level. To apply the filter to a CE-facing interface, include the input, output, or group statements at the [edit interfaces interface-name unit unit-number family vpls filter] hierarchy level.

Note: Output filters do not work for broadcast, multicast, and unknown unicast traffic.

VPLS Broadcast and Unknown Filters

To restrict the flow of broadcast and unknown unicast packets into a VPLS domain, you must create a firewall filter and apply the filter to one of the forwarding tables of the VPLS routing instance. When you apply a filter in this way, the filter processes traffic from all interfaces in the instance, including vt interfaces. To configure match conditions for a VPLS-based firewall filter, include the source-mac-address, destination-mac-address, interface-group, ethernet-type, or vlan-ethernet-type statements at the [edit firewall family vpls filter filter-name term term-name from] hierarchy level. Then, specify statements to activate the desired action (for example, discard) for the matched packets at the [edit firewall family vpls filter filter-name term term-name then] hierarchy level.

To apply the filter to the broadcast and unknown unicast table of a VPLS routing instance, include the input statement and the name of the filter at the [edit routing-instances instance-name forwarding-options family vpls flood] hierarchy level. To apply the filter to the destination MAC address table of a VPLS routing instance, include the input statement and the name of the filter at the [edit routing-instances instance-name forwarding-options family vpls filter] hierarchy level.

When you configure VPLS, a priority filter for Spanning Tree Protocol (STP) bridge protocol data units (BPDUs) is enabled by default. This BPDU filter matches on the well-known STP MAC address of 01:80:c2:00:00:00/24 and applies high priority to this traffic.

For more information on VPLS policers and filters, see the JUNOS Policy Framework Configuration Guide and the JUNOS VPNs Configuration Guide.

Option: Enabling VPLS Class of Service

For JUNOS Release 6.2 or later, you can configure class of service (CoS) for all interfaces in the VPLS domain. CoS information is sent across the MPLS backbone and is preserved for all VPLS traffic processed by local interfaces, virtual ports, and remote interfaces.

For more information on configuring CoS, see the JUNOS Class of Service Configuration Guide.

Option: Enabling VPLS Graceful Restart

VPLS graceful restart allows you to continue forwarding VPLS traffic across the core MPLS network even if one of the routers in the forwarding path restarts. Graceful restart for VPLS functions the same way as Layer 2 VPN graceful restart. To configure graceful restart for VPLS, include the graceful-restart statement at the [edit routing-options] hierarchy level on all PE and core routers.

For more information on graceful restart, see the JUNOS High Availability Configuration Guide.

Option: Clearing MAC Addresses and Modifying the VPLS Table Timeout Interval

You can fine-tune your VPLS domain by clearing MAC address entries from the VPLS table or modifying the default timeout interval for the VPLS table.

Note: On MX-series routers running JUNOS Release 8.4 and later, you can set the expiration time of entries in the MAC table only for the entire router, not for specific VPLS routing instances. To set the expiration for the entire router, include the mac-table-aging-time seconds statement at the [edit protocols l2-learning] hierarchy level. Do not include the mac-table-aging-time statement at the [edit routing-instances routing-instance-name protocols vpls] hierarchy level on MX-series routers running JUNOS Release 8.4 and later.

To clear all MAC address entries from the VPLS table, issue the clear vpls mac-address command. Add the logical-system logical-system-name option to clear entries within a logical system and include the instance instance-name option to clear entries in a specific VPLS instance. Use the mac-address option to remove individual MAC addresses.

To configure the VPLS table timeout interval, include the mac-table-aging-time statement at the [edit routing-instances instance-name protocols vpls] hierarchy level. The default interval is 300 seconds, with a minimum of 10 seconds and a maximum of 1 million seconds. As a general rule, you can configure longer values for small, stable VPLS networks and shorter values for large, dynamic VPLS networks. If no traffic is received for a specific MAC, M-series and T-series routers wait one additional interval before automatically clearing MAC address entries from the VPLS table. MX-series routers do not wait this interval.

Option: Configuring VPLS Interinstance Bridging and Routing

To deliver interinstance traffic between two or more VPLS instances, or between a VPLS instance and a Layer 3 VPN routing instance, you must use a logical tunnel interface. Originally designed to interconnect logical systems, the logical tunnel interface acts as a point-to-point connection between instances. A logical tunnel interface can be generated by a Tunnel Services PIC installed on an Enhanced FPC in your routing platform, an integrated Adaptive Services Module installed in an M7i router, or a tunnel services interface configured on MX-series routers. To configure a logical tunnel interface, include the lt-fpc/pic/0 statement at the [edit interfaces] hierarchy level. Keep in mind these rules when you connect instances:

• You need to configure both endpoints of the logical tunnel. Configure the first logical tunnel interface in the VPLS instance and the second within the instance you want to interconnect to the VPLS domain.
• Choose one of several interface encapsulation types for your logical tunnel interface peers. Your choices are Ethernet, Ethernet circuit cross-connect (CCC), Ethernet VPLS, Frame Relay, Frame Relay CCC, VLAN, VLAN CCC, and VLAN VPLS. Include one of these choices with the encapsulation statement at the [edit interfaces lt-fpc/pic/0 unit unit-number] hierarchy level.
• Depending on the encapsulation type you select, specify a corresponding data-link connection identifier (DLCI) number for Frame Relay or a VLAN identifier for VLAN encapsulations on your logical tunnel interface peers. To configure, include the dlci or vlan-id statement at the [edit interfaces lt-fpc/pic/0 unit unit-number] hierarchy level.
• Your choice of protocol family for the logical tunnel interface also is determined by your selection of an encapsulation type. For Ethernet VPLS and VLAN VPLS, family vpls is assigned by default. For all other Ethernet and VLAN encapsulation types, include the mpls or inet statement at the [edit interfaces lt-fpc/pic/0 unit unit-number family] hierarchy level. For Frame Relay encapsulation types, you can configure any of the available protocol families: ccc, inet, inet6, iso, mpls, or tcc.
• Be sure to match the logical interface unit numbers of the peering logical tunnel interfaces. To configure, include the peer-unit statement at the [edit interfaces lt-fpc/pic/0 unit unit-number] hierarchy level.

  [edit]

  interfaces {

  lt-fpc/pic/0 {

  unit unit-number {

  encapsulation (ethernet | ethernet-ccc | ethernet-vpls | frame-relay |
  frame-relay-ccc | vlan | vlan-ccc | vlan-vpls);

  peer-unit number; # The logical unit number of the peering lt interface.

  dlci dlci-number;

  vlan-id vlan-number;

  family (ccc | inet | inet6 | iso | mpls | tcc);

  }

  }

  }

  routing-instances {

  vpls-instance-name {

  interface ge-fpc/pic/port.unit-number;

  interface lt-0/0/0.1;

  ...

  second-instance-name {

  interface at-fpc pic/port.unit-number;

  interface lt-0/0/0.2;

  ...

  }

  }

  }

Option: Selecting Interfaces to Process VPLS Traffic

On M-series and T-series routing platforms, the PICs that can create VPLS virtual ports dynamically from vt interfaces include the Tunnel Services PIC, the Link Services PIC, and the Adaptive Services PIC. On MX-series routers, logical tunnel interfaces configured by including the tunnel-services statement at the [edit chassis fpc slot-number pic number] hierarchy level can create VPLS virtual ports dynamically from vt interfaces.

By default, the JUNOS software automatically and randomly selects vt interfaces to act as VPLS virtual ports in a round-robin fashion. However, if your routing platform contains two or more of these tunnel-enabled interfaces, you can manually select which interfaces process traffic for each VPLS domain.

You can select an interface to be the primary device responsible for VPLS traffic processing. You can also select a group of interfaces to share responsibility for VPLS traffic processing. When the primary interface is operating normally, it handles all VPLS-related tasks. If the primary device is not available, any interfaces included in the VPLS interface group assume responsibility.

To select an interface to be the primary device responsible for VPLS traffic processing, include the primary statement at the [edit routing-instances instance-name protocols vpls tunnel-services] hierarchy level. To select a group of interfaces to share responsibility for VPLS traffic processing, include the devices statement at the [edit routing-instances instance-name protocols vpls tunnel-services] hierarchy level.

Option: Limiting the Number of MAC Addresses Learned on an Interface

There are three main levels where you can configure MAC address limits:

• interface-mac-limit—This statement allows you to specify a limit for MAC addresses at an interface level. For VPLS, you can include the interface-mac-limit statement at the [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls site site-name interfaces interface-name], [edit routing-instances routing-instance-name protocols vpls], or [edit routing-instances routing-instance-name protocols vpls site site-name interfaces interface-name] hierarchy level. For MX-series routers only, you can specify what the router does with additional MACs once the MAC limit is reached. The default behavior is for the router to flood the MACs, but you can alternatively include the packet-action drop option to have the router drop the MACs. The default MAC address table size for each interface is 1024 addresses.
• mac-table-size—This statement allows you to specify a limit for MAC addresses at a domain level. For VPLS, you can include the mac-table-size statement at the [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls] or [edit routing-instances routing-instance-name protocols vpls] hierarchy level. The default MAC address table size for each domain is 5120 addresses.
• global-mac-limit (MX-series routers only)—This statement allows you to specify a limit for MAC addresses for all interfaces and all domains for the entire router. You can include the global-mac-limit statement at the [edit protocols l2-learning] hierarchy level. The default MAC address table size for the entire system is 393,215 addresses.

Note: If you manually configure a MAC address limit, you must ensure that values for interface limits (such as the interface-mac-limit) are set lower than domain limits (such as mac-table-size), and the domain limits are set lower than global limits (such as global-mac-limit). If a value for a more specific limit is set higher than a more global limit, the commit will fail.

The range of values for the interface-mac-limit statement is 16 through 65,536. The output of the show vpls statistics command displays the results of configuring interface-level MAC address limitations.

Option: Optimizing VPLS Traffic Flows

To improve the performance of VPLS traffic processing in your routing platform, you can implement the following features:

• To optimize VPLS traffic flows across multiple paths, you can enable per-packet load balancing. To configure, include the load-balance per-packet statement at the [edit policy-options policy-statement policy-name term term-name then] hierarchy level and apply the policy to the forwarding table with the export policy-name statement at the [edit routing-options forwarding-table] hierarchy level.
• To optimize hashing of source and destination MAC addresses within VPLS traffic flows, include the source-mac and destination-mac statements at the [edit forwarding-options hash-key family multiservice] hierarchy level.

For more information on load balancing and hash keys, see the JUNOS Policy Framework Configuration Guide.

Option: Aggregated Interfaces for VPLS

You can configure aggregated Ethernet interfaces between CE devices and PE routers for VPLS routing instances. Traffic is load balanced across all of the links in the aggregated interface. If one or more links in the aggregated interface fails, the traffic is switched to the remaining links.

In the example below, 0 is the interface instance number that completes the link association. This number can be from 0 through 127, for a total of 128 aggregated interfaces. The VPLS encapsulation types supported on aggregated Ethernet interfaces are ethernet-vpls, vlan-vpls, or extended-vlan-vpls.

The aggregated Ethernet interface must also be configured for a VPLS routing instance. Use the standard VPLS routing instance configuration on aggregated Ethernet interfaces.

For more information on how to configure aggregated Ethernet interfaces, see the JUNOS Network Interfaces Configuration Guide.

Option: Configuring VPLS Graceful Routing Engine Switchover

Graceful Routing Engine switchover (GRES) allows a routing platform with dual Routing Engines to switch over from a master Routing Engine to a backup Routing Engine without causing an interruption to packet forwarding. Graceful Routing Engine switchover is supported with VPLS, meaning that should the master Routing Engine go down, the router can switch to the backup Routing Engine without affecting VPLS traffic.

To configure graceful Routing Engine switchover, include the graceful-switchover statement at the [edit chassis redundancy] hierarchy level. To disable graceful Routing Engine switchover, remove the graceful-switchover statement at the [edit chassis redundancy] hierarchy level.

Option: Configuring VPLS Nonstop Active Routing

Nonstop active routing (NSR) enables a routing platform with redundant Routing Engines to switch from a primary Routing Engine to a backup Routing Engine without alerting peer nodes that a change has occurred. Nonstop active routing uses the same infrastructure as graceful Routing Engine switchover to preserve interface and kernel information. However, nonstop active routing also preserves routing information and protocol sessions by running the routing protocol process (rpd) on both Routing Engines. The logical interface, next-hop router, and both advertised and received labels are preserved. In addition, nonstop active routing preserves TCP connections maintained in the kernel.

Enabling Nonstop Active Routing

Nonstop active routing requires you to configure graceful Routing Engine switchover (GRES). To enable graceful Routing Engine switchover, include the graceful-switchover statement at the [edit chassis redundancy] hierarchy level:

By default, nonstop active routing is disabled. To enable nonstop active routing, include the nonstop-routing statement at the [edit routing-options] hierarchy level:

To disable nonstop active routing, remove the nonstop-routing statement from the [edit routing-options] hierarchy level.

To enable the routing platform to switch over to the backup Routing Engine when the routing protocol process (rpd) fails rapidly three times in succession, include the other-routing-engine statement at the [edit system processes routing failover] hierarchy level.

For more information about the other-routing-engine statement, see the JUNOS System Basics Configuration Guide.

Synchronizing the Routing Engine Configuration

When you configure nonstop active routing, you must also include the commit synchronize statement at the [edit system] hierarchy level so that configuration changes are synchronized on both Routing Engines:

If you try to commit the nonstop active routing configuration without including the commit synchronize statement, the commit operation fails.

If you issue the commit synchronize command at the [edit] hierarchy level on the backup Routing Engine, the JUNOS system software displays a warning and commits the candidate configuration.

Note: A newly inserted backup Routing Engine automatically synchronizes its configuration with the master Routing Engine configuration. When you configure nonstop active routing, you can bring the backup Routing Engine online after the master Routing Engine is already running. There is no requirement to start the two Routing Engines simultaneously.

Verifying VPLS Nonstop Active Routing Operation

To see whether or not nonstop active routing is enabled, issue the show task replication command.

Note: You must issue the show task replication command on the master Routing Engine. This command is not supported on the backup Routing Engine.

For more information on this command, see the JUNOS System Basics and Services Command Reference.

Tracing VPLS Nonstop Active Routing Synchronization Events

To trace the label and logical interface association that VPLS receives from the kernel replication state, include the nsr-synchronization statement at the [edit routing-options traceoptions flag] hierarchy level. This flag also traces the Layer 2 VPN signaling state replicated from routes advertised by BGP.

Example: Configuring Nonstop Active Routing

The following example enables graceful Routing Engine switchover, nonstop active routing, and nonstop active routing trace options for VPLS.

Option: Configuring the Spanning Tree Protocol and VPLS on MX-series Routers

If multiple routers on a customer site are connected the same PE, you should configure a version of the Spanning Tree Protocol on that PE. To configure RSTP or MSTP and VPLS simultaneously, include the rstp or mstp statement at the [edit instance-type layer2–control] hierarchy level:

The Per-VLAN Spanning Tree (PVST) protocol maintains a separate spanning-tree instance for each VLAN. To enable PVST for a specific VLAN ID, there should be a VPLS instance with that VLAN ID and all of the logical interfaces assigned to that instance should have the same matching VLAN ID. To configure PVST with VPLS, include the vstp statement at the [edit instance-type layer2-control] hierarchy level:

If you only want STP to run on a device, you can configure STP by including the force-version stp statement at the [edit protocols rstp] or [edit protocols vstp] hierarchy level:

For more information about the Spanning Tree Protocol (VSTP, MSTP, RSTP, or STP), see the MX-series Solutions Guide and the JUNOS Routing Protocols Configuration Guide.

Filtering Layer 2 Packets in a VPLS Instance (MX-series Routers Only)

You can match the learn-vlan-id, user-vlan-id, and traffic-type terms for a VPLS instance on the MX-series platform. Packets entering or exiting the VPLS instance have a single VLAN tag. This VLAN tag is the same as what was received from the network. This VLAN tag corresponds to the one VLAN ID on a singly tagged logical interface or inner VLAN tag for the doubly tagged logical interface. The VLAN ID is used to qualify learned MAC addresses.

To configure a firewall filter for a VPLS instance, specify the conditions that the packet must match at the [edit firewall family vpls filter filter-name term term-name from] hierarchy level. To apply a firewall filter to a VPLS routing instance, include the input filter-name statement at [edit routing-instances routing-instance-name forwarding-options family vpls filter] hierarchy level. For more information, see the JUNOS Policy Framework Configuration Guide.