User manual JUNIPER NETWORKS JUNOSE 11.1.0 REV 4-29-2010

[. . . ] JUNOSeTM Software for E SeriesTM Broadband Services Routers Release Notes Release 11. 1. 0 Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA 408-745-2000 www. juniper. net Published: 2010-04-29 Juniper Networks, the Juniper Networks logo, JUNOS, NetScreen, ScreenOS, and Steel-Belted Radius are registered trademarks of Juniper Networks, Inc. in the United States and other countries. JUNOSe is a trademark of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. [. . . ] 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: Known Behavior 35 JUNOSe 11. 1. 0 Release Notes 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. 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)# 36 Known Behavior Release 11. 1. 0 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. [. . . ] There is no per-VR limit; all multicast routes can be on a single VR or present across multiple VRs. The maximum number of interfaces can be achieved by any combination; for example, two streams each being replicated to 32, 768 interfaces; 16, 384 streams each being replicated four times; or any other combination. Table 11: Routing Protocol Maximums Feature BFD Sessions per line module for ES2 4G LM Sessions per line module for all modules other than ES2 4G LM 100 50 100 50 E120 E320 96 E120 and E320 System Maximums Appendix A: System Maximums Table 11: Routing Protocol Maximums (continued) Feature ECMP maximum paths to a destination BGP, IS-IS, MPLS, OSPF, RIP 16 16 E120 E320 IPv4 forwarding table entries per chassis (See Note 1 on page 96. ) 1, 048, 576 1, 048, 576 IP network interfaces (IPv4 and IPv6) Per chassis (See Note 2 on page 96. ) Per ES2 4G LM Per ES2 10G LM Per ES2 10G ADV LM Per ES2 10G Uplink LM 16, 000 16, 000 32, 000 8000 16, 000 16, 000 32, 000 8000 64, 000 96, 000 IPv4 routing protocol scaling and peering densities (See Note 3 on page 96. ) Routing table entries (See Note 4 on page 96. ) ANCP Adjacency Scaling (See Note 5 on page 96. ) BGP-4 peering sessions BGP-4 routes (NLRI) IP next hops (egress FECs); used to represent the IP addresses of next-hop routers on Ethernet interfaces MPLS next hops (egress FECs) when graceful restart is not enabled MPLS next hops (egress FECs) when graceful restart is enabled MPLS forwarding entries when graceful restart is not enabled MPLS forwarding entries when graceful restart is enabled IS-IS adjacencies IS-IS routes MPLS LDP LSPs when graceful restart is not enabled MPLS LDP LSPs when graceful restart is enabled 3000 1, 500, 000 1, 000, 000 500, 000 250, 000 64, 000 32, 000 150 20, 000 10, 000 5000 3000 1, 500, 000 1, 000, 000 500, 000 250, 000 64, 000 32, 000 150 20, 000 10, 000 5000 10, 000 5000 1000 25, 000 5000 5000 500, 000 500, 000 MPLS RSVP-TE LSPs when graceful restart is not enabled 10, 000 MPLS RSVP-TE LSPs when graceful restart is enabled OSPF adjacencies OSPF routes 5000 1000 25, 000 E120 and E320 System Maximums 97 JUNOSe 11. 1. 0 Release Notes Table 11: Routing Protocol Maximums (continued) Feature IPv6 routing table entries (See Note 3 on page 96. ) E120 100, 000 E320 100, 000 J-Flow statistics J-Flow­enabled VRs and VRFs, in any combination Sampled interfaces per VR or VRF Total sampled Interfaces per chassis 16 32 512 16 32 512 Martini circuits for layer 2 services over MPLS Total Martini circuits per line module Total Martini circuits per chassis (See Note 6 on page 96. ) External Martini circuits per chassis 16, 000 32, 767 32, 767 16, 000 16, 000 16, 000 32, 767 Internal Martini circuits (local cross-connects) per chassis 16, 000 Mobile IP bindings per chassis ­ 96, 000 Multicast routes (IPv4 and IPv6) Forwarding entries [(S, G) pairs] per chassis (See Note 7 on page 96. ) Outgoing interfaces per chassis (See Note 8 on page 96. ) 65, 536 65, 536 16, 384 16, 384 Response Time Reporter simultaneous operations per VR 500 500 Response Time Reporter maximum tests per chassis (SRP-100 or SRP-320) ­ 500 Response Time Reporter maximum tests per virtual router (SRP-100 or SRP-320) ­ 100 VRRP VRIDs per line module See Ethernet VRRP VRIDs per line module on page 94. See Ethernet VRRP VRIDs per line module on page 94. 98 E120 and E320 System Maximums Appendix A: System Maximums Policy and QoS Maximums Table 12 lists policy and QoS maximums for the E120 router and the E320 router. The following notes are referred to in Table 12: 1. For more information about system resource requirements for nodes, queues, and shadow nodes, see JUNOSe Quality of Service Configuration Guide, Chapter 15, QoS Profile Overview. [. . . ]