Existing configuration (snippets):
vlan 81 name untrusted-no-outbound by port tagged ethe 3/1/6 untagged ethe 1/1/6 ip access-group untrusted-no-outbound in interface ve 81 ip address 192.168.81.2/24 ip helper-address 1 192.168.120.2 ip helper-address 2 192.168.120.3 ip access-list extended untrusted-no-outbound sequence 10 permit tcp any 192.168.88.0/24 established sequence 20 permit icmp any any sequence 50 permit udp any host 192.168.255.1 eq ntp sequence 70 deny tcp any 192.168.0.0/16 sequence 80 deny udp any 192.168.0.0/16
With this configuration in place, the devices attached to 1/1/6 and 3/1/6 were able to send DHCP requests (and obtain addresses) via VLAN 81.
I added port 4/1/1 (also tagged) to VLAN 81, but the device attached that port was unable to get an address via DHCP. Setting up a monitor on port 4/1/1 showed the DHCP 'discover' arriving (with VLAN id 81) from the device, but it was not forwarded to the ip-helper addresses attached to 'interface ve 81'.
Removing the 'ip access-group' from 'vlan 81' and then re-adding it cured the problem; traffic from port 4/1/1 on vlan 81 began flowing. It appears that adding the port to the VLAN, with an existing access-group, did not result in the access-group's rules being applied to that port.
I added another rule to that access-list today, and again it was not applied to the port I was using to test. It appears that this is a more pervasive problem than what I originally thought. I had to remove and re-apply the access-group to get traffic flowing via the new rule I had added.