内容

概要

問題

解決方法

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

概要

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

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

この例のトポロジでは、10Km 離れた位置にある 2 つのデータセンターが示されています。DC1とDC2を接続する10KMのFCoE仮想拡張(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）介入またはダーク ファイバのいずれかを必要とします。