本記事に掲載している構成、機器名、IPアドレス、VLAN番号、ネットワーク構成およびコマンド出力は、説明用に置き換えた仮の情報です。筆者の環境とは関係ありません。
1 はじめに
あるとき、ネットワーク環境を確認していると不思議な状態に気づきました。
L2スイッチにip default-gatewayが設定されていないのに、L2スイッチ自身が外部ネットワークと通信できている!?
通常、異なるIPネットワークと通信するにはip default-gatewayの設定が必要なはず。
ところが、実際に外部ネットワークのIPアドレスへpingを実行すると問題なく応答が返ってきました。
ip default-gatewayが設定されていないのに通信できるのはなぜ?
今回は、L2スイッチの設定、疎通結果およびARPテーブルを確認しながら通信が成立している理由を考えてみます。
本記事ではL2スイッチの管理SVIとは異なるIPネットワークを「外部ネットワーク」と表記します。インターネットに限定した表現ではありません。
本記事は、確認できた設定、疎通結果およびARPテーブルをもとに、通信が成立している仕組みを考察したものです。
パケットキャプチャや設定変更による比較検証は実施していないため、確認できた事実と推測を分けて記載します。
2 確認した構成と設定
まず、今回の記事で説明する構成は次のような構成になります。
外部ネットワークA ─┐
├─ 上位L3SW ─ L2SW
外部ネットワークB ─┘ └ 管理SVI
説明用の仮設定はこんな感じです。
L2スイッチ
| 項目 | 設定・状態 |
|---|---|
| 管理SVI | Vlan100 |
| IPアドレス | 192.168.0.100/24 |
ip routing |
無効 |
ip default-gateway |
未設定 |
| デフォルトルート | なし |
上位L3スイッチ
| 項目 | 設定・状態 |
|---|---|
| 接続SVI | Vlan100 |
| IPアドレス | 192.168.0.1/24 |
Vlan100のMACアドレス |
aaaa.bbbb.cccc |
| 外部ネットワークへの経路 |
10.0.0.0/24、172.16.0.0/24
|
| Proxy ARP | 有効 |
その他の条件は次のとおり。
-
ip routingは無効 -
ip default-gatewayは未設定 - デフォルトルートは存在しない
- 管理SVIにはIPアドレスが設定されている
- 上位L3スイッチは外部ネットワークへの経路を持っている
- 上位L3スイッチの対象インターフェースではProxy ARPが有効
本記事で取り上げるのは、管理SVIを送信元としたL2スイッチ自身の通信です。
L2スイッチに接続されているPCやサーバーなどの通信は、それぞれのデバイスに設定されたIPアドレス、サブネットマスクおよびデフォルトゲートウェイに従います。
L2スイッチのip default-gatewayは、L2スイッチ自身が外部ネットワークと通信するための設定であり、接続されているデバイスの通信経路を指定するものではありません。
3 ARPの基本動作
ARP(Address Resolution Protocol)は、IPv4アドレスに対応するMACアドレスを調べるためのプロトコルです。
イーサネット上で通信するには、宛先IPアドレスだけでなくフレームを送信する宛先MACアドレスも必要になります。
同一ネットワーク宛ての場合
例えば192.168.0.100/24から同一ネットワークにある192.168.0.20へ通信する場合、送信元は192.168.0.20のMACアドレスを調べるためにARP Requestをブロードキャストします。
192.168.0.20のMACアドレスを教えてください
192.168.0.20を持つデバイスは、自身のMACアドレスをARP Replyで返します。
192.168.0.20のMACアドレスは
bbbb.bbbb.bbbbです
送信元は、受信したIPアドレスとMACアドレスの対応をARPテーブルへ登録します。
192.168.0.20 → bbbb.bbbb.bbbb
異なるネットワーク宛ての場合
次に192.168.0.100/24から異なるネットワークにある10.0.0.10へ通信する場合を確認しましょう。
異なるネットワークと通信する場合は、デフォルトゲートウェイと通信する必要があります。
そのため、まずはデフォルトゲートウェイである192.168.0.1のMACアドレスを調べるためにARP Requestをブロードキャストします。
192.168.0.1のMACアドレスを教えてください
ここでのARPは、最終宛先の10.0.0.10ではないことに注目。
192.168.0.1を持つデフォルトゲートウェイは自身のMACアドレスをARP Replyで返します。
192.168.0.1のMACアドレスは
cccc.cccc.ccccです
送信元は受信したIPアドレスとMACアドレスの対応をARPテーブルへ登録します。
192.168.0.1 → cccc.cccc.cccc
これでデフォルトゲートウェイのMACアドレスが分かったので、送信元は10.0.0.10宛てのIPパケットを、デフォルトゲートウェイのMACアドレスへ送信します。
送信元IPアドレス : 192.168.0.100
宛先IPアドレス : 10.0.0.10
送信元MACアドレス: aaaa.aaaa.aaaa
宛先MACアドレス : cccc.cccc.cccc
ここで、パケットの宛先IPアドレスは10.0.0.10のままです。
一方、宛先MACアドレスにはデフォルトゲートウェイのcccc.cccc.ccccが使用され、以降の通信はデフォルトゲートウェイ宛のユニキャスト通信となります。
デフォルトゲートウェイがない場合
では、そのデフォルトゲートウェイが設定されていない場合はどうなるのでしょうか。
宛先が異なるネットワークに存在するにもかかわらず、デフォルトゲートウェイが設定されていない場合、ARPでMACアドレスを調べる対象のIPアドレスがわかりません。
異なるネットワーク宛て
↓
デフォルトゲートウェイを確認
↓
設定されていない
↓
ARPでMACアドレスを調べる対象のIPアドレスがわからない
↓
通常は最終宛先をARPせず、通信できない
この場合は最終宛先のMACアドレスをARPで解決するのではなく、ARPをしないまま宛先へ到達できないと判断されます。
ここが今回の事象の肝になるところ。
通常想定される動作をまとめるとこんな感じ。
- 同一ネットワーク宛ての場合は、最終宛先IPアドレスをARPする
- 異なるネットワーク宛ての場合は、デフォルトゲートウェイをARPする
- 異なるネットワーク宛てで、デフォルトゲートウェイが設定されてない場合は、通常はARPせず、通信できない
4 Proxy ARPについて
ここでProxy ARPについて簡単に説明します。
例えばルータを挟んで次の2つのネットワークがあったとします。
端末A ── ルータA ── ルータB ── 端末B
端末A:172.16.0.100/16
端末B:172.16.10.100/24
前提として、端末Aはサブネットの存在を認識しておらず172.16.0.0/16を1つのネットワークとして扱っているものとします。また、ルータAは172.16.10.0/24への経路を学習しているものとします。
このとき、端末Aから端末Bへ通信を行う場合どうなるか確認しましょう。
端末Aから見ると、端末Bの172.16.10.100は自身と同じ172.16.0.0/16に存在すると判断します。
そのため、端末Aはデフォルトゲートウェイではなく、最終宛先である172.16.10.100のMACアドレスを調べるためにARP Requestをブロードキャストで送信します。
172.16.10.100のMACアドレスを教えてください
しかし、端末Aと端末Bはルータ2台を挟んだ異なるネットワークに存在します。
ARP RequestはルータAを越えないため、端末Bには届きません。また、ルータA自身のIPアドレスも172.16.10.100ではないため、通常のARPでは応答しません。
その結果、端末Aは172.16.10.100のMACアドレスを解決できず、端末Bと通信できません。
これを解決するのがProxy ARPです。
Proxy ARPが有効なルータは、自身が宛先ネットワークへの経路を持っている場合、実際の宛先に代わって自身のMACアドレスをARP Replyで返します。
端末A
「172.16.10.100のMACアドレスを教えてください」
↓
ルータA
「172.16.10.100のMACアドレスはaaaa.aaaa.aaaa(ルータAのMACアドレス)です」
ルータAは、実際には172.16.10.100を持っていません。
それでも、172.16.10.0/24への経路を持っているため、実際の宛先に代わって自身のMACアドレスを回答します。
端末AのARPテーブルには、次の対応が登録されます。
172.16.10.100 → aaaa.aaaa.aaaa(ルータAのMACアドレス)
端末Aは、172.16.10.100宛てのIPパケットをルータAのMACアドレスへ送信します。その後、ルータAが受信したIPパケットを本来の宛先であるルータBへ転送します。
端末Aからは端末Bと直接通信しているように見えますが、実際のイーサネットフレームはルータAへ送信されています。
RFC 1027では、サブネットの存在を認識できないホストに対し、サブネットを意識させずに通信させる仕組みとしてProxy ARPが説明されています。
また、Ciscoの公式資料でも、Proxy ARPによって、デフォルトゲートウェイや経路設定を持たない端末がリモートネットワークへ到達できる場合があると説明されています。
5 今回の事象
さて、説明が長くなりましたが、今回の事象をもう一度確認してみます。
- L2スイッチには
ip default-gatewayが設定されていない - それにもかかわらず、L2スイッチ自身が外部ネットワークと通信できている
今回の外部ネットワークは、Proxy ARPの説明で使用したような、サブネットマスクの違いによって同一ネットワークと判断されるアドレスではありません。管理SVIとは明確に異なるネットワークのアドレスです。
しかし、実際にL2スイッチから複数の外部ネットワークへpingを実行すると、ちゃんと応答が返ってきました。
以下は、IPアドレスやMACアドレスを説明用の値へ置き換えた出力例です。
L2SW# ping 10.0.0.1 source Vlan100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.100
!!!!!
Success rate is 100 percent (5/5)
このとき、L2スイッチのARPテーブルはどうなっているかというと、
L2SW# show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.0.1 2 aaaa.bbbb.cccc ARPA Vlan100
Internet 10.0.0.1 0 aaaa.bbbb.cccc ARPA Vlan100
Internet 172.16.0.1 0 aaaa.bbbb.cccc ARPA Vlan100
複数の外部ネットワークにある宛先IPアドレスがARPテーブルに登録されており、対応するMACアドレスはすべて上位L3スイッチのMACアドレスと一致していました。
この結果を見ると、上位L3スイッチのProxy ARPによって通信が成立している可能性が高そうです。
では、なぜProxy ARPが動作したのか?
Proxy ARPが動作するためには、上位L3スイッチがARP Requestを受信する必要があります。ARP Requestを受信していなければ、Proxy ARPによるARP Replyも返せません。
先に説明した一般的な動作では、異なるネットワーク宛てでデフォルトゲートウェイが設定されていない場合、通常は最終宛先をARPせず、通信できないと判断されるはずです。
それにもかかわらず、今回のL2スイッチでは、外部ネットワークが上位L3スイッチのMACアドレスと対応付けられてARPテーブルに登録されています。
つまり、今回のL2スイッチは、一般的に想定される動作とは異なり、ip default-gatewayがない状態で、管理SVIから外部ネットワークについて何らかのARP Requestを送信した可能性が高いと考えられます。
一般的に想定される動作
異なるネットワーク宛て
↓
デフォルトゲートウェイがない
↓
次の送信先を決定できない
↓
最終宛先をARPせず、通信できない
今回確認したと考えられる動作
異なるネットワーク宛て
↓
デフォルトゲートウェイがない
↓
L2スイッチが外部宛先IPアドレスについてARP Requestを送信
↓
上位L3スイッチがProxy ARPで応答
↓
外部宛先IPアドレスと上位L3スイッチのMACアドレスが
ARPテーブルへ登録
↓
通信成立
ただし、今回はパケットキャプチャを実施していないため、実際に送信されたARP Requestそのものは確認できていません。
確認できた事実は、外部ネットワークがARPテーブルに存在し、対応するMACアドレスが上位L3スイッチと一致していたことです。
6 なぜL2スイッチは外部宛先をARPしたのか
Proxy ARPによって、ARP Requestを受信した後の上位L3スイッチの動作は説明できます。
しかし、なぜL2スイッチが異なるネットワークにある宛先IPアドレスをARPしたのかは、今回確認した範囲では分かりませんでした。
Cisco Communityでは、一部のCatalystについて、ip default-gatewayが設定されていない場合に外部ネットワークに対してARPする挙動が報告されています。
一方、この挙動をCatalystの仕様として明記したCisco公式資料は見つけられませんでした。
ほかにも、次の点は分かっていません。
- どの機種やソフトウェアバージョンで発生するのか
-
ip default-gateway未設定時に常に発生するのか - 複数のSVIにIPアドレスがある場合、どのSVIからARP Requestを送信するのか
- 複数のSVIから同じ宛先についてARP Requestを送信する可能性があるのか
このあたりは検証できる環境があればいいのですが、いかんせん筆者の環境では準備できず、、、
そのため、ip default-gatewayが未設定の場合にCatalystが必ず外部宛先をARPすると言い切れず、なんとも歯がゆい結果で終わりました。
7 結果的に条件がかみ合って通信できた可能性
以上のことから、今回ip default-gatewayが設定されていないL2スイッチから外部ネットワークへ通信できたのは、次の2つの条件が結果的にかみ合ったためと推察します。
L2スイッチ側
`ip default-gateway`が未設定でも、
外部宛先IPアドレスについてARP Requestを送信する挙動
+
上位L3スイッチ側
外部ネットワークへの経路を持ち、
Proxy ARPが有効になっていた
↓
`ip default-gateway`が未設定でも外部ネットワークとの通信が成立
これは、Proxy ARPをip default-gatewayの代わりとして意図的に利用したわけではありません。
L2スイッチの機種やソフトウェアの挙動と、上位L3スイッチで有効になっていたProxy ARPが結果的にかみ合ったことで通信できていたと考えるのが妥当です。
そのため、今後も同じ条件で通信し続けられる保証はありません。上位L3スイッチでProxy ARPが無効化された場合や、機器更改によってL2スイッチの挙動が変わった場合、外部ネットワークと通信できなくなる可能性があります。
8 まとめ:ip default-gatewayを設定しましょう
今回確認したL2スイッチは、ip default-gatewayが設定されていないにもかかわらず、外部ネットワークと通信できていました。
ARPテーブルを見ると、外部ネットワークのIPアドレスに対して、上位L3スイッチのMACアドレスが登録されています。
このことから、L2スイッチが外部ネットワークの宛先についてARP Requestを送信し、上位L3スイッチがProxy ARPで応答したことで、通信できていた可能性が高そうです。
ただし、今回の通信は、L2スイッチの挙動と上位L3スイッチのProxy ARPが、結果的にかみ合ったもの。
上位L3スイッチでProxy ARPが無効化されたり、機器更改によってL2スイッチの動作が変わったりすると、通信できなくなる可能性があります。
また、同一ネットワーク上にProxy ARPで応答可能なL3機器が複数存在する場合、どのL3機器からの応答が採用されるか予想できず、想定外の経路で通信するリスクも考えられます。
CiscoのCatalyst設定ガイドでも、デフォルトゲートウェイは、スイッチが外部ネットワークと通信するために必要なIP設定の一つとして扱われています。
通信できるからといって、設定しなくてもいいかは別の話です。
L2スイッチ自身が外部ネットワークと通信する場合は、暗黙的な動作へ依存せず、意図した上位L3機器をデフォルトゲートウェイとして明示しましょう。
結論、よいこはip default-gatewayを設定しましょう!
参考
- RFC 826: An Ethernet Address Resolution Protocol
- RFC 1027: Using ARP to Implement Transparent Subnet Gateways
- RFC 1122: Requirements for Internet Hosts - Communication Layers
- Understand Proxy ARP - Cisco
- IP Addressing Configuration Guide, Cisco IOS XE 17.x - Address Resolution Protocol
- Assigning the Switch IP Address and Default Gateway - Cisco Catalyst 2960
- ip default-gateway - Cisco Community
- Proxy Arp and Switches without "ip default-gateway" configured - Cisco Community
- proxy arp - Cisco Community
- Switching and Default-Gateway statement - Cisco Community
Cisco Communityはユーザー間の技術情報交換を目的としたコミュニティです。本記事では、同様の事象が報告されている参考事例として掲載しており、Ciscoの公式仕様を示す根拠としては扱っていません。