PIM SM + IGMP snooping suitability Test (ii) TTL problem

PIM SM + IGMP snooping suitability Test (ii) Introduction to TTL issues

The two questions and answers in the previous section are based on theoretical analysis and experimental validation, and this section describes the problems encountered in experiments and experiments.

Test topology

Figure 1

Experiment Description

Before doing experiments to verify the technical problems, first of all to clarify the purpose of the experiment, then detailed planning to build the experimental steps, and then list the steps used to verify the experiment. The last important step is the experiment deduction, before the experiment should use the theory to make a rough deduction to the experiment process and the phenomenon, can guarantee the control of the experiment process.

Experimental purpose

The aim of the experiment was to test:
1) Bootstrap protocol BSR is preempted;
2) How IGMP snooping handles failover of the downstream two-layer redundant link.

Building the experimental steps

I built the experimental topology with a small number of devices, 1, the lab has a Cisco C2800 router (RP_BSR), a Huawei S5720 three layer switch (Huiju), a two-layer switch (S5700) for the company Jieru, and two laptops with VLC installed Media Player.
1) The whole network routing can be reached between RP_BSR and Huiju through OSPF;
2) RP_BSR and Huiju establish PIM SM neighbor, note: RP_BSR F0/1 must open PIM, otherwise RP_BSR can not forward the group broadcast text;
3) RP_BSR configuration c-rp for 224.0.0.0/4, C-BSR source Lo0 priority 2501;
4) Configure C-BSR source Lo0 priority 0 on Huiju;
5) Huiju on SVI VLAN 100 on IGMP, VLAN 100 on IGMP snooping;
6) Multicast source with VLC ready to launch streaming video, destination address 224.1.1.1, group members with VLC ready to accept UDP streaming video from 224.1.1.1
。

Verifying the experimental steps

1) After Bootstrap protocol convergence (130s), RP_BSR, Huiju to view BSR election results;
2) To change the priority of the candidate BSR (greater than the current BSR), RP_BSR, Huiju to view BSR election results;
3) The two links between Huiju and Jieru utilize STP protocol redundancy;
4) The multicast source starts to play, the group member begins to receive;
5) Disconnect the fowarding link between the Huiju and the Jieru, and the group member catches the packet to observe the phenomenon;
6) Change the link redundancy protocol between Huiju and Jieru, repeat 5).

Experimental phenomenon Deduction

1) 1 After the configuration is complete, huiju and RP_BSR will try to become BSR, RP_BSR priority is greater than Huiju, Huiju received RP_BSR bootstrap message, will reset the boot timer, keep listening state, and RP_ BSR will continue to send the bsr,130s boot timer after timeout, RP_BSR becomes BSR,RP_BSR at the same time as the C-RP,RP_BSR becomes BSR will flood Rp-set,huiju and RP_BSR will think RP_BSR is 224.0.0.0/ 4 Groups of Rp;2
2) Change the C-BSR priority of Huiju to 255, Huiju will find that its priorities are higher, 130s will preempt BSR,RP_BSR and Huiju can see Huiju become BSR,RP_BSR will send candidate RP declaration to Huiju, Huiju to the whole network flooding Rp-set,huiju and RP_BSR will think RP_BSR is the RP of the 224.0.0.0/4 group;
3) After the multicast source starts playing, a multicast stream with the destination address of 224.1.1.1 is sent, and a RP_BSR (s,g) entry (10.10.10.2,224,1,1,1) 3,incoming interface is created after the multicast packet is received f0/ The 1,outgoing interface is null, and the group member begins to receive, and the team members send the IGMP Membership report message Huiju it to join the 224.1.1.1 group, Huiju generates a (*,G) entry (*, 224.1.1.1), The interface to the RP is set to the incoming interface, VLANIF 100 is configured as a outgoing interface, and a join message is sent to the RP, while IGMP snooping adds G0/0/14 to 224.1.1.1 's link layer forwarding 5;RP_BSR When the join message is received, the f0/0 is set to the (10.10.10.2,224,1,1,1) outgoing interface and the multicast stream is sent to f0/0, and the member group begins to receive the video on VLC.
4) When the LINK1 is disconnected, the group member on the multicast video will be broken, but will not recover, how to restore the need to see the phenomenon, and analysis.

Experimental validation

The previous background is covered, and the experimental results are detailed in the "PIM SM + IGMP snooping Applicability Test" section, which is not described here. It is time to talk about the key elements of this section. In fact, the experimental verification process is not as smooth as the experimental phenomenon, the process has a very secret problem, this section focuses on how to find and solve the problem.

Problem description

When I set up the experimental environment to prepare the test, I found that the group member VLC can not receive the video anyway, the team member grabbed the package and no multicast packets from the multicast source, I also see (10.10.10.2,224,1,1,1) on the RP_BSR (s,g) entry, But I ping 224.1.1.1 on the multicast source PC, RP_BSR did establish the (S,G) entry, and in the S5700 (the switch shown in Figure 1) through the switch port mirroring the packet, we found that the multicast source did send the multicast stream to the RP_BSR. Why the router does not forward VLC sent to the multicast package, really let me think of its solution.

Problem solving

When I analyze ping and UDP multicast packets why not at the same time, I suddenly thought it would be TTL in the mischief, I caught on the multicast source PC on the multicast packet on the IP header is found on the TTL is 1 (see Figure 2), which means that the default multicast stream can only be propagated within the LAN and not through the router.

Figure 2
Know the cause of the problem to solve, I found on the Internet can be manually specified in the form of the command line VLC send packet TTL value, similar to the following:

vlc -vvv D:\test.mkv --sout udp:224.1.1.1:1234 --ttl 10

The problem is solved.

Subsequent

Actually, the results of the experiment were also analyzed by the clutch. Before the experiment, I wasn't exactly sure how IGMP snooping handles the downlink two-layer redundant link failover, including how IGMP works. The experiment can see that IGMP snooping itself has no mechanism to perceive whether the downlink two-layer link is redundant, but rather relies on IGMP's own mechanism. By grasping the packet you can see the router IGMP interface sends a membership query to the subnet every 60s, and the group member responds to membership report. At this point the IGMP snooping can learn the new downstream interface. So I thought it would be possible to shorten the interrupt time of the multicast stream by changing the time interval of the small router IGMP membership query, and the result really worked as shown in 3:

Figure 3
There must be some doubt here, since IGMP snooping is so smart, why stick with it? The problem is simple, when the link between Huiju and Jieru is leased to the operator's leased line, the bandwidth is limited, IGMP snooping is still very effective.

1. BSR priority value 0~255, priorty the same comparison IP address, the larger the higher the first;
2. The Bootstrap principle is described in the "PIM SM + IGMP snooping applicability test" subsection;
3. When the multicast source is not directly connected with the RP, the issue of source registration and RPT Switching SPT is also involved.
4. The topology shown in Figure 1 assumes that Huiju is the STP root bridge, and STP on Jieru chooses G0/0/1
   As the root port (because the G0/0/1 ID of the huiju is small), the G0/0/2 is blocked, so the IGMP Membership report is sent from Link1;
5. This table is available in the "PIM SM + IGMP snooping suitability test" subsection.

PIM SM + IGMP snooping suitability Test (ii) TTL problem