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

Documentation Updates

This section lists the errata and changes in Junos OS Release 13.2R8 documentation for the M Series, MX Series, and T Series.

Aggregated Ethernet Interfaces Feature Guide for Routing Devices

  • 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.
  • The [edit protocols lacp] hierarchy level topic fails to mention that the ppm centralized statement is supported at this level for MX Series routers. This statement has been supported from Junos OS Release 9.4. You can use the ppm statement to switch between distributed and centralized periodic packet management (PPM). By default, distributed PPM is active. To enable centralized PPM, include the ppm centralized statement at the [edit protocols lacp] hierarchy level. You can disable distributed PPM processing for all packets that use PPM and run all PPM processing on the Routing Engine by configuring the no-delegate-processing configuration statement at the [edit routing-options ppm] statement hierarchy level.
  • The “Configuring Secured Port Block Allocation,” “port,” and “secured-port-block-allocation” topics should include the following note:

    If you make any configuration changes to a NAT pool that has secured port block allocation configured, you must delete the existing NAT address pool, wait at least 5 seconds, and then configure a new NAT address pool. We also strongly recommend that you perform this procedure if you make any changes to the NAT pool configuration, even if you do not have secured port block allocation configured.

Chassis-Level Feature Guide

  • The “MPC3E on MX Series Routers Overview” topic incorrectly states that configuration of an MX Series Virtual Chassis is not supported on an MPC3E module. In fact, in Junos OS Release 13.2, 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.]

  • Although documentation for software features supported on the MX104 3D Universal Edge Router is included in the Junos OS Release 13.2 documentation, the MX104 router is not supported in Junos OS Release 13.2.
  • 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.
    • 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 state 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.
    • 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.

Class of Service Library for Routing Devices

  • The Applying Scheduler Maps and Shaping Rate to DLCIs and VLANs and Scaling of Per-VLAN Queuing on Non-Queuing MPCs topics in the CoS Output Queuing and Scheduling Feature Guide for Routing Devices fails to mention that you can configure can also configure logical interface scheduling on the 8x10GE ports of an 2x100GE + 8x10GE MPC4E, apart the 2x100GE ports.

Dynamic Firewall Feature Guide for Subscriber Services

  • The enhanced-policer topic 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 in-spec statistics; 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.

Ethernet Interfaces Feature Guide

  • In the Output Fields section of the show interfaces (10-Gigabit Ethernet), show interfaces (Gigabit Ethernet), and show interfaces (Fast Ethernet) command topics of the Ethernet Interfaces Feature Guide, the descriptions of the Bit errors and Errored blocks fields that are displayed under the PCS Statistics section of the output are ambiguous. The following are the revised descriptions of these fields:
    • Bit errors—The number of seconds during which at least one bit error rate (BER) occurred while the PCS receiver is operating in normal mode.
    • Errored blocks—The number of seconds when at least one errored block occurred while the PCS receiver is operating in normal mode.

Ethernet Networking Feature Guide for MX Series Routers

  • 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.

Firewall Filters Feature Guide for Routing Devices

  • The following additional information regarding the decapsulation of GRE packets as a terminating action for firewall filters applies to the "Firewall Filter Terminating Actions" topic:

    Note: The decapsulate action that you configure at the [edit firewall family inet filter filter-name term term-name] hierarchy level does not process traffic with IPv4 and IPv6 options. As a result, traffic with such options is discarded by the decapsulation of GRE packets functionality.

Interchassis Redundancy Using Virtual Chassis Feature Guide for MX Series Routers

  • In the Junos OS 13.2 Release Notes for M Series Multiservice Edge Routers, MX Series 3D Universal Edge Routers, and T Series Core Routers, the Support for MX Series Virtual Chassis (MX Series routers with MPC3E interfaces) feature description failed to mention that you can configure a two-member MX Series Virtual Chassis on both MPC3E modules and MPC4E modules. The correct description for this feature is as follows:
    • Support for MX Series Virtual Chassis on MX Series routers with MPC3E and MPC4E interfaces—Extends support for configuring a two-member MX Series Virtual Chassis to MX240, MX480, and MX960 routers with any of the following modules installed:
      • MPC3E (model number MX-MPC3E-3D)
      • 32x10GE MPC4E (Model number: MPC4E-3D-32XGE-SFPP)
      • 2x100GE + 8x10GE MPC4E (Model number: MPC4E-3D-2CGE-8XGE)

      All MX Series Virtual Chassis features are supported on these modules.

      In earlier Junos OS releases, MX Series routers did not support MX Series Virtual Chassis configuration on MPC3E and MPC4E modules.

      [See Junos OS High Availability Library for Routing Devices and Junos OS for MX Series 3D Universal Edge Routers.]

    • 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.

Interfaces Feature Guide for Subscriber Management

  • 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 Address-Aware Carrier-Grade NAT and IPv6 Feature Guide

  • The documentation for the port control protocol (PCP) server configuration statement will be updated as follows:
    • The first line of the syntax should read server server-name {
    • A Hierarchy section should be added, with the hierarchy shown as
      [edit services pcp]
    • A Release Information section should be added stating “Statement introduced in Junos OS Release 13.2R1”.
  • The following note applies to the topic “Configuring Address Pools for Network Address Port Translation (NAPT) Overview”:

    Note: When 99 percent of the total available ports in a pool for napt-44 are used, no new flows are allowed on that NAT pool.

  • The principal document for network address translation and IPv6 transition, Next-Generation Network Addressing / Carrier-Grade NAT and IPv6 Migration Solutions, has been renamed and substantially revised for Junos OS Release 13.2. The document, which is available as a Pathway Page and corresponding PDF, is now called Junos Address Aware Carrier-Grade NAT and IPv6 Feature Guide. The renaming and internal content reflect a significant effort to improve the usability of the documentation.
    • Junos Address Aware—This name encompasses network address translation (NAT) and IPv6 migration features that are offered on routers using the services capabilities of the following interface cards: MS-100, MS-400, and MS-500 Multiservices PICs, Multiservices Dense Port Concentrators (MS-DPCs), Multiservices Modular Port Concentrators (MS-MPCs ), and Multiservices Modular Interface Cards (MS-MICs). The term also encompasses inline NAT, the set of NAT features available using the Modular Port Concentrator (MPC) type 1, 2, and 3 Trio-based line cards, leveraging the ability to provide services on the data plane.
    • We have provided tables that show feature availability and differences by type of interface card. As new features are added to any platform, these tables will be updated to assist you in choosing the right platform for your requirements. The updated documentation also includes a best practices topic for implementation of carrier-grade NAT on the MS-DPC.

    [See Junos Address Aware Carrier-Grade NAT and IPv6 Feature Guide, CGNAT Implementations Feature Comparison for Junos Address Aware by Type of Interface Card, and CGN Implementation: Best Practices.]

  • The address-allocation statement topic fails to state the following additional information regarding addresses allocation on MS-MICs and MS-MPCs:

    Regardless of whether the round-robin method of allocation is addresses is enabled by using the address-allocation round-robin statement, round-robin allocation is enabled by default on MS-MICs and MS-MPCs.

  • 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 following information regarding the guidelines for configuration of IP addresses for NAT processing applies to the "Configuring Source and Destination Addresses Network Address Translation Overview " section of the "Network Address Translation Rules Overview" topic:

    The addresses that are specified as valid in the inet.0 routing table and not supported for NAT translation are orlonger match filter types. You cannot specify any regions within such address prefixes in a NAT pool.

  • The following information regarding the working of APP with NAT rules applies to the "Network Address Translation Rules Overview" topic:

    For MX Series routers with MS-MICs and MS-MPCs, although the address pooling paired (APP) functionality is enabled within a NAT rule (by including the address-pooling statement at the [edit services nat rule rule-name term term-name then translated] hierarchy level), it is a characteristic of a NAT pool. Such a NAT pool for which APP is enabled cannot be shared with NAT rules that do not have APP configured.

Junos OS Administration Library for Routing Devices

  • The extend-size statement topic fails to note that when you include this statement to in crease the size of the configuration database, you must reboot the router after committing the configuration to make the change effective.

Junos OS for Routing Devices Documentation

Layer 2 Configuration Guide, Bridging, Address Learning, and Forwarding

  • 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).
  • The following additional information applies to the "Configuring VLAN Identifiers for Bridge Domains and VPLS Routing Instances" topic:

    The maximum number of Layer 2 interfaces that you can associate with a bridge domain or a VPLS instance on MX Series routers is 4000.

Layer 2 VPNs Feature Guide for Routing Devices

  • 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.

MPLS Applications Feature Guide for Routing Devices

  • 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.
  • 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 Administration Guide for Routing Devices

  • 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;}}

    [See filter-interfaces.]

Protocol Family and Interface Address Properties Feature Guide

  • 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 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 Configuration Guide

  • In the “Introducing Multiservices MIC and Multiservices MPC (MS-MIC and MS-MPC)” topic, MPC-Type3 should be added to the list of line cards on which you can install an MS-MIC.
  • For a NAT pool that uses deterministic port block allocation, the show services nat pool detail command should also show the DetNAT subscriber exceeded port limits counter, which displays the number of times a subscriber exceeded its port limits.
  • The following information should be added to the “Configuring AS or Multiservice PIC Redundancy” topic:

    For the rsp interface, number can be from 0 through 15.

  • The following information should be added to the syntax of the “service-set (Services)” configuration statement topic. 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;}
  • The redundancy-options statement under the hierarchy [edit interfaces rmsnumber] and [edit interfaces rspnumber] should state that it supports the hot-standby option. The hot-standby option specifies that the failure detection and recovery must take place in less than 5 seconds.
  • The port number statement under the hierarchy [edit services rpm twamp server] should remove the text that states you must configure the port statement to enable TWAMP. The Configuring TWAMP Servers topic should also remove the text that states you must configure the port statement.
  • 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 Understanding Aggregated Mulitservices Interfaces and the Example: Configuring an Aggregated Multiservices Interface (AMS) topics in the Services Interface Configuration Guide incorrectly state that when member-failure-options are not configured, the default behavior is to redistribute the traffic among the available interfaces. The topics should state that when member-failure-options are not configured, the default behavior is to drop member traffic with a rejoin timeout of 120 seconds.
  • In the Lines of Sample DTCP Parameter File table in the Flow-Tap Operation topic, the description for the Seq:10 command contained in the DTCP file incorrectly states that the router looks for a newer sequence number before accepting and implementing new parameters, and that any configuration attempt with an older sequence number is rejected by the dynamic flow capture process.

    The following guideline correctly describes the processing of the Seq:10 command in the DTCP file:

    The router does not validate the sequence number attribute during any configuration changes that are performed for a DTCP parameter file sent to the router from the mediation device. Regardless of whether the sequence number conflicts with a previous sequence number or is unique, it is disregarded and not considered.

    The following additional fields are missing from the Lines of Sample DTCP Parameter File table

    Command

    Description

    DELETE DTCP/0.6

    This indicates the DTCP version to be used. DTCP/0.6 should be used for all versions of Junos OS up to and including Junos OS 8.5. DTCP/0.7 should be used for Junos OS 9.0 and later. However, Junos OS 9.5R2 and later also accept previous versions of DTCP.

    If any unsupported parameters are received for a particular DTCP version, the request is rejected.

    Note: The notification responses from Junos OS contains the same DTCP version that the control source has communicated to Junos OS. For notifications being sent even before the control source has contacted Junos OS, the DTCP version 0.7 will be used.

    CRITERIA-ID: criteria-id

    This line denotes the ID that DTCP assigns for the mirrored session when you create a DTCP ADD message. Use this ID in your DELETE messages to disable the intercept for a specific subscriber. To view the ID, use the DTCP LIST message. The CRITERIA-ID and the Cdest-ID are mutually exclusive in DELETE messages.

    [Services Interfaces, Flow-Tap]

  • The following procedure applies to the Provisioning Flow-Tap to a Linux Mediation Device topic

    The following example shows the syntax to invoke the Perl script from a Linux device for deleting a previously configured Flow-Tap session::

    1. Invoke the Perl script:
      [root@host-e flowtap]# ./dfcclient.pl
    2. Use the following line to push the parameter file del_lea1_tcp.flowtap to the router. In this example, 10.209.75.199 is the IP address of the router, and verint verint123 is the username and password that has permission to implement flow-tap-operation. Any firewall that is between the mediation device and the routing device should allow ssh and port 32001.
      [root@host-e flowtap]# ./dfcclient.pl 10.209.75.199 verint verint123 del_lea1_tcp.flowtap

      The following settings are contained in the del_lea1_tcp.flowtap DTCP parameter file. DTCP DELETE can use either Criteria- ID to delete only that criteria or Cdest-ID to delete everything with cdest-ID that you previously created. 

      DELETE DTCP/0.7
Csource-ID: dtcp
Cdest-ID: LEA1
Flags: STATIC
    3. Use the show policer | match flow statement to verify that the flow-tap filter is removed from the router:

    The following sample shows how to disable mirroring for a specific subscriber by using the CRITERIA-ID.

    DELETE DTCP

    DELETE DTCP/0.7
Csource-ID: dtcp1
CRITERIA-ID: 2
Flags: STATIC
Seq: 10
Authentication-Info: 7e84ae871b12f2da023b038774115bb8d955f17e


DTCP/0.7 200 OK
SEQ: 10
CRITERIA-COUNT: 1
TIMESTAMP: 2011-02-13 16:00:02.802
AUTHENTICATION-INFO: 2834ff32ec07d84753a046cfb552e072cc27d50b
  • 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, MX, 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 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.
    • Also, 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.

    For SRX Series and J Series devices, if you configure a sample action in a firewall filter for sampling packets that match the filter criterion, then you must include the packet-capture statement at the [edit forwarding-options] hierarchy level, 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 bytes;rate 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.

  • 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.

  • The following information is missing from the passive-mode-tunneling configuration statement topic and the Example: Configuring Junos VPN Site Secure on MS MIC and MS-MPC topic:

    Passive module tunneling is not supported on MS-MICs and MS-MPCs.

  • 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.
  • The following additional information applies to the working of basic NAT on AMS interfaces of MS-MPCs and MS-MICs for the "Aggregated Multiservices Interface" section of the "Understanding Aggregated Multiservices Interfaces" topic

    Note: With basic NAT44, load balancing on AMS interfaces of MS-MICs and MS-MPCs does not work properly if the ingress hash key is source IP address and the egress hash key is destination IP address.

    If the service set is applied on the Gigabit Ethernet or 10-Gigabit Ethernet interface that functions as the NAT inside interface, then the hash keys used for load balancing might be configured in such a way that the ingress key is set as destination IP address and the egress key is set as source IP address. Because the source IP address undergoes NAT processing, it is not available for hashing the traffic in the reverse direction. Therefore, load-balancing does not happen on the same IP address and forward and reverse traffic do not map to the same PIC. With the hash keys reversed, load balancing occurs correctly.

    With next-hop services, for forward traffic, the ingress-key on the inside-interface load-balances traffic, and for reverse traffic, the ingress-key on the outside-interface load-balances traffic or per-member-next-hops steer reverse traffic. With interface-style services, the ingress-key load-balances forward traffic and the egress-key load-balances forward traffic or per-member-next-hops steer reverse traffic. Forward traffic is traffic entering from the inner side of a service-set and reverse traffic is traffic entering from the outer side of a service-set. The forward key is the hash key used for the forward direction of traffic and the reverse key is the hash key used for the reverse direction of traffic (depends on whether it relates to interface-services or next-hop-services style.)

    With stateful firewalls, you can configure the following combinations of forward and reverse keys for load balancing. In the following combinations presented for hash keys, FOR-KEY refers to the forward key, REV-KEY denotes the reverse key, SIP signifies source IP address, DIP signifies destination IP address, and PROTO refers to protocol such as IP.

    • FOR-KEY: SIP, REV-KEY: DIP
    • FOR-KEY: SIP,PROTO REV-KEY: DIP, PROTO
    • FOR-KEY: DIP, REV-KEY: SIP
    • FOR-KEY: DIP,PROTO REV-KEY: SIP, PROTO
    • FOR-KEY: SIP,DIP REV-KEY: SIP, DIP
    • FOR-KEY: SIP,DIP,PROTO REV-KEY: SIP, DIP,PROTO

    With static NAT configured as basic NAT44 or destination NAT44, and with stateful firewall configured or not, if the forward direction of traffic must undergo NAT processing, configure the hash keys as follows:

    • FOR-KEY: DIP, REV-KEY: SIP
    • FOR-KEY: DIP,PROTO REV-KEY: SIP, PROTO

    If the reverse direction of traffic must undergo NAT processing, configure the hash keys as follows:

    • FOR-KEY: SIP, REV-KEY: DIP
    • FOR-KEY: SIP,PROTO REV-KEY: DIP, PROTO

    With dynamic NAT configured, and with stateful firewall configured or not, only the forward direction traffic can undergo NAT. The forward hash key can be any combination of SIP, DIP, and protocol, and the reverse hash key is ignored.

  • 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 following information regarding the interoperation of FTP ALG and address-pooling paired features is missing from the "ALG Descriptions" topic of the "Application Properties" chapter:

    On MS-MPCs and MS-MICs, for passive FTP to work properly without FTP application layer gateway (ALG) enabled (by not specifying the application junos-ftp statement at the [edit services stateful-firewall rule rule-name term term-name from] and the [edit services nat rule rule-name term term-name from] hierarchy levels), you must enable the address pooling paired (APP) functionality enabled (by including the address-pooling statement at the [edit services nat rule rule-name term term-name then translated] hierarchy level). Such a configuration causes the data and control FTP sessions to receive the same NAT address.

  • 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).

Standards Reference

  • 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
  • In the Output Fields section of the show services ipsec-vpn ipsec security-associations command topic of the Junos VPN Site Secure Feature Guide, 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.

Subscriber Management Provisioning Guide

  • 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.

Subscriber Access Configuration Guide

  • The Firewall Filters and Enhanced Network Services Mode Overview topic and the enhanced-mode topic fail to mention that you must not use enhanced mode for firewall filters that are intended for control plane traffic. Control plane filtering is handled by the Routing Engine kernel, which cannot use the term-based format of the enhanced mode filters.
  • The Configuring an L2TP Tunnel Group for LNS Sessions with Inline Services Interfaces topic in the Junos OS Subscriber Access Configuration Guide fails to mention the gateway-name statement at the [edit services l2tp tunnel-group group-name local-gateway] hierarchy level. You must use this statement when you configure an LNS to specify the gateway name for the LNS. When the LAC sends an SCCRQ message to initiate tunnel creation, the LNS includes this name in the SCCRP message that it returns to the LAC. The LAC then compares this name to the remote gateway name, which is the name of the LNS as configured on the LAC. The names must match. If they do not, tunnel creation fails.
  • The Example: HTTP Service Within a Service Set topic in the Junos OS 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.
  • 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 LAC Tunnel Selection Overview topic in the Junos OS 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 Subscriber Management Scaling Values (XLS) spreadsheet previously reported that 64,000 PPPoE subscribers are supported per interface for Junos OS Release 12.3 and subsequent releases. In fact, the chassis supports 128,000 PPPoE subscribers beginning in Junos OS Release 12.3 (as well as in Junos OS 11.4X27).

    You can access the latest version of the Subscriber Management Scaling Values (XLS) spreadsheet from the Downloads box at Junos OS Subscriber Management and Services Library.

  • 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.

System Log Messages Reference

  • The formats of the MSVCS_LOG_SESSION_OPEN and MSVCS_LOG_SESSION_CLOSE system log messages in the "MSVCS System Log Messages" chapter are incorrectly specified. The following is the correct and complete format of the MSVCS_LOG_SESSION_OPEN and MSVCS_LOG_SESSION_CLOSE system log messages:

    App: application, source-interface-name fpc/pic/port\address in hexadecimal format source-address:source-port source-nat-information -> destination-address:destination-port destination-nat-information (protocol-name) hh:mm:ss.milliseconds protocol-name (tos tos-bit-value, ttl ttl-value, id id-number, offset offset-value, flags [ip-flag-type], proto protocol- name (protocol-id), length number)

System Services Administration Guide for Routing Devices

  • The “Configuring the SSH Protocol Version” topic incorrectly states that both version 1 and version 2 of the SSH protocol are enabled by default. The topic should state that version 2 of the SSH protocol is enabled by default, and you must explicitly configure version 1 if you want to enable it.

Traffic Sampling, Forwarding, and Monitoring Feature Guide for Routing Devices

User Access and Authentication Guide for Routing Devices

  • 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.

VPLS Feature Guide for Routing Devices

  • The following information regarding the working of firewall filters and policers with MAC addresses applies to the "Configuring Firewall Filters and Policers for VPLS " topic:

    The behavior of firewall filters processing with MAC addresses differs between DPCs and MPCs. On MPCs, interface filters are always applied before MAC learning occurs. The input forwarding table filter is applied after MAC learning is completed. However, on DPCs, MAC learning occurs independently of the application of filters. If the CE-facing interface of the PE where the firewall filter is applied is an MPC, then the MAC entry times out and is never learned again. However, if the CE-facing interface of the PE where the firewall filter is applied is an DP, then the MAC entry is not timed out and if the MAC address entry is manually cleared, it is relearned.

VPNs Library for Routing Devices

  • The “Routing Instances Overview” topic should include the following instance types: Ethernet VPN (EVPN) and Internet Multicast over MPLS. Use the Ehternet VPN instance type, which is supported on the MX Series only, to connect a group of dispersed customer sites using a Layer 2 virtual bridge. Use the Internet Multicast over MPLS instance type to provide support for ingress replication provider tunnels to carry IP multicast data between routers through an MPLS cloud, using MBGP or next-generation MVPN.

    To configure an EVPN instance type, include the evpn statement at the [edit routing-instances routing-instance-name instance-type] hierarchy level. To configure an Internet Multicast over MPLS instance type, include the mpls-internet-multicast statement at the [edit routing-instances routing-instance-name instance-type] hierarchy level.

Modified: 2016-06-10

Previous Page Next Page