H3C SE 教程笔记——构建H3C高性

第5篇    IP组播

第18章    IP组播概述

    IP组播技术实现了数据在IP网络中点到多点的高效传送，能够节约大量网络带宽、降低网络负载。通过IP组播技术可以方便地在IP网络之上提供一些增值业务，包括在线直播、网络电视、远程教育、远程医疗、IP监控、实时视频会议等对带宽和数据交互的实时性要求较高的信息服务。

18.2    组播介绍

    在IP网络中，节点之间的通信通常采用点到点的方式，即在同一时刻，一个发送源只能发送数据给一个接收者，这种通信方式成为单播。单播一起简洁、实用的通信方式在IP网络中得到广泛使用。

    对于某些网络应用如多媒体会议、IP视频监控，需要发送源将数据发送给网络中的部分接收者，不是一个也不是全部，这种传输方式称为点到多点的传输。

    采用单播实现点到多点的传输时，发送源需要向每一个接收者单独发送一份数据，当接收者数量增加时，发送源复制数据的工作负荷也会成比例增加。此外，由于同一个时刻发送源只能发送数据给一个接收者，当接收者数量巨大时，一些接收者接收数据的延时会大大增加，这对于一些延时敏感的应用如多媒体会议、视频监控等，是不可接受的。

    从图中还可以看到，链路上可能会传输大量目的地址不同但是内容完全相同报文，这些内容相同的报文占用了大量的链路带宽，降低了链路带宽的有效利用率。

    通过广播方式也可以实现网络中多个接收者收到发送源发送的数据，并且不管接收者数目是多少，发送源只需要发送一份广播数据。

    相对于单播，广播方式减少了发送源的处理，降低了发送源的负荷。但是采用广播方式，网络中的所有主机都会收到广播数据，而不管其是否需要接收，这样不仅数据的安全性得不到保障，而且造成网络中信息的泛滥，浪费大量带宽资源。

    单播和广播均不能以最小的网络开销实现数据的单点发送、多点接收，IP组播（以下简称组播）技术的出现解决了这个问题。

    组播指发送源将产生的单一IP数据包通过网络发送给一组特定接收者的网络传输方式。组播结合了单播和广播的优点，在进行点到多点传输时，发送源不需要关心接收者的数目，仅需要发送一份报文；路由器仅关心接口下是否有接收者，同样不需要关心接收者的数量，所以在路由器之间的链路上也仅传送一份报文。

    和单播相比，组播减轻了发送源的负担，并且提高了链路的有效利用率。此外，发送源可以同时发送报文给多个接收者，可以满足延时应用的需求。

    和广播相比，组播方式下路由器仅在有接收者的接口复制报文，报文最终传递给接收者而非网络中的所有主机，可以节省大量网络带宽。另外，广播只能在同一网段中进行，而组播可以实现跨网段的传输。

    利用组播技术可以方便地提供一些新的增值业务，包括在线直播、网络电视、远程教育、远程医疗、网络电台、实时视频会议等对带宽和数据交互的实时性要求较高的信息服务。

    从组播和单播、广播的对比可以总结得出组播的优点：

    ·组播可以增强报文发送效率，控制网络流量，减少服务器和CPU的负载；

    ·组播可以优化网络性能，消除流量冗余；

    ·组播可以适应分布式应用，当接收者数量变化时，网络流量的波动很平稳。

    由于组播应用基于UDP而非TCP，这就决定了组播应用存在UDP相应的缺点：

    ·组播数据基于Best Effort发送，无法保证语音、视频等应用的优先传输，当报文丢失时，采用应用层的重传机制无法保证实时应用的低延时需求；

    ·不提供拥塞控制机制，当网络出现拥塞时，无法为高优先级的应用保留带宽；

    ·无法实现组播数据包重复检测，当网络拓扑发生变化时，接收者可能会收到重复的报文，需要应用层去剔除；

    ·无法纠正组播数据包乱序到达的问题。

    组播技术主要应用在多媒体会议、IP视频监控、实时数据组播、游戏和仿真等方面。

    多媒体会议是最早的组播应用。多媒体会议的工具最先在UNIX环境下被开发出来，这些工具允许通过组播实现多对多的多媒体会议。除多媒体工具外，还有基于UNIX的白板工具被开发出来，用于用户共享公共的电子白板，适合网络教学。

    IP视频监控是近年来发展迅猛的安防应用，IP视频监控系统中摄像头发送模拟视音频信号给编码器，编码器进行模/数转换、编码压缩、IP封装后将报文发送到IP网络。×××收到IP报文后进行解封装、解码、解压缩、数/模转换，然后将模拟视音频流传送到电视墙显示。视频客户端也可以接收IP报文进行软解码本地播放。

    在IP视频监控中，编码器可以通过组播方式发送监控视频，组播方式可以极大的降低编码器端的负荷，减少网络中的冗余视音频流，并且可以满足实时监控的需求。

    实时数据传送是组播很受欢迎的一个应用领域，例如股票、金融数据传送、实时足球播放、现场演唱会点播等。

    组播还适合于网络游戏和仿真应用。如果采用单播方式，游戏玩家之间需要建立点到点的连接，对于PC机或服务器的处理能力而言是N平方数量级的负荷。当玩家数量上升，PC机或服务器将不堪重负。采用组播方式，某一个玩家不需要和其他每一个玩家都建立连接，例如玩家A要发送数据给其他玩家，其他玩家仅需要加入组播组A，则玩家A发送到组播组A的数据所有其他玩家都可以收到。

18.3    组播技术体系架构

    组播的实现机制较单播复杂，要实现组播，首先需要解决如下几个问题：

    ·组播的接收者是数目不定的一组接收者，无法像单播一样使用主机IP地址来进行标识，所以首先要解决如何在网络标识一组接收者。

    ·如果实现了对组的标识，还需要解决接收者如何加入和离开这个组，路由设备又如何维护组成员信息。

    ·组播接收者可能分散在网络中的任何角落，那么组播源和组播接收者之间的转发路径基于什么模型，组播数据如何在路径上转发。

    ·组播数据转发路径如何建立和维护。

    上述技术需求通过组播架构中的一些重要机制来实现，包括：组播地址、组播组管理协议、组播分发树模型、组播转发机制和组播路由协议。

    组播通信中使用组播地址来标识一组接收者，使用组播地址标识的接收者集合称为组播组。

    IANA（Internet Assigned Numbers Authority，因特网编号分配委员会）将D类地址空间分配给IPv4组播使用，地址范围为224.0.0.0到239.255.255.255，组播地址的分类和具体包含如下：

    ·224.0.0.0-224.0.1.255，协议预留组播地址，除224.0.0.0保留不做分配外，其它地址供路由协议、拓扑查找和协议维护等使用。

    ·224.0.2.0-238.255.255.255，用户组地址，全网范围内有效。

    ·239.0.0.0-239.255.255.255，本地管理组地址，仅在本地管理域内有效。

    组播地址解决了IP报文在网络层寻址的问题，但通信最终还要依赖于数据链路层和物理层，因此和单播一样，组播也需要考虑数据在链路层如何寻址。

    以太网传输单播IP报文的时候，目的MAC地址使用的是接收者的MAC地址。由于组播目的地不再是一个具体的接收者，而是一个成员不确定的组，所以在链路层需要使用特定的组播MAC地址来标识一组接收者。

    IANA定义IPv4组播MAC地址格式为01-00-5E-XX-XX-XX。

    组播MAC地址中高24位固定为0x01005E，第25位为0，低23位来自于组播IP地址的低23位。

    由于组播IP地址的高4位是1110，代表组播标识，而低28位中只有23位被映射到组播MAC地址，这样组播地址中就有5位信息丢失。于是，就有32个组播IP地址映射到了同一个组播MAC地址上，因此在二层处理过程中，设备可能要接收一些本组以外的组播数据，而这些多余的组播数据就需要设备的上层进行过滤了。

    例如组播IP地址为228.128.128.128，其对应的组播MAC地址为01-00-5E-00-80-80，组播IP地址为229.128.128.128，其对应的组播MAC地址仍然为01-00-5E-00-80-80。

    解决了如何标志组播组的问题，还需要考虑接收者怎样加入组播组，如何维护组播组以及由谁来维护组播组等问题。在组播架构中使用组播组管理协议来实现上述需求。

    组播组管理协议是运行于主机和路由器之间的协议。主机通过组播组管理协议通知路由器加入或离开某个组播组；路由器通过组播组管理协议响应主机加入请求，建立相应的组播表项，并通过查询消息维护组播组信息。

    常用的组播组管理协议为IGMP（Internet Group Managerment Protocol，因特网组管理协议）。

    在单播通信中，发送源和接收者之间的路径是点到点的一条线，起点为发送源，目的地为一个接收者，该路径由单播路由协议建立。

    在组播中，目的地是数目不定的一组接收者，这就决定了组播报文转发路径和单播不同。

    组播转发路径基于树形结构，称为组播分发树，接收者位于树形结构的叶子处，组播分发树由组播路由协议建立。

    根据组播分发树树根位置的不同，组播分发树模型分为最短路径树（Shortest Path Tree，简称SPT）模型和共享树（Rendezvous Point Tree，简称RPT）模型。

    SPT树根为发送源，因此SPT也称为“源”树，其从发送源到每一个接收者的路径都是最优的。

    RPT模型树根为网络中的某一台设备，称为汇聚点，从发送源到接收者的组播数据必须首先经过汇聚点，然后再由汇聚点发送到每一个接收者，因此RPT模型中，从发送源到接收者之间的路径不一定是最优路径。

    在单播通信中，IP报文转发的依据是报文的目的IP地址，目的IP地址在网络中唯一的标识了一台主机，网络中的路由器收到单播IP报文后只需要通过目的IP地址查找单播路由表，确定报文对应的下一跳地址，得出报文的出接口，然后将报文从该出接口发出即可。沿途的每一台路由器都进行同样的操作，即可保证将报文准确无误的送到目的地，并且通过选择最优路径，可以消除网络中的路径环路。

    组播不能简单的通过查看报文的目的IP地址就得到报文传送的最优路径以及对应的出接口，因为组播报文的目的地址不是一台明确的主机，有可能路由器每一个接口都存在接收者。

    组播采用逆向路径转发的方式，判断组播报文是否从指向组播分发树树根的最短路径到达，只有来自最优路径的组播报文才会被转发，来自于最优路径的组播报文会被丢弃。沿途每一台组播路由器都进行同样的操作，可以保证报文从组播源到组播组中的每一个接收者所经过的路径都是最优的，并且可以消除组播路径环路。

    综上所述，单播转发的时候主要关心报文往哪里去了，而组播转发的时候主要关心报文从哪里来。

    组播路由协议运行在三层组播设备之间，用于建立和维护组播路由，并正确、高效地转发组播数据包。组播路由协议建立了从一个数据源端到多个接收端的无环（loop-free）数据传输路径，即组播分发树。

    组播路由协议根据作用范围组可以分为域内组播路由协议和域间组播路由协议，其中域内组播路由协议主要包括DVMRP（Distance Vector Multicast Routing Protocol，距离矢量组播路由协议）、MOSPF（Multicast Extensions to OSPF，组播OSPF协议）和PIM（Protocol Independent Multicast，协议无关组播），域间组播路由协议包括PIM DM（Protocol Independent Multicast-Dense Mode，协议无关组播-密集模式）、DVMRP、MOSPF，基于RPT的组播路由协议包括PIM SM（Protocol Independent Multicast-Sparse Mode，协议无关组播-稀疏模式）。

    组播协议主要包含主机和路由器之间的协议，路由器和路由器之间的协议，以及组播域之间的协议。

    主机和路由器之间的协议即组播组管理协议，IPv4中通常使用IGMP。通过IGMP，路由器可以了解在本地网段中，哪些组播组存在接收者，并维护组成员信息。

    路由器和路由器之间的协议为组播路由协议，常用的组播路由协议为PIM。通过PIM，可以将组成员信息扩散到整个网络，从而建立送发送源到接收者之间的组播分发树。

    组播域的边界通常为单播域的边界，由于域之间组播路由信息有可能无法直接交互，导致接收者无法跨域接收组播数据，此时需要在域之间运行域间组播路由协议，解决域间组播通信的问题，常用的域间组播路由协议为MSDP。

18.4    组播模型

    根据接收者对组播源处理源方式的不同，组播模型分为以下两类：

    ·ASM（Any-Source Multicast，任意信源组播）模型：在ASM模型中，组播接收者无法指定组播源，任意组播源发送到同一个组播组的数据，都会被网络设备传送到组播接收者。

    ·SSM（Source-Specific Multicast，指定信源组播）模型：在现实生活中，用户可能只对某些组播源发送的组播信息感兴趣，而不愿接受其它源发送的信息。SSM模型为用户提供了一种能够在客户端指定组播源的传输服务。

    SSM模型与ASM模型的根本区别在于：SSM模型中的接收者已经通过其它手段预先知道了组播源的具体位置。

    ASM模型中，当接收者通过组播管理协议加入某组播组时，并不区分组播数据的发送源。

    上图中，发送源A发送组播数据，源地址1.1.1.1，目的组播地址为228.1.1.1；发送源B发送组播数据，源地址为1.1.1.2，目的组播地址也为228.1.1.1。

    主机A、C希望接收发送源A发送的组播数据，主机B希望接收发送源B发送的组播数据，因此主机A、B、C通过组播管理协议加入了组播组228.1.1.1。但由于ASM模型无法指定发送源，此后，路由器会将发送源A和发送源B发送的组播数据均发送到主机A、B、C。

    ASM模型无法满足主机接收指定发送的组播数据，如果主机收到多分来自不同发送源的相同组播组的数据，需要上层应用进行区分。

    和ASM模型不同，在SSM模型中接收者指定组播组的同时还可以指定发送源。

    例如，主机A和主机C要求接收发送源A发送的组播地址为228.1.1.1的组播数据，则仅有源地址为1.1.1.1，目的地址为228.1.1.1的组播数据会发送到主机A和主机C，发送源B发送的组播数据虽然组播地址也为228.1.1.1的组播数据会发送到主机A和主机C，发送源B发送的组播数据虽然组播地址也为228.1.1.1，但是由于源地址不是主机A和主机C所指定的，因此发送源B发送的组播报文不会被主机A和主机C接收。

    同样，主机B指定接收源地址为1.1.1.2，目的地址为228.1.1.1的组播数据，则仅有发送源B发送的组播报文会被主机B接收。

第19章    组播组管理协议

    组播组管理协议运行在主机和与其直接相连的三层组播设备之间。常用的组播组管理协议为IGMP，该协议规定了主机与三层组播设备之间建立和维护组播组成员关系的机制。

    在实际组播应用中，通常还需要二层组播协议来配置组播组管理协议的工作。二层组播协议包含IGMP Snooping（IGMP窥探）和组播VLAN。通过IGMP Snooping可以解决组播报文在链路层广播的问题，通过组播VLAN可以节省网络带宽，降低三层设备的负担。

19.2    组播组管理协议概述

    组播组管理协议是运行于主机和路由器之间的协议。组播组管理协议的工作机制包含：成员加入和离开组播组、路由器维护组播组、查询器选举机制以及成员报告抑制机制。

    组播路由器周期性的发送查询报文，询问网段上是否有组播接收者。如果网段上有主机希望接收某个组播组的数据，则主机会向路由器回复成员报告报文，报告自己想要接收哪个组播组的数据。路由器收到主机发送的成员报告报文后，会为主机请求加入的组播组建立一个表项，表示该组播组在该网段有成员。

    当主机需要接收某个组的数据时，也可以不必等待路由器发送查询报文，而直接发送成员报文加入某个组播组。同样，路由器收到成员报告报文后，会更新组播组信息。

    当主机不再需要接收某个组播组的数据时，主机可以发送离开消息通知路由器离开该组播组，路由器会通过查询机制判断网段上该组播组是否有其他成员存在。如果还有其他成员存在，则路由器继续维护该组播组，如果没有成员存在，路由器会将该组播组信息删除，此后，路由器不再将该组播组的数据转发到该网段。

    当局域网网段上有多台路由器时，网段上可能会出现重复的查询报文，也可能会有重复的组播数据发送到该网段，此时需要在这些路由器之间选举某台路由器负责该网段组播数据的转发以及组播组的维护，这台路由器即为该网段的查询器。查询器选举结束后，网段上只有查询器会发送查询报文，其他路由器仅在查询器发生故障，且经过新一轮的选举成为新的查询器后，才会发送查询报文。

    对于某个网段，路由器仅需要知道是否有组播组成员存在，只要某个组播组有成员，路由器就会为该组播组维护相应信息，并将组播数据转发到该网段。路由器不需要确切的知道组播组在该网段有哪些组成员。因此如果一个网段有多台主机想要接收同一组播组的数据，只需要有一台主机发送成员报文报文即可，这就需要一种机制来抑制网段上同一个组播组的其他主机发送成员报告报文，这个机制就是成员报告抑制机制。

    当主机需要发送成员报告报文时，首先会等待一段随机的延时。如果在这段延时期间，主机收到了其他主机发送的成员报告报文，并且和自身要求加入的组播组信息相同，则该主机会取消自身成员报告报文的发送。如果在延时期间没有收到要求加入相同组播组的成员报告报文，则主机会正常发送成员报告报文。通过成员报告抑制机制，可以减少网段上重复成员报告报文的发送。

    组播组管理协议不负责通知主机加入哪些组播组，这是由主机上层应用决定的，组播组管理协议也不负责报文在路由器之间的转发，这由组播路由协议实现。

    IPv4常用的组播组管理协议为IGMP。到目前为止，IGMP有三个版本：

    ·IGMPv1在RFC 1112中定义

    ·IGMPv2在RFC 2236中定义

    ·IGMPv3在RFC 3376中定义

    IGMPv1定义了基本的查询和成员报告过程，IGMPv2在此基础上添加了组成员快速离开机制和查询器选举机制，IGMPv3又在IGMPv2的基础上增加了指定组源的功能。

    所有版本的IGMP都支持ASM模型；IGMPv3可以支持SSM模型。

19.3    IGMPv2

    IGMP查询器RTA周期性地以组播方式向本地网段内的所有主机发送IGMP General Query报文，目的地址为224.0.0.1，TTL为1。

    收到General Query报文后，由于主机A和主机B希望接收组播组228.1.1.1的数据，所以会对General Query报文进行响应。为了防止Membership Report报文发生冲突，主机A和主机B会等待一段时间后，才会发送Membership Report报文，延迟时间为[0，Max RepsTime]之间的一个随机值，Max Reps Time为最大响应延时，由路由器在General Query报文中发布。

    假设主机B延迟时间大于主机A的延迟时间，则主机A会首先发送Membership Report报文，目的地址为主机A要加入的组播组地址228.1.1.1。主机B收到主机A发送的Membership Report报文后，经过判断发现是关于同一个组228.1.1.1的Membership Report报文，则主机B会取消自己Membership Report报文的发送，从而减少了本地网段的信息流量。

    与此同时，由于主机C关注的组播组228.2.2.2，所以它仍将会发送关于组播组228.2.2.2的Membership Report报文，以向RTA宣告其属于组播组228.2.2.2。

    当然，如果主机有新的组播接收需求，可以主动向RTA发送Membership Report报文，而不必等待RTA周期性的发送General Query报文。从而节省了主机加入某组播组的时间。

    经过以上的查询和响应的过程，RTA了解到本地网段中有组228.1.1.1和组228.2.2.2的成员，于是创建组播转发表项（*,228.1.1.1）和（*,228.2.2.2），作为组播数据的转发依据，其中*代表任意组播源。

    组播源转发表还包含组播报文的入接口和组播报文的出接口列表等信息，用于指导组播报文在本地路由器的转发，此时RTA会将连接主机A、B、C的接口加入到对应组播组的出接口列表中。

    当由组播源发往228.1.1.1或228.2.2.2的组播报文到达RTA时，由于RTA上存在（*，228.1.1.1）和（*，228.2.2.2）组播转发项，于是将该组播报文会根据出接口信息转发到本地网段，接收者主机便能收到该组播数据了。

    在IGMPv2中，当一个主机离开某组播组时会向本地网段向本地网段内的所有组播路由器发送Leave Group报文，目的地址为224.0.0.2，报文中包含要离开的组播地址信息。

    图中主机A和主机C要分别离开组播组228.1.1.1和229.2.2.2，则会向RTA发送Leave Group报文。

    当IGMP查询器RTA收到Leave Group报文后，会发送另外一种查询报文——Group-Specific Query报文，用于确认该组播组在网段内是否还有成员存在。Group-Specific Query报文的目的地址为所要查询的指定组播组地址。

    由于主机B仍然需要接受组播组228.1.1.1的数据，所以主机B收到Group-Specific Query报文后，会在[0,Max Reps Time]时间内回复Membership Report报文。

    RTA在最大响应时间内收到了主机B的Membership Report报文，认为组播组228.1.1.1仍然有接收者，所以继续维护该组播组。由于主机C离开后，网段内不再有组播组228.2.2.2的成员，所以在最大响应时间内RTA无法收到关于组播组228.2.2.2的Membership Report报文，RTA将删除组播组228.2.2.2的表项，此后不会再将目的地址为228.2.2.2的报文发送到该网段。

    在IGMPv1中没有定义查询器选举机制，当某共享网段上存在多个组播路由器时，需要通过组播路由协议（如PIM）选举的DR（Designate Router，指定路由器）充当查询器。

    在IGMPv2中，增加了独立的查询器选举机制，其选举过程如下：

    ·所有IGMPv2路由器在初始时都认为自己是查询器，并向本地网段内的所有主机和路由器发送IGMP General Query报文，目的地址为224.0.0.1。

    ·本地网段中的其它IGMPv2路由器在收到该报文后，将报文的源IP地址与自己的接口地址作比较。通过比较，IP地址最小的路由器将成为本网段的查询器，其它路由器成为非查询器（Non-Querier）。

    ·所有非查询器上都会启动一个定时器，在该定时器超时前，如果收到了来自查询器的IGMP查询报文，则重置该定时器；否则，就认为当前查询器失效，从而发起新的查询器选举过程。

    IGMPv2是在IGMPv1的基础之上发展而来的，其报文格式和IGMPv1报文格式基本相同。不同之处在于IGMPv2将IGMPv1中的4位Version字段与4位Type字段整合成为一个8位的Type字段。将IGMPv1预留没有使用的8位Unused字段设置为8位Max Reps Time字段。

    IGMPv2的Type字段定义了四种报文类型：

    Membership Query报文，Type字段值为0x11。

    ·版本1的Membership Report报文，Type字段值为0x12，该Report报文用于和IGMPv1兼容。

    ·版本2的Membership Report报文，Type字段值为0x16。

    ·Leave Group报文，Type字段值为0x17。

    Membership Query报文又包含两个类型：General Query和Group-Specific Query。这两种查询报文由组地址字段进行区分：General Query报文的组地址字段为0，而Group-Specific Query报文的组地址字段为要查询的组播组的地址。

    最大响应时间（Max Resp Time）字段仅在Membership Query报文中使用。该字段规定了主机在发送一个Membership Report报文时最大的延时时间，单位为0.1秒，默认值为100（即10秒）。在Membership Report报文和Leave Group报文中，会由主机设置为0。

    检验和（Checksum）字段是IGMP报文长度的16位检测。

    组地址（Group Address）字段在不同的报文类型中有不同的含义。在General Query报文中该字段设置为0；在Group-Specific Query报文中该字段为被查询的组播组地址；在Membership Report报文和Leave Group报文中，组地址字段为主机想要加入或离开的组播组地址。

19.4    IGMPv3

    IGMPv3在兼容和继承IGMPv1和IGMPv2的基础上，进一步增强了主机的控制能力，并增强了Membership Query报文和Membership Report报文的功能。

    IGMPv3增加了对组播源过滤的支持，IGMPv3主机不仅可以选择接收某个组播组的数据，还可以根据喜好选择接收或拒绝某些源发送到这个组播组的数据。

    例如，网络中有两个频道都在播放NBA比赛，频道1的节目用组播流（1.1.1.1，228.1.1.1）表示。如果网络中的设备仅支持IGMPv1/v2无法区分组播源，只能区分组播组。而如果用户设备支持IGMPv3协议，就可以通过路由器只接收组播源为1.1.1.1的组播流，而不想接收组播源为2.2.2.2的组播流，这样路由器就可以只把频道1的NBA比赛转发给用户。

    IGMPv3增加了对特定源组查询的支持，在Group-and-Source-Specific Query报文中，既携带组地址，还携带一个或多个源地址。IGMPv3取消了Leave Group报文类型，通过在Membership Report报文中申明不再接收任何源发送给某组播组的数据，即可实现离开这个组播组的功能。Membership Report报文的目的地址使用组播地址224.0.0.22，不再使用具体z组播组的地址。

    IGMPv3中一个Membership Report报文可以携带多个源组信息，不同于IGMPv1/v2仅能包含一个组信息，因而大量减少了Membership Report报文的数量，不再需要成员报告抑制机制。取消成员报告抑制机制后，IGMPv3主机不需要对收到的Membership Report报文进行解析，可以大量减少主机的工作量。

    IGMPv3主机为接口上每一个组播组都维护一个表项信息，其格式为（组地址，过滤模式，源列表）。

    组播组的过滤模式包含INCLUDE和EXCLUDE两种类型：

    ·INCLUDE模式表示只接收来自于在源列表中列出的组播源发送的组播数据；

    ·EXCLUDE模式表示只接收来自于不在源列表中列出的组博源发送的组播数据。

    源列表包含0个或多个IP单播地址，通常用集合形式来表示。通常使用INCLUDE（S，G）表示接收来自源S的组播地址为G的数据，使用EXCLUDE（S，G）表示不希望接收来自源S的组播地址为G的数据，使用EXCLUDE（S，G）表示不希望接收来自源S的组播地址为G的数据。

    例如，主机A接收来自于组播源1.1.1.1发送的目的地址为228.1.1.1的组播流，则主机A维护的组播组228.1.1.1的表项为INCLUDE（1.1.1.1，228.1.1.1）。

    如果主机B不希望接收来自于组播源2.2.2.2发送的目的地址为228.1.1.1的组播流，则主机B的组播组228.1.1.1的表项为EXCLUDE（2.2.2.2，228.1.1.1）。

    IGMPv3主机还为接口上每一个组播组维护状态信息。当收到路由器发送的Membership Query报文时，主机向路由器回应组播组的当前状态，当组播组的状态改变时主机主动向路由器发送Membership Report报文通知组播组的状态发生了变化。

    IGMPv3组播组有当前状态、过滤模式改变状态、源列表改变状态三种状态，这些状态信息在Membership Report报文通知组播组的状态发生了变化。

    IGMPv3组播组有当前状态、过滤模式改变状态、源列表改变状态三种状态，这些状态信息在Membership Report报文的组记录字段（Group Record）中表示：

    IGMPv3路由器侧也为接口上的每一个组播维护状态信息，和IGMPv3主机侧相比，路由器还为每一个组播组以及源列表中的每一个组播源维护状态定时器。

    路由器维护的组状态格式为（组地址，组定时器，过滤模式，源记录列表），其中源记录的格式为（源地址，源定时器）。

    路由器维护的每一个组播组只对应一种过滤模式：

    ·对于INCLUDE模式，源记录列表包含该接口所属网段内的主机需要接收的所有组播源，表示为INCLUDE（S，G）；

    ·对于EXCLUDE模式，源记录列表包含两类源列表，第一类与过滤模式相反，是主机需要接收的组播源列表S1；第二类是主机不需要接收的组播源列表S2，表示为：EXCLUDE（S1，S2，G）。

    IGMPv3路由器RTA周期性发送General Query报文，IGMPv3主机收到General Query报文后，在接口设置定时器，定时器超时后发送Membership Report报文。

    主机A希望接收组播组228.1.1.1的数据，但是不希望接收来自组播源2.2.2.3的数据，因此主机A回复的Membership Report报文中的组记录为IS_EX（2.2.2.3，228.1.1.1）。

    主机B希望接收组播组228.1.1.2的数据，且希望接收来自组播源2.2.2.2和2.2.2.4的数据，因此主机B回复的Membership Report报文中的组记录为IS_IN（2.2.2.2+2.2.2.4，228.1.1.2）。

    主机C希望接收组播组228.1.1.1的数据，但是不希望接收来自组播源2.2.2.1的数据，因此主机C回复的Membership Report报文中的组记录为IS_EX（2.2.2.1，228.1.1.1）

    路由器收到Membership Report报文后，会为组播组228.1.1.1和228.1.1.2建立表项维护状态信息。其中，组播组228.1.1.1，过滤模式为EXCLUDE，排除的组播源为2.2.2.1和2.2.2.3，表示为EXCLUDE（NULL，2.2.2.1+2.2.2.3,228.1.1.1）。组播组228.1.1.2过滤模式为INCLUDE，需要接收的组播源为2.2.2.2和2.2.2.4，表示为INCLUDE（2.2.2.2+2.2.2.4，228.1.1.2）。

    当主机B不再希望接收来自组播源2.2.2.2发送的组播数据时，会主动发送Membership Report报文，报文中包含的组记录为BLOCK（2.2.2.2，228.1.1.2）。

    如果在Max Reps Time时间内，路由器没有收到任何对于该Group-and-Source-Specific Query报文的回应，则路由器会在组播组228.1.1.2对应的源列表中，删除组播源2.2.2.2，此时该组播组状态信息为INCLUDE（2.2.2.4，228.1.1.2）。组播组228.1.1.1的源列表信息保持不变。

    当主机不愿意接受某组播组的数据时，可以发送离开组报文。IGMPv3取消了Leave报文，使用特殊的组记录方式来表示主机离开某个组。

    IGMPv3有Membership Query报文和Membership Report报文两种类型，Membership Query报文类型号为0x11，包含General Query报文、Group-Specific Query报文和Group-and-Source-Spencific Query报文。Membership Report报文类型号为0x22。

    此外，IGMPv3可以兼容IGMPv1/v2的报文，包含类型号为0x12的IGMPv1 Membership Report报文、类型号为0x16的IGMPv2 Membership Report报文和类型号为0x17的IGMPv2 Leave Group报文。

    IGMPv3的查询报文在IGMPv1/v2报文的基础上增加了源地址列表，源地址以及一些标志位。

    对于普遍组查询报文，组地址字段置位0，源地址数字段也为0，报文中不包含任何源地址信息。

    对于特定组查询报文，组地址字段为被查询的组播地址，源地址数字段为被查询的源地址的个数，在源地址字段列出被查询的各个源地址。

    IGMPv3普遍组查询报文的目的地址为224.0.0.1，特定组查询报文和特定源组查询报文的目的地址为被查询的组播组地址。

    IGMP3的Report报文比IGMPv1/v2的Report报文增加了组记录数字段和组记录字段。一个Report报文可以携带多个组记录，每一个组记录单独的记录了某个组的记录类型以及对应的组播源信息。

    组记录格式主要包括：记录类型、组播组地址、组播源个数和组播源地址列表。组记录类型包含当前状态记录、过滤模式改变记录和源列表变化记录三种类型。其中当前状态记录又可以分为IS_IN和IS_EX两类，过滤模式改变记录分为TO_IN和TO_EX两类，源列表变化记录分为ALLOW和BLOCK两类。

19.5    IGMP不同版本间的操作

    当运行不同的版本的IGMP路由器和主机协同工作时，通常比较IGMP报文中的类型字段以及报文的长度即可判断IGMP的版本。

    ·IGMPv1：Membership Query报文长度为8字节，且Max Reps Cole字段值为0。IGMPv1中Membership Report报文的最大响应延时不是通过Membership Query报文版本可以通过比较报文长度以及Max Reps Code字段的值来确定。

    ·IGMPv1：Membership Query报文长度为8字节，且Max Reps Code字段值为0。IGMPv1中Membership Report报文的最大响应延时不是通过Membership Query报文获得，而是使用固定值10秒。收到Membership Query报文后，主机会在[0,10]秒间随机选择一个延时发送Membership Report报文。

    ·IGMPv2：Membership Query报文长度为8字节，且Max Reps Code字段值不为0。

    ·IGMPv3：Membership Query报文长度大于8字节。

    IGMP各版本功能有较大差异，对于查询器选举、离开组方式、指定组查询、指定源组加入等功能，IGMP各版本差别如下：

    IGMPv1本身不支持查询选举，这个工作需要组播路由协议配置支持；IGMPv1中没有Leave Group报文，当主机离开某个组时，不会发送任何消息选择默默的离开，如果该主机为组播组的最后一位接收者，则路由器默认情况下需要最多两个普遍查询间隔即两分钟的时间才得知组播组没有成员，在此期间路由器会继续将组播数据发送到该网段，浪费大量网络带宽，IGMPv1无法支持特定组查询和特定源组的加入。

    IGMPv2在IGMPv1的基础上，增加了查询器选举机制，并且通过使用Leave Group报文和Group-Specific Query报文大大减少了路由器感知主机离开某个组的时间。IGMPv2不支持针对特定源组的加入。

    IGMPv3在IGMPv2的基础上增加了对特定源组加入的支持，路由器也可以针对特定源组进行查询。

    运行新IGMP版本的主机和路由器可以和运行老IGMP版本的主机和路由器兼容。当运行IGMPv2的主机或路由器和运行IGMPv1的主机或路由器协同工作时，分为如下几种场景：

    ·与IGMPv1路由器的兼容

    当IGMPv2主机和IGMPv1路由器一起运行时，由于IGMPv1路由器无法识别版本2的Membership Report报文，所以IGMPv2的主机必须发送版本1的Membership Report报文，且不再发送Leave Group报文。

    当IGMPv2路由器和IGMPv1路由器一起运行时，将由IGMPv1路由器充当查询器的角色。

    ·与IGMPv1主机的兼容

    IGMPv2路由器如果发现IGMPv1主机，则必须忽略网段上收到的任何Leave Group报文。因为IGMPv1主机不能识别Group-Specific Query报文，如果发送Group-Specific Query报文，IGMPv1主机将不作任何回应，可能导致路由器错误的删除组播表项。

    IGMPv2主机的Membership Report报文会被IGMPv1主机发送的关于同一个组的Membership Report报文抑制。

    当IGMPv3主机和IGMPv1/v2的路由器一起运行时，IGMPv3主机会为网段上的IGMPv1或IGMPv2查询器维护一个定时器，IGMPv3主机的工作模式由这些定时器状态决定。

    当IGMPv1查询器状态定时器运行时，说明网段上有IGMPv1路由器且充当查询器的角色，则IGMPv3主机将工作在IGMPv1模式；当IGMPv1查询器状态定时器没有运行，而IGMPv2查询器状态定时器运行时，说明网络上有IGMPv2路由器且充当查询器的角色，则IGMPv3主机将工作在IGMPv2模式；当没有IGMPv1/IGMPv2查询器状态定时器运行时，IGMPv3主机工作在其默认即IGMPv3模式。

    当IGMPv3主机和IGMPv1/v2主机一同运行时，IGMPv3主机的Report报文可以被IGMPv1/v2主机发送的关于同一个组的Membership Report报文抑制。

    当IGMPv3路由器和IGMPv1/v2路由器一起运行时，网段中的查询器必须为较低IGMP版本的路由器，即IGMPv1/IGMPv2路由器。

    当IGMPv3路由器和IGMPv1/v2主机一起运行时，IGMPv3路由器的工作模式由IGMPv1/v2主机状态定时器决定。

    当IGMPv1主机状态定时器运行时，说明网段上有IGMPv1主机，则IGMPv3路由器将工作在IGMPv1模式；当IGMPv1主机状态定时器没有运行，而IGMPv2主机状态定时器运行时，说明网络上有IGMPv2主机，则IGMPv3路由器将工作在IGMPv2模式；当没有IGMPv1/IGMPv2主机状态定时器运行时，IGMPv3路由器工作在其默认模式即IGMPv3模式。

    当IGMPv3路由器发送Membership Query报文，收到IGMPv1/v2的Membership Report报文时，会将其转换成包含组记录IS_EX（NULL，G）的IGMPv3 Membership Report报文来处理；

    当IGMPv3路由器收到IGMPv2的Leave Group报文时，会将其转换成包含组记录TO_IN（NULL，G）的IGMPv3 Membership Report报文来处理。

19.6    IGMP Snooping

    在实际网络中，由于路由器接口数有限，所以主机通常都是通过交换机连接到路由器。

    当主机和路由器之间的交换机为二层交换机时，其无法识别路由器发来的组播报文，因此会作为未知报文在网段内广播，导致不属于该组播成员的主机也收到了组播报文。如图所示，主机B也将收到发往主机A和主机C的组播报文，由于主机B不是接收者，因此会将组播报文丢弃。

    可以看到这种情况浪费了网络带宽，并增加了非接收者主机的处理负担，偏离了组播涉及的初衷。

    通过在二层交换机上实现IGMP Snooping功能可以解决组播报文在二层广播发送的问题。

    IGMP Snooping是运行在二层设备上的组播约束机制，用于管理和控制组播组。运行IGMP Snooping的二层设备通过对收到的IGMP报文进行分析，为端口和MAC组播地址建立起映射关系，并根据这样的映射关系转发组播数据。

    图中，主机A和主机C是组播组228.1.1.1的接收者，则二层交换机会通过IGMP Snooping为组播组228.1.1.1记录一个表项，表项中包含连接路由器的端口、组播组地址以及连接接收者的端口。当有目的地址为228.1.1.1的组播报文到达时，二层交换机只会将组播报文从连接接收者的端口E1/0/2和E1/0/4发送出去，从而避免了二层的广播。

    IGMP Snooping通过二层组播将信息只转发给有需要的接收者，可以带来以下好处：

    ·减少了二层网络中的广播报文，节约了网络带宽；

    ·增强了组播信息的安全性；

    ·为实现对每台主机的单独计费带来了方便。

    在路由器和主机间运行IGMP Snooping的交换机上存在两种端口：路由器端口和成员端口。

    在路由器端口（Router Port）指交换机上朝向三层组播设备（DR或IGMP查询器）一侧的端口，如SWA和SWB各自的Ethernet1/0/1端口。交换机将本设备上的所有路由器端口都记录在路由器端口列表中。

    成员端口（Member Port）有称为组播组成员端口，表示交换机上朝向组播组成员一侧的端口，如SWA的Ethernet1/0/2和Ethernet1/0/4端口，以及SWB的Ethernet1/0/2端口。交换机将本设备上的所有成员端口都记录在IGMP Snooping转发表中。

    IGMP查询器定期向本地网段内的所有主机与路由器（224.0.0.1）发送IGMP General Query报文，以查询该网段有哪些组播组成员。在收到IGMP Membership Report报文时，IGMP Snooping交换机将其从VLAN内的所有路由器端口转发出去，并从该报文中解析出主机要加入的组播组地址，并对报文的接收端口做如下处理：

    ·如果不存在该组播组所对应的转发表项，则创建转发表项，将该端口作为动态成员端口添加到出端口列表中，并启动器老化定时器；

    ·如果已存在该组播组所对应的转发表项，但其出端口列表中不包含该端口，则将该端口作为动态成员端口添加到出端口列表中，并启动器老化定时器；

    ·如果已存在该组播组所对应的转发表项，且其出端口列表中已包含该动态成员端口，则重置其老化定时器。

    IGMP Snooping交换机不会将IGMP Membership Report报文通过非路由器端口转发出去，因为根据主机上的IGMP成员报告抑制机制，如果非路由器端口下还有该组播组的成员主机，则这些主机在收到该Membership Report报文后便抑制了自身Membership Report报文的发送，从而使IGMP Snooping交换机无法获知这些端口下还有改组播组的成员主机。

    运行IGMPv1的主机离开组播组时不会发送IGMP离开组报文，因此交换机无法立即获知主机离开的信息，只能等待成员端口的老化定时器超时后，交换机会将该端口从转发表中删除。

    运行IGMPv2或IGMPv3的主机离开组播组时，会通知路由器自己离开了某个组播组。当交换机从某动态成员端口上收到IGMP离开组报文时，首先判断要离开的组播组所对应的转发表项是否存在，以及该组播组所对应转发表项的出端口列表中是否包含该接收端口。

        ·如果不存在该组播组对应的转发表项，或者改组播组对应转发表项的出端口列表中不包含该端口，交换机将该报文直接丢弃；

        ·如果存在该组播组对应的转发表项，且该组播组对应转发表项的出端口列表中包含该端口，交换机会将该报文从VLAN内的所有路由器端口转发出去。同时，由于并不知道该接收端口下是否还有改组播组的其他成员，所以交换机不会立刻把该端口从该组播组所对应转发表项的出端口列表中删除，而是重置其老化定时器。

    当IGMP查询器收到IGMP Leave Group报文后，从中解析出主机要离开的组播组的地址，并通过接收端口向该组播组发送IGMP Group-Specific Query报文。交换机在收到IGMP Group-Specific Query报文后，将其从VLAN内的所有路由器端口和该组播组的所有成员端口转发出去。

    对于IGMP Leave Group报文的接收端口（假定为动态成员端口），交换机在其老化时间内：

    ·如果从该端口收到了主机响应该特定组查询的IGMP Membership Report报文，则表示该端口下还有改组播组的成员，于是重置其老化定时器；

    ·如果没有从该端口收到主机响应特定组查询的IGMP Membership Report报文，则表示该端口下已没有该组播组的成员，则在其老化时间超时后，将其从该组播组所对应转发表项的出端口列表中删除。

19.7    组播VLAN

    在传统的组播点播方式下，当属于不同VLAN的主机同时点播同一组播组时，路由器需要把组播数据在每个用户VLAN内部复制一份发送给二层交换机。这样既然造成了带宽的浪费，也给路由器增加了额外的负担。

    图中，主机A位于VLAN2，主机B位于VLAN3，主机C位于VLAN4，三台主机都希望接收同一组播组的数据，则路由器在收到组播报文后，需要在VLAN2、VLAN3和VLAN4内各复制一份组播报文，然后发送给二层交换机。二层交换机从Trunk端口收到组播数据后，分别在对应的VLAN内发送。

    当存在大量属于不同VLAN的接收者时，路由器和二层交换机之间的链路上将会传送大量内容相同的组播报文，而路由器也会增加很多处理负担。

    使用组播VLAN功能可以解决这个问题。在二层交换机上配置了组播VLAN后，路由器只需把组播数据在组播VLAN内复制一份发送给二层交换机，而不必在每个用户VLAN内都复制一份，从而节省了网络带宽，也减轻了路由器的负担。

    图中，接收者主机A、B、C分属不同的用户VLAN。在二层交换机上配置VLAN 10位组播VLAN，将所有的用户VLAN都配置为该组播VLAN的子VLAN，并在组播VLAN内使能IGMP Snooping。

    配置完成后，IGMP Snooping将在组播VLAN中对路由器端口进行维护，而在各子VLAN中对成员端口进行维护。这样，路由器只需把组播数据在组播VLAN内复制一份发送给二层交换机，二层交换机会将其分发给组播VLAN内那些有接收者的子VLAN。

第20章    组播转发机制

    与单播转发路径不同，组播数据转发路径基于树形结构，不同的组播路由协议计算生成的组播分发树不同。

    由于组播报文的目的地址是一组接收者，无法从发送方向判断组播转发的最优路径，组播采用逆向转发检查机制确保组播数据沿正确路径传输。

20.2    组播分发树模型

    单播传输中，接收者是唯一的，所以从发送源到接收者之间的路径是点到点的一条线。

    组播传输中，接收者可能是一组分布于网络中任何角落的主机，这就决定了组播数据的转发路径是点到多点的一棵树，因此组播报文的转发路径称为组播分发树。

    组播分发树由组播路由协议建立。根据树根节点的不同，组播分发树模型可分为：

    ·SPT（Shorttest Path Tree，最短路径树）：树根为组播源，从树根出发到达每一个接收者所经过的路径都是最优的。

    ·RPT（Rendezvous Point Tree，共享树）：树根是网络中的某一台路由器，称为RP（Rendezvous Point，汇聚点）。网络中所有接收者共享RP，作为组播分发树的树根。组播源发出的组播数据必须首先到达RP，再由RP分发给各个组播接收者，这样就保证组播数据从组播源到组播接收者经过的是最优路径。

    在SPT模型中，组播源到达任何一个接收者所经过的路径都是最优的。

    SPT上的每一个路由器都会维护（S，G）表项，用于组播报文的转发，其中S表示SPT的根即组播源，G指该SPT的组播组地址。

    图中可以看到，从组播源到每一个接收者所经过的路径都是最优路径。不同组播源以自己为根，独立建立SPT。沿SPT传送组播报文可以将报文转发的路径延迟降到最低。

    在SPT模型中，组播源到达任何一个接收者所经过的路径是最优的。

    SPT上的每一个路由器都会维护（S，G）表项，用于组播报文的转发，其中S表示SPT的根即组播源，G指该SPT的组播组地址。

    图中可以看到，从组播源到每一个接收者所经过的路径都是最优路径。不同组播源以自己为根，独立建立SPT。沿SPT传送组播报文可以将报文转发的路径延迟降到最低。

    RPT由接收者端发起建立，由于接收者不了解组播源的位置，所以需要在网络中指定一个特殊的节点，作为所有接收者共享的树根，这个根节点就是RP（Rendezvous Point，汇聚点）。

    RPT上的每一个路由器都会维护（*，G）表项，用于组播报文的转发，其中*表示任意源，G指组播组地址。

    图中，组播源分别发送组播报文给各自的接收者，在组播报文到达接收者之前首先需要经过RP，然后再由RP分发给不同的接收者。可以看到组播报文在组播源和部分接收者之间没有走最优路径。

    和SPT相比，RPT的路径不是最优的，组播报文转发时引入了额外的路径延迟。但是路由器维护的表项信息比较简单，可以节省路由器内存空间。

20.3    RPF机制

    单播数据包转发的依据是目的IP地址，该目的地址在网络中唯一地标识了一个节点的位置，所以根据目的地址即可以确定一条到达目的节点的最优路径。沿着确定的路径转发还可以避免环路的产生。

    组播数据包的目的地址是组播地址，该组播地址标识了网络中的一组接收者，这些接收者可能处于网络中的任意位置，仅通过目的地址无法确保组播报文沿着正确的路径转发。此外，组播接收者位置的不确定可能会导致路径环路的产生。

    通过RPF（Reverse Path Forwarding，逆向路径转发）检查机制可以解决上述问题。

    RPF检查依据的是组播数据包的源地址。进行RPF检查时，以组播数据包的源IP地址为目的地址查找单播路由表，选取一条最优单播路由。对应表项中的出接口为RPF接口，下一跳为RPF邻居。路由器认为来自RPF邻居且由该RPF接口收到的组播包所经历的路径是从“报文源”到本地的最短路径。如果RPF检查失败即组播包不是从到达“报文源”的下一跳出接口到达，则丢弃收到的组播包。沿途每一个路由器都进行同样的检查，可以保证组播包从“报文源”到接收者之间的路径是最优的。

    根据组播分发树模型的不同，“报文源”所代表的含义也不同。如果当前组播包沿着从组播源到RP的SPT进行传输，则以组播源为“报文源”进行RPF检查；如果当前报文沿着从RP到接收者的RPT进行传输，则以RP为“报文源”进行RPF检查。

    图中组播报文从路由器的接口S0/0到达，报文的源IP地址为192.18.0.32。路由器将报文的源IP地址作为目的地址查找单播路由表，发现从路由器发到达报文源的单播路由下一跳的出接口为S0/1，不同于报文当前到达路由器的接口，说明该报文不是沿着最优的路径到达路由器，路由器丢弃该报文。

    图中组播报文从路由器的接口S0/1到达，报文的源IP地址为192.18.0.32。路由器将报文的源IP地址作为目的地址查找单播路由表，发现从路由器出发到达报文源的单播路由下一跳的出接口为S0/1，和报文当前到达路由器的接口相同，说明该报文沿着正确的接口到达路由器，路由器将该报文从所有对应的出接口发送出去。

    组播报文的出接口列表中具体包含哪些接口，由组播路由协议确定。

    对每一个收到的组播数据报文都进行RPF检查会给路由器带来较大负担，利用组播转发表可以解决这个问题。

    路由器转发组播报文基于的是组播转发表项，表项包含报文源、组播组地址、入接口和出接口列表等信息。对于SPT，此处的报文源为组播源；对于RPT，此处的报文源为RP。为便于表示，此处统一使用（S，G）代表组播转发表项，S代表报文源，G代表组播组。

    当路由器收到组播数据报文后，查找组播转发表：

    ·如果组播转发表不存在对应的（S，G）表项，则对于该报文执行RPF检查，将得到的RPF接口作为（S，G）表项的入接口，并结合路由信息得到（S，G）表项的出接口列表。

    ·若该报文实际到达的接口正是其RPF接口，则RPF检查通过，向出接口列表中的所有出接口转发该报文；若该报文实际到达的接口不是其RPF接口，则RPF检查失败，丢弃该报文。

    ·如果组播转发表中已存在（S，G）表项，且该报文实际到达的接口与入接口相匹配，则向出接口列表中的所有出接口转发该报文。

    ·如果组播转发表中已存在（S，G）表项，但该报文实际到达的接口与表项中的入接口不匹配，则对此报文执行RPF检查。

    如果检查得到的RPF接口与表项中的入接口一致，则说明当前（S，G）表项已过时，于是把表项中的入接口更新为检查得到的RPF接口。如果该报文实际到达的接口正是该RPF接口，则向出接口列表中的所有出接口转发该报文，否则将其丢弃。

第21章    组播路由协议

    路由器在进行组播报文转发时，需要查找组播路由表，依照出接口列表将报文复制并发送。组播路由表是通过组播路由协议得到的。组播路由协议包含DVMRP、MOSPF、PIM等。

21.2    组播路由协议概述

    组播路由协议运行在三层组播设备之间，用于建立和维护组播路由表，并正确、高效地转发组播报文。

    组播路由协议为组播源和组播接收者建立了无环的传输路径，即组播分发树，不同的组播路由协议基于的组播分发树可能不同。

    组播路由协议根据不同的组播模型可以分为基于ASM（任意信源模型）的组播路由协议和基于SSM（指定信源模型）的组播路由协议。对于ASM组播模型，组播路由协议又可以分为域内组播路由协议和域间组播路由协议。域内组播路由协议用于在AS内部发现组播源并构建组播分发树；域间组播路由协议用于实现组播信息在AS间的传递。

    根据组播应用环境中组播接收者疏密程度的不同，组播路由协议有密集和稀疏两种模式。

    ·在密集模式下，组播数据流采用“推”的方式从组播源泛洪发送到网络中的每一个角落，组播接收者采用被动接收的方式接收组播报文。如果某路由器所负责的所有网段均不存在接收者，则该路由器会向上游路由器发送请求，停止上游向自己泛洪组播报文。

    密集模式实现非常简单，但是泛洪机制会浪费大量网络带宽。密集模式适用于网络环境中成员众多的场合，如股票交易大厅、学校网上教学等。

    ·在稀疏模式下，组播数据流采用“拉”的方式从组播源发送到组播接收者，组播接收端路由器主动向组播源发送接收请求，组播报文只会发送到真正有接收需求的网段。

    稀疏模式实现较为复杂，但是节省了大量网络带宽。稀疏模式适用于网络环境中接收成员较少的场合，如小区音/视频点播、IP智能监控等。

    域内组播路由协议主要包含DVMRP、MOSPF和PIM。

    DVMRP（Distance Vector Multicast Routing Protocol，距离矢量组播路由协议）基于距离矢量算法，即“RIP模式”。DVMRP路由协议运行时首先通过交互组播路由信息，得到一颗经过裁剪的泛洪广播树，树根为组播源，所有DVMRP路由器都为叶子节点。所有路由器都拥有唯一的上游路由器指向组播源，组播报文沿着这颗经过裁剪的广播树，通过泛洪/剪枝机制到达组播接收者。DVMRP具有RIP的所有缺点并且需要交互特定的组播路由信息，实际应用中使用很少。

    MOSPF（Multicast Extensions to OSPF，组播OSPF协议）是OSPF支持组播的扩展模式。MOSPF基于链路状态算法，通过交互特殊的LSA——组成员LSA，使得路由器了解各组播组成员的位置，当收到组播报文时可以沿最短路径树将组播报文发送到每一个组播接收者。MOSPF采用链路状态算法，可以清楚的了解每一个接收者的具体位置，所以不会产生大量的泛洪组播流，但是其运行环境受限，只能运行在OSPF网络中，实际应用中使用较少。

    PIM（Protocol Independent Multicast，协议无关组播）需要使用单播路由表进行RPF检查，但是不依赖于某种具体的单播路由协议来生成单播路由表。PIM具有DVMRP和MOSPF无法比拟的优点，相对于DVMRP，PIM不需要交互组播路由信息；相对于MOSPF，PIM灵活简单，因此PIM在实际组播应用中使用非常广泛。

    PIM协议报文基于UDP协议，端口号是103，使用专门的组播IP地址224.0.0.13。根据实现机制的不同，PIM协议可以分为PIM-DM、PIM-SM和PIM-SSM三种。

21.3    PIM-DM

    PIM-DM（Protocol Independent Multicast-Dense Mode，协议无关组播-密集模式）在RFC3973中定义，通常适用于组播组成员相对比较密集的小型网络。

    PIM-DM使用“推（Push）模式”传送组播数据，其基于原理如下：

    ·PIM-DM假设网络中的每个子网都存在至少一个组播组成员，因此组播数据将被扩散（Flooding）到网络中的所有节点。然后，PIM-DM对没有组播数据转发的分支进行剪枝（Prune），只保留包含接收者的分支。这种“扩散-剪枝”现象周期性地发生，被剪枝的分支也可以周期性地恢复成转发状态。

    ·当被剪枝 分支的节点上出现了组播组的成员时，为了减少该节点恢复成转发状态所需的时间，PIM-DM使用嫁接（Graff）机制主动恢复其对组播数据的转发。

    PIM-DM还包含邻居发现、断言（Assert）、状态刷新等处理机制。

    PIM-DM基于SPT模型，通过PIM-DM可以构建以组播源为根、接收者为叶子的组播分发树，组播报文沿最优路径到达每一个接收者。

    PIM路由器周期性地以组播方式发送PIM Hello消息，目的组播地址为224.0.0.13，所有PIM路由器都是该组播组的成员。通过Hello消息，路由器可以发现PIM邻居并建立和维护各路由器之间的PIM邻居关系。

    当连接组播接收者共享网段上有多台路由器，且路由器运行IMGPv1时，路由器可以通过PIM的Hello消息为该网段的接收者主机选举DR，并由DR充当IGMPv1的查询器。PIM-DM只有此时才需要选举DR。

    选举DR时，首先比较Hello消息的优先级，拥有最高Hello消息优先级的路由器称为该网段的DR；如果Hello消息的优先级相同，则通过比较路由器接口IP地址来竞选DR，IP地址最大的路由器将成为DR。当DR出现故障时，其余路由器在超时后没有收到DR发送的Hello消息，则会触发新的DR选举过程。

    当收到组播报文时，PIM-DM路由器首先进行RPF检查，确定报文是否从正确的接口到达。如果RPF检查正确，路由器会为该组播报文建立组播转发表项（S，G），S代表发送源，G代表组播组。该组播转发表项还包含一个入接口和出接口列表，组播转发表项的入接口即为RPF接口，出接口列表包含除RPF接口外的所有连接PIM-DM邻居的接口以及直接连接组播组G成员主机的接口。

    网络中的每一台PIM路由器都进行同样的处理，经过扩散（Flooding）过程，PIM-DM域内的每台路由器都会收到来自源S的组播报文，并创建（S，G）表项。

    如图所示，假设所有路由器均运行PIM-DM，组播源192.168.0.32发送报文组播报文到直连的路由器，路由器经过RPF检查后，将组播报文从非RPF接口发送出去，沿途每一台路由器都进行了同样的处理过程。最后，网络中每一台路由器都收到了来自192.168.0.32的组播报文，并建立（192.168.0.32，G）表项。如果路由器本地有组播组G的成员，则路由器会将组播报文发送给接收者。

    如果路由器不需要PIM邻居发送组播报文给自己，则发送Prune消息给PIM邻居，PIM邻居收到Prune（剪枝）消息后将不再转发该组播组的报文到本路由器。

    路由器有两种情况需要发送Prune消息：

    ·如果路由器维护的（S，G）表项中出接口列表为空，表示路由器下游没有组播接收者，则路由器会向上游RPF邻居发送Prune消息。

    例如，RTD和RTF会向RPF邻居RTC发送Prune消息，剪掉不需要的组播流。

    ·如果路由器从非RPF接口收到组播报文，则会触发Assert（断言）过程，Assert失败的一方也会向获胜的一方发送Prune消息。例如，RTD下游没有接收者，所以RTD向RTF邻居RTC发送Prune消息，但是同一网段的路由器RTE的下游存在接收者，如果RTC停止向该网段发送组播报文，将导致RTE无法收到并转发报文给接收者。

    针对这种问题，PIM-DM定义了加入机制：如果路由器从RPF接口收到Prune消息，且路由器下游存在接收者时，路由器要想RPF邻居发送Join消息，使得上游RPF邻居继续维持组播报文在该共享网段的转发。在本例中，RTE从RPF接口收到RTD发送的Prune消息，则RTE会从RPF接口发送Join消息给RTC，使得RTC继续转发组播报文到共享网段，这是PIM-DM中唯一使用到Join消息的地方。

    经过“扩散-剪枝”过程，最终形成组播源和组播接收者之间的SPT。

    网络中的所有路由器都会一直维护（S，G）表项，只有当组播源S不再发送组播流之后，路由器才会删除该组播源对应的（S，G）表项信息。

    PIM-DM的“扩散-剪枝”过程是周期性发生的。各个被剪枝的接口提供超时机制，当剪枝超时后接口会重新向下游发送组播报文，这个“扩散-剪枝”过程会一直持续下去。

    当被剪枝的路由器上出现组播接收者时，路由器不必等待下一次扩散的到来，而可以通过嫁接（Graft）机制快速的恢复上游RPF邻居对组播报文的转发 。

    例如，RTF下有接收者想要加入组播组G，则该接收者会向RTF发送IGMP Membership Report报文，RTF收到Membership Report报文后会建立组播组成员表项，并向RTC回复Graft ACk，告诉RTC已经收到了Graft消息。然后，RTC会收到Graft消息的接口添加到（S，G）表项的出接口列表中。之后，组播数据就会被RTC转发到RTF，而接收者也就能从RTF收到组播数据了。

    嫁接过程中，Graft消息和Graft ACK都是单播方式发送的，其中Graft消息的单播目的地址为RPF邻居的IP地址，RPF邻居回复的Graft ACK的目的地址为本路由器发送嫁接消息的源IP地址。

    在一个网段内如果存在多台组播路由器，则相同的组播报文可能会被重复发送到该网段。为了避免出现这种情况，需要通过断言（Assert）机制来选择网段上唯一的组播数据转发者。

    图中，当RTA和RTB从上游节点收到来自源S的组播报文后，都会向本地网段转发该报文，于是处于下游的节点RTC就会收到两份相同的组播报文，RTA和RTB也会从各自的本地接口收到对方转发来的该组播报文。

    此时，RTA和RTB会在收到重复组播报文的接口上发送Assert消息，Assert消息中携带组播源地址S、组播组地址G、到达组播源的单播路由的优先级和Metric。通过比较Assert消息后，RTA和RTB中的获胜者将成为组播报文在该网段的唯一转发者。Assert消息的比较规则如下：

    ·到组播源S的单播路由的优先级较高者获胜；

    ·如果到组播源S的单播路由的优先级相等，那么到组播源的Metric值较小者获胜；

    ·如果到组播源S的Metric值也相等，则本地接口IP地址较大者获胜。

    假如RTA和RTB到达组播源S的单播路由优先级和度量值都相同，因为RTB的IP地址大于RTA的IP地址，RTB为断言获胜者。作为断言失败者，RTA会向RTB发送Prune消息，由于该网段上存在接收者RTC，当RTC收到Prune消息后，会发送Join消息，使得RTB继续向该网段转发组播报文。

    当RTB上游接口中断时，为避免组播业务长期中断，RTB会立即发送Metric值为无穷大的Assert消息，从而引发新一轮的断言过程，使得RTA成为该网段新的断言获胜者。

    通过“扩散-剪枝”过程可以快速、简便的建立从组播源到组播接收者之间的SPT。但是由于该过程是周期进行的，每隔一段时间，网络中就会充斥组播报文，而不需要接收组播报文的路由器就需要再次申请剪枝，重复的“扩散-剪枝”过程浪费了大量的网络带宽，增加了路由器的处理负担。

    针对上述问题，PIM-DM提供了状态刷新机制。和组播源直接相连的路由器发出的State Refresh消息，其他路由器收到State Refresh消息后会重置剪枝超时定时器，同时向入接口之外的所有连接PIM邻居的接口发送State Refresh消息。其中，对于当前处于转发状态的接口，State Refresh消息中的剪枝标识位置0；对于当前处于剪枝状态的接口，State Refresh消息中的剪枝标识位置1。

    通过周期性的发送State Refresh消息，可以使得处于剪枝状态的接口维持在当前状态，从而减少不必要的扩散。

    状态刷新机制，使用周期性的协议报文替代周期性的组播数据扩散，较少网络消耗，优化了网络资源。

21.4    PIM-SM

    PIM-SM（Protocol Independent Multicast-Sparse Mode，协议无关组播-稀疏模式）在RFC4601中定义，在实际应用中适用于任何形式的网络。

    PIM-SM使用“拉（Pull）模式”传送组播数据，其基本原理如下：

    ·PIM-SM假设所有主机都不需要接收组播数据，只会明确提出需要组播数据的主机转发。

    ·使用RP作为共享树的根。连接接收者的DR向某组播组对应的RP发送加入消息（Join），该消息被逐跳送达RP，所经过的路径就形成了RPT的分支。

    ·组播源如果要向某组播组发送组播数据，首先由组播源侧DR负责向RP进行注册，然后组播源把组播数据发向RP，当组播数据到达RP后，被复制并沿着RPT发送给接收者。

    PIM-SM邻居发现过程和PIM-DM相同，都是通过以组播方式发送Hello报文，从而建立和维护PIM邻居关系。

    在PIM-DM中，只有当接收者侧有多台路由器连接到共享网段，且路由器运行IGMPv1时，才需要进行DR的选举。在PIM-SM中，无论路由器运行什么样的IGMP版本，接收者侧或发送源侧的路由器都需要进行DR的选举，选举出的DR将作为该共享网络中组播数据的唯一转发者。其中，接收者侧的DR负责向RP发送加入报文；组播源侧的DR负责向RP发送注册报文。

    DR的选举方式和PIM-DM中介绍的选举方式相同。首先，比较Hello报文中的优先级，拥有最高Hello报文优先级的路由器将成为DR；如果优先级相同，则需要比较路由器接口IP地址的大小，IP地址最大的路由器将成为DR。

    接收者侧的DR必须运行IGMP，否则连接在该DR上的接收者将不能通过该DR加入组播组。

    接收者首先通过IGMP Report报文通知DR加入某组播组，DR会在本地建立（*，G）表项，然后向RPF邻居发送Join消息，此时DR会将连接接收者的接口加入到（*，G）表项的出接口列表中，同时将指向RP的单播路由的下一跳出接口作为该（*，G）表项的入接口。由于接收者并没有指定组播源，因此（*，G）表项中的组播源为任意组播源。

    Join消息将沿着DR指向RP的单播路由逐跳发送，最后到达RP。沿途每一台路由器包括RP都会建立对应的（*，G）表项。网络中每一个接收者侧的DR都进行相同的操作，最终形成以RP为根的RPT。

    当RP收到组播组G的报文时，从（*，G）表项的出接口将报文转发出去，组播报文沿RPT传送，最终由接收者侧的DR转发给接收者。

    只要DR本地有组播组G的接收者，DR就会周期性的向上游发送加入消息，保证上游路由器正常发送组播报文到本地。当DR相连的所有网段都没有组播组G的接收者时，DR会向上游路由器发送剪枝消息，通知上游停止向自己发送组播组G的报文。

    组播源不关心有没有接收者，会一直向某组播组G发送组播数据。当组播源侧的DR收到组播组G的报文时，会建立（S，G）表项，同时将连接组播源接口作为（S，G）表项的入接口。

    DR将收到的组播报文封装在Register消息中，单播发送到对应的RP。RP收到单播Register消息后，判断本地是否存在对应的（*，G）表项。如果存在（*，G）表项，RP将Register消息中封装的组播报文取出，然后从（*，G）表项的出接口发送出去。

    RP会为该组播源创建对应的（S，G）表项，入接口为收到单播Register报文的接口，出接口和（*，G）表项中的出接口相同。然后，RP向组播源方向发送特定源和组的Join消息，Join消息将沿着RP指向组播源的单播路由逐跳发送，最后到达组播源侧的DR。沿途每一台路由器都会建立（S，G）表项。

    组播源侧的DR收到Join消息后，将接收Join消息的接口添加到（S，G）表项的出接口列表中，此时，形成了组播源到RP之间的一颗SPT。

    此时，组播源发出的组播报文会通过两种方式发送到RP。一种是由DR进行封装，单播发送到RP；一种是通过DR本地的（S，G）表项沿着SPT组播发送到RP。

    单播和组播发送的报文达到RP时，RP将丢弃单播注册封装的报文，而将以组播方式接收的报文发送到RPT上。同时，RP会向组播源侧的DR单播发送Register-Stop消息，通知DR停止单播注册封装过程。此后，组播报文将仅沿着SPT发送到RP，再由发送到RPT上。

    组播源的DR路由器会维护一个注册抑制定时器，在定时器时间范围内，DR都以组播方式发送数据，而不去封装注册报文。在定时器超时前，DR会发送若干空Register消息，该消息没有封装任何组播数据，仅仅用来提醒RP：该发送Register-Stop消息了，否则DR会重新通过单播发送注册封装报文。RP收到Register-Stop消息后会更新注册抑制定时器，并继续以组播方式发送数据。

    至此为止，网络中形成两棵树，一颗是组播源到RP的SPT，一颗是从RP到组播接收者的RPT。可以看到组播源到接收者之间的路径不一定是最优的，因为必须通过RP转发。当网络中组播源和接收者数量众多时，RP将成为网络性能的瓶颈，并降低了网络带宽使用率，增加了报文转发的路径延迟。

    为了获得更小的报文延迟，接收者侧的DR会发起从RPT到SPT的切换。

    当DR收到第一个组播报文时，就可以获取组播源的地址，然后向组播源方向发送特定源组的Join消息，Join消息将沿着DR指向组播源的单播路由逐跳发送，最后到达组播源侧的DR或已经存在（S，G）表项的路由器。沿途每一台路由器都会建立（S，G）表项。

    此后，组播源发送的报文将会沿着两个方向到达接收者侧的DR或DR上游的某台路由器。其中，一封报文沿SPT到达，一封报文沿RPT到达，收到两封报文的路由器会丢弃从RP方向收到的组报文，并向RP发送Prune消息。

    如果RP本地（S，G）表项的出接口列表为空，则RP向组播源侧的DR发送Prune消息，剪掉不需要的组播流。

    最终，网络中形成组播源和接收者之间的SPT。

    和PIM-DM相比，PIM-SM中的SPT基于接收者主动的加入，所以不需要泛洪报文到网络中的每一个角落，节省了大量的网络带宽。和RPT相比，组播报文经过最优路径到达接收者，不需要RP的中转，提高了报文转发的效率。

    PIM-SM中，组播组加入请求是由接收者端主动发起的，而接收者初始时候，并不知道组播源的位置，因此需要RP作为接收者加入某组播组的汇聚点；组播源起始的时候也不知道接收者在什么地方，所以也将组播报文发给RP，由RP中转。由此可见RP是PIM-SM中的核心设备，RP的选择是PIM-SM运行的关键。

    在结构简单的小型网络中，组播信息量少，整个网络仅依靠一个RP进行组播信息的转发即可，此时可以在PIM-SM域中的各路由器上静态指定RP的位置；但是在更多的情况下，PIM-SM域的规模都很大，通过RP转发的组播信息量巨大。

    为了缓解RP的负担并优化RPT的拓扑结构，可以在PIM-SM域中配置多个C-RP（Candidate-RP，候选RP），通过BootStrap机制来动态选举RP，使用不同的RP服务于不同的组播组，此时需要配置BSR（BootStrap Router，自举路由器）。

    BSR是PIM-SM域的管理核心，一个PIM-SM域内只能有一个BSR，但可以配置多个C-BSR（Candidate-BSR，候选RP），通过BootStrap机制来动态选举RP，使不同的RP服务于不同的组播组，此时需要配置BSR（BootStrap Router，自举路由器）。

    BSR是PIM-SM域的管理核心，一个PIM-SM域内只能有一个BSR，但可以配置多个C-BSR（Candidate-BSR，候选BSR）。这样，一旦BSR发生故障，其余C-BSR能够通过自动选举产生新的BSR，从而确保业务免受中断。

    C-RP路由器周期性的以单播方式发送宣告报文（Advertisement）给PIM-SM域中的BSR，该报文中携带有C-RP的地址和优先级以及其服务的组播组范围。BSR收到宣告报文后，将这些信息汇总为RP-Set（RP集，即组播组与RP 映射关系数据库），封装在自举报文（Bootstrap）中并以组播方式发布到整个PIM-SM域。

    网络中的各路由器将依据RP-Set提供的信息，使用相同的规则从众多C-RP中为特定组播组选择其对应的RP，具体规则如下：

    ·首先比较C-RP的优先级，优先级较高者获胜；

    ·若优先级相同，则使用哈希（Hash）函数计算哈希值，该值较大者获胜；

    ·若优先级和哈希值都相同，则C-RP地址较大者获胜。

    在一个PIM-SM域中只能有一个BSR，由C-BSR通过自动选举产生。C-BSR间的自动选举机制描述如下：

    ·最初,每个C-BSR都认为自己是本PIM-SM域的BSR，并使用接口的IP地址作为BSR地址，发送自举报文；

    ·当某C-BSR收到其它C-BSR发来的自举报文时，首先比较自己与后者的优先级，优先级较高者获胜；在优先级相同的情况下，再比较自己与后者的BSR地址，拥有较大IP地址者获胜。

    实际应用中，RP和BSR可以是同一台路由器。

    图中，PIM-SM域有三台路由器作为C-RP，C-RP周期性的向网络中的BSR单播发送宣告报文。BSR收到宣告报文后，将宣告报文中的C-RP地址、优先级以及其服务的组播组范围等信息汇总为RP-Set，通过自举报文以组播方式发布给PIM-SM中的所有路由器。

    其他路由器收到自举报文后组播组选择对应的RP。一个RP可以为多个组播组服务，而一个组播组只能选择一个RP。

    最后RTA选择C-RP1作为组播组228.1.1.1的RP，RTB选举C-RP2作为组播组228.2.2.2的RP，RTC选择C-RP3作为组播组228.3.3.3的RP，实现了RP间的负载分担。

21.5    PIM-SSM

    组播的SSM模型在RFC4607中定义，SSM模型为指定源组播提供了解决方案。IANA为SSM分配了特定的组播地址段：232.0.0.0-232.255.255.255。

    PIM-SSM通过PIM-SM的一部分机制来实现，可以看做是PIM-SM的子集。PIM-SSM的机制包含邻居发现和DR选举以及加入过程。

    PIM-SSM的邻居发现和DR选举机制与PIM-SM的对应机制相同。由于接收者事先已经通过某种途径知道了组播源的IP地址，所以PIM-SSM的加入过程和PIM-SM的加入过程相比有所区别。

    主机端的DR周期性的发送IGMPv3查询报文，如果网段上有主机想要接收某特定源的组播报文，则主机回复IGMPv3 Report报文，包含想要接收的组播源地址S以及组播组地址G。

    当主机想要接收某组播源发送的组播报文时，也可以主动发送IGMPv3 Report报文，向DR发起请求。

    DR收到主机发送的Report报文，判断主机想要加入的组播组G是否在SSM模型规定的232.0.0.0-232.255.255.255范围之内，如果组播组G在SSM模型范围之内，则DR会维护组成员信息，并建立（S，G）表项。

    DR向组播源S发起加入请求，加入消息将沿着DR指向组播源S的单播路由逐跳发送，最后到达组播源侧的DR。沿途每一台路由器都会建立（S，G）表项。从而构建了一颗从组播源到接收者的SPT。

    此后，组播报文就会沿着组播源到接收者之间的SPT到达接收者。

    PIM-SSM模式中，由于主机事先知道了组播源的位置，可以直接向组播源发起加入，所以不需要在网络中选举RP，简化了协议的处理。并且组播报文开始就沿着SPT传送，不需要RPT和SPT的切换，提高了报文转发的效率。

第22章    组播配置和维护

22.2    组播配置命令

    在配置各项组播功能之前，应该首先使能IP组播路由，否则部分其他组播配置不生效，设备不转发任何组播报文。

    全局使能组播的命令为：

        [H3C]multicast routing

    igmp命令用来进入IGMP视图。IGMP视图下的全局配置对所有接口都有效，接口视图下的配置只对当前接口有效，后者的配置优先级较高。

        进入IGMP视图的命令为：

        [H3C]igmp

        IGMP缺省使能的版本为IGMPv2，可在接口视图下指定IGMP版本。在接口视图下指定IGMP版本的命令为：

        [H3C-Vlan-interface100]igmp version vesion-number

    只有在接口上使能了IGMP，在该接口上对其它IGMP特性所做的配置才能生效，所以首先需要使能接口的IGMP功能。

    在接口使能IGMP的命令如下，只有先使能了IP组播路由，本命令才能生效。

        [H3C-Vlan-interface100]igmp enable

    当IGMP查询器启动后，会周期性地发送IGMP普遍组查询报文，以判断网络上是否有组播组成员，可以根据网络的实际情况来修改周期性发送IGMP普遍组查询报文的时间间隔。配置普遍查询报文发送时间间隔的命令为：

        [H3C-Vlan-interface100]igmp query-interval interval

    在收到IGMP普遍查询报文后，主机会为起所加入的每个组播组都启动一个延迟定时器，其值在0到最大响应时间（该时间值从IGMP查询报文的最大响应时间字段获得）中随机待定，当定时器的值减为0时，主机就会向该定时器对应的组播组发送IGMP成员关系报告报文。

    合理配置IGMP查询的最大响应时间，既可以使主机对IGMP查询报文做出快速响应，又可以减少由于定时器同时超时，造成大量主机同时发送报告报文而引起的网络拥塞。

    配置普遍查询报文的最大响应时间的命令为：

        [H3C-igmp]max-response-time interval

    配置IGMP Snooping时，必须首先全局使能IGMP Snooping，然后在IGMP Snooping视图下指定使能IGMP Snoopiing功能的VLAN，对应的配置命令为：

        [H3C]igmp-snooping

        [H3C-igmp-snooping]enable vlan vlan-id

    在交换机上，如果端口下只连接有一个接收者，则可以通过使能端口快速离开功能以节约带宽和资源。

    端口快速离开是指当交换机从某端口收到主机发送的离开某组播组的IGMP离开组报文时，直接把该端口从对应转发表项的出端口列表中删除。此后，当交换机收到对该组播组的IGMP特定组查询报文时，交换机将不再向该端口转发。

    端口快速离开功能配置命令为：

        [H3C-Ethernet1/0/1]igmp-snooping fast-leave

    通常情况下，运行IGMP的主机会对IGMP查询器发出的查询报文进行响应。如果主机由于某种原因无法响应，就可能导致组播路由器认为该网段没有该组播组的成员，从而取消相应的转发路径。

    为避免这种情况发生，可以将交换机的某个端口配置成为组播组成员（即配置模拟主机加入）。当收到IGMP查询报文时由模拟主机进行响应，从而保证该交换机能够继续收到组播报文。

    模拟主机加入的配置命令为：

    [H3C-Ethernet1/0/1]igmp-snooping host-join group-address [source-ip source-address] vlan vlan-id

    未知组播数据报文是指在IGMP Snooping转发表中不存在对应转发表项的那些组播数据报文，交换机收到未知组播报文时将在未知组播数据报文所属的VLAN内广播该报文，这样会占用大量的网络带宽，影响转发效率。

    可以在交换机上启动丢弃未知组播数据报文功能，当交换机收到未知组播数据报文时，只向路由器转发，不在VLAN内广播。如果交换机没有路由器端口，数据报文会被丢弃，不再转发。

    配置位置组丢弃的命令为：

        [H3C-vlan2]igmp-snooping drop-unknown

    在运行了IGMP的组播网络中，会有一台三层组播设备充当IGMP查询器，负责发送IGMP查询报文，使三层组播设备能够在网络层建立并维护组播转发表项，从而在网络层正常转发组播数据。

    但是，在一个没有三层组播设备的网络中，由于二层设备并不支持IGMP，因此无法实现IGMP查询器的相关功能。为了解决这个问题，可以在二层设备上使能IGMP Snooping查询器，使二层设备能够在数据链路层建立并维护组播转发表项，从而在数据链路层正常转发组播数据。

    二层设备查询器的配置包含配置查询器、配置查询报文的源地址、配置特定组查询报文的源地址等配置，对应的配置命令为：

    配置查询器：

        [H3C-vlan2]igmp-snooping querier

    配置普遍查询报文的源地址：

        [H3C-vlan2]igmp-snooping general-query source-ip ip-address

    配置特定组查询报文的源地址：

        [H3C-vlan2]igmap-snooping special-query source-ip ip-address

    配置特定组查询报文的源地址：

        [H3C-vlan2]igmp-snoopiing special-group source-ip ip-address

    配置组播VLAN时，首先需要把某个VLAN配置为组播VLAN，再将用户VLAN添加到该组播VLAN内，使其成为组播VLAN的子VLAN。

    配置组播VLAN的命令为：

        [H3C]multicast-vlan vlan-id

    向组播VLn内添加子VLAN的命令为：

        [H3C-mvlan-100]subvlan vlan-list

    配置PIM-DM通常只需要在接口下使能PIM-DM即可，配置命令为：

        [H3C-Vlan-interface100]pim dm

    PIM-SM的配置包含使能PIM-SM、RP的相关配置、C-BSR的相关配置。如果需要指定某台设备作为共享网段上的DR设备，还需要配置Hello报文的优先级选项。

    使能PIM-SM的配置命令为：

        [H3C-vlan-interface100]pim sm

    配置DR优先级的命令为：

        [H3C-Vlan-inteface100]pim hello-option dr-priority priority

    在PIM视图下配置RP和C-BSR的相关信息，进入PIM视图的配置命令为：

        [H3C]pim

    PIM-SM中RP可以通过手工指定，也可以通过动态选举。

    当网络内仅有一个动态RP时，通过手工配置静态RP可以避免因单一节点故障而引起的通信中断，同时也可以避免C-RP与BSR之间频繁的信息交互而占用带宽。当网络中同时存在动态RP和静态RP时，如果指定了preferred参数，则优先选择静态RP，只有当静态RP失效时，动态RP才能生效。如果未指定preferred参数，则表示优先选择动态RP，只有当未配置动态RP或动态RP失效时，静态RP才能生效。

    手工指定RP的配置命令为：

        [H3C-pim]static-rp re-address [acl-number | bidir | preferred]

    配置RP通过动态选举时，可以把有意成为RP的路由器配置为C-RP。建议在骨干路由器上配置C-RP。

    配置候选RP的命令为：

        [H3C-pim]c-rp ip-address [advertisement-interval adv-interval | group-policy acl-number | holdtime hold-time | priority priority] [bidir]

    在一个PIM-SM域中只能有一个BSR，但需要配置一个C-BSR。任意一台路由器都可以被配置为C-BSR之间通过自动选举产生BSR，BSR负责在PIM-SM域中收集并发布RP信息。C-BSR应配置在骨干网的路由器上，C-BSR的IP地址必须有对应的本地接口，且该接口上必须使能PIM。

    配置候选BSR的命令为：

    [H3C-pim]c-bsr ip-address [scope group-address {mask-length | mask}][hash-length hash-length | priority priority]

22.3    组播维护命令

    组播路由和转发信息的查看主要包括查看组播路由表、查看组播转发表和查看组播源的RPF信息。

    组播路由表是进行组播数据转发的基础，通过查看该表可以了解（S，G）表项等的建立情况。查看组播路由表的命令为：

        <H3C>display multicast routing-table

    组播转发表直接用于指导组播数据的转发，通过查看该表可以了解组播数据的转发状态。查看组播转发表的命令为：

        <H3C>display multicast forwarding-table

    通过查看组播源的RPF信息可以了解RPF接口、RPF邻居等信息，配置命令为：

        <H3C>display multicast rpf-info source-address

    通过查看IGMP组信息可以了解接口维护的某组播组的相关信息如Report报文个数、最后一个发送Report报文的主机地址、组播组超时时间等。配置命令为：

        <H3C>display igmp group group-address

    通过查看IGMP Snooping组信息可以了解路由端口、成员端口、组地址等信息。配置命令为：

        <H3C>display igmp-snooping group

    通过查看PIM路由表项，可以了解（S，G）或（*，G）表项的入接口、（S，G）或（*，G）表项的上游邻居、（S，G）或（*，G）表项下游接口的信息。配置命令为：

        <H3C>display pim routing-table

    使用PIM-SM时，通过查看RP信息，可以了解当前RP的地址、RP所服务的组播组、RP优先级、RP超时时间等信息。配置命令为：

        <H3C>display pim rp-info

22.4    组播配置示例

22.4.1    三层组播配置示例

    本例要求配置组播路由协议PIM-SM，IGMP使用版本2。配置过程如下：

    配置IP地址和单播路由协议

        配置VLAN接口以及各接口的IP地址和子网掩码，具体配置过程略。

        配置PIM-SM域内的各交换机之间采用OSPF协议进行互连，确保在网络层互通，并且各交换机之间能够借助单播路由协议实现动态更新，具体配置略。

    使能三层组播功能

        在交换机上使用命令multicast routing使能三层组播。

    [SWA]multicast routing

    [SWB]multicast routing

    [SWC]multicast routing

    [SWD]multicast routing

    配置IGMP

        在交换机连接组播接收者的VLAN接口上使用命令igmp enable使能IGMP。

    [SWB-Vlan-interface10]igmp enable

    [SWD-Vlan-interface20]igmp enable

    配置IGMP

        在交换机连接组播接收者的VLAN接口上使用命令igmp enable使能IGMP。

        [SWB-Vlan-inteface10]igmp enable

        [SWD-Vlan-interface20]igmp enable

    配置PIM-SM

        在各交换机的三层接口上配置PIM-SM，使用命令pim sm。

        [SWA-Vlan-interface1]pim sm

        [SWA-Vlan-interface2]pim sm

        [SWA-Vlan-interface3]pim sm

    SWB、SWC、SWD的配置和SWA相同，配置过程略。

        指定SWC作为PIM域中的C-RP和C-BSR

        [SWC-pim]c-rp 3.3.3.3

        [SWC-pim]c-bsr    3.3.3.3

    在SWB和SWD上使用命令display IGMP group查看组播信息。

    使用命令display multicast routing-table可以查看组播路由表的内容，组播路由表的内容和选择的组播路由协议无关，所以使用PIM-DM和使用PIM-SM时，组播路由表内容相同。

22.4.2    二层组播配置示例

    本例要求配置IGMP Snooping，并在SWA上配置IGMP Snooping查询器。配置过程如下：

    在SWA上配置VLAN10并按照组网图将对应接口加入VLAN10。配置SWA的VLAN10虚接口IP地址为10.10.10.2，作为IGMP Snooping查询器的源IP。

    在SWA的全局和VLAN10内使能IGMP Snooping。

        [SWA]igmp-snooping

        [SWA-vlan10]igmp-snooping enable

    在SWA的VLAN10内使能IGMP Snooping查询器，并配置查询报文的源地址。

        [SWA-vlan10]igmp-snooping querier

        [SWA-vlan10]igmp-snooping general-query source-ip 10.10.10.2

        [SWA-vlan10]igmp-snooping special-query source-ip 10.10.10.2

    在SWA的VLAN10内配置未知组播丢弃。

        [SWA-vlan10]igmp-snooping drop-unkown

    在SWA上使用命令display igmp-snooping group查看二层组播组信息，包含路由端口以及组成员端口等信息。

        [H3C]dis igmp-snooping group

第6篇    园区网安全技术

第23章    园区网安全概述

    园区网络在功能和性能日益提升的同时，安全问题也逐渐突出，常见的安全威胁有非法接入网络、非法访问网络资源、报文窃听、MAC地址欺骗等。本章首先介绍网络安全的概念，然后对上述园区网络中的安全威胁进行介绍，最后介绍对应的安全防范措施，包括安全架构、端口接入控制、访问控制和安全连接等。

23.2    网络安全概述

    网络安全是Internet必须面对的一个实际问题，也是一个综合性技术。网络安全具有两层含义：保证内部局域网的安全以及保证内网与外网数据交换的安全。

    常常从如下几个方面综合考虑整个网络的安全：

    ·保护物理网络线路不会轻易遭受***；

    ·有效识别合法的和非法的用户；

    ·实现有效的访问控制；

    ·保证内部网络的隐蔽性；

    ·有效的防伪手段，重要的数据重点保护；

    ·对网络设备、网络拓扑的有效管理；

    ·病毒防范。

    从网络安全关注的内容中看出，需要保护的资源包括：

    ·网络设备：能够地域***，可以进行正常的流量转发；

    ·运行信息：网络设备能够正常维持内部转发表项，不会出现数据包泛洪的情况；

    ·带宽资源：能够抵御流量***；

    ·网络终端：抵御非法访问，关闭服务器漏洞，避免服务器因受到破坏而无法正常工作；

    ·网络数据：保护网络数据包的内容不被篡改，验证报文来自真正的对方；

    ·用户信息：保护用户的ID、密码不被窃听。

23.3    园区网常见安全威胁

    园区网常见的安全威胁包括非法接入网络、非法访问网络资源、MAC地址欺骗和泛洪、报文窃听等。

    ·非法接入网络：是非法访问玩过资源的前提。即使接入网络后不访问网络资源，***者也可以采用Dos***等手段导致网络瘫痪。

    ·非法访问网络资源：指非法用户在没有被授权的情况下访问局域网设备或数据，修改网络设备的配置和运行状态，获取数据。

    ·MAC地址欺骗和泛洪：是通过发送大量源MAC地址不同的数据报文，使得交换机端口MAC地址表学习达到上限，无法学习新的MAC地址，从而导致二层数据泛洪。

    ·远程连接***：对TELNET等连接进行***，包括截取用户名密码等用户信息或数据信息，篡改数据并重新投放到网络上等。

23.4    园区网安全防范措施

23.4.1    安全网络整体架构

    AAA（Authentication，Authorization and Accounting，验证、授权和计费）提供了一个用来对认证、授权和计费三种安全功能进行配置的一致性框架。是对网络安全的一种管理。

    AAA的实现采用两种协议：RADIUS和TACACS+

    ·RADIUS（Remote Authentication Dial In User Service，远程认证拨号用户服务）是一种分布式的、客户端/服务器模式的信息交互协议，能保护网络不受未授权访问的干扰，常应用在既要求较高安全性、又允许远程用户访问的各种网络环境中。

    ·TACACS（Terminal Access Controller Access Control System Plus，终端访问控制器控制协议+）与RADIUS协议类似，采用客户端/服务器模式实现网络接入设备与TACACS服务器之间的通信。其典型应用是对需要登录到设备上进行操作的终端用户进行认证、授权和计费。交换机作为TACACS+的客户端，将用户名和密码发给TACACS+服务器进行验证。用户验证通过并得到授权之后可以登录到设备上进行操作。

23.4.2    端口接入控制

    针对非法接入网络，可以采用端口接入控制技术来进行防范。端口接入技术包括802.1X技术、MAC地址认证和端口安全。

    802.1x协议及基于端口的网络接入控制协议，在局域网接入设备的端口这一级对所接入的用户进行认证和控制。连接在端口上的用户如果能够通过认证，就可以访问局域网的资源；如果认证失败，这无法访问局域网的资源。802.1X系统为典型的客户端/服务器模式，包括三个实体：客户端、设备端和认证服务器。用户可以通过启动客户端软件发起802.1X认证，认证服务器用于实现对用户认证、授权和计费，通常为RADIUS服务器。

    MAC地址认证是一种基于端口和MAC地址对用户的网络访问权限进行控制的认证方法，它不需要用户安装任何软件。设备在首次检测到用户的MAC地址后，即启动对该用户的认证操作。认证过程中也不需要输入用户名和密码。

    端口安全特性是一种基于MAC地址对网络接入进行控制的安全机制，是对已有的802.1X认证和MAC地址认证的扩充。通过定义各种端口安全模式，让设备学习到合法的安全MAC地址，以达到相应的网络管理效果。提供了802.1X和MAC地址认证的扩展和组合应用。

注意：

    由于端口安全特性通过多种安全模式提供了802.1X和MAC地址认证的扩展和组合应用，因此在需要灵活使用以上两种认证方式的组网环境下，推荐使用端口安全特性。

23.4.3    访问控制

    针对非法访问网络资源，可以采用网络访问控制技术进行防范，常用的包括访问控制列表ACL、终端准入防御EAD和Portal。

    ACL（Access Control List，访问控制列表）可以实现流识别功能，配置一系列的匹配条件对报文进行分类，达到过滤报文目的，匹配条件可以是报文的源地址、目的地址、端口号等。设备可以通过在用户接入的端口配置恰当的ACL，来抵御用户访问非法网络资源。

    EAD（Endpoint Admission Defense，端点准入防御）作为一个网络断点接入控制方案，通过安全客户端、安全策略服务器、接入设备以及第三方服务器的联动，加强了对用户的几种管理，提升了网络的整体防御能力。当EAD客户端进行安全认证失败时，只能访问隔离区域，进行软件升级和病毒库升级操作；当安全认证成功时，可以访问安全区的网络资源。

    PORTAL认证通常被称为WEB认证，即必须通过门户网站的认证，才能够访问网络资源。PORTAL的扩展功能包括通过强制接入终端实施补丁和防病毒策略，加强网络终端对病毒抗***的主动防御能力。

23.4.4    安全连接

    针对远程连接***，可以采用SSH进行防范。用户在一个不安全的网络环境中远程登录到设备时，SSH（Secure Shell，安全外壳）可以利用加密和加强的认证功能提供安全保障，保证设备不受IP欺诈、明文密码截取等***。

    SSH提供了三种机制，以构成它所提供的服务的基础：

    ·一个传输层协议：提供了服务器鉴别、数据保密性、数据完整×××；

    ·一个用户鉴别协议：用于服务器鉴别用户；

    ·一个链接协议：可以在一条底层SSH连接上复用多条逻辑通信通道。

23.4.5    其他安全防范措施

    园区网中还会涉及到其他的安全技术，包括防火墙、IDS、×××技术等。

    防火墙是一种高级访问控制设备，一方面可以阻止来自因特网的、对受保护网路的未授权访问，另一方面允许内容网络用户对因特网进行WEB访问或收发电子邮件等。同时防火墙还有其他特点，例如进行身份鉴别、对信息进行安全加密处理等。

    IPS（Intrusion Protection System，***防御系统）依照一定的安全策略，对网络系统的运行情况进行监视，尽可能发现各种***企图、***行为并采取有效的防御措施，以保证网络系统资源的机密性、完整性和可用性，是一种主动保护。

    ×××（Virtual Private Network，虚拟专用网）利用公共网络来构建私人专用网络。在公共网上传输数据，必须提供隧道、加密以及报文的验证，因此×××能够像私人网络一样提供安全性、可靠性、可管理性和服务质量。

第24章    AAA、RADIUS和TACACS+

    AAA（Authentication，Authorization and Accounting，认证，授权和计费）是一个综合的安全架构。和其他一些安全技术配置使用，可以提升网络和设备的安全性。

    AAA是一种管理框架，它提供了授权部分实体去访问特定的资源，同时可以记录这些实体操作行为的一种安全机制，具有良好的可扩展性，容易实现用户信息的集中管理，目前被广泛使用。

24.2    AAA架构

24.2.1    AAA基本结构

    AAA（Authentication，Authorzation and Accounting，认证、授权和计费）是网络安全的一种管理机制，提供了认证、授权、计费三种安全功能。AAA一般采用客户机/服务器结构，客户端运行于NAS（Network Access Server，网络接入服务器）上，服务器则集中管理用户信息。

    AAA的三种安全功能具体作用如下：

    ·认证：确认远端访问用户的身份，判断访问者是否为合法的网络用户。

    ·授权：对认证通过的不同用户赋予不同的权限，限制用户可以使用的服务。例如用户成功登陆服务器后，管理员可以授权用户对服务器中的文件进行访问和打印操作。

    ·计费：记录用户使用网络服务中的所有操作，包括使用的服务类型、起始时间、数据流量等，它不仅是一种计费手段，也对网络安全起到了监视作用。

    AAA可以通过多种协议来实现，目前常用的是RADIUS协议和TACACS+协议。RADIUS协议和TACACS+协议规定了NAS与服务器之间如何传递用户信息。二者在结构上都采取客户机/服务器模式，都使用公共密钥对传输的用户信息进行加密，都有较好的灵活性和可扩展性。两者之间存在的区别主要体现在传输协议的使用、信息包加密、认证授权分离、多协议支持等。

    H3C交换机也提供本地认证功能，即将用户信息（包括用户名、密码和各种属性）配置在设备上，此认证类型的优点是认证速度快。

    如上图AAA基本结构图中，用户可以根据实际组网需要来决定认证、授权、计费功能分别由哪种协议的服务器来承担，其中NAS负责把用户的认证、授权、计费信息透传给服务器（RADIUS服务器或TACACS+服务器）。例如可以用TACACS+服务器实现认证和授权，用RADIUS服务器实现计费。当然用户也可以只使用AAA提供的一种或两种安全服务。

    通过对认证、授权、计费服务器进行详细配置，AAA能够对多种服务器提供安全保证，包括FTP服务、TELNET服务、PPP、端口控制等。

    在AAA中，三种安全功能是三个独立的业务流程，其中：

    ·认证：完成各接入或服务请求的用户名、密码、用户信息的交互过程，它不会下发授权信息给用户，也不会触动计费流程。

    ·授权：发送授权请求给所配置的授权服务器，授权通过后向用户下发授权信息。例如为TELNET用户、SSH用户下发访问级别，为FTP用户设定访问目录等。授权为可选配置。

    ·计费：发送计费开始、计费更新、计费结束请求报文给所配置的计费服务器。计费不是必须使用的。

24.2.2    AAA配置

    AAA的配置可以分为两部分：

    第1步：根据需要配置本地认证或远程认证方案，远程认证时需要配置RADIUS方案或TACACS+方案：

    ·本地认证：需要在交换机上配置本地用户名，并设置相应的密码和用户级别。

    [system]local-user username

    ·RADIUS方案（radius-scheme）：通过引用已配置的TACACS+方案来实现认证、授权、计费。

    [sysname]hwtacacs scheme hwtacacw-scheme-name

    第2步：创建用户所属的ISP（Internet Service Provider，Internet服务提供商），并在ISP域中引用已经配置的AAA方案。以认证方法为例：

    [sysname]domain isp-name

    [sysname-isp-ispname]authentication default {hwtacacs-scheme hwtcacs-scheme-name [local] | none | radius-scheme radius-scheme-name [local]}

其中主要参数如下：

    ·hwtacacs-scheme hwtacacs-scheme-name [local]：指定TACACS+方案；

    ·local：本地认证

    ·none：不进行认证

    ·radius-scheme radius-scheme-name [local]：指定RADIUS方案。

注意：

    如果配置了radius-scheme radius-scheme-name local或hwtacacs-scheme hwtcacs-scheme-name local，则local为RADIUS服务器或TACACS+服务器没有正常响应后的备选认证方案。

    在AAA方案认证域中，引用认证方案的同时，还必须引用授权方案和计费方案。

24.3    RADIUS协议

24.3.1    RADIUS协议概述

    RADIUS（Remote Authentication Dial-In User Service，远程认证拨号用户服务）是一种分布式、客户端/服务器结构的信息交互协议，能保护网络不受未授权访问的干扰，常应用在其要求较高安全性、又允许远程用户访问的各种网络环境中。该协议定义了基于UDP端口1812、1813分别作为认证、计费端口。

    RADIUS最初仅是针对拨号用户的AAA协议，后来随着用户接入方式的多样化发展，RADIUS也适应多种用户接入方式，如以太网接入、ADSL接入。它通过认证授权来提供接入服务，通过计费来收集、记录用户对网络资源的使用。

    RADIUS的客户端/服务器模式为：

    ·NAS设备作为RADIUS客户端，负责传输用户信息到指定的RADIUS服务器上，然后根据从服务器返回的信息进行相应处理（如接入/挂断用户）；

    ·RADIUS服务器负责接收用户连接请求，认证用户，给设备返回所需要的信息。

    RADIUS客户端与服务器之间认证消息的交互是通过共享密钥的参与来完成，并且共享密钥不能通过网络来传输，增强了信息交互的安全性，同时在传输过程中对用户密码进行了加密。RADIUS服务器支持多种方法来认证用户，如基于PPP的PAP、CHAP认证等。

24.3.2    RADIUS消息交互流程

24.3.3    RADIUS报文结构

24.3.4    RADIUS属性

    RADIUS报文中Attribute（属性）字段专门携带认证、授权和计费信息，请求提供和相应报文的配置细节，该字段采用TLV（Type，Length，Value，类型，长度，值）三元组的形式体用。

    ·类型（TYpe）字段1个字节，取值为1-255，用于指明属性的类型，表24-2列出了RADIUS认证、授权常用的属性；

    ·长度（Length）字段1个字节，指明此属性的长度，单位为字节，包括类型字段、长度字段和属性字段；

    ·属性值（Value）字段包括该属性的信息，其格式和内容由类型字段和长度字段决定，最大长度为254字节。

    RADIUS协议具有良好的可扩展性，协议中定义的26号属性（Vendor-Specific）用于设备厂商对RADIUS进行扩展，以实现标准RADIUS没有定义的功能。

    在扩展属性的RADIUS报文结构中，Vendor-ID字段占4个字节，代表厂商号，厂商可以封装多个自己定义的TLV子属性，从而在应用中得以扩展。

24.3.5    RADIUS配置

    配置RADIUS以方案（Scheme）为单位来进行。当创建一个新的RADIUS方案后，需要对属于此方案的RADIUS服务器的IP地址和端口号进行设置，这包括认证/授权服务器和计费服务器。其中每种服务器又有主服务器和从服务器的区别。

    RADIUS方案（Scheme）仅定义了设备和服务器之间进行信息交互所必需的一些参数，为了使这些参数能够生效，还必须在某个ISP域视图下指定该域应用的RADIUS方案。

    RADIUS配置步骤如下：

    第1步：创建RADIUS方案：

        [sysname]radius scheme radius-scheme-name

    第2步：配置主、从认证/授权服务器的IP地址和端口号：

        [sysname-radius-name]primary authentication ip-address [port-number]

        [sysname-radius-name]secondary authentication ip-address [port-number]

    缺省情况下，主、从认证/授权服务的IP地址为0.0.0.0，UDP端口号为1812。

    第3步：配置主、从认证/授权服务器的IP地址和端口号，以及相关参数：

        [sysname-radius-name]primary accounting ip-address [port-number]

        [sysname-radius-name]secondary accounting ip-address [port-number]

    缺省情况下，主、从计费服务器的IP地址0.0.0.0，UDP端口号为1813。

    第4步：配置RADIUS报文的共享密钥：

        [sysname-radius-name]key{accounting | authentication}string

注意：

    在实际组网中，可以指定两台RADIUS服务器分别作为主、从认证授权（计费）服务器；也可以一台服务器既作为主认证/授权服务器（计费服务器）和从认证/授权服务器（计费服务器）的IP地址不能相同，否则配置不成功。

    保证设备上的RADIUS服务端口与RADIUS服务器上的端口设置一致。

    保证设备上设置的共享密钥与RADIUS服务器上的完全一致。

    为防止认证请求报文丢失，交换机会重传一定数量的认证请求报文，其重传次数可配置。

        [sysname-radius-name]retry times

    RADIUS的三个定时器含义如下：

    ·服务器响应超时定时器（response-timeout）：如果RADIUS请求报文传送出去一段时间后，设备没有得到服务器的回应，交换机将在response定时器超时时重传RADIUS请求报文；

    ·服务器静默定时器（timer quiet）：当主服务器不可到时，状态变为block，设备会与从服务器交互。若从服务器可达，设备与从服务器通信，并开启quiet定时器，在设定的时间间隔之后，将服务器的状态恢复为acitve；

    ·实时计费间隔定时器（realtime-accounting）：每隔设定的时间，交换机会向RADIUS服务器发送一次在线用户的计费信息。

24.3.6    RADIUS调试与维护

    完成RADIUS配置后，在任意视图下执行display命令可以显示AAA、RADIUS的运行情况，通过查看显示信息验证配置后的效果。

24.4    TACACS+协议

24.4.1    TACACS+协议概述

    TACACS+（Terminal Access Controller Access Control System Plus），终端访问控制器控制系统协议)与RADIUS类似，主要通过客户机/服务器模式与TACACS+服务器通信来实现多种类型用户的AAA功能，可用于终端用户的认证、授权和计费。

    H3C设备实现的HWTACACS，是在TACSCS+基础上进行了功能增强的安全协议。

    与RADIUS协议相比，TACACS+协议具有更为可靠的传输和加密机制，更加适合安全控制。二者的主要区别如表24-4所示。

24.4.2    TACACS+认证交互流程

24.4.3    TACACS+报文结构

24.4.4    TACSCS+配置与维护

    TACACS+的配置是以TACACS+方案为单位进行的。

    第1步：在进行其他相关配置前，首先要创建HWTACACS方案并进入其视图：

        [sysname]hwtavacs scheme hwtacacs-shceme-name

    第2步：配置主认证、授权、计费服务器的IP地址和端口号：

        [sysname-hwtacase-name]primary authentication ip-address [port-number]

        [sysname-hwtcase-name]primary authorization ip-address [port-number]

        [sysname-hwtacase-name]primary accounting ip-address [port-number]

    缺省情况下，主认证、授权、计费服务器的IP地址和端口号：

        [sysname-hwtacase-name]secondary authentication ip-address [port-number]

        [sysname-hwtacase-name]secondary authorization ip-address [port-number]

        [sysname-hwtacase-name]secondary accounting ip-address [port-number]

    缺省情况下，从认证、授权、计费服务器的IP地址为0.0.0.0，TCP端口号为49。

    第4步：配置共享密钥。交换机与服务器使用MD5算法来加密交互的TACACS+报文，双方通过设置共享密钥来验证报文合法性。只有密钥一致的情况下，双方才能接受对方发来的报文并作出响应。

        [sysname-hwtacase-name]key {accounting | authentication | authorization} string

    HWTACACS与RADIUS协议一样，也有相同的定时器，作用与RADIUS相似，此处不再赘述。

    无论是RADIUS认证还是HWTRACACS认证，交换机发送给服务器的用户名都有两种格式：带域名或不带域名，即“use@ISP”或“user”两种格式。通过执行以下命令可以切换：

        [sysname-hwtacase-name]user-name-format {with-domain | without-domain}

第25章    端口接入控制

    端口接入控制的主要目的是验证接入用户身份的合法性，以及在认证的基础上对用户的网络接入行为进行授权和计费。目前有多重方式实现端口接入控制。H3C设备提供的端口接入控制协议主要有802.1X认证、MAC地址认证、端口安全认证。

25.2    802.1X协议介绍

25.2.1    802.1X概述

    2001年，IEEE802 LAN/WAN委员会为解决无线局域网网络安全问题，提出了802.1X协议，并在2004年最终完成了该协议的标准化。802.1X协议作为局域网端口的一个普通接入控制机制在以太网中被广泛应用，主要解决以太网内认证和安全方面的问题。

    802.1X协议是一种基于端口的网络接入控制协议（Port-Based Network Access Control Protocol）。“基于端口的网络接入控制”是指在局域网接入设备的端口这一级所接入的用户设备进行认证和控制。连接在端口上的用户设备如果能通过认证，就可以访问网络中的资源；如果不能通过认证，则无法访问网络中的资源。

25.2.2 802.1X协议系统结构

    802.1X系统为典型的Client/Server结构，包括三个实体：客户端（Client）、设备端（Device）和认证服务器（Server）。

    ·客户端：是位于局域网链路一端的一个实体，由处于对端的设备对其进行认证。客户端一般为用户终端设备，用户可以通过启动客户端软件发起802.1X认证。客户端必须支持EAPOL（Extensible Authentication Protocol over LAN，局域网上的可扩展认证协议）。

    ·设备端：是位于局域网链路一端的一个实体，对所连接的客户端进行认证。设备端通常为支持802.1X协议的网络设备，它为客户端提供接入局域网的端口，该端口可以是物理端口，也可以是逻辑端口。

    ·认证服务器：是为设备端提供认证服务器的实体。认证服务器用于实现对用户进行认证、授权和计费，通常RADIUS（Remote Authentication Dial-In User Servce，远程认证拨号用户服务）服务器。

25.2.3    802.1X基本概念

    ·受控/非受控端口：设备端为客户端提供接入局域网的接口，这个端口被划分为两个逻辑端口，即受控端口和非受控端口。任何到达该端口的帧，在受控端口与非受控端口上均可见。

        ·非受控端口始终处于双向连通状态，主要用来传递EAPOL协议帧，保证客户端始终能够发出或接收认证报文。

        ·受控端口在授权状态下处于双向连通状态，用于传递业务报文；在非授权状态下禁止从客户端接收任何报文。

    ·授权/费授权状态：设备端利用认证服务器对需要接入局域网的客户端执行认证，并根据认证结果（Accept或Reject）对受控的授权/非授权状态进行相应地控制。用户可以通过在端口下配置接入控制的模式来控制端口的授权状态。端口支持以下三种接入控制模式：

        ·强制授权模式（authorized-force）：表示端口始终处于授权状态，允许用户不经授权即可访问网络资源。

        ·强制非授权模式（unauthorized-force）：表示端口始终处于非授权状态，不允许用户进行认证。设备端不对通过该端口接入的客户端提供认证服务。

        ·自识别模式（auto）：表示端口初始状态为非授权状态，仅允许EAPOL报文转发，不允许用户访问网络资源；如果认证通过，则端口切换到授权状态，允许用户访问网络资源。这也是最常见的情况。

    ·受控方向：受控端口可以被设置成单向受控和双向受控。

        ·实行双向受控时，禁止帧的发送和接收；

        ·实行单向受控时，禁止从客户端接收帧，但允许向客户端发送帧。

    ·端口接入控制方式：包括基于端口/基于MAC的两种方式。

        ·当采用基于MAC方式时，该端口下的所有接入用户均需要单独认证，当某个用户下线时，也只有该用户无法使用网络。

        ·当采用基于端口方式时，只要该端口下的第一个用户认证成功后，其它接入该端口下的用户无须认证就可使用网络资源，但是当第一个用户下线后，其它用户也会被拒绝使用网络。

25.2.4    802.1X认证触发和认证方式的分类

    802.1X的认证触发方式分为两种：客户端主动触发和设备端主动触发。

    ·客户端主动触发：客户端主动向设备发送EAPOL-Start报文来触发认证，该报文目的地址是由IEEE802.1X协议分配的一个组播MAC地址：01-80-C2-00-00-03。

    另外，由于网络中可能存在不支持上述的组播报文的设备，从而使得认证设备无法收到客户端的认证请求，因此设备端还支持广播触发方式（即可以接收客户端发送的目的地址为广播MAC地址的EAPOL-Start报文。这种触发方式需要H3C iNode的802.1X客户端的配置）。

    ·设备端主动触发：设备会以一定的时间间隔（例如30秒）主动向客户端发送EAP-Request/Identity报文来触发认证，这种触发方式用于支持不能主动发送EAPOL-Start报文的客户端，例如Windows XP自带的802.1X客户端。

    802.1X认证系统使用EAP（Extensible Authentication Protocol，可扩展认证协议）来实现客户端、设备端和认证服务器之间认证信息的交互。在客户端与RADIUS服务器之间，可以使用两种方式来交换信息，分为EAP中继和EAP终结。

    ·EAP中继：EAP协议报文由设备端进行中继，使用EAPOR（EAP over RADIUS）封装格式承载于RADIUS协议中，包含MD5、EAP-TLS、EAP-TTLS、PEAP四种认证方法。

    ·EAP终结：EAP协议报文由设备端进行终结，采用包含PAP（Password Authentication Protocol，密码验证协议）或CHAP（Challenge Handshake Authentication Protocol，质询握手协议验证协议）属性的报文与RADIUS服务器进行认证交互。

25.2.5    EAP中继方式的认证流程

    IEEE 802.1X标准规定的EAP中继方式将EAP（可扩展认证协议）承载在其它高层协议中，如EAP over RADIUS，以便扩展认证报文穿越复杂的网络到达认证服务器。一般来说，EAP中继方式需要RADIUS服务器支持EAP属性：EAP-message和Message-Authentictator，分别用来封装EAP报文及时对携带EAP-Message的RADIUS报文进行保护。这里以EAP-MD5方式为例介绍基本业务流程，认证过程如下：

    1）当用户有访问网络需求时打开802.1X客户端程序，输入已经申请、登过记的用户名和密码，客户端程序将发出请求认证的报文（EAPOL-Start报文）给设备端，开始启动一次认证过程。

    2）设备端收到请求认证的数据帧后，将发出一个请求帧（EAP-Request/Identity报文）要求用户的客户端程序发送输入的用户名。

    3）客户端程序响应设备端发出的请求，将用户名信息通过数据帧（EAP-Response/Identity报文）发送给设备端。设备端将客户端发送的数据帧经过封包处理后（RADIUS Access-Request报文）送给认证服务器进行处理。

    4）RADIUS服务器收到设备端转发的用户名信息后，将该信息与数据库中的用户名表对比，找到该用户名对应的密码信息，用随机生成的一个加密字对它进行加密处理，同时也将此加密字通过RADIUS Access-Challenge报文发送给设备端，由设备端转发给客户端程序。

    5）客户端程序收到由设备端传来的加密字（EAP-Request/MD5 Challenge报文）后，用该加密字对密码部分进行加密处理（此种加密算法通常是不可逆的），生成EAP-Response/MD5 Challenge报文，并通过设备端传给认证服务器。

    6）RADIUS服务器将收到的已加密字（RADIUS Access-Request报文）和本地经过加密运算后的密码信息进行对比，如果相同，则认为该用户为合法用户，反馈认证通过的消息（RADIUS Access-Accept报文和EAP-Suscess报文）。

    7）设备收到认证通过消息后将端口改为授权状态，允许用户通过端口访问网络。在此期间，设备端会向客户端定期发送握手报文，以对用户的在线情况进行监测。缺省情况下，如果两次握手请求报文都得不到客户端应答，设备端就会让用户下线，防止用户因为异常原因下线而设备无法感知。

    8）客户端也可以发送EAPOL-Logoff报文给设备端，主动要求下线。此时设备端会把端口状态从授权状态改变成未授权状态，并向客户端发送EAP-Failure报文。

注意：

    EAP中继方式下，需要保证在客户端和RADIUS服务器上选择一致的EAP认证方法，而在设备端，只需要通过dot1x authentication-method eap命令启动EAP中继方式即可。

25.2.6    EAP终结方式的认证流程

    EAP终结方式将EAP报文在设备端终结并映射到RADIUS报文中，利用标准RADIUS协议完成认证、授权和计费。设备端与RADIUS服务器之间可以采用PAP或者CHAP认证方法。

    EAP终结方式与EAP中继方式的认证流程相比，不同之处在于用来对用户密码信息进行加密处理的随机加密字由设备生成，之后设备端会把用户名、随机加密字和客户端加密后的密码信息一起送给RADIUS服务器，进行相关的认证处理。

25.2.7    EAPOL消息的封装格式

    EAPOL是802.1X协议定义的一种报文封装格式，主要用于在客户端和设备端之间传送EAP报文，以允许EAP报文在LAN上传送。EAPOL数据包封装时其协议字段为0x888e。后续各字段含义分别如下：

    ·Protocol Version：表示EAPOL帧的发送方所支持的协议版本号；

    ·Type：表示EAPOL数据帧类型，目前设备上支持的数据类型见下表。

表25-1    EAPOL数据类型

    ·Packet Body Length：表示Packet Body域的长度，单位为字节。如果为0，则表示没有Packet Body。如EAPOL-Start和EAPOL-Logoff就没有Packet Body。

    ·Packet Body：表示数据内容，根据不同的Type有不同的格式。

25.2.8    EAP-Packet的封装格式

    当EAPOL数据包Type域为EAP-Packetsh时，Packet Body将按照CLV格式进行封装。

    ·Code：指明EAP包的类型，共有4种，Request、Reponse、Success、Failure。

    ·Identifier：用于匹配Request消息和Response消息。

    ·Length：EAP包的长度，包含Code、Identifier、Length和Data域，单位为字节。

    ·Data：EAP包的内容，由Code类型决定。

    当Code类型为Success和Failure时，数据包没有Data域，相应的length域的值为4。

    当Code类型为Request和Response时，数据包的Data域的格式如图所示。Type为Request或Response类型，Type data的内容由Type决定。例如，Type值为1时代表Identity，用来查询对方的身份；Type值为2时，代表Notification，用于传递提示消息给客户端；Type值为4，代表MD5-Challenge，类似于PPP CHAP协议，包含质询消息。

    ·EAP-Message：该属性用来封装EAP消息，类型代码为79，String域最长253字节，如果EAP数据包长度大于253字节，可以对其进行分片，依次封装在多个EAP-Message属性中。

    ·Message-Authentication：该属性用来避免接入请求包被窃听，类型代码为80。在含有EAP-Message属性的数据包中，必须同时也包含Message-Authenticator，否则该数据包会被认为无效而被丢弃。

25.2.9    802.1X、PPPoE认证和WEB认证的对比

    从上表中可以看出，相对于PPPoE和WEB认证，802.1X的优势较为明显，是理想的低成本运营解决方案。802.1X适用于接入设备与接入端口间点到点的连接方式，实现对局域网用户接入的认证与服务管理，常用于运营管理相对简单，业务复杂较低的企业以及园区。

25.3    802.1X扩展应用

25.3.1    Dynamic VLAN

    802.1X用户在服务器上通过认证时，服务器会把授权信息传送给设备端。如果服务器上配置了下发VLAN功能，在授权信息中则会包含授权下发的VLAN信息，设备根据用户认证上线的段端口链路类型，按以下三种情况将端口加入下发VLAN中：

    ·若端口的链路类型为Access，当前Access端口离开用户配置的VLAN并加入授权下发的VLAN中。

    ·若端口的链路类型为Trunk，设备允许授权下发的VLAN通过当前Trunk端口，并且端口的缺省VLAN ID为下发VLAN的VLAN ID。

    ·若端口的链路类型为Hybrid，设备不允许授权下发的VLAN以不携带Tag的方式通过当前Hybrid端口，并且端口的缺省VLAN ID为下发VLAN的VLAN ID。需要注意的是，若当前Hybrid端口上配置了基于MAC的VLAN，则设备将根据认证服务器下发的授权VLAN动态地创建基于用户MAC的VLAN，而端口的缺省VLAN ID不改变。

    授权下发的VLAN并不改变端口的配置，也不影响端口的配置。但是，授权下发的VLAN的优先级高于用户配置的VLAN，即通过认证后起作用的VLAN是授权下发的VLAN，用户配置的VLAN在用户下线后生效。

25.3.2    Guest VLAN

    Guest VLAN功能允许用户在未认证或认证失败的情况下，可以访问某一特定VLAN中的资源，比如获取客户端软件，升级客户端或执行其他一些用户升级程序。这个VLAN通常被称为Guest VLAN。

    根据端口的接入控制方式不同，可以将Guest VLAN划分基于端口的Guest VLAN和基于MAC的Guest VLAN。

    ·PGV（Port-based Guest VLAN，基于端口的Guest VLAN）：在接入控制方式被配置为portbased的端口上启用的Guest VLAN称为PGV。若在一定时间内（默认90秒），配置了PGV的端口上无客户端进行认证，则该端口将被加入Guest VLAN，所有在该端口接入的用户将被授权访问Guest VLAN里的资源。端口加入Guest VLAN的情况与加入授权下发VLAN相同，与端口链路类型有关。

    当端口上处于Guest VLAN中的用户发起认证且成功时，端口会离开Guest VLAN，之后端口加入VLAN情况与认证服务器是否下发VLAN有关，具体如下：

        ·若认证服务器下发VLAN，则端口加入下发的VLAN中。用户下线后，端口离开下发的VLAN回到初始VLAN中，该初始VLAN为端口加入Guest VLAN之前所在的VLAN。

        ·若认证服务器未下发VLAN，则端口回到初始VLAN中。用户下线后，端口仍在该初始VLAN中。

    ·MGV（MAC-Based Guest VLAN，基于MAC的Guest VLAN）：在接入控制方式配置为macbased的端口上启用的Guest VLAN称为MGV。配置了MGV的端口上未认证的用户被授权访问Guest VLAN里的资源。

    MGV需要与基于MAC的VLAN配合使用，端口配置MGV的同时，需要使能mac-vlan。设备会动态地创建基于用户MAC的VLAN表项，以将未认证或认证失效的用户加入到Guest VLAN中。

    当端口上处于Guest VLAN中的用户发起认证且成功时，设备会根据认证服务器是否下发VLAN决定将该用户加入到下发的VLAN中，或回到加入Guest VLAN之前端口所在的初始VLAN。

25.4    802.1X配置和维护

25.4.1    802.1X基本配置命令

    接入设备的管理者通常会使用RADIUS或本地认证方法，来配合802.1X完成用户的身份认证。因此，在配置802.1X时首先完成以下配置任务：

    ·配置802.1X用户所属的ISP认证域及其使用的AAA方案，即本地认证方案或RADIUS方案。

    ·如果需要通过RADIUS服务器进行认证，则应该在RADIUS服务器上配置相应的用户名和密码。

    ·如果需要本地认证，则应该在设备上手动添加认证的用户名和密码。配置本地认证时，用户使用的服务类型必须设置为lan-access。

    只有同时开启全局和端口的802.1X特性后，802.1X的配置才能在端口上生效，配置802.1X的基本步骤如下：

25.4.2    802.1X的定时器及配置

    在802.1X认证过程中会启动多个定时器以控制接入用户、设备以及RADIUS服务器之间进行合理、有序的交互。802.1X的定时器主要有以下几种：

    ·用户名请求超时定时器（tx-period）：该定时器包含两种含义。其一，当设备端向客户端发送EAP-Request/Identity请求报文后，设备端启动该定时器，若在tx-period设置的时间间隔内，设备端没有收到客户端的响应，则设备端将重发认证请求报文；其二，为了兼容不主动发送EAPOL-Start连接请求报文的客户端，设备会定期组播EAP-Request/Identity请求报文来检测客户端。tx-period定义了该组播报文的发送时间间隔。

    ·客户端认证超时定时器（supp-timeout）：当设备端向客户端发送了EAP-Request/MD5 Challenge请求报文后，设备端会启动此启动定时器，若在该定时器超时前，设备端没有收到客户端的响应，设备端将重发该报文。

    ·认证服务器超时定时器（Server-timeout）：当设备端向认证服务器发送了RADIUS Access-Request请求报文后，设备端会启动server-timeout定时器，若在该定时器超时前，设备端没有收到认证服务器的响应，设备将认为认证失败，启动下一次认证。

    ·握手定时器（handshake-period）：此定时器是在用户认证成功后启动的，设备端以此间隔为周期发送握手请求报文，以定期检测用户的在线情况。如果设备在指定时间内都没有收到客户端的响应报文时，就认为用户已经下线。

    ·静默定时器（quiet-period）：对用户认证失败以后，设备端需要静默一段时间（该时间由静默定时器设置），在静默期间，设备端不处理该用户的认证请求。

    ·周期性重认证定时器（reauth-period）：如果端口下开启了周期性重认证功能，设备端以此定时器设置的时间间隔为周期对该端口在线用户发起重认证。

    配置各个定时器参数的命令如下：

    [sysname]dot1x timer {ead-timeout ead-timeout-value | handshake-period handshake-period-value | quiet-period quiet-period-value | reauth-period reauth-period-value | server-timeout server-timeout-value | supp-timeout supp-timeout-value | tx-period tx-period-value}

    缺省情况下，静默功能处于关闭状态。如果需要防止用户频繁触发认证，请使用如下命令行静默功能：

    [sysname]dot1x quiet-period

    另外，用户可以根据需要，开启或关闭在线用户握手功能，在开启在线握手功能后，设备才会按照handshake-period定时器间隔周期发送握手请求报文，命令行如下：

    [sysname-GigabitEthernet1/0/1]dot1x handshake

25.4.3    配置Guest VLAN和VLAN下发

    可以在以太网端口视图下配置Guest VLAN，命令如下：

        [sysname-GigabitEthernet1/0/1]dot1x guest-vlan vlan-id

    若通过远程Radius服务器下发数字型VLAN，在设备上不需要创建该VLAN，用户认证成功后根据服务器下发的VLAN信息，设备会自动创建该VLAN。

    若通过远程Radius服务器下发字符型VLAN，在设备上需要先创建所下发的VLAN，并配置该VLAN的name，该name要与服务器上设置的一致。比如：

        [H3C]vlan 10

        [H3C-vlan10]name test

    若采用本地用户进行认证，下发VLAN需要配置如下属性：

        [H3C]local-user user-name

        [H3C-luser-user-name]authorization-attribute vlan vlan-id

25.4.4    802.1X典型配置案例

    组网需求：

    ·一台主机通过802.1X认证接入网络，认证服务器为RADIUS服务器。Host通过交换机的端口GigabitEthernet1/0/1（该端口在VLAN 1内）；Update Server是用于客户端软件下载和升级的服务器，在VLAN 20内；交换机连接Internet网络的端口在VLAN10内。

    ·在GigabitEthernet1/0/1上开启802.1X特性并设置VLAN 20为的Guest VLAN，当设备从端口发送触发认证报文（EAP-Request/Identity）超过设定的最大次数而没有收到任何回应报文后，GigabitEthernet1/0/1被加入Guest VLAN中，此时Host和Update Server都在VLAN 20内，Host可以访问Update Server并下载802.1X客户端。

    ·当用户认证成功上线，认证服务器下发VLAN 10。此时Host和连接Internet网络的端口都在VLAN 10内，Host可以访问Interent。

    完成上述配置之后触发认证之前，通过命令display current-configuration或者display interface gigabitethernet 1/0/1可以查看Guest VLAN的配置情况。

    在端口UP且没有用户主动上线情况下，设备将发送认证请求（EAP-Request/Identity）报文，发送超时设定的最大次数后仍未由用户响应请求，则将该端口自动加入Guest VLAN。通过命令display vlan 20可以查看端口配置的Guest VLAN是否生效。

    在用户认证成功之后，通过display interface gigabitEthernet 1/0/1中可以看到用户接入的端口GigabitEthernet1/0/1加入了认证服务器下发的授权VLAN 10中。

25.4.5    802.1X显示和维护

    在维护和配置过程中，可以通过如下命令来快速802.1X用户的会话连接信息、相关统计信息或配置信息：

        [system]display dot1x[sessions | statistics] [interface inteface-list]

    802.1X用户的相关统计信息还可以通过如下命令清除以便在维护过程中排除历史信息的干扰：

        <system>reset dot1x statistics [interface interface-list]

    当需要确切掌握某个认证用户的更具体信息时，可以使用如下命令查看认证用户详细信息。

        [sysname]display dot1x [sessions | statistics][inteface interface-list]

25    MAC地址认证

25.5.1    MAC地址认证概述

    MAC地址认证是一种基于端口和MAC地址对用户的网络访问权限进行控制的认证方法，它不需要用户安装任何客户端软件。设备在首次检测到用户的MAC地址以后，即启动对该用户的认证操作。认证过程中，也不需要用户手动输入用户名和密码。

    目前设备支持两种方式的MAC地址认证：通过RADIUS服务器认证和本地认证。

    MAC地址认证用户分为两种类型：MAC地址用户名和固定用户名。

    ·MAC地址用户名：使用用户的MAC地址作为认证时的用户名和密码。

    ·固定用户名：不论用户的MAC地址为何值，所有用户均使用在设备上预先配置的用户名和密码进行认证。同一个端口下可以有多个用户进行认证，且均使用同一个固定用户名通过认证。同一个端口下可以有多个用户进行认证，且均使用同一个固定用户名通过认证。

25.5.2    两种认证方式的工作流程

    当选用RADIUS服务器认证方式进行MAC地址认证时，设备作为RADIUS客户端，与RADIUS服务器配置完成MAC地址认证操作：

    ·采用MAC地址用户名时，设备将检测到的用户MAC地址作为用户名和密码发送给RADIUS服务器。

    ·采用固定用户名时，设备将已经在本地配置的用户名和密码作为待认证用户的用户名和密码，发送给RADIUS服务器。

    当选用本地认证方式进行MAC地址认证时，直接在设备上完成对用户的认证。需要在设备上配置本地用户名和密码：

    ·采用MAC地址用户名时，需要配置的本地用户名为各接入用户的MAC地址。

    ·采用固定用户名时，需要配置的本地用户名为自定义的，所有用户对应的用户名和密码与自定义一致。

25.5.3    MAC地址认证的配置命令

    通过使用MAC地址认证，可以对用户的网络访问权限进行控制，在配置MAC地址认证之前，需要首先完成以下配置任务：

    ·创建并配置ISP域。

    ·若采用本地认证方式，需建立本地用户并设置其密码。

    ·若采用远程RADIUS认证方式，需要确保设备与RADIUS服务器之间的路由可达，并添加用户名及密码。

    在全局MAC地址认证没有开启之前端口可以启动MAC地址认证，但不起作用；只有在全局MAC地址认证启动后，各端口的MAC地址认证配置才会立即生效。MAC地址认证基本步骤如下：

    第1步：启动全局的MAC地址认证

        [sysname]mac-authentication

    第2步：启动端口的MAC地址认证

        [sysname-interface-name]mac-authentication

    第3步：配置MAC地址认证的用户名和密码

        [sysname]mac-authentication user-name-format {fixed [account name] [password {cipher | simple} password] | mac-address [{with-hyphen | without-hyphen}[lowercase | lowercase | uppercase]]}

    第4步：配置MAC认证用户名使用的认证域

        [sysname]mac-authentication domain domain-name

25.5.4    MAC认证的典型配置案例

    组网需求：

    用户主机Host通过端口GigabitEthernet1/0/1连接到设备上，设备通过RADIUS服务器对用户进行认证、授权和计费。

    ·设备的管理者希望在各端口上对用户接入进行MAC地址认证，以控制器对Internet的访问。

    ·要求设备每隔180秒就对用户是否下线进行检测；并且当用户认证失败时，需等待3分钟才能对用户再次发起认证。

    ·所有用户都属于域h3c，认证时采用固定用户名格式，用户名为aaa，密码为123456。

    完成上述配置之后，连接认证用户到端口后将触发MAC认证，通过命令display mac-authentication或者display mac-authentication connection验证配置结果，并可以查看当前MAC认证通过的用户。

25.5.5    MAC地址认证的显示和维护

    MAC认证的维护命令和802.1x认证的维护命令基本相同，可以快捷现实全局或指定端口的MAC认证用户简要统计信息，同时也提供了相应的统计信息清除命令。当需要查看某个MAC认证用户的详细信息时，则需要采用display mac-authentication connection命令显示。

25.6    端口安全

25.6.1    端口安全概述

    端口安全（Port Security）是一种基于MAC地址对网络接入进行控制的安全机制，是对已有的802.1X认证和MAC地址认证的扩充。这种机制通过检测数据帧中的源MAC地址来控制非授权设备对网络的访问，通过检测数据帧中的目的MAC地址来控制对非授权设备的访问。

    端口安全的主要功能是通过定义各种端口安全模式，让设备学习到合法的源MAC地址，以达到相应的网络管理效果。启动了端口安全功能之后，当发现非法报文时，系统将触发相应特性，并按照预先指定的方式进行处理，既方便用户的管理又提高了系统的安全性。

    端口安全的特性有NeedToKnow特性、***检测（IntrusionProtection）特性和Trap特性。

    ·NeedToKnow特性：通过检测从端口发出的数据帧的目的MAC地址，保证数据帧只能被发送到已经通过认证的设备上，从而防止非法设备窃听网络数据。

    ·***检测（IntrusionProtection）特性：指通过检测从端口收到的数据帧的源MAC地址，对接收非法报文的端口采取相应的安全策略，包括端口被暂时断开连接、永久断开连接或MAC地址被过滤（默认3分钟，不可配置），以保证端口的安全性。

25.6.2    端口安全的模式

    根据用户认证上线方式的不同，可以将端口安全模式划分为三类：MAC地址学习类型、802.1X认证类型、MAC地址认证及与802.1X认证组合类型。对端口安全模式的具体描述请参见下表。

25.6.3    端口安全的配置命令

    在端口安全功能未使能的情况下，端口安全模式可以进行配置但不会生效；在端口上有用户在线的情况下，端口安全模式无法改变。端口安全具体配置步骤如下：

    第1步：使能端口安全功能，在使能端口安全功能之前，需要关闭全局的802.1X和MAC地址认证功能。

        [system]port-security enable

    第2步：配置端口允许的最大安全MAC地址数，端口安全允许某个端口下有多个用户通过认证，但是允许的用户数不能超过规定的最大值。配置端口允许的最大安全MAC地址数有两个作用：一是控制能够通过某端口接入网络的最大用户数，二是控制端口安全能够添加的安全MAC地址数。

        [sysname-GigabitEthenret1/0/1]port-security max-mac-count count-value

    第3步：配置端口安全模式，在配置端口安全模式之前，端口上需要满足以下条件：

    ·802.1X认证关闭、端口接入控制方式为macbased、端口接入控制模式为auto。

    ·MAC地址认证关闭。

    ·端口未加入聚合组或业务环回组。

    （否则以上各条件若不满足，系统会提示错误信息，无法进行配置。反之，若端口上配置了端口安全模式，以上配置也不允许改变。）

    ·对于autolearn模式，还需要提前设置端口允许的最大安全MAC地址数。

    [sysname-GigabitEthernet1/0/1] port-security port-mode {autolearn | mac-authentication | mac-else-userlogin-secure | mac-else-userlogin-secure-ext | secure | userlogin | userlogin-secure | userlogin-secure-ext | userlogin-secure-or-mac | userlogin-secure-or-mac-ext | userlogin-without}

    第4步：配置端口NeedToKnow特性，该功能用来限制认证端口上出方向的报文转发。即，用户通过认证后，此次MAC为目的地址的报文都可以正常转发。可以设置以下三种方式：

    ·ntkonly：仅允许目的MAC地址为已通过认证的MAC地址的单播报文通过；

    ·ntk-withbroadcasts：允许目的MAC地址为已通过认证的MAC地址的单播报文或广播地址的报文通过。

    ·ntk-withmulticasts：允许目的MAC地址为已通过认证的MAC地址的单播报文，广播地址或组播地址的报文通过。

    除缺省情况之处，配置了NeedToKnow的端口在以上任何一种方式都不允许未知MAC地址的单播报文通过。

    [sysname-GigabitEthernet1/0/1]port-security ntk-mode {ntk-withbroadcasts | ntk-withmulticasts | ntkonly}

    第5步：配置***检测特性，当设备检测到一个非法的用户通过端口视图访问网络时，该特性用于配置可能对其采取的安全措施，包括以下三种方式：

    ·blockmac：表示将非法报文的源MAC地址加入阻塞MAC地址列表中，源MAC地址为阻塞MAC地址的报文将被丢弃。此MAC地址在被阻塞3分钟（系统默认，不可配）后恢复正常。

    ·disableport：表示将收到非法报文的端口永久关闭。

    ·disableport-temporarily：表示将收到非法的端口暂时关闭一段时间。关闭时长可通过port-security timer disableport命令配置。

    [sysname-GigabitEthernet1/0/1]port-security intrusion-mode {blockmac | disableport | disableport-temporarily}

25.6.4    端口安全配置案例

    组网需求：

    在交换机的端口GigabitEthernet1/0/1上对接入用户做如下的限制：

    ·允许64个用户自由接入，不进行认证，将学习到的用户MAC地址添加为安全MAC地址；

    ·当安全MAC地址数量达到64后，停止学习；当再有新的MAC地址接入时，触发***检测，并将此MAC阻塞。

    可以看到端口的最大安全MAC数为64，端口模式为autolearn，***保护动作为BlockMacAccess。

    配置完成后，允许地址学习，学习到的MAC地址数可以用上述命令显示，如学习到5个，那么当前的安全MAC地址数就为5，可以在端口视图下用display this命令查看学习到的MAC地址。

    当学习到的MAC地址数达到64后，用命令display port-security interface可以看到端口模式变为secure,再有新的MAC地址达到触发***保护，Trap信息如下：

25.6.5    端口安全常见故障排查

第26章    网络访问控制

    网络信息安全威胁在不断增加，对网络访问的控制成为网络管理的重要内容。网络访问控制通常包含通过安全策略组织不符合安全要求的终端访问网络，对WEB访问用户进行控制，以及通过访问控制列表过滤非法用户对网络的访问。

26.2    EAD解决方案

26.2.1    EAD概述

    传统的针对病毒的防御体系是以孤立的单点防御为主，如在个人计算机上安装防病毒软件、防火墙软件等。当发现新的病毒或新的网络***时，一般是由网络管理员发布病毒告警或补丁升级公告，要求网络中的所有计算机安装相关防御软件。传统的防御软件并不能有效应对病毒的威胁，主要表现在被动防御，缺乏主动抵抗能力；单点防御，对病毒的重复、交叉感染缺乏控制；分散管理，安全策略不统一。

    EAD（Endpoint Admisssion Defense，断点准入防御）整合孤立的单点防御系统，加强对用户的集中管理，统一实施企业安全策略，提高网络终端的主动抵抗能力。EAD方案通过安全客户端、安全策略服务器、接入设备以及第三方服务器的联动，可以将不符合安全要求的终端限制在“隔离区”内，防止“危险”终端对网络安全的损害，避免“易感”终端受到病毒的***。EAD的主要功能包括：

    ·检查终端用户的安全状态和防御能力；

    ·隔离“危险”和“易感”终端；

    ·强制修复系统补丁、升级防病毒软件；

    ·管理与监控。

    EAD提供了一个全新的安全防御体系，将防病毒功能与网络接入控制相融合，加强了对终端用户的集中管理，提高了网络终端的主动抵抗能力。EAD具有以下技术特点：

    ·整合防病毒与网络接入控制，大幅提高安全性；

    ·支持多种认证方式，适用范围较广；

    ·全面“隔离”危险终端；

    ·灵活、方便的部署与维护；

    ·详细的安全事件日志与审计；

    ·专业防病毒厂商的合作；

    ·具有策略实施功能，方便企业实施组织级安全策略；

    ·可扩展性的安全解决方案，有效保护投资。

26.2.2    EAD工作原理

    EAD的基本部件包括安全客户端、安全联动设备、安全策略服务器以及防病毒服务器、补丁服务器等第三方服务器。

    ·安全客户端是安装在用户系统上的软件，是对用户终端进行身份验证、安全状态评估、以及安全策略实施的主体。

    ·安全联动设备是企业网络中安全策略的实施点，起到强制网络接入终端进行身份验证、隔离不符合安全策略的用户终端、提供基于身份的网络服务的作用。安全联动设备可以是H3C的交换机、路由器等。

    ·安全策略服务器是EAD方案中的管理与控制中心，可运行在Windows、Linux平台下，兼具用户管理、安全策略管理、安全状态评估、安全联动控制、以及安全事件审计等功能。

    ·第三方服务器是指处于隔离区中、用于终端进行自我修复的防病毒服务器或补丁服务器。

    EAD的基本功能是通过以上组件的联动实现的，其基本过程如下：

    第1步：用户终端试图接入网络时，首先通过安全客户端由安全联动设备和安全策略服务器配合进行身份认证，非法用户将被拒绝接入网络。

    第2步：安全策略服务器对合法用户下发安全策略，并要求合法用户进行安全状态认证。

    第3步：由客户端的第三方桌面管理系统协同安全策略服务器对合法终端的补丁版本、病毒库版本等进行检测。之后，安全客户端将安全策略的检查结果上报安全策略服务器。

    第4步：安全策略服务器根据检查结果控制用户的访问权限。安全状态合格的用户将实施由安全策略服务器下发的安全设置，并由安全联动设备提供基于身份的网络服务；安全状态不合格的用户将被安全联动设备隔离到隔离区，可以进行系统的修复如补丁、病毒库的升级，直到安全状态合格。

    安全认证通过后在安全策略服务器的配合下可以对合法检测进行安全修复和管理工作，主要包括心跳机制、实时监控及监控发现异常后的处理。

26.2.3    EAD配置

    在H3C网络设备上，配置EAD的主要任务是设置安全策略服务器。可以RADIUS方案视图下使用如下命令来指定安全策略服务器的IP地址：

        [SWA-radius-name]security-policy-server ip-address

    缺省情况下，设备没有指定RADIUS服务器的安全策略服务器。

    在日常工作中，EAD客户端的部署工作量很大。例如，网络管理员需要手动为每个EAD客户端下载版本、升级客户端软件。在EAD客户端数目较多的情况下，这给管理员带来巨大的工作量。通过配置802.1X支持的EAD快速部署，可以使所有接入网络的终端用户通过特定的服务器，从而能够下载并安装EAD客户端。它由以下两个功能组成：

    ·用户受限访问：802.1X认证成功前（包括认证失败），终端用户只能访问一个特定的IP地址段，该IP地址段中可以配置一个或多个特定服务器，用于提供EAD客户端的下载升级或者动态地址分配等服务；

    ·用户HTTP访问URL重定向：终端用户在802.1X认证成功前（包括认证失败），如果用户使用浏览器访问网络，设备就会将用户访问的URL地址重定向到已配置的URL。

    可以在系统视图下配置用户受限访问地址段，其命令为：

        [SWA]dot1x ead-assistant enable

        [SWA]dot1x ead-assistant free-ip ip-address {mask-address | mask-length}

    同样，在系统视图下配置HTTP访问URL重定向的地址，其命令为：

        [SWA]dot1x ead-assistant url url-string

    注意：

        重定向的URL必须处在Free IP网段内，否则无法实现重定向。

    在上图所示网络中，交换机SWA作为安全联动设备，负责实施对用户的访问控制功能。服务器区域中包含有安全策略服务器、防病毒服务器等。为了实现EAD快速部署功能，将服务器区域的地址范围配置为Free IP网段，以使主机能够在通过认证前从服务器下载EAD客户端软件；同时设置WEB服务器，以使主机的HTTP访问能够被重定向。SWA上的相关配置如下：

        [SWA-radius-name]security-policy-server 192.168.2.1

        [SWA]dot1x ead-assistant enable

        [SWA]dot1x ead-assistant free-ip 192.168.2.0 24

        [SWA]dot1x ead-assistant ead-assistant url http://192.168.2.3

    因为EAD快速部署需要802.1X支持，所以需要在交换机上开启802.1X功能。SWA上的相关配置如下：

    [SWA]dot1x

    [SWA]interface ethernet 1/0/1

    [SWA-Ethernet1/0/1]dot1x

26.3    PORTAL认证

26.3.1    概述

    Portal认证通常也称为WEB认证，Portal认证网站通常也称为门户网站可以开展广告、社区服务、个性化的业务等，使宽带运营商、设备提供商和内容服务商形成一个产业生态系统。

    Portal可以通过强制接入终端实施补丁和防病毒策略，加强网络终端对病毒***的主动防御能力，其扩展功能主要包括如下：

    ·在Portal身份认证的基础上增加了安全认证机制，可以检测接入终端上是否安装了防病毒软件、是否更新了病毒库、是否安装了非法软件、是否更新了操作系统补丁等；

    ·用户通过身份认证后仅仅获得访问部分互联网资源（非受限资源）的权限，如病毒服务器、操作系统补丁更新服务器等；当用户通过安全认证后便可以访问更多的互联网资源（受限资源）。

    Portal体系主要由4个基本要素组成：认证客户端、接入设备、Portal、认证/计费服务器。除此之外根据桌面安全要求可以选择安装安全策略服务器。

    认证客户端是安装于用户终端的客户端系统，为运行HTTP/HTTPS协议的浏览器或运行Portal客户端软件的主机。

    交换机、路由器等宽带接入设备统称接入设备，主要有三方面的作用：

    ·在认证之前，将认证网段内用户的所有HTTP请求都重定向到Portal服务器；

    ·在认证过程中，与Portal服务器、安全策略服务器、认证/计费服务器交互，完成身份认证/安全检查/计费的功能；

    ·在认证通过后，允许用户访问被管理员授权的互联网资源。

    Portal服务器是接收Portal客户端认证请求的服务器端系统，提供免费门户服务和基于WEB认证的界面，与接入设备交互认证客户端的认证信息。

    Portal服务器是通过接收Portal客户端认证请求的服务器端系统，提供免费门户服务和基于WEB认证的界面，与接入设备交互认证客户端的认证信息。

    认证/计费服务器与接入设备交互，完成对用户的认证和计费。

    安全策略服务器则与Portal客户端、接入设备进行交互，完成对用户的安全认证，并对用户进行授权操作。

    以上五个基本要素的交互过程为：

    ·未认证用户访问网络时，在IE地址栏输入一个互联网地址，那么此HTTP请求在经过接入设备时会被重定向到Portal服务器的WEB认证主页上；若需要使用Portal的扩展认证功能，则用户必须使用Portal客户端。

    ·用户在认证主页/认证对话框中输入认证信息后提交，Portal服务器会将用户的认证信息传递给接入设备。

    ·然后接入设备再与认证/计费服务器通信进行认证和计费。

    ·认证通过后，如果未对用户采用安全策略，则接入设备会打开用户与互联网的通路，允许用户访问互联网资源；如果对用户采用了安全策略，则客户端、接入设备、与安全策略服务器交互，对用户的安全检测通过之后，安全策略服务器根据用户的安全性授权用户访问受限资源。

26.3.2    PORTAL认证方式

    根据客户端与接入设备之间是否有三层设备，Portal认证方式分为非三层认证方式和三层认证方式。

    根据地址分配方式的不同，非三层认证方式yo又包括有直接认证方式和二次地址分配认证方式。

    ·直接认证方式：用户在认证前通过手工配置或DHCP直接获取一个IP地址，只能访问Portal服务器，以及设定的免费访问地址；认证通过后即可访问网络资源。

    ·二次地址分配认证方式：用户在认证前通过DHCP获取一个私网IP地址，只能访问Portal服务器，以及设定的免费访问地址；认证通过后，用户会申请到一个公网IP地址，即可访问网络资源。该认证方式解决了IP地址规划和分配问题，对未通过认证的用户不分配公网IP地址。

    三层认证方式与非三层认证方式的区别是：

    ·组网方式不同。三层认证方式的认证客户端和接入设备之间可以跨越三层转发设备；非三层认证方式则要求认证客户端和接入设备之间没有三层设备；

    ·用户标识不同。三层认证方式中接入设备不会学习认证客户端的MAC地址信息，因此以IP地址唯一标识用户；非三层认证方式中，以IP和MAC地址的组合来唯一标识用户。

26.3.3    PORTAL认证过程

    三层认证方式与非三层直接认证方式具有相同的认证流程，其过程如下：

    1）Portal用户通过HTTP协议发起认证请求。HTTP报文经过接入设备时，对于访问Portal服务器或设定的免费访问地址的HTTP报文，设备允许其通过；对于访问其他地址的报文，接入设备将其重定向到Portal服务器。Portal服务器提供Web页面供用户输入用户名和密码来进行认证。

    2）Portal服务器与接入设备之间进行CHAP（Challenge Handshake Authentication Protocol，质询握手验证协议）认证交互，若采用CHAP（Password Authentication Protocol，密码验证协议）认证则直接进入下一步骤。

    3）Portal服务器将用户输入的用户名和密码组装成认证请求报文发往接入设备，同时开启定时器等待认证应答报文。

    4）接入设备与RADIUS服务器之间进行RADIUS协议报文的交互。

    5）接入设备向Protal服务器发送认证应答报文；

    6）Portal服务器向客户端发送认证通过报文，通知客户端认证（上线）成功。

    7）Portal服务器向接入设备发送认证应答确认。

    8）客户端和安全策略服务器之间进行安全信息交互。安全策略服务器检测接入终端的安全性是否合适，包括是否安装防病毒软件、是否更新病毒库、是否安装了非法软件、是否更新操作系统补丁等。

    9）安全策略服务器根据用户的安全性授权用户访问非授权资源，授权信息保存到接入设备中，接入设备将使用该信息控制用户的访问。

    以上步骤中，步骤8、9为Portal认证扩展功能的交互过程。

    三层认证方式下的二次地址分配认证方式流程如上图所示（步骤1-6与直接认证方式中 步骤1-6相同）；

    7）客户端收到认证通过报文后，通过DHCP请求获取新的公网IP地址，并通知Portal服务器用户已经获得新IP地址。

    8）Portal服务器通知接入设备客户端获得新公网IP地址。

    9）接入设备通过检测ARP协议报文发现了用户IP变化，并通告Portal服务器已检测到用户IP变化。

    10）Portal服务器通知客户端上线成功。

    11）Portal服务器向接入设备发送IP变化确认报文。

    12）客户端和安全策略服务器之间进行安全信息交互，安全策略服务器检测接入终端的安全性是否合格，包括是否安装防病毒软件、是否更新病毒库、是否安装了非法软件、是否更新操作系统补丁等。

    13）安全策略服务器根据用户的安全性授权用户访问非授权资源，授权信息保存到接入设备中，接入设备将使用该信息控制用户的访问。

26.3.4    PORTAL配置

    Portal的基本配置包括配置Portal服务器、Portal Web服务器和在接口上启用Portal协议。

    可以在系统视图下配置Portal服务器，其命令如下：

        [SWA]portal server server-name

        [SWA-portal-server-name]ip ip-address [key {simple | cipher}]key-string

        [SWA-portal-server-name]port port-id

    其中主要参数含义如下：

    ·server-name：指定Portal服务器的名字；

    ·ip-address：Portal服务器的IP地址。若配置本地Portal服务器，则此地址为接入设备上与Portal客户端路由可达的三层接口IP地址；

    ·key-string：与Portal服务器通信需要的共享密钥；

    ·port-id：设备向Portal服务器主动发送报文时使用的目的端口号，缺省值为50100；

    对于采用web浏览器作为portal客户端的用户，可以配置portal Web服务器在Portal认证过程中向用户推送认证页面，同时Portal Web服务器也是设备强制重定向用户HTTP请求报文时所使用的服务器。在系统视图下配置Portal Web服务器，其命令如下：

    [SWA]portal web-server server-name

    [SWA-portal-sebsrv-name]url sting

    其中主要参数含义如下：

    ·server-name：指定Portal Web服务器的名字；

    ·url-string：HTTP报文重定向地址，缺省地址格式为http://ip-address

    配置完Portal服务器和Portal Web服务器后，还需要在接口上使能Portal认证，同时指定引用的Portal Web服务器、配置认证方式和服务类型。相关命令如下所示：

        [SWA-Vlan-inteface100]portal enable method {direct | layer3 | redhcp}

        [SWA-Vlan-inteface100]portal apply web-server server-name

    其中主要参数如下：

    ·direct：直接认证方式；

    ·layer3：三层认证方式；

    ·redhcp：二次地址分配认证方式；

    ·server-name：Portal Web服务器的名字。

    如上图所示：主机PCA连接到交换机SWA上进行接入认证，交换机上进行Portal服务器配置，将主机的HTTP请求重定向到Portal Web服务器,由Portal Web服务器将用户的认证信息传递给接入设备；然后接入设备再与认证/计费服务器通信进行认证和计费。

    因没有DHCP服务器，所以网络中采用三层直接方式的Portal认证。

    交换机SWA上的配置如下：

    因客户端还需要通过认证/计费服务器通信进行认证和计费；通过安全策略服务器进行网络资源访问授权，所以还需要在SWA中增加如下配置：

第27章    SSH

    用于远程登录的Telnet应用提供用户名密码验证，以确认登录用户的身份，但是其验证相对简单，且用户名和密码采用明文传输，导致设备的安全性降低。

    为了保障设备的安全，采用更为安全可靠的登录方式和验证协议成为趋势，由此诞生了SSH（Secure Shell）协议。SSH是一种安全的远程登录协议，基于TCP/IP传输层协议，可以采用口令方式或密钥方式实现安全认证，其安全性大大强于Telnet，在安全性要求较高的网络中，SSH已经成为远程登录的首选。

27.2    SSH基本原理

27.2.1    SSH概述

    Telnet是互联网上使用最广泛的远程登录协议。但是，Telnet协议本身并没有提供安全的认证方式，而且通过TCP传输的内容都是明文方式，用户名和密码可以通过网络报文分析的方式获得，存在着很大的安全隐患。另外，由于系统对Telnet用户采用简单的口令验证，所以DOS***、主机IP地址欺骗、路由欺骗等恶意***都可能给系统带来致命的威胁。

    SSH（Secure Shell）是一种安全的远程登录协议。SSH协议基于TCP进行传输，端口号是22。通过使用SSH协议，远程登录访问的安全性得到了很大的提升。此外，SSH还提供SFTP（SSH File Transfer Protocol），对在公共的Internet上的数据传输进行了安全保护。

    SSH协议具有如下特点：

    ·完善的数据传输机密性：SSH协议支持DES、3DES数据加密算法。SSH客户端与服务器端通讯时，用户名及口令均进行了加密，有效防止了非法用户对口令的窃听。同时SSH服务对传输的数据也进行了加密。保证了数据的安全性和可靠性。

    ·多种认证方式：SSH支持公钥验证方式、密码验证方式、不验证方式，用户可以灵活进行选择。

    公钥验证方式是SSH必须支持的认证方式。使用了公钥验证方式后，客户端生成一段由用户私钥签名的数据发送到服务器，服务器收到用户公钥和签名数据后，会检查用户公钥和签名的合法性，如果都合法则接受该请求，否则拒绝。

    密码验证方式为SSH可选支持的认证方式之一。Client将用户名和密码发送给服务器服务器根据既定的验证方式进行密码验证（本地或远程）验证成功，则接受该请求，否则拒绝。

    不验证方式也为可选支持的认证方式之一。配置用户为不认证方式时，服务器在任何情况下必须返回验证通过，此时SSH用户认证成功。

    ·所支持的RSA认证具有***防御功能：SSH中使用的RSA方式是最著名的且被广泛应用的公钥加密体制。RSA的加密方式为非对称加密，密钥为一对相关密钥（公钥和私钥），其中任一个密钥加密的信息只能用另一个密钥进行解密。私钥的唯一性决定其不仅可以用于加密，还可以作为数字签名，防止非法用户篡改数据。

    当前SSH有两个版本——SSH1和SSH2。但随着SSH的成熟应用，大多数实现都已经基于SSH2。后续介绍将以SSH2为基础进行介绍。

    SSH协议框架中最主要的部分是三个协议：传输层协议、用户认证协议和连接协议。同时SSH协议框架中还为许多高层的网络安全应用协议提供扩展的支持。它们之间的层次关系可以用上图来表示，在这个框架中：

    ·传输层协议（The Transport Layer Protocol）提供服务器认证，数据机密性，信息完整性；

    ·用户认证协议（The User Authentication Protocol）为服务器提供客户端的身份鉴别；

    ·连接协议（The Connection Protocol）将加密的信息隧道复用成若干个逻辑通道，提供给更高层的应用协议使用。

    各种高层应用协议可以相对于独立于SSH基本体系之外，并依靠这个基本框架，通过连接协议使用SSH的安全机制。

27.2.2    SSH工作过程

    在整个工作过程中，为实现SSH的安全连接，服务器端与客户端要经历如下五个阶段；

1. 版本号协商阶段

   版本号协商阶段的主要目的是客户端与服务器端协商双方都能够支持的SSH版本，具体步骤如下：

1. 服务器打开端口22，等待客户端连接；

2. 客户端向服务器端发起TCP初始连接请求，TCP连接建立后，服务器向客户端发送第一个报文，包括版本标志字符串，格式为“SSH-<主协议版本号>.<次协议版本号>-<软件版本号>”，协议版本号由主版本号和次版本号组成，软件版本号主要是为了调试使用；

3. 客户端收到报文后，解析该数据包，如果服务器端的协议版本号比自己的低，且客户端能支持服务器端的低版本，就使用服务器端的低版本号，否则使用自己的协议版本号；

4. 客户端回应服务器，回应报文包含了客户端决定使用的协议版本号；

5. 服务器比较客户端发来的版本号，决定是否同客户端一起工作；如果协商成功，则进入密钥和算法协商阶段，否则服务器断开TCP连接。




2. 密钥和算法协商阶段：

   在此阶段，客户端和服务器交换算法协商报文，从而协商出最后使用的算法并生成会话密钥和会话ID。具体步骤如下：

     ·服务器端和客户端分别发送算法协商报文给对端，报文中包含自己支持的公钥算法列表、加密算法列表、MAC（Message Authentication Code，消息验证码）算法列表、压缩

算法列表等； 

        ·服务器端和客户端根据对端和本端支持的算法列表得出最终使用的算法；

        ·服务器端和客户端利用DH交换（Diffie-Hellman Exchange）算法、主机密钥对等参数，生成会话密钥和会话ID。

    通过以上步骤，服务器和客户端就取得了相同的会话密钥和会话ID。对于后续传输的数据，两端都会使用会话密钥进行加密和解密，保证了数据传送的安全。在认证阶段，两端会使用会话密钥进行加密和解密，保证了数据传送的安全。在认证阶段，两端会使用会话ID用于认证过程。

3.认证阶段：

    此阶段涉及到客户机与服务器间的认证过程，具体步骤如下：

    ·客户端向服务器发送认证请求，认证请求中包含用户名、认证方法、与该认证方法相关的内容（如：password认证时，内容为密码）；

    ·服务器对客户端进行认证，如果认证失败，则向客户端发送认证失败消息，其中包含可以再次认证的方法列表；

    ·客户端从认证方法列表中选取一种认证方法再次进行认证；

    ·该过程反复进行，直到认证成功或者认证次数达到上限，服务器关闭连接为止。

    SSH提供两种认证方法：

    ·password认证：客户端向服务器发出password认证请求，将用户名和密码加密后发送给服务器；服务器将该信息解密后得到用户名和密码的明文，与设备上保存的用户名和密码进行比较，并返回认证成功或失败的消息；

    ·publikey认证：采用数字签名的方法来认证客户端。目前，设备上可以利用RSA两种公共密钥算法实现数字签名。客户端发送包含用户名、公共密钥和公共密钥算法的publickey认证请求给服务器端。服务器对公钥进行合法性检查，如果不合法，则直接发送失败消息；否则，服务器利用数字签名对客户端进行认证，并返回认证成功或失败的消息。

4.会话请求阶段：

    认证通过后，客户端向服务器发送会话请求。服务器等待并处理客户端的请求。在这个阶段，请求被成功处理后，服务器向客户端回应SSH2_MSG_CHANNEL_SUCCESS包，SSh进入交互会话阶段；否则回应SSH2_MSG_CHANNEL_FAILURE包，表示服务器处理请求失败或者不能识别请求。

5.交互会话阶段：

    会话请求成功后，连接进入交互会话阶段。在这个模式下，数据被双向传送。客户端将要执行的命令加密后传给服务器，服务器接收到报文，解密后执行该命令，将执行的结果加密发还给客户端，客户端将接收到的结果解密后显示到终端上。

27.3    SFTP介绍

    通常情况下，传输文件、共享资源主要通过FTP协议来实现。和TFTP协议相比，FTP提供了必要的可靠性，然而对于一些要求网络安全级别比较高，需要严格防范传输数据被监听的情况来说，FTP协议就无法胜任了。

    SFTP（SSH File Transfer Protocol或Secure File Transfer Protocol）是SSH 2.0中支持的功能。和FTP不同的是，SFTP传输协议默认采用加密方式来传输数据。SFTP建立在SSH连接的基础之上，它使得远程用户可以安全地登录设备，进行文件管理和文件传送等操作，为数据传输提供了更高的安全保障。同时，由于设备支持作为客户端的功能，用户可以从本地设备安全登录到远程设备上，进行文件的安全传输。

27.4 配置SSH

27.4.1    配置SSH服务器

    在设备上配置SSH特性之前，设备必须要生成DSA或RSA密钥。虽然一个客户端只会采用DSA和RSA公钥算法中的一种来认证服务器，但是由于不同客户端支持的公钥算法不同，为了确保客户端能够成功登录服务器，建议在服务器上同时生成DSA和RSA两种密钥对。

    在系统视图下配置生成DSA、ECDSA或RSA密钥，在某些早期软件版本中仅支持RSA公钥算法。其参考命令如下：

    [SWA]public-key local create {dsa | ecdsa | rsa}

    缺省情况下，SSH服务器功能处于关闭状态。所以，需要在系统视图下使能SSH服务，其参考命令如下：

    [SWA]ssh server enable

    上述配置完成后，设备生成了DSA、ECDSA或RSA密钥对，且具有SSH服务器功能。

    SSH客户端通过VTY用户界面访问设备。因此，需要配置SSH客户端登录时采用的VTY用户界面，使其支持SSH远程登录协议。配置结果在客户端下次请求登录时生效。

    在VTY用户界面视图下配置登录用户界面的认证方式为scheme方式，命令如下：

        [SWA-ui-vty0-4]authentication-mode scheme

    在VTY用户界面视图下配置所在用户界面支持SSH协议。命令如下：

        [SWA-ui-vty0-4]protocol inbound {all | ssh | telnet}

    缺省情况下，系统支持所有的协议。

    SSH用户具有两种服务类型：Stelnet和SFTP。Stelnet即Secure Telnet，是指传统的SSH服务；SFTP即Secure FTP。

    如果要使用传统的SSH服务，则需要在系统视图下配置SSH用户为Stelnet服务类型并指定认证方式，命令如下：

    [SWA]ssh user username service-type stelnet authentication-type {password | {any | passord-publickey | publickey} assign {pki-domain domain-name | publickey keyname}}

    命令中参数含义如下：

    ·username：SSH用户名，为1-80个字符的字符串

    ·stelnet：服务类型为安全的Telnet。

    ·authenticaiton-type：SSH用户的认证方式。包括：

    ·password：强制指定该用户的认证方式为password。

    ·any：指定该用户的认证方式可以是password，也可以是publickey。

    ·password-publickey：强制指定该用户的认证方式为password和publickey认证同时满足。客户端版本为SSH1的用户只要通过其中一种认证即可登录；客户端版本为SSH2的用户必须两种认证都通过才能登录。

    ·publickey：强制指定该用户的认证方式为publikey。

    ·assign：指定用于验证客户端的参数。

    pki-domian domian-name：指定验证客户端证书的PKI域。domain-name表示PKI域的名称，为1-31个字符的字符串，不区分大小写。服务器端使用保存在该PKI域中的CA证书对客户端证书进行合法性检查，无需提前保存客户端的公钥，能够灵活满足大数量客户端的认证需求。

    publickey keyname：为SSH用户分配一个已经存在的公钥。keyname表示已经配置的客户端公共密钥名。

    需要注意的是，对于AAA用户，即使没有创建对应的SSH用户，只要能通过AAA认证，且设置的服务类型为SSH，则该用户仍然可以通过password认证方式登录服务器。

    SSH用户采用publickey认证方式时，需要在服务器端配置客户端的DSA、ECDSA或RSA主机公钥，并在客户端为该SSH用户指定与主机公钥对应的DSA、ECDSA或RSA私钥，以便当客户端登录服务器时，对客户端进行验证。

    可以通过从公钥文件中导入和手工配置两种方式来在服务器配置客户端的公钥。

    ·从公钥文件中导入客户端的publickey公钥时，系统会自动自动将客户端生成的公钥文件转换为PKCS（Public Key Cryptography Standards，公共密钥加密标准）编码形式，并实现客户端公钥的配置。这种方式需要客户端事先将publickey密钥的公钥文件通过FTP/TFTP以二进制（binary）方式上传到服务器端。

    ·手工配置客户端的publickey公钥时，可以采用拷贝粘贴的方式将客户端的主机公钥配置到服务器端。这种方式要求拷贝粘贴的主机公钥必须是未经转化的DER（Distinguished Encoding Rules，特异编码规则）公钥编码格式。

    在系统视图下配置从公钥文件中导入客户端的publickey公钥，命令如下：

        [SWA]public-key peer keyname import sshkey filename

            [SWA]public-key peer keyname

            [SWA-pkey-public-key]直接输入公钥内容

            [SWA-pkey-public-key]peer-public-key end

    以上配置过程中，public-key peer命令用来进入公共密钥视图，然后可以输入密钥数据。在输入密钥数据时，字符之间可以有空格，也可以按回车继续输入数据。所配置的公钥必须是未经转换的DER公钥编码格式的十六进制字符串。

    密钥输入完成后，用public-key-code end命令退回到系统视图，结束公钥的编辑过程，系统自动保存配置的公钥。

27.4.2    配置SSH客户端

    缺省情况下，客户端用设备路由指定的接口地址访问SSH服务器。可以在系统视图下为SSH客户端指定源IP地址或源IP地址或源接口，命令如下所示：

        [SWA]ssh client source {ip ip-address | interface intface-type interface-number} [***-instance ***-instance-name] [identity-key {dsa | rsa} | prefer-compress zlib | prefer-ctos-cipher {3des | aes128 | aes256 | des} | prefer-ctos-pipher{3des | aes128 | aes256 | des} | prefer-ctos-hmac{md5 | md5-96 | sha1 | sha1-96} | prefer-kex {dh-group-exchange | dh-group | dh-group14} | prefer-stoc-cipher {3des | aes256 | des} | prefer-stoc-hmac {md5 | md5-96 | sha1 | sha1-96}]* [dscp dscp-value | publickey keyname | source {interface interface-number | ip ip-address}]*

27.5.2    SFTP配置示例

27.6    SSH的显示和维护

第7篇    园区网管理维护

第28章    园区网管理维护综述

    任何网络的安全可靠运行都由多方面决定，它以精心设计细心建设为基础，在完善周到的维护管理才健康运行。同样，在有了良好的设计和建设之后，必须采用科学有效的管理手段来维护才可以确保园区网的健康运行，提供不间断服务。但随着网络规模的增大，网络设备种类的繁杂给园区网管理带来了更大的挑战。如网络中的不同角色，路由器、交换机、服务器、应用终端等的管理，不同厂商的设备混合组网的管理都给网络管理带来了麻烦。

28.2    园区网维护管理的目标及难题

    当一个园区网建设完成并投入使用之后，网络管理员不得不面对的问题就是确保网络的健康运行。这也是网络维护管理的首要目标。为了达成此目标，必须采取相应的措施和手段实现网络设备的终端的实时监控或定期监控，使其工作状态了然于胸。但这并非网络维护管理工作的全部，任何网络设备和传输线路都不可能百分之百的不间断运行，当某个网络设备故障或者某个传输线路终端之后，网络管理员应当能够在最短时间内立即知晓故障点，故障原因并针对此故障采取有效措施快速恢复网络运行。

    随着业务规模的扩大，新业务的集成应用，网络是否能够继续支撑当前业务的发展也是网络使用者和管理者关注的重要内容。因此掌握网络业务现状，快速响应新需求，调整业务部署和对网络进行升级扩容也是网络维护管理的重要目标之一。网络的维护管理工作做得是否到位，就取决于对上述重要目标的实现程度。

    网络建设者为了平衡性能和成本各方面因素，选择的网络设备种类、设备厂商和型号越来越多样化，因此各网络设备的特性差异，性能差异也非常明显。使用同一套网络管理系统实现如此多样化设备的管理是网络管理必须解决的首要难题。要兼容不同厂商设备实现细节差异和私有协议的应用也是维护管理中的又一难题。

    设备数量大，物理位置分散，管理任务繁重，要求网管系统性能优异，远程管理易于实施。化繁为简是大型园区网络管理新的课题。

    不同的操作系统有不同的系统漏洞，从网络设备到网络终端到服务器以及传输线路处处都可能成为网络***的***切入点。网络建设和管理一旦考虑不周，很容易出现顾此失彼的现象。将网络置于危险境地。

    网络设计的疏忽，新业务的开展都可能出现网络流量在某些物理链路或逻辑链路上形成拥塞。网络流量***更新更是网络拥塞的罪魁祸首。网络流量拥塞的及时发现并解决也是网路管理面临的难题之一。

    网络设备记录日志和告警的时间混乱，导致日志告警产生的先后顺序无法准确判定给网络故障的定位和原因分析带来了困难，也许因为一条重要日志或告警信息的时间错误会将管理员的故障定位引入歧途，保证日志和告警信息的有序准确记录也是维护管理面临的难题之一。

28.3    网络维护管理的技术应用

    针对网络维护管理工作面临的难题，网络管理员都分别找到了相应的应对策略和解决方案。

    首先网络管理员依靠SNMP协议可以实现网络设备的统一管理。通过标准的MIB信息实现网络拓扑的发现和绘制，设备的基本信息查询和配置，设备Trap告警的统一管理。通过日志服务器的部署还可以实现网络设备重要日志的统一监管。

    为了应对不同厂商的差异，应在网络规划和建设中选择业界标准协议，选择具有良好兼容性的网络设备。如选择通用的OSPF路由协议而非私有路由协议，标准的LLDP（Link Layer Discovery Protocol）协议而非私有的拓扑发现协议。

    为了降低网管系统的管理任务，简化网络拓扑结构，选择恰当的网络拓扑是解决手段之一，同样部署堆叠和集群将多个物理设备联合成一个逻辑单元也能大幅降低网络管理单元数量，从而更进一步简化网络拓扑，让网络管理简单。

    为了消除网络安全隐患，及时发现网络瓶颈和拥塞，流量统计、流量镜像、***防范等措施的部署是必要的。通过流量统计可以总结发现网络流量分布状况，预测网络流量的发展。通过各种流量镜像技术可以及时发现网络隐患，审计终端用户的网络行为。通过***防范部署可以有效的预防非法流量导致设备的宕机和网络瘫痪。

    在网络中部署NTP服务器并运行NTP协议，可以保证所有网络设备具有统一的时钟参考，日志告警信息记录的时间准确无误，为网络故障定位提供准确可靠的依据。

第29章    SNMP及日志管理

    随着网络规模的不断扩大，网络拓扑环境和应用环境日趋复杂，而对网络进行精确管理的要求越来越高，并且自动化网络管理日益成为网络管理的一个趋势。

    SNMP（Simple Network Managemant Protocol，简单网络管理协议）提供了一种从网络设备中收集网络管理信息的方法，也为设备向网络管理工作站报告问题和错误提供了一种方法。SNMP可以屏蔽不同设备的物理差异，实现对不同厂商产品的自动化管理。

    SNMP已经成为IP领域网络管理的标准协议，并被广泛应用。

29.2    SNMP的基本架构

29.2.1    网络管理关键功能

    ISO（Internation Organization for Standardzation，国际化标准组织）定义的网络管理的关键功能有：

        ·故障管理：对网络中的问题或故障进行定位的过程。通过提供快速检查问题并启动恢复过程的工具，使网络的可靠性增强。

        ·计费管理：测量用户对网络的资源的使用情况，并据此建立度量标准，设定额度，确定费用以及给用户开具账单。

        ·配置管理：从网络获取数据，并使用这些数据对网络设置的配置进行管理的过程。目标是监视网络运行的环境和状态，改变和协调网络设备的配置，确保网络有效和可靠地运行。

        ·性能管理：保证网络保持在可通过和不拥塞的状态，为用户提供更好的服务。目标是通过监控网络的运行状态、调整网络参数来改善网络的性能，确保网络的安全运行。

        ·安全管理：通过控制信息的访问点保护网络中的敏感信息。

29.2.2    网络管理面临的挑战与SNMP

    网络应用的发展对网络管理提出了更高的要求和挑战：

    ·网络规模越来越大，网络设备之间的连接与业务越来越复杂，单纯靠人工管理这些设备和业务已经不可行。

    ·在同一个网络中，设备的种类越来越多，必须要求使用一种标准的管理手段才能完成这些设备的统一管理。

    ·网络管理要求实现不间断的管理，因此在无人值守的情况下网络管理必须提供一种自动化的工具来完成网络管理功能。

    SNMP作为网络管理协议，刚好解决了目前网络管理中遇到的几大挑战，并在花费最少的人力、设备、资金的前提下提供更智能的网络管理服务。

29.2.3    SNMP基本架构

    一个基于SNMP的网络管理模型，有四个重要的组成部分：

    ·NMS（Network Managerment Station，网络管理站）：NMS通常是一个独立的设备，上面运行着网络管理的应用程序。网络管理应用程序能够提供一个非常友好的人机交互界面，网络管理员能通过它来完成绝大部分的网络管理工作。NMS通过SNMP协议从SNMP Agent获取管理信息，并且监听UDP162端口，接收SNMP Agent发送的Trap/告警信息。同时NMS还努力还努力做到提供失效管理、安全管理、计费管理、配置管理和性能管理。

    ·SNMP Agent（SNMP代理）：SNMP Agent是驻留在被管理设备的一个软件模块，它主要负责如下管理任务：

        ·监听UDP161端口，接收和处理来自NMS的请求报文，并将处理结构返回给NMS；

        ·在一些紧急的情况下，SNMP Agent还会主动发送Trap告警报文给NMS。

    ·SNMP（Simple Network Managerment Protocol，简单网络管理协议）：NMS与被管理设备之间的交互遵循SNMP协议规定。

    ·MIB（Managerment Information Base，管理信息库）：MIB是存储在被管理设备中的管理信息数据库。

29.2.4    管理信息库

    MIB（Managerment Information Base，管理信息库），是指被管理对象信息的集合，也就是所有代理进程包含的、并且能够被管理进程进行查询和设置的信息的集合。

    SNMP Agent通过MIB把被管对象按照一定的规则组织起来并以树状结构进行存储。NMS通过SNMP协议向Agent发出查询，设置MIB等操作即可实现对被管理设备的管理操作。只有在被管理设备的MIB库中存在的对象才能被SNMP管理。

    管理对象信息包括OID（Object Identifier，对象标识符）、对象数据类型以及对象访问权限等属性信息，这些信息通过SMI（Structure of Management Informaiton，管理信息结构）规定的语法和组织形式组成一个树形的MIB数据库。

    MIB按照一种层次式属性结构排列。一个对象在树中的位置非常清楚地标识了如何访问该对象。在MIB树中，一个对象称为MIB树的一个节点，每个节点都有全局唯一的名字，并且具有同一个父节点的编号不能重复。

    对一个节点的访问可以通过两种方式实现，一种是直接引用节点的名字，例如在图中节点F可以直接使用节点的名字“F”唯一标识该节点，每个节点都有全局唯一的名字，并且具有同一个父节点的子节点的编号不能重复。

    对一个节点的访问可以通过两种方式实现，一种是直接引用节点的名字，例如在图中节点F可以直接使用节点的名字“F”唯一标识该节点；另外一种方式是使用OID（Object Identifer，对象标识符）来引用。

    OID（Object Identifier，对象标识符）用于命名一个对象。它还标识了如何在MIB中访问该对象。OID由4字节的整数序列组成，用来标识被管对象。MIB树中的每个节点对应一个整数，从根节点到树中任意节点所经过的节点所对应的整数组成的有序整数序列，即为一个有效的OID。例如F可以表示为“1.2.2.1”。显然可以通过提供OID来确定所要访问的MIB对象。

    当对一个MIB节点进行访问的时候，所访问的对象的一个特定实例，而不是一个对象类型。

    在MIB树中，节点根据其位置的不同，大致可以分为两类：

        ·叶子节点：不包含子节点的节点，称为叶子节点。在MIB树中，只有叶子节点是具有管理意义的节点。有的叶子节点不能被访问（not-accessible，不能被访问的叶子节点经常被用做表变量的索引项）；有的不仅能读写，还能被创建（read-only）；有的既允许读，又允许写（read-write）;有的不仅有读写，还能被创建（read-create，SNMPv2概念；SNMPv1也有创建功能，通过对具有read-write属性的表变量叶子节点，实行写操作来实现）。

        ·非叶子节点：具有子节点的节点，称为非叶子节点。MIB树中的非叶子节点表明了该节点的子孙节点的相关性，这些子孙节点一般具有大体相同的功能属性，通过访问这些节点，可以实现相对独立的功能。非叶子节点不能通过SNMP协议直接访问。

    叶子节点又分为两类：

        ·表型节点（TABULAR）：又称为列对象，这些节点在设备中代表一个抽象的对象，每个对象在设备中对应多个实例，NMS获取的对象信息实际上是该对象的某一个实例信息的访问。例如在一个设备中存在多个接口，要想通过MIB获取一个接口的接口描述（ifDescr），必须指定要获取的接口的标识，接口标识实际使用的是接口索引（ifIndex），所以对于接口索引为1的接口，要获取该接口的描述信息，需要访问的实例为“ifDescr.1”。

        ·标量节点（SCALAR）：标量节点在MIB中只有一个实例对象，对象和实例之间不存在模糊性。但是为了和表型节点的约定一致，并区别一个对象类型和一个对象实例，SNMP规定一个标量对象的实例标识由它的对象标识符加上0组成。例如对于“sysObjectID”，一个设备只有一个值，因此“sysObjectID”为标量节点，该标量节点的实例标识为“sysObjectID.0”。

    图中MIB树是一个标准的MIB树，MIB树的根节点没有名字或编号，但是下面有三个子树：

        ·ccitt（0）：由CCITT管理

        ·iso（1）：由ISO管理

        ·joint-iso-ccitt：由ISO和CCITT共同管理

    每一个子树下面根据需要又定义了不同的子树。

29.3        SNMP标准介绍

29.3.1    SNMP版本

    从1988年SNMPv1发布至今，SNMP协议发展经历了多个版本的演变。目前常用的版本有：

    ·SNMPv1：该版本基于SGMP（Simple Gateway Monitoring Protocol，简单网关监视协议）发展而来，于1988年发布，定义于RFC1157。

    ·SNMPv2c：该版本使用了SNMPv1的消息封装以及团体名的概念，因此称为“基于团体的SNMPv2”。该版本发布在1996年，在RFC1901-1908中定义。虽然该版本应用比较广泛，但是该版本一直没有成为一个标准协议，只能称为“事实上的标准”。

    ·SNMPv3：2002年SNMPv3正式成为标准协议，以替代SNMPv1标准。SNMPv3标准目前在RFC3411-3418中定义。

29.3.2    SNMPv1

    SNMPv1 Agent和NMS之间通过标准消息通信，使用UDP协议作为传输层协议，每一个消息都是一个单独的报文。UDP使用无连接的服务，因此SNMP不需要依靠在Agent和NMS之间保持连接来传输信息。

    SNMPv1支持5种消息类型：Get-Request、GetNext-Request、Set-Request、Get-Response和Trap。NMS使用Get-Request和GetNext-Request从拥有SNMP Agent的网络设备中检索消息。NMS使用Set-Request实现设备中参数的远程配置，SNMP Agent将配置结果以Get-Response消息反馈给NMS。Trap是SNMP Agent发送给NMS的非请求消息，这些消息通知NMS被管理设备发生一个特定事件。例如可以通过Trap消息报告设备的某个接口从linkup状态变为linkdown状态。

    SNMP Agent和NMS之间是通过团体名（Community Name）来进行安全机制认证的，团体名以明文传输，因此SNMPv1的安全性较弱。团体是SNMP Agent和若干个经SNMP Agent授权的网路管理站应用程序组成的。每个团体名都有自己的标识，即团体名，来区别于其他的团体。实质上，团体名充当一个相关权限的密码。当Agent收到一个来自NMS的请求报文时，首先检查这个团体名是否存在，如果不存在，对此报文不再继续处理而直接丢弃；如果存在，则检查请求报文中所请求的节点是否是在该团体所被允许访问的对象集合中，并且该访问的行为是否被允许。

29.3.3    SNMPv2c

29.3.4    SNMPv3

29.3.5    SNMP v1/v2C/v3对比

29.4    SNMP在交换机上的配置

29.4.1    SNMP配置任务

    实现SNMP的配置，关键配置任务有5步。分别为启动SNMP Agent任务、打开SNMP协议开关、创建MIB视图、创建团体（SNMPv1&SNMPv2c）或创建组和创建用户（SNMPv3）：

    ·    启动SNMP Agent服务

    [H3C]snmp-agent

    snmp-agent命令用来启动SNMP Agent。缺省情况下，SNMP Agent功能关闭。执行任何带snmp-agent关键字的配置命令都可以启动SNMP Agent。

    ·    配置SNMP运行版本

    [H3C]snmp-agent sys-info version {all | v1| v2c |v3}

    缺省情况下开启SNMPv3版本.

    ·    配置MIB视图

    [H3C]snmp-agent mib-view {excluded | included} view-name oid-tree [mask mask-value]

    其中主要参数说明如下：

    ·excluded：表示当前视图下不包括该MIB子树的任何节点（即禁止访问MIB子树的所有节点）。

    ·include：表示当前视图包括该MIB子树的所有节点（即允许访问MIB子树的所有节点）。

    ·view-name：视图名，为1-32个字符的字符串。

    ·oid-tree：MIB子树，用子树根节点的OID（如1.4.5.3.1）或名称（如“system”）表示。OID是由一系列的整数组成，标明节点在MIB树中的位置，它能惟一标识一个MIB库中的对象。

    MIB视图是MIB的子集，由视图名和MIB子树来惟一确定一个MIB视图。视图名相同但包含的子树不同，则认为是不同的视图。

    ·    创建团体：SNMPv1和SNMPv2c使用团体名进行访问鉴别，因此使用SNMPv1或SNMPv2进行网络管理前，必须配置访问团体。下面命令用于团体的配置：

    [H3C]snmp-agent community {read | write}{simple | cipher} community-name [mib-view view-name] [acl acl-number | acl ipv6 ipv6-acl-number]*

第30章    *LLDP技术

    随着数据网络的发展，网络上的设备种类日益繁多。为了使不同厂商的设备能够在网络中相互发现并交互各自的系统级配置信息，需要有一个标准的信息交流平台。

    在这种背景下，IEEE（Institute or Electrical and Electronics Engineer，电气与电子工程师协会）制定了LLDP（Link Layer Discovery Protocol，链路层发现协议），提供了一种标准的链路层发现方式。设备可以将其主要能力、管理地址、设备标识、接口标识等信息组织成不同的TLV（Type/Length/Value，类型/长度/值），并封装在LLDPDU（Link Layer Discovery Protocol Data Unit，链路层发现协议数据单元）中发布给自己直连的邻居，邻居收到这些信息后将其以标准MIB（Managerment Information Base，管理信息库）的形式保存起来，以供网络管理系统查询及判断链路的通信状况。

30.2    LLDP简介

    为了便于网络管理和维护，大多数设备厂商都制定了自己的链路层发现协议。但当多个厂商的设备联合组网时，这些私有的协议都将无能为力，因此制定一种能够在多个厂商间互操作的链路层发现协议变得迫在眉睫。LLDP因此诞生并提供如下主要功能来解决网络维护管理的难题。

        ·运行LLDP的网络设备以标准的方式发现并利用网络物理拓扑信息。例如，交换机A和交换机B连接，通过LLDP协议，在A设备上就知道对端的设备名称、MAC地址、管理地址、端口名称、端口速率、是否支持聚合、是否支持POE、是否具有二层网桥功能、是否具有三层路由功能等信息。

        ·LLDP MED（Media Endpoint Discovery，媒体终端发现）方案可以直接提供信息给网络管理系统，帮助定位不一致或错误问题。LLDP-MED TLV为VoIP（Voice over IP，在IP上传送语音）提供了许多高级的应用，包括基本配置、网络策略配置、地址信息以及目录管理等，满足了语音设备的不同生产厂商在成本有效、易部署、易管理等方面的要求，为语音设备的生产者、销售者以及使用者提供了便利。

    LLDP协议的设计目的是发布信息给远端设备，使其可以建立关于网路拓扑的管理信息库。LLDP并不会修改对端设备的配置不会对对端设备产生任何控制，也就是说，LLDP为上层提供了链路发现的方法，但对发现的链路问题，并不提供解决方法。

30.3    LLDP基本工作原理

30.3.1    LLDP的端口工作模式

    LLDP有四种端口工作模式：

    ·    TxRx：端口既发送也接收LLDP报文；TxRx模式是缺省模式，正常运行LLDP的设备之间都运行在TxRx模式。

    ·    Tx：端口只发送不接收LLDP报文；此模式下，发布自身信息，不保存邻居信息。

    ·    Rx：端口只接收不发送LLDP报文；此模式下，保存邻居信息，不发布自身信息。

    ·    Disable：端口既不发送也不接收LLDP报文；此模式下，不发布自身信息，也不保存邻居信息。

    管理员可以为每个端口选择任何一种收发模式，以适应不同的需求。LLDP邻居间的报文交互没有确认机制，发送方发送报文后并不需要等待对方应答。同理，接收方对接收到报文后也不用返回确认应答报文。

30.3.2    LLDP报文的发送

    LLDP根据端口的工作状态决定报文的收发执行，如果端口工作在TxRx或Tx模式时，端口则按照如下规则进行LLDP报文的发送：

    ·快速发送：为了支持LLDP MED，LLDP支持快速发送机制。在链路UP、发送使能、发现新邻居等情况下，端口将按照1秒钟的时间间隔发送一定数量的LLDPb报文，以保证尽快建立邻居关系。

    ·周期发送：正常情况下，设备将在端口上周期性的发送LLDP报文以维持邻居关系，发送周期可配置，默认为30秒。

    ·延迟发送：当本地信息库里的信息变化时，会触发LLDP报文发送，这样邻居可以及时更新远端信息。但如果信息频繁变化，会导致LLDP大量发送，为避免这种情况，使用令牌桶机制对LLDP报文发送作限速处理。目前默认限制发送报文速率的令牌桶大小为5.

    ·重初始化延时：为避免链路动荡时LLDP发送状态机的频繁初始化，发送状态机变为非发送状态时，需要等待一定的延时才执行重新初始化。此延时定时器默认为2秒；

    ·发送Shutdown帧：当LLDP关闭或从发送模式切换为Disable或Rx模式时，需要发送Shutdown帧。该报文只包含必要的必选TLV。且其中的TTL TLV的Value字段值为0。

    ·发送统计：统计本端口发送的LLDP报文数量。

30.3.3    LLDP报文的接收

    如果端口工作在TxRx或者Rx模式，端口则按照如下规则进行LLDP报文的接收：

    ·合法性检查：首先对LLDP报文格式、内容、TLV的顺序、长度等信息进行合法性检查。如果合法性检查失败，则丢弃。如果合法性检查成功，则根据报文内容建立或更新邻居信息，如果报文的TTL值为0，则立即老化该邻居信息。

    ·多邻居处理：一个端口可能收到多个邻居的信息，比如端口下挂一个HUB。在这种情况下，防止资源被大量占用，需要限制允许接收的邻居数量，根据设备性能和实际需要可以灵活配置。

    ·接收统计：对接收的有效或无效LLDP报文进行统计。

注意：

    LLDP报文只能在邻居设备间交互，不被邻居转发，不带tag。如果设备不运行LLDP协议，则LLDP报文作为普通数据报文被转发。对于聚合端口，LLDP可以在聚合组的任何一个子端口上运行，即LLDP运行在聚合特性之下。LLDP协议只能运行在设备的二层以太网口、任何可以阻塞端口的特性不影响LLDP报文的收发。LLDP报文每次发送，都必须提取所有允许发送的TLV封装到报文里，而不是增量式的发送。

30.3.4    LLDP报文封装格式

30.3.5    LLDPDU组成

30.3.6    LLDP TLV分类

30.3.7    必选基本TLV介绍

30.3.8    可选基本TLV介绍

30.3.9    组织定义TLV介绍

30.4    LLDP基本配置

30.4.1    使能LLDP功能

    全局使能LLDP功能后，设备才会把LLDP报文作为协议报文处理，否则设备将LLDP报文当着业务报文转发。全局使能LLDP功能的命令是：

        [H3C]lldp global enable

    缺省情况下，全局LLDP使能之后，端口上的LLDP也处于使能状态，如果需要在特定端口上关闭和重新使能可以使用端口视图下命令进行单独控制。

    端口视图下使能LLDP的命令是：

        [H3C-GigabitEthernet1/0/1]lldp enable

    开启LLDP功能后，需要配置合适的LLDP端口工作模式，支持四种工作模式：

        [H3C-GigabitEthernet1/0/1]lldp admin-status {disable | rx | tx | txrx}

    其中参数说明如下：

        ·disable：端口工作在disable模式，此模式下端口即不接受也不发送LLDP报文。

        ·rx：端口工作在rx模式，此模式下端口不发送LLDP报文但接收LLDP报文。

        ·tx：端口工作在tx模式，此模式下端口至发送LLDP报文但不接收LLDP报文。

        ·txrx：端口工作在txrx模式，此模式下端口既发送也接收LLDP报文。

30.4.2    配置LLDP全局参数

    系统视图下配置快速发送报文数，快速发送报文个数缺省值为4，取值范围1-8；

        [H3C]lldp fast-count count

    系统视图下配置TTL乘数，TTL乘数缺省值4，取值范围2-10:

        [H3C]lldp hold-multiplier value

    系统视图下配置LLDP trap 定时器，缺省值30秒，取值范围5-3600:

        [H3C]lldp timer notificaiton-interval interval

    系统视图下配置LLDP重初始化延时计时器，缺省值2秒，取值范围1-10:

        [H3C]lldp timer reinit-delay delay

    系统视图下配置LLDP报文发送周期，缺省值30秒，取值分为5-32768:

        [H3C]lldp timer tx-interval interval

30.4.3    配置端口LLDP运行参数

30.4.4    LLDP的显示与调试

30.4.5    LLDP配置示例

第31章    镜像技术

    在日常网络维护过程中，掌握网络中转发传输的是什么流量，流量从哪个网络节点出发到哪个网络节点终止，目前网络带宽占用实际比例是多少，是一个网络管理员最为关心的事情，也是必须关心的事情。镜像技术就是掌握上述信息的一种重要辅助手段。

    另外在IT技术日益发送和广泛应用的今天，对重要数据网络和公共信息网络进行安全审查也显得尤为重要。尽管这些任务大多交给防火墙、IPS、IDS等安全设备，但将流量送给某些安全设备也需要采用镜像技术来完成报文的复制，使得在监控信息的同时不影响业务的正常开展。

31.2    镜像技术概述和原理

31.2.1    镜像技术简介

    镜像就是将指定端口的报文或者符合指定规则的报文复制到目的端口。用户可利用镜像技术，进行网络监管和故障排除。其中镜像技术中应用最为广泛，实现最为简单的当属端口镜像，为了便于认识镜像技术，首先介绍端口镜像中涉及的几个基本概念：

    ·源端口：源端口是被监控的端口，用户可以对通过该端口的报文进行监控和分析。

    ·目的端口：目的端口也可称为监控端口，该端口将接收到的报文转发到数据监测设备，以便对报文进行监控和分析。

    ·镜像的方向：端口镜像的方向分为入方向、出方向和双向。

        ·入方向：仅对源端口接收的报文进行镜像。

        ·出方向：仅对源端口发送的报文进行镜像。

        ·双向：对源端口接收和发送的报文都进行镜像。

31.2.2    镜像分类

    镜像技术包括如下三种：

    ·本地端口镜像：是指将设备的一个或多个端口（源端口）的报文复制到本设备的一个监视端口（目的端口），用于报文的监视和分析。其中，源端口和目的端口必须在同一台设备上。

    ·远程端口镜像：是指将设备的一个或多个端口的报文复制并通过中间网络设备转发到指定目的交换机上的目的端口。它突破了源端口和目的端口必须在同一台设备上的限制，使源端口和目的端口间可以跨越多个网络设备。

    ·流镜像：是指通过ACL等规则将具有某特征的数据流复制到目的端口。它通过QoS策略实现，即使用流分类技术来定义需要被镜像的报文的匹配条件，再通过配置流行为将符合条件的报文镜像至指定的方向。因此流镜像可以避免过多的冗余流量被复制到目的端口。

31.2.3    本地端口镜像

    本地端口镜像是最为简单的镜像技术，H3C网络设备通过本地镜像组的方式来实现。同一个镜像组可以包含一个或多个镜像源端口，但只能有一个镜像目的端口，且可以根据实际需要指定端口上被镜像报文的方向。当完成端口镜像的源端口和目的端口配置之后，交换机按照正常的转发规则转发所有报文外，还在所有镜像源端口根据实际配置的镜像方向将报文复制到镜像目的端口。

    由于源端口可以是多个，因此在做本地端口镜像时需要注意实际被镜像流量不要超过目的端口的物理带宽，否则容易导致镜像报文因拥塞而丢弃。同时由于镜像目的端口将发送大量的被镜像报文，因此此端口不宜作正常业务转发。

31.2.4    远程端口镜像

    远程端口镜像通过远程源镜像组和远程目的镜像组互相配合的方式实现。在整个远程端口镜像过程中，源设备负责将源端口的报文在特定VLAN内通过出端口转发出去。网络中间设备在指定VLAN内将报文转发到目的设备。目的设备从指定VLAN内接收镜像报文并转发给目的端口。如图所示，完成远程镜像至少包含源设备和目的设备，大多数情况下还存在中间设备：

    ·源设备：源端口所在的设备，用户需要在源设备上创建远程源镜像组。本设备负责将源端口的报文复制一份，来远程镜像VLAN中通过出端口将报文转发出去，传输给中间设备或目的设备。

    ·中间设备：网络中处于源设备和目的设备之间的设备。中间设备负责将镜像报文传输给下一个中间设备或目的设备。如果源设备与目的设备直接相连，则不存在中间设备。用户需要确保远程镜像VLAN内源设备到目的设备的二层互通性。且在实现端口的双向镜像时需要保证中间设备可以禁止该VLAN内MAC地址的学习，从而可以正常的将镜像报文从一个端口转发到另一个端口。

    ·目的设备：远程镜像目的端口所在的设备，用户需要在目的设备上创建远程目的镜像组。目的设备收到报文后，比较报文的VLAN ID和远程目的镜像组的远程镜像VLAN是否相同，如果相同，则将该报文通过镜像目的端口转发给监控设备。

31.2.5    流镜像

    流镜像，即将指定的数据包复制到用户指定的目的地，以进行网络检测和故障排除。

    流镜像根据实际镜像的目标不同可以分为两种：

    ·流镜像到端口：是把通过配置了流镜像的端口的符合要求的数据包复制一份，然后发送到目的端口。

    ·流镜像到CPU：是把通过配置了流镜像的端口的符合要求的数据包复制一份，然后发送到CPU以供分析诊断。在特定的条件下可以通过将流量镜像到CPU，并通过设备的debugging命令查看收到报文的具体内容而不需要额外的监控终端。

31.3    配置端口镜像

31.3.1    端口镜像配置命令

    端口镜像的配置可分为三个步骤：

    第1步：在系统视图下创建本地镜像组。mirroring-group local命令来创建一个本地镜像组。

        [H3C]mirroring-group group-id local

        group-id：表示端口镜像组的组号。不同的产品取值范围不同。

    第2步：在系统视图或端口视图下配置源端口。mirroring-group mirroring-port命令用来为镜像组配置源端口。

        [H3C]mirroring-group group-id mirroring-port interface-list {both | inbound | outbound}

        [H3C-GigabitEthernet1/0/1]mirroring-group group-id mirroring-port {both | inbound | outbound}

31.3.2    端口镜像配置示例

31.4    配置远程镜像

31.4.1    远程镜像配置任务

    远程端口镜像需要分别在源设备，目的设备和中间设备上配置，具体配置任务包括：

    ·在源设备上配置远程源镜像组：首先需要在系统视图下创建远程源镜像组，然后为镜像组配置源端口、出端口和Proble VLAN。

    ·配置中间设备：中间设备只需要在指定VLAN内禁止MAC地址学习并将互联端口配置为Trunk端口且允许指定VLAN通过。

    ·在目的设备上配置目的镜像组：首先需要在系统视图下创建远程目的镜像组，然后为镜像组配置目的端口和Proble VLAN。

31.4.2    配置源设备

31.4.3    配置中间设备

31.4.4    配置目的设备

31.4.5    远程镜像配置示例

31.5    配置流镜像

31.5.1    流镜像配置命令

31.5.2    流镜像配置示例

31.6    镜像显示及注意事项

第32章    NTP

    网络设备记录的日志信息是网络状态监控和网络故障定位的重要依据，保证其具备严格的先后顺序是非常必要的。频繁配置设备时间会耗费管理员的大量精力，且不论配置得如何频繁如何细心，都无法确保各设备的时钟分秒不差。

    要满足这种网络设备保持时间一致性的需求，需要利用NTP协议在各设备之间自动同步时间，使所有设备的时间都达到一致。NTP在其他诸多方面也都有着广泛应用。

32.2    NTP简介

32.2.1    NTP的作用

    对于网络中的各网络设备来说，如果依靠管理员手工输入命令来修改系统时钟，不但工作量巨大，而且也不能保证时钟的精确性。相反，通过NTP自动同步，可以很快将网络设备的时钟同步，同时也能保证很高的精度。

    NTP（Network Time Protocol，网络时间协议）由RFC 1305规定，用来在分布式时间服务器和客户端之间进行时间同步的协议。NTP基于UDP进行传输，使用的UDP端口号为123。

    使用NTP的目的是对网络内所具有时钟的设备进行时钟同步，使网络内所有设备的时钟保持一致，从而使设备能够提供基于同一时间的多种应用。

    运行NTP的本地系统，既可以接受来自其他时钟源的同步，又可以作为时钟源同步其它的时钟，并且可以和其它设备互相同步。

    NTP主要应用于需要网络中所有设备时钟保持一致的场合，比如：

    ·在网络管理中，对于从不同设备采集来的日志信息、调试信息进行分析的时候，需要以时间作为参考依据。

    ·计费系统要求所有设备的时钟保持一致。

    ·定时重启网络中的所有设备，要求所有设备的时钟保持一致。

    ·多个系统协同处理同一个比较复杂的事件时，为保证正确的执行顺序，多个系统必须参考同一时钟。

    ·在备份服务器和客户端之间进行增量备份时，要求备份服务器和所有客户端之间的时钟同步。

32.2.2    NTP基本架构

    在实际网络中NTP采用Client/Server结构运行，但服务器和客户端的概念是相对的，提供时间标准的设备称为时间服务器，接收时间服务的设备称为客户端。作为客户端的NTP设备同时还可以作为其它NTP设备的服务器。因此相互进行时钟同步的各网络设备最终组成树状网络结构。从时钟服务器的根到各分支逐级进行时钟同步。

    NTP采用分层（Stratum）的方法来定义时钟的准确性。NTP设备的时钟层数越大，说明时钟精度越低。实际网络中，通常将从权威时钟（如原子时钟）获得时钟同步的NTP服务器的层数设置为1，并将其作为主参考时钟源，用于同步网络中其它设备的时钟。网络中的设备与主参考时钟源的NTP距离，即NTP同步链上NTP服务器的数目，决定了设备上时钟的层数。

    配置本地时钟作为参考时钟或者已经上一级时钟源同步后，本地设备也可以作为时钟源同步网络中的其他设备。

32.3    NTP原理

32.3.1    NTP工作原理

32.2.3    NTP报文结构

    NTP有两种不同类型的报文，一种是时钟同步报文，另一种是控制报文。控制报文仅用于需要网络管理的场合，它对于时钟同步功能来说并不是必须的。

32.3.3    NTP工作模式

    设备可以采用多种NTP工作模式进行时间同步：

    ·客户端/服务器模式

    ·对等体模式

    ·广播模式

    ·组播模式

    用户可以根据需要选择合适的工作模式。在不能确定服务器或对等体IP地址、网络中需要同步的设备很多等情况下，可以通过广播或组播模式实现时钟同步；服务器和对等体模式中，设备从指定的服务器或对等体获得时钟同步，增加了时钟的可靠性。

    在客户端/服务器模式中，客户端向服务器发送时钟同步报文，报文中的Mode字段设置为3（客户模式）。服务器端收到报文后会自动工作在服务器模式，并发送应答报文，报文中的Mode字段设置为4（服务器模式）。客户端收到应答报文后，进行时钟过滤和选择，并同步到优选的服务器。

    在该模式下，客户端能同步到服务器，而服务器无法同步到客户端。

    在对等体模式中，主动对等体和被动对等体之间首先交互Mode字段为3（客户端模式）和4（服务器模式）的NTP报文。之后，主动对等体向被动对等体发送时钟同步报文，报文中的Mode字段设置为1（主动对等体），被动对等体收到报文后自动工作在被动对等体模式，并发送应答报文，报文中的Mode字段设置为2（被动对等体）。经过报文的交互，对等体模式建立起来。主动对等体和被动对等体可以互相同步。如果双方的时钟都已经同步，则以层数小的时钟为准。

    在广播模式中，服务器端周期性地向广播地址255.255.255.255发送时钟同步报文，报文中的Mode字段设置为5（广播模式）。客户端侦听来自服务器的广播报文。当客户端接收到第一个广播报文后，客户端与服务器交互Mode字段为3（客户端模式）和4（服务器模式）的NTP报文，以获得客户端与服务器间的网络延迟。之后，客户端就进入广播客户端模式，继续侦听广播报文的到来，根据到来的广播报文对系统时钟进行同步。

    在组播模式中，服务器端周期性地向用户配置的组播地址（若用户没有配置组播地址，则使用默认的NTP组播地址224.0.1.1）发送时钟同步报文，报文中的Mode字段设置为5（组播模式）。客户端侦听来自服务器的组播报文。当客户端接收到第一个组播报文后，客户端与服务器交互Mode字段为3（客户模式）和4（服务器模式）的NTP报文，以获得客户端与服务器间的网络延迟。之后，客户端就进入组播客户端模式，继续侦听组播报文的到来，根据到来的组播报文对系统时钟进行同步。

32.3.4    NTP部署示例

32.3.5    NTP验证

    在一些对安全性要求较高的网络中，运行NTP协议时需要启用验证功能。通过客户端和服务器端的密码验证，可以保证客户端只与通过验证的设备进行同步，提高网络安全性。

    NTP验证功能可以分为客户端的NTP验证和服务器端的NTP验证两个部分。在应用NTP验证功能时，应注意以下原则：

    ·对于所有同步模式，如果使能了NTP验证功能，应同时配置验证密钥并将密钥设为可信密钥。否则，无法正常启用NTP验证功能。

    ·对于客户端/服务器模式和对等体模式，还应在客户端（对等体模式中的主动对等体）将指定密钥于对应的NTP服务器（对等体模式的被动对等体）关联；对于广播服务器模式和组播服务器模式，应在广播服务器或组播服务器上将指定密钥与对应的NTP服务器关联。否则，无法正常启用NTP验证功能。

    ·对于客户端/服务器同步模式，如果客户端没有成功启用NTP验证功能，不论服务器端是否使能NTP验证，客户端均可以与服务器端同步；如果客户端上成功启用了NTP验证功能,则客户端只会同步到提供可信密钥的服务器，如果服务器提供的密钥不是可信的密钥，那么客户端不会与其同步。

    ·对于所有同步模式，服务器端的配置与客户端的配置应保持一致。

32.4    NTP基本配置

32.4.1    NTP配置命令

32.4.2    NTP配置示例