검색 엔진의 방문이 늘어나고 있군...

Posted
Filed under 네트워크
참조 원문 : Best Networking Tweaks for Linux


ifconfig (interface) txqueuelen #
  제목의 명령어처럼 'txqueuelen'이라는 옵션을 통해 전송 버퍼의 크기를 늘릴 수 있습니다. 리눅스에서 네트워크 어댑터를 위한 소프트웨어 버퍼의 크기는 전통적으로 1000 패킷입니다. 네트워크 연구원과 과학자에 따르면 LAN의 경우 1만 정도가 적당하고 만약 LAN의 속도가 기가 비트 이상이라면 그보다 높게 설정하는 것이 좋다고 합니다. 모뎀이나 WAN 링크의 경우 디폴트로 0~100 정도의 값이 설정될 수 있지만 1000까지 올릴 경우 성능이 향상될 수 있습니다. 단, 이 설정 값을 올리면 그 만큼의 메모리가 사용되므로 임베디드 라우터를 사용할 경우 조심할 필요가 있습니다. 16MB 정도의 램이라면 1만 정도로 설정해도 대체로 문제가 없다고 합니다.

  이 명령어를 적용하는 방법으로는 /etc/rc.local 파일에 직접 'ifconfig eth0 txqueuelen 10000'이라는 줄을 추가한다던가 데비안의 경우 /etc/network/interfaces 파일에서 대상 인터페이스 설정 밑에 'up ifconfig $IFACE txqueuelen 10000'라는 줄을 추가하는 방법이 있습니다.


/etc/sysctl.conf
  이 파일은 리눅스와 다른 *nix 기반의 시스템에서 네트워크와 파일에 대한 디폴트 설정을 담당합니다. 아래는 트윅에 도움이 되는 설정과 각 설정에 대한 설명입니다.
net.ipv4.tcp_rfc1337=1
net.ipv4.tcp_window_scaling=1
net.ipv4.tcp_workaround_signed_windows=1
net.ipv4.tcp_sack=1
net.ipv4.tcp_fack=1
net.ipv4.tcp_low_latency=1
net.ipv4.ip_no_pmtu_disc=0
net.ipv4.tcp_mtu_probing=1
net.ipv4.tcp_frto=2
net.ipv4.tcp_frto_response=2
net.ipv4.tcp_congestion_control=illinois
  1. RFC 1337(TIME-WAIT Assassination Hazards in TCP)로 발표된 취약점 방지 옵션으로 클라이언트로부터 RST를 받아서 TIME_WAIT 상태로 갈 경우 바로 접속을 종료하고 소켓을 닫는다.
  2. TCP window scaling으로 들어오는 패킷으로 인해 네트워크 어댑터가 포화상태가 되는 것을 방지한다.
  3. TCP SACK와 FACK로 대량의 데이터 손실 없이 수신을 받는다.
  4. 대역폭보다 패킷이 더 중요하다면 latency를 1로 설정하고 대역폭이 더 중요하다면 0으로 설정한다. 원격 데스크탑이나 VOIP의 경우 전송량이 대단하지 않기 때문에 패킷을 중시하는 편이 더 좋다.
  5. IPv6는 라우터 레벨에서 패킷이 조각화되는 것을 피하기 위해 PMTU를 기본적으로 사용하는데 IPv4에서도 이 옵션을 사용할 수 있다. PMTU는 링크 사이에 사용할 최고의 패킷 사이즈를 라우터에게 알리는 메커니즘이지만 실무상 일반적으로 ICMP 포트를 막아 ping을 방지하는 경우가 많고 그런 경우 이 메커니즘을 사용할 수 없습니다. 리눅스는 일단 이 옵션을 사용하려고 시도합니다. 이 옵션에 문제가 있다면 라우터에 문제가 있는 것이며 1로 바꿔서 사용하지 않을 수 있습니다. "MTU probing"도 이 옵션의 일부로서 아까 옵션과 반대로 1이 사용하는 것이고 0이 사용하지 않는 겁니다.
  6. FRTO는 신규 리눅스 커널에 등장한 메커니즘으로써 무선 호스트에 대한 최적화를 담당합니다. 무선 호스트가 있다면 사용하고 없다면 설정을 지우거나 0으로 설정합니다.
  7. TCP Congestion Controls
      윈도우 비스타 이상의 버전부터는 혼잡 제어(Congestion Control)에 표준 TCP Reno 대신 Compound TCP를 사용합니다. 리눅스의 경우 커널 2.6.19을 기준으로 장거리 링크에 좋은 성능을 발휘하는 CUBIC을 디폴트로 사용하고 있습니다. 이 글의 원저자는 TCP Westwood +와 TCP Illinois를 주로 사용한다고 하는데 아래는 혼잡 제어 알고리즘 중 TCP Illinois를 사용하는 방법을 제시하고 있습니다.
  1. 자신의 커널이 알맞은 모듈을 가지고 있는지 확인한다. TCP Illinois는 2008년 이후로 표준 우분투 커널에 'tcp_illinois'라는 이름으로 컴파일되어 탑재되고 있다. 'modprobe -l | grep 모듈명'으로 모듈이 존재하는지 확인할 수 있다.
  2. 해당 커널 모듈을 /etc/modules 파일에 추가한다. 지금의 경우 'tcp_illinois'라는 줄을 추가하면 된다. 이 파일에 추가한 모듈은 다음 부팅 때 적용되며 다시 부팅을 하지 않고 지금 바로(1회성) 모듈을 올리려면 'sudo modprobe tcp_illinois' 명령어를 사용한다. 모듈이 올라왔는지의 여부는 'lsmod | grep tcp_illinois' 명령어로 확인할 수 있다.
  3. /etc/sysctl.conf 파일에 'net.ipv4.tcp_congestion_control=illinois'라는 줄(이미 위의 내용의 마지막 줄에서 등장)을 추가하여 해당 모듈에 대한 파라미터를 설정한다. 이 설정은 다음 부팅 때 적용되며 지금 바로 적용하려면 'sudo sysctl -p' 명령어를 사용한다.
2010/12/14 09:56 2010/12/14 09:56
Posted
Filed under 네트워크

more..



more..



more..



more..



more..



more..



more..



more..



more..



more..



more..



more..



more..



more..



참고 도서: CCNA ICND2 Official Exam Certification Guide
2010/09/26 17:12 2010/09/26 17:12
Posted
Filed under 네트워크

more..



more..



more..



more..



more..



more..



more..



more..



more..



more..



참고 도서: CCNA ICND2 Official Exam Certification Guide

2010/09/12 16:54 2010/09/12 16:54
Posted
Filed under 네트워크
RIP은 현재 실존하는 라우팅 프로토콜 중 가장 간단한 프로토콜이라고 할 수 있습니다. 초기에 나온 버전1(이후 RIPv1)과 후에 기능을 보강한 버전2(이후 RIPv2)가 있는데 버전2는 클래스리스 라우팅 프로토콜이기 때문에 VLSM을 지원하여 더 유연한 설정이 가능합니다.

more..



more..


 

more..



more..



more..



more..



참고 도서: CCENT / CCNA ICND1 Official Exam Certification Guide
2010/09/01 17:43 2010/09/01 17:43
Posted
Filed under 네트워크
라우터의 목적은 패킷을 목적지까지 최고의 경로로 보내는 것입니다. 여기서 '최고'의 기준과 경로의 수집 방법은 라우터에서 사용할 라우팅 프로토콜에 의해 결정됩니다. 라우터는 자신이 사용하는 라우팅 프로토콜로 같은 라우팅 프로토콜을 사용하는 다른 라우터에게서 경로를 수집하며 이렇게 형성한 정보의 결과를 라우팅 테이블이라고 부릅니다.


라우팅 프로토콜의 분류

라우팅 프로토콜의 분류. EGP의 EGP는 더 이상 쓰이지 않는다.

  라우팅 프로토콜은 크게 IGP(Interior Gateway Protocol)와 EGP(Exterior Gate Protocol)로 나눌 수 있습니다. 이 두 개념을 다루기 이전에 먼저 AS(Autonomous System)라는 것을 알아야 합니다. AS는 하나의 집단을 이루는 관리 단위에 부여하는 번호로서 회사, 학교, 조직 등이 하나의 AS를 이룰 수 있는 예라고 할 수 있습니다. IP주소와 마찬가지로 AS도 ICANN(Internet Corporation for Assigned Network Number)이 관리를 총괄합니다. IGP는 하나의 AS 내에서 패킷이 가는 경로를 알려주는 역할을 하는 라우팅 프로토콜로서 RIP(버전1, 2 모두 포함), EIGRP(IGRP 포함), OSPF 등이 여기에 속합니다. 이와 달리 EGP는 서로 다른 AS끼리 경로를 교환하는 라우팅 프로토콜로서 같은 패킷이 한 AS를 2번 지나지 않게 하여 루프에 빠지는 것을 막기도 합니다. IGP에 해당하는 프로토콜의 수가 여럿인 것과 달리 EGP에 해당하는 프로토콜은 BGP(Border Gateway Protocol)가 유일합니다. 사실 BGP가 존재하기 전에 그 이전 버전 격인 EGP라는 프로토콜이 있었는데 지금은 완전히 BGP로 대체되었기 때문에 사용되지 않습니다.


주요 IGP 라우팅 프로토콜과 비교 사항 설명

주요 라우팅 프로토콜 요약

  위 표는 주요 IGP 라우팅 프로토콜에 대한 요약으로서 각 사항들에 대한 설명은 아래와 같습니다.

클래스리스, 라우팅 업데이트 시 서브넷 마스크 전송
  'O'는 해당 프로토콜이 클래스리스 라우팅 프로토콜임을 뜻하고 'X'는 클래스풀 라우팅 프로토콜임을 뜻합니다. 클래스리스 라우팅 프로토콜은 대상 서브넷이 어느 클래스에 속하는지를 생각하지 않으며 서브넷 마스크만으로 서브넷을 구분하므로 다른 라우터에 광고를 할 때도 서브넷 마스크를 함께 보내는 프로토콜입니다. 반대로 클래스풀 라우팅 프로토콜은 네트워크가 클래스풀 네트워크라고 가정하며 그러므로 IP만 보면 서브넷 마스크를 알 수 있으므로 다른 라우터에 광고를 할 때 서브넷 마스크를 보내지 않는 프로토콜입니다. 클래스리스 라우팅 프로토콜은 VLSM 지원, 라우팅 업데이트 시 서브넷 마스크 전송, 수동 경로 요약 지원 항목이 모두 'O'이고 반대로 클래스풀 라우팅 프로토콜은 모두 'X'입니다. 사실 이것 자체가 클래스리스와 클래스풀 라우팅 프로토콜을 구분하는 특징입니다.

VLSM 지원
  VLSM(Variable-Langth Subnet Mask)이란 하나의 클래스풀 네트워크 안에서 여러 서브넷 마스크를 사용할 수 있는 기능을 말합니다. 이와 반대로 하나의 클래스풀 네트워크 안에서 하나의 서브넷 마스크만 쓰는 것을 SLSM(Static-Length Subnet Mask)이라고 합니다. 여기서 중요한 것은 '동일한 클래스풀 네트워크 안에서'입니다. 그렇기 때문에 만약 라우팅 테이블에 '10.0.0.0 네트워크에 서브넷 마스크가 255.255.255.0'에 대한 경로와 '11.0.0.0 네트워크에 서브넷 마스크가 255.255.0.0'에 대한 경로가 있다고 하더라도 하나는 '10.0.0.0' 네트워크고 다른 하나는 '11.0.0.0' 네트워크이기 때문에 이는 VLSM과 무관합니다. 일단 VLSM의 실제 토폴로지 예와 그에 따라 형성되는 라우팅 테이블을 통해 보겠습니다.

VLSM을 사용한 예

  토폴로지를 보면 같은 192.168.0.0 네트워크 안에서 2개 이상의 서브넷이 존재하고 있는데 이런 기능을 바로 VLSM이라고 부릅니다. 이렇게 구성하고 VLSM을 지원 안 하는 라우팅 프로토콜인 RIPv1을 사용한 후 라우팅 테이블을 보겠습니다.
Router#show ip route
Codes: C - connected, S - static, I - IGRP, 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

     192.168.0.0/30 is subnetted, 2 subnets
C       192.168.0.0 is directly connected, Serial1/0
C       192.168.0.4 is directly connected, Serial1/1
  보시다시피 직접 연결된 192.168.0.0/30 서브넷만 있을 뿐 192.168.0.64/26과 192.168.0.128/26 서브넷은 테이블에 형성되어 있지 않습니다. 그럼 이번에는 VLSM을 지원하는 RIPv2 프로토콜을 사용한 후 라우팅 테이블을 보겠습니다.
Router#show ip route
Codes: C - connected, S - static, I - IGRP, 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

     192.168.0.0/24 is variably subnetted, 4 subnets, 2 masks
C       192.168.0.0/30 is directly connected, Serial1/0
C       192.168.0.4/30 is directly connected, Serial1/1
R       192.168.0.64/26 [120/1] via 192.168.0.2, 00:00:13, Serial1/0
R       192.168.0.128/26 [120/1] via 192.168.0.6, 00:00:22, Serial1/1
  보시다시피 RIPv1을 사용할 때는 없었던 두 서브넷이 라우팅 테이블에 형성된 것을 볼 수 있습니다. VLSM을 두고 '서브네팅한 네트워크를 다시 서브네팅하는 것'이라고 정의하는 경우가 많은데 틀린 말은 아니지만 이것은 정의라기보다 용도에 더 가까우므로 '하나의 클래스풀 네트워크 안에서 여러 서브넷 마스크를 사용하는 것'이라고 알아두는 것이 좋을 것이라고 생각합니다.

수동 경로 요약 지원, 자동 경로 요약 지원
  주소의 앞부분이 동일한 여러 네트워크를 알고 있을 때 해당 네트워크들을 하나로 요약해서 광고하는 기능입니다. 예를 들어 만약 192.168.10.0/26, 192.168.10.64/26, 192.168.10.128/26, 192.168.10.192/26라는 4개의 네트워크와 직접 연결된 라우터가 있다고 합시다. 만약 이 라우터가 다른 라우터에게 저 4개의 네트워크를 광고한다면 4개의 네트워크를 각각 따로 광고할 필요가 있을까요? 4개의 네트워크 모두 192.168.10.0/24에 포함되는 네트워크입니다. 따라서 광고할 때 '나에게는 192.168.0.0/24 네트워크가 있다.'라고 광고한다면 광고를 받는 쪽에서는 4개의 경로 대신 1개의 경로만 라우팅 테이블에 기록할 것이고 그로 인해 라우팅 테이블이 간소화될 것입니다. 이런 기능을 경로 요약 지원이라고 하며 이것을 수동으로 관리자가 직접 설정할 수 있으면 수동 경로 요약을 지원하는 것이고 따로 관리자가 설정하지 않아도 작동하게 할 수 있으면 자동 경로 요약을 지원하는 겁니다.

거리 벡터, 링크 상태
  이 두 가지는 해당 라우팅 프로토콜이 최적의 경로를 결정할 때 무엇을 기준으로 삼는가를 나타냅니다. 거리 벡터(Distance Vector) 알고리즘을 사용하는 라우팅 프로토콜은 단순히 '목적지까지 얼마나 많은 라우터를 거쳐가나'를 기준으로 최적의 경로를 결정하며 인접한 라우터에게 자신의 라우팅 테이블을 넘겨줍니다. 알고리즘 자체가 간단하지만 루프 문제가 발생할 수 있다는 문제가 있습니다. 링크 상태(Link State) 알고리즘을 사용하는 라우팅 프로토콜은 서브넷과 서브넷의 상태를 데이터베이스화해서 보관하며 이를 이용하여 최상의 경로를 결정합니다. EIGRP의 경우 특이하게 이 두 가지 중 하나에 속하지 않는데 사실 거리 벡터를 기본으로 두 가지 특성을 모두 담고 있다고 볼 수 있어 '고급 거리 벡터 프로토콜'이라고도 부르며 시스코는 공식적으로 '밸런스트 하이브리드(Balanced Hybrid)'라는 이름을 주장하고 있습니다.

표준 여부
  해당 프로토콜이 표준에 속하는 프로토콜인가를 나타냅니다. 표에 있는 프로토콜 중 EIGRP를 제외한 모든 프로토콜이 표준 프로토콜입니다. EIGRP는 시스코 사가 자체 개발한 고유의 프로토콜로서 시스코 사의 제품에서만 사용할 수 있습니다.

멀티캐스트를 통한 라우팅 업데이트
  라우팅 업데이트 패킷을 보낼 때 멀티캐스트를 이용하여 보내는가를 나타냅니다. 멀티캐스트를 이용할 경우 업데이트를 보내고 싶은 대상에게만 보낼 수 있어 네트워크의 대역폭에 부담을 덜 주게 됩니다. 멀티캐스트를 이용하지 않는 프로토콜의 경우 브로드캐스트를 이용하여 업데이트를 보내는데 브로드캐스트는 같은 네트워크의 모든 호스트에게 전달되기 때문에 대역폭을 낭비하게 됩니다.

인증 지원
  광고를 주고 받을 라우터를 서로 인증하는 기능을 뜻합니다. 인증을 설정하지 않을 경우 공격자들이 라우팅 프로토콜의 허점을 악용하여 DoS 공격을 할 가능성이 있습니다. 예를 들어 공격자가 자신의 라우터를 네트워크에 연결시키고 특정 경로에 대한 메트릭을 낮게 만든 후 광고하여 어떤 목적지로 가려는 패킷을 모두 자신의 라우터로 모으는 행위를 할 수 있습니다. 인증 기능을 사용할 경우 인증된 라우터에 대해서만 라우팅 업데이트를 제공하기 때문에 이런 공격을 방어할 수 있습니다.

수렴 속도
  네트워크 토폴로지에 변화가 일어날 경우 라우팅 업데이트를 통해 이를 인식하고 최상의 경로를 다시 계산하여 라우팅 테이블에 반영하는 과정을 수렴(Convergence)라고 합니다. 수렴이 빠를수록 네트워크의 장애 복구 시간도 짧아지기 때문에 빠를수록 좋다고 할 수 있습니다.


라우터가 최고의 경로를 판단하는 기준

  동일한 라우팅 프로토콜에서 최고의 경로를 판단하는 기준이 되는 값을 메트릭(Metric)이라고 하며 값이 낮을수록 좋은 경로임을 의미합니다. 그런데 각 라우팅 프로토콜마다 메트릭 값을 구하는 방법도 다르고 값의 크기도 다릅니다. 예를 들어 RIP의 경우 메트릭 값을 구할 때 거쳐가는 라우터의 개수를 기준으로 삼으며 값의 크기도 1~2 자리 수 정도 밖에 되지 않지만 EIGRP의 경우 거쳐가는 회선의 대역폭과 지연 값 등을 참조하며 값도 RIP과 비교해 매우 높습니다. 즉, 라우팅 프로토콜마다 메트릭 값이 의미하는 바가 다릅니다. 그렇기 때문에 한 라우터에 여러 라우팅 프로토콜이 작동하고 있고 어떤 목적지까지 가는 경로를 각각의 라우팅 프로토콜마다 가지고 있을 경우 단순히 메트릭 값을 비교하는 것으로는 어느 프로토콜의 경로가 더 좋은 경로인지 알 수가 없습니다. 그래서 시스코 라우터에서는 각 프로토콜마다 일종의 우선 순위라고 할 수 있는 값을 정해두고 있는데 이것을 AD(Administrative Distance)라고 하며 이 값이 낮을수록 좋은 프로토콜임을 의미합니다. 그러므로 같은 목적지를 향하는 경로를 2개 이상의 프로토콜이 알고 있다면 AD 값이 가장 낮은 프로토콜의 경로가 라우팅 테이블에 적용됩니다. 아래는 각 라우팅 프로토콜의 AD 값입니다. '직접 연결된 곳'은 목적지가 라우터와 직접 연결된 곳을 말하며 '정적 경로'는 관리자가 수동으로 지정한 경로를 뜻하는 것으로 실제로 라우팅 프로토콜이 아니지만 AD 값을 가지고 있으므로 적었습니다.

시스코 IOS의 Administrative Distance

  라우팅과 관련하여 백업 정적 경로(Backup Static Route)라는 것이 있는데 이것은 정적 경로의 경우 AD를 원하는 값으로 설정할 수 있다는 것을 응용하는 기법입니다. 기본적으로 정적 경로의 AD 값은 어떤 라우팅 프로토콜보다도 낮습니다. 따라서 어떤 목적지에 대해 정적 경로가 설정되어 있다면 그 경로가 라우팅 테이블에 올라가 사용될 겁니다. 하지만 해당 정적 경로를 설정할 때 AD 값을 다른 프로토콜보다 높게 설정한다면 어떻게 될까요? 그 정적 경로는 동일한 목적지에 대한 다른 라우팅 프로토콜의 경로가 모두 사용 불가가 될 때 비로서 쓰일 겁니다. 이런 식으로 구성한 정적 경로를 백업 정적 경로라고 합니다.

  최고의 경로를 판단하는 또 다른 기준은 서브넷 마스크의 프리픽스 길이입니다. 만약 목적지가 10.100.1.2인 패킷을 받은 라우터의 라우팅 테이블에 10.100.0.0/16과 10.100.1.0/24가 있다면 라우터는 해당 패킷을 10.100.1.0/24가 가리키는 곳으로 패킷을 보냅니다. 이렇게 라우터는 패킷을 받으면 자신의 라우팅 테이블 보고 IP와 프리픽스를 비교하여 패킷의 목적지와 가장 일치하는 경로로 패킷을 보냅니다. 그런데 만약 아래와 같이 AD와 프리픽스가 서로 대결을 벌이는 상황이 오면 어떻게 될까요?

AD vs Prefix

C    192.168.0.0/24 is directly connected, Serial1/0
C    192.168.1.0/24 is directly connected, Serial1/1
R    192.168.2.0/24 [120/1] via 192.168.0.2, 00:00:18, Serial1/0
R    192.168.3.0/24 [120/1] via 192.168.1.2, 00:00:08, Serial1/1
     192.168.4.0/24 is variably subnetted, 2 subnets, 2 masks
S       192.168.4.0/24 [1/0] via 192.168.0.2
S       192.168.4.1/32 [100/0] via 192.168.1.2
  라우팅 테이블을 보면 Router3의 루프백 주소인 192.168.4.1과 관련된 정적 경로가 2개 있는 것을 볼 수 있습니다. 하나는 프리픽스가 24인 대신 AD 1이고 다른 하나는 프리픽스가 32로 패킷의 목적지 주소와 완벽히 일치하는 대신 AD가 100입니다. 여기서 192.168.4.1을 향해 패킷을 던지면 라우터는 AD가 더 낮은 192.168.0.2로 패킷을 보낼까요? 아니면 프리픽스가 더 많이 일치하는 192.168.1.2로 패킷을 보낼까요?
Router#traceroute 192.168.4.1
Type escape sequence to abort.
Tracing the route to 192.168.4.1

  1   192.168.1.2     32 msec   31 msec   31 msec  
  2   192.168.3.1     47 msec   62 msec   63 msec  
  이런 경우 라우터는 프리픽스가 더 일치하는 쪽을 더 좋은 경로로 판단합니다. 즉, AD보다 프리픽스의 우선 순위가 더 높습니다. 따라서 위의 결과에서 볼 수 있듯이 192.168.1.2로 패킷을 넘기게 됩니다.


참고 도서: CCENT / CCNA ICND1 Official Exam Certification Guide
2010/08/29 16:08 2010/08/29 16:08
Posted
Filed under 네트워크
1. 부팅 제어
  시스코 라우터는 아래의 4단계를 거쳐 부팅이 진행됩니다.
  1. POST(Power-On Self-Test)를 수행하여 하드웨어 점검.
  2. ROM 내의 부트스트랩 프로그램을 RAM으로 복사 후 실행.
  3. 부트스트랩 프로그램에서 로드할 IOS 이미지(또는 OS)를 결정 후 로드.
  4. IOS는 부트스트랩 프로그램으로부터 하드웨어 제어권을 받은 후 NVRAM에 있는 설정 파일을 RAM에 로드하여 running-config로 사용.
  1, 2단계는 관리자가 할 수 있는 것이 아무것도 없지만 3, 4단계는 설정 레지스터(Configuration Register)라는 16비트의 값을 변경하여 제어할 수 있으며 특히 4단계 과정을 바꾸는 것은 패스워드를 복구하는 과정과 관련이 있습니다. 설정 레지스터 값은 전역 설정 모드에서 config-register 명령어로 설정할 수 있습니다. 이 설정 값은 startup-config나 running-config 영역에 저장되는 것이 아니며 별도로 저장 명령어를 사용할 필요는 없습니다. show version 명령어를 사용하면 마지막 줄에서 현재 레지스터 값을 볼 수 있으며 다음 부팅 때 적용될 레지스터 값이 현재 값과 다르다면 그 값도 볼 수 있습니다.

  만약 부팅 시 3단계에서 IOS 이미지를 찾지 못하면 ROM에 저장된 OS를 로드합니다. 예전 시스코 라우터에는 RxBoot와 ROMMON이라는 2개의 OS가 같이 들어 있었지만 요즘 출시되는 라우터에는 두 기능이 통합되어 ROMMON만이 존재하므로 그에 맞춰 설명하겠습니다.

  먼저 3단계에서 IOS 이미지를 찾는 순서부터 알아보겠습니다. 시스코 라우터는 부팅 시 설정 레지스터의 마지막 4비트(=부트 필드)와 전역 설정 모드에서 실행하는 boot system 명령어를 통해 로드할 OS를 결정합니다. boot system 명령어로 플래시 메모리에 있는 IOS 이미지 파일명이나 파일명과 함께 IOS 이미지 파일이 있는 곳의 IP 주소를 지정할 수 있으며 여러 번 사용하여 여러 IOS 이미지 파일을 지정할 수 있습니다. 아래는 boot system 명령어의 사용법입니다.

boot system 명령어

  로드할 IOS 이미지를 결정하는 과정은 아래와 같습니다.
  1. 부트 필드가 0이면 ROMMON OS 로드.
  2. 부트 필드가 1이면 플래시 메모리에 있는 가장 낮은 번호의 IOS 이미지 파일 로드. 각 파일의 번호는 show flash 명령어를 통해 확인 가능.
  3. 부트 필드가 2~F면 startup-config 파일에 설정한 boot system 명령어를 순서대로 실행하여 지정한 IOS 이미지 파일들에 대한 로드를 차례대로 시도. 만약 전부 실패하면 플래시 메모리에 있는 가장 낮은 번호의 IOS 이미지 파일 로드.
  4. IOS 이미지 파일 로드에 실패하면 브로드캐스트를 보내 TFTP 서버를 찾아 IOS 이미지 파일명을 추측하고 로드. 그것도 실패하면 ROMMON OS 로드.
  대부분의 라우터는 3번 마지막 부분에 와서 IOS 이미지 파일을 찾는데 그 이유는 공장 출하 시 플래시 메모리에 하나의 IOS 이미지 파일이 있고 설정 레지스터는 0x2102로 되어 있으며 boot system 명령어는 설정되어 있지 않기 때문입니다.

2. 패스워드 복구
  중고 장비 구입, 인수인계 누락, 관리 소홀로 인해 라우터의 패스워드를 모르는 경우가 있을 수 있습니다. 이때는 각 라우터에 맞는 방법을 사용하여 패스워드를 초기화해야 합니다. 여기서는 ROMMON을 사용하여 복구하는 방법을 알아보겠습니다.

  먼저 ROMMON OS로 들어가야 하는데 그러기 위해서는 전원을 다시 올린 후 부팅 시 Ctrl+Break를 눌러야 합니다. ROMMON으로 진입했으면 패스워드 인증을 건너뛰기 위해 설정 레지스터 값을 바꿔야 하는데 이때 config-register가 아닌 confreg 명령어를 사용하여 레지스터 값을 '0x2142'로 변경합니다. 여기서 3번째 값인 '4'가 중요한데 이것은 부팅 시 NVRAM에 있는 설정을 읽지 않도록 만드는 값입니다. 이렇게 하면 부팅 시 설정을 읽어오지 않기 때문에 마치 새로 구입한 라우터처럼 패스워드 없이 Privileged Mode로 넘어갈 수 있습니다. 리부팅은 전원을 내릴 필요 없이 reset 명령어로 할 수 있습니다. 여기까지의 과정을 실제로 해보겠습니다.
ForgottenPassword>enable
Password:
Password:
Password:
% Bad secrets

ForgottenPassword>
-------------리부팅-------------
ForgottenPassword>System Bootstrap, Version 12.1(3r)T2, RELEASE SOFTWARE (fc1)
Copyright (c) 2000 by cisco Systems, Inc.
cisco 2811 (MPC860) processor (revision 0x200) with 60416K/5120K bytes of memory

Self decompressing the image :
###########
monitor: command "boot" aborted due to user interrupt
rommon 1 > confreg 0x2142
rommon 2 > reset
-------------리부팅-------------
         --- System Configuration Dialog ---

Continue with configuration dialog? [yes/no]: no


Press RETURN to get started!



Router>              <- 라우터 이름이 디폴트 이름으로 바꼈다.
  이제 Privileged Mode로 들어가서 패스워드를 원하는 것으로 재설정할 수 있는데 중요한 것은 그 전에 기존의 설정을 NVRAM에서 RAM으로 불러와야 한다는 겁니다. 만약 그러지 않고 패스워드만 설정한 후 NVRAM에 저장해버리면 라우터의 기존 설정들이 모두 덮어씌워질 겁니다. 그러므로 반드시 copy startup-config running-config 명령어로 NVRAM의 설정을 RAM으로 불러와 패스워드를 변경하도록 합니다. 그리고 config-register 명령어로 설정 레지스터의 값을 원래 값인 '2102'로 돌려줍니다. 패스워드 변경이 끝나면 copy running-config startup-config 명령어나 write 명령어로 설정을 NVRAM에 저장하고 reload 명령어로 리부팅을 합니다.
Router>enable
Router#copy startup-config running-config
ForgottenPassword#configure terminal
ForgottenPassword(config)#enable secret foobar
ForgottenPassword(config)#config-register 0x2102
ForgottenPassword(config)#exit
ForgottenPassword#copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
[OK]
ForgottenPassword#reload


참고 도서: CCENT / CCNA ICND1 Official Exam Certification Guide
참고 자료 제공: 강사 김기태
2010/08/25 23:59 2010/08/25 23:59
Posted
Filed under 네트워크

1. IOS 업그레이드 / 백업 / 복구
  IOS는 Internetwork Operating System의 약자로서 시스코의 라우터나 스위치의 운영체제를 뜻합니다. 시스코의 제품은 IOS 이미지 파일(IOS를 담고 있는 일종의 압축 파일)의 저장 장소로 플래시 메모리를 사용하는데 이는 플래시 메모리가 하드디스크와 달리 움직이는 부분이 없어 장애가 덜 발생하기 때문입니다. 일반적으로 제품에 달린 플래시 메모리에는 하나의 IOS 이미지 파일을 넣을 용량 정도 밖에 없습니다.

  그럼 먼저 복구나 업그레이드를 위해 TFTP를 이용하여 IOS 이미지를 플래시 메모리로 복사는 방법부터 알아보겠습니다. 복사할 이미지를 시스코 사이트 등에서 구해 TFTP 서버의 루트 디렉토리에 넣습니다. 그 후 라우터에서 다음과 같이 copy 명령어를 사용하여 플래시 메모리로 복사합니다. 당연히 라우터는 TFTP에 접근할 수 있어야 합니다.

  • 라우터의 IP: 192.168.0.1
  • TFTP 서버의 IP: 192.168.0.2
  • 가져올 IOS 이미지 이름: c2600-i-mz.122-28.bin

Router#copy tftp flash
Address or name of remote host []? 192.168.0.2
Source filename []? c2600-i-mz.122-28.bin
Destination filename [c2600-i-mz.122-28.bin]?

Accessing tftp://192.168.0.2/c2600-i-mz.122-28.bin...
Loading c2600-i-mz.122-28.bin from 192.168.0.2: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[OK - 5571584 bytes]

5571584 bytes copied in 3.281 secs (389093 bytes/sec)

  하지만 위와 달리 용량이 부족할 경우에는 복사에 실패합니다. 또한 사용 중인 IOS의 버전에 따라 복사하기 전에 이전 IOS의 삭제 여부를 물어볼 수도 있으며 세부적으로 출력 결과가 틀릴 수 있지만 방법은 동일합니다. 만약 플래시 메모리의 남은 용량이 부족하다면 플래시 메모리의 내용을 확인하고 필요 없는 파일들을 삭제하면 됩니다. 아래는 플래시 메모리 속에 있는 파일을 확인하고 그 중 한 파일을 지우는 예제입니다.

Router#show flash

System flash directory:
File  Length   Name/status
  3   50938004 c2800nm-advipservicesk9-mz.124-15.T1.bin
  6   4414921  c2960-lanbase-mz.122-25.FX.bin
  5   4670455  c2960-lanbase-mz.122-25.SEE1.bin
  2   28282    sigdef-category.xml
  1   227537   sigdef-default.xml
[60279199 bytes used, 3737185 available, 64016384 total]
63488K bytes of processor board System flash (Read/Write)

Router#delete c2960-lanbase-mz.122-25.SEE1.bin
Delete filename [c2960-lanbase-mz.122-25.SEE1.bin]?
Delete flash:/c2960-lanbase-mz.122-25.SEE1.bin? [confirm]

Router#

  새로운 IOS 이미지를 사용하려면 라우터가 IOS를 다시 로드하게 만들어야 하며 이는 reload 명령어를 통해 수행할 수 있습니다.

  라우터에 있는 IOS 이미지를 TFTP로 백업하는 방법도 위와 거의 같으며 복사할 위치만 바꿔주면 됩니다. 실제 예는 아래와 같습니다.

Router#copy flash tftp
Source filename []? c2600-i-mz.122-28.bin
Address or name of remote host []? 192.168.0.2
Destination filename [c2600-i-mz.122-28.bin]?

Writing c2600-i-mz.122-28.bin...!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[OK - 5571584 bytes]

5571584 bytes copied in 3.281 secs (1698000 bytes/sec)

  이번에는 라우터의 이미지가 망가졌을 때 ROM에 있는 ROMMON이라는 임시 운영체제를 이용하여 TFTP로부터 IOS 이미지 파일을 가져와 복구하는 방법을 알아보겠습니다. 먼저 라우터의 IOS 이미지 파일이 손상된 상황을 구현하기 위해 플래시 메모리 내의 IOS 이미지 파일을 지우고 reload 명령어로 IOS를 다시 불러오도록 만들겠습니다.

Router#delete flash
Delete filename []?c2600-ipbasek9-mz.124-8.bin
Delete flash:/c2600-ipbasek9-mz.124-8.bin? [confirm]

Router#sh flash

System flash directory:
File  Length   Name/status
  2   28282    sigdef-category.xml
  1   227537   sigdef-default.xml
[255819 bytes used, 63760565 available, 64016384 total]
63488K bytes of processor board System flash (Read/Write)

Router#reload
Proceed with reload? [confirm]
%SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload Command.

System Bootstrap, Version 12.1(3r)T2, RELEASE SOFTWARE (fc1)
Copyright (c) 2000 by cisco Systems, Inc.
cisco 2621 (MPC860) processor (revision 0x200) with 60416K/5120K bytes of memory

Boot process failed...

The system is unable to boot automatically.  The BOOT
environment variable needs to be set to a bootable
image.
rommon 1 >

  시스코 제품은 부팅에 적절한 IOS 이미지 파일을 찾는데 실패하면 ROM에 내장된 임시 OS 파일을 불러옵니다. 구형 제품에는 RxBoot와 부트 헬퍼라는 2개의 OS가 들어 있지만 현재 유통되고 있는 제품에는 ROMMON이라는 OS만 들어 있으므로 ROMMON을 사용하여 설명하겠습니다. 현재 라우터에는 IOS 이미지가 없기 때문에 TFTP 서버에서 IOS 이미지를 받아야 합니다. 여기서 중요한 규칙이 있는데 바로 TFTP 서버는 라우터가 가진 첫 번째 이더넷(또는 패스트이더넷) 포트에서 네트워크로 닿을 수 있는 곳에 존재해야 한다는 것입니다. 그렇지 않으면 정상적으로 필요한 내용을 입력해도 이미지를 받아올 수 없습니다. 또한 라우터의 첫 번째 이더넷 포트에 TFTP 서버가 직접 연결되어 있을 필요는 없지만 스위치만큼은 직접 연결되어 있으면 안 됩니다. 그 이유는 라우터가 IOS 이미지 파일을 가져오는 시도를 하면 그때부터 스위치와 1, 2계층 연결이 시작되는데 스위치의 STP 때문에 연결이 성립되기까지 시간이 걸려서 연결이 완성되기 전에 라우터쪽에서 먼저 타임 아웃이 떠버립니다. 그러므로 스위치와 직접적인 연결을 피하거나 직접 연결된 스위치에서 STP 기능을 비활성화시켜줘야 합니다.
 
  TFTP로부터 이미지를 받아오는데 필요한 정보는 아래와 같습니다.

  1. 라우터의 임시 IP 주소
  2. 라우터의 서브넷 마스크
  3. 디폴트 게이트웨이
  4. TFTP 서버의 주소
  5. IOS 이미지 파일명

  만약 TFTP 서버가 같은 네트워크에 있다면 디폴트 게이트웨이를 설정하는 것에 의미가 없으므로 라우터의 임시 주소와 동일하게 설정해줘도 무관합니다. 아래 예는 라우터의 첫 번째 이더넷 포트에 TFTP 서버가 직접 연결되어 있는 환경에서 수행한 내용입니다. 위의 5가지 사항을 아래와 같은 방법으로 입력한 후 마지막에 tftpdnld 명령어를 실행하면 지정한 TFTP 서버로부터 IOS 이미지 파일을 받아올 수 있습니다. 주의할 것은 아래에서 대문자로 입력한 문자열들은 반드시 대문자로 입력해야 제대로 작동한다는 겁니다.

rommon 1 > IP_ADDRESS=192.168.0.1
rommon 2 > IP_SUBNET_MASK=255.255.255.0
rommon 3 > DEFAULT_GATEWAY=192.168.0.1
rommon 4 > TFTP_SERVER=192.168.0.2
rommon 5 > TFTP_FILE=c2600-i-mz.122-28.bin
rommon 6 > tftpdnld

          IP_ADDRESS: 192.168.0.1
      IP_SUBNET_MASK: 255.255.255.0
     DEFAULT_GATEWAY: 192.168.0.1
         TFTP_SERVER: 192.168.0.2
           TFTP_FILE: c2600-i-mz.122-28.bin
Invoke this command for disaster recovery only.
WARNING: all existing data in all partitions on flash will be lost!

Do you wish to continue? y/n:  [n]:  y

.
Receiving c2600-i-mz.122-28.bin from 192.168.0.2 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
File reception completed.
Copying file c2600-i-mz.122-28.bin to flash.


2. 설정 파일 백업 / 복구
  설정 파일을 백업하고 복구하는 것도 앞서 알아봤던 IOS 백업 및 복구 방법과 비슷합니다. 이전의 실습 환경과 동일한 환경에서 라우터의 이름을 'ConfigIsLoaded'로 바꾼 후 설정을 NVRAM에 저장한 뒤 TFTP 서버에 백업을 해보겠습니다.
  • 라우터의 IP: 192.168.0.1
  • TFTP 서버의 IP: 192.168.0.2
Router#configure terminal
Router(config)#hostname ConfigIsLoaded
ConfigIsLoaded(config)#^Z
ConfigIsLoaded#copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
[OK]
ConfigIsLoaded#copy startup-config tftp
Address or name of remote host []? 192.168.0.2
Destination filename [ConfigIsLoaded-confg]?

Writing startup-config...!!
[OK - 659 bytes]

659 bytes copied in 0.078 secs (8000 bytes/sec)
  이제 라우터의 NVRAM에 있는 설정 내용을 지우고 리부팅시켜 라우터를 초기의 상태로 돌린 후 TFTP 서버에 저장했던 설정 파일을 RAM으로 가져와서 다시 NVRAM에 저장하겠습니다. 여기서 주의해야 할 점은 TFTP 서버와 연결된 인터페이스의 IP와 서브넷은 당연히 수동으로 설정해야 한다는 겁니다. 그렇지 않으면 TFTP 서버 자체에 접근할 수 없을테니까요.
ConfigIsLoaded#erase startup-config
Erasing the nvram filesystem will remove all configuration files! Continue? [confirm]
[OK]
Erase of nvram: complete
%SYS-7-NV_BLOCK_INIT: Initialized the geometry of nvram
ConfigIsLoaded#reload
Proceed with reload? [confirm]
------------------------리부팅 메시지 생략------------------------
Router>enable
Router#configure terminal
Router(config)#interface fastEthernet 0/0
Router(config-if)#ip address 192.168.0.1 255.255.255.0
Router(config-if)#no shutdown

%LINK-5-CHANGED: Interface FastEthernet0/0, changed state to up

%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up

Router(config-if)#^Z
Router#copy tftp running-config
Address or name of remote host []? 192.168.0.2
Source filename []? ConfigIsLoaded-confg
Destination filename [running-config]?

Accessing tftp://192.168.0.2/ConfigIsLoaded-confg....
Loading ConfigIsLoaded-confg from 192.168.0.2: !
[OK - 659 bytes]

659 bytes copied in 3.046 secs (216 bytes/sec)

ConfigIsLoaded#copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
[OK]


참고 도서: CCENT / CCNA ICND1 Official Exam Certification Guide
참고 자료 제공: 강사 김기태
2010/08/25 15:43 2010/08/25 15:43
Posted
Filed under 네트워크
bandwidthclock rate는 모두 WAN 링크의 속도를 설정하는 명령어입니다. 때문에 이 두 명령어의 차이점을 질문을 하는 사람들이 많습니다. 일단 그걸 알아보기 전에 먼저 알아야 할 것이 있습니다. 라우터는 클로킹(Clocking)이라는 과정을 통해 CSU/DSU에서 정한 속도를 감지하여 물리적으로 맞춥니다. 그러므로 라우터는 시리얼 링크의 속도를 감지하기 위한 별도의 설정을 하지 않아도 됩니다.

  clock rate 명령어는 시리얼 링크의 초당 비트 전송 속도를 지정하는 명령어입니다. 하지만 전송 속도는 CSU/DSU에서 지정하는 것이기 때문에 보통은 필요가 없는 명령어입니다. 실제로 이 명령어가 필요한 경우는 CSU/DSU를 사용하지 않고 Back-To-Back 시리얼 케이블을 이용하여 라우터끼리 직접 연결(=Back-To-Back 연결)할 때입니다. 이 연결에서는 CSU/DSU를 쓰지 않기 때문에 두 라우터 중 한 라우터는 전송 속도를 포함한 클로킹을 반대쪽 라우터에 제공해야 합니다. 즉, DCE 케이블과 연결된 라우터는 clock rate 명령어를 사용하여 초당 비트 전송 속도를 설정해야 하며 이때 입력 값의 단위는 비트입니다. 주의할 것은 DTE 케이블이 연결된 인터페이스에서는 clock rate 명령어가 적용되지 않는다는 겁니다. 심지어 에러 메시지도 출력하지 않고 그냥 무시하기 때문에 실수를 하기 쉬운 부분입니다. 참고로 Packet Tracer에서 두 라우터를 연결할 때 케이블을 자동 선택으로 골라서 연결하면 먼저 클릭한 라우터에 DCE 케이블이 연결되므로 주의하시기 바랍니다. 만약 인터페이스에 설정된 clock rate 값이나 연결된 케이블의 종류(DCE, DTE)을 알고 싶다면 show controllers 명령어를 통해 확인이 가능합니다. 또한 clock rate 값의 경우 show running-config 명령어로도 확인이 가능합니다
1. clock rate 명령어로 인터페이스의 전송 속도를 128kbps로 설정
Router#configure terminal
Router(config)#interface serial 1/0
Router(config-if)#clock rate 128000

2. 인터페이스의 clock rate 및 연결된 케이블 확인
Router#show controllers serial 1/0
Interface Serial1/0
Hardware is PowerQUICC MPC860
DCE V.35, clock rate 128000
--------------뒷부분 결과 생략--------------

3. 설정한 clock rate 확인
Router#show running-config
--------------앞부분 결과 생략--------------
interface Serial1/0
 clock rate 128000
--------------뒷부분 결과 생략--------------
  bandwidth 명령어도 전송 속도를 설정하는 명령어라는 점에서 clock rate 명령어와 비슷하지만 이 명령어는 직접적인 전송 속도에 영향을 끼치지 않습니다. 대신 이 값은 라우팅 프로토콜에서 메트릭을 계산할 때 참조 용도로 사용됩니다. 예를 들어 EIGRP와 OSPF 프로토콜은 기본 메트릭을 계산하는데 이 값을 사용합니다. clock rate 명령어의 입력 값 단위가 비트인 것에 비해 이 명령어의 입력 값 단위는 kbps입니다. 그러므로 bandwidth 명령어로 값을 설정할 때나 show running-config 명령어로 값을 확인할 때 값이 100,000이라고 써 있으면 100 Mbps라는 의미입니다. 보이지는 않지만 모든 인터페이스에는 이 명령어의 디폴트 값이 존재합니다. 디폴트 값은 인터페이스의 종류에 의해 결정되며 시리얼 링크는 1544(=1.544 Mbps=T1 라인), 이더넷 인터페이스는 해당 인터페이스의 현재 속도와 동일한 값이 디폴트 값으로 작동합니다. 그러므로 같은 패스트이더넷 인터페이스라도 현재 100 Mbps로 작동하고 있으면 100,000이 적용되고 10 Mbps로 작동하고 있으면 10,000이 적용됩니다. 물론 수동으로 이 명령어를 사용하여 설정하면 설정한 값이 적용됩니다.
1. bandwidth 명령어로 인터페이스의 전송 속도를 128 kbps로 설정
Router#configure terminal
Router(config)#interface serial 1/0
Router(config-if)#bandwidth 128

2. 설정한 bandwidth 확인
Router#show running-config
--------------앞부분 결과 생략--------------
interface Serial1/0
 bandwidth 128
--------------뒷부분 결과 생략--------------


참고 도서: CCENT / CCNA ICND1 Official Exam Certification Guide
2010/08/25 12:37 2010/08/25 12:37
Posted
Filed under 네트워크
일반적으로 엔터프라이즈급에서는 라우터와 외부를 연결할 때 먼저 시리얼 케이블로 라우터와 CSU/DSU를 연결시킵니다. 통신 회사에서 설치하는 WAN 케이블에는 대개 RJ-48 커넥터가 붙어 있는데 이 커넥터를 CSU/DSU와 연결합니다. 참고로 RJ-48은 크기와 모양에 있어서 RJ-45와 동일합니다. 다만 최근에는 라우터의 시리얼 인터페이스에 CSU/DSU가 포함되어 있는 추세이기 때문에 RJ-48 커넥터를 직접 라우터의 시리얼 인터페이스에 연결하는 경우가 많습니다.

  엔터프라이즈급에서 라우터를 CSU/DSU와 연결하는 것과 달리 SOHO나 일반 가정집에서는 라우터(또는 공유기)를 케이블 모뎀(케이블TV 회선으로 인터넷에 연결)이나 DSL 모뎀(DSL로 인터넷에 연결)과 연결하며 이때 시리얼 케이블이 아닌 UTP 스트레이트 케이블로 연결합니다.

  엔터프라이즈의 CSU/DSU와 SOHO의 모뎀(케이블, DSL)은 역할상 비슷하나 큰 차이가 있습니다. CSU/DSU의 경우 통신 회사의 WAN 회선에 사용되는 1계층과 시리얼 케이블의 1계층 사이를 변환하지만 모뎀의 경우 이더넷 케이블과 케이블(CATV 또는 DSL) 사이의 1계층과 2계층을 모두 변환합니다. 따라서 엔터프라이즈에서 라우터와 CSU/DSU를 SOHO(또는 일반 가정집)에서는 모뎀과 라우터(또는 공유기) 사이를 UTP 스트레이트 케이블로 연결합니다.


참고 도서: CCENT / CCNA ICND1 Official Exam Certification Guide
2010/08/24 12:43 2010/08/24 12:43
Posted
Filed under 네트워크
관련 글: [네트워크] IPv4 어드레싱

  서브네팅은 IP 라우팅과 관련된 것을 논하기 전에 반드시 알아야 하는 지식입니다. 서브네팅이란 A, B, C 클래스에 속한 하나의 네트워크 주소를 더 작은 네트워크로 쪼개는 것을 말합니다. 즉, 이전에 설명한 A, B, C 클래스에 속한 하나의 네트워크가 국가급 규모라면 서브네팅은 그 하나의 국가를 다시 여러 도시로 나누는 것으로 비유할 수 있습니다.

  네트워크 주소란 특정 호스트 주소 범위를 대표하는 주소라고 할 수 있는데 현실적으로 체감할 수 있게 예를 들면 어떤 호스트의 IP 주소가 C클래스 주소인 222.121.111.222이고 서브네팅을 하지 않았다고 가정하면 해당 호스트는 222.121.111.0 네트워크에 속해 있다고 할 수 있습니다. 이 네트워크에 속하는 IP 주소 범위는 222.121.111.0 ~ 222.121.111.255입니다.(단, IP 주소 222.121.111.0은 지금 설명한 '네트워크 주소'라는 특수한 역할을 하고 222.121.111.255도 브로드캐스트라는 이미 예약된 특수한 주소이기 때문에 호스트에 할당할 수 없습니다.)

  이미 설명한 바와 같이 서브네팅을 하지 않아도 서브넷 마스크라는 것은 기본적으로 어느 IP에든 존재합니다. 각 클래스별 네트워크 부분의 주소 범위와 기본 서브넷 마스크는 다음과 같습니다.

  서브네팅에 대해 알기 전에 먼저 서브넷 마스크의 기본 개념에 대해 알아봅시다. '마스크(Mask)'라는 단어는 전산에서 '어떤 문자 패턴 일부분의 유지 또는 소거를 제어하기 위해 사용되는 문자 패턴'이라는 뜻을 지닙니다. 이름에서 풍기듯 서브넷 마스크는 IP 주소에서 네트워크와 호스트 부분을 나누는 기준을 나타내는 값입니다. 서브넷 마스크로 네트워크와 호스트 부분을 나누는 작업은 2진수로 이뤄집니다. 서브넷 마스크를 2진수로 바꿨을 때 1은 네트워크 부분, 0은 호스트 부분을 지칭합니다. IP 주소와 서브넷 마스크를 2진수로 바꾼 후 각 자리마다 부울 AND 연산을 해서 나온 결과가 '네트워크 주소'라는 값이 됩니다. 이렇게 각 자리마다 비트 연산을 하는 것을 Bitwise 부울 연산이라고 합니다. A, B, C 클래스의 IP 주소를 각 클래스에 해당하는 디폴트 서브넷 마스크로 연산하여 네트워크 주소를 구하는 예를 들어보겠습니다. 읽기 좋게 각 옥텟마다 띄어쓰기를 했습니다.

1. A 클래스 IP: 15.100.211.40(A 클래스의 디폴트 서브넷 마스크: 255.0.0.0)
00001111 01100100 11010011 00101000     <- 15.100.211.40   IP 주소
&&&&&&& &&&&&&& &&&&&&& &&&&&&&     <- Bitwise 부울 AND 연산
11111111 00000000 00000000 00000000     <- 255.0.0.0            서브넷 마스크
----------------------------------------------------------
00001111 00000000 00000000 00000000     <- 15.0.0.0              네트워크 주소

2. B 클래스 IP: 182.153.231.222(B 클래스의 디폴트 서브넷 마스크: 255.255.0.0)
10110110 10011001 10011001 11011110     <- 182.153.231.222   IP 주소
&&&&&&& &&&&&&& &&&&&&& &&&&&&&     <- Bitwise 부울 AND 연산
11111111 11111111 00000000 00000000     <- 255.255.0.0       서브넷 마스크
----------------------------------------------------------
10110110 10011001 00000000 00000000     <- 182.153.0.0       네트워크 주소

3. C 클래스 IP: 222.129.12.110(C 클래스의 디폴트 서브넷 마스크: 255.255.255.0)
11011110 10000001 00001100 01101110     <- 222.129.12.110   IP 주소
&&&&&&& &&&&&&& &&&&&&& &&&&&&&     <- Bitwise 부울 AND 연산
11111111 11111111 11111111 00000000     <- 255.255.255.0       서브넷 마스크
----------------------------------------------------------
11011110 10000001 00001100 00000000     <- 222.129.12.0       네트워크 주소

  위의 계산 과정을 보면 한 가지 흥미로운 사실을 알 수 있습니다. 2진수의 AND 연산은 비교하는 두 값이 모두 1일 때만 결과가 1이 됩니다. 그렇기 때문에 2진수로 서브넷 마스크가 1인 부분과 대응하는 IP 주소 부분은 그대로 자신의 값이 결과 값이 됩니다. 더 쉽게 말하면 값이 255인 서브넷 마스크 옥텟과 대응하는 IP 주소 옥텟은 따로 연산할 필요가 없이 그대로 자기 자신의 값이 결과가 됩니다. 같은 이유로 값이 0인 서브넷 마스크 옥텟과 대응하는 IP 주소 옥텟은 무조건 결과가 0이 됩니다. 이로 인해 서브네팅이 되지 않은(즉, 디폴트 서브넷 마스크를 쓰는) IP 주소는 별도의 계산이 필요 없이 바로 해당 IP 주소의 네트워크 주소를 구할 수 있습니다.

  또한 서브넷 마스크는 반드시 2진수로 1의 연속 후 0의 연속으로 이뤄져 있어야 합니다. 1과 0이 섞여 있으면 서브넷 마스크 값이 될 수 없습니다. 그렇기 때문에 255.255.64.0(2진수로 11111111 11111111 01000000 00000000) 같은 서브넷 마스크 값은 존재할 수 없습니다. 이러한 규칙 때문에 서브넷 마스크를 더 간단히 표현할 수 있는 방법이 있는데 이것을 프리픽스 표기법(Prefix Notation) 또는 CIDR(Classless Inter-Domain Routing) 표기법이라고 부릅니다. 이것은 슬래쉬(/) 문자 뒤에 서브넷 마스크를 2진수로 만들었을 때 나오는 1의 개수를 적어 표기하는 겁니다. 예를 들어 IP 주소가 192.168.0.24이고 서브넷 마스크가 255.255.255.0이라면 CIDR로 표기할 경우 '192.168.0.24/24'가 됩니다. 또한 2진수를 기준으로 서브넷 마스크의 첫 번째 비트는 반드시 1로 시작합니다. 그러므로 서브넷 마스크의 첫 번째 옥텟은 128 이상의 값을 가집니다.

  지금까지 서브네팅을 하지 않은 IP 주소들에 대해 다뤘습니다. 그렇다면 서브네팅을 하면 과연 어떤 모양이 될까요? 바로 아래의 그림처럼 됩니다.

클래스풀 어드레싱(Classful Addressing)

  이렇게 IP 주소를 네트워크, 서브넷, 호스트로 나누는 것을 클래스풀 어드레싱(Classful Addressing)이라고 부릅니다. 이렇게 불리는 이유는 주소의 네트워크 부분이 A, B, C 클래스를 토대로 결정되기 때문입니다. 그런데 라우팅의 관점으로 보면 네트워크 부분과 서브넷 부분은 결국 해당 주소가 어느 네트워크에 속해 있는지를 알려주기 위해 존재합니다. 즉, 같은 목적을 가진 하나의 존재로 볼 수 있는 것이죠. 이렇게 네트워크 클래스와 서브넷을 하나로 합쳐서 보는 개념을 클래스리스 어드레싱(Classless Addressing)이라고 합니다. 클래스리스 어드레싱은 IP 주소를 네트워크 부분과 호스트 부분만으로 나눕니다. 그리고 그 네트워크 부분을 '서브넷'이나 '프리픽스'라고 부릅니다.

클래스리스 어드레싱(Classless Addressing)

  그럼 서브네팅을 했을 때의 모습도 대강 살펴봤으니 본격적으로 서브네팅에 대해 알아보겠습니다. 서브네팅의 궁극적인 목표는 결국 IP 주소를 아끼는 겁니다. 아래 그림을 봅시다.

서브네팅을 하지 않은 경우

  그림처럼 각 네트워크마다 B 클래스 네트워크 주소를 하나씩 할당했다고 합시다. 물론 IP 할당을 총괄하고 있는 기관인 ICANN에서 절대로 4개씩이나 되는 B 클래스 네트워크 주소를 저렇게 낭비하게 할당해주지도 않겠지만 일단 서브네팅의 유용함을 강조하기 위해 극단적인 예를 들어보겠습니다. 하나의 B 클래스 네트워크는 65,534개의 호스트 주소를 가지고 있습니다. 그런데 실제로 사용하고 있는 주소는 150.1.0.0, 150.2.0.0, 150.3.0.0에서 각각 2개씩, 150.4.0.0에서 3개를 사용하여 총 9개만 사용하고 있습니다. 그림에서 4개의 B 클래스 네트워크 주소(150.1.0.0 ~ 150.4.0.0)를 사용하고 있으므로 사용할 수 있는 호스트 주소는 총 262,136개이고 그 중 9개만 사용하고 있어 262,127개의 IP 주소를 낭비하고 있는 겁니다. 이번에는 서브네팅을 사용하는 그림을 보도록 하겠습니다.

서브네팅을 한 경우

  이번에는 150.1.0.0이라는 하나의 B 클래스 주소를 가지고 서브네팅을 하여 사용한 그림입니다. 서브네팅을 하지 않았을 때와 달리 이번에는 하나의 B 클래스 네트워크만 사용했으므로 65,525개의 주소만 낭비하게 됩니다. 예가 극단적이라 여전히 낭비가 크지만 262,127개에 비하면 훨씬 적게 낭비하는 셈입니다.

  서브네팅의 방법 자체는 별거 없습니다. 위에서 설명했던 디폴트 클래스 서브넷을 통해 네트워크 주소를 구하는 것과 방법은 동일합니다. 다만, 서브네팅을 할 때는 네트워크와 호스트의 경계를 옥텟 단위로 자르는 것이 아니라 호스트 부분을 자유자재로 자르기 때문에 계산이 좀 더 복잡해집니다. 일단 가장 기본이 되는 2진수->10진수와 10진수->2진수 변환에 대해 알 필요가 있습니다.

  2진수로 표현된 IP를 10진수로 바꿀 때는 먼저 각 옥텟이 8자리의 2진수라는 것을 알고 있어야 합니다. 2진수일 때 각 자리별 값을 10진수로 나타내면 아래와 같습니다.

10000000 = 128
01000000 = 64
00100000 = 32
00010000 = 16
00001000 = 8
00000100 = 4
00000010 = 2
00000001 = 1

  이거 하나만 정확히 알고 있으면 2진수와 10진수 사이의 변환을 문제 없이 할 수 있습니다. 만약 2진수 '10110010'을 10진수로 바꾸려면? 위에 나온 것을 참조하면서 1로 된 부분에 해당하는 값을 하나하나 더하기만 하면 됩니다. 그러므로 답은 128+32+16+2=178이 되겠습니다. 10진수 178을 2진수로 바꾸고 싶다면? 178은 128 이상이므로 '1'을 적고 128을 뺍니다. 그 결과를 다음 값인 64와 비교합니다. 결과인 50은 64 미만이므로 '0'을 적습니다. 이런 식으로 위의 순서대로 차례차례 비교하여 적어나가면 결국 8자리의 2진수 '10110010'가 완성됩니다.

  서브네팅은 한 클래스의 네트워크를 더 작은 네트워크로 나눠서 쓰는 것이기 때문에 얼마나 작게 나눌 것인지 계획하고 그에 맞게 서브넷 마스크를 정하는 방법을 알아야 합니다. 서브네팅은 호스트 주소 부분 중 일부를 뺏아서 하위 네트워크인 서브넷으로 이용하는 것이기 때문에 서브넷을 많이 만들수록 각 서브넷 당 호스트 주소는 줄어들게 됩니다. 이는 이미 위에서 나온 A, B, C 클래스의 클래스풀 어드레싱 그림을 통해서도 확인할 수 있습니다.

  서브넷 부분으로 사용하는 비트 수로 서브넷의 개수를 알 수 있고 호스트 부분으로 사용하는 비트 수로 서브넷당 호스트 주소의 개수를 알 수 있습니다. 서브넷 부분의 비트 수를 s, 호스트 부분의 비트 수를 h라고 한다면 공식은 아래와 같습니다.
  • 서브넷의 개수 = 2^s(제로 서브넷과 브로드캐스트 서브넷을 활용하지 않을 경우 2^s - 2)
  • 서브넷당 호스트 주소의 개수 = 2^h - 2
  서브넷당 호스트 주소의 개수에서 2개를 제외하는 이유는 호스트 부분의 비트가 전부 0인 '네트워크 주소'와 호스트 부분의 비트가 전부 1인 '브로드캐스트 주소'는 호스트에 할당할 수 없는 예약된 주소이기 때문입니다. 그런데 이와 비슷한 개념의 주소가 서브넷에도 2개 있습니다. 호스트에서 사용할 수 없는 주소와 마찬가지로 모든 서브넷의 비트가 0인 경우와 1인 경우입니다. 단, 주의할 것은 호스트 부분의 해당 주소들은 무조건 사용할 수 없는 것과 달리 이 2개의 서브넷 주소는 디폴트로 사용할 수 있는 주소입니다. 즉, 별도의 설정을 하지 않으면 사용할 수 있습니다. 이 2개의 특별한 서브넷 주소에 대해서는 잠시 후에 알아보겠습니다.

  먼저 서브넷의 개수를 구하는 방법을 알아봅시다. 150.150.0.0이라는 B 클래스 네트워크 주소를 가지고 100개의 서브넷을 만든다고 가정하겠습니다. 2의 제곱 중 원하는 서브넷 개수를 처음으로 만족하는 제곱 수를 구합니다. 2^1=2, 2^2=4, 2^3=8, 2^4=16, 2^5=32, 2^6=64, 2^7=128, 2^8=256이므로 7제곱이 지금 구하는 조건에 가장 최적이 됩니다. 이 제곱의 수만큼 '1'을 아래처럼 B 클래스의 디폴트 서브넷 마스크 뒤에 붙이면 됩니다.

11111111 11111111 00000000 00000000   <- B 클래스의 디폴트 서브넷 마스크(255.255.0.0)
                                       11111110 00000000   <- 1을 7개 채운 뒤 나머지를 0으로 채운다.
----------------------------------------------------------
11111111 11111111 11111110 00000000   <- 완성된 서브넷 마스크(255.255.254.0)

  이래서 서브넷 마스크는 2진수로 1의 연속 후 0의 연속으로 이루어지는 것입니다. 완성된 서브넷 마스크를 10진수로 표기하면 '255.255.254.0'이 되고 이것을 CIDR 표기법으로 표기하면 '/23'이 됩니다. 남은 호스트 비트가 9비트이므로 각 서브넷당 호스트의 개수는 2^9 -2 = 510개가 됩니다. 만약 위의 상황에서 서브넷을 500개 만들고 싶다면? 2^9=512가 이 조건에 가장 근접하므로 서브넷 마스크는 '255.255.255.128'이 될 것이며 CIDR로 '/25'가 될 것입니다. 남은 호스트 비트는 7개이므로 각 서브넷당 호스트의 개수는 2^7 - 2 = 126개가 됩니다.

  위의 접근법과 반대로 만약 서브넷당 호스트가 10개 정도가 되도록 만드려면 어떻게 할까요? 2의 제곱 중 10 이상이면서 가장 가까운 수는 2^4=16입니다. 서브넷당 2개의 호스트 주소를 쓸 수 없으므로 여기서 2를 뺍니다. 그 결과 값은 14이며 그래도 여전히 10 이상의 값이므로 조건에 만족합니다. 이제 2의 제곱의 수만큼 낮은 자리에 0을 붙이고 나머지 높은 자리에는 1을 붙입니다..

11111111 11111111 00000000 00000000   <- B 클래스의 디폴트 서브넷 마스크(255.255.0.0)
                                      11111111 11110000   <- 맨 뒤에 0을 4개 채운 뒤 나머지를 1로 채운다.
----------------------------------------------------------
11111111 11111111 11111111 11110000   <- 완성된 서브넷 마스크(255.255.240.0)

  이거면 필요한 서브넷, 호스트의 개수를 기준으로 적절한 서브넷 마스크를 만들 수 있습니다. 하지만 안타깝게도 여기서 끝이 아닙니다. 서브네팅에서 가장 귀찮은 것이 남았는데 바로 각 서브넷의 시작 주소와 마지막 주소를 구하는 것입니다. 먼저 192.168.11.0의 C 클래스 네트워크를 255.255.255.240의 서브넷 마스크로 나누겠습니다. CIDR로 표기하면 192.168.11.0/28이 되겠네요. 서브넷 부분이 4비트, 호스트 부분이 4비트이므로 서브넷이 16개, 서브넷당 호스트가 14(16-2)개입니다. 그렇다면 각 서브넷당 호스트의 주소들은 어떻게 될까요?

192.168.11.0/28 서브네팅

  192.168.11.0/28로 서브네팅된 네트워크는 위와 같은 모습이 됩니다. 약간 복잡해 보인다면 2진수로 바꾼 각 서브넷 주소들의 마지막 옥텟을 비교해봅시다.

첫 번째 서브넷 주소의 4번째 옥텟 : 00000000 = 10진수 0
두 번째 서브넷 주소의 4번째 옥텟 : 00010000 = 10진수 16
세 번째 서브넷 주소의 4번째 옥텟 : 00100000 = 10진수 32
네 번째 서브넷 주소의 4번째 옥텟 : 00110000 = 10진수 48

  느낌이 오십니까? 당연하지만 서브넷을 이루는 비트가 마지막 옥텟의 상위 4비트이므로 이 값이 하나씩 증가할 때마다 다음 서브넷으로 넘어가게 됩니다. 나머지 하위 4비트는 호스트의 주소를 표현하는데 사용합니다. 물론 모든 비트가 0이면 서브넷 자체를 나타내므로 사용할 수 없고 모든 비트가 1이어도 브로드캐스트 주소가 되므로 사용할 수 없습니다. 이 개념들을 잘 기억하고 서브넷 계산을 반복해서 연습하면 쉽게 익숙해질 수 있습니다.

  사실 각 서브넷을 구하는데는 쉬운 계산법이 있습니다. 서브넷 마스크의 각 옥텟 값을 보면 255나 0이 아닌 값이 하나 있을 겁니다. 위에서 사용한 서브넷 마스크 값인 255.255.240.0을 예로 들면 240이 여기에 해당합니다. 이 값을 256에서 뺍니다. 그 결과의 배수가 각 서브넷의 주소입니다. 0, 16, 32, 48...위와 딱 들어맞죠? 당연히 256 이전의 배수까지만 유효합니다. 여기서 한 가지 예외가 있다면 서브넷 비트의 길이가 한 옥텟을 넘는 경우입니다. 만약 150.150.0.0을 255.255.255.240으로 서브네팅(150.150.0.0/28)한다면 어떻게 해야 할까요? 일단 배수는 16으로 동일합니다. 이전의 예처럼 똑같이 16의 배수로 각 서브넷 주소를 구합니다. 그러다가 256이 되는 순간이 옵니다. 이때 앞의 옥텟의 값을 1 증가시키고 마지막 옥텟을 0으로 초기화 합니다. 즉, 150.150.0.240의 다음 서브넷 주소는 150.150.1.0이 됩니다. 이것을 계속하여 B 클래스의 네트워크 주소가 바뀌기 전의 주소가 마지막 서브넷 주소(=브로드캐스트 서브넷)가 됩니다. 이 경우엔 150.150.255.240이 되겠군요.

  마지막으로 아까 설명을 마치지 못했던 2개의 특별한 서브넷 주소에 대해서 알아보겠습니다. 설정에 따라서 서브넷 주소에도 호스트 주소처럼 사용하지 못하는 주소가 2개 있으며 해당 주소들은 다음과 같습니다.

  1. 제로 서브넷(Zero Subnet) 또는 서브넷 제로(Subnet Zero) : 모든 서브넷 비트가 0인 서브넷. 제로 서브넷의 서브넷 주소는 항상 클래스풀 네트워크 주소와 같다는 특징이 있습니다. 예를 들어 B클래스 네트워크인 150.120.0.0를 서브네팅했다면 어떻게 서브네팅을 했던 간에 서브넷 부분의 모든 비트가 0이므로 제로 서브넷 주소는 언제나 150.120.0.0이 됩니다. 그렇기 때문에 150.120.0.0이라고 하면 이게 150.120.0.0이란 B 클래스 네트워크 전체를 말하는 것인지, 아니면 150.120.0.0을 (어떻게든)서브네팅한 상태의 첫 번째 서브넷 주소인가가 혼돈되기 때문에 네트워크 초기에는 사용하지 않았지만 이것은 많은 주소를 낭비하는 결과를 초래했기 때문에 현재는 기본으로 사용하도록 되었습니다.
  2. 브로드캐스트 서브넷(Broadcast Subnet) : 모든 서브넷 비트가 1인 서브넷. 이 주소는 네트워크 브로드캐스트 주소와 동일하게 서브넷의 모든 호스트로 패킷을 전송하는 주소로 예약된 주소였었습니다. 만약 150.120.0.0을 255.255.240.0으로 서브네팅한 B 클래스 네트워크가 있다고 가정합시다. 만약 150.120.255.255로 패킷을 보낸다면 이 패킷은 150.120.0.0 네트워크 전체의 호스트에게 보내는 패킷이 될까요? 아니면 150.120.240.0 서브넷에 속한 호스트들에게 보내는 패킷이 될까요? 이런 애매함 때문에 예전에는 사용할 수 없는 주소였지만 제로 서브넷과 같은 이유로 현재는 기본으로 사용하고 있습니다.
  이 2개의 주소를 일반적인 서브넷 주소로 사용하려면 라우터에서 전역 설정 명령어인 'ip subnet zero'를 설정되어 있어야 하는데 사실 디폴트로 설정되어 있습니다. 그러므로 'no ip subnet zero' 명령어를 사용하지 않는다면 기본적으로 위에서 설명한 제로 서브넷과 브로드캐스트 서브넷을 일반적인 서브넷 주소로 사용할 수 있습니다.


참고 도서: CCENT / CCNA ICND1 Official Exam Certification Guide
2010/08/19 16:50 2010/08/19 16:50