| opendevreview | Jake Yip proposed openstack/neutron unmaintained/yoga: 'DNM: check upper-constraints redirect' https://review.opendev.org/c/openstack/neutron/+/910866 | 00:10 |
|---|---|---|
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Make mandatory the router name in the LRP.external_ids https://review.opendev.org/c/openstack/neutron/+/910222 | 08:10 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Create an OVN DB transaction context decorator https://review.opendev.org/c/openstack/neutron/+/910538 | 08:12 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] "Logical_Router" pinned to chassis, OVN L3 scheduler https://review.opendev.org/c/openstack/neutron/+/909194 | 08:14 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Provide HA functionality to "Logical_Router" chassis pinning https://review.opendev.org/c/openstack/neutron/+/909437 | 08:14 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Implement OVN agent metadata extension https://review.opendev.org/c/openstack/neutron/+/898238 | 08:25 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] "Logical_Router" pinned to chassis, OVN L3 scheduler https://review.opendev.org/c/openstack/neutron/+/909194 | 08:26 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Provide HA functionality to "Logical_Router" chassis pinning https://review.opendev.org/c/openstack/neutron/+/909437 | 08:27 |
| ralonsoh | slaweq, hello! good morning. I rebased https://review.opendev.org/c/openstack/neutron/+/910222 to allow gerrit to merge this patch. I didn't make any change | 09:01 |
| ralonsoh | if you have 10 secs, thanks! | 09:01 |
| slaweq | ralonsoh done | 09:03 |
| ralonsoh | thanks! | 09:05 |
| noonedeadpunk | hey folks! I need help with OVN BGP agent. Basically in the part of how traffic from br-ex.vlan should get to the physical interface? As I got - physical interface should be removed from OVS br-ex bridge, as then ovn-bgp-agent does create/manage this interface in kernel space | 10:37 |
| noonedeadpunk | but I don't see anything which would connect physical interface with routing tables for br-ext.vlan | 10:38 |
| noonedeadpunk | can somebody help me out a bit to figure out how this type of connectivity intend to work? | 10:39 |
| opendevreview | Merged openstack/neutron stable/2023.2: [stable-only][OVN] Set VETH interface MAC address before up https://review.opendev.org/c/openstack/neutron/+/910714 | 10:39 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Enable "ha" API flag for OVN routers https://review.opendev.org/c/openstack/neutron/+/910889 | 10:41 |
| opendevreview | Merged openstack/neutron stable/2023.1: [stable-only][OVN] Set VETH interface MAC address before up https://review.opendev.org/c/openstack/neutron/+/910715 | 10:42 |
| opendevreview | Merged openstack/neutron stable/zed: [stable-only][OVN] Set VETH interface MAC address before up https://review.opendev.org/c/openstack/neutron/+/910716 | 10:42 |
| ralonsoh | noonedeadpunk, did you open a LP bug? Please talk to ltomasbo (if available) | 10:42 |
| opendevreview | Merged openstack/neutron master: Fix iptables mapping of 'ipip' protocol https://review.opendev.org/c/openstack/neutron/+/909943 | 10:44 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Enable "ha" API flag for OVN routers https://review.opendev.org/c/openstack/neutron/+/910889 | 10:45 |
| noonedeadpunk | no, as I'm not sure it's a bug... | 10:45 |
| noonedeadpunk | Except maybe documentation bug, but I'm not sure yet | 10:46 |
| noonedeadpunk | So intention was to validate that and update docs if applicable | 10:46 |
| noonedeadpunk | And I'm unsure for creating a bug until I'm really sure it's a bug and not intended behaviour that I just don't get... | 10:50 |
| ltomasbo | hello noonedeadpunk | 10:51 |
| noonedeadpunk | \o/ | 10:51 |
| ltomasbo | noonedeadpunk, what driver are you using? bgp one? | 10:51 |
| noonedeadpunk | nb_ovn_bgp_driver and underlay exposure method | 10:52 |
| ltomasbo | noonedeadpunk, kernel networking is used to connect between the physical nic and the br-ex | 10:52 |
| noonedeadpunk | I do see a routing table being created and ovs flows to redirect traffic | 10:52 |
| ltomasbo | noonedeadpunk, great! so, in that case, you should have a rule for the IP (ip rule show) that would redirect the traffic to an specific routing table | 10:52 |
| noonedeadpunk | Yup, and I have them, sec | 10:53 |
| ltomasbo | noonedeadpunk, by default it will be named br-ex, so then you can do "ip route show table br-ex", and you should find there the routes redirecting the traffic through the vlan device br-ex.vlan to br-ex | 10:53 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2023.2: [OVN] Set MTU of the VETH interfaces between OVS and metadata https://review.opendev.org/c/openstack/neutron/+/910717 | 10:53 |
| ltomasbo | noonedeadpunk, it can be a bit old and some things may have changed slightly, but the main blocks are explained here: https://luis5tb.github.io/bgp/2021/02/04/ovn-bgp-agent-in-depth-traffic-flow-inspection.html | 10:54 |
| noonedeadpunk | ltomasbo: br-provider is our name for br-ex: https://paste.openstack.org/show/begAKyX8WSGhquMbRtU9/ | 10:54 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2023.1: [OVN] Set MTU of the VETH interfaces between OVS and metadata https://review.opendev.org/c/openstack/neutron/+/910718 | 10:54 |
| noonedeadpunk | but then what should connect say - br-provide.3102 with bond0.3102? | 10:55 |
| noonedeadpunk | Or it should be using default route or... | 10:55 |
| noonedeadpunk | 203.0.113.54 is a router IP | 10:56 |
| noonedeadpunk | And I get SRC-NAT traffic from VM on br-provide.3102 | 10:56 |
| ltomasbo | noonedeadpunk, ahh, I see. The idea is that you should use ECMP instead of bonding, as you can rely on BGP now | 10:57 |
| noonedeadpunk | And also I do see DST traffic to the router on bond0 (as FRR config is injected properly) | 10:57 |
| ltomasbo | noonedeadpunk, as it relies on kernel routing, it indeed need either a default route or some specific route in the main routing table to send the traffic out | 10:57 |
| noonedeadpunk | ltomasbo: Ok, so basically FRR should be configured to accept incoming routes as well? | 10:57 |
| noonedeadpunk | as example... | 10:58 |
| noonedeadpunk | ok, yes, or a static route in a default table | 10:58 |
| ltomasbo | noonedeadpunk, well... that depends on how you want to deploy. You can enable learning if you want, but for scaling purposes what we assume is that compute nodes will be connected to leaf, and that should be their default routes, so no need for learning routes, but just have a default route to the leaf(s) | 10:58 |
| ltomasbo | noonedeadpunk, we usually use something like this to only learn the default route: https://opendev.org/openstack/ovn-bgp-agent/src/branch/master/etc/frr/frr.conf#L35 | 11:00 |
| noonedeadpunk | oh, actually compute nodes were second question if you may. there's contraversary in docs about compute nodes. Given that VMs having only geneve (east/west), is there still a need for bgp-agent on computes? Or it's ok to have it only on net nodes for FIP/routers? | 11:00 |
| noonedeadpunk | ltomasbo: yeah, I took that example :) | 11:01 |
| noonedeadpunk | s/net nodes/gateway nodes/ | 11:01 |
| ltomasbo | noonedeadpunk, it depends... if you deploy without DVR, there is no need to have ovn-bgp-agent in the computes, as everything would be advertized from the gateway nodes | 11:02 |
| noonedeadpunk | thinking about the scenario where gateway is not on computes and enable_distributed_floating_ip=False | 11:02 |
| ltomasbo | noonedeadpunk, but if you have DVR enabled, then FIPs or IPs on the provider will be directly exposed from the compute nodes | 11:02 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Implement OVN agent metadata extension https://review.opendev.org/c/openstack/neutron/+/898238 | 11:02 |
| ltomasbo | ahh, ok, if that is the case, no, you don't need them on the computes, only in the networkers/gateways | 11:02 |
| noonedeadpunk | ltomasbo: ok, thanks a lot for answers, I guess I have a more clear picture now! I will contribute back to docs then with some small nit I've found | 11:03 |
| noonedeadpunk | ps: there's also another fix to interface trimming I've faced: https://review.opendev.org/c/openstack/ovn-bgp-agent/+/910654 as `br-provider` I'm having is not fitting 15 chars when VLAN is assigned :( | 11:04 |
| ltomasbo | noonedeadpunk, you're welcome! and please do! And keep questions coming! as well as concerns about missing functionality, other needs, etc. It is great to have extra perspectives on this! | 11:04 |
| ltomasbo | noonedeadpunk, ohh, I missed that one! Will review it asap | 11:04 |
| noonedeadpunk | not 100% sure I catched all cases though.... | 11:05 |
| noonedeadpunk | But locally it seems working | 11:05 |
| noonedeadpunk | and yeah, I guess I get to this situation with bonds/bridges as converting working "default" OVN to ovn-bgp-agent setup and trying to find on how make such thing in a least painful manner | 11:07 |
| noonedeadpunk | ltomasbo: sorry, I was thinking about your ECMP advise, but how east-west will be handled then? throught the single interface or separate nic? | 11:51 |
| ltomasbo | noonedeadpunk, umm, that is actually a really good question | 11:57 |
| ltomasbo | noonedeadpunk, it should use the IP from the loopback for the compute, so it can use the same nics | 11:59 |
| noonedeadpunk | and then also be routed, yeah, ok makes sense | 12:01 |
| opendevreview | Merged openstack/ovn-bgp-agent master: Fix OVN LB Delete events for NB driver https://review.opendev.org/c/openstack/ovn-bgp-agent/+/905783 | 12:11 |
| opendevreview | Luis Tomas Bolivar proposed openstack/ovn-bgp-agent stable/2023.2: Fix OVN LB Delete events for NB driver https://review.opendev.org/c/openstack/ovn-bgp-agent/+/910620 | 12:17 |
| noonedeadpunk | oh, actually I think I've faced that ^ but haven't checked what was the reason | 12:18 |
| jlibosva | ralonsoh: hi, doing my bug deputy duty and I see https://bugs.launchpad.net/neutron/+bug/2055561 already has all patches merged. Can I close the LP as done or is there anything else required? | 13:35 |
| ralonsoh | jlibosva, let me check | 13:53 |
| jlibosva | thanks | 13:53 |
| ralonsoh | jlibosva, ah yes, the problem is that launchpad won't change a stable-only status | 13:54 |
| ralonsoh | yes, that should be closed now | 13:54 |
| jlibosva | I thought so but wanted to check first. I'm gonna close it as released | 13:54 |
| jlibosva | thanks ralonsoh ! | 13:54 |
| ralonsoh | sure | 13:54 |
| opendevreview | Merged openstack/ovn-bgp-agent stable/2023.2: Fix OVN LB Delete events for NB driver https://review.opendev.org/c/openstack/ovn-bgp-agent/+/910620 | 13:58 |
| opendevreview | Merged openstack/neutron master: [OVN] Make mandatory the router name in the LRP.external_ids https://review.opendev.org/c/openstack/neutron/+/910222 | 14:23 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [FT] Check "Port_Binding" register exists before checking type https://review.opendev.org/c/openstack/neutron/+/910941 | 14:26 |
| noonedeadpunk | ltomasbo_: sorry it's me again:) looking at routing tables/interfaces, started wondering if there is/was a reason not to spawn frr/agent inside a namespace? then it could be potentially slightly easier not to mess up with routing on hosts and have some kind of isolation... | 15:55 |
| ltomasbo_ | the routes are added on different routing tables | 15:58 |
| ltomasbo_ | it will be a mess to have to plug interfaces across that namespace in and out, no? | 15:59 |
| noonedeadpunk | ok, so I'm thinking of the usecase of the "air-gapped" environemnt, where components of host os ideally should not have access to public networks | 15:59 |
| ltomasbo_ | we are also adding support VRF so that it is isolated in its own vxlan/vni | 15:59 |
| noonedeadpunk | with "native" ovn you give an interface and it's all done in ovs | 15:59 |
| noonedeadpunk | but it's for incoming traffic rather then outgoing? | 15:59 |
| noonedeadpunk | but yeah, I see how limited sense this might have... | 16:00 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Create an OVN DB transaction context decorator https://review.opendev.org/c/openstack/neutron/+/910538 | 16:00 |
| noonedeadpunk | I was more trying to prevent host OS reaching the internet through the default gateway | 16:01 |
| noonedeadpunk | as in current setup "default" gateway is pretty much just mgmt network with access to local mirrors | 16:02 |
| noonedeadpunk | but I guess I do see how against the concept it is | 16:05 |
| ltomasbo_ | noonedeadpunk, yep, for that, probably this is what you need: https://review.opendev.org/c/openstack/ovn-bgp-agent/+/906505 | 16:09 |
| ltomasbo_ | noonedeadpunk, that way, it is not exposing routes in the underlay, but in a given VRF | 16:09 |
| ltomasbo_ | and you can have different gateways for the different VRFs | 16:09 |
| noonedeadpunk | frankly speaking, I guess what I'd need would be ovn expose method, if it was only supporting ipv6 | 16:10 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] "Logical_Router" pinned to chassis, OVN L3 scheduler https://review.opendev.org/c/openstack/neutron/+/909194 | 16:10 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Provide HA functionality to "Logical_Router" chassis pinning https://review.opendev.org/c/openstack/neutron/+/909437 | 16:10 |
| ltomasbo_ | noonedeadpunk, this is more similar to the work I described here: https://luis5tb.github.io/bgp/2021/06/25/openstack-networking-with-evpn.html | 16:10 |
| ltomasbo_ | noonedeadpunk, ohh, it is in the roadmap | 16:11 |
| ltomasbo_ | noonedeadpunk, it should be simple to add actually, I can probably work on that next week and try to complete that part (though it was missing proper BFD support due to an issue with core OVN not enforcing BFD on policies) | 16:12 |
| noonedeadpunk | as that setup really sounds like providing decent isolation and has quite some benefits... | 16:12 |
| ltomasbo_ | noonedeadpunk, indeed, yes! that one is not using kernel networking and allows datapath acceleration | 16:12 |
| noonedeadpunk | huh, well. I'd better test that out instead of checking on namespaces for sure xD | 16:13 |
| noonedeadpunk | Ok, I will try to complete current underlay setup anyway before moving on to ovn jsut to ensure I have at least one option fully working | 16:15 |
| noonedeadpunk | thanks a lot for answering! | 16:15 |
| ltomasbo_ | great! and if later you want to discuss about your use case let me know, it would be nice what could be improved to better support it | 16:16 |
| noonedeadpunk | yeah, sure, I'm though not 100% sure of what specifically we want. I'm not a networking guy per say, but have to combine all pieces together, while having mixed requirements from both sides | 16:17 |
| opendevreview | Brian Haley proposed openstack/neutron stable/2023.2: Fix iptables mapping of 'ipip' protocol https://review.opendev.org/c/openstack/neutron/+/910911 | 16:18 |
| opendevreview | Brian Haley proposed openstack/neutron stable/2023.1: Fix iptables mapping of 'ipip' protocol https://review.opendev.org/c/openstack/neutron/+/910912 | 16:18 |
| noonedeadpunk | but for sure will come back with some explanations/experiences | 16:19 |
| opendevreview | Brian Haley proposed openstack/neutron stable/zed: Fix iptables mapping of 'ipip' protocol https://review.opendev.org/c/openstack/neutron/+/910913 | 16:19 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Exclude files from coverage check, improve overall result https://review.opendev.org/c/openstack/neutron/+/910968 | 16:44 |
| opendevreview | Roberto Acosta proposed openstack/neutron master: [ML2/OVN] Add external_ids key for Static Routes https://review.opendev.org/c/openstack/neutron/+/907489 | 18:05 |
| opendevreview | Roberto Acosta proposed openstack/neutron master: [ML2/OVN] Add external_ids key for SNAT rules https://review.opendev.org/c/openstack/neutron/+/907915 | 21:49 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!