redefine

Приветствую! Ваша задача понятна - отбиться от атак на канал связи, как Вы полагаете, Вы сможете и сами, но Вам нужна защита против L4-L7 DDoS. Вот пример решения похожей задачи - http://habrahabr.ru/company/timeweb/blog/175919/

CNick, Коротко: 1. Вряд ли проблема в ПО Peakflow. Может все же посмотреть на active/inactive таймауты, семплинг и на прочие элементы конфигурации Flow? Например, Peakflow не любит AS и ip prefix агрегацию на 7600. 2. Должен учитывать, так как значение строится по 3 точкам (сегодня, вчера, неделя назад). Детали нужно выяснять. 3. Это зависит не столько от описания MO, сколько от Вашей таблицы маршрутизациии, т.к. источник статистики - корреляция Flow и BGP. Например, если у Вас 2 МО (1.1.1/24 и 1.1/16) и один маршрут в BGP (1.1/16), то трафик будет считаться в оба МО. Если же у Вас такие же объекты и 2 маршрута (1.1.1/24, 1.1/16), то LPM сработает и трафик на 1.1.1.250 посчитается только в объект 1.1.1/24. Посмотрите мое ЛС и я смогу Вам ответить более подробно.

JoeDoe, расскажите подробнее, пожалуйста: Что такое dynamic IP mcast и mcast extensions for extranets? Как строятся p2mp lsp - rsvp-te или mLDP? DS-lite/6RD умеете? Можно детали по cflowd accounting для CGNAT? Я так понимаю, становится возможным по cflowd сообщать об адресах до и после трансляции? Это, надо понимать, Arbor TMS выполненный на базе ISA?

Разве в РТ используется не BGP-based VPLS? Есть мнение, что visir как раз хорошо знает, о чем говорит ;)

И Вы правы. Но приложения могут создавать туннельный интерфейс с помощью IPSEC, PPTP и т.д. :) Если между абонентом и Вами есть оператор XYZ, который фильтрует серые сети, то icmp unreachable fragmentation needed (type=3, code=4) с серого адреса не пройдет границу между Вами и оператором XYZ. Как-то так.

Tima, тут дело даже не в маленьком MTU на магистрали. Никогда не сталкивались с неработающим IPSEC из-за сломанного PMTUD? Это неприятно для корпоративных VPN-приложений, в которых нельзя выставить MTU вручную.

Давайте подискутируем. Аргумент против серых адресов для сети, по которой идет Интернет-трафик - неработающий Path MTU Discovery. Какие мнения на этот счет?

JNPR продолжает отжигать: Общее http://www.networkworld.com/news/2011/110711-internet-outage-252851.html?hpg1=bn Некоторые детали http://pastebin.com/HBWiH92j

1. Нет BAS интерфейса 2. Для связки IP pool и DHCP сервер скажите [Quidway] ip pool isp2_pool remote [Quidway-ip-pool-isp2_pool] gateway 30.30.30.1 255.255.255.0 [Quidway-ip-pool-isp2_pool] dhcp-server group group1 [Quidway-ip-pool-isp2_pool] quit 3. Совершенно справедливое замечание от Jazzy$ Вполне читабельный мануал: http://support.huawei.com/support/pages/kbcenter/view/product.do?actionFlag=searchManualTableOfContents&web_doc_id=SE0000455855&doc_type=ProductManual

Junos не ссылается на RFC1918 при блокировке 128.0/16. Скорее всего, это делается из-за RFC3330, который в 2010 году заменен на RFC5735. Попробуйте обновить софт.

Это где их по 900 дают??? Присоединюсь к вопросу. Это в Контур-М? (можно ответить в ЛС).

Расскажите подробности.

Значит они забыли обновиться :) http://www.retn.net/en/network/equipment/ аналогично 5300 в яндексе ;)

Про EX-ы говорят уже лучше, чем пару лет назад, но все еще не без проблем: http://community.livejournal.com/ru_juniper/8048.html HW 5300 под Ваши задачи работает стабильно. Cisco - тоже. Про Force10 неплохие отзывы в штатах, но у нас с отлаженными поставками этого дела пока значительно хуже, чем с Cisco/Juniper/Huawei/Extreme. А есть ли на свете такое оборудование, на котором 100% не будет "неожиданных нюансов, которые будет не решить"? Pahan, если сомневаетесь в железе, берите на тест где-нибудь на месяц. Основные проблемы за это время появятся.

недавно была тема: http://forum.nag.ru/forum/index.php?showtopic=55384

Ну так расскажите. Решение для уровня доступа-агрегации базовых станций. БС подключаются к коробкам по E1/FE. Uplink-и - РРЛ, STM-1, GE. Трафик БС прокидывается до RNC/MSC через MPLS сеть с помощью (ненавижу это слово) псевдопроводов (далее - PW). PW строится с помощью targeted LDP сессии. IGP метка раздается по RSVP-TE. Соответственно, на Data Plane это обычный MPLS. Что здесь от MPLS-TP (из того, что я помню)? 1. управление через NMS в формате "проложили туннель из точки А в точку Б". При подключении новой БС настраивать отдельно коробку не надо. 2. зачатки OAMа 3. возможность делать 1:1 PW redundancy для защиты сервиса С одной стороны, маловато. С другой стороны - это разработка 2007 года. А тогда кроме draft-ietf-mpls-tp-framework, draft-ietf-mpls-tp-oam-requirements и requirements for MPLS-TP ничего особо конкретного и не было. MPLS-TP (вроде бы он тогда еще заканчивал быть T-MPLSом) был больше идеей, нежели спецификациями на GACH и bidirectional LSP. Без обид, но согласитесь: здесь нет ничего проприетарного, QinQ тут не причем, и MPLS здесь в полный рост.

Согласен. Если это относилось к PTN, то говорит только о том, что Вы не в курсе того, как работает PTN.

Хуавей в этом вопросе не то что-бы не самый прыткий, а у него фактически до сих пор даже нету этого решения в виде готового к продаже продукта. Причины простые - он не лидер, он хороший копипастер. Не совсем. Коробки PTN, на котором построено пол-Мегафона, у Хуавея есть уже несколько лет. В PTNе очень много MPLS-TPшных идей.

Я может открою тайну, если скажу что одного "какого-либо стандарта" и не будет :) Вендоры уже запустили маркетинговую машину и теперь будет много P-S, I-D и драфтов, пока MPLS-TP не постигнет судьба l3vpn, где уже все что могли, сказали. Посмотрите кол-во RFC и драфтов на тему MPLS-TP в первоисточнике. Некоторые из них вполне даже "в окончательном варианте". И там не только Ху, но и Ци, и Аль :)

Цифры в студию! Можно даже на пресловутый сабж - т.е. CPT. P.S. я полагаю, ценник должен быть дешевле. Но не на порядок. Data plane тот же. Control plane - почти тот же. Коробка и проволока "у ней внутре" одинаковые :)

Вендоров определили, зачетку занесем позже:) А разве Ciena не работает в этом же направлении?

Статью читать очень тяжело. Отчасти из-за перевода. Отчасти из-за первоначальной маркетинговой ориентированности. Но вот что подумалось. Ранее одной из основных идей MPLS-TP (тогда еще T-MPLS) было упрощение управления для тех, кому тяжело с точки зрения эксплуатации переходить с SDH на MPLS. Им обещали, что вы не будете знать ничего про RSVP-TE, а просто будете рисовать туннели в NMS - как раньше это и делалось в SDH. Сейчас, как мне кажется, эту мысль уже никто в массы не несет. Как-то больше делается упор на OAM (G-ACH, CC, CV). Насколько я понимаю, стандартизация движется не быстро. Судя по http://datatracker.ietf.org/wg/mpls/ идей (и документов) много. Однако для того же OAMа много документов в состоянии draft. Juniper, кстати, тоже верит (или поддается общей волне) в MPLS-TP. Смотрите презентацию Компеллы с февральского MPLS congress 2010. Кстати, может кто в курсе, в T4000 есть что-то MPLS-TPшное? :)

Huawei LS-S5328C-EI-24S?

Да и конфигурится ужасно сложно. Все эти MA, MP и MEP, да еще на каждый сервис...

Принять одинаковый тег на разных физических портах нельзя. если накрыть его оутер влан то точно можно, оутер может быть как одинаковый так и разный, подозреваю, что без оутер тоже будет работать.Вопрос зачем роутед порты, если для vll/vpls то работает, если для терминации l3 то нет, ип адресация прописывается только на svi интерфейсах. Конструкция вида interface GigabitEthernet1/0/1.1 dot1q termination vid 10 ip address 10.10.10.1 255.255.255.0 interface GigabitEthernet1/0/2.1 dot1q termination vid 10 ip address 10.10.20.1 255.255.255.0 насколько я понимаю, работать не будет. Вроде бы, asco интересовал именно этот вопрос?