Re: [Ebtables-user] Weird stuff with 2.4.23
Brought to you by:
bdschuym
Menu
▾
▴
Re: [Ebtables-user] Weird stuff with 2.4.23
|
From: Robbie D. <ro...@mi...> - 2004-01-14 19:03:00
|
Gavin Hamill wrote: > On Mon, 2004-01-12 at 18:12, Robbie Dinn wrote: > >> Have you though of using UML (User Mode linux). > > > > What an interesting idea :) I'd played with UML briefly in the past, but > had completely forgotten about it... > > My biggest problem was getting the networking going, and I don't feel > confident that I'd be able to hang the relevant 4 virtual machines > together with the appropriate networking to make it work. To fully test, > I need > > client1 -- <LAN> -- server1---IPSEC---- server2 --- <LAN> client2 OK, see below > > To keep this thread on-topic, do you think you could provide a quick > HOWTO for configuring the required tap devices so that each client binds A Howto? I haven't written one myself. Here are a few by other people though http://edeca.net/articles/bridging/index.html http://uml.openconsultancy.com/#network http://www.suse.com/~kraxel/uml/howto.html [see 'network setup (bridge)'] > > to the right place client to the same 'vLAN' as the server on that side? Sorry, I am not familiar with vLAN. Could we assume for simplicity that we have seperate distinct LAN's for the moment? > >> There are only so many boxes you can fit on one desk... > > > > Definately :) > > Cheers, > Gavin. OK, so we have client1 -- <LAN> -- server1---IPSEC---- server2 --- <LAN> client2 Client 1 has one one network interface which it will probably know locally as eth0, lets call it client1/eth0. Server1 has two network interfaces, lets call them server1/eth0 and server1/eth1. But if you are a sysadmin sitting on server 1, you will probably just refer to them as eth0 and eth1. Likewise server2 and client2. client[12] and server[12] can all be UML instances running on a physical host machine. There are two LAN's and the IPSEC thing. Presumably the IPSEC thing is some tunnel over the Internet with routers and so on in between, but for simplicity lets make the two servers part of the same subnet and sitting on a LAN. We will give a number to each of the LAN's. And we show the physical machine as well. Best viewed with a fixed width font. client1/eth0 -- <LAN1> -- eth0/server1/eth1 -- <LAN2> -- eth1/server2/eth0 -- <LAN3> -- eth0/client2 ---------------------------------------- physical machine ------------------------------------------ Now give each network interface on the UML instances a TUNTAP interface on the physical machine. client1/eth0 -- <LAN1> -- eth0/server1/eth1 -- <LAN2> -- eth1/server2/eth0 -- <LAN3> -- eth0/client2 tap1 tap2 tap3 tap4 tap5 tap6 ---------------------------------------- physical machine ------------------------------------------ Now join the tap interfaces on the physical machince the LAN's. Each LAN corresponds to a bridge on the host physical machine. client1/eth0 -- <LAN1> -- eth0/server1/eth1 -- <LAN2> -- eth1/server2/eth0 -- <LAN3> -- eth0/client2 tap1 tap2 tap3 tap4 tap5 tap6 -------- br0 --------- -------- br1 --------- -------- br2 --------- ---------------------------------------- physical machine ------------------------------------------ Note, packets from client1/eth0 to server1/eth0 will be bridged via br0 but a packet from from say client1/eth0 to server2/eth0 is bridged via br0 then routed through virtual machine server1, then bridged via br1. Lets specify some IP addresses and MAC addresses to be used by the UML virtual machines by means of a table. uml interface IP addr MAC addr host interface host bridge client1/eth0 192.168.1.1 FE:FF:C0:A8:1:1 tap1 br0 server1/eth0 192.168.1.2 FE:FF:CO:A8:1:2 tap2 br0 server1/eth1 192.168.2.1 FE:FF:CO:A8:2:1 tap3 br1 server2/eth1 192.168.2.2 FE:FF:CO:A8:2:2 tap4 br1 server2/eth0 192.168.3.2 FE:FF:CO:A8:3:1 tap5 br2 client2/eth0 192.168.3.1 FE:FF:C0:A8:3:1 tap6 br2 Note that IP address and MAC address are associated with the interfaces in the UML virtual machines, not with the tuntap devices which are part of the physical machine. I am asumming that all the UML instances are running under a single ordinary user account. To allow this, we need to relax the permissions on /dev/net/tun so that ordinary user can manipulate tuntap devices. # chown 666 /dev/net/tun # ls -l /dev/net/tun crw------- 1 root root 10, 200 2003-09-23 18:59 /dev/net/tun # create the tap devices and bridges, then enslave the tap devices under the bridges. I am assuming that all the UML instances are # for i in 1 2 3 4 5 6 ; do > tunctl -u robbie -t tap${i} > ip link set dev tap${i} up > done Set 'tap1' persistent and owned by uid 500 Set 'tap2' persistent and owned by uid 500 Set 'tap3' persistent and owned by uid 500 Set 'tap4' persistent and owned by uid 500 Set 'tap5' persistent and owned by uid 500 Set 'tap6' persistent and owned by uid 500 # brctl addbr br0 # brctl stp br0 off # brctl sethello br0 1 # brctl addif br0 tap1 # brctl addif br0 tap2 # brctl addbr br1 # brctl stp br1 off # brctl sethello br1 1 # brctl addif br1 tap3 # brctl addif br1 tap4 # brctl addbr br2 # brctl stp br2 off # brctl sethello br2 1 # brctl addif br2 tap5 # brctl addif br2 tap6 # ip link set dev br0 up # ip link set dev br1 up # ip link set dev br2 up Then you should be ready to fire up the UML instances. I would start them something like this: $ /path/to/uml-linux ubda=/path/to/client1/root_fs \ eth0=tuntap,tap1,FE:FF:C0:A8:1:1,192.168.1.1 \ <other arguments> $ /path/to/uml-linux ubda=ubda=/path/to/server1/root_fs \ eth0=tuntap,tap2,FE:FF:C0:A8:1:2,192.168.1.2 \ eth1=tuntap,tap3,FE:FF:C0:A8:2:1,192.168.2.1 \ <other arguments> $ Likewise for server2 and client2, substituting the correct arguments. One last thing, my guess is that you want to build a UML kernel with the ebtables patch applied and and add the ebtables rules on the UML server1 and server2 machines. Probably no need to have ebtables rules on the physical machine. If you do want ebtables rules on the physical machine after all, you will need sort the packets into seperate chains for each bridge. I hope all that wasn't too off-topic. |