Docker, rtp, ICMP port unreachable

Fórumok

Pronlema:

 

Fujitsu szerver, RHEL 7.7 rajta, illetve Docker par containerrel (MACVLAN).

Kulso esztkoz SIP kommunikaciot csinal, kuldi az RTP csomagokat az egyik Docker contenernek, majd kihuzzuk az egyik PSU-t a szerverbol es a kommunikacio megszakad nehany ezredmasodpercre ezzel:

ICMP   "destination unreachable (Port unreachable)"  --- ezt a kontener kuldi vissza  a kulso eszkoznek

Azaz mintha a containerben megszunne/eltunne a UDP port par miliszekundumra, vagy tulzottan besokallna, azaz nem tudna fogadni a bejovo RTP csomagokat.

Es mindez akkor csak HA KIHUZZUK AZ EGYIK PSU-t !! Azaz valami triggerelodik...

 

Otlet?

Valaki tapasztalt hasonlot?

Esetleg mit tennetek a debugban?

 

(az is erdekes, hogy utana folytatodik a kommunikacio, szoval recoverelodik a cucc! - de sajnos ez a keves ido eleg ahhoz, hogy par cucc atallitodjon a rendszerben negativ iranyban)

Hozzászólások

Szerkesztve: 2021. 04. 07., sze – 18:49

Egyaltalan az is a kerdes, hogy melyik layer kuldi ki ezeket az ICMP csomagokat, ha latja, hogy beerkeznek RTP (UDP) csomagok, de nincs aki fogadja oket?

A RHEL network stack? A Docker network stack? Vagy az applikacio (framework - >Java) maga?

akkor is fennáll a jelenség, ha a PSU-ból húzod ki a delejt?

Szerkesztve: 2021. 04. 07., sze – 21:45

Kontakthibás a hálózati kábel :-D

Mikor a PSU-k közöttt váltás van akármennyi időre is de van kiesés én ezt normálisnak gondolnám. Alapból azok nem dolgoznak csak ha kell és a switch akármennyi mp-t is vagy század másodpercet időbe vesz. Én fentebb venném az icmp csomagok küldésének idejét, asszem azt is lehet megadni hogy milyen sűrűn küldje és kérjen visszajelzést. 

én biztos kipróbálnám hogy a host oprendszerből tolnám az icmp-t és ha ott is van szakadás akkor nem a docker és hasonló layerekben kell keresni a hibát.

elég messzire vezethet ez a dolog, így tippre alaplap tervezési problémára is tippelhetek akár, lehet meg kéne keresni a fujitsu supportot.

Gábriel Ákos

"de sajnos ez a keves ido eleg ahhoz, hogy par cucc atallitodjon a rendszerben negativ iranyban"
Pedig azert na, RTP meg SIP eseten a csomagvesztes az eg elegge alap dolog, nem is ertem, hogy erre miert nem vagytok szoftverben felkeszulve. Ezek a protokollok direkt ugy vannak kitalalva, hogy alatta total instabil lehet a halozat.

Ugy tunik, az app bezarja a portot milisecundumokra, ez okozza a gondot. Nem az ICMP packetek.

Mit javasolnatok milisecundumos port bezaras tesztelesere?

Egy konténerizált, microservice környezetben ez megintcsak nem kellene, hogy gondot okozzon. Konténerek jönnek-mennek, erre megfelelő resiliency patternekkel kell felkészülni. 
Nem azt kell tesztelned, hogy pár ezredmásodpercig zárvaa port, hanem azt, hogy a rendszer többi része hogy kezeli le azt, hoyg akár egy, három, öt másodpercig vagy óráig zárva a port, és hogyan veszi észre, hogy újra lehet kapcsolódni? Úgy látom, nálatok semmi resiliency nincsen kiépítve.

Szóval nem a pár ezredmásodperc a lényeg, hanem az, hogy a rendszer többi része számára ez miért ennyire fontos, és miért nem tudnak kijönni ebből az állapotból? Hiszen ezek szerint ha egyáltalán leállás van valahol, akkor azt sem tudják kezelni.

Azt hiszed en ezt nem tudom? ha egy kicsit belelatsz egy nagy ceg design es fejlesztesi sebessegebe, ez nem ugy megy, hogy szolok a fejlesztonek, hogy a sz.r applikaciod miert nem kezeli le ezt, meg azt. Ugyanis ennek az atfutasi ideje hetek, amire ezt befejleszti.

Itt az van, hogy jon egy hiba, a mar "eladott" rendszeren,  amit persze nem vettek eszre a tesztek alatt, mert az masik hardveren futott! nagy okosok! Azt hittek, hogy a Docker az mindenhato, majd megeszi ezt is. Hat nem.

A fejleszto azt mondja, hogy nem kap CPU-t a process, emiatt eldobja a kapcsolatokat. Az mar nem biztos, hogy erdekli, hogy deritem ki, miert nem kap CPU-t?

En azt mondom, a port bezarodik, de ezt bizonyitanom kell. Nincs mese. strace szoba johet, de ettol nem vagyok tulzotan feldobva... 

A leallast tudjak kezelni, iivel a SIP onmagaban ilyen, de ebben az esetben a par milisecundum is eszrevevodik, es ez a baj...