Overview of a pfSense-CARP setup

You need one real IP address for every CARP cluster host. So, if you want to have 2 cluster members, you will need 2 IP addresses for the real interfaces and then an IP for each virtual IP address. So in this case it would amount to 3. In the example shown to the right, the primary CARP clusters WAN IP address is 127.29.29.1 and the backup firewalls WAN IP address is 127.29.29.2. The primary clusters LAN IP address is 192.168.1.2 and the backup firewall’s LAN IP address is 192.168.1.3.

Setting up dedicated pfsync interface

We strongly advise using a dedicated interface for pfsync.

Set up each cluster sync interface, give it an IP address in the same subnet. Example: on the master cluster member enter 192.168.4.1 and on the backup cluster member enter 192.168.4.2 for the IP address. Use a /24 subnet.

Enable pfSync

Enable pfSync in Firewall -> Virtual IPs -> CARP settings -> Synchronize Enabled (check it) on all cluster members.
-> Synchronize Virtual IPs [ X ]
-> Synchronize to IP [ insert Slave IP ONLY on Master! ]
-> Remote System Password [ do not forget! ]

Select the dedicated Sync interface with the Synchronize Interface dropdown on all cluster members.

Afterward visit Firewall -> Rules and add an allow all from any to any rule on each cluster member for the newly created pfsync interface.

Adding CARP shared virtual IP addresses

Now on the master cluster member add a virtual IP addresses of the CARP type in Firewall -> Virtual IPs. Make sure that the virtual IP addresses fall within the same subnet of an IP address defined on real interface (WAN, LAN, OPT1, etc.). You need to dedicate a unique VHID per shared virtual IP address. The lowest skew states that the host should be a master. The XMLRPC process will automatically add +100 to each host while syncing. So we recommend setting the skew to 0 on the master hosts CARP virtual IPs. pfSense will handle the rest.

Preparing for XMLRPC Sync

Now set the same Admin password and protocol for the webConfigurator (HTTP/HTTPS) on each cluster member

On the master cluster member, visit Firewall -> Virtual IPs -> CARP Settings and enter the 2nd cluster members sync ip address (earlier in example was 192.168.4.2). Afterwards, enable all sections you want to sync (Synchronize rules, Synchronize aliases, Synchronize nat, ..*). This will automatically push configurations from the master cluster member to the backups. Click save. You should see the virtual ip addresses automatically synchronized to the backup hosts

Setting up advanced outbound NAT

Enable advanced outbound NAT in Firewall -> NAT -> Outbound -> Enable advanced outbound NAT. Click save.

Edit the automatically added rule for LAN. Pick a shared CARP virtual IP address as the Translation IP address. Give the item a description and click Save.

Setting DHCP Server to use CARP LAN IP Address

On both firewalls, visit Services -> DHCP Server. Click on the LAN tab. Set the default gateway to 192.168.1.3. Click save.

It also may be a good idea to enable failover DHCP. Enter 192.168.1.2 in the failover peep box on the primary and 192.168.1.1 on the backup server. Click save.

Checking that XMLRPC sync worked

Visit the backup cluster member and verify that NAT, Virtual IP’s and rules have been synchronized correctly.

Finally on the backup host, visit Firewall -> Virtual IPs -> CARP settings -> and enable “Synchronize Enabled” and make sure that your pfSync interface is correct. Click save.

You should read the hardware redundancy chapter in the pfSense book before configuring CARP.

From the Tutorials page:

• Building a fully redundant Cluster with 2 pfSense-systems between WAN/LAN with CARP & pfsync / pfSense CARP & pfsync failover-simulation

http://www.pfsense.org/mirror.php?section=tutorials/carp/carp-cluster-new.htm

I have many pfSense Firewall appliances in my shop, which you can buy.

That’s it! Enjoy your failover firewall solution.

K finálnej štandardizácii prišlo sedem rokov od štartu vývoja nového štandardu a viac ako dva roky od spustenia certifikácie zariadení s druhým návrhom štandardu. V súčasnosti sa už denne predáva viac ako milión zariadení kompatibilných s druhým návrhom WiFi 802.11n certifikovaných WiFi alianciou.

Oproti druhému návrhu štandardu, s ktorým sú kompatibilné súčasné zariadenia, prišlo vo finálnej verzii k menším zmenám najmä u voliteľných funkcií a vlastností.

Zariadenia certifikované WiFi alianciou pre súlad s finálnou verziou štandardu budú interoperabilné s doterajšími zariadeniami a podľa oznámenia WiFi aliancie doterajšie zariadenia kompatibilné s druhým návrhom štandardu získajú dokonca právo používať logo kompatibility s finálnou verziou štandardu, keďže sú kompatibilné zo základnými požiadavkami aj finálneho 802.11n.

U viacerých 802.11n čipsetov je zároveň možné, že výrobcovia iba aktualizáciou firmvéru zabezpečia aj u už predaných zariadení úplnú kompatibilitu s finálnou verziou štandardu.

Verzia 802.11n je na rozdiel od doteraz bežne používaných verzií WiFi 802.11b a 802.11g určených len pre 2.4 GHz pásmo určená pre 2.4 GHz alebo 5 G GHz pásmo.

Oproti verzii 802.11g nová verzia 802.11n výrazne zrýchlila, z maximálnej fyzickej komunikačnej rýchlosti 54 Mbps až na 600 Mbps, teda 11.1-násobne. Časť zrýchlenia je dosiahnutá vďaka voliteľnému zdvojnásobeniu šírky využívaného komunikačného kanálu z 20 MHz na 40 MHz, o ďalšie takmer 5-násobné zrýchlenie sa už postarala efektívnejšia technológia.

Zdvojnásobenie šírky kanálu na 40 MHz poskytuje 108 frekvencií v OFDM namiesto 52 frekvencií, bitrate sa tak zvyšuje presne 2.25-násobne. Aj 802.11n môže ale stále používať aj 20 MHz kanály.

802.11n používa efektívnejšie opravné kódy, keď na ne pripadá len 1/6 prenášaných bitov namiesto 1/4, rýchlosť tak zvyšujú o devätinu. Rýchlosť zvyšuje aj skrátený ochranný interval proti rušeniu oneskoreným odrazeným signálom z 800 ns na 400 ns, čo umožňuje zvýšiť rýchlosť o ďalšiu jednu devätinu.

Najväčšie zrýchlenie ale prináša technológia Multiple Input Multiple Output, MIMO. Pri použití MIMO dve zariadenia komunikujú na jednej frekvencii nie jedným ale viacerými, dvomi až štyrmi, dátovými streamami a rýchlosť sa tak zdvoj, stroj alebo zoštvornásobuje.

Pre každý dátový stream potrebujú mať obe zariadenia samostatnú anténu. U zariadení certifikovaných podľa druhého návrhu štandardu 802.11n bola overovaná kompatibilita s MIMO s maximálne dvomi streamami, ktoré umožňujú maximálnu rýchlosť 300 Mbps. Súčasné čipsety podporujú typicky maximálne dva dátové streamy, najlepšie zatiaľ predstavené čipsety popredných výrobcov tri prípadne prototypy plné štyri streamy s maximálnou rýchlosťou 450 Mbps respektíve 600 Mbps.

802.11n zároveň okrem výrazného zvýšenia fyzickej prenosovej rýchlosti zvyšuje aj efektívnosť prenosu samotných dát pomocou napríklad spájania potvrdzovacích framov, podľa dostupných informácií môžu u 802.11n dáta tvoriť v ideálnych podmienkach až približne 75% fyzickej rýchlosti oproti menej ako 50% pri 802.11g.

Plné znenie schválenej finálnej verzie štandardu bude zverejnené v októbri, certifikácia nových zariadení s finálnou verziou štandardu vrátane testovania interoperability nových voliteľných funkcií začne už tento mesiac.

Článok je prevzatý z www.dsl.sk.

Pôvodné riešenie bolo založené na technológií WiFi 5,8GHz point-to-point. Hardware bol použitý WRAP od PC Engines GmbH s kartami Atheros. Software bol a stále je použitý OS Linux, distribúcia LEAF konkrétne Bering uClibc.

Dĺžka trasy uplinku (last mile, vzduch) je okolo 1km. Keďže počet zákazníkov stúpa, vznikla potreba aj zálohy samotnej trasy vo vzduchu. Samozrejme, hneď sa objavilo riešenie mať skladom záložný hardware. V prípade výpadku trasy, je ale oprava pri tejto variante časovo náročná (vybavovanie vstupov, lezenie po rebríkoch k anténam, samotná výmena HW, …).
Networkingu a routingu sa venujem pár rokov, takže som sa začal pohrávať s myšlienkou Load Sharing-u.

Design

Keďže linux je flexibilný a distribúcia LEAF zvláda routing bez problémov vznikol prvý design zapojenia. Samozrejme požadovaná rýchlosť si vyžaduje aj silný hardware. Preto jednoznačne padol výber na hardware od PC Engines GmbH , konkrétne ALIX, ktorý má výkonnejší procesor a viac pamäte priamo na boarde.
Prvotný design zapojenia bol navrhnutý s jedným zariadením s ethernetom a 2x WiFi kartou na každej strane.

obr. č. 1.: prvotný návrh designu zapojenia

Samotné testy začali konfiguračným templatom na jednom zariadení. V tomto prípade som zisťoval, či zariadenie vôbec dokáže prijať plánovanú konfiguráciu a či jednotlivé časti konfigurácie budú spolupracovať. Mnoho problémov sa podarilo odstrániť, alebo obísť, no objavili sa aj také, na základe ktorých som musel meniť design celého riešenia.

Vážnejší problém pri designe podľa obrázku č. 1 vznikol pri definovaní ath0 a ath1 rozhraní do TEQL rozhrania. Jednoducho nie je možné definovať k virtuálnemu teql0 rozhraniu athx, možné je pridávať len ethx rozhrania.

Vzhľadom k tomuto obmedzeniu som zmenil design. Keďže hardware ALIX nie je finančne náročný, úlohy ktoré boli pôvodne plánované do jedného zariadenia som distribuoval na viac zariadení na jednej strane. Vznikol návrh, kde na každej strane boli navrhnuté 3ks zariadení ALIX. Jedno zariadenie, ktore robí samotný Load Sharing a 2ks zariadení ALIX, ktoré robia bridge medzi ethernet a wifi rozhraním.
V tomto prípade som ale musel počítať s napájaním pre 3ks zariadení na každej strane a umiestnením týchto zariadení na stožiari. Našťastie, toto je menší a riešiteľný problém. Takže padlo definitívne rozhodnutie pre design č. 2.

obr. č. 2.: finálny návrh designu zapojenia

Z histórie viem, že najväčší problém robia wifi karty, finálnym designom č.2 bol eliminovaný výpadok celej trasy v prípade zaseknutia čo i len jednej wifi karty. Ak by nastal tento problém pri designe č.1 (samozrejme traffic sa presmeruje automaticky bez výpadku do funkčnej trasy), bol by potrebný reštart zariadenia, čo znamená výpadok na 1 až 2 minúty (pri down/up wifi rozhrania sa teql interface nespamätal a bol nutný reštart).
Pri designe č.2 tento problém nenastáva. Wifi rozhranie môžete zhodiť/nahodiť a teql rozhranie, keďže je na inom zariadení automaticky zistí opätovné oživenie vadnej trasy a začne fungovať load sharing.

Pri tomto designe je potrebné zariadenia sledovať cez SNMP alebo Syslog. Nám sa stalo v živej prevádzke, že na jednom zariadení, ktoré robí bridge, sa pokazil napajací zdroj, traffic sa presmeroval automaticky na funkčnú trasu a týždeň si to nikto nevšimol.  Keď sme to zistili, bolo dostatok času na opravu a všetko fungovalo. Po oprave load sharing zistil, že obe trasy sú funkčné a zapojil do prevádzky obidve trasy, opäť bez výpadku. Na jednej strane ma tešilo, že backup reálne funguje, ale na druhej upozornilo na potrebu monitorovania týchto zariadení.

obr. č. 3.: comps použité pri vývoji a testoch

Configuration

Pri návrhu konfigurácie bolo potrebné urobiť pár základných vecí:
1) prepojenie Bridge zariadení vo vzduchu cez AP, Ad-Hoc, alebo WDS.
2) Bridge medzi Ethernet a WiFi rozhraním
3) Load Sharing
4) funkčný backup

Pri konfigurácií WiFi som potreboval bridging (WiFi/Ethernet). Rozhodol som sa pre WDS. Bolo to najjednoduchšie riešenie a vyžadovala si to IP adresácia pre Load Sharing. Keďže na zariadeniach  beží OS Linux konkrétne LEAF, do kernelu som musel pridať moduly pre Bridging, defaultne tam nie sú. Všetko fungovalo bez problémov na prvý pokus.

Samotný Load Sharing si taktiež vyžaduje doplnenie pár modulov do kernelu, v tomto prípade tc a teql. Podľa finálneho návrhu designu zapojenia, zariadenie ktoré robí Load Sharing obsahuje len eth rozhrania, teda nebol problém s pridávaním ethx rozhraní do teql0 interfacu.

# tc qdisc add dev eth1 root teql0
# tc qdisc add dev eth2 root teql0
# ip link set dev teql0 up

obr. č. 4.: vyťaženosť procesora zariadenia, ktoré robí Load Sharing v živej prevádzke

Performance

Cieľom, okrem funkčného backup riešenia, bolo aj zvýšenie prenosovej rýchlosti s dostatočnou rezervou na najbližší rok/roky. Prvé testy som robil len na kábloch, bez WiFi. Zariadenia ALIX majú ethernet porty 10/100Mbps, teda performance bola len otázkou výkonu procesora tohto zariadenia. Na testy výkonnosti som použil IPerf na počítačoch Mac, Linux aj Windows. Zaťaženie procesora samozrejme stúpa s objemom prenesených dát, ale do úvahy treba brať aj veľkosť packetov. Ja som používal na test typickú veľkosť packetu v internet trafficu okolo 600 octetov. Výsledky zaťaženia procesora pri rôznych objemoch prenášaných dát cez zariadenia ALIX sú nasledovné:
- 10Mbps, CPU 5%
- 20Mbps, CPU 15%
- 30Mbps, CPU 20%

Zariadenia bez problémov zvládajú Load Sharing 80Mbps trafficu, čo je veľmi dobrý výsledok.  Na obrázku č.4 je graf vyťaženia procesora zariadenia, ktoré robí Load Sharing v živej prevádzke. Maximá na grafe predstavujú reálny traffic okolo 30Mbps viď obr. č.5.

obr. č.5.: vyťaženosť uplinku do internetu, živá prevádzka

Testy záťaže procesorov dopadli nad očakávania a na rad prišiel test finálneho designu aj s WiFi. Keďže HW pre Bridge je rovnaký ako pre Load Sharing, otázka znela, aký bude mať WiFi dopad na rýchlosť prenosu dát. Samozrejme pri testoch v plnom designe aj s WiFi som nedosahoval rýchlosti 80Mbps, ale okolo 60-70Mbps, čo je vynikajúce a vyhovujúce pre ciele projektu.

Na obrázku č.6 je fotka reálneho testovania (v lab podmienkach). Na spodnej poličke sú zariadenia, ktoré robia Load Sharing a na vrchnej poličke su Bridge WiFi/Ethernet pre dve nezávislé trasy podľa finálneho designu zapojenia na obr. č. 2.

obr. č. 6.: foto z reálneho testovania Load Sharingu

Laboratórne podmienky sú jedna vec a nasadenie do reálnej prevádzky druhá. Tesne pred koncom roka 2008 bolo riešenie nasadené do prevádzky, funguje bez problémov a k spokojnosti lokálneho ISP.

Tiež je na mieste otázka kvality WiFi signálu v husto obývaných oblastiach. Je pravda, že toto riešenie je nasadené v menej obývanej oblasti, no na druhej strane WiFi 5,8GHz má dostatočný počet kanálov, aby bolo možné sa vyhnúť rušeniu iných sietí.

CAPEX, OPEX

Investície do HW pre toto riešenie je na úrovni 1300 euro aj s vývojom a prácou. Pre backup, v prípade závady na HW, je potrebná investícia okolo 200 euro. Servisné práce je možné robiť sebestačne.

Tieto čísla sú smiešne oproti investície do profesionálneho RR spoja (point-to-point), ktorého nákupná cena je na úrovni okolo 6700 euro. K tejto čiastke je potrebné si pripočítať cenu práce na profesionála a do OPEXu pravidelný maintenance fee (nie malá čiastka) pre prípad výpadku, alebo závady na zariadení. Maintenance fee je určite povinné, keďže v prípade závady na RR spoji nemáte pripojenie do Internetu a naviac čakáte na príchod technika (čo niekedy trvá rádovo hodiny).

Záver

Riešenie je funkčné, zákazník je spokojný s výkonnosťou, riešením aj financiami, čo je hlavné a to je pre mňa dôležité. Ak ťa článok zaujal, napíš svoj názor do commentov. V prípade, že máš záujem o rôzne riešenia z oblasti networkingu, network security (firewall, IPSec,…) alebo VoIP, kontaktuj ma. Určite sa ozvem späť.