Uitval modem laat router vastlopen

[ShadowAS1]

Beste tweakers,

Sinds een paar dagen hebben we vreselijke problemen met onze internetverbinding (UPC).
Na uren werk zijn we erachter gekomen dat het modem (alweer) de boosdoener is.. deze is al eens vervangen.

Wat er gebeurt is dat op gegeven moment internet uitvalt, en intern wel gewoon nog werkt. Alles is dan bereikbaar behalve de router. Dat trekt natuurlijk de aandacht naar de router toe. Dit was eerst een D-Link DIR-635 maar die is inmiddels vervangen door een HP ProLiant DL380 G5 met pfSense (binnen VMware ESXi) en die bleef met hetzelfde probleem kampen.

Op gegeven moment kwamen we erachter dat als we het modem (Cisco EPC3925) power cyclen alles weer werkt.

Er is wegens eerdere problemen al eens een monteur langs geweest, deze heeft het signaal getest en kwam tot de conclusie dat het signaal bijna té sterk was. En toen is dus het oude modem vervangen, dus aan het signaal zal het niet liggen.
Nou begin ik me toch af te vragen hoe het kan dat het modem opeens vastloopt en daarmee de router met zich meeneemt?

Een logische stap lijkt me om UPC op te bellen om het modem te vervangen, maar als dit makkelijker opgelost kan worden is het natuurlijk altijd fijn.

Ik moet er wel bij zeggen dat we in een vrij aparte situatie zitten. In eerste instantie kon UPC niet op ons huidige adres leveren, maar op kosten van de gevestigde instelling heeft UPC alsnog een coax de grond in gegraven.

Mijn vraag dus: Hoe kan het dat het modem zonder verklaarbare reden de router laat trippen (maakt niet uit welke router ik gebruik) en wat is een logische actie om nu te nemen?

[Deef_K]

Lange leve de Cisco EPC3925, kijk maar eens op het chelloo forum. Genoeg te vinden over dit slecht stukje hardware.

Ook ik heb regelmatig dat de ssid helemaal weg is, wifi niet werkt, internet er volledig uit.

[Ultraman]

De Cisco EPC3925 is een modem-router, tenzij je deze in Bridge modus hebt gezet. Draai je in Bridge modus of in Routing modus?

Als tegenervaring: Mijn EPC3925 staat in Bridge modus, met een TP-Link TL-WR1043ND met OpenWRT er achter als router, en is prima stabiel te noemen. Signaalwaarden hier verder hartstikke netjes voor zover mij bekend. Huidige uptime in nu een maand zonder probleem.

[ShadowAS1]

Zoals ik al (niet zo heel duidelijk) in de OP vermeldde De Cisco staat in bridge-modus. Ik weet hoe slecht die routing-modus is en zeker de SPI die bij alles roet in het eten gooit.

Het gekke is dat alles normaal gesproken ook perfect werkte in bridge, maar dit probleem is opeens een paar dagen geleden begonnen.

[Ultraman]

ShadowAS1 schreef op donderdag 25 april 2013 @ 11:06:
Zoals ik al (niet zo heel duidelijk) in de OP vermeldde De Cisco staat in bridge-modus. Ik weet hoe slecht die routing-modus is en zeker de SPI die bij alles roet in het eten gooit.

Ok, dan is dat het dus niet.

Het gekke is dat alles normaal gesproken ook perfect werkte in bridge, maar dit probleem is opeens een paar dagen geleden begonnen.

Ah... ja das tricky dan.

[ShadowAS1]

Ja oké, maar wat is dan logisch om als volgende stap te ondernemen?

[jjust]

Ik ken niet zo bekend met pfSense maar zijn er iets van logfiles beschikbaar. Zo ja wat staat daar in. Misschien kan je daar wat terugvinden over wat het probleem met de modem of de router precies is. Het lijkt me raar dat de modem problemen geeft en dan de router niet meer beschikbaar is. Het lijkt me dat deze over het interne netwerk nog steeds beschikbaar moet zijn.

[ShadowAS1]

jjust schreef op donderdag 25 april 2013 @ 15:53:
Ik ken niet zo bekend met pfSense maar zijn er iets van logfiles beschikbaar. Zo ja wat staat daar in. Misschien kan je daar wat terugvinden over wat het probleem met de modem of de router precies is. Het lijkt me raar dat de modem problemen geeft en dan de router niet meer beschikbaar is. Het lijkt me dat deze over het interne netwerk nog steeds beschikbaar moet zijn.

Daar heb ik als eerste gekeken, de router vermeld niets, dat is het rare.

Maar zoals ik al zei: voor pfSense hadden we een D-Link Dir-635, deze gaf exact hetzelfde probleem.

[jjust]

Het lijkt erop alsof de router ook crasht. Waarom zou je hem anders niet kunnen bereiken. Een mogelijke oorzaak zou kunnen zijn dat er veel request worden gedaan b.v. pogingen om te connecten o.i.d. Als dit niet van je eigen netwerk komt misschien dan van de modem. Misschien toch nog eens kijken in je eigen netwerk of alle ip instellingen goed staan. Of bijvoorbeeld ipv6 aangezet is bij een netwerkadapter die request doet aan de router etc. Is er een paar dagen geleden wat veranderd in het netwerk? Anders kan de conclusie niet anders zijn dat het aan de modem ligt.

[ShadowAS1]

IPv6 is uit, verder is het niet dat pfsense crashet o.i.d. het is echt netwerktechnisch, want als ik inlog op de vSphere console (pfSense draait als VM in ESXi) dan kan ik wel gewoon pfSense de opdracht geven om te rebooten. Hij doet dat dan braaf, maar zodra ie gereboot is is ie nogsteeds onbereikbaar tot ik het modem reboot.

[jjust]

Tja dan lijkt het er toch op dat de modem de schuldige is. Hopelijk is UPC zo vriendelijk om hem op korte termijn te ruilen. Dan maar hopen dat een nieuwe modem het probleem oplost.

[Skoefel]

3925 zijn gewoon waardeloze dingen, mijn ervaring ermee is dramatisch. En als je eindelijk iemand "technisch" aan de lijn krijgt naar 20 minuten wordt er eerst gevraagd om in veilige modus of iets dergelijks op te starten. Gewoon zeggen dat er totaal geen verbinding meer is op heel je 3925 is, zodra de monteur komt het probleem uitleggen.. Gaat je veel tijd schelen.

[ShadowAS1]

ik heb net een halfuur met UPC aan de lijn gehangen...
Blijkt dus, dat doordat UPC hier een 1:1 lijn levert. Wij een te sterk signaal hebben..
Nougoed, monteur komt volgende week vrijdag, alleen zitten er nu nog 200 man met gekloot hier de hele week

[jjust]

Dat is ook mooi waardeloos. Toen mijn Ziggo modem stuk was melde ik het 's avonds en stond de volgende dag er een monteur op de stoep. Zo kan het dus ook.

Ben wel benieuwd hoe ze dat gaan oplossen. Blijkbaar kunnen ze het niet remote en moeten ze on site het signaal verzwakken o.i.d.

[Skoefel]

ShadowAS1 schreef op donderdag 25 april 2013 @ 20:09:
ik heb net een halfuur met UPC aan de lijn gehangen...
Blijkt dus, dat doordat UPC hier een 1:1 lijn levert. Wij een te sterk signaal hebben..
Nougoed, monteur komt volgende week vrijdag, alleen zitten er nu nog 200 man met gekloot hier de hele week

Lijkt me heeeeel onwaarschijnlijk...

[dion_b]

ShadowAS1 schreef op donderdag 25 april 2013 @ 20:09:
ik heb net een halfuur met UPC aan de lijn gehangen...
Blijkt dus, dat doordat UPC hier een 1:1 lijn levert. Wij een te sterk signaal hebben..
Nougoed, monteur komt volgende week vrijdag, alleen zitten er nu nog 200 man met gekloot hier de hele week

Ofwel jij hebt verkeerd begrepen wat ze zeiden, danwel heeft degene die je aan de lijn had de meest fantastische lulverhaal opgehangen

Doe eens wat meer harde info geven. Wat lees je qua signaalwaardes uit in de modem (192.168.100.1)?

Verder staat het feit dat de modem uitvalt los van het gedrag van je router(s) als dat gebeurt. Wat een router hoort te doen als z'n WAN down gaat is gewoon vrolijk doorwerken als altijd. Maakt niet uit wat die modem verder doet, dat zou enkel de internetverbinding mogen beinvloeden.

1 uitzondering: een DOCSIS modem die bridge is hoort normaal DHCP requests 1-op-1 te relayen. Maar als een DOCSIS modem z'n verbinding met CMTS kwijt is, gaat hij normaliter zelf een DHCP server draaien in de reeks 192.168.100.0/24 om je in de gelegenheid te stellen met dat ding te verbinden om evt foute instellingen bij te stellen.
Stel nu dat je zelf op je LAN de 192.168.100.0/24 subnet gebruikt, dan is het vrij logisch dat je router over de zeik gaat, aangezien hij dan aan WAN- en LAN-zijde dezelfde IP-reeks heeft en dus niet meer weet wat waarheen gerouteerd moet worden. Zo ja is oplossing om zelf een andere /24 te gebruiken binnenhuis.

[ShadowAS1]

Nee, wij zitten op 192.168.0.0/20
Dus dat valt buiten de DHCP range van dat modem.

Alleen de medewerker van UPC vermeldde dat er één waarde was die sterk afweek van de rest..
En ik zou 't zo geloven als UPC een lulverhaal op heeft gehangen, dat zou niet de eerste keer zijn..

Maar ik snap ook niet waarom die router er dan uit mikt.. want zowel pfsense als de d-link geeft dat probleem, de helft heeft dan ineens internet, de andere helft niet

Om even wat verduidelijking over het netwerk hier op te leveren. Het is een enorm netwerk, met 2 door vlan gescheidde netwerken.
Het netwerk bestaat uit 23 gebouwen en zo'n 300-400 devices op het vlan waar ik aan werk.
Clients zijn zowel wired als wireless, wireless word door een andere partij hier geregeld, dit dmv Juniper APs, worden vanaf het andere vlan beheerd.
Verbindingen tussen de 23 gebouwen door (is een groot terrein) word dmv glasvezel gedaan.
Deze glasverbinding komt in elk gebouw binnen op een Extreme Networks Summit x250e-24p switch. vanuitdaar word het door het betreffende gebouw verspreid via ethernet.

Het modem zit als volgt aangesloten: AOP--->CiscoEPC3925--->UTP Kabel naar Patchpanel punt 21-23--->UTP kabel van 21-23 naar 21-08--->UTP kabel naar wandcontactdoos--->UTP Kabel naar router--->UTP kabel terug naar wandcontactdoos--->UTP kabel naar Switch--->Fiber richting rest van het netwerk.

Een andere opmerking: Zoals dus vermeld word de router onbereikbaar voor de meeste clients zodra het modem vastloopt. Als ik de UTP kabel uit het modem haal, en op een client die geen internet meer heeft mijn DHCP lease vernieuwd doet ie het weer. Maar zodra ik het modem er weer in doe knalt ie er binnen n minuut weer uit.

@dion_b ik denk niet dat ik 't verkeerd begrepen heb, tenminste, als hij letterlijk zegt dat er een te sterk signaal is, ik het dan navraag, en het nogmaals bevestigd word, dan lijkt t mij dat t wel zo is Er was in ieder geval een 'sterk afwijkende waarde die voor een te sterk signaal zorgde'

[ Voor 68% gewijzigd door ShadowAS1 op 26-04-2013 09:46 ]

[jjust]

ShadowAS1 schreef op vrijdag 26 april 2013 @ 09:32:
Nee, wij zitten op 192.168.0.0/20
Dus dat valt buiten de DHCP range van dat modem.


Een andere opmerking: Zoals dus vermeld word de router onbereikbaar voor de meeste clients zodra het modem vastloopt. Als ik de UTP kabel uit het modem haal, en op een client die geen internet meer heeft mijn DHCP lease vernieuwd doet ie het weer. Maar zodra ik het modem er weer in doe knalt ie er binnen n minuut weer uit.

Als de router weer bereikbaar is na een vernieuwing van de DHCP lease en dan weer uitvalt nadat de modem weer op de router wordt aangesloten dan lijkt me dit toch een DHCP probleem. Zoals Dion_b beschreef. Wellicht dat de range die hij noemde toch anders is. Misschien als het nog een keer gebeurd UPC bellen en vragen of de modem gewoon verbinding heeft.

Anders volgende week proberen om een nieuwe modem te scoren.

[ShadowAS1]

jjust schreef op vrijdag 26 april 2013 @ 10:25:
[...]


Als de router weer bereikbaar is na een vernieuwing van de DHCP lease en dan weer uitvalt nadat de modem weer op de router wordt aangesloten dan lijkt me dit toch een DHCP probleem. Zoals Dion_b beschreef. Wellicht dat de range die hij noemde toch anders is. Misschien als het nog een keer gebeurd UPC bellen en vragen of de modem gewoon verbinding heeft.

Anders volgende week proberen om een nieuwe modem te scoren.

Nou, 't is case solved
Ik kwam erachter dat een van de jongeren een beetje aan het experimenteren was dsploit op zn android phone. Alleen had dsploit zijn ip static op 192.168.0.1 gezet, wat dus een IP conflict met de router veroorzaakte.

Neemt nog steeds niet weg dat het modem problemen geeft, maar alles werkt verder weer.

Bedankt voor jullie hulp allen!

[jjust]

Haha die jongen heeft vrienden gemaakt. Gelukkig heb je het gevonden. Hier kan je lang naar zoeken.

[Skoefel]

Fijn dat het is opgelost, toch vind ik een D-Link DIR-635 voor 300/400 devices maar een beetje vreemd...

[ShadowAS1]

Lester Temmink schreef op vrijdag 26 april 2013 @ 17:58:
Fijn dat het is opgelost, toch vind ik een D-Link DIR-635 voor 300/400 devices maar een beetje vreemd...

Tsja, ik heb 't niet bedacht. In die tjid waren er overigens maar een stuk of 50 devices.. is nu een stuk meer. Vandaar dat het nu ook met pfSense geregeld wordt.

[dion_b]

ShadowAS1 schreef op vrijdag 26 april 2013 @ 12:09:
[...]


Nou, 't is case solved
Ik kwam erachter dat een van de jongeren een beetje aan het experimenteren was dsploit op zn android phone. Alleen had dsploit zijn ip static op 192.168.0.1 gezet, wat dus een IP conflict met de router veroorzaakte.

Neemt nog steeds niet weg dat het modem problemen geeft, maar alles werkt verder weer.

Bedankt voor jullie hulp allen!

Maar wat was dan de link met de modem die down ging?

Trouwens, dit geeft mooi aan waarom het handig is om een minder gebruikte /24 te pakken dan 192.168.0.0/24. Je geeft aan een /20 te nemen, dan zit je helemaal verkeerd in de 192.168.0.0/16, aangezien dat bedoeld is voor class C oftewel /24 netwerken. Genoeg devices die aannemen dat een IP in die range in een /24 zit, niet iets groters. Als je iets groters wilt kun je beter een reeks nemen uit 172.16.0.0/12 - en ook daar niet de 0.0 pakken.

[ShadowAS1]

Die link met het modem is nog steeds, 't modem is gewoon aan t eind van z'n leven lijkt het Alleen het probleem met de niet bereikbare router is solved.

dion_b: Jij raadt dus aan om bijv. 172.16.10.0/20 te pakken?

[dion_b]

Yup, dan zit je binnen de standaarden en is kans op gedoe als je hier had nagenoeg nul.