BGP は他のルーティングプロトコルと異なり、「BGP で学習した経路」だけを保持する「BGP テーブル」を持ちます。BGP では複数の Peer から同じ経路を学習した場合、既定のアルゴリズムに従って最善と思われる経路（ベストパス）を選出します。このアルゴリズムのことを「ベストパス選択アルゴリズム（Best Path Selection Algorithm）」と呼びます。BGP テーブル上でベストパスとして選出された経路はルーティングテーブルにインストールされ、実際のパケット転送（の、方路検索）時に利用されます。
従来の RouterOS は鍵交換方式での SSH ログインをサポートしているものの、DSA 鍵にしか対応しておらず、RSA 鍵には対応していませんでした。しかし、まだ RC 版（Release Candidate ＝ リリース候補版）ではあるものの、最新の RouterOS 6.31 からは RSA 鍵にも対応したようです。以下は RouterOS 6.31 の changelog です。
What's new in 6.31rc11 (2015-Jul-28 16:06):
) ipsec - fix replay window, was accidently disabled since version 6.30; ) ssh - allow host key import/export; ) ssh - use 2048bit RSA host key when strong-crypto enabled; ) ssh - support RSA keys for user authentication; ) wireless - improved WMM-PowerSave support in wireless-cm2 package; ) pptp & l2tp - fixed problem where android client could not connect if both dns names were not provided (was broken since v6.30); ) auto upgrade - added ability to select which versions to select when upgrading; ) quickset - fixed HomeAP mode; ) lte - improved modem identification to better support multiple identical modems; ) snmp - fix system scripts table; *) lcd - added LCD package for all architectures (for serial port LCD modules)
今回は現時点の最新バージョンである RouterOS 6.31rc11 で RSA 鍵による SSH ログインを試してみます。
先日、某所で「Windows ファイアウォールが有効（ICMP を拒否）な状態で Ping すると ICMP Request はキャプチャ出来るのか？」という話題が出たので試してみました。
仮想環境を使うと検証がはかどります。ただ、仮想環境上にクローズなネットワークを作って検証する場合は（IP での疎通性が無い為）いちいち VI Client や Web Client からコンソール接続する必要があり、不便です。しかし、VMware では仮想マシンのコンソールをネットワークにリダイレクトする機能があるので、これを使えば VI Client や Web Client を使わなくても仮想マシンのコンソールに接続出来て便利です。今回は CentOS や Ubuntu 等の仮想マシンのコンソールポートに TELNET で接続出来るように設定してみます。
iBGP ではルーティングループの発生を抑える為にスプリットホライズン動作をします。具体的には「ある iBGP Peer で学習した経路を別の iBGP Peer には広告しない」という振る舞いをします。下図はスプリットホライズン動作を図示したものです。ルータ A、B、C はフルメッシュで iBGP 接続されている前提です。
ルータ A は B と C に経路を広告します。しかし、ルータ B は A から学習した経路を C には広告しません（iBGP で学習した経路を他の iBGP Peer には広告しません）。この振る舞いのおかげでルーティングループを防止出来ますが、「iBGP は必ずフルメッシュ構成にしなければならない」とも言えます。フルメッシュ構成時に必要となる iBGP Peer の下図は以下の式で求められます（n = ルータの台数）。
以下の通り、フルメッシュ構成ではルータの台数が増えれば増える程、爆発的に iBGP Peer の総数が肥大化します。
| ルータの台数 | iBGP Peer の総数 |
|---|---|
| 3 | 3 |
| 5 | 10 |
| 10 | 45 |
| 20 | 190 |
| 30 | 435 |
| 40 | 780 |
| 50 | 1,225 |
| 100 | 4,950 |
iBGP Peer の総数が肥大化すると各ルータの CPU やメモリリソースを大量に浪費する、といったデメリットがあります。こういった問題を避ける為には以下の方法があります。
今回は Mikrotik（RouterOS）を RR に設定してみます。
前回は BGP Advertise Best External による BGP のバックアップパスを設定してみました。通常であれば BGP はスプリットホラインズン動作によりループが出来ないように振る舞います。しかし、BGP Advertise Best External を使うとループが発生してしまうことがあります。今回は BGP Advertise Best External 設定環境下で意図的にループを発生させてみます。
通常、BGP スピーカが他の BGP スピーカに広告する経路は最善の経路と選定されたものだけであり、全く同じ複数の経路を広告することは出来ません。つまり、BGP において「ベストパスは常にひとつだけ」であり、「バックアップパス（代替パス）は存在しない」ということになります。しかしながら、バックアップパスがあれば障害によってベストパスが無くなってもいち早くバックアップパスに切り替わることが出来るので収束が早くなる、といった利点があります。バックアップパスを広報する手段として以下の 3 種類が検討されているそうです。
今回は Cisco ルータを使って BGP Advertise Best External によるバックアップパスを試してみます。尚、検証に際しては RFC 以外にも以下の資料を参考にさせて頂きました。
これらの資料を公開してくださった土屋師子生さん、篠宮 俊輔さん、河野 美也さんに敬意を表します。
前回 は Cisco CSR 1000V へ REST API でアクセスしてみました。今回は ASAv へ REST API でアクセスしてみます。必要最低限しか設定していませんので、商用環境で利用する際はセキュリティへの配慮が必要です。
Cisco CSR 1000V に REST API でアクセスする為の設定をまとめておきます。商用環境で利用する際はセキュリティへの配慮が必要です。
VIRL に RouterOS を追加するとルーティングの挙動確認等、論理的な検証は非常に楽になります。そこで今回は VIRL 上で動作する RouterOS の動作イメージを作成し、それを VIRL へ登録してみます。VIRL をお持ちで無い方は GNS3 でも近い手順で似たような検証環境を作れると思います（未検証）。
一点だけ、注意点があります。RouterOS の仕様でライセンス未登録状態だと 24 時間しか利用出来ないそうです。ですが、少なくても私は「短時間で作る・壊すを繰り返す」為、ライセンス未登録状態でも全く困っていません。