こんにちは、ハブル。 私は現在、OTUS のネットワーク エンジニア コースのコース リーダーを務めています。
新規コースの募集開始に向けて , VxLAN EVPN テクノロジーに関する一連の記事を用意しました。
VxLAN EVPN がどのように機能するかについては膨大な量の資料があるため、最新のデータセンターの問題を解決するためのさまざまなタスクと実践方法を収集したいと考えています。
VxLAN EVPN テクノロジーに関するシリーズの最初の部分では、ネットワーク ファブリック上のホスト間の L2 接続を構成する方法を見ていきたいと思います。
すべての例は、スパイン/リーフ トポロジで組み立てられた Cisco Nexus 9000v 上で実行されます。 この記事では、アンダーレイ ネットワークのセットアップについては詳しく説明しません。
- アンダーレイネットワーク
- アドレス ファミリ l2vpn evpn の BGP ピアリング
- NVEのセットアップ
- 抑制-arp
アンダーレイネットワーク
使用されるトポロジは次のとおりです。
すべてのデバイスでアドレス指定を設定しましょう。
Spine-1 - 10.255.1.101
Spine-2 - 10.255.1.102
Leaf-11 - 10.255.1.11
Leaf-12 - 10.255.1.12
Leaf-21 - 10.255.1.21
Host-1 - 192.168.10.10
Host-2 - 192.168.10.20すべてのデバイス間に IP 接続があることを確認してみましょう。
Leaf21# sh ip route
<........>
10.255.1.11/32, ubest/mbest: 2/0 ! Leaf-11 доступен чеерз два Spine
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 2/0 ! Leaf-12 доступен чеерз два Spine
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.21/32, ubest/mbest: 2/0, attached
*via 10.255.1.22, Lo0, [0/0], 00:02:20, local
*via 10.255.1.22, Lo0, [0/0], 00:02:20, direct
10.255.1.101/32, ubest/mbest: 1/0
*via 10.255.1.101, Eth1/4, [110/41], 00:00:06, ospf-UNDERLAY, intra
10.255.1.102/32, ubest/mbest: 1/0
*via 10.255.1.102, Eth1/3, [110/41], 00:00:03, ospf-UNDERLAY, intraVPC ドメインが作成され、両方のスイッチが整合性チェックに合格し、両方のノードの設定が同一であることを確認してみましょう。
Leaf11# show vpc
vPC domain id : 1
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : primary
Number of vPCs configured : 0
Peer Gateway : Disabled
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Disabled
Delay-restore status : Timer is off.(timeout = 30s)
Delay-restore SVI status : Timer is off.(timeout = 10s)
Operational Layer3 Peer-router : Disabled
vPC status
----------------------------------------------------------------------------
Id Port Status Consistency Reason Active vlans
-- ------------ ------ ----------- ------ ---------------
5 Po5 up success success 1BGPピアリング
最後に、オーバーレイ ネットワークの設定に進むことができます。
この記事の一部として、次の図に示すように、ホスト間のネットワークを構成する必要があります。
オーバーレイ ネットワークを構成するには、l2vpn evpn ファミリをサポートするスパイン スイッチとリーフ スイッチで BGP を有効にする必要があります。
feature bgp
nv overlay evpn次に、リーフとスパインの間に BGP ピアリングを構成する必要があります。 セットアップを簡素化し、ルーティング情報の配布を最適化するために、Spine を Route-Reflector サーバーとして構成します。 セットアップを最適化するために、テンプレートを使用してすべての Leaf を構成に書き込みます。
Spine の設定は次のようになります。
router bgp 65001
template peer LEAF
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
route-reflector-client
neighbor 10.255.1.11
inherit peer LEAF
neighbor 10.255.1.12
inherit peer LEAF
neighbor 10.255.1.21
inherit peer LEAFLeaf スイッチのセットアップは次のようになります。
router bgp 65001
template peer SPINE
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
neighbor 10.255.1.101
inherit peer SPINE
neighbor 10.255.1.102
inherit peer SPINESpine で、すべての Leaf スイッチとのピアリングを確認してみましょう。
Spine1# sh bgp l2vpn evpn summary
<.....>
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.255.1.11 4 65001 7 8 6 0 0 00:01:45 0
10.255.1.12 4 65001 7 7 6 0 0 00:01:16 0
10.255.1.21 4 65001 7 7 6 0 0 00:01:01 0ご覧のとおり、BGP には問題はありませんでした。 VxLAN の設定に進みましょう。 さらなる構成はスイッチのリーフ側でのみ行われます。 スパインはネットワークのコアとしてのみ機能し、トラフィックの送信のみに関与します。 すべてのカプセル化とパス決定の作業は、リーフ スイッチ上でのみ行われます。
NVEのセットアップ
NVE - ネットワーク仮想インターフェイス
セットアップを開始する前に、いくつかの用語を紹介しましょう。
VTEP - 仮想トンネル エンド ポイント、VxLAN トンネルが開始または終了するデバイス。 VTEP は必ずしもネットワーク デバイスである必要はありません。 VxLAN テクノロジーをサポートするサーバーもサーバーとして機能できます。 このトポロジでは、すべてのリーフ スイッチが VTEP です。
VNI - 仮想ネットワーク インデックス - VxLAN 内のネットワーク識別子。 VLAN と同様のことが言えます。 ただし、いくつかの違いがあります。 ファブリックを使用する場合、VLAN は XNUMX つのリーフ スイッチ内でのみ一意となり、ネットワーク全体には送信されません。 ただし、各 VLAN には、ネットワーク上ですでに送信されている VNI 番号を関連付けることができます。 それがどのようなもので、どのように使用できるかについては、さらに詳しく説明します。
VxLAN テクノロジーの機能を有効にし、VLAN 番号を VNI 番号に関連付ける機能を有効にしてみましょう。
feature nv overlay
feature vn-segment-vlan-basedVxLAN の動作を担当する NVE インターフェイスを設定しましょう。 このインターフェイスは、VxLAN ヘッダー内のフレームのカプセル化を担当します。 GRE のトンネル インターフェイスと類似することができます。
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0Leaf-21 スイッチでは、すべてが問題なく作成されます。 ただし、コマンドの出力を確認すると、 show nve peers、その後は空になります。 ここで、VPC 構成に戻る必要があります。 Leaf-11 と Leaf-12 はペアで動作し、VPC ドメインによって結合されていることがわかります。 これにより、次のような状況が得られます。
ホスト 2 は、リーフ 21 に 1 つのフレームを送信し、それをネットワーク経由でホスト 21 に送信します。 ただし、リーフ 1 は、ホスト 21 の MAC アドレスが XNUMX つの VTEP 経由で同時にアクセスできることを認識します。 この場合、Leaf-XNUMX は何をすべきでしょうか? 結局のところ、これはネットワークにループが発生する可能性があることを意味します。
この状況を解決するには、Leaf-11 と Leaf-12 が工場内で XNUMX つのデバイスとして機能する必要があります。 解決策は非常に簡単です。 トンネルを構築するループバック インターフェイスに、セカンダリ アドレスを追加します。 セカンダリ アドレスは両方の VTEP で同じである必要があります。
interface loopback0
ip add 10.255.1.10/32 secondaryしたがって、他の VTEP の観点からは、次のトポロジが得られます。
つまり、Leaf-21 の IP アドレスと 11 つの Leaf-12 と Leaf-XNUMX の間の仮想 IP の間にトンネルが構築されます。 これで、XNUMX つのデバイスから MAC アドレスを問題なく学習できるようになり、トラフィックが XNUMX つの VTEP から別の VTEP に移動できるようになります。 XNUMX つの VTEP のどちらがトラフィックを処理するかは、Spine のルーティング テーブルを使用して決定されます。
Spine1# sh ip route
<.....>
10.255.1.10/32, ubest/mbest: 2/0
*via 10.255.1.11, Eth1/1, [110/41], 1d01h, ospf-UNDERLAY, intra
*via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intra
10.255.1.11/32, ubest/mbest: 1/0
*via 10.255.1.11, Eth1/1, [110/41], 1d22h, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 1/0
*via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intra上でわかるように、アドレス 10.255.1.10 は XNUMX つのネクストホップを通じてすぐに利用可能になります。
この段階では、基本的な接続について説明しました。 NVE インターフェイスの設定に進みましょう。
すぐに Vlan 10 を有効にして、ホストの各リーフ上の VNI 10000 に関連付けましょう。 ホスト間にL2トンネルを設定しましょう
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGP次に、NVE ピアと BGP EVPN のテーブルを確認してみましょう。
Leaf21# sh nve peers
Interface Peer-IP State LearnType Uptime Router-Mac
--------- --------------- ----- --------- -------- -----------------
nve1 10.255.1.10 Up CP 00:00:41 n/a ! Видим что peer доступен с secondary адреса
Leaf11# sh bgp l2vpn evpn
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000) ! От кого именно пришел этот l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]/88 ! EVPN route-type 3 - показывает нашего соседа, который так же знает об l2VNI10000
10.255.1.10 100 32768 i
*>i[3]:[0]:[32]:[10.255.1.20]/88
10.255.1.20 100 0 i
* i 10.255.1.20 100 0 i
Route Distinguisher: 10.255.1.21:32777
* i[3]:[0]:[32]:[10.255.1.20]/88
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 i上では EVPN ルート タイプ 3 のルートのみが表示されています。このタイプのルートはピア (リーフ) について話していますが、ホストはどこにあるのでしょうか?
問題は、MAC ホストに関する情報が EVPN ルート タイプ 2 経由で送信されるということです。
ホストを表示するには、EVPN ルート タイプ 2 を構成する必要があります。
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoHost-2 から Host-1 に ping を実行してみましょう。
Firewall2# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 data bytes
36 bytes from 192.168.10.2: Destination Host Unreachable
Request 0 timed out
64 bytes from 192.168.10.1: icmp_seq=1 ttl=254 time=215.555 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=254 time=38.756 ms
64 bytes from 192.168.10.1: icmp_seq=3 ttl=254 time=42.484 ms
64 bytes from 192.168.10.1: icmp_seq=4 ttl=254 time=40.983 ms以下では、ホスト MAC アドレスを持つルート タイプ 2 が BGP テーブルに表示されていることがわかります - 5001.0007.0007 および 5001.0008.0007
Leaf11# 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 ! evpn route-type 2 и mac адрес хоста 1
10.255.1.10 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216 ! evpn route-type 2 и mac адрес хоста 2
* i 10.255.1.20 100 0 i
*>l[3]:[0]:[32]:[10.255.1.10]/88
10.255.1.10 100 32768 i
Route Distinguisher: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 i次に、MAC ホストに関する情報を受け取ったアップデートに関する詳細情報を確認できます。 以下はコマンド出力のすべてではありません。
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.255.1.11:32777 ! отправил Update с MAC Host. Не виртуальный адрес VPC, а адрес Leaf
BGP routing table entry for [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216,
version 1507
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 labe
led nexthop
AS-Path: NONE, path sourced internal to AS
10.255.1.10 (metric 81) from 10.255.1.102 (10.255.1.102) ! с кем именно строим VxLAN тоннель
Origin IGP, MED not set, localpref 100, weight 0
Received label 10000 ! Номер VNI, который ассоциирован с VLAN, в котором находится Host
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Тут видно, что RT сформировался автоматически на основе номеров AS и VNI
Originator: 10.255.1.11 Cluster list: 10.255.1.102
<........>工場でフレームがどのように見えるかを見てみましょう。
ARP の抑制
見事、ホスト間で L2 通信が確立され、そこで終了できるようになりました。 ただし、すべてがそれほど単純ではありません。 ホストが少ない限り問題はありません。 しかし、何百、何千ものホストがある状況を想像してみましょう。 どのような問題に直面する可能性がありますか?
この問題は BUM(ブロードキャスト、不明なユニキャスト、マルチキャスト) トラフィックです。 この記事では、ブロードキャスト トラフィックを処理するオプションについて検討します。
イーサネット ネットワークの主なブロードキャスト ジェネレーターは、ARP プロトコルを介したホスト自体です。
Nexus は、ARP リクエストに対抗するためのメカニズム、suppress-arp を実装しています。
この機能は次のように動作します。
- ホスト 1 は、そのネットワークのブロードキャスト アドレスに APR 要求を送信します。
- リクエストはリーフ スイッチに到達し、このリクエストをホスト 2 に向かうファブリックに渡す代わりに、リーフは自ら応答し、必要な IP と MAC を示します。
したがって、ブロードキャスト リクエストは工場に送信されませんでした。 しかし、Leaf が MAC アドレスしか知らない場合、これはどのように機能するのでしょうか?
すべては非常に単純です。EVPN ルート タイプ 2 は、MAC アドレスに加えて、MAC/IP の組み合わせを送信できます。 これを行うには、リーフ上の VLAN に IP アドレスを設定する必要があります。 どの IP を設定すればよいのかという疑問が生じます。 Nexus では、すべてのスイッチに分散 (同じ) アドレスを作成できます。
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! задаем virtual mac для создания распределенного шлюза между всеми коммутаторами
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! на всех Leaf задаем одинаковый IP
fabric forwarding mode anycast-gateway ! говорим использовать Virtual macしたがって、ホストの観点からは、ネットワークは次のようになります。
BGP l2route evpn を確認してみましょう
Leaf11# 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.21 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.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.0008.0007]:[32]:[192.168.10.20]/248
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
<......>
Route Distinguisher: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
*>i 10.255.1.20 100 0 i
<......>コマンド出力から、EVPN ルート タイプ 2 では、MAC に加えてホスト IP アドレスも表示されることがわかります。
では、suppress-arp の設定に戻りましょう。 この設定は、VNI ごとに個別に有効になります。
interface nve1
member vni 10000
suppress-arp次に、いくつかの複雑さが生じます。
- この機能が動作するには、TCAM メモリにスペースが必要です。 以下に、suppress-arp の設定例を示します。
hardware access-list tcam region arp-ether 256この設定には倍幅が必要です。 つまり、256 を設定した場合は、TCAM で 512 を解放する必要があります。TCAM のセットアップは、割り当てられたタスクのみに依存し、ネットワークごとに異なる場合があるため、この記事の範囲を超えています。
- suppress-arp の実装は、すべてのリーフ スイッチで実行する必要があります。 ただし、VPC ドメイン内に存在するリーフ ペアで設定を行う場合、複雑さが生じる可能性があります。 TCAM が変更されると、ペア間の整合性が失われ、XNUMX つのノードが動作しなくなる可能性があります。 さらに、TCAM 変更設定を適用するには、デバイスの再起動が必要になる場合があります。
そのため、現在の状況において、実行中のファクトリにこの設定を実装する価値があるかどうかを慎重に検討する必要があります。
これでシリーズの最初の部分は終了です。 次のパートでは、ネットワークを異なる VRF に分離した VxLAN ファブリックを介したルーティングについて見ていきます。
そして今、私は皆さんを招待します 、その中でコースについて詳しく説明します。 このウェビナーに登録した最初の 20 名の参加者には、放送後 1 ～ 2 日以内に電子メールで割引証明書が届きます。
出所： habr.com