vrouter wrongly intercepts dhcp-relay response from service instance

[Marcel Wiget]

VM service instance running inside Contrail/Openstack is acting as DHCP server for remotely connected DHCP clients behind a physical router. The router is connected via BGP and MPLS over GRE to Contrail. This is a NFV use case where a cloud CPE is implemented as a virtualized network function (NFV).

While DHCP packets are successfully relayed by the router's dhcp relay server to the service instance, the VM's DHCP response packets aren't forwarded via vrouter over the data path to the physical router.

Discovered the issue while testing contrail 1.03 in the lab, then tried to figure out what happens by looking at the latest open contrail source code.

The root cause seem to be in vrouter/dp-core/vr_flow.c, where all dhcp packets with either destination UDP port 67 or 68 are trapped for local handling by the agent (AGENT_TRAP_L3_PROTOCOLS).

DHCP packets from a server to a client can be distinguished from a dhcp relay response packet to the dhcp server by checking the UDP source port: a dhcp client will always use source port 68 (bootpc), while a dhcp server sending a response to another dhcp server uses source port 67 (bootps). Both, client and server use destination port 67 (bootps).

Suggested patch attached.

Setup:

[DHCP client] ------ [vrf on physical router with dhcp relay to VM's IP address] ---- [Contrail/Openstack service instance with dhcp server]

DHCP relayed packets arrive within the service instance, but the response packets are trapped by the vrouter, which can be seen via the debug gui at http://<contrail-ip-address>:8085/Snh_DhcpInfo?

[Marcel Wiget (mwiget)]

Thinking about my quick-and-dirty patch a bit more, its probably advisable to keep the test for the destination udp port in place as well, but exclude the dhcp relay response case specifically, where source and destination udp port are set to 67 (bootps).

[Anand H. Krishnan (anandhk)]

For now, we are going to trap only packets from VM, and that too only dhcp packets that are part of request. This issue has been fixed in 1.05