ATM Interfaces

The configuration of ATM interfaces is similar to that of Frame Relay because they both support multipoint operation through the use of virtual circuit (VC)–based multiplexing. ATM technology can be very complex, especially if the device supports switched VCs, multiple ATM Adaptation Layer (AAL) types, voice/date integration, and traffic shaping. The good news is that M-series routers currently support only Permanent Virtual Circuit (PVC) modes of ATM operation, so there is no need to deal with ATM forum/Q2931 call establishment signaling. Currently, there is support only for AAL5 Segmentation and Reassembly (SAR) functionality, which is relatively straightforward when compared to other AAL options defined by ATM technology.

Note 

Juniper Networks routers can support any AAL type when the interface is configured for cell relay mode. A discussion of this capability is beyond the scope of this book.

ATM interfaces on M-series routers support point-to-point and multipoint connection types; traffic shaping; Operations, Administration, and Management (OAM) keepalive; and the ATM Forum’s Integrated Local Management Interface (ILMI) for IP address and network interface registration. The following ATM configuration and verification examples are based on the topology shown in Figure 2.4. Based on the back-to-back nature of this initial ATM topology, the operator must be sure that the same VPI/VCI values are provisioned on both routers as in the case of back-to-back Frame Relay connection. Unlike the Frame Relay protocol, with ATM the use of the ILMI and link keepalives based on OAM cell exchanges are not affected by the absence of an ATM switch that normally functions as the User-to-Network Interface (UNI) DCE.

Figure 2.4: ATM interface topology

Physical Properties for ATM Interfaces

When implemented on a fiber optic–based SONET interface, the physical properties for an ATM interface are virtually identical to those detailed in the “Physical Properties for POS Interfaces” section earlier in this chapter. However, configuration at the physical-device level can include the following ATM-specific options:

• Support for the ILMI protocol

• Declaration of the maximum number of virtual circuits per virtual path (VP)

M-series routers also offer support for T3/E3-based ATM interfaces which, being copper- based, offer a different set of physical configuration options, some of which are listed next:

• Cell encapsulation mode (PLCP/Direct)

• CSU compatibility mode

• T3 C-bit parity

• Frame checksum (16- or 32-bit)

• Payload scrambling

• Loopback, line build, out, and BERT testing properties

The default setting for cell encapsulation is to use the Physical Layer Convergence Protocol (PLCP). Direct cell mapping is also supported, and is in fact required when the G.832 E3 line coding option has been selected. For proper operation, both ends of the T3/E3 ATM link must use the same cell-mapping approach.

This ATM interface configuration example will use the default physical device settings with the following ATM-specific options:

• No ILMI (default)

• Allow for VCI assignment of 3.300

The following commands correctly configure the physical properties of our SONET-based ATM interface:

[edit interfaces at-0/1/0] lab@r3# set atm-options vpi 3 maximum-vcs 301 [edit interfaces at-0/1/0] lab@r3# show atm-options {    vpi 3 maximum-vcs 301; }

Because the ILMI protocol is disabled by default, the declaration of VP 3 and the maximum numbers of VCs that can in turn be supported within this VP complete the ATM-related physical device configuration. It may seem odd that the maximum VCI value specified in this example was 301 instead of the more intuitive setting of 300. This setting is needed because VCIs are zero indexed, which technically makes VCI 300 the 301st VCI instance. The ATM SAR ASIC allocates buffers based on the maximum number of VCIs supported in a specific virtual path, so you will be unable to commit a configuration that specifies a VCI number that lies outside the value specified by the maximum-vcs.

After committing the configuration, the results of a show interfaces indicate that all is well with the ATM physical layer settings on r3:

[edit interfaces at-0/1/0] lab@r3# run show interfaces at-0/1/0 Physical interface: at-0/1/0, Enabled, Physical link is Up  Interface index: 14, SNMP ifIndex: 12 Link-level type: ATM-PVC, MTU: 4482, Clocking: Internal,  SONET mode, Speed: OC3,  Loopback: None, Payload scrambler: Enabled  Device flags  : Present Running  Link flags    : None  Input rate    : 0 bps (0 pps)  Output rate   : 0 bps (0 pps)  SONET alarms  : None  SONET defects : None

Configuring ATM Interface Logical Properties

As with a Frame Relay interface, the logical properties for ATM interfaces will include the specification of a protocol family and its associated addressing, along with the binding of one or more virtual circuit identifiers to logical units on the interface.

The criteria for the ATM logical properties configuration in this example are as follows:

• Logical unit 200, VPI 3, and VCI 200

• IPv4 family, with the addressing shown earlier in Figure 2.4

• NLPID encapsulation

• Unspecified Bit Rate (UBR) with no traffic shaping

Tip 

Because the JNCIP candidate is only required to configure a VCI 200, requiring support of a VCI 300 could be considered a “trick” in that it would be easy for the candidate to incorrectly set the maximum-vci option to a value of 300 with little chance of ever catching the 0-based indexing mistake. But genuine "experts" should be familiar with this nonintuitive maximum VCI issue, having come across the problem numerous times during their years of configuring ATM interfaces in the field. If nothing else, this ATM configuration example should stress the need for careful analysis of all tasks and operational requirements presented in your scenario, as well as the need to seek clarification from your exam proctor when you think a task may have hidden issues.

The following commands correctly configure r3 for this scenario. Because UBR is the default, no configuration is needed, or is in fact possible, for the UBR requirement posed in this configuration example:

[edit] lab@r3# edit interfaces at-0/1/0 unit 200 [edit interfaces at-0/1/0 unit 200] lab@r3# set family inet address 192.168.0.5/30 [edit interfaces at-0/1/0 unit 200] lab@r3# set vci 3.200  [edit interfaces at-0/1/0 unit 200] lab@r3# set encapsulation atm-nlpid 

The interface configuration resulting from these commands is shown next:

[edit interfaces at-0/1/0] lab@r3# show atm-options {     vpi 3 maximum-vcs 301;  }  unit 200 {    encapsulation atm-nlpid;    vci 3.200;    family inet {       address 192.168.0.5/30;    }  } 

Note 

Omitting the VPI value when configuring the VCI will result in the default VPI value of 0. Because this example calls for VPI 3, care must be taken to explicitly configure the correct VPI value.

The default encapsulation for ATM VCs is LLC/SNAP, so NLPID-based encapsulation must be configured at the logical unit/VCI level for compliance with this example’s requirements. The default ATM connection type of point-to-point is a perfect match for this configuration example, so no connection type modification is necessary.

Similar commands are entered on r4 to create the ATM interface configuration shown here:

[edit interfaces at-0/2/1] lab@r4# show atm-options {    vpi 3 maximum-vcs 301;  }  unit 200 {    encapsulation atm-nlpid;    vci 3.200;    family inet {       address 192.168.0.6/30;    }  }

Verifying ATM Operation

With the point-to-point ATM configuration now committed in both r3 and r4, the operator can verify proper operation by displaying the interface’s status or by conducting ping testing. We begin our verification with an example of the former:

[edit interfaces at-0/1/0] lab@r3# run show interfaces terse at-0/1/0 Interface    Admin Link Proto Local          Remote at-0/1/0     up    up  at-0/1/0.200 up    up   inet 192.168.0.5/30

The terse display indicates that the interface is up both administratively and at the logical-link layers, and confirms the use of logical unit 200 as required. The following command displays additional details on the operational status of the ATM interface and confirms the correct NLPID encapsulation:

 [edit interfaces at-0/1/0] lab@r3# run show interfaces at-0/1/0 Physical interface: at-0/1/0, Enabled, Physical link is Up  Interface index: 14, SNMP ifIndex: 12  Link-level type: ATM-PVC, MTU: 4482, Clocking: Internal, SONET mode, Speed: OC3,  Loopback: None, Payload scrambler: Enabled  Device flags  : Present Running  Link flags    : None  Input rate    : 0 bps (0 pps)  Output rate   : 0 bps (0 pps)  SONET alarms  : None  SONET defects : None  Logical interface at-0/1/0.200 (Index 5) (SNMP ifIndex 30)    Flags: Point-To-Point SNMP-Traps Encapsulation: ATM-NLPID  Input packets : 0  Output packets: 0    Protocol inet, MTU: 4470, Flags: None      Addresses, Flags: Is-Preferred Is-Primary        Destination: 192.168.0.4/30, Local: 192.168.0.5  VCI 3.200    Flags: Active    Total down time: 0 sec, Last down: Never  Traffic statistics:      Input packets:                   0      Output packets:                  0

To verify the operation of the ATM VC, the operator now issues a conventional ping from r3 to r4:

[edit interfaces at-0/1/0] lab@r3# run ping count 2 192.168.0.6 PING 192.168.0.6 (192.168.0.6): 56 data bytes 64 bytes from 192.168.0.6: icmp_seq=0 ttl=255 time=1.371 ms 64 bytes from 192.168.0.6: icmp_seq=1 ttl=255 time=1.204 ms --- 192.168.0.6 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.204/1.288/1.371/0.083 ms

The operator can also verify the ATM circuit using the atm option to the ping command as follows:

 [edit interfaces at-0/1/0] lab@r3# run ping atm vci 3.200 segment interface at-0/1/0 53 byte oam cell received on (vpi=3 vci=200): seq=1 53 byte oam cell received on (vpi=3 vci=200): seq=2 53 byte oam cell received on (vpi=3 vci=200): seq=3

Based on these results, it would seem that all is good with your initial ATM interface configuration!

Tip 

When conventional IP-level pings fail on an ATM interface, you should consider using the atm option, which generates OAM loopback cells (F5 level) at either the VCI segment or end-to-end connection levels. These non-IP pings can help isolate ATM and physical layer problems from those that relate to your IP layer configuration. Because this example illustrates a back-to-back connection, you will get the same result regardless of whether you evoke the command with the segment or end-to-end switches. When a switch is present, the segment-level ping will validate the ATM access link while the end-to-end level option will test the end-to-end operation of the virtual channel connection (VCC). You can also configure the background generation of OAM cells to verify link integrity using the oam-period option under the desired VCI.

Monitoring ILMI Operation

While the ILMI protocol can be used to provide link integrity testing between the ATM device and its attached switch, M-series routers only make use of the ILMI protocol for SNMP-related get and puts that are used to exchange ATM interface and IP address information for the devices that attach to a particular ATM access link. As with any command/response protocol, one can gain valuable insight and troubleshooting clues from monitoring the status and operation of the ILMI protocol.

ILMI is enabled on an ATM interface with the following command:

[edit interfaces at-0/1/0] lab@r3# set atm-options ilmi 

In order to commit this configuration, you must ensure that you have enabled support for the well-known 0.16 VPI/VCI value associated with the ILMI protocol at the physical-device level with the following command:

lab@r3# set atm-options vpi 0 maximum-vcs 17 

The modified ATM configuration in r3 is shown next with the ILMI-related changes highlighted:

[edit interfaces at-0/1/0] lab@r3# show atm-options {    vpi 3 maximum-vcs 201;    vpi 0 maximum-vcs 17;    ilmi;  }  unit 200 {    encapsulation atm-nlpid;    vci 3.200;    family inet {       address 192.168.0.5/30;    }  } 

After committing the ILMI change, the router creates a new logical unit that is associated with the 0.16 VPI/VCI value used by ILMI. Information about ILMI protocol operation can now be obtained by showing the interface:

lab@r3# run show interfaces at-0/1/0 Physical interface: at-0/1/0, Enabled, Physical link is Up  Interface index: 14, SNMP ifIndex: 12  Link-level type: ATM-PVC, MTU: 4482, Clocking: Internal, SONET mode, Speed:   OC3,  Loopback: None, Payload scrambler: Enabled  Device flags  : Present Running  Link flags    : None  Input rate    : 0 bps (0 pps)  Output rate   : 248 bps (0 pps)  SONET alarms  : None  SONET defects : None  Logical interface at-0/1/0.200 (Index 4) (SNMP ifIndex 30)    Flags: Point-To-Point SNMP-Traps Encapsulation: ATM-NLPID  Input packets : 0  Output packets: 0    Protocol inet, MTU: 4470, Flags: None      Addresses, Flags: Is-Preferred Is-Primary        Destination: 192.168.0.4/30, Local: 192.168.0.5  VCI 3.200    Flags: Active    Total down time: 0 sec, Last down: Never  Traffic statistics:      Input packets: 0      Output packets: 0  Logical interface at-0/1/0.32767 (Index 5) (SNMP ifIndex 31)    Flags: Point-To-Point SNMP-Traps Encapsulation: ATM-VCMUX  Input packets : 0  Output packets: 91    VCI 0.16       Flags: Active, ILMI      Total down time: 0 sec, Last down: Never  Traffic statistics:      Input packets:                      0      Output packets:                    91 

The fact that ILMI packets are present only in one direction is a sure sign that the router is having problems communicating to the local ATM switch, or as is the case in this example, the presence of a device that has not been configured to support ILMI. After including ILMI support in r4’s configuration, we can display information gleaned from ILMI exchanges:

lab@r3# run show ilmi all Physical interface: at-0/1/0, VCI: 0.16  Peer IP address: 192.168.0.6, Peer interface name: at-0/2/1

The results confirm that r3 is connected to r4’s at- 0/2/1 interface, and that r4’s IP address has in fact been set to 192.168.0.6.

Multipoint ATM Connections

The presence of an ATM switch allows for multipoint ATM connections. A typical multipoint topology is shown in Figure 2.5.

Figure 2.5: Multipoint ATM connections

In this case, r1 is connected to both r2 and r3 using a single logical unit that has been associated with two remote destination IP addresses and the local connection identifier (VPI/VCI) used to reach each of them. The required ATM configuration for r1 is similar to that of a multi- point Frame Relay connection. The key difference between a multipoint and a point-to-point ATM connection is the inclusion of the multipoint and multipoint-destination keywords as shown in the following:

[edit interfaces at-0/1/0] lab@r3# show atm-options {    vpi 0 maximum-vcs 201;  }  unit 200 {    multipoint;    family inet {      address 10.0.1.1/24 {         multipoint-destination 10.0.1.2 vci 102;         multipoint-destination 10.0.1.3 vci 103;      }    }  }

As with Frame Relay, Juniper Networks M-series routers can respond to ATM Inverse ARP requests but cannot initiate them. Therefore, static VCI–to–IP address mapping is mandatory when configuring a Juniper Networks router for multipoint ATM operation. To allow the router to respond to an ATM inverse ARP request, include the inverse-arp keyword as part of the multipoint-destination configuration.

ATM Traffic Shaping

Juniper Networks M-series routers support ATM traffic shaping using either Constant or Variable Bit Rate (CBR/VBR) traffic parameters. Unspecified Bit Rate (UBR) is the default traffic shaping method. You can also configure a maximum queue length on each VC, a technique that is often used to put a finite bound on queue latency (at the cost of dropping traffic that is in excess of VC’s shaping profile). To demonstrate the configuration and verification of ATM traffic shaping, you will now apply the following VBR shaping profile to the ATM connection between r3 and r4:

• Peak bit rate = 1Mbps (~2600 cells/second)

• Sustained bit rate = 500Kbps (~1300 cells/second)

• Maximum burst = 25 cells

• Maximum queue depth of 20 packets

Tip 

You can also specify ATM traffic shaping rates in cells/second by using the suffix c after the desired cell rate, as in set shaping vbr peak 100c for a CBR shaping profile that generates 100 cells per second. Each such cell will carry about 48 bytes of user payload, which equates to a link level throughput of approximately 38.4Kbps. JUNOS software will convert cell-per-second rates into bit-per-second rates when the configuration is displayed.

The commands used to configuring this ATM shaping profile on r3 are shown in the following:

[edit interfaces at-0/1/0 unit 200] lab@r3# set shaping queue-length 20  [edit interfaces at-0/1/0 unit 200] lab@r3# set shaping vbr peak 1m sustained 500k burst 25 

The resulting shaping configuration is shown next with highlights:

[edit interfaces at-0/1/0] lab@r3# show atm-options {    vpi 3 maximum-vcs 201;    vpi 0 maximum-vcs 17;    ilmi;  }  unit 200 {    encapsulation atm-nlpid;    vci 3.200;    shaping {       vbr peak 1m sustained 500k burst 25;       queue-length 20;    }    family inet {       address 192.168.0.5/30;    }  }

To verify that shaping is having an effect, we conduct large packet flood pings, both with shaping enabled and after shaping has been deactivated:

 [edit interfaces at-0/1/0] lab@r3# run ping size 64000 rapid count 5 192.168.0.6 PING 192.168.0.6 (192.168.0.6): 64000 data bytes ..!.. --- 192.168.0.6 ping statistics --- 5 packets transmitted, 1 packets received, 80% packet loss round-trip min/avg/max/stddev = 1048.413/1048.413/1048. 413/0.000 ms

A packet loss of 80 percent is pretty harsh, even for a flood ping. Now the ping test is repeated with shaping deactivated:

[edit interfaces at-0/1/0] lab@r3# deactivate unit 200 shaping [edit interfaces at-0/1/0] lab@r3# commit commit complete [edit interfaces at-0/1/0] lab@r3# run ping size 64000 rapid count 5 192.168.0.6 PING 192.168.0.6 (192.168.0.6): 64000 data bytes !!!!! --- 192.168.0.6 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 31.168/31.474/31.929/0.263

These results indicate that ATM shaping is working as expected.

ATM Interface Summary

ATM interface configuration and testing is similar to Frame Relay in that both interface types support multipoint capabilities using virtual circuit identifiers. ATM interfaces require explicit configuration of VP and maximum VC counts at the physical level, and these values must be adjusted to accommodate the 0-based indexing of VCI values. When a VP value is not specified, JUNOS software will assume a value of 0, so pay special attention when configuring ATM VCIs that do not make use of VP 0.

ATM ping testing can quickly isolate ATM problems from those caused by configuration mistakes made at the IP layer. The use of ILMI can provide information about the device that terminates the ATM access link, and its command/response nature can be used to confirm the integrity of an ATM access link. OAM cells should be enabled when keepalive functions are desired on an ATM interface. Lastly, ATM connections default to a UBR traffic shaping profile but can be configured to support traffic shaping using either CBR or VBR parameters.