classic.ISPforum.cz

Zdravim panove - mam takovy maly ufo problem.
Prevzal jsem jednu sit, trochu jsem to zacal konsolidovat a po dokonceni se mi nahodne objevuje u ruznych klietnu nasledujici problem: vsechno funguje, klienti surfujou jako o zivot, ale pokud se pokusi najet na stranky facebooku nebo youtube tak se stranka nacte, ale je to jako kdyby se nenacetly css styly te stranky. Kdyz jsem se pokousel to opravit, tak nekdy staci restartovat jejich klienta nekdy ne, nekdy se to samo srovna casem a pak se to zase objevi u nekoho jineho...

Sit je cela na ROS, routovana pomoci static routes (je tam jenom par bodu). Paterni linka je teda dramaticky podhodnocena (coz uz resim), shaper QT. Je jasny, ze kdyz je to pretizeny, takze by jim to mohlo blbnout, ale ono je to tak, ze je to fakt nahodny - ja se v danej okamzik pripojim svym NT na ten samej bod, taky na wifine a me to stejne jako vetsine klientu frci uplne v poho, linka je nebo neni vytizena, ale u nich to proste nenabehne korektne. Deje se to na ruznejch klientech (5460, ubnt, zcomax, MK, jak na 2,4 tag 5,4).

Za kazdou myslenku budu rad, diky.

nemáš tam náhodou hotspot? já to před vánocemi řešil tady na jednom hotspotu v jedný ubytovně a přesně jak píšeš, FB jako by nenačetlo styly. Nevim jseli má FB nějaký problemy nebo co ale tak nějak se ladilo nastavení a tak nějak to bylo jak na kterym PC. Příčina se nenašla.

ja som vcera mal rovnaky problem u seba na UPC, nestahovali sa vobec CSS styly (tusim od 20h do 01h). vidim to na problem na strane FB (CDN Akamai).

hmm - zajímavé. No hotspot balíčky mám na mainrouteru i ostatních AP, ale nikde to není nakonfigurované ani to neběží, takže v tom by asi zakopaný pes být neměl... Když jsem to řešil na jednom AP, tak jsem tam akorát našel, že si ap načetlo navíc adresu z dhcpčka virtualap, ktery na tom běželo - tak mi napadlo, že se tam trochu víc předávaj pakety a tím by třeba došlo na načtení kostry stránky a pak by te zbytek byl zahozenej, protože odezva by byla moc dloho po požadavku. DHCP klienta jsem vypnut (zůstal tam po předchozim nastavení a já si toho nevšiml) a vše najednou fungovalo. Jenže se to potom objevilo jinde a pak i znova na stejném místě a i na jiných AP.
Zajímavé je, že se to objevilo i na UPC (jak tu zaznělo) - i když všichni víme, jak jim to funguje...

No mě napadly víceméně jen dva směry kterými se dát a to je problém s DNS nebo routy.
Routy jsem všechny překontroloval a jsou ok.
DNS jsem taky překontroloval a je to taky ok - je pravda, že nám ho dělá náš operátor (lokální - nic velkého), ale vše ostatní běželo naprosto v pořádku, tak nemám důvod si myslet, že by měli problém.

Ještě mi teďka napadla jedna věc - po dokončení konsolidace tj. zásah po kterém se to objevilo, začala být síť dost brutálně vytěžována z venku DoS útokem. V rámci toho došlo k omezení služeb na googlu. To jsem pořešil zradikalizováním firewallu, který byl před tím ušit horkou jehlou a propouštěl skoro všechno. Následně se služby zprovoznili všechny zpátky a v normalu - jedinné co se zachovalo je tenhle problém s FB a YT. Jak jsem koukal po netu, tak se to objevuje různě i u jiných lidí, ale zkuste to vysvětlit klientům, když jsou to např. ženy na mateřské, pro které je fb prakticky jediným stykem s realitou (né že bych to považoval za správné, ale štve mi, že nejsem schopen nejít, kde je problém).

Ještě upřesnění - vše běží na ROS 5.22 a není to nic velkého tj. mainrouter RB00 s dautherboardem (5AP a spoj), groove kterej dela spoj na dalsi AP (RB433) a pak AP (RB333) na spoji od mainrouteru. Vytížení v řádu max desítek procent.

Mě něco podobného dělala změna MTU na jednom z portů. Stačí, aby YT nebo FB měli styly uloženy na jiném serveru a už se k nim nedostaneš.

Zkus si na počítači kde otevíraš stránky nastavit jiný DNS server, třeba veřejný 8.8.8.8 Je to nějaký problém s DNS v mikrotikách.

Abych nezapoměl potom vymazat dns cache ipconfig /flushdns

Tak panové - mám resumé. Věc jsem prověřil a už to 14 dní testuju abych měl jistotu. Jak tu právě napsal menics, je to v DNS. Na bodech kde to blblo jsem zakázal balíčky hotspotu(protože je nepotřebuju), vypnul jsem MPLS baliček a našel chybu v adrese DNS. A problem se už znova neobjevil.

Zajimavé je, že chyba byla až v adrese sekundárního DNS, takže první zápis byl platný, předpokládám, že tedy MT dává dotaz DNS1 a pokud není dostatečně rychle nalezena shoda v záznamech ptá se DNS2 (standartní postup) nebo se pletu a dotazuje to rovnou oba a pak využije rychlejšího? (což by bylo divný...)

A nesměřoval ten první platný záznam na "dnsku" provozovanou na mikrotiku? Měli jsme třeba problém s tím že některé routery (SMC atd.) nějak neuměli komunikovat s DNS cache na mikrotiku a prostě někdy se jim nechtělo vracet záznamy. nevím jestli to nebylo verzí sw na mk protože se tam pak něco opravovalo, nechodilo to možná po ugradu na 5.12

What's new in 5.18 (2012-Jun-21 17:20):
*) dns could not resolve some domain names, was ignoring replies with DNAME RRs;

What's new in 5.21 (2012-Oct-12 08:25):
*) dns - fix empty response;

jj to by mohlo byt ono - primarin dns je u naseho poskytovatele a ta je urcite na MT, ale verzi ROS jsem nezjistoval. Ta druha uz by mela byt nekde dal, predpokladam jejich velko dodavatele
Jsem rád, že jsme se dobrali nějakého výsledku, snad to ostatním pomůže.

mne nieco podobne robilo, pri yahoo, fb, a este xy stranok...

zmenil som ISP na wan porte som mal predtym IP a vsetko slo bez problemov...
novy ISP isiel cez pppoe a problem y nastali...
po x pokusoch som zistil ze mam problem s IP ktore maju shapovenie cez QT upload...
musel som vsetkym IP prehodit shapovanie uploadu na simple a problem zmyzol...
nechapem co kde je problem, ale pri pppoe mi nejde QT upload shapovanie.. teda ist ide ale nastane tento problem...

ako sekundarny dns pre podobne problemy som zacal pouzivat 8.8.8.8, zrusil som resolvovanie....