[PVE-User] Problem proxmox 2.0 to forward vmbr1 to eth0, eth1, eth2 VM
flavio.stanchina at ies.it
Mon Mar 26 14:09:56 CEST 2012
maykel at maykel.sytes.net wrote:
> El 2012-03-26 11:34, Flavio Stanchina escribió:
>> Your network configuration doesn't make sense. You have three network
>> cards on the same subnet and you say the cable is not connected on vmbr2
>> and vmbr3, [...]
>> I suggest to test a similar network configuration on two physical
>> machines before trying it in a virtualized environment with the
>> additional complexities of bridging and virtual networks.
> Hi Flavio, thanks for your response.
> The idea was to connect:
> vmbr0 --> LAN
> vmbr1 --> LAN
> vmbr2 --> WAN
> vmbr3 --> WAN
So you're saying that vmbr2 and vmbr3 are NOT on the same network as
vmbr1. Why, then, did you give them an IP address on the same subnet as
vmbr1? Why did you give them an IP address at all?
> But even with the same range of ips in vmbr1, vmbr2 andvmbr3, if there is a cable not connected vmbr3 vmbr2 and should not answer to ping. Do not you think?
To tell the truth, I'm not sure I understand exactly why the Linux
network stack behaves in this way, but it does. As I said in my previous
email, you should definitely do some tests on physical hardware before
blaming Proxmox VE for odd behavior.
For the record, I just tried this on a server I have lying around:
# ip addr
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UNKNOWN qlen 100
link/ether 00:04:75:d7:61:85 brd ff:ff:ff:ff:ff:ff
inet 10.1.3.70/24 brd 10.1.3.255 scope global eth0
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
state DOWN qlen 1000
link/ether 00:4f:4e:11:e0:65 brd ff:ff:ff:ff:ff:ff
inet 10.1.3.254/24 brd 10.1.3.255 scope global eth1
As you can see, eth0 has address 10.1.3.70 and the cable is connected,
while eth1 has address 10.1.3.254 but the cable is disconnected
From a Windows client:
>ping -n 1 10.1.3.70
Reply from 10.1.3.70: bytes=32 time<1ms TTL=64
>ping -n 1 10.1.3.254
Reply from 10.1.3.254: bytes=32 time<1ms TTL=64
>arp -a | grep 00-04-75-d7-61-85
10.1.3.70 00-04-75-d7-61-85 dynamic
10.1.3.254 00-04-75-d7-61-85 dynamic
As you can see, the server answers pings to both addresses, obviously
from the same physical interface (eth0 in this case). As I said above, I
don't understand exactly *why* it answers for the second address but, as
I have no doubt that the Linux networking guys know their way around
TCP/IP, I'm going to assume it's been designed to do so and it's not a bug.
Informatica e Servizi
Trento - Italy
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
-- Brian W. Kernighan
More information about the pve-user