| 리포트 | 기술문서 | 테크-블로그 | 원샷 갤러리 | 네트워크/통신 뉴스 | 기술자료실 | 자유게시판      한국 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 UPDATED

Fujitsu NEW Microsoft AWS    
  Ericsson Nokia Huawei Samsung Mavenir Affirmed Metaswitch Athonet Altiostar Airspan Kyocera Apresia   일본 Local 5G 전개 현황
 
스폰서채널 |

 

  스폰서채널 서비스란?
banner
banner
문제의 답: 왜 두 서버간에 통신이 되지 않을까요?
Answer: Ping problem between servers
January 20, 2012 | By 유창모 (cmyoo@netmanias.com)
banner
코멘트 (7)
11
 
어제 올린 문제 "왜 두 서버간에 통신이 되지 않을까요?"에 대한 답변 시간입니다.
 
문제의 원인
 
아래 그림을 보면서 설명 드리겠습니다.
 
[1] 먼저 Server 1의 IP 주소와 Subnet Mask를 보면 10.25.2.4/25입니다. 이를 IPSubnetter 프로그램을 통해 살펴 보면, 10.25.2.4/25와 동일 네트웍(동일 서브넷, 동일 LAN)에 있는 IP 주소 Range는 그림의 붉은색 박스와 같이 10.25.2.1 ~ 10.25.2.126입니다. 즉, 이 주소 대역의 Host와는 라우터(Default Gateway)를 거칠 필요 없이 바로 통신이 가능하다고 Server 1은 생각합니다.
[2] 이제 Server 1에서 ping 10.25.2.68을 합니다.
[3] Destination IP 주소인 10.25.2.68은 (1)에서 설명드린 Server 1과 같은 네트웍(10.25.2.1 ~ 10.25.2.126)에 속한 주소입니다. 따라서 Server 1은 이 목적지 주소가 자기와 동일 네트웍에 있다고 판단하고 이 목적지 주소로 바로 ARP Request를 보냅니다(브로드캐스트). ARP Reqeust를 하는 목적은 목적지 Host의 MAC 주소(이 경우는 Server 2의 MAC 주소)를 알아내기 위함입니다.
[4] 본 ARP Request(Target IP = 10.25.2.68)는 이제 Router로 도달하게 됩니다. 근데 Router가 받은 ARP Request의 Target 주소는 자신의 주소(10.25.2.1)가 아닌 다른 주소(10.25.2.68)인거죠. 이런 경우 즉, ARP Request의 Target 주소가 자신이 아닌 경우 라우터는 ARP Request 패킷을 무시합니다.
 
이와 같이 되면 Server 1은 ARP Request에 대한 응답을 받지 못하게 되고, 결국 Server 1은 Ping(정확히는 ICMP Echo Request 패킷이라 부르죠) 패킷을 내보내 보지도 못하게 됩니다.
 

그래서 두 서버간에 통신이 되지 않게 되는 겁니다 (물론  Server 2에서 Server 1으로의 Ping도 안됩니다.)

 

 

 

해결책

 

본 문제는 실제 말레이지아 Y사의 IMS 망 구축시에 있었던 이슈로 서버 담당자가 Subnet Mask를 잘못 설정하여 발생하였던 것입니다. 그럼 이제 정상적인 설정하에 두 서버간에 Ping 통신에 대해서 보여 드리도록 하겠습니다.

 

일단 두 서버의 Subnet Mask를 "/25"에서 "/26"으로 수정해야 합니다. 

[1] Server 1의 IP 설정 10.25.2.4/26을 IPSubnetter 프로그램을 통해 살펴 보면, Server 1과 동일 네트웍에 있는 IP 주소 Range는 10.25.2.1 ~ 10.25.2.62가 됩니다. (이제는 Server 1과 Server 2가 다른 네트웍으로 나누어 진거죠)

[2] Server 1에서 Ping 10.25.2.68을 합니다.

[3] Destination IP 주소 10.25.2.68은 Server 1과 다른 네트웍에 존재하는 Host입니다. (10.25.2.62까지가 Server 1과 동일 네트웍임) 따라서 Server 1은 목적지 주소인 10.25.2.68에 대한 ARP Request를 하지 않고, 자신에게 설정된 Default Gateway(그림에서는 보이지 않았으나 Server 1과 연결된 Router의 Interface 주소인 10.25.2.1로 설정되어 있다고 가정함)로 ARP Request를 보냅니다.

[4] ARP Request(Target IP=10.25.2.1)를 수신한 Router는 자신의 Interface 주소 10.25.2.1에 대한 MAC 주소를 실어서 ARP Reply 패킷을 Server 1으로 보냅니다.

[5] 이제 Server 1은 "10.25.2.68를 목적지로 하는 Ping" 패킷에 대한 Destination MAC 주소(여기서는 Router MAC)를 알았으므로 Ping 패킷을 Router로 보내게 됩니다. 그리고 이를 수신한 라우터는 자신의 라우팅 테이블을 참조하여 이 패킷을 Server 2로 전송하게 됩니다. (Router에서 Server 2로 Ping 패킷을 보내기 전에도 ARP operation이 있으나 생략)

 

 

유영욱 2012-07-05 19:17:57
잘 보았습니다. 근데 혹시 가운데 router에서 Proxy-ARP가 enable 되어있으면 server1에서 ARP-Request Broadcast 발생시 router에서 자신의 MAC으로 ARP-Reply 해주지 않나요?
넷매니아즈 2012-07-05 19:29:44
네, 맞습니다.
ARP Proxy가 enable되어 있으면 서버가 보내는 ARP Request내의 Target IP 주소에 상관없이 무조건 Router가 자신의 MAC으로 응답을 하므로 위 글과 같이 서버의 네트워크 설정이 잘못 되어 있어도 통신이 가능하겠네요.
싱가폴 2015-03-08 23:42:05

잘 보았습니다.

정하송 2016-04-11 17:44:06

잘 배웠습니다.

간서치 2018-07-24 15:08:06

우문이겠지만 라우터 오른편의 10.25.2.64/26 이라는 IP를 라우터에 설정할 수 있나요?
Network ID인데...

임성호 2018-07-25 14:21:05

예전부터 CIDR(Classless Inter-Domain Routing)라고 해서 subnet mask(/26)를 이용해서 network과 host ID를 구분하고 있습니다. 네이버에서 CIDR라고 하면 관련 글이 많이 나옵니다 (https://blog.naver.com/roopy0124/221315700008)

궁금해요 2018-07-26 00:37:58

26비트면 가용 ip가

1~62 / 0과63은 네트워크,브로드캐스트 주소

65~126 / 64와127은 네트워크, 브로드캐스트 주소

129~190 / 128과 191은 네트워크, 브로드캐스트 주소

193~254/ 192와 255는 네트워크, 브로드캐스트 주소

아닌가요?

한마디로 라우터에 네트워크 주소인 10.25.2.64/26은 사용 불가한거 아닌가 궁금해서 글올립니다

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
Related Contents
02/15/2012
Netmanias Blog
12/30/2011
Netmanias Blog
12/29/2011
Netmanias Blog
12/28/2011
Netmanias Blog
02/10/2010
Netmanias Technical Documents
11/12/2004
Netmanias Technical Documents
08/11/2003
Netmanias Technical Documents
View All (995)
5G (75) 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) Private 5G (1) 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 파일로 다운로드

   받으실 수 있습니다. 

     
     

 

     
         
     

 

 

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