20180507 17 : MAC Address, ARP

Ethernet 이라 불리우는 랜 케이블인  Local Area Network 인 LAN에 대해서 알아보는 시간. 네트워크 레이어를 이야기할 때 서브넷에 대해서 선행적으로 알고 있어야 한다. 라우터가 있으면 같은 네트워크 prefix 를 가지고 있으며 라우터를 거치지 않고 접근이 가능한 호스트들의 집합이다. 이 호스트들은 Local Area Network 로 이루어져 있다. 

Gateway Router 가 있다면, 우리의 머신이 게이트웨이 라우터에 바로 연결된 것이 아니라 여러 다른 데이터 링크들과 함께 같이 연결되어 있다. 라우터를 거치지 않고 LAN을 통해 바로 데이터를 전달할 수 있는 것이다. 공유되는 미디엄으로 이루어진 하나의 집합인 것이다.

이더넷

단순하면서 효과적인 프로토콜이다. 데이터 링크 레이어에서 말하는 프로토콜은 전부 맥 프로토콜이며, 맥 프로토콜은 충돌은 효과적으로 해결하기 위한 프로토콜이다. 요즘에 랜의 구성은 이더넷이 스위치를 통해서 연결되어 이어주는 작업이 되고 있는 것이다.

프레임

애플리케이션 전송 단위인 메시지가 세그먼트가 되고 세그먼트가 IP 패킷이 되고 링크 레이어의 전송 단위인 프레임의 데이터 부분으로 들어간다. CRC 를 통해서 에러체킹을 한다. Type 은 안에 들어가는 데이터가 어떤 상위의 프로토콜인지 코드로 명시되어 있다. 공유되는 미디엄에 대해서, 어떻게 하면 충돌을 해결한 것인가에 대한 문제를 생각해야 한다. 이더넷에서 사용하는 맥 프로토콜은 CSMA/CD 이다. 말하기 전에 듣고 있으며, 말이 다 끝난 뒤 말을 시작한다. 이 부분에서 말을 시작한 뒤 충돌이 발생한 경우 랜덤한 시간많은 기다리며, 그 랜덤한 시간은 Exponential backoff 만큼 기다린다. 

CSMA/CD 가 정확히 어떤 의미인지, 세밀히 알 필요가 있다. CSMA/CD 의 동작을 보면, 재전송은 언제 하는가? 특정 소스에서 프레임을 보내려고 한다면 보내기 전에 듣고, 듣기가 끝나면 전송을 한다. 여기서 collision detect 를 하게 되고, backoff 만큼 기다리며 다시 재전송한다. collision detect 는 자신이 보낼 프레임이 전송되지 않았음을 말하고 있다. 여기서 TCP 의 패킷 재전송의 문제와 비교해서 말할 줄 알아야 한다.

링크 레이어에서 게이트웨이 라우터와의 경로, 결국 collision detect 의 이슈는 하나의 홉에서 일어나는 이슈이다. collision 이 판단하는 경우 재전송을 한다는 이야기이다. 하지만 collision detect 하지 않은 경우는, 자신이 전송한 프레임은 100% 잘 전송되었음을 확인 가능하다. 만약에 collision 이 발생했는데, collision 을 detect 못하게 된다면 매우 큰 문제일 것이다. (유선 이더넷 상황, 유선 케이블 상황) collision 이 발생한다면 도달하지 못할 것이다. collision 이 발생하지 않았다면, 유선 케이블의 상황에서 무사히 도착했음을 암시적으로 알 수 있다. 유선 네트워크는 케이블에 의해서 시그널이 보호받고 있다.

시나리오 생각

결론적으로, 이더넷에서 굳이 게이트웨이 라우터가 링크레이어에서의 피드백을 주지 않아도 된다. collision 이 없으면 링크레이어에서 ACKs 를 보내지 않아도 도달했음을 밝히는 것이기 때문이다. 따라서 재전송을 하지 않는다. 하지만 실제로 collision 이 발생했는데, collision 을 detect 하지 못하는 상황이 발생하는가?? 

- 이러한 상황이 왜 생겼는가 ? 그리고 어떻게 해결할 것인가?

collision 을 바로 알아차리지 못한 문제이다. 해당 프레임이 다 보내질때까지 계속 말을 끌어야 한다. 말을 짧게 하고 던져버려서, 그 사이에 일어난 collision 으 알아차리지 못한 것이다. 할 말이 많이 없어도 소스에서 최소한 어느정도라도 말을 하고 있어야 하는 것이 있다. 이를 위해 minimum frame size 64byte 라는 최소한의 길이가 있는 것이다.

만약에 소스에서 실제로 보내고자 하는 데이터가 1byte 라고 하더라도 의미없는 padding byte 를 삽입하여 혹시나 발생할 수 있는 collision 을 대비하는 것이다. 이더넷에서 존재하는 미니멈 프레임 사이즈를 강제하는 이유가 바로 위에 설명한 내용이다. 

이더넷 프레임에 적힌 헤더에 대한 이야기

링크레이어에서 사용하는 Address 체계가 있으며, 이를 MAC Address 라고 불리우는 48bit 짜리, Address 이다. source address 와 destination address 가 있는데 여기 들어가는 Address 는 MAC Address 라는 것이고, 내부에는 48bit짜리 address 가 들어가 있다. 48bit 라서 24bit 씩 끊어서 사용한다. 앞의 24bit 는 제조회사이며 뒤의 24bit는 인터페이스의 고유 번호이다. 

약간의 이해를 돕기 위한 예시

(1) 더블알

(2) 서울특별시 더블구 더블동

(3) 주민번호 : 500101 - 1000000 

라고 한 사람이 존재한다고 하자. 위에 내용을 인터넷 환경과 매칭시켜 말할 수 있다.

(1) hostname

(2) ip

(3) mac address (인터페이스 그 자체) 

(1) 과 (2)는 변경이 가능하지만, (3) 의 경우는 출시할 때 딱 찍혀 나와서 고정된 값이다.

결국 LAN 환경에서 인터페이스와 인터페이스 간의 메세지 교환을 하기 위함이다. 생각해보자. 결국 자신의 MAC Address 를 변경한다는 의미가 나한테 나가는 MAC Frame의 source Address 를 변경할 수 있다는 의미이다. 실제로 네트워크 인터페이스의 맥 어드레스를 바꾸는 것이 아니라, 약간 조작?을 가할 뿐이다. MAC Address 는 MAC Frame 에 쓰이는 주소이다. 

무조건 우리의 컴퓨터에서 가장 첫번째로 보내는 개체가 게이트웨이 라우터이다. 실제로 IP 패킷을 감싼 프레임이 전송되는 것이다. 프레임의 Source Address 는 나 자신의 인터페이스 카드라고 생각하다면, Destination Address 는 무엇일까?

시나리오 1 ( 머릿속에 그리고 말로 이야기할 줄 알아야한다. )

특정 목적지에 패킷을 보내야 하는데, 우선적으로 패킷을 게이트웨이 라우터로 보내야 한다. 우리는 게이트웨이 라우터 IP 를 알아야 하는데 어떻게 아는 것인가? DHCP 라는 프로토콜을 통해서 게이트웨이의 라우터의 IP 주소를 획득하게 되는 것이다. 따라서 무슨 일이 생기는 경우 게이트웨이 라우터로 보내야 한다는 것을 알게 된다. 우선 IP 패킷의 source address 와 destination address 는 나의 IP 와 구글의 IP가 들어간다. 구글 IP는 DNS 를 통해서 알게 되고 해당 데이터는 프레임의 데이터 속으로 들어간다. 그리고 프레임의 Source Address를 보면 해당 출발지의 MAC Address 를 넣는다. 그리고 Destination Address 는 게이트웨이 라우터의 MAC Address 가 들어간다. 하지만 게이트웨이 라우터의 MAC Address 를 어떻게 알 것인가? 

DHCP 를 통해서 게이트웨이 라우터의 IP는 알지만, MAC Address 를 알지 못한다. 따라서 게이트웨이 라우터의 IP 를 가지고 MAC Address 를 찾는 과정이 필요하다. 이 부분에 대한 명시는 각각의 호스트에 ARP 라는 테이블이 있다. ARP 는 Address Resolution Protocol 의 약자이다. ARP 테이블 내부에는 단순히 IP 주소와 IP주소대해 매핑되는 MAC Address 에 대한 테이블이다. 결국 테이블에는 게이트웨 라우터의 IP에 해당하는 MAC Address 가 적혀있는 것이다. 하지만 가장 최초에는 MAC Address 가 없기 때문에 테이블에 없다. 결국 내가 찾고자 하는 MAC Address 가 ARP 테이블에 없는 경우에는 "나" 는 ARP Request 라는 프레임을 LAN 전체에 브로드캐스트한다. ARP Request 도 프레임이기 때문에 Source 는 자기 자신이고, Dest 는 전부 1이다. (브로드캐스트는 비트가 전부 1) 

해당 메세지 내부에는 Gateway IP 가 적혀있다. 따라서 메세지에 적힌 IP가 자기자신이 아니면 버리고, 자기자신의 IP이면 MAC Address 를 반환하는 것이다. 따라서 IP 에 해당하는 MAC Address 를 모르는 경우, ARP Request 를 통해서 MAC Address 를 알 수 있다. ARP Table 에는 TTL 이 있는데, Cache 테이블의 모습으로, 유효시간이 존재한다. 따라서 캐시 테이블에 MAC Address 가 있는 경우 바로 참조하고 없는 경우 테이블을 갱신한다.

시나리오 2

시나리오 1에서 게이트웨이 라우터가 가져오는 것은 IP 패킷인데, Source 는 보낸 출발지고 Destination 은 구글을 보게 될 것이다. 게이트웨이 라우터가 해당 패킷을 받고나서 하는 일은 포워딩 테이블을 참조하여야 한다. 게이트웨이 라우터 안의 포워딩 테이블을 참조하여 destination 을 찾고 next hop을 확인한다. 포워딩 테이블을 참조해서 next hop 을 참조하고 다시 프레임으로 IP 패킷을 감싼다. 그리고 다시 source Address 는 게이트웨이 라우터의 다른 MAC Address 이다. (라우터에 여러 개의 인터페이스 카드가 존재하기 때문에 들어오는 인터페이스 카드와 나가는 인터페이스 카드가 다르다). 이후에 CSMA/CD 를 통해서 프레임을 전송한다. 그리고 destination Address 그 다음의 라우터 MAC Address 이며, 이는 ARP 테이블을 통해서 알 수 있다. 결국 이러한 과정을 반복하는 것이다.

처음 출발점부터 도착지 구글까지 IP Source Address 와 Destination Address 는 그대로이며, 프레임의 Source Address 와 Destination Address 만 변경되는 것이다. 이 과정에서 라우터는 두 개의 테이블을 참조한다.

(1) 포워딩 테이블을 통해서 Next hop 을 참조하는 것

(2) ARP 테이블을 통해서 그 다음 라우터의 MAC Address 를 참조하는 것

MAC Address 와 MAC Address 참조하는 것, 포워딩 테이블 참조, ARP 테이블 참조, 프레임 전송 원리

정리 )

• Ethernet 이란

• collision detect 는 어디서 일어나야 하는 것인가

• minimum frame size 64Byte 란 무엇을 의미하는가

• 데이터 링크 레이어의 데이터 전송 단위인 프레임에서 source Address & dest Address 는 무엇인가

• MAC Address 는 48 bit 로 이루어져 있으며 이는 무엇인가 ( 24bit + 24bit )

• ARP 란

• ARP Table 이란

• A 라는 지점의 Source 에서 Google 서버에 접속하기 위해 어떤 과정이 존재하는가? (시나리오 설명)

• 네트워크 코어의 라우터는 어느 테이블을 어떻게 참조하는가

• 프레임 전송 원리에 대해서 설명