[Firehol-devs] [Firehol-support] Testing and emulation with network namespaces
Tsaousis, Costa
costa at tsaousis.gr
Wed Apr 1 09:09:04 BST 2015
Hi Phil,
this is very nice.
I have a few questions:
1. Can a physical lan be linked to a virtual switch? For example, I
have two ethernet devices, can I link each of these to a different
virtual switch with a different virtual gateway?
2. Can physical ethernet vlans join virtual switches?
3. Is QoS operational on the virtual ethernets? This opens a whole set
of new possibilities for QoS.
4. Last time I checked, namespaces had an issue with logging,
especially kernel logging. I was unable to monitor the iptables logs
of the namespaces. Have you found any solution?
Costa
On Wed, Apr 1, 2015 at 12:49 AM, Phil Whineray <phil at sanewall.org> wrote:
> Hi
>
> I've been on a bit of a mission trying to work out the best way of dealing
> with mixed router/bridge configurations which took me down the path of
> wanting to emulate complex network setups.
>
> Since linux 2.6.24 there has been support for network namespaces. These
> are used in the firehol unit tests just to prevent messing with your normal
> firewall set.
>
> Much more can be done though, see https://lwn.net/Articles/580893/
> for some info. I now have a script which can take a setup file with
> a simple format and automate the setup of a virtual network of hosts
> and switches of arbitrary complexity. See below for a complete setup.
>
> There is currenly no attempt to connect to the root namespace (and
> hence the outside world) - that will need to be done manually if you
> really need it.
>
> The question I have - is it useful enough to include in the firehol
> tree, either as a testing helping tool or even main script? Also, has
> anyone got a good name for it?
>
> Cheers
> Phil
>
>
> # This definition sets up a network according to the diagram below which
> # covers a multitude of possible scenarios.
> #
> # Key:
> # hostname
> # [device] (hosts have just a [veth0] unless otherwise noted)
> # (switch)
> #
> # host21 +- host01 host41
> # | | |
> # | host22 +- host02 | host42
> # | | | (sw0) | |
> # | | . . . . . . . . | . . . . . . . . . | |
> # | | . [veth0] . | |
> # +-----+----[vbr0eth2] | [vbr1eth4]----+-----+
> # (sw2) . | | fw | . (sw4)
> # . + [vbr0]--+---[vbr1] + .
> # (sw3) . | | | . (sw5)
> # +-----+----[vbr0eth3] | [vbr1eth5]----+-----+
> # | | . [veth1] . | |
> # | | . . . . . . . . | . . . . . . . . . | |
> # | | | (<direct>) | |
> # | host31 [veth0] | host52
> # | gw |
> # host32 [veth1] [veth2] host51
> # (<direct>) / \ (<direct>)
> # host11 host12
> #
> # A network namespace is created for each host and switch to keep everything
> # isolated. The name of the host or switch is the name used for the namespace
> # making it easy to use "ip netns exec" to specify where commands should run.
> #
> # Examples:
> # Tcpdump traffic passing through a switch
> # sudo ip netns exec sw0 tcpdump -i switch -w capfile
> # Tcpdump traffic seen by a device on a host
> # sudo ip netns exec host12 tcpdump -i veth0 -w capfile
> # Ping "from" host01 (10.0.0.1) to host12 via switch sw0 and hosts fw and gw:
> # sudo ip netns exec host01 ping 192.168.2.12
> # Start netcat on port 23 of host52 to receive telnet:
> # sudo ip netns exec host52 nc -l -p 23
> # telnet "from" host21 (10.0.0.1) to host52 via fw, switches and bridges:
> # sudo ip netns exec host21 telnet 10.45.45.52
> # Panic firehol in fw host namespace (now previous commands are blocked):
> # sudo ip netns exec fw sbin/firehol.in panic
> #
> # Note that there are no virtual machines in use, all processing is done
> # on the host but with separate views of what the network looks like.
> #
>
> host fw
> dev veth0 10.0.0.254/24
> dev veth1 10.1.1.254/24
> dev vbr0eth2
> dev vbr0eth3
> dev vbr1eth4
> dev vbr1eth5
> bridgedev vbr0 vbr0eth2 vbr0eth3 10.23.23.254/24
> bridgedev vbr1 vbr1eth4 vbr1eth5 10.45.45.254/24
> route default via 10.1.1.253
> exec echo 1 > /proc/sys/net/ipv4/ip_forward
>
> host gw
> dev veth0 fw/veth1 10.1.1.253/24
> dev veth1 192.168.1.254/24
> dev veth2 192.168.2.254/24
> route default via 10.1.1.254
> exec echo 1 > /proc/sys/net/ipv4/ip_forward
>
> host host01
> dev veth0 10.0.0.1/24
> route default via 10.0.0.254
>
> host host02
> dev veth0 10.0.0.2/24
> route default via 10.0.0.254
>
> host host11
> dev veth0 gw/veth1 192.168.1.11/24
> route default via 192.168.1.254
>
> host host12
> dev veth0 gw/veth2 192.168.2.12/24
> route default via 192.168.2.254
>
> host host21
> dev veth0 10.23.23.21/24
> route default via 10.23.23.254
>
> host host22
> dev veth0 10.23.23.22/24
> route default via 10.23.23.254
>
> host host31
> dev veth0 10.23.23.31/24
> route default via 10.23.23.254
>
> host host32
> dev veth0 10.23.23.32/24
> route default via 10.23.23.254
>
> host host41
> dev veth0 10.45.45.41/24
> route default via 10.45.45.254
>
> host host42
> dev veth0 10.45.45.42/24
> route default via 10.45.45.254
>
> host host51
> dev veth0 10.45.45.51/24
> route default via 10.45.45.254
>
> host host52
> dev veth0 10.45.45.52/24
> route default via 10.45.45.254
>
> switch sw0
> dev d01 fw/veth0
> dev d02 host01/veth0
> dev d03 host02/veth0
>
> switch sw2
> dev d01 fw/vbr0eth2
> dev d02 host21/veth0
> dev d03 host22/veth0
>
> switch sw3
> dev d01 fw/vbr0eth3
> dev d02 host31/veth0
> dev d03 host32/veth0
>
> switch sw4
> dev d01 fw/vbr1eth4
> dev d02 host41/veth0
> dev d03 host42/veth0
>
> switch sw5
> dev d01 fw/vbr1eth5
> dev d02 host51/veth0
> dev d03 host52/veth0
> _______________________________________________
> Firehol-support mailing list
> Firehol-support at lists.firehol.org
> http://lists.firehol.org/mailman/listinfo/firehol-support
More information about the Firehol-devs
mailing list