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이 사용됩니다.

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 (대역이 다름)

[클러스터 접속]

# 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가 할당되지 않은 것을 확인할 수 있습니다.

(⎈|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 설치

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 등을 확인할 수 있습니다.

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 세션 상태 등을 확인할 수 있습니다.

(⎈|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 설치

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 통신 이해하기

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

[노드 정보 확인]

(⎈|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 노드 지정하여 생성

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로 파드가 생성된 것을 볼 수 있습니다.

(⎈|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 사용 현황을 확인할 수 있습니다.

(⎈|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

 

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

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)

# 컨트롤 플레인 노드에서 실행
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 생성

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