Мониторинг сети (клиентов) на втором уровне

Привяжи у клиентов IP к мак адресу

Зачем, задача поставлена так, что хотелось бы отказаться от ip.

>отказаться от ip.

отказаться от сетевого протокола?

если вы так хотите, то да. Я же ясно написал, что мониторинг хочется осуществлять на 2м уровне, а там нет ни ip протокола, ни пакетов, если я правильно всё помню.

> Есть куча клиентов, множество клиентов могут быть в одно vlan. Они «ходят» в

интернет через pppoe. То есть потребности в ip-адресе у них нет.

Да ладно !? Как это нет ? :-)
Надо учить матчасть...

pppoe концентраторы обычно при авторизации умеют отдавать на радиус номер влана с которого идет подключение, вот и пишите его в какую-нибудь базу. По start/stop/update accounting в базу можно писать время и количество байт. Останется токо к этой базе веб морду приделать для отображения кол-ва народу на вланах, трафику, фазы луны и т.п. Графики, имхо, проще всего через rrdgraph_libdbi приделать.

> Да ладно !? Как это нет ? :-)

Надо учить матчасть...

В локальном ip-адресе смысла нет, при чём тут матчасть - не понял, pppoe ведь работает на кадрах?

pppoe концентраторы обычно при авторизации умеют отдавать на радиус номер влана с которого идет подключение, вот и пишите его в какую-нибудь базу. По start/stop/update accounting в базу можно писать время и количество байт. Останется токо к этой базе веб морду приделать для отображения кол-ва народу на вланах, трафику, фазы луны и т.п. Графики, имхо, проще всего через rrdgraph_libdbi приделать.

Обсчёт трафика меня не интересует, и через radius-сервер, этого лучше вообще не делать. Видимо я не очень хорошо описал проблему. Интересует то, чем можно проверить находится клиент в сети или нет, интересует физический линк с клиентом. Может, что то типа arping или чего-другого.

>> Да ладно !? Как это нет ? :-)

Надо учить матчасть...

В локальном ip-адресе смысла нет, при чём тут матчасть - не понял,

pppoe ведь работает на кадрах?

Хосты куда отвечать-то будут ? На деревню дедушке ? Unnumbered на ppp-концентраторе может быть, и есть, как правило, но у клиента обязательно есть <IP>/32.

Интересует то, чем можно проверить находится клиент в сети или нет

и этим, в том числе, занимается Radius-сервер. Правда не всегда может. Тут уже нюансы. А проверять надо сессии на pppoe-концентраторе. Есть сессия - есть клиент, нет сессии - нет клиента.

>Хосты куда отвечать-то будут ? На деревню дедушке ? Unnumbered на ppp-концентраторе может быть, и есть, как правило, но у клиента обязательно есть <IP>/32.

А адрес у клиента появляется когда? Когда у него активна pppoe сессия или нет? Для приёмов\отсылки PADO\PADI запросов не нужны никакие ip-адреса, о чём я вам и толкую. А если у клиента нет сессии, это ещё не значит, что его нет впринципе, может погорел порт на коммутаторе, к которому подцеплен клиент. И вот такие случаи и надо мониторить. Только вот проблема в том, что на домах за оптикой зачастую ставится неуправляемая железка, то есть можно, что либо увидеть только на свиче агрегации.

Если клиент вам позвонит и скажет, что у него подключение pppoe не осуществляется, что вы будете делать в случае, если у клиента нет явного локального ip-адреса и если у вас сеть построена не по принципу vlan на клиента?

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

На радиус также отдается client-endpoint, если pppoe, то это мак сетевой абонента. Пишите эти маки в базу. Потом скриптом мониторьте наличие этих маков на свичах агрегации.

Если клиент вам позвонит и скажет, что у него подключение pppoe не осуществляется, что вы будете делать в случае, если у клиента нет явного локального ip-адреса и если у вас сеть построена не по принципу vlan на клиента?

Улыбаться и рассказывать как прекрасно, что инет поломался, зрение портится не будет :)

>На радиус также отдается client-endpoint, если pppoe, то это мак сетевой абонента. Пишите эти маки в базу. Потом скриптом мониторьте наличие этих маков на свичах агрегации.

Так оно и работает, радиус работает на rlm_python, в котором записывается в БД Calling-Station-Id, причём, скрипт работает так, что клиент с другим значение данного параметра просто не сможеть авторизоваться. То есть мак абонента есть. Да, на свиче агрегации наличие мака смотреть можно. Но хотелось бы узнать, может есть готовые для этого решения для этого? Насколько я помню мак не исчезает из таблицы на коммутаторе, если у клиента проблема на линии.

> Для приёмов\отсылки PADO\PADI запросов не нужны никакие ip-адреса, о чём я вам и толкую

А, так хочется процесс подключения видеть ?

Если клиент вам позвонит и скажет, что у него подключение pppoe не осуществляется, что вы будете делать в случае,

если у клиента нет явного локального ip-адреса и если у вас сеть построена не по принципу vlan на клиента?

Строить надо правильно. :-) Без всяких «зачастую ставится неуправляемая железка». У нас, в самом худшем случае, D-Link DES-2108.

> Насколько я помню мак не исчезает из таблицы на коммутаторе, если у клиента проблема на линии.

Смотря какие проблемы. Если пакеты от него идут, не исчезает. Если пакеты пропадут, то исчезнет через какое-то время. Если не исчезнет - это,скорее, баг, чем фича.

>А если у клиента нет сессии, это ещё не значит, что его нет впринципе, может погорел порт на коммутаторе, к которому подцеплен клиент. И вот такие случаи и надо мониторить.

Не прошло и суток как вопрос условно сформулирован. Вариант - собирать таблицы mac для каждого из портов в дистрибуте. Где-то lldp/cdp помогут.

что вы будете делать в случае, если у клиента нет явного локального ip-адреса и если у вас сеть построена не по принципу vlan на клиента?

Я бы сделал сеппуку за pppoe в сети с такими бродкастами.

Всем спасибо за ответы, в итоге понял, как лучше сделать. Остановлюсь на таблице маков на свичах агрегации. А насчёт правильного построения сетей - это вопрос философский. Можно ведь не стоять у истоков, а прийти туда, где уже было, а перестройка сети вещь не из дешёвых :).

> Остановлюсь на таблице маков на свичах агрегации.

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

Так оно, но это уже можно будет посмотреть tcpdump'ом, наверное.