Pseudowire 상태와 트래픽 카운터: 어느 쪽이 전달을 증명하는가
운영 상태는 서비스가 구성되어 동작 중임을 말하고, 카운터는 프레임이 이동했음을 말한다. 둘 다 VC 인덱스로 결합하고 방향, 불연속성, MIB 지원을 확인한다.
up을 보고하는 pseudowire는 서비스가 존재하고 두 방향이 모두 트래픽을 실어야 한다는 데 동의한다는 것을 알려준다. 그러나 고객 프레임 하나라도 실제로 통과했는지는 알려주지 않는다. 상태 객체와 카운터 객체는 서로 다른 목적으로 작성되었고, 하나를 다른 하나의 증거로 삼는 것이 이런 대시보드 대부분이 틀리는 지점이다. 둘을 비교하는 것이 일이고, 어느 한쪽만 신뢰하는 것은 아무도 묻지 않은 질문에 답하는 것이다.
상태와 카운터는 서로 다른 질문에 답한다
주 VC 항목은 결합된 운영 상태를 가지며, 그 상태는 두 방향 상태가 모두 up일 때만 up이다. 그 뒤에 있는 모든 것은 제어 평면과 구성 지식이다. 즉 로컬 접속 회선, 피어, 시그널링이다. 이 상태의 행은 의도와 준비에 대한 진술이며, 전달된 프레임에 대한 것이 아니다.
트래픽은 패킷과 바이트에 대한 고용량 카운터의 별도 테이블에 살고, 그 행들은 같은 VC 인덱스를 갖는다. 그곳의 증가는 측정한 구간 동안 프레임이 바로 그 행을 통과했다는 증거다. 변하지 않는 카운터는 그 자체로 모호하다. 유휴 서비스, 잘못된 행을 읽는 수집기, 조용히 끊긴 경로는 모두 같은 평평한 선을 만든다.
| Question | Object | What it can establish |
|---|---|---|
| Is the service up? | cpwVcOperStatus | Both direction states agree the VC should carry traffic. |
| Which side is down? | cpwVcInboundOperStatus, cpwVcOutboundOperStatus | Direction of the reported fault. |
| Did frames move? | cpwVcPerfTotalTable HC counters | Observed forwarding on that row between two polls. |
| Is the interval clean? | cpwVcPerfTotalDiscontinuityTime | Whether the counter was reset inside the window. |
테이블을 심각도의 사다리가 아니라 증거의 두 열로 읽어야 한다. 카운터가 평평한 up은 증가하는 up의 더 나쁜 버전이 아니라 다음 단계가 다른 또 하나의 관측이다.
티켓의 번호가 아니라 VC 인덱스로 결합한다
VC 테이블은 정수 하나로 인덱싱되며, VC ID, 피어 주소, 서비스 유형과 이름은 그 행의 속성이다. 이 속성으로 서비스를 찾고, 인덱스로 첫 폴링 이후에도 계속 찾는다. 인터페이스 인덱스, 표시된 회선 이름, MPLS 레이블은 숫자가 일치하더라도 그 인덱스가 아니다.
숫자 OID는 블로그 글이 아니라 수집기의 MIB 파일에서 도출하고, 그다음 테이블을 한 번 순회하여 찾은 정체성을 저장한다.
snmptranslate -On CPW-VC-MIB::cpwVcIndex
snmptranslate -On CPW-VC-MIB::cpwVcPerfTotalDiscontinuityTime
snmpwalk -v2c -c monitor 10.60.4.21 -On CPW-VC-MIB::cpwVcTable관리 주소와 인덱스를 함께 모니터링 시스템에 기록한다. 재프로비저닝은 서비스를 다른 행으로 옮길 수 있고, 이름으로 VC ID에 결합한 수집기는 여전히 정중하게 응답하는 오래된 인덱스를 계속 그리게 된다.
방향은 가입자가 아니라 pseudowire를 뜻한다
인바운드 카운터는 VC가 패킷 교환망에서 받은 것을 설명하고, 아웃바운드 카운터는 VC가 그 망으로 전달한 것을 설명한다. 고객을 향한 PE에서는 이것이 흔히 어떤 순서로든 다운로드와 업로드에 대응한다. 허브 PE나 코어와 피어링하는 PE에서는 같은 객체 이름이 반대의 고객 경험을 설명한다.
장비 역할마다 매핑을 한 번 적고 대시보드 레이블에 유지한다. 고객 업로드라는 제목이지만 실제로는 코어로 향하는 트래픽을 그리는 그래프는 검토를 통과하고, 용량 결정에 사용하는 모든 사람을 조용히 오도한다. 같은 위험이 그 그래프에 기반한 경보에도 적용되는데, 잘못된 팀을 호출하기 때문이다. 각 그래프를 pseudowire 기준 이동 방향으로 표시하고, 고객 매핑은 그것이 필요한 패널 안에 두어야 한다.
한 번의 시험이 객체 설명을 아무리 많이 읽는 것보다 낫다. 알려진 파일을 서비스로 통과시키고, 바로 뒤에 양방향을 폴링하여 어느 카운터가 움직였는지 본다. 결과는 장비 역할 옆에 기록해야 한다. 다음 사람이 같은 질문을 하기 때문이다.
속도는 하나의 불연속성 구간 안에서만 유효하다
속도는 바이트 카운터의 증가분을 경과 초로 나누고, 초당 비트로 만들기 위해 여덟을 곱해 계산한다. 카운터가 감소했거나, 에이전트가 재시작했거나, 행이 바뀌었거나, 불연속성 객체가 움직였다면 그 구간을 무효로 처리한다. 그 객체는 시스템 가동 시간 기준으로 표현되므로 장비 재시작도 그것을 무효화한다. 스파이크를 그리는 대신 표본을 버리고 새 구간을 연다.
알려진 간격으로 두 표본을 얻고, 타임스탬프는 터미널 이력이 아니라 수집기에서 가져온다.
snmpget -v2c -c monitor -Oqv 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalInHCBytes.7
sleep 60
snmpget -v2c -c monitor -Oqv 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalInHCBytes.7
snmpget -v2c -c monitor -Oqv 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalDiscontinuityTime.7고용량 카운터는 단일 pseudowire에서 랩어라운드를 문제가 아니게 만들므로, 감소는 거의 항상 재설정, 교체된 에이전트, 다른 행을 뜻하며 산술적 오버플로가 아니다. 그래서 세 번째 명령이 처음 두 개만큼 중요한 것이다.
설치된 릴리스가 실제로 무엇을 지원하는지 확인한다
MIB 정의는 명세이며, 당신의 이미지에 대한 약속이 아니다. 테이블이 없거나, 부분적으로 구현되었거나, 기능이 활성화될 때까지 존재하지만 채워지지 않을 수 있고, 같은 플랫폼이라도 릴리스마다 다를 수 있다. CISCO-IETF-PW-MIB 정의 는 객체 이름을 알려주고, 그것들이 응답하는지는 장비가 알려준다.
두 테이블과 펌웨어 문자열을 한 번의 패스로 폴링하고, 릴리스 노트의 주장과 비교한다.
snmpget -v2c -c monitor -Oqv 10.60.4.21 SNMPv2-MIB::sysDescr.0
snmpwalk -v2c -c monitor 10.60.4.21 CPW-VC-MIB::cpwVcTable | wc -l
snmpwalk -v2c -c monitor 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalTable | wc -l빈 워크와 지원되지 않는 워크는 다른 실패이므로 줄 수만이 아니라 오류를 읽어야 한다. 상태 테이블은 응답하고 성능 테이블은 응답하지 않는다면, 첫 절에서 설계한 결합은 착지할 곳이 없고 수정은 회선 변경이 아니라 수집기 변경이다.
분쟁 중인 회선의 순서는 짧다. 인덱스에서 행 정체성을 확인하고, 알려진 전송 하나로 방향 매핑을 확인하고, 깨끗한 불연속성 구간 안에서만 속도를 계산하고, 그 릴리스에서 두 테이블이 모두 응답하는지 확인한다. 각 단계는 후보 설명 하나를 제거한다. 네 가지가 모두 성립하는데 카운터가 여전히 움직이지 않는다면 증거는 pseudowire에서 멀어지는 쪽을 가리킨다. 바로 그 지점에서 접속 회선의 패킷 캡처가 값을 한다.