Physical Interface Properties

Physical Interface Properties Overview

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.

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

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

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

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

• MPC8E (MX2K-MPC8E)

• MPC9E (MX2K-MPC9E)

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

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

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

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

Media MTU Sizes by Interface Type for T320 Routers

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 JRR200 Series Routers

Configuring the Media MTU

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

• If you change the size of the media MTU, you must ensure that the size is equal to or greater than the sum of the protocol MTU and the encapsulation overhead. You configure the protocol MTU by including the mtu statement at the following hierarchy levels:

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

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

Configuring the Media MTU on ACX Series Routers

• Media MTU Overview

• How to Configure the Media MTU

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.

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.

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

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.

Configuring Interface Description

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

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

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:

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

Configuring Interface Ranges

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

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

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

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.

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.

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.

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.

• protocols dot1x authentication interface

• protocols dvmrp interface

• protocols oam ethernet lmi interface

• protocols esis interface

• protocols igmp interface

• protocols igmp-host client num interface

• protocols mld-host client num interface

• protocols router-advertisement interface

• protocols isis interface

• protocols ldp interface

• protocols oam ethernet link-fault-management interface

• protocols lldp interface

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

• protocols link-management peer control-channel

• protocols link-management te-link name interface

• protocols mld interface

• protocols ospf area id interface

• protocols pim interface

• protocols router-discovery interface

• protocols rip group name neighbour

• protocols ripng group name neighbour

• protocols rsvp interface

• protocols snmp interface

• protocols layer2-control bpdu-block interface

• protocols layer2-control mac-rewrite interface

• protocols mpls interface

• protocols stp interface

• protocols rstp interface

• protocols mstp interface

• protocols vstp interface

• protocols mstp msti id interface

• protocols mstp msti vlan id interface

• protocols vstp vlan name interface

• protocols gvrp interface

• protocols igmp-snooping vlan name interface

• protocols lldp interface

• protocols lldp-med interface

• protocols sflow interfaces

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

• ethernet-switching-options analyzer name output interface

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

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

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

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

• ethernet-switching-options bpdu-block interface

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

Expanding Interface Range Member and Member Range Statements

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

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.

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:

Member Interfaces Inheriting Configuration from Configuration Groups

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

Interfaces Inheriting Common Configuration

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

Configuring Inheritance Range Priorities

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

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.

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

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

1. In configuration mode, go to the [edit interfaces interface-name] hierarchy level.
2. To configure the speed, include the speed statement at the [edit interfaces interface-name] hierarchy level.

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.

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.

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

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

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

   • 100m—Links are 100 Mbps.

   • 10g—Links are 10 Gbps.

   • 1g—Links are 1 Gbps.

   • oc192—Links are OC192 or STM64c.

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

   • 10m—Links are 10 Mbps.

   • 100m—Links are 100 Mbps.

   • 1g—Links are 1 Gbps.

   • 10g—Links are 10 Gbps.

   • 50g—Links are 50 Gbps.

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

   • 100g—Links are 100 Gbps.

   • 100m—Links are 100 Mbps.

   • 10g—Links are 10 Gbps.

   • 1g—Links are 1 Gbps.

   • 40g—Links are 40 Gbps.

   • 50g—Links are 50 Gbps.

   • 80g—Links are 80 Gbps.

   • 8g—Links are 8 Gbps.

   • mixed—Links are of various speeds.

   • oc192—Links are OC192.

Configuring SONET/SDH Interface Speed

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

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

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

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

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

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.

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.

Example: Adding an Interface Alias Name

• Requirements

• Overview

• Configuration

• Verification

Requirements

• 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

• Configuring Alias Names for the Controller Interfaces

• Results

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

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

Results

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

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

Verification

• Verifying the Configuration of the Alias Name for the Controller Interfaces

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

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 information about clocking on channelized interfaces, see Channelized IQ and IQE Interfaces Properties. Also see Configuring the Clock Source on SONET/SDH Interfaces and Configuring the Channelized T3 Loop Timing.

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

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

Configuring the Clock Source

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

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

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

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

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

Configuring Interface Encapsulation on 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.

• flexible-ethernet-services

• ethernet-ccc

• ethernet-tcc

• ethernet

• vlan-ccc

• vlan-tcc

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Enabling Unidirectional Traffic Flow on Physical Interfaces

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

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

Physical Interface Damping Overview

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

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

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

• Periodic flaps of long duration (seconds).

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

Figure 1: Two Router Interfaces Connected Through Transport Equipment

Note

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

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

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

Figure 2: Multiple Flaps of Short Duration (Milliseconds)

Damping Overview for Longer Physical Interface Transitions

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

Figure 3: Periodic Flaps of Long Duration (Seconds)

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.

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

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

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

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

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

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

Damping Shorter Physical Interface Transitions

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

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

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

Damping Longer Physical Interface Transitions

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

   Configure max-suppress to a value that is greater than the value of half-life; otherwise, the configuration is rejected.
4. (Optional) Set the decay half-life in seconds, which is the interval after which the accumulated interface penalty counter is reduced by half if the interface remains stable.Note

   Configure max-suppress to a value that is greater than the value of half-life; otherwise, the configuration is rejected.
5. (Optional) Set the reuse threshold (no units). When the accumulated interface penalty counter falls below this value, the interface is no longer suppressed.
6. (Optional) Set the suppression threshold (no units). When the accumulated interface penalty counter exceeds this value, the interface is suppressed.

Example: Configuring Physical Interface Damping

• Requirements

• Overview

• Configuration

• Verification

Requirements

• 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

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

Results

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

Verification

• Verifying Interface Damping on xe-6/0/0

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

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.

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

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