Что означает этот фиктивный маршрут (0 & 0x68 c8.c8.c8.c8 ...) в моей таблице маршрутизации?

4

Это свежо после перезагрузки в беспроводной сети, которая, как известно, немного ненадежна. Первая строка отличается от всего, что я видел раньше:

$ netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
0&0x68             c8.c8.c8.c8.c8.c8.c8.c8.c8.8.0.0.8.ff.ff.ff.0.0.0.68.80.0.5.14.4.0.f.1e.3.8.1.0.7.0.0.0.b.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7f.ff.ff.ff.0.0.0.0.a8.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.10.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.10.2.0.0.ac.13.80.1.4.0.0.0.0.0.0.0.0.0.0.0.80.0.5.14.4.0.f.1e.5.0.6.5.3.0.0.0.0.0.0.0.1.8.1.0.0.0.0.0.4.0.0.0.7f.ff.ff.ff.0.0.0.0.a8.5.0.0.0.0.0.0.20.7.10.51 USc             9        0     en0
default            172.19.128.1       UGSc           11        0     en0
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH              4      155     lo0
172.19.128/20      link#4             UCS             2        0     en0
172.19.128.1       0:b:86:61:f2:70    UHLWIir        12       14     en0   1177
172.19.129.189     127.0.0.1          UHS             0        0     lo0
172.19.143.255     ff:ff:ff:ff:ff:ff  UHLWbI          0        6     en0

Первая запись очень липкая; даже отказ от сетевого интерфейса не убивает его. Это не признается route delete. Мне нужно перезагрузить ОС, чтобы избавиться от нее. Это делает систему полностью непригодной для использования, так как вызывает сбой сетевых подключений:

$ telnet www.google.com 80
Trying 74.125.141.104...
telnet: connect to address 74.125.141.104: Cannot allocate memory
telnet: Unable to connect to remote host

Что здесь происходит, и как я могу это исправить, когда это происходит без перезагрузки?

архиепископ
источник
У пользователя Mike(см. Его комментарии к моему ответу) была похожая проблема, и он мог избавиться от фиктивного маршрута без перезагрузки, отключив IPv4, применив изменения и повторно включив его. Вы снова столкнулись с проблемой?
Jaume
@jaume К счастью для меня и к сожалению для StackExchange, я не испытывал это в последнее время.
архиепископ
Я рад за тебя. Если проблема возникнет снова, я был бы признателен, если бы вы попытались описать шаги в моем ответе и сообщили об этом.
Jaume

Ответы:

4

Хотя я не мог воспроизвести его на своем MacBook Pro (OS X 10.8.2), некоторые пользователи сообщали о похожем поведении, включая создание фиктивного маршрута:

Destination        Gateway            Flags        Refs      Use   Netif Expire
(...)
128.0&0x8600  ff.ff.ff.ff.0.0.0.0.0.0.0.0.5.ff.ff.ff.86.0.0.0.88.0.5.14.5.0.68.c.1.9.0.0.7.0. 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7f.ff.ff.ff.0.0.0.0.dc.5.0.0.0.0.0.0.8d.c.5a .4f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. 0.0.10.2.0.0.a9.fe.0.0.0.0.0.0.0.0.0.0.14.12.5.0.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 .6.ff.ff.ff.ff.ff.0.0.7c.0.5.14.1.0.68.c.7.8.0.0.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 .0.0.0.0.7f.ff.ff.ff.0.0.0.0.0.40.0.0.0.0.0.0.0.0.0.0.0.c0.0.0.0.c0.0.0.0.0.0.0. 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.10.2.0.0.ac.1c.84 USc             0        4     en0

при переводе компьютера в спящий режим при использовании VPN-подключения по WiFi. Это не похоже на ваш случай, так как вы видите такой маршрут сразу после запуска вашего Mac.

Я не могу сказать вам, что здесь происходит, но в ссылке выше есть сообщение, в котором упоминается, что это можно исправить без перезагрузки, например:

Выключение tcp / ip и включение его снова работает как шарм.

Если вы хотите попробовать, откройте «Системные настройки», выберите панель «Сеть» и, если необходимо, щелкните значок блокировки, чтобы внести изменения:

введите описание изображения здесь

Выберите ваше открытое соединение из списка слева (Ethernet или WiFi), нажмите кнопку Advanced..., выберите вкладку TCP / IP, установите для параметра «Настройка IPv4» значение «Выкл.»:

введите описание изображения здесь

и подтвердите нажатием OK. Верните TCP / IP к исходным настройкам.

Надеюсь, это поможет.

Жауме
источник
Спасибо! Эта проблема временная, но в следующий раз, когда я это замечу, я попробую это и посмотрю, поможет ли это.
архиепископ
Будем надеяться, это поможет. Не могли бы вы отчитаться после тестирования? Мне тоже любопытно ...
Jaume
Мне тоже любопытно. Кажется, я получаю это только в некоторых случаях и только когда я использую VPN-клиент Juniper Network Connect.
Майк
@Mike: Спасибо за ваш комментарий. Если вы можете проверить это, я буду признателен за любые отзывы.
Jaume
@jaume - я снова столкнулся с этой проблемой, и она разрешилась с помощью предложенных вами шагов - я отключил IPv4 на обоих моих активных интерфейсах (wifi и eth), применил изменения, затем снова включил их, и фиктивный маршрут исчез. Спасибо!
Майк
1

Чтобы устранить проблему из командной строки или удаленно:

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"

Это отключает IPv4 на интерфейсе с неверным маршрутом и повторно включает DHCP. Для введенных вручную IP-адресов:

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"

Для получения полной информации о том, что делает, что и почему я использую этот конкретный код: http://briancanfixit.blogspot.com/2014/05/fix-juniper-network-connect-on-mac-bad.html

BrianCanFixIT
источник
0

Знать о поле: Netif ,

отключение соответствующего интерфейса в соответствии с Netif для очистки недопустимых маршрутов. (например, на моей MacBookPro Retina en0 - это Wi-Fi)

Билл Чунг
источник