Md at debian.org

tales of a debian maintainer

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.

The Product Bay

The Product Bay.

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.

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?

The Public Domain Manifesto

The Public Domain Manifesto.

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

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?

Il diritto all'oblio: caro web, dimenticami

Il diritto all'oblio: caro web, dimenticami.

About

Sono l'Italia che non vuole bene.

S M T W T F S
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28            

See also:

My blogroll:


W3C HTML 4.01
W3C CSS 2.0     

Powered by Bryar.pm.