Onderwerp: Routing issue Ziggo netwerk

Zo'n 20% meer als je de alles in 1 bundels vergelijkt. Valt reuze mee dus

Valt mee, zie: http://www.ziggozakelijk.nl/internet...et_plus/bestel het grootste voordeel is dat je een eigen IP range op naam krijgt!

Prive betaal ik voor Alles-in-1 Plus € 51,50
Zakelijk betaal ik voor Internet Plus ZZ1 € 58,31

Klein verschil dus, waarbij zakelijk internet iets sneller is dan prive.

Oorspronkelijk geplaatst door Cybafish

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?).

Wel, ik schreef dan ook dat het wat vergezocht was. De OP was niet heel specifiek over hoeveel andere servers (cq src/dst paren) hij getest had.
Overigens is bij dit soort gebundelde verbindingen geen sprake van een "cache", het is een design keuze om bv 2x1G (of 4x1G), of 2*10G of 2*155M te gebruiken, en de verdeling van flows over de verbindingen is deterministisch. Misschien lastig te voorspellen, maar een exact zelfde flow gaat over dezelfde link, ook na dagen.
Als alleen IP adressen in de hashing meegenomen worden kun je zonder van server of client IP te wisselen dus niet een andere link gebruiken; Zitten er ook poorten in is de verdeling meer random aangezien een client typisch een 'willekeurige hoge poort' als source port neemt bij het opzetten van een verbinding.
Anyway, erg speculatieve theorie voor dit geval, maar in het algemeen best mogelijk. En dan is het lastig te vinden.

Oorspronkelijk geplaatst door Cybafish

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

Ik ook. Precies de situatie van de OP, van je Ziggo modem naar je UK colo server/subnet pingen en tracen om te troubleshooten.
Het duitse plaatje is ietwat simpel, omdat de hele Internet wolk van een aantal ASen met een onbekende topologie door een enkel touwtje voorgesteld wordt. (Netzwerk2), en ook de topologie binnen de hoster gebundeld is tot een enkele router.(Router2).

En normaliter wordt verkeer van buiten wel degelijk *via* het interface wat voor de bestemming de gateway vormt afgeleverd.
Eigenlijk het enige verkeer wat *niet* door het gateway interface gaat, is verkeer tussen servers in hetzelfde subnet, bij een normale setup.

Oorspronkelijk geplaatst door Cybafish

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.

En andersom (dwz: announce van net A is ook aangekomen bij router B).
Precies wat ik schreef, als ping/trace naar het gateway IP werkt kun je bijna zeker het hele transport traject uitsluiten als probleem van een netwerk of routing issue.
En dat is wat je met ping & trace te zoeken hebt op (juist) het gateway IP.

Oorspronkelijk geplaatst door Cybafish

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.

Als het *niet* werkt moet je verder zoeken inderdaad.
Als volledige buitenstaander kun je een gateway niet weten (ook al kun je raden naar voor de hand liggende opties als .1/.254 in een /24, of equivalenten in een /27,/26,/25 e.d.
Maar als eigenaar van beide endpoints, met de vraag bij welke provider je moet klagen, heb je natuurlijk wat extra kennis en weet je dus het subnet en de gateway.
Zo'n gateway adres filteren is zeker hinderlijk bij troubleshooten,en eigenlijk vraag ik me af hoeveel partijen dat doen.Als je een beetje netwerk hebt levert het een behoorlijke lijst losse filter-adressen op die voortdurend bijgehouden moet worden.
Het kan, maar er zijn meestal grotere risico's om op te filteren dan de bereikbaarheid van een gateway-IP.

Als de gateway (ook) onbereikbaar is, is de volgende vraag of er een algemeen routing issue is, of iets in het domein van de eigenaar van het subnet. (hetzij filter/firewall, hetzij een 'echte' storing).
Daarvoor kijk je met traceroute, maar nog steeds naar het kleinste subnet wat geannounced wordt waarbinnen je probleem host zit.
Zit je probleemhost in een /24 subnet, en wordt het als een /23 geannounced (oa, naast een overlappende /19 en misschien nog een totaal ander subnet), dan wil je weten of je vanaf je source uberhaupt tot binnen het netwerk van de bestemming komt, of dat je niet eens je source-netwerk uit komt.

Als je bedoelt te zeggen met "e.g een transit uplink" om te testen naar een totaal ander subnet (en zelfs andere prefix) dan waar je probleem-host in zit, wel, daar heb je vrij weinig aan. Die kan op een andere pop uitkomen, via een andere peer of door een andere transit gaan.
Je wilt zo precies mogelijk een sectie of partij uitsluiten als probleem, en dat doe je door bijna alles hetzelfde te houden behalve de component die je test.
En in veel gevallen is de testen naar een gateway IP een prima manier om "alles hetzelfde behalve de host en access switch" te testen.

Andersom trouwens ook, wanneer je als netwerk engineer zonder toegang tot servers moet kijken naar connectivity problemen, is testen vanaf de connected router met als source adres het IP adres van het interface waarachter de probleemservers zitten hebben beslist aan te raden.
(default neemt een router bij ping & trace als source het uitgaande interface)

Oorspronkelijk geplaatst door Cybafish

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...

Natuurlijk is testen richting gateway het niet de enige test bij connectivity problemen, (noch de aller- állereerste), maar het is absoluut zinvol om te proberen bij troubleshooten, en ik zou "ping/trace naar gateway IP" zeker niet in de klasse "de gekste dingen bij troubleshooten" onderbrengen.

Oorspronkelijk geplaatst door Ber|Art

Valt mee, zie: [url]het grootste voordeel is dat je een eigen IP range op naam krijgt!

Nu je het zegt, dat wist ik nog niet. Ik heb een klant een Ziggo zakelijk abonnement aangeraden en hun organisatie naam staat inderdaad gekoppeld aan de IP's.

Oorspronkelijk geplaatst door visser

Natuurlijk is testen richting gateway het niet de enige test bij connectivity problemen, (noch de aller- állereerste), maar het is absoluut zinvol om te proberen bij troubleshooten, en ik zou "ping/trace naar gateway IP" zeker niet in de klasse "de gekste dingen bij troubleshooten" onderbrengen.

Ik heb je post met een grote glimlach gelezen, je hebt duidelijk passie voor het halen van je gelijk, net als ik.

Wat de techniek betreft zijn we het allebei met elkaar eens, hoewel jij het in andere bewoordingen brengt en andere dingen aanstipt dan dat ik doe. Verdere ondersteunende voorbeelden en argumenten zouden dan ook zonde van jouw en mijn tijd zijn.

Oorspronkelijk geplaatst door visser

Eigenlijk het enige verkeer wat *niet* door het gateway interface gaat, is verkeer tussen servers in hetzelfde subnet, bij een normale setup.

Toch nog een opmerking ter verduidelijking; jij hebt het over de interface, ik heb het over het IP. Het gateway IP draagt voor buiten niet dezelfde betekenis als voor binnen, waar dat voor een ander device binnen de range wel het geval is (en daar laat ik het gemakshalve maar bij). Daar kún je inderdaad wel wat mee, maar alleen als je ook verstand hebt van de achterliggende techniek -- anders zet het alleen maar aan tot de verkeerde conclusies. Als ik zo het niveau van de posts tot aan jouw binnenkomer bekijk, gok ik dat daar weinig BGP'ers tussen zitten en acht ik de kans daarom zeer aanwezig dat er verkeerde conclusies worden getrokken.

Toegegeven, mijn stelling "als buitenstaander heb je niets op een gateway IP te zoeken" was ietwat zwart/wit, maar jouw stelling is weer wat de andere kant op gechargeerd.

Oorspronkelijk geplaatst door Cybafish

Ik heb je post met een grote glimlach gelezen, je hebt duidelijk passie voor het halen van je gelijk, net als ik.

Wat de techniek betreft zijn we het allebei met elkaar eens, hoewel jij het in andere bewoordingen brengt en andere dingen aanstipt dan dat ik doe. Verdere ondersteunende voorbeelden en argumenten zouden dan ook zonde van jouw en mijn tijd zijn.

Er is inderdaad niet zo veel meer toe te voegen aan deze casus, en ja, ik ben meestal wel bereid om een discussie aan te gaan als ik ergens anders over denk

Oorspronkelijk geplaatst door Cybafish

[knip]
conclusies. Als ik zo het niveau van de posts tot aan jouw binnenkomer bekijk, gok ik dat daar weinig BGP'ers tussen zitten en acht ik de kans daarom zeer aanwezig dat er verkeerde conclusies worden getrokken.

Mw ja, maar dat was feitelijk al begonnen (speculaties dat er "iets" in het Ziggo netwerk gedaan zou worden speciaal voor die éne server). Onder andere daarom heb ik een stukje meegedacht aan de diagnose.

Anyway, altijd leuk, een beetje technisch discussieren ..
[..]