Monitoring and Troubleshooting

목적

라우터 또는 스위치의 모든 인터페이스를 통과하는 트래픽에 대한 실시간 통계를 표시합니다.

작업

라우터 또는 스위치의 모든 인터페이스를 통과하는 트래픽에 대한 실시간 통계 표시:

의미

샘플 출력은 활성 인터페이스에 대한 트래픽 데이터와 명령이 시작된 이후 또는 키를 사용하여 C 카운터가 지워진 이후 각 필드가 변경된 양을 표시합니다. 이 예제에서는 monitor interface 명령이 실행된 이후 또는 카운터가 마지막으로 0으로 반환된 이후 명령이 15초 동안 실행되었습니다.

목적

라우터 또는 스위치의 인터페이스를 통과하는 트래픽에 대한 실시간 통계를 표시합니다.

작업

라우터 또는 스위치의 인터페이스를 통과하는 트래픽을 표시하려면 다음 Junos OS CLI 운영 모드 명령을 사용합니다.

의미

샘플 출력은 특정 SONET 인터페이스()에 대한 입력 및 출력 패킷을 보여줍니다.so-0/0/1 이 정보에는 SONET/SDH 및 T3 알람, 감지된 루프백, 프레이밍 오류 증가와 같은 일반적인 인터페이스 장애가 포함될 수 있습니다. 자세한 내용은 추적 오류 조건 검사 목록을 참조하십시오.

실행 중에 명령의 출력을 제어하려면 에 표 1표시된 키를 사용합니다.

명령과 함께 일치 조건을 사용하는 방법에 대한 자세한 내용은 CLI 탐색기 를 monitor traffic 참조하십시오.

문제

솔루션

스케줄러 맵을 멀티링크 번들 및 해당 구성 링크에 적용할 수 있습니다. 스케줄러 맵을 사용하여 여러 CoS 구성 요소를 적용할 수 있지만 필요한 것만 구성합니다. 불필요한 전송 지연을 방지하기 위해 구성 링크의 구성을 단순하게 유지하는 것이 좋습니다.

표 5 에는 멀티링크 번들 및 해당 구성 링크에 적용될 CoS 구성 요소가 나와 있습니다.

문제

솔루션

지터와 지연 시간을 줄이려면 다음을 수행합니다.

1. 각 구성 링크에서 셰이핑 속도를 구성했는지 확인합니다.

2. 링크 서비스 인터페이스에서 셰이핑 속도를 구성하지 않았는지 확인합니다.

3. 구성된 셰이핑 속도 값이 물리적 인터페이스 대역폭과 동일한지 확인합니다.

4. 셰이핑 속도가 올바르게 구성되었는데도 지터가 지속되면 주니퍼 네트웍스 기술 지원 센터(JTAC)에 문의하십시오.

문제

솔루션

LFI가 활성화되면 데이터(비 LFI) 패킷이 MLPPP 헤더로 캡슐화되고 지정된 크기의 패킷으로 단편화됩니다. LFI(Delay-Sensitive, Voice) 패킷은 PPP로 캡슐화되어 데이터 패킷 조각 사이에 인터리브됩니다. 대기열 및 로드 밸런싱은 LFI 패킷과 비 LFI 패킷에 대해 다르게 수행됩니다.

LFI가 올바르게 수행되는지 확인하려면 패킷이 구성된 대로 단편화되고 캡슐화되는지 확인합니다. 패킷이 LFI 패킷으로 처리되는지 또는 비 LFI 패킷으로 처리되는지 확인한 후 로드 밸런싱이 올바르게 수행되는지 확인할 수 있습니다.

Solution Scenario—두 개의 주니퍼 네트웍스 디바이스 R0 및 R1이 두 개의 시리얼 링크 se-1/0/0 및 se-1/0/1를 통합하는 멀티링크 번들 lsq-0/0/0.0 로 연결되어 있다고 가정해 보겠습니다. R0 및 R1에서 MLPPP 및 LFI는 링크 서비스 인터페이스에서 활성화되고 단편화 임계값은 128바이트로 설정됩니다.

이 예에서는 패킷 생성기를 사용하여 음성 및 데이터 스트림을 생성했습니다. 패킷 캡처 기능을 사용하여 수신 인터페이스에서 패킷을 캡처하고 분석할 수 있습니다.

다음 두 데이터 스트림이 멀티링크 번들로 전송되었습니다.

• 200바이트의 데이터 패킷 100개(단편화 임계값보다 큼)

• 60바이트의 데이터 패킷 500개(단편화 임계값보다 작음)

다음 두 개의 음성 스트림이 멀티링크 번들로 전송되었습니다.

• 소스 포트 100에서 200바이트의 음성 패킷 100개

• 소스 포트 200에서 200바이트의 음성 패킷 300개

LFI 및 로드 밸런싱이 올바르게 수행되는지 확인하려면,

1. 패킷 단편화를 확인합니다. 운영 모드에서 명령을 입력하여 show interfaces lsq-0/0/0 큰 패킷이 올바르게 조각화되었는지 확인합니다.

   Meaning- 출력은 멀티링크 번들에서 디바이스를 전송하는 패킷의 요약을 보여줍니다. 멀티링크 번들에 대한 다음 정보를 확인합니다.

   • 총 전송 패킷 수 = 1000

   • 총 통과 조각 수=1100

   • 단편화된 데이터 패킷 수 = 100

   멀티링크 번들에서 전송된 총 패킷 수(600 + 400)는 전송 패킷 수(1000)와 일치하여 손실된 패킷이 없음을 나타냅니다.

   전송 프래그먼트 수는 전송 패킷 수를 100배 초과하여 100개의 대용량 데이터 패킷이 올바르게 프래그먼트화되었음을 나타냅니다.

   Corrective Action- 패킷이 올바르게 단편화되지 않은 경우, 단편화 임계값 구성을 확인합니다. 지정된 단편화 임계값보다 작은 패킷은 단편화되지 않습니다.

2. 패킷 캡슐화를 확인합니다. 패킷이 LFI 또는 비 LFI 패킷으로 취급되는지 확인하려면 캡슐화 유형을 결정합니다. LFI 패킷은 PPP로 캡슐화되며, 비 LFI 패킷은 PPP와 MLPPP로 캡슐화됩니다. PPP 및 MLPPP 캡슐화는 서로 다른 오버헤드를 가지므로 패킷 크기가 다릅니다. 패킷 크기를 비교하여 캡슐화 유형을 결정할 수 있습니다.

   단편화되지 않은 작은 데이터 패킷에는 PPP 헤더와 단일 MLPPP 헤더가 포함됩니다. 큰 단편화된 데이터 패킷에서 첫 번째 단편에는 PPP 헤더와 MLPPP 헤더가 포함되지만 연속된 단편에는 MLPPP 헤더만 포함됩니다.

   PPP 및 MLPPP 캡슐화는 패킷에 다음과 같은 바이트 수를 추가합니다.

   • PPP 캡슐화는 7바이트를 추가합니다.

     4바이트의 헤더+2바이트의 FCS(Frame Check Sequence)+유휴 상태이거나 플래그를 포함하는 1바이트

   • MLPPP 캡슐화는 6바이트에서 8바이트 사이를 추가합니다.

     4바이트의 PPP 헤더+2 - 4바이트의 멀티링크 헤더

   그림 1 은(는) PPP 및 MLPPP 헤더에 추가된 오버헤드를 보여줍니다.

   그림 1: PPP 및 MLPPP 헤더

   CRTP 패킷의 경우, 캡슐화 오버헤드와 패킷 크기는 LFI 패킷보다 훨씬 작습니다. 자세한 내용은 예: 압축된 실시간 전송 프로토콜 구성.

   표 6 은(는) 데이터 패킷과 음성 패킷에 대한 캡슐화 오버헤드를 각각 70바이트로 보여줍니다. 캡슐화 후 데이터 패킷의 크기는 음성 패킷의 크기보다 큽니다.

   표 6: PPP 및 MLPPP 캡슐화 오버헤드

   패킷 유형	캡슐화	초기 패킷 크기	캡슐화 오버헤드	캡슐화 후의 패킷 크기
   음성 패킷(LFI)	PPP	70바이트	4 + 2 + 1 = 7바이트	77 바이트
   짧은 시퀀스의 데이터 조각(비 LFI)	메이저리그PPP	70바이트	4 + 2 + 1 + 4 + 2 = 13바이트	83바이트
   긴 시퀀스의 데이터 조각(비 LFI)	메이저리그PPP	70바이트	4 + 2 + 1 + 4 + 4 = 15바이트	85바이트

   운영 모드에서 명령을 입력하여 show interfaces queue 각 대기열에서 전송된 패킷의 크기를 표시합니다. 전송된 바이트 수를 패킷 수로 나누어 패킷 크기를 구하고 캡슐화 유형을 결정합니다.

3. 로드 밸런싱을 확인합니다. 운영 모드에서 멀티링크 번들 및 해당 구성 링크에 명령을 입력하여 show interfaces queue 패킷에 대해 로드 밸런싱이 적절하게 수행되는지 확인합니다.

   Meaning- 이러한 명령의 출력은 링크 서비스 인터페이스 및 해당 구성 링크의 각 대기열에서 전송 및 대기열에 있는 패킷을 보여줍니다. 표 7 에는 이러한 값의 요약이 나와 있습니다. (전송된 패킷 수가 모든 링크의 대기열 패킷 수와 같기 때문에 이 테이블에는 대기열에 있는 패킷만 표시됩니다.)

   표 7: 대기열에서 전송된 패킷 수

   대기열에 있는 패킷	번들 lsq-0/0/0.0	구성 링크 se-1/0/0	구성 링크 se-1/0/1	설명
   Q0의 패킷	600	350	350	구성 링크를 통과하는 총 패킷 수(350+350 = 700)가 멀티링크 번들에서 대기 중인 패킷 수(600)를 초과했습니다.
   Q2의 패킷	400	100	300개	구성 링크를 통과하는 총 패킷 수는 번들의 패킷 수와 같습니다.
   Q3의 패킷	0	19	18	구성 링크의 Q3을 통과하는 패킷은 구성 링크 간에 교환되는 keepalive 메시지를 위한 것입니다. 따라서 번들의 Q3에는 패킷이 계산되지 않았습니다.

   멀티링크 번들에서 다음을 확인합니다.

   • 대기열에 있는 패킷 수는 전송된 패킷 수와 일치합니다. 숫자가 일치하면 패킷이 삭제되지 않은 것입니다. 전송된 패킷보다 대기열에 더 많은 패킷이 있는 경우 버퍼가 너무 작기 때문에 패킷이 손실되었습니다. 구성 링크의 버퍼 크기는 출력 단계에서 혼잡을 제어합니다. 이 문제를 해결하려면 구성 링크의 버퍼 크기를 늘려야 합니다.

   • Q0(600)을 전송하는 패킷 수는 멀티링크 번들에서 수신된 크고 작은 데이터 패킷 수(100+500)와 일치합니다. 숫자가 일치하면 모든 데이터 패킷이 Q0을 올바르게 전송한 것입니다.

   • 멀티링크 번들(400)에서 Q2를 전송하는 패킷 수는 멀티링크 번들에서 수신된 음성 패킷의 수와 일치합니다. 숫자가 일치하면 모든 음성 LFI 패킷이 Q2를 올바르게 전송합니다.

   구성 링크에서 다음을 확인합니다.

   • Q0을 전송하는 총 패킷 수(350+350)는 데이터 패킷 및 데이터 조각 수(500+200)와 일치합니다. 숫자가 일치하면 단편화 후의 모든 데이터 패킷이 구성 링크의 Q0을 올바르게 전송합니다.

     패킷이 두 구성 링크를 모두 전송하여 비 LFI 패킷에서 로드 밸런싱이 올바르게 수행되었음을 나타냅니다.

   • 구성 링크에서 Q2(300+100)를 전송하는 총 패킷 수는 멀티링크 번들에서 수신된 음성 패킷 수(400)와 일치합니다. 숫자가 일치하면 모든 음성 LFI 패킷이 Q2를 올바르게 전송합니다.

     전송된 se-1/0/0소스 포트 100 의 LFI 패킷 및 전송된 소스 포트 200se-1/0/1의 LFI 패킷 . 따라서 모든 LFI(Q2) 패킷은 소스 포트를 기반으로 해시되었으며 두 구성 링크를 모두 올바르게 전송했습니다.

   Corrective Action- 패킷이 하나의 링크만 전송한 경우 다음 단계를 수행하여 문제를 해결합니다.

   1. 물리적 링크가 (작동) 또는 down (사용할 수 없음)인지 up 확인합니다. 사용할 수 없는 링크는 PIM, 인터페이스 포트 또는 물리적 연결에 문제가 있음을 나타냅니다(링크 레이어 오류). 링크가 작동하면 다음 단계로 이동합니다.

   2. 비 LFI 패킷에 대해 분류자가 올바르게 정의되어 있는지 확인합니다. 비 LFI 패킷이 Q2까지 대기열에 추가되도록 구성되지 않았는지 확인합니다. Q2까지 대기열에 있는 모든 패킷은 LFI 패킷으로 처리됩니다.

   3. LFI 패킷에서 다음 값 중 하나 이상이 다른지 확인합니다. 원본 주소, 대상 주소, IP 프로토콜, 원본 포트 또는 대상 포트. 모든 LFI 패킷에 대해 동일한 값이 구성된 경우, 패킷은 모두 동일한 플로우로 해시되고 동일한 링크를 전송합니다.

4. 결과를 사용하여 부하 분산을 확인합니다.

문제

솔루션

타사 디바이스가 주니퍼 네트웍스 디바이스와 동일한 FRF.12를 지원하지 않거나 다른 방식으로 FRF.12를 지원하는 경우, PVC의 주니퍼 네트웍스 디바이스 인터페이스는 FRF.12 헤더가 포함된 단편화된 패킷을 폐기하고 이를 "폴리싱된 폐기"로 간주할 수 있습니다.

해결 방법으로, 두 피어 모두에서 멀티링크 번들을 구성하고 멀티링크 번들에서 단편화 임계값을 구성합니다.

문제

• 설명
• 환경
• 증상

솔루션

show security policies checksum 명령을 사용하여 보안 정책 체크섬 값을 표시하고, 보안 정책이 동기화되지 않은 경우 명령을 사용하여 request security policies resync 라우팅 엔진 및 패킷 전달 엔진의 보안 정책 구성을 동기화합니다.

문제

솔루션

이러한 오류를 해결하려면 다음을 수행합니다.

1. 구성 데이터를 검토합니다.

2. /var/log/nsd_chk_only 파일을 엽니다. 이 파일은 커밋 검사를 수행할 때마다 덮어쓰며 자세한 실패 정보를 포함합니다.

문제

솔루션

1. 운영 show 명령 - 보안 정책에 대한 운영 명령을 실행하고 출력에 표시된 정보가 예상한 것과 일치하는지 확인합니다. 그렇지 않은 경우 구성을 적절하게 변경해야 합니다.

2. Traceoptions - 정책 구성에서 명령을 설정합니다 traceoptions . 이 계층 아래의 플래그는 명령 출력의 사용자 분석에 따라 선택할 수 있습니다 show . 사용할 플래그를 결정할 수 없는 경우 flag 옵션을 all 사용하여 모든 추적 로그를 캡처할 수 있습니다.

로그를 캡처하기 위해 선택적 파일 이름을 구성할 수도 있습니다.

추적 옵션에서 파일 이름을 지정한 경우 /var/log/<filename>에서 로그 파일을 확인하여 파일에 오류가 보고되었는지 확인할 수 있습니다. (파일 이름을 지정하지 않은 경우 기본 파일 이름이 이벤트됩니다.) 오류 메시지는 실패 위치와 적절한 이유를 나타냅니다.

추적 옵션을 구성한 후에는 잘못된 시스템 동작을 일으킨 구성 변경을 다시 커밋해야 합니다.

문제

솔루션

문제

솔루션

오류 메시지를 사용하여 섀시와 관련된 문제를 이해합니다.

ISSU가 시작되면 섀시 관점에서 ISSU와 관련된 문제가 있는지 확인하기 위해 섀시에 요청이 전송됩니다. 문제가 있는 경우 로그 메시지가 생성됩니다.

문제

솔루션

ISSU 도중 오류가 발생하면 로그 메시지가 생성되며 ISSU는 트래픽에 영향을 주지 않고 계속 작동합니다. 이전 버전으로 되돌려야 하는 경우, 섀시 클러스터의 두 노드에서 일치하지 않는 버전이 생성되지 않도록 이벤트가 기록되거나 ISSU가 중단됩니다. 표 8 에서는 몇 가지 일반적인 오류 조건과 이에 대한 해결 방법을 제공합니다. 에 표 8 사용된 샘플 메시지는 SRX1500 디바이스에서 전송된 것으로, 지원되는 모든 SRX 시리즈 방화벽에도 적용됩니다.

error: [Oct  6 12:30:16]: Reboot secondary node failed (error-code: 4.1)

       error: [Oct  6 12:30:16]: ISSU Aborted! Backup node maybe in inconsistent state, Please restore backup node
       [Oct  6 12:30:16]: ISSU aborted. But, both nodes are in ISSU window.
       Please do the following:
       1. Rollback the node with the newer image using rollback command
          Note: use the 'node' option in the rollback command
          otherwise, images on both nodes will be rolled back
       2. Make sure that both nodes (will) have the same image
       3. Ensure the node with older image is primary for all RGs
       4. Abort ISSU on both nodes
       5. Reboot the rolled back node

[Oct  3 14:00:46]: timeout waiting for secondary node node1 to sync(error-code: 6.1)
        Chassis control process started, pid 36707 

       error: [Oct  3 14:00:46]: ISSU Aborted! Backup node has been upgraded, Please restore backup node 
       [Oct  3 14:00:46]: ISSU aborted. But, both nodes are in ISSU window. 
       Please do the following: 
      1. Rollback the node with the newer image using rollback command 
          Note: use the 'node' option in the rollback command 
          otherwise, images on both nodes will be rolled back 
      2. Make sure that both nodes (will) have the same image 
      3. Ensure the node with older image is primary for all RGs 
      4. Abort ISSU on both nodes 
      5. Reboot the rolled back node  

[Aug 27 15:28:17]: Secondary node0 ready for failover.
[Aug 27 15:28:17]: Failing over all redundancy-groups to node0
ISSU: Preparing for Switchover
error: remote rg1 priority zero, abort failover.
[Aug 27 15:28:17]: failover all RGs to node node0 failed (error-code: 7.1)
error: [Aug 27 15:28:17]: ISSU Aborted!
[Aug 27 15:28:17]: ISSU aborted. But, both nodes are in ISSU window.
Please do the following:
1. Rollback the node with the newer image using rollback command
    Note: use the 'node' option in the rollback command
           otherwise, images on both nodes will be rolled back
2. Make sure that both nodes (will) have the same image
3. Ensure the node with older image is primary for all RGs
4. Abort ISSU on both nodes
5. Reboot the rolled back node
{primary:node1}

Reboot failure on     Before the reboot of primary node, devices will be out of ISSU setup and no primary node error messages will be displayed.
Primary node

문제

솔루션

다음 오류 메시지를 사용하여 호환성 관련 문제를 이해할 수 있습니다.

문제

솔루션

이미지가 없거나 이미지 파일이 손상된 경우 유효성 검사가 실패합니다. 이미지가 존재하지 않고 ISSU가 중단될 때 초기 검증 검사가 실패할 때 다음 오류 메시지가 표시됩니다.

이미지가 없을 때

이미지 파일이 손상된 경우

이미지 파일이 손상된 경우 다음과 같은 출력이 표시됩니다.

기본 노드는 디바이스 구성을 검증하여 새 소프트웨어 버전을 사용하여 커밋할 수 있는지 확인합니다. 문제가 발생하면 ISSU가 중단되고 오류 메시지가 표시됩니다.

문제

솔루션

다음 오류 메시지를 사용하여 설치 관련 문제를 이해하십시오.

ISSU는 ISSU 명령에 지정된 대로 설치 이미지를 인수로 다운로드합니다. 이미지 파일은 로컬 파일이거나 원격 사이트에 있을 수 있습니다. 파일이 없거나 원격 사이트에 액세스할 수 없는 경우 오류가 보고됩니다.

문제

솔루션

다음 오류 메시지를 사용하여 문제를 파악합니다.

문제

솔루션

다음 오류 메시지를 사용하여 ksyncd와 관련된 문제를 이해하십시오.

ISSU는 보조 노드(노드 1)에 ksyncd 오류가 있는지 확인하고 문제가 있는 경우 오류 메시지를 표시하며 업그레이드를 중단합니다.