Hide Navigation Pane
Show Navigation Pane
Feedback
Download
SHA1
Virtual Private LAN Service on MX Series Routers Frequently Asked Questions
This section presents frequently-asked questions and answers related to VPLS configurations on Juniper Networks MX Series routers.
What are the Juniper Networks solutions for Metro Ethernet Forum (MEF) 6.1 Ethernet services definitions, including Ethernet private line, Ethernet virtual private line, Ethernet LAN, Ethernet lines, and Ethernet trees?
- Ethernet private line (EPL) and Ethernet virtual private line (EVPL) are emulated by Juniper Networks Layer 2 circuit and Layer 2 VPN configurations.
- Ethernet LAN (E-LAN) is emulated by any Juniper Networks VPLS configuration solution.
- Ethernet lines (E-Line) service is emulated by using Juniper Networks Layer 2 circuit service configuration. The encapsulation type for the E-Line can be full Ethernet or only VLAN.
- Ethernet trees (E-Tree) service can be built using point-to-multipoint, or a more sophisticated implementation can be built using hub-and-spoke communities with BGP VPLS.
How can I prevent the receipt of hub routes on a directly-connected customer premises equipment spoke interface in a hub provider edge router? Can a core-facing statement be used for this purpose on MX Series routers?
To prevent spokes from talking to each other, spoke provider edge (PE) routers export different VPN routing and forwarding (VRF) targets, and import only the hub VRF targets. Using this method, spokes only exchange routes with the hub, however, the hub PE router imports all of the spoke VRF route targets. For example, assume that an interface residing on the hub PE router needs to connect with a spoke customer provider edge (CPE) router. When this spoke interface is added to the hub routing instance, it will receive hub routes, which is not expected in a hub-and-spoke topology.
A solution is to configure a core-facing statement under the spoke interface on the hub PE router. This will prevent route advertisements from the hub PE router from going to the directly-connected spoke CPE. Use the following configuration command to have broadcasts go only to the hub CE from the spoke CE attached to the hub PE router.
How does qualified learning for virtual private LAN service operate? On which Juniper Networks platforms is it supported?
Figure 1 illustrates topology examples used to answer this question.
Figure 1: VPLS Learning Examples
Traffic type and direction: unknown unicast from CE1 VLAN700 to CE2 VLAN700
In this example, first assume that Router PE2 is a Juniper Networks M Series Multiservice Edge Router. M Series routers do not process VLAN information, so the packets from Router CE1 are flooded out from Router PE2 to all ports and VLANs, not only to those connected to VLAN700. You can use the monitor interface and show interface queue commands to verify this behavior.
If, however, Router PE2 is a Juniper Networks MX Series 3D Universal Edge Router, the packets from Router CE1 for VLAN700 are flooded from Router PE2 only on the ports connected to VLAN700. This behavior is VPLS qualified learning. MX Series routers perform qualified lookups and qualified learning.
When one of the sites goes down in a single VPLS instance, why is there traffic loss on another site? How is a VPLS label block allocated when multiple sites are configured in a single VPLS instance?
Figure 2 displays the topology used to illustrate this scenario. In it, a PE router has several site IDs configured within the same VPLS instance. The PE router advertises a separate label block for each of these site IDs to the remote PE routers. The label block associated with the lowest site ID number is selected to build pseudowires between the local PE router and the remote PE routers. You can use the show vpls connections command to verify that the pseudowire that has "Up" status between two PE routers is associated with the lowest site IDs on both PE routers.
Figure 2: VPLS Label Block Allocation
Router PE1 derives its labels from the label block associated with Site 2, which comes through Router PE2.
If Site 2 goes down and Site 3 remains operational, Router PE1 changes its label allocation to use the label block associated with Site 3. Consequently, a failure of Site 2 causes a loss of traffic between Site 1 and Site 3.
Additionally, traffic disruption can occur if Site 3 is provisioned initially, and Site 2 is provisioned at a later time. When Site 2 comes up, this causes a change in the labels used by Router PE1 for both Sites 2 and 3, causing traffic disruption for Site 3.
Solution: Router PE1 only programs its forwarding table to push labels that are advertised by a Site 2 label block. The forwarding table for Router PE2 expects traffic to come with the label advertised in a Site 2 label block. Neither Router PE1 nor Router PE2 has programmed their forwarding tables to use labels from a Site 3 label block, consequently, there will be traffic loss if Site 2 goes down. Traffic will resume after Router PE1 and Router PE2 program their forwarding tables to use labels from a Site 3 label block.
This is the intended behavior and is working as designed. For more information about VPLS label blocks, see Technology Overview Understanding VPLS Label Blocks Operation.
How can I control the behavior of VPLS class-based forwarding with multiple label-switched paths (LSPs) when one LSP goes down?
The following configuration is an example in which class-based forwarding is applied to a VPLS. It works as expected when both RSVP LSPs are up. If one of the LSPs goes down, all traffic uses the remaining LSP. For example, if the to-brg2-private LSP or tunnel goes down, all of the PRIVATE class traffic then uses the REALTIME tunnel.
To change this behavior, apply a filter that only allows traffic of the specific forwarding class on each LSP:
What is the maximum number of VPLS instances supported on MX Series routers?
The maximum number of VPLS instances supported on MX Series routers is 8,000.
This number is derived as follows: the logical interface limit on an MX Series router is 64,000. In BGP VPLS, the default label block size is eight, which provides eight pseudowires per VPLS. Divide the number of logical interfaces by the number of pseudowires to get the maximum number of VPLS instances supported: 64,000/8 = 8,000.
In Junos OS 10.0 and later, use the label-block-size size statement to configure VPLS label block size as 2, 4, 8, or 16. If the block size is increased, the number of VPLS instances can be increased. With LDP VPLS, there is no concept of label block, so the number of logical interfaces used is based on the number of sites attached to the VPLS.
Theoretically, if there are fewer than eight sites per LDP VPLS, that network could scale to 8,000 logical interfaces and greater. However, the qualified tested maximum number is 8,000.
What is the maximum number of sites supported per VPLS instance?
Currently, the flooding in VPLS is limited to 4,000 sites per VPLS mesh group. MX Series routers support 14 user-defined mesh groups. Therefore, the maximum number of sites possible is 56,000 (4000 x 14 = 56,000).
How many Layer 2 circuits can be terminated into a single VRF instance?
On an MX Series router, 48 Layer 2 circuits can be terminated into a single VRF, per each tunnel PIC.
The limiting factor is the way MAC addresses are assigned to logical tunnel (lt) interface units. On an MX Series router there are 1984 MAC addresses on the EEPROM. This is statically divided by the number of slots (12) and PICs (4) to determine there are 48 per PIC. That number is the same on each platform although MAC space might be smaller.
Additional limitations are presented by the availability of bandwidth and the lack of resiliency because these solutions are bound to a tunnel PIC. If the dense port concentrator (DPC) associated with the tunnel goes down, all Layer 2 circuits are gone.
What are the Junos OS solutions for terminating Martini Layer 2 circuits into VPLS?
In Junos OS, Martini Layer 2 circuits can be terminated into VPLS by using logical tunnel (lt) interfaces. In Junos OS 9.2 and later, this can also be done without a tunnel PIC by using mesh groups.
What are the label-switched interface (LSI) label value assignments for different services?
VPLS uses a dynamic virtual tunnel logical interface on a tunnel PIC to model traffic from a remote PE router site in a VPLS domain. All traffic coming from the remote site is treated as if it is coming over the virtual port that represents this remote site, for the purposes of Ethernet flooding, forwarding, and learning.
In this approach, an MPLS lookup based on the inner VPN label is done on a PE router in the CF chip or R-chip. The label is stripped and the Layer 2 Ethernet frame it contained is forwarded to a tunnel PIC. The tunnel PIC loops the packet back, then a lookup is performed based on Ethernet MAC addresses.
Drawbacks to this approach include creating a bottleneck at the tunnel PIC and requiring the PE router to perform two lookups.
By default, VPLS uses a tunnel PIC. If the no-tunnel-services statement is configured under a VPLS instance, it uses an LSI and does not require a tunnel PIC.
The current label numbering assignment is listed in Table 1.
Table 1: Label Numbering Assignments
Services | Label Values |
|---|---|
Reserved | 0 - 15 |
LSI VPN | 16 - 2047 |
LSP VPLS | 2048 - 4095 |
Unassigned | 4096 - 10,000 |
Static LSP | 10,000-99,999 |
Global | 100000-799999 |
Block Allocation | 800000-899999 |
Per Intf | 900000-999999 |
I have a non-MX Series router for VPLS. Is there an alternative to the MX-specific no-local-switching statement that I can use in this configuration?
Yes, as an alternative to the no-local-switching statement, you can configure the CE interfaces in single mesh groups on M Series or T Series routers.
The no-local-switching statement completely blocks the CE-to-CE communication in a multihomed VPLS instance. If the PE router has multiple CE interfaces, the CE routers are not able to switch traffic among themselves. This saves bandwidth to the CE link by not broadcasting unwanted flooded traffic.
Sample Configuration
user@host# show vpls connectionsLayer-2 VPN connections: Legend for connection status (St) EI -- encapsulation invalid NC -- interface encapsulation not CCC/TCC/VPLS EM -- encapsulation mismatch WE -- interface and instance encaps not same VC-Dn -- Virtual circuit down NP -- interface hardware not present CM -- control-word mismatch - -- only outbound connection is up CN -- circuit not provisioned <- -- only inbound connection is up OR -- out of range Up -- operational OL -- no outgoing label Dn -- down LD -- local site signaled down CF -- call admission control failure RD -- remote site signaled down SC -- local and remote site ID collision LN -- local site not designated LM -- local site ID not minimum designated RN -- remote site not designated RM -- remote site ID not minimum designated XX -- unknown connection status IL -- no incoming label MM -- MTU mismatch MI -- Mesh-Group ID not available BK -- Backup connection ST -- Standby connection PF -- Profile parse failure PB -- Profile busy Legend for interface status Up -- operational Dn -- down Instance: vpls-vlan100 Local site: vlan100-volt-PE (4) connection-site Type St Time last up # Up trans 3 rmt Up Jun 17 08:11:59 2009 1 Remote PE: 10.255.171.30, Negotiated control-word: No Incoming label: 262147, Outgoing label: 800003 Local interface: lsi.1048576, Status: Up, Encapsulation: VPLS Description: Intf - vpls vpls-vlan100 local site 4 remote site 3
Use the show vpls-flood extensive command to verify that traffic from CE interfaces will only travel on pseudowires:
user@host# show vpls flood extensiveName: vpls-vlan100 CEs: 2 VEs: 1 Flood route prefix: 0x4a/32 Flood route type: IFF_FLOOD Flood route owner: lsi.1048576 Flood group name: __ves__ Flood group index: 0 Nexthop type: comp Nexthop index: 568 Flooding to: Name Type NhType Index CE-MG Group comp 565 Composition: flood-to-all Flooding to: Name Type NhType Index ge-2/0/1.0 CE ucst 515 ge-2/1/0.0 CE ucst 571 Flood route prefix: 0x46/32 Flood route type: IFF_FLOOD Flood route owner: ge-2/0/1.0 Flood group name: CE-MG Flood group index: 2 Nexthop type: comp Nexthop index: 556 Flooding to: Name Type NhType Index __ves__ Group comp 549 Composition: flood-to-all Flooding to: Name Type NhType Index lsi.1048576 VE indr 1048574 Flood route prefix: 0x4b/32 Flood route type: IFF_FLOOD Flood route owner: ge-2/1/0.0 Flood group name: CE-MG Flood group index: 2 Nexthop type: comp Nexthop index: 556 Flooding to: Name Type NhType Index __ves__ Group comp 549 Composition: flood-to-all Flooding to: Name Type NhType Index lsi.1048576 VE indr 1048574
Is there an example configuration for terminating Layer 2 circuits into VPLS using mesh groups?
The following example terminates Layer 2 circuits into VPLS using mesh groups. In the example, the mesh-group mx-pw statement is the mesh group configuration:
Which components are used in calculating the load balancing (hashing) algorithm for a link aggregation group?
For Layer 3 traffic, the default components used to calculate the load balancing (hashing) algorithm for a link aggregation group (LAG) are the source address, destination address, and interface indexes. If you include the hash-key statement under the [edit forwarding-options hash-key] hierarchy level, the information in that level is used to compute the hash key for load balancing.
What is the maximum supported number of link aggregation group bundles and members per bundle on MX Series routers?
Junos OS supports a maximum of 128 LAG bundles with 16 members each on MX Series routers.
What is the interworking scalability for mesh groups in VPLS LDP-BGP?
You can have up to 14 mesh groups per VPLS on MX Series routers and up to 126 on M Series routers. For example, for a given VPLS instance, if you need LDP-BGP interworking, there must be one mesh group for every LDP-VPLS cloud that is connected to the BGP-VPLS cloud, at the interworking router.
Is the label block size configurable per VPLS and per router or logical system?
In Junos OS 10.0 and later, use the label-block-size size statement to configure VPLS label block size. Use this to increase the VPLS scaling. If the label block is configured as two, this will increase the VPLS scaling four times. You can allocate the label block size in increments of 2, 4, 8, or 16.
Is indirect next hop supported for VPLS?
No, indirect next hop is only supported for Layer 3 VPNs. In Junos OS 10.3 and later, a constraint of not allowing VPLS configuration when using indirect next hop for other services is removed. With this constraint removed, you can have VPLS with indirect next hop and the routing protocol process will ignore the VPLS configuration.
I want to define multiple port mirroring interfaces on a single chassis and select which traffic is mirrored to each interface. How can I accomplish this on MX Series, M Series, and T Series routers?
Junos OS supports multiple port mirror destinations in MX Series routers, and on M Series M120 and M320 routers. For more information about configuring port-mirroring on MX Series routers, refer to Layer 2 Port Mirroring in the current version of the Junos OS® Software MX Series Ethernet Services Routers Layer 2 Configuration Guide, http://www.juniper.net/techpubs/en_US/junos10.1/information-products/pathway-pages/layer-2/layer-2-port-mirroring.html
In T Series routers, there is only one chassis-wide destination. All platforms support multiple source ports (interfaces that need to be mirrored).
Can traffic be port-mirrored from a Layer 2 VPN on T Series routers for PE routers?
No, this is not supported in T Series routers at this time. It is only supported in MX Series routers, and in M Series routers M120 and M320 with E3 FPCs (I-chip-based).
Can the outgoing and incoming traffic of a given T Series or MX Series interface be port-mirrored?
Yes, this is supported on all Juniper Networks platforms.
Can integrated routing and bridging traffic be port-mirrored?
In Junos OS 9.6R2 and later, if the following conditions are met, an integrated routing and bridging (IRB) packet can be mirrored as a Layer 2 packet:
- The IRB is associated with the bridge-domain or vpls routing-instance.
- The bridge-domain has a forwarding table filter configured with an action of then port-mirror or then port-mirror-instance instance.
This Layer 2 IRB port mirroring can be disabled using the no-irb-layer-2-copy statement at the bridge-domain or the vpls routing-instance hierarchy level.
What are the differences in packet processing between a VT interface and an LSI interface (vrf-table-label or no-tunnel-services)?
The LSI interface provides better packet processing performance than the VT interface, unless there are core-facing interface restrictions or loss of ingress forwarding functionality, because the frame is sent only once through the route lookup.
In a VT interface, the packet loops back, with a first pass as mpls-vrf and a second pass for frame processing. The VT interface is limited by an overall tunnel bandwidth of 1/10 Gbps. The LSI interface is limited by line rate.
What is an example configuration for using an entire site as primary and backup for VPLS multihoming?
The following example shows the VPLS_CUST_101 routing instance configured as the primary site and the VPLS_CUST_102 routing instance configured as the backup site. Note that in the portion of the example that shows the other PE router, the VPLS_CUST_101 routing instance is the backup site and the VPLS_CUST_102 routing instance is the primary site.
user@host# show vpls connections...
Instance: VPLS_CUST_101
Local site: 3 (3)
connection-site Type St Time last up # Up trans
1 rmt Up Feb 18 09:16:06 2009 1
Remote PE: 1.1.1.1, Negotiated control-word: No
Incoming label: 800256, Outgoing label: 800274
Local interface: vt-11/3/10.1051392, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS_CUST_101 local site 3 remote site 1
3 rmt SC site-collision
Instance: VPLS_CUST_102
Local site: 3 (3)
connection-site Type St Time last up # Up trans
1 rmt LN
3 rmt SC site collision
user@host# show vpls connections...
Instance: VPLS_CUST_101
Local site: 4 (3)
connection-site Type St Time last up # Up trans
1 rmt LN
3 rmt SC
Instance: VPLS_CUST_102
Local site: 4 (3)
connection-site Type St Time last up # Up trans
1 rmt Up Feb 18 19:00:28 2009 1
Local interface: vt-11/3/10.1048579, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS_CUST_102 local site 3 remote site 1
Remote PE: 1.1.1.1, Negotiated control-word: No
Incoming label: 800016, Outgoing label: 800266
3 rmt SC
Which classification methods are supported for ingress queuing on an Enhanced Queuing Dense Port Concentrator on MX Series routers?
Support for ingress queuing on EQ-DPC includes the following methods, as defined in Institute of Electrical and Electronics Engineers (IEEE) 802.1p:
- IP Differentiated Services code point (DSCP) precedence for IPv4 interfaces
- MPLS EXP for MPLS interfaces
- Tagged VPLS, bridge, and circuit cross-connect (CCC) interfaces
There is no support for ingress queuing for untagged VPLS and CCC interfaces.
DSCP is not supported as a classification option for ingress queuing on VPLS interfaces.
Is BGP autodiscovery supported for LDP-based VPLS as defined in draft-ietf-l2vpn-signaling-xx?
No, this is not currently supported as defined in the draft Provisioning, Autodiscovery, and Signaling in L2VPNs. Enabling BGP autodiscovery in this manner requires support for forwarding equivalence class (FEC) 129, which is not yet supported in Juniper Networks devices. Support is provided for legacy LDP-VPLS and BGP-VPLS with FEC 128.
As a workaround, you can manually provision each LDP PE router in an LDP mesh group by including the neighbor statement. Support for FEC 129 may be included in future releases.
Is IGMP snooping supported on NG-VPLS when point-to-multipoint is in the core?
No, this is not supported.
