VxLAN 공장. 3 부

안녕하세요, 하브르님. 일련의 기사를 마무리하고 있습니다. 강좌 개설을 기념하여 "네트워크 엔지니어" 오투스에 의해, 패브릭 내 라우팅을 위해 VxLAN EVPN 기술을 사용하고 방화벽을 사용하여 내부 서비스 간의 액세스를 제한합니다.

시리즈의 이전 부분은 다음 링크에서 찾을 수 있습니다.

• 주기의 한 부분 - 서버 간 L1 연결
• 시리즈 2부 - VNI 간 라우팅
• 시리즈의 2.5부 - 이론적 여담

오늘 우리는 VxLAN 패브릭 내부의 라우팅 논리를 계속 연구할 것입니다. 이전 부분에서는 단일 VRF 내의 패브릭 내 라우팅을 살펴보았습니다. 그러나 네트워크에는 수많은 클라이언트 서비스가 있을 수 있으며, 이들 모두는 서로 다른 VRF에 분산되어 액세스를 차별화해야 합니다. 네트워크 분리 외에도 기업에서는 이러한 서비스 간의 액세스를 제한하기 위해 방화벽을 연결해야 할 수도 있습니다. 예, 이것이 최선의 솔루션이라고 할 수는 없지만 현대 현실에는 "현대적인 솔루션"이 필요합니다.

VRF 간 라우팅을 위한 두 가지 옵션을 고려해 보겠습니다.

1. VxLAN 패브릭을 떠나지 않고 라우팅합니다.
2. 외부 장비에 대한 라우팅.

VRF 간의 라우팅 논리부터 시작해 보겠습니다. 특정 수의 VRF가 있습니다. VRF 간에 라우팅하려면 모든 VRF(또는 라우팅이 필요한 부분)에 대해 알고 있는 네트워크의 장치를 선택해야 합니다. 이러한 장치는 예를 들어 리프 스위치 중 하나일 수 있습니다(또는 동시에 모두). . 이 토폴로지는 다음과 같습니다.

이 토폴로지의 단점은 무엇입니까?

맞습니다. 모든 Leaf는 네트워크의 모든 VRF(및 그 안에 있는 모든 정보)에 대해 알아야 하며, 이로 인해 메모리 손실이 발생하고 네트워크 부하가 증가합니다. 결국 각 리프 스위치는 네트워크에 있는 모든 정보를 알 필요가 없는 경우가 많습니다.

그러나 소규모 네트워크의 경우 이 옵션이 매우 적합하므로(특정 비즈니스 요구 사항이 없는 경우) 이 방법을 더 자세히 고려해 보겠습니다.

이 시점에서 VRF에서 VRF로 정보를 전송하는 방법에 대한 질문이 있을 수 있습니다. 왜냐하면 이 기술의 요점은 바로 정보의 전파가 제한되어야 한다는 것이기 때문입니다.

그리고 그 대답은 라우팅 정보 내보내기 및 가져오기와 같은 기능에 있습니다(이 기술 설정은 초 주기의 일부). 간단히 반복하겠습니다.

AF에서 VRF를 설정할 때 다음을 지정해야 합니다. route-target для import и export маршрутной информации. Указать его можно в автоматическом режиме. Тогда в значение попадет ASN BGP и L3 VNI, привязанный к VRF. Это удобно, когда у вас в фабрике используется только одна ASN:

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

그러나 ASN이 두 개 이상 있고 그 사이에 경로를 전송해야 하는 경우 수동 구성이 더 편리하고 확장 가능한 옵션이 될 것입니다. route-target. 수동 설정에 대한 권장 사항은 첫 번째 숫자입니다. 예를 들어 다음과 같이 자신에게 편리한 숫자를 사용하세요. 9999.
두 번째는 해당 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 간 라우팅을 위한 두 번째 옵션을 고려해 보겠습니다.

외부 장치를 통해 작업하는 데는 여러 가지 옵션이 있습니다.

1. 장치는 VxLAN이 무엇인지 알고 있으며 이를 패브릭의 일부에 추가할 수 있습니다.
2. 장치는 VxLAN에 대해 아무것도 모릅니다.

논리는 위에 표시된 것과 거의 동일하므로 첫 번째 옵션에 대해서는 다루지 않을 것입니다. 모든 VRF를 방화벽으로 가져오고 VRF 간의 라우팅을 구성합니다.

방화벽이 VxLAN에 대해 아무것도 모르는 경우(물론 VxLAN을 지원하는 장비가 나타나고 있는 경우) 두 번째 옵션을 고려해 보겠습니다. 예를 들어 Checkpoint는 버전 R81에서 지원을 발표했습니다. 이에 대해 읽을 수 있습니다. 여기에그러나 이는 모두 테스트 단계이므로 작동 안정성에 대한 확신은 없습니다.)

외부 장치를 연결하면 다음 다이어그램이 나타납니다.

다이어그램에서 볼 수 있듯이 방화벽과의 인터페이스에 병목 현상이 나타납니다. 향후 네트워크를 계획하고 네트워크 트래픽을 최적화할 때 이 점을 고려해야 합니다.

그러나 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

그러나 원격 Leafs는 어떻습니까? 기본 외부 경로를 어떻게 전달합니까?

맞습니다. VxLAN 패브릭을 통한 다른 접두사와 마찬가지로 EVPN 경로 유형 5를 통해 이루어집니다. 그러나 이는 그리 간단하지 않습니다(다른 공급업체에 확인해 본 적이 없기 때문에 Cisco에 대해 이야기하는 경우).

기본 경로는 방화벽이 연결된 리프에서 보급되어야 합니다. 그러나 경로를 전송하려면 Leaf가 경로를 스스로 알아야 합니다. 그리고 여기에서 특정 문제가 발생합니다(아마도 나에게만 해당). 경로는 해당 경로를 광고하려는 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에 속하며 나머지 Leaf로 전송됩니다.

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