02-组播路由与转发配置
本章节下载: 02-组播路由与转发配置 (447.56 KB)
目 录
1.11.1 配置在所有VLAN内泛洪RPF检查失败的组播数据报文
1.11.2 配置在特定VLAN内组播RPF检查失败的组播数据报文
1.11.3 配置将RPF检查失败的组播数据报文上送给CPU进行处理
1.12 配置组播数据在Super VLAN内的各Sub VLAN之间互通
每个组播路由协议都有一个自身的路由表,它们与静态配置的组播路由综合成一个总的组播路由表,由一系列(S,G)和(*,G)表项组成,即由组播源S向组播组G发送组播数据的组播路由信息。其中最优组播路由下发到组播转发表中,控制组播数据的转发。组播传输路径上的设备根据组播转发表转发组播数据的同时还需执行RPF(Reverse Path Forwarding,逆向路径转发)机制确保组播数据沿正确路径传输。
组播路由协议在创建和维护组播路由表项时,运用了RPF检查机制,以确保组播数据能够沿正确的路径传输,同时还能避免由于各种原因而造成的环路。
执行RPF检查的过程如下:
(1) 首先,以“报文源”的IP地址为目的地址,分别从单播路由表、MBGP路由表和组播静态路由表中各选出一条最优路由。
根据组播报文传输的具体情况不同,“报文源”所代表的具体含义也不同:
· 如果当前报文沿从组播源到接收者或RP(Rendezvous Point,汇集点)的SPT(Shortest Path Tree,最短路径树)进行传输,则以组播源为“报文源”进行RPF检查。
· 如果当前报文沿从RP到接收者的RPT(Rendezvous Point Tree,共享树)进行传输,或者沿从组播源到RP的组播源侧RPT进行传输,则都以RP为“报文源”进行RPF检查。
· 如果当前报文为BSR(Bootstrap Router,自举路由器)报文,沿从BSR到各设备的路径进行传输,则以BSR为“报文源”进行RPF检查。
有关SPT、RPT、组播源侧RPT、RP和BSR的详细介绍,请参见“IP组播配置指导”中的“PIM”。
(2) 然后,从这些最优路由中再选出一条作为RPF路由。选取规则如下:
· 如果配置了按照最长匹配选择路由,则:
¡ 选择掩码匹配最长的路由。
¡ 如果掩码相同,则选择路由优先级最高的路由。
¡ 如果路由优先级也相同,则按照组播静态路由、MBGP路由、单播路由的顺序进行选择。
¡ 如果存在等价路由,则选择下一跳的IP地址较大者。
· 如果没有配置按照最长匹配选择路由,则:
¡ 选择路由优先级最高的路由。
¡ 如果路由优先级相同,则按照组播静态路由、MBGP路由、单播路由的顺序进行选择。
¡ 如果存在等价路由,则选择下一跳的IP地址较大者。
RPF路由中包含有RPF接口和RPF邻居的信息:
· 如果RPF路由为单播路由或MBGP路由,则该路由表项的出接口就是RPF接口,下一跳就是RPF邻居。
· 如果RPF路由为组播静态路由,则该路由表项中会明确指定RPF接口和RPF邻居。
(3) 最后,判断报文实际到达的接口与RPF接口是否相同:
· 相同,RPF检查通过。
· 不同,RPF检查失败。
对每一个收到的组播数据报文都进行RPF检查会给设备带来较大负担,而利用组播转发表可以解决这个问题。在建立组播路由和转发表时,会把组播数据报文(S,G)的RPF接口记录为(S,G)表项的入接口。当设备收到组播数据报文(S,G)后,查找组播转发表:
· 如果组播转发表中不存在(S,G)表项,则对该报文执行RPF检查,将其RPF接口作为入接口,结合相关路由信息创建相应的表项,并下发到组播转发表中:
¡ 若该报文实际到达的接口正是其RPF接口,则RPF检查通过,向所有的出接口转发该报文;
¡ 若该报文实际到达的接口不是其RPF接口,则RPF检查失败,丢弃该报文。
· 如果组播转发表中已存在(S,G)表项,且该报文实际到达的接口与入接口相匹配,则向所有的出接口转发该报文。
· 如果组播转发表中已存在(S,G)表项,但该报文实际到达的接口与入接口不匹配,则对此报文执行RPF检查:
¡ 若其RPF接口与入接口一致,则说明(S,G)表项正确,丢弃这个来自错误路径的报文;
¡ 若其RPF接口与入接口不符,则说明(S,G)表项已过时,于是把入接口更新为RPF接口。如果该报文实际到达的接口正是其RPF接口,则向所有的出接口转发该报文,否则将其丢弃。
图1-1 RPF检查过程
如图1-1所示,假设网络中单播路由畅通,未配置MBGP,Device C上也未配置组播静态路由。组播报文(S,G)沿从组播源(Source)到接收者(Receiver)的SPT进行传输。假定Device C上的组播转发表中已存在(S,G)表项,其记录的入接口为Port A:
· 如果该组播报文从接口Port A到达Device C,与(S,G)表项的入接口相匹配,则向所有的出接口转发该报文。
· 如果该组播报文从接口Port B到达Device C,与(S,G)表项的入接口不匹配,则对其执行RPF检查:通过查找单播路由表发现到达Source的出接口(即RPF接口)是Port A,与(S,G)表项的入接口一致。这说明(S,G)表项是正确的,该报文来自错误的路径,RPF检查失败,于是丢弃该报文。
组播静态路由有两种主要用途:改变RPF路由和衔接RPF路由。
通常,组播的网络拓扑结构与单播相同,组播数据的传输路径也与单播相同。可以通过配置组播静态路由以改变RPF路由,从而为组播数据创建一条与单播不同的传输路径。
图1-2 改变RPF路由示意图
如图1-2所示,当网络中没有配置组播静态路由时,Device C到组播源(Source)的RPF邻居为Device A,从Source发出的组播信息沿Device A—Device C的路径传输,与单播路径一致;当在Device C上配置了组播静态路由,指定从Device C到Source的RPF邻居为Device B之后,从Source发出的组播信息将改变传输路径,沿Device A—Device B—Device C的新路径传输。
当网络中的单播路由被阻断时,由于没有RPF路由而无法进行包括组播数据在内的数据转发。可以通过配置组播静态路由以生成RPF路由,从而创建组播路由表项以指导组播数据的转发。
图1-3 衔接RPF路由示意图
如图1-3所示,RIP域与OSPF域之间实行单播路由隔离。当网络中没有配置组播静态路由时,OSPF域内的接收者(Receiver)不能收到RIP域内的组播源(Source)所发出的组播信息;当在Device C和Device D上均配置了组播静态路由,分别指定从Device C到Source的RPF邻居为Device B、从Device D到Source的RPF邻居为Device C之后,Receiver便能收到Source发出的组播信息了。
网络中可能存在不支持组播协议的设备,从组播源发出的组播数据沿组播设备逐跳转发,当下一跳设备不支持组播协议时,组播转发路径将被阻断。而通过在处于单播网段两端的组播设备之间建立隧道,则可以实现跨单播网段的组播数据转发。
如图1-4所示,在组播设备Device A和Device B之间建立隧道。Device A将组播数据封装在单播报文中,通过单播设备转发至隧道另一端的Device B,再由Device B将单播报文头剥掉后继续进行组播传输。
若要将该隧道专用于组播数据传输,可以在隧道两端只配置组播静态路由而不配置单播静态路由,从而使单播数据报文无法利用此隧道进行传输。
本特性的支持情况与设备型号有关,请以设备的实际情况为准。
设备型号 |
业务板类型 |
说明 |
M9006 M9010 M9014 |
Blade IV防火墙业务板 |
支持 |
Blade V防火墙业务板 |
支持 |
|
NAT业务板 |
支持 |
|
应用交付业务板 |
不支持 |
|
异常流量清洗业务板 |
不支持 |
|
M9010-GM |
加密业务板 |
支持 |
M9016-V |
Blade V防火墙业务板 |
支持 |
M9008-S M9012-S |
Blade IV防火墙业务板 |
支持 |
应用交付业务板 |
不支持 |
|
入侵防御业务板 |
支持 |
|
视频网关业务板 |
支持 |
|
异常流量清洗业务板 |
不支持 |
|
M9008-S-6GW |
IPv6业务板 |
支持 |
M9008-S-V |
Blade IV防火墙业务板 |
支持 |
M9000-AI-E8 |
Blade V防火墙业务板 |
支持 |
应用交付业务板 |
不支持 |
|
M9000-AI-E16 |
Blade V防火墙业务板 |
支持 |
当一个接口配置有从IP地址或借用了其它接口的IP地址时,组播数据并不能通过从IP地址或借来的IP地址进行路由和转发,而只能通过该接口的主IP地址进行路由与转发。有关主、从IP地址以及IP地址借用的详细介绍,请参见“三层技术-IP业务配置指导”中的“IP地址”。
组播路由与转发配置任务如下:
(1) 使能IP组播路由
(2) (可选)配置组播静态路由
(3) (可选)配置按照最长匹配选择RPF路由
(4) (可选)配置组播负载分担
(5) (可选)配置组播转发边界
(6) (可选)处理RPF检查失败的组播数据报文
(7) (可选)配置组播数据在Super VLAN内的各Sub VLAN之间互通
(8) (可选)配置缓存未知组播数据报文的最大数目
在配置组播路由与转发之前,需配置任一单播路由协议,实现域内网络层互通。
在公网实例或VPN实例中配置各项三层组播功能之前,必须先在该实例中使能IP组播路由。
(1) 进入系统视图。
system-view
(2) 使能IP组播路由,并进入MRIB(Multicast Routing Information Base,组播路由信息库)视图。
multicast routing [ vpn-instance vpn-instance-name ]
缺省情况下,IP组播路由处于关闭状态。
通过配置组播静态路由,可以为来自特定组播源的组播报文指定RPF接口或RPF邻居。
组播静态路由仅在所配置的组播设备上生效,不会以任何方式被广播或者引入给其它设备。
(1) 进入系统视图。
system-view
(2) 配置组播静态路由。
ip rpf-route-static [ vpn-instance vpn-instance-name ] source-address { mask-length | mask } { rpf-nbr-address | interface-type interface-number } [ preference preference ]
(3) (可选)删除所有组播静态路由。
delete ip rpf-route-static [ vpn-instance vpn-instance-name ]
可以通过undo ip rpf-route-static命令删除指定的组播静态路由外,也可以通过delete ip rpf-route-static命令删除所有的组播静态路由。
在未配置按照最长匹配选择RPF路由之前,RPF检查以最优路由作为RPF路由。在配置按照最长匹配选择RPF路由之后,RPF检查将按照最长匹配选择RPF路由。
有关RPF路由选择的详细介绍,请参见“1.1.1 1. RPF检查过程”。
(1) 进入系统视图。
system-view
(2) 进入MRIB视图。
multicast routing [ vpn-instance vpn-instance-name ]
(3) 配置按照最长匹配选择RPF路由。
longest-match
缺省情况下,选择路由优先级最高的路由作为RPF路由。
用户通过配置根据组播源或组播源组进行组播流量的负载分担,可以优化存在多条组播数据流时的网络流量。
本配置对双向PIM不生效。
(1) 进入系统视图。
system-view
(2) 进入MRIB视图。
multicast routing [ vpn-instance vpn-instance-name ]
(3) 配置对组播流量进行负载分担。
load-splitting { source | source-group }
缺省情况下,不对组播流量进行负载分担。
组播信息在网络中的转发并不是漫无边际的,每个组播组对应的组播信息都必须在确定的范围内传递。组播转发边界可以限制组播协议报文的收发,为指定范围的组播组划定了边界条件。如果组播报文的目的地址与边界条件匹配,就停止转发。当在一个接口上配置了组播转发边界后,将不能从该接口转发组播报文(包括本机发出的组播报文)并丢弃该接口接收到的组播报文。
本配置不需要使能IP组播路由。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 配置组播转发边界。
multicast boundary group-address { mask-length | mask }
缺省情况下,接口上未配置任何组播组的转发边界。
在某些特定组网环境下,会出现RPF检查失败的VLAN接口下存在接收者的情况,为了让这些接收者也能收到RPF检查失败的组播数据报文,可以将这些报文在所有VLAN内泛洪。
进行本配置不需要使能IP组播路由。
(1) 进入系统视图。
system-view
(2) 配置在所有VLAN内泛洪RPF检查失败的组播数据报文。
multicast rpf-fail-pkt flooding
缺省情况下,不在VLAN内泛洪RPF检查失败的组播数据报文。
(3) 退回用户视图。
quit
(4) 清除组播转发表中的转发项。
reset multicast [ vpn-instance vpn-instance-name ] forwarding-table all
reset multicast forwarding-table命令的目的是让设备更新硬件表项,执行本命令后,multicast rpf-fail-pkt flooding命令才能生效。
在某些特定组网环境下,会出现RPF检查失败的VLAN接口下存在接收者的情况,为了让这些接收者也能收到RPF检查失败的组播数据报文,可以将这些报文在特定VLAN内组播。
要进行组播RPF检查失败的组播数据报文的VLAN必须使能了IGMP Snooping且对应VLAN接口上配置有三层组播协议(IGMP或PIM)。当VLAN内有相应的IGMP Snooping转发表项时,便在该VLAN内组播。
进行本配置不需要使能IP组播路由。
(1) 进入系统视图。
system-view
(2) 配置在所有VLAN内泛洪RPF检查失败的组播数据报文。
multicast rpf-fail-pkt flooding
缺省情况下,不在VLAN内泛洪RPF检查失败的组播数据报文。
(3) 进入VLAN接口视图。
interface vlan-interface vlan-interface-id
(4) 配置在当前VLAN内组播RPF检查失败的组播数据报文。
multicast rpf-fail-pkt bridging
缺省情况下,不在VLAN内组播RPF检查失败的组播数据报文。
(5) 退回系统视图。
quit
(6) 退回用户视图。
quit
(7) 清除动态IGMP Snooping转发表的信息。
reset igmp-snooping group all [ vlan vlan-id ]
执行本命令后,multicast rpf-fail-pkt bridging命令才能生效。
有关reset igmp-snooping group命令的详细介绍,请参见“IP组播命令参考”中的“IGMP Snooping”。
在以下两种情况下,需要将RPF检查失败的组播数据报文上送给CPU进行处理:
· 如果组播数据报文从组播转发表项的出接口到达,则RPF检查失败,需要将该报文上送给CPU进行处理,以触发Assert机制剪枝多余的组播流量。
· 在RPT向SPT切换时,如果SPT与RPT在DR(Designated Router,指定路由器)上的入接口不同,为了使DR能感知到SPT上组播流量的到达,就需要将到达SPT入接口但RPF检查失败(剪枝RPT前的RPF接口是RPT的入接口)的组播数据报文上送给CPU进行处理。
有关Assert机制、DR以及RPT向SPT切换的详细介绍,请参见“IP组播配置指导”中的“PIM”。
进行本配置不需要使能IP组播路由。
(1) 进入系统视图。
system-view
(2) 配置把RPF检查失败的组播数据报文上送CPU处理。
multicast rpf-fail-pkt trap-to-cpu
缺省情况下,不把RPF检查失败的组播数据报文上送CPU处理。
(3) 退回用户视图。
quit
(4) 清除组播转发表中的转发项。
reset multicast [ vpn-instance vpn-instance-name ] forwarding-table all
执行本命令后,multicast rpf-fail-pkt trap-to-cpu命令才能生效。
一个Super VLAN内可以有多个Sub VLAN,不同Sub VLAN之间相互隔离。通过本配置可以使组播数据在同一Super VLAN内的各Sub VLAN之间互通。有关Super VLAN及其Sub VLAN的详细介绍,请参见“二层技术-以太网交换配置指导”中的“VLAN”。
(1) 进入系统视图。
system-view
(2) 进入VLAN接口视图。
interface vlan-interface interface-number
(3) 配置组播数据在Super VLAN内的各Sub VLAN之间互通。
multicast forwarding supervlan community
缺省情况下,组播数据在Super VLAN内的各Sub VLAN之间隔离。
(4) 退回系统视图。
quit
(5) 退回用户视图。
quit
(6) 清除所有以Super VLAN接口为入接口的转发表项。
reset multicast [ vpn-instance vpn-instance-name ] forwarding-table incoming-interface { interface-type interface-number }
执行本命令后,multicast forwarding supervlan community命令才能生效。
建立组播转发表项需要一定时间,在这段时间内设备若收到(S,G)表项的组播数据报文,可以缓存该报文。如果需要缓存多个未知组播数据报文,可以通过本配置来设置对于同一个(S,G)表项,可缓存的最大未知组播数据报文数目。通过本配置还可以设置内存中缓存的未知组播数据报文的总数。
建议配置multicast forwarding-table cache-unknown total的值要远远大于multicast forwarding-table cache-unknown per-entry配置的值。
(1) 进入系统视图。
system-view
(2) 设置对于同一个(S,G)表项,可缓存的最大未知组播数据报文数目。
multicast forwarding-table cache-unknown per-entry per-entry-limit
缺省情况下,对于同一个(S,G)表项,可缓存的最大未知组播数据报文数目为1。
(3) 设置内存中缓存的未知组播数据报文的总数。
multicast forwarding-table cache-unknown total total-limit
缺省情况下,内存中缓存的未知组播数据报文的总数量为1024。
在多CPU设备上,组播/广播报文会被转发到不同CPU之间进行负载分担。设备支持如下两种转发模式:
· 逐包模式:将组播/广播报文依次发送到不同的CPU进行处理,不保证报文的处理顺序。
· 逐流模式:根据组播/广播报文的源IP地址、源端口号、目的IP地址、目的端口号、协议号等信息来区分和划定一条流,同一条流被分配到同一个或多个CPU进行处理,处理过程保证先进先出。
当组播/广播报文有保序需求时,请执行undo multicast-broadcast forwarding-mode per-packet命令配置组播/广播报文的CPU转发模式为逐流模式。
(1) 进入系统视图。
system-view
(2) 配置组播/广播报文的CPU转发模式为逐包模式。
multicast-broadcast forwarding-mode per-packet
缺省情况下,组播/广播报文的CPU转发模式为逐包模式。
执行reset命令清除组播路由表或组播转发表中的信息,可能导致组播信息无法正常传输。
在完成上述配置后,在任意视图下执行display命令可以显示配置后组播路由与转发的信息,通过查看显示信息验证配置的效果。
在用户视图下执行reset命令可以清除组播路由与转发的统计信息。
表1-1 组播路由与转发显示和维护
操作 |
命令 |
显示MRIB维护的接口信息 |
display mrib [ vpn-instance vpn-instance-name ] interface [ interface-type interface-number ] |
显示组播边界的信息 |
display multicast [ vpn-instance vpn-instance-name ] boundary [ group-address [ mask-length | mask ] ] [ interface interface-type interface-number ] |
显示组播快速转发表信息 |
(独立运行模式) display multicast [ vpn-instance vpn-instance-name ] fast-forwarding cache [ source-address | group-address ] * [ slot slot-number [ cpu cpu-number ] ] (IRF模式) display multicast [ vpn-instance vpn-instance-name ] fast-forwarding cache [ source-address | group-address ] * [chassis chassis-number slot slot-number [ cpu cpu-number ] ] |
显示组播转发的DF信息 |
(独立运行模式) display multicast [ vpn-instance vpn-instance-name ] forwarding df-info [ rp-address ] [ verbose ] [ slot slot-number [ cpu cpu-number ] ] (IRF模式) display multicast [ vpn-instance vpn-instance-name ] forwarding df-info [ rp-address ] [ verbose ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] |
显示组播转发的事件统计信息 |
(独立运行模式) display multicast [ vpn-instance vpn-instance-name ] forwarding event [ slot slot-number [ cpu cpu-number ] ] (IRF模式) display multicast [ vpn-instance vpn-instance-name ] forwarding event [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] |
显示组播转发表的信息 |
(独立运行模式) display multicast [ vpn-instance vpn-instance-name ] forwarding-table [ source-address [ mask { mask-length | mask } ] | group-address [ mask { mask-length | mask } ] | incoming-interface interface-type interface-number | outgoing-interface { exclude | include | match } interface-type interface-number | slot slot-number [ cpu cpu-number ] | statistics ] * (IRF模式) display multicast [ vpn-instance vpn-instance-name ] forwarding-table [ source-address [ mask { mask-length | mask } ] | group-address [ mask { mask-length | mask } ] | chassis chassis-number slot slot-number [ cpu cpu-number ] | incoming-interface interface-type interface-number | outgoing-interface { exclude | include | match } interface-type interface-number | statistics ] * |
显示组播转发表的DF列表信息 |
(独立运行模式) display multicast [ vpn-instance vpn-instance-name ] forwarding-table df-list [ group-address ] [ verbose ] [ slot slot-number [ cpu cpu-number ] ] (IRF模式) display multicast [ vpn-instance vpn-instance-name ] forwarding-table df-list [ group-address ] [ verbose ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] |
显示组播路由表的信息 |
display multicast [ vpn-instance vpn-instance-name ] routing-table [ source-address [ mask { mask-length | mask } ] | group-address [ mask { mask-length | mask } ] | incoming-interface interface-type interface-number | outgoing-interface { exclude | include | match } interface-type interface-number ] * |
显示组播静态路由表的信息 |
display multicast [ vpn-instance vpn-instance-name ] routing-table static [ source-address { mask-length | mask } ] |
显示组播源的RPF信息 |
display multicast [ vpn-instance vpn-instance-name ] rpf-info source-address [ group-address ] |
清除组播快速转发表中的转发项 |
(独立运行模式) reset multicast [ vpn-instance vpn-instance-name ] fast-forwarding cache { { source-address | group-address } * | all } [ slot slot-number [ cpu cpu-number ] ] (IRF模式) reset multicast [ vpn-instance vpn-instance-name ] fast-forwarding cache { { source-address | group-address } * | all } [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] |
清除组播转发的事件统计信息 |
reset multicast [ vpn-instance vpn-instance-name ] forwarding event |
清除组播转发表中的转发项 |
reset multicast [ vpn-instance vpn-instance-name ] forwarding-table { { source-address [ mask { mask-length | mask } ] | group-address [ mask { mask-length | mask } ] | incoming-interface { interface-type interface-number } } * | all } |
清除组播路由表中的路由项 |
reset multicast [ vpn-instance vpn-instance-name ] routing-table { { source-address [ mask { mask-length | mask } ] | group-address [ mask { mask-length | mask } ] | incoming-interface interface-type interface-number } * | all } |
· 清除组播路由表中的路由项后,组播转发表中的相应表项也将随之删除。
· 清除组播转发表中的转发项后,组播路由表中的相应表项也将随之删除。
路由器没有配置动态路由协议,接口的物理状态与链路层协议状态都显示为up,但是组播静态路由失败。
· 如果没有正确配置或更新与当前网络情况相匹配的组播静态路由,则组播静态路由表中不存在此路由项;
· 如果查询到有比组播静态路由更优的路由,也可能导致组播静态路由失败。
(1) 使用display multicast routing-table static命令显示组播静态路由表的信息,以确定是否正确配置了对应的路由并存在于组播静态路由表中。
(2) 检查组播静态路由与RPF邻居相连接口的接口类型,如果不是点到点接口,则RPF邻居必须使用指定地址的形式配置。
不同款型规格的资料略有差异, 详细信息请向具体销售和400咨询。H3C保留在没有任何通知或提示的情况下对资料内容进行修改的权利!