]>
Commit | Line | Data |
---|---|---|
0bcd1f7f DM |
1 | Network Configuration |
2 | --------------------- | |
3 | include::attributes.txt[] | |
4 | ||
5 | {pve} uses a bridged networking model. Each host can have up to 4094 | |
6 | bridges. Bridges are like physical network switches implemented in | |
7 | software. All VMs can share a single bridge, as if | |
8 | virtual network cables from each guest were all plugged into the same | |
9 | switch. But you can also create multiple bridges to separate network | |
10 | domains. | |
11 | ||
12 | For connecting VMs to the outside world, bridges are attached to | |
13 | physical network cards. For further flexibility, you can configure | |
14 | VLANs (IEEE 802.1q) and network bonding, also known as "link | |
15 | aggregation". That way it is possible to build complex and flexible | |
16 | virtual networks. | |
17 | ||
18 | Debian traditionally uses the 'ifup' and 'ifdown' commands to | |
19 | configure the network. The file '/etc/network/interfaces' contains the | |
20 | whole network setup. Please refer to to manual page ('man interfaces') | |
21 | for a complete format description. | |
22 | ||
23 | NOTE: {pve} does not write changes directly to | |
24 | '/etc/network/interfaces'. Instead, we write into a temporary file | |
25 | called '/etc/network/interfaces.new', and commit those changes when | |
26 | you reboot the node. | |
27 | ||
28 | It is worth mentioning that you can directly edit the configuration | |
29 | file. All {pve} tools tries hard to keep such direct user | |
30 | modifications. Using the GUI is still preferable, because it | |
31 | protect you from errors. | |
32 | ||
33 | Naming Conventions | |
34 | ~~~~~~~~~~~~~~~~~~ | |
35 | ||
36 | We currently use the following naming conventions for device names: | |
37 | ||
38 | * Ethernet devices: eth[N], where 0 ≤ N (`eth0`, `eth1`, ...) | |
39 | ||
40 | * Bridge names: vmbr[N], where 0 ≤ N ≤ 4094 (`vmbr0` - `vmbr4094`) | |
41 | ||
42 | * Bonds: bond[N], where 0 ≤ N (`bond0`, `bond1`, ...) | |
43 | ||
44 | * VLANs: Simply add the VLAN number to the device name, | |
45 | separated by a period (`eth0.50`, `bond1.30`) | |
46 | ||
47 | This makes it easier to debug networks problems, because the device | |
48 | names implies the device type. | |
49 | ||
50 | Default Configuration using a Bridge | |
51 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
52 | ||
53 | The installation program creates a single bridge named `vmbr0`, which | |
54 | is connected to the first ethernet card `eth0`. The corresponding | |
55 | configuration in '/etc/network/interfaces' looks like this: | |
56 | ||
57 | ---- | |
58 | auto lo | |
59 | iface lo inet loopback | |
60 | ||
61 | iface eth0 inet manual | |
62 | ||
63 | auto vmbr0 | |
64 | iface vmbr0 inet static | |
65 | address 192.168.10.2 | |
66 | netmask 255.255.255.0 | |
67 | gateway 192.168.10.1 | |
68 | bridge_ports eth0 | |
69 | bridge_stp off | |
70 | bridge_fd 0 | |
71 | ---- | |
72 | ||
73 | Virtual machines behave as if they were directly connected to the | |
74 | physical network. The network, in turn, sees each virtual machine as | |
75 | having its own MAC, even though there is only one network cable | |
76 | connecting all of these VMs to the network. | |
77 | ||
78 | ||
79 | Routed Configuration | |
80 | ~~~~~~~~~~~~~~~~~~~~ | |
81 | ||
82 | Most hosting providers do not support the above setup. For security | |
83 | reasons, they disable networking as soon as they detect multiple MAC | |
84 | addresses on a single interface. | |
85 | ||
86 | TIP: Some providers allows you to register additional MACs on there | |
87 | management interface. This avoids the problem, but is clumsy to | |
88 | configure because you need to register a MAC for each of your VMs. | |
89 | ||
90 | You can avoid the problem by "routing" all traffic via a single | |
91 | interface. This makes sure that all network packets use the same MAC | |
92 | address. | |
93 | ||
94 | A common scenario is that you have a public IP (assume 192.168.10.2 | |
95 | for this example), and an additional IP block for your VMs | |
96 | (10.10.10.1/255.255.255.0). We recommend the following setup for such | |
97 | situations: | |
98 | ||
99 | ---- | |
100 | auto lo | |
101 | iface lo inet loopback | |
102 | ||
103 | auto eth0 | |
104 | iface eth0 inet static | |
105 | address 192.168.10.2 | |
106 | netmask 255.255.255.0 | |
107 | gateway 192.168.10.1 | |
108 | post-up echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp | |
109 | ||
110 | ||
111 | auto vmbr0 | |
112 | iface vmbr0 inet static | |
113 | address 10.10.10.1 | |
114 | netmask 255.255.255.0 | |
115 | bridge_ports none | |
116 | bridge_stp off | |
117 | bridge_fd 0 | |
118 | ---- | |
119 | ||
120 | ||
121 | Masquerading (NAT) with iptables | |
122 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
123 | ||
124 | In some cases you may want to use private IPs behind your Proxmox | |
125 | host's true IP, and masquerade the traffic using NAT: | |
126 | ||
127 | ---- | |
128 | auto lo | |
129 | iface lo inet loopback | |
130 | ||
131 | auto eth0 | |
132 | #real IP adress | |
133 | iface eth0 inet static | |
134 | address 192.168.10.2 | |
135 | netmask 255.255.255.0 | |
136 | gateway 192.168.10.1 | |
137 | ||
138 | auto vmbr0 | |
139 | #private sub network | |
140 | iface vmbr0 inet static | |
141 | address 10.10.10.1 | |
142 | netmask 255.255.255.0 | |
143 | bridge_ports none | |
144 | bridge_stp off | |
145 | bridge_fd 0 | |
146 | ||
147 | post-up echo 1 > /proc/sys/net/ipv4/ip_forward | |
148 | post-up iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o eth0 -j MASQUERADE | |
149 | post-down iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o eth0 -j MASQUERADE | |
150 | ---- | |
151 | ||
152 | //// | |
153 | TODO: explain IPv6 support? | |
154 | TODO: explan OVS | |
155 | //// |