Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    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.

    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

    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.

    The following example illustrates the use of the VLAN mapping functionality in VPLS routing instances to normalize VLANs. This method is beneficial in scenarios with flexible VLAN tagging (asymmetric tag depth). In such an environment, the VLAN configuration data that you specified applies the appropriate VLAN tags to the input and output VLAN maps for the ingress and egress logical interfaces respectively. For example, if certain packets are received as single- tagged packets and if the remaining packets are received as double-tagged packets, using VLAN mapping enables normalization.

    Using the VLAN mapping capability is effective only if packets of unequal VLAN tags are received or transmitted from logical interfaces to achieve normalization. We recommend that you do not use VLAN mapping in environments in which the VLAN tags are of equal tag depths for optimal configuration. In such cases, you can use the vlan-id all statement to enable normalization of VLANs.

    [edit]
    interfaces ge-1/0/0 {
    encapsulation flexible-ethernet-services;
    flexible-vlan-tagging;
    unit 1 {
    encapsulation vlan-vpls;
    vlan-id-range 1-1000;
    input-vlan-map {
    push; /* Push the service vlan on input */
    vlan-id 1200; # This VLAN ID is the normalized VLAN for incoming packets
    }
    output-vlan-map pop; /* Pop the service vlan on output */
    }
    unit 11 {
    encapsulation vlan-vpls;
    vlan-id 1500;
    }
    }
    interfaces ge-2/0/0 {
    encapsulation flexible-ethernet-services;
    flexible-vlan-tagging;
    unit 1 {
    encapsulation vlan-vpls;
    vlan-id-range 1-1000; # Note the use of the VLAN id range statement.
    input-vlan-map {
    push; /* Push the service vlan on input */
    vlan-id 1300; # This VLAN ID is the normalized VLAN for incoming packets
    }
    output-vlan-map pop; /* Pop the service vlan on output */
    }
    }
    }
    interfaces ge-3/0/0 {
    encapsulation flexible-ethernet-services;
    flexible-vlan-tagging;
    unit 1 {
    encapsulation vlan-vpls;
    vlan-id 1-1000;
    input-vlan-map {
    push; /* Push the service vlan on input */
    vlan-id 1400; # This VLAN ID is the normalized VLAN for incoming packets
    }
    output-vlan-map pop; /* Pop the service vlan on output */
    }
    }
    }
    interfaces ge-6/0/0 {
    encapsulation flexible-ethernet-services;
    flexible-vlan-tagging;
    unit 11 {
    encapsulation vlan-vpls;
    vlan-id 1500;
    }
    }
    routing-instances {
    customer-c1-v1-to-v1000 {
    instance-type vpls;
    interface ge-1/0/0.1;
    interface ge-2/0/0.1;
    interface ge-3/0/0.1;
    } # End of customer-c1-v1-to-v1000
    customer-c1-v1500 {
    instance-type vpls;
    interface ge-1/0/0.11;
    interface ge-6/0/0.11;
    } # End of customer-c1-v1500
    } # End of routing-instances

    The following operations are performed when you use the VLAN mapping configuration:

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

    The following example illustrates the use of the vlan-id all statement in logical interfaces when a virtual switch instance with a bridge domain is associated with the logical interfaces. You can normalize VLANs and create learning domains for each VLAN. A routing instance uses a trunk bridge to connect different departments in an organization, each with their own VLANs, at two different sites. You must configure a bridge domain and VLAN identifier for each VLAN associated with the trunk interface.

    [edit]
    interfaces ge-1/0/0 {
    encapsulation flexible-ethernet-services;
    flexible-vlan-tagging;
    unit 1 {
    encapsulation vlan-vpls;
    family bridge {
    interface-mode trunk;
    vlan-id-list 1-1000; # Note the use of the VLAN id list statement.
    }
    }
    unit 11 {
    encapsulation vlan-vpls;
    family bridge {
    interface-mode trunk;
    vlan-id-list 1500;
    }
    }
    }
    interfaces ge-2/0/0 {
    encapsulation flexible-ethernet-services;
    flexible-vlan-tagging;
    unit 1 {
    encapsulation vlan-vpls;
    family bridge {
    interface-mode trunk;
    vlan-id-list 1-1000; # Note the use of the VLAN id list statement.
    }
    }
    }
    interfaces ge-3/0/0 {
    encapsulation flexible-ethernet-services;
    flexible-vlan-tagging;
    family bridge {
    unit 1 {
    encapsulation vlan-vpls;
    interface-mode trunk;
    vlan-id-list 1-1000; # Note the use of the VLAN id list statement.
    }
    }
    }
    interfaces ge-6/0/0 {
    encapsulation flexible-ethernet-services;
    flexible-vlan-tagging;
    family bridge {
    unit 11 {
    encapsulation vlan-vpls;
    interface-mode trunk;
    vlan-id-list 1500;
    }
    }
    }
    routing-instances {
    customer-c1-virtual-switch {
    instance-type virtual-switch;
    interface ge-1/0/0.1;
    interface ge-2/0/0.1;
    interface ge-3/0/0.1;
    bridge-domains {
    c1-vlan-v1-to-v1000 {
    vlan-id all; # Note the use of the VLAN id all statement
    }
    }
    } # End of customer-c1-v1-to-v1000
    customer-c2-virtual-switch {
    instance-type virtual-switch;
    interface ge-1/0/0.11;
    interface ge-6/0/0.11;
    bridge-domains {
    c1-vlan-v1500 {
    vlan-id all; # Note the use of the VLAN id all statement
    }
    }
    } # End of customer-c1-v1500
    } # End of routing-instances

    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 following operations are performed when you use the vlan-id all configuration:

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

    Modified: 2017-08-31