Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

TechLibrary
Table of Contents
Navigation  Back up to About Overview 
ContentIndex
 
[+] Expand All
[-] Collapse All

Errata and Changes in Documentation for Junos OS Release 12.3 for M Series, MX Series, and T Series Routers

Errata

Hardware

  • The Protocols and Applications Supported by MX240, MX480, MX960, MX2010, and MX2020 MPCs topic erroneously states that support was introduced in Junos OS Release 10.4 for IEEE 802.3ah OAM (discovery and link monitoring, fault signaling and detection, and remote loopback). In fact, this support was introduced in Junos OS Release 11.1.

Class of Service

  • The Example: Configuring Scheduling Modes on Aggregated Interfaces topic fails to mention the following additional information regarding the parameters that are scaled for aggregated interface member links when the scheduler parameters are configured using scheduler maps:

    Apart from transmit rate and buffer size that are scaled when the parameters are configured using scheduler maps, shaping rate is also scaled if you configure it in bits per second (bps). Shaping rate is not scaled if you configure it as a percentage of the available interface bandwidth.

    [Class of Service, Schedulers on Aggregated Ethernet and SONET/SDH Interfaces]

  • The following additional information regarding the processing of custom EXP rewrite rules on MPCs applies to the Rewriting IEEE 802.1p Packet Headers with an MPLS EXP Value topic:

    For MPCs, default EXP rewrite rules do not exist for logical interfaces. The EXP CoS bits for MPLS labels are obtained from the IP precedence bits for IP traffic. The EXP bits for labels that are pushed or swapped are inherited from the current label of the MPLS packets. For non-IP and non-MPLS packets, the EXP bits are set to 0. If a custom EXP rewrite rule is configured on the core-facing interface, then it overrides the EXP bits.

    [Class of Service, CoS Re-Marking of Packets Entering or Exiting the Network]

  • The Configuring Tunnel Interfaces on MX Series Routers topic in the Services Interfaces Configuration Guide fails to state that Ingress queuing and tunnel services cannot be configured on the same MPC as it causes the Packet Forwarding Engine forwarding to stop. Each feature can, however, be configured and used separately.
  • The enhanced-policer topic in the Junos OS Subscriber Access Configuration Guide fails to include a reference to the Enhanced Policer Statistics Overview topic. The overview topic explains how the enhanced policer enables you to analyze traffic statistics for debugging purposes.

    The enhanced policer statistics are as follows:

    • Offered packet statistics for traffic subjected to policing.
    • OOS packet statistics for packets that are marked out-of-specification by the policer. Changes to all packets that have out-of-specification actions, such as discard, color marking, or forwarding-class, are included in this counter.
    • Transmitted packet statistics for traffic that is not discarded by the policer. When the policer action is discard, the statistics are the same as the statistics that are within specification; when the policer action is non-discard (loss-priority or forwarding-class), the statistics are included in this counter.

    To enable collection of enhanced statistics, include the enhanced-policer statement at the [edit chassis] hierarchy level. To view these statistics, include the detail option when you issue the show firewall, show firewall filter filter-name, or show policer command.

High Availability (HA) and Resiliency

  • The MPC3E on MX Series Routers Overview topic in the Junos OS System Basics: Chassis-Level Features Configuration Guide incorrectly states that configuration of an MX Series Virtual Chassis is not supported on an MPC3E module. In fact, the MPC3E module supports all MX Series Virtual Chassis features, including Layer 2 and IEEE 802.3ad link aggregation features.

    An MX Series Virtual Chassis configuration on an MPC3E module or on MPC/MIC interfaces does not support the Spanning Tree Protocol.

    [See MPC3E on MX Series Routers Overview.]

  • In Junos OS Release 11.4 and later releases, the Example: Replacing a Routing Engine in a Virtual Chassis Configuration for MX Series 3D Universal Edge Routers topic in the MX Series Interchassis Redundancy Using Virtual Chassis pathway page failed to mention that for a replacement Routing Engine shipped from the factory that you plan to install in an MX Series Virtual Chassis member router, you must modify the default factory configuration to enable proper operation of the Virtual Chassis. The documentation has been updated to include this information in Junos OS Release 13.2 and later releases, as follows:

    A Routing Engine shipped from the factory is loaded with a default factory configuration that includes the following stanza at the [edit] hierarchy level:

    [edit]
    system {commit {factory-settings {reset-virtual-chassis-configuration;}}}

    When this configuration stanza is present, the Routing Engine can operate only in a standalone chassis and not in an MX Series Virtual Chassis member router. As a result, if you install this Routing Engine in the standby slot of a Virtual Chassis member router (member1-re1 in this example), the Routing Engine does not automatically synchronize with the master Routing Engine and boot in Virtual Chassis mode.

    To ensure that the standby factory Routing Engine successfully synchronizes with the master Routing Engine, you must remove this standalone chassis configuration stanza from the standby factory Routing Engine and verify that it reboots in Virtual Chassis mode before you install the Junos OS release.

    To modify the Routing Engine factory configuration to ensure proper operation of the MX Series Virtual Chassis:

    1. Log in to the console of the new Routing Engine as the user root with no password.
    2. Configure a plain-text password for the root (superuser) login.
      {local:member1-re1}[edit system]root# set root-authentication plain-text-passwordNew password: type password hereRetype new password: retype password here
    3. Delete the standalone chassis configuration.
      {local:member1-re1}[edit]root# delete system commit factory-settings reset-virtual-chassis-configuration
    4. Commit the configuration.

      The new Routing Engine synchronizes the Virtual Chassis member ID with the master Routing Engine and boots in Virtual Chassis mode.

    5. Verify that the new Routing Engine is in Virtual Chassis mode.

      During the boot process, the router displays the following output to indicate that it has synchronized the Virtual Chassis member ID (1) with the master Routing Engine and is in Virtual Chassis mode.

      ...
      virtual chassis member-id = 1
      virtual chassis mode      = 1
      ...
  • For a two-member MX Series Virtual Chassis to function properly, you must enable enhanced IP network services on both member routers when you first set up the Virtual Chassis. If necessary, you can also enable enhanced IP network services for an existing Virtual Chassis.

    Enhanced IP network services defines how the router recognizes and uses certain modules. When you set each member router’s network services to enhanced-ip, only MPC/MIC modules and MS-DPC modules are powered on in the router. Non-service DPCs do not work with enhanced IP network services.

    In Junos OS Release 11.4 and later releases prior to Release 13.2, the documentation for MX Series Virtual Chassis fails to mention the required procedures for enabling enhanced IP network services.

    Use the following procedure to enable enhanced IP network services as part of the initial Virtual Chassis configuration. Perform these steps immediately after you create the preprovisioned member configuration on the master router, and before you enable graceful Routing Engine switchover (GRES) and nonstop active routing (NSR) on both member routers.

    To enable enhanced IP network services when you first set up an MX Series Virtual Chassis:

    1. Configure enhanced IP network services on member 0.
      1. Log in to the console on member 0.
      2. Access the chassis hierarchy.
        [edit]user@hostA# edit chassis
      3. Configure enhanced IP network services for member 0.
        [edit chassis]user@hostA# set network-services enhanced-ip
      4. Commit the configuration on member 0 by using the commit synchronize command.

        Note: Immediately after you commit the configuration, the software prompts you to reboot the router. You can proceed without rebooting the router at this point because a reboot occurs when you configure the member IDs to enable Virtual Chassis mode.

    2. Configure enhanced IP network services on member 1.
      1. Log in to the console on member 1.
      2. Access the chassis hierarchy.
        [edit]user@hostB# edit chassis
      3. Configure enhanced IP network services for member 1.
        [edit chassis]user@hostB# set network-services enhanced-ip
      4. Commit the configuration on member 1 by using the commit synchronize command.

        Note: Immediately after you commit the configuration, the software prompts you to reboot the router. You can proceed without rebooting the router at this point because a reboot occurs when you configure the member IDs to enable Virtual Chassis modee.

    3. (Optional) After the Virtual Chassis forms, verify that enhanced IP network services has been properly configured.
      1. Verify that enhanced IP network services is configured on the master Routing Engine in the Virtual Chassis master router (member0-re0).
        {master:member0-re0}user@hostA> show chassis network services
        Network Services Mode: Enhanced-IP
      2. Verify that enhanced IP network services is configured on the master Routing Engine in the Virtual Chassis backup router (member1-re0).
        {backup:member1-re0}user@hostB> show chassis network services
        Network Services Mode: Enhanced-IP

    Use the following procedure to enable enhanced IP network services for an existing Virtual Chassis configuration.

    To configure enhanced IP network services for an existing Virtual Chassis:

    1. Log in to the console for the master Routing Engine in the Virtual Chassis master router (member0-re0).
    2. Access the chassis hierarchy.
      {master:member0-re0}[edit]user@hostA# edit chassis
    3. Configure enhanced IP network services on member 0.
      {master:member0-re0}[edit chassis]user@hostA# set network-services enhanced-ip
    4. Commit the configuration by using the commit synchronize command.

    5. When prompted to do so, reboot both Routing Engines in each member router forming the Virtual Chassis.

      • For Junos OS Releases 11.4, 12.1, 12.2, 12.3R1, and 12.3R2:
        {master:member0-re0}user@hostA> request system reboot member 0 other-routing-engineuser@hostA> request system reboot member 1 other-routing-engineuser@hostA> request system reboot
      • For Junos OS Release 12.3R3 and later releases:
        {master:member0-re0}user@hostA> request system reboot
      Rebooting all Routing Engines in the Virtual Chassis propagates the enhanced IP network services configuration to both member routers.
    6. (Optional) Verify that enhanced IP network services has been properly configured for the Virtual Chassis.
      1. Verify that enhanced IP network services is configured on the master Routing Engine in the Virtual Chassis master router (member0-re0).
        {master:member0-re0}user@hostA> show chassis network services
        Network Services Mode: Enhanced-IP
      2. Verify that enhanced IP network services is configured on the master Routing Engine in the Virtual Chassis backup router (member1-re0).
        {backup:member1-re0}user@hostB> show chassis network services
        Network Services Mode: Enhanced-IP
  • The following additional information applies to the Virtual Chassis Components Overview topic in the Interchassis Redundancy Using Virtual Chassis Feature Guide for MX Series Routers for Junos OS Release 11.2 and later releases.

    When you configure chassis properties for MPCs installed in a member router in an MX Series Virtual Chassis, keep the following points in mind:

    • Statements included at the [edit chassis member member-id fpc slot slot-number] hierarchy level apply to the MPC (FPC) in the specified slot number only on the specified member router in the Virtual Chassis.

      For example, if you issue the set chassis member 0 fpc slot 1 power off statement, only the MPC installed in slot 1 of member ID 0 in the Virtual Chassis is powered off.

    • Statements included at the [edit chassis fpc slot slot-number] hierarchy level apply to the MPCs (FPCs) in the specified slot number on each member router in the Virtual Chassis.

      For example, if you issue the set chassis fpc slot 1 power off statement in a two-member MX Series Virtual Chassis, both the MPC installed in slot 1 of member ID 0 and the MPC installed in slot 1 of member ID 1 are powered off.

    Best Practice: To ensure that the statement you use to configure MPC chassis properties in a Virtual Chassis applies to the intended member router and MPC, we recommend that you always include the member member-ID option before the fpc keyword, where member-id is 0 or 1 for a two-member MX Series Virtual Chassis.

Infrastructure

  • The following additional information regarding the configuration of peer IP addresses for ICCP peers and multichassis protection for MC-LAG applies to the Configuring ICCP for MC-LAG topic:

    For Inter-Chassis Control (ICCP) in a multichassis link aggregation group (MC-LAG) configured in an active-active bridge domain, you must ensure that you configure the same peer IP address hosting the MC-LAG by including the peer ip-address statement at the [edit protocols iccp] hierarchy level and the multi-chassis-protection peer ip-address statement at the [edit interfaces interface-name] hierarchy level. Multichassis protection reduces the configuration at the logical interface level for MX Series routers with multichassis aggregated Ethernet (MC-AE) interfaces. If the ICCP is UP and the interchassis data link (ICL) comes UP, the router configured as standby will bring up the MC-AE interfaces shared with the peer active-active node specified by the peer statement.

    For example, the following statements illustrate how the same peer IP address can be configured for both the ICCP peer and multichassis protection link:

    set interfaces ae1 unit 0 multi-chassis-protection 10.255.34.112 interface ae0.0 set protocols iccp peer 10.255.34.112 redundancy-group-id-list 1

    Although you can commit an MC-LAG configuration with various parameters defined for it, you can configure multichassis protection between two peers without configuring the ICCP peer address. You can also configure multiple ICCP peers and commit such a configuration.

    [Network Interfaces, Ethernet Interfaces]

  • The following additional information regarding the behavior of the accept-data statement for MC-LAG in an active-active bridge domain applies to the Active-Active Bridging and VRRP over IRB Functionality on MX Series Routers Overview topic:

    For a multichassis link aggregation group (MC-LAG) configured in an active-active bridge domain and with VRRP configured over an integrated routing and bridging (IRB) interface, you must include the accept-data statement at the [edit interfaces interface-name unit logical-unit-number family inet address address vrrp-group group-id] hierarchy level to enable the router that functions as the master router to accept all packets destined for the virtual IP address.

    On an MC-LAG, if you modify the source MAC address to be the virtual MAC address, you must specify the virtual IP address as the source IP address instead of the physical IP address. In such a case, the accept-data option is required for VRRP to prevent ARP from performing an incorrect mapping between IP and MAC addresses for customer edge (CE) devices. The accept-data attribute is needed for VRRP over IRB interfaces in MC-LAG to enable OSPF or other Layer 3 protocols and applications to work properly over multichassis aggregated Ethernet (mc-aeX) interfaces.

    [Network Interfaces, Ethernet Interfaces]

  • The following additional information regarding the support of vlan-id none statement for MC-LAG applies to the Active-Active Bridging and VRRP over IRB Functionality on MX Series Routers Overview topic:

    In an IPv6 network, you cannot configure a multichassis link aggregation group (MC-LAG) in an active-active bridge domain if you specified the vlan-id none statement at [edit bridge-domain bd-name] hierarchy level. The vlan-id none statement that enables the removal of the incoming VLAN tags identifying a Layer 2 logical interface when packets are sent over VPLS pseudowires is not supported for IPv6 packets in an MC-LAG.

    [Network Interfaces, Ethernet Interfaces]

Interfaces and Chassis

  • The Redundancy Fabric Mode on Active Control Boards subsection in the Corrective Actions for Fabric Failures on MX Series Routers topic and the Configuring Redundancy Fabric Mode for Active Control Boards on MX Series Routers topic incorrectly contain the following information about the default mode of redundant operation of active control boards on MX Series routers:

    Until Junos OS Release 12.1, the MX Series routers that contain the enhanced Switch Control Board (SCB) with MX Series router with MPCs or MICs and the MPC3E, the control boards operate in redundancy fabric mode (all the FPCs use 4 fabric planes as active planes). Starting with Junos OS Release 12.2, on MX Series routers that contain the enhanced SCB with Trio chips and the MPC3E, the control boards operate in increased fabric bandwidth mode by default (all the available fabric planes are used).

    The preceding description is incorrect because the enhanced SCB operates by default in redundancy fabric mode and not increased fabric mode in Junos OS Release 12.2 and later. The correct default operation of enhanced SCBs with Trio chips and the MPC3E is as follows:

    The MX Series routers that contain the enhanced Switch Control Board (SCB) with Trio chips and the MPC3E, the control boards operate in redundancy fabric mode (all the FPCs use 4 fabric planes as active planes) by default.

    [System Basics, Chassis-Level Features]

  • The redundancy-mode configuration statement topic fails to state the following additional information regarding the default behavior for enhanced Switch Control Board (SCB) with Trio chips and the MPC3E on MX Series routers:

    The MX Series routers that contain the enhanced Switch Control Board (SCB) with Trio chips and the MPC3E, the control boards operate in redundancy fabric mode (all the FPCs use 4 fabric planes as active planes) by default.

    [System Basics, Chassis-Level Features]

  • The following additional information regarding the binding of multiple port-mirror instances at the FPC level of M320 routers applies to the Filter-Based Forwarding with Multiple Monitoring Interfaces section in the Configuring Port Mirroring topic:

    Because M320 routers do not support multiple bindings of port-mirror instances per FPC, the port-mirror-instance action is not supported in firewall filters for these routers.

    [Services Interfaces]

  • The forwarding-mode (100-Gigabit Ethernet) configuration statement topic fails to mention that this statement is supported on MX Series routers from Junos OS Release 12.1. The Supported Platforms section of this topic fails to list MX Series routers on which this command is supported.

    [Network Interfaces, Ethernet Interfaces]

  • The show chassis fabric unreachable-destinations command is incorrectly mentioned as supported on MX240, MX480, and MX960 routers from Junos OS Release 11.4R2 and Junos OS Release 12.1. The Supported Platforms section of this topic also incorrectly states MX240, MX480, and MX960 routers as supported routers for this command. This command is not available on the MX240, MX480, and MX960 routers. Instead, the correct command is the show chassis fabric destinations command, which you can use to view the state of fabric destinations for all FPCs.

    [System Basics and Services Command Reference]

  • The Limiting traffic black-hole time by detecting Packet Forwarding Engine destinations that are unreachable over the fabric (MX240, MX480, and MX960 routers) subsection under the New Features in Junos OS Release for M Series, MX Series, and T Series Routers main section of the Junos OS 11.4 Release Notes and Junos OS 12.1 Release Notes erroneously describes that the show chassis fabric unreachable-destinations command has been introduced. The correct command that has been introduced is the show chassis fabric destinations command, which is available in Junos OS Release 11.4R2 and later, and Junos OS Release 12.1R1 and later.

    [Release Notes]

  • The following additional information regarding the working of unnumbered interfaces applies to the Example: Configuring an Unnumbered Ethernet Interface section in the Configuring an Unnumbered Interface topic:

    The sample configuration that is described works correctly on M Series and T Series routers. For unnumbered interfaces on MX Series routers, you must additionally configure static routes on an unnumbered Ethernet interface by including the qualified-next-hop statement at the [edit routing-options static route destination-prefix] hierarchy level to specify the unnumbered Ethernet interface as the next-hop interface for a configured static route.

    [Services Interfaces, Flow-Tap]

  • The following enhancements and additions apply to the Example: Configuring Multichassis Link Aggregation in an Active- Active Bridging Domain on MX Series Routers topic:
    • The Topology Diagram section fails to mention that interface ge-1/0/2 functions as the ICCP link between the two PE devices, interface ge-1/1/1 is the ICL-PL link, and interface ge-1/1/4 is the link that connects to the server or the MC- LAG client device.
    • As a best practice, we recommend that you configure the ICCP and ICL interfaces over aggregated Ethernet interfaces instead of other interfaces such as Gigabit Ethernet interfaces, depending on your topology requirements and framework.
    • You must disable RSTP on the ICL-PL interfaces for an MC-LAG in an active-active bridging domain.
    • The Step-by-Step Procedure section for Router PE2 that is illustrated in the example is missing, although the quick configuration statements are presented.

      To configure Router PE2:

      1. Specify the number of aggregated Ethernet interfaces to be created.

        [edit chassis]user@PE2# set aggregated-devices ethernet device-count 5

      2. Specify the members to be included within the aggregated Ethernet bundles.

        [edit interfaces]user@PE2# set ge-1/0/5 gigether-options 802.3ad ae1user@PE2# set ge-1/1/0 gigether-options 802.3ad ae0

      3. Configure the interfaces that connect to senders or receivers, the ICL interfaces, and the ICCP interfaces.

        [edit interfaces]user@PE2# set ge-1/0/3 flexible-vlan-tagginguser@PE2# set ge-1/0/3 encapsulation flexible-ethernet-servicesuser@PE2# set ge-1/0/3 unit 0 encapsulation vlan-bridgeuser@PE2# set ge-1/0/3 unit 0 vlan-id-range 100-110user@PE2# set ge-1/0/4 flexible-vlan-tagginguser@PE2# set ge-1/0/4 encapsulation flexible-ethernet-servicesuser@PE2# set ge-1/0/4 unit 0 encapsulation vlan-bridgeuser@PE2# set ge-1/0/4 unit 0 vlan-id-range 100-110user@PE2# set ge-1/0/5 gigether-options 802.3ad ae0user@PE2# set ge-1/1/0 gigether-options 802.3ad ae1

      4. Configure parameters on the aggregated Ethernet bundles.

        [edit interfaces ae0]user@PE2# set flexible-vlan-tagginguser@PE2# set encapsulation flexible-ethernet-servicesuser@PE2# set unit 0 encapsulation vlan-bridgeuser@PE2# set unit 0 vlan-id-range 100-110user@PE2# set unit 0 multi-chassis-protection 100.100.100.1 interface ge-1/0/4.0
        [edit interfaces ae1]user@PE2# set flexible-vlan-tagginguser@PE2# set encapsulation flexible-ethernet-servicesuser@PE2# set unit 0 encapsulation vlan-bridgeuser@PE2# set unit 0 vlan-id-range 100-110user@PE2# set unit 0 multi-chassis-protection 100.100.100.1 interface ge-1/0/4.0

      5. Configure LACP on the aggregated Ethernet bundles.

        [edit interfaces ae0 aggregated-ether-options]user@PE2# set lacp activeuser@PE2# set lacp system-priority 100user@PE2# set lacp system-id 00:00:00:00:00:05user@PE2# set lacp admin-key 1
        [edit interfaces ae1 aggregated-ether-options]user@PE2# set lacp activeuser@PE2# set lacp system-priority 100user@PE2# set lacp system-id 00:00:00:00:00:05user@PE2# set lacp admin-key 1

      6. Configure the MC-LAG interfaces.

        [edit interfaces ae0 aggregated-ether-options]user@PE2# set mc-ae mc-ae-id 5user@PE2# set mc-ae redundancy-group 10user@PE2# set mc-ae chassis-id 1user@PE2# set mc-ae mode active-activeuser@PE2# set mc-ae status-control active
        [edit interfaces ae1 aggregated-ether-options]user@PE2# set mc-ae mc-ae-id 10user@PE2# set mc-ae redundancy-group 10user@PE2# set mc-ae chassis-id 1user@PE2# set mc-ae mode active-activeuser@PE2# set mc-ae status-control active
        The multichassis aggregated Ethernet identification number (mc-ae-id) specifies which link aggregation group the aggregated Ethernet interface belongs to. The ae0 interfaces on Router PE1 and Router PE2 are configured with mc-ae-id 5. The ae1 interfaces on Router PE1 and Router PE2 are configured with mc-ae-id 10.

        The redundancy-group 10 statement is used by ICCP to associate multiple chassis that perform similar redundancy functions and to establish a communication channel so that applications on peering chassis can send messages to each other. The ae0 and ae1 interfaces on Router PE1 and Router PE2 are configured with the same redundancy group redundancy-group 10.

        The chassis-id statement is used by LACP for calculating the port number of the MC-LAG's physical member links. Router PE2 uses chassid-id 1 to identify both its ae0 and ae1 interfaces. Router PE2 uses chassis-id 0 to identify both its ae0 and ae1 interfaces.

        The mode statement indicates whether an MC-LAG is in active-standby mode or active-active mode. Chassis that are in the same group must be in the same mode.

      7. Configure a domain that includes the set of logical ports.

        [edit bridge-domains bd0]user@PE2# set domain-type bridgeuser@PE2# set vlan-id alluser@PE2# set service-id 20user@PE2# set interface ae0.0user@PE2# set interface ae1.0user@PE2# set interface ge-1/0/3.0user@PE2# set interface ge-1/1/1.0user@PE2# set interface ge-1/1/4.0
        The ports within a bridge domain share the same flooding or broadcast characteristics in order to perform Layer 2 bridging.

        The bridge-level service-id statement is required to link related bridge domains across peers (in this case Router PE1 and Router PE2), and should be configured with the same value.

      8. Configure ICCP parameters.

        [edit protocols iccp]user@PE2# set local-ip-addr 100.100.100.2user@PE2# set peer 100.100.100.1 redundancy-group-id-list 10user@PE2# set peer 100.100.100.1 liveness-detection minimum-interval 1000

      9. Configure the service ID at the global level.

        [edit switch-options]user@PE2# set service-id 10
        You must configure the same unique network-wide configuration for a service in the set of PE routers providing the service. This service ID is required if the multichassis aggregated Ethernet interfaces are part of a bridge domain.

    [Network Interfaces, Ethernet Interfaces]

  • The following additional information regarding the compatibility of modules for the interoperation of RPM clients and RPM servers applies to the Configuring RPM Probes section in the Configuring Real-Time Performance Monitoring topic:

    Keep the following points in mind when you configure RPM clients and RPM servers:

    • You cannot configure an RPM client that is PIC-based and an RPM server that is based on either the Packet Forwarding Engine or Routing Engine to receive the RPM probes.
    • You cannot configure an RPM client that is Packet Forwarding Engine-based and an RPM server that receives the RPM probes to be on the PIC or Routing Engine.
    • The RPM client and RPM server must be located on the same type of module. For example, if the RPM client is PIC-based, the RPM server must also be PIC-based, and if the RPM server is Packet Forwarding Engine-based, the RPM client must also be Packet Forwarding Engine-based.

    [System Basics, Chassis-Level Features]

  • The following corrections apply to the Example: Configuring One VPLS Instance for Several VLANs topic:

    The following sentence is erroneously presented:

    If VLANs 1 through 1000 for customer C1 span the same sites, then the vlan-id all and vlan-id-list-range statements provide a way to switch all of these VLANs with a minimum configuration effort and fewer switch resources.

    The correct description is as follows:

    If VLANs 1 through 1000 for customer C1 span the same sites, then the vlan-id all and vlan-id-list statements provide a way to switch all of these VLANs with a minimum configuration effort and fewer switch resources.

    The following example replaces the existing example that illustrates the use of the vlan-id all statement:

    [edit]
    interfaces ge-1/0/0 {encapsulation flexible-ethernet-services;flexible-vlan-tagging;unit 1 {encapsulation vlan-vpls;family bridge {interface-mode trunk;vlan-id-list 1-1000; # Note the use of the VLAN id list statement.}}unit 11 {encapsulation vlan-vpls;family bridge {interface-mode trunk;vlan-id-list 1500;}}}
    interfaces ge-2/0/0 {encapsulation flexible-ethernet-services;flexible-vlan-tagging;unit 1 {encapsulation vlan-vpls;family bridge {interface-mode trunk;vlan-id-list 1-1000; # Note the use of the VLAN id list statement.}}}
    interfaces ge-3/0/0 {encapsulation flexible-ethernet-services;flexible-vlan-tagging;family bridge {unit 1 {encapsulation vlan-vpls;interface-mode trunk;vlan-id-list 1-1000; # Note the use of the VLAN id list statement.}}}
    interfaces ge-6/0/0 {encapsulation flexible-ethernet-services;flexible-vlan-tagging;family bridge {unit 11 {encapsulation vlan-vpls;interface-mode trunk;vlan-id-list 1500;}}}
    routing-instances {customer-c1-virtual-switch {instance-type virtual-switch;interface ge-1/0/0.1;interface ge-2/0/0.1;interface ge-3/0/0.1;bridge-domains {c1-vlan-v1-to-v1000 {vlan-id all; # Note the use of the VLAN id all statement}}} # End of customer-c1-v1-to-v1000customer-c2-virtual-switch {instance-type virtual-switch;interface ge-1/0/0.11;interface ge-6/0/0.11;bridge-domains {c1-vlan-v1500 {vlan-id all; # Note the use of the VLAN id all statement}}} # End of customer-c1-v1500} # End of routing-instances

    Note the use of the vlan-id all statement in the virtual-switch instance called customer-c1-v1-to-v1000.

    [MX Series Ethernet Services Routers Solutions Guide]

  • The Junos OS 12.3 Release Notes did not report that the default bandwidth and burst values for DDoS protection changed for the aggregate, host, pfe, syslog, and tap packet types in the sample protocol group. In releases before Junos OS Release 12.3, the default bandwidth value was 10,000 pps and the default burst size value was 10,000 packets. Beginning in Junos OS Release 12.3, the default values are 1000 pps for bandwidth and 1000 packets for burst size.
  • The open-timeout configuration statement topic and the Configuring Default Timeout Settings for Services Interfaces topic incorrectly state that the default value of the timeout period for TCP session establishment is 30 seconds. The correct default value is 5 seconds.

    [System Basics, Chassis-Level Features]

  • The Supported Platforms section of the set chassis display message command topic erroneously states that this command is supported on MX Series routers. This command is not available on MX Series routers.

    [System Basics, Chassis-Level Features]

  • The IP Demux Interfaces over Static or Dynamic VLAN Demux Interfaces topic incorrectly states that both DPCs and MPCs support VLAN demux subscriber interfaces. In fact, only MPCs support these interfaces.

Junos OS XML API and Scripting

  • The NETCONF XML Management Protocol Guide incorrectly states that when performing a confirmed commit operation using the <commit> element, the <confirm-timeout> value specifies the number of minutes for the rollback deadline. The value of the <confirm-timeout> element actually specifies the number of seconds for the rollback deadline.

    [NETCONF XML Management Protocol Guide]

Layer 2 Ethernet Services

  • The following information regarding the differences in the default limit on MAC addresses that can be learned on an access port and a trunk port is inadvertently omitted from the Limiting MAC Addresses Learned from an Interface in a Bridge Domain topic:
    • For an access port, the default limit on the maximum number of MAC addresses that can be learned on an access port is 1024. Because an access port can be configured in only one bridge domain in a network topology, the default limit is 1024 addresses, which is same as the limit for MAC addresses learned on a logical interface in a bridge domain (configured by including the interface-mac-limit limit statement at the [edit bridge-domains bridge-domain-name bridge-options interface interface-name] or [edit bridge-domains bridge-domain-name bridge-options] hierarchy level.
    • For a trunk port, the default limit on the maximum number of MAC addresses that can be learned on a trunk port is 8192. Because a trunk port can be associated with multiple bride domains, the default limit is the same as the limit for MAC addresses learned on a logical interface in a virtual switch instance (configured by including the interface-mac-limit limit statement at the [edit routing-instances routing-instance-name switch- options interface interface-name] for a virtual switch instance).

MPLS

  • The "Configuring Miscellaneous LDP Properties," "Configuring the Authentication Key Update Mechanism for BGP and LDP Routing Protocols," "authentication-key-chain (LDP)," and "authentication-key-chain (BGP and BMP)” topics should include the following information: You must also configure the authentication algorithm using the authentication-algorithm algorithm statement. This statement must be included at the [edit protocols (bgp | ldp)] hierarchy level when you configure the authentication-key-chain key-chain statement at the [edit protocols (bgp | ldp)] hierarchy level.

    [MPLS]

  • The "Path Computation for LSPs on an Overloaded Router" topic should state that when you set the overload bit on a router running IS-IS, only new LSPs are prevented from transiting through the router. Any existing Constrained Path Shortest First (CPSF) LSPs remain active and continue to transit through the router. The documentation incorrectly states that any existing LSPs transiting through the router are also rerouted when you configure the overload bit on an IS-IS router.

Network Management and Monitoring

  • The documentation fails to clearly describe the characters that can be used for SNMPv3 authentication passwords. Besides numbers, uppercase letters, and lowercase letters, the following special characters are supported:

    , . / \ < > ; : ' [ ] { } ~ ! @ # $ % ^ * _ + = - `

    In addition, the following special characters are also supported, but you must enclose them within quotation marks (“”) if you enter them on the CLI; if you use a Network Management System to enter the password, the quotation marks are not required:

    | & ( ) ?

    The documentation also fails to clearly state that characters entered by simultaneously pressing the Ctrl key and additional keys are not supported. [PR/883083: This issue has been resolved]

  • The syntax of the filter-interfaces statement in the SNMP Configuration Statement section is incorrect. The correct syntax is as follows:
    filter-interfaces {all-internal-interfaces;interfaces interface-names{interface 1;interface 2;}}

Routing Policy and Firewall Filters

  • The OSPF Configuration Guide incorrectly includes the transmit-interval statement at the [edit protocols ospf area area interface interface-name] hierarchy level. The transmit-interval statement at this hierarchy level is deprecated in the Junos OS command-line interface.

    [OSPF Configuration Guide]

Routing Protocols

  • In routing instances, when a BGP neighbor sends BGP messages to the local routing device, the incoming interface on which these messages are received must be configured in the same routing instance that the BGP neighbor configuration exists in. This is true for neighbors that are a single hop away or multiple hops away. [Routing Protocols]

Services Applications

  • The show services stateful-firewall subscriber-analysis command should be included in the System Basics and Services Command Reference Guide. This command displays information about the number of active subscribers on the service physical interface card (PIC).
  • The show services stateful-firewall flow-analysis command should be included in the System Basics and Services Command Reference Guide. This command displays stateful firewall flow statistics.”
  • In the Next-Generation Network Addressing Carrier-Grade NAT and IPv6 Solutions Guide, the section “Configuring Address Pools for Network Address Port Translation” should be revised as follows: The following variables should be added Nr_Addr_PR_Prefix – Number of usable pre-NAT IPv4 subscriber addresses in a “from” clause match condition Nr_Addr_PU_Prefix – Number of usable post-NAT IPv4 addresses configured in the NAT pool Rounded_Port_Range_Per_IP – ceil[(Nr_Addr_PR_Prefix/Nr_Addr_PU_Prefix)] * Block_Size The Forward Translation formulas should be: 1. Pr_Offset = Pr_Prefix- Base_Pr_Prefix 2. Pr_Port_Offset = Pr_Offset * Block_Size 3. Rounded_Port_Range_Per_IP = ceil[(Nr_Addr_PR_Prefix/Nr_Addr_PU_Prefix)] * Block_Size 4. Pu_Prefix = Base_Public_Prefix + floor(Pr_Port_Offset/Rounded_Port_Range_Per_IP) 5. Pu_Start_Port = Pu_Port_Range_Start + (Pr_Port_Offset % Rounded_Port_Range_Per_IP) The Reverse Translation formulas should be: 1. Pu_Offset = Pu_Prefix - Base_Pu_Prefix 2. Pu_Port_Offset = (Pu_Offset * Rounded_Port_Range_Per_IP) + (Pu_Actual_Port - Pu_Port_Range_Start) 3. Subscriber_IP = Base_Pr_Prefix + floor(Pu_Port_Offset / Block_Size)
  • The following information should be added to the syntax of the “service-set (Services)” configuration statement topic in the Services Interfaces Configuration Guide. This information should appear under the service-set service-set-name level:
    service-set-options { bypass-traffic-on-exceeding-flow-limits;bypass-traffic-on-pic-failure;enable-asymmetric-traffic-processing;support-uni-directional-traffic;}

    This issue was being tracked by PR888803.

  • The following information should replace Table 1 and the section “Sample Output” in the “show services stateful-firewall statististics” topic in the System Basics and Services Command Reference:

    Table 5: show services stateful-firewall statistics Output Fields

    Field Name

    Field Description

    Interface

    Name of an adaptive services interface.

    Service set

    Name of a service set.

    New flows

    Rule match counters for new flows:

    • Rule Accepts—New flows accepted.
    • Rule Discards—New flows discarded.
    • Rule Rejects—New flows rejected.

    Existing flow types packet counters

    Rule match counters for existing flows:

    • Accepts—Match existing forward or watch flow.
    • Drop—Match existing discard flow.
    • Rejects—Match existing reject flow.

    Hairpinning Counters

    Hairpinning counters:

    • Slow Path Hairpinned Packets—Slow path packets that were hairpinned back to the internal network.
    • Fast Path Hairpinned Packets—Fast path packets that were hairpinned back to the internal network.

    Drops

    Drop counters:

    • IP option—Packets dropped in IP options processing.
    • TCP SYN defense—Packets dropped by SYN defender.
    • NAT ports exhausted—Hide mode. The router has no available Network Address Translation (NAT) ports for a given address or pool.
    • Sessions dropped due to subscriber flow limit—Sessions dropped because the subscriber’s flow limit was exceeded.

    Errors

    Total errors, categorized by protocol:

    • IP—Total IP version 4 errors.
    • TCP—Total Transmission Control Protocol (TCP) errors.
    • UDP—Total User Datagram Protocol (UDP) errors.
    • ICMP—Total Internet Control Message Protocol (ICMP) errors.
    • Non-IP packets—Total non-IPv4 errors.
    • ALG—Total application-level gateway (ALG) errors

    IP Errors

    IPv4 errors:

    • IP packet length inconsistencies—IP packet length does not match the Layer 2 reported length.
    • Minimum IP header length check failures—Minimum IP header length is 20 bytes. The received packet contains less than 20 bytes.
    • Reassembled packet exceeds maximum IP length—After fragment reassembly, the reassembled IP packet length exceeds 65,535.
    • Illegal source address 0—Source address is not a valid address. Invalid addresses are, loopback, broadcast, multicast, and reserved addresses. Source address 0, however, is allowed to support BOOTP and the destination address 0xffffffff.
    • Illegal destination address 0—Destination address is not a valid address.  The address is reserved.
    • TTL zero errors—Received packet had a time-to-live (TTL) value of 0.
    • Illegal IP protocol number (0 or 255)—IP protocol is 0 or 255.
    • Land attack—IP source address is the same as the destination address.
    • Non-IPv4 packets—Packet was not IPv4. (Only IPv4 is supported.)
    • Bad checksum—Packet had an invalid IP checksum.
    • Illegal IP fragment length—Illegal fragment length. All fragments (other than the last fragment) must have a length that is a multiple of 8 bytes.
    • IP fragment overlap—Fragments have overlapping fragment offsets.
    • IP fragment reassembly timeout—Some of the fragments for an IP packet were not received in time, and the reassembly handler dropped partial fragments.
    • IP fragment limit exceeded: 0—Fragments that exceeded the limit.
    • Unknown: 0—Unknown fragments.

    TCP Errors

    TCP protocol errors:

    • TCP header length inconsistencies—Minimum TCP header length is 20 bytes, and the IP packet received does not contain at least 20 bytes.
    • Source or destination port number is zero—TCP source or destination port is zero.
    • Illegal sequence number and flags combinations — Dropped because of TCP errors, such as an illegal sequence number, which causes an illogical combination of flags to be set.
    • SYN attack (multiple SYN messages seen for the same flow)—Multiple SYN packets received for the same flow are treated as a SYN attack. The packets might be retransmitted SYN packets and therefore valid, but a large number is cause for concern.
    • First packet not a SYN message—First packets for a connection are not SYN packets. These packets might originate from previous connections or from someone performing an ACK/FIN scan.
    • TCP port scan (TCP handshake, RST seen from server for SYN)—In the case of a SYN defender, if an RST (reset) packet is received instead of a SYN/ACK message, someone is probably trying to scan the server. This behavior can result in false alarms if the RST packet is not combined with an intrusion detection service (IDS).
    • Bad SYN cookie response—SYN cookie generates a SYN/ACK message for all incoming SYN packets. If the ACK received for the SYN/ACK message does not match, this counter is incremented.
    • TCP reconstructor sequence number error—This counter is incremented in the following cases:

      The TCP seqno is 0 and all the TCP flags are also 0.

      The TCP seqno is 0 and FIN/PSH/URG TCP flags are set.

    • TCP reconstructor retransmissions—This counter is incremented for the retransmitted packets during connection 3-way handshake.
    • TCP partially opened connection timeout (SYN)—This counter is incremented when the SYN Defender is enabled and the 3-way handshake is not completed within the SYN DEFENDER TIMEOUT. The connection will be closed and resources will be released by sending RST to the responder.
    • TCP partially opened connection timeout (SYN-ACK)—This counter is incremented when the SYN Defender is enabled and the 3-way handshake is not completed within the SYN DEFENDER TIMEOUT. The connection will be closed and resources will be released by sending RST to the responder.
    • TCP partially closed connection reuse—Not supported.
    • TCP 3-way error - client sent SYN+ACK—A SYN/ACK should be sent by the server on receiving a SYN. This counter is incremented when the first message received from the initiator is SYN+ACK.
    • TCP 3-way error - server sent ACK—ACK should be sent by the client on receiving a SYN/ACK from the server. This counter is incremented when the ACK is received from the Server instead of from the Client.
    • TCP 3-way error - SYN seq number retransmission mismatch—This counter is incremented when the SYN is received again with a different sequence number from the first SYN sequence number.
    • TCP 3-way error - RST seq number mismatch—A reset could be received from either side. The server could send a RST on receiving a SYN or the client could send a RST on receiving SYN/ACK. This counter is incremented when the RST is received either from the client or server with a non-matching sequence number.
    • TCP 3-way error - FIN received—This counter is incremented when the FIN is received during the 3-way handshake.
    • TCP 3-way error - invalid flags (PSH, URG, ECE, CWR)—This counter is incremented when any of the PSH, URG, ECE, or CWR flags were received during the 3-way handshake.
    • TCP 3-way error - SYN recvd but no client flows—This counter is incremented when SYN is received but not from the connection initiator. The counter is not incremented in the case of simultaneous open, when the SYN is received in both the directions.
    • TCP 3-way error - first packet SYN+ACK—The first packet received was SYN+ACK instead of SYN.
    • TCP 3-way error - first packet FIN+ACK—The first packet received was FIN+ACK instead of SYN.
    • TCP 3-way error - first packet FIN—The first packet received was FIN instead of SYN.
    • TCP 3-way error - first packet RST—The first packet received was RST instead of SYN.
    • TCP 3-way error - first packet ACK—The first packet received was ACK instead of SYN.
    • TCP 3-way error - first packet invalid flags (PSH, URG, ECE, CWR)—The first packet received had invalid flags.
    • TCP Close error - no final ACK—This counter is incremented when ACK is not received after the FINs are received from both directions.
    • TCP Resumed Flow—Plain ACKs create flows if rule match permits, and these are classified as TCP Resumed Flows. This counter is incremented in the case of a TCP Resumed Flow.

    UDP Errors

    UDP protocol errors:

    • IP data length less than minimum UDP header length (8 bytes)—Minimum UDP header length is 8 bytes. The received IP packets contain less than 8 bytes.
    • Source or destination port is zero—UDP source or destination port is 0.
    • UDP port scan (ICMP error seen for UDP flow)—ICMP error is received for a UDP flow. This could be a genuine UDP flow, but it is counted as an error.

    ICMP Errors

    ICMP protocol errors:

    • IP data length less than minimum ICMP header length (8 bytes)—ICMP header length is 8 bytes. This counter is incremented when received IP packets contain less than 8 bytes.
    • ICMP error length inconsistencies—Minimum length of an ICMP error packet is 48 bytes, and the maximum length is 576 bytes. This counter is incremented when the received ICMP error falls outside this range.
    • Duplicate ping sequence number—Received ping packet has a duplicate sequence number.
    • Mismatched ping sequence number—Received ping packet has a mismatched sequence number.
    • No matching flow—No matching existing flow was found for the ICMP error.

    ALG errors

    Accumulation of all the application-level gateway protocol (ALG) drops counted separately in the ALG context:

    • BOOTP—Bootstrap protocol errors
    • DCE-RPC—Distributed Computing Environment-Remote Procedure Call protocols errors
    • DCE-RPC portmap—Distributed Computing Environment-Remote Procedure Call protocols portmap service errors
    • DNS—Domain Name System protocol errors
    • Exec—Exec errors
    • FTP—File Transfer Protocol errors
    • H323—H.323 standards errors
    • ICMP—Internet Control Message Protocol errors
    • IIOP—Internet Inter-ORB Protocol errors
    • Login—Login errors
    • NetBIOS—NetBIOS errors
    • Netshow—NetShow errors
    • Real Audio—RealAudio errors
    • RPC—Remote Procedure Call protocol errors
    • RPC portmap—Remote Procedure Call protocol portmap service errors
    • RTSP—Real-Time Streaming Protocol errors
    • Shell—Shell errors
    • SIP—Session Initiation Protocol errors
    • SNMP—Simple Network Management Protocol errors
    • SQLNet—SQLNet errors
    • TFTP—Trivial File Transfer Protocol errors
    • Traceroute—Traceroute errors

    Drop Flows

    • Maximum Ingress Drop flows allowed-–Maximum number of ingress flow drops allowed.
    • Maximum Egress Drop flows allowed-–Maximum number of egress flow drops allowed.
    • Current Ingress Drop flows-–Current number of ingress flow drops.
    • Current Egress Drop flows-–Current number of egress flow drops.
    • Ingress Drop Flow limit drops count-–Number of ingress flow drops due to maximum number of ingress flow drops being exceeded.
    • Egress Drop Flow limit drops count-–Number of egress flow drops due to maximum number of egress flow drops being exceeded.

    show services stateful-firewall statistics extensive

    user@host> show services stateful-firewall statistics extensive 
    Interface: ms-1/3/0
  Service set: interface-svc-set
    New flows:
      Rule Accepts: 907, Rule Discards: 0, Rule Rejects: 0
    Existing flow types packet counters:
      Accepts: 3535, Drop: 0, Rejects: 0
    Haripinning counters:
      Slow Path Hairpinned Packets: 0, Fast Path Hairpinned Packets: 0
    Drops:
      IP option: 0, TCP SYN defense: 0
      NAT ports exhausted: 0, Sessions dropped due to subscriber flow limit: 0
    Errors:
      IP: 0, TCP: 0
      UDP: 0, ICMP: 0
      Non-IP packets: 0, ALG: 0
    IP errors:
      IP packet length inconsistencies: 0
      Minimum IP header length check failures: 0
      Reassembled packet exceeds maximum IP length: 0
      Illegal source address: 0
      Illegal destination address: 0
      TTL zero errors: 0, Illegal IP protocol number (0 or 255): 0
      Land attack: 0
      Non-IPv4 packets: 0, Bad checksum: 0
      Illegal IP fragment length: 0
      IP fragment overlap: 0
      IP fragment reassembly timeout: 0
      IP fragment limit exceeded:0
      Unknown: 0
    TCP errors:
      TCP header length inconsistencies: 0
      Source or destination port number is zero: 0
      Illegal sequence number and flags combination: 0
      SYN attack (multiple SYN messages seen for the same flow): 0
      First packet not a SYN message: 0
      TCP port scan (TCP handshake, RST seen from server for SYN): 0
      Bad SYN cookie response: 0
      TCP reconstructor sequence number error: 0
      TCP reconstructor retransmissions: 0
      TCP partially opened connection timeout (SYN): 0
      TCP partially opened connection timeout (SYN-ACK): 0
      TCP partially closed connection reuse: 0
      TCP 3-way error - client sent SYN+ACK: 0
      TCP 3-way error - server sent ACK: 0
      TCP 3-way error - SYN seq number retransmission mismatch: 0
      TCP 3-way error - RST seq number mismatch: 0
      TCP 3-way error - FIN received: 0
      TCP 3-way error - invalid flags (PSH, URG, ECE, CWR): 0
      TCP 3-way error - SYN recvd but no client flows: 0
      TCP 3-way error - first packet SYN+ACK: 0
      TCP 3-way error - first packet FIN+ACK: 0
      TCP 3-way error - first packet FIN: 0
      TCP 3-way error - first packet RST: 0
      TCP 3-way error - first packet ACK: 0
      TCP 3-way error - first packet invalid flags (PSH, URG, ECE, CWR): 0
      TCP Close error - no final ACK: 0
      TCP Resumed Flow: 0
    UDP errors:
      IP data length less than minimum UDP header length (8 bytes): 0
      Source or destination port is zero: 0
      UDP port scan (ICMP error seen for UDP flow): 0
    ICMP errors:
      IP data length less than minimum ICMP header length (8 bytes): 0
      ICMP error length inconsistencies: 0
      Duplicate ping sequence number: 0
      Mismatched ping  sequence number: 0
      No matching flow: 0
    ALG errors:
      BOOTP: 0, DCE-RPC: 0, DCE-RPC portmap: 0
      DNS: 0, Exec: 0, FTP: 0
      H323: 0, ICMP: 0, IIOP: 0
      Login: 0, NetBIOS: 0, Netshow: 0
      Real Audio: 0, RPC: 0, RPC portmap: 0
      RTSP: 0, Shell: 0, SIP: 0
      SNMP: 0, SQLNet: 0, TFTP: 0
      Traceroute: 0
    Drop Flows:
      Maximum Ingress Drop flows allowed: 20
      Maximum Egress Drop flows allowed: 20
      Current Ingress Drop flows: 0
      Current Egress Drop flows: 0
      Ingress Drop Flow limit drops count: 0
      Egress Drop Flow limit drops count: 0

    **If max-drop-flows is not configured, the following is shown**
    Drop Flows:
      Maximum Ingress Drop flows allowed: Default
      Maximum Egress Drop flows allowed: Default
  • The following information should be added after the second paragraph of the “Configuring Inline Sampling” topic in the Services Interfaces Configuration Guide:

    The following limitations exist for inline sampling:

    • Flow records and templates cannot be exported if the flow collector is reachable through any management interface.
    • The flow collector should be reachable through the default routing table (inet.0 or inet6.0). If the flow collector is reachable via a non-default VPN routing and forwarding table (VRF), flow records and templates cannot be exported.
    • If the destination of the sampled flow is reachable through multiple paths, the IP_NEXT_HOP (Element ID 15) and OUTPUT_SNMP (Element ID 14) in the IPv4 flow record would be set to the Gateway Address and SNMP Index of the first path seen in the forwarding table.
    • If the destination of the sampled flow is reachable through multiple paths, the IP_NEXT_HOP(Element ID 15) and OUTPUT_SNMP (Element ID 14) in the IPv6 flow records would be set to 0.
    • The user-defined sampling instance gets precedence over the global instance. When a user-defined sampling instance is attached to the FPC, the global instance is removed from the FPC and the user-defined sampling instance is applied to the FPC.
    • The Incoming Interface (IIF) and Outgoing Interface (OIF) should be part of the same VRF. If OIF is in a different VRF, DST_MASK (Element ID 13), DST_AS (Element ID 17), IP_NEXT_HOP (Element ID 15), and OUTPUT_SNMP (Element ID 14) would be set to 0 in the flow records.
    • Each Lookup Chip (LU) maintains and exports flows independent of other LUs. Traffic received on a media interface is distributed across all LUs in a multi-LU platform. It is likely that a single flow will be processed by multiple LUs. Therefore, each LU creates a unique flow and exports it to the flow collector. This can cause duplicate flows records to be seen on the flow collector. The flow collector should aggregate PKTS_COUNT and BYTES_COUNT for duplicate flow records to derive a single flow record.

    This issue is being tracked by PR907991

  • The System Basics and Services Command Reference should include the following commands in the chapter “Dynamic Application Awareness Operational Mode Commands”:

    request services application-identification application: Copy, disable, or enable a predefined application signature.

    request services application-identification group: Copy, disable, or enable a predefined application signature group.

    show services application-identification application: Display detailed information about a specified application signature, all application signatures, or a summary of the existing application signatures and nested application signatures. Both custom and predefined application signatures and nested application signatures can be displayed.

    show services application-identification group: Display detailed or summary information about a specified application signature group or all application signature groups. Both custom and predefined application signature groups can be displayed.

    show services application-identification version: Display the Junos OS application package version.

  • The following command should appear in the network address operational mode commands:
    clear services nat statistics<interface interface-name><service-set service-set-name>

    The <interface interface-name> option clears NAT statistics for the specified interface only.

    The <service-set service-set-name> option clears NAT statistics for the specified service set only.

    The clear services inline nat statistics command should include the following option:

    <interface interface-name>

    The <interface interface-name> option clears inline NAT statistics for the specified interface only.

  • The following additional information regarding the interoperation of sample actions in firewall filters and traffic sampling applies to the Minimum Configuration for Traffic Sampling section in the Configuring Traffic Sampling topic:

    The following prerequisites apply to M Series, MX Series, and T Series routers when you configure traffic sampling on interfaces and in firewall filters:

    • If you configure a sample action in a firewall filter for an inet or inet6 family on an interface without configuring the forwarding-options settings, operational problems might occur if you also configure port mirroring or flow-tap functionalities. In such a scenario, all the packets that match the firewall filter are incorrectly sent to the service PIC.
    • If you include the then sample statement at the [edit firewall family inet filter filter-name term term-name] hierarchy level to specify a sample action in a firewall filter for IPv4 packets, you must also include the family inet statement at the [edit forwarding-options sampling] hierarchy level or the instance instance-name family inet statement at the [edit forwarding-options sampling] hierarchy level. Similarly, if you include the then sample statement at the [edit firewall family inet6 filter filter-name term term-name] hierarchy level to specify a sample action in a firewall filter for IPv6 packets, you must also include the family inet6 statement at the [edit forwarding-options sampling] hierarchy level or the instance instance-name family inet6 statement at the [edit forwarding-options sampling] hierarchy level. Otherwise, a commit error occurs when you attempt to commit the configuration.
    • If you configure traffic sampling on a logical interface by including the sampling input or sampling output statements at the [edit interface interface-name unit logical-unit-number] hierarchy level, you must also include the family inet | inet6 statement at the [edit forwarding-options sampling] hierarchy level, or the instance instance-name family inet | inet6 statement at the [edit forwarding-options sampling] hierarchy level.
  • The Configuring Port Mirroring topic erroneously states that the input statement can be included under the [edit forwarding-options port-mirroring family (inet | inet6) output] hierarchy level. Only the output statement is available at the [edit forwarding-options port-mirroring family (inet | inet6)] hierarchy level. To configure the input packet properties for port mirroring, you must include the input statement at the [edit forwarding-options port-mirroring] hierarchy level.

    To configure port mirroring on a logical interface, configure the following statements at the [edit forwarding-options port-mirroring] hierarchy level:

    [edit forwarding-options port-mirroring]
    input {maximum-packet-length bytesrate rate;run-length number;}
    family (inet|inet6) {output {interface interface-name {next-hop address;}no-filter-check;}}

    Also, the note incorrectly states that the input statement can also be configured at the [edit forwarding-options port-mirroring] hierarchy level and that it is only maintained for backward compatibility. The note also mentions that the configuration of the output statement is deprecated at the [edit forwarding-options port-mirroring] hierarchy level.

    The correct behavior regarding the port-mirroring configuration for the packets to be mirrored and for the destination at which the packets are to be received is as follows:

    Note: The input statement is deprecated at the [edit forwarding-options port-mirroring family (inet | inet6)] hierarchy level and is maintained only for backward compatibility. You must include the input statement at the [edit forwarding-options port-mirroring] hierarchy level.

    [Services Interfaces, Port Mirroring]

  • In the Output Fields section of the show services ipsec-vpn ipsec security-associations command topic, the descriptions of the Local Identity and Remote Identity fields are not clear and complete. The following are the revised descriptions of these fields:
    • Local Identity—Protocol, address or prefix, and port number of the local entity of the IPsec association. The format is id-type-name (proto-name:port-number,[0..id-data-len] = iddata-presentation). The protocol is always displayed as any because it is not user-configurable in the IPsec rule. Similarly, the port number field in the output is always displayed as 0 because it is not user-configurable in the IPsec rule. The value of the id-data-len parameter can be one of the following, depending on the address configured in the IPsec rule:
      • For an IPv4 address, the length is 4 and the value displayed is 3.
      • For a subnet mask of an IPv4 address, the length is 8 and the value displayed is 7.
      • For a range of IPv4 addresses, the length is 8 and the value displayed is 7.
      • For an IPv6 address prefix, the length is 16 and the value displayed is 15.
      • For a subnet mask of an IPv6 address prefix, the length is 32 and the value displayed is 31.
      • For a range of IPv6 address prefixes, the length is 32 and the value displayed is 31.

      The value of the id-data-presentation field denotes the IPv4 address or IPv6 prefix details. If the fully qualified domain name (FQDN) is specified instead of the address for the local peer of the IPsec association, it is displayed instead of the address details.

    • Remote Identity—Protocol, address or prefix, and port number of the remote entity of the IPsec association. The format is id-type-name (proto-name:port-number,[0..id-data-len] = iddata-presentation). The protocol is always displayed as any because it is not user-configurable in the IPsec rule. Similarly, the port number field in the output is always displayed as 0 because it is not user-configurable in the IPsec rule. The value of the id-data-len parameter can be one of the following, depending on the address configured in the IPsec rule:
      • For an IPv4 address, the length is 4 and the value displayed is 3.
      • For a subnet mask of an IPv4 address, the length is 8 and the value displayed is 7.
      • For a range of IPv4 addresses, the length is 8 and the value displayed is 7.
      • For an IPv6 address prefix, the length is 16 and the value displayed is 15.
      • For a subnet mask of an IPv6 address prefix, the length is 32 and the value displayed is 31.
      • For a range of IPv6 address prefixes, the length is 32 and the value displayed is 31.

      The value of the id-data-presentation field denotes the IPv4 address or IPv6 prefix details. If the fully qualified domain name (FQDN) is specified instead of the address for the remote peer of the IPsec association, it is displayed instead of the address details.

    [Services Interfaces, IPsec Properties, Junos VPN Site Secure]

  • The Supported Flow Monitoring and Discard Accounting Standards topic fails to mention the following additional information:

    On MX Series routers, Junos OS partially supports the following RFCs:

    • RFC 5101, Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information
    • RFC 5102, Information Model for IP Flow Information Export

    [Junos OS Supported Standards]

  • The following additional information applies to the sample configuration described in the Example: Flow-Tap Configuration topic of the Flow Monitoring chapter.

    Note: The described example applies only to M Series and T Series routers, except M160 and TX Matrix routers. For MX Series routers, because the flow-tap application resides in the Packet Forwarding Engine rather than a service PIC or Dense Port Concentrator (DPC), the Packet Forwarding Engine must send the packet to a tunnel logical (vt-) interface to encapsulate the intercepted packet. In such a scenario, you need to allocate a tunnel interface and assign it to the dynamic flow capture process for FlowTapLite to use.

    [Services Interfaces, Flow Monitoring]

  • The topic Configuring Secured Port Block Allocation contains a note listing configuration changes that require a reboot of the services PIC. The note has been updated to include change to the NAT pool name.
  • The functionality to log the cflowd records in a log file before they are exported to a cflowd server (by including the local-dump statement at the [edit forwarding-options sampling instance instance-name family (inet |inet6 |mpls) output flow-server hostname] hierarchy level) is not supported when you configure inline flow monitoring (by including the inline-jflow statement at the [edit forwarding-options sampling instance instance-name family inet output] hierarchy level).
  • The “Configuring Unicast Tunnels” topic incorrectly shows the backup-destination statement. This statement does not apply to unicast tunnels and should be removed.

Subscriber Access Management

  • In the Subscriber Access Configuration Guide, there is an error in the Example: Configuring RADIUS-Based Subscriber Authentication and Accounting topic. In the example, the profile stanza incorrectly includes the authentication statement. The correct statement is authentication-order, as shown in the following sample:
    profile isp-bos-metro-fiber-basic {authentication-order radius;}

    [Subscriber Access]

  • The L2TP for Subscriber Access Overview topic in the Junos OS Subscriber Access Configuration Guide incorrectly states that L2TP is supported only on MX240, MX480, and MX960 routers. In fact, support for MX80 routers was added in Junos OS Release 12.3. In that release and later releases, the MX80 supports all L2TP features that were supported on the MX240, MX480, and MX960 routers as of Junos OS Release 11.4.

    [Subscriber Access]

  • The MX Series 3D Universal Edge Router Interface Module Reference does not state that VLAN demux configurations are not supported on MX Series routers that have any of the following line cards installed:
    • Enhanced Queuing Ethernet Services DPCs (DPCE-X-Q)
    • Enhanced Queuing IP Services DPCs (DPCE-R-Q)

    The nonsupport includes any configuration stacked on top of a VLAN demux. For example, although PPPoE is supported, PPPoE over aggregated Ethernet interfaces is not supported when one of these cards is installed, because this configuration requires PPPoE to be stacked on a VLAN demux.

  • In the AAA Service Framework Feature Guide for Subscriber Management, the parse-direction (Domain Map) statement and the Specifying the Parsing Direction for Domain Names topic show an incorrect default setting for the parse-direction statement. The correct default is the left-to-right direction.
  • In the Junos OS Subscriber Access Feature Guide, the fail-over-within-preference statement at the [edit services l2tp] hierarchy level is incorrectly spelled. The correct spelling for this statement is failover-within-preference.
  • The Example: HTTP Service Within a Service Set topic in the Subscriber Access Configuration Guide erroneously describes how to configure captive portal content delivery rules in service sets.

    Use the following procedure to configure captive portal content delivery rules in service sets:

    1. Define one or more rules with the rule rule-name statement at the [edit services captive-portal-content-delivery] hierarchy level. In each rule you specify one or more terms to match on an application, destination address, or destination prefix list; where the match takes place; and actions to be taken when the match occurs,
    2. (Optional) Define one or more rule sets by listing the rules to be included in the set with the rule-set rule-set-name statement at the [edit services captive-portal-content-delivery] hierarchy level.
    3. Configure a captive portal content delivery profile with the profile profile-name statement at the [edit services captive-portal-content-delivery] hierarchy level.
    4. In the profile, specify a list of rules with the cpcd-rules [rule-name] statement or a list of rule sets with the cpcd-rule-sets [rule-set-name] statement. Both statements are at the [edit services captive-portal-content-delivery profile profile-name] hierarchy level.
    5. Associate the profile with a service set with the captive-portal-content-delivery-profile profile-name statement at the [edit services service-set service-set-name] hierarchy level.
  • The LAC Tunnel Selection Overview topic in the Subscriber Access Configuration Guide incorrectly describes the current behavior for failover between preference levels. The topic states that when the tunnels at every preference level have a destination in the lockout state, the LAC cycles back to the highest preference level and waits for the lockout time for a destination at that level to expire before attempting to connect and starting the process over.

    In fact, the current behavior in this situation is that from the tunnels present at the lowest level of preference (highest preference number), the LAC selects the tunnel that has the destination with the shortest remaining lockout time. The LAC ignores the lockout and attempts to connect to the destination.

  • The LAC Tunnel Selection Overview, Configuring Weighted Load Balancing for LAC Tunnel Sessions and weighted-load-balancing (L2TP LAC) topics in the Junos OS Subscriber Access Configuration Guide incorrectly describe how weighted load balancing works on an L2TP LAC. The topics state that the tunnel with the highest weight (highest session limit) within a preference level is selected until it has reached its maximum sessions limit, and then the tunnel with the next higher weight is selected, and so on.

    In fact, when weighted load balancing is configured, tunnels are selected randomly within a preference level, but the distribution of selected tunnels is related to their weight. The LAC generates a random number within a range equal to the aggregate total of all session limits for all tunnels in the preference level. Portions of the range—pools of numbers—are associated with the tunnels according to their weight; a higher weight results in a larger pool. The random number is more likely to be in a larger pool, so a tunnel with a higher weight (larger pool) is more likely to be selected than a tunnel with a lower weight (smaller pool).

    For example, consider a level that has only two tunnels, A and B. Tunnel A has a maximum sessions limit of 1000 and tunnel B has a limit of 2000 sessions, resulting in an aggregate total of 3000 sessions. The LAC generates a random number in the range from 0 through 2999. A pool of 1000 numbers, the portion of the range from 0 through 999, is associated with tunnel A. A pool of 2000 numbers, the portion of the range from 1000 through 2999, is associated with tunnel B. If the generated number is less than 1000, then tunnel A is selected, even though it has a lower weight than tunnel B. If the generated number is 1000 or larger, then tunnel B is selected. Because the pool of possible generated numbers for tunnel B (2000) is twice that for tunnel A (1000), tunnel B is, on average, selected twice as often as tunnel A.

  • The table in topic, “AAA Access Messages and Supported RADIUS Attributes and Juniper Networks VSAs for Junos OS,” incorrectly indicates that VSA 26-1 (Virtual-Router) supports CoA Request messages. VSA 26-1 does not support CoA Request messages.

User Access and Authentication

  • The "Example: DHCP Complete Configuration" and "dchp" topics should not include support for the MX Series Universal Edge 3D Routers. This feature is supported only on the M Series and the T Series.

    [User Access and Authentication]

User Interface and Configuration

  • For the set system login format command, the des option has been deprecated.
  • The output for show configuration | display inheritance | display set now displays the set commands needed to duplicate the fully inherited configuration.

VPNs

  • The following guideline regarding the support of LSI traffic statistics on M Series routers is missing from the General Limitations on IP-Based Filtering section in the Filtering Packets in Layer 3 VPNs Based on IP Headers topic:

    Label-switched interface (LSI) traffic statistics are not supported for Intelligent Queuing 2 (IQ2), Enhanced IQ (IQE), and Enhanced IQ2 (IQ2E) PICs on M Series routers.

    [VPNs, Layer 3 VPNs]

  • The following limitation regarding firewall filters configured in conjunction with the vrf-table-label statement is missing from the General Limitations on IP-Based Filtering in the Filtering Packets in Layer 3 VPNs Based on IP Headers topic:

    Firewall filters cannot be applied to interfaces included in a routing instance on which you have configured the vrf-table-label statement.

    This documentation is applicable to all M Series, T Series, and SRX Series routers.

    [VPNs, Layer 3 VPNs]

  • The descriptions of the pw-label-ttl-1 and router-alert-label options in the control-channel (Protocols OAM) configuration statement topic are incorrectly and interchangeably stated. The correct descriptions of these options are as follows:
    • pw-label-ttl-1—For BGP-based pseudowires that send OAM packets with the MPLS pseudowire label and time-to-live (TTL) set to 1.
    • router-alert-label—For BGP-based pseudowires that send OAM packets with router alert label.

    [VPNs, Layer 2 VPNs]

Changes to the Junos OS Documentation Set

The following are the changes made to the Junos OS documentation set:

  • A new topic, CGN Implementation: Best Practices, which provides experience-based recommendations for configuring carrier-grade NAT, has been added to the documentation set. The new topic is available at https://www.juniper.net/techpubs/en_US/junos12.3/topics/concept/nat-best-practices.html
  • ALG documentation for MX Series platforms has been updated. The topic has been reorganized and expanded, with particular emphasis on SIP and SIP-NAT interaction. An updated version of the documentation is available at the following PR link location: PR817816

Services Interfaces Configuration Guide

  • The description for the max-packets-per-second, maximum-packet-length, and run-length statements at the [edit forwarding-options sampling instance instance-name input] hierarchy level should include the following:

    This statement is not supported when you configure inline flow monitoring (by including the inline-jflow statement at the [edit forwarding-options sampling instance instance-name family (inet | inet6) output] hierarchy level).

Modified: 2016-06-09

Previous Page Next Page