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

[Luigi]

Grazie Stefano, è uno degli argomenti che sto per raccogliere in Ground
Routing - Appendix, lo includo nel documento, naturalmente citandoti. :-)

Il giorno 19 settembre 2014 03:08, Stefano De Carlo <stefanauss a gmail.com>
ha scritto:

> 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.
>
>
> _______________________________________________
> Calabria mailing list
> Calabria a ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/calabria
>
>


-- 
#musk from calabria.ninux.org - CS

@openmusk
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.ninux.org/pipermail/calabria/attachments/20140930/71d3d2e6/attachment-0001.html>