JunosE 12.0.0 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/authorization requests to a RADIUS server, AAA internal limits prevent the actual number of outstanding authentication/authorization requests from exceeding 9600. These internal AAA limits apply only to authentication/authorization requests and not to accounting 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 it is not supported.

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.

• When you reload an ATM line module that is configured with NBMA circuits as passive OSPF interfaces and that has established OSPF adjacencies and IBGP peers (configured on Gigabit Ethernet interfaces), the transmission of OSPF hello packets might be affected until all the NBMA interfaces have initialized.

Work-around: Either remove the passive OSPF interface statements on the NBMA interfaces, or statically configure the OSPF cost on the NBMA interfaces.

• When you configure an ATM PVC where PCR = SCR and maximum burst size is zero, the CLI returns an error indicating the burst size is invalid and it does not create the VC.

Work-around: Configure a CBR or a UBR plus PCR to create the circuit with the same parameters, depending on the desired priority for the traffic. CBR has a high priority and UBR plus PCR has a medium priority.

• The ATM peak cell rate (PCR) does not appear in the L2TP Calling Number AVP for the first PPP session when the ATM shaping parameters were configured by RADIUS return attributes.
• When you use the no-authenticate keyword with the subscriber command to prevent subscriber authentication so that the subscriber information can be used for DHCP option 82, suboption 2, the SRP module can reset. This issue does not occur when you use the no-authenticate keyword with the subscriber command as a way to perform a RADIUS configuration.
• When you perform an snmpWalk on the juniAtmSubIfVccTable, a response is received for only a few of the total configured ATM subinterfaces when both of the following are true: the router has a line module that has some ATM-related configuration and the line module is in the disabled state.

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.

Bridged Ethernet

• The CLI erroneously permits you to configure bridge1483 encapsulation over AAL5MUX IP even though that configuration is not supported.

CLI

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

DHCP External Server

• If you are using DHCP external server and a burst of client releases occurs during a unified ISSU, some of the client releases might not be processed. [Defect ID 180178]
• 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.

• DHCP external server may not be able to bind all DHCP clients when all of the following conditions exist:
• 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 DHCP external server and either DHCP relay or relay proxy are configured on the same ES2 4G LM.
• 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 stand-alone 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 DHCP external server and either DHCP relay or relay proxy in the same virtual router.
• Configure the client-facing and server-facing interfaces for 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 DHCP external server and either DHCP relay or relay proxy on separate ES2 4G LMs.
• DHCP NAK packets are sent from a different VLAN than the one on which the renew request is received on a router that is configured with dynamic VLANs, DHCP local server, and automatically created dynamic subscriber interfaces. This behavior occurs only after a link flap has taken place.

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 higher-numbered release, the software automatically transfers existing configurations that use the 0x9200 Ethertype to the 0x88a8 Ethertype.

• The show interface 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.

Forwarding

• A memory leak of about two percent can occur on the ES2 10G LM and result in a module reset when a large number of successive SRP switchovers take place with active DHCP clients.
• VPLS forwarding does not function properly when any of the following conditions occur:
• MLPPP interfaces are used
• L2TP is used with sequence numbers enabled
• GRE is used with sequence numbers enabled

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

• 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.
• The ES2 10G LM and the ES2 10G Uplink LM do not support VLAN statistics in the current release.
• 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

• IP interface statistics become inconsistent when a slot is reset, because some traffic (such as control traffic) might be destined for the SRP module and is therefore counted elsewhere.
• 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 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 9 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 9 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 9 or more characters.
• Change VRF descriptions, VRF names, or both so that the combination of associated VRF names and descriptions consists of 9 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.
• During a warm restart after a system failover, the SRP module can take several minutes to resume the normal exchange of UDP/IP packets to applications. During this restart time, the E Series router does not send or receive dead peer detection (DPD) keepalives, which are used to verify connectivity between the router and its peers. The length of the restart time depends on the number of interfaces—if the restart time is too long, remote peers might determine that the connection from them to the E Series router is broken and then shut down an IPSec tunnel that has DPD enabled. In the worst case, all IPSec tunnels might be shut down. [Defect ID 65132]

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, however, 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.

• If you perform a stateful SRP switchover operation on a router with IS-IS previously configured on the device, the IS-IS application takes longer than the normal duration (approximately 40 seconds) to restart after the switchover is completed. The time that it takes for IS-IS to restart after a stateful switchover causes a large delay in the transmission of hello packets with restart TLV (type 211) from the restarting router to neighboring routers. Because of the delay in transmission of hello packets to neighboring routers, active adjacencies are not maintained between the restating router and other routers in the IS-IS domain. To avoid adjacencies being reset, we recommend that you increase the hold timers for the IS-IS protocol to appropriate values, based on the level of complexity of the network and configuration settings, so as to enable IS-IS graceful restart to be completed successfully. [Defect ID 90546]

The long duration for restart of a previously running application on the router also occurs if you configured OSPF on the router and perform a stateful SRP switchover process. This condition can occur even in environments that are not scaled to the maximum limits and contain minimal subscriber connections or attribute definitions.

Because the IP application takes about 30-35 seconds to reinitialize and process control packets after a stateful SRP switchover, and the continual increase in the time needed for completion of IP reinitialization in JunosE releases (owing to consumption of system resources for enhanced functionalities), we recommend that you increase the hold timers for the associated protocols running on the router to necessary levels so that graceful restart can function properly.

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.

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

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.

• When you install an ES2-S1 Redundancy IOA with a hardware revision number of -02 or less in slot 0 or slot 11 of the E320 router or in slot 0 or the E120 router, do not install an OCx/STMx ATM IOA or an OCx/STMx POS IOA in the lower (E320) or left (E120) adapter bay of slot 1 or slot 12. When the spare line module is controlling another slot and you revert back to the primary line module, the ATM or POS IOAs can become unusable or cause the line module to reset. [Defect ID 69760]

Work-around: This problem is not present for ES2-S1 Redundancy IOAs with a hardware revision number of -03 or higher.

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

• You cannot use an underscore character (_) in an MPLS tunnel name.
• 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 from a release numbered lower than Release 7.1.0, 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. When you upgrade the router to JunosE Release 7.1.0 or a higher-numbered release from a release numbered lower than Release 7.1.0, remote ATM layer 2 over MPLS circuits (also known as MPLS shim interfaces) that use Martini encapsulation are erroneously signaled with the control word attribute setting "Control word is not preferred by default". Because control words are required for these MPLS shim interfaces, these circuits should instead be signaled with the setting "Control word is preferred by default".

Work-around: To reinstate the proper setting ("Control word is preferred by default"), remove the MPLS shim interface from the ATM subinterface and then reconfigure it.

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.
• Do not configure a multicast group with more than 10,219 outgoing interfaces (OIFS) on the same ES2 10G LM. [Defect ID 81768]
• 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 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. Informational Note: 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.

• In JunosE Release 11.0.0 and higher-numbered releases, you must specify at least one option by which the router defines a packet flow in order to configure classifier control lists (CLACLs) for policy lists to be attached to VLAN interfaces. Although a carriage return, <cr>, is displayed when you type a question mark (?) after entering the vlan classifier list classifierName command without defining any other keyword or CLACL option, an error message is displayed when you press Enter to configure the VLAN CLACL with only the name. The error message states that a VLAN classifier list cannot be configured without any classification criteria, such as color, traffic class, user packet class, or user priority. You must specify at least one keyword or option to configure VLAN CLACL successfully. [Defect ID 184139].

In JunosE releases earlier than Release 11.0.0, you could configure all CLACLs (except those CLACLs that were attached to IP interfaces) without specifying an option or a keyword. Because the policy management application treats only one default classifier group (configured with an * in the policy list) as a valid setting, this functionality change ensures that only one classifier that matches all packets can be present in a VLAN policy list definition.

• 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 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 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 you attach a policy to an interface and the policy contains a classifier rule that is unsupported for that interface, the CLI generates a message and the policy is applied. However, if an existing policy is already attached to that interface, then support for the new policy is not checked and the invalid policy is applied to the interface without warning. The results of this attachment are not predictable.
• No logs are created if you use the policy-list option with the log severity severityValue policyMgrPacketLog policy-list policyListName command when logging policyMgrPacketLog events.

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.
• The router cannot resolve inconsistent requests caused by two QoS profiles that modify the same scheduler property inconsistently.

Work-around: Avoid using two QoS profiles that modify the same scheduler property inconsistently, such as setting different values for the shaping rate for the same S-VLAN node.

• When you perform an SNMP walk of the juniQosQueueStatistics MIB, a timeout of up to 5 minutes ensues, during which the SRP module CPU utilization goes to 100 percent.
• Egress strict-priority packets may experience high latency on OC3/STM1 ATM interfaces associated with the LM if you have shaped the port rate to more than 148.5 Mbps.

Work-around: To ensure low strict-priority latency, shape the port rate to no more than 148.5 Mbps.

• An error message regarding the qos-parameter instance QosParameterDefinition is erroneously generated on an ERX1440 router when it is configured for L2C and QoS RAM and receives TLV 144 (DSL Type). The parameter instantiation actually functions properly.
• On the E120 and E320 routers, you cannot attach QoS profiles to L2TP tunnels by means of the CLI because the CLI does not pass the router ID to QoS.
• PPP sessions may be dropped if you change the shaping rate in a QoS profile that affects thousands of circuits while QoS traffic affected by the profile is being forwarded.

Work-around: Do not change the shaping rate in a QoS profile that affects thousands of circuits while QoS traffic is using the profile.

• Egress traffic may be dropped on OC12/STM4 ATM interfaces if you have shaped the port rate to more than 542 Mbps.

Work-around: Do not exceed a shaped port rate of 542 Mbps.

• Incorrect output is sent to the CLI the first time you enter Global Configuration mode or issue the show subscribers command after viewing the VLAN subinterface over which a subscriber is connected.

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

• When you configure the router with an address pool that has two IP address ranges, only the range that you configured first is available via the MIB.

SRC Software and SDK Software

• The SRC client does not prevent you from changing the name of the router while the client is connected to the SAE, resulting in SAE issues such as lost IP addresses and stale users.

Work-around: To change the router name while the SRC client is connected to the SAE, shut down the SRC client, change the name, then re-enable the SRC client.

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.

• After a stateful SRP switchover, each layer of the interface columns must reconstruct its interfaces from the mirrored information. While the interfaces are being reconstructed the SRP module cannot send or receive frames, including the protocol frames that signal graceful restart behavior with OSPF and IS-IS peers. If the configured hold time is too short, peers might mistakenly declare the adjacency down during the time in which the graceful restart is taking place. [Defect ID 65132]

Work-around: Increase the hold time to provide sufficient time for interface synchronization before the peers declare the adjacency down.

• For OSPF, use the ip ospf dead-interval command to set the hold time. We recommend that you use Bidirectional Forwarding Detection (BFD) with a longer OSPF dead interval to achieve fast failure detection.
• For IS-IS, use the isis hello-interval and isis hello-multiplier commands to set the hold time.

We recommend the following hold times for each protocol, based on the number of interfaces.

Interface Count	Recommended Hold Time for OSPF	Recommended Hold Time for IS-IS
16000 or less	80 seconds	50 seconds
16001 to 32000	87 seconds	55 seconds
32001 to 48000	90 seconds	70 seconds

• When you issue show commands as soon as the CLI is available after a stateful SRP switchover, the commands can hang until the warm restart is completed.

Subscriber Interfaces

• MAC address validation is not supported on either of the following:
• Packet-triggered subscriber interfaces that are created dynamically
• Packet-triggered subscriber interfaces that are managed on the primary IP interface

A packet-triggered subscriber interface is created when the router receives a packet with an IP source address that does not match any entries in the demultiplexer table. When the router detects an unmatched packet, it generates a trigger event that determines whether to create a dynamic subscriber interface or configure an existing interface. To configure packet detection on the router, use the ip auto-detect ip-subscriber command.

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 either:

• 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 either:

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

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:

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

• The show configuration category management syslog virtual-router default command incorrectly displays logs for multiple syslog destinations when you add a log to only one syslog destination. The show log configuration command shows the correct configuration.

Tunneling

• When you configure the GE-2 line module, the GE-HDE line module, or the ES2-S1 GE-4 IOA to operate as a shared tunnel-server module, the available bandwidth for tunnel services is limited to 0.5 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.