波仔
📡 第三章 路由器和它庞大的功能
📄 一句话概括

路由器的管理界面有六种，不是「选一个用」，是「各有各的场合」。 Console 是唯一不依赖网络的入口——设备起不来时只有它能进去。

📝 本节和前面几节的关系

03.06 把功能全讲完了，从这一节开始讲「怎么管这些功能」。 03.06.01 说「管理功能不配也能用，所以常被欠」，这一节开始补那笔账。

一、六种界面各在什么时候用

界面 优点 缺点

Console（串口） 不依赖网络 必须到现场 SSH 加密、功能全 依赖网络与管理面 Telnet 兼容老设备 明文 HTTPS（Web） 直观 功能不全 SNMP 可批量、可监控 不能做复杂配置 NETCONF／RESTCONF 结构化、可自动化 设备支持不一

分成两类看更清楚：带内的（SSH、HTTPS、SNMP、NETCONF）都依赖网络与管理面； 带外的只有 Console 一个。 而两类的价值完全不同：带内管日常，带外管救命。

二、Console 为什么不可替代

设备配置错了 IP、把管理口 shutdown 了、镜像坏了起不来——这三种情况下，所有带内方式全部失效。 只有 Console 能进去。

所以运维规范里有一条： 机房里的设备必须能物理接触到串口，或者接一台终端服务器（terminal server）统一纳管。 远程机房更必须有——否则一次配置失误就要派人飞过去。

终端服务器的价值在于「把串口变成网络可达」：一台设备几十个串口，接上所有网络设备， 远程 telnet 到某个串口就等于插上了那根线。 这是「带外管理」最常见的落地形式。

三、9600 为什么显得慢

默认波特率 9600、8N1，也就是每字节 10 位（1 起始 ＋ 8 数据 ＋ 1 停止）， 所以每秒约 960 字节。

一屏 24 行、大约 2 KB 的配置，要 2 秒多才能刷完。 改成 115200 之后每秒 11520 字节，同样的屏 0.2 秒。 差了 12 倍。

所以「用串口看日志很慢」不是错觉，是波特率的物理限制。 能改就改——但要注意：改了设备端，终端软件也要改，否则全是乱码。

四、安全上要砍掉两样

Telnet 与 HTTP 都是明文：在网络上抓包就能看到密码，而管理密码泄漏等于设备被接管。

今天的最低要求是 SSH 加 HTTPS，再加一条「管理网段限定源地址」——只允许运维网段访问管理口， 这样即使密码漏了也进不来。

还有一条容易被忘：管理面要与业务面隔离。03.06.09 讲的 VRF 就是干这个的。 业务网里的一台机器被攻破，不应该能看到管理网的路由。

五、动手 Demo：四种用户界面，各在什么时候用

这段列出六种管理界面的优缺点与适用场合， 再按「9600 与 115200 两种波特率」算刷一屏 2 KB 配置各需要多久。

for bps in (9600, 115200):
    P(u"  %d bps：每秒 %d 字节，一屏 2 KB 要 %.1f 秒。"
      % (bps, bps // 10, 2048.0 / (bps // 10)))

实跑输出：

--------------------------------------------------------------------
四种用户界面，各在什么时候用
--------------------------------------------------------------------
**路由器的管理界面有四种**，不是「选一个用」，是「各有各的场合」。

  界面                  优点                 缺点                   什么时候用
  ------------------------------------------------------------------------------------------
  Console（串口）       不依赖网络           必须到现场             设备起不来时唯一入口
  SSH                   加密、功能全         依赖网络与管理面       日常配置
  Telnet                兼容老设备           明文                   不该用
  HTTPS（Web）          直观                 功能不全、易被攻击     简单查看
  SNMP                  可批量、可监控       不能做复杂配置         集中监控
  NETCONF／RESTCONF     结构化、可自动化     设备支持不一           自动化运维

**「Console 是唯一可靠入口」这一条要记住**：设备配置错了 IP、把管理口 shutdown 了、
或者启动失败——**这时候只有 Console 能进去。**
**所以机房里的设备必须能物理接触到串口，或者接一台终端服务器。**

**算一下 Console 的传输时间**：默认波特率 9600，8N1，也就是每字节 10 位。

  9600 bps：每秒 960 字节。看一屏 24 行的配置（约 2 KB）要 2.1 秒。
  115200 bps：每秒 11520 字节。看一屏 24 行的配置（约 2 KB）要 0.2 秒。

**9600 下一屏要 2 秒多**，这就是为什么「用串口看日志」感觉很慢。**能改就改成 115200**，快 12 倍。

**安全上要砍掉两样**：**Telnet 与 HTTP**。它们都是明文，**在网络上抓包就能看到密码。**
**今天的最低要求是 SSH ＋ HTTPS，最好再加一条「管理网段限定源地址」。**

「每秒 960 字节」这个换算要会：8N1 是每字节 10 位， 所以波特率除以 10 就是字节速率。这条换算在算串口、算低速链路时天天用。

表里「必须到现场」这四个字是 Console 唯一的缺点，也是它的全部价值： 正因为不依赖网络，它才在断网时可用。 这两个性质是同一件事的两面。

「砍掉 Telnet 与 HTTP」这一条在很多单位还做不到：因为老设备只支持 Telnet。 折中办法是「限定源地址 + 单独管理网段」， 把明文的风险限制在一个可控的范围里，而不是放着不管。

30 秒实验

  1. 找一根 Console 线，看看你手上的设备有没有 CONSOLE 口。
  2. 查一下设备上开了哪些管理方式，有没有 Telnet。
  3. 想一想：如果设备配错了 IP，你怎么进去改？

常见误区

  1. 以为 SSH 能替代 Console。设备起不来时 SSH 不存在。
  2. 以为 Web 界面功能最全。多数设备的 Web 只能做基础配置。
  3. 以为串口慢是设备性能差。是 9600 波特率的物理限制。
自测三问（点开对答案） 1. 为什么 Console 不可替代？ —— 它不依赖网络与管理面，设备配错 IP 或起不来时是唯一入口。 2. 9600 波特率下每秒能传多少字节？ —— 约 960 字节，因为 8N1 每字节占 10 位。 3. 管理面安全的最低三条要求是什么？ —— 用 SSH 与 HTTPS、限定源地址、管理面与业务面隔离。

下一节：进去之后第一件事是看日志。

相关笔记