OpenNebula

I would like to second this request. We also have use cases where ONE-level L3 management causes problems. However, it would be nice to have L2 management handled by ONE.

Cheers, Boris

Daniel Dehennin wrote:

Hello,

I defined some networks with ranged leases but I do not use ONE contextualization to manage them.

Switching to 4.4 break my setup due to #2318 and I have to comment the call to mac_spoofing source:src/vnm_mad/remotes/ovswitch/OpenvSwitch.rb?rev=release-4.4#L52

I think the networks management could be improved by decorrelating the network TYPE to leases management.

The TYPE could be:

• define a simple L2 network (VMs could pass VLAN on it)
• define a VLAN network (like simple L2 but ONE manage VLAN tags)

On top of that network TYPE, we could:

• do nothing and let VMs manage the L3 protocol, typically with a DHCP server
• manage leases per L3 protocol

Then, we could define a network as:

• name: raw_network
  • type: L2
  • bridge: br0
  • L3: unmanaged
• name: playground
  • type: VLAN
  • bridge ovsbr0
  • VLAN_ID: 10
  • L3: unmanaged
• name: secured_net
  • type: VLAN
  • bridge ovsbr0
  • VLAN_ID: 30
  • L3: managed
    • IPv4: ranged 10.0.1.0/24
    • IPv6: ranged <PREFIX>/64

Regards.

This feature would be very useful.
If IP are managed by a central configuration tool like puppet or chef, in addition to mac_spoofing problem, this create a confusion in user mind because the ip displayed isn't the one allocated.
The only way to avoid this is to hide IP informations in sunstone views. But an option to correctly split L2 and L3 would be better.