[martin74]

ась? я получу ип один раз, потом пропишу его же статикой, и выдавайте мне через dhcp хоть 127.0.0.1.....

Без ACL на порту\на маршутизаторе вы ничего не сделаете.

Какой интересный молодой человек. Вы представляете себе, как работает DHCP Snooping? Коммутатор подслушивает не только выданный IP-адрес, но и Lease Time. Истечёт срок аренды вашего адреса, и так же закроется Вам доступ.

Ничего не путаем? Или на длинках свет клином сошелся? Я в курсе, что последние прошивки длинков так себя ведут. Только это ни разу не DHCP Snooping ;)

[shoorickello]

Ну да, имелось ввиду, что такое поведение достигается вместе с IP-Mac-Port Binding :-)

[vIv]

Ну да, имелось ввиду, что такое поведение достигается вместе с IP-Mac-Port Binding :-)

А это-то тут при чём?!?!! Описанное отслеживание настройки клиента по DHCP - обычный классический IP Source Guard

[martin74]

между какими буквами это имелось в виду? ;)

ip-mac-port binding - это ACL. На самом то деле ;)

Отсюда вопрос - а что я не так сказал? ;)

 

[sergei270886]

ты где покупал .qtech? и как это оборудование себя видет?

Заранее спасибо!

[mikevlz]

/me использует обычный isc-dhcp плюс перловый скрипт, каждые 5 минут генерящий новый конфиг. В случае изменения md5 конфига - перестартовывается демон... И чем это плохо?

Абонентов - мало. Около 8к.

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

 

Кстати, попробуй его запустить на 4К интерфейсов. Стартует просто вечность 8-(

запускать его на 4к интерфесах - это решение безусловно интересное, но оно умеет лазить в базу. Через жопу, но умеет. модуль для LDAP в нем есть. Для тех, кому не нравится LDAP - можно покрутить OMAPI-шелл и скриптинг.

Буду крайне признателен за ссылки на описание этого механизма, и, думаю, не я один.

По поводу LDAP смотреть в isc-DHCPd, у меня при сборке на BSD оно предлагает опцию. А уж какой бэкенд будет у LDAP - это уже вопрос настройки OpenLDAP.

По поводу OMAPI-shell - читать в манах dhcpd, есть например такой пункт(поиск по OMAPI):

OMAPI
       The  DHCP server provides the capability to modify some of its configu-
       ration while it is running, without stopping it, modifying its database
       files,  and restarting it.  This capability is currently provided using
       OMAPI - an API for manipulating remote objects.  OMAPI clients  connect
       to  the  server  using  TCP/IP,  authenticate, and can then examine the
       server's current status and make changes to it.

       Rather than implementing the underlying OMAPI protocol  directly,  user
       programs  should  use  the  dhcpctl API or OMAPI itself.   Dhcpctl is a
       wrapper that handles some of the housekeeping chores  that  OMAPI  does
       not  do automatically.   Dhcpctl and OMAPI are documented in dhcpctl(3)
       and omapi(3).

       OMAPI exports objects, which can then be examined and  modified.    The
       DHCP  server exports the following objects: lease, host, failover-state
       and group.   Each object has a number of  methods  that  are  provided:
       lookup,  create,  and destroy.   In addition, it is possible to look at
       attributes that are stored on objects, and  in  some  cases  to  modify
       those attributes.

Ну и далее по тексту man-а.

Изменено 16 января, 2009 пользователем mikevlz

[vIv]

По поводу LDAP смотреть в isc-DHCPd, у меня при сборке на BSD оно предлагает опцию. А уж какой бэкенд будет у LDAP - это уже вопрос настройки OpenLDAP.

По поводу OMAPI-shell - читать в манах dhcpd, есть например такой пункт(поиск по OMAPI):

 

Ну и далее по тексту man-а.

Очень интересно! Спасибо за наводку!

[BudushiyISP]

Ряд вопросиков на основе вышесказанного:

В здании скажем 8-портовый управляемый L2 коммутатор, на район управляемый 24 портовый L2 коммутатор, ну и ядро L3 коммутатор с поддержкой SFlow и ACL до 4000 правил.

Рассмотрим сценарий работы. 8 пользователей - это 8 VLAN поднялись до районного узла, с районного узла 8 VLAN разных пользователей пришли в Ядро...

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

Теперь скажем один из 8 клиентов ведёт успешную работу и получает информацию c Интернета и с локальной сети. Считать траффик локальной сети не нужно, а вот внешний Интернет необходимость.

 

Как Sflow отличает траффик локальный и Интернет ?

 

Через какой промежуток времени передается статистика и каким образом?

 

Достаточно ли одного ACL для одно тарифа на группу пользователей ?

 

По какому принципу как правило соединен биллинг с коммутатором доступ через управляющий VLAN или пофигу:) ?

Изменено 16 января, 2009 пользователем BudushiyISP

[vIv]

Как Sflow отличает траффик локальный и Интернет ?

 

Через какой промежуток времени передается статистика и каким образом?

 

Достаточно ли одного ACL для одно тарифа на группу пользователей ?

 

По какому принципу как правило соединен биллинг с коммутатором доступ через управляющий VLAN или пофигу:) ?

Никак, он только отдаёт данны биллингу. Биллинг уже потом разбирается

 

Как настроишь, почитай про sFlow

 

Если коммутаторы умеют, то да

 

Как правило, через выделенный management VLAN.

 

[20512]

Зачем так громко такми крупными буквами кичать?

А самому, ручками своими попробовть?

Сразу все станет ясно и понятно......

[BudushiyISP]

Зачем так громко такми крупными буквами кичать?

А самому, ручками своими попробовть?

Сразу все станет ясно и понятно......

А пробовать негде, еще не приобрёл активное оборудование. Собираю стенд пока - для тестирования, буду раз 100 прогонять все функции.