지난 시간에 이어 오늘 설명 드릴 내용은 아래 그림 우측 IP Routing입니다.
예전에 IP 분야 경력자 면접을 볼 때 우측 그림상에서 패킷 흐름/테이블 변화(아래 설명할 내용)를 화이트보드에 한번 그려 보라 한 적이 있는데요. 웃는 얼굴로 설명을 시작했지만 끝은 별로 좋지 않았다는...
지난 시간과 마찬가지로 망 구성도를 잘 봐 주시기 바랍니다. MAC/IP 값은 아래 테이블과 같습니다.
| Server/Router |
Port |
MAC 주소 |
IP 주소 |
| SVR1 |
lan1 |
m1 |
1.1.1.10 |
| SVR3 |
lan1 |
m3 |
2.1.1.30 |
|
R1
|
ge1/1 |
a1 |
1.1.1.1 |
| ge2/1 |
a2 |
2.1.1.1 |
IP Routing
1. SVR1 sends ARP Request
- IP 주소 1.1.1.10인 SVR1이 목적지 주소 2.1.1.30인 SVR3로 패킷을 전송하려 합니다.
- SVR1은 목적지 주소 2.1.1.30에 대해 자신의 Routing Table을 참조(lookup)하고, 그 결과 default route(0.0.0.0/0)에 매칭되어 "목적지로 가기 위해서는 Gateway는 1.1.1.1이고 출력 포트(OIF: Outgoing Interface)는 lan1"임을 알게 되었습니다. 보통 일반 PC의 경우 DHCP를 통해 IP 주소를 할당(임대) 받으면서 DHCP Option 3을 통해 Gateway 주소를 받아오고, 서버의 경우 운영자가 직접 Gateway 주소를 설정 합니다. 그러면 그 주소가 Routing Table에 인스톨 됩니다.
- Gateway(Default Gateway라고도 함)란 SVR1과 연결된(중간에 L2 스위치가 여러개 있던 없던 간에) 첫번째 라우터를 의미하며 이 Gateway는 나(SVR1)와 동일 네트워크에 존재합니다. (그림상에서 SVR1(1.1.1.10)과 연결된 첫번째 라우터 R1의 인터페이스 주소 1.1.1.1이 Gateway가 됨)
- SVR1은 Gateway 주소 1.1.1.1에 대한 MAC 주소가 ARP Table에 없어(ARP Miss) ARP Request 패킷을 lan1 포트로 내보내며 패킷 구성은 아래와 같습니다.
| |
Header |
Fields |
| |
Ethernet Header
|
* Destination MAC = FF:FF:FF:FF:FF:FF(브로드캐스팅, 동일 LAN에 있는 모든 노드로 전달)
* Source MAC = Sender(SVR1)의 MAC 주소 m1 |
| |
ARP Header
|
* Sender MAC = ARP Request 패킷 송신자(sender), 즉 SVR1의 MAC 주소 m1
* Sender IP = ARP Request 패킷 송신자(sender), 즉 SVR1의 IP 주소 1.1.1.10
* Target MAC = 00:00:00:00:00:00임 (SVR1은 이 값을 알고 싶어 하는 것임)
* Target IP = ARP Request 패킷 수신자(target), 즉 R1의 IP 주소 1.1.1.1 |
- 이제 이 패킷을 수신한 S1(스위치 1)은 Source MAC Learning을 수행(MAC 주소 m1은 fe1 포트에 연결되어 있음을 MAC Table에 저장)하고,
- 수신 패킷의 Destination MAC 주소를 참조하여 출력 포트를 정하게 되는데 이 경우는 브로드캐스팅 주소(FF:FF:FF:FF:FF:FF)입니다. 따라서 S1은 수신 포트를 제외한 나머지 포트로 Flooding 합니다. 따라서 이 패킷은 SVR2와 R1(라우터 1)이 수신합니다.
- SVR2는 수신된 ARP Request 패킷의 Target IP 주소가 자신의 것이 아님을 확인 후 버립니다.
2. R1 responds with ARP Reply
- ARP Request를 수신한 R1(라우터 1)은 Target IP 주소를 보고 자신의 MAC 주소를 물어 본 것임을 압니다. 따라서 R1은 1.1.1.1에 대한 MAC 주소를 Sender MAC 필드에 담아 ARP Reply 패킷을 ge1/1 포트로 내보내며, 그 패킷의 구성은 아래와 같습니다.
| |
Header |
Fields |
| |
Ethernet Header
|
* Destination MAC = ARP Reply를 수신할 SVR1의 MAC 주소 m1
* Source MAC = Sender(R1)의 MAC 주소 a1 |
| |
ARP Header
|
* Sender MAC = ARP Reply 패킷 송신자(sender), 즉 R1의 MAC 주소 a1
* Sender IP = ARP Reply 패킷 송신자(sender), 즉 R1의 IP 주소 1.1.1.1
* Target MAC = ARP Reply 패킷 수신자(target), 즉 SVR1의 MAC 주소 m1
* Target IP = ARP Reply 패킷 수신자(target), 즉 SVR1의 IP 주소 1.1.1.10 |
- 이 패킷을 수신한 S1은 Source MAC Learning을 수행(MAC 주소 a1은 fe3 포트에 연결되어 있음을 MAC Table에 저장)하고,
- 수신 패킷의 Destination MAC 주소 m1에 대한 MAC Table을 참조하여 해당 패킷을 fe1 포트로 패킷을 전달(유니캐스팅)합니다.
- 그리고 이 패킷을 수신한 SVR1은 자신의 ARP Table에 그 값(1.1.1.1의 MAC 주소 a1)을 저장합니다.
3. SVR1 sends IP Packet to R1
- 이제 SVR1은 SVR3로 IP 패킷을 보낼 준비가 되었습니다. SVR1은 아래와 같이 패킷을 구성하여 lan1 포트로 내보냅니다.
| |
Header |
Fields |
| |
Ethernet Header
|
* Destination MAC = Receiver(R1)의 MAC 주소 a1
* Source MAC = Sender(SVR1)의 MAC 주소 m1 |
| |
IP Header
|
* Destination IP = Receiver(SVR3)의 IP 주소 2.1.1.30
* Source IP = Sender(SVR1)의 IP 주소 1.1.1.10 |
- 이 패킷을 수신한 S1은 이미 Learning된 Source MAC 주소이므로 Source MAC Learning 과정은 생략하고, Destination MAC 주소 a1에 대한 MAC Table 참조를 통해 fe3 포트로 패킷을 보냅니다.
4. R1 sends ARP Request
- 패킷을 수신한 R1(라우터 1)은 자신의 FIB(Routing Table)를 참조하여 "목적지 주소 2.1.1.30은 나와 바로 붙어 있는 네트워크이고(Next Hop이 없으므로) 출력 포트는 ge2/1"라는 사실을 알게 되고,
- 이제 R1은 2.1.1.30에 대한 MAC 주소를 알기 위해 ARP Table을 참조합니다. 하지만 해당 엔트리가 없습니다(ARP Miss). 따라서 R1은 아래와 같이 ARP Request 패킷을 ge2/1 포트로 내보냅니다.
| |
Header |
Fields |
| |
Ethernet Header
|
* Destination MAC = FF:FF:FF:FF:FF:FF(브로드캐스팅, 동일 LAN에 있는 모든 노드로 전달)
* Source MAC = Sender(R1)의 MAC 주소 a2 |
| |
ARP Header
|
* Sender MAC = ARP Request 패킷 송신자(sender), 즉 R1의 MAC 주소 a2
* Sender IP = ARP Request 패킷 송신자(sender), 즉 R1의 IP 주소 2.1.1.1
* Target MAC = 00:00:00:00:00:00임 (R1은 이 값을 알고 싶어 하는 것임)
* Target IP = ARP Request 패킷 수신자(target), 즉 SVR3의 IP 주소 2.1.1.30 |
- 이 패킷을 수신한 S2(스위치 2)는 Source MAC Learning을 수행(MAC 주소 a2는 fe3 포트에 연결되어 있음을 MAC Table에 저장)하고,
- 수신 패킷의 Destination MAC 주소를 참조하여 출력 포트를 결정하는데 이 경우는 브로드캐스팅 주소(FF:FF:FF:FF:FF:FF)입니다. 따라서 S2는 수신 포트를 제외한 나머지 포트로 Flooding 합니다. 따라서 이 패킷은 SVR3과 SVR4가 수신합니다.
- SVR4는 수신된 ARP Request 패킷의 Target IP 주소가 자신의 것이 아니므로 버립니다.
5. SVR3 responds with ARP Reply
- ARP Request를 수신한 SVR3은 Target IP 주소를 보고 자신의 것임을 압니다. 따라서 SVR3은 2.1.1.30에 대한 MAC 주소를 Sender MAC 필드에 담아 ARP Reply 패킷을 lan1 포트로 내보내며, 그 패킷의 구성은 아래와 같습니다.
| |
Header |
Fields |
| |
Ethernet Header
|
* Destination MAC = ARP Reply를 수신할 R1의 MAC 주소 a2
* Source MAC = Sender(SVR3)의 MAC 주소 m3 |
| |
ARP Header
|
* Sender MAC = ARP Reply 패킷 송신자(sender), 즉 SVR3의 MAC 주소 m3
* Sender IP = ARP Reply 패킷 송신자(sender), 즉 SVR3의 IP 주소 2.1.1.30
* Target MAC = ARP Reply 패킷 수신자(target), 즉 R1의 MAC 주소 a2
* Target IP = ARP Reply 패킷 수신자(target), 즉 R1의 IP 주소 2.1.1.1 |
- 이 패킷을 수신한 S2는 Source MAC Learning을 수행(MAC 주소 m3는 fe1 포트에 연결되어 있음을 MAC Table에 저장)하고,
- 수신 패킷의 Destination MAC 주소 a2에 대한 MAC Table을 참조하여 해당 패킷을 fe3 포트로 패킷을 전달(유니캐스팅)합니다.
- 그리고 이 패킷을 수신한 R1은 자신의 ARP Table에 그 값(2.1.1.30의 MAC 주소 m3)을 저장합니다.
6. R1 sends IP Packet to SVR3
- SVR3의 MAC 주소를 알았으므로, 이제 R1(라우터 1)은 SVR1에서 SVR3로 향하는 패킷을 IP 라우팅 할 수 있습니다. R1은 아래와 같은 구성으로 SVR1이 보낸 패킷을 SVR3로 라우팅 시켜 줍니다.
| |
Header |
Fields |
| |
Ethernet Header
|
* Destination MAC = Receiver(SVR3)의 MAC 주소 m3
* Source MAC = Sender(R1)의 MAC 주소 a2 |
| |
IP Header
|
* Destination IP = Receiver(SVR3)의 IP 주소 2.1.1.30
* Source IP = Sender(SVR1)의 IP 주소 1.1.1.10 |
- 이 패킷을 수신한 S2(스위치 2)는 이미 Learning된 Source MAC 주소이므로 Source MAC Learning 과정은 건너뛰고, Destination MAC 주소 m3에 대한 MAC Table 참조를 통해 fe1 포트로 패킷을 전송하여 SVR3가 패킷을 수신합니다.
정리
모든 단말/서버(이하 서버로 부름)는 스위치와 라우터를 통해 다른 서버와 연결되어 있습니다.
서버에서 보낸 패킷이 Ethernet Switching 될 것이냐 IP Routing 될 것이냐는 결정은 패킷을 송신하는 서버에서 이미 결정이 됩니다.
지난 시간에 설명드린 바와 같이 패킷 송신 서버는 목적지 주소(1.1.1.20)가 나(1.1.1.10)와 동일 네트워크에 존재하면 해당 목적지 단말의 MAC 주소를 Destination MAC으로 하여 패킷을 전달하고 이 패킷은 스위치를 통해 Ethernet Switching 되어 수신 서버로 전달됩니다.
반면 오늘 설명과 같이 목적지 주소(2.1.1.30)가 나(1.1.1.10)와 다른 네트워크에 존재하는 경우 해당 목적지가 아닌 Gateway (1.1.1.1)의 MAC 주소를 Destination MAC으로 하여 패킷을 전달하는데, 이 때의 Gateway는 서버와 연결된 첫번째 L3 Hop, 즉 라우터(R1) 입니다. 따라서 이 패킷은 목적지 주소가 라우터 MAC 이므로 중간에 스위치가 있어도 Ethernet Switching 되어 라우터로 도착할 것이고, 라우터는 수신 패킷의 Destination MAC이 자신의 것임을 확인 한 후에 FIB lookup을 하여 IP Routing(혹은 Forwarding이라 부름) 하게 됩니다.
방금 중요한 포인트를 말씀드렸습니다.
"라우터는 수신 패킷의 Destination MAC 주소가 내 MAC이면 라우팅, 아니면 폐기합니다."
단, Destination MAC 주소가 FF:FF:FF:FF:FF:FF인 경우는 일단 라우터의 Control Plane이 받아 봅니다. 위에서 R1이 ARP Request 패킷을 수신하여 처리한 것과 같이요.
머릿속으로는 다 알고 있다고 생각했는데 글을 읽다 보니 그렇지 않았다는 깨달음을.... ^^
제대로 그리는 사람 없어요....
궁금한 게 있습니다.
L3 장비(라우터)는 IP를 인식하고
L2 장비(스위치)는 IP를 인식하지 못하고 MAC만을 알아본다고 배웠는데요.
그래서 L3 장비(라우터와 같은)는 IP만을 가지고 통신을 하는줄 알았는데 지금 과정을 살펴보면
모든 과정에서 반드시 IP와 MAC을 모두 알고 있어야 하는 건가요?
- IP 라우터는 MAC 주소가 "내 주소"인 패킷인 경우 해당 패킷의 Destination IP 주소를 참조하여 패킷 포워딩.
- L2 스위치는 수신 패킷의 Destination MAC 주소를 참조하여 패킹 스위칭
즉, IP 라우터는 Destination IP 주소를 참조하여 패킷을 포워딩하는 것이 맞습니다. 다만 모든 패킷을 포워딩 하는 것이 아니라 위 블로그 설명과 같이 해당 패킷의 Destination MAC 주소가 내 것인 경우만 포워딩하고 그렇지 않으면 폐기합니다. 이와 같이 "Destination MAC 주소가 내거냐?"에 따라 패킷 수신/폐기 여부를 결정하는 것은 PC도 마찬가지입니다.
단, Destination MAC 주소가 FF:FF:FF:FF:FF:FF인 경우는 일단 라우터의 Control Plane 이 받아 봅니다. 위에서 R1이 ARP Request 패킷을 수신하여 처리한 것과 같이요.
이 부분이 이해가 잘 안되는데 Control Plane 이 무슨 말인지 몰라서 이해가 안되는 건지..
R1이 ARP Request 패킷을 수신하여 처리한 것과 같이요. 라는 말이 무슨 말인가요?
위에서 설명한 건 목적지 IP가 내(R1) IP 주소라서 자신의 MAC 주소를 담아서 ARP Reply 패킷을 보낸 걸로 아는데요.. 이것처럼 처리한다는 말인가요? 브로드캐스트 트래픽을 받아서 내 MAC 주소를 담아서 ARP Reply 패킷을 보낸다는 건가요? SVR1 에게.. ? ... ㅠ.ㅠ
그럼 브로드캐스트 트래픽에 대해 답을 준다는 건데.. 제가 알기론 라우터는 브로드캐스트 트래픽을 버린다고 알고 있었는데 뭔가 다르네요 ㅠ.ㅠ
일반적인 브로드캐스트 패킷은 라우터가 버리는게 맞구요.
다만 ARP Request(브로드캐스트 패킷임)는 라우터가 수신하고, 필요시 이에 대한 응답(ARP Reply)을 주어야 합니다.
질문이 있습니다.
R1에서 SVR3에 대한 ARP table 이 비어 있어(MAC을 모른다면) 이미 SVR1에서 온 패킷을 가지고 있고 그것과 별개로 그것을 전달하기 위한 SVR3에 대한 ARP를 R1이 수행한다면 ARP를 알아낸다음 그전에 들어왔던 SVR1에서 SVR3로 전달하고자 하는 패킷을 전달한다고 봐도 되나요? 그럼 SVR1에서 SVR3로 가는 중이던 패킷은 잠깐 어딘가에 보관되고 있는건가요? ARP 처리는 아주 짧은 시간안에 처리되니 잠깐 보관해도 사용자는 모르고 R1에 버퍼라던지 이런곳에 특별히 문제가 없는건가요?
ARP miss 발생 시 해당 패킷은 라우터에서 버려지지 않을까 하는데요. 아래 링크 참조하세요.
http://blog.ipspace.net/2007/04/why-is-first-ping-lost.html
해당 질문을 올리고 나서 아래의 글을 읽어봤는데요 아래의 글대로라면
https://www.netmanias.com/ko/?m=view&id=blog_nwp&no=5521
⑤ Switch Module을 거쳐 이 패킷은 Line Card #2의 Egress Packet Buffer에 저장됩니다.
⑥ Line Card #2의 Packet Processor는 ARP Table을 lookup하여 Next Hop 20.1.1.1에 대한 MAC 주소가 있는지 봅니다.
⑦ 이론! ARP Table에 없습니다. 따라서 Packet Processor는 ARP Miss Event(20.1.1.1의 MAC 주소가 없어요~)를 Control Module로 전달합니다.
⑧ 본 Event를 수신한 Control Module은 ge2/1 포트로 ARP Request 패킷을 보내고, R2로 부터 ARP Reply 패킷을 수신합니다.
⑨ 그런 후 Control Module은 자신의 ARP Table에 20.1.1.1에 대한 MAC 주소 b2를 저장하고,
⑩ ARP Miss Event를 보냈던 Line Card #2의 ARP Table에 그 정보를 전달하여 저장하도록 합니다. (다른 Line Card로는 전달하지 않음)
⑪ 이제 Line Card #2는 Next Hop 20.1.1.1에 대한 MAC 주소(b2)를 알게 되었으니 Egress Packet Buffer에서 패킷을 꺼내어 ge2/1 포트로 전달하면 됩니다. 패킷 전달시 Egress Packet Processor는 이미 설정된 QoS 정책(Scheduling Algorithm)에 따라 이 패킷을 바로 보낼 수도 있고 아니면 다른 우선순위가 높은 패킷으로 인해 잠시 Egress Packet Buffer에 대기시킬 수도 있습니다(여기 클릭). R1이 R2로 전달하는 패킷 구성은 다음과 같습니다.
[Ethernet Header] Destination MAC 주소 = b2(R2의 MAC 주소), Source MAC 주소 = a5(R1의 MAC 주소)
[IP Header] Destination IP 주소 = 100.1.1.1, Source IP 주소 = 1.1.1.10(SVR1의 IP 주소)
라고 되어 있는 부분을 참조한다면 Egress Packet Buffer에 대기하고 있었다는 말이 되는게 아닌가요?
이건 장비 구현에 따라 달라지지 않을까 하는데요.
좋은 정보 감사합니다.
해당 문서는 다운로드가 불가능한가요???