Kubernetes/Network Study

Calico 개념 및 실습

백곰곰 2024. 9. 21. 16:47
728x90
반응형

가시다님의 Kubernetes Advanced Networking Study에 참여하게 되어, 스터디 때 다룬 주제를 정리하려고 합니다.
3주차는 Calico CNI를 주제로 진행되었습니다.

 

Calico란?

Calico는 Kubernetes 워크로드와 Kubernetes가 아닌 레거시 워크로드가 원활하고 안전하게 통신할 수 있도록 해주는 네트워킹 및 보안 솔루션입니다. Calico CNI와 Calico network policy가 있습니다.

 

Calico 구성 요소

https://docs.tigera.io/calico/latest/reference/architecture/overview

  • calico datastore
    • calico 동작을 위한 데이터 저장소이며, Kubernetes API server(기본), ETCD 중 선택 가능하며 해당 저장소에 접근하기 위한 driver를 제공함(kubernetes, etcd)
  • calico-node 파드
    • felix
      • host 네트워크 인터페이스, 라우팅 테이블, iptables 규칙 관리
      • 학습한 파드 CIDR을 노드(host)의 라우팅 테이블에 업데이트
    • bird
      • 라우팅 데몬으로, 각 노드가 관리하는 파드 CIDR을 광고하는 역할 담당(BGP 라우팅)
      • 노드 종료 전 해당 노드의 파드 CIDR에 대한 라우팅 정보를 삭제할 수 있도록 광고
    • confd
      • calico datastore에 변경 발생 시, 해당 설정이 bird에 반영될 수 있게 함
  • CNI IPAM 플러그인
    • 자체 IPAM 플러그인을 제공하며, host-local 의 ip 대역은 사용하지 않음

Calico 모드

  • IPIP
    • 파드간 통신 시 노드 <-> 노드 구간에서 IPIP 인켑슐레이션을 통해 이루어짐
  • Direct
    • 원본 패킷 그대로 전달(파드 ip로 통신)
    • 다른 네트워크(서브넷)에서는 파드 ip에 대한 라우팅 정보가 없기 때문에 추가적인 조치 필요
  • CrossSubnet
    • 같은 네트워크의 노드간은 Direct 모드로, 다른 네트워크의 노드간은 IPIP 모드 사용
  • VXLAN
    • 파드간 통신 시 노드 <-> 노드 구간에서 VXLAN 인켑슐레이션을 통해 이루어짐
  • pod 패킷 암호화
    • WireGuard 터널을 통해 파드 트래픽을 암호화하여 노드간 전달

Calico 설치

[실습 환경 구성]

cloudformation을 통해 클러스터를 구성합니다.

control plane 1대, worker node 3대로 구성된 클러스터이며, kubeadm이 사용됩니다.

jboss-cli
curl -O https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/kans/kans-3w.yaml aws cloudformation deploy --template-file kans-3w.yaml --stack-name mylab --parameter-overrides MyInstanceType=t2.micro[EC2 타입] KeyName=[key-name] SgIngressSshCidr=$(curl -s ipinfo.io/ip)/32 --region ap-northeast-2

 

상세 구성

  • EC2
    • 컨트롤 플레인 노드
      • k8s-m : IP : 192.168.10.10
    • 데이터 플레인 노드
      • k8s-w0 : 192.168.10.101
      • k8s-w1 : 192.168.10.102
      • k8s-w2 : 192.168.20.100 (대역이 다름)

[클러스터 접속]

bash
# k8s-m EC2 SSH 접속 후 kubeconfig 설정 ssh -i [pem key] ubuntu@$(aws cloudformation describe-stacks --stack-name mylab --query 'Stacks[*].Outputs[0].OutputValue' --output text --region ap-northeast-2) kubectl config rename-context "kubernetes-admin@kubernetes" "HomeLab" (⎈|HomeLab:N/A) root@k8s-m:~# kubectl cluster-info Kubernetes control plane is running at https://192.168.10.10:6443 CoreDNS is running at https://192.168.10.10:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

 

[calico 설치]

현재 CNI가 설치되어 있지 않아, 노드의 IP를 사용하지 않는 파드에는 IP가 할당되지 않은 것을 확인할 수 있습니다.

bash
(⎈|HomeLab:N/A) root@k8s-m:~# kubectl get po -A -owide NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES kube-system coredns-55cb58b774-5nmd9 0/1 Pending 0 56m <none> <none> <none> <none> kube-system coredns-55cb58b774-k9tsp 0/1 Pending 0 56m <none> <none> <none> <none> kube-system etcd-k8s-m 1/1 Running 0 56m 192.168.10.10 k8s-m <none> <none> kube-system kube-apiserver-k8s-m 1/1 Running 0 56m 192.168.10.10 k8s-m <none> <none> kube-system kube-controller-manager-k8s-m 1/1 Running 0 56m 192.168.10.10 k8s-m <none> <none> kube-system kube-proxy-886qp 1/1 Running 0 56m 192.168.20.100 k8s-w0 <none> <none> kube-system kube-proxy-9g9dx 1/1 Running 0 56m 192.168.10.102 k8s-w2 <none> <none> kube-system kube-proxy-d7dht 1/1 Running 0 56m 192.168.10.10 k8s-m <none> <none> kube-system kube-proxy-lqjf4 1/1 Running 0 56m 192.168.10.101 k8s-w1 <none> <none> kube-system kube-scheduler-k8s-m 1/1 Running 0 56m 192.168.10.10 k8s-m <none> <none>

calico cni 설치

bash
kubectl apply -f https://raw.githubusercontent.com/gasida/KANS/main/kans3/calico-kans.yaml # 설치 후 확인 (⎈|HomeLab:N/A) root@k8s-m:~# kubectl get po -A -owide NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES kube-system calico-kube-controllers-77d59654f4-5vw9g 1/1 Running 0 2m13s 172.16.184.1 k8s-w2 <none> <none> kube-system calico-node-8qdt6 1/1 Running 0 2m13s 192.168.10.101 k8s-w1 <none> <none> kube-system calico-node-gv49x 1/1 Running 0 2m13s 192.168.20.100 k8s-w0 <none> <none> kube-system calico-node-rvcbt 1/1 Running 0 2m13s 192.168.10.10 k8s-m <none> <none> kube-system calico-node-tpnns 1/1 Running 0 2m13s 192.168.10.102 k8s-w2 <none> <none> kube-system coredns-55cb58b774-5nmd9 1/1 Running 0 60m 172.16.184.3 k8s-w2 <none> <none> kube-system coredns-55cb58b774-k9tsp 1/1 Running 0 60m 172.16.184.2 k8s-w2 <none> <none> kube-system etcd-k8s-m 1/1 Running 0 60m 192.168.10.10 k8s-m <none> <none> kube-system kube-apiserver-k8s-m 1/1 Running 0 60m 192.168.10.10 k8s-m <none> <none> kube-system kube-controller-manager-k8s-m 1/1 Running 0 60m 192.168.10.10 k8s-m <none> <none> kube-system kube-proxy-886qp 1/1 Running 0 60m 192.168.20.100 k8s-w0 <none> <none> kube-system kube-proxy-9g9dx 1/1 Running 0 60m 192.168.10.102 k8s-w2 <none> <none> kube-system kube-proxy-d7dht 1/1 Running 0 60m 192.168.10.10 k8s-m <none> <none> kube-system kube-proxy-lqjf4 1/1 Running 0 60m 192.168.10.101 k8s-w1 <none> <none> kube-system kube-scheduler-k8s-m 1/1 Running 0 60m 192.168.10.10 k8s-m <none> <none>

 

calico-kube-controllers(Deployment)와 calico-node(DaemonSet)가 설치된 이후에 파드 IP가 정상적으로 할당된 것을 볼 수 있습니다.

calico-node에서 실행 중인 프로세스를 확인하면, calico의 구성 요소인 bird, felix 등을 확인할 수 있습니다.

bash
kubectl debug -it calico-node-8qdt6 -n kube-system --image nicolaka/netshoot --target=calico-node k8s-w1  ~  ps -ef PID USER TIME COMMAND 1 root 0:00 /usr/local/bin/runsvdir -P /etc/service/enabled 57 root 0:00 runsv node-status-reporter 58 root 0:00 runsv bird6 59 root 0:00 runsv bird 60 root 0:00 runsv felix 61 root 0:00 runsv cni 62 root 0:00 runsv confd 63 root 0:00 runsv monitor-addresses 64 root 0:00 runsv allocate-tunnel-addrs 65 root 0:00 calico-node -status-reporter 66 root 0:00 calico-node -monitor-token 67 root 0:00 calico-node -allocate-tunnel-addrs 68 root 0:06 calico-node -felix 70 root 0:00 calico-node -monitor-addresses 71 root 0:00 calico-node -confd 193 root 0:00 bird6 -R -s /var/run/calico/bird6.ctl -d -c /etc/calico/confd/config/bird6.cfg 194 root 0:00 bird -R -s /var/run/calico/bird.ctl -d -c /etc/calico/confd/config/bird.cfg 1535 root 0:01 zsh 1630 root 0:00 ps -ef

또한, calico-node에는 DATASTORE_TYPE, CALICO_IPV4POOL_BLOCK_SIZE, CALICO_IPV4POOL_IPIP 등 calico 에 대한 설정값이 포함되어 있습니다.

 

birdcl 명령어로 BGP 라우팅 정보, BGP 세션 상태 등을 확인할 수 있습니다.

bash
(⎈|HomeLab:N/A) root@k8s-m:~# kubectl exec -it calico-node-8qdt6 -n kube-system -- birdcl Defaulted container "calico-node" out of: calico-node, debugger-64chb (ephem), debugger-xcc44 (ephem), debugger-przz4 (ephem), upgrade-ipam (init), install-cni (init), mount-bpffs (init) BIRD v0.3.3+birdv1.6.8 ready. bird> show route 0.0.0.0/0 via 192.168.10.1 on ens5 [kernel1 05:30:56] * (10) 172.16.184.0/24 via 192.168.10.102 on ens5 [Mesh_192_168_10_102 05:30:57] * (100/0) [i] 192.168.0.2/32 via 192.168.10.1 on ens5 [kernel1 05:30:56] * (10) 192.168.10.0/24 dev ens5 [direct1 05:30:55] * (240) 192.168.10.1/32 dev ens5 [kernel1 05:30:56] * (10) 172.16.158.0/24 blackhole [static1 05:30:55] * (200) 172.16.158.0/32 dev tunl0 [direct1 05:30:55] * (240) 172.16.116.0/24 via 192.168.10.10 on ens5 [Mesh_192_168_10_10 05:30:57] * (100/0) [i] 172.16.34.0/24 via 192.168.10.1 on ens5 [Mesh_192_168_20_100 05:30:58 from 192.168.20.100] * (100/?) [i] bird> show protocol name proto table state since info static1 Static master up 05:30:56 kernel1 Kernel master up 05:30:56 device1 Device master up 05:30:56 direct1 Direct master up 05:30:56 Mesh_192_168_10_10 BGP master up 05:30:58 Established Mesh_192_168_20_100 BGP master up 05:30:59 Established Mesh_192_168_10_102 BGP master up 05:30:58 Established

 

calicoctl 설치

bash
curl -L https://github.com/projectcalico/calico/releases/download/v3.28.1/calicoctl-linux-amd64 -o calicoctl chmod +x calicoctl && mv calicoctl /usr/bin calicoctl version (⎈|HomeLab:N/A) root@k8s-m:~# calicoctl version Client Version: v3.28.1 Git commit: 601856343 Cluster Version: v3.28.1 Cluster Type: k8s,bgp,kubeadm,kdd

Calico 통신 이해하기

파드 생성 시 설정되는 항목 확인

[노드 정보 확인]

bash
(⎈|HomeLab:N/A) root@k8s-m:~# kubectl get nodes -o jsonpath='{.items[*].spec.podCIDR}' 172.16.0.0/24 172.16.3.0/24 172.16.2.0/24 172.16.1.0/24 ## worker node#1 접속 root@k8s-w1:~# ip -c -d addr show tunl0 3: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 8981 qdisc noqueue state UNKNOWN group default qlen 1000 link/ipip 0.0.0.0 brd 0.0.0.0 promiscuity 0 minmtu 0 maxmtu 0 ipip any remote any local any ttl inherit nopmtudisc numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 inet 172.16.158.0/32 scope global tunl0 valid_lft forever preferred_lft forever root@k8s-w1:~# lsns -t net NS TYPE NPROCS PID USER NETNSID NSFS COMMAND 4026531840 net 128 1 root unassigned /sbin/init ## PodCIDR에 대해 blackhole처리 root@k8s-w1:~# ip -c route | grep bird 172.16.34.0/24 via 192.168.20.100 dev tunl0 proto bird onlink 172.16.116.0/24 via 192.168.10.10 dev tunl0 proto bird onlink blackhole 172.16.158.0/24 proto bird 172.16.184.0/24 via 192.168.10.102 dev tunl0 proto bird onlink root@k8s-w1:~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.10.1 0.0.0.0 UG 100 0 0 ens5 172.16.34.0 192.168.20.100 255.255.255.0 UG 0 0 0 tunl0 172.16.116.0 192.168.10.10 255.255.255.0 UG 0 0 0 tunl0 172.16.158.0 0.0.0.0 255.255.255.0 U 0 0 0 * 172.16.184.0 192.168.10.102 255.255.255.0 UG 0 0 0 tunl0 192.168.0.2 192.168.10.1 255.255.255.255 UGH 100 0 0 ens5 192.168.10.0 0.0.0.0 255.255.255.0 U 100 0 0 ens5 192.168.10.1 0.0.0.0 255.255.255.255 UH 100 0 0 ens5 root@k8s-w1:~# iptables -t filter -S | grep cali | wc -l 39 root@k8s-w1:~# iptables -t nat -S | grep cali | wc -l 15

[파드 생성] k8s-w1 노드 지정하여 생성

bash
kubectl apply -f - <<EOF apiVersion: v1 kind: Pod metadata: name: pod1 spec: nodeName: k8s-w1 containers: - name: pod1 image: nicolaka/netshoot command: ["tail"] args: ["-f", "/dev/null"] terminationGracePeriodSeconds: 0 --- apiVersion: v1 kind: Pod metadata: name: pod2 spec: nodeName: k8s-w1 containers: - name: pod2 image: nicolaka/netshoot command: ["tail"] args: ["-f", "/dev/null"] terminationGracePeriodSeconds: 0 EOF (⎈|HomeLab:N/A) root@k8s-m:~# kubectl get po -A -owide | grep pod default pod1 1/1 Running 0 2m55s 172.16.158.1 k8s-w1 <none> <none> default pod2 1/1 Running 0 2m55s 172.16.158.2 k8s-w1 <none> <none>

172.16.158.0/24 대역에 포함된 IP로 파드가 생성된 것을 볼 수 있습니다.

bash
(⎈|HomeLab:N/A) root@k8s-m:~# kubectl get no k8s-w1 -o jsonpath='{.spec.podCIDR}' 172.16.2.0/24

이는 노드의 podCIDR과 다른 값이며, host-local IPAM을 사용하지 않는 것을 알 수 있습니다.

아래와 같이 실제 podCIDR과 IP 사용 현황을 확인할 수 있습니다.

bash
(⎈|HomeLab:N/A) root@k8s-m:~# kubectl get cm -n kube-system kubeadm-config -oyaml | grep -i subnet podSubnet: 172.16.0.0/16 serviceSubnet: 10.200.1.0/24 (⎈|HomeLab:N/A) root@k8s-m:~# calicoctl get ippool -o wide NAME CIDR NAT IPIPMODE VXLANMODE DISABLED DISABLEBGPEXPORT SELECTOR default-ipv4-ippool 172.16.0.0/16 true Always Never false false all() (⎈|HomeLab:N/A) root@k8s-m:~# calicoctl ipam show --show-blocks +----------+-----------------+-----------+------------+--------------+ | GROUPING | CIDR | IPS TOTAL | IPS IN USE | IPS FREE | +----------+-----------------+-----------+------------+--------------+ | IP Pool | 172.16.0.0/16 | 65536 | 9 (0%) | 65527 (100%) | | Block | 172.16.116.0/24 | 256 | 1 (0%) | 255 (100%) | | Block | 172.16.158.0/24 | 256 | 3 (1%) | 253 (99%) | | Block | 172.16.184.0/24 | 256 | 4 (2%) | 252 (98%) | | Block | 172.16.34.0/24 | 256 | 1 (0%) | 255 (100%) | +----------+-----------------+-----------+------------+--------------+ (⎈|HomeLab:N/A) root@k8s-m:~# calicoctl get workloadEndpoint -A NAMESPACE WORKLOAD NODE NETWORKS INTERFACE default pod1 k8s-w1 172.16.158.1/32 calice0906292e2 default pod2 k8s-w1 172.16.158.2/32 calibd2348b4f67 kube-system calico-kube-controllers-77d59654f4-5vw9g k8s-w2 172.16.184.1/32 cali97d7a104f2b kube-system coredns-55cb58b774-5nmd9 k8s-w2 172.16.184.3/32 califdb0b8d1bd6 kube-system coredns-55cb58b774-k9tsp k8s-w2 172.16.184.2/32 cali5b8256888b3

 

[파드 생성 후 노드 정보 확인]

bash
root@k8s-w1:~# ip -c link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 02:e3:49:b6:4c:63 brd ff:ff:ff:ff:ff:ff altname enp0s5 3: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 8981 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/ipip 0.0.0.0 brd 0.0.0.0 6: calice0906292e2@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8981 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netns cni-0dd15409-9a61-aadd-f129-9e2760384733 7: calibd2348b4f67@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8981 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netns cni-c1501660-a9e6-3d73-35e0-c240775986e6 root@k8s-w1:~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.10.1 0.0.0.0 UG 100 0 0 ens5 172.16.34.0 192.168.20.100 255.255.255.0 UG 0 0 0 tunl0 172.16.116.0 192.168.10.10 255.255.255.0 UG 0 0 0 tunl0 172.16.158.0 0.0.0.0 255.255.255.0 U 0 0 0 * 172.16.158.1 0.0.0.0 255.255.255.255 UH 0 0 0 calice0906292e2 172.16.158.2 0.0.0.0 255.255.255.255 UH 0 0 0 calibd2348b4f67 172.16.184.0 192.168.10.102 255.255.255.0 UG 0 0 0 tunl0 192.168.0.2 192.168.10.1 255.255.255.255 UGH 100 0 0 ens5 192.168.10.0 0.0.0.0 255.255.255.0 U 100 0 0 ens5 192.168.10.1 0.0.0.0 255.255.255.255 UH 100 0 0 ens5 root@k8s-w1:~# iptables -t filter -S | grep cali | wc -l 91 root@k8s-w1:~# iptables -t nat -S | grep cali | wc -l 15

새로 생성된 파드에 대해 네트워크 인터페이스와 route 정보가 추가된 것을 확인할 수 있습니다.

또한 iptables Filter 테이블의 다수의 규칙이 추가된 것을 알 수 있습니다.


동일 노드 내 파드 통신

pod1(VETH1) -> pod2(VETH2)

bash
# 컨트롤 플레인 노드에서 실행 VETH1=$(calicoctl get workloadEndpoint | grep pod1 | awk '{print $4}') echo $VETH1 VETH2=$(calicoctl get workloadEndpoint | grep pod2 | awk '{print $4}') echo $VETH2 # k8s-w1 에서 실행 VETH1=(위에서 확인한 값) VETH2=(위에서 확인한 값)

pod1 <-> pod2 간 통신 시, 터널이나 노드의 네트워크 인터페이슬 통하지 않고 파드의 calico 인터페이스(파드 ip)만을 통해 통신하는 것을 확인할 수 있습니다.

 

파드 - 외부 통신

pod1 <-> 외부(인터넷) 통신 시 calico 인터페이스와 노드 네트워크 인터페이스를 통해 통신이 이루어지는 것을 확인할 수 있습니다.

또한, pod ip는 노드 ip로 변환됩니다.

 

서로 다른 노드 내 파드 통신

k8s-w2노드에 pod3 생성

bash
kubectl apply -f - <<EOF apiVersion: v1 kind: Pod metadata: name: pod3 spec: nodeName: k8s-w2 containers: - name: pod3 image: nicolaka/netshoot command: ["tail"] args: ["-f", "/dev/null"] terminationGracePeriodSeconds: 0 EOF (⎈|HomeLab:N/A) root@k8s-m:~# kubectl get po -A -owide | grep pod default pod1 1/1 Running 0 68m 172.16.158.1 k8s-w1 <none> <none> default pod2 1/1 Running 0 68m 172.16.158.2 k8s-w1 <none> <none> default pod3 1/1 Running 0 13s 172.16.184.4 k8s-w2 <none> <none>

pod1 -> pod3 통신 테스트

pod1 -> pod3 통신 시 calico 인터페이스와 tunl0 인터페이스를 통해 통신하는 것을 알 수 있습니다.

기본 설정인 IPIP 모드를 사용하고 있기 때문에, IPIP 터널을 사용하여 통신합니다. 


BGP(Border Gateway Protocol) 개념 by GPT

  • BGP (Border Gateway Protocol)는 인터넷에서 사용되는 주요 라우팅 프로토콜 중 하나로, 자율 시스템(Autonomous System, AS) 간의 경로 정보를 교환하는 데 사용됩니다. 자율 시스템은 네트워크 그룹을 의미하며, 인터넷은 여러 자율 시스템으로 구성되어 있습니다. BGP는 이러한 자율 시스템들 간에 데이터를 전달하기 위한 최적의 경로를 결정하고 이를 네트워크 장치(라우터)들 간에 공유합니다.
  • BGP에서 라우팅을 자동으로 업데이트하는 과정은 라우터 간의 동적 경로 정보 교환을 통해 이루어집니다. BGP는 각 라우터가 자신의 경로 정보를 다른 라우터에게 지속적으로 공유하고, 변경 사항이 발생하면 이를 동적으로 업데이트하여 네트워크의 경로 정보를 항상 최신 상태로 유지합니다.@
    • BGP Peering 설정
      • 두 라우터 간에 BGP 세션을 설정하여 연결을 설정하고 경로 정보를 교환합니다.
    • 라우트 광고(Route Advertisement)
      • 각 라우터는 자신이 알고 있는 경로(네트워크 프리픽스(network prefixes))를 다른 피어 라우터에게 광고합니다. 만약 새로운 경로가 발견되거나, 기존 경로가 더 이상 유효하지 않게 되면 해당 경로 정보가 다른 라우터들에게 즉시 공유됩니다.
    • 경로 업데이트(Route Updates)
      • 네트워크에 변화(예: 네트워크 장애, 새로운 네트워크 추가 등)가 발생하면, 이를 감지한 라우터는 BGP 피어에게 즉시 해당 경로의 변경 사항을 업데이트합니다. 이때 사용되는 BGP 메시지는 Update 메시지라고 하며, 이를 통해 새로운 경로가 추가되거나 기존 경로가 삭제됩니다. BGP는 이런 경로 변경 사항을 수신한 후, 네트워크 전체에서 경로를 다시 계산하고 적합한 경로를 사용하도록 설정합니다.
    • 경로 선택(Route Selection)
      • 여러 경로가 있을 경우, BGP는 경로 선택 기준에 따라 가장 적합한 경로를 선택합니다. 경로 선택 기준에는 경로의 길이(AS 경로 길이), 정책 기반 라우팅, 경로 비용 등이 포함됩니다.
      • 변경된 경로가 가장 적합하다고 판단되면, BGP는 라우팅 테이블을 갱신하고 이를 다른 피어들에게 다시 전달합니다.

참고)

 

 

 

728x90