[Megas]

Уважаемый All.

Вот и дошла очередь до настройки свичей и причесания сабжа в божеский вид.

Сейчас стоит пара DES-3200-10, но планируется их сотня не меньше.

Прошу посмотреть и наставить на путь истинный в отношении их конфигурирования для макс безопасности и все такое... планируется юзать Option 82

Сейчас заливаемый конфиг выглядит так:

 

create account admin Admin

enable password encryption

 

create vlan management tag 3900

config vlan management add tagged 9-10

 

 

config ipif System vlan management ipaddress 192.168.245.11/24 state enable

create iproute default 192.168.245.1

 

 

config vlan default delete 1-10

 

 

create vlan vlan101 tag 101 advertisement

config vlan vlanid 101 add untagged 1-8

config vlan vlanid 101 add tagged 9-10

 

 

### Пока пропускаем config port_security ports 1-8 admin_state enable max_learning_addr 1 lock_address_mode DeleteOnTimeout

 

 

#Запретить STP на клиентских портах, чтобы пользователи не могли гадить в сеть провайдера BPDU пакетами

config stp version rstp

config stp ports 1-8 fbpdu disable state disable

 

 

##И, наконец, включить STORM Control для борьбы с бродкастовыми и мультикастовыми флудами

config traffic control 1-8 broadcast enable multicast enable action drop threshold 64 countdown 5 time_interval 5

 

 

#Настроить loopback detection, чтобы 1) глючные сетевые карточки, которые отражают пакеты обратно и 2) пользователи, создавшие в своей квартире кольца на втором уровне не мешали работе сети

enable loopdetect

config loopdetect recover_timer 1800

config loopdetect interval 10

config loopdetect ports 1-8 state enable

config loopdetect ports 9-10 state disable

 

### Фильтруем DHCP сервера на клиенте

config filter dhcp_server ports 1-8 state enable

 

 

config traffic_segmentation 1-8 forward_list 9-10

 

 

enable syslog

create syslog host 1 ipaddress 192.168.245.1 severity all

 

 

# Дополнение релея

enable dhcp_relay

config dhcp_relay option_82 state enable

config dhcp_relay option_82 check enable

config dhcp_relay option_82 policy replace

config dhcp_relay option_82 remote_id default

config dhcp_relay add ipif System 192.168.245.1

 

enable dhcp_local_relay

config dhcp_local_relay vlan vlan101 state enable

 

 

#### настройка GVRP

enable gvrp

config gvrp 9-10 state enable ingress_checking disable

 

Как бы все работает что надо для начала, но не хватает:

SNMP мониторинг.

MAC-NOTIFICATION.

 

И возник спор, что эффективнее:

config port_security ports 1-8 admin_state enable max_learning_addr 1 lock_address_mode DeleteOnTimeout

эта опция не работает если включен dhcp_snoop

или

enable address_binding dhcp_snoop

Как раз остановился вчера на enable address_binding dhcp_snoop и залил такие настройки:

 

enable address_binding dhcp_snoop

config address_binding dhcp_snoop max_entry ports 1-8 limit 5

 

config address_binding ip_mac ports 1-8 state enable

config address_binding ip_mac ports 1-8 allow_zeroip enable

config address_binding ip_mac ports 1-8 forward_dhcppkt disable

 

### в доплнение

disable address_binding acl_mode

enable address_binding trap_log

 

B получил блокировку мака клиента сходу, хотя мак прилетал через Option 82

попытки его вырезать из состояния блокировки в таблице fdb ничему не привели, пробовал так:

delete fdb vlan101 mac 00-85-f2-44-43-34

delete address_binding blocked all и прочие манипуляции с delete address_binding *

мак оставался заблочиным пока reset config force agry не сделал.

 

 

Так что, прошу помощи по настройке:

enable address_binding dhcp_snoop

ведь хотелось бы использовать все преимущества управляемой сети.

[terrible]

config dhcp_relay option_82 state enable

config dhcp_relay option_82 check disable

config dhcp_relay option_82 policy keep

config address_binding ip_mac ports 1-8 forward_dhcppkt enable

 

На свиче можно использовать либо IP-MAC-Binding, либо Port-Security. Первое - блокирует невалидные MAC адреса, второе - некомутирует невалидные MAC адреса. Причем проверка валидности MAC адреса в обоих случаях разная.

[Megas]

Интересует случай когда:

Есть порт, есть клиент, идет запрос на сервер dhcp идет ответ к определенному маку на порту свича.

 

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

Извиняюсь конечно если не правильно выражаюсь.

[Deac]

чтобы и сосед по порту на свиче не мог прописать сам себе ip другого порта

Для этого есть ACL, запрещающий что-либо не с разрешённого IP.

 

В случае с VLAN-per-User - вообще неактуально.

[Megas]

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

[Deac]

более просто и элегантно

VLAN-per-User

[Megas]

Можно ли как-то в свичах DES 3200-10 посмотреть статистику по срабатыванию правил ACL?

[GFORGX]

более просто и элегантно

VLAN-per-User

Deac! Ожидал от Вас ответа "PPPoE", что-то изменилось? (:

[s.lobanov]

более просто и элегантно

VLAN-per-User

Deac! Ожидал от Вас ответа "PPPoE", что-то изменилось? (:

 

Одно другому не мешает :)

[Megas]

И снова полезли косяки клиентов, стоит у абона роутер в который заходит мой шнурок, чудесным образом с клиентского порта начали сыпаться ip вида 10.1.64.*

хотя наша внутренния сеть: 192.168.*.*

сегодня с утра пришлось отключить config address_binding ip_mac и попробовать перейти на acl с привязкой ip+port

 

собственно теперь вопрос:

а как определить что это клиентский роутер начал гнать пургу в сеть?

раньше это можно было через лог выяснить.

и как в обще посмотреть с каким ip сидит клиент на порту коммутатора, да и в обще как можно отдельно прослушать порт клиента сидя у себя в серверной, при условии что используется vlan на свич, неужели все таки прийдеться переходить на vlan на абонента?

[Gunner]

А надо ли ? Привязали АЦЛем к порту ип - все. То,что шлет клиент левые ип, это его проблемы не ваши.Выйдет только с тем что привязан. У меня по опт82 выдаются ип с помощью дшцп для удобства клиентам эти же ип прибиты к портам.А роутер там гонит или у клиента вирь меня не волнует.

[KotikBSd]

Работаем на длинках, используем mac-ip-port-binding встроенный, особо некто не жалуется, более 3000 абонентов. Один раз попался кривой видеорегистратор сетевой, срал в сеть каким-то левым ип. И есть один абонент у которого дома чуть ли не серверная, стоит несколько машин под виндой, на них ещё виртуалки, и бывает что они срут внутренней виртуальной подсетью. Но у него к нам никаких претензий, он понимает что это его железо косячит. Так что особо проблем нет с биндингом, не нужно панику разводить из-за пары абонентов с кривым железом :)

[secandr]

KotikBSd дай бог, будет у вас 50 000 абонентов и заговорите вы по другому...

[GFORGX]

ACL неудобно, оно требует очень умного механизма SA, предусматривающего, что удалённые свитчи могут быть по каким-то причинам недоступны в момент этого самого SA и т. д.

 

Используем нативный длинковский IMPB с DHCP Snooping, проблемы были на 2.08 и 2.60, с 2.71 все проблемы исчезли. Абонентов - 9к примерно. Полёт чудесный.

[GFORGX]

И есть один абонент у которого дома чуть ли не серверная, стоит несколько машин под виндой, на них ещё виртуалки, и бывает что они срут внутренней виртуальной подсетью.

Такому чудику я бы отдельный VLAN выдал с /30, без всяких биндингов, на Вашем месте :)

[secandr]

GFORGXничего сверхъестественного оно не требует. Продуманная логика выдачи ip, тюнинг дхцп сервера и простенькую САР для контроля ACL.

[GFORGX]

простенькую САР для контроля ACL.

Окей - на узле нет света 31-го и 1-го числа, двое суток. Или же файберкат. Как Ваша простенькая САР сможет обновить ACL? А если что-то случится с сервером, который это осуществляет? Глупая и бессмысленная точка отказа.

[secandr]

GFORGX вы просто придумали себе проблему и пытаетесь решить её в лоб, всё гораздо проще и безотказнее...

 

2 года ~50k абонентов работают без проблем по такой схеме. И САР нужна только что бы проверять не снёс ли кто по ошибке ацл или не забыл ли настроить коммутатор после замены, ну и в автомате прописывать настройки по шаблону. САР можно выключить на любой срок - сеть будет работать без сбоев.

 

Собственно говоря: вся информация о клиентах, вланах, каналах,... хранится в БД. Самой сетью заниматься особо не нужно: внёс изменения в БД, САР с n-ой попытки достучалась до коммутатора и поправила конфиг. Если недостучалась - иницировала аварию. Тех служба разобралась и починила.

Если надо включиться прямо сейчас - зашёл на коммутатор, создал влан, сунул в него порт. А все ацл, qos, портсеки и прочую лабудень за тебя навешает машина автоматом.

[Gunner]

У вас так часто меняются пользователи на порту ? У нас скрипт отрабатывает 2 раза в неделю. По умолчанию все порты открыты. Я не уверен что за неделю появиться кульхацкер который подменит мак и ип другого клиента в своем влане.

[Negator]

А надо ли ? Привязали АЦЛем к порту ип - все. То,что шлет клиент левые ип, это его проблемы не ваши.Выйдет только с тем что привязан. У меня по опт82 выдаются ип с помощью дшцп для удобства клиентам эти же ип прибиты к портам.А роутер там гонит или у клиента вирь меня не волнует.

+1. Мы также работаем.

 

Используем нативный длинковский IMPB с DHCP Snooping, проблемы были на 2.08 и 2.60, с 2.71 все проблемы исчезли. Абонентов - 9к примерно. Полёт чудесный.

а вот на 3526 пробовали? Я пробовал, но давно, и были проблемы. Сейчас софт вылизали?

[GFORGX]

GFORGX вы просто придумали себе проблему и пытаетесь решить её в лоб, всё гораздо проще и безотказнее...

Да я-то себе никакую проблему не придумывал, это ваш сервис-активейшн мне проблемой страшной кажется (:

 

2 года ~50k абонентов работают без проблем по такой схеме. И САР нужна только что бы проверять не снёс ли кто по ошибке ацл или не забыл ли настроить коммутатор после замены, ну и в автомате прописывать настройки по шаблону. САР можно выключить на любой срок - сеть будет работать без сбоев.

Рискну предположить - доступ в интернет тоже блокируется на основе ACL/iptables на терминирующем роутере? Рад за Вас, у Вас очень мегапрямые руки, если у вас всё это обновление ACL всегда успешно работает, и никто из должников не сидит в этих ваших интернетах или наоборот :)

 

Собственно говоря: вся информация о клиентах, вланах, каналах,... хранится в БД. Самой сетью заниматься особо не нужно: внёс изменения в БД, САР с n-ой попытки достучалась до коммутатора и поправила конфиг. Если недостучалась - иницировала аварию. Тех служба разобралась и починила.

Если надо включиться прямо сейчас - зашёл на коммутатор, создал влан, сунул в него порт. А все ацл, qos, портсеки и прочую лабудень за тебя навешает машина автоматом.

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

 

Используем нативный длинковский IMPB с DHCP Snooping, проблемы были на 2.08 и 2.60, с 2.71 все проблемы исчезли. Абонентов - 9к примерно. Полёт чудесный.

а вот на 3526 пробовали? Я пробовал, но давно, и были проблемы. Сейчас софт вылизали?

3526 у меня нету, вся сеть на 3528/3552. 2.08 и 2.71 - как небо и земля, действительно, вылизано.

[secandr]

искну предположить - доступ в интернет тоже блокируется на основе ACL/iptables на терминирующем роутере?

Авторизация в интернет работает на CISCO ASR-1000.

Доступ к локальным ресурсам блокируется ацлем, так же ацл выставляет приоритеты CoS по типам трафика. Всё работает как часы.

 

это ваш сервис-активейшн мне проблемой страшной кажется (:

Вот это я и называю "придумали себе проблему и пытаетесь решить её в лоб". Гибче надо быть.

[Dyr]

Мы используем DES-3200-28 с dhcp_opt82, на них настраиваем ACL'ки такого вида (на порту разрешаем по 8 ip адресов):

 

create access_profile packet_content_mask offset1 l2 0 0xFFFF offset2 l2 16 0xFFFF offset3 l2 18 0xFFF8 profile_id 252
create access_profile ip source_ip_mask 255.255.255.248 profile_id 253
create access_profile packet_content_mask offset1 l2 0 0xFFFF profile_id 254
create access_profile ip source_ip_mask 000.000.000.000 profile_id 255
config access_profile profile_id 252 add access_id auto_assign packet_content offset1 0x0806 offset2 0x0A35 offset3 0x0008 port 1 permit
config access_profile profile_id 253 add access_id auto_assign ip source_ip 10.53.0.8 port 1 permit
config access_profile profile_id 254 add access_id auto_assign packet_content offset1 0x0806 port 1 deny
config access_profile profile_id 255 add access_id auto_assign ip source_ip 000.000.000.000 port 1 deny

config access_profile profile_id 252 add access_id auto_assign packet_content offset1 0x0806 offset2 0x0A35 offset3 0x0010 port 2 permit
config access_profile profile_id 253 add access_id auto_assign ip source_ip 10.53.0.16 port 2 permit
config access_profile profile_id 254 add access_id auto_assign packet_content offset1 0x0806 port 2 deny
config access_profile profile_id 255 add access_id auto_assign ip source_ip 000.000.000.000 port 2 deny

 

 

 

[sexst]

Еще полезно

1)Разрешить логирование команд

enable command logging

2)Раз есть сислог, настроить ntp, чтобы в него сыпалось адекватное время

enable sntp
config time_zone operator + hour 4 min 0
config sntp primary xxx.xxx.xxx.xxx secondary xxx.xxx.xxx.xxx poll-interval 600

3)Т.к. в 3200 есть проблемы с хэшами, порезать юникаст, который направляется маку, не попавшему в таблицу коммутации - пусть лучше только у одного будет плохо со скоростью, чем он нескольким подгадит торрентами/локалкой

config traffic control 1-8 broadcast enable multicast enable unicast enable action drop threshold [b]xxx[/b] countdown 0 time_interval 5

4)Snmp трапы

enable snmp traps
enable snmp authenticate_traps
enable snmp linkchange_traps
config snmp linkchange_traps ports all enable
create snmp host xxx.xxx.xxx.xxx v2c public 

Пользуем в 3200-28, думаю и в 3200-10 есть

Изменено 1 марта, 2012 пользователем sexst