ACI dhcp relay for MS Server 2019

[ivanindic]

Hi all,

We are currently trying to setup dhcp relay inside ACI and also the Option 82 on the MS AD SRV 2019. I went through the description in the Cisco technote, which is quite easy for the ACI configuration itself.

What I haven't understood correctly is how to configure the Microsoft DHCP Opton 82. Sub-Options like Agent Circuit ID (1), Agent Remote ID (2) and Link Selection (5) are needed.

Inside MS DHCP per scope (IP subnet) only one value can be assigned for the mentioned sub-options (see attachement). When trying to find out those values from the leafs I recognized that every leaf has other sub-option values.

May you help me understand where I make the mistake. Assigning the dhcp relay per BD means that all leafs have the relay agent configured. Which means I would need to configure all leaf values (sub-option) in my Option 82 on MS DHCP. But I can't as I can only configure one per scope. :-(

Thx a lot for helping me out here.

Br,

Ivan

[ivanindic]

Short update:

- It is possible to have multiple policies/conditions assigened to the scope inside MS DHCP. So it's possible to have multiple different relay agent information per scope.

So to simplify the above question:

- Do I need to configure inside DHCP Server per scope as many conditions as leafs I have?

Thx.

[6askorobogatov]

You do not need to config. multiple suboptions for option 82, just one. 

Microsoft DHCP now (from 2012 R3 or something)  supports  Option 82 Suboption 5 Link selection automatically. 

[ralphcarter]

Keep in mind that Cisco ACI automatically inserts Option 82 information into DHCP requests on behalf of the client when its used as a proxy.

With Server 2016 and 2019, you have to create a local server scope (for the DHCP server itself) and just exclude this range in the scope (if you want or keep it) in addition to the client scope.

Unless its some complicated setup you are deploying, you don't have to create any Option configuration on the DHCP server. 

[ivanindic]

Hi,

Thx for your fast response.

OK, means on the ACI you configure the dhcp relay and on the MS AD you just setup the client scopes and the local scope of the server subnet where the DHCP itself is located. So no need to configure option 82 nor any sub-options for it. Right?

Let me try this to see what happens.

As mentioned in 6askorobogatov reply the link selection should work automatically. Which again means no Option 82 at all have to be setup, the MS AD will read the link selection value and assigned the IP to the client from the proper scope.

I though that I have read in the technote that when the AD server replies without including the Option 82 in the response message the ACI leaf will discard the packet. Anyway let me try to see what happens.

Br,

Ivan

[ralphcarter]

Yes, go for it and let us know.

[6askorobogatov]

First of all:  is your DHCP in the fabric or outside ?  Is your DHCP relay BD and DHCP server are  on the same VRF ?  

In the case of "yes" you do not need option 82 for DHCP server to recognize correct subnet.

You only need Option82 compatible  DHCP server to include option82 in reply. If you DHCP relay is in the fabric and DHCP relay is in another VRF, you need to make DHCP server to recognize option82 to assign IP etc. from the right scope (suboption 5 will do that automatically) 

Also you need DHCP server to accept requests from local IPs. 

Let's say you server is 192.168.100.100 (subner 192.168.100.0/24) . You need to create DHCP  scope for subnet 192.168.100.0/24 and make it unavailable (scope and exclude IPs make 0 available addresses). DHCP will get request, sees right scope, sees no IPs available and will trying to assign IP  from other scopes based on Op82/sub5

[ivanindic]

Well, thx for detailed reply.

My DHCP is in the fabric but running in an other VRF then the clients. And yep, the relay is on the BD.

So you wrote I will definitely need to make the AD server recognize the Option 82. But how do I do that?

What I read from the DHCP relay technote is, there are different sub-options e.g. Agent Relay ID etc. As I recognized looking for those information to provide to our server guys the agent relay id is different per leaf switch.

Thus that means that in each client scope on the DHCP server I will need to configure all possible agent relay ids. Meaning every leaf has an individual which will need to be configured on the DHCP server as every leaf acts as anycast gw for my clients which also means every leaf is a dhcp relay. That would really not scale properly, who thinks about extending the DHCP config when expending the fabric. :-(

However, I will do some tests and analyse the traffic-capture sent to/from dhcp server so I will see if the Option82 is included and which scope is being selected.

Will share my findings as soon as it's done. 

[6askorobogatov · Accepted solution]

It's way simple then you imagine and has nothing to do with leafs. Due to vxlans, DHCP request from one VRF to other will NOT have a source IP of the source BD in the frame. DHCP server will see request coming from the local BD gateway, 

in my example from 192.268.100.X (whatever is L3 on BD is).  You need DHCP to accept request but not assign IP from 192.168.100.0/24 scope. Right ?  So you need scope for 192.168.100.xx with no lease addresses available. Create scope and exclude ALL IPs from the scope. 

That is it.  DHCP  will automatically recognize and use op82 suboption 5.   Just have a scope for correct IPs (matching source BD IPs)  ready. 

[ivanindic · Accepted solution]

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

[6askorobogatov]

nice to know. thanks. 

your config description is a bit confusing, what L3out has to do with DHCP relay request/reply if your DHCP server is in the fabric ?   Or im missing something ? 

[ivanindic]

Hi, let me try to simplify:

- The VDI Client (source network 192.168.200.0/24) and the DHCP server (destination network 192.168.100.0/24) are in "different" VRFs.

- The only way to reach the DHCP server from the client VRF is by routing through the L3out to the zone-firewall, which will then send back the traffic to the dhcp server in the other VRF. So source and destination are in the fabric but only reachable by going out of the fabric and back.

As mentioned the issue is that the source IP address is set by the dhcp relay agent to be from the destination network 192.168.100.1 but the origin dhcp broadcast has been raised inside the client subnet (192.168.200.0) and the corresponding VRF.

Source IP: 192.168.100.1 (VRF Client) takes the L3Out to the ZFW to reach the Destination IP 192.168.100.10 (DHCP server in VRF Server). But the ZFW is expecting to see a source IP from the client subnet (192.168.200.0/24) as it is coming from the client VRF. So the packet is beeing dropped as spoofing prevention.

Hopefully I could describe it a bit more clear

Br,

Ivan

[6askorobogatov]

"...- The only way to reach the DHCP server from the client VRF is by routing through the L3out to the zone-firewall, ..."

Fabric send DHCP request directly from requestor BD to DHCP server. DHCP relay is all what you need to allow traffic and leak route.   You have to specify in DHCP policy TENANT / APP / EPG of the DHCP server, not the L3Out

That is VXLAN and that is the reason why ACI uses option 82,  IP of the source in the frame is local to DHCP server. So, to assign IP from the correct subnet DHCP server reads content of Opt.82 

[ivanindic]

Well, this is exactly how we have configured it. I have attached two screenshots.

The client subnet (100.76.2.0/23) routing table has no direct route to the destination subnet (100.78.0.0/23) so it has to use the default route (0.0.0.0) which points to the IP of the zone-firewall interface. Seams no leaking established by the dhcp relay configuration.

Here you can see the zone-firewall output:

Firewall static routes:

S 100.76.2.0/23 [10/0] via 100.109.160.33, udspzzzp01-sp (service zone) -> The client subnet is behind service zone!
S 100.78.1.0/24 [10/0] via 100.109.160.17, udspzzzp01-ap (admin zone) -> The server subnet is behind admin zone!

Firewall packet capture
478.144033 udspzzzp01-sp in 100.78.1.1.67 -> 100.78.1.99.67: udp 374 
481.802744 udspzzzp01-sp in 100.78.1.1.67 -> 100.78.1.99.67: udp 374
492.077870 udspzzzp01-sp in 100.78.1.1.67 -> 100.78.1.99.67: udp 374

The dhcp request is sent to the dhcp server with the source 100.78.1.1 but getting to the zone-firewall on the services interface as the client is sitting in the 100.76.2.0/23 network). That's spoofing from the firewalls point of view and it's beeing dropped.

Actually with the VXLAN I don't get it why the source IP could not be the 100.76.1.1.

Probably you can find the issue in my setup I really just can't see it. :-(

Br,

Ivan 

[6askorobogatov]

If DHCP request / reply goes via FW, you have misconfigured DHCP relay policy, i believe. 

Whatever is in the ACI always has a way to connect to each other, that is the idea of the fabric.   

If you config. DHCP policy with TENANT/APP/EPG/DHCP address, fabric will take care of  sending broadcast in the source BD to DHCP server.   Firewalls should not be in the path of DHCP request/reply.  Later, when client will try to renew lease it will use unicast that will follow route path. That is a different story, you may want to  allow that in FW,  if not, client will still eventually renew lease by sending broadcast.

That may help :https://learningnetwork.cisco.com/docs/DOC-27313