Pemecahan masalah jaringan

Halaman ini berisi detail tentang cara memecahkan masalah jaringan umum.

Pemecahan masalah bootstrap jaringan

Bagian ini menunjukkan beberapa error umum yang mungkin Anda alami saat menyelesaikan proses bootstrap jaringan.

Error pembuatan konfigurasi

Untuk menyelesaikan penginstalan jaringan, file konfigurasi jaringan diinstal di mesin bootstrapper. Jika Anda mengalami error pembuatan konfigurasi, periksa file YAML yang ada di /root/cellcfg untuk konfigurasi tombol yang gagal.

Bootstrap terhenti di ping fase 1

Jika proses bootstrap jaringan terhenti pada ping fase 1, ikuti langkah-langkah berikut untuk menemukan masalahnya:

  1. Dapatkan lokasi konfigurasi penggantian yang dihasilkan dari log bootstrap: /tmp/network-bootstrap/ID
  2. Temukan pengalihan yang terhenti dengan melihat file konfigurasi switch dengan alamat IP.
  3. Login ke switch dan periksa log operasi.

Bootstrap terhenti di ping tahap 2

Jika proses bootstrap jaringan terhenti pada ping fase 2, ikuti langkah-langkah berikut untuk menemukan masalahnya:

  1. Dapatkan lokasi konfigurasi penggantian yang dihasilkan dari log bootstrap: /tmp/network-bootstrap/ID
  2. Temukan switch yang terhenti dengan melihat file konfigurasi switch dengan alamat IP pengelolaan.
  3. Periksa konfigurasi switch pengelolaan untuk mengetahui potensi masalah akses di jaringan pengelolaan.

Pemecahan masalah rekonsiliasi hari ke-2 jaringan

Ringkasan

GDC menggunakan fitur penggantian konfigurasi yang disediakan oleh Cisco NX-OS selama rekonsiliasi switch untuk mengganti konfigurasi yang sedang berjalan di switch dengan konfigurasi yang benar-benar baru. Langkah-langkah yang dilakukan operasi penggantian konfigurasi secara internal adalah:

  1. Menghitung perbedaan antara konfigurasi yang sedang berjalan dan konfigurasi yang disediakan pengguna.
  2. Membuat file patch yang merupakan perbedaan antara konfigurasi yang sedang berjalan dan konfigurasi input.
  3. Melakukan validasi semantik pada file patch.
  4. Menerapkan file patch.
  5. Memverifikasi bahwa file patch telah ditambahkan dengan benar dengan membandingkan running-config dengan konfigurasi input. Jika tidak, akan kembali ke konfigurasi sebelumnya
  6. Timer dimulai sebelum perintah configure replace commit harus dijalankan atau konfigurasi baru dikembalikan.

Kegagalan dapat terjadi di setiap langkah sebelumnya, tetapi paling sering terjadi selama langkah 3, 4, dan 1. Berikut adalah beberapa cara untuk memecahkan masalah error dengan configure replace.

Langkah-langkah pemecahan masalah umum

Memeriksa status peralihan keseluruhan

Di server admin root, jalankan kubectl describe aggswitch/mb-ab-aggsw01 -n gpc-system (ganti nama switch dengan nama switch yang diperlukan)

Objek Kubernetes switch di cluster admin root menampilkan log exec dan verifikasi dalam deskripsi objek jika penggantian konfigurasi terakhir gagal.

Periksa status operasi penggantian konfigurasi terakhir

Di konsol Switch, jalankan show config-replace status:

Status akan memberikan informasi berikut

  • Status keseluruhan seperti "selesai", "gagal", dll.
  • Apakah penggantian konfigurasi telah di-commit atau sedang menunggu untuk di-commit.
  • Waktu mulai dan berakhir operasi penggantian konfigurasi terakhir

Memeriksa konfigurasi mana yang diterapkan oleh operasi penggantian konfigurasi terakhir

Di konsol switch, jalankan show config-replace log exec.

Log eksekusi penggantian konfigurasi menampilkan log yang dihasilkan saat menerapkan konfigurasi yang ditentukan oleh operasi penggantian konfigurasi sebagai konfigurasi patch, yaitu perbedaan dalam konfigurasi yang sedang berjalan dan konfigurasi input.

Perhatikan bahwa log ini terkadang memiliki error yang diabaikan oleh operasi penggantian konfigurasi dan tidak menyebabkan penggantian konfigurasi gagal secara keseluruhan. Kecuali jika error adalah baris terakhir log exec di bagian "Executing Patch", error tersebut kemungkinan bukan penyebab kegagalan penggantian konfigurasi.

Periksa apakah verifikasi operasi penggantian konfigurasi terakhir berhasil

Di konsol switch, jalankan show config-replace log verify.

Setelah langkah exec penggantian konfigurasi, operasi penggantian konfigurasi akan membandingkan konfigurasi yang berjalan baru pada switch dengan konfigurasi input. Konfigurasi ini harus sama. Jika tidak, penggantian konfigurasi akan gagal dan mengembalikan konfigurasi ke konfigurasi sebelumnya.

Ada dua bagian dalam log verifikasi.

  • Configuration To Be Added Missing in Running-config: Bagian ini mencantumkan konfigurasi yang ada dalam konfigurasi input, tetapi tidak ada dalam konfigurasi baru yang sedang berjalan
  • Configuration To Be Removed Present in Running-config: Bagian ini mencantumkan konfigurasi yang ada dalam konfigurasi berjalan baru, tetapi tidak ada dalam konfigurasi input

Memeriksa semua perintah yang telah dijalankan di switch

Di konsol switch, jalankan show accounting log start-time 2022 Sep 13 20:00:00 (mengganti waktu mulai dengan waktu mulai yang diperlukan)

Log akuntansi menampilkan setiap perintah yang dijalankan di switch. Log ini dapat membantu Anda melihat perintah apa yang dijalankan di switch melalui NXAPI atau secara manual. Anda juga dapat mengetahui kapan tepatnya setiap operasi penggantian konfigurasi dijalankan dan berapa kali operasi tersebut telah dijalankan.

Periksa panggilan NX-API yang telah dilakukan ke switch dan dari mana

Di konsol Switch, jalankan show nxapi-server logs

Log NX-API menampilkan log yang terkait dengan panggilan NXAPI yang dilakukan ke switch. Karena stack otomatisasi kami melakukan panggilan NXAPI ke switch karena berbagai alasan, termasuk untuk menjalankan penggantian konfigurasi, hal ini berguna untuk melihat panggilan NXAPI yang dilakukan dan dari mana panggilan tersebut berasal.

Pemecahan Masalah Interkoneksi

Ringkasan Interconnect API

Interconnect API mengonfigurasi koneksi eksternal untuk sel pusat data GDC. Ada 3 jenis interkoneksi

  • Interkoneksi Pusat Data (DCI): Interkoneksi dari pusat data GDC ke pusat data GDC lainnya melalui switch leaf batas bidang data.
  • Customer Peering Interconnect (CPI): Interkoneksi dari pusat data GDC ke jaringan ORG melalui switch leaf batas bidang data.
  • Network Operation Center (NOC): Interkoneksi dari pusat data GDC ke Network Operation Center melalui switch leaf batas data plane dan switch agregasi pengelolaan.

Objek API berikut tersedia:

  • InterconnectLink: Objek API ini menentukan port fisik yang terhubung ke switch eksternal.
  • InterconnectAttachment: Objek API ini menentukan lampiran yang ada di atas InterconnectLink yang dikonfigurasi. Informasi yang terdapat di setiap lampiran menentukan hal berikut:

    1. Jenis interkoneksi
    2. Informasi BGP
    3. Informasi ID VLAN
    4. Kebijakan Rute yang dikonfigurasi
  • RoutePolicy: Objek API ini memodelkan kebijakan yang digunakan untuk membagikan rute dengan peer BGP interkoneksi.

Pemecahan masalah

Objek API InterconnectLink dan InterconnectAttachment menampilkan banyak informasi yang dapat menjelaskan status saat ini.

  • InterconnectLink: Informasi berikut diekspos untuk setiap port fisik yang terhubung ke switch eksternal.

    1. Up: Informasi status apakah port aktif atau tidak.
    2. DownReason: Alasan port tidak aktif.
  • InterconnectAttachment: Informasi berikut diekspos untuk setiap lampiran Interconnect yang dikonfigurasi.

    1. BGPStatus: Status sesi BGP, misalnya, Aktif atau Nonaktif.
    2. UpTime: Stempel waktu terakhir kali sesi BGP aktif.
    3. PrefixCounters: Penghitung yang menampilkan total awalan Received, Sent, dan Withdrawn.

Memverifikasi kebijakan rute

RoutePolicy menentukan daftar awalan dan tindakan yang akan dilakukan, misalnya, Izinkan atau Tolak. Mencantumkan semua kebijakan rute yang terkait dengan resource InterconnectAttachment untuk memverifikasi apakah alamat IP adalah bagian dari RoutePolicy yang valid.

Memverifikasi awalan/traffic rute BGP pada switch leaf perbatasan melalui firewall

Jalur data interkoneksi juga melintasi dua firewall PANW: firewall Intrusion Detection and Prevention System (IDPS) dan firewall perimeter. Meskipun awalan rute dipelajari dari sesi BGP, firewall mungkin menghapusnya.

Verifikasi prefiks rute yang dipelajari di berbagai VRFs

Traffic eksternal melintasi beberapa VRF di switch agregasi saat transit melalui firewall yang berbeda. Memeriksa awalan rute BGP yang dipelajari melalui VRF ini menunjukkan awalan rute/traffic yang dihentikan di firewall.

Semua traffic eksternal ditempatkan di VRF eksternal *-external-vrf bergantung pada cluster sumber atau tujuan traffic pada switch leaf border. Contoh: root-external-vrf memiliki traffic dengan sumber atau tujuan ke cluster admin root.

Setelah traffic melintasi firewall IDPS, traffic tersebut ditempatkan di salah satu VRF interkoneksi berikut:

  • oc-vrf
  • dci-vrf
  • cp-vrf

Untuk traffic yang ditujukan ke NOC, ada firewall perimeter tambahan yang setelahnya traffic akan mendarat di octransit-vrf.

Login ke switch leaf perbatasan dan gunakan perintah berikut untuk menampilkan prefiks rute yang dipelajari di berbagai VRF:

show bgp vrf <vrf_name> all

Dengan vrf_name dapat berupa salah satu VRF.

Pemecahan masalah BGP ANG

File kubeconfig cluster

Pastikan Anda memiliki nilai KUBECONFIG_FILE berikut untuk memeriksa objek:

  • ROOT_ADMIN_KUBECONFIG: file kubeconfig untuk cluster admin root.
  • ORG_ADMIN_KUBECONFIG: file kubeconfig untuk cluster admin org.
  • ORG_SYSTEM_KUBECONFIG: file kubeconfig untuk cluster sistem org.
  • ORG_USER_KUBECONFIG: file kubeconfig untuk cluster pengguna org.

Cluster macet dalam status penyediaan

  1. Pastikan objek NodePool siap.

    kubectl --kubeconfig KUBECONFIG_FILE \
        get nodepools -A
    

    Jika objek nodepool tidak dibuat atau siap, periksa NodePoolClaim dan konektivitas node.

  2. Pastikan objek ClusterBGPPeer siap.

    Pastikan objek ClusterBGPPeer dibuat untuk flat-ip-bgp-x, lb-bgp-x, dan 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
    

    Jika objek tidak dibuat, periksa objek NetworkGatewayGroup dan BGPPeer.

  3. Pastikan BGPSession sudah aktif.

    kubectl --kubeconfig KUBECONFIG_FILE \
        get bgpsessions -A
    

    Jika sesi BGP tidak aktif, lihat Sesi BGP tidak dibuat.

Sesi BGP tidak dibuat

Periksa EBGPNeighbor di TORSwitchInternal

  1. Periksa ClusterBGPRouter untuk mendapatkan switch TOR yang di-peering dari setiap antarmuka.

    Antarmuka ORG_NAME ClusterBGPRouter digunakan untuk melakukan peering semua cluster 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
    
  2. Untuk setiap TORSwitchInternal, periksa spec.ebgpNeighbors untuk melihat apakah semua objek ClusterBGPPeer dikonfigurasi.

Men-debug sesi BGP di switch TOR

  1. SSH ke salah satu switch TOR yang di-peering.
  2. Verifikasi tetangga BGP ANG untuk ORG_NAME:

    > 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
      ...
    
  3. Periksa status sesi BGP:

    > sh bgp ses vrf ORG_NAME-external-vrf
    > sh bgp ses vrf ORG_NAME-internal-vrf
    
  4. Melihat log BGP:

    > debug ip bgp all
    > no debug ip bgp all (disable log mode)
    
  5. Pindahkan proses debug menggunakan bash:

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