[ Contents] [ Prev] [ Next] [ Report an Error]

Release 8.1 Features

The following features have been added to JUNOS Release 8.1. The identifier following the description is the short title of the manual or manuals to consult for further information. For a complete list of manuals, see Table 5 and Table 6.

Hardware

New M-series router model—The M120 Internet router is a complete routing system that provides SONET/SDH, ATM, Ethernet, and channelized interfaces for large networks and network applications, such as those supported by Internet service providers (ISPs) and large enterprise customers. Application-specific integrated circuits (ASICs), a definitive part of the router design, enable the router to forward data at the high speeds demanded by current network media.
The M120 provides multiple redundancy options and chassis configurations, enhanced ASIC features, and improved chassis and Packet Forwarding Engine (PFE) scaling. The M120 utilizes the I-chip ASIC, which supports up to 32,000 logical interfaces. The base chassis provides 120 Gbps of midplane bandwidth between the interfaces and Forwarding Engine Boards (FEBs), and 144 Gbps of half-duplex fabric bandwidth between the interfaces and the FEBs.

The M120 is a quarter-rack chassis that supports up to six Flexible PIC Concentrators (FPCs). Four slots accept FPCs of types 1, 2, and 3 and two Compact FPCs (cFPCs). Each FPC can be configured with a variety of network media types, altogether providing up to 130 physical interface ports per system. The router height of 20.75 in. (52.71 cm) enables stacked installation of four routers in a single floor-to-ceiling rack, for increased port density per unit of floor space. In a standalone configuration, the router’s maximum aggregate throughput is 120 Gbps, full duplex.
4-port OC192c PIC with XFP (T640 routing nodes and TX Matrix platforms)—The 4-port OC192c PIC with 10-gigabit small form-factor pluggable transceivers (XFP) can be operated in either 4-port mode or in OC768-over-4xOC192 mode. In OC768-over-4xOC192 mode, four OC192 links are aggregated into one OC768 link with one logical interface to achieve data rates beyond 10 Gbps within existing infrastructures and without requiring link bonding or load sharing over parallel links. To configure the PIC to operate in OC768-over-4xOC192 mode, include the aggregate-ports statement at the [edit chassis fpc slot-number pic pic-number] hierarchy level. To display logical and physical interface information in either mode, issue the show interfaces so-fpc/pic/port extensive operational mode command. The 4-port OC192c PIC with XFP also supports XFP optics. To display XFP optics diagnostics data and alarms, issue the show interfaces so-fpc/pic/port diagnostics optics operational mode command. [Network Interfaces, Interfaces Command Reference, T640 and TX Matrix PIC Guides]
1-port OC192c PIC with XFP (M320 and T-series routing platforms)—The 1-port OC192c PIC with 10-gigabit small form-factor pluggable transceivers (XFP) supports traditional SONET and SDH framing with the enhancement of XFP optics. To display XFP optics diagnostics data and alarms, issue the show interfaces so-fpc/pic/port diagnostics optics operational mode command. [Network Interfaces, Interfaces Command Reference, M320 and T-series PIC Guides]
New services PICs (M-series and T-series routing platforms, except for M20 and M160 routers)—The new MultiServices 100 and MultiServices 400 PICs support the same feature set as the Adaptive Services PICs as of JUNOS Release 8.0. The two MultiServices PIC models deliver enhanced performance and scaling compared to the previous AS PICs. They support the existing Layer 2 and Layer 3 services packages. To configure service packages, include the service-package statement at the [edit chassis fpc slot-number pic slot-number adaptive-services] hierarchy level. You can display the service package configuration by issuing the show chassis pic fpc-slot number pic-slot number command. [Services Interfaces, System Basics and Services Command Reference, M-series and T-series PIC Guides]

Note: Please contact Juniper Networks customer support before implementing MultiServices PICs. [PR/81905]
RE-A-1000 (M40e routers) and RE-A-2000 (M320 and T-series routing platforms) Routing Engines—Next-generation Routing Engines that use USB flash memory instead of a PC Card. The USB flash install media is prepared in the same way as the PC Card install media except that the device name is /dev/rda0 instead of /dev/rad3. All operational mode commands used for existing Routing Engines apply to the new Routing Engines. To see if the USB flash install media is present in the USB slot, issue the show chassis hardware detail operational mode command. [Systems Basics and Services Command Reference]

Caution: Writing an install image to /dev/rad3 instead of /dev/rda0 will destroy the Routing Engine hard disk.

Note: Please contact Juniper Networks customer support before implementing RE-A-1000 and RE-A-2000 Routing Engines. [PR/95538]

2-port Channelized T1/E1 PIM (J-series Services Routers)—Enables you to configure a single Physical Interface Module (PIM) interface as a channelized T1 interface or a channelized E1 interface. The Channelized T1/E1 PIM supports channelization to the NxDS0 level in addition to all the functionality supported by regular T1 and E1 PIMs. Each interface can be configured in clear-channel, fractional, or channelized mode. To configure channelized T1 interfaces, include the ct1-pim/0/port statement at the [edit interfaces] hierarchy level. To configure channelized E1 interfaces, include the ce1-pim/0/port statement at the [edit interfaces] hierarchy level. [J-series Basic Configuration, Network Interfaces]

Note: The following information pertains to Channelized T1/E1 PIMs:

You cannot configure a Channelized T1/ E1 PIM through a J-Web user interface Quick Configuration page. The Quick Configuration pages do not display the channelized T1 and channelized E1 interfaces. To configure a Channelized T1/E1 PIM, you must use the J-Web configuration editor or the JUNOS software command-line interface (CLI).
The maximum MTU for clear-channel T1 and E1 interfaces on Channelized T1/E1 PIMs is 9150 bytes.

User Interface and Configuration

Support for Common Criteria EAL3—Adds configuration details about Common Criteria Evaluation Assurance Level 3 (EAL3) to the existing JUNOS-FIPS Configuration Guide, which has been renamed the Secure JUNOS Configuration Guide for Common Criteria and JUNOS-FIPS. The following required configuration components are part of the Common Criteria implementation for the JUNOS software:
- Disabling a console—To disable local console capabilities to manage the router, include the disable option at the [edit system ports console] hierarchy level.
- Logging load operations—Implements system log accounting for secret data type attribute changes (for example, changing a password or RADIUS shared secret password) executed with the CLI, JUNOScope, or the J-Web user interface during the following configuration load operations:
- Separation of management traffic—Documents configurations and arrangements that allow only authorized managers to access the JUNOS software, and maintains each authorized manager in a separate virtual address space.
- Identification and authentication of system managers—Documents configurations where only system managers can change authentication data for locally authenticated users, RADIUS/TACACS+ support, password guidelines, SSH public key authentication, access control for attributes and operational commands, and security roles such as superusers.
[Secure JUNOS]

Interfaces and Chassis

Configure SONET or SDH framing on a per-interface basis (4-port OC48 SFP PICs installed in M-series and T-series routing platforms)—Enables you to configure SONET or SDH framing on a per-interface basis and mix SONET and SDH modes on different interfaces in the same PIC. For example, incoming SDH links from Europe and outgoing SONET links to the USA now can be configured on the same PIC. Before this support was added, SONET or SDH framing could only be configured on a per-PIC basis. When you change SONET/SDH mode on an interface, only the framing type on the interface is changed. The PIC does not go offline and come back online. However, a small traffic interruption occurs on the affected interface when you change the framing type. Traffic flowing through other interfaces on the same PIC is not affected. To configure framing on a per-interface basis, include the framing (sdh | sonet) statement at the [edit interfaces so-fpc/pic/port] hierarchy level. To view interface information, issue the show interfaces so-fpc/pic/port operational mode command. [Network Interfaces, Interfaces Command Reference]

Note: If you configure Automatic Protection Switching (APS), you must use the same SONET/SDH mode on both the working and protection interfaces. Otherwise, APS support does not function properly.

Mixed tagging support (Gigabit Ethernet Intelligent Queuing [IQ] and IQ2 PICs on M-series and T-series routing platforms)—Enables you to configure single tags and dual tags for logical interfaces on the same Gigabit Ethernet interface. Before JUNOS Release 8.1, two logical interfaces on the same Gigabit Ethernet interface could not be configured to receive and map frames simultaneously with single or dual tag framing. To configure mixed tagging, include the flexible-vlan-tagging statement at the [edit interfaces ge-fpc/pic/port] hierarchy level and include the vlan-tags statement with inner and outer options or the vlan-id statement at the [edit interfaces interface-name unit logical-unit-number] or [edit logical-routers logical-router-name interfaces interface-name unit logical-unit-number] hierarchy levels. [Network Interfaces, Interfaces Command Reference]

VPI/VCI rewrite for ATM cell mode (ATM2 OC3 and ATM2 OC12 PICs installed in M320 and T-series routing platforms)—The virtual path identifier (VPI)/virtual channel identifier (VCI) rewrite behavior of ATM2 OC3 and ATM2 OC12 PICs now matches the behavior of ATM2 OC48 PICs. Beginning with JUNOS Release 8.1, the logical interfaces on each end of a cell-relay tunnel can be configured with any VPI/VCI and still function properly. Before JUNOS Release 8.1, the logical interfaces on each end of a cell-relay tunnel required that you configure matching VPI/VCIs. ATM cell mode encapsulations are used to transport ATM cells through cell-relay tunnels across MPLS networks. This feature is supported on interfaces with Layer 2 switching cross-connects and remote interface switching (MPLS LSP tunnel cross-connects), but does not support virtual path (VP) or virtual channel (VC) merging. No new configuration statements or operational mode commands are required for this feature. [Network Interfaces]

Note: When you configure the physical interface MTU for a flexible VLAN configuration, you must increase the MTU by 4 bytes more than the MTU you would configure for a standard VLAN tagged interface.

Using bandwidth to adjust VRRP priority—Enables the priority of a Virtual Router Redundancy Protocol (VRRP) group to be decreased dynamically when the operational speed of a specified interface drops below a configured bandwidth threshold. You can configure up to five bandwidth thresholds. To configure VRRP priority so that bandwidth is considered, include the bandwidth-threshold statement at the [edit interfaces interface-name unit logical-unit-number family inet address ip-address vrrp-group group-number track interface interface-name] hierarchy level and specify the priority-cost option to decrease the priority when the bandwidth threshold is exceeded. To configure a waiting period between dynamic changes in priority, include the priority-hold-time statement at the [edit interfaces interface-name unit logical-unit-number family inet address ip-address vrrp-group group-number track] hierarchy level. Enhancements to the show vrrp (detail | extensive) and show vrrp interface command output enable you to monitor dynamic changes in VRRP priority. Enhancements to the show vrrp track and show vrrp track interfaces commands include the addition of summary and detail options. [Network Interfaces, Interfaces Command Reference]
Enhanced optical diagnostics information (10-Gigabit Ethernet PICs with XENPAK optics installed in M320 and T-series routing platforms)—Displays diagnostics data and alarms for 10-Gigabit Ethernet with XENPAK interfaces. XENPAK Multisource Agreement (MSA) optics support is added to the current support for 300-pin MSA optics. To display diagnostics, issue the show interfaces diagnostics optics ge-fpc/pic/port or show interfaces diagnostics optics xe-fpc/pic/port operational mode commands. [Interfaces Command Reference, M320 PIC Guide, T-series PIC Guides]
Support for FRF.8 transparent mode (ATM interfaces on M7i, M10i, M20, M40e, M320, and T-series routing platforms)—Extends JUNOS software support of the FRF.8 (Frame Relay Forum) specification to include both transparent mode and translation mode. Before JUNOS Release 8.1, the only supported mode on ATM interfaces was translation mode. No new configuration statements or operational mode commands are required. [Network Interfaces]

Note: When you use FRF.8 transparent mode, the JUNOS software cannot accept Frame Relay packets.
Display age of ARP entries—Extends the show arp command to display the age of a particular ARP entry. To display the age of ARP entries, issue the show arp expiration-time command. [System Basics and Services Command Reference]
Display the package running on a MultiServices PIC—Provides the Package output field as a way to see if a MultiServices PIC is running a Layer 2 or Layer 3 package. To display package information, issue the show chassis pic fpc-slot slot-number pic-slot slot-number command. [System Basics and Services Command Reference]
Option to disable the craft interface—Enables you to disable the physical operation of the craft interface front panel on the routing platform. To disable the buttons on the craft interface front panel, include the craft-lockout statement at the [edit chassis] hierarchy level. [System Basics]

Services Applications

Class-of-service (CoS) marking and reclassification for the AS PIC—Adds a new rule-based service that provides DiffServ code point (DSCP) marking and forwarding-class assignment for traffic transiting the Adaptive Services (AS) PIC. The service uses application, application set, source, or destination address as match conditions, as well as match direction, and uses a similar structure for other rule-based services such as stateful firewall. The service actions allow you to associate the DSCP alias or value, forwarding-class name, system log activity, or a preconfigured application profile with the matched packet flows. To configure CoS for the AS PIC, include the appropriate statements at the [edit services cos rule rule-name] hierarchy level. You can define profiles by including the application-profile statement at the [edit services cos] hierarchy level. In addition, you can implement CoS actions on the reverse traffic flows by including the reflexive or reverse statements at the [edit services cos rule rule-name term term-name then] hierarchy level. Specification of the underlying DSCP and forwarding-class mappings uses the existing configurations at the [edit class-of-service] hierarchy level. To display the configured mappings, issue the new operational mode commands: show services cos statistics (dscp | forwarding-class). To clear the statistics, issue the clear services cos statistics command. [Services Interfaces, Class of Service, System Basics and Services Command Reference]
Active monitoring flow-tap application (M-series and T-series routing platforms, except for M160 routers and TX Matrix platforms)—Enables you to intercept IPv4 packets transiting an active flow monitoring router and send a copy of matching packets to one or more content destinations, for use in flexible trend analysis of security threats and in lawful intercept of data. This feature extends the existing dynamic flow capture (DFC) functionality based on Dynamic Tasking Control Protocol requests. The flow-tap application allows you to specify an Adaptive Services PIC to run the flow-tap service and convey flow-tap filters from the mediation device to the router over an SSH channel for additional security. The filters are automatically installed in the Packet Forwarding Engine (to direct matching traffic to the configured Adaptive Services PIC), and in the AS PIC itself (from where the packets are sent to one or more content destinations). To configure the AS PIC, include the interface sp-fpc/pic/port.logical-unit statement at the [edit services flow-tap] hierarchy level. To configure SSH for the flow-tap service, include the ssh statement at the [edit system services flow-tap-dtcp] hierarchy level. You must also define user permissions for flow-tap users to allow them to configure flow-tap services. You can define a login class at the [edit system login class class-name permissions] hierarchy level by including one of the following new permission bits: flow-tap, flow-tap-control, or flow-tap-operation. You can also specify user permissions through the new Juniper-User-Permissions RADIUS attribute. [Services Interfaces, System Basics, Feature Guide]
Certificate revocation list support for digital certificates for IPSec services (J-series Services Routers and Adaptive Services PICs installed in M-series and T-series routing platforms)—Enables the router to acquire the most recently issued certificate revocation list (CRL) from a certificate authority (CA), which IP Security (IPSec) peers use to verify the validity of digital certificates during Internet Key Exchange (IKE) negotiation. A certificate revocation list contains a list of digital certificates that have been canceled before their expiration date. You can download CRLs either automatically using the Lightweight Directory Access Protocol (LDAP) or manually. Only Microsoft and Entrust CAs are supported. The following CRL-related configuration statements and operational mode commands are supported:
- To enable or disable CRL verification, include the revocation-check statement at the [edit security pki ca-profile ca-profile-name] hierarchy level. By default, CRL verification is enabled.
- To configure CRL properties, include the crl statement at the [edit security pki ca-profile ca-profile-name revocation-check] hierarchy level.
- You can specify the location of the LDAP server where the CA stores its current CRL at the [edit security pki ca-profile ca-profile-name revocation-check crl url] hierarchy level.
- To allow IPSec tunnels to be established even if the CRL check fails, include the disable on-download-failure statement at the [edit security pki ca-profile ca-profile-name revocation-check crl] hierarchy level.
- To install a CRL that was manually downloaded, issue the new request security pki crl ca-profile ca-profile-name filename path/filename operational mode command.
- To display and delete CRLs installed on the router, issue the following new operational mode commands: show security pki crl and clear security pki crl. [System Basics, System Basics and Services Command Reference, Feature Guide]
Instance-aware IPSec IKE—Enables you to configure Internet Key Exchange (IKE) gateway IP addresses that are present in a virtual private network (VPN) routing and forwarding (VRF) instance as long as the peer is reachable through the VRF instance. To reach an IPSec IKE peer through a routing instance, include the routing-instance option at the [edit services service-set service-set-name ipsec-vpn-options local-gateway address] hierarchy level. You can display the routing instance by issuing the show services ipsec-vpn ipsec security-associations operational mode command. A new routing-instance option is added to the request services ipsec-vpn ipsec switch tunnel command, and there is a new clear services ipsec-vpn ipsec statistics command. [Services Interfaces, Feature Guide, System Basics and Services Command Reference]

RPM timestamp (J-series Services Routers and AS PICs installed in M-series and T-series routing platforms)—Provides timestamping for real-time performance monitoring (RPM) probes when the probe packets transit the Adaptive Services (AS) PIC or J-series Services Router. The following probe types support timestamping on J-series, M-series, and T-series routing platforms: icmp-ping, icmp-ping-timestamp, udp-ping, and udp-ping-timestamp. To configure RPM timestamping on M-series and T-series routing platforms, include the destination-interface sp-fpc/pic/port statement at the [edit services rpm probe owner-name test test-name] hierarchy level and the rpm client statement at the [edit interfaces sp-fpc/pic/port unit logical-unit-number] hierarchy level. To allow probes to be timestamped by the forwarding process in J-series Services Routers, include the hardware-timestamp statement at the [edit services rpm probe owner-name test test-name] hierarchy level. [Services Interfaces, J-series Basic Configuration]

Note: A single AS PIC in a single routing platform supports the following maximum number of simultaneous tests (or flows) with a tolerance of 1 millisecond:

30 tests for UDP ping
50 tests for ICMP ping

Note: Please contact Juniper Networks customer support before implementing RPM timestamping on J-series Services Routers. [PR/79847]

Routing Protocols

BFD for single-hop external BGP sessions—Extends the Bidirectional Forwarding Detection (BFD) protocol to support BGP. To configure BFD for BGP, include the bfd-liveness-detection statement at the [edit protocols bgp group group-name] and [edit protocols bgp group group-name neighbor neighbor-name] hierarchy levels. [Routing]
Configuring TCP MSS for BGP peers—Allows you to configure the Transmission Control Protocol (TCP) maximum segment size (MSS) for BGP sessions to prevent Internet Control Message Protocol (ICMP) vulnerability issues associated with TCP path maximum transmission unit (MTU) discovery. TCP MSS allows you to prevent fragmentation of packets sent by peers. You can configure the advertised MSS value for each BGP peer, either globally, per-group, or per-peer at the [edit protocols bgp], [edit logical-routers logical-router-nameprotocols bgp], or [edit routing-instances instance-name protocols bgp] hierarchy levels. To configure the TCP MSS value, include the tcp-mss statement at the [edit protocols bgp], [edit protocols bgp group group-name], or [edit protocols bgp group group-name neighbor neighbor-name] hierarchy levels. [Routing]

BGP path selection enhancement—Adds the interior gateway protocol (IGP) cost to a next-hop destination into the multiple exit discriminator (MED) before comparing MED values for BGP path selection. To configure BGP to factor the IGP cost into the MED, include the med-plus-igp statement at the [edit protocols bgp path-selection] or [edit logical-routers logical-router-name protocols bgp path-selection] hierarchy level. You can verify the revised MED by viewing the "MED-plus-IGP" field in the output of the show route extensive command. [Routing]

Note: The new MED has the following attributes:

It replaces the original MED in the BGP path selection algorithm.
It replaces the MED in the BGP multipath computation.
It does not replace the MED used by the BGP update send process to handle updates sent to neighboring BGP peers.

MPLS Applications

LMP control channel configuration—Defined in RFC 4204, the Link Management Protocol (LMP) is used to establish and maintain dynamic control channels for Generalized Multiprotocol Label Switching (GMPLS) traffic-engineering links. To configure the interface used by the dynamic control channel, include the lmp-control-channel statement at the [edit protocols link-management peer peer-name] hierarchy level. To configure the IP address of the remote peer for the control channel, include the remote-address statement at the [edit protocols link-management peer peer-name lmp-control-channel control-channel-interface] hierarchy level. To configure message attributes for LMP Config, LinkSummary, and Hello messages, or to specify that the remote peer configures the control channel, include the lmp-protocol statement at the [edit protocols link-management peer peer-name] hierarchy level. To display statistics for the LMP connection, issue the show link-management statistics command. [MPLS Applications, Feature Guide, Protocols Command Reference]
Ultimate-hop popping for point-to-multipoint LSPs—Allows you to configure ultimate-hop popping for point-to-multipoint label-switched paths (LSPs), which can be particularly beneficial when transit traffic traverses the same egress device. When you enable ultimate-hop popping, a single copy of traffic can be sent over the incoming link to save a significant amount of bandwidth. To enable ultimate-hop popping for all point-to-multipoint LSPs terminating on the router, configure the tunnel-services statement at the [edit protocols rsvp] hierarchy level. For ultimate-hop popping to function, a tunnel PIC is required on the egress node. By default, the JUNOS software automatically selects a virtual loopback tunnel (VT) interface to receive the RSVP traffic. To configure a VT interface explicitly, include the devices option at the [edit protocols rsvp tunnel-services] hierarchy level. [MPLS Applications]
MPLS LSP traceroute supported on transit routers—Provides support for the traceroute functionality specified in RFC 4379, Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures, but only on transit routers. You can issue the traceroute command for a Multiprotocol Label Switching (MPLS) label-switched path (LSP) on an ingress router that fully supports RFC 4379, and the command functions correctly as it propagates across any intervening routers running JUNOS software. Standard Internet Control Message Protocol (ICMP)-based traceroute follows a single path from a source to destination, relying on IP time-to-live (TTL) expiration. This path might be different for different invocations, based on the path the IP packet takes. LSP traceroute attempts to trace the path taken by an LSP, relying on MPLS TTL expiration. An LSP can take multiple paths from ingress to egress. This occurs in particular with equal-cost multipath (ECMP). LSP traceroute can trace all possible paths to an LSP egress node. No new configuration statements are required. [Protocols Command Reference]

Multicast

BFD for PIM—Extends the Bidirectional Forwarding Detection (BFD) protocol to detect failures quickly in a Protocol Independent Multicast (PIM) network environment. BFD failure detection timers provide faster detection by using shorter time limits than default failure detection mechanisms inherent in a routing protocol. The timers are also adaptive and you can adjust them to be more or less aggressive. To enable BFD for PIM, include the bfd-liveness-detection statement at the [edit protocols pim interface interface-name] hierarchy level and include either the minimum-receive-interval and minimum-transmit-interval statements or the minimum-interval statement at the [edit protocols pim interface interface-name bfd-liveness-detection] hierarchy level. Enhancements to the show bfd session and show pim neighbors detail commands enable you to view PIM BFD status. [Multicast, Protocols Command Reference]
Load sharing multicast traffic over aggregated trunks (M320 and T-series routing platforms)—Allows more than one multicast downstream interface to represent an aggregated interface, which enables load sharing on downstream aggregated interfaces (such as Gigabit Ethernet or SONET/SDH). Other features involving aggregated interfaces, such as virtual private LAN service (VPLS) and point-to-multipoint LSPs, are not affected. The new functionality is enabled by default and there are no new configuration statements. [Multicast]
Multicast data MDT configuration enhancement—Allows you to specify prefixes as well as specific group and source addresses for both the multicast group and multicast source when defining a maximum threshold value for data multicast distribution tree (MDT) creation. To configure prefixes for a group, include the group statement at the [edit protocols pim mdt threshold] hierarchy level. To configure prefixes for a source within a group, include the source statement at the [edit protocols pim mdt threshold group group-number] hierarchy level. [Multicast]
Multicast ping enhancement—Disables the Routing Engine from responding to multicast ping packets (ICMP echo messages). By using this enhancement, you can prevent unauthorized persons from discovering the list of provider edge (PE) routers in the network. To allow the Routing Engine to ignore multicast pings, include the no-multicast-echo statement at the [edit system] hierarchy level. [System Basics, Multicast]
Alternate way of enabling multicast on an interface—Allows multicast traffic to be transported on a specific interface without configuring Protocol Independent Multicast (PIM). To enable multicast traffic on an interface, include the interface interface-name statement at the [edit routing-options multicast] or [edit routing-instances instance-name routing-options multicast] hierarchy level. [Routing, Multicast]

Note: You cannot enable multicast traffic on an interface using the interface statement and configure PIM on the same interface simultaneously.

Routing Policy and Firewall Filters

Decrementing TTL values for a BOOTP or DHCP relay agent—Allows you to adjust the IP time-to-live (TTL) value for a bootstrap protocol (BOOTP) or Dynamic Host Configuration Protocol (DHCP) relay agent. To perform an IP TTL decrement before accepting any packets for processing when DHCP response packets are sent to a DHCP client, include the client-response-ttl statement at the [edit forwarding-options helpers bootp] or [edit forwarding-options helpers bootp interface interface-name] hierarchy level. [Policy]
Modify the IP/MPLS load-balancing hash function—Allows you to specify which bits are included in the IP/MPLS load-balancing hash function. By default, the most significant bit and least significant bit of the source and destination port fields are hashed. To select specific bits to be hashed, include your choice of the source-msb, source-lsb, destination-msb, or destination-lsb statement at the [edit forwarding-options hash-key family mpls payload ip port-data] hierarchy level. To prevent all four bits from being hashed, include the layer-3-only statement at the [edit forwarding-options hash-key family mpls payload ip] hierarchy level. [Policy]
MPLS load-balancing hash function consistency—Makes the MPLS load-balancing hash function standardized across all routing platforms that run the JUNOS software. To include the third MPLS label in the hash function, include the label-3 statement at the [edit forwarding-options hash-key family mpls] hierarchy level. To include no MPLS labels in the hash function, include the no-labels statement at the [edit forwarding-options hash-key family mpls] hierarchy level. [Policy]

Class of Service

Oversubscribing DLCI bandwidth (FRF.16 LSQ interfaces on AS PICs)—Extends support for oversubscription to FRF.16 Link Services IQ (LSQ) data-link connection identifier (DLCI) bundles. Allows you to configure shaping rates such that their sum exceeds the physical interface bandwidth. If the actual data traffic does not exceed the interface bandwidth, oversubscription allows you to sell more bandwidth than the physical interface can support. To configure DLCI bandwidth oversubscription, include the per-unit-scheduler statement at the [edit interfaces interface-name] hierarchy level; the shaping-rate statement at the [edit class-of-service traffic-control-profiles] hierarchy level; and the output-traffic-control-profile statement at the [edit class-of-service interfaces interface-name unit logical-unit-number] hierarchy level. [Class of Service, Services Interfaces]
Guaranteed bandwidth for DLCIs (FRF.16 Link Services IQ interfaces on AS PICs)—Extends support for guaranteed bandwidth to FRF.16 LSQ DLCI bundles. Allows you to configure guaranteed bandwidth for each FRF.16 DLCI. You cannot provision the sum of the guaranteed rates to be more than the physical interface bandwidth, and the guaranteed rate is a minimum. If excess physical interface bandwidth is available for use, the logical interface receives more than the guaranteed rate. To configure guaranteed bandwidth for DLCIs, include the per-unit-scheduler statement at the [edit interfaces interface-name] hierarchy level; the guaranteed-rate statement at the [edit class-of-service traffic-control-profiles] hierarchy level; and the output-traffic-control-profile statement at the [edit class-of-service interfaces interface-name unit logical-unit-number] hierarchy level. [Class of Service, Services Interfaces]
Enhanced rewrite profile options applied to incoming frames or outgoing frames on a logical interface (Gigabit Ethernet IQ2 PICs installed in M320 and T-series routing platforms)—Adds support for the simultaneous addition (push), deletion (pop), and replacement (swap) of the outer virtual LAN (VLAN) tag on logical interfaces in ingress and egress directions. You also can assign the IEEE 802.1p rewrite rule to dual VLAN tags to rewrite the IEEE bits in both the outer and inner VLAN tags of the tagged Ethernet frames. When you enable the class-of-service (CoS) rewrite for both tags, the same IEEE 802.1p rewrite table is used for the inner and outer VLAN tag. To define the rewrite profile to be applied to incoming frames or outgoing frames on a logical interface, include the input-vlan-map and output-vlan-map statements with options at the [edit interfaces ge-fpc/pic/port unit logical-unit-number] or [edit logical-routers logical-router-name interfaces ge-fpc/pic/port unit logical-unit-number] hierarchy level. To enable the CoS rewrite for the outer and inner VLAN tags, include the vlan-tag statement at the [edit class-of-service interfaces interface-name unit logical-unit-number rewrite-rules ieee-802.1 (rewrite-name | default)] hierarchy level and specify the outer-and-inner option. [Class of Service, Network Interfaces, Interfaces Command Reference]
Low-latency queuing support (J-series Services Routers)—Provides low-latency, strict priority queuing to allow delay-sensitive data, such as voice, to be sent before packets in other queues. When you enable congestion detection and queue management, delay-sensitive data is given preference over other traffic without impacting the lower priority queues. To configure low-latency queuing, include the strict-high statement at the [edit class-of-service schedulers scheduler-name priority] hierarchy level and the out-of-profile statement at the [edit firewall policer policer-name then] hierarchy level. [J-series Advanced Configuration, Class of Service]

Increase of maximum packet buffer (Type 1 and Type 2 FPCs installed in M320 and T-series routing platforms)—Allows you to configure a temporal buffer size up to 80,000 microseconds. The delay-buffer bandwidth provides packet buffer space to absorb burst traffic up to the specified duration of delay. To configure, include the buffer-size temporal statement at the [edit class-of-service schedulers scheduler-name] hierarchy level. [Class of Service]

Note: On some PICs you can enable much larger buffer sizes to be configured by including the q-pic-large-buffer statement in the configuration. For more information, see the JUNOS Class of Service Configuration Guide.

Per-unit scheduling on T1 interfaces (Channelized OC3 IQ PIC)—Enables multiple queues and output scheduling for each logical T1 interface. To configure per-unit scheduling on T1 interfaces, include the per-unit-scheduler statement at the [edit interfaces t1-fpc/pic/port:channel:channel] hierarchy level. This statement automatically enables multiple output queues on each logical interface that you configure. To associate a scheduler with the output queues, include the scheduler-map statement at the [edit class-of-service interfaces t1-fpc/pic/port:channel:channel unit logical-unit-number] hierarchy level. [Class of Service, Network Interfaces, Feature Guide]
Set the DSCP field of IPv4 and IPv6 packets to 000000 (M320 and T-series platforms)—Allows you to selectively set the DiffServ code point (DSCP) field of MPLS-tagged (or non-MPLS) IP version 4 (IPv4) and version 6 (IPv6) packets to 0 without affecting output queue assignment, and to continue to set the MPLS EXP field according to the configured rewrite table, based on forwarding classes. To configure the DSCP field to 0 for IPv4 traffic, include the dscp 0 action modifier at the [edit firewall family family-name filter filter-name term term-name then] hierarchy level. To configure the DSCP field to 0 for IPv6 traffic, include the traffic-class 0 action modifier at the [edit firewall family inet6 filter filter-name term term-name then] hierarchy level. [Class of Service, MPLS Applications, Policy]
Extended support for large delay buffers on slow interfaces (Channelized OC12 IQ PIC)—Enables you to control congestion and packet dropping that occur when large bursts of traffic are sent by a high-speed interface (such as an OC3) and received by a lower-speed interface (such as a T1 or NxDS0). To enable larger buffer sizes, include the q-pic-large-buffer statement at the [edit chassis fpc fpc-slot pic pic-slot] hierarchy level. To configure the delay buffer, include the buffer-size statement at the [edit class-of-service schedulers scheduler-name] hierarchy level. [Class of Service]

Network Management

MPLS OAM Traffic Engineering MIB—Provides support for RFC 3812, Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) (read-only access). [Network Management]
Allow system log events to trigger SNMP traps—Provides an enhancement to event policies to include a new action that raises traps for events based on system log messages. This feature enables notification of a Simple Network Management Protocol (SNMP) trap-based application when an important system log message occurs. You can convert any system log message (for which there are no corresponding traps) into a trap. This feature is valuable for customers who use network management system (NMS) traps rather than system log messages to monitor their networks. To convert a system log message into a trap, include the raise-trap statement at the [edit event-options policy policy-name then] hierarchy level. A new MIB (jnx-syslog.mib) is provided to support this feature. [Network Management, Configuration and Diagnostic Automation]
Standardized tracing operations for SNMP activity—Tracing operations for the following SNMP processes have been standardized to include new options for configuring access to log files and for configuring a regular expression for lines to be logged:
- SNMP agent process (snmpd)—Responds to SNMP requests.
- SNMP remote operations process (rmopd)—Services SNMP requests for execution of ping and traceroute operations.
- Management Information Base II (MIB II) process (mib2d)—Services requests for information gathered and reported by SNMP.
To configure access to log files, include the file (world-readable | no-world-readable) statement at the [edit snmp traceoptions] hierarchy level. To refine trace operation output, include the match regex statement at the [edit snmp traceoptions file filename] hierarchy level and specify a regular expression to be matched. [Network Management]
Newly supported traps and notifications—No changes or additions for this release.

JUNOScope

Specify options when importing XML—Supports synchronization of JUNOScope settings imported from multiple servers. The JUNOScope software provides the following import methods to use in case a conflict occurs between existing records stored in the JUNOScope server and the imported records:
- Ignore—(Default) An existing record stored in the JUNOScope server takes precedence over any imported record. The imported record is ignored and the existing record is not affected. Any imported record that does not exist in the JUNOScope server is inserted.
- Merge—If a record exists in the JUNOScope server and also exists in the imported record, the imported record merges with the existing record and is augmented as necessary. If an imported record conflicts with an existing record, the imported record takes precedence over the existing record. The existing record is merged with the imported record; however, the fields of the imported record take precedence over the fields of the existing record. Any imported record that does not exist in the JUNOScope server is inserted.
- Override—All records in the JUNOScope server are deleted; then all imported records are inserted. Before the override operation occurs, a message window appears with the following confirmation prompt: “The import with override option will delete all the existing records. Do you want to continue?” [JUNOScope]
Documented Database Administration Procedures for JUNOScope—Enables an administrator to back up and restore application data stored by JUNOScope, including settings, operational, and inventory data; archived device configurations; archived inventory reports; and imported JUNOS software images. [JUNOScope]

J-Web

Graphical chassis viewer for the J-Web user interface (M7i and M10i routers)—Displays a diagrammatic image of various chassis components and information about each component similar to what can be obtained by issuing the show chassis hardware command. To use the graphical chassis viewer, click the icon in the upper right-hand corner of any J-Web page to open a separate window displaying the image of the chassis and its component parts, including power supplies, individual PICs, and ports. [J-Web]
J-Web display enhancement—Adds the output of the show chassis fpc command into the J-Web user interface. To display the FPC information, navigate in J-Web to Monitor>Chassis. [J-Web]

JUNOS API and Other Scripting

Remote procedure call (RPC) system log message search—Provides a new JUNOS XML request tag element (<get-syslog-events>) that enables a JUNOScript or NETCONF client to request system log messages that match a specified set of filtering criteria. [JUNOS XML API Operational Reference]

New XML operational request tag elements—Table 1 lists the new JUNOS Extensible Markup Language (XML) operational request tag elements and their corresponding CLI commands.

Table 1: JUNOS 8.1 CLI Commands and Equivalent JUNOS XML Tag Elements

CLI Command	Request Tag Element	Response Tag Element
show chassis environment cb	<get-environment-cb-information>	<environment-component-information>
show chassis environment feb	<get-environment-feb-information>	<environment-component-information>
show chassis environment fpc	<get-environment-fpc-information>	<environment-component-information>
show chassis environment fpm	<get-environment-fpm-information>	<environment-component-information>
show chassis environment mcs	<get-environment-mcs-information>	<environment-component-information>
show chassis environment pcg	<get-environment-pcg-information>	<environment-component-information>
show chassis environment pem	<get-environment-pem-information>	<environment-component-information>
show chassis environment routing-engine	<get-environment-re-information>	<environment-component-information>
show chassis environment scg	<get-environment-scg-information>	<environment-component-information>
show chassis environment sfm	<get-environment-sfm-information>	<environment-component-information>
show chassis environment sib	<get-environment-sib-information>	<environment-component-information>
show cli authorization	<get-authorization-information>	<authorization-information>
show services cos statistics	<get-service-cos-statistics-information>	<service-cos-statistics-information>
show services cos statistics forwarding-class	<get-service-cos-forwarding-class-statistics>	<service-cos-forwarding-class-statistics>
show services cos statistics diffserv	<get-service-cos-diffserv-statistics>	<service-cos-diffserv-statistics>

[JUNOS XML API Operational Reference]

[ Contents] [ Prev] [ Next] [ Report an Error]