Перейти к содержимому
Калькуляторы

wonderer

Пользователи
 Просмотреть профиль  Активность

  • Публикации

    18

  • Зарегистрирован

  • Посещение

 Тип публикации 

Сообщения, опубликованные пользователем wonderer

  1. Опубликовано · Жалоба на ответ

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

  3. Опубликовано · Жалоба на ответ

    to mondragon

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

  4. Опубликовано · Жалоба на ответ

    Ок, не вопрос.

    сморозил глупость, бывает и пост свой удалил.

     

    По существу. не знал, что у АЛЮ монолитная ось,

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

     

    Охотно поверю, что эта коробка в каком-то виде сможет ISSU, ибо ось монолитная.

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

     

  5. Опубликовано · Жалоба на ответ

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

    Можете rus-p спросить, он вообще Alcatel-Lucent эксплуатирует уже несколько лет.

     

    Если бы у вас было бы реальное желание купить железо, вы бы провели конкурс, тесты, сравнили бы, кто и что реально может. Как это делали МТС. Мостелеком, Билайн, Эр-Телеком.

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

    Хочется вам рекламировать свое АЛЮ - да делайте вы это ради бога, только зачем при этом говорить что JNPR - это говно, а ALU вот один такой красивый. Только в отличии от JNPR почему-то ALU стесняется выложить документацию на сайте.

    Ладно, проехали.

     

  6. Опубликовано · Жалоба на ответ

    to Fduchun

     

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

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

  9. Опубликовано · Жалоба на ответ

    термины L2/L3 connected DHCP придумали на НАГе, имхо удачные названия.

    Смысл их прямой, работа с IPoE абонентом по DHCP, для случаев когда абонент имеет L2 сеть до браса или L3 сеть до браса.

     

    Циска умеет работать с L3 connected DHCP только если DHCP сервер поднят на Циске. Но это имхо не торт.

  10. Опубликовано · Жалоба на ответ

    тут многое зависит от вашего дизайна и вашей специфики.

     

    1. обычно сеть сегментируют логически и стремятся закреплять один ip белый для NAT на группу серых /22, /23, /24., по вкусу. Т.е. объем поиска сужается.

    2. бывает так, что фиксируют и даже сами серые IP, особенно если домовой провайдер вовлечен в пиринг с другими домовыми провайдерами.

    3. мы же говорим, про распространение, т.е. всякие сканы, вирусы - не в счет. Распространение - это достаточно длительный диалог с точки зрения переданного объема, который должен засечь даже сэмплированный netflow. Трудно если честно представить себе "распространение" если в диалоге было меньше 1000 пакетов.

  11. Опубликовано · Жалоба на ответ

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

  13. Опубликовано · Изменено пользователем wonderer · Жалоба на ответ

    элементарно....

     

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

  14. Опубликовано · Жалоба на ответ

    а че сразу лохи?

     

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

  15. Опубликовано · Жалоба на ответ

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

  16. Опубликовано · Жалоба на ответ

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

  17. Опубликовано · Жалоба на ответ

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

     

  18. Опубликовано · Жалоба на ответ

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