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

[Feature Request] BGP support for OVN EIP, FIP #5010

Open
abasitt opened this issue Feb 18, 2025 · 4 comments
Open

[Feature Request] BGP support for OVN EIP, FIP #5010

abasitt opened this issue Feb 18, 2025 · 4 comments
Labels
feature New network feature subnet vpc

Comments

@abasitt
Copy link

abasitt commented Feb 18, 2025

Description

I want to have advertise OVN EIP, FIP over BGP to TOR but currently this is not supported. It only works in layer 2 with external network. I think layer 2 has limitation e.g.

  • Node failover is slow
  • It uses multiple IP in public network just to have external network setup e.g. 1 IP per LRP for each VPC
  • There is no ECMP from TOR to Network edge nodes.

Can we explore BGP ? I am not sure if there are any current limitation and neither I am expert on OVN, but I am wondering if this is doable?.

Instead of mapping external-network to a physical port or provider-network vlan, it could be map to the interface on host-net that has a proxy-arp enabled? This could be same as today we have an interface on the host for join-network.

  • Allow user to create a multiple subnets for EIP/FIP. This has to be different and not the same to assign IP to LRP.
  • Whenever FIP/EIP is created, CNI add routes in the host-network towards the LRP e.g. LRP can have auto-generated interface name like how its done in calico for veth-pair. Ideally make this linux vrf aware if user wants to enable VRF on the network-edge host. The advantages of most specific routes e.g. /32 or /128 is that EIP/FIP can be shared between different VPC as long it's in same VRF.
  • BGP speaker on the host can then pick those routes and advertise it the TOR. This could be just a summary subnet route.

I hope this make sense or any one else have a better idea ?. I would love to see BGP implementation for this.

Who will benefit from this feature?

The advantages I see of this approach is that.

  • Network nodes can be totally routed. There is no need to extend layer2 to the nodes.
  • Faster fail-over and ECMP
  • VRF awareness on the host and possibility to extend EVPN to the host in future

Anything else?

No response

@abasitt abasitt added the feature New network feature label Feb 18, 2025
@oilbeater
Copy link
Collaborator

oilbeater commented Feb 20, 2025

@abasitt Thanks for the detailed description. Have you looked into this?https://kubeovn.github.io/docs/stable/en/advance/with-bgp/, Kube-OVN already provides BGP capabilities to announce Pod IPs either directly to the L3 network or through EIPs.

@abasitt
Copy link
Author

abasitt commented Feb 21, 2025

@oilbeater thank you for looking into it. Yes I tried that but it only works with nat-gateway. I am looking for a bgp support for OVN EIP,FIP and SNAT https://kubeovn.github.io/docs/stable/en/advance/ovn-eip-fip-snat/

@oilbeater
Copy link
Collaborator

@abasitt, I understand the point now. I believe OVN doesn't natively support BGP for EIP, FIP, and SNAT. This means we might need to introduce a new set of agents or controllers and possibly modify the network flow. This isn't an easy feature, so I would recommend extending the functionality within the NAT gateway. What do you think?

@abasitt
Copy link
Author

abasitt commented Feb 25, 2025

@oilbeater I understand this will be complex. There are few pending proposals for nat-gateway e.g. High availability. The rest kinda become loosely couple when we use nat-gateway and BGP support is already there. I don't have much idea to improve it more but will be happy to report improvements in future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New network feature subnet vpc
Projects
None yet
Development

No branches or pull requests

2 participants