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

Mar 30 Set 2014 15:58:54 CEST

Il 30 settembre 2014 13:58, Luigi <open.musk a gmail.com> ha scritto:
> 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.

Ragazzi queste speculazioni sono utili ed è un peccato lasciarle solo in ML.
Se possibile raccogliamole su un google docs condiviso su ninux.org,
infondo sono questi i device entry level che verranno usati per anni,
ne vale la pena.

grazie stè !