| 리포트 | 기술문서 | 테크-블로그 | 글로벌 블로그 | 원샷 갤러리 | 통신 방송 통계  | 한국 ICT 기업 총람 |

제품 검색

| 네트워크/통신 뉴스 | 기술자료실 | 자유게시판 |  
 
 
섹션 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/UHD IoT SDN/NFV Wi-Fi Video Streaming KT SK Telecom LG U+ OTT Network Protocol CDN YouTube Data Center
 
스폰서채널 |

 

  스폰서채널 서비스란?
스위칭과 라우팅... 참 쉽죠잉~ (1편: Ethernet 스위칭)
Switching and Routing (Part 1: Ethernet Switching)
May 31, 2012 | By 유창모 (cmyoo@netmanias.com)
코멘트 (21)
36

제목이 좀 유치하죠? ^^* 말랑 말랑한 블로그 공간에서의 표현이므로 너그럽게 봐 주시기 바랍니다.

 

오늘과 내일에 걸쳐 L2(Ethernet) 스위칭과 L3(IP) 라우팅 과정에서 살펴 보도록 하겠습니다. 본 글을 통해 다음과 같은 내용을 설명 드리도록 하겠습니다.

  • ARP와 IP 패킷
  • 스위칭/라우팅 과정에서 Ethernet Header의 변화
  • 스위칭/라우팅 과정 전후로 단말과 스위치, 라우터의 테이블(Routing, ARP, MAC Table) 엔트리 변화

 

Switching과 Routing

 

 

위 그림은 앞으로(오늘과 내일) 설명드릴 망 구성도이므로 잘 봐 주시기 바랍니다. (특히 서버/라우터의 MAC, IP 주소, 스위치/라우터의 포트(인터페이스) 번호)

 

좌측 그림과 같이 Sender(SVR1)와 Receiver(SVR2)가 동일 네트워크(LAN)에 위치해 있는 경우 라우터 R1을 거치지 않고 스위치 S1을 통해 바로 통신이 되며 이 때의 패킷 구성은 다음과 같습니다. (동일 네트워크인지 아닌지 어떻게 구분하는지 궁금하시면 여기를 클릭)

 Header  Fields     

 Ethernet Header

 

 * Destination MAC = Receiver(SVR2)의 MAC 주소 m2
 * Source MAC = Sender(SVR1)의 MAC 주소 m1

 IP Header

 

 * Destination IP = Receiver(SVR2)의 IP 주소 1.1.1.20
 * Source IP = Sender(SVR1)의 IP 주소 1.1.1.10

 

반면 우측 그림과 같이 Sender(SVR1)와 Receiver(SVR3)가 동일 네트워크(LAN)에 위치하지 않은 경우 라우터 R1을 거치게 되는데 이 때의 Ethernet Header 필드는 라우터를 사이에 두고 서로 값을 가지게 됩니다.

 

SVR1에서 R1으로 패킷 전송시

 Header  Fields     

 Ethernet Header

 

 * Destination MAC = Router(R1의 ge1/1)의 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

 

R1에서 SVR3로 패킷 전송시

 Header  Fields     

 Ethernet Header

 

 * Destination MAC = Receiver(SVR3)의 MAC 주소 m3
 * Source MAC = Router(R1의 ge2/1)의 MAC 주소 a2

 IP Header

 

 * Destination IP = Receiver(SVR3)의 IP 주소 2.1.1.30
 * Source IP = Sender(SVR1)의 IP 주소 1.1.1.10

 

 

Ethernet Switching

 

 

그림을 그리다 보니 너무 길쭉해 졌습니다. (다음 시간 그림은 더 길어요~)

 

1. SVR1 sends ARP Request

  • IP 주소 1.1.1.10을 가진 SVR1이 목적지 주소 1.1.1.20인 SVR2로 패킷을 전송하려 합니다.
  • 서버든 라우터든 패킷을 보내기 위해서는 일단 Routing Table을 참조합니다. Routing Table Lookup 결과 목적지 주소는 나(SVR1)와 동일 네트워크에 존재하고(라우팅 엔트리 1.1.1.0/24에 Gateway가 없음이 나와 동일 네트워크임을 나타냄), 출력 포트(OIF: Outgoing Interface)는 lan1입니다(그림에서 서버의 포트는 하나만 그렸으므로 다 lan1이죠).
  • 이제 SVR1은 목적지 주소 1.1.1.20에 대한 MAC 주소를 알기 위해 자신의 ARP Table을 참조합니다. 그런데 테이블이 비어 있습니다. (해당 엔트리가 없으면 ARP Miss라 부름)
  • 따라서 SVR1은 SVR2(1.1.1.20)의 MAC 주소를 알아내기 위해 lan1 포트로 ARP Request를 보냅니다. ARP Request 패킷은 아래와 같이 구성됩니다. 
   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), 즉 SVR2의 IP 주소 1.1.1.20
  • 이제 이 패킷은 S1(스위치 1)이 수신하고, 수신 패킷(스위치는 수신 패킷이 IP 패킷인지 ARP 패킷인지 관심 없음)의 Source MAC 주소를 배웁니다. 따라서 S1의 MAC Table에는 {MAC 주소 m1은 fe1 포트에 연결되어 있음}이 기록됩니다.
  • Source MAC Learning 직후 S1은 수신 패킷의 Destination MAC 주소를 봅니다. 브로드캐스팅 주소네요. 따라서 S1은 수신 포트를 제외한 나머지 모든 포트로(VLAN 설정이 있다면 동일 VLAN에 속한 모든 포트로) Flooding 합니다. 그래서 이 ARP Request 패킷은 SVR2와 라우터 R1이 수신을 합니다.
  • R1은 수신된 ARP Request 패킷의 Target IP 주소를 보고 이 주소가 내 것이 아님을 알고(R1이 소유한 주소는 1.1.1.1과 2.1.1.1) 버립니다.

 

2. SVR2 responds with ARP Reply

  • ARP Request를 수신한 SVR2도 Target IP 주소를 봅니다. 내 주소네요. 따라서 SVR2는 1.1.1.20에 대한 MAC 주소를 Sender MAC 필드에 담아 ARP Reply 패킷을  lan1 포트로 내보냅니다. ARP Reply 패킷은 아래와 같이 구성됩니다.
   Header      Fields         
 

 Ethernet Header  

 

 * Destination MAC = ARP Reply를 수신할 SVR1의 MAC 주소 m1
 * Source MAC = Sender(SVR2)의 MAC 주소 m2
 

 ARP Header   

 

 

 

 * Sender MAC = ARP Reply 패킷 송신자(sender), 즉 SVR2의 MAC 주소 m2
 * Sender IP = ARP Reply 패킷 송신자(sender), 즉 SVR2의 IP 주소 1.1.1.20
 * Target MAC = ARP Reply 패킷 수신자(target), 즉 SVR1의 MAC 주소 m1
 * Target IP = ARP Reply 패킷 수신자(target), 즉 SVR1의 IP 주소 1.1.1.10
  • 이 패킷을 수신한 S1은 Source MAC Learning을 하여 MAC Table에 {MAC 주소 m2는 fe2 포트에 연결되어 있음}를 기록하고,
  • 수신 패킷의 Destination MAC 주소 m1에 대해 MAC Table을 참조하여 fe1 포트로 패킷을 전달(유니캐스팅)합니다.
  • 그리고 이를 수신한 SVR1은 자신의 ARP Table에 그 값(1.1.1.20의 MAC 주소 m2)을 기록합니다.

 

3. SVR1 sends IP Packet to SVR2

  • 이제 SVR1은 SVR2로 IP 패킷을 보낼 준비가 되었습니다. 따라서 SVR1은 아래와 같은 구성의 IP 패킷을 lan1 포트로 내보냅니다.
   Header      Fields         
 

 Ethernet Header  

 

 * Destination MAC = Receiver(SVR2)의 MAC 주소 m2
 * Source MAC = Sender(SVR1)의 MAC 주소 m1
 

 IP Header   

 

 * Destination IP = Receiver(SVR2)의 IP 주소 1.1.1.20
 * Source IP = Sender(SVR1)의 IP 주소 1.1.1.10
  • 이 패킷을 수신한 S1(스위치 1)은 Source MAC Learning을 하려 봤더니 Source MAC 주소 m1은 이미 배운 MAC 입니다. 따라서 MAC Learning은 필요 없구요. Destination MAC 주소 m2를 MAC Table에서 찾아 보았더니 fe2 포트로 내보내면 된다고 적혀 있습니다.
  • 따라서 이 패킷은 fe2 포트를 통해 나가고, SVR2가 수신 합니다.

 

나그네 2012-06-01 13:50:09
좋은내용 감사합니다.
이진구 2012-06-04 09:44:44
항상 좋은내용 감사합니다.
손재홍 2012-07-02 00:27:48
패킷흐름에 관한 자료검색하다 오늘 처음으로 이 사이트를 알게 되었습니다.

한가지 질문이 있는데요, SVR2의 ARP Table에서 SVR1의 lan1의 MAC주소 생성 시점은 언제 인가요? 3번의 SVR2가 SVR1의 ARP Request을 수신한 후, 즉 SVR1에 ARP Reply송신전 인가요?

감사합니다!
넷매니아즈 2012-07-02 11:31:52
안녕하세요? 손재홍님.

SVR2의 ARP Table에 SVR1의 MAC 주소가 생성되는 시점은 본 블로그 설명 이후에 발생합니다.

SVR1에서 SVR2로 Ping Request(ICMP Echo Request)을 보내고, 그 응답으로 SVR2에서 SVR1으로 Ping Reply(ICMP Echo Reply)를 보내는 시나리오를 가지고 설명 드리겠습니다.

■ SVR1(1.1.1.10)에서 Ping 1.1.1.20 수행 (본 블로그 설명 내용)
1. SVR1은 1.1.1.20에 대한 MAC이 없으므로(ARP entry miss), ARP Request를 Broadcasting함
2. 이를 수신한 SVR2는 ARP Reply로 응답
- SVR1이 보낸 ARP Request 패킷에 의해 SVR2가 SVR1의 MAC 주소를 배우지는 않습니다!
3. ARP Reply를 수신한 SVR1은 SVR2의 MAC을 배움 (ARP entry fill)
4. 이제 SVR1에서 SVR2로 Ping Request 전송되고 SVR2가 수신

■ SVR2(1.1.1.20)에서 SVR1으로 Ping 응답 (본 블로그에 설명되지 않은 내용)
5. SVR2가 1.1.1.10으로 Ping Reply를 보내려 하는데, SVR2는 1.1.1.10에 대한 MAC이 없음 (ARP entry miss)
6. 따라서 SVR2는 ARP Request를 Broadcasting 함
7. 이를 수신한 SVR1은 ARP Reply로 응답
8. ARP Reply를 수신한 SVR2는 SVR1의 MAC을 배움 (ARP entry fill)
- 이 시점에 SVR2는 SVR1의 MAC 주소를 배움!!!!
9. 이제 SVR2에서 SVR1으로 Ping Reply 전송

정리하면, ARP entry(IP 주소에 대한 MAC 주소 정보)는 ARP Reply를 수신하면서 생성됩니다.
손재홍 2012-07-02 14:46:12
우선은 상세하고 친절한 답변 감사드립니다.

그렇다면, SVR2에서 SVR1으로 ARP Reply를 송신시에는 어디의 ARP Table을 참조하게 되나요?

아래의 MS페이지에서는 ARP Request 수신후 ARP Table에 ARP를 생성 후 ARP Reply를 송신한다고 나와 있는데 조금 어렵네요.

http://technet.microsoft.com/ko-kr/library/cc758357(v=ws.10)
넷매니아즈 2012-07-02 15:33:36
이렇게 정리해 보겠습니다.

1. ARP Request/Reply는 "상대방(IP)의 MAC 주소를 알아 오는 프로토콜로, ARP Request/Reply 전송시에 ARP Table은 참조하지 않습니다. 왜냐면 자신의 IP와 MAC 주소는 ARP Table에 포함되어 있지 않거든요.
2. MS 페이지 내용을 보고 혹시나 해서 시험을 해 보았는데요 (Windows XP와 7으로 각각 시험)
MS Windows의 경우, ARP Request 패킷에 포함된 "Sender의 IP와 MAC 주소"를 가지고 ARP Learning을 바로 하네요. (좋은 정보 주셔서 감사합니다.)

즉, 위 설명을 다음과 같이 수정해야 겠습니다. (아래 3번 내용 참조)
■ SVR1(1.1.1.10)에서 Ping 1.1.1.20 수행
1. SVR1은 1.1.1.20에 대한 MAC이 없으므로(ARP entry miss), ARP Request를 Broadcasting함
2. 이를 수신한 SVR2는 ARP Reply로 응답
3. 또한 ARP Request를 수신한 SVR2는 이 패킷에 포함된 Sender(SVR1)의 IP와 MAC을 배워 ARP entry에 추가 (ARP entry fill: IP=1.1.1.10 is at "m1")
4. ARP Reply를 수신한 SVR1은 SVR2의 MAC을 배움 (ARP entry fill: IP=1.1.1.20 at "m2")
5. 이제 SVR1에서 SVR2로 Ping Request 전송되고 SVR2가 수신

■ SVR2(1.1.1.20)에서 SVR1으로 Ping 응답
5. SVR2가 1.1.1.10으로 Ping Reply를 보내려 하는데, SVR2는 1.1.1.10에 대한 MAC이 있음 (위에 2/3번 과정)
6. 따라서 ARP Request 전송 절차 없이, SVR2는 SVR1으로 Ping Reply 전송

그런데요.
이와 같이 단말(Receiver)이 ARP Request 패킷 기반으로 Sender의 MAC과 IP를 자신의 ARP cache에 넣는지는 OS 의존적인 사항 같습니다. (자신은 없지만요...)
그래서 Linux에서도 이와 같이 동작하는지는 확인이 좀 필요할 것 같네요. (손재홍님. 혹시 Linux 동작도 확인이 되시면 공유 부탁드릴께요~) ^^
손재홍 2012-07-02 23:25:05
홈페이지의 깊이있고 좋은 내용에 한번 감동하고 질문에 대한 답변에 다시 한번 감동했습니다.
내용 정리 감사합니다, 리눅스에서의 동작확인 되면 공유하도록 하겠습니다.
넷매니아즈 2012-07-03 11:31:02
손재홍님, 좋은 말씀 감사합니다.

항상 감동드릴 수 있는 넷매니아즈가 되도록 노력하겠습니다! ^^*
북북노인 2012-09-24 10:43:59
잘 보구 갑니다
이홍기 2012-11-08 16:56:02
이사이트는 사막의 오아시스 같아여~
조치원 2013-07-11 18:10:37
안녕하세요.

ARP 동작에 대해 한 가지 문의 드립니다.
HOST A가 HOST B에 대한 mac 정보를 arp cache table에 가지고 있으며, HOST A가 arp cache를 5 분 마다 갱신 한다고 가정합니다.
HOST A 와 HOST B가 24 시간 내내 데이타를 주고 받을 때에도, host A는 host B로 5분 마다 arp request를 보내게 되는지요?
이러한 현상이 있어서 문의 드립니다.

감사합니다.
넷매니아즈 2013-07-11 22:44:58
질문의 답은 https://www.netmanias.com/bbs/view.php?id=qna&no=5182를 참고하시구요 (신성균님 답변 감사드립니다. ^^)

참고적으로 2가지 말씀드리면.
예전에 외산 장비를 가지고 시험을 해 본 적이 있는데 아래와 같은 특성을 가지고 있습니다.
[벤더 1] Aging time을 20분(1200초)로 설정시, ARP entry의 aging time 값은 +-300초를 랜덤하게 적용하여 최대 1500초에서 최소 900초 중에 aging out이 되도록 합니다. 이를 통해 ARP operation이 특정 시간에 몰리지 않도록 합니다. (even distribution)
[벤더 2] ARP aging time의 3/4에 이르면, ARP request를 보내고 reply가 수신되면 해당 엔트리의 aging out timer 값를 갱신하여 엔트리를 계속 가지고 있을 수 있도록 합니다. (만약 reply가 수신되지 않으면 4/4에 이르러서 aging out됨)
네트워크앞잡이 2014-11-27 00:20:49

동일 네트워크인지 아닌지 어떻게 구분하는지 궁금하시면 여기를 클릭

 

이 클릭이 작동을 안해 여쭤봅니다.

 

그 방식이 어떻게 되나요?

Netmanias 2014-11-27 02:50:22

아래 글(Subnet Mask와 Default Gateway)에 설명되어 있습니다.

https://www.netmanias.com/ko/?m=view&id=blog&no=5403

33 2015-02-28 02:51:29

안녕하세요

갈갈이30형제 2015-04-20 14:37:08

네트워크 공부하는 초보입니다.

너무나 상세하고 순차적인 설명에 이해가 빠르게 됬습니다. 너무 감사드립니다.

NETWORK는어려운데참쉽게설명하네요 2015-05-30 13:40:36

너무나 좋은 글에 감사합니다.

정말 대단히 많은 도움이 되었습니다.

감사합니다. NETMANIA.

이정훈 2015-06-11 11:01:20

감사합니다.! 많이 배우고 갑니다.!

질문있습니다. 2015-10-14 14:11:40

R1은 수신된 ARP Request 패킷의 Target IP 주소를 보고 이 주소가 내 것이 아님을 알고(R1이 소유한 주소는 1.1.1.1과 2.1.1.1) 버립니다. 라고 하셨는데, 만약 스위치에 단말이 여러 개 연결되어 있을 때, ARP Request 패킷을 폐기하기전에 ARP cache table에 기록을 안하나요.? 댓글에는 ARP Request 패킷만으로도 ARP learning을 한다고 하셨는데...

chofox78 2017-06-21 16:19:08

좋은 글 감사합니다.

주나 2018-03-27 15:49:15

안녕하세요

 

네트워크 공부 막 시작한 초보입니다 ㅜㅜ

데이터링크 계층에서 app message가 150bytes, H4,H3이 20bytes, H2가 16bytes, T2가 4 bytes라면 구성된

프레임 크기를 구하라고하면 저거 다 더하면 되는 건가요??

참고로 H4는

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
Related Contents
View All (973)
5G (68) AI (5) ALTO (1) AR (2) ARP (6) AT&T (1) Akamai (5) Authentication (5) BT (1) Backhaul (2) Big Data (2) Bridging (5) C-RAN/Fronthaul (17) CDN (20) CIoT (2) CPRI (6) Carrier Aggregation (5) Charging (2) China Mobile (2) Cisco (6) CoMP (3) Comcast (1) DHCP (6) DNS (15) Data Center (15) EDGE (11) EMM (1) EPS Bearer (7) Ethernet (3) FTTH (8) GSLB (5) Gigabit Internet (17) Google (17) Google Global Cache (8) Google TV (1) HLS (5) HTTP (5) HTTP Adaptive Streaming (7) HTTP Progressive Download (2) Handover (5) Huawei (1) IGMP (3) IP (6) IP Allocation (8) IP Routing (20) IPSec (4) IPTV (25) IoST (2) IoT (45) KT (45) Korea (8) Korea ICT Vendor (1) L3 Switch (5) LG U+ (24) LTE (99) LTE-A (10) LTE-A Pro (1) LTE-M (1) LTE-U (3) LoRa (5) MEC (11) MPLS (3) MWC 2013 (1) MWC 2015 (3) MWC 2016 (2) MWC 2017 (1) Mobile IPTV (1) Multi-Screen (1) Multicast (2) NAT (9) NB-IoT (6) NTT Docomo (1) Netflix (5) Network Protocol (49) Network Slicing (3) OSPF (3) OTT (20) Operator CDN (1) P2P (3) PS-LTE (3) Pooq (2) QoS (5) RCS (1) RRH (1) Request Routing (3) SD-WAN (8) SDN/NFV (34) SK Broadband (1) SK Telecom (38) Samsung (2) Security (8) Self-Driving (3) Shortest Path Tree (2) Small Cell (3) Spectrum Sharing (1) TAU (2) Transparent Caching (9) UHD (7) VLAN (2) VPN (3) VR (3) Video Streaming (22) VoLTE (1) VoWiFi (1) WAN Optimization (1) Wi-Fi (30) WiBro(WiMAX) (2) YouTube (16) eICIC (1) eMBMS (1) ePDG (6) u+ tv G (4) 로컬 5G (1)

 

 

     
         
     

 

     
     

넷매니아즈 회원 가입 하기

2019년 1월 현재 넷매니아즈 회원은 49,000+분입니다.

 

넷매니아즈 회원 가입을 하시면,

► 넷매니아즈 신규 컨텐츠 발행 소식 등의 정보를

   이메일 뉴스레터로 발송해드립니다.

► 넷매니아즈의 모든 컨텐츠를 pdf 파일로 다운로드

   받으실 수 있습니다. 

     
     

 

     
         
     

 

 

비밀번호 확인
코멘트 작성시 등록하신 비밀번호를 입력하여주세요.
비밀번호