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 


연구실의 새 서버(이름이 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