Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Physical Interface Properties

 

The physical interfaces on security devices affect the transmission of either link-layer signals or the data across the links. The topics below describes the physical properties that include clocking properties, transmission properties, such as the maximum transmission unit (MTU), and encapsulation methods, such as point-to-point and Frame Relay encapsulation. SRX series devices also support jumbo frames.

Understanding Interface Physical Properties

The physical properties of a network interface are the characteristics associated with the physical link that affect the transmission of either link-layer signals or the data across the links. Physical properties include clocking properties, transmission properties, such as the maximum transmission unit (MTU), and encapsulation methods, such as point-to-point and Frame Relay encapsulation.

The default property values for an interface are usually sufficient to successfully enable a bidirectional link. However, if you configure a set of physical properties on an interface, those same properties must be set on all adjacent interfaces to which a direct connection is made.

Table 1 summarizes some key physical properties of device interfaces.

Table 1: Interface Physical Properties

Physical Property

Description

bert-error-rate

Bit error rate (BER). The error rate specifies the number of bit errors in a particular bit error rate test (BERT) period required to generate a BERT error condition. See Understanding Bit Error Rate Testing.

bert-period

Bit error rate test (BERT) time period over which bit errors are sampled. See Understanding Bit Error Rate Testing.

chap

Challenge Handshake Authentication Protocol (CHAP). Specifying chap enables CHAP authentication on the interface. See Understanding CHAP Authentication on a PPPoE Interface.

clocking

Clock source for the link. Clocking can be provided by the local system (internal) or a remote endpoint on the link (external). By default, all interfaces use the internal clocking mode. If an interface is configured to accept an external clock source, one adjacent interface must be configured to act as a clock source. Under this configuration, the interface operates in a loop timing mode, in which the clocking signal is unique for that individual network segment or loop. See Understanding Interface Clocking.

description

A user-defined text description of the interface, often used to describe the interface's purpose.

disable

Administratively disables the interface.

encapsulation

Type of encapsulation on the interface. Common encapsulation types include PPP, Frame Relay, Cisco HDLC, and PPP over Ethernet (PPPoE). See Understanding Physical Encapsulation on an Interface.

fcs

Frame check sequence (FCS). FCS is an error-detection scheme that appends parity bits to a digital signal and uses decoding algorithms that detect errors in the received digital signal.

mtu

Maximum transmission unit (MTU) size. MTU is the largest size packet or frame, specified in bytes or octets, that can be sent in a packet-based or frame-based network. The TCP uses MTU to determine the maximum size of each packet in any transmission.

You can adjust the MTU values at the physical interfaces by using the following command:

set interface interface-name mtu mtu-value

Sometimes there is a need to reduce the MTU values on interfaces to match the host tap interface MTU otherwise packets are dropped. You can adjust the MTU values by setting the mtu option of the set interfaces [fxp0 | em0 | fab0 | fab1] command to a value between 256 and 9192.

Example:

user@host# set interfaces em0 mtu 1400

The supported range for configuring an MTU packet size is 256 through 9192 bytes. However, all interfaces do not support 9192 bytes. For more information on the supported interfaces, see MTU Default and Maximum Values.

no-keepalives

Disabling of keepalive messages across a physical link. A keepalive message is sent between network devices to indicate that they are still active. Keepalives help determine whether the interface is operating correctly. Except for ATM-over-ADSL interfaces, all interfaces use keepalives by default.

pap

Password Authentication Protocol (PAP). Specifying pap enables PAP authentication on the interface. See Understanding CHAP Authentication on a PPPoE Interface.

payload-scrambler

Scrambling of traffic transmitted out the interface. Payload scrambling randomizes the data payload of transmitted packets. Scrambling eliminates nonvariable bit patterns (strings of all 1s or all 0s) that generate link-layer errors across some physical links.

Understanding Bit Error Rate Testing

In telecommunication transmission, the bit error rate (BER) is the percentage of bits that have errors compared to the total number of bits received in a transmission, usually expressed as 10 to a negative power. For example, a transmission with a BER of 10–6 received 1 errored bit in 1,000,000 bits transmitted. The BER indicates how often a packet or other data unit must be retransmitted because of an error. If the BER is too high, a slower data rate might improve the overall transmission time for a given amount of data if it reduces the BER and thereby lowers the number of resent packets.

A bit error rate test (BERT) is a procedure or device that measures the BER for a given transmission. You can configure a device to act as a BERT device by configuring the interface with a bit error rate and a testing period. When the interface receives a BERT request from a BER tester, it generates a response in a well-known BERT pattern. The initiating device checks the BERT-patterned response to determine the number of bit errors.

Understanding Interface Clocking

Clocking determines how individual routing nodes or entire networks sample transmitted data. As streams of information are received by a device in a network, a clock source specifies when to sample the data. In asynchronous networks, the clock source is derived locally, and synchronous networks use a central, external clock source. Interface clocking indicates whether the device uses asynchronous or synchronous clocking.

Note

Because truly synchronous networks are difficult to design and maintain, most synchronous networks are really plesiochronous networks. In a plesiochronous network, different timing regions are controlled by local clocks that are synchronized (with very narrow constraints). Such networks approach synchronicity and are generally known as synchronous networks.

Most networks are designed to operate as asynchronous networks. Each device generates its own clock signal, or devices use clocks from more than one clock source. The clocks within the network are not synchronized to a single clock source. By default, devices generate their own clock signals to send and receive traffic.

The system clock allows the device to sample (or detect) and transmit data being received and transmitted through its interfaces. Clocking enables the device to detect and transmit the 0s and 1s that make up digital traffic through the interface. Failure to detect the bits within a data flow results in dropped traffic.

Short-term fluctuations in the clock signal are known as clock jitter. Long-term variations in the signal are known as clock wander.

Asynchronous clocking can either derive the clock signal from the data stream or transmit the clocking signal explicitly.

This topic contains the following sections:

Data Stream Clocking

Common in T1 links, data stream clocking occurs when separate clock signals are not transmitted within the network. Instead, devices must extract the clock signal from the data stream. As bits are transmitted across the network, each bit has a time slot of 648 nanoseconds. Within a time slot, pulses are transmitted with alternating voltage peaks and drops. The receiving device uses the period of alternating voltages to determine the clock rate for the data stream.

Explicit Clocking Signal Transmission

Clock signals that are shared by hosts across a data link must be transmitted by one or both endpoints on the link. In a serial connection, for example, one host operates as a clock master and the other operates as a clock slave. The clock master internally generates a clock signal that is transmitted across the data link. The clock slave receives the clock signal and uses its period to determine when to sample data and how to transmit data across the link.

This type of clock signal controls only the connection on which it is active and is not visible to the rest of the network. An explicit clock signal does not control how other devices or even other interfaces on the same device sample or transmit data.

Understanding Frame Check Sequences

All packets or frames within a network can be damaged by crosstalk or interference in the network's physical wires. The frame check sequence (FCS) is an extra field in each transmitted frame that can be analyzed to determine if errors have occurred. The FCS uses cyclic redundancy checks (CRCs), checksums, and two-dimensional parity bits to detect errors in the transmitted frames.

This topic contains the following sections:

Cyclic Redundancy Checks and Checksums

On a link that uses CRCs for frame checking, the data source uses a predefined polynomial algorithm to calculate a CRC number from the data it is transmitting. The result is included in the FCS field of the frame and transmitted with the data. On the receiving end, the destination host performs the same calculation on the data it receives.

If the result of the second calculation matches the contents of the FCS field, the packet was sent and received without bit errors. If the values do not match, an FCS error is generated, the frame is discarded and the originating host is notified of the error.

Checksums function similarly to CRCs, but use a different algorithm.

Two-Dimensional Parity

On a link that uses two-dimensional parity bits for frame checking, the sending and receiving hosts examine each frame in the total packet transmission and create a parity byte that is evaluated to detect transmission errors.

For example, a host can create the parity byte for the following frame sequence by summing up each column (each bit position in the frame) and keeping only the least-significant bit:

If the sum of the bit values in a bit position is even, the parity bit for the position is 0. If the sum is odd, the parity bit is 1. This method is called even parity. Matching parity bytes on the originating and receiving hosts indicate that the packet was received without error.

MTU Default and Maximum Values

The MTU values are by default without any MTU configurations. If the MTU value is set, then the formula IFF MTU (IP MTU) = IFD MTU (Media MTU) – L2 Overhead is applicable. See Table 2 for default MTU values.

Note

For ATM MLPPP irrespective of UIFD MTU, the IP MTU is always 1500 because the IP MTU calculation is based on the LSQ interface. Even if you configure the LSQ family MTU, the IP MTU value cannot exceed 1504.

Table 2 lists MTU values for the SRX Series Services Gateways Physical Interface Modules (PIMs).

Table 2: MTU Values for the SRX Series Services Gateways PIMs

PIM

Default Media MTU (Bytes)

Maximum MTU (Bytes)

Default IP MTU (Bytes)

1-Port Gigabit Ethernet Small Form-Factor Pluggable (SFP) Mini-PIM

1514

9010

1500

1-Port Small Form-Factor Pluggable (SFP) Mini-PIM

1514

1518

1500

DOCSIS Mini-PIM

1504

1504

1500

Serial Mini-PIM

1504

2000

1500

T1/E1 Mini-PIM

1504

2000

1500

Dual CT1/E1 GPIM

1504

9000

1500

Quad CT1/E1 GPIM

1504

9000

1500

2-Port 10- Gigabit Ethernet XPIM

1514

9192

1500

16-Port Gigabit Ethernet XPIM

1514

9192

1500

24-Port Gigabit Ethernet XPIM

1514

9192

1500

 

ADSL2+ Mini-PIM (Encapsulation)

atm-snap

1512

1512

1504

atm-vcmux

1512

1512

1512

atm-nlpid

1512

1512

1508

atm-cisco-nlpid

1512

1512

1510

ether-over-atm-llc

1512

1512

1488

atm-ppp-llc

1512

1512

1506

atm-ppp-vcmux

1512

1512

1510

atm-mlppp-llc

1512

1512

1500

ppp-over-ether-over-atm-llc

1512

1512

1480

 

VDSL- Mini-PIM AT mode (Encapsulation)

atm-snap

1514

1514

1506

atm-vcmux

1514

1514

1514

atm-nlpid

1514

1514

1510

atm-cisco-nlpid

1514

1514

1512

ether-over-atm-llc

1514

1524

1490

atm-ppp-llc

1514

1514

1508

atm-ppp-vcmux

1514

1514

1512

atm-mlppp-llc

1514

1514

1500

ppp-over-ether-over-atm-llc

1514

1514

1482

 

VDSL- Mini-PIM PT mode

1514

1514

1500

 

G.SHDSL Mini-PIM AT mode (Encapsulation)

atm-snap

4482

4482

4470

atm-vcmux

4482

4482

4470

atm-nlpid

4482

4482

4470

atm-cisco-nlpid

4482

4482

4470

ether-over-atm-llc

4482

4482

1500

atm-ppp-llc

4482

4482

4476

atm-ppp-vcmux

4482

4482

4480

atm-mlppp-llc

4482

4482

1500

ppp-over-ether-over-atm-llc

4482

4482

1492

 

G.SHDSL Mini-PIM PT mode

1514

1514

1500

Understanding Jumbo Frames Support for Ethernet Interfaces

SRX Series devices support jumbo frames up to 9192 bytes.

Jumbo frames are Ethernet frames with more than 1500 bytes of payload (maximum transmission unit [MTU]). Jumbo frames can carry up to 9000 bytes of payload.

You configure jumbo frames at the physical interface by using the following command:

set interface interface-name mtu mtu-value

Example:

The supported range for configuring an MTU packet size is 256 through 9192 bytes. However, all interfaces do not support 9192 bytes. For more information on the supported interfaces, see MTU Default and Maximum Values.