[Ivan Rostovikov]

Добрый день.

Вот такая задача требует решения:

Есть сеть провайдера. Древовидная структура. Все коммутаторы управляемые.

 

Коренной коммутатор. От него с разных портов - уровень агрегации,еще несколько коммутаторов.

с каждого свича агрегации еще по 100-200 портов на свичи доступа.

Свичи доступа часто включены друг в друга по цепочке (2-4 свича).

 

В общем стандартное "дерево".

Состав свичей (особенно доступа) постоянно меняется. Каждый день добавления, замены и т.д.

Сеть большая. PPPoE. Все свичи управляются через менеджмент вланы.

Абонент может подключиться с любого порта.

При подключении абонента известен его мак адрес (биллинг получает от BRAS)

Задача состоит в том, что бы узнать адрес свича доступа и номер порта с которого подключен абонент.

Т.е. начиная с самого "верха дерева" нужно проследить все таблицы FDB и дойти до конечного свича и конечного порта.

IP Ареса всех свичей в принципе известны но привязать к портам - нереально.

Есть идеи как реализовать такой скрипт ?

[pliskinsad]

PPPoE Circuit ID http://forum.nag.ru/forum/index.php?showtopic=41007

+ Еще к cacti есть плагин mactrack : http://docs.cacti.net/plugin:mactrack‎

Edited July 8, 2013 by pliskinsad

[secandr]

Есть замечательная штука - mac notification. Коммутатор при появлении в fdb нового мака отсылает трап. Включаете это дело на клиентских портах и радуетесь.

[sexst]

Mac notification. Если свитчей не особенно много, то можно часто драть полную fdb таблицу сети по snmp.

[zstas]

да зачем огород городить, если свичи поддерживают pppoe circuit id insertion - доступ режется в биллинге одним скриптом. во втором посте есть ссылка как это реализовывается в bgbilling.

[Negator]

Задача состоит в том, что бы узнать адрес свича доступа и номер порта с которого подключен абонент.

Т.е. начиная с самого "верха дерева" нужно проследить все таблицы FDB и дойти до конечного свича и конечного порта.

IP Ареса всех свичей в принципе известны но привязать к портам - нереально.

Есть идеи как реализовать такой скрипт ?

 

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

 

В вашем случае нужно другое:

 

1.Мак адрес известен

2. Известен адрес проживания абонента.

3. Известны IP адреса всех свичей на доме абонента.

4. UPLINK и DOWNLINK порты этих свичей тоже должны быть известны. (Если нет - стоит выяснить и пронумеровать все)

 

Пишем простой скрипт, который снимает всю fdb таблицу с каждого свича на доме, по SNMP ищем в результатах нужный нам мак, исключаем из выдачи

uplink и downlink порты.

Таким образом вы получите IP и порт свича куда воткнут абонент.

Мы такую штуку сделали уже лет 5 назад.

Минус только один - нужно чтобы абонент был в онлайне.

 

Вариант N2

mac notification. Коммутатор при появлении в fdb нового мака отсылает трап.

Обрабатываете трап на сервере,пишете в базу.

Собственно найти нужный мак в базе еще проще.

 

У нас используются оба варианта.

[morf]

Пишем простой скрипт, который снимает всю fdb таблицу с каждого свича на доме, по SNMP ищем в результатах нужный нам мак, исключаем из выдачи

uplink и downlink порты.

Таким образом вы получите IP и порт свича куда воткнут абонент.

Мы такую штуку сделали уже лет 5 назад.

Минус только один - нужно чтобы абонент был в онлайне.

 

Сделал пару месяцев назад скрипт, который как раз прогоняется по всем коммутаторам и забирает таблицу FDB, далее данные анализирует и вносит в биллинг.

Коммутаторов в сети порядка 50 штук. Скрипт сделал многопоточным по всем коммутаторам в часы-пик проходится секунд за 20.

 

Вариант N2

mac notification. Коммутатор при появлении в fdb нового мака отсылает трап.

Обрабатываете трап на сервере,пишете в базу.

Собственно найти нужный мак в базе еще проще.

Тоже думал начать с этой функции, но на некоторых коммутаторах (dlink 3526/3028) трапы приходили странным образом, как будто повторялись.

Edited July 9, 2013 by morf

[darkagent]

и mac notification и сдирание fdb - костыли, теряющие актуальность с ростом количества коммутаторов доступа (соотв. с возрастанием нагрузки на "обрабатывающие" машины). circuit-id как в pppoe, так и в dhcp-relay для ipoe специально предусмотрены для таких задач.

[Ivan Rostovikov]

Благодарю всех за советы.

Буду смотреть в сторону circuit-id и mac notification.

Скорее второе. Т.к. circuit-id требует модификации ACL на свичах.

[tartila]

и mac notification и сдирание fdb - костыли, теряющие актуальность с ростом количества коммутаторов доступа (соотв. с возрастанием нагрузки на "обрабатывающие" машины). circuit-id как в pppoe, так и в dhcp-relay для ipoe специально предусмотрены для таких задач.

 

Не согласен на счет mac-notification. Используем данную шляпу на DES-3526/DES-3528 при абон. базе около 10k. Сделан не блокируемый fork по snmp-trap, заносится mac в mysql - все работает достаточно стабильно и надежно.

[darkagent]

базе около 10k.

10k можно относить к разряду маленьких сетей. проблемы начнутся при >100k

[srg555]

по порядку с точки зрения некривизны решения:

 

адекватный актуальный тех. учёт

vlan-per-user

tr101 (pppoe+)

vlan-per-switch + psec + snmp-костыль для выяснения порта относительно ранее неизвестных маков

mac-notification

[sexst]

10k можно относить к разряду маленьких сетей. проблемы начнутся при >100k

Не замечал я что-то проблем при 100к. И дальше не замечал.

[darkagent]

Не замечал я что-то проблем при 100к. И дальше не замечал.

да простая математика:

предположим что сферические 100к абон.базы размазаны на 24х портовые коммутаторы, ~4200 коммутаторов только для доступа такой абон.базы, каждый будет генерить трап на mac notification, помимо этого генерятся еще трапы по прочему функционалу коммутаторов (допустим spanning-tree new root или topology change, а так же device coldstart в случае дергания железки). трапы - udp пакеты, которые банально могут умереть по пути до сервера, при различных обстоятельствах. а обстоятельства могут быть простые - пропал свет в районе, допустим там 100-200 коммутаторов. свет включился, но коммутаторы стартовали не синхронно (доступ завелся раньше, агрегация позже) - и мы уже потеряли ту пачку mac notification трапов, которые коммутаторы доступа отправили в никуда в период между link up всех живых абонентов и полной прогрузки data plane агрегации. а даже если агрегация не пострадала (упсам хватило батареек), получаем udp шторм в сторону trapd сервера - и там не только mac notification пакеты, но и разные coldstart/stp/и прочие трапы. если справится trapd, справится ли sql сервер с возросшей нагрузкой?

[Negator]

Задача состоит в том, что бы узнать адрес свича доступа и номер порта с которого подключен абонент.

 

и mac notification и сдирание fdb - костыли, теряющие актуальность с ростом количества коммутаторов доступа (соотв. с возрастанием нагрузки на "обрабатывающие" машины). circuit-id как в pppoe, так и в dhcp-relay для ipoe специально предусмотрены для таких задач.

 

Это смотря что за задача.

Если звонит абонент и в биллинге нажать кнопочку - "найти порт", при нажатии на которую скрипт будет снимать fdb c 1-4 свичей доступа в доме и сравнивать с маком абонента - такая задача никаких костылей не несет, будь у тебя хоть 100 коммутаторов вообще, хоть десятки тысяч. Если нужно искать всех и одновременно (не представляю зачем), тогда да - будут проблемы.

 

 

и мы уже потеряли ту пачку mac notification трапов, которые коммутаторы доступа отправили в никуда в период между link up всех живых абонентов и полной прогрузки data plane агрегации. а даже если агрегация не пострадала (упсам хватило батареек), получаем udp шторм в сторону trapd сервера - и там не только mac notification пакеты, но и разные coldstart/stp/и прочие трапы. если справится trapd, справится ли sql сервер с возросшей нагрузкой?

Кстати говоря стандартный snmptrapd скорее всего не справится, будет пропускать.

Ну и что в конце концов? Ну потеряем мы некоторое количество трапов. Это так страшно для контекста данной задачи?

[darkagent]

Если звонит абонент и в биллинге нажать кнопочку - "найти порт", при нажатии на которую скрипт будет снимать fdb c 1-4 свичей доступа в доме и сравнивать с маком абонента - такая задача никаких костылей не несет, будь у тебя хоть 100 коммутаторов вообще, хоть десятки тысяч.

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

[sexst]

Не замечал я что-то проблем при 100к. И дальше не замечал.

да простая математика:

предположим что сферические 100к абон.базы размазаны на 24х портовые коммутаторы, ~4200 коммутаторов только для доступа такой абон.базы, каждый будет генерить трап на mac notification, помимо этого генерятся еще трапы по прочему функционалу коммутаторов (допустим spanning-tree new root или topology change, а так же device coldstart в случае дергания железки). трапы - udp пакеты, которые банально могут умереть по пути до сервера, при различных обстоятельствах. а обстоятельства могут быть простые - пропал свет в районе, допустим там 100-200 коммутаторов. свет включился, но коммутаторы стартовали не синхронно (доступ завелся раньше, агрегация позже) - и мы уже потеряли ту пачку mac notification трапов, которые коммутаторы доступа отправили в никуда в период между link up всех живых абонентов и полной прогрузки data plane агрегации. а даже если агрегация не пострадала (упсам хватило батареек), получаем udp шторм в сторону trapd сервера - и там не только mac notification пакеты, но и разные coldstart/stp/и прочие трапы. если справится trapd, справится ли sql сервер с возросшей нагрузкой?

Именно поэтому периодически (даже у нас раз в 10 минут) строится полная fdb сети. Ну и 40ктрапов в секунду нормально написанный демон прожевывает особенно не замечая.

[Ivan Rostovikov]

>Используем данную шляпу на DES-3526/DES-3528 при абон. базе около 10k. Сделан не блокируемый fork по snmp-trap, заносится mac в mysql .....

 

 

 

tartila Скриптом не поделитесь ?

 

Интересует обработка трапа, выделение полезной информации, и запись в БД.

 

[StSphinx]

Сделал пару месяцев назад скрипт, который как раз прогоняется по всем коммутаторам и забирает таблицу FDB, далее данные анализирует и вносит в биллинг.

Коммутаторов в сети порядка 50 штук. Скрипт сделал многопоточным по всем коммутаторам в часы-пик проходится секунд за 20.

 

 

Скриптом не поделитесь?

[tartila]

>Используем данную шляпу на DES-3526/DES-3528 при абон. базе около 10k. Сделан не блокируемый fork по snmp-trap, заносится mac в mysql .....

 

 

 

tartila Скриптом не поделитесь ?

 

Интересует обработка трапа, выделение полезной информации, и запись в БД.

 

Скриптом не поделюсь, обвязки много (инклуды)...

[Negator]

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

Согласен. Но у автора PPPoE, там не получится управлять услугами на основе гео-данных абонента. Вообще такой механизм я назову только option_82.

[darkagent]

Но у автора PPPoE, там не получится управлять услугами на основе гео-данных абонента

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

[srg555]

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

Согласен. Но у автора PPPoE, там не получится управлять услугами на основе гео-данных абонента. Вообще такой механизм я назову только option_82.

 

Какая разница какой тип подключения? В pppoe есть 100% аналог option82 - tr101 remote/circuit id

 

И что значит "управлять услугами"?

[sexst]

Интересует обработка трапа, выделение полезной информации, и запись в БД.

На самом деле все просто с трапами - открываете сокет, получаете датаграмму из кучи битов, распахиваете ее согласно Basic Encoding Rules, получаете трап в ~ том привычном текстовом виде, который видно в tcpdump'e. Дальше смотрите на oid события и вызываете для обработки некоторый внешний скрипт, которому отдаете трап (на разные события трапы обычно разной структуры). Все. Работы на пару дней с учетом чтения доков по BER.