Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Choose the default External Network #119

Closed
maxrome opened this issue Mar 27, 2017 · 8 comments
Closed

Choose the default External Network #119

maxrome opened this issue Mar 27, 2017 · 8 comments
Milestone

Comments

@maxrome
Copy link

maxrome commented Mar 27, 2017

In case the VIM instance has more than one external network, the user should have the manner to choose the external network from where attach the router and then get the floating ips

It could be a parameter of POP json (eg. defaultExternalNetwork) or a parameter at VNF launch time.

@lorenzotomasini
Copy link
Member

Hi @maxrome ,

This is a good point and we would like to integrate this enhancement. However i believe that adding it to the pop is not the right place, or at least, since you are raising the issue, it would be better to make it as much programmable as possible. This means, from my point of view that the vimInstance could contain a default pool name or external net from which picking the fip, but the main place to put this would be the VNFDConnectionPoint, something like:

...
"vnfc":[
      {
          "connection_point":[
             {
                     "virtual_link_reference":"mgmt"
                  },
                  {
                     "floatingIp":"random",
                     "floatingIpSource":"<the_pool_name>",
                     "virtual_link_reference":"net_d"
                  }
               ]
            }
         ]
     }
...

the "floatingIpSource" field name can be different this is just the first name that comes in my mind. but this has priority on vimInstance fip pool name. if both are not specified the current behaviour will be kept

feedbacks are welcome

@lorenzotomasini lorenzotomasini added this to the 4.0.0 milestone Mar 27, 2017
@gc4rella
Copy link
Member

@RuthDVerizon is this something similar to what you guys are trying to achieve?

@maxrome
Copy link
Author

maxrome commented Mar 28, 2017

Hello @lorenzotomasini,
you are right, it must be much programmable as possible. But I think that the VNDF must be agnostic from the VIM, it will be delivered inside the VNF Package, so it should not contain references to VIM resources. Maybe the right place could be the NSD. What do you think about?

Of course a default "floatingIpSource" for VIM instance could be a first step forward

Let me know, bye

@RuthDevlaeminck
Copy link
Collaborator

RuthDevlaeminck commented Mar 28, 2017

@gc4rella

Our company had to solve the problem of assigning floating IP’s when dealing with multiple floating IP pools as well. We approached this problem bearing in mind the following issues regarding networking.

  1. In OpenStack Networking, a floating IP pool is represented as an external network and a floating IP is allocated from a subnet associated with the external network. (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/4/html/Getting_Started_Guide/Defining_a_Floating_IP-Address_Pool.html)
  2. A floating IP from a specific pool (i.e. pool A) can only be associated with VM’s that are connected to internal networks that have a router to that external network (pool A)

We made the following assumptions:

  1. An internal network will only be associated with a single external network via a router.

Given this information it is possible to determine which pool a floating IP should be assigned from without adding any information to the config file. The changes made to support this exist in the openstack4j-plugin repository on branch "issue-9". openbaton/openstack4j-plugin#10 No changes were required for the NFVO code.

Here is an example of how our changes now work.

OpenBatonPoolExample.docx

@maxrome
Copy link
Author

maxrome commented Mar 29, 2017

Hello @RuthDVerizon,
I think your solution works if the private network exists and is attached to a router with an interface toward an external network.
The problem is whenever the private network does not exist.
In this case, the VIM driver creates the network and then creates the router to be attached to the external network. Method getExternalNet() used inside createRouter() returns always the first External Network, so the private network is always attached to the first one. Instead we should be able to select the external network by id or name.

This is the current code:

private Router createRouter(OSClient os, VimInstance vimInstance) throws VimDriverException {`
log.info("Create Router on " + vimInstance.getName());
    return os.networking()
        .router()
        .create(
            Builders.router()
                .name("openbaton-router")
                .adminStateUp(true)
                .externalGateway(getExternalNet(vimInstance).getExtId())
                .build());
  }

  private Network getExternalNet(VimInstance vimInstance) throws VimDriverException {
    for (Network net : listNetworks(vimInstance)) {
      if (net.getExternal()) {
        return net;
      }
    }
    throw new VimDriverException("No External Network found! please add one");
  }

@RuthDevlaeminck
Copy link
Collaborator

Hi @maxrome

Yes, our code does require that the internal network already exist. Our code changes were to ensure that we used the floating IP pools from the external network that was actually connected to the desired network (not a randomly chosen one), not to specify which external network should be used upon creation of a new internal network.

@RuthDevlaeminck
Copy link
Collaborator

RuthDevlaeminck commented May 3, 2017

@maxrome @lorenzotomasini

In looking into this further I believe that the idea of adding this to the VNFDConnection point has much merit. This would allow for different ip pools to be used for different subnets (which would be necessary for us to use this for the work we are doing). My only concern is that if different vnfd.conf files specify different ip pools for the same subnet we could have an issue.

Also this is something we could use in the near future so I would be interested in writing the code for a solution.

@lorenzotomasini
Copy link
Member

I think that this issue is partially closed. the poolName is selectable from the VirtualLinkDescriptor.

However the possibility to choose the external network while creating the router is still not available. i opened #243 referencing this particular issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants