Новый пакетный фильтр для борьбы с флудом на уровне Linux ядра

Послушал индуса.
http://www.youtube.com/watch?v=-Y9kbhmUuek

Когда-то давно на отдельно взятом линуксовом маршрутизаторе я за два дня решил проблему DDOS со стороны дикой домовой сети связкой tcpdump + bash очень похожим образом. Скрипты потом без нареканий проработали больше года.
Схема была не гибкая, учитывала только небольшую часть вариантов флуда, но для тех условий замечательно работала.

Но таки да, это вам не датацентр. И траффик был смешной - 100-400 Мбит/с.

спору нет, индусы руляд )

Что такое Linux ядра? Интересно, а Linux головного мозга бывает? Не у всех же есть собственное ядро.

Добавили бы тег "сети".

>также ждем аналога accf_http

http://articles.techrepublic.com.com/5100-10878_11-1050878.html

> http://www.cisco.com/en/US/products/ps6235/index.html

Чуваг, не слушай ты этих дураков, орущих про Cisco. Многие из них не в состоянии отличить L3-коммутатор от программного маршрутизатора. Catalyst 6500 -- очень хороший, но для того, чтобы просто блокировать или шейпить нескольких тысяч IP на скоростях до гигабита, он слишком дорог. С такой задачей вполне справятся компы с Linux или FreeBSD.

По сабжу. Лучше бы разработчики netfilter допилили и включили в ядро модуль ipset, осуществляющий поддержку таблиц IP- и MAC-адресов в iptables. Драйвер e1000 -- известное глюкало, и сейчас он теряет актуальность, т.к. на всех новых материнках сетевухи висят на шине PCIe, а у них свой драйвер -- e1000e. Поэтому никаких реальных преимуществ перед ipset у представленного поделия нет.

спасибо за лестный отзыв обо мне и моих коллегах )
Наверно, Вы тоже немного путаетесь...
Catalyst 6500 это просто шасси, на них цепляются сервис модули, про один из которых мы и говорим в контексте защиты от d[d]os, а для фильтрации или блокировки, обычно применяют совсем другой модуль.

даешь замену киске !

> а для фильтрации или блокировки, обычно применяют совсем другой модуль.

Но он тоже Ъ-ынтырпрайзный. 32000 правил, нереально долгий обсчёт, и т.д. А при частом обновлении всего running-config ещё и перезагрузки требует периодически.

Обычные компьютеры, на которых маршрутизация делается средствами CPU, никогда не будут эффективнее аппаратных решений. У L3-свичей стоимость на порт будет ниже, чем у любого кластера из говноPC. С другой стороны, заменить, скажем, маршрутизатор из устаревшей серии Cisco 7200 на машину с Core 2 Quad вполне можно уже сейчас, она тоже сможет держать гигабит с несколькими сотнями тысяч pps. Но в качестве border gateway ее все равно нельзя поставить, потому что для Linux на сегодняшний день нет ни одной нормальной реализации BGP. Quagga -- решето с утечками памяти. OpenBGPD -- получше, но работает только под *BSD. Сделайте дистрибутив с нормальной реализацией BGP и OSPF, с неизбыточным шеллом, простыми и единообразными конфигами для всех сетевых настроек и демонов, тогда и можно будет верещать о замене брэндового железа.

> Обычные компьютеры, на которых маршрутизация делается средствами CPU, никогда не будут эффективнее аппаратных решений.

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

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

> Но в качестве border gateway ее все равно нельзя поставить, потому что для Linux на сегодняшний день нет ни одной нормальной реализации BGP. Quagga -- решето с утечками памяти.

А то циску нельзя положить?
Зато, например, quagga умеет держать несколько AS.

> Сделайте дистрибутив с ... с неизбыточным шеллом, простыми и единообразными конфигами для всех сетевых настроек и демонов

Зачем? И чем Вам не нравятся существующие дистрибутивы? В любом случае, красоста конфигов и системы управления - вопрос максимум недели дя опытного юниксоида.

> тогда и можно будет верещать о замене брэндового железа.

Нет, о замене брэндового железа никто не говорит. Величина откатов пострадает.

> Величина откатов пострадает.

зачем ты трындишь о том, к чему не имеешь ни малейшего отношения?

> А то циску нельзя положить?

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

> В любом случае, красоста конфигов и системы управления - вопрос максимум недели дя опытного юниксоида.

Вы работали с IOS и JunOS или чисто теоретически рассуждаете? Брэндовое железо -- это готовое решение, которое достаточно только настроить путем ввода нескольких команд, а не сырой материал, из которого нужно собирать это решение. Опытный юниксоид должен провозиться как минимум несколько дней с тем, чтобы довести машину до нужного функционала: скомпилить ядро, потюнить, отредактировать конфиги, поставить пакеты и т.д. и т.п. Люди платят Cisco за отсутствие этого гемора и за какие-никакие гарантии того, что их продукт будет решать поставленную задачу. Про самопал на базе PC ничего нельзя сказать с уверенностью, пока его сам не соберешь и не оттестируешь.

> Но он тоже Ъ-ынтырпрайзный. 32000 правил, нереально долгий обсчё
эт точно - до сих пор без смеха не могу вспомнить как кошковод в 6513 полтыщи правил засовывал - понятие цепочек как в iptables им д сих пор неведомо. про 65xx кк свич ничо плохого не могу сказать, но вот его FWSM - как раз гавно ещё то.

> достаточно только настроить путем ввода нескольких команд
даааа?
а что делать когда у тебя одних только правил для FW под 7000?
гнать не надо!
ядро я уже забыл когда компилил в новых дистрах, аналоигчно про настрйоки

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

Пример с Anomaly Guard Module был более интересен.

>> Величина откатов пострадает.

> зачем ты трындишь о том, к чему не имеешь ни малейшего отношения?

Я не технарей обвиняю и не самих cisco, а интеграторов.

> Вы работали с IOS и JunOS или чисто теоретически рассуждаете?

JunOS - нет. Cisco IOS - постоянно, имею полсотни девайсов от cisco разного уровня, И 6500/7600 в том числе.

> Брэндовое железо -- это готовое решение,
> ... многабукаф ...
> Про самопал на базе PC ничего нельзя сказать с уверенностью, пока его сам не соберешь и не оттестируешь.

А с этим я и не спорю.

> до сих пор без смеха не могу вспомнить как кошковод в 6513 полтыщи правил засовывал

Потыщи - это что-то Вы уже привираете. Когда правил всего пара тысяч, они хаваются мгновенно.

Замечательно! Осталовь написать пакетный фильтр для борьбы с троллями...

Эк ему сессию срезало - полуслове!

Оно уже рабо

А как посмотреть, сколько памяти в ядре занимает открытое TCP соединение? или хотя бы все текущие TCP соединения?

lsof, fuser если под линуксом

> хаваются мгновенно
смех не в том что медленно "всовывается"
а то, как это построенно - на уровне 70-80-х - примерно как нетбиос -в виде одного списка без ответвлений

> использовании нужных устройств в нужных местах (т.е. правильный
> дизайн)
ну-ну. сферических коней в вакууме?
очнитесь - это настошая жизнь, а Вы - не Нео!
обычно всё выходит по формуле "гладко было на бумаге".
на само деле Сиьска по части конфигурации ACL отсасывает у iptables и pf
и даже частичное засовывание в ASIC ей не помоагет, увы(вздох)!

> ну-ну. сферических коней в вакууме?
> очнитесь - это настошая жизнь, а Вы - не Нео!

какие кони? я тебе говорю про конкретные проекты, реализованные мной и моими коллегами.


> обычно всё выходит по формуле "гладко было на бумаге".

не обобщай )


>на само деле Сиьска по части конфигурации ACL отсасывает у iptables и pf
> и даже частичное засовывание в ASIC ей не помоагет, увы(вздох)!

ты снова про ерему? ACL и прочее это вынужденная мера, костыль, я бы сказал.
http://www.linux.org.ru/view-message.jsp?msgid=3406611&lastmod=1232006297...

> Обычные компьютеры, на которых маршрутизация делается средствами CPU,
> никогда не будут эффективнее аппаратных решений
> У L3-свичей стоимость на порт будет ниже
по-моему Вы путаете тёплое с мягким -
1) стоимость порта когда говорят про маршрутизацию обычно ставят не 1 место, собственно это и не обсуждалось, хотя тема очень спорная, особенно памятую про вот это:
http://asterisk.org.ru/index.php?option=content&task=view&Itemid=1&am...
http://asterisk.org.ru/index.php?option=com_joomlaboard&func=view&id=...
да - и огласите стоимость порта в 7206 и 6509 - одни из самых ходовых агрегатов в расчётет на 3-5 BGP uplinks - тоже ходовая конфа
я , чтобы не быть голословным, оглашу стоимость работавшего решения на PC/Linux: 2 рабочих соседа по BGP (постоянно работающие), 1 - потенциальный (протестирован, обычно не работает - запасной), +1 - на приватной AS просто линк проетсирован был (нагрузка на 4 BGP peers).
IBM x305 PIV-2/512MB с 4-портовой Intel 4x1GE (чип там Тнудра был ЕМНИП) в дополнение к 2 своим плюс 1 линк на G.703 был.
вместе с достаточно дорогой Digium E100P - <3000$, цены 2003 года
стоиомтсь за полноценный порт - ~430USD (3000$/7портов)
огласите цену за порт в 7206 при 7-портовой конфигурации?
и 2) хочу посмотреть на действительно "аппаратный" BGP-рутер - лажу в виде NPE не предлагать, хочу именно "аппаратный" - то есть без участия CPU и полностью на ASIC/FGA

А никто и не говорит, что у 7206 стоимость на порт ниже. По этому поводу речь шла о L3-коммутаторах, которые применяют на уровне агрегации и в ядрах крупных сетей. От них не требуется особого интеллекта, главное чтобы держали нужный пакетрейт.

Бордеры -- отдельная песня. Здесь важна не стоимость на порт, а надежность работы всех компонент, т.к. портов обычно мало. Претензии здесь в основном не к Linux, а к Quagga. Если она у вас работала без вопросов и не страдала при этом от утечек памяти, то я очень рад. Однако, в ответственных случаях я предпочитаю не гадать заработает Quagga или не заработает, а использовать проверенные решения.

> хочу посмотреть на действительно "аппаратный" BGP-рутер

Аппаратно реализуют только саму маршрутизацию, а не протоколы маршрутизации (в том числе BGP), которые редактируют таблицу. В IOS и JunOS программная реализация полноценна и надежна. О Quagga такого сказать нельзя. По поводу вменяемой аппаратной маршрутизации можно посмотреть в сторону модулей для M-серии Juniper и на старшие серии Catalyst'ов.

> на само деле Сиьска по части конфигурации ACL отсасывает у iptables и pf > и даже частичное засовывание в ASIC ей не помоагет, увы(вздох)!

Почему частичное? Полное. У Вас не случалось ситуации "переполнения правил", когда циска начинает фильтровать софтварно ? ) Жопа полная.

>> хаваются мгновенно
> смех не в том что медленно "всовывается"
> а то, как это построенно - на уровне 70-80-х - примерно как нетбиос -в виде одного списка без ответвлений

Насколько я понимаю, скорость "всовывания" как раз и получается столь "медленной" из-за того, что циска внутри себя строит некое дерево на аппаратном уровне.
Когда Вы добавляетет строчку в iptables, тоже происходит полная "распаковка" всех правил таблицы, и полная "упаковка" обратно. Что при действительно большом количестве правил довольно заметно, только расходуется не cputime, а оперативная память. Сожрать сто тысяч правил на современном железе - две секунды, но полгига оперативы. Тоже не всё гладко.

> так в том то и дело, что при использовании нужных устройств в нужных местах (т.е. правильный дизайн) позволяет избежать таких диких аксес листов и прочей порнографии.
> chocholl * (*) (14.01.2009 18:06:18)

ОК, если Вас не затруднит, изложите вкратце рекомендуемый Вами дизайн дл я следующего случая типичной домовой сети:
Предполагается подключить в одном микрорайоне 30000 физических лиц к услуге доступа в Интернет. Тарифы делаются в соответствии с рынком - в итоге получится примерно 10К с полосой в 1Мбит/с, 10К с полосой в 2Мбит/с, 10К с полосой в 5Мбит/с. На каждый дом распределение по скоростям примерно одинаковое.

> Люди платят Cisco за отсутствие этого гемора и за какие-никакие гарантии того, что их продукт будет решать поставленную задачу.

Вообще, в реальной жизни претензии к циске не в том, что она чего-то не умеет или не решает. Напрягает ситуация, когда возникает желание что-то поменять, дополнить. И тут выясняется - без недокументированной команды service unsupported-transciever мы не принимаем чужие SFP, половина модулей не работает с sup32, работает только с sup720, если Вам вдруг потребуется поддержка OSPF на железке, платите ещё пару килобаксов за "продвинутый" IOS, и т.д. Таких неприятных моментов - море.

И, кстати, добавим реальных задач:
Есть задача иметь возможность нарезать полосы для полумиллиона абонентов - что порекомендуете, уважаемые цискари?
Есть задача делать NAT на пять миллионов трансляций на скорости 10Гбит/с и 2Mpps - сколько стоит и каково решение?

> По этому поводу речь шла о L3-коммутаторах, которые применяют на уровне агрегации и в ядрах крупных сетей. От них не требуется особого интеллекта, главное чтобы держали нужный пакетрейт.

А как бы сделать красиво так, чтобы хотя бы от ping -f на них самих этим тупым L3 коммутаторам, типа 3500, плохо не становилось? )
Ключевое слово - красиво.

Капча - Балмер? o_0

Linux - ruleZZZ!
Cisco - suXXX!

> не говорит, что у 7206 стоимость на порт ниже ...
> речь шла о L3-коммутаторах
по грубой моей прикидке, GPL для 6509 даже с 48 портами и учётом портов на спервизоре - меньше ~430USD - не выходит, если убогий 48-п в расчёт не брать а брать реально пацанские модули - выходит под косарь за порт. где L3 дешевле? и это ещё без цены FWSM! где дешевле-то?
дело тут совсем не в цене. я,к стати, ничего против 65xx не имею как свичей.:) хотя дохло всё.
> Здесь важна не стоимость на порт, а надежность работы всех компонент
> т.к. портов обычно мало
да-да - я эту песню знаю. сдыхают и 7xxx.
а стоимость порта всёж-таки учитывается - о чём на астериске человек и написал. ну в самом деле - глупо переплачивать? ну ладно, раз Вы сливаете вопрос по-тихому, тогда рассажу про него я.
действительно, 7206VXR/NPE-G2 7206VXR with NPE-G2 includes 3GigE/FE/E Ports and IP SW = стоит около 5k$, ну можно до 18k$ отжать наверное
при этом если мы говорим про отказоустойчивость 1 киска - не выход, то есть надо 2. итого 36k$
ну - можно 7201 взять, тем более что там 2 гига можно поставить -деньги те же.
да, в нашем случае x305 явно был похуже - 1 PSU и т.д. но это легко компенсируется дешевизной и простотой замены - когда у нас была проблемка с PSU на IBM - на эти 2 дня был просто поставлен обычный пицук. ну пусть мы бы двойной компелкт купили (как изначально я предлагал) - 3k$*2=6k$ при этом 3килобача - это цена вместе с дорогой E1 платой. по идее в цене киске надо модуль соотв. тоже учесть. ну ладно, пусть так.
моя фамилия итого по ведомости:
cisco 7201||7206vxr - 36k$
брендовый pc - 6k$
кстати, тот ibm работает до сих пор (5,5 лет!) но стоимость и простота его замены таковы что это можно сделать почти в любой момент (как любят говорить соотв. марктелоги, "it provides assurance of upgrade paths ;), 3k$- это стоимость решения на уровне начотдела в любой средней конторе (>100 чел). про 18k$ - уже сомневаюсь.:-)
можо ещё купить пару подобных пицюков - всё равно дешевле будет!
мне могут скзаать что вот у Сиськи 2 БП - да, есть за сравнимые деньги решения с 2 БП и у пицуков но мы были жётско ограничены по срокам и требованиям к надёжности (это в смысле - мы не могли ждать поставки полгода или брать что-то типа самосбора). ну как видиет - подхъод себя оправдал и окупил уже давно.
далее про "надежность работы всех компонент" можете рассказывать только тому кто не видел как Сиська-рутер внутри устроена. чудес ведь не бывает.;)
также особенно весело когда начинают сказки про "чудесные возможности" PIX расскзаывать. особенно младших, первые так помню вообще на десктопном ZX чипсете были собраны из обычных десктопных плат - их даже одно время купить можно было в обычной лавке.
тепреь что касается вот етого:
> Претензии не к Linux, а к Quagga. не страдала от утечек памяти
у нас был bird - первые 2 года (при мне) не было особых проблем,
потом на одном из соседей стал либо падать линк либо наш BGP daemon.
поскольку я уже не был сотрудник - не знаю как это решили. но решили.
потом года через 3,5 пошли какие-т остранные утечки - ну раз в месяц приходилось перегружать по словам бывших коллег (поскольку bird footprint очень мал, а памяти - много - это сразу не чувстовалось, видимо копилось месяц - хотя и Full view)
причём коллеги упорно отказывались обновить ПО хотя я им и совтеовал (там были какие-то исправления по части BGP)
в прошлом году (через 5 лет!) внезапно перестал работаь линк с одним из соседей - изветсной кстати не только в РФ компанией - вот тупо Hodl timer не нравится и всё! причём с того конца упорно отрицали что что-томеняли - валили всё на то что типа ваш пицук корывй - потом другие соседи пояснили что у них тоже есть как они выразились "шероховатости" - что в итоге?
выяснилось, что "шероховатости" реально мешают работать и что те поменяли любимую Вами Сисько на Можжевельник (Juniper).
И по поводу этой проблемы (Juniper interoperability issue with Cisco) даже была открыта заявка (CASE # не скажу, бо не знаю). Так-то вот, дружок, сказки рассказывать про "надежность работы всех компонент".;-)
но bird это не помогло - ведь обновлять его коллеги почему-то не хахотели. ну ладно - переехали на quagga, разобрались , поставили рекомендованные исправления и обновления (в т.ч. не относящиеся к проблеме Hold timer) и - о, чудо! заработало и с Juniper.

> Аппаратно реализуют только саму маршрутизацию, а не протоколы
> маршрутизации (в том числе BGP), которые редактируют таблицу
ээ, по-моему - у Вас некое заблуждение в голове.
протокол - это просто набор неких правил. И более ничего!
Сам по себе он ничего не исправляет нигде.:)
Нужно чтоб кто-то это сделал => необходимость наличия некого автомата, неважно, в железе или в ПО.
Поэтому мне непонятно, что понимается под "реализацией аппаратной маршрутизации", если при этом требуется ЦП и ПО?
Если имеется в виду, что рулением (то есть перекидыванием пакета со входа например ge0/1 на выход fe1/5) BGP занимается соотв. ASIC/FGA - хорошо, покажите мне именно такую модель такого модуля Cisco?
.
прежде чем отвечать - втыкать сюда и подумать: http://www.isi.edu/~johnh/PAPERS/Chang02a.pdf
потом сюда:
http://www.cisco.com/en/US/products/hw/routers/ps167/products_data_sheet09186...
подумать о назначении GSP во флагмане Cisco GSR.
на случай - если не глазам:
Gigabit Route Processor

The GRP is a high-performance engine that provides the routing intelligence for the Cisco 12000 GSR family. It is dedicated to determining the network topology and calculating the best path across the network. The GRP has the following hardware characteristics:

* 200-MHz R5000 CPU
* Optionally up to 256-MB CPU DRAM (default 128 MB)
...
The GRP provides the following key functions:

* Processes interior gateway protocols (IGPs) such as Intermediate System-to-Intermediate System (IS-IS), Interior Gateway Routing Protocol (IGRP), Open Shortest Path First (OSPF), and Enhanced IGRP (EIGRP) to determine the network topology
* Processes external gateway protocols (EGPs) such as Border Gateway Protocol (BGP)
* Creates and maintains the routing table (up to one million route entries)
* Distributes and updates Express Forwarding (EF) tables on the LCs and maintains copies of the tables of each LC for card initialization



понять - что оно и есть то самое ЦП - без решений которого маршрутизация и не делается! и чтобы Xbar перекинул в GSr что-то куда-то - надо чтобы GSP вначале на это посмотрел! то есть это уже не чисто "аппаратный" маршрутизатор!
их просто нельзя сделать (пока!) по технологическим причинам - для этого просто надо изготовить такой супер-вентиль , который даже интель рне потянет. действительно, раз размер BGP FV table уже переваливает за 250мб, а кол-во путей также уже давно превысило сто тысяч - просто физически невозможно такое на ASIC кристалле сделать!
то есть даже на врехнем конце у Cisco нет такого.
и уж тем более такое не будут делать в среднем уровне (7xxx) не говоря уже про нижний конец.

> > обавляетет строчку в iptables, тоже происходит полная "распаковка"
я давно туда в код не лазил, но мне кажется, что Вы - ошибаетесь.
там немного по-другому сделано принципиально. ничо про списки не слышали? вроде их ещё до Паскаля изобрели, в Кнуте ИП есть.
смысл моей претензии даж ене в скорости вдувавания - в конце концов сто тыщ мильнонов правил не каждый день вдувают - вопрос в том что
цепочек нету - и это серьёзный изъян Сисько (и Линукса тоже до ipchains)
причём дизайн самих кискиных процов не накладывает такого ограничения!
я понимаю там в 6509 да ASIC работают но в рутерах-то один фиг cef проц генерит!

Надо внимательнее читать. 7206 -- устаревшая модель, я не рассматривал ее как серьезного конкурента сегодняшним компам, о чем и писал выше. Сравнивались проприетарные реализации BPG и Quagga, доступная на компах. Что здесь не так?

> реально пацанские модули - выходит под косарь за порт > брендовый pc - 6k$

А в ядро крупной сети для маршрутизации внутрисетевого трафика вы что поставите? Много-много "брендовых PC" или все-таки Catalyst? Еще более интересно, как вы потом будете администирировать всю эту кучу PC.

> ээ, по-моему - у Вас некое заблуждение в голове. протокол - это просто набор неких правил. И более ничего! Сам по себе он ничего не исправляет нигде.:)

Я говорил о "реализации протокола", а не о самом протоколе. Кроме того, я никогда не утверждал, что BGP где-то реализовано аппаратно. Это действительно технически невозможно.

> потом года через 3,5 пошли какие-т остранные утечки - ну раз в месяц приходилось перегружать по словам бывших коллег

Об этом и речь. Quagga -- глюкало из той же серии, была по крайней мере, не знаю как сейчас. По мне так лучше иметь платную реализацию BGP без утечек, чем бесплатную с утечками. Если Quagga или какую-то еще реализацию таки доведут до ума, и ей можно будет доверять, то я буду только рад.

> И по поводу этой проблемы (Juniper interoperability issue with Cisco) даже была открыта заявка (CASE # не скажу, бо не знаю). Так-то вот, дружок, сказки рассказывать про "надежность работы всех компонент".;-)

Interoperability -- это вообще-то проблема недобросовестной конкуренции, а не надежности реализации конкретного устройства и софта на нем. То, что вендоры не могут между собой договориться о единых стандартах, всецело на их совести.

Anyway, у брэндового железа есть свои ниши, где его по чисто техническим причинам нельзя заменить решениями на базе Linux. Иначе его производители давно бы обанкротились. Или вы и дальше будете все это объяснять с помощью некой теории заговора, согласно которой злые капиталисты из Cisco и Juniper давят свободное ПО и проталкивают свое жуткое глюкало на рынок с помощью "откатов"?

> И тут выясняется - без недокументированной команды service unsupported-transciever мы не принимаем чужие SFP, половина модулей не работает с sup32, работает только с sup720, если Вам вдруг потребуется поддержка OSPF на железке, платите ещё пару килобаксов за "продвинутый" IOS, и т.д. Таких неприятных моментов - море.

Да-да, абсолютно согласен. Гибкости не хватает, кругом сплошное зарабатывание денег. Это потому, что Cisco почти монополизировала некоторые сегменты рынка. Вот в SOHO-сегменте масса игроков и такого безобразия нет: куча всевозможных изделий на базе Linux, выбирай на вкус. Однако это не повод для того, чтобы обмазывать инженеров и программистов Cisco говном и говорить, что любой их продукт работает заведомо хуже обычного компа.

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

Сиська, это специализированное и дорогое решение. Специализированное решение только тогда имеет право на жизнь (не является говном), когда оно сильно, подчеркиваю, сильно лучше универсального.

> обмазывать инженеров и программистов Cisco говном
лично я этого и не говорил, самое большое - можно обмазать этим манагеров и марктологов
> любой их продукт работает заведомо хуже обычного компа
этого я тоже не говорил, но вот про младшие PIX - это в точку!
на обычном пицуке дешевле, лучше, проще, глюков меньше. проверено.

> на обычном пицуке дешевле, лучше, проще, глюков меньше. проверено.

+1
В очень большом количестве случаев. Сиська себя окупает в очень ограниченном круге задач. Чуть меньше/больше - всё, циска не в тему. В долгосрочной перспективе с вариантами расширения или апргрейда - циска очеь дорого обходится.

> 7206 -- устаревшая модель
а типа ibm x305 на piv-2.0 - суперсовременный что ли? да его уже 5 лет как не продают!
> ядро крупной сети для маршрутизации внутрисетевого трафика
это смотря что за сеть.
администрировать кучу однотипных пицуков представляет не большую проблему чем кучу однотипных Cisco, если конечно у Вас не венда на пицуках.;) Sun и Novell например предлагают такие решения десятилетиями. это просто пример.
поскольку я админил тогда сетку из солидной кучи рутерочков на линуксе, проблемы основнеы я знаю - большая часть была решена унификацией, при этом большая часть пицуков была списанное разнообразное гуано. Однако грамотный подоход (тут кто-то говорил что для Cisco это предоплагается, непонятно, почему при работе с линукс предполагается сразу только криворукие ламеры) - основными проблемами были только отказы самого железа (впрочем, при его бросовой стоимости->0 просто тупо менялось на другое с перетыканием флэша).
кстати, про каталисты - в соотвествующих местах стояли в итоге и каталисты, связка очень удачная кстати была linux router+catalyst.:)я >никогда не утверждал, что BGP где-то реализовано аппаратно. Это
> действительно технически невозможно.
а как же "Аппаратно реализуют только саму маршрутизацию" от 15.01.2009 13:47:35 и "Обычные компьютеры, на которых маршрутизация делается средствами CPU, никогда не будут эффективнее аппаратных решений" от 14.01.2009 14:43:25? Объяснитесь тогда, что под "маршрутизация" понимается?
Вот достаточно, типовое определение:
"Routing is the process of selecting paths in a network along which to send network traffic. Routing is performed for many kinds of networks, including the telephone network, electronic data networks (such as the Internet), and transportation (transport) networks."
Как я уже показал, за "process of selecting paths" даже в GSR отвечает ЦП.
теперь поповоду "аппартного BGP" - не вижу принципиальных проблем сделать это на вентилях кроме просто физических ограничений в настоящее время. В BGP никаокй чёрной магии нет и всё достаточно просто - дело лишь в точности следования протоколу - засунуть это в ASIC теоретически можно, нельзя лишь при сегодняшней технологии и по соотношению цена/воможности - дешевле рутер поставить обычный.:-)
> Quagga -- глюкало из той же серии
> лучше иметь платную реализацию BGP без утечек, чем бесплатную с
> утечками Если Quagga или какую-то еще реализацию таки доведут до ума
ну, положим, у Cisco тоже хватате CASE с BGP issues
про Juniper тут уже писалось
так что получается что лучше - платная реализацая BGP c утечками или бесплатная тоже с утечками?
кстати- на Quagga уже есть "аппаратные маршрутизаторы" - промышленное исполнение но open-source based.

да, кстати, как там в IOS с 32-битными ASN? Как не поддерживается на старом железе? это ж Ынтерпрайз?!

Ну что, кошководы слились?

> администрировать кучу однотипных пицуков представляет не большую проблему чем кучу однотипных Cisco

Задаю вопрос более конкретно: "Что проще админить: 10 PC или одно шасси с модулями?". Я хотел бы в реальной жизни увидеть хотя бы одну настолько нищебродскую локалку, где внутрисетевой трафик маршрутизируют десятки PC. И сетевика, который этот бред захочет администрировать. Все сколько-нибудь приличные конторы, набравшие тысяч 10 юзеров могут позволить себе по крайней мере несколько 3750, а то и 65xx с sup720. BGP обычно вешают либо на свичи, либо на что-то в духе Cisco 7600. Встречаются и граждане с бордером на FreeBSD с Quagga, но этому обычно никто не радуется. Мелкие провайдеры шейпят и натят по-разному (в зависимости от ширины канала и пакетрейта), в основном с помощью FreeBSD, если пакетрейты все еще небольшие. У крупных телекомов на сетевых задачах стоят если не Cisco, то Juniper, а писюки с FreeBSD или Linux используются для DNS и прочих сервисов.

Про PIX я вообще ничего не говорил. Они не нужны. Но только вот не надо мне нагло врать про то, что хороший L3-коммутатор проще и эффективнее заменить на кучу PC.

> "Routing is the process of selecting paths in a network along which to send network traffic. Routing is performed for many kinds of networks, including the telephone network, electronic data networks (such as the Internet), and transportation (transport) networks."

Слишком общее и размытое определение. Википедерастия как она есть. Вот хорошее определение, подходящее для IP-сетей. Маршрутизация -- это решение о том, через какой интерфейс передается пакет на основании IP-адреса назначения. Это вполне реализовано аппаратно. Протоколы маршрутизации (BGP, RIP, OSPF) занимаются формированием таблицы. Вы таки не понимаете, что процесс передачи пакетов на основании таблицы маршрутизации (собственно "маршрутизация") и процесс формирования самой таблицы -- это разные вещи?

> да, кстати, как там в IOS с 32-битными ASN?

В IOS-XR есть вроде как, сам не видел. Однако, это не большая проблема, т.к. нововведения обычно разрабатывают с учетом обратной совместимости.

> 32-bit ASN

BGP Support for 4-Byte ASN есть в IOS 12.0(32)S12

http://www.cisco.com/en/US/docs/ios/iproute/configuration/guide/irp_bgp_overv...

Опять кошководы буянят? :D

> BGP обычно вешают либо на свичи
мне уже сейчас смеяться или как?
я же говорил, что сравниваются сетки средних предприятий (уже доросли до bgp но выкладывать десятки килобачей не хочется- накладно)
про замену свичей на пц-рутеры в наше время можно не говорить - это невыгодно просто по денежным соображениям невыгодно-L3 начинаются от 6 тыров. но bgp-рутер на 65xx - это смех.:)
> Слишком общее и размытое определение
вообще-то оно хорошо с OSI коррелирует. вполне нормальное ФОРМАЛЬНОЕ определение. аналог bgp в телефонии кстати вполне себе рабтал даже ещё до эпохи ламп - чисто аппартный.;-)

>> да, кстати, как там в IOS с 32-битными ASN?
> В IOS-XR есть вроде как. Однако, это не большая проблема
дааа?! сделайте пожалуйста мне это на 28xx.;-)