ARP-флуд hotspot, батареи мобильников, таблица устройств.. На кой это все?!

[KorDen]

Все меньше перестаю понимать смысл дефолтных настроек и нововведений. В основном претензии направлены к авто-сканированию по ARP, выжирающему батарейки мобильных устройств, и все ради чего?

Ради того, чтобы быстро показывать, какое устройство отключилось, а какое подключилось в вебморде? Зачем?! Основная масса пользователей видела вебморду один раз при настройке (если, очень вероятно, не просили кого-то настроить), затем они зачастую даже не знают как на нее зайти! Но даже если пользователь заходит на морду - зачем слать эти запросы бесконечно в остальное время?

Поясните мне этот тайный смысл. Что там такого собираетесь добавить, что это является неотложной необходимостью? Мельком уже по постам читается какое-то подобие IP-MAC Binding и слежение за MAC-адресами.. Но опять, зачем ради этого сканировать сеть, ведь достаточно просто следить за ARP-таблицей, которая сама построится при активности клиента?

 

Касательно фразы "влияние на батарейки мобильников незначительное" - так оно все незначительное, условно: отрубил автосканирование, плюс 2% за ночь, поигрался с rekey-interval - плюс еще 2%, и так далее... И телефон уже живет гораздо дольше.

 

Собственно предложение: переделать логику автосканирования на более толерантную или вообще обдумать, а нужно ли оно?

Изменено 14 февраля, 2017 пользователем KorDen

[ndm]

В 2/14/2017 в 23:15, Le ecureuil сказал:

идеи рассмотрим и подумаем что реально можно сделать

@KorDen см. версию 2.09.A.3.0-4.

[IgaX]

1 час назад, Le ecureuil сказал:

Предлагайте варианты

если обнаруженный хост опрашивается с помощью unicast arp, то остальное все настраивается .. м.б. для удобства большинства сделать готовые пресеты для выбора путем комбобокса в web.

но по мне лучше добавить возможность устанавливать дефолтный dtimperiod для wifimaster (м.б. в будущем позволят и для каждого ssid отдельно, чтобы сегментировать подключения по классу беспроводных устройств и в зависимости от этого устанавливать dtim).

и плюс к дефолтному dtimperiod возможность менять его при помощи расписания .. скажем, если в основном мобильные клиенты, то дефолтный ставим в районе 4, а по расписанию на ночь ставить, например, dtim 100, чтобы устройства раз в 10 сек снимали для себя информацию из буфера AP .. так будет больше похоже на реализацию сна у мобильных клиентов с вытекающей оптимизацией использования аккумулятора.

в любом случае, с dtim придется экспериментировать для оптимума, чтобы мобильные приложения работали ожидаемо.

[Le ecureuil]

В 2/25/2017 в 22:42, demos.vlz сказал:

@ndmв журнале изменений  2.09.A.3.0-5 сказано:  оптимизирован discovery: не рассылаем broadcast по Wi-Fi для неизвестных хостов

На Гига 3  2.09.A.3.0-6 по Wireshark вижу такое. Известен только 192.168.1.251 - подключенный по проводу свич. Это нормально?

вижу

Да, это нормально.

Подобные пакеты отмечаются особой маркой, и сам WiFi драйвер их внутри себя уничтожает, не давая им вылетать в воздух. При этом в захвате они видны. Так сделано специально, чтобы при отправке на bridge пакеты уходили на провод нормально, а воздух их резал, независимо от того, кто и в каком объеме включен в bridge.

Попробуйте захватить эфир WiFi, и вы увидите, что их там нет.

[Le ecureuil]

49 минут назад, KorDen сказал:

Поясните мне этот тайный смысл. Что там такого собираетесь добавить, что это является неотложной необходимостью? Мельком уже по постам читается какое-то подобие IP-MAC Binding и слежение за MAC-адресами.. Но опять, зачем ради этого сканировать сеть, ведь достаточно просто следить за ARP-таблицей, которая сама построится при активности клиента?

Уже сто раз обсуждалось.

Этого в целом недостаточно, потому что у клиентов может быть не прописан default route, они могут быть забиты статикой, они могут вообще не ходить в Интернет. А отображать их всех нужно.

Насчет более толерантной логики сканирования - вот тут можно подумать. Предлагайте варианты.

[r13]

20 минут назад, Le ecureuil сказал:

А отображать их всех нужно.

Для чего?

[Le ecureuil]

1 час назад, r13 сказал:

Для чего?

Такое техническое задание. Исчерпывающе, не так ли?

[r13]

5 минут назад, Le ecureuil сказал:

Такое техническое задание. Исчерпывающе, не так ли?

Угу 

[IgaX]

и м.б. кнопочку добавить для быстрого сканирования (кому для удобства нужно сразу)  .. да и вопросов меньше будет.

[IgaX]

и заодно возможность устанавливать отдельные настройки autoscan для любого соответствующего интерфейса и чтобы можно было менять на кастомные по расписанию (например, через cli, чтобы web-gui не перегружать) - так сказать, на упреждение любой вариант, который может понадобиться для гибкости.

не знаю что еще придумать

[KorDen]

7 часов назад, Le ecureuil сказал:

Насчет более толерантной логики сканирования - вот тут можно подумать. Предлагайте варианты.

Скажем, для начала, не опрашивать постоянно воздух, ведь есть информация подключенных к WiFi устройств. Понятно, что это не покроет все варианты спама по воздуху, например подключение через отдельную точку доступа, но сильно его уменьшит КМК. Если на WiFi есть неопознанное устройство, (не запросило IP, не появилось в ARP) - прогнать один-два раза скан и через воздух.

Плюс добавить опцию включения-выключения сканированив я свойства сегмента или даже на страницу устройств, типа галки "Автоматическое обнаружение устройств в фоновом режиме", с возможными пояснениями.

[Le ecureuil]

30 минут назад, KorDen сказал:

Скажем, для начала, не опрашивать постоянно воздух, ведь есть информация подключенных к WiFi устройств. Понятно, что это не покроет все варианты спама по воздуху, например подключение через отдельную точку доступа, но сильно его уменьшит КМК. Если на WiFi есть неопознанное устройство, (не запросило IP, не появилось в ARP) - прогнать один-два раза скан и через воздух.

Плюс добавить опцию включения-выключения сканированив я свойства сегмента или даже на страницу устройств, типа галки "Автоматическое обнаружение устройств в фоновом режиме", с возможными пояснениями.

Спасибо за конструктивные идеи, подумаем, поэкспериментируем.

Мы на самом деле готовы заняться оптимизацией расхода батареи и использования ресурса радиоканала при discovery, и любые (возможно даже кажущиеся бредовыми) идеи рассмотрим и подумаем что реально можно сделать. Так что чем больше предложите, тем лучше.

Пока у нас в 2.09 в рамках активной альфа-разработки на это есть время.

[KorDen]

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

[Le ecureuil]

Да, это только первый этап - самое (по нашему мнению) безболезненное.

Постараемся в каждой новой сборке оптимизировать сильнее по мере возможности.

[demos.vlz]

В 18.02.2017 в 10:04, ndm сказал:

@KorDen см. версию 2.09.A.3.0-4.

@ndmв журнале изменений  2.09.A.3.0-5 сказано:  оптимизирован discovery: не рассылаем broadcast по Wi-Fi для неизвестных хостов

На Гига 3  2.09.A.3.0-6 по Wireshark вижу такое. Известен только 192.168.1.251 - подключенный по проводу свич. Это нормально?

вижу

Изменено 25 февраля, 2017 пользователем demos.vlz

[Le ecureuil]

В 2/14/2017 в 16:50, IgaX сказал:

если обнаруженный хост опрашивается с помощью unicast arp, то остальное все настраивается .. м.б. для удобства большинства сделать готовые пресеты для выбора путем комбобокса в web.

но по мне лучше добавить возможность устанавливать дефолтный dtimperiod для wifimaster (м.б. в будущем позволят и для каждого ssid отдельно, чтобы сегментировать подключения по классу беспроводных устройств и в зависимости от этого устанавливать dtim).

и плюс к дефолтному dtimperiod возможность менять его при помощи расписания .. скажем, если в основном мобильные клиенты, то дефолтный ставим в районе 4, а по расписанию на ночь ставить, например, dtim 100, чтобы устройства раз в 10 сек снимали для себя информацию из буфера AP .. так будет больше похоже на реализацию сна у мобильных клиентов с вытекающей оптимизацией использования аккумулятора.

в любом случае, с dtim придется экспериментировать для оптимума, чтобы мобильные приложения работали ожидаемо.

Unicast ARP хоть и стандартизован, но многими антивирусами и IDS воспринимается как "атака" или "подозрительная активность", потому сразу нет.

[Le ecureuil]

Еще какие-либо идеи есть?

[IgaX]

24 минуты назад, Le ecureuil сказал:

Unicast ARP хоть и стандартизован, но многими антивирусами и IDS воспринимается как "атака" или "подозрительная активность", потому сразу нет.

М.б. все же сделать опционально. Т.к. тогда вопросы к многими антивирусами и IDS.

http://serverfault.com/a/409891 (See RFC1122, section 2.3.2.1 - ARP Cache Validation)

Цитата

(2) Unicast Poll -- Actively poll the remote host by periodically sending a point-to-point ARP Request to it, and delete the entry if no ARP Reply is received from N successive polls. Again, the timeout should be on the order of a minute, and typically N is 2.

Плюс, опять же - это нормальное поведение, даже я это вижу с отключенным сканером и никакой ругани:

Скрытый текст

И некоторые комментарии:
https://supportforums.cisco.com/discussion/11416946/arp-cache-timeout-cisco-routers
https://supportforums.cisco.com/discussion/10901751/router-arp-request-unicast

32 минуты назад, Le ecureuil сказал:

Еще какие-либо идеи есть?

Если предложение выше не пройдет, то, по возможности, чтобы записи статики ip arp (если намертво прибиваются в кэш) не опрашивались сканером в private и не только .. в отношении public бы тоже не хотелось (м.б. опционально, если специально для чего-то еще используется), но там м.б. proxy arp жарит.

В общем, если есть ip arp, то в отношении этих записей не делать валидацию кэша. Это нормальная практика, в т.ч. с позиции безопасности (чтобы не отсвечивать лишний раз), чтобы нормальные ids в т.ч. среагировали на появление arp-a, когда его быть не должно.

[IgaX]

7 часов назад, IgaX сказал:

В общем, если есть ip arp, то в отношении этих записей не делать валидацию кэша

Если понадобится - например, пруф.

Скрытый текст

...

There are static ARP cache entries and dynamic ARP cache entries. Static entries are manually configured and kept in the cache table on a permanent basis. They are best for devices that have to communicate with other devices usually in the same network on a regular basis. Dynamic entries are added by the Cisco IOS software and kept for a period of time, then removed.

Static and Dynamic Entries in the ARP Cache

Static routing requires an administrator to manually enter IP addresses, subnet masks, gateways, and corresponding MAC addresses for each interface of each router into a table. Static routing enables more control but requires more work to maintain the table. The table must be updated each time routes are added or changed.

Dynamic routing uses protocols that enable the routers in a network to exchange routing table information with each other. The table is built and changed automatically. No administrative tasks are needed unless a time limit is added, so dynamic routing is more efficient than static routing. The default time limit is 4 hours. If the network has a great many routes that are added and deleted from the cache, the time limit should be adjusted.

The routing protocols that dynamic routing uses to learn routes, such as distance-vector and link-state, is beyond the scope of this document. For more information, refer to Cisco IOS IP Routing Protocols Configuration Guide , Release 12.4.

...

Defining Static ARP Entries

Perform this task to define static mapping between IP addresses (32-bit address) and a MAC address (48-bit address) for hosts that do not support dynamic ARP. Because most hosts support dynamic address resolution, defining static ARP cache entries is usually not required. Performing this task installs a permanent entry in the ARP cache that never times out. The entries remain in the ARP table until they are removed using the no arp command or the clear arp interface command for each interface.

 

[Le ecureuil]

9 часов назад, IgaX сказал:

Если понадобится - например, пруф.

  Показать содержимое

...

There are static ARP cache entries and dynamic ARP cache entries. Static entries are manually configured and kept in the cache table on a permanent basis. They are best for devices that have to communicate with other devices usually in the same network on a regular basis. Dynamic entries are added by the Cisco IOS software and kept for a period of time, then removed.

Static and Dynamic Entries in the ARP Cache

Static routing requires an administrator to manually enter IP addresses, subnet masks, gateways, and corresponding MAC addresses for each interface of each router into a table. Static routing enables more control but requires more work to maintain the table. The table must be updated each time routes are added or changed.

Dynamic routing uses protocols that enable the routers in a network to exchange routing table information with each other. The table is built and changed automatically. No administrative tasks are needed unless a time limit is added, so dynamic routing is more efficient than static routing. The default time limit is 4 hours. If the network has a great many routes that are added and deleted from the cache, the time limit should be adjusted.

The routing protocols that dynamic routing uses to learn routes, such as distance-vector and link-state, is beyond the scope of this document. For more information, refer to Cisco IOS IP Routing Protocols Configuration Guide , Release 12.4.

...

Defining Static ARP Entries

Perform this task to define static mapping between IP addresses (32-bit address) and a MAC address (48-bit address) for hosts that do not support dynamic ARP. Because most hosts support dynamic address resolution, defining static ARP cache entries is usually not required. Performing this task installs a permanent entry in the ARP cache that never times out. The entries remain in the ARP table until they are removed using the no arp command or the clear arp interface command for each interface.

 

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

[vasek00]

В 14.02.2017 в 14:31, KorDen сказал:

Ради того, чтобы быстро показывать, какое устройство отключилось, а какое подключилось в вебморде? Зачем?! Основная масса пользователей видела вебморду один раз при настройке (если, очень вероятно, не просили кого-то настроить), затем они зачастую даже не знают как на нее зайти! Но даже если пользователь заходит на морду - зачем слать эти запросы бесконечно в остальное время?

Согласен

Le ecureuil

Этого в целом недостаточно, потому что у клиентов может быть не прописан default route, они могут быть забиты статикой, они могут вообще не ходить в Интернет. А отображать их всех нужно.

В таком случае мы не сможем достоверно определить в сети ли хост, или просто статически забит в кэш и при этом в оффлайне.

На странице home.bridges прописываем "Адрес шлюза" получили default route для клиента, ну забит он статикой и что с этого? Не ходят в интернет но первое что сделает клиент например Windows проверит шлюз (ARP запросом на то что прописано в свойствах сетевой). 

Или жестко ответ - "для реализации конфликтов IP адресов".

[IgaX]

16 минут назад, Le ecureuil сказал:

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

поэтому и "опционально"  .. чтобы опцией могли воспользоваться те, кто сознательно готов пожертвовать этой информацией.

может, тогда возможность крутить таймаут записей кэша для разных интерфейсов (независимо от рефрешера ip hotspot auto-scan interval {time} и ip hotspot auto-scan timeout {time}) .. и проблему на public.

Скрытый текст

An implementation of the Address Resolution Protocol (ARP) [LINK:2] MUST provide a mechanism to flush out-of-date cache entries. If this mechanism involves a timeout, it SHOULD be possible to configure the timeout value.

...

(1) Timeout -- Periodically time out cache entries, even if they are in use. Note that this timeout should be restarted when the cache entry is "refreshed" (by observing the source fields, regardless of target address, of an ARP broadcast from the system in question). For proxy ARP situations, the timeout needs to be on the order of a minute.

 

[Le ecureuil]

1 час назад, vasek00 сказал:

Согласен

Le ecureuil

На странице home.bridges прописываем "Адрес шлюза" получили default route для клиента, ну забит он статикой и что с этого? Не ходят в интернет но первое что сделает клиент например Windows проверит шлюз (ARP запросом на то что прописано в свойствах сетевой). 

Или жестко ответ - "для реализации конфликтов IP адресов".

Не у всех и не везде винда. Например IP-камеры, NAS, и много устройств IoT не делают никаких проверок, потому нам нужно выявлять их и конфликты с ними самостоятельно.

[Le ecureuil]

1 час назад, IgaX сказал:

поэтому и "опционально"  .. чтобы опцией могли воспользоваться те, кто сознательно готов пожертвовать этой информацией.

может, тогда возможность крутить таймаут записей кэша для разных интерфейсов (независимо от рефрешера ip hotspot auto-scan interval {time} и ip hotspot auto-scan timeout {time}) .. и проблему на public.

  Показать содержимое

An implementation of the Address Resolution Protocol (ARP) [LINK:2] MUST provide a mechanism to flush out-of-date cache entries. If this mechanism involves a timeout, it SHOULD be possible to configure the timeout value.

...

(1) Timeout -- Periodically time out cache entries, even if they are in use. Note that this timeout should be restarted when the cache entry is "refreshed" (by observing the source fields, regardless of target address, of an ARP broadcast from the system in question). For proxy ARP situations, the timeout needs to be on the order of a minute.

 

Давайте пока без новых команд или изменения поведения уже существующих. Это конечно возможно, но не так просто как вы думаете.

[vasek00]

46 минут назад, Le ecureuil сказал:

Не у всех и не везде винда. Например IP-камеры, NAS, и много устройств IoT не делают никаких проверок, потому нам нужно выявлять их и конфликты с ними самостоятельно.

Есть и IP камеры 4шт. wi-fi + 2 LAN камеры и NAS в этой же сети. Все устройства привязка к MAC и раздача им интернета. Вопрос о каком конфликте может идти речь, стоят уж не помню сколько времени прошли этапы роутеров giga c v1, KII c 2.04 до 2.09 кроме бзика с не восстановлением wi-fi (на 2.х) не чего не было и то все решилось. На ПК прописана статика, Аndroid на полном DHCP. В WEB смотрится ну раз в неделю.

 

Изменено 17 марта, 2017 пользователем vasek00

[IgaX]

3 часа назад, Le ecureuil сказал:

Это конечно возможно, но не так просто как вы думаете

Хоть не "потому сразу нет"

Вселяет оптимизм

[Le ecureuil]

9 часов назад, vasek00 сказал:

Есть и IP камеры 4шт. wi-fi + 2 LAN камеры и NAS в этой же сети. Все устройства привязка к MAC и раздача им интернета. Вопрос о каком конфликте может идти речь, стоят уж не помню сколько времени прошли этапы роутеров giga c v1, KII c 2.04 до 2.09 кроме бзика с не восстановлением wi-fi (на 2.х) не чего не было и то все решилось. На ПК прописана статика, Аndroid на полном DHCP. В WEB смотрится ну раз в неделю.

 

Вы описываете свой частный случай, и не пытаетесь думать сразу о всех вариантах, в том числе о малограмотных пользователях (учитывая, что эта фича должна работать у всех по-умолчанию, мы обязаны думать о них даже больше).

[vasek00]

Как же не думаем, только одно стремление к лучшему из того что есть. Только вот данная фитча есть во всех моделях ценовой категории, а может лучше разделить эту ценовую нишу - типа для простого пользователя и для продвинутого. Но такое вряд ли возможно, так как вступает уже маркетинг, хотя кол-во продаж наверное роутеров от 4000р. и выше намного ниже кол-ва продаж до 4000р.

Изменено 18 марта, 2017 пользователем vasek00

[r13]

1 час назад, vasek00 сказал:

Как же не думаем, только одно стремление к лучшему из того что есть. Только вот данная фитча есть во всех моделях ценовой категории, а может лучше разделить эту ценовую нишу - типа для простого пользователя и для продвинутого. Но такое вряд ли возможно, так как вступает уже маркетинг, хотя кол-во продаж наверное роутеров от 4000р. и выше намного ниже кол-ва продаж до 4000р.

Да какая разница в какой ценовой категории, главное что кому надо ее можно отключить! 

[vasek00]

2 часа назад, r13 сказал:

Да какая разница в какой ценовой категории, главное что кому надо ее можно отключить! 

Научите данного пользователя про которого сказал Le ecureuil ранее постом выше через WEB ее отключить, если он даже не знает что она есть. 

[r13]

1 час назад, vasek00 сказал:

Научите данного пользователя про которого сказал Le ecureuil ранее постом выше через WEB ее отключить, если он даже не знает что она есть. 

Так это и не для него. Ему все это arp по боку. Интернет есть, вконтактик работает и слава богу