簡介H12-811 HCIA-Datacom 655題新題庫面向準(zhǔn)備華為HCIA-Datacom認(rèn)證的考生及網(wǎng)絡(luò)基礎(chǔ)學(xué)習(xí)者圍繞認(rèn)證考試中的常見考點(diǎn)組織判斷題、單選題和多選題適合用于系統(tǒng)刷題、階段自測與考前查漏補(bǔ)缺。題庫內(nèi)容覆蓋網(wǎng)絡(luò)協(xié)議基礎(chǔ)、命令行接口、數(shù)據(jù)包分析、傳輸層協(xié)議、靜態(tài)路由、OSPF、VRP操作平臺(tái)、路由器配置及IEEE 802.11n等模塊題目附帶參考答案便于對照理解概念、梳理配置命令和總結(jié)排錯(cuò)思路。題庫以題目串聯(lián)協(xié)議字段、路由表查看命令、OSPF鄰居狀態(tài)等細(xì)節(jié)適合邊練邊查強(qiáng)化對知識(shí)點(diǎn)的記憶與應(yīng)用。資源包共1個(gè)PDF文件大小約7MB內(nèi)容集中適合在電腦或移動(dòng)設(shè)備上按章節(jié)練習(xí)與反復(fù)查閱。目前已有2350人學(xué)習(xí)可作為HCIA-Datacom備考過程中的題庫訓(xùn)練材料幫助讀者熟悉題型分布、定位薄弱知識(shí)點(diǎn)并提升答題熟練度。1. 從 655 道題倒推的知識(shí)地圖H12-811 的考點(diǎn)分布把這份題庫按技術(shù)塊拆開H12-811 這條線其實(shí)就六條主線二層轉(zhuǎn)發(fā)MAC 表、VLAN、STP、鏈路聚合、路由與 OSPF、傳輸層與 IP 服務(wù)TCP/UDP、ACL、DHCP、NAT、IPv6、WLAN、網(wǎng)絡(luò)管理與可編程接口。655 道題里真正考“背定義”的很少絕大多數(shù)考的是“同一個(gè)現(xiàn)象兩種解釋你選哪個(gè)”——PVID 到底是 1 還是 10、橋 ID 里 2048 能不能出現(xiàn)、MPLS 的 S 位 0 和 1 誰表示棧底、AP 拿到 AC 地址后第一步干什么。這份筆記按“地圖—模塊—易錯(cuò)—清單”的順序重排了一遍適合已經(jīng)過完一遍教材、準(zhǔn)備二輪復(fù)習(xí)的人拿來對照考點(diǎn)。梳理下來你會(huì)發(fā)現(xiàn)丟分點(diǎn)往往不在難題而在這些“看著會(huì)、一做就錯(cuò)”的判定細(xì)節(jié)上。2. 二層轉(zhuǎn)發(fā)與 VLANMAC 表、Tag 與 STP 的判定順序交換模塊是整份題庫里出題最密集的部分從 MAC 地址學(xué)習(xí)一直串到 STP 選舉、鏈路聚合幾乎每隔幾題就出現(xiàn)一次。它的特點(diǎn)是每個(gè)知識(shí)點(diǎn)單獨(dú)看都不難但題面一旦把“泛洪”“PVID”“根路徑開銷”混在一張拓?fù)鋱D里就很容易選錯(cuò)。這一章按“轉(zhuǎn)發(fā)動(dòng)作—打標(biāo)簽—防環(huán)”三層往上疊把判斷順序固定下來。2.1 MAC 地址表與泛洪三個(gè)動(dòng)作的固定順序二層交換機(jī)收到一個(gè)幀動(dòng)作永遠(yuǎn)是三步先看源 MAC 學(xué)不學(xué)再看目的 MAC 查不查得到最后決定轉(zhuǎn)發(fā)還是泛洪。源 MAC 學(xué)進(jìn)表里綁定“MAC 端口 老化時(shí)間”目的 MAC 查得到就單播轉(zhuǎn)發(fā)查不到就除入端口外所有端口泛洪廣播幀和未知組播同樣泛洪。題庫里那道“目的 MAC 是 5489-98ec-f011、表里沒有匹配條目”的題答案就是泛洪而不是丟棄或回送不可達(dá)——交換機(jī)不會(huì)因?yàn)椴椴坏骄蛠G包它沒有這個(gè)機(jī)制。幾個(gè)容易混淆的邊界要單獨(dú)記交換機(jī)重啟后所有動(dòng)態(tài)學(xué)習(xí)的 MAC 表項(xiàng)全部丟失必須重新學(xué)習(xí)所以“重啟后某端口學(xué)到的地址不需要重新學(xué)習(xí)”這種選項(xiàng)一定是錯(cuò)的路由器的每個(gè)接口屬于不同廣播域而一臺(tái)交換機(jī)上不開 VLAN 時(shí)所有端口同屬一個(gè)廣播域開了 VLAN 才按 VLAN 切分。沖突域則看物理層設(shè)備集線器相連的端口還在同一個(gè)沖突域里交換機(jī)的每個(gè)端口各自是一個(gè)沖突域。以太網(wǎng)幀的 Type/Length 字段是另一組必考點(diǎn)取值直接決定上層是什么Type/Length 取值含義關(guān)鍵結(jié)論0x0800上層為 IPv4IP 首部 2060 字節(jié)選項(xiàng)字段最多 40 字節(jié)0x0806上層為 ARPEthernet II 幀源 MAC 一定不是全 F目的 MAC 可能是廣播0x8100攜帶 VLAN Tag一定是 802.1Q 幀與上層是 TCP 還是 UDP 無關(guān)0x8100 那道題的正確選項(xiàng)只有“該幀一定攜帶了 VLAN TAG”其余三個(gè)“上層一定存在某首部”的說法都越界了——Tag 只說明二層封裝說明不了三層協(xié)議。2.2 VLAN 與端口類型Access、Trunk、Hybrid 的 Tag 處理VLAN 部分最容易被題面繞進(jìn)去的是“誰打標(biāo)簽、誰剝標(biāo)簽”。Access 口只屬于一個(gè) VLAN收方向不打標(biāo)簽、發(fā)方向剝標(biāo)簽Trunk 口默認(rèn) PVID 為 1允許列表里的 VLAN 帶標(biāo)簽通過PVID 對應(yīng)的幀不打標(biāo)簽Hybrid 口最靈活可以在出方向?qū)χ付?VLAN 剝掉 Tag也可以保留所以“Hybrid 發(fā)送數(shù)據(jù)幀時(shí)一定攜帶 VLAN Tag”是錯(cuò)的“Hybrid 只接收帶 Tag 的幀”也是錯(cuò)的“Hybrid 不需要 PVID”同樣錯(cuò)。命令行側(cè)要記兩組數(shù)字陷阱。vlan batch 10 20創(chuàng)建 2 個(gè) VLANvlan batch 10 to 20創(chuàng)建 11 個(gè)10 到 20 含兩端。這題四個(gè)選項(xiàng)里最容易選錯(cuò)的是“2 和 11”因?yàn)樗嫉牟皇敲钍悄銛?shù)不數(shù)得清區(qū)間。# 查看端口當(dāng)前的鏈路類型、PVID 和允許通過的 VLAN display port vlan GigabitEthernet0/0/1 # 把 Trunk 口改成 Access 口之前的清理動(dòng)作 interface GigabitEthernet0/0/1 undo port trunk allow-pass vlan 2 to 4094 port link-type access port default vlan 10第一行用于確認(rèn)現(xiàn)狀display port vlan會(huì)列出 PVID 和 Trunk 的 VLAN 列表是判斷“PVID 是 1 還是 10”這類題的唯一依據(jù)。第二段的關(guān)鍵在undo port trunk allow-pass vlan 2 to 4094Trunk 口的允許列表里默認(rèn)含 VLAN 1直接undo port trunk allow-pass vlan all會(huì)連 VLAN 1 一起刪掉而 VLAN 1 是設(shè)備管理 VLAN刪了會(huì)影響管理面。所以題目里“先執(zhí)行 undo ... vlan all”是錯(cuò)的“先執(zhí)行 undo ... vlan 2 to 4094”才是對的。還有兩個(gè)小結(jié)論要背死同一臺(tái)交換機(jī)上不同 VLANIF 接口的 IP 地址不能相同VLANIF 的地址是給該 VLAN 內(nèi)主機(jī)做網(wǎng)關(guān)用的不是給物理口配的。2.3 STP 與鏈路聚合選舉鏈條和活動(dòng)端口STP 的題幾乎全在考“比什么、按什么順序比”。橋 ID 優(yōu)先級(jí) MAC優(yōu)先級(jí)默認(rèn) 32768步長 4096所以 2048 這種不是 4096 倍數(shù)的優(yōu)先級(jí)不可能出現(xiàn)在配置 BPDU 里——這是那道“哪個(gè)橋 ID 不可能出現(xiàn)”的唯一解法。根橋選舉先比優(yōu)先級(jí)、再比 MAC都是越小越優(yōu)根端口選舉的順序是到根橋的路徑開銷 → 對端發(fā)送者橋 ID → 對端端口 ID → 本端端口 ID。路徑開銷是累加的不是取一段。SWD 的 G0/0/4 收到配置 BPDU 時(shí)里面攜帶的根路徑開銷是“從根橋到發(fā)送者”的累加值每段 200 的話兩跳就是 400選 600 或 200 都是沒算清段數(shù)。端口狀態(tài)轉(zhuǎn)換要記一個(gè)例外任何狀態(tài)都可以直接轉(zhuǎn)到 Disabled因?yàn)檫@是管理性關(guān)閉不受 STP 狀態(tài)機(jī)約束。指定端口的選舉則看“誰到根橋更近”集線器不跑 STP、不參與比較所以連在 HUB 上的端口不會(huì)被選成指定端口。鏈路聚合分兩個(gè)選舉別混選舉對象比較順序結(jié)論LACP 主動(dòng)端設(shè)備級(jí)系統(tǒng)優(yōu)先級(jí)小優(yōu)→ 系統(tǒng) MAC小優(yōu)與接口編號(hào)無關(guān)活動(dòng)端口端口級(jí)接口優(yōu)先級(jí)小優(yōu)→ 接口編號(hào)小優(yōu)與設(shè)備優(yōu)先級(jí)無關(guān)設(shè)了最大活動(dòng)端口數(shù)為 3 的時(shí)候把 4 個(gè)口按“優(yōu)先級(jí) 編號(hào)”排序排在第四位的那個(gè)就是非活動(dòng)端口編號(hào)越大越吃虧。組播 MAC 地址以 01-00-5E 開頭這個(gè)和單播、廣播的區(qū)分也要一眼能判。3. 路由與 OSPF從靜態(tài)路由到 LSDB 同步的判定鏈路由這塊的題量僅次于交換而且很多是“給一張圖 一段配置問為什么不通”。這類題的本質(zhì)是把“路由表怎么查”“鄰居怎么起”“LSDB 怎么同步”三件事拆開考。復(fù)習(xí)時(shí)建議按“查表 → 建鄰 → 同步 → 選路”的順序走一遍比零散背命令有效得多。3.1 路由表查找與靜態(tài)路由的邊界路由表查找只認(rèn)一條鐵律最長掩碼匹配。目的地址 9.1.1.1 同時(shí)能匹配 9.1.0.0/16 和一條更短的匯總路由時(shí)選 /16只有默認(rèn)路由 0.0.0.0/0 能兜住所有匹配不上的流量。掩碼長度相同時(shí)才比優(yōu)先級(jí)路由協(xié)議的管理距離這也是為什么默認(rèn)路由經(jīng)常被寫成“最后的選擇”。靜態(tài)路由和動(dòng)態(tài)路由的對比幾乎是送分題但送分題也會(huì)設(shè)坑對比項(xiàng)靜態(tài)路由動(dòng)態(tài)路由OSPF/BGP 等配置方式管理員手工逐條配置協(xié)議自動(dòng)學(xué)習(xí)鄰居交互不交互路由信息需要交互報(bào)文拓?fù)渥兓荒茏詣?dòng)適應(yīng)需人工改自動(dòng)收斂系統(tǒng)開銷低相對高那道“以下關(guān)于靜態(tài)路由說法錯(cuò)誤的是”的題錯(cuò)項(xiàng)就是“路由器之間需要交互路由信息”——靜態(tài)路由壓根不跑協(xié)議沒有交互這回事。診斷工具要分清用途tracert跟蹤轉(zhuǎn)發(fā)路徑發(fā)出的是 UDP 報(bào)文所以抓包看到 IP 首部 protocol 字段是 17ping -a指定回顯請求的源地址-s指定報(bào)文大小-d是設(shè)置 DF 位-n是發(fā)包個(gè)數(shù)。四個(gè)參數(shù)張冠李戴是高頻錯(cuò)點(diǎn)。# 只看靜態(tài)路由不摻雜直連和動(dòng)態(tài)路由 display ip routing-table protocol static # 在 OSPF 視圖下查看本進(jìn)程的配置 ospf 1 display this第一條命令的輸出只包含靜態(tài)路由條目是“如何只查看靜態(tài)路由”那道題的標(biāo)準(zhǔn)答案display ip routing-table會(huì)把直連、靜態(tài)、動(dòng)態(tài)全列出來display ip routing-table verbose則是看單條明細(xì)。第二條display this在協(xié)議視圖下執(zhí)行顯示當(dāng)前視圖的配置比display current-configuration精準(zhǔn)得多。靜態(tài)路由配置里還有一個(gè)必須會(huì)的寫法# 兩臺(tái)路由器各配一條默認(rèn)路由指向?qū)Χ藢?shí)現(xiàn)主機(jī)互通 ip route-static 0.0.0.0 0.0.0.0 11.0.12.2 ip route-static 0.0.0.0 0.0.0.0 11.0.12.10.0.0.0 0.0.0.0就是默認(rèn)路由的寫法下一跳分別指向?qū)Χ说慕涌诘刂?。反過來如果寫成ip route-static 10.0.12.5 255.255.255.252 11.0.12.1下一跳指向自己這一側(cè)的地址就是明顯的方向錯(cuò)誤——這是那道多選題里兩個(gè)錯(cuò)誤選項(xiàng)的共同特征。3.2 OSPF 五種報(bào)文與鄰居狀態(tài)機(jī)OSPF 的報(bào)文只有五種但每種的職責(zé)邊界必須分清報(bào)文作用關(guān)鍵點(diǎn)Hello發(fā)現(xiàn)鄰居、維持鄰居關(guān)系不攜帶 LSA周期發(fā)送DD交換 LSDB 摘要只帶 LSA 頭部不帶完整內(nèi)容LSR請求本地缺少的 LSA按摘要里的缺口發(fā)請求LSU攜帶完整 LSA 更新真正傳路由信息LSACK確認(rèn)收到的 LSA保證更新的可靠性問“哪個(gè)報(bào)文確保 LSA 更新可靠”答案只能是 LSACK問“哪個(gè)報(bào)文請求本地缺少的 LSA”答案只能是 LSR問“Hello 報(bào)文的功能”答案就是鄰居發(fā)現(xiàn)和維持鄰居關(guān)系別把“同步 LSDB”和“更新 LSA”也選進(jìn)去。鄰居狀態(tài)機(jī)上兩個(gè)結(jié)論最容易記反一是“先 Full 再同步 LSDB”是錯(cuò)的正確順序是先完成 LSDB 同步才進(jìn)入 Full二是穩(wěn)定狀態(tài)只有 Down、2-Way、Full 三種Attempt 是 NBMA 網(wǎng)絡(luò)里的過渡態(tài)不算穩(wěn)定狀態(tài)。2-Way 狀態(tài)在廣播網(wǎng)絡(luò)里其實(shí)是正常現(xiàn)象——非 DR/BDR 的路由器之間就停在這個(gè)狀態(tài)不再往下走。同一區(qū)域內(nèi)所有路由器的 LSDB 完全相同但路由表各不相同因?yàn)槊颗_(tái)路由器的位置不同、下一跳不同。這條結(jié)論幾乎每年都換個(gè)說法考一次。3.3 DR/BDR 選舉與網(wǎng)絡(luò)類型的對應(yīng)關(guān)系OSPF 支持四種網(wǎng)絡(luò)類型廣播、NBMA、點(diǎn)到點(diǎn)、點(diǎn)到多點(diǎn)。其中需要選舉 DR 和 BDR 的只有廣播和 NBMA點(diǎn)到點(diǎn)和點(diǎn)到多點(diǎn)不選。這個(gè)對應(yīng)關(guān)系是硬記的題面一般直接問“哪種網(wǎng)絡(luò)類型需要選舉 DR/BDR”。Router ID 的選舉順序手工配置優(yōu)先沒配就選最大的 Loopback 接口地址再?zèng)]有就選最大的物理接口地址。所以“配置 Router ID”不是必須手動(dòng)做的設(shè)備會(huì)自己選但“創(chuàng)建 OSPF 區(qū)域”和“創(chuàng)建 OSPF 進(jìn)程”是必做動(dòng)作——沒有進(jìn)程號(hào)就進(jìn)不了協(xié)議視圖題目里“沒配進(jìn)程號(hào)導(dǎo)致學(xué)不到路由”這個(gè)選項(xiàng)是錯(cuò)的因?yàn)椴慌溥M(jìn)程號(hào)根本配不下去。區(qū)域劃分上一臺(tái)路由器的不同接口可以屬于不同區(qū)域不是“所有接口必須屬于同一區(qū)域”。這條判斷的正確選項(xiàng)是 False。鄰居起不來、學(xué)不到路由常見原因就四個(gè)直接當(dāng)清單背沒有宣告與鄰居相連的網(wǎng)段Hello 發(fā)不出去一端配了認(rèn)證、另一端沒配Hello 里的認(rèn)證字段對不上兩端區(qū)域 ID 不一致區(qū)域號(hào)不同不能建鄰網(wǎng)絡(luò)類型不匹配一端廣播一端點(diǎn)到點(diǎn)Hello 周期和死區(qū)時(shí)間都對不上。# 宣告網(wǎng)段注意后面跟的是反掩碼 ospf 1 router-id 1.1.1.1 area 0 network 10.0.12.0 0.0.0.255network后面跟的是反掩碼0.0.0.255對應(yīng) /24。這里的router-id建議手工指定避免設(shè)備重啟后因接口地址變化導(dǎo)致 Router ID 改變進(jìn)而觸發(fā)鄰居重建。4. 傳輸層與網(wǎng)絡(luò)服務(wù)端口、ACL、DHCP 與 NAT這一章的知識(shí)點(diǎn)比較雜但出題方式很固定協(xié)議號(hào)填幾、端口范圍是多少、ACL 編號(hào)落在哪一段、DHCP 少了哪個(gè)報(bào)文。它們的共同點(diǎn)是“數(shù)字”而數(shù)字題最容易在考前一周集體遺忘所以建議單獨(dú)整理成一張速查表而不是散在筆記里。4.1 TCP/UDP協(xié)議號(hào)、握手次數(shù)與端口范圍IP 首部的 protocol 字段決定了上層是什么協(xié)議常用的三個(gè)值必須脫口而出1 是 ICMP6 是 TCP17 是 UDP。訪問 Web 服務(wù)器時(shí)傳輸層用 TCP所以 protocol 取值為 6——這是開篇第一道判斷題的考點(diǎn)。抓包看到 protocol 為 17說明承載的是 UDPtracert用的就是這種報(bào)文。TCP 建立連接三次握手、終止連接四次揮手這個(gè)結(jié)論沒有例外而“UDP 用 SYN 和 ACK 請求建立連接”是錯(cuò)的UDP 根本沒有連接的概念更沒有序列號(hào)字段做重組。UDP 的優(yōu)點(diǎn)是時(shí)延低、開銷小適合語音視頻這類對時(shí)延敏感、能容忍少量丟包的流量。端口號(hào)范圍知名端口 11023注冊端口 102449151動(dòng)態(tài)端口 4915265535。Telnet 服務(wù)器監(jiān)聽 23 端口客戶端用的是隨機(jī)高位端口所以抓到 50190 這種源端口屬于正?，F(xiàn)象——它是客戶端臨時(shí)分配的不是服務(wù)器端口。那道“三個(gè)數(shù)據(jù)包都不包含應(yīng)用層數(shù)據(jù)”的題考的是握手階段三次握手的前兩個(gè)報(bào)文只帶 TCP 首部第三個(gè)可以帶數(shù)據(jù)也可以不帶題面給定條件時(shí)按圖判斷不要想當(dāng)然認(rèn)為握手一定沒有應(yīng)用層數(shù)據(jù)。4.2 ACL 編號(hào)與規(guī)則匹配順序ACL 編號(hào)是純記憶題但四個(gè)區(qū)間經(jīng)常被記串類型編號(hào)范圍能匹配的字段基本 ACL20002999源 IP高級(jí) ACL30003999源/目的 IP、協(xié)議、端口二層 ACL40004999源/目的 MAC、VLAN ID用戶自定義 ACL60006031自定義規(guī)則二層 ACL 只能匹配 MAC 和 VLAN 相關(guān)字段不能匹配 IP所以“二層 ACL 可以匹配源 MAC、目的 MAC、源 IP、目的 IP”這個(gè)說法是錯(cuò)的反過來高級(jí) ACL 的編號(hào)落在 30003999不是 40004999。匹配順序只有一條從上到下逐條匹配命中即執(zhí)行動(dòng)作并停止不再往下看。正因?yàn)槿绱藝?yán)格條件的規(guī)則編號(hào)要排前面寬松條件的排后面如果先放了一條“permit any”后面的精細(xì)規(guī)則永遠(yuǎn)命中不了這是血淚經(jīng)驗(yàn)里最常提到的一條。另外要注意“匹配結(jié)果是拒絕”不等于“報(bào)文一定被丟棄”——還要看這條 ACL 被應(yīng)用在哪個(gè)方向、有沒有被其他策略覆蓋題面給的是“最終被丟棄”時(shí)判斷要結(jié)合上下文。# 高級(jí) ACL先放行到特定主機(jī)的 80 端口再拒絕其余 acl number 3000 rule 5 permit tcp source 192.168.1.0 0.0.0.255 destination 10.0.0.1 0 destination-port eq 80 rule 10 deny iprule 5和rule 10之間留了間隔是為了以后插入新規(guī)則時(shí)不用重排編號(hào)。source后面跟的是反掩碼destination-port eq 80只匹配目的端口 80其余端口不匹配。最后一條deny ip是兜底把所有沒被前面規(guī)則放行的流量拒掉——順序如果反過來第一條就全放行了后面的規(guī)則形同虛設(shè)。4.3 DHCP 報(bào)文與地址獲取失敗排查DHCP 的正常交互是四步Discover客戶端廣播找服務(wù)器、Offer服務(wù)器回應(yīng)可分配的地址、Request客戶端請求使用該地址、ACK服務(wù)器確認(rèn)。題庫里那道多選題把 Discover、Offer、Request 都列了進(jìn)去還混進(jìn)一個(gè)不存在的“ROLLOVER”就是考你知不知道四種報(bào)文的名字。地址獲取失敗的原因按排查順序排客戶端與 DHCP 服務(wù)器之間不通客戶端拿不到回應(yīng)Windows 系統(tǒng)會(huì)自動(dòng)生成 169.254.0.0/16 的地址——注意不是 172.254.0.0這個(gè)選項(xiàng)是專門設(shè)的陷阱網(wǎng)絡(luò)里有另一臺(tái) DHCP 服務(wù)器搶先回應(yīng)客戶端拿到了別的地址池的地址服務(wù)器地址池已經(jīng)分配完沒有空閑地址可發(fā)接口下配置了錯(cuò)誤的 DHCP 參數(shù)比如地址池網(wǎng)段和接口網(wǎng)段對不上。接口下如果同時(shí)配了兩個(gè)地址池客戶端最終拿到哪個(gè)取決于接口所屬的網(wǎng)段和地址池的匹配關(guān)系不是隨機(jī)二選一。這類題要看清“接口地址屬于哪個(gè)網(wǎng)段”再選。4.4 NAT 與 PPP/PPPoE私網(wǎng)地址訪問公網(wǎng)必須經(jīng)過 NAT 轉(zhuǎn)換這是 IPv4 地址緊缺的直接結(jié)果公網(wǎng)地址之間互訪則不需要。判斷“某地址訪問 Internet 一定要經(jīng)過 NAT”時(shí)要看這個(gè)地址本身是私網(wǎng)還是公網(wǎng)題面給的是 192.168 開頭的私網(wǎng)地址答案就是需要。PPP 的鏈路建立分兩個(gè)階段LCP 負(fù)責(zé)鏈路層參數(shù)協(xié)商認(rèn)證方式、最大接收單元等NCP 負(fù)責(zé)網(wǎng)絡(luò)層參數(shù)協(xié)商IP 地址、壓縮方式等。物理鏈路激活后先進(jìn)入鏈路建立階段跑的是 LCP。PPP 的一個(gè)特殊之處是鏈路兩端的 IP 地址可以不在同一網(wǎng)段因?yàn)樗屈c(diǎn)對點(diǎn)鏈路不存在“同網(wǎng)段才能通”的限制。PPPoE 的會(huì)話過程只有三個(gè)階段發(fā)現(xiàn)階段、會(huì)話階段、會(huì)話終結(jié)階段沒有“數(shù)據(jù)轉(zhuǎn)發(fā)階段”這個(gè)獨(dú)立階段——數(shù)據(jù)轉(zhuǎn)發(fā)是會(huì)話階段里做的事不作為單獨(dú)階段列出。5. 易錯(cuò)點(diǎn)排查IPv6、WLAN 與網(wǎng)絡(luò)管理里的五個(gè)盲區(qū)后面這幾塊內(nèi)容在題庫里占比不算最高但恰恰是“看書時(shí)覺得懂了、一做題就翻車”的重災(zāi)區(qū)。原因很統(tǒng)一它們的知識(shí)點(diǎn)都是成對出現(xiàn)的0 和 1、161 和 162、tagged 和 untagged只要記反一個(gè)方向整道題就廢。這一章按“易漏點(diǎn) → 為什么漏 → 怎么補(bǔ)”把五個(gè)最容易踩的坑攤開講。5.1 IPv6 地址簡寫與 EUI-64兩個(gè)方向容易記反的細(xì)節(jié)易漏點(diǎn)IPv6 地址2001:ABEF:224E:FFE2:BCC0:CD00:DDBE:8D58能不能簡寫答案是“不能”因?yàn)楹唽懸?guī)則只允許省略前導(dǎo)零和連續(xù)的全零段而這段地址里既沒有前導(dǎo)零可省也沒有連續(xù)的全零段。很多人一看這么長就下意識(shí)選“能簡寫”。為什么漏IPv6 簡寫規(guī)則背得不完整只記住了“雙冒號(hào)可以壓縮連續(xù)的 0”忘了“每組內(nèi)的前導(dǎo)零也可以省略”這個(gè)前提——兩個(gè)規(guī)則都不滿足時(shí)地址就保持原樣。怎么補(bǔ)把規(guī)則寫成兩句口訣——每組內(nèi)的前導(dǎo)零可省連續(xù)的全零段可以用一次雙冒號(hào)代替但雙冒號(hào)全地址只能出現(xiàn)一次。再配 EUI-64 一起記把 48 位 MAC 從中間劈開插入FFFE然后把第一字節(jié)的第七位U/L 位取反。MAC 是00E0-FCEF-0FEC插入后是00E0-FCFF-FEEF-0FEC第一字節(jié)00取反第七位變成02結(jié)果就是02E0-FCFF-FEEF-0FEC。選項(xiàng)里00E0-FCEF-FFFE-0FEC是沒插對位置02E0-FCEF-FFFE-0FEC是位置和取反都錯(cuò)的組合。IPv6 的另外幾個(gè)固定數(shù)字地址總長 128 位基本報(bào)頭固定 40 字節(jié)Hop Limit 字段對應(yīng) IPv4 的 TTL地址類型只有單播、組播、任播三種沒有廣播。5.2 WLANWi-Fi 6 的標(biāo)準(zhǔn)號(hào)與 CAPWAP 上線順序易漏點(diǎn)Wi-Fi 6 對應(yīng)的是 802.11ax不是 802.11ac那是 Wi-Fi 5也不是 802.11at那是 PoE 供電標(biāo)準(zhǔn)。另外FIT AP 拿到 AC 的 IP 地址后第一步是建立 CAPWAP 隧道而不是請求配置文件或升級(jí)版本。為什么漏802.11 后面那一串字母太像ac、ax、at、au 混在一起上線流程則是“先建隧道再要配置”的因果鏈沒理順容易按“先升級(jí)再配置”的直覺去選。怎么補(bǔ)把標(biāo)準(zhǔn)號(hào)和代數(shù)綁成一張小表——11n 對應(yīng) Wi-Fi 42.4G 和 5G 雙頻、11ac 對應(yīng) Wi-Fi 55G、11ax 對應(yīng) Wi-Fi 6。CAPWAP 上線順序記成“建隧道 → 要配置 → 下配置 → 升級(jí)版本”隧道是通道沒有通道什么都傳不了。控制隧道用 UDP 5246數(shù)據(jù)隧道用 UDP 5247兩個(gè)端口不一致所以“控制隧道和數(shù)據(jù)隧道端口號(hào)一致”是錯(cuò)的。STA 關(guān)聯(lián) AP 之前要先拿到 SSID靠的是 AP 周期發(fā)送的 Beacon 幀和 STA 主動(dòng)發(fā)出的 Probe RequestProbe Response 是對請求的回應(yīng)不是“STA 用來獲取 SSID”的主動(dòng)報(bào)文。2.4G 頻段的 13 個(gè)可用信道部分區(qū)域 14 個(gè)之間存在重疊只有 1、6、11 三個(gè)互不重疊所以“14 個(gè)信道不存在重疊”是錯(cuò)的。安全策略上WPA2-PSK 并不是唯一支持 TKIP 的策略這個(gè)“只有……才”的表述本身就是錯(cuò)項(xiàng)標(biāo)志。5.3 SNMP161 和 162 到底誰是誰易漏點(diǎn)代理進(jìn)程主動(dòng)發(fā)告警用的是 162 端口NMS 主動(dòng)查詢設(shè)備用的是 161 端口MIB 不是只存在于 NMS 上被管設(shè)備上也有。為什么漏兩個(gè)端口挨得太近做題時(shí)憑“16 開頭”的印象隨手選MIB 的分布則是被“數(shù)據(jù)庫”三個(gè)字帶偏以為集中存放。怎么補(bǔ)記一句“查詢走 161告警走 162”——NMS 發(fā) Get-Request 到設(shè)備的 161設(shè)備發(fā) Trap 到 NMS 的 162。SNMPv1 定義了五種操作Get-Request、Get-Next-Request、Set-Request、Response、Trap。其中 Set-Request 是 NMS 用來下發(fā)配置的Trap 是設(shè)備主動(dòng)上報(bào)的Get-Next 是遍歷 MIB 樹用的。MIB 是被管設(shè)備上對象的結(jié)構(gòu)化描述NMS 通過讀取設(shè)備上的 MIB 獲取狀態(tài)所以“MIB 只存在于 NMS 上”是錯(cuò)的。另外 SNMP 報(bào)文用 UDP 承載這也是判斷題的?？?。5.4 MPLS 的 S 位與 SR 的設(shè)計(jì)理念易漏點(diǎn)MPLS 標(biāo)簽里的 S 位取值為 1 表示棧底后面沒有其他標(biāo)簽取值為 0 表示后面還有標(biāo)簽。很多人記成反過來。為什么漏S 是 Stack 的首字母直覺上“1 還有棧”更順實(shí)際含義正好相反。怎么補(bǔ)記“1 到底”——S1 就是棧底到了最后一個(gè)標(biāo)簽。S 位在幀模式里只有 1 bit每個(gè) MPLS 報(bào)文頭里都有這一位不存在“信元模式 2 bit”的說法。順帶把 SR 一起記Segment Routing 基于源路由理念設(shè)計(jì)由頭節(jié)點(diǎn)在報(bào)文里壓入一段有序的標(biāo)簽棧中間節(jié)點(diǎn)只按棧頂標(biāo)簽轉(zhuǎn)發(fā)不再維護(hù)逐跳狀態(tài)這和“策略路由”“路由策略”是完全不同的東西。5.5 設(shè)備管理接口與虛擬化別被名詞唬住易漏點(diǎn)設(shè)備的開放接口里不包括 Telnet 這種傳統(tǒng)遠(yuǎn)程登錄協(xié)議NETCONF、JSON、XML 才是虛擬化的特點(diǎn)不止“隔離”一條還包括封裝、獨(dú)立、硬件無關(guān)。為什么漏NETCONF、JSON、XML 這幾個(gè)詞看著像“編程接口”Telnet 看著像“管理接口”很容易混為一談虛擬化的四個(gè)特點(diǎn)則常常只記住第一條。怎么補(bǔ)把“可編程接口”和“管理通道”分開記——NETCONF 是基于 XML 的網(wǎng)絡(luò)配置協(xié)議JSON 是數(shù)據(jù)格式XML 是標(biāo)記語言它們服務(wù)于自動(dòng)化配置Telnet 是交互式命令行通道不屬于開放接口。虛擬化的特點(diǎn)記四個(gè)詞隔離、封裝、獨(dú)立、硬件無關(guān)同一個(gè)物理服務(wù)器上的虛擬機(jī)相互隔離各自有獨(dú)立的操作系統(tǒng)和資源視圖。至于用腳本登錄設(shè)備抓回顯read_very_eager()是非阻塞讀取通常要配合 time 模塊用read_all()是讀到 EOF 為止回顯沒有 EOF 就會(huì)一直阻塞這兩個(gè)方法的差別在判斷題里反復(fù)出現(xiàn)。6. 復(fù)習(xí)清單與查漏補(bǔ)缺考前一周的復(fù)盤路徑把前面五章壓成一張可執(zhí)行的表復(fù)習(xí)時(shí)按“模塊 → 自檢問題 → 過不了怎么辦”三列走比從頭翻書快得多模塊自檢問題過不了怎么辦二層轉(zhuǎn)發(fā)未知單播、廣播、已知單播三種情況的處理動(dòng)作能否一句話說清回到 2.1 重畫三步判斷流程VLANPVID、允許列表、Tag 剝不剝?nèi)齻€(gè)概念能否分開解釋用display port vlan的輸出對照記憶STP根橋、根端口、指定端口各自的比較順序把“優(yōu)先級(jí)→MAC”“開銷→橋 ID→端口 ID”寫成兩行鏈路聚合主動(dòng)端和活動(dòng)端口分別比什么記住“設(shè)備級(jí)比系統(tǒng)端口級(jí)比接口”路由最長掩碼匹配和默認(rèn)路由的優(yōu)先級(jí)關(guān)系用一條 /16 和一條 /24 做例子手推一遍OSPF五種報(bào)文、三種穩(wěn)定狀態(tài)、四種網(wǎng)絡(luò)類型報(bào)文按“發(fā)現(xiàn)—摘要—請求—更新—確認(rèn)”串成鏈ACL四個(gè)編號(hào)區(qū)間和匹配順序記住“命中即?！眹?yán)格規(guī)則編號(hào)靠前DHCP四種報(bào)文和 169.254 的來源把“Discover→Offer→Request→ACK”默寫一遍IPv6簡寫規(guī)則、40 字節(jié)報(bào)頭、EUI-64 取反位找三個(gè)地址動(dòng)手簡寫一次WLAN11ax 對應(yīng) Wi-Fi 6、CAPWAP 雙端口、上線順序把 5246/5247 和“先建隧道”綁在一起記SNMP161 查詢、162 告警、五種操作用“查詢走 161、告警走 162”一句話鎖死具體到每一天的安排我的做法是前兩天只做錯(cuò)題回爐把 655 道題里做錯(cuò)的題按模塊歸類同一模塊錯(cuò)三道以上就說明這個(gè)模塊的地圖沒建起來回去重讀對應(yīng)章節(jié)中間兩天做跨模塊的圖例題尤其是“給拓?fù)? 給配置 問現(xiàn)象”的組合題這類題最能暴露“單個(gè)知識(shí)點(diǎn)會(huì)、連起來就不會(huì)”的問題最后兩天只過速查表不再做新題把協(xié)議號(hào)、端口號(hào)、編號(hào)區(qū)間、標(biāo)準(zhǔn)號(hào)這四類數(shù)字反復(fù)默寫到不錯(cuò)為止。還有一個(gè)查漏補(bǔ)缺的具體技巧把每道錯(cuò)題的錯(cuò)因?qū)懗梢痪湓捀袷焦潭椤拔乙詾?X實(shí)際是 Y”。比如“我以為 S 位 1 表示后面還有標(biāo)簽實(shí)際是 1 表示棧底”“我以為二層 ACL 能匹配 IP實(shí)際只能匹配 MAC 和 VLAN”。攢到二十條左右你會(huì)發(fā)現(xiàn)自己翻車的方向高度集中通常就三四個(gè)點(diǎn)集中補(bǔ)這幾個(gè)點(diǎn)比刷一百道新題有效。從那以后我每次復(fù)習(xí)這類認(rèn)證題庫都強(qiáng)制走一遍“先畫地圖、再分模塊、最后只盯錯(cuò)因一句話”的流程不再從頭到尾刷題。地圖建不起來的時(shí)候刷得越多越焦慮地圖建起來之后很多題看一眼題干就知道它想考哪個(gè)判定。希望這份梳理能幫到你把 655 道題從“題?！弊兂梢粡埬茈S時(shí)調(diào)出來的圖。本文還有配套的精品資源點(diǎn)擊獲取