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

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 devices, transparent mode provides full security services for Layer 2 switching capabilities. On these SRX Series devices, 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 device can function as a Layer 2 switch with multiple VLANs that participate in the same Layer 2 network.

In transparent mode, the SRX Series device 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

  • Unified Threat Management (UTM)

  • Network Address Translation (NAT)

  • VPN

Note
  • Starting in Junos OS Release 12.3X48-D10 and Junos OS Release 17.3R1, mixed mode is the default mode, and you can configure an SRX Series device using both transparent mode (Layer 2) and route mode (Layer 3) simultaneously, with no reboot required.

  • On all SRX Series devices, transparent mode is not supported on mPIMs.

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

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 device 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 device 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 device 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 device 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 devices 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 devices. See Ethernet Switching and Layer 2 Transparent Mode Overview.

The SRX Series device 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 devices 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 devices 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 master in a redundancy group cannot send gratuitous ARP requests to notify network devices of a change in mastership 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 Devices

You can configure the fxp0 out-of-band management interface on the SRX Series device 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.

Note

On SRX1500, the default Layer 2 global mode is transparent-bridge mode.

Note

Starting in Junos OS Release 15.1X49-D50 and Junos OS Release 17.3R1, the factory-default configuration of the SRX300, SRX320, SRX340, and SRX345 devices is switching mode. When these devices are loaded or reset with the factory-default configuration, these devices are in switching mode.

Starting from 15.1X49-D50 until 15.1X49-D90, when you load or reset the factory-default configuration on SRX300, SRX320, SRX340, and SRX345 devices, these devices are in switching mode. When you delete the Layer 2 global mode configuration on these devices, these devices are in transparent-bridge mode.

Starting with Junos OS Release 15.1X49-D100, when you load or reset the factory-default configuration on SRX300, SRX320, SRX340, SRX345, SRX550, and SRX550M devices, these devices are in switching mode. When you delete the Layer 2 global mode configuration on these devices, these devices are in switching mode. To configure the devices to transparent-bridge mode, you must configure the Layer 2 global mode configuration to transparent-bridge mode. Use the command set protocols l2-learning global-mode transparent-bridge before rebooting the devices with Junos OS 15.1X49-D100 image.

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 devices 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 devices:

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

In addition, the SRX Series devices do not support the following Layer 2 features:

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

  • Nonqualified VLAN learning, where only the MAC address is used for learning within the VLAN—VLAN learning on SRX Series devices 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.

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:
    [edit]

    user@host# set vlans vlan-name vlan-id vlan-id-number

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

    [edit]

    user@host# set vlans vlan-name vlan-id-list vlan-ids | vlan-id--vlan-id
  2. Assign at least one interface to the VLAN:
    [edit]

    user@host# set interface interface-name family ethernet-switching vlan members vlan-name

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.
    [edit interfaces]

    user@host# set interface-name unit logical-unit-number family ethernet-switching interface-mode trunk
  2. Configure the native VLAN ID and assign the interface to the native VLAN ID:
    [edit interfaces]

    user@host# set interface-name native-vlan-id number
  3. Assign the interface to the native VLAN ID:
    [edit interfaces]

    user@host# set interface-name unit logical-unit-number family ethernet-switching vlan members native-vlan-id-number

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:

[edit]

user@host# set interfaces interface-name unit logical-unit-number family ethernet-switching interface-mode trunk

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

[edit]

user@host# set interfaces interface-name unit logical-unit-number family ethernet-switching interface-mode access

To assign an interface to VLAN:

[edit interfaces]

user@host# set interface-name unit logical-unit-number family ethernet-switching vlan members [all | vlan-names | vlan-ids]

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:

[edit]

user@host# set interfaces interface-name unit logical-unit-number family inet address ip-address

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:

[edit]

user@host# set interfaces interface-name unit logical-unit-number family inet6 address ip-address

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:
    [edit]

    user@host# set vlans vlan-name vlan-id vlan-id
  2. Create an IRB logical interface:
    [edit]

    user@host# set interface irb unit logical-unit-number family inet address ip-address
  3. Associate the IRB interface with the VLAN:
    [edit]

    user@host# set vlans vlan-name l3-interface irb.logical-unit-number

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:
    [edit chassis]

    user@host# set aggregated-devices ethernet device-count number
  2. Specify the name of the link aggregation group interface:
    [edit]

    user@host# set interfaces aex
  3. Specify the minimum number of links for the aggregated Ethernet interface (aex)– that is, the defined bundle– to be labeled up:
    [edit interfaces]

    user@host# set aex aggregated-ether-options minimum-links number
  4. Specify the link speed for the aggregated Ethernet bundle:
    [edit interfaces]

    user@host# set aex aggregated-ether-options link-speed link-speed
  5. Specify the members to be included within the aggregated Ethernet bundle:
    [edit interfaces]

    user@host# set interface-name ether-options 802.3ad aex

    user@host# set interface-name ether-options 802.3ad aex
  6. Specify an interface family for the aggregated Ethernet bundle:
    [edit interfaces]

    user@host# set aex unit 0 family inet address ip-address

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:
    [edit interfaces]

    user@host# set aex aggregated-ether-options lacp active
  2. Specify the interval at which the interfaces send LACP packets:
    [edit interfaces]

    user@host# set aex aggregated-ether-options lacp periodic interval

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 2: 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 {
...
}
}
switch-options {
}
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 3: RTG Statements

Original Hierarchy

Changed Hierarchy

ethernet-switching-options {
group name {
description;
interface interface-name {
primary;
}
...
}
}
}
switch-options {
group name {
description;
interface interface-name {
primary;
}
preempt-cutover-timer seconds;
...
}
}
}

Table 4: Deleted Statements

Original Hierarchy

Changed Hierarchy

ethernet-switching-options {
mac-notification {
...
}
}

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

ethernet-switching-options {
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 {
}

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 5: Port Mirroring hierarchy

Original Hierarchy

Changed Hierarchy

ethernet-switching-options {
}
forwarding-options {
}

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 6: 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 7: dot1q-tunneling

Original Hierarchy

Changed Hierarchy

ethernet-switching-options {
dot1q-tunneling {
ether-type (0x8100 | 0x88a8 | 0x9100);
...
}
}
interfaces interface-name {
}
interfaces interface-name {
}

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 8: mac-table-aging-time statement

Original Hierarchy

Changed Hierarchy

ethernet-switching-options {
}
protocols {
l2-learning {
}
}

Changes to Nonstop Bridging

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

Table 9: Nonstop Bridging statement

Original Hierarchy

Changed Hierarchy

ethernet-switching-options {
}
protocols {
layer2-control {
}
}

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 10: Port Security statements

Original Hierarchy

Changed Hierarchy

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 );
prefix (hostname | mac | none);
use-string string;
}
vendor-id [string];
}
(examine-dhcp | no-examine-dhcp);
}
(ip-source-guard | no-ip-source-guard);
}
}
vlans vlan-name forwarding-options{
group group-name {
interfaceiinterface-name {
static-ip ip-address {
mac mac-address;
}
}
}
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 11: DHCP Snooping Statements

Original Hierarchy

Changed Hierarchy

dhcp-snooping-file {
location local_pathname | remote_URL;
timeout seconds;
}
system [
processes [
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 12: VLAN hierarchy

Original Hierarchy

Changed Hierarchy

vlans vlan-name switch-options {
}
ethernet-switching-options {
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 {
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 {
}
}

Statement is removed.

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

Statement has been moved to different hierarchy.

vlans {
vlan-name {
switch-options {
...
}
}
}
vlans {
vlan-name {
primary-vlan vlan-name;
...
}
}

Statement has been removed.

vlans {
vlan-name {
}
}

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 13: 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 {
}
}
}
}
interface interface-name {
encapsulation extended-vlan-bridge;
unit logical-unit-number {
vlan-id number;
vlan-id-list [vlan-id vlan-idvlan-id];
}
}
vlans {
vlan-name {
input filter-name
output filter-name;
...
}
}
}
vlans {
vlan-name {
forwarding-options {
input filter-name
output filter-name;
...
}
}
}
}
vlans {
vlan-name {
mac-limit limit action action;
...
}
}
vlans {
vlan-name {
switch-options {
}
}
}
vlans {
vlan-name {
switch-options {
interface interface-name {
}
}
}
}
vlans {
vlan-name {
}
}
protocols {
l2-learning {
}
}

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 14: Changes to the Storm Control Profile hierarchy level

Original Hierarchy

Changed Hierarchy

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 15: Changes to the Interfaces hierarchy

Original Hierarchy

Changed Hierarchy

interfaces interface-name {
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 {
}
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 {
}
}
}

Note: Statement has been replaced with a new statement.

interfaces irb

Changes to IGMP Snooping

Table 16: IGMP Snooping hierarchy

Original Hierarchy

Changed Hierarchy

protocols {
igmp-snooping {
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;
interface (all | interface-name) {
group multicast-ip-address;
}
}
source-address ip-address;
}
robust-count number;
}
}
}
protocols {
igmp-snooping {
vlan vlan-name {
interface (all | interface-name) {
group-limit <1..65535>
host-only-interface
group multicast-ip-address {
source <>
}
}
}
}
l2-querier {
source-address ip-address;
}
source-address ip-address;
}
query-interval number;
query-last-member-interval number;
query-response-interval number;
robust-count number;
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 17 and Table 18 provide lists of existing commands that have been moved to new hierarchies or changed on SRX Series devices 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 17: 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 18: 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, and ACX5448 routers differ from those for other ACX Series routers (ACX1000, ACX1100, ACX2000, ACX2100, ACX2200, and ACX4000) and MX Series routers.

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

Table 19: 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, and ACX5448 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 20 shows the differences in show commands for Layer 2 features in Layer 2 next generation mode.

Table 20: 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, and ACX5448 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

Release History Table
Release
Description
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.
Starting with Junos OS Release 15.1X49-D100, when you load or reset the factory-default configuration on SRX300, SRX320, SRX340, SRX345, SRX550, and SRX550M devices, these devices are in switching mode. When you delete the Layer 2 global mode configuration on these devices, these devices are in switching mode.
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.