今天一早接到一個客戶電話，說他有一個交換機下面的用戶，大面積和上線下線。
由於之有已建議用戶在主干換了普通VLAN交換機。所以這次出現問題概率較小，只在一條支路的交換機下面。
下面我對這個情況的發生做一下分析：
PPPoE認證分為兩個階段：
第一階段：發現階段
1.客戶端以向FFFF-FFFF-FFFF廣播發送PADI數據包尋找AC，即服務端
2.服務端回復一個PADO單播幀；
3.農牧民端回復一個PADR單播請求，期望進行會話
4.服務端回復一個PADS數據包，同意進行下一步協商（包中攜帶一個sessionid，作為用戶的憑證之一）
第二階斷：會話階段
雙方使用PPP的LCP協議協商鏈路，NCP進行用戶名密碼檢驗，雙方完成通訊。
在第一階段pppoe會話重要依據就是雙方的mac地址，在和sessionid
在用戶下線的時候，用戶會發送PADT數據包進行協商，斷開會話連接
大家可以想象一下：病毒模擬發包的方式，向服務端發送PADT數據包？服務端以為是客戶端請求下線，就會斷開客戶端，導致客戶端掉線，多可怕的事啊。
具體數據包看附圖
有人要問了，病毒沒有客戶端與服務端通訊的seddionid，如何斷開？這個問題，我晚點再給大家解釋，大家先看圖
圖上第一段是客戶機正常下線的數據圖片。
過程是客戶端向服務端發送一個PADT，然后服務端收到PADT包，然后再回饋一個PADT包，客戶端下線，這個過程服務端只收到一個PADT數據包的。
圖上第三段是大面積掉線用戶的數據圖片。
大家仔細看，服務端收到兩個PADT包，多了一個PADT？這要如何解釋？
原因是病毒模擬客戶端向服務端發送PADT，服務端回饋一個PADT，此時按理如果是由客戶端自己主動發起的斷開，他是不會再回饋一個PADT包的。
可是我們服務端確實是收到了兩個PADT，這是因為第一個不是我們的客戶端發送的(是病毒發送的)，所以客戶端以為是服務端主動斷開，所以再回復一個PADT，才有上面的2個PADT包。
我仔細看了一下日志，大部分用戶都是2個PADT的數據包，印證了這一點。
接下去，我向大家解釋一下，為什么沒有sessionid，病毒為什么能模仿發送數據包？
發送PADT起碼要知道客戶端MAC和sessionid，我在抓包的時候發現：中毒的客戶機，一秒鍾發起5000多個ARP請求，而且是獲取其他客戶機MAC地址的ARP數據包。
這說明病毒一直在掃描內網的MAC，這個因為是二層通訊，這人以很簡單可以獲取的，而且在三層是禁止不了的。
接下去說一下sessionid吧
由於session是0xFFFF，也就是65536，網上有人說，病毒要斷開一個客戶端，要發送65536個數據包？
其實不然的，病毒沒有這么傻吧？斷開一個客戶端，要這么麻煩，6萬多個數據包，也得發送好一會兒。
病毒其實可以模擬一個pppoe認證過程的，自己就會獲取一個sessionid，或者根本不需要，因為本身就是pppoe 上網的，直接獲取。
大家都清楚，PPPOE的sessionid是累加的，這個看日志就知道了，所以病毒只要往他的MAC地址庫里面取出來的地址（這個數量就很少了吧），然后發送session為當前sessionid的數值就可以了
想想，是不是太可怕了？
又有人要問了，這樣之前上網的不就沒事？確實是，但是你總要下線吧，下線后，你的sessionid就在病毒掃描范圍內了，有甚者，全網掃描
有人要問了，這個要怎么防呢？其實這是二層通訊，除非你每個端口用VLAN隔離，才可以完全避免啊，
其實只要增加VLAN交換機使用，8口的才50多一個，以后還會更便宜，出了問題，影響的面積就不會是全網，不但有些用戶不受影響，而且也好找
如果有遇到這個問題要咨詢詳細處理的，可以加我的Q561454825