[오리뎅이의 라우팅 이야기 - 3] Connected - IP 네트워킹, 라우팅의 시작 - 3/3
오리뎅이의 라우팅 테이블 훔쳐보기안녕하세요? 오리뎅이입니다.
Connected 마지막 편입니다. 인터페이스에 IP와 subnet mask를 설정하면, 라우팅 테이블에 자동으로 Connected와 Local 엔트리가 생성되었었는데요. 이번에는 Static route 설정으로 connected를 알아 보겠습니다.
Static route로 만드는 Connected
Connected를 만드는 기술 그 두번째입니다. 밑장 빼기 기술 아닙니다. 사기가 아니라는 말씀. (^^), Static route 설정에서 nexthop 또는 gateway를 설정하지 않고, Interface만 지정해서 설정하는 방법으로 Static connected를 만들 수 있습니다. 실제 설정 예를 들어 설명하기에 앞서 각 OS에서 Static route 설정 방법을 확인해 보겠습니다.
|
예) ip route 10.1.2.0 255.255.255.0 10.1.1.2 25 // Old IOS 방식은 nexthop 또는 interface 중 1개만 가능 ip route 10.1.2.0 255.255.255.0 Gi0/1 25 // Old IOS 방식은 nexthop 또는 interface 중 1개만 가능 |
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
|
cs |
참조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에서로 모두 변경해 보겠습니다.
|
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
Router4(config)#ip route 10.10.12.0 255.255.255.252 GigabitEthernet 0/1
%Default route without gateway, if not a point-to-point interface, may impact performance
Router4(config)#ip route 10.10.13.0 255.255.255.0 GigabitEthernet 0/1
%Default route without gateway, if not a point-to-point interface, may impact performance
Router4(config)#exit
Router4#show 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 is directly connected, GigabitEthernet0/1
S 10.10.13.0/24 is directly connected, GigabitEthernet0/1
|
cs |
참조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 해 봤습니다. (^^)
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
C:\>ping 10.10.13.2
Pinging 10.10.13.2 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Reply from 10.10.13.2: bytes=32 time<1ms TTL=125
Ping statistics for 10.10.13.2:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
|
cs |
참조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.2 0 0060.70A6.4230 ARPA GigabitEthernet0/0
Internet 10.10.11.1 - 000C.8506.9702 ARPA GigabitEthernet0/1
Internet 10.10.13.2 0 0060.47EE.5301 ARPA GigabitEthernet0/1
|
cs |
참조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)
Internet address is 10.10.11.2/30
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
... 후략 ...
|
cs |
참조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를 각각 설정하였습니다.
|
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
Router7(config)#ip route 10.10.11.0 255.255.255.0 gigabitEthernet 0/0
%Default route without gateway, if not a point-to-point interface, may impact performance
Router7#show ip route
... 중략 ...
10.0.0.0/8 is variably subnetted, 3 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
S 10.10.11.0/24 is directly connected, GigabitEthernet0/0
Router7#ping 10.10.11.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.11.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Router7#show ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.10.10.1 - 0007.EC52.8801 ARPA GigabitEthernet0/0
---------------------------------------------------------------------------------------------
Router8#show ip route
... 중략 ...
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.10.11.0/24 is directly connected, GigabitEthernet0/0
L 10.10.11.1/32 is directly connected, GigabitEthernet0/0
Router8(config)#ip route 10.10.10.0 255.255.255.0 gigabitEthernet 0/0
%Default route without gateway, if not a point-to-point interface, may impact performance
Router8#show ip route
... 중략 ...
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C 10.10.11.0/24 is directly connected, GigabitEthernet0/0
L 10.10.11.1/32 is directly connected, GigabitEthernet0/0
S 10.10.10.0/24 is directly connected, GigabitEthernet0/0
Router8#ping 10.10.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Router8#show ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.10.11.1 - 0030.F20C.DE01 ARPA GigabitEthernet0/0
|
cs |
참조32 : Static connected로 서로 다른 subnet 대역간 ping이 될까요? - 패킷트레이스는 안되네요
패킷트레이서에서는 설정은 잘 들어가 지지만, 실제로 ping은 안되는군요. 되도록 구현을 안한 것 같습니다. Virtual Box Linux VM을 이용해서 linux box 실제 상황에서는 되는지 확인해 봤습니다.
|
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
|
limcs@limcs-VM10:~/Desktop$ ifconfig enp0s9
enp0s9: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.16.10.11 netmask 255.255.255.0 broadcast 0.0.0.0
ether 08:00:27:b9:6f:ff txqueuelen 1000 (Ethernet)
... 후략 ...
limcs@limcs-VM10:~/Desktop$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.2.2 0.0.0.0 UG 100 0 0 enp0s3
172.16.10.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s9
limcs@limcs-VM10:~/Desktop$ sudo ip route add 172.16.11.0/24 dev enp0s9
limcs@limcs-VM10:~/Desktop$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.2.2 0.0.0.0 UG 100 0 0 enp0s3
172.16.10.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s9
172.16.11.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s9
---------------------------------------------------------------------------------------------
limcs@limcs-VM11:~/Desktop$ ifconfig enp0s9
enp0s9: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.16.11.11 netmask 255.255.255.0 broadcast 0.0.0.0
ether 08:00:27:e1:df:51 txqueuelen 1000 (Ethernet)
... 후략 ...
limcs@limcs-VM11:~/Desktop$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.2.2 0.0.0.0 UG 100 0 0 enp0s3
172.16.11.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s9
limcs@limcs-VM11:~/Desktop$ sudo ip route add 172.16.10.0/24 dev enp0s9
limcs@limcs-VM11:~/Desktop$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.2.2 0.0.0.0 UG 100 0 0 enp0s3
172.16.10.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s9
172.16.11.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s9
|
cs |
참조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
rtt min/avg/max/mdev = 0.830/0.830/0.830/0.000 ms
limcs@limcs-VM10:~/Desktop$ sudo tcpdump -i enp0s9 -n host 172.16.11.11
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s9, link-type EN10MB (Ethernet), capture size 262144 bytes
20:11:56.814760 ARP, Request who-has 172.16.11.11 tell 172.16.10.11, length 28
20:11:56.815190 ARP, Reply 172.16.11.11 is-at 08:00:27:e1:df:51, length 46
20:11:56.815200 IP 172.16.10.11 > 172.16.11.11: ICMP echo request, id 1, seq 1, length 64
20:11:56.815516 IP 172.16.11.11 > 172.16.10.11: ICMP echo reply, id 1, seq 1, length 64
limcs@limcs-VM10:~$ arp 172.16.11.11
Address HWtype HWaddress Flags Mask Iface
172.16.11.11 ether 08:00:27:e1:df:51 C enp0s9
limcs@limcs-VM11:~$ sudo arp 172.16.10.11
Address HWtype HWaddress Flags Mask Iface
172.16.10.11 ether 08:00:27:b9:6f:ff C enp0s9
|
cs |
참조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.0 192.168.35.120 IF 9
확인!
C:\WINDOWS\system32>route add 12.13.14.0 mask 255.255.255.0 0.0.0.0 IF 9
확인!
C:\WINDOWS\system32>route print
===========================================================================
인터페이스 목록
13...00 05 9a 3c 7a 00 ......Cisco AnyConnect Secure Mobility Client Virtual Miniport Adapter for Windows x64
9...b8 ac 6f 1d 1e 36 ......Intel(R) 82567LM-3 Gigabit Network Connection
10...0a 00 27 00 00 0a ......VirtualBox Host-Only Ethernet Adapter
1...........................Software Loopback Interface 1
===========================================================================
IPv4 경로 테이블
===========================================================================
활성 경로:
네트워크 대상 네트워크 마스크 게이트웨이 인터페이스 메트릭
0.0.0.0 0.0.0.0 192.168.35.1 192.168.35.120 25
11.12.13.0 255.255.255.0 연결됨 192.168.35.120 26
11.12.13.255 255.255.255.255 연결됨 192.168.35.120 281
12.13.14.0 255.255.255.0 연결됨 192.168.35.120 26
12.13.14.255 255.255.255.255 연결됨 192.168.35.120 281
127.0.0.0 255.0.0.0 연결됨 127.0.0.1 331
127.0.0.1 255.255.255.255 연결됨 127.0.0.1 331
|
cs |
참조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일 일요일 저녁 수원에서 뒤뚱뒤뚱~~~~ [오리]
'오리뎅이의 라우팅 테이블 훔쳐보기' 카테고리의 다른 글
| [오리뎅이의 라우팅 이야기 - 4] Static Routing의 시작은 PC와 서버 (6) | 2020.12.31 |
|---|---|
| [오리뎅이의 라우팅 이야기 - 2] Connected - IP 네트워킹, 라우팅의 시작 - 2/3 (0) | 2020.12.07 |
| [오리뎅이의 라우팅 이야기 - 1] Connected - IP 네트워킹, 라우팅의 시작 - 1/3 (3) | 2020.12.06 |