好奇心ha盛なhabrachitatelのカットの下で、dmvpnでtsiskaで一度にお金を節約した人々の苦しみの説明を待っています。
また、それがもたらしたもの。
質問の背景
数年前、芝生が緑になり、％company_name％が事業を始めたばかりで、2つの支店があったとき、
Vyatta Network OSを単一のルーティングプラットフォームとして使用し、静的なopenvpnサイト間トンネルをVPNソリューションとして使用することが決定されました。
この決定の理由の1つは、ISRをカスタマイズする豊富な可能性でした。
バックアップ対策の1つとして、各ファイルに2つのルーターをインストールしました。
このような数のピアを持つ星型のトポロジは、正当であると見なされました。
ハードウェアアプライアンスが使用することになっていたので
-esxiを備えたフルサーバー-大規模インストール用
-アトムを備えたサーバー-小さなサーバー用。
突然、1年で支店の数は10に増え、もう1つ半-最大28になりました。
ビジネスからの企業クエストの絶え間ない流れは、トラフィックの増加と新しいネットワークおよびアプリケーションサービスの出現を引き起こしました。
それらのいくつかは、個別のサーバーではなく、Linuxルーターの仮想マシンに落ち着きました。
機能vyattaが失われ始め、多数のパッケージがサービスの全体的な安定性とパフォーマンスに影響を与えました。
また、VPNには多くの問題がありました。
1.その時点で、約100の静的トンネルが1つのポイントで終了していました。
2.将来的には、10の支店がさらにオープンしました。
さらに、現在の実装のopenvpn、
1.動的に生成されたサイト間トンネルの作成を許可しません。
2. 1-2のアップリンクトンネルを備えたルーターのプロセッサで、暗号化により1-2コア（この場合は8〜16）の過負荷を引き起こし、トンネル内のトラフィックに面白い結果をもたらすマルチスレッドではありません。
3.条項2は、プロセッサがAES-NIをサポートしていないルーターに特に典型的です。
gre + ipsecを使用すると、パフォーマンスの問題を解決できますが、トンネルがあり、何百ものトンネルがあります。
非常に悲しいことでした。ハードウェア暗号化を備えたtsiskで暖かくなり、dmvpnを使用したかったのです。
または、すでにグローバルなMPLS VPN。
ささいなことをしないために。
何かをする必要がありました
-おいしい脳とesxiを搭載した1-2xプロセッササーバーがブランチになりました
-ルーターが解凍され、すべてのサードパーティサービスが純粋なLinuxを備えた専用の仮想マシンに移動しました
-いくつかの検索の後、仮想化されたx86 routerosがルーティングプラットフォームとして選択されました。
Mikrotikはそれまでに運用経験があり、x86でのタスクのパフォーマンスと安定性に問題はありませんでした。
鉄のソリューション、特にRB7 **およびRB2011 **では、以前よりも楽しくなりました
潜在的に、そのようなソリューションは、フィールドでの機能の増加をもたらしました
-ルートの再配布
-pbr + vrf
-MPLS
-ピム
-QoS
他にもいくつかあります。
問題は、ルーター（vyattaなど）がマルチポイントVPNをサポートしていないことでした。
再び悲しいことになり、彼らは純粋にLinuxのフルメッシュソリューションに向かって掘り始めました。
ちなみに、彼の記事の ValdikSS habrayuzerに感謝します 。
レビューされた：peervpn、tinc、campagnol、GVPE、Neorouter、OpenNHRP、Cloudvpn、N2N
その結果、妥協案としてtincvpnに決めました。
また、エキゾチックなカプセル化方式を使用したgvpeが大好きでしたが、リモートピアに複数のIP（異なるISPから）を指定することはできませんでした。
なんて残念なことに、チンクもシングルスレッドでした。
解決策として、ダーティハックが使用されました。
1.各2つのメンバー間では、メッシュは1ではなく、N個のトンネルで上昇します。これらのトンネルは、発信トラフィックバランシングを備えたボンドインターフェイスに結合されます。
2.結果として、異なるコア間ですでに分散可能なN個のプロセスが既にあります。
指定されたスキームを使用する場合、ラボで
-指定されたスキームに従って1つの結合に集約された8つのTincインターフェイス
-プロセスを異なるコアに強制的にバインド
-1 x xeon 54 **、55 **（aes-niサポートのない旧世代プロセッサ）
-aes128 / sha1
-転送プロトコルとしてのudp。
-トンネルの内側と外側の両方でQoSを使用しない。
VPNのパフォーマンスは、ギガビットチャネルで約550〜600 mbpsでした。
助かりました。
何が起こった：
1.最終決定には、「vpn-pair」という作業名が付けられました。
2. 1つのesxiホストに配置され、仮想インターフェイスによって結合された2つの仮想マシンで構成されます。
1-ルーティングの問題のみを扱うrouteros
2-なめられ、わずかにドープされたチンクを持つ純粋なLinux。
VPNブリッジとして機能します。
ティンク構成はラボの構成に似ていますが、ボンドインターフェースはマイクロティックへの仮想リンクでブリッジされています。
その結果、すべてのルーターに共通のL2があり、ospfを上げて楽しむことができます。
3.各ブランチには2つのvpnペアがあります。
...継続する...
注釈
1.原則として、tincはvyattaに統合することができます。このためのパッチも作成されました（1つのインターフェースを持つオプションの場合）。
ただし、緊急時（またはプラットフォームの更新後）にカスタムパッチを使用してこのようなバンドルの動作を予測することは最後まで困難であり、このような実験は大規模なネットワークには望ましくありません。
2.「マトリョーシカ」オプションも検討されました。
彼には2つの方向がありました。
-ハードウェアx86 Mikrotikの購入および統合仮想化（KVM）によるvpn-bridgeを使用したlinux-vmのサポート。
悪いパフォーマンスのために離陸しませんでした。
-ネストされた仮想化（esxi-> routeros-> kvm-> linux）。
esxi 5.1でVT-X / EPTエミュレーションがサポートされていないため（kvmマシンを起動する必要があるため）、同じ理由で離陸しませんでした。