Old Catalyst: DHCP times out with LACP enabled

There's a dusty old Catalyst¹ in my lab that's causing a a server boot/provisioning problem, but only when LACP is enabled.

The port configuration looks like this:

interface FastEthernet0/28 switchport trunk native vlan 20 switchport trunk allowed vlan 20,400 switchport mode trunk switchport nonegotiate channel-group 5 mode active spanning-tree portfast trunk ip dhcp snooping vlan 20 information option format-type circuit-id string <something> 

LACP is enabled, but the client isn't talking LACP (yet). I'm counting on the port to run in (I)individual mode while server provisioning is underway.

With this configuration in place, untagged DHCP DISCOVER messages are lost for a while after the interface comes up. Here's an example timeline merged together from a few sources:

DEBUG 12:23:11.776 %LINK-3-UPDOWN: Interface FastEthernet0/28, changed state to up PCAP 12:23:12.553 DHCP DISCOVER copied to SPAN port (dropped) CLI 12:23:14.351 'show spanning-tree vlan 20' does not mention Fa0/28 PCAP 12:23:16.524 DHCP DISCOVER copied to SPAN port (dropped) CLI 12:23:17.102 'show spanning-tree vlan 20' does not mention Fa0/28 CLI 12:23:18.981 'show spanning-tree vlan 20' does not mention Fa0/28 CLI 12:23:20.181 'show spanning-tree vlan 20' reports: "Fa0/28 Desg FWD 200000 128.28 P2p Edge" DEBUG 12:23:20.298 Created spanning tree port Fa0/28 (33E86FC) for tree MST0 (39AF5C4) DEBUG 12:23:20.298 Enabling spanning tree port: FastEthernet0/28 (33E86FC) DEBUG 12:23:20.298 Enabling spanning tree port: FastEthernet0/28 (33E8528) DEBUG 12:23:20.332 Returning spanning tree port stats: FastEthernet0/28 (33E8528) LOG 12:23:21.305 %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/28, changed state to up DEBUG 12:23:24.493 DHCPSNOOP(hlfm_set_if_input): Setting if_input to Fa0/28 for pak. Was not set DEBUG 12:23:24.493 DHCP_SNOOPING: received new DHCP packet from input interface (FastEthernet0/28) PCAP 12:23:24.524 DISCOVER forwarded toward relay with Option 82 data included 

Each case where a DHCP DISCOVER message is "dropped", it indicates that the SPAN session on Fa0/28 saw the packet, but the uplink SPAN, DHCP snooping process, DHCP relay and DHCP server did not see the packet.

If I remove the channel-group directive from the port, things work the way you'd expect: No DHCP discover messages are dropped.

The problem here is that one of my DHCP clients isn't willing to wait 10+ seconds for a DHCP reply. It sends 4 DISCOVER messages with 1, 2 and 4 second delays between (7 seconds altogether) before it gives up.

Anybody seen this behavior before? Have ideas about how I might speed up the port's transition from "link up" to "STP forwarding"?

I can probably work around the problem by customizing the client, but that's a can of worms I'd prefer not to open.

[1] WS-C2960-48TT-L running 12.2(44)SE5