[Contents] [Prev] [Next] [Index] [Report an Error]

Special Interfaces

In addition to the configured network interfaces associated with the physical ports and wires that make up much of the network, devices have special interfaces. Table 22 lists each special interface and briefly describes its use.

For information about interface names, see Network Interface Naming.

Table 22: Special Interfaces

Interface Name	Description
dsc	Discard interface. See Discard Interface.
fxp0	In a J-series Services Router chassis cluster configuration, configurable management interfaces are created from built-in interfaces on the connected J-series chassis. The fxp0 interface is the management port, and fxp1 is used as the control link interface in a chassis cluster. In an SRX-series services gateway, the fxp0 management interface is a dedicated port located on the Routing Engine. In an SRX-series services gateway chassis cluster configuration, the control link interface must be port 0 on an SPC. For each node in the chassis cluster, you must configure the SPC that is used for the control link interface. For more information about chassis clusters, see the JUNOS Software Security Configuration Guide. For more information about the device management port interfaces, see Management Interface.
gr-0/0/0	Configurable generic routing encapsulation (GRE) interface. GRE allows the encapsulation of one routing protocol over another routing protocol. Within a J-series device, packets are routed to this internal interface, where they are first encapsulated with a GRE packet and then re-encapsulated with another protocol packet to complete the GRE. The GRE interface is an internal interface only and is not associated with a physical medium or PIM. You must configure the interface for it to perform GRE.
gre	Internally generated GRE interface. This interface is generated by the JUNOS software to handle GRE. It is not a configurable interface.
ip-0/0/0	Configurable IP-over-IP encapsulation (also called IP tunneling) interface. IP tunneling allows the encapsulation of one IP packet over another IP packet. Generally, IP routing allows packets to be routed directly to a particular address. However, in some instances you might need to route an IP packet to one address and then encapsulate it for forwarding to a different address. In a mobile environment in which the location of the end device changes, a different IP address might be used as the end device migrates between networks. Within a J-series device, packets are routed to this internal interface where they are encapsulated with an IP packet and then forwarded to the encapsulating packet's destination address. The IP-IP interface is an internal interface only and is not associated with a physical medium or PIM. You must configure the interface for it to perform IP tunneling.
ipip	Internally generated IP-over-IP interface. This interface is generated by the JUNOS software to handle IP-over-IP encapsulation. It is not a configurable interface.
lo0	Loopback address. The loopback address has several uses, depending on the particular JUNOS feature being configured. See Loopback Interface.
lo0.16384	Internal loopback address. The internal loopback address is a particular instance of the loopback address with the logical unit number 16384. It is created by the JUNOS software as the loopback interface for the internal routing instance. This interface prevents any filter on lo0.0 from disrupting internal traffic.
ls-0/0/0	Configurable link services interface. Link services include the multilink services MLPPP, MLFR, and Compressed Real-Time Transport Protocol (CRTP). Within a J-series device, packets are routed to this internal interface for link bundling or compression. The link services interface is an internal interface only and is not associated with a physical medium or PIM. You must configure the interface for it to perform multilink services. For more information about multilink services, see Services Interfaces.
lsi	Internally generated link services interface. This interface is generated by the JUNOS software to handle multilink services like MLPPP, MLFR, and CRTP. It is not a configurable interface.
lt-0/0/0	Interface used to provide class-of-service (CoS) support for real-time performance monitoring (RPM) probe packets. Within a J-series device, packets are routed to this internal interface for services. The lt interface is an internal interface only and is not associated with a physical medium or PIM. You must configure the interface for it to perform CoS for RPM services. Note: The lt interface on the M-series and T-series routing platforms supports configuration of logical devices—the capability to partition a single physical device into multiple logical devices that perform independent routing tasks. However, the lt interface on the J-series device does not support logical devices.
pc-pim/0/0	Internally configured interface used by the system as a control path between the WXC Integrated Services Module and the Routing Engine.
pd-0/0/0	Configurable Protocol Independent Multicast (PIM) de-encapsulation interface. In PIM sparse mode, the first-hop routing platform encapsulates packets destined for the rendezvous point device. The packets are encapsulated with a unicast header and are forwarded through a unicast tunnel to the rendezvous point. The rendezvous point then de-encapsulates the packets and transmits them through its multicast tree. Within a J-series device, packets are routed to this internal interface for de-encapsulation. The PIM de-encapsulation interface is an internal interface only and is not associated with a physical medium or Physical Interface Module (PIM). You must configure the interface for it to perform PIM de-encapsulation.
pe-0/0/0	Configurable Protocol Independent Multicast (PIM) encapsulation interface. In PIM sparse mode, the first-hop routing platform encapsulates packets destined for the rendezvous point device. The packets are encapsulated with a unicast header and are forwarded through a unicast tunnel to the rendezvous point. The rendezvous point then de-encapsulates the packets and transmits them through its multicast tree. Within a J-series device, packets are routed to this internal interface for encapsulation. The PIM encapsulation interface is an internal interface only and is not associated with a physical medium or Physical Interface Module (PIM). You must configure the interface for it to perform PIM encapsulation.
pimd	Internally generated Protocol Independent Multicast (PIM) de-encapsulation interface. This interface is generated by the JUNOS software to handle PIM de-encapsulation. It is not a configurable interface.
pime	Internally generated Protocol Independent Multicast (PIM) encapsulation interface. This interface is generated by the JUNOS software to handle PIM encapsulation. It is not a configurable interface.
pp0	Configurable PPPoE encapsulation interface. PPP packets being routed in an Ethernet network use PPPoE encapsulation. Within a J-series device, packets are routed to this internal interface for PPPoE encapsulation. The PPPoE encapsulation interface is an internal interface only and is not associated with a physical medium or PIM. You must configure the interface for it to forward PPPoE traffic. For more information about PPPoE interfaces, see Configuring Point-to-Point Protocol over Ethernet.
st0	Secure tunnel interface used for IPSec VPNs.
tap	Internally generated interface. This interface is generated by the JUNOS software to monitor and record traffic during passive monitoring. When packets are discarded by the Packet Forwarding Engine, they are placed on this interface. It is not a configurable interface.
umd0	Configurable USB modem physical interface. This interface is detected when an USB modem is connected to the USB port on the device. Note: The J4350 and J6350 devices have two USB ports. However, you can connect only one USB modem to the USB ports on these devices. If you connect USB modems to both the USB ports, only the first USB modem connected to the device is recognized.

Discard Interface

The discard (dsc) interface is not a physical interface, but a virtual interface that discards packets. You can configure one discard interface. This interface allows you to identify the ingress (inbound) point of a denial-of-service (DoS) attack. When your network is under attack, the target host IP address is identified, and the local policy forwards attacking packets to the discard interface. Traffic routed out the discard interface is silently discarded.

Loopback Interface

The Internet Protocol (IP) specifies a loopback network with the (IPv4) address 127.0.0.0/8. Most IP implementations support a loopback interface (lo0) to represent the loopback facility. Any traffic that a computer program sends on the loopback network is addressed to the same computer. The most commonly used IP address on the loopback network is 127.0.0.1 for IPv4 and ::1 for IPv6. The standard domain name for the address is localhost.

The loopback interface can perform the following functions:

Device identification—The loopback interface is used to identify the device. While any interface address can be used to determine if the device is online, the loopback address is the preferred method. Whereas interfaces might be removed or addresses changed based on network topology changes, the loopback address never changes.
When you ping an individual interface address, the results do not always indicate the health of the device. For example, a subnet mismatch in the configuration of two endpoints on a point-to-point link makes the link appear to be inoperable. Pinging the interface to determine whether the devicer is online provides a misleading result. An interface might be unavailable because of a problem unrelated to the device's configuration or operation.
Routing information—The loopback address is used by protocols such as OSPF to determine protocol-specific properties for the device or network. Further, some commands such as ping mpls require a loopback address to function correctly.
Packet filtering—Stateless firewall filters can be applied to the loopback address to filter packets originating from, or destined for, the Routing Engine.

Management Interface

Management interfaces are the primary interfaces for accessing the device remotely. Typically, a management interface is not connected to the in-band network, but is connected instead to the device's internal network. Through a management interface you can access the device over the network using utilities such as ssh and telnet and configure it from anywhere, regardless of its physical location. Simple Network Management Protocol (SNMP) can use the management interface to gather statistics from the device.

Management interfaces vary based on device type:

The J-series Services Routers include four built-in Gigabit Ethernet interfaces located on the front panel of the router chassis named ge-0/0/0, ge-0/0/1, ge-0/0/2, and ge-0/0/3 from left to right. These are not physically dedicated management interfaces, although the factory configuration for these routers automatically enables the J-Web user interface on these interfaces. You can use them to pass traffic or you can segregate one off and place it in the management zone to be used as a management interface. To use a built-in interface as a management Ethernet interface, configure it with a valid IP address.
The SRX 5600 and SRX 5800 services gateways include a 10/100-Mbps Ethernet port on the Routing Engine (RE). This port, which is labeled ETHERNET, is a dedicated out-of-band management interface for the device. The JUNOS software automatically creates the device’s management interface fxp0. To use fxp0 as a management port, you must configure its logical port fxp0.0 with a valid IP address. While you can use fxp0 to connect to a management network, you cannot place it into the management zone.

Note: On the SRX 5600 and SRX 5800 services gateways, you must first connect to the device through the serial console port before assigning a unique IP address to the management interface.

As a security feature, users cannot log in as root through a management interface. To access the device as root, you must use the console port.

Services Interfaces

On Juniper Networks M-series and T-series routing platforms, individual services such as IP-over-IP encapsulation, link services such as multilink protocols, adaptive services such as stateful firewall filters and NAT, and sampling and logging capabilities are implemented by services Physical Interface Cards (PICs). On a J-series Services Router, these same features are implemented by the general-purpose CPU on the main circuit board.

Although the same JUNOS software image supports the services features across all routing platforms, on a J-series device no Physical Interface Module (PIM) is associated with services features.

To configure services on a J-series device, you must configure one or more internal interfaces by specifying PIM slot 0 and port 0—for example, gr-0/0/0 for GRE.

J-series devices support multilink protocol services on the ls-0/0/0 interface. At the logical level, the ls-0/0/0 interface supports the Multilink Point-to-Point Protocol (MLPPP) and Multilink Frame Relay (MLFR) FRF.15 encapsulation types, and at the physical level, the interface supports the MLRF FRF.16 encapsulation type and Compressed Real-Time Transport Protocol (CRTP).

MLPPP and MLFR

Multilink Point-to-Point Protocol (MLPPP) is a protocol for aggregating multiple constituent links into one larger PPP bundle. Multilink Frame Relay (MLFR) allows you to aggregate multiple Frame Relay links by inverse multiplexing. MLPPP and MLFR provide service options between low-speed T1 and E1 services. In addition to providing additional bandwidth, bundling multiple links can add a level of fault tolerance to your dedicated access service. Because you can implement bundling across multiple interfaces, you can protect users against loss of access when a single interface fails.

MLFR Frame Relay Forum

JUNOS supports FRF.12 fragmentation header formats for both FRF.15 (MLFR) and FRF.16 (MFR).

MLFR Frame Relay Forum 15 (FRF.15) combines multiple permanent virtual circuits (PVCs) into one aggregated virtual circuit (AVC). This process provides fragmentation over multiple PVCs on one end and reassembly of the AVC on the other end. MLFR FRF.15 is supported on the ls-0/0/0 interface.

MLFR FRF.16 is supported on the ls-0/0/0:channel, which carries a single MLFR FRF.16 bundle. MLFR FRF.16 combines multiple links to form one logical link. Packet fragmentation and reassembly occur on each virtual circuit. Each bundle can support multiple virtual circuits.

Note: If you configure a permanent virtual circuit (PVC) between T1, E1, T3, or E3 interfaces in J-series device and another vendor, and the other vendor does not have the same FRF.12 support or supports FRF.12 in a different way, the devices interface might discard a fragmented packet containing FRF.12 headers and count it as a "Policed Discard." Therefore, when you configure a PVC between T1, E1, T3, or E3 interfaces in the devices and another vendor, you should configure multilink bundles on both peers and configure fragmentation thresholds on the multilink bundle.

CRTP

Real-Time Transport Protocol (RTP) can help achieve interoperability among different implementations of network audio and video applications. However, the header can be too large a payload for networks using low-speed lines such as dial-up modems. Compressed Real-Time Transport Protocol (CRTP) can reduce network overhead on a low-speed link. On a J-series device, CRTP can operate on a T1 or E1 interface with PPP encapsulation.

[Contents] [Prev] [Next] [Index] [Report an Error]