🥇VxLAN ファクトリー。パート 3

こんにちは、ハブル。一連の記事も終わりつつありますが、 コースの立ち上げに専念「ネットワークエンジニア」オータス著、ファブリック内のルーティングに VxLAN EVPN テクノロジーを使用し、内部サービス間のアクセスを制限するためにファイアウォールを使用します。

シリーズの前の部分は、次のリンクからご覧いただけます。

今日は、VxLAN ファブリック内のルーティングロジックを引き続き学習します。前のパートでは、単一の VRF 内のファブリック内ルーティングについて説明しました。ただし、ネットワーク内には膨大な数のクライアントサービスが存在する可能性があるため、それらすべてを異なる VRF に分散して、それらの間のアクセスを区別する必要があります。ネットワークの分離に加えて、企業はこれらのサービス間のアクセスを制限するためにファイアウォールに接続する必要がある場合があります。はい、これは最善の解決策とは言えませんが、現代の現実には「最新の解決策」が必要です。

VRF 間のルーティングに関する XNUMX つのオプションを検討してみましょう。

VxLAN ファブリックを離れることなくルーティング。
外部機器でのルーティング。

VRF 間のルーティングロジックから始めましょう。 VRF は一定数あります。 VRF 間でルーティングするには、すべての VRF (またはルーティングが必要な VRF 間の部分) を認識するネットワーク内のデバイスを選択する必要があります。そのようなデバイスには、たとえば、リーフスイッチの XNUMX つ (またはすべてを一度に) などがあります。。このトポロジは次のようになります。

このトポロジの欠点は何ですか?

そうです、すべてのリーフはネットワーク上のすべての VRF（およびそこに含まれるすべての情報）について知る必要があるため、メモリの損失とネットワーク負荷の増加につながります。結局のところ、多くの場合、各リーフスイッチはネットワーク上のすべての情報を知る必要はありません。

ただし、小規模ネットワークにはこのオプションが非常に適しているため (特定のビジネス要件がない場合)、この方法をさらに詳しく検討してみましょう。

この時点で、VRF から VRF に情報を転送する方法について疑問が生じるかもしれません。これは、このテクノロジーのポイントはまさに情報の配布を制限することであるためです。

その答えは、ルーティング情報のエクスポートとインポートなどの機能にあります（このテクノロジーの設定は、 2番目のサイクルの一部）。簡単に繰り返します。

AF で VRF を設定する場合は、必ず指定する必要があります route-target インポートおよびエクスポートのルーティング情報用。自動的に指定することも可能です。この値には、VRF に関連付けられた ASN BGP および L3 VNI が含まれます。これは、ファクトリに ASN が XNUMX つしかない場合に便利です。

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! В автоматическом режиме экспортируется RT-65001:99000
    route-target import auto

ただし、複数の ASN があり、ASN 間でルートを転送する必要がある場合は、手動構成の方が便利でスケーラブルなオプションになります。 route-target。手動セットアップの推奨事項は最初の番号です。たとえば、次のような都合のよい番号を使用してください。 9999.
XNUMX 番目は、その VRF の VNI と等しくなるように設定する必要があります。

次のように設定してみましょう。

vrf context PROD10
  address-family ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Пример 1 import из другого VRF
    route-target import 9999:88000         ! Пример 2 import из другого VRF

ルーティングテーブルでは次のようになります。

Leaf11# sh ip route vrf prod
<.....>
192.168.20.0/24, ubest/mbest: 1/0
    *via 10.255.1.20%default, [200/0], 00:24:45, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN          ! префикс доступен через L3VNI 99000

VRF 間のルーティングの XNUMX 番目のオプション、つまりファイアウォールなどの外部機器を経由するオプションを考えてみましょう。

外部デバイスを介して作業するには、いくつかのオプションがあります。

デバイスは VxLAN が何であるかを認識しているので、それをファブリックの一部に追加できます。
デバイスは VxLAN について何も知りません。

ロジックは上記とほぼ同じであるため、最初のオプションについては説明しません。すべての VRF をファイアウォールに移動し、その上で VRF 間のルーティングを設定します。

ファイアウォールが VxLAN について何も知らない場合の 81 番目のオプションを考えてみましょう (もちろん、今では VxLAN をサポートする機器が登場しています。たとえば、Checkpoint はバージョン RXNUMX でのサポートを発表しました。それについてはこちらを参照してください) ここでただし、これはすべてテスト段階であり、動作の安定性には自信がありません）。

外部デバイスを接続すると、次の図が表示されます。

図からわかるように、ファイアウォールとのインターフェイスにボトルネックが発生しています。これは、将来ネットワークを計画し、ネットワークトラフィックを最適化するときに考慮する必要があります。

ただし、VRF 間のルーティングに関する元の問題に戻りましょう。ファイアウォールを追加した結果、ファイアウォールはすべての VRF について認識している必要があるという結論に達しました。これを行うには、すべての VRF が境界リーフ上でも設定され、ファイアウォールが個別のリンクで各 VRF に接続されている必要があります。

その結果、ファイアウォールを使用したスキームは次のようになります。

つまり、ファイアウォール上で、ネットワーク上にある各 VRF へのインターフェイスを設定する必要があります。一般に、ロジックは複雑ではないようです。ここで唯一気に入らないのは、ファイアウォール上の膨大な数のインターフェイスですが、ここで自動化について考えてみましょう。

大丈夫。ファイアウォールを接続し、すべての VRF に追加しました。しかし、各リーフからのトラフィックがこのファイアウォールを通過するようにするにはどうすればよいでしょうか?

ファイアウォールに接続されているリーフでは、すべてのルートがローカルであるため、問題は発生しません。

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, static       ! маршрут по-умолчанию через Firewall

しかし、リモートのリーフはどうなるでしょうか? デフォルトの外部ルートを渡すにはどうすればよいでしょうか?

そうです、VxLAN ファブリック上の他のプレフィックスと同様に、EVPN ルートタイプ 5 を経由します。ただし、これはそれほど単純ではありません（他のベンダーについては確認していないため、Cisco について話している場合）

デフォルトルートは、ファイアウォールが接続されているリーフからアドバタイズする必要があります。ただし、ルートを送信するには、リーフ自身がルートを知っている必要があります。そして、ここで特定の問題が発生します (おそらく私にだけ)。そのようなルートをアドバタイズしたい場合は、ルートを VRF に静的に登録する必要があります。

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

次に、BGP 構成で、AF IPv4 にこのルートを設定します。

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0

しかし、それだけではありません。このようにすると、デフォルトルートはファミリーに含まれなくなります。 l2vpn evpn。これに加えて、再配布を構成する必要があります。

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0
            redistribute static route-map COMMON_OUT

どのプレフィックスが再配布を通じて BGP に入るかを示します

route-map COMMON_OUT permit 10
  match ip address prefix-list COMMON_OUT

ip prefix-list COMMON_OUT seq 10 permit 0.0.0.0/0

さて、プレフィックス 0.0.0.0/0 EVPN ルートタイプ 5 に分類され、リーフの残りの部分に送信されます。

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.255.1.5%default, [200/0], 5w6d, bgp-65001, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN
    ! 10.255.1.5 - Виртуальный адрес Leaf(так как Leaf выступают в качестве VPС пары), к которому подключен Firewall

BGP テーブルでは、5 経由のデフォルトルートを持つルートタイプ 10.255.1.5 の結果も観察できます。

* i[5]:[0]:[0]:[0]:[0.0.0.0]/224
                      10.255.1.5                        100          0 i
*>i                   10.255.1.5                        100          0 i

これで、EVPN に関する一連の記事は終了です。将来的には、この方法のほうがスケーラブルであると考えられるため、マルチキャストと組み合わせた VxLAN の運用を検討してみます (現時点では物議を醸している発言です)。

このトピックに関してまだ質問や提案がある場合は、EVPN の機能を検討してください。さらに検討します。

出所： habr.com

VxLAN ファクトリー。パート3

コメントを追加します返信をキャンセル

VxLAN ファクトリー。 パート3

コメントを追加します 返信をキャンセル

VxLAN ファクトリー。パート3

コメントを追加します返信をキャンセル