專利名稱：同步動態(tài)主機配置協(xié)議中繼地址表與服務器地址池的方法
技術領域：
本發(fā)明涉及網(wǎng)絡通信技術領域，具體涉及一種同步動態(tài)主機配置協(xié)議中繼地址表與服務器地址池的方法。
背景技術：
如今的網(wǎng)絡，不管是企業(yè)網(wǎng)還是城域網(wǎng)，規(guī)模都越來越大，節(jié)點數(shù)也越來越多。這樣，就給網(wǎng)絡管理帶來更大的挑戰(zhàn)，尤其是IP(因特網(wǎng)協(xié)議)地址的管理。在規(guī)模較小的網(wǎng)絡中，采用靜態(tài)配置IP地址沒有什么麻煩，但對規(guī)模較大的網(wǎng)絡，采用靜態(tài)配置IP地址不僅容易出錯，造成IP地址沖突，而且會使配置工作變得非常復雜，因此產(chǎn)生了DHCP(Dynamic Host Configuration Protocol，動態(tài)主機配置協(xié)議)。DHCP提供了一種動態(tài)指定IP地址和配置參數(shù)的機制。啟用DHCP的計算機可以自動申請IP地址，不需要手工配置任何網(wǎng)絡參數(shù)就可以上網(wǎng)，它的出現(xiàn)使得計算機上網(wǎng)的配置變得方便容易，而且也簡化了網(wǎng)絡管理工作。另外DHCP使IP地址可以租用，對于擁有多臺計算機的大型網(wǎng)絡來說，每臺計算機擁有一個IP地址有時可能是不必要的，因此可以使幾臺計算機分時租用一個IP地址，從而節(jié)約了IP地址資源。
DHCP協(xié)議基于一般的client(客戶機)/server(服務器)模型，即client主動發(fā)起請求報文，server返回相應的應答報文。這里的client就是普通的計算機，server就是DHCP server，計算機啟動或申請地址時向DHCP server發(fā)送地址申請報文，DHCP server自動為client指定IP地址和其它網(wǎng)絡參數(shù)，并發(fā)送回應報文。由于DHCP client與server交互過程中大多使用廣播報文，而為了減少網(wǎng)絡中廣播報文流量，TCP/IP(傳輸控制協(xié)議/因特網(wǎng)協(xié)議)協(xié)議規(guī)定廣播報文是不能直接透傳到其他網(wǎng)段的，所以存在DHCP廣播報文不能跨網(wǎng)段交互的問題。這樣如果DHCP client和server分別在不同網(wǎng)段就無法進行交互。
目前，利用DHCP中繼解決上述問題，即利用DHCP中繼在不同網(wǎng)段之間轉發(fā)DHCP報文，從而實現(xiàn)多個網(wǎng)絡共用一個DHCP server。通常的DHCP中繼是集成在路由器或三層以太網(wǎng)交換機中的一個功能子模塊，三層以太網(wǎng)交換機和路由器一樣也可以配置不同的網(wǎng)段來劃分子網(wǎng)，其DHCP中繼實現(xiàn)方式相同。DHCP中繼典型組網(wǎng)方式如圖1所示，包括具有DHCP中繼功能的三層交換機、與其相連的網(wǎng)絡1中的DHCP服務器和網(wǎng)絡2中的DHCP客戶機。
以三層以太網(wǎng)交換機作為中繼，其DHCP中繼實現(xiàn)方式如下參見圖2，正常情況下client申請IP地址成功需要經(jīng)過以下4個報文交互過程(1)client主動發(fā)出DHCP-discover(DHCP發(fā)現(xiàn))廣播報文查找可用server；(2)server回應提供配置參數(shù)的DHCP-offer(DHCP授權)報文；(3)client根據(jù)這些參數(shù)發(fā)出DHCP-request(DHCP請求)廣播報文；(4)server回應DHCP-ack(DHCP確認)報文，并把該地址從空閑改為已分配狀態(tài)。
client收到DHCP-ack報文后就可以確認動態(tài)配置成功。
如果client原來已經(jīng)分配過地址，則可以省略DHCP-discover、DHCP-offer兩個報文，直接向server發(fā)送DHCP-request申請原來的地址，server認為該配置可用即回應DHCP-ack報文，否則回應DHCP-nak(DHCP否決)報文。
DHCP中繼用于在不同網(wǎng)絡之間轉發(fā)DHCP報文，為DHCP廣播報文提供網(wǎng)段間的轉發(fā)功能，使DHCP服務器為不在其網(wǎng)段內的用戶終端提供服務，從而實現(xiàn)多個網(wǎng)絡共用一個DHCP服務器。
DHCP支持三種類型的地址分配(1)自動分配方式中DHCP給主機指定一個永久的IP地址；
(2)動態(tài)分配方式中DHCP給主機指定一個有時間限制的IP地址，到時間或主機明確表示放棄這個地址時，這個地址可以被其他的主機使用；(3)手工分配方式中主機的IP地址是由網(wǎng)絡管理員指定的，DHCP只是把指定的IP地址告訴主機。
在這三種方式中，只有動態(tài)分配的方式可以對已經(jīng)分配給主機但現(xiàn)在此主機已經(jīng)不用的IP地址重新加以利用。這樣，在給一臺臨時連入網(wǎng)絡的主機分配地址或者在一組不需要永久的IP地址的主機中共享一組有限的IP地址時，動態(tài)分配顯得特別有用。當一臺新主機要永久的接入一個網(wǎng)絡時，而網(wǎng)絡的IP地址非常有限，為了將來這臺主機被淘汰時能回收IP地址，這種情況下動態(tài)分配也是一個很好的選擇。
但利用DPCP協(xié)議進行動態(tài)地址分配也帶來了一個問題，因為目前DHCP協(xié)議中沒有考慮如何限制主機設置固定IP地址，即不經(jīng)過DHCP申請網(wǎng)絡IP地址而擅自指定某個固定IP地址，也就是存在IP地址欺騙的問題。
針對該問題，中國專利申請125007.3公開了“一種動態(tài)地址分配中防止IP地址欺騙的方法”，該方法在DHCP中繼上通過把申請過IP地址的主機MAC(媒體接入控制)地址和IP地址記錄在一個動態(tài)地址表中，只有在該動態(tài)地址表中存在的主機才會在交換機中生成對應的ARP(地址解析協(xié)議)表項，而私自固定設置IP地址的主機無法生成ARP表項，也就無法連通外部網(wǎng)絡。但該方案并沒有揭示如何使該動態(tài)地址表與DHCP服務器的IP地址池保持一致的問題。例如，DHCP服務器地址池中某個IP地址租期已經(jīng)過期或被刪除，對應DHCP中繼上的動態(tài)地址池就應該刪除該項，否則如果把主機IP地址固定設為該過期IP地址，則主機仍然可以上網(wǎng)，也即無法避免IP地址欺騙的問題。

發(fā)明內容
本發(fā)明的目的在于提供一種同步動態(tài)主機配置協(xié)議中繼地址表與服務器地址池的方法，以解決現(xiàn)有技術方案中不能動態(tài)保持DHCP中繼的動態(tài)地址表與DHCP服務器IP地址池同步的問題。
為此，本發(fā)明提供以下技術方案一種同步動態(tài)主機配置協(xié)議中繼地址表與服務器地址池的方法，所述方法包括A、所述中繼通過同步動態(tài)主機配置協(xié)議DHCP消息獲取所述服務器地址池的表項狀態(tài)；B、根據(jù)所述獲取的服務器地址池的表項狀態(tài)修改所述地址表，使所述地址表中的地址與所述服務器地址池中已分配的地址一致。
所述步驟A包括A1、所述中繼定時遍歷所述地址表，依次獲取地址表項中的IP地址；A2、發(fā)送包含所述IP地址的DHCP請求消息到所述服務器；A3、所述服務器根據(jù)所述DHCP請求消息向所述中繼發(fā)送回應消息；A4、所述中繼根據(jù)所述回應消息獲取所述服務器地址池的表項狀態(tài)。
所述步驟A2包括A21、根據(jù)所述IP地址和所述中繼的媒體接入控制地址構造所述DHCP請求消息報文；A22、將所述DHCP請求消息報文發(fā)送到所述服務器。
所述步驟A21包括將所述IP地址作為待檢測地址填充到所述DHCP請求消息報文的事務標識字段；將所述中繼的媒體接入控制地址填充到所述DHCP請求消息報文的客戶機硬件地址字段。
所述步驟A3包括A31、所述服務器獲取所述DHCP請求消息中的IP地址；
A32、根據(jù)所述IP地址查詢所述地址池；A33、根據(jù)查詢結果向所述中繼發(fā)送回應消息。
所述步驟A33包括當所述IP地址對應的所述地址池中的地址為空閑時，向所述中繼發(fā)送DHCP確認消息；當所述IP地址對應的所述地址池中的地址為被占用時，向所述中繼發(fā)送DHCP否決消息。
所述步驟A4包括A41、如果所述中繼收到的是所述DHCP確認消息，則根據(jù)所述DHCP確認消息獲取所述待檢測地址；A42、如果所述中繼收到的是所述DHCP否決消息，并且所述DHCP否決消息報文中的客戶機硬件地址字段為所述中繼的媒體接入控制地址時，則正常結束；A43、如果所述中繼收到的是所述DHCP否決消息，并且所述DHCP否決消息報文中的客戶機硬件地址字段不為所述中繼的媒體接入控制地址時，則進行正常的中繼轉發(fā)流程。
所述步驟A41包括當所述DHCP確認消息報文中的客戶機硬件地址字段為所述中繼的MAC地址時，根據(jù)所述DHCP確認消息報文中的事務ID字段獲取所述待檢測地址；否則，根據(jù)所述DHCP確認消息進行正常的中繼轉發(fā)流程。
所述步驟B包括B1、查詢所述地址表；B2、刪除所述地址表中與所述待檢測地址對應的地址表項。
所述方法還包括當所述DHCP確認消息報文中的客戶機硬件地址字段為所述中繼的MAC地址時，所述中繼向所述服務器發(fā)送DHCP釋放消息；所述服務器根據(jù)所述DHCP釋放消息進行對應的操作。
所述中繼集成在路由器或三層以太網(wǎng)交換機中。
由以上本發(fā)明提供的技術方案可以看出，本發(fā)明通過在DHCP中繼上模擬DHCP客戶機向DHCP服務器申請網(wǎng)絡地址的方式，獲知DHCP服務器地址池中各IP地址的分配狀態(tài)，根據(jù)該狀態(tài)就可刪除動態(tài)地址表中對應于DHCP服務器地址池中已經(jīng)空閑的IP地址，保證了該空閑地址不再被未申請用戶使用。依照該方式，通過在DHCP中繼上定時遍歷動態(tài)地址表，對每一個地址表項進行及時檢測，保證了DHCP中繼地址池與DHCP服務器地址池的一致性，從而增強了IP地址的使用安全。


圖1是DHCP中繼的典型組網(wǎng)方式；圖2是現(xiàn)有技術中DHCP中繼轉發(fā)報文流程；圖3是DHCP報文格式；圖4是本發(fā)明方法的流程圖；圖5a、圖5b是本發(fā)明方法中DHCP中繼與DHCP服務器的消息交互流程；圖6是本發(fā)明方法中對中繼地址表的遍歷檢測流程；圖7是本發(fā)明方法中DHCP中繼對DHCP服務器的回應消息的處理流程。
具體實施例方式
本發(fā)明的核心在于在DHCP(動態(tài)主機配置協(xié)議)中繼上模擬DHCP客戶機向DHCP服務器申請網(wǎng)絡地址的方式，獲知DHCP服務器地址池中各IP地址的分配狀態(tài)，然后根據(jù)該狀態(tài)刪除動態(tài)地址表中對應于DHCP服務器地址池中已經(jīng)空閑的IP地址，使DHCP中繼的動態(tài)地址表與DHCP服務器地址池保持同步狀態(tài)。
為了使本技術領域的人員更好地理解本發(fā)明方案，下面結合附圖和實施方式對本發(fā)明作進一步的詳細說明。
參照圖3，圖3示出了DHCP報文格式，其中“消息類型”字段表示當前報文是客戶機的請求還是服務器的應答，為1時表示是客戶機的請求，為2時表示是服務器的應答。
“硬件地址類型”，“硬件地址長度”字段分別表示客戶機的網(wǎng)絡硬件地址類型、長度，如“硬件地址類型”為1，表示客戶機的網(wǎng)絡硬件是10MB的以太網(wǎng)類型，“硬件地址長度”為6，表示客戶機的網(wǎng)絡硬件地址長度是6bytes(即以太網(wǎng)類型的6bytes的MAC地址)。
“跳數(shù)”字段表示當前的DHCP報文經(jīng)過的DHCP中繼的數(shù)目，類似于IP頭中的跳數(shù)字段，但含義完全不同，客戶機或服務器發(fā)出DHCP報文時，此字段都初始化為0，每經(jīng)過一個DHCP中繼，此字段就會加1，此字段的作用是限制DHCP報文不要經(jīng)過太多的DHCP中繼，協(xié)議規(guī)定，當“跳數(shù)”大于4(也有規(guī)定為16)時，這個DHCP報文就不能再進行處理，而是丟棄。
“事務ID(標識)”字段客戶機每次發(fā)送DHCP請求報文時選擇的隨機數(shù)，由客戶機和服務器用來聯(lián)系消息和響應請求，匹配服務器的響應報文是對哪個請求報文的響應。服務器在應答報文中必須填上相同的事務ID值，用于確認請求/應答是否匹配。
“秒數(shù)”字段用來表示客戶機開始DHCP請求后的時間流逝秒數(shù)，此字段一般沒有多大意義，最初設計此字段是為了讓DHCP服務器在繁忙時，優(yōu)先處理此字段大的DHCP請求。
“標志”字段在DHCP協(xié)議中只使用了其左邊的最高位，作為廣播響應標識位。
“客戶機IP地址”字段表示客戶機自己的IP地址?？梢允欠掌鞣峙浣o客戶機的IP地址，也可以是客戶機已有的IP地址。
“你的IP地址”字段表示服務器分配給客戶機的IP地址。當DHCP服務器響應客戶機的DHCP請求時，將把分配給客戶機的IP地址填入此字段。
“服務器IP地址”字段表示客戶機獲取啟動配置信息的服務器IP地址，一般是TFTP(簡單文件傳輸協(xié)議)服務器的IP地址。
“中繼IP地址”字段記錄第一個DHCP中繼代理的IP地址。當客戶機發(fā)出DHCP請求報文后，如果網(wǎng)絡中存在DHCP中繼，則第一個DHCP中繼轉發(fā)這個DHCP請求報文時，就會把自己的IP地址填入此字段(隨后的DHCP中繼將不再改寫此字段，只是把跳數(shù)加1)。DHCP服務器將會根據(jù)此字段為用戶分配IP地址，并把響應報文轉發(fā)給此DHCP中繼代理，由DHCP中繼代理再轉發(fā)給客戶機。
“客戶機硬件地址”字段記錄客戶機的實際硬件地址內容。當客戶機發(fā)出DHCP請求報文時，將把自己的網(wǎng)卡硬件地址填入此字段，DHCP服務器一般都會使用此字段來唯一標識一個客戶機。而且此字段與前面的“硬件地址類型”、“硬件地址長度”字段必須一致。如當“硬件地址類型”、“硬件地址長度”分別為1和6時，此字段必須填入6bytes的以太網(wǎng)MAC(媒體接入控制)地址。
“服務器的主機名”字段記錄客戶機獲取啟動配置信息的服務器名字。此字段由DHCP服務器填寫，而且是可選的，如果填寫，必須是一個以0結尾的字符串。
“啟動文件名”字段記錄客戶機的啟動配置文件名。此字段由DHCP服務器填寫，而且是可選的，如果填寫，必須是一個以0結尾的字符串。
“選項”字段此字段中包含了大量可選的終端初始配置信息和網(wǎng)絡配置信息，如決定終端的IP特性配置信息、域名信息、標識終端的特殊信息、終端的默認網(wǎng)關IP地址、DNS(域名系統(tǒng))服務器的IP地址、WINS(Windows InternetName Server)服務器的IP地址、用戶使用IP地址的有效租期等信息。
本發(fā)明方法中主要通過上述“事務ID”字段、“客戶機硬件地址”字段及“中繼IP地址”字段承載所需信息，實現(xiàn)DHCP中繼對DHCP服務器地址池的查詢。
本技術領域人員知道，DHCP協(xié)議采用CLIENT-SERVER方式進行交互，其報文格式共有8種，由“選項”字段中的“DHCP message type”選項的value值來確定，具體含義如下1.DHCP-discover(發(fā)現(xiàn))類型值為0x01，此為客戶機開始DHCP過程的第一個報文；2.DHCP-offer(授權)類型值為0x02此為服務器對DHCP-discover報文的響應；3.DHCP-request(請求)類型值為0x03，此報文是客戶機開始DHCP過程中對服務器的DHCP-offer報文的回應，或者是客戶機續(xù)延IP地址租期時發(fā)出的報文；4.DHCP-decline(拒絕)類型值為0x04，當客戶機發(fā)現(xiàn)服務器分配給它的IP地址無法使用，如IP地址沖突時，將發(fā)出此報文，通知服務器禁止使用IP地址；5.DHCP-ack(確認)類型值為0x05，服務器對客戶機的DHCP-request報文的確認響應報文，客戶機收到此報文后，才真正獲得了IP地址和相關的配置信息；6.DHCP-nak(否決)類型值為0x06，服務器對客戶機的DHCP-request報文的拒絕響應報文，客戶機收到此報文后，一般會重新開始新的DHCP過程。
7.DHCP-release(釋放)類型值為0x07，客戶機主動釋放服務器分配給它的IP地址的報文，當服務器收到此報文后，就可以回收這個IP地址，能夠分配給其他的客戶機。
8.DHCP-inform(信息)類型值為0x08，客戶機已經(jīng)獲得了IP地址，發(fā)送此報文，只是為了從DHCP服務器處獲取其他的一些網(wǎng)絡配置信息，如路由IP，DNS IP等。
本發(fā)明就是在DHCP中繼上模擬DHCP客戶機向DHCP服務器申請網(wǎng)絡地址。報文應答分為兩種情況，如果申請的網(wǎng)絡地址在服務器的地址池中已經(jīng)空閑，則可以申請成功，并且服務器會返回一個DHCP確認報文；如果申請的網(wǎng)絡地址在服務器地址池中被占用，則服務器會返回一個DHCP否決報文。這樣，DHCP中繼根據(jù)收到的服務器的回應就可以檢測某個網(wǎng)絡地址在服務器地址池中的分配狀態(tài)。具體地址信息的承載是通過DHCP報文中的“事務ID”字段、“客戶機硬件地址”字段來實現(xiàn)的。下面將結合圖4對本發(fā)明方法作詳細說明。
參照圖4，圖4是本發(fā)明方法的流程圖，包括以下步驟首先，在步驟401由DHCP中繼定時遍歷其地址表，依次獲取地址表項中的IP地址；然后，進到步驟402根據(jù)IP地址和中繼的MAC地址構造DHCP請求消息報文。
前面已經(jīng)提到，本發(fā)明中利用DHCP報文中的事務ID字段和客戶機硬件地址字段承載查詢DHCP服務器地址池時所需的信息，具體承載信息如下將獲取的IP地址作為待檢測地址填充到DHCP請求消息報文的事務ID字段；將DHCP中繼的MAC地址填充到DHCP請求消息報文的客戶機硬件地址字段。
因為在DHCP中繼利用DHCP消息對服務器進行地址池表項狀態(tài)查詢的同時，還會有其他客戶機的正常DHCP轉發(fā)報文，因此就需要DHCP中繼將這種檢測報文與正常的轉發(fā)報文區(qū)別開。也就是通過檢查回應報文中的事務ID字段和客戶機硬件地址字段來判斷該報文是否為服務器的檢測回應。
在發(fā)起的request(請求)報文客戶機硬件地址字段中填入DHCP中繼(即交換機或路由器)的硬件MAC地址，這樣也可以避免與網(wǎng)絡上的真實地址發(fā)生沖突，服務器在回應的ack(確認)或nak(否決)報文中也會填入相同的值。DHCP中繼將收到ack或nak報文中的硬件地址域作為判斷該報文是否是檢測回應的首要條件；同樣如果在發(fā)起的request報文的事務ID里填入當前檢測地址項的IP地址，服務器在回應的ack或nak報文中也會填入相同的值。DHCP中繼將收到ack或nak報文中的事務ID字段作為判斷該報文是否是檢測回應的第二個條件。
因為硬件地址是固定不變的，容易受到欺騙報文的攻擊，而第二個條件中當前檢測地址項的IP地址是在不斷變化的，攻擊者無法仿冒，從而也大大增強了該檢測功能實現(xiàn)上的安全性。
步驟403將DHCP請求消息報文發(fā)送到DHCP服務器。
DHCP服務器收到DHCP請求消息后，進到以下步驟處理首先，在步驟404服務器獲取DHCP請求消息中的IP地址。
進到步驟405根據(jù)IP地址查詢地址池。
然后，進到步驟406根據(jù)查詢結果向中繼發(fā)送回應消息。
因為地址池中包括允許接入服務器的所有IP地址，這些地址有些可能已分配給某些客戶機使用，有些還未分配或是客戶機的使用租期到期被收回，即這些地址處于空閑狀態(tài)。在地址池中，對每個表項都標明了該表項中IP地址的當前使用狀態(tài)。因此，服務器根據(jù)獲取的DHCP請求消息中的IP地址對地址池的查詢結果有兩種情況該IP地址被占用或空閑。針對這兩種情況，服務器向中繼返回不同的回應消息。
(1)當該IP地址對應的地址池中的地址為空閑時，向中繼發(fā)送DHCP確認消息；
(2)當該IP地址對應的地址池中的地址為被占用時，向中繼發(fā)送DHCP否決消息。
步驟407中繼根據(jù)回應消息獲取服務器地址池的表項狀態(tài)。
針對上述不同的回應消息，中繼的處理也不同如果中繼收到的是DHCP確認消息，則根據(jù)DHCP確認消息獲取待檢測地址；如果中繼收到的是DHCP否決消息，則正常結束。
在前面步驟402中已經(jīng)說明在中繼發(fā)起的DHCP請求消息中，客戶機硬件地址字段中填入了DHCP中繼的硬件MAC地址，在事務ID字段中填入了當前檢測地址項的IP地址。服務器在回應的確認或否決報文中也會填入相同的值。這樣，DHCP中繼根據(jù)收到的確認或否決報文中的客戶機硬件地址字段就可知道是否為查詢的回應消息，根據(jù)事務ID字段獲知查詢的IP地址。如果DHCP確認消息報文中的客戶機硬件地址字段為中繼的MAC地址，則根據(jù)DHCP確認消息報文中的事務ID字段獲取待檢測地址；否則，根據(jù)DHCP確認消息進行對應的轉發(fā)流程。
進到步驟408DHCP中繼根據(jù)所述待檢測地址查詢地址表。
然后，進到步驟409刪除地址表中與待檢測地址對應的地址表項。
在上述過程中，如果服務器向中繼返回的是確認消息，則說明模擬申請地址成功，服務器已為該申請分配了IP地址，該IP地址就是中繼發(fā)送的請求消息中的事務ID字段中填充的地址，也就是上面所說的待檢測地址。因為中繼只是借用DHCP協(xié)議，模擬DHCP客戶機向DHCP服務器申請網(wǎng)絡地址，但其真正的目的是對申請的IP地址進行狀態(tài)檢測。因此，在這種情況下，中繼還必須主動發(fā)送一個DHCP釋放報文，以恢復DHCP服務器上對應的該地址。服務器根據(jù)DHCP釋放消息進行對應的操作，即恢復該地址為空閑狀態(tài)。
例如，在DHCP中繼的地址表中存在IP地址202.110.11.2，利用本發(fā)明對該地址進行檢測。其在地址池中為不同狀態(tài)時的報文應答流程分別如圖5a和圖5b所示。
參照圖5a所示該地址為空閑時報文的應答流程，主要有以下消息交互過程1.DHCP中繼發(fā)送請求消息，該消息中包含待檢測地址202.110.11.2；2.DHCP服務器收到請求消息后，檢測地址202.110.11.2在服務器地址池中為空閑狀態(tài)，分配該地址，向DHCP中繼回送確認消息；3.DHCP中繼收到確認消息后，發(fā)送釋放消息，該消息中包括需要釋放的IP地址202.110.11.2。DHCP服務器會根據(jù)該消息進行對應的操作。
參照圖5b所示該地址為已分配時報文的應答流程，主要有以下消息交互過程1.DHCP中繼發(fā)送請求消息，該消息中包含待檢測地址202.110.11.2；2.DHCP服務器收到請求消息后，檢測地址202.110.11.2在服務器地址池中為已分配狀態(tài)，向DHCP中繼回送否決消息。DHCP收到否決消息后，正常結束。
因為在DHCP中繼的動態(tài)地址表中會有多個地址表項，為了保持地址表與地址池中已分配地址的一致，就需要對每一個地址表項都進行檢測，通過在DHCP中繼上定時遍歷該地址表來實現(xiàn)。
考慮到服務器回應的確認報文或否決報文有可能會丟失，所以為了使每一個地址表項的檢測都能收到回應，需要對前一個地址表項是否接收到回應進行檢查，如果沒有收到回應則仍然處理上一個表項。檢測的定時時間由定時器來實現(xiàn)。
對地址表項進行遍歷檢測的流程如圖6所示首先，在步驟601定時器到時后，進到步驟602，判斷當前處理的地址表項狀態(tài)是否還在等待回應；如果是，則進到步驟604，發(fā)送request檢測報文，繼續(xù)檢測當前等待回應的表項，并標志當前表項狀態(tài)為等待狀態(tài)。然后，到步驟605，等待定時器到時后，再返回601，進行下一輪檢測。
如果不是，則進到步驟603，取地址表中的下一個表項作為當前處理項，然后，進到步驟604，發(fā)送request檢測報文，繼續(xù)檢測當前等待回應的表項，并標志當前表項狀態(tài)為等待狀態(tài)。然后，到步驟605，等待定時器到時后，再返回601，進行下一輪檢測。
在DHCP中繼模擬DHCP客戶機向DHCP服務器申請網(wǎng)絡地址，對地址表項進行檢測的同時，DHCP中繼還會轉發(fā)實際DHCP客戶機與DHCP服務器的DHCP報文，因此，DHCP中繼會從DHCP服務器接收到對檢測報文的回應消息及對實際客戶機申請地址的回應消息，此時，需要對這些消息進行判斷，分別做出不同的處理，處理過程如圖7所示在步驟S01DHCP中繼接收報文，接收的報文可能有以下三種情況(1)ack(確認)報文；(2)nak(否決)報文；(3)DHCP服務器發(fā)送的其他報文。
DHCP中繼對這三種不同報文的處理如下當收到ack報文時，進到步驟S11，判斷收到的ack報文是否為服務器對檢測報文的應答，如果是，則進到步驟S12，向服務器發(fā)送release報文，標記當前處理表項結束等待，并刪除中繼上對應的動態(tài)地址表項。然后，進到步驟S13，等待接收下一個報文。
當收到nak報文時，進到步驟S21，判斷收到的nak報文是否為服務器對檢測報文的應答，如果是，則進到步驟S22，標記當前處理表項結束等待。然后，進到步驟S13，等待接收下一個報文。
當收到其他報文時，進到步驟S02，進行中繼的正常轉發(fā)流程。
上述DHCP中繼可以集成在路由器或三層以太網(wǎng)交換機中。其對DHCP服務器地址池的查詢方式相同。
上述實施例描述了在DHCP中繼上實現(xiàn)地址表與DHCP服務器地址池分配地址保持一致的實現(xiàn)過程，應該知道，稍加變化，即可將本發(fā)明用于多個DHCP服務器主備之間進行分配地址的同步，或者其他需要查詢DHCP服務器地址池的應用中。
雖然通過實施例描繪了本發(fā)明，本領域普通技術人員知道，本發(fā)明有許多變形和變化而不脫離本發(fā)明的精神，希望所附的權利要求包括這些變形和變化而不脫離本發(fā)明的精神。
權利要求
1.一種同步動態(tài)主機配置協(xié)議中繼地址表與服務器地址池的方法，其特征在于，所述方法包括A、所述中繼通過同步動態(tài)主機配置協(xié)議DHCP消息獲取所述服務器地址池的表項狀態(tài)；B、根據(jù)所述獲取的服務器地址池的表項狀態(tài)修改所述地址表，使所述地址表中的地址與所述服務器地址池中已分配的地址一致。
2.根據(jù)權利要求1所述的方法，其特征在于，所述步驟A包括A1、所述中繼定時遍歷所述地址表，依次獲取地址表項中的IP地址；A2、發(fā)送包含所述IP地址的DHCP請求消息到所述服務器；A3、所述服務器根據(jù)所述DHCP請求消息向所述中繼發(fā)送回應消息；A4、所述中繼根據(jù)所述回應消息獲取所述服務器地址池的表項狀態(tài)。
3.根據(jù)權利要求2所述的方法，其特征在于，所述步驟A2包括A21、根據(jù)所述IP地址和所述中繼的媒體接入控制地址構造所述DHCP請求消息報文；A22、將所述DHCP請求消息報文發(fā)送到所述服務器。
4.根據(jù)權利要求3所述的方法，其特征在于，所述步驟A21包括將所述IP地址作為待檢測地址填充到所述DHCP請求消息報文的事務標識字段；將所述中繼的媒體接入控制地址填充到所述DHCP請求消息報文的客戶機硬件地址字段。
5.根據(jù)權利要求2所述的方法，其特征在于，所述步驟A3包括A31、所述服務器獲取所述DHCP請求消息中的IP地址；A32、根據(jù)所述IP地址查詢所述地址池；A33、根據(jù)查詢結果向所述中繼發(fā)送回應消息。
6.根據(jù)權利要求5所述的方法，其特征在于，所述步驟A33包括當所述IP地址對應的所述地址池中的地址為空閑時，向所述中繼發(fā)送DHCP確認消息；當所述IP地址對應的所述地址池中的地址為被占用時，向所述中繼發(fā)送DHCP否決消息。
7.根據(jù)權利要求6所述的方法，其特征在于，所述步驟A4包括A41、如果所述中繼收到的是所述DHCP確認消息，則根據(jù)所述DHCP確認消息獲取所述待檢測地址；A42、如果所述中繼收到的是所述DHCP否決消息，并且所述DHCP否決消息報文中的客戶機硬件地址字段為所述中繼的媒體接入控制地址時，則正常結束；A43、如果所述中繼收到的是所述DHCP否決消息，并且所述DHCP否決消息報文中的客戶機硬件地址字段不為所述中繼的媒體接入控制地址時，則進行正常的中繼轉發(fā)流程。
8.根據(jù)權利要求7所述的方法，其特征在于，所述步驟A41包括當所述DHCP確認消息報文中的客戶機硬件地址字段為所述中繼的媒體接入控制地址時，根據(jù)所述DHCP確認消息報文中的事務ID字段獲取所述待檢測地址；否則，根據(jù)所述DHCP確認消息進行正常的中繼轉發(fā)流程。
9.根據(jù)權利要求4所述的方法，其特征在于，所述步驟B包括B1、查詢所述地址表；B2、刪除所述地址表中與所述待檢測地址對應的地址表項。
10.根據(jù)權利要求6所述的方法，其特征在于，所述方法還包括當所述DHCP確認消息報文中的客戶機硬件地址字段為所述中繼的媒體接入控制地址時，所述中繼向所述服務器發(fā)送DHCP釋放消息；所述服務器根據(jù)所述DHCP釋放消息進行對應的操作。
11.根據(jù)權利要求1至10任一項所述的方法，其特征在于，所述中繼集成在路由器或三層以太網(wǎng)交換機中。
全文摘要
本發(fā)明公開了一種同步動態(tài)主機配置協(xié)議中繼地址表與服務器地址池的方法，所述方法包括中繼通過同步動態(tài)主機配置協(xié)議DHCP消息獲取服務器地址池的表項狀態(tài)；根據(jù)獲取的服務器地址池的表項狀態(tài)修改所述地址表，使所述地址表中的地址與所述服務器地址池中已分配的地址一致。利用本發(fā)明，可以實現(xiàn)在DHCP中繼上查詢DHCP服務器地址池中IP地址的狀態(tài)，使DHCP中繼地址表與DHCP服務器地址池保持同步，從而有效地限制未經(jīng)DHCP申請或已過租期的IP地址的使用，保證網(wǎng)絡管理的安全。
文檔編號H04L29/06GK1738269SQ20041005820
公開日2006年2月22日 申請日期2004年8月17日 優(yōu)先權日2004年8月17日
發(fā)明者修亦宏 申請人:杭州華為三康技術有限公司