[Ninux-Calabria] TP-Link TL-WR1043ND v2.x, AR8237N strano e routing a terra

[Stefano De Carlo]

TL; DR: In fondo trovate le modalità con cui si può trattare questo
switch in modo che digerisca il routing a terra. Per configurarlo
correttamente vi serve solo leggere in fondo :)

TL; DS(croll): porta 6 sempre tagged + grhowto.

~~~

Ciao,

volevo condividere con voi alcune speculazioni sullo switch (AR8237N) di
questo router, che è elettronicamente cablato in maniera diversa dagli
altri che utilizzano lo stesso silicio (TL-WDR3500, TL-WDR3600,
TL-WDR4300, tra quelli supportati da NinucsWrt), e la cosa si riflette
in OpenWrt e ha un impatto sulla guida al routing a terra.

* Del silicio dell'AR8237N fanno parte dei MAC chip. Sono quei
componenti dello switch convertono i pacchetti in uno stream di bytes.
Attenzione, non gestiscono lo stadio fisico, gli impulsi elettrici, ma
"scrivono" e "leggono" i pacchetti Ethernet da/per la CPU.

* Del silicio dell'AR8237N fanno parte due 2 GMII (Gigabit Media
Independent Interface) distinte. Le GMII sono una "API elettronica" di
interconnessione tra MAC e PHY (lo strato fisico, quello che traduce i
bytes da/per il MAC in impulsi elettrici). Sono standard, che è l'intero
punto della questione, così MAC e PHY se ne possono fregare dei dettagli
l'uno dell'altro.

* Ogni PHY ha il suo MAC chip (normale), e in più (nell'AR8237N) ce ne
sono 2 di "raccolta" (GMAC0 e GMAC1)

L'associazione GMAC + MII è quella che conosciamo come "porta cpu" dello
switch. È cioè la porta non-fisica dello switch attraverso la quale la
CPU può parlare "MAC" con lo switch.
Il kernel, di regola, la chiama "eth0".

Se siete familiari con il routing a terra sapete che nei router
normalmente ci capitano due casi:

1) Tutte le porte fanno capo a "eth0". Questo significa che il GMAC0
raccoglie tutte le porte fisiche in un bridge "elettronico" che si
imposta nei registri dello switch. La porta "WAN" verrà quindi creata ad
un livello molto più alto, grazie alle VLAN (eth0.1, eth0.2).

2) Tutte le porte meno la "blu/WAN" fanno capo a "eth0". Questo
significa che il GMAC0 bridgia elettronicamente tutte le porte fisiche
*meno una*, una modalità anch'essa prevista dai registri dello switch
(un cortocircuito, banalmente).
Cosa succede alla porta "blu/WAN"? È agganciata ad una sua MII dedicata
e da essa direttamente alla CPU, da cui sarà gestita in toto. Niente
GMAC di raccolta, la CPU la vede direttamente come un'interfaccia a sè
stante, che solitamente il kernel chiama "eth1". Da notare che non può
essere una qualsiasi porta, ma *quella*, elettronicamente predisposta a
questa modalità.

Ora, se vi ricordate abbiamo detto che l'AR8237N ha due GMAC e relative
MII, ed è per questo che sui modelli che lo montano vi trovate una "port
6". Ma sopra non abbiamo mai menzionato GMAC1, perchè? Perché la TP-Link
lo lascia inutilizzato su 3500/3600/4300, non c'è collegata nessuna
delle porte fisiche.
Sul 1043NDv2 invece GMAC1 gestisce la porta "blu/WAN" su una SGMII dedicata.

Questa è una differenza sostanziale rispetto ai due casi soliti perché
stavolta ci sono *due* associazioni GMAC + MII e di conseguenza *due*
"porte cpu" dello *stesso* switch, e di conseguenza *due* interfacce
(eth0 e eth1) che però *non* sono distinte: cosa più importante,
condividono la stessa VLAN table, perché questa è propria dello switch.

== CONFIGURAZIONE ==

La ripartizione di default dello switch in OpenWrt è questa (t = tagged,
u = untagged, x = off):

                ________________________________
               |               CPU              |
               |eth1                        eth0|
               |________________________________|
                 |                            |
_________________|____________________________|__
switch port   | p0 | p1 | p2 | p3 | p4 | p5 | p6 |
______________|____|____|____|____|____|____|____|
router port   |  - |lan4|lan3|lan2|lan1|wan |  - |
______________|____|____|____|____|____|____|____|
vlan1         |  u |  u |  u |  u |  u |  x |  x |
______________|____|____|____|____|____|____|____|
vlan2         |  x |  x |  x |  x |  x |  u |  u |
______________|____|____|____|____|____|____|____|


Questa ripartizione però assegna alle porte che partecipano nel br-lan
l'interfaccia eth1, mentre la solita eth0 viene assegnata alla WAN.
Tutto questo è rilevante perchè quando a partire da questo default si
vanno a modificare le VLAN agendo da LuCI, le interfacce corrispondenti
erroneamente (da netifd, methinks) vengono create su eth0.x, mentre a
noi servirebbero sulla eth1.x.
Se poi si creano nel passo successivo le Networks mettendo il pallino su
eth0.x, non funziona giustamente nulla.

Due possibili approcci (negli esempi, routing a terra con 1 antenna):

= Business as usual =

                ________________________________
               |               CPU              |
               |eth1                        eth0|
               |________________________________|
                 |                            |
_________________|____________________________|__
switch port   | p0 | p1 | p2 | p3 | p4 | p5 | p6 |
______________|____|____|____|____|____|____|____|
router port   |  - |lan4|lan3|lan2|lan1|wan |  - |
______________|____|____|____|____|____|____|____|
vlan2         |  t |  x |  x |  x |  x |  u |  t |
______________|____|____|____|____|____|____|____|
vlan3         |  t |  t |  x |  x |  x |  x |  t |
______________|____|____|____|____|____|____|____|
vlan7         |  t |  t |  u |  u |  u |  x |  t |
______________|____|____|____|____|____|____|____|

Trattiamo la porta 6 come qualsiasi porta CPU nel routing a terra: tutto
tagged.
In questo caso però OpenWrt torna a considerare come interfaccia-switch
la eth0 (ancora netifd?).
Dunque, così facendo, le VLAN-interface presentate da LuCI (eth0.x) sono
corrette e funzionanti.
Occhio alla network WAN: rimarrà eth0, che ora è invece lo switch-LAN.
Nell'esempio dobbiamo riassegnarla a eth0.2 in physical settings.

= Manuale =

                ________________________________
               |               CPU              |
               |eth1                        eth0|
               |________________________________|
                 |                            |
_________________|____________________________|__
switch port   | p0 | p1 | p2 | p3 | p4 | p5 | p6 |
______________|____|____|____|____|____|____|____|
router port   |  - |lan4|lan3|lan2|lan1|wan |  - |
______________|____|____|____|____|____|____|____|
vlan1 (unused)|  t |  t |  x |  x |  x |  x |  x |
______________|____|____|____|____|____|____|____|
vlan2         |  x |  x |  x |  x |  x |  u |  u |
______________|____|____|____|____|____|____|____|
vlan3         |  t |  t |  x |  x |  x |  x |  x |
______________|____|____|____|____|____|____|____|
vlan7         |  t |  t |  u |  u |  u |  x |  x |
______________|____|____|____|____|____|____|____|

In questo caso quando una porta CPU è tagged, l'altra è off.
Lo switch mantiene la separazione di default eth1-LAN + eth0-WAN,
ma ciò riporta in auge il problema delle VLAN-interface in LuCI, create
sull'interfaccia madre errata.
Per ovviare, semplicemente: quando creiamo una nuova Network *non*
spuntiamo la eth0.x che ci serve ma, nel campo di testo "Custom
Interface" digitiamo a mano eth1.x. Ricordate, la VLAN table è la stessa ;)

(Non mi ricordo se ho testato la WAN in questa configurazione, mal 99%
si e funzionava. Routing a terra 100% operativo.)

Non so che vantaggio possa esserci a eseguire il secondo tipo di
configurazione. L'unico che mi viene in mente è che, potenzialmente,
taggando entrambe le porte CPU tutto viene trattato dal solo GMAC0,
difatto rinunciando al throughput dedicato della seconda MII Gigabit.
Effetti sulle performance massime?

Stefanauss.

-------------- parte successiva --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://ml.ninux.org/pipermail/calabria/attachments/20140919/562bc4cf/attachment.pgp>