engineering/Network Eng.2006. 8. 29. 00:03

NVRAM에 저장되어 있는 Configuration register 값은 각각의 의미를 지닌 16bit로 구성되어 있고 16진수로 표현 된다. 예를 들어 router의 default configuration register값인 0x2102 를 이진수로 변환하면 다음과 같은 값들이 표현된다.

예를 들어 위 그림의 표에서 6번 bit가 ‘1’로 설정되면 부팅 시 NVRAM을 참조 하지 말라는 의미로 사용된다. 즉 부팅 시에 Configuration 정보를 참조하지 말고 초기 상태로 부팅하라는 의미이다. 이 값은 password recovery를 수
행하는 경우에 변경되는 값이기도 한다. 이 중에 부팅 시에 가장 중요하게 참조되는 부분은 바로 boot field이다.
boot field에서 표현하는 정보는 IOS Image의 참조 위치를 알려주는 정보이 며 다음과 같은 정보를 제공하고 있다.

Boot Field Meaning
------------------------------------------------------------------------------------
0x0 (0000) Stays at the system bootstrap prompt
0x1 (0001) Boots system image on EPROM
0x2-F (0010 ~ ) Specifies a default netboot filename Enables boot
system commands that override default netboot filename

Boot field의 Default값은 0x2(0010)이다. 이는 IOS Device가 부팅 시에 기본적으로 flash memory에서 IOS Image를 참조한다는 의미이다.

출처 - 네트워크 전문가 따라잡기( http://cafe.naver.com/neteg.cafe )

Posted by theYoungman
engineering/Network Eng.2006. 8. 11. 15:56

◎ 모뎀상태를 확인할 수 있는 indicator
: * : power-level이 3dB 이상 변화 발생
: ! : cable modem이 상향신호를 최대로 출력 중


◎ show interfaces cable 2/0(3/0) upstream 0(0~5)
ⓐ interface or upstream port별 TX, RX 속도 확인

ⓑ 확인 결과 70 ~ 80 ~ 90%가 지속되면 Cell 분할 및 가입자수를 각 상향 Port별 균등하게 분할 필요

◎ show controllers cable 2/0(3/0) upstream 0(0~5)

ⓐ 상향 Port의 신호레벨 (SNR) 확인

ⓑ 25dB이상이어야 정상이며, 30dB 이상 나오면 최적이고, 20dB 까지 모뎀 online 가능

ⓒ 상향변조방식 QPSK (25dB이상), 16QAM(30dB이상)

ⓓ SNR이 적을 경우
: 상향 신호세기 자체가 낮을 경우 : 증폭기의 상향 증폭레벨 조정
: 잡음이 많을 경우 : 케이블망 상향선로 정비로 유입잡음 차단 및 Tap Off단에 filter 장착 (20MHz 이하 차단)

◎모뎀 online 후 PC가 IP Address를 받지 못하면 CM에 연결된 PC수를 확인 후 모뎀이 잡고 있는 PC NIC MAC Address를 clear 시켜줌

ⓐ sh cable modem x.x.x.x detail 명령어로 max-cpe 개수 확인
: x.x.x.x ( IP / MAC Address )

ⓑ sh int c2/0(3/0) modem sid # 명령어로 모뎀에 연결되어 있는 MAC Address 확인
: sh cable modem x.x.x.x 결과 에서 Prim Sid 번호가  # 임

ⓒ 정상적인 IP/MAC이 있더라도 Internet을 사용하지 못하면 clear cable host x.x.x.x 로 해당 MAC 제거
: clear cable host x.x.x.x

예제 청원유선만해당

월곡 탑연 show cable modem | inc Cable2/0/U0

오송1,2,3,4 동평 보영@ show cable modem | inc Cable2/0/U1

월탄 교원대근처 show cable modem | inc Cable2/0/U2

중봉(봉산,정중,서평) show cable modem | inc Cable2/0/U3

궁평1.2구 show cable modem | inc Cable2/0/U4

대평유선 show cable modem | inc Cable2/0/U5

online 된 모뎀만 볼 수 있음 show cable modem | inc online

각 포트별 전체 모뎀 show cable modem summary total


show cable modem detail 각모뎀별 내용을 볼 수 있음


sh int c2/0 up | inc util CMTS 상향 Port의 Utilization 값 확인

sh int c2/0 modem 000 (sid) lancard mac 확인

utilization이 70~90%이상 계속해서 사용될 경우 해당 Port에 연결된 CM뒤의 가입자들은 상향쪽으로
Bottleneck이 발생하여 결과적으로 속도가 저하됨

sh cable flap-list c2/0 up 0

cable flap-list 확인하여 해당모뎀의 최근 flap이 언제 발생했는지 확인 및
상향쪽 miss가 hit에 비해 많거나, CRC가 발생한다면 상향 Route 확인 지시


show interfaces cable 2/0 upstream 0 port별 TX, RX 속도 확인


# show cable modem : 모뎀의 전체적인 상황 볼 수 있다.
# show cable modem | inc online : online 된 모뎀만 볼 수 있음
# show cable modem | inc offline : offline 된 모뎀만 볼 수 있음
# show cable modem | inc init : init 상태의 모뎀 볼 수 있음
# show cable modem summary total : 각 포트별 전체 모뎀의 상태 볼 수 있음
# show cable modem | inc MAC Address 또는 10.x.x.x : 특정 모뎀만 선택해서 볼 수 있음
# show cable modem | inc Cable2/0/U0 : 2번 Card의 0 번 포트의 모뎀만 볼 수 있음
(마지막 숫자에 따라서 포트 구별 됨)
# show interface 2/0 modem sid 값 : show cable modem 에서 나타난 sid 값으로 모뎀의 상태와 모뎀에 연결된 PC의 IP 를 볼 수 있음
# clear cable modem IP 나 MAC Address reset : 특정 모뎀을 reset 시킬 수 있음
clear cable modem MAC reset
# clear cable host IP 나 MAC Address : 모뎀에 연결된 PC 가 가지고간 IP 삭제
# clear cable modem all reset : 모든 모뎀을 reset 시킬 수 있음(주의해서 사용)
# show controllers Cable2/0 | inc SNR : 각 상향 포트별의 SNR 값 볼 수 있음
# show cable hop : 각 포트별 상향 주파수 확인
상향 포트 주파수 변환 방법
(상향 설정된 주파수 대역에 잡음이 많거나 SNR 값이 나쁠 때 사용)
i) # show cable hop로 상향 주파ii) 수 확인
iii) # test cable hop cable2/0 upstream 0(포트번호)
iv) # show cable hop로 상향 변경 주파v) 수 확인
vi) ii) 항목 한번 사용시 한 단계씩 변함(세번 입력하면 원래 값으로 돌아옴)




명령어 추가

show env all :cmts 건강상태보기

clear cab modem 00a0.736a.4475 reset 특정모뎀리셋
sh cab hop 포트별주파수 확인
test cab hop c2/0 up5 5번상향포트의 주파수변경
sh cab modem 0000.0000.0000 특정모뎀의 rx레벨확인 및 상태 보기
sh cab modem detail 모뎀별 신호 잡음비
sh cab modem detail | inc 444 특정모뎀의 신호잡음비
clear cab host [ip or mac] 랜카드가 받아간 아이피 리셋
sh int c2/0 modem 0 전체호스트의 ip 확인
sh int c2/0 modem 0 | inc 317 특정호스트의 ip확인
sh cab f hit/miss p-adj(3dB조정명령)
sh cab f sort-f cab f를 p-adj 많은순으로 정렬
sh cab f sort-t cab f를 시간으로 정렬
sh cab f c3/0 up1 sort-f 특정포트의 cab f p-adj순 정렬
sh cab f c3/0 up1 | inc 0000.0000.0000 특정모뎀의 cab f 보기
clear cable flap-list all flap-list 초기화
clear cable flap-list 0000.0000.0000 특정모뎀의 cab f 최기화
sh cab modem su cmts의 전체 모뎀수
sh int c2/0 sid counter 가입자별 상향트래픽
sh int c2/0 u1 포트별트래픽
sh contr c2/0 u1 포트별신호잡음비
sh cab modem c2/0 up 1 : inc ! 특정포트의 !만 색출(!는 모뎀이 상향을MAX보냄)
configure terminal config 모드로 전환


◎ 속도가 느려요
가) CMTS 상향 Port의 SNR 확인 및 cable flap-list 확인

ⓐ 모뎀이 붙어있는 상향 Port의 SNR비 확인, 아주(20 ~ 25dB 이하) 낮아졌다면 상향 조정지시
: 잡음 때문에 SNR 값이 떨어진 것인지, 상향 신호세기가 일정하지 못한지 방송사에서 확인
: cmts#sh contr c3/0 up | inc SNR (엔터)
SNR 28.6280 dB
SNR 19.840 dB
SNR 26.200 dB
SNR 25.5760 dB
SNR 28.9440 dB
SNR 27.6040 dB (위 부터 C3/0의 0~5번 Port를 말함)

ⓑ cable flap-list 확인하여 해당모뎀의 최근 flap이 언제 발생했는지 확인 및
상향쪽 miss가 hit에 비해 많거나, CRC가 발생한다면 상향 Route 확인 지시
: cmts#sh cable flap-list c3/0 up 0 (엔터)
MAC Address Upstream Ins Hit Miss CRC P-Adj Flap Time
0000.f031.8689 Cable3/0/U0 19 43799 25131 20 721 1358 Feb 20 16:06:01
0090.9601.65be Cable3/0/U0 65 9575 2051 1 !936 1126 Feb 20 14:15:08
00a0.736a.9144 Cable3/0/U0 3 64431 638 2 813 841 Feb 19 17:01:49
0090.9601.3da8 Cable3/0/U0 140 20745 3528 2 3 381 Feb 20 17:29:32
0000.f028.7e93 Cable3/0/U0 65 19184 10474 1 51 349 Feb 20 20:12:44
0090.9601.7285 Cable3/0/U0 77 9756 2668 0 0 260 Feb 20 18:06:07


ⓒ APT가입자중 PC IP Address를 확인하여 CMTS에 할당한 IP 및 해당 Router가 일치하지
않으면 해당 Switching Hub에 연결된 가입자중에 하나가 IP 공유 Program을 사용하고 있어
가입자에게 다른 IP를 할당하게 되어 통신이 불가하거나, 통신이 되어도 속도가 느려지게 됨

나) CMTS 상향 Port의 Utilization 값 확인 및 상향 과다 사용 시 상향 대역폭 확장

ⓐ sh int c2/0(3/0) up | inc util (엔터)
: cmts#sh int c3/0 up | inc util
Avg upstream channel utilization : 9%
Avg upstream channel utilization : 25%
Avg upstream channel utilization : 74%
Avg upstream channel utilization : 21%
Avg upstream channel utilization : 92%
Avg upstream channel utilization : 15% (위 부터 C3/0의 0~5번 Port를 말함)
: utilization이 70~90%이상 계속해서 사용될 경우 해당 Port에 연결된 CM뒤의 가입자들은 상향쪽으로
Bottleneck이 발생하여 결과적으로 속도가 저하됨

ⓑ 상향 Port별 SNR 값 30dB 이상, 잡음/SNR값 변동 없고 42MHz까지 지원 가능한 Port에 한해 대역폭 확장

다) 상향 과다 사용자 색출 및 상향속도 제한

ⓐ sh int c2/0(3/0) sic counters (엔터)
: 시간차를 두고 명령어를 2회 실시한 후 그 결과를 근거로 상향사용자 추적
:  inoctets 를 기준으로 sorting 하여 증가가 가장 많이된 sid번호가 상향 과다 사용자

ⓑ 상향과다 사용자를 대상으로 CNR에서 상향을 제한하는 Client-Class, Policy를 생성 : 데이콤 신청
: 모뎀 등록 변경
: 모뎀 원격 Reset : 반드시 reset를 걸어줘야 함

ⓒ 위 방법은 단시간 내에 확인하는 방법이기 때문에 상향과다 사용자를 정확히 색출하기 어려움
따라서 주기적으로 적어도 2~3일 정도 차이를 두고  inoctets 값을 비교해서 추적하는 것이 타당함

ⓓ 위 방법은 단기적인 방법이므로 적절한 Cell 분할로 상향 Port별 가입자를 균등하게 분배하는 것과
상향 망 개선 후 변조방식 및 상향 대역폭을 변경하는 방법이 있음



* ping 안될시 ping docsis [ip주소] 로 확인가능. - ping doc [ip번호]


▣ DOCSIS 1.0 / 1.1 명령어----------------------------------------
◎ (1.0) Max CPE / SNR 확인 (scm d | inc [mac-add뒷자리])
show cable modem detail | include [mac-add]

◎ (1.1) Max CPE / SNR(&상/하향파워) / QOS 확인
show cable modem [mac-add] verbose
show cable modem [mac-add] verbose | include SNR
show cable modem [mac-add] verbose | include CPE
show cable modem [mac-add] verbose | include QoS

◎ (1.1) 상/하향 파워 및 SNR 확인
show cable modem [mac-add] phy

◎ (1.0/1.1) 각 포트 SNR 확인
show controllers c3/0 | inc SNR
show controllers [CMTS interface] | include SNR

◎ (1.0/1.1) upstream port 의 주파수 및 FEC 확인 (sch)
show cable hop

◎ (1.0) downstram port 의 주파수 확인
show controller cable3/0 | inc Fre / MHz

◎ (1.1/1.0) 상향 사용율(%) 확인
show interface c4/0 mac-s| include util (docsis 1.1)
show interface c4/0 up| include util (docsis 1.0)

◎ (1.0/1.1) 지정한 CM에 붙은 Host IP를 보고자 할때
show interface cable3/0 modem [sid-no]
show cable modem [mac-add] cpe

◎ (1.0/1.1) Ins / Hit / Miss / CRC 확인
show cable modem [mac-add] flap (docsis 1.1)
show cable flap | inc [mac-add] (docsis 1.0)
Ins - intermittent downstream sync loss or DHCP or modem registration porblems
(간헐적인 하향 싱크 손실 또는 DHCP나 모뎀 인증 문제)
Hit - The Number of times the CM responds to MAC layer keepalive message
(CMTS와 CM간의 keepalive message가 정상 도달하는 경우의 총수)
Miss - The Number of times the CM misses to MAC layer keepalive message
(CMTS와 CM간의 keepalive message가 손실되는 경우로
Hit와 Miss의 비율이 8% 미만이 정상이며 그 이상인 경우 상향측 문제로 추정가능)
CRC - The Number of cyclic redundancy check (CRC) errors from this CM
P-Adj - TX 파워가 3dB 이상 조정되는 경우 1 증가
Time - The most recent time that the CM dropped the connection

◎ (1.1) 각 포트별 소속 단국 확인-포트변경시 활용 (단, 파워콤만 가능)
show interface c4/0 up | include Des

◎ (1.0) 서로 다른 하향 사용시 포트변경 (단, 파워콤만 가능)
cable modem [mac-add] change-frequency [해당 하향주파수] [포트번호]
=> 현재 파워콤CMTS에서도 사용불가 (Dacom권한 없음-CICK포함)

◎ (1.0/1.1) 같은 하향 사용시 포트변경 #1 (Dacom권한 없음-CICK포함)
cable modem [mac-add] c [바꿀 포트번호]

◎ (1.0/1.1) 같은 하향 사용시 포트변경 #2
test cable ucc c3/0 [sid-no] [바꿀 포트순서]

◎ (1.0) 상향 포트별 사용중인 주파수를 동일 스펙트럼 그룹내 다른 주파수로 강제 변환
test cable hop c2/0 upstream [해당 포트번호]

◎ (1.0/1.1) offline 상태인 모뎀의 offline 된 시간 확인 (scm off | inc [mac-add])
show cable modem offline | include [mac-add끝자리]

◎ (1.0/1.1) 해당 셀에 붙은 Total/Active/Registered Modems 갯수 (scm su | inc 3/0)
show cable modem summary | include Cable3/0

◎ (1.1) 상/하향 사용량 감시 (scm c3/0 counters)
show cable modem c3/0 counters | inc [mac-add끝자리]
(MAC Address / US-Packets / US-Bytes / DS-Packets / DS-Bytes)

◎ (1.0) 상/하향 사용량 감시 (sh int c3/0 sid counters)
show interface c3/0 sid [sid-no] counters
* [sid-no] 생략시 전체 리스트 출력

◎ (1.0/1.1) 모뎀 리셋 (ccm [cm-ip] reset)
clear cable modem [mac-add or cm ip) reset

◎ (1.0/1.1) cm에 연결된 pc ip clear
clear cable host [pc ip]
cch [pc ip]/[pc mac-add]

▣ 데이콤 보라홈넷 기준치--------------------------------------
◎ CMTS측 상향 Power(CMTS에서 수신하는 파워) : 0±10 dBmV

◎ CM측 상향 Power(CM에서 송신하는 파워) : 43±10 dBmV
(55이상-과열 가능성 높음 / 적정값이하-품질저하)

◎ CM측 하향 Power(CM에서 수신하는 파워) : 0±10 dBmV (규격은 0±15)

◎ SNR : 상/하향 모두 30dB 이상 (Cisco 기준 : 29dB)
20dB미만인 경우 잦은 초기화현상을 발견할 수 있음

◎ Utilization : 70% 이하 (Cisco 기준 : 75% 이하)
상향사용율 90% 이상인 경우 병목현상으로 인한 속도저하 유발 (1M미만 ~ 30k)

▣ Cable Modem initial State------------------------------------
◎ init(r1) : CM이 initial ranging 을 보내고 있음
◎ init(r2) : CM은 ranging 상태
◎ init(rc) : CM ranging 완료
◎ init(d) : DHCP request를 받게 된다
◎ init(i) : DHCP reply received : IP address 할당
◎ init(t) : TOD exchange가 된다
◎ init(o) : option file transfer 가 시작된다
◎ online(d) : 모뎀은 정상 등록되었으나 CNR 에서 enable Network Access 체크누락
◎ online(pk) : 정상 사용 가능한 상태로 보안접속 상태임 (DHCP 별도 관리 가입자임)

Posted by theYoungman
engineering/Network Eng.2006. 8. 11. 15:55

syslog 를 이용한 원격로그지원
slog-8617.tgz


1. syslog 설명
2. syslog.conf 파일 설명
3. 원격 저장을 위한 설정
3.1  로그를 받는 쪽
3.2  로그를 보내려는 쪽
3.3  일반사용자 계정으로 로그서버 설정 과 구축


1. syslog 설명

전통적인 유닉스 시스템에서는, 시스템에서 발생하는 내용들에대해서 로깅(Logging)을

제공합니다.


물론 보안과 관리의 목적이며 이 로그 파일들은 운영체제마다 조금씩 틀리지만,
리눅스의 경우 /var/log 에 쌓이게 됩니다.


시스템 관리자는 일정 규칙에의해 설정을 하게 되며, 자신이 개발하는 프로그램에도 syslog
기능을 사용하는게 가능합니다.  syslog 기능은 syslogd 를  기동시킴으로서, 작동하게 되는데

물론 항상 떠 있어야 하겠고, 사용하는 관련 파일들로는 /etc/syslog.conf 가 주로 사용되고, 
/etc/sysconfig/syslog, 원격백업등을위해서 /etc/hosts 파일과,  /etc/services 파일등의 편집이
필요할 수도 있습니다.



2. syslog.conf 파일 설명

이 파일은 형식이, [selector]와 [action] 으로 나눠지며, 다시 [selector]는 [facility]와

[severity]로 나눠 집니다. 여기서 facility자리는 "어떤것에대해" 정도로  생각하면되고,

severity는 "우선순위" 입니다.  [action]은 보통 파일이름을 지정해서, 해당파일에 쓰란거죠.

여기다 원격지를 지정하면 원격지로  보냅니다.


정리하면, [facility][severity][action]은,  어떤것에대해(facility), 어떤 심각도(severity) 로,
어떻게 해라(action)  입니다.


[facility] 리스트 -----------------------------------------

kern: 커널
user: 사용자 레벨(일반 프로세스)
mail: 메일 서브 시스템
auth: 보안, 권한 프로그램들
daemon: 다른 시스템 데몬
news: 뉴스 서브시스템
local0-7:  다른용도 사용을위해 예약
* : 모든것

(이 외에도 몇가지가 더 있습니다.)


[severity] 리스트 ----------------------------------------

0 :  emergency 비상상태
1 :  alert 상태
2 :  critical 상태
3 :  error 상태
4 :  warning 상태
5 :  notice 상태
6 :  info 정보 메세지 (시스템 분석용)
7 :  debug (프로그램 디버그할때)
none : 이것이 facility와 사용되면 해당 facility는 제외,


[action] 필드 --------------------------------------------

파일명 : 해당 파일에 기록
@호스트명 : 해당 호스트로 전송

종합해서 샘플을 풀이해보자면,


mail.debug   /tmp/maillog
(mail 에대해, 상태는 debug로해서, /tmp/mailog 에 기록하라)


*.debug;mail.none    @myhost
(모든것에대해, 상태는 debug로, mail은 제외하고,  myhost로 전송하라)


conf설정에서 중요한것은 칸을 띄울때는 공백이 아니라, 탭으로 하여야 합니다.(중요!!!)


3. 원격 저장을 위한 설정


3.1  로그를 받는 쪽


로그백업을 원격지로 보내기위해서는, 보내려는 syslogd 를 기동시킬때,
/etc/sysconfig/syslog 파일을 열어서

SYSLOGD_OPTIONS="-m 0 -r"        
처럼 바꿔줍니다. -r 이 Remote 의미 입니다. 물론 위 설정을 안바꾸고 syslogd를 기동시킬때
옵션으로 줘도 되죠.



3.2  로그를 보내려는 쪽


/etc/hosts 파일을 편집합니다.  로그 서버를 giran이라고 칭하고, 도메인이 giran.uu.net 이며,
IP를  111.111.111.111 이라면

111.111.111.111   giran.uu.net  giran   loghost

처럼 설정을 해둡니다.  /etc/hosts 파일 형식은 참고로,
[IP-address fully-qualified-domain-name hostname "loghost"] 형식입니다.


이렇게만 해두면, 로그를 받는 서버측이 잘 작동하는것을 볼 수 있습니다.
하지만, 우리의 문제는 로그를 받는쪽 서버의 일개 계정 사용자 뿐이라는 거죠.
그래서 슈퍼유저가 아니라서, 받을수도 없고, 설정할 수도 없고, 기존 로그파일에
섞일 우려도 있고요.


3.3  일반사용자 계정으로 로그서버 설정 과 구축


A) /etc/services 파일 수정


이 기능을 사용하려면, 먼저 [보내는 쪽]에서 수정해야할게 /etc/services 파일을 열어서

syslog  514/udp

라고 되있는 부분을 1514 처럼 원하는 값으로 바꿔주세요.
(이 값은 후에나올, slog 툴에서 리슨 포트랑 일치해야 겠죠)

이렇게 하는 이유는 syslogd 는 원격지로 패킷을 보낼때, udp 514번을 이용합니다.
514번은 이미 글로벌하게 사용되는 포트이고, 우리는 사적으로 사용할 계획이니까요.


B) /etc/syslog.conf 파일 예제


*.info;mail.none;news.none     /var/log/messages
*.info;mail.none;news.none     @loghost


위에서, 첫줄은 보통 디폴트로 있는 구문입니다. 그 아래에 같은형식으로 적고, 파일이 아닌
호스트로 수정해주세요. 이렇게 같은걸 2줄 적는 이유는 동시에 처리되게 하려는거죠
로컬 로그파일에도 기록되고, 원격 호스트로도 보내고요.


C) /etc/hosts 파일 예제


111.111.111.111   giran.uu.net  giran   loghost

이것은 위에서 언급했습니다.

이렇게 해서 [로그를 보내려는 클라이언트]의 설정이 마무리 되었습니다.
서버측은 설정할게 없습니다. 단지 자신의 개인 계정에서 첨부 소스파일을 압축을 풀어
소스에서, LOG_HOME 수정후, 컴파일하여 실행시키면 됩니다.

#define LOG_HOME    "/user4/starzan/slog/"
처럼 되있는 부분을 자신의 계정의 디렉토리를 지정하면 되겠네요. 만약 포트가 충돌된다면,
소스에서 역시 포트 번호를 바꾸시면 되며, C 소스파일에 대해서는 설명을 생략합니다.
소스는 저도 손가는대로 짠이후 안봐서 버그가 있을수 있으니, 직접 고쳐 사용하시던지
아니면, 적어주세요. ^^

# tar xvfz slog.tgz

# make        (바이너리 만듦니다.)

# ./slog
# 죽일때는, kill  [pid]

이 slog는 로그파일을 원격지 ip별로 기록합니다. 저 같은경우 이렇게 실행 함으로서
여러대의 로그파일을 관리했죠.
즉,
111.111.111.111.log
111.111.111.112.log
111.111.111.113.log
처럼 패킷이 들어오는 ip에 따라 로그에 기록합니다. 그래서 서버별로 관리 하기 좋죠.

이상입니다.



(첨부소스는, 간단한 UDP 서버 입니다

Posted by theYoungman
engineering/Network Eng.2006. 8. 11. 15:52

[ 802.1 LAN/MAN architecture, Security, MAC & LLC layers ]

http://grouper.ieee.org/groups/802/1/


Active Project

  • Interworking
  • 802.1Q-REV - 802.1Q Revision
  • 802.1AC - Media Access Control Service revision
  • 802.1ad - Provider Bridges
  • 802.1ag - Connectivity Fault Management
  • 802.1ah - Provider Backbone Bridges
  • 802.1aj - Two-port MAC Relay
  • 802.1ak - Multiple Registration Protocol
  • Security
  • 802.1aa - 802.1X Revision (early drafts)
  • 802.1X-REV - 802.1X Revision (later drafts)
  • 802.1AE - MAC Security
  • 802.1af - MAC Key Security

  • Archived Projects

  • 802 - Overview & Architecture
  • 802a - Playpen Ethertypes
  • 802b - Registration of Object Identifiers
  • 802.1D (1998) - MAC bridges
  • 802.1D (2004) - MAC Bridges
  • 802.1G - Remote MAC bridging
  • 802.1p - Traffic Class Expediting and Dynamic Multicast Filtering (published in 802.1D-1998)
  • 802.1Q - Virtual LANs
  • 802.1s - Multiple Spanning Trees
  • 802.1t - 802.1D Maintenance
  • 802.1u - 802.1Q Maintenance
  • 802.1v - VLAN Classification by Protocol and Port
  • 802.1w - Rapid Reconfiguration of Spanning Tree
  • 802.1X - Port Based Network Access Control
  • 802.1y - 802.1D Maintenance (published under 802.1D(2004))
  • 802.1z - 802.1Q Maintenance - withdrawn
  • 802.1AB - Station and Media Access Control Connectivity Discovery

    [ 802.2 Logical Link Control (LLC) ]

    http://grouper.ieee.org/groups/802/2/


    Working Group (WG) 802.2 develops standards for Logical Link Control (LLC).

    WG 802.2 is inactive (in "hibernation") with no new projects in development. Its completed work is a published standard, variously designated

  • ANSI/IEEE Standard 802.2, 1998 Edition, and
  • ISO/IEC 8802-2:1998.
  • On December 10, 2003, the IEEE-SA Standards Board approved the reaffirmation of Standard 802.2.

    Participants in the reaffirmation ballot offered 39 comments, which the Working Group studied and discussed. Comments and committee rejoinders are preserved in a Comment Report, which may serve as a useful reference for understanding Std. 802.2.

    CONTACT INFORMATION

    The Chair of WG 802.2 is David Carlson.

    The sponsor is the LAN and MAN Standards Committee (LMSC), a.k.a. Project 802.

    ANSI/IEEE Standard 802.2, 1998 Edition is available online at the Get IEEE 802™ home page



    [ 802.3 CSMA/CD (ETHERNET) ]

    http://grouper.ieee.org/groups/802/3/


  • IEEE 802.3 Call for interest:

  • The IEEE 802.3 Working Group develops standards for CSMA/CD (Ethernet) based LANs. We have a number of active projects as listed below:

  • Additional information:
  • Next IEEE 802.3 Interim meeting notice.
  • Next IEEE 802 Plenary meeting notice.
  • IEEE 802.3 related announcements.
  • IEEE 802.3 Plenary minutes.
  • IEEE 802.3 Maintenance.
  • IEEE 802.3 Interpretations.
  • IEEE 802.3 related Plenary tutorials.
  • IEEE 802.3 reflector policy.
  • IEEE 802.3 Management registration arcs.
  • IEEE 802.3 Auto-Negotiation selector fields.
  • IEEE 802.3 Private area (password-protected).
  • Other information:
  • Operating Rules of IEEE Project 802 Working Group 802.3, CSMA/CD LANs.
  • Requirements for Voting on IEEE 802.3 Drafts.
  • Typical Working Group 802.3 meetings during IEEE 802 Plenary Week.
  • Requesting an interpretation of the Standard.
  • IEEE 802.3 Patent policy.
  • Discussion of Cost in Working Group 802.3.
  • Published Standard:
  • IEEE 802 Standards Available for Free Download.
  • Purchasing published IEEE 802.3 Standards and drafts.
  • IEEE Standards On-Line Subscription Information.
  • IEEE Standards Ordering Information.
  • Publication Status of IEEE 802.3 Documents.
  • Correction sheets for published IEEE 802.3 Standard.
  • ISO/IEC approval status for published IEEE 802.3 Standard.
  • Machine readable extracts of published IEEE 802.3 Standard.
  • Archive Information of completed work:
  • IEEE 802.3 Trunking Study Group.
  • IEEE 802.3 Higher Speed Study Group.
  • IEEE 802.3 DTE Power via MDI Study Group.
  • IEEE 802.3 10GBASE-CX4 Study Group.
  • IEEE 802.3 10GBASE-T Study Group.
  • IEEE 802.3 Backplane Ethernet Study Group.
  • IEEE 802.3 10Gb/s on FDDI-grade MM fiber Study Group.
  • IEEE 802.3 Power over Ethernet Study Group.
  • IEEE Std 802.3z-1998, Gigabit Ethernet.
  • IEEE Std 802.3aa-1998, Maintenance #5.
  • IEEE Std 802.3ab-1999, 1000BASE-T.
  • IEEE Std 802.3ac-1998, VLAN TAG.
  • IEEE Std 802.3ad-2000, Link Aggregation.
  • IEEE Std 802.3ae-2002, 10Gb/s Ethernet.
  • IEEE Std 802.3af-2003, DTE Power via MDI.
  • IEEE Std 802.3ag-2002, Maintenance #6 (Revision).
  • IEEE Std 802.3ah-2004, Ethernet in the First Mile.
  • IEEE Std 802.3aj-2003, Maintenance #7.
  • IEEE Std 802.3ak-2004, 10GBASE-CX4.
  • IEEE Std 802.3REVam-2005, Maintenance #8 (Revision).
  • IEEE Std 1802.3-2001, Conformance Test Maintenance #1.
  • IEEE P802.3 Ethernet over LAPS liaison Ad hoc.
  • IEEE P802.3 Static Discharge in Copper Cables Ad hoc.
  • IEEE P802.3 100BASE-FX over dual Single Mode Fibre Call For Interest.
  • Contact Information:

  • [ 802.4 TOKEN BUS ]

    http://grouper.ieee.org/groups/802/4/


  • The IEEE 802.4 Working Group develops standards for Token Bus. This working group is currently in hibernation (inactive) with no ongoing projects.
  • CONTACT INFORMATION

    IEEE Standards Staff Liaison for IEEE 802: Denise Pribula.

    IEEE 802.4 Hibernating Working Group Chair: Paul Eastman.


    [ 802.5 Web Site ]

    http://grouper.ieee.org/groups/802/5/

    Working Group Standalone Documents

    This is a set of standalone documents that support the committee's work. It includes:

    • a committee mission statement
    • committee membership list,
    • committee voter and observer information
    • a master list for meeting documents
    • editorship rules and
    • a list of outstanding maintenance work to be carried out by the committee.

    Published Standards

      8802-5 : 1998 (ISO/IEC) [ANSI/IEEE 802.5, 1998 Edition]

      Information technology--Telecommunications and information exchange between systems--Local and metropolitan area networks--Specific requirements--
      Part 5: Token ring access method and physical layer

    • Standard details.
    • Order from here.

    802.5c-1991 (R1997) Supplement to IEEE Std 802.5-1989

    Recommended Practice for Dual Ring Operation with Wrapback Reconfiguration (ANSI)

  • Standard details.
  • Order from here.
  • TR 11802-4 : 1994 (ISO/IEC) [ANSI/IEEE Std 802.5j-1993]

    Supplement to ISO/IEC 8802-5 : 1992, Fibre optic station attachment (ISO/IEC Technical Report Type 2)

  • Standard details.
  • Order from here.
  • 802.5:1998 / Amendment 1.:1998 Dedicated Token Ring Operation and Fibre Optic Media

    This document contains IEEE Stds. 802.5r-1997 and 802.5j-1997 (both approved on September 16th, 1997. DTR is a mode of operation of token ring equipment on dedicated (i.e., point-to-point) links. It defines DTR Concentrators and DTR Stations. DTR Concentrators have C-Ports which have two modes of operation: Port mode, and Station emulation mode. Both DTR Concentrators and DTR Stations may support two access methods: token-passing (TKP) and transmit-immediate (TXI). The full power of DTR is seen on links operating with the TXI access protocol, because this protocol allows the link to carry data at full speed in both directions at once (full-duplex operation).

  • Standard details.
  • Order from here.
  • Archive Material

    802.5 Physical layer tutorial material

    Jim Carlo has collected the physical layer papers which have been presented to the 802.5 committee over the years. These papers represent a huge volume of expertise in the arcane field of token ring physical layer design.

    Working Groups

    P802.5t 100 Mbit/s Dedicated Token Ring

    Project scope: Generate a standard for 100 Mbit/s 802.5 Token Ring LANs with MACs based on the present 802.5 Token Ring MAC. It will support 2-pair Category 5 (100 ohm) and STP (150 ohm) cabling based on the 802.3 100BASE-TX PHY and support transmission over optical fibre based on using the 100BASE-X PHY and the FDDI fibre PMD. The standard will consist of specifications for both stations and ports. The Media Access Control (MAX) will operate a dedicated Token Ring link, using the Transmit Immediate (TXI) Access Protocol as defined for 4/16 Mbit/s Token Ring operation with minimal modifications to support operation with the IEEE 802.3 100 Mbit/s Phyisical Layer (100BASE-X PHY). The Token Ring management objects defined for 4/16 Mbit/s operation will continue to be used for 100 Mbit/s operation. The frame format between MAC and LLC will be preserved.

    P802.5v Gigabit Token Ring

    Project scope: Define IEEE 802.5 Token Ring (MAC) parameters and minimal augmentation of its operation, physical layer characteristics, and management parameters for transfer of 802.5 format frames at 1,000 Mb/s or faster. The standard will consist of specifications for both stations and ports. MAC frame format will be based on that defined for IEEE 802.5. The frame format between MAC and LLC is being preserved

  • Project Approval Request
  • IEEE Standards Status Report on P802.5v
  • Working group documents. [Secure]
  • P802.5w Errata to 802.5:1998 and Amd.1:1998

    Project scope: Correct errors in 802.5 and its amendments.

  • Project Approval Request
  • IEEE Standards Status Report on P802.5w
  • Working group documents. [Secure]
  • P802.5x Supplement to 802.1Q: Virtual Bridged LANs: Source Routing

    Scope: Specify extensions to 802.1Q to enhance support for the source route bridging method.

  • Project Approval Request
  • IEEE Standards Status Report on P802.5x
  • Working group documents. [Secure]
  • P802.5rev Token Ring standard revision

    Scope: Unification of the token ring standards and supplements with clarification and corrections.

  • Project Approval Request
  • IEEE Standards Status Report on P802.5
  • Working group documents. [Secure]
  • P802.5z Aggregation of Multiple Link Segments

    Scope: Specify a DTE to DTE logical link which consists of n parallel instances of an 802.5 point-to-point link segment. The logical link will support existing 802.5 MAC clients.

  • Project Approval Request
  • IEEE Standards Status Report on P802.5z
  • Working group documents. [Secure]
  • P802.5?? Enhanced Source Routing

    Scope: The source route bridging method [802.1d] will be enhanced to provide additional resilience and may be enhanced to provide additional load sharing capabilities.

  • Project Approval Request

  • [ 802.6 METROPOLITAN NETWORKS ]

    http://grouper.ieee.org/groups/802/6/


  • The IEEE 802.6 Working Group develops standards for Metropolitan Networks. This working group is currently in hibernation (inactive) with no ongoing projects.
  • CONTACT INFORMATION

    IEEE Standards Staff Liaison for IEEE 802: Denise Pribula.

    IEEE 802.6 Hibernating Working Group Chair: Jim Mollenauer.


    [ 802.7 Broadband TAG ]

    http://grouper.ieee.org/groups/802/7/


  • The IEEE 802.7 Broadband Technical Advisory Group (TAG) developed a recommended practice, IEEE Std 802.7 - 1989, IEEE Recommended Practices for Broadband Local Area Networks (Reaffirmed 1997). This group is inactive with no ongoing projects. The maintenance effort for IEEE Std 802.7 - 1989 is supported by 802.14.
  • CONTACT INFORMATION

    IEEE Standards Staff Liaison for IEEE 802: Denise Pribula.


    [ 802.8 FIBER OPTIC TAG ]

    http://grouper.ieee.org/groups/802/8/


  • The IEEE 802.8 Technical Advisory Group (TAG) develops recommended practices for fiber optics.
  • CONTACT INFORMATION

    IEEE Standards Staff Liaison for IEEE 802: Denise Pribula.

    IEEE 802.8 Working Group Chair: Chip Benson.


    [ 802.9 ISOCHRONOUS LANS ]

    http://grouper.ieee.org/groups/802/9/

  • The IEEE 802.9 Working Group develops standards for Isochronous LANs.

  • CONTACT INFORMATION
  • IEEE Standards Staff Liaison for IEEE 802: Denise Pribula.

    IEEE 802.9 Working Group Chair: Dhadesugoor Vaman.


    [ 802.10 Standards for Interoperable LAN/MAN Security (SILS) ]

    http://grouper.ieee.org/groups/802/10/


    The SILS working group has completed its activities in developing LAN/MAN security standards. Although the group is inactive information may still be obtained through the contacts listed below.

    STANDARDS

  • Get IEEE 802
  • MEMBERS ONLY INFORMATION

  • E-mail Reflector: std-802-10.
  • CONTACT INFORMATION

  • IEEE Standards Staff Liaison for IEEE 802: Andrew Ickowicz.
  • IEEE 802.10 Working Group Chair: Ken Alonge.

  • [ 802.11 WIRELESS LOCAL AREA NETWORKS ]

    http://grouper.ieee.org/groups/802/11/

    IEEE 802.11a-1999 (8802-11:1999/Amd 1:2000(E)), IEEE Standard for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications—Amendment 1: High-speed Physical Layer in the 5 GHz band

    IEEE 802.11b-1999 Supplement to 802.11-1999,Wireless LAN MAC and PHY specifications: Higher speed Physical Layer (PHY) extension in the 2.4 GHz band

    802.11b-1999/Cor1-2001, IEEE Standard for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications—Amendment 2: Higher-speed Physical Layer (PHY) extension in the 2.4 GHz band—Corrigendum1

    IEEE 802.11d-2001, Amendment to IEEE 802.11-1999, (ISO/IEC 8802-11) Information technology--Telecommunications and information exchange between systems--Local and metropolitan area networks--Specific requirements--Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Operation in Additional Regulartory Domains

    IEEE 802.11F-2003 IEEE Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation

    IEEE 802.11g-2003 IEEE Standard for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications—Amendment 4: Further Higher-Speed Physical Layer Extension in the 2.4 GHz Band

    IEEE 802.11h-2003 IEEE Standard for Information technology—Telecommunications and Information Exchange Between Systems—LAN/MAN Specific Requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Spectrum and Transmit Power Management Extensions in the 5GHz band in Europe

    IEEE 802.11i-2004 Amendment to IEEE Std 802.11, 1999 Edition (Reaff 2003). IEEE Standard for Information technology--Telecommunications and information exchange between system--Local and metropolitan area networks?Specific requirements--Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications--Amendment 6: Medium Access Control (MAC) Security Enhancements

    IEEE 802.11j-2004 IEEE Standard for Information technology—Telecommunications and information exchange between systems--Local and metropolitan area networks—Specific requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications—Amendment 7: 4.9 GHz–5 GHz Operation in Japan



    [ 802.12 DEMAND PRIORITY ]

    http://grouper.ieee.org/groups/802/11/

  • The IEEE 802.12 Working Group develops standards for Demand Priority.
  • CONTACT INFORMATION

    IEEE Standards Staff Liaison for IEEE 802: Denise Pribula.

    IEEE 802.12 Working Group Chair: Pat Thaler.



    [ 802.15 Working Group for Wireless Personal Area Networks ]

    http://grouper.ieee.org/groups/802/15/


    ABOUT

    The 802.15 WPAN?effort focuses on the development of consensus standards for Personal Area Networks or short distance wireless networks.  These WPANs address wireless networking of portable and mobile computing devices such as PCs, Personal Digital Assistants (PDAs), peripherals, cell phones, pagers, and consumer electronics; allowing these devices to communicate and interoperate with one another. The goal is to publish standards, recommended practices, or guides that have broad market applicability and deal effectively with the issues of coexistence and interoperability with other wired and wireless networking solutions.

    The IEEE 802.15 Working Group is part of the 802 Local and Metropolitan Area Network Standards Committee of the IEEE Computer Society. The IEEE-SA is an international membership organization serving today's industries with a complete portfolio of standards programs. The IEEE has more than 368,225 members in approximately 150 countries. Through its members, the IEEE is a leading authority on areas ranging from aerospace, computers and telecommunications to biomedical engineering, electric power and consumer electronics.

    For more information on 802.15 or to participate, contact Bob Heile (+1 781 222 1393 voice), bheile@ieee.org .



    [ 802.16 Working Group on Broadband Wireless Access Standards ]

    http://grouper.ieee.org/groups/802/16/


    The IEEE 802.16 Working Group on Broadband Wireless Access Standards develops standards and recommended practices to support the development and deployment of broadband Wireless Metropolitan Area Networks. IEEE 802.16 is a unit of the IEEE 802 LAN/MAN Standards Committee, the premier transnational forum for wireless networking standardization.

    People often take the view that standardization is the enemy of creativity. But I think that standards help make creativity possible -- by allowing for the establishment of an infrastructure, which then leads to enormous entrepreneurialism, creativity, and competitiveness.
    -Vint Cerf, TCP/IP co-developer and Internet pioneer, in
    Fast Company, April 2000.

  • News
  • Session #39 held 12-15 Sept in Taipei; report to follow
  • Session #38 Report highlights results of meetings of 18-22 July 2004
  • IEEE 802.16 Project Development Milestone Schedules
  • Session Reports
  • General Information
  • Background Information on IEEE 802.16
  • Tutorials
  • Published IEEE 802.16 Standards and Drafts
  • Download some IEEE 802.16 Standards under Get IEEE 802TM program
  • Liaisons and External Organizations
  • What People Are Saying about IEEE 802.16
  • Details (mainly for participants)
  • Upcoming Meetings (and previous ones)
  • Working Group Documents (also see TG & Liaison pages)
  • Unfiled Contributions
  • Task Groups and Committees
  • Working Group Letter Ballots
  • Key Development Resources
  • Participants, Participation, and Membership
  • Legal Issues
  • Submitting Documents
  • Search IEEE 802.16 Webspace


  • [ 802.17 Resilient Packet Ring Working Group ]

    http://grouper.ieee.org/groups/802/17/

    Working Group Description

    The IEEE 802.17 Resilient Packet Ring Working Group (RPRWG) develops standards to support the development and deployment of Resilient Packet Ring networks in Local, Metropolitan, and Wide Area Networks for resilient and efficient transfer of data packets at rates scalable to many gigabits per second. These standards build upon existing Physical Layer specifications, and will develop new PHYs where appropriate. IEEE 802.17 is a unit of the IEEE 802 LAN/MAN Standards Committee.

    In Metropolitan and Wide Area Networks, fiber optic rings are widely deployed. These rings are currently using protocols that are neither optimized nor scalable to the demands of packet networks, including speed of deployment, bandwidth allocation and throughput, resiliency to faults, and reduced equipment and operational costs.

    Active Projects

    802.17b Amendment

    802.17 Maintenance

    802.17 Interpretations

    Completed Projects

    802.17-2004 Base Standard

    802.17a-2004 Amendment

    Working Group Contact Information

    Chair:Mike Takefman
    Vice Chair:John Lemon
    Secretary:Volunteer Needed
    Webmaster:John Lemon
    IEEE Standards Staff Liaison for IEEE 802: Sue Vogel


    [ 802.18 LAN/MAN Standards Committee 802.18 - the Radio Regulatory TAG ]

    http://grouper.ieee.org/groups/802/18/


    Introduction

    IEEE 802, the LAN/MAN Standards Committee, or LMSC, currently has 6 Working Groups with projects on standards for radio-based systems ... IEEE 802.11 (WLAN), IEEE 802.15 (WPAN), IEEE 802.16 (WMAN), IEEE802.20 (Wireless Mobility), IEEE 802.21 (Handoff/Interoperability Between Networks), and IEEE 802.22 (WRAN).

    Therefore, monitoring of, and active participation in, ongoing radio regulatory activities, at both the national and international levels, are an important part of LMSC's work. That is the job of the 802.18 Radio Regulatory Technical Advisory Group ("RR-TAG"). Any suggestions for improvements to these pages to make them more useful will always be welcome and may be sent to Michael Lynch.

    Hot Items

    The 802.18 RR-TAG September interim meeting will be held in Geneva, Switzerland, from 19 - 23 September.  The RR-TAG will be meeting in the ITU facility.  The meeting will provide RR-TAG attendees exposure to the ITU-R process, allow ITU-R meeting attendees to learn what the function of the RR-TAG is and to encourage participation in the IEEE process.

    The meeting announcement will be sent 21 August to the RR-TAG reflector.  For further details, to include registration, please contact the RR-TAG chair.

    The link is up now and available for the September joint wireless interim session (excluding the RR-TAG) in Orange County.

    A link is also available for the January joint wireless interim session in Hawaii.  It is advisable to book your hotel well in advance.



    [ 802.19 Coexistence Technical Advisory Group (TAG) ]

    http://grouper.ieee.org/groups/802/19/


    IEEE 802.19 TAG GENERAL INFORMATION

  • 802.19 Meeting Plan Information.
  • 802.19 Closing Reports.
  • 802 Policies & Procedures
    • Coexistence Assurance Excerpt:
      • "6.4 Technical Feasibility
        d) Coexistence of 802 wireless standards specifying devices for unlicensed operation.  The working group proposing a wireless project is required to demonstrate Coexistence through the preparation of a Coexistence Assurance (CA) document unless it is not applicable.
        • Working Group will create a CA document as part of the balloting process.
        • Working Group will not create a CA document
          • Reason it is not applicable: ___________________________________"
      • "22. Procedure for Coexistence Assurance (Formally Procedure 11)
        If indicated in the five criteria, the wireless working group shall produce a coexistence assurance (CA) document in the process of preparing for working group letter ballot and sponsor ballot.  The CA document shall accompany the draft on all wireless working group letter ballots.  The CA document shall address coexistence with all relevant approved 802 wireless standards specifying devices for unlicensed operation. The working group should consider other specifications in their identified target band(s) in the CA document.  The 802.19 TAG shall have one vote in working group letter ballots that include CA documents.  As part of their ballot comments, the 802.19 TAG will verify the CA methodology was applied appropriately and reported correctly.  The ballot group makes the determination on whether the coexistence necessary for the standard or amendment has been met if the ballot passes.  A representative of the 802.19 TAG should vote in all wireless sponsor ballots that are in the scope of the 802.19 coexistence TAG."
        Source: Revised effective March 21, 2005, LMSC_P&P_MARCH_2005_R050722.DOC
  • 802.19 Policy and Procedures Adobe Acrobat (228KB).
  • 802.19 list of projects requiring a CA document.
  • 802.19 Submission Templates:
  • MS Word (37KB). 
  • MS PowerPoint (57KB).
  • Search 802.19 Web Site.
  • E-Mail Reflector.
  • IEEE 802.19 TAG ARCHIVED INFORMATION

  • 802.19 Mailing-List archive by date by thread.
  • Document Archives.
  • IEEE 802.19 TAG CONTACT INFORMATION

  • IEEE 802.19 TAG Chair: Steve Shellhammer
  • IEEE 802.19 TAG Vice Chair: Tom Siep
  • IEEE 802.19 TAG Editor: David Cypher
  • IEEE 802.19 TAG Secretary: Steve Whitesell
  • IEEE 802.19 TAG Sponsor: Paul Nikolich
  • IEEE Standards Staff Liaison: Andrew Ickowicz
  • IEEE 802.11 Liaison: Sheung Li
  • IEEE 802.15 Liaison: Tom Siep

  • RELATED LINKS

  • IEEE Wireless Zone
  • IEEE 802.11 WLAN
  • IEEE 802.15 WPAN
  • IEEE 802.16 WMAN
  • IEEE 802.18 RR TAG
  • IEEE 802.20 MBWA
  • IEEE 802.21 Media Independent Handoff Working Group
  • IEEE 802.22 WRANs
  • IEEE 802 LAN/MAN Standards Committee
  • IEEE Computer Society
  • IEEE Site Map

  • [ 802.20 Mobile Broadband Wireless Access (MBWA) ]

    http://grouper.ieee.org/groups/802/20/


    IEEE 802.20 Mission and Project Scope

    On 11 December 2002, the IEEE Standards Board approved the establishment of IEEE 802.20, the Mobile Broadband Wireless Access (MBWA) Working Group.

    • Mission

      The mission of IEEE 802.20 is to develop the specification for an efficient packet based air interface that is optimized for the transport of IP based services. The goal is to enable worldwide deployment of affordable, ubiquitous, always-on and interoperable multi-vendor mobile broadband wireless access networks that meet the needs of business and residential end user markets.

    • MBWA Scope

      Specification of physical and medium access control layers of an air interface for interoperable mobile broadband wireless access systems, operating in licensed bands below 3.5 GHz, optimized for IP-data transport, with peak data rates per user in excess of 1 Mbps. It supports various vehicular mobility classes up to 250 Km/h in a MAN environment and targets spectral efficiencies, sustained user data rates and numbers of active users that are all significantly higher than achieved by existing mobile systems.



    [ 802.21 ]

    http://grouper.ieee.org/groups/802/21/


    Welcome

    IEEE 802.21 is developing standards to enable handover and interoperability between heterogeneous network types including both 802 and non 802 networks.

    Membership

    The rules governing attaining voting member status are here:

  • Membership
  • Submissions

    If you would like to post a file on these pages, please send the file to the address below and the file will be posted in the appropriate area within the web site.

  • First Read: Submitting Documents
  • Then send file to: Ajay Rajkumar
  • Working Group Documents

    Current work items are based on the PAR:

  • PAR
  • Five Criteria doc
  • Latest draft
  • Documents and submissions toward the current work items are copyright of the IEEE but publicly available here. There is a separate server for the conferences, so there can be some lag time for updates between the two servers.

  • November 2005
  • September 2005
  • July 2005
  • May 2005
  • March 2005
  • January 2005
  • November 2004
  • September 2004
  • July 2004
  • May 2004
  • March 2004

  • [ 802.22 LAN/MAN Standards Committee 802.22 WG on WRANs (Wireless Regional Area Networks) ]

    http://grouper.ieee.org/groups/802/22/


    Introduction

    IEEE 802.22, the Working Group on Wireless Regional Area Networks ("WRANs") is the newest Working Group in the IEEE 802 LMSC.

    Its charter, under the PAR approved by the IEEE-SA Standards Board is to develop a standard for a cognitive radio-based PHY/MAC/air_interface for use by license-exempt devices on a non-interfering basis in spectrum that is allocated to the TV Broadcast Service.

    Meeting documents will be posted, on a per meeting basis, on this website, as soon as possible after the conclusion of meetings, and will be available via an index under the "Meeting Documents" link in the link bar at the left of this page.

    A "Members Only" directory, with password protection, has been established under the "Members Only Documents" tab in the link bar, but currently has no content other than a "placeholder" page. When "members only" content is generated, an e-mail will be sent to those entitled to access the private area with the required userid and password to gain access..

    Any suggestions for improvements to these pages to make them more useful, or reports of broken links, will always be welcome and may be sent to Carl Stevenson.

    HOT ITEMS


    The IEEE 802 November 2005 Plenary Session Event Portal is NOW available for meeting registration and hotel reservations at: http://ieee802.facetoface-events.com/plenary/

    This portal now includes the Visa Invitation Letter as well, however all potential attendees must registered for this Session prior to receiving the letter.


    Please find the January 2006 IEEE 802 Wireless Interim Session meeting announcement at: http://ieee802.facetoface-events.com/wireless/. Since this Session will be held in Waikoloa, Hawaii, some important preliminary meeting information (especially Early Bird room rates) is included in this document.  REGISTRATION SERVICES WILL BE AVAILABLE SOON FOR THIS JANUARY 2006 SESSION!!


    Call for Notice of Intent to Propose - Deadline Extended (again)

    Due to a number of requests for an extension, the deadline has been extended again. Those intending to submit proposals for consideration towards a baseline upon which the first draft of the IEEE 802.22 Standard will be based must notify the Chair of the WG by e-mail no later than 6:00 pm, EDT, on Saturday, October 15th, 2005. There will be NO further extensions of this deadline.

    Requirements Document and Channel Model Approved

    The Requirements and Channel Model documents wer approved at our September interim meeting in Garden Grove, CA, and are now available in the September 2005 area of "Meeting Documents"
    (document numbers 22-05-0007-46-0000 and 22-05-0055-07-00 respectively)
    The Channel Model document is in the process of being editorially incorporated into the Requirements document as Appendix C and revision 47 of the Requirements document will be posted as soon as that editorial task has been completed (merging two Word docs with different formatting and styles without making a mess of things is a tedious task).
    Until the merged document is posted in the September 2005 directory, the separate documents should meet the needs of those who are preparing proposals.

    Call for Proposals

    A "Call for Proposals" has been issued via the IEEE 802.22 e-mail reflector and cc'd to the Chairs of the other Wireless WGs and TAGs for forwarding to their e-mail reflectors. A copy of the Call for Proposals document is available in the November 2005 section of "Meeting Documents." Remember the deadline for submitting a "Notice of Intent to Propose." Proposals will only be accepted from proposers who meet the notice requirement.



    last update. 2005-10-24.

    Posted by theYoungman
    engineering/Network Eng.2006. 8. 11. 15:13

    BGP (Border Gateway Protocol)는 AS Number가 다른 네트웍간에 Routing Information을 주고 받는 Exterior Gateway Protocol로 현재 BGP는 Version 4가 이용되고 있는데 이것을 간단히 줄여 BGP4라고 하며 앞으로 이책에서 BGP는 BGP4를 의미한다

     

    /개요

    가. BGP는 언제 필요한 Routing Protocol 인가?



    /Policy Routing

    BGP는 AS Number간 다른 두 네트웍간에 Routing Information을 주고 받을때 이용될 수 있는 Exterior Gateway Protocol이다. 따라서 AS Number가 동일한 네트웍내에서 BGP를 이용할 필요는 없다. AS Number가 동일한 네트웍에서는 RIP, IGRP, OSPF, EIGRP와 같은 Interior Gateway Protocol을 이용하는 것이 바람직하다.

    AS Number가 다른 두 네트웍을 연결할 때 반드시 BGP를 이용할 필요는 없다. Part III. 7. Routing Information의 재분배에서 AS Number가 다른 두 네트웍을 연결할때 재분배를 통하여 Routing Information을 주고 받을 수 있도록 할수 있었기 때문이다.

    BGP는 Policy Routing Protocol이라고 하는데 이유는 Routing이 라우터에 의해 결정되는 것이 아니라 네트웍운영자의 정책에 의해 결정되기 때문이다.

    AS100이 Interior Gateway Protocol로 AS200과 상호접속을 하였다고 가정하자. 이 경우 AS100에 있는 네트웍에 대한 정보는 AS200에 의하여 재분배된 다음 인터넷으로 전달된다. AS100에 130.100.0.0이 있다면, 인터넷측에서 130.100.0.0은 AS200에 속하는 것으로 간주한다.

    즉 AS100은 의미가 없으며 AS200만이 있을 뿐이다. 이런 경우 AS100은 AS200의 라우팅정책을 따르게 된다. 즉 외부의 입장에서 볼때 확장된 AS200 만이 있을 뿐이다. AS100과 같이 독자적인 라우팅정책이 필요하지 않을 경우는 BGP를 이용하여 접속하지 않아도 된다. 독자적인 라우팅정책을 필요로 하지 않는 경우는 일반적으로2개 이상의 다른 AS에 접속하지 않는 경우이다. 그림에서 AS100은 AS200으로만 연결이 되어 있다.

    다음과 같은 경우는 상황이 다르다. AS100이 IGP로 AS200과 접속한 상태에서  AS300으로 직접 갈 수 있는 경로를 추가로 구성하였다고 가정하자. 이때 AS100과 AS300은 Interior Gateway Protocol로 접속하는 것이 타당할까? 답은 물론 아니다. AS100과 AS300이 IGP로 접속할 경우 AS100에 있는 네트웍정보가 AS300을 통해 외부로 전달되기 때문에 문제가 발생한다.

    즉 인터넷 입장에서 볼때 AS100에 있는 130.100.0.0이 AS200에도 속하고 AS300에도 속하는 것처럼 보이기 때문이다. 인터넷 전체의 Routing에 큰 혼란을 초래한다. 따라서 어떤 네트웍을 다른 2개의 AS에 IGP로 연결하는 것은 피해야 한다.

    따라서 위의 문제 상황을 피하기 위해서 아래와 같이 AS100은 AS300과 BGP로 접속을 하여야 한다.

    위 상황에서 AS200은 AS300에 대한 정보를 AS100을 통해 받기를 원하지 않을 수 있다. 그러나 AS200은 AS100을 통해 AS300에 대한 정보를 전달을 받고 있으며, AS200이 AS100과 IGP로 접속되어 있기 때문에 원하는대로 Routing을 처리하기는 쉽지 않다.

    따라서 AS200과 AS100은 다음과 같이 BGP로 접속하는 것이 바람직하다. 이와 같이 AS간에 BGP로 접속을 하면 각 AS별로 독자적인 라우팅정책을 정하고 편리하게 구현할 수 있다.

    각 AS에서는 다음과 같은 라우팅정책을 수립하고 구현할 수 있다. AS200과 AS300을 인터넷사업자(ISP: Internet Service Provider)라고 가정하자.

    다음의 예는 국내의 ISP들이 실제 구현하고 있는 방법이기도 하다.

    /AS100
    인터넷으로 갈때는 라우터B를 통해 AS200을 경유한다.
    - AS300으로 갈때는 라우터D를 통해 직접 간다.
    /AS200
    - AS100에 있는 네트웍은 AS200을 경유하여 인터넷으로 갈 수 있다.
    - AS300은 AS100, AS200을 경유하여 인터넷으로 갈 수 없다.
    - AS300과의 통신은 인터넷을 경유하도록 한다.
    /AS300
    - AS100에 있는 네트웍은 AS300으로 접속할 있다.
    - AS100은 AS300을 경유하여 인터넷으로 갈 수 없다.
    - AS200은 AS100, AS300을 경유하여 인터넷으로 갈 수 없다.
    -AS200과의 통신은 인터넷을 경유하도록 한다.

    이처럼 BGP를 이용하는 경우는 두개 이상의 AS에 접속하고 또한 독자적인 라우팅정책을 수립하여 구현할때 필요하다.

    BGP를 설정하기 위해서는 BGP를 지원하는 라우터를 구비하여야 하고 공인된 AS Number를 할당받아야 한다. BGP를 지원하는 라우터는 여러 제품이 있는데 필자는 CISCO 라우터를 주로 이용한다. AS Number를 할당받는 방법은 Part I 2.6 AS Number 등록에서 이미 언급하였다.
    나. BGP의 일반적인 특징은?
    BGP에서는 목적지에 대한 최상의 경로를 선택할때 다양한 Metric을 이용한다. IGRP에서는 Bandwidth, Delay, Reliability, Load, MTU등을 조합하여 계산한 Cost가 가장 낮은 경로를 최상의 경로를 선택하는 반면 BGP에서는 우선순위가 있는 각 Metric을 차례대로 참조하여 최상의 경로를 선택한다. BGP에서 이용하는 Metric에는 Next_Hop, Weight, Local Preference, AS_path, Origin type, MED등이 있다. 경로를 선택하고 전달하는 과정은 다음과 같다.
    /경로가 접근할 수 없는 Next_hop을 가질 경우 해당 경로를    Routing Table에서 제거한다.
    /가장 높은 Weight을 가진 경로를 선택한다.
    /Weight이 같을 경우 가장 높은 Local Preference를 가진 경로를 선택한다.
    /Local Preference가 같을 경우 BGP 라우터 자신으로부터 발생된 경로를 선택한다.
    /BGP 라우터 자신으로부터 발생된 경로가 없을 경우  AS_path의 길이가 가장 짧은 경로를 선택한다.
    /만약 경로에 대한 AS_path의 길이가 모두 같을 경우 Origin type을 보고   우선 순위가 가장 높은 것을 가진 경로를 선택한다.
    /Origin type이 같을 경우 가장 낮은 MED를 가진 경로를 선택한다.
    /MED가 같을 경우 IBGP에 의해 얻은 경로보다 EBGP에 의해 얻은 경로를 선택한다.
    /해당 경로가 동일한 IBGP나 EBGP에 의해서 얻은 것일 경우   가장 가까운 IGP Neighbor를 가진 경로를 선택한다.
    /Router ID로 가장 작은 IP Address를 가진 경로를 선택한다.

    대개 경로에 대한 Weight, Local Preference등이 동일하기 때문에 경로결정에 가장 큰 영향을 미치는 요소는 AS_path의 길이다. 위에서 언급한 Metric들에 대해서 다시 설명하도록 하겠다.

    BGP는 IGRP나 EIGRP 처럼 Multi-Path Routing을 지원하지 못하고 앞에서 언급한 경로선택과정을 통해 한 목적지에 대해 최상의 경로 1개만을 선택하여 준다.

    BGP는 Routing Information을 전달할때 Partial Update 방식을 이용한다. 따라서 처음 BGP Session을 맺을때 네트웍전체에 대한 Routing Information을 전달하지만 이후에는 변화된 정보만을 전달한다.

    BGP는 Classless Inter Domain Routing을 지원한다. Routing Information을 교환할때 목적지에 대한 Network Address를 Class 형태의 IP Network Address로만 전달하는 것이 아니라 Subnet Mask 및 Supernet Mask를 그대로 함께 전달하는 것이다. Subnet Mask를 전달할 경우는 IP Address를 효과적으로 분산해 이용할 수 있다는 장점이 있고, Supernet Mask를 전달할 경우는 Routing Table의 크기를 작게 유지할 수 있다는 장점이 있다.

    BGP에는 두 가지 형태가 있는데 첫번째 것은 External BGP이고, 두번째 것은 Internal BGP이다.

    External BGP는 다른 AS에 속한 라우터간에 맺으며, Internal BGP는 같은 AS에 속한 라우터간에 맺는다. External BGP는 EBGP로, Internal BGP는 IBGP로 줄여서 표기하기도 한다. IBGP는 EBGP에 비하여 보다 다양한 기능을 제공하는데 특히 Routing Information의 흐름을 보다 적절하게 제어할 수 있다는 장점이 있다.  

    External BGP에 대한 Administrative Distance는 20이고, Internal BGP에 대한 것은 200이다. 즉 EBGP에 의해 얻은 정보를 우선 참조한다.


    다. AS_Path 란 무엇인가?


    AS_path는 해당 목적지까지 갈때 경유하는 AS들의 AS Number들로 구성된 것이다. AS_path에는 경유하는 AS Number만 표시될 뿐이지 해당 AS에서 어떤 경로를 지나왔는지는 표시되지 않는다. 가령 다음과 같이 네트웍이 구성되어 있을 경우 AS100의 입장에서 네트웍 130.100.0.0에 대한 AS_path는 200 300 400 이다.
    AS100 ------AS200 ------AS300 -------AS400         (130.100.0.0)
    AS400에 있는 라우터는 AS300에 있는 라우터에게 130.100.0.0에 대한 정보를 전달할때 AS_path로 400을 전달한다.
    AS300 :  130.100.0.0     400
    AS300에 있는 라우터가 AS200에 있는 라우터에게 130.100.0.0에 대한 정보를 전달할때는 자신의 AS Number를 AS_path에 Prepend 시킨 AS_Path 300 400을 전달한다.
    AS200 :  130.100.0.0     300   400
    AS200에서 AS100으로 정보가 전달될때도 같은 방식이 적용된다.
    AS100 :  130.100.0.0     200   300   400
    따라서 동일한 목적지에 대한 AS_path의 길이가 짧을 경우 가까운 곳에 있다고 판단하여 짧은 AS_path를 가진 경로를 선택한다. 이러한 이유 때문에 BGP Routing을 AS_path Routing이라고도 한다.  AS_path 300 400의 길이는 2, AS_path 200 300 400의 길이는 3이다.

    AS_path에는 경유하는 AS에 대한 정보가 담겨 있는데 AS_path를 가지고 AS간에 Routing Loop을 쉽게 방지할 수 있다. 만약 AS_path에 자신의 AS Number가 표시되어 있다면 그것은 자신이 내보낸 정보이므로 해당 정보를 무시한다. 따라서 BGP Routing은 Routing Loop이 발생하지 않는다. 이러한 이유때문에 BGP를 Loop Free Routing Protocol이라고 한다.
    라. BGP 설정 방법은?
    BGP에는 두 가지 형태가 있는데 첫번째 것은 External BGP이고, 두번째 것은 Internal BGP이다. External BGP는 다른 AS에 속한 라우터간에 맺으며, Internal BGP는 같은 AS에 속한 라우터간에 맺는다. External BGP는 EBGP로, Internal BGP는 IBGP로 줄여서 표기하기도 한다. IBGP는 EBGP에 비하여 보다 다양한 기능을 제공하는데 특히 Routing Information의 흐름을 보다 적절하게 제어할 수 있다는 장점이 있다.

    BGP는 BGP Session을 맺기 위해Transport Protocol로 Transmission Control Protocol (TCP)을 이용하며 BGP Session을 맺은 상대측 라우터를 Neighbor 혹은 Peer 라고도 표현된다. BGP에서 Neighbor간에는 반드시 직접 연결되어 있을 필요는 없는데 이러한 특징은 RIP, IGRP, OSPF, EIGRP에서의 Neighbor와 다른 것에 유의하자.



    BGP를 설정하는 방법은 다음과 같다.
    Router(config)# router bgp local-asn
    Router(config-router)#
    neighbor neighbor-ip-address remote-as neighbor-asn
    router bgp는 BGP Routing Protocol을 활성화하겠다는 것이며 이때 local-asn을 함께 입력한다. local-asn은 라우터가 속한 AS의 AS Number이다. neighbor-ip-address는 Neighbor의 IP Address인데 보통 두 라우터를 연결하는 Interface에 할당된 IP Address를 많이 이용하며, 경우에 따라서 Loopback Interface에 할당된 IP Address를 이용하기도 한다. Loopback Interface에 대한 내용을 조금 뒤에 다루도록 하겠다.

    neighbor-ip-address로 지정된 라우터가 다른 AS에 있는 것이라면 이것은 EBGP Session을 맺는 것이며 이때 neighbor-asn은 Neighbor가 속한 AS Number를 입력해 주면 된다.

    neighbor-ip-address로 지정된 라우터가 같은 AS에 있는 것이라면 이것은 IBGP Session을 맺는 것이며 이때 neighbor-asn은 자신의 AS Number를 입력해 주면 된다.

    아래와 같이 라우터가 연결되어 있을 경우 EBGP 및 IBGP 설정은 다음과 같이 할 수 있다.

    Router-A(config)# router bgp 100
    Router-A(config-router)# neighbor 130.100.1.2 remote-as 100
    Router-A(config-router)# neighbor 130.100.2.2 remote-as 200

    Router-B(config)# router bgp 100
    Router-B(config-router)# neighbor 130.100.1.1 remote-as 100

    Router-C(config)# router bgp 200
    Router-C(config-router)# neighbor 130.100.2.1 remote-as 100
    위에서 라우터A와 라우터C간에는 EBGP Session을 맺었으며, 라우터A와 라우터B간에는 IBGP Session을 맺었다.

    Neighbor의 IP Address를 지정할때 유의하여야 할 점은 해당 Neighbor까지 갈 수 있는 경로가 Routing Table에 등록되어 있어야 한다는 점이다.

    일반적으로 EBGP Session은 다른 AS에 있는 라우터와 직접 연결한뒤 맺어지기 때문에 항상 Neighbor가 Routing Table에 등록이 되어 있는 반면, IBGP Session은 직접 연결되어 있지 않은 내부 라우터간에도 맺어지기 때문에 잘못 조작을 하였을 경우 Neighbor가 Routing Table에 등록되어 있지 않을 수도 있다.

    Neighbor를 Routing Table에 등록하는 방법은 IGP를 정확히 조작해 주거나 Static Route등을 등록하면 된다.
    마. Routing Information 재분배

    RIP, IGRP, OSPF, EIGRP간에 Routing Information 재분배가 가능하듯이 BGP 정보도 그들과 재분배를 할 수 있다. BGP 라우터는 내부 AS에 있는 네트웍정보를 BGP Routing Information 형태로 외부 AS에게 전달하고, 외부AS로부터 받은 네트웍정보를 IGP Routing Information 형태로 내부로 전달한다

    외부로부터 얻은 정보를 IGP로 재분배하기 위한 설정방법은 IGP간의 재분배 설정 방법과 동일하다. 아래의 그림에서 라우터A가 AS200으로부터 받은 정보를 IGP로 재분배하기 위한 설정방법은 다음과 같다.

    Router-A(config)# router bgp 100
    Router-A(config-router)# neighbor 130.100.1.2 remote-as 100
    Router-A(config-router)# neighbor 130.100.2.2 remote-as 200
    Router-A(config-router)# exit
    Router-A(config)# router ospf 100
    Router-A(config-router)# redistribute bgp 100 metric 2000 subnets
    위와 같이 외부 AS에 대한 정보를 내부 라우터에게 반드시 재분배하여 전달할 필요는 없다. 내부 AS에서 외부 AS와 연결된 BGP Router가 하나밖에 없을때 Default Route를 적용하면 내부 AS에 있는 라우터들의 부하를 줄여줄 수 있기 때문이다.



    내부 AS에 있는 네트웍정보 즉 IGP Routing Information을 BGP Routing Information으로 전달하는 방법은 재분배하는 방법과, 전달할 Network Address를 등록해주는 방법이 있다. 일반적으로 전달할 목적지에 대한 Network Address를 등록해주는 방법이 권고되고 있다. 위에서 130.100.0.0이 AS100에 속하고 그것만을 AS200에게 전달하고자 할 경우 다음과 같이 network 명령어를 이용하여 Network Addres를 등록하도록 한다. BGP에서의 network 명령어는 RIP, IGRP, OSPF, EIGRP에서의 network 명령어와 쓰임새가 다른점에 유의하자.
    Router-A(config)# router bgp 100
    Router-A(config-router)# neighbor 130.100.1.2 remote-as 100
    Router-A(config-router)# neighbor 130.100.2.2 remote-as 200
    Router-A(config-router)# network 130.100.0.0
    또 한가지 유의할 점은 130.100.0.0이 BGP에 의해 외부 AS로 전달이 되려면 130.100.0.0에 대한 경로를 BGP 라우터가 알고 있어야 한다는 점이다. 즉 130.100.0.0에 대한 경로가 BGP 라우터의 Routing Table에 등록되어 있어야 된다

    바. Routing Information 제어


    RIP, IGRP, OSPF, EIGRP에서는 IP Address만을 참조하는 Distribute-List를 가지고 Routing Information의 흐름을 제어하는 방법을 제공한다. BGP에서는 Distribute-List 이외에도 Route Map Filtering, AS_path Filtering, Community Filtering 과 같은 Filtering 을 제공한다.

    이외에도 Peer Group, CIDR, Confederation, Route Reflector, Route Flap Dampening과 같은 것들이 제공하는데 이책에서는 Distribute_List, Route Map Filtering, AS_path Filtering, CIDR, Route Reflector에 대해서만 알아보도록 하겠다.

    /BGP 설정


    BGP를 설정하는 방법에 대해서는 1.4 BGP 설정방법은?에서 이미 다루었다. 따라서 여기에서는 좀더 자세한 내용을 알아보도록 하겠다.

    가. IBGP
    /IBGP 설정이 필요한 경우
    IBGP는 한 AS내에 다른 AS와 연결된 2개 이상의 라우터가 있을 경우만 설정하여 이용하는 것이 바람직하다. 다시 표현하자면 EBGP를 운영하고 있는 라우터가 2개 이상일 경우일때만 필요하다는 것이다. 그리고 AS내에 있는 모든 라우터가 IBGP를 설정할 필요는 없으며, 기본적으로 EBGP를 운영하고 있는 라우터간에 IBGP를 설정해주면 된다.

    EBGP를 운영하고 있는 라우터가 1개일 경우 IBGP 설정은 불필요하다. IBGP는 외부 AS로부터 받은 정보를 같은 AS내에 있는 다른 EBGP 라우터에 전달, 목적지에 대한 경로를 선택할 수 있도록 하는 역할을 담당하므로 외부와 접속된 EBGP가 1개일 경우 경로는 이미 결정되어 있으므로 IBGP의 역할은 필요없게 된다. 단지 BGP 라우터는 AS 내의 다른 라우터들과는 IGP로 정보를 교환하고, BGP와 IGP간에 Routing Information을 재분배하기만 하면 된다.

    /Full Mesh 형태의 IGBP Session
    IBGP의 특성중 하나는 IBGP 라우터가 같은 AS내에 있는 IBGP 라우터로부터 네트웍의 변화된 정보를 전달받으면 그 정보를 자신과 IBGP Session을 맺은 다른 IBGP 라우터에게 전달하지 않고 EBGP를 이용하여 다른 AS에 있는 EBGP라우터에게만 전달한다는 것이다.

    라우터 A, B, C가 각각 EBGP Session 을 라우터E, F, G와 맺고, 라우터A는 라우터B, 라우터B는 라우터C와 IBGP Session을 맺지 않은 경우를 생각해보자. 즉 라우터A와 라우터C 사이에는 직접 IBGP Session을 맺지 않은 것이다.


    만약 AS200에서 어떤 변화가 발생되면 라우터 E는 그 사실을 라우터A에게 전달할 것이다. 네트웍의 변화에 대한 정보를 얻은 라우터A는 IBGP Session을 맺은 라우터B에게 전달한다.

    앞에서도 말했듯이 라우터B는 정보가 같은 AS에 있는 라우터A로부터 왔으므로 그 정보를 IBGP Session을 맺은 라우터C에게 전달하지 않고 EBGP Session을 맺은 라우터F에게만 전달한다. 따라서 변화된 정보가 라우터C를 통해 AS400에까지 전달되지 않는다.

    그러므로 라우터A와 라우터C간에 IBGP Session을 맺어주어야 한다.

    AS내에서 EBGP 라우터간에는 Full Mesh 형태로 IBGP Session을 모두 맺어주어야 한다.

    Router-A# sh running-config
    !
    router bgp 100
      neighbor b-ip-address remote-as 100
      neighbor c-ip-address remote-as 100
      neighbor e-ip-address remote-as 200

    Router-B# sh running-config
    !
    router bgp 100
      neighbor a-ip-address remote-as 100
      neighbor c-ip-address remote-as 100
      neighbor f-ip-address remote-as 300

    Router-C# sh running-config
    !
    router bgp 100
      neighbor a-ip-address remote-as 100
      neighbor b-ip-address remote-as 100
      neighbor g-ip-address remote-as 400
    /Loopback Interface

    라우터A, B, C 들은 서로 직접 연결되어 있으며, 모두 Full Mesh 형태로 IBGP Session을 다음과 같이 맺었다고 가정하자.

    Router-A# sh running-config
    !
    router bgp 100
    neighbor 130.100.2.2 remote-as 100
    neighbor 130.100.1.2 remote-as 100

    Router-B# sh running-config
    !
    router bgp 100
    neighbor 130.100.2.1 remote-as 100
    neighbor 130.100.3.2 remote-as 100

    Router-C# sh running-config
    !
    router bgp 100
    neighbor 130.100.1.1 remote-as 100
    neighbor 130.100.3.1 remote-as 100
    위와 같은 상황에서 라우터A와 라우터C를 직접 연결하는 회선에 장애가 발생하였을 경우 라우터A와 라우터C간의 IBGP Session은 사라지게 된다. 이유는 라우터A에서 Neighbor를 130.100.1.2 즉 회선에 할당된 IP Address를 이용해 지정하였고 회선에 장애가 발생함에 따라 130.100.1.2에 도달할 수 없어 IBGP Session을 맺을 수 없기 때문이다.

    그러나 IBGP Session은 직접 연결되어 있지 않더라고 맺을 수 있기 때문에 라우터A에서 라우터C와 IBGP Session을 위해 Neighbor를 130.100.4.1을 선언하였더라면 라우터A와 라우터C간의 회선이 끊어졌더라도 IBGP Session을 맺을 수 있었을 것이다. 라우터A는 라우터B를 경유하여 130.100.4.1을 접속할 수 있기 때문이다.

    Loopback Interface는 물리적인 Interface가 아니라 가상의 Interface로서 위에서처럼 물리적인 Interface에 장애가 발생함에 따라 그것에 할당된 IP Address등을 이용할수 없게 되는 상황을 방지해 줄 수 있는 것이다. Loopback Interface를 선언하는 방법은 다음과 같다.
    Router(config)# interface loopback number
    Router(config-if)#
    ip address ip-address netmask

    number는 0에서 2147483648까지 가능하다.

    따라서 Loopback Interface를 활용한 IBGP Session은 다음과 같이 설정할 수 있다.

    Router-A# sh running-config
    !
    interface loopback 0
    ip address 130.100.5.1 255.255.255.0
    !
    router bgp 100
    neighbor 130.100.6.1 remote-as 100
    neighbor 130.100.6.1 update-source loopback 0
    neighbor 130.100.7.1 remote-as 100
    neighbor 130.100.7.1 update-source loopback 0

    Router-B# sh running-config
    !
    interface loopback 0
    ip address 130.100.6.1 255.255.255.0
    !
    router bgp 100
    neighbor 130.100.5.1 remote-as 100
    neighbor 130.100.5.1 update-source loopback 0
    neighbor 130.100.7.1 remote-as 100
    neighbor 130.100.7.1 update-source loopback 0

    Router-C# sh running-config
    !
    interface loopback 0
    ip address 130.100.7.1 255.255.255.0
    !
    router bgp 100
    neighbor 130.100.5.1 remote-as 100
    neighbor 130.100.5.1 update-source loopback 0
    neighbor 130.100.6.1 remote-as 100
    neighbor 130.100.6.1 update-source loopback 0


    Loopback Interface를 이용해 IBGP Session을 맺은 경우 반드시 update-source를 함께 선언해주어야 한다. 라우터A에서 update-source를 선언함으로써 라우터B와 라우터C에게 IBGP Session을 위한 Neighbor는 130.100.5.1이라고 알려주게 된다.
    나. EBGP
    EBGP를 설정하는 방법은1.4 BGP 설정방법은?에서 다루었기 때문에 여기에서는 EBGP 설정과 관련된  Multihop, Synchronization에 대해서 알아보도록 하겠다.
    /Multihop
    IBGP 라우터들은 직접 연결되어 있지 않아도 IBGP Session을 맺을 수 있다. EBGP 라우터들은 대개 전용회선과 같은 것으로 직접 연결되어 EBPG Session을 맺는데 어떠한 이유에서 EBGP 라우터들이 직접 연결될 수 없거나 Serial Link에 할당된 IP Address로 neighbor를 지정할 수 없는 상황이 발생할 수 있다.

    가장 좋은 예가 Loopback Interface에 할당된 IP Address로 neighbor를 선언하는 경우이다.

    이런 경우 neighbor의 IP Address를 선언해 주고 neighbor ebgp-multihop이라는 명령어를 함께 선언해 주어야 한다. 위와 같은 상황에서는 neighbor의 IP Address는 Loopback Interface에 할당된 IP Address를 이용하면 된다.

    Router-A# sh run
    loopback interface 0
    ip address 130.100.1.1 255.255.255.0
    !
    router bgp 100
    neighbor 130.200.1.1 remote-as 200
    neighbor 130.200.1.1 ebgp-multihop
    neighbor 130.200.1.1 update-source loopback 0

    Router-B# sh run
    loopback interface 0
    ip address 130.200.1.1 255.255.255.0
    !
    router bgp 200
    neighbor 130.100.1.1 remote-as 100
    neighbor 130.100.1.1 ebgp-multihop
    neighbor 130.100.1.1 update-source loopback 0

    이때 주의하여야 할 것은 IBGP에서와 마찬가지로 EBGP 라우터가 loopback interface의 IP Address에 대한 경로를 알고 있어야 한다는 점이다. AS200에 있는 EBGP 라우터가 130.200.0.0에 대한 정보를 AS100의 EBGP 라우터에게 전달할 경우는 별도로 130.200.0.0에 대한 정보를 AS100에 등록해 줄 필요는 없다.

    그러나 130.200.0.0에 대한 정보를 AS100의 EBGP 라우터에게 전달하지 않을 경우, 운영자는 라우터A에 130.200.0.0에 대한 Static Route 등을 등록하여 주어야 한다.

    라우터B측에서도 마찬가지다.

    Router-A# sh run
    loopback interface 0
    ip address 130.100.1.1 255.255.255.0
    !
    router bgp 100
    neighbor 130.200.1.1 remote-as 200
    neighbor 130.200.1.1 ebgp-multihop
    neighbor 130.200.1.1 update-source loopback 0
    !
    ip address 130.200.0.0 255.255.0.0 130.150.1.2
    Router-B# sh run
    loopback interface 0
    ip address 130.200.1.1 255.255.255.0
    !
    router bgp 200
    neighbor 130.100.1.1 remote-as 100
    neighbor 130.100.1.1 ebgp-multihop
    neighbor 130.100.1.1 update-source loopback 0
    !
    ip address 130.100.0.0 255.255.0.0 130.150.1.1

    /Synchronization
    다음의 네트웍 상황을 살펴보자. 라우터B만이 BGP라우터가 아니고 나머지는 모두 BGP 라우터이다. AS100은 AS200과 AS300을 중계하고 있다.

    라우터A가 라우터D로부터 130.20.0.0에 대한 정보를 전달 받으면 이것을 IBGP Neighbor인 라우터C에게 전달하며, 라우터C는 이 정보를 라우터E에게 전달할 것이다. AS300에 있는 라우터는 130.20.0.0으로 가려는 트래픽을 라우터C에게 전달할 것이다. 그리고 라우터C는 해당 트래픽을 라우터B에게 전달할 것이다. 그런데 아직 라우터B가 라우터A로부터 130.20.0.0에 대한 정보를 받지 못했다고 생각해보자. 그러면 당연히 라우터B는 해당 트래픽을 폐기해 버릴 것이다.

    BGP에서 다른 두 개 이상의 AS를 연결하는 역할을 하는 AS가 있을 경우 이 AS에 있는 BGP 라우터들은 목적지에 대한 경로를 IGP로부터 모두 얻을때까지는 해당 경로를 다른 BGP 라우터에게 알려주지 않는 것을 Synchronization이라고 한다.

    따라서 위와 같은 상황에서 Synchronization이 활성화되어 있다면 라우터C는 라우터A로부터 받은 목적지에 대한 경로정보를 라우터B로부터 모두 전달받을때까지 기다렸다가 이후 라우터E에게 전달한다. 따라서 라우터B에서 트래픽이 폐기되는 것을 방지할 수 있게 된다.

    그러나 이러한 Synchronization은 Routing Information의 전달을 지연시키는 요소중의 하나인데 이러한 Synchronization은 다음과 같은 상황에서는 필요하지 않을 수 있다.

    - 자신의 AS가 다른 AS간의 트래픽을 중계하지 않을 때
    - 다른 AS간의 트래픽을 중계하는 라우터들이 모두 IBGP를 운영할때

    CISCO 라우터의 BGP에서는 기본적으로 Synchronization이 활성화되어 있는데 Synchronization을 비활성화하는 방법은 다음과 같다.

    Router(config)# router bgp local-asn
    Router(config-router)#
    no synchronization
    다. Network Advertisement
    RIP, IGRP, OSPF, EIGRP과 같은 IGP를 운영하고 있는 라우터는 맨처음에 Network Address 및 그것에 대한 경로정보를 전달할때 자신에게 직접 접속된 Network Address만을 전달한다. 방법은 이미 익혔듯이 network 명령어를 이용하여 자신에게 접속된 Network Address를 선언하면 된다.
    Router# sh running -config
    !
    router rip
    network 130.100.0.0
    network 130.110.0.0


    BGP 라우터는 조금 다르다.

    BGP 라우터는 자신이 소속된 AS에 있는 모든 Network Address를 BGP Routing Table에 등록하여 다른 AS의 BGP 라우터에게 전달한다. 즉 BGP 라우터에 직접 접속된 Network Address가 아니더라도 자신의 AS에 속한 Network Address를 전달하는 것이다.

    BGP 라우터가 외부로 전달할 Network Address를 BGP Routing Table에 등록하는 방법은 여러가지가 있으며 이제부터 그것을 알아보도록 하겠다. 이 과정을 거치지 않으면 BGP Session을 맺었더라도 전달하는 Network Address 및 경로에 대한 정보를 전달하지 않는다.

    Network Address를 BGP Routing Table에 등록하는 방법은 Network 명령어를 이용하는 방법, 재분배에 의한 방법이 있는데 필자뿐만 아니라 다른 문서들에서도 Network 명령어만을 이용하도록 권하고 있다.
    /Network 명령어 이용


    위와 같은 상황에서 라우터A와 라우터B는 다음과 같이 BGP Session을 맺을 것이다.

    Router-A#sh run
    router bgp 100
    neighbor 130.100.1.6 remote-as 200
    Router-B#sh run
    router bgp 100
    neighbor 130.100.1.6 remote-as 200
    그리고 라우터A와 라우터B는 자신의 AS에 속한 Network Address들을 다음과 같이 모두 선언해 준다.
    Router-A#sh run
    router bgp 100
    neighbor 130.3%0.0.2 remote-as 200
    network 130.100.0.0
    network 130.3%0.0.0

    Router-B#sh run
    router bgp 100
    neighbor 130.3%0.0.1 remote-as 100
    network 130.130.0.0
    network 130.131.0.0
    위와 같이 BGP 라우터를 설정한 경우 라우터 A와 라우터B에서 BGP 정보를 확인해 보자. BGP 정보를 확인하는 방법은 show ip bgp 라는 명령어를 이용하면 된다.
    Router> show ip bgp
    BGP 라우터에서 show ip bgp 라는 명령어를 입력하면 BGP에 의해 전달받은 Network Address 및 그것에 대한 경로정보를 보여준다. show ip bgp 명령어가 보여주는 정보는 여러가지인데 이것들에 대해서는 <a>여기</a>에서 자세히 다루도록 하겠다. 여기에서는 Network, Next Hop, Path, Origin에 대해서만 우선 알아보도록 하겠다.

    라우터A에서 show ip bgp 명령어를 입력하였을 경우 결과는 다음과 같다.

    Router-A> show ip bgp
    table version is 4, local router ID is 130.3%0.0.1
    status code : s suppressed, d damped, h history, * valid, > best, i - internal
    origin code : i - IGP, e - EGP, ? - incomplete
    Network             Next Hop          Metric  LocPrf   Weight    Path

    *> 130.100.0.0

    0.0.0.0

    0

    100

    0


    I

    *> 130.3%0.0.0







    *> 130.130.0.0

    130.3%0.0.2

    0

    100

    0

    200

    i

    *> 130.131.0.0

    130.3%0.0.2

    0

    100

    0

    200

    i

    network 명령어를 이용하여 BGP Neighbor에게 전달할 Network Address를 전달하는 방법의 가정 큰 장점은 어떤 Network Address를 전달하는지 쉽게 알 수 있다는 점이다.

    Posted by theYoungman
    engineering/Network Eng.2006. 8. 11. 14:36
    출처 블로그 > 슈마의 네트워크 이야기
    원본 http://blog.naver.com/airbag1/80015586114
    PIX Firewall Configuration교육센터
    2003.05.09


    LINE-HEIGHT: 11pt;}.bott { font-family:"돋움"; font-size:11px; line-height:13px}

    이 글은 네트웍 엔지니어가 PIX 방화벽을 보다 쉽게 설치하기 위해 작성한 안내서이
    다. 일반적으로 회사(기관)에서 방화벽을 구매하는 이유는 네트웍 보안 요구사항을 충
    족하기 위해서 이다. 따라서 이 글은 네트웍 보안 요구사항을 PIX 방화벽을 통해서 어
    떻게 구현할 것인가를 설명하도록 한다.

    네트웍 보안을 위한 첫번째 단계 : 보안 정책 Security Policy 수립

    네트웍에서 PIX 방화벽을 효과적으로 이용하려면, 우선 PIX 방화벽을 통해서 어떤
    traffic이 허용하고 막을지를 결정하는 보안 정책 Security Policy을 세워야 한다. 보
    안 정책이란 보다 구체적으로 회사 내부의 네트웍 자원을 누구에게 허용하고, 어떤 네
    트웍 자원을 허용할 지를 결정하게 된다. 네트웍 보안 정책에 관한 자세한 안내는 아
    래의 자료를 참고하기 바란다.

    http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_v4/pixcfg/pixcnint
    .htm#xtocid254855

    네트웍 구조와 PIX 방화벽

    Private Internet Exchange (PIX) 방화벽이 올바르게 설치되었다면, 외부의 네트웍에
    서 내부의 네트웍으로 허용되지 않는 접속을 차단하게 된다. PIX 방화벽을 통해서 보
    호하게 되는 네트웍을 내부 네트웍inside network이라고 하고 접속이 통제 받는 네트
    웍을 외부 네트웍 outside network이라고 한다. PIX 방화벽은 다양한 주변 네트웍을
    형성할 수 있는데, 대표적인 것이 Demilitarized Zone (DMZ)이다. 따라서 PIX 방화벽
    의 기능은 DMZ, 내부 네트웍, 외부 네트웍간의 모든 네트웍 접속을 통제하는 역할을
    수행하게 된다.

    그림 1은 PIX 방화벽이 인터넷에서 들어오는 트래픽으로부터 내부의 네트웍을 어떻게
    보호하는 지를 보여준다.

    그림 1. 네트웍에서 PIX 방화벽


    이런 구조에서 PIX 방화벽은 내부 네트웍과 외부 네트웍(DMZ 을 포함해서)의 경계에
    위치하게 된다. 내부 네트웍과 외부 네트웍간의 모든 트래픽은 보안 기능을 수행하기
    위해서 반드시 PIX 방화벽을 거치게 된다. 외부 네트웍은 일반적으로 인터넷을 통해
    서비스를 제공하는 시스템들이 위치한다. 이러한 서비스들을 제공하는 것은 웹 서버,
    FTP 서버, 메일 서버등이 있다. 이러한 응용프로그램 서버들로의 접근은 인터넷 접속
    Router에서 Access List를 사용하여 접근을 컨트롤할 수 있다.
    다른 방법으로, 그림 1에 나타낸 것과 같이 여러 서버들을 DMZ에 위치하도록 할 수 있
    다. 그러면 PIX 방화벽은 이런 서버들로 접근을 계속 모니터링하고 조절할 수 있다.
    또한 PIX 방화벽은 회사의 보안 정책에 따라 내부 네트웍으로의 모든 트래픽을 조절
    할 수 있다.

    일반적으로 내부 네트웍은 회사의 고유한 내부 네트웍, 즉 인트라넷, 이며 외부 네트
    웍은 인터넷이 된다. 또한 PIX 방화벽은 이러한 회사 내부의 자원을 분리해서 다른 사
    용자들로부터 특정 그룹의 컴퓨터 시스템을 보호할 수 있다. DMZ을 만듦으로서 보다
    다양한 보안 수준을 갖는 영역을 형성할 수 있게 된다. PIX의 각 interface들은
    Routing Information Protocol(RIP) routing update를 받아들이고 RIP default route
    정보를 브로드케스트할 수 있다.

    이 문서의 구조

    이 문서는 당사에서 구축한 PIX 방화벽의 예를 보여준다. 각 PIX 방화벽의
    configuration은 다음과 같은 포맷을 구성되어 있다.

    - 네트웍 보안 요구 사항
    - 특정 네트웍의 운영 예제와 필요 사항
    - 네트웍 구성도
    - 네트웍 요구사항에 따른 configuration. 특정 요구사항과 관련된 부분은 굵은체로
    나타내었다.
    - 요구 사항을 적용하기 위한 명령어에 대한 논의

    아래는 일반적으로 구현되는 PIX 방화벽의 예이다. 특정 사례에 대해서 살펴보기 전
    에 PIX 방화벽의 일반적인 기능 구현에 대해 살펴보도록 하자.


    Basic PIX Firewall Configuration

    네트웍 보안 요구 사항


    - 내부의 네트웍 단말들은 DMZ과 인터넷(외부 네트웍)을 사용할수 있어야 한다.
    - DMZ의 단말은 인터넷을 사용할 수 있지만, 내부 네트웍으로 접근은 금지한다.
    - DMZ안에 있는 호스트 A(192.150.50.9, 사설 IP address는 192.168.0.2)은 World
    Wide Web 서비스를 제공한다.
    - 내부 네트웍의 호스트B (192.150.50.7, 사설 IP address는 10.0.0.99)은 인터넷 메
    일 서비스를 제공한다.

    그림 2. 네트웍 구성도 – 기본 설정


    Configuration Code Snapshot

    pixfirewall(config)# write terminal
    Building configuration...
    : Saved
    :
    PIX Version 4.2(0)205 Beta
    nameif ethernet0 outside security0
    nameif ethernet1 inside security100
    nameif ethernet2 dmz security50
    enable password 8Ry2YjIyt7RRXU24 encrypted
    passwd 2KFQnbNIdI.2KYOU encrypted
    hostname pixfirewall

    fixup protocol ftp 21
    fixup protocol http 80
    fixup protocol h323 1720
    fixup protocol rsh 514
    fixup protocol smtp 25
    fixup protocol sqlnet 1521
    no failover
    failover ip address outside 0.0.0.0
    failover ip address inside 0.0.0.0
    names
    pager lines 24
    syslog output 20.7

    no syslog console
    syslog host inside 10.0.0.100
    interface ethernet0 auto

    interface ethernet1 auto
    interface ethernet2 auto
    ip address outside 192.150.50.3 255.255.255.0
    ip address inside 10.0.0.3 255.0.0.0
    ip address dmz 192.168.0.1 255.255.255.0
    arp timeout 14400
    global (outside) 1 192.150.50.10-192.150.50.252 netmask 255.255.255.0
    nat (inside) 1 10.0.0.0 255.0.0.0 0 0
    nat (dmz) 1 192.168.0.0 255.255.255.0 0 0

    static (dmz,outside) 192.150.50.9 192.168.0.2 netmask 255.255.255.255 0 0
    static (inside,outside) 192.150.50.7 10.0.0.99 netmask 255.255.255.255 10 40
    static (inside,dmz) 10.0.0.0 10.0.0.0 netmask 255.0.0.0 0 0
    conduit permit tcp host 192.150.50.9 eq www any
    conduit permit tcp host 192.150.50.7 eq smtp any
    conduit permit icmp host 192.150.50.7 any
    age 10
    no rip outside passive
    no rip outside default
    no rip inside passive
    no rip inside default
    no rip dmz passive
    no rip dmz default
    route outside 0.0.0.0 0.0.0.0 192.150.50.1 1
    timeout xlate 24:00:00 conn 12:00:00 udp 0:02:00
    timeout rpc 0:10:00 h323 0:05:00 uauth 0:05:00
    snmp-server host outside 0.0.0.0
    no snmp-server location
    no snmp-server contact
    snmp-server community public
    snmp-server syslog disable
    snmp-server log_level 5
    mtu outside 1500
    mtu inside 1500
    mtu dmz 1500
    Cryptochecksum:921ac2a721ef50f3109ebe7ee03fb2cb
    : end
    [OK]
    pixfirewall(config)#

    요구사항 구현

    nameif ethernet0 outside security0

    첫번째 이더넷 카드 (전원으로부터 첫번째 이더넷 카드)는 외부 영역이라고 명명한
    다. 이 interface에 접속되어 있는 네트웍은 외부에 해커에 노출된 곳이다. 따라서 보
    안 레벨을 0으로 설정한다.

    nameif ethernet1 inside security100
    두번째 이더넷 카드 (전원으로부터 두번째 이더넷 카드)는 내부 영역이라고 명명한
    다. 이 interface에 접속되어 있는 네트웍은 보다 안전한 곳이다. 따라서 보안 레벨
    을 100으로 설정한다.

    nameif ethernet2 dmz security50
    세번째 이더넷 카드 (전원으로부터 세번째 이더넷 카드)는 DMZ 영역이라고 명명한다.
    이 interface에 접속되어 있는 네트웍은 외부 네트웍보다는 안전하지만 내부 네트웍보
    다는 덜 안전한다. 따라서 보안 레벨을 50으로 설정한다.

    enable password 8Ry2YjIyt7RRXU24 encrypted
    Enable password를 설정한다.

    passwd 2KFQnbNIdI.2KYOU encrypted
    Telnet password을 설정한다.

    hostname pixfirewall
    PIX 방화벽의 이름을 "pixfirewall"로 설정한다.

    fixup protocol smtp 25
    PIX 방화벽은 여러 가지 위험 요소들을 막는다.(SMTP 명령어. fixup 명령어는 내부 네
    트웍으로 들어오는 패킷중에 목적지 소스 포트가 25일 경우 SMTP security를 수행한
    다. 이것은 default 로 설정되어있다.

    no failover
    Failover기능을 사용하지 않는다.

    names
    IP address와 영문자 이름을 일치시킨다. IP host와 같은 기능을 수행하는 명령어이
    다.

    pager lines 24
    이 명령어는 Console이나 Telnet에서 디스플레이되는 라인의 길이를 설정하는 명령어
    이다.

    syslog output 20.7
    모든 메시지를 syslog server로 보내도록 한다. 이 메시지를 PIX에서 발생하는 환경
    정보, 에러 메서지, 경고, 디버그 메시지등을 담고 있다.

    syslog host inside 10.0.0.100
    syslog server의 IP address를 10.0.0.100으로 설정. 이 서버는 내부 네트웍에 위치한
    다.

    interface ethernet0 auto
    첫번째 네트웍 interface의 속도와 duplex mode를 자동으로 인식하고 설정한다.

    ip address outside 192.150.50.3 255.255.255.0
    PIX 방화벽의 외부 interface의 ip address를 192.150.50.3 (class C)로 설정한다.

    arp timeout 14400
    캐시로 저장된 arp 항목을 14400초 동안 유지한다.

    global (outside) 1 192.150.50.10-192.150.50.252 netmask 255.255.255.0
    Global pool을 생성하고 global pool의 값을 1로 할당한다. 위의 경우, 글로벌 풀은
    243개의 IP address를 갖는다. 이 address는 Network Address Translations에 의해서
    할당된 것이다.

    nat (inside) 1 10.0.0.0 255.0.0.0 0 0
    nat (inside) 명령어는 내부 네트웍의 클라이언트와 DMZ과 인터넷 영역의 서버간의
    IP 통신을 가능하게 한다. 내부 네트웍의 호스트에서 인터넷의 호스트와 통신하기 위
    해서 내보낸 패킷이 PIX를 통과하게 되는데, 패킷의 Source Address의 IP address부분
    이 10으로 설정되어 있으면 이것을 Global pool 값 1에 있는 IP address로 바꾸도록
    설정하는 것이다.

    nat (dmz) 1 192.168.0.0 255.255.255.0 0 0
    nat (inside) 명령어는 DMZ 네트웍의 단말과 인터넷 영역의 서버간의 IP 통신을 가능
    하게 한다. DMZ 네트웍의 호스트가 인터넷의 호스트와 통신하기 위해서 내보낸 패킷
    이 PIX를 경유하게 되는데, 이때 패킷의 Source Address의 IP address부분이
    192.168.0으로 설정되어 있으면 이것을 Global pool 1에 있는 IP address로 바꾸도록
    설정하는 것이다.

    static (dmz,outside) 192.150.50.9 192.168.0.2 netmask 255.255.255.255 0 0
    DMZ 네트웍의 호스트(192.168.0.2)가 인터넷의 호스트와 통신을 하고자 할때, DMZ의
    네트웍 호스트에서 인터넷으로 나가는 패킷의 Source Address를 192.150.50.9로 바꾸
    도록 한다. 이 address는 공인 어드레스이다. 이것은 역의 경우에도 동일하게 적용된
    다. 즉 외부 인터넷의 호스트가 통신을 시도할 때에도 역시 192.150.50.9를
    192.168.0.2로 바꾸게 된다. 따라서 IP address 192.150.50.9는 다른 호스트에서 사용
    하지 못한다.

    static (inside,dmz) 10.0.0.0 10.0.0.0 netmask 255.0.0.0 0 0
    이것은 내부 네트웍의 패킷이 DMZ 네트웍으로 전송되도록 하는 netstatic 명령어이다.

    conduit permit tcp host 192.150.50.9 eq www any
    이것은 DMZ 네트웍의 192.168.0.2 서버에 HTTP 프로토콜을 쓰는 패킷만 접근을 허용하
    는 명령이다. (주의할 점은 이 명령이 정상적으로 작동하려면 static (dmz,outside)
    192.150.50.9 192.168.0.2 netmask 255.255.255.255 0 0 명령과 같이 사용해야만 한
    다.)

    conduit permit tcp host 192.150.50.7 eq smtp any
    외부 네트웍에서 내부 네트웍의 메일 서버(10.0.0.99)로 SMTP (mail)패킷 전송을 받아
    들인다.

    route outside 0.0.0.0 0.0.0.0 192.150.50.1 1
    이 네트웍의 default 경로는 192.150.50.1로 설정한다. (이 address는 Internet
    router의 IP address이다.)


    출처 www.networktraining.co.kr

    Posted by theYoungman
    engineering/Network Eng.2006. 8. 11. 14:20

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

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

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


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


    제로님께서 요청하셨던 '어떻게 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 되고 말 것입니다.


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

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


    출처:빅보스님



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

    Posted by theYoungman
    engineering/Network Eng.2006. 8. 11. 14:04

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

    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)

    Posted by theYoungman
    engineering/Network Eng.2006. 8. 11. 14:01

    라우팅과 라우팅 프로토콜에는 몇 가지의 문제가 있다. 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

    Posted by theYoungman
    engineering/Network Eng.2006. 8. 11. 13:53

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

    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

    Posted by theYoungman