Re: Testing and emulation with network namespaces

"Tsaousis, Costa" <[email protected]>
Newsgroups gmane.comp.security.firewalls.firehol.user,gmane.comp.security.firewalls.firehol.devel
Message-ID <CANL+VpYd3dHggeu-CgSMX+myDNp-BhAGR+T+T5WfoTEZFkSXQA@mail.gmail.com>
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 <[email protected]> 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
> [email protected]
> http://lists.firehol.org/mailman/listinfo/firehol-support
_______________________________________________
Firehol-support mailing list
[email protected]
http://lists.firehol.org/mailman/listinfo/firehol-support
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.