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 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 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.
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.
bgpConnections (default,0.0.0.0): TCP error code xx (...) occurred while accepting inbound TCP connection
The message is generated when an unconfigured peer attempts to establish a TCP session with an E Series router and a valid route to the source address of the peer is absent from the router's routing table.
If a valid route exists in the routing table, the following message is displayed when an unconfigured peer attempts to establish a TCP session with an E Series router; X.X.X.X is the source address of the unconfigured peer:
NOTICE 08/29/2001 16:50:11 bgpConnections (default,X.X.X.X): Inbound connection refused - no peer X.X.X.X configured in core
BGP/MPLS VPNs
- NAT does not function properly with secondary routing table lookup (fallback global) or global export mapping on the VRF.
B-RAS
- Pool groups are not supported; although the ip local pool group command appears in the CLI, it is not supported.
- 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
- 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.
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.
 |
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.
Dynamic Interfaces
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.
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
- 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
- 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:
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
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.
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
- 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.
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]
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.
- 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.
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)#
- In JUNOSe Release 11.0.0, 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.
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 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
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.
Work-around: Use the OIDs that the SNMP agent sends.
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.
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.
- 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.
Subscriber Interfaces
- 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: [Defect ID 43168]
NOTICE 09/01/2002 18:47:52 CEST controlNetwork (slot 11): Control Bus Master slave error 0x5 while accessing slot
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.