Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Layer 2 Networking

Overview of Layer 2 Networking

Layer 2, also known as the Data Link Layer, is the second level in the seven-layer OSI reference model for network protocol design. Layer 2 is equivalent to the link layer (the lowest layer) in the TCP/IP network model. Layer2 is the network layer used to transfer data between adjacent network nodes in a wide area network or between nodes on the same local area network.

A frame is a protocol data unit, the smallest unit of bits on a Layer 2 network. Frames are transmitted to and received from devices on the same local area network (LAN). Unilke bits, frames have a defined structure and can be used for error detection, control plane activities and so forth. Not all frames carry user data. The network uses some frames to control the data link itself..

At Layer 2, unicast refers to sending frames from one node to a single other node, whereas multicast denotes sending traffic from one node to multiple nodes, and broadcasting refers to the transmission of frames to all nodes in a network. A broadcast domain is a logical division of a network in which all nodes of that network can be reached at Layer 2 by a broadcast.

Segments of a LAN can be linked at the frame level using bridges. Bridging creates separate broadcast domains on the LAN, creating VLANs, which are independent logical networks that group together related devices into separate network segments. The grouping of devices on a VLAN is independent of where the devices are physically located in the LAN. Without bridging and VLANs, all devices on the Ethernet LAN are in a single broadcast domain, and all the devices detect all the packets on the LAN.

Forwarding is the relaying of packets from one network segment to another by nodes in the network. On a VLAN, a frame whose origin and destination are in the same VLAN are forwarded only within the local VLAN. A network segment is a portion of a computer network wherein every device communicates using the same physical layer.

Layer 2 contains two sublayers:

  • Logical link control (LLC) sublayer, which is responsible for managing communications links and handling frame traffic.

  • Media access control (MAC) sublayer, which governs protocol access to the physical network medium. By using the MAC addresses that are assigned to all ports on a switch, multiple devices on the same physical link can uniquely identify one another.

    The ports, or interfaces, on a switch operate in either access mode, tagged-access, or trunk mode:

    • Access mode ports connect to a network device such as a desktop computer, an IP telephone, a printer, a file server, or a security camera. The port itself belongs to a single VLAN. The frames transmitted over an access interface are normal Ethernet frames. By default, all ports on a switch are in access mode.

    • Tagged-Access mode ports connect to a network device such as a desktop computer, an IP telephone, a printer, a file server, or a security camera. The port itself belongs to a single VLAN. The frames transmitted over an access interface are normal Ethernet frames. By default, all ports on a switch are in access mode. Tagged-access mode accommodates cloud computing, specifically scenarios including virtual machines or virtual computers. Because several virtual computers can be included on one physical server, the packets generated by one server can contain an aggregation of VLAN packets from different virtual machines on that server. To accommodate this situation, tagged-access mode reflects packets back to the physical server on the same downstream port when the destination address of the packet was learned on that downstream port. Packets are also reflected back to the physical server on the downstream port when the destination has not yet been learned. Therefore, the third interface mode, tagged access, has some characteristics of access mode and some characteristics of trunk mode:

    • Trunk mode ports handle traffic for multiple VLANs, multiplexing the traffic for all those VLANs over the same physical connection. Trunk interfaces are generally used to interconnect switches to other devices or switches.

      With native VLAN configured, frames that do not carry VLAN tags are sent over the trunk interface. If you have a situation where packets pass from a device to a switch in access mode, and you want to then send those packets from the switch over a trunk port, use native VLAN mode. Configure the single VLAN on the switch’s port (which is in access mode) as a native VLAN. The switch’s trunk port will then treat those frames differently than the other tagged packets. For example, if a trunk port has three VLANs, 10, 20, and 30, assigned to it with VLAN 10 being the native VLAN, frames on VLAN 10 that leave the trunk port on the other end have no 802.1Q header (tag). There is another native VLAN option. You can have the switch add and remove tags for untagged packets. To do this, you first configure the single VLAN as a native VLAN on a port attached to a device on the edge. Then, assign a VLAN ID tag to the single native VLAN on the port connected to a device. Last, add the VLAN ID to the trunk port. Now, when the switch receives the untagged packet, it adds the ID you specified and sends and receives the tagged packets on the trunk port configured to accept that VLAN.

Including the sublayers, Layer 2 on the QFX Series supports the following functionality:

  • Unicast, multicast, and broadcast traffic.

  • Bridging.

  • VLAN 802.1Q—Also known as VLAN tagging, this protocol allows multiple bridged networks to transparently share the same physical network link by adding VLAN tags to an Ethernet frame.

  • Extension of Layer 2 VLANs across multiple switches using Spanning Tree Protocol (STP) prevents looping across the network.

  • MAC learning, including per-VLAN MAC learning and Layer 2 learning suppression–This process obtains the MAC addresses of all the nodes on a network

  • Link aggregation—This process groups of Ethernet interfaces at the physical layer to form a single link layer interface, also known as a link aggregation group (LAG) or LAG bundle

    Note:

    Link aggregation is not supported on NFX150 devices.

  • Storm control on the physical port for unicast, multicast, and broadcast

    Note:

    Storm control is not supported on NFX150 devices.

  • STP support, including 802.1d, RSTP, MSTP, and Root Guard

Understanding VLANs

A VLAN (virtual LAN) is a collection of network nodes grouped together to form separate broadcast domains. On an Ethernet network that is a single LAN, all traffic is forwarded to all nodes on the LAN. On VLANs, frames whose origin and destination are in the same VLAN are forwarded only within the local VLAN. Frames that are not destined for the local VLAN are the only ones forwarded to other broadcast domains. VLANs thus limit the amount of traffic flowing across the entire LAN, reducing the possible number of collisions and packet retransmissions within a VLAN and on the whole LAN.

On an Ethernet LAN, all network nodes must be physically connected to the same network. On VLANs, the physical location of the nodes is not important; therefore, you can group network devices in any way that makes sense for your organization, such as by department or business function, by types of network nodes, or by physical location. Each VLAN is identified by a single IP subnetwork and by standardized IEEE 802.1Q encapsulation.

To identify which VLAN the traffic belongs to, all frames on an Ethernet VLAN are identified by a tag, as defined in the IEEE 802.1Q standard. These frames are tagged and are encapsulated with 802.1Q tags.

For a simple network that has only a single VLAN, all traffic has the same 802.1Q tag. When an Ethernet LAN is divided into VLANs, each VLAN is identified by a unique 802.1Q tag. The tag is applied to all frames so that the network nodes receiving the frames know to which VLAN a frame belongs. Trunk ports, which multiplex traffic among a number of VLANs, use the tag to determine the origin of frames and where to forward them.

Ethernet Switching and Layer 2 Transparent Mode Overview

Layer 2 transparent mode provides the ability to deploy the firewall without making changes to the existing routing infrastructure. The firewall is deployed as a Layer 2 switch with multiple VLAN segments and provides security services within VLAN segments. Secure wire is a special version of Layer 2 transparent mode that allows bump-in-wire deployment.

A device operates in transparent mode when there are interfaces defined as Layer 2 interfaces. The device operates in route mode (the default mode) if there are no physical interfaces configured as Layer 2 interfaces.

For SRX Series Firewalls, transparent mode provides full security services for Layer 2 switching capabilities. On these SRX Series Firewalls, you can configure one or more VLANs to perform Layer 2 switching. A VLAN is a set of logical interfaces that share the same flooding or broadcast characteristics. Like a virtual LAN (VLAN), a VLAN spans one or more ports of multiple devices. Thus, the SRX Series Firewall can function as a Layer 2 switch with multiple VLANs that participate in the same Layer 2 network.

In transparent mode, the SRX Series Firewall filters packets that traverse the device without modifying any of the source or destination information in the IP packet headers. Transparent mode is useful for protecting servers that mainly receive traffic from untrusted sources because there is no need to reconfigure the IP settings of routers or protected servers.

In transparent mode, all physical ports on the device are assigned to Layer 2 interfaces. Do not route Layer 3 traffic through the device. Layer 2 zones can be configured to host Layer 2 interfaces, and security policies can be defined between Layer 2 zones. When packets travel between Layer 2 zones, security policies can be enforced on these packets.

Table 1 lists the security features that are supported and are not supported in transparent mode for Layer 2 switching.

Table 1: Security Features Supported in Transparent Mode

Mode Type

Supported

Not Supported

Transparent mode

  • Application Layer Gateways (ALGs)

  • Firewall User Authentication (FWAUTH)

  • Intrusion Detection and Prevention (IDP)

  • Screen

  • AppSecure

  • Content Security

  • Network Address Translation (NAT)

  • VPN

Note:

On SRX300, SRX320, SRX340, SRX345, and SRX550M devices, the DHCP server propagation is not supported in Layer 2 transparent mode.

In addition, the SRX Series Firewalls do not support the following Layer 2 features in Layer 2 transparent mode:

  • Spanning Tree Protocol (STP), RSTP, or MSTP—It is the user’s responsibility to ensure that no flooding loops exist in the network topology.

  • Internet Group Management Protocol (IGMP) snooping—Host-to-router signaling protocol for IPv4 used to report their multicast group memberships to neighboring routers and determine whether group members are present during IP multicasting.

  • Double-tagged VLANs or IEEE 802.1Q VLAN identifiers encapsulated within 802.1Q packets (also called “Q in Q” VLAN tagging)—Only untagged or single-tagged VLAN identifiers are supported on SRX Series Firewalls.

  • Nonqualified VLAN learning, where only the MAC address is used for learning within the VLAN—VLAN learning on SRX Series Firewalls is qualified; that is, both the VLAN identifier and MAC address are used.

Also, on SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX550, or SRX650 devices, some features are not supported. (Platform support depends on the Junos OS release in your installation.) The following features are not supported for Layer 2 transparent mode on the mentioned devices:

  • G-ARP on the Layer 2 interface

  • IP address monitoring on any interface

  • Transit traffic through IRB

  • IRB interface in a routing instance

  • IRB interface handling of Layer 3 traffic

    Note:

    The IRB interface is a pseudointerface and does not belong to the reth interface and redundancy group.

Layer 2 Transparent Mode on the SRX5000 Line Module Port Concentrator

The SRX5000 line Module Port Concentrator (SRX5K-MPC) supports Layer 2 transparent mode and processes the traffic when the SRX Series Firewall is configured in Layer 2 transparent mode.

When the SRX5K-MPC is operating in Layer 2 mode, you can configure all interfaces on the SRX5K-MPC as Layer 2 switching ports to support Layer 2 traffic.

The security processing unit (SPU) supports all security services for Layer 2 switching functions, and the MPC delivers the ingress packets to the SPU and forwards the egress packets that are encapsulated by the SPU to the outgoing interfaces.

When the SRX Series Firewall is configured in Layer 2 transparent mode, you can enable the interfaces on the MPC to work in Layer 2 mode by defining one or more logical units on a physical interface with the family address type as Ethernet switching. Later you can proceed with configuring Layer 2 security zones and configuring security policies in transparent mode. Once this is done, next-hop topologies are set up to process ingress and egress packets.

Understanding IPv6 Flows in Transparent Mode on Security Devices

In transparent mode, the SRX Series Firewall filters packets that traverse the device without modifying any of the source or destination information in the packet MAC headers. Transparent mode is useful for protecting servers that mainly receive traffic from untrusted sources because there is no need to reconfigure the IP settings of routers or protected servers.

A device operates in transparent mode when all physical interfaces on the device are configured as Layer 2 interfaces. A physical interface is a Layer 2 interface if its logical interface is configured with the ethernet-switching option at the [edit interfaces interface-name unit unit-number family] hierarchy level. There is no command to define or enable transparent mode on the device. The device operates in transparent mode when there are interfaces defined as Layer 2 interfaces. The device operates in route mode (the default mode) if all physical interfaces are configured as Layer 3 interfaces.

By default, IPv6 flows are dropped on security devices. To enable processing by security features such as zones, screens, and firewall policies, you must enable flow-based forwarding for IPv6 traffic with the mode flow-based configuration option at the [edit security forwarding-options family inet6] hierarchy level. You must reboot the device when you change the mode.

In transparent mode, you can configure Layer 2 zones to host Layer 2 interfaces, and you can define security policies between Layer 2 zones. When packets travel between Layer 2 zones, security policies can be enforced on these packets. The following security features are supported for IPv6 traffic in transparent mode:

The following security features are not supported for IPv6 flows in transparent mode:

  • Logical systems

  • IPv6 GTPv2

  • J-Web interface

  • NAT

  • IPsec VPN

  • With the exception of DNS, FTP, and TFTP ALGs, all other ALGs are not supported.

Configuring VLANs and Layer 2 logical interfaces for IPv6 flows is the same as configuring VLANs and Layer 2 logical interfaces for IPv4 flows. You can optionally configure an integrated routing and bridging (IRB) interface for management traffic in a VLAN. The IRB interface is the only Layer 3 interface allowed in transparent mode. The IRB interface on the SRX Series Firewall does not support traffic forwarding or routing. The IRB interface can be configured with both IPv4 and IPv6 addresses. You can assign an IPv6 address for the IRB interface with the address configuration statement at the [edit interfaces irb unit number family inet6] hierarchy level. You can assign an IPv4 address for the IRB interface with the address configuration statement at the [edit interfaces irb unit number family inet] hierarchy level.

The Ethernet Switching functions on SRX Series Firewalls are similar to the switching features on Juniper Networks MX Series routers. However, not all Layer 2 networking features supported on MX Series routers are supported on SRX Series Firewalls. See Ethernet Switching and Layer 2 Transparent Mode Overview.

The SRX Series Firewall maintains forwarding tables that contain MAC addresses and associated interfaces for each Layer 2 VLAN. The IPv6 flow processing is similar to IPv4 flows. See Layer 2 Learning and Forwarding for VLANs Overview.

Understanding Layer 2 Transparent Mode Chassis Clusters on Security Devices

A pair of SRX Series Firewalls in Layer 2 transparent mode can be connected in a chassis cluster to provide network node redundancy. When configured in a chassis cluster, one node acts as the primary device and the other as the secondary device, ensuring stateful failover of processes and services in the event of system or hardware failure. If the primary device fails, the secondary device takes over processing of traffic.

Note:

If the primary device fails in a Layer 2 transparent mode chassis cluster, the physical ports in the failed device become inactive (go down) for a few seconds before they become active (come up) again.

To form a chassis cluster, a pair of the same kind of supported SRX Series Firewalls combines to act as a single system that enforces the same overall security.

Devices in Layer 2 transparent mode can be deployed in active/backup and active/active chassis cluster configurations.

The following chassis cluster features are not supported for devices in Layer 2 transparent mode:

  • Gratuitous ARP—The newly elected primary in a redundancy group cannot send gratuitous ARP requests to notify network devices of a change in primary role on the redundant Ethernet interface links.

  • IP address monitoring—Failure of an upstream device cannot be detected.

A redundancy group is a construct that includes a collection of objects on both nodes. A redundancy group is primary on one node and backup on the other. When a redundancy group is primary on a node, its objects on that node are active. When a redundancy group fails over, all its objects fail over together.

You can create one or more redundancy groups numbered 1 through 128 for an active/active chassis cluster configuration. Each redundancy group contains one or more redundant Ethernet interfaces. A redundant Ethernet interface is a pseudointerface that contains physical interfaces from each node of the cluster. The physical interfaces in a redundant Ethernet interface must be the same kind—either Fast Ethernet or Gigabit Ethernet. If a redundancy group is active on node 0, then the child links of all associated redundant Ethernet interfaces on node 0 are active. If the redundancy group fails over to the node 1, then the child links of all redundant Ethernet interfaces on node 1 become active.

Note:

In the active/active chassis cluster configuration, the maximum number of redundancy groups is equal to the number of redundant Ethernet interfaces that you configure. In the active/backup chassis cluster configuration, the maximum number of redundancy groups supported is two.

Configuring redundant Ethernet interfaces on a device in Layer 2 transparent mode is similar to configuring redundant Ethernet interfaces on a device in Layer 3 route mode, with the following difference: the redundant Ethernet interface on a device in Layer 2 transparent mode is configured as a Layer 2 logical interface.

The redundant Ethernet interface may be configured as either an access interface (with a single VLAN ID assigned to untagged packets received on the interface) or as a trunk interface (with a list of VLAN IDs accepted on the interface and, optionally, a native-vlan-id for untagged packets received on the interface). Physical interfaces (one from each node in the chassis cluster) are bound as child interfaces to the parent redundant Ethernet interface.

In Layer 2 transparent mode, MAC learning is based on the redundant Ethernet interface. The MAC table is synchronized across redundant Ethernet interfaces and Services Processing Units (SPUs) between the pair of chassis cluster devices.

The IRB interface is used only for management traffic, and it cannot be assigned to any redundant Ethernet interface or redundancy group.

All Junos OS screen options that are available for a single, nonclustered device are available for devices in Layer 2 transparent mode chassis clusters.

Note:

Spanning Tree Protocols (STPs) are not supported for Layer 2 transparent mode. You must ensure that there are no loop connections in the deployment topology.

Configuring Out-of-Band Management on SRX Series Firewalls

You can configure the fxp0 out-of-band management interface on the SRX Series Firewall as a Layer 3 interface, even if Layer 2 interfaces are defined on the device. With the exception of the fxp0 interface, you can define Layer 2 and Layer 3 interfaces on the device’s network ports.

Note:

There is no fxp0 out-of-band management interface on the SRX300, SRX320, and SRX550M devices. (Platform support depends on the Junos OS release in your installation.)

Ethernet Switching

Ethernet switching forwards the Ethernet frames within or across the LAN segment (or VLAN) using the Ethernet MAC address information. Ethernet switching on the SRX1500 device is performed in the hardware using ASICs.

Starting in Junos OS Release 15.1X49-D40, use the set protocols l2-learning global-mode(transparent-bridge | switching) command to switch between the Layer 2 transparent bridge mode and Ethernet switching mode. After switching the mode, you must reboot the device for the configuration to take effect. Table 2 describes the default Layer 2 global mode on SRX Series Firewalls.

Table 2: Default Layer 2 Global Mode on SRX Series Devices

Junos OS Release

Platforms

Default Layer 2 Global Mode

Details

Prior to Junos OS Release 15.1X49-D50

and

Junos OS Release 17.3R1 onwards

SRX300, SRX320, SRX340, and SRX345

Switching mode

None

Junos OS Release 15.1X49-D50 to Junos OS Release 15.1X49-D90

SRX300, SRX320, SRX340, and SRX345

Switching mode

When you delete the Layer 2 global mode configuration on a device, the device is in transparent bridge mode.

Junos OS Release 15.1X49-D100 onwards

SRX300, SRX320, SRX340, SRX345, SRX550, and SRX550M

Switching mode

When you delete the Layer 2 global mode configuration on a device, the device is in switching mode. Configure the set protocols l2-learning global-mode transparent-bridge command under the [edit] hierarchy level to switch to transparent bridge mode. Reboot the device for the configuration to take effect.

Junos OS Release 15.1X49-D50 onwards

SRX1500

Transparent bridge mode

None

The Layer 2 protocol supported in switching mode is Link Aggregation Control Protocol (LACP).

You can configure Layer 2 transparent mode on a redundant Ethernet interface. Use the following commands to define a redundant Ethernet interface:

  • set interfaces interface-name ether-options redundant-parent reth-interface-name

  • set interfaces reth-interface-name redundant-ether-options redundancy-group number

Layer 2 Switching Exceptions on SRX Series Devices

The switching functions on the SRX Series Firewalls are similar to the switching features on Juniper Networks MX Series routers. However, the following Layer 2 networking features on MX Series routers are not supported on SRX Series Firewalls:

  • Layer 2 control protocols—These protocols are used on MX Series routers for Rapid Spanning Tree Protocol (RSTP) or Multiple Spanning Tree Protocol (MSTP) in customer edge interfaces of a VPLS routing instance.

  • Virtual switch routing instance—The virtual switching routing instance is used on MX Series routers to group one or more VLANs.

  • Virtual private LAN services (VPLS) routing instance—The VPLS routing instance is used on MX Series routers for point-to-multipoint LAN implementations between a set of sites in a VPN.

Understanding Unicast

Unicasting is the act of sending data from one node of the network to another. In contrast, multicast transmissions send traffic from one data node to multiple other data nodes.

Unknown unicast traffic consists of unicast frames with unknown destination MAC addresses. By default, the switch floods these unicast frames that are traveling in a VLAN to all interfaces that are members of the VLAN. Forwarding this type of traffic to interfaces on the switch can trigger a security issue. The LAN is suddenly flooded with packets, creating unnecessary traffic that leads to poor network performance or even a complete loss of network service. This is known as a traffic storm.

To prevent a storm, you can disable the flooding of unknown unicast packets to all interfaces by configuring one VLAN or all VLANs to forward any unknown unicast traffic to a specific trunk interface. (This channels the unknown unicast traffic to a single interface.)

Understanding Layer 2 Broadcasting on Switches

In a Layer 2 network, broadcasting refers to sending traffic to all nodes on a network.

Layer 2 broadcast traffic stays within a local area network (LAN) boundary; known as the broadcast domain. Layer 2 broadcast traffic is sent to the broadcast domain using a MAC address of FF:FF:FF:FF:FF:FF. Every device in the broadcast domain recognizes this MAC address and passes the broadcast traffic on to other devices in the broadcast domain, if applicable. Broadcasting can be compared to unicasting (sending traffic to a single node) or multicasting (delivering traffic to a group of nodes simultaneously).

Layer 3 broadcast traffic, however, is sent to all devices in a network using a broadcast network address. For example, if your network address is 10.0.0.0, the broadcast network address is 10.255.255.255. In this case, only devices that belong to the 10.0.0.0 network receive the Layer 3 broadcast traffic. Devices that do not belong to this network drop the traffic.

Broadcasting is used in the following situations:

  • Address Resolution Protocol (ARP) uses broadcasting to map MAC addresses to IP addresses. ARP dynamically binds the IP address (the logical address) to the correct MAC address. Before IP unicast packets can be sent, ARP discovers the MAC address used by the Ethernet interface where the IP address is configured.

  • Dynamic Host Configuration Protocol (DHCP) uses broadcasting to dynamically assign IP addresses to hosts on a network segment or subnet.

  • Routing protocols use broadcasting to advertise routes.

Excessive broadcast traffic can sometimes create a broadcast storm. A broadcast storm occurs when messages are broadcast on a network and each message prompts a receiving node to respond by broadcasting its own messages on the network. This, in turn, prompts further responses that create a snowball effect. The LAN is suddenly flooded with packets, creating unnecessary traffic that leads to poor network performance or even a complete loss of network service.

Using the Enhanced Layer 2 Software CLI

Enhanced Layer 2 Software (ELS) provides a uniform CLI for configuring and monitoring Layer 2 features on QFX Series switches, EX Series switches, and other Juniper Networks devices, such as MX Series routers. With ELS, you configure Layer 2 features in the same way on all these Juniper Networks devices.

This topic explains how to know if your platform is running ELS. It also explains how to perform some common tasks using the ELS style of configuration.

Understanding Which Devices Support ELS

ELS is automatically supported if your device is running a Junos OS release that supports it. You do not need to take any action to enable ELS, and you cannot disable ELS. See Feature Explorer for information about which platforms and releases support ELS.

Understanding How to Configure Layer 2 Features Using ELS

Because ELS provides a uniform CLI, you can now perform the following tasks on supported devices in the same way:

Configuring a VLAN

You can configure one or more VLANs to perform Layer 2 bridging. The Layer 2 bridging functions include integrated routing and bridging (IRB) for support for Layer 2 bridging and Layer 3 IP routing on the same interface. EX Series and QFX Series switches can function as Layer 2 switches, each with multiple bridging, or broadcast, domains that participate in the same Layer 2 network. You can also configure Layer 3 routing support for a VLAN.

To configure a VLAN:

  1. Create the VLAN by setting a unique VLAN name and configuring the VLAN ID:

    Using the VLAN ID list option, you can optionally specify a range of VLAN IDs.

  2. Assign at least one interface to the VLAN:

Configuring the Native VLAN Identifier

EX Series and QFX Series switches support receiving and forwarding routed or bridged Ethernet frames with 802.1Q VLAN tags. Typically, trunk ports, which connect switches to each other, accept untagged control packets, but do not accept untagged data packets. You can enable a trunk port to accept untagged data packets by configuring a native VLAN ID on the interface on which you want the untagged data packets to be received.

To configure the native VLAN ID:

  1. On the interface on which you want untagged data packets to be received, set the interface mode to trunk, which specifies that the interface is in multiple VLANs and can multiplex traffic between different VLANs.
  2. Configure the native VLAN ID and assign the interface to the native VLAN ID:
  3. Assign the interface to the native VLAN ID:

Configuring Layer 2 Interfaces

To ensure that your high-traffic network is tuned for optimal performance, explicitly configure some settings on the switch's network interfaces.

To configure a Gigabit Ethernet interface or a 10-Gigabit Ethernet interface as a trunk interface:

To configure a Gigabit Ethernet interface or a 10-Gigabit Ethernet interface as a access interface:

To assign an interface to VLAN:

Configuring Layer 3 Interfaces

To configure a Layer 3 interface, you must assign an IP address to the interface. You assign an address to an interface by specifying the address when you configure the protocol family. For the inet or inet6 family, configure the interface IP address.

You can configure interfaces with a 32-bit IP version 4 (IPv4) address and optionally with a destination prefix, sometimes called a subnet mask. An IPv4 address utilizes a 4-octet dotted decimal address syntax (for example, 192.168.1.1). An IPv4 address with destination prefix utilizes a 4-octet dotted decimal address syntax with a destination prefix appended (for example, 192.168.1.1/16).

To specify an IP4 address for the logical unit:

You represent IP version 6 (IPv6) addresses in hexadecimal notation by using a colon-separated list of 16-bit values. You assign a 128-bit IPv6 address to an interface.

To specify an IP6 address for the logical unit:

Configuring an IRB Interface

Integrated routing and bridging (IRB) provides support for Layer 2 bridging and Layer 3 IP routing on the same interface. IRB enables you to route packets to another routed interface or to another VLAN that has a Layer 3 protocol configured. IRB interfaces enable the device to recognize packets that are being sent to local addresses so that they are bridged (switched) whenever possible and are routed only when necessary. Whenever packets can be switched instead of routed, several layers of processing are eliminated. An interface named irb functions as a logical router on which you can configure a Layer 3 logical interface for VLAN. For redundancy, you can combine an IRB interface with implementations of the Virtual Router Redundancy Protocol (VRRP) in both bridging and virtual private LAN service (VPLS) environments.

To configure an IRB interface:

  1. Create a Layer 2 VLAN by assigning it a name and a VLAN ID:
  2. Create an IRB logical interface:
  3. Associate the IRB interface with the VLAN:

Configuring an Aggregated Ethernet Interface and Configuring LACP on That Interface

Use the link aggregation feature to aggregate one or more links to form a virtual link or link aggregation group (LAG). The MAC client can treat this virtual link as if it were a single link to increase bandwidth, provide graceful degradation as failure occurs, and increase availability.

To configure an aggregated Ethernet interface:

  1. Specify the number of aggregated Ethernet interfaces to be created:
  2. Specify the name of the link aggregation group interface:
  3. Specify the minimum number of links for the aggregated Ethernet interface (aex)– that is, the defined bundle– to be labeled up:
  4. Specify the link speed for the aggregated Ethernet bundle:
  5. Specify the members to be included within the aggregated Ethernet bundle:
  6. Specify an interface family for the aggregated Ethernet bundle:

For aggregated Ethernet interfaces on the device, you can configure the Link Aggregation Control Protocol (LACP). LACP bundles several physical interfaces to form one logical interface. You can configure aggregated Ethernet with or without LACP enabled.

When LACP is enabled, the local and remote sides of the aggregated Ethernet links exchange protocol data units (PDUs), containing information about the state of the link. You can configure Ethernet links to actively transmit PDUs, or you can configure the links to passively transmit them, sending out LACP PDUs only when they receive them from another link. One side of the link must be configured as active for the link to be up.

To configure LACP:

  1. Enable one side of the aggregated Ethernet link as active:

  2. Specify the interval at which the interfaces send LACP packets:

Understanding ELS Configuration Statement and Command Changes

ELS was introduced in Junos OS Release 12.3R2 for EX9200 switches. ELS changes the CLI for some of the Layer 2 features on supported EX Series and QFX Series switches.

The following sections provide a list of existing commands that were moved to new hierarchy levels or changed on EX Series switches as part of this CLI enhancement effort. These sections are provided as a high-level reference only. For detailed information about these commands, use the links to the configuration statements provided or see the technical documentation.

Changes to the ethernet-switching-options Hierarchy Level

This section outlines the changes to the ethernet-switching-options hierarchy level.

Note:

The ethernet-switching-options hierarchy level has been renamed as switch-options.

Table 3: Renaming the ethernet-switching-options hierarchy

Original Hierarchy

Changed Hierarchy

ethernet-switching-options {
    authentication-whitelist {
        ...
    }
}
switch-options {
    ...
    authentication-whitelist {
        ...
    }
}
ethernet-switching-options {
     interfaces interface-name {
        no-mac-learning;
        ...
    }
}
switch-options {
     interfaces interface-name {
         no-mac-learning;
        ...
    }
}
ethernet-switching-options {
    unknown-unicast-forwarding {
        (...)
        }
}
switch-options {
    unknown-unicast-forwarding {
        (...)
        }
}
ethernet-switching-options {
     voip {
         interface (all | [interface-name | access-ports]) {
             forwarding-class (assured-forwarding | best-effort | expedited-forwarding | network-control);
             vlan vlan-name;
                ...
        }
    }
}
switch-options {
     voip {
         interface (all | [interface-name | access-ports]) {
             forwarding-class (assured-forwarding | best-effort | expedited-forwarding | network-control);
             vlan vlan-name;
                ...
        }
    }
}
Table 4: RTG Statements

Original Hierarchy

Changed Hierarchy

ethernet-switching-options {
    redundant-trunk-group {
        group name {
            description;
            interface interface-name {
                primary;
            }
            preempt-cutover-timer seconds;
            ...
        }
    }
}
switch-options {
    redundant-trunk-group {
        group name {
            description;
            interface interface-name {
                primary;
            }
            preempt-cutover-timer seconds;
            ...
        }
    }
}
Table 5: Deleted Statements

Original Hierarchy

Changed Hierarchy

ethernet-switching-options {
    mac-notification {
        notification-interval seconds;
        ...
    }
}

The statements have been removed from the switch-options hierarchy.

ethernet-switching-options {
     traceoptions {
        file filename <files number> <no-stamp> <replace> 
<size size> <world-readable | no-world-readable>;
        flag flag <disable>;
        ...
    }
}

The statements have been removed from the switch-options hierarchy.

ethernet-switching-options {
    port-error-disable {
        disable-timeout timeout;
        ...
    }
}
Note:

The port-error-disable statement has been replaced with a new statement.

interfaces interface-name family ethernet-switching {
    recovery-timeout seconds;
}

Changes to the Port Mirroring Hierarchy Level

Note:

Statements have moved from the ethernet-switching-options hierarchy level to the forwarding-options hierarchy level.

Table 6: Port Mirroring hierarchy

Original Hierarchy

Changed Hierarchy

ethernet-switching-options {
    analyzer   {
         name {
            ...
        }
    }
}
forwarding-options {
    analyzer   {
         name {
            ...
        }
    }
}

Changes to the Layer 2 Control Protocol Hierarchy Level

The Layer 2 control protocol statements have moved from the ethernet-switching-options hierarchy to the protocols hierarchy.

Table 7: Layer 2 Control Protocol

Original Hierarchy

Changed Hierarchy

ethernet-switching-options {
     bpdu-block {
        ...
    }
}
protocols {
     layer2-control {
        bpdu-block {
            ...
        }
    }
}

Changes to the dot1q-tunneling Statement

The dot1q-tunneling statement has been replaced with a new statement and moved to a different hierarchy level.

Table 8: dot1q-tunneling

Original Hierarchy

Changed Hierarchy

ethernet-switching-options {
     dot1q-tunneling {
         ether-type (0x8100 | 0x88a8 | 0x9100);
            ...
    }
}
interfaces interface-name {
    ether-options {
        ethernet-switch-profile {
            tag-protocol-id [tpids];
        }
    }
}
interfaces interface-name {
    aggregated-ether-options {
        ethernet-switch-profile {
            tag-protocol-id [tpids];
        }
    }
}

Changes to the L2 Learning Protocol

The mac-table-aging-time statement has been replaced with a new statement and moved to a different hierarchy level.

Table 9: mac-table-aging-time statement

Original Hierarchy

Changed Hierarchy

ethernet-switching-options {
    mac-table-aging-time seconds;
        ...
}
protocols {
     l2-learning {
        global-mac-table-aging-time seconds;
            ...
    }
}

Changes to Nonstop Bridging

The nonstop-bridging statement has moved to a different hierarchy level.

Table 10: Nonstop Bridging statement

Original Hierarchy

Changed Hierarchy

ethernet-switching-options {
    nonstop-bridging;
}
protocols {
    layer2-control {
        nonstop-bridging {
        }
    }
}

Changes to Port Security and DHCP Snooping

Port security and DHCP snooping statements have moved to different hierarchy levels.

Note:

The statement examine-dhcp does not exist in the changed hierarchy. DHCP snooping is now enabled automatically when other DHCP security features are enabled on a VLAN. See Configuring Port Security (ELS) for additional information.

Table 11: Port Security statements

Original Hierarchy

Changed Hierarchy

 ethernet-switching-options {
     secure-access-port {
         interface (all | interface-name) {
            (dhcp-trusted | no-dhcp-trusted );
             static-ip  ip-address {
                 mac mac-address; 
                 vlan  vlan-name;
            }
        }
         vlan (all | vlan-name) {
            (arp-inspection | no-arp-inspection );
             dhcp-option82 {
                disable;
                     circuit-id {
                     prefix hostname;
                     use-interface-description;
                     use-vlan-id;
                }
                 remote-id {
                     prefix (hostname | mac | none);
                     use-interface-description;
                     use-string string;
                }
                 vendor-id [string];
            }
            (examine-dhcp | no-examine-dhcp);
            }
            (ip-source-guard | no-ip-source-guard);
        }
    }
vlans vlan-name forwarding-options{
    dhcp-security {
        arp-inspection; 
        group group-name {
            interfaceiinterface-name {
                static-ip ip-address {
                    mac mac-address;
                }
            }
            overrides {
                no-option82; 
                trusted; 
            }
        }
        ip-source-guard; 
        no-dhcp-snooping; 
        option-82 {
            circuit-id {
                prefix {
                    host-name; 
                    routing-instance-name;
                }
                use-interface-description (device | logical); 
                use-vlan-id; 
            }
            remote-id {
                host-name; 
                use-interface-description (device | logical); 
                use-string string;
            }
            vendor-id {
                use-string string;
            }
        }
    }
Tip:

For allowed mac configuration, the original hierarchy statement set ethernet-switching-options secure-access-port interface ge-0/0/2 allowed-mac 00:05:85:3A:82:8 is replaced by the ELS command set interfaces ge-0/0/2 unit 0 accept-source-mac mac-address 00:05:85:3A:82:8

Note:

DHCP snooping statements have moved to a different hierarchy level.

Table 12: DHCP Snooping Statements

Original Hierarchy

Changed Hierarchy

 ethernet-switching-options {
     secure-access-port {
        dhcp-snooping-file {
            location local_pathname | remote_URL;
            timeout seconds;
            write-interval seconds;
        }
system [
    processes [
        dhcp-service
            dhcp-snooping-file local_pathname | remote_URL;
                write-interval interval;
            }
    }

Changes to Configuring VLANs

The statements for configuring VLANs have moved to a different hierarchy level.

Note:

Starting with Junos OS Release 14.1X53-D10 for EX4300 and EX4600 switches, when enabling xSTP, you can enable it on some or all interfaces included in a VLAN. For example, if you configure VLAN 100 to include interfaces ge-0/0/0, ge-0/0/1, and ge-0/0/2, and you want to enable MSTP on interfaces ge-0/0/0 and ge-0/0/2, you can specify the set protocols mstp interface ge-0/0/0 and set protocols mstp interface ge-0/0/2 commands. In this example, you did not explicitly enable MSTP on interface ge-0/0/1; therefore, MSTP is not enabled on this interface.

Table 13: VLAN hierarchy

Original Hierarchy

Changed Hierarchy

 ethernet-switching-options {
     secure-access-port vlan (all | vlan-name{
        mac-move-limit
    }
vlans vlan-name  switch-options {
    mac-move-limit
}
ethernet-switching-options {
    static {
        vlan vlan-id {
            mac mac-address next-hop interface-name;
            ...
        }
    }
}
Note:

Statement is replaced with a new statement and has moved to a different hierarchy level.

vlans {
    vlan-name {
        switch-options {
            interface interface-name {
                static-mac mac-address;
                    ...
            }
        }
    }
}
vlans {
    vlan-name {
        interface interface-name { 
            egress;
            ingress;
            mapping (native (push | swap) | policy | tag (push | swap));
            pvlan-trunk;
            ...
        }
    }
}

These statements have been removed. You can assign interfaces to a VLAN using the [edit interfaces interface-name unit logical-unit-number family ethernet-switching vlan members vlan-name] hierarchy.

vlans {
    vlan-name {
        isolation-id id-number;
            ...
    }
}

Statements have been removed.

vlans {
    vlan-name {
        interface vlan.logical-interface-number;
            ...
    }
}
Note:

Syntax is changed.

vlans {
    vlan-name {
        interface irb.logical-interface-number;
            ...
    }
}
vlans {
    vlan-name {
        l3-interface-ingress-counting layer-3-interface-name; 
            ...
    }
}

Statement is removed. Ingress traffic is automatically tracked.

vlans {
    vlan-name {
        no-local-switching;
            ...
    }
}

Statement is removed.

vlans {
    vlan-name {
        no-mac-learning;
            ...
    }
}

Statement has been moved to different hierarchy.

vlans {
    vlan-name {
        switch-options {
            no-mac-learning limit 
                ...
        }
    }
}
vlans {
    vlan-name {
        primary-vlan vlan-name;
            ...
    }
}

Statement has been removed.

vlans {
    vlan-name {
        vlan-prune;
            ...
    }
}

Statement is removed.

vlans {
    vlan-name {
        vlan-range vlan-id-low-vlan-id-high;
            ...
    }
}
Note:

Statement has been replaced with a new statement.

vlans {
    vlan-name {
        vlan-id-list [vlan-id-numbers];
            ...
    }
}
vlans {
    vlan-name {
        l3-interface vlan.logical-interface-number;
            ...
    }
}
Note:

Syntax is changed.

vlans {
    vlan-name {
        interface irb.logical-interface-number;
            ...
    }
}
Table 14: Statements Moved to a Different Hierarchy

Original Hierarchy

Changed Hierarchy

vlans {
    vlan-name {
        dot1q-tunneling {
            customer-vlans (id | native | range);
            layer2-protocol-tunneling all | protocol-name {
                drop-threshold number;
                shutdown-threshold number;
                    ...
            }
        }
    }
}

For dot1q-tunneling:

interface interface-name {
    encapsulation extended-vlan-bridge; 
    flexible-vlan-tagging; 
    native-vlan-id number; 
    unit logical-unit-number {
        input-vlan-map action; 
        output-vlan-map action;
        vlan-id number;
        vlan-id-list [vlan-id vlan-idvlan-id];
    }
}

For layer2-protocol-tunneling (MAC rewrite enabled on an interface):

protocols {
    layer2-control {
        mac-rewrite {
            interface interface-name {
                protocol {
                    ...
                }
            }
        }
    }
}
vlans {
    vlan-name {
        filter{
            input  filter-name
            output  filter-name;
            ...
        }
    }
}
vlans {
    vlan-name {
        forwarding-options {
            filter{
                input  filter-name
                output  filter-name;
                ...
            }
        }
    }
}
vlans {
    vlan-name {
        mac-limit limit action action;
            ...
    }
}
vlans {
    vlan-name {
        switch-options {
            interface-mac-limit limit {
                packet-action action;
                ...
            }
        }
    }
}
vlans {
    vlan-name {
        switch-options {
            interface interface-name {
                interface-mac-limit limit {
                    packet-action action;
                    ...
                }
            }
        }
    }
}
vlans {
    vlan-name {
        mac-table-aging-time seconds;
            ...
    }
}
protocols {
     l2-learning {
        global-mac-table-aging-time seconds;
            ...
    }
}

Changes to Storm Control Profiles

Storm control is configured in two steps. The first step is to create a storm control profile at the [edit forwarding-options] hierarchy level, and the second step is to bind the profile to a logical interface at the [edit interfaces] hierarchy level. See Example: Configuring Storm Control to Prevent Network Outages on EX Series Switches for the changed procedure.

Table 15: Changes to the Storm Control Profile hierarchy level

Original Hierarchy

Changed Hierarchy

ethernet-switching-options {
    storm-control {
        (...)
        }
}
forwarding-options {
    storm-control-profiles profile-name {
        (...)
        }
    }
interfaces interface-name unit number family ethernet-switching {
    storm-control storm-control-profile;
}

Changes to the Interfaces Hierarchy

Note:

Statements have been moved to a different hierarchy.

Table 16: Changes to the Interfaces hierarchy

Original Hierarchy

Changed Hierarchy

interfaces interface-name {
    ether-options {
        link-mode mode;
        speed (auto-negotiation | speed)
    }
}
interfaces interface-name {
    link-mode mode;
    speed speed)
}
interfaces interface-name {
    unit logical-unit-number {
        family ethernet-switching {
            native-vlan-id vlan-id 
        }
    }
}
interfaces interface-name {
    native-vlan-id vlan-id
}
interfaces interface-name {
    unit logical-unit-number {
        family ethernet-switching {
            port-mode mode 
        }
    }
}
Note:

Statement has been replaced with a new statement.

interfaces interface-name {
    unit logical-unit-number {
        family ethernet-switching {
            interface-mode mode 
        }
    }
}
interfaces vlan
Note:

Statement has been replaced with a new statement.

interfaces irb

Changes to IGMP Snooping

Table 17: IGMP Snooping hierarchy

Original Hierarchy

Changed Hierarchy

protocols {
    igmp-snooping {
        traceoptions  {
            file filename <files number> <no-stamp> <replace> <size maximum-file-size> <world-readable | no-world-readable>;
            flag flag <flag-modifier> <disable>;
        }
        vlan (all | vlan-identifier) {
            disable;
            data-forwarding {
                receiver {
                    install;
                    source-vlans vlan-name;
                }
                source {
                    groups ip-address;
                }
            }
            immediate-leave;
            interface (all | interface-name) {
                multicast-router-interface;
                static {
                    group multicast-ip-address;
                }
            }
            proxy {
                source-address ip-address;
            }
            robust-count number;
        }
    }
}
protocols {
    igmp-snooping {
        vlan vlan-name {
                data-forwarding {
                    receiver {
                        install;
                        source-list vlan-name;
                        translate;
                    }
                    source {
                        groups ip-address;
                    }
                }
            immediate-leave;
                interface (all | interface-name) {
                    group-limit <1..65535>
                    host-only-interface
                    multicast-router-interface;
                    immediate-leave;
                    static {
                        group multicast-ip-address {
                            source <>
                        }
                    }
                }
            }
            l2-querier {
                source-address ip-address;
            }
            proxy {
                source-address ip-address;
            }
            query-interval number;
            query-last-member-interval number;
            query-response-interval number;
            robust-count number;
            traceoptions  {
                file filename <files number> <no-stamp> <replace> <size maximum-file-size> <world-readable | no-world-readable>;
                flag flag <flag-modifier>;
            }
        }
    }
}

Enhanced Layer 2 CLI Configuration Statement and Command Changes for Security Devices

Starting in Junos OS Release 15.1X49-D10 and Junos OS Release 17.3R1, some Layer 2 CLI configuration statements are enhanced, and some commands are changed. Table 18 and Table 19 provide lists of existing commands that have been moved to new hierarchies or changed on SRX Series Firewalls as part of this CLI enhancement effort. The tables are provided as a high-level reference only. For detailed information about these commands, see CLI Explorer.

Table 18: Enhanced Layer 2 Configuration Statement Changes

Original Hierarchy

Changed Hierarchy

Hierarchy Level

Change Description

bridge-domains bridge-domain--name {
    ...
    }
}
vlans vlans-name {
    ...
    }
}

[edit]

Hierarchy renamed.

bridge-domains bridge-domain--name {
    vlan-id-list [vlan-id] ;
}
vlans vlans-name {
    vlan members [vlan-id] ;
}

[edit vlans vlans-name]

Statement renamed.

bridge-options {
    interface interface-name { 
        encapsulation-type;
        ignore-encapsulation-mismatch;
        pseudowire-status-tlv;
        static-mac mac-address {
            vlan-id vlan-id;
        }
    }
    mac-table-aging-time seconds;
    mac-table-size {
        number;
        packet-action drop;
    }
}
switch-options {
    interface interface-name { 
        encapsulation-type;
        ignore-encapsulation-mismatch;
        pseudowire-status-tlv;
        static-mac mac-address {
            vlan-id vlan-id;
        }
    }
    mac-table-aging-time seconds;
    mac-table-size {
        number;
        packet-action drop;
    }
}

[edit vlans vlans-name]

Statement renamed.

bridge {
    block-non-ip-all;
    bpdu-vlan-flooding;
    bypass-non-ip-unicast;
    no-packet-flooding {
        no-trace-route;
    }
}
ethernet-switching {
    block-non-ip-all;
    bpdu-vlan-flooding;
    bypass-non-ip-unicast;
    no-packet-flooding {
        no-trace-route;
    }
}

[edit security flow]

Statement renamed.

family {
    bridge {
        bridge-domain-type (svlan| bvlan);
    ...
family {
    ethernet-switching {
    ...

[edit interfaces interface-name ] unit unit-number

Hierarchy renamed.

...
routing-interface  irb.0;
...
...
l3-interface  irb.0;
...

[edit vlans vlans-name]

Statement renamed.

Table 19: Enhanced Layer 2 Operational Command Changes

Original Operational Command

Modified Operational Command

clear bridge mac-table

clear ethernet-switching table

clear bridge mac-table persistent-learning

clear ethernet-switching table persistent-learning

show bridge domain

show vlans

show bridge mac-table

show ethernet-switching table

show l2-learning interface

show ethernet-switching interface

Note:

There is no fxp0 out-of-band management interface on the SRX300, SRX320, and SRX500HM devices. (Platform support depends on the Junos OS release in your installation.)

Layer 2 Next Generation Mode for ACX Series

The Layer 2 Next Generation mode, also called Enhanced Layer 2 Software (ELS), is supported on ACX5048, ACX5096, and ACX5448 routers for configuring Layer 2 features. The Layer 2 CLI configurations and show commands for ACX5048, ACX5096, ACX5448, ACX710, ACX7100, ACX7024, and ACX7509 routers differ from those for other ACX Series routers (ACX1000, ACX1100, ACX2000, ACX2100, ACX2200, and ACX4000) and MX Series routers.

Table 20 shows the differences in CLI hierarchy for configuring Layer 2 features in Layer 2 next generation mode.

Table 20: Differences in CLI Hierarchy for Layer 2 Features in Layer 2 Next Generation Mode

Feature

ACX1000, ACX1100, ACX2000, ACX2100, ACX2200, ACX4000, and MX Series Routers

ACX5048, ACX5096, ACX5448, ACX710, ACX7100, ACX7024, and ACX7509 Routers

Bridge Domain

[edit bridge-domains bridge-domain-name]

[edit vlans vlan-name]

Family bridge

[edit interfaces interface-name unit unit-number family bridge]

[edit interfaces interface-name unit unit-number family ethernet-switching]

Layer 2 options

[edit bridge-domains bridge-domain-name bridge-options]

[edit vlans vlan-name switch-options]

Ethernet options

[edit interfaces interface-name gigether-options]

[edit interfaces interface-name ether-options]

Integrated routing and bridging (IRB)

[edit bridge-domains bridge-domain-name] routing-interface irb.unit;

[edit vlans vlan-name] l3-interface irb.unit;

Storm control

[edit vlans vlan-name forwarding-options flood filter filter-name]

[edit forwarding-options storm-control-profiles]

[edit interfaces interface-name ether-options] storm-control name; recovery-timeout interval;

Internet Group Management Protocol (IGMP) snooping

[edit bridge-domains bridge-domain-name protocols igmp-snooping]

[edit protocols igmp-snooping vlan vlan-name]

Family bridge firewall filter

[edit firewall family bridge]

[edit firewall family ethernet-switching]

Table 21 shows the differences in show commands for Layer 2 features in Layer 2 next generation mode.

Table 21: Differences in show Commands for Layer 2 Features in Layer 2 Next Generation Mode

Feature

ACX1000, ACX1100, ACX2000, ACX2100, ACX2200, ACX4000, and MX Series Routers

ACX5048, ACX5096, ACX5448, ACX710, ACX7100, ACX7024, and ACX7509 Routers

VLAN

show bridge-domain

show vlans

MAC table

show bridge mac-table

show ethernet-switching table

MAC table options

show bridge mac-table(MAC address, bridge-domain name, interface, VLAN ID, and instance)

show ethernet-switching table

Switch port listing with VLAN assignments

show l2-learning interface

show ethernet-switching interfaces

Kernel state of flush database

show route forwarding-table family bridge

show route forwarding-table family ethernet-switching

Flexible Ethernet Services Encapsulation to Support the Service Provider and Enterprise Styles of Configuration on ACX7000 Series of Routers

Flexible Ethernet services is a type of encapsulation that enables a physical interface to specify Ethernet encapsulations at the logical interface level. Each logical interface can have a different Ethernet encapsulation. Defining multiple per-unit Ethernet encapsulations makes it easier to customize Ethernet-based services to multiple hosts connected to the same physical interface.

An Ethernet interface that is not encapsulated with flexible Ethernet services and is operating in Layer 2 mode is limited to a single logical interface unit (0). Bridging is enabled on the interface by configuring ethernet-switching as the interface family on unit 0. The ethernet-switching family can be configured only on logical interface unit 0, and no other logical units can be defined on that interface.

Some switching features, however, cannot be configured on logical interface unit 0. Features such as Q-in-Q tunneling require the logical interface to transmit VLAN-tagged frames. To enable a logical interface to receive and forward Ethernet frames tagged with a matching VLAN ID, you must bind the logical interface to that VLAN. These features must be configured on a logical interface unit other than 0, because you cannot bind a VLAN ID to unit 0.

When you encapsulate an interface by using flexible Ethernet services, you can configure a logical interface unit other than 0 with family ethernet-switching. You can also configure other logical interfaces on that same interface with different types of Ethernet encapsulations. This enables logical interfaces that are bound to a VLAN ID to coexist with logical interfaces configured with family ethernet-switching.

The flexible-ethernet-services statement allows configuration of both service-provider-style logical interfaces and enterprise-style logical interfaces.

For example, if you configure PVLAN on the same physical interface on which you are configuring Q-in-Q tunneling, you can use flexible ethernet services to support the enterprise style of configuration for PVLAN, using family ethernet-switching, along with vlan-bridge encapsulation for Q-in-Q tunneling.

Best Practice:

We recommend you configure the following statements using groups when configuring devices that function as hardware VTEPs:

  • set interfaces interface-name flexible-vlan-tagging

  • set interfaces interface-name encapsulation extended-vlan-bridge

  • set interfaces interface-name native-vlan-id vlan-id

Service Provider Style of Configuration

To configure the interface to support the service provider style of configuration:

  1. Enable flexible Ethernet services encapsulation on the interface.
  2. Enable the interface to transmit packets with 802.1Q VLAN single-tagged and dual-tagged frames:
  3. Configure a logical interface (unit) on the interface:
    Note:

    Do not use logical interface unit 0. You must later bind a VLAN tag ID to the unit you specify in this step, and you cannot bind a VLAN tag ID to unit 0. It is a best practice to match the unit number to the VLAN ID to which the interface is bound.

  4. Encapsulate the logical interface for service provider style bridging configuration—for example, use vlan-bridge encapsulation on an interface to be used for Q-in-Q tunneling. (If you were configuring the interface only for Q-in-Q tunneling, you would use encapsulation extended-vlan-bridge on the physical interface.)
  5. Bind the logical interface from the preceding step to a VLAN ID:
  6. Configure another logical interface. (If you were configuring just PVLAN, we would recommend that you configure a single logical interface for all PVLAN domains on an interface.)

Enterprise Style of Configuration

To configure the interface to support the enterprise style of configuration:

  1. Enable flexible Ethernet services encapsulation on the interface.
  2. Enable the interface to transmit packets with 802.1Q VLAN single-tagged and dual-tagged frames:
  3. Configure a logical interface (unit) on the interface:
  4. Enable the logical interface in the preceding step for enterprise style bridging configuration:
  5. Assign VLAN membership to the logical interface:
  6. Configure the interface as a trunk interface to transmit frames with 802.1Q VLAN tags:

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
15.1X49-D40
Starting in Junos OS Release 15.1X49-D40, use the set protocols l2-learning global-mode(transparent-bridge | switching) command to switch between the Layer 2 transparent bridge mode and Ethernet switching mode.
15.1X49-D10
Starting in Junos OS Release 15.1X49-D10 and Junos OS Release 17.3R1, some Layer 2 CLI configuration statements are enhanced, and some commands are changed.