Onderwerp: Verschil in netwerken

We hebben 20 GE AMS-IX , maar ook 20 GE via Openpeering welke op haar beurt private peerings heeft met @home, wanadoo, chello enz. In deze setup zit al redundantie ingebouwd.

Daarnaast hebben we nog 1 GE naar de DE-CIX , 1 GE naar de LINX , 1 GE naar de Free-BIX en nog wat andere peering punten.

Het is nog nooit voorgekomen dat level3 boven de 150 mbit/s is gekomen terwijl we 2 Gbit aan totale capaciteit met ze hebben.

Een van de grote nadelen van maar 1 tranist partij hebben is dat wanneer er politiek (of andere) spelletjes spelen niks kan doen tot de grote partijen het hebben opgelost.

In de recente historie hebben we dat gezien met cogent en L3
Eweka netwerk was toen niet bereikbaar voor cogent klanten (toch best een boel)

Tevens kan je problemen ervaren als er peering problemen spelen.
Als L3 capaciteit met DTAG wil uitbreiden, maar DTAG (puur ter voorbeeld) dat niet wil zit je met de gebakken peren.

Als je meerdere transit partijen hebt ben je vrij om een alternatieve route te kiezen.

Een van de grote nadelen van maar 1 tranist partij hebben is dat wanneer er politiek (of andere) spelletjes spelen niks kan doen tot de grote partijen het hebben opgelost.

In de recente historie hebben we dat gezien met cogent en L3
Eweka netwerk was toen niet bereikbaar voor cogent klanten (toch best een boel)

Wij peeren met CogentCo dus we waren vanaf Cogentco klanten gewoon bereikbaar

Je 2e voorbeeld heeft een punt. Het ligt dan echter m.i. meer voor de hand om eerst te proberen een partij rechtstreeks aan te sluiten en anders, als ze dat niet willen, voor het beste alternatief te kiezen in plaats van andersom.

http://www.tsystemspeer.com is het bewijs hiervan.

Oorspronkelijk geplaatst door eweka

En wie geeft jou de garantie dat de partij aan de overkant wel genoeg transit tot haar beschikking heeft dan ? Als de partij geen voldoende capaciteit ter beschikking heeft dan kun je kiezen voor een andere weg over het internet om die partij te bereiken , echter de weg terug heb je nog steeds geen invloed op.

Correct, echter de meeste partijen zullen toch wel kiezen voor symetrisch routeren in plaats van heftige localprefs. Met meerdere transit heb ik de keuze uit meerdere paths naar een partij.

Oorspronkelijk geplaatst door eweka

Daarnaast is er voor de partij aan de overkant ook een kostenafweging. Deze zal zo min mogelijk over transit willen sturen en zo veel mogelijk over peering, uitzonderingen daargelaten. Dikke kans dat ze minder capaciteit ter beschikking hebben voor jouw Transit dan voor onze directe peering.

Dit is lang niet altijd zo, zeker US partijen staan erom bekend dat ze hun peering punten nog wel eens willen verwaarlozen, zowel publieke als private peering is dan een doorn in het oog.

Oorspronkelijk geplaatst door eweka

Nog zo'n onzin. Ons netwerk is geoptimaliseerd op kwaliteit en niet alleen op usenet. Cogentco komt er bij ons als transit provider niet in, over andere partijen met eenzelfde kwaliteit maar te zwijgen.

Grappig dat je Cogentco noemt, want zij doen exact met hun netwerk wat jullie ook doen, zoveel mogelijk over peering mikken waardoor de kwaliteit minder beinvloedbaar is, dit en hot potato routing policy (zie cold vs hot potato routing) is exact waarom Cogent een mindere transit partij is.

Wij hebben wel een directe transit met cogent, omdat we routes optimaliseren en datgene wat we uitsturen zelf in de hand houden, Cogent puur in je BGP mixen en BGP het maar laten uitzoeken is inderdaad, naar mijn mening, ook geen goed idee, juist omdat zij op diverse peering points capaciteitsproblemen hebben.

Ze zijn geen tier-1 en kopen ook transit, op transit zie je geen capaciteitsproblemen, door een directe connectie met cogent te onderhouden:

1. Hoef ik geen rekening te houden met congestie van cogent op peering punten om cogent klanten te bereiken.

2. kan ik ook transit partijen en goede routes van cogent bereiken, wat soms de leukste route is naar de USA.

Met puur peering kun je dat niet, jij bereikt hooguit de cogent klanten, als cogent hun public peering connectie weer eens vol laat lopen, heb je packetloss naar deze klanten.

Oorspronkelijk geplaatst door eweka

Ik gaf je net een lijstje met peerings. Op die lijst staan bijvoorbeeld ook Cogent en KPN, wat inhoud dat wij klant A als die cogent of KPN als transit heeft ook achter cogent zien en zij ons ook. Idem voor Abovenet, KPN , enz. Er zijn dus voor ons net zoveel mogelijkheden om ons verkeer te sturen of zelfs nog meer dan dat je alles over een transit pijp als telia heen mikt , of in een erger geval een leaseweb waardoor je weinig redundantie hebt of uitwijkmogelijkheden.

Even voor de duidelijkheid, we nemen ook troutes af van InstantXS waardoor we wel redundantie hebben, verder hebben we altijd de optie om verkeer via Telia, Level(3) of Cogent te sturen, redundantie is er voldoende op zo een manier, wij hebben immers carrier connecties en kunnen via een connectie heel Internet bereiken, we zijn niet geheel afhankelijk van peers.

Overigens ben ik het met je eens, dat peering voordelen kan hebben, paths kleiner maken etc, jullie setup is niet slecht, nogmaals, voor alle duidelijkheid. Maar 99% van alle grote eindgebruikers/contentgebruikers kiezen voor multiple transit setup, dat lijkt me een reden hebben, wat denk jij daarvan?

Peering connecties zijn zo betrouwbaar als de tegenpartij waarmee je peert ze
maakt.

Oorspronkelijk geplaatst door eweka

Onderstaand nog een view hoe ik het Neoworld network zie. Dan begrijp je wellicht beter wat ik bedoel .....

telnet@FRX2.eweka.nl#show ip bgp 194.126.173.18
Number of BGP Routes matching display condition : 12
Status codes: s suppressed, d damped, h history, * valid, > best, i internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 194.126.172.0/22 195.69.144.144 50 250 0 286 16265 35017 i
* 194.126.172.0/22 195.69.144.89 100 250 0 286 16265 35017 i
*i 194.126.172.0/22 81.171.102.243 74 0 19151 6461 16265 350 17 i
* 194.126.172.0/22 195.69.144.214 20 100 0 21155 29502 35017 35 017 35017 35017 i
* 194.126.172.0/22 195.69.145.63 10 100 0 21155 29502 35017 35 017 35017 35017 i
* 194.126.172.0/22 195.69.144.253 100 0 29502 35017 35017 35 017 35017 i
* 194.126.172.0/22 195.69.144.253 100 0 29502 35017 35017 35 017 35017 i
* 194.126.172.0/22 195.69.144.122 63 100 0 6461 16265 35017 i
*i 194.126.172.0/22 81.171.102.198 422 99 0 6461 16265 35017 i
* 194.126.172.0/22 213.228.3.234 1030 99 0 6461 16265 35017 i
*i 194.126.172.0/22 81.171.102.202 667 99 0 6461 16265 35017 i
* 194.126.172.0/22 195.69.144.124 0 100 0 174 174 174 35017 i
Last update to IP routing table: 1d7h17m1s, 1 path(s) installed:

Ik zie je dus echt niet alleen achter level3 of achter 1 peer , maar achter een hele hoop terwijl jullie mij met die 2 of 3 uplinks dus via minder wegen zien. Daar zit het verschil. Ik heb dus veel meer mogelijkheden om het verkeer te sturen op de manier zoals ik dat wil en niet zoals mijn transit provider(s) dat willen.

2/3 uplinks is wel een beetje overdreven weinig natuurlijk, neoworld heeft wat meer paden om uit te kiezen, daarom zie je ons ook via aardig wat connecties:

- Via InstantXS : Proserve peering routes, AMS-IX routes, NL-IX routes
- Via Leaseweb: AMS-IX routes, KPN Eurorings, Abovenet, Teleglobe, MCI, TeliaSonera.
- Level(3)
- TeliaSonera direct
- Cogentco

Zijn zowieso 5 directe links, verscheidene indirecte next hop links, waaronder effectief 4 full transit partijen, ofwel effectief minimaal 4 paths naar heel Internet.

Mijn (voorlopige) conclusie:
Eweka heeft echter op een paar punten zeker gelijk, peeren kan de verbinding verbeteren mits er actief routing management uitgevoerd word. Zeker nu wij groeien kijken we steeds meer naar directe en alternatieve indirecte peering mogelijkheden, peering is zeker niet slecht, mits zeer goed geoptimaliseert en belangrijker: continue geoptimaliseert.

Eweka heeft een mooi netwerk en ik vind hun aantal peers indrukwekkend, echter zou de kwaliteit naar mijn mening, toenemen, zodra zij meer full transit partijen aansluiten, waardoor ze nog meer in eigen hand hebben.

Overigens ben ik het met je eens, dat peering voordelen kan hebben, paths kleiner maken etc, jullie setup is niet slecht, nogmaals, voor alle duidelijkheid. Maar 99% van alle grote eindgebruikers/contentgebruikers kiezen voor multiple transit setup, dat lijkt me een reden hebben, wat denk jij daarvan?

Wat ik daarvan denk heb ik je al uitgelegd , ikzelf denk ik met voldoende argumenten.

Daarnaast 99 % van de gebruikers zal niet kiezen op basis van de argumenten hier omdat ze dat waarschijnlijk weinig zegt. Je gooit hier iets de zaal in waar mischien 5 % een goede kijk op heeft, zonder alle gegevens voorhanden te hebben en geeft daar een nadrukkelijke mening bij. Dat is niet zo netjes. Daarnaast is het een bewuste keuze als een klant die al maakt, veelal gebaseerd op smaak en vertrouwen.

Ook heb ik uitgelegd dat Multiple transit niet per definitie beter hoeft te zijn. Of je nu via Transit naar punt A gaat , of via peering naar punt A , of via multiple peers naar punt A , dat zal de meeste een zorg zijn , zolang het maar werkt en liefst ook nog goed. Daarnaast wordt het nog ingewikkelder als we gaan praten over de weg terug , symetrische routing , asymetrische routing enz enz enz. waarna veel mensen helemaal de draad kwijt raken.

Tevens praat je over andere netwerken zoals True,en Proserve. De laatste keer dat ik naar die netwerken heb kekeken is al weer een behoorlijk tijdje terug. Hun doelgroep is veelal een compleet andere doelgroep doordat ze andere value add services aanbieden dan dat wij hebben bij Eweka. Daarom zal ik ook minder snel een mening geven over hun, dat kunnen ze denk ik veel beter zelf doen als ze daarom gevraagd wordt en doorgaans zijn dat soort dingen wederzijds.

Nu ga ik toch weer dit topic even een nieuw leven inblazen.

Zoals je ziet, elk netwerk kan prima pingtijden hebben, mooie traces, maar dan ineens ligt het plat en ben je enkele uren weg.

Dáár zit nou het verschil in de netwerken.

Overigens hebben we dit enkele weken terug ook al gezien, een partij hun enige router ging er uit en ze hadden geen SLA om die snel gefixed te krijgen, dat was dus weer 8 uur downtime.

Zo zie je maar, hardwarematig maakt het allemaal niet zo veel uit, maar het zit hem in de dingen er omheen.

En tja, mooie verhalen als "ik heb overal engineers en pro-actieve routing" vallen snel als een kaartenhuis in elkaar, dat zie je maar.

Oorspronkelijk geplaatst door Wido

Zware DDOS is hopelijk een geldig excuus?

Oorspronkelijk geplaatst door Swiftway-UK

Zware DDOS is hopelijk een geldig excuus?

Bereikbaarheid? Ook easyracks kon je niet bereiken..

Informatieverstrekking aan klanten?
Hoe dan ook, het zal zeker helpen als je de klanten via een eigen noc server ga informeren..

Toch wel toevallig dat iets al langer duurt en plotseling opgelost is als jij ten tonele verschijn.

Wil niet gaan lopen bashen, daar is het veel te warm voor.. maar zelf heb ik dan toch mijn bedenkingen bij het e.e.a. ik het zoiets van.. proactief?? yeah right..

Oorspronkelijk geplaatst door Swiftway-UK

Zware DDOS is hopelijk een geldig excuus?

Dan is 12 uur alsnog wel erg veel, heel erg veel.

IP's waarop de DDoS komt niet meer announcen en je bent er toch aardig snel vanaf.

Ookal verspringt je DDoS van range naar range, dan alsnog zal hij niet op alle ranges binnen komen.

En daarnaast, DDoS, was dat het wel? Het wordt namelijk vaak als een makkelijk excuus gebruikt voor iets wat ergens anders lag. Waarom moest RedBus dan servers rebooten?

Redbus moest een aantal firewalls en switches rebooten.

Oorspronkelijk geplaatst door Swiftway-UK

Redbus moest een aantal firewalls en switches rebooten.

Ok, fair enough

En zojuist zagen we dus ook dat een grote, dure jongen een paar uur problemen kan hebben

Tja, idd helaas zelfs die

Ontkomen kom je nooit, ook al heb je de mooiste en duurste apparatuur staan, niks is eeuwig... En niet alles werkt altijd waarvoor het gemaakt is...