-
Notifications
You must be signed in to change notification settings - Fork 53
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
Comments
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 |
@RuthDVerizon is this something similar to what you guys are trying to achieve? |
Hello @lorenzotomasini, Of course a default "floatingIpSource" for VIM instance could be a first step forward Let me know, bye |
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.
We made the following assumptions:
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. |
Hello @RuthDVerizon, 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");
} |
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. |
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. |
I think that this issue is partially closed. the However the possibility to choose the external network while creating the router is still not available. i opened #243 referencing this particular issue |
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.
The text was updated successfully, but these errors were encountered: