Advances in networking for virtual machines
So far the networking of virtual machines has usually been managed by configuring a Virtual Ethernet Bridge (VEB) in the host, i.e. the good old implementation of 802.1D in the Linux Kernel:
A Virtual Ethernet Bridge (VEB) is a capability within a physical end station that supports local bridging between multiple virtual end stations and (optionally) the external bridging environment.
While this works well and in some cases is the best solution, in other setups performances or policy needs dictate that the traffic between virtual machines is forwarded to an external bridge (the Ethernet switch connected to the host) and back without having in the host a real bridge learning MAC addresses from its ports and implementing the STP. Enters the VEPA:
A Virtual Ethernet Port Aggregator (VEPA) is a capability within a physical end station that collaborates with an adjacent, external bridge to provide bridging support between multiple virtual end stations and external networks. The VEPA collaborates by forwarding all station-originated frames to the adjacent bridge for frame processing and frame relay (including "hairpin" forwarding) and by steering and replicating frames received from the VEPA uplink to the appropriate destinations.
Support for VEPAs has been added to Linux 2.6.33 with a simple change to the macvlan driver.
The next step will be to use the macvtap driver (available in 2.6.34), which exposes a tap character device usable by kvm-qemu and "connected" to a macvlan-like interface.
Ancora su 1.0.0.0/8
Per evitare di intasare il route collector, RIPE ha smesso di annunciare 1.1.1.0/24 e 1.2.3.0/24 e quindi ho colto l'occasione per provare a farlo io per un po' (limitatamente a MIX, NAMEX e MINAP).
Ho ricevuto traffico da diversi peer che evidentemente non filtrano i miei annunci, e sospetto che ne arriverebbe molto di più se alcuni non avessero una prefix-list anti-bogon non aggiornata... :-)
Mi sono arrivati 300-350 Kbps: il più sono 3 stream da 78 Kbps verso la porta UDP 15206 e SYN verso la porta TCP 25. Per il resto ho visto broadcast NETBIOS verso 1.1.1.255 (da un ospedale, a giudicare dai nomi), ping, ACK e SYNACK per protocolli assortiti.
Il traffico SMTP è praticamente tutto di messaggi verso zaobao.com.sg (MX 1.1.1.1), che riceve backscatter perché falsificato da uno spammer, e bbspam.com (MX 1.2.3.4) che è una storia istruttiva su come non si dismette un servizio usato da terzi non cooperanti.
Il traffico UDP invece è il risultato di scansioni SIP alla ricerca di telefoni e centralini insicuri, questi blog spiegano i dettagli: 1, 2.
annunciate delle sottoreti di 1.0.0.0/8
Come di consueto dopo ogni nuova allocazione di reti da ICANN a un RIR, RIPE ha iniziato ad annunciare da uno dei propri route collector alcune route di prova per verificane la raggiungibilità.
Questo caso è particolarmente interessante, perché con l'allocazione di 1.0.0.0/8 ad APNIC oggi RIPE ha iniziato ad annunciare anche delle route che coprono gli IP "interessanti" 1.1.1.1 e 1.2.3.4.
Secondo una prima ricognizione veloce che ho fatto su alcune reti italiane, Telecom Italia, Tiscali ed I.Net accettano le route ma a quanto pare non hanno ancora aggiornato le ACL di confine perché non arrivano le risposte.
Da WIND funziona tutto, mentre da Fastweb ovviamente non funziona nulla perché come è noto (ab)usano internamente 1.0.0.0/8 per indirizzare i clienti di Milano.
MCLink ha la route per 1.2.3.0/24 ma c'è una route interna che copre 1.1.1.0/24. Anche in questo caso le risposte non arrivano.
Seeweb funziona. :-)
In ogni caso, 1.1.1.1 non è quasi mai raggiungibile perché quasi tutti i percorsi arrivano ad AMS-IX tramite Tata che lo ha null-routed per motivi ignoti.
Mi dicono che il route collector sta ricevendo parecchie decine di Mbps di traffico per queste reti, se vedete pacchetti persi è perché al momento ha solo una porta a 10 Mbps verso AMS-IX.
Digest di UKNOF14 e UKNOF15
Ecco la solita rassegna degli interventi fatti ai meeting 14 e 15 di UKNOF che trovato più interessanti.
- Broadband Forum Overview: panoramica su diverse architetture broadband presenti e future.
- Care and Feeding of Optical Fibre: pulire sempre i connettori!
- Fixed Mobile Convergence: panoramica delle picocelle vendute da C&W. Rimango scettico.
- .uk, F root e K root si preparano a rendere sicure le proprie zone con DNSSEC. Quanti anni ci vorranno ancora per .it? Cosa bisogna fare per fare percepire ai clienti un bisogno di DNSSEC che mi permetta di venderglielo? Esiste una smart card o token USB con funzioni di HSM che fornisca PKCS#11 senza bisogno di middleware proprietario? Controllate i vostri firewall e CPE!
- Route Servers for !Dummies: capite meglio a cosa servono, perché ne sentirete riparlare presto.
- Route Server Bake-off Results: test delle principali piattaforme.
- BIRD Route Server at LINX: da tenere d'occhio, ultimamente lo sviluppo è ricominciato. Immagino che abbiano trovato dei nuovi tesisti. :-)
- The Internet from Zen's point of view: "come eravamo".
- IETF v6ops Deployment Questionnaire: rispondete se fornite accesso.
- Naked BGP: come è fatto il wire protocol. Interessante route injector.
- A Practical Perspective on Traffic Engineering: a cosa serve. Arte o scienza?
Dell Latitude, VT support and KVM
If you have a recent Dell Laptop (I tested this on a Latitude E6400) and even if VT support is enabled in the BIOS setup you get this error when you try to load kvm-intel:
kvm: disabled by bios
then make sure that the "Trusted Execution" feature in the "Virtualization Support" menu is disabled.
Should I blame Dell or the KVM developers?
H.264, Firefox and the <video> element
Recently some Mozilla developers (1, 2) have been trying to justify the lack of support of the HTML 5 <video> element in Firefox for the system-provided codecs (e.g. GStreamer, DirectShow and so on).
While I fully agree that patented codecs like H.264 are very bad for the Internet, it is not clear to me how watching H.264 video with the proprietary Flash plugin would help promoting unencumbered codecs more than watching H.264 video without using non-free software.
Beware: if your position is that there is no need to watch H.264 Youtube videos then please refrain from wasting your and my time with a reply, because you are missing the point (and probably many others as well).
call center
- Operatrice Vodafone: «[...] Lei ha già una linea di rete fissa in casa?»
- Md: «No, non ho bisogno che qualcuno mi chiami dagli anni '80, buonasera.»
Curiosa anche la spudorata bugia iniziale "siccome lei è un buon cliente Vodafone vogliamo proporle...", a meno che considerino buoni clienti quelli che non usano il telefono.
È la seconda volta in tre giorni, qualcuno ha una ricetta semplice per farli smettere di chiamarmi?