[PVE-User] Problem proxmox 2.0 to forward vmbr1 to eth0, eth1, eth2 VM

[Flavio Stanchina]

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 
(NO-CARRIER).

 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.

-- 
Flavio Stanchina
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