Dotaz: Výpadky připojení

[Martin]

Ahoj,

mám problém s připojením k internetu, resp. vypadává mi spojení.

Tento stroj slouží jako router (cca rok), cca před 14 dny jsem měl jeden problém, že mi to na jednom rozhraní způsobovalo chyby, protože jsem měl v záloze ještě jednu volnou síťovou kartu, tak jsem to předělal na tu druhou, ale po 14 dnech se to ozvala opět ta samá chyba. Ping z venkovní sítě na router, chvíli jede, chvíli zase ne:

64 bytes from 188-xxxxx.cz (188.xxx.xxx.xxx): icmp_seq=314 ttl=54 time=16.0 ms
64 bytes from 188-xxxxx.cz (188.xxx.xxx.xxx): icmp_seq=315 ttl=54 time=16.0 ms
From 188-xxxxx.cz (188.xxx.xxx.xxx) icmp_seq=323 Destination Host Unreachable
From 188-xxxxx.cz (188.xxx.xxx.xxx) icmp_seq=324 Destination Host Unreachable
From 188-xxxxx.cz (188.xxx.xxx.xxx) icmp_seq=325 Destination Host Unreachable
From 188-xxxxx.cz (188.xxx.xxx.xxx) icmp_seq=326 Destination Host Unreachable
From 188-xxxxx.cz (188.xxx.xxx.xxx) icmp_seq=327 Destination Host Unreachable
From 188-xxxxx.cz (188.xxx.xxx.xxx) icmp_seq=328 Destination Host Unreachable
From 188-xxxxx.cz (188.xxx.xxx.xxx) icmp_seq=329 Destination Host Unreachable
From 188-xxxxx.cz (188.xxx.xxx.xxx) icmp_seq=330 Destination Host Unreachable
From 188-xxxxx.cz (188.xxx.xxx.xxx) icmp_seq=331 Destination Host Unreachable
64 bytes from 188-xxxxx.cz (188.xxx.xxx.xxx): icmp_seq=332 ttl=54 time=16.4 ms
64 bytes from 188-xxxxx.cz (188.xxx.xxx.xxx): icmp_seq=333 ttl=54 time=15.9 ms
64 bytes from 188-xxxxx.cz (188.xxx.xxx.xxx): icmp_seq=334 ttl=54 time=15.8 ms
64 bytes from 188-xxxxx.cz (188.xxx.xxx.xxx): icmp_seq=335 ttl=54 time=16.4 ms

Jedná se připojení se staticky nastavenou IP adresou, zkoušel jsem kabeláž a ta se zdá být v pořádku (testováno notebookem). Myslíte, že by to mohlo být teplotou, sensors ukazuje:

M/B Temp:     +53.0°C  (low  = -127.0°C, high = +127.0°C)
temp3:        +76.5°C  (low  = -127.0°C, high = +127.0°C)

Disk (hddtemp) má teplotu 41°C

Myslíte, že už je to moc, nebo mám hledat chybu jinde? Pokud mě nakopnete směr kterým se mám vydat pro zjištění problém budu rád, já už fakt nevím co zkusit.

Odpovědi

[Jendа]

Nemůže být chyba cestou? Co ping na poslední hop před routerem? Co ping z routeru na tento hop?

[Martin]

Jako jistý si nejsem, ale když jsem posledně připojil ten notebook, tak jelo vše jak mělo. vrátil jsem to zpět do routeru a opět to bylo rozsekané, takže myslím že se musí prostě dít něco nekalého v něm. Ten ping vypadával také, bohužel nemůžu pingovat z routeru, když se na něj nepřipojím (je fyzicky daleko). Jak píšu momentálně to funguje dobře 0% ztrátovost, ale mám pocit, že když se to opravilo samo, tak se to opět vrátí jako i před těmi 7 dny.

[Milan Roubal]

Kdyz jsem podobne chovani resil naposled tak byly v siti 2 zarizeni se stejnou IP adresou.

[Martin]

Je to veřejná IP adresa přidělena ISP, takže předpokládám, že tam snad nebude mít kolizi. Neodpovídalo by mi na ping to druhé "zařízení", pokud nemá blokované... Krom toho mi to s připojeným notebookem šlo (při tom minulém výpadku, jen nebyl před 14 dny ale 7, ale to je asi jedno).

[NN]

Kde jsou pakety mezi ICMP sekvenci 315-323? Stracene/zahozene? Pakety dorazi/nedorazi na server? Odejdou, ze serveru, ale nevrati se? Pouzij tcpdump a over to.

[Martin]

No problém je, že ten router(linux server) je fyzicky daleko ode mě, takže se k němu jen tak nepřipojím, když zrovna nejede. Ten ping je směrem k němu, chtěl jsem mít ukázku toho jak to vypadává. Jinak bez jakéhokoliv zásahu postupně k večeru klesala ztrátovost teď ráno byla na nule ale občas se taky ztratí do 1%.

[petr_p]

Tenhle výpis je k ničemu, protože v něm chybí IP adresy. Například je důležité, kdo odeslal Destination Host Unreachable.

[Martin]

Ve výpisu je skrytá jen jedna IP adresa a to toho routeru.

[petr_p]

V tom případě někdo někde podvádí.

Destination Host Unreachable (ICMP typ 3, podtyp 1) se používá, když router nemůže odeslat packet stroji na lokální síti. V případě Ethernetu to znamená, že nemá jeho MAC adresu. Například když stroj je vypnutý. Pak ovšem ve výpisu pingu by jako zdrojová adresa chybovém zprávy byla adresa routeru, nikoliv nedosažitelného stroje.

Jinak řečeno, to že tam nemáte jinou adresu, je známkou, že váš ISP má rozbité svoje routery, nebo že váš stroj odesílá tuto chybovou zprávu zcela nesmyslně (sám o sobě tvrdí, že není dostupný), takže má třeba špatně nastavený firewall.

Poslední dobou vídávám takovéto zprávy z cloudových center, kdy se míchá dohromady linková a spojová vrtsva (například MACVLAN) a ještě do toho zasahuje překlad adres, který se snaží předstírat statické adresy.

Z časování zpráv to vypadá, že vše funguje, mezitím routeru ISP vyprší záznam s MAC adresou vašeho stroje, sedm sekund se poukouší přeložit ARPem adresu (to je to ticho), pak se mu to podaří a zase vše funguje.

Normálně se ARP dotaz pokládá ještě před vypršením záznamu, takže by to znamenalo, že zatímco packety s ICMP chodí, s ARP nechodí. To je docela blbost. Jedině že by někdo někde zahazoval broadcastové rámce. Nebo linka byla natolik ucpaná/zarušená, že projde jen pár packetů a zrovna to jsou ty s ICMP, ale žádný a ARP. To by se ale projevilo na náhodných ztrátách i ICMP, což z těch pár, co jsou ve výpisu, nevypadá.

Taky se normálně používá oportunistické učení MAC adres, takže když router ISP vidí ICMP rámce od vás, tak si z nich přečte MAC a nemusí se na ni znovu ptát. Tohle se tu také očividně neděje.

Tohle všechno jsou ale spekulace, které bez dalšího výzkumu nic neobjasní. Například logovat na vašem stroji ICMP a ARP, by bylo vidět, co přichází od ISP, když se vyskytne porucha, by bylo velmi vhodné.

[Martin]

Příloha:

• fw_conntrack-month.png (60007 bytů)

Já pinguji ten router (pc jako linuxem - NATem) přes internet. Momentálně se pohybuji se ztrátovostí kolem 10% :-/ Mám tam puštěný munin a ten neukazuje, nějaký abnormální trafic, ani počet spojení, pohybuje se to všechno v ročních průměrech, takže vytížené to asi nějak extra nebude, ale něco se asi stalo před těmi pár dny, když byl první výpadek, ale jestli je to něco co způsobuje tuto chybu nevím, viz. přiložený graf.

Jakým optimálním nástrojem logovat ať je to k něčemu použitelné?

[Jendа]

Jakým optimálním nástrojem logovat ať je to k něčemu použitelné?

tcpdumpem, jak jinak. Pokud je to prehistorická verze, nezapomenout na parametr -s hodně.

[petr_p]

Agregované grafy jsou k ničemu. Potřebujete úplný záznam provozu z období chyby. To jest packet po packetu. Začít můžete s nástrojem tcpdump.

[Martin]

Tak jsem trochu posledoval tcpdump a nezdají se mi tam nějaké věci, z veřejného rozhraní mi chodí nějaké dotazy s neveřejnou IP:

# tcpdump -i eth0|grep 192.168.
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:15:46.482933 IP 192.168.19.4.5678 > 255.255.255.255.5678: UDP, length 98
12:15:46.771615 IP 192.168.19.11.5678 > 255.255.255.255.5678: UDP, length 98
12:15:49.805162 IP 188-xxxxx.cz.3942 > 192.168.0.1.1900: Flags [S], seq 464587655, win 5840, options [mss 1460,sackOK,TS val 3653775 ecr 0,nop,wscale 1], length 0
12:15:49.809415 IP 188-xxxxx.cz.3033 > 192.168.0.1.1900: Flags [S], seq 453562137, win 5840, options [mss 1460,sackOK,TS val 3653431 ecr 0,nop,wscale 1], length 0
12:15:49.920191 IP 188-xxxxx.cz.3943 > 192.168.0.1.1900: Flags [S], seq 459674858, win 5840, options [mss 1460,sackOK,TS val 3653787 ecr 0,nop,wscale 1], length 0
12:15:49.932105 IP 188-xxxxx.cz.3034 > 192.168.0.1.1900: Flags [S], seq 464378535, win 5840, options [mss 1460,sackOK,TS val 3653443 ecr 0,nop,wscale 1], length 0
12:15:50.012810 IP 188-xxxxx.cz.3035 > 192.168.0.1.1900: Flags [S], seq 460494958, win 5840, options [mss 1460,sackOK,TS val 3653451 ecr 0,nop,wscale 1], length 0
12:15:50.043228 IP 188-xxxxx.cz.3944 > 192.168.0.1.1900: Flags [S], seq 461101675, win 5840, options [mss 1460,sackOK,TS val 3653799 ecr 0,nop,wscale 1], length 0
12:15:50.118928 IP 188-xxxxx.cz.3036 > 192.168.0.1.1900: Flags [S], seq 455199982, win 5840, options [mss 1460,sackOK,TS val 3653462 ecr 0,nop,wscale 1], length 0
12:15:50.120911 IP 188-xxxxx.cz.3945 > 192.168.0.1.1900: Flags [S], seq 456943227, win 5840, options [mss 1460,sackOK,TS val 3653807 ecr 0,nop,wscale 1], length 0
12:15:50.226986 IP 188-xxxxx.cz.3037 > 192.168.0.1.1900: Flags [S], seq 466132341, win 5840, options [mss 1460,sackOK,TS val 3653473 ecr 0,nop,wscale 1], length 0
12:15:50.240904 IP 188-xxxxx.cz.3946 > 192.168.0.1.1900: Flags [S], seq 457813199, win 5840, options [mss 1460,sackOK,TS val 3653819 ecr 0,nop,wscale 1], length 0
12:15:50.324793 IP 188-xxxxx.cz.3038 > 192.168.0.1.1900: Flags [S], seq 460404270, win 5840, options [mss 1460,sackOK,TS val 3653482 ecr 0,nop,wscale 1], length 0
12:15:50.334284 IP 188-xxxxx.cz.3947 > 192.168.0.1.1900: Flags [S], seq 456033724, win 5840, options [mss 1460,sackOK,TS val 3653828 ecr 0,nop,wscale 1], length 0
12:15:50.428977 IP 188-xxxxx.cz.3039 > 192.168.0.1.1900: Flags [S], seq 459672645, win 5840, options [mss 1460,sackOK,TS val 3653493 ecr 0,nop,wscale 1], length 0
12:15:50.436808 IP 188-xxxxx.cz.3948 > 192.168.0.1.1900: Flags [S], seq 459925799, win 5840, options [mss 1460,sackOK,TS val 3653838 ecr 0,nop,wscale 1], length 0
12:15:50.532836 IP 188-xxxxx.cz.3949 > 192.168.0.1.1900: Flags [S], seq 466710127, win 5840, options [mss 1460,sackOK,TS val 3653848 ecr 0,nop,wscale 1], length 0
12:15:50.534815 IP 188-xxxxx.cz.3040 > 192.168.0.1.1900: Flags [S], seq 452616629, win 5840, options [mss 1460,sackOK,TS val 3653503 ecr 0,nop,wscale 1], length 0
12:15:50.637651 IP 188-xxxxx.cz.3950 > 192.168.0.1.1900: Flags [S], seq 450809210, win 5840, options [mss 1460,sackOK,TS val 3653858 ecr 0,nop,wscale 1], length 0
12:15:50.638007 IP 188-xxxxx.cz.3041 > 192.168.0.1.1900: Flags [S], seq 463764187, win 5840, options [mss 1460,sackOK,TS val 3653514 ecr 0,nop,wscale 1], length 0
12:15:50.741721 IP 188-xxxxx.cz.3951 > 192.168.0.1.1900: Flags [S], seq 450855901, win 5840, options [mss 1460,sackOK,TS val 3653869 ecr 0,nop,wscale 1], length 0
12:15:50.743787 IP 188-xxxxx.cz.3042 > 192.168.0.1.1900: Flags [S], seq 458482915, win 5840, options [mss 1460,sackOK,TS val 3653524 ecr 0,nop,wscale 1], length 0
12:15:50.845510 IP 188-xxxxx.cz.3952 > 192.168.0.1.1900: Flags [S], seq 451569341, win 5840, options [mss 1460,sackOK,TS val 3653879 ecr 0,nop,wscale 1], length 0
12:15:50.853186 IP 188-xxxxx.cz.3043 > 192.168.0.1.1900: Flags [S], seq 465696165, win 5840, options [mss 1460,sackOK,TS val 3653535 ecr 0,nop,wscale 1], length 0
12:15:50.960321 IP 188-xxxxx.cz.3953 > 192.168.0.1.1900: Flags [S], seq 456815535, win 5840, options [mss 1460,sackOK,TS val 3653891 ecr 0,nop,wscale 1], length 0
12:15:50.962281 IP 188-xxxxx.cz.3044 > 192.168.0.1.1900: Flags [S], seq 457897976, win 5840, options [mss 1460,sackOK,TS val 3653546 ecr 0,nop,wscale 1], length 0
12:15:51.053071 IP 188-xxxxx.cz.3045 > 192.168.0.1.1900: Flags [S], seq 455730758, win 5840, options [mss 1460,sackOK,TS val 3653555 ecr 0,nop,wscale 1], length 0
12:15:51.053316 IP 188-xxxxx.cz.3954 > 192.168.0.1.1900: Flags [S], seq 452591486, win 5840, options [mss 1460,sackOK,TS val 3653900 ecr 0,nop,wscale 1], length 0
12:15:52.798223 IP 188-xxxxx.cz.3942 > 192.168.0.1.1900: Flags [S], seq 464587655, win 5840, options [mss 1460,sackOK,TS val 3654075 ecr 0,nop,wscale 1], length 0
12:15:52.806057 IP 188-xxxxx.cz.3033 > 192.168.0.1.1900: Flags [S], seq 453562137, win 5840, options [mss 1460,sackOK,TS val 3653731 ecr 0,nop,wscale 1], length 0

Taky se mi nezdá, že mi tam chodí toto, ne vždy tak najednou:

12:13:18.218971 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 4c:5e:0c:ee:4c:35 (oui Unknown), length 300
12:13:18.859055 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 4c:5e:0c:ff:6c:b3 (oui Unknown), length 300
12:13:18.886645 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 4c:5e:0c:dc:34:f9 (oui Unknown), length 300
12:13:19.194129 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 4c:5e:0c:2f:c4:31 (oui Unknown), length 300
12:13:19.252124 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 4c:5e:0c:ee:4c:35 (oui Unknown), length 300
12:13:19.254527 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 4c:5e:0c:dd:8b:c5 (oui Unknown), length 300

Může toto způsobovat nějakou chybu? Je toto moje chyba v konfuguraci nebo ISP?

[petr_p]

Může toto způsobovat nějakou chybu? Je toto moje chyba v konfuguraci nebo ISP?

To my nemůžeme vědět, protože nevíme, jak máte síť organizovanou, kdo má jaké rozsahy, které lze kam směrovat a tak dále. Nakonec z těch výpisu není poznat, jestli se jedná o odchozí nebo příchozí packety (to je ale problém tcpdumpu, že neukazuje směr; má jen přepínač --direction pro výběr zobrazeného směru).

[petr_p]

První dva záznamy jsou autodiscovery protokol mezi RouterOS. Pokusy připojit se na TCP port 1900 vypadají jako útok nebo blbě implementovaný SSDP, který má používat UDP. Zbytek je 5 DHCP klientů z továrny Mikrotiku toužících po IP adrese.

[Martin]

Tak problém bude asi na rozhraní, jsem přehlédl ty errory a droppy:

eth0      Link encap:Ethernet  HWadr 00:30:xx:xx:xx:xx
          inet adr:188.xxx.xxx.xxx  Všesměr:188.xxx.xx.xx  Maska:255.255.255.240
          AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST  MTU:1500  Metrika:1
          RX packets:214706 errors:60745 dropped:35288 overruns:0 frame:0
          TX packets:82175 errors:0 dropped:0 overruns:0 carrier:0
          kolizí:0 délka odchozí fronty:1000 
          Přijato bajtů: 85953800 (85.9 MB) Odesláno bajtů: 8618402 (8.6 MB)

Podle toho jak jsem googlil se jedná o problém, kdy se síťovky nedomluví na rychlosti a duplexu. Domluvená rychlost je 100/full, což mi přijde jako normální. Zkusím tam dojít a píchnout tam notebook a co si domluví z auto-negotiation on, když to s tím ntbkem jelo.

Nemáte nějaký tip co by to mohlo ještě způsobovat, na co se zaměřit?

[gogol]

Akym typom linky si pripojeny k ISP ?

nejake bezdratove pojitko, alebo metalika/optika ?

[Martin]

Jejich připojení je bezdrát do nějaké jejich krabice a pak z něj ethernet ke mě přímo do routeru. nevím jestli to ale může být jejich připojením, když notebookový test fungoval dobře.

[gogol]

Notebookovy test mohol byt ok, pretoze si to skusal v "inom" case. Nepredpokladam, ze si pingal ten router aj notebook sucasne. Bezdrat je nevypocitatelny, zvlast ten v bezlicencnom pasme. Staci ak je obcas v dosahu rusiaca stanica a bude sa to spravat takymto sposobom. Obcas v dosahu znamena, ze moze byt vacsinu casu pod rozlisenim prijimaca, ale obcas za prihodnych poveternostnych podmienok sa moze signal zvysit a rusit. Doporucil by som pingat tu "jejich krabicu" z routra a sucasne tvoju IP na druhej strane. Bohuzial bezdrat ma dve strany, takze ak by to bolo bezdratom, tak bude asi potrebne urcit na ktorej strane je rusenie, pretoze moze byt na jednej, druhej, alebo aj na obidvoch stranach a navyse nesumerne.