6-5 VXLAN / EVPN — L2 を L3 網の上に延ばす仕組みと、学習の置き換え
VXLAN が L2 を L3 網の上に延ばす仕組みを、カプセル化と VTEP、EVPN の順に押さえます。Catalyst 9000v 2 台で MAC-IP が ARP の後に立つこと、MTU が 50 バイトずれること、L3VNI と対称 IRB を実機で確かめます。
1. 前節の振り返りと本節の内容
前節 6-4 SD-WAN 設計と運用 では、Cisco Catalyst SD-WAN を設計と運用の側から見直しました。transport の選び方は color の選び方であり、TLOC は system IP・color・encapsulation の 3 つ組で識別され、OMP は宛先と出口と機能の在り処を別々に配ること。オーバーレイという言葉が指していたのは、L3 の網の上に拠点間のトンネルを張る仕組みでした。
本節は舞台をデータセンタへ移します。VXLAN が延ばすのは L3 の到達性ではなく、L2 のセグメントです。6-4 の末尾は 3 つの論点を予告しました。何をカプセル化し、宛先をどう学習し、その学習を BGP EVPN でどう置き換えるのかです。本節はこの 3 つをこの順で扱います。
| 6-4 が予告した論点 | 本節のどこで扱うか |
|---|---|
| 何をカプセル化するのか | §2 でヘッダの内訳と 50 バイト、§3 で VTEP と VNI の対応 |
| 宛先をどう学習するのか | §4。素の VXLAN が使う flood-and-learn と、その難点 |
| その学習を BGP EVPN でどう置き換えるのか | §5 で仕組み、§9〜§10 で実機（type-3 は端末の学習に依らず立ち、MAC-IP は ARP 解決の後） |
そのうえで、この構成でしか見えないものを実機で確かめます。MTU が 50 バイトずれること（§11）、L3VNI と対称 IRB（§12）、どの構文が受理され、どれが拒否されるか（§13）です。
本節の実機は CML 上の Catalyst 9000v で、この VM イメージは Cisco 公式が beta と明記しています。
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 イメージ上での観測」であって、「Cisco が公式にサポートしている挙動」ではありません。公式ドキュメントの動作確認済み機能の一覧に VXLAN / EVPN は載っていませんが、一覧に無いことと非対応と明示されていることは別です。本節は前者の状態で観測しています。
2. 何をカプセル化するのか
VXLAN は、端末が出したイーサネットフレームをまるごと包んで IP 網に流します。中身を書き換えるのではなく、前に外側のヘッダを付けるだけです。RFC 7348 はこの外側ヘッダの構成をこう述べています。
an outer header comprising an outer MAC, outer IP header, and VXLAN header (see Figure 1 in Section 5 for frame format) are prepended to the original MAC frame.
外側 MAC が含まれている点が大切です。外側 Ethernet 14 バイト、外側 IP 20 バイト、UDP 8 バイト、VXLAN 8 バイトで、合わせて 50 バイトになります。ただしこれは外側が IPv4（オプションなし）で、外側にタグが付かない場合の値です。外側が IPv6 なら基本ヘッダだけで 40 バイトになり、802.1Q タグが付けばさらに増えます。本ラボは IPv4・タグなしなので、以下の実測はこの 50 の条件で読んでください。
宛先の UDP ポートは IANA が割り当てた 4789 です。
A well-known UDP port (4789) has been assigned by the IANA in the Service Name and Transport Protocol Port Number Registry for VXLAN.
そして VXLAN ヘッダの中心にあるのが VNI です。
Each VXLAN segment is identified through a 24-bit segment ID, termed the “VXLAN Network Identifier (VNI)”. This allows up to 16 M VXLAN segments to coexist within the same administrative domain.
VLAN の識別子は 12 ビットで、表せるのは 4096 通りですが、0 と 4095 は予約されているので通常使えるのは 1〜4094 です。これに対し VNI は 24 ビットで、上の引用のとおり約 1600 万のセグメントを同居させられます。セグメントを数える単位が変わったことが、VXLAN がデータセンタで使われる理由の一つです。
3. 誰が包んで、誰が解くのか
包む側と解く側を VTEP と呼びます。RFC 7348 の用語定義です。
VTEP VXLAN Tunnel End Point. An entity that originates and/or terminates VXLAN tunnels
Cisco の資料では綴りが違い、Virtual Tunnel End points (VTEPs) と書かれています。
Every VXLAN segment has tunnel edge devices known as Virtual Tunnel End points (VTEPs).
**同じものを指していますが、原典によって語が違います。**本節は RFC 側の「VXLAN Tunnel End Point」を採り、Cisco の資料を読むときは後者の表記に出会うことを覚えておいてください。
本節のラボは leaf を 2 台だけ置き、そのあいだを直結します。spine もルートリフレクタも置きません。Cisco の資料も 2 台構成では spine が必須でないと述べています。
In a two-VTEP topology, a spine switch is not mandatory.
1 つの nve1 の下に、用途の違う VNI が並びます。この対応は後で実機の出力として確かめます（§12）。
**nve1 は「トンネル 1 本」そのものではありません。**VTEP 側の論理インタフェースで、実際のトンネルの相手（tunnel adjacency）は受け取った type-3 に応じて対向 VTEP ごとに作られ、同じ相手への複数の VNI はそれを共有します。本ラボは対向が 1 台なので「1 つの nve1 に 3 本の VNI」という形に見えますが、対向が増えれば相手ごとの adjacency が増えます。
4. 宛先をどう学習するのか
ここからが 6-4 が予告した 2 つ目の論点です。VXLAN を入れただけでは、宛先の知り方は変わっていません。
素の VXLAN、つまり RFC 7348 だけの世界では、宛先を知らないフレームは同じセグメントの全 VTEP へ複製されます。RFC は、ブロードキャストが IP マルチキャストグループへ送られると述べています。
However, this broadcast packet is sent out to the IP multicast group on which that VXLAN overlay network is realized.
Cisco の資料はこれを「flood and learn」と呼び、こう説明します。
VXLAN natively operates on a flood and learn mechanism where broadcast, unknown unicast and multicast (BUM) traffic in a given VXLAN network is sent over the IP core to every VTEP that has membership in that network.
やっていることは従来のスイッチと同じです。宛先が分かるまで一度は溢れさせ、返ってきたフレームの中身から学びます。変わったのはどこを流れるかであって、どうやって知るかではありません。
そして資料自身が、その難点を明示しています。
The drawback of the flood and learn mechanism is that it does not allow scalability in a VXLAN network.
この節のラボは flood-and-learn を組んでいません。 マルチキャスト underlay には PIM が要り、2 台構成では複製が 1 本にしかならないためです。したがって §4 の内容は出典に基づく説明であり、本節の実測ではありません。
5. その学習を BGP EVPN でどう置き換えるのか
3 つ目の論点です。EVPN は、学習の材料をデータから制御プレーンへ移します。RFC 8365 の表現です。
Control-plane learning is used for MAC (and IP) addresses instead of data-plane learning.
複製が必要な通信の運び方も、選べるようになります。
Control-plane information is distributed with BGP and broadcast and multicast traffic is sent using a shared multicast tree or with ingress replication
本節が使うのは後者です。Cisco の定義はこうです。
Ingress replication, or headend replication, is a unicast approach to handle multidestination Layer 2 overlay BUM traffic.
EVPN が運ぶ経路には種類があります。RFC 7432 が定義するのは 4 つで、原典では次のように箇条書きされています（行頭の + は RFC の記号です）。
- 1 - Ethernet Auto-Discovery (A-D) route
- 2 - MAC/IP Advertisement route
- 3 - Inclusive Multicast Ethernet Tag route
- 4 - Ethernet Segment route
本節で実際に立つのは type-3 と type-2、そして §12 で type-5 です。Cisco 側の説明を引きます。
Route type 3 – This performs multicast router advertisement, announcing the capability and intention to use ingress replication for specific VNIs.
Route type 2 – This advertises endpoint reachability information, including MAC and IP addresses of the endpoints or VTEPs.
type-5 は RFC 7432 ではなく RFC 9136 の追加です。
The EVPN route type 5 decouples the IP prefix advertisements from the MAC/IP Advertisement routes in EVPN.
ここまでが出典に基づく説明です。ここから先は、本節のラボで実際に撮った出力です。
6. 実機の前提を測る
設定を書く前に、土台が何であるかを確かめます。
**以下に貼る実機出力は改変していません。**紙面の都合で必要な行だけを抜き出していますが、抜き出した行そのものは実機が印字したままです（本節の全 245 行を show-outputs/ へ機械照合しています）。
LEAF1# 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)ライセンスは network-advantage と dna-advantage が使用中です。
LEAF1# show license summary
network-advantage (CAT9K_VIRTUAL Network ...) 1 IN USE
dna-advantage (CAT9K_VIRTUAL DNA Adva...) 1 IN USE機種は自分をこう名乗ります。
LEAF1# show inventory
NAME: "Switch 1", DESCR: "Catalyst 9000 UADP 8 Port Virtual Switch"
PID: C9KV-UADP-8P , VID: V01 , SN: CMLUADPそして本節でいちばん効いてくる値が、この 1 行です。
LEAF1# show system mtu
Global Ethernet MTU is 1500 bytes.この時点で VXLAN の設定はまだ入っていません。
LEAF1# show running-config | section nve
LEAF1#出力が空であること自体は、あとで何かを主張する根拠には使いません。Phase B 以降との差分の起点としてだけ使います。なお、ここでいう「素」は day0 の設定を当てた後の状態です。ip routing、OSPF、Loopback1、underlay の routed port、アクセスポートはすでに入っています。
7. underlay を作り、収束させてから測る
VXLAN は IP 網の上に載るので、まず VTEP どうしが IP で届く必要があります。本ラボは OSPF で Loopback1 を配ります。
LEAF1# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.255.0.2 0 FULL/ - 00:00:36 10.0.12.2 GigabitEthernet1/0/1対向の Loopback が経路表に入りました。
LEAF1# show ip route ospf
O 10.255.0.2/32 [110/2] via 10.0.12.2, 00:04:50, GigabitEthernet1/0/1LEAF1# show ip route 10.255.0.2
Routing entry for 10.255.0.2/32ここまで確かめてから ping します。
LEAF1# ping 10.255.0.2 source Loopback1 repeat 5
Success rate is 100 percent (5/5), round-trip min/avg/max = 66/148/445 ms順番に意味があります。事前調査では、OSPF が上がりきる前に同じ ping を打って 0% を得ていました。そのときの show ip ospf neighbor は空で、show ip route は経路なしと答えています。**0% を見たら、まず「そこに本当に流したか」「読み取りのタイミングを外していないか」を疑ってください。**転送できないことの証明にはなりません。
8. VXLAN を「素で」立てる — BGP を張る前
まず EVPN インスタンスと NVE インタフェースだけを入れます。
LEAF1(config)# l2vpn evpn
LEAF1(config-evpn)# replication-type ingress
LEAF1(config-evpn)# exit
LEAF1(config)# l2vpn evpn instance 1 vlan-based
LEAF1(config-evpn-evi)# encapsulation vxlan
LEAF1(config-evpn-evi)# replication-type ingress
LEAF1(config-evpn-evi)# exitVLAN と VNI を結びつけます。
LEAF1(config)# vlan configuration 10
LEAF1(config-vlan-config)# member evpn-instance 1 vni 10001
LEAF1(config-vlan-config)# exitNVE インタフェースを作ります。
LEAF1(config)# interface nve1
LEAF1(config-if)# no ip address
LEAF1(config-if)# source-interface Loopback1
LEAF1(config-if)# host-reachability protocol bgp
LEAF1(config-if)# member vni 10001 ingress-replication
LEAF1(config-if)# no shutdown
LEAF1(config-if)# exitこの状態で NVE は上がります。
LEAF1# show nve interface nve1
Interface: nve1, State: Admin Up, Oper Up
BGP host reachability: Enabled, VxLAN dport: 4789宛先ポートが 4789 であることが、ここで確認できます。§2 で引いた IANA の割り当てが、実機の表示として現れています。
VNI も VLAN に紐づいて Up です。
LEAF1# show nve vni
Interface VNI Multicast-group VNI state Mode VLAN cfg vrf
nve1 10001 N/A Up L2CP 10 CLI N/Aしかし、対向のことは何も知りません。
LEAF1# show nve peers
Interface VNI Type Peer-IP RMAC/Num_RTs eVNI state flags UP time列見出しだけが出て、データ行がありません。そして Core への接続は DOWN です。
LEAF1# show l2vpn evpn summary
Connectivity to Core: DOWN「NVE が Oper Up だから動いている」と読んではいけません。インタフェースは up ですが、対向 VTEP を 1 台も知らない状態です。この DOWN が、次節で UP に変わります。その対が、BGP EVPN の担当範囲を示します。
EVI の対応も確かめておきます。
LEAF1# show l2vpn evpn evi
EVI VLAN Ether Tag L2 VNI Multicast Pseudoport
----- ----- ---------- --------- ------------- ------------------
1 10 0 10001 UNKNOWN Gi1/0/2:10LEAF1# show running-config | section l2vpn
l2vpn evpn
replication-type ingress
l2vpn evpn instance 1 vlan-based
encapsulation vxlan
replication-type ingress9. BGP EVPN を張る
leaf どうしで iBGP を張り、l2vpn evpn のアドレスファミリを有効にします。spine もルートリフレクタもないので、直接張ります。
LEAF1(config)# router bgp 65001
LEAF1(config-router)# bgp router-id 10.255.0.1
LEAF1(config-router)# bgp log-neighbor-changes
LEAF1(config-router)# neighbor 10.255.0.2 remote-as 65001
LEAF1(config-router)# neighbor 10.255.0.2 update-source Loopback1
LEAF1(config-router)# address-family l2vpn evpn
LEAF1(config-router-af)# neighbor 10.255.0.2 activate
LEAF1(config-router-af)# neighbor 10.255.0.2 send-community both
LEAF1(config-router-af)# exit-address-familyセッションが上がりました。
LEAF1# show bgp l2vpn evpn summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.255.0.2 4 65001 8 9 7 0 0 00:01:48 2末尾が状態名ではなく数値になっていれば確立済みです。この 2 は受け取ったプレフィックス数です。
そして Core への接続が変わります。
LEAF1# show l2vpn evpn summary
Global Replication Type: Ingress
Connectivity to Core: UP§8 の DOWN と並べてください。**NVE の状態は何も変えていません。**変わったのは BGP を張ったことだけで、それによって「コアと繋がっている」と機器が言い始めました。
対向も見えるようになりました。
LEAF1# show nve peers
Interface VNI Type Peer-IP RMAC/Num_RTs eVNI state flags UP time
nve1 10001 L2CP 10.255.0.2 2 10001 UP N/A 00:01:57EVPN が運ぶ経路のうち、この時点で来ているのは type-3 と MAC の type-2 です。まず type-3 を見ます。
「type-3 が先に立つ」という順序があるわけではありません。RFC 7432 も RFC 8365 も、route type の間の広告順序は規定していません。違うのは生成の契機です。type-3 は「この VNI に参加している」という宣言なので端末の学習に依存せず立ちますが、type-2 は MAC（と IP）を学んで初めて生成されます。本ラボでも BGP を張る前から MAC の学習は起きており（§15）、実測が示すのは MAC/IP の 0 → 1 の変化だけです。
LEAF1# show bgp l2vpn evpn route-type 3
PMSI Attribute: Flags:0x0, Tunnel type:IR, length 4, vni:10001, tunnel identifier: < Tunnel Endpoint: 10.255.0.2 >Tunnel type:IR が、§5 で引いた「ingress replication を使う意思の表明」にあたります。端末の情報ではなく、参加表明と複製方式の告知です。
この時点の内訳を見ます。
LEAF1# show l2vpn evpn evi 1 detail
Replication Type: Ingress
Pseudoports:
GigabitEthernet1/0/2 service instance 10
Routes: 1 MAC, 0 MAC/IP
Peers:
10.255.0.2
Routes: 1 MAC, 0 MAC/IP, 1 IMET, 0 EAD行の字下がりがスコープを表しています。上の Routes: は Pseudoports: の下、つまり自分のアクセスポートで学んだ分。下の Routes: は Peers: の下、つまり対向 VTEP から受け取った分です。同じ 1 MAC, 0 MAC/IP でも意味が違います。
読み取れるのは、この時点で対向はすでに MAC を 1 本広告しており、IMET も 1 本来ていること。そして両方とも MAC/IP は 0 本であることです。MAC と IP を組にした経路は、端末の IP が ARP で解けてから立ちます。
NVE のパケットカウンタも見ておきます。あとで増分を見るための起点です。
LEAF1# show interface nve1
15 packets input, 5310 bytes, 0 no buffer
15 packets output, 5760 bytes, 0 underruns10. 端末が喋ると何が起きるか
VLAN 10 に検証用の SVI を立て、スイッチ自身を端末の代わりにします。理由は §15 に書きます。
LEAF1(config)# interface Vlan10
LEAF1(config-if)# ip address 192.168.10.251 255.255.255.0
LEAF1(config-if)# no shutdown
LEAF1(config-if)# exit対向の SVI へ疎通します。
LEAF1# ping 192.168.10.252 source Vlan10 repeat 5
Success rate is 80 percent (4/5), round-trip min/avg/max = 81/97/105 ms**L2 が延びました。**この SVI は疎通を測るために置いただけで、2 台の leaf は VLAN 10 の間で routing をしていません。同じセグメントが L3 網を越えている、という形です（§12 でこの同じ VLAN に VRF を付けて anycast ゲートウェイにするので、そこから先は状況が変わります）。
5 発中 4 発です。逆方向（LEAF2 から LEAF1 へ）の同じ試験は Success rate is 100 percent (5/5), round-trip min/avg/max = 96/102/111 ms でした。
この 1 発が何で落ちたのかは確かめていません（§15）。ARP の解決で消えたという説明はもっともらしく見えますが、それを示す出力を撮っていないので本節では主張しません。なお本ラボの ping は成功した時点で再試行を打ち切る作りなので、80% になった試験の «2 回目» は存在しません。
学習の結果が出る場所は 2 つに分かれます。まず従来の MAC アドレステーブルです。
LEAF1# show mac address-table vlan 10
Vlan Mac Address Type Ports
---- ----------- -------- -----
10 5254.0058.7da2 DYNAMIC Gi1/0/2
10 5254.00a8.304d STATIC Vl10
Total Mac Addresses for this criterion: 2ローカルの 2 つしか出ていません。Gi1/0/2 は自分のアクセスポートに繋がった端末、Vl10 は今立てた SVI 自身です。対向にいる端末の MAC はここにありません。
しかし学習していないわけではありません。EVPN の表を見ます。
LEAF1# show l2vpn evpn mac
MAC Address EVI VLAN ESI Ether Tag Next Hop(s)
-------------- ----- ----- ------------------------ ---------- ---------------
5254.0058.7da2 1 10 0000.0000.0000.0000.0000 0 Gi1/0/2:10
5254.006e.f9a3 1 10 0000.0000.0000.0000.0000 0 10.255.0.2書き分けが見えます。ローカルの MAC は次ホップがポート名（Gi1/0/2:10）、リモートの MAC は次ホップが対向 VTEP の IP（10.255.0.2）です。MAC アドレステーブルにリモートが出ないことを「学習していない」と読むと誤ります。
BGP の側では type-2 が立っています。
LEAF1# show bgp l2vpn evpn route-type 2
BGP routing table entry for [2][10.255.0.1:1][0][48][525400587DA2][0][*]/20, version 10
BGP routing table entry for [2][10.255.0.1:1][0][48][525400587DA2][32][192.168.10.11]/24, version 22同じ MAC について 2 本あります。[0][*] が MAC だけを運ぶもの、[32][192.168.10.11] が MAC と IP を一緒に運ぶものです。[32] は IPv4 アドレスの長さです。10.255.0.1:1 は Loopback から自動生成された RD です。
**§9 の時点との差は MAC/IP の側です。**あちらは 1 MAC, 0 MAC/IP でした。MAC を運ぶ経路そのものは BGP が上がった時点で既にあり、増えたのは IP を伴う方です。「type-2 は通信が起きるまで 1 本も無い」わけではありません。
ARP の対応も確かめておきます。
LEAF1# show ip arp vlan 10
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.10.251 - 5254.00a8.304d ARPA Vlan10
Internet 192.168.10.252 0 5254.003f.204d ARPA Vlan10
Internet 192.168.10.12 2 5254.006e.f9a3 ARPA Vlan10
Internet 192.168.10.11 1 5254.0058.7da2 ARPA Vlan10そしてカウンタが増えました。
LEAF1# show interface nve1
73 packets input, 19404 bytes, 0 no buffer
73 packets output, 22182 bytes, 0 underruns§9 の時点で 15 だったものが 73 になっています。トンネルを通ったパケットがあることは示せますが、内訳までは確かめていません。§9 の時点ですでに 0 ではなかった 15 が何であったかも、本節では特定していません。
11. MTU は 50 バイトずれる
§2 で外側ヘッダが 50 バイトだと確認しました。それが通信のどこに効くかを測ります。underlay の MTU を上げないまま、両側の境界を刻んで測ります。
まず underlay です。物理側は 1500 でした（§6）。
LEAF1# ping 10.255.0.2 source Loopback1 repeat 3 size 1500 df-bit
Success rate is 100 percent (3/3), round-trip min/avg/max = 403/557/675 ms1 バイト増やします。
LEAF1# ping 10.255.0.2 source Loopback1 repeat 3 size 1501 df-bit
Success rate is 0 percent (0/3)underlay の上限は 1500 です。「1500 は通り 1550 は落ちた」ではなく、通った最大の 1 つ上で落ちることまで確かめてあります。
次に overlay、つまり VXLAN の中を通る側です。
LEAF1# ping 192.168.10.252 source Vlan10 repeat 3 size 1450 df-bit
Success rate is 100 percent (3/3), round-trip min/avg/max = 435/450/468 msLEAF1# ping 192.168.10.252 source Vlan10 repeat 3 size 1451 df-bit
Success rate is 0 percent (0/3)overlay の上限は 1450 です。
| 層 | 通った最大 | 落ちた最小 |
|---|---|---|
| underlay（Loopback → 対向 Loopback） | 1500 | 1501 |
| overlay（SVI → 対向 SVI・VXLAN 越し） | 1450 | 1451 |
**1500 − 1450 = 50。**両側とも境界が閉じているので、この 50 は引き算の推定ではありません。
ただしこの 50 と §2 で数えた 50 は、同じ数でも内訳が違います。ping … size N の N は IP データグラムの長さなので、外側 Ethernet はこの測定に 1 バイトも寄与していません。実際に効いているのはこちらです。
| どの 50 か | 内訳 |
|---|---|
| §2 — 線路上のフレームが大きくなる量 | 外側 Ethernet 14 + 外側 IP 20 + UDP 8 + VXLAN 8 |
| §11 — 通る最大サイズの差（この測定） | 内側 Ethernet 14 + 外側 IP 20 + UDP 8 + VXLAN 8 |
overlay の 1450 は、外側 IP データグラムが underlay の 1500 に収まる条件（20 + 8 + 8 + 14 + N ≤ 1500）から出ています。**両方が 50 になるのは、内側と外側の Ethernet ヘッダがどちらも 14 バイトだからです。**タグ付きフレームのように内側が 18 バイトになる場合は、この 2 つの数は一致しません。
ここで表示に引きずられないでください。NVE インタフェースは大きな MTU を表示します。
LEAF1# show interface nve1 | include MTU
MTU 9216 bytes, BW 1000000 Kbit/sec, DLY 10 usec,LEAF1# show interface GigabitEthernet1/0/1 | include MTU
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,**nve1 の 9216 を「9216 まで通る」と読んではいけません。**実測のとおり overlay は 1450 が上限で、効いているのは物理インタフェースと show system mtu の 1500 の側です。9216 は論理インタフェースの表示にすぎません。
RFC 7348 は、この状況について 2 つのことを述べています。
VTEPs MUST NOT fragment VXLAN packets.
it is RECOMMENDED that the MTUs (Maximum Transmission Units) across the physical network infrastructure be set to a value that accommodates the larger frame size due to the encapsulation
**本ラボは後者をあえて実施していません。**上げなかったらどうなるかを測るためです。実運用では underlay 側を上げてください。
なお 50 という数値を明記している一次資料は Nexus 9000（NX-OS）の白書です。
which requires 50 or 54 bytes of overhead on top of the standard Ethernet MTU (1550 or 1554)
白書は 50 と 54 の内訳を書いていません。本節は本ラボの構成（外側 IPv4・タグなし）に対応する 50 の側だけを扱い、54 の条件については踏み込みません。**本節が取得した Catalyst 9500 の BGP EVPN VXLAN 設定ガイド 17.15 は、overhead が何バイトかを数値では書いていません。**ただし MTU に触れていないわけではなく、設定例の側では system mtu 9198 を入れています（取得した 9 ページ中 4 ページに計 21 箇所）。
つまり公式ガイドは「underlay の MTU を上げておけ」を設定例で示していて、本ラボはそれをあえてやっていません。上げなかったときに何が起きるかを測るためです。したがって「Catalyst の公式資料が 50 と言っている」とは書きませんが、「Catalyst の資料は MTU に触れていない」とも書きません。数値の出どころは NX-OS の白書と本ラボの実測、実運用の指針は上の設定例です。
12. L3VNI と対称 IRB
ここまでは L2 を延ばす話でした。VXLAN は L3 のルーティングも同じトンネルに載せられます。Cisco の説明です。
The network forwards the routed traffic using a Layer 3 virtual network instance (VNI) and an IP VRF.
その運び方には 2 通りあります。
In asymmetric IRB, the ingress VTEP performs both bridging and routing whereas the egress VTEP performs only bridging.
In symmetric IRB, both the ingress and egress VTEPs perform both bridging and routing.
対称 IRB の利点も明記されています。
In symmetric IRB, you are required to define only the VNIs of locally attached endpoints on the ingress and egress VTEPs.
本ラボは対称 IRB です。VRF と core VLAN、L3VNI を入れます。
LEAF1(config)# vlan 20
LEAF1(config-vlan)# name L2-STRETCH-B
LEAF1(config-vlan)# exit
LEAF1(config)# vlan 901
LEAF1(config-vlan)# name CORE-L3VNI
LEAF1(config-vlan)# exit
LEAF1(config)# vrf definition VPN-A
LEAF1(config-vrf)# rd 65001:1
LEAF1(config-vrf)# address-family ipv4
LEAF1(config-vrf-af)# route-target export 65001:50001
LEAF1(config-vrf-af)# route-target import 65001:50001
LEAF1(config-vrf-af)# route-target export 65001:50001 stitching
LEAF1(config-vrf-af)# route-target import 65001:50001 stitching
LEAF1(config-vrf-af)# exit-address-familycore VLAN に L3VNI を割り当てます。
LEAF1(config)# l2vpn evpn instance 2 vlan-based
LEAF1(config-evpn-evi)# encapsulation vxlan
LEAF1(config-evpn-evi)# replication-type ingress
LEAF1(config-evpn-evi)# exit
LEAF1(config)# vlan configuration 20
LEAF1(config-vlan-config)# member evpn-instance 2 vni 10002
LEAF1(config-vlan-config)# exit
LEAF1(config)# vlan configuration 901
LEAF1(config-vlan-config)# member vni 50001
LEAF1(config-vlan-config)# exit
LEAF1(config)# interface Vlan901
LEAF1(config-if)# vrf forwarding VPN-A
LEAF1(config-if)# ip unnumbered Loopback1
LEAF1(config-if)# no autostate
LEAF1(config-if)# no shutdownno autostate は必須です。資料が明記しています。
For a core-facing SVI to function properly, the no autostate command must be configured under the SVI.
L3VNI の番号は core VLAN のものと一致させます。
The Layer 3 VNI id must match with the VNI id configured in the core VLAN on the VTEP.
そして分散エニーキャストゲートウェイです。両 leaf に同じ IP と同じ MAC を置きます。
LEAF1(config)# interface Vlan10
LEAF1(config-if)# vrf forwarding VPN-A
LEAF1(config-if)# mac-address aabb.cc01.f100
LEAF1(config-if)# ip address 192.168.10.1 255.255.255.0
LEAF1(config-if)# no shutdown
LEAF1(config-if)# exit
LEAF1(config)# interface Vlan20
LEAF1(config-if)# vrf forwarding VPN-A
LEAF1(config-if)# mac-address aabb.cc01.f200
LEAF1(config-if)# ip address 192.168.20.1 255.255.255.0
LEAF1(config-if)# no shutdown
LEAF1(config-if)# exit
LEAF1(config)# interface Loopback100
LEAF1(config-if)# vrf forwarding VPN-A
LEAF1(config-if)# ip address 172.31.99.1 255.255.255.255Loopback100 は、このあとの疎通試験（ping vrf VPN-A … source Loopback100）で送信元になるアドレスです。VRF の中に置いてあります。
同じ MAC を全 VTEP で保つ方法は 2 つあると資料が述べています。
Manual MAC address configuration and MAC aliasing are the two methods used to maintain the same MAC address across all VTEPs and configure distributed anycast gateway.
本ラボは前者、mac-address を手で書く方です。SVI の条件も明記されています。
The same subnet mask and IP address must be configured on all the switch virtual interfaces (SVIs) that act as a distributed anycast gateway (DAG).
NVE に L3VNI を追加し、BGP で VRF の経路を配ります。
LEAF1(config)# interface nve1
LEAF1(config-if)# member vni 10002 ingress-replication
LEAF1(config-if)# member vni 50001 vrf VPN-A
LEAF1(config-if)# exit
LEAF1(config)# router bgp 65001
LEAF1(config-router)# address-family ipv4 vrf VPN-A
LEAF1(config-router-af)# advertise l2vpn evpn
LEAF1(config-router-af)# redistribute connected
LEAF1(config-router-af)# exit-address-family投入後、同じ nve1 の上に 3 本の VNI が並びます。
LEAF1# show nve vni
Interface VNI Multicast-group VNI state Mode VLAN cfg vrf
nve1 50001 N/A Up L3CP 901 CLI VPN-A
nve1 10002 N/A Up L2CP 20 CLI VPN-A
nve1 10001 N/A Up L2CP 10 CLI VPN-A**Mode 列が役割を分けています。**L2CP が L2 を延ばす VNI、L3CP が L3VNI です。VLAN 20（VNI 10002）には端末を繋いでいませんが Up になっています。定義した VNI は端末が居なくても立つことが分かります。
ただしこれは、先ほど引いた「対称 IRB ではローカルに居るエンドポイントの VNI だけ定義すればよい」の実演にはなっていません。その利点を実際に見るには、片方の leaf にだけ VLAN 10 の端末を、もう片方にだけ VLAN 20 の端末を置き、相手側の L2VNI を省いても L3VNI 経由で届くことを示す必要があります。本ラボはその対照を組んでいません（§15）。
type-5 が立ちました。
LEAF1# show bgp l2vpn evpn route-type 5
BGP routing table entry for [5][65001:1][0][32][172.31.99.2]/17, version 47VRF の経路表にも入っています。
LEAF1# show ip route vrf VPN-A
172.31.0.0/32 is subnetted, 2 subnets
C 172.31.99.1 is directly connected, Loopback100
B 172.31.99.2 [200/0] via 10.255.0.2, 00:01:56, Vlan901疎通します。
LEAF1# ping vrf VPN-A 172.31.99.2 source Loopback100 repeat 5
Success rate is 100 percent (5/5), round-trip min/avg/max = 70/129/243 ms**L3VNI を通ってルーティングされました。**経路の出口も確かめます。
LEAF1# show ip cef vrf VPN-A 172.31.99.2
172.31.99.2/32
nexthop 10.255.0.2 Vlan901**出口が Vlan901 になっています。**これは §12 の冒頭で no autostate を付けて作った core SVI、つまり L3VNI 50001 に紐づいた入り口です。VRF の経路表の側にも同じ Vlan901 が出ています。routed なトラフィックが L2VNI ではなく L3VNI を通っていることを、この 1 語が示します。
分散エニーキャストゲートウェイの方は、両方の leaf を見ないと確かめられません。
LEAF1# show interface Vlan10
Hardware is Ethernet SVI, address is aabb.cc01.f100 (bia 5254.00a8.304d)
Internet address is 192.168.10.1/24LEAF2# show interface Vlan10
Hardware is Ethernet SVI, address is aabb.cc01.f100 (bia 5254.003f.204d)
Internet address is 192.168.10.1/24同じ IP、同じ MAC です。括弧内の bia（burned-in address）は機体ごとに違い（LEAF1 が 5254.00a8.304d、LEAF2 が 5254.003f.204d）、その上に同じ MAC を被せていることが読み取れます。ただしこれは、いま投入した設定を読み返しただけとも言えます。状態として成立していることを示すのは、次の出力です。
LEAF1# show ip route vrf VPN-A 192.168.10.0 255.255.255.0
Routing entry for 192.168.10.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Vlan10LEAF2# show ip route vrf VPN-A 192.168.10.0 255.255.255.0
Routing entry for 192.168.10.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Vlan10**両方の leaf が、同じサブネットを自分のローカル接続として持っています。**どちらに繋がった端末も、自分の隣にいる leaf をゲートウェイとして使えます。これが分散エニーキャストゲートウェイの意味です。
12.1 anycast のアドレスからは ping できない
ここで 1 つ、実機ならではの挙動があります。同じ疎通試験を、Loopback100 ではなく anycast の SVI を送信元にして打つと通りません。
LEAF1# ping vrf VPN-A 172.31.99.2 source Vlan10 repeat 5
Success rate is 0 percent (0/5)4 回試して 4 回とも 0% でした。**しかしこれは失敗ではありません。**送信元は 192.168.10.1 ですが、LEAF2 も 192.168.10.1 を自分のアドレスとして持っています。LEAF2 が返そうとした応答の宛先は、LEAF2 自身のアドレスです。だから LEAF1 へは戻りません。
**分散エニーキャストゲートウェイが正しく成立しているからこそ、この結果になります。**機器の制約でも、対称 IRB の不調でもありません。疎通を測るときは、ゲートウェイのアドレスではなく端末のアドレスを送信元にしてください。
13. どの構文が受理され、どれが拒否されるか
最後に、周辺の構文をいくつか投げて機器の反応を見ます。**判断の材料にするのは、機器が印字した文字列だけです。**プロンプトが遷移したことを「受理された」の証拠にはしません。
まず 17.13.1 で入った簡素化 CLI です。資料はこう述べています。
Cisco IOS XE 17.13.1 simplifies the CLIs and automatically sets default values for most of the common configurations.
引数なしの member evpn-instance を投げます。
LEAF1(config)#vlan configuration 30
LEAF1(config-vlan-config)# member evpn-instance
LEAF1(config-vlan-config)#exit受理されたことは、投入後の running-config に残っていることで確かめます。
LEAF1# show running-config | section vlan configuration 30
vlan configuration 30
member evpn-instance既定プロファイルも存在します。
LEAF1# show l2vpn evpn profile default detail
EVPN Profile (VLAN Based): default (auto)
evpn id base: 0
l2 vni base: 20000
Encapsulation: vxlan
Replication Type: Ingress**簡素化 CLI は 17.15.03 にも在ります。**ただし本節の設定は旧来の書き方で通しました。簡素化形が効くのは連続した複数の VLAN をまとめて捌く場面で、VNI が 1 本の本ラボでは利得がないうえ、教えたい対応関係（VLAN と EVI と VNI）が自動生成の裏に隠れてしまうためです。
次に、ingress replication で立てた VNI をマルチキャストへ変えられるか試します。
LEAF1(config-if)# member vni 10001 mcast-group 225.0.0.101
% Can not change VNI mode between multicast and ingress-replication**拒否されました。**しかも理由が明示されています。**複製方式は後から入れ替えられません。**本ラボが最初から ingress replication で組んでいることの意味が、この 1 行から読めます。
Ethernet Segment を途中まで書いてみます。
LEAF1(config)#l2vpn evpn ethernet-segment 1
LEAF1(config-evpn-es)# identifier type 0 00.01.02.03.04.05.06.07.08
LEAF1(config-evpn-es)#exit
% Ethernet Segment 1 configuration is incomplete, redundancy must be configuredVLAN-aware bundling の書き方はこの版では通りません。
LEAF1(config)# l2vpn evpn instance 9 vlan-aware
^
% Invalid input detected at '^' marker.範囲外の VNI は、範囲を教えて拒否されます。
LEAF1(config-if)# member vni 99999999 ingress-replication
% Valid VNI Range is 4096-16777215.いずれも % で始まる行が出ています。**「エラーが出なかった」ではなく「何が印字されたか」で分類してください。**構文として受け付けられても初期化で落ちる、という中間状態も存在します。
これらを投げた後も、本命の設定は残っています。
LEAF1# show running-config | section nve
interface nve1
no ip address
source-interface Loopback1
host-reachability protocol bgp
member vni 10001 ingress-replication
member vni 10002 ingress-replication
member vni 50001 vrf VPN-A14. 落とし穴・補足
本節で実際に踏んだ、あるいは踏みかけた読み違えをまとめます。
- **経路が入る前の 0% を「転送できない」と読まない。**事前調査では OSPF が上がりきる前に ping して 0% を得ていました。同じ時点の
show ip ospf neighborは空です。先に収束を確かめてから測る（§7）。 - **
Oper Upは「動いている」ではない。**NVE インタフェースが up でもConnectivity to Coreは DOWN のことがあります。BGP を張って初めて UP に変わります（§8 と §9 の対）。 - **MAC アドレステーブルにリモートが出ないことを「学習していない」と読まない。**リモートの MAC は
show l2vpn evpn macに、次ホップが対向 VTEP の IP という形で載ります（§10）。 - **
show interface nve1のMTU 9216を「9216 まで通る」と読まない。**効いているのは物理インタフェースとshow system mtuの 1500 の側です（§11）。 - **anycast のアドレスを ping の送信元にすると返ってきません。**対向も同じアドレスを持つので、応答が対向側で終端されます。分散エニーキャストゲートウェイが成立しているからこその結果です（§12.1）。
- **稼働中の VNI は複製方式をその場で入れ替えられません。**ingress replication で立てた VNI にマルチキャストを指定すると
% Can not change VNI mode between multicast and ingress-replicationで拒否されます。拒否されたのはインプレースの変更であって、no member vni …で外して作り直す経路まで否定されたわけではありません（本ラボはそれを試していません）（§13）。 - **「エラーが出なかった」を受理の根拠にしない。**IOS-XE は構文エラー以外にも値域や状態の拒否を固有のメッセージで返します。
%で始まる行が出ていないかで判断してください（§13）。 - **VXLAN 越えの往復時間が遅いことを VXLAN の性質と書かない。**CML の Catalyst 9000v は beta で、データプレーンのスループットが約 250 Kbps と公式に明記されています。
15. 確かめていないこと
本節が測っていないことを明示します。
- 端末どうしの疎通。ラボの端末（alpine）へ管理経路で入れなかったため、端末発の通信は 1 つも撮っていません。**これは取得側の事情であって、機器や VXLAN の性質ではありません。**代わりに、スイッチ自身の SVI を端末代わりにした疎通と、MAC / MAC-IP の学習と、NVE のカウンタで L2 延伸を示しています。
- 端末から見た分散エニーキャストゲートウェイ。同じ理由で撮っていません。§12 で示したのは「両 leaf の VRF 経路がローカル接続になっている」ところまでで、「端末から見て同じゲートウェイだった」とは書いていません。
- flood-and-learn とマルチキャスト underlay。組んでいません。§4 は出典に基づく説明です。
- spine-leaf とルートリフレクタ。置いていません。実運用では spine が BGP のルートリフレクタを兼ねる構成が一般的ですが、本ラボでは観測できません。
- マルチホーミング（Ethernet Segment）。3 台目が要ります。加えて Catalyst 9000 の資料は、この版で all-active 冗長が非対応であると明記しています。これは EVPN 一般の話ではなく、この製品のこの版の制限です。
- NVE カウンタの内訳。§9 の時点で 15 だったものが何であったかは特定していません。
- type-3 と type-2 のどちらが先に流れたか。Phase C で状態を 1 回撮っただけなので、順序は観測していません。しかも BGP を張る前の Phase B の時点で
MAC Addresses: 1 / Local: 1が印字されており、MAC の学習自体は EVPN より前から起きています。実測が示すのは MAC/IP の 0 → 1 の変化だけです。 - 疎通が 5 発中 4 発になる理由。その 1 発が何で落ちたかを示す出力は撮っていません。（本ラボの ping は成功した時点で再試行を止めるので、80% の試験には 2 回目がありません。「初回が落ちて再試行で通る」形が撮れているのは VXLAN を通らない対照試験の側だけです。）
- §9 の時点で既にあった MAC 経路 1 本の中身。その時点で
show bgp l2vpn evpn route-type 2を撮っていないため、どの MAC であったかは確かめていません。本節が示せるのは「MAC/IP が 0 から 1 以上へ変わった」ことまでです。 - 対称 IRB のスケール上の利点。「ローカルに居るエンドポイントの VNI だけ定義すればよい」ことの実演には、leaf ごとに違う VLAN の端末を置き、相手側の L2VNI を省いても届くことを示す対照が要ります。本ラボは両 leaf に同じ VNI を定義しているので、この利点は出典としてのみ扱っています。
- VXLAN 越えの往復時間が遅い理由。遅いこと自体は観測できますが、**VXLAN の性質としては書きません。**CML の Catalyst 9000v は beta で、データプレーンのスループットが約 250 Kbps と公式に明記されています。
16. 次節
本節では、VXLAN が何をカプセル化し、宛先をどう学習し、その学習を BGP EVPN がどう置き換えるのかを見ました。包むのは元のイーサネットフレームそのもので、線路上のフレームは 50 バイト大きくなること。物理側で通る最大サイズとトンネルの中で通る最大サイズも 50 ずれますが、こちらの 50 は内訳が違うこと（§11）。素の VXLAN の学習は従来と同じ flood-and-learn で、EVPN はそれを制御プレーンでの配布に置き換えること。経路は一度に立つのではなく、参加表明の type-3 は端末の学習に依存せず立ち、MAC と IP を組にした経路は端末の IP が ARP で解けてから増えること（MAC だけを運ぶ経路は BGP 確立の時点で既にあり、順序そのものは規定されていません）。学習の結果は MAC アドレステーブルと EVPN の表に分かれて見えること。そして L3VNI と対称 IRB により、同じ VRF を VTEP 間へ延ばし、その VRF 内のルーティングを同じトンネルの上で運べること（VRF を跨ぐには別途 route leaking などが要ります）。
実機では、NVE が up でも Core との接続が DOWN である状態を撮り、BGP を張ることで UP に変わる対を残しました。MTU は両側の境界を刻み、1500 と 1450 という形で差が 50 であることを実測しました。分散エニーキャストゲートウェイでは、両方の leaf が同じサブネットをローカル接続として持つことを確かめ、その帰結として anycast のアドレスからは ping が返らないことも見ました。確かめていないことは §15 にまとめてあります。
次節 6-6 SD-Access (SDA) では、ここで見た VXLAN を自動化の側から扱います。本節は VXLAN と EVPN そのものを手で組みましたが、SD-Access は同じオーバーレイをファブリックとして構成し、エンドポイントの識別と場所の解決に LISP を使います。手で書いた nve1 や l2vpn evpn が、誰にどう置き換えられるのかを見ていきましょう。
17. 出典
本節が参照した資料です。Cisco の 13 件と RFC 4 件を 2026 年 9 月 5 日に取得しました。本文中の引用はその時点のページの逐語です。
**注意が 1 つあります。**VXLAN のオーバーヘッドを 50 バイトと数値で明記している資料は、下表のうち Nexus 9000（NX-OS）の白書だけです。本節が取得した Catalyst 9500 の設定ガイドは、overhead が何バイトかを数値では書いていません（ただし設定例には system mtu 9198 が入っており、MTU に触れていないわけではありません。§11）。利用する製品とリリースの資料で確認してください。