Current Software Release

The current software release is Release 4.2R3. For information about obtaining the software packages, see the Juniper Networks Web page, http://www.juniper.net/techpubs/.

For upgrade instructions, see the section "Upgrade to Release 4.2".

Resolved Issues

The following issues have been resolved since JUNOS Release 4.2R2. The identifier following the description is the tracking number in our bug database.

Platform and Forwarding

When you added and deleted large numbers of logical interfaces in quick succession, the kernel might have panicked and displayed the message: "panic: ip_ifmulticast no references". [PR/11580]
On rare occasions, a race condition within the virtual memory process in the JUNOS kernel might have caused the kernel to panic. The following message identified this condition: "vm_object_deallocate: object deallocated too many times". [PR/11665]
If you configured a system with CCC, MPLS, and Ethernet, the next-hop database on the Packet Forwarding Engine might have been corrupted. [PR/11894]
You could not have forwarded MPLS packets with two labels from an ATM permanent virtual circuit (PVC) nexthop. There was no workaround. [PR/11930]
When you removed or reinserted FPCs, the software might have become corrupted. [PR/12184]
M160 routers were experiencing kernel failures. [PR/12291]
The router might have terminated unexpectedly in periods of high memory utilization. [PR/12539]
For clients running the SSH1 protocol for data authentication and encryption, a vulnerability was discovered in the CRC-32 compensation attack detector. [PR/12577]

User Interface and Configuration

You had to log in as root on the router console to be able to copy files between the primary Routing Engine and the secondary Routing Engine. [PR/10318]
If you deactivated the first route-filter instance within a from clause, it caused all instances of route-filter to be deactivated. [PR/10752]

Interfaces and Chassis

If you configured the fxp0 interface with speed or duplex settings, it modified only the advertised capabilities that could be negotiated through the autonegotiation mechanism. The fix causes such a configuration to set the interface with that characteristic explicitly. If you specify either speed or duplex, you must specify both properties, because manually setting one results in both being manually set. [PR/7496]
If you configured the icmp-type time-exceeded statement at the [edit firewall filter filter-name term term-name from] hierarchy level to explicitly allow ICMP time-exceeded messages to pass through, the firewall filter might have blocked the messages anyway. [PR/10090]
If you configured APS and the protect router rebooted, APS might have unnecessarily switched to protect state. [PR/10944]
If you configured VLAN-CCC encapsulation on a Gigabit Ethernet or Fast Ethernet interface, issuing a commit command might have caused the interface to transition from up to down and then up again. A workaround was to explicitly set the MTU value for the interface. [PR/11572]
On SONET/SDH interfaces, Juniper Networks routers normally send out a value of 0xCC in the J0 byte. When you use SDH mode with Marconi DWDM equipment, the DWDM equipment expects a value of 0x01 and the 0xCC value caused an error. [PR/11603]
The chassis process (chassisd) might have failed to isolate defective FPCs, which could have caused the router to reset. [PR/11783]
If you configured the speed on the management interface fxp0, it would have been disabled upon reboot. [PR/11818]
The system error log on an M160 router might have filled up with the following messages: "chassisd[PID]: CHASSISD_SENSOR_REREAD: HPS 0 temperature sensor reporting 127 overtemp, rereading". [PR/12087]
When you configured a SONET/SDH interface with Point-to-Point Protocol (PPP) encapsulation and activated the interface, the system displayed SNMP_TRAP_LINK_DOWN messages. [PR/12164]
If you configured IS-IS on an interface and included configuration options in the commit, the router might have sent an improper response. [PR/12265]
If an ATM PIC and a SONET PIC shared the same FPC, configuring ATM traffic shaping on the ATM interfaces could have caused the FPC to reset. [PR/12412]
If you configured a large filter (in excess of 6000 policers, for example), it could have caused the Packet Forwarding Engine to reset. The only workaround was to use a filter with fewer terms. [PR/12442]
The Internet Processor II was not performing per-packet load balancing according to specifications. [PR/12460]
A Channelized OC-12 interface might have remained in loopback state after the remote CSU terminated a FEAC loop test. [PR/12698]

Simple Network Management Protocol

On the backup Routing Engine, the MIB object jnxOperatingState should have returned enumeration of standby(7) instead of unknown(1). [PR/11615]
If you requested multiple variable bindings in a single SNMP Get PDU request, the MIB-II object ifDescr might have corrupted data. [PR/11620]
If you performed a complete MIB walk, the MIB process (mib2d) might have dumped core at ifAlias. [PR/11795]
The ifAlias value reported for a logical interface was the ifAlias value for the logical interface's associated physical interface. [PR/12376]
MIB objects of type IpAddress were encoded incorrectly when returned in response to an SNMP Get request. A workaround was to retrieve the object using an SNMP GetNext request. [PR/12750]
ipCidrRouteIFIndex might have returned an erroneous value if the route has multiple nexthops. [PR/12771]

Routing Protocols

OSPF was setting the mask value for LSA Type 4 messages incorrectly. [PR/6599]
You could not set reference bandwidth, which is used as a scaling factor in computation of OSPF metrics, to values over 4 GB. [PR/7264]
In a system with BGP route damping enabled and many alternate paths per prefix, the routing protocol process (rpd) might have failed with a floating-point exception after you reconfigured it. [PR/8820]
On numbered point-to-point links, OSPF advertised an incorrect destination prefix length. (Conforming implementations should ignore this field, but some implementations validate it.) A workaround was to configure the interface address, rather than the interface name, under [edit protocols ospf area n.n.n.n]. [PR/9056]
If an interface went down, RIP routes learned from that interface could have remained in the forwarding table until the hold-down timer expired. [PR/11439]
On large IS-IS networks, a router might have sent out LSPs with a smaller sequence number than the purged one. This could have caused excessive IS-IS SPF calculation. [PR/11651]
The system should have displayed a virtual adjacency over an advertised LSP as "up" only if there is a reverse link in all levels on which the LSP is advertised (that is, SPF can use the LSP). Otherwise, it should have displayed the state of the adjacency as "one-way", and set the L field in the display to the levels for which a reverse link exists. [PR/11671]
If you enabled traffic engineering shortcuts in IS-IS, the routing protocol process (rpd) kept getting larger and logging "RPD_OS_MEMHIGH" messages. [PR/11687]
IS-IS adjacencies did not form over GRE interfaces that had an ISO MTU of less than 1492 bytes. This occurred if the destination of the GRE tunnel was reachable over a Fast Ethernet or Gigabit Ethernet interface. A workaround was to configure the Ethernet interface for jumbo frames. The workaround was ineffective if the Ethernet switch to which the router was connected did not support jumbo frames. [PR/11796]
OSPF did not establish adjacencies with any system that accepts larger packets than it sends (and specifies this in the MTU negotiation in OSPF). A workaround was to adjust interface MTUs accordingly. [PR/12292]
The routing protocol process (rpd) might have leaked memory at the rate of 80 bytes per minute. The only workaround was to restart rpd. [PR/12458]
IS-IS might not have installed routes when there were two routers advertising these prefixes with the same metric and the route was bring transmitted over a label-switched path (LSP). [PR/12480]
The routing protocol process (rpd) might have consumed a constant 98%of CPU utilization when there were IS-IS routes that had nexthops resolved using multiple LSPs. [PR/12509]

MPLS Applications

Even when fast reroute was working properly, the JUNOS software continued to forward user traffic after a topology break. The CSPF process (at the ingress) was unaware of this and might have torn down LSPs prematurely, causing unnecessary packet loss. [PR/5489]
When the stitching node or router served as a penultimate hop for the transmit LSP, circuit cross-connect (CCC) interfaces were unable to forward to the transmit LSP. In other words, the LSP was a single-hop LSP. [PR/11194]
When byte counter increments over an LSP are extremely large (2⁶¹ or larger), RSVP might have dumped core as a result of floating-point overflow while collecting traffic statistics. [PR/11734]
Although primary and secondary paths of the same LSP are supposed to refrain from sharing links, it was found that they might criss-cross the same links. [PR/12098]
Advertising a large amount of information into IS-IS and then withdrawing most of it might have caused the traffic engineering database to become inconsistent. This in turn caused MPLS LSP setup failures. [PR/12477]
The LDP databases might have gotten out of synchronization between two neighbors. There was no workaround. [PR/12525]
Certain fields in the show mpls lsp command output were being truncated to 16 characters. [PR/12757]

Outstanding Issues

This section lists outstanding issues with this release of the JUNOS software. The identifier following the description is the tracking number in our bug database.