Junos L2VPN이 레이블을 표시하지만 아무것도 전달하지 않는 이유

L2VPN 연결이 Up이고 어태치먼트가 올라와 있지만 프레임이 하나도 지나가지 않는다는 고객 보고가 들어옵니다. 상태 표시등은 정직하며, 프레임은 원격 끝에서 사용할 수 있는 전달 상태가 없는 서비스로 분류되고 있습니다. BGP로 시그널링되는 포인트 투 포인트 L2VPN에서는 첫 번째 결정이 경로 조회가 아니라 어태치먼트에 달려 있습니다. 고객 프레임은 논리 인터페이스로 도착하고, 그 인터페이스가 연결을, 따라서 원격 사이트를 지정합니다. 그 이후의 모든 것은 피어가 광고한 내용으로 만들어진 레이블 전달 상태입니다.

프레임은 경로 조회를 하지 않습니다

시그널링이 상태를 준비했고, 패킷별 처리는 이미 선택된 연결에 대한 레이블 조회입니다. 따라서 경로가 없는 이유를 묻는 것은 잘못된 질문이며, 중요한 두 값, 즉 어태치먼트의 연결과 그것이 사용하는 서비스 레이블을 가립니다.

이것은 노력의 비대칭도 설명합니다. 구성 검토는 무엇이 설치되었어야 하는지를 알려 주고, 연결 보기는 실제로 무엇이 도출되었는지를 알려 주며, 레이블 블록 불일치에서 살아남는 것은 후자뿐입니다.

두 개의 레이블, 두 개의 방향

각 PE는 로컬에서 레이블 블록을 할당하고 그 기준과 크기를 광고하며, 피어는 오프셋을 더해 특정 사이트의 레이블을 도출합니다. 따라서 할당은 로컬하게 의미가 있으며, 두 PE가 같은 서비스에 서로 다른 기준과 다른 블록 크기를 사용할 수 있습니다. 무엇이든 바꾸기 전에 양쪽 끝에서 연결을 읽어 보세요. 레이블 하나만큼 작게 산정된 블록은 결코 설치되지 않는 연결과 똑같아 보입니다.

show l2vpn connections instance CUST-A extensive

그 출력에서 수신 레이블은 이 PE가 할당하고 피어에게 사용하라고 알린 것이며, 송신 레이블은 이 PE가 푸시하는 피어의 할당입니다. 둘을 거꾸로 읽는 것이 전형적인 실수이며, 이쪽에는 결코 나타나서는 안 될 값을 찾아 나서게 만듭니다. 연결 참조는 사이트, 상태, 블록 정보를 포함해 레이블 옆의 필드를 문서화합니다.

레이블 조회가 증명하는 것

수신 값을 얻었다면 로컬 조회는 명령 하나입니다:

show route label 160042

그 출력에는 다음 홉이 있는 l2vpn 항목이 표시되어야 하며, 레이블 작업은 프레임이 나가기 전에 푸시되는지, 교체되는지, 팝되는지를 알려 줍니다. 아무것도 표시되지 않으면 연결이 Up으로 보이더라도 서비스 상태가 설치된 적이 없다는 뜻이며, 불일치는 전송이 아니라 시그널링에 있습니다.

프레임 하나를 따라가 보세요

어태치먼트에 푸시한 패킷 하나가 어떤 구성 검토보다 더 많은 것을 판가름합니다. 서비스 레이블 경로는 원격 PE를 향한 전송 LSP를 가리켜야 하고, 두 레이블은 피어가 보고한 값과 일치해야 합니다. 전송이 정상인데 서비스 레이블이 잘못되면 프레임은 올바른 라우터에 도달해 그곳에서 폐기되며, 그래서 원격 끝의 카운터는 비어 보이고 근거리 끝의 카운터는 바빠 보입니다.

어태치먼트의 캡슐화, 제어 워드 설정, MTU를 동시에 확인하세요(이들은 홉별 동작이 아니라 협상되는 속성이기 때문입니다).

서비스 모델을 분리해 두세요

VPLS는 MAC 주소를 학습하고 EVPN은 엔드포인트를 광고합니다만, 포인트 투 포인트 L2VPN은 둘 다 하지 않으므로 같은 BGP와 MPLS 인프라를 타더라도 프레임 선택 절차는 서로 바꿀 수 없습니다. 한 모델의 문제 해결 단계를 다른 모델로 옮기면 근거 없는 자신감에 찬 결론이 나옵니다.

경로가 없을 때는 양쪽 피어의 연결 상태, 어태치먼트, 두 레이블 방향, 캡슐화, 제어 워드 설정, MTU를 기록하세요. 그 기록은 광고된 것과 전달 평면이 실제로 하는 일을 연결하며, 그것이 유일하게 중요한 연결 고리이고 다음 엔지니어가 요구할 내용이기도 합니다.