1. Welkom op het onafhankelijke Ziggo Gebruikersforum. Een forum voor en door gebruikers van Ziggo.
    Registreer je gratis om direct zelf berichten te plaatsen en gebruik te maken van extra functies!
    Verberg deze melding

Kan weer bepaalde websites niet meer bezoeken.

Discussie in 'Internet - Algemeen' gestart door topmusic, 5 sep 2008.

Niet open voor verdere reacties.
  1. Hallo CeeS,

    Nog even ter aanvulling, ik heb ook op bovenstaande probleem-links geklikt in voorgaande posts en die pakt die hier ook niet.
    Ik zit in postcode 2725 als dat informatie is.

    Ik heb ingcard al gebeld en zij zijn er weer van overtuigd dat het probleem bij Ziggo ligt.
    De consument zelf trekt altijd aan het langste eind bij dit soort dingen.
    Wat kan hieraan gedaan worden?

    Met vriendelijke groet,
     
  2. Je zou de traceroute aan ingcard.nl kunnen laten zien, maar vermoedelijk kom je helemaal niet bij de systeembeheerders uit, maar bij een callcenter die normaal alleen vragen over de kaart krijgt... Maar wie weet...

    Verder is het melden hier ook goed, want er lezen Ziggo medewerkers mee en er zijn inderdaad weer sites bereikbaar geworden omdat er dan blijkbaar vanuit Ziggo contact opgenomen wordt met betreffende beheerders.

    Maar eigenlijk is dit in de meeste gevallen gewoon een kwestie van slecht onderhoud van bepaalde websites die hele ip-ranges blokkeren omdat ze niet uitgegeven zijn. Dat zouden ze dus heel regelmatig moeten aanpassen, want deze range is alweer even in bedrijf.
     
  3. Dank je CeeS,

    Ik snap wat je bedoeld, alhoewel er nieuwe vragen naar boven komen :)
    Ik zal het trouwens nog een keer proberen via ingcard, maar ik hoop dat er ook een Ziggo medewerker bovenop zit.

    Ik mail trouwens nog steeds via cable.wanadoo en heb er geen enkel probleem mee.
    Zo wil ik het eigenlijk ook, m'n oude bekende emailadres gelinkt naar orange of online of ziggo.
    Het komt allemaal nog bij mijn wanadoo adres uit, perfect.

    Als ik dit parallel met deze nieuwe range bekijk, die al weer even in bedrijf is.
    Waarom kan die dan niet via een oude range bij de site komen, als het de nieuwe range niet lukt? :)
    Ik kan mij namelijk moeilijk voorstellen dat ik al die oude slecht onderhouden sites opeens allemaal moet gaan bellen omdat ik schijnbaar in een nieuwe range val en ze niet meer kan bereiken.

    Ik hoor hier graag meer hierover uit nieuwsgierigheid en een fijne avond verder :)
    groet,
     
  4. De 32.x.x.x is van AT&T en is een transit partner die zorgt dat de verschillende datacentra aan elkaar gekoppeld worden (waar de servers staan). Die verbindingen kun je het beste vergelijken met een tolweg. Je betaalt om er verkeer over te mogen laten gaan, daarom dien je subnets te registreren met je transit partners om je klanten toegang te geven tot alle netwerken.
    Wat bij Ziggo is misgegaan is dat de registratie van het nieuwe 94.x.x.x netwerk om één of andere reden niet goed is gegaan. De schuldvraag bij wie het is foutgegaan is voor buitenstaanders louter speculatief, maar het is wel duidelijk dat het niet aan individuele websites ligt. Die firewall is in dit geval dus het tolpoortje wat niet opengaat voor een onbekende ip range.
     
  5. Wat is er dan misgegaan en wat moet er dan nog gebeuren ?
    (Weet je dit zeker of is dit speculatief gebaseerd op wat je ziet gebeuren?)
     
  6. Ik heb geen toegang tot contracten en afspraken dus die zekerheid kan ik je niet geven. Wat er moet gebeuren is dat voor alle partners het 94.x.x.x blok wordt toegevoegd aan de bestaande ziggo blokken, puur administratief. Technisch "snelle" oplossing is vaak tijdelijk herrouteren over andere werkende lijnen (er leiden meer wegen naar Rome). Het is vaak wat langzamer (omweg) maar je kunt wel op de sites komen. Ik kan niet antwoorden of Ziggo een andere weg naar bijvoorbeeld ingcard.nl kan nemen, dit is afhankelijk van de partners die je hebt naar, in het geval van ingcard.nl, het IBM netwerk in Londen. Al mijn beschikbare verbindingen lopen voor ingcard.nl via het AT&T netwerk, dus directe alternatieven kan ik hier niet noemen.
     
  7. Beste CeeS en Mart,

    Even een update.
    Ik heb weer contact opgenomen met Ingcard en een notitie laten noteren voor hun technische dienst dat het probleem nog steeds bestaat.
    Hij was onder de indruk dat het probleem al opgelost was, sinds mensen met dit probleem niet teruggebeld hebben.
    Klantenservice heeft opdracht om mensen te verwijzen naar de desbetreffende internet providers die dit probleem zouden hebben.
    Zij kunnen naar hun weten dit niet oplossen, maar stuurt het door.
    Ben snel teruggebeld met het slechte nieuws dat mensen met dit probleem bij hun provider moeten zijn.
    Verder kom ik niet.

    Zoals ik al eerder zei, ik hoop dat er ook een Ziggo medewerker bovenop zit, dus hoop ik dat die aandachtig meelezen.

    Groet,
    Eddy
     
  8. Mart,

    Dit is een klok klepel verhaal.

    Ten eerste ATT is geen transit partner, maar een peering partner, daar is een subtiel verschil in zoals je wellicht weet.

    Verder zijn de netblocks netjes in de RIPE database opgenomen, zoals gebruikelijk :

    route: 94.208.0.0/13
    descr: Casema Network
    origin: AS30776

    Als een carrier of peering partner filtering op een routing database toepast loopt dat niet stuk midden in het netwerk van die carrier of peer. Dat is het geval hier wel. Routing stopt midden in het ATT domein ergens.

    Zoasl de trace laat zien zit ING card achter die laatste HOP waar je de timeout krijgt. Ik heb de AS nummers er ook even bij gezet.

    [root@control ~]# lft -A www.ingcard.nl
    Tracing ..........T
    TTL LFT trace to www.ingcard.nl (129.35.72.70):80/tcp
    1 [41887] amsterdam-c1-gig11.prolocation.net (81.23.230.252) 0.4ms
    2 [24730] gigabone10-0.prolocation.net (81.173.31.225) 0.5ms
    3 [6762] ams7-garnier-1-nl.ams.seabone.net (195.22.213.133) 0.8ms
    4 [6762] ams31-ams1-racc1.ams.seabone.net (195.22.213.145) 1.2ms
    5 [AS?] nlamtr1103er1.am.nl.attglobal.net (195.69.144.194) 2.5ms
    6 [2686] 32.119.112.1 7.8ms
    7 [2686] 32.112.133.2 10.7ms
    8 [12980] 129.35.67.130 10.8ms
    ** [neglected] no reply packets received from TTL 9
    10 [12980] [target] www.ingcard.nl (129.35.72.70):80 10.8ms

    Bij eerder geposte traces loopt ie daar niet door. Wat denk je zelf, wie zou daar filteren denk je? Ziggo?

    AS12980 pakt het verkeer ook aan, dat is AS-IGNEMEA, de juiste dus al...

    Natuurlijk zegt ING Card anders maar ik zie niets anders dan dat een trace op de een na laatste hop stopt, waar ook filtering op plaats vind (de hop met de neglected). Maw, een firewall. DAAR (of er achter) zit de ellende zoals ook andere al opmerkte. Ze pakken het verkeer aan en binnen het IGN netwerk droppen ze het op de node die in de traces zichtbaar is.

    Een firewall een tolpoortje die niet open gaat naar een reeks die gewoon geregistreerd staat in een IRDB (RIPE in dit geval)? Moet je me toch eens uitleggen dan. Dan zou ATT gewoon niet routeren, en niet tot de firewall die voor deze betreffende dienst staat. Zo werkt het niet. Deze firewall blocked gewoon de 94.x range. Orange gebruikers in deze zelfde range rapporteren hetzselfde, ook die 94.x. Een andere ISP hetzelfde probleem. Ik denk dat de beheerder van het desbetreffende device op BOGONS filterd en die niet netjes geupdate heeft.

    Zie : http://www.cymru.com/Documents/bogon-list.html

    Bye,
    Raymond.
     
  9. Raymond,

    Dank je voor de moeite die je neemt om een en ander toe te lichten.

    Duidelijk.

    Je hebt gelijk, ik heb me een hop verkeken.

    Ik heb niet gesteld dat Ziggo iets filtert, ik heb alleen aangegeven dat de blokkade buiten het Ziggo netwerk ligt (in dit geval op het AT&T netwerk), maar dat je wel degelijk als consument bij Ziggo moet zijn om dit op te lossen. Als consument kun je niet bij de transit/peering partners aan de bel trekken als de route niet loopt, dat moet echt vanuit een NOC-persoon gedaan worden.

    in het screenshot in de post van Invidia Major zie ik geen acceptatie op AS-IGNEMEA. Daar loopt de trace tot en met de eerste hop op AS2686.

    Dat laatste sluit ik niet uit, maar ik blijf bij mijn standpunt dat een ISP in dit geval de taak heeft om te zorgen dat de routering loopt tot aan de site. Uiteraard is een ISP niet verantwoordelijk en heeft ook weinig invloed op zaken buiten het eigen netwerk, maar zij hebben wel meer gewicht bij het aanschrijven van de betreffende netwerken om iets voor elkaar te krijgen dan een doorsnee consument.

    Groet,

    Mart
     
  10. Een standaard traceroute tool verteld wel iets, maar in dit soort gevallen te weinig. Liever zie je dan een trace met een tol als MTR (of WinMTR), of beter nog met LFT omdat die ook netjes laat die als er onderweg ergens een firewall dwars zit.

    Natuurlijk kan Ziggo contact opnemen, wat ook gebeurd is, maar ING is vrij volhardend, het ligt aan jullie (Ziggo), als we dan vragen of ze dat willen toelichten omdat wij denken dat dat niet zo is, blijft het zoals andere ook al aangeven, stil. Ik denk dat de bal bij de content provider ligt. Ook die heeft hier een verantwoording in. En die gaat verder als hun klanten alleen vertellen dat het niet meer werkt.

    Verder ga ik mee in je verhaal hoor.

    Bye,
    Raymond.
     
Niet open voor verdere reacties.

Deel Deze Pagina