Known Behavior

This section briefly describes E-series router behavior and related issues. In some cases the behavior differs from non-E-series implementations; in others the behavior is included to emphasize how the router works.

BGP

• The E-series router does not include the link-local IPv6 address in the next-hop field of an MP-BGP update message carrying IPv6 routing information over IPv4 transport. This behavior is compliant with RFC 2545 but might have interoperability issues with other implementations that expect a link-local IPv6 address in the next-hop field on a directly connected external BGP peering.

Work-around: Enable EBGP multihop configuration on the remote (non-Juniper Networks) peer.

• The following message might be displayed under certain conditions:

bgpConnections (default,0.0.0.0): TCP error code xx (...) occurred while accepting 
inbound TCP connection 

The message is generated when an unconfigured peer attempts to establish a TCP session with an E-series router and a valid route to the source address of the peer is absent from the router's routing table.

If a valid route exists in the routing table, the following message is displayed when an unconfigured peer attempts to establish a TCP session with an E-series router; X.X.X.X is the source address of the unconfigured peer:

NOTICE 08/29/2001 16:50:11 bgpConnections (default,X.X.X.X): Inbound 
connection refused - no peer X.X.X.X configured in core

BGP/MPLS VPNs

• NAT does not function properly with secondary routing table lookup (fallback global) or global export mapping on the VRF.

B-RAS

• Pool groups are not supported; although the ip local pool group command appears in the CLI, it is not supported.

CLI

• When you issue the reload command on an ERX-310 router, the command might display a warning message that erroneously indicates that a synchronizing operation will be performed. Any references to synchronization that appear in command output or system messages do not apply to the ERX-310 router, which does not support SRP module redundancy. [Defect ID 47563]
• The following commands have been deprecated in the JUNOSe software and might be removed completely in a future release. If a command has been deprecated for only a particular command mode, the table specifies any modes for which it is still available.
  

  Deprecated Command	Command Mode	Preferred Command
  description	Interface Configuration Still available in Controller Configuration and VRF Configuration modes	ip description
  forward next-hop	Policy List Configuration	forward next-hop in Classifier Group Configuration mode
  forward next-interface	Policy List Configuration	forward next-interface in Classifier Group Configuration mode
  hostname	Domain Map Tunnel Configuration Still available in Global Configuration mode	client-name
  [ no ] ike crl	Global Configuration	[ no ] ipsec crl
  [ no ] ip inspect strict	Global Configuration	Use stateful firewall commands ip inspect [ keyword ]
  [ no ] ipsec isakmp-policy rule	Global Configuration	[ no ] ipsec ike-policy-rule
  loopback	Domain Map Configuration Still available in Controller Configuration and Interface Configuration modes	local-interface
  no ospf enable	Router Configuration	ospf shutdown
  radius disconnect client	Global Configuration The Radius Disconnect Configuration mode has been removed from the CLI.	subscriber disconnect
  show ike certificates	User Exec, Privileged Exec	show ipsec certificates
  show ike configuration	User Exec, Privileged Exec	show ipsec ike-configuration
  show ike identity	User Exec, Privileged Exec	show ipsec identity
  show ike policy-rule	User Exec, Privileged Exec	show ipsec ike-policy-rule
  show ike sa	User Exec, Privileged Exec	show ipsec ike-sa
  t1 lineCoding	Controller Configuration	None. This command never had any effect.
  tunnel mpls label-dist	Interface Configuration, Tunnel Profile Configuration	None
  virtual-router	Domain Map Configuration Still available in Privileged Exec and Global Configuration modes	router-name

  
  

The router displays a notice when you issue the command manually. If the command is in a script, the router automatically maps the deprecated command to the preferred command. If the deprecated command no longer has a function, then that command has no effect when you run a script containing the command.

• The show configuration command normally takes a long time to finish for extremely large configurations. If you specify a search string (with the begin, exclude, or include options) with the command for a string that is not present in the configuration, then the CLI session appears to be busy for a prolonged period. The CLI filtering feature for show commands does not speed up execution of the command.

Dynamic Interfaces

• Dynamic IPv6 interfaces over static PPP interfaces are not supported.

Ethernet

• When counting bits per second on a Fast Ethernet or Gigabit Ethernet interface, the E-series router includes 12 bytes for interpacket gap, 7 bytes for preamble, and 1 byte for start frame delimiter, for a total of 20 bytes (160 bits) per packet more than some non-E-series routers. This value therefore shows the total bandwidth utilization on the interface, including both data and overhead.

GRE

• When you shut down the only outgoing IP interface to the IP destinations of GRE/IP tunnels, the tunnels remain in the up state rather than transitioning to down. As a consequence, all IP routes that use these tunnels as next hops also remain in the routing table.

Hardware

• PCMCIA NVS Card Warning
  

  CAUTION: Although you can remove PCMCIA NVS (flash) cards from a running router, we recommend that you do not do so. If you remove the card while data is being written to or copied from the NVS card, data might be lost or corrupted. Therefore, we strongly recommend that you shut down the router before removing a PCMCIA NVS card.

  
  
• The 4XOC3 APS MULTIMODE and 4XOC3 APS SINGLE MODE I/O modules are incompatible with the following versions of the OCx/STMx ATM and OCx/STMx POS line modules:

• OCx/STMx ATM line modules with assembly numbers 350-00039-xx, 350-80039-xx, and 350-90039-xx
• OCx/STMx POS line modules with assembly number 350-10039-xx

• When you configure 1:5 line module redundancy by using either the 4XOC3 APS MULTIMODE or 4XOC3 APS SINGLE MODE I/O module, the spare R-Mid OCX I/O module you install must have assembly number 350-00094-01 Rev. A01 or later. Spare R-Mid OCX I/O modules with an earlier assembly number are not supported for 1:5 redundancy configurations that use either the 4XOC3 APS MULTIMODE or 4XOC3 APS SINGLE MODE I/O module.
• There is a very small chance that some line modules can have an improperly modified keying block that prevents the module from proper seating in the top slot of an older ERX-7xx chassis or a preproduction ERX-310 chassis. For example, this problem has been observed for an OCx/STMx module in slot 2 of an early-test ERX-310 chassis.

Work-around: Remove the keying block to insert the module into the top slot, or insert the module into a different slot.

• Because the FE-2 line module connects directly to its I/O module rather than to a midplane, installing one module can unseat the other module.

Work-around: Ensure that the screws fastening the I/O module to the chassis are tight to prevent separation between the modules and a resulting poor connection.

IP

• In JUNOSe versions lower than Release 5.3.0, forwarding of source-routed packets (the ip source-route command) was erroneously enabled by default in the default VR, and disabled by default in all other VRs. Beginning with Release 5.3.0, forwarding of source-routed packets is correctly disabled by default in all VRs. The incorrect setting that resides in previous versions of JUNOSe software is stored in any script (.scr) or binary (.cnf) configuration file that you create while that release is running. Consequently, if you upgrade your E-series router to Release 5.3.0 and load the configuration from the previous version, the incorrect setting is restored with the rest of the configuration. In this case, do one of the following to achieve the correct behavior (source-routed packet forwarding disabled in the default VR):

• With Release 5.2.0 or lower still running on the router, issue the no ip source-route command before you save the configuration file.
• With Release 5.3.0 or higher running on the router, issue the no ip source-route command.

• ASIC line modules can accommodate routing tables of up to 2M entries. Non-ASIC line modules are limited to 100K entries (although more routes can still work because a routing table of up to 1M entries can be compressed to 100K or fewer nonconsecutive routes). See E-series Module Guide, Chapter 1, Module Combinations, for information about which modules are ASIC and which are non-ASIC.
• When you issue the show ip forwarding-table command for a particular slot, it is normal and appropriate behavior when the Status field indicates Valid while the Load Errors field is increasing daily for that VR. The Load Errors field records any failed routing table distribution attempt as an error. Attempts can fail for many reasons during normal operation; a failed attempt does not necessarily indicate a problem. It is normal to see many load errors per day. If the Status field indicates Invalid, then the routing table distribution has failed constantly for that VR and a real problem exists. You might occasionally see a status of Updating. However, if the Status field always indicates Updating, then the routing table distribution has failed constantly for that VR, and a real problem exists.
• The enhancement to the CLI to permit unnumbered reference to any kind of interface rather than just loopback interfaces has consequences such as the following: [Defect ID 47743]

• If the references to shared interfaces appear in the show configuration output before the configuration for the interfaces they refer to, restoring such a configuration with a script generated from show configuration generates errors like the following:

% Error, line 3929:

host1(config-if)#ip share-interface FastEthernet 3/0.2

% No such interface

• Unnumbered interfaces that refer to nonloopback interfaces (for example, ip unnumbered fastethernet 3/0.2) and that appear in the show configuration output before the interface referred to might generate similar no such interface errors.

Work-around: Run the script twice.

IPSec

• When you shut down the only outgoing IP interface to the IP destinations of IPSec tunnels, the tunnels remain in the up state rather than transitioning to down. As a consequence, all IP routes that use these tunnels as next hops also remain in the routing table. You can use DPD to avoid this situation. DPD must be active, which requires both IPSec tunnel endpoints to support DPD.

L2TP

• NAT dynamic translation generation affects the LNS session creation time. When NAT dynamic translations and LNS sessions are created simultaneously, NAT dominates the TSM CPU cycles, resulting in a delay in the LNS session creation rate. The LNS session creation rate returns to its normal rate when NAT dynamic translations are no longer being generated. [Defect ID 53191]

Work-around: When signaling performance must be optimal, avoid the simultaneous configuration of NAT and LNS.

• If you create an L2TP destination profile profileName, establish tunnels with the profile, and then remove the profile, you cannot subsequently create another destination profile using that same profileName until all the tunnels drain from the previous instance of this destination profile. If you do not wait, the E-series router displays a message similar to the following:

l2tp: Discarding incoming sccrq from vr default, remote address 192.168.100.1 - 
no destination profile.

If you do not want to wait for the tunnels to drain, use a different name for the destination profile. [Defect ID 32973]

MPLS

• The E-series router does not support multiple FEC elements in a single label-mapping message, which is the default behavior for Juniper Networks M-series routers. When communicating with an M-series router that uses the default setting, an E-series router might display the following error message:

ERROR 04/09/2003 19:46:00 mplsGeneral (default): 
LDPGetFecElemsFromTlv:too many FEC Elements in TLV. Maximum number 
supported is 1.

Work-around: Use the set protocol ldp deaggregate command on the M-series router to specify that the router not include multiple FEC elements in a single label mapping.

Policy Management

• Traffic shaping is not supported on non-ASIC modules. For information about which modules are ASIC or non-ASIC, see E-series Module Guide, Chapter 1, Module Combinations.
• Multiple Forwarding Solution Rules for a Single Classifier List in a Policy

Before Release 5.2.0b1, it was possible to configure a policy with multiple rules that specified forwarding solutions where all of these rules were associated with a single classifier list. This typically was a configuration error, but the CLI accepted it. Beginning with Release 5.2.0b1, the CLI no longer accepts this configuration.

• Multiple forwarding rules behavior before Release 5.2.0b1:

• If multiple forward or filter rules were configured to reference the same classifier list in a single policy, then all rules except the first rule configured were marked as eclipsed in the show policy command display. Next-interface and next-hop rules were treated in the same manner. The eclipsed rules were not applied.
• If a policy were configured with one rule from the [forward, filter] pair and one rule from the [next-hop, next-interface] pair, and if both rules referenced the same classifier list, then no visible eclipsed marking occurred. However, these two rules were mutually exclusive, and only one of them defined the forwarding behavior. The rule action that was applied was in the order (from highest to lowest preference): next interface, filter, next hop, forward. The applied rule was the rule whose behavior was seen by forwarded packets.

For example, if a policy had both a next-interface and a filter rule, then the next interface was applied. If a policy had a next-hop and a filter rule, then the filter rule was applied.

• Multiple forwarding rules behavior for Release 5.2.0b1 and later:

Beginning with Release 5.2.0b1, the multiple rules behavior is designed so that when a forwarding solution conflict occurs within a policy, such as those described earlier, the second forwarding solution overwrites the preceding solution. That is, the last forwarding rule configured for the given classifier list within a policy is the forwarding behavior that is used. Also, a warning message is now displayed when this type of conflict occurs.

Example 1

In this example, the filter rule action overwrites the forward rule, and is therefore applied.

host1(config)#policy-list wstPolicyList

host1(config-policy-list)#forward classifier-group svaleClacl1

host1(config-policy-list)#filter classifier-group svaleClacl1

WARNING: This rule has replaced a previously configured rule.

host1(config-policy-list)#exit

host1(config)#

Example 2

In this example, three forwarding solution conflicts result in rules being overwritten. The filter rule is the last rule configured, and is therefore applied.

host1(config)#policy-list bostTwo

host1(config-policy-list)#forward classifier-group clacl5

host1(config-policy-list)#next-hop 1.1.1.1 classifier-group clacl5

WARNING: This rule has replaced a previously configured rule.

host1(config-policy-list)#next-interface atm 1/0.0 classifier-group clacl5

WARNING: This rule has replaced a previously configured rule.

host1(config-policy-list)#filter classifier-group clacl5

WARNING: This rule has replaced a previously configured rule.

host1(config-policy-list)#exit

host1(config)#

NOTE: When you upgrade the nonvolatile memory to Release 5.2.0b1 or later, the upgrade removes eclipsed rules and rules whose behavior was not applied in the previous release. This removal ensures that the postupgrade forwarding behavior is the same as the preupgrade behavior. NOTE: If you upgrade to Release 5.2.0b1 or later and then configure your router using a script generated before Release 5.2.0b1, the postupgrade and preupgrade forwarding behaviors might not be the same. The new Release 5.2.0b1 configuration behavior is applied—the last policy rule configured for a given classifier list that specifies a forwarding behavior is the only rule remaining.

POS

• The default behavior for POS interfaces was changed at Release 3.2.2 to conform with RFC 2615 so that payload scrambling (pos scramble-atm) is enabled by default; in earlier versions it was disabled by default. When you upgrade from a release numbered lower than 3.2.2 to Release 3.2.2 or higher, POS links that were configured in the lower release do not come up. You must manually change the configuration on either side of the link.

PPP

• The GE-2 line module does not support dynamic IP interfaces over static PPP interfaces when the PPPoE subinterface is also static.The OC3/STM1 GE/FE line module does not support dynamic IP interfaces over static PPP interfaces when the ATM interface column is also static.

QoS

• The qos-mode-port command supports configuration of only ATM port zero interfaces. If you upgrade from an earlier release in which you had configured QoS port mode on nonzero ports, you must access Interface Configuration mode for each of those ports and issue the no qos-mode-port command to remove the unsupported configuration.
• In Release 4.0.0 and higher releases, ATM VCs are not shaped to the configured rate if you use the atm-vc node scheduler-profile command to configure VC shaping and your QoS configuration involves ATM VPs shaped in the SAR.

This command does shape VCs correctly when you have configured the SAR for per-port queuing with the qos-mode-port command. However, per-port queuing is recommended mostly for configurations with strict-priority scheduling. You cannot issue the qos-mode-port command when you have configured the SAR for VP tunnel shaping, because the command disables all ATM/SAR shaping configurations.

Work-around: Configure shaping on the IP interface, rather than on the VC, with the ip node scheduler-profile command. The ip node scheduler-profile command is added to the new QoS profile, and any existing atm-vc node commands are left in place. The ip node scheduler-profile command is also compatible with the default mode of operation of the SAR. Using the ip node scheduler-profile command works well in configurations with one IP interface per VC, which is the case except when multiple PPPoE clients are stacked above a single VC.

SNMP

• SNMP MIBs

Information about all the SNMP MIBs (both standard and proprietary) that the router supports in this release is available in the MIBs folder on the JUNOSe Software CD.

• Some Juniper Networks SNMPv1-formatted traps contain an incorrect object identifier (OID) in the SNMPv1-Trap-PDU enterprise field. An SNMPv2 trap is typically identified by an OID that ends in the form ...x.y.z.0.n. This OID appears, in full, as the value of the snmpTrapOID.0 object in the varbind list of an SNMPv2-formatted trap. In the corresponding SNMPv1-formatted trap, this OID is broken down into subcomponents that fill the SNMPv1-Trap-PDU enterprise field (...x.y.z) and specific trap number field (n); the zero is unused.

The SNMPv1-formatted versions of the following Juniper Networks traps incorrectly contain ...x.y.z.0 in the SNMPv1-Trap-PDU enterprise field. That is, a zero is mistakenly appended to the correct enterprise OID value.

 Trap Name
 Expected Enterprise OID
 Enterprise OID Sent by SNMP Agent

 junidApsEventSwitchover

 .1.3.6.1.4.1.4874.3.2.2.1.2

 .1.3.6.1.4.1.4874.3.2.2.1.2.0


 junidApsEventModeMismatch

 .1.3.6.1.4.1.4874.3.2.2.1.2

 .1.3.6.1.4.1.4874.3.2.2.1.2.0


 junidApsEventChannelMismatch

 .1.3.6.1.4.1.4874.3.2.2.1.2

 .1.3.6.1.4.1.4874.3.2.2.1.2.0


 junidApsEventPSBF

 .1.3.6.1.4.1.4874.3.2.2.1.2

 .1.3.6.1.4.1.4874.3.2.2.1.2.0


 junidApsEventFEPLF

 .1.3.6.1.4.1.4874.3.2.2.1.2

 .1.3.6.1.4.1.4874.3.2.2.1.2.0


 juniAddressPoolHighAddrUtil

 .1.3.6.1.4.1.4874.2.2.21.3

 .1.3.6.1.4.1.4874.2.2.21.3.0


 juniAddressPoolAbatedAddrUtil

 .1.3.6.1.4.1.4874.2.2.21.3

 .1.3.6.1.4.1.4874.2.2.21.3.0


 juniAddressPoolNoAddresses

 .1.3.6.1.4.1.4874.2.2.21.3

 .1.3.6.1.4.1.4874.2.2.21.3.0


 juniDhcpLocalServerPoolHighAddrUtil

 .1.3.6.1.4.1.4874.2.2.22.3

 .1.3.6.1.4.1.4874.2.2.22.3.0


 juniDhcpLocalServerPoolAbatedAddrUtil

 .1.3.6.1.4.1.4874.2.2.22.3

 .1.3.6.1.4.1.4874.2.2.22.3.0


 juniDhcpLocalServerPoolNoAddresses

 .1.3.6.1.4.1.4874.2.2.22.3

 .1.3.6.1.4.1.4874.2.2.22.3.0


 pimNeighborLoss

 .1.3.6.1.3.61.1

 .1.3.6.1.3.61.1.0



 

Work-around: Use the OIDs that the SNMP agent sends.

Stateful SRP Switchover (High Availability)

• Additional processing is required to maintain and mirror the necessary state information that enables subscriber sessions to stay up across an SRP failover. As a result, performance of other control plane functions is reduced. Specifically, call setup rates are lower than in previous releases.
  

  NOTE: Rapid call setup rates are most important following an outage that causes all subscribers to drop, because many of the dropped subscribers immediately attempt to reconnect. This type of outage occurs far less frequently with stateful SRP switchover.

  
  

We have ongoing development activities to characterize and improve call setup rates in future releases.

• High availability remains inactive for 20 minutes after an initial cold-start or cold-restart of the router. This delay enables the system to reach a stable configuration before starting high availability.

If you want to override the 20 minute timer, turn high availability off by using the mode file-system-synchronization command, and then on again by using the mode high-availability command.

System

• In a router with a redundancy group that does not span quadrants (for example, a three-slot redundancy group that spans slots 0, 1, and 2 in a 14-slot chassis), the potential bandwidth of the redundant module is erroneously included in the quadrant bandwidth calculation. The show utilization command might indicate that the bandwidth is exceeded for modules in that group. [Defect ID 31034]
• When you copy the running configuration to NVS, the E-series router verifies whether it has available space equal to at least twice the size of the .cnf file. If the space is insufficient, you cannot complete the copy. [Defect ID 40655]

Work-around: Make sufficient space on the NVS by deleting .rel or .cnf files.

• If you upgrade the system software on a router with redundant SRP modules, the secondary SRP module does not run the new software until it reboots. If, before it is booted, you issue the srp switch command or the primary SRP module fails, the secondary SRP module runs with the old release when it takes control.
• The show version command displays how long the router has been running; it does not reflect the uptime of a particular SRP module.

System Logging

• If you enable engineering logs and set the control network logs to a level of notice or lower (down from the default of error), you might see erroneous controlNetwork log messages like the following that are generated because SNMP polling on line modules (correctly) detects no fabric: [Defect ID 43168]

NOTICE 09/01/2002 18:47:52 CEST controlNetwork (slot 11): Control Bus 
Master slave error 0x5 while accessing slot