Connected 마지막 편입니다. 인터페이스에 IP와 subnet mask를 설정하면, 라우팅 테이블에 자동으로 Connected와 Local 엔트리가 생성되었었는데요. 이번에는 Static route 설정으로 connected를 알아 보겠습니다.
Static route로 만드는Connected
Connected를 만드는 기술 그 두번째입니다. 밑장 빼기 기술 아닙니다. 사기가 아니라는 말씀. (^^),Static route 설정에서 nexthop 또는 gateway를 설정하지 않고, Interface만 지정해서 설정하는 방법으로 Static connected를 만들 수 있습니다. 실제 설정 예를 들어 설명하기에 앞서 각 OS에서 Static route 설정 방법을 확인해 보겠습니다.
Linux Static route설정 예) ip route add157.11.5.0/24via192.168.1.1deveth0metric1 destination^ ^gateway^interface^metric
Cisco Router Static route설정
예) ip route10.1.2.0255.255.255.010.1.1.225// Old IOS 방식은 nexthop 또는 interface 중 1개만 가능 destination^ nexthop^^AD
ip route10.1.2.0255.255.255.0Gi0/125 // Old IOS 방식은 nexthop 또는 interface 중 1개만 가능 destination^ interface^^AD ip route10.1.2.0255.255.255.0Gi0/110.1.1.225 // 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을 사용하였었습니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Router4#sho ip route
... 중략 ...
10.0.0.0/8 is variably subnetted, 6 subnets, 3 masks
C 10.10.10.0/24 is directly connected, GigabitEthernet0/0
L 10.10.10.1/32 is directly connected, GigabitEthernet0/0
C 10.10.11.0/30 is directly connected, GigabitEthernet0/1
L 10.10.11.1/32 is directly connected, GigabitEthernet0/1
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
Router5#show ip route
... 중략 ...
10.0.0.0/8 is variably subnetted, 6 subnets, 3 masks
S 10.10.10.0/24 [1/0] via 10.10.11.1
C 10.10.11.0/30 is directly connected, GigabitEthernet0/0
L 10.10.11.2/32 is directly connected, GigabitEthernet0/0
C 10.10.12.0/30 is directly connected, GigabitEthernet0/1
L 10.10.12.1/32 is directly connected, GigabitEthernet0/1
S 10.10.13.0/24 [1/0] via 10.10.12.2
Router6#show ip route
... 중략 ...
10.0.0.0/8 is variably subnetted, 6 subnets, 3 masks
S 10.10.10.0/24 [1/0] via 10.10.12.1
S 10.10.11.0/30 [1/0] via 10.10.12.1
C 10.10.12.0/30 is directly connected, GigabitEthernet0/0
L 10.10.12.2/32 is directly connected, GigabitEthernet0/0
C 10.10.13.0/24 is directly connected, GigabitEthernet0/1
L 10.10.13.1/32 is directly connected, GigabitEthernet0/1
참조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에서로 모두 변경해 보겠습니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Router4(config)#no ip route 10.10.12.0 255.255.255.252
Router4(config)#no ip route 10.10.13.0 255.255.255.0
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 해 봤습니다. (^^)
1
2
3
4
5
6
7
8
9
10
11
12
13
C:\>ping 10.10.13.2
Pinging 10.10.13.2with32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Reply from10.10.13.2: bytes=32 time<1ms TTL=125
Ping statistics for10.10.13.2:
Packets: Sent =4, Received =1, Lost =3 (75% loss),
참조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이 되어 있는 것이 보입니다.
1
2
3
4
5
6
Router4#show ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.10.10.1- 000C.8506.9701 ARPA GigabitEthernet0/0
Internet 10.10.10.200060.70A6.4230 ARPA GigabitEthernet0/0
Internet 10.10.11.1- 000C.8506.9702 ARPA GigabitEthernet0/1
Internet 10.10.13.200060.47EE.5301 ARPA GigabitEthernet0/1
참조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를 확인해 보겠습니다.
1
2
3
4
5
6
7
Router#show inte GigabitEthernet 0/0
GigabitEthernet0/0 is up, line protocol is up (connected)
Hardware is CN Gigabit Ethernet, address is 0060.47ee.5301 (bia 0060.47ee.5301)
참조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는 라우터를 통해야지만 통신이 된다고 배웠었는데, 이게 정말 될까요?
그림8. 동일 LAB에서 서로 다른 subnet끼리 통신이 된다고요?
패킷트레이서에서 하나의 스위치에 연결된 서로 다른 subnet 대역끼리 static route로 서로 통신이 되는지 확인해 보기 위해서 그림8과 같이 구성하고, IP와 subnet mask, 그리고 static route를 각각 설정하였습니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
Router7#show ip route
... 중략 ...
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.10.10.0/24 is directly connected, GigabitEthernet0/0
L 10.10.10.1/32 is directly connected, GigabitEthernet0/0
참조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를 걸어서 확인했습니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
limcs@limcs-VM10:~$ ping 172.16.11.11-c 1
PING 172.16.11.11 (172.16.11.11) 56(84) bytes of data.
64 bytes from 172.16.11.11: icmp_seq=1 ttl=64 time=0.830 ms
---172.16.11.11 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
참조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와 함께 설정을 하면 됩니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
C:\WINDOWS\system32>route add 11.12.13.0 mask 255.255.255.0192.168.35.120 IF 9
확인!
C:\WINDOWS\system32>route add 12.13.14.0 mask 255.255.255.00.0.0.0 IF 9
참조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"을 보냅니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Router>show ip route
Codes: L -local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
*- candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.10.10.0/30 is directly connected, GigabitEthernet0/0
L 10.10.10.1/32 is directly connected, GigabitEthernet0/0
직접 연결된 상대방에게 메시지를 전달할 수 없는 상황이 한가지 더 있습니다. 라우터의 Interface가 Up 상태이더라도 ARP resolution이 안되는 상황이 또 다른 직접 전달할 수 없는 상황2 입니다. 패킷 트레이서에서는 이 상황은 재현이 안되네요. Router에서 직접 연결된 host로 ARP resolution이 안되는 그림4와 같은 상황도 Router2에서 메시지를 직접 전달할 수 없는 상황입니다.
그림4. 라우터에서 다운으로 감지되지 않는 Remote 인터페이스 다운 경우
실제 상황에서는 그림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이 안되는 경우
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
C:\Users\user>ipconfig /all
... 중략 ...
IPv4 주소 . . . . . . . . . : 192.168.35.120(기본 설정)
서브넷 마스크 . . . . . . . : 255.255.255.0
임대 시작 날짜. . . . . . . : 2020년 12월 1일 화요일 오후 4:11:03
임대 만료 날짜. . . . . . . : 2020년 12월 1일 화요일 오후 7:11:02
참조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와 같은 구성을 만들었습니다.
그림5. "Destination net unreachable" 확인을 위해 만들어 본 구성
우선 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 이 잘 가겠지요? 네, 잘 갑니다.
참조24 : Router6(10.10.12.2)에서 Destination host unreachable이 잘 오는군요
그럼 이제 다음 수순은 무엇일까요? 이번에 다음 구간을 shutdown 하고 ping을 다시 날려 보았습니다.
그림7. Router5에서 "Destination net unreachable"이 올 것으로 예상되는 상황
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 편으로 이어집니다.
티스토리에 새롭게 둥지를 만들고, 첫번째 글을 작성하고 있습니다. 작년(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에서 라우팅 테이블을 출력해 본 예입니다.
Cisco 라우터의 라우팅 테이블에서는 "show ip route" 명령으로 라우팅 테이블 엔트리(항목)를 조회할 수 있습니다. 참고2를 보면, 윗 부분에 Codes 들에 대한 설명이 쭈르륵 나열되어 있습니다. 그 중에 가장 첫번째에 "C - connected" 라고 보여주고 있습니다. 또한 중간 부분에는 "directly connected, Ethernet0"와 같이 어느 인터페이스에 직접 연결되어 있는지도 설명해 주고 있습니다. 밑부분에 엔트리들을 보면, 맨 앞에 C, S 와 같이 영문 대문자로 각 엔트리가 어떤 라우팅 프로토콜에 의해서 등록된 것인지를 표시해 보여 줍니다. S는 static routing protocol에 의해서 설정된 것임을 나타냅니다.
* 엔트리(entry:항목) : 라우팅 테이블을 출력하면, 많은 행(row)들이 출력됩니다. 행 하나 하나를 엔트리라고 부릅니다
1
2
3
4
5
6
7
8
9
10
root@k1-master01:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.28.1.1 0.0.0.0 UG 0 0 0 ens1f0
10.244.24.64 172.19.21.13 255.255.255.192 UG 0 0 0 tunl0
Linux에서는 "route -n" 명령으로 라우팅 테이블을 출력해 볼 수 있습니다. Gateway column이 "0.0.0.0" 으로 표시되는 것들이 Connected 입니다. Linux에서는 "route -n" 명령 외에 "ip route show" 명령을 이용해서도 라우팅 테이블 항목들을 아래와 같이 출력해 볼 수 있습니다.
1
2
3
4
5
6
7
8
9
root@k1-master01:~# ip route show
default via 172.18.1.1 dev ens1f0 proto static
10.244.24.64/26 via 172.19.21.13 dev tunl0 proto bird onlink
blackhole 10.244.108.0/26 proto bird
10.244.108.10 dev vethcbcf231e16d scope link
10.244.108.11 dev veth039a14621a0 scope link
10.244.112.192/26 via 172.19.21.11 dev tunl0 proto bird onlink
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.1.0/24 dev ens1f0 proto kernel scope link src 172.18.1.24
"route -n" 명령의 출력문에서 Gateway가 "0.0.0.0" 이었던 destination network에는 공통적으로 "scope link"가 적혀 있습니다. Linux에서 "man ip" 명령으로 scope에 대한 설명을 보면, scope 에 대해서 아래와 같이 설명하고 있습니다.
1
2
3
4
scope SCOPE_VAL
the scope of the destinations covered by the route prefix. SCOPE_VAL may be a number or a string from
the file/etc/iproute2/rt_scopes. If this parameter is omitted, ip assumes scope global for all gatewayed
unicast routes,scope link for direct unicast and broadcast routes and scope host forlocal routes.
"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을 설정하는 방법 - 라우터
그림1. 라우터와 라우터 연결
패킷트레이서에서 2911 IP 2대를 서로 연결하고, IP와 subnet은 설정하지 않은 상태에서 route table을 보면 아래 참조5와 같이 아무런 엔트리도 생성되어 있지 않습니다.
1
2
3
4
5
6
7
8
9
10
11
12
Router#show ip route
Codes: L -local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
*- candidate default, U - per-user static route, o - ODR
참조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에 설정되어 있는 것을 확인할 수 있습니다.
1
2
3
4
root@k1-master01:~# ip route show table local
local127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
local172.28.1.24 dev enp1s0 proto kernel scope host src 172.28.1.24
local172.29.21.6 dev enp6s0 proto kernel scope host src 172.29.21.6
참고로 쿠버네티스의 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에 각각 추가하였습니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
limcs@limcs-VirtualBox:~$ ifconfig enp0s9
enp0s9: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
참조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에 엔트리가 등록된 것을 볼 수 있습니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
limcs@limcs-VirtualBox:~$ ping 172.16.10.11-c 2
PING 172.16.10.11 (172.16.10.11) 56(84) bytes of data.
64 bytes from172.16.10.11: icmp_seq=1 ttl=64 time=0.045 ms
64 bytes from172.16.10.11: icmp_seq=2 ttl=64 time=0.061 ms
---172.16.10.11 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1023ms
rtt min/avg/max/mdev =0.045/0.053/0.061/0.008 ms
limcs@limcs-VirtualBox:~$ ping 172.16.10.12-c 2
PING 172.16.10.12 (172.16.10.12) 56(84) bytes of data.
64 bytes from172.16.10.12: icmp_seq=1 ttl=64 time=0.628 ms
64 bytes from172.16.10.12: icmp_seq=2 ttl=64 time=0.553 ms
---172.16.10.12 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
참조11 : 양쪽 VM 인터페이스에 IP와 subnet mask만 설정하고 ping 되나 보기
자기 자신 local 인터페이스 IP도 ping이 되고, 다른 VM IP로도 ping이 성공합니다. 라우터에서도 그랬었고, 지금 Linux VM 간에도 저희는 연결된 인터페이스에 IP와 subnet mask (또는 prefex length)를 설정했는데, routing table에Connected와Localroute 엔트리가 각각 생성되는 것을 확인 할 수 있었습니다.
Windows는 본 글에서 예를 들어 확인해 보지는 않았지만, Windows를 포함하여 다른 모든 IP 기기들도 routing table을 가지고 있고, 인터터페이스에 IP와 subnet mask를 설정하면,Connected와Local엔트리가 라우팅 테이블에 생성됩니다.
L2 연결은 MAC으로 통신한다는 의미가 아니랍니다
지금까지 두 대의 장비를 직접 케이블로 직결한 경우만 봐서 호~~옥시라도 오해하시는 분이 계실까봐서 안내 말씀 드립니다. (^^) L2 Switch를 통해서 연결되는 host들끼리는 동일 subnet 대역의 IP를 설정하고, subnet mask를 동일하게 설정 할 경우 모두 connected 라우팅 엔트리에 의해서 통신이 됩니다.
그림2. L2 switch에 연결된 host 들
그림2와 같이 하나의 2960 L2 switch에 라우터와 PC, 서버등 5대의 host들을 동일 subnet에 IP를 할당하고, subnet mask도 동일하게 255.255.255.0으로 설정을 해 주었습니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
Router2>show ip route
Codes: L -local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
*- candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.10.10.0/30 is directly connected, GigabitEthernet0/0
L 10.10.10.1/32 is directly connected, GigabitEthernet0/0
Router>ping 10.10.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max =0/0/1 ms
Router>ping 10.10.10.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max =0/0/1 ms
Router>ping 10.10.10.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max =0/0/1 ms
Router>ping 10.10.10.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.5, timeout is 2 seconds:
.!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max =0/0/1 ms
참조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 장비들은 라우터에서 직접전달이 됩니다.이게 매우 중요한 의미가 있는 대사입니다. 밑줄 쫘~~악!! ㅎ
그림3. 서로 다른 LAN을 라우터를 통해 연결
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Router2>show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
*- candidate default, U - per-user static route, o - ODR
참조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을 해 보겠습니다. 결과가 어떻게 바뀔까요?
10.10.11.2는 Router2에게는 직접 연결된 host이므로, 라우팅 테이블에 Connected 엔트리가 lookup 됩니다. Connectedhost 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 편으로 이야기가 이어집니다
