wonderer

ну емае... вы для порядку сказали бы сразу, что это не в 7750 шасси, думаю rus-p и другие коллеги имеющие 7750 на сети будут счастливы тому факту, что для fp3 придется заменить все, включая шасси

есть и такая точка зрения :)

to mondragon ничего удивительного в том, с чем вы столкнулись нет, засинкать стейты между двумя разными айсиками - это сложная задача. А вот делать customer facing интерфейсы в виде ether channel - это реально изврат. сорри )

Ок, не вопрос. сморозил глупость, бывает и пост свой удалил. По существу. не знал, что у АЛЮ монолитная ось, но черт побери когда с пеной у рта (это про жестко) начинают доказывать что это ноу-хау - то, увы... верю с трудом. Охотно поверю, что эта коробка в каком-то виде сможет ISSU, ибо ось монолитная. Но за это приходится платить тем, что если где-то что-то навернулось на уровне протокола или какой-либо функциональности - то упадет и все остальное.

Да я вам про совсем другое говорю. Все эти отчеты - это вообще ни о чем. Вы про Miercom отчеты о циско слышали как-нибудь? После тех историй вера к подобным отчетам полностью подорвана. Как говорится "кто девушку ужинает тот ее и танцует". Во многих перечисленных вами операторах таким же образом покупались и циски и джуниперы и даже хуавеи и что? Хочется вам рекламировать свое АЛЮ - да делайте вы это ради бога, только зачем при этом говорить что JNPR - это говно, а ALU вот один такой красивый. Только в отличии от JNPR почему-то ALU стесняется выложить документацию на сайте. Ладно, проехали.

to Fduchun ваши ссылокчки на маркетинговые "документы" не выдерживают никакого сравнения с технической документацией того же JNPR, где черным по белому прописаны все ограничения и ссылку на которую вы сами же дали. Плавали, знаем. Нчего в этом мире не бывает идеального, а откровенный маркетинговый булшит только вызывает дополнительные подозрения и недоверие. Судя по цитатам из документации, которые вы здесь привели, в АЛЮ нет четкого понимания как минимум того, что есть NSR, а есть NSF (non-stop forwarding), ибо назвать ARPы, PPP, LACP и проч вещи являющимися функциями сугубо forwarding plane термином NSR по меньшей мере не уместно. Вобщем вывод - мутняк и все тут.

Пруфлинк в студию. Или вам типа на слово верить?

вот: ISG DHCP Restrictions ISG cannot relay DHCP requests when a Layer 3 DHCP relay agent is between the ISG device and subscriber devices. http://www.cisco.com/en/US/docs/ios/ios_xe....html#wp1075732

термины L2/L3 connected DHCP придумали на НАГе, имхо удачные названия. Смысл их прямой, работа с IPoE абонентом по DHCP, для случаев когда абонент имеет L2 сеть до браса или L3 сеть до браса. Циска умеет работать с L3 connected DHCP только если DHCP сервер поднят на Циске. Но это имхо не торт.

тут многое зависит от вашего дизайна и вашей специфики. 1. обычно сеть сегментируют логически и стремятся закреплять один ip белый для NAT на группу серых /22, /23, /24., по вкусу. Т.е. объем поиска сужается. 2. бывает так, что фиксируют и даже сами серые IP, особенно если домовой провайдер вовлечен в пиринг с другими домовыми провайдерами. 3. мы же говорим, про распространение, т.е. всякие сканы, вирусы - не в счет. Распространение - это достаточно длительный диалог с точки зрения переданного объема, который должен засечь даже сэмплированный netflow. Трудно если честно представить себе "распространение" если в диалоге было меньше 1000 пакетов.

Ну как бы немцы должны знать куда или точнее кому этот хомячок распространял, т.е. DST они знают и время знают. Осталось найти только одну неизвестную, и если вы сняли у себя netflow до трансляции, то это легко сделать

т.е.? кэширование - это и есть netflow. Что еще кроме netflow поможет ответить на подобные запросы.

элементарно.... когда вы пакет еще не снатили у вас в пакете source серый а destination тот что хомячок запросил, вот этот пакет и нужно кэшировать.

а че сразу лохи? сначала нужно задать вопрос, кто из железных вендоров может сделать кэширование серого IP и только потом сделать NAT (брасики на линухах не в счет). Там в Германии поди NAT вообще не юзают.

fozz :) ... вы решили проблему для трафика, который идет к абоненту, т.к. его раскрасил ваш бордер. Это-то и ежу понятно, что работает и для этого не нужен никакой QPPB. Вопрос в том, как интеллектуально рейт-лимитить трафик, который приходит от абонента? Подозреваю, что QPPB не запашет в ISG, если классифицировать по дейстинейшену и тутже рейт-лимитить.

VitMain, итригующе... :) Т.е. команда bgp-policy destination может быть включена для virtual-template интерфейса? У вас реально работает? Я спрашиваю потому, что нигде не встречал такого конфига в гугле... везде bgp-policy включается на обычных L3 интерфейсах...

VitMain, я не понимаю как эта фича поможет сделать rate-limit на входящем в брас от абонента трафике? с трафиком в сторону абонента - все понятно.

вопрос в связи с этим. QPPB работает per subscriber на ISG напрмиер, если BGP на брасе поднят? или суть советов сводится делать это на каком-то раутере до ISG?