|
|
Release Highlights
Release 13.2.0 includes the features described in this section.
ANCP (L2C)
- Support for Filtering the Output of show Commands Related to ANCP
You can now filter the output of the L2C-related show commands by specifying | (the UNIX pipe symbol), one of the following keywords, and either a case-sensitive text string or a regular expression.
For more information about the filtering feature, see Filtering show Commands in the JunosE Command Reference Guide N to Z.
The following commands have been enhanced to support the filtering feature:
Change in existing behavior: New feature added as described here.
IS-IS
- Ability to Advertise IPv6 Prefixes of Passive Interfaces
You can configure IS-IS to advertise IPv6 prefixes that belong to only passive interfaces. Enabling this feature causes only connected passive IPv6 prefixes to be retained and all other entries to be removed from the LSP database. Disabling this command restores all the entries in the LSP database, thus allowing all IPv6 prefixes to be advertised.
You can use the advertise-passive-only command in Address Family Configuration mode to advertise IPv6 prefixes of passive interfaces only. For example:
host1(config-router)# address-family ipv6
host1(config-router-af)# advertise-passive-only
Configuring IS-IS to advertise only passive interfaces reduces network convergence time between two integrated IS-IS systems.
The following command has been enhanced in this release:
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, you could configure IS-IS to advertise only IPv4 prefixes of passive interfaces.
L2TP
- Transmission of the L2C RAM Actual Upstream Rate from LAC to LNS Using the RX Connect-Speed AVP [38]
You can now transmit the L2C RAM actual upstream rate to the L2TP network server (LNS) using the receive (RX) connect speed attribute-value pair (AVP). Since there is no integration between L2C and L2TP, the actual upstream rate is sent from L2C to AAA, which sends it with tunnel parameters to the L2TP access concentrator (LAC) during the creation of the tunnel. The LAC transmits the actual upstream rate to the LNS through the RX Connect-Speed AVP [38] in the ICCN message.
The following command has been added to support this feature:
As part of this feature, the l2tp event log has been modified to notify the transmission of the upstream data rate from LAC to LNS and to report the failure in transmission of the upstream data rate from LAC to LNS.
Change in existing behavior: New feature added as described here. In lower-numbered releases, LAC performs one of the following tasks:
- Transmits the configured advisory RX speed in the RX Connect-Speed AVP even when the generation of RX Connect-Speed AVP during equal RX and TX speeds is enabled.
- Generates the RX Connect-Speed AVP when the TX and RX speeds are equal if the generation of the AVP is enabled. The RX Connect-Speed AVP is suppressed if the generation of the AVP is disabled.
Packet Mirroring
- Support for Preserving the snmp-server secure-log Command Configuration Across Warm Restart
JunosE Software now preserves the snmp-server secure-log command configuration across a warm restart operation by storing the configuration in the non-volatile memory. Based on the stored configuration, the trap data is logged for the packet mirrors that are automatically applied during subscriber login for the newly attached secure policy after the restart operation.
Informational Note: The trap data is not preserved across the reboot because it is not stored in the non-volatile memory.
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, the snmp-server secure-log command configuration is not preserved across the reboot.
Policy Management
- Support for Forwarding Rules Based on Next-Hop Addresses for IPv6 Policies on ES2 4G LMs, ES2 10G LMs, and ES2 10G Uplink LMs
You can now configure a rule for input IPv6 policies to forward all packets that match a classifier control list (CLACL) associated with that rule to the specified next-hop addresses on ES2 4G LMs, ES2 10G LMs, and ES2 10G Uplink LMs. If a classifier group has multiple rules, the router uses the rules according to their precedence, not in the order in which you created the rules. For input Ipv6 policy lists, if you configure the forward next-hop rule, it has a higher precedence than all other rules, such as color or rate-limit-profile rules.
For input IPv6 policy lists, policy rules are available to enable you to make a forwarding decision that includes the next hop. You can configure the forward next-hop nextHop command for classifier groups in IPv6 policy lists to enable an interface to forward all packets that satisfy the CLACL associated with that rule to the specified next-hop address. You can also use the forward next-hop nextHop order orderValue command in Classifier Group Configuration mode to specify the order for the forward rule in the CLACL. You can configure only indirect next-hop addresses while configuring forwarding rules based on next-hop addresses for input IPv6 policies.
You can configure the rule to forward all packets that match a CLACL to a particular next-hop address only for input IPv6 policies on routers with ES2 4G LMs, ES2 10G LMs, and ES2 10G Uplink LMs (policies applied to ingress interfaces) or IPv6 policies on ES2 4G LMs, ES2 10G LMs, and ES2 10G Uplink LMs that function as access line modules (receive traffic from low-speed circuits and route it to uplink modules). You cannot configure next-hop addresses as forwarding rules for IPv6 policies when the ES2 4G LMs, ES2 10G LMs, and ES2 10G Uplink LMs are core-facing, uplink modules. However, when the ES2 4G LMs, ES2 10G LMs, and ES2 10G Uplink LMs operate as access modules for forwarding rules for IPv6 policies, you can configure the core-facing modules as ES2 4G LMs, ES2 10G LMs, ES2 10G Uplink LMs, or ES2 10G ADV LMs.
The performance of the policy manager application might be slightly impacted if you configure a significant number of IPv6 policies with forward rules and the reachability states of the configured next-hop addresses transition frequently.
Forwarding of traffic based on next-hop addresses in input IPv6 policy lists is available only for ingress IPv6 interfaces that are configured over Ethernet or MPLS interfaces. You cannot configure forward rules based on next-hop addresses in policy lists for IPv6 interfaces over GRE tunnels.
The output of the show ipv6 interface and show policy-list commands have been enhanced to display the configured next-hop and next-interface actions for forward rules for IPv6 policies.
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, you could configure rules to forward packets to the specified next-hop addresses for only input IPv4 policy lists.
- Support for Detection of Corruption in FPGA Statistics for Policies Managed by the SRC Client
When a bit flip occurs in the RAM of the field-programmable gate array (FPGA) statistics of a router, which functions as the SRC client, the router may transmit erroneous and inconsistent statistical details for IPv4 and IPv6 subscribers to the SRC server or the Common Open Policy Service (COPS) server. This affects the computation of accounting information for subscriber sessions. When incorrect policy statistical details are sent from the SRC client, you can resolve the problem of inconsistent subscriber accounting only by replacing the defective hardware.
To prevent hardware from being replaced, you can configure a software detection mechanism that identifies corruption in the FPGA statistics before the SRC client sends erroneous subscriber statistics to the SRC server. The capability to detect incorrect statistics operates by comparing the statistical counters of packets processed by an interface and the packets for policies attached to the interface against a configured threshold value.
If the difference between the interface counters and policy counters for ingress or egress policies collected over two polling intervals exceeds the specified threshold value, a corruption is detected in the FPGA statistics and the subscriber statistics are not forwarded to the SRC server. If the difference between the interface counters and policy counters for ingress or egress policies collected over two polling intervals is less than the specified threshold value, no corruption is identified in the FPGA statistics and the collected subscriber statistical details are sent to the SRC server.
You can now use the fpga-stats-monitoring-enable command in Privileged Exec mode to enable the capability to detect corruption in FPGA statistics and prevent the transmission of incorrect statistical details to the SRC server for subscriber policies managed by the SRC server.
You can use the fpga-stats-monitoring threshold command in Global Configuration mode to specify a threshold value to be used to determine corruption in FPGA statistics. The threshold value is matched against the difference of interface and policy counter values (for ingress and egress policies) collected over two consecutive polling periods.
You can use the show fpga-stats-monitoring command to display the settings configured for detection of FPGA corruption.
When the detection mechanism identifies a defective slot, it fails to validate the FPGA statistics and SNMP traps are not generated. When the detection utility notices a corruption in FPGA statistics, it generates a system event logging message.
The following commands have been added to support this feature:
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, if incorrect statistics of subscriber policies managed by the SRC server were sent to the SRC server, you could recover the correct statistics only by replacing the malfunctioning hardware. The new feature notifies the user in the event of a hardware corruption and avoids sending erroneous statistics to the SRC server upon corruption detection.
PPP
- Support for Increase of the Maximum Timeout Duration of PPP Sessions to 13 Years
JunosE Software now supports the capability to increase the maximum duration for which a PPP session needs to be preserved and kept activated to 13 years using the tech-support encoded-string command in Privileged Exec mode. We recommend that you configure this setting for enhanced maximum timeout duration for PPP sessions only under the direction of Juniper Networks customer support, as we generally recommend that parameters are configured using this command.
By default, established PPP sessions are maintained before being terminated for a duration equal to the sum of one non-leap year and one day (366 days). If you configure the no aaa timeout session sessionTimeout command, the default session timeout of 366 days is applicable. If you configure RADIUS authentication for PPP sessions and the Session-Timeout attribute from the RADIUS server returns a value of zero, the scenario is the same as the default behavior. In such a case, PPP sessions are preserved for a maximum of 366 days.
If you do not configure the tech-support encoded-string command for enhanced maximum timeout of PPP sessions, the PPP sessions are kept alive for 366 days by default. If you enabled the functionality to increase the maximum timeout of PPP sessions to 13 years, you must reboot the router configuration with factory default settings to restore the default maximum timeout for PPP sessions.
The setting for increased maximum timeout period of PPP sessions is preserved across a restart of the router using configuration (.cnf) or script (.scr) files if the tech-support encoded-string command is contained in the .cnf or .scr files. This setting is also retained after stateful SRP switchover and unified ISSU operations.
By default, when a PPP session is established, a timer control starts with the timeout value preconfigured to be 366 days. When the increased timeout mechanism for PPP sessions is enabled, the timer control runs for 13 years. This timer control restarts every year until the end of the timeout period, and is repeatedly recycled for a total duration of 13 years. At the end of 13 years, the timeout value reaches zero and the sessions are terminated.
You can also use the show ppp session-To-Thirteen-Years command in Privileged Exec or User Exec mode to verify whether the capability to preserve PPP sessions for a timeout duration of 13 years is enabled using the tech-support encoded-string command.
The following commands have been added or enhanced to support this feature:
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, you could configure the maximum timeout period for B-RAS PPP sessions to be only 366 days (one non-leap year plus one day) using the aaa timeout session sessionTimeout command; you could not further enhance this timeout duration.
RADIUS
- Inclusion of Dual-Stack Lite Tunnel Name and PCP Server Name RADIUS Attributes in RADIUS Accounting Messages
You can now include the DS-Lite-Tunnel-Name and PCP-Server-Name RADIUS attributes in RADIUS accounting messages. You can use the radius include command in Global Configuration mode to include these attributes in Acct-Start, Acct-Stop, and Interim-Acct messages. When included in Acct-Stop messages, the attribute is also included in Interim-Acct messages. The attribute is excluded by default from the Acct-Start, Acct-Stop, and Interim-Acct messages.
The DHCP server sends the PCP-Server-Name attribute to DHCP subscribers when the OPTION_PCP_SERVER code is included in the Parameter Request List Option. The DHCPv6 server sends the DS-Lite-Tunnel-Name attribute to DHCPv6 subscribers only when the OPTION_AFTR_NAME code is included in the Option Request Option. The DHCPv6 server sends the PCP-Server-Name RADIUS attribute to DHCPv6 subscribers only when the OPTION_PCP_SERVER code is included in the Option Request Option.
Informational Note: The DS-Lite-Tunnel-Name and PCP-Server-Name RADIUS attributes are not supported when DHCP is configured in Equal-Access or Standalone mode.
As part of this feature, the DS-Lite-Tunnel-Name and PCP-Server-Name RADIUS attributes have been added to the radius include command.
The following command has been modified to support this feature:
The output of the following command has been modified to support this feature:
As part of this feature, the following event logs have been modified:
Change in existing behavior: New feature added as described here.
- Support for Processing DNS Addresses from Microsoft RADIUS VSAs for PPP Clients During IPCP Negotiations
The RADIUS client, which is a B-RAS router, supports the processing and parsing of the Microsoft RADIUS VSAs for the primary and secondary DNS addresses that are returned in the Access-Accept messages from the RADIUS server in an environment that contains PPP clients. The AAA application running on the router, which is the RADIUS client, transmits the DNS addresses to the PPP application in the authentication response message. PPP includes these DNS addresses in the Internet Protocol Control Protocol (IPCP) packets that are negotiated between the PPP client and the router.
The RADIUS client services the Microsoft vendor ID 311 and does not discard the DNS server addresses that the Microsoft VSAs contain in the Access-Accept messages.
The PPP application uses Link Control Protocol (LCP) negotiations to establish the connection with the subscriber. PPP sends Network Control Protocol (NCP) packets to establish and configure the session with the client. After a link has been established and optional facilities have been negotiated as needed by the LCP between the customer premises equipment (CPE) and the provider edge (PE) router, PPP running on the PE router or the B-RAS server sends Network Control Protocol (NCP) packets. When the CPE sends an IPCP negotiation, it negotiates IPv4 addresses, IPv6 addresses, or both.
After the PE router receives an IPCP configuration request from the CPE, which starts the IPCP negotiation process, the B-RAS application running on the router requests a new IPv4 address from the RADIUS server. After successful authentication, the RADIUS server sends the Access-Accept message with all of the supported attributes for all sessions established.
If the Access-Accept message contains the MS-Primary-DNS-Server [311-28] and MS-Secondary-DNS-Server [311-29] RADIUS VSA attributes, which denote the primary and secondary DNS server addresses that can be requested by PPP clients from the B-RAS server during IPCP negotiations, the RADIUS client or the B-RAS server sends the values of the VSAs to the CPE in the IPCP packet that is negotiated.
During IPCPv4 negotiations, if the Access-Accept message contains both the Juniper Networks VSAs related to the DNS addresses (Primary-DNS [26-4] and Secondary-DNS [26-5]) and the Microsoft VSAs related to DNS addresses (MS-Primary-DNS-Server [311-28] and the MS-Secondary-DNS-Server [311-29]), the Juniper Networks VSAs take precedence over the Microsoft VSAs.
During IPCPv6 negotiations, if the Access-Accept message contains both the Juniper Networks VSAs related to the DNS addresses (Ipv6-Primary-DNS [26-47] and Ipv6-Secondary-DNS [26-48]) and the Microsoft VSAs related to DNS addresses (MS-Primary-DNS-Server [311-28] and the MS-Secondary-DNS-Server [311-29]), the Juniper Networks VSAs take precedence over the Microsoft VSAs.
With the capability to validate the Microsoft VSAs for primary and secondary DNS addresses enabled, the order of precedence of the RADIUS attributes in the Access-Accept messages to be used for IPCP negotiations is as follows:
As part of this feature, the radiusAttributes system logging category has been enhanced to record information at the debug severity level if the MS-Primary-DNS-Server [311-28] and the MS-Secondary-DNS-Server [311-29] RADIUS VSA attributes are contained in the Access-Accept message that the RADIUS server sends to the RADIUS client to enable the DNS addresses of the PPP clients to be used in IPCP negotiations.
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, the RADIUS client discarded and did not validate the Microsoft RADIUS VSAs for primary and secondary DNS server addresses if these values were transmitted in the Access-Accept messages from the RADIUS server. Only the Primary-DNS [26-4] and Secondary-DNS [26-5] Juniper Networks VSAs for IPv4 packets and Ipv6-Primary-DNS [26-47] and Ipv6-Secondary-DNS [26-48] Juniper Networks VSAs for IPv6 packets were processed if they were present in the Access-Accept messages. The Microsoft VSAs associated with DNS server addresses were ignored and the LNS device did not use these addresses during IPCP negotiations between the router and the PPP client.
- Inclusion of QoS-Profile-Name VSA Attribute in RADIUS Accounting Messages
You can now include the QoS-Profile-Name [26-26] VSA attribute received from the RADIUS server through the Access-Accept message into the accounting messages.
You can use the radius include command from Global Configuration mode to configure inclusion of this VSA attribute in Acct-Start, Acct-Stop, and Interim-Acct messages. When included in Acct-Stop messages, the attribute is also included in Interim-Acct messages. The attribute is excluded by default from the Acct-Start, Acct-Stop, and Interim-Acct messages.
The following SNMP MIB objects have been added to the Juniper Networks RADIUS client MIB:
- rsRadiusClientIncludeQosProfileNameInAcctStart—Enables or disables the inclusion of the QoS-Profile-Name VSA attribute in the RADIUS Accounting-Start packet.
- rsRadiusClientIncludeQosProfileNameInAcctStop—Enables or disables the inclusion of the QoS-Profile-Name VSA attribute in the RADIUS Accounting-Stop packet.
The following command has been enhanced to support this feature:
The output of the following command has been changed to support this feature:
As part of this feature, the radiusSendAttributes log has been modified to add the QoS-Profile-Name VSA attribute at the debug level.
Change in existing behavior: New feature added as described here.
SNMP
- Processing Performance Enhancements for SNMP Query and Walk Operations
You can now perform an SNMP walk of the ifStackTable object of the IF MIB, which contains information about the relationships between the multiple sublayers of network interfaces, without encountering a timeout for the traps sent to the SNMP host or the router. This enhancement is done only for IP and PPP upper-layer compression logic with the following limitations:
You can now have an optimized CPU utilization while performing the following operations:
- A Get operation to enable the router to retrieve the JuniSystemModuleSoftwareversion object instance in the System MIB from the server and the entPhysicalTable object in the Entity MIB
- Parsing the .rif files, which are retrieved from SYSTEM MIB
- An SNMP walk or a Get Bulk operation is performed for the juniSystemIssu MIB object of the Juniper Networks System MIB
Change in existing behavior: Existing feature extended as described here.
|
Copyright © 2012, Juniper Networks, Inc. Report An Error |
|
|