Ask Different is a question and answer site for power users of Apple hardware and software. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This is fresh after a reboot, on a wireless network which is known to be a little flaky. The first line is unlike anything I've seen before:

$ netstat -rn
Routing tables

Destination        Gateway            Flags        Refs      Use   Netif Expire
0&0x68             c8.c8.c8.c8.c8.c8.c8.c8.c8.8.0 USc             9        0     en0
default         UGSc           11        0     en0
127                UCS             0        0     lo0          UH              4      155     lo0
172.19.128/20      link#4             UCS             2        0     en0       0:b:86:61:f2:70    UHLWIir        12       14     en0   1177          UHS             0        0     lo0     ff:ff:ff:ff:ff:ff  UHLWbI          0        6     en0

The first entry is very sticky; even taking down the network interface doesn't kill it. It isn't recognized by route delete. I need to restart the OS to get rid of it. It makes the system entirely unusable, since it causes network connections to fail:

$ telnet 80
telnet: connect to address Cannot allocate memory
telnet: Unable to connect to remote host

What's going on here, and how can I fix it when it happens without a reboot?

share|improve this question
User Mike (see his comments on my answer) had a similar problem and could get rid of the bogus route without a reboot by disabling IPv4, applying changes and re-enabling it. Have you experienced the problem again? – jaume Mar 12 '13 at 10:01
@jaume Fortunately for me and unfortunately for StackExchange, I have not experienced it recently. – archbishop Mar 13 '13 at 14:35
I'm happy for you. Should the problem appear again, I'd appreciate if you gave the steps in my answer a try and reported back. – jaume Mar 13 '13 at 16:19

Although I couldn't reproduce it on my MacBook Pro (OS X 10.8.2), some users have reported a similar behavior, including the creation of a bogus route:

Destination        Gateway            Flags        Refs      Use   Netif Expire
128.0&0x8600  ff.ff.ff.ff. .4f. .6.ff.ff.ff.ff.ff.0.0.7c. . USc             0        4     en0

when putting the computer to sleep while using a VPN connection over WiFi. This doesn't seem to be your case, as you see such a route right after starting your Mac.

I can't tell you what's going wrong here, but there is a post in the link above that mentions that it could be fixed without a reboot like this:

Turning off tcp/ip and turning it back on worked like a charm.

If you want to give it a try, open System Preferences, select the Network pane and, if necessary, click the lock icon to make changes:

enter image description here

Select your open connection from the list on the left hand side (Ethernet or WiFi), press the button Advanced..., select the TCP/IP tab, set Configure IPv4 to Off:

enter image description here

and confirm by pressing OK. Set TCP/IP back to its original setting.

Hope it helps.

share|improve this answer
Thanks! This problem is intermittent, but next time I notice it, I'll try this and see if it helps. – archbishop Feb 5 '13 at 19:14
Let's hope it helps. Could you report back after testing? I'm curious too... – jaume Feb 6 '13 at 7:59
I'm also curious. I only seem to get this on some occasions, and only when I'm running Juniper's Network Connect VPN client. – Mike Mar 4 '13 at 10:55
@Mike: Thanks for your comment. If you can test it I'd appreciate any feedback. – jaume Mar 4 '13 at 12:37
@jaume - I encountered this problem again, and it resolved using the steps you suggested - I disabled IPv4 on both of my active interfaces (wifi and eth), applied the changes, then re-enabled them and the bogus route disappeared. Thanks! – Mike Mar 12 '13 at 9:41

To fix the issue from the command line, or remotely:

interfacetofix=`netstat -r -f inet | grep "0&" | awk '{print $NF}'`
interfacenametofix=`networksetup -listnetworkserviceorder | grep "$interfacetofix" -B1 | tail -2 | head -1 | cut -d " " -f 2-10`
networksetup -setv4off "$interfacenametofix"; networksetup -setdhcp "$interfacenametofix"

This disables IPv4 on the interface with the bad route and re-enables DHCP. For manually entered IP addresses:

interfacetofix=`netstat -r -f inet | grep "0&" | awk '{print $NF}'`
interfacenametofix=`networksetup -listnetworkserviceorder | grep "$interfacetofix" -B1 | tail -2 | head -1 | cut -d " " -f 2-10`
interfaceIP=`networksetup -getinfo "$interfacenametofix" | grep "^IP address:" | awk '{print $NF}'`
interfaceSubnet=`networksetup -getinfo "$interfacenametofix" | grep "Subnet mask:" | awk '{print $NF}'`
interfaceRouter=`networksetup -getinfo "$interfacenametofix" | grep "^Router:" | awk '{print $NF}'`
networksetup -setv4off "$interfacenametofix"; networksetup -setmanual "$interfacenametofix" "$interfaceIP" "$interfaceSubnet" "$interfaceRouter"

For full details on what does what and why I use this specific code:

share|improve this answer

Be aware of the field: Netif,

disabling the proper interface according to Netif to clean up the invalid routes. (e.g., on my MacBookPro Retina, en0 is wi-fi)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.