|
|
Release Highlights
Release 11.1.0 includes the features described in this section.
Ethernet
- Support for Configuring 802.3ah OAM Link-Fault Management on Ethernet Interfaces
JUNOSe Software supports the IEEE 802.3ah standard for Operation, Administration, and Maintenance (OAM). You can configure IEEE 802.3ah OAM on Ethernet point-to-point direct links or emulated point-to-point links.
You must enable link-fault management on an interface using the ethernet oam lfm command in Interface Configuration mode to be able to configure link detection settings.
JUNOSe Software supports the following OAM functionalities:
- Discovery—Detects the devices in the network and their OAM capabilities. This process is triggered automatically when you enable OAM on the interface.
- Link monitoring—Detects and signifies link faults under various conditions using the Event Notification OAM protocol data unit (PDU), and sends events to the remote OAM entity when problems are detected on the link.
- Remote fault detection—Detects failure conditions that occur in the receive path of the link and influences the state of the link based on the Event Notification OAM PDU received from the remote peer.
- Remote loopback—Causes the interface of a local entity to receive and respond to loopback requests from remote peers. Remote loopback mode ensures link quality between the router and a remote peer.
The following line module combinations on E Series routers support the 802.3ah OAM link-fault management feature:
In addition, the following log event categories have been added to support the OAM link-fault management feature:
The following commands have been added to support configuration of OAM link-fault management:
The following commands have been added to support monitoring of OAM link-fault management:
Change in existing behavior: New feature added as described here.
ICR
- Support for Interchassis Redundancy (ICR) on ES2 10G LM and the ES2 10G ADV LM
On E120 and E320 routers, the ES2 10G LM and ES2 10G ADV LM now support interchassis redundancy (ICR). ICR enables you to recover from router failure and minimize subscriber downtime, when the router or access interface on the edge router fails, by re-creating subscriber sessions on the backup router that were originally terminated on the failed router. ICR currently supports only PPPoE subscribers.
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, ICR was not supported on the ES2 10G LM and ES2 10G ADV LM.
- Support for Fast Reconnection of PPPoE Subscribers
JUNOSe Software now supports the fast reconnection of PPPoE subscribers after an ICR failover, except when an administrator intentionally forces a failover.
After an ICR failover, when the new master router becomes active, the aggregation network forwards PPPoE data to the new master router. In lower-numbered releases, the new master router dropped these packets because a session did not exist for the PPPoE subscribers on the new master router.
Now, when receiving traffic for non-existent PPPoE sessions, the router sends early termination requests by sending PPPoE Active Discovery Termination (PADT) packets to the clients instead of waiting for the client to reconnect after the PPPoE session expires. The clients respond by sending requests to log in again. Then, the new master router creates sessions for the PPPoE subscribers..
Change in existing behavior: New feature added as described here. In lower-numbered releases, the router drops the PPPoE packets because a session did not exist for the PPPoE subscribers. This is no longer the case.
IP
- Support for Hardware Multicast Replication on ES2-S3 GE-20 IOA
Logical port 20 on the ES2-S3 GE-20 IOA is reserved for the hardware multicast packet replication feature. You can now configure logical port 20 for hardware multicast replication on the ES2-S3 GE-20 IOA.
Change in existing behavior: Existing feature extended as described here. In lowered-numbered releases, logical port 20 could not be configured for hardware multicast replication on the ES2-S3 GE-20 IOA. This is no longer the case.
L2TP over MPLS
- Support for L2TP over MPLS with ES2 10G ADV LM as Access Module
JUNOSe Software now supports configuration of L2TP over MPLS with an ES2 4G LM, ES2 10G LM, or ES2 10G ADV LM as the access module and an ES2 10G ADV LM as the uplink line module.
Change in existing behavior: Existing feature extended as described here.
MLPPP
Change in existing behavior: Existing feature extended as described here.
MPLS
- Support for Verifying Connectivity of Point-to-Multipoint LSPs at Egress Nodes
You can now use the MPLS ping and trace features, available in routers other than E Series routers, to detect data plane failures at E Series routers that function as egress nodes of point-to-multipoint LSPs.
The MPLS ping feature for egress nodes in point-to-multipoint LSPs is not supported on ES2 10G LM line modules, although these LMs support MPLS settings. This restriction occurs because ES2 10G LMs do not forward the received MPLS LSP ping packets to the SRP module on the router, which disables a response to be transmitted to the originator of the request.
As part of this feature, the mplsTraffic event log category has been enhanced to display point-to-multipoint MPLS ping and trace packets received at egress LSRs of point-to-multipoint LSPs.
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, E Series routers that were egress nodes of point-to-multipoint RSVP-TE MPLS LSPs could not respond to point-to-multipoint MPLS ping messages (echo requests) and, therefore, could not participate in verification of data-plane of point-to-multipoint RSVP-TE MPLS LSPs.
- Support for Troubleshooting MTU Failures in Point-to-Point MPLS LSPs
You can now determine the label-switched router (LSR) in a point-to-point LSP at which packets are dropped from further transmission, when the size of the packet exceeds the maximum transmission (MTU) size, and troubleshoot MTU failures.
You can use the data-size keyword with the trace mpls command for point-to-point LSPs in Privileged Exec and User Exec modes to specify the size of the MPLS ping messages (echo requests) in point-to-point LSPs associated with an IP or IPv6 address, a Martini circuit, an L3VPN IP or IPv6 prefix, an RSVP-TE tunnel, or a VPLS instance. You can specify a size in the range 0–6400 bytes; the default size is 100 bytes.
You can use the data-size keyword to determine whether MPLS packets with a particular size can be forwarded over an MPLS point-to-point LSP, when the size of the packet exceeds the MTU size at any of the LSRs that are nodes on the LSP. If you specify the packet size for MPLS echo requests, you can determine the exact LSR where the MTU size is exceeded and the MPLS packets are discarded. You can use this keyword to enable the pad TLV to be added to the MPLS LSP ping message (echo request), which results in future MPLS LSP ping echo requests to be of the same specified number of bytes.
The following commands have been enhanced to support specification of size of the MPLS ping message (echo request packet) to troubleshoot MTU problems in point-to-point MPLS LSPs:
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, you could not use the trace function of the MPLS ping feature to troubleshoot MTU problems in point-to-point MPLS LSPs.
Multiclass MLPPP
- Multiclass MLPPP Support
Multiclass multilink PPP (MLPPP) enables you to fragment data packets of different priorities into multiple classes and to send high-priority packets between fragments of larger packets. When the MLPPP bundle consists of more than one multilink interface, multilink classes ensure that high-priority data packets are received in the sequence they were transmitted.
With multiclass MLPPP each traffic class is mapped to a separate multilink class. Multiclass MLPPP supports mapping of up to eight traffic classes. The default traffic class is the best-effort class. The multiclass MLPPP feature also supports fragmentation and reassembly on the multilink classes.
As part of this feature, the following SNMP MIB objects have been added to the Juniper Networks PPP MIB:
The following SNMP MIB objects have been added to the Juniper Networks PPP Profile MIB:
The following commands have been added or enhanced to support multiclass MLPPP configuration and monitoring:
Change in existing behavior: New feature added as described here.
Packet Mirroring
- Support for Packet Mirroring Trigger
You can now trigger packet mirroring for PPP and DHCP subscribers through the following new subscriber identification methods:
You can use the mirror-enable command to configure this feature through the CLI. The DHCP Option 82 identification method is used to trigger mirroring only for DHCP subscribers. The Agent Circuit ID and Agent Remote ID identification methods are used to trigger mirroring for both PPP and DHCP subscribers.
Change in existing behavior: New feature added as described here.
Policy Management
- Support for HTTP Redirect on ES2 10G ADV LM
You can now create an exception rule within an IP policy classifier group for the ES2 10G ADV LM. The exception rule enables an application such as HTTP redirect to perform application-dependent action on the content of the packet. To create the exception rule, use the exception http-redirect command.
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, an IP policy with exception http-redirect as the action was not supported on the ES2 10G ADV LM.
- Support for IPv6 HTTP Redirect on ES2 10G LM
You can now create an exception rule within an IPv6 policy classifier group for the ES2 10G LM. The exception rule enables an application such as HTTP redirect to perform application-dependent action on the content of the packet. To create the exception rule, use the exception http-redirect command.
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, the ES2 10G LM did not support an IPv6 policy with exception http-redirect.
- Support for CAM Classifier Size of 144-Bit
You can now configure content-addressable memory (CAM) hardware classifier entries to be 144 bits for IPv6 policies on the ES2 10G LM or the ES2 10G Uplink LM. The number of 144-bit classifiers supported on the ES2 10G LM is 256K and on the ES2 10G Uplink LM is 128K.
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, the number of 144-bit classifiers supported on the ES2 10G LM was 128K and the number of 144-bit classifiers supported on the ES2 10G Uplink LM was 64K.
SDX Software and SRC Software
- Transfer of Calling Station ID to PDP
JUNOSe Software now supports sending of the calling station ID to the Policy Decision Point (PDP) for a virtual router. To enable this, use the sscc option send-calling-station-id command in Global Configuration mode.
The following command has been modified in this release:
The output of the following command has been modified in this release:
Change in existing behavior: New feature added as described here.
SNMP
- Bulk Statistics Support for QoS Schema
The bulk statistics feature now supports the QoS schema, which enables service providers to receive QoS statistics on egress queues for various interface types. Service providers can use this feature to keep track of network congestion and oversubscription by monitoring the QoS statistics and configuration information for the egress interface queues on the router.
To enable bulk statistics to export egress queue-level statistics for subscriber interfaces, you can now use the bulkstats schema subtree qos command in Global Configuration mode. To enable the export of aggregate forwarded and dropped rates of traffic over each S-VLAN or ATM VP (virtual path), include the export-summarized-stats keyword.
The output of the show bulkstats command has been updated to display information about the QoS schema.
As part of this feature, the following new MIB objects have been added to the Juniper Networks Enterprise MIB to specify the attributes for the QoS schema:
The following commands have been added or modified as part of this feature
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, you obtained queue level statistics and configuration information for all logical interfaces using the QoS MIB. This feature has been enhanced to support the export of egress queue QoS statistics for various interface types.
System
- Automatic Update of MAC Address Without SRP Switchover After SRP IOA Hot-Swap
On E120 and E320 routers, when you complete hot-swapping an SRP IOA, its MAC address in the subnet is now automatically refreshed without rebooting the SRP or the chassis. Also, you can re-insert an SRP IOA that you had taken out previously to the same network without refreshing the MAC address of the SRP IOA.
If you have configured RADIUS server on an SRP IOA that you want to replace, you can perform either of the following actions to prevent loss of accounting or logout information:
Change in existing behavior: Existing feature extended as described here. In lower-numbered releases, after you completed the hot-swap, you used the srp switch command to refresh the MAC address of the SRP IOA. Failure to refresh the MAC address resulted in MAC address conflict, which could cause disruption of applications or sessions running over the management port. This is no longer the case.
System Maximums
- Increased Number of Active Service Sessions and Active Subscriber Sessions on E120 and E320 Routers
Beginning with JUNOSe Release 11.1.0, the number of active service sessions and the number of active subscriber sessions on E120 and E320 routers have increased as follows:
- For E120 routers, the number of active service sessions increased from 131,072 to 196,608 and the number of active subscriber sessions increased from 49,152 to 64,000.
- For E320 routers, the number of active service sessions increased from 131,072 to 262,144 and the number of active subscriber sessions increased from 49,152 to 96,000.
Change in existing behavior: Existing feature extended as described here.
- Increased Number of L2TP Tunnels per Chassis on E120 and E320 Routers with SRP-320 and ES2 4G LM
The number of L2TP tunnels per chassis on E120 and E320 routers with an SRP-320 module and an ES2 4G LM has increased from 16,000 to 32,000
Change in existing behavior: New system maximums as described here.
|
Copyright © 2010, Juniper Networks, Inc. Report An Error |
|
|
