Сеть 169.254.0.0 - что это?

[Geo]

 В таблице маршрутизации (просмотр: route -n) имеется маршрут к сети 169.254.0.0.
Что это за сеть, какая программа его вставляет в таблицу и для чего использует?
Пользователь решил продолжить мысль 19 Апреля 2009, 05:10:17: Нашел в Гугле:

Сеть эта нужна для Automatic Private IP Addressing(APIPA) - службы для обеспечения работы локальной сети в случае, когда нет сервера DHCP.
Отключить ея можно внся в /etc/sysconfig/network-scripts/ifcfg-eth? строку :
Код
NOZEROCONF=yes

Отсюда вопрос - надо ли это если IP статический?
Как отключить в Ubuntu, если директории /etc/sysconfig нет?
Пользователь решил продолжить мысль 19 Апреля 2009, 07:36:23:
И еще:

При построении (проектировании) внутренней IP-сети при выборе диапазонов статических адресов (либо диапазонов для выделения адресов DHCP-серверами) следует придерживаться рекомендаций RFC3330, в соответствии с которыми для использования во внутренних сетях зарезервированы следующие диапазоны адресов, установленные RFC1918:
10.0.0.0/8 (10.0.0.0-10.255.255.255); 1 сеть класса A
172.16.0.0/12 (172.16.0.0-172.31.255.255); 16 сетей класса B
192.168.0.0/16 (192.168.0.0-192.168.255.255); 256 сетей класса C
Согласно документу, данные диапазоны адресов не должны появляться в Интернете. В соответствии с RFC3330 любой маршрутизатор в Интернете, обнаружив IP-пакет с адресом из указанного диапазона (неважно, источник или приёмник), обязан его уничтожить.
Кроме того, есть ещё два зарезервированных диапазона адресов, однако они используются для специальных целей и не рекомендуются для прямого присвоения:
192.0.2.0/24 (192.0.2.0-192.0.2.255); 1 сеть класса C
169.254.0.0/16 (169.254.0.0-169.254.255.255); 256 сетей класса C
Первый диапазон (сеть) описывается как тестовый. Он должен использоваться в документации и примерах кода, где часто ассоциирован с доменными именами example.com и example.net.
Второй диапазон описан как "link local" - он используется для протокола автоматического присвоения адреса (APIPA, Automatic Private IP Adressing), то есть для самостоятельного присвоения рабочей станцией самой себе IP-адреса, если тот не указан в настройке протокола и не может быть получен с сервера DHCP (из-за его отсутствия или неработоспособности), в т.ч. при соединении двух компьютеров напрямую. Заманчивость использования этого диапазона адресов (особенно на DHCP-серверах) перечёркивается тем, что на самом деле диапазон состоит из 256 сетей класса C, более того, согласно протоколу APIPA присвоение адреса происходит по возможности в сети, которая отсутствует в ЛВС.
Не рекомендуется пытаться обойти это ограничение расширением маски сети, поскольку далеко не каждый аппаратный или программный маршрутизатор (в том числе сервер) способен понять и обработать такое отступление от правил. В худшем случае оборудование может вообще прекратить работать, и его придётся перегружать.
При необходимости Вы можете делить любую сеть из указанных диапазонов на подсети маской подсети, однако при этом не используйте первую и особенно последнюю из получившихся сетей, только те, что в середине. Эффект может быть такой же, как описан в предыдущем абзаце, однако может быть и хуже - в сети в случайные моменты начнут появляться непонятные и невоспроизводимые проблемы любого рода, недиагностируемые обычными средствами, - ужас любого системного администратора.

Еще из Гугла

169.254.0.0/16 Применяется для динамической конфигурации хоста, когда хост должен получить адрес по DHCP, но сервер недоступен после 3 запросов, хост автоматически присваевает себе адрес с этого диапозона, перебирая по одному, до тех пор пока небудет найден свободный. Подробнее можно глянуть RFC 3927

Пользователь решил продолжить мысль 19 Апреля 2009, 15:29:43: В скрипте /etc/network/if-up.d/avahi-autoipd закомментил строки, записывающие соответствующий роут:

# if [ -x /bin/ip ]; then
#    # route already present?
#    ip route show | grep -q '^169.254.0.0/16[[:space:]]' && exit 0
#
#    /bin/ip route add 169.254.0.0/16 dev $IFACE metric 1000 scope link
# elif [ -x /sbin/route ]; then
#    # route already present?
#    /sbin/route -n | egrep -q "^169.254.0.0[[:space:]]" && exit 0
#
#    /sbin/route add -net 169.254.0.0 netmask 255.255.0.0 dev $IFACE metric 1000
# fi

После перезагрузки, запись в таблице роутов больше не появляется.

[Geo]

 Вернул на место файл avahi-autoipd с раскомментированными строками.
Но соответствующая строчка в роутах так и не появилась.

Что бы это значило???

Неужели пингвин растоптал свое яйцо?

[kostryukov]

Неужели пингвин растоптал свое яйцо?

скорее ты раздавил это яйцо своими ручками )))

[sht0rm]

Geo
Проблема то в чем?

[lockie]

какая программа его вставляет в таблицу

Демон avahi.

Отсюда вопрос - надо ли это если IP статический?

Скорее нет, чем да. Гуглите mDNS/DNS-SD и думайте, надо оно вам или нет

Как отключить в Ubuntu, если директории /etc/sysconfig нет?

Удалить /etc/rc2.d/avahi*

[Geo]

 А почему оно не вернулось после восстановления соответствующих настроек?

Ведь это плохой признак. Значит какие-то функции не имеют обратного хода.

Из опыта моей работы могу сказать, что такого рода признаки в работе сложных систем всегда приводят к потере устойчивости.

Для lockie.
 Если восстановлен файл, из которого avahi берет настройки, а строки в роутах не появляются - значит не avahi туда их вставляет.

[kostryukov]

у нас в сети принято отключать этот демон(avahi), ибо изза него днски сетевые не работают
отключить - система / администрирование / службы / avahi

[Geo]

Цитата из http://silverghost.org.ua/tag/linux/

И все таки я дождался момента, когда сервак начал дико глючить и увидел заветную надпись “Neighbour table overflow“. Ковыряние Гугла показало, что проблема с размером таблиц кеша ARP. Увеличение ее до 10000 ничего не дало...
Дальнейшее ковыряние Гугла навело на мысль о том, что сервак находится под атакой вирусняка из внутренней сети. Послушав tcpdump’ом поочереди внутренние интерфейсы выявил нехорошую активность. Но, что самое странное, эта активность была связана с сетью 169.254.0.0/16, т.е. с сетью, которая в принципе у меня не должна быть. При чем сервак сам упорно опрашивал по ARP все IP в этой подсети, т.е. фактически сам себе устроил arpflood и DoS в одном лице.

Таблица роутнига указала на один из внутренних VLANов, где и был обнаружен этот флуд. В принципе все уже было понятно, кроме одного: откуда эта сетка взялась? Оказывается в RedHat-like ОСях это фича ядра. Т.е. этот маршрут удалить нельзя через ip route. Был найден другой путь - во всех конфигах интерфейсов была добавлена строчка:

    NOZEROCONF=yes

После рестарта сети маршрут с сетью 169.254.0.0 удалился и флуд закончился. Сервер продолжил работать как часы, оставив после этой проблемы вопросы:

   1. Нафига принудительно пихать мне сеть, которая мне 300 лет не нужна?
   2. Почему до определенного момента все работало и флуда не было?

Сейчас вот проверил на своем серваке. В Убунте нет такого маршрута. В очередной раз убедился, что не зря перелез на нее с Федоры.

Никого не наводит на мысль, что это может быть дыра?

[Tokh]

Может быть. С точки зрения того, что можно заставить работать сервер не так как рассчитывал настроивший систему. Как настроить.

Только человек-то пишет, что в Ubuntu у него "из коробки" этой сети небыло. А у меня она почему-то была. Удалить заветный маршрут через ip он не смог, а я могу. Вместо лечения болезни (источник флуда) он отчитывается о ликвидации симптомов (отключил ZeroConf).

Насколько я смутно помню, начинать поиск можно с "Что такое Zeroconf?". Всплывёт тема Plug and Play для сетевых устройств.

P.S. В тему дырок. Программы могут откликаться на входящие соединения с IPv6 адресами. IPv6 поддержка включена в Ubuntu, но я думаю, что при составлении правил фаервола и настройке сервера далеко не все об думают. Кто-то не думает про Zeroconf. А кто-то даже не проверят сервер, на предмет того, что там было предустановлено...

[Geo]

 Вот и меня это озадачило, тем более, что все попытки отключить этот маршрут стандартными средствами ни к чему не приводили.
Из за этого и начал флудить...
Может есть какой-то более корректный способ отключать/включать эту сеть, чем нашел я?

Тем более, что после отключения через изменения в avahi-autoipd стали недоступными виндовые машины в сети. Пришлось ручками и с бубном.

[Br[angel]]

 Я пробовал удалить этот маршрут по описанию --> http://ubuntuforums.org/showpost.php?p=4501018&postcount=5

1. I disabled network manager applet from sessions and from starting up at boot
2. I edited /etc/networks file and comment out: link-local 169.254.0.0

I rebooted and now all of the "dhcdbd: message_handler:" error messages are gone, along with former network error messages normally found in daemon.log.

3. sudo route del -net 169.254.0.0 netmask 255.255.0.0 dev eth0

169.254.0.0 was removed from the routing table but it reappeared on reboot! So I decided to poke around a bit, and:

4. Remove/purged the following: libnss-mdns avahi-autoipd avahi-daemon
5. sudo route del -net 169.254.0.0 netmask 255.255.0.0 dev eth0 (probably not required now after #4 though)
6. Rebooted (yes, I could've restarted networking but I wanted to reboot to satisfy my curious nature)
7. route -n reveals 169.254.0.0 is now GONE!
8. Stand up and DANCE!

 И ничего у меня не вышло )) Как маршрут был,так и остался.Тут /etc/network/if-up.d/ & /etc/network/if-down.d  ничего не трогал, т.к Geo писал , что манипуляции с avahi-autoipd не имеют обратного хода:

 

А почему оно не вернулось после восстановления соответствующих настроек?

Ведь это плохой признак. Значит какие-то функции не имеют обратного хода.

Из опыта моей работы могу сказать, что такого рода признаки в работе сложных систем всегда приводят к потере устойчивости.

 upd:все-таки удалил avahi-autoipd и avahi-daemon из /etc/network/if-up.d/ & /etc/network/if-down.d
 маршрут исчез.