| opendevreview | ZhouHeng proposed openstack/neutron master: Improve ACL comparison efficiency https://review.opendev.org/c/openstack/neutron/+/885449 | 00:28 |
|---|---|---|
| opendevreview | Miguel Lavalle proposed openstack/neutron master: Fix trunk test_subport_delete functional test https://review.opendev.org/c/openstack/neutron/+/921296 | 00:47 |
| opendevreview | Ihar Hrachyshka proposed openstack/neutron-lib master: DNM: mypy improvements https://review.opendev.org/c/openstack/neutron-lib/+/921483 | 01:08 |
| opendevreview | Ihar Hrachyshka proposed openstack/neutron-lib master: DNM: mypy improvements https://review.opendev.org/c/openstack/neutron-lib/+/921483 | 01:13 |
| opendevreview | Ihar Hrachyshka proposed openstack/neutron-lib master: DNM: mypy improvements https://review.opendev.org/c/openstack/neutron-lib/+/921483 | 01:17 |
| opendevreview | Ihar Hrachyshka proposed openstack/neutron-lib master: DNM: mypy improvements https://review.opendev.org/c/openstack/neutron-lib/+/921483 | 01:18 |
| opendevreview | Ihar Hrachyshka proposed openstack/neutron-lib master: mypy: enable checks for all __init__.py files https://review.opendev.org/c/openstack/neutron-lib/+/921484 | 01:36 |
| opendevreview | Ihar Hrachyshka proposed openstack/neutron-lib master: DNM: mypy improvements https://review.opendev.org/c/openstack/neutron-lib/+/921483 | 01:49 |
| opendevreview | Ihar Hrachyshka proposed openstack/neutron-lib master: mypy: add type hints to fake_notifier module https://review.opendev.org/c/openstack/neutron-lib/+/921485 | 02:11 |
| opendevreview | Luis Tomas Bolivar proposed openstack/ovn-bgp-agent master: Ensure cr-lrp permanent ip nei entry is added on NB DB driver https://review.opendev.org/c/openstack/ovn-bgp-agent/+/921491 | 07:34 |
| opendevreview | Merged openstack/neutron stable/2024.1: [stable only] Fix KeyError in set_gateway_mtu https://review.opendev.org/c/openstack/neutron/+/921437 | 08:27 |
| opendevreview | Lajos Katona proposed openstack/neutron-tempest-plugin master: Tap Mirror API and scenario tests https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/886004 | 08:51 |
| opendevreview | yatin proposed openstack/neutron-lib master: Add neutron unit test job in check queue https://review.opendev.org/c/openstack/neutron-lib/+/921422 | 08:56 |
| opendevreview | Merged openstack/neutron stable/2023.2: [stable only] Fix KeyError in set_gateway_mtu https://review.opendev.org/c/openstack/neutron/+/921438 | 09:26 |
| seba | I'm looking at the extraroutes extension for routers and it looks like I can create routes with an ipv6 subnet that have a ipv4 nexthop, so it's an address family mismatch. Is that a valid construct in vanilla OpenStack? I know linux has some foreign addressy family next hop stuff implemented in the last years, but somehow I'd expect this to not be an acceptable extraroute | 10:54 |
| *** haleyb is now known as haleyb|out | 11:30 | |
| vicent | Hi, I was asking on the general chat, but maybe it is better here. I am wondering, it is possible to use geneve tenant networks with multiple physnets, so with tunnel endpoint on different NICs? | 12:14 |
| opendevreview | Merged openstack/neutron stable/2023.1: [stable only] Fix KeyError in set_gateway_mtu https://review.opendev.org/c/openstack/neutron/+/921440 | 12:22 |
| opendevreview | Lajos Katona proposed openstack/networking-sfc master: Handle missing vlan for egress flow setup https://review.opendev.org/c/openstack/networking-sfc/+/921514 | 12:26 |
| opendevreview | Jay Jahns proposed openstack/ovn-bgp-agent master: Announce lrp ip if advertisement method is subnet https://review.opendev.org/c/openstack/ovn-bgp-agent/+/921516 | 12:41 |
| opendevreview | Jay Jahns proposed openstack/ovn-bgp-agent master: Announce lrp ip if advertisement method is subnet https://review.opendev.org/c/openstack/ovn-bgp-agent/+/921516 | 12:42 |
| opendevreview | yatin proposed openstack/neutron unmaintained/yoga: [yoga only] Drop 8-stream jobs https://review.opendev.org/c/openstack/neutron/+/921517 | 12:42 |
| farbod | Hi | 13:22 |
| farbod | I have a question about Nuetron overlay networks. | 13:22 |
| farbod | I deep dived a bit inside Neutron and OVS and the question that came to my mind is that when a VNI on an overlay network comes to the br-tun inside the server, who is responsible for handling this VxLan frame? | 13:22 |
| farbod | I mean at the end the br-tun forwards it to the br-int but why there is multiple VxLan ports in br-tun. | 13:22 |
| farbod | I also wonder how we are not getting limited by mapping each VNI to local VLAN IDs on the server for isolating the networks? | 13:22 |
| farbod | I mean as I understood each VNI tag translates to a corresponding VLAN ID. | 13:22 |
| farbod | Also what about the MAC addresses in the flow table of the br-tun? What are they used for? | 13:22 |
| opendevreview | Elod Illes proposed openstack/neutron-fwaas stable/2023.2: Remove devstack-gate requirement https://review.opendev.org/c/openstack/neutron-fwaas/+/921524 | 13:38 |
| opendevreview | Elod Illes proposed openstack/neutron-fwaas stable/2023.1: Remove devstack-gate requirement https://review.opendev.org/c/openstack/neutron-fwaas/+/921525 | 13:39 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Add policy for create_agent api call https://review.opendev.org/c/openstack/neutron/+/921526 | 13:40 |
| opendevreview | Elod Illes proposed openstack/neutron-fwaas unmaintained/zed: Remove devstack-gate requirement https://review.opendev.org/c/openstack/neutron-fwaas/+/921527 | 13:41 |
| farbod | Any info? | 13:44 |
| racosta | Hi farbod. Just an advice, avoid using vxlan in your deployment with openvswitch because there is a limitation related to the representation of the VNI! more specifically, in the mapping of the datapaths for each flow created. I mean, in a OVN deplyment, if you use vxlan you will limit the number of ports mapped in the datapath_bindings of the southbound database (I imagine it's similar for the OVS plugin). Use generic | 13:45 |
| racosta | encapsulation (Geneve) in your configuration and map the vlans of your provider network to the physical interface associated with the ovs bridge mappings in the neutron config file - `bridge_mappings = provider:br-provider`. | 13:45 |
| farbod | So you mean br-int in OVS can't handle more than VLAN ID limit range tunnel networks? | 13:47 |
| racosta | No, the problem is not with the br-int interface. The question is the flows mapped to the datapath! each datapath flow receives a tunnel_key and the behavior changes when you use vxlan or geneve. | 13:50 |
| farbod | What do you mean by datapath? | 13:51 |
| racosta | The flow that is created in each network element running openvswitch, to redirect traffic from a VM port to a gateway chassis, for example. So, basically, you need a VM port to be connected to a logical router (which can reside on a remote chassis with a network gateway role), and this flow between chassis needs to be tunneled and identified with the tunnel_key / datapath. | 13:57 |
| racosta | So, you don't need VXLAN encapsulation to tunnel communication between chassis in your cloud (that's why I suggested using Geneve). And regarding the external interface/provider, you just need to map the VLANs in the neutron config and have the physical interface created on a network node. https://docs.openstack.org/neutron/latest/admin/deploy-ovs-provider.html | 14:05 |
| farbod | Does internal connection between br-int and br-tun happens with VLAN IDs or VxLan VNI tunnels? | 14:33 |
| farbod | For example in this picture in the doc https://docs.openstack.org/neutron/latest/admin/deploy-ovs-selfservice.html in self service network in the network node it shows that connection between br-int and br-provider is with VLAN tunnel and connection between br-int and br-tun is with internal tunnel. Is it right? | 14:36 |
| farbod | I mean when I use ovs-ofctl dump-flows br-tun I see that it maps each tunnel ID to a VLAN. | 14:36 |
| opendevreview | Brian Haley proposed openstack/neutron master: Bump neutron-lib to 3.13.0 https://review.opendev.org/c/openstack/neutron/+/921533 | 14:39 |
| vicent | I keep getting this with my OVN neutron: Invalid input for operation: provider:physical_network specified for geneve network. | 15:02 |
| vicent | Is it possible to configure provider networks with geneve segmentation? | 15:02 |
| vicent | It should be possible according to https://docs.openstack.org/neutron/latest/feature_classification/provider_network_support_matrix.html#operation_Geneve_driver_ovn | 15:04 |
| farbod | Can anybody guide me? | 15:15 |
| vicent | Hi racosta, isn't the link you send for ovs? but you were talking about OVN deployment. | 15:31 |
| vicent | farbod, if I understand it correctly, if you check the flows on br-tun, you will get vxlan encapsulated as part of the actions | 15:32 |
| lajoskatona | farbod: Hi, for OVS based deployment there is VLAN between br-int and br-tun and there Neutron pushes the packets to the tunnel | 15:33 |
| lajoskatona | vicent, farbod: vicent is right from br-tun to br-int there should be a mapping to vlan ids, but the other direction you have to tunnel | 15:35 |
| vicent | I am just trying to find the configuration for provider networks using geneve segmentation for OVN. I can only find for flat and vlan segmentations. Any idea where to get that? | 15:36 |
| racosta | https://docs.openstack.org/neutron/latest/install/ovn/manual_install.html | 15:42 |
| farbod | I get it. So what if the number of tenant networks be more than 4096 on a single host? How it will map the VNIs to the VLANs between br-int and br-tun? | 15:52 |
| vicent | racosta, thanks, but that only includes vlan segmentation for provider networks | 16:06 |
| vicent | Or can I set a flat network and then a different provider:physical_network for the tenant networks to go to different interfaces? | 16:10 |
| opendevreview | Merged openstack/neutron unmaintained/zed: [stable only] Fix KeyError in set_gateway_mtu https://review.opendev.org/c/openstack/neutron/+/921441 | 16:36 |
| -opendevstatus- NOTICE: Gerrit will be restarted at around 17:45 UTC to pick up some small image updates | 16:45 | |
| farbod | Is there a limit for it? | 17:25 |
| opendevreview | Merged openstack/neutron unmaintained/yoga: [yoga only] Drop 8-stream jobs https://review.opendev.org/c/openstack/neutron/+/921517 | 17:32 |
| opendevreview | Miro Tomaska proposed openstack/neutron master: Revert "Use HasStandardAttributes as parent class for Tags DB model" https://review.opendev.org/c/openstack/neutron/+/921566 | 19:14 |
| farbod | Why like LinuxBridge OVS doesn't use a bridge for each network and uses only one br-int for all the traffic and limits it with VLAN IDs? | 19:26 |
| opendevreview | Miro Tomaska proposed openstack/neutron stable/2024.1: Revert "Use HasStandardAttributes as parent class for Tags DB model" https://review.opendev.org/c/openstack/neutron/+/921567 | 19:27 |
| opendevreview | Miro Tomaska proposed openstack/neutron stable/2023.2: Revert "Use HasStandardAttributes as parent class for Tags DB model" https://review.opendev.org/c/openstack/neutron/+/921568 | 19:28 |
| opendevreview | Miro Tomaska proposed openstack/neutron stable/2023.1: Revert "Use HasStandardAttributes as parent class for Tags DB model" https://review.opendev.org/c/openstack/neutron/+/921569 | 19:31 |
| opendevreview | Miro Tomaska proposed openstack/neutron stable/zed: Revert "Use HasStandardAttributes as parent class for Tags DB model" https://review.opendev.org/c/openstack/neutron/+/921570 | 19:33 |
| opendevreview | Miro Tomaska proposed openstack/neutron stable/yoga: Revert "Use HasStandardAttributes as parent class for Tags DB model" https://review.opendev.org/c/openstack/neutron/+/921571 | 19:34 |
| opendevreview | Miro Tomaska proposed openstack/neutron stable/wallaby: Revert "Use HasStandardAttributes as parent class for Tags DB model" https://review.opendev.org/c/openstack/neutron/+/921572 | 19:35 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!