イーサネットの深淵：アクセスポートとトランクポートが織りなすVLANの規律
ネットワークエンジニアとして現場を渡り歩いていると、「VLANなんてスイッチの設定一つで終わる話だ」という声を耳にすることがある。だが、OSI参照モデルの第2層、すなわちデータリンク層で起きている物理的な書き換えと、それが上位層のパフォーマンスやセキュリティにどう直結しているかを理解している者は驚くほど少ない。
今日は、スイッチングの基本でありながら、極限のチューニングの源流となる「アクセスポート」と「トランクポート」の真の挙動について、パケットレベルから解き明かしていこう。
—
1. カプセル化の物理：タグという名の「身分証」
イーサネットフレームがスイッチのポートに飛び込んできた瞬間、そのフレームには「出自」が刻まれる。これがIEEE 802.1Qによるタグ付けだ。
- アクセスポート（Untagged）: 到着したフレームを、ポートに割り当てられたデフォルトVLAN（PVID）に強制的に紐付ける。送信時にはタグを剥ぎ取り、端末側に「VLANの概念」を意識させない。これがエンドホストとの通信における原則だ。
- トランクポート（Tagged）: 複数のVLANを多重化する。フレームのイーサネットヘッダー内に4バイトの「タグ」を挿入し、VLAN ID（VID）を明示する。
ここで重要なのは、「タグの挿入はCPU（ASIC）への負荷である」という点だ。スループットを限界まで追い込む環境では、MTU（最大転送単位）をデフォルトの1500バイトから、タグ分を考慮して1504バイト（あるいはジャンボフレーム対応で9000バイト）へ引き上げる設定が必須となる。これを忘れると、特定のフレームが「ジャイアントフレーム」と見なされ、黙って廃棄されるという、夜も眠れなくなるようなパケットロスに直面することになる。
—
2. パフォーマンスの深淵：TCPバッファとMTUの相関
ネットワークエンジニアがしばしば見落とすのは、L2のトランク設定がTCPのトランスポート効率に与える影響だ。
もしサーバーサイドでMTUが適切に最適化されていない状態で、トランクポートを経由して大きなデータを送信しようとすれば、パケットの断片化（フラグメンテーション）が頻発する。CPUは断片化されたパケットの再構築で忙殺され、結果としてレイテンシが増大し、TCPのハンドシェイクすら遅延する。
極限の最適化を目指すのであれば、Linuxカーネルレベルで以下のチューニングを検討すべきだ。
# カーネルパラメータでTCPバッファを拡張し、高帯域・高遅延環境に対応する
# /etc/sysctl.conf に追記
net.ipv4.tcp_rmem = 4096 87380 16777216 # 受信バッファの最小/デフォルト/最大
net.ipv4.tcp_wmem = 4096 65536 16777216 # 送信バッファの最小/デフォルト/最大
net.ipv4.tcp_window_scaling = 1 # ウィンドウスケーリングを有効化トランクポートを通過するパケットが TCP Window Scaling を最大限に活用できるよう、L2/L3の経路全体でMTUの整合性を保つことが、輻輳制御を成功させるための第一歩だ。
—
3. セキュリティ：ネイティブVLANという名の脆弱性
トランクポートの運用において、最も警戒すべきは「ネイティブVLAN」の存在だ。ネイティブVLAN（CiscoでいえばVLAN 1）を介して流れるフレームは、タグが付与されない。
これは、「タグを意図的に外したパケット」をトランクリンクに送り込むことで、本来到達できないはずのVLANへフレームを流し込む「VLANホッピング攻撃」の温床となる。
現場で適用すべき鉄則設定（Cisco IOS例）
! トランクポートから不要なVLANを排除し、攻撃対象領域を最小化する
interface GigabitEthernet0/1
switchport mode trunk
switchport trunk native vlan 999 ! 未使用のVLANをネイティブに指定（VLAN 1は絶対避ける）
switchport trunk allowed vlan 10,20,30 ! 必要なVLANのみに絞り込む
no switchport trunk native vlan tag ! ネイティブVLANのタグ付けを強制してホッピングを防ぐswitchport trunk allowed vlan を指定せずデフォルトの「すべて許可」で放置することは、プロフェッショナルとしてあるまじき行為だ。通信経路を絞り込むことは、単なる管理上の都合ではなく、セキュリティの最前線なのだ。
—
4. 結び：パケットの呼吸を感じるために
ネットワークの挙動は、パケットがワイヤーを駆け巡る「物理的な呼吸」そのものだ。スイッチの設定画面を操作する際、それが「タグを付与するASICの動作」なのか、「カーネルのTCPスタックが再構築を試みる挙動」なのかを脳内でイメージできるか。
- RTT（往復遅延時間）を削減したいなら：トランク上のネイティブVLANを排除し、余計なASIC処理を削ぎ落とせ。
- TLSハンドシェイクを高速化したいなら：TCPウィンドウサイズをチューニングし、初回RTTで証明書データまで押し込めるようにせよ。
インフラアーキテクトに求められるのは、ただ仕様を網羅することではない。プロトコルの隅々に潜む「ゆらぎ」を制御し、いかにして無駄のない、強固なデータパスを構築するか。この追求に終わりはない。
次回の記事では、このL2スイッチングをさらに深掘りし、ARPキャッシュの枯渇とGARP（Gratuitous ARP）によるフェイルオーバーの最適化について解説しようと思う。また深淵を覗きに来てほしい。
コメント