【実務・中級編】アクセスポートの定義と untagged フレームの処理仕様 – インフラ・物理＆L2/L3ネットワーク基礎実践ガイド

VLANの「 untagged 」を制する者は、L2ネットワークの深淵を制する

ネットワークエンジニアとして現場を歩いていると、新人エンジニアから「VLANって、結局フレームにヘッダをくっつけているだけですよね？」と聞かれることがある。半分正解だが、半分は甘い。特に「アクセスポート」における untagged 処理の挙動を深く理解していないと、クラウドの仮想ネットワーク設計や、複雑なコンテナネットワークのトラブルに直面したとき、確実に泥沼に足を取られることになる。

今日は、多くのエンジニアが「なんとなく」で済ませている、IEEE 802.1Qの untagged フレーム処理の核心に切り込んでいこう。

—

1. なぜ「タグなし」が重要なのか？

標準規格 IEEE 802.1Q は、イーサネットフレームのヘッダに4バイトのタグを挿入することで、単一の物理回線上で複数の論理ネットワークを共存させる。ここで登場するのが「アクセスポート」という概念だ。

アクセスポートは、いわば「VLANの境界線」だ。このポートに接続された端末（PCやサーバ）は、自分がVLANに所属していることすら知らない。端末から送信されるフレームは常に untagged であり、スイッチのポートに入った瞬間に、そのポートに紐付けられた PVID (Port VLAN ID) が付与される。逆に、スイッチから端末へ送る際は、タグを剥ぎ取って送出する。

この「剥ぎ取る（Strip）」という処理こそが、レガシーな端末との互換性を保ち、我々が物理層を意識せずにWeb APIを叩ける理由なんだ。

—

2. 通信フロー：パケットは「タグ」をどう脱ぎ着するか

パケットの挙動をシーケンスで追ってみよう。

1. Ingress (入力側):

端末から届いた untagged フレームをスイッチが受信。
ポート設定（access vlan 10など）に基づき、スイッチ内部で VLAN ID: 10 というラベル（内部タグ）を貼り付ける。

2. Switch Fabric (スイッチ内部):

スイッチは「このラベルはVLAN 10宛てだ」と判断し、MACアドレステーブルを引いて出力ポートを決定する。

3. Egress (出力側):

目的のポートが再び「アクセスポート（VLAN 10）」であれば、スイッチは内部タグを削除（Strip）し、untagged フレームとして端末に渡す。
もし出力ポートが「トランクポート」なら、タグを維持したまま送り出す。

この仕組みがあるから、Web APIのクライアントであるアプリケーションは、背後のVLAN構成を一切意識することなく、HTTP GET リクエストを投げられるわけだ。

—

3. 実践：Cisco IOSでの設定と確認

現場でよくあるミスは、ネイティブVLANとアクセスポートの設定の混同だ。実機設定を見てみよう。

! アクセスポートの設定例
interface GigabitEthernet0/1
 description Connected to WebServer-01
 switchport mode access
 switchport access vlan 10  ! このポートに入る全フレームをVLAN 10として扱う
 spanning-tree portfast    ! サーバ接続なら即時転送モードを有効に

ここで重要なのは、show interfaces status や show vlan brief での状態確認だ。

# ポートが正しくVLAN 10に属しているか確認するコマンド
Switch# show vlan id 10

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
10   WEB_TRAFFIC                      active    Gi0/1

もし、設定がミスって native vlan と access vlan が衝突すると、ネットワークは瞬時に「ブラックホール」と化す。デバッグ時は必ずパケットキャプチャを行い、Wireshark 上でタグが見えているか、あるいはタグが剥がされているかを冷静に判断すること。

—

4. 開発者が知っておくべき「その先のレイヤー」

インフラエンジニアだけでなく、Web API開発者もこの「タグの剥離」を意識する瞬間がある。それが、コンテナネットワークや Cloud VPC の設計だ。

例えば、Python でネットワークの状態を簡易チェックする際、OSが仮想NIC越しにタグを認識できない場合がある。これはOS側で 802.1Q のタグを剥がす処理が行われているからだ。

import socket

# 本来、Socket通信レベルではタグは見えない（OSが処理済みのため）
# もしタグが見えるなら、それはNICがプロミスキャスモードであるか、
# vlan-taggingが有効な特殊環境である可能性が高い
def check_network_latency(target_ip):
    # 実際には物理層のVLAN構成の影響を抽象化して通信している
    # インフラ側でVLANミスがあれば、ここは疎通不可となる
    try:
        s = socket.create_connection((target_ip, 80), timeout=5)
        print(f"Connection to {target_ip} successful.")
    except Exception as e:
        print(f"Network unreachable: {e}")

APIのレスポンスが極端に遅い場合や、パケットロスが頻発する場合、アプリケーションレイヤーのコードを疑う前に、「スイッチポートのVLAN設定で untagged 処理が正しく行われているか」という物理・L2の視点を持つこと。これが、一流のインフラアーキテクトへの入り口だ。

—

最後に：現場で生き残るためのTips

自動化の罠: Ansible や Terraform でVLANを設定する際、untagged のポートに trunk 設定を誤爆させる事故は後を絶たない。必ず dry-run を実行し、影響範囲を確認すること。
トラブルシュートの基本: 疎通確認時は ping だけでなく、必ず traceroute を使い、どのホップでパケットが消えているかを確認せよ。タグの不一致は、多くの場合「送信はできるが、戻りのパケットがVLAN不一致でドロップされる」という非対称な挙動を示す。

ネットワークの世界は地味だが、すべての通信の土台だ。君たちが書いたコードが世界に届くのは、こうしたL2の「名もなき処理」が正確に動いているからだということを、忘れないでほしい。

さて、次は「トランクポートにおけるネイティブVLANの危険な挙動」について語ろうか。準備はいいかな？