사이트 내에서는 같은 iESI, 사이트 간에는 고유하게: Junos 스티칭

두 쌍의 게이트웨이가 두 데이터 센터를 담당하며, 설계에 interconnect ESI 값이 몇 개 필요한지 누군가 결정해야 합니다. 답은 게이트웨이 그룹당 하나이며, fabric당 하나도 게이트웨이당 하나도 아닙니다. 이를 잘못하면 구성된 것처럼 보이면서 잘못된 forwarder를 선택하는 fabric이 생기거나, 분리된 채로 두어야 할 두 사이트가 병합됩니다. 이 규칙과 예외는 게이트웨이 목록 옆에 적어 둘 가치가 있습니다.

두 범위, 두 규칙

사이트 내에서 이중화된 interconnect 게이트웨이는 하나의 multihomed 엔드포인트로 동작하므로 하나의 interconnect ESI를 공유합니다. 그들의 peer는 두 개의 독립 멤버가 아니라 하나의 논리 멤버를 보아야 합니다. 공유 값의 요점이 바로 그것입니다.

사이트 간에는 각 게이트웨이 그룹이 자체 값을 가집니다. 동일한 식별자를 공유하는 두 데이터 센터는 제어 평면에서 하나의 multihomed 그룹이 되며, 이는 WAN을 넘는 스티칭 설계가 보통 의도하는 바가 아닙니다. 한 그룹에 속한 두 사이트는 서로의 장애 모드도 상속합니다.

사이트 내: 그룹을 위한 하나의 ID

두 peer에 같은 값을 같은 서비스 컨텍스트에서 부여하고, 채팅 스레드가 아니라 네트워크의 식별자 인벤토리에 기록하십시오. 두 멤버 사이의 불일치는 멤버 하나짜리 그룹과 뚜렷한 경보가 없는 상태를 만드는 장애 모드입니다. 동작하는 세션을 믿기 전에 두 멤버를 비교하십시오.

지원되는 모델은 all-active입니다. 같은 참조 문서는 이 스티칭 ID에 대해 single-active 운영, 자동 파생 LACP 식별자, source-bmac 옵션을 배제하므로, 그중 하나를 전제한 설계는 식별자를 선택하기 전에 재검토해야 합니다. 이 제약은 설계 입력이며 각주가 아닙니다.

사이트 간: 서로 다른 값, 또는 의도적인 병합

사이트마다 고유한 값을 쓰면 두 게이트웨이 그룹이 분리된 채로 유지됩니다. 의도가 정말로 하나의 multihomed 그룹을 사이트 간에 확장하는 것이라면, 그것은 지연, 장애, 포워딩에 대한 자체적 결과를 지닌 다른 아키텍처이며, 식별자 선택이 아니라 아키텍처로 결정해야 합니다. 유지보수 창 전에 그 결정을 문서로 요청하십시오.

의도한 구분을 계획에 적어 두어, 나중에 동작하는 사이트 템플릿을 복사하는 엔지니어가 그 식별자까지 함께 가져오지 않게 하십시오.

peer 문은 ID의 일부입니다

그룹의 각 게이트웨이는 loopback 주소로 로컬 peer를 나열하며, 그 관계는 개별 MAC-VRF 내부가 아니라 전역 EVPN 수준에 존재합니다. 이를 잘못된 계층에 두는 것은 commit은 되지만 결코 그룹을 형성하지 않는 구성을 만드는 흔한 방법입니다. 참조 계층을 한 번 읽고, 그에 따르십시오.

문의 이름도 바뀌었습니다. Juniper는 24.2R1에서 interconnect peer-gateways 문의 이름을 바꾸고, 24.4R1에서 데이터 센터 interconnect를 위한 interconnect 전용 형식을 복원했습니다. 따라서 중간 릴리스에서 가져온 스니펫은 배포된 버전이 받아들이지 않는 이름을 사용할 수 있고, 그 반대도 마찬가지입니다. 스니펫이 어느 릴리스에서 왔는지 스니펫 옆에 기록하십시오.

iESI 공유가 하지 않는 일

route target, VNI 또는 로컬 EVPN 인스턴스를 대신 정의하지 않습니다. 그것들은 양쪽에서 일치해야 하는 별도의 구성으로 남으며, 식별자는 일치하지만 route target이 일치하지 않으면 형성은 되고 아무것도 전달하지 않는 그룹이 됩니다. 그 설정의 양쪽을 같은 단계에서 비교하십시오.

peer 도달 가능성이나 designated forwarder 선출을 증명하지도 않습니다. 정상 상황에서 unicast와 필요한 broadcast 및 multicast 동작을 시험하고, 그다음 게이트웨이 하나를 제거해 남은 멤버가 그룹을 혼자 담당하는지 반복하십시오.

바로 그 두 번째 실행이 그룹이 실제임을 증명합니다.

관찰된 멤버십과 서비스 컨텍스트를 시험 결과와 함께 보관하십시오. 그러면 나중의 식별자 변경을 문자열의 미관적 수정이 아니라 실제로 그것인 multihoming 변경으로 검토할 수 있습니다. 결과만이 식별자가 도면이 말하는 대로 동작한다는 유일한 증거입니다.