본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.
Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.
이 문서에서는 ACI의 간헐적 삭제 트러블슈팅 단계에 대해 설명합니다.
이 문서의 자료는 Troubleshooting Cisco Application Centric Infrastructure, Second Edition 책, 특히 Intra-Fabric Fowarding - Intermittent drops 장에서 추출되었습니다.
이 예에서는 EP A(10.1.1.1)에서 EP B(10.1.2.1)로 ping할 때 간헐적으로 감소합니다.
[EP-A ~]$ ping 10.1.2.1 -c 10
PING 10.1.2.1 (10.1.2.1) 56(84) bytes of data.
64 bytes from 10.1.2.1: icmp_seq=1 ttl=231 time=142 ms
64 bytes from 10.1.2.1: icmp_seq=2 ttl=231 time=141 ms
<-- missing icmp_seq=3
64 bytes from 10.1.2.1: icmp_seq=4 ttl=231 time=141 ms
64 bytes from 10.1.2.1: icmp_seq=5 ttl=231 time=141 ms
64 bytes from 10.1.2.1: icmp_seq=6 ttl=231 time=141 ms
<-- missing icmp_seq=7
64 bytes from 10.1.2.1: icmp_seq=8 ttl=231 time=176 ms
64 bytes from 10.1.2.1: icmp_seq=9 ttl=231 time=141 ms
64 bytes from 10.1.2.1: icmp_seq=10 ttl=231 time=141 ms
--- 10.1.2.1 ping statistics ---
10 packets transmitted, 8 received, 20% packet loss, time 9012ms
대상 호스트(EP B)에서 패킷 캡처(tcpdump, Wireshark 등)를 수행합니다. ICMP의 경우 시퀀스 번호에 초점을 맞춰 간헐적으로 삭제된 패킷이 EP B에서 관찰되는지 확인합니다.
[admin@EP-B ~]$ tcpdump -ni eth0 icmp
11:32:26.540957 IP 10.1.1.1 > 10.1.2.1: ICMP echo request, id 3569, seq 1, length 64
11:32:26.681981 IP 10.1.2.1 > 10.1.1.1: ICMP echo reply, id 3569, seq 1, length 64
11:32:27.542175 IP 10.1.1.1 > 10.1.2.1: ICMP echo request, id 3569, seq 2, length 64
11:32:27.683078 IP 10.1.2.1 > 10.1.1.1: ICMP echo reply, id 3569, seq 2, length 64
11:32:28.543173 IP 10.1.1.1 > 10.1.2.1: ICMP echo request, id 3569, seq 3, length 64 <---
11:32:28.683851 IP 10.1.2.1 > 10.1.1.1: ICMP echo reply, id 3569, seq 3, length 64 <---
11:32:29.544931 IP 10.1.1.1 > 10.1.2.1: ICMP echo request, id 3569, seq 4, length 64
11:32:29.685783 IP 10.1.2.1 > 10.1.1.1: ICMP echo reply, id 3569, seq 4, length 64
11:32:30.546860 IP 10.1.1.1 > 10.1.2.1: ICMP echo request, id 3569, seq 5, length 64
...
삭제는 ICMP 에코 응답(EP B - EP A)에 있어야 합니다.
삭제는 ICMP 에코(EP A - EP B)에 있어야 합니다.
가능하면 두 엔드포인트 간의 계약에서 허용하는 다른 프로토콜(예: ssh, 텔넷, http 등)을 사용하여 두 엔드포인트 간의 연결을 테스트해 보십시오
아래와 같이 엔드포인트 플래핑 또는 대기/버퍼링에 문제가 있을 수 있습니다.
포워딩은 MAC 및 IP를 기반으로 하므로 포워딩 테이블(예: 엔드포인트 테이블)에 문제가 없어야 합니다. 다른 프로토콜에도 영향을 미치므로 대기/버퍼링 역시 이유가 되어서는 안 됩니다. ACI가 프로토콜에 따라 다른 전달 결정을 내리는 유일한 이유는 PBR 활용 사례입니다.
스파인 노드 중 하나에 문제가 있을 수 있습니다. 프로토콜이 다른 경우, 동일한 소스 및 목적지의 패킷이 인그레스 리프에 의해 다른 업링크/패브릭 포트(즉, 다른 스파인)에 로드 밸런싱될 수 있습니다.
Atomic Counters를 사용하면 패킷이 스파인 노드에서 삭제되어 이그레스 리프에 도달하지 않도록 보장할 수 있습니다. 패킷이 이그레스 리프에 도달하지 않은 경우 인그레스 리프의 ELAM을 확인하여 패킷이 전송되는 패브릭 포트를 확인합니다. 특정 스파인에 문제를 격리하려면 리프 업링크를 종료하여 트래픽을 다른 스파인으로 강제 전달할 수 있습니다.
ACI는 엔드포인트 테이블을 사용하여 한 엔드포인트에서 다른 엔드포인트로 패킷을 전달합니다. 부적절한 엔드포인트 정보로 인해 패킷이 잘못된 목적지로 보내지거나 잘못된 EPG로 분류되어 contract dropped될 수 있기 때문에 엔드포인트 flapping으로 인해 간헐적인 연결 문제가 발생할 수 있습니다. 대상이 엔드포인트 그룹 대신 L3Out이어야 하는 경우에도 IP가 리프 스위치에서 동일한 VRF의 엔드포인트로 학습되지 않도록 해야 합니다.
엔드포인트 플래핑 문제 해결 방법에 대한 자세한 내용은 이 섹션의 "엔드포인트 플래핑" 하위 섹션을 참조하십시오.
삭제 비율이 변경되는지 확인하려면 ping 간격을 늘리거나 줄입니다. 간격 차이는 충분히 커야 합니다.
Linux에서는 '-i' 옵션을 사용하여 간격(초)을 변경할 수 있습니다.
[EP-A ~]$ ping 10.1.2.1 -c 10 -i 5 -- Increase it to 5 sec
[EP-A ~]$ ping 10.1.2.1 -c 10 -i 0.2 -- Decrease it to 0.2 msec
간격이 감소할 때 드롭 비율이 증가하면 엔드포인트 또는 스위치에서 대기하거나 버퍼링하는 것과 관련이 있을 수 있습니다.
고려할 삭제 비율은 (삭제 횟수/시간) 대신 (전송 된 총 패킷 수/삭제 횟수)입니다.
이러한 시나리오에서는 다음을 확인합니다.
예를 들어 100000 ping이 최대한 짧은 간격으로 전송되는 경우 엔드포인트의 Rx 카운터는 100000 증가하면서 관찰될 수 있습니다.
[EP-B ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.1.2.1 netmask 255.255.255.0 broadcast 10.1.2.255
ether 00:00:10:01:01:02 txqueuelen 1000 (Ethernet)
RX packets 101105 bytes 1829041
RX errors 0 dropped 18926930 overruns 0 frame 0
TX packets 2057 bytes 926192
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
문제 해결 경로에서 ACI 패브릭을 제거하려면 리프 스위치의 이그레스 포트에 SPAN 캡처를 사용합니다.
또한 이전 버퍼링 단계에 나와 있는 것처럼 전체 네트워크 스위치를 문제 해결 경로에서 제거하는 데 대상의 Rx 카운터를 유용하게 사용할 수 있습니다.
이 섹션에서는 엔드포인트 플래핑을 확인하는 방법에 대해 설명합니다. 자세한 내용은 다음 문서에서 확인할 수 있습니다.
ACI가 여러 위치에서 동일한 MAC 또는 IP 주소를 학습하면 엔드포인트가 이동한 것처럼 보입니다. 이는 또한 스푸핑 디바이스 또는 잘못된 컨피그레이션에 의해 야기될 수 있다. 이러한 동작을 엔드포인트 플래핑이라고 합니다. 이러한 시나리오에서는 이동/플랩 엔드포인트(브리지 트래픽의 MAC 주소, 라우팅된 트래픽의 IP 주소)로 향하는 트래픽이 간헐적으로 실패합니다.
엔드포인트 플래핑을 탐지하는 가장 효과적인 방법은 고급 엔드포인트 추적기를 사용하는 것입니다. 이 앱은 훨씬 큰 패브릭을 관리해야 하는 경우 ACI AppCenter 앱으로 실행하거나 외부 서버에서 독립형 앱으로 실행할 수 있습니다.
경고! 이 가이드는 4.2에 작성되었습니다. 그 이후로 Enhanced Endpoint Tracker 앱은 더 이상 사용되지 않으며 Nexus Dashboard Insights의 기능을 더 많이 사용합니다. 자세한 내용은 Cisco 버그 ID CSCvz를 참조하십시오59365 .
위 그림에는 AppCenter의 Enhanced Endpoint Tracker가 나와 있습니다. 다음은 Enhanced Endpoint Tracker를 사용하여 플래핑 엔드포인트를 찾는 방법의 예입니다.
이 예에서 IP 10.1.2.1은 MAC 0000.1001.0102의 EP B에 속해야 합니다. 그러나 MAC 0000.1001.9999의 EP X도 잘못 구성되거나 IP 스푸핑으로 인해 IP 10.1.2.1로 트래픽을 소싱하고 있습니다.
Enhanced Endpoint Tracker(고급 엔드포인트 추적기)는 IP 10.1.2.1을 학습한 시기와 위치를 표시합니다. 위 스크린샷에 나와 있는 것처럼 MAC 0000.1001.0102(예상) 및 0000.1001.9999(예상 안 됨)를 사용하는 두 엔드포인트 간에 10.1.2.1이 펄럭입니다. 그러면 IP 10.1.2.1에 대한 연결 문제가 발생합니다. 잘못된 MAC 주소를 학습하면 패킷이 잘못된 인터페이스를 통해 잘못된 디바이스로 전송되기 때문입니다. 이 문제를 해결하려면 예기치 않은 VM이 부적절한 IP 주소로 트래픽을 소싱하지 않도록 조치를 취하십시오.
다음은 부적절한 컨피그레이션으로 인한 엔드포인트 플래핑의 일반적인 예입니다.
서버 또는 VM이 VPC 없이 두 인터페이스를 통해 ACI 리프 노드에 연결된 경우, 서버는 액티브/스탠바이 NIC 티밍을 사용해야 합니다. 그렇지 않으면 패킷이 두 업링크에 모두 로드 밸런싱되며, ACI 리프 스위치 관점에서 보면 엔드포인트가 두 인터페이스 간에 플래핑하는 것처럼 보입니다. 이 경우 액티브/스탠바이 또는 동급의 NIC 티밍 모드가 필요하거나 ACI 측에서 VPC를 사용해야 합니다.
이 장에서는 인그레스 인터페이스 삭제와 관련된 주요 카운터를 확인하는 방법에 대해 설명합니다.
ACI 모드로 실행되는 Nexus 9000 스위치에서는 인그레스 인터페이스 삭제를 위한 ACI의 세 가지 주요 하드웨어 카운터가 있습니다.
삭제의 주요 원인은 다음과 같습니다.
전달 삭제는 기본적으로 유효한 알려진 이유로 인해 삭제된 패킷입니다. 실제 데이터 트래픽 감소와 달리, 이러한 현상은 일반적으로 무시될 수 있으며 성능 저하 문제가 발생하지 않습니다.
스위치에서 유효하지 않은 프레임을 수신하면 오류로 인해 삭제됩니다. 이것의 예는 FCS 또는 CRC 오류가 있는 프레임을 포함한다. 자세한 내용은 "CRC — FCS — 컷스루 스위칭" 뒷부분의 내용을 참조하십시오.
스위치에서 프레임을 수신했는데 인그레스 또는 이그레스에 사용할 수 있는 버퍼가 없는 경우, 프레임은 'Buffer'로 삭제됩니다. 이는 일반적으로 네트워크의 어딘가에서 혼잡함을 암시합니다. 결함을 표시하는 링크가 꽉 찼거나 대상을 포함하는 링크가 혼잡할 수 있습니다.
API와 객체 모델을 활용하여 사용자가 패브릭에 이러한 삭제의 모든 인스턴스를 빠르게 쿼리할 수 있다는 점에 유의하십시오(apic에서 실행).
# FCS Errors (non-stomped CRC errors)
moquery -c rmonDot3Stats -f 'rmon.Dot3Stats.fCSErrors>="1"' | egrep "dn|fCSErrors"
# FCS + Stomped CRC Errors
moquery -c rmonEtherStats -f 'rmon.EtherStats.cRCAlignErrors>="1"' | egrep "dn|cRCAlignErrors"
# Output Buffer Drops
moquery -c rmonEgrCounters -f 'rmon.EgrCounters.bufferdroppkts>="1"' | egrep "dn|bufferdroppkts"
# Output Errors
moquery -c rmonIfOut -f 'rmon.IfOut.errors>="1"' | egrep "dn|errors"
결함이 발견되거나 CLI를 사용하여 인터페이스의 패킷 삭제를 확인해야 하는 경우, 이를 수행하는 가장 좋은 방법은 하드웨어에서 플랫폼 카운터를 보는 것입니다. 일부 카운터는 'show interface'를 사용하여 표시되지 않습니다. 세 가지 주요 삭제 이유는 플랫폼 카운터를 통해서만 볼 수 있습니다. 이를 보려면 다음 단계를 수행하십시오.
SSH를 leaf에 연결하고 이 명령을 실행합니다. 이 예는 이더넷 1/31에 대한 것입니다.
ACI-LEAF# vsh_lc
module-1# show platform internal counters port 31
Stats for port 31
(note: forward drops includes sup redirected packets too)
IF LPort Input Output
Packets Bytes Packets Bytes
eth-1/31 31 Total 400719 286628225 2302918 463380330
Unicast 306610 269471065 453831 40294786
Multicast 0 0 1849091 423087288
Flood 56783 8427482 0 0
Total Drops 37327 0
Buffer 0 0
Error 0 0
Forward 37327
LB 0
AFD RED 0
...
리프 스위치와 동일한 방법으로 고정 스파인(N9K-C9332C 및 N9K-C9364C)을 확인할 수 있습니다.
모듈형 스파인(N9K-C9504 등)의 경우 플랫폼 카운터를 보려면 먼저 라인 카드를 연결해야 합니다. spine에 SSH를 적용하고 이 명령을 실행합니다. 이 예는 이더넷 2/1에 대한 것입니다.
ACI-SPINE# vsh
ACI-SPINE# attach module 2
module-2# show platform internal counters port 1
Stats for port 1
(note: forward drops include sup redirected packets too)
IF LPort Input Output
Packets Bytes Packets Bytes
eth-2/1 1 Total 85632884 32811563575 126611414 25868913406
Unicast 81449096 32273734109 104024872 23037696345
Multicast 3759719 487617769 22586542 2831217061
Flood 0 0 0 0
Total Drops 0 0
Buffer 0 0
Error 0 0
Forward 0
LB 0
AFD RED 0
...
대기열 통계 카운터는 'show queuing interface'를 사용하여 표시됩니다. 이 예는 이더넷 1/5에 대한 것입니다.
ACI-LEAF# show queuing interface ethernet 1/5
================================================================================
Queuing stats for ethernet 1/5
================================================================================
================================================================================
Qos Class level1
================================================================================
Rx Admit Pkts : 0 Tx Admit Pkts : 0
Rx Admit Bytes: 0 Tx Admit Bytes: 0
Rx Drop Pkts : 0 Tx Drop Pkts : 0
Rx Drop Bytes : 0 Tx Drop Bytes : 0
================================================================================
Qos Class level2
================================================================================
Rx Admit Pkts : 0 Tx Admit Pkts : 0
Rx Admit Bytes: 0 Tx Admit Bytes: 0
Rx Drop Pkts : 0 Tx Drop Pkts : 0
Rx Drop Bytes : 0 Tx Drop Bytes : 0
================================================================================
Qos Class level3
================================================================================
Rx Admit Pkts : 1756121 Tx Admit Pkts : 904909
Rx Admit Bytes: 186146554 Tx Admit Bytes: 80417455
Rx Drop Pkts : 0 Tx Drop Pkts : 22
Rx Drop Bytes : 0 Tx Drop Bytes : 3776
...
위치는 '패브릭 > 인벤토리 > 리프/스파인 > 물리적 인터페이스 > 통계'입니다.
오류 통계는 동일한 위치에서 볼 수 있습니다.
마지막으로, GUI에서는 인터페이스당 QoS 통계를 표시할 수 있습니다.
CRC는 이더넷에서 4B 숫자를 반환하는 프레임의 다항식 함수이다. 모든 단일 비트 오류와 높은 비율의 이중 비트 오류를 잡아냅니다. 따라서 프레임이 전송 중에 손상되지 않았음을 확인하기 위한 것입니다. CRC 오류 카운터가 증가하는 경우 하드웨어에서 프레임 상에서 다항식 함수를 실행할 때 프레임 자체에서 발견된 4B 번호와 다른 4B 번호가 생성되었음을 의미합니다. 이중 불일치, 케이블 오류, 하드웨어 고장과 같은 여러 가지 이유로 프레임이 손상될 수 있습니다. 그러나 일부 수준의 CRC 오류가 예상되어야 하며 표준에서는 이더넷에서 최대 10-12비트 오류 속도를 허용합니다(1012비트 중 1비트는 플립될 수 있음).
저장-전달 및 컷스루 레이어 2 스위치는 모두 데이터 패킷의 대상 MAC 주소를 기준으로 전달 결정을 내립니다. 또한 스테이션이 네트워크의 다른 노드와 통신할 때 패킷의 소스 MAC(SMAC) 필드를 검사할 때 MAC 주소를 학습합니다.
저장-전달 스위치는 전체 프레임을 수신하고 무결성을 확인한 후 데이터 패킷에 대한 전달 결정을 내립니다. 컷스루 스위치는 수신 프레임의 목적지 MAC(DMAC) 주소를 검사한 직후 포워딩 프로세스에 참여합니다. 그러나 컷스루 스위치는 CRC 검사를 수행하기 전에 전체 패킷을 볼 때까지 기다려야 합니다. 즉, CRC가 검증될 때까지 패킷이 이미 전달되었으며 검사에 실패할 경우 삭제할 수 없습니다.
전통적으로 대부분의 네트워크 디바이스는 저장 후 전달을 기반으로 작동했습니다. 컷스루 스위칭 기술은 짧은 지연 시간의 포워딩이 필요한 고속 네트워크에서 사용되는 경향이 있습니다.
특히, 2세대 이상 ACI 하드웨어의 경우, 인그레스 인터페이스가 더 빠른 속도이고 이그레스 인터페이스가 같은 속도이거나 속도가 더 느린 경우 컷스루 스위칭이 수행됩니다. 저장 후 전달 스위칭은 인그레스 인터페이스 속도가 이그레스 인터페이스보다 낮은 경우 수행됩니다.
CRC 오류가 있는 패킷은 삭제해야 합니다. 프레임이 컷스루 경로에서 전환되는 경우 패킷이 이미 전달된 후 CRC 검증이 수행됩니다. 따라서 유일한 옵션은 FCS(Ethernet Frame Check Sequence)를 중단하는 것입니다. 프레임을 중단하려면 FCS를 CRC 검사를 통과하지 않는 알려진 값으로 설정해야 합니다. 이 때문에 CRC에 실패한 불량 프레임 하나가 드롭할 저장 및 전달 스위치에 도달할 때까지 통과하는 모든 인터페이스에 CRC로 표시될 수 있습니다.
예를 들어
명령을 사용하여 포트 확인
vsh_lc: 'show platform internal counter port <X>'
이 명령에서는 3개의 값이 중요합니다.
module-1# show platform internal counters port 1 | egrep ERR
RX_FCS_ERR 0 ---- Real error local between the devices and its direct neighbor
RX_CRCERR 0 ---- Stomped frame --- so likely stomped by underlying devices and generated further down the network
TX_FRM_ERROR 0 ---- Packet received from another interface that was stomp on Tx direction
손상된 링크가 손상된 프레임을 많이 생성할 경우, 해당 프레임은 다른 모든 리프 노드에 플러딩될 수 있으며 패브릭에서 대부분의 리프 노드의 패브릭 업링크 인그레스(ingress)에서 CRC를 찾을 수 있습니다. 이러한 모든 것은 손상된 단일 링크에서 발생할 수 있습니다.
개정 | 게시 날짜 | 의견 |
---|---|---|
2.0 |
08-Sep-2022 |
"Store-and-forward vs cut-through switching" 섹션 수정 |
1.0 |
10-Aug-2022 |
최초 릴리스 |