Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Documentation Updates

 

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

Adaptive Services Interfaces Feature Guide

  • The following items describe updates for aggregated Mulitservices (AMS) interfaces information:

    • The description for the rejoin-timeout statement under the hierarchy [edit interfaces interface-name load-balancing-options member-failure-options drop-member-traffic] should be changed to the following:

      Configure the time by when failed members (members in the DISCARD state) should rejoin the aggregated Multiservices (AMS) interface automatically. All members that do not rejoin by the configured time are moved to the INACTIVE state and the traffic meant for each of the members is dropped.

      If multiple members fail around the same time, then they are held in the DISCARD state using a single timer. When the timer expires, all the failed members move to INACTIVE state at the same time.

    • The following information should be added to the “Aggregated Multiservices Interface” section in the “Understanding Aggregated Multiservices Interfaces” topic:

      Member interfaces are identified as mams in the configuration. The chassisd process in routers that support AMS configuration creates a mams entry for every multiservices interface on the router.

      When you configure services-options at the ams interface level, the options apply to all member interfaces (mams) for the ams interface.

      The options also apply to service sets configured on ms- interfaces corresponding to the ams interface’s member interfaces. All settings are per PIC. For example, session-limit applies per member and not at an aggregate level.

      Note

      You cannot configure services-options at both the ams (aggregate) and member-interface level. If services-options is configured on ms-x/y/z, it also applies to service sets on mams-x/y/z.

      When you want services-options settings to apply uniformly to all members, configure services-options at the ams interface level. If you need different settings for individual members (for example, because of a syslog configuration), configure services-options at the member-interface level.

    • The show interfaces load-balancing command topic should include the following description for Last change in the table:

      Time elapsed since the last change to the interface. Changes that affect the elapsed time displayed include internal events that may not have changed the state of any member.

    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.

  • The descriptions in the “Options” section of the IPsec protocol statement at the [edit services ipsec-vpn ipsec proposal proposal-name] and [edit services ipsec-vpn rule rule-name term term-name then manual direction direction] hierarchy levels fail to state that the ah and bundle options are not supported on MS-MPCs and MS-MICs on MX Series routers.

Chassis-Level Feature Guide

  • The "Configuring Redundancy Fabric Mode for Active Control Boards on MX Series Routers" topic incorrectly states that on MX Series routers that contain the enhanced SCB with Trio chipset and the MPC3E, redundancy mode is enabled by default. The correct default behavior is that on MX Series routers that contain the enhanced SCB, regardless of the type of DPC or MPC installed on it, the default mode is the redundancy mode.

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

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

Firewall Filters Feature Guide for Routing Devices

  • The following additional information regarding the de-encapsulation 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.

High Availability Feature Guide for Routing Devices

  • The "Nonstop Active Routing System Requirements" topic should include the inet-mvpn and inet6-mvpn protocol families for BGP in the list of supported family types. The topic previously documented that NSR supports next-generation MVPN starting with Junos OS 14.1R1, but did not include the specific names of the next-generation MVPN protocol families in the list.

  • The topic “Improving the Convergence Time for VRRP” failed to include the following information:

    • Disable duplication address detection for IPv6 interfaces—Duplicate address detection is a feature of the Neighbor Discovery Protocol for IPv6. Duplicate address detection is enabled by default and determines whether an address is already in use by another node. When duplicate address detection is enabled, convergence time is high after an IPv6 interface that has been configured for VRRP tracking comes up. To disable duplicate address detection, include the ipv6-duplicate-addr-translation transmits 0 statement at the [edit system internet-options] hierarchy level. To disable duplicate address detection only for a specific interface, include the dad-disable statement at the [edit interfaces interface-name unit logical-unit-number family inet6] hierarchy level.

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

Junos Address Aware Carrier Grade NAT and IPv6 Feature Guide

  • 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 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 a change to the NAT pool name.

  • Configuration example Configuring Inline Network Address Translation - Interface-Service Service Set should state that a Modular Port Concentrator (MPC) with a Trio chipset is required, not a Multiservices Dense Port Concentrator.

  • 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 increase the size of the configuration database, you must reboot the router after committing the configuration to make the change effective.

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

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

Monitoring, Sampling, and Collection Services Interfaces Feature Guide for Routing Devices

  • The Options section for the flow-export-rate statement under the hierarchy [edit forwarding-options sampling instance instance-name family inet output inline-jlow] did not include the default value. The default value is:

    Default: 1 for each PFE on the FPC to which the sampling instance is applied.

  • 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 failed to include the following:

    Note

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

  • The “Configuring RPM Timestamping” topic failed to mention that RPM timestamping is also supported on the MS-MPCs and MS-MICs on MX Series routers.

  • The topics “Real-Time Performance Monitoring Services Overview” and “Configuring RPM Probes” failed to state that RPM is not supported on logical systems.

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.

Overview for Routing Devices

  • The "Configuring Automatic Mirroring of the CompactFlash Card on the Hard Disk Drive" and the "mirror-flash-on-disk" topics should not include support for MX5, MX10, and MX40 3D Universal Edge Routers. On the MX Series, this feature is supported only on the MX104, MX240, MX480, MX960, MX2010, and MX2020 routers.

OSPF Feature Guide

  • OSPF domain-id interoperability (MX Series)— Starting in Junos OS Release 14.1R5, to enable interoperability with routers from other vendors, you can set the AS number for domain-id attributes to 0 for the following commands:

    Caution

    Do not downgrade the Junos OS after configuring the AS number for domain-id attributes to 0. Set the AS number to a non-zero value and commit the configuration before downgrading the Junos OS.

Routing Policy and Firewall Filters

  • Support for logical queue-depth in the Packet Forwarding Engine for IP options packets for a given protocol (M Series, MX Series, and T Series)— Starting with Junos OS Release 14.1R8, you can configure logical queue-depth in the Packet Forwarding Engine for IP options packets for a given protocol. The queue-depth indicates the number of IP options packets that can be enqueued in the Packet Forwarding Engine logical queue, beyond which it would start dropping the packets.

Services Interfaces Configuration Guide

  • 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 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 (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 following information regarding the restriction on prefix lengths you can configure in NAT pools on MS-MPCs and MS-MICs applies to the "Configuring Source and Destination Addresses Network Address Translation Overview " section of the "Network Address Translation Rules Overview" topic:

    On MX Series routers with MS-MPCs and MS-MICs, if you configure a NAT address pool with a prefix length that is equal to or greater than /16, the PIC does not contain sufficient memory to provision the configured pool. Also, memory utilization problems might occur if you attempt to configure many pools whose combined total IP addresses exceed /16. In such circumstances, a system logging message is generated stating that the NAT pool name failed to be created and that the service set is not activated. On MS-MPCs and MS-MICs, you must not configure NAT pools with prefix lengths greater than /16.

  • The “Configuring Unicast Tunnels” topic incorrectly shows the backup-destination statement. This statement does not apply to unicast tunnels and should be removed.

Standards Reference

  • The Supported Network Management Standards topic incorrectly states that Junos OS supports mplsL3VpnIfConfTable as part of compliance with RFC 4382, MPLS/BGP Layer 3 Virtual Private Network (VPN) MIB. Junos OS does not support this table.

Subscriber Management Network Access Feature Guide

  • The LAC Tunnel Selection Overview, Configuring Weighted Load Balancing for LAC Tunnel Sessions, and weighted-load-balancing (L2TP LAC) topics in the Junos OS Broadband Subscriber Management and Services Library 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.

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.

  • Support for the packet-triggered subscribers and policy control rule base (PTSP) feature was discontinued starting in Junos OS Release 13.1R1, but this was not reflected in the documentation. Text exclusive to PTSP has been removed from the Broadband Subscriber Sessions Feature Guide. This includes all CLI topics and the following chapters:

    • “Configuring the PTSP Feature to Support Dynamic Subscribers”

    • “Configuring the PTSP Partition to Connect to the External Policy Manager”

    • “Configuring PTSP Services and Rules”

    • “Monitoring and Managing Packet-Triggered Subscribers”

    Topics for other features that refer to PTSP are updated to report the end of support.

  • The following topics erroneously include information about the Ignore-DF-Bit VSA (26-70): “RADIUS Attributes and Juniper Networks VSAs Supported by the AAA Service Framework,” “Juniper Networks VSAs Supported by the AAA Service Framework”, and “AAA Access Messages and Supported RADIUS Attributes and Juniper Networks VSAs for Junos OS.” Junos OS does not support VSA 26-70.

    Some versions of the RADIUS dictionary file also erroneously list 26-70 as supported by the Junos OS.

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)

Tunnel Encryption Services Interfaces

  • The topic “Configuring Tunnel Interfaces on MX Series Routers” incorrectly states that bandwidth rates of 20 gigabits per seconds and 40 gigabits per second require use of a 100-Gigabit Ethernet Modular Port Concentrator and 100-Gigabit CFP MIC. The MPC4E, MPC5E, and MPC6E also support 20 and 40 gigabits per second.

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

  • The enhanced-hash-key configuration statement topic fails to mention that the src-prefix-len option is available for configuration at the [edit forwarding-options enhanced-hash-key family inet6 layer-3-services src-prefix-len] hierarchy level. You can use the src-prefix-len option to include the source prefix length in the hash key for enhanced IP forwarding engines.

User Access and Authorization Feature 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.

  • 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 a DPC, 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.