Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Configuring ADSL Interfaces

 

Asymmetric digital subscriber line (ADSL) technology helps in transporting high-bandwidth data using the twisted-pair telephone lines. The topics below discuss the ADSL interfaces, configuration details of ADSL and SHDSL interfaces, and configuration of different clients on ADSL interfaces.

ADSL Interface Overview

Selected Juniper Networks security devices support DSL features including ATM-over-ADSL and ATM-over-SHDSL interfaces.

Note

Payload loopback functionality is not supported on ATM-over-SHDSL interfaces.

Asymmetric digital subscriber line (ADSL) technology is part of the xDSL family of modem technologies that use existing twisted-pair telephone lines to transport high-bandwidth data. ADSL lines connect service provider networks and customer sites over the "last mile" of the network—the loop between the service provider and the customer site.

ADSL transmission is asymmetric because the downstream bandwidth is typically greater than the upstream bandwidth. The typical bandwidths of ADSL, ADSL2, and ADSL2+ circuits are defined in Table 1.

Table 1: Standard Bandwidths of DSL Operating Modes

Operating Modes

Upstream

Downstream

ADSL

800 Kbps—1Mbps

8 Mbps

ADSL2

1—1.5 Mbps

12—14 Mbps

ADSL2+

1—1.5 Mbps

24—25 Mbps

ADSL2+ Annex M

2.5—3 Mbps

25 Mbps

ADSL, ADSL2, and ADSL2+ support the following standards:

  • For Annex A:

    • ITU G.992.1 (ADSL)

  • For Annex A only:

    • ANSI T1.413 Issue II

    • ITU G.992.3 (ADSL2)

    • ITU G.992.5 (ADSL2+)

  • For Annex M:

    • ITU G.992.3 (ADSL2)

    • ITU G.992.5 (ADSL2+)

  • For Annex B:

    • ITU G.992.1 (ADSL)

    • ITU G.992.3 (ADSL2)

    • ITU G.992.5 (ADSL2+)

  • For Annex B only

    • ETSI TS 101 388 V1.3

The ADSL Mini-PIM facilitates a maximum of 10 virtual circuits on supported security devices.

Supported security devices with Mini-PIMs can use PPP over Ethernet over ATM (PPPoEoA) and PPP over ATM (PPPoA) to connect through ADSL lines only.

ADSL Systems

ADSL links run across twisted-pair telephone wires. When ADSL modems are connected to each end of a telephone wire, a dual-purpose ADSL circuit can be created. Once established, the circuit can transmit lower-frequency voice traffic and higher-frequency data traffic.

To accommodate both types of traffic, ADSL modems are connected to plain old telephone service (POTS) splitters that filter out the lower-bandwidth voice traffic and the higher-bandwidth data traffic. The voice traffic can be directed as normal telephone voice traffic. The data traffic is directed to the ADSL modem, which is typically connected to the data network.

ADSL2 and ADSL2+

The ADSL2 and ADSL2+ standards were adopted by the ITU in July 2002. ADSL2 improves the data rate and reach performance, diagnostics, standby mode, and interoperability of ADSL modems.

ADSL2+ doubles the possible downstream data bandwidth, enabling rates of 20 Mbps on telephone lines shorter than 5000 feet (1.5 km).

ADSL2 uses seamless rate adaptation (SRA) to change the data rate of a connection during operation with no interruptions or bit errors. The ADSL2 transceiver detects changes in channel conditions—for example, the failure of another transceiver in a multicarrier link—and sends a message to the transmitter to initiate a data rate change. The message includes data transmission parameters such as the number of bits modulated and the power on each channel. When the transmitter receives the information, it transitions to the new transmission rate.

ATM CoS Support

Certain class-of-service (CoS) components for Asynchronous Transmission Mode (ATM) are provided to control data transfer, especially for time-sensitive voice packets. The ADSL Mini-PIM on the SRX210 device provides extended ATM CoS functionality to provide cells across the network. You can define bandwidth utilization, which consists of either a constant rate or a peak cell rate, with sustained cell rate and burst tolerance. By default, unspecified bit rate (UBR) is used because the bandwidth utilization is unlimited.

The following ATM traffic shaping features are supported:

Constant bit rate (CBR)

CBR is the service category for traffic with rigorous timing requirements like voice and certain types of video. CBR traffic needs a constant cell transmission rate throughout the duration of the connection.

Variable bit rate non-real - time (VBR-NRT)

VBR-NRT is intended for sources such as data transfer, which do not have strict time or delay requirements. VBR-NRT is suitable for packet data transfers.

Unspecified bit rate (UBR)

UBR is ATM’s best-effort service, which does not provide any CoS guarantees. This is suitable for noncritical applications that can tolerate or quickly adjust to loss of cells.

The ability of a network to guarantee class of service depends on the way in which the source generates cells and also on the availability of network resources. The connection contract between the user and the network thus contains information about the way in which traffic is generated by the source.

A set of traffic descriptors is specified for this purpose. The network provides the class of service for the cells that do not violate these specifications. The following are the traffic descriptors specified for an ATM network:

  • Peak cell rate (PCR)—Top rate at which traffic can burst.

  • Sustained cell rate (SCR)—Normal traffic rate averaged over time.

  • Maximum burst size (MBS)—The maximum burst size that can be sent at the peak rate.

  • Cell delay variation tolerance (CDVT)—Allows the user to delay the traffic for a particular time duration in microseconds to follow a rhythmic pattern.

For traffic that does not require the ability to periodically burst to a higher rate, you can specify a CBR. You can configure VBR-NRT for ATM interfaces, which supports VBR data traffic with average and peak traffic parameters. VBR-NRT is scheduled with a lower priority and with a larger sustained cell rate (SCR) limit, allowing it to recover bandwidth if it falls behind.

On SRX300, SRX320, SRX340, SRX345, SRX380, and SRX550HM devices, the ATM interface takes more than 5 minutes to come up when CPE is configured in ANSI-DMT mode and CO is configured in automode. This occurs only with ALU 7300 DSLAM, due to limitation in current firmware version running on the ADSL Mini-PIM.

ADSL and SHDSL Interfaces Configuration Overview

An SRX Series device with an ADSL interface supports LFI through an MLPPP.

Note

Currently, Junos OS supports bundling of only one xDSL link under bundle interface.

To support MLPPP encapsulation and the family mlppp on the ADSL interface on an SRX Series device, you enable an existing Junos OS CLI.

To establish an ADSL link between network devices, you must use some intermediate connections. First, use an RJ-11 cable to connect the CPE (for example, an SRX Series device) to a DSLAM patch panel to form an ADSL link. Then use OC3 or DS3 to connect the DSLAM to M Series or E Series devices to form an ATM backbone.

You can configure the following properties for the ADSL and SHDSL interfaces:

  • Physical properties

  • Logical properties

You can configure the following physical properties for the interface:

  • ATM virtual path identifier (VPI) options for the interface—for example, at-2/0/0:

    • ATM VPI—A number from 0 through 255—for example, 25.

    • Operation, Maintenance, and Administration (OAM) F5 loopback cell thresholds (“liveness”) on ATM virtual circuits. The range is from 1 through 255, and the default is 5 cells.

      • Down count—Number of consecutive OAM loopback cells an ATM virtual circuit must lose to be identified as unavailable—for example, 200.

      • Up count—Number of consecutive OAM loopback cells an ATM virtual interface must receive to be identified as operational—for example, 200.

    • OAM period—Interval, in seconds, at which OAM cells are transmitted on ATM virtual circuits—for example, 100. The range is from 1 through 900 seconds.

    • Configure CBR for the interface—for example, at-1/0/0.

      • CBR—Range from 33,000 through 1,199,920

      • CDVT—Range from 1 through 9,999

    • Configure VBR for the interface—for example, at-1/0/0.

      • MBS—Range from 33,000 through 1,199,920

      • CDVT—Range from 1 through 9,999

      • PCR—Range from 33,000 through 1,199,920

      • SCR—Range from 33,000 through 1,199,920

  • Type of DSL operating mode for the ATM-over-ADSL and ATM-over-SHDSL interfaces—for example, auto:

    Annex A (used in North American network implementations) and Annex B (used in European network implementations) support the following operating modes:

    • auto—Configures the ADSL interface to autonegotiate settings with the DSLAM located at the central office. For Annex A, the ADSL interface trains in either ANSI T1.413 Issue II mode or ITU G.992.1 mode. For Annex B, the ADSL interface trains in ITU G.992.1 mode. For the SHDSL interface, the line rate is available only in two-wire mode and is the default value.

    • itu-dmt—Configures the ADSL interface to train in ITU G.992.1 mode.

    • 192 Kbps or higher—Speed of transmission of data on the SHDSL connection. For the SHDSL interface, in the four-wire mode, the default line rate is 4,608 Kbps.

    Annex A supports the following operating modes:

    • adsl2plus—Configures the ADSL interface to train in ITU G.992.5 mode. You can configure this mode only when it is supported on the DSLAM.

    • itu-dmt-bis—Configures the ADSL interface to train in ITU G.992.3 mode. You can configure this mode only when it is supported on the DSLAM.

    • ansi-dmt—Configures the ADSL interface to train in the ANSI T1.413 Issue II mode.

    Annex B supports the following operating modes:

    • etsi—Configures the ADSL line to train in the ETSI TS 101 388 V1.3.1 mode.

    • itu-annexb-ur2—Configures the ADSL line to train in the G.992.1 Deutsche Telekom UR-2 mode.

    • itu-annexb-non-ur2—Configures the ADSL line to train in the G.992.1 Non-UR-2 mode.

  • Loopback option for testing the SHDSL connection integrity–for example, local loopback.

    The following values are available:

    • local—Used for testing the SHDSL equipment with local network devices.

    • payload—Used to command the remote configuration to send back the received payload.

    • remote—Used to test SHDSL with a remote network configuration.

  • Signal-to-noise ratio (SNR) margin—for example, 5 dB for either or both of the following thresholds:

    • current—Line trains at higher than current noise margin plus SNR threshold. The range is from 0 to 10 dB. The default value is 0.

    • snext—Line trains at higher than self-near-end crosstalk (SNEXT) threshold. The default value is disabled.

    Setting the SNR creates a more stable SHDSL connection by making the line train at a SNR margin higher than the threshold. If any external noise below the threshold is applied to the line, the line remains stable. You can also disable the SNR margin thresholds.

  • Encapsulation type—for example, ethernet-over-atm:

    • atm-pvc—ATM permanent virtual circuits is the default encapsulation for ATM-over-ADSL and ATM-over-SHDSL interfaces.

      For PPP over ATM (PPPoA)-over-ADSL and over-SHDSL interfaces, use this type of encapsulation.

    • ethernet-over-atm—Ethernet over ATM encapsulation.

      For PPP over Ethernet (PPPoE) over ATM-over-ADSL and ATM-over-SHDSLinterfaces that carry IPv4 traffic, use this type of encapsulation.

You can configure the following logical properties for the interface:

  • Logical interface. Set a value from 0 through 16,385—for example, 3. Add other values if required by your network.

  • Configure encapsulation for the ATM-for-ADSL or ATM-for-SHDSL logical unit—for example, atm-nlpid.

    The following encapsulations are supported on the ATM-over-ADSL and ATM-over-SHDSL interfaces that use inet (IP) protocols only:

    • atm-vc-mux—Use ATM virtual circuit multiplex encapsulation.

    • atm-nlpid—Use ATM network layer protocol identifier (NLPID) encapsulation.

    • atm-cisco-nlpid—Use Cisco NLPID encapsulation.

    • ether-over-atm-llc—For interfaces that carry IPv4 traffic, use Ethernet over LLC encapsulation. You cannot configure multipoint interfaces if you use this type of encapsulation.

    The following encapsulations are supported on the ATM-over-ADSL or ATM-over-SHDSL for PPP-over-ATM (PPPoA) interfaces only.

    • atm-ppp-llc—AAL5 logical link control (LLC) encapsulation.

    • atm-ppp-vc-mux—Use AAL5 multiplex encapsulation.

    Other encapsulation types supported on the ATM-over-ADSL and ATM-over-SHDSL interfaces are:

    • ppp-over-ether-over-atm-llc—Use PPP over Ethernet over ATM LLC encapsulation. When you use this encapsulation type, you cannot configure the interface address. Instead you configure the interface address on the PPP interface.

    • atm-snap—Use ATM subnetwork attachment point (SNAP) encapsulation.

  • OAM options for the ATM virtual circuits:

    • OAM F5 loopback cell thresholds (“liveness”) on ATM virtual circuits. The range is from 1 through 255, and the default is 5 cells.

      • Down count—Number of consecutive OAM loopback cells an ATM virtual circuit must lose to be identified as unavailable—for example, 200.

      • Up count—Number of consecutive OAM loopback cells an ATM virtual interface must receive to be identified as operational—for example, 200.

    • OAM period—Interval, in seconds, at which OAM cells are transmitted on ATM virtual circuits—for example, 100. The range is from 1 through 900 seconds.

  • Family protocol type—for example, inet. Commands vary depending on the protocol type.

  • ATM VCI options for the interface:

    • ATM VCI type—vci

    • ATM VCI value—A number from 0 through 4,089—for example, 35—with VCIs 0 through 31 reserved.

Example: Configuring the DHCP Client on ADSL Interface

This example shows how to configure DHCP client on ADSL or SHDSL or VDSL2 interface (when VDSL2 interface is configured to operate in ADSL fallback mode).

Requirements

Before you begin:

Overview

In this example, you configure the ATM interface as at-1/0/0. You then set the logical interface to unit 0 and specify the family protocol type as inet. Finally, you configure the DHCP client.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following command, paste it into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the command into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

To configure DHCP client on ADSL interfaces:

  1. Set the encapsulation mode.
  2. Configure the ATM VPI option.
  3. Set operating mode.
  4. Set the logical interface.
  5. Set the encapsulation mode for logical interface.
  6. Set the ATM VCI option.
  7. Specify the family protocol type.
  8. Configure the DHCP client.
  9. Set the DHCP client identifier as a ASCII or hexadecimal value (optional):

    Use hexadecimal if the client identifier is a MAC address—for example, 00:0a:12:00:12:12.

  10. Set the DHCP lease time in seconds—for example, 86400 (24 hours). The range is 60 through 2147483647 seconds (optional).
  11. Define the number of attempts allowed to retransmit a DHCP packet (optional)—for example, 6

    The range is 0 through 6. The default is 4 times.

  12. Define the interval, in seconds, allowed between retransmission attempts (optional)—for example, 5.

    The range is 4 through 64. The default is 4 seconds.

  13. Set the IPv4 address of the preferred DHCP server (optional)—for example, 10.1.1.1.
  14. Set the vendor class ID for the DHCP client (optional)—for example, ether.

Results

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

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying the DHCP Configuration

Purpose

Verify that the DHCP options are configured properly.

Action

Verify the DHCP configuration by using the run show system services dhcp client command.

user@host# run show system services dhcp client

Verify Interface Status

Purpose

Verify the interface status and check traffic statistics.

Action

Verify interface status by using the show interface terse command and test end-to-end data path connectivity by sending the ping packets to the remote end IP address.

user@host# run show interfaces at-1/0/0 terse
user@host# run ping 10.40.1.1 count 100 rapid

See also

Example: Configuring the IPv6 Address on an ADSL Interface

This example shows how to configure the IPv6 address on an ADSL interface.

Requirements

Before you begin, configure network interfaces as necessary. See Understanding Ethernet Interfaces.

Overview

In this example, you specify the following configuration parameters:

  • Encapsulation type: Ethernet over ATM on DSL logical interface

  • ATM virtual path identifier (VPI): 2

  • Encapsulation type: Ethernet over ATM on DSL logical interface

  • Encapsulation type for the ATM-for-ADSL logical unit: Ethernet over ATM LLC

  • ATM virtual channel (VCI): 2.118

  • IPv6 address and prefix: 13:13::1/64

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

To configure the IPv6 address on an ADSL interface:

  1. Configure the encapsulation type.
  2. Specify the annex type.
  3. Configure the encapsulation for the logical unit.
  4. Configure the VCI value.
  5. Configure family protocol type and assign an IPv6 address.

Results

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

If you done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying ADSL Interface Properties

Purpose

Verify that the ADSL interface properties are configured properly.

Action

From operational mode, enter the show ipv6 neighbors command. The output shows a summary of interface information.

user@host> show ipv6 neighbors

Meaning

The IPv6 Address field displays the configured IPv6 address on the interface.

Example: Configuring ATM-over-ADSL Network Interfaces

This example shows how to configure ATM-over-ADSL network interfaces for the devices.

Requirements

Before you begin:

Overview

This example shows how to use devices with ADSL Annex A or Annex B PIMs to send network traffic through a point-to-point connection to a DSLAM. Within the example, you set the DSL operating mode type to auto so that the ADSL interface will autonegotiate settings with the DSLAM.

The example shows how to create an ATM interface called at-2/0/0. The values for the interface’s physical properties are kept relatively low—the ATM VPI is set to 25; both the OAM down count and up count are set to 200 cells; the OAM period is set to 100 seconds.

The example also shows how to set traffic shaping values on the ATM interface to support CoS. CBR is enabled in order to stabilize the cell transmission rate throughout the duration of the connection. Additionally, the VBR peak is set to 33,000 for data packet transfers.

Within the example, you set the encapsulation mode to ethernet-over-atm to support PPP over Ethernet IPv4 traffic. You also configure a logical interface (unit 3). The logical interface uses ATM NLPID encapsulation. As with the physical interface, the OAM down count and up count are set to 200 cells on the logical interface and the OAM period is set to 100 seconds. The family protocol is set to inet and the VCI is set to 35.

Note

On SRX300, SRX320, SRX340, SRX345, SRX380, and SRX550HM devices, the ATM interface takes more than 5 minutes to come up when CPE is configured in ANSI-DMT mode and CO is configured in automode. This occurs only with ALU 7300 DSLAM, due to limitation in current firmware version running on the ADSL Mini-PIM.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following command, paste it into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the command into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode.

To configure ATM-over-ADSL network interfaces for the devices:

  1. Create an ATM interface.
  2. Configure the physical properties for the ATM interface.
  3. Specify the CBR value and VBR value for the Ethernet interface.
  4. Set the DSL operating mode type.
  5. Configure the encapsulation type.
  6. Configure the encapsulation for the logical unit.
  7. Configure the OAM liveness values for an ATM virtual circuit.
  8. Specify the OAM period.
  9. Set the family protocol type.
  10. Configure the VCI value.

Results

From configuration mode, confirm your configuration by entering the show interfaces at-1/0/0 and show interfaces at-2/0/0 commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying the ADSL Interface Properties

Purpose

Verify that the interface properties are correct.

Action

From operational mode, enter the show interfaces at-1/0/0 extensive command.

user@host> show interfaces at-1/0/0 extensive

The output shows a summary of interface information. Verify the following information:

  • The physical interface is enabled. If the interface is shown as disabled, do either of the following:

    • In the CLI, delete the disable statement at the [edit interfaces interface-name] level of the configuration hierarchy.

    • In J-Web, clear the Disable check box on the Interfaces page (Interfaces>interface-name).

  • The physical link is up. A link state of down indicates a problem with the interface module, interface port, or physical connection (link-layer errors).

  • The last flapped time is an expected value. It indicates the last time the physical interface became unavailable and then available again. Unexpected flapping indicates likely link-layer errors.

  • The traffic statistics reflect expected input and output rates. Verify that the number of inbound and outbound bytes and packets matches expected throughput for the physical interface. To clear the statistics and see only new changes, use the clear interfaces statistics interface-name command.

  • No ADSL alarms and defects appear that can render the interface unable to pass packets. When a defect persists for a certain amount of time, it is promoted to an alarm. The following are ADSL-specific alarms:

    • LOCDI—Loss of cell delineation for interleaved channel.

    • LOCDNI—Loss of cell delineation for noninterleaved channel.

    • LOF—Loss of frame.

    • LOM—Loss of multiframe.

    • LOP—Loss of power.

    • LOS—Loss of signal.

Examine the operational statistics for an ADSL interface. Statistics in the ATU-R (ADSL transceiver unit–remote) column are for the near end. Statistics in the ATU-C (ADSL transceiver unit–central office) column are for the far end.

  • Attenuation (dB)—Reduction in signal strength .

  • Capacity used (%)—Amount of ADSL usage.

  • Noise margin (dB)—Maximum extraneous signal allowed without causing the output to deviate from an acceptable level.

  • Output power (dBm)—Amount of power used by the ADSL interface.

  • Bit rate (kbps)—Data transfer speed on the ADSL interface.

Verifying a PPPoA Configuration for an ATM-over-ADSL Interface

Purpose

Verify that the PPPoA configuration for an ATM-over-ADSL interface is correct.

Action

From operational mode, enter the show interfaces at-1/0/0 and the show access commands.

Example: Configuring MLPPP-over-ADSL Interfaces

This example shows how to configure MLPPP on an ADSL interface.

Requirements

Before you begin, configure network interfaces as necessary. See Understanding Ethernet Interfaces.

Overview

In this example, you set the encapsulation as atm-mlppp-llc for the interface at-5/0/0. You then configure the family MLPPP bundle as lsq-0/0/0.1.

Figure 1 shows a typical example of MLPPP-over-ADSL end-to-end connectivity.

Figure 1: MLPPP-over-ADSL Interface
 MLPPP-over-ADSL Interface

Configuration

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode .

To configure MLPPP on an ADSL interface:

  1. Configure an interface.
  2. Set the MLPPP encapsulation.
  3. Specify the family MLPPP.
  4. If you are done configuring the device, commit the configuration.

Verification

To verify the configuration is working properly, enter the show interfaces at-5/0/0 command.

Example: Configuring CHAP on DSL Interfaces

This example shows how to configure CHAP on either the ATM-over-ADSL or the ATM-over-SHDSL interface.

Requirements

Before you begin, configure network interfaces as necessary. See Understanding Ethernet Interfaces.

Overview

In this example, you specify the CHAP access profile and create an interface called at-3/0/0. You configure CHAP on either the ATM-over-ADSL or the ATM-over-SHDSL interface and specify a unique profile name called A-ppp-client containing a client list and access parameters. You then specify a unique hostname called A-at-3/0/0.0 to be used in CHAP. Finally, you set the passive option to handle incoming CHAP packets.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following command, paste it into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the command into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode.

To configure CHAP on either the ATM-over-ADSL or the ATM-over-SHDSL interface:

  1. Define a CHAP access profile.
  2. Create an interface.
  3. Configure CHAP and specify a unique profile name.
  4. Specify a unique hostname.
  5. Set the option to handle incoming CHAP packets only.

Results

From configuration mode, confirm your configuration by entering the show access profile A-ppp-client and show interfaces at-3/0/0 commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying ADSL Interface Properties

Purpose

Verify that the ADSL interface properties are enabled.

Action

From operational mode, enter the show interfaces at-3/0/0 extensive command.

user@host> show interfaces at-3/0/0 extensive

The output shows a summary of interface information. Verify the following information:

  • The physical interface is Enabled. If the interface is shown as Disabled, do either of the following:

    • In the CLI configuration editor, delete the disable statement at the [edit interfaces interface-name] level of the configuration hierarchy.

    • In the J-Web configuration editor, clear the Disable check box on the Interfaces page (Interfaces>interface-name).

  • The physical link is up. A link state of dDown indicates a problem with the interface module, interface port, or physical connection (link-layer errors).

  • The last flapped time is an expected value. It indicates the last time the physical interface became unavailable and then available again. Unexpected flapping indicates likely link-layer errors.

  • The traffic statistics reflect expected input and output rates. Verify that the number of inbound and outbound bytes and packets matches expected throughput for the physical interface. To clear the statistics and see only new changes, use the clear interfaces statistics interface-name command.

  • No ADSL alarms and defects appear that can render the interface unable to pass packets. When a defect persists for a certain amount of time, it is promoted to an alarm. The following are ADSL-specific alarms:

    • LOCDI—Loss of cell delineation for interleaved channel

    • LOCDNI—Loss of cell delineation for noninterleaved channel

    • LOF—Loss of frame

    • LOM—Loss of multiframe

    • LOP—Loss of power

    • LOS—Loss of signal

Examine the operational statistics for an ADSL interface. Statistics in the ATU-R (ADSL transceiver unit–remote) column are for the near end. Statistics in the ATU-C (ADSL transceiver unit–central office) column are for the far end.

  • Attenuation (dB)—Reduction in signal strength measured in decibels.

  • Capacity used (%)—Amount of ADSL usage in %.

  • Noise margin (dB)—Maximum extraneous signal allowed without causing the output to deviate from an acceptable level.

  • Output power (dBm)—Amount of power used by the ADSL interface.

  • Bit rate (kbps)—Data transfer speed on the ADSL interface.

Verifying a PPPoA Configuration for an ATM-over-ADSL Interface

Purpose

Verify that the PPPoA configuration for an ATM-over-ADSL interface is correct.

Action

From operational mode, enter the show interfaces at-3/0/0 and the show access commands.

Verifying an ATM-over-SHDSL Configuration

Purpose

Verify that the interface properties are correct.

Action

From operational mode, enter the show interfaces at-3/0/0 extensive command.

user@host> show interfaces at-3/0/0 extensive

The output shows a summary of interface information. Verify the following information:

  • The physical interface is enabled. If the interface is shown as disabled, do either of the following:

    • In the CLI configuration editor, delete the disable statement at the [edit interfaces interface-name] level of the configuration hierarchy.

    • In the J-Web configuration editor, clear the Disable check box on the Interfaces page (Interfaces>interface-name).

  • The physical link is up. A link state of down indicates a problem with the interface module, interface port, or physical connection (link-layer errors).

  • The last flapped time is an expected value. It indicates the last time the physical interface became unavailable and then available again. Unexpected flapping indicates likely link-layer errors.

  • The traffic statistics reflect expected input and output rates. Verify that the number of inbound and outbound bytes and packets matches expected throughput for the physical interface. To clear the statistics and see only new changes, use the clear interfaces statistics interface-name command.

  • No SHDSL alarms and defects appear that can render the interface unable to pass packets. When a defect persists for a certain amount of time, it is promoted to an alarm.

    • LOS—Loss of signal. No signal was detected on the line.

    • LOSW—Loss of sync word. A message ID was sent.

    • Power status—A power failure has occurred.

    • LOSD—Loss of signal was detected at the remote application interface.

    • ES—Errored seconds. One or more cyclic redundancy check (CRC) anomalies were detected.

    • SES—Severely errored seconds. At least 50 CRC anomalies were detected.

    • UAS—Unavailable seconds. An interval has occurred during which one or more LOSW defects were detected.

Examine the SHDSL interface status:

  • Line termination—SHDSL transceiver unit–remote (STU–R). (Only customer premises equipment is supported.)

  • Annex—Either Annex A or Annex B. Annex A is supported in North America, and Annex B is supported in Europe.

  • Line mode—SHDSL mode configured on the G.SHDSL interface pair, either two-wire or four-wire.

  • Modem Status—Data. Sending or receiving data.

  • Last fail code—Code for the last interface failure.

  • Framer mode—Framer mode of the underlying interface: ATM.

  • Dying gasp—Ability of a device that has lost power to send a message informing the attached DSL access multiplexer (DSLAM) that it is about to go offline.

  • Chipset version—Version number of the chipset on the interface

  • Firmware version—Version number of the firmware on the interface.

Examine the operational statistics for a SHDSL interface.

  • Loop attenuation (dB)—Reduction in signal strength measured in decibels.

  • Transmit power (dB)—Amount of SHDSL usage in %.

  • Receiver gain (dB)—Maximum extraneous signal allowed without causing the output to deviate from an acceptable level.

  • SNR sampling (dB)—Signal-to-noise ratio at a receiver point in decibels.

  • Bit rate (kbps)—Data transfer speed on the SHDSL interface.

  • CRC errors—Number of cyclic redundancy check errors.

  • SEGA errors—Number of segment anomaly errors. A regenerator operating on a segment received corrupted data.

  • LOSW errors—Number of loss of signal defect errors. Three or more consecutively received frames contained one or more errors in the framing bits.

  • Received cells—Number of cells received through the interface.

  • Transmitted cells—Number of cells sent through the interface.

  • HEC errors—Number of header error checksum errors.

  • Cell drop—Number of dropped cells on the interface.

Example: Configuring ATM-over-SHDSL Network Interfaces

This example shows how to configure ATM-over-SHDSL network interfaces.

Requirements

Before you begin:

Overview

In this example, you set the ATM-over-SHDSL mode on the G.SHDSL interface, if required. You create an interface called at-2/0/0 and configure the physical properties for the interface. You configure the encapsulation type and annex type. You specify the SHDSL line rate for the ATM-over-SHDSL interface and the loopback address for testing the SHDSL connection integrity. Then you configure the SNR margin, set the logical interface, and configure the encapsulation for the ATM-over-SHDSL logical unit.

Additionally, you configure the OAM liveness values for an ATM virtual circuit and set the OAM period, Finally, you add the family protocol type inet and configure the VCI value.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following command, paste it into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the command into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure ATM-over-SHDSL network interfaces for the device:

  1. Set the ATM-over-SHDSL mode on the G.SHDSL interface.
  2. Create an interface.
  3. Configure the physical properties for the interface.
  4. Configure the encapsulation type.
  5. Set the annex type.
  6. Configure the SHDSL line rate.
  7. Configure the loopback option for testing the SHDSL connection integrity.
  8. Configure the signal-to-noise ration margin.
  9. Configure the logical interface.
  10. Configure the encapsulation for the logical unit.
  11. Configure the OAM liveness values for an ATM virtual circuit
  12. Configure the OAM period.
  13. Add the Family protocol type.
  14. Configure the VCI value.

Results

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

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying an ATM-over-SHDSL Configuration

Purpose

Verify that the interface properties are correct.

Action

From operational mode, enter the show interfaces at-2/0/0 extensive command.

user@host> show interfaces at-2/0/0 extensive

The output shows a summary of interface information. Verify the following information:

  • The physical interface is enabled. If the interface is shown as disabled, do either of the following:

    • In the CLI configuration editor, delete the disable statement at the [edit interfacesinterface-name] level of the configuration hierarchy.

    • In the J-Web configuration editor, clear the Disable check box on the Interfaces page (Interfaces>interface-name).

  • The physical link is up. A link state of down indicates a problem with the interface module, interface port, or physical connection (link-layer errors).

  • The last flapped time is an expected value. The last flapped time indicates the last time the physical interface became unavailable and then available again. Unexpected flapping indicates likely link-layer errors.

  • The traffic statistics reflect expected input and output rates. Verify that the number of inbound and outbound bytes and packets matches expected throughput for the physical interface. To clear the statistics and see only new changes, use the clear interfaces statistics interface-name command.

  • No SHDSL alarms and defects appear that can render the interface unable to pass packets. When a defect persists for a certain amount of time, it is promoted to an alarm.

    • LOS—Loss of signal. No signal was detected on the line.

    • LOSW—Loss of sync word. A message ID was sent.

    • Power status—A power failure has occurred.

    • LOSD—Loss of signal was detected at the remote application interface.

    • ES—Errored seconds. One or more cyclic redundancy check (CRC) anomalies were detected.

    • SES—Severely errored seconds. At least 50 CRC anomalies were detected.

    • UAS—Unavailable seconds. An interval has occurred during which one or more LOSW defects were detected.

Examine the SHDSL interface status:

  • Line termination—SHDSL transceiver unit–remote (STU–R). (Only customer premises equipment is supported.)

  • Annex—Either Annex A or Annex B. Annex A is supported in North America, and Annex B is supported in Europe.

  • Line mode—SHDSL mode configured on the G.SHDSL interface pair, either two-wire or four-wire.

  • Modem status—Data. Sending or receiving data.

  • Last fail code—Code for the last interface failure.

  • Framer mode —ATM Framer mode of the underlying interface.

  • Chipset version—Version number of the chipset on the interface

  • Firmware version—Version number of the firmware on the interface.

Examine the operational statistics for a SHDSL interface.

  • Loop attenuation (dB)—Reduction in signal strength measured in decibels.

  • Transmit power (dB)—Amount of SHDSL usage in %.

  • Receiver gain (dB)—Maximum extraneous signal allowed without causing the output to deviate from an acceptable level.

  • SNR sampling (dB)—Signal-to-noise ratio at a receiver point in decibels.

  • Bit rate (kbps)—Data transfer speed on the SHDSL interface.

  • CRC errors—Number of cyclic redundancy check errors.

  • SEGA errors—Number of segment anomaly errors. A regenerator operating on a segment received corrupted data.

  • LOSW errors—Number of loss of signal defect errors. Three or more consecutively received frames contained one or more errors in the framing bits.

  • Received cells—Number of cells received through the interface.

  • Transmitted cells—Number of cells sent through the interface.

  • HEC errors—Number of header error checksum errors.

  • Cell drop—Number of dropped cells on the interface.