<div dir="ltr">Grazie Stefano, è uno degli argomenti che sto per raccogliere in Ground Routing - Appendix, lo includo nel documento, naturalmente citandoti. :-)<br></div><div class="gmail_extra"><br><div class="gmail_quote">Il giorno 19 settembre 2014 03:08, Stefano De Carlo <span dir="ltr"><<a href="mailto:stefanauss@gmail.com" target="_blank">stefanauss@gmail.com</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">TL; DR: In fondo trovate le modalità con cui si può trattare questo<br>
switch in modo che digerisca il routing a terra. Per configurarlo<br>
correttamente vi serve solo leggere in fondo :)<br>
<br>
TL; DS(croll): porta 6 sempre tagged + grhowto.<br>
<br>
~~~<br>
<br>
Ciao,<br>
<br>
volevo condividere con voi alcune speculazioni sullo switch (AR8237N) di<br>
questo router, che è elettronicamente cablato in maniera diversa dagli<br>
altri che utilizzano lo stesso silicio (TL-WDR3500, TL-WDR3600,<br>
TL-WDR4300, tra quelli supportati da NinucsWrt), e la cosa si riflette<br>
in OpenWrt e ha un impatto sulla guida al routing a terra.<br>
<br>
* Del silicio dell'AR8237N fanno parte dei MAC chip. Sono quei<br>
componenti dello switch convertono i pacchetti in uno stream di bytes.<br>
Attenzione, non gestiscono lo stadio fisico, gli impulsi elettrici, ma<br>
"scrivono" e "leggono" i pacchetti Ethernet da/per la CPU.<br>
<br>
* Del silicio dell'AR8237N fanno parte due 2 GMII (Gigabit Media<br>
Independent Interface) distinte. Le GMII sono una "API elettronica" di<br>
interconnessione tra MAC e PHY (lo strato fisico, quello che traduce i<br>
bytes da/per il MAC in impulsi elettrici). Sono standard, che è l'intero<br>
punto della questione, così MAC e PHY se ne possono fregare dei dettagli<br>
l'uno dell'altro.<br>
<br>
* Ogni PHY ha il suo MAC chip (normale), e in più (nell'AR8237N) ce ne<br>
sono 2 di "raccolta" (GMAC0 e GMAC1)<br>
<br>
L'associazione GMAC + MII è quella che conosciamo come "porta cpu" dello<br>
switch. È cioè la porta non-fisica dello switch attraverso la quale la<br>
CPU può parlare "MAC" con lo switch.<br>
Il kernel, di regola, la chiama "eth0".<br>
<br>
Se siete familiari con il routing a terra sapete che nei router<br>
normalmente ci capitano due casi:<br>
<br>
1) Tutte le porte fanno capo a "eth0". Questo significa che il GMAC0<br>
raccoglie tutte le porte fisiche in un bridge "elettronico" che si<br>
imposta nei registri dello switch. La porta "WAN" verrà quindi creata ad<br>
un livello molto più alto, grazie alle VLAN (eth0.1, eth0.2).<br>
<br>
2) Tutte le porte meno la "blu/WAN" fanno capo a "eth0". Questo<br>
significa che il GMAC0 bridgia elettronicamente tutte le porte fisiche<br>
*meno una*, una modalità anch'essa prevista dai registri dello switch<br>
(un cortocircuito, banalmente).<br>
Cosa succede alla porta "blu/WAN"? È agganciata ad una sua MII dedicata<br>
e da essa direttamente alla CPU, da cui sarà gestita in toto. Niente<br>
GMAC di raccolta, la CPU la vede direttamente come un'interfaccia a sè<br>
stante, che solitamente il kernel chiama "eth1". Da notare che non può<br>
essere una qualsiasi porta, ma *quella*, elettronicamente predisposta a<br>
questa modalità.<br>
<br>
Ora, se vi ricordate abbiamo detto che l'AR8237N ha due GMAC e relative<br>
MII, ed è per questo che sui modelli che lo montano vi trovate una "port<br>
6". Ma sopra non abbiamo mai menzionato GMAC1, perchè? Perché la TP-Link<br>
lo lascia inutilizzato su 3500/3600/4300, non c'è collegata nessuna<br>
delle porte fisiche.<br>
Sul 1043NDv2 invece GMAC1 gestisce la porta "blu/WAN" su una SGMII dedicata.<br>
<br>
Questa è una differenza sostanziale rispetto ai due casi soliti perché<br>
stavolta ci sono *due* associazioni GMAC + MII e di conseguenza *due*<br>
"porte cpu" dello *stesso* switch, e di conseguenza *due* interfacce<br>
(eth0 e eth1) che però *non* sono distinte: cosa più importante,<br>
condividono la stessa VLAN table, perché questa è propria dello switch.<br>
<br>
== CONFIGURAZIONE ==<br>
<br>
La ripartizione di default dello switch in OpenWrt è questa (t = tagged,<br>
u = untagged, x = off):<br>
<br>
________________________________<br>
| CPU |<br>
|eth1 eth0|<br>
|________________________________|<br>
| |<br>
_________________|____________________________|__<br>
switch port | p0 | p1 | p2 | p3 | p4 | p5 | p6 |<br>
______________|____|____|____|____|____|____|____|<br>
router port | - |lan4|lan3|lan2|lan1|wan | - |<br>
______________|____|____|____|____|____|____|____|<br>
vlan1 | u | u | u | u | u | x | x |<br>
______________|____|____|____|____|____|____|____|<br>
vlan2 | x | x | x | x | x | u | u |<br>
______________|____|____|____|____|____|____|____|<br>
<br>
<br>
Questa ripartizione però assegna alle porte che partecipano nel br-lan<br>
l'interfaccia eth1, mentre la solita eth0 viene assegnata alla WAN.<br>
Tutto questo è rilevante perchè quando a partire da questo default si<br>
vanno a modificare le VLAN agendo da LuCI, le interfacce corrispondenti<br>
erroneamente (da netifd, methinks) vengono create su eth0.x, mentre a<br>
noi servirebbero sulla eth1.x.<br>
Se poi si creano nel passo successivo le Networks mettendo il pallino su<br>
eth0.x, non funziona giustamente nulla.<br>
<br>
Due possibili approcci (negli esempi, routing a terra con 1 antenna):<br>
<br>
= Business as usual =<br>
<br>
________________________________<br>
| CPU |<br>
|eth1 eth0|<br>
|________________________________|<br>
| |<br>
_________________|____________________________|__<br>
switch port | p0 | p1 | p2 | p3 | p4 | p5 | p6 |<br>
______________|____|____|____|____|____|____|____|<br>
router port | - |lan4|lan3|lan2|lan1|wan | - |<br>
______________|____|____|____|____|____|____|____|<br>
vlan2 | t | x | x | x | x | u | t |<br>
______________|____|____|____|____|____|____|____|<br>
vlan3 | t | t | x | x | x | x | t |<br>
______________|____|____|____|____|____|____|____|<br>
vlan7 | t | t | u | u | u | x | t |<br>
______________|____|____|____|____|____|____|____|<br>
<br>
Trattiamo la porta 6 come qualsiasi porta CPU nel routing a terra: tutto<br>
tagged.<br>
In questo caso però OpenWrt torna a considerare come interfaccia-switch<br>
la eth0 (ancora netifd?).<br>
Dunque, così facendo, le VLAN-interface presentate da LuCI (eth0.x) sono<br>
corrette e funzionanti.<br>
Occhio alla network WAN: rimarrà eth0, che ora è invece lo switch-LAN.<br>
Nell'esempio dobbiamo riassegnarla a eth0.2 in physical settings.<br>
<br>
= Manuale =<br>
<br>
________________________________<br>
| CPU |<br>
|eth1 eth0|<br>
|________________________________|<br>
| |<br>
_________________|____________________________|__<br>
switch port | p0 | p1 | p2 | p3 | p4 | p5 | p6 |<br>
______________|____|____|____|____|____|____|____|<br>
router port | - |lan4|lan3|lan2|lan1|wan | - |<br>
______________|____|____|____|____|____|____|____|<br>
vlan1 (unused)| t | t | x | x | x | x | x |<br>
______________|____|____|____|____|____|____|____|<br>
vlan2 | x | x | x | x | x | u | u |<br>
______________|____|____|____|____|____|____|____|<br>
vlan3 | t | t | x | x | x | x | x |<br>
______________|____|____|____|____|____|____|____|<br>
vlan7 | t | t | u | u | u | x | x |<br>
______________|____|____|____|____|____|____|____|<br>
<br>
In questo caso quando una porta CPU è tagged, l'altra è off.<br>
Lo switch mantiene la separazione di default eth1-LAN + eth0-WAN,<br>
ma ciò riporta in auge il problema delle VLAN-interface in LuCI, create<br>
sull'interfaccia madre errata.<br>
Per ovviare, semplicemente: quando creiamo una nuova Network *non*<br>
spuntiamo la eth0.x che ci serve ma, nel campo di testo "Custom<br>
Interface" digitiamo a mano eth1.x. Ricordate, la VLAN table è la stessa ;)<br>
<br>
(Non mi ricordo se ho testato la WAN in questa configurazione, mal 99%<br>
si e funzionava. Routing a terra 100% operativo.)<br>
<br>
Non so che vantaggio possa esserci a eseguire il secondo tipo di<br>
configurazione. L'unico che mi viene in mente è che, potenzialmente,<br>
taggando entrambe le porte CPU tutto viene trattato dal solo GMAC0,<br>
difatto rinunciando al throughput dedicato della seconda MII Gigabit.<br>
Effetti sulle performance massime?<br>
<br>
Stefanauss.<br>
<br>
<br>_______________________________________________<br>
Calabria mailing list<br>
<a href="mailto:Calabria@ml.ninux.org">Calabria@ml.ninux.org</a><br>
<a href="http://ml.ninux.org/mailman/listinfo/calabria" target="_blank">http://ml.ninux.org/mailman/listinfo/calabria</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><div style="text-align:left"><span style="font-family:'courier new',monospace;font-size:small">#musk from <a href="http://calabria.ninux.org" target="_blank">calabria.ninux.org</a> - CS</span></div><div style="text-align:left"><font face="courier new, monospace"><br></font></div><div style="text-align:left"><font face="courier new, monospace">@openmusk</font></div></div>
</div>