why can't turn dhcp discovery and request message into unicast ?
As we know, The DHCP operation begins with clients broadcasting a request, then DHCP server send a DHCP offer message to the client. In response to the DHCP offer,the client replies with a DHCP request to request the offered address. DHCP Discovery message and DHCP request message are both broadcast. In some scenarios, we want to broadcast messages as little as possible, Why can't turn DHCP discovery and request message into unicast before the broadcast outflow from host? Maybe we add some flow entries in OVS bridge to modify mac_address of DHCP broadcast, the premise is L2 agent to be able to get mac_address of dhcp port. I add some flow entries for br-eth1 bridge which modify broadcast into unicast, it works, and vm successfully request IP addresses automatically.
[root@compute1 ~]# ovs-ofctl dump-flows br-eth1 #####this is my flow entries, mac_address of dhcp port is fa:16:3e:c0:4e:ea#####
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=263106.173s, table=0, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=9,ip,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff,nw_src=0.0.0.0,nw_dst=255.255.255.255 actions=resubmit(,26)
cookie=0x0, duration=263106.155s, table=26, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=2,dl_vlan=13,dl_src=fa:16:3e:5f:2f:7b actions=mod_vlan_vid:333,mod_dl_dst:fa:16:3e:c0:4e:ea,NORMAL
cookie=0x0, duration=263107.295s, table=26, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=0 actions=drop
I also develop some codes for neutron which can get mac_address of dhcp_port and add flow entries for ovs bridge.
For compatibility issues with multiple agents per network for HA, I have a way to solve it. For example, when there are two dhcp-agents per network, I add two tables to modify mac_address for DHCP broadcast, in table 26 ,it turn the dest mac_address into one dhcp_port mac_address and normal , and at the same time the message will be resubmitted into table 27. In table 27, it turn the dest mac_address into the other dhcp_port mac_address add then normal. At last, both of dhcp-agents will receive the DHCP request.
Below are flow entries as example:
[root@compute1 ~]# ovs-ofctl dump-flows br-eth1
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=263106.173s, table=0, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=9,ip,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff,nw_src=0.0.0.0,nw_dst=255.255.255.255 actions=resubmit(,26)
cookie=0x0, duration=44.624s, table=26, n_packets=2, n_bytes=0, idle_age=44, priority=2,in_port=2,dl_vlan=1,dl_src=fa:16:3e:e4:d5:4e actions=mod_dl_dst:fa:16:3e:2b:3a:eb,mod_vlan_vid:333,NORMAL,resubmit(,27)
cookie=0x0, duration=263107.295s, table=26, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=0 actions=drop
cookie=0x0, duration=263106.155s, table=27, n_packets=2, n_bytes=0, idle_age=65534, hard_age=65534, priority=2,dl_vlan=1,dl_src=fa:16:3e:e4:d5:4e actions=mod_vlan_vid:333,mod_dl_dst:fa:16:3e:c0:4e:ea,NORMAL
cookie=0x0, duration=263107.295s, table=27, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=0 actions=drop
