Sultan

это всё (с оговорками) умеет обычная фря

802.1q, bw limiting, traffic classifier, и т.п. policy routing, ospf/bgp, возможность bridging'а интерфейсов, ip accountg на интерфейсе в обоих направлениях (a-la ng_ipacct) с возможностью фильтрации того, что считаем, netflow (на любителя), nat, ssh, statefull fw, желательно, с процедурным стилем, pptp/pppoe, gif. это на вскидку, что мне нужно от маршрутизатора.

зачем так много портов?

на rtl'ах (чипах для nic) нет rxcsum и txcsum offload, по-моему.

Пока я нашел только, что обещалась корректная работа с 802.1q, что ни о чем не говорит, т.к. под этим может подразумеваться просто транзит тэгированных пакетов. т.е. обычный хаб, в таком случае, тоже корректно работает с 802.1q. По поводу "будут вопросы" - вопросы не исключены в любом случае :) Пока я нашел только то, что 802.1q не будет.

написать "будет" или "не будет", по-моему было короче :)

1. делать больше 3-4-х веток внутри одного "отряда" (8-портовых L2) - это уже смущать потребителя :) с другой стороны, тут могут быть вариации и на одном и том же чипсете, т.к. можно варьировать "обвязку". 2. делать snmp без ip acl и без возможности спихнуть его в отдельный vlan(802.1q вообще предполагается?) - это будет вредительством. я неправ?

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

Вообще, свичи нужны со страшной силой. Чьи - вопрос цены.

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

Больше 0.34 от стоимости des-3226s не дам :)

Не знаю, как остальным, а мне было бы интересно, если б конечный продукт умел следующее: 1. управление по rs232 (для минимизации места можно и RJ45 вместо DB9 ), 2. управление по telnet (не менюшка, а cli) + acl на telnet, 3. snmp + acl на это дело, 4. 802.1q: а) полный диапазон тэгов, б) возможность вынести управление в отдельный vlan, в) возможность организации транзита тэгов через выбранные порты, 4. rstp, ну или stp на худой конец, 5. возможность ограничения скорости порта (простой drop пакетов) от 1Mbps с шагом в 1 Mbps.

расскажи, как в сетке из пары сотен клиентов сделать это "мытьё рук" при условии, что нужны реальные айпишки (не обсуждается), и примерно 10% траффика идёт между юзерами я уже предлогал - читай еще раз.

даже если мы не можем айпи к порту привязать - то с неизменным МАКом он вычисляется с полпинка и его порт просто даунится автоматом к этому можно лёгко прикрутить arpwatch какой-нить Это опять "лечение глистов", а не "мытьё рук". Я предлагаю "мытьё рук".

Повторяю еще раз - вы фиксируете на порту свича mac, но вы не можете контроллировать на порту свича ip. у вас остается единый broadcast domain. так что предлагаю самому rtfm. попомните мои слова - всегда найдется дурак, который попробует прописать себе частный ip вашего гейта или своего соседа, для непонятливых поясняю: в тырнет он таким образом не выйдет, но вы скипидару заработаете.

я подразумевал возможность фильтрации tcp/udp 135-139 и rpc-шных виндовых дыр. фильтровать http-трафик я и не предлогал - всё есть в условиях договора.

у вас тут две "засады": 1. не обеспечивается бесперебойность сервиса (вспоминаем про замену в нерабочее время "сломанной" карточки - не каждый день, но оператора характеризует не 99% времени безотказной работы, а 1% времени простоя) 2. вы незащищены от баловства клиента, когда он может свалить любой ipв сети, прописав его себе. 3. у вас отсутствует возможность предотвращения распространения вирусов в вашей сети (оператор может получить по башке, если с его сети начнут валить вирусы. я предпочитаю лечению профилактику). насчет полной бесполезности mac security, признаю - я неправ, но "вредоносность" за этим делом всё ж водится.

99% наших клиентов живут с реальными айпишками Простите, а что Вы догда подразумеваете под доступом в Internet? Я уже писал где то, что если это NAT, Proxy и т.п. вещи - это не Internet, это внутренняя сеть с присоединением к Internet. Причем на "прикладном", а не "транспортном" уровне. Это абсолютно нормально и правильно для внутрикорпоративной сети, и абсолютно неприемлемо для договора с абонентом. Во всяком случае, я не взял бы такой договор. А про 99% мне как то все равно. То есть дайте мне реальный IP и никаих фильтров! я буду фильтровать то, что меня обяжут фильтровать, но такую возможность я должен иметь. а сполитикой продаж вы поторопились эдак до ввода IPv6... А это вообще странно. Сначала делать нормальную с точки зрения построения сети структуру, т.е. никакой авторизации, паролей, 100% разделение пользователей и т.д. - и тут же прикручивать туннели! "Робот-манипулятор берет болванку и засовывает ее в пресс времен братьев Карамазовых"... Просто опять выплывает забавная вещь - TCP/IP при нынешнем числе адресов и хостов - протокол больше для локальной сети. это не странно, это разумно, если пытаться юзать ethernet в таком качестве. можно давать клиенту и подсети (dhcp), но тогда будет повышенный расход ip (похоже, что вас подобный вопрос не заботит, либо у вас пара-тройка клиентов). иначе вам надо юзать frame ralay или atm (готовы за это платить?). а так у вас получается большая локалка с методами организации уместными для внутриквартирной сети, а никак не операторская сеть передачи данных.

кому как... еще раз повторяю - mac security не защищает ни от mac spoofing, ни от ip spoofing. без vlan из сети получается болото.

2) "если вы не предусмотриели какой-то ситуации, то это не значит, что такое не может случиться" :) ситуация элементарная - у некоторых дома лежит карточка в запасе. в результате "форсмажора", используемый в данный момент сетевоф интерфейс вылетает - меняем карточку. "а дело было вечером..." - делать до утра нечего :) 3) элементарно - делал одинаковые mac машинам, сидюящим в разных vlan'ах. напоминаю, что маршрутизация разделяет broadcast domain.

2) круглосуточно "сексовать" - дорогое удовольствие, а я говорил именно про нерабочее время. 3) маршрутизатор тоже будет работать нормально - проверенно.

99% наших клиентов живут с реальными айпишками если нужно дать один-два реальных ip, то можно поставить pptp/pppoe-сервер и давать его оттуда. L3-коммутатор, который может быть на магистральным, а не центральным. свои недостатки есть, но достоинств больше. чтоб народ файлом менялся - проще поднять p2p-сеть. Вот тут от лайткомовского коммутатора желательна бы такая фича, как ограничение скорости на порту с мегабитным шагом (от 1 Mbps).

Именно так эт как сказать... за сколько абонент заплатит - столько и дать. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 - мало? Например? Народу в отделе "секс по телефону" меньше держать надо.

"Гостем" в антиMACовых постах был я :) это называется "секс по телефону", без которого вполне можно обойтись указанным мной способом. нормальному свичу должно быть пофиг, что творится в разных vlan'ах, т.е. пусть хоть десять одинаковых mac, но каждый в своем vlan. ip проще выдавать по dhcp с привязкой к vlan. считаем себе преспокойно трафик по подсетям и в ус не дуем. тут же получаем еще одно преимущество - если абонент заводит еще один компьютер, то он тоже получает доступ в инет (если не кончились ip в выдаваемой подсети), следовательно увиличивает доходы оператора. :) тут есть одно "но" - в этом случае dot1q должен терминироваться не писюком, а L3-коммутатором (d-link 3326, наример), а писюк с биллингом ставится на "аплинковый" порт.

хочу на пингвинячей проксе настроить vlan'ы, но понятия не имею, что нужно делать на свиче. Может кто-нить настраивал такое на i460t?