2007년 12월 20일 목요일

Why 3-way Handshake is needed for TCP?

A Connection-Oriented Protocol, such as TCP, exchanges Control Information(called a Handshake) with the remote computer to verify that it is ready to receive data before sending it. When the handshaking is successful, the computers are said to have established a connection.
In contrast, a Connectionless Protocol, such as IP, doesn't exchange Control Information to establish an end-to-end connection before transmitting data.

TCP Connection Establishing: 3-Way Handshake

TCP Connection이 성립되기 위해서는 먼저 Server가 Connection을 수락할 준비상태에 들어가 있어야 하는데, 이를 'Passive open'이라 한다. Client는 Server로의 Connection Establishment를 요구하며, 이것은 'Active open'이다.

사용자 삽입 이미지

1. SYN Segment(Client의 Synchronization Information 전송): Client는 Source Port에 자신을 나타내는 Port Number를 넣고, Destination Port에는 Server를 가리키는 Port Number를 넣는다.(그림에서 Destination Port가 23이므로 Telnet Server로 Connection Request하는 경우이다). Sequence Number에는 Client의 ISN(Initialization Sequence Number)를 넣고, Acknowledgment Number는 0을 넣고, Flag는 SYN bit를 1로 설정하여 전송한다.

2. SYN+ACK Segment(Server의 Synchronization Information 전송 + SYN Segment 수신 확인): Server는 Source Port에 자신을 나타내는 Port Number를 넣고, Destination Port에는 Sender 나타내는 Port Number를 넣는다.(Telnet Server를 예로 들고 있으므로 Source Port에는 23번이 들어간다, Sender의 Port Number는 첫번째 단계에서 수신한 SYN Segment에서 있다. 결과적으로 보면 Sender가 보낸 SYN Segment에서 Source Port와 Destination Port가 서로 바뀌어 들어간 것과 같다). Sequence Number에는 Server의 ISN를 넣고, Acknowledgment Number에는 “Client의 ISN + 1”의 값을 넣고, Flag는 SYN 와 ACK bit를 모두 1로 설정하여 전송한다.

3. ACK Segment(SYN Segment 수신 확인): Client는 첫번째 단계와 동일하게 Source Port와 Destination Port를 설정하고, Acknowledgment Number에는 “Server의 ISN + 1”의 값을 넣고, Flag는 ACK bit를 1로 설정하여 전송한다.

TCP is a connection oriented protocol. It has to establish a connection between two parties (host and server) before it can start transmitting data (as opposed to for example, IP). The 3-way handshake verifies that both ends are connected properly.


[Related Articles]
[DOC] AMAN2002를 활용한 TCP 연결 설정과 연결 종료 분석 by NetMan
2007/11/08 - [Network] - [scrap] TCP/IP Sliding Window
2007/10/23 - [Network/Network Story] - Network Selfstudy
2007/10/21 - [Network/cisco.com] - [cisco.com] Understanding TCP/IP
2007/09/28 - [Network/Link for Network] - [Link] TCP/IP의 이해(IP Address & Subnet)

2007년 12월 15일 토요일

Dynamips / Dynagen Tutorial

Dynamips / Dynagen Tutorial
Documentation Revision 1.11.2

한 블로그에서 Tutorial의 번역판을 우연히 찾게 되었다.
번역이 불완전하긴 하지만 원본의 문서가 양이 많아서 읽어보려면 상당한 시간이 걸리므로
우선은 시간을 좀 절약할 수 있지 않을까 해서 스크랩해둔다.
이것은 Documentation Revision 1.9.1을 번역한 것이다.

more..


[Related Article]
2007/12/17 - [Network/Router Simulation] - Dynamips / Dynagen Tutorial 번역/요약
2007/12/13 - [Network/Router Simulation] - Cisco 7200 Simulator - Dynamips

2007년 12월 13일 목요일

Cisco 7200 Simulator - Dynamips

[Project Homepage]

Introduction

The Project was started in August 2005 to emulate a Cisco 7200 on a traditional PC.
Now, it also supports Cisco 3600 series (3620, 3640 and 3660), 3700 series (3725, 3745) and 2600 series (2610 to 2650XM, 2691).

The goals of this emulator are mainly:

    * To be used as a training platform, with software used in real world.
    * Test and experiment the numerous and powerful features of Cisco IOS.
    * Check quickly configurations to be deployed later on real routers.

Of course, this emulator cannot replace a real router: you should be able to get a performance of about 1 kpps (depending on your host machine), to be compared to the 100 kpps delivered by a NPE-100 (the oldest NPE model). So, it is simply a complementary tool to real labs for administrators of Cisco networks or people wanting to pass their CCNA/CCNP/CCIE exams.

Current status

At this time, the emulator I have programmed is able to boot a large number of Cisco IOS releases available for the 7200, 3600, 3700 and 2600 platforms, including the latest 12.2S and 12.4T.

The following devices are emulated in the current release (0.2.7):

  • MIPS64 and PowerPC CPU processors. The instruction sets are not completely emulated now (MIPS FPU support is lacking, TLB support is not finished and other minor things), but it is sufficient for IOS ;
  • DRAM and Packet SRAM memory ;
  • Non-Volatile Memory (NVRAM) ;
  • Signetics SCN 2681 DUART (C7200 Console and AUX ports) ;
  • National Semiconductors NS16552 DUART (C3600/C3700/C2600 Console and AUX ports) ;
  • Dallas DS1620 Temperature Sensors and Voltage Sensors, allowing the C7200 Environmental Monitor to work properly ;
  • NMC93C46 Serial EEPROM ;
  • Bootflash of 8 Mb (Intel 28F016SA) ;
  • Galileo GT64010/GT64120/GT96100 PCI controllers, DEC 21x50 PCI bridges and so ;
  • PCMCIA ATA disk emulation (C7200 only at this time).
  • ...

The following Cisco 7200 Port Adapters (PA) are currently supported:

  • FastEthernet cards "C7200-IO-FE" and "PA-FE-TX" based on DEC21140 chip
  • FastEthernet cards "C7200-IO-2FE" and "PA-2FE-TX" based on Intel i8254x chips
  • GigabitEthernet cards "C7200-IO-GE-E" and "PA-GE" based on Intel i8254x chips
  • Ethernet cards "PA-4E" and "PA-8E" based on AMD Am79c97x chips
  • ATM card "PA-A1" based on Texas Instruments Tneta1570 chip
  • Serial cards "PA-4T+" and "PA-8T"
  • POS (Packet over SONET) card "PA-POS-OC3" (experimental, only works with recent IOS images)

The following Cisco 3600 (3620,3640,3660) Network Modules (NM) are currently supported:

  • Ethernet cards: "NM-1E", "NM-4E" and "NM-1FE-TX", all based on AMD Am79c97x chips
  • Ethernet switching module: "NM-16ESW"
  • Serial card "NM-4T"

The following Cisco 2691/3725/3745 Network Modules (NM) are currently supported:

  • FastEthernet cards: "NM-1FE-TX"
  • Ethernet switching module: "NM-16ESW"
  • Serial card "NM-4T"

The following Cisco 2600 Network Modules (NM) are currently supported:

  • Ethernet cards: "NM-1E", "NM-4E" and "NM-1FE-TX"
  • Ethernet switching module: "NM-16ESW"

Lab simulation / "Hypervisor" mode

It is now possible to run the emulator as an "Hypervisor" to start and control many virtual router instances simultaneously.

Dynagen, is a front-end (written in Python) that makes lab simulation with the hypervisor very easy: it uses an INI-like configuration file to provision Dynamips emulator networks.
It takes care of specifying the right port adapters, generating and matching up those pesky NIO descriptors, specifying bridges, frame-relay, ATM switches, etc.
It also provides a management CLI for listing devices, suspending and reloading instances, etc.
You can also distribute virtual instances across different servers to set up complex labs. To begin with Dynagen, you can consult this very complete tutorial.

Dynagui is a graphical front-end. It uses Dynagen to communicate with the hypervisor.


How to use it ?

Very important remark: by default, an instance will take 100% of the host CPU.
To avoid this, please read the "idle-pc" section in the README.

Emulated hardware
The emulator currently supports the following platforms:
   - Cisco 7200 (NPE-100 to NPE-400)
   - Cisco 3600 (3620, 3640 and 3660)
   - Cisco 2691
   - Cisco 3725
   - Cisco 3745
   - Cisco 2600 (2610 to 2650XM)
   - Cisco 1700 (1710 to 1760)

By default, a Cisco 7206VXR with NPE-200 (256 Mb of DRAM) is emulated.
To emulate another platform, use the "-P" command line option
(for example, "-P 3725" or "-P 3600").

For the 7200, you can change the NPE type with the "-t" option.
It is possible to select "npe-100", "npe-150", "npe-175", "npe-200", "npe-225", "npe-300" and "npe-400". The "npe-g1" is not working.

For the 3600, a 3640 with 128 Mb is emulated by default.
You can change this with the "-t" option and by specifying "3620" or "3660".
Don't forget to set the chassis type depending on your IOS image, a c3660 image will not run on c3640 hardware and vice-versa.

Remark: PCMCIA card emulation is not supported yet with Cisco 3600.

Command Line Options details
--idle-pc <pc>
:
The "idle PC" feature allows you to run a router instance without having a 100% CPU load. This implies that you can run a larger number of instances per real machine.
To determine the "idle PC", start normally the emulator with your Cisco IOS image, and a totally IOS empty configuration (although not mandatory, this will give better results).
When the image is fully booted, wait for the "Press RETURN to get started!" message prompt, but do not press Enter key.
Wait about 5 seconds, then press "Ctrl-] + i".
Some statistics will be gathered during 10 seconds.
At the end, the emulator will display a list of possible values to pass to the "--idle-pc" option.
You may have to try some values before finding the good one.
To check if the idle PC value is good, just boot the Cisco IOS image, and check your CPU load when the console prompt is available.
If it is low, you have found a good value, keep it preciously.
Important remarks: 
* An "idle PC" value is *specific* to a Cisco IOS image.
   You cannot boot a different IOS image without proceeding as described above.
* Do not run the process while having the "autoconfiguration" prompt.

To boot quickly, the preferred method is to decompress the IOS image with the "unzip" utility.
It avoids to run the self-decompressing process in the emulator.

$ unzip -p c7200-advipservicesk9-mz.124-9.T.bin > image.bin
warning [c7200-advipservicesk9-mz.124-9.T.bin]: 27904 extra bytes at beginning or within zipfile
(attempting to process anyway)
$ file image.bin
image.bin: ELF 32-bit MSB executable, cisco 7200, version 1 (SYSV), statically linked, stripped

You can ignore the warning, unzip has just skipped the self-decompressing code at the beginning of the image.


Cisco 7200 Simulator FAQ

2007년 12월 6일 목요일

DynDNS의 WebHop Redirect Service 이용하기

www.dyndns.com에 Log-in합니다.

좌측메뉴에서 Host Services항목을 선택합니다.

Add New Hostname click하면 아래와 같이 나옵니다.

먼저 Service Type항목에서 WebHop Redirect를 선택해줍니다.

그럼 아래쪽에 WebHop Settings항목이 나타납니다.

우선 Hostname에는 새로이 사용할 주소를 지정해줍니다.

그 다음 WebHop Settings의 Redirect URL에 위에서 지정한 주소를 이용해

접근해야할 URL을 입력합니다.

http://mydyndns.homeip.net:8080/ 과 같이 Port Nr.도 함께 지정해 줍니다.

Yes, cloak this page항목을 체크하면 실제주소가 보여지지 않고

Cloaked title에 지정한 내용을 보여주게 됩니다.

Creat Host를 누르면 설정완료입니다.


이제 http://mydyndns.homeip.net:8080/ 대신 Web Browser의 주소창에

위에서 지정한 주소를 입력해주면 됩니다.

2007년 11월 29일 목요일

Network Selfstudy


후니의 네트워크 이야기 컬럼의 내용을 기반으로 내용을 보충해 넣은 자습용 문서이다.

아직은 기초적인 내용들만이 담겨져 있지만 계속 추가해 나갈 예정이다.
LAN, MAN, WAN, OSI Reference Model, TCP/IP Model, Ethernet,
Network Cable, Hub, Bridge, Switch, Router
등에 관한 내용들이 담겨있다.



ver.0.1.1 Page 5 오타수정.
ver.0.1.2 Page 8 Graphic수정.



secure.pe.kr의 강의실에 공개되어 있는 강좌들 중
TCP/IP Protocol Suite와 IP Address에 관한 부분을 정리한 자습용 문서이다.
위의 문서에 비해서는 추가된 내용이 적다. 그만큼 내용이 충실한 강좌였기때문이기도 하다.





2007년 11월 26일 월요일

[Terms] STP(Spanning Tree Protocol)

[Source] Terms Korea

STP는 동일한 두 개의 Computer Network  Segment를 서로 연결하기 위해 두 개Bridge가 사용된 곳에서 Bridge 간에 정보를 교환할 수 있도록 함으로써, 주어진 Message를 둘 중 오직 한 개의 Bridge만이 처리할 수 있도록 해주는 Protocol이다.

STP는 흔히 'Bridge Loop'라고 알려져 있는 상황을 예방한다.

1. Bridge Loop Caused by a Workgroup Bridge Connected to the Wired LAN


2. Bridge Loop Caused by Two Workgroup Bridges on the Same Remote Hub 

Ethernet이나 Token Ring과 같은 LAN에서, Computer는 공유하고 있는 전송로를 서로 먼저 사용하기 위해 경쟁한다. 만약 너무 많은 수의 Computer가 동시에 Data를 전송하려 시도하면, Network의 전반적인 효율이 악영향을 받을 수 있으며 심지어 Traffic 전달이 거의 멈추는 지경에 까지 이를 수 있다.
이러한 개연성을 최대한 줄이기 위해, Bridge라고 불리는 장치를 이용하여 LAN을 두 개 이상의 Network Segment로 나누게 된다. 이로 인해 각 Message는 원하는 목적지로 가기 전에 Bridge를 통과하게 되는데, 이때 Bridge는 그 Message를 송신측이 속해있는 동일 Segment 내 어딘가로 보내야 할지, 아니면 다른 Segment로 보내야 할지를 결정하게 된다.
Bridge는 수신측
주소를 보는 것 외에 어떠한 일도 하지 않으며, 자신이 미리 알고 있는 정보에 기반하여 받은 Message를 올바른 경로로 전달하기만 한다. Network Segment와 Bridge 이용의 장점은 Network 경로를 사용하기 위해 벌어지는 경쟁을 절반 이하로 줄임으로써, Network이 멈출 가능성을 현저하게 줄이는데 있다.

각각의 Bridge는 양측 Segment트 간에 교환하게 되는 최초 Message와 Message에 응답한 Computer를 인식하고 기록해 놓는 등의 후속 행위를 통해, 어느 Computer가 어느 Segment에 속해 있는지를 지속적으로 학습(Leaning)하게 된다. 따라서 Bridge는 점차 어느 Computer가 어느 Segment에 속해 있는지 그 자체에 대한 그림을 스스로 구축하게 된다.
Bridge는 두 번째 이후의 Message가 전송될 때부터, 그 Message를 어떤 Segment로 전달할 것인가를 결정할 때 자신이 갖고 있는 표를 참조하게 된다.
경험을 통해 Bridge가 Network을 학습하게 하는 이러한 접근 방식을, 관리자가 따로 Bridge브리지 설정을 할 필요가 없는 형식의 Bridging이라는 의미로 ‘Transparent Bridging
(투명한 브리징)’이라고 부른다.

Network 내에 Bridge를 설치할 때에는, 고장에 대비하여 Back-up용 Bridge를 추가하는 것이 보통이다.
Message 전송은 실제로 Main Bridge(Root Bridge)가 담당하지만, Main Bridge(Root Bridge)와 Back-up Bridge 모두는 지속적으로 Network 형상을 파악하고 있어야 한다. 그리고 두 Bridge는 서로 어떤 Bridge가 Main Bridge(Root Bridge)인지를 알 수 있도록 하기 위한 방법이 필요하다.
이를 위하여 두 Bridge 간에는 BPDU(Bridge Protocol Data Unit)를 이용하여 정보를 교환하기 위해 별도의 경로를 통한 접속을 갖고 있다.

각 Bridge 내의 Program이 그 Protocol을 어떻게 사용할지를 결정할 수 있도록 해주는 것을 Spanning Tree Algorithm이라고 부른다.
이 Algorithm은 특히 Bridge Loop, 즉 한 Segment에서 다른 Segment로 연결되는 경로를 다중화하면 무한 Loop가 생기는 상황이 벌어지지 않도록 고안되었다. 이 Algorithm은 Bridge가 다중
경로를 가지고 있을 때, 그 중 가장 효율적인 경로를 사용하도록 할 책임이 있다. 만약 최적의 경로를 이용할 수 없는 상황이 생기면, Algorithm이 새로 계산하여 차선의 경로를 찾는다.

STP가 Network을 결정하고 나면 BPDU를 이용하여 이 Data를 교환하는데,
이 작업은 다음의 두 단계로 나뉘어 진다.

1 단계: Algorithm은 수신된 설정 Message를 평가하고 제일 나은 선택 사항을 고름으로써 Bridge가 보낼 수 있는 최적의 Message를 결정한다.

2 단계: 특정 Bridge가 보낼 수 있는 최적의 Message를 선택한 후, Root 접속이 아닌 곳에서 받은 설정 Message와 Algorithm이 선택한 내용을 서로 비교한다. 이때, 만약 1단계에서 선택한 Option이 Root 접속이 아닌 곳으로부터 받은 내용보다 못하면, Algorithm은 그 Port를 제거한다.

STP는 IEEE의 한 위원회에 의해 개발되었다. IEEE는 현재, 기존의 STP에 Network 복원시간을 줄일 수 있도록 품질 향상에 주력하고 있는데, Link 상태의 고장 또는 변경 후 30~60 초 내의 시간을 10초 이내로 줄이는데 목표를 두고 있다.

Example:

  • Bridge에 내장된 STP를 이용하여 Network을 이중으로 구성, Network의 단절을 방지.
  • 전송로 A와 전송로 B구간의 Wireless구간은 정상연결상태.
  • Packet은 전송로 A 또는 B 한쪽으로만 송수신.
  • 전송로 A구간에 장애 발생시 자동으로 전송로 B구간으로 절체(Change Over)되어 Packet 송수신.


Related Article:

[cisco.com] Understanding and Configuring Spanning Tree Protocol (STP) on Catalyst Switches


2007년 11월 22일 목요일

[scrap] 화보로 보는 네트워크 기초 | 라우터의 이해


[Source] 앞서가는 네트워커를 위한 기술 활용전문지 온더넷 / 출판일 :2005년 11월호 / 박재곤 기자

화보로 보는 네트워크 기초 | 라우터의 이해
 
PC마다 LAN 카드를 장착하고, 이들을 허브나 스위치로 연결했다고 이것이 인터넷에 연결되는 것을 의미하지는 않는다. 라우터는 이렇게 허브나 스위치로 연결된 내부 LAN을 바깥 세상, 즉 인터넷과 연결시켜주는 역할을 하는 장비다. 때문에 인터넷을 기반으로 하는 오늘날의 네트워크 환경에서 인터네트워킹 장비인 라우터를 이해하는 것은 네트워크를 이해하는 좋은 방법의 하나가 될 것이다.

라우터(Router)는 이름 그대로 네트워크와 네트워크 간의 경로(Route)를 설정하고 가장 빠른 길로 트래픽을 이끌어주는 네트워크 장비다. 우리말로 풀어보면 '경로설정기'라고 할 수 있을 것이다.
인터넷, 다시 말해 IP 네트워크가 모든 네트워크의 기본이 되면서 라우터는 네트워크의 가장 핵심 장비로 등극했다. 인터넷이 확산되기 이전에는 사실 네트워크 자체가 확산되지 않은 상태이긴 했지만, 우리보다 네트워크의 역사가 오래된 해외의 경우를 보더라도, 과거 기업 단위 LAN 환경의 핵심은 스위치였다. 네트워크 내를 흐르는 트래픽의 대부분이 내부 LAN에서만 움직였기 때문에 스위치를 넘어 데이터가 전달되는 비중이 많지 않았기 때문이다. 내부 LAN 밖으로 데이터가 나가는 경우는 본사와 지사를 연결하는 전용회선을 통하는 경우가 전부였다.
하지만 인터넷 기반의 네트워크 환경에서는 어떤 형식으로든 네트워크가 외부의 다른 네트워크와 연결돼야 하고, 이를 위해서는 서로 다른 네트워크 간을 연결하는 장비인 라우터의 비중이 높아질 수 밖에 없게 된 것이다. 물론 라우터가 IP 네트워크 만을 위한 장비는 아니지만, 여기서는 최근의 네트워크 환경과 이해의 편의를 위해 인터넷 환경에 한정해 살펴보겠다.

라우터는 인터네트워킹 장비다
인터넷에 연결된 개별 네트워크의 수는 이루 헤아릴 수 없이 많은 것이 사실이다. 인터넷의 어원이 인터네트워크(Internetwork)에 있듯이, 라우터는 이렇게 서로 연결된 네트워크(Internetwork) 간의 경로(Route)를 설정해주는 장비다. 라우터가 '경로'에 비중을 둔 이름을 갖게 된 것도 이렇게 수없이 연결된 네트워크 간을 어떻게 연결하는 것이, 다시 말해 어떤 경로로 연결하는 것이 가장 효율적인가를 알려주는 길잡이 역할이 중요하기 때문이다.
라우터의 이런 인터네트워킹 기능은 OSI 참조모델로 살펴보면 훨씬 명확하게 이해할 수 있다. 허브나 스위치가 OSI 참조모델 2계층, 데이터 링크 계층에 속하는 반면, 라우터는 3계층, 즉 네트워크 계층에 해당하는 장비이다. 잘 알려진 대로 네트워크 계층은 여러 개의 독립적인 네트워크 간에 데이터를 전송하는 것에 관한 계층이다.
허브나 스위치가 속해 있는 데이터링크 계층의 데이터 전송은 물리적인 장치의 주소 지정에 의해 단일 네트워크로 연결된 모든 장치에 데이터를 브로드캐스팅하며, 수신측 장비에서 확인해 자신에게 오는 데이터를 수신받는 방식이다. 이런 방식은 일정한 범위와 크기의 내부 LAN에서는 가능하지만, 네트워크의 규모가 일정 크기를 넘어서면 매우 비효율적인, 그리고 현실적으로 운영할 수 없는 네트워크가 되고 만다. 광대한 인터넷을 향해 브로드캐스팅을 한다는 것은 누가 생각해도 합리적이지 못한 방법이다.
그러나 네트워크 계층의 장비인 라우터는 여러 개의 네트워크가 연결된 환경에서 특정 경로를 선택해 데이터가 전송되도록 한다. 이는 목적지로 데이터를 전송하면서 목적지가 아닌 네트워크에 데이터가 전송되는 것을 방지할 수 있다. 여기서 특정 경로란 다양한 라우팅 알고리즘을 통한 최적의 경로를 말한다.

 

라우터는 컴퓨터다
라우터의 기본적인 구성은 일반 컴퓨터와 마찬가지다. 중앙처리 장치인 CPU가 있고, 각종 메모리가 라우터의 운영체제와 환경설정 정보, 그리고 라우팅 정보 등을 담고 있다. 그리고 네트워크 인터페이스를 통해 트래픽을 입출력한다. 때문에 초기에는 소규모 환경에서 값비싼 라우터 장비 대신 일반 PC 서버를 이용해 라우팅 서비스를 구현하는 경우도 적지 않았다.
CPU는 라우터의 성능(처리량)을 결정짓는 부분이기 때문에 소형 라우터보다 중형 라우터가 더 빠른 CPU를 내장하고 있으며, 사용자가 많거나 더 많은 작업을 할수록 메모리 용량이 커야 한다.
라우터의 메모리에는 라우터 운영체제(예를 들면 시스코의 IOS)와 라우터의 환경 설정에 대한 내용 즉, 라우터 비밀번호, 시리얼 포트의 속도, 포트에 등록된 IP 어드레스 등의 내용이 저장돼 있다. NVRAM( Non-Volatile Random Access Memory)을 사용하기 때문에 라우터를 재부팅해도 수정된 환경이 적용된다.
라우터는 ROM에 있는 부트스트랩 프로그램을 통해 플래시 메모리에 라우터 운영체제를 저장하고 있다가 메모리로 올린다. 네트워크 운영체제는 기능이 향상되고, 제공하는 기능이 많아질수록 버전이 올라가는데, 이때 프로그램 크기도 점차 커지므로 이를 저장하고 운영하기 위한 메모리도 커진다. 따라서 네트워크 운영체제의 버전이나 장비에 따라 필요한 플래시 메모리 용량이 다르다. 일반적으로 시스코 IOS 12 버전이라면 8MB 정도의 메모리가 필요하다.
라우터는 외부 인터넷이나 원거리에 있는 지점간 통신을 하기 위해 통신 포트를 제공한다. 일반적으로 2개를 제공하는 시리얼 포트는 첫번째 포트가 serial0, 두번째 포트는 serial1로 지정돼 있다.
PC 의 COM 포트는 일반적으로 비동기 방식의 포트(Async Port)에 해당하는 반면, 시스코 라우터의 시리얼 포트는 동기(Synchronous) 방식이다. 또한 라우터에도 이더넷 포트가 있어서 스위치나 허브를 연결할 수 있다. 그밖에도 라우터에는 콘솔(console) 포트와 AUX(AUXiliary) 포트가 있는데, 이는 라우터를 처음 설치하거나 유지보수를 위해 설정을 변경할 때 사용한다.


라우터의 핵심 : 라우팅 테이블
스위치가 MAC 어드레스를 기반으로 패킷을 목적지로 전달하는 것처럼, 라우터도 어드레스 테이블에 해당하는 '라우팅 테이블'을 가지고 라우팅 서비스를 제공한다. 이 라우팅 테이블에 기록된 정보를 바탕으로 라우터는 자신에게 보내온 패킷을 어디로 전달할 것인지 결정한다. 보다 정확하게 말하면, 라우터는 철저하게 라우팅 테이블에 의존해 라우팅을 한다. 따라서 라우터의 운영은 라우팅 테이블을 관리하는 것이 절반 이상의 비중을 차지하며, 이 라우팅 테이블을 어떻게 구성하고 관리하느냐에 따라 라우터의 원래 목적, 즉 최적의 경로를 찾는 것이 가능해진다.
라우팅 테이블의 정보를 관리하는 방법은 크게 정적(static) 라우팅과 동적(dynamic) 라우팅으로 나눌 수 있다. 정적 라우팅은 관리자가 직접 라우터에 대해 접속하려는 특정 장소, 즉 상대 라우터를 지정하는 방식이며, 동적 라우팅은 라우터가 자체적으로 라우터끼리의 접속 정보를 주고받아 라우팅 테이블이 자동 갱신되는 방법이다.
동적 라우팅이 당연히 편하고 효과저인 방법처럼 보이지만, 정적 라우팅도 라우터 자체의 부하가 적고 회선 대역폭의 효율이 좋다는 장점이 있다. 때문에 모뎀이나 브로드밴드 네트워크와 같이 필요할 때만 연결하는 환경에서는 라우팅 정보를 라우터끼리 주고받지 않는 정적 라우팅이 주로 이용된다.
동 적 라우팅은 자동으로 라우팅 테이블이 갱신된다는 장점으로 인해 장애가 발생된 라우터가 라우팅 정보에세 제거됨으로써 네트워크 장애의 영향을 피할 수 있으며, 일부 라우터가 사라지거나 새로이 추가돼도 항상 최적의 경로로 데이터를 전송할 수 있다. 이미 헤아릴 수 없을 정도로 많은 라우터가 설치돼 있는 인터넷은 정적 라우팅을 적용하기에는 이미 너무 복잡한 상태라고 할 수 있다.

최적 경로 찾기의 조건 : 라우팅 프로토콜과 라우팅 알고리즘
그렇다면 동적 라우팅 테이블은 어떤 방식으로 만들어지는 것일까. 연결된 라우터끼리 무작위로 정보를 전송해 이를 저장하는 방식으로는 복잡 다단한 구성을 갖고 있는 인터넷에서 라우터가 최적의 경로를 찾을 수 없을 것이다.
이렇게 라우터끼리 서로의 정보를 주고 받는 방식을 정한 것이 바로 라우팅 프로토콜이며, 이들 라우팅 프로토콜은 일정한 라우팅 알고리즘을 바탕으로 이뤄져 있다. 라우팅 알고리즘은 거리 계산 방식(Distance Vector Advertisement)과 연결 상태 방식(Link State Advertusement)으로 나눠지며, 거리 계산 방식의 라우팅 프로토콜에는 RIP, IGRP, EIGRP가, 연결 상태 방식 라우팅 프로토콜에는 OSPF, IS-IS, NLSP 등이 대표적이다.
거리 계산 방식은 네트워크 어드레스에 대해 거리(홉 수)와 방향(라우터의 어느 포트인지) 정보를 다른 라우터로 보내 라우팅 테이블 정보를 변경하는 방법이다. 반면 연결 상태 방식은 여기에 더해 대역폭, 전송지연, 회선 신뢰도, 부하 등을 적절히 조합해 최적의 경로를 선택한다. 다시 말해 라우터를 여러 개 거쳐서 홉 수가 많더라도 회선 속도가 보다 빠른 쪽으로 경로를 설정할 수 있다는 것이다.


· RIP
RIP는 처음에 제록스의 XNS(Xerox Network System)에서 사용하기 위한 라우팅 프로토콜로 개발됐다. 이후 1982년에 BSD(Berkeley Standard Distribution) 버전 유닉스의 TCP/IP 프로토콜 환경에서 ‘routed’라는 프로세스 형태로 구현되면서 일반에 널리 알려졌으며, RFC(Request For Comment) 1085로 제정, 인터넷 표준 라우팅 프로토콜로 정해졌다.
RIP는 초기에 빠른 속도로 인터넷 환경에 적용됐는데, 그 이유는 당시의 인터넷은 그다지 복잡하지 않았기 때문에 RIP와 같이 구현이 쉽고 견고한 라우팅 프로토콜을 원하고 있었기 때문이다.
RIP에서는 송신지와 수신지 간의 거리를 패킷이 경유하는 라우터의 개수에 해당하는 홉(hop) 수로 표시하는데, 하나의 라우터를 경유한다면 이는 1홉의 거리가 되며, 2개의 라우터를 경유한다면 2홉의 거리가 되는 것이다.
RIP는 매 30초 이내에 새로운 라우팅 정보를 발송하며, 만약 180초 이내에 새로운 라우팅 정보가 수신되지 않으면 해당 경로를 이상 상태로 간주한다. RIP에서는 액티브와 패시브 두 가지 유형의 사용자를 정의하고 있다.
액 티브 사용자(라우터가 대표적임)는 자신이 속해 있는 네트워크 내에서 데이터그램 패킷을 통해 매 30초마다 라우팅 정보를 브로드캐스트한다. 반면에, 패시브 사용자(호스트 컴퓨터가 대표적임)는 RIP 정보를 수신해 경로를 갱신하지만, 스스로 라우팅 정보를 송신하지는 않는다. RIP 패킷 내에는 송신지에서 바라본 각 수신지 주소와 홉 수 등이 포함돼 있다.
그러나 RIP에는 몇가지 결함이 있다. 홉 수가 15를 넘는 대규모 네트워크에는 적합하지 않고, 서브넷 마스크를 지원하지 않으므로 IP 주소 영역의 활용을 제한한다. 또한 경로 테이블 전체를 매 30초마다 전송하므로 네트워크 대역폭의 효율적인 사용이 어렵고 최적의 경로를 찾기 위한 정보로 홉(거리값)만을 고려하므로 RIP가 선택한 경로가 최적의 경로가 아닌 경우가 발생할 수 있다. 이후 RIP의 단점을 보완하기 위한 RIP v2가 개발되긴 했지만, 다른 라우팅 프로토콜과의 경쟁에서 밀려, 그다지 많이 사용되지는 않고 있다.

· OSPF
1980년대 중반 이후 RIP 프로토콜의 한계가 드러나자 IETF( Internet Engineering Task Force)는 SPF(Shortest Path First) 알고리즘에 기반한 IP 네트워크용 라우팅 알고리즘인 OSPF를 개발했다.
OSPF는 ‘Open Shortest Path First’란 이름에서 알 수 있듯이 모든 사양이 개방돼 있다. OSPF의 사양은 RFC 1247(후에 RFC 1583; OSPF v2로 대체)로 발표됐다.
OSPF 는 연결 상태(link state) 개념을 기반으로 한다. 논리적인 영역 내의 모든 라우터는 연결 상태 정보를 모든 라우터에 전송하는데, 이로 인해 논리적인 그룹 영역의 모든 라우터에 일관된 연결 상태 정보 데이터베이스가 제공된다.
각 라우터는 이를 통해 SPF(Shortest Path First) 알고리즘을 실행해 경로를 계산하고 이것을 라우팅 경로로 간주한다. 이는 RIP와 달리 연결 실패가 감지된 후 1초 이내에 재연결하는 기능을 제공한다. 업데이트된 라우팅 정보만을 생성하기 때문에 네트워크 트래픽도 적으며, 논리적인 네트워크 체계에서 계층을 형성하고, 확장성이 좋다.
OSPF는 라우터간에 변경된 최소한의 부분만을 교환하므로 네트워크의 효율 저하를 최소화하며, 라우터의 위치를 설정함에 의해 확장성과 대규모 네트워크에 적용할 수 있는 장점이 있다. OSPF는 RIP가 갖고 있는 여러 단점을 해결할 수 있지만, 프로토콜 자체가 복잡해 구성과 관리가 어렵다는 것이 단점으로 지적된다.

· IGRP
IGRP(Interior Gateway Routing Protocol)는 시스코에서 독자적으로 개발한 프로토콜이다. RIP와 유사하게 홉 수를 기준으로 정보를 전송하는 IGRP는 회선의 전송 능력, 전송 지연 시간, 회선의 사용율, 신뢰성을 바탕으로 라우팅 경로를 결정한다. IGRP는 또한 복수 경로에서의 로드밸런싱 기능을 지원한다.

· OSI 라우팅
OSI 참조 모델을 만든 ISO(International Organization for Standardization)가 OSI 참조 모델의 네트워크 계층 프로토콜을 위한 라우팅 프로토콜로 개발했다. OSI 라우팅의 기반이 되는 IS-IS는 처음에 DECnet에서 사용되는 라우팅 개념에서 출발했다. 초기에는 OSI 표준 모델의 네트워크 계층 프로토콜인 CLNP(Connectionless Network Protocol)를 위한 라우팅만을 지원했으나, 후에 IP 네트워크를 위한 버전도 개발됐다.
OSI 라우팅 프로토콜은 OSI 참조 모델에 근거한 표준 라우팅 프로토콜이기는 하지만, 실제 환경에서는 잘 사용되지 않는다.