네트워킹 문제 해결

이 페이지에는 일반적인 네트워킹 문제를 해결하는 방법에 관한 세부정보가 포함되어 있습니다.

네트워크 부트스트랩 문제 해결

이 섹션에서는 네트워크 부트스트랩 프로세스를 완료할 때 발생할 수 있는 몇 가지 일반적인 오류를 보여줍니다.

구성 생성 오류

네트워크 설치를 완료하기 위해 부트스트래퍼 머신에 네트워크 구성 파일이 설치됩니다. 구성 생성 오류가 발생하면 /root/cellcfg에 있는 YAML 파일에서 실패한 스위치 구성을 확인하세요.

1단계 핑에서 부트스트랩이 멈춤

네트워크 부트스트랩 프로세스가 1단계 핑에서 멈추면 다음 단계에 따라 문제를 찾으세요.

부트스트랩 로그에서 생성된 스위치 구성 위치를 가져옵니다. /tmp/network-bootstrap/ID
IP 주소가 있는 스위치 구성 파일을 확인하여 정지된 스위치를 찾습니다.
스위치에 로그인하고 작업 로그를 확인합니다.

2단계 핑에서 부트스트랩이 멈춤

네트워크 부트스트랩 프로세스가 2단계 핑에서 멈추면 다음 단계에 따라 문제를 찾으세요.

부트스트랩 로그에서 생성된 스위치 구성 위치를 가져옵니다. /tmp/network-bootstrap/ID
관리 IP 주소로 스위치 구성 파일을 확인하여 정지된 스위치를 찾습니다.
관리 네트워크의 잠재적인 액세스 문제가 있는지 관리 스위치 구성을 확인합니다.

네트워크 2일차 조정 문제 해결

개요

GDC는 스위치 조정 중에 Cisco NX-OS에서 제공하는 구성 바꾸기 기능을 사용하여 스위치의 실행 중인 구성을 완전히 새로운 구성으로 바꿉니다. 구성 바꾸기 작업이 내부적으로 실행하는 단계는 다음과 같습니다.

현재 실행 중인 구성과 사용자가 제공한 구성 간의 차이를 계산합니다.
실행 중인 구성과 입력 구성 간의 차이인 패치 파일을 생성합니다.
패치 파일에 대한 시맨틱 유효성 검사를 실행합니다.
패치 파일을 적용합니다.
실행 중인 구성을 입력 구성과 비교하여 패치 파일이 올바르게 추가되었는지 확인합니다. 그렇지 않으면 이전 구성으로 되돌아갑니다.
명령어 configure replace commit을 실행하거나 새 구성이 되돌려야 하는 타이머가 시작됩니다.

이전 단계에서 오류가 발생할 수 있지만 3단계, 4단계, 1단계에서 가장 자주 발생합니다. 다음은 configure replace 관련 오류를 해결하는 몇 가지 방법입니다.

일반적인 문제 해결 단계

전체 스위치 상태 확인

루트 관리자 서버에서 kubectl describe aggswitch/mb-ab-aggsw01 -n gpc-system을 실행합니다 (스위치 이름을 필요한 스위치 이름으로 바꿈).

루트 관리자 클러스터의 스위치 Kubernetes 객체는 마지막 구성 바꾸기가 실패한 경우 객체 설명에 exec 및 확인 로그를 표시합니다.

마지막 구성 바꾸기 작업의 상태 확인

스위치 콘솔에서 show config-replace status을 실행합니다.

상태는 다음 정보를 제공합니다.

'완료', '실패' 등의 전체 상태입니다.
구성 교체가 커밋되었는지 또는 커밋되기를 기다리고 있는지 여부입니다.
마지막 구성 바꾸기 작업의 시작 및 종료 시간

마지막 구성 바꾸기 작업에서 적용된 구성 확인

스위치 콘솔에서 show config-replace log exec을 실행합니다.

구성 바꾸기 실행 로그는 구성 바꾸기 작업에서 패치 구성으로 결정된 구성(즉, 실행 구성과 입력 구성의 차이)을 적용하는 동안 생성된 로그를 보여줍니다.

이러한 로그에는 구성 바꾸기 작업에서 무시되는 오류가 포함되어 있는 경우가 있으며, 이러한 오류는 전체 구성 바꾸기가 실패하는 원인이 되지 않습니다. 오류가 '패치 실행' 섹션의 exec 로그 마지막 줄에 있지 않으면 구성 교체 실패의 원인이 아닐 수 있습니다.

마지막 구성 바꾸기 작업의 확인이 성공했는지 확인합니다.

스위치 콘솔에서 show config-replace log verify을 실행합니다.

구성 바꾸기 실행 단계 후 구성 바꾸기 작업은 스위치의 새 실행 구성을 입력 구성과 비교합니다. 이러한 구성은 일치해야 합니다. 그렇지 않으면 구성 교체가 실패하고 구성이 이전 구성으로 롤백됩니다.

확인 로그에는 두 섹션이 있습니다.

Configuration To Be Added Missing in Running-config: 입력 구성에는 있지만 새로 실행되는 구성에는 없는 구성을 나열합니다.
Configuration To Be Removed Present in Running-config: 새 실행 구성에는 있지만 입력 구성에는 없는 구성을 나열합니다.

스위치에서 실행된 모든 명령어 확인

스위치 콘솔에서 show accounting log start-time 2022 Sep 13 20:00:00를 실행합니다(시작 시간을 필요한 시작 시간으로 대체).

회계 로그에는 스위치에서 실행되는 모든 명령어가 표시됩니다. 이러한 로그는 NXAPI를 통해 또는 수동으로 스위치에서 실행된 명령어를 확인하는 데 유용합니다. 또한 각 구성 바꾸기 작업이 정확히 언제 실행되었는지, 몇 번 실행되었는지 파악할 수 있습니다.

스위치에 어떤 NX-API 호출이 어디에서 이루어졌는지 확인

스위치 콘솔에서 show nxapi-server logs를 실행합니다.

NX-API 로그에는 스위치에 이루어진 NXAPI 호출과 관련된 로그가 표시됩니다. 자동화 스택은 구성 교체를 실행하는 등 여러 이유로 스위치에 NXAPI 호출을 하므로 어떤 NXAPI 호출이 이루어졌고 어디에서 왔는지 확인하는 데 유용합니다.

상호 연결 문제 해결

상호 연결 API 개요

Interconnect API는 GDC 데이터 센터 셀의 외부 연결을 구성합니다. 상호 연결에는 3가지 종류가 있습니다.

데이터 센터 상호 연결 (DCI): 데이터 플레인 테두리 리프 스위치를 통해 GDC 데이터 센터에서 다른 GDC 데이터 센터로 상호 연결합니다.
고객 피어링 인터커넥트 (CPI): 데이터 플레인 경계 리프 스위치를 통해 GDC 데이터 센터에서 ORG 네트워크로 연결되는 인터커넥트입니다.
네트워크 운영 센터 (NOC): 데이터 영역 테두리 리프 스위치와 관리 집계 스위치를 통해 GDC 데이터 센터에서 네트워크 운영 센터로 상호 연결합니다.

다음 API 객체가 있습니다.

InterconnectLink: 이 API 객체는 외부 스위치에 연결되는 실제 포트를 정의합니다.
InterconnectAttachment: 이 API 객체는 구성된 InterconnectLink 위에 있는 첨부파일을 정의합니다. 첨부파일별로 포함된 정보는 다음을 정의합니다.
1. Interconnect 유형
2. BGP 정보
3. VLAN ID 정보
4. 구성된 경로 정책
RoutePolicy: 이 API 객체는 상호 연결 BGP 피어와 경로를 공유하는 데 사용되는 정책을 모델링합니다.

문제 해결

InterconnectLink 및 InterconnectAttachment 상태 확인

InterconnectLink 및 InterconnectAttachment API 객체는 현재 상태를 파악할 수 있는 풍부한 정보를 노출합니다.

InterconnectLink: 외부 스위치에 연결된 각 물리적 포트에 대해 다음 정보가 노출됩니다.
1. Up: 포트가 작동 중인지 아니면 작동 중지되었는지에 관한 상태 정보입니다.
2. DownReason: 포트가 다운된 이유입니다.
InterconnectAttachment: 구성된 각 인터커넥트 연결에 대해 다음 정보가 노출됩니다.
1. BGPStatus: BGP 세션의 상태입니다(예: Up 또는 Down).
2. UpTime: BGP 세션이 마지막으로 시작된 시간의 타임스탬프입니다.
3. PrefixCounters: 총 접두사 Received, Sent, Withdrawn를 보여주는 카운터입니다.

경로 정책 확인

RoutePolicy은 접두사 목록과 취할 작업(예: 허용 또는 거부)을 정의합니다. InterconnectAttachment 리소스와 연결된 모든 경로 정책을 나열하여 IP 주소가 유효한 RoutePolicy에 포함되는지 확인합니다.

방화벽을 통해 경계 리프 스위치에서 BGP 경로 접두사/트래픽 확인

상호 연결 데이터 경로도 침입 감지 및 방지 시스템 (IDPS) 방화벽과 경계 방화벽이라는 두 개의 PANW 방화벽을 통과합니다. 경로 접두사가 BGP 세션에서 학습된 경우에도 방화벽에서 삭제할 수 있습니다.

다양한 `VRFs`에서 학습된 경로 접두사 확인

외부 트래픽은 여러 방화벽을 통과할 때 집계 스위치에서 여러 VRF를 통과합니다. 이러한 VRF를 통해 학습된 BGP 경로 프리픽스를 확인하면 방화벽에서 삭제된 경로 프리픽스/트래픽을 확인할 수 있습니다.

모든 외부 트래픽은 경계 리프 스위치에서 트래픽의 소스 또는 대상 클러스터에 따라 외부 VRF에 배치됩니다.*-external-vrf 예: root-external-vrf에 루트 관리자 클러스터로 향하는 소스 또는 대상이 있는 트래픽이 있습니다.

트래픽이 IDPS 방화벽을 통과하면 다음 상호 연결 VRF 중 하나에 배치됩니다.

oc-vrf
dci-vrf
cp-vrf

NOC로 향하는 트래픽의 경우 추가 경계 방화벽이 있으며 이 방화벽을 통과한 트래픽은 octransit-vrf에 도달합니다.

보더 리프 스위치에 로그인하고 다음 명령어를 사용하여 다양한 VRF에서 학습된 라우팅 접두사를 표시합니다.

show bgp vrf <vrf_name> all

여기서 vrf_name은 VRF 중 하나일 수 있습니다.

ANG BGP 문제 해결

클러스터 kubeconfig 파일

객체를 확인하려면 다음 KUBECONFIG_FILE 값이 있어야 합니다.

ROOT_ADMIN_KUBECONFIG: 루트 관리자 클러스터의 kubeconfig 파일입니다.
ORG_ADMIN_KUBECONFIG: 조직 관리자 클러스터의 kubeconfig 파일입니다.
ORG_SYSTEM_KUBECONFIG: 조직 시스템 클러스터의 kubeconfig 파일입니다.
ORG_USER_KUBECONFIG: 조직 사용자 클러스터의 kubeconfig 파일입니다.

클러스터가 프로비저닝 상태에서 멈춰 있음

NodePool 객체가 준비되었는지 확인합니다.
```
kubectl --kubeconfig KUBECONFIG_FILE \
    get nodepools -A
```
노드 풀 객체가 생성되지 않거나 준비되지 않은 경우 NodePoolClaim 및 노드 연결을 확인합니다.

ClusterBGPPeer 객체가 준비되었는지 확인합니다.

ClusterBGPPeer 객체가 flat-ip-bgp-x, lb-bgp-x, node-x에 대해 생성되었는지 확인합니다.

kubectl --kubeconfig KUBECONFIG_FILE \
    get clusterbgppeers -A
...
ORG_NAME-system-cluster   flat-ip-bgp-peer-0                   16h
ORG_NAME-system-cluster   lb-bgp-peer-0                        21h
ORG_NAME-system-cluster   node-10.251.100.10-peer-10.0.224.0   21h

객체가 생성되지 않으면 NetworkGatewayGroup 및 BGPPeer 객체를 확인합니다.

BGPSession가 작동하는지 확인합니다.
```
kubectl --kubeconfig KUBECONFIG_FILE \
    get bgpsessions -A
```
BGP 세션이 설정되지 않은 경우 BGP 세션이 설정되지 않음을 참고하세요.

BGP 세션이 설정되지 않음

`TORSwitchInternal`에서 `EBGPNeighbor` 확인

ClusterBGPRouter를 확인하여 각 인터페이스의 피어링된 TOR 스위치를 가져옵니다.

ORG_NAME ClusterBGPRouter의 인터페이스는 ORG_NAME의 모든 클러스터를 피어링하는 데 사용됩니다.

 apiVersion: network.private.gdc.goog/v1alpha1
 kind: ClusterBGPRouter
 metadata:
 labels:
     clusterbgpreconciler.system.private.gdc.goog/overlay-network: external
 name: external-vrf-cluster-bgp-router
 namespace: ORG_NAME
 spec:
 clusterASN: 64513
 interfaces:
 - ip: 10.0.252.48
   switchMetadata:
   rackName: alatl14-aa
   switchRef:
       kind: TORSwitch
       name: alatl14-aa-torsw01
 - ip: 10.0.252.49
   switchMetadata:
   rackName: alatl14-aa
   switchRef:
       kind: TORSwitch
       name: alatl14-aa-torsw02
 networkASN: 65014

각 TORSwitchInternal에 대해 spec.ebgpNeighbors를 확인하여 모든 ClusterBGPPeer 객체가 구성되어 있는지 확인합니다.

TOR 스위치에서 BGP 세션 디버그

피어링된 TOR 스위치 중 하나에 SSH로 연결합니다.

ORG_NAME의 ANG BGP 인접 항목을 확인합니다.

> sh run bgp
router bgp 65014
...
  vrf ORG_NAME-external-vrf
    ...
    neighbor 10.251.100.3
      inherit peer ANG
      update-source loopback200
    neighbor 10.251.100.4
      inherit peer ANG
      update-source loopback200
    ...
  vrf ORG_NAME-internal-vrf
    ...
    neighbor 172.20.128.5
      inherit peer ANG
      update-source loopback100
    neighbor 172.20.128.6
      inherit peer ANG
      update-source loopback100
  ...

BGP 세션 상태를 확인합니다.

> sh bgp ses vrf ORG_NAME-external-vrf
> sh bgp ses vrf ORG_NAME-internal-vrf

BGP 로그를 확인합니다.

> debug ip bgp all
> no debug ip bgp all (disable log mode)

bash를 사용하여 디버깅을 이동합니다.

> run bash
> sudo tcpdmp -i any port 179 -vvv

네트워킹 문제 해결 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.