yoel caspersen blog bloghoved

Juleudfordringen: En billig, redundant BGP-router

Når man som ny internetudbyder skal i gang i en boligforening, er det nærliggende at entrere med en eksisterende internetudbyder, der leverer en fiberforbindelse og et sæt offentlige IP-adresser, man kan bruge.

Det fungerer fint og er relativt billigt. Men når man skal have den næste boligforening koblet på nettet, begynder det så småt at give mening at opgradere til næste trin.

Inden for ISP-verdenen er det næste trin, at man bliver registreret hos RIPE og får et AS-nummer med tilhørende IPv4- og IPv6-adresser. Det koster ca. 15.000 kr. om året, og det giver mulighed for, at man kan begynde at købe trafik fra flere udbydere og tænke redundans ind i sit setup.

En klub af ligemænd - sådan da

Når man har et AS-nummer og køber trafik fra en eller flere udbydere, er man en såkaldt Tier 3 provider. Man kommer op i kategorien Tier 2, når man begynder at peere med andre ISP'er, samtidig med at man køber trafik.

I den absolutte superliga finder vi Tier 1 providers, der er så store, at de kan slippe afsted med ikke at købe trafik fra andre udbydere, men udelukkende peerer med andre Tier 1 providers og sælger trafik til resten.

Eksempler på Tier 1 providers er Cogent, AT&T, Deutsche Telekom, Telia og andre store spillere. På listen over Tier 2 providers finder vi bl.a. TDC, GlobalConnect, Telenor og lignende virksomheder. Langt de fleste internetudbydere i verden er Tier 2 providers.

Fordelen ved at købe trafik fra en Tier 1 provider er, at det i nogle tilfælde er rigtig billigt - fx er Cogent en af de billigste udbydere, man kan finde.

Til gengæld giver det nogle andre udfordringer at bruge en Tier 1 provider - i og med, at Tier 1 providers ikke køber trafik fra andre udbydere, men udelukkende peerer med jævnbyrdige virksomheder og betalende kunder, kan man komme i en situation, hvor ens Tier 1 provider ikke har adgang til hele internettet.

En ny internetudbyder bør derfor gå efter at købe trafik fra en Tier 2-udbyder, da det giver større sandsynlighed for, at man kan nå alle IP-adresser på nettet, både på IPv4 og IPv6. Optimalt set bør man købe trafik fra to forskellige udbydere, da man så også kan opnå redundans i sin løsning.

There's an app for that...

Hos Kviknet er tiden kommet til at opgradere vores bolignet. Vi startede med at købe en internetforbindelse fra GlobalConnect med tilhørende offentlige IP-adresser, men i mellemtiden er vi blevet landsdækkende på TDC's DSL-netværk og har fået vores eget AS-nummer med tilhørende IP-adresser hos RIPE.

Vi skal derfor have bygget en redundant løsning til vores bolignet, der kan genbruges, når vi går i krig på TDC's fibernet i DONG-området. Den vigtigste byggeklods er to BGP-routere, der kobler op til to forskellige Tier 2-udbydere.

En BGP-router til dette formål bør have plads til samtlige routes på internettet i sin route-tabel. P.t. har den globale IPv4 route-tabel ca. 560.000 entries, og på IPv6 er der ca. 25.000 entries.

Illustration: Privatfoto

Hvis man går efter en ren hardwareløsning skal man have den store tegnebog frem. En BGP-router med plads til den fulde route-tabel koster nemt et godt stykke over 100.000 kr., og man skal have to af dem, før det giver mening.

Man kan godt lave en skrabet løsning, hvor man anvender en software-router til at udtrække de vigtigste routes og installere dem i en billig hardware-router. Typisk kan en sådan hardware-router håndtere mellem 10.000 og 20.000 routes, og hvis man primært formidler trafik til danske websites, er der en god chance for, at størstedelen af destinationerne vil ligge i route-tabellen.

Der findes et nemmere alternativ til dette, nemlig en software-router baseret på en Linux-server og en BGP daemon som Quagga eller BIRD.

Den store udfordring ved en software-router baseret på commodity-hardware er antallet af pakker, der kan håndteres per sekund. Det skyldes, at opslag i route-tabellen foregår i RAM, hvis opslaget ikke er cached i CPU'en. Det er en operation, der er svær at parallellisere, og selv den mindste latency ved opslaget giver derfor en begrænsning i antallet af pakker, der kan routes per sekund.

I daglig drift er det ikke et issue for en dansk Tier 3-udbyder, da brugerne vil have en tendens til at tilgå de samme destinationer. Problemet kommer, når ISP'en bliver udsat for et DDoS-angreb, hvor der er mange små pakker fra mange forskellige IP-adresser over hele verden.

Mit juleprojekt er at bygge et proof of concept, hvor vi samtidig undersøger, hvad vi kan gøre for at forebygge problemer ved DDoS-angreb.

Disclaimer: Jeg er softwareudvikler med en overdreven tro på, at alt kan lade sig gøre i software, hvis man vil det nok, men jeg er ikke netværksekspert. Tag derfor mine konklusioner med et gran salt, og kom gerne med rettelser, så vi kan blive klogere.

Linux - netværkets schweizerkniv

En Linux-server kan håndtere store datamængder på middelmådig hardware - på en low-end server kan man godt sende mellem 10 og 20 Gbit/s igennem maskinen, før den begynder at få det dårligt, så længe netværkspakkerne ikke er for små.

Til dette projekt anvender vi et par billige Fujitsu-servere med Quad-core Xeon-processor og 8 GB RAM. Serverne kommer med 2 stk. 1 Gbit/s Intel-netværkskort, der bundles med LACP, så vi opnår en ind- og udgående båndbredde på 2 Gbit/s pr. server.

Som OS anvender vi Ubuntu Server 14.04 LTS. Canonical sender jævnligt opdateringer ud til Ubuntu, hvilket både er en fordel og en ulempe. En BGP-router skal helst ikke genstartes for tit, men omvendt er vi heller ikke interesseret i at have en gammel platform med sikkerhedshuller.

Vi spilder ikke penge på redundante strømforsyninger eller RAID - løsningen skal alligevel kunne holde til, at en af serverne forsvinder helt, og så giver det bedre mening at spare RAID og redundant strømforsyning væk og købe en ekstra server i stedet.

Som BGP daemon anvender vi Quagga. BIRD skulle være et udmærket alternativ, men Quagga anvender langt hen ad vejen Cisco-syntax, hvilket gør det nemmere at håndtere for en nybegynder som undertegnede.

Følg med i næste afsnit, hvor vi konfigurerer de to software-routere.

Og indtil da - glædelig jul!

Kommentarer (65)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Frej Mau

Jeg bruger selv pfSense i hverdagen til en mindre Kollegie løsning.
Der har vi selv pt 1Gbit op og ned til deling med alle beboerene samt 8 IP adresser.
Peanuts i know, men lige nu er jeg igang med at planlægge opgrade på infrastrukturen til at supportere 10Gbit op og ned.
Og pt kan vi få det til at rulle med et billigt (2500 kr) dual intel SFP+ pci-e netkort sammen med den HP Proliant DL380 G6 som vi opgradere til at køre 2 styks 4 core 8 threads Xeon istedet for "kun" en.
I starten kunne vi klare fuld load på forbindelsen med kun 2 cores (altså 1Gbit begge veje).
Nu kører vi så nogle extra services og bruger flere cores, da højere hastighedere = mere cpu forbrug.
Løsningen kan snildt bruges til multiWAN og til at dele offenligt IPer ud til klienter baseret på Private VLANs samt support for en masse overvågning som kan parres med en FreeNAS (hint forskernettet bruger også FreeNAS til logging). Pfsense har også ACL som kan baseres på interfaces.

Dette er mit bud på en smart løsning som ikke koster alverden.

MultiWAN internet -> pfsense -> sfp+ "core" switch med vlan -> enten switch som står ude hos kunden eller en switch før dette som deler forbindelsen op, igen med VLAN support. -> kunden med deres eget VLAN med deres egen IP (hvis i tilbyder det)

Hvis andre har et andet bud vil jeg meget gerne høre det da jeg gerne selv vil lære alternative løsninger :)

God Jul

  • 5
  • 0
Baldur Norddahl

Vi startede med to Linux servere med BIRD og det fungerede nu udmærket. Vi opgraderede til hardware router fordi vi fik et tilbud vi ikke kunne sige nej til. Hvis man har pengene, så er det bare nemmere og man sover måske også en smule bedre, når man ved at det er en traditionel og velafprøvet løsning. Dertil kommer at når hastighederne bliver hurtigere end 10G, så begynder det for alvor at være svært at få en software løsning til at følge med. Vores netværk har en teoretisk kapacitet på cirka 50G, selvom vi pt. kun har 2x 10G IP transit.

Men tilbage til software routeren. Første observation er at DDoS er ingress. Pakkerne kommer udefra det store internet og har typisk kun én enkelt af dine IP adresser som mål. Dvs. samtlige pakker rammer den samme route. Det at source IP adresserne kan være spoofede eller stamme fra et meget stort antal bots er faktisk irrelevant for din routning ind i nettet. Returtrafikken, hvis der er noget retur, er begrænset af din kundes evne til at svare. Worst case så er det en kunde der har 1000/1000 (hvis i sælger den slags) men altså slet ikke i 10G størrelsesorden.

Selv hvis det er et DDoS der har dig som internetudbyder som mål (ekstremt sjældent), og de derfor har spredt angrebet over alle dine IP adresser, så er det altså din interne routing tabel der bliver brugt. Den er typisk kun i størrelsesorden 100 entries eller mindre. Så der er altså stor chance for at den brugte del af routingtabellen faktisk kan ligge i CPU cache.

Ved et DDoS er dit første forsvar at identificere angrebet og droppe det med IPTables. I det tilfælde bliver pakkerne slet ikke routet.

Men pas på med at antage at normal trafik er lig med store pakker. Her er nogle pakke countere fra et transit link:

  In_64B            2927034517           In_65_127B         8241948597  
  In_128_255B       3049016192           In_256_511B        717878814  
  In_512_1023B      1006343380           In_1024_1518B      10517015111  
  In_1519_MaxB      65488178033                               
  E_64B             3279878021           E_65_127B          85082878289  
  E_128_255B        9343810152           E_256_511B         2369989917  
  E_512_1023B       10422829625          E_1024_1518B       27560341253  
  E_1519_MaxB       17990091102          

Den største counter her er egress 65 til 127 bytes. Dvs. faktisk den case vi mindst bryder os om (udgående=stor routing tabel, små pakker).

Heldigvis har en ISP til private meget mere ingress (download) målt i bytes i forhold til egress. Så det er ikke nødvendigt at kunne performe helt op til maks i upload retningen.

  • 5
  • 0
Baldur Norddahl

Den opgave er en lidt anden end det Yoel er ved at bygge. Yoels udfordring er at håndtere den store routingtabel. Din er at håndtere connection tracking og NAT for et stort antal brugere. Du forsømmer at fortælle os om hvor mange i er - det er faktisk vigtigere end båndbredden.

En stor bittorrent bruger kan være rigtig tung for en fælles bolignet NAT. Det er antallet af samtidige forbindelser der belaster og måske lidt af samme årsag som at den store routing tabel er tung. Data kan ikke være i CPU cache og vi ender derfor med at være begrænset af memory båndbredde.

  • 5
  • 0
Baldur Norddahl

Undskyld hvis jeg taler lidt med mig selv her. Jeg kom i tanke om at egress på føromtalte transit link nok er lidt højere end naturligt på grund af vores routing politik. Man skal tænke på at indgående og udgående routing sjældent er symmetrisk. Vi har en tendens til at foretrække det ene transitlink over det andet på udgående trafik. Den indgående trafik forsøger vi påvirke via noget trafik engineering (BGP tricks) som altså ikke matcher fuldstændigt det vi gør med udgående trafik.

På den anden side, så er det præcis sådan noget din software router også skal kunne håndtere. Når nu du planlægger med at bygge et par, så skal du også være forberedt på at belastningen ikke bliver ligeligt fordelt og at belastningen ikke bliver symmetrisk. Du kan derudover regne med at noget trafik skal tælles to gange fordi det først skal håndteres af den ene router, for at blive sendt til den anden og videre ud i verden.

  • 4
  • 0
Baldur Norddahl

Der er lidt interessant julelæsning her: http://www.amazon.com/The-2014-Internet-Peering-Playbook-ebook/dp/B00HOW...

TDC er en såkaldt regional tier 1. Det betyder at de har en position i markedet og en størrelse som gør at ingen kan få en settlement free peering aftale med dem. Undtaget de øvrige regional tier 1, hvilket i praksis er de gamle tele monopoler i de omkringliggende lande. Der kan også være historiske undtagelser som eksempelvis forskningsnettet.

Årsagen til at du ikke kan få en peering aftale med TDC er at de tænker at du nok er villig til at betale. Enten direkte eller indirekte. Hvis ikke du køber transit af TDC, så køber du af nogen som har købt transit af TDC. Så de er næsten sikre på at få penge for din trafik. I tilfælde at du køber trafik fra en af de andre regional tier 1, så er trafikken gratis for TDC da de netop har settlement free peering med disse.

Køber du udelukkende trafik af eksempelvis Cogent, så opdager du at din trafik går via New York for at komme til TDC kunder. Det kører du med cirka én dag inden du har fået så mange klager, at du indser at du hellere må lægge en express ordre hos TDC.

Så er der mellemstore virksomheder, som ikke helt er regional tier 1, men som alligevel føler sig så store at de ikke peerer med hvem som helst. Et eksempel er Global Connect. De nægter at peere med dig fordi de mener at du burde være kunde og man peerer ikke med kunder. En konsekvens heraf er at deres net ikke er så godt som det kunne være.

Generelt er det sådan at jo mindre du er, jo mere er du villig til at peere med alle. En undtagelse her er Hurrican Electric (he.net) som peerer med så mange som muligt.

  • 5
  • 0
Yoel Caspersen Blogger

Og pt kan vi få det til at rulle med et billigt (2500 kr) dual intel SFP+ pci-e netkort sammen med den HP Proliant DL380 G6 som vi opgradere til at køre 2 styks 4 core 8 threads Xeon istedet for "kun" en.

Det er spændende at høre om jeres løsning - vi, der sidder med den slags opgaver, støder jo som regel ind i de samme udfordringer af og til.

Som Baldur pointerer, går det konkrete projekt ud på at se, om vi kan bygge et par fornuftige BGP-routere i software på helt almindelig server-hardware. Men vi har også et andet projekt under opsejling, nemlig at vi skal bygge et par CGN gateways, dvs. nogle NAT-routere til Carrier Grade NAT - og her kommer vi i nærheden af noget, der minder lidt om jeres setup.

Omkring 10 Gbit/s Intel-kort og multicore CPU'er vil jeg anbefale, at man checker hvordan ens CPU affinity er sat op. Hvis man fx kører med et Intel x520-kort, er der så vidt jeg husker 16 native queues på kortet, som hver kan (og bør) kobles op på en specifik CPU-kerne, så man ikke ender med at have 100 % belastning på en enkelt CPU-kerne mens resten af systemet ingenting laver. Hvis man kører en nyere Linux-kerne bliver det håndteret automatisk, mens ældre Linux-kerner skal hjælpes lidt på vej.

Glædelig jul :-)

  • 4
  • 0
Yoel Caspersen Blogger

Vi startede med to Linux servere med BIRD og det fungerede nu udmærket. Vi opgraderede til hardware router fordi vi fik et tilbud vi ikke kunne sige nej til. Hvis man har pengene, så er det bare nemmere og man sover måske også en smule bedre, når man ved at det er en traditionel og velafprøvet løsning.

Hvad er det for nogle bokse, I kører med? De traditionelle ISP'er sværger til Cisco, Brocade og Juniper.

I tilfældet indgående trafik er det, som du nævner, primært ens interne route-tabel, der bliver brugt. Her kan man også lave et par tricks, så man offloader pakkerne til en billig layer 3 switch, der godt kan holde den interne route-tabel i sin TCAM. Det gør setup'et mere komplekst, men det holder omkostningerne nede.

Når den udgående trafik er relevant, skyldes det, at vi også gerne vil drive et par services, der kan anvende vores ubenyttede upstream-kapacitet og derved forrente vores trafikinvesteringer bedre.

Den største counter her er egress 65 til 127 bytes. Dvs. faktisk den case vi mindst bryder os om (udgående=stor routing tabel, små pakker).

Har du nogen ide om, hvad det er for en type trafik, vi taler om her? Er det torrent-trafik, eller har I kunder, der er en del af et DNS-botnet? ;-)

  • 3
  • 0
Yoel Caspersen Blogger

Ved ikke om det er relevant, men lacp over 2 stk 1 GB interfaces giver ikke et reelt 2 GB interface.

Der er lidt overhead til selve LACP-protokollen (tæt på ingenting), og så er det også afhængigt af den algoritme, der styrer pakkerne. I vores setup bliver pakkerne routet efter en parameter kaldet bond-xmit_hash_policy layer3+4 - den skulle gerne fordele pakkerne efter IP-adresse og port-nummer, så pakker tilhørende fx en TCP-session altid kører over det samme link.

Ved få sessions med stort båndbreddeforbrug (fx nogle få brugere, der henter filer fra en enkelt server), kan man godt se en skæv belastning - men i praksis bliver loadet jævnt fordelt, når bare der er tilstrækkelig mange brugere bag den trafik, der sendes hen over LACP-gruppen.

Er det den problematik, du tænker på, eller er der noget, jeg har overset?

  • 2
  • 0
Yoel Caspersen Blogger

På den anden side, så er det præcis sådan noget din software router også skal kunne håndtere. Når nu du planlægger med at bygge et par, så skal du også være forberedt på at belastningen ikke bliver ligeligt fordelt og at belastningen ikke bliver symmetrisk. Du kan derudover regne med at noget trafik skal tælles to gange fordi det først skal håndteres af den ene router, for at blive sendt til den anden og videre ud i verden.

Du har helt ret, og det er også tænkt ind i det setup, vi er ved at teste af. Jeg ser selvfølgelig lidt miljøskadet af, at jeg primært har arbejdet med løsninger, der håndterer stor udgående båndbredde, og hvor den indgående båndbredde er negligerbar. Som ISP med forbrugerkunder er det ca. den modsatte situation, vi har, så der skal nok ligge et par spændende overraskelser der.

  • 2
  • 0
Yoel Caspersen Blogger

TDC er en såkaldt regional tier 1. Det betyder at de har en position i markedet og en størrelse som gør at ingen kan få en settlement free peering aftale med dem. Undtaget de øvrige regional tier 1, hvilket i praksis er de gamle tele monopoler i de omkringliggende lande. Der kan også være historiske undtagelser som eksempelvis forskningsnettet.

Det er nok en meget præcis betegnelse - her i DK fylder TDC meget, men på verdensplan er de en lille spiller, modsat fx Telia, som er voldsomt store. Nu er de betalte peering-aftaler som regel hemmelige, så det er ikke nemt at afgøre, om en tier 1 provider reelt er en tier 1, eller om de egentlig hører til i tier 2-kategorien.

Årsagen til at du ikke kan få en peering aftale med TDC er at de tænker at du nok er villig til at betale.

Køber du udelukkende trafik af eksempelvis Cogent, så opdager du at din trafik går via New York for at komme til TDC kunder.

Jeg bliver gang på gang fascineret over at se, hvordan TDC får åbenlyse urimeligheder til at ligne tekniske uhensigtsmæssigheder. Det er dygtigt gjort, og de har positioneret sig utrolig godt i det danske samfund.

Generelt er det sådan at jo mindre du er, jo mere er du villig til at peere med alle. En undtagelse her er Hurrican Electric (he.net) som peerer med så mange som muligt.

Off topic: Det gør det faktisk utrolig udfordrende at sende store datamængder tværs over Atlanten, hvis de ender på en IP-adresse i Hurricane Electrics netværk. Ved det mindste nedbrud (og dem er der mange af, når der er mange paths til den samme destination) skifter pakkerne rute, og da HE peerer med hvem som helst, kan trafikken nemt gå over links uden den fornødne kapacitet.

  • 3
  • 0
Baldur Norddahl

Har du nogen ide om, hvad det er for en type trafik, vi taler om her? Er det torrent-trafik, eller har I kunder, der er en del af et DNS-botnet? ;-)

Nej ham har vi lukket for :-)

Lad os tjekke det:

baldur@ballerup2:~/nfdump-1.6.13$ bin/nfdump -M /home/baldur/netflow/ballerup:albertslund -R . 'port 53' -n 10 -s srcip -O packets  
Top 10 Src IP Addr ordered by packets:  
Date first seen          Duration Proto       Src IP Addr    Flows(%)     Packets(%)       Bytes(%)         pps      bps   bpp  
2015-12-24 12:14:41.800 10215.610 any       185.24.168.17   528308(23.4)   529639(21.6)   42.6 M(15.3)       51    33388    80  
2015-12-24 12:14:48.870 10208.590 any       185.24.168.19   402619(17.8)   403616(16.4)   31.9 M(11.5)       39    25026    79  
2015-12-24 12:14:58.270 10199.160 any             8.8.8.8    76641( 3.4)   102295( 4.2)   12.9 M( 4.6)       10    10116   126  
2015-12-24 12:14:48.840 10199.050 any        85.204.194.4    75879( 3.4)    76070( 3.1)    4.2 M( 1.5)        7     3281    55  
2015-12-24 12:14:56.840 10193.510 any      85.204.133.113    28758( 1.3)    55088( 2.2)    2.8 M( 1.0)        5     2191    50  
2015-12-24 12:14:55.830 10200.530 any      185.24.169.173    40013( 1.8)    40299( 1.6)    3.1 M( 1.1)        3     2454    77  
2015-12-24 12:31:19.780  1728.100 any       185.24.171.73     7427( 0.3)    37143( 1.5)    3.9 M( 1.4)       21    18117   105  
2015-12-24 12:14:59.820 10174.410 any      85.204.120.111    29690( 1.3)    29858( 1.2)    2.3 M( 0.8)        2     1771    75  
2015-12-24 12:14:50.830 10196.040 any      185.24.171.131    25504( 1.1)    25873( 1.1)    1.8 M( 0.7)        2     1442    71  
2015-12-24 12:14:58.420 10198.980 any       192.43.172.30    20608( 0.9)    20638( 0.8)   15.7 M( 5.7)        2    12332   761  
   
Summary: total flows: 2262159, total bytes: 277950090, total packets: 2455156, avg bps: 217353, avg pps: 239, avg bpp: 113  
Time window: 2015-12-24 12:13:54 - 2015-12-24 15:04:58  
Total flows processed: 23274366, Blocks skipped: 0, Bytes read: 1303388116  
Sys: 1.112s flows/second: 20928397.3 Wall: 1.110s flows/second: 20960193.0

De to øverste er vores egne DNS servere. Herefter ser vi trafik fra nogle populære tredieparts DNS servere (8.8.8.8 = Google DNS). Ham på fjerdepladsen er en kunde. Han har sendt 76070 DNS pakker over 3 timer (7 pakker i sekundet). Men det er alt sammen små pakker (gennemsnit på 55 bytes) så det er næppe DDoS. Jeg gætter på at han kører en torrent klient som laver DNS lookup på alle den kommer i kontakt med.

  • 3
  • 0
Baldur Norddahl

Er det den problematik, du tænker på, eller er der noget, jeg har overset?

Det primære problem jeg har med LACP er at det kan være problematisk at sælge 1000/1000 hvis dit net er baseret på aggregerede gigabit links. Folk forventer at båndbredden er til rådighed også på en enkelt TCP forbindelse.

De fleste hastighedstest er designet så at der downloades med mindst 2 TCP forbindelser. Hvis du er heldig, så falder de to TCP forbindelser på hver sin fysiske gigabit link. Men der er lige så stor chance for at de ender på samme link. Og hvis det skal igennem flere aggregerede links undervejs, så skal du kun tabe terningskastet én gang undervejs for at blive begrænset i dit throughput. Så jo flere aggregerede links undervejs, jo større chance for at hastighedstesten kommer dårligt ud. Ok man kunne nok designe nettet så det er garanteret at algoritmen altid vælger samme link i alle hops, men det bliver meget følsomt for at du tænker dig om når du ændrer i nettet.

Jeg har en teori om at det er derfor flere energiselskaber nøjes med at sælge 500 Mbit/s. Så slipper de for at skulle lave 10 Gbit/s backbone, hvilket er den eneste reelle måde at løse problemet på.

  • 3
  • 0
Frej Mau

Vi sidder 362 kolligianer. Vi bruger pt under peak hours 300-400mbit ud af vores 994 mbit. Men dette er dels pågrund af vores gamle Cisco Catalyst 2960 kun har gigabit uplink og kun 100 mbit ud til brugeren.

  • 4
  • 0
Yoel Caspersen Blogger

Jeg har en teori om at det er derfor flere energiselskaber nøjes med at sælge 500 Mbit/s. Så slipper de for at skulle lave 10 Gbit/s backbone, hvilket er den eneste reelle måde at løse problemet på.

Det er også det eneste rigtige når man sælger gigabit-forbindelser ;-)

Vores 2 x 1 Gbit/s er kun i det her proof of concept. Det er simpelt at opgradere til 10 Gbit/s - det kræver 2 stk. Intel x520-kort og et par 10 G moduler til vores switches.

Interessant. Vores peak er væsentligt højere, nok omkring 2 Mbit/s per kunde. Og det er altså langt fra alle der har 1000/1000.

Det er nok forskellen på at levere til kollegieværelser og til familier.

Vi oplever ca. 1 Mbit/s pr. bruger i gennemsnit. Vi sælger 100/100 Mbit/s på vores fibernet, og det er både til familier og unge. Jeg hører lignende tal fra andre i branchen - så måske har I et par storslemme pirater i jeres kundekreds, eller også sætter vores CGN en alvorlig dæmper på trafikken ;-)

  • 3
  • 0
Baldur Norddahl

I tilfældet indgående trafik er det, som du nævner, primært ens interne route-tabel, der bliver brugt. Her kan man også lave et par tricks, så man offloader pakkerne til en billig layer 3 switch, der godt kan holde den interne route-tabel i sin TCAM. Det gør setup'et mere komplekst, men det holder omkostningerne nede.

Det behøver ikke blive særligt komplekst. Det kræver bare en smule samarbejde fra dine transitleverandører. Hos Cogent var det et standard spørgsmål om man ønsker en /30 eller /29 som peering subnet.

Med /30 er der fire IP adresser:

IP0: reserveret (network)
IP1: Cogents router
IP2: Din router
IP3: reserveret (broadcast)

Med /29 er der 8 adresser, som kan bruges sådan:

IP0: reserveret (network)
IP1: Cogents router
IP2: Din hardware switch
IP3: Din Linux server som snakker BGP med Cogent
IP4-6: bruges ikke
IP7: reserveret (broadcast)

Rent fysisk forbinder du det således:

  Cogent <-> hw switch <-> dit netværk  
                  |  
                  |  
          Linux/BGP server   

Det vil sige, Cogent er forbundet til din hw switch, måske på et 10G kredsløb. Din server sider på en anden port på switchen og resten af dit net på en tredie. Det er ikke givet at du ofrer et 10G på serveren.

Cogent og server er på ét vlan, lad os kalde det VLAN1. Netværk og server er på et andet vlan som vi kalder VLAN2. Serveren er på begge VLANs så at den kan route imellem dem.

Nu koder du din Linux/BGP til at bruge IP2 som next-hop. Det får Cogent til at aflevere alt indgående trafik direkte til din hardware switch. Med det menes at Cogent sender trafikken til switchens IP-adresse (IP2) da trafikken jo rent fysisk vil gå igennem switchen under alle omstændigheder. Dermed håndterer switchen pakkerne på layer 3 niveau og kan flytte pakkerne direkte til VLAN2 uden at de først skal sendes til Linux serveren.

Et alternativ til ovenstående er multi-hop BGP.

Pointen er at switchen ikke snakker BGP med Cogent, men den kan godt være target for trafik fra Cogent alligevel. Og den kan også route trafik direkte ud igennem Cogent uden at trafikken først skal via Linux serveren.

Udgående trafik håndteres ud fra en af tre strategier:

1 simple stupid: alt udgående trafik går via Linux serveren
2 default route: alt udgående trafik sendes til Cogent uden videre omtanke.
3 optimeret: default route er via Linux serveren, men de mest brugte routes læses ind i switchen.

Nummer 2 kan også kombineres med at indlæse vigtige routes, som så sender optimeret trafik via den alternative transit udbyder. Så at man siger at vi optimerer top 10.000 routes og resten default router vi bare.

Hvis din switch kan BGP, så er #3 faktisk ret simpel. Det er bare at lave en BGP session til switchen fra den BGP dæmon du allerede kører på Linux serveren. Og så lave et sæt regler for hvad der eksporteres til switchen. Du kan starte med noget der er primitivt, f.eks. alle routes med as-path længde under 3 eller alle routes til danske AS numre, samt Google, Akamai etc. Det behøver ikke være dynamisk.

Der er også den ultimative variant: glem den store routingtabel. Bed om at få en default route fra dine transit leverandører. Vi sender alligevel det meste udgående trafik til TDC. Hvis vi også sender resten til TDC, så er der ingen der opdager forskellen. Cogent outbound er der så bare som backup i tilfælde af at TDC er nede. Med denne variant kan vores billige switche snakke BGP direkte med transitleverandøren. Som ekstra bonus får man hurtigere konvergenstid og du sparer helt at have en server i din routing.

Bemærk at man stadig kan vælge at optimere. Du kan downloade routingtabellen offline og indlæse de vigtigste destinationer til den alternative transitleverandør. Her er exabgp god.

  • 4
  • 0
Baldur Norddahl

Hvis jeg skulle starte forfra med et begrænset budget, så ville jeg vælge at droppe den store routingtabel. Da jeg startede troede jeg at man kun var en rigtig ISP hvis man havde den. Men sandheden er at medmindre man har andre ASN som kunder, og dermed har nogen der skal have en kopi af routingtabellen, så er den oversolgt.

Vores forudsætning er at BGP automatisk vælger den bedste route ud fra data den finder i den store routingtabel. Du kan lave forskellige regler, men som udgangspunkt har du ikke så meget at vælge ud fra, andet end as-path længde. Men er as-path længde nogen særlig god målestok? Ét as-path hop kan tage dig 10.000 km på den anden side af jordkloden. Tre hop kan ske inden for det samme rum ved Hørskætten eller Industriparken.

Men hvis BGP vælger ud fra data som basalt set er garbage, hvorfor betale så meget og gøre en så stor indsats for at få fat i den routingtabel?

Der er nogle data der kan bruges en smule. Jeg har lavet et system som siger at hvis as-path består af tre ASN, hvor det første er mit eget, det andet er Cogent og det tredie er destinationen, så er der tale om vi begge er kunder hos Cogent. Og Cogents netværk er som sådan udmærket, så jeg kan fint sende trafik til ham via Cogent og få god kvalitet til billige penge. Jeg har en tilsvarende regel for TDC men som andenprioritet.

Men helt generelt så er der brug for noget bedre. Jeg har et projekt som går ud på at køre traceroutes til samtlige destinationer i route tabellen. Via et trick (source routing) kan jeg forcere hvilken af vores transits der bliver valgt til tracerouten og dermed kan jeg sammenligne hvilken transit mulighed der giver det bedste resultat. Herefter er det planen at indlæse regler bygget på resultatet af dette.

Så er det bare at routingtabellen faktisk er mere i vejen end den gavner. Jeg kan ligeså godt bare uploade de routes der skal bruges via exabgp. Og bruge Netflow til at finde de mest brugte routes, så at jeg kan udvælge de 10.000 vigtigste. Det tæller dobbelt, da jeg kun behøver at uploade en route hvis valget er forskelligt fra default valget.

Man sparer ret meget ved at sige fint nok, en lille routing tabel er godt nok til os. Vi køber almindelige switche til under 10% af hvad en "rigtig" router koster og lader den snakke BGP med vores transits. Men det er stadig en ren hardware løsning, så vi behøver ikke sove dårligt på grund af en frygt for om det nu også holder hvis vi bliver angrebet. Det er også billigere, for switchene skal du nok have under alle omstændigheder. Du slipper for at spekulere i om du har investeret nok i dine servere. En eventuelt exabgp kan du køre fra en "server" til 1000 kr. Hvis din exabgp server crasher, så sker der ikke andet end at trafikken flytter over på default route, dvs. du mister din optimering.

  • 5
  • 0
Yoel Caspersen Blogger

Pointen er at switchen ikke snakker BGP med Cogent, men den kan godt være target for trafik fra Cogent alligevel. Og den kan også route trafik direkte ud igennem Cogent uden at trafikken først skal via Linux serveren.

Det var lige præcis sådan en løsning, jeg tænkte på, da jeg skrev at man kunne offloade trafikken til en switch. Og måske ender det også med at være noget i den stil, vi laver - ulempen er, at det så stiller krav (om end små) til vores switch - den skal kunne route, og hvis den taler BGP, gerne med support for 4 byte AS-nummer, er det endnu bedre. Vi er dog stadig i den meget billige ende, og det er ganske givet, at det er en løsning, der giver bedre nattesøvn.

Der er også den ultimative variant: glem den store routingtabel. Bed om at få en default route fra dine transit leverandører.

Den lider af en ulempe: Hvis den ene af vores udbydere er en Tier 1 provider, og de afbryder peeringen med en anden Tier 1-provider, får vores routing switch intet at vide om det. Begge udbydere vil fortsat tilbyde os en default route, og vi kan således risikere, at vores kunder får problemer med at tilgå en ny, hip service i USA, hvis udbyder ikke vil betale beskyttelsespenge til Cogent (eller omvendt, for den sags skyld).

Lige netop Cogent har en historik for at depeere, hvis de har en kamp de skal have udkæmpet med en anden Tier 1 provider. Fx på IPv6, hvor de ikke har peeret med Hurricane Electric siden 2009.

Så spørgsmålet er, om ikke default-route-løsningen er lidt for simpel - det virker umiddelbart som om, det måske var bedre at gå efter løsningen, hvor software-routeren installerer de mest brugte routes på switchen og så ellers router resten selv.

  • 3
  • 0
Yoel Caspersen Blogger

Vores forudsætning er at BGP automatisk vælger den bedste route ud fra data den finder i den store routingtabel. Du kan lave forskellige regler, men som udgangspunkt har du ikke så meget at vælge ud fra, andet end as-path længde. Men er as-path længde nogen særlig god målestok? Ét as-path hop kan tage dig 10.000 km på den anden side af jordkloden. Tre hop kan ske inden for det samme rum ved Hørskætten eller Industriparken.

Jeg er helt enig i, at BGP ikke er optimalt. Men hvordan finder vi den optimale route? Er det:

  • Færrest involverede parter (dvs. AS-hops, BGP's metode)
  • Lav pingtid (hurtig respons på websites etc.)
  • Høj båndbredde (hurtig download af filer m.v.)
  • Lavest pris (irrelevant for slutkunden)

Antallet af AS-hops giver en indikation af, hvor mange firmaer der er involveret i at bringe pakken fra A til B. Jo færre, jo bedre, synes at være ideen bag. Men der er ingen garanti for båndbredde eller pingtid, og trafikken kan sagtens passere adskillige netværk uden at man kan se det, hvis en udbyder fx anvender MPLS eller lignende.

Lav pingtid er vigtigt til gamere, IP-telefoni og n-vejs videokonferencer. Nå ja, og aktiehandlere, men de kører på deres egne kredsløb så det er ikke så relevant her.

Høj båndbredde er umiddelbart også en vigtig parameter, men der er ikke altid en korrelation mellem disse parametre. På TCP er det dog relevant at se på bandwidth-delay product.

BGP tager umiddelbart kun højde for antallet af AS-hops, hvilket nok er den mest primitive metrik her.

Men helt generelt så er der brug for noget bedre. Jeg har et projekt som går ud på at køre traceroutes til samtlige destinationer i route tabellen. Via et trick (source routing) kan jeg forcere hvilken af vores transits der bliver valgt til tracerouten og dermed kan jeg sammenligne hvilken transit mulighed der giver det bedste resultat. Herefter er det planen at indlæse regler bygget på resultatet af dette.

Interessant tanke, der umiddelbart (som jeg læser det) vil optimere efter lav pingtid. Det fungerer nok godt til de fleste formål, men det tager ikke højde for båndbredden. Den er også svær at måle, når man ikke har en standardiseret test af dette på tværs af internettet.

Ideelt set burde samtlige pakker på internettet markeres med en form for QoS-parameter, der fortæller alle routere på vejen, hvilken parameter der skal routes efter: Færrest AS-hops, lavest pingtid eller højest båndbredde (alternativt højest båndbredde hvis båndbredde er lavere end x, ellers lavest pingtid). Afsenderen markerer profilen på pakken alt efter formålet.

For at det skulle være muligt, skulle BGP updates mellem routerne også inkludere information om aktuel båndbredde på den aktuelle router-port. Da sådan noget kan svinge hurtigt, ville det være nødvendigt at øge antallet af BGP updates kraftigt, og der ville også skulle indføres en dæmpningsmekanisme, så vi undgår at systemet går i selvsving.

Men ideen er dødfødt, da det ville være nødvendigt at indføre systemet på store dele af internettet før det giver mening, og så er det nok bedre at kigge på, hvad man selv kan gøre som ISP uden at involvere eksterne parter. Her virker din ide med at se på pingtiden som et interessant kompromis.

  • 3
  • 0
Yoel Caspersen Blogger

Men dette er dels pågrund af vores gamle Cisco Catalyst 2960 kun har gigabit uplink og kun 100 mbit ud til brugeren.

Det er egentlig et interessant spørgsmål, om øget hastighed på slutbrugerens port giver et større båndbreddeforbrug, når vi taler om 100 Mbit/s vs 1 Gbit/s.

Generelt vil jeg sige nej, da de fleste må forventes at hente det, de synes, de har brug for, uanset om det tager 1 minut eller 10 minutter.

Men der er måske et brugersegment, der ændre billedet en smule: Hoarderne. Det er brugere, som lider af en samlermani, og derfor henter alt hvad de kan komme i nærheden af inden for HD-film, uanset om de har tid til at se dem eller ej. Deres computere er altid tændt, og deres bittorent-klient kører 24/7. Her vil det selvfølgelig gøre en forskel, at der er større hul igennem til internettet, da de simpelthen kan nå at downloade mere på den samme tid.

Har I nogen målinger af, om det er enkelte brugere, der står for størstedelen af trafikken, eller er det jævnt fordelt på alle brugerne?

  • 3
  • 0
Baldur Norddahl

Den lider af en ulempe: Hvis den ene af vores udbydere er en Tier 1 provider, og de afbryder peeringen med en anden Tier 1-provider, får vores routing switch intet at vide om det. Begge udbydere vil fortsat tilbyde os en default route, og vi kan således risikere, at vores kunder får problemer med at tilgå en ny, hip service i USA, hvis udbyder ikke vil betale beskyttelsespenge til Cogent (eller omvendt, for den sags skyld).

Det er kun et problem hvis begge udbydere er Tier 1, hvilket er en dårlig ide under alle omstændigheder.

Såfremt kun den ene udbyder er Tier 1, så sørger du bare for at din Tier 2 udbyder har højere prioritet. Så går trafik den vej medmindre du specifikt har lavet en optimeret route, som sender det ud den anden vej.

Men ellers så undlad at vælge såkaldte Tier 1 udbydere. Og det vil i praksis sige undgå Cogent og HE. Eksempelvis Telia vil ikke kunne leve med at mangle noget af internettet - og skulle det ske alligevel, så kan du også leve med det (dit net vil aldrig være dårligere end Telias).

Som bredbåndsudbyder til private, så er vores trafik meget asymmetrisk. Hvis vi altid sender 100% af vores upload til TDC, så er vi ikke dårligere end TDC, uanset hvad der sker. Og det er gratis da vores trafikafregning bestemmes af den retning med mest trafik, hvilket vil sige download. Cogent sparer stadig den samme mængde penge, da de fortsætter med at hive download ud af TDC linket.

Husk også at download styres af vores annonceringer. Det er præcis det samme uanset om du har den store tabel eller ej. Der er kun en forskel i upload retningen. Der er ikke tale om at download kan blive "fanget" på tier 1 udbyderens net, blot fordi vi har fravalgt den store tabel.

  • 4
  • 0
Baldur Norddahl

Jeg er helt enig i, at BGP ikke er optimalt. Men hvordan finder vi den optimale route?

Jeg kender ikke nogen metode der kan måle båndbredden, så den er ude. Teoretisk kunne du bruge NLNOG RING men jeg tror du bliver smidt ud af nettet hvis du ligger og flytter store mængder test data og desuden er der ikke noget krav om at maskinerne har noget særligt båndbredde til rådighed.

Lav ping tid er ofte også lig med god båndbredde. Om ikke andet så fordi det omvendte, høj latency, stort set altid er lig med dårlig båndbredde.

At tælle ASN hobs (as-path længde) er min verden lige så vilkårligt som at slå med en terning. Det virker i den forstand at metoden hjælper BGP til at undgå loops og du får en deterministisk afgørelse. Hvis vi rent faktisk brugte terninger i stedet, så ville routes flappe konstant. Metoden giver også lidt mening i det specialtilfælde hvor as-path er meget kort, da vi generelt er interesseret i at aflevere trafikken direkte, hvis muligt, eller med kun én mellemmand. Det sidste er en indikator for at trafikken ikke skal over til den anden ende af verdenen (men ikke skudsikker: TDC peerer i New York).

BGP mangler simpelthen GPS koordinater, link længde, link kapacitet eller andre indikatorer der kan bruges. Det er der ikke, så du kan i stedet fuldtidsbeskæftige en NOC afdeling med at sidde og programmere hints ind manuelt. Du kan også købe dyre appliances der gør noget i stil med min traceroute metode.

  • 3
  • 0
Ole Kaas

Har du overvejet Mikrotiks CCR modeller? Der er delte og stærke meninger om Mikrotiks produkter, men man kan ikke komme uden om prisen på $995 pr. router.

Jeg havde et Quagga setup med 2 linux servere, men af hensyn til den nattesøvn som Baldur omtaler, valgte jeg at kigge på Mikrotik. Jeg kaom aldrig længere end til et test setup inden forretningen tog en anden drejning. Men de åd da rask væk en fuld BGP route-tabel og så vidt jeg husker var der endda plads til et par stykker mere.

  • 3
  • 0
Yoel Caspersen Blogger

Har du overvejet Mikrotiks CCR modeller? Der er delte og stærke meninger om Mikrotiks produkter, men man kan ikke komme uden om prisen på $995 pr. router.

Jeg har gode erfaringer med Mikrotik som CPE - men jeg har ingen hands-on-erfaring med deres større modeller.

Kan det virkelig passe at man kan få en router med fuld route-tabel til $995 pr. router? Det lyder næsten som om, de snyder på vægten og kun installerer en brøkdel af route-tabellen i TCAM og holder resten i RAM.

Har du et specifikt modelnavn, så jeg kan tage et kig på specifikationerne? Det lyder næsten for godt til at være sandt, men hvis det ikke er, er det da helt klart noget vi skal kigge på.

  • 0
  • 0
Maciej Szeliga

Splittet en ældre firewall fra en kendt specialist på området ad... og hvad fandt jeg:
en std. industri PC fra et Taiwanesisk firma som specialiserer sig i industri PC-er og et ekstra 4 ports Gigabit kort fra samme firma, på boardet fandt jeg endda et SVGA udtag (dog uden D-sub stik). Nu kører den opnsense - fordi det den er født med ikke er supporteret længere på det hw.

Hvad jeg prøver at sige er at der er rigtigt meget nu om dage som kører på std. PC-hardware med en specialiseret Linux (eller xBSD) og lader som om det er "state of the art, purpose built hardware". Det er simpelthen blevet nemmere og billigere at tune en Linux end at bygge højt specialiserede hardware dimser... selv Cisco gør det (bare se på Nexus switche).

Uanset hvad du vil gøre så kan du finde en Linux eller xBSD som nogen har fået til at gøre det samme... og den løsning er sandsynligvis gratis.

  • 3
  • 0
Anders Lorensen

Jeg er helt enig i, at BGP ikke er optimalt. Men hvordan finder vi den optimale route? Er det:
•Færrest involverede parter (dvs. AS-hops, BGP's metode)
•Lav pingtid (hurtig respons på websites etc.)
•Høj båndbredde (hurtig download af filer m.v.)
•Lavest pris (irrelevant for slutkunden)

Dit forrige blog indlæg hed "Skal vi sælge value added services"
Hvad med at lave kunden tage valget som value added service? Det vil glæde både dem der downloader blueray film og vil have høj båndbredde og gamerne der vil have lav ping tider. Laveste pris lader du så være default valget (så hr og fru jensen er billige, da de er ligeglade), og færrest involverede parter lader du vare "højeste oppetid" valget.

Hvordan det teknisk skal strikkes sammen er en hel anden sag - men sikkert langt fra umuligt at implementere.

  • 2
  • 1
Baldur Norddahl

Kan det virkelig passe at man kan få en router med fuld route-tabel til $995 pr. router? Det lyder næsten som om, de snyder på vægten og kun installerer en brøkdel af route-tabellen i TCAM og holder resten i RAM.

Mig bekendt har de slet ikke TCAM. Det har Juniper i øvrigt hellere ikke, der er mange måder at nå i mål på.

Mikrotik er noget med en special udviklet CPU med 36+ cores. De kører en Linux som de har optimeret og videreudviklet. Den kan tage en fuld routing tabel, men der er nogle ting man skal være opmærksom på. Det første er at konvergenstiden ikke er optimal. Dvs. den er længe om at loade tabellen (nogle siger 20 minutter). Det skulle være fordi deres BGP proces kun kan køre på én core og er noget de arbejder på (dvs. det sagde de i 2013 og det siger de stadig...). Det andet er at den ikke nødvendigvis klarer fuld throughput med små pakker. Du har med andre ord nogle af de samme problemer som hvis du bruger din egen linux kasse til formålet.

Jeg har forsøgt at søge lidt på det, men finder ikke nogen der direkte har målt throughput med full tabel og små pakker. Kun en enkelt der klager over lidt droppede pakker ved 0,5 Gbit/s.

Det er helt sikkert ikke noget der kan bruges hvis du skal køre 10 Gbit/s. Eller dvs. den kan bruges i stedet for en Linux boks i kombination med en anden switch. Det er bare ikke ret fedt hvis den virkelig bruger 20 minutter på at starte.

  • 4
  • 0
Baldur Norddahl

Jeg fandt dette:

http://www.stubarea51.com/2015/07/10/mikrotik-ccr1072-1g-8s-review-part-...
http://www.stubarea51.net/2015/07/25/mikrotik-ccr1072-1g-8s-review-part-...
http://www.stubarea51.net/2015/10/09/mikrotik-ccr1072-1g-8s-review-part-...

Det er en Mikrotik med 8x 10G porte. Det lykkes for dem at køre 80 Gbit/s igennem den og de kan også loade en full routing tabel på få minutter.

Men de snyder på vægtskålen. De bruger MTU 9000 til testen - det giver på ingen måde svar på om den kan klare det i et realistisk ISP miljø.

  • 4
  • 0
Yoel Caspersen Blogger

Dit forrige blog indlæg hed "Skal vi sælge value added services"
Hvad med at lave kunden tage valget som value added service?

Det er en glimrende ide, som faktisk også har strejfet mig under denne debat. Spørgsmålet er, hvordan vi skiller de forskellige kategorier ad rent teknisk. Vi kan godt kigge på, hvilken IP-adresse, forespørgslerne kommer fra, dvs. den udgående trafik fra slutbrugeren, men det bliver nok svært at gøre noget ved den indgående trafik. Det kunne muligvis løses ved at have forskellige puljer af offentlige IP-adresser, som annonceres via BGP på forskellig vis. Afhængig af kundens profil får han en offentlig IP-adresse fra den rigtige pulje.

Vi kan selvfølgelig designe vores netværk, så gamere får en mere direkte vej til vores core-routere og dermed evt. kan skære et millisekund eller to af deres pingtid. Spørgsmålet er om det rykker nok til at man kan sælge det som en ekstra service.

I forvejen kan man på eBSA (som vi kommer til at gå over til inden længe) sætte en profil, der optimerer DSL'en efter høj båndbredde eller lav pingtid. Det bliver nok et produkt, vi kommer til at sælge til gamere for en beskeden merpris, da der vil være en smule mere support forbundet med den opsætning.

Giver det mening at tilbyde en profil, der er optimeret til fx amerikansk trafik, og en profil, der er optimeret til dansk trafik?

  • 1
  • 1
Yoel Caspersen Blogger

Uanset hvad du vil gøre så kan du finde en Linux eller xBSD som nogen har fået til at gøre det samme... og den løsning er sandsynligvis gratis.

Jeg er meget enig i budskabet og det er den primære drivkraft bag at sætte et par software-routere op - nemlig at vi skal se, om vi kan bygge en bæredygtig løsning til lav pris ved at anvende commodity-hardware.

Den eneste udfordring, jeg ikke har set løst 100 %, er at foretage routing på fuld route-tabel i software uden at man rammer loftet omkring de 10 Gbit/s hvis pakkestørrelsen falder.

Så vidt jeg ved, var det netop hvad Vyatta (en konkurrent til Quagga og BIRD) arbejdede på at løse. Modsat Quagga, som blot modtager route updates via BGP og installerer de resulterende routes i serverens egen route-tabel, var det målet at Vyatta skulle optimere selve route-processen.

Vyatta blev i øvrigt overtaget af Brocade, og det er mit indtryk, at de mere eller mindre har lukket projektet ned. Hvis min opfattelse er korrekt, viser det blot, at software-baseret routing kan være en alvorlig trussel mod de etablerede hardwareproducenters dominans.

  • 3
  • 0
Anders Lorensen

Jeg tror det er de færreste der ved præcist hvor serverne står, når de sidder og spiller et spil. Men man ved ofte godt hvilken verdensdel de står i.
Mange spil vælger man f.eks at logge på en server kaldet "US" eller "EU".

I first person shooters spil betyder 5 ms rigtig meget. I andre spil, næsten ingenting.
eSport er en voksende branche, og alle der deltager i eSport ved at svartider er altafgørende. Så jeg tror der er et marked, og jeg tror også det er voksende.
De lave svartider vil være noget jeg personligt gerne vil betale for, så længe vi snakker om priser på maks 20-30 kroner om måneden.

  • 3
  • 0
Baldur Norddahl

Det var ikke umiddelbart det jeg oplevede. Det er et stykke tid siden - men som jeg husker det var den hurtigt ombord. Men det var også et test setup hvor der ikke var andet trafik.

Lige dét tester de - se det andet link jeg fandt.

Public BGP Table – IPv4 with 1 upstream peer (457,461 routes – 1 Minute 33 seconds)
Public BGP Table – IPv4 with 2 upstream peers (914,922 routes – 3 Minutes 25 seconds)
Public BGP Table – IPv4 with 4 upstream peers (1,829,844 routes – 7 Minutes 8 seconds)
Public BGP Table – IPv4 with 8 upstream peers (3,659,688 routes – 13 Minute 17 seconds)

Det synes ikke at være så galt. Jo hvis der kommer mange upstreams med fuld tabel, men så er man nok også vokset fra Mikrotik.

  • 4
  • 0
Yoel Caspersen Blogger

Kan man ikke skrive en PM til bloggeren hér? Mail mig på ole [at] hygos punktum dk.

Det er hermed gjort. Tak for din feedback i øvrigt, det er fedt at der kommer nye vinkler på de tekniske udfordringer.

Er der nogen derude, der har rigtige driftserfaringer med Mikrotiks core-routere? Det lyder jo voldsomt billigt, men der er en verden til forskel om man "bare" får en Linux-server i en fancy kasse og med et pænt webinterface, eller om man reelt får en full blown hardware-router til spotpris.

  • 1
  • 0
Michael Rasmussen

Det er muligt, det blot er en linux-server i en fancy kasse, men de har sikkert brugt rigtig mange ressourcer på at lave en optimal konfiguration i så fald, som, med al respekt for dig og dine kollegaer, i sikkert ikke vil være i stand til at gøre tilsvarende, såfremt i vælger en software løsning, i selv vil konfigurere. Lig dertil oveni at får support med i handlen.

  • 0
  • 0
Baldur Norddahl

Jeg er nu ikke imponeret over specs: http://routerboard.com/CCR1036-12G-4S

Ved 64 bytes pakker og 25 IPTables regler klarer den kun at route 1,8 Gbit/s. Så sent som i sidste uge havde vi et 5 Gbit/s DDoS angreb med små pakker. Vi har flere ACL regler på inbound, blandt andet for at stoppe UDP 1900 og en enkelt bruger der ikke fatter at lukke hans DNS relay, så vi har gjort det for ham. Der er ikke 25 ACL regler, men alligevel.

Jeg vil hellere ikke føle mig sikker på at den rent faktisk kan klare at route "fast path" med den fulde routing tabel. Det vil jeg nok kræve demonstreret først...

  • 2
  • 0
Jn Madsen

... at finde udstyr, der ikke er de "gode gamle" leverandører (Cisco, Juniper, Alcatel, Huawei osv) med råddent høje priser, hvis man vil have BGP med hele svineriet, fulde BGP tables og n10/n40/n100/n100 Gb interfaces,- og selvfølgeligt full-blown throughput på alle interfaces.

De gamle ISP'er er meget konservative, man skifter ikke bare lige udstyr, og hvis man gør, så tager det år at implementere.

Det er simpelthen et lidt lukket land for nye leverandører,- så jeg tror ikke de orker at tage alle udviklings omkostningerne. De tunge ISP'er har også en lidt kedelig vane med at gennemteste udstyret,- der er ikke plads til "ups", "tæt på" og "det går nok".
Samtidigt er det helt normalt at de "gamle" leverandører sælger med rabatter på 80-90% til de tunge ISP'er. Rabatter som små nystartede virksomheder ikke kan komme i nærheden af.

Så vi lander hurtigt i cowboy'der løsninger som i denne tråd. Yderst spændende for nørder som os,- men vi ender med løsninger man ikke har lyst til at smide mange tusinde kunder på, erhvervsløsninger eller garantere høje SLA.
På et tidspunkt må man bide i det sure æble, og sælge sin første-fødte og sætte konen i pant for at investere i udstyr fra en af de gamle dinosaurer.

Personligt afventer jeg spændt SDN, de nærmer sig noget der kan bruges. Det kan kun gå for langsomt.

  • 1
  • 0
Yoel Caspersen Blogger

Tak for dit tip, Michael.

Refurbished hardware er en af de steder, hvor man kan spare rigtig mange penge. Vi køber selv en del refurbished HP-udstyr til forskellige projekter, og i tilfældet HP er der livstidsgaranti og frit tilgængelige software-opdateringer til netværksudstyr, også refurbished.

Et andet sted, man kan spare rigtig mange penge, er at købe uoriginale transceivers, som ellers normalt koster en bondegård, hvis de skal købes originalt.

  • 1
  • 0
Yoel Caspersen Blogger

Så vi lander hurtigt i cowboy'der løsninger som i denne tråd. Yderst spændende for nørder som os,- men vi ender med løsninger man ikke har lyst til at smide mange tusinde kunder på, erhvervsløsninger eller garantere høje SLA.
På et tidspunkt må man bide i det sure æble, og sælge sin første-fødte og sætte konen i pant for at investere i udstyr fra en af de gamle dinosaurer.

Lad os nu se - innovation og nytænkning sker også nedefra, og ikke kun hos giganternes R&D-afdelinger.

Personligt plejer jeg at kigge mod Netflix, Facebook og Google, når jeg skal finde inspiration til en anderledes måde at gøre tingene på. Hvis det virker for dem, virker det nok også for os ;-)

  • 1
  • 0
Jn Madsen

Personligt plejer jeg at kigge mod Netflix, Facebook og Google, når jeg skal finde inspiration til en anderledes måde at gøre tingene på. Hvis det virker for dem, virker det nok også for os ;-)

Jeg er helt og aldeles enig. Som vi har sludret om før,- så tror jeg på SDN. Det vakler stadig rundt i sine barnesko,- men det vil udvikle sig.
Netop Netflix, Facebook og Google,- de navne antyder, hvor enorme ressoucer det kræver at udvikle nye metoder der virker.

  • 0
  • 0
Baldur Norddahl

Så vi lander hurtigt i cowboy'der løsninger som i denne tråd.

Jeg mener ikke det er cowboy løsninger. Jeg kan finde på løsninger der er komplekse og som kræver proxy arp samt at de andres udstyr opfører sig på en bestemt måde. Det er der slet ikke tale om her. Når eksempelvis Cogent tilbyder en /29 på bestillingsblanketten, så er det fordi det er noget de har set før og mere end én gang.

Og så kan man måske overveje om det er nemmere (og billigere) at finde en Cisco certified et eller andet. Eller om det nu også er så svært at finde gode folk der har massere af erfaring med Linux.

En ren software løsning er enkel og stabil. Der er faktisk kun en reel udfordring (små pakker) og den er velkendt. Det kan man teste og vurdere om man kan leve med de performance karakteristikker som systemet nu engang har.

En kombi løsning er også enkel hvis man holder fra sig fra proxy arp lignende metoder, og trykker IP transit udbyderen på maven indtil at de vil levere /29 eller multi hop BGP.

Som iværksætter ryster jeg på hovedet når nogen mener de er nødt til at investere store dele af deres kapital i udstyr, udelukkende på baggrund af stor firma tankegang. Ikke alt kan være perfekt fra dag et, og lige her kan man få frigjort en hel del kapital, der så kan investeres anderledes. Man kan altid opgradere når man er blevet stor.

  • 3
  • 0
Jens Jönsson

Så vi lander hurtigt i cowboy'der løsninger som i denne tråd. Yderst spændende for nørder som os,- men vi ender med løsninger man ikke har lyst til at smide mange tusinde kunder på, erhvervsløsninger eller garantere høje SLA.
På et tidspunkt må man bide i det sure æble, og sælge sin første-fødte og sætte konen i pant for at investere i udstyr fra en af de gamle dinosaurer.

Nøj, hvor har jeg hørt den mange gange før. Hvis det var tilfældet, at man ikke har lyst, så kan man ligeså godt lukke og slukke....
Det sjove i denne branche er når man snakker med medarbejdere hos nogen af de "store". De forstår ikke at man tør og tror ikke på det kan lade sig gøre (og så er det lige meget at man har bevist at det kan man og det kan lade sig gøre).
Men det er så derfor, man kan snuppe kunder fra dem. For deres løsninger bliver ravende dyre og det skal nødvendigvis spejle sig i priserne.

  • 2
  • 0
Jn Madsen

Nøj, hvor har jeg hørt den mange gange før. Hvis det var tilfældet, at man ikke har lyst, så kan man ligeså godt lukke og slukke....

Hov hov, du læser mit indlæg som fanden læser bibelen :-)

Jeg refererer bare til min erfaring,- som netværksdesigner hos et par af de store.
Hvorfor skulle de skifte? De køber udstyr fra de gamle tunge leverandører med rabatter på 80-90%. De har direkte hot telefonlinie til de ypperste programmører i branchen hos leverandøren, der i løbet af få timer kan kode noget software der kan patches i nødsituationer.
Du kan tro de kigger med på nye teknologier som SDN,- flere udenlandske ISP'er har samlet bolden op, og mit gæt er, at SDN i løbet af de næste 10 år vil rykke ind rigtigt mange steder.
Men husk på at ISP'ere snakker om Terabit der flyttes i core routerne, interfaces kører LACP med 10/40/100 Gb interfaces.
Der kan en hjemmestrikket Linux server godt begynde at få sved på panden :-)

Men ja,- jeg bruger al min tilgængelige tid på at lære om SDN, det er der det kommer til at sne ... tror jeg. (ellers har jeg spildt utallige timer :-) )

Yoel og Baldur: Cowboy'der løsninger,- ja, det lyder lidt mere negativt end det er ment. Jeg er selv den største Ole Opfinder. Men tunge ISP'er har nogle helt specielle krav til stort og stabilt throughput. Der er de ret enestående i branchen.
Alle andre steder er der åbent hus for at være meget kreativ,- og man kan lave vanvittigt fede ting med små midler,- og sjovest af alt,- man kan lave noget der er bedre end den dyre hyldevare.
Google, Facebook og de andre,- de løb ind i problemer man ikke havde set før. Da de voksede sig større end noget netværks verdenen havde set før,- da oplevede de nye problematikker omkring design, provisionering og drift som begyndte at blive en plage.
Samtidigt oplevede de, at hvor man i data og server verdenen var vant til at "styk-prisen" faldt, jo flere man lavede,- bl.a. vha. virtualisering,- så kom den samme driftbesparelse ikke med netværksdelen.
Netværket blev bare mere og mere råddent dyrt. Prisen per ydelse faldt ikke. Store tunge routere og switche er vanvittigt dyre,- selv med heftige rabatter.

Det var der, at de første tanker om SDN blev født,- andre samlede bolden op, og det ser ud til at blive en funktionsdygtig teknologi til mange andre ting end lige datacentre.
I det lys roder jeg faktisk ikke så meget med klassisk netværk mere,- jeg prøver at blive bedre til programmering (mest Python) og Linux.
Det er fremtidens netværkstekniker, tror jeg,- lige dele netværk, Linux og kodning.

  • 1
  • 0
Jn Madsen

NSA var været meget aktive og været en stor bedragsyder til OpenSource og SDN.

NSA bruger RYU SDN controlleren,- og de har også et omfattende netværk, så de rendte ind i de samme skaleringsproblemer. De lægger dog ikke detaljerede tegninger ud på nettet. Måske ikke den store overraskelse :-)

Hvis i vil se en sjov fætter,- her er en af deres tekniske chefer:

https://www.youtube.com/watch?v=NgahKksMZis

  • 0
  • 0
Yoel Caspersen Blogger

og været en stor bedragsyder

Lige netop dét er der vist ingen tvivl om længere ;-)

Men jo, trods slåfejlen har du ret. Det er nok også NSA's fortjeneste, at spændende projekter som PF_RING har set dagens lys. Hvis man ser bort fra det moralsk angribelige i at overvåge hele verden mod dens vilje, må det også være et super spændende område at arbejde med, og de må have nemt ved at tiltrække de mest kreative sjæle inden for området.

Jeg opfatter ikke dit indlæg som negativt, selv om jeg godt kan se, det falder nogle for brystet her i debatten ;-) Du kender den etablerede ISP-verden indefra, så du har givetvis ret i, at det er den måde, "de store" ser verden på.

Som udvikler er jeg tit stødt på holdningen om, at man opgraderer til en større boks, når den nuværende rammer loftet (scale up), i stedet for at købe en boks mere (scale out). Det er den holdning, der fører til enorme core-routere i teleindustrien og store mainframes i bankvæsenet.

Som ny virksomhed er man ikke belastet af gode rabataftaler og vendor lock-in, så jeg forestiller mig i min naivitet, at det kan lade sig gøre at scale out, hvis man indretter sit netværk efter det. Selvfølgelig vil der være cases, hvor det er en bedre forretning at scale up (fx er en 10 Gbit/s fiber billigere end 10 x 1 Gbit/s), men det må kunne løses smartere og billigere end at "købe en større boks".

  • 1
  • 0
Jn Madsen

Lige netop dét er der vist ingen tvivl om længere ;-)

LOL ... det så jeg ikke før nu,- det må have været min underbevidsthed der skrev den der ... kanon :-)

De store ISP'er har et andet regnestykke.
Det starter med fiberen. Fiber kapacitet er en mangelvare mange steder, og det er rasende dyrt at grave nye ned. Gravetilladelser kan også tage en evighed.

(Jeg kunne nævne sjove historier, hvor det ene kontor i en kommune er rasende over, at de stadig ikke har fået den lovede fiber,- men årsagen er et andet kontor i kommunen der ikke vil give gravetilladelse. ISP'en er så pludseligt mægler/stik-i-rend-dreng mellem 2 kommunale nabokontorer, der ikke vil holde frokost sammen. Den 4' part bliver så kommunens juridiske kontor,- der går ind og overvejer sagsanlæg pga manglende levering )

Så ISP'en regner på kapaciteter på fiber,- lige oven på kommer CWDM og DWDM systemer,- interfaces, transpondere, DSLAM, switche, routere ... LACP der ikke altid load-sharer optimalt => derfor er det bedre at gå op i hastighed på et interface. ISP'ernes peering er som regel over et interface,- der slipper man ikke for 100G alligevel. Det udelukker fra starten af en del low-end udstyr,- især hvis man skal bruge 20-40 100G interfaces på en central router.

Så det er et større regnestykke man har,- og routere er kun en mindre del af det hele.

Jeg tror nu, at det i Danmark mest kun er en håndfuld eller 2 firmaer der arbejder med de regnestykker.

Vendor lock-in har fanden skabt,- det er noget man gør alt for at undgå. Ingen proprietære løsninger, provisionerings-værktøjer der er nemme at tilpasse.
TDC har historisk altid haft en fler-leverandør politik. Når den ene blev for fræk,- så truede man bare med den anden.
Leverandørerne ved også godt, det gælder om at "rådgive" kunden til en løsning, så kunden ikke nemt kan skifte leverandør. Det er et spil hvor alle er luskede :-)

  • 2
  • 0
Baldur Norddahl

Det udelukker fra starten af en del low-end udstyr,- især hvis man skal bruge 20-40 100G interfaces på en central router.

Peak fra samtlige danske lidt over 2 millioner husstande må være på omkring 2000G. Det går ikke alt igennem den samme router :-)

Hjemmebygger løsningerne kan ikke være med når det begynder at blive seriøst. Men kan sagtens bygge en ISP med 10.000 husstande eller mere på softwareløsninger. Man behøver jo hellere ikke sende alt trafikken gennem den samme router.

  • 1
  • 0
Jn Madsen

Peak fra samtlige danske lidt over 2 millioner husstande må være på omkring 2000G. Det går ikke alt igennem den samme router :-)

Jeg lover dig,- det er ikke for sjov, at en dansk ISP nu bruger 1 Tera kantroutere til forsyning til visse geografiske områder.
Corerouterne er så en del større.

At sige man ikke behøver udstyr i den tunge ende,- det er det samme som at sige, at Danmark ikke behøver motorveje og landeveje for at forbinde landsdelene. Det hele fungerer fint med en hulens bunke små grusveje.

Men som sagt,- for netværksfolk er det et helt specielt område.
Alle andre steder,- der kan vi lege mere med løsningerne. Heldigvis, eller var netværk da kedelig at rode med. :-)

  • 0
  • 1
Jn Madsen

Du skal også huske på, at redundans skal indregnes.
Trafikken skal stadig komme igennem, selv om interface X brænder af samtidigt med at kloakmand Peter kværner en megafiber Y med sit trykluftværktøj.
Sådan noget er dagligdag,- nettet skal redde den slags automatisk uden menneskelig indgriben.

  • 0
  • 0
Yoel Caspersen Blogger

Jørn, har du nogle gode kilder til viden om SDN? Meget af det materiale, der umiddelbart ligger på nettet, er salgspræsentationer fulde af buzzwords, som jeg er vaccineret imod, men jeg kunne godt tænke mig at vide noget konkret om det for at kunne danne mig en oplyst holdning til det ;-)

  • 3
  • 0
Jn Madsen

Du har helt ret,- det flyver rundt med smarte ord. Cisco, HP, Juniper og alle de andre,- de har samlet bolden op, og bruger det i deres reklamer som om de har patent på det og fået det optimeret. De er fulde af fup.
Rent mareridt for os der prøver at forstå.
Manden der oprindeligt udviklede det ... lige glemt hans navn ... han siger han ikke længere kan finde ud af hvad det er. SDN er blevet et smartass ord, som alle bruger, oftest i forkert kontekst.

Men selve kernen,- den er der endnu. Hvis du vil lige til biddet, og ikke spilde oceaner af tid (som jeg har gjort), så er er der en side de rigtigt aktive udviklere er på:

https://www.sdxcentral.com/flow/sdn-software-defined-networking/

Det der fik mig til at "fange" den, det var dette billige kursus -29$ (de har vist noget juletilbud lige nu). Det fik en masse brikker små brikker til at falde på plads hos mig. Lynende dygtig fyr, godt udviklede materialer, han forklarer tingene kanon:

http://academy.gns3.com/courses/a-practical-sdn-and-openflow-introduction

Men ja,- det er svært at få neglene i,- men du kan kode, du kan Linux og du ved meget om netværk. Du fanger den nok meget hurtigere end mig. Jeg sveder stadig som et svin over kodning og Linux,- selv efter nogle års øvelse :-)

  • 1
  • 0
Jn Madsen

Hvad hulen sker der for mine fingre?
Vrøvler .. "brikker små brikker" ... nå, du forstår nok hvad jeg mener :-)

De kunne godt give lidt længere frist til at redigere ... så os med fingre uden for kontrol, også kan nå at rette vores fejl ...

  • 0
  • 0
Jens Jönsson

Du skal også huske på, at redundans skal indregnes.
Trafikken skal stadig komme igennem, selv om interface X brænder af samtidigt med at kloakmand Peter kværner en megafiber Y med sit trykluftværktøj.

Hvor mange ISP'ere i Danmark har redundans på corenettet ? Vi har flere gange hørt om at store områder har været uden forbindelse efter overgravning af fiberkabel....

  • 0
  • 0
Jn Madsen

Hvor mange ISP'ere i Danmark har redundans på corenettet ? Vi har flere gange hørt om at store områder har været uden forbindelse efter overgravning af fiberkabel....

De største har omfattende redundans,- men "shit happens", du ved.
Core nettene har fuld redundans hos de store,- ofte tredobbelt,- men ting går alligevel galt.

Den ene fiber vej bliver hakket over, mens den anden er under service, eller flere interfaces brænder af på samme tid. Statistisk umuligt, men det sker alligevel.
Underlige bugs popper stadig op i software,- strømudfald,- og nogen har stjålet dieselen til generatorerne,- og overvågningen på tanken virkede ikke.

Shit happens ... og det er i virkeligheden ikke så tit de store udfald sker? Små regionale udfald hvor er ikke er redundans, skal ikke forveksles med core udfald.

  • 1
  • 1
Baldur Norddahl

Hvor mange ISP'ere i Danmark har redundans på corenettet ? Vi har flere gange hørt om at store områder har været uden forbindelse efter overgravning af fiberkabel....

0 0

Der mangler redundans i accessnettene. Og de accessnet kan dække enorme geografiske områder.

Sidst vi hørte om en overgravning var det YouSee. Næsten halvdelen af YouSee nettet forsynes fra fire telefoncentraler: Hillerød, Virum, Borups Alle og Hedehusene. Der er da givetvis redundans mellem de nævnte fire centraler. Men fra central (CMTS) og ud til kunden? Nix.

En CMTS konverterer fra IP/Ethernet til Docsis/DVB. Herfra er det et analogt signal. Så hvis du bor på nordkysten, så kommer dit analoge signal i sidste ende fra noget udstyr der står i Hillerød. Man kan i princippet godt lave redundans på et analogt signal. Der er udstyr der måler lysstyrken på den primære fiber. Hvis den går i sort, så skiftes automatisk til backup fiberen. Men mig bekendt er det ikke noget man i stor stil har ofret på kabelnettet.

Et andet eksempel er TDCs accessnet. Der er naturligvis ikke redundans på kobberkablet (eller fiberkablet) fra din bolig og ud til DSLAM. Og nævnte DSLAM er også et single point of failure. Men derudover så har DSLAM ikke redundant fiber uplink. Derfor er udstyret (en access switch) i den anden ende af dette fiber uplink også single point of failure. Herfra er der en fiberring der omfatter en håndfuld centraler. Ringen er i de fleste, men ikke alle, tilfælde redundant. Men TDC tilbyder ikke redundant adgang til ringen, det skal ske ved en POI port hvor en TDC access router bliver single point of failure, linket fra TDC access routeren til ISP access router er single point of failure og ISP access router er single point of failure.

Når Yoel kæmper som en brav mand for at undgå at have et single point of failure i hans integration med transportnettet, så bør man måske bare indse at der alligevel er en lang kæde af single points of failures og komme videre i livet... Den nemmeste måde at løse STP udfordringerne er at acceptere endnu et single point of failure men at gøre dette så solidt som muligt og have en hot/cold spare klar.

  • 4
  • 0
Jn Madsen

Helt rigtigt, Baldur.

Nu spurgte Jens specifikt til redundans i core nettet, så det var det jeg svarede på.

Naturligt nok, jo tættere man kommer på kunden, jo mindre redundans er der,- med mindre kunden specifikt køber en grad af redundans,- der så kan gradbøjes i mange trin. (dobbelt strømforsyning/batterier/dobbelt udstyr/flere fremføringsveje/forskellige termineringer osv osv)

En "normal" DSL kunde vil have en lang række af single point of failures (SPOF) fra sit hjem hele vejen til sin DSLAM. Hjemmets udstyr, kobberet/coax/fiber,- hele vejen til første centralpunkt.
DSLAM'en kan have 2 fibre i nakken,- men ikke altid (nok de færreste gange), og DSLAM'en selv er også SPOF (som du siger).
Det kribler for at fortælle lidt mere,- men jeg må nok respektere tavsheds klausuler, så jeg holder mig til ting der er almindeligt kendt :-)

Ringene er per design redundante.
Afhængigt af ISP,- der vil være redundans fra DSLAM terminering (uplink switch) ind mod coren,- her er der mange forskellige løsninger,- men de ISP'er jeg kender har redundans. De mindre ofrer nok ikke den udgift.

Centraler har altid flere udgange,- men som jeg beskriver lidt højere oppe,- shit happens :-)

PS, -jeps, det er fedt at læse om Yoel's projekt, fandme friskt gået, respekt her fra :)

  • 1
  • 0
Jn Madsen

Det har vist hjulpet lidt på de pludselige fejl, at man har forhøjet taksten for reparation på skader på fiber.

Før i tiden, når en entreprenør stod med 10 mand og et par gravemaskiner til mange tusinde kroner i timen,- og han ikke havde undersøgt forholdene ordenligt,- og han så mødte en fiber i jorden,- så sagde han vist bare "fuck det, grav lortet over". Det var næsten gratis.

Nu koster det lidt gysser,- det har hjulpet lidt på grave-iveren, og de har også lært at ringe først og spørge om der er noget i jorden der hvor de vil grave.

Det har hjulpet lidt på stabiliteten. Det er ikke så sjovt når den ene stækning er under service,- og Byggemand Bob tæsker løs på den redundante fiber med sin gravko :-)

  • 1
  • 0
Baldur Norddahl

Afhængigt af ISP,- der vil være redundans fra DSLAM terminering

Nej. Det vil være ulovligt. TDC må ikke tilbyde aftaler uden at tilbyde dem til alle, og redundant adgang til ringene er ikke en mulighed. Ej heller redundant adgang på POI1 niveau. Og redundant adgang på POI0 niveau har TDC ikke engang selv. Redundant adgang på POI3 niveau er i beta og bliver testet af flere selskaber pt.

Jørn - jeg ved ikke hvad du har lavet hos TDC. Men husk hvem du taler med her - vi (flere virksomheder repræsenteret i disse tråde) er TDC Wholesale kunder. Hvis der er nogen der ved hvordan TDCs interface er imod alternative operatører, så er det os - det er nemlig os der er kunderne.

Der er ikke noget af det her der er hemmeligt. Alle kan læse det direkte fra TDC selv: https://wholesale.tdc.dk/wholesale/produkter/aftaler/Sider/productadditi...

  • 1
  • 0
Jn Madsen

Nej. Det vil være ulovligt.

Hov hov,- det er ikke det jeg mener :-) (jeg kan godt se formuleringen kan tolkes på den måde).

Det jeg siger, det er at det er muligt ved nogle DSLAM at have 2 fibre i nakken som redundant uplink.

Jeg siger ikke, at det er noget man tilbyder til nogen og ikke til andre. Sådan arbejder man selvfølgeligt ikke.

Jeg havde ikke set min formulering kunne tolkes på andre måder :-)

Helt korrekt,- vi holder os selvfølgeligt kun til oplysninger der almindeligt kendte her.

  • 0
  • 0
Jens Jönsson

Der mangler redundans i accessnettene. Og de accessnet kan dække enorme geografiske områder.

For den ukyndige er det ekstremt svært at kende forskel på core og accessnet.
F.eks. havde GC et stort nedbrud på Fyn (kan ikke huske hvornår), nærmere betegnet Odense. Det havde indflydelse over hele Fyn. Her tænkte jeg bare, at det er underligt at så mange trækkes med i faldet, har man vitterligt ikke mere redundans.

Det har vist hjulpet lidt på de pludselige fejl, at man har forhøjet taksten for reparation på skader på fiber.

Det er vel bare kravet om at man >skal< checke i LER inden gravning, ellers er det for egen risiko og regning der gør sig gældende.

  • 1
  • 0
Log ind eller Opret konto for at kommentere