|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Eugene B. Berdnikov 2:5020/400 14 Aug 2005 17:08:03
To : Sergey Velikanov
Subject : Re: poptop и неправильные ответы на arp запросы
--------------------------------------------------------------------------------
Sergey Velikanov <sv@intelsoft.com> wrote:
>> Это уже интереснее. Proxyarp действительно не срабатывает. Hо.
>> Выявились некоторые косяки, которые при первом взгляде я пропустил:
>>
>> 1. У eth0 юникастовый адрес 192.168.10.254 совпадает с бродкастовым.
>> Hехорошо. В принципе линукс работает в такой ситуации, и даже
>> более правильно, чем винда, но лучше бродкаст сделать другим -
>> 192.168.10.255 или 255.255.255.255. Подозреваю, в конфиге опечатка.
SV>
SV> да это опечатка, кстати а почему iproute2 не вычисляет броакаст сам?
В смысле - почему не ставит верхний адрес подсети в качестве бродкаста?
Hе знаю. Пакет iproute2 писался А.Кузнецовым в те времена, когда в умах
сетевиков уже прочно сидел CIDR, а деление на классы сетей A/B/C/D/Е
считалось архаизмом. В принципе традиция связывать верхний адрес подсети
с бродкастом есть именно традиция, и нет серьёзных технологических причин
делать ip-адрес бродкастовых пакетов уникальным внутри одного сегмента.
Я знаю примеры, когда на разных узлах бродкасты сконфигурены, скажем,
в 192.168.10.255, 192.168.10.127, 255.255.255.255 и даже 0.0.0.0, но
хосты прекрасно между собой общаются. :) Такая же ситуация имеется
с малтикастами - обычно достаточно правильного dst_mac на L2-уровне.
Похоже, ANK решил (совершенно справедливо), что содержимое dst_ip в
бродкастовых пакетах абсолютно безразлично большинству сервисов, и
оставил его по дефолту нулевым. Поэтому, если поднять интерфейс через
ip link, то ifconfig покажет у него бродкаст 0.0.0.0, и я не встречал
с этим проблем.
При этом в iproute, однако, была сохранена традиция при установке адреса
(или при подъёме интерфейса) создавать два бродкастовых маршрута - на
верхний и нижний адреса подсети. Они помещаются в таблицу local.
SV> после того как я поставил all.proxy_arp =0, у меня прекратился тот косяк
SV> когда мой рутер захватывал мак адреса, и вроде все работает.
ОК.
SV> 9: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1446 qdisc pfifo_fast qlen
SV> 3
SV> link/ppp
SV> inet 192.168.250.1 peer 192.168.10.201/32 scope global ppp0
SV>
SV> # arp -a
SV> ? (192.168.10.1) at 00:0D:93:47:60:0E [ether] on eth0
SV> ? (192.168.10.201) at * PERM PUP on eth0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Вот это и есть правильно сработавший proxyarp в ppp, с точностью
до PUP<->PUB. Hаверное, был посмертный глюк забитого бага... ;) :))
Интересно только, была ли причина проблемы в назначении бродкаста или же
в совпадении локального адреса ppp-интерфейса с адресом на eth0.
--
Eugene Berdnikov
--- ifmail v.2.15dev5.3
* Origin: Institute for High Energy Physics, Protvino, Russia (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
