326 lines
17 KiB
Typst
326 lines
17 KiB
Typst
#import "labtemplate.typ": *
|
||
#show: nudtlabpaper.with(title: "双向转发检测（BFD）配置",
|
||
author: "程景愉",
|
||
id: "202302723005",
|
||
training_type: "无军籍",
|
||
grade: "2023",
|
||
major: "网络工程",
|
||
department: "计算机学院",
|
||
advisor: "张军",
|
||
jobtitle: "工程师",
|
||
lab: "306-707",
|
||
date: "2025.09.24",
|
||
header_str: "《网络工程》实验报告",
|
||
)
|
||
#set page(header: [
|
||
#set par(spacing: 6pt)
|
||
#align(center)[#text(size: 11pt)[《网络工程》实验报告]]
|
||
#v(-0.3em)
|
||
#line(length: 100%, stroke: (thickness: 1pt))
|
||
],)
|
||
|
||
#show heading: it => box(width: 100%)[
|
||
#v(0.50em)
|
||
#set text(font: hei)
|
||
#it.body
|
||
]
|
||
|
||
#outline(title: "目录",depth: 3, indent: 1em)
|
||
#pagebreak()
|
||
#outline(
|
||
title: [图目录],
|
||
target: figure.where(kind: image),
|
||
)
|
||
|
||
#show heading: it => box(width: 100%)[
|
||
#v(0.50em)
|
||
#set text(font: hei)
|
||
#counter(heading).display()
|
||
// #h(0.5em)
|
||
#it.body
|
||
]
|
||
#set enum(indent: 0.5em,body-indent: 0.5em,)
|
||
#pagebreak()
|
||
|
||
= 实验目的
|
||
#para[
|
||
通过配置双向转发检测（BFD）协议与OSPF联动，验证其在网络故障检测和快速切换中的应用效果。具体目标如下：
|
||
]
|
||
+ 熟悉BFD协议的基本原理、会话管理方式及检测机制。
|
||
+ 掌握BFD与OSPF联动的配置方法，提高路由协议的故障检测速度。
|
||
+ 测试网络在链路故障情况下的切换性能，验证BFD配置的实际效果，提升网络可靠性和故障恢复能力。
|
||
= 实验原理
|
||
== BFD协议简介
|
||
=== 定义
|
||
#para[
|
||
双向转发检测BFD（Bidirectional Forwarding Detection）是一种全网统一的检测机制，用于快速检测、监控网络中链路或者IP路由的转发连通状况。
|
||
]
|
||
=== 目的
|
||
#para[
|
||
为了减小设备故障对业务的影响，提高网络的可靠性，网络设备需要能够尽快检测到与相邻设备间的通信故障，以便及时采取措施，保证业务继续进行。在现有网络中，有些链路通常通过硬件检测信号，如SDH告警，检测链路故障，但并不是所有的介质都能够提供硬件检测。此时，应用就要依靠上层协议自身的Hello报文机制来进行故障检测。上层协议的检测时间都在1秒以上，这样的故障检测时间对某些应用来说是不能容忍的。在三层网络中，Hello报文检测机制无法针对所有路由来检测故障，如：静态路由。这对系统间互联互通定位故障造成困难。
|
||
]
|
||
#para[
|
||
BFD协议就是在这种背景下产生的，BFD提供了一个通用的标准化的介质无关和协议无关的快速故障检测机制。具有以下优点：
|
||
]
|
||
- 对相邻转发引擎之间的通道提供轻负荷、快速故障检测。这些故障包括接口、数据链路，甚至有可能是转发引擎本身。
|
||
- 用单一的机制对任何介质、任何协议层进行实时检测。
|
||
=== 受益
|
||
#para[
|
||
BFD可以实现快速检测并监控网络中链路或IP路由的转发连通状态，改善网络性能。相邻系统之间通过快速检测发现通信故障，可以更快地帮助用户建立起备份通道以便恢复通信，保证网络可靠性。
|
||
]
|
||
== BFD协议工作原理
|
||
=== 原理简介
|
||
#para[
|
||
BFD在两台网络设备上建立会话，用来检测网络设备间的双向转发路径，为上层应用服务。BFD本身并没有邻居发现机制，而是靠被服务的上层应用通知其邻居信息以建立会话。会话建立后会周期性地快速发送BFD报文，如果在检测时间内没有收到BFD报文则认为该双向转发路径发生了故障，通知被服务的上层应用进行相应的处理。下面以OSPF与BFD联动为例，简单介绍会话工作流程。
|
||
]
|
||
#figure(image("pic1.png",fit:"stretch",width: 60%),caption: "BFD会话建立流程图")<pic1>
|
||
@pic1 是一个简单的网络组网，两台设备上同时配置了OSPF与BFD，BFD会话建立过程如下所示：
|
||
+ OSPF通过自己的Hello机制发现邻居并建立连接；
|
||
+ OSPF在建立了新的邻居关系后，将邻居信息（包括目的地址和源地址等）通告给BFD；
|
||
+ BFD根据收到的邻居信息建立会话；
|
||
+ 会话建立以后，BFD开始检测链路故障，并做出快速反应。
|
||
#para[
|
||
BFD故障发现处理流程如下：
|
||
]
|
||
#figure(image("pic2.png",fit:"stretch",width: 60%),caption: "BFD故障发现处理流程图")<pic2>
|
||
如@pic2 所示：
|
||
+ 被检测链路出现故障；
|
||
+ BFD快速检测到链路故障，BFD会话状态变为Down；
|
||
+ BFD通知本地OSPF进程BFD邻居不可达；
|
||
+ 本地OSPF进程中断OSPF邻居关系。
|
||
=== BFD会话建立方式
|
||
#para[
|
||
BFD会话的建立有两种方式，即静态建立BFD会话和动态建立BFD会话。静态和动态创建BFD会话的主要区别在于本地标识符（Local Discriminator）和远端标识符（Remote Discriminator）的配置方式不同。BFD通过控制报文中的Local Discriminator和Remote Discriminator区分不同的会话。
|
||
]
|
||
+ 静态建立BFD会话。
|
||
静态建立BFD会话是指通过命令行手工配置BFD会话参数，包括配置本地标识符和远端标识符等，然后手工下发BFD会话建立请求。
|
||
|
||
+ 动态建立BFD会话。
|
||
动态建立BFD会话时，系统对本地标识符和远端标识符的处理方式如下：
|
||
- 动态分配本地标识符：
|
||
当应用程序触发动态创建BFD会话时，系统分配属于动态会话标识符区域的值作为BFD会话的本地标识符。然后向对端发送Remote Discriminator的值为0的BFD控制报文，进行会话协商。
|
||
- 自学习远端标识符：
|
||
当BFD会话的一端收到Remote Discriminator的值为0的BFD控制报文时，判断该报文是否与本地BFD会话匹配，如果匹配，则学习接收到的BFD报文中Local Discriminator的值，获取远端标识符。
|
||
=== BFD会话管理
|
||
#para[
|
||
BFD会话有四种状态：Down、Init、Up和AdminDown。会话状态变化通过BFD报文的State字段传递，系统根据自己本地的会话状态和接收到的对端BFD报文驱动状态改变。BFD状态机的建立和拆除都采用三次握手机制，以确保两端系统都能知道状态的变化。以BFD会话建立为例，简单介绍状态机的迁移过程。
|
||
]
|
||
#figure(image("pic3.png",fit:"stretch",width: 60%),caption: "BFD状态机迁移图")<pic3>
|
||
如@pic3 所示：
|
||
+ SwitchA和SwitchB各自启动BFD状态机，初始状态为Down，发送状态为Down的BFD报文。对于静态配置BFD会话，报文中的Remote Discriminator的值是用户指定的；对于动态创建BFD会话，Remote Discriminator的值是0；
|
||
+ SwitchB收到状态为Down的BFD报文后，状态切换至Init，并发送状态为Init的BFD报文；
|
||
+ SwitchB本地BFD状态为Init后，不再处理接收到的状态为Down的报文；
|
||
+ SwitchA的BFD状态变化同SwitchB；
|
||
+ SwitchB收到状态为Init的BFD报文后，本地状态切换至Up；
|
||
+ SwitchA的BFD状态变化同SwitchB。
|
||
=== BFD检测机制
|
||
#para[
|
||
BFD的检测机制是两个系统建立BFD会话，并沿它们之间的路径周期性发送BFD控制报文，如果一方在既定的时间内没有收到BFD控制报文，则认为路径上发生了故障。
|
||
]
|
||
#para[
|
||
BFD提供异步检测模式。在这种模式下，系统之间相互周期性地发送BFD控制报文，如果某个系统连续几个报文都没有接收到，就认为此BFD会话的状态是Down。
|
||
]
|
||
= 实验环境
|
||
== 实验背景
|
||
#para[
|
||
配置BFD与OSPF联动，凭借BFD协议的快速检测和快速切换功能，在交换机不灵时将线路自动切换到路由器上。
|
||
]
|
||
== 实验设备
|
||
#align(center)[#table(
|
||
columns: (auto, auto,auto),
|
||
rows:(2em,2em,3em),
|
||
inset: 10pt,
|
||
align: horizon+center,
|
||
table.header(
|
||
[*设备名称*], [*设备型号*], [*设备数量*]
|
||
),
|
||
"交换机", "华为S5735", "1",
|
||
"路由器", "华为AR6120-S", "3",
|
||
"PC", "联想启天M410
|
||
Windows 10", "2",
|
||
)]
|
||
#para[
|
||
另有网线若干，控制线1条。
|
||
]
|
||
= 实验步骤及结果
|
||
== 实验拓扑
|
||
#para[
|
||
按实验背景，绘制拓扑图如下：
|
||
]
|
||
#figure(image("拓扑.png",format: "png",fit:"stretch",width: 80%),caption: "实验拓扑图")
|
||
== 按照拓扑图接线
|
||
#para[
|
||
按照拓扑图接线
|
||
]
|
||
#figure(image("接线图1.jpg",format: "jpg",fit:"stretch",width: 55%),caption: "机柜正面接线图")<front>
|
||
#figure(image("接线图2.jpg",format: "jpg",fit:"stretch",width: 55%),caption: "机柜背面接线图")
|
||
== 配置基本网络
|
||
=== 配置PC
|
||
- 配置PC1的IP地址为`10.20.1.2/24`，网关为`10.20.1.1`；
|
||
- 配置PC2的IP地址为`10.30.1.2/24`，网关为`10.30.1.1`。
|
||
#para[
|
||
步骤简单，展示图略。
|
||
]
|
||
=== 配置路由器IP地址
|
||
#para[
|
||
按照拓扑图配置路由器的IP地址。
|
||
]
|
||
1. 配置Router_1路由器：
|
||
- 接口 `GE 0/0/0` 连接到 `LSW`，IP地址为 `10.1.0.101/24`。
|
||
- 接口 `GE 0/0/1` 连接到 `Router_2`，IP地址为 `10.10.0.101/24`。
|
||
- 接口 `GE 0/0/2` 连接到 `PC1`，IP地址为 `10.20.1.1/24`。
|
||
#figure(image("ar1ip1.jpg",format: "jpg",fit:"stretch",width: 60%),caption: "配置Router_1的IP地址(1)")
|
||
#figure(image("ar1ip2.jpg",format: "jpg",fit:"stretch",width: 60%),caption: "配置Router_1的IP地址(2)")
|
||
#figure(image("ar1ip3.jpg",format: "jpg",fit:"stretch",width: 60%),caption: "配置Router_1的IP地址(3)")
|
||
|
||
2. 配置Router_2路由器：
|
||
- 接口 `GE 0/0/0` 连接到 `Router_1`，IP地址为 `10.10.0.102/24`。
|
||
- 接口 `GE 0/0/1` 连接到 `Router_3`，IP地址为 `10.40.1.101/24`。
|
||
#figure(image("ar2ip.jpg",format: "jpg",fit:"stretch",width: 60%),caption: "配置Router_2的IP地址")
|
||
|
||
3. 配置Router_3路由器：
|
||
- 接口 `GE 0/0/0` 连接到 `LSW`，IP地址为 `10.1.0.102/24`。
|
||
- 接口 `GE 0/0/1` 连接到 `Router_2`，IP地址为 `10.40.1.102/24`。
|
||
- 接口 `GE 0/0/2` 连接到 `PC2`，IP地址为 `10.30.1.1/24`。
|
||
#figure(image("ar3ip.jpg",format: "jpg",fit:"stretch",width: 60%),caption: "配置Router_3的IP地址")
|
||
== 配置BFD与OSPF联动
|
||
#para[
|
||
本次实验使用BFD与OSPF联动，配置基于接口状态的单跳检测。
|
||
在Router_1上配置接口的BFD特性：
|
||
]
|
||
#figure(image("ar1g0_bfd.jpg",format: "jpg",fit:"stretch",width: 90%),caption: "在Router_1上配置接口的BFD特性")
|
||
#para[
|
||
配置`cost`值为1，提高主路径优先级：
|
||
]
|
||
#figure(image("ar1g0_cost.jpg",format: "jpg",fit:"stretch",width: 80%),caption: "配置Cost值")
|
||
#para[
|
||
配置BFD参数，使得能够快速切换。实验背景对于网络可靠性要求较高链路，可以配置减小BFD报文实际发送时间间隔：
|
||
]
|
||
#figure(image("ar1g0_bfd_args.jpg",format: "jpg",fit:"stretch",width: 90%),caption: "配置BFD参数")
|
||
#para[
|
||
在Router_3上的配置与Router_1类似。
|
||
]
|
||
#para[
|
||
在每个路由器上配置并使能OSPF的BFD功能（使用`bfd all-interfaces enable`）：
|
||
]
|
||
#figure(image("ar1ospf.jpg",format: "jpg",fit:"stretch",width: 70%),caption: "在Router_1上配置OSPF协议")
|
||
#figure(image("ar2ospf.jpg",format: "jpg",fit:"stretch",width: 70%),caption: "在Router_2上配置OSPF协议")
|
||
#figure(image("ar3ospf.jpg",format: "jpg",fit:"stretch",width: 70%),caption: "在Router_3上配置OSPF协议")
|
||
== 验证BFD配置
|
||
#para[
|
||
配置完成后，通过查看BFD会话状态和OSPF邻居状态，验证BFD配置是否生效；在交换机LSW上对端口执行`shutdown`来模拟链路故障，并在故障前、后进行主机之间的Ping测试和traceroute测试，验证BFD的快速检测和快速切换功能。
|
||
]
|
||
=== 查看状态
|
||
#para[
|
||
通过`display ospf peer`命令查看OSPF邻居状态（以Router_1为例）：
|
||
]
|
||
#figure(image("ar1peer.jpg",format: "jpg",fit:"stretch",width: 80%),caption: "查看OSPF邻居状态")
|
||
#para[
|
||
可以看到OSPF邻居状态为Full，说明OSPF配置生效。
|
||
通过`display bfd session`命令查看BFD会话状态：
|
||
]
|
||
#figure(image("ar1session.jpg",format: "jpg",fit:"stretch",width: 80%),caption: "查看BFD会话状态")
|
||
#para[
|
||
可以看到BFD会话状态为Up，说明BFD配置生效。
|
||
]
|
||
=== 模拟链路故障
|
||
#para[
|
||
首先在PC1上执行traceroute命令，查看PC1到PC2的路径：
|
||
]
|
||
#figure(image("before.jpg",format: "jpg",fit:"stretch",width: 50%),caption: "查看PC1到PC2的路径")
|
||
#para[
|
||
然后执行长ping：`ping -t 10.30.1.2`。
|
||
在长ping过程中，对交换机端口执行`shutdown`，模拟链路故障：
|
||
]
|
||
#figure(image("shutdown.jpg",format: "jpg",fit:"stretch",width: 50%),caption: "模拟链路故障")
|
||
#para[
|
||
查看PC1上的长ping是否中断：
|
||
]
|
||
#figure(image("cutoff.jpg",format: "jpg",fit:"stretch",width: 70%),caption: "查看PC1上的长ping")<pic10>
|
||
#para[
|
||
可以看到中间TTL发生了变化，即路径发生变化，从原来的经过2个路由器变为了经过3个路由器，但最后的结果中，丢包率为0。这说明Router_1通过BFD协议快速检测到故障，及时切换了线路。
|
||
查看PC1上的traceroute是否发生变化：
|
||
]
|
||
#figure(image("after.jpg",format: "jpg",fit:"stretch",width: 60%),caption: "再次查看PC1到PC2的路径")<pic11>
|
||
#para[
|
||
可以看到路径发生了变化，从原来的直接到Router_2切换为经过Router_3再到Router_2。
|
||
]
|
||
#para[
|
||
在`shutdown`状态下，在PC1上再次执行长ping，观察链路的恢复。在交换机上执行`undo shutdown`，恢复链路。查看PC1上的长ping是否恢复：
|
||
]
|
||
#figure(image("undocutoff.jpg",format: "jpg",fit:"stretch",width: 70%),caption: "再次查看PC1上的长ping")<pic12>
|
||
#para[
|
||
可以看到在链路恢复后，长ping恢复正常，丢包率为0。
|
||
至此，BFD配置验证完成。
|
||
]
|
||
|
||
= 思考题
|
||
== 创建BFD会话中本地标识符和远端标识符可以一样吗？
|
||
#para[
|
||
答案：可以，但不推荐。
|
||
]
|
||
#para[
|
||
原因：
|
||
BFD会话的本地标识符和远端标识符理论上可以相同，但为了避免标识冲突和排查问题的复杂性，通常采用不同的值。标识符的主要作用是区分不同的会话，而相同标识符可能在某些特殊情况下引发识别问题。推荐遵循标准，确保标识符的唯一性。
|
||
]
|
||
== BFD与浮动路由联动前，PC1和PC2不能通信，是因为浮动路由机制不起作用了吗？如果不是，请说明原因。
|
||
#para[
|
||
答案：不是浮动路由机制不起作用，而是因为主链路未出现故障，浮动路由没有被触发。
|
||
]
|
||
#para[
|
||
分析：
|
||
浮动路由是备份路由，其优先级低于主路由，只有在主路由不可用时才生效。
|
||
如果主链路正常，路由表中只会使用主路由，备份路由（浮动路由）不会被安装到路由表中。因此，PC1和PC2不能通信的原因可能是主路由或其对应链路上存在其他问题（例如ACL限制或配置错误），而非浮动路由机制本身的问题。
|
||
]
|
||
== AR1和AR2之间有2条线路，一条主，一条辅。配置了BFD后，主链路断开。当链路恢复连通后，路由器会立刻启用主的路由吗？请分析原因。
|
||
#para[
|
||
答案：不一定会立刻启用主路由，取决于动态路由协议的收敛时间和BFD的状态恢复时间。
|
||
]
|
||
#para[
|
||
分析：
|
||
当主链路恢复连通时，BFD会检测到链路恢复并通知动态路由协议（如OSPF、BGP等）。
|
||
动态路由协议需要重新将主路由添加到路由表中，这通常涉及路由重计算或邻居关系的重新建立。
|
||
如果主路由的优先级高于辅路由，则会最终启用主路由。但启用的时间可能有短暂延迟，具体取决于：
|
||
]
|
||
1. BFD检测到链路恢复的时间间隔。
|
||
2. 动态路由协议的收敛时间。
|
||
== 如何配置BFD配置成单臂回声模式，该模式是单跳还是多跳？
|
||
#para[
|
||
答案：单臂回声模式是单跳模式。
|
||
]
|
||
#para[
|
||
原因：
|
||
单臂回声模式是一种轻量级的BFD运行模式，仅由本地设备发送BFD控制报文，而对端仅响应回显报文。这种模式通常用于单跳链路的简单连通性检测。
|
||
配置：
|
||
]
|
||
```
|
||
system-view
|
||
interface GigabitEthernet0/0/1
|
||
bfd echo enable
|
||
```
|
||
|
||
= 实验总结
|
||
== 内容总结
|
||
#para[
|
||
本次实验通过配置双向转发检测（BFD）协议与OSPF联动，验证了其在快速检测链路故障、实现快速切换方面的功能。实验内容包括网络设备的基础配置、BFD会话的建立与管理、以及链路故障的模拟与恢复。通过测试，成功实现了在故障发生时网络能够在极短时间内自动切换至备用路径，显著提高了网络的可靠性和稳定性。
|
||
]
|
||
== 心得感悟
|
||
#para[
|
||
通过此次实验，我更加深刻地理解了BFD协议的原理及其在实际网络环境中的重要性。BFD提供了一种高效的故障检测机制，能够弥补传统Hello机制检测时间较长的不足，对保障关键业务的持续运行具有重要意义。实验还让我意识到网络设计与配置中的细节对整体性能和可靠性的重要影响。熟练掌握这些技术，不仅提高了我的网络工程实践能力，也让我对网络高可用性设计有了更深层次的认识。
|
||
]
|
||
|
||
#show heading: it => box(width: 100%)[
|
||
#v(0.50em)
|
||
#set text(font: hei)
|
||
// #counter(heading).display()
|
||
// #h(0.5em)
|
||
#it.body
|
||
]
|
||
// #pagebreak()
|
||
#bibliography("ref.yml",full: true,title: "参考文献",style:"gb-7714-2015-numeric")
|
||
|
||
/*
|
||
根据这个网站的格式示范https://github.com/typst/hayagriva/blob/main/docs/file-format.md
|
||
为这个网页生成.yml文件
|
||
https://blog.csdn.net/jxjdhdnd/article/details/138009187
|
||
*/ |