New and Changed Features
This section describes the new features and enhancements to existing features in the Junos OS main release and the maintenance releases for MX Series and T Series.
Release 16.2R2 New and Changed Features
Interfaces and Chassis
Enhancement to ambient-temperature statement (MX Series)—Starting in Junos OS Release 16.2R2 the default ambient temperature is set at 40° C on MX480, MX960, MX2010, and MX2020 3D Universal Edge Routers. You can override ambient temperature by resetting the temperature to 55° C or 25° C.
[edit] user@router# set chassis ambient-temperature ? Possible completions: 25C 25 degree celsius 40C 40 degree celsius 55C 55 degree celsius [edit]
When a router restarts, the system adjusts the power allocation or the provisioned power for the line cards on the basis of the configured ambient temperature. If there is not enough power, then a minor chassis alarm is raised. However, the chassis continues to run with the configured ambient temperature. You can configure a new higher ambient temperature only after you make more power available by adding new power supply modules or by taking a few line cards offline. By using the provisioned power that is saved by configuring a lower ambient temperature, you can bring more hardware components online.
Enhancement to policer configuration—Starting in Junos OS Release 16.2R2, you can configure the MPC to take a value from 0 through 5 for the policer tick byte by using the policer-limit statement at the [edit chassis] hierarchy level. If this statement is not configured, the policer tick byte can take values up to 7, which is the default behavior. You can use the set chassis policer-limit command to enable this feature.
You must restart the MPC or the router for the changes to take effect.
Subscriber Management and Services
LAC support for IPv6 address family and firewalls (MX Series)—Starting in Junos OS Release 16.2R2, you can configure the LAC to create the IPv6 address family (inet6) when establishing a tunnel for subscribers. By default, the LAC requires only family inet to enable forwarding into an IP tunnel. It can apply IPv4 firewall filters to the session. Even when family inet6 is included in the dynamic profile, by default it is not created and IPv6 firewall filters cannot be applied.
Include the enable-ipv6-services-for-lac statement at the [edit system services l2tp] hierarchy level to allow the IPv6 family to be created and IPv6 filters to be applied.
Use the show services l2tp summary command to display the current state, Disabled or Enabled, in the IPv6 Services for LAC Sessions field.
Configurable grace period for unresponsive RADIUS servers (MX Series)—Starting in Junos OS Release 16.2R2, you can use the timeout-grace statement at the [edit access radius-options] hierarchy level to configure a grace period that determines when an unresponsive RADIUS authentication server is marked as down or unreachable. When the server fails to respond to any of the attempts made for an authentication request, it times out, the time is noted, and the grace period begins. If the server is unresponsive for subsequent authentication requests, the grace period is checked each time the server times out. When the check determines that the grace period has expired, the server is marked as down or unreachable.
You can configure the grace period from 0 through 30 seconds; the default is 10 seconds. Use a short grace period to declare servers unavailable sooner and direct requests to available servers. Use a long grace period to give unresponsive servers more opportunities to respond.
In earlier releases, the grace period was 10 seconds and was not configurable.
Support for excluding tunnel attributes from RADIUS Access-Request messages (MX Series)—Starting in Junos OS Release 16.2R2, you can use the exclude statement at the [edit access profile profile-name radius attribute] hierarchy level to exclude the following tunnel attributes from RADIUS Access-Request messages in addition to the previously supported Accounting-Start and Accounting-Stop messages:
acct-tunnel-connection—RADIUS attribute 68, Acct-Tunnel-Connection
tunnel-assignment-id—RADIUS attribute 82, Tunnel-Assignment-Id
tunnel-client-auth-id—RADIUS attribute 90, Tunnel-Client-Auth-Id
tunnel-client-endpoint—RADIUS attribute 66, Tunnel-Client-Endpoint
tunnel-medium-type—RADIUS attribute 65, Tunnel-Medium-Type
tunnel-server-auth-id—RADIUS attribute 91, Tunnel-Server-Auth-Id
tunnel-server-endpoint—RADIUS attribute 67, Tunnel-Server-Endpoint
tunnel-type—RADIUS attribute 64, Tunnel-Type
User Interface and Configuration
Support for configuring the ephemeral database using the NETCONF and Junos XML protocols (MX Series and T Series)—Starting in Junos OS Release 16.2R2, NETCONF and Junos XML protocol client applications can configure the ephemeral configuration database. The ephemeral database provides a fast programmatic interface that enables multiple clients to simultaneously load and commit configuration changes on a device running Junos OS and with significantly greater throughput than when committing data to the candidate configuration database. Junos OS provides a default instance and up to eight user-defined instances of the ephemeral configuration database. The device’s active configuration is a merged view of the committed configuration database and the configuration data in all instances of the ephemeral configuration database. Ephemeral configuration data is volatile and is deleted upon rebooting the device.
Release 16.2R1 New and Changed Features
Authentication, Authorization and Accounting
Hardened shared secrets in Junos OS (MX Series)—Starting in Junos OS Release 16.2, new CLI commands are introduced to configure a system master password and request to decrypt an encrypted secret, allowing for hardening of shared secrets such as preshared keys and RADIUS passwords.
Having a master password enables devices to encrypt passwords in such a way that only devices running Junos OS that have knowledge of the master password can decrypt the encrypted passwords. The following new CLI commands are available:
request system decrypt password
set system master-password
Class of Service
Support for ingress rate limiting (MX Series)—Beginning with Junos OS Release 16.2R1, on MPCs that support ingress queuing, you can perform rate limiting on incoming packets based on the forwarding class and packet loss priority defined for each packet at ingress. You can perform ingress rate limiting by applying an input traffic control profile (using the input-traffic-control-profile statement) or an input scheduler map (using the input-scheduler-map statement) to a physical or logical interface where the traffic control profile or scheduler map contains a rate-limited scheduler.
EVPNs
EVPN MAC pinning (MX Series)—Starting in Release 16.2, Junos OS enables MAC pinning for Ethernet VPN (EVPN), including customer edge (CE) interfaces and EVPN over MPLS core in both all-active mode and single-active mode.
A MAC address pinned over CE interfaces in EVPN is synchronized to remote EVPN PE devices by adding the Sticky bit (in accordance with RFC 7432, Section 7.7, MAC Mobility Extended Community). On a remote EVPN PE device, a MAC address received with Sticky bit enabled is pinned over the MPLS core. A pinned MAC address cannot be moved to a different interface. When a MAC address is pinned locally in a bridge domain, the address is synchronized to remote EVPN PE devices. The interface with the locally pinned MAC address discards traffic sent from any other interface that has the identical MAC address if it is learned locally in the bridge domain.
Distribution of VXLAN VNIDs using EVPN (MX Series)—Starting in Release 16.2, Junos OS enables Ethernet VPN (EVPN) with Virtual Extensible LAN (VXLAN) encapsulation to provide Layer 2 connectivity for endpoints within a virtual network that Contrail virtualization software creates. Endpoints in this scheme include virtual machines (VMs) connected to a virtual server, and nonvirtual bare-metal servers (BMSs) connected to a top-of-rack (ToR) platform. An MX Series router functions as a default gateway for nonvirtual BMSs for the traffic among the endpoints that belong to different virtual networks.
The virtual network uses two types of encapsulation:
MPLS-over-GRE is used for L3 routing between Contrail and MX platform.
EVPN with VXLAN encapsulation is used for L2 connectivity between VM and BMS within a VN.
An MX Series router supports all-active L3 gateways for redundancy and load balancing to ensure failure protection for the default gateway.
General Routing
Support for the combined operation of Synchronous Ethernet and Precision Time Protocol or hybrid mode (MX104)—A combined operation of Synchronous Ethernet and Precision Time Protocol (PTP), also known as hybrid mode, is supported on the MX104 routers. In hybrid mode, the Synchronous Ethernet equipment clock (EEC) derives the frequency from Synchronous Ethernet and the phase and time of day from PTP (also known as IEEE 1588v2) for time synchronization.
Synchronous Ethernet and PTP provide frequency and phase synchronization; however, the accuracy in the order of nanoseconds is difficult to achieve through either PTP or Synchronous Ethernet, and they do not support a large number of network hops. Hybrid mode resolves these issues by extending the number of network hops and also provides the clock synchronization accuracy in the order of tens of nanoseconds.
Note Hybrid mode is not supported on integrated routing and bridging (IRB) and aggregated Ethernet interfaces configured on MX104 routers.
High Availability and Resiliency
NSR support for EVPN (MX Series)—Starting in Release 16.2, Junos OS ensures minimal loss of traffic when a Routing Engine switchover occurs with nonstop active routing (NSR) and graceful Routing Engine switchover (GRES) enabled. The forwarding state of the Packet Forwarding Engine (PFE) remains intact during switchover. The signaling state on the primary Routing Engine and on the standby Routing Engine are built in parallel.
This feature is supported for EVPN over MPLS.
Note Expect a traffic loss pertaining to a topology change if the topology change occurs during a switchover.
PIM NSR support for VXLAN (MX Series)—Starting in Release 16.2, Junos OS enables Protocol Independent Multicast (PIM) nonstop routing (NSR) support for Virtual Extensible LANs (VXLANs).
The Layer 2 address learning process (l2ald) passes VXLAN parameters (vxlan multicast group addresses and vtep-interface-source) to the routing protocol process on the master Routing Engine. The routing protocol process forms PIM joins with the multicast routes through the pseudo-VXLAN interface.
Because the l2ald does not run on the backup Routing Engine, the PIM NSR mirroring mechanism provides the VXLAN configuration details to the backup Routing Engine. The routing protocol process matches the multicast routes on the backup Routing Engine with PIM states, which maintains the multicast routes in the Forwarding state.
Unified ISSU support (MX104)—Unified in-service software upgrade (ISSU) is supported on the MX104 router. Unified ISSU enables you to upgrade from an earlier Junos OS release to a later one with no disruption on the control plane and with minimal disruption of traffic. [See Unified ISSU Concepts]
MX Series Virtual Chassis ISSU support for MPC6E line cards (MX Series Virtual Chassis)—Starting in Junos OS Release 16.1, MPC6E line cards support ISSU in MX Series Virtual Chassis environments.
Interfaces and Chassis
Support for Synchronous Ethernet and Synchronization Status Messages on MIC-3D-4OC3OC12-1OC48 and MIC-3D-16CHE1-T1-CE (MX104, MX240, MX480, MX960)—Starting with Junos OS Release 16.2R1, Synchronous Ethernet and Synchronization Status Messages (SSMs) are supported on the MIC-3D-4OC3OC12-1OC48 and MIC-3D-16CHE1-T1-CE MICs. Synchronous Ethernet (ITU-T G.8261 and ITU-T G.8264) is a physical layer technology that enables you to deliver synchronization services. It supports sourcing and transfer of frequency for synchronization purposes for both wireless and wireline services. An SSM indicates the quality level of the transmitting synchronous Ethernet Equipment Clock (EEC).
You can configure Channelized T1 (ct1) interfaces as clock sources on MIC-3D-4OC3OC12-1OC48 and MIC-3D-16CHE1-T1-CE. To configure a clock source, you must specify the parameters that must be considered by the clock selection algorithm while selecting the best clock source. The parameters include the quality level value, the priority of the clock source, the request criteria, and the wait time to restore the interface signal to up state. To configure ct1 as a clock source, include the set source interfaces interface-name statement at the edit [chassis synchronization] hierarchy level.
Note To configure the ct1 interface as a clock source, ensure that the option-2 network option is configured.
You can configure a maximum of eight clock sources by using the set chassis synchronization source source-name command. If you attempt to configure more than eight sources, the configuration fails.
You can configure the ct1 interface to enable Ethernet Synchronization Message Channel (ESMC) packet transmission by using the set chassis synchronization esmc-transmit interfaces interface-name command.
IPv6
Forced IPv6 DNS server address insertion (MX Series)—Starting in Junos OS Release 16.2, MX Series devices can dynamically provision DHCPv6 lease times and DNSv6 Server IP addresses for DHCPv6 clients. The IP addresses and lease times are provided to DHCPv6 clients in DHCPv6 Advertisement and Reply messages without requiring a Solicit or Request message from a CPE device.
Layer 2 Features
Implicit maximum bandwidth for inline services for L2TP LNS (MX Series)—Starting in Junos OS Release 16.2, you are no longer required to explicitly specify a bandwidth for L2TP LNS tunnel traffic using inline services. When you do not specify a bandwidth, the maximum bandwidth supported on the PIC is automatically available for the inline services; inline services can use up to this maximum value. For example:
user@host# set chassis fpc 3 pic 0 inline-servicesuser@host# set chassis fpc 3 pic 1 inline-servicesuser@host> show interfaces si-3/0/0Physical interface: si-3/0/0, Enabled, Physical link is Up Interface index: 181, SNMP ifIndex: 561 Type: Adaptive-Services, Link-level type: Adaptive-Services, MTU: 9192, Speed: 100000mbps …
user@host> show interfaces si-3/1/0Physical interface: si-3/1/0, Enabled, Physical link is Up Interface index: 182, SNMP ifIndex: 562 Type: Adaptive-Services, Link-level type: Adaptive-Services, MTU: 9192, Speed: 100000mbps …
In earlier releases, you must specify a bandwidth to enable inline services by including the bandwidth statement with the inline-services statement.
Management
Starting in Junos OS Release 16.2R1, a new framework for API clients that uses the gRPC protocol is available for session management and device interaction. The gRPC protocol provides the request/response interface between the Junos extension toolkit (JET) service daemon (JSD) and the on-box or off-box application. The gRPC framework replaces the Apache Thrift framework that was used in previous releases. [See www.grpc.io.]
New Programmable Routing Protocol Process (prpd) Configuration Statements and Operational Commands (MX80, MX104, MX240, MX480, MX960, MX2010, MX2020, vMX Series)—Starting in Junos OS Release 16.2R1, new configuration statements are introduced to allow you to set purge a timeout for prpd API clients and to set traceoptions to log information regarding those clients. A new operational command is introduced to allow you to monitor prpd clients and information regarding their connections.
[See set routing-options programmable-rpd purge-timeout, set routing-options programmable-rpd traceoptions flag ]
Support for adding nonnative YANG RPCs to the Junos OS schema (MX Series and T Series)—Starting with Junos OS Release 16.1R3, you can load custom YANG RPCs on devices running Junos OS. Creating custom RPCs enables you to precisely define the input parameters and operations and the output fields and formatting for your specific operational tasks on those devices. The ability to add custom RPCs to a device is also beneficial when you want to create RPCs that are device-agnostic and vendor-neutral. You can load YANG modules that add custom RPCs by using the request system yang add operational command.
[See Creating Custom RPCs in YANG for Devices Running Junos OS.]
Network Management and Monitoring
SNMP support for the timing feature on MX104 routers —Starting in Junos OS Release 16.2R1, SNMP supports the timing feature on MX104 routers. Currently, SNMP support is limited to defect and event notifications through SNMP traps. The enterprise-specific MIB, Timing Feature Defect/Event Notification MIB, helps to monitor the operation of PTP clocks within the network. The trap notifications are disabled by default. To enable trap notifications for the timing events and defects , include the timing-event statement at the [edit snmp trap-group trap-group object categories] hierarchy level.
Platform and Infrastructure
Virtual broadband network gateway support on virtual MX Series router (vMX)—Starting in Junos OS Release 16.2, vMX supports most of the subscriber management features available with Junos OS Release 16.2 on MX Series routers to provide a virtual broadband network gateway on x86 servers.
vBNG runs on vMX, so it has similar exceptions; the following subscriber management features available on MX Series routers are not supported for vBNG:
High availability features such as hot-standby backup for enhanced subscriber management and MX Series Virtual Chassis.
CoS features such as shaping applied to an agent circuit identifier (ACI) interface set and its members.
To deploy a vBNG instance, you must purchase these licenses:
vMX PREMIUM application package license with 1 Gbps, 5 Gbps, 10 Gbps, or 40 Gbps bandwidth
vBNG subscriber scale license with 1000, 10 thousand, 100 thousand, or 1 million subscriber sessions for one of these tiers: Introductory, Preferred, or Elite
Virtual MX Series router (vMX)—Starting in Junos OS Release 16.2, you can deploy vMX routers on x86 servers. FreeBSD 10 is the underlying OS for Junos OS for vMX.
vMX supports most of the features available on MX Series routers and allows you to leverage Junos OS to provide a quick and flexible deployment. vMX provides the following benefits:
Optimizes carrier-grade routing for the x86 environment
Simplifies operations by consistency with MX Series routers
Introduces new services without reconfiguration of current infrastructure
Routing Protocols
Support for OSPF segment routing (MX Series)—Starting with Junos OS Release 16.2R1, IPv4 OSPF segment routing support is enabled through MPLS. OSPF creates an adjacency segment per OSPF neighbor, for a given interface, adjacency, and area. A separate MPLS label is allocated for each adjacency segment created.
Labels are allocated only when the neighbor moves from Init state to Upstate and requests the label manager for an unreserved label. The corresponding label transitions are downloaded to the MPLS forwarding table after the label is advertised in locally originated LSPs. In case of LAN adjacencies, OSPF neighborship remains in a two-way state for the adjacencies between the DR-others. A separate label is allocated for each of the LAN neighbors, including the DR-other adjacencies that remain in the two-way state.
The Junos OSPF implementation enables the network operator to provision the following:
IPv4 address family node segment index node-sid—This node-sid will be assigned to a router and used by all other remote routers in the network to index into respective node segment label blocks (SRGBs). It derives the segment identifier to forward IPv4 traffic destined for the same router which was assigned as node-sid.
Note Provisioning the IPv4 node-sid is allowed per routing instance, and is not allowed per OSPF area.
Support for dynamic GRE tunnel creation based on IPv6 and 6VPE routes (MX Series)— Starting with Junos OS Release 16.2, dynamic GRE tunnel creation is triggered by IPv6 L3VPN as well as 6VPE routes without the preexistence of IPv4 L3VPN routes in the same VRF instance.
Support of inner-vlan-list for qualified-bum-pruning-mode of VPLS routing instance (MX Series with MPCs/MICs FPCs)— Starting with Junos OS Release 16.2, support for qualified-bum-pruning-mode is provided on dual-tagged subscriber interfaces configured with inner VLAN list or inner VLAN range for a VPLS routing instance. This allows the BUM traffic egressing this interface to be checked against the combination of the single service provider VLAN with the inner VLAN list or inner VLAN range of the subscriber interface and forward only the packet that is intended for the subscriber. The inner VLAN list on a subscriber interface can have multiple elements. Each element of the inner VLAN list can be a single VLAN tag or a range of VLANs.
Enhancement to the output of the show route detail operational command (MX80, MX104, MX240, MX480, MX960, MX2010, MX2020, vMX Series)—Starting in Junos OS Release 16.2, the output of the show route detail command has been enhanced to show the keyword programmed in the state output field if the route was installed programmatically by an API client application.
[See show route detail.]
BGP labeled unicast supports stack of labels (MX Series)—Beginning with Release 15.1F5, 16.2R1, and later releases, Junos OS supports RFC 3107, Carrying Label Information in BGP-4, that allows stacking of multiple labels in the BGP labeled unicast. In earlier Junos OS Releases, only one label per prefix is supported in the BGP unicast label. Junos OS now supports a label stack of up to five labels per prefix in the BGP labeled unicast updates. BGP labeled unicast updates with more than five labels are not supported and Junos OS sets their state to hidden. This feature allows the use of BGP unicast label stack to control packet forwarding in the network and to reflect the BGP unicast label stack routes to its clients without changing the next hop.
Support for IS-IS flooding groups (MX Series and T Series)—Starting with Junos OS Release 15.1F5, 16.2R1, and later releases, you can configure flooding groups with IS-IS. This feature limits link-state PDU flooding over IS-IS interfaces.
An LSP that is not self-originated is flooded only through the interface belonging to the flood group that has the configured area ID in the LSP. This helps minimize the routes and topology information, thus ensuring optimal convergence. You can segregate both level 1 and level 2 networks into flood groups by using area IDs as tags to identify a flood group. Configure interfaces with specific area IDs to modify the flooding behavior as per your requirements.
To enable IS-IS flooding groups, include the flood-group flood-group-area-ID statement at the [edit protocols isis interface] hierarchy level.
[See IS-IS Overview.]
Micro loop avoidance when IS-IS link fails (MX Series and T Series)—Beginning with Release 15.1F5, 16.2R1, and later releases, Junos OS enables a device to defer IS-IS route download when an IS-IS link fails in order to avoid micro loops. When local links go down, the IS-IS protocol floods an entire area with the database. If the node connected to the local interface that has failed converges faster than the neighboring node, then the connected node redirects traffic to the converged path. This redirection can result in micro looping of traffic until the neighboring node converges. When the primary path of a protected node fails, the connected node does not need to converge quickly if the configured backup path is not impacted. In this case, traffic flow toward a converged path is deferred until the configured delay time.
Support for IS-IS segment routing (MX Series)—Starting with Junos OS Release 15.1F5, 16.2R1, and later releases, IS-IS segment routing support is enabled through MPLS. Currently, label advertisements are supported for IS-IS only. IS-IS creates an adjacency segment per adjacency, per level, and per address family (one each for IPv4 and IPv6). Junos OS IS-IS implementation allocates node segment label blocks in accordance with the IS-IS protocol extensions for supporting segment routing node segments and provides a mechanism to the network operator to provision an IPv4 or IPv6 address family node segment index. To configure segment routing, use the following configuration statements at the [edit protocols isis] hierarchy level:
source-packet-routing—Enable the source packet routing feature.
node-segment—Enable source packet routing at all levels.
use-source-packet-routing—Enable use of source packet routing node segment labels for computing backup paths for normal IPv4 or IPv6 IS-IS prefixes and primary IS-IS source packet routing node segments.
no-advertise-adjacency-segment—Disable advertising of the adjacency segment on all levels for a specific interface.
Support for BGP Optimal Route Reflection (BGP-ORR) (MX Series)—Starting with Junos OS Release 16.2, you can configure BGP-ORR with OSPF as the interior gateway protocol (IGP) on a route reflector to advertise the best path to the BGP-ORR client groups by using the shortest IGP metric from a client's perspective, instead of the route reflector's view.
To enable BGP-ORR, include the optimal-route-reflection statement at the [edit protocols bgp group group-name] hierarchy level.
Use the following CLI commands to monitor and troubleshoot the configuration for BGP-ORR:
show bgp group—View the primary and backup configurations of BGP-ORR.
show ospf bgp-orr—View the OSPF BGP-ORR metric (RIB).
show route advertising protocol bgp peer—Verify whether the routes are being advertised according to the BGP-ORR rules.
Security
Global configuration for flow detection and tracking (MX Series)—Starting in Junos OS Release 16.2, you can configure the mode of operation for flow detection and tracking globally for all protocol groups and packet types. In earlier releases, although you enable flow detection and tracking globally, you can configure the behavior only at the individual flow aggregation levels: physical interface, logical interface, or subscriber; you cannot configure the behavior globally. The new global configuration applies to all packet types in the traffic flow unless it is overridden by the configuration for a protocol group or packet type at the flow aggregation levels.
Services Applications
Support for load balancing dynamic endpoint IPsec tunnels among services interfaces (MX Series routers with MS-MPCs and MS-MICs)—Starting in Junos OS Release 16.2, you can load-balance IPsec tunnels with dynamic endpoints among services interfaces on multiple PICs. You configure load balancing by configuring multiple next-hop IPsec service sets, each identifying services interfaces with the inside-service and outside-service statements at the [edit services service-set service-set-name next-hop-service] hierarchy level. The services interfaces in the outside-service statements of the service sets must be in the same VPN routing and forwarding (VRF) instance, and each of the service sets must include the same local-gateway and ike-access-profile values at the [edit services service-set service-set-name ipsec-vpn-options] hierarchy level.
Support for multiple source-destination port pairs in a DTCP ADD request (MX Series routers)—Starting in Junos OS Release 16.2, the MX Series router can process mediation device DTCP ADD requests that contain up to 15 source-destination port pairs. Multiple source-destination port pairs must be separated by commas.
Subscriber Management and Services
Shared memory logs for client-level analysis (MX Series)—Starting in Junos OS Release 16.2, shared memory logging smlog is available by default so you can retrieve client activity on a per subscriber basis. Additional filters enables you to retrieve logs according to a variety of parameters, including the client identifier, client DUID, interface name, IP address, session ID, subnet, and VLAN.
A complete list of supported filters is available at the [show shmlog entries logname all] hierarchy level and a complete list of flags is available at the [show shmlog entries logname all flag-name] hierarchy level.
See shmlog for information about disabling shared memory logs, and steps required to view the data.
Support dynamic VLAN access profile assignments (MX Series)—Starting in Junos OS Release 16.2, you can assign different access profiles to different dynamic profiles on the same interface. For example, you can attach an access profile to an interface configured for dynamic VLAN/SVLAN so all the VLANs/SVLANs use the same set of authentication, authorization, and accounting parameters. However, different access profiles can have different authentication/authorization settings, so that you could have authentication on some VLAN/SVLAN ranges but not on other ranges.
To configure dynamic VLAN access profile assignments, add the access profile at the [edit interfaces <interface-name> auto-configure vlan-ranges dynamic-profile <profile-name> access-profile <vlan-access-profile-name>] or [edit interfaces <interface-name> auto-configure stacked-vlan-ranges dynamic-profile <svlan-profile-name> access-profile <svlan-vlan-access-profile-name>] hierarchy level.
Support for 1:1 LNS stateful redundancy on aggregated inline service interfaces (MX Series with MPCs and MIC interfaces)—Starting in Junos OS Release 16.2, you can create an aggregated inline service virtual logical interface that bundles pairs of inline services anchor interfaces across MPCs to provide 1:1 LNS stateful redundancy between the paired members. You can assign a single bundle or one or more pools of bundles per L2TP tunnel group.
LNS sessions are subsequently established on the aggregated interface. When an LNS session failover occurs, the secondary link becomes active and all the LNS data traffic destined for the session automatically moves over to the secondary anchor interface on a different MPC. The subscriber session remains up on the virtual logical interface. No traffic statistics are lost. If this redundancy is not configured, subscriber traffic is lost, the keepalives expire, and the PPP client is disconnected.
When a card comes back online after a failover, you can move the LNS data traffic from the currently active secondary interface back to the primary interface on the original card You can manually force a switchover from the primary interface to the secondary interface, and you can manually revert to the original interface in this case as well.
Subscriber login session with optional services (MX Series)—Starting in Junos OS Release 16.2, you can use the service activation statement at the [edit access profile profile-name radius options] hierarchy level to specify whether successful activation of services referenced in the Activate-Service VSA (26-65) in the RADIUS Access-Accept message is required or optional for subscriber login access.
When activation is required, failure for any reason causes the Network-Family-Activate-Request for that network family to fail. If no other network family is already active for the subscriber, then the client application logs out the subscriber.
When activation is optional, subscribers can still log in when a service fails to activate because of a configuration error. Failures for any other reason do not allow successful login.
By default, activation is required for services applied with a dynamic profile and is optional for services applied by an Extensible Subscriber Services Manager (ESSM) operation script. In earlier releases, only the default behavior is available.
Note This configuration does not apply to services activated by means of RADIUS CoA requests, JSRC Push-Profile-Request (PPR) messages, or subscriber secure policy.
Processing multiple activation and deactivation requests in a single CoA message (MX Series)—Starting in Junos OS Release 16.2R1, subscriber management processes RADIUS-initiated Change of Authorization (CoA) messages in a more efficient manner. When it receives CoA message that has multiple activation and deactivation requests, the router groups the requests together, by type. The router then processes all deactivation requests before processing the activation requests.
Processing deactivation requests first helps the router provide a consistent behavior for activated services. For example, a particular service might be activated multiple times, using different parameters. It is more efficient for the router to process the deactivation requests for existing instances of the service before attempting to activate the same service with different parameters.
In earlier releases, the router processed all activation requests first, before processing the deactivation requests in the CoA message.
Support for username stripping per routing instance (MX Series)—Starting in Junos OS Release 16.2, you can configure a subscriber access profile so that a portion of each subscriber login string is discarded and the remaining characters subsequently are used as a modified username by an external AAA server for session authentication and accounting. The modified username appears, for example, in RADIUS Access-Request, Acct-Start, and Acct-Stop messages, as well as RADIUS-initiated disconnect requests and change of authorization (CoA) requests. The login string is examined in the direction you specify until a delimiter is identified as one of the configured delimiters. The delimiter and all characters to the right of the delimiter are discarded.
AAA option sets to authorize and configure subscribers per routing instance to support username stripping (MX Series)—Starting in Junos OS Release 16.2, you can include one or more of the following statements at the new [edit access aaa-options aaa-options-name] hierarchy level to define a set of AAA options for a subscriber or set of subscribers that username stripping is applied to:
access-profile profile-name—Specify the name of the access profile that includes the username stripping configuration.
aaa-context aaa-context-name—Specify the logical-system:routing-instance that the subscriber session uses for AAA (RADIUS) interactions like authenticating and accounting.
subscriber-context subscriber-context-name—Specify the logical-system:routing-instance in which the subscriber interface is placed.
Note Only the default (master) logical system is supported.
Use the aaa-options aaa-options-name statement at the [edit dynamic-profiles profile-name interfaces pp0 unit $junos-interface-unit ppp-options] hierarchy level to apply the attributes to PPP subscribers tunneled from the LAC to the LNS inline service interface.
Alternatively, use the aaa-options aaa-options-name statement at the [edit access group-profile profile-name ppp-options] hierarchy level to apply the attributes to PPP subscribers tunneled from LACs that are members of the user group.
Usernames are examined and modified according to the subscriber and AAA contexts specified in the option set. In the event of a conflict between option sets configured in both a group profile and a dynamic profile, the dynamic profile takes precedence.
Support for maximum session limits on L2TP service interfaces (MX Series)—Starting in Junos OS Release 16.2, you can include the l2tp-maximum-session number statement at the [edit interfaces siservice-interface] or [edit interfaces asiservice-interface] hierarchy level to specify the maximum number of sessions that are allowed on an individual service interface (si) or aggregated service interface (asi). New session requests on an interface are accepted only when the session count is less than the maximum session limit. If the limit has been reached, subsequent requests are dropped and the LNS responds with a CDN message (Result Code 2, Error Code 4). When a pool of interfaces is configured, interfaces at the maximum limit are ignored in favor of an interface in the pool that has a lower session count. For an asi interface, the configuration applies to all member interfaces; you cannot configure the limit for individual member interfaces.
Enhanced load balancing on L2TP physical service interfaces (MX Series)—Starting in Junos OS Release 16.2, when a service interface in a service device pool is rebooted, sessions reconnect and new session requests are distributed based on the number of sessions on the available interfaces in the pool. The sessions are assigned to the interface with the fewest sessions. If more than one interface has the minimum number of sessions, then a random selection determines which interface gets the session.
In earlier releases, session load balancing is a simple round-robin distribution among the interfaces. Consequently, fewer sessions are assigned to a newly rebooted interface than to the other interfaces. For example, consider a pool with two si interfaces, si-0/0/0 and si-1/0/0. Each has 100 sessions. If si-1/0/0 reboots, it drops all 100 sessions. As the sessions reconnect, they alternate between the two interfaces so that when all sessions have reconnected, si-0/0/0 has 150 sessions and the reconnected si-1/0/0 interface has only 50 sessions.
Consider the same pool with the new behavior. As sessions reconnect, si-1/0/0 has fewer sessions (0 to start) than si-0/0/0 (100). Because the interface with the fewest sessions is selected, all sessions are assigned to si-1/0/0 until it reaches the same count as si-0/0/0.
For aggregated services interfaces (asi), the interface with the lowest session count is selected from the pool for new or reconnect session requests. When the active si interface in the asi bundle goes down, all the active sessions on that primary interface fail over to the secondary interface.
Monitoring only ingress traffic for subscriber idle timeouts (MX Series)—Starting in Junos OS Release 16.2, you can specify that only ingress data traffic is monitored for subscriber idle timeout processing. If you include the client-idle-timeout-ingress-only statement in addition to the client-idle-timeout statement at the [edit access-profile profile-name session-options] hierarchy level, subscribers are logged out or disconnected when no ingress traffic is received for the duration of the idle timeout period. Egress traffic is not monitored. If you do not include the client-idle-timeout-ingress-only statement, both ingress and egress data traffic are monitored during the timeout period to determine whether subscribers are logged out or disconnected.
Broadband-specific support for PCEF (MX Series)—Starting in Junos OS Release 16.2, the policy and charging enforcement function (PCEF) is supported for broadband-specific functionality. PCEF is one of the major components of the 3rd Generation Partnership Project (3GPP) policy and charging control (PCC) architecture that provides the unification of wireline provisioning and accounting for customers. PCEF provides user traffic handling and CoS at the gateway, provides service data flow detection, and applies the rules received from the Policy and Charging Rules Function (PCRF). PCEF optionally interacts with the Online Charging System (OCS) using the 3GPP Gy protocol to retrieve policy and charging authorization for quotas and credit control.
BPCEF configuration consists of configuring the characteristics of the PCRF and OCS with which it interacts. Include the pcrf statement at the [edit access] hierarchy level to configure the PCRF partition and the global attributes, rules, and parameters to authorize and provision subscribers. Include the ocs statement at the [edit access] hierarchy level to configure the OCS global attributes and partition. Include the provisioning-order pcrf statement at the [edit access profile profile-name] hierarchy level to request provisioning from the PCRF over the Gx protocol. Include the charging-service-list ocs statement at the [edit access profile profile-name] hierarchy level to configure the list of charging services to be communicated.
Use these new commands to display PCRF and OCS information: show network-access pcrf state, show network-access pcrf statistics, show network-access ocs state, and show network-access ocs statistics. Use these new commands to clear statistics and subscriber counters: clear network-access pcrf statistics, clear network-access pcrf subscribers, and clear network-access ocs statistics.
DHCPv6 relay agent supports multiple addresses or prefixes per DUID (MX Series)—Starting in Junos OS Release 16.2, DHCPv6 relay agent supports multiple address or network prefix leases assigned to a single DHCP Unique ID (DUID). Existing operational commands that display DHCPv6 relay bindings now display multiple addresses and network prefixes. When you are configuring DHCPv6 relay agent, if service accounting is required separately for each address or network prefix issued to a single subscriber, you must configure a separate address pool at the DHCPv6 server for each address or network prefix allocated.
Support for vendor-specific information in DHCPv4 and DHCPv6 relay (MX Series)—Starting in Junos OS Release 16.2, you can add a hostname, location (such as a unique connection identifier), or both in DHCP control packets sent over server-facing interfaces. For DHCPv4 relays, the feature leverages option 82, suboption 9, to provide the vendor-specific information. For DHCPv6 relays, it is added under the vendor-specific option (17).
This feature can be useful when used with operator-developed tools for troubleshooting DHCP servers and providing service assurances. For example, a central DHCP server can log the information, and operators can query a single entity to track and troubleshoot subscriber IP information and network attachment points.
To configure vendor-specific information, add a hostname, location, or both at the [edit forwarding-options dhcp-relay relay-option-82 vendor-specific host-name] or [edit forwarding-options dhcp-relay relay-option-82 vendor-specific location] hierarchy level.
Preserving and restoring IPv6 prefixes assigned using DHCPv6 Prefix Delegation (MX Series)—Starting in Junos OS Release 16.2, when IPv6 addresses are assigned using DHCPv6 Prefix Delegation, you can configure the router to preserve and restore a subscriber's delegated prefix through multiple logins. This feature prevents an IA-PD change, which triggers renegotiation for all hosts attached to the residential gateway. This feature requires the use of Agent-Circuit-IDs (ACIs) to identify subscribers.
Subscriber management and services feature and scaling parity (MX104)—The MX104 router supports all subscriber management and services features that are supported by the MX80 router and the MX240, MX480, and MX960 routers. In addition, the scaling and performance values for the MX104 router match those of the MX80, MX240, MX480, and MX960 routers.
DHCP rate adjustment (MX Series)—Starting in Junos OS Release 16.2, you can use DHCP tags to modify the CLI-configured and RADIUS-configured shaping rate values after a subscriber is instantiated. The new values are conveyed in DHCP option 82, suboption 9 discovery packets. Suboption 9 contains the Internet Assigned Numbers Authority (IANA) DSL Forum VSA (vendor ID 3561).
Configure the shaping rate adjustment controls by including the dhcp-tags statement at the [edit class-of-service adjustment-control-profiles profile-name application] hierarchy level. Specify the desired rate-adjustment algorithm and set a priority for the DHCP Tags application in the adjustment control profile.
System Logging
Internal communication health monitor—Starting in Junos OS Release 16.2, you can use the internal communication health monitor daemon (icmd). The icmd daemon runs on all Routing Engines in the chassis or virtual chassis and it monitors internal communication systems, reports any unexpected communication changes, logs communication issues to /var/log/messages and provides debugging information.
The icmd daemon can be deployed on all platforms as icmd in /usr/libexec and runs automatically with jlaunchd.
VPNS
Support for next-hop-based dynamic tunnels (MX Series and T Series)—Starting with Junos OS Release 16.2, dynamic generic routing encapsulation (GRE) and UDP tunnels support the creation of a tunnel composite next hop for every dynamic tunnel created. The tunnel composite next hop includes the dynamic tunnel’s source and destination IP address, encapsulation data, and a VPN label (when chained composite next hop is not enabled).
For dynamic GRE tunnels, the next-hop-based tunneling feature should be explicitly configured. This feature overcomes the scaling limitation of the default interface-based tunnel mode by removing the dependency on physical interfaces, and creating a next-hop ID instead of a next-hop interface for every GRE tunnel configured. To enable next-hop-based dynamic GRE tunnels, include the next-hop-based-tunnel statement at the [edit routing-options dynamic-tunnels gre] hierarchy level. With next-hop-based dynamic GRE tunnels, a device can scale up to 32,000 dynamic GRE tunnels.
For dynamic UDP tunnels, the next-hop-based tunnel mode is supported by default. These tunnels are referred to as MPLS-over-UDP tunnels, and they provide a scaling advantage of up to 4,000 UDP tunnels on a device.
The next-hop-based dynamic tunnel feature benefits data center deployments that require mesh IP connectivity from one provider edge (PE) device to all other PE devices in the network. At a given point in time, for the same tunnel destination, the next-hop-based dynamic tunnel encapsulation can either be GRE or UDP.
[See Example: Configuring Next-Hop-Based MPLS-Over-UDP Dynamic Tunnels and Example: Configuring Next-Hop-Based Dynamic GRE Tunnels.]
VXLAN
Overlay ping and traceroute functionality for VXLAN tunnels (MX Series)—Starting in Junos OS Release 16.2R1, two new CLI commands supporting ping and traceroute troubleshooting functionality are provided to debug VXLAN overlay tunnels: ping overlay vni vni-id tunnel-src ip-address-src tunnel-dst ip-address-dst and traceroute overlay vni vni-id tunnel-src ip-address-src tunnel-dst ip-address-dst. Use the ping overlay and traceroute overlay commands to validate and verify the presence of the VXLAN tunnel endpoints within the context of the overlay VXLAN network identifier or VXLAN Segment ID (VNI) segment.Understanding Overlay ping and traceroute Packet Support