Nettiyhteyden kanssa ongelmia, ajatuksia tai ideoita?

[Algron28]

Eli.

Telian kaapelimodeemilla tulevan nettiyhteyden kanssa ongelmia. Kytkentä näin, cisco siltaavana

Ongelma on että välillä parikin kertaa päivässä nettiyhteys jumii täysin ja mitään dataa ei kulje wanin yli. Telialta tuleva arp pakettien virta kuitenkin valuu reitittimille asti. Ja tämä koskee siis molempia reitittimiä ja tapahtuu yhtäaikaa molemmille. Tähän yleensä auttaa kun reitittimet resetoi, mutta välillä käy niin että eivät sen jälkeen saa heti IP osoitetta telialta.

tämä yleensä korjaantuun 10-20 min kuluessa mutta reitittimen portti pitää käyttää alhaalla että hakee ip:n. Modeemin yhteysvalot eivät missään kohtaa mene alas kuitenkaan.

Mitenkähän tätä kannattaisi lähteä diagnosoimaan?

 

[Stanley H. Tweedle]

Onko käytössä Telian nimipalvelimet?

Soneran yhteyden katkominen loppui, kun laittoi muut nimipalvelimet.

 

[Algron28]

Pitääpäs kokeilla. Se varmaan tuo edgerouter käyttää sitä DNS mikä sieltä operaattorin dhcp:ltä tulee jos muuta ei ole määritelty. Pitää vaihtaa toiselle ER joku manuaalisesti. Suosituksia mitä DNS:sää kannattaa käyttää?

 

[Stanley H. Tweedle]

Tästähän on koulukuntaeroja. Nopeasti ja varmasti toimivat Googlen 8.8.8.8 ja 8.8.4.4 on ainakin diagnoosin tekemiseen hyvät.

 

[Algron28]

Noniin, heitin toiseen edgerouteriin nimipalvelimet manuaalisti tämän ohjeen mukaan: Ubiquiti Networks Community

Helppo vertailla kun on kaksi laitetta joissa sama ongelma. Eikös tämä Telian (eli siis soneran) nimipalvelin ongelma ole tuttu jo vuodelta kivi ja kirves. Nyt kun tarkemmin muistelen niin tästä on murossa poristu aikoinaan useaan otteeseen. Miksihän homma ei pelitä vieläkään näiden kaikkien vuosien jälkeen.

 

[Stanley H. Tweedle]

Vanha juttuhan se on ja jos tuo on sinulla syy myös sitkeä ja aivan käsittämätöntä tunarointia.

 

[Lagittaja]

Sivuhuomiona kun tässä on ER:t ja DNS:t esillä niin voisin mainita että jos Algron28 ei ole tietoinen niin näissä käytetään dnsmasq:ta DNS:n hoitamiseen. Siitä löytyy kaikenlaista kivaa mutta etenkin tuohon "mitä palvelimia käyttäisin" kysymykseen liittyen nostaisin esille dnsmasq:n "all-servers" vaihtoehdon.
Eli tämän "all-servers" vaihtoehdon kanssa jos purkit on konffattu toimimaan DNS palvelimena sinun verko(i)llesi ja service dns forwarding name-server vaihtoehtoina on esimerkiksi A.A.A.A, B.B.B.B ja C.C.C.C palvelimet > jos purkille tulee DNS kysely jota ei löydy välimuistista > kysely pistetään eteenpäin jokaiselle ja se joka vastaa ensimmäisenä "voittaa".

Pidetään järki kuitenkin matkassa eikä ruveta änkemään paria tusinaa nimipalvelinta tuonne, ihan turhaa liikennettä. Minulla on kolme, Googlen B ja sitten molemmat Censurfridns:n palvelimista. Kaksikin kyllä riittäisi..
Ja kun dnsmasq:ssa käytetään sitä välimuistia niin sekin vähän hellittää sitä kuormaa. Se forwarded vs answered locally suhde vähän vaihtelee ja riippuu tietenkin käytöstä mutta itse olen nähnyt kaikkea 10-40% välillä.​

Ja kun kysyit että mitä DNS palvelimia käyttäisit niin netistä löytyy näistä listaa ja koneella voit DNSBench nimisen sovelluksen avulla testata mitkä ovat sinulle nopeimpia.
Esimerkiksi täältä https://public-dns.info/ ja sivun alalaidasta löytyy eri maat listattuna.

 

[demu]

Kun Cisco on siltaavana, Telian tarjoamat IP-osoitteet (5 kpl?) loppuvat kesken kun wlaniin kirjautuu liian monta käyttäjää?
Nyt jokainen kytkimen takana oleva laite vie omansa ja wlan käyttäjät myös (elleivät ole reitityksen/NATin takana).

Laita edgerouter reitin+NAT heti Ciscon taakse.

 

[Algron28]

Kun Cisco on siltaavana, Telian tarjoamat IP-osoitteet (5 kpl?) loppuvat kesken kun wlaniin kirjautuu liian monta käyttäjää?
Nyt jokainen kytkimen takana oleva laite vie omansa ja wlan käyttäjät myös (elleivät ole reitityksen/NATin takana).

Laita edgerouter reitin+NAT heti Ciscon taakse.

Wan on kytkimissä kuljetettu omassa virtual-lan:issa joten wan puolella ei (ainakaan pitäisi) liikkua muut kuin edgerouterien ja telian välistä liikennettä omassa vlanissaan.

 

[Algron28]

Ei ollut ongelma dns palvelimessa. Konffasin hp-kytkimeen port mirrorin ja tökkäsin perään koneen jossa wireshark. En kerennyt tuota hetkeä loggaamaan kun tuo katkos iskee mutta näyttäisi että sen jälkeen wan puolella kulkee wain Telian puolelta tulevia arp-kyselyitä ja reitittimistä lähteviä dns kyselyitä joihin ei näyttäisi tulevan vastausta. En ole mikään wireshark mestari sitten.

 

[Stanley H. Tweedle]

Telia onnistunut laajentamaan ongelmansa koskemaan myös muita nimipalvelimia?

SÄPO:n servereissä ruuhkaa?

 

[Lagittaja]

Kun Cisco on siltaavana, Telian tarjoamat IP-osoitteet (5 kpl?) loppuvat kesken kun wlaniin kirjautuu liian monta käyttäjää?
Nyt jokainen kytkimen takana oleva laite vie omansa ja wlan käyttäjät myös (elleivät ole reitityksen/NATin takana).

Laita edgerouter reitin+NAT heti Ciscon taakse.

Ei..

Hänellä nettiyhteys kulkee hallittavien kytkimien läpi VLANissa reitittimille. Relevantti Google haku olisi "router on a stick".

 

[Algron28]

Huomasimpa kun tuossa tutkailin tuota wireshark logia että HP:ssä on jäänyt spanning tree päälle tuohon ciscoon menevään porttiin (ja sitähän se ei tarvitse). Kun nappasin sen pois alkoi data liiikkua. Liekkö tuossa ollut ongelma.

nämä ongelmat alkoivat pari viikkoa sitten kun telia teki jonkun isomman huollon kun netti oli monta tuntia päivällä mykkä. Samaan aikaan alkoi niitä ARP-kyselyitä puskea verkosta päin minulle ja niitäkään aikaisemmin ei ole tullut. Eli jotain on muutettu Teliankin suunnalta. Lisäksi tuo spanning tree on ollut päällä varmaan siitä asti kun tuo modeemi on siirretty nykyiseen paikkaansa eli yli vuoden päivät.

Tämän jälkeen liikenne toimi parikymmentä minuuttia mutta tuo toinen routeri jossa vielä Telian DNS lakkasi toimimasta mutta nyt tuo toinen jossa eri DNS jatkoi toimintaansa. Muutin tuohon toiseenkin erin DNS:n käyttöön. pitää nyt tarkkailla poistuiko ongelma ja antaa tuon wiresharkin logata

 

[Algron28]

Tuo paransi tilannetta huomattavasti mutta näyttää että edelleen ajoittain käy jonkinlainen katkos.

Se vaikuttaisi olevan nyt paljon lyhyempi mutta kuitenkin niin pitkä että toisessa edgerouterissa olevan openvpn clientin tunneli kyykkää ja pitää resetoida ja toisen edgerouterin perässä oleva IPFS node kyykkää myös. Muu liikenne jälkimmäisen edgerouterin perässä toipuu kuitenkin hyvin nopeasti.

Mitenhän tuota kannattaisi seuraavaksi tutkia? Jos paketteja meinaa syynätä pitäisi keksiä joku järkevä capture filter että se pakettimäärä pysyy järkevänä. Mietin myös että joku ohjelma mikä pingaa vaikka googlen dns palvelinta x-sekunnin välein ja loggaa ylös kun ei mene perille olisi hyödyllinen. Noita ohjelmia näytti googletuksella olevan yks jos toinenkin mutta onko kellään suosituksia? Mieluusti linuxissa toimiva mutta paremman puutteessa windowskin käy.

 

[Algron28]

Tämä ongelma vaivaa vieläkin joskin tämän lisäksi Telialla on ollut kaikkea muutakin ongelmaa kaapeli-tv:nsä kanssa. Vittu mitä paskaa sanon minä. Telian asiakaspalveluun soiteltu asiasta parikin kertaa ja parin päivän päästä on tullut tekstiviesti että vika korjattu. Niin, ne pahimmat ongelmat eli se jos ei toimi ollenkaan.

Mitenkähän tätä nyt voisi sitten itse diagnosoida eteenpäin? Alkaa pikkuhiljaa vituttamaan tämä huonosti toimivuus. Pari asiaa mitkä itsellä ihmetyttää:

1: Telian DHCP jakaa huonosti IP osoitteita. Reitittimet saavat aina osoitteensa kyllä takaisin kun käynnistävät uudelleen mutta siinäkin välillä kestää (DHCP jakaa saman osoitteen joten lienee muistissa mac. toisaalta meneehän siinä hetki ennen kuin hallinta vastaa että tiedä kauanko reititin kerkeää kysellä) mutta kun koitin läppäriä liittää suoraan modeemiin niin kesti minuutti tolkulla ennen kuin läppäri sai IP:n. Wiresharkilla kun tarkistelin tapahtunutta niin läppäri kyllä lähetteli discovery viestejä ja verkosta tuli offer viestejä mutta muuten ei tapahtunut mitään.

2: Onko kaikki samassa KTV-segmentissä olevat kaapelimodeemit tai ainakin niiden broadcast liikenne samassa aliverkossa? Ihmettelen vain tuota DHCP liikenteen määrää mikä näyttää kirjautuvan tuohon wiresharkin loggaukseen että ainakin offer viestejä sieltä puskee tulemaan. mukana myös muuta DHCP liikennettä.

Alla kaavio miten siis nyt kytketty.

 

[Algron28]

Noniin, Systeemi on tuossa ensimmäisen päivän jauhanut ja jauhaa vieläkin. Tämä menee jo aika yksinpuheluksi, mutta kirjoittelempa jos tästä vaikka jollekkin joskus hyötyä on.

Eli. Modeemin perässä ei ole tänään ollut kuin tuo zyxel ja nuo kaksi läppäriä. Reitittimet on olleet irtikytkettyinä ja minä olen riutunut mokkulahteyden perässä.

Tuossa Linux läppärissä on scripti joka pingaa www.google.fi osoitetta 5 sekunnin välein ja mikäli ping ei mene läpi se kirjaa kellonajan ja päivämäärän erilliseen logitiedostoon. Klo 18 jälkeen alkoi yksittäisiä rivejä logiin ilmestyä mutta tuossa kahdeksan jälkeen sittin yhteys taas alkoi jumia kunnes liikenne lakkasi kokonaan.

En ole tuota vielä wiresharkilla päässyt tarkemmin kattelemaan sillä logitan vielä siinä toivossa että näkisi palautuuko tuo ollenkaan itsestään. Mutta tällä hetkellä siellä menee vain jatkuvaa www.google.fi DNS kyselyä (Telian DNS käytössä tässä hommassa, joo, on paska, mutta eipähän telia voi sanoa että kolmannen osapuolen homm ei toimi) johon ei tule vastausta. Myöskin satunnaista DHCP requestia Telian reittimelle havaittavissa mutta noihin ei myöskään tule mitään vastausta joitain satunnaisia ACK paketteja lukuunottamatta.

Modeemin linjavalot ovat päällä kaikki enkä ainakaan ole havainnut että olisivat käyneet poissa. Logejahan tuossa ei siltaavassa tilassa taida olla.

Eli voisin nyt sanoa näin harrastelijana sanoa että vähän tuntuu että vika ei ole kyllä minun reitittimissä eikä konffeissa vaan joko tuossa ciscon modeemissa tai Telian verkossa.

Edit: Tuota olen kans miettinyt että logatusta liikenteestä päätellen tuolla Telian verkossa näyttää olevan useampi DHCP. Läppäri koittaa huhuilla 10.14.8.54 mutta välillä tulee offer paketteja aivan toisesta IP:stä 10.20.144.1

 

[Algron28]

Ei näytä itsestään palautuvan tuosta verkkokatkoksesta tuo kone. Eli kun verkko yhteys jumiin niin liikenne ei palaudu normaaliksi ainakaan tunneissa. Eli piti käyttää Linux läppärin päästä verkkokaapeli irti ja tökätä takaisin paikalleen ja liikenne rupesi taas rullaamaan. Meni jumiin siis illalla ja annoin yön pyöriä josko korjaisi itsensä.

Noita paketti logeja tuosta kattelin niin välillä näkyy aikalailla uudelleenlähetyksiä purskeina. Tuo .249 päätteinen on tuon Linux koneen osoite.

Tosin varsinainen hetki kun yhteys jumii niin ai siinä ainakaan omasta mielestäni mitään erityistä näy ainakaan omaan silmään. Ping ja DNS vain lakkaavat vastaamasta. ja mitä manuaalisti kokeilin niin kun se liikenne katkeaa niin myöskään manuaalinen ping esim 8.8.8.8 osoitteeseen ei mene läpi.

Aamulla katsoin Telian sivuja ja ei ollut mitään vikailmoitusta mutta kun koitin soittaa asiakaspalveluun niin siellä pyöri nauhote viasta alueella niin en sitten jaksanut alkaa jonottamaan. Onhan se tietenkin ikävää jos sivuilla näkyy kovinkin paljon vikoja niin mitäpä sitä tietoa sinne laittamaan.

Aamun jälkeen on taas pelittänyt toistaiseksi ja pitää antaa vaikka vapun yli tuon hyrrätä.



EDIT: ja niin, tuosta on logista on suodatettu ARP ja NTP (portti 123) pois koska mikäli tätä ei tehe niin ainakin ARP liikennettä puskee Telian verkosta siinä määrin että tuosta loggauksesta tulee raskasta.

 

[Algron28]

Ja täällä Mein Kampf jatkuu. Eilisen päivän toimi ihan kohtuudella (kaikki muut kaapelimodeemikäyttäjät viettämässä vappua?) mitä nyt ajoittaista ping failedtia tullut, mutta ei kertaakaan niin että olisi mennyt täysin jumiin

Spoileri: Logia

Ping failed at 2018.05.01-08.52.21

Ping failed at 2018.05.01-08.53.42

Ping failed at 2018.05.01-08.53.57

Ping failed at 2018.05.01-08.54.22

Ping failed at 2018.05.01-08.55.44

Ping failed at 2018.05.01-08.55.59

Ping failed at 2018.05.01-09.02.15

Ping failed at 2018.05.01-09.19.08

Ping failed at 2018.05.01-09.31.27

Ping failed at 2018.05.01-10.12.18

Ping failed at 2018.05.01-10.49.20

Ping failed at 2018.05.01-10.50.11

Ping failed at 2018.05.01-10.50.26

Ping failed at 2018.05.01-10.52.03

Ping failed at 2018.05.01-11.22.23

Ping failed at 2018.05.01-11.53.59

Ping failed at 2018.05.01-12.15.49

Ping failed at 2018.05.01-12.46.04

Ping failed at 2018.05.01-13.39.00

Ping failed at 2018.05.01-14.00.51

Ping failed at 2018.05.01-14.20.33

Ping failed at 2018.05.01-16.00.23

Ping failed at 2018.05.01-16.37.36

Ping failed at 2018.05.01-16.42.07

Ping failed at 2018.05.01-16.50.41

Ping failed at 2018.05.01-17.01.14

Ping failed at 2018.05.01-17.47.38

Ping failed at 2018.05.01-17.50.26

Ping failed at 2018.05.01-18.11.45

Ping failed at 2018.05.01-18.40.03

Ping failed at 2018.05.01-18.42.51

Ping failed at 2018.05.01-18.52.07

Ping failed at 2018.05.01-18.58.55

Ping failed at 2018.05.01-19.16.57

Ping failed at 2018.05.01-19.24.16

Ping failed at 2018.05.01-20.08.34

Ping failed at 2018.05.01-20.13.55

Ping failed at 2018.05.01-20.18.15

Ping failed at 2018.05.01-20.29.43

Melkein jo uskoin että olisiko voinut tulla kuntoon. Mutta keskiviikko taas palautti todellisuuteen. Koko yön melko samanlaista logia kunnes aamulla siinä 10 jälkeen alkoi tulla pidempiä pätkiä kunnes sitten puolenpäivän jälkeen iski jumiin.

Soitto Telian vikanumeroon ja sieltä sitten kehoittivat hakemaan paikallisesta Telia liikkeestä toista modeemia lainaan.

Teliakauppaan ei tietenkään voinut soittaa että olisi kysynyt onko niillä modeemia vapaana ettei turhaan lähde käymään paikanpäällä ja jonottamaan pitkään paikanpäällä. Pistin siis renkaat alle ja lähdin käymään.

Modeemit oli kaikki lainassa. Lainaajia ennen minua oli jonossa parikymmentä. Parikymmentä lainaajaa? Ei hemmetti, tuossa menee kuukausia, Totesin harmistuneena. Vaihtoehtoja ei hirveästi enää tässä vaiheessa ollut kerta en halunnut liittyä pitkään listaan muiden toivottomien kanssa.

Seuraavaksi askeleeksi jäi siis hommata jostain muualta toinen modeemi. Mitä itse olen katsellut niin vaihtoehtoja ei hirveästi vaikuta olevan. Verkkiksen ja muiden myymä Fritz!box vaikutti laadukkaalta laitteelta, mutta mikäli ymmärsin oikein niin kyseistä parinsadan euron hintaista kampetta ei saa edes siltaavaan tilaan.

Tilasin siis Telialta uuden kaapelimodeemin, joko technicolor-matolaatikko koska tuon sai ainakin siltaavaan tilaan. Saa nähdä minkälainen romu kyseessä on. Muuta modeemia heillä ei kuulemma ollut myynnissä.

 

[dot1q]

Moi!
Tää on nyt sellasta sokkona perään ja "mutua" tulee.. Mutta mutta. Piirrosten ja kirjoitusten innoittamana kysyn:

Kun työasemasi saa (lnx työasema) DHCP:ltä uutta osoitetta, niin päivittyykö sen työaseman ARP tiedot oikein? Mä en ole windows maailmasta paljon pompannut linuxin puolelle mutta jos winkkarissa työasemalta kysyy mitkä ovat sen ARP tiedot, se listaa ekaksi oletusyhdyskäytävän ARP tiedon ja kertoo onko se dynaaminen vai staattinen tyypiltään.

näin:
C:\>arp -a

Interface: 10.10.70.151 --- 0x2
Internet Address Physical Address Type
10.10.70.1 1c-e8-5d-58-13-c1 dynamic
jne jne jne tässä välissä muitakin saman aliverkon laitteita.
224.0.0.22 01-00-5e-00-00-16 static
224.0.0.251 01-00-5e-00-00-fb static
224.0.0.252 01-00-5e-00-00-fc static
232.44.44.233 01-00-5e-2c-2c-e9 static
239.255.255.250 01-00-5e-7f-ff-fa static
255.255.255.255 ff-ff-ff-ff-ff-ff static

JOS verkko on särki eli rikki, se ei välttämättä rekisteröi sitä sun clientin ARP tietoa operaattorin reitittimelle JA tällöin sinun työasemallasi ei näy listautuneena tuota oletusyhdyskäytävän ARP tietoa.

Tällöin vika on operaattorin runkoverkon konfiguraatiossa. Tunnistaisin tämän tyyppisen vikatilanteen siitä että minulle listautuisi tuossa kohtaa - kun vika on päällä - tällainen arp listaus työasemalle

C:\>arp -a

Interface: 10.10.70.151 --- 0x2
Internet Address Physical Address Type
224.0.0.22 01-00-5e-00-00-16 static
224.0.0.251 01-00-5e-00-00-fb static
224.0.0.252 01-00-5e-00-00-fc static
232.44.44.233 01-00-5e-2c-2c-e9 static
239.255.255.250 01-00-5e-7f-ff-fa static
255.255.255.255 ff-ff-ff-ff-ff-ff static

JA jos wiresharkkaan liikennettä, näen että DHCP requesti menee läpi (kuten sinullakin näyttää menevän jos oikein tulkitsin listaa, tosin 2-3 vuoteen en ole sharkannut..) MUTTA ARP kyselyt, joita työasemani tekee - eivät saa verkosta koskaan vastausta. Eli niitä näkyy vain yhteen suuntaan - clientiltä verkkoon päin. Mutta verkosta päin niiihin viesteihin ei tule yhden yhtäkään vastausta.

Joskus jouduin korjauttamaan operaattorilla tuollaista vikaa, mutta se oli tosiaan operaattorin omassa laitteistossa ja missä kohtaa se oli - buziness salaisuuksia eivät kertoneet. Mutta pitipä vääntää kättä tuon kanssa että tuli kuntoon.

 

[Algron28]

Moi!
Tää on nyt sellasta sokkona perään ja "mutua" tulee.. Mutta mutta. Piirrosten ja kirjoitusten innoittamana kysyn:

Kun työasemasi saa (lnx työasema) DHCP:ltä uutta osoitetta, niin päivittyykö sen työaseman ARP tiedot oikein? Mä en ole windows maailmasta paljon pompannut linuxin puolelle mutta jos winkkarissa työasemalta kysyy mitkä ovat sen ARP tiedot, se listaa ekaksi oletusyhdyskäytävän ARP tiedon ja kertoo onko se dynaaminen vai staattinen tyypiltään.

näin:
C:\>arp -a

Interface: 10.10.70.151 --- 0x2
Internet Address Physical Address Type
10.10.70.1 1c-e8-5d-58-13-c1 dynamic
jne jne jne tässä välissä muitakin saman aliverkon laitteita.
224.0.0.22 01-00-5e-00-00-16 static
224.0.0.251 01-00-5e-00-00-fb static
224.0.0.252 01-00-5e-00-00-fc static
232.44.44.233 01-00-5e-2c-2c-e9 static
239.255.255.250 01-00-5e-7f-ff-fa static
255.255.255.255 ff-ff-ff-ff-ff-ff static

JOS verkko on särki eli rikki, se ei välttämättä rekisteröi sitä sun clientin ARP tietoa operaattorin reitittimelle JA tällöin sinun työasemallasi ei näy listautuneena tuota oletusyhdyskäytävän ARP tietoa.

Tällöin vika on operaattorin runkoverkon konfiguraatiossa. Tunnistaisin tämän tyyppisen vikatilanteen siitä että minulle listautuisi tuossa kohtaa - kun vika on päällä - tällainen arp listaus työasemalle

C:\>arp -a

Interface: 10.10.70.151 --- 0x2
Internet Address Physical Address Type
224.0.0.22 01-00-5e-00-00-16 static
224.0.0.251 01-00-5e-00-00-fb static
224.0.0.252 01-00-5e-00-00-fc static
232.44.44.233 01-00-5e-2c-2c-e9 static
239.255.255.250 01-00-5e-7f-ff-fa static
255.255.255.255 ff-ff-ff-ff-ff-ff static

JA jos wiresharkkaan liikennettä, näen että DHCP requesti menee läpi (kuten sinullakin näyttää menevän jos oikein tulkitsin listaa, tosin 2-3 vuoteen en ole sharkannut..) MUTTA ARP kyselyt, joita työasemani tekee - eivät saa verkosta koskaan vastausta. Eli niitä näkyy vain yhteen suuntaan - clientiltä verkkoon päin. Mutta verkosta päin niiihin viesteihin ei tule yhden yhtäkään vastausta.

Joskus jouduin korjauttamaan operaattorilla tuollaista vikaa, mutta se oli tosiaan operaattorin omassa laitteistossa ja missä kohtaa se oli - buziness salaisuuksia eivät kertoneet. Mutta pitipä vääntää kättä tuon kanssa että tuli kuntoon.

Pitääs tuota vähän kattoa mutta kuulostas ihan mahdolliselta. Tosin silloin kun netti jumii niin dhcp ei mene läpi. Mitä tuossa alemmassa kuvassa näkyy tuo dhcp niin se ei ole minun koneen vaan jonkun toisen telian koneen dhcp jos muistan oikein kun mac pakettien mac osoitteesta katoin. Oman läppärin käyttis koittaa huhuilla .54 päätteistä dhcp palvelinta eikä liikennöinyt tuon .1 päätteisen kanssa.

Tuo arppi homma on enemmän kuin mahdollista. Koska kaikki muu paitsi broadcast liikenne katkeaa. Eli Telian verkko jossain kohtaa "unohtaa" että nämä päätelaitteet oli täällä. Dhcp ilmeisesti toimii niin että ennenkuin lease päättyy client kyselee jatkoa vain siitä osoitteesta mistä dhcp palvelin aikaisemmin vastasi. Mutta kun lease umpeutuu tulee uusi kysely broadcastina jolloin Telian reititin taas hoksaa että "ai niin, nää on tuolla" ja liikenne toimii taas.

Tuo selittäisi sen arp liikenteen (who has ip x, tell y) määrän mikä tuolta Telian verkosta tulee.

 

[dot1q]

Juu DHCP menee just noin että kun 50% leasea jäljellä, se koittaa uusia Saman käyttämänsä osoitteen Samalta palvelimelta josta se on sen saanut.

Muistaakseni loput meni näin:

Kun 25% jäljellä, se alkaa kysyä samalta palvelimelta osoitetta (mutten nyt muista kysyykö taas samaa vai sitten jo jotain muuta).
Kun 15% jäljellä, se kysyy samalta serveriltä mitä tahansa osoitetta.
Kun 0% jäljellä, se huutaa kenelltä tahansa mitä tahansa osoitetta.

Itsellä toi tuli vastaan niin että sama tietokone toimi jossain toisessa paikassa ok, mutta tietyssä kohteessa taas haistatti pitkät. Ei millään pelannut. Ei vaikka käsin liimasi DefaultGatewayn ARP tiedon (static leimalla) winkkariin - ei auttanut. Koska verkko ei ollut rekisteröinyt sitä clienttiä että mistä se clientti löytyy.

Tsemppiä vian hakuun, jos tästä on kyse, on tämä vaikeampi tapaus diagnosoitavaksi. Ei helppo heillekään.

Tuon vian aikanen ARP taulu työasemalta kertoo siis lisää. Winkkari työasema SAI IP:n perille asti DHCP:ltä jaettuna. Eli sen verran erilainen tapaus se.

 

[Algron28]

Pitää tuota arppia kattoa kun tuo vika taas iskee päälle. tuon arppiliikenteen monitorointi kokoaikaisesti on ongelma kun sitä paketti virtaa tulee sieltä telian verkosta niin paljon. Ja kun se on broadcast liikennettä se tulee läpi silloinkin kuin unicast liikenne on seis.

Kyseisen kuvan aikana modeemiin oli kytketty vain port mirror kytkin sekä sen perään tyhmä mediamuunnin pitämään porttia ylhäällä.

 

[dot1q]

Sähän voit suodattaa tuota näkymää wiresharkista sisällyttämällä sääntöjä siihen että mitä info kentässä lukee. Valkkaa siihen vain sinun tietämiäsi tässä tarvittuja osoitteita käyttöön. esim. GW:n ip, sun kohdelaitteen MAC osoite. Muuten tuossa on tosiaan tauhkaa ihan järjettömästi.

 

[Algron28]

Olen tuossa aikaisemmin pähkäillytkin jo tuon filtteröinnin kanssa ja lähinnä huomioinut sen että pidemmissä capturoinneissa jos (kun) tulee paljon paketteja niin menee tuo kone juntturaan helposti sen capturoinning jälkeen kun alkaa käymään läpi. Olisi siis hyvä jos saisi jo capture filtteriin laitettua joitain rajauksia mitä liikennettä ei tarvi logata. Noissaki oli eroja mitä pystyi capture filterillä rajaamaan ja mitä display filterillä.

 

[dot1q]

Oletko jakanut capturetiedostot pienempiin pätkiin?
Jos et, kannattaa laittaa joku 100Mt kooksi per kaappaustiedosto. Se sujuvoittaa mielestäni sovelluksen toimintaa.

 

[Algron28]

Oletko jakanut capturetiedostot pienempiin pätkiin?
Jos et, kannattaa laittaa joku 100Mt kooksi per kaappaustiedosto. Se sujuvoittaa mielestäni sovelluksen toimintaa.

Oliko tuossa lie jotain asetusta että se tekisi automaattisesti useita pieniä tiedostoja. En löytänyt äkkiä eikä netissäkään ollut kuin puhetta jostain ulkoisesta softasta. Ilmeisesti tuo wireshark tarvii 10 kertaisen määrän ram muistia siihen capture tiedoston kokoon nähden.


Uusi modeemi saapui. Katotaampa miten toimii, ainakin n. Tunti asennuksen jälkeen oli jumissa mutta saas nähdä. Mitä tuota logia tarkistelin niin nyt on oikeastaan yllättävän hyvin tuo vanhakin toiminut vaikka ping failia tullut jonkun verran niin jumiin ei mennyt eilen eikä tänään.

Aika halvan oloinen tuo technicolor. Hallintaa en tutkinut pidemmälle kuin että nappasin sen siltaavaan tilaan. Pitää ehkä jotain laittaa tuohon alle että ilma pääsee virtaamaan paremmin läpi.

 

[dot1q]

wau, kuitua 6 paria LC liittimin, OS2 oletan.
Mutta tästä kohtaa mä olen sen paketteihin jakamisen tehnyt. 8Gt ram/16Gt ram jompsis kumpsis + i7 cpu on riittäny toi 100megan koko ihan mukavasti.

Sitten sitä listan suodatusta tuolla "filter" kohdan optiolla isoon massaan niin näkee oleelliset. Kannattaa ensin listauttaa joku helppo juttu - jotta näkee miten filter kohdan suodatus rakentuu. Seuraavaksi tekee jonkun vaikeamman mutta yksilöivämmän suodatuksen tuohon jotta wildcard muotoilun päälle alkaa ymmärtää.

 

[Algron28]

wau, kuitua 6 paria LC liittimin, OS2 oletan.

Tuo taitaa olla OS1. Kuidun tyyppi FRMSU. Sisäverkon kaapeleita.



Eipä se tuo modeemin vaihto ratkaissut ongelmaa. Edelleen on ongelmia taas siinä että Telialta ei saa IP osoitetta toinen reititin ja nyt sitten tuo testiläppärikään.

Testikytkentää on muutettu näin:

Tuossa liitteenä wireshark capture ilman filtteröintiä jos joku osaavampi haluaa vilkaista. Heti käynnistyksen jälkeen molemmista ER reitittimistä enabloitiin WAN portit jolloin ne alkoivat huhuilla IP:tä Telialta. Ainoastaan toinen, se joka oli aikaisemmin ennen muutosta ollut verkossa sai IP:n. Toinen ollut irtikytkettynä jokusen päivän.

Ping läppäri on IBM (mac osoite) ja myös se ei saanut IP:tä tuon muutoksen jälkeen. Molemmat jatkaa huutelua mutta Telian verkko ei reagoi mitään.

 

[dot1q]

En nyt mikään varsinainen velho ole tuossa hommassa mutta katsotaan. Nopean vilkaisun jälkeen tiedän että sun linuxilla toimivan laitteen nimi on ilmeisesti "linux7" ja sen mac osoite on ilmeisesti 44:d9:e7:9e:85:87. Sun HP kytkimellä tai jollain muulla on CDP:n sijaan valmistajariiippumattomampi vastaava toiminto päällä (LLDP) mutta se ei ny haittaa mitään.

Tein tuosta "follow stream" toiminnolla automaattisesti tämmöisen haku loitsun:
(ip.addr eq 0.0.0.0 and ip.addr eq 255.255.255.255) and (udp.port eq 68 and udp.port eq 67)
Eli se näyttää kaikki 0.0.0.0.0 tai 255.255.255.255 osoitteella luodut udp portteihin 68 ja 67 osuvat paketit..

Nopsaan kun noita kattelee, niin noin 9 sec välein sun laitteet pyytää DHCP:ltä osoitetta. Mutta mutta. Tuossa on vaan perus ARP tauhakaa tuon lisäksi mukana. Sun laitteet ei näytä saavan _mitään_ vastausta DHCP pyyntöön .
3 laitetta näin pyytelevän osoitetta:

numero 73. 78:8a:20:bc:11:77 6.3 sec (Joku Ubicuiti laite?)
numero 113. 00:11:25:80:d5:d3 10.3 sec (IBM)
numero 163. 44:d9:e7:9e:85:87 14.9 sec (linux7)

Nämä huutelee DHCP:ltä osoitetta pakettiin numero 469 asti. Siinä tapahtuu muutos. Transaktio id:llä 0x12fbde82, 44:d9:e7:9e:85:87 laite (linux7) huutaa ajassa 42.2871830 DHCP serveriltä (miltä tahansa) osoitetta itselleen. Tässä kohtaa osoitehuuteluun tulee vihdoin vastausta.

Ajassa 43.3108120 bootp protokollalla tulee vastaus serveriltä 2c:ab:eb:27:f0:19 serverin IP taitaa olla 10.20.144.1 (eipäs kun tämä taitaa olla 10.14.8.54)
bootp vastauksen sisältö kertoo että:
Clientille tulee osoite (siis sun koneelle) 80.220.155.215.
Clientille tulee gatewayksi "relay agent" 80.220.152.1 (joo tää vahvistuu bootp paketin sisällä myöhemmin jotta tää on Router ip)
Osoitteen lease aika on VAIN 30 minuuttia. Winkkarit kysyy siis 15min välein jo jotta saako jatkaa samalla IP:llä...
CLientin aliverkon peite (subnetmask) on 255.255.252.0
DNS:ät on paketissa tarjottu olevan 193.210.19.19 ja 193.210.18.18)
domain name on cable.inet.fi

Tuohon serverin vastaukseen sun clientti reagoi näin:
Pyydänpä uudestaan DHCP:ltä osoitetta (wtf?) Nyt menee yli mun ymmärryksen. Ihan käsittämätöntä. Juurihan tämä sai osoitteen perille ja siinä nähdäkseni kaikki validi tieto tarjolla.

Ok. Sitten serveri vastaa heti perään uudestaan. Sun clientti saa ihan eri osoitteen nyt kuin viimeksi. Mutta muut arvot ovat samat. Se on sinänsä loogista, koska (katso tämän alla olevan kuvan alla)

sun tietokone pyysi ihan _sokkona_ tuota uutta IP:tä itselleen:

Se ei ollut käsitellyt serveriltä tullutta pakettia mitenkään kun se pyysi tuota osoitetta uudestaan heti sen saatuaan...
Katsotaanpa kuittaako se laite nyt serverille että "joo, kiitos, sain osoitteen.. Voinko siirtyä käyttämään sitä?"
Muistiin se että nyt tarjotu IP on 80.220.153.198. Edellinen osoite oli 80.220.155.215.

Eli nyt tutkitaan nämä paketit mitä sieltä tuli "ACK":na takasin. Paketit A ja B eli ID:T 473 ja 474

Paketti A (473) kertoo seuraavaa:
DHCP serveriksi epäilemäni laite 10.20.144.1 vastaa laitteelle 80.220.155.215 (tässä on jotain tuttua. Tämähän oli se eka osoite jota sun laitteelle tarjottiin) seuraavaa:

Käytä client osoitteena osoitetta 80.220.155.215 samat jargonit kuin aiemminkin siis. Ja 30minuutin DHCP lease.

Paketti A tutkittu. Mites sitten toi paketti B.

Muuten identtinen kuin paketti A, mutta nyt tuleekin Option 51 kohdassa (lease time) DHCP leaseen ajaksi 12tuntia!

Sekunnit olivat tässä kohtaa wiresharkaamisen alkamisesta edenneet 43 sekunnin kohdalle. Mä en nyt ihan muista ulkoa miksi tapahtuisi noin että tarjotaan ensin vaan 30min leasea ja sitten 12h. Ömityistä. En osaa kommentoida tätä sen enempää. Jos tuntisin linux dhcp serveriä paremmin (eli öö edes yhtään pätkän vertaa), voisin ehkä ymmärtää mistä on kyse.

Sen jälkeen näen vain kaks osoitteen pyyntöä hetkeen.. IBM ja se kolmas kampe pyytää osoiteta muttei näytä heruvan vastauksia.

Edetään aina 53 sekuntiin asti. Juur ennen NTP pyyntöään, jonka sun IP.n saanut kone tekee, sun kone vastaa toisen koneen ARP kyselyyn (joku kyselee default gatewaytä, en tutki tätä enempää)

Paketin 586 kohdalla sun kone, joka sai IP:n 80.220.155.215, kyselee NTP:llä aikaa itselleen. Se kysyy sitä serveriltä 192.89.123.26 ja saa ihan sekunnin osissa vastauksen tuolta serveriltä. Sisältö näyttää validilta mun silmään molemmissa paketeissa.

Sekunnin päästä tapahtuu sama homma uudestaan. NTP kuvion tarkkuutta en tiedä että onko tämä vaan "just in case" eka meni pieleen, tehdään toinen. Vain pieniä eroja kellonajoissa ja reference serverin ip osoitteissa. Normaalia. Tähän oikeastaan jäljet päätty NTP:tä toi huutelee tuosta eteenpäin.

IMHO; DHCP palvelussa tai sen viestien välittämisessä on jotain vikaa. Ehkä serveri on ruuhkaantunut yleisesti ottaen joko CPU/RAM/osoitepulan takia?
Mä katson vielä mitä toi osaa kertoa _vain_ sinun tuon linux7 vekotteen osalta. Lähinnä tuosta kohtaa missä se saa se kone DHCP:ltä vihdoin vastakaikua.

 

[dot1q]

tohon ylläolevaan meni sitten oikeesti joku +1h tässä arki-illan oheistoimintoina..

ARPin osalta huomiona että nyt mua kiinnostaa jäljittää ensisijaisesti siis koko polku tuon 0x12fbde82 transaktio id:n osalta. Tongin sitä alkuunsa. Mistä se oikeasti alkaa, onko sun laitteella ollut jo joku ip vai ei ja mikä se on ollut. Onko sillä ollut ARP kyselyitä jne ja tuleeko sillä uudella olemaan jotain ARP huuteluja..

 

[dot1q]

Ohhoh. Tää alkoi jo näemmä 14 sek kohdalla tää homma transaktio id:n perusteella. Laitteella onkin näemmä ollut jo osoite aiemmin. Se pyytää uusimaan tuota samaa itselleen 80.220.153.198. Tähän uusimispyyntöön ei tule vastausta. Tässä kohtaa laite näyttää pyytävän jo miltä tahansa serveriltä vastausta.

20 sek kohdalla seuraavan kerran ilmenee saman transaktio id. Se pyytää taas samaa osoitetta uudestaan.. Hmm. Toi sanoo molemmissa paketeissa laitteen hostnameksi RVN-OURI-R02

28 sek kohdalla. Taas sama räbä.

Tämän perusteella en itseasiassa ala tuota ARP puolta enempää tonkimaan. Mielipiteeni on että ongelma on dhcp toiminnoissa, ei ARP puolella. My 50cent.

 

[Algron28]

Tuhannesti kiitoksia @dot1q kun jaksoi tuota hieman avata ja käyttää lauantaita tähän.

Edgerouterien mac osoitteet on
Source: Ubiquiti_bc:11:77 (78:8a:20:bc:11:77)
Source: Ubiquiti_9e:85:87 (44:d9:e7:9e:85:87)

Linux kone on se ibm. Se on sellainen vanha räpsy jonka kaivoin tähän ja siinä on Linux lite.

Osittan tuo varmaan liittyy tuohon DHCP ongelmaan mutta en ole ihan varma onko se ainoa ongelma. Ainakin tuota DHCP lease aikaa on pienennetty sillä muistelisin että vielä joitain viikkoja sitten se olisi ollut peräti 7 päivää.


Resetoin modeemin ja sen jälkeen reitittimet ja läppärin ja nyt taas kuso kulkee toistaiseksi. Pitää taas jäädä tarkkailemaan. Telialle tein jo aamupäivällä vikatiketin ongelman jatkumisesta.


Lisäksi huomasin tuossa technicolorin lootassa ärsyttävän ominaisuuden. Mikäli laite ei ole saanut muodostettua WAN yhteyttä verkkoon on laitteen oma DHCP käytössä vaikka laitteesta on valittu siltaava tila(sammuu kun laite saa WAN yhteyden). Näin ollen mikäli esim sähkökatkon jälkeen reititin on noussut ylös ennen kaapelimodeemiyhteyden muodostumista niin se nappaa tuolta modeemin omalta DHCP:ltä 192.168.100.x osoitteen ja sitten ei data liiku ennen kuin lease aika umpeutuu ja uusi osoite haetaan operaattorilta. Pitäisi testata aktivoituuko tuo DHCP myös jos WAN yhteys katkeaa välillä.

 

[dot1q]

Jos DHCP jaot ovat nyt nähtävillä olevan tiedon valossa olleet 168h, 12h ja 0,5h, niin osoitteiden loppuminen taitaa olla se ongelma mikä on verkon toimittajalla, Telialla(?), nyt käsillä. Siihen ei auta muu kuin hankkia lisää osoitteita. se vaan että mistäs niitä IPv4 osoitteita lisää taikovat lol, ei mistään.
Onko sinulla mahdollista siirtyä käyttämään IPv6 puolta? Jos on, ja se pelaa.. voisi olla nopein tie toimivaan verkkoon tässä kohtaa. Jaa mutta toi on kaapelimodeemi kohde. Mahtaako kaapelimodeemiympäristössä olla IPv6 toteutuksia? En tiedä, en tosin ole seurannutkaan. 4G puolella on IPv6 tullut testattua/käytettyä jne joskus. Revertoin takasin IPv4 puolelle koska haasteita oli ja en ole muistanut kokeilla hommaa uudestaan. Sama pää kesät talvet

Edit. niin olehan hyvä, ihan jees kun välillä joutuu verestämään wiresharkkaamista. Ja varsinkin kun näin sokkona toisen aineiston pohjalta joutuu sen tekemään, niin aina parempi.

 

[Algron28]

Voishan tuota ip6 kokeilla. Pitää ensin vähän opiskella kun se ei niin tuttu ole kun sitä ei ole käyttänyt. Aloin vain miettiä että tukikohan se telia kuinka tuota kun ainakin joskus niillä oli pelkkä tunnelointi tarjolla eikä natiivi tukea. Ilmeisesti mobiilipuolella operaattorit tukee jo hyvin.

Vois vaikka tuolla toisella routerilla testailla tuota.

 

[jessenic]

Voishan tuota ip6 kokeilla. Pitää ensin vähän opiskella kun se ei niin tuttu ole kun sitä ei ole käyttänyt. Aloin vain miettiä että tukikohan se telia kuinka tuota kun ainakin joskus niillä oli pelkkä tunnelointi tarjolla eikä natiivi tukea. Ilmeisesti mobiilipuolella operaattorit tukee jo hyvin.

Vois vaikka tuolla toisella routerilla testailla tuota.

Ei taida Telialla olla natiivia IPv6-tukea kuin yritysliittymissä ja sekin lisämaksusta. Mobiilipuoleltakin se uupuu vielä.

 

[rlame]

Minulla ongelmia aiheutti taannoin viallinen kytkin. Suosittelen siis kokeilemaan jokaista lenkkiä ketjussa.

 

[Algron28]

Ei taida Telialla olla natiivia IPv6-tukea kuin yritysliittymissä ja sekin lisämaksusta. Mobiilipuoleltakin se uupuu vielä.

Niinpä tietenkin. Ompas kämyä mutta eipä taas yllätä. Siitä 6rd:stä ei taida olla iloa jos ip4 liikenne ei kulje kuitenkaan.

Minulla ongelmia aiheutti taannoin viallinen kytkin. Suosittelen siis kokeilemaan jokaista lenkkiä ketjussa.

Jokainen lenkki täällä päässä on jo kokeiltu. Kolmella eri asiakaslaitteella samallainen ongelma ja ainoa näille yhteinen verkkolaite on siltaava kaapelimodeemi joka sekin vaihdettu jo kertaalleen.

Nopeaa päivitystä tilanteesta: ongelma jatkuu, mutta jotain on muutettu (tai alkukesäinen sunnuntai on houkutellut kaikki netin käyttäjät ulos). Liikenne jumii edelleen sillointällöin ja ping ei mene läpi tämän tapahtuessa mutta dhcp renew menee läpi ja laittaa liikenteen toimimaan. Tosin nyt vaivaa se että ping pätkii satunnaisen jatkuvasti, useita kertoja tunnissa.

 

[Algron28]

Tarina jatkuu. Telialta soitteli joku ja tarkasteli hieman liittymää. Totesi lopulta että alueella kuulemma saneerataan verkkoa jotta saataisiin sitä paremmaksi. Sanoi että ootella sen valmistuvan ja katsoa sitten josko häiriöt olisivat poistuneet sen myötä.