Ubiquiti UniFi és EdgeRouter LITE tapasztalatok

Vettem a napokban par Ubiquiti Unifi WiFi Accesspointot, meg egy Ubiquiti EdgeRouter Lite routert. Akkor a tapasztalatok a cuccokkal, igy 2-3 nap utan:

UAP: erzodik, hogy 'kiforrott' a technologia. Par dolog meg igy hianyzik nekem. Megha multitenancy nem is, de mindenkeppen fura, hogy nem lehet a tobb kulonbozo telephelyen levo ap-kat viszonylag fuggetlenul managelni, csak overrideolni lehet AP-nkent az egyes beallitasokat. Roppant macera lehet ez, tobb telephelyet egy kontrollerrel managelve. Fura az is, hogy nem lehet tobb admin jogu usert felvenni, hanem csak egyet. Es az deplane fura, hogy ez az admin user lesz az ap-kon helyben is a 'root' felhasznalo helyett, azaz az admin nevevel kell rajuk sshzni :)

EdgeRouter Lite: bejott a legenda. Valoban Vyatta cuccrol van szo, ahogy igy utana neztem, atigazolt az Ubuquitihez par vyattas developer, aztan gondolom licencelik az os-t, meg hazon belul faragjak ubiquitisre. Nagy prozitivum, hogy az OS nem akar tul okos lenni, azaz enged lemenni root bash szinte, kezzel hegeszteni a dolgot, ha ugy hozza a szukseg. Tul okos OS-re jo pelda az, amit a MikroTik muvel. Azzal sajnos vannak behatobb tapasztalataim, es ha az kvazi alapfunkcionalitason tul akar az ember valamit nem is annyira kulonleges felallast osszerittyenteni, akkor mar aranytalanul sok kompromisszumot kell kotni.

Ubiquiti allo fasszal hirdeti mindenfele, hogy hardware acceleration van a packet forwardingra es az IPSec titkositasra. Hat ez tobbe-kevesbe igaz. Igaz akkor, ha ket nativ interface kozott kell forwardolni a packetet. De ha VLAN taget kell tenni barmelyik forgalomra, akkor mar CPU-bol tolja a forgalmat. De ugyanez igaz a PPPoE-s kapcsolatokra is. Sajnos az IPSec gyorsitasi kepesseget nem sikerult prezentalnia a cuccnak, 10Mbps AES256/SHA1 traffic mellett 18% softirq loadot latni. Ugyanez VLAN taggelt forgalom eseten IPSec nelkul 12.5%. A ketto egyutt csak 24%, erdekes modon. Az en elkepzelesem szerint egy access router lenne (lett volna) az eszkoz, ahol egy telephelyet (lakasomat) site-to-site vpn-nel osszekotnem egy masikkal, a helyi switch fele VLAN taggelt forgalmazassal. Ez - ugy tunik - a leheto legrosszabb scenario, mert mindent procibol fog megoldani. Es ha 24% a 10 Mbps eseten, akkor az eles vegpont 40-80 Mbps varhato forgalmatol siman beverezne. Es ott meg hozzajon a PPPoE overhead is, ami a mostani tesztekben (UPC-s DHCP) nem is volt jelen. Szoval nem tudom, hogy mi legyen az eszkozzel. L3 'switchnek' tul keves porttal bir, es buta ip routingra meg boven jo amit az eleve meglevo L3 switchem tud. Lehet, hogy megiscsak maradok az intel d2500cc lapnal openbsd-vel, mint ahogy most van. Gondolokodom rajta, hogy mire lehet igy hasznalni a kis ERlite-ot. Kisszines, hogy az OpenBSD projekt is gondolkodik rajta, hogy folytassa azt a portjat, ami erre az octeon procira epul :)) Van itthon egy Ubiquiti Routerstation Pro-m is, lehet kiprobalom, hogy az ERLite-hoz kepest hogy 'huz' a 680 MHz-es procijaval :) Sot, arra mar regi vagyam FreeBSD-t telepiteni, lehet itt az ideje.

Most ennyit tudtam igy hirtelen, emlekezetbol leirni a tapasztalatokrol.

Zorp GPL Policy Generátor

Készítettem a Zorp GPL verziójához egy ZMS-szerű konfiguráció-generátor alkalmazást, amely egy egyszerű, könnyen megérhető és szerkeszthető leíró fileból dolgozik. Nagyvonalakban a következőket tudja:

  • Több site és azon belül tűzfal clusterek és zóló tűzfal gépek támogatása;
  • "linkek" használata: bárhol meghivatkozható változók, cluster nodeonként eltérő értékekkel;
  • policy.py generálás:
    • Zónaszerkezetben az InetZone-on inbound és outbound service-felsorolásait kitölti a szabályrendszernek megfelelően;
    • Teljesértékű instance, serivce, router és chainer támogatás;
  • instances.conf generálás;
  • Hálózatikonfiguráció-menedzsment, azaz az interfaces(5) filet is kezelni tudja
  • Fullos High-Availability támogatás;
site
Több site és azon belül tűzfal clusterek és zóló tűzfal gépek támogatása;
linkek
"linkek" használata: bárhol meghivatkozható változók, cluster nodeonként eltérő értékekkel;
policy.py
Zónaszerkezetben az InetZone-on inbound és outbound service-felsorolásait kitölti a szabályrendszernek megfelelően; Teljesértékű instance, serivce, router és chainer támogatás;
instances.conf
instances.conf generálás;
HA
Fullos High-Availability támogatás, keepalived(8) VRRP protokoll használatával, így akár nem-Zorp tűzfalakkal, routerekkel is házasítható, mint fallback megoldás.
Netwroking
Hálózatikonfiguráció-menedzsment, azaz az interfaces(5) filet is kezelni tudja

--

2012-05-16 update: nem fejeztem be, mint ahogy ezt a blogpostot sem. A cucc kis simitasok utan most is generalja a policy-t, de droppoltam mar a Zorpot is, helyette van haproxy meg egyeb kisebb ganyolas.

Wifi - Ethernet bonding

The problem

When I'm at home, I dislike undocking my laptop to move around the house because of the Ethernet-to-WiFi switchover takes long seconds and all my TCP sessions like SSH get lost. It's because my laptop is assigned a different IP Address on wifi and on the wired network even if they belong to the same Layer2 segment (here: VLAN). Weel, it looks like this not the case any more.

The idea

Today I was thinking of bonding, a stuff used to do failover/loadbalancing on wired ethernet NICes, commonly in the enterprises. It can do all sort of standardized stuff like 802.3ad/LACP, broadcasting, 4 different kind of loadbalancing---in this scenario I need only the so called "Active-backup policy". That is, only one interface is active at a time, where the wired Ethernet is the preferred. There is no special config need on the network rig, but it's effective iff the wired connection and the wireless ESSID belong to the same layer 2 network segment.

My theory works like a charm

In this video I demonstrate the setup in use---where a bond0 interface is active on the primary wired eth0 that fails over to wlan0 upon disconnection of the wired ethernet cable. The failover (and failback) happens amazlingly fast, virtually no interrupt can be observed.


Wifi-Ethernet bonding convergence in action

Integration into the everydays

I use wicd to manage my wireless connections. A sad thing is that it doesn't support this much weird setup at all. There was a thread (called Wireless and Wired) on the official forum, one of the developers told 'I would expect it to be very distant in the future, if ever'. I don't know if there's any other network/connection manager to support this. Even worse, wicd is apparently abandoned: they closed down their forums due to spam bots, and there's no reaction from developers on the official freenode IRC #wicd either. Altough wicd source looks easy to modify I guess I will stick to my handmade 'init' scripts to do bonding and wpa_supplicant configuration.

What would be needed in wicd:

A GUI/TUI item needed to configure bonding interface, thus a '-b bond0' paramtere could be used for wpa_supplicant and DHCP client daemons need to bind on bond0 instead of the physical slave devices.

Extending it to the mobile broadband?

It's not possible using standard Linux bonding, instead IPSec+MOBIKE could be used for seamless inter-network roaming. I'm on further rambling on this.

Dummy domains for testing DNS stuff

I've made a plenty of domains with full of various intentional mistakes for testing DNS implementations, and also for sanity checks while making a check script that will operate very much like ISZT regcheck 'Domi'. Maybe I'll call it OpenDomi as ISZT refused to open the source of Domi. Here are the domains and description of mistakes they have:

domain mistake
test00.y7.hu valid domain without MX records
test01.y7.hu valid domain with only 1 NS
test02.y7.hu domain with only 1 NS that doesn't match SOA MNAME
test03.y7.hu domain with 3 Nses, 1 doesn't exist
test04.y7.hu domain with 3 Nses, 1 not auth for zone
test05.y7.hu domain with 3 Nses, 1 not auth for zone
test06.y7.hu domain with SOA record having less than the required fields
test07.y7.hu domain with SOA record having MNAME field removed
test08.y7.hu domain with SOA record having confusing MNAME field
test09.y7.hu domain with different SOA serials on NSes
test10.y7.hu domain with non-working RNAME address
test11.y7.hu domain with non-working RNAME mail domain
test12.y7.hu domain with no SOA record at all
test13.y7.hu domain with SOA fields out of RIPE recommendation ranges
test14.y7.hu domain with MX records not having A records
test15.y7.hu domain with MX record not having A records
test16.y7.hu domain with MX record not accepting mail for domain
test17.y7.hu domain with an NS record being a CNAME
test18.y7.hu domain not delegated on parent
test19.y7.hu domain with NSes pointing to the same address
test20.y7.hu domain with NSes different from parent delegation
test21.y7.hu domain with NS GLUEs different from parent delegation

Feel free to use these domains for your tests.

i3 wm 4.1 is out

The long awaited 4.1 is out with implemented features came from right top of the wishlistes:

  • tray support in i3bar (for NetworkManager, Skype, etc.);
  • window criteria now supports PCRE;
  • application startup notification;
  • the application window will appear on the workspace on which it was launched and not on the currently focused workspace (actually, I will miss this 'feature' as I used to launch libreoffice from a shell and then I switched to another workspace to use libreoffice from there);
  • i3bar is now configurable in the i3 configfile.

and much more in the release notes.

However, I still miss a Nagios-like event broker interface for further event notification and control scripting support. The simple event subscription API in i3 is too simple for my needs right now (I have a long-lasting dream of a hardware interface for i3, details later :) ). I've flagged the Arch community package as out of date so expect an 'official' update package release soon.