Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Physical Interface Properties

 

This topic discusses on how to configure various physical interface properties with examples.

Physical Interface Properties Overview

The software driver for each network media type sets reasonable default values for general interface properties, such as the interface’s maximum transmission unit (MTU) size, receive and transmit leaky bucket properties, link operational mode, and clock source.

To modify any of the default general interface properties, include the appropriate statements at the [edit interfaces interface-name] hierarchy level:

Media MTU Overview

The media maximum transmission unit (MTU) is the largest data unit that can be forwarded without fragmentation.

The default media MTU size used on a physical interface depends on the encapsulation used on that interface. In some cases, the default IP Protocol MTU depends on whether the protocol used is IP version 4 (IPv4) or International Organization for Standardization (ISO).

The default media MTU is calculated as follows:

When you are configuring point-to-point connections, the MTU sizes on both sides of the connections must be the same. Also, when you are configuring point-to-multipoint connections, all interfaces in the subnet must use the same MTU size.

Note

The actual frames transmitted also contain cyclic redundancy check (CRC) bits, which are not part of the media MTU. For example, the media MTU for a Gigabit Ethernet Version 2 interface is specified as 1514 bytes, but the largest possible frame size is actually 1518 bytes; you need to consider the extra bits in calculations of MTUs for interoperability.

The physical MTU for Ethernet interfaces does not include the 4-byte frame check sequence (FCS) field of the Ethernet frame.

A SONET/SDH interface operating in concatenated mode has a “c” added to the rate descriptor. For example, a concatenated OC48 interface is referred to as OC48c.

If you do not configure an MPLS MTU, the Junos OS derives the MPLS MTU from the physical interface MTU. From this value, the software subtracts the encapsulation-specific overhead and space for the maximum number of labels that might be pushed in the Packet Forwarding Engine. Currently, the software provides for three labels of four bytes each, for a total of 12 bytes.

In other words, the formula used to determine the MPLS MTU is the following:

Media MTU Sizes by Interface Type

The media maximum transmission unit (MTU) is the largest data unit that can be forwarded without fragmentation.

If you change the size of the media MTU, you must ensure that the size is equal to or greater than the sum of the protocol MTU and the encapsulation overhead.

This topic includes following information:

Media MTU Sizes by Interface Type for M5 and M7i Routers with CFEB, M10 and M10i Routers with CFEB, and M20 and M40 Routers

Table 1: Media MTU Sizes by Interface Type for M5 and M7i Routers with CFEB, M10 and M10i Routers with CFEB, and M20 and M40 Routers

Interface Type

Default Media MTU (Bytes)

Maximum MTU (Bytes)

Default IP Protocol MTU (Bytes)

Adaptive Services

(MTU size not configurable)

9192

N/A

N/A

ATM

4482

9192

4470

E1/T1

1504

9192

1500

E3/T3

4474

9192

4470

Fast Ethernet

1514

1533 (4-port)

1532 (8-port)

1532 (12-port)

Note: The maximum MTU for two 100Base-TX Fast Ethernet port FIC is 9192 bytes.

1500 (IPv4), 1497 (ISO)

Gigabit Ethernet

1514

9192

Note: The maximum MTU for one Gigabit Ethernet port FIC is 9192 bytes.

1500 (IPv4), 1497 (ISO)

Serial

1504

9192

1500 (IPv4), 1497 (ISO)

SONET/SDH

4474

9192

4470

Media MTU Sizes by Interface Type for M40e Routers

Table 2: Media MTU Sizes by Interface Type for M40e Routers

Interface Type

Default Media MTU (Bytes)

Maximum MTU (Bytes)

Default IP Protocol MTU (Bytes)

Adaptive Services

(MTU size not configurable)

9192

N/A

N/A

ATM

4482

9192

4470

E1/T1

1504

4500

1500

E3/T3

4474

4500

9192 (4-port)

4470

E3/DS3 IQ

4474

9192

4470

Fast Ethernet

1514

1533

1500 (IPv4), 1497 (ISO)

Gigabit Ethernet

1514

9192 (1- or 2-port)

9192 (4-port)

1500 (IPv4), 1497 (ISO)

Serial

1504

9192

1500 (IPv4), 1497 (ISO)

SONET/SDH

4474

4500 (1-port nonconcatenated)

9192 (4-port OC3)

9192 (4-port OC3c)

4500 (1-port OC12)

4500 (4-port OC12)

4500 (4-port OC12c)

4500 (1-port OC48)

9192 (2-port OC3)

9192 (2-port OC3c)

9192 (1-port OC12c)

9192 (1-port OC48c)

4500 (1-port OC192)

9192 (1-port OC192c)

4470

Media MTU Sizes by Interface Type for M160 Routers

Table 3: Media MTU Sizes by Interface Type for M160 Routers

Interface Type

Default Media MTU (Bytes)

Maximum MTU (Bytes)

Default IP Protocol MTU (Bytes)

Adaptive Services

(MTU size not configurable)

9192

N/A

N/A

ATM

4482

9192

4470

E1/T1

1504

4500

1500

E3/T3

4474

4500

4470

E3/DS3 IQ

4474

9192

4470

Fast Ethernet

1514

1533

1500 (IPv4), 1497 (ISO)

Gigabit Ethernet

1514

9192 (1- or 2-port)

4500 (4-port)

1500 (IPv4), 1497 (ISO)

Serial

1504

9192

1500 (IPv4), 1497 (ISO)

SONET/SDH

4474

4500 (1-port nonconcatenated)

9192 (1- or 2-port)

4500 (4-port)

4470

Media MTU Sizes by Interface Type for M7i Routers with CFEB-E, M10i Routers with CFEB-E, and M320 and M120 Routers

Table 4: Media MTU Sizes by Interface Type for M7i Routers with CFEB-E, M10i Routers with CFEB-E, and M320 and M120 Routers

Interface Type

Default Media MTU (Bytes)

Maximum MTU (Bytes)

Default IP Protocol MTU (Bytes)

ATM2 IQ

4482

9192

4470

Channelized DS3 IQ

4471

4500

4470

Channelized E1 IQ

1504

4500

1500

Channelized OC12 IQ

4474

9192

4470

Channelized STM1 IQ

4474

9192

4470

DS3

4471

4500

4470

E1

1504

4500

1500

E3 IQ

4471

4500

4470

Fast Ethernet

1514

1533 (4-port)

1532 (8-, 12- and 48-port)

1500 (IPv4), 1497 (ISO)

Gigabit Ethernet

1514

9192

1500 (IPv4), 1497 (ISO)

SONET/SDH

4474

9192

4470

T1

1504

4500

1500

CT3 IQ

(excluding M120)

4474

9192

4470

Media MTU Sizes by Interface Type for MX Series Routers

Table 5: Media MTU Sizes by Interface Type for MX Series Routers

Interface Type

Default Media MTU (Bytes)

Maximum MTU (Bytes)

Default IP Protocol MTU (Bytes)

Gigabit Ethernet

1514

  • 9192

  • 9500 (Junos OS 16.1R1 and later releases)

1500 (IPv4), 1488 (MPLS), 1497 (ISO)

10-Gigabit Ethernet

1514

  • 9192

  • 9500 (Junos OS 16.1R1 and later releases)

1500 (IPv4), 1488 (MPLS), 1497 (ISO)

Multi-Rate Ethernet

1514

  • 9192

  • 9500 (Junos OS 16.1R1 and later releases)

1500 (IPv4), 1488 (MPLS), 1497 (ISO)

Tri-Rate Ethernet

1514

  • 9192

  • 9500 (Junos OS 16.1R1 and later releases)

1500 (IPv4), 1488 (MPLS), 1497 (ISO)

Channelized SONET/SDH OC3/STM1 (Multi-Rate)

1514

9192

1500 (IPv4), 1488 (MPLS), 1497 (ISO)

DS3/E3 (Multi-Rate)

1514

9192

1500 (IPv4), 1488 (MPLS), 1497 (ISO)

Note: Starting in Junos OS Release 16.1R1, the MTU size for a media or protocol is increased from 9192 to 9500 for Ethernet interfaces on the following MX Series MPCs:

  • MPC1

  • MPC2

  • MPC2E

  • MPC3E

  • MPC4E

  • MPC5E

  • MPC6E

Note

Starting in Junos OS Release 16.1R1, the MTU size for a media or protocol is increased from 9192 to 9500 for Ethernet interfaces on the following MX Series MPCs:

  • MPC1

  • MPC2

  • MPC2E

  • MPC3E

  • MPC4E

  • MPC5E

  • MPC6E

Starting in Junos OS Release 16.1R1, the MTU size has been increased to 16,000 bytes for certain MPCs. The MTU size for the following MPCs has been increased to 16000 bytes:

  • MPC7E (MPC7E-MRATE and MP7E-10G)

  • MPC8E (MX2K-MPC8E)

  • MPC9E (MX2K-MPC9E)

Starting in Junos OS Release 17.3R1, the MTU size for MX10003 MPC is 16,000 bytes.

Starting in Junos OS Release 17.4R1, the MTU size for MX204 is 16,000 bytes.

In all Junos OS releases, the maximum MTU size for MX5, MX10, MX40, and MX80 routers is 9192 bytes.

In all Junos OS releases, the maximum MTU size for MPC2E-NG and MPC3E-NG is 9500 bytes.

Media MTU Sizes by Interface Type for T320 Routers

Table 6: Media MTU Sizes by Interface Type for T320 Routers

Interface Type

Default Media MTU (Bytes)

Maximum MTU (Bytes)

Default IP Protocol MTU (Bytes)

ATM

4482

9192

4470

ATM2 IQ

4482

9192

4470

Channelized OC12 IQ

4474

9192

4470

Channelized STM1 IQ

4474

9192

4470

DS3

4471

4500

4470

Fast Ethernet

1514

1533 (4-port)

1532 (12- and 48-port)

1500 (IPv4), 1497 (ISO)

Gigabit Ethernet

1514

9192

1500 (IPv4), 1497 (ISO)

SONET/SDH

4474

9192

4470

CT3 IQ

4474

9192

4470

Media MTU Sizes by Interface Type for T640 Platforms

Table 7: Media MTU Sizes by Interface Type for T640 Platforms

Interface Type

Default Media MTU (Bytes)

Maximum MTU (Bytes)

Default IP Protocol MTU (Bytes)

ATM2 IQ

4482

9192

4470

48-port Fast Ethernet

1514

1532

1500 (IPv4), 1497 (ISO)

Gigabit Ethernet

1514

9192

1500 (IPv4), 1497 (ISO)

SONET/SDH

4474

9192

4470

CT3 IQ

4474

9192

4470

Media MTU Sizes by Interface Type for EX Series Switches and ACX Series Routers

Table 8: Media MTU Sizes by Interface Type for EX Series Switches

Interface Type

Default Media MTU (Bytes)

Maximum MTU (Bytes)

Default IP Protocol MTU (Bytes)

Gigabit Ethernet

1514

9216

1500 (IPv4), 1497 (ISO)

10-Gigabit Ethernet

1514

9216

1500 (IPv4), 1497 (ISO)

Table 9: Media MTU Sizes by Interface Type for ACX Series Routers

Interface Type

Switch

Default Media MTU (Bytes)

Maximum MTU (Bytes)

Default IP Protocol MTU (Bytes)

Gigabit Ethernet and 10-Gigabit Ethernet

ACX1000, ACX2000, ACX4000, ACX5048, ACX5096 line of routers, and ACX500.

1514

9216

1500 (IPv4), 1497 (ISO)

Gigabit Ethernet and 10-Gigabit Ethernet

ACX5448 series and ACX710 Series

1514

10000

1500 (IPv4), 1497 (ISO)

Note

On ACX Series routers, you can configure the protocol MTU by including the mtu statement at the [edit interfaces interface-name unit logical-unit-number family inet] or [edit interfaces interface-name unit logical-unit-number family inet6] hierarchy level.

  • If you configure the protocol MTU at any of these hierarchy levels, the configured value is applied to all families that are configured on the logical interface.

  • If you are configuring the protocol MTU for both inet and inet6 families on the same logical interface, you must configure the same value for both the families. It is not recommended to configure different MTU size values for inet and inet6 families that are configured on the same logical interface.

Media MTU Sizes by Interface Type for PTX Series Packet Transport Routers

Table 10: Media MTU Sizes by Interface Type for PTX Series Packet Transport Routers

Interface Type

Default Media MTU (Bytes)

Maximum MTU (Bytes)

Default IP Protocol MTU (Bytes)

10-Gigabit Ethernet

1514

9500

1500 (IPv4), 1488 (MPLS), 1497 (ISO)

40-Gigabit Ethernet

1514

9500

1500 (IPv4), 1488 (MPLS), 1497 (ISO)

100-Gigabit Ethernet

1514

9500

1500 (IPv4), 1488 (MPLS), 1497 (ISO)

Media MTU Sizes by Interface Type for JRR200 Series Routers

Table 11: Media MTU Sizes by Interface Type for JRR200 Series Routers

Interface Type

Default Media MTU (Bytes)

Maximum MTU (Bytes)

Default IP Protocol MTU (Bytes)

Management Ethernet Interfaces (em0,em2 -em9)

1514

9192

1500 (IPv4), 1497 (ISO)

Configuring the Media MTU

The media maximum transmission unit (MTU) is the largest data unit that can be forwarded without fragmentation. The default media MTU size used on a physical interface depends on the encapsulation being used on that interface. For a listing of MTU sizes for each encapsulation type, see Media MTU Sizes by Interface Type.

To configure the media-MTU size:

  1. In configuration mode, go to the [edit interfaces interface-name] hierarchy level.
  2. Include the mtu statement.
  • If you change the size of the media MTU, you must ensure that the size is equal to or greater than the sum of the protocol MTU and the encapsulation overhead. You configure the protocol MTU by including the mtu statement at the following hierarchy levels:

    • [edit interfaces interface-name unit logical-unit-number family family]

    • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family family]

Note
  • Changing the media MTU or protocol MTU causes an interface to be deleted and added again.

  • Because tunnel services interfaces are considered logical interfaces, you cannot configure the MTU setting for the physical interface. This means you cannot include the mtu statement at the [edit interfaces interface-name] hierarchy level for the following interface types: generic routing encapsulation (gr-), IP-IP (ip-), loopback (lo-), link services (ls-), multilink services (ml-), and multicast (pe-, pd-). You can, however, configure the protocol MTU on all tunnel interfaces except virtual tunnel (vt) interfaces. Starting in Junos OS Release 17.1R3, you cannot configure the maximum transmission unit (MTU) size for vt interfaces because the mtu bytes option is deprecated for vt interfaces. Junos OS sets the MTU size for vt interfaces by default to unlimited.

  • If you configure an MTU value by including the mtu statement at the [edit interfaces interface-name unit logical-unit-number family mpls] hierarchy level, the configured value is used.

Configuring the Media MTU on ACX Series Routers

Media MTU Overview

The default media MTU size used on a physical interface depends on the encapsulation used on that interface. In some cases, the default IP Protocol MTU depends on whether the protocol used is IP version 4 (IPv4) or International Organization for Standardization (ISO).

The default media MTU is calculated as follows:

When you are configuring point-to-point connections, the MTU sizes on both sides of the connections must be the same. Also, when you are configuring point-to-multipoint connections, all interfaces in the subnet must use the same MTU size.

Note

The actual frames transmitted also contain cyclic redundancy check (CRC) bits, which are not part of the media MTU. For example, the media MTU for a Gigabit Ethernet Version 2 interface is specified as 1514 bytes, but the largest possible frame size is actually 1518 bytes; you need to consider the extra bits in calculations of MTUs for interoperability.

The physical MTU for Ethernet interfaces does not include the 4-byte frame check sequence (FCS) field of the Ethernet frame.

If you do not configure an MPLS MTU, the Junos OS derives the MPLS MTU from the physical interface MTU. From this value, the software subtracts the encapsulation-specific overhead and space for the maximum number of labels that might be pushed in the Packet Forwarding Engine. Currently, the software provides for three labels of four bytes each, for a total of 12 bytes.

In other words, the formula used to determine the MPLS MTU is the following:

If you configure an MTU value by including the mtu statement at the [edit interfaces interface-name unit logical-unit-number family mpls] hierarchy level, the configured value is used. Junos OS Release 16.2R1.6 and later releases do not support family mpls MTU.

How to Configure the Media MTU

To modify the default media MTU size for a physical interface, include the mtu statement at the [edit interfaces interface-name] hierarchy level:

If you change the size of the media MTU, you must ensure that the size is equal to or greater than the sum of the protocol MTU and the encapsulation overhead.

Note

Changing the media MTU or protocol MTU causes an interface to be deleted and added again.

You configure the protocol MTU by including the mtu statement at the following hierarchy levels:

  • [edit interfaces interface-name unit logical-unit-number family inet]

  • [edit interfaces interface-name unit logical-unit-number family inet6]

If you configure the protocol MTU at any of these hierarchy levels, the configured value is applied to all families that are configured on the logical interface.

Note

If you are configuring the protocol MTU for both inet and inet6 families on the same logical interface, you must configure the same value for both the families. It is not recommended to configure different MTU size values for inet and inet6 families that are configured on the same logical interface.

Encapsulation Overhead by Interface Encapsulation Type

If you change the size of the media MTU, you must ensure that the size is equal to or greater than the sum of the protocol MTU and the encapsulation overhead. The following table lists the interface encapsulation and corresponding encapsulation overhead.

Table 12: Encapsulation Overhead by Encapsulation Type

Interface Encapsulation

Encapsulation Overhead (Bytes)

802.1Q/Ethernet 802.3

21

802.1Q/Ethernet Subnetwork Access Protocol (SNAP)

26

802.1Q/Ethernet version 2

18

ATM Cell Relay

4

ATM permanent virtual connection (PVC)

12

Cisco HDLC

4

Ethernet 802.3

17

Ethernet circuit cross-connect (CCC) and virtual private LAN service (VPLS)

4

Ethernet over ATM

32

Ethernet SNAP

22

Ethernet translational cross-connect (TCC)

18

Ethernet version 2

14

Extended virtual local area network (VLAN) CCC and VPLS

4

Extended VLAN TCC

22

Frame Relay

4

PPP

4

VLAN CCC

4

VLAN VPLS

4

VLAN TCC

22

Configuring Interface Description

You can include a text description of each physical interface in the configuration file. Any descriptive text you include is displayed in the output of the show interfaces commands, and is also exposed in the ifAlias Management Information Base (MIB) object. It has no impact on the interface’s configuration.

To add a text description, include the description statement at the [edit interfaces interface-name] hierarchy level:

For example:

The description can be a single line of text. If the text contains spaces, enclose it in quotation marks.

Note

You can configure the extended DHCP relay to include the interface description in the option 82 Agent Circuit ID suboption. See Using DHCP Relay Agent Option 82 Information in the Junos OS Broadband Subscriber Management and Services Library.

For information about describing logical units, see Adding a Logical Unit Description to the Configuration.

To display the description from the router or switch CLI, use the show interfaces command:

user@host> show interfaces fe-0/0/1

To display the interface description from the interfaces MIB, use the snmpwalk command from a server. To isolate information for a specific interface, search for the interface index shown in the SNMP ifIndex field of the show interfaces command output. The ifAlias object is in ifXTable.

Configuring Interface Ranges

Note

This task uses Junos OS for EX Series switches that does not support the Enhanced Layer 2 Software (ELS) configuration style. If your switch runs software that supports ELS, see Configuring Interface Ranges for EX Series Switches with ELS. For ELS details, see Using the Enhanced Layer 2 Software CLI.

The Junos OS allows you to group a range of identical interfaces into an interface range. You first specify the group of identical interfaces in the interface range. Then you can apply a common configuration to the specified interface range, reducing the number of configuration statements required and saving time while producing a compact configuration.

Configuring Interface Ranges

To configure an interface range, include the interface-range statement at the [edit interfaces] hierarchy level.

The interface-range statement accepts only physical networking interface names in its definition. The following interface types are supported and example CLI descriptors are shown:

  • ATM—at-fpc/pic/port

  • Channelized—(coc | cstm)n-fpc/pic/port

  • DPC—xe-fpc/pic/port

  • E1/E3—(e1 | e3)-fpc/pic/port

  • Ethernet—(xe | ge | fe)-fpc/pic/port

  • ISDN—isdn-fpc/pic/port

  • Serial—se-fpc/pic/port

  • SONET/SDH—so-fpc/pic/port

  • T1/T3—(t1 | t3)-fpc/pic/port

Interfaces can be grouped either as a range of interfaces or using a number range under the interface-range statement definition.

Interfaces in an interface-range definition can be added as part of a member range or as individual members or multiple members using a number range.

To specify a member range, use the member-range statement at the [edit interfaces interface-range name] hierarchy level.

To specify interfaces in lexical order, use the member-range start-range to end-range statement.

A range for a member statement should contain the following:

  • *—All, specifies sequential interfaces from 0 through 47.

    Caution

    The wildcard * in a member statement does not take into account the interface numbers supported by a specific interface type. Irrespective of the interface type, * includes interface numbers ranging from 0 through 47 to the interface group. Therefore, use * in a member statement with caution.

  • num—Number, specifies one specific interface by its number.

  • [low-high]—Numbers between low to high, specifies a range of sequential interfaces.

  • [num1, num2, num3]—Numbers num1, num2, and num3 specify multiple specific interfaces.

Example: Specifying an Interface Range Member Range

To specify one or multiple members, use the member statement at the [edit interfaces interface-range name] hierarchy level.

To specify the list of interface range members individually or for multiple interfaces using regex, use the member list of interface names statement.

Example: Specifying an Interface Range Member

Regex or wildcards are not supported for interface-type prefixes. For example, prefixes ge, fe, and xe must be mentioned explicitly.

An interface-range definition can contain both member and member-range statements within it. There is no maximum limit on the number of member or member-range statements within an interface-range. However, at least one member or member-range statement must exist within an interface-range definition.

Example: Interface Range Common Configuration

Configuration common to an interface range can be added as a part of the interface-range definition, as follows:

An interface-range definition having just member or member-range statements and no common configurations statements is valid.

These defined interface ranges can be used in other configuration hierarchies, in places where an interface node exists.

Example: Interface-Range foo Used Under the Protocols Hierarchy

foo should be an interface-range defined at the [interfaces] hierarchy level. In the above example, the interface node can accept both individual interfaces and interface ranges.

Tip

To view an interface range in expanded configuration, use the (show | display inheritance) command. For more information, see the CLI User Guide.

By default, interface-range is not available to configure in the CLI where the interface statement is available. The following locations are supported; however, some of the hierarchies shown in this list are product specific:

  • protocols dot1x authentication interface

  • protocols dvmrp interface

  • protocols oam ethernet lmi interface

  • protocols esis interface

  • protocols igmp interface

  • protocols igmp-host client num interface

  • protocols mld-host client num interface

  • protocols router-advertisement interface

  • protocols isis interface

  • protocols ldp interface

  • protocols oam ethernet link-fault-management interface

  • protocols lldp interface

  • protocols link-management peer lmp-control-channel interface

  • protocols link-management peer control-channel

  • protocols link-management te-link name interface

  • protocols mld interface

  • protocols ospf area id interface

  • protocols pim interface

  • protocols router-discovery interface

  • protocols rip group name neighbour

  • protocols ripng group name neighbour

  • protocols rsvp interface

  • protocols snmp interface

  • protocols layer2-control bpdu-block interface

  • protocols layer2-control mac-rewrite interface

  • protocols mpls interface

  • protocols stp interface

  • protocols rstp interface

  • protocols mstp interface

  • protocols vstp interface

  • protocols mstp msti id interface

  • protocols mstp msti vlan id interface

  • protocols vstp vlan name interface

  • protocols gvrp interface

  • protocols igmp-snooping vlan name interface

  • protocols lldp interface

  • protocols lldp-med interface

  • protocols sflow interfaces

  • ethernet-switching-options analyzer name input [egress | ingress ] interface

  • ethernet-switching-options analyzer name output interface

  • ethernet-switching-options secure-access-port interface

  • ethernet-switching-options interfaces ethernet-switching-options voip interface

  • ethernet-switching-options redundant-trunk-group group g1 interface

  • ethernet-switching-options redundant-trunk-group group g1 interface

  • ethernet-switching-options bpdu-block interface

  • poe interface vlans pro-bng-mc1-bsd1 interface

Expanding Interface Range Member and Member Range Statements

All member and member-range statements in an interface range definition are expanded to generate the final list of interface names for the specified interface range.

Example: Expanding Interface Range Member and Member Range Statements

For the member-range statement, all possible interfaces between start-range and end-range are considered in expanding the members. For example, the following member-range statement:

member-range ge-0/0/0 to ge-4/0/20

expands to:

The following member statement:

ge-5/[0-5]/*

expands to:

The following member statement:

ge-5/1/[2,3,6,10]

expands to:

Configuration Inheritance for Member Interfaces

When the Junos OS expands the member and member-range statements present in an interface-range, it creates interface objects if they are not explicitly defined in the configuration. The common configuration is copied to all its member interfaces in the interface-range.

Example: Configuration Priorities

Foreground interface configuration takes priority compared to configuration inherited by the interface through the interface-range.

In the preceding example, interface ge-1/0/1 will have an MTU value of 1024.

This can be verified with output of the show interfaces | display inheritance command, as follows:

user@host: # show interfaces | display inheritance

Member Interfaces Inheriting Configuration from Configuration Groups

Interface range member interfaces inherit the config-groups configuration like any other foreground configuration. interface-range is similar to any other foreground configuration statement. The only difference is that the interface-range goes through a member interfaces expansion before Junos OS reads this configuration.

The hold-time configuration is applied to all members of interface-range range-1.

This can be verified with show interfaces | display inheritance as follows:

user@host# show interfaces | display inheritance

Interfaces Inheriting Common Configuration

If an interface is a member of several interface ranges, that interface will inherit the common configuration from all of those interface ranges.

In this example, interfaces ge-10/0/0 through ge-10/0/47 will have both hold-time and mtu.

Configuring Inheritance Range Priorities

The interface ranges are defined in the order of inheritance priority, with the first interface range configuration data taking priority over subsequent interface ranges.

Interface ge-1/1/1 exists in both interface-range int-grp-one and interface-range int-grp-two. This interface inherits mtu 256 from interface-range int-grp-one because it was defined first.

Configuration Expansion Where Interface Range Is Used

In this example, interface-range range-1 is used under the protocols hierarchy:

The interface node present under authenticator is expanded into member interfaces of the interface-range range-1 as follows:

The interface range-1 statement is expanded into two interfaces, ge-10/1/1 and ge-5/5/1, and configuration retries 1 is copied under those two interfaces.

This configuration can be verified using the show protocols dot1x | display inheritance command.

Specifying an Aggregated Interface

The M Series, MX Series, and T Series routers support aggregated interfaces. To specify an aggregated interface assign a number with the aggregated interface name. For example, configure aex at the [edit interfaces] hierarchy level, where x is an integer ranging 0 through 127 for M Series and T Series routers and 0 through 479 on MX Series routers.

For aggregated SONET/SDH interfaces, configure asx at the [edit interfaces] hierarchy level.

Note

SONET/SDH aggregation is proprietary to the Junos OS and might not work with other software.

If you are configuring VLANs for aggregated Ethernet interfaces, you must include the vlan-tagging statement at the [edit interfaces aex] hierarchy level to complete the association.

Configuring the Interface Speed

You can configure the interface speed in following ways:

Configuring the Interface Speed on Ethernet Interfaces

For M Series and T Series Fast Ethernet 12-port and 48-port PIC interfaces, the management Ethernet interface (fxp0 or em0), and the MX Series Tri-Rate Ethernet copper interfaces, you can explicitly set the interface speed. The Fast Ethernet, fxp0, and em0 interfaces can be configured for 10 Mbps or 100 Mbps (10m | 100m). The MX Series Tri-Rate Ethernet copper interfaces can be configured for 10 Mbps, 100 Mbps, or 1 Gbps (10m | 100m | 1g). For information about management Ethernet interfaces and to determine the management Ethernet interface type for your router, see Understanding Management Ethernet Interfaces and Supported Routing Engines by RouterMX Series routers, with MX-DPC and Tri-Rate Copper SFPs, support 20x1 Copper to provide backwards compatibility with 100/10BASE-T and 1000BASE-T operation through an Serial Gigabit Media Independent Interface (SGMII) interface.

  1. In configuration mode, go to the [edit interfaces interface-name] hierarchy level.
  2. To configure the speed, include the speed statement at the [edit interfaces interface-name] hierarchy level.
Note
  • By default, the M Series and T Series routers management Ethernet interface autonegotiates whether to operate at 10 megabits per second (Mbps) or 100 Mbps. All other interfaces automatically choose the correct speed based on the PIC type and whether the PIC is configured to operate in multiplexed mode (using the no-concatenate statement in the [edit chassis] configuration hierarchy.

  • Starting with Junos OS Release 14.2 the auto-10m-100m option allows the fixed tri-speed port to auto negotiate with ports limited by 100m or 10mmaximum speed. This option must be enabled only for Tri-rate MPC port, that is, 3D 40x 1GE (LAN) RJ45 MIC on MX platform. This option does not support other MICs on MX platform.,

  • When you manually configure Fast Ethernet interfaces on the M Series and T Series routers, link mode and speed must both be configured. If both these values are not configured, the router uses autonegotiation for the link and ignores the user-configured settings.

  • If the link partner does not support autonegotiation, configure either Fast Ethernet port manually to match its link partner's speed and link mode. When the link mode is configured, autonegotiation is disabled.

  • On MX Series routers with tri-rate copper SFP interfaces, if the port speed is negotiated to the configured value and the negotiated speed and interface speed do not match, the link will not be brought up.

  • When you configure the Tri-Rate Ethernet copper interface to operate at 1 Gbps, autonegotiation must be enabled.

  • Starting with Junos OS Release 11.4, half-duplex mode is not supported on Tri-Rate Ethernet copper interfaces. When you include the speed statement, you must include the link-mode full-duplex statement at the same hierarchy level.

See also

On aggregated Ethernet interfaces, you can set the required link speed for all interfaces included in the bundle. Generally, all interfaces that make up a bundle must have the same speed. If you include in the aggregated Ethernet interface an individual link that has a speed different from the speed that you specify in the link-speed parameter, an error message is logged. However, there are exceptions.

Starting with Junos OS Release 13.2, aggregated Ethernet supports mixed rates and mixed modes on T640, T1600, T4000, and TX Matrix Plus routers. For example, these mixes are supported:

  • Member links of different modes (WAN and LAN) for 10-Gigabit Ethernet links.

  • Member links of different rates: 10-Gigabit Ethernet, 40-Gigabit Ethernet, 50-Gigabit Ethernet, 100-Gigabit Ethernet, and OC192 (10-Gigabit Ethernet WAN mode)

Starting with Junos OS Release 14.1R1 and 14.2, support for mixed rates on aggregated Ethernet bundles is extended to MX240, MX480, MX960, MX2010, and MX2020 routers.

Starting with Junos OS Release 14.2, aggregated Ethernet supports mixed link speeds on PTX Series Packet Transport Routers.

Note
  • Member links of 50-Gigabit Ethernet can only be configured using the 50-Gigabit Ethernet interfaces of 100-Gigabit Ethernet PIC with CFP (PD-1CE-CFP-FPC4).

  • Starting with Junos OS Release 13.2, 100-Gigabit Ethernet member links can be configured using the two 50-Gigabit Ethernet interfaces of 100-Gigabit Ethernet PIC with CFP. This 100-Gigabit Ethernet member link can be included in an aggregated Ethernet link that includes member links of other interfaces as well. In releases before Junos OS Release 13.2, the 100-Gigabit Ethernet member link configured using the two 50-Gigabit Ethernet interfaces of 100-Gigabit Ethernet PIC with CFP cannot be included in an aggregated Ethernet link that includes member links of other interfaces.

To configure member links of mixed rates and mixed modes on T640, T1600, T4000, TX Matrix Plus, and PTX routers, you need to configure the mixed option for the [edit interfaces aex aggregated-ether-options link-speed] statement.

To set the required link speed:

  1. Specify that you want to configure the aggregated Ethernet options.
  2. Configure the link speed.

    speed can be in bits per second either as a complete decimal number or as a decimal number followed by the abbreviation k (1000), m (1,000,000), or g (1,000,000,000).

    Aggregated Ethernet interfaces on the M120 router can have one of the following speeds:

    • 100m—Links are 100 Mbps.

    • 10g—Links are 10 Gbps.

    • 1g—Links are 1 Gbps.

    • oc192—Links are OC192 or STM64c.

    Aggregated Ethernet links on EX Series switches can be configured to operate at one of the following speeds:

    • 10m—Links are 10 Mbps.

    • 100m—Links are 100 Mbps.

    • 1g—Links are 1 Gbps.

    • 10g—Links are 10 Gbps.

    • 50g—Links are 50 Gbps.

    Aggregated Ethernet links on T Series, MX Series, PTX Series routers, and QFX5100, QFX10002, QFX10008, and QFX10016 switches can be configured to operate at one of the following speeds:

    • 100g—Links are 100 Gbps.

    • 100m—Links are 100 Mbps.

    • 10g—Links are 10 Gbps.

    • 1g—Links are 1 Gbps.

    • 40g—Links are 40 Gbps.

    • 50g—Links are 50 Gbps.

    • 80g—Links are 80 Gbps.

    • 8g—Links are 8 Gbps.

    • mixed—Links are of various speeds.

    • oc192—Links are OC192.

Configuring SONET/SDH Interface Speed

To configure the speed of SONET/SDH interfaces in concatenated mode:

  1. In configuration mode, go to the [edit interfaces interface-name] hierarchy level, where the interface-name is so-fpc/pic/port.
  2. Configure interface speed in concatenated mode.

    For example, each port of 4-port OC12 PIC can be configured to be in OC3 or OC12 speed independently when this PIC is in 4xOC12 concatenated mode.

To configure the speed of SONET/SDH interfaces in nonconcatenated mode:

  1. In configuration mode, go to the [edit interfaces interface-name] hierarchy level, where the interface-name is so-fpc/pic/port.
  2. Configure interface speed in nonconcatenated mode.

    For example, each port of 4-port OC12 PIC can be configured to be in OC3 or OC12 speed independently when this PIC is in 4xOC12 concatenated mode.

To configure the PIC to operate in channelized (multiplexed) mode:

  1. In configuration mode, go to the [edit chassis fpc slot-number pic pic-number] hierarchy level.
  2. Configure the no-concatenate option.
Note

On SONET/SDH OC3/STM1 (Multi-Rate) MIC with SFP, Channelized SONET/SDH OC3/STM1 (Multi-Rate) MIC with SFP, and Channelized OC3/STM1 (Multi-Rate) Circuit Emulation MIC with SFP, you cannot set the interface speed at the [edit interfaces] hierarchy level. To enable the speed on these MICs, you need to set the port speed at the [edit chassis fpc slot-number pic pic-number port port-number] hierarchy level.

For more information about using the non-concatenate statement, see the Junos OS Administration Library.

By default, the router’s management Ethernet interface, fxp0 or em0, autonegotiates whether to operate in full-duplex or half-duplex mode. Fast Ethernet interfaces can operate in either full-duplex or half-duplex mode, and all other interfaces can operate only in full-duplex mode. For Gigabit Ethernet, the link partner must also be set to full duplex.

Note

When you configure the Tri-Rate Ethernet copper interface to operate at 1 Gbps, autonegotiation must be enabled.

Note

When you manually configure Fast Ethernet interfaces on the M Series and T Series routers, link mode and speed must both be configured. If both these values are not configured, the router uses autonegotiation for the link and ignores the user-configured settings.

Note

When the Fast Ethernet interface on Juniper Networks routers with autonegotiation enabled interoperates with a device configured to operate in half-duplex mode (autonegotiation disabled), the interface defaults to half-duplex mode after the PIC is taken offline and brought back online. This results in packet loss and cyclic redundancy check (CRC) errors.

To explicitly configure an Ethernet interface to operate in either full-duplex or half-duplex mode, include the link-mode statement at the [edit interfaces interface-name] hierarchy level:

Interface Alias Names Overview

You can configure a textual description of a logical unit on a physical interface to be the alias of an interface name. Interface aliasing is supported only at the unit level. If you configure an alias name, the alias name is displayed instead of the interface name in the output of all show, show interfaces, and other operational mode commands. In Junos OS Release 12.3R8 and later, display of the alias can be suppressed in favor of the actual interface name by using the display no-interface-alias parameter along with the show command. Configuring an alias for a logical unit of an interface has no effect on how the interface on the router or switch operates.

When you configure the alias name of an interface, the CLI saves the alias name as the value of the interface-name variable in the configuration database. To enable backward compatibility with Junos OS releases in which the support for interface aliases is not available, when the Junos OS processes query the configuration database for the interface-name variable, the actual, exact value of the interface-name variable is returned instead of the alias name for system operations and computations.

This capability to define interface alias names for physical and logical interfaces is useful in a Junos Node Unifier (JNU) environment that contains a Juniper Networks MX Series 5G Universal Routing Platform as a controller and EX Series Ethernet switches, QFX Series devices, and ACX Series Universal Metro Routers as satellite devices. The following are the benefits of configuring an alias name, which enables a meaningful, single, and easily identifiable name to be allocated to an interface:

  • You can group physical interfaces as one aggregated interface (link aggregation group or LAG bundle) and name that bundle as a satellite connection interface (for example, sat1).

  • You can select a logical interface as a member of the LAG bundle or the entire LAG, and name that interface to represent a satellite device port or a service instance (for example, ge-0/0/1).

  • You can combine the satellite name and the interface name aliases to wholly represent the satellite port name (for example, sat1:ge-0/0/1 or ge-sat1/0/0/1 or ge-1/0/0/1) in the most easily distinguishable format that denotes a combination of port and satellite parts of the name.

To specify an interface alias, you can use the alias statement at the [edit interfaces interface-name unit logical-unit-number] and [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number] hierarchy levels.

Note

In Juniper Networks M Series Multiservice Edge Routers, if the same alias name is configured on more than one logical interface, the router displays an error message and commit fails.

See also

Example: Adding an Interface Alias Name

This example shows how to add an alias to the logical unit of an interface. Using an alias to identify interfaces as they appear in the output for operational commands can allow for more meaningful naming conventions and easier identification.

Requirements

This example uses the following hardware and software components:

  • One MX Series router that acts as a controller

  • One EX4200 switch that acts as a satellite device

  • Junos OS Release 13.3R1 or later

Overview

You can create an alias for each logical unit on a physical interface. The descriptive text you define for the alias is displayed in the output of the show interfaces commands. In Junos OS Release 12.3R8 and later, display of the alias can be suppressed in favor of the actual interface name by using the display no-interface-alias parameter along with the show command. The alias configured for a logical unit of an interface has no effect on how the interface on the router or switch operates – it is only a cosmetic label.

Configuration

Consider a scenario in which alias names are configured on the interfaces of a JNU controller that are connected to a satellite, sat1, in the downlink direction in the JNU management network by using two links. The alias names enable effective, streamlined identification of these interfaces in the operational mode commands that are run on the controller and satellites.

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them in a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level:

Configuring Alias Names for the Controller Interfaces

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To add an alias name to the controller interfaces that are used to connect to the satellite devices in the downlink direction:

  1. Configure an alias name for the logical unit of an aggregated Ethernet interface that is used to connect to a satellite, sat1, in the downlink direction. Configure inet family and address for the interface.
  2. Configure an alias name for the logical unit of another aggregated Ethernet interface that is used to connect to the same satellite, sat1, in downlink direction. Configure INET family and address for the interface.
  3. Configure an alias name for the Gigabit Ethernet interface on the controller and configure its parameters.
  4. Configure Gigabit Ethernet interfaces to be member links of an ae- logical interface.
  5. Configure RIP in the network between the controller and the firewall gateway.

Results

In configuration mode, confirm your configuration by entering the show command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

After you have confirmed that the interfaces are configured, enter the commit command in configuration mode.

Note

In Juniper Networks M Series Multiservice Edge Routers, if the same alias name is configured on more than one logical interface, the router displays an error message and commit fails.

Verification

To verify that the alias name is displayed instead of the interface name, perform these steps:

Verifying the Configuration of the Alias Name for the Controller Interfaces

Purpose

Verify that the alias name is displayed instead of the interface name.

Action

Display information about all RIP neighbors.

Meaning

The output displays the details of the benchmarking test that was performed. For more information about the show rip neighbor operational command, see show rip neighbor in the CLI Explorer.

See also

Clock Source Overview

For both the router and interfaces, the clock source can be an external clock that is received on the interface or the router’s internal Stratum 3 clock.

For example, interface A can transmit on interface A’s received clock (external, loop timing) or the Stratum 3 clock (internal, line timing, or normal timing). Interface A cannot use a clock from any other source. For interfaces such as SONET/SDH that can use different clock sources, you can configure the source of the transmit clock on each interface.

The clock source resides on the System Control Board (SCB) for M40 routers, the System and Switch Board (SSB) for M20 routers, the Control Board (CB) for M120 routers, and the Miscellaneous Control Subsystem (MCS) for M40e and M160 routers. M7i and M10i routers have a clock source on the Compact Forwarding Engine Board (CFEB) and Enhanced Compact Forwarding Engine Board (CFEB-E).

For T Series and MX Series, the clock source internal Stratum 3 clock resides on the SONET Clock Generator and Switch Control Board (SCB) respectively. By default, the 19.44-MHz Stratum 3 reference clock generates the clock signal for all serial PICs (SONET/SDH) and Plesiochronous Digital Hierarchy (PDH) PICs. PDH PICs include DS3, E3, T1, and E1 PICs.

Note

M7i and M10i routers do not support external clocking of SONET interfaces.

For information about clocking on channelized interfaces, see Channelized IQ and IQE Interfaces Properties. Also see Configuring the Clock Source on SONET/SDH Interfaces and Configuring the Channelized T3 Loop Timing.

For information about configuring an external synchronization interface that can be used to synchronize the internal Stratum 3 clock to an external source on the M40e, M120, M320, routers and T Series routers, see Junos OS Administration Library, Configuring Junos OS to Support an External Clock Synchronization Interface for M Series, MX Series, and T Series Routers.

For information about configuring Synchronous Ethernet on MX 80, MX240, MX480, and MX960 Universal Routing Platforms, see Junos OS Administration Library, Synchronous Ethernet Overview and Configuring Clock Synchronization Interface on MX Series Routers.

Configuring the Clock Source

For both the router and interfaces, the clock source can be an external clock that is received on the interface or the router’s internal Stratum 3 clock.

To set the clock source as external or internal:

  1. In configuration mode, go to the [edit interfaces interface-name] hierarchy level:
  2. Configure the clocking option as external or internal.
Note

M7i and M10i routers do not support external clocking of SONET interfaces.

Note

On Channelized SONET/SDH PICs, if you set the parent (or the master) controller clock to external, then you must set the child controller clocks to the default value—that is, internal.

For example, on the Channelized STM1 PIC, if the clock on the Channelized STM1 interface (which is the master controller) is set to external, then you must not configure the CE1 interface (which is the child controller) clock to external. Instead you must configure the CE1 interface clock to internal.

For information about clocking on channelized interfaces, see Channelized IQ and IQE Interfaces Properties. Also see Configuring the Clock Source on SONET/SDH Interfaces and Configuring the Channelized T3 Loop Timing.

For information about configuring an external synchronization interface that can be used to synchronize the internal Stratum 3 clock to an external source on the M40e, M120, and M320 routers and on the T Series routers, see Junos OS Administration Library, Configuring Junos OS to Support an External Clock Synchronization Interface for M Series, MX Series, and T Series Routers.

For information about configuring Synchronous Ethernet on MX80, MX240, MX480, and MX960 Universal Routing Platforms, see Junos OS Administration Library, Synchronous Ethernet Overview and Configuring Clock Synchronization Interface on MX Series Routers.

Configuring Interface Encapsulation on Physical Interfaces

Understanding Interface Encapsulation on Physical Interfaces

Point-to-Point Protocol (PPP) encapsulation is the default encapsulation type for physical interfaces. You need not configure encapsulation for any physical interfaces that support PPP encapsulation. If you do not configure encapsulation, PPP is used by default.

For physical interfaces that do not support PPP encapsulation, you must configure an encapsulation to use for packets transmitted on the interface. You can optionally configure an encapsulation on a logical interface, which is the encapsulation used within certain packet types.

Encapsulation Capabilities of Physical Interfaces

When you configure a point-to-point encapsulation (such as PPP or Cisco HDLC) on a physical interface, the physical interface can have only one logical interface (that is, only one unit statement) associated with it. When you configure a multipoint encapsulation (such as Frame Relay), the physical interface can have multiple logical units, and the units can be either point-to-point or multipoint.

Ethernet CCC encapsulation for Ethernet interfaces with standard TPID tagging requires that the physical interface have only a single logical interface. Ethernet interfaces in VLAN mode can have multiple logical interfaces.

For Ethernet interfaces in VLAN mode, VLAN IDs are applicable as follows:

  • VLAN ID 0 is reserved for tagging the priority of frames.

  • For encapsulation type vlan-ccc, VLAN IDs 1 through 511 are reserved for normal VLANs. VLAN IDs 512 and above are reserved for VLAN CCCs.

  • For encapsulation type vlan-vpls, VLAN IDs 1 through 511 are reserved for normal VLANs, and VLAN IDs 512 through 4094 are reserved for VPLS VLANs. For 4-port Fast Ethernet interfaces, you can use VLAN IDs 512 through 1024 for VPLS VLANs.

  • For Gigabit Ethernet interfaces and Gigabit Ethernet IQ and IQE PICs with SFPs (except the 10-port Gigabit Ethernet PIC and the built-in Gigabit Ethernet port on the M7i router), you can configure flexible Ethernet services encapsulation on the physical interface. For interfaces with flexible-ethernet-services encapsulation, all VLAN IDs are valid. VLAN IDs from 1 through 511 are not reserved.

  • For encapsulation types extended-vlan-ccc and extended-vlan-vpls, all VLAN IDs are valid.

The upper limits for configurable VLAN IDs vary by interface type.

When you configure a TCC encapsulation, some modifications are needed to handle VPN connections over unlike Layer 2 and Layer 2.5 links and terminate the Layer 2 and Layer 2.5 protocol locally.

The router performs the following media-specific changes:

  • PPP TCC—Both Link Control Protocol (LCP) and Network Control Protocol (NCP) are terminated on the router. Internet Protocol Control Protocol (IPCP) IP address negotiation is not supported. The Junos OS strips all PPP encapsulation data from incoming frames before forwarding them. For output, the next hop is changed to PPP encapsulation.

  • Cisco HDLC TCC—Keepalive processing is terminated on the router. The Junos OS strips all Cisco HDLC encapsulation data from incoming frames before forwarding them. For output, the next hop is changed to Cisco HDLC encapsulation.

  • Frame Relay TCC—All Local Management Interface (LMI) processing is terminated on the router. The Junos OS strips all Frame Relay encapsulation data from incoming frames before forwarding them. For output, the next hop is changed to Frame Relay encapsulation.

  • ATM—Operation, Administration, and Maintenance (OAM) and Interim Local Management Interface (ILMI) processing is terminated at the router. Cell relay is not supported. The Junos OS strips all ATM encapsulation data from incoming frames before forwarding them. For output, the next hop is changed to ATM encapsulation.

Configuring the Encapsulation on a Physical Interface

By default, PPP is the encapsulation type for physical interfaces. To configure the encapsulation on a physical interface, include the encapsulation statement at the [edit interfaces interface-name] hierarchy level:

To configure encapsulation on a physical interface:

  1. In configuration mode, go to the [edit interfaces interface-name] hierarchy level.
  2. Configure the encapsulation type as described in encapsulation.
    Note
    • When you configure a point-to-point encapsulation (such as PPP or Cisco HDLC) on a physical interface, the physical interface can have only one logical interface (that is, only one unit statement) associated with it. When you configure a multipoint encapsulation (such as Frame Relay), the physical interface can have multiple logical units, and the units can be either point-to-point or multipoint.

    • When the encapsulation type is set to Cisco-compatible Frame Relay encapsulation, ensure that the LMI type is set to ANSI or Q933-A.

    • When vlan-vpls encapsulation is set at the physical interface level, commit check will validate that there should not be any inet family configured within it.

Displaying the Encapsulation on a Physical SONET/SDH Interface

Purpose

To display the configured encapsulation and its associated set options on a physical interface when the following are set at the [edit interfaces interface-name] hierarchy level:

  • interface-name—so-7/0/0

  • Encapsulation—ppp

  • Unit—0

  • Family—inet

  • Address—192.168.1.113/32

  • Destination—192.168.1.114

  • Family—iso and mpls

Action

Run the show command at the [edit interfaces interface-name] hierarchy level.

Meaning

The configured encapsulation and its associated set options are displayed as expected. Note that the second set of two family statements allow IS-IS and MPLS to run on the interface.

Related Documentation

Configuring Interface Encapsulation on PTX Series Packet Transport Routers

This topic describes how to configure interface encapsulation on PTX Series Packet Transport Routers. Use the flexible-ethernet-services configuration statement to configure different encapsulation for different logical interfaces under a physical interface. With flexible Ethernet services encapsulation, you can configure each logical interface encapsulation without range restrictions for VLAN IDs.

Supported encapsulations for physical interfaces include:

  • flexible-ethernet-services

  • ethernet-ccc

  • ethernet-tcc

Supported encapsulations for logical interfaces include:

  • ethernet

  • vlan-ccc

  • vlan-tcc

Note

PTX Series Packet Transport Routers do not support extended-vlan-cc and extended-vlan-tcc encapsulation on logical interfaces. Instead, you can configure a tag protocol ID (TPID) value of 0x9100 to achieve the same results.

To configure flexible Ethernet services encapsulation, include the encapsulation flexible-ethernet-services statement at the [edit interfaces et-fpc/pic/port ] hierarchy level. For example:

Configuring Keepalives

By default, physical interfaces configured with Cisco HDLC or PPP encapsulation send keepalive packets at 10-second intervals. The Frame Relay term for keepalives is LMI packets; the Junos OS supports both ANSI T1.617 Annex D LMIs and ITU Q933 Annex A LMIs. On ATM networks, OAM cells perform the same function. You configure OAM cells at the logical interface level; for more information, see Defining the ATM OAM F5 Loopback Cell Period.

To disable the sending of keepalives:

  1. In configuration mode, go to the [edit interfaces interface-name] hierarchy level.
  2. Include the no-keepalives statement at the [edit interfaces interface-name] hierarchy level.

To disable the sending of keepalives on a physical interface configured with Cisco HDLC encapsulation for a translational cross-connection:

  1. In configuration mode, go to the [edit interfacesinterface-name] hierarchy level.
  2. Include the no-keepalives statement with the encapsulation cisco-hdlc-tcc statement at the [edit interfaces interface-name] hierarchy level.

To disable the sending of keepalives on a physical interface configured with PPP encapsulation for a translational cross-connection:

  1. In configuration mode, go to the [edit interfaces interface-name] hierarchy level.
  2. Include the no-keepalives statement with the encapsulation ppp-tcc statement at the [edit interfaces interface-name] hierarchy level.

For more information about translation cross-connections, see Circuit and Translational Cross-Connects Overview.

When you configure PPP over ATM or Multilink PPP over ATM encapsulation, you can enable or disable keepalives on the logical interface. For more information, see Configuring PPP over ATM2 Encapsulation.

To explicitly enable the sending of keepalives:

  1. In configuration mode, go to the [edit interfaces interface-name] hierarchy level.
  2. Include the keepalives statement at the [edit interfaces interface-name] hierarchy level.

To change one or more of the default keepalive values:

  1. In configuration mode, go to the [edit interfaces interface-name] hierarchy level.
  2. Include the keepalives statement with the appropriate option as intervalseconds, down-countnumber, and the up-countnumber..

On interfaces configured with Cisco HDLC or PPP encapsulation, you can include the following three keepalive statements; note that Frame Relay encapsulation is not affected by these statements:

  • interval seconds—The time in seconds between successive keepalive requests. The range is from 1 second through 32767 seconds, with a default of 10 seconds.

  • down-count number—The number of keepalive packets a destination must fail to receive before the network takes a link down. The range is from 1 through 255, with a default of 3.

  • up-count number—The number of keepalive packets a destination must receive to change a link’s status from down to up. The range is from 1 through 255, with a default of 1.

Caution

If interface keepalives are configured on an interface that does not support the keepalives configuration statement (for example, 10-Gigabit Ethernet), the link layer may go down when the PIC is restarted. Avoid configuring the keepalives on interfaces that do not support the keepalives configuration statement.

For information about Frame Relay keepalive settings, see Configuring Frame Relay Keepalives.

On MX Series routers with Modular Port Concentrators/Modular Interface Cards (MPCs/MICs), the Packet Forwarding Engine on an MPC/MIC processes and responds to Link Control Protocol (LCP) Echo-Request keepalive packets that the PPP subscriber (client) initiates and sends to the router. The mechanism by which LCP Echo-Request packets are processed by the Packet Forwarding Engine instead of by the Routing Engine is referred to as PPP fast keepalive For more information about how PPP fast keepalive works on an MX Series router with MPCs/MICs, see the Junos OS Subscriber Access Configuration Guide.

Understanding Unidirectional Traffic Flow on Physical Interfaces

By default, physical interfaces are bidirectional; that is, they both transmit and receive traffic. You can configure unidirectional link mode on a 10-Gigabit Ethernet interface that creates two new physical interfaces that are unidirectional. The new transmit-only and receive-only interfaces operate independently, but both are subordinate to the original parent interface.

The unidirectional interfaces enable the configuration of a unidirectional link topology. Unidirectional links are useful for applications such as broadband video services where almost all traffic flow is in one direction, from the provider to the user. Unidirectional link mode conserves bandwidth by enabling it to be differentially dedicated to transmit and receive interfaces. In addition, unidirectional link mode conserves ports for such applications because the transmit-only and receive-only interfaces act independently. Each can be connected to different routers, for example, reducing the total number of ports required.

Note

Unidirectional link mode is currently supported on only the following hardware:

  • 4–port 10–Gigabit Ethernet DPC on the MX960 router

  • 10–Gigabit Ethernet IQ2 PIC and 10–Gigabit Ethernet IQ2E PIC on the T Series router

The transmit-only interface is always operationally up. The operational status of the receive-only interface depends only on local faults; it is independent of remote faults and of the status of the transmit-only interface.

On the parent interface, you can configure attributes common to both interfaces, such as clocking, framing, gigether-options, and sonet-options. On each of the unidirectional interfaces, you can configure encapsulation, MAC address, MTU size, and logical interfaces.

Unidirectional interfaces support IP and IPv6. Packet forwarding takes place by means of static routes and static ARP entries. which you can configure independently on both unidirectional interfaces.

Only transmit statistics are reported on the transmit-only interface (and shown as zero on the receive-only interface). Only receive statistics are reported on the receive-only interface (and shown as zero on the transmit-only interface). Both transmit and receive statistics are reported on the parent interface.

Enabling Unidirectional Traffic Flow on Physical Interfaces

By default, physical interfaces are bidirectional; that is, they both transmit and receive traffic. You can configure unidirectional link mode on a 10-Gigabit Ethernet interface that creates two new physical interfaces that are unidirectional. The new transmit-only and receive-only interfaces operate independently, but both are subordinate to the original parent interface.

To enable unidirectional link mode on a physical interface, perform the following steps:

  1. In configuration mode, go to the [edit interfaces interface-name] hierarchy level:
  2. Configure the unidirectional option to create two new, unidirectional (transmit-only and receive-only) physical interfaces subordinate to the original parent interface.
Note

Unidirectional link mode is currently supported on only the following hardware:

  • 4–port 10–Gigabit Ethernet DPC on the MX960 router

  • 10–Gigabit Ethernet IQ2 PIC and 10–Gigabit Ethernet IQ2E PIC on the T Series router

Physical Interface Damping Overview

Physical interface damping limits the advertisement of the up and down transitions (flapping) on an interface. Each time a transition occurs, the interface state is changed, which generates an advertisement to the upper-level routing protocols. Damping helps reduce the number of these advertisements.

From the viewpoint of network deployment, physical interface flaps fall into the following categories:

  • Nearly instantaneous multiple flaps of short duration (milliseconds).

  • Periodic flaps of long duration (seconds).

Figure 1 is used to describe these types of interface flaps and the damping configuration that you can use in each case.

Figure 1: Two Router Interfaces Connected Through Transport Equipment
Two Router Interfaces Connected Through
Transport Equipment
Note

We recommend that you use similar damping configurations on both ends of the physical interface. Configuring damping on one end and not having interface damping on the other end can result in undesired behavior.

The following sections describe the types of interface damping depending upon the transition time length.

Damping Overview for Shorter Physical Interface Transitions

Figure 1 shows two routers with two transport devices between them. If a redundant link between the two transport devices fails, link switching is performed. Link switching takes a number of milliseconds. As shown in Figure 2, during switching, both router interfaces might encounter multiple flaps with an up-and-down duration of several milliseconds. These multiple flaps, if advertised to the upper-level routing protocols, might result in undesired route updates. This is why you might want to damp these interface flaps.

Note

Damping is suitable only with routing protocols.

For shorter physical interface transitions, you configure interface damping with the hold-time statement on the interface. The hold timer enables interface damping by not advertising interface transitions until the hold timer duration has passed. When a hold-down timer is configured and the interface goes from up to down, the down hold-time timer is triggered. Every interface transition that occurs during the hold-time is ignored. When the timer expires and the interface state is still down, then the router begins to advertise the interface as being down. Similarly, when a hold-up timer is configured and an interface goes from down to up, the up hold-time timer is triggered. Every interface transition that occurs during the hold-time is ignored. When the timer expires and the interface state is still up, then the router begins to advertise the interface as being up.

Figure 2: Multiple Flaps of Short Duration (Milliseconds)
Multiple Flaps of Short Duration (Milliseconds)

Damping Overview for Longer Physical Interface Transitions

When the link between a router interface and the transport devices is not stable, this can lead to periodic flapping, as shown in Figure 3. Flaps occur in the order of seconds or more, with an up-and-down flap duration in the order of a second or more. In this case, using the hold timer feature might not produce optimal results as it cannot suppress the relatively longer and repeated interface flaps. Increasing the hold time duration to seconds still allows the system to send route updates on the flapping interface, so fails to suppress periodically flapping interfaces on the system.

Figure 3: Periodic Flaps of Long Duration (Seconds)
Periodic Flaps of Long Duration (Seconds)

For longer periodic interface flaps, you configure interface damping with the damping statement on the interface. This damping method uses an exponential back-off algorithm to suppress interface up-and-down event reporting to the upper-level protocols. Every time an interface goes down, a penalty is added to the interface penalty counter. If at some point the accumulated penalty exceeds the suppress level, the interface is placed in the suppress state, and further interface link up and down events are not reported to the upper-level protocols.

Note
  • Only PTX Series routers, T Series routers, MX960 routers, MX480 routers, MX240 routers, MX80 routers, and M10i routers support interface damping for longer periodic interface flaps on all the line cards.

  • Penalty added on every interface flap is 1000.

  • The system does not indicate whether an interface is down because of suppression or that is the actual state of the physical interface. Because of this, SNMP link traps and Operation, Administration, and Maintenance (OAM) protocols cannot differentiate the damped version of the link state from the real version. Therefore, the traps and protocols might not work as expected.

  • You can verify suppression by viewing the information in the Damping field of the show interface extensive command output.

At all times, the interface penalty counter follows an exponential decay process. Figure 4 and Figure 5 show the decay process as it applies to recovery when the physical level link is down or up. As soon as the accumulated penalty reaches the lower boundary of the reuse level, the interface is marked as unsuppressed, and further changes in the interface link state are again reported to the upper-level protocols. You use the max-suppress option to configure the maximum time for restricting the accumulation of the penalty beyond the value of the maximum penalty. The value of the maximum penalty is calculated by the software. The maximum penalty corresponds to the time it would take max-suppress to decay and reach the reuse level. The penalty continues to decay after crossing the reuse level.

Figure 4 and Figure 5 show the accumulated penalty, and the decay over time as a curve. Whenever the penalty is below the reuse level and the physical level link changes state, state changes are advertised to the system and cause SNMP state changes.

Figure 4 shows the penalty dropping below the reuse level when the physical link is down. The system is notified of a state change only after the physical level link transitions to up.

Figure 4: Physical-Level Link Is Down When the Penalty Falls Below the Reuse Level
Physical-Level Link Is Down When the
Penalty Falls Below the Reuse Level

Figure 5 shows the penalty dropping below the reuse level when the physical link is up. The system is notified of a state change immediately.

Figure 5: Physical-Level Link Is Up When the Penalty Falls Below the Reuse Level
Physical-Level Link Is Up When the Penalty
Falls Below the Reuse Level

Damping Shorter Physical Interface Transitions

By default, when an interface changes from being up to being down, or from down to up, this transition is advertised immediately to the hardware and Junos OS. In some situations—for example, when an interface is connected to an add/drop multiplexer (ADM) or wavelength-division multiplexer (WDM), or to protect against SONET/SDH framer holes—you might want to damp interface transitions. This means not advertising the interface’s transition until a certain period of time has passed, called the hold-time. When you have damped interface transitions and the interface goes from up to down, the down hold-time timer is triggered. Every interface transition that occurs during the hold-time is ignored. When the timer expires and the interface state is still down, then the router begins to advertise the interface as being down. Similarly, when an interface goes from down to up, the up hold-time timer is triggered. Every interface transition that occurs during the hold-time is ignored. When the timer expires and the interface state is still up, then the router begins to advertise the interface as being up. For information about physical interface damping, see Physical Interface Damping Overview.

This task applies to damping shorter physical interface transitions in milliseconds. To damp longer physical interface transitions in seconds, see Damping Longer Physical Interface Transitions.

To configure damping of shorter physical interface transitions:

  1. Select the interface to damp, where the interface name is interface-type-fpc/pic/port:
  2. Configure the hold-time for link up and link down.

The hold time can be a value from 0 through 4,294,967,295 milliseconds. The default value is 0, which means that interface transitions are not damped. Junos OS advertises the transition within 100 milliseconds of the time value you specify.

For most Ethernet interfaces, hold timers are implemented using a one-second polling algorithm. For 1-port, 2-port, and 4-port Gigabit Ethernet interfaces with small form-factor pluggable transceivers (SFPs), hold timers are interrupt-driven.

Note

The hold-time option is not available for controller interfaces.

Damping Longer Physical Interface Transitions

Physical interface damping limits the advertisement of the up and down transitions (flapping) on an interface. An unstable link between a router Interface and the transport devices can lead to periodic flapping. Longer flaps occur with a period of about five seconds or more, with an up-and-down duration of one second. For these longer periodic interface flaps, you configure interface damping with the damping statement on the interface. This damping method uses an exponential back-off algorithm to suppress interface up and down event reporting to the upper-level protocols. Every time an interface goes down, a penalty is added to the interface penalty counter. If at some point the accumulated penalty exceeds the suppress level max-suppress, the interface is placed in the suppress state, and further interface state up and down transitions are not reported to the upper-level protocols.

Note
  • Only PTX Series routers, T Series routers, MX2010 routers, MX2020 routers, MX960 routers, MX480 routers, MX240 routers, MX80 routers, and M10i routers support interface damping for longer periodic interface flaps.

  • The system does not indicate whether an interface is down because of suppression or that is the actual state of the physical interface. Because of this, SNMP link traps and Operation, Administration, and Maintenance (OAM) protocols cannot differentiate the damped version of the link state from the real version. Therefore, the traps and protocols might not work as expected.

  • You can verify suppression by viewing the information in the Damping field of the show interface extensive command output.

You can view the damping parameters with the show interfaces extensive command.

To configure damping of longer physical interface transitions:

  1. Select the interface to damp, where the interface name is interface-type-fpc/pic/port or an interface range:
  2. Enable longer interface transition damping on a physical interface:
  3. (Optional) Set the maximum time in seconds that an interface can be suppressed no matter how unstable the interface has been.Note

    Configure max-suppress to a value that is greater than the value of half-life; otherwise, the configuration is rejected.

  4. (Optional) Set the decay half-life in seconds, which is the interval after which the accumulated interface penalty counter is reduced by half if the interface remains stable.Note

    Configure max-suppress to a value that is greater than the value of half-life; otherwise, the configuration is rejected.

  5. (Optional) Set the reuse threshold (no units). When the accumulated interface penalty counter falls below this value, the interface is no longer suppressed.
  6. (Optional) Set the suppression threshold (no units). When the accumulated interface penalty counter exceeds this value, the interface is suppressed.

Example: Configuring Physical Interface Damping

This example shows how to configure damping for a physical interface on a PTX Series Packet Transport Router.

Requirements

This example uses the following hardware and software components:

  • One PTX Series Packet Transport Router

  • One or more routers that provide input packets and receive output packets

  • Junos OS Release 14.1 or later

Overview

Physical interface damping provides a smoothing of the up and down transitions (flapping) on an interface. Each time a transition occurs, the interface state is changed, which generates an advertisement to the upper-level routing protocols. Damping helps reduce the number of these advertisements.

From the viewpoint of network deployment, physical interface flaps fall into these categories:

  • Nearly instantaneous multiple flaps of short duration (milliseconds). For shorter physical interface transitions, you configure interface damping with the hold-time statement on the interface. The hold timer enables interface damping by not advertising interface transitions until the hold timer duration has passed. When a hold-down timer is configured and the interface goes from up to down, the interface is not advertised to the rest of the system as being down until it has remained down for the hold-down timer period. Similarly, when a hold-up timer is configured and an interface goes from down to up, it is not advertised as being up until it has remained up for the hold-up timer period.

  • Periodic flaps of long duration (seconds). For longer periodic interface flaps, you configure interface damping with the damping statement on the interface. This damping method uses an exponential back-off algorithm to suppress interface up and down event reporting to the upper-level protocols. Every time an interface goes down, a penalty is added to the interface penalty counter. If at some point the accumulated penalty exceeds the suppress level, the interface is placed in the suppress state, and further interface state up transitions are not reported to the upper-level protocols.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

To configure damping on the PTX Series Packet Transport Router:

  1. Set the half-life interval, maximum suppression, reuse, suppress values, and enable:
  2. Commit configuration:

Results

From configuration mode, confirm your configuration by entering the show interfaces command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

To confirm that the configuration is working properly, perform this task:

Verifying Interface Damping on xe-6/0/0

Purpose

Verify that damping is enabled on the interface and that the damping parameter values are correctly set.

Action

From operational mode, run the show interfaces extensive command.

user@router# run show interfaces xe-6/0/0 extensive

Meaning

Damping is enabled and configured successfully on the xe-6/0/0 interface.

See also

Enabling or Disabling SNMP Notifications on Physical Interfaces

By default, Simple Network Management Protocol (SNMP) notifications are sent when the state of an interface or a connection changes. You can enable or disable these notification based on you requirements.

To explicitly enable sending SNMP notifications on the physical interface, perform the following steps:

  1. In configuration mode, go to the [edit interfaces interface-name] hierarchy level:
  2. Configure the traps option to enable sending of Simple Network Management Protocol (SNMP) notifications when the state of the connection changes.

To disable sending SNMP notifications on the physical interface, perform the following steps:

  1. In configuration mode, go to the [edit interfaces interface-name] hierarchy level:
  2. Configure the no-traps option to disable sending of Simple Network Management Protocol (SNMP) notifications when the state of the connection changes.

See also

Configuring Accounting for the Physical Interface

Accounting Profiles Overview

Juniper Networks routers and switches can collect various kinds of data about traffic passing through the router and switch. You can set up one or more accounting profiles that specify some common characteristics of this data, including the following:

  • The fields used in the accounting records

  • The number of files that the router or switch retains before discarding, and the number of bytes per file

  • The polling period that the system uses to record the data

You configure the profiles and define a unique name for each profile using statements at the [edit accounting-options] hierarchy level. There are two types of accounting profiles: interface profiles and filter profiles. You configure interface profiles by including the interface-profile statement at the [edit accounting-options] hierarchy level. You configure filter profiles by including the filter-profile statement at the [edit accounting-options] hierarchy level. For more information, see the Network Management and Monitoring Guide.

You apply filter profiles by including the accounting-profile statement at the [edit firewall filter filter-name] and [edit firewall family family filter filter-name] hierarchy levels. For more information, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide.

Configuring Accounting for the Physical Interface

Before you begin

You must configure a profile to collect error and statistic information for input and output packets on a particular physical interface. An accounting profile specifies what statistics should be collected and written to a log file. For more information on how to configure an accounting-data log file, see the Configuring Accounting-Data Log Files.

An interface profile specifies the information collected and written to a log file. You can configure a profile to collect error and statistic information for input and output packets on a particular physical interface.

  1. To configure which statistics should be collected for an interface, include the fields statement at the [edit accounting-options interface-profile profile-name] hierarchy level.
  2. Each accounting profile logs its statistics to a file in the /var/log directory. To configure which file to use, include the file statement at the [edit accounting-options interface-profile profile-name] hierarchy level.
    Note

    You must specify a file statement for the interface profile that has already been configured at the [edit accounting-options] hierarchy level. For more information, see the Configuring Accounting-Data Log Files

  3. Each interface with an accounting profile enabled has statistics collected once per interval time specified for the accounting profile. Statistics collection time is scheduled evenly over the configured interval. To configure the interval, include the interval statement at the [edit accounting-options interface-profile profile-name] hierarchy level.
    Note

    The minimum interval allowed is 1 minute. Configuring a low interval in an accounting profile for a large number of interfaces might cause serious performance degradation.

  4. To configure the interfaces on which the accounting needs to be performed, apply the interface profile to a physical interface by including the accounting-profile statement at the [edit interfaces interface-name] hierarchy level.

Displaying Accounting Profile for the Physical Interface

Purpose

To display the configured accounting profile a particular physical interface at the [edit accounting-options interface-profile profile-name] hierarchy level:

  • interface-name—ge-1/0/1

  • Interface profile —if_profile

  • File name—if_stats

  • Interval—15 minutes

Action

  • Run the show command at the [edit edit interfaces ge-1/0/1] hierarchy level.

  • Run the show command at the [edit accounting-options] hierarchy level.

Meaning

The configured accounting and its associated set options are displayed as expected.

Disabling a Physical Interface

Disabling a Physical Interface

You can disable a physical interface, marking it as being down, without removing the interface configuration statements from the configuration.

Caution

Dynamic subscribers and logical interfaces use physical interfaces for connection to the network. The Junos OS allows you to set the interface to disable and commit the change while dynamic subscribers and logical interfaces are still active. This action results in the loss of all subscriber connections on the interface. Use care when disabling interfaces.

To disable a physical interface:

  1. In configuration mode, go to [edit interfaces interface-name] hierarchy level.
  2. Include the disable statement.
Note

On the router, when you use the disable statement at the edit interfaces hierarchy level, depending on the PIC type, the interface might or might not turn off the laser. Older PIC transceivers do not support turning off the laser, but newer Gigabit Ethernet PICs with SFP and XFP transceivers do support it and the laser will be turned off when the interface is disabled.

Warning

Do not stare into the laser beam or view it directly with optical instruments even if the interface has been disabled.

Example: Disabling a Physical Interface

Sample interface configuration:

Disabling the interface:

Verifying the interface configuration:

Effect of Disabling Interfaces on T series PICs

The following table describes the effect of using the set interfaces disable interface_name statement on T series PICs.

Table 13: Effect of set interfaces disable <interface_name> on T series PICs

PIC Model Number

PIC Description

Type of PIC

Behaviour

PF-12XGE-SFPP

10-Gigabit Ethernet LAN/WAN PIC with SFP+ (T4000 Router)

5

Tx laser disabled

PF-24XGE-SFPP

10-Gigabit Ethernet LAN/WAN PIC with Oversubscription and SFP+ (T4000 Router)

5

Tx laser disabled

PF-1CGE-CFP

100-Gigabit Ethernet PIC with CFP (T4000 Router)

5

Tx laser disabled

PD-4XGE-XFP

10-Gigabit Ethernet, 4-port LAN/WAN XFP

4

Tx laser disabled

PD-5-10XGE-SFPP

10-Gigabit LAN/WAN with SFP+

4

Tx laser disabled

PD-1XLE-CFP

40-Gigabit with CFP

4

Tx laser disabled

PD-1CE-CFP-FPC4

100-Gigabit with CFP

4

Tx laser disabled

PD-TUNNEL

40-Gigabit Tunnel Services

4

NA

PD-4OC192-SON-XFP

OC192/STM64, 4-port XFP

4

Tx laser not disabled

PD-1OC768-SON-SR

OC768c/STM256, 1-port

4

Tx laser not disabled

Related Documentation

Release History Table
Release
Description
Starting in Junos OS Release 17.4R1, the MTU size for MX204 is 16,000 bytes.
Starting in Junos OS Release 17.3R1, the MTU size for MX10003 MPC is 16,000 bytes.
Starting in Junos OS Release 16.1R1, the MTU size has been increased to 16,000 bytes for certain MPCs.
Starting with Junos OS Release 14.2 the auto-10m-100m option allows the fixed tri-speed port to auto negotiate with ports limited by 100m or 10mmaximum speed. This option must be enabled only for Tri-rate MPC port, that is, 3D 40x 1GE (LAN) RJ45 MIC on MX platform. This option does not support other MICs on MX platform.
Starting with Junos OS Release 14.2, aggregated Ethernet supports mixed link speeds on PTX Series Packet Transport Routers.
Starting with Junos OS Release 14.1R1 and 14.2, support for mixed rates on aggregated Ethernet bundles is extended to MX240, MX480, MX960, MX2010, and MX2020 routers.
Starting with Junos OS Release 13.2, aggregated Ethernet supports mixed rates and mixed modes on T640, T1600, T4000, and TX Matrix Plus routers.
Starting with Junos OS Release 13.2, 100-Gigabit Ethernet member links can be configured using the two 50-Gigabit Ethernet interfaces of 100-Gigabit Ethernet PIC with CFP.
Starting with Junos OS Release 11.4, half-duplex mode is not supported on Tri-Rate Ethernet copper interfaces. When you include the speed statement, you must include the link-mode full-duplex statement at the same hierarchy level.