You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OpenStack has a default mechanism called Port Security, that enables the use of Security Groups and prevents VMs from forwarding traffic as an anti-spoofing protection.
However, given NFV scenarios where regular routing is used (no SFC), VNFs may need to forward traffic and even provide its own filtering policies (vFW, for example)
From Openstack, port-security can be disabled manually per port: neutron port-update --port-security-enabled=False [port-UUID]
... but in dynamic/auto-scaling environments, this is not practical.
It can also be disabled globally per network: neutron net-update --port-security-enabled=False [net-UUID]
...but this is not convenient when other VMs that require Security Groups share the same network.
My suggestion is that Open Baton adds support for disabling port-security on a per port basis by specifying this parameter at the CP level.
Apart from the demos I'm working on, I guess this may be a common scenario as other VNFM implementations are allowing this:
OpenStack has a default mechanism called Port Security, that enables the use of Security Groups and prevents VMs from forwarding traffic as an anti-spoofing protection.
However, given NFV scenarios where regular routing is used (no SFC), VNFs may need to forward traffic and even provide its own filtering policies (vFW, for example)
From Openstack, port-security can be disabled manually per port:
neutron port-update --port-security-enabled=False [port-UUID]
... but in dynamic/auto-scaling environments, this is not practical.
It can also be disabled globally per network:
neutron net-update --port-security-enabled=False [net-UUID]
...but this is not convenient when other VMs that require Security Groups share the same network.
My suggestion is that Open Baton adds support for disabling port-security on a per port basis by specifying this parameter at the CP level.
Apart from the demos I'm working on, I guess this may be a common scenario as other VNFM implementations are allowing this:
Thanks,
Gianpietro
The text was updated successfully, but these errors were encountered: