Comments 18
Ну типа про option82 — да (хотя имхо 1:1 VLAN веселее), но строить провайдерский доступ, обставив город каталистами 2950 — о-хо-хо, написал бы вот кто-нибудь о том, почему так делать не надо :)
В настройках management-интерфейса указать, что DHCP-запросы нужно пересылать на 2960-й коммутатор по адресу 10.0.254.2
Лишнее.
Командой ip dhcp snooping database мы определим место хранения базы, в примере она будет храниться в файле dhcp на флеш.
Очень большая ошибка. Флеш быстро загадится морем файлов. Надо tftp хотя бы.
Так как Cisco 2950 не поддерживает Dynamic ARP Inspection, данную технологию нужно настраивать на вышестоящем коммутаторе Cisco 2960.
Надо либо прямо на коммутаторе, к которому подключен пользователь, либо вообще не надо, ибо бесполезно. Толку рубить корявые arpы на аплинке, если атаковать будут соседей по свитчу?
Раз уж начали — надо и ip source guard добавить.
Цель Dynamic ARP Inspection — предотвратить подмену IP для биллинга, речь идет не о корпоративной сети. Понятно, что чем ближе, тем правильнее. То же и про ip source guard.По ip helper-address согласен, оказалось лишнее.
Я описал, где можно хранить базу, в том числе и на тфтп. Флеш взят для примера, как самый простой вариант.
Я описал, где можно хранить базу, в том числе и на тфтп. Флеш взят для примера, как самый простой вариант.
Цель Dynamic ARP Inspection — предотвратить подмену IP для биллинга
Т.е. если человек начнет спуфить первый хоп для соседей по свитчу — ничего страшного? :) Мне представляется, что именно в ориентированной на хомячков провайдерской сети первым делом и нужна подобная защита от кулхацкеров, научившихся запускать backtrack. Кто-то писал, что даже TDR по ночам запускает и анализирует внезапные изменения характеристик патч-кордов до пользователей. И реально хватает за задницу любителей подсосаться к чужой сети.
Флеш взят для примера
Честно говоря, не стоит приводить такие примеры, а если приводить, то только с оговорками по поводу того, какие платформы поддерживают дозапись в собственной файловой системе. Реально чревато. «ip dhcp snooping database tftp» занимает то же количество строк и лишь чуть длиннее, зато универсально.
По поводу того, чем плохо «обставив город каталистами 2950» — это же очевидно.
1) Через месяц железка окончательно завершает свой жизненный цикл, EOL был объявлен 5 лет назад. Небось скупаете Б/У? Ну-ну.
2) Железка очень нефункциональна и вообще весьма убога.
3) Если вы молитесь на шильдик Cisco и считаете, что любой каталист лучше любого не-каталиста, то это — колоссальное заблуждение.
Ой. Я не это совсем имел в виду. Ну, т. е. использовать EoL и БУ оборудование — это вполне себе бизнесс-стратегия, успех которой обсуждать мне, честно говоря, лень. Скажу лишь, что для данной конкретной задачи 2950 ничем не лучше, чем третьесортный китайский OEM. Но мне, честно говоря, показалось, что автор их использовал просто потому что они у него под рукой были — типа, лаба.
Я скорее про техническую часть. Вообще сеть под ШПД-подписку из одних только коммутаторов такого рода (не обязательно c2950, вообще любых энтерпрайзных свичей) — это сомнительная затея с точки зрения масштабируемости, управляемости, устойчивости к отказу и проч. Точнее, она более-менее ОК, когда между BRAS-ом и абонентом не больше двух коммутаторов. Дальше начинается подземелье.
Я скорее про техническую часть. Вообще сеть под ШПД-подписку из одних только коммутаторов такого рода (не обязательно c2950, вообще любых энтерпрайзных свичей) — это сомнительная затея с точки зрения масштабируемости, управляемости, устойчивости к отказу и проч. Точнее, она более-менее ОК, когда между BRAS-ом и абонентом не больше двух коммутаторов. Дальше начинается подземелье.
>>Очень большая ошибка. Флеш быстро загадится морем файлов. Надо tftp хотя бы.
Сколько ни делал — ни разу не видел. Файл перезаписывается. Он нужен, что бы после внезапной перезагрузки железки у юзеров связь не пропала. Если они напрямую на свиче — они переполучат адреса и это «унюхается» снупингом, а если нет — то нет. А когда есть файлик — инфа подцепиться из него.
sh flash
…
5 -rwx 2097 Sep 3 2013 16:06:38 +04:00 dhcp_snooping
Сколько ни делал — ни разу не видел. Файл перезаписывается. Он нужен, что бы после внезапной перезагрузки железки у юзеров связь не пропала. Если они напрямую на свиче — они переполучат адреса и это «унюхается» снупингом, а если нет — то нет. А когда есть файлик — инфа подцепиться из него.
sh flash
…
5 -rwx 2097 Sep 3 2013 16:06:38 +04:00 dhcp_snooping
Смотря какая платформа. Судя по наличию «flash», это — IOS роутер, с ними всегда просто. И «софтовый роутер» можно смело называть «одним устройством», они в большинстве своем одинаковы. А хардварные железки все очень разные и со своими закидонами.
www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/31sg/system/message/emsg.html
Выглядит это так: на флеше стотыщ файлов «dhcp_snooping» (или как они там были названы в конфиге), все кроме одного помечены как удаленные. Любое изменение = новый файл, старое место не освобождается.
www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/31sg/system/message/emsg.html
Saving DHCP snooping bindings to a flash file system such as bootflash or slot0 could cause the flash to fill up. Possible consequences include a long delay to regain a console connection, write failures for database configurations, regular squeeze requirements, and reduced life of flash due to regular squeeze operations.
Выглядит это так: на флеше стотыщ файлов «dhcp_snooping» (или как они там были названы в конфиге), все кроме одного помечены как удаленные. Любое изменение = новый файл, старое место не освобождается.
Я привел вывод с cisco2960. У меня на них на всех снупинг включен. Факт есть факт — файл перезаписывается. То же самое юзаю на c3560 — такая же картина, файл перезаписывается, никакой кучи файлов нет. с3560 работают много лет, за это время все место исчерпалось бы много раз.
Настроено так
ip dhcp snooping database flash:dhcp_snooping
ip dhcp snooping database write-delay 60
ip dhcp snooping database timeout 60
Так что где-то может это проблема с невысвобождением места и есть, но к железу статьи это относится не должно.
Настроено так
ip dhcp snooping database flash:dhcp_snooping
ip dhcp snooping database write-delay 60
ip dhcp snooping database timeout 60
Так что где-то может это проблема с невысвобождением места и есть, но к железу статьи это относится не должно.
Пачку сока(виртуальную) тому кто кинет линк на принципы формирования НЕХ строки для опций ДХЦП. Хочу попробовать такое реализовать на микротике. Чисто ради академического интереса. Что бы шла привязка не по МАС а по порту свитча.
Кстати а отследить от какой безпроводной точки пришел клиент к ДХЦП можно? А то у знакомого есть пару точек в режиме моста, и нужно порезать клиентов конкретной точки(более детально не знаю). Проблема в том что все воткнуты в один порт роутера. Так что по входному порту не получается.
Кстати а отследить от какой безпроводной точки пришел клиент к ДХЦП можно? А то у знакомого есть пару точек в режиме моста, и нужно порезать клиентов конкретной точки(более детально не знаю). Проблема в том что все воткнуты в один порт роутера. Так что по входному порту не получается.
hex-строку формирует свич, поэтому строка зависит от типа свича.
DHCP-сервер должен ее обрабатывать, микротик, похоже, не умеет обрабатывать опцию 82 и выдавать адрес из пула в зависимости от значения этой опции.
По поводу точек доступа, опять же, все зависит от конкретной точки.
DHCP-сервер должен ее обрабатывать, микротик, похоже, не умеет обрабатывать опцию 82 и выдавать адрес из пула в зависимости от значения этой опции.
По поводу точек доступа, опять же, все зависит от конкретной точки.
Сорри, что поднимаю старый пост. Просто, хотел добавить, что у некоторых свитчей есть небольшая возможность по настройке принципов формирования этого HEX. Ниже пример команды на Cisco Catalyst 3750.
switch(config)#ip dhcp snooping information option format remote-id?
hostname Use configured hostname for remote id
string User defined string for remote id
switch(config)#ip dhcp snooping information option format remote-id?
hostname Use configured hostname for remote id
string User defined string for remote id
На щет адреса из пула не уверен, а вот дополнительные роуты передавали клиентам через «оцпию82»(был пост на форуме ixbt в ветке по микротикам, но вот найти немогу). Вот и ищу теперь книжку «Опция 82 для чайников» :).
упс, каюсь, там другие опции использовали
forum.ixbt.com/topic.cgi?id=14:57592:2936#2936
Накопал, как работать с опциями DHCP-сервера. В частности, с 33 и 121 — маршрут до отдельного узла и список произвольных маршрутов (но принцип одинаков для любой опции)
1. IP — DHCP Server — Options, там создаём новую опцию
2. Задаём ей имя — например, DHCP classless routes (121)
3. Указываем код опции — 121
4. В отдельном текстовом редакторе формируем значение опции:
а) записываем все нужные нам маршруты в формате подсеть/маска, шлюз
б) подсеть обрезаем до такого количества байт, которое вмещается в маске. Например, сеть 10.0.0.0/8 будет записана как 10 8. Также, подсеть 192.168.0.0/24 запишется как 192 168 0 24. А сеть 172.16.16.0/21 превратится в 172 16 16 21
в) переставляем значение маски перед номером подсети. Тогда подсеть 10.0.0.0/8 превратится в 8 10, а сеть 192.168.0.0/24 станет 24 192 168 0
г) записываем в одну строку подсеть и шлюз. Если у нас есть несколько подсетей, маршруты до которых надо передать, то просто записываем их один за другим
д) обязательно в конце добавляем дефолтный маршрут, поскольку клиенты имеют право игнорировать стандартную опцию маршрута по умолчанию при наличии опции 121
е) переводим всё в шестнадцатиричную систему счисления и перед полученной строкой ставим 0x
Пример: надо передать маршруты до сети 10.5.0.0/16 через 192.168.8.1, а до 10.6.0.0/16 — через 192.168.8.254, а дефолтный маршрут у нас через 192.168.8.4
Рисуем строку: 16 10 5 192 168 8 1 16 10 6 192 168 8 254 0 192 168 8 4
Нужная нам строка для скармливания маршрутизатору: 0x100a05c0a80808100a06c0a808fe00c0a80804
5. В свойствах подсети, указываемой в DHCP-сервере, нужно указать на использование свежесозданной опции
6. ?????????
7. PROFIT!!!
forum.ixbt.com/topic.cgi?id=14:57592:2936#2936
Накопал, как работать с опциями DHCP-сервера. В частности, с 33 и 121 — маршрут до отдельного узла и список произвольных маршрутов (но принцип одинаков для любой опции)
1. IP — DHCP Server — Options, там создаём новую опцию
2. Задаём ей имя — например, DHCP classless routes (121)
3. Указываем код опции — 121
4. В отдельном текстовом редакторе формируем значение опции:
а) записываем все нужные нам маршруты в формате подсеть/маска, шлюз
б) подсеть обрезаем до такого количества байт, которое вмещается в маске. Например, сеть 10.0.0.0/8 будет записана как 10 8. Также, подсеть 192.168.0.0/24 запишется как 192 168 0 24. А сеть 172.16.16.0/21 превратится в 172 16 16 21
в) переставляем значение маски перед номером подсети. Тогда подсеть 10.0.0.0/8 превратится в 8 10, а сеть 192.168.0.0/24 станет 24 192 168 0
г) записываем в одну строку подсеть и шлюз. Если у нас есть несколько подсетей, маршруты до которых надо передать, то просто записываем их один за другим
д) обязательно в конце добавляем дефолтный маршрут, поскольку клиенты имеют право игнорировать стандартную опцию маршрута по умолчанию при наличии опции 121
е) переводим всё в шестнадцатиричную систему счисления и перед полученной строкой ставим 0x
Пример: надо передать маршруты до сети 10.5.0.0/16 через 192.168.8.1, а до 10.6.0.0/16 — через 192.168.8.254, а дефолтный маршрут у нас через 192.168.8.4
Рисуем строку: 16 10 5 192 168 8 1 16 10 6 192 168 8 254 0 192 168 8 4
Нужная нам строка для скармливания маршрутизатору: 0x100a05c0a80808100a06c0a808fe00c0a80804
5. В свойствах подсети, указываемой в DHCP-сервере, нужно указать на использование свежесозданной опции
6. ?????????
7. PROFIT!!!
Вы говорите о выдаче маршрута, это не проблема. Можно описать кучу опций со значениями, которые будет ОТДАВАТЬ сервер.
121-я — статический маршрут
150-я — тфтп сервер и так далее.
Особенность опции 82 в том, что ее сервер ПОЛУЧАЕТ. И на основании этой опции выбирает пул, из которого выдать адрес. Так вот, сервер должен уметь анализировать эту опцию во входящем запросе. Микротик этого не умеет, на сколько мне известно.
121-я — статический маршрут
150-я — тфтп сервер и так далее.
Особенность опции 82 в том, что ее сервер ПОЛУЧАЕТ. И на основании этой опции выбирает пул, из которого выдать адрес. Так вот, сервер должен уметь анализировать эту опцию во входящем запросе. Микротик этого не умеет, на сколько мне известно.
Спасибо. Получается микротику никак не укажешь что бы автоматом выдавал адреса на основании порта, а не МАС. Жаль, ну что ж, отрицательный результат тоже результат.
используйте с микротиком внешний сервер радиуса и все получится
бегло просмотрел: mikrotik + freeradius + mysql www.netup.ru/phpbb/viewtopic.php?p=47149#47149
детально не вникал, но по конфигу вроде все хватаетдля начала работы… гляньте ветку, может окажется Вам полезной…
детально не вникал, но по конфигу вроде все хватаетдля начала работы… гляньте ветку, может окажется Вам полезной…
Sign up to leave a comment.
Построение провайдерской сети на коммутаторах Cisco с использованием Option 82 и Dynamic ARP Inspection