你好哈布爾。 我目前是 OTUS 的“網絡工程師”課程負責人。
期待新課程開始招生 ，我準備了一系列關於VxLAN EVPN技術的文章。
關於 VxLAN EVPN 操作的資料非常多，因此我想收集各種任務和實踐來解決現代數據中心中的問題。
在 VxLAN EVPN 技術週期的第一部分中，我想考慮一種在網絡工廠之上組織主機之間的 L2 連接的方法。
所有示例都將在 Cisco Nexus 9000v 上執行，並組裝在主幹-葉子拓撲中。 在本文中，我們不會詳細討論 Underlay 網絡的設置。
- 底層網絡
- 地址系列 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, intra讓我們檢查一下VPC域是否已經創建，兩台交換機都通過了一致性檢查，並且兩個節點上的設置是否相同：
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 對等互連
最後，我們可以繼續配置覆蓋網絡。
作為本文的一部分，需要在主機之間組織一個網絡，如下圖所示：
要配置 Overlay 網絡，您需要在支持 l2vpn evpn 系列的 Spine 和 Leaf 交換機上啟用 BGP：
feature bgp
nv overlay evpn接下來，您需要在 Leaf 和 Spine 之間配置 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 SPINE在 Spine 上，檢查與所有 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。 進一步的配置僅在Leaf交換機側進行。 Spine僅作為網絡的核心，只參與流量的傳輸。 所有封裝和路徑定義工作僅發生在葉子交換機上。
NVE設置
NVE-- 網絡虛擬接口
在開始設置之前，我們先介紹一些術語：
VTEP - 虛擬隧道端點，VxLAN 隧道開始或結束的設備。 VTEP 不一定是任何網絡設備。 支持VxLAN技術的服務器也可以發揮作用。 在我們的拓撲中，所有 Leaf 交換機都是 VTEP。
VNI - 虛擬網絡索引 - VxLAN 內的網絡標識符。 可以用VLAN來類比。 然而，也存在一些差異。 使用結構時，VLAN 僅在一台葉子交換機內變得唯一，並且不會通過網絡傳輸。 但每個 VLAN 都可以與已通過網絡傳輸的 VNI 編號關聯。 下面將討論它的外觀以及如何使用它。
啟用 VxLAN 技術的功能以及將 VLAN 編號與 VNI 編號關聯的功能：
feature nv overlay
feature vn-segment-vlan-based我們來配置NVE接口，它負責VxLAN的操作。 該接口負責將幀封裝在 VxLAN 標頭中。 您可以與 GRE 的 Tunnel 接口進行類比：
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0在 Leaf-21 交換機上，一切創建都沒有問題。 但是，如果我們檢查命令的輸出 show nve peers，那麼它將為空。 這裡需要返回VPC設置。 我們看到 Leaf-11 和 Leaf-12 通過 VPC 域配對並聯合。 這會導致以下情況：
Host-2 向 Leaf-21 發送一幀，然後通過網絡傳輸至 Host-1。 然而，Leaf-21 發現 Host-1 的 MAC 地址可同時通過兩個 VTEP 使用。 在這種情況下Leaf-21應該怎麼做？ 畢竟，這意味著網絡中可能會出現環路。
為了解決這種情況，我們需要Leaf-11和Leaf-12在工廠內也充當一台設備。 解決起來非常簡單。 在我們從中構建隧道的環回接口上，添加輔助地址。 兩個 VTEP 上的輔助地址必須相同。
interface loopback0
ip add 10.255.1.10/32 secondary因此，從其他VTEP的角度來看，我們得到以下拓撲：
也就是說，現在將在Leaf-21的IP地址和兩個Leaf-11和Leaf-12之間的虛擬IP之間建立隧道。 現在，從兩台設備學習 MAC 地址將不再有問題，並且流量可以從一台 VTEP 傳輸到另一台。 使用 Spine 上的路由表決定兩個 VTEP 中的哪一個將處理流量：
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 可通過兩個下一躍立即可用。
在這個階段，我們已經弄清楚了基本的連接。 讓我們繼續設置 NVE 接口：
我們將立即啟用 Vlan 10 並將其與主機的每個 Leaf 上的 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現在讓我們檢查 BGP EVPN 的 nve 對等點和表：
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 的路由。這種類型的路由談論的是對等點（Leaf），但是我們的主機在哪裡？
事實是，有關 MAC 主機的信息是通過 EVPN 路由類型 2 傳輸的
為了查看我們的主機，您需要配置 EVPN 路由類型 2：
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export auto讓我們從 Host-2 ping 到 Host-1：
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下面我們可以看到路由類型 2 出現在 BGP 表中，主機的 MAC 地址為 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 請求 - 抑制 arp。
該功能的工作原理如下：
- Host-1 向其網絡的廣播地址發送 APR 請求。
- 請求到達 Leaf 交換機，Leaf 不會將此請求進一步傳遞到工廠 Host-2，而是自行應答並指示所需的 IP 和 MAC。
因此，廣播請求沒有發送到工廠。 但如果 Leaf 只知道 MAC 地址，這怎麼行呢？
一切都很簡單，EVPN路由類型2，除了MAC地址之外，還可以傳輸MAC/IP捆綁。 為此，Leaf 必須在 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 內存空間。 我將給出一個抑制arp設置的例子：
hardware access-list tcam region arp-ether 256此設置需要雙寬。 也就是說，如果您設置 256，則必須在 TCAM 中釋放 512。設置 TCAM 超出了本文的範圍，因為設置 TCAM 僅取決於分配給您的任務，並且可能因網絡而異。
- 必須在所有Leaf 交換機上實施suppress-arp。 但是，在位於 VPC 域中的葉對上進行配置時，可能會變得複雜。 當更改 TCAM 時，配對之間的一致性將被破壞，並且一個節點可能會停止服務。 此外，可能需要重新啟動設備才能應用 TCAM 更改設置。
因此，您應該仔細考慮是否值得在您的情況下在工作工廠上實施此設置。
週期的第一部分到此結束。 在下一部分中，我們將考慮通過跨不同 VRF 進行網絡隔離的 VxLAN 工廠進行路由。
現在我邀請大家 ，其中我將詳細介紹該課程。 報名參加本次網絡研討會的前 20 名參與者將在直播後 1-2 天內通過電子郵件收到折扣證書。
來源： www.habr.com