おい、ハブル。 VxLAN EVPN テクノロジーに関する一連の記事を続けます。 コース開始のために特別に書かれたもの オータス著。 そして今日は、タスクの興味深い部分であるルーティングについて考えてみましょう。 しかし、ネットワークファクトリーの仕事の一部として、それがどれほど平凡に聞こえるとしても、すべてがそれほど単純ではありません。
最後の部分では、Nexus 9000v 上のネットワーク ファブリック上に構築された XNUMX つのブロードキャスト ドメインを実現しました。 ただし、これがデータセンター ネットワークの枠組み内で解決する必要があるタスクのすべてではありません。 そして今日は、ネットワーク間または VNI 間のルーティングというタスクを検討します。
Spine-Leaf トポロジが使用されていることを思い出してください。
まず、ルーティングがどのように発生し、どのような特徴があるかを分析します。
理解を助けるために、論理図を単純化し、ホスト 20000 に別の VNI 2 を追加してみましょう。 結果は次のとおりです。
この場合、トラフィックをあるホストから別のホストに転送するにはどうすればよいでしょうか?
次の2つのオプションがあります。
- すべての VNI に関する情報をすべてのリーフ スイッチに保持すると、すべてのルーティングがネットワークの最初のリーフで行われます。
- 専用の L3 VNI を使用する
最初の方法は簡単で便利です。 すべてのリーフ スイッチですべての VNI を起動するだけでよいためです。 ただし、リーフ全体で数百または数千の VNI を実行することは、もはや簡単な作業ではないようです。 そのため作中では使用頻度が極めて低い。
方法 2 を分析します。これは、より興味深く、少し複雑ですが、工場のセットアップに柔軟性が与えられます。
VRF トポロジに「PROD」を追加しましょう。 リーフ 10/11 ペアにインターフェイス VLAN 12 を追加し、リーフ 20 にインターフェイス VLAN 21 を追加しましょう。 VLAN 20 は VNI 20000 に関連付けられています
vrf context PROD
rd auto ! Route Distinguisher не принципиален и можем использовать сформированный автоматически
address-family ipv4 unicast
route-target both auto ! указываем Route-target с которым будут импортироваться и экспортироваться префиксы в/из VRF
vlan 20
vn-segment 20000
interface nve 1
member vni 20000
ingress-replication protocol bgp
interface Vlan10
no shutdown
vrf member PROD
ip address 192.168.20.1/24
fabric forwarding mode anycast-gatewayL3VNI を使用するには、新しい VLAN を作成し、それを新しい VNI に関連付ける必要があります。 新しい VNI は、VLAN 10 および 20 の情報に関心のあるすべてのリーフで同じである必要があります。
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Создаем L3 VNI
vrf context PROD
vni 99000 ! Привязываем L3 VNI к определенному VRFその結果、図は次のようになります。
少し仕上げる必要があります - もう 99 つのインターフェイスを追加します - VRF PROD のインターフェイス vlan XNUMX
interface Vlan99
no shutdown
vrf member PROD
ip forward ! На интерфейсе не должно быть IP. Используется только для пересылки пакетов между Leafその結果、ホスト 1 からホスト 2 にフレームを渡すロジックは次のようになります。
- Host-1 によって送信されたフレームは、VNI 10 に関連付けられている VLAN 10000 のリーフに到着します。
- リーフは宛先アドレスがどこにあるかを確認し、3 番目のリーフ スイッチ上の LXNUMX VNI 経由でそれを見つけます。
- 宛先アドレスへのルートが見つかるとすぐに、リーフは必要な L3VNI 99000 を含むヘッダーにフレームをパックし、XNUMX 番目のリーフに向けて送信します。
- 3 番目のリーフ スイッチは、L99000VNI 2 からデータを受信します。元のフレームを取得し、それを必要な L20000VNI 20 に転送し、さらに VLAN XNUMX に転送します。
この作業の結果、L3VNI では、ネットワーク上のすべての VNI に関する情報をすべてのリーフ スイッチに保持する必要がなくなります。
その結果、ホスト 1 からホスト 2 にトラフィックを送信すると、パケットは新しい VNI - 99000 を使用して VxLAN 内にパックされます。
Leaf-1 が別の VNI から MAC アドレスをどのように正確に学習するかはまだわかりません。 これは、EVPN ルート タイプ 2 (MAC / IP) を使用しても発生します。
次に、別の VNI にあるプレフィックスに関するルートを伝播するプロセスを示します。
つまり、VNI 20000 から受信したアドレスには XNUMX つの RT があります。
Update から受信したルートは、VRF 設定で指定された Route-target を持つ BGP テーブルに分類されることを思い出してください (プロセスは多少複雑ですが、この記事では説明しません)。
RT 自体は、AS:VNI (自動モードが使用されている場合) という式で形成されます。
自動モードと手動モードでの RT 形成の例:
vrf context PROD
address-family ipv4 unicast
route-target import auto - автоматический режим работы
route-target export 65001:20000 - ручной режим формирования RTその結果、別の VNI からのプレフィックスには XNUMX つの RT 値があることが上記でわかります。
そのうちの 65001 つ 99000:3 は追加の LXNUMX VNI です。 この VNI はすべてのリーフで同じであり、VRF 設定のインポート ルールに該当するため、プレフィックスは BGP テーブルに入ります。これは出力から確認できます。
sh bgp l2vpn evpn
<.....>
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216
10.255.1.10 100 32768 i
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[32]:[192.168.10.10]/272
10.255.1.10 100 32768 i
*>l[3]:[0]:[32]:[10.255.1.10]/88
10.255.1.10 100 32768 i
Route Distinguisher: 10.255.1.21:32787
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]/272 ! Префикс полученный из VNI 20000
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 i受信したアップデートをさらに詳しく見ると、このプレフィックスには XNUMX つの RT があることがわかります。
Leaf11# sh bgp l2vpn evpn 5001.0008.0007
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.255.1.21:32787
BGP routing table entry for [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.2
0]/272, version 5164
Paths: (2 available, best #2)
Flags: (0x000202) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not i
n HW
Path type: internal, path is valid, not best reason: Neighbor Address, no labeled nexthop
AS-Path: NONE, path sourced internal to AS
10.255.1.20 (metric 81) from 10.255.1.102 (10.255.1.102)
Origin IGP, MED not set, localpref 100, weight 0
Received label 20000 99000 ! Два label для работы VxLAN
Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8 ! Два значения Route-target, на основе, которых добавили данный префикс
Router MAC:5001.0005.0007
Originator: 10.255.1.21 Cluster list: 10.255.1.102
<......>Leaf-1 のルーティング テーブルには、プレフィックス 192.168.20.20/32 も表示されます。
Leaf11# sh ip route vrf PROD
192.168.10.0/24, ubest/mbest: 1/0, attached
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, direct
192.168.10.1/32, ubest/mbest: 1/0, attached
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, local
192.168.10.10/32, ubest/mbest: 1/0, attached
*via 192.168.10.10, Vlan10, [190/0], 01:27:22, hmm
192.168.20.20/32, ubest/mbest: 1/0 ! Адрес Host-2
*via 10.255.1.20%default, [200/0], 01:20:20, bgp-65001, internal, tag 65001 ! Доступный через Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Через VNI 99000ルーティング テーブルにプライマリ プレフィックス 192.168.20.0/24 が欠落していることに気づきましたか?
そうです、彼はそこにはいません。 つまり、リモート リーフは、ネットワーク上のホストに関する情報のみを受け取ります。 そして、これは正しい動作です。 上記では、すべてのアップデートに MAC / IP の内容が情報として含まれていることがわかります。 語るべき接頭語はありません。
これはホスト モビリティ マネージャー (HMM) プロトコルであり、ARP テーブルに入力され、そこから BGP テーブルがさらに入力されます (この記事の枠組みではこのプロセスは省略します)。 HMM から受信した情報に基づいて、ルート タイプ 2 の EVPN が形成されます (MAC/IP によって送信されます)。
しかし、プレフィックスに関する情報を渡す必要がある場合はどうすればよいでしょうか?
このタイプの情報については、EVPN ルート タイプ 5 があります。これにより、アドレス ファミリ l2vpn evpn 経由でプレフィックスを送信できます (このタイプのルートは、この記事の執筆時点ではドラフト バージョンのみです) このため、製造元が異なると、このタイプのルートの動作が異なる場合があります)
プレフィックスを転送するには、アドバタイズされる VRF の BGP プロセスにプレフィックスを追加する必要があります。
router bgp 65001
vrf PROD
address-family ipv4 unicast
redistribute direct route-map VNI20000 ! В данном случае анонсируем префиксы подключение непосредственно к Leaf в VNI 20000
route-map VNI20000 permit 10
match ip address prefix-list VNI20000_OUT ! Указываем какой использовать prefix-list
ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0/24 ! Указываем какие сети будут попадать в EVPN route-type 5その結果、アップデートは次のようになります。
BGP テーブルを見てみましょう。 EVPN ルート タイプ 2,3 に加えて、ネットワーク番号に関する情報を含むタイプ 5 ルートが登場しました。
<......>
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:3
* i[5]:[0]:[0]:[24]:[192.168.10.0]/224
10.255.1.10 0 100 0 ?
*>i 10.255.1.10 0 100 0 ?
Route Distinguisher: 10.255.1.11:32777
* i[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
* i[2]:[0]:[0]:[48]:[5001.0007.0007]:[32]:[192.168.10.10]/272
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
* i[3]:[0]:[32]:[10.255.1.10]/88
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
Route Distinguisher: 10.255.1.12:3
*>i[5]:[0]:[0]:[24]:[192.168.10.0]/224 ! EVPN route-type 5 с номером префикса
10.255.1.10 0 100 0 ?
* i
<.......> プレフィックスはルーティング テーブルにも表示されます。
Leaf21# sh ip ro vrf PROD
192.168.10.0/24, ubest/mbest: 1/0
*via 10.255.1.10%default, [200/0], 00:14:32, bgp-65001, internal, tag 65001 ! Удаленный префикс, доступный через Leaf1/2(адрес Next-hop = virtual IP между парой VPC)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! Префикс доступен через L3VNI 99000
192.168.10.10/32, ubest/mbest: 1/0
*via 10.255.1.10%default, [200/0], 02:33:40, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN
192.168.20.0/24, ubest/mbest: 1/0, attached
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, direct
192.168.20.1/32, ubest/mbest: 1/0, attached
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, local
192.168.20.20/32, ubest/mbest: 1/0, attached
*via 192.168.20.20, Vlan20, [190/0], 02:35:46, hmmこれで、VxLAN EVPN に関する一連の記事の第 XNUMX 部を終了します。 次のパートでは、VRF 間のルーティングのさまざまなオプションを検討します。
出所： habr.com