Add documentation on OVN BGP agent setup with EVPN #51
Conversation
MatusJenca2
force-pushed
the
mjenca-ovn-bgp-evpn
branch
2 times, most recently
from
3996ebd to
f605f9f
Compare
MatusJenca2
force-pushed
the
mjenca-ovn-bgp-evpn
branch
from
fad2692 to
8cac667
Compare
OgarOgarovic
force-pushed
the
mjenca-ovn-bgp-evpn
branch
from
54612ce to
48b859e
Compare
MatusJenca2
force-pushed
the
mjenca-ovn-bgp-evpn
branch
3 times, most recently
from
03e98d5 to
8cd0a52
Compare
MatusJenca2
force-pushed
the
mjenca-ovn-bgp-evpn
branch
from
3f13667 to
ccca02d
Compare
Signed-off-by: Matus Jenca <[email protected]> Signed-off-by: Ivan Vnučko <[email protected]>
MatusJenca2
force-pushed
the
mjenca-ovn-bgp-evpn
branch
from
ada1e47 to
1839679
Compare
|
LGTM :-) @maxwolfs What do you think is an appropriate place for this document? |
| ``` | ||
| - Get images tag | ||
| ``` | ||
| dokcer image ls |
| The OVN BGP Agent is a component designed to integrate the Open Virtual Network (OVN) with the Border Gateway Protocol (BGP) for routing purposes. OVN is a network virtualization system that provides software-defined networking (SDN) capabilities for virtualized environments, such as OpenStack. BGP, on the other hand, is the protocol used to exchange routing information between different networks (as explained in the previous message). | ||
|
|
||
| ### Advantages of OVN BGP vs pure OVN networking | ||
| - **Direct external network reachability / connectivity** - External access to VMs and connectivity of VMs to external network is simplified because the BGP agent advertises their internal IP addresses without needing NAT, Floating IP or external gateway. By using BGP, which is a standard protocol in networking, the OVN BGP Agent integrates OVN virtual networks seamlessly with existing physical routers and external network infrastructures. This allows OVN environments to be easily connected to external data centers, service provider networks, or the Internet. Without OVN BGP Agent, connecting requires configuring gateway routers or L3 devices to handle the routing between the virtual and physical networks. |
There was a problem hiding this comment.
I think this lacks some realworld use case examples. Assuming we are talking about IPv4, in most use cases the customers want/should use RFC1918 / private addressing between VMs (keep in mind that IPv4 addresses are rare and expensive, we charge ~3 EUR per month for one!). Exposing them externally would not mean external connectivity without introducing NAT somewhere else.
This is of course different for IPv6 - which is not using NAT either way (nor with or without bgp agent)
Also, this seems to cover the L3 mode "afi IPv4/6 unicast", but below we are talking about the L2 "EVPN" mode. When we experimented with the OVN BGP Agent I was mostly interested in the "expose Floating IPs and IPv6 subnets to switches (L3)" part, but EVPN is a totally different use case, which might make a lot of sense for interconnectivity. Maybe I'm missing something here, but for me it's not clear.
| BGP provides intelligent path selection, allowing optimized routing of traffic between the virtual and physical networks. For example, BGP can help choose the shortest or most efficient path for traffic between the data center and external networks, potentially improving performance and reducing latency. | ||
|
|
||
| - **Scalability and multi-tenant environments** - The OVN BGP Agent enables scalable multi-tenant environments. Each tenant's network can be advertised separately via BGP, and policies can be applied based on BGP advertisements. This makes it easier to manage large-scale cloud environments where multiple tenants or customers need isolated but externally reachable networks. No manual configuration of floating IPs and NATs required. | ||
| - **Enhanced security** - BGP routing policies can be used to apply access controls, such as filtering routes or controlling which networks can be advertised and accepted. This allows for more granular control of how traffic flows between the virtualized environment and external networks. Without OVN BGP Agent, security policies would need to be applied manually or through static firewall and NAT configurations, which may not be as flexible or scalable as BGP-based route filtering and access control mechanisms. |
There was a problem hiding this comment.
How are these policies configured? AFAIK the agent just controls routing on a Linux VRF and let's FRR announce it - which would be configured statically.
| where low-latency and highly predictable paths are required, or where MPLS | ||
| infrastructure already exists. | ||
|
|
||
| Geneve tunnels, VLANs or VXLANs can be also used by Neutron as ML2 drivers to |
There was a problem hiding this comment.
Multitenancy is the de facto standard (never came across even a private cloud that doesn't have tenant networks, whether that be VLAN-backed or VXLAN/Geneve). Maybe the "can also be used" is an underestimation ;-)
|
This documentation describes the development status for the SDN encyrption. As you can see, there are currently some Openstack change requests waiting to be integrated into Kolla-Ansible. So that this can be tracked, it makes sense to create a new menu item ‘Technical Previews’ below https://docs.scs.community/docs/category/iaas-layer where this document is then stored. (https://github.com/SovereignCloudStack/docs/tree/main/docs/02-iaas) |
Signed-off-by: Marc Schöchlin <[email protected]>
Signed-off-by: Marc Schöchlin <[email protected]>
Signed-off-by: Marc Schöchlin <[email protected]>
Relates to SovereignCloudStack/issues#614