Dagbog-bloggen

ZTE - alternativ søges!

Af 26

Det er ingen hemmelighed, at vi hos Kviknet anvender hardware fra ZTE på visse strækninger af vores backbone-net.

Derfor kommer ZTE's problemer også på et træls tidspunkt, for at sige det på godt jysk. Vi står nemlig over for en opgradering af kapaciteten, og noget kunne tyde på, vi bliver nødt til at finde et alternativ til ZTE.

Kravsspecifikation

Vi skal bygge et antal redundant forbundne fiberringe, hvor hver node på ringen er en switch eller router på en TDC-central.

Illustration: Yoel Caspersen

Trafikken skal kunne gå fra en vilkårlig central til en anden på en forudsigelig vis, og nettet skal kunne overleve et kabelbrud mellem to centraler uden at trafikken afbrydes. Konvergenstiden skal ideelt set være under 1 sekund, men ellers som minimum under 30 sekunder.

Kapaciteten på hvert link skal være 40 Gbit/s, og vi vil gerne kunne opgradere til 100 Gbit/s, når prisen på 100 Gbit/s transceivers falder.

Derfor er det ideelt, hvis noden har 2 x 100 Gbit/s QSFP-28 uplink-porte med support for 40 Gbit/s transceivers. Noder, der forbinder to ringe, skal i sagens natur have 4 uplink-porte i stedet for 2.

Hver node skal også have minimum 4 x 10 Gbit/s access-porte.

MTU på kundetrafik skal være minimum 1500 bytes, og encapsulation m.v. skal derfor lægges oveni. MTU på det enkelte interface i noden bør givetvis være 1600 bytes eller derover.

IP-pakker skal i det enkelte flow ankomme i samme rækkefølge, som de bliver sendt.

På den enkelte central opsamler vi trafik fra kunder på TDC's netværk som QinQ-trafik, dvs. layer 2.

Trafikken skal afleveres på samme måde på 2 udvalgte lokationer i nettet.

Illustration: Yoel Caspersen

Transport af layer 2-trafik

Så vidt kravsspecifikationen - nu til lidt teori.

Layer 2-trafik skal før eller siden "konverteres" til layer 3-trafik i en såkaldt BNG (Broadband Network Gateway).

BNG'en er den enkelte kundes default gateway og er i bund og grund blot en router, som kan aggregere flere kunde-VLANs i samme IP subnet.

For hver BNG, vi har i vores net, spilder vi et antal IP-adresser, da der skal sættes hele scopes af til hver BNG.

Med Kviknets nuværende størrelse vil det være overkill at anbringe en BNG på hver enkelt telefoncentral, og vi nøjes derfor med at placere BNG'er to indbyrdes uafhængige steder i nettet, så vi har redundans via VRRP.

Det kan vores nuværende backbone-netværk, da det er baseret på MPLS.

Med MPLS kan man lave en L2VPN (layer 2-forbindelse) fra et vilkårligt punkt i nettet til et andet, og det betyder, at vi både kan transportere VLANs fra den enkelte kunde til en BNG, men også mellem kunderne indbyrdes, hvis vi fx skal bygge et privat net mellem to forskellige afdelinger i en virksomhed.

Ulempen ved MPLS er, at hardware med understøttelse for MPLS generelt er dyrere end hardware uden.

Det skyldes sandsynligvis, at MPLS er en nicheteknologi, der primært anvendes i telesektoren, mens det er datacentermarkedet, der med sit væsentligt større volumen driver udviklingen inden for netværkshardware.

Hvis man ikke selv betaler for sit legetøj, er netværksteknikerens foretrukne valg lige for tiden en router fra Juniper med MPLS-support.

Men som en low-cost ISP-on-a-shoestring er vi nødt til at undersøge, om der findes en mere kosteffektiv løsning - og den har hidtil heddet ZTE.

Medmindre vi finder et alternativ til ZTE, der har MPLS-support til overkommelig pris, er det muligt, vi skal overveje at droppe MPLS som underliggende protokol i nettet.

Et interessant alternativ til L2VPN kan være VXLAN, hvor man transporterer sin layer 2-trafik indkapslet i UDP-pakker via et helt almindeligt layer 3-netværk med support for MTU >= 1550 bytes.

Derved kan man bygge et billigt, routed netværk baseret på layer 3-switche med OSPF-support. Det vil være en relativt primitiv løsning sammenlignet med et full blown MPLS-netværk med traffic engineering, men det vil givetvis være godt nok til vores behov, der primært handler om at transportere layer 2-trafik fra A til X og Z i vores netværk på en redundant og forudsigelig måde.

Dertil kommer, at VXLAN ser ud til at være fornuftigt supporteret på Linux.

Hvad siger netværksfolkene derude - er der et godt, prismæssigt sammenligneligt alternativ til ZTE, med eller uden MPLS, hvis vi skal transportere layer 2-trafik inkl. QinQ-trafik fra et vilkårligt sted i vores net til et andet?

Kommentarer (26)
Kenn Leth Hansen

Har i overvejet at kigge i retning af disaggregated networking? Det er modent på datacentermarkedet, men kommer nok aldrig helt til ISP-markedet netop pga. manglende support for MPLS.

De helt store chipsetfabrikanter er Mellanox og Broadcom, hvor Broadcom med Trident2+, Maverick og Tomahawk har mange features til fornuftige priser. Og det bedste er at der findes masser af NOS leverandør med styresystemer til switchene.

Selv sidder jeg pt. med nogen Broadcom Maverick baserede switches med Cumulus Linux ovenpå som OS. 1/10/25/50/100G porte og masser af features håndteret i switching ASIC, herunder VxLAN, L3 routing, etc.

Cumulus er lækkert at arbejde med når man er vant til Linux, og så er Cumulus contributer til FRRouting (fork af Quagga) of mange andre open networking projekter hvilket er et plus i min bog.

Yoel Caspersen Blogger

Har i overvejet at kigge i retning af disaggregated networking? Det er modent på datacentermarkedet, men kommer nok aldrig helt til ISP-markedet netop pga. manglende support for MPLS.

Det er faktisk noget, vi har haft oppe at vende flere gange, og jeg synes tanken er interessant.

Ikke mindst fordi vi må konstatere, at rigtig meget firmware til netværksudstyr er noget fejlfyldt skrammel.

Hvis man skulle blive lidt konkret, hvilket prisleje taler vi om, hvis man går i den retning? Jeg er med på, at udviklingstid, support etc. skal lægges oveni, men selve hardwaren og Cumulus Linux - hvad koster en node, der kan bruges i vores eksempel?

Morten Brørup

Her er et par uddybende spørgsmål:
Er der sort fiber mellem noderne, eller skal trafikken transporteres over en specifik protokol?
De indgående pakker fra kunderne skal ud til begge BNG'er (altså to kopier af hver pakke), eller blot til en af dem?
Pakkerne er QinQ både ind og ud, og skal ikke re-tagges af noderne?
Du har ikke brug for nye BNG'er?
Skal noderne switche eller route trafik vedrørende private L2-tunneller mellem en kundes flere lokationer? (Da det er L2-tunneler skal de vel switches, men man ved jo aldrig…)
Hvilket interface skal nodernes porte til BNG'erne have?

mvh
Morten Brørup
CTO, SmartShare Systems

Yoel Caspersen Blogger

Er der sort fiber mellem noderne, eller skal trafikken transporteres over en specifik protokol?

Der er sorte fiberpar, single mode, mellem noderne.

De indgående pakker fra kunderne skal ud til begge BNG'er (altså to kopier af hver pakke), eller blot til en af dem?

Blot en af dem. Hver BNG har en IP-adresse i samme scope som kunden, og vha VRRP styres det, hvilken BNG agerer default gateway for kunden. Download-trafik (set fra kundernes side) kan komme fra en vilkårlig BNG, afhængigt af hvor trafikken kommer fra.

Pakkerne er QinQ både ind og ud, og skal ikke re-tagges af noderne?

Pakkerne er QinQ både ind og ud. Outer tags må gerne pilles af under transport, så længe de sættes på igen når trafikken forlader netværket.

Hver node i netværket skal håndtere en POI-port, hvor QinQ-trafik udveksles med TDC. En POI-port har typisk mellem 1 og 5 forskellige outer VLAN tags. Det er således en overkommelig opgave at konfigurere en separat tunnel pr. outer VLAN tag mellem POI og BNG, således trafikken inde i tunnelen er single tagged. Men tunnelerne skal skilles ad på BNG'en, så outer tag skal sættes på igen før trafikken afleveres til BNG'en.

Du har ikke brug for nye BNG'er?

Nej - ikke som en del af dette projekt. Jeg er dog på udkig efter en bedre løsning, end den vi har, men det kommer i et senere blogindlæg.

Skal noderne switche eller route trafik vedrørende private L2-tunneller mellem en kundes flere lokationer? (Da det er L2-tunneler skal de vel switches, men man ved jo aldrig…)

Switching er nok at foretrække, men det er ikke 100 % afklaret for nuværende.

Hvilket interface skal nodernes porte til BNG'erne have?

n x 10 Gbit/s i et LAG.

Morten Brørup

De indgående pakker fra kunderne skal ud til begge BNG'er (altså to kopier af hver pakke), eller blot til en af dem?

            Blot en af dem. Hver BNG har en IP-adresse i samme scope som kunden, og vha VRRP styres det, hvilken BNG agerer default gateway for kunden

Lad os for diskussionens skyld antage, at noderne ikke snakker VRRP. Er det så ligegyldigt, hvilken af de to BNG'er, noderne afleverer kundens trafik til, blot det er den samme BNG hele tiden?

Kenn Leth Hansen

Hvis man skulle blive lidt konkret, hvilket prisleje taler vi om, hvis man går i den retning? Jeg er med på, at udviklingstid, support etc. skal lægges oveni, men selve hardwaren og Cumulus Linux - hvad koster en node, der kan bruges i vores eksempel?

Jeg kan afsløre at det er billigt, men samtidig også afhænger af om du køber Cumulus Express (hardware + software fra Cumulus) eller køber hardware andetsteds, f.eks. via Dell.

Vi kan tage en snak udenfor dette forum omkring de priser vi landede på. Hvordan fanger jeg dig?

Jonas Hauge

Jeg er enig i at hardware som kan levere et ordentligt MPLS featureset har en højere kost en switchene - i jeres scenarie vil I dog kunne spare tid ift redesign ved at vælge noget der kan indsættes 1-1 i jeres nuværende netværk. Noget du selv er ganske opmærksom på.

Du nævner selv Juniper, hvis man ikke kigger på pris. Har I konkret forhørt jer om prisen på f.eks. MX204? Den opfylder reelt set alle jeres behov i 1RU.

Alternativt, hvis man skal kigge på VXLAN tankegangen, så vil jeg klart gå med en Mellanox-switch for at undgå problemer med f.eks. buffer management på Broadcom Tomahawk. Disse kan købes inklusiv Cumulus licens, hvilket er noget billigere end at købe det hver for sig.
Der er lige kommet en SN2010 på markedet med 4 x QSFP28 + 18 x SFP+/SFP28 porte. Er godt klar over at I ikke har behov for 25G :-)

Giv lyd, hvis jeg skal uddybe yderligere.

(NB: Skal lige nævnes at jeg sidder som teknisk rådgiver hos distributøren som sælger både Juniper og Mellanox i Danmark, men ovenstående er skrevet ud fra egen holdning).

Joachim Jerberg Jensen

Hej Yoel,

Du bør se på Cisco NCS 5500 platformen, tænker 5501 vil passe perfekt til dette formål. Med -SE versionen for du fuld internet routing table samt ekstra dybe buffers.
Alternativt er NC540 som er meget prisattraktiv! Begge køre den nye 64 bit IOS-XR, MPLS, EVPN og SR med Linux og containers samt et Netconf API.

Din fysiske ring topologi kræver desuden Topology-Independent LFA for sub 50ms konvergering, og med Segment Routing kan du lave 100% LFA'er i en hvilken som helst topologi, samt Traffic Engineering og unequal path load-balancing hvis du vil.

Dine BNG'er bør du overveje at lave fuldt virtuelle XRv9000 (40G og 32K subscribers på en X86), med statefull sync. Termineringen af BNG sessionen kan du evt. lave med Pseudowire Headend helt ude fra din access-porte på NCS platformen.
MEF services bør du se på om du kan levere med Ethernet VPN og SR i bunden, det er fremtiden.

Mvh Joachim, Cisco

Michael Nielsen

Hej Yoel,

Intet galt i DIY, men der er også omkostninger, specielt hvis/når ting fejler og højere forretningsrisiko, som skal holdes op imod fleksibiliteten.

Dissaggregate Netværk er interessant og noget som f.eks. AT&T har taget til sig, men der kræves en vis skala af ens support / udviklings organisation og netværksstørrelse for at påvise en god TCO vs. risk/reward. Jeg har ihvertfald ikke set det d.d. på små kunder, som efterfølgende kan drives af andre, hvis "experten" smutter fra firmaet.

Anyway - TCO kan laves på mange måder og er lidt som statistik.

Baseret på dine krav så ser Broadcom's Jericho chipset ud til at passe til dine krav, som flere netværksleverandører kan tilbyde inkl. Cisco - se f.eks. NCS-5501-Base. Den har 48x10/1G SFP+ porte + 6x100/40/10G QSFP28 porte. Du har dog ikke behov for mange access porte, så måske kunne en PAYG kapacitet løsning gøre initiel investeringen mindre ...

Det kombineret med EVPN ovenpå MPLS og påsigt Segment Routing, hvis når du får behov for nem traffic engineering uden TE tunneller.

Derudover giver operativ systemet IOS-XR på NCS 5500 mulighed for Telemetri, PCEF, BGP LS, Netconf / YANG m.m. for nem SDN WAN løsninger ud over CLI og SNMP. Ovenstående er hyldevare og end 2 end support fra en leverandør hvis / når der opstår problemer.

Yoel Caspersen Blogger

Du bør se på Cisco NCS 5500 platformen, tænker 5501 vil passe perfekt til dette formål. Med -SE versionen for du fuld internet routing table samt ekstra dybe buffers.
Alternativt er NC540 som er meget prisattraktiv! Begge køre den nye 64 bit IOS-XR, MPLS, EVPN og SR med Linux og containers samt et Netconf API.

Kan du klare den til under 50.000 kr. pr. node i det skitserede setup?

Jens Jönsson

Søreme så:

https://twitter.com/realDonaldTrump/status/995680316458262533

Trump spiller et helt andet slags spil end de fleste andre politikere, vi er vant til. Det bliver spændende at se, hvordan sagen udvikler sig.

Han er sgu snu. Hvor mange tror du køber ZTE produkter fremadrettet ?
Han får fortalt kinerserne at de skal holde igen, ellers sker der ting og sager.
Mon ikke ZTE forbliver en mindre spiller fremadrettet ?

De kigger sjovt nok også på Huawei, hvorfor mon....

Yoel Caspersen Blogger

Intet galt i DIY, men der er også omkostninger, specielt hvis/når ting fejler og højere forretningsrisiko, som skal holdes op imod fleksibiliteten.

På nuværende tidspunkt har vi oplevet flere situationer, hvor muligheden for hurtigt at kode en ændring i en vital komponent har gjort forskellen mellem et lille og et stort bump på vejen.

Som eksempel kan nævnes et tilfælde, hvor TDC omlagde en række coax-kunder fra DOCSIS 3.0 til DOCSIS 3.1. Indholdet af option 82 i DHCP-pakkerne blev fra det ene øjeblik til det andet ændret markant, og vi var nødt til at gentænke vores setup. Tyve minutter senere var der produceret en patch til DHCP-serveren, og de pågældende kunder kunne køre videre.

Havde vi i stedet baseret serveren på et proprietært, lukket produkt, havde vi haft et alvorligt problem.

I den ideelle verden køber vi et hyldevareprodukt, hyrer en tilfældig netværksmand fra gaden og glæder os over, at alting bare virker, og at vi kan udskifte netværksmanden, hvis han bliver for fræk. Men i praksis er det min oplevelse, at der er mærkelige fejl i alle former for udstyr, og at fleksibilitet og transparens er afgørende, når lokummet brænder.

I tilfældet ZTE lærte vi på den hårde måde, at man ikke skal bruge BVI-interfaces, selv om manualen og producenten hårdnakket påstår, de virker.

En softwarefejl i en Juniper-switch/router hos en underleverandør gjorde forleden, at en række kunder mistede forbindelsen til nettet i 15 minutters tid. Det var heldigvis i forlængelse af et servicevindue, men det kunne lige så godt være sket på et andet tidspunkt og have forårsaget væsentligt længere nedetid.

Pointen med dette er, at fejl også findes i hyldevarer, og modsat DIY-produkter er der ikke det store at gøre ved det, når fejlen optræder i hyldevaren. Vi får hverken ZTE eller Juniper til at kode et fix på 20 minutter, hvis overhovedet.

Jeg har ihvertfald ikke set det d.d. på små kunder, som efterfølgende kan drives af andre, hvis "experten" smutter fra firmaet.

Som mindre virksomhed er man ganske rigtigt sårbar over for tab af nøglepersoner. Det gælder nok i de fleste sammenhænge, men i særdeleshed, hvis der anvendes egen-udviklet software, som en enkelt medarbejder har udviklet. Hyldevarer kan muligvis hjælpe en smule på dette.

Jonas Hauge

Har du kendskab til, i hvilket omfang man kan køre single- og doubletagged trafik gennem en VXLAN-tunnel på en sådan switch? Så vidt jeg kan gennemskue, handler det (også) om implementationen på den enkelte platform.

Det kommer, ganske korrekt, an på både chippen og samspillet med aktuelle NOS. Jeg er igang med at grave i, hvad Spectrum chippen har af muligheder sammen med VXLAN og vlan-tags med Cumulus som NOS. Skal nok smide en update herinde, når jeg er blevet klogere.

Anser du VXLAN og Cumulus som modent til vores formål?

Jeg er ikke sikker på at jeg selv ville gå den vej. Centralt i nettet er det nok ikke et problem, hvor pakker bare skal routes hurtigst muligt - men man kunne nemt ramme ind i uforudsete feature- og skaleringsoverraskelser på kanten.

Et eksempel med VXLAN: https://docs.cumulusnetworks.com/display/DOCS/VXLAN+Scale - ikke at jeg ser I får brug for så mange VXLANs per node, men bare som underbygning af, at der er mange detaljer som skal overvejes.

Baldur Norddahl

ikke at jeg ser I får brug for så mange VXLANs per node

Men antallet af VLANs bliver meget højt. Det er et VLAN per kunde. 20.000 kunder = 20.000 q-in-q VLANs. Jeg synes det er lidt uklart om det er et problem ifølge den dokumention du linker til.

Antallet af VXLANs er cirka 300. Muligvis det dobbelte eller tredobbelte afhængig af hvordan man tæller (er hvert ben i en trekant et VXLAN - hvis ja, så bliver antallet cirka 900).

Man kan eksempelvis ikke implementere en BNG på Linux til det her. Der opstår et problem når du forsøger oprette mere end 1000 VLAN interfaces.

Joachim Jerberg Jensen

VXLAN er en enkapsulering lavet til datacenteret, for at løse konkrete udfordringer her.
I vil kun få problemer med VXLAN i jeres SP WAN.. Eks. er Håndtering af BUM - Broadcast, Unknown og Mulitcast, IPv6, VTEP/VNI scale mv.

I et SP WAN netværk bør i køre MPLS.. Det kan være enten SR, LDP eller RSVP baseret.

Mvh
Joachim

Yoel Caspersen Blogger

Men antallet af VLANs bliver meget højt. Det er et VLAN per kunde. 20.000 kunder = 20.000 q-in-q VLANs. Jeg synes det er lidt uklart om det er et problem ifølge den dokumention du linker til.

Hvis man kigger på Junipers dokumentation, ser det ud som om, det kan lade sig gøre at køre QinQ-trafik hen over en VXLAN-tunnel:

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/evpn-...

Hvis det også gælder for Cumulus, burde vi kunne holde antallet af VXLAN-tunneler nede på et håndterbart antal.

Nicklas Seehusen

Uden at have erfaringer eller kendskab til priser vil jeg sige at OcNOS ligner et spændende alternativ til Cumulus hvis man er service provider.

https://www.ipinfusion.com/products/ocnos/

Hvis refurbished hardware kunne blive aktuelt for at holde prisen nede, så er HP en af de få producenter som ikke har licenseret deres features, og software updates er tilgængelige uden en service kontrakt, hvilket gør det til et ideelt refurbished produkt ift. andre producenter som kræver service kontrakter og licenser.
H3C/HP har produceret udstyr med 10G SFP+/40G QFSP+ porte og MPLS feature i mange år (Comware OS - ikke Provision), så de ældste HP 5900 switche tror jeg du kan finde for under 10.000kr/stk med 48x10G+4x40G. Dog ville jeg kigge efter de nyere 5940 / 5950 med QSFP28. Umiddelbart bør du kunne finde sådan en HP 5950 med 48x 25G SFP28 + 8x 100G QSFP28 for ca. 30.000kr refurbished (søg på JH402A) - måske endda manufacturer refurbished så du også lige får en limited lifetime garanti med oven i. Portene er bagudkomptabile ned til 1G SFP.

HP 59xx-serien er "datacenter switche", men så længe man ikke skal have store routningstabeller ville jeg sige de er ligeså valide som noget der officielt er et service provider produkt.
Sådan lige opsummeret - 136k mac table, MPLS, vlan-mapping 1:1/1:2/2:2, Netstream support (Netflow/IPFIX), support for alle routnings protokoller, native ipv4/ipv6.
Kig listen af features her fra side 22 (dog er MPLS L2VPN ikke i listen, men tilføjet som feature på side 2, hmm):
http://h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-a00038185en_us-4.pdf
(de fås også med DC psu'er også JH402A er en af de få 59xx'ere som kun er 46cm i dybden som er noget mere optimalt end de 60-70cm dybe modeller).

Uanset om det er 5900, 5920, 5930, 5940 eller 5950 ville jeg dog kigge dokumentationen igennem for at sikre sig om de features man forventer er der, og hvordan de skalerer. Som dit netværk er designet kunne du godt rende ind i skaleringsproblemer på meget af det klassiske netværks-jern - der kan nemt ligge en showstopper at lure.

Yoel Caspersen Blogger

HP 59xx-serien er "datacenter switche", men så længe man ikke skal have store routningstabeller ville jeg sige de er ligeså valide som noget der officielt er et service provider produkt.

Helt enig, HP's Comware-serie er generelt noget udmærket grej. Prisen er dog højere end tilsvarende ZTE-udstyr, men kvaliteten er generelt høj. Jeg har dog ikke arbejdet med MPLS på Comware, så har ingen førstehåndserfaring med den del.

Uden at have erfaringer eller kendskab til priser vil jeg sige at OcNOS ligner et spændende alternativ til Cumulus hvis man er service provider.

Det ser spændende ud. Men man skal dog lige holde sig for øje, at prisen tilsyneladende er $4799 for OS med MPLS alene, og så kommer prisen for switchen oveni.

Log ind eller Opret konto for at kommentere
Tip redaktionen
Dette websted anvender cookies til at huske dine indstillinger og statistik. Denne information deles med trediepart.
Ok