Switching Features Overview

This topic describes the Layer 2 switching features for supported devices and ports. For more information, see the Junos OS Documentation for EX Series Switches.

This topic covers:

• VLANs
• Integrated Bridging and Routing
• Spanning Tree Protocols
• Generic VLAN Registration Protocol
• Link Aggregation
• 802.1X Port-Based Network Authentication
• Link Layer Discovery Protocol (LLDP) and Link Layer Discovery Protocol-Media Endpoint Discovery (LLDP-MED)
• IGMP Snooping
• Q-in-Q VLAN Tagging

VLANs

Bridging divides a single physical LAN into two or more virtual LANs, or VLANs. Each VLAN is a collection of network nodes that are grouped together to form a separate broadcast domain. 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 VLAN. 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 LAN as a whole.

On an Ethernet LAN, all network nodes must be physically connected to the same network. Each VLAN is identified by a single IP subnetwork and by standardized IEEE 802.1Q encapsulation.

To pass traffic within a VLAN, the switch uses Layer 2 forwarding protocols, including IEEE 802.1Q, Spanning Tree Protocol (STP), and Generic VLAN Registration Protocol (GVRP). To pass traffic between two VLANs, the switch uses standard Layer 3 routing protocols, such as static routing, OSPF, and RIP.

Note: Independent VLAN learning (IVL) is supported on SRX100, SRX240, and SRX650 devices and shared VLAN learning (SVL) is supported on J Series devices and SRX210 devices.

Types of Switch Ports

The ports, or interfaces, on a switch operate in either access mode or trunk mode.

An interface in access mode connects to a network device, such as a desktop computer, an IP telephone, a printer, a file server, or a security camera. The interface itself belongs to a single VLAN. The frames transmitted over an access interface are normal Ethernet frames.

Trunk interfaces 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 one another.

IEEE 802.1Q Encapsulation and Tags

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.

Integrated Bridging and Routing

Integrated bridging and routing (IRB) provides support for simultaneous Layer 2 bridging and Layer 3 routing within the same bridge domain. Packets arriving on an interface of the bridge domain are switched or routed based on the destination MAC address of the packet. Packets with the router’s MAC address as the destination are routed to other Layer 3 interfaces.

Spanning Tree Protocols

Spanning Tree Protocol (STP), defined in IEEE 802.1D, creates a tree of links in the Ethernet switched network. Links that cause loops in the network are disabled, thereby providing a single active link between any two switches.

Note: Only STP is supported on the SRX210 device.

Rapid Spanning Tree Protocol (RSTP), originally defined in IEEE 802.1w and later merged into IEEE 802.1D, facilitates faster spanning tree convergence after a topology change.

Multiple Spanning Tree Protocol (MSTP), initially defined in IEEE 802.1s and later included in IEEE 802.1Q, supports mapping of multiple VLANs onto a single spanning tree instance. This reduces the number of spanning tree instances required in a switched network with many VLANs.

Generic VLAN Registration Protocol

The Generic VLAN Registration Protocol (GVRP) is an application protocol of the Generic Attribute Registration Protocol (GARP) and is defined in the IEEE 802.1Q standard. GVRP learns VLANs on a particular 802.1Q trunk port and adds the corresponding trunk port to the VLAN if the advertised VLAN is preconfigured on the switch.

The VLAN registration information sent by GVRP includes the current VLAN membership—that is, which switches are members of which VLANs—and which switch ports are in which VLAN. GVRP shares all VLAN information configured manually on a local switch.

As part of ensuring that VLAN membership information is current, GVRP removes switches and ports from the VLAN information when they become unavailable. Pruning VLAN information limits the network VLAN configuration to active participants only, reducing network overhead, and targets the scope of broadcast, unknown unicast, and multicast (BUM) traffic to interested devices only.

Link Aggregation

You can combine multiple physical Ethernet ports to form a logical point-to-point link, known as a link aggregation group (LAG) or bundle. A LAG provides more bandwidth than a single Ethernet link can provide. Additionally, link aggregation provides network redundancy by load-balancing traffic across all available links. If one of the links should fail, the system automatically load-balances traffic across all remaining links. You can select up to eight Ethernet interfaces and include them within a link aggregation group.

Note: Link aggregation is supported only for Ethernet interfaces that are configured in switching mode (family ethernet-switching). Aggregating interfaces that are configured in routed mode (family inet) is not supported.

Link aggregation can be used for point-to-point connections. It balances traffic across the member links only within an aggregated Ethernet bundle and effectively increases the uplink bandwidth. Another advantage of link aggregation is increased availability, because the LAG is composed of multiple member links. If one member link fails, the LAG continues to carry traffic over the remaining links.

Link Aggregation Group (LAG)

You can configure a LAG by specifying the link number as a physical device and then associating a set of ports with the link. All the ports must have the same speed and be in full-duplex mode. Junos OS assigns a unique ID and port priority to each port.

Note: You must enable Link Aggregation Control Protocol (LACP) when you configure a LAG.

The ID and priority are not configurable. When configuring a LAG, consider the following guidelines:

• Up to 8 Ethernet ports can be created in each bundle.
• Each LAG must be configured on both sides of the link.
• The ports on either side of the link must be set to the same speed.

A typical deployment for a LAG would be to aggregate trunk links between an access switch and a distribution switch or customer edge (CE) device. LAGs are not supported on virtual chassis port links. LAGs can only be used for a point-to-point connection. At least one end of the LAG should be configured as active.

Link Aggregation Control Protocol (LACP)

LACP, a subcomponent of IEEE 802.3ad, provides additional functionality for LAGs.

When LACP is not enabled, a local LAG might attempt to transmit packets to a remote single interface, which causes the communication to fail. When LACP is enabled, a local LAG cannot transmit packets unless a LAG with LACP is also configured on the remote end of the link.

By default, Ethernet links do not exchange protocol data units (PDUs), which contain 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. The transmitting link is known as the actor and the receiving link is known as the partner.

Note: Presently, LACP can be configured only for the Ethernet switching family.

802.1X Port-Based Network Authentication

IEEE 802.1X, also known as port-based network access control (PNAC), is a mechanism to provide authentication to devices attached on the LAN. Hosts are authenticated when they initially connect to a LAN. Authenticating hosts before they receive an IP address from a DHCP server prevents unauthorized hosts from gaining access to the LAN.

A LAN network configured for 802.1X authentication contains three basic components:

• Supplicant—The IEEE term for a host that requests to join the network. The host can be responsive or nonresponsive. A responsive host is one on which 802.1X authentication is enabled and that provides authentication credentials (such as a user name and password). A nonresponsive host is one on which 802.1X authentication is not enabled.
• Authenticator Port Access Entity—The IEEE term for the authenticator. The SRX Series or J Series device is the authenticator and controls access by blocking all traffic to and from supplicants until they are authenticated.
• Authentication server—The server containing the back-end database that makes authentication decisions. (Junos OS supports RADIUS authentication servers.) The authentication server contains credential information for each supplicant that can connect to the network. The authenticator forwards credentials supplied by the supplicant to the authentication server. If the credentials forwarded by the authenticator match the credentials in the authentication server database, access is granted. If the credentials forwarded do not match, access is denied.

Note: Change of authorization (CoA) is not supported on SRX100, SRX210, SRX240, SRX650, and J Series devices.

The implementation of 802.1X authentication provides the following features for the specified devices:

The 802.1X implementation provides the following supplicant capacities:

See Configuring 802.1X Features for information about configuring the 802.1X authentication options.

Dynamic VLAN Assignment

When a supplicant first connects to an SRX Series or J Series device, the authenticator sends a request to the supplicant to begin 802.1X authentication. If the supplicant is an 802.1X-enabled device, it responds, and the authenticator relays an authentication request to the RADIUS server.

As part of the reply to the authentication request, the RADIUS server returns information about the VLAN to which the port belongs. By configuring the VLAN information at the RADIUS server, you can control the VLAN assignment on the port.

MAC RADIUS Authentication

If the authenticator sends three requests to a supplicant to begin 802.1X authentication and receives no response, the supplicant is considered nonresponsive. For a nonresponsive supplicant, the authenticator sends a request to the RADIUS server for authentication of the supplicant’s MAC address. If the MAC address matches an entry in a predefined list of MAC addresses on the RADIUS server, authentication is granted and the authenticator opens LAN access on the interface where the supplicant is connected.

You can configure the number of times the authenticator attempts to receive a response and the time period between attempts.

Static MAC Bypass

The authenticator can allow particular supplicants direct access to the LAN and bypass the authentication server by including the supplicants’ MAC addresses in the static MAC bypass list configured on the SRX Series or J Series device. This list is checked first. If a match is found, the supplicant is considered successfully authenticated and the interface is opened up for it. No further authentication is done for that supplicant. If a match is not found and 802.1X authentication is enabled for the supplicant, the device continues with MAC RADIUS authentication on the authentication server.

For each MAC address in the list, you can configure the VLAN to which the supplicant is moved or the interfaces on which the supplicant can connect.

Guest VLAN

You can specify a guest VLAN that provides limited network access for nonresponsive supplicants. If a guest-vlan is configured, the authenticator connects all nonresponsive supplicants to the predetermined VLAN, providing limited network access, often only to the Internet. This type of configuration can be used to provide Internet access to visitors without compromising company security.

Note: In 802.1x, mac-radius and guest-vlan should not be configured together, because guest-vlan does not work when mac-radius is configured.

VoIP VLAN Support

When VoIP is used with 802.1X, the RADIUS server authenticates the phone, and Link Layer Discovery Protocol–Media Endpoint Discovery (LLDP-MED) provides the class-of-service (CoS) parameters for the phone. (For more information, refer to Link Layer Discovery Protocol (LLDP) and Link Layer Discovery Protocol-Media Endpoint Discovery (LLDP-MED).)

You can configure 802.1X authentication to work with VoIP in multiple-supplicant or single-supplicant mode:

• Multiple-supplicant mode—Allows multiple supplicants to connect to the interface. Each supplicant is authenticated individually.
• Single-supplicant mode—Authenticates only the first supplicant. All other supplicants who connect later to the interface are allowed to “piggyback” on the first supplicant’s authentication and gain full access.

Server Reject VLAN

By default, when authentication fails, the supplicant is denied access to the network. However, you can specify a VLAN to which the supplicant is moved if authentication fails. The server reject VLAN is similar to a guest VLAN. With a server reject VLAN, however, authentication is first attempted by credential, then by MAC address. If both authentication methods fail, the supplicant is given access to a predetermined VLAN with limited network access.

RADIUS Server Failure Fallback

You can define one of four actions to be taken if no RADIUS authentication server is reachable (if, for example, a server failure or a timeout has occurred on the authentication server).

• deny—(default) Prevent traffic from flowing from the supplicant through the interface.
• permit—Allow traffic to flow from the supplicant through the interface as if the supplicant were successfully authenticated by the RADIUS server.
• use-cache—Force successful authentication if authentication was granted before the failure or timeout. This ensures that authenticated users are not adversely affected by a failure or timeout.
• vlan vlan-name | vlan-id —Move the supplicant to a different VLAN specified by name or ID. This applies only to the first supplicant connecting to the interface.

Note: For permit, use-cache, and vlan fallback actions to work, 802.1X supplicants need to accept an out of sequence SUCCESS packet.

RADIUS Accounting

Configuring RADIUS accounting on a SRX Series or J Series device lets you collect statistical data about users logging on and off a LAN, and sends it to a RADIUS accounting server. The collected data can be used for general network monitoring, to analyze and track usage patterns, or to bill a user based on the amount of time or type of services accessed.

To configure RADIUS accounting, specify one or more RADIUS accounting servers to receive the statistical data from the device, and select the type of accounting data to be collected. To view the collected statistics, you can access the log file configured to receive them.

Link Layer Discovery Protocol (LLDP) and Link Layer Discovery Protocol-Media Endpoint Discovery (LLDP-MED)

Devices use LLDP and LLDP-MED to learn and distribute device information on network links. The information allows the device to quickly identify a variety of systems, resulting in a LAN that interoperates smoothly and efficiently.

LLDP-capable devices transmit information in Type Length Value (TLV) messages to neighbor devices. Device information can include specifics, such as chassis and port identification and system name and system capabilities. The TLVs leverage this information from parameters that have already been configured in the Juniper Networks Junos OS.

LLDP-MED goes one step further, exchanging IP-telephony messages between the device and the IP telephone. These TLV messages provide detailed information on PoE policy. The PoE Management TLVs let the device ports advertise the power level and power priority needed. For example, the device can compare the power needed by an IP telephone running on a PoE interface with available resources. If the device cannot meet the resources required by the IP telephone, the device could negotiate with the telephone until a compromise on power is reached.

The following basic TLVs are supported:

• Chassis Identifier—The MAC address associated with the local system.
• Port identifier—The port identification for the specified port in the local system.
• Port Description—The user-configured port description. The port description can be a maximum of 256 characters.
• System Name—The user-configured name of the local system. The system name can be a maximum of 256 characters.
• Switching Features Overview This information is not configurable, but taken from the software.
• System Capabilities—The primary function performed by the system. The capabilities that system supports; for example, bridge or router. This information is not configurable, but based on the model of the product.
• Management Address—The IP management address of the local system.

The following LLDP-MED TLVs are supported:

• LLDP-MED Capabilities—A TLV that advertises the primary function of the port. The capabilities values range 0 through 15:
  • 0—Capabilities
  • 1—Network policy
  • 2—Location identification
  • 3—Extended power via medium-dependent interface power-sourcing equipment (MDI-PSE)
  • 4—Inventory
  • 5–15—Reserved
• LLDP-MED Device Class Values:
  • 0—Class not defined
  • 1—Class 1 device
  • 2—Class 2 device
  • 3—Class 3 device
  • 4—Network connectivity device
  • 5–255— Reserved
• Network Policy—A TLV that advertises the port VLAN configuration and associated Layer 2 and Layer 3 attributes. Attributes include the policy identifier, application types, such as voice or streaming video, 802.1Q VLAN tagging, and 802.1p priority bits and Diffserv code points.
• Endpoint Location—A TLV that advertises the physical location of the endpoint.
• Extended Power via MDI—A TLV that advertises the power type, power source, power priority, and power value of the port. It is the responsibility of the PSE device (network connectivity device) to advertise the power priority on a port.

LLDP and LLDP-MED must be explicitly configured on uPIMs (in enhanced switching mode) on J Series devices, base ports on SRX100, SRX210, and SRX240 devices, and Gigabit Backplane Physical Interface Modules (GPIMs) on SRX650 devices. To configure LLDP on all interfaces or on a specific interface, use the lldp statement at the [set protocols] hierarchy. To configure LLDP-MED on all interfaces or on a specific interface, use the lldp-med statement at the [set protocols] hierarchy.

IGMP Snooping

Internet Group Management Protocol (IGMP) snooping regulates multicast traffic in a switched network. With IGMP snooping enabled, a LAN switch monitors the IGMP transmissions between a host (a network device) and a multicast router, keeping track of the multicast groups and associated member ports. The switch uses that information to make intelligent multicast-forwarding decisions and forward traffic to the intended destination interfaces. J Series devices support IGMPv1 and IGMPv2.

How IGMP Snooping Works

A J Series device usually learns unicast MAC addresses by checking the source address field of the frames it receives. However, a multicast MAC address can never be the source address for a packet. As a result, the switch floods multicast traffic on the VLAN, consuming significant amounts of bandwidth.

IGMP snooping regulates multicast traffic on a VLAN to avoid flooding. When IGMP snooping is enabled, the switch intercepts IGMP packets and uses the content of the packets to build a multicast cache table. The cache table is a database of multicast groups and their corresponding member ports. The cache table is then used to regulate multicast traffic on the VLAN.

When the router receives multicast packets, it uses the cache table to selectively forward the packets only to the ports that are members of the destination multicast group.

How Hosts Join and Leave Multicast Groups

Hosts can join multicast groups in either of two ways:

• By sending an unsolicited IGMP join message to a multicast router that specifies the IP multicast that the host is attempting to join.
• By sending an IGMP join message in response to a general query from a multicast router.

A multicast router continues to forward multicast traffic to a VLAN provided that at least one host on that VLAN responds to the periodic general IGMP queries. For a host to remain a member of a multicast group, therefore, it must continue to respond to the periodic general IGMP queries.

To leave a multicast group, a host can either not respond to the periodic general IGMP queries, which results in a “silent leave” (the only leave option for hosts connected to switches running IGMPv1), or send a group-specific IGMPv2 leave message.

Q-in-Q VLAN Tagging

Q-in-Q tunneling, defined by the IEEE 802.1ad standard, allows service providers on Ethernet access networks to extend a Layer 2 Ethernet connection between two customer sites.

In Q-in-Q tunneling, as a packet travels from a customer VLAN (C-VLAN) to a service provider's VLAN, a service provider-specific 802.1Q tag is added to the packet. This additional tag is used to segregate traffic into service–provider–defined service VLANs (S-VLANs). The original customer 802.1Q tag of the packet remains and is transmitted transparently, passing through the service provider's network. As the packet leaves the S-VLAN in the downstream direction, the extra 802.1Q tag is removed.

Note: When Q-in-Q tunneling is configured for a service provider’s VLAN, all routing engine packets, including packets from the routed VLAN interface, that are transmitted from the customer-facing access port of that VLAN will always be untagged.

There are three ways to map C-VLANs to an S-VLAN:

• All-in-one bundling—Use the dot1q-tunneling statement at the [edit vlans] hierarchy to map without specifying customer VLANs. All packets from a specific access interface are mapped to the S-VLAN.
• Many-to-one bundling—Use the customer-vlans statement at the [edit vlans] hierarchy to specify which C-VLANs are mapped to the S-VLAN.
• Mapping C-VLAN on a specific interface—Use the mapping statement at the [edit vlans] hierarchy to map a specific C-VLAN on a specified access interface to the S-VLAN.

The following table lists the C-VLAN to S-VLAN mapping supported on SRX Series devices:

Note: On SRX650 devices, in the dot1q-tunneling configuration options, customer VLANs range and VLAN push do not work together for the same S-VLAN, even when you commit the configuration. If both are configured, then VLAN push takes priority over customer VLANs range.

Integrated bridging and routing (IRB) interfaces are supported on Q-in-Q VLANs for SRX210, SRX240, SRX650, and J Series devices. Packets arriving on an IRB interface on a Q-in-Q VLAN are routed regardless of whether the packet is single or double tagged. The outgoing routed packets contain an S-VLAN tag only when exiting a trunk interface; the packets exit the interface untagged when exiting an access interface.

In a Q-in-Q deployment, customer packets from downstream interfaces are transported without any changes to source and destination MAC addresses. You can disable MAC address learning at both the interface level and the VLAN level. Disabling MAC address learning on an interface disables learning for all the VLANs of which that interface is a member. When you disable MAC address learning on a VLAN, MAC addresses that have already been learned are flushed.