Junos 내보내기 정책: 이름은 일치 조건이 아니다

누군가 정책에 EXPORT-STATIC이라는 이름을 붙이고 연결했지만, VPN 라우팅 인스턴스의 프리픽스가 왜 원격 끝에 도달하지 않는지 궁금해하고 있다. 이름은 선택에 아무런 영향을 주지 않는다. 정책은 정의와 연결이며, 무엇을 내보내는지는 일치 조건, 정렬된 항, 그리고 그것을 사용하는 컨텍스트가 결정한다. 이 셋을 그 순서대로 읽으면, 수수께끼는 대개 한 번도 일치하지 않은 하나의 항으로 줄어든다.

이름은 라벨이지 조건이 아니다

Junos는 정책 이름을 해석하지 않는다. 정적 내보내기라고 부르는 것이 합당한 정책이 static 프로토콜과 일치할 수도 있고, 주소 프리픽스와 일치할 수도 있으며, 아무것도 일치하지 않고 지나가는 모든 것을 받아들일 수도 있다. 라벨은 그것을 만든 사람이 쓴 문서이며, 그 사람이 의도에 대해 가진 기억만큼만 신뢰할 수 있다.

예상 밖의 내보내기 결과는 정의를 읽으라는 요청으로 다루고, 연결이 고장 났다는 증거로 다루지 않는다. 정의를 읽고 그것이 라벨과 모순되게 하라.

항보다 먼저 연결을 찾아라

올바른 정의라도 잘못된 위치에 연결되면 다른 교환을 바꾼다. 어떤 라우팅 인스턴스, 프로토콜, 그리고 이웃이나 그룹이 실제로 정책을 참조하는지 확인해야 하는데, 하나의 BGP 그룹 아래 연결된 정책은 다른 그룹에 영향을 주지 않으며 인스턴스에 연결된 정책이 그 안의 모든 프로토콜에 반드시 적용되는 것도 아니다. Junos는 이 계층을 구분하며, 의도가 인스턴스 수준에서 표현되었을 때 그룹 수준에서 내보내기가 빠지는 일은 흔하다.

항을 하나도 읽기 전에 연결 경로를 적어 두라. 이런 조사의 절반은 정의는 그대로이고 내보내기 문장만 옮겨진 상태로 거기서 끝난다. 변경 로그에 차이를 기록해 아무도 그것을 실수로 되돌리지 않게 하라.

항은 순서대로 평가되며 첫 번째 결정이 이긴다

항은 처음부터 끝까지 실행되며, 받아들이거나 거부하는 항은 종료 결정이다. 의도한 예외처럼 보이는 뒤의 항은 앞의 항이 이미 경로의 운명을 결정했다면 결코 실행되지 않으므로, 정책이 위에서 아래로 올바르게 읽히면서도 의도와 반대로 동작할 수 있다. 순서는 당신이 신경 쓰는 경로에 대해 확인해야 하며, 항이 입력된 순서에 대해서가 아니다.

동작을 생략한 항은 종료하지 않고, 평가는 다음 항으로 계속되며, 최종 결과는 뒤에 오는 것과 적용되는 기본값에 달려 있다. 이것은 정말 유용한 구조이며, 의도하지 않았을 때는 확실한 놀라움의 원천이다.

정적 경로만 내보내는 예시이며, 연결은 그룹에 있다:

policy-options {
    policy-statement EXPORT-STATIC {
        term statics { from protocol static; then accept; }
    }
}
protocols bgp group TO-PEER { export EXPORT-STATIC; }

OSPF로 학습되었고 정적 경로로 구성되지 않은 프리픽스는 정책의 이름이 무엇이든 일치에 실패해 떨어진다.

동작은 복사본을 바꾸며 원래 경로를 바꾸지 않는다

정책 동작은 해당 광고를 위해 평가되는 경로, 즉 라우팅 테이블의 항목이 아니라 복사본에 작용한다. 따라서 로컬 show route 명령은 한 속성 집합을 가진 경로를 보여 주는 반면 내보낸 버전은 다른 속성을 지닐 수 있고, 원본은 내보내기에 의해 다시 쓰이지 않는다. 이 차이는 어느 쪽 출력이 옳은가에 대한 여러 논쟁을 설명한다: 둘 다 옳으며, 서로 다른 객체를 기술한다. 두 엔지니어가 경로 속성에 대해 의견이 다를 때마다 어느 뷰를 인용하는지 말하라.

받아들이기와 거부하기는 종료 결정이며, 속성 변경은 반드시 그렇지 않다. 평가가 고려하지 않은 항으로 계속될 수 있으므로 community 설정이 정책을 끝낸다고 가정하지 마라.

광고된 뷰를 기대와 비교하라

실제 피어에서, 예를 들어 show route advertising-protocol bgp 192.0.2.1 같은 프로토콜별 뷰를 사용해 올바른 라우팅 인스턴스 컨텍스트에서 읽어라. VRF에 있는 경로가 반드시 내보내기 정책을 통과한 것은 아니고, 광고된 출력에 나타난 경로가 반드시 원격 측에서 수락된 것도 아니다. 이들은 세 가지 별개의 상태이며 서로 다르게 실패한다.

하나는 반드시 광고되어야 하고 다른 하나는 로컬로 남아야 하는 두 프리픽스로 설계를 받아들여라. 그러면 정책에 시험할 수 있는 계약이 생기고, 이름 붙은 경로 하나가 마침내 나타날 때까지 내보내기를 넓히는 대안적 수정을 피할 수 있다.