[c-nsp] Multicast issue
My source multicast supplier is sending two flows for the same mcast group (224.0.4.4) 355715: Jun 11 08:55:45.870 CET: %SEC-6-IPACCESSLOGP: list 198 permitted udp 1.1.1.1(0) - 224.0.4.4(0), 150 packets 355717: Jun 11 08:56:45.871 CET: %SEC-6-IPACCESSLOGP: list 198 permitted udp 2.2.2.2(0) - 224.0.4.4(0), 5827 packets in my C3925 (connected to the mcast supplier on g0/1.10) mroute table I see just one source active: #sh ip mroute 224.0.4.4 count Use show ip mfib count to get better response time for a large number of mroutes. IP Multicast Statistics 9 routes using 4458 bytes of memory 5 groups, 0.80 average sources per group Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 224.0.4.4, Source count: 1, Packets forwarded: 4251, Packets received: 264466 RP-tree: Forwarding: 0/0/0/0, Other: 260215/260215/0 Source: 1.1.1.1/32, Forwarding: 4251/0/44/0, Other: 4251/0/0 If I do clear ip mroute 224.0.4.4 the second source is added in mroute table: #sh ip mroute 224.0.4.4 count IP Multicast Statistics 10 routes using 4984 bytes of memory 5 groups, 1.00 average sources per group Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 224.0.4.4, Source count: 2, Packets forwarded: 2402, Packets received: 2424 RP-tree: Forwarding: 0/0/0/0, Other: 22/22/0 Source: 1.1.1.1/32, Forwarding: 48/0/44/0, Other: 48/0/0 Source: 2.2..2.2/32, Forwarding: 2354/0/371/0, Other: 2354/0/0 Both has ingress and egress intf: #sh ip mroute 224.0.4.4 IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group, V - RD Vector, v - Vector Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.4.4), 00:02:10/stopped, RP 172.21.15.2, flags: SPF Incoming interface: GigabitEthernet0/0, RPF nbr 10.11.254.33 Outgoing interface list: Null (1.1.1.1, 224.0.4.4), 00:01:26/00:02:03, flags: FT Incoming interface: GigabitEthernet0/1.10, RPF nbr 10.2.0.233 Outgoing interface list: GigabitEthernet0/0, Forward/Sparse-Dense, 00:01:26/00:03:02 (2.2.2.2, 224.0.4.4), 00:02:10/00:03:23, flags: FT Incoming interface: GigabitEthernet0/1.10, RPF nbr 10.2.0.233 Outgoing interface list: GigabitEthernet0/0, Forward/Sparse-Dense, 00:02:08/00:03:19 This works since the mcast flow is running, once it's stopped by supplier and restarted again in the morning I've to do again the clear ip mroute xxx Any idea why I'm experiencing this behaviour ? Tks ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] multicast issue
On 07/17/2013 05:28 PM, Chris Marget wrote: Span mode? Nope. Just an optical splitter at the carrier handoff. Just to add a +1 - tap rather than SPAN is important, because SPAN has some distinctly screwy behaviours w.r.t multicast traffic on some platforms. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] multicast issue
I manage a network where multicast is the most important traffic and sometimes I get issue by customer where they state that some packets are lost… I used to manage a the network for a very large financial firm, had to deal with this sort of issue all the time. I had optical taps in multiple spots in the environment. The most important ones collected data at the edge and at the server handoff. These taps fed into a Niksun appliance which wrote full packets to disk. Niksun is a powerful box, but I used it primarily to deliver pcaps, not so much for its analysis features. Analysis was done with some stuff that I'd whipped up, because I couldn't find any off-the-shelf products that gave useful visibility into what was happening on the wire. Case study of a missing packets incident here: http://bit.ly/13jjP7z A video highlighting my analysis tool here: http://bit.ly/ygf8EG /chris ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] multicast issue
If I get your description you have the tap (which vendor? ) at source and destination (I guess in span mode?), these taps send data to niksun appliance (which model?) that create the pcap and then you can analyse for example with wireshark these files, am I correct? The taps were NetOptics iTaps, but didn't need to be. The important part of the tap was the optical splitter, which is usually around US $300 for a duplex unit. Span mode? Nope. Just an optical splitter at the carrier handoff. The Niksun was a NetVCR appliance of some sort. I just used it for capture, not analysis. I'd probably have been happier with a Linux system and a hardware capture card (endace, napatech, etc...), but this environment tended to prefer gold-plated appliances rather than homegrown solutions. The whole system was put together in order to demonstrate whether my gear (enterprise routers/switches/firewalls) were delivering data from the transit provider's handoff down to the servers. By storing every packet that crossed the various handoffs (into my equipment at one end, and out of it at the other end), I could prove to the pricing feed people whether I was responsible for any problems they were seeing. Wireshark was one of the analysis tools I used, but it was not particularly helpful for the protocols I was transporting. The links I shared previously detailed some of the analysis techniques. /chris ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] multicast issue
Hi, We run a BGP NG-MVPN for IPTV content delivery, with Juniper MX480 in the PE layer and Cisco CRS in the P layer. With RSVP-TE P2MP LSP running from the Sender PE ( which is connecting to the multicast upstream HE router ) to the Receiver PE routers ( with downstream GPON IPTV subscribers ). We have BrixVision IPTV probes at the Sender PE router before the traffic enter our MPLS cloud and the same type of probes at Receiver PE routers. So far there is no need for IPTV probes along the RSVP-TE P2MP LSP path. This will help to determine the traffic quality in the IP/MPLS core. At the downstream we have STB probe aka Single Channel Probe from the same brand deployed at the customer's place if there is a picture quality complaint. This will help us to determine issue from receiver PE router through the GPON networks towards the customer home. We had evaluated Ineoquest before, however we found Brixvision was more suitable to our environment. In the early stage of deployment we kept our eye on the IAT and MLR on the probe almost everyday. The Brixvision has very detail real time zoomed-in analysis like TS Sync, PAT, CRC and etc per group. Hope this help. Regards Amos Thong -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of R S Sent: Wednesday, July 17, 2013 12:53 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] multicast issue Hi all Just a brainstorming and your possible help. I manage a network where multicast is the most important traffic and sometimes I get issue by customer where they state that some packets are lost... Does anybody have an idea or can help me in understanding a possible solution in monitoring traffic in real time manner, maybe with the use of some software or appliance or whatelse. In my idea I could monitor traffic on the source and on the destination, then with a sort of parsing understand if it's my network loosing the packets or not... Any idea ? suggestion ? tks ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ CONFIDENTIALITY - The contents of and any attachments to this email are private and confidential. If you are not the intended recipient or addressee indicated in this message, please notify the sender of the error and destroy the email and any attachments. Please do not reproduce the contents of the email or its attachments as such reproduction is a breach of confidentiality and for which legal action including injunctive relief may be sought against you. If it is your company policy that official communications are not by email, please advise immediately. Any opinions, conclusions and other information in this message that do not relate to the official business of TIME dotCom shall be understood as neither given nor endorsed by TIME dotCom, nor shall TIME dotCom shall be liable (directly or vicariously) for such opinions, statements or communications. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] multicast issue
Hi, Our version is video verifier which is specially design for IPTV. I am not sure if they have a version that do non-video multicast. You might want to have a look at their range of product at their homepage at http://www.exfo.com/ Regards Amos Thong From: dim0sal [mailto:dim0...@hotmail.com] Sent: Wednesday, July 17, 2013 11:53 PM To: Thong Hawk Yen; cisco-nsp@puck.nether.net Subject: R: RE: [c-nsp] multicast issue Hi Is brixvision suitable also for not iptv mcast flows? We run financial market mcast flows. .. Tks Sent with Mobile Messaggio originale Da: Thong Hawk Yen hawk.yen.th...@time.com.my Data: A: R S dim0...@hotmail.com,cisco-nsp@puck.nether.net Oggetto: RE: [c-nsp] multicast issue Hi, We run a BGP NG-MVPN for IPTV content delivery, with Juniper MX480 in the PE layer and Cisco CRS in the P layer. With RSVP-TE P2MP LSP running from the Sender PE ( which is connecting to the multicast upstream HE router ) to the Receiver PE routers ( with downstream GPON IPTV subscribers ). We have BrixVision IPTV probes at the Sender PE router before the traffic enter our MPLS cloud and the same type of probes at Receiver PE routers. So far there is no need for IPTV probes along the RSVP-TE P2MP LSP path. This will help to determine the traffic quality in the IP/MPLS core. At the downstream we have STB probe aka Single Channel Probe from the same brand deployed at the customer's place if there is a picture quality complaint. This will help us to determine issue from receiver PE router through the GPON networks towards the customer home. We had evaluated Ineoquest before, however we found Brixvision was more suitable to our environment. In the early stage of deployment we kept our eye on the IAT and MLR on the probe almost everyday. The Brixvision has very detail real time zoomed-in analysis like TS Sync, PAT, CRC and etc per group. Hope this help. Regards Amos Thong -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of R S Sent: Wednesday, July 17, 2013 12:53 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] multicast issue Hi all Just a brainstorming and your possible help. I manage a network where multicast is the most important traffic and sometimes I get issue by customer where they state that some packets are lost... Does anybody have an idea or can help me in understanding a possible solution in monitoring traffic in real time manner, maybe with the use of some software or appliance or whatelse. In my idea I could monitor traffic on the source and on the destination, then with a sort of parsing understand if it's my network loosing the packets or not... Any idea ? suggestion ? tks ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ CONFIDENTIALITY - The contents of and any attachments to this email are private and confidential. If you are not the intended recipient or addressee indicated in this message, please notify the sender of the error and destroy the email and any attachments. Please do not reproduce the contents of the email or its attachments as such reproduction is a breach of confidentiality and for which legal action including injunctive relief may be sought against you. If it is your company policy that official communications are not by email, please advise immediately. Any opinions, conclusions and other information in this message that do not relate to the official business of TIME dotCom shall be understood as neither given nor endorsed by TIME dotCom, nor shall TIME dotCom shall be liable (directly or vicariously) for such opinions, statements or communications. CONFIDENTIALITY - The contents of and any attachments to this email are private and confidential. If you are not the intended recipient or addressee indicated in this message, please notify the sender of the error and destroy the email and any attachments. Please do not reproduce the contents of the email or its attachments as such reproduction is a breach of confidentiality and for which legal action including injunctive relief may be sought against you. If it is your company policy that official communications are not by email, please advise immediately. Any opinions, conclusions and other information in this message that do not relate to the official business of TIME dotCom shall be understood as neither given nor endorsed by TIME dotCom, nor shall TIME dotCom shall be liable (directly or vicariously) for such opinions, statements or communications. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
Re: [c-nsp] multicast issue
ASR 9000 has video monitoring capabilites built in. No need to use additional gear in most of the scenarios. -- ./ Dnia 17 lip 2013 o godz. 19:06 Thong Hawk Yen hawk.yen.th...@time.com.my napisał(a): Hi, Our version is video verifier which is specially design for IPTV. I am not sure if they have a version that do non-video multicast. You might want to have a look at their range of product at their homepage at http://www.exfo.com/ Regards Amos Thong From: dim0sal [mailto:dim0...@hotmail.com] Sent: Wednesday, July 17, 2013 11:53 PM To: Thong Hawk Yen; cisco-nsp@puck.nether.net Subject: R: RE: [c-nsp] multicast issue Hi Is brixvision suitable also for not iptv mcast flows? We run financial market mcast flows. .. Tks Sent with Mobile Messaggio originale Da: Thong Hawk Yen hawk.yen.th...@time.com.my Data: A: R S dim0...@hotmail.com,cisco-nsp@puck.nether.net Oggetto: RE: [c-nsp] multicast issue Hi, We run a BGP NG-MVPN for IPTV content delivery, with Juniper MX480 in the PE layer and Cisco CRS in the P layer. With RSVP-TE P2MP LSP running from the Sender PE ( which is connecting to the multicast upstream HE router ) to the Receiver PE routers ( with downstream GPON IPTV subscribers ). We have BrixVision IPTV probes at the Sender PE router before the traffic enter our MPLS cloud and the same type of probes at Receiver PE routers. So far there is no need for IPTV probes along the RSVP-TE P2MP LSP path. This will help to determine the traffic quality in the IP/MPLS core. At the downstream we have STB probe aka Single Channel Probe from the same brand deployed at the customer's place if there is a picture quality complaint. This will help us to determine issue from receiver PE router through the GPON networks towards the customer home. We had evaluated Ineoquest before, however we found Brixvision was more suitable to our environment. In the early stage of deployment we kept our eye on the IAT and MLR on the probe almost everyday. The Brixvision has very detail real time zoomed-in analysis like TS Sync, PAT, CRC and etc per group. Hope this help. Regards Amos Thong -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of R S Sent: Wednesday, July 17, 2013 12:53 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] multicast issue Hi all Just a brainstorming and your possible help. I manage a network where multicast is the most important traffic and sometimes I get issue by customer where they state that some packets are lost... Does anybody have an idea or can help me in understanding a possible solution in monitoring traffic in real time manner, maybe with the use of some software or appliance or whatelse. In my idea I could monitor traffic on the source and on the destination, then with a sort of parsing understand if it's my network loosing the packets or not... Any idea ? suggestion ? tks ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ CONFIDENTIALITY - The contents of and any attachments to this email are private and confidential. If you are not the intended recipient or addressee indicated in this message, please notify the sender of the error and destroy the email and any attachments. Please do not reproduce the contents of the email or its attachments as such reproduction is a breach of confidentiality and for which legal action including injunctive relief may be sought against you. If it is your company policy that official communications are not by email, please advise immediately. Any opinions, conclusions and other information in this message that do not relate to the official business of TIME dotCom shall be understood as neither given nor endorsed by TIME dotCom, nor shall TIME dotCom shall be liable (directly or vicariously) for such opinions, statements or communications. CONFIDENTIALITY - The contents of and any attachments to this email are private and confidential. If you are not the intended recipient or addressee indicated in this message, please notify the sender of the error and destroy the email and any attachments. Please do not reproduce the contents of the email or its attachments as such reproduction is a breach of confidentiality and for which legal action including injunctive relief may be sought against you. If it is your company policy that official communications are not by email, please advise immediately. Any opinions, conclusions and other information in this message that do not relate to the official business of TIME dotCom
[c-nsp] multicast issue
Hi all Just a brainstorming and your possible help. I manage a network where multicast is the most important traffic and sometimes I get issue by customer where they state that some packets are lost… Does anybody have an idea or can help me in understanding a possible solution in monitoring traffic in real time manner, maybe with the use of some software or appliance or whatelse. In my idea I could monitor traffic on the source and on the destination, then with a sort of parsing understand if it’s my network loosing the packets or not… Any idea ? suggestion ? tks ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] multicast issue
We use IneoQuest gear to monitor multicast data after it leaves the source and before it enters the destination. The boxes give nice reports of both IP and MPEG, and are MDI compliant (RFC4445) Cheers, JF cisco-nsp cisco-nsp-boun...@puck.nether.net a écrit sur 2013-07-16 12:53:23 : De : R S dim0...@hotmail.com A : cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net, Date : 2013-07-16 12:59 Objet : [c-nsp] multicast issue Envoyé par : cisco-nsp cisco-nsp-boun...@puck.nether.net Hi all Just a brainstorming and your possible help. I manage a network where multicast is the most important traffic and sometimes I get issue by customer where they state that some packetsare lost… Does anybody have an idea or can help me in understanding a possible solution in monitoring traffic in real time manner, maybe with the use of some software or appliance or whatelse. In my idea I could monitor traffic on the source and on the destination, then with a sort of parsing understand if it’s my network loosing the packets or not… Any idea ? suggestion ? tks ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] multicast issue
Yep, same here. Lots of multicast video with IQ probes all over the place. I really like them. They've saved my neck many times during overnight maintenance. It's nice to know for sure what is happening around the network as you make your changes. On Tue, Jul 16, 2013 at 8:51 PM, jean-francois.d...@videotron.com wrote: We use IneoQuest gear to monitor multicast data after it leaves the source and before it enters the destination. The boxes give nice reports of both IP and MPEG, and are MDI compliant (RFC4445) Cheers, JF cisco-nsp cisco-nsp-boun...@puck.nether.net a écrit sur 2013-07-16 12:53:23 : De : R S dim0...@hotmail.com A : cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net, Date : 2013-07-16 12:59 Objet : [c-nsp] multicast issue Envoyé par : cisco-nsp cisco-nsp-boun...@puck.nether.net Hi all Just a brainstorming and your possible help. I manage a network where multicast is the most important traffic and sometimes I get issue by customer where they state that some packetsare lost… Does anybody have an idea or can help me in understanding a possible solution in monitoring traffic in real time manner, maybe with the use of some software or appliance or whatelse. In my idea I could monitor traffic on the source and on the destination, then with a sort of parsing understand if it’s my network loosing the packets or not… Any idea ? suggestion ? tks ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] multicast issue
I neoQuest is just for video applications. On Tue, Jul 16, 2013 at 9:12 PM, dim0sal dim0...@hotmail.com wrote: Hi all Thanks. But is this IQ used only for multicast video or also for other mcast applications like financial applications? Sorry but I don t know IneoQuest. Tks Sent with Mobile Messaggio originale Da: John Neiberger jneiber...@gmail.com Data: A: jean-francois.d...@videotron.com Cc: james lavespa dim0...@hotmail.com,cisco-nsp cisco-nsp-boun...@puck.nether.net,cisco-nsp@puck.nether.net Oggetto: Re: [c-nsp] multicast issue Yep, same here. Lots of multicast video with IQ probes all over the place. I really like them. They've saved my neck many times during overnight maintenance. It's nice to know for sure what is happening around the network as you make your changes. On Tue, Jul 16, 2013 at 8:51 PM, jean-francois.d...@videotron.com wrote: We use IneoQuest gear to monitor multicast data after it leaves the source and before it enters the destination. The boxes give nice reports of both IP and MPEG, and are MDI compliant (RFC4445) Cheers, JF cisco-nsp cisco-nsp-boun...@puck.nether.net a écrit sur 2013-07-16 12:53:23 : De : R S dim0...@hotmail.com A : cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net, Date : 2013-07-16 12:59 Objet : [c-nsp] multicast issue Envoyé par : cisco-nsp cisco-nsp-boun...@puck.nether.net Hi all Just a brainstorming and your possible help. I manage a network where multicast is the most important traffic and sometimes I get issue by customer where they state that some packetsare lost… Does anybody have an idea or can help me in understanding a possible solution in monitoring traffic in real time manner, maybe with the use of some software or appliance or whatelse. In my idea I could monitor traffic on the source and on the destination, then with a sort of parsing understand if it’s my network loosing the packets or not… Any idea ? suggestion ? tks ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Multicast Issue
After reading this thread it sounds like it could be DSLAM related. Our brand (OCCAM/Calix) has a few interesting gotchas along these lines. I take it you don't see the same behavior directly connected to the switch? Also this is a Cisco-oriented list, while some people are familiar with other vendors, other gear isn't exactly the group's expertise. Cheers - Ross -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mohammad Khalil Sent: Monday, June 04, 2012 6:17 PM To: danail.pet...@yahoo.com Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Multicast Issue Hi , I am using IGMP v2 Regarding the core switch , its non Cisco switch and i only configured IGMP quierer to server for the Vlan created for TVs (STBs) BR, Subject: Re: [c-nsp] Multicast Issue From: danail.pet...@yahoo.com Date: Mon, 4 Jun 2012 13:11:14 +0300 CC: td_mi...@yahoo.com; m...@mcadory.info; cisco-nsp@puck.nether.net To: eng_m...@hotmail.com Hi there, A few questions: 1. What IGMP version is used? 2. What kind is the platform - 65/76 and if so - what modules are used. If this is an IGMPv3 - there is a well known issue with it. I should search a little for that but S,G channels are not properly snooped by the switch, which results in broadcast manner you described. BR, Dani On Jun 4, 2012, at 12:14 PM, Mohammad Khalil wrote: Hi all , thanks for all replies Seemingly after i connected a laptop with wireshark , there seem a lot of broadcast which reach as well unused ports Bandwidth supposed to be 5M for each stream requested , so is it possibly CPE ? We have configured IGMP quierer on the Core Switch BR, Date: Sat, 2 Jun 2012 23:25:22 -0700 From: td_mi...@yahoo.com Subject: Re: [c-nsp] Multicast Issue To: eng_m...@hotmail.com; m...@mcadory.info CC: cisco-nsp@puck.nether.net Badly configured QoS perhaps ? What about limitation on how much of the link can be used for multicast ? Can you try adding incremental streams in smaller amounts to find at what point you have too much traffic ? Have you graphed the usage on the link to verify that the amount of bandwidth being used is indeed what you think it might be ? There are about 101 different reasons it could be performing badly, we're sort of just throwing suggestions out there. regards,Tony. From: Mohammad Khalil eng_m...@hotmail.com To: m...@mcadory.info Cc: cisco-nsp@puck.nether.net Sent: Sunday, 3 June 2012 3:22 PM Subject: Re: [c-nsp] Multicast Issue Hi , the issue seems not BW issue as according to the specifications , each TV is supposed to consume 5M So any ideas? BR, Mohammad Date: Wed, 30 May 2012 23:44:31 -0500 Subject: Re: [c-nsp] Multicast Issue From: m...@mcadory.info To: eng_m...@hotmail.com CC: cisco-nsp@puck.nether.net http://www.cardinalpeak.com/blog/?p=1054 is a good explanation of bit rate measurement process using WS. Use that to validate your expected 8Mbps stream rate. Also validate with your DSLAM operator that the 24Mbps you quote isn't total video and IPTV, but dedicated to video (or at least dedicated when video is flowing) to get your ~3 streams worth. Matt On Wed, May 30, 2012 at 1:29 AM, Mohammad Khalil eng_m...@hotmail.com wrote: The downstream is configured to be 24 M but the upstream is configured to be 4M this is the current setup , so it is for sure bandwidth issue ? From: mark.ti...@seacom.mu To: eng_m...@hotmail.com Subject: Re: [c-nsp] Multicast Issue Date: Wed, 30 May 2012 08:18:57 +0200 CC: cisco-nsp@puck.nether.net On Wednesday, May 30, 2012 08:14:20 AM Mohammad Khalil wrote: Actually its supposed for each stream to consume 8M should i try to increase the speed limits configured ? As this is VDSL, are you sure you're actually getting 24Mbps into the house? We tested IPTv on VDSL using new copper across 50m - it was a disaster. If you can, try increasing bandwidth and see if that helps. But it definitely sounds like when you request a 2nd stream and the picture develops block noise, you're starving the link of bandwidth. Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp
Re: [c-nsp] Multicast Issue
Hi all , thanks for all replies Seemingly after i connected a laptop with wireshark , there seem a lot of broadcast which reach as well unused ports Bandwidth supposed to be 5M for each stream requested , so is it possibly CPE ? We have configured IGMP quierer on the Core Switch BR, Date: Sat, 2 Jun 2012 23:25:22 -0700 From: td_mi...@yahoo.com Subject: Re: [c-nsp] Multicast Issue To: eng_m...@hotmail.com; m...@mcadory.info CC: cisco-nsp@puck.nether.net Badly configured QoS perhaps ? What about limitation on how much of the link can be used for multicast ? Can you try adding incremental streams in smaller amounts to find at what point you have too much traffic ? Have you graphed the usage on the link to verify that the amount of bandwidth being used is indeed what you think it might be ? There are about 101 different reasons it could be performing badly, we're sort of just throwing suggestions out there. regards,Tony. From: Mohammad Khalil eng_m...@hotmail.com To: m...@mcadory.info Cc: cisco-nsp@puck.nether.net Sent: Sunday, 3 June 2012 3:22 PM Subject: Re: [c-nsp] Multicast Issue Hi , the issue seems not BW issue as according to the specifications , each TV is supposed to consume 5M So any ideas? BR, Mohammad Date: Wed, 30 May 2012 23:44:31 -0500 Subject: Re: [c-nsp] Multicast Issue From: m...@mcadory.info To: eng_m...@hotmail.com CC: cisco-nsp@puck.nether.net http://www.cardinalpeak.com/blog/?p=1054 is a good explanation of bit rate measurement process using WS. Use that to validate your expected 8Mbps stream rate. Also validate with your DSLAM operator that the 24Mbps you quote isn't total video and IPTV, but dedicated to video (or at least dedicated when video is flowing) to get your ~3 streams worth. Matt On Wed, May 30, 2012 at 1:29 AM, Mohammad Khalil eng_m...@hotmail.com wrote: The downstream is configured to be 24 M but the upstream is configured to be 4M this is the current setup , so it is for sure bandwidth issue ? From: mark.ti...@seacom.mu To: eng_m...@hotmail.com Subject: Re: [c-nsp] Multicast Issue Date: Wed, 30 May 2012 08:18:57 +0200 CC: cisco-nsp@puck.nether.net On Wednesday, May 30, 2012 08:14:20 AM Mohammad Khalil wrote: Actually its supposed for each stream to consume 8M should i try to increase the speed limits configured ? As this is VDSL, are you sure you're actually getting 24Mbps into the house? We tested IPTv on VDSL using new copper across 50m - it was a disaster. If you can, try increasing bandwidth and see if that helps. But it definitely sounds like when you request a 2nd stream and the picture develops block noise, you're starving the link of bandwidth. Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Multicast Issue
Hi there, A few questions: 1. What IGMP version is used? 2. What kind is the platform - 65/76 and if so - what modules are used. If this is an IGMPv3 - there is a well known issue with it. I should search a little for that but S,G channels are not properly snooped by the switch, which results in broadcast manner you described. BR, Dani On Jun 4, 2012, at 12:14 PM, Mohammad Khalil wrote: Hi all , thanks for all replies Seemingly after i connected a laptop with wireshark , there seem a lot of broadcast which reach as well unused ports Bandwidth supposed to be 5M for each stream requested , so is it possibly CPE ? We have configured IGMP quierer on the Core Switch BR, Date: Sat, 2 Jun 2012 23:25:22 -0700 From: td_mi...@yahoo.com Subject: Re: [c-nsp] Multicast Issue To: eng_m...@hotmail.com; m...@mcadory.info CC: cisco-nsp@puck.nether.net Badly configured QoS perhaps ? What about limitation on how much of the link can be used for multicast ? Can you try adding incremental streams in smaller amounts to find at what point you have too much traffic ? Have you graphed the usage on the link to verify that the amount of bandwidth being used is indeed what you think it might be ? There are about 101 different reasons it could be performing badly, we're sort of just throwing suggestions out there. regards,Tony. From: Mohammad Khalil eng_m...@hotmail.com To: m...@mcadory.info Cc: cisco-nsp@puck.nether.net Sent: Sunday, 3 June 2012 3:22 PM Subject: Re: [c-nsp] Multicast Issue Hi , the issue seems not BW issue as according to the specifications , each TV is supposed to consume 5M So any ideas? BR, Mohammad Date: Wed, 30 May 2012 23:44:31 -0500 Subject: Re: [c-nsp] Multicast Issue From: m...@mcadory.info To: eng_m...@hotmail.com CC: cisco-nsp@puck.nether.net http://www.cardinalpeak.com/blog/?p=1054 is a good explanation of bit rate measurement process using WS. Use that to validate your expected 8Mbps stream rate. Also validate with your DSLAM operator that the 24Mbps you quote isn't total video and IPTV, but dedicated to video (or at least dedicated when video is flowing) to get your ~3 streams worth. Matt On Wed, May 30, 2012 at 1:29 AM, Mohammad Khalil eng_m...@hotmail.com wrote: The downstream is configured to be 24 M but the upstream is configured to be 4M this is the current setup , so it is for sure bandwidth issue ? From: mark.ti...@seacom.mu To: eng_m...@hotmail.com Subject: Re: [c-nsp] Multicast Issue Date: Wed, 30 May 2012 08:18:57 +0200 CC: cisco-nsp@puck.nether.net On Wednesday, May 30, 2012 08:14:20 AM Mohammad Khalil wrote: Actually its supposed for each stream to consume 8M should i try to increase the speed limits configured ? As this is VDSL, are you sure you're actually getting 24Mbps into the house? We tested IPTv on VDSL using new copper across 50m - it was a disaster. If you can, try increasing bandwidth and see if that helps. But it definitely sounds like when you request a 2nd stream and the picture develops block noise, you're starving the link of bandwidth. Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Multicast Issue
Hi , I am using IGMP v2 Regarding the core switch , its non Cisco switch and i only configured IGMP quierer to server for the Vlan created for TVs (STBs) BR, Subject: Re: [c-nsp] Multicast Issue From: danail.pet...@yahoo.com Date: Mon, 4 Jun 2012 13:11:14 +0300 CC: td_mi...@yahoo.com; m...@mcadory.info; cisco-nsp@puck.nether.net To: eng_m...@hotmail.com Hi there, A few questions: 1. What IGMP version is used? 2. What kind is the platform - 65/76 and if so - what modules are used. If this is an IGMPv3 - there is a well known issue with it. I should search a little for that but S,G channels are not properly snooped by the switch, which results in broadcast manner you described. BR, Dani On Jun 4, 2012, at 12:14 PM, Mohammad Khalil wrote: Hi all , thanks for all replies Seemingly after i connected a laptop with wireshark , there seem a lot of broadcast which reach as well unused ports Bandwidth supposed to be 5M for each stream requested , so is it possibly CPE ? We have configured IGMP quierer on the Core Switch BR, Date: Sat, 2 Jun 2012 23:25:22 -0700 From: td_mi...@yahoo.com Subject: Re: [c-nsp] Multicast Issue To: eng_m...@hotmail.com; m...@mcadory.info CC: cisco-nsp@puck.nether.net Badly configured QoS perhaps ? What about limitation on how much of the link can be used for multicast ? Can you try adding incremental streams in smaller amounts to find at what point you have too much traffic ? Have you graphed the usage on the link to verify that the amount of bandwidth being used is indeed what you think it might be ? There are about 101 different reasons it could be performing badly, we're sort of just throwing suggestions out there. regards,Tony. From: Mohammad Khalil eng_m...@hotmail.com To: m...@mcadory.info Cc: cisco-nsp@puck.nether.net Sent: Sunday, 3 June 2012 3:22 PM Subject: Re: [c-nsp] Multicast Issue Hi , the issue seems not BW issue as according to the specifications , each TV is supposed to consume 5M So any ideas? BR, Mohammad Date: Wed, 30 May 2012 23:44:31 -0500 Subject: Re: [c-nsp] Multicast Issue From: m...@mcadory.info To: eng_m...@hotmail.com CC: cisco-nsp@puck.nether.net http://www.cardinalpeak.com/blog/?p=1054 is a good explanation of bit rate measurement process using WS. Use that to validate your expected 8Mbps stream rate. Also validate with your DSLAM operator that the 24Mbps you quote isn't total video and IPTV, but dedicated to video (or at least dedicated when video is flowing) to get your ~3 streams worth. Matt On Wed, May 30, 2012 at 1:29 AM, Mohammad Khalil eng_m...@hotmail.com wrote: The downstream is configured to be 24 M but the upstream is configured to be 4M this is the current setup , so it is for sure bandwidth issue ? From: mark.ti...@seacom.mu To: eng_m...@hotmail.com Subject: Re: [c-nsp] Multicast Issue Date: Wed, 30 May 2012 08:18:57 +0200 CC: cisco-nsp@puck.nether.net On Wednesday, May 30, 2012 08:14:20 AM Mohammad Khalil wrote: Actually its supposed for each stream to consume 8M should i try to increase the speed limits configured ? As this is VDSL, are you sure you're actually getting 24Mbps into the house? We tested IPTv on VDSL using new copper across 50m - it was a disaster. If you can, try increasing bandwidth and see if that helps. But it definitely sounds like when you request a 2nd stream and the picture develops block noise, you're starving the link of bandwidth. Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Multicast Issue
On Sunday, June 03, 2012 08:25:22 AM Tony wrote: There are about 101 different reasons it could be performing badly, we're sort of just throwing suggestions out there. Agree - it still points toward a bandwidth issue, Mohammad. The picture is fine with only one stream, but goes noisy when add a second one. Check to make sure: a) How much bandwidth you can actually squeeze through the link, Unicast and Multicast. b) What you're being told you have is what you actually have. c) If there is QoS enabled in the case that the link is carrying non-Multicast traffic also. Another exercise for you would be to try and watch the same channel on another Tv off the same switch. This is to make sure that Multicast is actually work, and that a second copy of the same stream isn't being created on the same switch that holds the (S,G) for the original stream. Again, 101 things possibly going on here, but without any more concrete information, we're shooting in the dark. Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Multicast Issue
You may be running out of bandwidth (or other resources) in the point where your traffic is being replicated. Diogo On 6/3/12, Tony td_mi...@yahoo.com wrote: Badly configured QoS perhaps ? What about limitation on how much of the link can be used for multicast ? Can you try adding incremental streams in smaller amounts to find at what point you have too much traffic ? Have you graphed the usage on the link to verify that the amount of bandwidth being used is indeed what you think it might be ? There are about 101 different reasons it could be performing badly, we're sort of just throwing suggestions out there. regards, Tony. From: Mohammad Khalil eng_m...@hotmail.com To: m...@mcadory.info Cc: cisco-nsp@puck.nether.net Sent: Sunday, 3 June 2012 3:22 PM Subject: Re: [c-nsp] Multicast Issue Hi , the issue seems not BW issue as according to the specifications , each TV is supposed to consume 5M So any ideas? BR, Mohammad Date: Wed, 30 May 2012 23:44:31 -0500 Subject: Re: [c-nsp] Multicast Issue From: m...@mcadory.info To: eng_m...@hotmail.com CC: cisco-nsp@puck.nether.net http://www.cardinalpeak.com/blog/?p=1054 is a good explanation of bit rate measurement process using WS. Use that to validate your expected 8Mbps stream rate. Also validate with your DSLAM operator that the 24Mbps you quote isn't total video and IPTV, but dedicated to video (or at least dedicated when video is flowing) to get your ~3 streams worth. Matt On Wed, May 30, 2012 at 1:29 AM, Mohammad Khalil eng_m...@hotmail.com wrote: The downstream is configured to be 24 M but the upstream is configured to be 4M this is the current setup , so it is for sure bandwidth issue ? From: mark.ti...@seacom.mu To: eng_m...@hotmail.com Subject: Re: [c-nsp] Multicast Issue Date: Wed, 30 May 2012 08:18:57 +0200 CC: cisco-nsp@puck.nether.net On Wednesday, May 30, 2012 08:14:20 AM Mohammad Khalil wrote: Actually its supposed for each stream to consume 8M should i try to increase the speed limits configured ? As this is VDSL, are you sure you're actually getting 24Mbps into the house? We tested IPTv on VDSL using new copper across 50m - it was a disaster. If you can, try increasing bandwidth and see if that helps. But it definitely sounds like when you request a 2nd stream and the picture develops block noise, you're starving the link of bandwidth. Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Sent from my mobile device ./diogo -montagner JNCIE-M 0x41A ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Multicast Issue
Hi , the issue seems not BW issue as according to the specifications , each TV is supposed to consume 5M So any ideas? BR, Mohammad Date: Wed, 30 May 2012 23:44:31 -0500 Subject: Re: [c-nsp] Multicast Issue From: m...@mcadory.info To: eng_m...@hotmail.com CC: cisco-nsp@puck.nether.net http://www.cardinalpeak.com/blog/?p=1054 is a good explanation of bit rate measurement process using WS. Use that to validate your expected 8Mbps stream rate. Also validate with your DSLAM operator that the 24Mbps you quote isn't total video and IPTV, but dedicated to video (or at least dedicated when video is flowing) to get your ~3 streams worth. Matt On Wed, May 30, 2012 at 1:29 AM, Mohammad Khalil eng_m...@hotmail.com wrote: The downstream is configured to be 24 M but the upstream is configured to be 4M this is the current setup , so it is for sure bandwidth issue ? From: mark.ti...@seacom.mu To: eng_m...@hotmail.com Subject: Re: [c-nsp] Multicast Issue Date: Wed, 30 May 2012 08:18:57 +0200 CC: cisco-nsp@puck.nether.net On Wednesday, May 30, 2012 08:14:20 AM Mohammad Khalil wrote: Actually its supposed for each stream to consume 8M should i try to increase the speed limits configured ? As this is VDSL, are you sure you're actually getting 24Mbps into the house? We tested IPTv on VDSL using new copper across 50m - it was a disaster. If you can, try increasing bandwidth and see if that helps. But it definitely sounds like when you request a 2nd stream and the picture develops block noise, you're starving the link of bandwidth. Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Multicast Issue
Actually its supposed for each stream to consume 8M should i try to increase the speed limits configured ? From: mark.ti...@seacom.mu To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Multicast Issue Date: Wed, 30 May 2012 07:25:01 +0200 CC: eng_m...@hotmail.com On Wednesday, May 30, 2012 07:15:28 AM Mohammad Khalil wrote: Hi all , i have CPE that terminates VDSL connection with a downstream of 24M The CPE receives Multicast streams to serve two televisions The network is all layer 2 connections When serving one television , all is working good but when two are in service the picture is stuck as if the multicast traffic is stopped or something Any ideas? Sounds like you're asking too much from the link. How much bandwidth does a single stream consume? Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Multicast Issue
On Wednesday, May 30, 2012 08:14:20 AM Mohammad Khalil wrote: Actually its supposed for each stream to consume 8M should i try to increase the speed limits configured ? As this is VDSL, are you sure you're actually getting 24Mbps into the house? We tested IPTv on VDSL using new copper across 50m - it was a disaster. If you can, try increasing bandwidth and see if that helps. But it definitely sounds like when you request a 2nd stream and the picture develops block noise, you're starving the link of bandwidth. Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Multicast Issue
The downstream is configured to be 24 M but the upstream is configured to be 4M this is the current setup , so it is for sure bandwidth issue ? From: mark.ti...@seacom.mu To: eng_m...@hotmail.com Subject: Re: [c-nsp] Multicast Issue Date: Wed, 30 May 2012 08:18:57 +0200 CC: cisco-nsp@puck.nether.net On Wednesday, May 30, 2012 08:14:20 AM Mohammad Khalil wrote: Actually its supposed for each stream to consume 8M should i try to increase the speed limits configured ? As this is VDSL, are you sure you're actually getting 24Mbps into the house? We tested IPTv on VDSL using new copper across 50m - it was a disaster. If you can, try increasing bandwidth and see if that helps. But it definitely sounds like when you request a 2nd stream and the picture develops block noise, you're starving the link of bandwidth. Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Multicast Issue
On Wednesday, May 30, 2012 08:29:13 AM Mohammad Khalil wrote: The downstream is configured to be 24 M but the upstream is configured to be 4M this is the current setup , so it is for sure bandwidth issue ? Your IPTv traffic will flow downstream, from the Receiver PE router. So the 4Mbps upstream traffic won't have any bearing, as IGMP Join messages (which travel upstream) are low bandwidth anyway. The real question is, even though you've configured for 24Mbps downstream, can you actually get that? Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Multicast Issue
http://www.cardinalpeak.com/blog/?p=1054 is a good explanation of bit rate measurement process using WS. Use that to validate your expected 8Mbps stream rate. Also validate with your DSLAM operator that the 24Mbps you quote isn't total video and IPTV, but dedicated to video (or at least dedicated when video is flowing) to get your ~3 streams worth. Matt On Wed, May 30, 2012 at 1:29 AM, Mohammad Khalil eng_m...@hotmail.com wrote: The downstream is configured to be 24 M but the upstream is configured to be 4M this is the current setup , so it is for sure bandwidth issue ? From: mark.ti...@seacom.mu To: eng_m...@hotmail.com Subject: Re: [c-nsp] Multicast Issue Date: Wed, 30 May 2012 08:18:57 +0200 CC: cisco-nsp@puck.nether.net On Wednesday, May 30, 2012 08:14:20 AM Mohammad Khalil wrote: Actually its supposed for each stream to consume 8M should i try to increase the speed limits configured ? As this is VDSL, are you sure you're actually getting 24Mbps into the house? We tested IPTv on VDSL using new copper across 50m - it was a disaster. If you can, try increasing bandwidth and see if that helps. But it definitely sounds like when you request a 2nd stream and the picture develops block noise, you're starving the link of bandwidth. Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Multicast Issue
Hi all , i have CPE that terminates VDSL connection with a downstream of 24M The CPE receives Multicast streams to serve two televisions The network is all layer 2 connections When serving one television , all is working good but when two are in service the picture is stuck as if the multicast traffic is stopped or something Any ideas? Thanks ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Multicast Issue
On Wednesday, May 30, 2012 07:15:28 AM Mohammad Khalil wrote: Hi all , i have CPE that terminates VDSL connection with a downstream of 24M The CPE receives Multicast streams to serve two televisions The network is all layer 2 connections When serving one television , all is working good but when two are in service the picture is stuck as if the multicast traffic is stopped or something Any ideas? Sounds like you're asking too much from the link. How much bandwidth does a single stream consume? Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Multicast issue
Hitesh Vinzoda a écrit : Hi all, Hi Hitesh I had configured multicast in my lan using sparse-dense mode. RP and group is defined statically on each L3 switches. I'm receiving the multicast beyond all L3's except ones running HSRP. Any ideas guyz http://www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a0080094aab.shtml Regards, -- Francois http://blog.packetfault.org ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Multicast issue
Hi all, I had configured multicast in my lan using sparse-dense mode. RP and group is defined statically on each L3 switches. I'm receiving the multicast beyond all L3's except ones running HSRP. Any ideas guyz Regards Hitesh Vinzoda ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
