Features in JUNOS Software Release 9.3 for M-series, MX-series, and T-series Routing Platforms

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

Features in JUNOS Software Release 9.3 for M-series, MX-series, and T-series Routing Platforms

The following features have been added to JUNOS Release 9.3. Following the description is the title of the manual or manuals to consult for further information. For a complete list of manuals, see Table 11, Table 12, and Table 14.

Hardware

Extended FPC support for MultiServices 500 PICs—MultiServices 500 (Type 3) PICs are now supported on T640-FPC3-ES Flexible PIC Concentrators (FPCs), which can be installed in T640 and T1600 routing platforms. All the existing functionality, including both Layer 2 and Layer 3 services packages, is supported. There are no changes to the command-line interface (CLI) or the behavior of the PIC. [T640 PIC Guide, T1600 PIC Guide]
New Enhanced IQ PICs with SFP (M40e, M120, and T-series routing platforms)—The following Enhanced Intelligent Queuing (IQ) PICs with small form-factor pluggable transceivers (SFP) are available:
- 4-port Channelized DS3/E3 Enhanced IQ PIC
- 2-port Channelized SONET/SDH OC3/STM1 Enhanced IQ PIC
- 1-port Channelized SONET/SDH OC12/STM4 Enhanced IQ PIC
- 4-port DS3/E3 Enhanced IQ PIC
- 4-port SONET/SDH OC3/STM1 Enhanced IQ PIC
- 1-port SONET/SDH OC12/STM4 Enhanced IQ PIC
The Enhanced IQ PICs support all the same features as existing IQ PICs. The valid configuration statements are also the same; for some options, limits and ranges of values are different to support augmented capabilities. [PIC Guides, CoS, Network Interfaces]
New Circuit Emulation PICs (M7i, M10i, and M40e routers)—New Circuit Emulation PICs support structure-agnostic time-division multiplexing (TDM) over packet (SAToP) as defined in RFC 4553. The PICs provide Layer 2 circuit emulation service, which is used mainly in mobile backhaul applications. The following PICs are available:
- 12-port T1/E1 Circuit Emulation PIC
- 4-port SONET/SDH OC3/STM1 Circuit Emulation PIC
You can configure the 12-port T1/E1 PIC for either 12 T1-mode or 12 E1-mode interfaces, but not a combination of both interface types. To specify the mode for all interfaces on the PIC, include either the framing t1 or framing e1 statement at the [edit chassis fpc slot-number pic slot-number] hierarchy level. To configure each of the 12 interfaces, include either the interface-type t1 statement at the [edit interfaces ct1-fpc/pic/port no-partition] hierarchy level (for T1 mode) or the interface-type ce1 statement at the [edit interfaces ce1-fpc/pic/port no-partition] hierarchy level (for E1 mode). [PIC Guides, Network Interfaces, System Basics]
New MultiServices DPC (MX-series Ethernet services routers)—The MultiServices Dense Port Concentrator (DPC) supports the following Layer 3 services:
- Active flow monitoring
- Generic routing encapsulation (GRE) tunnels (including GRE key and fragmentation)
- Intrusion detection service (IDS)
- IP Security (IPsec)
- Network address translation (NAT)
- Real-time performance monitoring (RPM)
- Stateful firewall
All functionality available for these features on Adaptive Services and MultiServices PICs is also available on MultiServices DPCs and is configured by including the existing statements at the [edit services] hierarchy level. All existing commands for monitoring the features are also supported. The show chassis commands represent MultiServices DPCs as MS-DPC or MS-DPC PIC. [DPC Guide, Network Interfaces, Services Interfaces]

Software Installation and Upgrade

License support for CoA—The RADIUS Change-of-Authorization (CoA) feature is part of the Subscriber Access Feature Pack License. As with other licensed JUNOS features, you can commit a configuration that includes the CoA feature without having a license and use the feature for a 30-day trial period (dated from first actual use of the feature). To display license key information, issue the show system license command. [Software Installation and Upgrade]

User Interface and Configuration

“Logical system” replaces “logical router”—Beginning in JUNOS Release 9.3, the term logical system and the JUNOS name logical-system replace their previous counterparts logical router and logical-router in all contexts, including configuration statements, command names and output fields, error and log messages, and SNMP MIB object names. The [edit logical-routers] hierarchy level is now [edit logical-systems].
The name logical-router is still accepted in JUNOS Release 9.3, to enable continued use of scripts and other tools that use the previous name. Similarly, in JUNOS Releases 8.3R2 through 9.2, logical-system is accepted as an alternate to logical-router. We encourage you to update your JUNOS environment to use the new term. [All JUNOS documentation]

Interfaces and Chassis

External clock synchronization (M120 routers)—Enables you to synchronize an M120 router’s internal Stratum 3 clock module to a standard external timing source such as Building Integrated Timing System (BITS), SDH Equipment Timing Source (SETS), or an equivalent quality timing source. External clock synchronization is supported for T1, E1, and SONET/SDH interfaces. To configure external clock synchronization, include the synchronization statement at the [edit chassis] hierarchy level. To view information about the external clock synchronization, issue the show chassis synchronization command. To change the external clock synchronization time source, issue the request chassis synchronization switch command. [System Basics, System Basics Command Reference]
Interfaces shared by PSDs—Enables multiple Protected System Domains (PSDs) to receive and forward traffic on the interfaces on a PIC. (A PSD is a Routing Engine [or pair of redundant Routing Engines] on the JCS 1200 platform that is associated with one or more FPCs on a T-series routing platform.) Any FPC that is not assigned to a specific PSD can be used to host shared interfaces. In JUNOS Release 9.3, interfaces on SONET/SDH PICs only can be shared.
On the Root System Domain (RSD), you configure multiple logical interfaces on a physical SONET/SDH interface (the shared uplink interface) and assign each logical interface to a specific PSD. On the PSD, you include a corresponding configuration stanza for the physical interface and the logical interfaces, peering each logical interface with a logical interface on a Tunnel PIC managed by the PSD. The Tunnel PIC transports packets between that logical interface on the PSD and the physical interface on the RSD. In the configuration on both the RSD and PSD, you must specify Frame Relay encapsulation for the physical interface (but point-to-multipoint Frame Relay encapsulation is not supported).

On the RSD, assign each logical interface to a PSD by including the new uplink-shared-with psdn statement at the [edit interfaces so-fpc/pic/port.logical-unit-number] hierarchy level for the logical interface.

On the PSD, include the following new statements at the indicated hierarchy levels:
- The shared-uplink statement at the [edit interfaces so-fpc/pic/port] hierarchy level, to identify the physical SONET interface acting as the shared uplink
- The ut-fpc/pic/port statement at the [edit interfaces] hierarchy level, to configure the physical interface on the Tunnel PIC as an uplink tunnel interface
You must also include other existing statements to complete the interface configuration on the RSD and PSDs; for details, see the PSD documentation.

When applied to shared interfaces, JUNOS features that are configured on logical interfaces—such as CoS classifiers and rewrite rules, firewall filters, and policers—are configured on the PSD. With JUNOS Release 9.3, only output filtering is supported. JUNOS features that are configured on physical interfaces, such as drop profiles and scheduler maps, are configured on the RSD.

The following new fields in the output from the show interfaces so-fpc/pic/port command display information about shared interfaces:
- Shared-uplink—Located in the Physical interface: section; indicates whether the routing domain owns the shared interface.
- Shared uplink—Located in the Logical interface: section; includes these fields:
  - shared with—(RSD only) Names the PSD that owns the logical shared interface. For example, psd3.
  - peer interface—(PSD only) Names the logical tunnel interface that peers with the logical shared interface. For example, ut-2/1/0.2.
  - tunnel token—Specifies the receive (Rx) and transmit (Tx) tunnel tokens. For example, Rx: 5.519, Tx: 13.514.
[Protected System Domain]
Finer control of active and standby LACP links (MX-series routers)—Enables you to better control the behavior of active and standby links on aggregated Ethernet interfaces by more precisely defining Link Aggregation Control Protocol (LACP) system and port priorities. To configure LACP system priority for all aggregated Ethernet interfaces on a router, include the new system-priority statement at the [edit chassis aggregated-devices ethernet lacp] hierarchy level. To configure LACP system priority for a particular interface, include the system-priority statement at the [edit interfaces aex aggregated-ether-options lacp] hierarchy level. To configure LACP port priority for a particular interface, include the new port-priority statement at the [edit interfaces interface-name (fastether-options | gigether-options) 802.3ad aex lacp] hierarchy level.
In addition, the new link-protection statement specifies revertive or nonrevertive protection for aggregated Ethernet interfaces. In revertive mode, when a new link becomes operational or is added to the aggregator, LACP recalculates link priority and the link with higher priority (lower numerical value) becomes the active link. In nonrevertive mode, when collection distribution is enabled, the current active link retains that role even if its priority is lower (is numerically higher) than a subsequently added link. To configure link protection for all aggregated Ethernet interfaces, include the link-protection statement at the [edit chassis aggregated-devices ethernet lacp] hierarchy level. To configure link protection for a particular aggregated Ethernet interface, include the link-protection statement at the [edit interfaces aex aggregated-ether-options lacp] hierarchy level.

The new request lacp link-switchover aex operational mode command supports forced switchover to a different active link. Because the command overrides LACP priority calculations, we strongly recommend that you use it only when the actor (the Juniper Networks router) is controlling the active and standby links and the partner (peer) is following, which applies when you configure only the actor for link protection.

The show lacp interfaces command is enhanced to display link state (active or standby). [Network Interfaces, System Basics]
Extended platform support for Ethernet OAM—Support for Ethernet Operation, Administration, and Maintenance (OAM) is extended to several types of Gigabit Ethernet PICs installed in Enhanced III FPC3 FPCs in M320 routers and in M120 routers. [Network Interfaces]
Ethernet host addresses with no subnets—Enables you to configure an Ethernet interface as a host address (that is, with a network mask of /32), without requiring a subnet. Such interfaces can serve as OSPF point-to-point interfaces, and MPLS is also supported. [Network Interfaces, Routing]
Layer 2 circuit signaling extensions for SAToP and CESoP TDM pseudowires—Enables wireless service providers to replace T1 and E1 time-division multiplexing (TDM) circuits with T1 and E1 pseudowires for backhauling cell site traffic towards a binary synchronous communications (BSC) device or radio network controller (RNC). Support is added for SAToP or structure-aware TDM circuit emulation service over packet (CESoP) pseudowires on the 12-port T1/E1 Circuit Emulation PIC and the 4-port OC3c/STM1 Circuit Emulation PIC channelized for T1/E1 interfaces using LDP-signaled Layer 2 circuits. To configure SAToP or CESoP encapsulation on a T1 or E1 interface for a PE router, include the satop or cesop statement at the [edit interfaces interface-name encapsulation] hierarchy level. [Network Interfaces]
Command for monitoring Packet Forwarding Engine memory usage (M320 and T-series routing platforms)—The new show pfe resource usage memory command displays static RAM (SRAM) memory usage statistics for the Packet Forwarding Engine. [System Basics Command Reference]
Annex B support for SONET multiplex section protection (M120 and M320 routers)—Enables you to configure support for Annex B standards when you enable multiplex section protection (MSP) switching on SONET/SDH interfaces. Include the sonet-options aps annex-b statement at the [edit interfaces so-fpc/pic/port] hierarchy level. Use the show aps extensive command to display detailed information about an Annex B configuration. [Network Interfaces]

Services Applications

VPN aggregation for VoIP calls—Supports virtual private network (VPN) routing and forwarding (VRF) instances with the Packet Gateway Control Protocol (PGCP). Users on one VPN can now call users on another VPN, across up to 1024 Layer 3 VPNs. Scalability enhancements include a mesh-like VRF configuration that uses only one logical service interface for each VRF, and the ability to assign a pool of logical service interfaces to a service set, which eliminates the previous requirement for large numbers of separately configured service sets and logical service interfaces.
To configure a pool of logical services interfaces, include statements at the [edit services service-interface-pools] hierarchy level. To associate a pool with a service set, include the next-hop-service service-interface-pool statement at the [edit services service-set service-set-name] hierarchy level.

To display VRF instances on gates or flows for a particular virtual packet gateway (VPG), include the new destination-routing-instance and source-routing-instance options for the show services pgcp gates gateway-name and show services pgcp flows gateway-name commands. To view linked VPNs on gates and flows, include the extensive option for the commands. [Multiplay Solutions, Services Interfaces, System Basics Command Reference]
Protection against PGCP notification “avalanches” (T640 routing node)—Prevents a packet gateway from sending an excessive number (an avalanche) of media inactivity notifications to the packet gateway controller (PGC) in a short period of time, which can severely degrade PGC performance. For example, when an upstream device in the network fails, all existing terminations in the packet gateway by default report media inactivity immediately, so all notifications arrive at the PGC at about the same time. Avalanche protection enables you to regulate the flow of notifications.
You can implement avalanche protection in one of two ways:
- As an H.248 property—Include the ip-flow-stop-detection statement at the [edit services pgcp gateway gateway-name h248-properties application-data-inactivity-detection] hierarchy level, specifying either immediate or regulated notification. To configure the transmission frequency for regulated notification, include the notification-regulation default value statement at the [edit services pgcp gateway gateway-name h248-properties notification-behavior] hierarchy level. To display the settings for regulated notification, issue the show services pgcp gateway gateway-name h248-properties notify-behavior command.
- As a limit on the PIC—Include the rate-limit statement at the [edit services pgcp] hierarchy level. This limits the transmission rate for all message types generated on the PIC, not just inactivity notifications.
You can log all notifications, along with other observed events, by including the audit-observed-events-returns statement at the [edit services pgcp gateway gateway-name h248-properties] hierarchy level. To include a timestamp on each event, include the event-timestamp-notification statement at the [edit services pgcp gateway gateway-name h248-properties] hierarchy level. [Multiplay Solutions, Services Interfaces, System Basics Command Reference]
H.248 overload control (M120, M320, and T640 platforms)—Enables a packet gateway to notify a PGC when it experiences processing overload that might prevent the timely execution of H.248 transactions. The packet gateway sends an overload notification to the PGC when the number of incoming H.248 transactions that are pending in its queue reaches the configured limit, which is defined as a percentage of the queue size. In response, the PGC lowers the admitted rate at which transactions are sent to the packet gateway. If the queue becomes 100 percent full, the packet gateway discards new transactions and sends error code #510 (Insufficient resources). To configure the queue usage percentage at which the packet gateway starts sending overload notifications, include the queue-limit-percentage statement at the [edit services pgcp gateway overload-control] hierarchy level. To display the queue usage percentage, issue the show services pgcp active-configuration command. [Multiplay Solutions, Services Interfaces, System Basics Command Reference]
RPM TWAMP support on MultiServices PICs—Adds support for the RPM Two-Way Active Measurement Protocol (TWAMP) on MultiServices PICs running in Layer 2 mode, as defined in Internet draft draft-ietf-ippm-twamp-09.txt, A Two-way Active Measurement Protocol (TWAMP). You can enable TWAMP on all MultiServices PIC models and on all router platforms that support these PICs. To enable TWAMP, include the following statements in the configuration:
- The server statement at the [edit services rpm twamp] hierarchy level
- The client-list and port statements at the [edit services rpm twamp server] hierarchy level, to define at least one client address and a TWAMP listening port
- The twamp-server statement at the [edit interfaces sp-fpc/pic/port unit logical-unit-number] hierarchy level, to specify the logical interface that provides the TWAMP service
To monitor TWAMP functionality, issue the show services rpm twamp server connection and show services rpm twamp server session commands. To clear server connections, issue the clear services rpm twamp server connection command. [Services Interfaces, System Basics Command Reference]
IPv6 flow aggregation templates—Adds support for IPv6 traffic templates for use with version 9 flow aggregation. Previously, only IPv4 and MPLS templates were supported. Include the family inet6 statement at the [edit forwarding-options sampling input] hierarchy level and the new ipv6-template option at the [edit services flow-monitoring version9 template template-name] hierarchy level. To filter the IPv6 traffic on a media interface, include the sampling (input | output) statement at the [edit interfaces interface-name unit logical-unit-number family inet6] hierarchy level. [Services Interfaces, Feature Guide]
Enhanced traffic class support for flow monitoring version 9 (M-series and T-series routing platforms)—Supports IPv6 with version 9 flow monitoring traffic sampling and templates. In addition, adds support for multiple traffic classes for version 9 flow monitoring traffic sampling and templates. To configure IPv6 on version 9 sampling, include the family inet6 statement at the [edit forwarding-options sampling input] hierarchy level. To configure multiple traffic classes, include more than one of the family options (family inet, family inet6, or family mpls) at the [edit forwarding-options sampling input] hierarchy level. To define IPv6 for the version 9 template record, include the ipv6-template statement at the [edit services flow-monitoring version9 template template-name] hierarchy level. Services Interfaces, Feature Guide]

Subscriber Access Management

New Mobile IP home agent (MX-series routers)—The JUNOS software now supports Mobile IP, a tunneling-based solution that enables an MX-series router on a user’s home subnet to track subscribers who roam beyond traditional network boundaries. The roaming subscribers are known as mobile nodes and they are tracked by registration with the Mobile IP home agent. The home agent forwards IP packets intended for the mobile node to the care-of address (CoA) currently being used by the mobile node.
Mobile IP is useful in environments where mobility is desired and the traditional land line dial-in model does not provide an adequate solution, and in environments where a wireless technology is used. Both GRE and IP-in-IP static tunnels are supported.

To configure Mobile IP service, you enable it on one or more interfaces and configure attributes of the virtual network on the router that hosts the home agent. Optionally, you can configure dynamic home assignment to redirect mobile node registration requests to a different home agent. You can also specify how the mobile node is authenticated.

To enable Mobile IP service on one or more interfaces, include the interface names at the new [edit services mobile-ip home-agent enable-service] hierarchy level.

To configure the virtual network on the home agent, include the virtual-network statement at the [edit services mobile-ip home-agent] hierarchy level. To specify the home agent’s IP address, include the home-agent-address address statement at the [edit services mobile-ip home-agent virtual-network] hierarchy level. The IP address must be a loopback address. You can also include the following statements at the [edit services mobile-ip home-agent virtual-network home-agent-address address] to configure attributes of the home agent:
- registration-lifetime number—Sets the maximum lifetime that the home agent grants to a mobile node registration. If the mobile node requests a lifetime longer than this value, the home agent assigns this lifetime. When the lifetime expires, the home agent removes the binding entry for the mobile node and tears down the session.
- revocation-required—Controls whether the home agent can revoke a mobile node registration.
- timestamp-tolerance number—Sets the maximum difference that the home agent accepts between its local time and a mobile node timestamp.
To configure the method that the home agent uses to authenticate mobile nodes, include the order statement at the [edit services mobile-ip authenticate] hierarchy level. Specify the value aaa for RADIUS authentication (the default), or local for local authentication. For more information about RADIUS authentication of mobile nodes, see the next bullet item in this section.

To configure the home agent to redirect a mobile node’s registration request to a different home agent, include the nai statement at the [edit services mobile-ip dynamic-home-assignment home-agent] hierarchy level. Specify the network address identifier (NAI) for the mobile node in one of two formats: hostname@domain-name.com or @domain-name.com. To specify the address of the home agent for that mobile node, include the home-agent address statement at the [edit services mobile-ip dynamic-home-assignment home-agent nai nai] hierarchy level.

To trace home agent operations for troubleshooting purposes, include the flag home-agent statement at the [edit services mobile-ip traceoptions] hierarchy level.

The following is a sample Mobile IP configuration:

[edit services mobile-ip] home-agent { enable-service { ge-0/1/1.0; ge-0/2/1.0; } virtual-network { home-agent-address 192.168.3.1 { registration-lifetime 100; registration-revocation required; timestamp-tolerance 200; } } } dynamic-home-assignment { home-agent { nai tsr23@example.com { home-agent 10.1.3.1; } } }

To monitor and manage a Mobile IP home agent, issue the following new commands:
- clear mobile-ip binding (all | ip-address address | nai identifier)—Clears the binding between the home agent and either all mobile nodes or the mobile node with the specified IP address or NAI.
- clear mobile-ip host (all | ip-address address | nai identifier)—Deletes either all mobile nodes and their binding information, or the mobile node with the specified IP address or NAI and its binding information.
- show mobile-ip home-agent overview—Displays summary information about the home agent.
- show mobile-ip home-agent bindings (ip-address address | nai identifier | summary)—Displays information about bindings between a home agent and either all mobile nodes or the mobile node with the specified IP address or NAI.
- show mobile-ip home-agent virtual-network—Displays information about the virtual network used by the mobile nodes.
- show mobile-ip home-agent traffic—Displays traffic statistics associated with the home agent.
[Subscriber Access]

RADIUS-based authentication of mobile nodes using Juniper Networks VSAs—Enables the Mobile IP home agent to use RADIUS to authenticate mobile nodes that request registration (see the previous bullet item in this section). The home agent extracts the NAI or the node address from the registration request. The authentication, authorization, and accounting service (AAA) generates a RADIUS Access-Request message with the NAI or address as the User-Name attribute (the address is used only if the NAI is missing from the mobile node’s request). AAA sends the Access-Request message to the RADIUS server, which returns Juniper Networks vendor-specific attributes (VSAs) in Access-Accept messages to provide the security association information required to authenticate the mobile node.

The User-Password attribute is also required for authentication, but the registration request does not include this attribute. When you define AAA parameters, you must set the User-Password attribute to the value juniper.

The home address to be used by the mobile node is conveyed to the RADIUS server in the Access-Request message by one of two standard RADIUS attributes. You can statically configure the home address in the Framed-IP-Address attribute. Alternatively, you can configure a local address pool from which to allocate home addresses to mobile nodes. In this case, the pool identification is passed in the Framed-Pool attribute. You configure these attributes when you configure AAA parameters at the [edit access] hierarchy level.

The Mobile IP home agent uses RADIUS authentication by default. To explicitly specify its use, include the order aaa statement at the [edit services mobile-ip authenticate] hierarchy level.

You can trace Mobile IP authentication events by including the following statements at the [edit services mobile-ip traceoptions] hierarchy level:

flag authentication—Trace includes all authentication-specific events.
flag session-db—Trace includes all session-specific events.
flag subscriber—Trace includes all events involving subscribers.

Table 1 describes the VSAs configured on the RADIUS server for RADIUS-based authentication during Mobile IP registration. The JUNOS software uses the vendor ID assigned to Juniper Networks (vendor ID 4874) by the Internet Assigned Numbers Authority (IANA).

Table 1: VSAs for Mobile IP Authentication

VSA Number	VSA Name	Definition
[26-84]	Mobile-IP-Algorithm	Authentication algorithm (optional)
[26-85]	Mobile-IP-SPI	Security parameter index (mandatory)
[26-86]	Mobile-IP-Key	Security association MD5 key (mandatory)
[26-87]	Mobile-IP-Replay	Replay timestamp (optional)
[26-89]	Mobile-IP-Lifetime	Maximum registration lifetime (optional)

If you do not configure the mandatory VSAs, mobile nodes cannot be authenticated and are not registered with the home agent. If you do not configure an optional VSA, RADIUS uses a locally configured value or a default value if there is no locally configured value. When the mobile node is authenticated, the Mobile IP home agent caches all subscriber-related information that was returned by the RADIUS server. Consequently, subscriber configuration changes made in the RADIUS server after authentication do not take effect until the subscriber logs out. [Subscriber Access]

DHCP support for dynamic demux interfaces (MX-series routers)—The Dynamic Host Configuration Protocol (DHCP) local server and DHCP relay agent now support the creation of dynamic demux interfaces. To configure dynamic demux interfaces for the DHCP local server, include the dynamic-profile profile-name statement at the [edit system services dhcp-local-server] or [edit system services dhcp-local-server group group-name] hierarchy level. To configure them for the DHCP relay agent, include the dynamic-profile profile-name statement at the [edit forwarding-options dhcp-relay] or [edit forwarding-options dhcp-relay group group-name] hierarchy level.
For both the DHCP local server and DHCP relay agent, you can specify the primary dynamic profile that is instantiated when the first subscriber logs in. This conserves interfaces in networks where dynamic demux interfaces are used to represent subscribers. To configure a primary dynamic profile, include the use-primary primary-profile-name statement at the appropriate hierarchy level: [edit system services dhcp-local-server dynamic-profile profile-name], [edit system services dhcp-local-server group group-name dynamic-profile profile-name], [edit forwarding-options dhcp-relay dynamic-profile profile-name], or [edit forwarding-options dhcp-relay group group-name dynamic-profile profile-name].

To limit the number of subscribers who can simultaneously log in for a group of interfaces, include the interface-client-limit statement at the [edit system services dhcp-local-server group group-name overrides] hierarchy level for the DHCP local server, and at the [edit forwarding-options dhcp-relay-agent group group-name overrides] hierarchy level for the DHCP relay agent. When the limit is reached, new discovery messages are discarded and counted. When the number of logged-in subscribers drops below the limit, new subscribers are allowed to log in. [Subscriber Access]
Dynamic subscriber interfaces for IP demux interfaces (MX-series routers)—Enables you to configure an IP demux interface to represent a subscriber interface in a dynamic profile. When a subscriber logs in using a DHCP access method, the demux interface is dynamically created. To configure the settings that DHCP applies to the interface when the subscriber logs in, include the demux0 statement at the [edit dynamic-profiles profile-name interfaces] hierarchy level. [Subscriber Access]
MAC address validation for Ethernet and IP demux interfaces (MX-series routers)—Enables the router to validate incoming packets by verifying that their source is a trusted IP and Ethernet media access control (MAC) address. The validation provides additional security when subscribers access billable services, because the router can discard packets that do not meet the validation requirements, such as packets with spoofed addresses.
MAC address validation is supported on IP demux interfaces and aggregated Ethernet, Fast Ethernet, Gigabit Ethernet, and 10-Gigabit Ethernet interfaces (with or without virtual LAN [VLAN] tagging) on MX-series routers only. The interfaces can be statically created or dynamically created using a dynamic profile.

To configure MAC address validation, include the mac-validate (loose | strict) statement at the [edit interfaces interface-name unit logical-unit-number family family-name] hierarchy level for static interfaces and the [edit dynamic-profiles interfaces interface-name unit logical-unit-number family family-name] hierarchy level for dynamic interfaces.

The output from the show interfaces command is enhanced to indicate whether MAC address validation is enabled. [Subscriber Access, Network Interfaces, Interfaces Command Reference]
Optional disabling of automatic ARP table population (MX-series routers)—Enables you to hide subscriber MAC address information from devices located outside the trusted access domain (for example, an external digital subscriber line access multiplexer [DSLAM]). By default, as communication is established with subscriber-access clients, the router’s Address Resolution Protocol (ARP) table is populated with client MAC address and newly-provisioned IP address information that is obtained from the DHCP local server or relay agent. To instead populate the table with less specific information that is safe to share with devices outside a trusted domain, include the no-arp statement at the appropriate hierarchy level:
- [edit forwarding-options dhcp-relay overrides]
- [edit forwarding-options dhcp-relay group group-name overrides]
- [edit system services dhcp-local-server overrides]
- [edit system services dhcp-local-server group group-name overrides]
[Subscriber Access]
Command to monitor active subscribers—The new show subscribers command displays information about active subscribers, including subscriber type, username, IP address, dynamic profile name, MAC address, and login time. [System Basics Command Reference]

Layer 2 Ethernet Services

Port-based access control (MX-series routers)—Implements the Institute of Electrical and Electronics Engineers (IEEE) standard 802.1x, Port-Based Network Access Control, which provides authenticated access to specific router ports. The only unauthenticated traffic accepted on a protected port is 802.1x control packets, which are forwarded to the Routing Engine for processing. Several 802.1x-compliant authentication methods are supported, including RADIUS and Microsoft Active Directory server.
You can enable port-based authentication on bridged ports, but not on routed ports. Dynamic changes to a user session are supported, which enables you to terminate an authenticated session by using the RADIUS disconnect message defined in RFC 3576, Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS).

To configure port-based authentication, include the authenticator statement at the [edit protocols dot1x] hierarchy level. [Network Interfaces]

Routing Policy and Firewall Filters

Aggregate policers for different family address types on the same interface—Enables you to configure separate firewall filters for different family address types that share the same interface and to configure the same policer as an action for each filter. To configure the aggregate policer, include the logical-interface-policer statement at the [edit firewall policer policer-name] hierarchy level. To apply the policer as a firewall filter action, include the policer-name statement at the [edit firewall family family-name filter filter-name term term-name then] hierarchy level. [Policy]
Lower minimum policer bandwidth limit (M120, M320, and MX-series routers)—Enables you to specify a policer bandwidth limit as low as 8000 bits per second (bps) on these routers. On all other routing platforms, the minimum policer bandwidth remains at 32,000 bps. Include the bandwidth-limit limit statement at the [edit firewall policer policer-name if-exceeding] hierarchy level. [Policy]

Routing Protocols

BFD protocol support for OSPFv3—Enables OSPFv3 to use the Bidirectional Forwarding Detection (BFD) protocol to detect network failures for IP version 6 (IPv6) traffic. (OSPFv2 continues to support BFD, as in previous releases.) Failures are detected more quickly than with OSPFv3’s default failure detection mechanism, because BFD’s failure-detection time limits are shorter. To enable BFD failure detection for OSPFv3, include the bfd-liveness-detection statement at the [edit protocols ospf3 area area-id interface interface-name] or [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name] hierarchy level. BFD for OSPFv3 is also supported for logical systems. The show bfd session detail command has been enhanced to display OSPFv3 information. [Routing, Routing Command Reference]
Priority assignment for prefixes in OSPF import policies—Enables you to assign one of three priority levels (high, medium, and low) to a prefix included in an OSPF import policy. The configured priorities determine the order in which OSPF routes are updated in the routing table after a network topology change, which is useful in a network with a large number of OSPF routes. In general, routes to which you do not explicitly assign a priority are treated as medium priority.
To configure prefix priority, include the priority (high | medium | low) statement at the [edit policy-options policy-statement policy-name term term-name then] hierarchy level. To apply the routing policy, include the import statement at the [edit protocols (ospf | ospf3)] or [edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] hierarchy level. The import policy can also be applied within a routing instance or logical system. The show ospf route detail command has been enhanced to display the priority of network routes. [Policy, Routing, Routing Command Reference]
Advertisement of the best external BGP path to internal peers—Enables a BGP peer to advertise the external path that has the highest local preference value to its internal peers (that is, into an internal BGP mesh group, route reflector cluster, or autonomous system [AS] confederation) even when the overall best path is an internal route. Being able to advertise this external path can be helpful in scenarios known to result in internal BGP route oscillation. To configure, include the advertise-external statement at the [edit protocols bgp group group-name] hierarchy level.
You can also configure BGP to restrict advertisement of the best external path over an active path with an equal cost until the route selection process reaches the step where the multiple exit discriminator (MED) metric is evaluated. As a result, an external path with an AS path worse than that of the active path is not advertised. To configure, include the conditional statement along with the advertise-external statement at the [edit protocols bgp group group-name] hierarchy level.

To configure a BGP export policy to match on routes advertised through this feature, include the state (active | inactive) statement at the [edit policy-options policy-statement statement-name term term-name from] hierarchy level. [Policy, Routing]
Support for SEND—Enables you to secure neighbor-discovery messages with the Secure Neighbor Discovery (SEND) protocol, which uses cryptographically generated addresses (CGAs) as defined in RFC 3972, Cryptographically Generated Addresses. SEND is useful in environments where physical security is not assured on the shared link over which IPv6 nodes send neighbor discovery messages to locate one another, determine link-layer addresses, and maintain reachability information about paths to active neighbors.
By default, routers send and receive both secured and unsecured neighbor-discovery messages. To permit acceptance of secured messages only, include the secure-messages-only statement at the [edit protocols neighbor-discovery secure security-level] hierarchy level.

You must also enable the use of CGAs by including the cryptographic-address statement at the [edit protocols neighbor-discovery secure] hierarchy level. Optionally, you can specify a file that contains a public-private key pair and the length of the key by including the key-pair filename and key-length number statements at the [edit protocols neighbor-discovery secure cryptographic-address] hierarchy level.

To configure timestamp options that help protect against replay attacks, include the timestamp statement at the [edit protocols neighbor-discovery secure] hierarchy level.

You can configure SEND for individual logical systems by including the appropriate statements at the [edit logical-systems logical-system-name protocols neighbor-discovery secure] hierarchy level.

The new Secure field in the output of the show ipv6 neighbors command displays SEND information. [Routing, Routing Command Reference]

Multicast

Full support for IGMPv3 and MLDv2—Enhances the JUNOS implementation of Internet Group Management Protocol version 3 (IGMPv3) and Multicast Listener Discovery protocol version 2 (MLDv2) to support all protocol features. In particular, the JUNOS software now supports exclude mode, which enables a host to specify sources that do not need to send traffic to it. In JUNOS Release 9.2 and earlier, only include mode is supported.
In the output from the show igmp group and show mld group commands, the new Group mode field reports the mode as Exclude or Include. [Multicast, Routing Command Reference]

MPLS Applications

MPLS applications over non-MPLS enabled networks (M7i, M10i, and M40e routers)—Enables MPLS to run on networks that do not have MPLS enabled on their core routers, by replacing the top label of the MPLS label stack with an IP-based encapsulation. There are no new statements associated with this feature. To tunnel MPLS traffic through a non-MPLS enabled network, include the tunnel statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level. Only IP version 4 (IPv4) tunnels are supported. [MPLS]

Routing Policy and Firewall Filters

Additional numeric-range match conditions in firewall filters (MX-series routers)—Extends the set of match conditions for firewall filters on MX-series routers to include the following:
- (learn-vlan-1p-priority | learn-vlan-1p-priority-except)—Learned IEEE 802.1p VLAN priority
- (loss-priority | loss-priority-except)—Packet loss priority (PLP)
- (user-vlan-1p-priority | user-vlan-1p-priority-except)—User IEEE 802.1p VLAN priority
The four new match conditions based on IEEE 802.1p VLAN priority are valid for the bridging and virtual private LAN service (VPLS) protocol families only (you can include them at the [edit firewall family (bridge | vpls) filter filter-name term term-name from] hierarchy level).

The two new match conditions based on PLP are valid for all protocol families only (you can include them at the [edit firewall family (any | bridge | ccc | inet | inet6 | mpls | vpls) filter filter-name term term-name from] hierarchy level). [Policy, MX-series Solutions]
Port mirroring of Layer 2 bridge and VPLS traffic (MX-series routers)—Enables you to configure port mirroring for Layer 2 traffic. Include the family (inet | inet6 | vpls) statement at the [edit forwarding-options port-mirroring] hierarchy level. You can configure various types of port mirroring by including the indicated statements:
- To configure multiple instances of port mirroring, include the instance instance-name statement at the [edit forwarding-options port-mirroring] hierarchy level.
- To associate a specific port-mirroring instance with a specific DPC, include the port-mirror-instances instance-name statement at the [edit chassis fpc slot-number] hierarchy level.
- To configure the router to mirror traffic only once, include the mirror-once statement at the [edit forwarding-options port-mirroring] hierarchy level. This option is useful when you are performing port mirroring on both the ingress and egress interfaces.
The extended support of port mirroring means you can now include the port-mirror action at the [edit firewall family (bridge | vpls) filter filter-name term term-name then] hierarchy level. [Layer 2, System Basics]
Firewall filters within logical systems—Enables you to configure firewall filters that apply only within a particular logical system by including statements at the [edit logical-systems logical-system-name firewall] hierarchy level. Most of the statements that are valid at the global [edit firewall] hierarchy level are also valid for individual logical systems; for details, see the JUNOS Policy Framework Configuration Guide.
In general, the firewall filters for a logical system must be complete and self-contained. They cannot reference firewall elements configured at the [edit firewall] hierarchy level or at the [edit logical-systems logical-system-name firewall] hierarchy level for a different logical system.

If you do not configure firewall filters for a logical system, the filters defined at the [edit firewall] hierarchy level apply to it. If you do configure filters for a logical system, the globally defined filters do not apply. If you want globally defined filters to apply to the logical system, you must explicitly configure them at the appropriate [edit logical-systems logical-system-name firewall] hierarchy level. To reduce duplication of effort in this case, define the filters in one or more configuration groups and apply the groups at the appropriate hierarchy levels. [Policy]

VPNs

Associating VPLS CE-facing interfaces with CE mesh groups—The JUNOS software now associates VPLS customer edge (CE)-facing interfaces with the CE mesh groups to which they belong, providing better control over the flooding behavior of VPLS routing instances. In JUNOS Release 9.2 and earlier, all CE-facing interfaces are associated with the default CE mesh group, which causes redundant packet forwarding in fully meshed CE devices, because packets arriving at a CE-facing interface are flooded to all other CE-facing interfaces in the default CE mesh group. To associate an interface with a mesh group, include the interface interface-name statement in the configuration for the mesh group. [VPNs]
Clearing MAC addresses for better convergence—Enables you to remove dynamically learned MAC addresses from the MAC address database, which promotes faster MAC address convergence. To enable MAC address clearing globally, include the mac-tlv-recv and mac-tlv-send statements at the [edit routing-instances routing-instance-name protocols vpls] hierarchy level. To enable MAC address clearing on the routers in a specific mesh group, include the mac-tlv-recv and mac-tlv-send statements at the [edit routing-instances routing-instance-name protocols vpls mesh-group mesh-group-name] hierarchy level. [VPNs]
Inter-AS VPLS with MAC processing at the AS boundary router—Enables a service provider to interconnect customer sites located in different ASs. Inter-AS VPLS requires internal BGP (IBGP) peering between the provider edge (PE) routers within an AS (including the AS boundary routers), and also requires external BGP (EBGP) peering between the AS boundary routers of different ASs. Both a full mesh of multihop EBGP sessions and a full mesh of label-switched paths (LSPs) are required between all AS boundary routers that peer with the AS boundary routers in the other ASs and provide VPLS service (BGP LSPs are sufficient). The route targets configured for the customer’s VPLS routing instances across multiple ASs must be identical.
To configure inter-AS VPLS, include the peer-as all statement at the [edit routing-instances routing-instance-name mesh-group mesh-group-name] hierarchy level on provider edge (PE) router that participates in the mesh group. Only one mesh group can be configured, and automatic site IDs are not supported. To verify and troubleshoot inter-AS VPLS configurations, issue the show vpls connections command. [VPNs, Feature Guide]
Multiple logical trunk interfaces per physical interface—Enables you to configure multiple logical trunk interfaces on a single physical interface. To configure, include the vlan-tagging or flexible-vlan-tagging statement at the [edit interfaces interface-name] hierarchy level. To configure the list of acceptable VLAN IDs, include the vlan-id-list statement at the [edit interfaces interface-name unit logical-unit-number family bridge] hierarchy level.
Including the family bridge statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level enables the logical interface to belong to multiple bridge domains. To designate a logical interface as an automatic member of all bridge domains specified at the [edit interfaces interface-name unit logical-unit-number family bridge] hierarchy level, include the interface in the virtual switch configuration for the routing instance. To configure a virtual-switch routing instance, include the instance-type virtual-switch statement at the [edit routing-instances routing-instance-name] hierarchy level.

Including the family bridge statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level further enables the logical interface to handle VPLS routing instance traffic but be a part of a virtual switch routing instance. This enables you to configure multiple customer sites to use the same pseudowire, relying on the inner packet’s VLAN ID to identify the customer traffic.

To configure a dual tagged trunk interface, include the flexible-vlan-tagging statement at the [edit interfaces interface-name] hierarchy level. Configure the outer tag by including the vlan-tags outer statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level, and configure the inner tag by including the inner-vlan-id-list statement at the [edit interfaces interface-name unit logical-unit-number family bridge] hierarchy level. [Layer 2]
VPLS trunk pseudowire interfaces (MX-series routers)—Enables VPLS functionality within a virtual-switch routing instance (one for which the configuration includes the instance-type virtual-switch statement at the [edit routing-instances routing-instance-name] hierarchy level). The interfaces in a virtual-switch routing instance (those specified by interface interface-name statements at the [edit routing-instances routing-instance-name] hierarchy level) are Layer 2 trunk interfaces. The VPLS pseudowires in a virtual-switch routing instance (which are created as a result of including the protocols vpls subhierarchy at the [edit routing-instances routing-instance-name] hierarchy level for the virtual-switch routing instance) are also trunk interfaces; that is, they belong to all bridge domains in the routing instance and participate in the passing of traffic within each bridge domain. On MX-series routers running JUNOS Release 9.2 and earlier, only VPLS routing instances (those configured with the instance-type vpls statement) support VPLS functionality. [Layer 2, VPNs]

High Availability

Unified ISSU support for additional hardware—Unified in-service software upgrade (ISSU) supports the following additional platforms, PICs, and FPCs:
- 1-port OC48c/STM16 ATM2 IQ PICs, which are supported on the M40e, M120, M320, and T-series routing platforms.
- T1600 Enhanced Scaling FPC4 on the T1600 routing node.
- TX Matrix platform. Unified ISSU is supported for the same protocols and hardware components as on T-series routing platforms.
- MX-series routers. You must also enable nonstop active bridging by including the nonstop-bridging statement at the [edit protocols layer2-control] hierarchy level (for more information about prerequisites, see the JUNOS High Availability Configuration Guide).
  
  Unified ISSU does not support the following features and protocols on MX-series routers:
  - Connectivity-fault management (CFM) for Ethernet interfaces, as defined by the IEEE 802.1ag OAM standard
  - Link-fault management (LFM) for Ethernet interfaces, as defined by the IEEE 802.3ah OAM standard
  - LACP
[High Availability]
Unified ISSU support for additional protocols—Unified ISSU now supports the following transport mechanisms and protocols:
- Layer 2 circuits.
- Layer 2 Control Protocol (L2CP). To enable ISSU support, you must include the delegate-processing statement at the [edit routing-options ppm] hierarchy level, which enables distributed periodic packet management (PPM) on the Packet Forwarding Engine instead of the Routing Engine. PPM is used to send and receive the hello bridge protocol data units (BPDUs) that maintain L2CP adjacencies. Performing PPM on the Packet Forwarding Engine means that adjacencies are maintained as a new Routing Engine assumes mastership during ISSU, which eliminates disruption in the Layer 2 control plane and minimizes disruption in the Layer 2 data plane.
- LDP-based VPLS.
- Protocol Independent Multicast (PIM), for IPv4 traffic only.
[High Availability]
NSR support for additional protocols—Nonstop active routing (NSR) now supports the following additional transport mechanisms and protocols:
- Layer 2 circuits
- LDP-based VPLS
To configure NSR for these protocols, include the same statements in the configuration as for other protocols: the nonstop-routing statement at the [edit routing-options] hierarchy level and the graceful-restart statement at the [edit chassis redundancy] hierarchy level. [High Availability, Multicast]

NSR support for PIM for IPv4—NSR now supports PIM for IPv4 traffic. State information replicated on the backup Routing Engine includes information about neighbor relationships, join and prune events, rendezvous point (RP) sets, synchronization between routes and next hops, and the forwarding state between the two Routing Engines.

To configure NSR for PIM, include the same statements in the configuration as for other protocols: the nonstop-routing statement at the [edit routing-options] hierarchy level and the graceful-restart statement at the [edit chassis redundancy] hierarchy level. To trace PIM NSR events, include the flag nsr-synchronization statement at the [edit protocols pim traceoptions] hierarchy level.

In JUNOS Release 9.3, NSR support varies for different PIM features. The features fall into the three categories described in the following list: supported features, unsupported features, and incompatible features.

PIM features supported with NSR in JUNOS Release 9.3

Auto-RP
Bidirectional Forwarding Detection (BFD)
Bootstrap router
Dense mode
Sparse mode (except for some subordinate features mentioned in the following list of unsupported features)
Source-specific multicast (SSM)
Static RPs

PIM features not supported with NSR in JUNOS Release 9.3

You can configure the following PIM features on a router along with NSR, but during Routing Engine switchover and other outages, their state information is not preserved and traffic loss is to be expected.

Internet Group Management Protocol (IGMP) exclude mode
IGMP snooping
PIM for IPv6 and related features such as embedded RP and MLD
Policy features such as bootstrap router export and import policies, flow maps, import join policy, neighbor policy, reverse path forwarding (RPF) check policies, RP/DR register message filtering, and scope policy
Upstream assert synchronization

PIM features incompatible with NSR in JUNOS Release 9.3

NSR does not support the following features in JUNOS Release 9.3, and you cannot configure them on a router enabled for PIM NSR. The commit operation fails if the configuration includes both NSR and one or more of these features:

Anycast RP
Draft-Rosen multicast VPNs (MVPNs)
Local RP
Next-generation MVPNs with PIM provider tunnels
PIM join load balancing

JUNOS Release 9.3 introduces a configuration statement that disables NSR for PIM only, so that you can activate incompatible PIM features and continue to use NSR for the other protocols on the router. Before activating an incompatible PIM feature, include the new nonstop-routing disable statement at the [edit protocols pim] hierarchy level. Note that in this case NSR is disabled for all PIM features, not only incompatible features.

Note: If both an incompatible PIM feature and NSR are enabled on a router running JUNOS Release 9.2 or earlier, you must perform additional steps when upgrading the router to JUNOS Release 9.3. For more information, see Upgrading to Release 9.3 on a Router Enabled for Both PIM and NSR.

[High Availability, Multicast]

Class of Service

Extended PIC support for per-unit schedulers—Enables you to configure per-unit schedulers for T1/NxDS0 interfaces on the channelized DS3 IQ PIC, and for DS0 interfaces on the channelized STM1 IQ PIC (that is, you can include the per-unit-scheduler statement at the [edit interfaces interface-name] hierarchy level). When per-unit schedulers are configured, you can define dedicated schedulers for the logical interfaces on the PIC by including the scheduler-map statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level. [CoS]
CoS functionality on the Enhanced IQ PIC (M40e, M120, M320, and T-series routing platforms)—The Enhanced IQ PIC provides the following class-of-service (CoS) features:
- Transmission rate limiting, to prevent low-latency traffic (such as voice) on a queue configured for strict-high priority from starving queues that are serving lower priority packets. Include the rate-limit option to the transmit-rate statement at the [edit class-of-service schedulers scheduler-name] hierarchy level. Although intended primarily for queues that serve low-latency traffic, you can rate limit any queue.
- Substitution of user-defined values for the type-of-service (ToS) bit in incoming packets. To define the values to substitute, include the translation-table statement at the [edit class-of-service] hierarchy level. To apply the values to a logical interface, include the translation-table statement at the [edit class-of-service interfaces interface-name unit logical-unit-number] hierarchy level. You can translate IPv4 ToS values to IPv4 values (DiffServ code point [DSCP] or INET), IPv6 to IPv6 (DSCP), or MPLS to MPLS (EXP bits).
- Hierarchical scheduling based on configuring a committed information rate (CIR) and peak information rate (PIR) for physical interfaces combined with other parameters for logical interfaces. For example, you can configure the CIR and PIR for a physical interface (internal node) by including the guaranteed-rate and shaping-rate statements respectively, and configure a packet loss priority and guaranteed rate (transmit rate) for the logical interface (leaf node).
[CoS]
Ingress BA classification on the Enhanced IQ PIC (M120 routers)—The Enhanced IQ PIC for the M120 router supports ingress behavior aggregate (BA) classification for DSCP, IP precedence, or EXP bits. The BA classifier sets the forwarding class and PLP bits for the packet and this information is used to forward the packet. [CoS]
Support for CoS service updates in dynamic profiles (MX-series routers)—Enables subscribers to merge services when changing services, instead of replacing services as in previous releases. To enable subscribers to change services by merging, include the new variables statement at the [edit dynamic-profiles profile-name] hierarchy level. To configure the CoS features for the dynamic profile, include statements at the [edit dynamic-profiles profile-name class-of-service] hierarchy level; the valid statements include delay-buffer-rate, guaranteed-rate, scheduler-map, and shaping-rate. The values of the variables are applied to a subscriber’s configuration when authenticating using RADIUS. [Subscriber Access]
Excess bandwidth and rate limiting on MultiServices PICs (M-series and T-series routing platforms)—On all versions (100, 300, and 500) of the MultiServices PIC, you can now limit the transmission rate for a link services IQ ( lsq-) logical interface in the same way as on other types of queuing PICs. As with the other PICs, the strict-high queue (often assigned to voice traffic) can starve lower priority queues. We recommend that you rate limit the strict-high queue to prevent this, by including the rate-limit option for the transmit-rate statement at the [edit class-of-service schedulers scheduler-name] hierarchy level.
You can also assign a percentage of excess bandwidth to logical interfaces on MultiServices PICs as on other PIC types. Include the excess-rate statement at the [edit class-of-service schedulers scheduler-name] hierarchy level.

Both the transmit-rate and excess-rate statements apply to egress traffic and per-unit schedulers only. Hierarchical and shared schedulers are not supported. To apply these features to an interface, you must also associate the scheduler with a scheduler map and apply the map to the interface configuration at the [edit class-of-service interfaces interface-name] hierarchy level. [CoS]
Ingress DSCP bits for multicast traffic over Layer 3 VPNs (M120, M320, MX-series, and T-series routing platforms)—Enables you to configure ToS rewrite rules that an ingress provider edge (PE) router applies to the DSCP bits of GRE packets as part of the implementation of the service provider’s overall class-of-service policy. Define the rule by including the rewrite-rules statement at the [edit class-of-service] hierarchy level, and apply the rule to the interface by including the rewrite-rules statement at the [edit class-of-service interfaces interface-name] hierarchy level. The rewrite rules are applied to all unicast packets and multicast groups.
Restrictions on this type of rewrite rule include the following:
- You cannot define different rewrite rules for different multicast groups.
- IPv6 multicast is not supported, so you cannot define a rewrite rule for DSCPv6 bits.
- You cannot use rewrite rules of this type to perform EXP marking.
[CoS]
BA classification for VPLS based on IEEE 802.1p bits (MX-series, M120, and M320 routers)—Enables you to configure BA classifiers based on IEEE 802.1p bits. Include the ieee-802.1 ieee-classifier-name encapsulated vlan-tag (inner | outer) statement at the [edit class-of-service routing-instances routing-instance-name classifiers] hierarchy level. Specify the inner option to base the BA classification on the inner VLAN tag from the inner Ethernet header, or the outer option to base it on the outer VLAN tag from the inner Ethernet header. BA classification based on the outer Ethernet header bits is not supported. [CoS]

JUNOS XML API and Scripting

Sequential RPCs in automation scripts—You can now execute sequential remote procedure calls (RPCs) within an automation script. [Automation]

New JUNOS XML API operational request tag elements—Table 2 lists the JUNOS Extensible Markup Language (XML) operational request tag elements that are new in JUNOS Release 9.3, along with the corresponding CLI command and response tag element for each one.

Table 2: JUNOS XML Tag Elements and CLI Command Equivalents New in JUNOS Release 9.3

Request Tag Element	CLI Command	Response Tag Element
<clear-binding-all>	clear mobile-ip binding all	None
<clear-binding-ip>	clear mobile-ip binding ip-address	None
<clear-binding-nai>	clear mobile-ip binding nai	None
<clear-database-replication -statistics-information>	clear database-replication statistics	None
<clear-dot1x-interface-session>	clear dot1x interface	<dot1x-interface-session>
<clear-dot1x-mac-session>	clear dot1x mac-address	<dot1x-mac-session>
<clear-service-pgcp-statistics>	clear services pgcp statistics	<service-pgcp-statistics-drain-information>
<clear-visitor-all>	clear mobile-ip visitor all	None
<clear-visitor-ip>	clear mobile-ip visitor ip-address	None
<clear-visitor-nai>	clear mobile-ip visitor nai	None
<get-cos-translation-table-information>	show class-of-service forwarding-table translation-table	<cos-translation-table-information>
<get-cos-translation-table-map-information>	show class-of-service translation-table	<cos-translation-table-map-information>
<get-cos-translation-table -mapping-information>	show class-of-service forwarding-table translation-table mapping	<cos-translation-table-mapping-information>
<get-database-replication -statistics-information>	show database-replication statistics	<database-replication-statistics-information>
<get-database-replication -summary-information>	show database-replication summary	<database-replication-summary-information>
<get-dot1x-authentication-failed-users>	show dot1x authentication-failed-users	<dot1x-authentication-failed-users>
<get-dot1x-interface-information>	show dot1x interface	<dot1x-interface-information>
<get-dot1x-interface-mac-addresses>	show dot1x static-mac-address interface	<dot1x-interface-mac-addresses>
<get-dot1x-static-mac-addresess>	show dot1x static-mac-address	<dot1x-static-mac-addresses>
<get-environment-psu-information>	show chassis environment psu	<environment-component-information>
<get-environment-psu-information>	show chassis environment psu	<environment-component-information>
<get-ioc-npc-connectivity-information>	show chassis ioc-npc-connectivity	<ioc-npc-connectivity>
<get-ip-mip-binding-information>	show mobile-ip home-agent binding ip-address	<mip-binding-information>
<get-mip-binding-information>	show mobile-ip home-agent binding	<mip-binding-information>
<get-mip-ha-overview-information>	show mobile-ip home-agent overview	<mip-ha-overview-information>
<get-mip-ha-traffic-information>	show mobile-ip home-agent traffic	<mip-home-agent-traffic-information>
<get-mip-ha-virtual-network-information>	show mobile-ip home-agent virtual-network	<mip-ha-virtual-network-information>
<get-nai-mip-binding-information>	show mobile-ip home-agent binding nai	<mip-binding-information>
<get-subscribers>	show subscribers	<subscriber>
<get-summary-mip-binding-information>	show mobile-ip home-agent binding summary	<mip-binding-information>
<get-system-resource-cleanup- processes-information>	show system resource-cleanup processes	<system-resource-cleanup-processes-information>
<get-vcpu-information>	show chassis vcpu	<vcpu-information>
<set-logical-router>	set cli logical-system	None

[JUNOS XML API Operational Reference]

System Logging

New and deprecated system log tags—The following sets of system log messages are new in this release:
- JCS—Messages generated by the Juniper Control System (JCS) process, which provides the user interface to the control processes for the management modules and switch modules in the JCS 1200 platform.
- LLDPD—Messages generated by the Link Layer Discovery Protocol (LLDP) process, which is responsible for discovering devices on a network and their capabilities.
- SAVAL—Messages generated by the MAC SA validation process, which verifies the match between the source IP address and MAC address in incoming packets, to prevent spoofing on Ethernet-based interfaces.
- VCCPD—Messages generated by the Virtual Chassis Control Protocol (VCCP) process.
The following system log messages are new in this release:
- CHASSISD_PSU_ERROR
- CHASSISD_PSU_FAN_FAIL
- CHASSISD_PSU_INPUT_BAD
- CHASSISD_PSU_OVERLOAD
- CHASSISD_PSU_TEMPERATURE
- CHASSISD_PSU_VOLTAGE
- CHASSISD_SNMP_TRAP1
- DCD_PARSE_ERROR_SCHEDULER_LIMIT
- L2ALD_MAC_LIMIT_REACHED_IFBD
- LIBMSPRPC_CLIENT_KCOM_NO_IF
- SPD_GEN_NUM_FAIL
The following system log messages are no longer documented, either because they indicate internal software errors that are not caused by configuration problems or because they are no longer generated. If these messages appear in your log, contact your technical support representative for assistance:
- KMD_CFG_NO_TRACE_FILE
- KMD_VPN_BIND_TUNNEL_IF
- PFE_FW_UNSUPPORTED
[System Log]