running vm can not change its gateway and ip as the dhcp server send

Bug #1514318 reported by yujie
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
CirrOS
Invalid
Low
Unassigned

Bug Description

In kilo + dvr environment, a running vm could not get the ip address sent by dhcp server.
1. Create a net with one subnet, setting no enable dhcp.
2. Create a vm in the subnet above, after it created successfully, it has no ip.
3. Setting the subnet enable dhcp, let the cirros vm created in step 2 exec "sudo udhcpc".
    Capturing packets in network node, the dhcp packet looks fine. But vm has no ip yet.
4. Reboot vm, it will get ip address.

The gateway setting on subnet has the same problem.

Changed in neutron:
assignee: nobody → venkata anil (anil-venkata)
Revision history for this message
Miguel Angel Ajo (mangelajo) wrote :

Hi @anil-venkata, does DVR has any specific flows for forwarding dhcp traffic specifically?, can you explain why's this happening?

Cheers,
Miguel.

Changed in neutron:
importance: Undecided → Low
Changed in neutron:
status: New → Incomplete
Revision history for this message
yujie (16189455-d) wrote :
Download full text (3.9 KiB)

As the cirros could not capture packets, I capture at the Compute Node which the vm live.
1. The vm start up without set the dhcp enabled.
2. Enable dhcp.
3. Cirros exec udhcpc.
The packets get in the tap port is:
tcpdump -i tapb3dcd00a-c5 -nevx
tcpdump: WARNING: tapb3dcd00a-c5: no IPv4 address assigned
tcpdump: listening on tapb3dcd00a-c5, link-type EN10MB (Ethernet), capture size 65535 bytes
01:40:33.441632 fa:16:3e:4c:3c:2e > Broadcast, ethertype IPv4 (0x0800), length 322: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 308)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from fa:16:3e:4c:3c:2e, length 280, xid 0x5f032d3e, Flags [none]
   Client-Ethernet-Address fa:16:3e:4c:3c:2e
   Vendor-rfc1048 Extensions
     Magic Cookie 0x63825363
     DHCP-Message Option 53, length 1: Discover
     Client-ID Option 61, length 7: ether fa:16:3e:4c:3c:2e
     MSZ Option 57, length 2: 576
     Parameter-Request Option 55, length 7:
       Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
       Domain-Name, BR, NTP
     Vendor-Class Option 60, length 12: "udhcp 1.20.1"

01:40:33.444854 fa:16:3e:1f:50:9d > fa:16:3e:4c:3c:2e, ethertype IPv4 (0x0800), length 367: (tos 0xc0, ttl 64, id 9022, offset 0, flags [none], proto UDP (17), length 353)
    10.0.30.10.bootps > 10.0.30.11.bootpc: BOOTP/DHCP, Reply, length 325, xid 0x5f032d3e, Flags [none]
   Your-IP 10.0.30.11
   Server-IP 10.0.30.10
   Client-Ethernet-Address fa:16:3e:4c:3c:2e
   Vendor-rfc1048 Extensions
     Magic Cookie 0x63825363
     DHCP-Message Option 53, length 1: Offer
     Server-ID Option 54, length 4: 10.0.30.10
     Lease-Time Option 51, length 4: 86400
     RN Option 58, length 4: 43200
     RB Option 59, length 4: 75600
     Subnet-Mask Option 1, length 4: 255.255.255.0
     BR Option 28, length 4: 10.0.30.255
     Domain-Name Option 15, length 14: "openstacklocal"
     Hostname Option 12, length 15: "host-10-0-30-11"
     Default-Gateway Option 3, length 4: 10.0.30.1
     Domain-Name-Server Option 6, length 4: 8.8.8.8

01:40:33.450331 fa:16:3e:4c:3c:2e > Broadcast, ethertype IPv4 (0x0800), length 334: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 320)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from fa:16:3e:4c:3c:2e, length 292, xid 0x5f032d3e, Flags [none]
   Client-Ethernet-Address fa:16:3e:4c:3c:2e
   Vendor-rfc1048 Extensions
     Magic Cookie 0x63825363
     DHCP-Message Option 53, length 1: Request
     Client-ID Option 61, length 7: ether fa:16:3e:4c:3c:2e
     Requested-IP Option 50, length 4: 10.0.30.11
     Server-ID Option 54, length 4: 10.0.30.10
     MSZ Option 57, length 2: 576
     Parameter-Request Option 55, length 7:
       Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
       Domain-Name, BR, NTP
     Vendor-Class Option 60, length 12: "udhcp 1.20.1"

01:40:33.509417 fa:16:3e:1f:50:9d > fa:16:3e:4c:3c:2e, ethertype IPv4 (0x0800), length 367: (tos 0xc0, ttl 64, id 9023, offset 0, flags [none], proto UDP (17), length 353)
    10.0.30.10.bootps > 10.0.30.11.bootpc: BOOTP/DHCP, Reply, length 325, xid 0x5f032d3e, Flags [none]
   Your-IP 10.0.30.11
   Server-...

Read more...

Changed in neutron:
status: Incomplete → New
yujie (16189455-d)
description: updated
affects: neutron → cirros
yujie (16189455-d)
Changed in cirros:
status: New → Invalid
Revision history for this message
venkata anil (anil-venkata) wrote :

I suspected below security group rules not added when user calls "neutron subnet-update --enable-dhcp"

-A neutron-openvswi-i888e2f4e-f -s 20.0.0.4/32 -p udp -m udp --sport 67 --dport 68 -j RETURN
-A neutron-openvswi-o888e2f4e-f -p udp -m udp --sport 68 --dport 67 -m comment --comment "Allow DHCP client traffic." -j RETURN

But I am wrong and these rules are added when "subnet-update" is called with "enable-dhcp"
But it is taking some time for adding these rules.

So when bug reporter calls "sudo udhcpc", it uses "default 3 seconds" as timeout between sending request packets, and so unable to get ip.
But when "udhcpc -T 60" is called with a timout of 60 seconds(cirros image by default is using 60 as timeout when calling udhcpc), I see vm getting ip.

Changed in cirros:
assignee: venkata anil (anil-venkata) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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