Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Physical Interface Properties

Use this topic to configure various properties of physical interfaces on your device. Read on to configure properties such as interface descriptions, interface speeds, and accounting profiles for physical interfaces.

Physical Interface Properties Overview

The software driver for each network media type sets reasonable default values for general interface properties. These properties include 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.

Configure the 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. The interface description 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. The description can be a single line of text. If the text contains spaces, enclose it in quotation marks.

For example:

Note:

You can configure the extended DHCP relay to include the interface description in the option 82 Agent Circuit ID suboption. See Using DHCP Relay Agent Option 82 Information.

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.

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

How to Specify an Aggregated Interface

An aggregated interface is a group of interfaces. To specify an aggregated Ethernet interface, configure aex at the [edit interfaces] hierarchy level, where x is an integer starting at 0.

The integer x ranges from 0 through 127 for M Series and T Series routers and 0 through 479 on MX Series routers.

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.

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

Note:

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

Interface Speed

The interface speed is the maximum amount of data that can travel through an interface per second. An interface speed ending in m is in megabits per second (Mbps). A link speed ending in g is in gigabits per second (Gbps).

Configuring the Interface Speed on Ethernet Interfaces

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

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

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

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

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

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

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

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

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

See Also

Configure the SONET/SDH Interface Speed

You can configure the speed on SONET/SDH interfaces in concetenated, nonconcatenated, or channelized (multiplexed) mode.

To configure the SONET/SDH interface speed in concatenated mode:

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

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

To configure the SONET/SDH interface speed in nonconcatenated mode:

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

  2. Configure the interface speed in nonconcatenated mode.

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

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

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

  2. Configure the no-concatenate option.

Note:

On SONET/SDH OC3/STM1 (Multi-Rate) MIC with small form-factor pluggable (SFP), Channelized SONET/SDH OC3/STM1 (Multi-Rate) message integrity check (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.

Forward Error Correction (FEC)

SUMMARY Forward error correction (FEC) improves the reliability of the data transmitted by your device. When FEC is enabled on an interface, that interface sends redundant data. The receiver accepts data only where the redundant bits match, which removes erroneous data from the transmission. Junos OS enables you (the network administrator) to configure Reed-Solomon FEC (RS-FEC) and BASE-R FEC on Ethernet interfaces. RS-FEC is compliant with IEEE 802.3-2015 Clause 91. BASE-R FEC is compliant with IEEE 802.3-2015 Cause 74.

Benefits of FEC

When you configure FEC on Ethernet interfaces, FEC improves your device function in these ways:

  • Enhances the reliability of the connection

  • Enables the receiver to correct transmission errors without requiring retransmission of the data

  • Extends the reach of optics

Overview

By default, Junos OS enables or disables FEC based on the plugged-in optics. For instance, Junos OS enables RS-FEC for 100 Gigabit (Gb) SR4 optics and disables RS-FEC for 100 G LR4 optics. You can override the default behavior and explicitly enable or disable RS-FEC.

You can enable or disable RS-FEC for 100-Gigabit Ethernet (GbE) interfaces. After you enable or disable RS-FEC using this statement, this behavior applies to any 100GbE optical transceiver installed in the port associated with the interface.

You can configure FEC clauses CL74 on 25 Gb and 50 Gb interfaces and CL91 on 100 Gb interfaces. Because the FEC clauses are applied by default on these interfaces, you must disable the FEC clauses if you do not want to apply them.

Note:

PTX5000 routers with FPC-PTX-P1-A and FPC2-PTX-P1A do not support RS-FEC.

On PTX3000 and PTX5000 routers, FPC3-SFF-PTX-1H and FP3-SFF-PTX-1T with PE-10-U-QSFP28 PIC and LR4 optics support RS-FEC only on port 2. For PE-10-U-QSFP28 with LR4 optics, RS-FEC is the default FEC mode on port 2 and NONE is the default FEC mode on ports 0, 1, and 3 through 9. For PE-10-U-QSFP28 with SR4 optics, RS-FEC is enabled by default on all ports. Do not modify the FEC mode on any port, irrespective of the optics installed.

Configure FEC

To disable or enable an FEC mode on an interface and any associated interfaces, complete the relevant action:

  1. To disable FEC mode:
  2. To enable an FEC mode:

    Alternatively:

  3. To view the FEC mode on an interface, use the show interfaces interface-name command. The output lists FEC statistics for that particular interface, including the number of FEC corrected errors, the number of FEC uncorrected errors, and the type of FEC that was disabled or enabled.

Interface Aliases

Overview

An interface alias is a textual description of a logical unit on a physical interface. An alias enables you to give a single meaningful and easily identifiable name to an interface. Interface aliasing is supported only at the unit level.

The alias name is displayed instead of the interface name in the output of all show, show interfaces, and other operational mode commands. Configuring an alias for a logical unit of an interface has no effect on how the interface operates on the device.

To suppress the alias in favor of the interface name, use the display no-interface-alias parameter along with the show command.

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. When the operating system processes query the configuration database for the interface-name variable, the exact value of the interface-name variable is returned instead of the alias name for system operations and computations.

Using the exact value of the interface name for system operations and computations enables backward compatibility with Junos OS releases in which the support for interface aliases is not available.

Configuration

To specify an interface alias, use the alias statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level. Start the alias name with a letter followed by letters, numbers, dashes, dots, underscores, colons, or slashes. Avoid starting the alias with any part of a valid interface name. Use between 5 and 128 characters.

For example:

On some devices, you can also configure the alias at the [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number] hierarchy level.

Note:

If you configure the same alias name on more than one logical interface, the router displays an error message, and the commit fails.

You can use interface alias names to make it easy to see the roles interfaces play in your configuration. For example, to make it easy to identify satellite connection interfaces:

  1. Group physical interfaces as one aggregated interface using a link aggregation group (LAG) or LAG bundle. Name that aggregated interface sat1 to show it is a satellite connection interface.
  2. Select a logical interface as a member of the LAG bundle or the entire LAG. Name that interface et-0/0/1 to represent a satellite device port or a service instance.
  3. You can combine the satellite name and the interface name aliases to wholly represent the satellite port name. For example, you could give your satellite port the alias sat1:et-0/0/1.

Example: Add 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. This capability to define interface alias names for physical and logical interfaces is useful in a Junos Node Unifier (JNU) environment that contains the following devices:

  • A Juniper Networks MX Series 5G Universal Routing Platform as a controller

  • EX Series Ethernet switches, QFX Series devices, and ACX Series Universal Metro Routers as satellite devices

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. 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 JNU controller interfaces that are connected to a satellite, sat1. The interfaces are connected 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:

Add an Interface Alias Name 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 interface alias name to the controller interfaces that are used to connect to the satellite devices in the downlink direction:

  1. Configure an alias name for the logical unit of an aggregated Ethernet interface that is used to connect to a satellite, sat1, in the downlink direction. Configure the 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 the downlink direction. Configure the 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

Use the examples in this section to verify that the alias name is displayed instead of the interface name.

Verify the Configuration of the Alias Name for the Controller Interfaces

Purpose

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

Action

Display information about all RIP neighbors.

Meaning

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

See Also

Clock Source Overview

For both the device 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 Control Board (CB) for M120 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 (T Series) and Switch Control Board (SCB) (MX Series). By default, the 19.44-MHz Stratum 3 reference clock generates the clock signal for all serial PICs (SONET/SDH) and PDH PICs. PDH PICs include DS3, E3, T1, and E1.

Note:

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

Configure the Clock Source

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

To set the clock source as external or internal:

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

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 M120 and M320 routers and on T Series routers, see 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 Synchronous Ethernet Overview and Configuring Clock Synchronization Interface on MX Series Routers.

See Also

Interface Encapsulation on Physical Interfaces

Point-to-Point Protocol (PPP) encapsulation is the default encapsulation type for physical interfaces. You don't need to configure encapsulation for physical interfaces that support PPP encapsulation, because 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. On a logical interface, you can optionally configure an encapsulation type that Junos OS uses within certain packet types.

Encapsulation Capabilities

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 circuit cross-connect (CCC) encapsulation for Ethernet interfaces with standard Tag Protocol Identifier (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 encapsulation types extended-vlan-ccc and extended-vlan-vpls, all VLAN IDs are valid.

  • For Gigabit Ethernet interfaces and Gigabit Ethernet IQ and IQE PICs with SFPs, 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.

    Note:

    The 10-port Gigabit Ethernet PIC and the built-in Gigabit Ethernet port on the M7i router do not support flexible Ethernet services encapsulation.

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

When you configure a translational cross-connect (TCC) encapsulation, some modifications are needed to handle VPN connections over dissimilar Layer 2 and Layer 2.5 links and terminate the Layer 2 and Layer 2.5 protocol locally. The device performs the following media-specific changes:

  • Point-to-Point Protocol (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. Junos OS strips all PPP encapsulation data from incoming frames before forwarding them. For output, the next hop is changed to PPP encapsulation.

  • Cisco High-Level Data Link Control (HDLC) TCC—Keepalive processing is terminated on the router. 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. 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.

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

Encapsulation Types

The physical interface encapsulation types include:

  • ATM CCC cell relay—Connects two remote virtual circuits or ATM physical interfaces with a label-switched path (LSP). Traffic on the circuit is ATM cells.

  • ATM PVC—Defined in RFC 2684, Multiprotocol Encapsulation over ATM Adaptation Layer 5. When you configure physical ATM interfaces with ATM PVC encapsulation, an RFC 2684-compliant ATM Adaptation Layer 5 (AAL5) tunnel is set up to route the ATM cells over a Multiprotocol Label Switching (MPLS) path that is typically established between two MPLS-capable routers using the Label Distribution Protocol (LDP).

  • Cisco-compatible High-Level Data Link Control (HDLC) framing (cisco-hdlc)—E1, E3, SONET/SDH, T1, and T3 interfaces can use Cisco HDLC encapsulation. Two related versions are supported:

    • CCC version (cisco-hdlc-ccc)—The logical interface does not require an encapsulation statement. When you use this encapsulation type, you can configure the ccc family only.

    • TCC version (cisco-hdlc-tcc)—Similar to CCC and has the same configuration restrictions, but used for circuits with different media on either side of the connection.

  • Ethernet cross-connect—Ethernet interfaces without VLAN tagging can use Ethernet CCC encapsulation. Two related versions are supported:

    • CCC version (ethernet-ccc)—Ethernet interfaces with standard Tag Protocol ID (TPID) tagging can use Ethernet CCC encapsulation. When you use this encapsulation type, you can configure the ccc family only.

    • TCC version (ethernet-tcc)—Similar to CCC, but used for circuits with different media on either side of the connection.

      For 8-port, 12-port, and 48-port Fast Ethernet PICs, TCC is not supported.

  • VLAN CCC (vlan-ccc)—Ethernet interfaces with VLAN tagging enabled can use VLAN CCC encapsulation. VLAN CCC encapsulation supports TPID 0x8100 only. When you use this encapsulation type, you can configure the ccc family only.

    When you configure Ethernet VLAN encapsulation on CCC circuits by using the encapsulation vlan-ccc statement at the [edit interfaces interface-name] hierarchy level, you can bind a list of VLAN IDs to the interface. To configure a CCC for multiple VLANs, use the vlan-id-list [ vlan-id-numbers ] statement. Configuring this statement creates a CCC for:

    • Each VLAN listed—for example, vlan-id-list [ 100 200 300 ]

    • Each VLAN in a range—for example, vlan-id-list [ 100-200 ]

    • Each VLAN in a list and range combination—for example, vlan-id-list [ 50, 100-200, 300 ]

  • Extended VLAN cross-connect—Gigabit Ethernet interfaces with VLAN 802.1Q tagging enabled can use extended VLAN cross-connect encapsulation. (Ethernet interfaces with standard TPID tagging can use VLAN CCC encapsulation.) Two related versions of extended VLAN cross-connect are supported:

    • CCC version (extended-vlan-ccc)—Extended VLAN CCC encapsulation supports TPIDs 0x8100, 0x9100, and 0x9901. When you use this encapsulation type, you can configure the ccc family only.

    • TCC version (extended-vlan-tcc)—Similar to CCC, but used for circuits with different media on either side of the connection.

      For 8-port, 12-port, and 48-port Fast Ethernet PICs, extended VLAN CCC is not supported. For 4-port Gigabit Ethernet PICs, extended VLAN CCC and extended VLAN TCC are not supported.

  • Ethernet VPLS (ethernet-vpls)—Ethernet interfaces with VPLS enabled can use Ethernet VPLS encapsulation.

  • Ethernet VLAN VPLS (vlan-vpls)—Ethernet interfaces with VLAN tagging and VPLS enabled can use Ethernet VLAN VPLS encapsulation.

  • Extended VLAN VPLS (extended-vlan-vpls)—Ethernet interfaces with VLAN 802.1Q tagging and VPLS enabled can use Ethernet Extended VLAN VPLS encapsulation. (Ethernet interfaces with standard TPID tagging can use Ethernet VLAN VPLS encapsulation.) Extended Ethernet VLAN VPLS encapsulation supports TPIDs 0x8100, 0x9100, and 0x9901.

  • Flexible Ethernet services (flexible-ethernet-services)—Gigabit Ethernet 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) can use flexible Ethernet services encapsulation. Aggregated Ethernet bundles can use this encapsulation type. You use this encapsulation type when you want to configure multiple per-unit Ethernet encapsulations. This encapsulation type allows you to configure any combination of route, TCC, CCC, Layer 2 virtual private networks (VPNs), and VPLS encapsulations on a single physical port. If you configure flexible Ethernet services encapsulation on the physical interface, VLAN IDs from 1 through 511 are no longer reserved for normal VLANs.

  • PPP—Defined in RFC 1661, The Point-to-Point Protocol (PPP) for the Transmission of Multiprotocol Datagrams over Point-to-Point Links. PPP is the default encapsulation type for physical interfaces. E1, E3, SONET/SDH, T1, and T3 interfaces can use PPP encapsulation.

Configure Encapsulation on a Physical Interface

To configure encapsulation on a physical interface:

  1. In configuration mode, go to the [edit interfaces interface-name] hierarchy level.
  2. Configure the encapsulation type.
    Note:

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

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

Display the Encapsulation on a Physical SONET/SDH Interface

Purpose

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

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

  • Encapsulation—ppp

  • Unit—0

  • Family—inet

  • Address—192.168.1.113/32

  • Destination—192.168.1.114

  • Family—iso and mpls

Action

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

Meaning

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

Configure Interface Encapsulation on PTX Series Routers

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

Supported encapsulations for physical interfaces include:

  • flexible-ethernet-services

  • ethernet-ccc

  • ethernet-tcc

Supported encapsulations for logical interfaces include:

  • ethernet

  • vlan-ccc

  • vlan-tcc

Note:

PTX Series Packet Transport Routers do not support extended-vlan-cc or 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:

Keepalives

By default, physical interfaces configured with Cisco High-Level Data Link Control (HDLC) or Point-to-Point Protocol (PPP) encapsulation send keepalive packets at 10-second intervals. The Frame Relay term for keepalives is Local Management Interface (LMI) packets; the Junos OS supports both ANSI T1.617 Annex D LMIs and International Telecommunication Union (ITU) Q933 Annex A LMIs. On Asynchronous Transfer Mode (ATM) networks, Operation, Administration, and Maintenance (OAM) cells perform the same function. You configure OAM cells at the logical interface level; for more information, see Defining the ATM OAM F5 Loopback Cell Period.

To disable the sending of keepalives:

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

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

  1. In configuration mode, go to the [edit interfacesinterface-name] hierarchy level.

  2. Include the no-keepalives statement with the encapsulation cisco-hdlc-tcc statement at the [edit interfaces interface-name] hierarchy level.

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

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

  2. Include the no-keepalives statement with the encapsulation ppp-tcc statement at the [edit interfaces interface-name] hierarchy level.

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

To explicitly enable the sending of keepalives:

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

  2. Include the keepalives statement at the [edit interfaces interface-name] hierarchy level.

To change one or more of the default keepalive values:

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

  2. Include the keepalives statement with the appropriate option as intervalseconds, down-countnumber, and the up-countnumber.

On interfaces configured with Cisco HDLC or PPP encapsulation, you can include the following three keepalive statements. Note that these statements do not affect Frame Relay encapsulation:

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

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

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

CAUTION:

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

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

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

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.

Benefits

  • 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.
  • 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, this can reduce the total number of ports required.
Note:

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

  • 4–port 10–Gigabit Ethernet Dense Port Concentrator (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, maximum transmittion unit (MTU) size, and logical interfaces.

Unidirectional interfaces support IP and IP version 6 (IPv6). Packet forwarding takes place by means of static routes and static Address Resolution Protocol (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.

Enable Unidirectional Traffic Flow on Physical Interfaces

Unidirectional link mode makes the traffic flow in only one direction. To enable unidirectional link mode on a physical 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.

Enable SNMP Notifications on Physical Interfaces

By default, Junos OS sends Simple Network Management Protocol (SNMP) notifications when the state of an interface or a connection changes. You can enable or disable SNMP notifications based on your requirements.

To explicitly enable sending SNMP notifications on the physical interface:

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

To disable SNMP notifications on the physical interface:

  1. In configuration mode, go to the [edit interfaces interface-name] hierarchy level:

  2. Configure the no-traps option to disable SNMP notifications when the state of the connection changes.

Accounting for Physical Interfaces

Devices running Junos OS can collect various kinds of data about traffic passing through the device. You (the systems administrator) can set up one or more accounting profiles that specify some common characteristics of this data. These characteristics include 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

Overview

There are two types of accounting profiles: filter profiles and interface profiles. Configure the profiles using statements at the [edit accounting-options] hierarchy level.

Configure filter profiles by including the filter-profile statement at the [edit accounting-options] hierarchy level. 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.

Configure interface profiles by including the interface-profile statement at the [edit accounting-options] hierarchy level. Read on to learn how to configure interface profiles.

Configure an Accounting Profile for a Physical Interface

Before You Begin

Configure an accounting data log file at the [edit accounting-options] hierarchy level. The operating system logs the statistics in the accounting data log file.

For more information about how to configure an accounting data log file, see the Configuring Accounting-Data Log Files.

Configuration

Configure an interface profile to collect error and statistic information for input and output packets on a particular physical interface. The interface profile specifies the information that the operating system writes to the log file.

To configure an interface profile:

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

    You must specify a file statement for the interface profile that has already been configured at the [edit accounting-options] hierarchy level.
  4. The operating system collects statistics from each interface with an accounting profile enabled. It collects the statistics once per interval time specified for the accounting profile. The operating system schedules statistics collection time evenly over the configured interval. To configure the interval, use the interval statement:
    Note:

    The minimum interval allowed is 1 minute. Configuring a low interval in an accounting profile for a large number of interfaces might cause serious performance degradation.
  5. Apply the interface profile to a physical interface by including the accounting-profile statement at the [edit interfaces interface-name] hierarchy level. The operating system performs the accounting on the interfaces that you specify.

See Also

How to Display the Accounting Profile

Purpose

To display the configured accounting profile of a particular physical interface at the [edit accounting-options interface-profile profile-name] hierarchy level that has been configured with the following:

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

  • Interface profile —if_profile

  • File name—if_stats

  • Interval—15 minutes

Action

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

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

Meaning

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

Disable a Physical Interface

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

How to Disable a Physical Interface

CAUTION:

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

To disable a physical interface:

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

    For example:

    Note:

    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. On a device with newer PICs, the laser turns off when the interface is disabled.
    Laser Warning:

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

Example: Disable a Physical Interface

Sample interface configuration:

Disable the interface:

Verify the interface configuration:

Effect of Disabling Interfaces on T Series PICs

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

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

PIC Model Number

PIC Description

Type of PIC

Behavior

PF-12XGE-SFPP

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

5

Transmit (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
Release History Table
Release
Description
14.2
Starting with Junos OS Release 14.2 the auto-10m-100m option allows the fixed tri-speed port to auto negotiate with ports limited by 100m or 10mmaximum speed. This option must be enabled only for Tri-rate MPC port, that is, 3D 40x 1GE (LAN) RJ45 MIC on MX platform. This option does not support other MICs on MX platform.
11.4
Starting with Junos OS Release 11.4, half-duplex mode is not supported on Tri-Rate Ethernet copper interfaces. When you include the speed statement, you must include the link-mode full-duplex statement at the same hierarchy level.