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:
Default media MTU = Default IP MTU + encapsulation overhead
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:
MPLS MTU = physical interface MTU – encapsulation overhead – 12
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:
- #id-media-mtu-sizes-by-interface-type__d18657e166
- Media MTU Sizes by Interface Type for JRR200 Series Routers
- Media MTU Sizes by Interface Type for M5 and M7i Routers with CFEB, M10 and M10i Routers with CFEB, and M20 and M40 Routers
- Media MTU Sizes by Interface Type for M40e Routers
- Media MTU Sizes by Interface Type for M160 Routers
- Media MTU Sizes by Interface Type for M7i Routers with CFEB-E, M10i Routers with CFEB-E, and M320 and M120 Routers
- Media MTU Sizes by Interface Type for MX Series Routers
- Media MTU Sizes by Interface Type for T320 Routers
- Media MTU Sizes by Interface Type for T640 Platforms
- Media MTU Sizes by Interface Type for EX Series Switches and ACX Series Routers
- Media MTU Sizes by Interface Type for PTX Series Packet Transport Routers
Media MTU Sizes by Interface Type for M5 and M7i Routers with CFEB, M10 and M10i Routers with CFEB, and M20 and M40 Routers
Interface Type |
Default Media MTU (Bytes) |
Maximum MTU (Bytes) |
Default IP Protocol MTU (Bytes) |
---|---|---|---|
Adaptive Services (MTU size not configurable) |
9192 |
N/A |
N/A |
ATM |
4482 |
9192 |
4470 |
E1/T1 |
1504 |
9192 |
1500 |
E3/T3 |
4474 |
9192 |
4470 |
Fast Ethernet |
1514 |
1533 (4-port) 1532 (8-port) 1532 (12-port) Note:
The maximum MTU for two 100Base-TX Fast Ethernet port FIC is 9192 bytes. |
1500 (IPv4), 1497 (ISO) |
Gigabit Ethernet |
1514 |
9192 Note:
The maximum MTU for one Gigabit Ethernet port FIC is 9192 bytes. |
1500 (IPv4), 1497 (ISO) |
Serial |
1504 |
9192 |
1500 (IPv4), 1497 (ISO) |
SONET/SDH |
4474 |
9192 |
4470 |
Media MTU Sizes by Interface Type for M40e Routers
Interface Type |
Default Media MTU (Bytes) |
Maximum MTU (Bytes) |
Default IP Protocol MTU (Bytes) |
---|---|---|---|
Adaptive Services (MTU size not configurable) |
9192 |
N/A |
N/A |
ATM |
4482 |
9192 |
4470 |
E1/T1 |
1504 |
4500 |
1500 |
E3/T3 |
4474 |
4500 9192 (4-port) |
4470 |
E3/DS3 IQ |
4474 |
9192 |
4470 |
Fast Ethernet |
1514 |
1533 |
1500 (IPv4), 1497 (ISO) |
Gigabit Ethernet |
1514 |
9192 (1- or 2-port) 9192 (4-port) |
1500 (IPv4), 1497 (ISO) |
Serial |
1504 |
9192 |
1500 (IPv4), 1497 (ISO) |
SONET/SDH |
4474 |
4500 (1-port nonconcatenated) 9192 (4-port OC3) 9192 (4-port OC3c) 4500 (1-port OC12) 4500 (4-port OC12) 4500 (4-port OC12c) 4500 (1-port OC48) 9192 (2-port OC3) 9192 (2-port OC3c) 9192 (1-port OC12c) 9192 (1-port OC48c) 4500 (1-port OC192) 9192 (1-port OC192c) |
4470 |
Media MTU Sizes by Interface Type for M160 Routers
Interface Type |
Default Media MTU (Bytes) |
Maximum MTU (Bytes) |
Default IP Protocol MTU (Bytes) |
---|---|---|---|
Adaptive Services (MTU size not configurable) |
9192 |
N/A |
N/A |
ATM |
4482 |
9192 |
4470 |
E1/T1 |
1504 |
4500 |
1500 |
E3/T3 |
4474 |
4500 |
4470 |
E3/DS3 IQ |
4474 |
9192 |
4470 |
Fast Ethernet |
1514 |
1533 |
1500 (IPv4), 1497 (ISO) |
Gigabit Ethernet |
1514 |
9192 (1- or 2-port) 4500 (4-port) |
1500 (IPv4), 1497 (ISO) |
Serial |
1504 |
9192 |
1500 (IPv4), 1497 (ISO) |
SONET/SDH |
4474 |
4500 (1-port nonconcatenated) 9192 (1- or 2-port) 4500 (4-port) |
4470 |
Media MTU Sizes by Interface Type for M7i Routers with CFEB-E, M10i Routers with CFEB-E, and M320 and M120 Routers
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
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
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
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
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) |
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
andinet6
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 forinet
andinet6
families that are configured on the same logical interface.
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
Interface Type |
Default Media MTU (Bytes) |
Maximum MTU (Bytes) |
Default IP Protocol MTU (Bytes) |
---|---|---|---|
Management Ethernet Interfaces ( |
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:
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:
Default media MTU = Default IP MTU + encapsulation overhead
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:
MPLS MTU = physical interface MTU – encapsulation overhead – 12
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:
[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.
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.
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:
[edit] user@host# set interfaces interface-name description text
For example:
[edit] user@host# set interfaces fe-0/0/1 description "Backbone connection to PHL01"
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 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
See Also
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.
- Configuring Interface Ranges
- Expanding Interface Range Member and Member Range Statements
- Configuration Inheritance for Member Interfaces
- Member Interfaces Inheriting Configuration from Configuration Groups
- Interfaces Inheriting Common Configuration
- Configuring Inheritance Range Priorities
- Configuration Expansion Where Interface Range Is Used
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]
—Numbersnum1
,num2
, andnum3
specify multiple specific interfaces.
Example: Specifying an Interface Range Member Range
member-range ge-0/0/0 to ge-4/0/40;
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
member ge-0/0/0;
member ge-0/*/*
member ge-0/[1-10]/0;
member ge-0/[1,2,3]/3;
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:
[edit] interfaces { + interface-range foo { + member-range ge-1/0/0 to ge-4/0/40; + member ge-0/1/1; + member ge-5/[1-10]/*; /*Common configuration is added as part of interface-range definition*/ mtu 256; hold-time up 10; ether-options { flow-control; speed { 100m; } 802.3ad primary; } } }
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
protocols { dot1x { authenticator { interface foo{ retries 1; } } } }
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 Junos OS 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
[edit] interfaces { interface-range range-1 { member-range ge-0/0/0 to ge-4/0/20; member ge-10/1/1; member ge-5/[0-5]/*; /*Common configuration is added part of the interface-range definition*/ mtu 256; hold-time up 10; ether-options { flow-control; speed { 100m; } 802.3ad primary; } } }
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
.
interfaces { interface-range range-1 { member-range ge-1/0/0/ to ge-10/0/47; mtu 256; } ge-1/0/1 { mtu 1024; } }
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.
groups { global { interfaces { <*> { hold-time up 10; } } } } apply-groups [global]; interfaces { interface-range range-1 { member-range ge-1/0/0 to ge-10/0/47; mtu 256; } }
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; }
See Also
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.
[edit] interfaces { interface-range range-1 { member-range ge-1/0/0 to ge-10/0/47; mtu 256; } } interfaces { interface-range range-1 { member-range ge-10/0/0 to ge-10/0/47; hold-time up 10; } }
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.
[edit] interfaces { interface-range int-grp-one { member-range ge-0/0/0 to ge-4/0/40; member ge-1/1/1; /*Common config is added part of the interface-range definition*/ mtu 256; hold-time up 10; } } interfaces { interface-range int-grp-two { member-range ge-5/0/0 to ge-10/0/40; member ge-1/1/1; mtu 1024; } }
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:
[edit] interfaces { interface-range range-1 { member ge-10/1/1; member ge-5/5/1; mtu 256; hold-time up 10; ether-options { flow-control; speed { 100m; } 802.3ad primary; } } protocols { dot1x { authenticator { interface range-1 { retries 1; } } } } }
The interface
node present under authenticator
is expanded into member interfaces of the interface-range range-1
as follows:
protocols { dot1x { authenticator { interface ge-10/1/1 { retries 1; } interface ge-5/5/1 { retries 1; } } } }
The interface range-1
statement
is expanded into two interfaces, ge-10/1/1 and ge-5/5/1, and configuration retries 1
is copied under those two interfaces.
This configuration can be verified using the show protocols
dot1x | display inheritance
command.
Specifying an Aggregated Interface
The M Series, MX Series, and T Series routers support aggregated
interfaces. To specify an aggregated interface assign a number with
the aggregated interface name. For example, configure aex
at the [edit interfaces]
hierarchy
level, where x is an integer ranging 0 through
127 for M Series and T Series routers and 0 through 479 on MX Series
routers.
For aggregated SONET/SDH interfaces, configure asx
at the [edit interfaces]
hierarchy
level.
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.
See Also
Configuring the Interface Speed
You can configure the interface speed in following ways:
- Configuring the Interface Speed on Ethernet Interfaces
- Configuring Aggregated Ethernet Link Speed
- Configuring SONET/SDH Interface Speed
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.
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 by100m
or10m
maximum 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 thelink-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:
See Also
Configuring SONET/SDH Interface Speed
To configure the speed of SONET/SDH interfaces in concatenated mode:
To configure the speed of SONET/SDH interfaces in nonconcatenated mode:
In configuration mode, go to the
[edit interfaces interface-name]
hierarchy level, where theinterface-name
isso-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 for Routing Devices.
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:
[edit interfaces interface-name] link-mode (full-duplex | half-duplex);
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:
set interfaces ae0 unit 0 alias "controller-sat1-downlink1" set interfaces ae0.0 family inet address 10.0.0.1/24 set interfaces ae1 unit 0 alias "controller-sat1-downlink1" set interfaces ae0.0 family inet address 192.0.2.128/25 set interfaces ge-0/0/0 vlan-tagging set interfaces ge-0/0/0 unit 0 alias "ge-to-corp-gw1" set interfaces ge-0/0/0.0 vlan-id 101 set interfaces ge-0/0/0.0 family inet address 1.1.1.1/23 set interfaces ge-0/1/0 gigether-options 802.3ad ae0 set interfaces ge-0/1/1 gigether-options 802.3ad ae0 set protocols rip group corporate-firewall neighbor ge-to-corp-gw1
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 Junos OS 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-tagging user@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 101 user@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 ae0 user@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.
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 for Routing Devices, 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 for Routing Devices, 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:
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 for Routing Devices, 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 for Routing Devices, 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
- Encapsulation Capabilities of Physical Interfaces
- Configuring the Encapsulation on a Physical Interface
- 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
andextended-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:
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
andmpls
Action
Run the show
command at the [edit interfaces interface-name]
hierarchy level.
[edit interfaces so-7/0/0] user@host# show encapsulation ppp; unit 0 { point-to-point; family inet { address 192.168.1.113/32 { destination 192.168.1.114; } } family iso; family mpls; }
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.
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:
interfaces { et-fpc/pic/port { vlan-tagging; encapsulation flexible-ethernet-services; unit 0 { vlan-id 1000; family inet { address 11.0.0.20/24; } } unit 1 { encapsulation vlan-ccc; vlan-id 1010; } unit 2 { encapsulation vlan-tcc; vlan-id 1020; family tcc { proxy { inet-address 11.0.2.160; } remote { inet-address 11.0.2.10; } } } } }
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:
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 theencapsulation 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 theencapsulation 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 asintervalseconds
,down-countnumber
, and theup-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.
See Also
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:
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
- Damping Overview for Longer Physical Interface Transitions
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 theshow 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.

See Also
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:
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 theshow interface extensive
command output.
You can view the damping parameters with the show interfaces
extensive
command.
To configure damping of longer physical interface transitions:
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.
set interfaces xe-6/0/0 damping half-life 11 max-suppress 2222 reuse 3333 suppress 4444 enable
Procedure
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.
user@router# show interfaces
xe-6/0/0 {
damping {
half-life 11;
max-suppress 2222;
reuse 3333;
suppress 4444;
enable;
}
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.
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:
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
- Configuring Accounting for the Physical Interface
- Displaying Accounting Profile 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 Junos OS Network Management Administration Guide for Routing Devices.
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.
See Also
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
- Example: Disabling a Physical Interface
- Effect of Disabling Interfaces on T series PICs
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:
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:
[edit interfaces] user@host# show ge-0/3/2 { unit 0 { description CE2-to-PE1; family inet { address 20.1.1.6/24; } } }
Disabling the interface:
[edit interfaces ge-0/3/2] user@host# set disable
Verifying the interface configuration:
[edit interfaces ge-0/3/2] user@host# show disable; # Interface is marked as disabled. unit 0 { description CE2-to-PE1; family inet { address 20.1.1.6/24; } }
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.
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 |