EVPN 방화벽 정책: 중앙 집중 게이트웨이와 분산 IRB
중앙 집중 게이트웨이는 테넌트 트래픽을 방화벽을 통해 보내고 분산 IRB는 그렇지 않습니다. 각각 어디에서 검사하는지와 고속 경로에 무엇이 필요한지 비교합니다.
두 가지 EVPN 설계는 테넌트 게이트웨이를 서로 다른 위치에 두며, 방화벽은 각각에서 다른 트래픽을 봅니다. 중앙 집중 게이트웨이에서는 서브넷 간 트래픽이 방화벽에 도달합니다. 라우팅이 바로 그곳에서 일어나기 때문입니다. 분산 IRB에서는 leaf 스위치가 로컬에서 라우팅하므로 의도적으로 넣지 않는 한 방화벽은 아무것도 보지 못합니다. 어느 모델도 틀리지 않았습니다. 틀린 것은 경계에 방화벽을 붙이고 fabric이 트래픽을 전달해 줄 것이라고 가정하는 것입니다.
두 모델, 두 가지 검사 지점
먼저 검사가 필요한 흐름을 지목하십시오. 두 모델이 그것을 다르게 다루기 때문입니다.
| Flow class | Centralized gateway | Distributed IRB |
|---|---|---|
| Same subnet | Bridged, not routed | Bridged, not routed |
| Inter-subnet | Routed at the firewall | Routed at the leaf |
| Inter-VRF | At the firewall | Needs leaking or service insertion |
| External | Border firewall | Border firewall |
같은 서브넷 내부 트래픽이 사람들이 잊는 행입니다. 한 VLAN의 두 호스트는 브리징으로 통신하며, 별도의 레이어 2 검사 설계가 가로채지 않는 한 그 경로에는 라우팅 방화벽이 없습니다. 이는 두 모델 모두에 해당하므로, 둘 사이의 비교가 아니라 설계의 공백입니다.
나머지 세 행이 바로 모델이 실제로 갈라지는 지점입니다.
중앙 집중 게이트웨이: 단순한 검사, 실제 전송 비용
테넌트 VLAN을 레이어 2 서비스로 유지하고 그 라우팅 게이트웨이를 방화벽에 둡니다. 그러면 서브넷 간 트래픽이 그 게이트웨이로 갔다가 돌아옵니다. 두 호스트가 같은 leaf에 있어도 그럴 수 있습니다. 검사 지점은 명확하며, 그것이 이 설계의 논거 전부입니다. 비용은 방화벽의 전송 부하와, 이제 설계해야 하는 중앙 용량 및 가용성 의존입니다.
변경은 의도한 테넌트 게이트웨이로 한정하십시오. 관리, underlay, 플랫폼 인터페이스가 각각 다른 역할을 할 때 모든 VLAN 주소를 제거하는 것은 너무 광범위합니다. 두 번째 활성 게이트웨이도 확인하십시오. 방화벽을 우회해 계속 라우팅하는 게이트웨이가 있으면 설계가 조용히 무너집니다.
이 모델은 감사자에게 설명하기 쉽습니다. 그렇다고 운영이 자동으로 저렴해지지는 않습니다.
분산 IRB: 고속 경로, 기본적으로 검사 없음
분산 anycast 게이트웨이에서는 각 leaf가 테넌트 트래픽을 로컬에서 라우팅하며, RFC 9135는 이것이 중앙 집중 게이트웨이로의 백홀을 피하는 이유를 설명합니다. 이점은 실제이며 직접적인 결과가 따릅니다. 방화벽이 어디에 연결되어 있는지로 검사 여부를 추론할 수 없습니다. 경계 leaf에 연결된 방화벽은 외부 트래픽과 명시적으로 그쪽으로 돌린 것만 봅니다.
플랫폼이 실제로 지원하는 방식으로 서비스를 넣으십시오. 정책 기반 리디렉션, 서비스 노드, 또는 방화벽을 통한 제어된 VRF 간 라우팅입니다. 의도한 트래픽을 실제 진입 지점에서 일치시키십시오. 호스트 쪽 인터페이스에 작성한 정책은 overlay에서 도착하는 패킷을 다루지 못합니다.
의도한 기본 경로가 아니라 실제 설치된 경로를 읽으십시오. 직접 가져온 더 구체적인 테넌트 프리픽스는 방화벽을 가리키는 기본 경로를 우회할 수 있으며, 구성에서는 아무것도 잘못되어 보이지 않습니다.
대칭성은 라우팅 속성이지 검사 보장이 아닙니다
대칭 IRB는 인그레스와 이그레스 provider edge 노드가 흐름에 대해 라우팅과 브리징을 어떻게 처리하는지 설명합니다. 두 방향이 같은 스테이트풀 장비에 도달하는지는 말하지 않습니다. ECMP, anycast, 방화벽 고가용성은 모두 어느 노드가 반환 트래픽을 보는지에 영향을 주며, 클러스터가 지원하는 상태 모델이 그것이 허용 가능한지 결정합니다.
중요한 모든 흐름에 대해 반환 경로를 명시적으로 따라가십시오. NAT는 그 작업의 보편적 대체물이 아니며, 그것에 기대는 설계는 보통 구축 단계가 아니라 페일오버 때 공백을 발견합니다.
설계를 승인하기 전에 필수 흐름 하나와 의도적으로 제외한 흐름 하나를 양방향으로 짚어 보십시오.
어떻게 고르고, 어느 경우든 무엇을 시험할지
검사 범위가 전송 용량보다 중요하고 중앙 의존을 감당할 수 있다면 중앙 집중 게이트웨이를 고르십시오. 로컬 라우팅이 핵심이라면 분산 IRB를 고르고, 당연하게 여기지 말고 명시적 서비스 삽입을 위한 예산을 잡으십시오.
그다음 실제로 설치한 라우팅을 시험하십시오. 두 설계가 가장 크게 갈리는 지점이 바로 거기입니다.
show ip route vrf TENANT 10.20.0.0/16
show bgp l2vpn evpn route-type prefix서비스 노드의 장애와 복구를 시험에 포함하십시오. 검사를 조용히 우회하는 폴백 경로는 계획된 fail-open 정책과 다른 결정이며, 보통 둘 중 하나만 의도됩니다. 완성된 설계는 각 트래픽 클래스가 어디로 라우팅되고, 어디서 검사되며, 그 검사 경로를 쓸 수 없을 때 무슨 일이 일어나는지를 밝힙니다.