Susanin

Новая это в пластике которая ? Эту еще не пробывали.А самих 2108 у нас стоит несколько десятков, пропуская десятки вланов. Работают исключительно. Каждые 5 минут cacti снимает с них трафик, ошибки, броадкст по портам и fdb таблицу. Еще плюс - во время гроз при одинаковых условиях 30хх серия горит в 100 % случаев, а 2108 только в 20%. Так что считаем эту серию самой удачной.

Вот еще бы цену узнать ...

www.cacti.netставиться легко и куча уже готовых скриптов на сайте. Если именно Вашего нету - по документации сделать свой - не проблема.

Чуть подправлю - 3560 держит 2k ACE - Коммутаторы Cisco Catalyst. Сравнительная таблица характеристик.

Имеется в виду фильтрация без привязки к IP ? Если да - то подскажите к сторону какой фичи копать.. Можно узнать - что за ограничения ?

Между вланами конечно. Какой нам смысл фильтровать поток между портами в центре ? А если на центральном роутере всего два порта ? :) /sbin/iptables -A FORWARD -p ALL -i eth1.100 -o eth1.101 -j ACCEPT /sbin/iptables -A FORWARD -p ALL -i eth1.101 -o eth1.100 -j ACCEPT А уж на влановский интерфейсы eth1.100 и eth1.101 я могу навесить какую угодно подсеть. И все будет работать. А мне видиться что не найду я реализации подобной гибкости в железе... Техсапорты больших вендоров так ничего и не могут предложить...

После долго ковыряние документов различных вендоров первоначальный вопрос немного трансформировался. Какие в принципе технологии существуют по разруливанию трафика между VLAN, без привязки к IP-подсети этого VLAN ? Т.е. когда идентификация осуществляться или по VALN ID или по интерфейсу влана. На сегодняшний момент я знаю только одну - PC роутер (Linux/iptables, FreeBSD/ipfw и все производные от них). Тут идентификация идет как раз по интерфейсу влана. Имеется в виду технология фильтрации маршрутизируемого потока тегированных VLAN. А еще есть какие-то технологии ? (вендор, типы и количество интерфейсов, цена пока не учитываются)

Да это не так важно. Если GE, то достаточно и 2-х, если FE - то 3-4 портов. А уж разветвитель вланов-то найдем без проблем.Главная загвоздка - это именно разруливание между вланами. В этом PC и хорош - там каждый влан - в файрволле можно с помощью интерфейса разрулить, что на порядок упрощает задачу. А в свичах, насколько нашел информацию, ACL - единственный вариант - это по подсетях источника-назначения. Если влан и можно использовать, то только источника, а не сразу источника/назначения. Да так и есть. Основная масса клиентов - домашние пользователи, сидят в подсетях /28 из подсети 172.18.0.0/16. Но есть и юр.лица, которым нужные реальные IP без ната, для них и проброшено несколько вланов с реальными IP, над которыми в последствии не используется NAT.Поэтому и получаеться что создание ACL на основе IP источника/назначения приводит к большому количеству правил, так необходимо описывать все ситуации можно/нельзя и нельзя перейти к схеме - [разрешено что-то, а в конце запрещено все]. Ибо последним правилом убъеться работа инета (весь инет не опишешь в ACL)

Имеем сетку на 700 хостов с хорошими темпами роста. В центре стоит L3 коммутатор. На текущий момент на нем около 20 VLAN. Средний траф примерно 100-120 Mbits. Готовимся к большому сегментированию сети по VLAN. Планируем довести их количество до 100 (и до 170 через полтора года). Стоит большая проблема - как сегментировать траффик, т.е. четко разделять какому VLAN с каким можно гонять траффик, а какому - нет. Ищем оборудование с поддержкой вышеуказанного кол-ва VLAN и IP-интерфейсов. Желательно сегментация именно по VLAN источника/назначения, так как адреса внутри VLAN-ов с разных сетей (т.е. наши серые, реальные инетовские, managment VLAN). По производительности и гибкости - хорошее решение = PC-роутер, но не удовлетворяет в плане надежности (да и не солидно как-то комп в ядро сети ставить.. :) Какой вариант можете предложить ? Сначала будем смотреть технические возможности, потом цену, ибо интересует вариант с возможностью роста, т.е. с запасом на будущее.

Ну в общем после нескольких часов терзаний отчасти добились желаемого. Вот конфиг, может кому поможет: SYSTEM STACK ROW| Layer Status| -----------|------------------------------------------------------------------| 1| slot.1.1 Tcom4 T1 Driver enabled up | 2| slot.1.1 cbq.1 enabled up | 3| slot.1.1 t1.1 enabled up | 4| slot.1.1 ppp.1 enabled up | 5| slot.1.1 ip.1 enabled up | 6| slot.1.2 Tcom4 T1 Driver enabled up | 7| slot.1.2 cbq.2 enabled up | 8| slot.1.2 t1.2 enabled up | 9| slot.1.2 ppp.2 enabled up | 10| slot.1.2 ip.2 enabled up | config ppp.1 receive-control-map "0x00000000" transmit-control-map "0x00000000" config ppp.1 ip-connect-mode open config ppp.2 receive-control-map "0x00000000" transmit-control-map "0x00000000" config ppp.2 ip-connect-mode open config t1.1 clocking internal config t1.2 clocking internal config t1.1 physical-layer line-type e1FAS line-coding b8zs data-link-facilities dsx1 config t1.1 physical-layer clock-source internal interface-type e1 timeslot-mask "1-32" config t1.2 physical-layer line-type e1FAS line-coding b8zs data-link-facilities dsx1 config t1.2 physical-layer clock-source internal interface-type e1 timeslot-mask "1-32" stack slot.1.1 cbq.1 t1.1 ppp.1 ip.1 stack slot.1.2 cbq.2 t1.2 ppp.2 ip.2 add ip.1 address.0.0.0.0 net-mask 255.255.255.255 src-addr xxx.xxx.xxx.xxx add ip.2 address.0.0.0.0 net-mask 255.255.255.255 src-addr xxx.xxx.xxx.xxx add ip.loopback address.xxx.xxx.xxx.xxx net-mask 255.255.255.255 router-address true И вот самое главное: add ip static-route.0.0.0.0 mask.0.0.0.0 tos.0 next-hop.ip.1 add ip static-route.0.0.0.0 mask.0.0.0.0 tos.0 next-hop.ip.2 Это позволило запустить инет при двух каналах. НО, реально работа идет по одному каналу. На втором канале (тот, что нам только-что добавили) на IP интерфейсе вообще нет входящих пакетов. При указании только одного правила (add ip static-route.0.0.0.0 mask.0.0.0.0 tos.0 next-hop.ip.1) инет живет отлично, но как только добавляю второе правило (add ip static-route.0.0.0.0 mask.0.0.0.0 tos.0 next-hop.ip.2) то сразу появляются периодические провалы в связи. Такое ощущение, что после прописывания второго правила пакеты от нас идут часть по первому каналу, часть по второму. И вот те, что идут по второму - не уходят дальше шлюза, что и вызывает провалы... Будем еще разбираться - у нас этот трабл или у ТТК. Поэтому хочу уточнить у тех, кто имеет опыт по работе с несколькими каналами Е1, без разницы на каком оборудовании: 1. Есть ли среди каналов "Главный", или все они равнозначны ? 2. Если один из двух каналов упадет - продолжиться ли нормальная работа вцелом (кроме снижения пропускной способности) ?

Немного не в тему, но по сути вопроса. (Может поможет.)Так у Cisco (Router) для STTK: Спасибо, поедем пробывать. Мы проверяли таймслоты при настройке одного потока. Ставили 1-32 и все работает. Еще смущает то, что в присланном конфиге от ТТК наш IP идет с маской /32 а шлюз вообще в другой подсети класса В с той-же маской /32, как между ними должен идти роутинг - не представляю.

Ситуация в следующем. Подключены к провайдеру ТТК. У нас оконечное устройство - Lucent AP 450. Раньше использовали 1 Е1. И все было в порядке. Встал вопрос о расширении канала. Взяли еще один поток. Настройки на второй поток прислали такие-же, как и на первый: > IP addr customer: ххх.ххх.ххх.х3 /32 > Rate limit: 2048 Kbps > Port config > Controller: SONET > > Framing: framed > Time slots: 1-31 > Clock source (TTK): internal > Encapsulation: ppp Во первых, странная маска тайм-слотов. Поставили 1-32 - все работает. Самое главное - когда брали один поток, IP висел на ppp интерфейсе и все было хорошо. Теперь, для объединения каналов в сумме до 4 мегабит, необходимо менять настройки. Что мы сделали: 1. Навесили IP на loopback 2. На обоих ppp интерфейсах прописали IP 0.0.0.0 с src-addr нашим IP 3. В настройках loopback интерфейса прописали router-address true Соединения ppp поднимаються, но траффик не идет. Есть предположения, что не идет пересылка пакетов непосредственно с ppp интерфейсов на loopback и обратно. С локальной сети IP на loopback интерфейсе пингуеться. Если у кого есть опыт по настройки объединения нескольких каналов Е1 на АР450 - пожалуйста, киньте конфиг. Заранее благодарен.

Меня тоже интересует законность такого мероприятия. Ведь рапидшара работает как-то, хотя на ней много чего лежит в архивах, в том числе и нелегельного. Получаеться, что можно предоставить сервак для заливки контента абонентами, а что они там заливают - не проблемы оператора.. Или все-таки и это незаконно ? P.S. и имею в виду законность наличия этого контента в общем доступе, без взимания денег за сам доступ - просто законность развалов фтп.

Дано: Сеть, разделенная VLAN-по портам. Надо: Организовать игровой сервер PvPGN, который требует наличия прямого коннекта между клиентами. Решение: Есть идея поднять на компе с PvPGN сервер VPN, и разрешить клиентам взаимодействовать между собой (лучше с возможностью фильтрации протоколов/портов взаимодействия). Естественно, ни какого шифрования не надо. Все это будет крутиться на XP. Серверную ось не ставлю, так как машина не такая мощная. Ищу софт для организации VPN-сервера на XP с вышеперечисленными требованиями. Пока из всего просмотренного лучше всего подходит OpenVPN, но не нравиться в нем то, что нет отдельной клиентской части, в её роли выступает сам-же сервер, но с клиентским конфигом. Мне бы лучше решение для клиента - типа "Поставил-нажал-и забыл". Может кто подскажет соответствующий софт.

Нет под руками этого устройства. Может подскажите - маршрутизация - подразумеваеться создание статических маршрутов или возможность роутинга между LAN и WAN сетями без NAT-a ?

А как же быть тогда с "поросятами" ? Т.е. после авторизации на порту абонент может поменять все свои сетевые реквизиты.

Русскую не нашел. (вернее не искал :) Eng - http://www130.nortelnetworks.com/cgi-bin/e...ranProduct=9102 Есть правда в ваших словах. Это определенный риск. Но, в DES-3828 есть именно та функция, которая мне нужна, и которой нигде (пока) не могу найти - IP-MAC Binding. Да и про ACL ничего в UserGuide к BPS не нашел. Зато (SA MAC) и (protocol-based) VLANs - это очень даже гуд.

1. Т.е. MAC совсем не контролировать ? Или в другом месте ? (в каком тогда..) 2. Полностью согласен. Я этого и не отрицал. Логин/пароль - это хорошо, когда речь идет тока об инете. А с локальными ресурсами ? На игровые тоже логин/пароль ставить ? 3. Хм.. А для домохозяек мне курсы проводить ? IMHO, чем меньше настроек у абонента - тем меньше гемора у службы поддержки. 4. Собственно, а изоляция клиентов ?

Я под "Сегментацией" принимал функцию на свиче, которая позволяет определить какой порт с каким может обмениваться данными, а с каким нет. Позволяет на не очень умном свиче создать схему - 1 общий порт, остальные порты - клиентские. Клиенсткие могут взаимодействовать только с серверным портом.

Посмотри DES-3828. На нем 500 записей можно создать IP-MAC Binding. И не надо будет комп ставить. Надо отключить клиента - удали(измени) его запись IP-MAC Binding.

Ткните носом, где можно почитать поподробнее про авторизацию через SNMP. Очень интересно. Согласен, поэтому и писал сразу что этот элемент наверняка можно заменить. Вот сейчас и ищу альтернативу. Думал - может кто что предложит. В основном все упираеться в возможность сегментации трафика, если без нее - то есть куча предложений.

Ага. только я же написал - схема для ДС. А в ДС кроме шлюзовой есть еще серваки, и не все они под Unix-системами. А на Win делать привязку - это уже гемор. Поэтому IMHO, лучше на свичке. Да и экономия 900$ из расчета даже на 150 абонентов - не такая уж большая. Кроме того, эта схема позволит в дальнейшем без затрат перейти, в случае необходимости, на 802.1q! Опять-же IMHO, если есть возможность ставить свичку, я всегда выберу её а не Unix-сервер.

Позвольте уж и мне свое видение схемы описать. Сразу скажу - у нас эта схема пока еще не используеться - нет необходимого оборудования. Но в ближайщие месяц-полтора мы её запустим полностью. Во первых - не посчитайте меня ярым сторонником фирмы D-Link, просто мы с этой фирмой много работаем по поводу радиооборудования, поэтому и в схеме я буду указывать оборудование их марки. Хотя, значительная часть элементов можно заменить продуктами других вендоров. Данная схема не предназначена для сетей с количеством абонентов > 1k. Итак: 1. На домах ставим абонентский свич. В нашем случае - DES-2108. От него нам интересно: Port security и Сегментация трафика. Собственно, на каждый порт привязываем абонентский MAC и разрезаем все порты друг от друга. Вот как раз здесь наверняка можно найти аналогичную свичку другого производителя. Далее, в центр ставим DES-3828. От него нам нужна прежде всего необходима одна изюминка - IP+MAC blinding. Эта фича (как я понял) являеться продолжением static ARP, но кроме ip защищает также и MAC. т.е. через свичку теперь не может пройти пакет с таким-же IP но другим маком, и с таким-же MAC, но другим ip. Как сообщили мне в региональном представительстве D-link в четвертом квартале 2005 г. должна выйти следующая версия прошивки для 3828, в которой уже можно будет делать привязку IP+MAC+PORT. Получаем: 1.Абонент не может сменить MAC - так как тогда не пройдет дальше абонентского свича. 2.Абонент не может сменить IP - так как тогда не пройдет выше центрального свича. 3. Абонент не может сменить и IP+MAC одновременно. 4. За счет сегментации трафика абоненты изолированы друг от друга на L2. 5.Полный контроль над всеми абонентскими портами. Стоимость ооборудования: DES-3828 - примерно - 900$ DES-2108 - примерно - 90$. Сфера приминения - в ДС (или участках ДС) с кол-во абонентов от 150 до 350. Плюсы: +изоляция абонентов; +отсутствие возможности НСД (несанкционированного доступа к сети) стандартными способами (сменой сетевых реквизитов); +нет никакой настройки оборудования со стороны клиента; +нет необходимости в каких-либо дополнительных программных средствах Минусы: -Это все-таки D-Link. Хотя в качестве абонентских свичей наверняка можно найти замену. -Крики абонентов о невозможности поиграть в сетевую игру с соседом. Отчасти решаеться отключение изоляции между некоторыми портами. -трафик не идет через сервер - следовательно нет полного контроля. (В принципе, если нет НСД, то необходимость полного контроля не так остра); -нельзя (если и можно, то я еще не нашел способа) логировать попытки НСД. Вот собственно моя схема. Жду комментариев, особенно с критикой :).

Подскажите, кто работал с BR-6104KP ответ на один вопрос. В описании говорится про возможность работы в режиме моста. Означает ли это то, что на него можно повесить два ip из разных сегментов (WAN и LAN) и отключить NAT? Очень нужно недорогое устройство, которое бы просто работало мостом между подсетями, не используя NAT, но с возможностью ACL.