Feature #2545

Decorrelate networks TYPE and IP management

Added by Daniel Dehennin almost 6 years ago. Updated about 5 years ago.

Status:ClosedStart date:12/08/2013
Priority:NormalDue date:
Assignee:Ruben S. Montero% Done:

0%

Category:Documentation
Target version:Release 4.8
Resolution:fixed Pull request:

Description

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.


Related issues

Related to Feature #2858: Extend Network Model Closed 04/29/2014
Related to Feature #3223: Ability to change the IP/gateway/MAC/mask after the templ... Closed 10/03/2014

History

#1 Updated by Boris Parak almost 6 years ago

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.

#2 Updated by Ruben S. Montero over 5 years ago

  • Tracker changed from Request to Feature
  • Category changed from Drivers - Network to Core & System
  • Status changed from Pending to New
  • Target version set to Release 4.6

#3 Updated by Jaime Melis over 5 years ago

  • Target version changed from Release 4.6 to Release 4.8

#4 Updated by Bastien Cadiot over 5 years ago

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.

#5 Updated by Ruben S. Montero over 5 years ago

#6 Updated by Ruben S. Montero over 5 years ago

  • Target version changed from Release 4.8 to Release 4.8 - Beta 1

#7 Updated by Ruben S. Montero over 5 years ago

  • Category changed from Core & System to Documentation

#8 Updated by Ruben S. Montero over 5 years ago

  • Assignee set to Ruben S. Montero

#9 Updated by Javi Fontan over 5 years ago

  • Target version changed from Release 4.8 - Beta 1 to Release 4.8

#10 Updated by Ruben S. Montero about 5 years ago

  • Status changed from New to Closed
  • Resolution set to fixed

#11 Updated by Ruben S. Montero about 5 years ago

  • Related to Feature #3223: Ability to change the IP/gateway/MAC/mask after the template is instantiated added

Also available in: Atom PDF