neutron

OVN DHCP replies source from subnet gateway IP

Bug #2007167 reported by James Denton
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
New
Undecided
Unassigned

Bug Description

Recently switched from using DHCP Agent to built-in OVN DHCP for baremetal deployments.

Version: Zed
OS: 22.04 LTS
OVS: 3.0.1
OVN: 22.09

When a baremetal node is provisioned, during PXE I am getting a lease from an OVN controller but nothing further (ie. no TFTP). Here is the DHCP request and reply:

root@lab-infra02:~# tcpdump -i ens192 -ne port 67 or port 68
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens192, link-type EN10MB (Ethernet), snapshot length 262144 bytes
16:16:23.767513 14:02:ec:32:3e:0c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 405: vlan 6, p 0, ethertype IPv4 (0x0800), 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 14:02:ec:32:3e:0c, length 359
16:16:23.768943 fa:16:3e:1f:ab:d3 > 14:02:ec:32:3e:0c, ethertype 802.1Q (0x8100), length 398: vlan 6, p 0, ethertype IPv4 (0x0800), 192.168.208.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 352

I've noticed two things:

1. The MAC fa:16:3e:1f:ab:d3 is not documented in Neutron's port list (and not sure if it should be) but appears to be owned by OVN in some way
2. The source IP 192.168.208.1 on the reply is the *gateway* IP for the provisioning subnet, which is a VLAN with a real external gateway *also* configured with 192.168.208.1.

Best I can tell, OVN is sending the DHCP reply as 192.168.208.1, which is actually not in allocation pool as it's configured as the subnet gateway and not use by Neutron at all. The subnet is not attached to a Neutron router, so not sure why it would be claimed. There ARE Neutron ports of owner network:dhcp, and one of these is allocation to lab-infra02 and listed in the logical port list in NB DB.

Here is more detail on the DHCP request/reply. Notice server-id is 192.168.208.1 where it ought to be 192.168.208.202:

17:19:04.278903 14:02:ec:32:3e:0c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 393: vlan 6, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 64, id 4507, offset 0, flags [none], proto UDP (17), length 375)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 14:02:ec:32:3e:0c, length 347, xid 0x56cdc32e, Flags [Broadcast] (0x8000)
   Client-Ethernet-Address 14:02:ec:32:3e:0c
   Vendor-rfc1048 Extensions
     Magic Cookie 0x63825363
     DHCP-Message (53), length 1: Discover
     MSZ (57), length 2: 1464
     Parameter-Request (55), length 35:
       Subnet-Mask (1), Time-Zone (2), Default-Gateway (3), Time-Server (4)
       IEN-Name-Server (5), Domain-Name-Server (6), Hostname (12), BS (13)
       Domain-Name (15), RP (17), EP (18), RSZ (22)
       TTL (23), BR (28), YD (40), YS (41)
       NTP (42), Vendor-Option (43), Requested-IP (50), Lease-Time (51)
       Server-ID (54), RN (58), RB (59), Vendor-Class (60)
       TFTP (66), BF (67), GUID (97), Unknown (128)
       Unknown (129), Unknown (130), Unknown (131), Unknown (132)
       Unknown (133), Unknown (134), Unknown (135)
     GUID (97), length 17: 0.55.53.53.50.53.56.54.67.85.54.48.49.89.82.78.48
     NDI (94), length 3: 1.3.16
     ARCH (93), length 2: 7
     Vendor-Class (60), length 32: "PXEClient:Arch:00007:UNDI:003016"
     END (255), length 0
 0x0000: 4500 0177 119b 0000 4011 67dc 0000 0000 E..w....@.g.....
 0x0010: ffff ffff 0044 0043 0163 58d3 0101 0600 .....D.C.cX.....
 0x0020: 56cd c32e 0000 8000 0000 0000 0000 0000 V...............
 0x0030: 0000 0000 0000 0000 1402 ec32 3e0c 0000 ...........2>...
 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x0100: 0000 0000 0000 0000 6382 5363 3501 0139 ........c.Sc5..9
 0x0110: 0205 b837 2301 0203 0405 060c 0d0f 1112 ...7#...........
 0x0120: 1617 1c28 292a 2b32 3336 3a3b 3c42 4361 ...()*+236:;<BCa
 0x0130: 8081 8283 8485 8687 6111 0037 3535 3235 ........a..75525
 0x0140: 3836 4355 3630 3159 524e 305e 0301 0310 86CU601YRN0^....
 0x0150: 5d02 0007 3c20 5058 4543 6c69 656e 743a ]...<.PXEClient:
 0x0160: 4172 6368 3a30 3030 3037 3a55 4e44 493a Arch:00007:UNDI:
 0x0170: 3030 3330 3136 ff 003016.
17:19:04.280925 fa:16:3e:1f:ab:d3 > 14:02:ec:32:3e:0c, ethertype 802.1Q (0x8100), length 398: vlan 6, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 64, id 4507, offset 0, flags [none], proto UDP (17), length 380)
    192.168.208.1.67 > 255.255.255.255.68: [no cksum] BOOTP/DHCP, Reply, length 352, xid 0x56cdc32e, Flags [Broadcast] (0x8000)
   Your-IP 192.168.208.228
   Client-Ethernet-Address 14:02:ec:32:3e:0c
   Vendor-rfc1048 Extensions
     Magic Cookie 0x63825363
     DHCP-Message (53), length 1: Offer
     BF (67), length 8: "ipxe.efi"
     Classless-Static-Route (121), length 14: (169.254.169.254/32:192.168.208.200),(default:192.168.208.1)
     Domain-Name-Server (6), length 4: 8.8.4.4
     Domain-Name (15), length 20: "cloud.arcanebyte.com"
     Lease-Time (51), length 4: 43200
     MTU (26), length 2: 1500
     Subnet-Mask (1), length 4: 255.255.252.0
     Default-Gateway (3), length 4: 192.168.208.1
     Server-ID (54), length 4: 192.168.208.1
     TFTP (66), length 10: "10.20.0.22"
     TFTP-Server-Address (150), length 4: 10.20.0.22
     PAD (0), length 0, occurs 4
     END (255), length 0
     PAD (0), length 0, occurs 4
 0x0000: 4500 017c 119b 0000 4011 d72c c0a8 d001 E..|....@..,....
 0x0010: ffff ffff 0043 0044 0168 0000 0201 0600 .....C.D.h......
 0x0020: 56cd c32e 0000 8000 0000 0000 c0a8 d0e4 V...............
 0x0030: 0000 0000 0000 0000 1402 ec32 3e0c 0000 ...........2>...
 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 0x0100: 0000 0000 0000 0000 6382 5363 3501 0243 ........c.Sc5..C
 0x0110: 0869 7078 652e 6566 6979 0e20 a9fe a9fe .ipxe.efiy......
 0x0120: c0a8 d0c8 00c0 a8d0 0106 0408 0804 040f ................
 0x0130: 1463 6c6f 7564 2e61 7263 616e 6562 7974 .cloud.arcanebyt
 0x0140: 652e 636f 6d33 0400 00a8 c01a 0205 dc01 e.com3..........
 0x0150: 04ff fffc 0003 04c0 a8d0 0136 04c0 a8d0 ...........6....
 0x0160: 0142 0a31 302e 3230 2e30 2e32 3296 040a .B.10.20.0.22...
 0x0170: 1400 1600 0000 00ff 0000 0000

+-------------------------+------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+-------------------------+------------------------------------------------------------------------------------------------------------------+
| admin_state_up | UP |
| allowed_address_pairs | |
| binding_host_id | lab-infra02 |
| binding_profile | |
| binding_vif_details | bound_drivers.0='ovn', connectivity='l2', port_filter='True' |
| binding_vif_type | ovs |
| binding_vnic_type | normal |
| created_at | 2022-07-23T17:20:44Z |
| data_plane_status | None |
| description | |
| device_id | dhcpa98a22b6-393b-5764-999a-f219f40cedd6-3176639e-b7ef-4359-aae3-f82f54471cde |
| device_owner | network:dhcp |
| device_profile | None |
| dns_assignment | fqdn='host-192-168-208-202.cloud.arcanebyte.com.', hostname='host-192-168-208-202', ip_address='192.168.208.202' |
| dns_domain | |
| dns_name | |
| extra_dhcp_opts | |
| fixed_ips | ip_address='192.168.208.202', subnet_id='c4a4b4f9-e9ae-4d1d-9aa7-7ba7858fcc38' |
| id | 420285ca-2785-47ff-9be5-6dc0fc83b0d6 |
| ip_allocation | immediate |
| mac_address | fa:16:3e:1b:5a:3a |
| name | |
| network_id | 3176639e-b7ef-4359-aae3-f82f54471cde |
| numa_affinity_policy | None |
| port_security_enabled | False |
| project_id | 7a8df96a3c6a47118e60e57aa9ecff54 |
| propagate_uplink_status | None |
| qos_network_policy_id | None |
| qos_policy_id | None |
| resource_request | None |
| revision_number | 29 |
| security_group_ids | |
| status | ACTIVE |
| tags | |
| trunk_details | None |
| updated_at | 2023-01-16T21:12:47Z |
+-------------------------+------------------------------------------------------------------------------------------------------------------+

Revision history for this message
yatin (yatinkarel) wrote :

Just Adding references with OVN DHCP working tests in TripleO zed:-

The required ovn commits[1][2] for baremetal booting are available in OVN-22.06, ovn-baremetal neutron docs[3].

OS:- CentOS 9 Stream
ovn version:- 22.06.0-16.el9s
ovs-version:- 2.17.0-62.el9s

ovn controller logs:- https://logserver.rdoproject.org/openstack-periodic-integration-zed-centos9/opendev.org/openstack/tripleo-ci/master/periodic-tripleo-ci-centos-9-ovb-3ctlr_1comp-featureset001-zed/365d126/logs/undercloud/var/log/containers/openvswitch/ovn-controller.log.txt.gz

ovn resources:- https://logserver.rdoproject.org/openstack-periodic-integration-zed-centos9/opendev.org/openstack/tripleo-ci/master/periodic-tripleo-ci-centos-9-ovb-3ctlr_1comp-featureset001-zed/365d126/logs/undercloud/var/log/extra/ovn.txt.gz

I don't have much insights on these, will ask @Lucas to take a look.

[1] https://github.com/ovn-org/ovn/commit/9cbd79c9ebbd0b6d0ea08c2cc70e234e56bb0415
[2] https://github.com/ovn-org/ovn/commit/0057cde2a64749bd2dbbaff525f7a1edccbd9c8a
[3] https://docs.openstack.org/neutron/latest/admin/ovn/baremetal.html#ovn-baremetal

tags: added: bar ovn
tags: added: baremetal
removed: bar
Revision history for this message
Lucas Alvares Gomes (lucasagomes) wrote :

Hi James,

When a port with VNIC "baremetal" is created, ML2/OVN will create a port of type "external" [0] in OVN. These ports are scheduled to a gateway node [1] (nodes marked with the "ovn-cms-options=enable-chassis-as-gw" flag in OVN). That's perhaps why you see it the reply coming from a gw node. The ovn-controller on the node hosting the external port is the one replying to the DHCP requests for the baremetal nodes (for VMs, that would be the ovn-controller running on the hypervisor where the VM is running).

Regarding the TFTP part, OVN does not do any TFTP, the TFTP server should be setup by the operator of the cluster. When the baremetal machine is booting, the TFTP server address should be given to it via DHCP options (see Ironic [2]) as well as the image name to be downloaded (see Ironic [3]).

[0] https://docs.openstack.org/neutron/latest/admin/ovn/external_ports.html
[1] https://docs.openstack.org/neutron/latest/admin/ovn/external_ports.html#ovn-database-information
[2] https://github.com/openstack/ironic/blob/eab0f73ff3c590a35d383cc1e5e788128141b9b9/ironic/common/pxe_utils.py#L577-L580
[3] https://github.com/openstack/ironic/blob/eab0f73ff3c590a35d383cc1e5e788128141b9b9/ironic/common/pxe_utils.py#L530-L545

Revision history for this message
James Denton (james-denton) wrote :

Hi Lucas,

Thanks for the comments.

> These ports are scheduled to a gateway node [1] (nodes marked with the "ovn-cms-options=enable-chassis-as-gw" flag in OVN). That's perhaps why you see it the reply coming from a gw node.

Sure, I understand. What's puzzling, though, is that the gateway node is responding as the subnet gateway IP (192.168.208.1) despite the network/subnet not being attached to a Neutron router. I guess I would've expected the source IP to be something from the allocation pool (like prior DHCP namespace IP was). Fixed IP 192.168.208.1 does not exist as a Neutron port.

Revision history for this message
James Denton (james-denton) wrote :

Hi Lucas,

I believe I have tracked this down to the lack of a "null terminated string" for option 66 and 67 presented by OVN. I reverted to a single DHCP agent and disabled OVN DHCP by setting [ovn]disable_ovn_dhcp_for_baremetal_ports = True.

At [1] you will see the full DHCP cycle with OVN DHCP, and at [2] the full DHCP cycle with DHCP Agent (dnsmasq). With OVN DHCP, option 66 and 67 are presented like so:

TFTP (66), length 14: "192.168.208.22"
BF (67), length 8: "ipxe.efi"

In this environment, 192.168.208.22 is the TFTP server IP and is on the same subnet as the PXE network (not routed). However, the PXE client attempts to use 192.168.208.1 as the TFTP server (tftp://192.168.208.1/ipxe.efi), possibly as a fallback.

Using dnsmasq-based DHCP agent, option 66 and 67 are presented like so:

TFTP (66), length 15: "192.168.208.22^@"
BF (67), length 9: "ipxe.efi^@"

Notice the null-termination happening there. With DHCP agent in place, my PXE client successfully loaded tftp://192.168.208.22/ipxe.efi and proceeded with iPXE boot and provisioning.

If it's useful, the system I'm testing with is an HP Proliant DL360 Gen9 PXE booting from the integrated HPE Ethernet 1Gb 4-port 331i Adapter. I believe this is a Broadcom BCM5719-based card. HP firmware 20.18.31. There may be a more recent firmware, but not sure if it handles normal strings or not.

[1] https://paste.opendev.org/show/bQ9ivwpx9rsBOS82bNVS/
[2] https://paste.opendev.org/show/bTqV5nT04949dfQvn3LD/

Revision history for this message
James Denton (james-denton) wrote :

PS: It's possible that the use of 192.168.208.1 is a red herring and coincidentally also the gateway IP address. A theory from a colleague is as follows:

--
Theory: The PXE client is EXPECTING null termination and therefore is always expecting to remove the final octal sequence (since NULL is only a single octal). You said before that when it was failing it was attempting to hit 192.168.201.1, also your gateway. The binary representation of 22 is 0001 0110. Lop off the last octal sequence, you get 0001 -> DEC 1.
--

It seems like these NICs (and others like them) might be expecting null termination, but more modern/recent NICs can handle either case. I have other NICs to test with but haven't gotten there yet.

Revision history for this message
James Denton (james-denton) wrote :
Download full text (6.3 KiB)

For grins, I decided to change the gateway IP for the provisioning subnet to 192.168.208.99. Now, when a machine is provisioned, we see the following in the flow table:

root@lab-infra02:/home/jdenton# ovs-ofctl dump-flows br-int | grep 192.168.208
 cookie=0xf36accc9, duration=40.502s, table=26, n_packets=0, n_bytes=0, idle_age=40, priority=100,udp,reg14=0x5,m
etadata=0x1,dl_src=14:02:ec:32:3e:0c,nw_src=192.168.208.251,nw_dst=255.255.255.255,tp_src=68,tp_dst=67 actions=co
ntroller(userdata=00.00.00.02.00.00.00.00.00.01.de.10.00.00.00.63.c0.a8.d0.fb.06.04.08.08.04.04.0f.14.63.6c.6f.75
.64.2e.61.72.63.61.6e.65.62.79.74.65.2e.63.6f.6d.33.04.00.00.a8.c0.1a.02.05.dc.01.04.ff.ff.fc.00.03.04.c0.a8.d0.6
3.36.04.c0.a8.d0.63,pause),resubmit(,27)
 cookie=0x88f3182e, duration=40.502s, table=27, n_packets=0, n_bytes=0, idle_age=40, priority=100,udp,reg0=0x8/0x
8,reg14=0x5,metadata=0x1,dl_src=14:02:ec:32:3e:0c,tp_src=68,tp_dst=67 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_D
ST[],mod_dl_src:fa:16:3e:1f:ab:d3,mod_nw_src:192.168.208.99,mod_tp_src:67,mod_tp_dst:68,move:NXM_NX_REG14[]->NXM_
NX_REG15[],load:0x1->NXM_NX_REG10[0],resubmit(,37)

Something to note is that while DHCP replies will be *sourced* as 192.168.208.99, the PXE client cannot actually communicate with that address, as shown here in these repeated ARP requests:

11:03:52.766526 14:02:ec:32:3e:0c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 405: vlan 6, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 64, id 25461, offset 0, flags [none], proto UDP (17), length 387)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 14:02:ec:32:3e:0c, length 359, xid 0xd2d114eb, Flags [Broadcast] (0x8000)
11:03:52.767872 fa:16:3e:1f:ab:d3 > 14:02:ec:32:3e:0c, ethertype 802.1Q (0x8100), length 386: vlan 6, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 64, id 25461, offset 0, flags [none], proto UDP (17), length 368)
    192.168.208.99.67 > 255.255.255.255.68: [no cksum] BOOTP/DHCP, Reply, length 340, xid 0xd2d114eb, Flags [Broadcast] (0x8000)
11:03:52.775178 14:02:ec:32:3e:0c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 6, p 0, ethertype ARP (0x0806), Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.208.99 tell 192.168.208.251, length 46
11:03:53.263325 14:02:ec:32:3e:0c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 6, p 0, ethertype ARP (0x0806), Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.208.99 tell 192.168.208.251, length 46
11:03:53.763352 14:02:ec:32:3e:0c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 6, p 0, ethertype ARP (0x0806), Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.208.99 tell 192.168.208.251, length 46

It's not until I attach the provisioning subnet to a Neutron router do I start to see ARP replies:

11:04:04.766589 14:02:ec:32:3e:0c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 6, p 0, ethertype ARP (0x0806), Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.208.99 tell 192.168.208.251, length 46
11:04:04.767108 fa:16:3e:e2:90:84 > 14:02:ec:32:3e:0c, ethertype 802.1Q (0x8100), length 64: vlan 6, p 0, ethertype ARP (0x0806), Ethernet (len 6), IPv4 (len 4), Repl...

Read more...

Revision history for this message
James Denton (james-denton) wrote :

Hi Lucas -

An additional hint was provided by https://bugs.launchpad.net/neutron/+bug/1971431:

"But then baremetal node fails to download ipxe.efi. It seems that the TFTP requests are being send towards DHCP server instead of ironic-conductor's TFTP server. So I checked the dhcp_options and realized that `next_server` option was missing. That's the second problem.

As soon as I manually added `next_server` with `ovn-nbctl dhcp-options-set-options <dhcp-option> [...] next_server="10.0.100.9"`, the baremetal node successfully downloaded ipxe.efi and booted just fine."

Worded differently, but exactly the behavior I'm seeing. I just verified that using `ovn-nbctl dhcp-options-set-options <dhcp-option> [...] next_server="<tftp ip>"` kicked off the download of ipxe.efi from the tftp server. It seems that option next_server is missing from the standard offer, but can be seen here once I add it manually:

04:36:28.903073 fa:16:3e:89:90:e6 > 0c:42:a1:d3:3f:e6, ethertype 802.1Q (0x8100), length 392: vlan 6, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 64, id 2290, offset 0, flags [none], proto UDP (17), length 374)
    192.168.208.1.67 > 255.255.255.255.68: [no cksum] BOOTP/DHCP, Reply, length 346, xid 0x502f8efd, secs 4, Flags [Broadcast] (0x8000)
   Your-IP 192.168.208.228
   Server-IP 192.168.208.22
   Client-Ethernet-Address 0c:42:a1:d3:3f:e6
   Vendor-rfc1048 Extensions
     Magic Cookie 0x63825363
     DHCP-Message (53), length 1: Offer
     BF (67), length 8: "ipxe.efi"
     Unknown (253), length 4: 3232288790
     Domain-Name-Server (6), length 4: 8.8.4.4
     Domain-Name (15), length 20: "cloud.arcanebyte.com"
     Lease-Time (51), length 4: 43200
     MTU (26), length 2: 1500
     Subnet-Mask (1), length 4: 255.255.252.0
     Default-Gateway (3), length 4: 192.168.208.1
     Server-ID (54), length 4: 192.168.208.1
     TFTP (66), length 14: "192.168.208.22"
     TFTP-Server-Address (150), length 4: 192.168.208.22
     PAD (0), length 0, occurs 4
     END (255), length 0
     PAD (0), length 0, occurs 4

Just to verify, here's what I'm running:

root@lab-infra02:/var/log/ovn# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.1 LTS"

root@lab-infra02:/var/log/ovn# ovn-nbctl --version
ovn-nbctl 22.09.0
Open vSwitch Library 3.0.1
DB Schema 6.3.0

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (master)

Related fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/875551

Revision history for this message
James Denton (james-denton) wrote :

IRC:

<lucasagomes> jamesdenton_, it's possible we don't have that option as a number in the "known" option list for ML2/OVN. Can you try sending the "server-ip-address" ?

---

I confirmed that sending Option 253 didn't work; Ironic needed to add 'server-ip-address' option to the port.

Didn't work:
ip_version='4', opt_name='253', opt_value='10.20.0.23'

Worked:
ip_version='4', opt_name='server-ip-address', opt_value='10.20.0.23'

However, Ironic is already using Option 255 (maybe for dnsmasq workaround) and if we use that, it works. The submitted patch is using Option 255. If that's not the desired approach, maybe the Ironic side can be adjusted.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/zed)

Related fix proposed to branch: stable/zed
Review: https://review.opendev.org/c/openstack/neutron/+/875662

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/yoga)

Related fix proposed to branch: stable/yoga
Review: https://review.opendev.org/c/openstack/neutron/+/875663

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/xena)

Related fix proposed to branch: stable/xena
Review: https://review.opendev.org/c/openstack/neutron/+/875664

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/wallaby)

Related fix proposed to branch: stable/wallaby
Review: https://review.opendev.org/c/openstack/neutron/+/875665

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (master)

Reviewed: https://review.opendev.org/c/openstack/neutron/+/875551
Committed: https://opendev.org/openstack/neutron/commit/dbfc18d1fa122140074d5c960c8440189b386fb8
Submitter: "Zuul (22348)"
Branch: master

commit dbfc18d1fa122140074d5c960c8440189b386fb8
Author: James Denton <email address hidden>
Date: Mon Feb 27 14:44:08 2023 -0600

    Apply Ironic's server-ip-address as TFTP next-server

    This patch uses existing DHCP option 255 (server-ip-address)
    provided by Ironic and applies it as next-server for the purpose
    of provisioning a baremetal server with OVN DHCP.

    Related-Bug: #2007167
    Change-Id: I59038639a8411c11c5fb8b366d9c858ef3db4f70

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/zed)

Reviewed: https://review.opendev.org/c/openstack/neutron/+/875662
Committed: https://opendev.org/openstack/neutron/commit/f6d24ebb052256bb2b818b13928961a6245f8f4f
Submitter: "Zuul (22348)"
Branch: stable/zed

commit f6d24ebb052256bb2b818b13928961a6245f8f4f
Author: James Denton <email address hidden>
Date: Mon Feb 27 14:44:08 2023 -0600

    Apply Ironic's server-ip-address as TFTP next-server

    This patch uses existing DHCP option 255 (server-ip-address)
    provided by Ironic and applies it as next-server for the purpose
    of provisioning a baremetal server with OVN DHCP.

    Related-Bug: #2007167
    Change-Id: I59038639a8411c11c5fb8b366d9c858ef3db4f70
    (cherry picked from commit dbfc18d1fa122140074d5c960c8440189b386fb8)

tags: added: in-stable-zed
tags: added: in-stable-yoga
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/yoga)

Reviewed: https://review.opendev.org/c/openstack/neutron/+/875663
Committed: https://opendev.org/openstack/neutron/commit/61ff4a1cc11c415269068f96f3238620527adb57
Submitter: "Zuul (22348)"
Branch: stable/yoga

commit 61ff4a1cc11c415269068f96f3238620527adb57
Author: James Denton <email address hidden>
Date: Mon Feb 27 14:44:08 2023 -0600

    Apply Ironic's server-ip-address as TFTP next-server

    This patch uses existing DHCP option 255 (server-ip-address)
    provided by Ironic and applies it as next-server for the purpose
    of provisioning a baremetal server with OVN DHCP.

    Related-Bug: #2007167
    Change-Id: I59038639a8411c11c5fb8b366d9c858ef3db4f70
    (cherry picked from commit dbfc18d1fa122140074d5c960c8440189b386fb8)

tags: added: in-stable-xena
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/xena)

Reviewed: https://review.opendev.org/c/openstack/neutron/+/875664
Committed: https://opendev.org/openstack/neutron/commit/c1973939fe876ea3bb11ea1cb916bbd0c46720d0
Submitter: "Zuul (22348)"
Branch: stable/xena

commit c1973939fe876ea3bb11ea1cb916bbd0c46720d0
Author: James Denton <email address hidden>
Date: Mon Feb 27 14:44:08 2023 -0600

    Apply Ironic's server-ip-address as TFTP next-server

    This patch uses existing DHCP option 255 (server-ip-address)
    provided by Ironic and applies it as next-server for the purpose
    of provisioning a baremetal server with OVN DHCP.

    Related-Bug: #2007167
    Change-Id: I59038639a8411c11c5fb8b366d9c858ef3db4f70
    (cherry picked from commit dbfc18d1fa122140074d5c960c8440189b386fb8)

tags: added: in-stable-wallaby
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/wallaby)

Reviewed: https://review.opendev.org/c/openstack/neutron/+/875665
Committed: https://opendev.org/openstack/neutron/commit/2e2066a55aa8c239adbd06b38936192b35829dd2
Submitter: "Zuul (22348)"
Branch: stable/wallaby

commit 2e2066a55aa8c239adbd06b38936192b35829dd2
Author: James Denton <email address hidden>
Date: Mon Feb 27 14:44:08 2023 -0600

    Apply Ironic's server-ip-address as TFTP next-server

    This patch uses existing DHCP option 255 (server-ip-address)
    provided by Ironic and applies it as next-server for the purpose
    of provisioning a baremetal server with OVN DHCP.

    Related-Bug: #2007167
    Change-Id: I59038639a8411c11c5fb8b366d9c858ef3db4f70
    (cherry picked from commit dbfc18d1fa122140074d5c960c8440189b386fb8)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.