VIMAGE, epair/if_bridge or netgraph?

[dteske at FreeBSD.org]

> -----Original Message-----
> From: dteske at FreeBSD.org [mailto:dteske at FreeBSD.org]
> Sent: Saturday, March 29, 2014 10:58 AM
> To: 'Palle Girgensohn'
> Cc: freebsd-virtualization at FreeBSD.org; 'Devin Teske'
> Subject: RE: VIMAGE, epair/if_bridge or netgraph?
> 
> 
> 
> > -----Original Message-----
> > From: owner-freebsd-virtualization at freebsd.org [mailto:owner-freebsd-
> > virtualization at freebsd.org] On Behalf Of Palle Girgensohn
> > Sent: Monday, June 11, 2012 2:37 PM
> > To: freebsd-virtualization at FreeBSD.org
> > Subject: VIMAGE, epair/if_bridge or netgraph?
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi,
> >
> > I'm updating some jail servers, and want to use VIMAGE. Compiled it
> > into the kernel, learned the hard way not to even include PF in the
> > same kernel [1], so now it works quite well.
> >
> > I am setting up many similar jails, some for testing, some for
> > production. The applications are web servers, som tomcat+apache's, and
> > some other standard type of services like email and ldap, simple stuff.
> > I need no fancy network control, I just need it to work. For each jail
> > there are two interfaces, one public, connected to a software bridge
> > (if_bridge or
> > ng_bridge) acting as a switch, and one internal, for maintenance,
> > connected to a different software bridge. To each software bridge, I
> > connect a physical external interface from the jail host.
> >
> > I am trying to decide whether to use epair and if_bridge, or to use
> netgraph.
> > For netgraph, there is a nice package at DruidBSD [3]. When I found
> > that, I had already rewritten the standard jail script, using the
> > v2 patches from polymorf [4]. They work equally fine for my purpose.
> >
> > So now I need to know which scales best, is there a difference in
> > performance or stability between netgraph and epair/if_bridge?
> >
> > Cheers,
> > Palle
> >
> >
> > [1] http://forums.freebsd.org/showthread.php?t=31765
> >
> > [2] http://forums.freebsd.org/showthread.php?t=31949
> >
> > [3] http://druidbsd.sourceforge.net/vimage.shtml
> >
> > [4] http://wiki.polymorf.fr/index.php?title=Howto:FreeBSD_jail_vnet
> 
> [Devin Teske]
> 
> Never saw a reply to this and I'm locating round-tuits to tackle e-mails that
> I've marked as "needing reply":
> 
> I have not profiled

Ugh, that was originally "I have not profiled [epair but I have profiled] netgraph"
-- 
Cheers,
Devin

> netgraph to have a limitation of 65530 eiface devices off a
> single if_bridge, but are allowed multiple bridges with that many devices.
> 
> The problems that you run into with that many devices is that if all the
> interfaces are visible to a single jail or single host... your "ifconfig"
> command could take several hours (about 4) to enumerate each iface to the
> screen.
> 
> I didn't mess much with epair because it failed to produce a situation where I
> could speak separate subnets over the same wire. Netgraph made it easy by
> way of being able to enable promiscuous and disable the "autosrc" feature
> (as you perhaps already found in my code you linked to above).
> --
> Cheers,
> Devin
> 
> 
> 
> _____________
> The information contained in this message is proprietary and/or confidential.
> If you are not the intended recipient, please: (i) delete the message and all
> copies; (ii) do not disclose, distribute or use the message in any manner; and
> (iii) notify the sender immediately. In addition, please be aware that any
> message addressed to our domain is subject to archiving and review by
> persons other than the intended recipient. Thank you.

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.