I think configuring PIM won't help on the nexus as this isn't igmp multicast. I see you say that resetting the multicast source will regenerate igmp queries again so I do understand this. The issue is solved after resetting nlb server and then after some time the problem happen again and so on. I try to ping the nlb from the same vlan but fail. The nlb become not pingable and the exchange become not reachable
#Why iptv channels stops after seconds on smart iptv mac#
So I configured static ARP on the nexus for this mac with the nlb ip addres to be reachable from all the network and all is working fineīut the problem is that after few hours. We can ping the nlb address from the same vlan only We configured nlb to use multicast and it produce mac address start with 03xx not IANA standard The fabric interconnect is in end host mode and connected to Nexus 5548 as layer 3 switch
I have Microsoft nlb for exchange installed on UCS This discussion is great and is very similar to a problem happen with me What happens if Host 2 is not interested in the multicast traffic anymore, but does not send and IGMP leave message (a behavior which is supported according to the protocol, to my knowledge)? how does SW1 know it should stop answer the IGMP queries sent by Host 1? How does SW1 know it should keep the port channel as part of the group, if it does not hear IGMP reports coming from SW2 anymore?Ģ. I also noticed that IGMP reports generated by Host 2 stop arriving on SW1 (since SW2 does not know it has an mrouter connected to the other side of the port channel anymore).ġ. When i ran "show ip igmo snooping groups" I saw the same output on both switches: On both switches the groups contained both Eth1/1 and the port channel, but after a while, the switch connected to Host 2 removed the port channel from the group.Īfter viewing the switch logs and sniffing the traffic on one of the port channel interfaces on SW1, i got to the conclusion that it happens since SW1 stops sending the queries generated by Host 1, and rather answers them locally (some proxy or something). Once Host 1 boots, it sends an IGMP query (which is flooded over the port channel), and multicast traffic starts flowing to Host 2. Since SW2 does not know where the mrouter of the group, it adds port Eth1/1 to the snooping group, and discards the packet the IGMP packet. Host 2 boots and sends an IGMP report, in order to join Host 1's multicast group. IGMP snooping is configured on both switches. Where Host 1 is a multicast traffic source, and Host 2 is a multicast traffic client.
0 kommentar(er)
