[Ninux-Calabria] routing a terra
Stefano De Carlo
stefanauss a gmail.com
Lun 23 Dic 2013 04:02:35 CET
Sabato pomeriggio in HPCC ho configurato e simulato il routing a terra
per NewSPIG con un
- TP-Link TL-WR1043ND v1.11, di quelli arrivati nuovi, come router a terra
- Una vecchia Nanostation M5, collegata al router sopra, in modalità AP
- Una vecchia AirGrid M5 in modalità station, collegata alla
- Workstation Sheldon dell'HPCC come "router a terra" improvvisato con
demone OLSR in esecuzione.
- I miei PC come "antenne" per simulare la comunicazione via VLAN.
- OpenWRT AA 12.09 sui router a terra, AirOS 5.5.6 sulle antenne.
Nel pomeriggio tutta la parte focale del routing a terra era
funzionante. Ma non ho saputo stare fermo e ho voluto raffinare il
setup, impostando la WLAN del router per fare da Access Point e fare
entrare i suoi client direttamente in Ninux. Non l'avessi mai fatto:
devo aver scatenato un bug immenso di LUCI (l'interfaccia web di
OpenWRT) che per ragioni indebuggabili mi ha sbattuto fuori dal router,
chiudendo interfacce che non erano interessate dalla modifica.
Una volta tornato a casa mi sono messo sul mio vecchio 1043ND (v1.8,
firmware identico) e ho ripetuto la configurazione, questa volta
utilizzando solo l'utility UCI a riga di comando per tutto, da zero,
senza mai toccare la GUI. Roba che ti fa rimpiangere la sintassi a tre
livelli di accesso dei Cisco. Ma ora funziona tutto, inclusi i dettagli
mancanti. Spero di poter semplicemente salvare la configurazione sul mio
e restorarla sul nuovo 1043, dovrebbe funzionare ma con OpenWRT non si
sa mai.
Allora, per prima cosa dobbiamo sapere la corrispondenza tra le
numerazioni delle porte dello switch interno tra il livello interno e
quanto è riportato sul telaio del router. Si, perché quasi mai c'è
corrispondenza 1:1. Fortunatamente nel caso del 1043, è tutto
corrispondente. In ogni caso, si trovano i match in meno di 1 minuto con
un cavo ethernet e giocando col comando swconfig, cercando nel suo
output i "link down" e "link up" per ogni porta.
root a OpenWrt:~# swconfig dev switch0 show
Global attributes:
enable_learning: 1
enable_vlan: 1
enable_vlan4k: 1
blinkrate: 0
enable_qos: 1
Port 0:
mib: Port 0 MIB counters
[....]
led: 2
disable: 0
rate_in: 1048512
rate_out: 1048512
pvid: 2
link: port:0 link:down
Port 1:
mib: Port 1 MIB counters
[....]
led: 3
disable: 0
rate_in: 1048512
rate_out: 1048512
pvid: 2
link: port:1 link:down
Port 2:
mib: Port 2 MIB counters
[....]
led: 4
disable: 0
rate_in: 1048512
rate_out: 1048512
pvid: 2
link: port:2 link:down
Port 3:
mib: Port 3 MIB counters
[....]
led: 0
disable: 0
rate_in: 1048512
rate_out: 1048512
pvid: 2
link: port:3 link:down
Port 4:
mib: Port 4 MIB counters
[....]
led: ???
disable: 0
rate_in: 1048512
rate_out: 1048512
pvid: 2
link: port:4 link:up speed:100baseT full-duplex txflow rxflow
Port 5:
mib: Port 5 MIB counters
[....]
led: ???
disable: 0
rate_in: 1048512
rate_out: 1048512
pvid: 2
link: port:5 link:up speed:1000baseT full-duplex txflow rxflow auto
VLAN 2:
info: VLAN 2: Ports: '05t', members=0021, untag=0001, fid=0
fid: 0
ports: 0 5t
VLAN 3:
info: VLAN 3: Ports: '1t5t', members=0022, untag=0000, fid=0
fid: 0
ports: 1t 5t
VLAN 4:
info: VLAN 4: Ports: '2t5t', members=0024, untag=0000, fid=0
fid: 0
ports: 2t 5t
VLAN 5:
info: VLAN 5: Ports: '3t5t', members=0028, untag=0000, fid=0
fid: 0
ports: 3t 5t
VLAN 6:
info: VLAN 6: Ports: '4t5t', members=0030, untag=0000, fid=0
fid: 0
ports: 4t 5t
VLAN 7:
info: VLAN 7: Ports: '1t2t3t4t5t', members=003e, untag=0000, fid=0
fid: 0
ports: 1t 2t 3t 4t 5t
(in questo output le VLAN sono già state impostate e quindi sono
mostrate nel riepilogo)
Per conoscere a quale porta corrisponde la CPU del router, è sufficiente
dare
root a OpenWrt:~# swconfig dev switch0 help
switch0: rtl8366rb(RTL8366RB), ports: 6 (cpu @ 5), vlans: 4096
.....
Non abbiamo bisogno di trattare la porta CPU in maniera particolare,
visto che vogliamo che tutto il traffico che passa dallo switch venga
riconosciuto ed elaborato dal router e che tutti i device che
attacchiamo abbiano un rapporto attivo con esso (non ci sono VLAN "di
passaggio"). Considerato questo, e pianificando noi di utilizzare più
VLAN, la porta CPU sarà sempre tagged.
La VLAN 2 arriva già di default in OpenWRT, è la porta WAN blu.
Le VLAN dalla 3 alla 6 le creiamo noi e veicoleranno il traffico che
l'antenna ha ricevuto dal/che trasmetterà nell'etere; ognuna di queste
VLAN contiene solo la singola porta (oltre alla CPU, ovviamente)
dell'antenna di cui si occuperà. Su questa VLAN non sarà possibile
comunicare con AirOS sull'antenna, perché come detto nella mail di
background, l'antenna è configurata in Bridge privo di indirizzo. Il
solito indirizzo che eravamo abituati a mettere per l'infrastruttura
wireless, 172.17.0.0/16, col routing a terra viene assegnato alla VLAN
di traffico sul router.
Ma all'antenna ci sarà pur sempre bisogno di arrivare, giusto? Le porte
sul router sono finite, e comunque non vogliamo certo salir su con un
secondo cavo solo per gestire l'antenna. A questo serve l'apposita VLAN
7, detta VLAN di gestione. Di questa VLAN fanno parte TUTTE le porte
dello switch: questo, mentre continua a separare le antenne quando
"parlano wireless" grazie alle altre VLAN, le mette invece nella stessa
rete locale Ninux del nodo: dunque router e antenna avranno indirizzi
del tipo 10.87.x.0/24 che potremo usare per accedere ai loro pannelli di
amministrazione.
Seguono il file di configurazione di OpenWRT che divide lo switch, crea
le VLAN come sopra descritte, tira su le corrispondenti interfacce, e
l'output di ifconfig corrispondente (con qualche commento utile).
root a OpenWrt:~# cat /etc/config/network
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
# Al momento inutilizzata.
# Può essere utilizzata per fornire Internet
# o per distribuire la rete locale verso
# un secondo dispositivo.
config interface 'wan'
option ifname 'eth0.2'
option proto 'dhcp'
config switch
option name 'rtl8366rb'
option reset '1'
option enable_vlan '1'
option enable_vlan4k '1'
config switch_vlan
option device 'rtl8366rb'
option vlan '2'
option ports '0 5t'
config switch_vlan
option device 'rtl8366rb'
option vlan '3'
option ports '1t 5t'
config switch_vlan
option device 'rtl8366rb'
option vlan '4'
option ports '2t 5t'
config switch_vlan
option device 'rtl8366rb'
option vlan '5'
option ports '3t 5t'
config switch_vlan
option device 'rtl8366rb'
option vlan '6'
option ports '4t 5t'
config switch_vlan
option device 'rtl8366rb'
option vlan '7'
option ports '1t 2t 3t 4t 5t'
config interface 'ANTENNA1'
option ifname 'eth0.3'
option proto 'static'
option ipaddr '172.17.87.3'
option netmask '255.255.0.0'
config interface 'ANTENNA2'
option ifname 'eth0.4'
option proto 'static'
option ipaddr '172.17.87.4'
option netmask '255.255.0.0'
config interface 'ANTENNA3'
option ifname 'eth0.5'
option proto 'static'
option ipaddr '172.17.87.5'
option netmask '255.255.0.0'
config interface 'ANTENNA4'
option ifname 'eth0.6'
option proto 'static'
option netmask '255.255.0.0'
option ipaddr '172.17.87.6'
config interface 'LAN_NINUX'
option ifname 'eth0.7'
option proto 'static'
option ipaddr '10.87.3.1'
option netmask '255.255.255.0'
# Questa rete sarà distribuita dall'
# access point 2.4GHz del router.
# Dunque la predisponiamo per bridgiarla
# alla radio0 in /eytc/config/wireless
option type 'bridge'
root a OpenWrt:~# ifconfig
br-LAN_NINUX Link encap:Ethernet HWaddr 54:E6:FC:98:6C:60
inet addr:10.87.3.1 Bcast:10.87.3.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2469 errors:0 dropped:15 overruns:0 frame:0
TX packets:1112 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:361309 (352.8 KiB) TX bytes:136493 (133.2 KiB)
eth0 Link encap:Ethernet HWaddr 54:E6:FC:98:6C:60
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:68798 errors:0 dropped:0 overruns:0 frame:0
TX packets:84521 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5802617 (5.5 MiB) TX bytes:12044157 (11.4 MiB)
Interrupt:4
eth0.2 Link encap:Ethernet HWaddr 54:E6:FC:98:6C:60
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:10786 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:4238898 (4.0 MiB)
eth0.3 Link encap:Ethernet HWaddr 54:E6:FC:98:6C:60
inet addr:172.17.87.3 Bcast:172.17.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:18237 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:1839334 (1.7 MiB)
eth0.4 Link encap:Ethernet HWaddr 54:E6:FC:98:6C:60
inet addr:172.17.87.4 Bcast:172.17.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:18211 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:1837302 (1.7 MiB)
eth0.5 Link encap:Ethernet HWaddr 54:E6:FC:98:6C:60
inet addr:172.17.87.5 Bcast:172.17.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:18231 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:1838730 (1.7 MiB)
eth0.6 Link encap:Ethernet HWaddr 54:E6:FC:98:6C:60
inet addr:172.17.87.6 Bcast:172.17.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:66775 errors:0 dropped:9 overruns:0 frame:0
TX packets:18361 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4235915 (4.0 MiB) TX bytes:1853358 (1.7 MiB)
eth0.7 Link encap:Ethernet HWaddr 54:E6:FC:98:6C:60
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2023 errors:0 dropped:0 overruns:0 frame:0
TX packets:694 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:328338 (320.6 KiB) TX bytes:97412 (95.1 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:257952 errors:0 dropped:0 overruns:0 frame:0
TX packets:257952 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:17540736 (16.7 MiB) TX bytes:17540736 (16.7 MiB)
wlan0 Link encap:Ethernet HWaddr 54:E6:FC:98:6C:60
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:698 errors:0 dropped:0 overruns:0 frame:0
TX packets:2052 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:54375 (53.1 KiB) TX bytes:382627 (373.6 KiB)
Due parole sulla VLAN di gestione. Le porte sono state tutte taggate, ma
funzionalmente non sarebbe cambiato niente se avessimo deciso fare la
VLAN 7 tutta untagged. La ragione principale per cui si è scelto di fare
così è che questa accortezza è un modo semplice ed elegante di aggirare
un bug noto presente in molti SoC presenti nei comuni router, di cui
potete leggere meglio a <https://dev.openwrt.org/ticket/12181>. Questo
bug impedisce che da una porta possa scaturire contemporaneamente
traffico taggato e non taggato, ovvero che una porta faccia parte di 2
VLAN, se in una delle quali essa risulta untagged. Ne consegue che,
semplicemente sostituendo all'untagged un ulteriore tag, questo bug
viene aggirato con 0 perdite funzionali.
Si noti bene che in realtà il 1043ND è esente da questo bug e dunque
avremmo potuto usare una VLAN 7 untagged. Ma non c'erano ragioni
particolari per desiderarlo, e quindi ho deciso di testare con una
configurazione che sarebbe obbligatoria su molti router "foglia" come il
740/741 e l'841.
Passiamo alle antenne.
Ovviamente bisogna impostare la modalità Bridge e creare le medesime
VLAN con gli stessi ID, per comunicare con quelle sul router.
Screenshot e breve HowTo.
http://imgur.com/zAQvvyu
- Impostare Network Mode a "Bridge"
- Esponiamo le impostazioni avanzate con Configuration Mode > Advanced
- Sezione VLAN: aggiungiamo, sull'interfaccia LAN0, una VLAN con ID
3-4-5-6, a seconda di quale porta del router la collegheremo.
- Sezione VLAN: aggiungiamo, sull'interfaccia LAN0, una VLAN con ID 7
per la gestione locale.
- Sezione Bridge: Eliminiamo BRIDGE0 cliccando su "Del"
- Scegliamo LAN0.7 come Management Interface
- Compiliamo gli indirizzi come da figura, utilizzando la LAN Ninux
assegnata al nostro nodo.
- Sezione Bridge: aggiungiamo un nuovo bridge (che ritroverà nome
BRIDGE0) e assegnamoli le interfacce WLAN0 e LAN0.{3,4,5,6} e
assicuriamoci che sia attivo.
Salviamo/Testiamo/Applichiamo. Tutte le altre impostazioni di AirOS non
sono minimamente afflitte da queste nuove modalità, e la vita continua
come sempre per i settaggi wireless.
Due parole sugli ID delle VLAN: perché partiamo da 3? Semplice: AirOS
non consente di utilizzare la VLAN con ID 1, mentre molto molto spesso
OpenWRT ha già una VLAN 2 per l'interfaccia WAN, e ha poco senso
mettersi a riordinarle.
A questo punto uno potrebbe avere la preoccupazione (e noi l'abbiamo
avuta): ma se uso le VLAN sulle antenne di un supernodo, poi ogni nodo
che si collegherà ad esso con le sue antenne dovrà utilizzare
necessariamente le VLAN? Questo causerebbe molti problemi per i neofiti
che vogliono entrare in Ninux, e per l'immediatezza di configurazione.
La risposte è: NO. Come detto, l'interfaccia wireless e la VLAN di
traffico (che viaggia, ovviamente, sulla porta eth0 dell'antenna) sono
tra loro in bridge. Il bridge si comporta esattamente come uno "switch
virtuale", e applica o rimuove il tag a seconda dell'interfaccia verso
la quale lo dovrà smistare. Dunque il traffico in ingresso sull'antenna
(ath0) proveniente, untagged, da un altro nodo viene girato verso
(eth0.3) il router a terra ma solo dopo che al pacchetto è stato
applicato il tag; similmente, quando il router a terra (eth0.3) inoltra
un pacchetto da inviare via 5GHz (ath0) il bridge riceverà il pacchetto
taggato dalla VLAN e rimuoverà il tag, per poi inoltrarlo verso il nodo
remoto che dunque vedrà solo il traffico untagged che è in grado di
gestire. In sostanza, ad un bridge Linux, possiamo assegnare le
interfacce come se fossero "porte":
- Se si tratta di un'interfaccia pura (es. ath0), essa si comporta come
una porta untagged.
- Se si tratta di un'interfaccia virtuale 802.1q (ovvero VLAN), essa si
comporta come una porta tagged.
Parlando di bridge e di wireless, torniamo sul router, per impostare
anche l'Access Point di distribuzione a 2.4GHz.
Ecco il file rilevante, commentato.
root a OpenWrt:~# cat /etc/config/wireless
config wifi-device 'radio0'
option type 'mac80211'
option macaddr '54:e6:fc:98:6c:60'
option hwmode '11ng'
option htmode 'HT20'
list ht_capab 'SHORT-GI-40'
list ht_capab 'DSSS_CCK-40'
option channel '9'
option disabled '0'
config wifi-iface
option device 'radio0'
option mode 'ap'
option encryption 'none'
option ssid 'newspigAP.calabria.ninux.org'
# unico settaggio veramente importante, è quello che
# lavora in combinazione con "option type 'bridge'
# presente in /etc/config/network all'interno
# dell'interfaccia con cui si desidera bridgiare
option network 'LAN_NINUX'
Su OpenWRT i bridge assumono il nome di br-<nome-interfaccia-ethernet>.
L'avvenuto successo del bridge tra rete locale Ninux e wifi 2.4GHz è
certificato dall'output di
root a OpenWrt:~# brctl show
bridge name bridge id STP enabled interfaces
br-LAN_NINUX 8000.54e6fc986c60 no eth0.7
wlan0
Ora chiunque può connettersi all'Access Point ed essere in Ninux, che
per gli stessi principi sopra esposti sul bridge, possono non
preoccuparsi assolutamente delle VLAN.
Il tutto coadiuvato da un bel DHCP.
root a OpenWrt:~# cat /etc/config/dhcp
config dnsmasq
option domainneeded '1'
option boguspriv '1'
option filterwin2k '0'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option nonegcache '0'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.auto'
config dhcp 'wan'
option interface 'wan'
option ignore '1'
config dhcp 'LAN_NINUX'
# vogliamo il dhcp sulla rete 10.87.x.0/24
option interface 'LAN_NINUX'
# i primi 5 sono riservati a router e antenne
option start '6'
option limit '150'
option leasetime '12h'
Veniamo ora al tocco finale: il routing. Ho installato solamente il
demone OLSR, senza il front-end web di LUCI. Non sono molto addentro
alle tante opzioni di OLSR, ma come spiegato da Spax nel suo talk, per
far fare il cuore del suo lavoro ad OLSR non basta altro che specificare
le interfacce sul quale dovrà girare, e le sottoreti che vogliamo
annunciare attraverso i messaggi HNA. È bastato dunque aggiungere le
sezioni nel file di configurazione di OLSRd, che su OpenWRT è
root a OpenWrt:~# cat /etc/config/olsrd
config olsrd
# uncomment the following line to use a custom config file instead:
#option config_file '/etc/olsrd.conf'
option IpVersion '4'
config LoadPlugin
option library 'olsrd_arprefresh.so.0.1'
config LoadPlugin
option library 'olsrd_dyn_gw.so.0.5'
config LoadPlugin
option library 'olsrd_httpinfo.so.0.1'
option port '1978'
list Net '0.0.0.0 0.0.0.0'
config LoadPlugin
option library 'olsrd_nameservice.so.0.3'
config LoadPlugin
option library 'olsrd_txtinfo.so.0.1'
option accept '0.0.0.0'
config InterfaceDefaults
option Mode 'mesh'
config Interface
option ignore '0'
option interface 'ANTENNA1'
option Mode 'mesh'
config Interface
option ignore '0'
option interface 'ANTENNA2'
option Mode 'mesh'
config Interface
option ignore '0'
option interface 'ANTENNA3'
option Mode 'mesh'
config Interface
option ignore '0'
option interface 'ANTENNA4'
option Mode 'mesh'
config Hna4
option netaddr '10.87.3.0'
option netmask '255.255.255.0'
Ultima cosa: aggiungere tutte le interfacce create per Ninux ad una zona
Firewall di OpenWRT. Tutto questo si fa in un solo colpo con
root a OpenWrt:~# uci set firewall. a zone[0].network='LAN_NINUX ANTENNA1
ANTENNA2 ANTENNA3 ANTENNA4'
Onestamente il firewall è l'unico aspetto che ha bisogno ancora di un
test esteso. Non ho avuto tempo, modo e voglia di esaminare quali sono i
default di OpenWRT e come possono influenzare il traffico
multi-interfaccia che creiamo sul routing a terra. Sia io che Peppe
abbiamo incontrato problemi che si è potuto risolvere semplicemente
spegnendo il firewall (/etc/init.d/firewall stop), ma a dire il vero nel
mio secondo giro di prove tutto è sembrato funzionare anche solo
aggiungendo tutte le interfacce alla stessa zona LAN, come abbiamo fatto
col comando appena visto. Spax mi informa che OpenWRT per default non
forwarda il traffico tra le interfacce appartenenti ad una stessa zona,
ma devo ancora capire in che modo ci affligge, se lo fa.
Stefanauss.
-------------- parte successiva --------------
Un allegato non testuale è stato rimosso....
Nome: signature.asc
Tipo: application/pgp-signature
Dimensione: 836 bytes
Descrizione: OpenPGP digital signature
URL: <http://ml.ninux.org/pipermail/calabria/attachments/20131223/cf965ac9/attachment-0001.sig>
Maggiori informazioni sulla lista
Calabria