Navigation  Back up to About Overview 
ContentIndex
  
[+] Expand All
[-] Collapse All

No index entries found.

New Features in Junos OS Release 12.3 for EX Series Switches

This section describes new features in Release 12.3 of the Junos operating system (Junos OS) for EX Series switches.

Not all EX Series software features are supported on all EX Series switches in the current release. For a list of all EX Series software features and their platform support, see Feature Explorer.

New features are described on the following pages:

Hardware


Juniper Networks EX9200 Ethernet Switches—The EX9200 Programmable Ethernet Switches support current and planned SDN interfaces and protocols, offering the flexibility and scalability to increase business agility by simplifying the deployment and operation of cloud applications, by offering server virtualization, and by supporting rich media collaboration tools across campuses and data centers. The EX9200 switches provide high performance, scalable connectivity, and carrier-class reliability for high-density environments such as campus aggregation and data center networks.

The first supported Junos OS release for the EX9200 switches is Release 12.3R2.

The EX9200 switches are modular systems that provide high availability and redundancy for all major hardware components, including Routing Engine modules, Switch Fabric (SF) modules, fan trays (with redundant fans), and power supplies. Four line cards are available for the EX9200 switches.

The three EX9200 switches are:

  • EX9204 Ethernet switch—The EX9204 switch has a capacity of up to 1.6 terabits per second (Tbps), full duplex.

    The EX9204 switch has a 6-U chassis. It has two dedicated slots for line cards and a multifunction slot that can be used for either a line card or a host subsystem, all horizontal and all on the front of the switch chassis.

  • EX9208 Ethernet switch—The EX9208 switch has a capacity of up to 4.8 Tbps, full duplex.

    The EX9208 switch has an 8-U chassis and six horizontal line card slots on the front of the switch chassis.

  • EX9214 Ethernet switch—The EX9214 switch has a capacity of up to 13.2 Tbps, full duplex.

    The EX9214 switch has a 16-U chassis and has 12 vertical line card slots on the front of the switch chassis.

The line cards combine a Packet Forwarding Engine and Ethernet interfaces in a single assembly. Line cards are field-replaceable units (FRUs), and they are hot-insertable and hot-removable.

The four line cards available for EX9200 switches are:

  • EX9200-32XS—32-port SFP+ line card
  • EX9200-40T—40-port 10/100/1000BASE-T RJ-45 line card
  • EX9200-40F—40-port 100FX/1000BASE-X SFP line card
  • EX9200-4QS—4-port 40-Gigabit Ethernet QSFP+ line card

[See EX9204 Hardware Documentation, EX9208 Hardware Documentation, and EX9214 Hardware Documentation.]

Access Control and Port Security

  • MAC limiting enhancements—The MAC limiting feature for access port security has been enhanced to provide additional flexibility and granularity. The new feature, VLAN membership MAC limit, enables you to configure a MAC limit for a specific interface based on its membership in a particular VLAN (VLAN membership MAC limit). A single interface that belongs to multiple VLANs can thus have more than one MAC limit.

    [See Understanding MAC Limiting and MAC Move Limiting for Port Security on EX Series Switches.]

  • VR-aware DHCP server and relay with option 82 on EX8200 switches and EX8200 Virtual Chassis—VR-aware DHCP (extended DHCP) server with option 82 is now supported on EX8200 standalone switches and EX8200 Virtual Chassis.

    [See Understanding DHCP Services for Switches and Understanding the Extended DHCP Relay Agent for EX Series Switches.]

  • VR-aware DHCPv6 server and relay support—Virtual router-aware (VR-aware) DHCPv6 server and VR-aware DHCPv6 relay are now supported on these switch platforms:
  • Bypassing 802.1X authentication when adding multiple LLDP-MED end devices—If you have a large-scale installation of LLDP-MED end devices, you can save configuration time by specifying the lldp-med-bypass statement at the [edit protocols dot1x authenticator interface (all | interface-name)] hierarchy level. By configuring the lldp-med-bypass statement on an interface, you enable the interface to bypass the 802.1X authentication procedure for connecting multiple LLDP-MED end devices. This configuration automatically adds the learned MAC addresses of the LLDP-MED end devices to the switch’s static MAC bypass list, so that you do not have to individually add the MAC address of each device. You can issue the lldp-med-bypass statement only when the interface is also configured for 802.1X authentication of multiple supplicants.

    [See lldp-med-bypass.]

  • Access control and port security features support added on EX3300 switches—EX3300 switches now support:

Class of Service (CoS)

  • Class-of-service feature support added on EX3300 switches—EX3300 switches now support:
    • IPv6 CoS (multifield classification and rewrite)
    • Flexible CoS outer 802.1p marking

    [See Junos OS CoS for EX Series Switches Overview.]

Converged Networks (LAN and SAN)

  • Enhanced transmission selection (IEEE 802.1Qaz) support on EX4500 switches—The EX4500 switch models that support Converged Enhanced Ethernet (CEE) now provide limited support for enhanced transmission selection (ETS) (IEEE 802.1Qaz). ETS is a bandwidth management mechanism that supports dynamic allocation of bandwidth for Data Center Bridging Capability Exchange protocol (DCBX) traffic classes.

    EX Series switches do not support the use of ETS to dynamically allocate bandwidth to traffic classes. Instead, the switches handle all DCBX traffic as a single default traffic class, group 7.

    However, the switches do support the ETS Recommendation TLV. The ETS Recommendation TLV communicates the ETS settings that the switch wants the connected DCBX peer interface to use.

    If the peer interface is willing to learn the ETS state of the switch, it changes its configuration to match the configuration in the ETS Recommendation TLV sent by the EX Series switch (that is, the traffic class group 7).

    The switch advertises that it is not willing to change its ETS settings.

    The advertisement of the ETS TLV is enabled by default for DCBX interfaces, but you can disable it.

    [See Disabling the ETS Recommendation TLV.]

  • Support for IEEE DCBX—The EX4500 switch models that support Converged Enhanced Ethernet (CEE) now also support the IEEE Data Center Bridging Capability Exchange protocol (IEEE DCBX). Earlier, these switches supported only DCBX version 1.01.

    DCBX version 1.01 and IEEE DCBX differ mainly in frame format. DCBX version 1.01 uses one TLV that includes all DCBX attribute information, which is sent as sub-TLVs. IEEE DCBX uses a unique TLV for each DCB attribute.

    DCBX is enabled by default on all 10-Gigabit Ethernet interfaces, and the default setting for the DCBX version on those interfaces is auto-negotiation.

    When the interface DCBX version is set for auto-negotiation (the default):

    • The switch sends IEEE DCBX TLVs. If the DCBX peer advertises the IEEE DCBX TLV three times, the switch changes the local DCBX interface to IEEE DCBX.
    • If the DCBX peer advertises DCBX version 1.01 TLVs three times, the switch changes the local DCBX interface to dcbx-version-1.01.

    When the interface DCBX version is set for dcbx-version-1.01:

    • The switch sends DCBX version 1.01 TLVs and ignores any IEEE DCBX TLVs from the peer.

    When the interface DCBX version is set for ieee-dcbx:

    • The switch sends IEEE DCBX-based TLVs and ignores any DCBX version 1.01 TLVs from the peer.

    To configure the DCBX version, use the set dcbx-version command at the [edit protocols dcbx interface (all | interface-name)] hierarchy level.

    The show dcbx neighbors command has been updated with additional fields that support the IEEE DCBX feature; these fields include Interface Protocol-Mode and TLV Type.

    [See Changes to and Errata in Documentation for Junos OS Release 12.3 for EX Series Switches.]

  • VN_Port to VN_Port FIP snooping on EX4500 switches—You can configure VN_Port to VN_Port (VN2VN_Port) FIP snooping if the hosts are directly connected to the same EX4500 switch. VN2VN_Port FIP snooping on an FCoE transit switch provides security to help prevent unauthorized access and data transmission on a bridge that connects ENodes in the Ethernet network. VN2VN_Port FIP snooping provides security for virtual links by creating filters based on information gathered (snooped) about FCoE devices during FIP transactions.

    [See Example: Configuring VN2VN_Port FIP Snooping (FCoE Hosts Directly Connected to the Same FCoE Transit Switch); see also Changes to and Errata in Documentation for Junos OS Release 12.3 for EX Series Switches.]

Enhanced Layer 2 Software (ELS) on EX9200 Switches

  • Uniform Enhanced Layer 2 Software (ELS) CLI configuration statements and operational commands—Enhanced Layer 2 Software (ELS) provides a uniform CLI for configuring and monitoring Layer 2 features on EX9200 switches and on MX Series routers in LAN mode (MX-ELM). With ELS, for example, you can configure a VLAN and other Layer 2 features on an EX9200 switch and an MX-ELM router by using the same configuration commands.

    [See the ELS CLI documentation for EX9200 switches: Junos OS for EX9200 Switches, Release 12.3.]

  • The web-based ELS Translator tool is available for registered customers to help them become familiar with the ELS CLI and to quickly translate existing EX Series switch-based CLI configurations into ELS CLI configurations.

    [See ELS Translator.]

Ethernet Switching and Spanning Trees

  • Ethernet ring protection switching—Ethernet ring protection switching has been extended to the following switches:
    • EX3300 switches
    • EX4500 switches
    • EX4550 switches
    • EX4550 Virtual Chassis
    • Mixed EX4200 and EX4500 Virtual Chassis
    • EX8200 switches
    • EX8200 Virtual Chassis

    Support for all these switches is in addition to that for EX2200, EX3200, and EX4200 switches provided in earlier releases. Ethernet ring protection switching, defined in the ITU-T G.8032 recommendation, provides a means to reliably achieve carrier-class network requirements for Ethernet topologies forming a closed loop.

    [See Ethernet Ring Protection Switching Overview.]

  • Disable MAC notifications on an interface—On EX Series switches, when you enable media access control (MAC) notifications, learned and unlearned MAC address and aging SNMP notifications are unicast on all switch interfaces. In a large Layer 2 domain, unicasting might be undesirable because it can lead to significantly excess traffic. You can now disable such notifications on individual interfaces. For example, you might need notifications only for devices that are locally attached to the switch; you might not need notifications that arrive through uplinks. To disable notifications on an interface, issue the set ethernet-switching-options interfaces interface-name no-mac-notification command.

    [See Understanding MAC Notification on EX Series Switches.]

  • VLAN pruning within an EX Series Virtual Chassis—VLAN pruning is now supported within an EX Series Virtual Chassis. When VLAN pruning is enabled within an EX Series Virtual Chassis, all broadcast, multicast, and unknown unicast traffic in a VLAN uses the shortest path possible across the Virtual Chassis to the egress VLAN interface. VLAN pruning within an EX Series Virtual Chassis enables you to conserve Virtual Chassis bandwidth by restricting broadcast, multicast, and unknown unicast traffic in a VLAN to the shortest possible path across the Virtual Chassis instead of broadcasting this traffic to all Virtual Chassis member switches.

    [See Enabling VLAN Pruning for Broadcast, Multicast, and Unknown Unicast Traffic in an EX Series Virtual Chassis (CLI Procedure).]

  • Spanning-tree protocol concurrent configuration support added on EX3300 switches—EX3300 switches now support concurrent configuration of RSTP and VSTP. [See Understanding RSTP for EX Series Switches.]
  • Extended Q-in-Q VLAN support for multiple S-VLANs per access interface on EX3300 switches—EX3300 switches now support filter-based S-VLAN tagging. [See Understanding Q-in-Q Tunneling on EX Series Switches.]

Firewall Filters and Routing Policy

High Availability

  • Nonstop bridging for the Ethernet switching process (eswd), LLDP, LLDP-MED, and spanning-tree protocols on EX3300 Virtual Chassis—Nonstop bridging (NSB) for the Ethernet switching process (eswd), LLDP, LLDP-MED, and spanning-tree protocols is now supported on EX3300 Virtual Chassis. You can now configure NSB to enable a transparent switchover between the master and backup Routing Engines without having to restart any of these processes or protocols.

    [See Understanding Nonstop Bridging on EX Series Switches.]

  • Nonstop active routing, graceful protocol restart, and graceful Routing Engine switchover enhancements for standalone EX8200 switches and EX8200 Virtual Chassis—Nonstop active routing (NSR), which enables a transparent switchover of Routing Engines without requiring restart of supported routing protocols, now supports RSVP and LDP on EX8200 standalone switches and EX8200 Virtual Chassis. Graceful protocol restart, a feature that enables a switch undergoing a restart to inform its adjacent neighbors and peers of the restart, is now supported for RSVP and LDP on standalone EX8200 switches and EX8200 Virtual Chassis. Graceful Routing Engine switchover (GRES) for Layer 2 and Layer 3 VPN LSPs is now supported on standalone EX8200 switches and EX8200 Virtual Chassis.

    [See Understanding Nonstop Active Routing on EX Series Switches or High Availability Features for EX Series Switches Overview.]

  • Virtual Router Redundancy Protocol (VRRP) for IPv6 on EX3300 switches—VRRP for IPv6 is now supported on EX3300 switches.

    [See Understanding VRRP on EX Series Switches.]

  • Unified ISSU for EX9200 switches—A unified in-service software upgrade (unified ISSU) enables you to upgrade between two different Junos OS releases with no disruption on the control plane and with minimal disruption of traffic. Unified ISSU is supported starting with Junos OS Release 12.3R3 on EX9200 switches with EX9200-40T or EX9200-40F line cards.

    [See Unified ISSU Concepts.]

Infrastructure

  • Automatic repair of corrupted partition when booting from alternate partition—Resilient dual-root partitioning has been enhanced to include an automatic snapshot feature. If the automatic snapshot feature is enabled and the system reboots from the alternate root partition, the switch automatically takes a snapshot of the Junos OS root file system in the alternate root partition and copies it to the primary root partition. This automatic snapshot procedure takes place whenever the system reboots from the alternate root partition, regardless of whether the reboot is due to a command or due to corruption of the primary root partition.

    [See Understanding Resilient Dual-Root Partitions on Switches.]

  • BFD performance improvements—BFD performance improvements have been made on EX4200 Virtual Chassis, EX4500 Virtual Chassis, and EX8200 switches.
  • IPv4 and IPv6 over GRE tunneling support on EX8200 standalone switches and EX8200 Virtual Chassis—Generic routing encapsulation (GRE) is an IP encapsulation protocol that is used to transport packets over a network. Information is sent from one network to the other through a GRE tunnel. EX8200 standalone switches and EX8200 Virtual Chassis now support both encapsulation and de-encapsulation. Also, the configuration procedures for standalone EX8200 switches and EX8200 Virtual Chassis are now the same as for EX3200 and EX4200 switches.

    [See Understanding Generic Routing Encapsulation.]

  • IPv6 for virtual router-aware DHCP—EX Series switches support IPv6 for virtual router-aware DHCP, that is, for the extended DHCP server and extended DHCP relay. The specific CLI statements supported for EX Series switches are:
    • For extended DHCP server:
      • At the [edit system services dhcp-local server dhcpv6] hierarchy level:
        • group
        • overrides
        • reconfigure
      • At the [edit access address-assignment pool pool-name] hierarchy level:
        • family inet6
          • dhcp-attributes
          • prefix
          • range
    • For extended DHCP relay:
      • At the [edit forwarding-options dhcp-relay dhcpv6] hierarchy level:
        • group
        • overrides
        • relay-agent-interface-id
        • relay-option
        • server-group

    [See Understanding DHCP Services for Switches and Understanding the Extended DHCP Relay Agent for EX Series Switches.]

Interfaces and Chassis

  • LACP standards-based link protection for aggregated Ethernet interfaces—LACP standards-based link protection can be enabled on a global level (for all aggregated Ethernet interfaces on the switch) or for a specific aggregated Ethernet interface. Earlier, EX Series switches supported only Junos OS link protection for aggregated Ethernet interfaces.

    [See Understanding Aggregated Ethernet Interfaces and LACP.]

  • Interfaces feature support added on EX3300 switches—EX3300 switches now support:
    • Unicast reverse-path forwarding (RPF)
    • IP directed broadcast

    [See Understanding Unicast RPF for EX Series Switches and Understanding IP Directed Broadcast for EX Series Switches.]

  • Default logging for Ethernet ring protection switching (ERPS) (EX2200, EX2200-VC, EX3200, EX3300, EX3300-VC, EX4200, EX4200-VC, EX4500, EX4500-VC, EX4550, EX4550-VC, EX8200, EX8200-VC)—Starting with Junos OS Release 12.3R9, the listed EX switches automatically log basic state transitions for the ERPS protocol. No configuration is required to initiate this logging. Basic state transitions include ERPS interface transitions from up to down, and down to up; and ERPS state transitions from idle to protection, and protection to idle.

    The basic state transitions are logged in a single file named erp-default, located in the /var/log directory of the switch. The maximum size of this file is 15 MB.

    Default logging for ERPS can capture initial ERPS interface and state transitions, which can help you troubleshoot issues that occur early in the ERPS protocol startup process. However, if more robust logging is needed, you can enable traceoptions for ERPS by entering the traceoptions statement in the [edit protocols protection-group] hierarchy level.

    Be aware that for ERPS, only default logging or traceoptions can be active at a time on the switch. That is, default logging for ERPS is automatically enabled and if you enable traceoptions for ERPS, the switch automatically disables default logging. Conversely, if you disable traceoptions for ERPS, the switch automatically enables default logging.

IPv6

  • Compliance with RFC 4291—EX Series switches drop the following types of illegal IPv6 packets:
    • Packets that have a link-local source or destination address. Because link-local addresses are intended to be used for addressing only on a single link, EX Series switches do not forward any packets with such addresses to other links.
    • Packets with the IPv6 unspecified source address 0:0:0:0:0:0:0:0.
    • Packets that are to be sent outside a node, but have the IPv6 loopback address 0:0:0:0:0:0:0:1 as the source address. When IPv6 packets are received on an interface, EX Series switches drop packets that have the loopback address as the destination address.
  • IPv6 neighbor redirect compliance with RFC 4861—Routers use ICMP redirect messages to notify the users on the data link that a better route is available for a particular destination. All EX Series switches now support sending ICMP redirect messages for both IPv4 and IPv6 traffic.

    [See Understanding the Protocol Redirect Mechanism on EX Series Switches.]

  • Added license support for EX2200 and EX4200 switches—The enhanced feature license (EFL) for EX2200 switches now supports the EX-2200-24T-DC model. The advanced feature license (AFL) for EX4200 switches now supports EX4200-24PX and EX4200-48PX models.

    [See Understanding Software Licenses for EX Series Switches.]

  • Support for IPv6 features on EX3300 switches—EX3300 switches now support:
    • IPv6 path MTU discovery
    • IPv6 routing BGP, RIPng, MBGP, and OSPFv3
    • IPv6 routing PIM for IPv6 multicast
    • IPv6 routing MLDv1 and MLDv2
    • IPv6 routing IPv6 ping and IPv6 traceroute
    • IPv6 routing stateless autoconfiguration
    • IPv6 routing IPv6 Layer 3 forwarding in hardware

J-Web Interface

Layer 2 and Layer 3 Protocols

  • VRF support on EX2200 switches—Virtual routing and forwarding (VRF) is now supported on EX2200 switches.

    [See Understanding Virtual Routing Instances on EX Series Switches.]

  • Feature support added on EX3300 switches—EX3300 switches now support:
    • Virtual routing and forwarding (VRF)—virtual routing instances—with IPv6 for unicast traffic
    • Layer 3 filter-based forwarding for unicast traffic
    • Layer 3 VRF for unicast BGP, RIP, and OSPF traffic
    • Multiple VLAN Registration Protocol (MVRP, IEEE 802.1ak)

Management and RMON

MPLS

  • Re-mark the DSCP values for MPLS packets that exit an EX8200 standalone switch or an EX8200 Virtual Chassis—In firewall filter configurations for EX8200 standalone switches and EX8200 Virtual Chassis, you can now apply the dscp action modifier on Layer 3 interfaces for IPv4 and IPv6 ingress traffic. This action modifier is useful specifically to re-mark the DSCP values for MPLS packets that leave an EX8200 standalone switch or an EX8200 Virtual Chassis, because these switches cannot re-mark the DSCP value on egress traffic. If you apply the dscp action modifier to ingress traffic, the DSCP value in the IP header is copied to the EXP value in the MPLS header, thus changing the DSCP value on the egress side.

    [See Firewall Filter Match Conditions, Actions, and Action Modifiers for EX Series Switches.]

Virtual Chassis

  • Member link enhancement for optical interfaces configured as Virtual Chassis ports between EX4500 and EX4550 member switches—When you configure optical interfaces as Virtual Chassis ports (VCPs) that you then use to interconnect EX4500 or EX4550 switches in a Virtual Chassis, you can now configure up to 24 optical interface links into a link aggregation group (LAG). Earlier, you could configure a maximum of eight links into a LAG. You can increase the member link limit in the following configurations: when you interconnect EX4500 switches in an EX4500 Virtual Chassis; when you interconnect EX4550 switches in an EX4550 Virtual Chassis; and when you interconnect EX4500 or EX4550 switches to other EX4500 or EX4550 switches in a mixed Virtual Chassis.
  • Dedicated Virtual Chassis port link aggregation on EX4550 switches—The dedicated Virtual Chassis ports (VCPs) on EX4550 switches automatically form a link aggregation group (LAG) bundle when two or more dedicated VCPs are used to interconnect the same Virtual Chassis member switches. This feature became available in Junos OS Release 12.3R2. The LAG provides more bandwidth than a single dedicated VCP can provide, and it provides VCP redundancy by load-balancing traffic across all available dedicated VCPs in the LAG. If one of the dedicated VCPs fails, the VCP traffic is automatically load-balanced across the remaining dedicated VCPs in the LAG. See also Changes to and Errata in Documentation for Junos OS Release 12.3 for EX Series Switches.
  • Support for RJ-45 interfaces as Virtual Chassis ports on EX2200 and EX2200-C switches—Starting with Junos OS Release 12.3R3, all RJ-45 interfaces, including built-in network ports with 10/100/1000BASE-T Gigabit Ethernet connectors and 1000BASE-T RJ-45 transceivers, on EX2200 and EX2200-C switches can now be configured into Virtual Chassis ports (VCPs). VCPs are used to interconnect EX2200 or EX2200-C switches into a Virtual Chassis.

Related Documentation

Modified: 2016-06-09