Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

32.10. Journalisation, dépannage et support de la MetalLB

Si vous avez besoin de dépanner la configuration de MetalLB, reportez-vous aux sections suivantes pour les commandes les plus couramment utilisées.

32.10.1. Définir les niveaux de journalisation de la MetalLB
Copier lien

MetalLB utilise FRRouting (FRR) dans un conteneur avec le paramètre par défaut de info, ce qui génère beaucoup de logs. Vous pouvez contrôler la verbosité des journaux générés en paramétrant logLevel comme illustré dans cet exemple.

Pour en savoir plus sur MetalLB, configurez le site logLevel à l'adresse debug comme suit :

Conditions préalables

  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
  • Vous avez installé l'OpenShift CLI (oc).

Procédure

  1. Créez un fichier, tel que setdebugloglevel.yaml, dont le contenu ressemble à l'exemple suivant : 

    apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
spec:
  logLevel: debug
  nodeSelector:
    node-role.kubernetes.io/worker: ""
    Copy to Clipboard Toggle word wrap

  2. Appliquer la configuration : 

    $ oc replace -f setdebugloglevel.yaml
    Copy to Clipboard Toggle word wrap
    Note

    Utilisez oc replace car le CR metallb est déjà créé et vous modifiez ici le niveau du journal.

  3. Affiche les noms des pods speaker: 

    $ oc get -n metallb-system pods -l component=speaker
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME                    READY   STATUS    RESTARTS   AGE
speaker-2m9pm           4/4     Running   0          9m19s
speaker-7m4qw           3/4     Running   0          19s
speaker-szlmx           4/4     Running   0          9m19s
    Copy to Clipboard Toggle word wrap

    Note

    Les pods Speaker et Controller sont recréés pour s'assurer que le niveau de journalisation mis à jour est appliqué. Le niveau de journalisation est modifié pour tous les composants de MetalLB.

  4. Consultez les journaux de speaker: 

    $ oc logs -n metallb-system speaker-7m4qw -c speaker
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    {"branch":"main","caller":"main.go:92","commit":"3d052535","goversion":"gc / go1.17.1 / amd64","level":"info","msg":"MetalLB speaker starting (commit 3d052535, branch main)","ts":"2022-05-17T09:55:05Z","version":""}
{"caller":"announcer.go:110","event":"createARPResponder","interface":"ens4","level":"info","msg":"created ARP responder for interface","ts":"2022-05-17T09:55:05Z"}
{"caller":"announcer.go:119","event":"createNDPResponder","interface":"ens4","level":"info","msg":"created NDP responder for interface","ts":"2022-05-17T09:55:05Z"}
{"caller":"announcer.go:110","event":"createARPResponder","interface":"tun0","level":"info","msg":"created ARP responder for interface","ts":"2022-05-17T09:55:05Z"}
{"caller":"announcer.go:119","event":"createNDPResponder","interface":"tun0","level":"info","msg":"created NDP responder for interface","ts":"2022-05-17T09:55:05Z"}
I0517 09:55:06.515686      95 request.go:665] Waited for 1.026500832s due to client-side throttling, not priority and fairness, request: GET:https://172.30.0.1:443/apis/operators.coreos.com/v1alpha1?timeout=32s
{"Starting Manager":"(MISSING)","caller":"k8s.go:389","level":"info","ts":"2022-05-17T09:55:08Z"}
{"caller":"speakerlist.go:310","level":"info","msg":"node event - forcing sync","node addr":"10.0.128.4","node event":"NodeJoin","node name":"ci-ln-qb8t3mb-72292-7s7rh-worker-a-vvznj","ts":"2022-05-17T09:55:08Z"}
{"caller":"service_controller.go:113","controller":"ServiceReconciler","enqueueing":"openshift-kube-controller-manager-operator/metrics","epslice":"{\"metadata\":{\"name\":\"metrics-xtsxr\",\"generateName\":\"metrics-\",\"namespace\":\"openshift-kube-controller-manager-operator\",\"uid\":\"ac6766d7-8504-492c-9d1e-4ae8897990ad\",\"resourceVersion\":\"9041\",\"generation\":4,\"creationTimestamp\":\"2022-05-17T07:16:53Z\",\"labels\":{\"app\":\"kube-controller-manager-operator\",\"endpointslice.kubernetes.io/managed-by\":\"endpointslice-controller.k8s.io\",\"kubernetes.io/service-name\":\"metrics\"},\"annotations\":{\"endpoints.kubernetes.io/last-change-trigger-time\":\"2022-05-17T07:21:34Z\"},\"ownerReferences\":[{\"apiVersion\":\"v1\",\"kind\":\"Service\",\"name\":\"metrics\",\"uid\":\"0518eed3-6152-42be-b566-0bd00a60faf8\",\"controller\":true,\"blockOwnerDeletion\":true}],\"managedFields\":[{\"manager\":\"kube-controller-manager\",\"operation\":\"Update\",\"apiVersion\":\"discovery.k8s.io/v1\",\"time\":\"2022-05-17T07:20:02Z\",\"fieldsType\":\"FieldsV1\",\"fieldsV1\":{\"f:addressType\":{},\"f:endpoints\":{},\"f:metadata\":{\"f:annotations\":{\".\":{},\"f:endpoints.kubernetes.io/last-change-trigger-time\":{}},\"f:generateName\":{},\"f:labels\":{\".\":{},\"f:app\":{},\"f:endpointslice.kubernetes.io/managed-by\":{},\"f:kubernetes.io/service-name\":{}},\"f:ownerReferences\":{\".\":{},\"k:{\\\"uid\\\":\\\"0518eed3-6152-42be-b566-0bd00a60faf8\\\"}\":{}}},\"f:ports\":{}}}]},\"addressType\":\"IPv4\",\"endpoints\":[{\"addresses\":[\"10.129.0.7\"],\"conditions\":{\"ready\":true,\"serving\":true,\"terminating\":false},\"targetRef\":{\"kind\":\"Pod\",\"namespace\":\"openshift-kube-controller-manager-operator\",\"name\":\"kube-controller-manager-operator-6b98b89ddd-8d4nf\",\"uid\":\"dd5139b8-e41c-4946-a31b-1a629314e844\",\"resourceVersion\":\"9038\"},\"nodeName\":\"ci-ln-qb8t3mb-72292-7s7rh-master-0\",\"zone\":\"us-central1-a\"}],\"ports\":[{\"name\":\"https\",\"protocol\":\"TCP\",\"port\":8443}]}","level":"debug","ts":"2022-05-17T09:55:08Z"}
    Copy to Clipboard Toggle word wrap

  5. Consulter les journaux FRR : 

    $ oc logs -n metallb-system speaker-7m4qw -c frr
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    Started watchfrr
2022/05/17 09:55:05 ZEBRA: client 16 says hello and bids fair to announce only bgp routes vrf=0
2022/05/17 09:55:05 ZEBRA: client 31 says hello and bids fair to announce only vnc routes vrf=0
2022/05/17 09:55:05 ZEBRA: client 38 says hello and bids fair to announce only static routes vrf=0
2022/05/17 09:55:05 ZEBRA: client 43 says hello and bids fair to announce only bfd routes vrf=0
2022/05/17 09:57:25.089 BGP: Creating Default VRF, AS 64500
2022/05/17 09:57:25.090 BGP: dup addr detect enable max_moves 5 time 180 freeze disable freeze_time 0
2022/05/17 09:57:25.090 BGP: bgp_get: Registering BGP instance (null) to zebra
2022/05/17 09:57:25.090 BGP: Registering VRF 0
2022/05/17 09:57:25.091 BGP: Rx Router Id update VRF 0 Id 10.131.0.1/32
2022/05/17 09:57:25.091 BGP: RID change : vrf VRF default(0), RTR ID 10.131.0.1
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF br0
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF ens4
2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF ens4 addr 10.0.128.4/32
2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF ens4 addr fe80::c9d:84da:4d86:5618/64
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF lo
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF ovs-system
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF tun0
2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF tun0 addr 10.131.0.1/23
2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF tun0 addr fe80::40f1:d1ff:feb6:5322/64
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF veth2da49fed
2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF veth2da49fed addr fe80::24bd:d1ff:fec1:d88/64
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF veth2fa08c8c
2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF veth2fa08c8c addr fe80::6870:ff:fe96:efc8/64
2022/05/17 09:57:25.091 BGP: Rx Intf add VRF 0 IF veth41e356b7
2022/05/17 09:57:25.091 BGP: Rx Intf address add VRF 0 IF veth41e356b7 addr fe80::48ff:37ff:fede:eb4b/64
2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF veth1295c6e2
2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF veth1295c6e2 addr fe80::b827:a2ff:feed:637/64
2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF veth9733c6dc
2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF veth9733c6dc addr fe80::3cf4:15ff:fe11:e541/64
2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF veth336680ea
2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF veth336680ea addr fe80::94b1:8bff:fe7e:488c/64
2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF vetha0a907b7
2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF vetha0a907b7 addr fe80::3855:a6ff:fe73:46c3/64
2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF vethf35a4398
2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF vethf35a4398 addr fe80::40ef:2fff:fe57:4c4d/64
2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF vethf831b7f4
2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF vethf831b7f4 addr fe80::f0d9:89ff:fe7c:1d32/64
2022/05/17 09:57:25.092 BGP: Rx Intf add VRF 0 IF vxlan_sys_4789
2022/05/17 09:57:25.092 BGP: Rx Intf address add VRF 0 IF vxlan_sys_4789 addr fe80::80c1:82ff:fe4b:f078/64
2022/05/17 09:57:26.094 BGP: 10.0.0.1 [FSM] Timer (start timer expire).
2022/05/17 09:57:26.094 BGP: 10.0.0.1 [FSM] BGP_Start (Idle->Connect), fd -1
2022/05/17 09:57:26.094 BGP: Allocated bnc 10.0.0.1/32(0)(VRF default) peer 0x7f807f7631a0
2022/05/17 09:57:26.094 BGP: sendmsg_zebra_rnh: sending cmd ZEBRA_NEXTHOP_REGISTER for 10.0.0.1/32 (vrf VRF default)
2022/05/17 09:57:26.094 BGP: 10.0.0.1 [FSM] Waiting for NHT
2022/05/17 09:57:26.094 BGP: bgp_fsm_change_status : vrf default(0), Status: Connect established_peers 0
2022/05/17 09:57:26.094 BGP: 10.0.0.1 went from Idle to Connect
2022/05/17 09:57:26.094 BGP: 10.0.0.1 [FSM] TCP_connection_open_failed (Connect->Active), fd -1
2022/05/17 09:57:26.094 BGP: bgp_fsm_change_status : vrf default(0), Status: Active established_peers 0
2022/05/17 09:57:26.094 BGP: 10.0.0.1 went from Connect to Active
2022/05/17 09:57:26.094 ZEBRA: rnh_register msg from client bgp: hdr->length=8, type=nexthop vrf=0
2022/05/17 09:57:26.094 ZEBRA: 0: Add RNH 10.0.0.1/32 type Nexthop
2022/05/17 09:57:26.094 ZEBRA: 0:10.0.0.1/32: Evaluate RNH, type Nexthop (force)
2022/05/17 09:57:26.094 ZEBRA: 0:10.0.0.1/32: NH has become unresolved
2022/05/17 09:57:26.094 ZEBRA: 0: Client bgp registers for RNH 10.0.0.1/32 type Nexthop
2022/05/17 09:57:26.094 BGP: VRF default(0): Rcvd NH update 10.0.0.1/32(0) - metric 0/0 #nhops 0/0 flags 0x6
2022/05/17 09:57:26.094 BGP: NH update for 10.0.0.1/32(0)(VRF default) - flags 0x6 chgflags 0x0 - evaluate paths
2022/05/17 09:57:26.094 BGP: evaluate_paths: Updating peer (10.0.0.1(VRF default)) status with NHT
2022/05/17 09:57:30.081 ZEBRA: Event driven route-map update triggered
2022/05/17 09:57:30.081 ZEBRA: Event handler for route-map: 10.0.0.1-out
2022/05/17 09:57:30.081 ZEBRA: Event handler for route-map: 10.0.0.1-in
2022/05/17 09:57:31.104 ZEBRA: netlink_parse_info: netlink-listen (NS 0) type RTM_NEWNEIGH(28), len=76, seq=0, pid=0
2022/05/17 09:57:31.104 ZEBRA: 	Neighbor Entry received is not on a VLAN or a BRIDGE, ignoring
2022/05/17 09:57:31.105 ZEBRA: netlink_parse_info: netlink-listen (NS 0) type RTM_NEWNEIGH(28), len=76, seq=0, pid=0
2022/05/17 09:57:31.105 ZEBRA: 	Neighbor Entry received is not on a VLAN or a BRIDGE, ignoring
    Copy to Clipboard Toggle word wrap

32.10.1.1. Niveaux de journalisation du FRRouting (FRR)
Copier lien

Le tableau suivant décrit les niveaux de journalisation FRR.

Expand
Tableau 32.8. Niveaux de journalisation
Niveau d'enregistrementDescription

all

Fournit toutes les informations de journalisation pour tous les niveaux de journalisation.

debug

Informations utiles au diagnostic. Réglé sur debug pour fournir des informations de dépannage détaillées.

info

Fournit des informations qui doivent toujours être enregistrées mais qui, dans des circonstances normales, ne nécessitent pas d'intervention de la part de l'utilisateur. Il s'agit du niveau de journalisation par défaut.

warn

Tout ce qui peut potentiellement provoquer un comportement incohérent de MetalLB. En général, MetalLB récupère automatiquement ce type d'erreur.

error

Toute erreur fatale au fonctionnement de MetalLB. Ces erreurs nécessitent généralement l'intervention d'un administrateur pour être corrigées.

none

Désactiver la journalisation.

32.10.2. Dépannage des problèmes BGP
Copier lien

L'implémentation BGP prise en charge par Red Hat utilise FRRouting (FRR) dans un conteneur dans les pods speaker. En tant qu'administrateur de cluster, si vous devez résoudre des problèmes de configuration BGP, vous devez exécuter des commandes dans le conteneur FRR.

Conditions préalables

  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
  • Vous avez installé l'OpenShift CLI (oc).

Procédure

  1. Affiche les noms des pods speaker: 

    $ oc get -n metallb-system pods -l component=speaker
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME            READY   STATUS    RESTARTS   AGE
speaker-66bth   4/4     Running   0          56m
speaker-gvfnf   4/4     Running   0          56m
...
    Copy to Clipboard Toggle word wrap

  2. Affichez la configuration en cours pour FRR : 

    $ oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show running-config"
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    Building configuration...

Current configuration:
!
frr version 7.5.1_git
frr defaults traditional
hostname some-hostname
log file /etc/frr/frr.log informational
log timestamp precision 3
service integrated-vtysh-config
!
router bgp 64500
    1 
    
 bgp router-id 10.0.1.2
 no bgp ebgp-requires-policy
 no bgp default ipv4-unicast
 no bgp network import-check
 neighbor 10.0.2.3 remote-as 64500
    2 
    
 neighbor 10.0.2.3 bfd profile doc-example-bfd-profile-full
    3 
    
 neighbor 10.0.2.3 timers 5 15
 neighbor 10.0.2.4 remote-as 64500
    4 
    
 neighbor 10.0.2.4 bfd profile doc-example-bfd-profile-full
    5 
    
 neighbor 10.0.2.4 timers 5 15
 !
 address-family ipv4 unicast
  network 203.0.113.200/30
    6 
    
  neighbor 10.0.2.3 activate
  neighbor 10.0.2.3 route-map 10.0.2.3-in in
  neighbor 10.0.2.4 activate
  neighbor 10.0.2.4 route-map 10.0.2.4-in in
 exit-address-family
 !
 address-family ipv6 unicast
  network fc00:f853:ccd:e799::/124
    7 
    
  neighbor 10.0.2.3 activate
  neighbor 10.0.2.3 route-map 10.0.2.3-in in
  neighbor 10.0.2.4 activate
  neighbor 10.0.2.4 route-map 10.0.2.4-in in
 exit-address-family
!
route-map 10.0.2.3-in deny 20
!
route-map 10.0.2.4-in deny 20
!
ip nht resolve-via-default
!
ipv6 nht resolve-via-default
!
line vty
!
bfd
 profile doc-example-bfd-profile-full
    8 
    
  transmit-interval 35
  receive-interval 35
  passive-mode
  echo-mode
  echo-interval 35
  minimum-ttl 10
 !
!
end
    Copy to Clipboard Toggle word wrap

    <.> La section router bgp indique l'ASN pour MetalLB. <.> Confirmez qu'une ligne neighbor <ip-address> remote-as <peer-ASN> existe pour chaque ressource personnalisée de pair BGP que vous avez ajoutée. <.> Si vous avez configuré BFD, confirmez que le profil BFD est associé au pair BGP correct et que le profil BFD apparaît dans la sortie de la commande. <.> Confirmez que les lignes network <ip-address-range> correspondent aux plages d'adresses IP que vous avez spécifiées dans les ressources personnalisées du pool d'adresses que vous avez ajoutées.

  3. Affiche le résumé BGP : 

    $ oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show bgp summary"
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    IPv4 Unicast Summary:
BGP router identifier 10.0.1.2, local AS number 64500 vrf-id 0
BGP table version 1
RIB entries 1, using 192 bytes of memory
Peers 2, using 29 KiB of memory

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt
10.0.2.3        4      64500       387       389        0    0    0 00:32:02            0        1
    1 
    
10.0.2.4        4      64500         0         0        0    0    0    never       Active        0
    2 
    

Total number of neighbors 2

IPv6 Unicast Summary:
BGP router identifier 10.0.1.2, local AS number 64500 vrf-id 0
BGP table version 1
RIB entries 1, using 192 bytes of memory
Peers 2, using 29 KiB of memory

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt
10.0.2.3        4      64500       387       389        0    0    0 00:32:02 NoNeg
    3 
    
10.0.2.4        4      64500         0         0        0    0    0    never       Active        0
    4 
    

Total number of neighbors 2
    Copy to Clipboard Toggle word wrap

    1 1 3
    Confirmez que la sortie comprend une ligne pour chaque ressource personnalisée d'homologue BGP que vous avez ajoutée.
    2 4 2 4
    La sortie qui montre 0 messages reçus et messages envoyés indique un homologue BGP qui n'a pas de session BGP. Vérifiez la connectivité du réseau et la configuration BGP de l'homologue BGP.

  4. Afficher les pairs BGP qui ont reçu un pool d'adresses : 

    $ oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show bgp ipv4 unicast 203.0.113.200/30"
    Copy to Clipboard Toggle word wrap

    Remplacez ipv4 par ipv6 pour afficher les homologues BGP qui ont reçu un pool d'adresses IPv6. Remplacez 203.0.113.200/30 par une plage d'adresses IPv4 ou IPv6 provenant d'un pool d'adresses.

    Exemple de sortie

    BGP routing table entry for 203.0.113.200/30
Paths: (1 available, best #1, table default)
  Advertised to non peer-group peers:
  10.0.2.3  <.>
  Local
    0.0.0.0 from 0.0.0.0 (10.0.1.2)
      Origin IGP, metric 0, weight 32768, valid, sourced, local, best (First path received)
      Last update: Mon Jan 10 19:49:07 2022
    Copy to Clipboard Toggle word wrap

    <.> Confirmez que la sortie comprend une adresse IP pour un homologue BGP.

32.10.3. Dépannage des problèmes BFD
Copier lien

L'implémentation de Bidirectional Forwarding Detection (BFD) prise en charge par Red Hat utilise FRRouting (FRR) dans un conteneur dans les pods speaker. L'implémentation BFD repose sur le fait que les pairs BFD sont également configurés en tant que pairs BGP avec une session BGP établie. En tant qu'administrateur de cluster, si vous devez résoudre des problèmes de configuration BFD, vous devez exécuter des commandes dans le conteneur FRR.

Conditions préalables

  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
  • Vous avez installé l'OpenShift CLI (oc).

Procédure

  1. Affiche les noms des pods speaker: 

    $ oc get -n metallb-system pods -l component=speaker
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME            READY   STATUS    RESTARTS   AGE
speaker-66bth   4/4     Running   0          26m
speaker-gvfnf   4/4     Running   0          26m
...
    Copy to Clipboard Toggle word wrap

  2. Affichez les pairs BFD : 

    $ oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show bfd peers brief"
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    Session count: 2
SessionId  LocalAddress              PeerAddress              Status
=========  ============              ===========              ======
3909139637 10.0.1.2                  10.0.2.3                 up  <.>
    Copy to Clipboard Toggle word wrap

    <.> Confirmez que la colonne PeerAddress inclut chaque pair BFD. Si la sortie ne répertorie pas l'adresse IP d'un homologue BFD que vous vous attendiez à voir figurer dans la sortie, dépannez la connectivité BGP avec l'homologue. Si le champ d'état indique down, vérifiez la connectivité des liens et de l'équipement entre le nœud et l'homologue. Vous pouvez déterminer le nom du nœud du module de haut-parleurs à l'aide d'une commande telle que oc get pods -n metallb-system speaker-66bth -o jsonpath='{.spec.nodeName}'.

32.10.4. Métriques MetalLB pour BGP et BFD
Copier lien

OpenShift Container Platform capture les métriques suivantes qui sont liées à MetalLB, aux pairs BGP et aux profils BFD :

  • metallb_bfd_control_packet_input compte le nombre de paquets de contrôle BFD reçus de chaque pair BFD.
  • metallb_bfd_control_packet_output compte le nombre de paquets de contrôle BFD envoyés à chaque pair BFD.
  • metallb_bfd_echo_packet_input compte le nombre de paquets d'écho BFD reçus de chaque pair BFD.
  • metallb_bfd_echo_packet_output compte le nombre de paquets d'écho BFD envoyés à chaque pair BFD.
  • metallb_bfd_session_down_events compte le nombre de fois où la session BFD avec un pair est entrée dans l'état down.
  • metallb_bfd_session_up indique l'état de la connexion avec un pair BFD. 1 indique que la session est up et 0 indique que la session est down.
  • metallb_bfd_session_up_events compte le nombre de fois où la session BFD avec un pair est entrée dans l'état up.
  • metallb_bfd_zebra_notifications compte le nombre de notifications BFD Zebra pour chaque pair BFD.
  • metallb_bgp_announced_prefixes_total compte le nombre de préfixes d'adresses IP de l'équilibreur de charge qui sont annoncés aux pairs BGP. Les termes prefix et aggregated route ont la même signification.
  • metallb_bgp_session_up indique l'état de la connexion avec un pair BGP. 1 indique que la session est up et 0 indique que la session est down.
  • metallb_bgp_updates_total compte le nombre de messages BGP update envoyés à un homologue BGP.

Ressources supplémentaires

  • Pour plus d'informations sur l'utilisation du tableau de bord de surveillance, reportez-vous à la section Interrogation des mesures.

32.10.5. A propos de la collecte des données MetalLB
Copier lien

Vous pouvez utiliser la commande CLI oc adm must-gather pour collecter des informations sur votre cluster, votre configuration MetalLB et le MetalLB Operator. Les fonctionnalités et objets suivants sont associés à MetalLB et à MetalLB Operator :

  • L'espace de noms et les objets enfants dans lesquels l'opérateur MetalLB est déployé
  • Toutes les définitions de ressources personnalisées (CRD) de l'opérateur MetalLB

La commande CLI oc adm must-gather collecte les informations suivantes à partir de FRRouting (FRR) que Red Hat utilise pour implémenter BGP et BFD :

  • /etc/frr/frr.conf
  • /etc/frr/frr.log
  • /etc/frr/daemons fichier de configuration
  • /etc/frr/vtysh.conf

Les fichiers de log et de configuration de la liste précédente sont collectés à partir du conteneur frr dans chaque pod speaker.

Outre les fichiers journaux et les fichiers de configuration, la commande CLI oc adm must-gather recueille les résultats des commandes vtysh suivantes :

  • show running-config
  • show bgp ipv4
  • show bgp ipv6
  • show bgp neighbor
  • show bfd peer

Aucune configuration supplémentaire n'est requise lorsque vous exécutez la commande CLI oc adm must-gather.

Ressources supplémentaires

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat