Afdrukvoorbeeld
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.Citaat:
Oorspronkelijk geplaatst door Dufu
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.
Je zou nog met wireshark kunnen kijken of je veel retransmits of ander onverwacht verkeersgedrag ziet tussen thuis en je server.Citaat:
Oorspronkelijk geplaatst door Dufu
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.
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.Citaat:
Oorspronkelijk geplaatst door Cybafish
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.
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?).Citaat:
Oorspronkelijk geplaatst door visser
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 (;)):Citaat:
Oorspronkelijk geplaatst door visser
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 (:D 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...
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.Citaat:
Oorspronkelijk geplaatst door Ber|Art
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?