ChatGPT Solution to allow DHCP from PPR'd interface

[kpalmer@naturipefarms.com]

Is anyone else using set interface Null0 in this way? I ran into an issue where DHCP clients on 192.168.44.0/24 were not receiving DHCP assignments from the Cisco router. ChatGPT recommend set interface Null0 and it worked. ChatGPT provided the following explanation:

Notes
Why DHCP bypass works here
In PBR, set interface Null0 doesn’t actually send DHCP to a black hole — it skips the PBR path and falls back to the router’s normal routing.
That lets your local VLAN DHCP exchange happen without being forced toward Firewall2.
Order matters
Sequence 1 must remain at the top so DHCP packets are matched before your ASA rules.
Removing or reordering this will break DHCP again.

ip dhcp excluded-address 192.168.44.1 192.168.44.50

ip dhcp pool Data44
network 192.168.44.0 255.255.255.0
!partial scope shown here
default-router 192.168.44.1

interface GigabitEthernet0/0/1.44
description ->Data Subnet
encapsulation dot1Q 44
ip address 192.168.44.1 255.255.255.0
ip policy route-map SelectFirewall
!

ip access-list extended ACL-BYPASS-DHCP
10 remark Match DHCP client/server traffic
10 permit udp any eq bootpc any eq bootps
20 permit udp any eq bootps any eq bootpc

route-map SelectFirewall permit 1
match ip address ACL-BYPASS-DHCP
set interface Null0
!

[MHM Cisco World]

Forget GPT it not accurate 

Can I see after you remove policy 

Debug ip dhcp

MHM 

[kpalmer@naturipefarms.com]

MHM, The solution above solved the issue. My curiosity is around why Cisco has almost no documentation describing this method of using set interface null0. I'll run debug ip dhcp and post the results when I get a chance. 

[MHM Cisco World]

Let wait debug then let see why we need set interface null0

OK waiting your reply 

Thanks 

MHM

[bigevilbeard]

kpalmer@naturipefarms.com thats amazing that you found and way to make this work. I think the reason you seen no documents on this is as this is a "Confluence of features", what AI has done is found is a result of combining multiple, independently designed features you have currently enable in an unintended but effective way. 

Now the risk here lies in the potential for unpredictable and unintended outcomes, as the others have raised.

[paul driver]

You dont mention how your topology is setup as you shouldn't need PBR for dhcp to work 

[kpalmer@naturipefarms.com]

PBR is configured on several interfaces to direct traffic to the correct location. The router has 4 physical interfaces and 8 subinterfaces. At one point there were four firewalls each with their own site to site VPN tunnels and MPLS. We are down to two firewalls and MPLS. My guess is that DHCP would have worked if I had removed the PBR from the interface. I left PBR in place since it was more important than DHCP. The work around was to run DHCP on a Windows server until I found a solution. 

[paul driver]

Hello
thank you for clarifying - so nulling the interface so its not PBR’d for dhcp traffic makes sense - As you would want allocation still continue for your users from the correct location of the dhcp server  which isn’t towards the PBR next hop