Bug 1415449 - [OVN] IPAM has no reply to DHCP request for renewal
Summary: [OVN] IPAM has no reply to DHCP request for renewal
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openvswitch
Version: 7.3
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Aaron Conole
QA Contact: qding
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-22 06:04 UTC by qding
Modified: 2017-07-13 06:03 UTC (History)
11 users (show)

Fixed In Version: openvswitch-2.6.1-6.git20161206.el7fdb
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-12 15:23:12 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description qding 2017-01-22 06:04:10 UTC
Description of problem:
OVN IPAM has no problem for dhclient to acquire IP address for a interface, but no replay for renewal.
The difference between DHCP Request for renewal and offer is that
ip src for renewal is the assigned IP address, while ip src for offer is 0.0.0.0, below is the log for tcpdump and in lfow table, it looks like only ip_src=0.0.0.0 defined

DHCP request for renewal:
00:06:36.562413 00:de:ad:00:00:01 > Broadcast, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    172.16.0.1.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 00:de:ad:00:00:01, length 300, xid 0x7a7efc6e, secs 203, Flags [none] (0x0000)
	  Client-IP 172.16.0.1
	  Client-Ethernet-Address 00:de:ad:00:00:01
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Request
	    Parameter-Request Option 55, length 13: 
	      Subnet-Mask, BR, Time-Zone, Classless-Static-Route
	      Domain-Name, Domain-Name-Server, Hostname, YD
	      YS, NTP, MTU, Option 119
	      Default-Gateway
	    END Option 255, length 0
	    PAD Option 0, length 0, occurs 41

DHCP Request for offer
00:06:52.340220 00:de:ad:00:00:01 > Broadcast, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 00:de:ad:00:00:01, length 300, xid 0x73756c65, Flags [none] (0x0000)
	  Client-Ethernet-Address 00:de:ad:00:00:01
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Request
	    Server-ID Option 54, length 4: 172.16.0.254
	    Requested-IP Option 50, length 4: 172.16.0.1
	    Parameter-Request Option 55, length 13: 
	      Subnet-Mask, BR, Time-Zone, Classless-Static-Route
	      Domain-Name, Domain-Name-Server, Hostname, YD
	      YS, NTP, MTU, Option 119
	      Default-Gateway
	    END Option 255, length 0
	    PAD Option 0, length 0, occurs 29

lflow

  table=10(ls_in_dhcp_options ), priority=100  , match=(inport == "hv0_vm00_vnet1" && eth.src == 00:de:ad:00:00:01 && ip4.src == 0.0.0.0 && ip4.dst == 255.255.255.255 && udp.src == 68 &&)
  table=10(ls_in_dhcp_options ), priority=100  , match=(inport == "hv0_vm00_vnet1" && eth.src == 00:de:ad:00:00:01 && ip6.dst == ff02::1:2 && udp.src == 546 && udp.dst == 547), action=(r)
  table=10(ls_in_dhcp_options ), priority=0    , match=(1), action=(next;)
  table=11(ls_in_dhcp_response), priority=100  , match=(inport == "hv0_vm00_vnet1" && eth.src == 00:de:ad:00:00:01 && ip4.src == 0.0.0.0 && ip4.dst == 255.255.255.255 && udp.src == 68 &&)
  table=11(ls_in_dhcp_response), priority=100  , match=(inport == "hv0_vm00_vnet1" && eth.src == 00:de:ad:00:00:01 && ip6.dst == ff02::1:2 && udp.src == 546 && udp.dst == 547 && reg0[3]))
  table=11(ls_in_dhcp_response), priority=0    , match=(1), action=(next;)


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Numan Siddique 2017-01-23 09:09:18 UTC
If the client doesn't get any response for DHCP renewal, the client should eventually fall back to sending DHCP discover right ?

Comment 3 Numan Siddique 2017-01-23 09:12:07 UTC
We could fix this by removing the ip4.src in the match of 'ls_in_dhcp_options' table. I would like to know if it is too bad for the client to fall back to DHCP discover request.

Comment 4 Russell Bryant 2017-01-24 13:20:00 UTC
(In reply to Numan Siddique from comment #3)
> We could fix this by removing the ip4.src in the match of
> 'ls_in_dhcp_options' table. I would like to know if it is too bad for the
> client to fall back to DHCP discover request.

Yes, that's probably not good enough.  That would mean its lease had expired and it shouldn't be using that IP address anymore, right?

Modifying the logical flows is a trivial patch, but do we need changes to ovn-controller as well?

Comment 5 Numan Siddique 2017-01-24 13:29:02 UTC
I don't think changes are required in ovn-controller.

Comment 6 Numan Siddique 2017-01-25 08:21:23 UTC
Patch submitted upstream - https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/328001.html

Comment 7 Lance Richardson 2017-01-25 18:10:23 UTC
(In reply to Numan Siddique from comment #6)
> Patch submitted upstream -
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/328001.html

Would it make sense to ask for this to be back-ported to 2.7?

Comment 8 Numan Siddique 2017-01-27 13:50:59 UTC
It's backported to 2.7 and 2.6 - https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/328024.html

Comment 9 Russell Bryant 2017-01-31 20:01:04 UTC
The fix for this issue was merged upstream to master, branch-2.7, and branch-2.6.  It now needs to be applied to our builds.

master: https://github.com/openvswitch/ovs/commit/213615b3cd1cf823d71e12e565c639c96f4213fb
branch-2.7: https://github.com/openvswitch/ovs/commit/ac4e51f216332a5350f482bdc953ab224c34b68c
branch-2.6: https://github.com/openvswitch/ovs/commit/3f08d2052db09253e8127424efaa696e54d242bb

Lance, could you help us get this patch into dist-git?

Comment 10 Aaron Conole 2017-01-31 21:35:45 UTC
I'll pull it into fdbeta and fedora.

Comment 14 qding 2017-03-08 03:24:42 UTC
verified with openvswitch-2.6.1-10.git20161206.el7fdp.x86_64
beaker job: https://beaker.engineering.redhat.com/jobs/1748086


Note You need to log in before you can comment on or make changes to this bug.