[Ninux-Calabria] routing a terra

Lun 23 Dic 2013 19:32:35 UTC

>
>
> 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.
>

Purtroppo è stato programmato con i piedi, per avere certezza della
modifiche in network bisogna sempre:

/etc/init.d/network restart

Il fatto che sbatta fuori è condizionato alla VLAN1, eth0 è occupato per il
bridge e attivando lo switch releghiamo l'I/O delle porte ethernet alle
VLAN configurate (VLAN1 di default). Le CPU untagged in VLAN1 solitamente
oscurano tutto perchè untaggano la CPU per una specifica VLAN e di
conseguenza oscurano la VLAN default (VLAN0), spiegato più in seguito.

però il ripristino della copia di backup funziona sempre :)

A Verde ho usato vlan1 e vlan2 in questa configurazione, riscrivendola in:

          eth0.1    Link encap:Ethernet  HWaddr 64:66:B3:41:3F:71
          inet addr:172.17.87.13  Bcast:172.17.255.255  Mask:255.255.0.0

          eth0.2    Link encap:Ethernet  HWaddr 64:66:B3:41:3F:71
          inet addr:192.168.1.33  Bcast:192.168.1.255  Mask:255.255.255.0

config switch_vlan
option device 'eth0'
option vlan '1'
option vid '1'
option ports '0t 2 4t'

config switch_vlan
option device 'eth0'
option vlan '2'
option vid '2'
option ports '0t 1 4t'

La porta 4 è di trunking, un jolly.
Lasciando tutte le CPU delle VLAN come tagged, le porte restanti comunicano
di default sulla VLAN0 come untagged e quì credo di capire che VLAN0
corrisponde ad eth0 (Vlan default, interfaccia che contiene sub-interfacce)
che essendo bridgata in br-lan deve avere - per forza - la CPU untagged
altrimenti blocca tutto.

se noi untagghiamo una CPU di una VLAN dobbiamo essere coscienti che stiamo
a sottrarre l'untagged alla VLAN default !!!

swconfig sembra confermarcelo:

root a VerdebinarioNinux:~# swconfig dev switch0 show
Global attributes:
enable_vlan: 1
Port 0:
pvid: 0
link: port:0 link:up speed:1000baseT full-duplex txflow rxflow
Port 1:
pvid: 2
link: port:1 link:up speed:100baseT full-duplex auto
Port 2:
pvid: 1
link: port:2 link:up speed:100baseT full-duplex auto
Port 3:
pvid: 0
link: port:3 link:down
Port 4:
pvid: 0
link: port:4 link:down
VLAN 0:
vid: 0
ports: 0t 3 4t
VLAN 1:
vid: 1
ports: 0t 2 4t
VLAN 2:
vid: 2
ports: 0t 1 4t

In questa configurazione abbiamo la porta 3 che comunica untagged sulla
VLAN0 (ovvero br-lan, essendo eth0 impegnato) e la porta 4, di trunking,
che comunica untagged sulla rete VLAN0/br-lan e tagged per tutte le VLAN.

La pratica conferma la regola, tagged non è esclusivo e possiamo crearne
fino a 16 in openWRT mentre l'untagged riserva una porta per un link eth
classico.

A verde il router ha la br-lan come 10.87.8.0 e due vlan, una per 172 e
un'altra per 192.
se dovessi aggiungere un'antenna taggerei la porta 3 o userei as-is la
porta 4.

Ad ogni modo la strategia di Stefano per risparmiare un indirizzo IP penso
sia de facto la migliore soluzione per la rete.

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.
>

Se posti la sequenza di comandi possiamo scriptarlo in un wizard con
semplici raw input bash.

>
> 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.

Considero che i comandi di UCI sono universali mentre i chip fanno più di
testa loro. Che faccia dannare è cosa amara...

> http://imgur.com/zAQvvyu

spettacolo.

>
> 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.
>
>
Sul TL-740N la WAN è sulla eth1. Se avesse più memoria sarebbe il top.

> 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.

Alla pari di una scoperta copernicana, la direzione dello switch
tagga/untagga i frames, scriviamolo sui muri.

> 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.
>

La firewall può salire sù, va creata una zona per ogni rete, pertanto
zona_172 e zona_10. Il Bug è che luci quando salva e "applica" include nel
postrouting esclusivamente la vlan1 :)
Quindi un essere umano normale dovrebbe inserire le regole mancati a mano
oppure ricreare da capo la firewall nell'eventualità di fare navigare i
frames attraverso le reti delle interfaccie e non solo esclusivamente sulle
interfacce (per il quale l'ip_forward basta )

Stè questa tua esperienza secondo me la puoi pubblicare di sana pianta sul
blog :)
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.ninux.org/pipermail/calabria/attachments/20131223/a922e227/attachment.htm>