MX가 IPsec을 종료하기 전에 갖춰야 할 조건
설정을 커밋해도 증명되는 것은 파서뿐이며 경로가 아닙니다. 서비스가 실제로 동작하는지는 플랫폼 튜플의 다섯 가지 요소가 결정합니다.
설정은 깔끔하게 커밋되고 인터페이스도 올라오는데 터널은 여전히 수립을 거부합니다. 로그 어디에도 이 플랫폼이 할 수 없다고 적혀 있지 않습니다. 그저 하지 않을 뿐입니다. Junos에서 IPsec은 섀시, 서비스 하드웨어 또는 소프트웨어 경로, 릴리스의 특정 조합이 있어야 수행할 수 있는 서비스이며, 기능 페이지는 여러분의 장비가 아니라 소프트웨어의 능력을 설명합니다. 튜플은 요소별로 확인해야 합니다. 커밋 결과가 증명하는 것은 파서뿐이기 때문입니다.
패킷이 실제로 지나는 곳
IPsec용으로 선택된 트래픽은 그것을 암호화하는 구성 요소에 도달해야 합니다. 서비스 모듈이 있는 플랫폼에서는 선택된 플로가 그 모듈로 유도되고, 이후 다시 포워딩 경로로 돌아옵니다. 모듈이 없거나 용량이 부족하거나 인터페이스에 바인딩되지 않았다면 설정은 존재하지만 패킷은 하나도 처리되지 않습니다. 커밋 출력 어디에도 그런 상태를 정상 상태와 구분해 주는 정보는 없습니다.
소프트웨어로 구현하는 방식은 작업을 라우팅 엔진 위에 또는 인라인 하드웨어 안에 두며, 리소스 한도가 크게 다릅니다. 설정에 보이는 터널이 실제로 어느 경로로 실려 가는지는 알려 주지 않습니다.
튜플의 다섯 가지 요소
어떤 권고를 읽기 전에 먼저 조합을 적어 두십시오. 한 요소가 나머지를 무효로 만들 수 있기 때문입니다. 삼 년 전에 서비스를 지원했던 부품 번호는 이 섀시에 있는 카드와 릴리스에 대해 아무것도 말해 주지 않습니다. 아래 행들을 점검 목록으로 읽고, 설정이 보여 줄 수 없는 값들을 채우십시오.
| Part | What to record | Where it fails quietly |
|---|---|---|
| Chassis and service hardware | Model plus the installed PIC, MPC or MIC | Card absent or not bound to the interface |
| Implementation | Services card, inline or software path | Configuration accepted, no processing |
| Release | Exact Junos version | The feature arrives in a later build |
| Address families and mode | Outer and inner family, tunnel mode, peer authentication | Half the traffic silently unprotected |
| Entitlement and capacity | Licence state and the workload profile | Ceiling reached only under load |
주소 패밀리와 워크로드는 사람들이 건너뛰기 쉬운 두 행이며, 둘 다 확인은 저렴하고 나중에 발견하면 비쌉니다. 튜플은 스프레드시트가 아니라 장비에서 읽으십시오. 설정은 실제로 설치된 것이 아니라 요청한 것을 보고하기 때문입니다. 대부분은 두 명령으로 충분합니다. show chassis hardware 는 실제로 장착된 카드를 알려 주고, show version 는 정확한 릴리스를 알려 줍니다. 둘 다 설정이 올바른지에 의존하지 않으며, 바로 그 점이 핵심입니다.
show chassis hardware
show version릴리스 게이트는 실제 게이트다
릴리스 세부 사항은 형식적인 문제가 아닙니다. Juniper의 IPsec 개요 문서는 멀티서비스 카드의 AES-GCM 지원을 Junos 17.3R1로, FIPS 모드는 17.4R1부터 시작하는 것으로 명시합니다. 따라서 같은 기능이라도 플랫폼을 운용하는 방식에 따라 두 개의 기준이 있고, 어떤 모드로 운용하는지가 어느 기준이 적용되는지를 결정합니다. 기능 목록을 확인하기 전에 모드를 확인하십시오.
문서화된 최신 버전이 아니라 실제로 설치된 정확한 버전의 릴리스 노트를 읽으십시오. 나중 빌드에서 등장한 기능이 이전 빌드에도 있다고 가정할 수 없고, 한 카드에 대해 쓰인 설명이 다른 카드로 그대로 옮겨지지도 않습니다. 릴리스 노트의 해당 줄을 설계 기록에 복사해 그 주장이 출처를 함께 갖게 하십시오. 플랫폼 패밀리를 위해 쓰인 지원 설명은 여러분이 운용하는 모드나 보유한 카드에 대한 설명이 아니기 때문입니다.
용량은 헤드라인이 아니라 워크로드다
측정 조건이 없는 헤드라인 처리량 수치는 마케팅 숫자입니다. 작은 패킷은 큰 패킷보다 비트당 비용이 훨씬 높고, 동시에 맺어진 보안 연계는 메모리를 소모하며, 카드를 공유하는 다른 모든 서비스가 남은 여유를 줄입니다.
예상되는 트래픽에서 추정하십시오. 일반적인 패킷 크기와 최악의 경우 크기, 피어 수, 그리고 그 카드가 NAT나 다른 서비스도 종료하는지 여부입니다. 그런 다음 어느 날 어떤 경로가 설계에서 가정한 것보다 많은 부하를 실을 경우를 위해 여유를 남기십시오. 하드웨어가 유휴 상태라고 가정하는 용량 계획은 계획이 아니라 바람입니다. 그 수치가 사업성 검토에 중요하다면 대표적인 부하에서 장비로 한 번 측정하고 그 측정값을 설계와 함께 보관하십시오.
설계보다 기록을 먼저 쓴다
설계에 필요한 각 능력마다 플랫폼 참조, 릴리스에 맞는 문서, 해결되지 않은 제약을 한곳에 모아 두십시오. 튜플의 어느 행이 충족되지 않으면 진부해진 구매 목록에 맞춰 설계를 다시 만드는 대신 별도의 승인된 게이트웨이와 비교하십시오. 기록에는 어떤 시스템이 그 작업을 수행하는지, 어떤 한도 아래에서 수행하는지를 적어야 합니다.
피어 확인은 그다음입니다. 원격 단과의 프로토콜 호환성은 다음 질문이며, 로컬 지원을 절대 대신하지 못합니다. 제안에 합의한 피어라도 패킷을 한 번도 암호화하지 않는 섀시를 도울 수는 없습니다.