Release 4.2 Features

The following features have been added to JUNOS Release 4.2:

• Four-port Channelized DS-3 PIC--Provides high-density T1 connectivity for access aggregation. The PIC supports 28 T1 or fractional T1 channels per port.
• Nonconcatenated mode support for the OC-12 SONET/SDH PIC--Available on all platforms. Note that when you switch from concatenated mode (the default mode of operation) to nonconcatenated mode on an M20 or M40 router, you must reboot the router for the change to take effect.

  Please contact Juniper Networks customer support before deploying this feature.

   

• Four-port quad-wide Gigabit Ethernet PICs--Available in short-reach (SX) versions for the M5, M10, M20, and M40 routers.
• Four-port OC-12c SONET/SDH multimode PIC--Available on the M160 router, the four-port OC-12c SONET/SDH FPC Type 2 PIC has the same functionality as the one-port OC-12c SONET/SDH PIC, except that the PIC cannot run in nonconcatenated mode.
• New M40 Routing Engine--An optional Routing Engine for the M40 router increases processor speed and memory capacity, thus improving overall Routing Engine performance and scalability.
• Support for OC-192c SR2-B, JDSU-based optics--Available for M160 routers.
• ATM ILMI--Provides the ability to listen on the ATM ILMI VC (VC 0.16) and process incoming messages, responding to requests for the router's IP address and information about the port to which the peer node is connected.
• BGP enhancements:
  • Refresh and capability negotiation--Provides a mechanism for a router to send a message to its peers requesting them to resend their previously advertised routes. Commands have been added to display and communicate the refresh capability of a router.
  • Routing table group support--Provides the ability to install routes in both the unicast and multicast routing tables, which is especially useful when you cannot do multicast NLRI negotiation.
  • Extended communities--The range has been extended, allowing you to assign communities for many uses without having them overlap. Also support for the Type field has been added to allow you to group communities with similar needs. For example, the Type field allows routing policies to filter out all communities of a particular type or allows only certain values for a particular type of community. Previously, you could do this only by explicitly enumerating all the community values to be denied or allowed.
• Policy-based LSP selection--Allows you to control which next-hop LSP among a set of equal-cost next-hop LSPs is installed in the routing table. If the chosen next-hop LSP is not a viable next hop for the route, the next-hop LSP is chosen randomly from the ones available.
• Enhancements for redundant Routing Engines and System and Switch Boards (SSB):
  • Log file for redundant Routing Engine messages--Provides a separate log file for redundant Routing Engine log messages, in /var/log/mastership.
  • Log in to one Routing Engine while logged into the other--Provides an operational mode command, request routing-engine login, to allow you to log into the other Routing Engine.
  • Automatic failover--If the backup Routing Engine detects a loss of keepalives from the master Routing Engine, the backup Routing Engine attempts to assume mastership. This feature is disabled by default.
• Advertise LSPs into IS-IS--Provides support for advertising LSPs into IS-IS such that all participating routers can take the LSP into account when performing SPF calculations. The advertised metric is the LSP's metric; the addresses are the addresses of the LSP specified in the from and to statements. The advertisement is for SPF calculations only; that is, not for CSPF. Therefore, opaque traffic engineering LSAs are not generated, and the traffic engineering metric is set to infinity.
• Circuit cross-connect (CCC) over VLANs--Allows you to configure Ethernet interfaces and CCCs. For this feature to work, you must configure a new encapsulation type, vlan-ccc.
• Keepalive control and interval on a per-interface basis--You can now modify the keepalive interval from its default of 10 seconds, and you can modify the hold-down timer to change how long to wait before declaring an interface dead.
• Minimizing the effects of fiber cuts--You can now configure backup paths that minimize the number of shared links and fiber paths with the primary paths as much as possible, to ensure that if a fiber is cut, the minimum amount of data is lost and that a path still exists to the destination. To do this, include the configuration statement fate-sharing at the [edit routing-options] hierarchy level.
• Multiple OSPF routing instances--You can now configure multiple routing instances, each running its own OSPF instance. You can define a routing table group as a collection of routing tables from different routing instances. A routing table group can be used by OSPF to import routes learned by OSPF to all its constituent routing tables. A route so installed carries the routing instance it came from as an attribute. Export policies can filter on routing instance attributes, allowing exporting of OSPF routes learned in one instance as OSPF external into another instance.
• Send firewall log messages to a system log server--Adds the alert action modifier to the [edit firewall filter then] hierarchy level to create a firewall filter that causes entries to be logged into a system log file. That file can also be sent to a system log server.
• LSP hold time--When an LSP transitions from being up to being down, or from down to up, the transition takes effect immediately in the router software and hardware. However, when advertising LSPs into IS-IS, you might want to damp LSP transitions, thereby not advertising the transition until a certain period of time has transpired (known as the hold time). In this case, if the LSP goes from up to down, the LSP is not advertised as being down until it has remained down for the hold-time period. Transitions from down to up are advertised into IS-IS immediately. Note that LSP damping affects IS-IS advertisements of the LSP only; other routing software and hardware react immediately to LSP transitions. To damp LSP transitions, you can include the advertisement-hold-time statement at the [edit protocols mpls] hierarchy level.
• SNMP MIB enhancements:
  • Support for the Ethernet 802.3 (dot3) MIB, RFC 2665.
  • The following existing MIBs have been brought into compliance with current standards:
    • ATM MIB, RFC 2515
    • DS1 MIB, RFC 2495
    • DS3 MIB, RFC 2496
    • etherStatsTable (in RMON), RFC 2819
    • Host Resources MIB, RFC 2790
    • ifType, IANAifType-MIB
    • Interface MIB, RFC 2233
    • Remainder of MIB-II, RFCs 2011, 2012, and 2013
    • SONET MIB, RFC 2558