|
|
Release Highlights
Release 13.1.0 includes the features described in this section.
DHCP
- Inclusion of DHCP Option 82 Agent-Circuit-Id and Agent-Remote-Id RADIUS Attributes in Access and Accounting Messages
You can now use DHCP Option 82, also known as the DHCP relay agent information option, to help protect the router against attacks such as spoofing of IP addresses and MAC addresses, and DHCP IP address starvation. Option 82 provides information about the network location of a DHCP client. The DHCP server uses this information to implement IP addresses or other parameters for the client.
The Option 82 attribute contains the agent remote identifier and agent circuit identifier suboptions. The agent-remote-id suboption contains the username and the domain name, such as "user@domain.com", and the agent-circuit-id suboption contains circuit identification details.
You can use the radius enable command in Global Configuration mode to enable the Agent-Circuit-Id and Agent-Remote-Id RADIUS VSA attributes to be retrieved and saved in ASCII format from the DHCP Option 82 VSA attribute [26–159] and be sent to the RADIUS server. You must configure this command to enable the sending of these VSA attributes before you use the radius include command to specify these two VSA attributes to be included in the Access-Request, Acct-Start, and Acct-Stop messages sent to the RADIUS server.
As a part of this feature, the dhcp-option82-circuitid and dhcp-option82-remoteid keywords have been added to the radius include command.
The output of the show radius attributes-included command has been modified to display whether the DHCP Option 82 Agent-Remote-Id and Agent-Circuit-Id RADIUS VSA attributes are enabled for inclusion in the Access-Request, Acct-Start, and Acct-Stop messages.
In addition, the radiusSendAttributes event category has been enhanced to record a message at the debug severity level when the DHCP Option 82 Agent-Remote-Id and Agent-Circuit-Id RADIUS VSA attributes are included in access and accounting messages.
The following command has been modified to support this feature:
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, you could include the DHCP Option 82 VSA attribute [26–159] in access and accounting messages. However, the agent circuit and agent remote identifiers could not be separately decoded and transmitted in access and accounting messages to the RADIUS server.
IP
- Processing of IPCP Negotiations for Dual-Stack Subscribers and Optimal Release of IPv4 Addresses for Terminated Sessions
You can configure the maximum number of successful IPCP renegotiations for IPv4 addresses that the router can receive per subscriber by using the ppp ipcp-max-negotiation maxRenegotiationsCount command. These settings are effective when you configure the router with the capability to send a notification to the AAA server regarding released IPv4 addresses in a dual-stack environment by using the aaa ipv4-addr-saving command.
You can also specify the interval during which the maximum number of IPCP renegotiations per subscriber needs to be restricted by using the ppp ipcp-nego-duration RenegotiationsInterval command.
The Ipv4-Release-Control RADIUS VSA attribute [26-164] can be configured to be sent in the Access-Request, Acct-Start, Interim-Acct, and Acct-Stop messages. You can use the radius include command to configure this attribute to be sent in the access and accounting messages.
As part of this feature, the aaaServerGeneral event category has been enhanced to record information on the IPCP renegotiation and assignment or release of IPv4 addresses for dual-stack subscribers. This log message also generates messages when the Ipv4-Release-Control VSA attribute is included in access and accounting messages sent to the RADIUS server.
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, when an IPv4 address was released by a dual-stack subscriber connected using the PPP link to the router, PPP did not communicate the released IPv4 address to the AAA server, and the utilization of addresses was not optimal and effective.
L2TP
- Monitoring the Duration for Which L2TP Tunnels are Active
You can now use the show l2tp tunnel detail l2tpName command to view the duration for which an L2TP tunnel is in the established state on both the LAC and LNS devices. When the tunnel transitions to the operationally up state, the system time at that point is used to compute the period for which the tunnel is active and established.
The total duration for which a specified tunnel is in the operationally up or active state is determined as the difference between the time at which the tunnel moved to the up state and the time of the system clock at which the command is issued. The Tunnel is Up for field under the Tunnel status section in the output of the show l2tp tunnel detail l2tpName command displays the duration for which the tunnel is active in days, hours, minutes, and seconds. This duration is useful in networks in which L2TP subscriber sessions are present for monitoring and diagnosing the state of the tunnels.
To display the duration for which all configured L2TP tunnels are active, use the show l2tp tunnel detail command without specifying the tunnel name. If a tunnel is established on a LAC or LNS device, which is a router running a JunosE release numbered lower than Release 13.1.0, and if you upgrade the router to Release 13.1.0, the field that displays the tunnel up time is not displayed in the output of the show l2tp tunnel detail command because the duration is not calculated and saved in the system.
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, the time period for which tunnels were active was not displayed for statistical purposes in network environments where subscribers were established over L2TP tunnels.
SNMP
- Generation of SNMP Traps for Thresholds of DHCP Local Address Pool Utilization
JunosE now handles SNMP traps and actively manages DHCP address pool space.
An address pool has SNMP thresholds associated with it that enable the local address server to signal SNMP traps when certain conditions exist. These thresholds include the high utilization threshold and abated utilization threshold. If a pool's outstanding addresses exceed the high utilization threshold and SNMP trap signaling is enabled, SNMP is notified. Likewise, when a pool's utilization drops below the abated threshold utilization threshold, SNMP is notified.
As a part of this feature, the show ip dhcp-local pool command has been modified to support this feature.
In addition, the MAX-ACCESS modes of the following MIB objects have been changed from not-accessible and accessible-for-notify to read-only:
Change in existing behavior: Existing feature extended as described here.
- Generation of SNMP Traps Based on Consolidated Utilization of Addresses in DHCP Local Address Pool Groups
The DHCP local server supports the generation of SNMP traps for local address pool groups when the utilization of addresses exceeds a configured high utilization threshold or when the utilization of addresses falls below an abated or minimum threshold. The utilization of the pool group is calculated based on the addresses allocated from all the pools that are part of the group. When you configure the warning command to specify the maximum and minimum threshold for SNMP traps to be sent, these threshold values apply for the aggregated utilization of all the pools in a pool group.
For linked pools, in which one DHCP local address pool is linked and referenced by other pools, the utilization of addresses is calculated for all the pools that are in the linked pools and they are collectively considered an aggregated pool group for generation of SNMP traps. By default, the minimum threshold is 75 percent and the maximum threshold is 85 percent for SNMP traps to be triggered.
In a linked pool or a pool group, you can configure the threshold values using the warning command for only the first pool in the pool group. Default values are assumed for the other pools in the linked pool or pool group.
In the output of the show ip dhcp-local pool groups command, which displays details of configured pool groups, the High Utilization Threshold and Abated Utilization Threshold fields display the aggregated values for all the pools in the group and not for the first pool in the pool group.
As part of this feature, the dhcpLocalPool event category has been enhanced to record a message at the debug level that the threshold values of the base pool and not of the other pools are considered in the linked pool when minimum and maximum threshold values are modified for the pools in a linked pool.
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, utilization of a DHCP local address pool group was computed based on the utilization of the address in the first pool in the group, and not calculated based on the usage of addresses in all the pools in the group. SNMP traps were generated when the minimum and maximum threshold values for DHCP local address pool utilization were reached for the first pool in the group. SNMP traps were not generated based on the aggregate minimum and maximum threshold values reached for all the pools in a pool group.
TACACS
- Increased Retry Attempts for Successful TCP Connection
You can now configure the TACACS+ client retry value to establish the TCP connection with the TACACS+ server.
The retry is initiated in either of the following two cases:
The maximum retry attempt for a request is five. By default, the maximum retry value is two.
The tacacs-server retransmit-retries command has been added to support this feature.
In addition, the tcpTraffic event category has been modified to record the retry option or message.
Change in existing behavior: Existing feature extended as described here.
Unified ISSU
- Unified ISSU Support for IPv6
You can now perform unified ISSU on the router without disconnecting IPv6 subscriber connections (DHCPv6/PPPv6), without disturbing the ND entries in line modules, without disturbing the IPv6 ISSU-supported routing protocol configurations, and with minimal (30 seconds or less) traffic-outage disruption in IPv6 data plane traffic forwarding through the chassis. This feature is supported on all platforms that support unified ISSU and high availability for IPv6.
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, the IPv6 traffic forwarding outage was more than 30 seconds during unified ISSU because the dynamically learned neighbor entires are not mirrored.
- Unified ISSU Support for IS-ISv6
Unified ISSU is now supported on IS-ISv6. You can upgrade ISSU when IS-IS is configured on a router. For a successful ISSU upgrade on an IS-IS router, IS-IS graceful restart must be configured on the router.
Graceful restart ensures that the neighboring routers are notified prior to the upgrade and the routers can route around the restarting router during the upgrade. To ensure that the IS-IS neighboring routers do not timeout during the upgrade, IS-IS increases the hello-interval and hold-time to be greater than 50 seconds (if the user-configured value is lower than 50 seconds). Once the upgrade is complete, IS-IS resets the values to the user-configured value. This ensures that the neighbors are retained across SRP switchover even during an ISSU upgrade.
Change in existing behavior: Existing feature extended as described here.
- Unified ISSU Support for BGP IPv6 Address Families
You can now perform a unified ISSU operation on the router with BGP IPv6 peer sessions, with less impact on network outages. BGP sends keepalive messages to all IPv6 peer sessions before the interface contoller restart, SRP switchover, and forwarding controller restart, without depending on the configured time interval for avoiding termination of BGP peer sessions. The prerequisites to be performed before initiating the unified ISSU operation are:
The following module combinations on E Series routers support unified ISSU for BGP IPv6 address families:
- On E120 and E320 routers:
- On ERX1440 routers:
- SRP-40G Plus
- OCx/STMx/DS3-ATM line modules with 4xDS3 ATM I/O, OC12 STM4 I/O Long Haul, OC12 STM4 I/O Multi Mode, OC12 STM4 I/O Single Mode, OC3-4 I/O Long Haul, OC3-4 I/O Multi Mode, OC3-4 I/O Single Mode, 4XOC3 APS I/O Single Mode, and OC12 STM4 APS Single Mode modules
- OCx/STMx ATM line modules with 4xDS3 ATM I/O, OC12 STM4 I/O Long Haul, OC12 STM4 I/O Multi Mode, OC12 STM4 I/O Single Mode, OC3-4 I/O Long Haul, OC3-4 I/O Multi Mode, OC3-4 I/O Single Mode, 4XOC3 APS I/O Single Mode, and OC12 STM4 APS Single Mode modules
- OCx/STMx POS line modules with OC12 STM4 I/O Long Haul, OC12 STM4 I/O Multi Mode, OC12 STM4 I/O Single Mode, OC3-4 I/O Long Haul, OC3-4 I/O Multi Mode, OC3-4 I/O Single Mode, 4XOC3 APS I/O Single Mode, and OC12 STM4 APS Single Mode modules
- GE/FE line modules with GE I/O SFP module
- GE-HDE line modules with GE-8 I/O and GE-2 SFP I/O modules
- Service modules
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, ISSU support was provided only for BGP IPv4 address families.
|
Copyright © 2012, Juniper Networks, Inc. Report An Error |
|
|
