Juniper

vpls configuration example

Juniper vpls configuration example ldp. Juniper network configuration example. Juniper mx vpls configuration example. Juniper srx vpls configuration example.

Figure 1: VPLS Topology Diagram In Figure 1, a simple VPLS topology is enabled between routers PE1 and PE2. CE routers CE1 and CE2 use Ethernet-based interfaces to connect VLAN 600 to their local PE router. The PE routers PE1 and PE2 are connected to one another by LSPs enabled across a service provider backbone running MPLS, BGP,
RSVP, and OSPF. In a VPLS routing instance named green, PE1 has a local interface fe-0/1/0 and a virtual port of vt-0/3/0.32770 (the virtual port is created dynamically on the Tunnel Services PIC when VPLS is configured). PE2 has a local interface fe-0/1/0 and a virtual port of vt-0/3/0.32771 in the same green instance.

As a result, routers CE1 and CE2 send Ethernet traffic to one another as if they were physically connected to each other on a LAN. On Router CE1, the only item you need to configure is the Fast Ethernet interface that connects to PE1. Be sure to write down the VLAN identifier and IP address, so you can match them later on CE2. Router CE1 [edit]
interfaces { fe-0/1/0 { vlan-tagging; # Configure VLAN tagging for VLAN VPLS or extended VLAN VPLS. unit 0 { vlan-id 600; # The Ethernet interface on CE2 must use the same VLAN ID. family inet { address 10.11.3.1/24; # The interface on CE2 must use the same prefix. } } } } If Router PE1 is an MX Series device, you need to configure a tunnel
service interface. To create tunnel interfaces on an 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 tunnel services] hierarchy level. The following
example shows a tunnel interface with 1 Gbps of bandwidth configured on PFE 3 of the DPC installed in slot 0 of an MX Series router: [edit chassis] fpc 0 { pic 3 { tunnel services { bandwidth 1g; } } } On Router PE1, prepare the router for VPLS by configuring BGP, MPLS, OSPF, and RSVP. (These protocols are the basis for most Layer 2 VPN-related
applications, including VPLS.) Include the signaling statement at the [edit protocols bgp group group-name family l2vpn] hierarchy level, because VPLS uses the same infrastructure for internal BGP as Layer 2 VPNs. Note: In Junos OS Release 7.3 and later, the signaling statement replaces the unicast statement at the [edit protocols bgp group group-
name family l2vpn] hierarchy level.
You must use the signaling statement if you wish to configure VPLS domains and Layer 2 VPNs simultaneously. Next, configure VLAN tagging on the Fast Ethernet interface connected to Router CE1. Include VLAN VPLS encapsulation at both the physical and logical interface levels. Be sure to use the same VLAN ID for all Ethernet interfaces that are
part of a single VPLS instance. Finally, add the Fast Ethernet interface into a VPLS routing instance and specify the site range, site ID number, and site name. Router PE1 [edit] interfaces { fe-0/1/0 { vlan-tagging;# Configure VLAN tagging for VLAN VPLS or extended VLAN VPLS. encapsulation vlan-vpls; # Configure VPLS encapsulation on both the
unit 0 { # physical interface and the logical interface. encapsulation vlan-vpls; vlan-id 600;# The VLAN ID is the same one used by the CE routers. } } so-1/1/0 { unit 0 { family inet { address 10.11.1.5/30; } family mpls; } } lo0 { unit 0 { family inet { address 10.245.14.218/32; } } } } routing-options { autonomous-system 69; forwarding-table {
export exp-to-fwd; # Apply a policy that selects an LSP for the VPLS instance. } } protocols { rsvp { interface all { aggregate; } } mpls { label-switched-path pe1-to-pe2 { # Configure an LSP to reach other VPLS PEs. to 10.245.14.219; } interface all; } bgp { group vpls-pe { type internal; local-address 10.245.14.218; family l2vpn { # VPLS uses the
same infrastructure as Layer 2 VPNs signaling; # for internal BGP. } neighbor 10.245.14.217; neighbor 10.245.14.219; } } ospf { traffic-engineering; area 0.0.0.0 { interface so-1/1/0.0 { metric 11; } interface lo0.0 { passive; } } } } policy-options { policy-statement exp-to-fwd { term a { from community grn-com; # Matches the community in the
VPLS instance. then { install-nexthop lsp pe1-to-pe2; # If there are multiple LSPs that exist accept; # between VPLS PE routers, this statement sends VPLS traffic } # over a specific LSP. } } community grn-com members target:11111:1; # Adds the instance to a BGP } # community. routing-instances { green { instance-type vpls; # Configure a VPLS
routing instance. interface fe-0/1/0.0; route-distinguisher 10.245.14.218:1; vrf-target target:11111:1; # This value is important to the BGP community. protocols { vpls { # Configure a VPLS site range, site name, and site identifier. site-range 10; site greenPE1 { site-identifier 1; } } } } } On Router P0, configure BGP, MPLS, OSPF, and RSVP to
interconnect PE1 and PE2. Router P0 [edit] interfaces { so-0/0/0 { unit 0 { family inet { address 10.11.2.6/30; } family mpls; } } so-1/1/0 { unit 0 { family inet { address 10.11.1.6/30; } family mpls; } } lo0 { unit 0 { family inet { address 10.245.14.217/32; } } } } routing-options { autonomous-system 69; } protocols { rsvp { interface all { aggregate;
} } mpls { interface all; } bgp { group vpls-pe { type internal; local-address 10.245.14.217; family l2vpn { # VPLS uses the same infrastructure as Layer 2 VPNs signaling; # for internal BGP. } neighbor 10.245.14.218; neighbor 10.245.14.219; } } ospf { traffic-engineering; area 0.0.0.0 { interface so-1/1/0.0 { metric 11; } interface so-0/0/0.0 { metric
15; } interface lo0.0 { passive; } } } } If Router PE2 is an MX Series device, you need to configure a tunnel service interfaces.
To create tunnel interfaces on an 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 3 of the DPC installed in slot 0 of an MX Series router: [edit chassis] fpc 0 { pic 3 { tunnel services { bandwidth 1g; } } } On Router PE2, configure BGP, MPLS, OSPF, and RSVP to complement the configuration on PE1. Next, configure VLAN tagging on the Fast Ethernet interface connected to
Router CE2. Include VLAN VPLS encapsulation at both the physical and logical interface levels. Be sure to use the same VLAN ID for all Ethernet interfaces that are part of a single VPLS instance. Finally, add the Fast Ethernet interface into a VPLS routing instance and specify the site range, site ID number, and site name. Router PE2 [edit] interfaces
{ fe-0/1/0 { vlan-tagging; # Configure VLAN tagging for VLAN VPLS or extended VLAN VPLS. encapsulation vlan-vpls; # Configure VPLS encapsulation on both the unit 0 { # physical interface and logical interface. encapsulation vlan-vpls; vlan-id 600;# The VLAN ID is the same one used by the CE routers.
} } so-0/0/0 { unit 0 { family inet { address 10.11.2.5/30; } family mpls; } } lo0 { unit 0 { family inet { address 10.245.14.219/32; } } } } routing-options { autonomous-system 69; forwarding-table { export exp-to-fwd; # Apply a policy that selects an LSP for the VPLS instance. } } protocols { rsvp { interface all { aggregate; } } mpls { label-switched-
path pe2-to-pe1 { # Configure an LSP to other VPLS PE routers. to 10.245.14.218; } interface all; } bgp { group vpls-pe { type internal; local-address 10.245.14.219; family l2vpn { # VPLS uses the same infrastructure as Layer 2 VPNs signaling; # for internal BGP. } neighbor 10.245.14.217; neighbor 10.245.14.218; } } ospf { traffic-engineering;
area 0.0.0.0 { interface so-0/0/0.0 { metric 15; } interface lo0.0 { passive; } } } } policy-options { policy-statement exp-to-fwd { term a { from community grn-com; # Matches the community with the VPLS instance. then { install-nexthop lsp pe2-to-pe1; # If there are multiple LSPs that exist accept; # between VPLS PE routers, this statement sends
VPLS traffic } # over a specific LSP. } } community grn-com members target:11111:1; # This adds the instance into a BGP community. } routing-instances { green { instance-type vpls; # Configure a VPLS routing instance. interface fe-0/1/0.0; route-distinguisher 10.245.14.219:1; vrf-target target:11111:1; # This value is important for the BGP
community. protocols { vpls { # Configure a VPLS site range, site name, and site identifier. site-range 10; site greenPE2 { site-identifier 2; } } } } } On Router CE2, complete your VPLS network by configuring the Fast Ethernet interface that connects to PE2. Use the same VLAN identifier and IP address prefix used on Router CE1. Router CE2 [edit]
interfaces { fe-0/1/0 { vlan-tagging; # Configure VLAN tagging for VLAN VPLS or extended VLAN VPLS. unit 0 { vlan-id 600; # The Ethernet interface on CE1 must use the same VLAN ID. family inet { address 10.11.3.2/24; # The interface on CE1 must use the same prefix. } } } } To verify proper operation of VPLS, use the following commands:
clear vpls mac-address instance instance-name show interfaces terse show route forwarding-table family mpls show route forwarding-table family vpls (destination | extensive | matching | table) show route instance (detail) show system statistics vpls show vpls connections show vpls statistics The following section shows the output of these commands
on Router PE1 as a result of the configuration example: user@PE1> show interfaces terse Interface Admin Link Proto Local Remote so-1/1/0 up up so-1/1/0.0 up up inet 10.11.1.5/30 mpls so-1/1/1 up up so-1/1/2 up up so-1/1/3 up up fe-0/1/0 up up fe-0/1/0.0 up up vpls # This is the local Fast Ethernet # interface. fe-0/1/1 up up fe-0/1/2 up up fe-0/1/3
up up gr-0/3/0 up up ip-0/3/0 up up mt-0/3/0 up up pd-0/3/0 up up pe-0/3/0 up up vt-0/3/0 up up vt-0/3/0.32770 up up # This is the dynamically generated virtual port.

dsc up up fxp0 up up fxp0.0 up up inet 192.186.14.218/24 fxp1 up up fxp1.0 up up tnp 4 gre up up ipip up up lo0 up up lo0.0 up up inet 10.245.14.218 --> 0/0 127.0.0.1 --> 0/0 inet6 fe80::2a0:a5ff:fe28:13e0 feee::10:245:14:218 lsi up up mtun up up pimd up up pime up up tap up up user@PE1> show system statistics vpls vpls: 0 total packets received
0 with size smaller than minimum 0 with incorrect version number 0 packets for this host 0 packets with no logical interface 0 packets with no family 0 packets with no route table 0 packets with no auxiliary table 0 packets with no corefacing entry 0 packets with no CE-facing entry 6 mac route learning requests # This indicates that VPLS is working.
6 mac routes learnt 0 mac routes aged 0 mac routes moved To display VPLS source and destination MAC address accounting information, use the destination, extensive, matching, or table option with the show route forwarding-table family vpls command. When you analyze the display output, keep in mind the following: VPLS MAC address accounting
is handled on a per-MAC address basis for each VPLS instance. All information is retrieved from MAC address entries in the MAC address table.
VPLS MAC address accounting is performed only on local CE routers. The VPLS counters for source and destination MAC addresses increment continuously until the oldest MAC address entries are removed from the memory buffer, either when the entries time out or if the VPLS instance is restarted. user@PE1> show route forwarding-table family
vpls extensive Routing table: green.vpls [Index 2] VPLS: Destination: default Route type: dynamic Route reference: 0 Flags: sent to PFE Next-hop type: flood Index: 353 Reference: 1 Destination: default Route type: permanent Route reference: 0 Flags: none Next-hop type: discard Index: 298 Reference: 1 Destination: fe-0/1/0.0 Route type: dynamic
Route reference: 0 Flags: sent to PFE Next-hop type: flood Index: 355 Reference: 1 Destination: bb:bb:bb:bb:bb:bb/48 # This MAC address belongs to remote CE2.
Route type: dynamic Route reference: 0 Flags: sent to PFE, prefix load balance Next-hop type: indirect Index: 351 Reference: 4 Next-hop type: Push 800000, Push 100002(top) Next-hop interface: so-1/1/0.0 Destination: aa:aa:aa:aa:aa:aa/48 # This MAC address belongs to local CE1. Route type: dynamic Route reference: 0 Flags: sent to PFE, prefix
load balance Next-hop type: unicast Index: 354 Reference: 2 Next-hop interface: fe-0/1/0.0 user@PE1> show route forwarding-table family vpls Routing table: green.vpls VPLS: Destination Type RtRef Next hop Type Index NhRef Netif default dynm 0 flood 353 1 default perm 0 dscd 298 1 fe-0/1/0.0 dynm 0 flood 355 1 bb:bb:bb:bb:bb:bb/48 # This
MAC address belongs to remote CE2. dynm 0 indr 351 4 Push 800000, Push 100002(top) so-1/1/0.0 aa:aa:aa:aa:aa:aa/48 # This MAC address belongs to local CE1. dynm 0 ucst 354 2 fe-0/1/0.0 user@PE1> show route forwarding-table family mpls Routing table: mpls MPLS: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 dscd
19 1 0 user 0 recv 18 3 1 user 0 recv 18 3 2 user 0 recv 18 3 100000 user 0 10.11.1.6 swap 100001 so-1/1/0.0 800002 user 0 Pop vt-0/3/0.32770 vt-0/3/0.32770 (VPLS) user 0 indr 351 4 Push 800000, Push 100002(top) so-1/1/0.0 user@PE1> show route instance green detail green: Router ID: 0.0.0.0 Type: vpls State: Active Interfaces: fe-0/1/0.0 # This
is the local Fast Ethernet interface. vt-0/3/0.32770 # This is the dynamically generated VPLS virtual port. Route-distinguisher: 10.245.14.218:1 Vrf-import: [ __vrf-import-green-internal__ ] Vrf-export: [ __vrf-export-green-internal__ ] Vrf-import-target: [ target:11111:1 ] Vrf-export-target: [ target:11111:1 ] Tables: green.l2vpn.0 : 2 routes (2 active, 0
holddown, 0 hidden) user@PE1> show vpls connections L2VPN Connections: Legend for connection status (St) OR -- out of range WE -- intf encaps != instance encaps EI -- encapsulation invalid Dn -- down EM -- encapsulation mismatch VC-Dn -- Virtual circuit down CM -- control-word mismatch -> -- only outbound conn is up CN -- circuit not present
<- -- only inbound conn is up OL -- no outgoing label Up -- operational NC -- intf encaps not CCC/TCC XX -- unknown NP -- interface not present Legend for interface status Up -- operational Dn -- down Instance: green Local site: greenPE1 (1) connection-site Type St Time last up # Up trans 2 rmt Up Jan 24 06:26:49 2003 1 Local interface: vt-
0/3/0.32770, Status: Up, Encapsulation: VPLS Remote PE: 10.245.14.219, Negotiated control-word: No Incoming label: 800002, Outgoing label: 800000 user@PE1> show system statistics vpls vpls: 0 total packets received 0 with size smaller than minimum 0 with incorrect version number 0 packets for this host 0 packets with no logical interface 0
packets with no family 0 packets with no route table 0 packets with no auxiliary table 0 packets with no corefacing entry 0 packets with no CE-facing entry 7 mac route learning requests 7 mac routes learnt 0 mac routes aged 0 mac routes moved user@PE1> show route instance green detail green: Router ID: 0.0.0.0 Type: vpls State: Active
Interfaces: fe-0/1/0.0 vt-0/3/0.32770 Route-distinguisher: 10.245.14.218:1 Vrf-import: [ __vrf-import-green-internal__ ] Vrf-export: [ __vrf-export-green-internal__ ] Vrf-import-target: [ target:11111:1 ] Vrf-export-target: [ target:11111:1 ] Tables: green.l2vpn.0 : 2 routes (2 active, 0 holddown, 0 hidden) user@PE1> show vpls statistics Layer-2 VPN
Statistics: Instance: green Local interface: fe-0/1/0.0, Index: 351 Remote provider edge router: 10.245.14.219 Multicast packets: 363 Multicast bytes : 30956 Flood packets : 0 Flood bytes : 0 Local interface: vt-0/3/0.32770, Index: 354 Remote provider edge router: 10.245.14.219 Multicast packets: 135 Multicast bytes : 12014 Flood packets : 135 Flood
bytes : 12014 To clear all MAC address entries for a VPLS instance from the VPLS table, issue the clear vpls mac-address instance instance-name command. Add the logical-system logical-system-name option to clear entries in a VPLS instance within a logical system.
Use the mac-address option to remove individual MAC addresses. 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 InstanceThe 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 IDBy 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 portYou 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-v1000customer-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-instancesThe 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;}}}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;}}}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-v1000customer-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-instancesNote 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