Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configure Layer 2 Bridging

SUMMARY 

Configuring a Bridge Domain

A bridge domain must include a set of logical interfaces that participate in Layer 2 learning and forwarding. You can optionally configure a VLAN identifier and a routing interface for the bridge domain to also support Layer 3 IP routing.

To enable a bridge domain, include the following statements:

Note:

The Layer 2 CLI configurations and show commands for ACX5048 and ACX5096 routers differ compared to other ACX Series routers. For more information, see Layer 2 Next Generation Mode for ACX Series.

You cannot use the slash (/) character in bridge domain names. If you do, the configuration does not commit and an error is generated.

For the vlan-id statement, you can specify either a valid VLAN identifier or the none or all options. For information about VLAN identifiers and VLAN tags for a bridge domain, see Configuring VLAN Identifiers for Bridge Domains and VPLS Routing Instances.

To include one or more logical interfaces in the bridge domain, specify an interface-name for an Ethernet interface you configured at the [edit interfaces] hierarchy level.

Note:

A maximum of 4000 active logical interfaces are supported on a bridge domain or on each mesh group in a virtual private LAN service (VPLS) instance configured for Layer 2 bridging.

To configure a layer 2 logical interface to be included in a bridge domain, you can either include the encapsulation vlan-bridge statement under the logical interface, or the encapsulation ethernet-bridge statement under the physical interface.

Note:

On ACX Series routers, a maximum of 1000 logical interfaces can be configured on a physical interface. You can configure a maximum of 3000 bridge domains on an ACX Series router.

By default, each bridge domain maintains a Layer 2 forwarding database that contains media access control (MAC) addresses learned from packets received on the ports that belong to the bridge domain. You can modify Layer 2 forwarding properties, including disabling MAC learning for the entire system or a bridge domain, adding static MAC addresses for specific logical interfaces, and limiting the number of MAC addresses learned by the entire system, the bridge domain, or a logical interface.

You can also configure spanning tree protocols to prevent forwarding loops. .

In Junos OS Release 8.5 and later, you can configure IGMP snooping for a bridge domain. For more information, see the Junos OS Multicast Protocols User Guide.

Integrated routing and bridging (IRB) provides simultaneous support for Layer 2 bridging and Layer 3 routing on the same interface. IRB enables you to route packets to another routed interface or to another bridge domain that has an IRB interface configured. You configure a logical routing interface by including the irb statement at the [edit interfaces] hierarchy level and include that interface in the bridge domain. For more information about how to configure a routing interface, see the Junos OS Network Interfaces Library for Routing Devices.

Note:

You can include only one routing interface in a bridge domain.

To configure a bridge domain with IRB support, include the following statements:

For each bridge domain that you configure, specify a bridge-domain-name. You must also specify the value bridge for the domain-type statement.

For the vlan-id statement, you can specify either a valid VLAN identifier or the none option.

Note:

If you configure a routing interface to support IRB in a bridge domain, you cannot use the all option for the vlan-id statement.

The vlan-tags statement enables you to specify a pair of VLAN identifiers; an outer tag and an inner tag.

Note:

For a single bridge domain, you can include either the vlan-id statement or the vlan-tags statement, but not both.

For MC-LAG bridge domains, when the VLAN identifier is none, use the service-id statement to facilitate media access control (MAC) and Address Resolution Protocol (ARP) synchronization among MC-LAG peers.

To include one or more logical interfaces in the bridge domain, specify the interface name for each Ethernet interface to include that you configured at the [edit interfaces] hierarchy level.

Note:

A maximum of 4000 active logical interfaces are supported on a bridge domain or on each mesh group in a VPLS routing instance configured for Layer 2 bridging.

To associate a routing interface with a bridge domain, include the routing-interface routing-interface-name statement and specify a routing-interface-name you configured at the [edit interfaces irb] hierarchy level. You can configure only one routing interface for each bridge domain. For more information about how to configure logical and routing interfaces, see the Junos OS Network Interfaces Library for Routing Devices.

In Junos OS Release 9.0 and later, IRB interfaces are supported for multicast snooping. For more information about multicast snooping, see the Understanding Multicast Snooping and VPLS Root Protection.

In Junos 11.4 and later, IP multicast is supported on Layer 2 trunk ports through IRB interfaces using the Trio chipset.

In Junos OS Release 9.6 and later, 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 two options, ce and irb. 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. For more information about configuring VPNs, see the Junos VPN Configuration Guide.

Note:

When you configure IRB interfaces in more than one logical system on a device, all of the of the IRB logical interfaces share the same MAC address.

Integrated Bridging and Routing (IRB) interfaces are used to tie together Layer 2 switched and Layer 3 routed domains on MX routers. MX routers support classifiers and rewrite rules on the IRB interface at the [edit class-of-service interfaces irb unit logical-unit-number] level of the hierarchy. All types of classifiers and rewrite rules are allowed, including IEEE 802.1p.

Note:

The IRB classifiers and rewrite rules are used only for routed packets; in other words, it is for traffic that originated in the Layer 2 domain and is then routed through IRB into the Layer 3 domain, or vice versa. Only IEEE classifiers and IEEE rewrite rules are allowed for pure Layer 2 interfaces within a bridge domain.

Configuring VLAN Identifiers for Bridge Domains and VPLS Routing Instances

For a bridge domain that is performing Layer 2 switching only, you do not have to specify a VLAN identifier.

For a bridge domain that is performing Layer 3 IP routing, you must specify either a VLAN identifier or dual VLAN identifier tags.

For a VPLS routing instance, you must specify either a VLAN identifier or dual VLAN identifier tags.

You can configure VLAN identifiers for a bridge domain or a VPLS routing instance in the following ways:

  • By using the input-vlan-map and the output-vlan-map statements at the [edit interfaces interface-name] or [edit logical-systems logical-system-name interfaces interface-name] hierarchy level to configure VLAN mapping. For information about configuring input and output VLAN maps to stack and rewrite VLAN tags in incoming or outgoing frames, see the Junos OS Network Interfaces Library for Routing Devices.

  • By using either the vlan-id statement or the vlan-tags statement to configure a normalizing VLAN identifier. This topic describes how normalizing VLAN identifiers are processed and translated in a bridge domain or a VPLS routing instance.

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.

Note:

You cannot configure VLAN mapping using the input-vlan-map and output-vlan-map statements if you configure a normalizing VLAN identifier for a bridge domain or VPLS routing instance using the vlan-id or vlan-tags statements.

To configure a VLAN identifier for a bridge domain, include either the vlan-id or the vlan-tags statement at the [edit interfaces interface-name unit logic-unit-number family bridge] or [edit logical-systems logical-system-name interfaces interface-name unit logic-unit-number family bridge] hierarchy level, and then include that logical interface in the bridge domain configuration. For more information about configuring a bridge domain, see Configuring a Bridge Domain.

For a VPLS routing instance, include either the vlan-id or vlan-tags statement at the [edit interfaces interface-name unit logic-unit-number] or [edit logical-systems logical-system-name interfaces interface-name unit logic-unit-number] hierarchy level, and then include that logical interface in the VPLS routing instance configuration. For more information about configuring a VPLS routing instance, see the Junos OS VPNs Library for Routing Devices.

Note:

The maximum number of Layer 2 interfaces that you can associate with a bridge domain or a VPLS instance on MX Series routers is 4000.

Note:

For a single bridge domain or VPLS routing instance, you can include either the vlan-id or the vlan-tags statement, but not both. If you do not configure a vlan-id, vlan-tags, or vlan-id-list [ vlan-id-numbers ] for the bridge domain or the VPLS routing instance, the Layer 2 packets received are forwarded to the outbound Layer 2 interface without having the VLAN tag modified unless an output-vlan-map is configured on the Layer 2 interface. This results in a frame being forwarded to a Layer 2 interface with a VLAN tag that is different from what is configured for the Layer 2 interface. Note that a frame received from the Layer 2 interface is still required to match the VLAN tag(s) specified in the interface configuration. The invalid configuration may cause a Layer 2 loop to occur.

The VLAN tags associated with the inbound logical interface are compared with the normalizing VLAN identifier. If the tags are different, they are rewritten as described in Table 1. The source MAC address of a received packet is learned based on the normalizing VLAN identifier.

Note:

You do not have to specify a VLAN identifier for a bridge domain that is performing Layer 2 switching only. To support Layer 3 IP routing, you must specify either a VLAN identifier or a pair of VLAN tags. However, you cannot specify the same VLAN identifier for more than one bridge domain within a routing instance. Each bridge domain must have a unique VLAN identifier.

If the VLAN tags associated with the outbound logical interface and the normalizing VLAN identifier are different, the normalizing VLAN identifier is rewritten to match the VLAN tags of the outbound logical interface, as described in Table 2.

For the packets sent over the VPLS routing instance to be tagged by the normalizing VLAN identifier, include one of the following configuration statements:

  • vlan-id number to tag all packets that are sent over the VPLS virtual tunnel (VT) interfaces with the VLAN identifier.

  • vlan-tags outer number inner number to tag all packets sent over the VPLS VT interfaces with dual outer and inner VLAN tags.

Use the vlan-id none statement to have the VLAN tags removed from packets associated with an inbound logical interface when those packets are sent over VPLS VT interfaces. Note that those packets might still be sent with other customer VLAN tags.

The vlan-id all statement enables you to configure bridging for several VLANs with a minimum amount of configuration. Configuring this statement creates a learning domain for:

  • Each inner VLAN, or learn VLAN, identifier of a logical interface configured with two VLAN tags

  • Each VLAN, or learn VLAN, identifier of a logical interface configured with one VLAN tag

We recommend that you do not use customer VLAN IDs in a VPLS routing instance because customer VLAN IDs are used for learning only.

You should use the service VLAN ID in a VPLS routing instance, as in the following configuration:

Note:

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.

The vlan-id-list [ vlan-id-numbers ] statement enables you to configure bridging for multiple VLANs on a trunk interface. Configuring this statement creates a learning domain for:

  • Each VLAN listed: vlan-id-list [ 100 200 300 ]

  • Each VLAN in a range: vlan-id-list [ 100-200 ]

  • Each VLAN in a list and range combination: vlan-id-list [ 50, 100-200, 300 ]

The following steps outline the process for bridging a packet received over a Layer 2 logical interface when you specify a normalizing VLAN identifier using either the vlan-id number or vlan-tags statement for a bridge domain or a VPLS routing instance:

  1. When a packet is received on a physical port, it is accepted only if the VLAN identifier of the packet matches the VLAN identifier of one of the logical interfaces configured on that port.
  2. The VLAN tags of the received packet are then compared with the normalizing VLAN identifier. If the VLAN tags of the packet are different from the normalizing VLAN identifier, the VLAN tags are rewritten as described in Table 1.
  3. If the source MAC address of the received packet is not present in the source MAC table, it is learned based on the normalizing VLAN identifier.
  4. The packet is then forwarded toward one or more outbound Layer 2 logical interfaces based on the destination MAC address. A packet with a known unicast destination MAC address is forwarded only to one outbound logical interface. For each outbound Layer 2 logical interface, the normalizing VLAN identifier configured for the bridge domain or VPLS routing instance is compared with the VLAN tags configured on that logical interface. If the VLAN tags associated with an outbound logical interface do not match the normalizing VLAN identifier configured for the bridge domain or VPLS routing instance, the VLAN tags are rewritten as described in Table 2.

The tables below show how VLAN tags are applied for traffic sent to and from the bridge domain, depending on how the vlan-id and vlan-tags statements are configured for the bridge domain and on how VLAN identifiers are configured for the logical interfaces in a bridge domain or VPLS routing instance. Depending on your configuration, the following rewrite operations are performed on VLAN tags:

  • pop—Remove a VLAN tag from the top of the VLAN tag stack.

  • pop-pop—Remove both the outer and inner VLAN tags of the frame.

  • pop-swap—Remove the outer VLAN tag of the frame and replace the inner VLAN tag of the frame.

  • swap—Replace the VLAN tag of the frame.

  • push—Add a new VLAN tag to the top of the VLAN stack.

  • push-push—Push two VLAN tags in front of the frame.

  • swap-push—Replace the VLAN tag of the frame and add a new VLAN tag to the top of the VLAN stack.

  • swap-swap—Replace both the outer and inner VLAN tags of the frame.

Table 1 shows specific examples of how the VLAN tags for packets sent to the bridge domain are processed and translated, depending on your configuration. “–” means that the statement is not supported for the specified logical interface VLAN identifier. “No operation” means that the VLAN tags of the received packet are not translated for the specified input logical interface.

Table 1: Statement Usage and Input Rewrite Operations for VLAN Identifiers for a Bridge Domain

VLAN Identifier of Logical Interface

VLAN Configurations for Bridge Domain

vlan-id none

vlan-id 200

vlan-id all

vlan tags outer 100 inner 300

none

No operation

push 200

push 100, push 300

200

pop 200

No operation

No operation

swap 200 to 300, push 100

1000

pop 1000

swap 1000 to 200

No operation

swap 1000 to 300, push 100

vlan-tags outer 2000 inner 300

pop 2000, pop 300

pop 2000, swap 300 to 200

pop 2000

swap 2000 to 100

vlan-tags outer 100 inner 400

pop 100, pop 400

pop 100, swap 400 to 200

pop 100

swap 400 to 300

vlan-id-range 10-100

No operation

vlan-tags outer 200 inner-range 10-100

pop 200

Table 2 shows specific examples of how the VLAN tags for packets sent from the bridge domain are processed and translated, depending on your configuration. “–” means that the statement is not supported for the specified logical interface VLAN identifier. “No operation” means that the VLAN tags of the outbound packet are not translated for the specified output logical interface.

Table 2: Statement Usage and Output Rewrite Operations for VLAN Identifiers for a Bridge Domain

VLAN Identifier of Logical Interface

VLAN Configurations for Bridge Domain

vlan-id none

vlan-id 200

vlan-id all

vlan tags outer 100 inner 300

none

no operation

pop 200

pop 100, pop 300

200

push 200

No operation

No operation

pop 100, swap 300 to 200

1000

push 1000

swap 200 to 1000

No operation

pop 100, swap 300 to 1000

vlan-tags outer 2000 inner 300

push 2000, push 300

swap 200 to 300, push 2000

push 2000

swap 100 to 2000

vlan-tags outer 100 inner 400

push 100, push 400

swap 200 to 400, push 100

push 100

swap 300 to 400

vlan-id-range 10-100

No operation

vlan-tags outer 200 inner-range 10-100

push 200

Configuring VLAN Identifiers for Bridge Domains in ACX Series

You can configure VLAN identifiers for a bridge domain for normalization in the following ways:

  • Configure VLAN mapping by using the input-vlan-map and the output-vlan-map statements at the [edit interfaces interface-name] hierarchy level.

  • Configure an implicit normalizing VLAN identifier under the bridge domain by using the vlan-id statement at the [edit bridge-domains bridge-domain-name] hierarchy level.

Note:

You cannot configure VLAN mapping by using the input-vlan-map and output-vlan-map statements if you configure a normalizing VLAN identifier for a bridge domain by using the vlan-id statement.

You can use the vlan-id-list [ vlan-id-numbers ] statement to configure bridging for multiple VLANs. Configuring this statement creates a bridge domain for:

  • Each VLAN listed—for example, vlan-id-list [ 100 200 300 ]

  • Each VLAN in a range—for example, vlan-id-list [ 100-200 ]

  • Each VLAN in a list and range combination—for example, vlan-id-list [ 50, 100-200, 300 ]

Example: Configuring Basic Layer 2 Switching on MX Series

This example shows how to configure Layer 2 switching with all interfaces participating in a single VLAN.

Requirements

No special configuration beyond device initialization is required before configuring this example.

This example uses an MX Series device to perform Layer 2 switching.

Overview

In this example, a single MX Series device is configured to act as a basic single-VLAN switch. Three connections are in place. The connections from the MX Series device attach to Junos OS routers, but the routers are used here for testing purposes only. In place of routers, you can use any IP networking devices.

Topology

Figure 1 shows the sample network.

Figure 1: Basic Layer 2 SwitchingBasic Layer 2 Switching

CLI Quick Configuration shows the configuration for all of the devices in Figure 1.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device S1

Device R1

Device R2

Device R3

Procedure

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Device S1:

  1. Configure the device interfaces.

  2. Configure the bridge domain.

Results

From configuration mode, confirm your configuration by entering the show interfaces and show bridge-domains commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Confirming the MAC Address Learning

Purpose

Display Layer 2 MAC address information.

Action
  • From Device S1, run the show bridge mac-table command.

  • From Device S1, run the show bridge mac-table extensive command.

Meaning

The output shows that the MAC addresses have been learned.

Making Sure That the Attached Devices Can Reach Each Other

Purpose

Verify connectivity.

Action
Meaning

The output shows that the attached devices have established Layer 3 connectivity, with Device S1 doing transparent Layer 2 bridging.

Checking the Bridge Domain

Purpose

Display bridge domain information.

Action
Meaning

The output shows that bridge domain is active.

Checking the Bridge Statistics

Purpose

Display bridge statistics.

Action
Meaning

The output shows that bridge domain interfaces are sending and receiving packets.

Checking the Bridge Flooding

Purpose

Display bridge flooding information.

Action
Meaning

If the destination MAC address of a packet is unknown to the device (that is, the destination MAC address in the packet does not have an entry in the forwarding table), the device duplicates the packet and floods it on all interfaces in the bridge domain other than the interface on which the packet arrived. This is known as packet flooding and is the default behavior for the device to determine the outgoing interface for an unknown destination MAC address.

Checking Layer 2 Learning

Purpose

Display Layer 2 learning information for all the interfaces.

Action