yoel caspersen blog bloghoved

Software-router del 2: Praktiske øvelser

I vores sidste debat kom vi ind på, om software-routing vitterligt er en gangbar løsning, og der ser ud til at være flere, der mener, at man sover bedre med en hardwarebaseret løsning.

Det er sandsynligvis korrekt, men spørgsmålet er, om software-routing vitterligt giver grund til at sove dårligt om natten.

Lidt data fra den virkelige verden

Fra et andet projekt har jeg data fra en software-router, som indtil nu har kørt i 184 dage. Serveren er en low-end IBM x3550 M3-server med 32 GB RAM og 2 stk. quadcore Xeon-processorer - den kører Ubuntu 14.04 LTS med Quagga 0.99.22.4, som er en smule bedaget og er den, der ligger i repositoriet til Ubuntu 14.04 LTS.

Den kører fuld route-tabel via BGP, og den er udstyret med et enkelt Intel x520 10 Gbit/s interface, der både håndterer ind- og udgående trafik. På de 184 dage, serveren har kørt, har den forwarded ca. 6,66 petabytes trafik. Der har ikke været et eneste nedbrud i den periode, og Quagga har ikke været genstartet.

Serveren har endda kørt med connection tracking, hvilket også tager ressourcer fra maskinen, og i gennemsnit har den haft et peak load average på ca. 1,1 - og da der er 8 kerner på maskinen, må det siges at være helt acceptabelt.

Ved dagligt peak har serveren forwarded ca. 5 Gbit/s fordelt på ca. 4.000 brugere. Det har primært været TCP-trafik.

Dette er empiriske data, og selv om man ikke skal tillæge anekdotisk bevisførelse større værdi, bekræfter det mig i, at man godt kan bygge et stabilt system baseret på software-routere, så længe vi taler om båndbredder i denne størrelse. Kommer vi op i større båndbredder, er det muligt, at billedet ændrer sig drastisk.

Testopstilling

Det har været foreslået, at vi laver en løsning, hvor vi kombinerer hardware- og software-routing og holder prisen i bund. Det er en udmærket tilgang, og det kan sagtens ske, at det bliver det, vi gør i sidste ende, men lad os først se, hvad der kan lade sig gøre i en ren software-router.

Jeg har bygget følgende opstilling:

Illustration: Privatfoto

Som tidligere nævnt er de servere, jeg anvender i projektet, low-end Fujitsu-servere til ca. 6.000 kr. stykket. Hvis man ofrer 2.500 kr. mere pr. styk, kan man smide et 10 Gbit/s Intel-kort i, men det er ikke med i dette projekt.

Ubuntu er installeret via netboot - mest fordi det var nemt og bekvemt, og fordi der var en bug i Ubuntus installer, der gjorde, at standard ISO'et ikke virkede out-of-the-box på en USB-nøgle. Jeg har lagt /var på en separat partition, så serveren ikke går ned, hvis et program ved et uheld får skrevet for meget data ned i sin log-fil.

Da jeg gerne vil have mulighed for at anvende Equal-cost multipath-routing, er jeg nødt til manuelt at kompilere og installere den nyeste version af Quagga.

I mit setup har jeg to routere, router-1 og router-2, der kobler op til hver sin udbyder via BGP. Herfra modtager de en fuld route-tabel på både IPv4 og IPv6, og der er også etableret iBGP-sessions mellem de to routere, der begge anvender vores AS-nummer AS204151.

iBGP er BGP mellem to enheder, der anvender samme AS-nummer, dvs. intern routing. Til iBGP er det generelt god latin at anvende loopback-adresser, da disse altid er oppe og derved mindsker sandsynligheden for route flaps.

Her et eksempel på iBGP-konfiguration for IPv4 og IPv6 på router-1:

interface lo
 ip address 185.107.12.17/32
 ipv6 address 2a06:4000:0:1::1/128
 link-detect
!
router bgp 204151
 bgp router-id 212.98.127.94
 network 185.107.12.0/22
 neighbor 185.107.12.18 remote-as 204151
 neighbor 185.107.12.18 update-source lo
 neighbor 185.107.12.18 next-hop-self
 neighbor 185.107.12.18 soft-reconfiguration inbound
 neighbor 2a06:4000::2 remote-as 204151
 neighbor 2a06:4000::2 next-hop-self
 maximum-paths 4
!
 address-family ipv6
 network 2a06:4000::/29
 neighbor 2a01:7e8:1:800::1c1 activate
 neighbor 2a01:7e8:1:800::1c1 soft-reconfiguration inbound
 neighbor 2a06:4000::2 activate
 neighbor 2a06:4000::2 soft-reconfiguration inbound
 exit-address-family

Udfordingen ved loopback-adresser er, at begge ender af linket skal vide, hvor den anden endes loopback-adresse er. Dette kan klares ved en statisk route i hver ende, der peger på den anden ende som next-hop for den anden endes loopback-adresse, men man kan også anvende en dynamisk route-protokol, der automatisk forwarder en routers route-tabel til resten af netværket.

I mit projekt har jeg anvendt OSPF (IPv4) og OSPFv3 (IPv6) til dette formål.

interface bond0.2
 ipv6 ospf6 cost 1
 ipv6 ospf6 priority 0
 ipv6 ospf6 network point-to-point
!
router ospf6
 router-id 1.1.1.1
 log-adjacency-changes
 redistribute connected
 interface bond0.2 area 0.0.0.0
!
router ospf
 log-adjacency-changes detail
 redistribute connected
 network 185.107.12.0/29 area 0.0.0.0

Nu er de to routere klar til at forwarde trafik, men vi vil gerne have en smule sikkerhed på systemet. Derfor skal vi have sat en firewall op, og her vil jeg gerne undgå connection tracking for den del af trafikken, der blot skal forwardes og ikke har selve serveren som afsender eller modtager.

Når tracking er skidt

Connection tracking er en vigtig komponent i en firewall, da det gør den stateful - herved kan man fx generelt forbyde indgående trafik, medmindre det er svar på en udgående forespørgsel.

I en router er connection tracking derimod formålsløs og optager en masse ressourcer, som vi i stedet kan bruge på at forwarde pakker. Vi skal dog stadig have tracking på de forbindelser, serveren selv initierer og gerne vil have svar på - det er fx BGP sessions, download af softwareopdateringer, SSH-trafik til management m.v.

Som altid kan magien klares i iptables:

# Make sure we track incoming and outgoing connections
# Add all local IP addresses of this machine here
iptables -t raw -A PREROUTING -s 185.107.12.1 -j ACCEPT
iptables -t raw -A PREROUTING -d 185.107.12.1 -j ACCEPT
iptables -t raw -A PREROUTING -s 185.107.12.33 -j ACCEPT
iptables -t raw -A PREROUTING -d 185.107.12.33 -j ACCEPT
iptables -t raw -A PREROUTING -s 185.107.12.49 -j ACCEPT
iptables -t raw -A PREROUTING -d 185.107.12.49 -j ACCEPT
# Don't track forwarded connections
iptables -t raw -A PREROUTING -j NOTRACK

Der kan og bør oprettes tilsvarende regler for IPv6-trafik. Derudover skal der åbnes for de specifikke services, routeren skal tilbyde, samt for management-adgang på et separat netværk.

Forbindelsen skal holdes i live

Redundansen opnås i core-netværket ved, at de deltagende maskiner kører route-protokollerne OSPF, OSPFv3 og BGP. På den måde sikres det, at alle maskinerne ved, om deres next-hop er oppe eller ej.

Det er dog ikke praktisk at anvende route-protokoller uden for core-netværket, dels på grund af sikkerheden, men også fordi mange netværksenheder uden for core-netværket hverken kan eller bør have en fuld route-tabel, men i stedet har en default gateway.

Derfor anvender vi VRRP, når vi skal sikre redundans på fx transportnetværket ud til en boligforening.

VRRP er en protokol, der gør det muligt for flere devices at deles om den samme IP-adresse - og i dette tilfælde er det gateway-adressen i boligforeningens subnet, der skal overtages af en backup-router, hvis den primære router går ned.

Inden for Linux-verdenen er det store hit Keepalived, som har en god track-record.

Den version, der følger med Ubuntu 14.04 LTS er dog håbløst gammel, så her bør man også manuelt kompilere nyeste version selv. Her er et eksempel på, hvordan den kan konfigureres:

vrrp_instance v30 {
        interface bond0.30
        virtual_router_id 30
        advert_int 1
        priority 100
        virtual_ipaddress {
                185.107.12.33/29
                fe80::1/64
                2a06:4000:0:2::1/64
        }
        notify_master "/bin/echo MASTER > /tmp/vrrp.status"
        notify_backup "/bin/echo BACKUP > /tmp/vrrp.status"
        notify_fault "/bin/echo FAULT > /tmp/vrrp.status"
}

I dette tilfælde har jeg oprettet et subnet til en kunde og reserveret de første to IP-adresser til VRRP.

Master-konfigurationen på router-1 er identisk med konfigurationen på router-2, med den lille forskel, at router-2 har priority 50. Det sikrer, at router-1 altid vil blive anvendt som gateway, hvis den er oppe.

For det næste subnet, vi opretter, bør vi anvende router-2 som master, da vi således kan balancere den udgående trafik også.

Hvad mangler vi herfra?

Jeg har en lille udfording, det ikke er lykkedes mig at løse endnu. Jeg har været nødt til at opsætte iBGP på IPv6 ved at anvende link-adressen og ikke loopback-adressen.

Enten er der en bug i Quagga, eller også har jeg ramt grænsen for min viden, for når jeg forsøger at sætte iBGP op vha. loopback-adressen på IPv6, forsøger den anden router at indsætte 127.0.0.1 som next-hop på IPv6, hvilket naturligvis fejler.

Skarpe læsere vil desuden bemærke, at vores to forskellige udbydere p.t. er samme AS-nummer på to forskellige P2P-links. Det skyldes, at vi endnu ikke har vores sekundære transit-aftale på plads - og praktisk betyder det ikke det store for vores test, ud over at trafikken mellem de to BGP-router bliver tæt på nul, da den bedste route altid vil være den direkte vej.

Vi skal have klargjort en test, der kan vise os, hvor mange pakker pr. sekund vi kan route ved små pakker - er der et godt forslag til, hvordan dette kan gøres, og skal vi mon op i 10 Gbit/s, før vi kan finde ud af, hvor loftet ligger?

Kommentarer (30)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Baldur Norddahl

Hvis sw1 crasher, så er din router1 stadig online og fortsætter med at annoncere dine prefixes. Dermed modtager den trafik, som den ikke kan aflevere videre ind i dit net.

Kan løses ved at du sørger for lidt flere redundante links eller ved at du programmerer Quagga til kun at annoncere prefixes hvis den kan se resten af nettet. Jeg kender ikke Quagga så kan ikke sige om den har den funktion.

  • 2
  • 0
Ivan Skytte Jørgensen

Et trick som Jesper Brouer fortalte om, da han arbejdede med support af 100Gbps-kort inden han havde fået dem til at virke (ventede på firmware fra leverandøren) var at skrue pakkestørrelsen ned til det minimale, fordi det meste overhead er pr. pakke - ikke hvormeget de fylder. Hvis du ikke har brug for connection-tracking i din test, så skulle det være forholdsvist overkommeligt at lave en pakkegenerator som sender en masse små pakker, og en /dev/null pakkemodtager, og sætte din router imellem disse to.
Så en test med 10-byte pakker på et 1Gbps kort vil svare stort set til en test med 100-byte pakker på et 10Gbps kort (sålænge kortenes arkitektur er nogenlunde ens mht. bus, DMA og interrupt coalescing)

  • 3
  • 0
Yoel Caspersen Blogger

Hvis sw1 crasher, så er din router1 stadig online og fortsætter med at annoncere dine prefixes. Dermed modtager den trafik, som den ikke kan aflevere videre ind i dit net.

Det burde jeg måske have inkluderet på oversigten. Provider 1 er faktisk termineret i sw1, hvorfra der er tagget et VLAN igennem til router-1. Så hvis sw1 crasher, er router-1 definitivt nede, også på BGP. Men ellers en helt igennem valid pointe, og når jeg ikke har tegnet det sådan, er det udelukkende for overblikkets skyld.

Jeg har dog en udfordring i forhold til split brain-problematikken på VRRP. Hvis linket fra sw1 til transportnettet forsvinder, vil både router-1 og router-2 stå som master, da de ikke kan se hinanden. Det er intet problem for den udgående trafik, men det er et problem for indgående trafik, da både router-1 og router-2 vil tro, de hver især kan aflevere trafikken.

  • 0
  • 0
Nicolai Kornum

Nu blev jeg nødt til at oprette en bruger og kommentere på dette for det er rimeligt interessant det du har gang I.

Nu arbejder jeg til daglig og har mest erfaring med Cisco hardware og software så det jeg skriver kommer både fra det perspektiv og setup I mente og derfor er det ikke sikkert det vil virke på dine software routere

Så vidt jeg ved bruger alle dynamiske routning protokoller til IPv6 derunder mBGP altid link-local adresserne (som dine IPv6-interfaces gerne selv skulle finde) som next-hop adresser I deres routes. Så sørg for at det er dem du router fra og til med dine statiske IPv6 routes til loopback-interfacet.

Problemet med redundansen på dine routere er mest af alt et problem fordi du gerne vil køre equal-cost multipath-routing. I praksis vil du nærmest altid kører al trafikken over en router og (I Cisco-termer) lave en IP SLA som tracker om modsatte routers loopback-interface er reachable. Hvis interfacet ikke længere er reachable ændre IP SLA'en på BGP path selection til den redundante router så den bliver primær.

I forrige blogpost var der nogle spørgsmål om og generelle misforståelser om BGP.

BGP path selection består ikke kun af AS_PATH men af ca. 13 forskellige path attributter (1 af dem er cisco proprietær), som BGP vægter I en bestemt rækkefølge (AS_PATH er nummer 4).
Her er linket til hvordan BGP bestemmer path selection: http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp...

Derudover er det sandt at der er ca. 500.000 annoncerede BGP routes som udgør internettet, men langt de fleste routers kan ikke håndterer så mange routes og derfor kan man bede dem man peere med om kun at annoncere en default route og lade dem klare byrden for dig, de skal jo nok annoncerer dine IP-segmenter videre I verdenen. (Ja man kan også bede om en default route og partial routes, men så stor en forskel gør det ikke)

Ellers vil jeg sige dit setup ser fornuftigt ud, kunne godt forklare mere om hardware vs. software routing, men I sidste ende kommer det altid an på økonomi

  • 2
  • 0
Yoel Caspersen Blogger

Nu blev jeg nødt til at oprette en bruger og kommentere på dette for det er rimeligt interessant det du har gang I.

Se det er jeg glad for at høre, og det er en af de ting, jeg synes er rigtig fedt ved version2s forum: Der er rigtig mange kompetente læsere, der kan byde ind og gøre os klogere.

Så vidt jeg ved bruger alle dynamiske routning protokoller til IPv6 derunder mBGP altid link-local adresserne (som dine IPv6-interfaces gerne selv skulle finde) som next-hop adresser I deres routes. Så sørg for at det er dem du router fra og til med dine statiske IPv6 routes til loopback-interfacet.

Jeg antager, at du taler om min udfordring med at få loopback-adresser og BGP til at virke på IPv6.

På ingen af routerne har jeg statiske routes til den anden routers loopback-adresse, det klarer jeg dynamisk med OSPFv3. Og det virker umiddelbart, for når jeg kigger i route-tabellen på router-1, dukker router-2's loopback-adresse 2a06:4000:0:1::2/128 op:

router-1# sh ipv6 ospf6 route  
*N E1 2a06:4000:0:1::2/128           fe80::921b:eff:fe62:acf4  bond0.2 5d17:04:00

Som det fremgår, er next-hop link-local-adressen på router-2. Problemet kommer, når jeg så forsøger at sætte en IPv6 BGP peer op, og anvender loopback-adressen som neighbor:

!  
 address-family ipv6  
 network 2a06:4000::/29  
 neighbor 2a06:4000:0:1::2 activate  
 neighbor 2a06:4000:0:2::2 soft-reconfiguration inbound  
 exit-address-family  
!

BGP-sessionen bliver umiddelbart etableret, men jeg får følgende fejl i loggen, hvorefter BGP-sessionen går ned:

BGP: %ADJCHANGE: neighbor 2a06:4000:0:1::2 Up  
BGP: Martian nexthop 127.0.0.1  
BGP: %NOTIFICATION: sent to neighbor 2a06:4000:0:1::2 3/8 (UPDATE Message Error/Invalid NEXT_HOP Attribute) 7 bytes 40 03 04 7f 00 00 01  
BGP: Notification sent to neighbor 2a06:4000:0:1::2: type 3/8  
BGP: 2a06:4000:0:1::2: Attribute NEXT_HOP, parse error  
BGP: %ADJCHANGE: neighbor 2a06:4000:0:1::2 Down BGP Notification send

Og her rammer vi enten en bug i Quagga eller grænsen for min viden. Det ser ud som om, router-2 forsøger at sende 127.0.0.1 som route til router-1 på IPv6, og det giver ingen mening for mig. Men hvis du kan spotte en oplagt fejl, hører jeg gerne om det :-)

  • 0
  • 0
Nicolai Kornum

Det ser mere ud som om at den next-hop adresse som routeren prøver at bruge er ukendt eller ugyldig for BGP.
Umiddelbart tror jeg der er et par løsninger
Tving BGP til at bruge en bestemt next-hop adresse med et route-map

Anden metode, hvis det er et l2 link mellem routerne igennem switchene kan man BGP peere på link-local adresserne, man skal stadig have lavet et route-map

Dette er hvad man ville gøre på en cisco kasse, ved dog ikke hvor anderledes Quagga opfører sig

Håber det hjælper

  • 1
  • 0
Nicolai Kornum

Route-map

address-family ipv6 config I BGP
neighbor (IPv6-adressen på naboen) route-map (navn på route-map) out

route-map laves under global config
route-map (navn på route-map) permit 10
match ipv6 address prefix-list (navn på prefix-list)
set ipv6 next-hop (IPv6-addressen på next-hop)

prefix-list laves under global config
ipv6 prefix-list (navn på prefix-list) permit (prefix på det netværk du vil route)
ipv6 prefix-list (navn på prefix-list) deny : :/0 (Den blokerer alt andet, hvis ikke denne linje er sat vil der være en implicit deny I stedet der gør det samme)

Peere på link-local adresser husk linjen
neighbor (Link-local adressen der peeres til) update-source lo

  • 1
  • 0
Yoel Caspersen Blogger

Dette er hvad man ville gøre på en cisco kasse, ved dog ikke hvor anderledes Quagga opfører sig

Hvis vi ser bort fra software-fejl, er det faktisk langt hen ad vejen den samme måde man gør det på i Quagga.

Tak for det fine eksempel med route-map. Når det nu skal være, så er det et elegant hack.

Min nuværende opsætning på IPv6 bruger ikke link-local-adressen som neighbor, men den globale IPv6-adresse, der er konfigureret på samme port som link-local-adressen. Er der nogen fordel ved at bruge link-local-adressen i stedet - ud over, at det er det, man normalt gør?

  • 0
  • 0
Yoel Caspersen Blogger

Er der nogen gode forslag til, hvordan vi kan undgå et split brain-issue i vores VRRP-setup, hvis et link til transport-netværket dør? I mit eksempel med /29-nettet til kunden er der kun layer 2 connectivity mellem de to routere gennem transportnettet - havde der været layer 2 connectivity mellem de to routere gennem sw1 og sw2, var der blevet skabt et loop, så derfor bliver VRRP-pakkerne udelukkende sendt via transportnettet. Udbyderen af vores transportnet tillader ikke STP.

Hvis et link til transportnettet dør, vil begge routere gå i master-tilstand. Den router, der er synlig fra kundens side, vil modtage udgående trafik, men indgående trafik vil risikere at blive sendt via begge routere, da de begge to tror, de er oppe.

Keepalived kan AFAIK konfigureres til at sende VRRP-pakkerne "out-of-band", dvs. på et andet VLAN end det VLAN, den virtuelle IP-adresse lever på. Vi kunne godt tagge et sådant VLAN igennem sw1 og sw2 - så er vi nogenlunde sikre på, at vi ikke får en situation med to masters. Det beskytter dog ikke mod fejl på links til transportnettet - hvis det "forkerte" link dør, vil kunden være afskåret fra at komme på internettet, og da begge routere kan se hinanden via VRRP-VLAN'et, vil den anden router ikke overtage den virtuelle adresse automatisk, og så er vi lige vidt.

En løsning kunne selvfølgelig være at køre en route-protokol på kundens router i stedet for at fedte med VRRP, men det virker lige lovlig drastisk.

  • 0
  • 0
Baldur Norddahl

Hvorfor bruger du next hop self? Next hop bør være den originale adresse på din peer og så bør du sørge for at OSPF distribuerer routing information så dette next hop er tilgængeligt fra den anden router. På den måde får du meget hurtigere konvergenstid hvis link til din peer går ned og hvis dine routere har support for hierarkisk FIB.

Hierarkisk FIB betyder at routes er organiseret i et træ, således at hvis alle routes under en bestemt next hop skal fjernes, så kan det gøres med en simpel operation. Information om at link til peer er nede bliver distribueret via OSPF. Det kan nedbringe konvergenstiden fra minutter til sekunder.

På en Linux boks gør det måske ingen forskel, men hvorfor ikke lave det rigtigt, så at det passer ind hvis du får "rigtigt" jern på et tidspunkt.

Spørgsmålet er om du ikke kan fikse problemet ved blot at skrive no next hop self?

  • 1
  • 0
Baldur Norddahl

Min nuværende opsætning på IPv6 bruger ikke link-local-adressen som neighbor, men den globale IPv6-adresse, der er konfigureret på samme port som link-local-adressen. Er der nogen fordel ved at bruge link-local-adressen i stedet - ud over, at det er det, man normalt gør?

Hvorfor bruger du ikke loopback adressen? Hvis du bruger link-local eller en interface adresse, og linket går ned, så går din BGP session ned. Også selvom der måtte findes en redundant vej som BGP sessionen kan fortsætte over. Derfor bruger du loopback adresser til iBGP sessions.

eBGP sessions skal derimod bruge interface adresser, da man er meget interesseret i at sessionen lukker hvis linket går ned.

Link-local adresser er mest til routes som en routing protokol har installeret. Den opdaterer dem selv hvis der sker ændringer. I din opsætning bør du derimod undgå dem.

  • 1
  • 0
Yoel Caspersen Blogger

Spørgsmålet er om du ikke kan fikse problemet ved blot at skrive no next hop self?

God pointe og god forklaring. Jeg opdaterer lige konfigurationen med dette.

Hvorfor bruger du ikke loopback adressen? Hvis du bruger link-local eller en interface adresse, og linket går ned, så går din BGP session ned. Også selvom der måtte findes en redundant vej som BGP sessionen kan fortsætte over. Derfor bruger du loopback adresser til iBGP sessions.

Fordi Quagga kløjs i det hvis jeg bruger loopback-adressen som iBGP neighbor på IPv6, og jeg ikke har nået at implementere route-map-løsningen endnu. :-)

På IPv4 bruger den loopback-adresserne som iBGP neighbors og link-adresserne som eBGP neighbors - dvs. helt efter bogen.

  • 0
  • 0
Baldur Norddahl

Mig bekendt er svaret på dette STP og hvis din udbyder blokkerer for dette, så har du lidt tabt. Hvorfor blokkerer de for STP?

Du kan vælge et single point of failure som dit interface til dem (en stabil switch). Og så køre STP internt i dit net. Det er lidt det man er nødt til i forhold til TDC og POI porte.

En anden mulighed er at du snakker MPLS med deres MPLS netværk. Hvis de tillader det altså. Der er også det problem at MPLS på Linux ikke er en moden teknologi. Jeg antager at det er L2VPN tunneller der skal termineres her.

  • 0
  • 0
Yoel Caspersen Blogger

Hvorfor blokkerer de for STP?

Som jeg husker forklaringen, skyldes det, at de ikke vil lægge op til en løsning, der kan give dem problemer, hvis vi laver en fejl i vores ende. Hvis vi laver en STP-løsning, men konfigurerer den forkert, skaber vi et loop, der også går ud over deres netværk.

Man kan selvfølgelig sige, at vi lidt er i samme situation med det nuværende setup - loop'et er kun et par "vlan x untag y"-kommandoer væk.

  • 0
  • 0
Mike Mikjær Blogger

Istedet for keepalived kan du bruge ucarp som er indbygget i Debian (og dermed vil jeg formode, også Ubuntu) opsætningen forgår i din /etc/network/interfaces fil sådan her:

http://www.specialhosting.dk/high-availibility-med-ucarp-og-debian-hsrpv...

Hvis du meget gerne vil undgå split-brain så hedder det STONITH

https://en.wikipedia.org/wiki/STONITH

Hvad er det konkret du forventer en split-brain vil kunne påføre dig? Split brain opstår hvis router 1 og router 2 ikke kan kommunikere med hinanden, men hver for sig stadig fungerer.

Begge dine maskiner har route-bare ip adresser, dvs. de burde kunne kommunikere med hinanden både via internettet og dit eget net, altså er de redundant forbundet.

En split-brain her vil således kun kunne opstå hvis f.eks. router-2 frakobles både internettet og lokalnettet. Hvordan forestiller du dig ellers det kan opstå?

Det næste er, hvilken skade gør en split-brain? Hvis dit net bliver partitioneret, så er det vel nærmest en fordel at hver part har en fungerende router?

  • 0
  • 0
Baldur Norddahl

De to routere har uafhængige links ind i transportnettet. Dette for at undgå at linket til transportnettet bliver single point of failure. Forestil dig nu at der sker noget inde i transportnettet så at den ene router ikke længere kan nå kunderne. Eller endnu værre, at den ene router kan nå en delmængde af kunderne og den anden router kan nå en anden delmængde.

STONITH løser ikke noget. Der er ikke nogen måde for en af routerne at se at den har bedre forbindelse end den anden. Så hvordan vil du afgøre hvilken router der skal dø?

Det er ikke tilladt at koble de to routere sammen da det vil skabe et loop. Broadcast trafik der går ud via det ene link til transportnettet vil komme ind igennem det andet link, blive sendt videre via linket mellem routerne og ud igen via det første link - du har nu en såkaldt broadcast storm.

Man bruger normalt spanning tree (STP) til at afbryde loopet. Men den løsning er blevet dømt ude af udbyderen.

  • 1
  • 0
Baldur Norddahl

Yoel, du kan komme 90% i mål hvis du laver nogle antagelser om transportnettet. Det er givetvis et MPLS netværk der automatisk router udenom link problemer. Hvis udbyderens router i den anden ende af dit link til transportnettet går ned, så bør linket også gå ned. Du kan eventuelt aftale at i overvåger linket med BFD for at være helt sikker på at det er tilfældet. Hvis linket er nede, så er dit interface nede og routes der går ud igennem dette interface bliver trukket tilbage.

De to routere har et link på layer 3 niveau. Derfor vil routeren, der nu har et interface der er nede, i stedet aflevere trafikken til den anden router. Ligeledes vil VRRP flytte til den router der stadig har et aktivt interface.

Jeg er ikke sikker på at Linux automatisk fjerner interface adresser fra route tabellen. Men det gør de fleste hardware routere. Det må være muligt at få Linux til at emulere dette. Muligvis er det bare at sørge for at Quagga gør det via BFD link failure detection.

Din antagelse er at hvis linket er oppe og BFD siger go, så har udbyderen nok styr på deres MPLS net til at pakkerne også bliver afleveret til kunderne.

  • 2
  • 0
Yoel Caspersen Blogger

En split-brain her vil således kun kunne opstå hvis f.eks. router-2 frakobles både internettet og lokalnettet. Hvordan forestiller du dig ellers det kan opstå?

Det næste er, hvilken skade gør en split-brain? Hvis dit net bliver partitioneret, så er det vel nærmest en fordel at hver part har en fungerende router?

Mikkel, tak for dit indlæg. Baldur rammer hovedet på sømmet i forhold til beskrivelsen af min udfordring - hvis et af linksne til transportnettet dør, eller hvis der går noget andet galt inden i transportnettet, vil jeg stå i en situation, hvor både router-1 og router-2 tror, de skal være mastere. Det skyldes, at layer 2-forbindelsen mellem de to routere, som er den, VRRP måler på, kun findes gennem transportnettet på VLAN 30 i mit setup. Herved vil jeg stå med et halvt eller helt defekt transportnet, da jeg ikke umiddelbart kan afgøre, hvilken master der er den bedste - det afhænger jo af, hvilken master der kan se de kunder, der eventuelt måtte være koblet på.

VRRP beskytter i denne opsætning kun mod at en af mine core routers dør - og det er selvfølgelig bedre end ingenting. En del af udfordringen ligger i, at core-router og core-switch er to forskellige enheder, så medmindre der implementeres en speciel mekanisme, som fx BFD, så vil routerens VLAN-interfaces altid være oppe, hvis bare der er forbindelse til core-switchen. Da interfacet er oppe, vil routen også blive propageret til de andre core routers via OSPF(v3) eller BGP.

Tak for tippet med ucarp. Det ser jo umiddelbart nemt ud - er den kompatibel med VRRP? Hvis jeg en dag opgraderer til en hardware-router, kan jeg gøre det uden at lukke netværket ned, hvis begge ender af et link taler VRRP.

Stonith virker som en fin løsning til at lukke fejlbehæftede nodes ned med. Det er bare ikke issuet her - issuet er at detektere, hvis der er en fejl på linket ud til kunden.

Det er svært at beskrive et netværk fyldestgørende i et blogindlæg - jeg kunne godt have medtaget al konfigurationen, men så ville jeg have haft en wall-of-text, der kun ville være forståelig for folk, der allerede var godt inde i sagerne. Jeg kunne godt have haft alle IP-adresserne og VLANs med på oversigtstegningen, men så havde den fyldt for meget til at passe ind i version2's layout, hvor der, trods alt, er begrænset plads til formidling.

Formålet med mine indlæg om vores løsning er dels at inspirere læsere, der selv kunne få lyst til at kaste sig ud i et projekt i stil med vores, dels at få noget kompetent input og diskutere de tekniske løsninger, så jeg selv kan blive klogere. Derfor byder jeg alle seriøse indlæg velkommen - også selv om vi på enkelte områder måsker rammer en smule forbi. Skulle der være ting, det ikke er lykkedes mig at formidle tydeligt, beklager jeg på forhånd, men spørg endelig ind, hvis det er.

Godt nytår :-)

  • 1
  • 0
Yoel Caspersen Blogger
  • 1
  • 0
Dennis Ladefoged

Det er osse en mulighed at bruge en Whitebox switch. De fået i mange afskygninger, dog mest med et broadcom trident chipset. Men du kan få modeller som kan indeholde en kæmpe routetabel.
Det fede med Whitebox er at du kan smide det styresystem på som du ønsker, closed eller open-source. F.eks Pica8, Cumulus eller openswitch. Jeg har en del held med Cumulus i flere driftsmiljøer. Openswitch er open-source, men stadig i sin spæde barndom og hvad der nu følger med af sjove ting.

Producenterne er ved at vågne op og indtil videre kan du købe en whitebox af f.eks HP, Dell og Juniper. Du skal nok ikke regne med at Cisco lancerer noget foreløbigt :-)

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