Configuring VPLS and Integrated Routing and Bridging
Traditional Layer 2 switching environments consist of Layer 2 devices (such as switches) that partition data into broadcast domains. The broadcast domains can be created through physical topologies or logically through virtual local area networks (VLANs). For MX Series routers, you can logically configure broadcast domains within virtual switch routing instances, VPLS routing instances, or bridging domains. The individual routing instances or bridging domains are differentiated through VLAN identifiers and these instances or domains function much like traditional VLANs.
To configure a VLAN with IRB support, include the following statements:
[edit]
routing-instances {
instance-name {
instance-type vpls;
vlan-id id;
route-distinguisher distinguisher;
vrf-target target;
interface interface-name;
interface interface-name;
routing-interface interface-name;
}
}
In multihomed VPLS configurations, you can configure VPLS to
keep a VPLS connection up if only an IRB interface is available by
configuring the irb option for the connectivity-type statement at the [edit routing-instances routing-instance-name protocols vpls] hierarchy level. The connectivity-type statement has the ce and irb options. The ce option is the default and specifies that a CE interface
is required to maintain the VPLS connection. By default, if only an
IRB interface is available, the VPLS connection is brought down.
A maximum of 4096 active logical interfaces are supported for a VLAN or on each mesh group in a VPLS routing instance configured for Layer 2 bridging.
For detailed information and configuration instructions on bridging domains and spanning tree protocol, see Junos OS Network Interfaces Library for Routing Devices and Junos OS Routing Protocols Library.
The following sections provide configuration information specific to VPLS in regards to integrated routing and bridging:
Configuring MAC Address Flooding and Learning for VPLS
In a VPLS routing instance or bridge domain, when a frame is received from a CE interface, it is flooded to the other CE interfaces and all of the VE interfaces if the destination MAC address is not learned or if the frame is either broadcast or multicast. If the destination MAC address is learned on another CE device, such a frame is unicasted to the CE interface on which the MAC address is learned. This might not be desirable if the service provider does not want CE devices to communicate with each other directly.
To prevent CE devices from communicating directly include the no-local-switching statement at the [edit bridge-domains bridge-domain-name] hierarchy level:
[edit bridge-domains bridge-domain-name] no-local-switching;
The no-local-switching statement is available only
on MX Series routers. If you include it, frames arriving on a CE
interface are sent to VE or core-facing interfaces only.
(MX80, MX104, and the 16x10GE MPC, MPC1, or MPC2 on MX240, MX480,
MX960, MX2010, and MX2020 only) If you configure the no-local-switching command at the [edit bridge-domains bridge-domain-name] hierarchy level, it might not prevent multicast traffic from
being forwarded between the CE-facing interfaces of the bridge domain.
Broadcast, unknown unicast, and known multicast traffic does not exhibit
this behavior.
Configuring MSTP for VPLS
When you configure integrated routing and bridging,
you might also need to configure the Multiple Spanning Tree Protocol
(MSTP). When you configure MSTP on a provider edge (PE) router running
VPLS, you must also configure ethernet-vpls encapsulation
on the customer-facing interfaces. VLAN-based VPLS interface encapsulations
are not supported with MSTP.