[Contents] [Prev] [Next] [Report an Error] [No Frames]

JUNOSe 7.0.4 Release Notes > Release 7.0.4 > Known Behavior

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

BGP

Resetting the BGP connection is slightly different when you change outbound policies for peer groups for which you have enabled Adj-RIBs-Out. You cannot merely perform a hard clear or outbound soft clear for individual peer group members because that causes BGP to resend only the contents of the Adj-RIBs-Out table. If you change the outbound policy for such a peer group and want to fill the Adj-RIBs-Out table for that peer group with the results of the new policy, you must use the clear ip bgp peer-group command to perform a hard clear or outbound soft clear of the peer group.

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

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

B-RAS

Bulkstats

CLI

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.

DHCP

The Address Resolution Protocol (ARP) performs spoof checking on all incoming ARP requests by default. For each incoming packet, ARP does a route lookup on the source IP address to determine the interface on which that IP address was routed. ARP then verifies that the interface on which the packet was received matches the routed interface. If the interface on which the packet was received does not match the routed interface, the router drops the packet.

When you configure applications such as DHCP relay that automatically install routes, you must ensure that the routes are correctly installed for your configuration. DHCP relay installs host routes by default, which is required in certain configurations to enable address renewals from the DHCP server to work properly. However, the default installation of host routes might cause a conflict when you configure DHCP relay with static subscriber interfaces.

For example, to configure multiple subscribers over a particular static subscriber interface (ip53001 in this example), you might use commands similar to the following to create demultiplexer table entries and a subnet route that points to the static subscriber interface.

  1. Create a shared IP interface.
    2. host1(config)#interface ip ip53001
  2. Associate the shared IP interface with a static layer 2 interface.
    3. host1(config-if)#ip share-interface gigabitEthernet 1/0
  3. Make the shared interface an unnumbered interface.
    4. host1(config-if)#ip unnumbered loopback 53
  4. Specify the source addresses that the subscriber interface uses to demultiplex traffic.
    5. host1(config-if)#ip source-prefix 10.10.10.0 255.255.255.252
  5. Exit Interface Configuration mode.
    6. host1(config-if)#exit
  6. Create a static route that sends traffic for destination address 10.10.10.0 to subscriber interface ip53001.
    7. host1(config)#ip route 10.10.10.0 255.255.255.252 ip53001

DHCP relay installs host routes for clients by default. In this example, the host routes are associated with the primary IP interface on Gigabit Ethernet 1/0. Because the host routes in this example are statically configured with the subscriber interface, there is no need for the router to install DHCP host routes. Unless you prevent DHCP relay from installing host routes by issuing the set dhcp relay inhibit-access-route-creation command, a configuration similar to this example can result in a conflict that causes undesirable ARP behavior.

Specifically, the ARP spoof-checking mechanism associates the ARP traffic with the primary IP interface (Gigabit Ethernet 1/0), although packets actually arrive on the subscriber interface (ip53001). The resulting behavior causes the router to detect a spoof and drop the packet.

To avoid these configuration conflicts, use the set dhcp relay inhibit-access-route-creation command to prevent DHCP relay from installing host routes by default.

Dynamic Interfaces

Ethernet

When installed in the ERX-1440 router, the GE-2 module delivers full bandwidth of 2 GB per port 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 ERX-1440 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 ERX-1440 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 ERX-1440 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 ERX-1440 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 ERX-1440 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 ERX-1440 router or the ERX-310 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.

Flash

GRE

Hardware

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

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

HDLC

IP

Work-around: Run the script twice.

IPSec

IS-IS

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.

L2TP

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

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 E-series routers other than the E320 router, redundant IOAs do not have a temperature sensor. Therefore, the show environment all command output lists the primary IOA temperature in the slot of the line module that is responsible for the IOA.

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

MLPPP

MPLS

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

Policy Management

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.

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)#







 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.


 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.

POS

PPP

For terminated PPP sessions, the JUNOSe software begins the collection of accounting statistics following, but not including, authentication acknowledgement from the E-series router. The acknowledgment is either a CHAP success or PAP acknowledgement packet. All subsequent traffic is counted up to the point that PPP at the router terminates the subscriber's session. PPP session termination can be initiated through a number of mechanisms: PPP shutdown at the client or router interface, subscriber logout at the router (by means of the logout subscriber command), lower layer down events, and silent client termination.

Accounting statistics reported in RADIUS octet counts (Acct-Input-Octets and Acct-Output-Octets) for terminated PPP customers include the following data:

Accounting statistics reported in RADIUS octet counts (Acct-Input-Octets and Acct-Output-Octets) for terminated PPP customers exclude the following data:

Accounting statistics reported in RADIUS packet counts (Acct-Input-Packets and Acct-Output-Packets) for terminated PPP customers are based on packets delivered to or received from the upper transport layer: IP, IPv6, MPLS, and OSI.

For tunneled subscribers at the L2TP LAC, the JUNOSe software counts the payload that PPP passes to or receives from L2TP for transport. At this stage in the protocol processing, any padding outside PPP, such as that for PPPoE, has been removed. Accounting includes the authentication acknowledgement packet, CHAP success packets, and PAP acknowledgment packets. Accounting ends when L2TP has been notified to terminate the session. Termination of a tunneled session can result from PPP termination, L2TP shutdown, subscriber logout, or lower layer down events. When the session is terminated through PPP, the software counts both the PPP terminate-request and the PPP terminate-acknowledgement packets.

Accounting statistics reported in RADIUS octet counts (Acct-Input-Octets and Acct-Output-Octets) for tunneled PPP customers at the L2TP LAC include the following data:

Accounting statistics reported in RADIUS octet counts (Acct-Input-Octets and Acct-Output-Octets) for tunneled PPP customers at the L2TP LAC exclude the following data:

Accounting statistics reported in RADIUS packet counts (Acct-Input-Packets and Acct-Output-Packets) for tunneled PPP customers at the L2TP LAC are based on packets delivered to or received from the L2TP session. These statistics exclude L2TP control traffic and L2TP hello messages.

QoS

SNMP

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

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.

SRP Module Redundancy

When you arm a configuration (.cnf) file by issuing the boot config cnfFilename command, a subsequent SRP switchover causes the redundant SRP module to take the role of primary SRP module with the configuration specified by the .cnf file. The new primary SRP module does not use the running configuration.

If you want the redundant SRP module to instead use the running configuration when it assumes the primary role, then you must first arm a configuration file with the boot config cnfFilename once command. To exhaust the once option, you must then cause the redundant SRP module to reload for some reason, such as by issuing a reload command or by arming a new JUNOSe release or a hotfix file.

When a switchover subsequently occurs, the redundant SRP module reloads with the running configuration and takes the primary role.

Stateful SRP Switchover (High Availability)

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

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.

Subscriber Interfaces

For details about the cause of this conflict and the work-around for it, see ARP Spoof Checking and DHCP Relay Configuration.

System

ERX routers report a module as inactive when either:

E320 routers report a module as inactive when either:

Because the E320 router 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.

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

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

[Contents] [Prev] [Next] [Report an Error] [No Frames]