perfsonar-dev - Re: Multicast troblshooting
Subject: perfsonar development work
List archive
- From: Stig Venaas <>
- To: Nicolas Simar <>
- Cc: "" <>, GN-JRA1-list <>
- Subject: Re: Multicast troblshooting
- Date: Tue, 22 Jan 2008 01:38:11 +0100
Nicolas Simar wrote:
> Hi Stig,
>
> just to mention you that few days ago, I met people from Renater and from
> the French regional network. They mentioned that they are interested by
> a monitoring tool that allow them to identify where a multicast problem
> is located.
>
> They had an issue between them and an Asian network. A multicast UDP
> transfer which was experiencing packet loss. The Asian network NOC was
> troubleshooting the problem with ICMPs and was identifying a certain
> amount of packet loss within the Regional network. The regional network
> wasn't seeing any packet loss locally and identify TEIN2 diagnoses as
> rather being an accumulation of packet loss over GEANT2-Renater.
Such problems are far too common and one of the reasons I started
working on this.
>
> There was no tool available to clearly identify where the problem was
> located (on which section of the network) and no way of exchanging that
> information between network in a trusted and meaningful way (both
> parties understanding the test done).
>
> I believe that what you describe as
> "Another possibility is that the join path is in place, but that the
> data is not forwarded all the way to the receiver. This is also
> something that would be checked thruogh the MP multicast service. If
> receiver receives some data but not all, the tool could also tell where
> packets are being dropped along the path. "
> would allow to identify the location(s) where the packets are being
> dropped. Would it be at an AS level or at a router level that those
> detection would occur?
By checking counters on each router along the path this can be detected
at the router level (you can check the number of packets forwarded by
each router). At least technically this can be done per router. However,
this could perhaps be per AS if someone thinks this reveals too much
detail.
I've however found that it's not easy to detect small amounts of packet
loss since it varies a lot how often the routers update the SNMP
counters. One could possibly use other methods than SNMP to check the
number of packets forwarded per node of the multicast tree.
Stig
>
> Cheers,
- Multicast troblshooting, Nicolas Simar, 01/14/2008
- Re: Multicast troblshooting, Stig Venaas, 01/21/2008
Archive powered by MHonArc 2.6.16.