データ センター スイッチング (Data Center Switching)について-Ask the Expert

[CiscoJapanModerator]

担当エキスパート：山田　哲義（Akinori Yamada）

Cisco Japan TAC のカスタマーサポートエンジニアとして、Nexus 7000/5000/3000/2000 シリーズのサポートを行っています。

また，上記製品の他に PPPoE/L2TP についても経験があります。

ディスカッション開催期間：2013年5月20日～2013年6月2日

[質問の回答方法]

サポートコミュニティへCisco.comIDでログインすると、この説明の右下に「返信」ボタンが表示されます。クリックすると投稿欄が表示されますので、質問をご記入ください。最後に「メッセージの投稿」をクリックすると質問が送信され、完了となります。

もし１つの質疑応答が進行していても、他の新しい質問を同じスレッド内に投稿いただいて問題ありません。
この「エキスパートに質問」のディスカッションスレッドに届いた質問は担当のTACエキスパートが回答しますがすべての質問に返信できないかもしれません。
返信が得られずに開催期間が終了して残ってしまった質問については、サポートコミュニティ事務局が今回の技術カテゴリの通常のディスカッション フォーラムへ再掲載し、有用な情報の展開へとつなげていきます。

エキスパートから返信が得られた質問については、評価機能でその回答が適切であったかをエキスパートへぜひ伝えてください。

あなたからの質問だけでなく、他コミュニティのメンバーから寄せられた質問がどう発展したかをのぞきに、ぜひこのフォーラムへ再度訪問されることをお待ちしております！

[エキスパートからの回答について]

質      問の投稿から原則数日以内に回答できるよう努めます。内容によっては、検証や確認に時間がかかる場合もありますのでご了承ください。質問の内容に  よっ    ては、エキスパートの担当範囲外の場合もございます。その際はサポートコミュニティ事務局、もしくは適切な担当から回答いたします。

ディスカッション期間を過ぎてからの投稿は、事務局より通常コミュニティへ投稿いただくようお願いさせていただくようになりますことも合わせてご理解ください。

[makotokaw]

Nexus 7000 に対して ACL を設定する検証をしていたところ、下記のようなメッセージが表示され、ACLが適用できませんでした。
switch(config-if)# ip access-group ACL_TEST  out
ERROR: Tcam will be over used, please turn off atomic update

仕様を確認する限り、ACL設定数の上限には達していないようです。

上記メッセージの意味と、もしあればこの問題の回避方法を教えて頂けないでしょうか。

よろしくお願いします。

[YAMADA Akinori]

ご質問ありがとうございます．

まず、Nexus 7000 シリーズでは ACL の設定変更時に通信中断を伴わないアトミックアップデートがデフォルトで有効となっております。

アトミックアップデートでは、I/O モジュールで使用されている ACL エントリの他にこれからアップデートされる ACL エントリを TCAM 上に保持します。そのためアトミックアップデートでは十分な TCAM 上のリソースが必要となります。

ご質問で頂いたエラーメッセージは、上記の実装により必要な TCAM の容量を確保できなかった為に出力されます。

回避方法として no hardware access-list update atomic コマンドにてアトミックアップデートを無効にする事で、全てのリソースを ACL に使用する事が可能になります。このコマンドはデフォルト VDC で実行し、全ての VDC で設定が適応されます。

ただし、アトミックアップデートを無効にした場合、ACL をアップデートして前から存在している ACL を削除するまでの短い処理時間中、ACL が適用されるトラフィックはデフォルトでドロップされます。

非アトミックアップデートでの通信中に受信パケットを全て許可したい場合は hardware access-list update default-result permit コマンドを使用します。

以上よろしくお願いします。

[k.matsubara]

現在、Catalyst6500 から Nexus 7000 + Nexus 5000 + Nexus 2000 の構成へと機器更新作業を推進しています。
Nexus 7000 を L3 として、Nexus 5000 + 2000 を L2 として使っており、各機器は冗長しています。

バージョンは次の通りです。

Catalyst6500
  IOS (tm) c6sup2_rp Software (c6sup2_rp-PSV-M), Version 12.1(19)E1, EARLY DEPLOYMENT RELEASE SOFTWARE (fc2)

Nexus7000
  kickstart: version 6.1(2)  bootflash:///n7000-s2-kickstart.6.1.2.bin
  system:    version 6.1(2)  bootflash:///n7000-s2-dk9.6.1.2.bin

Nexus5000
  kickstart: version 5.2(1)N1(1b)  bootflash:///n5000-uk9-kickstart.5.2.1.N1.1b.bin
  system:    version 5.2(1)N1(1b)  bootflash:///n5000-uk9.5.2.1.N1.1b.bin

Catalystへ接続しているサーバー群の移行を順次できるように、Catalyst 6500 ～ Nexus 7000 間を L2(Trunk) 接続し、HSRP-V1 をCatalyst 6500×2台とNexus7000×2台の計4台で組み、現在は 旧機器側の Catalyst 6500 が Active を持っています。

例えば、ある Vlan の HSRP は次のステータスとなっております。
・Catalyst6500 1系が Active
・Catalyst6500 2系が Standby
・Nexus7000    1系が Listen
・Nexus7000    2系が Listen

長々と恐縮ですが、以下に関しまして、可能な範囲でもご回答下さいますと助かります。
(切替作業に際しては、様々なリスクを検討しておく必要がありますので、その様な質問もございます)

(1)Catalyst6500 に接続したサーバーが、Nexus 側への接続を完了した後に、Cat6500～Nexus7000 間を接続しているLANケーブルを抜線することで、HSRP の Active を移動させる事を検討していますが、何か注意点はございますでしょうか。
HSRP のタイマーは、Catalyst/Nexus 共に default のまま使用しており、Hellotime 3 sec/holdtime 10 sec による通信断は許容する前提です。

(2)抜線による作業で、Nexus 側に HSRP VIP の Active が移動しないというリスクは考えられるものでしょうか。

(3)もし抜線した後に、Nexus 側の HSRP VIP が Active にならなかった場合には、どのような対応手順がありますでしょうか。
(該当 vlan を shutdown して no shutdown する? or priority を操作? or Nexus再起動?(避けたい) or etc.)

(4)抜線をするよりも、HSRP の priority 値を書き換える事で Nexus 側に HSRP VIP の Active を寄せる方が安全/確実な移行手順と言えるでしょうか。
(通信断は許容しますので、Catalyst～Nexus 間で HSRP の切替え作業中に通信不具合が発生する可能性があるか否かの観点で)

次の投稿の "正解 by Jerry Ye  オン Jul 23, 2011 9:33 AM" を読みまして、Catalyst/Nexus が共存している構成における HSRP VIP の Active 移動作業には、IOS/NS-OSのバージョンにより改善されているのかも知れませんが、通信上の問題(混乱)が発生しうるものでしょうか。

Catalyst 6500 -> Nexus 7000 migration
https://supportforums.cisco.com/thread/2095078

以上、よろしくお願い申し上げます。

[YAMADA Akinori]

ご質問ありがとうございます。

まず、HSRP についての互換性は Catalyst 6500、Nexus 7000 でも保たれており、過去マイグレーションによる混在環境のケースも確認できます。

この事を踏まえ、移行環境の Nexus 7000 で vPC のご利用はないという前提で回答致します。

１）可能であれば、エンドユーザ様の環境に即した環境での事前検証を入念に行う事を推奨致します。HSRP の互換性はありますが、移行環境や手順によっては想定しない動作を事前に確認するためです。

２）正しくハローパケットが到達し、処理されていれば問題ありません。なお，現時点で Nexus  のステータスが Listen となっている事からハローパケットの交換は正常に行えていると考えられます。

３）対処法については原因により異なるため回答できませんが，show hsrp コマンドや debug コマンドで移行しない原因を特定する事が重要となります。

４）より確実な方法としてプライオリティの変更による移行を推奨します。途中特定の Catalyst 6500 をアクティブ、Nexus 7000 をスタンバイにするなど、移行後のネットワークを想定した切り替えが可能です。

vPC の構成の場合、HSRP がアクティブでないステータスでも上位リンクから受信したパケットはそのまま下位リンクへ転送されます。

そのため、場合によっては下位のデバイスでのテーブルの書換えが発生し、想定しない障害が発生する可能性も考えられます。

vPC の構成の場合は，上記の URL にある通り N7K のリンクを shutdown し、移行の準備が整ったCatalyst 6500 のリンクを shutdownさせた後，Nexus 7000 のリンクを no shutdown する事を提案します。

[k.matsubara]

ご回答下さいましてありがとうございます。

当方構成の説明が不足しており恐縮です。Nexus では vPC を使用しております。

この為、最後にご提案下さいました、移行準備が整った後に Catalyst 6500 側を shutdown し、Nexus 7000 側を no shutdown する手順を検討することと致します。

(或いは、Catalyst と Nexus 間の配線を抜線することで分断し、パケットが混乱しない形で移行する)

残念ながら、この問題に気が付いたときにはすでに検証ができる環境ではなくなっておりまして、今回の質問とさせて頂いた次第です。

なお、「vPC の構成の場合、HSRP がアクティブでないステータスでも上位リンクから受信したパケットはそのまま下位リンクへ転送される」旨の説明がある資料リンクがございましたら、ご教授下さいますと幸いです。

(日本語ですと助かりますが、英語でも構いません)

以上、よろしくお願い申し上げます。

[YAMADA Akinori]

返信ありがとうございます。

vPC の仕様として peer-link を経由した通信は極力行わないようになっております。

その仕様に従い受信したパケットはローカルで処理されるため、vPC 構成では HSRP のステータスがアクティブでなくても、パケットの転送を行います。

ご所望の資料についてですが、以下 URL の『vPC のレイヤ 3 での相互作用』を参照してください。

http://www.cisco.com/web/JP/product/hs/switches/nexus7000/prodlit/white_paper_c11-516396.html

[k.matsubara]

ご確認並びに、資料リンクありがとうございました。

vPC 環境における HSRP では、ステータス上 Standby であっても HSRP 仮想MACアドレス宛のパケット転送をする旨は承知しました。

当方の環境において、現在 Nexus 側の HSRP ステータスは Listen となっておりますが、Listen においてはこの様な処理はしないという理解で宜しいでしょうか。

(現時点では、通信に問題は発生しておりませんが、潜在的な問題が発生し得る構成になっているのかどうか)

以上、よろしくお願い申し上げます。

[YAMADA Akinori]

Matsubara 様

確認しましたが Listen 環境でもパケットの転送は行われます。

しかしながら、Listen の状態であれば、パケットが Nexus 7000 側に向く事が無いため問題は発生しないと考えます。

また，移行時どちらかの Nexus 7000 がアクティブ / スタンバイになった時点で，Nexus 7000 * 2 と Catalyst 6500 の三台がパケットを転送しうる機器になります。

アップリンクとダウンリンクでアクティブが入れ子になった場合などは注意が必要となります。

そのため、先にご紹介した手順での移行を提案しております。

[k.matsubara]

内容承知いたしました。

ご確認下さいましてありがとうございました。

[SYUNTARO ARAKI]

NexusシリーズはVXLANをサポートしていますでしょうか？

サポートされている場合、VXLANの構成が良く分からないのですが、

以下の利用イメージで認識は合っていますでしょうか？

2つのデータセンター間でのDR構成を組みたいと考えています。

環境:
　・2つのVMware環境A,BがL3ネットワーク(L3スイッチ)を挟んで存在する
  ・各VMware環境とL3スイッチの間にNexusシリーズのスイッチが存在する

通信イメージ:
　VMWare環境A側のNexusシリーズにて、L2データをVXLANでL3データに
　カプセル化し、L3スイッチでVMware環境Bのネットワークにルーティング。
　VMWare環境BのNexusシリーズでヘッダを取り除き、L2データを仮想マシンに届ける。

VXLAN構成で利用したい機能：
　・VMotion

  ・vSphere Replication

  ・HA、FT構成は使用可能？？

[YAMADA Akinori]

ご質問ありがとうございます。

Nexus1000V 仮想スイッチでのみ VXLAN をサポートしております。
通信の仕組みに関しては、ARAKI 様のご認識の通りとなります。

vMotion, HA, FT や vSphere Replication のサポート詳細については、
お手数ですが VMware 社へお問い合わせ頂けますようお願いします。

以上よろしくお願い致します。

[SYUNTARO ARAKI]

Yamada様

ご返信ありがとうございます。了解しました。

また、VXLANを以下の構成で使用し、VM-1とVM-2を同じL2ネットワークにしたい場合、L3スイッチに対してマルチキャスト

ルーティングの設定と、MTUを1550Byte以上に拡張することは必須なのでしょうか？

|VM-1|==|Nexus1000V|==|PhysicalNIC|==|L3SW|==|L3SW|==|L3SW|==|Nexus1000V|==|VM-2|

既存の構成は普通のユニキャストルーティングで、普通の1500Byte MTUで通信を行っていますので、できれば

この2点の設定変更を行わず、既存の構成でVXLANを使用したいと考えています。

また、VM-1、VM-2のMTUの変更もしたくありません。

恐れているのは、MTUの変更による他通信への影響と、マルチキャストルーティング設定追加によりネットワーク運用が

複雑化することで、この2点を避けたいです。

[SYUNTARO ARAKI]

Yamada様

たびたびすみません、VXLANを使用するに当たり、物理的なL3スイッチでマルチキャストルーティングを使用しない、

MTUを1500Byteのまま使用する、VMでMTUの変更も行わない、の条件に加え、フラグメントの増大も許容したく

ない、を含めて、ご回答をいただけないでしょうか？

[YAMADA Akinori]

ARAKI 様

ご返信が遅くなりました。

MTU の変更、マルチキャストルーティング共に必須条件となります。

MTU の変更が必須というのは Nexus 1000V がフラグメントパケットのリアセンブリをサポートしていない事に起因します。

そのため Nexus 1000V 間の機器での MTU:1550、もしくは VM での MTU:1450 への変更が必要となります。

フラグメントの増大を防ぐためには MTU:1550 への変更が必要とご理解下さい。

次に L2 ブロードキャスト・マルチキャスト・Unknown ユニキャストは、 IP マルチキャストを使って通信するため、上位の物理ネットワークでマルチキャスト・ルーティングをサポートする必要があります。

上記については、以下の URL に前提条件として記載されております。

ご参考 URL:

http://www.cisco.com/cisco/web/support/JP/docs/SW/DCSWT/Nex1000VSWT/CG/026/b_VXLAN_Configuration_4_2_1SV_2_1_1_chapter_010.html?bid=0900e4b182e40102#concept_8D47371366C040859EE70FDDB3BBE6EB

以上よろしくお願いします。