I have look at ovn documentation and gateway http://openvswitch.org/support/boston2017/1150-ovn-gateways-ipv6.pdf http://blog.spinhirne.com/2016/09/the-ovn-gateway-router.html
they support both central gateway (no failover yet), or distributed gateway (like vxlan-ebgp). I think we could create a new daemon (pvenetworkd ?), running on each node, which manage the snat and nat if the gateway ip is present on the node with some plugins like while(1){ if(gatewayip is present) { if(plugin->bridge) { plugin->bridge->createnat (iptables ....) } if(plugin->ovn) { plugin->ovn->createnat ( ovn-nbctl ....) } } sleep 1; } I don't known how to store ip configuration ? do you want to store them in network config ? (/etc/pve/networks/mynetwork1.cfg for example) or in vm/ct configuration ? (we already have private ip in CT) or maybe both ? (store private ip in CT/VM + NAT public-private in network config ?) we also need ip for dhcp server static configuration with ip-mac, and maybe retrieve ip from dhcp dynamic leases. ----- Mail original ----- De: "Alexandre Derumier" <aderum...@odiso.com> À: "dietmar" <diet...@proxmox.com> Cc: "pve-devel" <pve-devel@pve.proxmox.com> Envoyé: Jeudi 25 Janvier 2018 16:22:10 Objet: Re: [pve-devel] proxmox 2018 : add support for "virtual" network and network plugins ? >>I'll try to look at vrrp implementation on linux (I known keepalived, and >>also [ https://github.com/fredbcode/Vrrpd | >>https://github.com/fredbcode/Vrrpd ] ). >> [ https://github.com/fredbcode/Vrrpd | https://github.com/fredbcode/Vrrpd ] >> ) don't work with bridge interface >>keepalived works great. node1 ----- vrrp_instance VI_TEST_1 { state BACKUP priority 200 nopreempt interface eth0 -> can be the proxmox management ip interface where is send the vrrp packets virtual_router_id 255 advert_int 5 virtual_ipaddress { 10.0.1.0/24 brd 10.1.0.255 dev vmbr1v1 scope global -> 1 gateway ip by network 10.0.2.0/24 brd 10.1.0.255 dev vmbr1v2 scope global } } node2 ----- vrrp_instance VI_TEST_1 { state BACKUP priority 150 nopreempt interface eth0 -> can be the proxmox management ip interface where is send the vrrp packets virtual_router_id 255 advert_int 5 virtual_ipaddress { 10.0.1.0/24 brd 10.1.0.255 dev vmbr1v1 scope global -> 1 ip by network 10.0.2.0/24 brd 10.1.0.255 dev vmbr1v2 scope global } } node3 ----- vrrp_instance VI_TEST_1 { state BACKUP priority 100 nopreempt interface eth0 -> can be the proxmox management ip interface where is send the vrrp packets virtual_router_id 255 advert_int 5 virtual_ipaddress { 10.0.1.0/24 brd 10.1.0.255 dev vmbr1v1 scope global -> 1 ip by network 10.0.2.0/24 brd 10.1.0.255 dev vmbr1v2 scope global } } ----- Mail original ----- De: "Alexandre Derumier" <aderum...@odiso.com> À: "Thomas Lamprecht" <t.lampre...@proxmox.com> Cc: "pve-devel" <pve-devel@pve.proxmox.com> Envoyé: Jeudi 25 Janvier 2018 14:35:28 Objet: Re: [pve-devel] proxmox 2018 : add support for "virtual" network and network plugins ? >>IMO its not to complicated, we would need to add a Resource class, >>which isn't particularly difficult. >>But I also think that Alexandre is right, would be to slow for this. I'll try to look at vrrp implementation on linux (I known keepalived, and also https://github.com/fredbcode/Vrrpd). For Nat rules, I think that pve-firewall daemon could manage them easily. (simply detect if the gateway ip exist on local node, and create the rules). I should be fast. ----- Mail original ----- De: "Thomas Lamprecht" <t.lampre...@proxmox.com> À: "pve-devel" <pve-devel@pve.proxmox.com>, "dietmar" <diet...@proxmox.com>, "Alexandre Derumier" <aderum...@odiso.com> Envoyé: Jeudi 25 Janvier 2018 14:17:37 Objet: Re: [pve-devel] proxmox 2018 : add support for "virtual" network and network plugins ? On 1/25/18 2:04 PM, Dietmar Maurer wrote: >> if user need gateway failover, I don't known if it's better to manage it >> with >> proxmox crm (maybe too slow?) > > I think we should not use/involve the HA stack here (much to complicated). > IMO its not to complicated, we would need to add a Resource class, which isn't particularly difficult. But I also think that Alexandre is right, would be to slow for this. _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel