I swear this sub interface used to give out addresses from this pool without issue. Something got wrecked though.
Here's the interface + sub interface config:
interface GigabitEthernet1/3 description SonosDirectConnectionPort no nameif no security-level no ip address interface GigabitEthernet1/3.103 description VLAN103_Sonos vlan 103 nameif insideSonos security-level 50 ip address 10.100.100.1 255.255.255.0
Here's the pertinent dhcp config:
dhcpd address 10.100.100.3-10.100.100.25 insideSonos dhcpd dns isp.dns.1 isp.dns.2 interface insideSonos dhcpd lease 604800 interface insideSonos dhcpd enable insideSonos
Trial and error previously led me to think it was necessary to disable call-home to get dhcpd to work properly, not 100% convinced this is necessary now. Related to this had executed:
no service call-home clear configure call-home
The physical port here will have a dumb switch wired-in so not 100% this NAT config is necessary either. Had configured:
object network Sonos subnet 10.100.100.0 255.255.255.0 object network Sonos nat (insideSonos,outside) dynamic interface
Finally, had defined catch-all ACL for the interface via access-group:
access-list ForVLAN103 line 1 extended permit ip any any access-group ForVLAN103 in interface insideSonos
Whether via link runner, client directly wired into port 1/3, or dumb switch wired into port 1/3 — clients do not get a DHCP address. tcpdump on wired-in client shows no inbound bootpc/DHCP frames whatsoever...despite the outbound discover frames from 0.0.0.0 ==> 255.255.255.255.
dhcpd state appears correct:
asa5506x# show dhcpd state Context Configured as DHCP Server . . . Interface insideSonos, Configured for DHCP SERVER
dhcp statistics are very uninteresting. dhcpd bindings...well there simply aren't any.
Necessary DHCP processes appear to be running on the ASA:
asa5506x# show processes | include dhcp Mwe 0x000055e7be3f66a4 0x00007fa6569cadb8 0x000055e7c5bb4060 47 0x00007fa6569c3030 30896/32768 dhcp_daemon 223 asa5506x# show processes | include DHCP Msi 0x000055e7be4193b2 0x00007fa6569d5e38 0x000055e7c5bb4060 14 0x00007fa6569ce030 31776/32768 DHCPRA Monitor 222 Mwe 0x000055e7be3f198c 0x00007fa6569e0ec8 0x000055e7c5bb4060 9 0x00007fa6569d9030 31872/32768 DHCPD Timer 221 Msi 0x000055e7be41ac85 0x00007fa65768ae98 0x000055e7c5bb4060 8 0x00007fa657683030 30128/32768 DHCP Network Scope Monitor 75
I think I'm executing a packet-tracer that should shed light on the behavior:
asa5506x(config)# packet-tracer input insideSonos udp 0.0.0.0 bootpc 255.255.2$ Phase: 1 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 255.255.255.255 using egress ifc identity Phase: 2 Type: ACCESS-LIST Subtype: Result: DROP Config: Implicit Rule Additional Information: Result: input-interface: insideSonos input-status: up input-line-status: up output-interface: NP Identity Ifc Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule
Please correct me if this syntax is not useful here.
Scratching my head.
Not sure why clients can't get an address.
What did I configure incorrectly?
your configuration looks fine. it could be your dump switch is playing up. make sure the dump switch to firewall and from your pc to dump switch are in correct order (cabling etc).
what this command show you
show interface GigabitEthernet1/3
Sheraz was on the right track. The dumb switch attached to 1/3 couldn't do VLAN tagging nor could any direct connected wired clients.
So I changed the config to drop VLAN103 and assign the IP directly to the 1/3 interface.
Everything working smoothly now.