|
|
Release Highlights
Release 11.2.0 includes the features described in this section.
DHCP
- Support for Controlling the Rate of Client Packets Processed by DHCP Relay
You can now limit the number of client packets sent from DHCP relay to DHCP Server. You can use the set dhcp relay max-client-packet-rate command to specify the number of client packets processed per second by DHCP relay. For example:
host1(config)# set dhcp relay max-client-packet-rate 1024The default number of client packets that are processed by DHCP relay is 4096.
The following commands have been added or enhanced to support the control of client packets forwarded from DHCP relay.
Change in existing behavior: New feature added as described here.
Documentation
- Enhanced JunosE Software Release 11.2.x and E Series Documentation
In an ongoing effort to provide our customers with a unified look across Juniper Networks documentation, we have enhanced the presentation of information for the JunosE Software Release 11.2.x and E Series documentation set.
These changes do not affect the functionality of the products. We welcome your feedback; send your comments in e-mail to techpubs-comments@juniper.net.
Change in existing behavior: New feature added as described here.
IPv6
- Duplicate IPv6 Prefix Check
You can now configure AAA to detect duplicates of IPv6 Neighbor Discovery Router advertisement prefixes and DHCPv6 delegated prefix. When a duplicate IPv6 prefix is detected, the corresponding subscriber session is terminated. You can use the aaa duplicate-prefix-check command to enable detection of duplicate IPv6 prefixes. For example:
host1(config)# aaa duplicate-prefix-check enable
The duplicate IPv6 prefix detection capability is disabled by default. You can use the show aaa duplicate-prefix-check command to check whether duplicate IPv6 prefix detection capability is enabled.
AAA does not detect duplicates of overlapping IPv6 prefixes.
The following commands have been added to support the checking of duplicate IPv6 prefixes..
Change in existing behavior: New feature added as described here.
PPP
- Support for IPCP Negotiation
During normal operation for an IPCP negotiation, if the client does not request a specific IP address, the server sends an IP address obtained from RADIUS or from the local address pool.
If the client seeks a specific IP address, on receiving NAK from the server, it sends a confReq message without specifying the IP address option. In this case, even though the server returns an IPCP confAck message, the server terminates the client because the server requires an IP address from the client.
You can now use the ppp peer-ip-address-optional command in Global Configuration mode to specify that the peer IP address is optional, which results in successful IPCP negotiation.
Change in existing behavior: New feature added as described here.
PPPoE
- Support for PPPoE Sessions with Duplicate MAC Addresses That Contain the IWF Attribute
JunosE Software now supports interworking function (IWF) PPPoE sessions with duplicate MAC addresses. Although duplicate protection of PPPoE sessions with the same MAC address enables prevention of unauthorized access to resources, there might be scenarios in interworked PPPoE sessions in which multiple sessions that originate from the same MAC address are required to access to network services and applications. In this release, you can enable multiple PPPoE sessions with the same MAC address that contain the IWF tag to be established. This feature is useful for IWF PPPoE sessions because of a number of such sessions contain the same MAC address of the DSLAM at which multiplexing and conversion functions are performed.
When the duplicate protection feature is enabled by using the pppoe duplicate-protection command in Profile Configuration or Subinterface Configuration mode, IWF PPPoE sessions that contain duplicate MAC addresses are still processed and can access network services until the maximum number of PPPoE sessions configured per major interface (configured using the pppoe sessions command) is reached.
As part of this feature, the pppoe logging event category has been modified to record information at the debug severity level when multiple PPPoE sessions with the same MAC address and containing the IWF-Session VSA in the PPPoE active discovery request (PADR) packets are configured.
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, protection of PPPoE sessions with duplicate MAC addresses could not be enabled for IWF PPPoE sessions because IWF sessions use the same source MAC address of the DSLAM for all subscriber connections. The duplicate protection feature permitted only one PPPoE session per source MAC address because the uniqueness of the PPPoE client was determined by the client's MAC address.
- Support for Encapsulation Type Lockout Based on DSL Forum VSAs for IWF PPPoE Sessions
JunosE Software now supports the dynamic encapsulation type lockout functionality for PPPoE sessions that contain the IWF-Session DSL Forum VSA (26-254) in the PPPoE active discovery request (PADR) packets. For IWF sessions that involve a set of functions to be processed to interconnect two networks of different technologies (such as PPPoE over ATM to PPPoE), the encapsulation type lockout for the PPPoE clients associated with the dynamic PPPoE subinterface column on the PPPoE major interface is determined using a combination of the Agent-Circuit-Id (26-1) and Agent-Remote-Id (26-2) DSL Forum VSAs, in addition to the MAC address. Dynamic encapsulation type lockout is enabled by default for all IWF PPPoE sessions.
The behavior of the following commands has changed to support encapsulation type lockout for IWF sessions based on DSL Forum VSAs:
- pppoe auto-configure lockout-time—When you enter this command in Interface Configuration mode or Subinterface Configuration mode to configure dynamic encapsulation type lockout, even if PPPoE sessions associated with a particular MAC address are locked out, other PPPoE sessions that originated with the same MAC address are not terminated (continue to remain logged in) if they are IWF sessions from different access loops (PPPoE clients) and this information is available to the B-RAS application.
- pppoe clear lockout interface—When you enter this command in Privileged Exec mode, the encapsulation lockout condition is cleared for all IWF PPPoE sessions whose source MAC address matches the MAC address specified in the command. In lower-numbered releases, issuing this command cleared the lockout condition only for one PPPoE session associated with a specific MAC address.
In addition, the output of the show pppoe interface lockout-time command now displays multiple entries for the same MAC Address if multiple IWF sessions contain the same MAC address.
As part of this feature, the pppoe logging event category has been modified to record information at the debug severity level whenever a PPPoE session with the IWF-Session VSA included in the PADR packets is established and terminated.
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, the PPPoE dynamic encapsulation type lockout functionality uses the MAC address as the only attribute to identify a subscriber whose session needs to be locked out. In this release, for PPPoE sessions with the IWF-Session DSL Forum VSA in the PADR packet from clients, the dynamic encapsulation lockout feature uses the Agent-Circuit-Id and Agent-Remote-Id DSL Forum VSAs, in addition to the MAC address, to uniquely distinguish the subscriber whose PPPoE session needs to be locked out.
System
- Support for Real-Time Optical Power Output Display and Predictive Failure Identification
The small form-factor pluggable transceivers (SFPs) and 10-gigabit small-form pluggable transceivers (XFPs) that comply with SFF-8472 now support the opportunity to monitor real-time transmitted optical power, received optical power, and predictive failure identifications due to laser degradation by external conditions. You can assess the the current operation conditions of the local transceivers by real-time monitoring the transmitted and received optical power. You can also monitor any degradation in power levels through SNMP traps and log messages, which are triggered when the transmitted or received power breaches the threshold limit. Thus, the management support helps in predictive link failure identification, which allows a host to identify potential link problems before system performance is impacted.
The output of the show interfaces command has been updated to display the real-time transceiver optical power.
Change in existing behavior: New feature added as described here.
Tunneling
- Tunnel-Server Support on 10G ADV LM
The E120 and E320 routers now support the ES2-S1 Service IOA and ES2 10G ADV line module (LM) combination. To provide 10 gigabit bidirectional throughput support, JunosE Software now supports the tunnel-server feature on the ES2 10G ADV LM.
The ES2 10G ADV LM supports two types of tunnel-server ports: dedicated and shared. The following table describes the supported and unsupported applications available on the ES2 10G ADV LM:
Shared tunnel server on the ES2 10G ADV LM supports line module redundancy. You can configure the ES2 10G ADV LM to provide shared tunnel-server functionality or forwarding functionality. However, both the primary and the redundant line modules must provide identical functionality.
You can use the existing shared server configuration commands for the ES2 10G ADV LM. Additionally, you can also reserve a percentage of the total available resources for forwarding on shared ports, by using the reserve-bandwidth command.
The following commands have been added or updated as part of this feature:
NOTE: Only the ES2 10G ADV LM supports the tunnel-server feature and not the ES2 10G LM or the ES2 10G Uplink LM.
Shared tunnel server on the ES2 10G ADV LM supports Generic Routing Encapsulation (GRE) tunnels for tunneling the mirrored data packets. The mirrored data is forwarded to the analyzer device using the GRE analyzer interface. Use the ip analyzer command to configure the GRE tunnel interface to act as as a GRE analyzer tunnel interface. The ES2 10G ADV LM does not support non-analyzer tunnel interfaces. Also, when you configure a GRE interface for checksum calculations, use of sequence numbers, session keys, and other optional parameters, the ES2 10G ADV LM does not support those GRE interfaces. However, if you have configured a non-analyzer tunnel interface or a GRE interface with optional parameters, these interfaces remain non-operational. The GRE analyzer interface forwards mirrored traffic and drops all non-mirrored traffic.
Also, placement of GRE tunnels on the supported locations is no longer synchronous with the tunnel configuration. So, you can configure tunnel servers when the chassis does not support the required resources such as shared tunnel server ports or tunnel server modules. However, the configured tunnels are non-operational. The tunnels become operational when the required resources are added to the chassis.
NOTE: The ES2 10G ADV LM dedicated tunnel server does not support GRE interfaces and line module redundancy.
If a chassis has shared or dedicated tunnel server on the ES2 4G LM and shared tunnel server on the ES2 10G ADV LM, the GRE non-analyzer tunnel interfaces are available on the ES2 4G LM. Only GRE analyzer interfaces with no optional configurations are available on the ES2 10G ADV LM shared tunnel server.
NOTE: Dedicated and shared tunnel servers do not support QoS profiles on interfaces stacked on the server-port.
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, support for shared server ports was only available on the ES2 4G LM. Also, placement of GRE tunnels on the supported locations was synchronous with the tunnel configuration. This is no longer the case.
- Support for Termination of an L2TP Session on a Dedicated Tunnel Server Port Configured on an ES2 10G ADV LM
The E Series router supports the termination of remote access subscribers connected using an L2TP tunnel. This feature is now supported on an ES2 10G ADV LM.
An ES2 10G ADV LM and Service IOA combination provides a dedicated tunnel server. You can now terminate this dedicated tunnel-server session for an L2TP LNS configured on an ES2 10G ADV LM.
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, the termination of an L2TP session on a dedicated tunnel-server port was supported only when configured on the ES2 4G LM.
|
Copyright © 2010, Juniper Networks, Inc. Report An Error |
|
|