[个人笔记]HCIP-Routing & Switching-IERS/H12-221

声明“H12-221的内容大部分在HCNA中涵盖了，此处是NA中没有的或不足的内容的补充

组播

单播相对于组播的缺陷：

• 重复流量过多
• 消耗设备和带宽资源
• 难以保障传输质量

广播相对于组播的缺陷：

• 地域范围限制：需要对象都在一个vlan里面
• 安全性无法保障
• 有偿性无法保障

组播的劣势：

• 大多都是UDP的数据包
  • 尽力而为
  • 会造成报文丢失
  • 会造成报文重复
  • 会造成报文失序
  • 缺少拥塞避免

组播服务模型

ASM/Any-Source Multicast：

• 任意发送者都可以成为组播源，接收者无法预知组播源的位置，接收者可以在任意时间加入或离开该主机组
• 要求组播地址必须整个组播网络中唯一（同一时刻一个ASM地址只能被一个组播应用使用）
• 有域内域间划分

SSM/Source-Specific Multicast：

• 接收者在加入组播地址时，可以指定只接收哪些源的数据
• 加入组播地址后，主机只会收到指定源发送到改组的数据
• 组播地址不再要求全网唯一，只需要每个组播源上保持唯一（同一个源上不同的组播应用必须使用不同的SSM来区分）
• 没有域内域间划分

组播IP和MAC地址

mac地址：01-00-5e+（IP地址二进制的后23位，在最开始处加二进制的“0”）

IGMP

IGMPv1：

• 报文类型：普遍组查询/Membership Query（60s/次），成员关系报告/Membership Report
• 响应抑制机制：抑制同一组播组的信息（路由器只需要知道有改组就行）
• 成员主动加入：发送成员关系报告
• 成员静默离开，不会发送离开报文（某组内130s没有成员关系报文则会认为该组内没有成员了，就会删除改组）
• 查询器的选举依赖上层路由协议的PIM的hello包，选组IP地址大的为查询器

IGMPv2：

• 报文类型：普遍组查询/Membership Query general（组播地址0.0.0.0）（比版本一多了最大相应时间的参数），特定组查询/Membership Query special（特定组播地址）（如某成员离开时发送以查询组内是否有成员），成员关系报告（v2和v1的，为了和版本一兼容），离开组信息/Leave Group
• 响应抑制
• 独立的查询选举机制，IP地址小的为查询器（默认自己为查询器，会发送普遍组查询，根据该报文的IP地址内容来比较）
• 缺省配置就是版本2

IGMPv3：

• 在版本二的基础上，可以根据数据源或组选择是否接受数据包（in/include和ex/exclude）
• 没有抑制机制，因为根据数据源选择
• 普及性虽然不强，但是安全性更高

IGMP Snooping：

• 组播数据在二层泛洪（交换机在收到组播消息后，默认执行泛红操作）（使得组播的操作和广播一样），造成网络资源浪费，存在安全隐患
• IGMP Snooping解决了上述问题：维护一个组播mac地址表（0口表示CPU–所有数据都需要由数据库处理，1口表示路由器，其他表示相应的接口），这样的话转发的时候就不用泛洪

组播分发树

SPT/Shortest Path Tree/最短路径树:也称源树/Source Tree，根据单播的度量值产生SPT

• 以组播源为树根，将组播源到每一个接收者的最短路径结合起来构成的转发树
• 每一个组播源与接收者们之间建立一颗独立的SPT
• 组播转发表项：(Source，Group)，iif/入接口，oiflist/出接口列表
• 路径最小，延时最小，但是占用内存多

RPT/Rendezvous Point Tree/共享树：

• 以某个路由器作为路由器的树根，这个根常被称为RP（汇合点或核心）
• 所有的组播源和接收者都使用这颗树来收发报文，组播源先向树根发送数据报文，之后报文向下转发到达所有的接收者
• 组播转发表项：（*，Group）—在到达树根前还是（S,G）到达树根后就变成 (*,G)，开始不关心数据源
• 路径不是最优的，引入额外的延迟，但是内存消耗少

RPF/Reverse Path Forwarding/反向路径转发

• 所有组播协议都使用RPF检查—错误，只有PIM使用，其他组播协议虽然也有类似的，但不叫RPF检查
• 确保组播数据沿正确路径传输
• 避免组播环路
• 路由器在收到组播数据报文后，只有确定这个数据报文是从自身连接到组播源的接口上收到的，才进行转发，否则丢弃
• 检查过程：
  • 在单播路由表中查找组播报文源地址的路由
  • 如果该路由的出接口就是该组播报文的入接口，则RPF通过

PIM/Protocol Independent Multicast

概述：

• 运行于组播路由器之前（IGMP运行于组播路由器和PC之间）

• 负责建立和维护组播路由，并正确高效地转发组播数据包

• 建立从组播源到多个接收端的无环转发路径，即组播分发树

两种模式：

• DM/Dense Mode/稠密模式
• SM/Sparse Mode/稀疏模式

DM

• 使用“推（PUSH）”方式来传递数据

• 使用于小型网络，组播成员地址比较密集

• **工作流程：**邻居发现（间隔=30s）（超时时间=105s），扩散（扩散-剪枝定时器=180s），剪枝（剪枝超时定时器=210s），状态刷新（状态刷新发生间隔=60s），嫁接，Assert机制（选定网段上的唯一组播数据发送者）

  • 邻居发现：周期性地发送hello数据包（发送到224.0.0.113）

  • 假设网络中的每个子网都存在至少一个对组播源感兴趣的接收端，因此组播数据将被扩散（flooding）到网络中的所有点，于此伴随着资源（带宽和路由器cpu的消耗）

  • 为了减少网络的资源消耗，对没有组播数据转发的分支进行剪枝（prune）操作，只保存包含接收者的分支

  • 这种“扩散-剪枝”现象周期性地发生，被剪枝的分支也可以周期性的恢复成转发状态

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

  • 构建并维护"SPT"

  • 不依赖于特定的单播路由协议，而是使用现存的单播路由表进行RPF检查

  • Assert机制的选举规则：

    1. 比较到组播源的优先级高者
    2. 比较到组播源的度量值小者
    3. 比较本地的IP地址大者

SM

• 使用“拉（pull）”方式传递数据

• 适用于范围较广，大中型网络（任何网络），组成员相对分散

• 工作流程：邻居发现。DR选举，RP发现，加入，剪枝，注册，SPT切换

  • 假设网络中的组播成员分布非常稀疏，几乎所有网段都不存在组成员。直到某网段出现组成员时，才构建路由，向该网段转发组播数据

  • 构建并维护RPT

  • 选择某台路由器作为公用的根节点RP，组播数据通过RP沿着RPT发送给接收者

  • 连接接收者的路由器向某组播组对应的RP发送加入报文（Join Message），该报文被逐跳发送到RP，所经过的路径就形成了RPT的分支

  • 组播源如果要向某组播组发送组播数据，首先由于组播源侧DR负责向RP注册，把注册报文（Register Message）通过单播的形式发送给RP，该报文到达RP后触发建立SPT。之后组播源吧组播数据沿着SPT发向R