Jump to content
Калькуляторы

RB2011UiAS у некоторых клиентов пропадает интернет DHCP+MAC, ARP satatic

Доброго времени суток, с недавних пор появилась такая плавающая проблема, пропадает доступ к интернету у пользователей. В разное время, на разный промежуток времени, у разных абонентов. От 1го человека до 5-10, из разных сегментов сети. При этом на микротике машины пользователей видны.

Либо само проходит, либо делаю перезагрузку роутеру и все работает, может каждый день глючить, а может пару дней, а то и неделю без происшествий. Раньше стоял RB750, RB2011 работает около 5ти месяцев, глюки постепенно начались где то месяц назад, не могу разобраться в чем проблема.

Иногда бывало не пускало нового клиента в интернет из за ARP static, удалял запись и добавлял заново, все ок. Может ли ARP таблицу глючить?

Share this post


Link to post
Share on other sites

Скорее всего сеть глючит, нужно проверить трафик на портах через Torch, посмотреть сколько маков на портах и т.п. Бывает клиентские роутеры глючат и флудят в сеть.

Share this post


Link to post
Share on other sites

Прошлая проблема решилась(периодически адрес шлюза занимался).

Сейчас похожая проблема, но не такая маштабная. Пропадает доступ в интернет у 1-2 разных клиентов, некоторым не везет чаще, пропадает через день, протяженностью от часа до целого дня. Одновременно отваливаются 1-2х. При этом в DHCP клиент виден как подключенный, пинг до него идет, при подключение нашего ноута к его кабелю, все работает. Через Torch от клиента идет трафик(много запросов 50-80) с маленьким объемом.

В какую сторону смотреть/копать? Зарание спасибо.

Share this post


Link to post
Share on other sites

Скорее всего сеть глючит, нужно проверить трафик на портах через Torch, посмотреть сколько маков на портах и т.п. Бывает клиентские роутеры глючат и флудят в сеть.

Тут еще такое дело. Все сеть на WiFi, проводных участков в процентном соотношении по абонентам 24% представляют из себя 1 неупровляемый коммутаор, все проводные сети агрегируются по радио, при этом везде стоят не управляемые мыльницы. Это получается цепочка из мыльныц?

При дальнейшем росте сети, глюков еще больше будет? Ставить на БС управляемые коммутаторы?

Достут сейчас по статическому DHCP с привязкой мак-IP, и симпатической ARP. Доступ тоже переделывать тогда прийдется?

Share this post


Link to post
Share on other sites

Это же Микротик.

Нужно сбросить на заводские настройки, настроить заново и больше никогда не трогать.

Если с первого раза не получится, повторить еще несколько раз.

Share this post


Link to post
Share on other sites

Это же Микротик.

Нужно сбросить на заводские настройки, настроить заново и больше никогда не трогать.

Если с первого раза не получится, повторить еще несколько раз.

то есть никогда не трогать? А абонентов добавлять, включать, отключать? Конфиг с настройками после сброса залить прокатит?

Share this post


Link to post
Share on other sites

Это же Микротик.

Нужно сбросить на заводские настройки, настроить заново и больше никогда не трогать.

Если с первого раза не получится, повторить еще несколько раз.

то есть никогда не трогать? А абонентов добавлять, включать, отключать? Конфиг с настройками после сброса залить прокатит?

Так и есть. Микротик настривается сразу и больше лучше не трогать, постоянные смены/обновления конфига приводят к "подземным стукам"

 

Вот лог из микротика, что за ошибка?

В арп таблице уже есть такой мак/айпи.

Share this post


Link to post
Share on other sites

Это же Микротик.

Нужно сбросить на заводские настройки, настроить заново и больше никогда не трогать.

Если с первого раза не получится, повторить еще несколько раз.

то есть никогда не трогать? А абонентов добавлять, включать, отключать? Конфиг с настройками после сброса залить прокатит?

Так и есть. Микротик настривается сразу и больше лучше не трогать, постоянные смены/обновления конфига приводят к "подземным стукам"

Выходит, при глюках его сбрасывать, заливать конфиг и так до следующих глюков?

Вот лог из микротика, что за ошибка?

В арп таблице уже есть такой мак/айпи.

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

Share this post


Link to post
Share on other sites

Это же Микротик.

Нужно сбросить на заводские настройки, настроить заново и больше никогда не трогать.

Если с первого раза не получится, повторить еще несколько раз.

то есть никогда не трогать? А абонентов добавлять, включать, отключать? Конфиг с настройками после сброса залить прокатит?

Так и есть. Микротик настривается сразу и больше лучше не трогать, постоянные смены/обновления конфига приводят к "подземным стукам"

Выходит, при глюках его сбрасывать, заливать конфиг и так до следующих глюков?

Вот лог из микротика, что за ошибка?

В арп таблице уже есть такой мак/айпи.

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

Я поступаю так. Настроил, погонял, если глюков не выявилось то бэкаплю конфиг и больше не трогаю.

Share this post


Link to post
Share on other sites

Тут еще такое дело. Все сеть на WiFi, проводных участков в процентном соотношении по абонентам 24% представляют из себя 1 неупровляемый коммутаор, все проводные сети агрегируются по радио, при этом везде стоят не управляемые мыльницы. Это получается цепочка из мыльныц?

При дальнейшем росте сети, глюков еще больше будет? Ставить на БС управляемые коммутаторы?

Достут сейчас по статическому DHCP с привязкой мак-IP, и симпатической ARP. Доступ тоже переделывать тогда прийдется?

 

Вам надо просто поставить несколько микротиков и разделить ими сеть на сегменты, управляемые коммутаторы не нужны. Если сеть так и будет не управляемая, переходите на PPPoE, с ним нет никаких проблем. С микротиков по EoIP будете гнать данные в центр.

 

Сейчас схема с привязкой по маку уже устаревшая, чем раньше начнете перевод, тем проще он произойдет.

Share this post


Link to post
Share on other sites

переходите на PPPoE

ПППоЕ не хочу... Соседи были на ПППоЕ, перешли на Виланы. Но там конфиг сети проще, каждый юзер=убик, убики в режим роутера и все.

Share this post


Link to post
Share on other sites

ПППоЕ не хочу... Соседи были на ПППоЕ, перешли на Виланы. Но там конфиг сети проще, каждый юзер=убик, убики в режим роутера и все.

 

Убнт плохо дружит с PPPoE.

 

Вообще такая схема в радио даже проще - адрес точки = адрес клиента, не нужно пробрасывать никаких вланов и т.п. Клиент может подключиться в любом месте сети и работать. Соответственно 80 процентов радиосетей работают на PPPoE.

Share this post


Link to post
Share on other sites

такая схема в радио даже проще - адрес точки = адрес клиента

ПППоЕ?

 

Конечно. Смотрите сами - в центре PPPoE сервер, на него любыми способами (вланы, EoIP, MPLS и т.п.) сводите данные от баз. При этом на базах бриджуете только беспроводной интерфейс и туннель, то есть данные абонентов за сетевой порт в чистом виде не попадают. Сами же абоненты ничего не видят, кроме мака базы (и то можно скрыть) и мака PPPoE сервера. Трафик между абонентами заблокирован.

 

Соответственно в центре вы видите всех клиентов в списке соседей, обычно в identity клиентов вписывают их логины, поэтому в случае, когда клиент по какой-то причине не устанавливает PPPoE соединение, можно найти его по логину и зайти по мак-телнет для проверки настроек.

 

Кроме всего, клиенты могут подключаться откуда угодно, то есть легко можно перевести клиента с базы на базу, а если везде одинаковый SSID, то в случае проблем, они могут и на другую зацепиться в аварийном режиме. Еще один плюс - выдача преднастроенных антенн, которые клиент устанавливает самостоятельно, по лампочкам (такое хорошо работает на малых расстояниях от БС).

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.