Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Example: Configuring One VPLS Instance for Several VLANs

This topic provides a configuration example to help you effectively configure a network of Juniper Networks MX Series 3D Universal Edge Routers for a bridge domain or virtual private LAN service (VPLS) environment. The emphasis here is on choosing the normalized virtual LAN (VLAN) configuration. The VPLS configuration is not covered in this chapter. For more information about configuring Ethernet pseudowires as part of VPLS, see the Junos OS, Release 13.2.

Note: This topic does not present exhaustive configuration listings for all routers in the figures. However, you can use it with a broader configuration strategy to complete the MX Series router network configurations.

Consider the VPLS network shown in Figure 1.

Figure 1: Many VLANs on One VPLS Instance

The Layer 2 PE routers are MX Series routers. Each site is connected to two P routers for redundancy, although both links are only shown for L2-PE1 at Site 1. Site 1 is connected to P0 and P1, Site 2 is connected to P0 and P2 (not shown), Site 3 is connected to P2 and P3, and Site 4 is connected to P1 and P3. VPLS pseudowires configured on the PE and P routers carry traffic between the sites.

The pseudowires for the VPLS instances are shown with distinct dashed and dotted lines. Most sites have multiple VLANs configured.

Service provider SP-1 is providing VPLS services for customer C1, services that could span several sites. Now customer C1 can have many VLANs in the range from 1 through 1000 (for example).

If VLANs 1 through 1000 for customer C1 span the same sites, then the vlan-id all and vlan-id-list statements provide a way to switch all of these VLANs with a minimum configuration effort and fewer switch resources.

Note: You cannot use the vlan-id all statement if you configure an IRB interface on one or more of the VLANs.

Alternatively, instead of configuring a VPLS instance, you can define a virtual switch with a bridge domain and associate the logical interfaces as trunk ports with the bridge domain. This configuration is necessary if you want to configure a list or range of VLAN IDs on the logical interfaces and use the vlan-id all statement to normalize VLANs.

A Layer 2 virtual switch, which isolates a LAN segment with its spanning-tree protocol instance and separates its VLAN ID space, filters and forwards traffic only at the data link layer. Each bridge domain consists of a set of logical ports that participate in Layer 2 learning and forwarding.

You can configure VPLS ports in a virtual switch so that the logical interfaces of the Layer 2 bridge domains in the virtual switch can handle VPLS routing instance traffic. VPLS configuration no longer requires a dedicated routing instance of type vpls. Packets received on a Layer 2 trunk interface are forwarded within a bridge domain that has the same VLAN identifier. A trunk interface is implicitly associated with bridge domains based on VLAN membership.

You can use either of the following two mechanisms to normalize VLAN identifiers and process them in a bridge domain or a VPLS routing instance:

• By using the input-vlan-map and the output-vlan-map statements at the [edit interfaces interface-name] hierarchy level to configure VLAN mapping.
• By using either the vlan-id statement or the vlan-tags statement to configure a normalizing VLAN identifier.

The vlan-id and vlan-tags statements are used to specify the normalizing VLAN identifier under the bridge domain or VPLS routing instance. The normalizing VLAN identifier is 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.

If you configure the vlan-id all statement in a VPLS routing instance, we recommend using the input-vlan-map pop and output-vlan-map push statements on the logical interface to pop the service VLAN ID on input and push the service VLAN ID on output and in this way limit the impact of doubly-tagged frames on scaling. You cannot use the native vlan- id statement when the vlan-id all statement is included in the configuration.

For the same network topology illustrated in Figure 1, if VLANs 1 through 1000 for customer C1 span the same sites, you can normalize the VLANs by doing one of the following. Using either of these optimal methods, you can switch and normalize all of these VLANs in an effective, streamlined manner without configuring separately for each VLAN ID.

• By configuring a VPLS routing instance if the logical interfaces are specified with a range of consecutive VLANs or a list of non-contiguous VLAN IDs and using VLAN maps to rewrite the VLAN tags on all of the incoming and outgoing packets on the logical interfaces with a normalized VLAN ID
• By configuring a virtual-switch instance consisting of a set of bridge domains that are associated with one or more logical interfaces configured as a trunk port

You cannot use the vlan-id statement to enable VLAN normalization in VPLS instances, if the logical interfaces in the VPLS instance are configured with the vlan-id-list or vlan-id-range statement. In such a scenario, you can use the input-vlan-map or the output-vlan-map option to achieve VLAN normalization.

• Packets received on logical interfaces ge-1/0/0.1 , or ge-2/0/0.1, or ge-3/0/0.1, with a single VLAN tag in the range from 1 through 1000 in the frame are accepted.
• The VLAN tags of a received packet are compared with the normalized VLAN tags specified with the vlan-id statement in the input VLAN map. If the VLAN tags of the received packet are different from the normalized VLAN tags, then the received VLAN tag is converted to the normalized VLAN tag of 1200 for packets received on the logical interface ge-1/0/0.1. Similarly, for logical interface ge-2/0/0.1, the normalized VLAN tag is 1300 for received packets and for logical interface ge-3/0/0.1, the normalized VLAN tag is 1400. Then, the source MAC address of a received packet is learned based on the normalized VLAN configuration.

  For output packets, based on the output vlan-map pop statement configured on the logical interfaces ge-1/0/0.1 , or ge-2/0/0.1, or ge-3/0/0.1, if the VLAN tags associated with an egress logical interface do not match the normalized VLAN tags within the packet, then the VLAN tags in the packets that are being transmitted from the egress logical interface are removed.

• Unknown source MAC addresses and unknown destination MAC addresses are learned based on their normalized VLAN values of 1 through 1000.
• All packets sent on the VPLS pseudowire have a normalized VLAN tag after the source MAC address field in the encapsulated Ethernet packet.
• The input-vlan-map pop and output-vlan-map push statements on the logical interface cause the service VLAN ID to be popped on input and the service VLAN ID to be pushed on output and in this way, the impact of doubly-tagged frames on scaling is limited.

Note the use of the vlan-id all statement in the virtual-switch instance called customer-c1-v1-to-v1000. The vlan-id all statement implicitly creates multiple learning domains, each with its own normalized VLAN.

• The logical interfaces are configured as a trunk port that multiplexes traffic from multiple VLANs and usually interconnects switches.
• All the VLAN identifiers are associated with a Layer 2 trunk port. Each of the logical interfaces, ge-1/0/0.1 , or ge-2/0/0.1, or ge-3/0/0.1, accepts packets tagged with any VLAN ID specified in the respective vlan-id-list statements.
• The association of the received packet to a logical interface is done by matching the VLAN tags of the received packet with the VLAN tags configured on one of the logical interfaces on that physical port. The vlan-id all configuration within the bridge domain c1-vlan-v1-to-v1000 for customer-c1-virtual-switch sets the normalized VLAN value. For a logical interface with a single VLAN tag, a learning domain implicitly created for each normalized VLAN of the interface.
• Bridge domain c1-vlan-v1-to-v1000 for customer-c1-virtual-switch has three logical interfaces:
  • Logical interface ge-1/0/0.1 configured on physical port ge-1/0/0.
  • Logical interface ge-2/0/0.1configured on physical port ge-2/0/0.
  • Logical interface ge-3/0/0.1configured on physical port ge-3/0/0.
• Packets received on logical interfaces ge-1/0/0.11 or ge-6/0/0.11 with a single VLAN tag of 1500 in the frame are accepted.
• Unknown source MAC addresses and unknown destination MAC addresses are learned based on their normalized VLAN values of 1 through 1000.
• All packets sent on the VPLS pseudowire have a normalized VLAN tag after the source MAC address field in the encapsulated Ethernet packet.
• Although there are only three logical interfaces in the VPLS instance called customer-c1-virtual-switch, the same MAC address (for example, M1) can be learned on different logical interfaces for different VLANs. For example, MAC address M1 could be learned on logical interface ge-1/0/0.1 for VLAN 500 and also on logical interface ge-2/0/0.1 for VLAN 600.