JunosE 12.2.1 Release Notes

Errata

This section identifies errors found in the JunosE documentation. These errors are corrected in subsequent releases of the affected documentation.

• The Policy and QoS Maximums table (for ERX310, ERX7xx, and ERX14xx routers) in Appendix A, System Maximums, of the JunosE Release Notes, for the following releases fails to mention the maximum number of policy rules supported by the SRC client running on ERX routers:
• Releases 11.2.0, 11.2.1, 11.2.2
• Releases 11.3.0, 11.3.1, 11.3.2
• Releases 12.0.0, 12.0.1, 12.0.2
• Releases 12.1.0, 12.1.1
• Release 12.2.0

Policy and QoS Maximums table (for ERX310, ERX7xx, and ERX14xx routers)

Feature	ERX310	ERX705 and ERX710	ERX1410	ERX1440
Policy rules supported by the SRC client	256,000	256,000	256,000	256,000

Also, the folowing additional information applies to the allocation of memory blocks for policy rules sent to the SR client from the SRC server for enforcing policy decisions:

For each rule that is sent from the SRC server using COPS messages to the SRC client, which is a router running JunosE Software, an entry is created in the policy table of the SRC client. A portion of the memory on the SRC client is needed to hold these policy rule entries that are transmitted to the SRC client for enforcing the policy decisions that are sent from the SRC server. The maximum number of memory blocks that is allocated to the SRC client functioning on the router for the policy rules that are sent from the SRC server is 256,000.

• The Policy and QoS Maximums table (for E120 and E320 routers) in Appendix A, System Maximums, of the JunosE Release Notes, for the following releases, fails to mention the maximum number of policy rules supported by the SRC client running on E120 and E320 routers:
• Releases 11.2.0, 11.2.1, 11.2.2
• Releases 11.3.0, 11.3.1, 11.3.2
• Releases 12.0.0, 12.0.1, 12.0.2
• Releases 12.1.0, 12.1.1
• Release 12.2.0

The following table lists the maximum number of policy rules supported by the SRC client on E120 and E320 routers:

Policy and QoS Maximums table (for E120 and E320 routers)

Feature	E120	E320
Policy rules supported by the SRC client	256,000	256,000

Also, the folowing additional information applies to the allocation of memory blocks for policy rules sent to the SR client from the SRC server for enforcing policy decisions:

For each rule that is sent from the SRC server using COPS messages to the SRC client, which is a router running JunosE Software, an entry is created in the policy table of the SRC client. A portion of the memory on the SRC client is needed to hold these policy rule entries that are transmitted to the SRC client for enforcing the policy decisions that are sent from the SRC server. The maximum number of memory blocks that is allocated to the SRC client functioning on the router for the policy rules that are sent from the SRC server is 256,000.

• The following additional information regarding the processing of tunneled subscriber sessions on Agent Circuit Identifier-based (ACI) VLAN subinterfaces with ICR partitions configured applies to the following guides in the JunosE documentation set:
• JunosE Service Availability Configuration Guide—Grouping ICR Subscribers Based on S-VLAN IDs section in Chapter 7, Managing Interchassis Redundancy
• JunosE Broadband Access Configuration Guide—Monitoring Subscriber Information section in Chapter 3, Monitoring and Troubleshooting Remote Access

If you attempt to bring up tunneled subscribers on ACI-based VLAN subinterfaces on LAC devices with subscriber groups that are based on S-VLAN IDs (using the ip vrrp vrid icr-partition group svlan command on S-VLAN subinterfaces), the VLAN subinterface does not come up and a log message to denote its down state is not generated. If you attempt to bring up tunneled subscribers on ACI-based VLAN subinterfaces on LAC devices with subscriber groups that are based on VLAN IDs (using the ip vrrp vrid icr-partition group vlan command on VLAN subinterfaces), the subscribers over tunnels are brought up. However, on the LAC device, the subscribers are logged in outside of the ICR partition.

This behavior is expected when attempts are made to log in tunneled subscribers over ACI-based VLAN subinterfaces configured with ICR partitions with VLAN-based grouping or S-VLAN based grouping.

• The [26-1] Virtual-Router section in JunosE Broadband Access Configuration Guide, Chapter 4, Configuring RADIUS Attributes fails to state the following additional information regarding the usage of the IPv4 virtual router context configured in the AAA domain map and the RADIUS server on an authentication virtual router:

If you configure the default virtual router as the authentication virtual router for the domain map using the ip-router-name command in Domain Map Configuration Mode and the Virtual-Router RADIUS VSA attribute [26-1] is returned from the RADIUS server in the Access-Accept message, the IPv4 virtual router context returned from the RADIUS server overrides the IPv4 virtual router context configured in the AAA domain map. If you configure a nondefault virtual router as the authentication virtual router for the AAA domain map and the Virtual-Router RADIUS VSA attribute [26-1] is returned from the RADIUS server in the Access-Accept message, the IPv4 virtual router context in the AAA domain map takes precedence over the IPv4 virtual router context returned from the RADIUS server.

• The [26-45] Ipv6-Virtual-Router section in JunosE Broadband Access Configuration Guide, Chapter 4, Configuring RADIUS Attributes fails to state the following additional information regarding the usage of the IPv6 virtual router context configured in the AAA domain map and the RADIUS server on an authentication virtual router:

If you configure the default virtual router as the authentication virtual router for the domain map using the ipv6-router-name command in Domain Map Configuration Mode and the IPv6-Virtual-Router RADIUS VSA attribute [26-45] is returned from the RADIUS server in the Access-Accept message, the IPv6 virtual router context returned from the RADIUS server overrides the IPv6 virtual router context configured in the AAA domain map. If you configure a nondefault virtual router as the authentication virtual router for the AAA domain map and the IPv6-Virtual-Router RADIUS VSA attribute [26-45] is returned from the RADIUS server in the Access-Accept message, the IPv6 virtual router context in the AAA domain map takes precedence over the IPv6 virtual router context returned from the RADIUS server.

• The syntax of the mpls ldp ip-forwarding command in the JunosE Command Reference Guide A to M incorrectly specifies that the access-list, host-only, and prefix-list keywords are optional arguments. The incorrect syntax of the command is as follows:

[ no ] mpls ldp ip-forwarding [ { access-list | prefix-list } listName ) ] [ host-only ]

The correct syntax of the command is as follows:

[ no ] mpls ldp ip-forwarding { access-list | prefix-list } listName host-only

Also, the Note in the command section incorrectly states that, although the carriage return, <cr>, option is displayed when you type a question mark (?) after entering the mpls ldp ip-forwarding command, this command takes effect only if the access-list, host-only, or prefix-list keyword, or a combination of them is specified. Additionally, it mentions that although the command is configured successfully and no error is displayed, labels are not used in the IP routing table for forwarding plain IP traffic.

The correct configuration behavior of this command is that you must enter one of the two keywords, specifically, access-list or prefix-list, along with the mpls ldp ip-forwarding command and the host-only keyword. Either of these keywords is required to enable labels to be used in the IP routing table for forwarding plain IP traffic. An error message is displayed when you press Enter to add LSPs to the routing table without specifying the access list or prefix list.

• The description of the ppp initiate-ip command in the JunosE Command Reference N to Z Guide fails to state the following information about this command:

Passive PPP clients are those subscribers configured with passive mode on dynamic or static PPP interfaces using the ppp passive-mode command. By default, passive mode is enabled on a PPP interface. Passive mode causes the PPP interfaces to wait for a period of one second before initiating LCP negotiation. This waiting period enables slow clients to start up and initiate LCP negotiation. Active PPP clients initiate the LCP negotiation process without waiting for the other side of the connection to initiate the negotiation.

If you configure a PPP interface without an IP interface or profile by not entering the ppp initiate-ip command, the router performs LCP negotiation for 2 to 3 minutes for passive clients. LCP negotiation is terminated after this period. To enable LCP negotiations to continue to occur for passive clients, you must enter the ppp initiate-ip command to enable PPP to create IP instances.

• The description of the ppp initiate-ipv6 command in the JunosE Command Reference N to Z Guide fails to state the following information about this command:

Passive PPP clients are those subscribers configured with passive mode on dynamic or static PPP interfaces using the ppp passive-mode command. By default, passive mode is enabled on a PPP interface. Passive mode causes the PPP interfaces to wait for a period of one second before initiating LCP negotiation. This waiting period enables slow clients to start up and initiate LCP negotiation. Active PPP clients initiate the LCP negotiation process without waiting for the other side of the connection to initiate the negotiation.

If you configure a PPP interface without an IPv6 interface or profile by not entering the ppp initiate-ipv6 command, the router performs LCP negotiation for 2 to 3 minutes for passive clients. LCP negotiation is terminated after this period. To enable LCP negotiations to continue to occur for passive clients, you must enter the ppp initiate-ipv6 command to enable PPP to create IPv6 instances.