Junos 9.6 Release Highlights

Link Layer Discovery Protocol (LLDP) support
Devices that support IEEE 802.1AB standard based protocol (LLDP) advertise information about themselves to other nodes on the 802 LAN networks and stores information they learn from other nodes. The protocol runs over the data-link layer only, allowing two systems running different network layer protocols to learn about each other. With this feature you can now configure the LLDP protocol on interfaces on MX Series routers.

Port mirroring with next-hop groups enhancement
Adds support for port-mirroring functionality using next-hop groups without Tunnel PICs on MX Series routers. Previously, port-mirroring using next-hop groups, also known as multipacket port-mirroring, was supported on MX Series routers, but required installation of a Tunnel PIC.

Reverse Telnet
Reverse Telnet is now available on J Series routers allowing you to configure the devices to listen on a specific port for Telnet and SSH (secure shell) services.

Class-of-Service (CoS) components
CoS components for Asynchronous Transfer Mode (ATM) are provided to control data transfer, especially for time-sensitive voice packets. J Series devices with ADSL Annex A or Annex B PIMs can use an ATM interface to send network traffic through a point-to-point connection to a DSL access multiplexer (DSLAM).

Low-impact ISSU chassis cluster upgrades
The SRX3000 and SRX5000 lines now support in-service software upgrades (ISSUs) to eliminate downtime when you are upgrading devices in a chassis cluster. In devices run by Junos 9.6 or later, you can issue a single request command to upgrade both devices in an SRX3000 or SRX5000 line cluster without needing to either reset devices or take the cluster out of service.

Active/active chassis clustering
This feature is now supported on SRX240 and SRX650 devices in addition to the existing support on SRX3400, SRX3600, SRX5600, and SRX5800 devices. The data plane now supports active/active chassis clustering for these SRX Series devices. You can configure one or more redundancy groups. Multiple redundancy groups make it possible for traffic to arrive on an interface of one redundancy group and egress on an interface that belongs to another redundancy group even if the ingress and egress interfaces are not active on the same node.

Selective stateless packet-based services
Selective stateless packet-based services allow you to use both flow-based and packet-based forwarding simultaneously on a system. This feature is supported on SRX100, SRX210, SRX240, and SRX650 devices. You configure these services by specifying and applying filters to certain interfaces. On these interfaces, traffic that matches the filter criteria will bypass flow-based forwarding.

Network processor bundling
This feature enables distribution of data traffic from one interface to multiple network processors for packet processing. This feature is supported on SRX5600 and SRX5800 devices.

Layer 2 transparent mode chassis clusters
A pair of SRX3400, SRX3600, SRX5600, or SRX5800 Services Gateways in Layer 2 transparent mode can be connected in a chassis cluster to provide network node redundancy. Devices in Layer 2 transparent mode can be deployed only in active/passive chassis cluster configurations. On a device in a Layer 2 transparent mode chassis cluster, the redundant Ethernet interface is configured as a Layer 2 logical interface.

Layer 2 transparent mode VLAN retagging
The VLAN identifier in packets arriving on a Layer 2 trunk port can be rewritten or "retagged" with a different internal VLAN identifier. This feature is supported on SRX3400, SRX3600, SRX5600 and SRX5800 devices.

Dial-up VPNs
Dial-up VPNs are now supported in chassis clustering environments.

Performance and capacity tuning for IDP
If you are deploying IDP policies, you can tune the device to increase IDP session capacity. This feature is supported on SRX3400, SRX3600, SRX5600, and SRX5800 devices.

Hub-and-spoke VPNs
For route-based IPsec VPNs, Junos Software supports a topology called hub-and-spoke, which allows two or more remote sites to communicate to each other through a central site using VPN tunnels.

NAT information in session logs
As with previous releases, a session can be logged whenever it is created, closed, rejected, or denied. Starting with Junos Release 9.6, additional NAT information is included in session logs for all SRX Series devices.

Persistent NAT
This feature is supported on SRX100, SRX210, SRX240 and SRX650 devices. Configuration of persistent NAT allows applications to use the Session Traversal Utilities for NAT (STUN) protocol for NAT traversal. Persistent NAT is sometimes referred to as Cone NAT. The term Cone NAT has been replaced by Persistent NAT by the IETF.

LAG over 1GE/10GE VC extension
Currently, it is possible to configure a Link Aggregation Group (LAG) across members of a virtual chassis (VC), but this is restricted only to downlink network ports. However, no aggregation is possible over extended/uplink VCP ports, although extended ports can still form a VC. There can be a total of up to 16 LAG'ed trunks configured per virtual chassis (including two dedicated vcp-0/1 trunks).

This enhancement in the EX4200 switches extends the configuration of a LAG across VCP ports of the same member between virtual chassis members of different models. As required earlier, such extended trunk members should all be running at the same IFL speed. When more than one such VC trunk member comes up, the virtual-chassis system will automatically LAG them.

Advantages of the extended VC LAG provisioning include:

• higher overall bandwidth for forwarding traffic across boxes over higher extended ports
• enhanced box-to-box management communication (in addition to default VCP ports)
• enhancing redundancy among VC members
• Auto Image Install

Auto Image Install leverages DHCP/Bootp to enable an EX3200 or EX4200 switch to automatically download an image, add an image or reboot the EX switch to activate the new image.

Customers can configure the EX switch to interact with a DHCP/Bootp Server and automatically check for a new image to be downloaded and installed. The feature looks for an image which is different than the currently installed image. If it sees the image of the same name, the Auto Image feature downloads and changes the existing image.

Port Error disable and Auto recovery
Auto recovery from the disabled state on secure and storm control interfaces has been enhanced on the EX3200 and the EX4200 switches. A port may be error-disabled for a number of reasons - storm control being in effect, mac limit being exceeded, mac-move-limit being exceeded etc. Once these conditions become true, the port will automatically be shut down.

Mac-move and mac-limit already supports the action shutdown wherein, on detection, the device blocks the ports. With this change, the action shutdown will actually shut down the interface.

For storm-control, the Junos 9.6 release adds an optional CLI to shutdown the interface. When this condition exists, the port is effectively disabled and link is made down, i.e. no traffic can be received or transmitted on the port. A syslog message (trap) is generated for the user on the console.

Multi-cast VLAN Registration (MVR)
The MVR feature in the EX3200 and the EX4200 switches is designed to allow bandwidth-efficient distribution of IPTV multicast streams across a layer 2 network. In a standard layer 2 network, a multicast stream received on one VLAN is never distributed to ports outside that VLAN. If multiple VLAN's require a multicast stream, a separate copy of that stream must be distributed throughout the L2 network for every VLAN. This wastes bandwidth in the network.

MVR defines the concept of a "Multicast VLAN". Hosts that are not attached to this VLAN may receive multicast streams from it. This allows a Multicast VLAN (M-VLAN) to be shared across the network. Customers remain in their own VLANs for bandwidth and security reasons, but are also able to receive multicast streams from the M-VLAN.

MVR traffic is selectively forwarded from the M-VLAN onto ports not on the M-VLAN. These ports are known as "MVR receiver ports". MVR receiver ports cannot inject data traffic onto the M-VLAN.

IGMPv3 snooping
The IGMP protocol is used to indicate multicast group membership by IPv4 hosts. This feature extends the IGMP snooping feature to support IGMPv3 packets with filter-mode with a type INCLUDE in the EX Series Ethernet Switches. IGMP snooping is a feature to limit the multicast data traffic to only those interfaces that sent an igmp report for a group.

Version 1 and 2 of the IGMP protocol are source unaware. Hosts express interest in listening to multicast streams destined to a group address irrespective of the source hosts streaming these packets. In IGMP version 3, as defined in RFC 3376 the protocol has a provision of specifying source addresses from which the host would like to listen to the stream.

SNMP MIB enhancements
Juniper continues to enhance our management support for the EX Series Ethernet Switches by extending existing MIBs and adding new MIB support.

• Multicast MIB enhancements
• OSPFv3 MIB
• MPLS MIB
• Traps support in VLAN MIB

Firewall Filters on Loopback interface
Firewall Filter functionality or Access Control List (ACL)s were supported on EX8200 platforms as of the Junos 9.4 release. Three types of ACLs are supported on both ingress and egress directions "PACL, VACL, RACL". This enhancement adds support for Egress RACL's on a Loopback interface for the EX8200 Series Ethernet Switches.

Loopback interfaces are commonly used as the published device interface for Management/Control-Plane access because this interface is abstract and remains available regardless of any changes to a device's physical interfaces. The IP address of the loopback interface is used by routing protocols to communicate with their peers on the network. Packets destined for the loopback interface can arrive at any device network port. An Egress RACL processes routed packets for the loopback interface.

Firewall Filter match criteria - TCP / UDP port ranges and prefix list
Additional Match Conditions enabled for the EX8200 in the Junos 9.6 release:

• tcp-established: match packet of an established TCP connection
• destination-prefix-list: Match IP destination prefixes in named list
• source-prefix-list: Match IP source prefixes in named list
• ip-options: Match IP options
• ip-options-except: Do not match IP options

L2 FDB and L3 GRES enhancements
Graceful RE Switchover (GRES) is a feature in JUNOS which provides a foundation for state synchronization to a backup RE. The EX8200 integrates the GRES capability to provide similar behavior to that of M/T.

VSTP
VLAN Spanning Tree Protocol (VSTP) allows Juniper Networks EX Series Ethernet Switches to run one or more STP or RSTP instances for each VLAN on which VSTP is enabled. With the Junos 9.6 release, this functionality is now available on the EX8200 switches.

For networks with multiple VLANs, this enables more intelligent tree spanning, because each VLAN can have interfaces enabled or disabled depending on the paths available to that specific VLAN. By default, VSTP runs RSTP, but you cannot have both standalone RSTP and VSTP running simultaneously on a switch. VSTP can be enabled for up to 253 VLANs. VSTP enables interoperability with PVST+.

Filter based forwarding
Filter-based Forwarding (FBF) enables EX Series switch policy-based routing and to forward a packet based on a selected routing table. With routing-instance as filter action, if a packet matches firewall match conditions, traditional destination-based forwarding occurs using the routing table selected. With the Junos 9.6 release this functionality is now available on the EX8200 switches.

Filter-based Forwarding allows the user to control the next-hop selection for customer traffic by defining input packet filters which examine the packet header. The action of this input packet filter uses a routing table instance. A packet that passes through the filter is compared against the match criteria used to classify the traffic and determine its ultimate destination.

Once classified, the packet is forwarded to a routing table specified, and the packet is forwarded to the next hop that corresponds to the destination address entry in the table. Initial support is for IPv4. When IPv6 Firewall Filters (ACLs) are implemented, FBF support in IPv6 will also be enabled.

Filter Based Forwarding is often used with Virtual Router functionality, also known as VPN Routing and Forwarding (VRF) Lite. Virtual Router functionality is also introduced in this 9.6 release on the EX8200 switches.

Virtual Router
The Virtual Router capability, also known as VPN Routing and Forwarding (VRF) Lite, allows administrators to divide a EX8200 switch into multiple independent virtual routers, each with its own routing table.

Splitting a device into many virtual routing instances isolates traffic traveling across the network without requiring multiple devices to segment the network. You can use virtual routing instances to isolate customer traffic on your network and to bind customer-specific instances to customer-owned interfaces.

EX8200 switches support up to 256 virtual routing instances. Virtual Routing and Forwarding (VRF) is often used in conjunction with Layer 3 sub-interfaces, allowing traffic on a single physical interface to be differentiated and associated with multiple virtual routers. Each logical Layer 3 sub-interface can belong to only one routing instance.