Previous Software Releases

Release 4.2R2

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

Software Installation

• Immediately after a software upgrade, the system configuration database, /var/db/juniper.data, might have been missing, thereby preventing the router from activating the committed configuration. A workaround was to create the /var/db/juniper.data file, enter configuration mode, and issue the commit command. [PR/10413]
• During a software upgrade, the management process might have logged errors about a database schema mismatch. These errors were cosmetic. The system operated normally after being rebooted. [PR/10618]

Platform and Forwarding

• When converting interfaces from point-to-point to multipoint and back again, the NTP process (xntpd) displayed the error message "SIOCGIFBRDADDR fails." The workaround was to restart xntpd. [PR/783]
• When you issued the ping command for an unreachable host and an ICMP unreachable message was not received, when you tried to end the session by typing Ctrl-C, the CLI stopped operating. [PR/8070]
• If you configured CCC connections on an M160 router and then took an SFM offline and back online again, the CCC connections belonging to that SFM contained incorrect next hops. This prevented the packets belonging to the affected CCC connections from reaching their destination. [PR/10464]
• If you used the traceroute command on MPLS LSPs, it might have caused random kernel panic on transit routers only. A workaround was to disable MPLS ICMP replies by typing the following command at a UNIX prompt: sysctl -w net.tag.icmpreply=0. [PR/10761]

User Interface and Configuration

• You could have configured NTP broadcast on only one address and thus on only one interface. There was no workaround. [PR/10382]
• Certain statements under configuration groups were not accepting lists of identifiers. [PR/10677]

Interfaces and Chassis

• When you unconfigured loopback mode on a SONET/SDH interface, the show interface command showed that the link flags still registered "loop detected." To clear the link flags, you had to take the PIC offline and bring it online again. [PR/9032]
• If the receive side of the protect circuit failed, APS might have malfunctioned. There was no workaround. [PR/10023]
• If you configured ATM VBR shaping rates in kilobytes, the router sometimes misread the specified values and either failed the commit or rendered the rates in units of cells rather than kilobytes. [PR/10353]
• APS did not support the exercise request. If an exercise request was received, the circuit might have been protection switched. There was no workaround. [PR/10439]
• If an ATM interface was physically disconnected from an ATM switch and you configured ILMI and committed that configuration, when you later deconfigured ILMI and attempted to commit, the router might have dumped core. The ILMI process reinitialized and was not affected. [PR/10460]
• Pressing the FPC online button multiple times could have caused multiple connection timeout requests to be queued and then subsequently overwritten. When the timers timed out, the FPC mistakenly was placed into diagnostic mode. [PR/10501]
• When you deleted a VRRP configuration from a logical interface and changed the IP address to the virtual IP address within a single commit, the router might have failed. The workaround was to delete the IP address (and the associated details) from the logical interface, commit the change, and then reconfigure the IP address with the virtual IP address and commit again. [PR/10655]
• The flow sequence number field in cflowd packets might have contained the packet sequence number instead of the flow sequence number. [PR/10670]
• When the alert option was configured for a firewall filter on the lo0 interface, system log messages might not have been sent to the remote host. [PR/10696]
• For Gigabit Ethernet interfaces only, if you configured VLAN tagging with a unit number higher than 4095, it caused an error. Unit numbers can range from 0 to 16384. [PR/10844]
• If you configured packet sampling and the number of packets sampled was large, the sampling process might have consumed large amounts of CPU time and memory. [PR/11036]
• For SONET interfaces only, a UDP port used for APS support remained open when APS was not in use. [PR/11174]
• If you installed a GE-LH PIC, which is not supported in Release 4.2 and earlier, the show chassis hardware command output not only included an entry for it, but displayed it as a GE-LX PIC. The fix removed all support for the GE-LH PIC in Release 4.2 and earlier. [PR/11610]

Simple Network Management Protocol

• The SNMP MIB process (mib2d) might have terminated unexpectedly when simultaneously processing interface changes and SNMP requests. [PR/9739]
• The MIB-II object ifOutDiscards did not increment when packets were dropped. [PR/9964]
• If you configured tunnel interfaces, such as PIM encapsulation, IP-IP, or GRE interfaces, the SNMP objects ifSpeed or ifHighSpeed should have returned zero. [PR/10399]
• The SNMP objects ifIn1SecRate and ifOut1SecRate returned values in bytes per second rather than in bits per second. [PR/10814]
• For routers with redundant Routing Engines, a Routing Engine in backup mode should not have generated BGP SNMP traps. [PR/11028]
• The enterprise Version 1 trap MIB returned incorrect OIDs for certain traps. The SNMP Version 1 traps are now in four separate enterprise MIBs, one each for BGP, OSPF, MPLS, and chassis traps. Now the enterprise ID field in Version 1 enterprise-specific traps is similar to that of the Version 2 variable binding snmpTrapID except that the last digit is put into the specific trap number. The generic trap number remains unchanged and stays as 6, indicating that it is an enterprise-specific trap. [PR/11088]
• If you had not set ifSpeed for an ATM logical interface, it should have returned the value for the main interface. [PR/11288]

General Routing

• The command show route prefix all did not show a hidden route if it was the longest match for the prefix. [PR/10549]
• When initializing itself, the routing protocol process might have logged some interface state-change messages at emergency priority. You can safely ignore these messages. [PR/10787]
• AS-path regular expressions of the form ()|N|N+1 did not commit properly. A workaround was to rewrite the expression to place the () alternation at the end: N|N+1|(). [PR/11286]

Routing Protocols

• RIP metrics did not appear in the show route command output. Also, BGP did not set its MED correctly. [PR/9617]
• In a network with a very large number of LSPs, IS-IS might have generated CSNPs that were too long. [PR/9796]
• On passive MSDP connections, blocking conditions might have occurred. [PR/10330]
• For routers with established OSPF peers, you might have received occasional authentication failures. [PR/10654]
• If you configured a route reflector and you configured an export policy to an IBGP neighbor, the routing protocol process might have dumped core. [PR/10758, PR/10759]
• The clear rip command clears RIP statistics; this command should have required clear permissions to issue it. [PR/10815]
• In a topology with redundant route reflectors for a particular route reflector client, prefixes originated by the route reflector client might have resulted in unexpected route churn between the route reflectors. If the route reflectors' router IDs were lower than the router ID of the client, the route reflectors might have preferred the path learned from the backup route reflector rather than from the route reflector client. A workaround was to configure the redundant route reflectors to use unique cluster IDs for their client clusters or configure an output delay by configuring the BGP out-delay statement. [PR/10817]
• When RIP was configured, the error message "task_receive_packet: RIP recvfrom/recvmsg: Bad file descriptor" appeared in the log file periodically if more than one RIP update packet was received at the same moment; however, RIP was working normally. This could have happened if updates from different neighbors synchronized with each other or if a neighbor sent more than one update. [PR/11041]
• In certain network topologies, the OSPF area border router might have failed to install routes or to propagate network summary LSAs. [PR/11103]
• If a RIP group name was 16 characters or more, the routing protocol process might have suddenly terminated. [PR/11110]
• If you configured RIP with many equal-cost neighbors, the routing protocol process might have consumed too much memory. [PR/11247]
• When IGMP membership changes occurred, PIM dense mode might not have updated multicast forwarding cache entries correctly. [PR/11267]
• IGMP group membership leaves were not reported to PIM correctly. [PR/11275]
• Nonconforming SAP packets might have caused the routing protocol process to terminate abnormally. [PR/11358]

MPLS Applications

• LDP sent 2 extra bytes at the end of status messages and expected other implementations to do so, causing interoperability problems. There was no workaround. [PR/10226]
• If you configured the no-cspf statement and there are multiple, equal-cost paths toward the egress router, an LSP might have blackholed traffic. [PR/10236]
• If you unconfigured an interface on one CCC connection and configured the same interface on another CCC connection, the routing protocol process might have terminated abnormally. [PR/10295]
• If you configured the no-decrement-ttl statement for an LSP, a transit router might have decremented the TTL counter anyway. [PR/10824]
• If you configured fast reroute in a topology with overlapping detours, detours might not have come up. [PR/10882]
• If you configured RSVP and no addresses were received, the routing protocol process might have dumped core every few days. [PR/11178]
• When an LSP was rerouted, the next hop was not updated. [PR/11224]
• If LSPs were advertised into IS-IS, LDP expected to see only IP next-hop addresses for routes in inet.0, causing LDP to ignore tagged next hops. Routes in inet.3 were processed correctly. [PR/11233]
• If you configured RSVP traceoptions, MPLS path names in trace messages were truncated to 15 characters. [PR/11417]