Nexus 7000 FCoE マルチホップ F1 距離制限

概要

このドキュメントでは、Fibre Channel over Ethernet（FCoE）マルチホップ インターフェイスで入力破棄が発生した場合の対処方法について説明します。 問題/解決策を説明するこのドキュメントは、リモート データセンターを相互接続するインターフェイスで破棄の症状がみられる場合に役立ちます。

この例では、実際にこの問題が発生する状況を説明します。 

この例のトポロジでは、10Km 離れた位置にある 2 つのデータセンターが示されています。 DC1 と DC2 は 10Km FCoE Virtual Expansion（VE）（マルチホップ）インターフェイスで接続されています。 N7K-F132XP-15 ラインカードでマルチホップ インターフェイスが設定されています。 F1 シリーズのデータシートに基づくと、これはサポートされている範囲内です。

このデータシートには、次の IEEE データセンター ブリッジング（DCB）機能が示されています。

• プライオリティ ベースのフロー制御（PFC）： IEEE P802.1Qbb
• 拡張伝送選択（ETS）： IEEE P802.1Qaz
• Data Center Bridging Exchange（DCBX）
• 最大ロスレス リンク距離： 20 km

このドキュメントの作成に当たり、Cisco bug ID CSCts72420 が修正されました。 ロスレス リンク距離 20Km という行が削除されました。

問題

EMC VPLEX デバイスではストレージ レプリケーション機能がサポートされています。 このシナリオでは同期レプリケーションが使用されます。 EMC VPLEX デバイスのアップグレード時に、デバイスが「非同期」になりました。 VPLEX アップグレード後に、デバイスが 10Km FCoE マルチホップ リンク経由で大量データのレプリケートを開始しました。

データ レプリケーションの増加に伴い、次のイベントが発生しました。

1. Nexus 5000-DC2 が Nexus 7000-DC2 に対し継続的なポーズの送信を開始しました。
2. Nexus 7000-DC2 が 10KM リンク経由で Nexus 7000-DC1 に対しポーズの送信を開始しました。
3. Nexus 7000-DC1 が Nexus 5000-DC1 にポーズを送信しました。

これらのイベントは、予期される FCoE フロー制御動作の概要です。 Nexus 5000-DC2 からポーズ フレームを受信する場合、エンドデバイスで輻輳が発生しています。 入力バッファが満杯の状態に近づき、ポーズ フレームがファブリックに少しずつ戻ります。

このシナリオにおける問題は、Nexus 7000-DC2 が 10Km マルチホップ リンク経由で入力でパケットを継続的に破棄することが問題です。

Ethernet4/1 is up
  Dedicated Interface
  Hardware: 1000/10000 Ethernet, address: XXXX.XXXX.XXXX (bia XXXX.XXXX.XXXX)
  MTU bytes (CoS values): 9216(0-2,4-7) 2112(3)
  BW 10000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA
  Port mode is trunk
  full-duplex, 10 Gb/s, media type is 10G
  Beacon is turned off
  Auto-Negotiation is turned on
  Input flow-control is off, output flow-control is off
  Rate mode is dedicated
  Switchport monitor is off
  EtherType is 0x8100
  Last link flapped 25week(s) 0day(s)
  Last clearing of "show interface" counters 79w2d
  30 seconds input rate 296186536 bits/sec, 27891 packets/sec
  30 seconds output rate 151677360 bits/sec, 19294 packets/sec
  Load-Interval #2: 5 minute (300 seconds)
    input rate 289.58 Mbps, 27.61 Kpps; output rate 165.20 Mbps, 20.05 Kpps
  RX
    566235497816 unicast packets  2504479 multicast packets  0 broadcast packets
    566239834433 input packets  502487779153524 bytes
    219280594774 jumbo packets  0 storm suppression packets
    0 runts  0 giants  0 CRC  0 no buffer
    0 input error  0 short frame  0 overrun   0 underrun  0 ignored
    0 watchdog  0 bad etype drop  0 bad proto drop  0 if down drop
    0 input with dribble  19312516 input discard
    1832141 Rx pause
  TX
    681040135255 unicast packets  2504251 multicast packets  0 broadcast packets
    681046392756 output packets  744942450903588 bytes
    333793360248 jumbo packets
    0 output error  0 collision  0 deferred  0 late collision
    0 lost carrier  0 no carrier  0 babble  0 output discard
    3753250 Tx pause
  5 interface resets

上記のインターフェイスは FCoE（CoS 3）トラフィックのみを伝送できるため、この状況が発生してはなりません。 入力破棄は、FCoE の「no-drop」QoS ポリシーに違反しています。 また、FCoE 環境での破棄が原因で SCSI 強制終了やエラーなどが発生する可能性があります。

解決策

デバイスがポーズを送信するときには、ポーズ フレームを生成するインターフェイスに、リンク距離の 2 倍をバッファリング可能な大きさのバッファ スペースを備えた入力キューが必要です。 これは、ポーズが生成される時点で回線がフルである可能性があるためです。 生成されたポーズ フレームを隣接デバイスが受信/処理する時点までに、回線が再びフルになる可能性があります。 したがって、ポーズを生成するデバイスは、リンク距離の 2 倍をバッファできる必要があります。

計算の結果、10Km リンクで 100 以上のパケットが送信されている可能性があります。 ASIC の制約により、F1 シリーズ ラインカードでは 10km 以上のリンクでのロスレス FCoE をサポートできません。 

注: 入力バッファ（IB）を使用して、ポーズ前に転送中だったパケットがキューに入れられます。 ポーズの送信後は、IB は使用されません。 遅延バッファ（LB）を使用して、ポーズの送信後に転送中のパケットがキューに入れられます。

F2/F2e をサポートするためのハードウェア/ソフトウェアのアップグレード

Cisco Bug ID CSCua10484 で、F2 長距離ロスレス距離サポートが解決されました。 NX-OS リリース 6.1(2) 以降では、これらの設定変更が許可されています。

注: 古いバージョンのコードでは、変更は許可されていましたが有効になりませんでした。

IB でパケット捕捉のために確保されているスペースは次のように計算されます。 PL_STOP - PL_PAUSE. デフォルトでは PL_STOP と HWM（PL_PAUSE）の値は同じです。

module-4# show hardware internal mac port 1 qos configuration | begin IB | end EB
  IB
    Port page limit : 3584 (1376256 Bytes)
    VL#  HWM pages(bytes)  LWM pages(bytes) Used PL_STOP(HWM & LWM)
                                            pages                    THR
     0    1107 (  425088)   1059 (  406656)     0     1107   1059
     1       2 (     768)      1 (     384)     0        2      1
     2    1107 (  425088)   1059 (  406656)     0     1107   1059
     3    1053 (  404352)   1029 (  395136)     0     1053   1029
     4       2 (     768)      1 (     384)     0        2      1
     5     231 (   88704)    159 (   61056)     0      231    159
     6       2 (     768)      1 (     384)     0        2      1
     7       2 (     768)      1 (     384)     0        2      1
    Credited DWRR WT: 216 (0xd8) Uncredited DWRR WT: 144 (0x90)
    DWRR honor UC = FALSE
     Leak Lo weight = 0xd8, enabled = FALSE
  EB

no-drop サービス クラス（CoS）に大きなバッファを割り当てることで長い距離に対応できるように、これらの値を変更できます。 このためには、「default-4q-7e-in-policy」Quality of Service（QoS）ポリシー マップをコピーします。

注: 次の設定シナリオは、Admin VDC ではなく Default VDC を使用する Nexus 7000 での COS 3 入力バッファ割り当ての増加に対応して調整されています。 Admin VDC は厳密な「管理」VDC であり、データプレーン機能がないため、Admin VDC では QoS ポリシーのコピーとバッファ割り当ての変更のための追加手順は不要です。 したがって Admin VDC を使用する場合は、Storage VDC でのみこれらの変更を行います。

Default VDC および Storage VDC

Switch(config)# qos copy policy-map type queuing ?
*** No matching command found in current mode, matching in (exec) mode ***
  default-4q-7e-in-policy   Default 7-ethernet input queuing policy
  default-4q-7e-out-policy  Default 7-ethernet output queuing policy

Switch(config)# qos copy policy-map type queuing default-4q-7e-in-policy prefix 7I_

ポリシーが Default VDC と Storage VDC の両方にコピーされたら、no-drop COS に対して大きなキュー制限率（%）を割り当てるため、「4q-7e-in」ポリシーマップを変更します。

Default VDC および Storage VDC

Switch(config)# show run ipqos
<snippet>

policy-map type queuing 7I_4q-7e-in
  class type queuing c-4q-7e-drop-in
    service-policy type queuing 7I_4q-7e-drop-in
    queue-limit percent 1                 <<<<<<<<<<<<<<<<<
  class type queuing c-4q-7e-ndrop-in
    service-policy type queuing 7I_4q-7e-ndrop-in
    queue-limit percent 99                <<<<<<<<<<<<<<<<<

次に、変更した QoS ポリシーを目的のインターフェイスに適用します。

Storage VDC

Switch(config)# int e4/1
Switch(config-if)# service-policy type queuing input 7I_4q-7e-in
Switch(config-if)# show run int e4/1

!Command: show running-config interface Ethernet4/1
!Time: Sun Mar  2 21:03:07 2014

version 6.1(4)

interface Ethernet4/1
  switchport
  switchport mode trunk
  switchport trunk allowed vlan 1,2990
  load-interval counter 2 30
  service-policy type queuing input 7I_4q-7e-in
  no shutdown

この時点で、PL_STOP 値が High Water Mark（HWM）を超えていることがわかります。 したがって、IB で大きなバッファ容量を使用できます。

module-4# show hardware internal mac port 1 qos configuration | begin IB | end EB
  IB
    Port page limit : 3584 (1376256 Bytes)
    VL#  HWM pages(bytes)  LWM pages(bytes) Used PL_STOP(HWM & LWM)
                                            pages                    THR
     0      15 (    5760)      9 (    3456)     0       15      9
     1       2 (     768)      1 (     384)     0        2      1
     2      15 (    5760)      9 (    3456)     0       15      9
     3    1161 (  445824)   1137 (  436608)     0     3521   1137
     4       2 (     768)      1 (     384)     0        2      1
     5       3 (    1152)      0 (       0)     0        3      0
     6       2 (     768)      1 (     384)     0        2      1
     7       2 (     768)      1 (     384)     0        2      1
    Credited DWRR WT: 216 (0xd8) Uncredited DWRR WT: 144 (0x90)
    DWRR honor UC = FALSE
     Leak Lo weight = 0xd8, enabled = FALSE
  EB

この例では、IB の残りスペース = 3521 ページ - 1161 ページ = 2360 ページ => 906,240 バイトになります。

注: この回避策を利用できるのは、FCoE トラフィックが FCoE マルチホップ インターフェイス経由で渡される場合だけです。 データ トラフィックも渡される場合は、Cisco Technical Assistance Center (TAC)に連絡して支援を受けてください。

または

可能であれば、サイト間ファイバ チャネル（FC）を使用します。 この解決策では、必要な距離に応じて、Coarse Wavelength Divison Multiplexer/Dense Wavelength Divison Multiplexer（CWDM/DWDM）介入またはダーク ファイバのいずれかを必要とします。