Junos L2VPN: 고객 연결 계약을 먼저 제대로 정하세요

pseudowire를 건드리기 전에 고객 프레임 하나를 PE 안까지 따라가 어디에 내려앉아야 하는지 보세요. 물리 포트가 그 프레임을 논리 유닛으로 분류하고, 그 유닛이 캡슐화를 지니며, 유닛은 서비스에 묶여 있습니다. 세 가지 별개의 결정, 잘못될 수 있는 세 가지 별개의 길입니다. 신호 장애로 에스컬레이션되는 사례의 대부분은 사실 그 서비스를 위해 아무도 설정하지 않은 유닛으로 분류된 프레임입니다. 그러니 연결에서 시작해 바깥으로 나아가세요.

프레임 계약을 적어 두세요

어떤 설정을 고르기 전에 계약을 기록하세요. 태그 없음, 서비스 태그 하나, 또는 스택이며, 고객이 보낼 MTU와 각 방향에서 기대하는 태그 처리를 덧붙이세요. 이는 현지 취향이 아니라 협상으로 정해지는 속성이기 때문입니다. 유닛 번호는 식별자일 뿐이며 인터페이스가 어떤 프레임을 받아들일지는 말해 주지 않습니다.

이것은 티켓 댓글이 아니라 서비스 노트에 쓰세요. 반년 뒤에 이걸 디버깅할 사람은 노트를 읽습니다. 티켓은 읽지 않습니다.

캡슐화를 계약에 맞추세요

단일 태그 서비스는 보통 VLAN 회선 캡슐화를 씁니다. 예를 들어 vlan-ccc 이며, 태그 없는 프레임에는 순수한 Ethernet 회선 형식이, 스택에는 두 태그를 이해하는 확장 형식이 필요합니다. 유닛 단위 서비스 캡슐화를 지원하는 플랫폼에서는 물리 인터페이스 하나가 여러 개를 동시에 수용할 수 있습니다. 편리한 동시에 프레임이 잘못된 유닛으로 들어가는 경로이기도 합니다. 플랫폼 안내서가 family ccc 를 요구한다면 라우팅 인터페이스에 덧붙이지 말고 전체 연결의 일부로 설정하세요.캡슐화 안내서 는 어떤 연결 유형이 어떤 요구 사항을 부과하는지 나열합니다.

만일을 대비해 모든 인터페이스에 family 문장을 넣지 마세요. 한 회선을 동작시키는 설정이 다음 회선에 고객이 결코 보내지 않는 프레임을 받아들이게 할 수 있습니다.

연결을 올바른 서비스에 바인딩하세요

BGP로 신호하는 레이어 2 VPN, LDP로 신호하는 회선, 그 밖에 지원되는 서비스는 각자 자신의 인터페이스 바인딩과 신호 설정을 가지며 서로 바꿔 쓸 수 없습니다. 한쪽의 연결 방식을 다른 쪽의 신호와 섞으면 피어를 보고할 뿐 프레임을 나르지 않는 회선이 됩니다.

가까운 쪽만 보지 말고 먼 쪽과 대조해 비교하세요: 피어 주소, 서비스 식별자, 캡슐화 합의, control word 기대치, 크기 예산입니다. 아래 MPLS 계층이 완전히 건강해도 연결이 빠져 있거나 다른 곳으로 분류될 수 있습니다. 그래서 하위 계층만 보는 시험은 여기서 아무것도 증명하지 못합니다.

상태가 아니라 프레임으로 확인하세요

고객이 트래픽을 보내는 동안 로컬 인터페이스 카운터를 읽고, 다음으로 서비스 상태를 읽고, 그다음 도착하는 프레임이 합의한 프레임인지 태그까지 포함해 확인하세요. 고쳐진 연결은 그 프레임을 전달합니다. 상태 변화만으로는 아무것도 증명하지 못합니다.

수집 권한이 있는 곳에서는 프레임을 양방향으로 보세요. 태그 비대칭은 상태 보기에서는 놓치기 쉽고 수집에서는 뚜렷합니다. 그 비대칭은 한 방향으로는 되고 반대 방향으로는 실패한다는 불만도 설명합니다.

그런 다음 적어 두세요

서비스 노트에 네 가지 값을 기록하세요. 계약, 캡슐화, 유닛, 서비스 바인딩입니다. 새 엔지니어에게 필요한 것이 바로 이 넷이며, 설정 검토가 명시하는 일은 드뭅니다.

반년 뒤 회선이 끊기면 그 노트가 십오 분짜리 작업과 동작 중인 설정에서 설계 전체를 다시 끌어내는 일의 차이가 됩니다. 마지막으로 확인한 날짜를 덧붙이면 노트가 얼마나 낡았는지도 알려 줍니다.