Replacing a legacy uml-switch with bess

Anton Ivanov anton.ivanov at cambridgegreys.com
Thu Jan 7 07:58:16 EST 2021


On 07/01/2021 12:31, Joshua Hawking wrote:
> Hi everyone,
> 
> I currently maintain a project called Netkit which facilitates network
> simulation using UML machines. This project is quite old and we've been
> working on upgrading it to a modern codebase.
> 
> Netkit relies on using uml_net for communication between the machines.
> It uses the legacy uml_switches to create hubs that connect to the
> machine, using the old ethX command line parameters. For example:
> 
> /home/josh/netkit-kernel
> --eth0=daemon,,,/home/josh/.netkit/vhub_Internet.cnct
> 
> where the vhub_Internet.cnct is the uml_switch socket. We're looking to
> upgrade this to use the new vector networking to utilize the better
> performance and remove legacy code that could break on a kernel update.
> 
> I've been looking at the linux kernel documentation that discusses using
> the Bess switch software to provide networking between UML machines.
> (https://github.com/torvalds/linux/blob/master/Documentation/virt/uml/user_mode_linux_howto_v2.rst#bess-socket-transport)
> 
> However, I can't find any good examples of using Bess with UML and was
> wondering whether anyone on the mailing list has any advice/examples.
> 
> I noted that Anton had submitted a PR to Bess to improve UML support and
> I was wondering whether this means that the build without this patch
> would not work with UML at all.
> 
> https://github.com/NetSys/bess/pull/1022
> 
> Hopefully someone may be able to point me in the right direction on
> handling uml_switch removal!

It will, but you need a fairly complex pipeline.

Basically, BESS replicator module which you need for BCAST/MCAST as well 
as flooding does not have a reflection check.

So f.e. 3 ports wired to a Replicator will not work.

As a result you cannot implement a simple shared switch and have to do a 
fully featured per-port pipeline with "drop to slow path for learning", 
implicit reflection checks, etc.

The workaround would be to have

inPort->L2Forwarding->Replicator

chain for each port and ensure that the Replicator is wired only to 
other ports in the same VLAN.

A.

> 
> Thanks,
> 
> Josh
> 
> 
> 
> _______________________________________________
> linux-um mailing list
> linux-um at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-um
> 


-- 
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/



More information about the linux-um mailing list