Ovatko nuo ARP-kyselyt Ubiquitin reitittimelle osoitettuja vai täysin sattumanvaraisia huteja? Jos Ubiquitille, näetkö Wiresharkin kaappauksista, vastaako Ubiquiti ARP-kyselyihin?
Jos Ubiquiti ohittaa itselleen osoitetut ARP-kyselyt, se ei mielestäni toimi oikein.
Jos vastaukset ARP-kyselyihin lähtevät Ubiquitilta normaalisti, joko kaapelimodeemin valmistaja tai joku järkijyrki Telialla on saattanut palomuurata ARP-protokollan tajuamatta, minkälaiseen pätkimiseen tämä tulee johtamaan.
Olen törmännyt hieman vastaavanlaiseen käytökseen aikaisemmin AVM Fritz!box 7270 kanssa. Se toimi aluksi hienosti 24 Online:n ADSL-liittymässä niin kauan, kun he käyttivät Ericssonin DSLAM:ejä. Sen jälkeen, kun 24 Online ulkoisti yhteydet Nebulan ylläpitämiin DSLAM:eihin, Fritz!box alkoi hukkaamaan yhteyden noin kahden minuutin kuluttua laitteen käynnistämisestä tai manuaalisesta DHCP renew-pakotuksesta.
Laitoin linjalle erillisen siltaavan ADSL-modeemin ja tutkin Fritz!boxin liikennöintiä Wiresharkilla. Nebulalta tuli ARP-kyselyitä Fritz!boxille, mutta Fritz!box ei reagoinut niihin millään tavoin. Googlettamalla Fritz!box ja ARP löytyi paljon saksankielistä keskustelua. Kielitaidon puutteen takia minulle ei kuitenkaan selvinnyt muuta, kuin että AVM:n ARP-toteutus syystä tai toisesta herättää keskustelua.
Nebulan DSLAM:iin vaihdettu yhteys toimi ongelmitta Windows-, Linux- ja Linksys WRT54G laitteiden kanssa.
Koska vika vaikutti olevan AVM:n rikkinäisessä ARP-toteutuksessa, vaihdoin reitittimeksi Linksys WRT54G. Fritz!box sai myöhemmin loppusijoituspaikakseen tuttavan Sonera ADSL:n, jonka ARP-toteutus sieti ARP-mykkäkoulua leikkivän Fritz!boxin.
ARP kyselyt koskee toisia Telian IP poolissa olevia osoitteita. Omaa osoitetta en ole niistä löytänyt. Noita siis puskee jatkuvalla kyydillä tulemaan WAN puollella, eikä puhuta mistään paketista tai kahdesta vaan paketteja tulee kymmenen/sekunnissa vauhdilla. Kyseliä lienee Telian reititin. MAC viittaa Ciscoon. Näitä siis puskee myös silloin kun oma reititin ei ole kiinni. Sama ongelma toistuu myös silloin kun Ubiquitin tilalla on linux läppäri ilman palomuuria tai vaikka molemmat olisi yhtä aikaa modeemin perässä.
Tuossa Technicolorin laitteessa on muutenkin yksi todella ärsyttävä vika. Jos laitteen käynnistää uudelleen niin vaikka laite on sillatussa tilassa on sen DHCP palvelin hetken aikaa toiminnassa ennenkuin modeemi saa muodostettua WAN yhteyden ja vaihtaa siltaavaan. Voitte arvata mitä typeryyksiä tästä seuraa kun modeemi jakaa 192.168 alkuisen osoitteen tietyissä tilanteissa perässä olevalle reitittimelle.
ARPhan on myös broadcast liikennetta joten jostain syystä joku tuntuu blokkaavan kaiken muun paitsi broadcast liikenteen.
Mulla oli tuo sama ARP-vika myös joskus, sitten se korjaantui itsestään. Nykyään taas tulee jotain muita outoja random paketeja, jotka on osoitettu täysin tuntemattomille laitteille. MAC-osoitteiden perusteella kohteet ovat usein Technicolorin valmistamia laitteita.
Kytkinten ei kyllä lähtökohtaisesti pitäisi välittää porteista ulos päin mitään muuta kuin ko. porttiin kuuluvia paketteja, mutta koska ilmiö ei sinänsä aiheuta minulle minkäänlaista haittaa (kyseinen liikenne on erittäin vähäistä) niin korjasin ongelman lisääämällä Telian kytkimen ja reitittimen välissä olevalle kytkimelle MAC-filtterin, joka laskee sisälle ainoastaan omille laitteille kuuluvat paketit sekä multicast-liikenteen, eli eräänlainen "esipalomuuri". Tämä suodatus tapahtuu jo ennen reititintä siis. Toki myös Edgerouteriin voisi ohjelmoida samanlaisen, mutta koska mulla on Edgerouterin lisäksi muitakin laitteita suoraan siltaavan yhteyden takana, niin minulla tuo filtteri pitää olla kytkimellä.
Koska sinullakin on hallitava kytkin, voit lisätä tuon MAC-filtterin halutessasi, voin neuvoa tarvittaessa lisää. Tosin siihen varsinaiseen ongelmaasi, eli kaapelinetin pätkimiseen tämä ei toki auta mitään. Siihen en osaa sanoa muuta kuin että myös täällä päin monet kaapelinetin asiakkaat valittavat täysin samaa ja koskee ilmeisesti etenkin omakotitaloja. Siitä kannattaa olla yhteydessä asiakaspalveluun tai tehdä vikailmoitus.
Itsellä samanlaista ongelmaa samalla netillä Rovaniemellä, eli netti pätkäisee 10-60s ajaksi satunnaisesti useita kertoja päivässä. Joskus on toiminut hyvin, mutta tänä vuonna tunnetulla Soneran/Telian laadulla. Eli et todellakaan ole ainoa tämän ongelman kanssa.
Tällä hetkellä voi vain toivoa että joku vetää kuidut tälle alueelle, koska Telialta puuttuu joko ammattitaito tai kiinnostus korjata Rovaniemen kaapelinettiä, jonka surkeus on varmasti heillä tiedossa vaikkeivat halua myöntää.
Ping- ja ARP-liikenteet kulkevat eri tasoilla verkossa, tästä voisi tehdä vielä vikailmoituksen tutkintaan tämän ketjun tiedoilla niin selvitetään yksityiskohtaisemmin kun tietoakin on hyvin täällä kerättynä.
Miten/mihin tästä pitäisi vikailmoitus tehdä niin että se menee oikeasti jonnekkin joka kehtaa tutkia asiaa syvemmin tältä osin? Tästä on ollut aikaisemminkin puhelimessa vikailmoitusta tehdessä puhetta mutta lopputulos on aina ollut sama että tehdään vikailmoitus ja parin päivän päästä tulee tekstari että vika korjattu, käynnistä modeemisi uudelleen ja that's it.
Ohessa on hetki sitten otettu pakettikaappaus. Modeemin (joka siis siltaavassa tilassa) perässä ei ollut muuta kuin läppäri jossa wireshark. Läppärin IP capturointihetkellä 80.221.69.90 (joo, en pelkää paljastaa sitä). Ohessa kuvankaappaus tuosta ARP liikenteestä mitä siis puskee tauotta tulemaan modeemista ulos. Tätä liikennettä ei siis tullut ennen tuota viime keväistä muutosta. Samaa puski myös tulemaan ennen technicoloria käytössä olleella ciscolla joten modeemistakaan tuo ei johdu.
Oma teoriani on että tuo pakettiliikenteen jumi voisi liittyä siihen miten Telian verkko "autentikoi" asiakkaiden päätelaitteet eli pitää esim kirjaa siitä kuinka monta IP:tä mihinkin liittymään on jaettu. Pätkäisyn yhteydessä verkko joku hukkaa reitin päätelaitteelleni tai päätelaite poistetaan "sallittujen listasta" jolloin verkko ei vastaa tai välitä sen paketteja eteenpäin. Puhdas DHCP sitten taas palauttaa "liikennöintioikeuden"
Tuo ARP kyselyiden määrä viittaa myös siihen että päätelaitteita on paljon "hukassa" tai sitten siitä että tuo broadcast domain on jäätävän iso.
@Nakkimuusi, voit tehdä vikailmoituksen vaikkapa tämän lomakkeen kautta (vaatii kirjautumisen). Laita vikailmoitukselle lisätiedoksi ainakin linkki tähän keskusteluun.
@@Nakkimuusi@ kirjoitti:
Oma teoriani on että tuo pakettiliikenteen jumi voisi liittyä siihen miten Telian verkko "autentikoi" asiakkaiden päätelaitteet eli pitää esim kirjaa siitä kuinka monta IP:tä mihinkin liittymään on jaettu.
Veikkaisin, että käyttävät normaalia IP Source guard + DHCP snooping -toiminnallisuutta, jossa kytkin laskee ainoastaan sellaista liikennettä läpi, joka tulee DHCP:llä sovitusta IP-osoitteesta. Kyseessä on ingress-filtteri, eli se suodattaa ainoastaan kytkimelle tulevaa (sinulta päin lähtevää) liikennettä. Siksi saatat nähdä broadcasteja yms. vaikka sinut olisi jo "heitetty pihalle" verkosta.
Homma toimii siten, että verkossa oleva kytkin kuuntelee DHCP-liikennettä ja päivittää sen mukaan taulukkoa siitä, mitkä laitteet saavat toimia missäkin portissa. Tämän taulkon perusteella lasketan sisään portteihin tulevat paketit. Tämä tauluko sisältää myös jäljellä olevan leasetimen. Jos lease ehtii kulua loppuun, poistuu kyseinen entry sieltä taulukosta ja samalla tästä osoitteesta ei enää oteta muuta kuin DHCP-kyselyitä vastaan.
Käytän jopa omassa lähiverkossa tätä samaa tekniikkaa ja jos verkkoon liittää esimerkiksi tuntemattoman laitteen, se ei toimi ennen kuin sille käydään tekemässä kiinteä osoite DHCP-palvelimelle. Eli kun DHCP ei anna laitteelle mitään osoitetta, se ei pääse verkkoon lainkaan. Samalla tavalla Telia voi rajoittaa asiakkaan laitteiden määrän viiteen - kun useammalle ei anneta osoitteita, eivät ne pääse verkkoon. Käytännössä tällainen edellä mainitsemani taulukko sallituista laitteista näyttää esimerkiksi tältä (MAC ja IP osoitteita hieman sensuroituna):
Tässä nähdään käytännössä myös se, mikä on staattisen ja dynaamisen IP-osoitteen ero, staattiset on määriteltävä kytkimelle käsin ja ne toimivat vain ennalta sovitussa portissa. Dynaamiset kytkin oppii itse. 'Trust Port' -tagatut portit ovat niitä, joissa eri verkkojen DHCP-palvelimet toimivat. Kytkin ei salli DHCP-palvelimen pitoa muissa porteissa.
No niin, eli näinollen tutkisinkin seuraavaksi, katkeaako liikenne tasan 20:n minuutin kuluttua (1200 sek lease) viimeisimmästä DHCP:n uudistamisesta. Jos laite ei uudista IP-osoitetta ajoissa, vaan jättää uudistamisen tuohon 20 minuutin kohdalle niin portti ehtii mennä kiinni eikä uudistus onnistu todennäköisesti ilman broadcast-menetelmää. Itse en ole tuota omissa kytkimissä ihan niin tarkasti testannut, mutta homman idea on kuitenkin se, että leasetimen umpeuduttua kaikki liikenne aiemmin saadusta IP:stä ei mene enää läpi, mutta DHCP kuitenkin onnistuu.
Voi olla, että paketteja katoaa juuri kriittisellä hetkellä kun laite on tekemässä DHCP-kyselyä yms.
Tämäkin ongelma olisi paljon lievempi, jos Telia käyttäisi järkevää leasetimea, esimerkiksi 86400 sek. Nyt kun se on 1200 sek. niin kaiken pitää toimia viimeisen päälle, ettei netti ala pätkiä. Vähänkin häiriöitä esimerkiksi kaapelinetin takia, niin porukka alkaa tippua pois netistä.
Koska sinulla on edgerouter, niin voit seurata DHCP:n toiminnallisuutta parhaiten komennolla "show dhcp client leases". SIitä näet mm. uudistamishetken kellonajat, milloin lease umpeutuu yms. tietoa.
Täällä ainakin lease time on Telialla 43200. Tuolle stopille ei ole mitään tiettyä aikaa missä vaiheessa se tapahtuu, Voi mennä parikin päivää hyvin tai sitten on monta kertaa samana päivänä. Yhteistä kuitenkin on että se tapahtuu jokaiselle päätelaitteelle samaan aikaan. Eli oikeasti minulla on kaksi eri reititintä tuossa modeemin takana ja välillä se linux läppäri kolmantena. Kun tämä stoppi tapahtuu se tapahtuu joka laitteelle samalla hetkellä. Tämän jälkeen joka laitteen täytyy pyytää uusi IP broadcast DHCP:llä että pystyvät liikennöimään. Jos tuon tekee vain yhdellä, niin muiden liikenne on edelleen pysähdyksissä.
Tavallaan tässä ongelmassa tuo pitkä leasetime vain pahentaa ongelmaa koska reititinhän ei pyydä automaattisesti uutta IP:tä broacastinä ennenkuin se lease time umpeutuu kun taas normaali uudistamispyyntö aikaisemmalle DHCP palvelimellehan tapahtuu jo hyvissä ajoin ennen leasetimen umpeutumista. Tästä johtuen liikenne ei automaattisesti palaudu kuin vasta pitkän ajan päästä kun lease time on täysin kulunut.
Tämän ilmiönhän on saanut manuaalisesti toistettua käyttämällä modeemin antennipiuhaa hetkisen irti.
Ohessa on vielä kuva alkukesästä kun tuo liikenne lakkaa. Tuossa modeemin perässä oli ainoastaan linux läppäri joka pingaa 5 sekunnin välein osoitetta www.google.fi Normaalisti en käytä Telian nimipalvelimia (ja kaikki varmaan tietää miksi) mutta tässä mittauksessa päätin käyttää koska niiden pitäisi kuitenkin toimia sen verta että normaali käyttö onnstuu. Tuossa olevat DHCP paketit eivät olleet tarkoitettu omalle koneelle. Tuosta on suodatettu ARP liikenne pois.
Oho, vieläkö jollakin onnellisella on 43200 leaseja? Saisinpa minäkin, jotta pääsisi mm. päivittämään reitittimen softat! Näköjään kaikki Telian kuluttaja-asiakkaat eivät olekaan tasa-arvoisia, osa kuten itse on kirottu 1200 sekunnin leasella ja osa saa nauttia pidemmästä. TASA-ARVOA peräänkuulutan nyt! :)
Mutta itse vikaan: havaintosi siitä, että ainostaan broadcast-muotoinen leasen uudistus kelpaa liikenteen katkettua, on kyllä tosi vahva indikaatio tuohon mitä aiemmin selitin IP source guardin toiminnasta. Sehän nimenomaan estää unicast-liikenteen asiakkaalta verkkoon päin, mutta ei toiseen suuntaan. Varmuuden asiaan saisi sieltä Telian kytkimen lokeista, koska siitä jää merkintä jos asiakas yrittää käyttää "luvatonta" IP-osoitetta.
Mutta - miksi se sitten tekee näin, ennen kuin lease on edes umpeutunut ei voi selittyä oikein muuten kuin että kyseinen kytkin boottailee itsekseen. Nimittäin jos tällaisen kytkimen boottaa, niin se johtaa juurikin kuvailemaasi tilanteeseen; unicast-liikenne asiakkailta verkkoon päin katkeaa, eivätkä laitteet saa leasea uudistettua unicastina lainkaan.
Oikein muutakaan järkisyytä sille, miksi se löisi portit kiinni kesken kaiken on vaikea keksiä. Melkovarma laitevika siis. Toivottavasti löytävät & korjaavat. Harmi ettet pysty tuolle itse tekemään mitään muuta kuin vikailmoituksen ja sen jälkeen toivomaan parasta.. :)
EDIT: Missasin yhden detailin, nimittäin sen että antennipiuhan irroitus triggeröi saman ilmiön. Silloinhan mikä tahansa katkos yhteydessä triggeröi vian päälle. Ja kaapelinettihän tunnestusti pätkii, eikä asiaan ole välttämättä helppoa korjausta.
Ilmeisesti IP source guard tai vastaava toiminne onkin integroitu osaksi CMTS:aa, eli havaitessaan kantoaallon katkon se resetoi leaset sieltä binding taulukosta. Jos en aivan väärin muista niin ADSL-linjassa taisi olla sama juttu, jos linja katkaisi niin portti meni kiinni. Sensijaan VDSL:aa sai pätkiä miten huvittaa ilman että meni kiinni.
Eli eli.. voisi olla myös CMTS:n conffijuttu, leaseja ei saisi nollata jostain sekunnin katkoksesta lainkaan.
Jännityksellä jään odottamaan, saavatko vikaa korjattua lainkaan..
Tuli vielä sellainen mieleen, että ainakin siinä EdgeRouterissahan voit ajaa omaa koodia. Ei olisi mahdottoman iso homma koodata pientä python-koodia tai shell-sriptiä pingaamaan jotain varmaa serveriä tai useampaa (vaikka Googlen DNS) vaikka kerran minuutissa ja mikäli ping ei mene läpi, käynnistetään se broadcast-pohjainen DHCP-menettely.
Varsinaista ongelmaahan tämä ei toki korjaa, mutta kiertäisi sitä osittain ja huolehtisi, ettei netti putoa pois ainakaan pitkäksi aikaa. Koska jos juurisyynä tässä on kaapeliverkon pätkiminen ja osasyyllisenä CMTS:n ominaisuus, voi olla ettei varsinaista korjausta tule ikinä.
Telian verkkohan on voitu suunnitella siten että siinä käytettäisiin heidän omia modeemeitaan ainoastaan reitittävänä, joka mahdollistaa sen että modeemiin integroitu reititin pystyy näkemään jos carrier putoaa ja starttaamaan DHCP-toimenpiteet carrierin palattua. Mulla oli aikoinaan TeleWellin ADSL-modeemi ja siinä homma toimi juurikin näin. Heti jos linkki putosi, oli lokissa seuraava merkintä IP address set to 0.0.0.0 tms. ja välittömästi linjan palattua se käynnisti IP-osoitteen uudelleenhaun.
Sillatussa järjestelmässä ei reititin pysty mistään näkemään, onko modeemi hukannut carrierin. Tällöin myöskään DHCP:n linkitys ei onnistu vaadittavalla tavalla ja siitä voi tulla tällainen riesa mikäli operaattorin pää lyö portit kiinni pienestäkin yhteyskatkosta.
@Nakkimuusi@ kirjoitti:
Täällä ainakin lease time on Telialla 43200
Kun tunnuit olevan hyvin verkkotekniikasta perillä, niin pystyisitkö katsomaan, mikä DHCP-palvelin jakelee näitä 43200 leasella olevia IP-osoitteita? Voisin itse koittaa unicast-kyselyllä, pääsisinkö sitä kautta "A-ryhmään" pidemmälle leaselle. Normaalein broadcast-kyselyin saan ainoastaan 88-alkuisia osoitteita ja 1200 leasella.
