Meraki MXのAuto VPNでは、MXはAuto VPN Peerの状態をTrackingしていません。 そのため、MXは他のOSPF Routerに向けて、Auto VPN Peerの状態に関わらずに、他拠点へのルートをOSPFで常に広報し続ける仕様になっています。
障害時のルーティングの切り替わりへの影響を気にされる方が居ると想定されます。 しかし、MXのRouted Modeでは、Auto VPNを構成しているMX間で重複したサブネットを他拠点に広報できないため、 Auto VPN Peerに障害が発生した場合でも迂回経路が発生しません。 もちろん、PeerがWarm-Spare構成で冗長化されていればSpare (Secondary)側のPeerを通る経路に切り替わります。 ですが、結局はAuto VPNの制御配下のPeerを経由する経路になっている点に変わりはありません。 そのため、Auto VPN Peerの状態をTrackingして、(Auto VPN Peer以外の)迂回経路に切り替わる必要性がない構成であれば、一般的に問題にならないと考えられます。
なお、筆者が本記事を作成した意図ですが、障害試験を行う際のルートの見え方を把握したいため本挙動を調査しておりました。
本挙動は、2022年01月頃にサポートに問い合わせて仕様の確認を行っております。
また、サポートに依頼すると、「MXがAuto VPN Peerの状態をTrackingできるように変更可能」である旨の回答も得ております。
ですが、表立っていない挙動変更を前提として設計するのは、製品の特性に合っていない導入を行うとも解釈できます。
特にMerakiはシンプルさが売りであるため、特殊な構成で導入してしまってから問題が発生するとリカバリが難しくなります。
CiscoのIOS-XE Routerなどは多機能さによるリカバリが行える可能性がありますが、Merakiはシンプル故に豊富な機能は持ち合わせていません。
そして、そもそも論として、サポートへの依頼が必要な機能や、BETA機能を利用するのはリスクを理解した上で有効化すべきです。 そのため、挙動変更を行う際は、十分に内容を検討した上で実施してください。
参考情報として、挙動の検証を行った際の情報を下記に記載します。
目次
検証時の情報
検証構成は筆者の下記の記事をベースとしております。 1点異なる点として、SpokeのMXのDefault route設定をCheckし、MXがFull Tunnelを張ったパターンでのみ検証しております。
正常時の確認
下記の点の確認を行っております。
- 正常時のSpokeのMXのルーティング テーブルの状態の確認
- Auto VPN Peerが正常に起動している点の確認
- ルーティング テーブルにルートが広報されている点の確認
- Auto VPN Peerのサブネットへの疎通が可能である点の確認
正常時と異常時の比較を行うために、SpokeのMXのルーティング テーブルの状態を確認しております。 MXはAuto VPN Peerの状態をTrackingしないため、正常時と異常時で特に変化はありません。
正常時と異常時の比較を行うために、Auto VPN Peerのサブネットへと疎通確認を行っております。 正常時は疎通が可能ですが、異常時には疎通が不可となります。
vyos@vyos:~$
vyos@vyos:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
O>* 0.0.0.0/0 [110/1] via 10.1.0.254, eth0, weight 1, 03:01:33
O>* 10.0.0.0/24 [110/1] via 10.1.0.254, eth0, weight 1, 2d23h43m
O 10.1.0.0/24 [110/1] is directly connected, eth0, weight 1, 2d23h44m
C>* 10.1.0.0/24 is directly connected, eth0, 2d23h44m
O>* 10.2.0.0/24 [110/1] via 10.1.0.254, eth0, weight 1, 2d23h43m
vyos@vyos:~$
vyos@vyos:~$
vyos@vyos:~$ ping 10.2.0.254 source-address 10.1.0.1 count 4
PING 10.2.0.254 (10.2.0.254) from 10.1.0.1 : 56(84) bytes of data.
64 bytes from 10.2.0.254: icmp_seq=1 ttl=62 time=55.0 ms
64 bytes from 10.2.0.254: icmp_seq=2 ttl=62 time=27.5 ms
64 bytes from 10.2.0.254: icmp_seq=3 ttl=62 time=28.4 ms
64 bytes from 10.2.0.254: icmp_seq=4 ttl=62 time=49.0 ms
--- 10.2.0.254 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 27.490/39.960/54.952/12.194 ms
vyos@vyos:~$
異常時の確認
下記の点の確認を行っております。
- 異常時のSpokeのMXのルーティング テーブルの状態の確認
- Auto VPN Peerに障害が発生している点の確認
- ルーティング テーブルにルートが広報され続けたままになっている点の確認
- Auto VPN Peerのサブネットへの疎通が不可になる点の確認
異常時であっても、SpokeのMXのルーティング テーブルには、障害が発生しているAuto VPN Peerのサブネットである 10.2.0.0/24の情報が残ったままになります。
OSPF Router (VyOS)のルーティング テーブルには、障害が発生しているAuto VPN Peerのサブネットである 10.2.0.0/24 が載ったままになっております。
そのため、MXがルートを広報し続けていると判別できます。
そして異常時であるため、Peerのサブネットへの疎通が不可となっています。
vyos@vyos:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
O>* 0.0.0.0/0 [110/1] via 10.1.0.254, eth0, weight 1, 03:23:04
O>* 10.0.0.0/24 [110/1] via 10.1.0.254, eth0, weight 1, 3d00h05m
O 10.1.0.0/24 [110/1] is directly connected, eth0, weight 1, 3d00h05m
C>* 10.1.0.0/24 is directly connected, eth0, 3d00h06m
O>* 10.2.0.0/24 [110/1] via 10.1.0.254, eth0, weight 1, 3d00h05m
vyos@vyos:~$
vyos@vyos:~$
vyos@vyos:~$
vyos@vyos:~$ ping 10.2.0.254 source-address 10.1.0.1 count 4
PING 10.2.0.254 (10.2.0.254) from 10.1.0.1 : 56(84) bytes of data.
--- 10.2.0.254 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3050ms
vyos@vyos:~$
