안녕하세요? 오리뎅이입니다.

 

위 사진은 2014년에 터키 이스탄불에 출장을 갔을 때, 찍은 사진이에요. 터키 보다폰 통신 사업자 사무실에서 회의를 마치고, 저희 법원 사무실로 돌아가기 위해서 택시를 탔는데요. 택시 기사가 길을 헤매이다가 내려 놓은 곳이 바로 이 언덕 뒷편이었어요. 저희 법원 사무실은 사진 오른쪽 언덕 중간 즈음에 있거든요. ^^. 저는 이전에 사우디에 주재원으로 있을 때, 가족 여행으로 이곳에 와봤던 적이 있어서 택시가 피에르로티 언덕 뒷편 즈음에 와 있는 것을 알겠더라구요. 그래서 마침 같이 출장 갔었던 동료도 있고 해서 좀 둘러 봐야겠다는 심정으로 기사님께 거기에 그냥 내려 달라고 했어요. 느낌으로 언덕 정상만 넘어가면 나올것 같아서 느낌만 믿고 이 피에르로티 언덕 앞쪽으로 걸어 왔어요. 택시 기사님이 헤매신 덕분에 출장 중에 이 아름다운 피에르로티 언덕을 관광 하게 되었던 것이지요. 사진으로 봐도 넘 멋진 풍경이네요. 코로나로 집콕을 너무 오래동안 해서 그런지 정말 너무 너무 다시 가보고 싶으네요. ^^ 

Static Routing 프롤로그

Connected에 이은 두번째 오리뎅이의 라우팅 이야기 주제는 Static Routing입니다. Connected는 PC나 서버, 그리고, 라우터와 같은 IP를 사용하는 장비에서 인터페이스에 IP와 Subnet을 설정하면 라우팅 테이블에 자동으로 Connected 엔트리가 생성 됩니다. 같은 subnet에 있는 다른 장비들과의 통신은 별도로 다른 라우팅 설정을 하지 않더라도 라우팅 테이블에 생성된 Connected로 통신이 됩니다. Static Routing 프로토콜 또는 Dynamic Routing 프로토콜을 이용해서 라우팅 설정을 해야 하는 경우는 라우팅 장비를 통해서 다른 네트워크에 떨어져 있는 장비와 통신을 하고자 하는 경우에 필요합니다. Static Routing은 PC와 서버는 물론이고, 라우터, Firewall, L4-L7 switch 등에서 매우 광범위하게 사용되고 있습니다. Dynamic Routing 프로토콜 이야기를 시작하기에 앞서 Static Routing의 BoB(Basic of Basic)를 하나씩 하나씩 찬찬히 살펴 보겠습니다.

 

    - Linux, Windows 10, 라우터 각각에서 Static Route 설정 방법 

       . 기본 Static Route 설정 방법

       . 4가지 파라미터 사용 방법

       . 설정 영구(Permanent) 적용 방법

    - Redundancy

       . Static Route 장애 감지

       . Link Redundancy vs L2 Device Redundancy vs L3 Device Redundancy 

       . L2 Redundancy

         → Bonding/Teaming

         → LACP

       . FHRP : VRRP, HSRP

       . Floating Static Route

       . ECMP

    - 빠른 장애 감지 및 절체 - BFD

       . Static Route + ECMP + BFD

    - Default Route 설계

    - Router On a Stick

    - Control Plane vs Data(Forwarding) Plane : 평면이 대체 모라구?

       . L2 SW, L3 SW, Router, L4-L7 Switch, Firwall등 각 장비의 CPU는 어디에 있나?

 

해야 할 이야기들이 정말 많아 보이네요. 그래도 하나씩 하나씩 풀어 가다보면, 곧 끝이 보이겠지요. 시작이 반이라고 했으니, 이미 절반은 끝낸 샘입니다요. ^^

 

Static Routing 설정 방법 1, 2, 3

[오리뎅이의 라우팅 이야기 - 3] Connected - IP 네트워킹, 라우팅의 시작 - 3/3 편에서는 Windows 10, Linux, 그리고 Cisco 라우터에서 Static Route를 설정하는 아래의 3가지 설정 방법에 대해서 살짝 맛보기로 알아 보았었습니다.

 

  방안 1) Gateway(PC or 서버) 또는 nexthop(라우터) 만 설정하는 경우 (이후 [gateway|nexthop]로 표시)

  방안 2) Interface만 설정하는 경우

  방안 3) [gateway|nexthop]과 Interface 둘 모두 설정하는 경우

 

* PC 또는 server와 같은 End host 장비에서는 다른 네트워크와 통신하기 위해서 설정하는 라우팅 디바이스의 IP를
   gateway라고 부르고, router에서는 다른 routing 장비를 통해서 간접 전달을 해야 하는 경우, 설정해야 하는 다른
   라우팅 장비의 IP를 nexthop이라고 부릅니다.

 

각 방안을 사용하는 경우의 특징으로는 다음과 같은 것들이 있었습니다.

 

  방안 1)을 사용하는 경우는 recursive lookup이 발생한다. Interface down 되어도 엔트리가 삭제되지 않는다

  방안 2)를 사용하는 경우는 대상과 직접 통신을 시도한다. 모든 대상 IP로 직접 ARP resolution 시도한다

  방안 3)을 사용하는 경우는 Recursive lookup 발생하지 않고, Interface가 down 되면 엔트리가 자동으로 삭제되고, ARP resolution은 [gateway|nexhop] 1개에 대해서만 생성된다.  

 

방안 3)으로 하는 것이 가장 이상적인 방법이란 것을 딱봐도 쉽게 알 수 있습니다. 특별한 이유가 있어 방안 1)이나 방안 2)를 사용 해야하는 경우가 아니라면, 방안 3) 으로 설정하는 것이 좋습니다.

 

* 방안 1)을 사용해야만 하는 특별한 이유 : 장비가 2가지 모두 설정하는 것을 지원하지 않는데, 방안 2)를 사용할 경우, 너무 많은 ARP table 엔트리가 생성될 수 있는 상황인 경우
* 방안 2)를 사용해야만 하는 특별한 이유 : 서로 다른 subnet 대역에 있는 peer간 통신이 되도록 해야 하는 경우

 

Static Routing의 시작은 - PC or 서버

그림1에는 점선 타원으로 표시한 5개의 서로 다른 LAN(Local Area Network)이 있습니다. 좌측에 있는 PC0과 PC1은 SW0를 통해서 R0에 연결되어 하나의 LAN을 구성합니다. 오른쪽의 Server0과 Server1도 SW1을 통해서 R2에 연결되어 또 다른 하나의 LAN을 구성합니다. 라우터와 라우터 사이는 직접 direct로 연결 되더라도 독립적인 하나의 LAN입니다.  PC와 서버는 서로 다른 네트워크에 있기 때문에 직접 통신이 불가능하고, 라우터를 통해서 간접 통신만 가능합니다. Static Routing 설정을 통해서 PC와 서버가 서로 통신이 되도록  해 보겠습니다.

 

PC와 서버가 서로 통신을 하기 위해서는 PC에서 서버로 가는 길(route), 서버에서 PC로 돌아 오는 길(route)의 양방향 route가 모든 라우팅 홉에 설정이 되어야 합니다. 라우팅 설정의 시작은 양쪽 end host인 PC와 서버에서 시작됩니다. 네트워크를 처음 배우는 분들은 패킷 트레이서나 GNS3와 같은 시뮬레이터로 실습을 할 때, 종종 PC나 서버의 라우팅 설정을 하지 않는 경우가 있습니다. 좀 더 심한 경우는 라우팅 테이블은 라우터에만 있다고 생각하는 경우도 있습니다. 이는 아마도 집이나 회사의 PC를 사용할 때에 라우팅 테이블 설정을 별도로 할 일이 없기때문에 PC에는 라우팅 테이블이 없다고 생각하게 되었을 수도 있을 것 같습니다.  PC에도 라우팅 테이블 있습니다. ^^

 

Windows 10 Static Routing 설정

Windows 10 PC에서의 Static Route 설정은 아래 참조1과 같이 4가지 파라미터들이 사용될 수 있습니다. MASK 까지 별도로 한다면 파라미터가 5가지 이지만, 의미상 Destination과 Mask(또는 Prefix)가 함께 목적지 네트워크를 나타내므로 하나의 파라미터라고 간주하고 이야기 하겠습니다. 

 

Windows 10 Static Route 설정    route add 10.10.13.0 MASK 255.255.255.0  10.10.10.1 METRIC 3 IF 2              destination^                           ^gateway    metric^    ^interface route -p add10.10.13.0/24 10.10.10.1 METRIC 3 IF 2    // -p (permanent) 옵션 : 재시동 되더라도 테이블 유지

참조1. Windows 10 Static Routing 설정 예

 

Destination은 MASK (또는 Prefix)와 함께 목적지 네트워크를 나타냅니다. MASK 대신에 10.10.13.0/24 와 같이 Prefix를 이용해서 목적지 네트워크를 나타낼 수도 있습니다.  Destination은 Static Routing 설정에 필수 파라미터입니다. Metric와 Interface는 필수 파라미터가 아닙니다. 생략할 수 있습니다. 

 

 

Gateway 없이 Interface만 이용해서 설정하는 방법은 Linux와 라우터에서는 가능하지만, Windows 10에서는 설정 방법이 다릅니다. Gateway를 생략하는 대신에 0.0.0.0 으로 설정하거나 Local IP로 설정을 합니다.  특별한 경우가 아니라면면, Gateway와 Interface 둘 모두를 설정하는 것이 좋습니다.  Windows 10에서 IF 2, IF 9 와 같이 IF 옆의 숫자는 Interface를 나타내는 Index 번호입니다. Interface Index 번호는 windows cmd 창에서 route print 명령을 입력했을 때, 가장 윗부분에 아래 참조2와 같이 이더넷 어답터 별로 가장 앞에 Index 번호가 출력됩니다.

 

참조2. Windows 10 라우팅 테이블의 IF 번호

 

Windows 10에서 Static Route의 Metric은 자동 매트릭 기능으로 Interface별로 Bandwidth에 따라서 자동으로 할당 되는 Interface Metric과 Routing Metric의 합계 값이 route print 명령의 결과로  routing table 출력에 매트릭 필드에 표시 됩니다.  Interface 별 자동 매트릭 기능은 Interface의 Bandwidth 별로 다음의 그림3과 같이 기본 값이 정해져 있습니다. 

 

그림3 출처 : https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/automatic-metric-for-ipv4-routes

 

 

그림3에서 Link Speed는 Tx/Rx Speed를 합산한 값입니다. 따라서 1G Ethenret Interface인 경우 Greater than or equal to 2GB에 해당되어 Meric이 25입니다. Static Routing 설정에 대한 Routing Metric은 값을 지정하지 않으면 기본값이 1입니다. 따라서 기본값을 주지 않고,  1G Ethernet Interface에 static route를 추가한 경우는 참조 3과 같이 Interface Metric 25와 Routing Metic 1을 합산한 값 26이 매트릭으로 표시 됩니다. 

 

참조3. Windows 10 매트릭 = Interface Meric + Routing Metric 

 

Windows 10 cmd 창에서 PowerShell을 실행하고, get-netroute 명령을 이용하면, 아래 그림4와 같이 RouteMetric과 ifMetric이 각각 구분되어 표시되는 것을 확인할 수 있습니다. 

 

 

PC가 재시동 되더라도 Static Routing으로 추가한 엔트리가 유지되도록 하려면 참조1의 아래 부분 예와 같이 -p 옵션을 사용하면 됩니다. 

 

 

Linux 서버 Static Routing 설정

Linux는 Ubuntu, Debian, Centos, Fedora, RHEL 등 많이 버전들이 있습니다. 어느 버전에서나 "ip route add" 명령과 "route add" 명령을 모두 사용해서 Static Route 설정을 할 수 있습니다. 모든 최신 리눅스 배포판에서는 "ip route add" 명령을 사용할 것을 권고합니다.

 

Linux Static Route 설정 예) ip route add 10.10.10.0/24 via 10.10.13.1 dev eth0  metric 1                       destination^      ^gateway          ^interface ^metric 예) route add 10.10.10.0/24 gw 10.10.13.1 dev eth0 metric 1

참조4. Linux Static Route 설정 예

 

Windows 10에서와 마찬가지로 Destination은 Static Routing 설정에 필수 파라미터입니다.  gateway와 interface는 둘중에 하나만 사용할 수 있습니다. 둘 다 생략할 수는 없습니다. 

 

 

Linux의 경우에도 특별한 경우가 아니라면, Gateway와 Interface 둘 모두를 설정하는 것이 좋습니다. Gateway만 설정하고 Interface를 설정하지 않으면, recursive lookup을 통해서 적절한 Interface를 찾습니다. 반대로 Interface만 설정하고, Gateway를 설정하지 않는 경우는 모든 목적지 IP에 대해서 직접 통신이 가능한 것으로 판단하고 직접 ARP Resolution을 시도할 것입니다. 같은 LAN에 목적지 장비가 있을 경우에는 통신에 문제가 없지만, 다른 network에 존재하는 목적지인 경우에는 라우터에 Proxy ARP 기능이 Enable 되어 있는 경우에만 라우터 인터페이스의 MAC address로 ARP Resolution이 됩니다. 목적지가 많아지면, ARP table entry가 늘어나서 ARP table lookup에 시간이 오래 소요되거나 table이 부족한 상황이 초래될 수도 있습니다. 그러니, 특별한 사유가 없는 한 Gateway와 Interface 둘 모두를 설정하는 것이 좋습니다.

 

Static Route 설정 시 Metric을 설정하지 않으면, 기본 값으로 1로 설정됩니다. Windows 10과는 달리 Interface Metric과 Route Metric이 별도로 있지 않고 그냥 Metric 만 있습니다.  동일 네트워크에 대해서 Metric이 낮은 엔트리가 우선하므로 Metric이 0인 Connected가 우선 순위가 가장 높고, Metric이 1인 Static Routing은 그 다음으로 우선 순위가 높습니다.  

 

Comand Line Interface 명령어로 추가한 Route 엔트리(Entry)는 서버가 재시동 되면 사라집니다. Static Route  설정을 서버가 재시동 되어도 라우팅 테이블에 그대로 유지되도록 하는 것은 각 Linux 배포판 별로 조금씩 상이합니다.

Ubuntu는 Version 17.10 부터는 /etc/netplan/ 디렉토리에 있는  yaml 화일에 static route를 아래 참조 4와 같이 추가합니다. Interface별로 default gateway는 gateway4: 에 gateway IP를 적고, static route의 경우는 routes: 에 to: Destination/Prefix, via: Gateway IP, metric: metric value  를 적습니다. metric은 생략할 수 있습니다. 생략할 경우 default value로 0 이 설정됩니다.

 

참조5. Ubuntu /etc/netplan/01-netcfg.yaml 화일에 static route를 추가

 

참조4와 같이 파일에 추가 한 후에 "sudo netplan ap+ply" 명령으로 적용합니다. 적용이 잘 되었는지 "ip route show" 또는 "route -rn" 명령으로 확인합니다. 적용이 잘 되었다면, 어떠한 이유로 서버가 재시동 되더라도 추가된 Route 엔트리는 계속 유지 됩니다.

 

RHEL 및 Centos 7.x 버전에서는 /etc/sysconfig/network-scripts/ 디렉토리에 있는 interface별 화일에 default gateway 및 static route를 추가합니다. Interface eno0에 default route와 static route 를 설정하는 경우는 참조5와 같이  ifcfg-eno0 화일에 설정 합니다.

 

참조6. RHEL 및 Centos 7.x 버전에서 static route를 영구 설정하는 방법

 

Default route를 영구 저장하기 위해서 참조4(Ubuntu - gateway4)나 참조5(RHEL - DEFROUT)와 같이 설정을 하는데요. Linux 시스템이 multiple interface를 가지는 경우, default gateway를 모든 interface에 copy 해서 적용하는 경우가 종종 있습니다. 그럴 경우 의도치 않은 인터페이스로 패킷이 라우팅 되어 인터넷 접속이 안되거나 원하는 목적지로 패킷이 라우팅 되지 않아 접속이 안되는 사태가 벌어집니다. ECMP (Equal cost Multiple Path)를 적용하기 위해서 복수의 Interface에 default gateway를 설정하는 경우가 아니라면 default gateway는 1개의 interface에만 추가해야 합니다.  Redudnancy 및 link 용량 증설을 위해서 ECMP를 사용하는 방법에 대해서는 추후 글에서 자세히 알아 보겠습니다.

Router의 Static Route 설정 방법

PC나 서버 같은 end host 장비에서 다른 네트워크로 보내기 위해서 패킷을 전달해야 할 라우팅 장비의 IP를 gateway라고 부릅니다. 반면에 라우팅 장비에서는 목적지로 보내기 위해서 패킷을 내 보내야 할 다른 라우팅 장비의 IP를 nexthop이라고 부릅니다. Host 장비(PC or 서버 등), 라우팅 장비 불문하고, 자기 자신의 인터페이스에 직접 연결된 상대방으로 보내는 경우는 Connected로 보내면 되기 때문에 라우팅 테이블에 gateway나 nexthop이 필요하지 않습니다. 오직 자기 자신의 Interface에 속하지 않은 network로 패킷을 간접 전달해야 하는 경우에 gateway 또는 nexthop이 필요합니다.

 

 

 

Static Routing 설정 명령어와 방법은 각 네트워크 장비 벤더별로 조금씩 다릅니다. 

 

Cisco Router에서는 static route 설정 시 interface와 nexthop 둘 중에 하나만 사용하거나 둘 모두를 사용할 수 있습니다. Linux 경우와 마찬가지로 interface만을 사용할 경우에는 모든 목적지에 프레임을 직접 전달할 하기 위해서 ARP resolution을 시도합니다. 반면에 nexthop만을 사용할 경우에는 출구 interface를 찾기 위해서  라우팅 테이블 recursive lookup이 발생 합니다. 

 

특별한 사유가 없는 한 interface와 nexthop 둘 모두를 사용하는 것이 좋습니다. 

 

Cisco Router Static Route 설정 예) ip route 10.10.13.0 255.255.255.0 10.10.11.2  25                 // Old IOS 방식은 nexthop 또는 interface 중 1개만 가능         destination^               nexthop^           ^AD     ip route 10.10.13.0 255.255.255.0 Gi0/1  25                        // Old IOS 방식은 nexthop 또는 interface 중 1개만 가능         destination^             interface^      ^AD                                ip route 10.10.13.0 255.255.255.0 Gi0/1 10.10.11.2 25          // New IOS 방식은 nexthop, interface 동시 사용 가능           destination^             interface^  nexthop^     ^AD

참조 7. Cisco Router Static Route 설정 예

 

PC와 Linux에서는 Gateway와 Interface 이외에 Metric 값을 옵션으로 설정할 수 있었습니다. 그런데, Cisco Router에서는 Metric 값은 설정할 수 없습니다. Static Route의 Metric 값이 설정은 안되지만, 라우팅 테이블 출력 시에는 그림7과 같이 Metric 값이 0으로 표시는 됩니다.

 

그러나 Cisco 장비에서 Static Route의 Metric 0은 의미가 없는 dummy 값입니다. Metric 값은 설정할 수 없지만, Cisco Router에서는 옵션으로 AD(Administrative Distance) 값을 설정할 수 있습니다. AD 값은 라우팅 프로토콜들 별로 우선 순위에 차등을 주는 값입니다. Cisco에서는 AD라고 부르고, 주니퍼에서는 Preference라고 부릅니다. 프로토콜 별로 기본값들도 다릅니다. 어떤 값들을 사용하는지는 구글에서 찾아 보면 그림 8과 같은 잘 정리해 놓은 그림들이 뚝딱 나옵니다. ^^

 

 

그림8 출처 : https://www.routexp.com/2020/03/check-out-value-administrative-distance.html

 

 

Cisco만 AD라고 부르고 나머지 벤더에서는 Preference 라고 부르는 군요. Cisco, Juniper, HP는 모두 Static Route의 우선 순위가 Connected 다음으로 높은 우선 순위를 보여 주고 있는데요. Huawei 는 특이하군요. Huawei는 안쓸거니까 그러거나 말거나 패쑤!! ^^

 

 

주니퍼 라우터의 Static Route 설정은 시스코와 다른 점이 몇가지 보입니다. 우선 위의 그림8과 같이 Preference라는 값으로 각 프로토콜들이 생성한 route의 우선 순위를 부여합니다. 그리고 동일 프로토콜이 생성한 route에 대해서 주니퍼 라우터에서는 metric 값으로 우선 순위를 부여할 수 있습니다.

 

Juniper Router Static Route 설정 예)  set routing-options static route 10.10.13.0/24 next-hop 10.10.11.2  preference 30 metric 15            // nexthop                                              destination^            nexthop^          prefernece^   metric^                                 set routing-options static route 10.10.13.0/24 next-hop Gi0/1                      //  interface 가능                                            destination^          interface^

참조8. Juniper Router Static Route 설정 예

 

주니퍼 라우터에서는 next-hop 뒤에 기본적으로  nexthop IP만 사용합니다. 그리고 기본적으로 nexthop IP는 directly connected IP만 사용합니다. 즉, 직접 연결된 라우터의 IP만 nexthop IP로 사용할 수 있습니다. 지금까지 설명으로 사용한 예에서 nexthop은 모두 direct conencted 인 IP만 사용했었는데요. 밑에서 자세히 설명 드릴 내용이지만 nexthop IP를 direct connected IP가 아닌 원격의 라우터 인터페이스 IP를 사용할 수도 있습니다.  주니퍼 라우터에서는 이렇게 direct connected IP를 nexthop으로 사용하는 경우에는 별도로 interface를 옵션으로 추가해 주지 않더라도 그림9와 같이 라우팅 테이블에 interface가 자동으로 추가되어 패킷 라우팅 시에 recursive lookup이 일어 나지 않습니다. 이것은 매우 바람직한 기능 같습니다.

 

 

PC, 서버, 시스코 라우터에서 Static Route 설정 시에 Interface만 줄 수 있었던 것처럼 주니퍼 라우터에서도 next-hop 뒤에 IP가 아닌 Interface를 줄 수 있습니다.  Interface만 주는 경우는 역시나 모든 목적지를 직접 연결된 것으로 간주하여 모든 IP에 대해서 직접 ARP Resolution을 시도합니다.

 

Cisco Route에서는 metric을 옵션으로 지정할 수 없었으나 주니퍼 라우터에서는 metric도 설정할 수 있습니다.  Metric을 생략할 경우 기본 값으로 그림8과 같이 5가 사용됩니다.

 

원격 [gateway|nexthop] 지정하기

앞에서 언급했던 바와 같이 지금까지의 Static Route 설정 예에서는 gateway 혹은 nexthop을 direct connected 상태인 인접 라우터의 interface IP를 사용했습니다. gateway|nexthop 으로 다른 네트워크에 있는 IP를 사용할 수 있습니다. 단, gateway|nexthop으로 사용 될 원격지 IP로 가기 위해서 어느 Interface를 통해서 나가야 하는지가 라우팅 테이블에 등록이 되어 있어야만 원격지 IP를 gateway|nexthop 으로 사용할 수 있습니다. 즉, Recursive lookup으로 원격지 nexthop IP로 연결되는 출구 interface를 찾을 수 있어야 합니다.

 

Windows 10 원격 gateway 지정하기 - 가능

 

참조9. Windows 10에서 원격지 IP를 Gateway로 설정하기

 

 

참조9를 보면 Windows 10에서 IP 10.10.12.2를 Gateway로 하여 Static Route 설정이 성공적으로 라우팅 테이블에 엔트리가 생성된 것을 볼 수 있습니다. 이는 recursive lookup에 의해서 10.10.12.2는 바로 위에 있는 default gateway를 통해서 도달 가능한 것이 확인 되기때문에 성공적으로 라우팅 엔트리가 추가 된 것입니다.

 

Linux 원격 gateway 지정하기 - 불가능(?)

Linux는 Static Route 설정 시 indrect nexthop IP를 Gateway로 허용하지 않는 것으로 보입니다. 지금까지 찾아 본 바로는 원격지 IP를 gateway로 주어서 설정을 성공시키지 못했습니다. 구글링으로도 방법을 찾지 못했습니다. 지원하지 않는다는 내용도 찾지를 못했기때문에 미확인입니다. 심적으로 판단하기에는 지원하지 않는 것 같습니다.

 

 

Cisco Router 원격 nexthop 지정하기

Cisco Router는 원격지 IP를 nexthop으로 설정하는 것이 가능합니다. Interface 없이 nexthop만 설정한 경우에 recursive lookup을 통해서 출구 interface를 찾는다고 했던것처럼 원격지 IP를 nexthop으로 설정한 경우에도 해당 원격지 IP에 도달 가능한 route가 라우팅 테이블에 있다면 정상적으로 recursive lookup으로 출구 interface를 찾아서 패킷을 forwarding 합니다.  만일 recursive lookup으로 출구 interface를 찾을 수 없는 경우에는 라우팅 테이블에 엔트리가 올라오지 않기 때문에 라우팅 lookup 실패로 패킷을 라우팅 하지 못하고 드롭합니다. 아래 그림13을 보면, 1에서 원격지 IP를 nexthop으로 static route 설정을 하지만, 2에서 확인 시 라우팅 테이블에 엔트리가 올라오지 않습니다. 3에서 1에서 설정한 nexthop IP에 대한 static route를 추가하니 4에서 원격지 IP를 nexthop으로 설정한 Static Routing 엔트리도 라우팅 테이블에 올라 온 것이 보입니다.

 

"Recursive lookup으로 출구 interface를 찾는다"는 의미는 원격지 IP를 nexthop으로 설정한 경우에도 Ethernet Frame은 직접 연결된 인접 라우터를 통해서 간접 전달이 되어야 하므로, directly connected 관계인 인접 라우터의 IP와 해당 네트워크 Interface가 recursive lookup에 의해서 검색되어야 한다는 의미입니다. 그림12의 R0 라우터에서 10.10.13.0/24 네트워크에 대한 nexthop을 직접 연결된 라우터 R1이 아니라, R1을 통해서 연결된 원격지 라우터 R2의 10.10.12.2를 nexthop으로 설정하는 경우에 recursive lookup에 의해서 10.10.12.2/24 네트워크에 대한 nexthop이 그림12의 4와 같이 직접 연결된 인접 라우터 R1의 10.10.11.2가 nexthop으로 검색 되어야 합니다.   

 

Juniper Router 원격 nexthop 지정하기 - resolve

Juniper Router에서도 원격지 IP를 nexthop으로 설정할 수 있습니다. Cisco Router나 Windows 10에서는 별도의 설정을 하지 않더라도 recursive lookup으로 라우팅 테이블에서 출구 interface를 찾습니다. 그리고, recursive lookup에 의해서 출구 interface가 찾아지면 패킷을 해당 출구 interface로 forwarding 하고, 출구 interface를 찾지 못하는 경우에는 패킷을 드롭 합니다.  Juniper Router는 이와는 다르게 원격지 IP를 nexthop IP로 설정하는 경우에는 resolve 옵션을 함께 사용해야지만, recursive lookup을 수행합니다.

 

 

그림14의 1번에서 Destination network 10.10.13.0/24 에 대한 next-hop IP를 원격지 IP인 10.10.12.2로 설정하고, 2번에서 10.10.12.0/24 network에 대한 static route까지 추가를 하더라도 라우팅 테이블에는 10.10.13.0/24에 대한 엔트리가 올라오지 않습니다. 4에서 10.10.13.0/24 에 대해 resolve 옵션을 추가로 설정하자마자 5번과 같이 10.10.13.0/24 network에 대한 엔트리가 라우팅 테이블에 생성되었습니다. Nexthop과 Interface가 recursive lookup을 통해서 인접 라우터의 nexthop IP인 10.10.11.2로 되어 있는 것을 볼 수 있습니다.

 

 

Windows 10, Linux, 라우터 등에서 Static Routing의 BoB에 대해서 알아 보았습니다. 오늘 알아본 BoB 내용을 바탕으로 다음 시간에는 Straic Routing의 장애 감지, Redudancy, High Availability, ECMP 등의 한 단계 차원 높은 주제들에 대해 알아 보겠습니다.

 

좀 이상하다 싶은 내용이 있으시면, 가차없이 태클을 날려 주세요. 오타를 보시면 콕콕 찝어 주세요. 추가적으로 궁금하신 내용이 있으시면 댓글에 질문을 달아 주세요. 태클과 질문을 통해서 쑥쑥 자라는 블로그가 되기를 희망해 봅니다.

 

2021년에 새로운 글로 찾아 뵙겠습니다. 구독해 주신 여러분!!! 새해 복 많이 받으세요!! 

 

2020년 12월 31일에 수원에서 뒤뚱뒤뚱 ~~~~ [오리]

안녕하세요? 오리뎅이입니다.

 

Connected 마지막 편입니다. 인터페이스에 IP와 subnet mask를 설정하면, 라우팅 테이블에 자동으로 Connected와 Local 엔트리가 생성되었었는데요. 이번에는 Static route 설정으로 connected를 알아 보겠습니다.

 

Static route로 만드는 Connected

Connected를 만드는 기술 그 두번째입니다. 밑장 빼기 기술 아닙니다. 사기가 아니라는 말씀. (^^), Static route 설정에서 nexthop 또는 gateway를 설정하지 않고, Interface만 지정해서 설정하는 방법으로 Static connected를 만들 수 있습니다. 실제 설정 예를 들어 설명하기에 앞서 각 OS에서 Static route 설정 방법을 확인해 보겠습니다.

 

Windows 10 static route 설정    예) route add 157.11.5.0 MASK 255.255.255.0  157.55.80.1 METRIC 3 IF 2              destination^    ^mask                    ^gateway    metric^    ^interface Linux Static route 설정 예) ip route add 157.11.5.0/24 via 192.168.1.1 dev eth0  metric 1                 destination^             ^gateway         ^ interface  ^metric                                 Cisco Router Static route 설정 예) ip route 10.1.2.0 255.255.255.0 10.1.1.2  25                 // Old IOS 방식은 nexthop 또는 interface 중 1개만 가능         destination^          nexthop^           ^AD     ip route 10.1.2.0 255.255.255.0 Gi0/1  25                     // Old IOS 방식은 nexthop 또는 interface 중 1개만 가능         destination^          interface^      ^AD                                ip route 10.1.2.0 255.255.255.0 Gi0/1 10.1.1.2 25          // New IOS 방식은 nexthop, interface 동시 사용 가능           destination^          interface^  nexthop^  ^AD

 

Windows 10, Linux는 static route를 설정할 때, destination, nexthop, interface, metric의 4가지 파라미터를 사용할 수 있습니다.  Cisco Router는 old IOS에서는 static route 설정 시에 destination, [nexthop/interface], AD(Administrative Distance)의 4가지 파라미터를 사용할 수 있지만, nexthop과 interface, 둘 모두를 동시에 사용할 수는 없습니다. Serial 링크에서는 interface를 사용하고, Ethenet 링크에서는 nexthop을 주로 사용합니다. 그리고, Cisco router는 static route 설정시에는 AD 값은 지정할 수 있지만 metric 값은 설정하지 못합니다. Static route은 metric은 0으로 출력이 되긴 하지만 의미 있는 값이 아니고, 변경이 불가합니다. Dynamic Routing Protocol이 설정하는 metric과 출력 포맷을 동일하게 하기 위해서 routing table을 출력할 때는 [1/0] 과 같이 AD는 1, metric은 0으로 표시가 됩니다. 

 

Recursive lookup이 일어나지 않도록 하려면?

Nexthop만을 사용하는 경우는 출구 interface를 찾기 위해서 routing table lookup을 한번 더(recursive lookup) 해야합니다. 또한, nexthop만을 지정한 route 엔트리는 interface down과 연결되지 않습니다. Interface down과 연결되지 않는다는 말은 nexthop과 연결된 interface가 down 되더라도 엔트리가 라우팅 테이블에서 삭제되지 않는다는 의미입니다. 반면에 interface를 사용하는 경우에는 인터페이스가 down되면, static route 엔트리가 라우팅 테이블에서 삭제됩니다. 라우터에서는 그리하여 nexthop을 사용하기 보다는 interface를 사용하는 것을  더 권장합니다. 최근 Cisco IOS에서는 nexthop과 interface, 둘 모두를 동시에 사용할 수 있습니다.  패킷트레이서는 둘 모두를 동시에 사용할 수 없습니다.

 

앞 글의 그림5에서 "Destiantion net unreachable" ICMP error 발생 확인을 위해서 각 router들에 가는 길, 오는 길을 static route로 설정을 했었습니다. Static route를 설정할 때, nexthop을 사용하였었습니다. 

 

참조27 :  그림5의 3개 Router의 라우팅 테이블이 요렇데여~

 

참조27은 Router4, Router5, Router6의 Routing Table을 보여 줍니다. Connected와 Local 엔트리들 이외에 각 라우터마다 2개의 S 엔트리가 생성되어 있습니다. 이 엔트리들이 Static으로 설정한 static route 엔트리들인데요. 각 엔트리를 보면, via 뒤에 nexthop IP만 있습니다. 출구 Interface가 지정되어 있지 않습니다. 이 경우 어느 interface로 보내야 할 지를 알수 없기 때문에 라우팅 테이블을 한번 더 lookup 해서 출구 인터페이스를 찾게 됩니다. Router4의 경우를 보면, 10.10.13.0/24의 nexthop IP 10.10.11.2는 라우팅 테이블을 한번 더 lookup 하여 10.10.11.0/30 엔트리를 찾습니다. 이제 출구 인터페이스 GigabitEthernet0/1을 찾았습니다. 

 

Recursive lookup이 일어나지 않도록 하려면, static route 설정할 때, nexthop을 사용하는 대신에 interface를 사용하면 됩니다. 그림5의 환경에서 Router4의 static route 설정을 nexthop에서 interface에서로 모두 변경해 보겠습니다.

 

참조28 : nexthop을 모두 interface로 바꾸었더니 Connected가 뿅~

 

nexthop 대신에 interface를 사용하여 static route를 설정하니, 이전에 nexthop IP만 가지고 있던 2개의 Static route가 아래와 같이 directly connected 로 변경되었습니다. 짠~ 하고, connected가 나타났습니다.(^^)

 

변경 전

S       10.10.12.0/30 [1/0] via 10.10.11.2
S       10.10.13.0/24 [1/0] via 10.10.11.2

 

변경 후

S       10.10.12.0/30 is directly connected, GigabitEthernet0/1
S       10.10.13.0/24 is directly connected, GigabitEthernet0/1

 

 

Static은 Static인데, direct connected 라네요. 그래서 Static route로 만드는 Connected 입니다. 이렇게 변경해도 PC1에서 Server1으로 ping이 될까요? 네~ 물론 됩니다. 되는지 ping 해 봤습니다. (^^)

 

참조29 : Router4에 static route로 connected 만들어 놓고 PC1에서 Server1으로 ping

 

처음 3번은 "Request timed out."이 발생했어요. "어?? ping 안되는 건가??" 하는 마음이 드는 순간 마지막 4번째 ping이 정상을 찍습니다. 호~~! 이후부터는 계속 정상 ping이 잘 됩니다. 

 

Connected는 직접 연결 : ARP Request를 직접 destination IP로 보냄

앞에서 계속해서 설명하길 connected는 직접 연결이고, ping 목적지인 host IP로 직접 ARP request를 보내서 ARP reply를 받아서 서로 직접 통신 하는 것이라고 설명을 했었습니다. 그런데, 이게 어쩐일인가요? 10.10.13.2가 Router4에 직접 연결된 host가 아닌데, 도대체 어떻게 된 일입니까요?  맞습니다. connected 라우팅 엔트리는 모든 IP 장비에서 직접 ARP request를 보냅니다. Router4의 ARP table을 확인해 보면, 아래 참조30과 같이 ARP cache table에 10.10.13.2 IP에 대한 MAC learning이 되어 있는 것이 보입니다.

 

참조30 : Router4에 Router6에 직접 연결된 10.10.13.2의 ARP resolution이??? - 니가 여기서 왜 나와?

 

Static으로 interface만 주고 route를 설정하면, Static connected 엔트리가 생성되고, IP 장비는 해당 엔트리에 직접 ARP Request를 보낼 수 있는 직접 연결된 장비로 인식하여 ARP request를 직접 보냅니다. 이 경우에는 Router5에 proxy ARP 기능이 enable되어 있어서 Router5가 대신 자기 MAC address로 ARP reply를 보내 준 것입니다. 실제 그런지 Router5의 MAC address를 확인해 보겠습니다.

 

참조31 : Router5의 Gi0/0 인터페이스 MAC address is 0060.47ee.5301

 

Router4는 10.10.13.2가 directly connectd 이기 때문에 ARP Request를 직접 10.10.13.2로 보냈는데, Router5가 대신 자신의 MAC address로 응답을 해 주었던 것입니다. 그렇게 패킷은 Router5에게 전달이 되고, 다시 Router5가 Router6으로 라우팅을 해서 ping 이 정상적으로 동작하게 된 것이었습니다.

 

connected는 ARP request를 직접 보낸다

라우터에 static route 설정 시 nexthop 대신에 interface 만을 사용하는 것은 recursive lookup을 줄일 수 있다는 면에서는 일면 바람직해 보이지만, ARP request를 직접 보낸다는 점에서 destination host IP 숫자가 제한적인 경우에만 사용하는 것이 좋습니다. 또한, ARP request를 직접 보내므로 destination host가 ARP request를 받아서 응답할 수 있도록 동일 Local Link에 존재하거나, Router가 proxy ARP로 ARP request에 대리 응답을 해 줄 수 있는 환경이어야만 합니다.

 

예를 들어 default route(0.0.0.0)를 interface 만을 이용해서 stratic route로 설정한 경우를 생각해 보면, 모든 destination에서 직접 ARP request를 보냅니다. 라우터가 proxy ARP로 응답을 해주는 상황이라면, 라우팅할 패킷이 발생하는 destination IP 수 만큼 ARP cache table entry도 등록이 될 것입니다. Destination IP가 많아지면, 성능저하를 가져 올 수도 있고 ARP cache table 메모리가 부족해 질 수도 있을 것입니다.

 

최근 라우터들은 기본적으로 nexthop과 interface를 동시에 지정할 수 있으니 특별한 경우가 아니라면 static route 설정 시 interface만을 사용하는 것은 지양하는 게 좋습니다. 특별한 경우는 어떠한 경우가 있을까요?  하나의 LAN에서 서로 다른 subnet 대역 IP를 가진 host가 서로 통신이 되어야 하는 경우가 그런 특별한 경우가 될 수 있을텐데요.  하나의 LAN에서 서로 다른 subnet 대역의 IP는 라우터를 통해야지만 통신이 된다고 배웠었는데, 이게 정말 될까요?  

 

패킷트레이서에서 하나의 스위치에 연결된 서로 다른 subnet 대역끼리 static route로 서로 통신이 되는지 확인해 보기 위해서 그림8과 같이 구성하고, IP와 subnet mask, 그리고 static route를 각각 설정하였습니다. 

 

참조32 : Static connected로 서로 다른 subnet 대역간 ping이 될까요? - 패킷트레이스는 안되네요

 

패킷트레이서에서는 설정은 잘 들어가 지지만, 실제로 ping은 안되는군요. 되도록 구현을 안한 것 같습니다. Virtual Box Linux VM을 이용해서 linux box 실제 상황에서는 되는지 확인해 봤습니다. 

 

참조33 : Linux machine에 각각 172.16.10.11/24, 172.16.11.11/24 로 다른 subnet 대역 IP 할당했씨유~

 

참조33과 같이 2개의 VM이 L2 bridge로 연결되어 있는 상황에서 한쪽에는 172.16.10.11/24, 다른 한쪽에는 172.16.11.11/24로인터페이스 IP를 각각 설정하였습니다. 그런 후에 서로 간에 상대방 IP에 대해서 Static Router 설정을 Interface만 주도록 설정해서 Connected 라우팅 엔트리가 등록 되게 만들었습니다.  Subnet이 다른데도 실제 ARP request가 나가고, ARP reply 응답을 해서 ICMP ping packet을 서로 주고 받게 되는지 확인하기 위해서 양쪽 host에 tcpdump를 걸어서 확인했습니다.

 

참조34 : ping 잘 되고, arp request/reply 잘 주고 받고, arp cache table도 잘 만들어 지네요

 

VirtualBox로 구성하였지만, 그림8과 같은 구성인데, 서로 다른 대역의 host끼리 L2 스위치를 통해서 서로 직접 통신이 잘 되는 것을 확인하였습니다.

 

IPv6에서는 Static connected로 서로 다른 대역 통신 X

Static connected로 만들었기 때문에 ARP request를 직접 보내는 것은 이해가 되지만, proxyARP도 아닌데 상대 host는 다른 subnet 대역에서 온 ARP request에 대해서 응답을 해 주네요. 이것은 IPv4 ARP 프로토콜이 IP 헤더가 없는 Link Layer protocol이기 때문에 ARP reply할 때, 동일 subnet 여부를 체크하지 않기 때문입니다. IPv6에서는 Neighbor Discovery 프로토콜이 ARP 프로토콜을 대체하였습니다. 그런데, 이 Neighbor Discovery 프로토콜은 ICMPv6로 동작하기 때문에 L3 Layer에서 동작합니다. 그래서 Neighb Discovery 요청(Neighbor Solicitation)에 대한 응답(Negibhbor Advertisement)는 동일 subnet에서 보낸 요청에만 응답을 하도록 되어 있습니다. 그렇기 때문에 IPv4 Static Connected처럼 서로 다른 대역의 IP가 서로 통신이 이루어지지 않습니다. 

 

Windows는 Static connected를 설정하는 방법이 Router, Linux와는 다릅니다. Windows에서는 nexthop을 안주는 게 아니고, nexthop을 자기 자신 IP를 주거나 0.0.0.0 으로 해서 interface와 함께 설정을 하면 됩니다.

 

참조35 : Windows10에서 Static route로 "연결됨" 라우팅 엔트리 만들기

 

참조 35와 같이 Windows에서는 static route 설정 시 gateway를 자기 자신 IP로 하거나(11.12.13.0), 0.0.0.0을 주거나(12.13.14.0) 모두 connected(연결됨) 엔트리가 만들어 지는 것을 볼 수 있습니다.

 

Connected를 단편으로 정리하려고 하다 보니, 글이 투머치 롱롱 스토리에 가독성도 떨어지는 것 같고 해서 글을 3편으로 분리하였습니다. ^^

 

오리뎅이의 라우팅 이야기는 Connected, Static Route, RIP, OSPF, IS-IS, iBGP, eBGP, VRF Lite, VRF(MPLS L3 VPN), VxLAN, EVPN까지 쭈욱 이어질 예정입니다. 함께 쭈욱 같이 공부해 보시죠. 

 

긴 글 끝까지 읽어 주셔서 고맙습니다. 

 

 

 2020년 12월 6일 일요일 저녁 수원에서 뒤뚱뒤뚱~~~~  [오리]

 

 

안녕하세요? 오리뎅이입니다.

 

Connected 이야기 전편에 이어 계속 이어집니다. 

 

"대상 네트워크에 연결할 수 없습니다" vs "대상 호스트에 연결할 수 없습니다"

 

("Destiantion net unreachable" vs "Destination host unreachable")

Test를 위해서 Router2의 10.10.11.0/24 LAN에 연결된 interface Gi0/1을 shut down 하고, PC0에서 PC0(1)로 ping을 수행해 보겠습니다.

 

참조19 : 직접 연결된 network의 host로 메시지를 전달할 수 없는 상황일 때는 host unreachable

 

Connnected, 직접 연결을 계속해서 반복적으로 얘기하고자 했던 또 한가지 이유입니다. 직접 연결된 네트워크의 host로 메시지를 전달할 수 없는 상황일 때, 라우터 또는 라우팅을 수행하는 장비에서는 "Destination host unreachable" ICMP error를 보냅니다. ICMP 응답 메시지를 보면, 앞부분에 누구로부터 수신된 메시지인지 출처를 찍어줍니다. 참조19에서는 영문 출력의 경우 "Reply from 10.10.10.1" 또는 한글 출력의 경우는 "192.168.35.1의 응답"으로와 같이 이 ICMP error 메시지를 보낸 라우터의 IP가 출력됩니다. "Destination host unreachable" 또는 "대상 호스트에 연결할 수 없습니다"라는 메시지가 출력된다면, 이는 ping의 목적지가 그 ICMP 에러 메시지를 보낸 라우터에게 직접 연결된 host였지만, 패킷을 직접 전달할 수 없는 상황이기때문에 ICMP error를 보내 준 것입니다.

 

Connected가 라우팅 테이블에서 사라졌다

참조15에서는 10.10.11.2로 ping을 했을 때, "Destination host unreachable"이 아닌, "Request timed out" 에러가 발생했었습니다. 무엇이 달랐을까요? Interface shutdown을 하기 전에는 Routing Table에 "Connected"가 있었고, ARP resolution도 정상적으로 수행되어 ICMP 메시지를 PC0(1)로 forwarding 할 수 있는 상황이었습니다. 그래서 정상적으로  메시지를 forwarding 하였고, ICMP error를 발생시킬 상황이 아니었습니다. Interface를 shutdown 한 후에는 아래 참조20과 같이 10.10.11.0/24 네트워크로 연결된 Connected와 Local이 라우팅 테이블에서 삭제 되었습니다. Interface가 down 되어 routing lookup이 안되므로 메시지를 forwarding 할 수 없는 상황입니다. 직접 연결 된 host인데, 메시지를 forwarding 할 수 없는 상황이기 때문에 라우터가 ICMP 에러를 보냅니다. 이 때 직접 연결된 host라는 것을 알려 주기 위해서 "Destination net unreachable"이 아닌 "Destination host unreachable"을 보냅니다.

 

참조20 : 직접 연결된 네트워크에 있는 host로 메시지를 전달할 수 없는 상황1

 

황당 퀴즈) Connected routing 엔트리가 routing table에서 사라지는 오직 하나의 경우는?

              정답) 유일무이(唯一無二) 수신 인터페이스가 down 된 경우 밖에 없습니다요.

 

직접 연결된 상대방에게 메시지를 전달할 수 없는 상황이 한가지 더 있습니다. 라우터의 Interface가 Up 상태이더라도 ARP resolution이 안되는 상황이 또 다른 직접 전달할 수 없는 상황2 입니다. 패킷 트레이서에서는 이 상황은 재현이 안되네요. Router에서 직접 연결된 host로 ARP resolution이 안되는 그림4와 같은 상황도 Router2에서 메시지를 직접 전달할 수 없는 상황입니다. 

 

실제 상황에서는 그림4와 같이 Router2와 Switch0(1) 사이의 link는 정상적으로 Up 상황이지만, Switch0(1)과 PC0(1)사이가 Down된 상황에서도 PC0에서 PC0(1)로 ping을 수행하는 경우, "Destination host unreachable" ICMP error가 Router2에서 생성되어 PC0로 보내 집니다. 단, Router2에 PC0(1)에 대한 ARP Resolution이 되어 있지 않은 상황일 때만 그렇습니다. Switch0(1)과 PC0(1)사이가 Down 되기 이전에 학습된 PC0(1)에 ARP 엔트리가 Router2에 남아 있는 상황이라면, Router2는 그 MAC address를 이용해서 ICMP ping request 메시지를 forwarding 해 버릴 것이기 때문에 Route2에서는 ICMP error가 발생하지 않습니다. 이 경우에 PC0에서는 "Request timed out"이 발생합니다.

 

 

Connected host가 unreachable 상태일 때, "Destination host unreachable" 를 보내 주는 것이 순리 

"Destination host unreachable" ICMP error가 발생하는 것은 router에서 뿐만 아니라 모든 IP 장비에서 동일하게 발생할 수 있습니다. 모든 IP 장비에서 직접 연결된, 즉, Connected 된 네트워크의 상대 host로 메시지를 직접 전달할 수 없는 2가지 상황일 때, "Destination host unreachable" 이 발생합니다.

 

메시지를 직접 전달할 수 없는 2가지 상황이란?

    1) Routing table에 엔트리가 없는 경우 (인터페이스가 down 되었거나, route 엔트리가 등록 안된 경우)

    2) nexthop IP에 대해 ARP resolution이 안되는 경우

 

참조21 : 오리뎅이 집 PC에서 존재하지 않는 host에 ping을 날려 봤씨유

 

참조22 : 오리뎅이 linux 머신에서도 존재하지 않는 host에 ping을 날려 봤슈

 

참조21, 참조22와 같이 Windows와 Linux host에서도 connected로 직접 연결된 범위에 속하는 존재하지 않는 IP로 ping을 보내면, host 자기 자신의 IP layer에서 "대상 호스트에 연결할 수 없습니다." 또는 "Destination Hsot Unreachable" 에러를 발생 시킵니다.

 

패킷트레이서에서는 "Destination net unreachable"은 발생시킬 수가 없던 것이었다

지금껏 "Destination host unreachable"에 case에 대해서 이야기 하였기에, 이제는 "Destination net unreachable"이 언제 발생하는가를 알아볼 차례입니다. 그래서 패킷크레이서에서 아래와 그림5와 같은 구성을 만들었습니다.

 

 

우선 PC1에서 Server1으로 ping이 되도록 static 라우팅 설정을 해줍니다. "사랑에는 일방통행이 있을지라도, 라우팅에는 일방통행이란 없다" 당연한거 아임까?  PC1과 Server1이 서로 통신이 되도록 하려면, 쌍방통해이 되도록 가는 길, 오는 길을 각각 모두 뚫어 주어야 합니다.  가는길은 PC1, Router4, Router5에 각각 static routing 설정을 해 주어야 합니다. Router6는 스태틱 라우틸 설정 안하나요? 이제는 이런 질문 하면 안됩니다. 마지막 hop 라우터는 host와 Connected 라서 따로 routing 설정을 안해도 된다는 사실을 이제 우리는 모두 알고 있습니다. 가는길을 설정 했으면, 오는 길도 설정합니다. Server1, Router6, Router5에 static route 설정을 합니다. Router4는 당근 PC1과 Connected이므로 라우팅 설정 불필요임돠. 자 이렇게 가는 길, 오는 길 쌍방을 뚫었습니다. Ping 이 잘 가겠지요? 네, 잘 갑니다.

 

참조23 : PC1과 Server1이 ping 잘되니 쌍방 라우팅 잘 설정 했다는 거

 

먼저 Router6에서 Server connected 인터페이스를 shutdown 하고, ping을 다시 날려 봤습니다. 뭐가 돌아 왔을까요?

 

 

참조24 : Router6(10.10.12.2)에서 Destination host unreachable이 잘 오는군요 

 

그럼 이제 다음 수순은 무엇일까요? 이번에 다음 구간을 shutdown 하고 ping을 다시 날려 보았습니다.

 

 

Router5에서는 10.10.13.0/24 네트워크가 connected된 네트워크가 아닙니다. 그러니, 여기서는 당연히 "Destination net unreachable" ICMP error가 돌아올 상황입니다. 그런디... "니가 거기서 왜나와?"  딱, 이럴때 쓰는 말인듯 하네요. ㅎ

 

참조25 : 예상을 깨고, Router5(10.10.11.2)는 Destination host unreachable을 보낸 것이었다

 

이 후에 Router4 인터페이스를 shutdown 시킨 경우에도 동일하게 Router4가 "Destination host unreachable" 보냈습니다. 이것은 제가 현장에서 경험했던 상황과는 다른 결과입니다. 아래 RFC 1812에 기술되어 있는 내용을 보더라도, 실제 라우팅 장비에서는 저런 상황에서는 "Destination net unreachable" ICMP error를 보내 주어야 합니다.  

RFC 1812, pages 56 and 57: If a router cannot forward a packet because it has no routes at all (including no default route) to the destination specified in the packet, then the router MUST generate a Destination Unreachable,  Code 0 (Network Unreachable) ICMP message.  If a packet is to be forwarded to a host on a network that is directly connected to the router (i.e., the router is the last-hop router) and the router has ascertained that there is no path to the destination  host then the router MUST generate a Destination Unreachable, Code 1 (Host Unreachable) ICMP message.

 참조26 : RFC 1812에서 정의하고 있는 Network Unreachable과 Host Unreachable

 

현장에서 "Destination host unreachable"을 수신하게 된다면, ICMP error를 보낸 라우팅 hop이 라스트 hop이고, 해당 라스트 hop에서 직접 연결된 host로 forwarding 할 수 없는 상황으로 파악하고, 트러블슈팅을 진행하면 됩니다.

 

반면에 "Destination net unreachable"을 수신하게 된다면, 라스트 hop이 아닌 중간 경로에 있는 어느 라우팅 노드에서 다음 라우팅 hop으로 forwarding 할 수 없는 상황으로 판단할 수 있습니다.

 

[오리뎅이의 라우팅 이야기 - 1] Connected - IP 네트워킹, 라우팅의 시작 - 3/3 편으로 이어집니다.

 

                                                                         2020년 12월 6일 일요일 저녁 수원에서 뒤뚱뒤뚱~~~~  [오리]

 

안녕하세요? 오리뎅이입니다.

 

 

티스토리에 새롭게 둥지를 만들고, 첫번째 글을 작성하고 있습니다. 작년(2019년) 중반 즈음에 쿠버네티스를 접하게 되면서, 연이어 Public Cloud까지 공부해야 할 것들이 너무 많아서 이것 저것 들여다 본다고, 블로그 글을 거의 올리지 못하고 있었습니다. 계속 주어 담기만 하다보니, 하고픈 이야기들이 꽉꽉 들어 차서 흘러 넘칠 것 같습니다. 이제 이야기 보따리를 좀 풀어 보려고 합니다. (^^). 그 첫번째로 라우팅 프로토콜 이야기 보따리를 풀어 헤쳐 보겠습니다.

 

[오리뎅이의 LAN 통신 이야기]에서는 주로 LAN Switching에 대해서 다루었었습니다. 동일한 LAN 내부에 있는 목적지 장비와의 통신 과정, 그리고 하나의 LAN에 속해 있는 장비와 다른 LAN에 속해 있는 장비와의 통신 과정을 삼테이블(Routing Table, ARP Table, MAC Table)의 생성과 변경 그리고 삭제 과정을 통해서 살펴 보았었습니다. 고로 LAN과 다른 LAN간의 통신은 Router 혹은 Routing 기능을 제공하는 L3 이상 장비를 통해서 이루어 진다는 것을 저희는 LAN 통신 이야기에서 이미 알아 보았었습니다.  그렇지만, LAN 통신 이야기에서는 라우팅 프로토콜들에 대해서는 다루지 않았었습니다.

 

LAN 통신 이야기에 이어서 라우팅 프로토콜에 대한 글을 계속하려는 생각이 없었던 것은 아니었지만, 저 개인적으로는 당시에 라우팅 프로토콜을 Deep Dive 해야 할 필요성을 느끼지 못했었기 때문에 미루고 있었습니다. 그런데, 쿠버네티스와 퍼블릭 클라우드를 공부하면서 오히려 전에는 사용할 일이 없겠다고 느꼈던 라우팅 프로토콜, BGP의 어택(?)을 받았습니다. 또한 VxLAN(Virtual eXtensible LAN)과 EVPN(Ethernet VPN)을 기반으로 해서 Leaf/Spine switch로 구성되는 Data Center IP Fabric에서도 Underlay IGP와 Overlay iBGP, 그리고 Customer tenant network와의 eBGP 연동 등으로 동적(Dynamic) Routing Protocol을 업무에서 접하게 되는 빈도가 전에 없이 급증 하였습니다. BGP를 자세하게 이해하지 않고서는 EVPN을 이해할 수 없습니다. 또한, BGP를 이해하려면 IGP로 사용되는 OSPF나 IS-IS에 대해서도 자세하게 알아야 할 필요가 있습니다. 결국 모 다 알아야 되는거 아니겠습니꽈? (^^). 지금 만나러 갑니다. 다 주거써~ 라우팅 프로토콜들!! 딱 기다렷!!

 

경고1 : 이 글은 네트워크 입문자분들을 독자로 예상하고 쓰는 글이오니, 중수 이상 분들은 오글거림을 각오하삼!!

경고2 : 글 내용이 투머치 롱롱 하니께유, 심호흡 한번씩 하시고 시작하세유~~

 

Connected - IP 네트워킹, 라우팅의 시작

일반적으로 잘 알려진 동적(Dynamic) 라우팅 프로토콜들로는 RIP, OSPF, IS-IS, BGP(iBGP, eBGP)가 있습니다. 그 외에 시스코에서 만든 IGRP와 EIGRP도 시스코 장비의 시장 장악력에 기반하여 많이 사용되고 있기때문에, 일반 IT 엔지니어들에게는 몰라도 스위치나 라우터 같은 네트워크 장비를 다루는 네트워크 엔지니어들에게는 잘 알려져 있습니다.  다이나믹 라우팅 프로토콜과 더불어 모든 IP 장비의 라우팅 테이블에 빠지지 않는 두가지 라우팅 프로토콜이 있습니다. 바로 Connected와 Static Routing입니다. Cisco 라우터에서는 Connected와 Static Routing도 각각의 하나의 라우팅 프로토콜 프로세스로 구동을 한다고 합니다. 다른 벤더 장비에서도 그렇게 동작하는지는 모르겠습니다. 동적 라우팅 프로토콜들에 대해서 자세하게 알아보기 이전에 Connected와 Static Routing에 대해 자세히 알아 보려고 합니다. 지금, Now, 당장은 우선  Connected (연결됨)에 대해 자세히 알아 볼 것입니다.  Connected 하면 떠올려야 할 아래 몇가지 중요한 개념들에 대해서 하나씩 하나씩 자세히 알아 볼 것입니다.  

 

    - Connected를 만드는 기술

      1) 인터페이스에 IP와 subnet mask를 설정하는 순간 - Connected의 탄생

      2) Static route로 만드는 Connected

    - L2 연결은 MAC으로 통신한다는 의미가 아니랍니다

    - 직접 전달 vs 간접 전달

    - 라우터의 직접 전달

    - Connected가 라우팅 테이블에서 사라졌다 - 링크 down

    - "Destination host unreachable" vs "Destination net unreachable"

 

Winodws, Linux 및 라우터에서 각각 라우팅 테이블을 출력해 보면, 라우팅 테이블 엔트리(entry:항목)에서 Connected (연결됨)를 쉽게 발견할 수 있습니다. 아래 참조1, 참조2, 참조3은 각각 Windows 10, Cisco Router, Ubuntu Linux에서 라우팅 테이블을 출력해 본 예입니다.

 

참조1 : Windows 10 라우팅 테이블

 

Windows 라우팅 테이블에서는 한글인 경우에는 게이트웨이 컬럼에 연결됨으로 표시가 됩니다. 영문 윈도우인 경우에는 Connected 라고 출력이 됩니다.

 

참조2 : Cisco Router 라우팅 테이블

 

Cisco 라우터의 라우팅 테이블에서는 "show ip route" 명령으로 라우팅 테이블 엔트리(항목)를 조회할 수 있습니다. 참고2를 보면, 윗 부분에 Codes 들에 대한 설명이 쭈르륵 나열되어 있습니다. 그 중에 가장 첫번째에 "C - connected" 라고 보여주고 있습니다. 또한 중간 부분에는 "directly connected, Ethernet0"와 같이 어느 인터페이스에 직접 연결되어 있는지도 설명해 주고 있습니다. 밑부분에 엔트리들을 보면, 맨 앞에 C, S 와 같이 영문 대문자로 각 엔트리가 어떤 라우팅 프로토콜에 의해서 등록된 것인지를 표시해 보여 줍니다. S는 static routing protocol에 의해서 설정된 것임을 나타냅니다. 

 

* 엔트리(entry:항목) : 라우팅 테이블을 출력하면, 많은 행(row)들이 출력됩니다. 행 하나 하나를 엔트리라고 부릅니다

 

참조3 : Linux 라우팅 테이블 by "route -n"

 

Linux에서는 "route -n" 명령으로 라우팅 테이블을 출력해 볼 수 있습니다. Gateway column이  "0.0.0.0" 으로 표시되는 것들이 Connected 입니다. Linux에서는 "route -n" 명령 외에 "ip route show" 명령을 이용해서도 라우팅 테이블 항목들을 아래와 같이 출력해 볼 수 있습니다. 

 

참조4 : Linux 라우팅 테이블 by "ip route show"

 

"route -n" 명령의 출력문에서 Gateway가 "0.0.0.0" 이었던 destination network에는 공통적으로 "scope link"가 적혀 있습니다. Linux에서 "man ip" 명령으로 scope에 대한 설명을 보면, scope 에 대해서 아래와 같이 설명하고 있습니다.

 

참조5 : Linux "man ip route" 명령으로 조회한 scope link 정의

 

"scope link for direct unicast and broadcast routes" : 직접 연결된 unicast와 broadcast 루트

 

이렇게 모든 IP 장비의 라우팅 테이블에는 무조건 Connected 항목이 있습니다. 이 항목이 없다면 거짓말입니다. "무조건 무조건이야~~~!"  왜 무조건일까요? 어떻게 Connected가 생성되는지를 알게 되면, 왜 무조건인지 이해가 됩니다. 함께 알아 보시죠~!  ^^

 

Connected를 만드는 기술

Connected를 만드는 방법은 다음과 같이 2가지가 있습니다. 첫번째 방법은 IP 월드를 살고 있는 저희들이 너무나 잘 알고 있는 방법입니다. 

 

    1) 인터페이스에 IP와 subnet을 설정하는 방법

    2) Static route 설정 시 nexthop 지정하지 않고, interface만 지정하는 방법

 

PC나 노트북을 받아서 Interface에 IP와 subnet을 그리고 Gateway를 설정하는 것은 누구나가 알고 있습니다. PC나 서버와 같은 host 뿐만 아니라 라우터와 L4/L7 Load Balancer, Firewall, NAT, 스마트폰에 이르기까지 모든 IP 통신을 하는 장비들은 Ethernet Interface에 IP와 subnet을 설정하면, 라우팅 테이블에 connected route 엔트리가 생성 됩니다. 시스코 패킷 트레이스를 이용해서 라우터와 PC, 그리고 서버에 각각 IP와 subnet을 설정해서 connected가 생성되는지를 확인해 보겠습니다. 먼저 라우터와 라우터간 연결 인터페이스에 IP와 subnet을 설정해서 connected route 엔트리가 생성되는지를 보겠습니다.

 

인터페이스에 IP와 subnet을 설정하는 방법 - 라우터

 

패킷트레이서에서 2911 IP 2대를 서로 연결하고, IP와 subnet은 설정하지 않은 상태에서 route table을 보면 아래 참조5와 같이 아무런 엔트리도 생성되어 있지 않습니다.

 

참조6 : 인터페이스에 IP와 subnet을 설정하기 전 라우팅 테이블

 

이제 양쪽 라우터끼리 서로 연결된 인터페이스에 각각 IP와 subnet을 설정하고, connected route 엔트리가 생성되는 것을 확인해 보겠습니다.

 

참조7 : 라우터 인터페이스에 IP와 subnet 설정하니 뚝딱 생겨난 Connected와 Local

 

Router2와 Router3가 서로 연결된 GigabitEthernet 0/0 인터페이스에 각각 IP와 subnet mask를 입력하고, "no shut" 명령을 입력하자,

 

"line protocol %LINEPROTO-5-PDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up"

 

이와 같은 로그가 출력되었고, 이어서 바로 라우팅 테이블을 다시 확인해 보니, 2개의 routing 엔트리가 생성되어 있는 것이 보입니다.

 

"어! 왜 2개지??? ㅎㅎㅎ"

 

앞에 "C" 로 마킹된 것은 제가 지금까지 얘기하고 있었던 "Connected"인데요. "L" 로 마킹 된 엔트리가 하나 더 생성되어 있네요.  L은 위에 설명을 보니 "L - local" 이라고 되어 있습니다. 그리고, 엔트리의 IP/prefix를 보니 10.10.10.1/32와 10.10.10.2/32 로 자기 자신 Interface에 할당 된 IP가 host subnet(subnet mask 255.255.255.255 또는 Prefix length 32)으로 local로 생성이 되는군요. 당황스럽네요. 다행히 사업자에게 데모하는 상황이 아니라 당황한 얼굴 표정은 안 들켰습니다. (^^)  사업자에 데모하는 와중에 예상치 못한 이런 결과가 톡 튀어 나오면, 정말 당황 스럽죠. 당황해서 "어버버~~~" 하기도 합니다. ㅋㅋㅋ

 

Local은 라우터에서나 Host에서나 같은 의미로 사용됩니다. Linux에서도 아래와 같이 "ip route show table local" 이라는 명령으로 host inteface에 항당한 IP들이 local routing table에 설정되어 있는 것을 확인할 수 있습니다.

 

참조8 : Linux host local routing table

 

참고로 쿠버네티스의 Serivce Type의 하나인 nodePort 서비스 타입을 설명하는 내용 중에 "nodePort 타입 서비스를 생성하면 LocalIP:NodePort로 서비스에 접속이 가능하다"는 설명이 있습니다. 여기서 말하는  LocalIP도 linux host에 설정된 Local IP들을 의미합니다. NodePort 서비스 접속은 loopback IP인 localhost, 127.0.0.1을 포함한 모든 host Local IP를 사용할 수 있습니다.

 

Windows도 Local을 라우팅 테이블에 등록합니다. 저희가 무심코 지나쳤지만, 2번째, 3번째, 4번째 엔트리를 한번 보실까요. 2번째 엔트리가 Connected subnet입니다. 3번째 엔트리가 바로 Local 이네요. 4번째 엔트리는 subnet broadcast IP이군요.

 

192.168.35.0     255.255.255.0                연결됨    192.168.35.120    281    // 2번째 엔트리,  Connected
192.168.35.120  255.255.255.255             연결됨    192.168.35.120    281    // 3번째 엔트리,  Local
192.168.35.255  255.255.255.255             연결됨    192.168.35.120    281    // 4번째 엔트리,  Broadcast

 

인터페이스에 IP와 subnet을 설정하는 방법 - 리눅스

잠시 이야기가 삼천포에 들렀다 왔습니다. 다시, 제자리로 돌아와서 Linux에서 서로 직결된 Interface에 IP와 subnet을 설정하여 connected route entry(Gateway가 0.0.0.0 인 엔트리)가 생성되는 것을 살펴 보겠습니다. Virtual Box를 이용해서 Ubuntu 20.04 VM 2개를 띄워서 만들어 봤습니다. Test를 위해서 내부네트워크 어답터 1개씩을 2개 VM에 각각 추가하였습니다.

 

참조9 : enp0s9에 IP와 subnet mask을 설정하기 전

 

 

참조10 : enp0s9에 IP 172.16.10.11과 subnet mask 255.255.255.0(prefix length /24) 설정 후

 

참조10과 같이 enp0s9 인터페이스에 IP와 prefix length, 172.16.10.11/24를 설정하니, routing table에 172.16.10.0 엔트리가 Gateway 0.0.0.0 으로 Iface enp0s9으로 생성이 되었습니다. 또한, 자기 자신의 인터페이스에 설정된 IP인 172.16.10.11도 local routing table에 엔트리가 등록된 것을 볼 수 있습니다.

 

참조11 : 양쪽 VM 인터페이스에 IP와 subnet mask만 설정하고 ping 되나 보기

 

자기 자신 local 인터페이스 IP도 ping이 되고, 다른 VM IP로도 ping이 성공합니다. 라우터에서도 그랬었고, 지금 Linux VM 간에도 저희는 연결된 인터페이스에 IP와 subnet mask (또는 prefex length)를 설정했는데, routing table에 Connected와 Local route 엔트리가 각각 생성되는 것을 확인 할 수 있었습니다. 

 

Windows는 본 글에서 예를 들어 확인해 보지는 않았지만, Windows를 포함하여 다른 모든 IP 기기들도 routing table을 가지고 있고, 인터터페이스에 IP와 subnet mask를 설정하면, Connected와 Local 엔트리가 라우팅 테이블에 생성됩니다.

 

L2 연결은 MAC으로 통신한다는 의미가 아니랍니다

지금까지 두 대의 장비를 직접 케이블로 직결한 경우만 봐서  호~~옥시라도 오해하시는 분이 계실까봐서 안내 말씀 드립니다. (^^) L2 Switch를 통해서 연결되는 host들끼리는 동일 subnet 대역의 IP를 설정하고, subnet mask를 동일하게 설정 할 경우 모두 connected 라우팅 엔트리에 의해서 통신이 됩니다.

 

그림2와 같이 하나의 2960 L2 switch에 라우터와 PC, 서버등 5대의 host들을 동일 subnet에 IP를 할당하고, subnet mask도 동일하게 255.255.255.0으로 설정을 해 주었습니다. 

 

참조12 : Connected 인터페이스로 서로 통신이 된다는 L2 Switch 연결 증명

 

이렇게 host 노드들이 L2 Switch를 통해서 연결되어 있는 경우를 동일 LAN에 속해 있다고 얘기를 합니다. 동일 LAN에 속해 있는 경우는 지금처럼 각각의 host interface에 IP와 subnet mask만 설정을 해주면, Connected 인터페이스가 생성되고, 인터페이스가 정상적으로 up만 되면 서로간에 직접 통신이 가능합니다.  L2 Switch가 몇개가 연결되더라도 동일하게 하나의 LAN에 속하기 때문에 직접 통신이 됩니다.

 

직접 통신이랑 통신하고자 하는 상대방 장비 IP로 직접 ARP request를 보내서 MAC address를 학습해서 패킷을 상대방으로 직접 전달하는 통신 방식을 말합니다. 이와는 다르게 ARP request를 Gateway 또는 nexthop으로 설정된 IP로 보내서 MAC address를 학습하여, 패킷을 보내면 라우팅 장비가 라우팅으로 상대방 장비 IP로 전달해서 통신하는 것을 간접 통신이라고 합니다.  패킷을 라우팅 기능을 하는 장비를 통해서 간접적으로 상대방 장비로 전달하다고 해서 간접 전달이라고 합니다.

 

L2 Switch들로만 연결해서 동일 LAN 구성으로 직접통신이 되도록 하는 것을 L2 연결 이라고 하고, "L2로 연결한다"는 말은 L2 Switch로 연결해서 서로 직접 통신할 수 있도록 구성한다는 의미입니다. 이와는 달리 "L3 연결" 또는 "L3로 연결한다"는 말은 라우팅 기능을 하는 장비를 통해서 routing을 통해서 서로 간접 통신하도록 구성한다는 의미입니다. 

 

앞에서 살펴본 바와 같이 동일 LAN에서 "L2 통신 한다"는 말은 IP 없이 MAC address만을 이용해서 통신한다는 의미가 아닙니다.  L2 연결 경우에도 IP 통신합니다. (^^)  

 

그림2와 같이 동일 LAN에 Router가 연결되어 있는 경우, Router 인터페이스도 다른 host IP와 마찬가지로 동일 LAN에 있기때문에 라우터 인터페이스와 같은 LAN에 속한 host 장비들은 라우터에서 직접전달이 됩니다. 이게 매우 중요한 의미가 있는 대사입니다. 밑줄 쫘~~악!! ㅎ

 

 

참조13 : Route2에 연결된 2개의 서로 다른 LAN, 둘 모두 Connected와 Local 만 있음

 

Router도 직접 연결된 network는 connected로 직접 통신

그림3과 같이 구성하고, 각 장비에서 IP와 subnet mask만 입력을 하였습니다. Router2에서 routing table을 확인해 보면, 참조13과 같이 Connected와 Local만 Gi0/0와 Gi0/1 인터페이스에 각각 생성이 되어 있습니다.

    

    * Gi0/0 : GigabitEthernet0/1 의 줄인 표현

 

이 상태에서 Router2에서 각각의 LAN에 연결된 host들로 ping test를 해 보면, 아래와 같이 잘 됩니다. 당근 잘되야죠. 두개의 LAN 모두 Router2에 직접 연결되어 있어서 직접 통신이 가능한 상태니까요. 

 

참조14 : Router2에 직결된 각 LAN의 host들로 ping 잘 됩니다

 

Router를 통해 연결된 서로 다른 LAN의 host 들은 Router를 통해 간접 연결

이제 밑에 10.10.10.0/24 LAN에 있는 PC0에서 위에 10.10.11.0/24에 있는 PC0(1) 로 ping을 해 보겠습니다. ping이 될까요?

 

참조15 : IP와 subnet mask만 설정하고, 다른 LAN IP로 ping을 한다면???

 

Router2 IP 10.10.10.1 로는 ping이 잘 되지만, PC0(1) IP, 10.10.11.2는 물론이고, Router2의 Gi0/1 IP, 10.10.11.1로도 ping이 가지 않습니다. "Request timed out"이 발생하네요.  당연한 결과죠. 저희는 다른 LAN과 통신하고자 할 경우에는 라우터를 통해서 간접 전달이 되도록 라우터 IP를 nexthop으로 하는 Gateway를 설정해야 하는데, PC들에는 IP와 subnet mask만 설정하였으므로 라우팅 테이블에는 Connected와 Local만 생성되어 있는 상태이고, 다른 LAN에 있는 IP는 라우팅 테이블에 없으니 lookup이 되지 않습니다. 이 상황에서 에러 출력을 "Request timed out"이 아니라 "Destination Net Unreachable" ICMP error를 출력해 주면 직관적으로 바로 routing table에 엔트리가 없다는 것을 알 수 있을텐데, 에러 출력 내용이 조금 아쉽습니다.

 

PC0에 Deafult Gateway를 10.10.10.1로 설정하고, 다시 ping을 해 보겠습니다. 결과가 어떻게 바뀔까요?

 

참조16 : PC0(1)에는 Gateway 설정 안하고, PC0에만 Gateway 설정하고 ping을 한다면?

 

그림3에서 위쪽 LAN의 PC0(1)에는 Gateway를 설정하지 않고, PC0에만 Gateway를 설정했습니다. 그랬더니, Router2의 인터페이스 IP, 10.10.11.1로는 ping이 갑니다. 그렇지만, PC0(1)로는 여전히 ping이 안 갑니다. 아니죠. 좀더 사실적으로 말하자면, "안 갑니다"가 아니라 "안 돌아 옵니다"가 맞습니다.

 

참조17. ping 전,후 Router2 ARP Table 비교

 

10.10.11.2는 Router2에게는 직접 연결된 host이므로, 라우팅 테이블에 Connected 엔트리가 lookup 됩니다. Connected host IP, 10.10.11.2로 ARP Request를 보내고, ARP reply를 받아서 ping request message를 PC0(1)로 보냅니다. 참조17은 ping 수행 전과 후의 Router2 ARP Table을 보여 주고 있는데, ping 수행 후에 ARP table에 10.10.11.2에 대한 엔트리가 생겨난 것을 볼 수 있습니다. PC(1)은 ping request 메시지를 받아서 응답을 하려고, 10.10.10.2를 destination IP로 하여 응답 메시지 전송을 시도합니다. 그러나, PC0(1)의 라우팅 테이블에는 Connected와 Local만 있는 상태이기 때문에 10.10.10.2로 가는 라우팅 엔트리가 검색되지 않습니다. PC0(1)은 ping reply 메시지를 전송하지 못합니다.

 

"사랑에는 일방통행이 있을지라도, 라우팅에는 일방통행이란 없다"

PC0(1)에도 Default Gateway를 설정합니다. 그럼 이제 PC0과 PC0(1) 사이에 서로 ping이 가겠네요. 응답도 오겠네요. (^^). 봅시다~~요.

 

참조18 : 서로 다른 LAN에 있는 PC끼리 Router2의 Connected로 통신 아주 잘 됩니다

 

예상했던 바와 같이 PC0(1)에도 Gateway 설정을 하고 나니, 이제 양방향으로 서로 ping이 잘 됩니다. 아직까지 Route2에는 Connected와 Local 외에는 어떤 다른 routing 설정도 하지 않았습니다. 그러나, Router2에 연결된 서로 다른 interface에 속한 network들은 Router 입장에서는 모두 Connected 네트워크이기 때문에 직접 전달이 가능합니다. 진접 연결된 LAN에 있는 host들에서 라우터로 메시지를 보내기만 하면 전달을 해 줄 수 있습니다. 각 네트워크에 속한 host들 간에는 서로가 직접 연결된 것이 아니고, Router를 통해서 간접 연결 된 상태이므로 Router를 통해 간접 전달이 될 수 있도록 양쪽 host에 모두 routing 설정을 해 주어야 합니다.

 

"사랑에는 일방통행이 있을지라도, 라우팅에는 일방통행이란 없다"는 말은 앞으로 제가 라우팅 이야기를 하는 동안, 수차례 반복해서 써먹게 될 것입니다. 라우팅은 항상 가는 길을 설정했으면, 오는 길도 설정해야 합니다. 연습에서건 실전에서건 라우팅에서 가장 많이 나오는 실수가 "단방향 라우팅만 설정을 해 놓고, ping이 안가네요!!" 입니다. 꼭 기억하고 실수하지 말라는 의미에서 약간의 과장이 섞인 강조어법입니다. 기억하세요. 라우팅에 일방통행은 없습니다. 항상 쌍방통행입니다요. 사랑이 항상 쌍방통행이라면 얼마나 좋을까요? (^^)

 

[오리뎅이의 라우팅 이야기 - 1] Connected - IP 네트워킹, 라우팅의 시작 - 2/3 편으로 이야기가 이어집니다

 

 

 2020년 12월 6일 일요일 저녁 수원에서 뒤뚱뒤뚱~~~~  [오리]