Config Lab: DAI 1
IP uses Address Resolution Protocol (ARP) to discover the MAC address used by other hosts in the same subnet. Unfortunately, cybersecurity attacks often use legitimate protocols in unintended ways to form an attack, and ARP is no exception.
To help prevent ARP-based attacks, engineers can enable the Dynamic ARP Inspection (DAI) feature of LAN switches. DAI in a switch monitors ARP messages flowing through the switch, filtering messages based on a set of rules. Notably, DAI compares ARP messages to tables of legitimate data about IP/MAC address pairs, with the DHCP Snooping feature gathering that data based on DHCP messages. In this lab, you configure both DAI and DHCP snooping on two different switches and examine the minor differences in configuration.
The Lab Exercise
The Lab Exercise
Many cybersecurity attacks use established protocols like DHCP and ARP to find a way to learn information and cause problems in a network. Two switch features, DHCP Snooping and Dynamic ARP Inspection (DAI), prevent attacks based on DHCP and ARP, respectively. Both use a similar configuration model to enable the feature in a VLAN and then either trust or not trust each switch port.
DAI relies on a list of valid IP/MAC address pairs. The list includes IP/MAC address pairs considered to be legitimate in the subnet. DAI then monitors incoming ARP messages on untrusted ports, comparing the ARP messages to the table of legitimate address pairs and filtering the messages that do not conform to the entries in the table.
DAI uses a table built by DHCP Snooping or by ARP ACLs. For this lab, configure DHCP Snooping correctly, which causes DHCP Snooping to create a table called the DHCP Snooping Binding Table. This table lists the IP/MAC address pairs for any host that successfully leased an IP address. Then also configure DAI so that it uses the DHCP Snooping Binding table to make its decisions.
For this lab, take these specific steps.
- Configure DHCP Snooping as follows:
- Enable DHCP Snooping in VLAN 10.
- Switch SW1 operates as a layer 2 switch, not a layer 3 switch, so disable the insertion of DHCP Option 82 headers.
- Configure (or use the default) so each switch port is either trusted or untrusted for DHCP Snooping.
- Configure DAI as follows:
- Enable DAI in VLAN 10.
- Analyze the devices attached to the switch and ask yourself: Which devices will have entries in the DHCP Snooping Binding table? Then, make a note of those devices and switch ports.
- Configure (or use the default) so each switch port is either trusted or untrusted for DAI Snooping.
Initial Configurations
The initial configuration on switch SW1 places all four of its ports into the same VLAN (VLAN 10). In addition, the router has an IP address configured on its LAN interface (G0/0) so that it can ping the DHCP server’s address on the LAN. The router should also be able to ping the client PCs once they lease an IP address.
hostname SW1
!
vlan 10
!
interface range FastEthernet0/1-3
switchport access vlan 10
switchport mode access
spanning-tree portfast
!
interface GigabitEthernet0/1
switchport access vlan 10
switchport mode access
spanning-tree portfastExample 1: SW1 Config
hostname R1
!
interface GigabitEthernet0/0
ip address 172.16.10.1 255.255.255.0
no shutdown
!
interface GigabitEthernet0/2/0
ip address 172.16.12.1 255.255.255.0
no shutdown
!
router ospf 1
network 172.16.0.0 0.0.255.255 area 0Example 2: R1 Config
The PCs each act as a DHCP client, expecting to lease an IP address and learn the mask and default gateway settings from the DHCP server. You can assume the DHCP Server shown in the figure works. However, to be complete, Example 5 shows the IOS DHCP server configuration that you could use to support this lab. (The CPT and CML files supplied with this lab use this same configuration.)
hostname DHCP_Server
!
ip dhcp excluded-address 172.16.10.1 172.16.10.100
!
ip dhcp pool subnet1
network 172.16.10.0 255.255.255.0
dns-server 172.16.10.9
default-router 172.16.10.1
domain-name example.com
!
interface GigabitEthernet0/0
ip address 172.16.10.9 255.255.255.0
no shutdown
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0Example 3: DHCP Server (IOS Router)
Answer Options - Click Tabs to Reveal
You can learn a lot and strengthen real learning of the topics by creating the configuration – even without a router or switch CLI. In fact, these labs were originally built to be used solely as a paper exercise!
To answer, just think about the lab. Refer to your primary learning material for CCNA, your notes, and create the configuration on paper or in a text editor. Then check your answer versus the answer post, which is linked at the bottom of the lab, just above the comments section.
You can also implement the lab using the Cisco Packet Tracer network simulator. With this option, you use Cisco’s free Packet Tracer simulator. You open a file that begins with the initial configuration already loaded. Then you implement your configuration and test to determine if it met the requirements of the lab.
(Use this link for more information about Cisco Packet Tracer.)
Use this workflow to do the labs in Cisco Packet Tracer:
- Download the .pkt file linked below.
- Open the .pkt file, creating a working lab with the same topology and interfaces as the lab exercise.
- Add your planned configuration to the lab.
- Test the configuration using some of the suggestions below.
You can also implement the lab using Cisco Modeling Labs – Personal (CML-P). CML-P (or simply CML) replaced Cisco Virtual Internet Routing Lab (VIRL) software in 2020, in effect serving as VIRL Version 2.
If you prefer to use CML, use a similar workflow as you would use if using Cisco Packet Tracer, as follows:
- Download the CML file (filetype .yaml) linked below.
- Import the lab’s CML file into CML and then start the lab.
- Compare the lab topology and interface IDs to this lab, as they may differ (more detail below).
- Add your planned configuration to the lab.
- Test the configuration using some of the suggestions below.
Network Device Info:
This table lists the interfaces listed in the lab exercise documentation versus those used in the sample CML file.
| Device | Lab Port | CML Port |
| SW1 | G0/1 | G0/0 |
| SW1 | F0/1 | G0/1 |
| SW1 | F0/2 | G0/2 |
| SW1 | F0/3 | G0/3 |
| R1 | G0/2/0 | G0/2 |
Lab Answers Below: Spoiler Alert
Lab Answers: Configuration (Click Tab to Reveal)
ip dhcp snooping
ip dhcp snooping vlan 10
no ip dhcp snooping information option
!
ip arp inspecetion vlan 10
!
interface fastethernet0/1
ip dhcp snooping trust
ip arp inspection trust
!
interface GigabitEthernet0/1
ip arp inspection trust
! You do NOT need to trust for DHCP hereExample 1: SW1 Config
Commentary, Issues, and Verification Tips (Click Tabs to Reveal)
First, focus on the DHCP Snooping configuration independent of the DAI configuration. The first three lines of Answer Example 1 list the DHCP Snooping global configuration. The first two commands enable DHCP Snooping in VLAN 10 (both are required): ip dhcp snooping and ip dhcp snooping vlan 10. Then, the no ip dhcp information option global command reverses a default setting of ip dhcp information option, which is necessary because the default setting makes sense only when the switch acts as both a layer 3 switch and as a DHCP Relay Agent.
As for the DHCP Snooping trust settings, the two switch SW1 ports connected to the DHCP clients can use the default setting of untrusted. But those defaults matter quite a bit to DAI because of the last of the following logic switch logic steps:
- DHCP Client messages enter the DHCP Snooping untrusted ports.
- DHCP Snooping allows the messages because they follow protocol rules.
- DHCP Snooping adds IP/MAC address pairs to the SW1 DHCP Snooping Binding table.
As for the other switch ports, the switch must trust the ports connected to the DHCP server (ip dhcp snooping trust) so that SW1 will allow incoming DHCP messages from the DHCP server. Also, note that the switch need not trust its port G0/1 (connected to router R1) because there should be no messages from the DHCP server arriving in that port. However, were the DHCP Server somewhere in the network further to the right of router R1, then SW1 would need to trust port G0/1 for DHCP Snooping.
Now, consider the DAI configuration. To start, ask yourself: For which of switch SW1’s switch ports does it make sense to treat the port as trusted and untrusted for DAI? It turns out that you can choose which ports to trust with DAI based on two rules:
- Trust for DAI if trusted for DHCP Snooping.
- Trust for DAI if the attached device is not a DHCP Client (even if the port is untrusted for DHCP Snooping)
Applying those rules to configure this lab, you should:
- Make switch ports F0/2 and F0/3, the ports connected to the PCs, untrusted for DAI (the default setting)
- Make switch port F0/1, the port connected to the DHCP server, trusted for DAI (rule 1 above)
- Make switch port G0/1, the port connected to the router, trusted for DAI (rule 2 above)
Beyond those settings, DAI requires a single global configuration command to both enable the feature and enable it in a specific VLAN: ip arp inspection vlan 10 in this case.
Known Issues in this Lab
This section of each Config Lab Answers post hopes to help with those issues by listing any known issues with Packet Tracer related to this lab. In this case, the issues are:
| Number | Summary | Detail |
| 1 | Core feature config only | CPT supports the configuration of core DAI features, including all mentioned in this lab. However, the configuration support is limited. |
| 2 | DAI does not work as intended. | CPT does not filter ARP messages with DAI enabled. Therefore, when you enable DAI and follow testing steps to simulate an attack, DAI does not filter the messages. |
| 3 | Incorrect show ip dhcp snooping binding output | On real gear, this command displays the DHCP Snooping Binding Table. CPT sporadically displays correct table entries. |
| 4 | Sparse show ip dhcp snooping output | Real gear displays more detailed output as compared to CPT. |
| 5 | Incorrect show ip arp inspection output | Once configured, real gear shows the feature with a state of “active” in a VLAN. CPT shows “inactive.” |
| 6 | CPT feature platform differences | In CPT, the 2960 and 3650 switch models provide some DHCP Snooping support. However, the support levels differ, with some differences in show commands. In our testing, the feature could be configured on both models but only worked when using 2960s. |
Why Would Cisco Packet Tracer Have Issues?
(Note: The below text is the same in every Config Lab.)
Cisco Packet Tracer (CPT) simulates Cisco routers and switches. However, CPT does not run the same software that runs in real Cisco routers and switches. Instead, developers wrote CPT to predict the output a real router or switch would display given the same topology and configuration – but without performing all the same tasks, an actual device has to do. On a positive note, CPT requires far less CPU and RAM than a lab full of devices so that you can run CPT on your computer as an app. In addition, simulators like CPT help you learn about the Cisco router/switch user interface – the Command Line Interface (CLI) – without having to own real devices.
CPT can have issues compared to real devices because CPT does not run the same software as Cisco devices. CPT does not support all commands or parameters of a command. CPT may supply output from a command that differs in some ways from what an actual device would give. Those differences can be a problem for anyone learning networking technology because you may not have experience with that technology on real gear – so you may not notice the differences. So this section lists differences and issues that we have seen when using CPT to do this lab.
Beyond comparing your answers to this lab’s Answers post, you can test in Cisco Packet Tracer (CPT) or Cisco Modeling Labs (CML). In fact, you can and should explore the lab once configured. However, note that in CPT Version 8.0, which we used when creating this lab in 2021, CPT did not implement DAI verification commands very well. If using a later CPT version in later years, you may get better results. Regardless, you can try the various show commands in the list below:
- Display all DHCP Snooping settings and per-interface non-default settings: show ip dhcp snooping
- Display the DHCP Snooping Binding Table: show ip dhcp snooping binding
- Display subsets of information about DAI:
- show ip arp inspection
- show ip arp inspection interfaces
- show ip arp inspection statistics
Hello i think that SW1 config answer in line 3 should be:
no ip dhcp snooping information option
Henri,
You are correct! Fixed now. Thanks much,
Wendell
Hello,
Since we are talking about security I have two questions:
1) Some operating systems allow us to change the mac address, and if I well understood, DAI can detect that as explained in the Cert Guide Vol. 2 pg 159-160.
That means if we modify the host’s mac address, the mac address in the ethernet header or arp header (I don’t know which one will be changed) won’t match the hardware mac address and DAI will discard the frame.
Is what I am telling true or not?
2)If the answer of the question 1 is true:
If the DAI is not enable, all “switchport port-security” functionalities become deciduous for hackers.Because an attacker could use an allowed mac address to bypass the security rules.
True or not?
Thanks in advance.
Hi Edmund,
Taking your questions by number:
1: I haven’t tested that specific scenario. Let’s say in that scenario the user is legit. If they change the MAC and reboot, causing the switch port to go down, I believe then DHCP Snooping will remove its snooping binding table entry, when the PC comes up and DHCP leases the switch makes a new DHCP snooping binding entry. So DAI has a legit entry to use.
DAI is more about an attacker on a second port when stable on the first port, which isn’t the scenario you described. But taking your scenario literally, if changing the MAC on the PC left the switch port up, without testing it, I would guess DAI would stop the traffic sent by the PC with the new MAC address. HAven’t tested it, though.
2) I’d say no to that one. First, the attacker is unlikely to know your port security config. But if they did, the sequence would be to get access to a port in an office or cubicle. Then somehow discern which switch port it’s attached to. Only then could it take advantage of knowing the port security config (which is again unlikely). But yes, knowing the switch config, and connecting to a wall plate, knowing the switch port, you could connect with port security allowing the connection.
Then… not discussed in CCNA are other security measures. I’d suggest checking out 802.1X/EAP, which would then require authentication before the user could send any traffic past the switch. Or Software Defined Access (SDA), with the DNA Center Controller and ISE, which also requires authentication before the user can use the LAN and also dynamically assigns the user to a VLAN based on their login credentials.
Good questions, made me think!
By re-reading my questions, I noticed I did not explain very well the scenario, sorry…
Here is a more consistent scenario :
(legit user) Allowed PC1 with mac address AAAA:BBBB:0001 connected to a switch (F0/1) with
port-security activated for only this mac: AAAA:BBBB:0001
(hacker) Not allowed LAPTOP with mac address CAFE:CCCC:9999
If the hacker know the PC1’s mac address, he could :
1)Replace his own mac address (LAPTOP) with PC1’s mac address
In example with the following command in linux : “ifconfig ethX hw ether AAAA:BBBB:0001”
Now the hacker’s laptop has the mac address AAAA:BBBB:0001 and the switch cannot make the difference between PC1 and the LAPTOP because the only way to do that is by looking at the mac address.
2)The hacker sitting at the desk with the PC1 on it, UNPLUG the PC1’s RJ-45 connector and PUT it directly in his laptop.
It does not matter if the maximum allowed port is 1, because the allowed pc has been unplugged
and there is still only one device connected on the port (The LAPTOP with the allowed m/c).
The hacker don’t need to know the switch’s port-security configuration, because he is already
allowed to connect using the PC1’s mac address.
I have an option on my modem-router that allows to restrict the Internet access by filtering mac addresses. So I tested the scenario;
I change my PC’s mac address, ping my router and finally analyzed what’s happen with wireshark:
The src mac address has been change in the frame sent (ethernet II layer 2) and (ARP layer 3) , I was able to bypass my router’s security.
To come to the conclusion,I just wanted to know if a cisco switch port-security option is able to detect this trivial attack because maybe it looks directly at the real hardware mac address and if it’s not the case, can ARP Inspection tools or something else help to avoid this problem?
I know the question is out the scope of CCNA, but if we are sure that port-security could be easily bypassed, we have to be aware of that.
P.S. Concerning SDA – DNA, I just finished the book and I never listen about that so far, I think it’s a very interesting concept that make a lot of what we learn old-fashioned.
Thank you for your availability.
Hi Edmund,
Thanks, much clearer now.
On your #1, the attacker learns the MAC of the legitimate PC via some other means than knowing the switch config. Got it. So the short answer is yes, port security cannot help in that case. If the attacker uses that same MAC address and that same Ethernet port it appears to be the same device to port security. port security checks only the source MAC address of incoming frames.
To me, that means the attacker has access to the PC. There’s a whole other world of tools to protect access to the OS, to prevent someone with access to the OS from connecting to the network to use it, and so on. But Port Security isn’t the solution here.
I don’t think DHCP Snooping or DAI help in this case, either. Your starting point is an attacker on the same port as a legit PC using the same MAC as the legit PC. So they have physical access to the space and keyboard access to the OS so they can look around and learn things. So I still think your approach to the problem (ignoring CCNA scope) is about protecting access to the legit PC.
Hope this helps,
Wendell
PS SDA is cool. So is SD-WAN, ACI, all the software-defined options from Cisco. But you have to know the CCNA stuff to understand the more advanced things. EG, with SDA, there’s a underlay campus that, when installed by DNA-C, functions as a routed access layer. That alone requires half of what you learn in CCNA! Kudos to you for digging in and learning well.
Thanks for the answer, now it’s clear for me, port-security is a useful functionality but we have to pay attention for the case we mention earlier.
I used the word “hacker” for a general purpose, but sometime users can create security holes unintentionally, for example, a young employee that want to play games on Internet or something else using his own laptop because usually companies don’t allow users to install programs on the company’s pc or the pc is not enough powerful to make the job, etc …
Most of cases analyzed in the book are scenarios around a switch, meaning that the hacker is located inside the company.So we can’t exclude the fact, with a very low probability, that the hacker could be a big rat working for the company knowing his allowed mac address, but as you say : “There’s a whole other world of tools”.
I think we talk about security enough and I better focus on the CCNA exam, thanks for the blog, I really appreciate it and the books too.
Thank you Wendell, you are our superstar!
Hello everyone,
I had the same doubt, but I thought that dhcp snooping would be able to recognize a spoofed Mac-address attack by comparing the chaddr field with the source Mac address field and realize that they are different.
Daniel,
If 100% of the devices were DHCP clients, an approach using DHCP Snooping but no Port Security would work well. But there’s no way I know of to prevent someone from using a static address and other IP settings. But for what it does, indeed, it can check the CHADDR vs. the 802.3 header’s source MAC and react if they’re different.
You’re quite welcome, Edmond!
Hi Mr. Odom,
Referencing OCG Vol 2, page 161, Example 8-5.
On DAI, you wrote, “If you were to configure a switch only with commands shown in Example 8-5, the switch would filter all ARPs entering all untrusted ports in VLAN 11.”
The commands in Example 8-5 are as follows:
#ip arp inspection vlan 11
#interface GigabitEthernet1/0/2
#ip arp inspection trust
So, my question (my thought) is that without DHCP snooping and ARP ACLs, and when only the commands (stated above) are used, what would the switch compare the filtered ARPs to?
Azza
Hi Azza,
Thanks for the note.
I had to go back and read to get the context. And I see what’s probably confusing there.
So, what I mean is this:
Configure like Example 8-5 only, with no ARP ACL and no DHCP Snooping, and DAI filters all incoming ARPs on untrusted ports. The reason: There’s no table with which to find permissible entries, as you suggest in your question. So, DAI alone creates deny-all-ARP logic for untrusted ports.
Then, that sentence you quoted was meant to be a lead-in to suggest that you must also configure ARP ACLs or DHCP snooping, and here’s how to also config DHCP snooping in the scenario in the book, as per Example 8-6.
Hope this helps! Feel free to follow up.
Wendell
Hi Mr. Odom,
Referencing OCG Vol 1, page 566, Line 15.
You write, “The show ipv6 route command lists the link-local address of the neighboring router, rather than the global unicast or unique local unicast address.”
I tested the ‘show ipv6 route’ command in all it variations and it does not list the link-local address of the neighboring router.
However, my lab is in packet tracer and that might have something to do about it.
I have checked the errata file on the OCG Vol 1 “CCNA-200-301-Vol1-Errata-2023-02-01” and I could not find anything about this.
So, is the statement still correct that the ‘show ipv6 route’ command lists the link-local address of the neighboring router?
The following are the examples from my lab:
Router(config)#int g0/0/0
Router(config-if)#ipv6 add 2001:db8:1111:2::1/64
Router(config-if)#do sho ipv6 int bri
GigabitEthernet0/0/0 [up/up]
FE80::260:5CFF:FEB6:501
2001:DB8:1111:2::1
GigabitEthernet0/0/1 [administratively down/down]
unassigned
Router(config-if)#do sho ipv6 route
IPv6 Routing Table – 3 entries
! Legend omitted for brevity
C 2001:DB8:1111:2::/64 [0/0]
via GigabitEthernet0/0/0, directly connected
L 2001:DB8:1111:2::1/128 [0/0]
via GigabitEthernet0/0/0, receive
L FF00::/8 [0/0]
via Null0, receive
Router(config-if)#do sho ipv6 nei
IPv6 Address Age Link-layer Addr State Interface
2001:DB8:1111:2::2 7 00D0.BCA4.5A01 REACH Gig0/0/0
Router#sho ipv6 rou summar
IPv6 routing table name is default(0) global scope – 3 entries
IPv6 routing table default maximum-paths is 16
Route Source Networks Overhead Memory (bytes)
connected 1 88 124
local 2 176 248
Total 3 264 372
Number of prefixes:
/8: 1, /64: 1, /128: 1
Hi Azza,
Welcome to the site. I appreciate the Mr. Odom, but feel free to call me by my first name.
I think you’re missing some context, but FYI, the book is correct as is, and I think Packet Tracer works correctly as well on this point.
As for your question, I refer you back to the page, to the entire paragraph just above Figure 24-8 from which the sentence you quoted comes from. Couple of key facts from that:
– It mentions the next-hop address will be a link-local address (LLA).
– It mentions the show ipv6 route command.
– The one show ipv6 route command you listed in your post does not list a route that has a next-hop address field in it.
What routes have a next-hop address? Those that require the local router to forward packets to the neighboring router. For example, if your Packet Tracer topology had two routers in it (like the topology in Figure 24-8), and you enabled OSPFv3, R1 would learn a route for “Subnet 2” per the figure. that route would list R2’s LLA as the next hop address.
EG, add this to the routers:
ipv6 router ospf 1
router-id 1.1.1.1 (or 2.2.2.2, or 3.3.3.3, make them unique)
on each interface, add:
ipv6 ospf 1 area 0
Assuming you had already enabled IPv6 unicast routing, and had already configured correct global unicast addresses on the interfaces, then that additional configuration should make OSPF work. Then the routes learned by OSPF (which have a next-hop address value) will list the LLA of the neighboring router.
Hope this helps,
Wendell
Hello Wendell,
Thank you so much for your efforts in making this lab.
I just wanted to point out that the lab and the picture for it is slightly off. The lab has additional devices.
Thank you
You’re quite welcome, John. Thanks for the heads up.
Hi Wendell,
A quick doubt. If we use fixed IPs in our LAN devices instead of DHCP, we cannot use DAI feature, right? (Because DAI depends on DHCP snooping binding table).
Vicente,
DAI can can also use something called an ARP ACL, which provides matching logic for ARP messages independent of the DHCP process.
Hi Wendell – this is a general question. I’m getting stuck on the logic of DAI trust vs. not trusted settings on ports. Specifically, why do we want all non-DHCP clients to be trusted for DAI?
Hey Bill,
DAI is tricky. And discussing DAI while keeping it basic is challenging, too. So, to do that, the chapter discusses DAI with the DHCP Snooping Binding Table, but with only a bare mention of ARP ACLs. In short – and this is the key – for an untrusted port, the only way DAI approves of an ARP is if that host successfully used DHCP. With no DHCP Snooping table entry, no passing the DAI check. So any port connected to devices with static IP addresses, or to anything not a DHCP client, you need to trust.
In real life, this can be reasonably applied in most cases, particularly if the site follows a consistent plan for which ports connect to user devices and which don’t, rather than arbitrary choices for switch ports.
Hope this helps.
Wendell
Lovely lab, but i missed the port to the router for DAI Trust.
Can you please explain a bit deeper the concept that you mention in summary in Lab Comments “Trust for DAI if the attached device is not a DHCP Client (even if the port is untrusted for DHCP Snooping)”.
From the book the only explaination is “Make DAI trusted (rather than the default setting of untrusted) on select ports in those
VLANs, typically for the same ports you trusted for DHCP Snooping.”
Thanks, Eleftherios!
Let me start with a broad statement. The book covers the basics of DHCP Snooping and DAI. But when it comes to the engineering work to think and apply it to real networks, you need to go much deeper.
However, more to the point of this lab and your question…
We’re using DAI, and we’re using the DHCP Snooping Binding Table, with no ARP ACLs. So, if the port does not have DHCP Snooping enabled, the DHCP Snooping function cannot place an entry in the DHCP Snooping Binding Table for DAI to use. If you left such a port untrusted for DAI, DAI would be relying on an entry in the DHCP Snooping Binding table… but there would be no DHCP Snooping Binding table entry to match the ARP message and allow it through. So DAI would filter all ARP messages on such a port.
An example of that? Take an endpoint device that uses a static IP address. DHCP Snooping cannot learn from its DHCP messages as it doesn’t send any. So, knowing that, you trust for DHCP snooping. That’s where the broad statement you quoted from the book comes from.
hello,
if we do not trust g0/1 for dhcp snooping why do we trust it for dynamic arp?
arent the trust settings same for both ?
Yeah, it gets a little confusing.
If I had taken the time and space to make the design more typical, with access and distribution switches, and routers above the distribution switches, the DHCP and DAI trust logic would match better. In my attempt to keep the lab topology small, it raises this unusual case.
The logic is summarized in the middle of the lab commentary tab. Short version, DHCP Snooping on that switch port should not receive any messages from a DHCP server, so untrusted – which allows correct DHCP client messages – is good. But untrusted DAI means it would filter ARPs sent by the router, which would cause problems.