不可忽視的MTU

■

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

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

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

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

故障現(xiàn)象

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

故障排查

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

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

故障分析

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

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

故障解決

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