I mentioned before that I had some trouble getting DHCP working with OVN ACLs enabled. I think I have finally gotten to the bottom of it.
My first workaround was a brute force patch to bypass conntrack if the packet was a DHCP request or response. That worked, but I wasn't able to explain why it was needed. It turns out I was looking in the wrong place. I thought it had to do with conntrack marking the odd looking DHCP requests as invalid. I was actually getting confused by a bunch of IPv6 traffic getting marked as invalid. It seems IPv6 neighbor discovery stuff is what's being marked invalid (at least that's my guess of what those packets are). Once I filtered all IPv6 out earlier in the flows, I got a clearer picture of what was happening. I'll have to revisit IPv6 later. Here's the broadcast flow in table 33 (the beginning of the logical egress pipeline) on my test environment. table=33, n_packets=1304, n_bytes=150792, priority=100,reg7=0xffff,metadata=0x1 actions=set_field:0x2->reg5,set_field:0x2->reg7,resubmit(,34),set_field:0x1->reg5,set_field:0x1->reg7,resubmit(,34),set_field:0x3->reg5,set_field:0x3->reg7,resubmit(,34),set_field:0x4->reg5,set_field:0x4->reg7,resubmit(,34),set_field:0xffff->reg7 So, we should see the packet resubmitted to table 34 for each logical port on the network the DHCP request was broadcast to. The problem is that it only hits table 34 once, for the first logical port, which is *not* the DHCP server. In fact, this would probably explain why I've seen inconsistent behavior, since the DHCP server could be listed first sometimes. I only see this problem when the ct() action is being used, so my guess is that this action causes the context to be lost: table=48, n_packets=2, n_bytes=660, priority=100,ip,metadata=0x1 actions=ct(table=49,zone=NXM_NX_REG5[0..15]) Does this seem plausible? If so, would you consider that a bug in the ct() action? -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
