30.12. MetalLB 로깅, 문제 해결 및 지원
MetalLB 구성 문제를 해결해야 하는 경우 일반적으로 사용되는 명령에 대한 다음 섹션을 참조하십시오.
30.12.1. MetalLB 로깅 수준 설정
MetalLB는 기본 정보
설정을 사용하여 컨테이너에서 FRRouting(FRR)을 사용합니다. 이 예에 설명된 대로 logLevel
을 설정하여 생성된 로그의 상세 수준을 제어할 수 있습니다.
logLevel
을 다음과 같이 debug
로 설정하여 MetalLB에 대한 더 깊은 통찰력을 얻습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
OpenShift CLI(
oc
)가 설치되어 있습니다.
프로세스
다음 예와 같은 콘텐츠를 사용하여
setdebugloglevel.yaml
과 같은 파일을 생성합니다.apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb-system spec: logLevel: debug nodeSelector: node-role.kubernetes.io/worker: ""
설정을 적용합니다.
$ oc replace -f setdebugloglevel.yaml
참고여기에서는
metallb
CR이 이미 생성되어 있으며 여기에서 로그 수준을 변경하고 있는 경우oc replace
를 사용합니다.발표자
Pod의 이름을 표시합니다.$ oc get -n metallb-system pods -l component=speaker
출력 예
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
참고speaker 및 controller Pod가 다시 생성되어 업데이트된 로깅 수준이 적용되도록 합니다. 로깅 수준은 MetalLB의 모든 구성 요소에 대해 수정됩니다.
발표자
로그를 확인합니다.$ oc logs -n metallb-system speaker-7m4qw -c speaker
출력 예
{"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"}
FRR 로그를 확인합니다.
$ oc logs -n metallb-system speaker-7m4qw -c frr
출력 예
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
30.12.1.1. FRRouting (FRR) 로그 수준
다음 표에서는 FRR 로깅 수준을 설명합니다.
로그 수준 | 설명 |
---|---|
| 모든 로깅 수준에 대한 모든 로깅 정보를 제공합니다. |
|
사람이 진단적으로 도움이 되는 정보입니다. |
| 항상 기록되어야 하지만 정상적인 상황에서 사용자 개입이 필요하지 않은 정보를 제공합니다. 이는 기본 로깅 수준입니다. |
|
잠재적으로 일관되지 않은 |
|
|
| 모든 로깅을 끕니다. |
30.12.2. BGP 문제 해결
Red Hat이 지원하는 BGP 구현에서는 speaker
Pod의 컨테이너에서 FRRouting(FRR)을 사용합니다. 클러스터 관리자는 BGP 구성 문제를 해결해야 하는 경우 FRR 컨테이너에서 명령을 실행해야 합니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
OpenShift CLI(
oc
)가 설치되어 있습니다.
프로세스
발표자
Pod의 이름을 표시합니다.$ oc get -n metallb-system pods -l component=speaker
출력 예
NAME READY STATUS RESTARTS AGE speaker-66bth 4/4 Running 0 56m speaker-gvfnf 4/4 Running 0 56m ...
FRR에 대한 실행 중인 구성을 표시합니다.
$ oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show running-config"
출력 예
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 neighbor 10.0.2.4 bfd profile doc-example-bfd-profile-full neighbor 10.0.2.4 timers 5 15 ! address-family ipv4 unicast network 203.0.113.200/30 4 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 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 transmit-interval 35 receive-interval 35 passive-mode echo-mode echo-interval 35 minimum-ttl 10 ! ! end
BGP 요약을 표시합니다.
$ oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show bgp summary"
출력 예
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 10.0.2.4 4 64500 0 0 0 0 0 never Active 0 Total number of neighbors 2
주소 풀을 수신한 BGP 피어를 표시합니다.
$ oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show bgp ipv4 unicast 203.0.113.200/30"
ipv4
를ipv6
으로 교체하여 IPv6 주소 풀을 수신한 BGP 피어를 표시합니다.203.0.113.200/30
을 주소 풀에서 IPv4 또는 IPv6 IP 주소 범위로 바꿉니다.출력 예
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 1 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
- 1
- 출력에 BGP 피어의 IP 주소가 포함되어 있는지 확인합니다.
30.12.3. BFD 문제 해결
Red Hat이 지원하는 BFD(Bidirectional Forwarding Detection) 구현에서는 발표자
Pod의 컨테이너에서 FRRouting(FRR)을 사용합니다. BFD 구현은 BFD 피어를 설정된 BGP 세션을 통해 BGP 피어로 구성되고 있습니다. 클러스터 관리자는 BFD 구성 문제를 해결해야 하는 경우 FRR 컨테이너에서 명령을 실행해야 합니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
OpenShift CLI(
oc
)가 설치되어 있습니다.
프로세스
발표자
Pod의 이름을 표시합니다.$ oc get -n metallb-system pods -l component=speaker
출력 예
NAME READY STATUS RESTARTS AGE speaker-66bth 4/4 Running 0 26m speaker-gvfnf 4/4 Running 0 26m ...
BFD 피어를 표시합니다.
$ oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show bfd peers brief"
출력 예
Session count: 2 SessionId LocalAddress PeerAddress Status ========= ============ =========== ====== 3909139637 10.0.1.2 10.0.2.3 up <.>
<.>
PeerAddress
열에 각 BFD 피어가 포함되어 있는지 확인합니다. 출력에 출력에 포함할 것으로 예상되는 BFD 피어 IP 주소가 나열되지 않은 경우 피어와 BGP 연결 문제를 해결합니다. 상태 필드가다운
된 경우 노드와 피어 간의 링크와 장비에 대한 연결을 확인합니다.oc get pods -n metallb-system speaker-66bth -o jsonpath='{.spec.nodeName}'
와 같은 명령을 사용하여 speaker Pod의 노드 이름을 확인할 수 있습니다.
30.12.4. BGP 및 BFD에 대한 MetalLB 메트릭
OpenShift Container Platform은 BGP 피어 및 BFD 프로필과 관련된 MetalLB의 다음 Prometheus 지표를 캡처합니다.
이름 | 설명 |
---|---|
| 각 BFD 피어로부터 수신된 BFD 제어 패킷의 수를 계산합니다. |
| 각 BFD 피어로 전송되는 BFD 제어 패킷의 수를 계산합니다. |
| 각 BFD 피어로부터 수신된 BFD 에코 패킷의 수를 계산합니다. |
| 각 BFD로 전송되는 BFD 에코 패킷의 수를 계산합니다. |
|
피어가 |
|
BFD 피어와의 연결 상태를 나타냅니다. |
|
피어가 |
| 각 BFD 피어에 대한 BFD Zebra 알림 수를 계산합니다. |
이름 | 설명 |
---|---|
| BGP 피어에 광고되는 로드 밸런서 IP 주소 접두사 수를 계산합니다. 접두사 및 집계 경로 라는 용어는 동일한 의미가 있습니다. |
|
BGP 피어와의 연결 상태를 나타냅니다. |
| 각 BGP 피어로 전송되는 BGP 업데이트 메시지의 수를 계산합니다. |
| 각 BGP 피어로 전송되는 BGP 공개 메시지의 수를 계산합니다. |
| 각 BGP 피어로부터 수신된 BGP 공개 메시지의 수를 계산합니다. |
| 각 BGP 피어로 전송되는 BGP 알림 메시지의 수를 계산합니다. |
| 각 BGP 피어로부터 수신된 BGP 업데이트 메시지의 수를 계산합니다. |
| 각 BGP 피어에 전송된 BGP keepalive 메시지의 수를 계산합니다. |
| 각 BGP 피어에서 수신된 BGP keepalive 메시지의 수를 계산합니다. |
| 각 BGP 피어에 전송된 BGP 경로 새로 고침 메시지의 수를 계산합니다. |
| 각 BGP 피어로 전송되는 총 BGP 메시지 수를 계산합니다. |
| 각 BGP 피어로부터 수신된 총 BGP 메시지 수를 계산합니다. |
추가 리소스
- 모니터링 대시보드 사용에 대한 자세한 내용은 메트릭 쿼리 를 참조하십시오.
30.12.5. MetalLB 데이터 수집 정보
oc adm must-gather
CLI 명령을 사용하여 클러스터, MetalLB 구성 및 MetalLB Operator에 대한 정보를 수집할 수 있습니다. 다음 기능 및 오브젝트는 MetalLB 및 MetalLB Operator와 연결되어 있습니다.
- MetalLB Operator가 배포된 네임스페이스 및 하위 오브젝트
- 모든 MetalLB Operator CRD(사용자 정의 리소스 정의)
oc adm must-gather
CLI 명령은 Red Hat이 BGP 및 BFD를 구현하는 데 사용하는 FRRouting (FRR)에서 다음 정보를 수집합니다.
-
/etc/frr/frr.conf
-
/etc/frr/frr.log
-
/etc/frr/daemons
구성 파일 -
/etc/frr/vtysh.conf
이전 목록의 로그 및 구성 파일은 각 speaker
pod의 frr
컨테이너에서 수집됩니다.
로그 및 구성 파일 외에도 oc adm must-gather
CLI 명령은 다음 vtysh
명령에서 출력을 수집합니다.
-
running-config 표시
-
bgp ipv4 표시
-
bgp ipv6 표시
-
Bgp Neories를 표시합니다.
-
bfd 피어 표시
oc adm must-gather
CLI 명령을 실행할 때 추가 구성이 필요하지 않습니다.
추가 리소스