search

eiginn / coreemu

Automatically exported from code.google.com/p/coreemu
BSD 2-Clause "Simplified" License
0 stars 1 forks source link

controlnet session option doesn't work across distributed session #202

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. create a scenario using two servers (local and remote)
2. enable the controlnet option under session > options
3. only the local machine gets the control network

Here is a workaround:

On the remote machine, set the controlnet=172.16.0.0/24 in the 
/etc/core/core.conf file and restart the daemon.

Start the scenario as before. Now both the local and remote servers will have a 
control net bridge "b.ctrlnet.nnnnn" (where nnnnn is derived from the session 
number) having the address 172.16.0.254.

First delete the address 172.16.0.254 from the remote controlnet so it doesn't 
conflict:
  sudo ip addr del 172.16.0.254/24 dev b.ctrlnet.37440

Now connect the controlnet on the two machines using a GRE tunnel:
# in this example 10.20.0.1 is local, 10.20.0.2 is the remote
# local server
sudo ip link add gt0 type gretap remote 10.20.0.2 key 50
sudo ip link set gt0 up
brctl addif b.ctrlnet.37625 gt0

# remote server
sudo ip link add gt0 type gretap remote 10.20.0.1 key 50
sudo ip link set gt0 up
brctl addif b.ctrlnet.37440 gt0

Now the local machine can access vnodes on the remote machine use their 
172.16.0.x IP address.

Original issue reported on code.google.com by ahrenh...@gmail.com on 13 May 2013 at 2:44

GoogleCodeExporter commented 9 years ago 
config message that sets the session options should be forwarded to slave 
server; don't add the 172.16.0.254 address if session.master=false

>CONF(flags=0x0,mod=session,types=<10 10 10 10 
>,values=<controlnet=172.16.0.0/24 enablerj45=1 enablesdt=0 preservedir=0>) 
reply

Original comment by ahrenh...@gmail.com on 12 Aug 2013 at 6:20

GoogleCodeExporter commented 9 years ago 
fixed in in r418

For a distributed session, there are two implemented behaviors:
1. One controlnet prefix. Each server will have a controlnet bridge and they 
will all be linked to the master server's bridge via GRE tunnels. The master 
bridge gets the last address in the controlnet (e.g. 172.16.255.254 for 
172.16.0.0/16).
2. Multiple controlnet prefixes. Each server will have a controlnet bridge and 
a separate prefix is assigned to each server. Assignments start with the first 
prefix belonging to the master server, then to each slave server sorted 
alphabetically by server name. The tunnels are still built, but additional 
routing rules would be required to route traffic between each prefix. This mode 
is required for e.g. DLEP R2RI support.

Original comment by ahrenh...@gmail.com on 29 Aug 2013 at 6:01