Multicast with source redundancy - Stream disrupted
I'm currently building a multicast infrastructure for IPTV and need to provide redundancy with my source.
In my current prototype system I'm using a Cisco 3560-IPBASE-M (SMI) v12.2(25).
Here is the layout:
Source 1 (VLAN X)
Cisco 3560 - Set Top Box (VLAN X)
Source 2 (VLAN Y)
So Source 1 is connected to the 3560 on VLAN X, Source 2 is connected to the 3560 on VLAN Y and the Set Top Box is connected on VLAN X.
Source 1 and Source 2 do not have the same IP address.
Both sources are sending a multicast stream to 188.8.131.52. The Set Top Box is subscribed to this multicast group and is receiving the stream from Source 1.
When there is a problem with Source 1, I change its VLAN to VLAN Z, and change Source 2's VLAN to VLAN X.
So the Set Top Box is supposed to pick up the stream from source 2.
Going from Source 1 to Source 2 is OK. The Set Top Box is still able to pickup the stream but going from Source 2 to Source 1 (and changing the VLAN accordingly) leads to a 30 seconds (precisely and always 30 seconds) period during which the stream is not received by the Set Top Box.
I've made no other modification to the Cisco configuration (except configuration and modifying VLANs).
What could go wrong?
I've tried to statically configure the 3 interfaces to be member of the multicast groups:
ip igmp snooping vlan 124 static 184.108.40.206 interface Fa0/44 (45 and 46)
but this does not change anything.
I've also tried to give both sources the same IP address without success either. I'm using IGMP v2, not v3, so having different IP addresses should not be a problem.
Re: Multicast with source redundancy - Stream disrupted
Just to let you know that I found the problem.
When you connect a cable on the switch, there is a 30 seconds period (in fact 15+15) during which the device that you connected is not reachable through the network. That is due to the spanning-tree protocol that is first in listening mode (15s) then in learning mode (15s) before going to a forwarding state in order not to create forwarding loops on the network.
The same thing happens when you change the VLAN of a port.
In order to eliminate this problem, you just need to declare the port as portfast (spanning-tree portfast). The STP will not go through the listening and learning state but directly to the forwarding state when you either connect a new device on the port or you change the VLAN of an already connected device.
Hope it can help other people who would have had the same problem.
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...