아래글은 세노님이 쓰신 글입니다. 세노(박병석)님이 예전에 쓰신 글을 퍼옵니다..^^

이글에 대한 저작권은 세노님한테 있습니다. ^^;

저는 첨에 이글을 보고.. 이야~! 참 기똥차다~! 라는 말이 저절로 나오더군요...ㅎㅎ

--------------------------------------------------------------------------

제로님께서 요청하셨던 '어떻게 null interface 가 routing loop 을 방지하는가'에 대해 말씀드리고자 합니다.

null interface 는 제로님께서 비팬에 올리신 글에서 말씀하셨듯이 특정 주소를 목적지로 하는 트래픽을 discard 시키기 위해 사용하며, access-list 와는 달리 라우터의 CPU 를 적게 사용하기 때문에 효과적으로 라우터의 부하를 줄이는 방법 으로 사용됩니다.
그런데, 이러한 잇점과 아울러 null interface 는 routing loop 을 방지하는데 일조하기도 합니다.

일반적으로 EIGRP 나 BGP 에서 specific 한 어드레스를 summarization 하게 되면, summarization 과 동시에 저절로 null interface 가 라우팅 테이블에 생성되는 것을 볼 수 있습니다. 바로 이것이 routing loop 을 방지하기 위해 생성되는 것입니다.

이해를 돕기 위해 하나의 예를 들어보겠습니다.

192.168.4.0 / 24 ---I
192.168.5.0 / 24 ---I------ [Router A] ------ [Router B] ------ [Internet]
192.168.6.0 / 24 ---I BGP BGP
192.168.7.0 / 24 ---I

Router A 와 Router B 사이에는 BGP 가 동작한다고 가정합니다.
Router A 의 뒷단에는 위와 같이 네 개의 C class 네트웍이 존재합니다.
Router A 는 ISP 망에 존재하는 Router B 를 통해 외부 Internet 으로 나갑니다.
Router A 에서 Router B 쪽으로 default route 를 설정합니다.

이런 상황에서, flapping 으로 인한 네트웍 토폴로지의 변화를 localize 함으로써 네트웍을 안정적으로 유지하고, 라우팅 테이블의 엔트리의 숫자를 줄임으로써 라우팅 테이블의 크기를 줄여 결과적으로 효율적으로 bandwidth 를 사용하기 위해 Router A 뒷단에 있는 네 개의 C class 네트웍을 하나의 네트웍(192.168.4.0 / 22)으로  summarization 해서 (이 경우엔 CIDR 이겠지요?) Router B 로 advertise 했다고 가정해보죠. 여기서는 summary-only 키워드를 통해 summary 된 정보만 advertize 했다고 가정하겠습니다.

이 경우에 Router A 에는 다음과 같은 라우팅 테이블이 존재할 것입니다.

- Router A -

192.168.4.0 / 24
192.168.5.0 / 24
192.168.6.0 / 24
192.168.7.0 / 24
192.168.4.0 / 22 null 0
0.0.0.0 via Router B

여기서 null 0 는 summarization 과 동시에 자동으로 생성된 null interface 입니다.
물론, 이보다 specific 한 route 가 존재하기 때문에 longest match 에 입각하여 null interface 로 인해 discard 되는 트래픽은 존재하지 않을 것입니다.

그리고 Router B 에는 다음과 같은 라우팅 테이블이 존재할 것입니다.
당연히 Router A 에서 summarization 한 결과를 넘겨줬기 때문에 Router B 의 라우팅 테이블에는 summary 된 결과만이 존재할 것입니다.

- Router B -

192.168.4.0 / 22 via Router A

자, 눈채 채셨습니까? 제로님.
일반적인 경우 아무런 문제없이 Router A 와 Router B 사이에 트래픽이 오고 갈 것 입니다. 물론 이 경우 저절로 생성된 null interface 는 유명무실하겠지요?
그런데!!!
Router A 의 뒷단에 있는 네트웍 가운데 하나, 예를 들어 192.168.7.0 네트웍으로 통하는 link 가 down 되었다고 가정해 봅시다. 어떤 일이 발생할까요?

먼저, Router B 의 라우팅 테이블은 변화가 없을 것입니다. flapping 이라고 보긴 어렵지만 - 아니, 조금 큰 규모의 flapping 이라고 보아야 할까요? - 어찌됐건 summary 된 모든 네트웍이 다 없어지지 않는 한 Router B 에는 Router A 로부터 건네 받은 summary 된 정보가 라우팅 테이블에 올라와 있을 것입니다.
그렇다면, 외부 Internet 에서 192.168.7.0 을 목적지로 하는 트래픽은 무리없이 Router A 로 전달되겠지요?

하지만 Router A 의 라우팅 테이블은 어떻게 변했을까요?
다음과 같이 192.168.7.0 / 24 엔트리는 사라지고 없을 것입니다.

192.168.4.0 / 24
192.168.5.0 / 24
192.168.6.0 / 24
192.168.4.0 / 22 null 0
0.0.0.0 via Router B

여기서 바로 null interface 의 진가가 나타나는 것이지요.

만약 null interface 가 없다면, Router B 로부터 전달받은 192.168.7.0 을 목적지로 하는 트래픽은 default route 를 통해서 다시 Router B 로 전달될 것입니다. 그리고 여기서 바로 routing loop 이 발생하는 것이지요. 하지만 null interface 가 존재하기 때문에 192.168.7.0 을 목적지로 하는 트래픽은 discard 되고 말 것입니다.

명확하게 정식화하지는 못했지만.. 대강 감이 잡히나요?
위의 내용들을 무시하시고 종이에 다시 한번 그림을 그려보며 하나하나 짚어보세요.
별 내용 아니지만 그래도 궁금해하시는 것 같아 글을 올렸습니다.
재밌게 보셨는지 모르겠네요.

행복한 주말 보내시기 바랍니다.
그럼 이만..

출처:빅보스님

- 네트워크 전문가 따라잡기 카페 펌.

이글은 진강훈씨 홈페이지에서 가져온 글입니다

27.라우팅 프로토콜과 라우티드 프로토콜

우리가 라우터를 사용하다 보면 여러 가지 비슷한 말들을 많이 만나게 되고 이게 혼동되기 시작하면서 라우터가 어렵다는 이야기를 많이 하게 되는데 그 중에 하나가 바로 이 라우팅 프로토콜과 라우티드 프로토콜이 아닐까 합니다.

지금까지 우리가 배웠던 TCP/IP 그리고 IPX, 애플토크 등 우리가 아는 모든 프로토콜은 전부가 라우티드 프로토콜입니다.

라우티드 프로토콜(Routed Protocol)이란 말 그대로 라우팅을 당하는, 즉 라우터가 라우팅을 해주는 고객을 뜻합니다. 즉 라우터라는 자동차에 올라타고 여행을 떠나는 승객이라고 생각하시면 될 겁니다. 그러니까 TCP/IP나 IPX 같은 녀석들이 라우터란 자동차를 타고 다른 네트워크로 여행을 떠나는 겁니다.

그렇다면 라우팅 프로토콜은 그 자동차를 안전하고 빠르게 운전하는 운전기사라고 볼 수 있습니다. 즉 라우터에 살면서 라우티드 프로토콜들에게 목적지까지 가장 좋은 길을 갈 수 있게 해주는 역할을 하는 녀석입니다.

따라서 라우터 입장에서는 어떤 운전기사(라우팅 프로토콜)를 채용하는가에 따라서 라우터의 성능(즉 얼마나 빨리, 그리고 안전하게 가는가)이 결정된다고 봐도 될 겁니다. 물론 자동차(라우터)가 가지고 있는 기본적인 성능도 중요하겠지만 말입니다.

이런 라우팅 프로토콜에는 RIP(Routing Information Protocol), OSPF (Open Shortest Path First), EIGRP(Enhanced Interior Gateway Routing Protocol - 이건 시스코에서만 쓰는 프로토콜) 등이 있습니다. 물론 이거 말고도 많지만 우선은 이 정도만 알고 계시면 될 겁니다.

전에도 한번 말씀드린 적이 있지만 이런 라우팅 프로토콜을 다른 말로는 라우팅 알고리즘이라고도 합니다.

이런 라우팅 알고리즘은 자신의 라우팅 테이블을 가지고 있으면서 자기가 찾아갈 경로에 대한 정보를 이곳에 기억해둡니다. 어디가 가장 빠르고 안전한 길인가 하고 말입니다.

즉 라우팅 테이블 운전기사(라우팅 프로토콜)가 가지고 있으면서 어떤 길이 가장 좋은 길인가 하고 메모해두는 이정표같은 것이라고 생각하시면 될 겁니다.

따라서 라우팅 테이블은 일종의 메모리라고 생각하시면 되고, 또 어떤 알고리즘을 사용하는가에 따라서 라우팅 테이블의 내용은 달라지게 됩니다. 그렇겠죠 ? 운전기사별로 메모하는 버릇이 다를 테니까 말입니다.

그럼 라우팅 테이블에는 어떤 내용이 들어갈까요? 주로 이런 내용입니다. 목적지, 그리고 그 목적지까지의 거리, 그리고 어떻게 가야 하는가 등의 내용입니다.

또 라우팅 테이블은 시간이 지나면서 계속 업데이트됩니다. 즉 변한다는 겁니다. 새로운 길이 생길 수도 있고 새로운 목적지가 추가될 수도 있기 때문입니다. 끊임없이 변화하는 게 바로 라우팅 테이블입니다.

그렇다면 라우팅 알고리즘은 목적지까지의 가장 빠르고 안전한 길을 어떤 조건들을 가지고 찾아낼까요? 그건 사용하는 라우팅 프로토콜(라우팅 알고리즘)에 따라 전부 다릅니다. 다음 시간부터는 이런 라우팅 프로토콜에 대해서 하나하나 공부해 보도록 하겠습니다.

자 그럼 이번 시간의 결론.

라우티드 프로토콜은 라우터란 자동차에 타는 승객이고 이 자동차를 운전하는 녀석이 바로 라우팅 프로토콜이다. 그리고 자동차는 라우터다. 이 자동자의 운전기사는 자기가 가는 목적지에 대한 이정표를 가지고 있는데 이걸 라우팅 테이블이라고 하고 이 라우팅 테이블은 운전자마다 모두 다르다. 여기까지입니다. 안녕 ^^ (www.dataNet.net)

라우팅과 라우팅 프로토콜에는 몇 가지의 문제가 있다. IP 소스(source) 라우팅은 IP 패킷 내에 의도하는 목적지의 경로가 상세하게 포함되어 있는데 RFC 1122 에 의해 목적지 호스트와 같은 경로를 반응해야 하기 때문에 매우 위험하다. 만약 공격자가 소스 라우팅된 패킷을 여러분의 네트워크 내부에 발송할 수 있다면 반응하는 메시지를 가로채어 여러분의 호스트를 마치 신뢰 관계에 있는 호스트와 통신하는 것처럼 만들 수 있기 때문이다.

따라서 모든 네트워크 인터페이스에서 IP 소스 라우팅을 사용할 수 없도록 설정하여 이 보안 결함을 차단하는 것이 좋다. 여기서는 모든 인터페이스에 대해 IP 소스 라우팅을 차단한다. 물론 두 번째 카드인 eth1에 대해서도 차단하는데 만약 이더넷 카드가 1개라면 sysctl.conf 파일에서 eth1 관련 설정은 제외하고 명령을 입력한다.

- 1단계

IP 소스 라우팅을 차단하기 위해 아래와 같이 입력한다.

'vi /etc/sysctl.conf'로 sysctl.conf 를 읽어 아래와 같이 추가한다.

#IP 소스 라우팅을 차단한다.
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.lo.accept_source_route = 0
net.ipv4.conf.eth0.accept_source_route = 0
net.ipv4.conf.eth1.accept_source_route = 0
net.ipv4.conf.defalut.accept_source_route = 0

- 2단계

일단 설정이 완료된 후에는 변경된 내용이 적용되도록 네트워크를 다시 시작한다.
네트워크를 재시작하는 명령은 아래와 같다.

모든 네트워크 장치를 수동으로 재시작하려면 아래와 같이 입력한다.

#/etc/rc.d/init.d/network restart

이 옵션은 커널 설정과 관계가 있다. 만약 호스트에서 이 옵션이 yes로 설정 되었다면 IP 소스 라우팅을 허용한다는 것이므로 반드시 no로 설정되어 있어야 한다. 1은 yes의 의미이고 0은 no의 의미이다. 네트워크를 재시작하지 않고도 아래와 같이하면 변경된 내용을 적용할 수 있다.

#sysctl -w net.ipv4.conf.all.accept_source_route=0
#sysctl -w net.ipv4.conf.lo.accept_source_route=0
#sysctl -w net.ipv4.conf.eth0.accept_source_route=0
#sysctl -w net.ipv4.conf.eth1.accept_source_route=0
#sysctl -w net.ipv4.conf.default.accept_source_route=0

현재상황을 말쓰드리겠습니다.

1. PC ↔ 더미허브 ↔ C2900 ↔ C5500 ↔ C3640  ===== T3 ===== C3640 ↔ C5500 ↔ 서버팜
 
  왼쪽의 C2900은 약 10대 정도이며, C2900 밑으로는 각각 7대 정도의 더미허브가 Cascade되어
  있습니다. PC 댓수는 약 600여대 정도 입니다.

2. MRTG 운영
  C3640의 Hssi를 MRTG로 모니터링 해서 보면, MAX IN 19메가 // MAX Out 10메가 정도 입니다.

3. 의사결정자의 요구사항
  그래프를 보면 30메가 만으로 충분하지 않느냐, KT와 쇼부쳐서(^^;;) 30메가로 줄여라,
  회선비 줄이자라고 요구함(30메가로 서비스 받는 곳 몇군대 있음).

4. 저의 의견
  서비스 제공에는 지장이 없겠으나, 서버팜으로부터 각각의 애플리케이션들이 다운로드
  받는 속도가 다소 느려지오니 30메가로 대역폭을 줄이는 것은 고려할 만한 사항이 아님.


핵심 쟁점을 말씀드리겠습니다.

1. 의사결정자 :
  - MRTG 그래프를 보면 30메가로도 충분 할 것 같은데 왜 속도가 느려지느냐?
    그만큼 사용자의 사용률이 높지 않다는 것이 아니냐?

  - 그리고, 왜 45메가를 풀로 사용을 안하고 inbound가 20메가 수준에서 머물러 있느냐?


2. 제 설명 :
  - 회선 대역폭(Bandwidth)는 도로에서의 차선과 제한 속도를 합친 개념 이다.

    때문에,  45메는 45차선//제한속도 90KM의 도로이고
    30메가는 30차선//제한속도 60KM의 도로 이다.

    그래서 30메가로 대역폭을 줄이면 서버팜과 PC간의 데이터 전송 속도가 다소 느려지는 것이다.

  - 모든 사용자의 PC가 단 1초도 쉬지 않고 계속해서 Data를 송, 수신하는 것은 아니지 않느냐
    5초, 5분의 평균 값이므로 그렇다.

위와같이 설명을 했는데 도저히 이해를 못합니다.
당연합니다. 저도 즉흥적으로 비유를 든 것이라서요..

질문 1. 제가 비유를 든 것이 적정한지요?
       한번에 Data가 들어오는 차선이 넓기 때문에 속도가 빠른 것이지,
       제한 속도라는 것이 있는 것은 아니지 않습니까?

질문 2. 정말 30메가로 줄일경우 전송 시간이 늘어 나는지요?

질문 3. 어째서 사용자가 가장 많이 사용하는 시간대에도
       MRTG 그래프의 MAX In이 45메가로 안나오는 것인지요?

       상식적으로 사용이 많으면 어느정도 45메가에 근접한 량이 나와야
       되는 것이 아닌지요?

       MRTG를 이용해서 적정 회선 대역폭을 산출하는 것이 가능할까요?


질문 4. 가장 궁극적인 질문이 되겠습니다. 속도와 BandWidth에 대한 개념이
       도무지 잡히지 않습니다. 설명 부탁 드립니다.

ohchungryum	한가지만 말씀드리죠. 님께서 말씀하신 사항은 장비의 성능을 무시한 결과이기때문에 이해하시기 어려운것입니다. T3를 연결하고 있는 C3640의 경우 최대 전송 성능이 100메가정도 되는데, 이건 단순히 전송처리만 할경우의 시스코 측정치이고, 실제로 이 라우터에서 어떤 트래픽을 전송하는지, 패킷 포워딩외에 어떤 처리를 하고 있는지에 따라 전송 성능은 크게 달라집니다. 한가지 예를 보여드리면, C3640의 최대 전송속도 : 50 - 70kpps (1) 64byte 패킷의 경우 = 70,000 x 64 = 4.48M (2) 1500byte 패킷의 경우 = 70,000 x 1500 = 105M 단순히 처리가능한 최대 패킷수를 70,000개로 봤을때 패킷의 사이즈에 따라 이렇게 큰 차이가 납니다. 아무리 유저의 사용량이 많은 시간대라고 하더라도 위 공식에 의하면 현실상 C3640의 경우 평균 최대전송량 30M를 넘기기는 어렵습니다. 위 네트워크는 라우터에서 병목현상이 일어나고 있을 가능성이 크니, 그쪽을 먼저 분석해서 해결하는게 우선적으로 해야할 일일듯 싶네요..-------한 유저분의 대답 ,이 의견에 관해서도 고수님들의 생각 부탁 드립니다.. 09/15 09:52
키미지투	사족) 어떤 넘의 성능이 100 이라고 가정했을때, 그넘이 100 을 다 쓰면 바꿔야 할까요??.. 그건, 아니겠죠.. 장비(벤더)마다 그 수치가 틀릴 수 있고, End User 의 환경에 따라서도 많이 틀려집니다. [그럼, 도대체 언제 바꿔(업그레이드)??] 가 Key 가 되겠져.. 내부 네트웍이 Clean 이라는 가정에서 (No Worms etc), 일반적으로 x % 를 넘어서면 개선(Upgrade)을 해라~ 고 합니다.. 물론, 여기서 x 는 임계치이며, 각 항목마다 틀립니다.. 가장, 기본적인것이 Ethernet 40%, CPU 70%, WAN 70% 등입니다.. 따라서, 위의 사항에서 HSSI(45M) 에서의 20M 는 50% 미만으로 적정한 수준을 유지하는 것이지만, 30M 회선에서 20M 사용은 거의 70% 에 육박하므로 제안하기가 쪼금 그렇네요.. ^^ 09/15 10:43
봉창	1. E1 이나 T3 회선에서는 속도와 밴드위스가 동일합니다. 유선에선 거의 동일하게 생각하고, 무선(무선랜, M/W, 위성회선, 셀폰)에선 다릅니다. 2. 의사결정자에게 아무리 설명해봐야 안 먹힐것 같군요. 이럴땐 제일 좋은 방법이 '남들도 이렇게 한다', '이렇게 하는게 표준이다', '회선 속도 줄이면 전체적인 네트워크 성능이 급격히 나빠질 수 있고, 이런 경우 책임을 누가 질것인가?', 등등의 다른 식으로 접근해 보세요. 기술적으로 아무리 설명해도 안먹히는 경우가 많거든요.

  속도와 밴드위스의 개념 - skullq 님의 답변.

>현재상황을 말쓰드리겠습니다.

1. PC ↔ 더미허브 ↔ C2900 ↔ C5500 ↔ C3640  ===== T3 ===== C3640 ↔ C5500 ↔ 서버팜
 
  왼쪽의 C2900은 약 10대 정도이며, C2900 밑으로는 각각 7대 정도의 더미허브가 Cascade되어
  있습니다. PC 댓수는 약 600여대 정도 입니다.

제대로 된 속도를 즐기고 싶다면 더미허브를 전부 스위치롤 바꾸라고 권고하십시요

2. MRTG 운영
  C3640의 Hssi를 MRTG로 모니터링 해서 보면, MAX IN 19메가 // MAX Out 10메가 정도 입니다.

5/min average라는걸 알고 계시죠?

3. 의사결정자의 요구사항
  그래프를 보면 30메가 만으로 충분하지 않느냐, KT와 쇼부쳐서(^^;;) 30메가로 줄여라,
  회선비 줄이자라고 요구함(30메가로 서비스 받는 곳 몇군대 있음).

일단 의사결정자에게 64k, 128k, 256k, 768k, T1, E1, T3와 같은 속도규약에 대해서 이야기 하십시요.
그리고 metro라는것도 있다고 이야기를 하고요.. 그럴경우에 추가적으로 FastEthernet PA가 필요함을 이야기하고요..
물론 그렇게 하지 않더라도 KT와 쇼부쳐서 우린 30메가만 쓰겠다. 해달라고 떼쓰면 됩니다.

4. 저의 의견
  서비스 제공에는 지장이 없겠으나, 서버팜으로부터 각각의 애플리케이션들이 다운로드
  받는 속도가 다소 느려지오니 30메가로 대역폭을 줄이는 것은 고려할 만한 사항이 아님.

위에서 잘 이야기 해주면 됩니다. 이미 더미허브를 600대정도의 pc에 엮어놨다면 체감속도가 그리 좋진 않습니다. 누군가 공유폴더만들어놓고 파일전송만으로도 짜증나는 일이 발생하니까요

핵심 쟁점을 말씀드리겠습니다.

1. 의사결정자 :
  - MRTG 그래프를 보면 30메가로도 충분 할 것 같은데 왜 속도가 느려지느냐?
    그만큼 사용자의 사용률이 높지 않다는 것이 아니냐?

  - 그리고, 왜 45메가를 풀로 사용을 안하고 inbound가 20메가 수준에서 머물러 있느냐?

burst packet이라는것이 있습니다.. 우리는 모르지만... 늘 같은 속도로 계속 packet이 흐르지 않는답니다. 자세히보면 bandwidth도 한번씩 튀고 packet도 한번씩 튄답니다.. 위에서 말씀 드렸듯이 5min avg입니다.

2. 제 설명 :
  - 회선 대역폭(Bandwidth)는 도로에서의 차선과 제한 속도를 합친 개념 이다.

    때문에,  45메는 45차선//제한속도 90KM의 도로이고
    30메가는 30차선//제한속도 60KM의 도로 이다.

    그래서 30메가로 대역폭을 줄이면 서버팜과 PC간의 데이터 전송 속도가 다소 느려지는 것이다.

  - 모든 사용자의 PC가 단 1초도 쉬지 않고 계속해서 Data를 송, 수신하는 것은 아니지 않느냐
    5초, 5분의 평균 값이므로 그렇다.

위와같이 설명을 했는데 도저히 이해를 못합니다.
당연합니다. 저도 즉흥적으로 비유를 든 것이라서요..

질문 1. 제가 비유를 든 것이 적정한지요?
    & nbsp;  한번에 Data가 들어오는 차선이 넓기 때문에 속도가 빠른 것이지,
     & nbsp; 제한 속도라는 것이 있는 것은 아니지 않습니까?

질문 2. 정말 30메가로 줄일경우 전송 시간이 늘어 나는지요?


질문 3. 어째서 사용자가 가장 많이 사용하는 시간대에도
       MRTG 그래프의 MAX In이 45메가로 안나오는 것인지요?

   & nbsp;   상식적으로 사용이 많으면 어느정도 45메가에 근접한 량이 나와야
    & nbsp;  되는 것이 아닌지요?

   & nbsp;   MRTG를 이용해서 적정 회선 대역폭을 산출하는 것이 가능할까요?


질문 4. 가장 궁극적인 질문이 되겠습니다. 속도와 BandWidth에 대한 개념이
    & nbsp;  도무지 잡히지 않습니다. 설명 부탁 드립니다.

이부분은... 다른분의 글을 좀 인용을 하겠습니다.

http://blog.naver.com/snowcall.do?Redirect=Log&logNo=100004142265

속도(speed)와 대역폭(bandwidth)의 차이가 무엇인지 알고 싶습니까?
일반적으로 전용회선 T1일 경우 대역폭이 1.54Mbps라고 하던데, 그렇다면 WAN에서는 대역폭만 지정하고 속도 설정은 안해도 되는 것인가요? 반대로 LAN에서는 100Mbps 전이중이라고 할 때 100Mbps가 속도를 의미하는데, 대역폭은 별도로 지정하지 않아도 되는 것일까요??

<Answer>

엄밀히 따져서 LAN과 WAN은 서로 다른 기술로, 관심을 두는 기술적인 초점도 다르다고 볼 수 있습니다. 먼저 대역폭(bandwidth)을 정의하면 네트워크에서 이용할 수 있는 신호의 최고 주파수와 최저 주파수의 차이를 말합니다. 일반적으로는 통신에서 이용 가능한 최대 전송속도를 의미하는데, 이는 다시 말해 정보를 전송할 수 있는 능력을 뜻합니다. 기본 단위로는 bps를 사용합니다. 모뎀에서 전송속도가 28.8Kbps라는 것은 초당 2만 8800비트를 전송할 수 있다는 의미입니다.
이 와 달리 데이터 전송 속도는 주어진 시간(대개 1초) 내에 한 지점에서 다른 지점으로 옮겨진 디지털 데이터의 양을 말합니다만, 데이터 전송 속도는 주어진 양의 데이터가 한 지점에서 다른 지점으로 이동하는 속도로도 볼 수 있습니다. 일반적으로 주어진 경로의 대역폭이 크면, 데이터 전송속도도 더 빠릅니다. 통신에서의 데이터 전송은 보통 bps 단위로 측정됩니다. 컴퓨터에서는 데이터 전송속도를 초당 전송되는 바이트 수로 측정하는 경우도 종종 있습니다.
위의 정의를 통해 속도와 대역폭의 차이를 살펴보면, 기본적으로 대역폭이라는 용어는 매체가 지닌 주파수의 범위를 의미하는 것이며, WAN 구간에서는 이런 대역폭이 중요한 요인이기 때문에 초기부터 이 용어가 중요하게 사용된 것입니다. 이와 달리 LAN 구간은 이더넷을 쓰는 경우가 많기 때문에 굳이 매체의 대역폭이 얼마인가를 따질 필요가 없었습니다. 따라서 그냥 데이터 전송 속도라는 개념만이 존재하게 된 것입니다.
물론 일반적인 유선 데이터 네트워크에서는 서로 표현만 다른 비슷한 의미라고 생각해도 되지만, 만약 통신과 관련된 개발자의 입장이라면 전혀 다른 말이 될 수 있기에 확실하게 구분할 필요가 있습니다.

제 의견을 말씀드리자면...

제가 알고있는 bandwidth는 전송규약에 의해서 전기적으로 최대 bandwidth는 이미 정의가 됩니다. 이 위에 장비들에 의해서 처리되는 시간당 한계용량이 바로 speed가 될것입니다. ethernet을 예로 들자면... 조그만 라우터에 최대 1500byte의 mtu사이즈로 패킷을 보내는것과 가장 작은 64byte로 보내는것과의 speed는 다릅니다. 차이는 있겠지만.......
전 대충 이렇게 이해하면서 살고 있습니다....
ㅎㅎ

  속도와 밴드위스의 개념 - 오리님의 답변

안녕하세요?

저도 한마디 거들어 보겠습니다. ^^

첫째로 장비 성능 관점입니다. 어떤 유저분인지 이 부분을 얘기했다고 하시니...

장비 성능 관점이라는 것은 CPU Processing 관점에서의 얘기입니다.

100M 이더넷에 정말로 100Mbps traffic을 보낼수 있는가?

저희는 자주 이런 성능시험을 하지요. S/W가 바뀔때마다 code가 추가되기도 하고,

빠지기도 하기때문에 CPU Processing 부하가 달라질수 있기때문이지요.

가장 작은 packet size부터 시작해서 최대 packet size까지 성능을 측정합니다.

똑같이 50Mbps의 Traffic을 전송하려면 작은 packet size일때는 그만큼 동일한

S/W routine이 여러번 반복된다는 의미이기때문에 그만큼 CPU 부하가 올라가게 됩니다.

1500bbyte를 1500byte packet을 보내면, CPU가 한번만 휙 돌면 끝나지만, 150byte로

쪼개서 보낸다면 동일한 routine을 10번이나 돌아야하기때문입니다.

100M 이더넷에 64byte로 열라 전송하는 시험을 하면, 20Mbps 정도만 되도 CPU

부하가 100%를 넘어가서 뻗어 버립니다. ㅠ.ㅠ

둘째로 대역폭과 speed 관점인데요.

E1과 T1을 예로 들어서 어떤게 speed가 빠른가요?

당근 E1은 2Mbps이고 T1은 1.5Mbps이니 E1이 빠르잖아요.

왜 빠른거죠?  2Mbit/sec와 1.5Mbit/sec 이게 속도잖아요.

예를 들어서 64byte packet을 2Mbit/sec, 1.5Mbit/sec로 전송한다면 각각 얼마의 시간이 걸릴까요.

(예를 들기 위해서 그냥 E1/T1 모든 채널로 data를 전송한다고 가정합니다.)

(64byte * 8bit)/2048000 = 250us

(64byte * 8bit)/1536000 = 333us

대역폭이 클수록 전송속도는 빠른데요. 이 것은 data가 physical link로 전송되는데 걸리는 시간인 transmission delay로

차이가 납니다. 위에 계산한 값이 바로 transmission delay를 계산해 본 것입니다.

이런 transmission delay의 차이로 인해 발생될 수 있는 현상은 queuing 발생과 drop입니다.

무슨 말인고 하니 5분간 traffic average가 20Mbps라고 하면 어떤 순간의 100ms동안에는

보통 3~4배내지는 그보다 더 높은 burstness가 발생하는 시간이 있게 마련입니다.

그러한 bursness가 발생할때, physcal로 전송하기 전에 queuing을 해주어야 하는데,

전송속도가 느리면 그만큼 많은 queuing이 발생하게 됩니다. queue depth에 따라서는 drop이 발생할 수도 있구요.

delay나 drop은 재전송을 유발하여 network의 또다른 congestion을 유발할 수 있는 놈들입니다.

vendor마다 권고하는 적정수준의 usage가 있고,  CPU 부하나 link usage등에 대한 증설 시점을

70%로 권고하는 경우가 많습니다. 권고수준이 이상의 usage에서는 vendor도 정상동작을 보장할 수

없다는 의미이므로 가능한 권고하는 수준 이하에서 놀도록 하는게 좋겠지요.

음!! 횡설수설했는데, 뭔가 도움이 될만한 내용인지 모르겠네요. 헐~~~!

skullq	아주 유익한 글이었습니다. 특히 장비개발측면에서 테스트방법과 매번 고민하는 내용들은 나름대로 bmt시 참고가 많이 될거 같습니다. 09/15 12:20
봉창	저도 재밌게 봤습니다. 상당히 수준이 높은 글입니다. 어지간한 사람은 한 두번 읽고는 이해 못할 수준일 듯...... 저도 대여섯번 읽었습다. 계속 부탁 드립니다. 09/15 12:38
멜랑꼴리	유익한 글이었습니다.. 09/15 13:09
ohchungryum	답글 주신 분들 감사 드립니다..굉장히 수준이 높으시군요..저도 여러번 반복해서 읽고 있습니다.. 09/15 13:37
플라잉쭌	엄청난 수준의 글이군요... 유익한 글 감사합니다. 이해될때까지 눈알 빠지게 읽어야죠..으흐흐 09/15 14:09
키미지투	마저마저~~ 난 언제쯤 이런 수준의 답을 달 수 있을지.. ㅎㅎ 감솨감솨~~ 09/15 15:36
오리	에고!! 왜들 그러시나요!! 얼굴이 뜨끈뜨끈해 지넹!!! 09/15 16:34
돈스코	글 잘읽었습니다. (64byte * 8bit)/2048000 = 250us <== 이건 64byte/(2048000bit/8) = 250us 이것의 오타겠죠? 한가지 질문사항이 있는데 media type에 따라서 MTU라는게 있는데 그러면 실제 전송 패킷사이즈는 응용소프트웨어에서 정하게 되는건가요? 전송되는 패킷사이즈의 크기를 정하는 원리에 대한 추가설명을 듣고싶습니다.^^ 09/15 18:45
오리	(64byte * 8bit)/2048000 = 250us <== 이건 64byte/(2048000bit/8) =======> 같은 의미인데요. 하나는 byte를 bit로 변환해서 bit로 나눈거고... 뒤에꺼는 나누는쪽을 byte로 바꿔서 나누는거고... 결국은 같은 얘기에요. 패킷사이즈의 크기를 정하는 것은 없읍니다. application에서 보낼 데이터의 크기가 얼마냐에 따라서 그냥 보내는 것이니까요. application이 큰 패킷을 보내면 TCP->IP를 거치면서 Fragmentation을 하는 것이구요. application이 MTU보다 작은 패킷을 보낸다면 그냥 그대로 전송되는 것이겠지요. 09/15 19:48
돈스코	잠시 착각햇네요.ㅎ, 역시 응용프로그램에서 .. 그렇다면 이게 데이타의 전송속도에 미치는 영향이 크겠군요.. 패킷사이즈를 정하는 원리는 프로그래머분들이 설명을 해주시면 좋을듯.. 암튼 잘 알겠습니다.~ 09/15 20:02
멜랑꼴리	transmission delay에 대해서 SMB application을 가지고 일반 L2장비에서 Switching(1:1 unicast 통신)해 보시구요....각 packet size별(64,128,512,1024,1518byte)로 비교해 보시면 차이를 느끼실 수 있을 겁니다...참고로 그냥 L2장비에서 switching하는것과 media-convertor를 통해 통신하는 것도 같이 비교해 보세요~ 성능이 딸리는 media-convertor의 경우 packet이 100% switching되지 않고 빠질 수 있거든요... 09/16 01:00
제브라	tramsmission delay에 관련된 데이타처리 속도가 궁금했었는데 이제 조금 이해가려하네요,,,정말 잘 읽었습니당 ^ㅡ^ 09/16 10:25

                 10M Ethernet
    C3550 <----------------------> PC(tftp server)

위와 같이 스위치에 IOS image(1Mbyte size)를 down 받는다고 할때, packet size나 기타 다른 조건들의
변경으로 down load 속도는 어떻게 차이가 날 수 있는지 대략적인 예를 들어서 설명해 보겠습니다.
10M Ethernet이니 Physical 전송 speed는 1/10000000 = 0.1us입니다.

대략 속도에 영향을 주는 delay factor는 Processing Delay와 Queueing Delay, Transmission Delay,
Propagation Delay의 4가지를 생각해 볼수 있습니다.   

Processing Delay는 tftp server S/W가 IOS image file을 읽어서 physical로 전송하기 위해서
실제로 physical로 전송을 담당하는 device나 processor가 읽어갈수 있는 장소(이하 queue)에
packet을 가져다 놓을때까지 걸리는 시간과 같이 S/W가 data를 전송하기 전에 handling하는데 걸리는 시간입니다.

Queueing Delay는 Application에서 앞서 보내려 했던 packet이 완전히 physical로 전송되기 전에 다시 queue에
packet을 write하여, 실제적인 transmission이 시작되기까지 queue에서 대기하는 시간입니다.

Transmission Delay는 Queue에 있던 packet이 완전히 phyisical link로 전송되는데 걸리는 시간입니다.

Propagation Delay는 physical midium을 타고 data(bit)가 상대편 수신부까지 전달되는데 걸리는 시간입니다.

전기의 전달 속도는 빛의 2/3 정도 계산하여 2.1*10E8으로 계산된다고 하며, 근접한 거리의 경우 다른
delay factor들에 비해 무시할만큼 작은 값이 되므로 이번 계산에서는 무시합니다.
(WAN 구간으로 100Km를 넘는 경우라면 절대로 무시할만한 시간이 아니겠지요. 인공위성을 통한 경우에는
더더군다나 무시할 수 없습니다. 단방향 delay가 약 500ms정도나 됩니다.)

Processing delay는 CPU의 부하 상태에 따라서 달라질수 있고, 때로는 매우 커질수도 있습니다.
이번 계산에서는 편의상 10ms로 가정하고 계산해 보겠습니다.

계산상의 편의를 위해서 header등을 모두 무시하고, 실제로 physical로 전송되는 packet size를 100byte(800bit)와
1000byte(8000bit)로 가정하고 계산을 해보겠습니다. 각각 Transmission dealy는 80us와 800us가 되겠지요.

첫째, packet by packet 단위로 ack를 받고 전송하는 경우
100byte씩 보낼 경우 총 10000번 전송을 해야하고, 1000byte씩 보낼경우 1000번을 전송해야 합니다.
(Tx Processing Delay + Transmissiong Delay  + Rx Processing Delay) * 송수신 반복 횟수
100byte   : (10000us + 80us + 10000us) * 10000 = 200800000us(약 200초)
1000byte : (10000us + 800us + 10000us) * 1000 = 20800000us(약 20초)
위에 보신 결과와 같이 packet by packet 단위로 ack를 주고 받는 경우, processing delay나 propagation delay가
transmission delay에 비해 매우 큰 경우 packet을 크게 잘라서 보내야 down loading 속도가 빨라집니다.

둘째, 첫째와 같이 다른 delay factor들로 인해 ack를 매번 받으면 많은 시간이 걸리기 때문에 Sender Buffer와 Receive Buffer를 두고,
일정 갯수의 packet을 Ack없이 연속적으로 보내는 경우.(TCP의 Accumulate Ack)  Windown Size를 10으로 가정해 보겠습니다.
즉, 10개를 연속 보낸후에 Ack을 받고 다시 10개를 연속 보내고, 또 Ack를 받고 하는 식의 방법입니다.
100 byte  : (10000us * 10 + 80 * 10 + 10000us) * 1000 = 110800000us(약 110초)
1000byte : (10000us * 10 + 800*10 + 10000us) * 100   =  11800000us ( 약 11.8초)

좀 빨라졌지요. ^^

위와 같은 결과를 볼때 FTP로 화일을 다운 받거나 할때, 속도를 빨리 하려면 어떻게 하는게 좋을까요.
가능하면 packet size를 크게 하고, window size도 가능한만큼 크게하면 속도가 빨라 집니다.

FTP나 HTTP같은거 실행하시고, etherial로 한번 확인해 보세요. packet size는 MTU일꺼고, window size도
data link의 품질 신뢰성이 높을수록 크게 잡게 될것입니다.

도움이 되는 글이었나요??? ^^

출처. 네트워크 전문가 따라잡기 -  오리님의 글

1. Process Switching
라우터가 각각의 패킷을 전송할 때마다 라우팅 테이블을 확인하고
넥스트 홉을 결정하여 패킷을 전송하는 방식을
Process Switching 이라고 합니다
이 방식은 라우터의 CPU에 많은 부하가 걸리고 스위칭 속도도 느립니다
또 패킷별로 로드 밸런싱(Load Balancing)이 이루어집니다
즉 각각의 패킷별로 스위칭을 하기 때문에 목적지로 가는 경로가 2개 있을 경우에는
패킷별로 한번씩 한번씩 다른 경로로 전송합니다
- 라우터에 세팅하는 방법 -
Process Switching 방식으로 동작시키려면 해당 인터페이스에
Router(config-if)#no ip route-cache
명령을 입력하면 됩니다

2. Fast Switching
라우터가 특정 목적지로 전송되는 패킷에 대하여
처음 한번은 Process Switching을 하고
두 번째부터는 처음 Process Switching 때 만든 캐쉬 정보를 이용하여
패킷을 전송하는 방식을 Fast Switching 이라고 합니다
Default Switching 방식입니다
이 방식은 목적지별로 로드 밸런싱(Load Balancing)이 이루어집니다
- 라우터에 세팅하는 방법 -
Fast Switching 방식으로 동작시키려면 해당 인터페이스에
Router(config-if)#ip route-cache
명령을 입력하면 됩니다

3. CEF(Cisco Express Forwarding) Switching
Fast Switching 방식을 다음과 같이 개선한 방식입니다
Fast Switching 방식은 처음 한번은 Process Switching을 해야 캐쉬가 생성되지만
CEF Switching 방식은 처음부터 라우팅 테이블을 캐쉬로 복사해 놓습니다
캐쉬를 검색하는 속도도 더 빠릅니다
Fast Switching 방식은 목적지 주소와 그 목적지로 가는 경로를 기록하지만
CEF Switching 방식은 목적지 주소와 함께 출발지 주소, 목적지로 가는 경로가 기록됩니다
이 방식은 출발지 -> 목적지별로 로드 밸런싱(Load Balancing)이 이루어집니다
단, interface mode로 들어가서 ip load-sharing per-packet 명령을 넣어주면 패킷별로 로드 밸런싱 가능

- 라우터에 세팅하는 방법 -
CEF Switching 방식으로 동작시키려면 전체 설정모드에서

Router(config)#ip cef
명령을 입력하면 됩니다
라우터에서 특정 인터페이스의 스위칭 방식을 확인하려면

Router#show ip interface
명령어를 사용하면 됩니다

rfc2004

Minimal Encapsulation for IP

  The format of the minimal forwarding header is as follows:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Protocol    |S|  reserved   |        Header Checksum        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                 Original Destination Address                  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  :            (if present) Original Source Address               :
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

rfc2784

The GRE packet header has the form:

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|       Reserved0       | Ver |         Protocol Type         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Checksum (optional)      |       Reserved1 (Optional)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

저놈들이 ip within ip와 gre의 packet header form입니다.

ip within ip는 말그대로 ip만을 위한 것입니다. ip header위에 그대로 또다른 ip address를 하나 더 가지고 있는것입니다.

하지만 gre는... 좀 다르죠... protocol type이라는 field가 있습니다.

여러 프로토콜을 보내고자 하는 목적지로 마음대로 보낼수가 있다는게 gre의 특징입니다.

ipip는 mobile네트웍 환경에서 많이 쓰인다고 합니다. 추축컨데.. unicast를 이용한 anycast를 흉내내기 위한 방법으로 사용이 될거 같네요..

그리고 gre는.... 광범위하죠... 말 그대로 routing encapsulation도 가능하고...

출처.

네트워크 전문가 따라잡기. - skullq 님의 답변

>답변 감사합니다.
>많은 도움이 되었습니다.
>그리고 아래 내용은 제가 궁금한 점이 있어서 한번더 질문이 있어서 이렇게 글을 보냅니다.
>
>답변 한번더 부탁드리겠습니다.
>
>
>
>
>>현재 사용하는 트래픽과 그쪽회사의 특성을 알수있다면 좀 다른것을 제안해 드릴수 있습니다.
>>방법은 많으니까요... ^^
>>
>>일단 이중화 하기 위해서 bgp를 사용할 경우에 대해서 말씀을 드리면..
>>AS가 있어야 하겠죠? 그리고 독립적인 IP를 krnic에서 할당을 받아야 합니다.
>>가능한가요?
>
>
>-->이 말씀은 이중화를 위해서는 BGP를 반드시 사용 해야 한다는 것으로 인식을 하면 되는 겁니까?
>BGP AS 넘버는 Krnic에 신청할 예정입니다.
ip분담금과 1년에 300만원정도의 AS사용료를 감안할 만큼 그리고 해외망까지 계약할경우 들어가는 비용을 지불할수 있을만큼 망이 크거나 중요하다면.. 그리 해야 할것입니다.

>
>>
>>만약 되었다면 bgp를 peering을 맺는뎅.... 이중화가 목적이고 하나가 active 그리고 하나가 standby라면..
>>bgp는 맺되 라우팅은 받지 않아도 전혀 상관없습니다...
>>그리고.. 해외망을 사용해야 하기 때문에 그건 나중에 생각하시면 됩니다.
>
>--> 인터넷 서비스에 관련있는 부분이라서 단순 회선 이중화는 아니고, 대역폭까지 고려한 내용으로 알고 있습니다.
그렇다면... 회선 이중화에 회선의 트래픽이 50%를 넘지 않도록 유지하는 정책을 세우면 될거 같습니다.


>>
>>국내라우팅은 16메가로도 충분할겁니다. 4000개정도...
>>해외망 라우팅을 받아야 할 이유가 전혀 없을겁니다... -.-
>
>--> 혹시 해외망의 라우팅 Table을 받지 않는 것이 라우터 설정상 있는 것인지 궁금합니다.
>아님 기존 ISP에서 라우팅 정보를 보내지 않아서 굳이 라우터에 설정이 필요 없는지 궁금합니다.
bgp는... 무조건 내 자신을 advertisement 해야 합니다. 이유는.. 그걸 보고 다른AS에 있는 네트웍이 들어오도록 하기 위한거죠.
만약 multi-homed 상황이 된다면 또 각 ISP의 회선을 하나의 라우터에만 물리시겠다면... 이야기는 정말 다르게 흐릅니다.
그건... 그때그때 다르오니 정확한 정보를 주시면 더 자세히 설명해드릴수 있습니다.


>>
>>route-map test-IN (in | out)
>>bgp를 제어하는 시스코라우터 설정입니다.
>>제어방법은 여러가지가 있는데.. 그것들을 적용하게끔 하는게 바로 route-map 입니다.
>>
>>soft-reconfiguration inbound는 bgp위 soft restart라고 생각하면 됩니다.
>>bgp routing을 clear하게되면 모든 라우팅 정보가 사라지고 그와동시에 통신이 단절되어 버립니다.
>>그래서 현재의 설정을 그대로 메모리에 쥐고있으면서 clear하면 새로운 정보를 받아서 메모리에 넣어놓고 현재의 설정과 빨리 바꿈으로써 서비스가 멈추지 않게끔 하는 기술입니다.
>
>--> 혹시 아래 내용중 2600/3600/3745등의 장비에서 BGP사용시 Traffic이 어느정도 까지 설정이 가능한지 궁금합니다.
>그리고 혹시 3750, 4900등의 장비에서 BGP를 사용할 경우 외부에서 Traffic을 어느정도까지 감당할 수 있는지 궁금합니다.
어느정도의 트래픽이라는건 data sheet에 보시면 나올겁니다.. 하지만 2600/3600는 권장하고 싶지 않고요 좀 힘들어 할수도 있겠네요...
3745는 장비를 잘 모릅니다.
그리고 L3 스위치들은 글쎄요.... 보통~ 그렇게 하진 않지만.. 가능할거 같네요... 오히려 더 좋은 퍼포먼스를 얻을수도....



>
>>
>>>안녕하세요.
>>>항상 좋은 자료 보고 갑니다.
>>>
>>>이번에 사이트에 요청이 있어서, ISP이중화에 대한 문제가 대두 되었습니다.
>>>
>>>그래서 여러 자료를 찾다 보니.. BGP에 대한 자료가 많이 나오더군요...
>>>
>>>1. BGP를 이용하지 않고 ISP이중화 방안이 있는지 궁금합니다.
>>>ISP를 이중화 하기 위해서 BGP를 사용 하는 것이 일반적이기는 하지만, 매달 나가는 금액도 따로 있고, routing 정보의 수가 만만찮아서 장비의 spec이 높아야 하는 것으로 알고 있습니다.
>>>그래서 혹시 ISP를 이중화 하는데 BGP이외의 방법이 있는지 궁금합니다.
>>>
>>>2. BGP를 하다보면 보통 routing table 이 4000개 이상, 전세계적으로 10만개가 넘는다고 들었습니다.
>>>혹시 이 모든 routing table을 제어 하는 방법이 있는지, 궁금합니다.
>>>
>>>route-map test-IN in
>>>route-map test-OUT out
>>>이라는 것이 하는 역할이 뭔지 궁금합니다.
>>>
>>>3. soft-reconfiguration inbound라는 부분이 나오는데, 찾아보니, routing정보를 받아 오기 위한 것으로 되어 있던데, 정확하게 사용하는 이유가 뭔지, 12.2이상에서는 사용하지 않아도 된다고 하던데 정확한 내용인지 궁금합니다.
>>>
>>>4. 2620/3640/3745 등의 라우터 장비를 이용해서 BGP를 구현 하는데 문제 점이 있는지, 만일 사용할려면 Memory를 upgrade하면 되는 것인지 확인 부탁드립니다. 자료를 찾아보니, 3640/3745 경우 64M 정도가 최소 사양이고, 128M를 recommend한다고 되어 있던데, 실질적으로 2620/3640/3745 장비를 사용할 경우 괜찮은 건지 궁금합니다.
>>>
>>>이상입니다.
>>>
>>>답변부탁드립니다.

출처.
네트워크 전문가 따라잡기
// skullq 님의 답변

SNMP(Simple Network Management Protocol)

SNMP?

1970년대 후반 네트워크 장치인 연결 정보를 얻기 위한 일종의 관리 프로토콜인 ICMP(Internet Control Management Protocol)이 처음 사용되었다. 1989년 기존의 프로토콜 기능을 향상시킨 SNMP로 통합되었다.

SNMP 관리 구조

SNMP는 매니저와 에이전트의 구조로 이루어져 있다. SNMP 에이전트는 각 네트워크 장치에 장치된다. 그리고 정해 놓은 규격에 따라 장치의 정보를 수집하고 보관한다. SNMP 매니저는 에이전트와 독립적인 장소에 존재하며, 네트워크에 분포된 SNMP 에이전트의 정보를 수집해서 전체 네트워크를 관리한다.

SNMP 매니저를 정보를 수집하기 위해서 Request 메시지를 에이전트에 전송하고 에이전트는 Response 메시지를 사용해서 자신의 정보를 매니저에게 보낸다. 에이전트가 수집할 정보의 내용을 정해놓은 규격을 MIB(Management Information Base)이라고 한다.

SNMP 데이터 수집 방법

에이전트의 내용을 매니저에게 전달하는 방법은 폴링과 이벤트 리포팅의 두 가지 방법이 있다.

            Polling                              manager | --- request à | Agent

                                                                 | ß response -- |

            Event reporting                manager | ß-- trap ---- | Agent

Polling

요청에 응답

매니저가 에이전트에게 원하는 정보를 요구하면 에이전트는 매니저가 원하는 정보를 찾아서 응답한다. 간단하지만 트래픽을 많이 사용하는 단점이 있다.

Event reporting

특별한 이벤트가 발생했을 경우에 전송되며 트랩이라고 한다.

SNMP 변천사

1989년 처음 발표된 SNMP는 현재 ver.3까지 발표 되었다.

1.       SNMP

2.       SMP(Simple Management Protocol) : 성능향상

Secure SNMP : 보안기능 향상

3.       SNMPv2(party) : 위 두 가지를 통합

4.       SNMPv2c(Community) : 보안 기능 제거, SNMP 인증 방식으로 복귀

SNMPv2USM : User Security Model 추가

5.       SNMPv3

SNMPv3

모듈화로서 기존의 매니저/에이전트 패러다임을 SNMP 개체(entity)로 바꾼 것이다. 이것에 의하면 SNMP 개체는 구성된 모듈에 따라서 매니저가 될 수고 있고 에이전트가 될 수도 있다.

RMON(Remote Monitoring)의 경우 v1은 SNMP를, v2는 SNMPv2를 기반으로 정의되었고, 현재 가장 많이 사용하고 있는 버전은 SNMPv2c(community)이다.

SNMP 프로토콜 스택

SNMP는 TCP/IP 프로토콜 스택에서 응용계층의 프로토콜이다. SNMP 메시지를 전송하는 전송계층 프로토콜은 UDP를 사용한다. SNMP는 UDP의 161, 162 두 개의 포트를 통해서 메시지를 주고 받는다.

SNMP 메시지의 종류

SNMP에서 에이전트와 매니저가 주고 받는 메시지는 총 다섯 개이다.

정상적인 요청/응답은 161번 포트, 트랩 메시지는 162번 포트를 사용한다.

SNMP의 정보 관리 방법

SNMP는 이 기종의 시스템에서도 TCP/IP를 통해서 정보를 교환해야 하기 때문에, SNMP만의 독자적인 정보 관리 방법을 가지고 있다.

SMI(Structured Management Information)

SNMP MIB 들을 정의하기 위한 일반적인 구조이다.

MIB 객체들은 ASN.1 문법에 따라 정의되는데 각각의 객체들은 각각 이름과 표기 문법 다른 시스템으로 전송을 위한 인코딩 규칙 등을 가지고 있다. 이들은 서로 고유한 객체 식별자에 의해 구분된다.

MIB(Management Information Base)

MIB는 SNMP 관리 스키마로서 SNMP에서 관리하는 객체, MO(Managed Object)를 정의해 놓은 집단이다. MIB는 관리 객체를 정의하기 위해서 ITU-T에서 정의한다. ASN.1(Abstract Notation One)을 사용한다.

ASN.1은 객체를 설명하는 일종의 스크립트 언어이다. ASN.1으로 정의된 객체는 모두 트리 구조로 이루어져 있다.

O-ID(Object-Identifier)

OID는 MIB의 관리 객체(MO)를 지정하는 식별자(Primary Key)이다. OID는 계층구조에 따라 자신을 나타내는 번호와 이름을 가지고 있으며 부모이름도 알고 있다.

SNMP 데이터의 인코딩 방법

모든 SNMP 데이터는 인코딩 되어서 전송된다. 이것은 이 기종 시스템 사이의 데이터 독립성을 유지하기 위해서다. SNMP는 Basic Encoding Rules(BER)이라는 인코딩 방법을 사용하며 이것은 ITU-T의 X.209에 정의되어 있다.

모든 데이터는 TAG, LENGTH, VALUE 의 형식으로 인코딩 된다.

SNMP의 보안 방법

네트워크 상에서 정보를 안전하게 관리하기 위해서는 컴과 네트워크의 보안이 보장되어야 한다.

SNMP는 community라는 일종의 패스워드를 사용하며, SNMP 메시지를 인증한다. 네트워크를 통해 전송되는 모든 메시지에 커뮤니티 값을 집어 넣어서 메시지 단위로 인증을 수행한다.

공개 커뮤니티 : public

관례적으로 에이전트가 공개하는 MO에 대해서는 커뮤니티 값을 ‘public’으로 설정해 놓는다. SNMP 매니저와 브라우저를 이용할 때 커뮤니티 값은 선정해 두지 않았는데, 에이전트에서 값을 가지고 왔다면, 그것은 커뮤니티 값이 ‘public’으로 설정되었기 때문이다.

접근정책 (Access policy)

SNMP는 접근하는 형태별로 다른 커뮤니티 값을 사용한다. 이러한 접근제어 방법은 SNMP MIB에 의한 접근과 SNMP 접근 모드의 관점으로 나뉜다.

SNMP Trap

트랩은 에이전트에 특별한 이벤트나 사고가 발생하였을 때, 매니저의 요구가 없더라도 스스로 판단해서 매니저로 전송하는 일종의 리포트 매니저이다. 162번 포트 사용

SNMP의 단점

폴링 방식을 사용하기 때문에 관리하는 객체가 늘어날수록 많은 대역폭과 매니저의 프로세서를 필요로 한다.

SNMPv2

SNMPv1의 단점이 네트워크 과부하 문제를 해결하고 관리자의 통신 방법을 확장했다. SNMPv2 메시지는 버전, 커뮤니티, PDU(Protocol Data Unit)로 구성된다.

GetBulk-Request

SNMPv1의 단점이 트래픽 부하를 해결하기 위해서 추가된 Request.

가져올 객체의 범위를 지정해서 한 메시지 안에 포함시키기에 트래픽 부하를 줄인다.