VxLAN 공장. 1 부

안녕하세요, 하브르님. 저는 현재 OTUS 네트워크 엔지니어 과정의 코스 리더입니다.
새로운 과정의 시작을 예상하여 "네트워크 엔지니어", VxLAN EVPN 기술에 대한 일련의 기사를 준비했습니다.

VxLAN EVPN의 작동 방식에 대한 자료가 방대하기 때문에 현대 데이터 센터에서 문제를 해결하기 위한 다양한 작업과 사례를 수집하고 싶습니다.

VxLAN EVPN 기술에 대한 시리즈의 첫 번째 부분에서는 네트워크 패브릭 위에서 호스트 간의 L2 연결을 구성하는 방법을 살펴보고 싶습니다.

모든 예는 Spine-Leaf 토폴로지로 조립된 Cisco Nexus 9000v에서 수행됩니다. 이 글에서는 Underlay 네트워크 설정에 대해 자세히 다루지 않겠습니다.

1. 언더레이 네트워크
2. 주소 계열 l2vpn evpn에 대한 BGP 피어링
3. NVE 설정
4. 억제-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               1

BGP 피어링

마지막으로 오버레이 네트워크 설정으로 넘어갈 수 있습니다.

이 기사의 일부로 아래 다이어그램에 표시된 대로 호스트 간 네트워크를 구성해야 합니다.

오버레이 네트워크를 구성하려면 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 LEAF

Leaf 스위치의 설정은 비슷합니다.

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 설정으로 넘어 갑시다. 추가 구성은 스위치의 리프 측에서만 수행됩니다. Spine은 네트워크의 핵심 역할만 하며 트래픽 전송에만 관여합니다. 모든 캡슐화 및 경로 결정 작업은 리프 스위치에서만 발생합니다.

NVE 설정

NVE - 네트워크 가상 인터페이스

설정을 시작하기 전에 몇 가지 용어를 소개하겠습니다.

VTEP - VxLAN 터널이 시작되거나 끝나는 장치인 가상 터널 끝점입니다. VTEP가 반드시 네트워크 장치일 필요는 없습니다. VxLAN 기술을 지원하는 서버는 서버 역할도 할 수 있습니다. 우리 토폴로지에서 모든 리프 스위치는 VTEP입니다.

VNI - 가상 네트워크 인덱스 - VxLAN 내의 네트워크 식별자입니다. VLAN에 비유할 수 있습니다. 그러나 몇 가지 차이점이 있습니다. 패브릭을 사용하는 경우 VLAN은 하나의 리프 스위치 내에서만 고유해지며 네트워크를 통해 전송되지 않습니다. 그러나 각 VLAN에는 이미 네트워크를 통해 전송된 VNI 번호가 연결되어 있을 수 있습니다. 그것이 어떻게 생겼는지, 어떻게 사용할 수 있는지에 대해서는 더 자세히 논의할 것입니다.

VxLAN 기술이 작동하고 VLAN 번호를 VNI 번호와 연결하는 기능을 활성화해 보겠습니다.

feature nv overlay
feature vn-segment-vlan-based

VxLAN의 동작을 담당하는 NVE 인터페이스를 구성해 보겠습니다. 이 인터페이스는 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은 두 개의 VTEP를 통해 동시에 Host-1의 MAC 주소에 액세스할 수 있음을 확인합니다. 이 경우 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에서 다른 VTEP로 이동할 수 있습니다. 두 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은 두 개의 Next-hop을 통해 즉시 사용 가능합니다.

이 단계에서는 기본적인 연결성을 다루었습니다. 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개 경로만 표시됩니다. 이 유형의 경로는 피어(Leaf)에 대해 이야기하지만 호스트는 어디에 있습니까?
문제는 MAC 호스트에 대한 정보가 EVPN 경로 유형 2를 통해 전송된다는 것입니다.

호스트를 보려면 EVPN 경로 유형 2를 구성해야 합니다.

evpn
  vni 10000 l2
    route-target import auto   ! в рамках данной статьи используем автоматический номер для route-target
    route-target export auto

Host-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(Broadcast, Unknown Unicast, Multicast) 트래픽입니다. 이 기사에서는 브로드캐스트 트래픽을 처리하는 옵션을 고려해 보겠습니다.
이더넷 네트워크의 주요 브로드캐스트 생성기는 ARP 프로토콜을 통한 호스트 자체입니다.

Nexus는 ARP 요청에 대처하기 위해 Suppress-arp라는 메커니즘을 구현합니다.
이 기능은 다음과 같이 작동합니다.

1. 호스트-1은 네트워크의 브로드캐스트 주소로 APR 요청을 보냅니다.
2. 요청은 리프 스위치에 도달하고 이 요청을 Host-2를 향한 패브릭으로 전달하는 대신 리프는 스스로 응답하고 필요한 IP 및 MAC를 나타냅니다.

따라서 브로드캐스트 요청이 공장으로 전달되지 않았습니다. 하지만 Leaf가 MAC 주소만 알고 있다면 이것이 어떻게 작동할 수 있을까요?

모든 것이 매우 간단합니다. EVPN 경로 유형 2는 MAC 주소 외에 MAC/IP 조합을 전송할 수 있습니다. 이렇게 하려면 리프의 VLAN에서 IP 주소를 구성해야 합니다. 질문이 생깁니다. 어떤 IP를 설정해야 합니까? 넥서스에서는 모든 스위치에 분산(동일) 주소를 생성할 수 있습니다.

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 설정은 사용자에게 할당된 작업에만 의존하고 네트워크마다 다를 수 있으므로 TCAM 설정은 이 기사의 범위를 벗어납니다.

• Suppress-arp 구현은 모든 리프 스위치에서 수행되어야 합니다. 그러나 VPC 도메인에 있는 리프 쌍에 구성할 때 복잡성이 발생할 수 있습니다. TCAM이 변경되면 쌍 간의 일관성이 깨지고 한 노드가 작동하지 않을 수 있습니다. 또한 TCAM 변경 설정을 적용하려면 장치를 재부팅해야 할 수도 있습니다.

따라서 현재 상황에서 이 설정을 실행 중인 팩토리에 구현하는 것이 가치가 있는지 신중하게 고려해야 합니다.

이것으로 시리즈의 첫 번째 부분을 마칩니다. 다음 부분에서는 네트워크를 서로 다른 VRF로 분리하여 VxLAN 패브릭을 통한 라우팅을 살펴보겠습니다.

이제 나는 모두를 초대합니다 무료 웹 세미나, 그 안에서 코스에 대해 자세히 설명하겠습니다. 본 웨비나에 등록하는 선착순 20명의 참가자는 방송 후 1~2일 이내에 이메일을 통해 할인 인증서를 받게 됩니다.

출처 : habr.com