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.
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:
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.
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.
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 | 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 | 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 | 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 |
| 1500 (IPv4), 1488 (MPLS), 1497 (ISO) |
10-Gigabit Ethernet | 1514 |
| 1500 (IPv4), 1488 (MPLS), 1497 (ISO) |
Multi-Rate Ethernet | 1514 |
| 1500 (IPv4), 1488 (MPLS), 1497 (ISO) |
Tri-Rate Ethernet | 1514 |
| 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:
|
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.
Starting in Junos OS Release 19.1R1, the maximum configurable MTU size for MPC10E-15C-MRATE is 16,000 bytes.
Starting in Junos OS Release 19.2R1, the maximum configurable MTU size for MPC10E-10C-MRATE is 16,000 bytes.
Starting in Junos OS Release 19.3R2, the maximum configurable MTU size for MX2K-MPC11E is 16,000 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) |
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:
- In configuration mode, go to the [edit interfaces interface-name] hierarchy level.[edit ]user@host# [edit interfaces interface-name]
- Include the mtu statement.[edit interfaces interface-name]mtu bytes;
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 inet]
[edit interfaces interface-name unit logical-unit-number family family inet6]
[edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family family]
Changing the media MTU or protocol MTU causes an interface to be deleted and added again.
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.
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.
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.
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.
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
Physical interface: fe-0/0/1, Enabled, Physical link is Up Interface index: 129, SNMP ifIndex: 23 Description: Backbone connection to PHL01 ...
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.
user-server> snmpwalk host-fxp0.mylab public ifXTable | grep -e '\.23' snmpwalk host-fxp0.mylab public ifXTable | grep -e '\.23' ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.23 = fe-0/0/1 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifInMulticastPkts.23 = Counter32: 0 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifInBroadcastPkts.23 = Counter32: 0 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifOutMulticastPkts.23 = Counter32: 0 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifOutBroadcastPkts.23 = Counter32: 0 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCInOctets.23 = Counter64: 0 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCInUcastPkts.23 = Counter64: 0 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCInMulticastPkts.23 = Counter64: 0 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCInBroadcastPkts.23 = Counter64: 0 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCOutOctets.23 = Counter64: 42 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCOutUcastPkts.23 = Counter64: 0 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCOutMulticastPkts.23 = Counter64: 0 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCOutBroadcastPkts.23 = Counter64: 0 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifLinkUpDownTrapEnable.23 = enabled(1) ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHighSpeed.23 = Gauge32: 100 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifPromiscuousMode.23 = false(2) ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifConnectorPresent.23 = true(1) ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifAlias.23 = Backbone connection to PHL01 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifCounterDiscontinuityTime.23 = Timeticks: (0) 0:00:00.00
Configuring Interface Ranges
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.
Expanding Interface Range Member and Member Range Statements
Member Interfaces Inheriting Configuration from Configuration Groups
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.
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
See also
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:
[ge-0/0/0, ge-0/0/1 ... ge-0/0/max_ports ge-0/1/0 ge-0/1/1 ... ge-0/1/max_ports ge-0/2/0 ge-0/2/1 ... ge-0/2/max_ports . . ge-0/MAX_PICS/0 ... ge-0/max_pics/max_ports ge-1/0/0 ge-1/0/1 ... ge-1/0/max_ports . ge-1/MAX_PICS/0 ... ge-1/max_pics/max_ports . . ge-4/0/0 ge-4/0/1 ... ge-4/0/max_ports]
The following member statement:
ge-5/[0-5]/*
expands to:
ge-5/0/0 ... ge-5/0/max_ports ge-5/1/0 ... ge-5/0/max_ports . . ge-5/5/0 ... ge-5/5/max_ports
The following member statement:
ge-5/1/[2,3,6,10]
expands to:
ge-5/1/2 ge-5/1/3 ge-5/1/6 ge-5/1/10
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
## 'ge-1/0/0' was expanded from interface-range 'range-1' ## ge-1/0/0 { ## ## '256' was expanded from interface-range 'range-1' ## mtu 256; } ge-1/0/1 { mtu 1024; } ## ## 'ge-1/0/2' was expanded from interface-range 'range-1' ## ge-1/0/2 { ## ## '256' was expanded from interface-range 'range-1' ## mtu 256; } ......... ......... ## ## 'ge-10/0/47' was expanded from interface-range 'range-1' ## ge-10/0/47 { ## ## '256' was expanded from interface-range 'range-1' ## mtu 256; }
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
ge-1/0/0 { ## ## '256' was expanded from interface-range 'range-1' ## mtu 256; ## ## 'hold-time' was inherited from group 'global' ## '10' was inherited from group 'global' ## hold-time up 10; } ge-1/0/1 { ## ## '256' was expanded from interface-range 'range-1' ## mtu 256; ## ## 'hold-time' was inherited from group 'global' ## '10' was inherited from group 'global' ## hold-time up 10; } ge-10/0/47 { ## ## '256' was expanded from interface-range 'range-1' ## mtu 256; ## ## 'hold-time' was inherited from group 'global' ## '10' was inherited from group 'global' ## hold-time up 10; }
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.
See also
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.
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.
- In configuration mode, go to the [edit interfaces
interface-name] hierarchy level.[edit ]user@host# edit interfaces interface-name
- To configure the speed, include the speed statement
at the [edit interfaces interface-name] hierarchy level.[edit interfaces interface-name]user@host# set speed (10m | 100m | 1g | auto | auto-10m-100m);
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
Configuring Aggregated Ethernet Link Speed
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.
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:
- Specify that you want to configure the aggregated Ethernet
options.user@host# edit interfaces interface-name aggregated-ether-options
- Configure the link speed.[edit interfaces interface-name aggregated-ether-options ]user@host# set link-speed 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, QFX5120, 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.
See also
Configuring SONET/SDH Interface Speed
To configure the speed of SONET/SDH interfaces in concatenated mode:
- In configuration mode, go to the [edit interfaces interface-name] hierarchy level, where the interface-name is so-fpc/pic/port.[edit]user@host# edit interfaces so-fpc/pic/port
- 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.
[edit interfaces so-fpc/pic/port]user@host# set speed (oc3 | oc12 | oc48)
To configure the speed of SONET/SDH interfaces in nonconcatenated mode:
- In configuration mode, go to the [edit interfaces interface-name] hierarchy level, where the interface-name is so-fpc/pic/port.[edit]user@host# edit interfaces so-fpc/pic/port
- 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.
[edit interfaces so-fpc/pic/port]user@host# set speed (oc3 | oc12)
To configure the PIC to operate in channelized (multiplexed) mode:
- In configuration mode, go to the [edit chassis fpc slot-number pic pic-number] hierarchy level.[edit]user@host# [edit chassis fpc slot-number pic pic-number]
- Configure the no-concatenate option.[edit interfaces so-fpc/pic/port]user@host# set no-concatenate
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.
See also
Configuring the Link Characteristics
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.
When you configure the Tri-Rate Ethernet copper interface to operate at 1 Gbps, autonegotiation must be enabled.
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.
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.
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:
- 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.[edit]user@host# set interfaces ae0 unit 0 alias "controller-sat1-downlink1"user@host# set interfaces ae0.0 family inet address 10.0.0.1/24
- 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.[edit]user@host# set interfaces ae0 unit 1 alias "controller-sat1-downlink2"user@host# set interfaces ae0.0 family inet address 10.0.0.3/24
- Configure an alias name for the Gigabit Ethernet interface
on the controller and configure its parameters.[edit]user@host# set interfaces ge-0/0/0 vlan-tagginguser@host# set interfaces ge-0/0/0 unit 0 alias "ge-to-corp-gw1"user@host# set interfaces ge-0/0/0.0 vlan-id 101user@host# set interfaces ge-0/0/0.0 family inet address 1.1.1.1/23
- Configure Gigabit Ethernet interfaces to be member links
of an ae- logical interface.[edit]user@host# set interfaces ge-0/1/0 gigether-options 802.3ad ae0user@host# set interfaces ge-0/1/1 gigether-options 802.3ad ae0
- Configure RIP in the network between the controller and
the firewall gateway.[edit]user@host# set protocols rip group corporate-firewall neighbor ge-to-corp-gw1
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.
[edit] interfaces { ae0 { unit 0 { alias "controller-sat1-downlink1"; family inet { address 10.0.0.1/24; } } unit 1 { alias "controller-sat1-downlink2"; family inet { address 10.0.0.3/24; } } } ge-0/0/0 { vlan-tagging; unit 0 { alias "ge-to-corp-gw1"; vlan-id 101; family inet { address 1.1.1.1/23; } } } ge-0/1/0 { gigether-options { 802.3ad ae0; } } ge-0/1/1 { gigether-options { 802.3ad ae0; } } } protocols rip { group corporate-firewall { neighbor ge-to-corp-gw1; } }
After you have confirmed that the interfaces are configured, enter the commit command in configuration mode.
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.
user@router> show rip neighbor Local Source Destination Send Receive In Neighbor State Address Address Mode Mode Met ge-to-corp-gw1 DN (null) 255.255.255.255 mcast both 1
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.
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.
See also
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:
- In configuration mode, go to the [edit interfaces interface-name] hierarchy level:[edit]user@host# edit interfaces interface-name
- Configure the clocking option as external or
internal.[edit interfaces interface-name]user@host# set clocking (external | internal)
M7i and M10i routers do not support external clocking of SONET interfaces.
On Channelized SONET/SDH PICs, if you set the parent (or the primary) 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 primary 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.
See also
Configuring Interface Encapsulation on Physical Interfaces
Understanding Interface Encapsulation on Physical Interfaces
Displaying the Encapsulation on a Physical SONET/SDH Interface
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:
- In configuration mode, go to the [edit interfaces interface-name] hierarchy level.[edit]user@host# set interfaces so-fpc/pic/port
- Configure the encapsulation type as described in encapsulation.[edit interfaces mo-fpc/pic/port]user@host# set encapsulation encapsulation-type
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
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:
- In configuration mode, go to the [edit interfaces interface-name] hierarchy level.[edit ]user@host# edit interfaces interface-name
- Include the no-keepalives statement at the [edit interfaces interface-name] hierarchy
level.[edit interfaces interface-name]no-keepalives;
To disable the sending of keepalives on a physical interface configured with Cisco HDLC encapsulation for a translational cross-connection:
- In configuration mode, go to the [edit interfacesinterface-name] hierarchy level.[edit ]user@host# edit interfaces interface-name
- Include the no-keepalives statement with the encapsulation cisco-hdlc-tcc statement at the [edit interfaces interface-name] hierarchy level.[edit interfaces interface-name]encapsulation cisco-hdlc-tcc;no-keepalives;
To disable the sending of keepalives on a physical interface configured with PPP encapsulation for a translational cross-connection:
- In configuration mode, go to the [edit interfaces interface-name] hierarchy level.[edit ]user@host# edit interfaces interface-name
- Include the no-keepalives statement with the encapsulation ppp-tcc statement at the [edit interfaces interface-name] hierarchy level.[edit interfaces interface-name]encapsulation ppp-tcc;no-keepalives;
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:
- In configuration mode, go to the [edit interfaces interface-name] hierarchy level.[edit ]user@host# edit interfaces interface-name
- Include the keepalives statement at the [edit interfaces interface-name] hierarchy
level.[edit interfacesinterface-name]keepalives;
To change one or more of the default keepalive values:
- In configuration mode, go to the [edit interfaces interface-name] hierarchy level.[edit ]user@host# edit interfaces interface-name
- Include the keepalives statement with the appropriate
option as intervalseconds, down-countnumber, and the up-countnumber..[edit interfaces interface-name]keepalives;keepalives <interval seconds> <down-count number> <up-count number>;
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.
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.
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.
See also
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:
- In configuration mode, go to the [edit interfaces interface-name] hierarchy level:[edit]user@host# edit interfaces interface-name
- Configure the
unidirectional
option to create two new, unidirectional (transmit-only and receive-only) physical interfaces subordinate to the original parent interface.[edit interfaces interface-name]user@host# set unidirectional
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
See also
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.

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

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.

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.
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 5 shows the penalty dropping below the reuse level when the physical link is up. The system is notified of a state change immediately.

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:
- Select the interface to damp, where the interface name
is interface-type-fpc/pic/port:[edit]user@host# edit interfaces interface-name
- Configure the hold-time for link up and link down.[edit interfaces interface-name]user@host# set hold-time up milliseconds down milliseconds
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.
The hold-time option is not available for controller interfaces.
See also
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.
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:
- Select the interface to damp, where the interface name
is interface-type-fpc/pic/port or an interface
range:[edit]user@host# edit interfaces interface-name
- Enable longer interface transition damping on a physical
interface:[edit interfaces interface-name damping]user@host# set enable
- (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.
[edit interfaces interface-name damping]user@host# set max-suppress maximum-seconds - (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.
[edit interfaces interface-name damping]user@host# set half-life seconds - (Optional) Set the reuse threshold (no units). When the
accumulated interface penalty counter falls below this value, the
interface is no longer suppressed.[edit interfaces interface-name damping]user@host# set reuse number
- (Optional) Set the suppression threshold (no units). When
the accumulated interface penalty counter exceeds this value, the
interface is suppressed.[edit interfaces interface-name damping]user@host# set suppress number
See also
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:
- Set the half-life interval, maximum suppression, reuse, suppress values, and enable:[edit interface]user@router# set xe-6/0/0 damping half-life 11 max-suppress 2222 reuse 3333 suppress 4444 enable
- Commit configuration:[edit]user@router# commit
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
Physical interface: xe-6/0/0, Enabled, Physical link is Up Interface index: 158, SNMP ifIndex: 535, Generation: 161 Link-level type: Ethernet, MTU: 1514, LAN-PHY mode, Speed: 10Gbps, BPDU Error: None, Loopback: None, Source filtering: Disabled, Flow control: Enabled Device flags : Present Running Interface flags: SNMP-Traps Internal: 0x4000 Link flags : None CoS queues : 8 supported, 8 maximum usable queues Hold-times : Up 0 ms, Down 0 ms Damping : half-life: 11 sec, max-suppress: 2222 sec, reuse: 3333, suppress: 4444, state: unsuppressed
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:
- In configuration mode, go to the [edit interfaces interface-name] hierarchy level:[edit]user@host# edit interfaces interface-name
- Configure the traps option to enable sending
of Simple Network Management Protocol (SNMP) notifications when the
state of the connection changes.[edit interfaces interface-name]user@host# set traps
To disable sending SNMP notifications on the physical interface, perform the following steps:
- In configuration mode, go to the [edit interfaces interface-name] hierarchy level:[edit]user@host# edit interfaces interface-name
- Configure the no-traps option to disable sending
of Simple Network Management Protocol (SNMP) notifications when the
state of the connection changes.[edit interfaces interface-name]user@host# set no-traps
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.
- 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. [edit accounting-options interface-profile profile-name]user@host# set fieldsfield-name
- 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.[edit accounting-options interface-profile profile-name]user@host# set file filenameNote 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
- 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.[edit accounting-options interface-profile profile-name]user@host# set interval minutes
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.
- 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.[edit interfaces]user@host# set interface-name accounting-profile profile-name
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.
[edit interfaces ge-1/0/1]accounting-profile if_profile;Run the show command at the [edit accounting-options] hierarchy level.
interface-profile if_profile {interval 15;file if_stats {fields {input-bytes;output-bytes;input-packets;output-packets;input-errors;output-errors;}}}
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.
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:
- In configuration mode, go to [edit interfaces interface-name] hierarchy level.[edit]user@host# edit interfaces ge-fpc/pic/port
- Include the disable statement.[edit interfaces at-fpc/pic/port ]user@host# set disable
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.
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 |