Changes in Default Behavior and Syntax in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers
Class of Service
- Forwarding class to queue number maps not supported
on Multiservices link services intelligent queuing (LSQ) interfaces—If you configure a forwarding class map associating a forwarding
class with a queue number, these maps are not supported on Multiservices
link services intelligent queuing (lsq-) interfaces.
[Class of Service]
Forwarding and Sampling
- Enhancement to the show firewall command—The show firewall command now supports a terse option that enables you to display only the names of firewall filters.
This option displays no other information about the firewall filters
configured on your system. Use the show firewall terse command
to verify that all the correct filters are installed.
[Routing Protocols and Policies Command Reference]
Interfaces and Chassis
- Disabling MAC address learning of neighbors through
ARP or neighbor discovery for IPv4 and IPv6 traffic for logical interfaces—The JUNOS Software provides the no-neighbor-learn configuration statement at the [edit interfaces interface-name unit interface-unit-number family inet] and [edit interfaces interface-name unit interface-unit-number family inet6] hierarchy levels.
To disable ARP address learning for IPv4 traffic for a logical interface, include the no-neighbor-learn statement at the [edit interfaces interface-name unit interface-unit-number family inet] hierarchy level:
[edit interfaces interface-name unit interface-unit-number family inet]no-neighbor-learn;To disable neighbor discovery for IPv6 traffic for a logical interface, include the no-neighbor-learn statement at the [edit interface interface-name unit logical-unit-number family inet6] hierarchy level:
[edit interfaces interface-name unit interface-unit-number family inet6]no-neighbor-learn;[System Basics]
- Logical and physical Ethernet interface bandwidth—If you configure a bandwidth on a logical Ethernet interface
greater than the bandwidth configured for the corresponding physical
Ethernet interface, the commit fails. The bandwidth of the logical
interface should always be less than the bandwidth of the physical
interface. If you do not configure a bandwidth for the logical interface,
it is automatically set to the bandwidth configured for the physical
interface.
[Network Interfaces]
- Support for line-rate mode on 10-port 10-Gigabit
Oversubscribed Ethernet (OSE) PIC (T640, T1600, TX Matrix Plus platforms)— Enables you to configure the T640, T1600, and TX Matrix
Plus routers to operate the 10-port 10-Gigabit OSE PIC in line-rate
mode, in which the OSE PIC disables oversubscription and operates
in line-rate mode. By default, the 10-port 10-Gigabit OSE PIC operates
in 2:1 oversubscription mode.
[System Basics]
- New CoS information field added
to the show interfaces extensive command output—The output of the show interfaces extensive command
now displays the class-of-service queue allocation information of
the physical interfaces (intelligent queueing PICs such as IQ2 and
so on) under the new class-of-service information category. In the
previous releases, the class-of-service queue allocation information
for physical interfaces was listed within the Packet Forwarding
Engine configuration category:
host@user# show interfaces extensive ge-7/1/3Packet Forwarding Engine configuration: Destination slot: 7 CoS information: Direction : Output CoS transmit queue Bandwidth Buffer Priority Limit % bps % usec 0 best-effort 95 950000000 95 0 low none 3 network-control 5 50000000 5 0 low none Direction : Input CoS transmit queue Bandwidth Buffer Priority Limit % bps % usec 0 best-effort 95 950000000 95 0 low none 3 network-control 5 50000000 5 0 low none[Interfaces Command Reference]
- Restriction on compatibility-mode adtran and verilink—On 2-port and 4-port channelized DS3 (T3) IQ interfaces, you
cannot configure compatibility-mode adtran, or verilink at the [edit interfaces interface-name t3-options] hierarchy level. If configured, the default mode
is applied on both the interfaces, that is, no subrating.
[Network Interfaces]
- Support for internal clocking mode on OSE PICs—The 10-port 10-Gigabit Oversubscribed Ethernet (OSE) PIC supports
only internal clocking mode on its ports.
[Network Interfaces]
- Commit-time warning messages at the [edit interfaces] hierarchy level are now system logged—CLI commit-time warnings displayed for configuration at the [edit interfaces] hierarchy level have been removed and are now logged as system log messages. This change is applicable to JUNOS Release 10.1R1 and later, 10.0R2, and 9.3R4. [CLI User Guide]
- Invalid count of queues—The
PD-5-10XGE-SFPP PICs in T Series routers do not display ingress control
queue statistics as output from the show interfaces queue xe-fpc/pic/port
forwarding-class command. However, you can use the following
commands to display the ingress control queue statistics:
- show interfaces queue both-ingress-egress xe-fpc/pic/port
- show interfaces queue xe-fpc/pic/port
- show interfaces queue xe-fpc/pic/port ingress
[Network Interfaces]
- Support for configuration of a range of interfaces
through the interface-range statement—Enables
you to group a range of identical interfaces and apply a common configuration
for the interfaces using a reduced number of configuration statements.
To configure an interface-range group, include the interface-range statement and substatements at the [edit interfaces] hierarchy
level. To view an interface range group in expanded configuration,
use the show | display inheritance command.
[Network Interfaces, Interfaces Command Reference]
- Enhancement to the show chassis fabric fpcs command—In JUNOS Release 10.1 and later,
the show chassis fabric fpcs command issued on a T640 or
T1600 router displays destination errors in addition to link errors.
The command output displays a list of Packet Forwarding Engines that
have destination errors, for those SIBs that are in the Check state. This enhancement is also applicable to JUNOS Release 9.6
and 10.0. The following sample shows the enhanced output for this
command:
user@host> show chassis fabric fpcsFabric management FPC state: FPC #3 PFE #1 SIB #2 Plane enabled SIB #3 Link error Destination error on PFEs 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 SIB #4 Destination error on PFEs 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21[System Basics Command Reference]
- Modification to the output of the show interfaces
extensive command output—For IQ2E interfaces,
the show interfaces extensive command output no longer displays
the schedulers field, because there is no static scheduler
partitioning of schedulers among different ports in IQ2E.
[Interfaces Command Reference]
- Enhancement to the show chassis sibs command—The show chassis sibs command now displays destination
errors for SIBS in the Check state. In JUNOS Release 10.1
and later and JUNOS Release 9.6 and 10.0, the command displays the
number of destination errors for SIBS in the Check state:
user@host> show chassis sibsSlot State Uptime 0 Empty 1 Empty 2 Check (21 destination errors) 1 day, 1 hour, 32 minutes, 55 seconds 3 Check (0 destination errors) 1 day, 1 hour, 32 minutes, 45 seconds 4 Empty use "show chassis fabric fpcs" to determine which PFEs have destination errors
However, for JUNOS Release 9.3 and 9.5, the command only displays the message destination errors or no destination errors for a SIB that is in the Check state, but does not display the number of destination errors:
user@host> show chassis sibsSlot State Uptime 0 Empty 1 Empty 2 Check (destination errors) 1 day, 1 hour, 32 minutes, 55 seconds 3 Check (no destination errors) 1 day, 1 hour, 32 minutes, 45 seconds 4 Empty use "show chassis fabric fpcs" for more details
In addition, the command also displays a message to use the show chassis fabric fpcs command for more information about the destination errors.
If there are no SIBs in the Check state, there is no change in the output of this command.
[System Basics Command Reference]
Layer 2 Ethernet Services
- Modification to the output of the show dhcp (relay
or server) binding commands—The output of the show dhcp server binding summary command, the show dhcp
relay binding summary command, and the show dhcpv6 server
binding command has been modified to include the number of clients
in the init state and the requesting state.
[Subscriber Access]
MPLS Applications
- MPLS statistics
file now optional—The file statement
configured at the [edit protocols mpls statistics] hierarchy
level is now optional. You still must configure the MPLS statistics
statement to collect LSP statistics for the MPLS MIBs. Rather than
accessing the LSP statistics in the MPLS statistics file, you can
view the statistics using SNMP instead. This change helps to reduce
disk space usage on the routing engine, especially on routers on which
numerous LSPs have been configured.
[MPLS]
- NSR tracing flags for MPLS—You
can now configure MPLS tracing flags for nonstop active routing (NSR)
synchronization events. This enables you to track the progress of
NSR synchronization between Routing Engines and record these operations
to a log file. To configure, include the flag nsr-synchronization or flag nsr-synchronization-detail statement at the [edit protocols mpls traceoptions] hierarchy level. The two
statements are not mutually exclusive; you can track the events at
a high level and in detail.
[High Availability, MPLS, Routing Protocols]
Multiplay
- Border gateway function (BGF) improved efficiency
and scalability through use of service interface pools—You can now use service interface pools to improve the maintainability
and scalability of your service set configurations. When your service
sets handle VPN traffic, you must specify a service
interface pool for the next next-hop-service for the service sets.
The interfaces that are members of the pool can serve as either inside
or outside interfaces.
You should also specify service interface pools as the next-hop service for service sets that do not currently handle VPN traffic. You gain the immediate benefit of more efficient resource utilization and you can add VPNs to the service set in the future without reconfiguring your service sets.
[Multiplay Solutions]
Routing Policy and Firewall Filters
- The ipsec-sa sa-name firewall
filter action is no longer supported on the MX Series routers. To
configure one or more actions for a firewall filter, include the actions statement at the [edit firewall
family family-name filter filter-name term term-name then] hierarchy level.
[Policy]
- Enhanced match-conditions support for VPLS and
bridge firewall filters (MX Series routers and routers with Enhanced
IQ2 [IQ2E] PICs only)—The protocol families vpls and bridge now support the interface-set match condition for firewall filters. To configure, include the interface-set interface-set-name statement
at the [edit firewall family bridge filter filter-name term term-name from] or the [edit
firewall family vpls filter filter-name term term-name from] hierarchy level. The protocol family bridge is supported only on MX Series routers.
An interface set is a set of logical interfaces used to configure hierarchical class-of- service schedulers. Previously only the following protocol families supported the interface-set match condition: ipv4, ipv6, any, and mpls.
[Policy]
Routing Protocols
- OSPF sham link—An OSPF sham
link is now installed in the routing table as a hidden route. Previously,
an OSPF sham link was not installed in the routing table. In addition,
a BGP route is no longer exported to OSPF if a corresponding OSPF
sham link is available. To configure a sham link, include the sham-link local ip-address statement at
the [edit routing-instances routing-instance-name protocols ospf] hierarchy level.
[Routing Protocols]
- Removal of BGP warning message—If
a BGP group is created without any defined peers, the warning message
no longer appears when the configuration is committed.
[Routing Protocols]
- Increase in limit to external paths accepted for
BGP route target filtering—You can now specify
for BGP to accept up to 256 external paths for route target filtering.
Previously, the maximum number that you could configure was 16. The
default value remains one (1). To specify the maximum number of external
paths for BGP to accept for route target filtering, include the external-paths number statement at the [edit protocols bgp family route-target] hierarchy level. This
statement is also supported for BGP groups and neighbors.
[Routing Protocols]
- Support for having the algorithm that determines
the single best path evaluate AS numbers in AS paths for VPN routes—By default, the third step of the algorithm that determines
the active route evaluates the length of the AS path but not the contents
of the AS path. In some VPN scenarios with BGP multiple path routes,
it can also be useful to compare the AS numbers of the AS paths and
to have the algorithm select the route whose AS numbers match. Include
the as-path-compare statement at the [edit routing-instances
routing-instance-name routing-options multipath] hierarchy level.
[Routing Protocols]
Services Applications
- Option to view APPID counters—Use
the option under show services application-identification counter to view the APPID counters for the specified interface.
[System Basics and Services Command Reference]
- Session offloading on Multiservices PICs—To enable session offloading on a per-PIC basis for Multiservices
PICs, include the session-offload statement at the [edit
chassis fpc] hierarchy level.
[System Basics]
- Option to clear the “do not fragment”
bit—To clear the “do not fragment”
bit for IPsec with dynamic endpoints, include the clear-dont-fragment-bit statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level.
[Services Interfaces]
- Option to clear tunnel MTU—To
clear the tunnel MTU, include the tunnel-mtu statement at
the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level.
[Services Interfaces]
- M120 router performance with IDP—For
M120 routers, the performance number is 4500 connections per second
when IDP is enabled.
[Services Interfaces]
- Enhancement to the output of the show services
accounting commands—The output for the show services accounting usage, show services accounting
status, show services accounting memory, and show
services accounting errors operational mode commands has been
updated to include new fields for use in querying service PICs.
[System Basics and Services Command Reference]
- Default idle timeout value for UDP- and TCP-based
applications—Upon identification by AppID, the
default idle timeout value is set to 30 seconds for UDP-based applications
and 1 hour for TCP-based applications. These settings can be overridden
by including the idle timeout statement at the [edit
services application-identification application application] hierarchy level.
[Services Interfaces]
- New statement to bypass traffic on exceeding flow
limit—If the flow in the service-set crosses the
maximum limit set by the max-flow statement, the bypass-traffic-on-exceeding-flow-limits
allows the packets to bypass without creating a new session. Following
are the required privilege levels:
- interface—To view the statement in the configuration
- interface-control—To add the statement to the configuration
[Services Interfaces]
- Diffie-Hellman group5 added to group1 and group2—The group5 designation specifies that IKE should use the 1536-bit
Diffie-Hellman prime modulus group when performing the new Diffie-Hellman
exchange. To configure the Diffie-Hellman group for an IKE proposal,
include the dh-group statement at the [edit services
ipsec-vpn ike proposal proposal-name] hierarchy
level:[edit services ipsec-vpn ike proposal proposal-name]dh-group (group1 | group2| group5);
[Services Interfaces]
- Permanent limitation for session-timeout on APPID—If session-timeout is configured for an APPID application,
a session for that application will be cleared once the session-timeout
expires. Once the same session is re-created as a new session, it
will not be identified by APPID.
[Services Interfaces]
- Integrated Multi-Services Gateway (IMSG)—The clear services border-signaling-gateway gateway-name statistics command no longer clears
the active calls counter.
[System Basics and Services Command Reference]
- New configuration statements for assigning policies—The following configuration statements at the [edit services
border-signaling-gateway gateway-name service-point service-point-name service-policies] hierarchy level
have been deprecated and replaced by new statements:
- new-call-usage-policies [policy-and-policy-set-names]
- new-transaction-policies [policy-and-policy-set-names]
Each statement applied policies to calls or transactions entering at the service point. Each is replaced by statements that explicitly apply policies to transactions or policies entering the service point or exiting from the service point. The new statements are:
- new-call-usage-input-policies [policy-and-policy-set-names]
- new-call-usage-output-policies [policy-and-policy-set-names]
- new-transaction-input-policies [policy-and-policy-set-names]
- new-transaction-output-policies [policy-and-policy-set-names]
[Services Interfaces, System Basics and Services Command Reference]
- Requirement for client-to-servicer and server-to-client
signatures—For certain applications that have
signatures for both client-to-server and server-to-client directions,
APPID (DAA) needs to see the data packets in both directions on the
same session to finish the identification process. For example, for
SIP proxy calls, the server may not send the response on the same
session (different destination port) and that session will not be
identified as application junos:sip.
[Services Interfaces]
- Integrated Multi-Services Gateway (IMSG) maximum
number of policies and policy-related entities per Border Signaling
Gateway (BSG)—The following table shows the maximum
number of policies and related entities.
Entity
Maximum
Policies (total of new call usage and new transaction policies) per BSG
750
New call usage policies per BSG
500
New transaction policies per BSG
500
Policies per service point
10
Service points per BSG
100
Terms per policy
20
Terms per BSG
10,000
Total of AND and OR operators in a policy term
4
[Session Border Control Solutions]
Subscriber Access Management
- Enabling and disabling DHCP snooping support—You can now explicitly enable or disable DHCP snooping support
on the router. If you disable DHCP snooping support, the router drops
snooped DHCP discover and request messages.
To enable DHCP snooping support, include the allow-snooped-clients statement at the [edit forwarding-options dhcp-relay overrides] hierarchy level. To disable DHCP snooping support, include the no-allow-snooped-clients statement at the [edit forwarding-options dhcp-relay overrides] hierarchy level. Both statements are also supported at the named group level and per-interface level.
In JUNOS Release 10.0 and earlier, DHCP snooping is enabled by default. In release 10.1 and later, DHCP snooping is disabled by default.
[Subscriber Access]
RADIUS interim accounting—When subscriber management receives the RADIUS Acct-Interim-Interval attribute (attribute 85), RADIUS interim accounting is performed based on the value in the attribute. The router uses the following guidelines:
- Attribute value is within the acceptable range (10 to 1440 minutes)—Accounting is updated at the specified interval.
- Attribute value of 0—No RADIUS accounting is performed.
- Attribute value is less than the minimum acceptable value (10 minutes)—Accounting is updated at the minimum interval.
- Attribute value is greater than the maximum acceptable value (1440 minutes)—Accounting is updated at the maximum interval.
[Subscriber Access]
User Interface and Configuration
- Restriction on the usage of the annotate command in the configuration hierarchy—The JUNOS
Software supports annotation of the configuration using the annotate command up to the last level in the configuration hierarchy. However,
annotation of the configuration options or statements within the last
level in the hierarchy is not supported. For example, in the following
sample configuration hierarchy, annotation is supported up to the level 1 parent hierarchy, but is not supported for the metric child statement:[edit protocols]isis {interface ge-0/0/0.0 {level 1 metric 10;}}}
[CLI User Guide]
- Support for accounting is restricted to events
and operations on a master Routing Engine—Starting
with JUNOS Release 9.3, accounting for backup Routing Engine events
or operations is not supported on accounting servers such as TACACS+
or RADIUS. Accounting is only supported for events or operations on
a master Routing Engine.
[CLI User Guide]
- Options added to the show arp command—The vpn and logical-system options have
been added to the show arp command.
[System Basics Command Reference]
- Change in range of the saved-core-files configuration statement—The range of the saved-core-files configuration statement at the [edit system] hierarchy level has been revised from 1 through 64, to 1 through 10.
[System Basics]
VPNs
- Mirroring IRB packets as Layer 2 packets (MX Series
router)—If you associate an IRB with the bridge
domain (or VPLS routing instance), and also configure within the bridge
domain (or VPLS routing instance) a forwarding table filter with the port-mirror or port-mirror-instance action, then the
IRB packet is mirrored as a Layer 2 packet. You can disable this behavior
by configuring the no-irb-layer-2-copy statement in the bridge
domain (or VPLS routing instance).
[MX Series Layer 2 Configuration]
- Layer 2 circuits, call admission control (CAC),
and bypass LSPs—You can now configure CAC on Layer
2 circuit-based LSPs with bandwidth constraints and also enable link
and node protection. However, if the primary LSP fails, CAC might
not be applied to the bypass LSP, meaning that the bypass LSP might
not meet the bandwidth constraint for the Layer 2 circuit. To minimize
the risk of losing traffic, the Layer 2 circuit continues to use
the non-CAC bypass LSP while an attempt is made to establish a new
Layer 2 circuit route over an LSP that does support CAC. Previously,
the Layer 2 circuit route was deleted if the bypass LSP did not have
sufficient bandwidth.
[VPNs]
- Service VLANs and the use of vlan-id all statement in a VPLS routing instance—If you
configure the vlan-id all statement in a VPLS routing instance,
we recommend using the input-vlan-map pop and output-vlan-map
push statements on the logical interface to pop the service VLAN
ID on input and push the service VLAN ID on output and in this way
limit the impact of doubly-tagged frames on scaling.
[MX Series Layer 2 Configuration]
- Layer 2.5 VPNs support ISO family and MPLS family
over TCC (MX Series routers)—JUNOS Release 8.3
introduced support for M320 and T Series routers. JUNOS Release 10.1
extends support to MX Series routers.
Interfaces supporting TCC (Ethernet, extended VLANs, PPP, HDLC, ATM, and Frame Relay) support ISO traffic and MPLS traffic on Layer 2.5 VPNs. Previously, Layer 2.5 VPNs configured on MX Series routers supported only inet traffic. For a protocol to be supported on a Layer 2.5 VPN, you must configure both ends of the VPN with the protocol configuration. IPv6 is not supported.
To enable ISO or MPLS traffic over TCC, include the mpls or iso statement at the [edit interfaces interface-name unit logical-unit-number family tcc protocol] hierarchy level. To display which protocol is supported for an interface, issue the show interfaces interface-name extensive operational mode command. The protocol is displayed in the Flags field.
To enable ISO over TCC in cases in which the Ethernet interface is on a customer-edge (CE) router, include the point-to-point statement at the [edit protocols isis interface interface-name] hierarchy level on the CE router. When you include this statement, the IS-IS protocol treats the Ethernet interface as point to point, even though the actual interface is a LAN interface.
The M Series routing platforms continue to support only inet traffic for Layer 2.5 VPNs.
[Network Interfaces, Translational Cross-Connect and Layer 2.5 VPNs Feature Guide, VPNs]
- New configuration statement for removing dynamically
learned MAC addresses from the MAC address database—Media
access control (MAC) flush processing removes MAC addresses from the
MAC address database that have been learned dynamically. With the
dynamically learned MAC addresses removed, MAC address convergence
requires less time to complete.
In this release, you enable MAC flush processing for the virtual private LAN service (VPLS) routing instance or for the mesh group under a VPLS routing instance by using the mac-flush statement instead of the mac-tlv-receive and mac-tlv-send statements.
mac-flush [ explicit-mac-flush-message-options ];To clear dynamically learned MAC addresses globally across all devices participating in the routing instance, you can include the statement at the following hierarchy levels:
- [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls]
- [edit routing-instances routing-instance-name protocols vpls]
To clear the MAC addresses on the routers in a specific mesh group, you can include the statement at the following hierarchy levels:
- [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls mesh-group mesh-group-name]
- [edit routing-instances routing-instance-name protocols vpls mesh-group mesh-group-name]

Note: The mac-tlv-receive and mac-tlv-send statements were removed from Release 10.0 of the JUNOS Software and are no longer visible in the [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls] and [edit routing-instances routing-instance-name protocols vpls] hierarchy levels. Although the mac-tlv-receive and mac-tlv-send statements are recognized in the current release, they will be removed in a future release. We recommend that you update your configurations and use the mac-flush statement.
To also configure the router to send explicit MAC flush messages, you can include explicit-mac-flush-message-options with the statement:
- any-interface—(Optional) Send a MAC flush message when any customer-facing attachment circuit interface goes down.
- any-spoke—(Optional) Send a MAC FLUSH-FROM-ME
flush message to all provider edge (PE) routers in the core when one
of the spoke pseudowires between the multitenant unit switch and the
other network-facing provider edge (NPE) router goes down, causing
the multitenant unit switch to switch to the this NPE router.

Note: This option has a similar effect in a VPLS multihoming environment with multiple multitenant unit switches connected to NPE routers, where both multitenant unit switches have pseudowires that terminate in a mesh group with local-switching configured. If the any-spoke option is enabled, then both PE routers send MAC FLUSH-FROM-ME flush messages to all PEs in the core.
- propagate—(Optional) Propagate MAC flush to the core.
[VPNs]
Related Topics
- New Features in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers
- Issues in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers
- Errata and Changes in Documentation for JUNOS Software Release 10.1 for M Series, MX Series, and T Series Routers
- Upgrade and Downgrade Instructions for JUNOS Release 10.1 for M Series, MX Series, and T Series Routers