BiTel

Кто нибудь подобное делал?

Абонентам выдаются серые IP. Но в пределах VLAN они могут поменять себе IP и занять чужой, с другого договора. В результате конфликт адресов. И соседа бреют с интернетом.
Как можно привязать IP к порту коммутатора?
DHCP мы не используем. Коммутаторы D-Link.

ip source guard (static), acl?

_________________
Клиент: вер. 7.0.806 / 29.04.2016 13:18:28 os: Windows 7; java: Java HotSpot(TM) Client VM, v.1.8.0_66
Сервер: вер. 7.0.1035 / 29.04.2016 13:17:38 os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_92

Первого нет на коммутаторах. (я во всяком случае не нашел)
По ACL`ам можешь подкинуть мануал?

access-list ip extended *имя правила*
permit host *допустимый ип абонента* any
deny any any


мануал в доке производителя. если ip source guard не могут, не факт что ацл тянут...

_________________
Клиент: вер. 7.0.806 / 29.04.2016 13:18:28 os: Windows 7; java: Java HotSpot(TM) Client VM, v.1.8.0_66
Сервер: вер. 7.0.1035 / 29.04.2016 13:17:38 os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_92

Вообще интересен вопрос можно ли сделать это средствами биллинга.
Ведь насколько я понял при использовании DHCP такая вещь возможна(судя по доке).

бгбиллинг позволяет сделать все.

_________________
Клиент: вер. 7.0.806 / 29.04.2016 13:18:28 os: Windows 7; java: Java HotSpot(TM) Client VM, v.1.8.0_66
Сервер: вер. 7.0.1035 / 29.04.2016 13:17:38 os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_92

Все мне сейчас не нужно.
Конкретно по вопросу можешь предложить варианты?

использовать возможности общения биллинга с коммутаторами через telnet или snmp

_________________
Клиент: вер. 7.0.806 / 29.04.2016 13:18:28 os: Windows 7; java: Java HotSpot(TM) Client VM, v.1.8.0_66
Сервер: вер. 7.0.1035 / 29.04.2016 13:17:38 os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_92

У вас каша в голове. Биллинг считает и управляет, чем и как, зависит полностью от вас. Нет IP Source Guard, нет ACL? Тогда только VLAN на абонента. Собирать их в пучок и вести к L3, где IP и будет прибиваться к VLAN'у.

на каждого абонента VLAN`ов не напасешься. на одном коммутаторе как правило один Vlan на всех абонетов этого коммутатора.
В пределах этого влана как раз таки и нужно ограничивать IP на порт

по какому это правилу один влан на коммутатор? тогда уже как правило используется dhcp с опцией 82

_________________
Клиент: вер. 7.0.806 / 29.04.2016 13:18:28 os: Windows 7; java: Java HotSpot(TM) Client VM, v.1.8.0_66
Сервер: вер. 7.0.1035 / 29.04.2016 13:17:38 os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_92

дхцп с опцией 82 только выдаёт человеку нужный ип, но не как не борется с возможностью смены ип на этом порту. Дхцп-снупинг в паре с ИП_Порт_Мак_биндинг на свитче спасает от этого , но усложняет админам и монтажникам жизнь если действия их не согласованны.
Как уже говорили - "vlan в порт" абстрагируется от мака в клиентском порту, да и привязка ип клиента уже не на самом коммутаторе, и на клиентском интерфейсе шлюза.
Но количество интерфейсов и вланов в этом случае равно кол-ву клиентов. Короче конвергенция в сетях связи ушла от физической телефонной линии до абонента и пришла к её виртуальному аналогу и привычным способам её взлома -врезкам в кабеля. Ну от этого осталось тока пппое сверху нахлобучить.
Я всё это к чему пишу - участие БЖБ в этой схеме - тока ип выдать, а всё остальное - это уж к другим средствам. Тока в схеме влан-в-порт можно выдавть ип с помощью БЖБ и не париться с остальным.

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

в связке ip source guard очень борется.

у тс судя по всему обычные неуправляемые мыльницы. так что сначала придется меня доступ

_________________
Клиент: вер. 7.0.806 / 29.04.2016 13:18:28 os: Windows 7; java: Java HotSpot(TM) Client VM, v.1.8.0_66
Сервер: вер. 7.0.1035 / 29.04.2016 13:17:38 os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_92

Hint: На каждый район может быть свое L3 устройство, или как минимум порт в этом устройстве и тогда предел VLAN'ов равен 4096*L3(шт./портов).

ЗЫ: я какбэ умолчал про QinQ еще.

Нет. Мыльниц нет, коммутаторы 2 уровня.


По нашему правилу один влан на коммутатор. Сеть была изначально так организована и дробить ее на 1 влан 1 клиент никто не будет.


Как я уже писал нет этого на наших коммутаторах.

Буду смотреть на dhcp 82. Здесь это уже обсуждалось? Киньте ссылкой

Ппц. Опция 82 вам ничего не даст в плане ограничения от подмены IP в пределах коммутатора. Сеть изначально спроектирована неверно, при такой схеме можно использовать только PPPoE/PPtP. Причем PPPoE предпочтительней, т.к. ему вообще параллельно на TCP/IP стек в опорной сети.

Было б много денег, ставили бы в дома не свитчи а сразу mikrotik rb1100AH. Ну чем не коммутатор?. Заодно и gateway тебе. И никаких vlanov. И интерфейсы на микротике можно переводить в режим arp replay-only, со автоматической статической привязкой по маку. Развернули бы на них dhcp-relay. А на BGB развернуть связку из BGB_DHCP и mikrotika в виде отцы и дети. Да вот беда - на работает такой dhcp на микротиковский релэй. Опции 82 нет там..., тока гигаворды. Тока isc-dhcp скрестить и мона с ним. Ну здесь уж эффект не тот...

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

А чем PPPoE не устраивает?

Скажу более - нас даже пптп устраивает. Но вот как-то не модно в наши дни vpn..., не тренд, как гриться Скора у всех холодильники в онлайн будут выходить. я думаю - там кроме дхцп-клиента ваще ничего не борту не будет. Ну мож медиа-плеер прицепят, шоб играл похоронный марш когда пиво будет подходить к концу.

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

Ну тут имхо либо дешево и "немодно", либо дорого и опрятно, либо дырявые самодельные схемы.

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

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

вы модель длинков скажите. а там можно и ацлом побаловаться

_________________
Клиент: вер. 7.0.806 / 29.04.2016 13:18:28 os: Windows 7; java: Java HotSpot(TM) Client VM, v.1.8.0_66
Сервер: вер. 7.0.1035 / 29.04.2016 13:17:38 os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_92

Модели DES 1228E, 1228ME,
Есть 3100 и 3200. Также 3028 и 3052 (но последних там по одной или две штуки)
Доживают свои дни 2108.

3100- овощь, 3200 ( если DES- самое оно )

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

это DGS 3100. Почему он овощь?

потому что в des2810 засунули коммутирующую матрицу без ASIC , плюсанули telnet и обозвали самым скорострельным d-linkoм в природе. Правда все атомарные операции выполняются устаревшим CPU. Но об этом манагеры и салесманы корпоративно умолчали. Потом одумались и разродились 24TG на другой аппаратной платформе. Но о скриптах на пёрле c с управлением по telnet пока вспоминать ещё рано.

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

ну тогда точно только туннели...

_________________
Клиент: вер. 7.0.806 / 29.04.2016 13:18:28 os: Windows 7; java: Java HotSpot(TM) Client VM, v.1.8.0_66
Сервер: вер. 7.0.1035 / 29.04.2016 13:17:38 os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_92

У нас работают на узлах 24TG как раз таки. Пока слава богу справляются.
Как насчет ACL`ов к ним? Ко всем мною перечисленным

наш броадкастовый сегмент достиг того предела, после которого на dgs3100 надо почаще делать "clear fdb all" и закупать вагонами dgs3120
acl ( и traffic_segmentaion ) - есть , но лучше их не включать.

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

DHCP + Опция 82 + DHCP Snooping. Только так и удается корректно бороться с подменами IP.
ACL - не лучший вариант, ибо ARP надо пропускать, в итоге подменщик никуда выйти не может, но у настоящего хозяина IP все равно "Ваш IP занят".
DHCP Snooping же полностью блокирует трафик клиента, пока тот не получит IP.
Плюс к этому - централизованное управление, легкость администрирования. Сменить подсеть, например, на всем подъезде - раз плюнуть.
PPPoE/PPtP... Шибко дорого получается гонять весь внутренний трафик через сервер. Это какой сервер надо, чтобы держал несколько десятков Gbit/sec ??

Да и вообще, DHCP рулит и будет рулить. ))

Готовых вменяемых DHCP серверов, чтобы поддерживал опцию 82 и данные хранил в базе - нет.
Есть самоделки. В данный момент у себя в сети использую как раз такую.
Подробности: http://forum.nag.ru/forum/index.php?showtopic=64849

Там есть реализация с веб-мордой и исходной базой. В базу легко и из биллинга данные заносить при желании.
Реализована привязка IP к свичу и порту. Можно дополнительно и к MAC (бывает у клиента несколько устройств, например TV-приставка получает IPTV + ПК).
Практика показала достаточную стабильность и надежность - схема работает уже более 3 месяцев.