ppp
一 PPP point to point protocol 數據鏈路層協議
PPP session establishment
1 link establishment phase
2. authentication phase
3. network layer protocol phase
點對點協議
特點：
封裝成幀 -----必須要實現的
透明性 ------
多種網絡層協議 ------（tcp或ipx協議）
多種類型鏈路 ------（光纖或電話線或雙絞線或同軸電纜等）
差錯檢測crc ------
檢測連接狀態 ------（提供各種狀態的匯報） 例如 欠費了 賬號密碼不對 電話線斷了 等各種不同 狀況的匯報
MTU --------最大傳輸單元
網絡層地址協商 -------分配ip地址
數據壓縮 ------壓縮 實現帶寬的節約 算法的支持
HDLC
LCP 負責身份驗證 ppp中建立鏈路的組件
NCP lcp通過之后 才能用此層分配ip地址 配置上層協議所需的環境 針對上層不同的協議類型 使 用不同的NCP組件
如果是ip 則提供 ipcp接口；如果是ipx 則提供ipxcp接口；如果是appletalk 則提供atcp接口。
PAP password authentication protocol 口令驗證協議
CHAP challenge-handshake authentication protocol 挑戰握手驗證協議
在這些協議中比較重要的是LCP 和NCP 前者負責創建，維護或終止一次物理連接
后者是一族協議 負責解決物理連接上運行什么網絡協議 以及解決上層網絡協議發生的問題
每一個ppp數據幀都以標志字節7e開始和結束
地址域 ：FF 由於點到點鏈路可以唯一標識對方 所以此字節無意義 填充為全1的廣播地址即可
控制域：0x03 無意義
協議域：區分ppp數據幀中信息域所承載的數據報文的內容 要求必須為奇數 低字節的最低位為1 高字節的 最低位為0 如果不符合上述規定 則接收端會向發送端發送一個protocol-reject報文 在此報文的 尾部 將完整地填充被拒絕的報文 主要的協議類型有LCP NCP 及普通的IP報文
實質上上面的協議類型標示ppp協議運行過程中的不同狀態 可以根據此協議域的值來判斷所處ppp的 哪個階段 可以通過抓包 判斷ppp的問題 再進行分析和定位
范圍 代表的含義
0x0***-0x3*** 特殊數據包的網絡層協議
0x8***-0xb*** 屬於網絡控制協議NCP
0x4***-0x7*** 用於沒有相關NCP的低通信量協議
0xc***-0xf*** 使用鏈路層控制協議LCP的包
保留值
0xc021 LCP
0xc023 PAP
0xc025 LINK quality report 鏈路品質報告
0xc223 CHAP
0x8021 IPCP IP控制協議
0x0021 ip internet protocol
0x0001 padding protoco 填料協議
0x0003-0x001f 保留
0x007d 保留
****
抓包實例：
信息域：缺省不超過1500字節 ppp協議中配置的參數選項MRU ===MAXimum receive unit
方法一：字節填充
信息部分中出現的標志字段的值解決辦法 （透明傳輸）
a 0x7e轉變成2個字節 0x7d 和0x5e
b 0x7d 轉變成2個字節 0x7d 和 0x5d
c 信息字段中出現ascii碼的控制字符 即數值小於0x20的字符
則在該字符前面要加入一個0x7d字節 同時將該字符的編碼加以改變
方法二：0比特填充
當用在SONET/SDH鏈路時 使用同步傳輸連續連串的比特連續傳送 這時ppp協議采用0比特填充方法來 實現透明傳輸
在發送端 只要發現有5個連續的1 就立即填入一個0 接收端對幀中的比特流進行掃描。每當發現5個連續1 時，就把這5個連續1后的一個0刪除。
所有的數據鏈路層協議都不進行編號和確認機制
PPP協議的工作狀態
1.用戶撥號接入isp 路由器（isp機房）的調制解調器對撥號確認 建立一條物理連接
2.pc向路由器發送一系列的LCP分組 封裝成多個PPP幀 這些分組及其相應選擇一些PPP參數 和進行網絡層 配置，NCP給新接入的pC機分配ip地址 （isp購買很多個ip地址）
3. 通信完畢后，NCP釋放網絡層的連接 收回原來分配出去的IP 地址.接着,LCP釋放數據鏈路層的連接 最后釋 放物理層連接
http://wenku.baidu.com/view/118ad274580216fc700afd5f.html?from=search
二 LCP協議
用於HDLC的上層 寫生數據鏈路的選項 制定MRU；lcp包被封裝在ppp數據區域內 協議用0xc021表示
代碼指定lcp包的種類 不同格式
標識符在請求和回復中使用 標識符無效 則該包將被靜靜丟棄
長度 制定lcp包長度 包括代碼 標識符 長度和數據區域 小於mru
數據 由0或多個8位字節
lcp包有3類
鏈路配置包 configure-request 匹配請求 代碼0x01
configure-ack 匹配正確應答
configure-nak 匹配不應答
configure-reject 匹配拒絕
鏈路結束包 terminate-request 終止請求
terminate-ack 終止應答
鏈路維修包 code-reject 代碼拒絕
protocol-reject 協議拒絕
echo-request 回波請求
echo-reply 回波應答
discard-request 拋棄請求
a： configure-request 匹配請求 ：
選項域格式：1字節類型 + 1字節長度 +數據
0x01 maximum-receive-unit 最大-接收-單元
0x02 async-control-character-map 異步-控制-字符-映射
0x03 authentication-protocol 鑒定-協議
0x04 quality-protocol 質量-協議
0x05 magic-number
0x07 protocol-field-compression 協議-域壓縮
0x08 addresss-and-control-field-compression 地址 控制域 壓縮
cofnigure-nak
configure-reject
terminate-request和terminate-ack
格式與configure-request格式都相同 不同點位前面的類型字段的值
工作流程 建立
1.客戶端打開一個連接 需要傳送一個configure-request包
2.isp router收到configre-request包 如果包中的每個配置選項及其所以值都能接受 就傳送一個configure-ack包
確認包中配置選項必須是接受的configure-request包中的配置選項的拷貝 且
標示符必須與configure-reques t包相同以保證匹配
如果收到的包與以上要求不符的包經被靜靜的丟棄
3.如果configre-request包中的每個配置選項及其所以值都能接受 但是配置項目當中的一些值不能被接受 則必 須傳送一個configure-nak包 其中選項域僅有收到的request包中不可接受的配置選項所填充
如果除了對端列出的配置項目之外還有新的項目要求配置 則nak也可以發送新的配置項目和值 以提醒對 端將其列入 request包中 作為下一次發送的請求項目
nak包中的標識符域必須匹配應答的request包
4.如果request 包中一些配置項目是不可辨認的或者不被寫上所受 則必須傳送一個configure-reject包 選項域 僅僅填充不可接受的配置項目 而且不被重定義或修改 標識符域request包相同
一個新的request包再發送時 必須不包含任何reject中列出的配置項目
終止包發送
1.發送terminate-request包 數據內容發生改變或接收到對前一個請求的有效應答 標識符域必須改變 對於重傳 標識符可以保持不變2.傳送ack包 接收到的request包的標識符必須被拷貝到要發送的ack包的標識符
流程：
1.接收到request包 后 必須傳送一個terminate-ack包 當接收到一個未被引用的terminate-ack包時表示對 端在關閉或停止狀態
2.如果要關閉一個連接 需要不斷發送terminate-request 直到收到terminate-ack包 或者收到鏈路低層 已經關閉的提示；或者已經接收到了足夠多的terminate-request包 以至於有充分的理由關閉
code-reject
在接收到一個帶有未知代碼的LCP包時 則必須傳送一個code-reject包報告回位置代碼的發送方。當接收到一個c ode-reject包 則應該報告問題並結束連接。
protocol-reject
當收到未知協議域的ppp包時 此時lcp處於打開狀態 所以需要傳送一個protocol-reject包回應對端 對端在接 收到protocol-reject包后 必須今早停止發送被指出的協議包
只能在LCP打開狀態下發送
echo-request和echo-reply
用於檢測數據鏈路層鏈路雙方是否正常運轉 這對調試 鏈路質量檢測 測試和其他眾多功能有幫助。
在LCP打開的情況下發送 在其他狀態下 需要被丟棄
接收到一個echo-request包時 必須傳送一個echo-reply包。
discard-request
測試遠端鏈路接收器 在LCP打開的情況下發送 接收器丟棄此包
c LCP定時器和計數器
1.重啟定時器 用於計算configure-request和terminate-request包的傳輸時間 超時事件觸發 並通知兩個request包需要重發 可配置 默認3s
2.重啟計時器
max-terminate 需要有一個terminate-request的重啟計數器 此項顯示request包發送后對端可能不會應答的 沒收到的terminate-ack包的個數 可配置 缺省為2次傳輸
max-confgure 顯示configure-request包發送后對端沒應答而沒收到configure-ack configure-nak 或config ure-reject包的個數 可配置 缺省為10次傳輸
max-failure 顯示configure-nak包發送后 ack包發送前的configure-nak包的個數 任何更進一步的用於對 端請求的選項被轉換到configure-reject包 必須可配置 缺省為5次傳輸
三 PAP協議
密碼驗證協議 鏈路雙方使用2次握手建立身份驗證 明文發送 並且對重復驗證和錯誤攻擊沒有保護措施 pap包格式
authenticat-request 用來啟動pap 不停的發送 直到接收到一個有效的響應包或超時計數器
收到au-request包 用戶名和密碼可識別 可接受 則發送一個au-ack包 如果不可接受 則發送一個au-nak包 並且終止鏈路
四 CHAP協議
其中的one-way-hash 單項哈希 就是不可逆的計算過程 例如MD5
對端發送md5（秘鑰） 驗證端 用md5（秘鑰） 如果兩個值匹配則驗證成功 秘鑰不在鏈路上傳播
要求雙方都知道秘鑰 建議為了避免在網絡的其他鏈路上發送秘鑰 可以配置一台中心服務器統一管理秘鑰
chap通過使用遞增的標識符和可變的挑戰值防止會送攻擊
重復挑戰目的：驗證者控制挑戰的頻率和時間
md5最佳秘鑰長度16字節
challenge值應該符合兩個標准：唯一性和不可預測性 每個值應該是唯一的
如果使用相同秘鑰聯系的chanlenge值的副本可能讓攻擊者利用前一個截獲的響應包響應 如圖
每個challenge值也應該是不可預測的，否則攻擊者欺騙對端響應一個可預測的未來challenge 然后用這個響 應偽裝成對端欺騙驗證者 如圖
1.鏈路建立階段結束后 認證者向對端發送challenge 信息
2.對端用經過單向哈希函數計算出來的值做應答 md5運算后
3.認證者根據他自己的預期哈希值來檢查應答 如果值匹配 認證得到承認 否則連接應該終止
4.經過一定的隨機間隔 認證者發送一個新的challenge給對端 重復1-3
協商chap認證協議的配置選項格式：類型 長度 認證協議 算法
chap包格式 封裝在ppp數據鏈路層幀的數據域中 ppp的協議字段只是0xc223
格式：ppp幀頭 ppp協議域 代碼 標識符 長度 數據
代碼字段只是chap包的類型：challenge respoonse success failure
用法：
chap的開始
發送chall包
發送應答包 需要比較應答值和計算的預期值
發送success或failure包
挑戰包發送時間：有效的應答包成功接收或者計數器滿
對端應該隨時為認證階段和nlp階段的挑戰做好准備
success包可能丟失 所以需要允許重復的應答包
終止鏈路 可以有LCP的終止請求和終止應答來指示認證失敗
IPCP 協議（對應於IP協議的服務） 和 PPP鏈路質量監控LQM 以及ccp壓縮控制協議（略）
五 ppp鏈路的各個階段
a 鏈路死亡階段 鏈路一定開始並結束於這個階段
b 鏈路建立階段 LCP用於交換配置信息報 建立連接
c 認證階段 此階段只有鏈路控制協議 認證協議 鏈路質量監視協議的包是被允許的
d 網絡層協議階段 在前面的階段完成后 每個網絡層協議 ip ipx或appletalk 必須被相對應的NCP分別設定 每個NCP可以隨時被打開和關閉
e 鏈路終止階段 ppp可以任意時間終止鏈路 終止的原因很多 ：載波丟失 認證失敗 鏈路質量失敗 空閑周 期定時器期滿 或者管理員關閉鏈路
LCP關閉鏈路 即可 不需要ncp關閉 相反 一個ncp關閉卻不足以引起ppp鏈路的終止 即使ncp處於 opened狀態。
ppp自動狀態機制
以LCP有限狀態自動機為例 由事件、動作 和狀態轉換定義
事件：接受外部命令（打開 關閉 重啟定時器） 接受對端包
動作：啟動重啟定時器 向對端傳包
完整ppp協議運轉過程的報文舉例
以下是一段較完整的PPP協議運轉過程的報文 W:7E FF 03 C0 21 01 01 00 14 02 06 00 0A 00 00 05 06 48 43 D3 0A 07 02 08 02 2E 15 7E C021:LCP Configure-Request:ID=1 ACCM:映射ASCII17、19 Magic-Number:4843D30A PFC ACFC 寫入配置請求 R:7E FF 03 C0 21 02 01 00 14 02 06 00 0A 00 00 05 06 48 43 D3 0A 07 02 08 02 C5 7C 7E C021:LCP Configure-Ack:ID=1 ACCM:映射ASCII17、19 Magic-Number:4843D30A PFC ACFC 接收方同意請求 R:7E FF 03 C0 21 01 03 00 1D 01 04 07 D0 02 06 00 0A 00 00 07 02 08 02 05 06 A7 A0 42 6F 03 05 C2 23 05 4B F2 7E C021:LCP Configure-Request ID=3 MRU=07D0 ACCM:映射ASCII17、19 PFC ACFC Magic-Number:A7A0426F 認證協議:CHAP MD5 接收方發送請求有新的配置請求 W:7E FF 03 C0 21 03 03 00 08 03 04 C0 23 99 7F 7E C021:LCP Configure-Nak:ID=3 認證協議PAP 提醒接收方將認證協議改為PAP; R:7E FF 03 C0 21 01 05 00 1C 01 04 07 D0 02 06 00 0A 00 00 07 02 08 02 05 06 A7 A0 42 6F 03 04 C0 23 91 AB 7E C021:LCP Configure-Request:ID=5 MRU=07D0 ACCM:映射ASCII17、19 PFC ACFC Magic-Number:A7A0426F 認證協議:PAP 接收方重新發出配置請求將認證協議改為PAP W:7E FF 03 C0 21 02 05 00 1C 01 04 07 D0 02 06 00 0A 00 00 07 02 08 02 05 06 A7 A0 42 6F 03 04 C0 23 A2 F1 7E C021:LCP Configure-Ack:ID=5 MRU=07D0 ACCM:映射ASCII17、19 PFC ACFC Magic-Number:A7A0426F 認證協議:PAP 同意配置請求 W:7E FF 03 C0 21 09 00 00 08 48 43 D3 0A CF AE 7E C021:LCP Echo-Request:ID=0 Magic-Number=48 43 D3 0A 發送回波請求檢測鏈路 W:7E FF 03 C0 23 01 03 00 0F 03 48 4C 59 06 57 4F 52 4B 45 52 2E 87 7E C023:PAP Request:ID=3 用戶名ID=48 4C 59 密碼=57 4F 52 4B 45 52 發送用戶名和密碼請求認證 R:7E FF 03 C0 21 0A 00 00 08 A7 A0 42 6F 87 F0 7E C021:LCP Echo-Reply:ID=0 Magic-Number=A7 A0 42 6F 接收端發送回波應答 R:7E C0 23 02 03 00 05 00 8B 09 7E C023:PAP Ack:ID=3 接收端通過驗證 w:7E FF 03 80 21 01 07 00 10 03 06 00 00 00 00 02 06 00 2D 0F 00 BE 0B 7E 8021:IPCP Configure-Request:ID=7 IP:00.00.00.00請求對端分配 壓縮TCP;最大時間片標識0F;時間片標識符不壓縮 發送IP請求和壓縮請求 R:7E 80 21 04 07 00 0A 02 06 00 2D 0F 00 6E 85 7E 8021:IPCP Configure-Reject:ID=7 壓縮TCP;最大時間片標識0F;時間片標識符不壓縮 接收端不同意壓縮 W:7E FF 03 80 21 01 08 00 0A 03 06 00 00 00 00 24 1A 7E 8021:IPCP Configure-Request:ID=8 IP:00.00.00.00請求對端分配 請求IP地址分配 R:7E 80 21 01 01 00 0A 03 06 C0 A8 FE FE 48 CC 7E 8021:IPCP Configure-Request:ID=1 IP:C0.A8.FE.FE W:7E FF 03 80 21 02 01 00 0A 03 06 C0 A8 FE FE 5F 56 7E 8021:IPCP Configure-Ack:ID=1 IP:C0.A8.FE.FE W:7E FF 03 80 21 01 08 00 0A 03 06 00 00 00 00 24 1A 7E 8021:IPCP Configure-Request:ID=8 IP:00.00.00.00 繼續發送IP請求 R:7E 80 21 03 08 00 0A 03 06 0A 5F 15 DB E9 3A 7E 8021:IPCP Configure-Nak:ID=8 IP:0A.5F.15.DB 接收端建議采用IP: 0A.5F.15.DB W:7E FF 03 80 21 01 09 00 0A 03 06 0A 5F 15 DB 24 C1 7E 8021:IPCP Configure-Request:ID=9 IP:0A.5F.15.DB 采納建議發送IP0A.5F.15.DB請求 R:7E 80 21 02 09 00 0A 03 06 0A 5F 15 DB 33 5B 7E 8021:IPCP Configure-Ack:ID=9 IP:0A.5F.15.DB 接收端通過請求分配IP:0A.5F.15.DB
TCP/IP協議過程 W:7E FF 03 C0 21 09 02 00 08 48 43 D3 0A 74 99 7E C021:LCP Echo-Request:ID=2 Magic-Number=48 43 D3 0A 發送回波請求 R:7E FF 03 C0 21 0A 02 00 08 A7 A0 42 6F 3C C7 7E C021:LCP Echo-Request:ID=2 Magic-Number=A7 A0 42 6F 接收端回波應答 W:7E FF 03 C0 21 05 02 00 10 55 73 65 72 65 71 75 65 73 74 53 33 7E C021:LCP Terminate-Request:ID=2 發送鏈路中斷請求 R:7E FF 03 C0 21 06 02 00 10 55 73 65 72 65 71 75 65 73 74 72 A9 7E C021:LCP Terminate-Ack:ID=2 接收端同意中斷鏈路 7E FF 03 C0 21 05 05 00 04 5C A4 7E C021:LCP Terminate-Request:ID=5 接收端發出中斷鏈路請求 W:7E FF 03 C0 21 06 05 00 04 91 81 7E C021:LCP Terminate-Ack:ID=5 同意中斷鏈路。
廣域網QOS設置
HDLC支持qos不好
在hdlc基礎上的PPP對QOS支持較好
接口緩沖區叫buffer 存儲網絡擁塞時候需要轉發 但需要等待轉發的報文
一般需要軟隊列的排隊機制稱為FIFO 排在前面的先發 排在后面的等待 先進先出
另一種稱為WFQ 叫做加權的公平隊列 相對更高級
一個隊列中有多個片段長度不一致 而且協議不同 可能會造成抖動 titter
例如：video片段為A VOIP報文為B ftp報文為C
隊列為：AABBAACBBBBAA
A B C長度都不同 其中C的長度最大 需要進行切片 並拆開 即鏈路分片及交互的方式 用來解決排隊 帶來的抖動。
實驗：
r1：
#interface s1/1
#encapsultaion ppp
#no ip address 注意物理接口不能有ip地址 因為邏輯多線路需要一個ip地址
#ppp multilink group 12 鏈路兩端的編號需要一致
#no shudown
r2配置相同
B
啟用多鏈路
r1：
#interface multilink 12
#encapsulation ppp
#ppp multilink
#ppp multilink group 12
#ip address 12.1.1.1 255.255.255.0
r2 配置類似
C 檢驗
r1#show ip interface brief
D 配置鏈路分段
r1#interface multilink 12
#ppp multilink fragment delay 10 啟用分片 10ms指定發送一個小分片 只是需要10ms即可
#ppp multilink interleave 開啟交互 比如將ftp報文分割成多個小分片后 將voip的報文夾雜在這些小分片中 來一起發送 保證不會產生抖動
r2相同的配置
E 配置帶寬利用率----壓縮
兩端都要配置壓縮
r1#interface multilink 12
#compress stac 堆棧式壓縮
r2同樣配置