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 )
'분류 전체보기'에 해당되는 글 150건
- 2006.08.29 Cisco Configuration Register
- 2006.08.11 CMTS 관련 운영 언어 및 예제
- 2006.08.11 syslog 를 이용한 원격로그지원
- 2006.08.11 IEEE 802.x 정리
- 2006.08.11 BGP (Border Gateway Protocol)
- 2006.08.11 Pix Firewall Configuration
- 2006.08.11 null0 interface 의 사용
- 2006.08.11 라우팅 프로토콜과 라우티드 프로토콜
- 2006.08.11 라우팅 프로토콜 보안
- 2006.08.11 속도와 밴드위스의 개념
◎ 모뎀상태를 확인할 수 있는 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 별도 관리 가입자임)
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 서버 입니다
[ 802.1 LAN/MAN architecture, Security, MAC & LLC layers ]
http://grouper.ieee.org/groups/802/1/
Active Project
Archived Projects
[ 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 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. 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/ [ 802.4 TOKEN BUS ] http://grouper.ieee.org/groups/802/4/ [ 802.5 Web Site ] http://grouper.ieee.org/groups/802/5/ This is a set of standalone documents that support the committee's work. It includes: 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). 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. 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 scope: Correct errors in 802.5 and its amendments. Scope: Specify extensions to 802.1Q to enhance support for the source route bridging method. Scope: Unification of the token ring standards and supplements with clarification and corrections. 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. 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. [ 802.6 METROPOLITAN NETWORKS ] http://grouper.ieee.org/groups/802/6/ [ 802.7 Broadband TAG ] http://grouper.ieee.org/groups/802/7/ [ 802.8 FIBER OPTIC TAG ] http://grouper.ieee.org/groups/802/8/ [ 802.9 ISOCHRONOUS LANS ] http://grouper.ieee.org/groups/802/9/ [ 802.10 Standards for Interoperable LAN/MAN Security (SILS) ] http://grouper.ieee.org/groups/802/10/ [ 802.11 WIRELESS LOCAL AREA NETWORKS ] 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.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/ [ 802.15 Working Group for Wireless Personal Area Networks ] http://grouper.ieee.org/groups/802/15/ 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. [ 802.17 Resilient Packet Ring Working Group ] http://grouper.ieee.org/groups/802/17/ 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 Completed Projects Working Group Contact Information [ 802.18 LAN/MAN Standards Committee 802.18 - the Radio Regulatory TAG ] http://grouper.ieee.org/groups/802/18/ 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. 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/ [ 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. 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. 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: 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. Working Group Documents Current work items are based on the PAR: 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. [ 802.22 LAN/MAN Standards Committee 802.22 WG on WRANs (Wireless Regional Area Networks) ] http://grouper.ieee.org/groups/802/22/ 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: 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 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" 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.CONTACT INFORMATION
CONTACT INFORMATION
IEEE Standards Staff Liaison for IEEE 802: Denise Pribula.
IEEE 802.4 Hibernating Working Group Chair: Paul Eastman.
Working Group Standalone Documents
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 802.5c-1991 (R1997) Supplement to IEEE Std 802.5-1989
Recommended Practice for Dual Ring Operation with Wrapback Reconfiguration (ANSI) 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) 802.5:1998 / Amendment 1.:1998 Dedicated Token Ring Operation and Fibre Optic Media
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
P802.5v Gigabit Token Ring
P802.5w Errata to 802.5:1998 and Amd.1:1998
P802.5x Supplement to 802.1Q: Virtual Bridged LANs: Source Routing
P802.5rev Token Ring standard revision
P802.5z Aggregation of Multiple Link Segments
P802.5?? Enhanced Source Routing
CONTACT INFORMATION
IEEE Standards Staff Liaison for IEEE 802: Denise Pribula.
IEEE 802.6 Hibernating Working Group Chair: Jim Mollenauer.
CONTACT INFORMATION
IEEE Standards Staff Liaison for IEEE 802: Denise Pribula.
CONTACT INFORMATION
IEEE Standards Staff Liaison for IEEE 802: Denise Pribula.
IEEE 802.8 Working Group Chair: Chip Benson.
IEEE Standards Staff Liaison for IEEE 802: Denise Pribula.
IEEE 802.9 Working Group Chair: Dhadesugoor Vaman.
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
MEMBERS ONLY INFORMATION
CONTACT INFORMATION
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
CONTACT INFORMATION
IEEE Standards Staff Liaison for IEEE 802: Denise Pribula.
IEEE 802.12 Working Group Chair: Pat Thaler.
ABOUT
-Vint Cerf, TCP/IP co-developer and Internet pioneer, in Fast Company, April 2000.
Working Group Description
Chair: Mike Takefman Vice Chair: John Lemon Secretary: Volunteer Needed Webmaster: John Lemon IEEE Standards Staff Liaison for IEEE 802: Sue Vogel
Introduction
Hot Items
IEEE 802.19 TAG GENERAL INFORMATION
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.
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 IEEE 802.19 TAG ARCHIVED INFORMATION
IEEE 802.19 TAG CONTACT INFORMATION
RELATED LINKS
Introduction
(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.
|
블로그 > 슈마의 네트워크 이야기 http://blog.naver.com/airbag1/80015586114 | ||||||
|
아래글은 세노님이 쓰신 글입니다. 세노(박병석)님이 예전에 쓰신 글을 퍼옵니다..^^
이글에 대한 저작권은 세노님한테 있습니다. ^^;
저는 첨에 이글을 보고.. 이야~! 참 기똥차다~! 라는 말이 저절로 나오더군요...ㅎㅎ
--------------------------------------------------------------------------
제로님께서 요청하셨던 '어떻게 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 |