20年以上ネットワークに携わってきたエンジニアがCatoを担当してみた

私はこれまで20年以上、ネットワークエンジニアとして基幹ネットワーク、データセンターネットワークのに携わってきました。キャリアの初期からCiscoやJuniperをはじめとしたネットワーク製品やセキュリティ製品を中心に扱い、データセンターの運用支援や企業のコアネットワーク、WAN/LANの設計・構築などを経験してきました。Catoを担当する前は、Cisco ACIやCatalyst Centerといったソリューションを主に担当していました。

長年Ciscoを中心としたRouter、Switch、Firewallなどを扱ってきた私にとって、ネットワークを考える際には、LAN/WANの構成、ルーティング、冗長化、通信経路、そしてどこでセキュリティ制御を行うかを整理することが基本にありました。SD-WANについても、インターネットや閉域網など複数の回線をUnderlayとして利用し、その上にOverlayを構成して、拠点間の通信経路を制御するという考え方は理解していました。

見た目だけで考えると、SocketにはWAN側とLAN側のインターフェースがあり、拠点に設置してCato Cloudへ接続します。そのため、これまでの知識に当てはめれば、RouterやSD-WAN Edgeに近い位置付けに見えます。

最初は、「SocketはCato版のRouterやSD-WAN Edge」くらいなんだという感覚で見ていました。ただ、Socketを単純にRouterとして考えると、少し違和感があります。

従来のRouterやSD-WANでは、RouterやWAN Edgeを起点として、Routing Table、Interface、WAN回線、Tunnelなどの状態を確認しながら通信経路を追うという見方をすると思います。

一方、CatoではSocket単体ですべての機能が完結しているわけではなく、SocketからCato Cloudへ接続した先を含めてネットワーク全体を捉える必要があります。

そのため、Socketの役割を理解するには、

LAN側のネットワークをCato Cloudへ接続する拠点側のEdge（接続点）

と捉えると、私には理解しやすくなりました。

つまり、

LAN → Socket → WAN（Underlay）→ Cato Cloud

という関係です。

Socketを従来のRouterと置き換えるイメージで考えていましたが、これが間違いだった様です。

もちろん拠点側のネットワーク機器として見ると、RouterやSD-WAN Edgeと共通する部分もあります。しかしCato全体で見ると、Socketだけを見るのではなく、SocketとCato Cloudを含めた通信経路全体で考える必要があります。

私自身、最初はSocketの中に「従来のRouterのどの機能があるのか」を考えながら学習をしていました。

しかし、

「SocketはRouterなのか？」と考えるより、「SocketはCato Cloudへ接続するために何をしているのか？」と考えた方が、私には理解しやすくなりました。

Socket単体で考えることをやめることで、少しずつ整理できるようになりました。

そして次に気になったのが、SocketからCato Cloudへの接続、つまりOverlayがどのように構成されているのかという点でした。

Socketの役割を整理した次に気になったのが、「Overlayはどこまで張られているのか？」という点でした。

PoPをどう考えるか

ここで私が重要だと感じたのが、PoPの存在です。

従来のサイト間VPNであれば、

一方Catoでは、

さらにSocketのPoP接続は固定的なものではなく、CatoにはPoP選択の仕組みがあります。接続後もConnection SLAによる評価が行われ、パケットロス、ジッター、遅延などが評価指標として使われます。ここも、私がCatoを理解するうえでポイントになった部分でした。

「対向拠点」ではなく「Cato Cloudへの接続」として見る

最初は、「拠点Aから拠点BへのTunnelはどこにあるのか？」という観点で理解をしようとし学習をしていました。

しかしCatoでは、それぞれのSocketとCato Cloudとの接続を起点に考えたほうが、全体像を整理しやすくなります。

Underlayとしてインターネットなどの回線があり、その上でSocketがPoPへ接続する。そして拠点間通信はCato Cloudを介して相手側の拠点へ到達する。

この構成が分かってくると、次に気になったのが、

「拠点Aから拠点Bへのルーティングは、いったいどこで制御されているのか？」という点でした。

従来のRouterを中心としたネットワークであれば、通信経路を確認するときにはルーティングテーブルを確認します。

例えば、ある拠点から別の拠点にあるネットワークへ通信する場合、

「この宛先へのRouteはどこから学習しているのか？」
「Next Hopはどこなのか？」
「どのInterfaceから転送されるのか？」

といった情報を確認しながら、通信経路を追っていきます。Cisco機器を長く扱ってきた私の場合、

などでルーティングテーブルを確認するのは、設計/構築/トラブルシューティングでも馴染みのある方法です。

そのためCatoについても、最初は「Socketのルーティングテーブルを確認すれば、拠点間の経路が見えるのではないか」という感覚で考えていました。

LAN側のルーティングは比較的イメージしやすい

まず、SocketからLAN側を見る部分については、従来のネットワークと比較しても理解しやすいところでした。

例えば、拠点内にL3 Switchがあり、その配下に複数のネットワークが存在する構成を考えてみます。

つまり、

という考え方です。ここまでは、RouterにStatic Routeを設定するときとそれほど大きく変わりません。

「この宛先Networkへ行くためのNext Hopはどこか」

というIPルーティングの基本的な考え方は、Catoでも同じです。

違って見えたのは、その先だった

私が少し感覚の違いを感じたのは、その先です。

従来のネットワークでは、RouterごとのRouting Tableを確認しながら、

というように、各Routerが持っている経路情報を順番に追うことで、End-to-Endの通信経路を理解していました。

一方、Catoでは前章で触れたように、それぞれのSocketがCato CloudのPoPへ接続します。

そのため、拠点間通信も、

という構成で考えることになります。

Routed Networkとして定義されたLAN側ネットワークはCato内へ広告され、他拠点との通信に利用できます。

ここで私の中では、ルーティングの見方が少し変わりました。

Router単体ではなく「SiteとNetwork」で見る

CiscoのRouterを扱っていると、「このRouterがどのルートを持っているのか」を見る癖があります。

ところがCatoでは、それだけでなく、「このSiteには、どのNetworkが存在しているのか」そして、「そのNetworkへCato Cloudを経由して、どのように到達するのか」という見方をした方が、全体像を整理しやすいと感じました。

つまり私の中では、

Router単体のRouting Tableを見て経路を追う

という感覚から、

Siteに存在するNetworkと、そのNetworkへの到達性をCato Cloud全体から見る

という感覚へ少しずつ変わっていきました。

これは「ルーティングを意識しなくてよくなった」という意味ではありません。

むしろ、

• Destination Network
• Subnet
• Next Hop
• Static Route
• LAN側のL3構成
• WAN側への通信経路

といった、従来からあるLayer 3の知識はそのまま必要です。違うのは、それらを見る範囲です。

私にとっては、

「このルートはどのRouterが持っている？」という見方から、「この拠点から相手の拠点まで、通信はどう流れる？」という見方になった。

と考えると、Catoのルーティングが理解しやすくなりました。

BGPも利用できるが、まずはStatic Routeで考えた

もちろん、Catoの経路制御はStatic Routeだけに限定されるわけではありません。

より動的な経路交換が必要な場合にはBGPも利用でき、SocketはBGPによる経路交換に対応しています。CMAからBGP Neighborの受信経路・送信経路を確認することもできます。

ただ、私が最初にCatoのルーティングを理解するうえでは、いきなりBGPから考えるより、

LAN側Network → Next Hop → Socket → Cato Cloud → 対向Site

というStatic Routeをベースにした通信経路から考えた方が、全体を整理しやすく感じました。

また、実際にBGPを利用してLAN側機器とSocket間で経路交換を行う場合には、Cisco RouterでBGPを構成するときと同じ感覚ですべての経路制御ができると考えず、Cato側で利用できる機能や経路制御方法を確認したうえで設計する必要があります。※Catoで利用できるBGP AttributeはCisco等のルータと比較すると限定されるため

ルーティングの考え方そのものは変わらない

Catoを触ってみて感じたのは、CatoだからといってIPルーティングそのものの考え方が変わるわけではない、ということでした。宛先Networkがあり、そのNetworkへのNext Hopを決め、通信を転送する。この基本は変わらないという事が理解出来ました。

一方で、従来のようにRouterを1台ずつ見ながらEnd-to-Endの経路を追うのではなく、Site、Network、Socket、PoP、Cato Cloudまで含めた一つの通信経路として見る。

ここが、私にとって従来のネットワークとの大きな見え方の違いでした。

そして、この通信経路が理解できると、次に気になったのが、

「回線やSocket、PoPに障害が発生した場合、この経路はどのように切り替わるのか？」

という点でした。

次は、冗長化と障害時の経路切り替えについて見ていきます。

従来のネットワークでは、可用性を確保するために、機器や回線を二重化し、それぞれの障害をどのように検知して通信を切り替えるかを設計します。

Ciscoを中心としたネットワークであれば、例えば、

• LAG/MLAG/vPC
• HSRP / VRRP
• Routing Protocol(OSPF/EIGRP/iBGP/eBGP)
• IP SLA
• Route Tracking/Interface Tracking

などを組み合わせて、

「何を監視するのか」
「何をもって障害と判断するのか」
「障害時にどの経路へ切り替えるのか」
「復旧したら元の経路へ戻すのか」

といったことを一つずつ考えていました。そのためCatoでも最初に気になったのは、

「回線障害やSocket障害が発生した場合、いったいどこが障害を検知して、どこで経路を切り替えているのか？」という点でした。

WAN回線の冗長化

まず分かりやすいのが、Socketに接続するWAN回線の冗長化です。

CatoではWAN LinkをActive/ActiveまたはActive/Passiveとして構成できます。Active/Activeでは複数のActive WAN Linkを評価してトラフィックを制御し、Active/Passiveでは通常Primary Linkを使用し、性能がSLA Thresholdを下回った場合にPassive Linkへ切り替える仕組みが提供されています。

ここで面白かったのが、単純にInterfaceのLink Up/Downだけを見ているわけではないという点です。

CatoのSocketとPoPはWAN Linkについて、Latency、Packet Loss、Jitter、Congestionなどを継続的に評価します。Active/Passive構成では、その評価をもとにSmart SLAがFailoverを判断します。 アクティブ/パッシブ ソケットサイトの接続SLA設定の構成

私の中では、

Socket自体を冗長化した場合はどうなるのか

次に気になったのがSocketそのものの障害です。回線を2本にしても、Socketが1台しかなければSocket自体が単一障害点になります。そこでSocketを2台構成にすると、Primary / SecondaryによるHA構成を取ることができます。LAN側ではVRRPが利用され、Socket HAを構成するとVRRPが自動的に作成されます。

イメージとしては、

となります。

従来の構成でもVRRP自体は馴染みがありますが、CatoではSocket HAの一部としてVRRPが組み込まれている点が、私にとっては分かりやすいポイントでした。

従来ネットワークとの違いをどう捉えたか

ここが、私がCatoの冗長化を理解するうえで一番面白いと感じた部分です。従来のネットワークでは、

Catoでも冗長化の基本的な考え方がなくなったわけではありません。

実際、Socket HAのLAN側ではVRRPが使われていますし、WAN LinkのActive/Active、Active/Passiveといった概念もあります。 ただ、私がCatoを触って感じた違いは、

個々のプロトコルや機器の設定から冗長化を見るのではなく、LAN → Socket → WAN Link → PoP → Cato Cloudという通信経路全体から可用性を見る

という点でした。

「VRRPはどう設定するか」「IP SLAとTrackをどう組み合わせるか」

という個々の設定から入るのではなく、「どの障害を想定し、その障害に対してCatoのどの仕組みで通信を継続させるのか」という見方をする。ここでも、RouterやFirewallを1台ずつ見ていたときとは、少し視点が変わったように感じました。

 

のように、構成図を見れば「この通信はどのFirewallを通り、どこでセキュリティポリシーが適用されるのか」を比較的イメージしやすい構成でした。そのためCatoでも最初は、

「Firewallはどこにあるのか？SocketがFiwawall?」という見方をしていました。

しかしCatoでは、Firewallだけでなく、IPSやCASB、DLPなど複数のセキュリティ機能が提供されています。例えばIPSはWAN、Inbound、Outboundのトラフィックを保護対象としており、複数の機能と組み合わせて利用できます。

そのため、「Firewallがどの装置として配置されているのか」を探すよりも、

「Cato Cloudを通る通信に対して、どのセキュリティポリシーが適用されるのか」という視点で見る方が、私には理解しやすく感じました。

私にとって大きかったのは、「Firewallをどこに置くか」から、「通信に対してどのセキュリティポリシーを適用するか」へ考え方が変わったことでした。

ネットワークとセキュリティを別々の装置として追いかけるのではなく、通信経路と、その通信に適用されるセキュリティ制御を一緒に見る。ここまで理解したところで、ようやく最初に感じていた、

「CatoのFirewallはいったいどこにあるのか？」という疑問も少しずつ腹落ちしてきました。

セキュリティの各機能については最初に紹介しました”Catoクラウド エンジニアブログまとめ記事”を見てください！

そのため、GUIからネットワーク全体を管理すること自体に大きな違和感があったわけではありません。

それでもCatoを触り始めたときには、

「SocketのConfigはどこにある？」
「Routingの状態はどこで確認する？」
「TunnelやWAN回線の状態はどこを見る？」
「障害時には何を起点に切り分ける？」
「通信ログはどこで確認する？」

といった疑問はありました。

最初はRouterやFirewall、SD-WANなど、これまで自分が知っているネットワークの構成要素にCatoを一つひとつ当てはめて理解しようとしていました。しかし実際に触れていく中で、Catoは個々の機器だけを見るのではなく、拠点からCato Cloudを経由して宛先へ到達するまでの通信全体として捉えると理解しやすいと感じるようになりました。

もちろん、Routing、冗長化、WAN、Firewallといった、これまで身につけてきたネットワークの知識が不要になるわけではありません。APICやCatalyst Centerのような集中管理の考え方を含め、これまでの経験があるからこそ理解しやすい部分も数多くあります。

一方で、「どの機器をどう設定するか」だけではなく、「通信がどのように流れ、どこで制御され、どう守られているのか」をサービス全体から見る。
この視点の変化が、私にとってCatoを理解するうえで一番大きなポイントでした。

20年以上ネットワークに携わってきましたが、まだまだ新しい発見があります。
これまで培ってきた知識をベースに、新しいネットワークの考え方を理解していくことも、ネットワークエンジニアの面白さなのかもしれません。