I ran into an interesting client behavior issues with several Apple Macbook Air Laptops today at work. I was able to solve the mystery, but thought I would post my findings as I just confirmed it in the home lab with my wife's computer.
Observed behavior:
Mac OS X clients running 10.9.1 using a DHCP address require the DNS Server to be configured in order for the default route to take affect. Without the default route, off-network traffic receives a "no route to host" error.
Now the network engineers at work were mocking up was an isolated network with no DNS or internet access. As far as I can tell
Scenario:
Catalyst 3750 acting as a L3 switch and doing DHCP for local VLANs.
DHCP Configuration:
ip dhcp pool ClientTest
network 192.168.145.0 255.255.255.0
default-router 192.168.145.1
Vlan Configuration:
interface Vlan145
ip address 192.168.145.1 255.255.255.0
For this scenario, I am using a Flexconnect AP with the SSID dropping off to vlan 145. Also I am using a server upstream to ping. I haven't had a chance to verify that this works with other vendors, but I would guess it does. Assume that routing is working (as it is). The production scenario was with a 4500, with local mode APs, and the results were the same.
Now for the client. My client in this case is a 2012 MBA running 10.9.1.
Here is my ifconfig output:
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 28:37:xx:xx:xx:xx
inet6 fe80::3 prefixlen 64 scopeid 0x4
inet 192.168.145.2 netmask 0xffffff00 broadcast 192.168.145.255
nd6 options=1<PERFORMNUD>
media: autoselect
status: active
Now lets see if we can ping the default gateway:
Valeries-MacBook-Air:~ valeriesnyder$ ping 192.168.145.1
PING 192.168.145.1 (192.168.145.1): 56 data bytes
64 bytes from 192.168.145.1: icmp_seq=0 ttl=255 time=3.185 ms
64 bytes from 192.168.145.1: icmp_seq=1 ttl=255 time=3.030 ms
c64 bytes from 192.168.145.1: icmp_seq=2 ttl=255 time=5.038 ms
Success. Now lets ping my server upstream from the lab:
Valeries-MacBook-Air:~ valeriesnyder$ ping 10.200.20.20
PING 10.200.20.20 (10.200.20.20): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
Request timeout for icmp_seq 0
ping: sendto: No route to host
Request timeout for icmp_seq 1
ping: sendto: No route to host
Request timeout for icmp_seq 2
Hmm, this should work. I verify in the network control panel that I have the 192.168.145.1 as the default router. There's no reason I *shouldn't* be able to ping the server. Except that I'm not passing the DNS Server through the DHCP server.
Lets change the DHCP server configuration to the following:
ip dhcp pool Test
network 192.168.145.0 255.255.255.0
default-router 192.168.145.1
dns-server 1.1.1.1
In this example, i'm using 1.1.1.1 which is a totally bogus DNS server. It doesn't need to work in order to get routing to work on the MBA.
Same SSID, just the DNS-Server change.
Here is the relavent ifconfig output:
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 28:37:xx:xx:xx:xx
inet6 fe80::3 prefixlen 64 scopeid 0x4
inet 192.168.145.2 netmask 0xffffff00 broadcast 192.168.145.255
nd6 options=1<PERFORMNUD>
media: autoselect
status: active
Now skipping straight to pinging outside the local subnet we find that it works, just by adding the DNS-Server
Valeries-MacBook-Air:~ valeriesnyder$ ping 10.200.20.20
PING 10.200.20.20 (10.200.20.20): 56 data bytes
64 bytes from 10.200.20.20: icmp_seq=0 ttl=124 time=8.056 ms
64 bytes from 10.200.20.20: icmp_seq=1 ttl=124 time=2.113 ms
64 bytes from 10.200.20.20: icmp_seq=2 ttl=124 time=3.217 ms
I have no idea why this client behavior occurs, or if it intentional. I was able to replicate the behavior with a Win2k8r2 dhcp server and an IP Helper.
*Note that Windows populates a DNS Server of 127.0.0.1 if you do not specify a DNS server.
You *MUST* delete this option in order to replicate the behavior.
Further Testing:
Configuring the IP address of the client manually without a DNS server configured exhibits the same behavior.
Conclusion:
Mac OS X Mavericks (10.9.1) requires a DNS Server defined in order to use the configured default route.
