非同期転送モード(ATM) : IP-ATM 間サービス クラス

IP to ATM COS キューイングによってカウントされるバイト

2002 年 11 月 8 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2006 年 11 月 3 日) | フィードバック

Q. QoS サービス ポリシーで、bandwidth 文の値を決定する必要があります。 ATM による permanent virtual circuit(PVC; 相手先固定接続)では、この値はどのように見積もればよいですか。 ATM セルの 53 バイト全体がカウントされますか。

A. class-based weighted fair queueing(CBWFQ; クラスベース重み付け均等化キューイング)と low latency queueing(LLQ; 低遅延キューイング)を有効にするためにサービス ポリシー内で設定される bandwidth コマンドと priority コマンドでは、それぞれに Kbps の値を使用します。これは、show interface の出力でカウントされているものと同じオーバーヘッド バイトをカウントする単位です。 具体的には、レイヤ 3 キューイング システムでは次の項目をカウントします。
 

オーバーヘッド フィールド 長さ show policy-map interface でのカウント
論理リンク制御/サブネットワーク アクセス プロトコル(LLC/SNAP) 8(パケットごと) カウントされる
ATM アダプテーション レイヤ 5(AAL5)トレーラー 4

カウントされない

AAL5 トレーラ(および
CRC)は、SAR で追加
されるため、
IOS では対象に
なりません。
カウントされる
4 バイトは、内部
VC カプセル化
のためのバイトです。

最後のセルを 48 バイトの偶数倍にするためのパディング 可変 カウントされない
ATM セル ヘッダー 5(セルごと) カウントされない

show policy-map interface で出力されるカウンタを使用して、レイヤ 3 キューイング システムでカウントされるオーバーヘッド バイトを見積もる方法について説明します。

シスコのデバイスでは、AAL5PDU バイトと ATM セル バイトについて、従来から次の定義を使用してきました。

ATM_cell_byte = roundup(aal5_pdu/48)*53

aal5_pdu_byte = ip_size + snap(8)+aal5_ovh(8) = ether_size - 2

次のテストでは、60 バイトの IP ペイロードを 1 秒間に 50 パケット(pps)、PVC 0/3 に宛てて送信しています。PVC 0/3 では AAL5SNAP カプセル化が設定されています。
r1#show policy-map interface
   ATM5/0.33: VC 0/33 -

    Service-policy output: llq (1265)

      Class-map: p5 (match-all) (1267/4)
        14349 packets, 1033128 bytes
        30 second offered rate 28000 bps, drop rate 0 bps
        Match: ip precedence 5  (1271)
        Weighted Fair Queueing
          Strict Priority
          Output Queue: Conversation 136
          Bandwidth 40 (kbps) Burst 1000 (Bytes)
          (pkts matched/bytes matched) 0/0
          (total drops/bytes drops) 0/0

1033128 バイト / 14349 パケット = パケットあたり 72 バイト

8(SNAP ヘッダー) + 60 IP ペイロード + 4(AAL5 トレーラの最初の 4 バイト) = 72

テストの後、show policy-map int コマンドを実行すると、14349 パケットと 1033128 バイトの値が表示されます。 これらの値は、このクラスの基準に一致するパケットの数をカウントしたものです。 (「pkts matched/bytes matched」の値は、VC で輻輳が発生したときか、パケットに対してプロセス交換が行われたときにだけ増分されます。 プロセス交換されたパケットは、すべてレイヤ 3 キューイング エンジンに送られます。)

show interface atm コマンドが同じオーバーヘッド バイトをカウントしているかどうか確認してみましょう。 次のテストでは、100 バイトの ping を 5 回送信しました。

7500-1#ping 192.168.66.70

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.66.70, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
7500-1#

show interface atm コマンドの出力には、5 つの入力パケットと、560 バイトが表示されます。  500 バイトの IP ペイロードに対する余分な 40 バイトは、次の式から計算できます。

40 バイト / 5 パケット = パケットあたり 8 バイトのオーバーヘッド

LLC/SNAP ヘッダーの 8 バイト

7500-b#show interface atm 4/1/0
ATM4/1/0 is up, line protocol is up
  Hardware is cyBus ATM
  Internet address is 192.168.66.70/30
  MTU 4470 bytes, sub MTU 4470, BW 155520 Kbit, DLY 80 usec, rely 255/255, load 1/255
  NSAP address: BC.CDEF01234567890ABCDEF012.345678901334.13
  Encapsulation ATM, loopback not set, keepalive not supported
  Encapsulation(s): AAL5, PVC mode
  2048 maximum active VCs, 1024 VCs per VP, 1 current VCCs
  VC idle disconnect time: 300 seconds
  Last input 00:00:03, output 00:00:03, output hang never
  Last clearing of "show interface" counters 00:00:21
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 1 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     5 packets input, 560 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     5 packets output, 560 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out

次のテストは、74 バイトのパケットを 100 個送信するイーサネット インターフェイスに対して行ったものです。
louve(TGN:OFF,Et3/0:2/2)#show pack

Ethernet Packet:  74 bytes
      Dest Addr: 0050.73d1.6938,   Source Addr: 0010.2feb.b854
      Protocol: 0x0800

IP    Version: 0x4,  HdrLen: 0x5,  TOS: 0x00
      Length: 60,   ID: 0x0000,   Flags-Offset: 0x0000
      TTL: 60,   Protocol: 1 (ICMP),   Checksum: 0x74B8 (OK)
      Source: 0.0.0.0,     Dest: 5.5.5.5

ICMP  Type: 0,   Code: 0  (Echo Reply)
      Checksum: 0x0EFF (OK)
      Identifier: 0000,  Sequence: 0000
Echo Data:
    0 : 0001 0203 0405 0607 0809 0A0B 0C0D 0E0F 1011 1213  ....................
   20 : 1415 1617 1819 1A1B 1C1D 1E1F                      ............

show policy-map interface コマンドと show interface ethernet コマンドはどちらも 740 バイトとしてカウントされます。
few#show policy-map interface ethernet 2/2
 Ethernet2/2

  Service-policy output: a-test

    Class-map: icmp (match-all)
      10 packets, 740 bytes

few#show interface ethernet 2/2
     10 packets output, 740 bytes, 0 underruns(0/0/0)

60 IP ペイロード + 2 * 6(送信元と宛先の MAC アドレス) + 2(プロトコル タイプ) = 74

この計算から、イーサネット CRC は show interface および show policy-map の出力のいずれにも含まれていないことが分かります。   重要なのは、CRC が含まれているかどうかにかかわらず、2 つの値にばらつきがないことです。

最後に、HDLC カプセル化を使用しているシリアル インターフェイスでカウントされているバイトを見てみましょう。  このテストでは、100 バイトのパケットを 5 個送信しました。

r3#show policy interface
  Serial4/2:0

    Service-policy output: test

      Class-map: icmp (match-all)
        5 packets, 520 bytes

Cisco HDLC フレームの定義について説明します。

text

flag = フレームの最初または最後 = 0x7E
address = フレーム タイプのフィールド:
   0x0F = ユニキャスト フレーム
   0x80 = ブロードキャスト フレーム
   0x40 = パディングされたフレーム
   0x20 = 圧縮されたフレーム
protocol = カプセル化されたデータのイーサネット タイプ。IP の場合の 0x0800 など

このシリアル テストに対する show policy interface コマンドの出力には、520 バイトと表示されます。 フレームごとに追加される 4 バイトには、フレームの最初および最後のフラグは含まれません。 その代わり、このバイトにはアドレス、コントロール、およびプロトコル フィールドが含まれます。 重要なのは、このバイトには frame check sequence(FCS; フレーム チェック シーケンス)が含まれないことです。

最後に

レイヤ 3 キューイング システムでカウントされるオクテットの数と、物理層に到達したパケットで実際に使用されているオクテットの数は異なることを認識しておくことが重要です。 64 バイトのパケットで使用される実際の帯域幅は、イーサネット インターフェイス上のものよりも ATM インターフェイスのものの方が大きくなっています。 特に、CBWFQ と LLQ は、次の 2 つの ATM 固有のオーバーヘッドの原因にはなりません。
  • パディング - パケットの最後のセルを 48 バイトの偶数倍にします。  このパディングは、パケットが ATM 層に到達したときに SAR によって追加されます。
  • 5 バイトの ATM セル ヘッダー。
言い換えれば、CBWFQ と LLQ では 64 バイトを 64 バイトとして見積もりますが、実際には、ATM および物理層でこのパケットは 106 バイトを占め、2 つのセルを使用します。   フラグと CRC はすべてのインターフェイスにありますが、レイヤ 3 キューイング システムには含まれません。

Cisco Bug ID CSCdt85156 は、CRC をカウントする機能の要求です。  ここでは、CRC のようにすべてが固定値で予測可能なレイヤ 2 のオーバーヘッドを priority 文に含め、物理ワイヤーに到達したときにフローによって実際に消費される帯域幅に、この設定を可能な限り近づけるようにすることについて説明しています。


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 10420