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.