umike

По конфигу абонентского порта для EoIP набралось следующее полезное: Комментарии приветствуются. # stp,lacp,gvrp bpdu bridge-protocol filter # drop tagged traf on access port switchport discard packet tag # limit kbps in hardware storm-control broadcast 16 storm-control multicast 16 storm-control unicast 16 # limit pps in software (цифры с потолка, непонятно это per second или per port-rate-statistics interval) rate-violation broadcast 200 rate-violation multicast 200 rate-violation unicast 20000 rate-violation control shutdown # do not flood unknown unicast as broadcast switchport flood-control ucast # limit multicast ip multicast destination-control access-group 6000 igmp snooping drop query # vlans switchport access vlan xx switchport association multicast-vlan yyyy # ACL (см выше) ip access-group 110 in traffic-statistic mac access-group 1110 in traffic-statistic #loopdetect loopback-detection specified-vlan 1-4094 loopback-detection control shutdown # limit mac address count per port switchport port-security switchport port-security maximum 64 switchport port-security violation restrict #либо switchport mac-address dynamic maximum 64

какая у вас модель? Пример работоспособной настройки source-control покажите пожалуйста? ACL для фильтрации трафика от абонента не используете или на мультикаст они не влияют?

с destination-control я разобрался. Хотелось понять зачем нужен именно source-control и как его применять А также как запретить клиенту транслировать мультики.

можно вообще пример конфига source-control и ситуации? В SNR-2965-24T я так и не понял что именно он фильтрует (группы к которым разрешается/запрещается igmp join?) и добиться работоспособности

Ок, для EoIP начнём с банальных # ip access-list 1100 permit any-source-mac any-destination-mac ethertype 2048 # arp access-list 1100 permit any-source-mac any-destination-mac ethertype 2054 # RARP и собственный loopdetect судя по счетчикам не нужны access-list 1100 permit any-source-mac any-destination-mac ethertype 32821 access-list 1100 permit f8:f0:82:00:00:00 000000FFFFFF f8:f0:82:00:00:00 000000FFFFFF ethertype 56329 # block all other access-list 1100 deny any-source-mac any-destination-mac # igmp в довесок к прочим фичам (source/destination control и т.д.) по желанию с type access-list 110 permit igmp any-source host-destination 224.0.0.2 access-list 110 permit igmp any-source 239.x.x.0 0.0.0.255 access-list 110 deny igmp any-source any-destination # permit dhcp client, deny any other ip broadcast access-list 110 permit udp any-source s-port 68 any-destination d-port 67 access-list 110 deny ip any-source host-destination 255.255.255.255 # не нужные подсетки (или наоборот, только нужные) вида access-list 110 deny ip 169.254.0.0 0.0.255.255 any-destination access-list 110 deny ip any-source 169.254.0.0 0.0.255.255 # ip протокол to multicast dst ip access-list 110 deny ip any-source 224.0.0.0 15.255.255.255 # DHCP server и так и сяк access-list 110 deny udp any-source s-port 67 any-destination access-list 110 deny udp any-source any-destination d-port 68 # NetBIOS, SSDP и прочее access-list 110 deny tcp any-source any-destination d-port 135 access-list 110 deny tcp any-source any-destination d-port 136 access-list 110 deny tcp any-source any-destination d-port 137 access-list 110 deny tcp any-source any-destination d-port 138 access-list 110 deny tcp any-source any-destination d-port 139 access-list 110 deny tcp any-source any-destination d-port 445 access-list 110 deny tcp any-source any-destination d-port 1900 access-list 110 deny tcp any-source any-destination d-port 2869 access-list 110 deny udp any-source any-destination d-port 135 access-list 110 deny udp any-source any-destination d-port 136 access-list 110 deny udp any-source any-destination d-port 137 access-list 110 deny udp any-source any-destination d-port 138 access-list 110 deny udp any-source any-destination d-port 139 access-list 110 deny udp any-source any-destination d-port 445 access-list 110 deny udp any-source any-destination d-port 1900 access-list 110 deny udp any-source any-destination d-port 2869 access-list 110 permit ip any-source any-destination в некоторых местах могло пригодиться такое #deny to dst ip 172.16.x.255/12 access-list 110 deny ip any-source 172.16.0.255 0.15.255.0 ERROR: destination wildcard is invalid! но похоже что коммутатор не хочет принимать несплошные wildcard mask. Навесил на 24 порта, судя по The unit0 tcam details is below ----------------------------------------------------------- Type rule Total Used free available mac-fw 120 128 120 8 1160 mac-ip-fw 744 768 744 24 1176 The unit0 total tcam number is:2048 used: 864 free:1184, utilization:42% ресурсов должно хватить, но вот на 48/52-портовую версию уже не факт что хватит если там tcam столько-же

хм. Неужели все используют SNR только на дистрибьюшене и в ядре, где подобные фильтры не нужны? :)

Коллеги, использующие SNR на доступе, поделитесь пожалуйста как используете SNR ALC аналогично D-Link PCF (в основном для фильтрации мусора)? На руках "поиграться" SNR-2965-24T. Возможно, кто-то опубликует или вышлет в личку свои ACL для примера? У D-Link наиболее подходящей оказалась конструкция из двух профилей (по этому посту): первый - ethertype + src mac + dst mac второй - PCF на L3/L4 Как с этим на SNR? 1) Имеет ли смысл по аналогии с D-Link создавать единый userdefined-access-list, покрывающий всё (11 смещений по 2 байте по идее должно хватить на все хотелки) или для простоты и переносимости между моделями можно создать обычные отдельные ACL, фильтрующие отдельно MAC, Ether Proto, IP-адреса, tcp/udp порты и это будет работать? 2) Не понял из беглого изучения мануалов, SNR UAL также как и D-Link PCF создаётся единственный на весь коммутатор? Несколько UAL разного вида создать нельзя? 3)Вопрос скорее к НАГу: у некоторых других производителей на этих-же dcn-платформах указывается, что есть ограничения на одновременное использование разных фич, например ip multicast destination-control и разных ACL. Не просвятите? Не хочется наткнуться на такие лимиты "потом".

Главное НЕ Связьприбор. Достался в наследство аппарат. В целом аппаратом работать можно, обещают бесплатное обслуживание в течение всего срока службы. Но сервис и ремонт - полный аллес. Отправленный в ремонт реф канул в бездну ремонтного отдела НА ТРИ МЕСЯЦА. Это при том, что по симптомам по телефону сразу сказали "это пробой лавинного диода". Через месяц-полтора нахождения рефа в ремонта наконец диагностировали что вы не поверите, таки да, вышел из строя лавинный диод. Замена стоит денег. И еще полтора месяца диод меняли, реф калибровали/поверяли и, наконец, выслали обратно. Впечатления аховые.

кипиш подняли знатный, возбуждение достигло регионов. К вечеру через RETN айпишник рутрекера перестал даже пинговаться.

Не первые и не последние. Руководство РКН очень интересуется "вечной" блокировкой трекеров. Смотрят на результаты которые выдает небезызвестная коробка. Если есть возможность, на эти сайты (а заодно и их зеркала) лучше повесить заглушку, где очень крупно написать "Доступ закрыт" (ну или нечно аналогичное). с этим все уже смирились. Заглушку на домен, конечно повесим. Мы изумлены требованием "блокировать несуществующие сайты". IMHO требование "предоставлять пепел от сжигания экземпляров несуществующих газет" это очередной шаг вдаль за грань допустимой степени безумия. Так и до министерства правды недалеко. Главный вопрос: через что коробочка отресолвила ip ресурсов, если наши DNS (как и большинство других) их не ресолвят, а коробочка получает настройки по DHCP? Хочется на будущее использовать именно этот православный ресолвер :)

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

Звонили местные, сообщили что им спустили сверху аяяй т.к. ревизор доложил о неблокировке некоторых ресурсов. О чём могут даже скрины предоставить. Попросили скрины. Вопрос в том, что ресурсы даже не ресолвятся. Даже через гугло- и чужие DNS. У некоторыех сайтов во whois даже нет полей nserver Местные прониклись, но сказали что на такие ресурсы тоже должна выдаваться заглушка. Технически загрузить зоны в днс и направить на заглушку не сложно, но сам факт, конечно, умиляет. Кто-то еще столкнулся с подобным или мы первые? :)

проясните зачем нужно config 802.1p user_priority 6 6 config 802.1p user_priority 4 4 ведь как я понимаю согласно нижеприведенному, оно и так по-дефолту попадёт в более приоритетную очередь чем некрашеный трафик? #show 802.1p user_priority Command: show 802.1p user_priority QOS Class of Traffic Priority-0 -> <Class-2> Priority-1 -> <Class-0> Priority-2 -> <Class-1> Priority-3 -> <Class-3> Priority-4 -> <Class-4> Priority-5 -> <Class-5> Priority-6 -> <Class-6> Priority-7 -> <Class-7> #show scheduling Command: show scheduling QOS Output Scheduling On Port: 1 Class ID Weight -------- ------ Class-0 1 Class-1 2 Class-2 3 Class-3 4 Class-4 5 Class-5 6 Class-6 7 Class-7 8 xcme, ACL могут пригодиться для модификации ingress трафика от юзера, например можно покрасить SIP по dst ip своих серверов. И кстати, в чём плюсы-минусы использования replace_source_ip ?

Нужна модель RB в качестве центрального роутера системы хотспотов. На сегодня запустили на давнем RB2011UiAS. У которого при включении хотспота загрузка CPU сразу образовалась под 100% и один раз случились "клины" (на уровне сети работает, но хотспот страничку не отдаёт). В dhcp в среднем выдано порядка 750 ip, в хотспоте Active ~150. Будет больше. Т.к. 2/3 хотспотов уличные в людных местах, то кол-во "мимо идущих" и "цепляющихся" устройств - десяток в секунду. Трафика мало - мегабит 20-100 и 5kpps. Помимо собствено simple queues хотспота использую дополнительную mangle классификацию по proto/port и дополнительные pcq queue чтобы торренты и подобное ограничивать. Подозреваю что RB2011 явно слаб и надо либо многоядерный CCR1009-8G-1S и выше, либо сразу купить лицензию L6 на PC. Ваши рекомендации?

Коллеги ни у кого случайно не имеется контактов людей из sberbank-ast, которые знают такие ужасные слова как "трафик", "ip-адрес", "автономная система" и другую обсценнную лексику телекома? Буду очень признателен в личку или на mm@kaluga.net. Столкнулись вчера с недоступностью подсети 193.104.207.0/24 площадки sberbank-ast, что длилось достаточно долго чтобы у моего саппорта от гос.заказчиков начала появляться седина. Телефонный номер в RIPE DB для этого блока и собственно AS42974 совсем мёртвый (абонент недоступен или вне зоны), что говорит само за себя. Маринки в саппорте сбербанка просто Маринки без права эскалации инцидентов. Как всегда остаётся надеяться на сообщество, т.е. на вас :)

Дело было вечером делать было нечего, загружал ноут с различных LiveCD (WinXP/Kubuntu/Knoppix), смотрел скорость на одних и тех-же тестах (как спидтест так и перекачка файлов с локальным ftp/samba), получал очень разные результаты. iperf/jperf показали примерно общий знаменатель.

eth0 192.168.0.1/24 eth1 172.16.0.1/24 сделан src-nat в eth1, работает сделан "проброс порта" dst-nat, трафик eth1:172.16.0.1:1234 перенаправляется на 192.168.0.100:1234, работает как сделать следующее: 1) ограничить доступ к "проброшенному" порту eth1:172.16.0.1:1234 списком конкретных разрешенных src-ip 2) запретить пакеты, идущие по роутингу транзитом из 172.16.0.1/24 в 192.168.0.0/24, не поломав наты второй день не могу сообразить, ранее работал с BSD, там пакеты из фаервола отправляются в нат, а тут порядок наоборот. Делаю последним правило drop всего из eth1, пытаюсь разрешить всё из eth1 + dst-ip 172.16.0.1 и получаю облом. Понимаю что чего-то не понимаю :)

ну да, если vlan170 сделать везде tagged, то у меня и вопроса бы не было: а вот с tagged/untagged.... изучаю Switch_Chip_Features

обождите, если объединить eth3 и 4 в бридж, то надо "железку" переводить в режим "и vlan169 tagged, vlan170 tagged", тогда можно и проще - на каждом порту создать vlan170 и соединить их бриджом. Вопрос в том, что vlan170 tagged в eth4 и untagged в eth3. Если делать так то что будет в eth4 ? tagged vlan170 в котором q-in-q tagged vlan169?

если на "железке" перевести оба vlan в tagged режим, то настройка становится понятной. Если реализация такущей схемы не выйдет, то буду переводить.

однако, ситуация немного другая. Если я делаю vlan170 на eth4 bridge170=(vlan170+eth3) поверх bridge170 создаю vlan169_on_bridge170 В eth3 получаем tag 169 + untag 170 В eth4 получаю vlan169, включенный в bridge170. На бридже в свою очередь создан vlan169. Таким образом в eth4 я получу vlan170 в котором q-in-q vlan169 ?? Мне этого не нужно.

спасибо, суть прояснилась. Непривычно. Перерисую схему и попробую.

вики смотрел, просветления не наступило. Ок, как реализовать вышеуказанное? Ставить "снаружи" свитч чтобы подать два вилана разными интерфейсами не интересно т.к. свободных портов хватает Как я понял, решить можно так: 1) сделать бридж между ether4 и ether5, на бридж повесить ip (это будет vlan222), однако эти ip делать доступными из ether4 нежелательно 2) поверх бриджа создать tagged vlan111

RB2011L-RM, подскажите как сделать "транковый" порт? Например ether5, в котором vlan 111 - tagged vlan 222 - untagged/native в соседнем ether4 будет vlan 222 tagged Причем еще оба вилана еще должны быть L3-интерфейсами через которые между виланами будет ходить трафик с натом и шейпированием. Настраиваю через веб-морду/winbox, хочу понимать принципы, поэтому объяснение лучше словами типа "создать бридж,включить в него..., создать вилан на интерфейсе..."

Евгений, про однопоточность pf-nat в курсе, ipfw nat в множество instance смотрели, загрузка тоже менялась достаточно рандомно. Смущает что ровно те-же pps и Mbps E3-1270 при той-же конфигурации софта обрабатываются спокойно. С точно таким-же pf и dummynet'ом и даже с такой-же карточкой.