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
See Also
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.
See Also
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.
Mode Type |
Supported |
Not Supported |
---|---|---|
Transparent mode |
|
|
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
- Understanding IPv6 Flows in Transparent Mode on Security Devices
- Understanding Layer 2 Transparent Mode Chassis Clusters on Security Devices
- Configuring Out-of-Band Management on SRX Series Firewalls
- Ethernet Switching
- Layer 2 Switching Exceptions on SRX Series Devices
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:
Layer 2 security zones and security policies. See Understanding Layer 2 Security Zones and Understanding Security Policies in Transparent Mode .
Firewall user authentication. See Understanding Firewall User Authentication in Transparent Mode .
Layer 2 transparent mode chassis clusters.
Class of service functions. See Class of Service Functions in Transparent Mode Overview.
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.
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.
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.
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.
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.
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 |
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.
See Also
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.)
See Also
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.
See Also
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
- Understanding How to Configure Layer 2 Features Using ELS
- Understanding ELS Configuration Statement and Command Changes
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
- Configuring the Native VLAN Identifier
- Configuring Layer 2 Interfaces
- Configuring Layer 3 Interfaces
- Configuring an IRB Interface
- Configuring an Aggregated Ethernet Interface and Configuring LACP on That Interface
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:
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:
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:
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:
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:
Enable one side of the aggregated Ethernet link as active:
[edit interfaces] user@host# set aex aggregated-ether-options lacp active
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
- Changes to the Port Mirroring Hierarchy Level
- Changes to the Layer 2 Control Protocol Hierarchy Level
- Changes to the dot1q-tunneling Statement
- Changes to the L2 Learning Protocol
- Changes to Nonstop Bridging
- Changes to Port Security and DHCP Snooping
- Changes to Configuring VLANs
- Changes to Storm Control Profiles
- Changes to the Interfaces Hierarchy
- Changes to IGMP Snooping
Changes to the ethernet-switching-options Hierarchy Level
This section outlines the changes to the ethernet-switching-options
hierarchy level.
The ethernet-switching-options
hierarchy level
has been renamed as switch-options
.
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; ... } } } |
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; ... } } } |
Original Hierarchy |
Changed Hierarchy |
---|---|
ethernet-switching-options { mac-notification { notification-interval seconds; ... } } |
The statements have been removed from the |
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 |
ethernet-switching-options { port-error-disable { disable-timeout timeout; ... } } |
Note:
The interfaces interface-name family ethernet-switching { recovery-timeout seconds; } |
Changes to the Port Mirroring Hierarchy Level
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.
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.
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.
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.
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.
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.
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; } } } |
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
DHCP snooping statements have moved to a different hierarchy level.
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.
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.
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 |
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; ... } } |
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 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-id–vlan-id]; } } For 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.
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
Statements have been moved to a different 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
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.
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. |
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 |
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.)
See Also
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.
Feature |
ACX1000, ACX1100, ACX2000, ACX2100, ACX2200, ACX4000, and MX Series Routers |
ACX5048, ACX5096, ACX5448, ACX710, ACX7100, ACX7024, and ACX7509 Routers |
---|---|---|
Bridge Domain |
[ |
[ |
Family |
[ |
[ |
Layer 2 options |
[ |
[ |
Ethernet options |
[ |
[ |
Integrated routing and bridging (IRB) |
[ |
|
Storm control |
[ |
[ [ |
Internet Group Management Protocol (IGMP) snooping |
[ |
[ |
Family |
[ |
[ |
Table 21 shows the 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 |
|
|
MAC table |
|
|
MAC table options |
|
|
Switch port listing with VLAN assignments |
|
|
Kernel state of flush database |
|
|
See Also
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.
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:
Enterprise Style of Configuration
To configure the interface to support the enterprise style of configuration:
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.
set protocols l2-learning global-mode(transparent-bridge
| switching)
command to switch between the Layer 2 transparent
bridge mode and Ethernet switching mode.