Tanto per followup, ecco che ho cambiato il MTU di sburratone 5.3.3: XM.v5.3.3.sdk# ifconfig eth1_real mtu 1519 ifconfig: SIOCSIFMTU: Invalid argument XM.v5.3.3.sdk# ifconfig eth1_real mtu 1518 XM.v5.3.3.sdk# ifconfig eth0_real mtu 1518 XM.v5.3.3.sdk# ifconfig eth0 mtu 1518 XM.v5.3.3.sdk# ifconfig eth0 Link encap:Ethernet HWaddr 00:27:22:39:D2:1D inet addr:192.168.145.49 Bcast:192.168.145.63 Mask:255.255.255.240 inet6 addr: fe80::227:22ff:fe39:d21d/64 Scope:Link UP BROADCAST RUNNING PROMISC ALLMULTI MULTICAST MTU:1518 Metric:1 RX packets:18632 errors:0 dropped:0 overruns:0 frame:0 TX packets:79168 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:10858627 (10.3 MiB) TX bytes:12361624 (11.7 MiB)
eth0_real Link encap:Ethernet HWaddr 00:27:22:39:D2:1D inet6 addr: fe80::227:22ff:fe39:d21d/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1518 Metric:1 RX packets:18632 errors:0 dropped:0 overruns:0 frame:0 TX packets:79169 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:11119475 (10.6 MiB) TX bytes:12361694 (11.7 MiB) eth1_real Link encap:Ethernet HWaddr 02:27:22:39:D2:1D UP BROADCAST PROMISC MULTICAST MTU:1518 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:352 (352.0 B) TX bytes:352 (352.0 B) Le nuove versioni di AirOS accetteranno i mini_jumbo e..naturalmente il WIFI accetta già ora MTU un sacco più alti. XM.v5.3.3.sdk# ifconfig ath0 mtu 2291 ifconfig: SIOCSIFMTU: Invalid argument XM.v5.3.3.sdk# ifconfig ath0 mtu 2290 XM.v5.3.3.sdk# ifconfig ath0 Link encap:Ethernet HWaddr 00:27:22:38:D2:1D inet addr:172.16.145.12 Bcast:172.16.255.255 Mask:255.255.0.0 inet6 addr: fe80::227:22ff:fe38:d21d/64 Scope:Link UP BROADCAST RUNNING PROMISC ALLMULTI MULTICAST MTU:2290 Metric:1 RX packets:466352 errors:0 dropped:0 overruns:0 frame:0 TX packets:266281 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:314021141 (299.4 MiB) TX bytes:41735771 (39.8 MiB) 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. 2012/11/9 Pierluigi Checchi <p.chec...@ieee.org> > E' vero grande mauriziooo hai ragione! > 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. > Io ho massima stima per GRE e non è vero che lo hanno abbandonato tutti. > Io lo uso per esempio. GRE vince, fratello. > > > > > > > 2012/11/9 Maurizio Scarpa <scarpa...@gmail.com> > >> Il 09/11/2012 16:03, Pierluigi Checchi ha scritto: >> >> 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. >> >> >> ...e l'header IP che MPLS non aggiunge dove lo mettiamo? >> >> dal sito di Mikrotik (non lo trovo una referenza così solida ma lo hai >> citato tu ...). >> << >> GRE the same as IPIP<http://wiki.mikrotik.com/wiki/Manual:Interface/IPIP>and >> EoIP <http://wiki.mikrotik.com/wiki/Manual:Interface/EoIP> 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. >> >> GRE tunnel adds 24 byte overhead (4-byte gre header + 20-byte IP >> header).>> >> >> O da questo MPLS for beginners ( >> http://mccltd.net/blog/wp-content/uploads/2010/04/MPLS-FAQ-For-Beginners1.pdf) >> si capisce la differenza: >> >> Q. Generic Routing Encapsulation (GRE) tunnel has an overhead of *24** >> **bytes*. How much overhead does an MPLS LSP tunnel have? >> >> A. An MPLS LSP tunnel has *one label (four bytes)** or two labels* (for >> example, when using >> Link Protection Fast reroute) of overhead. Unlike GRE tunnel, MPLS does >> not change the IP >> header. Instead, the label stack is imposed on to the packet that takes >> the tunnel path. >> 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). >> >> Sull'efficienza dei protocolli non discutiamo perchè se GRE è stato >> abbandonato da tutti (siamo nel 2012 non dimentichiamolo mai) un motivo >> dovrà pure esserci ... >> >> 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. >> >> 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. >> Thx >> >> Bye bye >> >> -- >> ======================================================================= >> Ing. Maurizio Scarpa >> >> Via Lucrezia Romana, 65 >> 00043 - Ciampino (RM) >> mail: scarpa...@gmail.com >> skype: scarpam72 >> ======================================================================= >> >> >
_______________________________________________ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless