Dotaz: Permanentní test linky

[kolemjdouci]

Zdravím pánové a dámy sháním nástroj na test stability linky mezi dvěma stroji. Občas vypadne služba a ja nevím proč. Použití ping není to pravé. Potřebuju něco co naváže spojení a v něm bude třeba posílat noop a udržovat spojení a když spadne zaloguje to.

---

---

Odpovědi

[Georgo10]

netcat a while cyklus v bashi

[NN]

Použití ping není to pravé.

Ptoc? Rekl bych ze zrovna ICMP a jeho latence/vypadky jsou idealni na testovani kvality linky.

[Jendа]

Pokud je cestou nějaký NAT nebo stavový firewall, ICMP může projít, ale TCP spojení se může po čase samovolně rozpadnout.

[kolemjdouci]

Ne ICMP neni to prave. Mel jsem zapnuty tyden ping a nezjistil jsem nic. Podle nej nulova stratovost vsechno jede. Na portu nejsou zadne errory, ale pritom se generuje obcas nejaka chyba na lince. Stroje jsou v jedne siti propojeny pres jeden MK RB493G. Bohuzel jde o sluzbu, kde se neustale provadi vymena dat a takove kratkodobe vypadky pak zpusoby jeji pad na cca 30 vterin az 5 minut nez se spojeni opet navaze. Nejde zmenit v konfiguraci na kratsi obnovu spojeni.

[trubicoid2]

ten ping paket je defualtne moc malej a nic nezjisti, zkus zvetsit paket a taky je muzes posilat rychleji, treba se tim neco zjisti

ping -s # -i # defaulne je -s 56 a -i 1

[Filip Jirsák]

Použít větší velikost paketů je první krok, který odhalí případné problémy s fyzickou linkou. Pokud to nepomůže, je potřeba zjistit, co přesně je to za spojení a co vede k jeho ukončování. Např. pokud by ta sonda byla klasické TCP/IP spojení, tak s její pomocí výpadek jednoho paketu neodhalíte, protože se TCP postará o jeho opakovaný přenos. Takže jde o to, zda to rozpadající se spojení je také TCP/IP nebo něco jiného, jestli se opravdu rozpadne nebo jestli je z jedné strany resetováno…

[2017]

>> Ptoc? Rekl bych ze zrovna ICMP a jeho latence/vypadky jsou idealni na testovani kvality linky.

Ping pomoci ICMP nebezi pres TCP. Spojeni pres TCP je uplne jiny svet a to i prestoze samo muze vyuzivat ICMP zpravy.

Nize nekdo radi netcat a to muzu jen doporucit, jen se to musi orchestrovat na obou koncich a to muze byt oproti Ping nekde nevyhoda.

[Filip Jirsák]

Ping pomoci ICMP nebezi pres TCP. Spojeni pres TCP je uplne jiny svet a to i prestoze samo muze vyuzivat ICMP zpravy.

Z pohledu linky je úplně jedno, jestli je to TCP nebo ICMP. Prostě se přenášejí například ethernetové rámce. Pro otestování linky může být důležitá maximálně velikost paketu případně jejich množství.

TCP je úplně jiný svět, ale až na vyšších úrovních. A dotaz byl na testování linky, ne na testování spojení.

[OldFrog {Ondra Nemecek}]

TCP je úplně jiný svět, ale až na vyšších úrovních. A dotaz byl na testování linky, ne na testování spojení.

Podle formulace dotazu mi to naopak přijde spíš jako dotaz na testování spojení:

Potřebuju něco co naváže spojení a v něm bude třeba posílat noop a udržovat spojení a když spadne zaloguje to.

Ideální by asi bylo testovat oboje, aby byla vidět případná souvislost.

BTW by se mi hodilo něco podobného, nejlépe už připraveného s nějakým grafickým výstupem, ale zase nepotřebuju kanón na vrabce - chci otestovat stabilitu dvou tří linek (první, druhý třetí hop a internet) jako podklad pro poskytovatele připojení případně jako argument pro zřízení jiné linky. Že by to měřilo odezvu a ztrátovost a hodilo do grafu. Ideální by bylo, aby to šlo případně spustit i na nějakém RPI. Našel jsem tunu řešení, co byste doporučili? Nechce se mi instalovat komplexní monitorovací nástroj...

[NN]

Jestli se rozpada TCP session, tak at to loguje tcpdumpem a muze si prochazet celou komunikaci podle libosti. Polootevrene seession a podobny vylomeniny pomuzou jak?

[vencour]

Mám za to, že síťové prvky po cestě se snaží projevovat svou inteligenci, tj. i napravovat (nebo přidávat) nějaké chyby po cestě. Pokud byste pingal v tunelu, dejme tomu šifrovaném gre, tak byste mohl něco zjistit.
Tj. nikdo by neměl po cestě nic modifikovat. A na druhou stranu pokud jsou ty potíže nahodilé, není zaručeno, že tento pokus něco vyvrátí.

[bla.bla]

obycajne SSH? a v cykle log do suboru vramci ssh session.

Pokud je to ssh, tak je enkapsulováno do tcp, tak to aplikační proxy firewallů zpravidla dokáže opakovaně přenášet při chybě, "kecat do chyb linky".

[jiwopene]

Použít se dá trvalé TCP spojení (kde se něco pořád posílá):

Klient (počítač který testuje a tvoří log)

# Zpráva k posílání
ZPRAVA=noop

# Interval odesílání
INTERVAL=.3 # 300 milisekund

# IP adresa a port k testování
HOST=127.0.0.1
PORT=1234

# Příkaz spuštěný při chybě (vložený *jako text*)
# Pozn.: V případě delší nedostupnosti je spouštěn pravidelně (po každém selhání)
LOG='date'

# Příkaz pro testvání (klient -- testující počítač)
while true; do while true; do echo "$ZPRAVA"; sleep $INTERVAL; done | nc $HOST $PORT > /dev/null; $LOG; done

Server (testovaný počítač)

# Port (musí být volný, pod 1024 [nebo možná 1025 -- nevím] požaduje root přístup)
PORT=1234

# Server
while true; do nc -lp $PORT