| 리포트 | 기술문서 | 테크-블로그 | 원샷 갤러리 | 네트워크/통신 뉴스 | 기술자료실 | 자유게시판      한국 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
 
Private 5G | Edge 넷매니아즈 Private 5G 분석글 KT SK Telecom Verizon AT&T Vodafone DT Telefonica China Mobile Optage NEC Microsoft AWS    
HOT!!! Ericsson Nokia Mavenir Affirmed Metaswitch Athonet Altiostar Airspan Kyocera Apresia   일본 Local 5G 전개 현황
 
스폰서채널 |

주니퍼 네트웍스: 5G DX - E2E Network Slicing 

  스폰서채널 서비스란?
4편: L3 스위치의 IP 라우팅 과정
Part 4: L3 Switch IP Routing Process
June 21, 2012 | By 유창모 (cmyoo@netmanias.com)
코멘트 (21)
23

지난 시간에 이어 오늘은 L3 스위치의 IP 라우팅(IP forwarding) 과정에 대해서 설명을 드리도록 하겠습니다. 이번 과정이 가장 복잡합니다. 두 눈 크게 뜨시고~ ^^*

 

Network Topology

 

지난 시간과 동일한 구성입니다. 단지 패킷 흐름이 SVR1(1.1.1.10)에서 SVR4(2.1.1.30)으로 전달된다는 것만 다릅니다.

 

 

2. IP Routing
 
2.1 서버 SVR1에서 SVR4로 패킷 전달: (1) IP 패킷을 수신한 R1은 목적지 VLAN에 속한 포트들로 ARP Request를 Flooding
 

 

SVR1에서 목적지 2.1.1.30인 SVR4로 패킷을 전송하려 합니다.

SVR1의 Routing Table lookup 결과, 목적지 주소 2.1.1.30은 Default Route(0.0.0.0/0)에 매칭되어 Gateway 주소가 1.1.1.1(R1)이고 출력포트는 lan1입니다.

SVR1은 ARP Table lookup 결과, Gateway 주소 1.1.1.1의 MAC 주소는 a1임을 압니다. (설명을 간략화 하기 위해 SVR1의 ARP Table에 R1이 MAC 주소 a1이 있다고 가정함)

SVR1은 목적지 주소 2.1.1.30으로 패킷을 송신합니다. 패킷 구성은 아래와 같습니다.

     [Ethernet Header] Destination MAC 주소 = a1(R1의 MAC 주소), Source MAC 주소 = m1(SVR1의 MAC 주소)

     [IP Header] Destination IP 주소 = 2.1.1.30(SVR4의 IP 주소), Source IP 주소 = 1.1.1.10(SVR1의 IP 주소)

ge1/1 포트로 패킷을 수신한 R1의 Line Card #1은 이 패킷을 잠시 Ingress Packet Buffer에 저장합니다.

 

Source MAC Learning

 Line Card #1의 Packet Processor는 MAC Table을 참조하여 수신된 패킷의 Source MAC 주소 = m1이 자신의 Table에 등록되어 있는지 확인합니다. 이 경우 등록되어 있지 않습니다.

따라서 Packet Processor는 Control Module로 "VLAN = 10에 속한 Source MAC 주소 = m1은 Port = ge1/1에 연결되어 있어요"라는 Event를 전달합니다.

본 Event를 수신한 Control Module은 자신의 MAC Table에 그 값을 기록합니다(Source MAC Learning을 합니다).

 이제 Control Module은 learning한 MAC 정보를 Line Card에 전달해야 하는데, 이 때 모든 Line Card가 해당 MAC 정보를 필요로 하지는 않습니다. 동일 VLAN을 소유한 Line Card들만 그 정보를 공유하면 됩니다. 따라서 Control Module은 VLAN Table을 참조하여 VLAN 10에 속한 포트가 ge1/1, ge1/2, ge2/1이므로 VLAN 10을 소유한 Line Card가 #1과 #2임을 알게 됩니다. VLAN Table은 CLI를 통해 각 Port에 VLAN 값을 할당할 때 그 엔트리가 생성됩니다.

 Control Module은 MAC 정보(VLAN=10, Source MAC=m1, Port=ge1/1)를 Line Card #1, #2로 전달하여 MAC Table에  그 값을 저장하게 합니다(Source MAC learning을 하도록 합니다).

 

IP Routing or Ethernet Switching

이제 이 패킷을 IP routing 시킬 것인가(FIB lookup을 통해 패킷 전달), Ethernet switching 시킬 것인가(MAC Table lookup을 통해 패킷 전달)를 결정하기 위해 수신된 패킷의 Destination MAC 주소를 참조합니다. 

수신된 패킷의 Destination MAC 주소가 

  • L3 스위치 R1의 MAC 주소, 즉 a1이면 이 패킷은 IP routing 시키고,
  • L3 스위치 R1의 MAC 주소가 아니면 Ethernet switching 시킵니다.
이 경우 Destination MAC 주소가 a1이므로 R1은 이 패킷을 IP routing 시킵니다

 

IP Routing based on Destination IP address

Packet Processor가 Destination IP 주소 2.1.1.30에 대한 FIB lookup(LPM: Longest Prefix Match)을 수행하여 이 패킷은 R1과 바로 연결되어 있는 목적지이고, 출력 인터페이스는 VLAN 20인 것을 알게됩니다.

그런 후 ARP Table을 lookup하여 목적지 2.1.1.30에 대한 MAC 주소가 있는지 봅니다.

이론! ARP Table에 없습니다. 따라서 Packet Processor는 ARP Miss Event(2.1.1.30의 MAC 주소가 없어요~)를 Control Module로 전달합니다.

본 Event를 수신한 Control Module은 VLAN 20에 속한 Line Card들을 찾기 위해 VLAN Table을 참조합니다. 이 경우 Line Card #1과 #2가 VLAN 20에 속한 포트를 소유하고 있네요.

이제 Control Module은 Line Card #1과 #2로 ARP Request 패킷(Who has 2.1.1.30? Tell 2.1.1.1)을 보냅니다.

ARP Request 패킷을 수신한 Line Card #1, #2는 각자 자신의 VLAN Table을 참조하여 VLAN 20에 속한 포트를 찾습니다.

이제 ARP Request 패킷은 Line Card #1의 ge1/3 포트와 Line Card #2의 ge2/2, ge2/3 포트로 전송(Flooding)됩니다.

 

 

2.2 서버 SVR1에서 SVR4로 패킷 전달: (2) R1은 SVR4로 부터 ARP Reply를 수신

 

 

ARP Request 패킷을 수신한 SVR4, SVR5, SVR6 중에 2.1.1.30 주소를 소유한 SVR4가 그 응답으로 ARP Reply(2.1.1.30 is at m3)를 R1으로 보냅니다.

역시 수신 패킷은 Ingress Packet Buffer에 잠시 저장이 되구요.

 앞에서와 동일한 과정으로 Source MAC Learning을 수행합니다. 즉, VLAN = 20에 속한 Source MAC 주소 = m3는 Port = ge1/3에 연결되어 있음을 R1은 알게 됩니다.

 이제 수신 패킷의 Destination MAC 주소를 보았더니 a1 즉, 라우터 R1의 주소입니다. 따라서 Ethernet switching이 아닌 IP routing을 시켜야 함을 알게 됩니다.

 그런 후 그 패킷의 타입(Ethernet Header에 있는 EtherType)을 보았는데 ARP 패킷(EtherType = 0x0806)입니다. Destination MAC 주소가 라우터 MAC인 ARP 패킷은 라우팅 시키지 않고 무조건 Control Module로 올립니다.

ARP Reply를 수신한 Control Module은 자신의 ARP Table에 2.1.1.30에 대한 MAC 주소 m3를 저장하고,

ARP 패킷을 전달했던 Line Card #1으로 방금 배운 ARP 정보를 전달하여 Line Card #1의 ARP Table에도 그 정보가 저장될 수 있도록 합니다.

 

2.3 서버 SVR1에서 SVR4로 패킷 전달: (3) IP 라우팅(포워딩)
 

 

이제 R1은 목적지 2.1.1.30으로 패킷을 전달(라우팅) 할 준비가 끝났습니다.
SVR1이 목적지 주소 2.1.1.30인 패킷을 R1으로 보내면,
R1은 이 패킷을 Ingress Packet Buffer에 잠시 저장하고,
수신 패킷의 Source MAC 주소 = m1을 보았더니 이미 Learning 된 MAC이므로 Source MAC Learning 절차는 생략합니다.
이제 수신 패킷의 Destination MAC 주소 = a1을 보았다니 자신의 MAC 주소입니다. 즉, 라우팅 시켜야 할 패킷인거죠.
이제 수신 패킷의 Destination IP 주소 = 2.1.1.30으로 FIB lookup을 하였더니 OIF(Outgoing Interface)가 VLAN 20입니다.
 그리고 ARP Table lookup 결과 2.1.1.30에 MAC 주소가 m3임을 알게 되었습니다.
 마지막으로 ARP Table에서 찾은 m3로 MAC Table을 lookup 합니다. 이는 m3가 연결된 출력 포트를 알기 위함입니다. 이 경우 m3는 ge1/3에 연결되어 있다고 나오네요.
패킷을 전달하기 위해 Ingress Packet Buffer에 있던 패킷을 Egress Packet Buffer로 옮깁니다.
그리고 이 패킷은 ge1/3으로 전달됩니다.
 
 
Summary
 
총 4편에 걸쳐 라우터/L3 스위치의 패킷 전달 과정에 대해서 알아 보았습니다.
L3 스위치 동작의 핵심은 3가지로 정리해 볼 수 있는데요.
첫째, L3 스위치는 수신 패킷을 Ethernet Switching 시키든 IP Routing 시키든 상관없이 무조건 Source MAC Learning 부터 수행한다.
둘째, L3 스위치는 수신 패킷의 Destination MAC 주소가 L3 스위치의 MAC 주소이면 이 패킷을 IP Routing 시키고, 그렇지 않은 경우 Ethernet Switching 시킨다.
셋째, L3 스위치는 IP Routing 과정에서 RIB/FIB에 명시된 OIF(Outgoing Interface)가 물리적 포트가 아닌 VLAN ID 정보가 될 수 있으므로, 실제 패킷을 송신할 출력 포트를 결정하기 위해서는 MAC Table을 참조한다. 즉, 
    1) FIB lookup을 통해 Next Hop 주소(예: 20.1.1.1)와 OIF(예: VLAN = 30)를 알아내고
    2) ARP Table lookup을 통해 Next Hop 주소(20.1.1.1)에 대한 MAC 주소(예: c1)를 알아내고
      (만약 Next Hop이 없을 경우(L3 스위치와 바로 연결), Destination IP 주소(예: 100.1.1.1)에 대한 MAC 주소를 알아냄)
    3) MAC Table lookup을 통해 MAC 주소(c1)에 대한 물리적 포트(예: ge3/1)를 알아낸다.
      (이 물리적 포트는 OIF에 명시된 VLAN(30)에 속해 있는 포트임)
그리고 만약 IP Routing 과정에서 MAC Table에 해당 엔트리가 존재하지 않으면 VLAN Table을 참조하여, OIF(VLAN = 30)에 속한 모든 물리적 포트로 패킷을 Flooding 한다.
 
이재환 2012-06-25 09:44:29
일목요연하게 정리한 좋은 자료 감사합니다.
강석훈 2012-06-25 11:58:10
좋은 글입니다. 앞으로도 계속 좋은 글 부탁드립니다.
서우진 2012-07-17 00:31:00
국내 장비벤더사의 엔지니어입니다. 평소 이더넷관련 자료를 많이 찾아봤지만
국내자료 중 최고라고 평가하고 싶습니다. 감탄사가 절로 납니다.
넷매니아즈 2012-07-17 10:21:59
칭찬 감사해요. 앞으로도 더 열심히 하겠습니다! ^^*
열공이 2012-07-19 10:22:22
너무나 자세한 설명 감사합니다^^
잘 읽었습니다^^
유영욱 2012-08-14 13:11:02
질문있습니다.
물리적인 인터페이스 MAC이 있고, 해당 인터페이스가 속한 VLAN의 MAC이 있는데 동일 VLAN 내의 통신(Ethernet switching)에서는 인터페이스 MAC을 사용하고, 서로 다른 VLAN과의 통신(IP Routing)에서는 VLAN MAC이 사용되는건가요?
넷매니아즈 2012-08-14 15:21:06
동일 VLAN에 속한 두 단말간에 통신할 때는 L3 SW의 MAC 주소는 사용되지 않습니다.
예를 들어, Host A(1.1.1.10/24)의 MAC = A이고, Host B(1.1.1.20/24)의 MAC = B가 동일 VLAN = 100인 L3 SW에 연결되어 있다면,
Host A가 Host B로 전달하는 패킷의 행태는 아래와 같습니다.
- Destination MAC = B
- Source MAC = A
- Destination IP = 1.1.1.20
- Source IP = 1.1.1.10

즉, VLAN에 할당된 MAC은 라우팅시에만 사용이 된다고 보시면 됩니다.
유영욱 2012-08-14 19:18:12
답변 감사합니다. 제가 생각하고 있는게 맞는것 같네요. 두번째 질문이 있는데요.

스위치에 VLAN이 여러개 존재하는데 모든 VLAN의 MAC 주소가 동일합니다. 이건 왜 그런건가요?
넷매니아즈 2012-08-16 12:36:47
사실 단말간에 통신을 위해 L2 SW에 MAC 주소는 불필요합니다. (앞서 보여 드린 예처럼요)
하지만 다음 2가지 경우에 스위치 MAC이 필요한데요.

1. L2 SW 관리용
EMS(SNMP)나 Telnet을 이용하여 L2 SW에 login을 하는 경우, L2 SW에는 IP 주소와 MAC 주소가 필요하게 되구요. 하지만 이 경우 보통 VLAN에 상관없이 L2 SW에는 하나의 MAC 주소를 할당하는 것이 일반적입니다.

2. STP(Spanning Tree Protocol)용
아래 링크 21page를 보시면 STP에서 사용되는 BPDU에 대한 설명이 있는데요. 보통 이 경우도 하나의 MAC 주소만 사용하나 봅니다(저는 STP 전문이 아니라서 잘 모르지만요~)

https://www.netmanias.com/bbs/view.php?id=techdocs&no=9
후아 2014-12-13 20:48:00

정말 훌륭한 지식

잘 배우고 갑니다.

감사합니다!

박성호 2015-01-27 10:13:51

좋은 글 감사합니다.

질문 있습니다.

앞에서 설명해 주신 FIB/RIB TABLE가 장비에서 show ip route 했을 때 나오는 정보라고 생각하면 되는 건가요?

 

신현수 2015-01-30 12:31:47

Cisco Router 기준으로, 아래와 같이 생각하시면 될 듯 합니다.

show ip route: Control Plane에서 관리하는 RIB를 보여줌

show ip cef: Data Plane에서 관리하는 FIB를 보여줌

 

참조사이트: https://supportforums.cisco.com/discussion/11841016/rib-and-fib-tables

이희규 2016-12-15 20:22:12

좋은 내용 감사합니다^^

서동휘 2018-02-20 15:12:06

먼저 좋은글을 올려주셔서 감사합니다. 

 

제가 이해가 안되는 점이 하나가 있어서 글을 남깁니다.

 

  • L3 스위치 R1의 MAC 주소, 즉 a1이면 이 패킷은 IP routing 시키고,
  • L3 스위치 R1의 MAC 주소가 아니면 Ethernet switching 시킵니다.

이 부분에서 이해가 안되는게 R1의 Vlan 10번 mac a1 과 IP 1.1.1.1 ,  SVR1 의 IP 1.1.1.10 과 m1의 맥 SVR1과 R1 이 통신을한다고 가정하였을때 SVR1 송신패킷은 Source MAC= m1 | Destination MAC = a1      | Source IP 1.1.1.10 | Destination IP 1.1.1.10 인데 같은 서브넷임에도 불구하고 L3 Switch 는 목적지맥이 a1이므로 IP routing을 보고 응답을 주는건가요?

정재형 2018-02-20 17:58:53

질문이 잘 이해가 되지 않아서요. SVR1의 송신 패킷의 source IP (1.1.1.10)와 destination IP (1.1.1.10)가 같은 경우를 말씀하시는 건가요?

서동휘 2018-03-09 14:44:12

R1의 interface IP 1.1.1.1 ,  MAC a1 

pc의 IP 1.1.1.2 ,  MAC p1 

 

일 경우 pc에서 1.1.1.1 로 PIng 을 쳤을때 목적지 mac 은 a1으로 찍고가기때문에 같은 서브넷 통신이지만 R1이라는 장비만을 봤을때 IP routing을 하게되는건가요?

이승효 2018-03-13 07:03:21

라우터 입장에서 설명 드리면,

1) 수신 패킷의 destination MAC 주소가 자신의 MAC이 아니면 (a1이 아니면) bridging

2) 수신 패킷의 destination MAC 주소가 자신의 MAC이고 (a1이고) desintaion IP 주소가 자신이 아니면 (1.1.1.1이 아니면) routing

3) 수신 패킷의 destination MAC 주소가 자신의 MAC이고 (a1이고) desintaion IP 주소가 자신이면 (1.1.1.1이면) 자신이 응답해야 하는 패킷

 

 질문 주신 목적지 주소 1.1.1.1로 ping을 치며 이를 수신한 라우터는 본인 패킷이므로 라우터 자신(control plane)이 ping 응답을 합니다.

김대혁 2018-08-08 13:05:25

"2.2 서버 SVR1에서 SVR4로 패킷 전달: (2) R1은 SVR4로 부터 ARP Reply를 수신" 부분에서 몇가지 질문 드리겠습니다.

 

1. SVR4의 ARP Reply를 수행할 때 MAC 주소는 a1이 아니라 a2 아닌가 싶습니다

2. 만일 SVR4가 Line Card 2번일 경우(get2/x) 응답 받은 SVR4의 Mac 주소를 APR Miss 이벤트를 발생시킨 Packet Processor가 있는 ARP Table에 저장하나요? 아니면 응답 받은 Line Card 2번에 저장하나요?

유제석 2018-08-09 17:55:24

질문 하나 있습니다.

  • L3 스위치 R1의 MAC 주소, 즉 a1이면 이 패킷은 IP routing 시키고,
  • L3 스위치 R1의 MAC 주소가 아니면 Ethernet switching 시킵니다.

이 부분에서 추가적으로 ff-ff-ff-ff-ff-ff 인 브로드캐스트 맥주소도 IP routing 시키는게 맞지 않을까요?

임지훈 2018-08-13 15:17:18

라우터는 Destination MAC이 broadcast인 패킷은 IP 라우팅시키지 않습니다.

ahiram 2019-07-05 15:08:32
  • L3 스위치 R1의 MAC 주소, 즉 a1이면 이 패킷은 IP routing 시키고,
  • L3 스위치 R1의 MAC 주소가 아니면 Ethernet switching 시킵니다.

 

상기 내용이 이해가 잘 안가는데요 반대가 아닌가요?

 

L3 스위치에 직접 연결된 MAC이면 Ethernet switching 하고 멀리 떨어진 경우 IP Routing 해야 하는 것은 아닌가 하는 생각이 들어 말씀드립니다.

network 처음 배운지 1개월정도 되었습니다. 많은 지도 부탁드립니다.

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
View All (993)
5G (74) 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 (14) 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 (50) 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 (14) 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 (37) 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)

 

 

     
         
     

 

     
     

넷매니아즈 회원 가입 하기

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

 

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

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

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

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

   받으실 수 있습니다. 

     
     

 

     
         
     

 

 

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