EVPN 올액티브에서 Linux 액티브-백업 본드: 무엇이 깨지는가

서버에 액티브-백업 본드를 두고, 패브릭에 올액티브 이더넷 세그먼트를 두면, 돌아오는 트래픽의 절반이 오류 카운터 하나 움직이지 않고 사라질 수 있다. 두 구성 중 어느 것도 그 자체로 틀리지 않았다. 문제는 둘 사이의 인계에 있다. 한쪽은 포트 하나를 고르고, 다른 쪽은 연결된 모든 리프가 전달할 수 있다고 가정한다. 각 방향에서 프레임 하나를 따라가면 불일치가 분명해진다.

액티브-백업이 들어오는 프레임에 하는 일

본딩 모드 1은 전송 경로에 정확히 슬레이브 하나를 유지하고, 현재 슬레이브가 실패할 때만 교체한다. 그 부분은 잘 알려져 있다. 여기서 중요한 것은 수신 쪽이다. 커널은 활성 슬레이브로 도착한 프레임만 스택에 넘기고, 다른 슬레이브에 나타난 프레임은 버린다. 이 all_slaves_active 설정은 바로 그 규칙을 완화하기 위해 존재하며, 기본값은 꺼짐이다. ip -d link show bond0 모드 옆에 현재 값을 출력한다.

/proc/net/bonding/bond0 활성 슬레이브를 지목하고 각 슬레이브의 링크 상태를 보고한다. 어떤 포트가 지금 트래픽을 나르는지에 대한 정직한 출처는 그 파일뿐이다.

이 모드의 호스트는 한 번에 쓸 수 있는 수신 경로가 하나뿐이며, 패브릭을 모르는 채로 로컬에서 선택된다. 그 호스트 앞으로 온 프레임이 다른 케이블로 도착하면, 스위치 포트는 그것을 수신으로 세고, 호스트 스택은 결코 그것을 보지 못하며, 호스트 자신의 드롭 카운터를 뺀 모든 카운터는 완벽하게 건강해 보인다.

올액티브 멀티호밍이 원격 다음 홉에 하는 일

EVPN 멀티호밍은 ESI로 식별되는 이더넷 세그먼트 하나를 공유하는 리프 집합을 기술하고, 그 세그먼트를 나머지 패브릭에 광고한다. 올액티브 모델에서 원격 피어는 세그먼트 주소에 대해 다음 홉을 하나보다 많이 설치한다. 서버 쪽으로 가는 유니캐스트는 그러면 어느 리프로도 도착할 수 있고, 패브릭은 플로우마다 자유롭게 고를 수 있다. 이것이 설계의 요점 전체이며, 서버 본드가 충족해야 하는 가정이기도 하다.

플러딩되는 트래픽은 다른 규칙을 따른다. 리프는 세그먼트마다 지정 포워더를 선출하므로, 브로드캐스트와 미지의 유니캐스트, 멀티캐스트는 보통 그중 하나를 통해 들어온다. 따라서 유니캐스트와 플러딩은 서로 다른 두 결정을 내리고, 그중 하나만 호스트의 본드 상태에 나타난다.

두 선출이 어긋나는 지점

커널은 링크 상태와 자신의 정책으로 활성 슬레이브를 고른다. 패브릭은 EVPN 경로로 다음 홉을, 리프 사이의 선출로 지정 포워더를 고른다. 어느 프로세스도 다른 쪽에 묻지 않는다. 서로 다른 리프를 고르면 실패는 방향에 따라 달라진다. 서버가 보내는 것은 정상적으로 나가고, 응답만 사라진다.

지원되는 두 가지 우회로가 있고, 서로 바꿀 수 없다. 패브릭이 논리적 연결 하나로 다룰 수 있는 본드를 호스트에 주라. 실제로는 리프와 협상한 LACP 본드를 뜻하며, 두 링크가 정말 함께 활성화된다. 또는 패브릭에서 단일 액티브 전달도 받아들여, 세그먼트가 본드와 같은 한 번에 포트 하나 모델을 따르게 하라. 통하지 않는 것은 포트 하나에서만 수신하는 본드 앞에 올액티브 세그먼트를 두는 구성이며, 비활성 슬레이브에서 수신을 의도적으로 켜고 그에 따르는 중복 전달을 받아들이지 않는 한 성립하지 않는다.

백업 케이블이 계속 건강해 보이는 이유

트래픽을 나르지 않는 케이블도 링크 업을 보고하고, 본드의 대기 슬레이브는 준비된 것처럼 보이도록 설계되어 있다. 운영자는 그것을 이중화로 읽고 질문을 그친다.

대신 돌아오는 프레임이 어느 물리 포트를 썼는지 물어라. 호스트에서는 본드 단위가 아니라 슬레이브 단위로 수신 패킷을 세라. 본드 카운터가 비대칭을 감추기 때문이다. 리프에서는 다음을 보라. 서버 MAC에 대한 브리지 포워딩 항목 과 EVPN 경로가 나르는 다음 홉 집합이다. 항목이 호스트 링크가 대기 상태인 리프를 가리킨다면, 설계는 호스트가 무시하는 포트로 전달하고 있다. 이것은 하드웨어 고장이 아니라 구성 불일치이며, 링크 상태를 아무리 모니터링해도 드러나지 않는다.

링크 상태가 아니라 양방향 전달을 시험하라

고장마다 행 하나, 방향마다 열 하나인 행렬을 만들고, 인터페이스 상태 대신 전달된 트래픽을 채워라. 첫 행은 정상 운영이며, 불일치가 숨는 곳이 바로 거기다. 증상이 애플리케이션 문제처럼 보이기 때문이다.

그다음 활성 호스트 링크를 빼고, 리프 하나를 빼고, 그 리프의 업링크를 빼고, 각각을 차례로 되돌려라. 각 단계 뒤에 활성 슬레이브와 EVPN 세그먼트 상태, 원격 포워딩 항목, 양방향에서 관측한 처리량을 기록하라. 호스트 링크가 올라간 채로 패브릭 경로를 잃는 리프가 흥미로운 사례다. 연결은 계속 광고된 채로 남아 조용히 막다른 길이 될 수 있다. 새 유니캐스트 플로우와 애플리케이션이 의존하는 플러딩 트래픽으로 시험하라. 둘은 서로 다른 포워딩 결정을 쓰기 때문이다.

행렬이 의도한 경로를 통한 양방향 전달을 보여줄 때만 설계를 받아들여라. 링크 업 상태의 케이블 두 개는 그 결과가 아니다.