TL-SG108E で家庭内に VLAN を作って 802.1Q タグを目視してみた

こんにちは。リテールアプリ共創部のきんじょーです。

案件で Direct Connect 接続を構築する必要があり、オンプレミス側の解像度を深めるために、L2 スイッチと業務用ルーターで家庭内ネットワークを AWS に接続していきます。

Direct Connect を家庭内には引き込めませんが、BGPでの経路伝播を確認するため Site-to-Site VPN で代用します。
この記事は L2 スイッチの検証記事です。AWS やルーターはまだ登場しません。

使用する機器

アイキャッチのTP-Link のスマートスイッチ TL-SG108E を使用します。8 ポートのギガビットスイッチで、802.1Q VLAN・ポートミラーリング・ループ防止などの機能を Web 管理画面から設定できます。Amazon で 3,500 円ほどでした。

型番がよく似た TL-SG108（E なし）はアンマネージドスイッチで、VLAN の設定ができません。この用途で購入する場合は末尾の E まで確認してください。

検証用の端末には、Mac と iPad を使用し、USB Ethernet アダプタで有線接続します。

やってみる

疎通確認

まずは VLAN を設定する前に、素の状態で疎通を確認します。

スイッチに Mac と iPad を LAN ケーブルで接続します。この検証環境には DHCP サーバーがいないため、端末には手動で IP アドレスを設定します。検証用のセグメントは 10.100.10.0/24 とし、Mac に 10.100.10.10/24、iPad に 10.100.10.20/24 を割り当てました。

Mac 側は、まず USB Ethernet アダプタがどのインターフェースに割り当てられているかを確認します。

$ networksetup -listallhardwareports

Hardware Port: USB 10/100/1000 LAN
Device: en8
Ethernet Address: 00:e0:4c:xx:xx:xx

Hardware Port: Thunderbolt Bridge
Device: bridge0
Ethernet Address: 96:60:0b:xx:xx:xx

Hardware Port: Wi-Fi
Device: en0
Ethernet Address: 3c:22:fb:xx:xx:xx

Hardware Port: Thunderbolt 1
Device: en3
Ethernet Address: 96:60:0b:xx:xx:xx

Hardware Port: Thunderbolt 2
Device: en4
Ethernet Address: 96:60:0b:xx:xx:xx

Hardware Port: Thunderbolt 3
Device: en12
Ethernet Address: 96:60:0b:xx:xx:xx

Hardware Port: Thunderbolt 4
Device: en11
Ethernet Address: 96:60:0b:xx:xx:xx

出力の「USB 10/100/1000 LAN」に対応する Device 名（今回は en8）が、以降のコマンドで使用するインターフェース名です。

iPad は USB-C Ethernet アダプタを接続すると設定アプリに「Ethernet」の項目が現れ、「IP を構成 > 手動」で固定 IP を設定できます。

管理画面へのアクセス

TL-SG108E の管理画面の IP はデフォルトで 192.168.0.1 です。検証用セグメントとはサブネットが異なるため、このままでは管理画面にアクセスできません。管理画面側は 192.168.0.0/24 への経路しか持っておらず、10.100.10.10 を送信元にすると応答を返せないためです。

Mac 側にはエイリアスで 192.168.0.0/24 のアドレスを追加しておきます。

$ sudo ifconfig en8 alias 192.168.0.10 netmask 255.255.255.0

$ ifconfig en8
en8: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	options=6464<VLAN_MTU,TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
	ether 00:e0:4c:xx:xx:xx
	inet6 fe80::e9:ef3b:19d9:9357%en8 prefixlen 64 secured scopeid 0x16
	inet 10.100.10.10 netmask 0xffffff00 broadcast 10.100.10.255
	inet 192.168.0.10 netmask 0xffffff00 broadcast 192.168.0.255
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect (1000baseT <full-duplex>)
	status: active

追加されました。
ブラウザで http://192.168.0.1 にアクセスし、初期ユーザー（admin/admin）でログインしてパスワードを変更します。

ping と 3 つのテーブル

Mac から iPad へ ping を打つと、当然ですが疎通します。設定を何もしていないスイッチは、全ポートが 1 つのネットワークとして動作します。

$ ping -c 3 10.100.10.20
PING 10.100.10.20 (10.100.10.20): 56 data bytes
64 bytes from 10.100.10.20: icmp_seq=0 ttl=64 time=1.198 ms
64 bytes from 10.100.10.20: icmp_seq=1 ttl=64 time=1.502 ms
64 bytes from 10.100.10.20: icmp_seq=2 ttl=64 time=1.483 ms

--- 10.100.10.20 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.198/1.394/1.502/0.139 ms

このとき、通信の裏では 3 つのテーブルが使われています。

1. ルーティングテーブル（Mac）: 宛先 10.100.10.20 は自分と同じサブネットなので、ゲートウェイを経由せず en8 から直接届けると判断します。netstat -rn では、ARP 解決に伴って作られた 10.100.10.20 宛のホストルートが en8 に紐づいているのが確認できます

$ netstat -rn
10.100.10.20       34:3d:c4:xx:xx:xx   UHLWIi                en8   1057

2. ARP テーブル（Mac）: IP アドレスから宛先 MAC アドレスを解決します。未解決の場合は ARP リクエストをブロードキャストし、iPad が応答します。arp -a に iPad の MAC アドレスが載ります

$ arp -a
? (10.100.10.10) at 0:e0:4c:xx:xx:xx on en8 ifscope permanent [ethernet]
? (10.100.10.20) at 34:3d:c4:xx:xx:xx on en8 ifscope [ethernet]

3. MAC アドレステーブル（スイッチ）: スイッチは受信フレームの送信元 MAC アドレスと物理ポートの対応を学習し、以降の宛先 MAC が分かっているフレームはそのポートにだけ転送します

TL-SG108Eでは管理画面で MAC アドレステーブルを確認することはできませんでした。

VLAN 設定

VLAN を設定して、このネットワークを論理的に分割します。
TL-SG108E の VLAN メニューには MTU VLAN・Port Based VLAN・802.1Q VLAN が並んでいます。

Port Based VLAN はその名の通り、ポートをグルーピングして VLAN を区切る方式です。スイッチが 1 台であればこれでも分離できますが、グループ分けの情報はそのスイッチの中でしか意味を持ちません。スイッチが複数台ある環境で VLAN を分けるためには、フレーム自体に VLAN の識別子（タグ）を付ける 802.1Q VLAN を使用します。今回はこちらを検証します。

802.1Q VLAN の設定

TL-SG108E の 802.1Q VLAN の設定は 2 箇所に分かれています。

1. 802.1Q VLAN: 各 VLAN にどのポートを所属させるかを、ポートごとに Untagged / Tagged / 非所属 で設定します
   • Untagged: そのポートからフレームを出すとき、タグを外して送出する所属方法です。接続された端末は VLAN の存在を意識しません
   • Tagged: タグを付けたまま送出する所属方法です。タグを解釈できる機器（スイッチやルーター）を接続するポートで使用します
2. 802.1Q PVID Setting: タグの付いていないフレームがポートに入ってきたとき、何番の VLAN として扱うか（PVID）を設定します。Untagged / Tagged が「出るとき」の設定であるのに対し、PVID は「入るとき」の設定です

TL-SG108E の管理画面に「アクセスポート」のような設定項目はなく、この Untagged / Tagged / PVID の組み合わせでポートの役割を作っていきます。ここからは 2 段階に分けて設定します。

段階1: すべてのポートをアクセスポートにする

まずは最小の構成です。ポート 1 は VLAN1 のまま残し、ポート 2-4 を VLAN10、ポート 5-8 を VLAN20 に分けます。

各ポートのVLAN設定は以下です。

PVIDはこのようになります。

このように 1 つの VLAN に Untagged で所属させ、PVID も同じ VLAN 番号に揃えたポートをアクセスポートと呼びます。接続された端末はタグを付けることも見ることもなく、VLAN の存在を意識しません。

なお、当初「管理画面は VLAN1 に所属しているので、VLAN10 のポートからは届かなくなるはず」と思い込んでいたのですが、実際は他の VLAN のポートからでも、192.168.0.0/24 のアドレスを設定すれば管理画面にアクセスできました。
Easy Smart シリーズには管理 VLAN の概念がなく、管理用のインターフェースは VLAN で分離されないようです。

VLAN を跨ぐと ping が通らなくなる

Mac（ポート 2）と iPad（ポート 3）が同じ VLAN10 にいる状態では、先ほどと同様に ping が疎通します。

iPad を VLAN20 側のポート 6 に挿し替えると、IP アドレスは同じサブネットのまま、ping が通らなくなります。

arp -a を確認すると、iPad のエントリが incomplete になっています。ping 以前に、ARP リクエストのブロードキャストが VLAN の境界を越えられず、MAC アドレスの解決から失敗しています。

$ arp -a 
? (10.100.10.10) at 0:e0:4c:xx:xx:xx on en8 ifscope permanent [ethernet]
? (10.100.10.20) at (incomplete) on en8 ifscope [ethernet]

同じスイッチ・同じサブネットでも、L2 のレベルで分離されていることが確認できます。

ブロードキャストドメインを確認

VLAN により「ブロードキャストドメイン」が区切られていることを tcpdump で確認します。

iPad と Mac が同じ VLAN にいる状態で、Mac 側でキャプチャを開始します。

$ sudo tcpdump -i en8 -e -n

Mac側から何も通信していなくても、色々なフレームが流れています。観測できたのは大きく 3 種類でした。

1 つ目は、宛先 MAC が ff:ff:ff:ff:ff:ff（ブロードキャスト）の DHCP リクエストです。約 5 秒間隔で延々と流れ続けています。

18:16:33.497145 ac:a7:f1:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 321: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from ac:a7:f1:xx:xx:xx, length 279
18:16:38.502106 ac:a7:f1:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 321: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from ac:a7:f1:xx:xx:xx, length 279

送信元 MAC ac:a7:f1:xx:xx:xx は Mac でも iPad でもありません。正体は、同じキャプチャに写っていた管理画面宛の ARP 応答から分かりました。

18:18:13.081335 ac:a7:f1:xx:xx:xx > 00:e0:4c:xx:xx:xx, ethertype ARP (0x0806), length 60: Reply 192.168.0.1 is-at ac:a7:f1:xx:xx:xx, length 46

192.168.0.1 is-at ac:a7:f1:xx:xx:xx、つまり TL-SG108E 自身の管理インターフェースです。192.168.0.1 で応答しつつ DHCP での IP 取得も試み続ける挙動のようで、DHCP サーバーの居ないこの検証環境ではリクエストが流れ続けていました。スイッチの管理インターフェースも、1 台のホストとして同じブロードキャストドメインに参加していることが分かります。先ほど確認した「管理インターフェースは VLAN で分離されない」という挙動とも整合します。

2 つ目は、Mac が送信する mDNS のサービス探索です。宛先はマルチキャストアドレス 224.0.0.251（MAC は 01:00:5e:00:00:fb）で、これもドメイン内の全端末に届きます。

18:18:13.559800 00:e0:4c:xx:xx:xx > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 470: 10.100.10.10.5353 > 224.0.0.251.5353: 0 [3a] [20q] PTR (QM)? lb._dns-sd._udp.local. PTR (QM)? _airport._tcp.local. PTR (QM)? _printer._tcp.local. （省略） PTR (QM)? _apple-pairable._tcp.local. (428)

プリンタ（_printer _ipp）や AirPlay 関連のサービスを探しています。「同じネットワークに繋ぐと機器が自動で見つかる」体験は、この探索フレームがブロードキャストドメインの内側に届くことで成立しています。

3 つ目は、Mac と iPad の間で交わされる ICMPv6 の Neighbor Solicitation / Advertisement です。

18:16:37.924429 00:e0:4c:xx:xx:xx > 34:3d:c4:xx:xx:xx, ethertype IPv6 (0x86dd), length 86: fe80::e9:ef3b:19d9:9357 > fe80::18b3:ba0f:9dba:a528: ICMP6, neighbor solicitation, who has fe80::18b3:ba0f:9dba:a528, length 32
18:16:37.925781 34:3d:c4:xx:xx:xx > 00:e0:4c:xx:xx:xx, ethertype IPv6 (0x86dd), length 78: fe80::18b3:ba0f:9dba:a528 > fe80::e9:ef3b:19d9:9357: ICMP6, neighbor advertisement, tgt is fe80::18b3:ba0f:9dba:a528, length 24

IPv6 で ARP に相当する隣接確認（NDP）です。手動で設定した IP アドレスは IPv4 だけですが、両端末とも fe80:: で始まるリンクローカルアドレスを自動生成しており、その到達確認が裏で行われています。

iPad 側でこのネットワークに存在しない IP へ ping を打つと、宛先の MAC アドレスを解決しようとする ARP リクエスト（who-has）の連打も観測できます。

21:02:50.124657 34:3d:c4:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.100.10.101 tell 10.100.10.20, length 46
21:02:53.124793 34:3d:c4:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.100.10.101 tell 10.100.10.20, length 46
21:02:56.127081 34:3d:c4:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.100.10.101 tell 10.100.10.20, length 46

これも宛先は ff:ff:ff:ff:ff:ff です。誰からも応答が得られないため、iPad は数秒おきに再送を繰り返しています。

iPad を別の VLAN に移して同じキャプチャをすると、iPadから送信されるフレームが一切見えなくなります。ブロードキャストドメインが、VLAN によって分割されたことを確認できます。

段階2: トランクポートで複数の VLAN を通す

ここまでのポートはすべてアクセスポートで、1 ポートにつき 1 つの VLAN しか扱えませんでした。次に、1 本のケーブルで複数の VLAN を通せるポートを作ります。

段階1でポート 8 は VLAN20（Untagged / PVID 20）に割り当てていました。これを VLAN20 の Untagged から外して VLAN1 の Untagged / PVID 1 に戻した上で、VLAN10 と VLAN20 に Tagged で所属させます。このように複数の VLAN を Tagged で運ぶポートをトランクポートと呼びます。スイッチ同士やスイッチとルーターを 1 本のケーブルで接続し、複数の VLAN をまとめて通すために使うポートです。

トランクポートにタグなしのフレームが入ってきた場合は、PVID に従って VLAN が割り振られます（ここでは VLAN1）。このように、トランクポートでタグなしのフレームを割り振る先の VLAN をネイティブ VLAN と呼びます。

次回の記事で VLAN 間ルーティングを担うルーターを接続するポート 1 も、同じ構成のトランクポートにしておきます。

トランクポートの先にいる機器には、タグを解釈できることが求められます。今回は 2 台目のスイッチの代わりに、Mac を、タグを処理できる機器として使用します。

$ sudo ifconfig vlan10 create
$ sudo ifconfig vlan10 vlan 10 vlandev en8
$ sudo ifconfig vlan10 inet 10.100.10.10 netmask 255.255.255.0 up

Mac をポート 8 に接続し、vlan10 仮想インターフェースに 10.100.10.10/24 を設定すると、VLAN10 のアクセスポートにいる iPad と疎通できます。素の en8 はネイティブ VLAN の VLAN1 に、vlan10 仮想インターフェースは VLAN10 に接続され、1 本のケーブルで 2 つの VLAN の両方と通信できる状態です。

なお、ここで軽く詰まりました。前の段階で en8 本体に付けた 10.100.10.10 を外さないと 10.100.10.0/24 宛の経路が en8 を向いたままになり、ping がタグなしで出ていって疎通しません。IP を外しても古い経路が残る場合は sudo route delete -net 10.100.10.0/24 で削除して vlan10 の IP を付け直します。

タグの実物を見る

これで準備が揃ったので、トランクポートを流れる 802.1Q のタグを実際に見てみます。

VLAN10 のアクセスポートにいる iPad と ping で疎通させながら、Mac の親インターフェース側を tcpdump でキャプチャします。

$ sudo tcpdump -i en8 -e -n vlan

21:47:15.061414 00:e0:4c:xx:xx:xx > 34:3d:c4:xx:xx:xx, ethertype 802.1Q (0x8100), length 102: vlan 10, p 0, ethertype IPv4 (0x0800), 10.100.10.10 > 10.100.10.20: ICMP echo request, id 26764, seq 54, length 64
21:47:15.062804 34:3d:c4:xx:xx:xx > 00:e0:4c:xx:xx:xx, ethertype 802.1Q (0x8100), length 102: vlan 10, p 0, ethertype IPv4 (0x0800), 10.100.10.20 > 10.100.10.10: ICMP echo reply, id 26764, seq 54, length 64
21:47:17.071032 00:e0:4c:xx:xx:xx > 34:3d:c4:xx:xx:xx, ethertype 802.1Q (0x8100), length 46: vlan 10, p 0, ethertype ARP (0x0806), Request who-has 10.100.10.20 (34:3d:c4:xx:xx:xx) tell 10.100.10.10, length 28
21:47:17.072120 34:3d:c4:xx:xx:xx > 00:e0:4c:xx:xx:xx, ethertype 802.1Q (0x8100), length 64: vlan 10, p 0, ethertype ARP (0x0806), Reply 10.100.10.20 is-at 34:3d:c4:xx:xx:xx, length 46

出力に ethertype 802.1Q (0x8100) と vlan 10 が表示されています。送信元 MAC アドレスと EtherType の間に 4 バイトのフィールド（TPID 0x8100 + TCI）が挿入され、その中に VLAN 番号が書かれています。ICMP だけでなく ARP にも同じタグが付いており、この VLAN のフレームはすべてタグ付きでトランクポートを通っていることが分かります。

タグ付きのフレームを観測できるのは親インターフェース側だけです。VLAN 仮想インターフェース側でキャプチャすると、タグが外された後のフレームが見えます。

$ sudo tcpdump -i vlan10 -e

Direct Connect の VIF（Virtual Interface）を作成する際に指定する VLAN ID について、実際の 802.1Q タグを見ることで理解が深まりました。
1 本の物理接続の上に複数の VIF を収容できるのは、この 4 バイトでフレームを識別しているためです。

ブロードキャストストーム

最後に、L2 ネットワークの代表的な事故であるブロードキャストストームを、安全な検証環境で意図的に起こしてみます。
稼働中のネットワークで行うと全体の通信が停止してしまうため、隔離された今のうちに検証します。

TL-SG108E のループ防止機能（Loop Prevention）を無効にした状態で、同じ VLAN の 2 ポートを 1 本の LAN ケーブルで直結し、ループを作ります。この状態で ARP のブロードキャストを発生させると（存在しない IP への ping で発生します）、全ポートの LED が激しく点滅し始め、tcpdump には同じ ARP リクエストが延々と流れ続けます。

IP ヘッダには TTL があり、ルーターを通過するたびに減算されて 0 になるとパケットは破棄されます。しかしイーサネットフレームに TTL に相当するフィールドはありません。ループに入ったブロードキャストフレームは、ケーブルを抜くまで回り続けてしまいます。

次に、tcpdump を流したまま管理画面で Loop Prevention を有効化すると、その直後からスイッチがあるフレームをブロードキャストし始めます。

20:55:51.520199 00:e0:4c:xx:xx:xx > ac:a7:f1:xx:xx:xx, ethertype IPv4 (0x0800), length 703: 192.168.0.10.56128 > 192.168.0.1.80: Flags [P.], seq 1:650, ack 1, win 65535, length 649: HTTP: GET /loop_prevention_set.cgi?lpEn=1&apply=Apply HTTP/1.1
20:55:51.525777 ac:a7:f1:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype RRCP (0x8899), length 60: ac:a7:f1:xx:xx:xx > ff:ff:ff:ff:ff:ff, RRCP-0x25 query
20:55:52.559634 ac:a7:f1:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype RRCP (0x8899), length 60: ac:a7:f1:xx:xx:xx > ff:ff:ff:ff:ff:ff, RRCP-0x25 query
20:55:53.560066 ac:a7:f1:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype RRCP (0x8899), length 60: ac:a7:f1:xx:xx:xx > ff:ff:ff:ff:ff:ff, RRCP-0x25 query

ethertype RRCP (0x8899) のブロードキャストが約 1 秒間隔で送信され続けています。RRCP は Realtek チップ搭載スイッチが使う独自プロトコルで、このプローブフレームを全ポートから送り出し、別のポートに戻ってきたらループと判定する仕組みとみられます。ストームが起きてから対処するのではなく、有効化した瞬間から 1 秒ごとにループの有無を確認し続けているわけです。

この状態で同じ結線をすると、スイッチがループを検出して該当ポートをブロックし、ストームは発生しませんでした。業務用ネットワークで STP（スパニングツリープロトコル）やループ防止機能が必須とされる理由を体感できました。

最後に

802.1Q VLANについて概念は理解していたものの、実際に設定したことはありませんでした。
TL-SG108Eを用いて実機で設定しフレームを目視することで以下を確認できました。

• VLAN は同じスイッチ・同じサブネットの端末を L2 のレベルで分離する。分離されると ARP のブロードキャストが届かなくなり、IP 以前に MAC アドレスの解決ができなくなる
• Untagged / Tagged はフレームが「出るとき」の設定、PVID は「入るとき」の設定
• 802.1Q のタグは送信元 MAC アドレスと EtherType の間に挿入される 4 バイトのフィールドで、tcpdump で実物を確認できる。Direct Connect の VIF で指定する VLAN ID はこのタグ
• イーサネットフレームには TTL がなく、ループしたブロードキャストは止まらない。ループ防止機能が必須とされる理由

次回は業務用ルーター（YAMAHA RTX1200）を接続して VLAN 間ルーティングを構成します。

この記事が誰かの役に立つと幸いです。以上。リテールアプリ共創部のきんじょーでした。