Onderwerp: Routing issue Ziggo netwerk

Hm volgens de vps aanbieder wordt er aan hun kant niets geblocked of gefilterd.

Ik heb nu mijn Ziggo ip veranderd (handig zo'n dynamisch ip) en nu werkt het weer gewoon. Dus er wordt toch ergens iets geblokkeerd of gefiltered. Beetje lastig uit te zoeken natuurlijk.

Oorspronkelijk geplaatst door Dufu

Hm volgens de vps aanbieder wordt er aan hun kant niets geblocked of gefilterd.

Ik heb nu mijn Ziggo ip veranderd (handig zo'n dynamisch ip) en nu werkt het weer gewoon. Dus er wordt toch ergens iets geblokkeerd of gefiltered. Beetje lastig uit te zoeken natuurlijk.

Je ziggo IP hoef je niet te veranderen dat kan alleen of door Ziggo of door je modem een 10 minuten uit te zetten daarna krijg je 9 van de 10 keer een nieuw IP maar ook niet altijd.

Op het moment dat jij je netwerkkaart een ander mac adres geeft of een nieuwe nic erin zet verandert hij ook.
Ziggo deelt ip's namelijk uit op mac adres

Dus zo moeilijk is een nieuw ip krijgen bij ziggo niet hoor

Dat is niet overal het geval, en ja ik praat uit ervaring doe wekelijks diverse aansluitingen voor Ziggo en kom regelmatig dit soort dingen tegen.

Ik zeg ook niet dat het moeilijk is.

Heb inderdaad de router een ander mac address gegeven waardoor je een nieuw ip adres krijgt toegewezen.

Oorspronkelijk geplaatst door Dufu

Hm volgens de vps aanbieder wordt er aan hun kant niets geblocked of gefilterd.

Ik heb nu mijn Ziggo ip veranderd (handig zo'n dynamisch ip) en nu werkt het weer gewoon. Dus er wordt toch ergens iets geblokkeerd of gefiltered. Beetje lastig uit te zoeken natuurlijk.

Je zou nog met wireshark kunnen kijken of je veel retransmits of ander onverwacht verkeersgedrag ziet tussen thuis en je server.

Een nogal vergezochte verklaring zou zijn als er ergens tussen jou en de server sprake is een gebundeld circuit.
Heel vaak ethernet (channel bonding, ether/port channel, trunk - diverse leveranciers gebruiken diverse termen), maar dat hoeft niet.
(seriëele of SDH link met identieke routing cost).
De switches of routers aan weerszijden van het gebundelde pad gebruiken een hash om het verkeer over de bundel te verdelen, zodanig dat een flow over hetzelfde pad (om geen out of order packets te veroorzaken).
Die hash kan op alleen source/dest , of de set src/dst + ports gebaseerd zijn.
Als één van de linkparen slecht is of vol zit, heb je bij bepaald verkeer daar last van, maar testen van een heel nabije andere client of server gaan prima, als die toevallig op een andere link in de bundel uitkomen.
Dat kan erg lastig zijn om te vinden.

Oorspronkelijk geplaatst door Cybafish

@visser, inderdaad asymmetric routing, schoonheidsfoutje

[..]

Tenslotte, pingen of tracen naar een gateway adres vanaf een extern netwerk is nooit een goed idee. Een extern netwerk heeft eigenlijk niets te zoeken bij een gateway (=intern).

Oneens, zeker bij troubleshooten. Het is een router interface, en je hebt er net zo veel, en net iets meer zelfs te zoeken met ping/trace, als bij andere hops in het pad.
Een gateway adres zit in hetzelfde subnet als de servers, en als de gateway werkt heb je bijna alle mogelijke (netwerk) routing problemen tussen dat subnet en je test/bron systeem uitgesloten.
Gateway werkt, server in gateway subnet niet brengt je bijna meteen naar server problemen als verkeerde of missende default-gateway op de server, firewall van de server, of soms filter op de gateway router of misschien arp issues.

Oorspronkelijk geplaatst door visser

Een nogal vergezochte verklaring zou zijn als er ergens tussen jou en de server sprake is een gebundeld circuit.

Dan zouden veel meer servers in die range problemen moeten hebben, niet toevallig nét die ene fatale combinatie van src/dst. Zo kan er ook op router niveau sprake zijn van host based multipath, maar dat blijft ook niet eeuwig in de cache zitten (en dit speelde wel een paar dagen?).

Oorspronkelijk geplaatst door visser

Oneens, zeker bij troubleshooten. Het is een router interface, en je hebt er net zo veel, en net iets meer zelfs te zoeken met ping/trace, als bij andere hops in het pad.
Een gateway adres zit in hetzelfde subnet als de servers, en als de gateway werkt heb je bijna alle mogelijke (netwerk) routing problemen tussen dat subnet en je test/bron systeem uitgesloten.
Gateway werkt, server in gateway subnet niet brengt je bijna meteen naar server problemen als verkeerde of missende default-gateway op de server, firewall van de server, of soms filter op de gateway router of misschien arp issues.

Ik heb het over van buitenaf tracen/pingen naar een gateway. Normaliter gaat het verkeer van buitenaf niet direct over het gateway IP. Src stuurt pakketjes naar zijn router (gateway), die stuurt ze naar de router van dst net, welke de boel weer doorstuurt naar dst. Bijpassend plaatje in Deutsch, dus dan weet je dat het gründlich is ():

http://upload.wikimedia.org/wikipedi..._Netzwerke.png

Als je dus als A antwoord krijgt van het gateway IP van B, dan kun je daaruit concluderen dat je netwerk announced wordt en is aangekomen bij router A. Het zegt echter niets over de werking van de switch waarop de router uplink van B is geprikt, nee, niet eens over de router uplink zelf. En als je geen antwoord krijgt, dan zegt dat eigenlijk ook niets. Kan evengoed een filter zijn in de router van B, want het is heel gebruikelijk om het gateway IP van buitenaf te filteren. Sterker nog, je weet als buitenstaander het gateway IP niet eens, want ook in dit geval wordt er een /18 announced, en zit er vrolijk een gateway in een /24 (misschien zelfs kleiner?) vlan binnen de /18. De src router doet zaken met de uplink van router B, niet met de gateway. Zelfs een router interface die niet door B zelf wordt geroute (e.g. een transit uplink) zegt dan nog meer over de werking van de router zelf.

Je kunt het altijd proberen natuurlijk en bij troubleshooten doen mensen soms de gekste dingen ( oh als ik daar eens een boek over zou schrijven), maar just my € 0,02...

Was een idd een routing probleem lijkt nu opgelost

Had je trouwens nog een reactie gekregen van Ziggo zelf Dufu? Ik ben nieuwsgierig wat ze te melden hadden en of die persoon verstand van zaken had.

@Ber|Art hoe weet je dit? Had je zelf ook met het probleem te maken?

@Clanhost nee heb nog geen reactie gehad van Ziggo.

Voor mijzelf was het probleem dus al 'opgelost' met een nieuw Ziggo ip, dit ip zat ook in een andere range dan mijn oude ip. Ik zie nu met just-ping.com dat er vanuit Groningen (server in Ziggo netwerk) ook geen packetloss meer is, dus er is in ieder geval iets gebeurd/opgelost inderdaad.

Ja ik had ook een erg trage verbinding vanmorgen, ik heb direct de zakelijke helpdesk gebeld en die belde na 30 minuten terug dat het probleem verholpen was. Het probleem zat in de routing tables die de hele wereld rond gingen (dus een behoorlijke omweg) vandaar de pingtimes van > 200ms

Maar hier is het dus (erg snel) opgelost...

Oorspronkelijk geplaatst door Ber|Art

Ja ik had ook een erg trage verbinding vanmorgen, ik heb direct de zakelijke helpdesk gebeld en die belde na 30 minuten terug dat het probleem verholpen was. Het probleem zat in de routing tables die de hele wereld rond gingen (dus een behoorlijke omweg) vandaar de pingtimes van > 200ms

Maar hier is het dus (erg snel) opgelost...

Ik weet niet zeker of wij dan met hetzelfde probleem te maken gehad hebben, maar hoe dan ook het lijkt in ieder geval opgelost nu, dus wellicht had het wel met elkaar te maken.

Weet ik ook niet, ik heb ze maar kort gesproken. Ik moet zeggen dat dit de eerste keer is dat ik Ziggo Zakelijk heb moeten bellen voor een storing, dus wat mij betreft petje af voor Ziggo Zakelijk!

Betaal je nu veel meer voor die extra service vergeleken met een normaal abonnement voor consumenten?