이 게시물은 <킹 오브 네트워킹 (피터전)>을 공부한 내용을 바탕으로 작성됨.
슈퍼네팅
서브네팅 (Subnetting) 은 하나의 큰 네트워크를 여러 개의 작은 네트워크로 나누는 기법이었다.
슈퍼네팅(Supernetting)은 서브네팅의 반대 개념으로 여러 개의 작은 네트워크를 하나의 큰 네트워크로 묶어주는 개념으로, 주로 경로를 축약하기 위해 사용되기 때문에 경로축약 혹은 Route summarization 등으로 불리기도 한다.
위 그림에서 R2, R3 라우터에는 각각 4개의 interface가 연결되어 있다. (여러 Interface가 연결되어있는 라우터의 IP를 Gateway라고 한다. 따라서 이 경우 R2, R3의 IP 주소는 Gateway 주소가 된다.) 이때 R2, R3는 자신의 interface 중 하나가 down되면 이를 R1에게 통보하고, R1은 라우팅 테이블을 수정한다. Down 되었던 interface가 다시 사용 가능해지면 그 사실을 R1에게 통보하고, 또 라우팅 테이블을 수정한다.
만약 슈퍼네팅(경로축약) 개념이 없었다면 현재 인터넷에 할당된 IP 주소 수억 개가 전부 라우팅테이블에 담겨야 하며, host가 UP/DOWN 될 때마다 라우팅 테이블을 수정해야하는 참사가 발생할 것이다.
따라서 우리는 위 그림과 같은 슈퍼네팅을 사용한다. R2, R3는 자신과 연결되어 있는 interface들의 주소를 하나로 축약하여 R1에 전달한다. 이때 연결된 interface 중 일부만 down되는 경우에는 R1에 통보하지 않고, 4개 전부 다 down되는 경우에만 R1에게 자신에게 정보를 전송하지 말라는 통보를 전달한다. 즉 하나의 라우터에서 발생한 장애 정보가 전체 네트워크로 전송되어 라우터에 부하를 주는 것을 방지할 수 있다.
또한 라우팅 테이블 크기를 줄여 장애 발생시 상황파악이 간단하고 네트워크 관리가 한결 쉬워진다. 라우팅 테이블은 라우터의 DRAM에 저장되는데, 테이블 크기가 크면 라우터 성능이 떨어져 경로 탐색시간이 느려진다. 슈퍼네팅은 라우팅 테이블을 간소화하여 이러한 문제점들을 해결한다.
느슨한 축약 & Longest match rule
위 네트워크에서 R2는 자신이 알고있는 4개의 네트워크를 상세하게 광고하지 않고 192.1.0.0/16으로 광고한다. 즉, 192.1으로 시작하는 패킷은 전부 다 R2로 전송하라는 것이다. 이때 R1이 목적지 IP 주소가 192.1.3.1인 패킷을 수신하면 R1은 이를 R2가 아닌 R3으로 전송한다.
192.1.3.1은 R3의 목적지 주소인 192.1.3.0과 3옥텟 일치하지만 R2의 목적지 주소인 192.1.0.0과는 2옥텟 일치하기 때문이다. Logest match rule에 의하여 IP 주소가 길게 일치하는 쪽으로 전송한다.
만약 R1이 목적지 IP 주소가 192.1.4.1인 패킷을 수신하면 이는 R2로 전송된다. R3는 192.1.3 이라는 네트워크를 갖기 때문에 192.1.4.1은 이와 전혀 다른 네트워크이므로 R3에게 전달할 수 없기 때문에 고려대상이 되지 않는다. 반면 R2의 주소인 192.1.0.0/16은 192.1.4 주소를 포함할 수 있다.
이처럼 네트워크 구성에 따라 슈퍼네팅을 좀 더 느슨하게 (network part를 더 작게) 구성할 수 있다. 필요에 따라서 192.0.0.0/8처럼 더 느슨하게 구성할 수도 있다.
show와 debug
위와 같은 네트워크가 있다고 하자. 라우터는 기본적으로 (라우팅 프로토콜을 사용하지 않았다면) 자신과 직접 연결되어 있는 네트워크의 주소만 알고 있다. 지금 이 상태에서는 R1와 R3가 서로 직접 연결된 것이 아니므로 통신이 불가능하다. 사용자가 직접 라우터에 경로를 지정해주는 '정적경로 설정'을 수행해보자.
R1(config)#ip route 1.1.0.0 255.255.0.0 1.1.12.2
R2(config)#ip route 1.1.10.0 255.255.255.0 1.1.12.1
R2(config)#ip route 1.1.30.0 255.255.255.0 1.1.23.3
R3(config)#ip route 1.1.0.0 255.255.0.0 1.1.23.2
- R1에서 목적지가 1.1.0.0/16인 패킷들은 1.1.12.2 (R2)로 보낸다.
- R2에서 목적지가 1.1.10.0/24인 패킷들은 1.1.12.1 (R1)로 보낸다.
- R2에서 목적지가 1.1.30.0/24인 패킷들은 1.1.23.3 (R3)로 보낸다.
- R3에서 목적지가 1.1.0.0/16인 패킷들은 1.1.23.2 (R2)로 보낸다.
R1#show ip route
(생략)
1.0.0.0/8 is variably subnetted, 5 subnets, 3 masks
S 1.1.0.0/16 [1/0] via 1.1.12.2
C 1.1.10.0/24 is directly connected, GigabitEthernet0/0
L 1.1.10.1/32 is directly connected, GigabitEthernet0/0
C 1.1.12.0/24 is directly connected, Serial0/1/0
L 1.1.12.1/32 is directly connected, Serial0/1/0
R1의 라우팅 테이블을 확인하면 위와 같다. S 1.1.0.0/16은 1.1.23.0/24와 1.1.30/24가 느슨하게 축약된 형태라고 볼 수 있다. (직접 설정해준 것이다.) 또한 1.1.0.0/16 네트워크로 향하는 패킷들은 전부 1.1.12.2 (R2)에 전송한다.
이제 debug를 해보자. debug ip packet 명령어는 라우터의 CPU가 처리하는 모든 IP 패킷을 실시간으로 보여준다.
R1#debug ip packet
Packet debugging is on
R1#ping 1.1.12.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.12.2, timeout is 2 seconds:
IP: tableid=0, s=1.1.12.1 (local), d=1.1.12.2 (Serial0/1/0), routed via RIB
IP: s=1.1.12.1 (local), d=1.1.12.2 (Serial0/1/0), len 128, sending
!
IP: tableid=0, s=1.1.12.2 (Serial0/1/0), d=1.1.12.1 (Serial0/1/0), routed via RIB
IP: s=1.1.12.2 (Serial0/1/0), d=1.1.12.1 (Serial0/1/0), len 128, rcvd 3
debug ip packet 명령어로 디버깅 상태로 들어간 후 트래픽을 발생시키기 위해 ping으로 패킷을 전송한다. 디폴트 설정에 의해 5개의 패킷을 목적지에 전달하고, 2초안에 응답이 오면 !로 표시한다. (실제 출력창에서는 위 메시지가 반복해서 5번이나 떴는데 스크롤 압박이라서 하나만 남겨뒀다.)
출력을 해석하면 다음과 같다.
- s=1.1.12.1 ☞ Source 주소, 출발지 IP 주소 (R1)
- d=1.1.12.2 ☞ Destination 주소, 목적지 IP 주소 (R2)
- len 128 ☞ 전송하는 패킷의 길이가 128 Byte이다.
- sending ☞ R1에서 해당 패킷을 전송한다.
- rcvd ☞ received로, ping을 보냈던 목적지로부터 다시 패킷을 돌려받았다는 의미이다.
R1(config)#no ip route 1.1.0.0 255.255.0.0 1.1.12.2
라우팅 테이블에서 특정 주소를 지우고 싶을때는 이렇게 한다. R1의 라우팅 테이블에서 R2의 주소를 지운 것이다. 이때 R1에서 R3으로 ping을 때려보자.
R1#ping 1.1.30.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.30.3, timeout is 2 seconds:
IP: s=0.0.0.0 (local), d=1.1.30.3 len 128, unroutable
R1#.
IP: s=0.0.0.0 (local), d=1.1.30.3 len 128, unroutable
R1#.
IP: s=0.0.0.0 (local), d=1.1.30.3 len 128, unroutable
R1#.
IP: s=0.0.0.0 (local), d=1.1.30.3 len 128, unroutable
R1#.
IP: s=0.0.0.0 (local), d=1.1.30.3 len 128, unroutable
R1#.
Success rate is 0 percent (0/5)
ping이 전부 다 실패했다. unroutable은 목적지 라우터 주소가 송신 라우터의 라우팅 테이블에 존재하지 않을 때 나타나는 메시지이다. R1➜R2➜R3 방향으로 이어져 있는데, R1➜R2부터 끊어진 상태라 위 같은 에러가 발생하는 것이다.
이번에는 R1➜R2는 다시 연결해두고 R2➜R3을 끊은 채 (R2의 라우팅 테이블에서 R3주소 삭제) R1➜R3으로 ping을 때려보자.
R1(config)#ip route 1.1.0.0 255.255.0.0 1.1.12.2
R2(config)#no ip route 1.1.30.0 255.255.255.0 1.1.23.3
R1#ping 1.1.30.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.30.3, timeout is 2 seconds:
IP: tableid=0, s=1.1.12.1 (local), d=1.1.30.3 (Serial0/1/0), routed via RIB
IP: s=1.1.12.1 (local), d=1.1.30.3 (Serial0/1/0), len 128, sending
U
IP: tableid=0, s=1.1.12.2 (Serial0/1/0), d=1.1.12.1 (Serial0/1/0), routed via RIB
IP: s=1.1.12.2 (Serial0/1/0), d=1.1.12.1 (Serial0/1/0), len 156, rcvd 3
Success rate is 0 percent (0/5)
여지껏 본 것과 조금 다른 결과가 출력되었다. R1➜R3으로 ping을 때려서 패킷을 보냈지만 R3이 아닌 R2로부터 응답이 돌아왔다. (rcvd의 source가 R3가 아닌 R2인 것을 확인할 수 있다.) R3까지는 접근할 수 없으니 R2에서 응답이 돌아온 것이다.
R2(config)#ip route 1.1.30.0 255.255.255.0 1.1.23.3
R3(config)#no ip route 1.1.0.0 255.255.0.0 1.1.23.2
R2에 R3 주소를 다시 입력해주고, 이번에는 R3➜R1 경로로 향하는 라우팅 테이블을 R3에서 삭제해본다. 그 후 R1➜R3 방향으로 ping을 때려보면 다음과 같은 결과를 얻는다.
R1#ping 1.1.30.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.30.3, timeout is 2 seconds:
IP: tableid=0, s=1.1.12.1 (local), d=1.1.30.3 (Serial0/1/0), routed via RIB
IP: s=1.1.12.1 (local), d=1.1.30.3 (Serial0/1/0), len 128, sending
Success rate is 0 percent (0/5)
결과는 당연히 실패! sending만 존재하고 rcvd는 존재하지 않는다. R1➜R3 방향으로 패킷을 보내는 데는 성공했지만, R3➜R1 방향으로 응답을 되돌려 보내는 것은 실패했다는 것이다.
여기서는 ping을 전송할 때 debug ip packet을 이용하여 debug 메시지들을 확인했다. ping을 5개 쏘면서 각각 패킷에 대한 상태를 출력해주었는데, 이러한 디버깅 명령어는 장비에 과도한 트래픽을 유발하므로 네트워크 장애발생 시 우선 show 명령어 등을 통해 네트워크 이상유무를 파악하는 것이 좋다. 가급적이면 debug는 최후의 수단으로 사용하자.
추가로, 디버그는 라우터나 스위치의 CPU가 처리하는 패킷들만 확인할 수 있다. 처리속도를 빠르게 하기 위해 대부분의 패킷들은 라우터와 스위치를 통과할 때 CPU를 거치지 않고 캐시(cache)에서 처리되는데, 이러한 경우에는 디버깅해도 출력이 불가능하다. 따라서 꼭 디버깅 해야하는 패킷이 있다면 interface config 모드에서 no ip route-cache 명령어를 사용하여 패킷들이 CPU만을 거쳐 처리되도록 한 후에 디버깅을 진행한다.
R1#show debugging
Generic IP:
IP packet debugging is on
R1#no debug ip packet
Packet debugging is off
show debugging 명령어를 통하여 현재 실행중인 debugging을 확인하고, no debug ip packet을 통하여 디버깅을 꺼주었다. un all 명령어를 입력하면 실행중인 모든 디버깅을 종료한다.
CDP
CDP(Cisco Discovery Protocol)은 이전에도 한 번 다룬적 있었다. 이름에 Cisco가 들어가는 것 부터 티가 나듯이, 이 프로토콜은 시스코 장비에서만 사용이 가능하며 자신과 인접한 시스코 장비가 있는지 알려주는 용도이다. CDP는 스위치와 같이 접속된 장비가 많을 때 특히 유용하다.
LLDP(Link Layer Discovery Protocol)은 CDP처럼 자신의 정보를 인접 장비에게 알려주는 용도이다. 다만 차이점이 있다면 CDP는 시스코 고유의 프로토콜인 반면 LLDP는 IEEE 802.1AB에서 규정한 표준 프로토콜이다.
R2#show cdp interface
Vlan1 is administratively down, line protocol is down
Sending CDP packets every 60 seconds
Holdtime is 180 seconds
GigabitEthernet0/0 is administratively down, line protocol is down
Sending CDP packets every 60 seconds
Holdtime is 180 seconds
GigabitEthernet0/1 is administratively down, line protocol is down
Sending CDP packets every 60 seconds
Holdtime is 180 seconds
show cdp interface 명령어를 입력하면 해당 라우터의 인터페이스들 중에서 CDP 사용가능한 인터페이스들을 출력한다. 사실 전부 다 가능한 것으로 출력됐지만 너무 길어서 생략했다.
R2#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID Local Intrfce Holdtme Capability Platform Port ID
R1 Ser 0/1/0 164 R C2900 Ser 0/1/0
R3 Ser 0/1/1 164 R C2900 Ser 0/1/1
show cdp neighbors 명령어를 입력하면 해당 장비와 연결되어있는 시스코 장비들을 출력한다.
LLDP
이번에는 위와 같은 네트워크를 구성한다.
R1(config)#interface gigabitEthernet 0/0
R1(config-if)#ip address 1.1.12.1 255.255.255.0
R1(config-if)#no shut
R2(config)#interface gigabitEthernet 0/0
R2(config-if)#ip address 1.1.12.2 255.255.255.0
R2(config-if)#no shut
R2(config)#interface gigabitEthernet 0/1
R2(config-if)#ip address 1.1.23.2 255.255.255.0
R2(config-if)#no shut
R3(config)#interface gigabitEthernet 0/0
R3(config-if)#ip address 1.1.23.3 255.255.255.0
R3(config-if)#no shut
show lldp 명령어를 사용하여 LLDP가 작동하고 있는지 여부를 확인해보자.
R2#show lldp
% LLDP is not enabled
아직 LLDP가 설정되어있지 않으므로 R1, R2, R3 모든 장비에 대해 LLDP를 활성화시키자.
R1(config)#lldp run
R2(config)#lldp run
R3(config)#lldp run
이렇게 활성화하고 난 후 다시 show lldp 명령어를 입력해보자.
R2#show lldp
Global LLDP Information:
Status: ACTIVE
LLDP advertisements are sent every 30 seconds
LLDP hold time advertised is 120 seconds
LLDP interface reinitialisation delay is 2 seconds
이번에는 무언가 떴다.
LLDP advertisements are sent every 30 seconds ➜ LLDP는 기본적으로 30초마다 자신의 정보를 이웃에게 전달한다.
LLDP hold time advertised is 120 seconds ➜ 정보를 연속해서 120초간 수신하지 못하면 상대방의 LLDP 정보를 삭제한다. 이웃 끊음~ 님 삭제요
LLDP interface reinitialisation delay is 2 seconds ➜ LLDP interface가 매 2초마다 업데이트된다.
LLDP를 이용하여 인접 장비를 살펴보자.
R2#show lldp neighbors
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID Local Intf Hold-time Capability Port ID
R1 Gig0/0 120 R Gig0/0
R3 Gig0/1 120 R Gig0/0
R2는 자신과 연결된 장비인 R1, R3를 잘 인식하고 있음을 알 수 있다. 여기서 Capability는 상대 장비의 기능을 의미하는데, R은 Router, B는 Bridge를 의미한다. R, B 외에도 여러 값을 가질 수 있다.
R2#show LLDP neighbor detail
------------------------------------------------
Chassis id: 0000.0C89.3701
Port id: Gig0/0
Port Description: GigabitEthernet0/0
System Name: R1
System Description:
Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.1(4)M4, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2012 by Cisco Systems, Inc.
Compiled Thurs 5-Jan-12 15:41 by pt_team
Time remaining: 90 seconds
System Capabilities: R
Enabled Capabilities: R
Management Addresses - not advertised
Auto Negotiation - supported, enabled
Physical media capabilities:
1000baseT(FD)
1000baseT(HD)
Media Attachment Unit type: 10
Vlan ID: 1
------------------------------------------------
Chassis id: 0001.42E6.4201
Port id: Gig0/0
Port Description: GigabitEthernet0/0
System Name: R3
System Description:
Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.1(4)M4, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2012 by Cisco Systems, Inc.
Compiled Thurs 5-Jan-12 15:41 by pt_team
Time remaining: 90 seconds
System Capabilities: R
Enabled Capabilities: R
Management Addresses - not advertised
Auto Negotiation - supported, enabled
Physical media capabilities:
1000baseT(FD)
1000baseT(HD)
Media Attachment Unit type: 10
Vlan ID: 1
Total entries displayed: 2
show lldp neighbors detail을 입력하면 인근 장비들에 대한 디테일한 정보를 알 수 있다.
핑 Ping
Ping은 PC, 서버, 라우터, 스위치 등 특정 장비의 동작 상태를 원격에서 확인하기 위해 사용하는 명령어이다. 핑은 ICMP 프로토콜을 이용하여 동작한다.
ICMP(Internet Control Message Protocol)는 PC, 서버, 라우터, 스위치 등 네트워크에 연결되어 있는 장비의 동작 상태를 확인할 때 사용하는 포로토콜이다. ICMP 패킷의 헤더에는 다음 표와 같은 type, code 필드가 존재하며 이 값들을 이용하여 특정 작업을 요청 / 응답한다.
예를들어 이제까지 사용했던 ping 명령어를 사용하여 IP 주소가 1.1.30.3인 장비가 제대로 동작중인지 확인하기 위해서 ping 1.1.30.3이라는 명령어를 사용한다고 해보자. 이것은 type 8, code 0의 echo request (Ping request)로 설정된 ICMP 패킷을 보내는 것이다. 이때 수신측 (1.1.30.3)에서 Ping request를 정상적으로 수신했다면 type 0, code 0의 echo reply (Ping reply) ICMP 패킷을 전송측에 보내 응답한다.
만약 라우팅 테이블에 1.1.30.3 정보가 없다면 type 3, code 0의 network unreachable ICMP를 받게된다.
표준 핑
이제껏 사용했던 핑이 표준 핑이다. 예를 들어 R1에서 R3에 접속된 IP 주소인 1.1.30.3 까지의 통신을 확인하는 방법은 다음과 같다. (실습 네트워크 1에서 진행한다.)
R1#ping 1.1.30.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.30.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/12/17 ms
R1과 R3경로가 잘 연결되어 있으므로 5개의 핑이 전부 다 정상적으로 전송되었다.
핑 결과 코드를 표로 살펴보면 다음과 같다.
| 코드 | 의미 |
| ! | 핑 성공 |
| . | 지정시간 내 핑이 돌아오지 않음 (time out) |
| U | 목적지 도달 불가 |
| Q | 소스퀜치 (목적지가 혼잡함) |
| M | 전송도중 패킷 분할이 필요하지만 분할이 불가능함 |
| ? | 알 수 없는 패킷 타입임 |
핑 패킷을 전송하는 것을 "핑을 때린다"라고 하고, 핑이 실패하는 것을 "핑이 빠진다"라고 한다.
확장 핑
확장 핑(Extended Ping)은 핑을 때릴 때 출발지 주소, 패킷 개수, 패킷 크기를 지정하여 때리는 것이다. 표준핑은 유저모드에서도 가능한 반면 확장 핑은 관리자 모드에서만 가능하다. Costumization된 핑을 때리고 싶을 때 사용한다.
R1#ping
Protocol [ip]:
Target IP address: 1.1.30.3
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: yes
Source address or interface: 1.1.10.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.30.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.10.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/11/15 ms
- Protocol [ip] : 핑에 사용할 L3 layer 프로토콜을 지정한다. Default는 IP이며, 기본값을 사용하려면 엔터를 누른다.
- Target IP address : 목적지 주소 입력
- Repeat count [5] : 연속해서 몇 개의 핑 패킷을 보낼지 지정한다.
- Datagram size [100] : 핑에 사용할 패킷의 길이 지정
- Timeout in second [2] : 패킷이 돌아와야 하는 최대 시간 지정. 지연이 심한 환경이거나 네트워크 규모가 큰 경우에는 이 값을 크게 지정해주어야 핑이 수행되는 것을 확인할 수 있다.
- Extended commands [n] : 확장 명령어를 사용할지 여부를 지정한다. 바로 밑에서 설명하는 조건들을 정의하기 위해서는 y로 입력하여 확장 핑 모드로 진입해야 함.
- Source address or interface : 핑의 출발지 주소. 여기에 출발지 IP 주소를 입력하는 것을 소스 핑(Source ping)이라고 한다. 출발지를 지정해주지 않으면 핑 패킷이 빠져나가는 interface의 주소가 출발지 주소로 지정된다. 또한, 이 출발지 주소는 핑이 다시 돌아올 때 목적지 주소로 사용된다. 특정 interface로부터 핑을 출발시키고 싶으면 IP 주소 대신 해당 interface 이름을 적어주면 된다.
- Type of service [0] : IP 패킷의 TOS(Type of Service)를 지정한다. 일반적으로 디폴트를 사용.
- Set DF bit in IP header? [no] : 라우터, 스위치 등의 통신 장비들은 interface를 통하여 전송할 수 있는 최대 데이터 길이가 정해져 있는데, 이를 MTU (Maximum Transmission Unit, 최대 전송 단위)라고 한다.
특정 interface의 MTU는 show interface를 통해 다음과 같이 확인할 수 있다.
R1#show interfaces Serial 0/3/0
Serial0/3/0 is administratively down, line protocol is down (disabled)
Hardware is HD64570
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
생략...
여기서는 MTU가 1500 Bytes로 설정되어 있다. 만약 MTU 사이즈보다 큰 IP 패킷을 해당 interface를 통하여 전송해야하는 경우에는 IP header의 DF(Don't Fragment, 분할 불가) 필더를 확인해야 한다. DF가 default인 no로 설정되어 있다면 패킷은 분할되어 전송된다. 반면 DF를 yes로 설정하면 패킷이 전송되다가 그 패킷보다 크기가 작은 MTU를 갖는 interface를 만나면 패킷은 곧바로 폐기된다.
- Data pattern [0xABCD] : 핑 패킷에 사용될 데이터 패턴을 지정한다. default로 패킷의 데이터 부분에 '0xABCD'라는 데이터를 반복적으로 채워 전송한다. 0x는 그 뒤의 문자들이 16진수임을 의미하므로, 결과적으로 2진수 1010 1011 1100 1101 이라는 데이터가 반복되어 전송된다.
- Loose, Strict, Record, Timestamp, Verbose [none]
- Loose : 일반적으로 핑 패킷의 전송 경로는 해당 라우터의 테이블에 따른다. 하지만 이 옵션을 사용하면 핑 패킷이 지나갈 경로를 미리 설정할 수 있다. 하지만 직접 지정해준 경로를 거칠 수 없으면 당연히 핑은 실패한다. 라우팅 경로와 다른 경로에 핑을 때리고 싶을 때 유용하게 사용된다.
- Loose, Strict, Record, Timestamp, Verbose [none] : Loose
- Source route : 1.1.23.3 (최종 목적지만 입력)
- Strict : Loose와 비슷하며, 여기서는 목적지로 가는 경로를 지정할 때 생략하지 말고 모두 적어주어야 한다.
- Loose, Strict, Record, Timestamp, Verbose [none] : Strict
- Source route : 1.1.12.2 1.1.23.3 (목적지로 가는 경로 내 있는 모든 주소 입력)
- Record : 목적지까지 가는 경로만을 알려주는 trace route와는 달리 Record를 사용하면 왕복 경로를 모두 알려주므로, 핑 패킷의 왕복 경로를 확인할 때 유용하다.
- Timestamp : 목적지까지 가는 경로 중에 있는 라우터에 설정되어 있는 시간을 표시
- Verbose : 핑 결과를 상세하게 표시할지 여부 설정. 사용하지 않는 경우에는 핑 성공 유무만 표시한다.
- Loose : 일반적으로 핑 패킷의 전송 경로는 해당 라우터의 테이블에 따른다. 하지만 이 옵션을 사용하면 핑 패킷이 지나갈 경로를 미리 설정할 수 있다. 하지만 직접 지정해준 경로를 거칠 수 없으면 당연히 핑은 실패한다. 라우팅 경로와 다른 경로에 핑을 때리고 싶을 때 유용하게 사용된다.
- Sweep range of sizes [n] : 패킷의 크기를 증가시키면서 핑을 할 때 사용한다. 전송경로의 MTU를 확인할 때 유용하며, 전송경로의 interface들의 DF를 yes로 설정한 후 (Set DF bit in IP header? [no] : yes)에 진행해야 한다. no로 설정하면 패킷이 아무리 커도 이를 분할하여 전송하므로 막힘없이 전송 잘 된다. 패킷의 최소 크기와 최대 크기 및 증가폭을 지정해주면 패킷의 크기를 차례로 증가시키면서 핑을 진행한다.
Record랑 Sweep range of sizes 실습 해보고싶은데 'This version of Cisco Packet Tracer does not support this option.' 라는 메시지가 뜬다.. 내가 쓰는 패킷 트레이서 최신버전 아니었던가?
트레이스 루트
트레이스 루트 (Trace Route)는 목적지까지 가는 경로를 알고자 할 때 사용하는 명령어이다. 네트워크 장애가 발생했을 떄 트레이스 루트를 이용하여 목적지까지 가는 경로 중 어떤 라우터까지 정상적으로 작동하는 지 알 수 있다.
R1#traceroute 1.1.30.3
Type escape sequence to abort.
Tracing the route to 1.1.30.3
1 1.1.12.2 14 msec 2 msec 0 msec
2 1.1.23.3 2 msec 1 msec 13 msec
Trace route라는 이름 그대로 경로를 추적한다. R1➜R2➜R3으로 핑이 전송되는 과정에 있는 라우터 R2, R3이 출력된 것을 알 수 있다.
트레이스루트 동작방식
트레이스루트는 경로탐지를 위해 UDP(User Datagram Protocol)를 사용하고, 응답으로는 ICMP를 이용한다.
- UDP 패킷에 최종 목적지 IP 주소, TTL(Time to Live) 값 1, 잘 사용하지 않는 UDP port number를 설정한 후 목적지 방향으로 전송한다.
- TTL 값이 1이므로 UDP 패킷을 받은 인접 라우터는 더 이상 해당 패킷을 목적지로 보내지 못하며, 이 사실을 출발지 IP 주소로 통보한다. 이때 'TTL 값이 만료되어 더 이상 패킷을 다른 곳으로 전송할 수 없다.'의 의미를 갖는 ICMP type 11, code 0 패킷을 이용한다. 이를 통해 트레이스 루트를 시작한 라우터는 목적지로 가는 첫 번째 라우터의 IP 주소를 알게 되는 것이다.
- TTL 값을 1 증가시켜서 위 과정을 반복한다. 그러면 두 번째 라우터까지 도달하고, 두 번째 라우터 역시 ICMP를 보낸다. 그러면 트레이스 루트를 시작한 라우터는 목적지로 가는 두 번째 라우터의 IP 주소도 알게 된다.
- 이런식으로 TTL 값을 1씩 증가시키며 반복하면서 경로에 존재하는 라우터들이 출발지로 보내는 ICMP 패킷에 담긴 IP 주소를 확인하여 경로를 기록해 나간다. 패킷이 마침에 목적지에 도착하면 해당 라우터는 UDP port number가 사용하지 않는 것임을 확인하고 포트 도달 불가(ICMP type 3, code 3) 패킷을 전송한다. 출발지에서 이 패킷을 수신하면 트레이스 루트가 종료된다.
'네트워크' 카테고리의 다른 글
| [네트워크] 28. ARP, 트랜스패런트 브리징 (1) | 2024.01.11 |
|---|---|
| [네트워크] 27. 텔넷, SSH, 이더넷 프레임, L123 장비들 (0) | 2024.01.10 |
| [네트워크] 25. 클라우드, IPv6 (1) | 2024.01.06 |
| [네트워크] 24. ISDN, 무선 네트워킹, 무선 보안표준 (1) | 2024.01.05 |
| [네트워크] 23. HDLC, PPP, 프레임 릴레이 (0) | 2024.01.02 |
