- Table of Contents
-
- 08-IP Multicast Configuration Guide
- 00-Preface
- 01-Multicast Overview
- 02-IGMP Snooping Configuration
- 03-PIM Snooping Configuration
- 04-Multicast VLAN Configuration
- 05-Multicast Routing and Forwarding Configuration
- 06-IGMP Configuration
- 07-PIM Configuration
- 08-MSDP Configuration
- 09-MBGP Configuration
- 10-Multicast VPN Configuration
- 11-MLD Snooping Configuration
- 12-IPv6 PIM Snooping Configuration
- 13-IPv6 Multicast VLAN Configuration
- 14-IPv6 Multicast Routing and Forwarding Configuration
- 15-MLD Configuration
- 16-IPv6 PIM Configuration
- 17-IPv6 MBGP Configuration
Title | Size | Download |
---|---|---|
05-Multicast Routing and Forwarding Configuration | 349.36 KB |
Contents
Configuring multicast routing and forwarding
GRE tunnel application in multicast forwarding
Configuring multicast routing and forwarding
Configuring static multicast routes
Configuring a multicast routing policy
Configuring a multicast forwarding range
Configuring the multicast forwarding table size
Configuring static multicast MAC address entries
Configuring RPF check failure processing
Displaying and maintaining multicast routing and forwarding
Multicast forwarding over a GRE tunnel
Troubleshooting multicast routing and forwarding
Static multicast route failure
Multicast data fails to reach receivers
Overview
In multicast implementations, multicast routing and forwarding are implemented by routing and forwarding tables:
· Each multicast routing protocol has its own multicast routing table, such as the PIM routing table.
· The multicast routing information of different multicast routing protocols forms a general multicast routing table.
· The multicast forwarding table helps guide the forwarding of multicast packets.
A multicast routing table consists of a set of (S, G) entries, each indicating the routing information for delivering multicast data from a multicast source to a multicast group. If a router supports multiple multicast protocols, its multicast routing table includes routes generated by multiple protocols. The router chooses the optimal route from the multicast routing table based on the configured multicast routing and forwarding policy and adds the route entry into its multicast forwarding table.
The term "router" in this document refers to both routers and Layer 3 switches.
RPF check mechanism
A multicast routing protocol relies on the existing unicast routes, MBGP routes, or static multicast routes in creating multicast routing entries. When creating multicast routing table entries, a multicast routing protocol uses the reverse path forwarding (RPF) check mechanism to ensure multicast data delivery along the correct paths. In addition, the RPF check mechanism also helps avoid data loops.
The basis for an RPF check is as follows:
· Unicast routing table—Contains the shortest path to each destination subnet.
· MBGP routing table—Contains multicast routing information.
· Static multicast routing table—Contains the RPF routing information defined by the user through static configuration.
RPF check process
When performing an RPF check, a router searches its unicast routing table, MBGP routing table, and static multicast routing table at the same time. The process is as follows:
1. The router chooses an optimal route from the unicast routing table, MBGP routing table, and static multicast routing table:
¡ The router automatically chooses an optimal unicast route by searching its unicast routing table, and using the IP address of the packet source as the destination address. The outgoing interface in the corresponding routing entry is the RPF interface and the next hop is the RPF neighbor. The router considers the path along which the packet from the RPF neighbor arrived on the RPF interface to be the shortest path that leads back to the source.
¡ The router automatically chooses an optimal MBGP route by searching its MBGP routing table, and using the IP address of the packet source as the destination address. The outgoing interface in the corresponding routing entry is the RPF interface and the next hop is the RPF neighbor.
¡ The router automatically chooses an optimal static multicast route by searching its static multicast routing table, and using the IP address of the packet source as the source address. The corresponding routing entry explicitly defines the RPF interface and the RPF neighbor.
2. The router selects one of these optimal routes as the RPF route. The selection process is as follows:
¡ If configured to use the longest prefix match principle, the router selects the longest prefix match route from the three. If these three routes have the same mask, the router selects the route with the highest priority. If the three routes have the same priority, the router selects a route as the RPF route according to the sequence of static multicast route, MBGP route, and unicast route.
¡ If not configured to use the longest prefix match principle, the router selects the route with the highest priority. If the three routes have the same priority, the router selects a route as the RPF route according to the sequence of static multicast route, MBGP route, and unicast route.
The "packet source" means different things in different situations:
· For a packet that travels along the SPT from the multicast source to the receivers or the rendezvous point (RP), the packet source for RPF check is the multicast source.
· For a packet that travels along the RPT from the RP to the receivers, or along the source-side RPT from the multicast source to the RP, the packet source for RPF check is the RP.
· For a bootstrap message from the BSR, the packet source for RPF check is the BSR.
For more information about the concepts of SPT, RPT, source-side RPT, RP, and BSR, see "Configuring PIM."
RPF check implementation in multicast
Implementing an RPF check on each received multicast data packet would bring a big burden to the router. The use of a multicast forwarding table is the solution to this issue. When creating a multicast routing entry and a multicast forwarding entry for a multicast packet, the router sets the RPF interface of the packet as the incoming interface of the (S, G) entry. After receiving an (S, G) multicast packet, the router first searches its multicast forwarding table:
1. If the corresponding (S, G) entry does not exist in the multicast forwarding table, the packet undergoes an RPF check. The router creates a multicast routing entry based on the relevant routing information and adds the entry into the multicast forwarding table, with the RPF interface as the incoming interface.
¡ If the interface that received the packet is the RPF interface, the RPF check succeeds and the router forwards the packet out of all the outgoing interfaces.
¡ If the interface that received the packet is not the RPF interface, the RPF check fails and the router discards the packet.
2. If the corresponding (S, G) entry exists, and the interface that received the packet is the incoming interface, the router forwards the packet out of all the outgoing interfaces.
3. If the corresponding (S, G) entry exists, but the interface that received the packet is not the incoming interface in the multicast forwarding table, the multicast packet undergoes an RPF check.
¡ If the RPF interface is the incoming interface of the (S, G) entry, this means the (S, G) entry is correct but the packet arrived from a wrong path. The packet will be discarded.
¡ If the RPF interface is not the incoming interface, this means the (S, G) entry has expired, and router replaces the incoming interface with the RPF interface. If the interface on which the packet arrived is the RPF interface, the router forwards the packet out of all the outgoing interfaces. Otherwise it discards the packet.
|
NOTE: The switch allows you to configure special processing of packets that have failed an RPF check instead of simply dropping them. For more information, see "Configuring RPF check failure processing." |
As shown in Figure 1, assume that unicast routes are available in the network, MBGP is not configured, and no static multicast routes have been configured on Switch C. Multicast packets travel along the SPT from the multicast source to the receivers. The multicast forwarding table on Switch C contains the (S, G) entry, with VLAN-interface 5 as the incoming interface.
· When a multicast packet arrives on interface VLAN-interface 5 of Switch C, because the interface is the incoming interface of the (S, G) entry, the router forwards the packet out of all outgoing interfaces.
· When a multicast packet arrives on interface VLAN-interface 2 of Switch C, because the interface is not the incoming interface of the (S, G) entry, the router performs an RPF check on the packet. The router searches its unicast routing table and finds that the outgoing interface to Source (the RPF interface) is VLAN-interface 5. This means the (S, G) entry is correct and packet arrived along a wrong path. The RPF check fails and the packet is discarded.
Static multicast routes
A static multicast route is an important basis for RPF check. Depending on the application environment, a static multicast route can change an RPF route and create an RPF route.
Changing an RPF route
Typically, the topology structure of a multicast network is the same as that of a unicast network, and multicast traffic follows the same transmission path as unicast traffic does. By configuring a static multicast route for a given multicast source, you can change the RPF route to create a transmission path for multicast traffic that is different from that for unicast traffic.
Figure 2 Changing an RPF route
As shown in Figure 2, when no static multicast route is configured, Switch C's RPF neighbor on the path back to Source is Switch A. The multicast information from Source travels along the path from Switch A to Switch C, which is the unicast route between the two routers; with a static multicast route configured on Switch C and with Switch B as Switch C's RPF neighbor on the path back to Source, the multicast information from Source travels from Switch A to Switch B and then to Switch C.
Creating an RPF route
When a unicast route is blocked, multicast traffic forwarding might be stopped due to lack of an RPF route. By configuring a static multicast route for a given multicast source, you can create an RPF route so that a multicast routing entry is created to guide multicast traffic forwarding regardless of whether a unicast route is available.
Figure 3 Creating an RPF route
As shown in Figure 3, the RIP domain and the OSPF domain are unicast isolated from each other. When no static multicast route is configured, the hosts (Receivers) in the OSPF domain cannot receive the multicast packets that the multicast source (Source) sent in the RIP domain. After you configure a static multicast route on Switch C and Switch D, specifying Switch B as the RPF neighbor of Switch C and specifying Switch C as the RPF neighbor of Switch D, the receivers can receive multicast data that the multicast source sent.
|
NOTE: · Static multicast routes affect only RPF checks and they cannot guide multicast forwarding. · A static multicast route takes effect only on the multicast router on which it is configured, and will not be advertised throughout the network or redistributed to other routers. |
GRE tunnel application in multicast forwarding
Some networking devices might not support multicast protocols in a network. Multicast devices forward multicast traffic from a multicast source hop by hop along the forwarding tree. When the multicast traffic is forwarded to a next-hop device that does not support IP multicast, the forwarding path is blocked. In this case, you can enable multicast traffic forwarding across the unicast subnet where the non-multicast-capable device resides by establishing a GRE tunnel between the devices at both ends of the unicast subnet.
For more information about GRE tunneling, see Layer 3—IP Services Configuration Guide.
Figure 4 Multicast data transmission through a GRE tunnel
As shown in Figure 4, with a GRE tunnel established between Device A and Device B, Device A encapsulates multicast data in unicast IP packets, which unicast routers then forward to Device B across the GRE tunnel. Then, Device B strips off the unicast IP header and continues to forward the multicast data down toward the receivers.
If unicast static routes are configured across the tunnel, any unicast packet can be transmitted through the tunnel. If you want to dedicate this tunnel to multicast traffic delivery, you can configure only a static multicast route across the tunnel, so that only multicast packets are transmitted through this tunnel.
Multicast traceroute
The multicast traceroute utility traces the path that a multicast stream flows down from the first-hop router to the last-hop router.
Concepts in multicast traceroute
· Last-hop router—If one of the interfaces of a router connects to the subnet that contains the given destination address, and if the router can forward multicast streams from the given multicast source onto that subnet, that router is called the "last-hop router."
· First-hop router—The router that directly connects to the multicast source is called the "first-hop router."
· Querier—The router that sends multicast traceroute requests is called the "querier."
Introduction to multicast traceroute packets
A multicast traceroute packet is a special IGMP packet, which differs from common IGMP packets in that its IGMP Type field is set to 0x1F or 0x1E and its destination IP address is a unicast address. The following types of multicast traceroute packets are available:
· Query, with the IGMP Type field set to 0x1F.
· Request, with the IGMP Type field set to 0x1F.
· Response, with the IGMP Type field set to 0x1E.
Process of multicast traceroute
1. The querier sends a query to the last-hop router.
2. After receiving the query, the last-hop router turns the query packet into a request packet by adding a response data block, which contains its interface addresses and packet statistics, to the end of the packet. The last-hop router then forwards the request packet through unicast to the previous hop for the given multicast source and group.
3. From the last-hop router to the multicast source, each hop adds a response data block to the end of the request packet and unicasts it to the previous hop.
4. When the first-hop router receives the request packet, it changes the packet type to indicate a response packet, and then sends the completed packet through unicast to the querier.
Configuration task list
Task |
Remarks |
|
Required. |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
||
Optional. |
Follow these guidelines when you perform the tasks in this section:
· Multicast can be routed and forwarded only through the primary IP address of an interface, rather than its secondary address or borrowed address. For more information about primary and secondary IP addresses, and IP unnumbered, see Layer 3—IP Services Configuration Guide.
· When the system is operating in standard mode, you must configure a reserved VLAN before you configure multicast routing and forwarding for a VPN instance. Otherwise, abnormality might occur in the system. After a reserved VLAN is configured, any change of it will incur reconfiguration of the reserved VLAN. For information about the system operating mode, see Fundamentals Configuration Guide. For information about the configuration and commands about a reserved VLAN, see MPLS Configuration Guide and MPLS Command Reference.
Enabling IP multicast routing
Before you configure any Layer 3 multicast functionality, you must enable IP multicast routing.
Enabling IP multicast routing for the public network
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enable IP multicast routing. |
multicast routing-enable |
Disabled by default. |
Enabling IP multicast routing in a VPN instance
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Create a VPN instance and enter VPN instance view. |
ip vpn-instance vpn-instance-name |
For more information about this command, see MPLS Command Reference. |
3. Configure a route distinguisher (RD) for the VPN instance. |
route-distinguisher route-distinguisher |
No RD configured by default. For more information about this command, see MPLS Command Reference. |
4. Enable IP multicast routing. |
multicast routing-enable |
Disabled by default. |
Configuring multicast routing and forwarding
Before you configure multicast routing and forwarding, complete the following tasks:
· Configure a unicast routing protocol so that all devices in the domain are interoperable at the network layer.
· Enable PIM (PIM-DM or PIM-SM).
· Determine the maximum number of downstream nodes for a single multicast forwarding table entry.
· Determine the maximum number of entries in the multicast forwarding table.
Configuring static multicast routes
By configuring a static multicast route for a given multicast source, you can specify an RPF interface or an RPF neighbor for multicast traffic from that source. If you want to remove a specific static multicast route, use the undo ip rpf-route-static command, if you want to remove all static multicast routes, use the delete ip rpf-route-static command.
When you configure a static multicast route, you cannot specify an RPF neighbor by providing the type and number (interface-type interface-number) of the interface if the interface of the RPF neighbor is a Layer 3 Ethernet interface, Layer 3 aggregate interface, Loopback interface, Layer 3 RPR logical interface, or VLAN interface. Instead, you can specify such an RPF neighbor only by its address (rpf-nbr-address).
To configure a static multicast route:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Configure a static multicast route. |
ip rpf-route-static [ vpn-instance vpn-instance-name ] source-address { mask | mask-length } [ protocol [ process-id ] ] [ route-policy policy-name ] { rpf-nbr-address | interface-type interface-number } [ preference preference ] [ order order-number ] |
No static multicast route configured by default. |
3. Delete static multicast routes. |
delete ip rpf-route-static [ vpn-instance vpn-instance-name ] |
Optional. |
Configuring a multicast routing policy
You can configure the router to determine the RPF route based on the longest prefix match principle. For more information about RPF route selection, see "RPF check process."
By configuring per-source or per-source-and-group load splitting, you can optimize the traffic delivery when multiple data flows are handled.
Configuring a multicast routing policy for the public network
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Configure the device to select the RPF route based on the longest match. |
multicast longest-match |
The route with the highest priority is selected as the RPF route by default. |
3. Configure multicast load splitting. |
multicast load-splitting { source | source-group } |
Optional. Disabled by default. This command does not take effect on BIDIR-PIM. |
Configuring a multicast routing policy in a VPN instance
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter VPN instance view. |
ip vpn-instance vpn-instance-name |
N/A |
3. Configure the device to select the RPF route based on the longest match. |
multicast longest-match |
The route with the highest priority is selected as the RPF route by default. |
4. Configure multicast load splitting. |
multicast load-splitting { source | source-group } |
Optional. Disabled by default. This command does not take effect on BIDIR-PIM. |
Configuring a multicast forwarding range
Multicast packets do not travel infinitely in a network. The multicast data corresponding to each multicast group must be transmitted within a definite scope. You can define a multicast forwarding range by specifying boundary interfaces, which form a closed multicast forwarding area.
You can configure a forwarding boundary specific to a particular multicast group on all interfaces that support multicast forwarding. A multicast forwarding boundary sets the boundary condition for the multicast groups in the specified range. If the destination address of a multicast packet matches the set boundary condition, the packet will not be forwarded. After you configure an interface as a multicast boundary, the interface can no longer forward multicast packets (including packets sent from the local device), or receive multicast packets.
To configure a multicast forwarding boundary:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter interface view. |
interface interface-type interface-number |
N/A |
3. Configure a multicast forwarding boundary. |
multicast boundary group-address { mask | mask-length } |
No forwarding boundary by default. |
Configuring the multicast forwarding table size
The router maintains the corresponding forwarding entry for each multicast packet that it receives. However, excessive multicast routing entries can exhaust the router's memory and cause lower router performance.
You can set a limit on the number of entries in the multicast forwarding table based on the networking situation and the performance requirements. If the configured maximum number of multicast forwarding table entries is smaller than the current value, the forwarding entries in excess will not be deleted immediately. Instead, the multicast routing protocols that are running on the router will delete them. The router will no longer add new multicast forwarding entries until the number of existing multicast forwarding entries comes down under the configured value.
When forwarding multicast traffic, the router replicates a copy of the multicast traffic for each downstream node and forwards the traffic. Thus, each of these downstream nodes forms a branch of the multicast distribution tree.
You can configure the maximum number of downstream nodes (the maximum number of outgoing interfaces) for a single entry in the multicast forwarding table to lessen the burden on the router for replicating multicast traffic. If the configured maximum number of downstream nodes for a single multicast forwarding entry is smaller than the current number, the downstream nodes in excess will not be deleted immediately. Instead, the multicast routing protocols that are running on the router will delete them. The router will no longer add new multicast forwarding entries for newly added downstream nodes until the number of existing downstream nodes comes down under the configured value.
Configuring the multicast forwarding table size for the public network
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Configure the maximum number of entries in the multicast forwarding table. |
multicast forwarding-table route-limit limit |
Optional. The default upper limit depends on the system operating mode. For more information, see Fundamentals Configuration Guide. |
3. Configure the maximum number of downstream nodes for a single multicast forwarding entry. |
multicast forwarding-table downstream-limit limit |
Optional. 256 by default. |
Configuring the multicast forwarding table size in a VPN instance
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter VPN instance view. |
ip vpn-instance vpn-instance-name |
N/A |
3. Configure the maximum number of entries in the multicast forwarding table. |
multicast forwarding-table route-limit limit |
Optional. 1024 by default. |
4. Configure the maximum number of downstream nodes for a single route in the multicast forwarding table. |
multicast forwarding-table downstream-limit limit |
Optional. 256 by default. |
Configuring static multicast MAC address entries
In Layer-2 multicast, a Layer 2 multicast protocol (such as IGMP snooping) can dynamically add multicast MAC address entries. Or, you can manually configure multicast MAC address entries.
Configuration guidelines
· Any legal multicast MAC address except 0100-5Exx-xxxx (where x represents a hexadecimal number from 0 to F) can be manually added to the multicast MAC address table. Multicast MAC addresses are the MAC addresses in which the least significant bit of the most significant octet is 1.
· When you configure a static multicast MAC address entry in system view, the configuration takes effect on the specified interface. When you configure a static multicast MAC address entry in interface view or port group view, the configuration takes effect on only the current interface or interfaces in the current port group.
Configuration procedure
To configure a static multicast MAC address entry in system view:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Configure a static multicast MAC address entry. |
mac-address multicast mac-address interface interface-list vlan vlan-id |
No static multicast MAC address entries existing by default. |
To configure a static multicast MAC address entry in interface view:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter Ethernet interface/Layer 2 aggregate interface view or port group view. |
· Enter Ethernet interface/Layer 2 aggregate interface view: · Enter port group view: |
In Ethernet interface view or Layer 2 aggregate interface view, the configuration takes effect on only the current interface. In port group view, the configuration takes effect on all ports in the port group. |
3. Configure a static multicast MAC address entry. |
mac-address multicast mac-address vlan vlan-id |
No static multicast MAC address entries exist by default. |
Configuring RPF check failure processing
After a multicast packet fails RPF check on a VLAN interface, it might need to be processed differently in different networking environments instead of being simply dropped. You can enable forwarding multicast packets that failed RPF check in the VLAN or enable delivering them to the CPU.
Configuration guidelines
After you enable forwarding multicast packets that failed RPF check in the VLAN:
· Use the reset multicast forwarding-table command to clear all the forwarding entries in the multicast forwarding table. Otherwise, this configuration cannot take effect.
· If you configure the multicast programs-on-demand function in a multicast VLAN, you must use the reset igmp-snooping group command to clear all the IGMP snooping multicast group information in the VLAN. Otherwise this configuration cannot take effect.
· For more information about the reset igmp-snooping group command, see IP Multicast Command Reference.
· If the VLAN enabled with the multicast programs-on-demand function is not a multicast VLAN, and a Layer 3 multicast routing protocol (such as IGMP or PIM) has been configured on the corresponding VLAN interface, you need to use the reset igmp group port-info command to clear Layer 2 port information for all IGMP multicast groups in the VLAN and use the reset igmp group command clear all IGMP multicast group information on the corresponding VLAN interface. Otherwise this configuration cannot take effect.
· For more information about the reset igmp group port-info and reset igmp group commands, see IP Multicast Command Reference.
· If the VLAN enabled with the multicast programs-on-demand function is not a multicast VLAN but has IGMP snooping enabled, this configuration cannot take effect.
· If you configure the multicast programs-on-demand function in a VLAN that has been enabled with BIDIR-PIM, you must use the reset multicast forwarding-table command to clear all the forwarding entries in the multicast forwarding table. Otherwise, the configuration cannot take effect.
After you enable delivering the multicast packets that failed RPF check to the CPU, use the reset multicast forwarding-table command to clear all the forwarding entries in the multicast forwarding table. Otherwise this configuration cannot take effect.
Forwarding the packets in the VLAN
A multicast packet that failed RPF check on a VLAN interface might be expected by some receivers in the VLAN. You can enable forwarding such multicast packets through multicast or broadcast in the VLAN so that the receivers can receive them.
With this feature enabled, the router searches its multicast forwarding table after receiving a packet that failed RPF check. If a match is found, it multicasts the packet according to the matching entry. Otherwise, the router broadcasts the packet in the VLAN.
To enable this feature, you also need to enable the multicast programs-on-demand function.
To enable forwarding multicast packets in case of RPF check failure:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enable forwarding multicast packets in case of RPF check failure on VLAN interfaces. |
multicast rpf-fail-pkt bridging |
Disabled by default. |
3. Enter VLAN view. |
vlan vlan-id |
N/A |
4. Enable the multicast programs-on-demand function in the VLAN. |
multicast forwarding on-demand |
Disabled by default. |
Delivering the packet to the CPU
In the following cases, a multicast packet that failed RPF check needs to be delivered to the CPU:
· When a multicast packet arrives on an outgoing interface of the corresponding multicast forwarding entry, the packet will fail RPF check and needs to be sent to the CPU in order to trigger the assert mechanism to prune the unwanted branch.
· If the SPT and RPT have different incoming interfaces on the receiver-side DR (the last-hop router), the multicast traffic will fail RPF check on the SPT incoming interface during an RPT-to-SPT switchover before the RPF information is refreshed. If the RPT is pruned at this moment, the multicast service will be instantaneously interrupted. By delivering packets that failed RPF check on a non-outgoing interface to the CPU, the router can determine whether the packets that have failed RPF check on the SPT interface are expected. If they are, the router initiates an RPT prune.
For more information about the assert mechanism, DR and RPT-to-SPT switchover, see "Configuring PIM."
To enable delivering packets that failed RPF check to the CPU:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enable delivering packets that failed RPF check to the CPU. |
multicast rpf-fail-pkt trap-to-cpu |
Disabled by default. |
|
NOTE: This configuration does not take effect on multicast packets forwarded by BIDIR-PIM entries. |
Tracing a multicast path
You can run the mtracert command to trace the path along which the multicast traffic flows from a given first-hop router to the last-hop router.
To trace a multicast path:
Task |
Command |
Remarks |
Trace a multicast path. |
mtracert source-address [ [ last-hop-router-address ] group-address ] |
Available in any view. |
Displaying and maintaining multicast routing and forwarding
|
CAUTION: The reset commands might cause multicast transmission failures. |
To display and maintain multicast routing and forwarding:
Task |
Command |
Remarks |
Display multicast boundary information. |
display multicast [ all-instance | vpn-instance vpn-instance-name ] boundary [ group-address [ mask | mask-length ] ] [ interface interface-type interface-number ] [ | { begin | exclude | include } regular-expression ] |
Available in any view. |
Display multicast forwarding table information (in standalone mode). |
display multicast [ all-instance | vpn-instance vpn-instance-name ] forwarding-table [ source-address [ mask { mask | mask-length } ] | group-address [ mask { mask | mask-length } ] | incoming-interface { interface-type interface-number | register } | outgoing-interface { exclude | include | match } { interface-type interface-number | register } | statistics | slot slot-number ] * [ port-info ] [ | { begin | exclude | include } regular-expression ] |
Available in any view. |
Display multicast forwarding table information (in IRF mode). |
display multicast [ all-instance | vpn-instance vpn-instance-name ] forwarding-table [ source-address [ mask { mask | mask-length } ] | group-address [ mask { mask | mask-length } ] | incoming-interface { interface-type interface-number | register } | outgoing-interface { exclude | include | match } { interface-type interface-number | register } | statistics | chassis chassis-number slot slot-number ] * [ port-info ] [ | { begin | exclude | include } regular-expression ] |
Available in any view. |
Display the DF information of the multicast forwarding table (in standalone mode). |
display multicast [ all-instance | vpn-instance vpn-instance-name ] forwarding-table df-info [ rp-address ] [ slot slot-number ] [ | { begin | exclude | include } regular-expression ] |
Available in any view. |
Display the DF information of the multicast forwarding table (in IRF mode). |
display multicast [ all-instance | vpn-instance vpn-instance-name ] forwarding-table df-info [ rp-address ] [ chassis chassis-number slot slot-number ] [ | { begin | exclude | include } regular-expression ] |
Available in any view. |
Display multicast routing table information. |
display multicast [ all-instance | vpn-instance vpn-instance-name ] routing-table [ source-address [ mask { mask | mask-length } ] | group-address [ mask { mask | mask-length } ] | incoming-interface { interface-type interface-number | register } | outgoing-interface { exclude | include | match } { interface-type interface-number | register } ] * [ | { begin | exclude | include } regular-expression ] |
Available in any view. |
Display information of the static multicast routing table. |
display multicast routing-table [ all-instance | vpn-instance vpn-instance-name ] static [ source-address { mask-length | mask } ] [ | { begin | exclude | include } regular-expression ] |
Available in any view. |
Display RPF route information of the specified multicast source. |
display multicast [ all-instance | vpn-instance vpn-instance-name ] rpf-info source-address [ group-address ] [ | { begin | exclude | include } regular-expression ] |
Available in any view. |
Display static multicast MAC address entries. |
display mac-address [ mac-address [ vlan vlan-id ] | [ multicast ] [ vlan vlan-id ] [ count ] ] [ | { begin | exclude | include } regular-expression ] |
Available in any view. |
Clear forwarding entries from the multicast forwarding table. |
reset multicast [ all-instance | vpn-instance vpn-instance-name ] forwarding-table { { source-address [ mask { mask | mask-length } ] | group-address [ mask { mask | mask-length } ] | incoming-interface { interface-type interface-number | register } } * | all } |
Available in user view. When a forwarding entry is removed, the associated routing entry will also be removed. |
Clear routing entries from the multicast routing table. |
reset multicast [ all-instance | vpn-instance vpn-instance-name ] routing-table { { source-address [ mask { mask | mask-length } ] | group-address [ mask { mask | mask-length } ] | incoming-interface { interface-type interface-number | register } } * | all } |
Available in user view. When a routing entry is deleted removed, the associated forwarding entry will also be removed. |
For more information about designated forwarder (DF), see "Configuring PIM."
Configuration examples
IMPORTANT: By default, Ethernet interfaces, VLAN interfaces, and aggregate interfaces are in the state of DOWN. To configure such an interface, use the undo shutdown commands to bring it up first. |
Changing an RPF route
Network requirements
As shown in Figure 5, PIM-DM runs in the network. All switches in the network support multicast. Switch A, Switch B and Switch C run OSPF. Typically, Receiver can receive the multicast data from Source through the path: Switch A to Switch B, which is the same as the unicast route.
Perform the following configuration so that Receiver can receive the multicast data from Source through the path: Switch A to Switch C to Switch B, which is different from the unicast route.
Configuration procedure
1. Configure the IP address and subnet mask for each interface as shown in Figure 5. (Details not shown.)
2. Enable OSPF on the switches in the PIM-DM domain to make sure the network-layer is interoperable among the switches in the PIM-DM domain and routing information among the switches can be dynamically updated. (Details not shown.)
3. Enable IP multicast routing, and enable PIM-DM and IGMP:
# Enable IP multicast routing on Switch B, enable PIM-DM on each interface, and enable IGMP on VLAN-interface 100.
<SwitchB> system-view
[SwitchB] multicast routing-enable
[SwitchB] interface vlan-interface 100
[SwitchB-Vlan-interface100] igmp enable
[SwitchB-Vlan-interface100] pim dm
[SwitchB-Vlan-interface100] quit
[SwitchB] interface vlan-interface 101
[SwitchB-Vlan-interface101] pim dm
[SwitchB-Vlan-interface101] quit
[SwitchB] interface vlan-interface 102
[SwitchB-Vlan-interface102] pim dm
[SwitchB-Vlan-interface102] quit
# Enable IP multicast routing on Switch A, and enable PIM-DM on each interface.
<SwitchA> system-view
[SwitchA] multicast routing-enable
[SwitchA] interface vlan-interface 200
[SwitchA-Vlan-interface200] pim dm
[SwitchA-Vlan-interface200] quit
[SwitchA] interface vlan-interface 102
[SwitchA-Vlan-interface102] pim dm
[SwitchA-Vlan-interface102] quit
[SwitchA] interface vlan-interface 103
[SwitchA-Vlan-interface103] pim dm
[SwitchA-Vlan-interface103] quit
# Enable IP multicast routing and enable PIM-DM on Switch C in the same way. (Details not shown.)
# Use the display multicast rpf-info command to view the RPF route to Source on Switch B.
[SwitchB] display multicast rpf-info 50.1.1.100
RPF information about source 50.1.1.100:
RPF interface: Vlan-interface102, RPF neighbor: 30.1.1.2
Referenced route/mask: 50.1.1.0/24
Referenced route type: igp
Route selection rule: preference-preferred
Load splitting rule: disable
The output shows that the current RPF route on Switch B is contributed by a unicast routing protocol and the RPF neighbor is Switch A.
4. Configure a static multicast route on Switch B, specifying Switch C as its RPF neighbor on the route to Source.
[SwitchB] ip rpf-route-static 50.1.1.100 24 20.1.1.2
Verifying the configuration
# Use the display multicast rpf-info command to view the information about the RPF route to Source on Switch B.
[SwitchB] display multicast rpf-info 50.1.1.100
RPF information about source 50.1.1.100:
RPF interface: Vlan-interface101, RPF neighbor: 20.1.1.2
Referenced route/mask: 50.1.1.0/24
Referenced route type: multicast static
Route selection rule: preference-preferred
Load splitting rule: disable
The output shows that the RPF route on Switch B has changed. It is now the configured static multicast route, and the RPF neighbor is now Switch C.
Creating an RPF route
Network requirements
As shown in Figure 6, PIM-DM runs in the network and all switches in the network support IP multicast. Switch B and Switch C run OSPF, and have no unicast routes to Switch A. Typically, Receiver can receive the multicast data from Source 1 in the OSPF domain.
Perform the following configuration so that Receiver can receive multicast data from Source 2, which is outside the OSPF domain.
Configuration procedure
1. Configure the IP address and subnet mask for each interface as shown in Figure 6. (Details not shown.)
2. Enable OSPF on Switch B and Switch C to make sure the network-layer is interoperable between Switch B and Switch C and their routing information can be dynamically updated. (Details not shown.)
3. Enable IP multicast routing, and enable PIM-DM and IGMP:
# Enable IP multicast routing on Switch C, enable PIM-DM on each interface, and enable IGMP on VLAN-interface 100.
<SwitchC> system-view
[SwitchC] multicast routing-enable
[SwitchC] interface vlan-interface 100
[SwitchC-Vlan-interface100] igmp enable
[SwitchC-Vlan-interface100] pim dm
[SwitchC-Vlan-interface100] quit
[SwitchC] interface vlan-interface 101
[SwitchC-Vlan-interface101] pim dm
[SwitchC-Vlan-interface101] quit
# Enable IP multicast routing on Switch A and enable PIM-DM on each interface.
<SwitchA> system-view
[SwitchA] multicast routing-enable
[SwitchA] interface vlan-interface 300
[SwitchA-Vlan-interface300] pim dm
[SwitchA-Vlan-interface300] quit
[SwitchA] interface vlan-interface 102
[SwitchA-Vlan-interface102] pim dm
[SwitchA-Vlan-interface102] quit
# Enable IP multicast routing and enable PIM-DM on Switch B in the same way. (Details not shown.)
# Use the display multicast rpf-info command to view the RPF routes to Source 2 on Switch B and Switch C.
[SwitchB] display multicast rpf-info 50.1.1.100
[SwitchC] display multicast rpf-info 50.1.1.100
No information is displayed, so no RPF route to Source 2 exists on Switch B or Switch C.
4. Configure a static multicast route:
# Configure a static multicast route on Switch B, specifying Switch A as its RPF neighbor on the route to Source 2.
[SwitchB] ip rpf-route-static 50.1.1.100 24 30.1.1.2
# Configure a static multicast route on Switch C, specifying Switch B as its RPF neighbor on the route to Source 2.
[SwitchC] ip rpf-route-static 10.1.1.100 24 20.1.1.2
Verifying the configuration
# Use the display multicast rpf-info command to view the RPF routes to Source 2 on Switch B and Switch C.
[SwitchB] display multicast rpf-info 50.1.1.100
RPF information about source 50.1.1.100:
RPF interface: Vlan-interface102, RPF neighbor: 30.1.1.2
Referenced route/mask: 50.1.1.0/24
Referenced route type: multicast static
Route selection rule: preference-preferred
Load splitting rule: disable
[SwitchC] display multicast rpf-info 50.1.1.100
RPF information about source 50.1.1.100:
RPF interface: Vlan-interface101, RPF neighbor: 20.1.1.2
Referenced route/mask: 50.1.1.0/24
Referenced route type: multicast static
Route selection rule: preference-preferred
Load splitting rule: disable
The output shows that the RPF routes to Source 2 exist on Switch B and Switch C. The routes are the configured static routes.
Multicast forwarding over a GRE tunnel
Network requirements
As shown in Figure 7, multicast routing and PIM-DM are enabled on Switch A and Switch C. Switch B does not support multicast. OSPF is running on Switch A, Switch B, and Switch C.
Perform the following configurations so that Receiver can receive the multicast data from Source.
Configuration procedure
1. Configure the IP address and subnet mask for each interface as shown in Figure 7. (Details not shown.)
2. Configure a GRE tunnel:
# Create Tunnel 0 on Switch A and configure the IP address and subnet mask for the interface.
<SwitchA> system-view
[SwitchA] interface tunnel 0
[SwitchA-Tunnel0] ip address 50.1.1.1 24
# Configure Tunnel 0 to operate in the GRE tunnel mode and specify the source and destination addresses for the interface.
[SwitchA-Tunnel0] tunnel-protocol gre
[SwitchA-Tunnel0] source 20.1.1.1
[SwitchA-Tunnel0] destination 30.1.1.2
[SwitchA-Tunnel0] quit
# Create Tunnel 0 on Switch C and configure the IP address and subnet mask for the interface.
<SwitchC> system-view
[SwitchC] interface tunnel 0
[SwitchC-Tunnel0] ip address 50.1.1.2 24
# Configure Tunnel 0 on Switch C to operate in the GRE tunnel mode and configure the source and destination addresses for the interface.
[SwitchC-Tunnel0] tunnel-protocol gre
[SwitchC-Tunnel0] source 30.1.1.2
[SwitchC-Tunnel0] destination 20.1.1.1
[SwitchC-Tunnel0] quit
3. Configure OSPF:
# Configure OSPF on Switch A.
[SwitchA] ospf 1
[SwitchA-ospf-1] area 0
[SwitchA-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[SwitchA-ospf-1-area-0.0.0.0] network 20.1.1.0 0.0.0.255
[SwitchA-ospf-1-area-0.0.0.0] network 50.1.1.0 0.0.0.255
[SwitchA-ospf-1-area-0.0.0.0] quit
[SwitchA-ospf-1] quit
# Configure OSPF on Switch B.
<SwitchB> system-view
[SwitchB] ospf 1
[SwitchB-ospf-1] area 0
[SwitchB-ospf-1-area-0.0.0.0] network 20.1.1.0 0.0.0.255
[SwitchB-ospf-1-area-0.0.0.0] network 30.1.1.0 0.0.0.255
[SwitchB-ospf-1-area-0.0.0.0] quit
[SwitchB-ospf-1] quit
# Configure OSPF on Switch C.
[SwitchC] ospf 1
[SwitchC-ospf-1] area 0
[SwitchC-ospf-1-area-0.0.0.0] network 30.1.1.0 0.0.0.255
[SwitchC-ospf-1-area-0.0.0.0] network 40.1.1.0 0.0.0.255
[SwitchC-ospf-1-area-0.0.0.0] network 50.1.1.0 0.0.0.255
[SwitchC-ospf-1-area-0.0.0.0] quit
[SwitchC-ospf-1] quit
4. Enable IP multicast routing, PIM-DM, and IGMP:
# Enable multicast routing on Switch A and enable PIM-DM on each interface.
[SwitchA] multicast routing-enable
[SwitchA] interface vlan-interface 100
[SwitchA-Vlan-interface100] pim dm
[SwitchA-Vlan-interface100] quit
[SwitchA] interface vlan-interface 101
[SwitchA-Vlan-interface101] pim dm
[SwitchA-Vlan-interface101] quit
[SwitchA] interface tunnel 0
[SwitchA-Tunnel0] pim dm
[SwitchA-Tunnel0] quit
# Enable multicast routing on Switch C, enable PIM-DM on each interface, and enable IGMP on VLAN-interface 200.
[SwitchC] multicast routing-enable
[SwitchC] interface vlan-interface 200
[SwitchC-Vlan-interface200] igmp enable
[SwitchC-Vlan-interface200] pim dm
[SwitchC-Vlan-interface200] quit
[SwitchC] interface vlan-interface 102
[SwitchC-Vlan-interface102] pim dm
[SwitchC-Vlan-interface102] quit
[SwitchC] interface tunnel 0
[SwitchC-Tunnel0] pim dm
[SwitchC-Tunnel0] quit
5. On Switch C, configure a static multicast route, specifying the RPF neighbor leading toward Source as Tunnel 0 on Switch A.
[SwitchC] ip rpf-route-static 50.1.1.0 24 50.1.1.1
Verifying the configuration
Source sends multicast data to the multicast group 225.1.1.1 and Receiver can receive the multicast data after joining the multicast group. You can view the PIM routing table information on routers using the display pim routing-table command. For example:
# View the PIM routing table information on Switch C.
[SwitchC] display pim routing-table
VPN-Instance: public net
Total 1 (*, G) entry; 1 (S, G) entry
(*, 225.1.1.1)
Protocol: pim-dm, Flag: WC
UpTime: 00:04:25
Upstream interface: NULL
Upstream neighbor: NULL
RPF prime neighbor: NULL
Downstream interface(s) information:
Total number of downstreams: 1
1: Vlan-interface200
Protocol: igmp, UpTime: 00:04:25, Expires: never
(10.1.1.100, 225.1.1.1)
Protocol: pim-dm, Flag: ACT
UpTime: 00:06:14
Upstream interface: Tunnel0
Upstream neighbor: 50.1.1.1
RPF prime neighbor: 50.1.1.1
Downstream interface(s) information:
Total number of downstreams: 1
1: Vlan-interface200
Protocol: pim-dm, UpTime: 00:04:25, Expires: never
The output shows that Switch A is the RPF neighbor of Switch C and the multicast data from Switch A is delivered over a GRE tunnel to Switch C.
Troubleshooting multicast routing and forwarding
Static multicast route failure
Symptom
No dynamic routing protocol is enabled on the routers, and the physical status and link layer status of interfaces are both up, but the static multicast route fails.
Analysis
· If the static multicast route is not configured or updated correctly to match the current network conditions, the route entry and the configuration information of static multicast route do not exist in the multicast routing table.
· If a better route is found, the static multicast route might also fail.
Solution
1. Use the display multicast routing-table static command to view the information of static multicast routes to verify that the static multicast route has been correctly configured and the route entry exists in the multicast routing table.
2. Check the type of the next hop interface of the static multicast route. If the interface is not a point-to-point interface, be sure to specify the next hop address for the outgoing interface when you configure the static multicast route.
3. Check that the static multicast route matches the specified routing protocol. If a protocol was specified in static multicast route configuration, enter the display ip routing-table command to check if an identical route was added by the protocol.
4. Check that the static multicast route matches the specified routing policy. If a routing policy was specified when the static multicast route was configured, enter the display route-policy command to check the configured routing policy.
Multicast data fails to reach receivers
Symptom
The multicast data can reach some routers but cannot reach the last-hop router.
Analysis
If a multicast forwarding boundary has been configured through the multicast boundary command, any multicast packet will be kept from crossing the boundary.
Solution
1. Use the display pim routing-table command to check whether the corresponding (S, G) entries exist on the router. If so, the router has received the multicast data. Otherwise, the router has not received the data.
2. Use the display multicast boundary command to view the multicast boundary information on the interfaces. Use the multicast boundary command to change the multicast forwarding boundary setting.
3. In the case of PIM-SM, use the display current-configuration command to check the BSR and RP information.