この記事はシスコの有志による Cisco Systems Japan Advent Calendar 2024 の 11日目として投稿しています。

前書き

Cisco SD-WANの技術仕様やトラブルシューティング手法について架空人物の会話を通してお届けいたします。

プロローグ

　目を疑うとはまさにこういう光景だった。
　液晶画面を凝視していた男は愕然として目を見開いたまま固まった。

　想定外の事象を目の当たりにした男は、衝撃のあまりに心の中で呟くつもりの言葉を思わず声に出してしまった。

　この無意識に発された一言は廊下を挟んで向かい側の部屋に伝わり一連の推理劇を引き起こすことを、男はこの時点で知る由もなかった。

第一章　安楽椅子探偵

　毎週一番楽しみにしている時間なのに、今回で最後になると思うとやはり寂しくなるね。兎麗莎（とれいさ）は検証センターの221B室こと「ネットワーク＆ミステリー研究室」に入室して読書中の女性に視線を向けながら心の中で嘆いた。

　彼女の名前は詩須子（しすこ）、約1年前から兎麗莎のOJTメンターを務めてきており、兎麗莎の憧れの先輩だ。

　「あっ、兎麗莎ちゃん、お疲れ！今はさ、めっちゃ安楽椅子探偵をやってみたい気分だな〜」と、詩須子が読みかけの『The Nine Mile walk』を机に置いて軽く背伸びをしながら兎麗莎に向かって興奮気味に言った。
　
　「お疲れ様です。あっ、読書の邪魔をしたようですみません。」

　「ううん、ちょうどよかった。ねぇ、なんか簡単な、たとえば20文字くらいの言葉を言ってみて！思いもかけなかった論理的な推論を私が引き出してみせるから！」

　「えっ？あっ、はい！」兎麗莎が頷きながら、どうしようかなと思索を巡らし始めるちょうどその時に、廊下の向こう側から悲鳴（？）のような声が入ってきた。

　「えっはれてる！？暗黙のACL(アクル)は仕事しろよ！」

と兎麗莎には確かにこう聞こえた。

第二章　推理編

「えっはれてる！？暗黙のACL(アクル)は仕事しろよ！」はいかがでしょうか？

おお、なんか神秘な感じね。文字数もちょうどよかったし。うん、これにしよう！

廊下の向こうから届いた声のようなので、サーバ研究室、クラウド研究室、データベース研究室のいずれかの部屋で検証作業とかをやっている人の声だったかもしれませんね。

そうかもね。あっ、こういうメタ推理のところからスタートするのではなくて、あくまでも言葉に着目して推理した方が楽しいよ。たとえば、声の主は明らかに何か想定外のことに遭遇して驚いたね。

確かに喋り方というか、このように伝わってきましたね。「はれてる」という部分に驚いたと思いますけど、何がはれているのでしょうかね？

IPsecやGREなどのトンネルか、OSPFやBGPなどのダイナミックルーティングのネイバーと思う。要は、トンネルが張れているか、ネイバーが張れているという意味の「張れてる」と思う。

なぜですか？向こう側の研究室はどちらかというとサーバ系で、ネットワーク系ではないと思いますけど。

あっ、くどいようでごめん。でも、やはりメタ推理はあまり好きではないので、言葉に着目して推理したのね。特に後半の「暗黙のACL(アクル)は仕事しろよ」のACL、つまりAccess Control Listね。

確かにAccess Control Listが出てくると、「怪我で腫れている」の「腫れてる」でもなく、「天気が晴れている」の「晴れてる」でもないと思いますが、Access Control List自体もいろんな意味があり、ネットワーク系以外の可能性もありますね。

その可能性はすでに考えた。確かにAccess Control Listだけを見ると、Linux系のファイルシステムのAccess Control List、Windows Active DirectoryのAccess Control List、OracleデータベースのAccess Control ListやAWSのS3 Access Control Listなど色々ネットワーク以外のAccess Control Listの可能性もあるね。ただし、Access Control Listの略称である ACLを「アクル」と呼ぶのはほぼネットワークエンジニアしかないと思う。

あっ、言われてみれば確かに！

もちろん、ネットワークエンジニアがサーバ系の作業を行っている可能性もあるけど。その場合でも「張れてる」という用語を自然に使える対象はやはりGREやIPsecのトンネルか、ルーティングプロトコルのネイバーくらいしかないと思う。

なるほど、納得です！ってことは、声の主は想定外のトンネルが張れている事象、あるいは想定外のルーティングプロトコルのネイバーが張れている事象を見て、驚いたということですね。

はい、そうだね。つまり、声の主は本来トンネルかネイバーが絶対「張れない」と想定していたけど、実際にトンネルかネイバーが「張れてる」事象に気付いて驚いた。さらに、声の主はすぐこの想定外の「張れてる」事象は、ACL（アクル）、つまり Access Control Listのせいと断定して、怒っていたと推察できる。

ACLのせいというのは、トンネルかネイバーが「張れない」ように何かの特定のACLを設定したけど、そのACLがうまく機能しなかったということでしょうか？

いや、多分、トンネルかネイバーが「張れない」ようにわざわざ設定したACLが動作しなかったのではなく、元々何も設定しなくても動作するはずのACLが動作しなかったことに怒りを覚えたと思うね。

あっ、そうか。「暗黙のACL(アクル)は仕事しろよ」の「暗黙」の部分を忘れました。確かに、暗黙のACLは文字通りに、設定しなくても動作するACLのことですね。えっと、ということはACLの最後の全部Denyの処理がうまく機能しなかったということでしょうか？

いや、ACLの最後の暗黙のDenyではないと思うよ。なぜなら、状況的にはあの一言は声の主が咄嗟に発した言葉だったので、普段から使い慣れている言葉が自然に口から飛び出たと思う。そう考えると、もしACLの最後の暗黙のDenyのせいであれば、「暗黙のDenyは仕事しろよ」とか、あるいは単に「ACLは仕事しろよ」という表現を使っていたと思う。

確かに、違和感がありますね。そうなると、「暗黙のACL」は、声の主が何か使い慣れているシステム・機器に存在する仕組みで、それはちゃんと機能すれば、トンネルかネイバーが張れないのに、なんらかの理由でうまく機能しなかったということになりますね。結局、その「暗黙のACL」とは何でしょうね？

ここからはやや大胆な推理になるけど、トンネルかネイバーが張れるか張れないかといった文脈で考えると、その「暗黙のACL」が存在するシステム・機器はルータである可能性が高いと思う。

確かに、合理性がありますね。

そして、「暗黙のACL」という表現はどう考えても英語から訳された言葉で、原文はおそらく「Implicit ACL」と思う。試しに、「Router」と「Implicit ACL」の両方をキーワードにしてGoogleで検索してみたら、システム・機器の正体がわかるはずよ。

早速検索してみよう！あっ、出た、上位の検索結果は全部Cisco社のSD-WANルータですね！

やはりそうだね。システム・機器の正体はCisco SD-WANルータと仮定すると、例の「張れてる」の対象はトンネルではなく、OSPFかBGPのネイバーだね。

えっと、それはどうやってわかったのですか？

Cisco SD-WANルータの「暗黙のACL」はallow-serviceとも呼ばれており、仕様的に以下のサービスの制御しかできない。

つまり、基本的にCisco SD-WANルータの「暗黙のACL」の設定だけでは、SD-WANトンネルを阻害することができない。OSPF、BGPは「暗黙のACL」のサービスに含まれているので、「暗黙のACL」の設定次第で、OSPFやBGPのネイバー張れないようにすることができるね。ちなみに、デフォルトでは「暗黙のACL」のOSPFもBGPも無効となっているため、特に何も設定しなくてもOSPFやBGPのネイバーが張れない。

確かに！あっ、でも、SD-WANトンネルの死活監視は確かにBFDを使っているので、「暗黙のACL」のBFDサービスを無効にしたらSD-WANトンネルが張れなくなるのではないのでしょうか？

あっ、ちょっと紛らわしいけど、「暗黙のACL」のBFDサービスはSD-WANトンネルのBFDではなく、ルーティングプロトコルの高速切り替え用のBFDだね。機能名でいうと、「BFD for Routing Protocols in Cisco Catalyst SD-WAN」だね。

なるほど、確かに「暗黙のACL」のBFDサービスはデフォルトで無効ですしね。あっ、でも、トンネルといっても、別にSD-WANトンネルだけでなく、標準IPsec/GREトンネルという可能性もありますよね。これらのトンネルの張れるか張れないかは「暗黙のACL」によって制御できるかは考慮しておく必要がありますね。

その可能性はすでに考えた。「暗黙のACL」の仕様では、コンフィグで明示的に設定された標準IPsec/GREトンネルは自動的に許可されているね。言い換えれば、「暗黙のACL」は明示的に設定されている標準IPsec/GREトンネルを阻害できない。Cisco社のSD-WAN Black Beltトレーニング座学資料の「暗黙のACL」の解説スライドにも記載されているね。

確かにそうでした！Cisco社のSD-WAN Black Beltトレーニング受講時の記憶が蘇った気がしますw

一旦状況を整理してみよう。
　声の主はCisco SD-WANルータで何らかの検証を実施している時に、暗黙のACLのallow-service BGPかallow-service OSPFを無効にしているにもかかわらず、Transport VPN側のBGPかOSPFルータとネイバーが張れている事に気付いて、暗黙のACLが効いていないと思い、「えっはれてる！？暗黙のACL(アクル)は仕事しろよ！」と例の言葉を発した。
　今までの推理で分かったのは、これくらいかしらね。

あの一言からここまで論理的に分析できたのはすごい！
　でも、なんで「張れてる」のでしょう？やはり暗黙のACLの不具合でしょうか？

暗黙のACLの不具合か。。不具合が原因だったらちょっと興醒めだけどねw　せっかくのミステリーなのに。

あっ！ひょっとすると、声の主は暗黙のACLはTransport VPNでしか機能しないことを知らずに、Service VPN側のBGPかOSPFネイバーが張れないように制御しようとしたという可能性は？

その可能性はすでに考えた。声の主はBGPかOSPFのネイバーが想定外に張れている事象に気付いた直後に、暗黙のACLが機能していないと判断し、さらに咄嗟に「えっはれてる！？暗黙のACL(アクル)は仕事しろよ！」という言葉を発したので、Cisco SD-WANにそれなりに詳しい人物と見て問題ないでしょう。
　そもそもあの驚きぶりからすると、多分直前までBGPかOSPFのネイバーが張れないことを検証等で確認済み、暗黙のACLの設定をいじっていないのに、突然にネイバーが張れるようになったというシチュエーションの可能性も低くないと思う。

確かにそうですね。うーむ、謎が深まりましたね。やはり、暗黙のACLがサボっていたのかな。あー、声の主と同じ気持ちになりそうです。
　というか、せめてルーティングプロトコルはBGPかOSPFか特定できればいいのになぁ。そうすると検証もやりやすくなりますね。
　あー、早速検証環境を構築してこの謎を再現してみたくなっちゃう気持ちです。

BGPかOSPFか。。
（Cisco SD-WAN Black Beltトレーニングの座学資料を凝視しつつしばらく思索に耽る）
あっ、わかった！兎麗莎ちゃん、グッジョブ！
謎は全て解けた！

えっ？

真犯人はこの中にいる！

こちらは先ほど見せてもらった暗黙のACLを説明するスライドですね。つまり、やはり真犯人は暗黙のACLということでしょうか？

いや、暗黙のACLは無実だ。暗黙のACLはただ仕様通りに動作していただけだと思う。真犯人の名前（と手口）は、このスライドに記載されているという意味で、「真犯人はこの中にいる！」と言ったのよ。

えっ、どういうこと？焦らさないで、教えてください！

はい。
（ちょっと大袈裟にカッコつけてから、スライドのある文字列にビシッと指を突きつける）
真犯人はあんただ！

第三章　解決編

「フローエントリに一致するリターンパケット（DIA 対応）」は真犯人？

はい。より正確にいうと、真犯人はDIA NATで、手口は「フローエントリに一致するリターンパケット」だ。

えっ、ちょっと意外性がある真犯人ですね。どうやってわかったのですか？

兎麗莎ちゃんのヒントのおかげよw　
　　「せめてルーティングプロトコルはBGPかOSPFか特定できれば」と兎麗莎ちゃんが呟いたじゃん。それを聞いて、暗黙のACLにフォーカスしすぎて、そもそも大事な「被害者特定」はまだやっていないなってことに気づいたの。

被害者特定？

想定外の「張れてる！？」は事件とみなせば、被害を受けたのはネイバーが張れないはずなのに張れてしまった「BGPかOSPF」、あるいはその両方になるよね。けど、Transport VPN側のルーティングでBGPとOSPFの両方を同時に使用する構成は滅多にないし、そもそも状況的に声の主はBGPとOSPF両方の想定外の「張れてる」事象に同時に気づいて例の言葉を発したとも考えにくいので、「被害者」はBGPとOSPFの両方ではなく、BGPとOSPFのどちらかのみ、という可能性が高いと判断しても問題なさそうね。

なるほど！確かに私も無意識にBGPかOSPFのどちらか一方だけが使用されていると認識して、あの再現試験をやりたくなる話を呟きましたね。でもBGPかOSPFの特定はできますか？手がかりが少なく無理な感じですね。

そこは、例のCisco SD-WAN Black Beltトレーニングの座学資料のスライドと、かの名探偵の名言のおかげで、被害者の特定ができ、さらに真犯人も同時に特定できたの！

かの名探偵の名言って？

「When you have eliminated the impossible, whatever remains, however improbable, must be the truth.」
日本語に訳すと、「不可能なものを消去し、最後に残ったのは如何に奇妙なものであっても、それが真実なんだ。」

あっ、シャーロック・ホームズの名言ですね！

はい、まずは例のCisco SD-WAN Black Beltトレーニングの座学資料のスライドをもう一度確認しよう。

このスライドに、暗黙のACLが許可できる通信および条件が記載されているのね。Allow-serviceのBGPもOSPFも無効に設定されている場合、BGPやOSPFの通信は暗黙のACLを通せるか？という観点を踏まえて、一旦表の形に整理すると、以下のようになる。

では、①〜⑦の順番で確認していこう。確認するポイントは、A)設定済みのTransport側のBGPかOSPFのネイバーを阻害もしくは許可する効果があるか、B)BGP、OSPFのネイバー確立への影響は異なるか。

①はコントローラのDTLS/TLSの許可なので、明らかにA)もB)も×

②はSD-WANルータ間のSD-WANトンネルの許可なので、明らかにA)もB)も×

③はSSE等との標準IPsec/GREトンネルなので、明らかにA)もB)も×

④はDIA NAT、つまりローカルブレイクアウトのトラフィックの戻りのパケットの許可なので、通常はサービスVPNのトラフィックにしか適用されないため、A)は×と思われる。ただし、B)は○だね。

ちょっと待って！なんで④のB)は○なんですか？

例えば、不具合や謎の仕様により、万が一Transport VPN側SD-WANルータの自発パケットはDIA NATによりNAT変換された場合、SD-WANルータからピアに送信されるBGPかOSPFのトラフィックの戻りのパケットが④の仕組みにより、暗黙のACL（allow-service BGP/OSPF無効）を突破して戻って来られる可能性があるよね。

不具合や謎の仕様はなんか怖いけど、はい、そうなりますね。

仮にこうなったとしても、BGPはネイバーが張れるが、OSPFはネイバーが張れない。

それはなぜですか？

そろそろOJT卒業する兎麗莎ちゃんなら、BGPやOSPFのネイバー確立の基本についてもうちょっと考えてみると理由がわかると思う。

あっ、はい！
　えっと、BGPはTCPポート179番で通信して、ピアとTCPコネクションを確立してからBGPセッションのやり取りを行い、ネイバーを確立します。
　OSPFはIPプロトコル番号の89番を使用して、マルチキャスト（224.0.0.5）でネイバーを検出・確立します。

あっ、わかりました！仮になんらかの理由でSD-WAN ルータがピアに送信したBGPかOSPFのパケットがDIA NATによりNAT変換されて、さらに戻りのパケットを許可するNATセッションが作成されたとして、TCPコネクションベースのBGPならBGPネイバー確立ができるが、特定のマルチキャストのIPアドレスで通信するOSPFはNATを突破できず、ネイバー確立ができないという理屈ですね！

お見事！その通りよ。
　　残りの容疑者も見ていこう。

⑤、⑥は前提条件となるallow-serviceのBGP、OSPF無効であるため、A)もB)もN/A

⑦はDHCP、DNS、ICMP、HTTPS、SSH、NETCONF、NTP、STUN、SNMP、BFDといった関係のないallow-serviceであるため、明らかにA)もB)も×

一旦整理の結果を表に反映しよう。なお、④のA)の×判定は他の容疑者と比べると弱いため、ちょっとはてなをつけたね。こんな感じになるかな。

この表を見ると、明らかに④番の容疑者は怪しいのですね。でも、SD-WANルータの自発パケット、しかもTransport VPN側の自発パケットは、本当にブレイクアウト用のDIA NATによりNAT変換されるのですかね。にわかに信じがたいのですね。
　そして、④のDIA NAT戻り許可と⑤のallow-service BGP/OSPF無効はどちらがもっと強いかについても疑問が残りますね。

そうね。不具合だったら興醒めなので、先ほど「謎仕様であってくれ！」と変な期待をしつつ、Cisco社のドキュメントを調べたのね。
　そうしたら、こんなのが見つかった。

https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/policies/ios-xe-17/policies-book-xe/localized-policy.html#id_117143

うわぁぁっ！「If a connection is initiated from a device, and if NAT is enabled on the device (for example, Direct Internet Access (DIA) is configured), return traffic is allowed by the NAT entry even if the implicit ACL has been configured as no allow-service .」と丁寧に記載されていますね！

「If a connection is initiated from a device, and if NAT is enabled on the device」の部分は、特にService VPNかTransport VPNを明言していないから、ルータのTransport VPN側の自発のパケットもDIA NATによりNAT変換される可能性がありますね。

そして、「return traffic is allowed by the NAT entry even if the implicit ACL has been configured as no allow-service 」の記載通り、DIA NATの戻り許可はallow-serviceの拒否より強いということですね。

これで犯人確定ですね！さすが詩須子さん！

推理の課題としては、確かにこれでQ.E.D（証明終了）となったかもね。
　けど、ミステリー小説や漫画によくあるパターンとしては、真犯人はなかなか罪を認めず、巧みに詭弁したりするよね。
　やはり、事件の完全解決のためには、動かぬ証拠の提示は必要不可欠だね。

動かぬ証拠？あっ、再現試験ということですね！

はい、その通りよ！
　兎麗莎ちゃんはそろそろOJT卒業＆遠方赴任の予定になっているから、多分研究室の活動は今回で最後になるよね。その集大成として、Cisco SD-WANの環境構築から、事件再現、証拠採取まで一通りやってもらえないかな。

はい、喜んで！

第四章　証拠編

今回の再現試験の環境は最低限コントローラ系とSD-WANルータ１台、レガシールータ１台というシンプルな環境でできるので、Cisco SD-WAN Black Beltトレーニングのハンズオンを全クリアした兎麗莎ちゃんなら、すぐ構築できるね。

はい、もちろん！既存のオンプレのコントローラ環境を使ってすでに構築完了しました！再現試験関連の部分にフォーカスすると、こんな感じの環境ですね。

SJCはSD-WANルータで、INT1はレガシールータです。
　SD-WANルータ（SJC）のVPN0、つまりTransport VPN側でレガシールータ（INT1）とBGPネイバーを確立するための設定を入れています。暗黙のACLはデフォルトの設定のままで、つまりAllow-service BGPは無効となっています。VPN0のインターフェースにNATも設定していません。
　この設定であれば、BGPは想定通りに張れないことは確認しました。

SD-WANルータ（SJC）のshow ip bgp neighborの結果

レガシールータ（INT1）のshow ip bgp neighborの結果

ちょっと待って。そのあとは多分NATを入れて、showコマンド等でBGPはどうなるか確認する予定と思うけど、showコマンドの結果だけなら多分弱いので、動かぬ証拠にならないと思う。さて、どうする？

そこは、ご心配なく！私は、大好きなあのツールを使って事件を再現しつつ動かぬ証拠を採取しますからw
　　そうですね、特殊設定系ミステリー小説風にいうと、死者を蘇らせて事件の全貌をステップごとに再現、いや、追体験する「降霊術」に匹敵する強力なツールを使いますね！

（わざとらしい様子で）おお、そんな便利で強力なツールは世の中にあるとはね！
　（さらにわざとらしく）当ててみようかなw
　SD-WANということで、あの名高いNWPI (Network Width Path Insight)かな？例の、ほら、パケットになった気分でルータの中の各プロセス・機能を探検して細かく可視化すると言われているツール。

今のは「釣り」でしょうw　引っかかりませんよ！w
　NWPIは確かに強力な可視化・トラブル解析のツールですが、VPN0、つまりTransport VPNのトラフィックをサポートしていないため、今回の「張れてる！？事件」の追跡に使えません。

ほー、なるほどねw　では、どんなツールかしらw

それは、みんな大好きなIOS-XE Datapath Packet Trace機能、通称Packet Trace ですね！
指定した条件を満たしたパケットになったつもりで、ルータの各機能・プロセスをそのパケットがどう通って、どのように処理されたかをトレースして、細かい結果を報告してくれるツールです。まぁ、ツールといっても、IOS-XEの標準機能の一つですけどね。

詳細については以下のガイドをご参照いただけます。
https://www.cisco.com/c/en/us/support/docs/content-networking/adaptive-session-redundancy-asr/117858-technote-asr-00.html

さすが兎麗莎ちゃん、いや、わたしのワトソンくんw
　では、黙ってお手並み拝見としようかな。

はい！では、まずはどのようなパケットを追跡するか、つまりPacket Traceの追跡条件を指定する標準ACLを設定しますね。
　はい、こんな感じで設定しました。

次は、この追跡条件を指定するACLをPacket Traceに適用します。
debug platform condition ipv4 access-list 143 both bidirection
さらに、追跡するパケット数を指定します。1024個パケットを追跡してから止まると設定しますね
debug platform packet-trace packet 1024 fia-trace

一旦、show debuggingで設定したPacket Traceの内容を確認しましょう。

いい感じですね。
では、debug platform condition startを実行して追跡をスタートします！

（しばらく待ってから）
　　色々追跡の結果が出ていると思うので、一旦show platform packet-trace summaryを実行して、現状の追跡サマリーを確認しましょう。

いい感じに時系列で追跡の結果が出ていますね。
0番のパケットはInputがINJ.2となっているので、ルータ自発のパケットでピア向けに送信されたBGPのパケットですね。おそらくは最初のTCP Synと思いますけどね。そして無事に送信（FWD）ができました。

1番のパケットはおそらくピアから送信されてきたBGPパケットですね。Gi1で着信した後、期待通りに暗黙のACLによりドロップされましたね。Reasonのところに「SdwanImplicitAclDrop」と親切に記載されているのでわかりやすいのですね。

サマリー情報だけでも色々わかりますけど、パケット番号を指定すると、このパケットはどんな処理をされてきたか全部詳細に確認できます。今回の「張れてる！？事件」の文脈で言うと、いわゆる犯行（？）の追体験ですねw

まずは、show platform packet-trace packet 0コマンドで0番のパケットを確認します

Inputはinternal0/0/rp:0なので、ルータ自発のパケットですね。ピア向けにTCP宛先ポート179番で送信されたので、BGPですね。TCP送信元ポートはランダムに割り当てられた13983となっているところに注目しておきましょう。
このパケットはその後も色々機能で処理されて、最終的に無事にGi1から送出されました。

次はshow platform packet-trace packet 1コマンドで1番のパケットを確認します。

このパケットはピアが0番パケットを受信した後、SD-WANルータに対して送ってきた戻りのパケットですね。TCP宛先ポートは0番パケットのTCP送信元ポートである13983となっていますし、TCP送信元ポートはもちろん179となっていますね。

もうちょっと後続の処理を見てみると、以下の通り、やはりこのパケットはSD-WANルータの暗黙のACLによりドロップされたことがわかりますね。

ドロップの理由については、サマリーより詳細に記載されていますね。暗黙のACLのallow-service BGPは無効（DISALLOW）となっていると。

さすが兎麗莎ちゃん、Packet Traceに慣れていますね。

はい、ありがとうございます！では、こんな要領でどんどん進めていきますね。次はGi1のNATを有効にすると、どうなるか見ていきましょう！

今回の「張れてる！？事件」と言う文脈では、いよいよ犯行の一部始終を再現してみるって感じですね。なんかワクワクしてきましたw。
予想ではこんな動作になりますね。

真犯人登場ということで、少しクローズアップw

コンフィグ差分はこんな感じですね。

あっ、ちょっと待って。Gi1のNATを有効にするだけで、本当に犯行（= 張れてる！？事件）の再現ができるのかな？ローカルブレイクアウトの設定、例えば、NATルートやデータポリシーのNAT VPNも合わせて入れないと、BGPのパケットはブレイクアウトできなかったりするとか。

それも考えましたけど、多分Gi1のNATを有効にするだけで事象の再現ができると思います。
　例のCisco社の公式ドキュメントに「If a connection is initiated from a device, and if NAT is enabled on the device」と記載されていますので、NATを有効にさえすれば、ルータ自発のパケットはNAT変換されると理解しています。私はいつもCisco社のドキュメントを信用していますからw

確かにドキュメントの記載を信用すれば、 NAT有効化だけでルータ自発のパケットはNAT変換されてしまうのね。口を挟んでごめんね！

ううん、詩須子さんのツッコミはいつも勉強になります！では、Gi1のNAT有効化を適用しますね。
　はい、適用完了です！
　早速BGPの状態を確認しよう。
　あっ、BGPネイバーが張れるようになった！

SD-WANルータ（SJC）のshow ip bgp neighborの結果

レガシールータ（INT1）のshow ip bgp neighborの結果

これは例の声の主が見た「張れてる！？」事象だったね。確かに驚きの光景だな。

では、Packet Traceで証拠を採取しますね。
あっ、その前に気になるNATテーブルを確認しますね

うわぁ、ルータ自発のBGPパケットは本当にNATされていますね！ TCP送信元ポートは11563から5062に変換されていますね。念の為、メモしておきましょう。

続きまして、Packet Traceのサマリーを確認しましょう。

0番のパケットはルータ自発のパケットでピア向けに送信されたBGPのパケットですね。前回同様、無事に送信（FWD）ができました。
1番のパケットはピアから送信されてきたBGPパケットですね。Gi1で着信した後、前回は「SdwanImplicitAclDrop」でドロップだったが、今回は「PUNT」で無事にルータ自身宛に届いたようですね。

次は、show platform packet-trace packet 0コマンドで0番のパケットを確認します。

0番のパケットはSD-WANルータがピアに送信したBGPパケットですね。TCP送信元ポートは先ほどのNATテーブルでメモしたNAT変換前の11563と同じですね。
もうちょっと0番のパケットの続きを確認してみると、以下のようにNAT変換されていることがわかりますね。

次は、show platform packet-trace packet 1コマンドで1番のパケットを確認します。

このパケットはピアが0番パケットを受信した後、SD-WANルータに対して送ってきた戻りのパケットですね。TCP宛先ポートは0番パケットのNAT変換後のTCP送信元ポートである5062となっていますね。

もうちょっと後続の処理を見てみると、以下の通り、このパケットはDIA NATの戻りパケットということで、SD-WANルータの暗黙のACLを突破しましたね。

Actionの「ALLOW」のReasonにはっきりと「SDWAN_NAT_DIA」と記されているのは、NAT犯人説の決定的な証拠ですね！
　さすが詩須子さん、いや、私のホームズさん！

ありがとうw じゃ、ホームズさんからワトソンくんへいきなりクイズです！
　「張れてる！？事件」の犯人が分かったけど、何か犯行を止める方法、つまり、NAT有効でもBGPネイバーが張れないようにする方法があるかな？

うーむ、今回の「張れてる！？事件」の一番核心の部分は、いうまでもなくDIA NATの戻りパケットが暗黙のACLを突破できる仕様ですね。
　それ自体は暗黙のACLの仕様であれば、暗黙のACLよりさらに強い何かの仕組みを使えば、その効果を上書きすることができますね。

あっ、わかりました！明示のACLです！明示のACLを使用して通したくないパケットをドロップすることができると思います。

はい、ご名答！

ちょうど検証は物足りなかったので、続いて明示の　ACLを設定して検証をやります！
　えっと、明示のACLを入れると、多分以下のような動作になりますね。

Block_BGPという明示のACLを作成しました。こんな感じですね。

それをGi1のinの方向に適用します。

やはり、BGPネイバーが張れなくなりましたね！

SD-WANルータ（SJC）のshow ip bgp neighborの結果

レガシールータ（INT1）のshow ip bgp neighborの結果

次は、Packet Traceで詳細を色々確認しますね。

0番のパケットはルータ自発のパケットでピア向けに送信されたBGPのパケットですね。今まで同様、無事に送信（FWD）ができました。
1番のパケットはピアから送信されてきたBGPパケットですね。Gi1で着信した後、前回は「PUNT」で無事にルータ自身宛に届いたが、今回は「SdwanAclDrop」、つまり明示のACLによりドロップされたことがわかりますね。