Tanto per followup, ecco che ho cambiato il MTU di sburratone 5.3.3:<div><div>XM.v5.3.3.sdk# ifconfig eth1_real mtu 1519</div><div>ifconfig: SIOCSIFMTU: Invalid argument</div><div>XM.v5.3.3.sdk# ifconfig eth1_real mtu 1518</div>
<div>XM.v5.3.3.sdk# ifconfig eth0_real mtu 1518</div><div>XM.v5.3.3.sdk# ifconfig eth0 mtu 1518</div><div>XM.v5.3.3.sdk# ifconfig</div><div>eth0 Link encap:Ethernet HWaddr 00:27:22:39:D2:1D<br></div><div> inet addr:192.168.145.49 Bcast:192.168.145.63 Mask:255.255.255.240</div>
<div> inet6 addr: fe80::227:22ff:fe39:d21d/64 Scope:Link</div><div> UP BROADCAST RUNNING PROMISC ALLMULTI MULTICAST MTU:1518 Metric:1</div><div> RX packets:18632 errors:0 dropped:0 overruns:0 frame:0</div>
<div> TX packets:79168 errors:0 dropped:0 overruns:0 carrier:0</div><div> collisions:0 txqueuelen:0</div><div> RX bytes:10858627 (10.3 MiB) TX bytes:12361624 (11.7 MiB)</div><div><br></div><div>
eth0_real Link encap:Ethernet HWaddr 00:27:22:39:D2:1D</div><div> inet6 addr: fe80::227:22ff:fe39:d21d/64 Scope:Link</div><div> UP BROADCAST RUNNING PROMISC MULTICAST MTU:1518 Metric:1</div><div> RX packets:18632 errors:0 dropped:0 overruns:0 frame:0</div>
<div> TX packets:79169 errors:0 dropped:0 overruns:0 carrier:0</div><div> collisions:0 txqueuelen:500</div><div> RX bytes:11119475 (10.6 MiB) TX bytes:12361694 (11.7 MiB)</div><div><br></div><div>
eth1_real Link encap:Ethernet HWaddr 02:27:22:39:D2:1D</div><div> UP BROADCAST PROMISC MULTICAST MTU:1518 Metric:1</div><div> RX packets:0 errors:0 dropped:0 overruns:0 frame:0</div><div> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0</div>
<div> collisions:0 txqueuelen:500</div><div> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)</div><div><br></div><div>lo Link encap:Local Loopback</div><div> inet addr:127.0.0.1 Mask:255.0.0.0</div>
<div> inet6 addr: ::1/128 Scope:Host</div><div> UP LOOPBACK RUNNING MTU:16436 Metric:1</div><div> RX packets:4 errors:0 dropped:0 overruns:0 frame:0</div><div> TX packets:4 errors:0 dropped:0 overruns:0 carrier:0</div>
<div> collisions:0 txqueuelen:0</div><div> RX bytes:352 (352.0 B) TX bytes:352 (352.0 B)</div><div><br></div></div><div><br></div><div>Le nuove versioni di AirOS accetteranno i mini_jumbo e..naturalmente il WIFI accetta già ora MTU un sacco più alti.</div>
<div><br></div><div><div>XM.v5.3.3.sdk# ifconfig ath0 mtu 2291</div><div>ifconfig: SIOCSIFMTU: Invalid argument</div><div>XM.v5.3.3.sdk# ifconfig ath0 mtu 2290</div><div>XM.v5.3.3.sdk# ifconfig</div><div>ath0 Link encap:Ethernet HWaddr 00:27:22:38:D2:1D</div>
<div> inet addr:172.16.145.12 Bcast:172.16.255.255 Mask:255.255.0.0</div><div> inet6 addr: fe80::227:22ff:fe38:d21d/64 Scope:Link</div><div> UP BROADCAST RUNNING PROMISC ALLMULTI MULTICAST MTU:2290 Metric:1</div>
<div> RX packets:466352 errors:0 dropped:0 overruns:0 frame:0</div><div> TX packets:266281 errors:0 dropped:0 overruns:0 carrier:0</div><div> collisions:0 txqueuelen:0</div><div> RX bytes:314021141 (299.4 MiB) TX bytes:41735771 (39.8 MiB)</div>
</div><div><br></div><div><br></div><div>Questo, come dice Maurizio, non permette di usare impunemente GRE, per il fatto del doppio header IP, serve sempre il clamping del MSS o il PMTUD che dentro ninux funziona sempre.</div>
<div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2012/11/9 Pierluigi Checchi <span dir="ltr"><<a href="mailto:p.checchi@ieee.org" target="_blank">p.checchi@ieee.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
E' vero grande mauriziooo hai ragione!<div>Mi so scordato un pezzo, però, tanto per cavarmela, MPLS è -anche- utilizzato con una specie di tunnel mode a layer3, con dentro IP (peraltro la configurazione spesso consigliata). Quindi siamo da capo a 12.</div>
<div>Io ho massima stima per GRE e non è vero che lo hanno abbandonato tutti. </div><div>Io lo uso per esempio. GRE vince, fratello.</div><div><br></div><div><br></div><div><br></div><div><br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">2012/11/9 Maurizio Scarpa <span dir="ltr"><<a href="mailto:scarpam72@gmail.com" target="_blank">scarpam72@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Il 09/11/2012 16:03, Pierluigi Checchi
ha scritto:<br>
</div>
<blockquote type="cite">MPLS aggiunge a ethernet 4 byte e nei casi di uso
pratico di MPLS inside MPLS (tipico del VPLS) anche 8 byte, contro
il GRE che ne aggiunge solo 4 di byte. </blockquote>
<br>
...e l'header IP che MPLS non aggiunge dove lo mettiamo?<br>
<br>
dal sito di Mikrotik (non lo trovo una referenza così solida ma lo
hai citato tu ...).<br>
<<<br>
GRE the same as <a href="http://wiki.mikrotik.com/wiki/Manual:Interface/IPIP" title="Manual:Interface/IPIP" target="_blank"> IPIP</a> and <a href="http://wiki.mikrotik.com/wiki/Manual:Interface/EoIP" title="Manual:Interface/EoIP" target="_blank"> EoIP</a> were originally developed
as stateless tunnels. Meaning that if remote end of the tunnels goes
down all traffic that was routed over the tunnels gets blackholed.
To solve this problem RouterOS have added keepalive feature for GRE
tunnels.
<p>GRE tunnel adds 24 byte overhead (4-byte gre header + 20-byte IP
header).>><br>
</p>
<p>O da questo MPLS for beginners
(<a href="http://mccltd.net/blog/wp-content/uploads/2010/04/MPLS-FAQ-For-Beginners1.pdf" target="_blank">http://mccltd.net/blog/wp-content/uploads/2010/04/MPLS-FAQ-For-Beginners1.pdf</a>)
si capisce la differenza:<br>
</p>
<p>Q. Generic Routing Encapsulation (GRE) tunnel has an overhead of
<u><b>24</b></u><u><b><br>
</b></u><u><b>bytes</b></u>. How much overhead does an MPLS LSP
tunnel have?<br>
</p>
<p>A. An MPLS LSP tunnel has <u><b>one label (four bytes)</b></u><u><b>
or two labels</b></u> (for example, when using<br>
Link Protection Fast reroute) of overhead. Unlike GRE tunnel, MPLS
does not change the IP<br>
header. Instead, the label stack is imposed on to the packet that
takes the tunnel path.<br>
</p>
Ad ogni modo MPLS è capace di trasportare anche frame Ethernet
"pure" senza che l'IP ci sia dentro o fuori (ATOM = Any Transport
Over MPLS) quindi non necessita di IP per trasportare iltraffico ma
usa il piano di controllo IP per identificare i percorsi. Il piano
di frowarding MPLS è completamente aware dell'IP (non a caso nel
modello OSI MPLS è al 2.5 mentre IP è al 3).<br>
<br>
Sull'efficienza dei protocolli non discutiamo perchè se GRE è stato
abbandonato da tutti (siamo nel 2012 non dimentichiamolo mai) un
motivo dovrà pure esserci ...<br>
<br>
Su quello che devo leggere o sentire aprezzo tutti i suggerimenti e
le fonti anche perchè non si smette mai di imparare ma ho il dannato
viziaccio di usare anche il mio cervello non mi limito a ripetere
passivamente gli spot pubblicitari.<br>
<br>
Non ho fonti maggiormente autoritative di quelle che ti ho elencato
da suggerirti ma mi limito a siggerirti di leggere con maggiore
attenzione le RFC per evitare di dimenticare un pezzo di un
protocollo.<br>
Thx<br>
<br>
Bye bye<span class="HOEnZb"><font color="#888888"><span><font color="#888888"><br>
<pre cols="72">--
=======================================================================
Ing. Maurizio Scarpa
Via Lucrezia Romana, 65
00043 - Ciampino (RM)
mail: <a href="mailto:scarpam72@gmail.com" target="_blank">scarpam72@gmail.com</a>
skype: scarpam72
=======================================================================
</pre>
</font></span></font></span></div>
</blockquote></div><br></div>
</blockquote></div><br></div>