6-6 SD-Access (SDA) — 登録と解決でファブリックを動かす LISP コントロールプレーン
SD-Access のコントロールプレーンは LISP、データプレーンは VXLAN です。Catalyst 9000v 2 台で LISP ファブリックを組み、EID の登録と解決、分散エニーキャストゲートウェイ、MTU 1450、SGACL を実測します。
1. 前節の振り返りと本節の内容
前節 6-5 VXLAN / EVPN では、VXLAN が元のイーサネットフレームのヘッダとペイロードを包んで L3 網に流すこと、包む側と解く側を VTEP と呼ぶこと、素の VXLAN の学習が従来と同じ flood-and-learn であること、そしてその学習を BGP EVPN が制御プレーンでの配布に置き換えることを扱いました。線路上のフレームは 50 バイト大きくなり、トンネルの中を通る最大サイズもちょうど 50 だけ小さくなりました。
本節は同じオーバーレイを、キャンパスの側から扱います。6-5 の末尾は 3 つの論点を予告しました。以下のとおりです。
| 6-5 が予告した論点 | 本節のどこで扱うか |
|---|---|
| 同じ VXLAN を自動化の側から扱う | §2 で平面の分け方、§15 で Catalyst Center が何を生成するか |
| 同じオーバーレイをファブリックとして構成し、エンドポイントの識別と場所の解決に LISP を使う | §4 で LISP の考え方、§10〜§12 で登録と解決の実機出力 |
手で書いた nve1 や l2vpn evpn が、誰にどう置き換えられるのか | §7〜§9 が置き換え先の CLI、§15 がその CLI を書く主体 |
3 つ目の答えを先に置きます。nve1 と l2vpn evpn を置き換えるのは LISP の登録と解決であり、Catalyst Center はその設定を生成する層です。つまり置き換えは 2 段階に分かれており、本節が実機で示せるのは前者、出典で示せるのが後者になります。本節のラボには Catalyst Center も ISE も居ません。それでもファブリックが建つことが、この 2 段階が分かれていることの証拠になります。
本節は出典に基づく部分と、本ラボの実測に基づく部分をはっきり分けます。
| 層 | どこ | 何を根拠にしているか |
|---|---|---|
| 出典層 | §2 / §3 / §4 / §13 の推奨値 / §14 後半 / §15 | Cisco SD-Access Solution Design Guide (CVD)、LISP VXLAN Fabric Configuration Guide 17.9.x、Command Reference 17.16.x、RFC 9300 / RFC 9301 / RFC 7348、draft-smith-vxlan-group-policy-05 |
| 実測層 | §5〜§13 / §14 前半 / §16 | 2 つのラボ（初回ラボ / 補強ラボ）の show 出力 41 ファイル。R- で始まる 14 ファイルが補強ラボ、残りの 27 ファイルが初回ラボです。どちらの出力かは §13 と §14 のブロックごとに示します。§5 の 1 件（両端末を同じサブネットに置いた構成）と §16 の 2 件の実機観測（show lisp site の応答と Catalyst 8000V の拒否）は、この 41 ファイルではなく着手前の予備ラボで撮ったもので、本文にその旨を書いています |
| 測っていないこと | §18 | — |
以下に貼る実機出力は改変していません。必要な行だけを抜き出した箇所には … を置いてありますが、抜き出した行そのものは実機が印字したままです（本節のコードブロック全行を show-outputs/ に行単位で機械照合しています。ただしプロンプトと投入コマンドを 1 行にまとめた表記だけは本節の組み立てで、実機はこの 2 つを別の行に印字します）。
本節の実機は CML 上の Catalyst 9000v で、この VM イメージは Cisco 公式が beta と明記しています。
Note: The Catalyst 9000 virtual switch is a beta VM image. The node definitions and VM image are distributed as-is in beta form with no formal or official support.
したがって以下の実測はすべて「beta イメージ上での観測」です。公式の動作確認済み機能の一覧は Basic L2 switching / OSPFv2 routing / SVIs / Loopback / L2 VLANs / External connectivity via the Gi0/0 management interface の 6 項目で、LISP も VXLAN も SD-Access も入っていません。一覧に無いことと、非対応と明示されていることは別です。本節は前者の状態で観測しています。
2. SD-Access を構成する平面
SD-Access (Software-Defined Access) は、Cisco がキャンパスネットワーク向けに提供するファブリックの仕組みです。CVD は構成技術を 4 つに分けます。
There are four key technologies that make up the SD-Access solution, each performing distinct activities in different network planes of operation:
In Cisco SD-Access the management plane is enabled and powered by Cisco Catalyst Center, the control plane is based on LISP (Locator/ID Separation Protocol), the data plane is based on VXLAN (Virtual Extensible LAN), and the policy plane is based on Cisco TrustSec.
同じ内容を、IOS-XE 側の設定ガイドは 3 つとして数えます。
Three fundamental components work together to provision a LISP VXLAN fabric. These enable flexible attachment of devices, data transmission and enhanced security through segmentation and group-based policies:
矛盾ではなく、管理平面を数に入れるかどうかの差です。転送に効く平面は 3 枚で、管理平面はその外側に立ちます。
| 平面 | 実装技術 | 役割 |
|---|---|---|
| 管理平面 (Management plane) | Cisco Catalyst Center | 設計・プロビジョニング・可視化。転送には関与しない |
| コントロールプレーン (Control plane) | LISP (Locator/ID Separation Protocol) | エンドポイントの識別子と居場所の対応づけ |
| データプレーン (Data plane) | VXLAN (Virtual Extensible LAN) | パケットのカプセル化と転送 |
| ポリシー平面 (Policy plane) | Cisco TrustSec | SGT による分離。設定ガイドは (Optional) と書く |
管理平面が転送に関与しないことは、CVD 自身が明記しています。
While Catalyst Center is not part of the SD-Access data plane or control plane, its availability directly affects how the fabric is provisioned, maintained, and operated. A Catalyst Center outage does not impact SD-Access wired and wireless traffic forwarding, but it does affect:
この 1 文が本節のラボの成立根拠です。Catalyst Center はファブリックを作り、保ち、運用する側に居るのであって、フレームを運ぶ側には居ません。
ここで用語を 1 つ分けておきます。Cisco 自身が、製品としての SD-Access と、CLI で組む仕組みとしてのファブリックを呼び分けています。
The SD-Access solution is provided through a combination of Cisco Catalyst Center, the Cisco Identity Services Engine (ISE), and wired and wireless device platforms that have fabric functionality.
A LISP VXLAN fabric is an enterprise solution that enables policy-based segmentation over a LISP-based fabric overlay across a Campus and Branch network. It uses a LISP-based control plane and VXLAN-based data plane.
本ラボが建てるのは後者、Cisco が LISP VXLAN fabric と呼んでいるものです。Catalyst Center と ISE を含む「SD-Access ソリューション」を組んだわけではありません。以降、実機の話をするときは LISP VXLAN fabric、製品と設計思想の話をするときは SD-Access と書き分けます。
ファブリックの中で装置が担う役割は、物理的な機種ではなくソフトウェアの機能です。
A fabric role in SD-Access is a software-based function that operates on physical network hardware. These roles are designed for modularity and flexibility—allowing a single device to host one or multiple roles as needed. When provisioning SD-Access fabric roles, it’s important to align their deployment with the underlying network architecture and its functional distribution. Placing different roles on separate devices provides the highest levels of availability, resiliency, and scalability.
| 役割 | 何をするか |
|---|---|
| fabric edge node | 端末を収容し、LISP の ITR / ETR として包み・解く装置 |
| control plane node | map-server と map-resolver を兼ね、EID と RLOC の対応を保持する装置 |
| border node | ファブリックの外との境界。L3 の IP ハンドオフでは、外へネイティブ IP で出す（VLAN を外部へ延伸する L2 ハンドオフもあり、本節では扱いません） |
| intermediate node | edge と border をつなぐ L3 の中継。VXLAN も LISP も SGT も要らないが MTU だけは要る |
役割の配置については、資料の間で強弱が割れます。上に引いた CVD は「分けたほうが可用性が高い」と書きますが、設定ガイドは同居を推奨します。
We recommend that you configure both the border and control plane nodes on a single fabric device.
そして CVD 自身も、実配備では同居が一般的だと書いています。
Fabric site control plane nodes may be deployed as either dedicated (distributed) or nondedicated (colocated) devices in relation to the fabric border nodes. In a Fabric in a Box deployment, all fabric roles must be colocated on the same device. In most deployments, it is common to deploy a colocated control plane node solution, using the border node and control plane node on the same device.
3 つとも同じ資料群の中にあります。理論上の可用性が高いのは分離、実務上の既定値は同居、という読み方になります。本ラボは 2 台しか使えないため、SW1 に control plane node と fabric edge を同居させます。
3. 6-5 との対比 — 同じデータプレーン、違うコントロールプレーン
6-5 の BGP EVPN と本節の LISP は、どちらも VXLAN の上に載る制御の仕組みです。ただしこの 2 つを正面から比較した Cisco の記述は存在しません。本節が取得した Cisco の資料のうち、EVPN という語が出てくるのは CVD 巻末の略語表 1 行だけでした。
EVPN—Ethernet Virtual Private Network (BGP EVPN with VXLAN data plane)
したがって以下の対比表は筆者の整理であって、Cisco の主張ではありません。各行の左側は 6-5 の実測と出典、右側は本節の実測と出典に基づきます。
| 6-5 VXLAN / EVPN | 6-6 LISP VXLAN fabric | |
|---|---|---|
| データプレーン | VXLAN | VXLAN（ヘッダにポリシー情報を載せる拡張つき） |
| コントロールプレーン | BGP EVPN | LISP |
| 端末の位置の伝え方 | MAC / MAC-IP の経路として広告される | EID として map-server に登録され、問い合わせに応じて返る |
| 端末の位置の置き場所 | 経路表と EVPN の表 | map-cache |
| ゲートウェイ | 対称 IRB による分散エニーキャストゲートウェイ | 分散エニーキャストゲートウェイ（同じ IP と MAC を全 edge が持つ） |
| 制御に関わる装置 | VTEP が BGP EVPN のピアを張る（6-5 のラボは leaf 2 台を直結） | edge / border / control plane node が LISP を話し、intermediate node は IP 転送だけでよい |
| 設定を書く主体 | 人間が CLI を書く | Catalyst Center が生成する（本節は CLI で手書きする） |
LISP-aware でなければならないのは edge と border だけ、という限定は設定ガイドの記述です。
Provides end-to-end segmentation using LISP Virtualization technology wherein only the fabric edge and border nodes must be LISP-aware. The rest of the components are just IP forwarders.
この一文が限っているのは、端末を収容して転送するノードのうち LISP-aware でなければならない範囲です。control plane node そのものは §4 で引くとおり LISP の map-server と map-resolver で、LISP を話す側に入ります。逐語で「要らない」と確定するのは intermediate node です。
Intermediate nodes do not have a requirement for VXLAN encapsulation/de-encapsulation, LISP control plane messaging support, or SGT awareness.
配りかたの違いについて、CVD は LISP を pull 型と呼びます。
Selective, pull-based control plane: This approach reduces unnecessary network updates and flooding, leading to more efficient resource use and supporting seamless network scalability.
As with DNS, a local node probably does not have information about everything in a network but instead asks for the information only when local hosts need it to communicate (known as a pull model). This information is then cached for efficiency.
ただし pull は Cisco の語彙で、RFC の語彙ではありません。RFC 9300 と RFC 9301 に pull という語は一度も出てきません。RFC が使うのは on-demand です。
The EID-to-RLOC Map-Cache is a generally short-lived, on-demand table in an Ingress Tunnel Router (ITR) that stores, tracks, and is responsible for timing out and otherwise validating EID-to-RLOC mappings.
そして、「LISP は pull、EVPN は push」という単純化は、現行の SD-Access には当てはまりません。同じ CVD が、新しい制御プレーン方式である LISP Pub/Sub を push として説明しているためです。
In the initial release of the Pub/Sub architecture, subscribers (border nodes) express interest in receiving updates for all registrations for a given instance ID (IID) table, and the publisher (control plane node) proactively pushes reachability information to subscribers. By pushing mappings instead of redistributing them through BGP in LISP/BGP, LISP Pub/Sub removes the dependency on BGP for information exchange within and across fabric sites (when using the optional SD-Access transit control plane).
LISP Pub/Sub is recommended for all new SD-Access implementations.
RFC 側にも push の機構があります。
This document specifies the Solicit-Map-Request (SMR), a control plane push-based mechanism. An additional control plane mechanism based on the Publish/Subscribe paradigm is specified in [LISP-PUBSUB].
本ラボが組んだのは Pub/Sub ではなく、map-server と map-resolver を明示した従来型の構成です。したがって §11 で観測する「必要になった側が取りに行く」形は、その構成での実測であり、Pub/Sub を採る現行の推奨構成に対する主張ではありません。加えて、本節は 6-5 の BGP EVPN 側で同じ実験をしていません。§11 が示すのは LISP 側で起きたことだけです。
4. LISP の考え方 — EID と RLOC の分離
LISP (Locator/ID Separation Protocol) は、アドレスを 2 つの名前空間に分けるところから始まります。
LISP defines two namespaces: Endpoint Identifiers (EIDs), which identify end hosts; and Routing Locators (RLOCs), which identify network attachment points.
| 用語 | 定義 |
|---|---|
| EID (Endpoint Identifier) | 端末を識別する値。誰であるか |
| RLOC (Routing Locator) | 端末を収容している装置のアドレス。どこに在るか |
| ITR (Ingress Tunnel Router) | 送信側でカプセル化する装置 |
| ETR (Egress Tunnel Router) | 受信側でカプセル化を解く装置 |
| xTR | ITR と ETR の両方を兼ねる装置の総称 |
なぜ分けるのかを、CVD は従来の IP アドレスの二重の役目から説明します。
In many networks, the IP address associated with an endpoint defines both its identity and its location in the network. In these networks, the IP address is used both for network layer identification (who the device is on the network) and as a network layer locator (where the device is at in the network or to which network the devices is connected). While an endpoint’s location in the network will change, who this device is and what it can access should not have to change. LISP allows the separation of identity and location though a mapping relationship of these two namespaces: an endpoint’s identity (EID) in relationship to its routing locator (RLOC).
この対応づけを EID-to-RLOC マッピングと呼び、その保管と応答を担うのがマッピングシステムです。SD-Access ではその実体が control plane node で、RFC が別々に定義する 2 つの役割を 1 台にまとめます。
The SD-Access fabric control plane node is built on Locator/ID Separation Protocol (LISP) functionality, combining both the map-server and map-resolver roles within the same node.
| 役割 | 定義（RFC 9301） |
|---|---|
| Map-Server | ETR の集合に代わって EID プレフィクスをマッピングデータベースに公開する装置 |
| Map-Resolver | ITR からの問い合わせを受け、マッピングデータベースを参照して答えを見つける装置 |
保持するデータベースは、SD-Access の用語では HTDB (Host Tracking Database) と呼ばれます。
Host tracking database (HTDB): The HTDB serves as the central repository of EID-to-RLOC mappings, where the RLOC corresponds to the IP address of the Loopback 0 interface on a fabric node. The HTDB is equivalent to a LISP site in traditional LISP, which includes what EIDs can be and have been registered.
RLOC が Loopback 0 のアドレスであると明記されている点が、後の underlay 設計に直結します。Loopback へ届くことが、ファブリックが動く前提になります。
本節で扱う主要な制御メッセージは 4 種類です（RFC が定めるメッセージはこれで尽きるわけではなく、Map-Notify-Ack や Encapsulated Control Message も定義されています。後述の Encapsulated Map-Request は後者を使います）。
| メッセージ | 向き | 定義（RFC 9301） |
|---|---|---|
| Map-Request | ITR → Map-Resolver | A control plane message that queries the Mapping System to resolve an EID. |
| Map-Reply | Map-Server / ETR → ITR | 問い合わせへの応答。到達性の確認にも使われる |
| Map-Register | ETR → Map-Server | A LISP message sent by an ETR to a Map-Server to register its associated EID-Prefixes. |
| Map-Notify | Map-Server → ETR | A LISP message sent by a Map-Server to an ETR to confirm that a Map-Register has been received and processed. |
未解決の宛先が現れたときの動きを、RFC が 1 文で書いています。
An ITR sends an Encapsulated Map-Request to a configured Map-Resolver when it needs an EID-to-RLOC mapping that is not found in its local Map-Cache.
ローカルの map-cache に無いときに、問い合わせが出ます。解決できるまでのあいだ、パケットは捨てられるか溜められます。
If the lookup fails, the ITR/PITR needs to retrieve the mapping using the LISP control plane protocol [RFC9301]. While the mapping is being retrieved, the ITR/PITR can either drop or buffer the packets.
ただし Map-Request が出る契機はこれだけではありません。RFC は 3 つを並べて書いています。
A Map-Request is sent from an ITR when it needs a mapping for an EID, wants to test an RLOC for reachability, or wants to refresh a mapping before Time to Live (TTL) expiration.
後ろの 2 つ、つまり RLOC の到達性の確認と TTL 切れ前の更新は、キャッシュに項目が在ることが前提です。宛先アドレスの取り方がそれを示します。
For the latter two cases, the destination IP address used for the Map-Request is one of the RLOC addresses from the Locator-Set of the Map-Cache entry.
到達性の確認は周期的に繰り返されます。
RLOC-Probes are sent periodically using a jittered timer interval
この痕跡は本節の実測にも現れます。§11 で引き直した後の項目は via map-reply, complete、つまりキャッシュに載っている状態で、同じ出力に Last RLOC-probe sent: 00:00:37 (rtt 67ms) が印字されています。キャッシュが在るあいだは制御メッセージが止まる、という読み方はできません。
ただし送信時刻が印字された項目は 2 件で、どちらも周期性を示しません。もう 1 件は clear の前に撮った SW1 の同じ EID の項目で、Last RLOC-probe sent: 00:08:34 (rtt 199ms) と出ています。2 件とも、この経過時間が同じ出力の項目の uptime（00:00:37 と 00:08:34）に一致するので、撮れているのは項目が生まれた時点の送信であって、周期的に繰り返されたことではありません。宛先側 SW2 の項目は never です。uptime: 00:10:34 まで在る項目に送信の記録が 1 度も無いことは、周期的な送信が本ラボでは撮れていないという読み方を補強します。加えて本ラボは各 instance-id に remote-rloc-probe on-route-change を入れており、この指定が probe の周期に与える影響も測っていません（§18）。
キャッシュに載せる方式には、載せる側の都合がそのまま効きます。CVD はこれを conversational learning と呼びます。
Conversational learning is the process of populating forwarding tables with only endpoints that are communicating through the node.
裏返せば、マッピングシステムが止まるとキャッシュに無い相手とは通信を始められません。
The fabric control plane node contains the database used to identify an endpoint’s location in the network. This is a central and critical function, and is required for the fabric to operate. If the fabric control plane is down, endpoints inside the fabric fail to establish communication to remote endpoints that are not cached in the local database.
最後に、VRF や VLAN との対応を担う instance ID です。
Network virtualization: A LISP instance ID (IID) is used to maintain independent VRF and VLAN topologies. From a data-plane perspective, the LISP IID maps to either a Layer 2 or Layer 3 VNI.
Layer 2 overlays are identified with a VLAN-to-VNI correlation (Layer 2 VNI), and Layer 3 overlays are identified with a Virtual Routing and Forwarding instance (VRF)-to-VNI correlation (Layer 3 VNI or instance ID in LISP).
6-5 で VNI と呼んでいたものが、LISP の側では instance-id という名前で設定に現れます。同じ 24 ビットの値を、データプレーンの側から呼ぶか制御プレーンの側から呼ぶかの違いです。
数値をまとめます。いずれも RFC 側の値で、Cisco の資料には登録周期の記載がありません（4 資料に対し 8 通りの語で検索して 0 件）。
| 値 | 意味 | 出典 |
|---|---|---|
| 1 分 | Map-Register の推奨送信間隔 | RFC 9301 |
| 3 分 | 受信が途絶えた登録を Map-Server が消すまでの時間 | RFC 9301 |
| 1 回 / 秒 / EID プレフィクス | Map-Request のレート上限 | RFC 9301 |
| UDP 4342 | LISP 制御メッセージの既定ポート | RFC 9301 / Command Reference 17.16.x |
| 24 ビット | Instance ID の幅（VXLAN の VNI と同じ幅） | RFC 9300 / RFC 7348 |
本ラボは登録周期を実測していません。上の 1 分と 3 分は RFC の推奨値であって、手元の機器が実際にその間隔で送っていることを確かめたものではありません。
5. 本ラボの構成
ここから実機に移ります。構成は Catalyst 9000v 2 台と端末 2 台です。
| ノード | 役割 | RLOC (Loopback0) | underlay | 収容する端末 |
|---|---|---|---|---|
| SW1 | control plane node + border + fabric edge | 10.255.0.1 | 10.0.0.1/30 | PC1 192.168.10.11（VLAN 10） |
| SW2 | fabric edge | 10.255.0.2 | 10.0.0.2/30 | PC2 192.168.20.12（VLAN 20） |
SW1 に付けた border という役割は名目上のものです。外部ネットワークへのハンドオフ（BGP と VRF-lite）は組んでいないため、本節の実測に border 固有の挙動は含まれません。
instance-id は 3 本です。
| instance-id | 種別 | 対応づけ | 用途 |
|---|---|---|---|
| 4097 | L3 VNI | VRF VN_LAB | VLAN をまたぐ通信。端末どうしはここを通る |
| 8197 | L2 VNI | VLAN 10 | 同じ VLAN の L2 延伸。MAC が EID になる |
| 8198 | L2 VNI | VLAN 20 | 同じ VLAN の L2 延伸。MAC が EID になる |
端末を別々の VLAN に置いてあることが、この構成の要点です。同じサブネットに置くと 2 台の通信が L2 VNI で橋渡しされてしまい、L3 VNI 側の解決が観測できません（これは着手前の予備ラボでの観測です。両端末を 192.168.10.0/24 に置いたとき、L3 VNI の map-cache は Negative cache entry のままでした）。分散エニーキャストゲートウェイが成立する条件は「両方の edge が同じゲートウェイを持つこと」であって、「端末が同じサブネットに居ること」ではないため、両方の VLAN の SVI を両方の edge に置けば主張は保たれます。
置いていないものと、その理由も先に挙げます。
| 置いていないもの | 理由 |
|---|---|
| Catalyst Center | CML にノード定義が存在しない |
| ISE | ノード定義はあるがイメージの実体が無い |
| spine / 専用 border / intermediate node | Catalyst 9000v の UADP 定義は 1 台あたり 4 vCPU・18 GB を要求し、2 台で CML の資源を使い切る |
| fabric wireless（AP / WLC） | 同じく資源の天井 |
機種と版を確かめます。
SW1# show version
Cisco IOS XE Software, Version 17.15.03
Cisco IOS Software [IOSXE], Catalyst L3 Switch Software (CAT9K_IOSXE), Version 17.15.3, RELEASE SOFTWARE (fc1)
…ライセンスの階梯です。
SW1# show license summary
…
network-advantage (CAT9K_VIRTUAL Network ...) 1 IN USE
dna-advantage (CAT9K_VIRTUAL DNA Adva...) 1 IN USEこの機体は 17.15.03 です。設定手順の出典は 17.9.x、コマンド仕様の出典は 17.16.x なので、3 つが別々の版になります。この差が実際に観測面へ出た箇所は §16 で扱います。
6. underlay — RLOC が届くことが前提
ファブリックの設定を書く前に、Loopback どうしが IP で届く状態を作ります。設定ガイドは前提条件としてこう書いています。
All fabric nodes must have a Loopback interface with an IPv4 address.
We recommend that the /32 routes of these Loopbacks be propagated by the underlay Interior Gateway Protocol (IGP) throughout the fabric site (without summarization). This is important to quickly detect the fabric edges that are going down.
Ensure that there is IP reachability between all fabric nodes.
本ラボは OSPF (Open Shortest Path First) で Loopback0 を配ります。隣接が Full になりました。
SW1# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.255.0.2 0 FULL/ - 00:00:39 10.0.0.2 GigabitEthernet1/0/1対向の RLOC が経路表に入ります。
SW1# show ip route 10.255.0.2
Routing entry for 10.255.0.2/32
Known via "ospf 1", distance 110, metric 2, type intra area
Last update from 10.0.0.2 on GigabitEthernet1/0/1, 00:01:10 ago
Routing Descriptor Blocks:
* 10.0.0.2, from 10.255.0.2, 00:01:10 ago, via GigabitEthernet1/0/1
Route metric is 2, traffic share count is 1転送表にも入ります。
SW1# show ip cef 10.255.0.2
10.255.0.2/32
nexthop 10.0.0.2 GigabitEthernet1/0/1順序に意味があります。LISP のセッションは RLOC への到達性の上に張られるので、show lisp session の数字を読む前に、この 3 つが揃っていることを確かめる必要があります。ここが揃っていないときにセッションが立たないのは、制御プレーンの問題ではなく到達性の問題です。
7. LISP の土台 — locator-set と service
まず router lisp の直下に、自分の RLOC と、アドレスファミリごとの動作を書きます。
SW1(config)#router lisp
SW1(config-router-lisp)# locator-table default
SW1(config-router-lisp)# locator-set rloc_set
SW1(config-router-lisp-locator-set)# IPv4-interface Loopback0 priority 10 weight 10
SW1(config-router-lisp-locator-set)# exit-locator-setlocator-set は「自分がどの RLOC として名乗るか」の宣言です。priority と weight は、同じ EID に複数の RLOC が対応するときの選択に使われます。
次に IPv4 のサービスを定義します。
SW1(config-router-lisp)# service ipv4
SW1(config-lisp-srv-ipv4)# encapsulation vxlan
SW1(config-lisp-srv-ipv4)# itr map-resolver 10.255.0.1
SW1(config-lisp-srv-ipv4)# etr map-server 10.255.0.1 key 0 lisplab
SW1(config-lisp-srv-ipv4)# etr map-server 10.255.0.1 proxy-reply
SW1(config-lisp-srv-ipv4)# itr
SW1(config-lisp-srv-ipv4)# etr
SW1(config-lisp-srv-ipv4)# sgt
SW1(config-lisp-srv-ipv4)# exit-service-ipv4encapsulation vxlan がここに現れます。6-5 で nve1 に書いたカプセル化が、LISP では service の属性として現れます。データプレーンは同じ VXLAN で、それを誰が制御するかだけが違うことが、設定の形にそのまま出ています。
itr map-resolver は問い合わせ先、etr map-server は登録先です。proxy-reply は、ETR に代わって map-server が Map-Reply を返す指定です。
Configures a map server to be used by the Egress Tunnel Router (ETR), and specifies that the map server answers the map-requests on behalf the ETR.
MAC を EID として扱う側も同じ形で定義します。
SW1(config-router-lisp)# service ethernet
SW1(config-lisp-srv-eth)# itr map-resolver 10.255.0.1
SW1(config-lisp-srv-eth)# etr map-server 10.255.0.1 key 0 lisplab
SW1(config-lisp-srv-eth)# etr map-server 10.255.0.1 proxy-reply
SW1(config-lisp-srv-eth)# itr
SW1(config-lisp-srv-eth)# etr
SW1(config-lisp-srv-eth)# exit-service-ethernet
SW1(config-router-lisp)# ipv4 source-locator Loopback0
SW1(config-router-lisp)# exit-router-lispこの土台の上に §9 の instance-id と eid-table を載せると、次のような論理インタフェースが現れます。以下の 2 つの出力は §9 まで設定した後に撮ったものです。§7 の段階で撮った capture には show が 1 本も含まれていません。
SW1# show lisp service ipv4 summary
…
Interface DB DB no Cache Incom Cache
EID VRF name (.IID) size route size plete Idle Role
VN_LAB LISP0.4097 5 0 4 0.0% 0.0% ITR-ETR
…LISP0.4097 が instance-id 4097 に対応する論理インタフェースで、Role は ITR-ETR です。インタフェース一覧にも現れます。
SW1# show ip interface brief | include LISP
L2LISP0 10.255.0.1 YES unset up up
L2LISP0.8197 10.255.0.1 YES unset up up
L2LISP0.8198 10.255.0.1 YES unset up up
LISP0 unassigned YES unset up up
LISP0.4097 192.168.20.1 YES unset up upLISP0 が L3 VNI 側、L2LISP0 が L2 VNI 側です。6-5 で 1 つの nve1 の下に VNI が並んだのに対し、LISP では instance-id ごとに論理インタフェースが生成されます。なお sgt は SGT をこのアドレスファミリで伝搬させる指定で、既定では伝搬しません。
SGT information is not propagated.
8. control plane node を建てる
ここまでの §7 の設定は、2 台に同じ内容を入れてあります。SW1 にはさらに、マッピングシステムそのものを載せます。
SW1(config)#router lisp
SW1(config-router-lisp)# service ipv4
SW1(config-lisp-srv-ipv4)# map-server
SW1(config-lisp-srv-ipv4)# map-resolver
SW1(config-lisp-srv-ipv4)# exit-service-ipv4
SW1(config-router-lisp)# service ethernet
SW1(config-lisp-srv-eth)# map-server
SW1(config-lisp-srv-eth)# map-resolver
SW1(config-lisp-srv-eth)# exit-service-ethernetmap-server と map-resolver を同じアドレスファミリの下に書くだけで、RFC が別々に定義した 2 つの役割が 1 台に載ります。
次に、受け入れる登録の範囲を宣言します。
SW1(config-router-lisp)# site LAB_SITE
SW1(config-router-lisp-site)# description fabric site for the guide lab
SW1(config-router-lisp-site)# authentication-key 0 lisplab
SW1(config-router-lisp-site)# eid-record instance-id 4097 192.168.10.0/24 accept-more-specifics
SW1(config-router-lisp-site)# eid-record instance-id 8197 any-mac
SW1(config-router-lisp-site)# eid-record instance-id 4097 192.168.20.0/24 accept-more-specifics
SW1(config-router-lisp-site)# eid-record instance-id 8198 any-mac
SW1(config-router-lisp-site)# exiteid-record は、edge から送られてくる Map-Register のうちどのプレフィクスを受け入れるかの定義です。
Use this command to configure the EID prefixes that are allowed in a map-register message sent by the edge device when registering with the control plane node.
accept-more-specifics を付けることで、宣言した /24 の中にある個々の /32 の登録を受け入れます。any-mac は L2 VNI 側で、どの MAC でも受け入れるという意味です。authentication-key は edge 側の etr map-server … key と一致している必要があります（lisplab は本ラボ限りの値です）。この共有鍵は検証ラボ専用の使い捨て値で、本番のファブリックでは鍵を平文のまま記事や設定の控えに残す運用はしません。
制御セッションの状態を見ます。control plane node を載せた SW1 側です。
SW1# show lisp session established
Sessions for VRF default, total: 5, established: 3
Peer State Up/Down In/Out Users
10.255.0.1:4342 Up 00:10:57 23/17 8
10.255.0.1:32579 Up 00:10:56 17/23 6
10.255.0.2:34107 Up 00:07:55 14/20 6edge だけの SW2 側です。
SW2# show lisp session established
Sessions for VRF default, total: 1, established: 1
Peer State Up/Down In/Out Users
10.255.0.1:4342 Up 00:09:52 20/14 8SW2 が張っている相手は 1 つだけで、その相手は SW1 です。ただしこの表示が示すのは reliable transport セッションであって、LISP の制御通信の相手一覧ではありません。設定ガイドは show lisp session を次のように定義しています。
To display the current list of reliable transport sessions in the fabric, use the show lisp session command in the privileged EXEC mode.
登録に使うセッションの相手が control plane node である、という限定で読みます。edge のあいだにまったく制御通信が無いわけではなく、RLOC の到達性を確かめる probe は 対向 edge の RLOC へ直接飛びます（§4・§11）。SW1 側で 3 本になっているのは、Peer の列に自分自身の RLOC 10.255.0.1 が 2 つと、SW2 の RLOC 10.255.0.2 が 1 つ並ぶためです。control plane node を同じ装置に同居させている構成が、そのままセッションの数に出ています。一方で total の 5 と established の 3 の差、つまり残り 2 の内訳は、手元の capture のどこにも印字されていません（§18）。
9. fabric edge と分散エニーキャストゲートウェイ
端末を収容する側を作ります。まず overlay の VRF (Virtual Routing and Forwarding) です。
SW1(config)#vrf definition VN_LAB
SW1(config-vrf)# rd 1:4097
SW1(config-vrf)# address-family ipv4
SW1(config-vrf-af)# route-target export 1:4097
SW1(config-vrf-af)# route-target import 1:4097
SW1(config-vrf-af)# exit-address-family
SW1(config-vrf)# exitこの VRF を L3 VNI に結びつけ、端末のサブネットを dynamic-EID として宣言します。
SW1(config)#router lisp
SW1(config-router-lisp)# instance-id 4097
SW1(config-lisp-inst)# remote-rloc-probe on-route-change
SW1(config-lisp-inst)# dynamic-eid LAB_Vlan10-IPV4
SW1(config-lisp-inst-dyn-eid)# database-mapping 192.168.10.0/24 locator-set rloc_set
SW1(config-lisp-inst-dyn-eid)# exit-dynamic-eid
SW1(config-lisp-inst)# dynamic-eid LAB_Vlan20-IPV4
SW1(config-lisp-inst-dyn-eid)# database-mapping 192.168.20.0/24 locator-set rloc_set
SW1(config-lisp-inst-dyn-eid)# exit-dynamic-eid
SW1(config-lisp-inst)# service ipv4
SW1(config-lisp-inst-srv-ipv4)# eid-table vrf VN_LAB
SW1(config-lisp-inst-srv-ipv4)# map-cache-limit 2000
SW1(config-lisp-inst-srv-ipv4)# exit-service-ipv4
SW1(config-lisp-inst)# exit-instance-iddynamic-eid は、そのサブネットに現れた端末を EID として扱うための定義です。
Creates a dynamic Endpoint Identifier (EID) policy and enters the dynamic-eid configuration mode on the fabric edge node.
To configure LISP host mobility, you must create a dynamic-eid policy that can be referenced by the lisp mobility dynamic-eid-name interface command.
名前が一致していることが条件です。router lisp の下の dynamic-eid LAB_Vlan10-IPV4 と、あとで SVI に書く lisp mobility LAB_Vlan10-IPV4 は、同じ文字列で結ばれます。
L2 VNI 側は VLAN に結びつけます。
SW1(config-router-lisp)# instance-id 8197
SW1(config-lisp-inst)# remote-rloc-probe on-route-change
SW1(config-lisp-inst)# service ethernet
SW1(config-lisp-inst-srv-eth)# eid-table vlan 10
SW1(config-lisp-inst-srv-eth)# database-mapping mac locator-set rloc_set
SW1(config-lisp-inst-srv-eth)# exit-service-ethernet
SW1(config-lisp-inst)# exit-instance-id
SW1(config-router-lisp)# instance-id 8198
SW1(config-lisp-inst)# remote-rloc-probe on-route-change
SW1(config-lisp-inst)# service ethernet
SW1(config-lisp-inst-srv-eth)# eid-table vlan 20
SW1(config-lisp-inst-srv-eth)# database-mapping mac locator-set rloc_set
SW1(config-lisp-inst-srv-eth)# exit-service-ethernet
SW1(config-lisp-inst)# exit-instance-id
SW1(config-router-lisp)# exit-router-lispそしてゲートウェイです。
SW1(config)#interface Vlan10
SW1(config-if)# description anycast gateway for VLAN 10 - same IP and MAC on both edges
SW1(config-if)# vrf forwarding VN_LAB
SW1(config-if)# ip address 192.168.10.1 255.255.255.0
SW1(config-if)# ip address 192.168.10.251 255.255.255.0 secondary
SW1(config-if)# mac-address 0000.0c9f.f001
SW1(config-if)# no lisp mobility liveness test
SW1(config-if)# lisp mobility LAB_Vlan10-IPV4
SW1(config-if)# no autostate
SW1(config-if)# no shutdown
SW1(config-if)# exitno autostate は、アクセスポートが落ちても SVI を down させないための指定です。ファブリックのゲートウェイは端末の有無と無関係に立っている必要があります。
この SVI を、もう 1 台の edge にも同じ IP と同じ MAC で置きます。CVD の定義です。
Anycast Layer 3 gateway: A common gateway (IP and MAC addresses) is used at every edge node that shares a common EID subnet, providing optimal forwarding and mobility across different RLOCs. On edge nodes, the anycast Layer 3 gateway is instantiated as a switched virtual interface (SVI) with a hard-coded MAC address that is uniform across all edge nodes within a fabric site.
Configure the same MAC address for a given SVI on all the fabric edge nodes.
実機で並べます。SW1 側です。
SW1# show running-config interface Vlan10
…
interface Vlan10
description anycast gateway for VLAN 10 - same IP and MAC on both edges
mac-address 0000.0c9f.f001
vrf forwarding VN_LAB
ip address 192.168.10.251 255.255.255.0 secondary
ip address 192.168.10.1 255.255.255.0
no lisp mobility liveness test
lisp mobility LAB_Vlan10-IPV4
no autostate
endSW2 側です。
SW2# show running-config interface Vlan10
…
interface Vlan10
description anycast gateway for VLAN 10 - same IP and MAC on both edges
mac-address 0000.0c9f.f001
vrf forwarding VN_LAB
ip address 192.168.10.252 255.255.255.0 secondary
ip address 192.168.10.1 255.255.255.0
no lisp mobility liveness test
lisp mobility LAB_Vlan10-IPV4
no autostate
endip address 192.168.10.1 と mac-address 0000.0c9f.f001 が 2 台に同じ値で在ります。端末はどちらの edge に繋がっても、同じ IP と同じ MAC のゲートウェイを見ます。違うのは secondary の 1 行だけで、こちらは SW1 が .251、SW2 が .252 という機体固有のアドレスです。これは anycast ではありません。後の MTU 測定で送信元として使うために置いてあります。anycast のアドレスを送信元にすると、応答が対向側で終端されて返ってきません。
なお MAC の値については、設定ガイドが範囲を推奨しています。
We recommend that you use a MAC address starting from the base range value of 0000.0C9F.F05F.
本ラボはこの推奨より前の値（0000.0c9f.f001 と 0000.0c9f.f002）を使っています。2 台で一致していることは満たしていますが、推奨範囲そのものには従っていません。
ゲートウェイのアドレスが登録の対象になるかどうかは、登録テーブルの側から見えます。
SW1# show lisp instance-id 4097 ipv4 database
LISP ETR IPv4 Mapping Database for LISP 0 EID-table vrf VN_LAB (IID 4097), LSBs: 0x1
Entries total 5, no-route 0, inactive 0, do-not-register 4
192.168.10.1/32, dynamic-eid LAB_Vlan10-IPV4, do not register, inherited from default locator-set rloc_set
…
10.255.0.1 10/10 cfg-intf site-self, reachable
192.168.10.11/32, dynamic-eid LAB_Vlan10-IPV4, inherited from default locator-set rloc_set
…
10.255.0.1 10/10 cfg-intf site-self, reachable
192.168.10.251/32, dynamic-eid LAB_Vlan10-IPV4, do not register, inherited from default locator-set rloc_set
…
10.255.0.1 10/10 cfg-intf site-self, reachable
…do not register が付いているのは、装置自身の SVI が持つアドレスです。anycast の 192.168.10.1/32 だけでなく、SW1 固有の secondary である 192.168.10.251/32 にも同じ印が付いています。冒頭の do-not-register 4 は、VLAN 10 と VLAN 20 の SVI アドレス 4 つを数えた値で、登録される /32 はこの出力では端末の 192.168.10.11/32 の 1 件だけです。
したがって、登録される側とされない側を分けているのは anycast かどうかではなく、そのアドレスが装置自身のものかどうかです。anycast のゲートウェイアドレスは、その集合にたまたま含まれています。§10 で見る show device-tracking database が L の行と ARP の行を分けているのは、同じ区別を端末検出の側から見たものになります。
10. 登録 — 誰がどこに居るかを預ける
control plane node の登録テーブルを見ます。
SW1# show lisp instance-id 4097 ipv4 server
LISP Site Registration Information
* = Some locators are down or unreachable
# = Some registrations are sourced by reliable transport
Site Name Last Up Who Last Inst EID Prefix
Register Registered ID
LAB_SITE never no -- 4097 192.168.10.0/24
00:10:45 yes# 10.255.0.1:32579 4097 192.168.10.11/32
never no -- 4097 192.168.20.0/24
00:07:27 yes# 10.255.0.2:34107 4097 192.168.20.12/32読み方が 2 つあります。
1 つ目。端末 2 台が /32 の EID として、自分が繋がっている edge の RLOC から登録されています。192.168.10.11/32 は 10.255.0.1（SW1）から、192.168.20.12/32 は 10.255.0.2（SW2）からです。Who Last Registered の列が、そのまま「どこに在るか」の答えになります。
2 つ目。/24 の 2 行が never なのは、設定した eid-record だからです。登録されていないのではありません。eid-record は「この範囲の登録を受け入れる」という宣言なので、それ自体は誰からも登録されません。ここを「登録が失敗している」と読むと、ファブリックが動いているのに壊れていると判断することになります。
MAC 側も同じ形です。
SW1# show lisp instance-id 8197 ethernet server
LISP Site Registration Information
* = Some locators are down or unreachable
# = Some registrations are sourced by reliable transport
Site Name Last Up Who Last Inst EID Prefix
Register Registered ID
LAB_SITE never no -- 8197 any-mac
00:11:30 yes# 10.255.0.1:32579 8197 5254.004c.332e/48L2 VNI では MAC アドレスが /48 の EID になります。ここでも any-mac の行は never で、実際の MAC が 1 件登録されています。
SVI の lisp mobility は、装置の端末検出機能が見つけたアドレスを dynamic-EID として拾い、それが登録になります。本ラボの端末は起動時から通信を出し続けているため、通信を出さなかった場合との対照は撮っていません（§18）。
SW1# show device-tracking database
Network Layer Address Link Layer Address Interface vlan prlvl age state Time left
…
L 192.168.10.251 0000.0c9f.f001 Vl10 10 0100 11mn REACHABLE
ARP 192.168.10.11 5254.004c.332e Gi1/0/2 10 0005 30s REACHABLE 211 s
L 192.168.10.1 0000.0c9f.f001 Vl10 10 0100 11mn REACHABLE
…ARP で始まる行が、アクセスポート Gi1/0/2 に現れた端末です。L で始まる行は装置自身の SVI のアドレスで、こちらは先ほどの do not register に対応します。
本ラボは端末に一度もログインしていません。端末は起動時から背景で ping を出し続けるだけの設定で、それが ARP を発生させ、装置がそれを検出して登録に至っています。
登録先は control plane node だけです。同じコマンドを edge だけの SW2 で打つと、表題しか返りません。
SW2# show lisp instance-id 4097 ipv4 server
LISP Site Registration Information空であることは機器の不調ではありません。SW2 は map-server ではないので、保持する登録がありません。
11. 解決 — 消して、引き直す
ここからが本節の中心です。リモートの端末がどこに居るかは、経路ではなくキャッシュとして持たれます。
先に断っておきます。本ラボの端末は起動時から通信を出し続けているため、LISP が立ち上がった時点ですでに解決済みでした。したがって「設定しただけでは未解決」という前後の対は、本ラボでは撮れていません。代わりに、解決済みのものを明示的に消して、引き直されるまでを 3 点で撮ります。
消す前です。
SW1# show lisp instance-id 4097 ipv4 map-cache
LISP IPv4 Mapping Cache for LISP 0 EID-table vrf VN_LAB (IID 4097), 4 entries
0.0.0.0/0, uptime: 00:00:01, expires: 00:00:59, via static-send-map-request
Negative cache entry, action: send-map-request
192.168.10.0/24, uptime: 00:15:50, expires: never, via dynamic-EID, send-map-request
Negative cache entry, action: send-map-request
192.168.20.0/24, uptime: 00:15:50, expires: never, via dynamic-EID, send-map-request
Negative cache entry, action: send-map-request
192.168.20.12/32, uptime: 00:11:14, expires: 23:48:45, via map-reply, complete
Locator Uptime State Pri/Wgt Encap-IID
10.255.0.2 00:11:14 up 10/10 -192.168.20.12/32 が via map-reply, complete として載り、Locator が 10.255.0.2、つまり SW2 です。この宛先へ送るパケットは、その RLOC 宛に VXLAN で包まれて出ます。
消します。
SW1# clear lisp instance-id 4097 ipv4 map-cache待たずに撮った直後の状態です。
SW1# show lisp instance-id 4097 ipv4 map-cache
LISP IPv4 Mapping Cache for LISP 0 EID-table vrf VN_LAB (IID 4097), 3 entries
0.0.0.0/0, uptime: 00:00:05, expires: 00:00:07, via static-send-map-request
Negative cache entry, action: send-map-request
192.168.10.0/24, uptime: 00:00:05, expires: never, via Transient away entry?, tentative
192.168.20.0/24, uptime: 00:00:05, expires: never, via Transient away entry?, tentative192.168.20.12/32 の行が消えています。解決済みの /32 が消え、dynamic-EID として設定した 2 つの /24 が tentative で残った状態です。宛先側にあたる 192.168.20.0/24 を、該当の EID を指定してより詳しく出します。
SW1# show lisp instance-id 4097 ipv4 map-cache 192.168.20.12
LISP IPv4 Mapping Cache for LISP 0 EID-table vrf VN_LAB (IID 4097), 1 entries
192.168.20.0/24, uptime: 00:00:11, expires: never, via Transient away entry?, tentative
Sources: Transient away entry
State: tentative, last modified: 00:00:11, map-source: local
Exempt, Packets out: 1(576 bytes), counters are not accurate (~ 00:00:05 ago)
Configured as EID address space
Configured as dynamic-EID address space
Encapsulating dynamic-EID trafficmap-source が local です。ここで確認できるのは、対象端末の /32 の解決済みマッピングが消え、設定してある dynamic-EID の範囲にあたる /24 の項目が残っていること、までになります。
この /24 の項目に「サブネットが自分の外に在る」という意味は付けられません。clear 直後の一覧には 192.168.10.0/24 も同じ tentative で並んでおり、そちらは PC1 が居るローカル側です。本節の構成は同じ EID サブネットを両方の edge に置く分散エニーキャストゲートウェイなので（§9）、サブネット単位で内と外を分けること自体ができません。
clear のあと待ってから撮った状態です。この待ちは取得スクリプトが置いた 30 秒で、段階ごとの時刻は capture に残っていません（capture のヘッダに在るのは取得を始めた時刻 1 個だけです）。
SW1# show lisp instance-id 4097 ipv4 map-cache 192.168.20.12
LISP IPv4 Mapping Cache for LISP 0 EID-table vrf VN_LAB (IID 4097), 1 entries
192.168.20.12/32, uptime: 00:00:37, expires: 23:59:22, via map-reply, complete
Sources: map-reply
State: complete, last modified: 00:00:37, map-source: 10.255.0.2
Active, Packets out: 0(0 bytes), counters are not accurate
Encapsulating dynamic-EID traffic
Locator Uptime State Pri/Wgt Encap-IID
10.255.0.2 00:00:37 up 10/10 -
Last up-down state change: 00:00:37, state change count: 1
Last route reachability change: 00:00:37, state change count: 1
Last priority / weight change: never/never
RLOC-probing loc-status algorithm:
Last RLOC-probe sent: 00:00:37 (rtt 67ms)via map-reply, complete に戻り、map-source が 10.255.0.2 になっています。Locator の行も同じ 10.255.0.2 です。
ただし、この map-source が何を指すのかは本節では確定できません。本節が取得した Cisco の資料には出力例が載っているだけで、フィールドの説明表がありません。応答した装置を指すという読み方は、本ラボの構成と合いません。両機の service ipv4 と service ethernet には etr map-server 10.255.0.1 proxy-reply が入っており（§7）、資料はこの指定を「map server answers the map-requests on behalf the ETR」と説明しています。応答者の意味であれば印字は map-server の RLOC 10.255.0.1 になるはずで、実際の印字 10.255.0.2 と合いません。さらに同じ出力の clear 直後の項目は map-source: local で、これも応答者としては読めません。書けるのは「解決済みの項目には map-source: 10.255.0.2、途中の項目には map-source: local と印字される」ところまでです（§18）。
3 点を並べると次のとおりです。
| いつ | 該当 EID の状態 | map-source |
|---|---|---|
| 消す前 | 192.168.20.12/32 が via map-reply, complete | （Locator 10.255.0.2） |
clear の直後 | /32 が消え、/24 が tentative | local |
| 30 秒待った後 | 192.168.20.12/32 が via map-reply, complete | 10.255.0.2 |
これが「消せる」ことの意味です。経路であれば、消しても配信元から再び配られます。キャッシュは消せて、次に必要になったときに問い合わせが出ます。
L2 VNI 側の map-cache にも、同じ書式で項目が載ります。
SW1# show lisp instance-id 8197 ethernet map-cache
LISP MAC Mapping Cache for LISP 0 EID-table Vlan 10 (IID 8197), 1 entries
5254.004c.332e/48, uptime: 00:16:02, expires: 23:43:57, via map-reply, complete
Locator Uptime State Pri/Wgt Encap-IID
10.255.0.1 00:16:02 up, self 10/10 -up, self と出ているのは、この MAC が自分の配下に居るためです。本ラボは 1 つの VLAN に端末を 1 台ずつしか置いていないので、対向の edge の配下に居る MAC を L2 VNI 越しに解決するところは撮れていません（§18）。
12. 経路表に載るもの、載らないもの
overlay の VRF の経路表を見ます。
SW1# show ip route vrf VN_LAB
Routing Table: VN_LAB
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
…
o - ODR, P - periodic downloaded static route, l - LISP
…
192.168.10.0/24 is variably subnetted, 4 subnets, 2 masks
C 192.168.10.0/24 is directly connected, Vlan10
L 192.168.10.1/32 is directly connected, Vlan10
l 192.168.10.11/32 [10/1] via 192.168.10.11, 00:11:49, Vlan10
L 192.168.10.251/32 is directly connected, Vlan10
192.168.20.0/24 is variably subnetted, 3 subnets, 2 masks
C 192.168.20.0/24 is directly connected, Vlan20
L 192.168.20.1/32 is directly connected, Vlan20
L 192.168.20.251/32 is directly connected, Vlan20読者は第 4 章から show ip route の凡例に l - LISP を見てきました。その記号の実体がこれです。ローカルに居る端末 192.168.10.11/32 が l の経路として載っています。
そしてリモートの端末 192.168.20.12/32 は、この表に載りません。居場所は map-cache にあります。
| 端末 | どこに現れるか |
|---|---|
| ローカルの端末（192.168.10.11） | VRF の経路表に l の経路として |
| リモートの端末（192.168.20.12） | map-cache に via map-reply, complete として |
不在は失敗ではなく機構です。リモートのすべてのエンドポイントを経路表に持たないことが、conversational learning の帰結になります。
自分のサブネット側の map-cache を見ると、内容が違うことも分かります。
SW1# show lisp instance-id 4097 ipv4 map-cache 192.168.10.11
LISP IPv4 Mapping Cache for LISP 0 EID-table vrf VN_LAB (IID 4097), 1 entries
192.168.10.0/24, uptime: 00:13:16, expires: never, via dynamic-EID, send-map-request
Sources: NONE
State: send-map-request, last modified: 00:13:16, map-source: local
Exempt, Packets out: 5(2880 bytes), counters are not accurate (~ 00:11:15 ago)
Configured as EID address space
Configured as dynamic-EID address space
Encapsulating dynamic-EID traffic
Negative cache entry, action: send-map-requestNegative cache entry は「解決に失敗した」という意味ではありません。この項目は Sources: NONE / map-source: local / via dynamic-EID と印字されており、Map-Reply から作られたものではなく、ローカルの dynamic-EID 設定から生まれた項目です。並んでいる action: send-map-request が意味するのは、RFC 9301 が Map-Reply の action bits で (2) Send-Map-Request として定義しているのと同じ振る舞いです。定義の前半はこうです。
The Map-Cache entry is created and flagged
続く後半が本体で、この項目に一致したパケットが Map-Request を送らせる、という内容です。問い合わせない印ではなく、このプレフィクスに一致する未解決の宛先へ通信が出たら、そのとき問い合わせが出るという待機の状態になります。印字されている値が RFC の action 値そのものであるかどうかは、本節が取得した資料では確かめていません。§11 の「消す前」の出力で 192.168.10.0/24 と 192.168.20.0/24 が同じ形で載っていたのも、この待機の項目です。
13. MTU — 推奨 9100 と手元の 1450
6-5 で測ったのと同じ話が、同じデータプレーンの上でもう一度出ます。VXLAN のオーバーヘッドについて、CVD は下限つきで書いています。
Any encapsulation method is going to create additional MTU (Maximum Transmission Unit) overhead on the original packet. As shown in Figure 1, VXLAN encapsulation uses a User Datagram Protocol (UDP) transport. Along with the VXLAN and UDP headers used to encapsulate the original packet, an outer IP and Ethernet header are necessary to forward the packet across the wire. At a minimum, these extra headers add 50 bytes of overhead to the original packet.
推奨値と範囲です。
VXLAN adds 50 bytes to the original packet. The common denominator and recommended MTU value available on devices operating in a fabric role is 9100. Networks should have a minimum starting MTU of at least 1550 bytes to support the fabric overlay. MTU values between 1550 and 9100 are supported, along with MTU values larger than 9100, although there may be additional configuration and limitations based on the original packet size.
設定ガイドは範囲を書かず、9100 という単値だけを推奨します。
All switches in the network including fabric edge, border, control plane, and intermediate nodes should support jumbo MTU. VXLAN header adds 50 bytes of encapsulation to a data packet that is sourced from an endpoint. We recommend an MTU of 9100 to support packet forwarding without fragmentation.
§13 と §14 の実測は 2 つのラボにまたがります。最初に組んだラボ（以下「初回ラボ」）の MTU 掃引は 1 巡だけで、結果が単調にならず境界の形をしていませんでした。そこで MTU 境界の測り直しと、§14 で扱う SGACL の対照の 2 件のために、同じ構成をもう一度組み直しました（以下「補強ラボ」）。2 つは別個の CML ラボの実体です。以下はブロックごとに、どちらのラボの出力かを示します。
この推奨値が、手元の機体では入りません（初回ラボ）。
SW1(config)#system mtu 9100
^
% Invalid input detected at '^' marker.caret が立っているのはコマンド名ではなく引数の側です。system mtu というコマンドが無いのではなく、9100 という値が受理されていません。ただし受理される値の上限がいくつなのかは、本ラボの capture に残していません（§18）。実値は 1500 のままです（初回ラボ）。
SW1# show system mtu
Global Ethernet MTU is 1500 bytes.そのうえで、トンネルの中を通る最大サイズを測ります。送信元は機体固有の 192.168.10.251 です。
まず補強ラボの 1450 バイトです。
SW1# ping vrf VN_LAB 192.168.20.12 source 192.168.10.251 repeat 5 size 1450 df-bit
Type escape sequence to abort.
Sending 5, 1450-byte ICMP Echos to 192.168.20.12, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.251
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 430/526/628 ms10 バイト増やします（補強ラボ）。
SW1# ping vrf VN_LAB 192.168.20.12 source 192.168.10.251 repeat 5 size 1460 df-bit
Type escape sequence to abort.
Sending 5, 1460-byte ICMP Echos to 192.168.20.12, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.251
Packet sent with the DF bit set
.....
Success rate is 0 percent (0/5)| 層 | 実測値 | 根拠 |
|---|---|---|
| underlay（物理側） | 1500 | Global Ethernet MTU is 1500 bytes. |
| overlay（トンネルの中） | 確認できた最大成功サイズ 1450 | 補強ラボで 1450 が 3 巡とも 100%、1460 が 3 巡とも 0% |
| 境界 | 1450 と 1460 のあいだ | 掃引は 10 バイト刻みで、1451〜1459 は測っていない |
仕様上のオーバーヘッド 50 バイトは、上の CVD と設定ガイドが書いている値です。実測が言えるのは、underlay が 1500 のもとで overlay を通った最大が 1450 であり、境界が 1450 と 1460 のあいだに在ることまでです。掃引は 10 バイト刻みなので、その内側の 1451 から 1459 は測っていません。本ラボは 50 の内訳も測っていません。パケットキャプチャを取得していないため、内訳の話は 6-5 と出典に譲ります。
測り方についても 1 つ断っておきます。この機体は beta イメージで、公式にデータプレーンのスループットが約 250 Kbps と明記されています。
Given that the switch is distributed in a BETA form, you may experience crashes, especially if you try to push too much traffic through the node. The dataplane throughput is limited to ~250 Kbps.
実際、サイズを増やしていない 100 バイトの ping でも、5 発のうち 1 発が落ちることがあります。以下は初回ラボの出力です。
SW1# ping vrf VN_LAB 192.168.20.12 source 192.168.10.251 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.12, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.251
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 77/91/107 msそのため補強ラボでは 9 サイズを 3 巡、昇順と降順を交互に測り直しました。結果は次のとおりです。
| サイズ（補強ラボ） | 3 巡の Success rate | 判定 |
|---|---|---|
| 1400 | 80% / 100% / 100% | 巡によって割れる。境界ではない |
| 1410〜1450 | 100% / 100% / 100% | 通る |
| 1460 / 1470 / 1500 | 0% / 0% / 0% | 通らない |
単発の Success rate を境界の根拠にはできません。初回ラボの 1 巡だけの掃引（こちらは repeat 3）では 1420 が 0% になりましたが、補強ラボで 3 巡測ると 1420 は 3 回とも 100% でした。単発の 0% は損失であって、境界ではありません。
なお、df-bit を外した 1500 バイトも通りません（補強ラボ）。
SW1# ping vrf VN_LAB 192.168.20.12 source 192.168.10.251 repeat 5 size 1500
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 192.168.20.12, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.251
.....
Success rate is 0 percent (0/5)断片化が許されているのだから通ってもよさそうですが、通りません。本ラボはこの理由を切り分けていません（§18）。
14. ポリシー面 — SGT / SGACL と VXLAN-GPO
SD-Access のポリシー面は Cisco TrustSec に基づきます。端末のグループを表す値を SGT (Security Group Tag)、グループ間の許可と拒否を書いたアクセスリストを SGACL (Security Group ACL) と呼びます。
Cisco TrustSec decouples access that is based strictly on IP addresses and VLANs by using logical groupings in a method known as Group-Based Access Control (GBAC). The goal of Cisco TrustSec technology is to assign an SGT value to the packet at its ingress to the network. An access policy is then enforced based on this tag information.
An SGT is a form of metadata. It is a 16-bit value assigned by Cisco ISE in an authorization policy when a user, device, or application connects to the network.
ISE の要否は、資料の系統によって書き方が違います。CVD は条件つきで必須と書きます。
Cisco ISE is optional for SD‑Access deployments that require only macro‑segmentation, but it becomes mandatory when identity‑based micro‑segmentation is required.
設定ガイドは任意と書きます。
Use of Identity Services Engine (ISE) for access control and policy enforcement is optional.
食い違っているのは条件の付け方です。CVD が必須と言っているのはアイデンティティに基づくマイクロセグメンテーション、つまり認証の結果で動的に SGT を配る形です。一方の設定ガイドは、条件を付けずに任意と書いています。この食い違いを「設定ガイドが念頭に置いているのは、VLAN から SGT への静的なマッピングの側だ」と読むのは本節の解釈であって、原典がその文脈を明示しているわけではありません。同じ設定ガイドの別の章には、静的なマッピングの手順が載っています。
This sample configuration shows how to manually map an SGT to VLANs and enforce the SGACL policy on the VLANs.
注意が 1 つあります。本節が以下で行う手動の SGACL 定義は、SD-Access の標準手順ではありません。公式の Group-based Policy の章は、静的なマッピングを使う手順であっても、その 1 行目に cts authorization list server-list を置いています。
Configures a AAA server to be used by the seed device.
つまり「ISE は任意」という記述は、認証サーバが要らないという意味ではありません。同じ章は、SGACL の中身そのものをローカルに定義する手順も載せていません。以下は ISE が無い学習環境での代替であって、実運用の手順ではありません。
ここでも実測は初回ラボと補強ラボにまたがります（§13）。補強ラボは §13 の MTU 境界の測り直しと、この SGACL の対照の 2 件のために組み直したもので、SGACL の側では送信元になる 192.168.10.251 も SGT 100 に明示的に分類してあります。ブロックごとに、どちらのラボの出力かを示します。
投入する設定です（補強ラボ）。VLAN 10 を SGT 100、VLAN 20 を SGT 200 とし、100 から 200 への ICMP を拒否します。最後の 1 行は補強ラボで足したもので、初回ラボには入っていません。
SW1(config)#cts role-based enforcement
SW1(config)#cts role-based enforcement vlan-list 10
SW1(config)#cts role-based sgt-map vlan-list 10 sgt 100
SW1(config)#cts role-based enforcement vlan-list 20
SW1(config)#cts role-based sgt-map vlan-list 20 sgt 200
SW1(config)#cts role-based sgt-map 192.168.10.11 sgt 100
SW1(config)#cts role-based sgt-map 192.168.20.12 sgt 200
SW1(config)#ip access-list role-based DENY_ICMP
SW1(config-rb-acl)# deny icmp
SW1(config-rb-acl)# exit
SW1(config)#cts role-based permissions from 100 to 200 DENY_ICMP
SW1(config)#cts role-based sgt-map 192.168.10.251 sgt 100同じ設定を SW2 にも入れます。バインディングを確認します（補強ラボ）。
SW1# show cts role-based sgt-map all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
192.168.10.11 100 CLI
192.168.10.251 100 CLI
192.168.20.12 200 CLI
IP-SGT Active Bindings Summary
============================================
Total number of CLI bindings = 3
Total number of active bindings = 3
…192.168.10.251 が並んでいるのは補強ラボだからです。初回ラボのバインディングは端末 2 台の 2 件で、スイッチ自身の secondary は分類していませんでした。
ポリシー表です（補強ラボ）。
SW1# show cts role-based permissions
IPv4 Role-based permissions from group 100 to group 200 (configured):
DENY_ICMP
RBACL Monitor All for Dynamic Policies : FALSE
RBACL Monitor All for Configured Policies : FALSE(configured) が、ローカルで定義したポリシーであることを示します。ISE から配られた動的なポリシーとは区別されます。
そして境界がここに出ます。以下は初回ラボの出力で、補強ラボでは show cts environment-data を撮っていません。
SW1# show cts environment-data
CTS Environment Data
====================
Current state = START
Last status = In Progress
Environment data is empty
State Machine is running
Retry_timer (60 secs) is not runningEnvironment data is empty は、ISE から受け取る environment data が空であることを示します。environment data は、装置が TrustSec のノードとして動くための運用情報です。TrustSec の設定ガイド（Catalyst 9300 / IOS XE 17.15.x）は中身を 3 つ挙げています。
Server lists: List of servers that the client can use for future RADIUS requests (for both authentication and authorization).
Device SG: Security group to which the device itself belongs.
Expiry timeout: Interval that controls how often the Cisco TrustSec device should refresh its environment data.
サーバの一覧、装置自身が属するセキュリティグループ、更新間隔の 3 つです。端末への動的な SGT 付与と SGACL の取得は、同じガイドが「Authorization and Policy Acquisition」として別に扱う経路になります。したがってこの表示から言えるのは、ISE から受け取る運用情報が空であるところまでで、動的な付与とポリシー配布が無いことまでは、この 1 行では確定しません。ローカルに定義した SGACL が成立しているかどうかは、次の実測が示します。
効いているかどうかを測ります。まず初回ラボで、入れる前の疎通です。
SW1# ping vrf VN_LAB 192.168.20.12 source 192.168.10.251 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.12, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.251
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 93/102/112 ms同じ ping は、SGACL を入れた後も 100% でした（初回ラボ）。
SW1# ping vrf VN_LAB 192.168.20.12 source 192.168.10.251 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.12, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.251
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 83/93/102 msつまりこの ping は、enforce の前後を分ける対照にはなっていません。落ちたのはこの通信ではありません。落ちているものはカウンタの側に現れます。同じ初回ラボで、送信元側 SW1 のカウンタです。
SW1# show cts role-based counters
Role-based IPv4 counters
From To SW-Denied HW-Denied SW-Permitt HW-Permitt SW-Monitor HW-Monitor
100 200 0 0 0 0 0 0100 200 の行は在りますが、すべて 0 です。ここで「効いていない」と結論すると測定点を取り違えます。同じ初回ラボの、宛先側の SW2 を見ます。
SW2# show cts role-based counters
Role-based IPv4 counters
From To SW-Denied HW-Denied SW-Permitt HW-Permitt SW-Monitor HW-Monitor
100 200 0 1 0 0 0 0HW-Denied が 0 ではありません。SGACL は宛先側の edge で効きます。
出典もこれを一般則として書いています。
Cisco TrustSec uses ingress tagging and egress filtering to enforce access control policy in a scalable manner.
ただし同じ資料は例外も併記しています。宛先のグループが分かる装置であれば、出口側でなくそこで適用されることもある、という記述です。
In some cases, ingress devices or other non-egress devices might have destination group information available. In those cases, SGACLs might be applied in these devices rather than egress devices.
本ラボの実測が示すのは、この構成で落ちているのが宛先側の SW2 だということまでです。どの装置で適用されるかは宛先グループの情報がどこまで届いているかで変わる、と出典は書いています。
ここまでの実測ブロックは初回ラボの出力で、この 1 も初回ラボの値です。落ち続けていることを確かめるため、補強ラボで適用前と適用後を対照にして測り直しました。以下の表は補強ラボの値です。適用前は 100 200 の行がそもそも存在しません。ポリシーが無いので数える対象が無い状態です。適用後、宛先側 SW2 のカウンタは時間を置いた 3 回の読み取りで次のように伸びました。読み取りの間隔は、取得スクリプトの実行ログに残る時刻から約 72 秒と約 73 秒です。
| 撮影時点（補強ラボ） | SW2（宛先側）の HW-Denied | SW1（送信元側） |
|---|---|---|
| 適用前 | 行が存在しない | 行が存在しない |
| 1 回目 | 12 | 0 |
| 2 回目（1 回目の約 72 秒後） | 48 | 0 |
| 3 回目（1 回目の約 145 秒後） | 86 | 0 |
この間隔は capture のファイル自身からは読み取れません。capture には 1 回目（適用から約 0 秒） 2 回目（適用から約 30 秒） という見出しが並んでいますが、これは取得スクリプトが「30 秒待つ」という手続きから機械的に生成した文字列であって、観測した時刻ではありません。実際の手続きは、ping を 5 発打ち、2 台のカウンタを読み、そのあとで 30 秒待つ、という繰り返しです。待ち時間 30 秒の上に ping とコマンド応答の所要時間が乗るため、実行ログが記録した読み取り時刻は 16 時 48 分 55 秒・16 時 50 分 7 秒・16 時 51 分 20 秒となり、間隔は約 72 秒と約 73 秒でした。スクリプトが書いた値が、観測値の顔をして capture に残るという形になります。
1 回目も適用の直後ではありません。SW2 への SGACL 投入は、その capture のヘッダが記録する 16 時 47 分 18 秒に始まっています。起点は投入の開始時刻です。1 回目の読み取りはその約 97 秒後（実行ログの 16 時 48 分 55 秒）なので、1 回目からすでに 12 が立っているのはこのためです。投入の完了（16 時 47 分 57 秒）を起点に数えれば約 58 秒で、どちらを起点に置くかで数字が変わります。
増分は 36 と 38 で、SGT 100 から 200 へ向かうトラフィックが継続的に落ちています。このカウンタは SGT のペア単位の集計なので、どの送信元のパケットが落ちたかは印字されません。何が落ちていたのかは本ラボでは同定していません（§18）。ISE が居ないため、SGT のバインディングも SGACL のポリシー実体もすべてローカル定義です。
一方で、スイッチ自身が出す ping は落ちません。補強ラボは送信元 192.168.10.251 を明示的に SGT 100 に分類し、宛先側の SW2 にもそのバインディングが入っている状態でしたが、上の 3 回とも疎通は 100% でした。
なお本ラボは、このバインディングを VRF を指定せずに入れています。上の設定行にも show cts role-based sgt-map all の出力にも、VRF は現れていません。TrustSec の設定ガイドは、IP-SGT のバインディングが VRF ごとの表に入ると書いています。
The IP-SGT binding is entered into the IP-SGT table associated with the specified VRF and the IP protocol version implied by the type of IP address.
したがって、このバインディングが overlay の VN_LAB に効いていたかどうかは裏づけていません。本ラボはこの理由を切り分けていません（§18）。
SGT がどこに載って運ばれるかは、VXLAN ヘッダの側の話になります。CVD はこう書いています。
The SD-Access fabric uses the VXLAN data plane to provide transport of the full original Layer 2 frame and additionally uses LISP as the control plane to resolve endpoint-to-location (EID-to-RLOC) mappings. The SD-Access fabric replaces 16 of the reserved bits in the VXLAN header to transport up to 64,000 SGTs using a modified VXLAN-GPO (sometimes called VXLAN-GBP) format described in https://tools.ietf.org/html/draft-smith-vxlan-group-policy-04.
6-5 で扱った RFC 7348 の VXLAN ヘッダは 8 バイトで、そのうち多くのビットが予約でした。
- Flags (8 bits): where the I flag MUST be set to 1 for a valid VXLAN Network ID (VNI). The other 7 bits (designated “R”) are reserved fields and MUST be set to zero on transmission and ignored on receipt.
- Reserved fields (24 bits and 8 bits): MUST be set to zero on transmission and ignored on receipt.
SD-Access が使うのは、この「送信時ゼロ・受信時無視」と定められた領域です。draft-smith-vxlan-group-policy がビットを定義しています。
| ビット | 名前 | 意味 |
|---|---|---|
| bit 0 | G (Group Based Policy Extension) | 1 なら Group Policy ID を運んでいる |
| bit 9 | D (Don’t Learn) | 立っていれば出口の VTEP は送信元アドレスを学習してはならない |
| bit 12 | A (Policy Applied) | 1 ならポリシー適用済み。G=1 のときだけ A ビットとして定義される |
| bit 16〜31 | Group Policy ID | 送信元のグループ識別子（16 ビット） |
Group Policy ID: 16 bit identifier that indicates the source TSI Group membership being encapsulated by VXLAN. The allocation of Group Policy ID values is outside the scope of this document.
幅が 16 ビットである点が、CVD の言う SGT の 16 ビットと一致します。なお A ビットの定義が、先ほどの実測と整合します。
A = 0 indicates that the group policy has not been applied to this packet. Group policies MUST be applied by devices when the A bit is set to 0 and the destination Group has been determined. Devices that apply the Group policy MUST set the A bit to 1 after the policy has been applied.
宛先のグループが確定した装置が適用する、という形が draft に書かれています。本ラボで宛先側の edge にカウンタが立ったことは、この記述と矛盾しません。ただし本ラボはパケットキャプチャを取得していないので、ビットが実際にどう立っていたかは観測していません（§18）。
3 点、注意が要ります。1 つ目は、この draft が失効した Internet-Draft であることです。
This Internet-Draft will expire on April 25, 2019.
2 つ目は、CVD が参照しているのが -04、本節が取得した一次資料が -05 であることです。3 つ目は、Group Policy ID = SGT という対応づけが Cisco 側の資料にしか書かれていないことです。IETF 側の 4 文書に SGT という語は 1 度も出てきません。
なお、ファブリックの外に出るときは SGT の扱いが変わります。
With IP-based handoffs, SGT tags are not copied over from VXLAN to IP headers.
Policy mapping: A border node maps the SGT information from within the fabric to be appropriately maintained when the traffic exits that fabric. When a fabric packet is decapsulated at the border node, the SGT information can be directly mapped into the Cisco metadata field of packet, using inline tagging.
本ラボは border の外側を組んでいないため、この部分は出典のみです。
15. Catalyst Center は何を自動化するのか
6-5 の末尾が残した「手で書いた設定は誰に置き換えられるのか」に戻ります。CVD は SD-Access をこう定義します。
Cisco Software-Defined Access is driving the evolution from traditional campus network designs to networks that directly implement the intent of an organization. Running on Cisco Catalyst™ Center hardware, SD-Access is a software application that is used to automate wired and wireless campus networks.
SD-Access はファブリック技術の名前であると同時に、Catalyst Center の上で動くソフトウェアアプリケーションの名前でもあります。Catalyst Center が担う領域は 5 つです。
| 領域 | 内容（CVD） |
|---|---|
| Design | 階層・設定・DNS / DHCP・IP アドレス・サイトプロファイル・イメージ管理・テレメトリ |
| Policy | エンドポイントの分類、グループベースおよび IP ベースのアクセス制御、QoS |
| Provision | 装置の投入、Plug and Play と LAN Automation、ファブリックサイトの構築、仮想ネットワークと transit |
| Assurance | 設計どおりの体験になっているかの監視と可視化 |
| Platform | API による外部システム連携 |
Provision の中の一句が、6-5 の問いへの直接の答えになります。
Provision: Provisions devices and adds them to the managed inventory, supports Cisco Plug and Play and LAN Automation, builds fabric sites with SD-Access components including Zero Trust, establishes virtual networks and transits, and offers a catalog of network services.
そして CVD は、本節がここまでやってきたことを不要だとも書いています。
A full understanding of LISP and VXLAN is not required to deploy the fabric in SD-Access, nor is there a requirement to know the details of how to configure each individual network component and feature to create the consistent end-to-end behavior offered by SD-Access. Catalyst Center is an intuitive, centralized management system used to automate configuration and policy across the wired and wireless SD-Access network. It takes the user’s intent and programmatically applies it to network devices.
本節はこの「知らなくてよい」とされた層を開けて見せています。運用で毎回 CLI を書くべきだという主張ではありません。生成されるものが何であるかを知っていることが、動かないときに読む力になります。
自動化は underlay にも及びます。
LAN Automation handles the plug-and-play zero-touch automation of the underlay network for the SD-Access solution. The simplified procedure builds a solid, error-free underlay network foundation using the principles of a Layer 3 routed access design. The LAN Automation feature uses components from the Cisco Plug and Play (PnP) solution, where configuration of the underlay can be orchestrated and devices are automatically added to the Cisco Catalyst Center inventory. LAN Automation is an alternative to manual underlay deployments to onboard multiple switches with SWIM and best-practices configuration using an IS-IS routed access design.
本節の §6 で OSPF を手で組んだ部分が、ここでは IS-IS による自動化として扱われます。ただし全部が自動になるわけではありません。
Cisco LAN Automation in Catalyst Center deploys a Layer 3 underlay using IS-IS as the primary routing protocol. Border Gateway Protocol (BGP) integration occurs only on seed devices (primary and peer), where you preconfigure it manually for reachability.
境界はボーダーノードの手前で止まります。
Catalyst Center fully automates BGP, VRF-lite, and border handoff interface configurations on SD-Access border nodes. Configuration of the peer devices has to be handled by the network administrator.
The handoff on the border node can be automated through Cisco Catalyst Center, though the peer router is configured manually or by using templates.
同じ趣旨が CVD の 2 箇所で独立に書かれています。ファブリックの内側は自動化され、その外側で待っている装置は人間が設定します。
分量についても触れておきます。「Catalyst Center を使うと設定が何行から何行になる」という定量比較は、どの資料にも書かれていません。本節が取得した CVD を 7 通りの語で検索して 0 件でした。代わりに、CLI 側の設定ガイドの分量を本稿で数えました。以下は本稿の計数であって、Cisco が示した数値ではありません。
| 章 | Procedure 内の CLI ステップ数（本稿の計数） |
|---|---|
| Fabric in a Box | 198 |
| Border node | 158 |
| Edge node | 136 |
| Control plane node | 23 |
| TrustSec | 7 |
| 合計 | 522 |
Fabric in a Box の章に載っている完成コンフィグの例は 246 行あり（vrf definition VN3 の行から末尾の ! までを対象に、空行と空白だけの行を除いて本稿が数えた値）、その中の router lisp ブロックは 1 つ、配下の instance-id は 4 つでした。本ラボが手で入れた設定も、規模としては同じ order にあります。
以上をまとめると、6-5 が残した問いへの答えは次の形になります。
| 6-5 で手で書いたもの | 6-6 での置き換え先 | それを書く主体 |
|---|---|---|
nve1 によるカプセル化の定義 | router lisp 配下の encapsulation vxlan と instance-id | Catalyst Center が生成する |
l2vpn evpn による学習の配布 | LISP の登録（Map-Register）と解決（Map-Request / Map-Reply） | 同上 |
| VTEP どうしの BGP ピア | edge から control plane node への LISP セッション | 同上 |
置き換えているのは LISP の登録と解決であって、Catalyst Center ではありません。Catalyst Center はその設定を生成する層に立ちます。本ラボは、生成する層が無くても下の 2 層が成立することを実測で示しています。
16. 版ズレと beta であること
本節が使った資料と実機は、版が 3 つに分かれます。
| 種類 | 資料・実体 | 版 | 更新日 |
|---|---|---|---|
| 設定手順 | LISP VXLAN Fabric Configuration Guide | Cisco IOS XE Cupertino 17.9.x | 2023 年 8 月 1 日 |
| 実機 | 本ラボの Catalyst 9000v | 17.15.03 | — |
| コマンド仕様 | Command Reference（Catalyst 9300） | Cisco IOS XE 17.16.x | 2024 年 12 月 11 日 |
| 設計指針 | SD-Access Solution Design Guide (CVD) | Catalyst Center 2.3.7.10 / LISP Pub/Sub | 2026 年 7 月 30 日 |
手順書が実機より 6 マイナーリリース古く、コマンドリファレンスは 1 世代新しい状態です。機能の前提そのものは満たしています。
Ensure that all the Cisco Catalyst 9000 Series switches in the fabric operate Cisco IOS XE 17.9.3 or later releases.
These features are available in all the releases subsequent to the one they were introduced in, unless noted otherwise.
この版ズレが観測面に出た箇所が 1 つあります。17.9.x の手順書は登録状態の確認に show lisp site を使っていますが、事前の確認（本ラボとは別の予備ラボ・同じ 17.15.03）では、このコマンドに対して commands are deprecated. という誘導メッセージが返り、show lisp instance-id <0-16777200> ipv4/ipv6/ethernet server を使うよう案内されました。本節が §10 で show lisp instance-id 4097 ipv4 server を使っているのはこのためです。
ただし「非推奨」と明記した Cisco の文書は 1 件もありません。9 資料を複数の語で検索して 0 件でした。17.16 のコマンドリファレンスは show lisp site を単に収録していないだけで、廃止とは書いていません。書けるのは「手元の 17.15.03 がそう返した」までです（この観測は予備ラボのもので、§1 が挙げた 41 ファイルの外にあります）。なお、同じ用途を新しい形のコマンドで説明する記述は、17.16 のリファレンスに存在します。
To display the Location Identifier Separation Protocol (LISP) site registration information, use the show lisp instance-id ipv4 server command in privileged EXEC mode.
CML 側の資料にも版差があります。CML 2.5 のページは Catalyst 9000v の説明にこの一文を含んでいました。
The default, Doppler D dataplane, provides support for a Software-Defined Access fabric.
現行の 2.10 のページの同じ位置は、次のようになっています。
The Catalyst 9000 Virtual Switch is an IOS-XE-based layer2/layer3 switch that provides software-based dataplane emulation for UADP and Q200 chipsets. Nodes that are running the chipset can be managed in Cisco Catalyst Center.
SD-Access に触れた一文が消えています。ただし該当の段落は一文だけでなく段落ごと書き換わっており、チップ名も管理製品名も変わっています。書けるのは「この 2 つのページの間でこの文が落ちている」までで、撤回や非対応化とは書けません。
最後に、機種の話を 1 つ。本節が使ったのは Catalyst 9000v だけです。事前の確認では、CML 同梱の Catalyst 8000V（17.16.01a）をライセンス未適用の状態で起動すると、router lisp が % Invalid input detected at '^' marker. で拒否されました。ただしこれを「Catalyst 8000V は LISP 非対応」と一般化することはできません。言えるのは、手元のイメージとライセンス状態での観測までです。ルータ系の他のイメージは測っていません。
17. 落とし穴・補足
show lisp instance-id … ipv4 serverの/24の行がneverでも異常ではありません。それは設定したeid-recordの行で、登録される対象ではありません。登録は/32の行として現れます。- 同じコマンドを fabric edge で打つと表題しか出ません。登録データベースを持つのは control plane node だけです。空であることは不調ではありません。
- map-cache に
Negative cache entry, action: send-map-requestが載っているのは正常です。RFC 9301 の(2) Send-Map-Requestの定義では、この項目に一致したパケットが Map-Request を送らせます。問い合わせない印ではなく、一致する未解決の宛先が現れたときに問い合わせが出る、という待機の状態です。 clearの直後に出るtentativeから読み取れるのは、/32が消えて dynamic-EID の/24だけが残った、ということまでです。同じ出力にローカル側の192.168.10.0/24も同じ状態で並ぶので、「サブネットが自分の外に在る」という意味をtentativeに与えることはできません。- anycast のアドレスを ping の送信元にすると返ってきません。対向も同じアドレスを持つので応答が対向側で終端されます。本ラボが SVI に
secondaryを 1 つずつ足しているのはこのためです。6-5 で同じ現象を扱いました。 show cts role-based countersは宛先側の edge で読みます。送信元側が 0 でも enforce されていないという意味にはなりません。- SVI の MAC はファブリック内の全 edge で同じ値にします。設定ガイドは
0000.0C9F.F05F以降を推奨しますが、本ラボはそれより前の値を使っています。一致していることは満たしていますが、推奨範囲そのものには従っていません。 no autostateを忘れると、端末が繋がっていないあいだ SVI が down します。ファブリックのゲートウェイは端末の有無と無関係に立っている必要があります。dynamic-eidの名前とlisp mobilityの名前は同じ文字列で結ばれます。片方だけ変えると動きません。- 単発の Success rate は MTU 境界の根拠になりません。beta イメージのデータプレーンは約 250 Kbps で、素の 100 バイトの ping でも巡によって 80% になります。境界を主張するには複数巡の測定が要ります。
system mtuに受理される値は機種と版に依存します。手元の機体は SD-Access が推奨する 9100 を受理せず、実値は 1500 のままでした。上限がいくつなのかは測っていません（§18）。
18. 本ラボで確かめていないこと
本節が測っていないことを明示します。
- Catalyst Center の動作。CML にノード定義が存在しないため、GUI のワークフローも、生成される設定も観測していません。§15 はすべて出典に基づく説明です。
- ISE による動的な SGT 付与と 802.1X の onboarding。ISE のイメージが CML に無いため組めません。実機側にもその欠落が
Environment data is emptyとして現れています。§14 の SGACL は静的なマッピングによる代替です。 - spine / 専用 border / intermediate node。Catalyst 9000v の UADP 定義は 1 台あたり 4 vCPU・18 GB を要求し、2 台で資源を使い切ります。多段構成での挙動は観測していません。
- fabric wireless（AP の join）。同じく資源の天井のため置いていません。
- VXLAN ヘッダそのもののビット。パケットキャプチャを取得していないため、§14 のビット定義は draft の記述であって、線路上でそのビットが立っていたことの確認ではありません。
- SD-Access と BGP EVPN の優劣。Cisco の資料がこの 2 つを正面から比較していないため、§3 の対比表は筆者の整理です。加えて 6-5 側で
clearに相当する実験をしていないので、本節が実測で言えるのは LISP 側だけです。 df-bitを外した 1500 バイトが通らない理由。断片化が許されているのに 0% でした。断片化がどこで行われるか、戻りの経路のどこで落ちるかを切り分けていません。system mtuに受理される値の上限。手元の機体が 9100 を拒否したことは撮れていますが、上限値そのものを機器に列挙させた出力は capture に残していません。ラボは撤去済みで追試もできません。- スイッチ自身が出す ping が SGACL で落ちない理由。補強ラボでは送信元を SGT 100 に分類し、宛先側にもそのバインディングが入っている状態でも疎通は 3 回とも 100% でした。装置が自分で生成するパケットに SGT が載るのか、載るとしてどこで載るのかを切り分けていません。資料上、IP-SGT のバインディングは VRF ごとの表に入ります。本ラボは VRF を指定せずに入れているため、そこが疑わしいのですが、確かめていません。なお TrustSec の SGACL の設定ガイドは、制限事項として、punt（CPU 宛）のトラフィックには SGACL がハードウェアで適用されず、SVI と LISP と loopback については software での適用も迂回されると書いています。ただし本ラボで enforce が立つのは宛先側の SW2 で、そこでは中継の扱いになるはずなので、この記述が本ラボの現象の説明になるかどうかも確かめていません。言えるのは「SGT 100 から 200 へ向かうトラフィックは落ちているが、スイッチ自身が出す ping は落ちていない」までです。
- SGACL で落ちていたパケットの送信元。
show cts role-based countersは SGT のペア単位の集計で、どの送信元のパケットかは印字されません。端末が背景で出している ping の頻度そのものを測っていないため、観測した増分をその通信と突き合わせることもできません。落ちていたのが何の通信かは同定していません。 - 50 バイトの内訳。掃引は 10 バイト刻みで、測ったのは 1450 が 3 巡とも通り、1460 が 3 巡とも通らないことまでです。1451 から 1459 は測っていないため、境界は 1450 と 1460 のあいだとしか言えません。
show lisp session establishedのtotalとestablishedの差。SW1 側はtotal: 5, established: 3と表示しますが、Peerの行は 3 本しかありません。残り 2 の内訳は、本ラボのどの capture にも印字されていません。map-sourceが何を指すのか。本節が取得した Cisco の資料に定義がありません。応答した装置を指すという読み方は、proxy-replyを入れている本ラボでは印字が10.255.0.1になるはずで、実際の10.255.0.2と合いません。clear直後に出るmap-source: localも応答者としては読めません。印字される値そのもの以上のことは、本ラボでは確定していません。- L2 VNI 越しの解決。本ラボは 1 つの VLAN に端末を 1 台ずつしか置いていないため、L2 VNI の map-cache に載るのは自分の配下の MAC（
up, self）だけです。対向の edge を Locator に持つ MAC の項目は、どの capture にも在りません。 - 登録の引き金。端末が通信を出さなかった場合との対照を撮っていません。本ラボの端末は起動時から ping を出し続けているため、無通信の状態が一度も存在しません。出典にも検出の引き金についての記述が見つかりませんでした。
- Map-Register の実際の送信周期。§4 の 1 分と 3 分は RFC の値で、手元の機器が実際にその間隔で送っていることは確かめていません。
- RLOC-probe の周期。§4 で引いた RFC の記述は周期的な送信ですが、送信時刻が印字された項目は 2 件で、いずれも map-cache の項目が生まれた時点の 1 発です（宛先側 SW2 の項目は
neverのままでした）。加えて本ラボは各 instance-id にremote-rloc-probe on-route-changeを入れており、この指定が周期に与える影響も測っていません。 - 端末側から見た挙動。端末には一度もログインしていません。観測はすべてスイッチ側の出力です。
- エンドポイントの移動。
dynamic-eidとlisp mobilityが本来扱うローミングは、端末を別の edge へ移す操作をしていないため観測していません。 instance-idの取り得る範囲。出典に範囲の定義が無く、本ラボも 3 つの値しか試していません。- ファブリックサイトあたりのスケール上限。CVD は具体的な数値を載せず、データシートへ送っています。
19. 次節
本節では、SD-Access のコントロールプレーンが LISP、データプレーンが VXLAN であること、そしてその 2 層が Catalyst Center 無しでも CLI だけで成立することを見ました。エンドポイントは EID として、自分が繋がっている edge の RLOC とともに map-server へ登録されること。リモートの居場所は経路表ではなく map-cache に載るので、消すことができ、消せば問い合わせによって引き直されること。ゲートウェイは同じ IP と同じ MAC で全部の edge に置かれ、そのアドレスは装置自身の SVI が持つ他のアドレスと同じく登録の対象から外れること。オーバーレイを通る最大サイズは、underlay が 1500 のもとで確認できた範囲で 1450 であったこと（差の 50 は出典が書く仕様値で、本節の掃引は 10 バイト刻みのため、実測が言えるのは境界が 1450 と 1460 のあいだに在るところまで。内訳は 6-5 §11 と出典に譲ること）。ポリシーは SGT として付与され、本ラボでは SGACL が宛先側の edge で効いたこと（出典は入口でタグ付けし出口でフィルタすることを一般則としつつ、宛先のグループが分かる装置では入口側で適用されることもあると併記しています）。確かめていないことは §18 にまとめてあります。
次節 6-7 DMVPN (実践) では、拠点間のトンネルを必要になったときに張る仕組みを扱います。本節のファブリックはキャンパスの内側に閉じており、edge のあいだの経路は最初から OSPF で通っていました。DMVPN (Dynamic Multipoint VPN) は WAN を挟んだ拠点間で、mGRE (multipoint GRE) と NHRP (Next Hop Resolution Protocol) を使い、トンネルの相手の実アドレスを問い合わせて解決します。問い合わせて解決するという形は本節の map-request に似て見えますが、同じものではありません。解決する対象も、答えを持つ装置も、キャッシュの置き場所も違います。Phase 1 から Phase 3 までの違いと合わせて、何がどう違うのかを見ていきましょう。
20. 出典
本節が参照した資料です。Cisco の 11 件と RFC / Internet-Draft の 4 件を 2026 年 9 月 13 日に、Cisco TrustSec の 6 件を 9 月 16 日に取得しました。下の表に載せているのは、そのうち本文が引用または参照した資料です。本文中の引用はその時点のページの逐語です。TrustSec の 3 件は Catalyst 9300 向けで、プラットフォームが本節の Catalyst 9000v とは違います（リリースは同じ 17.15 系）。