Narzędzia do testowania routingu multiemisji [zamknięte]

Szukam dobrego, prostego narzędzia, które działa na standardowym systemie operacyjnym (Windows lub Linux), którego mogę użyć do przetestowania prawidłowego przekazywania multiemisji przez router.

Klient został poproszony o włączenie routingu multiemisji na urządzeniu Linux działającym jako router, ponieważ ich system telefoniczny wymaga multiemisji do kilku funkcji. Ponieważ nie jestem fizycznie blisko klienta, tak naprawdę nie mam możliwości eksperymentowania z różnymi metodami konfiguracji routingu multiemisji w systemie Linux. Mogę skonfigurować router przy biurku, który jest identyczny z tym, który jest wdrożony w ich sieci, ale nie znam żadnych dobrych prostych narzędzi, których można użyć do generowania lub nasłuchiwania ruchu multiemisji.

Jednym narzędziem, które znalazłem, jest narzędzie mcast.exe, które jest częścią zestawu zasobów Windows 2000/2003. Z tego, co przeczytałem online, wydaje się, że mcast.exe nie działa na routerze i działa tylko w sieci lokalnej, więc nie wydaje mi się to przydatne do testowania routingu multiemisji.

Więc jakich narzędzi używasz do testowania poprawności konfiguracji routingu multiemisji?

Nie masz zbyt wiele rzeczywistych wrażeń multiemisji, ale widziałeś mz?

Description: versatile packet creation and network traffic generation tool
 mausezahn (mz) is a fast traffic generator written in C which allows you to
 send nearly every possible and impossible packet. It is mainly used to test
 VoIP or multicast networks but also for security audits to check whether
 your systems are hardened enough for specific attacks.
 Mausezahn can be used for example:
 .
  * as traffic generator (e.g. to stress multicast networks);
  * to precisely measure jitter (delay variations) between two hosts
    (e.g. for VoIP-SLA verification);
  * as didactical tool during a datacom lecture or for lab exercises;
  * for penetration testing of firewalls and IDS;
  * for DoS attacks on networks (for audit purposes of course);
  * to find bugs in network software or appliances;
  * for reconnaissance attacks using ping sweeps and port scans;
  * to test network behaviour under strange circumstances (stress test,
    malformed packets, ...).
Homepage: http://www.perihel.at/sec/mz/

Istnieją również ssmping:

Description: check your multicast connectivity
 Tools to check whether you can receive Source Specific Multicast (SSM)
 or Any Source Multicast (ASM) via either IPv4 or IPv6
 .
 If a host runs ssmpingd, users on other hosts can use the ssmping client
 to test whether they can receive SSM from the host. Another program
 called asmping is also provided to check whether can receive ASM.
Homepage: http://www.venaas.no/multicast/ssmping/

Oba można zainstalować na Ubuntu 10.10. Powodzenia!

iperf jest do tego idealny i jest łatwo dostępny dla większości dystrybucji Linuksa i Windows.

Po stronie słuchacza:

% iperf -s -u -B 224.1.1.1 -i 1
------------------------------------------------------------
Server listening on UDP port 5001
Binding to local address 224.1.1.1
Joining multicast group  224.1.1.1
Receiving 1470 byte datagrams
UDP buffer size:  110 KByte (default)
------------------------------------------------------------

... i będzie czekać na odpowiedź ze źródła. W źródle rozpocznij wysyłanie:

% iperf -c 224.1.1.1 -u -T 32 -t 3 -i 1
------------------------------------------------------------
Client connecting to 224.1.1.1, UDP port 5001
Sending 1470 byte datagrams
Setting multicast TTL to 32
UDP buffer size:  110 KByte (default)
------------------------------------------------------------
[  3] local 192.168.220.20 port 59347 connected with 224.1.1.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec   129 KBytes  1.06 Mbits/sec
[  3]  1.0- 2.0 sec   128 KBytes  1.05 Mbits/sec
[  3]  2.0- 3.0 sec   128 KBytes  1.05 Mbits/sec
[  3]  0.0- 3.0 sec   386 KBytes  1.05 Mbits/sec
[  3] Sent 269 datagrams

w tym samym czasie zobaczysz, że słuchacz otrzymuje ruch:

...
[  3] local 224.1.1.1 port 5001 connected with 192.168.220.20 port 59347
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0- 1.0 sec   128 KBytes  1.05 Mbits/sec   0.035 ms    0/   89 (0%)
[  3]  1.0- 2.0 sec   128 KBytes  1.05 Mbits/sec   0.015 ms    0/   89 (0%)
[  3]  2.0- 3.0 sec   128 KBytes  1.05 Mbits/sec   0.025 ms    0/   89 (0%)
[  3]  0.0- 3.0 sec   386 KBytes  1.05 Mbits/sec   0.068 ms    0/  269 (0%)

Określając -T 32opcję nadawcy, ustawiasz TTL na 32, co zapewni routing ruchu (przy założeniu, że IGMP, PIM i inne elementy na routerach są odpowiednio skonfigurowane)

BTW, kiedy po raz ostatni próbowałem użyć VLC w tym scenariuszu, natknąłem się na problem, w którym VLC zignorowałoby ustawienie TTL i zawsze transmitowało pakiety z TTL ustawionym na 1. Przeczytaj raport o błędzie, aby obejść to obejście.

To może, ale nie musi być pomocne, ale w przeszłości używałem VLC (wszystkich rzeczy) jako źródła wideo multiemisji. Jednak w moich przypadkach strumienie multiemisji nigdy nie musiały wychodzić poza domenę L2, więc nie mogę powiedzieć, czy generowany przez niego ruch byłby „właściwą” routowalną multiemisją.

mcast to narzędzie, którego używamy, aby sprawdzić, czy multiemisja jest dozwolona przez nasz router lokalny. Domyślnie powinno być wyłączone.

Nie chcesz, aby pakiety multiemisji odrywały się od zatykania sieci tam, gdzie nie są potrzebne.

Możesz także wypróbować te aplikacje: VIC i RAT, aplikacja do multiemisji, która była opracowywana dla MBONE, dostępna dla Windows XP i UNIX. Obsługuje także multiemisję IPv4 i IPv6. Możesz je zobaczyć na stronie http://mediatools.cs.ucl.ac.uk/nets/mmedia/