802.1x
五.802.1X協議的狀態
802.1x作爲一個認證協議，在實現的過程中有很多狀態，此圖就是其中的一種。
1）認證發起
認證的發起可以由用戶主動發起，也可以由認證系統發起。當認證系統探測到未經過認證的用戶使用網絡，就會主動發起認證；用戶端則可以通過客戶端軟件向認證系統發送EAPOL-Start報文發起認證。
A）由認證系統發起的認證
當認證系統檢測到有未經認證的用戶使用網絡時，就會發起認證。在認證開始之前，端口的狀態被強制爲未認證狀態。
如果客戶端的身份標識不可知，則認證系統會發送EAP-Request/Identity報文，請求客戶端發送身份標識。這樣，就開始了典型的認證過程。
客戶端在收到來自認證系統的EAP-Request報文後，將發送EAP-Response報文響應認證系統的請求。
認證系統支持定期的重新認證，可以隨時對一個端口發起重新認證的過程。如果端口狀態爲已認證狀態，則當認證系統發起重新認證時，該端口通過認證，那麼狀態保持不便；如果未通過認證，則端口的狀態改變爲未認證狀態
B）由客戶端發起認證
如果用戶要上網，則可以通過客戶端軟件主動發起認證。客戶端軟件會向認證系統發送EAPOL-Start報文主動發起認證。
認證系統在收到客戶端發送的EAPOL-Start報文後，會發送EAP-Request/Identity報文響應用戶請求，要求用戶發送身份標識，這樣就啓動了一個認證過程。
2）退出已認證態
有幾種方式可以造成認證系統把端口狀態從已認證狀態改變成未認證狀態。
客戶端未通過認證服務器的認證
由於管理性的控制端口始終處於未認證狀態，而不管是否通過認證。
與端口對應的MAC地址出現故障（管理性禁止或硬件故障）
客戶端與認證系統之間的連接失敗，造成認證超時
重新認證超時
客戶端未響應認證系統發起的認證請求
客戶端發送EAPOL-Logoff報文，主動下線
退出已認證狀態的直接結果就是導致用戶下線，如果用戶要繼續上網則要再發起一個認證過程。
爲什麼要專門提供一個EAPOL-Logoff機制，是處於如下安全的考慮。
當一個用戶從一臺終端退出後，很可能其他用戶不通過發起一個新的登錄請求，就可以利用該設備訪問網絡。提供專門的退出機制，以確保用戶與認證系統專有的會話進程被中止，可以防止用戶的訪問權限被他人盜用。通過發送EAPOL-Logoff報文，可以使認證系統將對應的端口狀態改變爲未認證狀態。
3）重新認證（根據時間）
爲了保證用戶和認證系統之間的鏈路處於激活狀態，而不因爲用戶端設備發生故障造成異常死機，從而影響對用戶計費的準確性，認證系統可以定期發起重新認證過程，該過程對於用戶是透明的，也即用戶無需再次輸入用戶名/密碼。
重新認證由認證系統發起，時間是從最近一次成功認證後算起。重新認證可以激活或關閉，協議狀態參數reAuthEnabled控制是否定期進行重新認證。重新認證的時間由參數reAuthPeriod控制，默認值爲3600秒（一個小時）而且默認重新認證是關閉的。
重新認證的時間設定需要認真的規劃，認證系統對端口進入的MAC地址的檢測能力會影響到該時間的設定。如果對MAC地址的檢測比較可靠，則重新認證時間可以設長一些。
4）認證報文丟失重傳
對於認證系統和客戶端之間通信的EAP報文，如果發生丟失，由認證系統負責進行報文的重傳。在設定重傳的時間時，考慮網絡的實際環境，通常會認爲認證系統和客戶端之間報文丟失的機率比較低以及傳送延遲低，因此一般通過一個超時計數器來設定，默認重傳時間爲30秒鐘。
對於有些報文的丟失重傳比較特殊，如EAPOL-Star報文的丟失,由客戶端負責重傳；而對於EAP-Failure和EAP-Success報文，由於客戶端無法識別，認證系統不會重傳。如果EAP-Failure或EAP-Success報文發生丟失，則客戶端會在auth-While計數器超時後，自動轉變爲CONNECTING狀態。
由於對用戶身份合法性的認證最終由認證服務器執行，認證系統和認證服務器之間的報文丟失重傳也很重要。
另外注意，對於用戶的認證，在執行802.1x認證時，只有認證通過後，纔有DHCP發起（如果配置爲DHCP的自動獲取） 和IP分配的過程。由於客戶終端配置了DHCP自動獲取，則可能在未啓動802.1x客戶端之前，就發起了DHCP的請求，而此時認證系統處於禁止通行狀態，這樣認證系統會丟掉初始化的DHCP幀，同時會觸發認證系統發起對用戶的認證。
由於DHCP請求超時過程爲64秒，所以如果802.1x認證過程能在這64秒內完成，則DHCP請求不會超時，能順利完成地址請求；如果終端軟件支持認證後再執行一次DHCP，就不用考慮64秒的超時限制。