소켓 생성 시 어떤 책은 PF_INET를 쓰고, 어떤 책은 AF_INET 를 사용합니다.

PF_INET는 프로토콜 체계(프로토콜 패밀리)중 하나이고,

AF_INET는 주소 체계(주소 패밀리)중 하나입니다.

 

프로토콜 패밀리는 아래와 같은 종류가 있습니다.

 프로토콜 체계(Protocol Family)  정의
 PF_INET IPv4인터넷 프로토콜
 PF_INET6 IPv6인터넷 프로토콜
 PF_LOCAL LOCAL 통신을 위한 UNIX 프로토콜
 PF_PACKET Low level socket을 위한 인터페이스
 PF_IPX IPX 노벨 프로토콜
 

소켓을 만들 때는 소켓이 사용될 환경을 고려해 프로토콜을 설정해 주어야 합니다.

다시 말해 프로토콜 패밀리는 소켓을 생성할 때 이 소켓이 어떤 프로토콜을 사용해 통신을 할지 정해줍니다.

참고로 소켓은 네트워크 통신을 할때만 사용되는 것은 아닙니다.

유닉스 계열의 시스템에서 시스템 내부의 프로세스들끼리 통신을 하기 위해서도 사용됩니다.

자주 사용되는 PF_INET는 프로토콜 패밀리중 하나입니다.

 

AF_INET는 주소 패밀리중 하나입니다.  종류는 아래와 같습니다.

 주소체계(Address Family) 정의
 AF_INET  IPv4인터넷 프로토콜
 AF_INET6  IPv6인터넷 프로토콜
 AF_LOCAL  LOCAL 통신을 위한 UNIX 프로토콜

 

이 들은 주소 구조체 안에 주소 패밀리를 정의할 때 사용합니다.

 

프로토콜 체계를 나타내는 PF_INET와 주소체계를 나타내는 AF_INET 는 같은 상수 값을 가지고 있습니다.

그렇다고 해서 주소정보를 설정하는 부분에 PF_INET를 사용하고 프로토콜 패밀리 정보를 설정하는 부분에 AF_INET를 넣는 것은 좋지 않습니다.

 

결과적으로, 프로토콜 체계를 설정하는 부분은 PF로 시작하는 상수를 사용하고, 주소 체계를 설정하는 부분은 AF로 시작하는 상수를  사용하는 것이 좋습니다.

 

실제 코딩 부분에서 socket()함수에 프로토콜 패밀리에 AF_INET를 넣어도 되지만 PF_INET를 넣는게 바람직하고

struct sockaddr_in 구조체에 주소 체계를 넣을 때에도 PF_INET 를 넣어도 되지만 AF_INET를 넣는게 바람직하다.

출처 : http://blog.naver.com/l18400?Redirect=Log&logNo=60109296392

BOOTP 및 DHCP

BOOTP(Bootstrap Protocol)는 DHCP보다 먼저 개발된 호스트 구성 프로토콜입니다. DHCP는 BOOTP를 향상시키고 BOOTP가 호스트 구성 서비스로서 가지는 제한을 해결합니다. RFC 951에 BOOTP가 정의되어 있습니다.

BOOTP/DHCP의 유사성

BOOTP와 DHCP의 관계로 인해 두 프로토콜 모두 일부 정의 특성을 공유합니다. 공통 요소는 다음과 같습니다.

 

서버와 클라이언트 간에 메시지를 교환하기 위해 사용하는 형식 구조

BOOTP와 DHCP는 거의 똑같은 요청 메시지(클라이언트에서 전송)와 응답 메시지(서버에서 전송)를 사용합니다. 이들 프로토콜에 있는 메시지는 576바이트의 단일 UDP(사용자 데이터그램 프로토콜) 데이터그램을 사용하여 각 프로토콜 메시지를 묶습니다. 메시지 머리글은 선택적인 데이터 전송에 사용되는 마지막 메시지 머리글 필드를 제외하면 BOOTP와 DHCP에서 동일합니다. BOOTP에서는 이 선택적 필드를 공급업체별 영역이라고 하고 64옥텟으로 제한됩니다. DHCP에서는 이 영역을 옵션 필드라고 하고 최대 312옥텟의 DHCP 옵션 정보를 운반할 수 있습니다.

 

클라이언트/서버 통신에 잘 알려진 UDP 포트 사용

BOOTP와 DHCP 모두 서버와 클라이언트 간에 메시지를 전송하고 수신할 때 예약된 같은 프로토콜 포트를 사용합니다. BOOTP 서버와 DHCP 서버 모두 67번 UDP 포트를 사용하여 클라이언트 요청 메시지를 수신하고 받습니다. BOOTP와 DHCP 클라이언트는 보통 BOOTP 서버나 DHCP 서버에서 메시지 응답을 받아들이기 위해 68번 UDP 포트를 예약합니다.

DHCP와 BOOTP 메시지는 거의 동일한 포맷 형식과 패킷 구조를 사용하고 대개 잘 알려진 같은 서비스 포트를 사용하므로 BOOTP 및 DHCP 릴레이 에이전트 프로그램은 일반적으로 BOOTP와 DHCP 메시지를 구분하지 않고 본질적으로 같은 메시지 형식으로 처리합니다.

 

구성 서비스의 필수 부분인 IP 주소 배포

BOOTP와 DHCP가 시작 중에 클라이언트에 IP 주소를 할당하지만 다른 할당 방법을 사용합니다. BOOTP는 보통 각 클라이언트에 단일 IP 주소를 고정 할당하여 이 주소를 BOOTP 서버 데이터베이스에 영구적으로 보존합니다. DHCP는 보통 사용 가능한 IP 주소를 동적으로 임대 할당하여 각 DHCP 클라이언트 주소를 DHCP 서버 데이터베이스에 일시적으로 보존합니다.

 

BOOTP/DHCP의 차이점

BOOTP와 DHCP에서 호스트를 구성하는 방법에는 상당한 차이가 있습니다. 다음 표에서는 서로 다른 두 프로토콜의 기능을 비교하고 대조합니다.

 

 BOOTP

 DHCP

 

  DHCP보다 먼저 만들어졌습니다.

 

  BOOTP보다 나중에 만들어졌습니다.

 

  제한된 부팅 기능이 있고 디스크가 없는 워크스테이션을 구성하기 위한 프로토콜입니다.

 

 

  로컬 하드 드라이브와 완전한 부팅 기능이 있으며 위치가 자주 바뀌는 네트워크 컴퓨터(예: 휴대용)를 구성하기 위한 프로토콜입니다.

 

 

  동적 BOOTP의 IP 주소 임대 만료일은 기본적으로 30일입니다.

 

  DHCP의 IP 주소 임대 만료일은 기본적으로 8일입니다.

 

  공급업체 확장이라고 하는 제한된 수의 클라이언트 구성 매개 변수를 지원합니다.

 

  옵션이라고 하는 크고 확장 가능한 클라이언트 구성 매개 변수 집합을 지원합니다.

 

  다음과 같이 2 단계 bootstrap 구성 프로세스를 설명합니다.

1. 클라이언트는 BOOTP 서버에 연결하여 주소를 결정하고 부팅 파일 이름을 선택합니다.

2. 클라이언트는 TFTP(Trivial File Transfer Protocol) 서버에 연결하여 부팅 이미지의 파일을 전송합니다.

 

 

  DHCP 클라이언트가 그 IP 주소를 결정하고 네트워크 작업에 필요한 모든 초기 구성 세부 사항을 얻기 위해 DHCP 서버와 협상하는 단일 단계 부팅 구성 프로세스를 설명합니다.

 

  BOOTP 클라이언트는 시스템이 다시 시작할  때를 제외하고는 BOOTP 서버로 구성을 다시 바인딩하거나 갱신하지 않습니다.

 

 

  DHCP 클라이언트는 DHCP 서버로 구성을 다시 바인딩하거나 갱신할 때 시스템을 다시 시작하지 않습니다. 대신 클라이언트는 DHCP 서버에 임대된 주소 할당을 갱신하기 위해 설정된 시간 간격마다 자동으로 리바인딩 상태가 됩니다. 이 프로세스는 백그라운드에서 이루어지므로 사용자가 인식할 수 없습니다.

 

 

출처 : http://www.microsoft.com/technet/prodtechnol/windowsserver2003/ko/library/ServerHelp/8e75e9f0-72e0-4b06-b6dd-abf88e652d3a.mspx?mfr=true

1. 먼저 snmp 패키지를 설치 한다.

# apt-get install snmp snmpd 


2. /etc/snmp/snmp.conf 에 설정 파일을 수정한다.

com2sec local  localhost  public
com2sec network  0.0.0.0/24  public

group rwgroup v1 local
group rwgroup v2c local
group rogroup v1 network
group rogroup v2c network

......


3. snmpd 데몬을 실행한다.

# /etc/init.d/snmpd start 


4. snmp 데몬이 정상 동작하는지 확인해 본다

# snmpwalk -v 2c -c public localhost system.sysDescr.0 


폴딩을 걸어 놓은 상태에서 다음에 파일을 열 때도 기존에 해 놨던 폴딩을 보고 싶으면,
명령행에 :mkview을 입력해서 폴딩 상태를 저장한다.

다시 읽어오고 싶으면, :loadview을 사용해서 폴딩정보를 로드하도록 한다.

출처 : http://shellbt.tistory.com/298872

vim의ㅣ 폴딩 기능이 유용할 것 같긴 한데..
저장하고 다시 열면 접었던 것들이 다 날아가서
실제로 사용하기가 힘들었죠.
오래 헤멘 끝에 마침내 영구적으로 폴딩 기능을
사용할 수 있는 방법을 알아냈습니다.

먼저 foldmarker에 대해 아셔야 합니다.
이름 그대로 폴딩을 위한 마커입니다.
"{{{", "}}}"을 접고자 하는 라인 위 아래에 넣어줍니다.
그냥 넣으면 안되니 라인 주석으로 "//" 감싸줍니다.

-------------
//{{{ function foobar(str1, str2)

/**
* foobar
*
*/
function foobar(str1, str2)
{
}

//}}}
//{{{ function barfoo(str)
------------

이런 식으로 넣고 :set fdm=marker 하면 자동으로
{{{, }}}로 감싼 부분이 폴딩됩니다.
외국 소스를 보다보면 위와 같은 코딩 관습이 종종
발견되는데 역시 다 이유가 있는 거였더군요. :)


이번엔 보너스팁입니다.
.vimrc 에 fdm=marker를 추가하셔도 되고,
소스 파일에 vim에서만 인식되는 다음 주석을
처음이나 끝에 추가하시면 됩니다.

-----------
/*
* vim60: ts=4 sw=4 fdm=marker
*/
-----------

출처 : http://kltp.kldp.net/stories.php?story=02/11/16/6893604

VOX

VOX는 Voice operated transmit (Voice Only Transmit) 음성만 전송한다는 의미이다.

이 글자'vox' 가 쓰여진것을 딱 한번 무전기에서 본적이있다.

역시 VOR과 비슷한 의미로 무전기와 연결된 헤드셋에 대고 말을 하면

자동으로 송신하는 기능이다.

 

이런기능은 외부잡음이 방해꾼이된다.

예를들어 농촌에 새 소리를 녹음할려고 VOR 녹음을 돌려놨는데

몇분마다 지나가는 비행기 때문에 녹음 메모리와 밧데리를 쓸데없이 소비하게 될수도 있다.

감지할 음량의 정도나 음색 대역폭 등을 구체적으로 설정할수 있다면

더 고급 VOR,VOX기능을 사용할수 있을텐데...

 

출처 : http://codebox.golgoroo.pe.kr/80012092134

ftp> ! [command]

잠시 셸로 빠져나간다.

셸을 종료하면 다시ftp로 돌아간다.

 

?, help

ftp> ? [command-name]

help 내용을 본다.

?만 입력하면 모든 명령어 목록이 출력되며명령어를 파라미터로 주면 해당 명령어의help 내용을 출력한다.

 

account

ftp> account [passwd]

remote 서버로account 정보를 보낸다.

 

append

ftp> append [local-file [remote-file]]

remote 서버에 파일이 존재할 경우 이어붙인다.

remote-file 명을 입력하지 않으면local-file 명으로 지정된다.

 

ascii

ftp> type ascii

전송 모드를ascii로 설정한다.

 

binary, image

ftp> type [binary/image]

전송 모드를binary로 설정한다.

 

bell

ftp> bell [on/off]

명령어 실행 완료 시 삐 소리 출력 여부 설정한다.

 

bye, quit

ftp 연결을 끊고 종료한다.

case

mget 명령 시의 원격 서버 파일명 대소문자 구분을 설정(on/off toggle, default: off)

(on이면) remote 서버의 파일들을mget으로 가져올 때대소문자 구분없이 모두 소문자로 가져온다.

 

 

cd

ftp> cd [remote-directory]

서버의 디렉토리를 변경

 

cdup

서버의 디렉토리를 한단계 전으로 변경(cd .. 와 동일)

 

chmod

ftp> chmod [mode remote-file]

파일의 권한을 변경

 

close, disconnect

ftp 연결을 끊는다.

ftp 연결만 끊으며ftp를 종료하지는 않는다정의한 매크로는 모두 삭제된다.

 

cr

텍스트 파일 전송시 엔터코드(Carriage Return) 유무를 조정. (on/off toogle, default: on)

 

delete

ftp> delete [remote-file]

remote 파일을 삭제한다.

빈 디렉토리도 삭제할 수 있다.

 

debug

디버깅 모드를 설정한다. (on/off toggle debug 레벨 설정)

 

dir, ls

ftp> dir [remote-directory] [local-file]]

디렉토리를 출력한다.

local 파일을 파라미터로 줄 경우, dir 명령의 결과를 파일로 저장할 수 있다.

 

form

파일 전송 포맷을 설정한다.

(non-print 포맷만 지원)

 

get, recv

ftp> get [remote-file [local-file]]

remote 파일을local 서버로 전송받는다.

local 파일명을 파라미터로 줄 경우전송받은 파일의 파일명을 지정할 수 있다.

 

glob

local 파일이름의 메타문자 확장을 설정한다. (on/off toggle, default: on)

 

hash

1024 바이트 전송 시마다'#' 기호를 출력한다.

hash 기능 사용 시 퍼포먼스 저하

 

idle

ftp> idle [seconds]

remote 서버 연결의 비활성화 시간을 설정/확인한다.

초 단위로 파라미터를 줄 경우비활성화 시간을 설정하며파라미터가 없는 경우 현재 설정 상태를 출력한다.

설정된 시간이 지나면ftp 접속이 끊어진다. (30~7200초 설정 가능)

 

lcd

ftp> lcd [local-directory]

local 디렉토리를 변경한다.

파라미터로 주어진 디렉토리로local 디렉토리를 변경하며파리미터가 없는 경우local home 디렉토리로 변경

 

macdef

ftp> macdef [macro-name]

매크로를 정의

명령어 실행 후 다음 라인부터의 내용이 매크로로 저장

빈 라인(내용없이 엔터 입력)이 입력되면 매크로 저장이 종료

최대4096개의 문자로 된16개의 매크로를 정의할 수 있으며정의된 매크로는close 명령어로 종료될 때까지 유지

 

$

ftp> $ [macro-name]

매크로를 실행한다.

 

macdef 명령어로 먼저 매크로를 정의해 놓은 후해당 매크로를 실행

반복적인 작업이나 일괄작업 등에 쓰임

 

mdelete

ftp> mdelete [remote-files]

다수의 파일을 삭제한다.

 

mdir

ftp> mdir [remote-files local-file]

다수의 디렉토리/파일의 출력 결과를local 파일로 저장한다.

 

mls

ftp> mls [remote-files local-file]

다수의 디렉토리/파일의 간단한 출력 결과를local 파일로 저장한다.

 

mget

ftp> mget [remote-files]

다수의remote 파일을 전송받는다.   

 

mkdir

ftp> mkdir [directory-name]

서버에 디렉토리를 생성한다.

  

mode

파일 전송 모드를 설정한다.

제공되는 모드는stream 뿐이다.

 

modtime

ftp> modtime [remote-file]

파일의 최종 수정시각을 출력한다.

 

mput

ftp> mput [local-files]

다수의local 파일을 서버로 전송한다.

 

newer

ftp> newer [remote-file [local-file]]

파일을get 하되, local 파일보다 나중인 경우에만 가져온다.

local 파일이 없는 경우 그냥get 한다.

 

nlist

ftp> nlist [remote-directory] [local-file]

디렉토리의 파일 목록을 출력한다.

디렉토리명을 지정할 수 있으며지정하지 않으면 현재 디렉토리가 출력된다.

 

open

ftp> open [server-host] [port-number]]

서버에 접속한다.

ftp 접속이 끊어졌을 경우ftp를 종료하지 않고open 명령어로 재접속 가능

 

prompt

multiple 명령어 실행 시 응답 여부를 설정한다. (on/off toggle, default: on)

off로 설정할 경우, multiple 명령어(mget, mput 실행시y/n 선택없이 강제로 진행된다. (모두y)

 

sendport

data 연결을 위해PORT 명령어 사용 여부를 설정한다. (on/off toggle, default: on)

off로 설정할 경우 명령어 실행에delay가 생길 수 있다.

 

passive

passive 모드 설정을 변경한다. (on/off toggle, default: off)

 

put, send

ftp> put [local-file] [remote-file]]

서버로local 파일을 전송한다.

파일명을 파라미터로 줄 경우, remote 서버로 전송되는 파일명을 지정할 수 있다.

 

pwd

서버의 현재 디렉토리를 출력한다.

 

reget

ftp> reget [file-name]

파일의 끝에 이어서get 한다.

파일을get 하던 중 중지된 경우처음부터 다시 받지 않고reget 명령어를 이용해 이어받을 수 있다.

 

rstatus

ftp> rstatus [file-name]

서버의 상태를 출력한다.

 

rhelp

ftp> rhelp [command-name]

서버로부터help 정보를 얻어온다.

ftp 프로그램 상의 명령어가 아닌 순수ftp 프로토콜의 명령어에 대한help 정보이다.

 

rename

ftp> rename [from-name [to-name]]

서버의 파일디렉토리의 이름을 변경한다.

 

rmdir

ftp> rmdir [directory-name]

빈디렉토리를 삭제한다.

 

runique

local 파일의unique 저장 설정을 변경한다. (on/off toggle, default: off)

만약remote 파일을get/mget으로 가져올 때, local 서버에 같은 이름의 파일이 존재하는 경우

해당off로 설정되어있으면 덮어씌기하고, on으로 설정되어있으면 파일명 끝에.1 과 같이 숫자 붙는다.

 

size

ftp> size [file-name]

파일의 사이즈를 출력한다.

 

status

현재ftp 접속 상태 정보를 출력한다.

 

struct

ftp> struct [struct-name]

파일 전송struct를 설정한다.

 

system

서버의OS 타입을 출력한다.

 

tenex

파일 전송 모드를tenex로 설정한다.

 

type

ftp> type [type-name]

파일 전송 모드를 설정

 

umask

ftp> umask [newmask]

서버의umask를 설정

 

verbose

verbose 모드를 설정한다. (on/off toggle, default: on)

on일 경우파일 전송 완료 시 전송 통계 내역(전송size, 소요시간초당 속도 등)을 출력한다.

출처 : 
http://blog.bntpidc.com/60109402564

[출처] ftp 명령어정리|작성자 BNTP IDC

전화선상에서 지원하는 음성 최대 주파수 대역은 4 KHz이다.
그러므로 나이퀴스트 이론에 의해 샘플링 주파수는 최소 8 KHz가 되어야 한다.
(나이퀴스트 이론 : 오리지널 음성의 최대 주파수를 최소 2배 이상 샘플링 한 후 전송하면 도착 지점에서 이것을 원래의 음성으로 복원할 수 있다)
그리고 각 샘플은 8 bit로 인코딩된다.
따라서 1 초에 8 bit * 8000 = 6400 bit(64Kbps)가 전송된다.


PCM은 음성 인코딩 방식 중 가장 보편적이면서 현재 대부분의 국가에서 PSTN 네트워크에 사용중인 방식이다. 또한 PCM 방식은 VoIP 환경에서도 대역폭이 풍부할 경우 좋은 음성 품질을 얻기 위해서 게이트웨이에 적용되는 방식이기도 하다.


이 방식에 근거해서 64 Kbps를 DS0라는 속도의 기본 단위로 정의한다. 즉, DS0 채널이 24개이면 T1, 32개이면 E1으로 부른다.


코덱의 종류

알고리즘

Bit Rate(B/W)

인코딩 타임(ms)

MOS

G.711

PCM

64K

10

4.1

G.726

ADPCM

16K, 24K, 32K

10

 

G.729

CS-ACELP

8K

10

3.9

G.729

LDCELP

16K

15

 

G.723

MLQ

5.3K, 6.3K

30

3.9

G.711 : PSTN
G.729 : VoIP에서 가장 보편적인 코덱
인코딩 타임 : 특정 코덱을 사용해서 아날로그 음성을 디지털 시그널로 변환하는데 걸리는 시간. 즉, DSP 칩에서 하나의 음성 프레임 아웃풋을 내보내는데 걸리는 처리시간을 말한다.


IP 네트워크를 통해 음성을 전송하기 위해서는 음성 데이터에 상대방의 IP 어드레스나 소켓 넘버 등 필요한 정보가 붙이는 '인캡슐레이션' 작업을 해야 한다. 이러한 인캡슐레이션 작업 때문에 각 음성 코덱을 이용해서 만들어진 결과값은 실제 네트워크로 전송될 때 이보다 더 많은 대역폭을 요구한다. 따라서 전용 회선 같은 WAN 구간에서 G.711은 82Kbps(payload : 64K + overhead : 18K)정도, G.729a는 26Kbps(payload : 8K + overhead : 18K) 정도의 대역폭이 필요하다.


G.711의 경우 디폴트 페이로드 사이즈는 160 Byte이다.
G.711 코덱은 10ms마다 아날로그 상태인 음성을 디지털로 바꾼다.(Digitization) 즉, DSP를 통해서 음성 아웃풋 샘플이 10ms마다 생긴다. 패킷을 구성할 때는 이러한 아웃풋 2개를 모은다. 이렇게 하는 이유는 음성 프레임 하나당 패킷을 만들면 오버헤드가 너무 커지기 때문이다. 그러므로 디폴트일 경우 G.711 패킷을 생성할 때마다 매번 20ms가 걸린다.


G.711의 초당 전송 트래픽이 64Kbps이다.
초당 64,000 bit  ->  초당 8,000 byte 를 전송.
즉, 1000 ms 당 8,000 Byte를 전송한다.
그렇다면 10ms마다 발생하는 음성 페이로드는 80 Byte이고, 20ms를 모으면 160 Btye가 된다.


패킷화 시간을 길게 잡으면 오버헤드가 줄어들어 대역폭 측면에서 보면 이득이 있다. 하지만 패킷화 시간을 길게 잡으면 실시간 트래픽의 성격에 맞지 않는 경우가 생긴다. 즉, 실시간 트래픽은 빠른 전송이 필요하기 때문에 너무 늦어지면 통신을 원활하게 하는데 문제가 밸상할 수 있다. 따라서, G.711, G.729의 경우에 디폴트 인코딩 타임이 20ms로 세팅되어 있다.

일단 ftp 명령 파일을 작성한다.
 ftp_cmd 파일

verbose
open 접속할주소
user ID PASSWORD
bi
ha
cd 디렉토리
put 업로드할파일
bye

접속할주소 : 접속 할 ftp 서버 주소
ID : 접속 할 ftp 서버의 계정명
PASSWORD : 계정에 대한 패스워드
디렉토리 : 작업할 디렉토리

위와 같이 파일을 만든 후

$ ftp -n < ftp_cmd 

명령을 내리면 저 명령들이 순차적으로 실행된다.

연구실의 새 서버(이름이 EDIS입니다 ^^;)에는 기가비트 이더넷 포트가 두 개나 있습니다.
지금까지는 하나의 포트만 사용했는데, 백업 데이터를 감당하는 용도로 사용하는 서버라서 대역폭이 매우 클 필요가 있겠더라고요.
그래서 예전부터 생각하고 있었던 네트워크 본딩을 시도해 보았습니다.

설치할 패키지는 ifenslave라는 것으로, 이것이 네트워크 본딩을 지원합니다.

# aptitude install ifenslave


이렇게 설치를 해 주고요, /etc/modprobe.d/arch/i386 파일에 다음 두 행을 추가합니다.

alias bond0 bonding
options bonding mode=0 miimon=100


mode가 의미하는 바는 다음과 같습니다.

mode=0 <- 제가 쓸 모드

This mode uses the Round-robin policy: Transmit packets in sequential order from the first available slave through the last. This mode provides load balancing and fault tolerance.

라운드-로빈 모드. 이 모드는 네트워크 부하 분산 및 내결함성 향상을 위해 쓰입니다.

mode=1

This mode uses an Active-backup policy: Only one slave in the bond is active. A different slave becomes active if, and only if, the active slave fails. The bond's MAC address is externally visible on only one port (network adapter) to avoid confusing the switch. This mode provides fault tolerance. The primary option affects the behavior of this mode.

액티브-백업 모드. 첫 번째 랜카드가 죽으면 두 번째 랜카드가 작동합니다. 두 번째가 죽으면 세 번째가 작동하고요. 그런 식입니다. 모드 0보다 매리트는 없어 보이네요.

mode=2

Transmit based on [(source MAC address XOR'd with destination MAC address) modulo slave count]. This selects the same slave for each destination MAC address. This mode provides load balancing and fault tolerance.

출발지 맥어드레스를 기반으로 부하 분산을 한다고 합니다. 즉, 부하 분산은 하지만 그것이 호스트 기반이라는 거죠. 랜카드 하나당 통신하는 호스트가 정해져 있습니다. 각각의 서버들에게 안정적인 대역폭을 제공하고자 할 때 쓸만해 보입니다.

물론 이런 경우에는 본딩을 한다기보다는 랜카드마다 할당된 IP주소를 모아서 하나로 관리한다는 성질이 더 강하지요.

mode=3

Broadcast policy: transmits everything on all slave interfaces. This mode provides fault tolerance.

각각의 본딩된 랜카드가 똑같은 패킷을 발송합니다. 랜카드가 절대로, 절대로 죽어서는 안 되는, 그리고 랜카드에서 생성된 패킷이 절대로, 절대로 없어져서는 안 되는 서버에 제격이죠.

mode=4

IEEE 802.3ad Dynamic link aggregation. Creates aggregation groups that share the same speed and duplex settings. Utilizes all slaves in the active aggregator according to the 802.3ad specification.

잘 이해는 안되지만, 그룹별로 관리하나 봅니다.

          *Pre-requisites:

1. Ethtool support in the base drivers for retrieving the speed and duplex of each slave.

2. A switch that supports IEEE 802.3ad Dynamic link aggregation. Most switches will require    some type of configuration to enable 802.3ad mode

mode=5

Adaptive transmit load balancing: channel bonding that does not require any special switch support. The outgoing traffic is distributed according to the current load (computed relative to the speed) on each slave. Incoming traffic is received by the current slave. If the receiving slave fails, another slave takes over the MAC address of the failed receiving slave.

글쎄요... 읽어봐도 무슨 내용인지...

*Prerequisite: Ethtool support in the base drivers for retrieving the speed of each slave.

mode=6

Adaptive load balancing: includes balance-transmit load balancing plus receive load balancing for IPV4 traffic, and does not require any special switch support. The receive load balancing is achieved by ARP negotiation. The bonding driver intercepts the ARP Replies sent by the local system on their way out and overwrites the source hardware address with the unique hardware address of one of the slaves in the bond such that different peers use different hardware addresses for the server.

이건 mode0과 비슷하지만, ARP변조를 통해 부하분산을 합니다. 원래 네트워크 본딩은 특별한 스위치 허브가 필요한데, 이건 그게 필요없다고 하네요.

저는 확인은 안했습니다만, 허브가 3com 이니까 웬만한 건 지원하리라 생각하고 mode0을 사용했습니다.


miimon은 해당 밀리초마다 체크한다는 의미입니다.

이걸 설정을 했으면, /etc/network/interfaces 파일을 편집합니다.
기존의 eth0, eth1 설정을 지우고요, 다음을 추가합니다.

auto bond0
iface bond0 inet static
        address 192.168.1.10
        netmask 255.255.255.0
        broadcast 192.168.1.255
        gateway 192.168.1.1
        dns-nameservers 165.246.10.2
        post-up ifenslave bond0 eth0 eth1

post-up 항목이 추가됐고, iface가 bond0으로 바뀐 것에 주목하세요.

여기까지 하셨으면, 서버를 리부팅합니다.

# reboot

자, 리부팅이 정상적으로 되셨나요? 그러면 ifconfig 를 실행해 보기로 하죠.

# ifconfig
bond0     Link encap:Ethernet  HWaddr 00:15:17:4E:F7:20
          inet addr:192.168.1.10  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::215:17ff:fe4e:f720/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:4019 errors:0 dropped:0 overruns:0 frame:0
          TX packets:290 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:388264 (379.1 KB)  TX bytes:39824 (38.8 KB)

eth0      Link encap:Ethernet  HWaddr 00:15:17:4E:F7:20
          inet6 addr: fe80::215:17ff:fe4e:f720/64 Scope:Link
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:2013 errors:0 dropped:0 overruns:0 frame:0
          TX packets:150 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:193628 (189.0 KB)  TX bytes:19430 (18.9 KB)
          Base address:0x2020 Memory:b8820000-b8840000

eth1      Link encap:Ethernet  HWaddr 00:15:17:4E:F7:20
          inet6 addr: fe80::215:17ff:fe4e:f720/64 Scope:Link
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:2006 errors:0 dropped:0 overruns:0 frame:0
          TX packets:140 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:194636 (190.0 KB)  TX bytes:20394 (19.9 KB)
          Base address:0x2000 Memory:b8800000-b8820000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:167 errors:0 dropped:0 overruns:0 frame:0
          TX packets:167 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:48261 (47.1 KB)  TX bytes:48261 (47.1 KB)

이렇게 보이면, 본딩이 제대로 이루어진 겁니다.
두 장의 랜카드가 기가비트였으니까, 이제 이 서버의 네트워크 속도는 무려 2기가비트!!
이제 백업 서버가 동시에 여럿이 작동해도 예전보다 두 배의 속도로 응답할 수 있게 되었습니다.

출처: http://wbstory.codns.com/~wbstory/blog/ ··· 594%25a9 (새 창으로 열기)

+ Recent posts