Ping loss door IPTV streamer. Bytes missing.

[_ferry_]

Op een netwerk waar ik aan het troubleshooten ben hangt een IPTV streamer, deze maakt een paar multicast streams aan van de aangeboden input (bijvoorbeeld in VLC te bekijken met udp://@239.x.x.x:1234 )

Nu spelen er wat vreemde zaken op dat netwerk, zoals apparaten die een DHCP request doen, vervolgens geen IP krijgen (al lijkt de server ze wel uit te delen), daarop doen ze een nieuwe request etc.
Nu merk ik ook dat de ping vanaf mijn PC naar de switch een hoge latency heeft en zelfs time outs.

Zodra ik de streamer er uit trekt lijken al die problemen te verdwijnen als sneeuw voor de zon. De seconde dat hij weer draait gaat het mis.
Als ik op deze interface van de switch (Juniper EX2300) monitor krijg ik meerdere keren per seconde dit soort meldingen:

12:32:35.481604 In IP truncated-ip - 1288 bytes missing! 10.0.0.x.53156 > 239.239.x.x.1234: UDP, length 1316

Nu zoek ik wat op dat soort meldingen, en lees ik dat het wel vaker kan voorkomen omdat het UDP verkeer betreft, en de stream in meerdere pakketjes zit. Klopt dat, en kan ik deze melding dus negeren. Of is deze hoge frequentie echt niet goed en moet ik het dus in die streamer zoeken?
Streamer losgekoppeld = snel netwerk/goeie ping, dus ik moet het sowieso wel daar in zoeken, maar ik wil even bevestigen dat deze melding een duiding is van het probleem.

[MAX3400]

Je haalt volgens mij 2 dingen door elkaar; de melding die je krijgt in je EX2300, is een melding dat het betreffende packet niet in je capture-buffer past. Dat heeft dus niets/weinig te maken met het issue wat je ervaart qua latency/ping. Volgens mij kan je in je monitoring/commandline de packet-buffer vergroten zodat elk packet (dus bijvoorbeeld ook een malformed jumbo-frame) wel opgepikt kan worden.

Dan even je DHCP-requests; je zegt dat de server ze wel lijkt uit te delen maar hoe weet je dat? Wordt er een reservation gemaakt op de server? Of zie je wel "DHCP traffic" van server naar switch maar nooit meer van switch naar client?

Andersom troubleshooting; is het makkelijk om de stream eens op unicast om te zetten als test? Ondanks dat het protocol niet verandert, is er wel een mogelijkheid dat de hoeveelheid data verkleint. Mogelijk dat je dan verder kan deduceren of dit switchport-related is of anderszins?

[_ferry_]

Okee, ik heb trouwens wel duidelijke pingloss naar de switch toe, vanaf mijn pc. Echter, van pc naar andere pc gaat allemaal prima. Terwijl die dus via die switch gaan. Erg vaag als je het mij vraagt
Qua framesize heb ik weinig kaas gegeten. De switches veel gebruikt met andere type streamer en daar heb ik nooit dit soort issues gehad (Wel zat andere dingen, mensen die kabeltjes gaan wisselen, routers toevoegen/lostrekken etc.)

De DHCP requests, ik beheer de server zelf niet, maar zag dat de server meerdere keren een reservering doet voor dezelfde cliënt. En cliënt dan vaak geen IP krijgt. Veel verder dan dat ben ik er niet in gedoken, omdat er dus wat vreemde zaken op het netwerk spelen.
De multicast omzetten maar multicast ondersteunt hij helaas niet.

[Verwijderd]

Ik ken die EX2300 niet, maar als de ping op de CPU afgehandeld moet worden is dat een stuk langzamer dan als de ASICs het zelf kunnen. En als die CPU vindt dat'ie betere dingen te doen heeft dan zie je packet loss. Dit kom je ook wel tegen op "high end" router hardware. Dus kijk maar liever wat je allemaal kan pingen vanaf de ene peecee en vanaf de andere peecee, wat je nog meer aan debuginfo kan vinden, en wat voor plaatje daaruit ontstaat. Ik verwacht van zo'n apparaat (managed switch, bekend merk) een heleboel debugging en logging opties die moeten kunnen vertellen wat er aan de hand is. Je kan wellicht ook zelf DHCP-aanvragen doen en tegelijkertijd met tcpdump oid kijken wat je terugkrijgt.

[LiquidSmoke]

udp, multicast, heb je hier niet een IGMP probleem?

Als ik het goed heb ondersteund de EX2300 IGMP snooping, staat dit aan?