JunosE 15.1.1 Release Notes

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.

AAA

• Although you can use the max-sessions command to configure a maximum of 32,000 outstanding authentication or authorization requests to a RADIUS server, AAA internal limits prevent the actual number of outstanding authentication or authorization requests from exceeding 9600. These internal AAA limits apply only to authentication or authorization requests and not to accounting requests.
• The JunosE Software does not support accounting for ATM 1483 subscribers. The atm1483 keyword for the aaa accounting default command is present in the CLI, but not supported.
• Incorrect and non-existent information is displayed in the output of the show subscribers summary command when an SRP module comes back online after a stateful SRP switchover. This problem occurs with subscribers that are allocated prefixes by using DHCPv6 Prefix Delegation and with the virtual router name not returned from the AAA domain map, in the RADIUS-Access-Accept message from the RADIUS server, or from the DCM profile. In such a case, the output of the show command displays virtual router details, although the virtual router name (default) is not returned from the AAA domain map, RADIUS server, or the DCM profile.
• In a dual-stack network with subscribers that are connected using static PPP interfaces and with QoS profiles associated with these interfaces, the output of the show qos-profile references command does not display the QoS profiles attached to the interfaces for IPv4 subscribers. The attached QoS profiles for IPv6 subscribers alone are displayed. This behavior is expected if you configured the QoS profile to be attached to an interface using the QoS-Profile-Name VSA attribute [26-26] that is returned from the RADIUS server by specifying the radius include qos-profile-name command.

ATM

• You cannot configure connection admission control (CAC) on an ATM interface on which you have created a bulk-configured virtual circuit (VC) range for use by a dynamic ATM 1483 subinterface. Conversely, you cannot create a bulk-configured VC range on an ATM interface on which you have configured CAC. The router rejects these configurations, which causes them to fail.

Configuring CAC and bulk-configured VCs on the same ATM interface was supported in previous JunosE Software releases. As a result, If you are upgrading to the current JunosE release from a lower-numbered release, configurations that use CAC and bulk configuration on the same ATM interface continue to work. However, we recommend that you disable CAC on these ATM interfaces to ensure continued compatibility with future JunosE releases.

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 depend on 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

• In a scaled environment, we recommend that you increase the hold timers for the following protocols to appropriate values, based on the level of complexity of the network and scaling settings, so as to enable graceful restart to be completed successfully. [Defect ID 184974]
• BGP
• IS-IS
• LDP
• OSPF
• RSVP

For a sample configuration scenario that illustrates how to configure hold timers for successful graceful restart in a scaled environment, see JunosE BGP and MPLS Configuration Guide, Chapter 1, Configuring BGP Routing.

• 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.
• If the router is under a heavy load, the show profile command might take longer than usual to execute.

Work-around: You can either delay examination of profiles until the router is less busy, or save a copy of the profile to a text file off the router.

CLI

• When you specify the show interfaces interfaceType interfaceSpecifier command, if you not leave a space between the interfaceType and the interfaceSpecifier options, the command processes correctly and displays the settings configured on the corresponding interface. For example, if you enter the show interfaces gi2/0/0 command, which denotes a Gigabit Ethernet interface on slot 2, adapter 0, and port 0, the system validates this command accurately and considers this command to be the same as show interfaces gi 2/0/0. Similarly, if you specify the show interfaces l2tp members command, the system analyzes the "l2tp" string to denote a LAG interface with a name of "2tp".

This method of processing of the interface names occurs because the system processes the letters in the interface name until it encounters an integer. The string of characters in the interface name is mapped to a valid interface type, if a match exists, and the remainder of the name is treated as the interface specifier. This behavior is expected when you specify the interface type and specifier options in the show interfaces command without a space separating the two options.

• In Interface Configuration mode for a major interface, the CLI displays options for protocols that are not supported by that interface type.
• When you issue the reload command on an ERX310 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 ERX310 router, which does not support SRP module redundancy.
• 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
  aaa accounting interval	Global Configuration	aaa service accounting interval and aaa user accounting interval
  cablelength short	Controller Configuration
  clock rate	Interface Configuration
  channel-group description	Controller Configuration
  channel-group shutdown	Controller Configuration
  channel-group snmp trap link-status	Controller Configuration
  channel-group timeslots	Controller Configuration
  classifier-list	Global Configuration	ip classifier-list
  color	Policy List Configuration	color in Classifier Group Configuration mode
  controller e1	Global Configuration
  controller t1	Global Configuration
  description	Interface Configuration Still available in Controller Configuration and VRF Configuration modes	ip description
  fdl	Controller Configuration
  fdl carrier	Controller Configuration
  fdl string	Controller Configuration
  fdl transmit	Controller Configuration
  filter	Policy List Configuration	filter in Classifier Group Configuration mode
  forward next-hop	Policy List Configuration	forward next-hop in Classifier Group Configuration mode
  forward next-interface	Policy List Configuration	forward interface in Classifier Group Configuration mode
  hostname	Domain Map Tunnel Configuration Still available in Global Configuration mode	client-name
  hssi description	Interface Configuration
  hssi force dte acknowledge	Interface Configuration
  hssi internal-clock	Interface Configuration
  ignore dcd	Interface Configuration
  ignore link-state-signals	Interface Configuration
  [ no ] ike crl	Global Configuration	[ no ] ipsec crl
  interface hssi	Global Configuration
  invert tx clock	Global Configuration
  ip dhcp-local cable-modem	Global Configuration	set dhcp-relay with the strings docsis and pktc in the server-string mapping specification
  ip mirror	Global Configuration	ip policy secure-input and ip policy secure-output; for E120 and E320 routers, you must use these commands because the ip mirror command has been removed from the CLI for those routers.
  ip policy local-input	Interface Configuration, Profile Configuration	None
  [ no ] ipsec isakmp-policy rule	Global Configuration	[ no ] ipsec ike-policy-rule
  ipv6 policy local-input	Interface Configuration, Profile Configuration	None
  j1	Controller Configuration
  license l2tp-session	Global Configuration	None
  lineCoding	Controller Configuration
  log	Policy List Configuration	log in Classifier Group Configuration mode
  log severity debug dhcpLocalProtocolDecode	Global Configuration	log severity debug dhcpCapture
  loopback	Domain Map Configuration Still available in Controller Configuration and Interface Configuration modes	local-interface
  loopback remote { remote line fdl ansi | remote line fdl bellcore | remote line inband remote payload [ fdl ] [ ansi ] }	Controller Configuration
  mark	Policy List Configuration	mark in Classifier Group Configuration mode
  mark-de	Policy List Configuration	mark-de in Classifier Group Configuration mode
  mark-exp	Policy List Configuration	mark-exp in Classifier Group Configuration mode
  mark-user-priority	Policy List Configuration	mark-user-priority in Classifier Group Configuration mode
  mpls ldp discovery transport-address	Interface Configuration	This command has no effect in Interface Configuration mode. Now available in Global Configuration mode.
  mpls topology-driven-lsp ip-interfaces	Global Configuration	ldp ip-forwarding
  [ no ] next-hop	Policy List Configuration	forward next-hop in Classifier Group Configuration mode
  [ no ] next-interface	Policy List Configuration	forward interface in Classifier Group Configuration mode
  nrzi-encoding	Interface Configuration
  no ospf enable	Router Configuration	ospf shutdown
  policy-list	Global Configuration	ip policy-list
  radius disconnect client	Global Configuration The RADIUS Disconnect Configuration mode has been removed from the CLI.	subscriber disconnect
  rate-limit-profile	Policy List Configuration	rate-limit-profile in Classifier Group Configuration mode
  remote-loopback	Controller Configuration
  router-name	Domain Map Configuration Still available in Tunnel Group Tunnel Configuration mode	auth-router-name and ip-router-name in Domain Map Configuration mode
  show controllers t1/e1	User Exec, Privileged Exec
  show controllers t1 remote	User Exec, Privileged Exec
  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
  show ip dhcp-external binding	Privileged Exec	show dhcp binding
  show ip dhcp-external binding-id	Privileged Exec	show dhcp binding
  show ip dhcp-local binding	Privileged Exec	show dhcp binding
  show ip dynamic-interface-prefix	Privileged Exec, User Exec	None
  show ip mirror interface	Privileged Exec	show secure policy-list
  show license l2tp-session	User Exec, Privileged Exec	None
  t1 lineCoding	Controller Configuration	None. This command never had any effect.
  traffic-class	Policy List Configuration	traffic-class in Classifier Group Configuration mode
  tunnel mpls label-dist	Interface Configuration, Tunnel Profile Configuration	None
  tunnel mpls autoroute announce bgp	Interface Configuration, Tunnel Profile Configuration	None
  unframed	Controller Configuration
  user-packet-class	Policy List Configuration	user-packet-class in Classifier Group Configuration mode
  virtual-router	Domain Map Configuration Still available in Privileged Exec and Global Configuration modes	auth-router-name and ip-router-name in Domain Map Configuration mode
  yellow	Controller Configuration

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.

DHCP

• Configuring authentication on the DHCP local server requires that you first disable the DHCP local server for standalone mode. Doing so removes your entire DHCP local server configuration. Therefore, if you want to configure authentication, do so before you have otherwise configured the DHCP local server.
• When you upgrade from a release numbered lower than Release 7.1.0, all DHCP host routes previously stored in NVS are deleted. After the upgrade, DHCP clients must reacquire their IP addresses, which results in the new host routes being correctly stored in NVS.
• Normally, the interface controller of a DHCP local server processes a renewal request received from a DHCP client and responds with a renewal acknowledgement. This acknowledgement is unicast directly to the DHCP client by using the ARP. In a scenario where the DHCP client is in a different subnet, a neighboring router acts as a relay between the local server and the client. If the proxy ARP is disabled in this neighboring router, then the renewal acknowledgement is dropped at the egress forwarding controller of the local server because of ARP failure. [Defect ID 91318]

DHCP External Server

• When the DHCP relay agent application and the DHCP external server application are configured in the same virtual router, using the ip dhcp-external server-sync command on an unnumbered IP interface does not function as expected. When you issue the ip dhcp-external server-sync command in this configuration to create subscriber state information based on lease renewals when the external DHCP server and the router are unsynchronized, the router does not forward the ACK request from the DHCP server to the client because there is no route. [Defect ID 88562]
• When a bound DHCP client on a dynamic subscriber interface extends its IP address lease by restarting the DHCP discovery process on its primary IP interface instead of by initiating the DHCP renewal process on its dynamic subscriber interface, the default behavior of the DHCP external server application to preserve the client's dynamic subscriber interface was changed in the following JunosE releases to delete and re-create the client's dynamic subscriber interface:
• Release 7.2.4p0-4 and all higher-numbered 7.2.x releases and patch releases
• Release 7.3.4 and all higher-numbered 7.3.x releases and patch releases
• Release 8.0.4 and all higher-numbered 8.0.x releases and patch releases
• Release 8.1.2 and all higher-numbered 8.1.x releases and patch releases
• Release 8.2.3 and all 8.2.3 patch releases
• Release 9.0.0 and all 9.0.0 patch releases
• Release 9.0.1 and all 9.0.1 patch releases
• Release 9.1.0 and all 9.1.0 patch releases

If you are upgrading the JunosE Software on the router from any of these releases, you must explicitly issue the ip dhcp-external recreate-subscriber-interface command to configure the router to continue to delete and re-create the DHCP client's dynamic subscriber interface.

Informational Note: The DHCP external server application is unsupported in JunosE Release 8.2.1 and JunosE Release 8.2.2.

• The DHCP external server may not be able to bind all DHCP clients when all of the following conditions exist:
• The DHCP external server and either DHCP relay or relay proxy are configured in separate virtual routers on an E320 router.
• The client-facing and server-facing interfaces for the DHCP external server and either DHCP relay or relay proxy are configured on the same ES2 4G LM.
• The DHCP external server is configured to create dynamic subscriber interfaces.

When these three conditions exist simultaneously, the ES2 4G LM may not be able to successfully process all DHCP packets. Although all clients may get bounded in DHCP relay or relay proxy, some clients may not get bounded in DHCP external server. (In a production environment, it is highly unlikely for conditions 1 and 2 to exist because standalone DHCP external server is normally configured for a DHCP relay in a different chassis.)

Work-around: You can eliminate this issue by modifying any one of these conditions. For example, this issue does not exist with any of the following configuration modifications:

• Configure the DHCP external server and either DHCP relay or relay proxy in the same virtual router.
• Configure the client-facing and server-facing interfaces for the DHCP external server and either DHCP relay or relay proxy on the same ES2 10G LM instead of the same ES2 4G LM.
• Configure the client-facing and server-facing interfaces for the DHCP external server and either DHCP relay or relay proxy on separate ES2 4G LMs.

Dynamic Interfaces

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

Ethernet

• The hashing algorithm that selects the LAG member link is associated with the IP address of the subscriber client to support QoS. Consequently, a particular flow is always hashed to the same link. When a member link is removed from a LAG bundle, traffic rate is disrupted and traffic flow is reduced. When the link goes down and then comes back up, the traffic flow is automatically redistributed.
• When counting bits per second on a Fast Ethernet or Gigabit Ethernet interface, an 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.
• To bridge unicast known-DA packets at line rate on both 2-Gbps ports of the GE-2 line module or the GE-HDE module when paired with the GE-2 SFP I/O module, the minimum packet size must be at least 144 bytes.

When installed in the ERX1440 router, the GE-2 module delivers full bandwidth of 4 GB per line module (2 GB at the ingress and 2 GB at the egress) only when installed in slot 2 or slot 4, and when the SRP-40G+ module is used in the router. When installed in any other ERX1440 slot, the GE-2 module delivers a maximum bandwidth of 2 GB per line module (1 GB maximum at the ingress and 1 GB maximum at the egress). Therefore, of the maximum 24 possible ports for the module in an ERX1440 chassis (that is, two ports in each of 12 slots), full bandwidth is delivered only on a maximum of four ports (those in slots 2 and 4).

When installed in the ERX1440 router, the GE-HDE line module delivers full bandwidth of 4 GB per line module (2 GB at the ingress and 2 GB at the egress) only when installed in slot 2 or slot 4, and when the SRP-40G+ module is used in the router. When installed in any other ERX1440 slot, the GE-HDE module delivers a maximum bandwidth of 2 GB per line module (1 GB maximum at the ingress and 1 GB maximum at the egress). Therefore, of the maximum 96 possible ports for the module in an ERX1440 chassis (that is, 8 ports in each of 12 slots), full bandwidth is delivered only on a maximum of 16 ports (those in slots 2 and 4).

When the GE-2 line module or the GE-HDE line module is installed in either the ERX1440 router or the ERX310 router and both ports are active, line rate performance is achieved only with packets that are 174 bytes or larger. The line module might not achieve line rate with packets that are smaller than 174 bytes.

• Support for the 0x9200 S-VLAN Ethertype has been removed. You can no longer specify the 9200 option with the svlan ethertype command.

When you upgrade to Release 7.1.0 or a higher-numbered release, the software automatically transfers existing configurations that use the 0x9200 Ethertype to the 0x88a8 Ethertype.

• The show interfaces gigabitEthernet command output does not display the following line of output for Gigabit Ethernet modules that do not support SFPs, such as the GE Single Mode I/O module and GE I/O Multi Mode I/O modules:
Primary/Secondary link signal detected
Primary/Secondary link signal not detected

Flash

• Flash cards manufactured by Wintec are present on some currently deployed routers. When you upgrade the JunosE Software on such routers, the firmware on the flash card controller is automatically updated during diagnostics. During this reboot, the software runs an integrity check on the file system to verify that the firmware update did not corrupt the contents of the flash card. This integrity check is an expected side effect of the enhanced firmware available in this release. The integrity check does not indicate a problem with the flash card or its contents.

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

• SRP modules with only 1 GB of memory do not work reliably in ERX7xx and ERX14xx routers running JunosE Release 8.1.0 or higher-numbered releases, and may experience system resets due to an out-of-memory condition. However, the ERX310 router still supports 1 GB of memory in the SRP-SE10 module.

Work-around: Upgrade your SRP module memory to 2 GB for all ERX7xx and ERX14xx routers running JunosE Release 8.1.0 or higher-numbered releases.

• Do not include a not protocol clause in any classifier control list for policies attached to an interface on an ES2 10G Uplink LM. The not protocol functionality is not available for this module.
• PCMCIA NVS Card Caution

  Caution: Before you insert or remove PCMCIA NVS (flash) cards from a running router, we strongly recommend that you halt the SRP module or shut down the router. Failure to do this can result in file corruption in one or both cards.

• 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 ERX7xx chassis or a preproduction ERX310 chassis. For example, this problem has been observed for an OCx/STMx module in slot 2 of an early-test ERX310 chassis.

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

HDLC

• By design, on the cOC12/STM4 module you cannot delete a serial interface while data for the interface is still enqueued. The enqueued data can drain only when the interface is operationally up. Therefore you must ensure that the interface is operationally up before you delete it. For example, if you have issued the shutdown command for the interface before you try to delete the interface, issue the no shutdown command, then delete the interface.

IP

• If you enable detection of duplicate IPv6 prefixes using the aaa duplicate-prefix-check command, and bring up a subscriber in a dual-stack network (in which both IPv4 and IPv6 subscribers are present) over a static PPP interface for which an IPv6 prefix is configured for IPv6 Neighbor Discovery router advertisements (using the ipv6 nd prefix-advertisement ipv6Prefix command), the subscriber session is successfully brought up. When you attempt to bring up another subscriber over a different interface on the same virtual router as the one used for the first subscriber, and for which the Ipv6-NdRa-Prefix (VSA 26-129) returned from the RADIUS server in the Access-Accept message is the same IPv6 prefix as the statically configured value for the first subscriber, the second subscriber session is also brought up and not disconnected as expected.

In such a scenario, the duplicate IPv6 prefix detection functionality does not cause the second subscriber session, which uses the same IPv6 prefix as the first subscriber session, to be rejected. Also, a new IPv6 route is installed for the second subscriber as a duplicate access-internal route. [Defect ID 187264]

• When you upgrade from certain releases to JunosE Release 9.2.0p1-0 or higher-numbered releases, descriptions configured for IP interfaces or IP subinterfaces are not retained across the upgrade when the descriptions are shorter than nine characters in length. Additionally, VRF descriptions are not retained across the upgrade when the combined length of the VRF description and the VRF name is shorter than nine characters. This behavior is seen during upgrades using a reload, stateful SRP switchover, or unified ISSU. Upgrades from the following releases are affected by this behavior:
• 7.x.x
• 8.0.x
• 8.1.x, 8.2.x, and 9.x.x builds created before July 23, 2008

Examples of descriptions that are not retained across the upgrade:

host1(config-if)#ip description 12345678

host1(config)#ip vrf 123

host1(config-vrf)#description 45678

Examples of descriptions that are retained across the upgrade:

host1(config-if)#ip description longdescription

host1(config)#ip vrf longername

host1(config-vrf)#description 45678

host1(config)#ip vrf 123

host1(config-vrf)#description longdescription

Work-around: Before you upgrade from an affected release to JunosE Release 9.2.0p1-0 or higher-numbered releases, ensure that you do the following:

• Change IP interface and subinterface descriptions to nine or more characters.
• Change VRF descriptions, VRF names, or both so that the combination of associated VRF names and descriptions consists of nine or more characters.
• The ip tcp adjust-mss command, which modifies the maximum segment size for TCP SYN packets traveling through the interface, is not supported on the ES2 10G LM or ES2 10G Uplink LM.
• If you have enabled ipInterface logging at a priority of debug, the acknowledgment that an interface has been deleted from the line modules can return to the SRP module after the layers beneath IP have deleted their interfaces. Consequently, the original name of the interface cannot be resolved or displayed in the log, and the system instead displays the ifIndex of the IP interface. This behavior has no functional effect other than that the log is misleading. However, previous log events indicate that the interface deletion was beginning.
• When you want to use a configuration script to configure IP shared interfaces that reference a physical interface, you must issue the service show configuration format 2 command before you generate the script. If the default show configuration format (format 1) is enabled instead, the generated script cannot properly configure the IP shared interfaces because they are created before the physical interfaces. To properly configure the shared interfaces in this event, run the generated format 1 script twice.
• 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 again the routing table distribution has failed constantly for that VR and a real problem exists.
• The enhancement to the CLI to support 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, trying to restore 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 dead keepalive detection (DPD) to avoid this situation. DPD must be active, which requires both IPsec tunnel endpoints to support DPD.

IS-IS

• When IS-IS is configured on a static PPP interface, the IS-IS neighbor does not come up if you remove the IP address from the interface and then add the IP address back to the interface.

Work-around: When you remove and add back the IP address, you must also remove the IS-IS configuration from the interface and then add the configuration back to the interface by issuing the no router isis and router isis commands.

• When you run IS-IS on back-to-back virtual routers (VRs) in an IS-IS-over-bridged-Ethernet configuration and do not configure different IS-IS priority levels on each VR, a situation can occur in which both VRs elect themselves as the designated intermediate system (DIS) for the same network segment.

This situation occurs because the router uses the same MAC address on all bridged Ethernet interfaces by default. When both VRs have the same (that is, the default) IS-IS priority level, the router must use the MAC address assigned to each interface to determine which router becomes the DIS. Because each interface in an IS-IS-over-bridged-Ethernet configuration uses the same MAC address, the router cannot properly designate the DIS for the network segment. As a result, both VRs elect themselves as the DIS for the same network segment, and the configuration fails. [Defect ID 72367]

Work-around: To ensure proper election of the DIS when you configure IS-IS over bridged Ethernet for back-to-back VRs, we recommend that you use the isis network point-to-point command in Interface Configuration mode to configure IS-IS to operate using point-to-point (P2P) connections on a broadcast circuit when only two routers (or, in this case, two VRs) are on the circuit. Issuing this command tears down the current existing IS-IS adjacency in that link and reestablishes a new adjacency.

L2TP

• L2TP peer resynchronization enables an L2TP failed endpoint to resynchronize with its peer non-failed endpoint. The JunosE Software supports failover protocol and silent failover peer resynchronization methods. If you configure the silent failover method, you must keep the following considerations in mind:
• PPP keepalives—To ensure resynchronization of the session database, PPP keepalives must be enabled on the L2TP data path. Without PPP keepalives, silent failover might disconnect an established session if there is no user traffic during failover recovery.
• Asymmetric routes on different line modules—Asymmetric routes whose receive and transmit paths use I/O paths on different line modules can result in improperly handled line module control packets. If your network does include this type of asymmetric route, tunnels using these routes might fail to recover properly.
• NAT dynamic translation generation affects the LNS session creation time. When NAT dynamic translations and LNS sessions are created simultaneously, NAT dominates the CPU cycles of the tunnel-service module, 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.

LDP

• The LDP database can maintain up to 250 neighbors if you configure the hello and dead intervals (or hold timers) for IGP, such as OSPF or IS-IS, to be higher than their default values. If you set the hello and dead intervals (or hold timers) at their default values, the LDP neighbors start flapping (constantly go up and down) when more than 200 LDP neighbors are present.

Line Module Redundancy

• On E120 routers and E320 routers, redundant IOAs have a temperature sensor, and the show environment all command lists the temperature of IOAs in their associated slots.

On ERX routers, redundant I/O modules do not have a temperature sensor. Therefore, the show environment all command output lists the primary I/O module temperature in the slot of the line module that is responsible for the I/O module.

MLPPP

• Do not configure both MLPPP fragmentation (with the ppp fragmentation command) and IP fragmentation of L2TP packets (with the ip mtu command) on the same interface. Instead, you must choose only one of the fragmentation configurations by setting it to the necessary value and set the other fragmentation configuration to the maximum allowable value.

MPLS

• Martini circuits configured on the ES2 10G LM act as true layer 2 tunnels, without modifying the layer 2 headers. For this reason, Martini VLAN retagging is not currently supported.
• If you are upgrading to Release 7.1.0 or a higher-numbered release and have inter-AS option B or C configurations, you must explicitly configure MPLS on all inter-AS links, as in the following example:

host1#configure terminal

host1(config)#interface fastEthernet 2/0

host1(config-if)#ip address ...

host1(config-if)#mpls

If you do not explicitly configure MPLS on the links, the inter-AS feature will not work properly.

Multicast

• The ip dipe sg-cache-miss and ipv6 dipe commands are not intended or supported for customer use, although they are visible in the User Exec and Privileged Exec modes respectively. These commands are intended to be used in a Juniper Networks internal lab environment for testing without a traffic generator.
• When you upgrade a router running a release earlier than JunosE Release 8.2.x to JunosE Release 8.2.x or higher-numbered releases, the Protocol Independent Multicast (PIM) configuration settings in VPN routing and forwarding (VRF) instances are not restored after the upgrade is completed. This problem happens only if you did not previously configure PIM on the parent virtual router (VR) for the VRF. This problem occurs with both IPv4 PIM and IPv6 PIM configurations on the router.

After the completion of the upgrade process, if you attempt to restore the PIM configuration directly on the VRF, an error message is displayed. For example, if you try to restore the IPv4 PIM settings on the VRF using the router pim command, the following error message is displayed:

host1:vrf01(config)#router pim
% PimIp not configured on this router

Work-around: To correct this problem after you upgrade a router running a release earlier than JunosE Release 8.2.x to JunosE Release 8.2.x or higher-numbered releases, you need to restore the PIM configuration on the upgraded router in two steps (first, on the parent VR, and then, on the VRF), instead of attempting to restore the PIM configuration directly on the VRF.

To restore IPv4 PIM configuration on the VRF, perform the following steps. These steps assume that a parent VR context, named "parent", and a VRF in the parent VR, named "vrf01", are already configured on the router.

1. Access the context of the parent VR, and create and enable IPv4 PIM on the parent VR.

host1(config)#virtual-router parent

host1:parent(config)#router pim

2. Enter the VRF Configuration mode to restore PIM settings on the VRF in the parent VR.

host1:parent(config)#virtual-router parent:vrf01

3. Create and enable IPv4 PIM on the VRF in the parent VR.

host1:parent:vrf01(config)#router pim

After the IPv4 PIM configuration is recovered on the VRF, you can remove the IPv4 PIM configuration settings on the parent VR by using the no router pim command, if necessary.

To restore IPv6 PIM configuration on the VRF, perform the following steps. These steps assume that a parent VR context, named "parent", and a VRF in the parent VR, named "vrf01", are already configured on the router.

1. Access the context of the parent VR, and create and enable IPv6 PIM on the parent VR.

host1(config)#virtual-router parent

host1:parent(config)#ipv6 router pim

2. Enter the VRF Configuration mode to restore PIM settings on the VRF in the parent VR.

host1:parent(config)#virtual-router parent:vrf01

3. Create and enable IPv6 PIM on the VRF in the parent VR.

host1:parent:vrf01(config)#ipv6 router pim

After the IPv6 PIM configuration is recovered on the VRF, you can remove the IPv6 PIM configuration settings on the parent VR by using the no ipv6 router pim command, if necessary.

Packet Mirroring

• The ES2 10G LM supports the packet mirroring feature when the module is paired with the ES2-S2 10GE PR IOA, the ES2-S1 GE-8 IOA, or the ES2-S3 GE-20 IOA. When you use the ES2 10G LM with these IOAs, CLI-based interface-specific mirroring is not supported.
• When both interface-specific mirroring and user-specific mirroring are configured on the same interface, the interface-specific secure policies take precedence. The interface-specific secure policies, which you manually attach using the CLI, override and remove any existing secure polices that were attached by a trigger action. If the interface-specific secure polices are subsequently deleted, the original trigger-based secure policies are not restored.
• Typically, when configuring packet mirroring, you configure a static route to reach the analyzer device through the analyzer port. If the analyzer port is an IP-over-Ethernet interface, you must also configure a static Address Resolution Protocol (ARP) entry to reach the analyzer device. However, because only a single static ARP entry can be installed for a given address at any given time, when you are using equal-cost multipath (ECMP) links to connect to the analyzer device, the static ARP configuration does not provide failover if the link being selected fails or is disconnected. Therefore, to provide continued connectivity if the link fails when using ECMP, enable the ip proxy-arp unrestricted command on the next-hop router for each ECMP interface. As a result, when the link fails, the router sends an ARP request to identify the MAC address of the analyzer device and gets a response over the new link.

Policy Management

• The ES2 10G LM does not support the deprecated next-hop command.
• You cannot configure classifier lists that reference multiple fields for a VLAN policy list on the ES2 10G Uplink LM or the ES2 10G LM, with the exception of traffic-class and color. The system incorrectly classifies VLAN policies that classify using multiple fields. For example, an invalid policy list that references multiple fields uses both color and user-packet-class, or one classifier list using color and another using user-packet-class.
• In rare cases, some policy configurations that use CAM hardware classifiers from releases earlier than Release 7.1.0 can fail because they exceed the total hardware classifier entry size of 128 bits that was introduced in Release 7.1.0. For more information about policy configurations and examples of previous configurations, see JunosE Policy Management Configuration Guide, Chapter 8, Policy Resources.
• Multiple Forwarding Solution Rules for a Single Classifier List in a Policy

Before Release 5.2.0, 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.0, the CLI no longer accepts this configuration.

• Multiple forwarding rules behavior for releases numbered lower than Release 5.2.0:
• 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.0 and higher-numbered releases:

Beginning with Release 5.2.0, 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)#

Informational Note: When you upgrade the nonvolatile memory to Release 5.2.0 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. If you upgrade to Release 5.2.0 or later and then configure your router using a script generated before Release 5.2.0, the postupgrade and preupgrade forwarding behaviors might not be the same. The new Release 5.2.0 configuration behavior is applied—the last policy rule configured for a given classifier list that specifies a forwarding behavior is the only rule remaining.

• Although it is not required, you can enclose the name of the classifier when you use the show classifier-list classifierName command and the name of the policy list when you use the show policy-list policyName command within double quotation marks. This method of specification of policy and classifier names ensures that the CLI interface does not process the abbreviated forms of the names as system-defined keywords, such as brief and detailed, available with show policy-list and show classifier-list commands.

For example, if you specify the show policy-list b command without enclosing the letter "b" within double quotation marks, assuming a policy list with the name "b" has been configured, the system auto-completes the letter "b" as brief and considers the command to denote a condensed display of policy lists (equivalent of the show policy-list brief command). Similarly, if you enter the show classifier-list d command to display the details of a configured classifier list with the name "d", the CLI interface processes the command as a listing of classifier details (equivalent of the show classifier-list detailed command).

To avoid incorrect and unexpected behavior in the output of the show classifier-list classifierName and show policy-list policyName commands, you must enclose the names of policy lists and classifier lists while using these commands within double quotation marks, especially if the names of the policy and classifier lists begin with letters that match the auto-complete forms of keywords. If the names of the policy and classifier lists do not match the beginning letters of the keywords or if you enter the full names of the policy and classifier lists, the system accurately processes the names even if you do not enclose them within double quotation marks while using these commands.

• When any of the policy resources near the state of being fully exhausted, any attempt to create, modify, or delete a policy rule or classifier that is associated with a policy already referenced by an interface fails. An error message is displayed stating that the policy resources are exhausted. The policy resource exhaustion trap is also generated because of the resource exhaustion. If you try to create a new policy instead of modifying a policy that is attached to an interface, the policy resources are allocated properly.

This behavior occurs because the policy manager application examines the availability of policy resources in the installed line modules and requires additional resources when you attempt to update or delete a policy referenced by an interface. As a result, the attempt to modify the policy fails with the error message on exhausted policy resources.

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.

PPPoE

• On the ES2 4G LM, ES2 10G LM, and ES2 10G Uplink LM, data packets for PPPoE are not counted at the PPPoE interface. Instead, PPPoE data packets are counted at the PPP interface that sits on the PPPoE interface. Use the show ppp interface command to display the data packets. Control packets for PPPoE are counted at the PPPoE interface; use the show pppoe interface command to display the control packets.

QoS

• In JunosE Releases 7.1.x, 7.2.x, and 7.3.x, you can attach a QoS profile to Ethernet interfaces that are configured in a link aggregation group (LAG) interface. However, beginning with JunosE Release 8.0.1, you can attach a QoS profile directly to the LAG interface. As of JunosE Release 8.0.1, the software restricts you from attaching a QoS profile to any Ethernet interfaces that are members of a LAG. [Defect ID 84632]

Work-around: Prior to upgrading from JunosE Releases 7.1.x, 7.2.x, or 7.3.x to JunosE Release 8.0.x or higher-numbered releases, remove the QoS profile from the Ethernet interface. When you have successfully upgraded to JunosE Release 8.0.x or higher-numbered releases, reattach the QoS profile to the LAG interface.

• In Release 7.2.0 and higher-numbered releases, you can configure the simple shared shaper to select scheduler nodes in a named traffic-class group as active constituents.

By default, simple implicit shared shapers activate scheduler nodes in named traffic-class groups. The implicit constituent selection process is now the same for both simple and compound shared shapers.

This is a change in default behavior. For releases before Release 7.2.0, you could not configure scheduler nodes as active constituents of the simple shared shaper, except for the best-effort node.

To recover the default behavior available before Release 7.2.0, or to select active constituents that are different, use simple explicit shared shapers to select best-effort nodes only.

• When you are configuring compound shared shaping using explicit constituents and you explicitly specify both a scheduler node and a queue stacked above the node as constituents of the shared shaper, the system selects the scheduler node (but not the queue) as the constituent.

RADIUS

• JunosE Software provides extended commands for configuring the formats of the RADIUS NAS-Port attribute (attribute 5) and the RADIUS Calling-Station-ID attribute (attribute 31) when the physical port value is greater than 7.

When the physical port value is greater than 7:

• An incorrectly configured NAS-Port attribute format results if you use either the radius nas-port-format 0ssssppp or radius nas-port-format ssss0ppp command.
• An incorrectly configured Calling-Station-ID attribute results if you use either the radius calling-station-format fixed-format command or the radius calling-station-format fixed-format-adapter-embedded command.

Work-around: Use the following commands on routers that have line modules with more than seven physical ports:

• To configure the NAS-Port attribute format, use the radius nas-port-format extended [ atm | ethernet ] command.
• To configure the Calling-Station-ID attribute format, use the radius calling-station-format fixed-format-adapter-new-field command.

SNMP

• SNMP MIBs

Information about all the SNMP MIBs (both standard and proprietary) that the router supports in this release is available in the MIB directory in the SW_Image_CD-2 folder of the JunosE Software image bundle, which you downloaded from the Juniper Networks website, that contains the release file for E120 and E320 routers.

• 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.

• If you perform an SNMP walk or a Get operation of the igmpInterfaceVersion object of the IP MIB for an IGMP interface configured as a passive interface (by using the ip igmp version passive command), a value of 255 is displayed for this object. You must set the value of this object to be only 1 or 2 using SNMP. If you attempt to set the igmpInterfaceVersion object to any value other than 1 or 2 using SNMP, an error message is displayed.
• When you perform an SNMP walk of the ipAddressTable object of the IP MIB, the following behavior is observed:
• The value of the ipAddressStatus attribute is always shown as preferred. If the interface is in the administratively down state, the IP address of that interface is not preferred for communication. In such a case, the ipAddressStatus attribute is still shown as preferred.
• The ipAddressOrigin object always returns as manual, even when the IP address is not manually configured and a link-local address is used.
• The ipAddressStorage object always returns the default value as volatile(2).
• When you perform an SNMP walk of the ipv6InterfaceRetransmitTime and ipv6InterfaceReachableTime MIB objects of the IP MIB, the values for these objects depend on the setting you configured using the ipv6 nd reachable-time and ipv6 nd ns-interval commands in the CLI interface.

The ipAddressCreated, ipAddressLastChanged, and ipAddressPrefix objects of the IP MIB are not implemented in JunosE software. The ipNetToPhysicalLastUpdate object might display inconsistent values because it is not fully supported.

• You cannot configure the ospfv3ExtAreaLsdbLimit MIB object in the OSPFV3 MIB, which denotes the maximum number of external link-state advertisements (LSAs), on the router because this object is not supported. As a result, the ospfv3LsdbOverflow trap is not generated to indicate that the maximum number of external LSAs (limit) in the link-state database has been exceeded. Also, the ospfv3LsdbApproachingOverflow trap is not generated to denote that the number of external LSAs has exceeded 90 percent of the limit.

SRC Software and SDX Software

• When you reenable the policy and QoS configuration support on IPv6 interfaces by using the sscc protocol ipv6 command after disabling the support by using the no sscc protocol ipv6 command, sometimes the support is not enabled because the IPv6 plug-in for SRC client is not completely removed. This behavior occurs because the DEC message received from the SRC server does not contain entries for removing some of the classifier-list PIB objects.

Work-around: You can avoid this problem either by executing the sscc restart clean-state command or by executing the no sscc enable cops-pr and sscc enable cops-pr commands before enabling the policy and QoS configuration support again.

• When you enter the show sscc statistics delta command to display the baselined SRC client statistics, the Active IP Interfaces field in the output of the command displays a negative value for the current number of active IP interfaces that the SRC client is aware of. This problem occurs for subscriber policies managed by the SRC client. Also, this scenario occurs if you enter the baseline sscc command to set a baseline for the SRC client statistics before viewing the baselined statistics using the show sscc statistics delta command. The router implements the baseline by reading and storing the statistics at the time the baseline is set and then subtracting this baseline when you retrieve baseline-relative statistics.

For example, if the number of active IP interfaces at a certain point in time is 4 and if you set the baseline for SRC statistics at that point, the output of the show sscc statistics delta command displays the value for the Active IP Interfaces field as 0 (by subtracting current statistical value of 4 from the baseline value of 4). If a subscriber goes down and the number of active IP interfaces reduces to 3, the output of the show sscc statistics delta command displays the value for the Active IP Interfaces field as –1 (by subtracting current statistical value of 3 from the baseline value of 4). [Defect ID 193694]

• In a network in which approximately 40,000-45,000 IP interfaces are managed by an SRC client on an E Series router, if you enter the sscc enable command to enable the SRC client after it was previously disabled, the CLI interface stops responding and is not accessible for about 15 minutes. [Defect ID 187946]

SSH

• If the SRP module restarts when SSH is configured in a VR other than default, SSH can sometimes become disabled. This happens if SSH attempts to bind with a VR before the VR comes back up after the restart. In this event, a warning message is generated to alert you to the fact that SSH is disabled in that VR. You must manually re-enable SSH either by accessing the console VTY or creating a Telnet session to the router.

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, the performance of other control plane functions is reduced. Specifically, call setup rates are lower than in previous releases.

  Informational Note: Rapid call setup rates are most important following an outage that causes all subscribers to drop, because many of the dropped subscribers will 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.

• Stateful SRP switchover 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 stateful SRP switchover.

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.

• When IP tunnels are configured on a router enabled for stateful SRP switchover, and the Service Module (SM) carrying these tunnels is reloaded, stateful SRP switchover transitions to the pending state. Stateful SRP switchover remains in the pending state for 10 minutes following the successful reloading of the SM. This amount of time allows for IP tunnel relocation and for the tunnels to become operational again on the SM. If an SRP switchover occurs while in the pending state, the router performs a cold restart.

Work-around: None.

System

• ERX routers display different behavior from E120 routers and E320 routers when reporting modules as inactive.

ERX routers report a module as inactive when one of the following happens:

• The I/O module is not present.
• The primary line module is fully booted and ready to resume operation. In this case, the standby is currently providing services.

E120 routers and E320 routers report a module as inactive when one of the following happens:

• The primary line module has no IOAs.
• The primary line module has IOAs, but they have failed diagnostics.
• The standby line module has taken over for the primary line module, and has control of the IOAs.

Because E120 and E320 routers can accommodate up to two IOAs per slot, at least one IOA must be online. If the second IOA fails, the line module is still online, but does not use both IOAs. You can ensure that every module is up and active in the system and not in a failed state by issuing the show version all command.

• 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 an ERX1410 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.

• You cannot delete the ipInterface log after you delete the corresponding IP interface. This does not prevent you from adding filters to other interfaces, nor does it prevent you from adding a filter to the same interface if you re-create it after deletion. [Defect ID 34842/45063]

Work-around: Remove the filter before you remove the interface. Alternatively, if you remove the interface first, then you must remove all filters associated with all IP interfaces.

Tunneling

• When you configure the GE-2 line module or the GE-HDE line module with a shared tunnel-server port, the available bandwidth for tunnel services is limited to 0.5 Gbps per module. When you configure the ES2 4G line module with a shared tunnel-server port, the available bandwidth for tunnel services is limited to 0.8 Gbps per module.
• In releases numbered lower than Release 7.3.0, a dynamic tunnel-server port was located on port 8 of the GE-HDE line module and GE-8 I/O module.

In Release 7.3.0 and higher-numbered releases, the dynamic tunnel-server port is located on port 9. When you upgrade to Release 7.3.0, any existing tunnel-server port configurations move from port 8 to port 9.