Hi all,   We finally discovered the proper solution for our use-case. Let me share it with you: If you segment your ACI tenants with a firewall inbetween and you need to enable dhcp relay in ACI, you need to configure a DHCP relay per tenant. Inside the relay policy you need to use the application EPG of the "source network" - not of the destination (DHCP server network). By selecting the source EPG the dhcp relay will translate the dhcp request broadcast to a unicast with the source IP of the source network (anycast gateway). With this setting the traffic which passes the firewall to reach the DHCP server will not be blocked by the spoofing protection of the firewall. As already mentioned in the previous replies you don't need to configure Option 82 on the MS 2019 DHCP server. You just need to have a scope for the dhcp server network without available IPs so that the DHCP server will read the Option 82 link-selection value to choose the proper scope to assign an IP to the client. Attention: Option 82 with link-selection is generated by the DHCP relay which means when the client already got an IP and does a IP lease renewal it will send a direct packet to the DHCP server without Option 82. For this case you need to check the proper configuration on the DHCP server. We are working on it. The all for your support and wish you a marry x-max and a HNY 2020.   Cheers, Ivan   ... View more

Hi all, Thx  6askorobogatov  for pointing to the right solution. We did test it and after a bit of troubleshooting it worked as you described. On the DHCP server only the local scope for the ip subnet of the dhcp server itself is necessary to be created without any available IPs, and the MS Server 2019 will automatically read the Option 82 Sub-Option 5 (Link-Selection) and assign the dynamic IP from the correct pool.   Unfortunately we run into an issue which I believe is somehow caused by the DHCP relay agent design of the ACI. Would be interested to hear your opinion. Let me describe the issue by the following example: - We have the customer "tenant A" which has the VRF A, the BD A and an ANP with EPG A - We have a second server "tenant B" which has the VRF B, the BD B and an ANP with EPG B - As those two tenant are strictly separated (security zoning) we provide in each tenant a L3Out point to the Next Hop IP which is the Zone-Firewall. This way all outgoing traffic from every tenant is sent to the Zone-FW which enforces the security policies. Per tenant we use a default permit-all contract so we avoid having to handle contracts in ACI.   Now it comes: - For the VDI client which needs a dynamic IP we deploy the VM inside the "tenant A" - The DHCP request (broadcast) is generated by the VDI client (which comes from the client subnet 192.168.200.0/24) and is being transformed by the DHCP relay agent. This leads to the situation that the destination IP becomes the IP of the DHCP server 192.168.100.10 (which is good) and the source IP becomes the IP of the destination subnet anycast gw 192.168.100.1. (which is bad).  - Unfortunately the ACI DHCP relay agent is spooing the source IP and putting the destination anycast gw ip as the value (192.168.100.1) instead of taking the source client subnet anycast gw as the value (192.168.200.1). - This request is now forwarded inside the "tenant A" source VRF A which has the L3Out to the Zone-FW.   Guess what, the Zone-FW is dropping the packets because it is receiving the packet from a source which does not belong to the receiving interface. (You can workaround this by overriding the spoofing settings on the firewall - which is not actually what we want).   Any ideas why the stuff is working like that and how you overcome those situations where you segment tenants with a firewall in between? In legacy networks (IOS/IOS-XE) the source IP is always the L3 interface of the source network (e.g. SVI). It's never the destination SVI. :-(   Thx a lot for any feedback.   Cheers, Ivan   ... View more