OpenStack with ml2/OVN - Part 1

Поділитися
Вставка
  • Опубліковано 28 чер 2024
  • In this video, we're looking at OVN to understand how Neutron objects map to OVN objects. How we can use OVS and OVN tools to troubleshoot connectivity issues.
    The blog post we're using:
    lewisdenny.io/how_to_trace_pa...
    What is OVN?
    canonical.com/blog/data-centr...
    docs.openstack.org/neutron/la...
    0:00 Intro
    3:10 OVS-DB
    4:38 OpenFlow and OVS
    5:44 LogicFlows and OVN
    6:20 DHCP entries
    7:30 Neutron objects
    9:05 Neutron Router
    9:50 OVN Objects Northbound DB
    10:40 NAT and FIPS
    14:00 OVN LoadBalancers
    14:14 Southbound DB
    15:17 Block traffic
    18:58 Failing ping
    19:20 tcpdump
    20:00 Gateway Chassis and DVR
    24:45 Openflow rules
    27:55 FIP ARP
    28:57 More openflow
    32:30 ovs-appctl ofproto/trace
    43:10 Allow ICMP and recheck the trace
    45:15 Overview part1
  • Наука та технологія

КОМЕНТАРІ • 8

  • @zap8014
    @zap8014 2 місяці тому +1

    Amazing explanation, thanks!

  • @LampJustin
    @LampJustin 2 роки тому +1

    Wow thank you very much! This is an amazing primer for ovn and debugging it. At work we're evaluating the switch from midonet to it and the series comes at the perfect time for me! I especially liked the ovs tracing as that's what I had the most trouble with. The official documentation is unfortunately a bit lacking right now imho. I hope to help with the docs when I get more experience with it... The only problem we're facing with ovn right now is that it doesn't integrate well with our L3-only infrastructure. Do you know of any solutions for that?
    I'm not searching for free consulting but I just didn't find anything on the net really. Only some "tests" and a repo on opendev that doesn't seem active. I even tried that but it was buggy and unfortunately the failover took like 90 seconds with longer than expected downtime. Thank you for all your hard work, really appreciate it!! :)

    • @LampJustin
      @LampJustin 2 роки тому

      Oh and yes the raft based consensus for the DBs work great ;) and so does running multiple northd instances! It's fantastic 😄

    • @triplewho1448
      @triplewho1448  2 роки тому +2

      Hey, thanks so much for the feedback.
      It can indeed be difficult to find information, there are a few good blogs that might help you as well in addition to the one I named in the description:
      Numan has some great information:
      numans.blog/
      As does Daniel Alvarez:
      dani.foroselectronica.es/
      And some more good info here:
      blog.russellbryant.net/category/ovs/ovn/
      When you say your l3-only networks. Are you referring to just provider networks? So each VM will be attached directly to your provider network without any OpenStack tenant networks or floating IP's invovled. Then you have something like Keepalived that should keep an IP address active between the two hosts if one were to go down?
      Does that describe the scenario you're referring to? I'm happy to try reproducing the scenario and see if I can find some more information for you.

    • @LampJustin
      @LampJustin 2 роки тому

      @@triplewho1448 Awesome thank you! I really admire your work!
      With the L3 architecture I mean that everything is talking BGP in our datacenter. From the HVs to the Cumulus Switches. The only L2 domains are between the switch and the physical machines. All of them announce their ips over BGP. I'm not referring to running machines in provider networks. Midonet for example announces the router and floating ips over BGP as well. Provider networks on ovn on the other hand only work in Layer 2 domains arping their mac IP bindings. What I'm asking is whether ovn can integrate with frr for example to announce the IPs over BGP. This would be great for large scale deployments. Thanks again :)

    • @triplewho1448
      @triplewho1448  2 роки тому

      ​@@LampJustin Ah ok, yeah the BGP thing is still a work in progress. I had a quick look into that and answered a similar question on the Reddit thread as well. But it seems like some of the BGP integration work might be stalled at this point. I assume the repo you were referring to is this one: opendev.org/x/ovn-bgp-agent But yeah, as you noticed, this is only for the VM's using FIPs. There is currently no solution for BGP advertisements from the OVN routers for the OpenStack tenant networks.
      I'll paste in my comment from the Reddit thread so that the full context is here as well:
      www.reddit.com/r/openstack/comments/v7mmob/openstack_networking_with_ovn/ibln9g7/?context=3
      There is a BGP Agent for OVN:
      ltomasbo.wordpress.com/2021/02/04/openstack-networking-with-bgp/
      ltomasbo.wordpress.com/2021/02/04/ovn-bgp-agent-in-depth-traffic-flow-inspection/
      And the repo:
      opendev.org/x/ovn-bgp-agent
      But this doesn't advertise OpenStack tenant networks via BGP. It's just for Floating IP addresses.
      There's also a current Spec to implement direct BGP peering from Neutron routers:
      specs.openstack.org/openstack/neutron-specs/specs/xena/bgpaas-enhancements.html
      But it looks like that work might not have been prioritised according to the latest PTG meeting notes:
      etherpad.opendev.org/p/neutron-zed-ptg#L116
      With a revert for some of the patches currently proposed:
      review.opendev.org/c/openstack/neutron-lib/+/843649
      And VPN is currently in the works as well:
      specs.openstack.org/openstack/neutron-specs/specs/xena/vpnaas-ovn.html
      review.opendev.org/c/openstack/neutron-vpnaas/+/765353
      I'll see if I can chase up any additional info about the BGP stuff as well and let you know.

    • @LampJustin
      @LampJustin 2 роки тому

      @@triplewho1448 Wow thank you so much for gathering the info. I already tried to use the Vpnaas ovn plugin and can tell you that it works pretty well! I haven't tried it with too many VPNs but a couple worked great!
      I really hope that BGP announcements for the router and fips will be a thing eventually. That would make the switch a lot less hard for us, but I guess we could get away with BGP EVPN for the public network in the meantime. Thank you!