link local address 169.254.xxx.xxx 동작원리

 

link local  address는 dhcp로부터 ip 할당을 받지 못한 경우 자체적으로 할당하는 ip 대역으로 통상적으로 169.254.0.0/16 대역을 예약하여 사용하고있다.

그리고 많은 글들에서 169.254.0.0/16 대역의 ip를 사용하는 서버끼리는 같은 network segment(broadcast domain, subnet, LAN)에 있다면 통신이 가능하다고한다.

 

이는 dhcp ip 할당을 실패하더라도 다른 서버를 통해 접근을 하기 위한 방안이라고한다.

여기서 드는 의문, 같은 network segment에서 local link address만 사용하는 서버와 정상적인 subnet의 ip를 사용하는 서버간 통신이 가능할까?

같은 network segment에 구성된 서버라면 사실 굳이 ip의 제약이 없다는 것은 알고 있다.

서로 router를 통한 통신을 하지 않고 arp프로토콜을 통해서 broadcast를하고 mac주소를 얻어내어 통신이 가능하기 때문이다.

이론적으로는 가능할텐데 실제로도 되는지 궁금?했다

(chatGPT에게 물어봤는데 명확한 답은 안알려줬다.)

 

요약 결론:

가능하다. 단 라우팅 설정을 서로 해줘야한다.

 

 

 

같은 broadcast 도메인에 있는 서버 3대를 준비한다.

(여기서 ip는 가상이다.)

 

1대는 기존 subnet 대역의 사설ip(10.64.64.33)를 그대로 유지,

나머지 2대는 기존에 있던 ip를 제거하고 169.254.xxx.xxx를 할당한다.

$ ip addr | grep eth0 | grep inet
    inet 10.64.64.33/24 brd 10.64.64.255 scope global eth0
    
$ ip addr | grep eth0 | grep inet
    inet 169.254.111.123/16 brd 10.254.255.255 scope global eth0
    
$ ip addr | grep eth0 | grep inet
    inet 169.254.111.124/16 brd 10.254.255.255 scope global eth0

Centos7 환경이며, ip 할당 과정과 설명은 생략하겠다..

 

 

가정 1. link local  address 간 통신, ping 체크

-> O.K, arp 테이블도 잘쌓임

 

가정 2. 기존 사설 ip <> link local address 통신, ping 체크

-> 실패

 

분명 이론상 가능할 거 같았는데 실패했다.. 왜지?

1번은 되고 왜 2번은 안되지? 원리가 무슨 link local address끼리만 하게끔 굳이 막고 그런건 없을텐데? 

arp로 mac주소만 가져오면 되는거 아닌가? 하고 생각하던 찰나.. 생각해보니 서버는 통신마다 arp를 무작정 날리지 않는다

라우팅 테이블에 적혀있는 라우팅 정보를 보고 먼저 어따 물어볼지 정하지 않는가!!

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.64.64.1      0.0.0.0         UG    100    0        0 eth0
10.64.64.0      0.0.0.0         255.255.2555.0  U     0      0        0 eth0

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0

ip를 할당하는 과정에서 자신의 subnet대역, link local address는 169.254.0.0/16, 기존 대역은 10.64.64.0/24만 0.0.0.0으로만 gateway가 셋팅되서 그랬던것 뿐.. (gateway 0.0.0.0은 나갈 gateway가 없다, i.e. 같은 LAN이란 뜻)

 

link-local address 서버에 ip route add 10.64.64.0 via 0.0.0.0 dev eth0 명령어후 ping 10.64.64.33을 날려보니 역시 안된다

그래도, arp 테이블에 정확하게 mac address는 들어왔다! -> arp의 broadcast가 나가고 응답받아 mac address는 정상적으로 채웠지만 응답은 없었다는 뜼

-> 생각해보니 10.64.64.33 이쪽 서버에는 link-local address 라우팅 설정을 안했다 ㅎ;

양쪽다 라우팅 설정을 해주니 정상적으로 통신 잘~ 된다.

 

 

결론! link-local 주소 대역은 사실 하나의 network segment끼리의 사설대역 ip로 쓰자는 일종의 약속일 뿐이다.

그렇기 때문에 network segment 밖으로 나가게되면 link-local address는 고유함을 보장받을 수 없다.

딱 이런 약속일뿐 서버의 커널이나 핵심 OS 시스템이 Link-local address를 위해서 특별한 기능을 갖고 있는건 아니다.

단, dhcp에서 ip 할당을 못받으면 dhcp client가 적당히 사용 가능한 link-local address는 할당 할 수 있다.

 

단, 라우터나 인터넷의 ISP등은 link-local address가 network segment에서 다른 network segment 밖으로 나가지 않게 필터링을 하는게 일반적이다. 만약 하지 않는다면 약속을 지키지 않고 구성이나 설정에 허점이 있는 것!

 

dhcp에서 할당을 못받았을 때도 사용 가능하고, cloud-init 같은 시스템에서는 ip 할당을 못받은 서버가 미리 link-local address를 갖는 특정 서버에 접근해서 셋팅에 필요한 data를 가져올 수도 있다.

https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html

인스턴스 메타데이터 검색 - Amazon Elastic Compute Cloud