SISF に関する情報
概要
スイッチ統合セキュリティ機能（SISF）は、レイヤ 2 ドメインのセキュリティを最適化するために開発されたフレームワークです。これは、IP デバイストラッキング（IPDT）と特定の IPv6 ファーストホップ セキュリティ（FHS）機能の 1を統合して、IPv4 から IPv6 スタックまたはデュアルスタックへの移行を簡素化します。
SISF インフラストラクチャは、以下によって使用される統合データベースを提供します。
-
IPv6 FHS 機能：IPv6 ルータアドバタイズメント（RA）ガード、IPv6 DHCP ガード、レイヤ 2 DHCP リレー、IPv6 重複アドレス検出（DAD）プロキシ、フラッディング抑制、IPv6 ソースガード、IPv6 宛先ガード、RA スロットラ、および IPv6 プレフィックスガード。
-
Cisco TrustSec、IEEE 802.1X、Locator ID Separation Protocol（LISP）、イーサネット VPN（EVPN）、および SISF のクライアントとして機能する Web 認証などの機能。
 （注） |
「SISF」、「デバイス トラッキング」および「SISF ベースのデバイストラッキング」という用語は、本書では同じ意味で使用され、同じ機能を指します。どの用語も、従来の IPDT または IPv6 スヌーピング機能を意味するものではなく、混同すべきではありません。 |
SISF インフラストラクチャについて
このセクションでは、SISF フレームワークに示す SISF インフラストラクチャのさまざまな要素について説明します。
バインディングテーブル
SISF インフラストラクチャは、バインディングテーブルを中心に構築されています。このバインディングテーブルには、スイッチのポートに接続されているホストに関する情報と、これらのホストの IP アドレスと MAC アドレスが含まれています。これは、スイッチに接続されているすべてのホストの物理マップを作成するうえで役立ちます。
バインディングテーブルの各エントリは、接続されたホストに関する次の情報を提供します。
-
ホストの IPv4 アドレスまたは IPv6 アドレス。
-
ホストの MAC アドレス。同じ MAC アドレスが IPv4 アドレスおよび IPv6 アドレスにリンクされる場合があります。
-
ホストが接続されているスイッチのインターフェイスまたはポート、および関連付けられた VLAN。
-
エントリの到達可能性を示すエントリの状態。
次の図は、シンプルなネットワークトポロジと、ネットワーク内の各アクセススイッチの代表的なバインディングテーブルを示しています。SWA と SWB は、ネットワーク内の 2 つのアクセススイッチです。この 2 つのアクセススイッチは、同じ分散スイッチに接続されています。H1、H2、H3、H4 はホストです。
これは分散バインディングテーブルの例で、ネットワーク内の各アクセススイッチには独自のテーブルがあります。別のセットアップとして、SWA と SWB のエントリを持つ分散スイッチ上に、1 つの集中管理型バインディングテーブルを置くことも可能です。
分散型または集中管理型のバインディングテーブルを置くことは、ネットワークに SISF を導入するプロセスにおける重要な設計上の選択肢であり、この章のポリシーパラメータについてセクションで詳しく説明します。
バインディング テーブル エントリの状態とライフタイム
エントリの状態は、ホストが到達可能かどうかを示します。バインディング テーブル エントリの安定した状態は、REACHABLE、DOWN、および STALE です。ある状態から別の状態に変化するとき、エントリは、VERIFY、INCOMPLETE、TENTATIVE など、他の一時的な状態または過渡的な状態になる場合があります。
エントリが特定の状態を維持する期間は、その有効期間と、エントリが正常に検証されたかどうかによって決まります。エントリの有効期間は、ポリシー主導、またはグローバルに設定できます。
device-tracking binding { reachable-lifetime { seconds | infinite } | stale-lifetime { seconds | infinite } | down-lifetime { seconds | infinite } }
状態：REACHABLE
エントリにこの状態がある場合、それは、制御パケットを受信したホスト（IP アドレスおよび MAC アドレス）が検証済みの有効なホストであることを意味します。到達可能なエントリのデフォルトの有効期間は 5 分です。期間を設定することもできます。到達可能な有効期間を設定することにより、ホストからの最後の着信制御パケットの後、ホストが REACHABLE 状態を維持できる期間を指定します。
エントリの到達可能な有効期間が切れる前にイベントが検出された場合、到達可能な有効期間はリセットされます。
新しいエントリが REACHABLE 状態になるには、次の図に示すプロセスを通ります。スイッチは接続されたホストからの着信制御パケットなどのイベント（E）を検出し、エントリを作成します。さまざまなイベントによってエントリが作成されます。これらについては、「バインディングテーブルのソース」セクションで説明します。エントリの作成に続いて、TENTATIVE や INCOMPLETE などの過渡的な状態になります。過渡的な状態の間に、スイッチはバインディングエントリの完全性を検証し、確認します。エントリが有効であることが判明した場合、状態は REACHABLE に変わります。
ただし、アドレスの盗難や類似のイベントが検出された場合、エントリは無効とみなされて削除されます。たとえば、攻撃者がターゲット IP と同じ IP およびその（攻撃者の）独自の MAC アドレスを使用して、勝手にネイバー アドバタイズメント メッセージを送信して、トラフィックをリダイレクトする場合です。
状態：Stale
エントリがこの状態にある場合、エントリの到達可能な有効期間が切れ、対応するホストがまだサイレントである（ホストからの着信パケットがない）ことを意味します。古いエントリのデフォルトの有効期間は 24 時間です。期間を設定することもできます。古い有効期間を過ぎても STALE 状態のままであるエントリは削除されます。
以下の図は、エントリの有効期間を示しています。
状態：Down
エントリがこの状態の場合、ホストの接続インターフェイスがダウンしていることを意味します。Down エントリのデフォルトの有効期間は 24 時間です。期間を設定することもできます。有効期間を過ぎても DOWN 状態のままであるエントリは削除されます。
ホストのポーリングとバインディング テーブル エントリの更新
ポーリングは、ホストの状態、まだ接続されているかどうか、および通信しているかどうかを確認するための、ホストの定期的な条件付きチェックです。エントリの状態を判断するだけでなく、ポーリングを使用してエントリの状態を再確認できます。
グローバル コンフィギュレーション モードで device-tracking tracking コマンドを使用して、ポーリングを有効にできます。有効にした後も、特定のインターフェイスまたは VLAN のポーリングを柔軟にオンまたはオフにできます。このためには、ポリシーで tracking enable または tracking disable キーワードを設定します（デバイス トラッキング コンフィギュレーション モード）。ポーリングが有効な場合、スイッチは指定された間隔でホストをポーリングし、到達可能な有効期間中の到達可能性を再確認します。
ポーリングが有効な場合、スイッチは到達可能な有効期間が切れた後、システムが決定した間隔で、最大 3 つのポーリング要求を送信します。または、グローバル コンフィギュレーション モードで device-tracking tracking retry-interval seconds コマンドでこの間隔を設定することもできます。
以下の図は、ホストがポーリングされるエントリの有効期間を示しています。図には、デフォルトの到達可能で古い有効期間、および再試行間隔が使用されています。
イベント（E）が検出され、REACHABLE エントリが作成されます。
到達可能な有効期間の間にイベントが検出されると、到達可能な有効期間タイマーがリセットされます。
到達可能な有効期間が切れると、スイッチはポーリング要求を送信します。スイッチは、システムが決定した固定の間隔で、最大 3 回ホストをポーリングします。ポーリング要求には、ユニキャスト Address Resolution Protocol（ARP）プローブ、またはネイバー要請メッセージの形式があります。この間、エントリの状態は VERIFY に変わります。ポーリング応答が受信されると（ホストの到達可能性が確認されると）、エントリの状態は REACHABLE に戻ります。
スイッチが 3 回試行してもポーリング応答を受信しない場合、エントリは STALE 状態に変わります。この状態が 24 時間維持されます。古い有効期間中にイベントが検出された場合、エントリの状態は REACHABLE に戻ります。古い有効期間が切れたときに、デバイスは到達可能性を確認するために最後のポーリングを 1 回送信します。この最後のポーリング試行で応答を受信した場合、エントリの状態は REACHABLE に戻ります。最後のポーリングの試行で応答が受信されない場合、エントリは削除されます。
バインディングテーブルのソース
次に、バインディング テーブル エントリの作成と更新の原因となる情報とイベントのソースを示します。
-
バインディングテーブルに動的にデータを取り込む学習イベント：
-
Dynamic Host Configuration Protocol（DHCP）のネゴシエーション（DHCP REQUEST、および DHCP REPLY）。これには、DHCPv4 と DHCPv6 が含まれます。
-
Address Resolution Protocol（ARP）パケット。
Cisco IOS XE Amsterdam 17.3.1 以降、ARP パケットは、CPU 使用率が高いシナリオを軽減するためにスロットリングされます。5 秒間あたり、同じ送信元からの最大 50 の ARP パケットが SISF によって処理されます。5 秒間に 50 という制限は、各バインディングエントリ、つまり各送信元 IP に対するものであることに注意してください。
次の場合、すべての ARP（ARP 要求および ARP 応答）パケットがドロップされます。
-
制限に達している。
-
Cisco Software-Defined Access が設定されている。
-
デバイス トラッキング ポリシーのセキュリティレベルが guard に設定されている。
-
-
Neighbor Discovery Protocol（NDP）パケット。
-
複数の Identity Association-Nontemporary Address（IA_NA）および Identity Association-Prefix Delegation（IA_PD）。
場合によっては、ネットワークデバイスが DHCP サーバーから複数の IPv6 アドレスを要求して受信することがあります。これは、レジデンシャルゲートウェイがアドレスをその LAN クライアントに配布することを要求する場合など、デバイスの複数のクライアントにアドレスを提供するために実行できます。デバイスが DHCPv6 パケットを送信すると、パケットにはデバイスに割り当てられているすべてのアドレスが含まれます。
SISF は DHCPv6 パケットを分析する際に、パケットの IA_NA（Identity Association-Nontemporary Address）および IA_PD（Identity Association-Prefix Delegation）コンポーネントを検査し、パケットに含まれる各 IPv6 アドレスを抽出します。SISF は、抽出された各アドレスをバインディングテーブルに追加します。
上記のような学習イベントによって作成されたエントリは、「動的エントリ」と呼ばれます。特権 EXEC コマンドの show device-tracking database details の出力では、このようなエントリの前に、動的学習イベントの種類を明確にする略語が付けられます。たとえば、ARP パケットの場合は ARP、NDP パケットの場合は ND などです。
-
-
静的バインディングエントリの設定。
レイヤ 2 ドメインにサイレントでも到達可能なホストがある場合、静的バインディングエントリを作成して、ホストがサイレントになった場合でもバインディング情報を保持できます。
静的バインディングエントリは、グローバル コンフィギュレーション モードで次のコマンドを設定することにより、バインディングテーブルに手動で追加されるバインディングエントリです。 device-tracking binding vlan vlan_id { ipv4_add | ipv6_add | ipv6_prefix } [ interface inteface_type_no ] [ 48-bit-hardware-address ] [ reachable-lifetime { seconds | default | infinite } | tracking { default | disable | enable [ retry-interval { seconds | default } ] } [ reachable-lifetime { seconds | default | infinite } ] ]
特権 EXEC コマンドの show device-tracking database details の出力では、静的エントリの前に文字「S」が付きます。
静的エントリの到達可能ライフタイムを設定できます。ステイル ライフタイム タイマーとダウンライフタイムタイマーは、システムによって infinite（無期限）に固定されます（STALE または DOWN 状態のエントリについて、show device-tracking database コマンドの出力で
Time Left列に「N/A」と表示される）。これは、静的エントリが STALE または DOWN 状態になると、バインディングテーブルで無期限にその状態のままになることを意味します。静的エントリは、次に示すアクションによってのみバインディングテーブルから削除できます。clear コマンドを使用したり、他のイベントによってバインディングテーブルから削除することはできません。
-
上記のコマンドの no 形式を設定してエントリを削除します。
-
静的エントリが、ローカルエントリに置き換えられます。
ローカルエントリは、デバイスで SVI を設定するとシステムによって自動的に作成されるエントリです。SVI を設定するときに、静的エントリと同じ IP アドレスを使用すると、ローカルエントリの方が優先順位が高いため、静的エントリがローカルエントリに置き換えられます。
このローカルエントリによる静的エントリの置き換えは、Cisco IOS XE Bengaluru 17.4.1 以降でのみ導入されており、それ以前のリリースでは行われません。
特権 EXEC コマンドの show device-tracking database details の出力では、ローカルエントリの前に文字「L」が付きます。
静的バインディングテーブルの詳細については、コマンドリファレンスにある device-tracking binding コマンドを参照してください。
-
（注） |
上記のプライマリイベントまたはキーイベントに加えて、ping によってデバイス トラッキング エントリが発生する特定のシナリオがあります。送信者の ARP キャッシュまたは IPv6 ネイバーテーブルにターゲットの IP アドレスがまだない場合、ping は IPv4 の ARP パケットまたは IPv6 の ND パケットをトリガーします。これにより、デバイス トラッキング エントリが発生する可能性があります。 ただし、ターゲット IP がすでに ARP キャッシュまたは IPv6 ネイバーテーブルにある場合、ping を実行しても ARP または ND パケットは生成されません。その場合、SISF は IP アドレスを学習できません。 |
デバイストラッキング
デフォルトでは、SISF ベースのデバイストラッキングは無効になっています。インターフェイスまたは VLAN でこの機能を有効にできます。
この機能を有効にすると、バインディングテーブルが作成され、続いてバインディングテーブルがメンテナンスされます。
バインディングテーブルのソース セクションに示されるイベントは、SISF ベースのデバイストラッキングのトリガーとして機能し、ネットワーク内のホストの存在、場所、および移動を追跡し、バインディング テーブルに入力して保持します。たとえば、ホストに関する情報が ARP または ND パケットによって学習される場合、同じホストからの後続のすべての ARP または ND パケットは、SISF ベースのデバイストラッキングのアラートとして機能し、バインディングテーブルのエントリを更新し、ホストがまだ同じ場所に存在するか、移動したかを示します。
スイッチが受信するパケットのスヌーピング、デバイスアイデンティティ（MAC および IP アドレス）の抽出、およびスイッチのバインディングテーブルへの情報保存の継続的なプロセスにより、バインディングの整合性が保証され、バインディングテーブル内のホストの到達可能性ステータスが保持されます 。
SISF ベースのデバイストラッキングを有効にする方法については、SISF の設定方法 を参照してください。
デバイス トラッキング ポリシー
デバイス トラッキング ポリシーは、SISF ベースのデバイストラッキングが従う一連のルールです。ポリシーは、どのイベントがリッスンされるか、ホストがプローブされるかどうか、ホストがプローブされるまでの待機時間などを指示します。これらのルールは、ポリシーパラメータと呼ばれます。
（注） |
このポリシーは、インターフェイスまたは VLAN に適用する必要があります。その場合にのみ、ポリシーパラメータに従って、インターフェイスまたは VLAN のバインディングテーブルが読み込まれます。 ポリシーを作成するさまざまな方法については、SISF の設定方法 を参照してください。 ポリシー設定を表示するには、特権 EXEC モードで show device-tracking policy policy_name コマンドを使用します。 |
ポリシーパラメータについて
ポリシーパラメータは、デバイストラッキング コンフィギュレーション モードでの設定に使用できるキーワードです。各ポリシーパラメータは、ネットワークセキュリティの 1 つ以上の側面に対応します。
このセクションでは、ポリシーを要件に合わせて設定できるように、いくつかの重要なポリシーパラメータの目的について説明します。
Device(config)# device-tracking policy example_policy
Device(config-device-tracking)# ?
device-tracking policy configuration mode:
device-role Sets the role of the device attached to the port
limit Specifies a limit
security-level setup security level
tracking Override default tracking behavior
trusted-port setup trusted port
デバイストラッキング コンフィギュレーション モードで表示されるすべてのパラメータの詳細については、対応するリリースのコマンド リファレンス ドキュメントを参照してください。
Glean 対 Guard 対 Inspect
パケットがネットワークに入ると、SISF が IP アドレスと MAC アドレス（パケットの送信元）を抽出し、後続のアクションは、ポリシーで設定されているセキュリティレベルによって決まります。
Glean、guard、inspect は、セキュリティレベル パラメータで使用できるオプションです。Glean は最も安全性の低いオプションで、 inspect は中程度の安全性で、guard は最も安全です。
ポリシーでこのパラメータを設定するには、デバイス トラッキング コンフィギュレーション モードで security-level キーワードを入力します。
Glean
セキュリティレベルが glean に設定されている場合、SISF が IP アドレスと MAC アドレスを抽出し、検証なしでバインディングテーブルに入力します。したがって、このオプションはバインディングの整合性を保証しません。たとえば、IEEE 802.1X や SANET などのクライアント アプリケーションがホストについてのみ学習し、認証のために SISF に依存しない設定に適しています。
このセキュリティレベルのバインディングエントリの追加に影響する唯一の要因は、アドレス数の制限です。ポートあたりの IP の最大数、MAC あたりの IPv4、MAC あたりの IPv6 には、個別の制限があります。制限に達すると、エントリは拒否されます。このパラメータの詳細については、アドレス数の制限 を参照してください。
Guard
これは、セキュリティレベル パラメータのデフォルト値です。
セキュリティレベルが guard に設定されている場合、SISF はネットワークに入るパケットの IP アドレスと MAC アドレスを抽出して検証します。検証の結果により、バインディングエントリが追加または更新されるか、またはパケットがドロップされてクライアントが拒否されるかが決まります。
検証のプロセスは、データベースで一致するエントリを検索することから始まります。データベースは、一元化または分散化できます。一致するエントリが見つからない場合は、新しいエントリが追加されます。
一致するエントリが見つかり、接続ポイント（MAC、VLAN、またはインターフェイス）が同じであることがわかった場合、タイムスタンプのみが更新されます。そうでない場合、検証の範囲は、アドレス所有者の検証を含むように拡張されます。これには、接続ポイントの変更（別の MAC または VLAN）が有効かどうかを判断するためのホストポーリングが含まれる場合があります。変更が有効な場合、エントリは更新されます。盗難の場合、エントリはバインディングテーブルに追加されません。
バインディングエントリが追加または更新されると、対応するクライアントにネットワークへのアクセスが許可されます。エントリが検証に合格しない場合、対応するクライアントは拒否されます。
（注） |
検証プロセスは、バインディングエントリと、対応する着信パケットに影響します。 |
Inspect
CLI でセキュリティレベルの inspect を使用できますが、これを使用しないことを推奨します。上記の glean および guard オプションは、ほぼすべての使用例とネットワーク要件に対応します。
パケットのセキュリティレベルと SISF アクション
セキュリティ レベル ポリシー パラメータは、ND および ARP パケットのアクションに影響を与える可能性があります。セキュリティレベルが guard でパケットが検証に合格しない場合、ドロップアクションが続きます。glean の場合、パケットはドロップされません。検証の失敗（ guard セキュリティレベルによる）には、無効なバインディング情報、アドレス数の制限に達したなど、さまざまな理由が考えられます。
パケットがARPパケットである場合、Cisco IOS XE Cupertino 17.7.1以降でなければ、ドロップアクションを実行できないことに注意してください。
Trusted-Port および Device-Role スイッチ
device-role スイッチと trusted-port オプションは、効率的で拡張可能な「セキュアゾーン」を設計するのに役立ちます。これら 2 つのパラメータを合わせて使用することで、バインディングテーブルのエントリの作成を効率的に分散できます。これにより、バインディングテーブルのサイズを制御できます。
trusted-port オプション：設定されたターゲットでガード機能を無効にします。trusted-port を経由して学習されたバインディングは、他のどのポートを経由して学習されたバインディングよりも優先されます。また、テーブル内にエントリを作成しているときに衝突が発生した場合も、信頼できるポートが優先されます。
device-role オプション：ポートに面するデバイスのタイプを示し、ノードまたはスイッチです。ポートのバインディングエントリを作成できるようにするには、デバイスをノードとして設定します。バインディングエントリの作成を停止するには、デバイスをスイッチとして設定します。
デバイスをスイッチとして設定することは、大規模なデバイス トラッキング テーブルの可能性が非常に高いマルチスイッチセットアップに適しています。ここで、デバイスに面するポート（アップリンクトランクポート）は、バインディングエントリの作成を停止するように設定できます。トランクポートの反対側のスイッチではデバイストラッキングが有効化され、バインディングエントリの有効性がチェックされるため、このようなポートに到着するトラフィックは信頼できます。
（注） |
これらのオプションのいずれか 1 つだけを設定することが適切な場合もありますが、より一般的な導入例は、ポートで trusted-port と device-role スイッチオプションの両方を設定することです。以下の例は、これについて詳しく説明しています。これらのオプションのいずれか 1 つだけが適している場合、またはこれが必要な場合についても、このセクションの最後で説明しています。 |
ポリシーでこれらのパラメータを設定するには、デバイス トラッキング コンフィギュレーション モードで、trusted-port および device-role キーワードを入力します。
例：マルチスイッチセットアップで Trusted-Port および Device-Role スイッチオプションを使用する
次の例では、device-role switch および trusted-port オプションが、効率的で拡張可能な「セキュアゾーン」の設計にどのように役立つかを説明します。
以下の図 Trusted-Port および Device-Role スイッチオプションのないマルチスイッチセットアップ では、SWA、SWB、および SWC が 3 つのアクセススイッチです。これらはすべて共通の分散スイッチに接続されています。この場合、分散スイッチで唯一必要な設定は、あらゆる種類のトラフィックがブロックされないようにすることです。
H1、H2、…H6 はホストです。各スイッチには、直接接続されたホストが 2 つあります。すべてのホストが相互に通信していて、制御パケットが転送されています。すべてのホストはまた、同じ VLAN 境界内にあります。各スイッチは、直接接続されているホストから、および他のスイッチに接続されているホストから、制御パケットを受信しています。これは、SWA が、SWB および SWC と同様、H1、H2、…H6 から制御パケットを受信していることを意味します。
スイッチごとに、直接接続されたホストのエントリには、バインディングテーブル内のインターフェイス、またはポート P1 および P2があります。他のスイッチに接続されているホストから発信されたエントリには、アップリンクポートを介して学習されたことを示すために、インターフェイスまたはポート名 PxUP が付けられます（x は、各スイッチに対応するアップリンクポートを表します）。たとえば、SWA がアップリンク ポートを介して学習したエントリのインターフェイスまたはポート名は PAUP で、SWB の場合は PBUP などです。
最終的な結果は、各スイッチが学習し、セットアップ内のすべてのホストのバインディングエントリを作成することです。
このシナリオでは、バインディングテーブルの非効率的な使用を示します。これは各ホストが複数回検証されるためであり、1 つのスイッチだけがホストを検証する場合よりも安全性は低くなります。次に、複数のバインディングテーブル内の同じホストのエントリは、より早くアドレス数の制限に達する可能性があります。制限に達すると、それ以上のエントリは拒否され、それにより必要なエントリが不足する可能性があります。
比較のため、以下の図 Trusted-Port および Device-Role スイッチオプションを使用したマルチスイッチセットアップ を参照してください。ここで、SWA が接続されていないホストのパケット（SWB に直接接続されている H3 など）を傍受すると、H3 がスイッチとして設定されているデバイス（device-role switch オプション）に接続されていることが検出され、スイッチのアップリンクポート（パケットの送信元）が信頼できるポート（trusted-port オプション）であるため、エントリは作成されません。
ホストがアクセスポート（各スイッチのポート P1 および P2）に表示されるスイッチにのみバインディングエントリを作成し、アップリンクポートまたは信頼できるポート（Px UP）に表示されるホストのエントリを作成しないことにより、各セットアップのスイッチは、必要なエントリのみを検証して作成するため、バインディング テーブル エントリの作成を効率的に分散できます。
マルチスイッチシナリオで device-role switch および trusted-port オプションを設定する 2 番目の利点は、ホスト、たとえば H1 があるスイッチから別のスイッチに移動するときに、エントリの重複を防ぐことです。以前の場所（たとえば SWA）にある H1 の IP および MAC バインディングは、STALE 状態に達するまでそこに留まり続けます。しかし、H1 が移動して 2 番目のスイッチ（SWC など）に接続すると、SWA はアップリンクポートを介して重複するバインディングエントリを受信します。このような状況で、2 番目のスイッチ（SWC）のアップリンクポートが信頼できるポートとして設定されている場合、SWA は古いエントリを削除します。さらに、SWC にはすでに最新のエントリがあり、このエントリは信頼できるため、別の新しいバインディングエントリは作成されません。
例：Trusted-Port および Device-Role スイッチオプションを使用しない場合
前の例では、分散型バインディングテーブルを使用するマルチスイッチセットアップが device-role switch および trusted-port オプションからどのようなメリットを受けるかを明確に示していすが、次の種類のネットワークには適していない可能性があります。
-
シスコ以外のスイッチが使用されているネットワーク
-
スイッチが SISF ベースのデバイストラッキング機能をサポートしていないネットワーク。
どちらの場合も、device-role switch および trusted-port オプションを設定しないことを推奨しました。さらに、分散スイッチ上で集中管理型のバインディングテーブルを維持することを推奨しました。これにより、シスコ以外のスイッチやこの機能をサポートしていないスイッチに接続されているすべてのホストについて、すべてのバインディングエントリが分散スイッチによって検証され、引き続きネットワークが保護されます。以下の図に、この例を示します。
効率的で拡張可能なセキュアゾーンの作成
適切なネットワークで trusted-port オプションと device-role switch オプションを使用し、他のネットワークではそれらを除外することにより、効率的で拡張可能なセキュアゾーンを実現できます。
セキュアゾーン 1、2、3 には、3 つの異なるセットアップと、それぞれの場合に確立されるセキュアゾーンが表示されます。
| セキュアゾーン： |
セキュアゾーン 1：非効率的で拡張不可能なセキュアゾーン |
セキュアゾーン 2：バインディングテーブルが分散化されている場合の効率的で拡張可能なセキュアゾーン |
セキュアゾーン 3：バインディングテーブルが一元管理されている場合の効率的なセキュアゾーン |
|---|---|---|---|
| 拡張性： | 拡張不可、各スイッチにネットワーク内のすべてのホストのエントリがある | 拡張可能、直接接続されたホストのみのエントリとしての各スイッチ | 拡張不可、分散スイッチにネットワーク内のすべてのホストのエントリがある |
|
ポーリングとネットワークへの影響： n = ホストの数 m = スイッチの数 ポーリング要求の総数：= n X m |
18 のポーリング要求が送信されている（ホスト 6 つ X スイッチ 3 つ）。 各ホストは、ネットワーク内のすべてのスイッチによってポーリングされる（trusted-port および device-role switch オプションがない場合）。 ネットワーク負荷が非常に高い。 |
6 つのポーリング要求が送信されている（スイッチごとに、ホスト 2 つ X スイッチ 1 つ）。 最小限のネットワーク負荷（ポーリング要求は、ローカルアクセススイッチによって直接接続されたホストに送信される。各ポーリング要求は、ネットワーク内の少数のポイントを通過する）。 |
6 つのポーリング要求が送信されている（ホスト 6 つ X スイッチ 1 つ）。 ネットワーク負荷はセキュアゾーン 2 よりも高いが、セキュアゾーン 1 ほど高くはない（ポーリング要求は分散スイッチから送信され、ホストに到達する前にアクセススイッチを通過する）。 |
| 効率： |
非効率的なバインディングテーブル。バインディングテーブルが各スイッチで複製されるため。 |
効率的なバインディングテーブル。各ホストのバインディング情報は 1 回だけ、1 つのバインディングテーブルとこれが直接接続されたスイッチのバインディングテーブルに入力されるため。 | 効率的なバインディングテーブル。各ホストのバインディング情報は 1 回だけ入力され、これは分散スイッチ上の一元管理されたバインディングテーブルにあるため。 |
| 推奨するアクション： | 適切なポリシーを再適用して、セキュアゾーンをセキュアゾーン 2 のようにする。 | なし。これは効率的で拡張可能なセキュアゾーン。 | なし。セットアップのタイプを考えると、これが可能な限り最高のセキュアゾーン（ネットワーク内の他のスイッチがシスコ以外のものであるか、この機能をサポートしていない場合）。 |
Trusted-Port または Device-Role スイッチのみを使用する場合
device-role switch のみを設定することは、エントリをリッスンする必要はあるが、学習する必要はない場合に適しています。たとえば、重複アドレス検出（DAD）の場合、またはスイッチに面したポートで IPv6 またはネイバー要請（NS）メッセージを送信する場合です。
スイッチポート（またはインターフェイス）でこのオプションを設定すると、SISF ベースのデバイストラッキングはポートをトランクポートとして扱い、ポートが他のスイッチに接続されていることを意味します。ポートが実際にトランクポートであるかどうかは関係ありません。したがって、NS パケットまたはクエリが新しいエントリの検証のためにネットワーク内のスイッチに送信されると、セキュアポート（device-role switch が設定されているポート）だけがパケットまたはクエリを受信します。これにより、ネットワークが保護されます。コマンドがどのポートにも設定されていない場合、クエリの一般的なブロードキャストが送信されます。
trusted-port のみを設定するのは、アクセスポートを信頼できるポートとして設定する必要がある場合に適しています。アクセスポートが、スイッチが使用している DHCP サーバーまたは同様のサービスに接続されている場合、アクセスポートを信頼できるポートとして設定すると、そのようなポートからのトラフィックが信頼されるため、サービスは中断されません。これにより、アクセスポートを含むセキュアゾーンも拡張されます。
アドレス数の制限
アドレス数制限パラメータは、バインディングテーブルに入力できる IP アドレスと MAC アドレスの数の制限を指定します。これらの制限の目的は、既知および予期されるホストの数に基づくバインディングテーブルのサイズを含めることです。これにより、ネットワーク内の不正なホストまたは IP に対してプリエンプティブなアクションを実行できるようになります。
ポリシーレベルでは、ポートあたりの IP アドレス数、MAC あたりの IPv4 アドレス数、MAC あたりの IPv6 アドレス数に個別の制限があります。ポートあたりの IP アドレスの数のみを設定または変更できます。
ポートあたりの IP
ポートあたりの IP オプションは、ポートに許可される IP アドレスの総数です。アドレスは IPv4 または IPv6 を使用できます。制限に達すると、それ以上の IP アドレス（すなわちエントリ）はバインディングテーブルに追加されません。
ポリシーでこのパラメータを設定するには、デバイス トラッキング コンフィギュレーション モードで limit address-count ip-per-port キーワードを入力します。現在設定されている制限よりも低い制限を設定すると、新しい（より低い）制限は新しいエントリにのみ適用されます。既存のエントリはバインディングテーブルに残り、バインディングエントリのライフサイクルを通過します。
MAC あたりの IPv4 および MAC あたりの IPv6
これは、1 つの MAC アドレスにマッピングできる IPv4 アドレスの数と、1 つの MAC アドレスにマッピングできる IPv6 アドレスの数を指します。制限に達すると、バインディングテーブルにエントリを追加できなくなり、新しいホストからのトラフィックはドロップされます。
（注） |
インターフェイスまたは VLAN で有効な MAC あたりの IPv4 制限および MAC あたりの IPv6 制限は、適用されるポリシーで定義されているとおりです。ポリシーで制限が指定されていない場合、制限が存在しないことを意味します。いかなる種類のポリシー（プログラム可能、カスタムポリシー、またはデフォルトポリシー）についても、MAC あたりの IPv4 または MAC あたりの IPv6 の制限を変更または設定することはできません。 制限があるかどうかを確認するには、show device-tracking policy policy name を入力します。 |
Device# show device-tracking policy LISP-DT-GUARD-VLAN
Policy LISP-DT-GUARD-VLAN configuration:
security-level guard (*)
<output truncated>
limit address-count for IPv4 per mac 4 (*)
limit address-count for IPv6 per mac 12 (*)
tracking enable
<output truncated>バインディングテーブルでのアドレス数制限と SISF アクション
アドレス数制限パラメータは、バインディングテーブルで実行されるアクションに影響します。制限に達すると、バインディングテーブルにバインディングエントリが追加されません。（パケットアクションには影響しません）。
アドレス数の制限および他の SISF 設定との相互作用
-
制限に階層はありませんが、各制限に設定されたしきい値は他の制限に影響します。
たとえば、ポートあたりの IP 制限が 100 で、MAC あたりの IPv4 制限が 1 の場合、単一のホストの IPv4-MAC バインディングエントリで制限に達します。ポートにさらに 99 個の IP アドレスがプロビジョニングされていても、同じ MAC にバインドされるそれ以上の IP エントリは許可されません。同様に、ポートあたりの IP 制限が 1 で、MAC あたりの IPv4 制限が 100 の場合、1 つのホストの IPv4-MAC バインディングエントリで制限に達します。MAC にさらに 99 個の IP アドレスがプロビジョニングされていても、その MAC にバインドされるそれ以上の IP エントリは許可されません。
-
グローバルおよびポリシーレベルの制限
device-tracking binding max-entries コマンドで設定される制限はグローバルレベルで、デバイス トラッキング コンフィギュレーション モードの limit address-count コマンドで設定される制限は、インターフェイスまたは VLAN レベルのポリシー用です。
ポリシーレベルの値およびグローバルで設定された値が存在する場合、1 つの制限に達するとバインディングエントリの作成が停止します。この制限は、グローバル値またはポリシーレベルの値のいずれかです。
グローバルに設定された値のみが存在する場合、1 つの制限に達すると、バインディングエントリの作成が停止します。
ポリシーレベルの値のみが存在する場合、ポリシーレベルの制限に達すると、バインディングエントリの作成が停止します。
トラッキング
追跡パラメータには、ネットワーク内のホストの追跡が含まれます。上のセクション ホストのポーリングとバインディング テーブル エントリの更新 では、これを「ポーリング」と呼びます。また、ポーリングの動作についても詳しく説明します。
グローバルレベルでポーリングパラメータを設定するには、グローバル コンフィギュレーション モードで device-tracking tracking コマンド入力します。このコマンドを設定した後も、個々のインターフェイスおよび VLAN で、ポーリングを柔軟にオンまたはオフにできます。このためには、ポリシーでポーリングを有効または無効にする必要があります。
ポリシーでポーリングを有効にするには、デバイス トラッキング コンフィギュレーション モードで tracking enable キーワードを入力します。デフォルトでは、ポリシーでポーリングは無効になっています。
ポリシーの作成に関するガイドライン
-
特定のターゲットで複数のポリシーを使用できる場合、システム内部のポリシーの優先度によって、どのポリシーが優先されるかが決まります。
手動で作成されたポリシーが最も優先されます。プログラムで作成されたポリシーの設定を上書きする場合は、カスタムポリシーを作成して、その優先度を高くすることができます。
-
プログラムで作成されたポリシーのパラメータは変更できません。カスタムポリシーの特定の属性を設定できます。
ポリシー適用のガイドライン
-
複数のポリシーを同じ VLAN に適用できます。
-
プログラムポリシーが VLAN に適用されていて、ポリシー設定を変更する場合は、カスタム デバイストラッキング ポリシーを作成して VLAN に適用します。
-
優先順位が異なる複数のポリシーが同じ VLAN に適用されている場合、優先順位が最も高いポリシーの設定が有効になります。ここでの例外は、mac あたりの IPv4 制限アドレス数、および mac あたりの IPv6 制限アドレス数の設定です。優先順位が最も低いポリシーの設定が有効になります。
-
デバイストラッキング ポリシーが VLAN のインターフェイスに適用されると、インターフェイスのポリシー設定が VLAN のポリシー設定よりも優先されます。ここでの例外は、mac あたりの IPv4 制限アドレス数、および mac あたりの IPv6 制限アドレス数の値で、インターフェイスと VLAN の両方のポリシーから集約されます。
-
デバイス トラッキング クライアント機能の設定が削除されない限り、ポリシーは削除できません。
フィードバック