■

相信做過網(wǎng)絡管理的朋友對“MTU”應該都不陌生，我們也經(jīng)常在家用路由器上見過路由器WAN口的MTU設(shè)置選項。我們先來引入一下MTU的定義：最大傳輸單元（Maximum Transmission

Unit，MTU）是指一種通信協(xié)議的某一層上面所能通過的最大數(shù)據(jù)包大小（以字節(jié)為單位）。最大傳輸單元這個參數(shù)通常與通信接口有關(guān)（網(wǎng)絡接口卡、串口等）。一般來說，MTU只是決定數(shù)據(jù)傳輸過程中最大數(shù)據(jù)包的大小，并不會影響網(wǎng)絡通斷。但是對于一些特定的設(shè)備來說，MTU可能決定著數(shù)據(jù)傳輸?shù)某晒εc否。筆者與同事們在近期的一個無線認證接入項目中就因忽視了MTU而遇到了麻煩，下面介紹一下我們處理這一MTU故障的經(jīng)過。

先來介紹一下這個無線認證接入項目，后臺是無線認證系統(tǒng)（Portal）和AP硬件控制器（AC），用戶端則是路由器和AP配合使用。網(wǎng)絡拓撲結(jié)構(gòu)如圖1所示。

圖1 網(wǎng)絡結(jié)構(gòu)

故障現(xiàn)象

設(shè)備全部配置好之后，AP可以正常Ping通網(wǎng)關(guān)和AC，在AC本機上可以Ping通AP所在的路由器，表示網(wǎng)絡通暢。但是在AC管理界面上始終顯示AP離線；而每次重啟AP后，AC上顯示的AP離線時間就會重置。因此，從AP到AC之間的鏈路已經(jīng)打通，但應是某種協(xié)議不匹配或者設(shè)備不支持導致AP無法正常上線。

故障排查

為了排查故障點，首先，我們將和路由器和AP直接掛在AC下面，通過路由器上設(shè)置靜態(tài)IP與AC互聯(lián)，這時AP可以正常上線。之后，我們將路由器與AP放回用戶端，但仍使用同樣的靜態(tài)IP，通過二層VLAN與AC互聯(lián)，當鏈路配置完畢后，AP仍能正常上線。最后，將路由器恢復至PPPoE模式后，AP離線。這樣看來，離線原因應在PPPoE上。

經(jīng)過對PPPoE報文抓包分析，我們發(fā)現(xiàn)，AP發(fā)送給AC的第一個報文中，信息是完整的，而隨后的所有報文信息均有缺失。這樣就導致AP上報的信息中，只有第一個數(shù)據(jù)包完整傳遞到AC上，所以會有一個上線提示；而隨后的數(shù)據(jù)包，包括keepalive報文均不能正常送達，以致AP一直顯示離線。每當AP重啟后，重新發(fā)送的第一個數(shù)據(jù)包又能完整送達，導致AP離線時間重置為零。

故障分析

為什么會發(fā)生報文缺失的情況呢？這就要從鏈路傳輸?shù)摹癕TU”說起了。在TCP/IP協(xié)議中，將要傳輸?shù)臄?shù)據(jù)分成較小的組進行傳輸，每個組的大小為576字節(jié)。而Windows默認的字節(jié)為1500，這是以太網(wǎng)的分組標準。因此，對于時下大多數(shù)使用以太網(wǎng)的局域網(wǎng)來說，最大傳輸單元的值是1500字節(jié)。如果在IP層要傳輸一個數(shù)據(jù)報比鏈路層的MTU還大，那么IP層就會對這個數(shù)據(jù)報進行分片。一個數(shù)據(jù)報會被分為若干片，每個分片的大小都小于或者等于鏈路層的MTU值。當同一網(wǎng)絡上的主機互相進行通信時，該網(wǎng)絡的MTU對通信雙方非常重要。

但是像PPPoE這樣的系統(tǒng)會減小這個數(shù)值，這就使得在使用最大傳輸單元發(fā)現(xiàn)方法時可能會產(chǎn)生這樣的結(jié)果：一些處于配置不當?shù)恼军c變得不可達了。比如這里AP發(fā)送給AC的報文，AP默認的MTU是1500，而PPPoE的MTU則是1420，這樣數(shù)據(jù)包在經(jīng)過會PPPoE系統(tǒng)傳輸時會被重新分片打包，導致從第二個數(shù)據(jù)包開始就出現(xiàn)數(shù)據(jù)錯位，以致隨后的信息丟失，出現(xiàn)AP不能上線的情況。

故障解決

找到問題之后，解決辦法就出來了，我們請設(shè)備商的工程師給AP重做了一個軟件版本，新版本可以自定義AP的MTU值，將其改為1420以下，這樣數(shù)據(jù)包就可以完整傳輸了，而AP也可以正常上線。因此，當我們遇到類似故障，數(shù)據(jù)鏈路正常但某種協(xié)議不通時，可以檢查一下不同協(xié)議的最大傳輸單元是否一致。