Giving a VPS a MAC address [message #1896] |
Sat, 04 March 2006 10:39  |
Jason Stubbs
Messages: 18 Registered: March 2006 Location: Japan
|
Junior Member |
|
|
In situations where a VPS needs a unique MAC address this guide can be used to give it one. The method used will be to create a tunneled bridge between the hardware node and the vps.
Note, this method causes further processing overhead so only add one if you need to. Also worth mentioning is that this will bypass all security that is offered by the venet virtual device. Lastly, each VPS needing a MAC address will require a dedicated tap device on the hardware node tied to the bridge.
In this guide, the local network is 192.168.0.0/24, the "internal" network (for communication between the hardware node and the VPS) is 192.168.1.0/24, the hardware node's IP will be 192.168.0.1, the VPS's IP will be 192.168.0.2 and the gateway is 192.168.0.253.
The software needed:
* kernel compiled with bridging and tun/tap support
* vtun (vtun.sf.net)
* bridge-utils (bridge.sf.net)
* usermode-utilities (user-mode-linux.sf.net)
HARDWARE NODE
Create a tap device, bridge it with your ethernet device and set the IPs on the bridge:
# tunctl -t tap0
# ifconfig eth0 0.0.0.0 promisc up
# ifconfig tap0 0.0.0.0 promisc up
# brctl addbr br0
# brctl addif br0 eth0
# brctl addif br0 tap0
# ifconfig br0 192.168.0.1 up
# ifconfig br0:1 192.168.1.1 up
Then set up vtun to run as a server:
# cat /etc/vtund-start.conf
--server-- 5000
# cat /etc/vtund.conf
options {
port 5000;
syslog daemon;
ppp /usr/sbin/pppd;
ifconfig /sbin/ifconfig;
route /sbin/route;
firewall /sbin/ipchains;
ip /sbin/ip;
}
vps101 {
speed 0;
compress no;
encrypt no;
passwd <passwd>;
type ether;
device tap0;
proto udp; # perhaps tcp is faster? haven't tested yet...
}
# /etc/init.d/vtund start
VPS 101
You will need to allow access to tun devices by the VPS and give it an IP on the "internal" network.
# vzctl set 101 --devices c:10:200:rw --save
# vzctl set 101 --ipadd 192.168.1.2 --save
Then just set up and run vtund within the VPS:
# cat /etc/vtund-start.conf
vps101 192.168.1.1
# cat /etc/vtund.conf
options {
port 5000;
timeout 60;
ppp /usr/sbin/pppd;
ifconfig /sbin/ifconfig;
route /sbin/route;
firewall /sbin/ipchains;
ip /sbin/ip;
}
vps101 {
passwd <passwd>;
type ether;
device tap1;
up {
ifconfig "%% 192.168.0.2 netmask 255.255.255.0";
};
down {
ifconfig "%% down";
};
}
# /etc/init.d/vtund start
Finally, you'll need to adjust routing on the VPS to access the gateway directly or else the "internal" address will be used when sending packets outside the local network and the gateway won't know how to send responses back.
# route del default
# route add -net 192.168.1.0/24 dev venet0
# route add default gw 192.168.0.253
And that's it! The tap device within the vps will get a random MAC address and will be visible to any other machines on the same network segment.
[Updated on: Mon, 06 March 2006 10:07] Report message to a moderator
|
|
|
|
|
|
Re: Giving a VPS a MAC address [message #3309 is a reply to message #1900] |
Mon, 22 May 2006 06:38   |
Jason Stubbs
Messages: 18 Registered: March 2006 Location: Japan
|
Junior Member |
|
|
I'm now running this setup in production combined with LVS to give complete failover and load balancing without any idle hardware. 
Now that there's a bit of traffic running over it though, overhead is a little more apparent. On a Xeon 2.4Ghz w/ HT (32bit/512kB cache), both the vtun client and server processes each use 1% CPU per 5MB (megabyte) / sec of bandwidth. That's taken when scp'ing a large file. Assuming packet size of 1460 bytes, that's about 4000 packets/sec. That gives about 200,000 packets/sec to exhaust a CPU. Likely a limit that won't be hit, but it does knock a small whole in the machine's computing power.
On the upside, I was afraid that with several tunnels being tied to the one bridge that all traffic would be sent across all tunnels making the above problem exponential. Luckily, Linux's bridging code seems to be smart enough to keep track of ARP replies and only send traffic where it needs to go.
[Updated on: Mon, 22 May 2006 07:01] Report message to a moderator
|
|
|
|
|
|