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

Vofffka

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

  • Публикации

    16

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

  • Посещение

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

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

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

    Ну да, защита инвестиций если только. И то - сомнительно, ибо когда 6500 перестанет справляться с ролью бордера по числу маршрутов (так же как и 7600) - его смело можно ставить молотить трафик в ядро, это он умеет делать превосходно.

     

    В 3BXL и 3CXL - размер TCAM 1млн. За все время существования интернета глобальные таблицы порядка 390-400 тыс. Не важно со скольки аплинков приходят FV - в FIB а соотвественно и в TCAM будет одна запись на один префикс. Думаю что пока рано говорить о нехватки 1млн TCAM. (Вариант с выносом FV в vrf отличный от global не рассматриваем, ибо нелогично)

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

    взять mlx и никаких плат докупать не надо, если только портов не хватает, все работает из коробки.

     

    К сожалению не приходилось сталкиватся с Brocade. Каков уровень поддержки и сервиса со стороны вендора и пратнеров?

    Мне бы не хотелось ради 10-30% экономии остатся один-на-один с коробкой :) Предпочитам отлаженную платформу, где многие собак уже съели,

    глюки всякие конечно тоже встречаются, но оперативная поддержка со стороны вендора всегда радует.

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

    а какая перспектива роста у бордера? число маршрутов одинаковое у 6500 и 7600, 1М. У Джунипера, скорее всего, 5М (пускай поправят знатоки). Число 10Г портов тоже одинаковое и зависит только от шасси.

     

    Не столько перспектива самого бордера, как перспектива купленного оборудования, вложение средств так сказать если сравнивать 65 и 76. Представим что вы завтра/через месяц/год подросли и появилось необходимость задействовать MPLS/L3VPNs/L2VPNs/VPLS и еще всякие сервисы. Докупили в 76-ю ES плату и вуаля, MPLS роутер готов. В случае 65-й только полная замена платформы. 65-я позиционируется как платформа для коммутации в enterprise с FWSM и VSS, 76-я для коммутации/маршрутизации причем мультисервисной. Либой транспорт: ethernet, stm, sdh, isdn :)

    У нас был случай когда клиент платил немалые деньги чтобы прогнать ISDN PRI из точки А в точку Б. TDMoverMPLS выручил. И это все на 76-й платформе.

     

    MX80 - сильный бордер и даже как MPLS роутер (но только транзитный P, не PE).

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

    а в чём отличе 6500 от 7600 в таком случае?

     

    Отличие в перспективе роста. В 76-ю платформу в дальнейшем можно установить ES либо SIP платы , получите гораздо больший функционал.

    65-я дальше L3 коммутатора не уйдет.

    А по цене 65 и 76 практически одинаковые (при стартовом бандл шасси + суп/рсп)

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

    Посоветуйте бордер с оптимальным соотношением цена/качество

    из требований

    - 3 FW

    - 1-2 10G

    - какоето разумное кол-во 1q вланов

     

    схема будет простая

    1-3 аплинка приходят в разных вланах и уходят на роутеры в ядре.

     

    Спасибо за помощь.

     

    1) Juniper MX80

    2) Cisco 7600 + RSP720-3CXL-10G

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

    1) Перекосы выравнивать путем перекидывания pvc с одного порта на другой пробовали?

    2)В начале марта выйдет софт 11.2.4 который можно ставить в продакшин и котором будет уметь NAT поверх LAG

     

    Наверное придется разбивать на группы по pvc. Сейчас на все 3 интерфейса заходит одинаковый набор pvc. Замечено что через MIC + SFP немного позже отвечает на PADI запросы чем через built-in порты.

    Про 11.2.4 интересно. Как там с лицензированием для уже существующих обладателей? Слышал что всякие плюшки а-ля CG-NAT отдельно лицензируется.

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

    Поделитесь опытом распределения нагрузки для PPPoE на SE100.

    Сейчас на первые 3 порта заведен абонентский L2 (набор dot1q вланов). Оставшиеся 3 порта собраны в LAG поверх которого L3 в ядро.

    На LAG трафик распределяется примерно поровну между портами, а вот на абонентских ощутимы перекосы.

    Абонентские порты в LAG не собирали из-за ограничения с НАТом.

     

    P.S. Кто-нибудь проводил эксперимент с L2VPN/VPLS? Например пригнать весь абонентский L2 с помощью equal cost multipath (ECMP) on label-switched path (LSP) и прибиндить pppoe на этот L2VPN?

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

    Если имеется в виду CG-NAT, то он готов в 11.1 релизе.

    Как и где можно получить этот релиз?

     

    Необходимо написать письмо на smartedge@nag.ru

    На все письма поступающие туда от пользователей SE дается доступ без ограничений.

    Письмо писал, ответа нет, как и доступа к разделу :)

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

    Коллеги, какой на сегодня последний стабильный релиз софта для PPPoE BRAS + NAT конфигурации?

    Реализовали уже persistent NAT?

     

    P.S. Здесь рассказывали про закрытый раздел. Как туда попасть? Письмо писал, ответа нет.

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

    Версия 1.3.5 падает с ошибками:

     

    [ 3754.022480] accel-pppd[6990]: segfault at 20 ip 00007fa7c8d5d750 sp 00007fff787a9110 error 4 in libtriton.so[7fa7c8d59000+8000]

    [ 4022.973460] accel-pppd[19738]: segfault at 70 ip 00007f00a50e4750 sp 00007fff59c9c2a0 error 4 in libtriton.so[7f00a50e0000+8000]

    [13970.239684] accel-pppd[7597]: segfault at c8 ip 00007f030b6bedfc sp 00007f0304a4a470 error 4 in libc-2.11.2.so[7f030b64d000+158000]

     

    Последний билд из git тоже падает:

     

    [15121.198780] accel-pppd[9940] general protection ip:7f872b576750 sp:7fffe1774eb0 error:0 in libtriton.so[7f872b572000+8000]

    [16738.736240] accel-pppd[29830]: segfault at 50 ip 0000000000406484 sp 00007f17d3126d60 error 4 in accel-pppd[400000+17000]

     

    error 4 это чтение по адресу 0?

     

    ситема Debian 6.0.1. ядро 2.6.32-5-amd64

     

    сделал objdump -d accel-pppd. вот кусок кода там где падает:

    0000000000406410 <lcp_layer_free>:

    406410: 55 push %rbp

    406411: 31 c0 xor %eax,%eax

    406413: 53 push %rbx

    406414: 48 89 fb mov %rdi,%rbx

    406417: 48 8d 3d f8 c1 00 00 lea 0xc1f8(%rip),%rdi # 412616 <_IO_stdin_used+0x54e>

    40641e: 48 83 ec 08 sub $0x8,%rsp

    406422: e8 e9 a5 00 00 callq 410a10 <log_ppp_debug>

    406427: 48 83 bb 18 01 00 00 cmpq $0x0,0x118(%rbx)

    40642e: 00

    40642f: 74 0c je 40643d <lcp_layer_free+0x2d>

    406431: 48 8d bb 18 01 00 00 lea 0x118(%rbx),%rdi

    406438: e8 ab ce ff ff callq 4032e8 <triton_timer_del@plt>

    40643d: 48 8b bb 00 01 00 00 mov 0x100(%rbx),%rdi

    406444: 48 8d 73 28 lea 0x28(%rbx),%rsi

    406448: 48 8d ab 08 01 00 00 lea 0x108(%rbx),%rbp

    40644f: e8 6c d5 ff ff callq 4039c0 <ppp_unregister_handler>

    406454: 48 8b b3 08 01 00 00 mov 0x108(%rbx),%rsi

    40645b: 48 39 f5 cmp %rsi,%rbp

    40645e: 74 33 je 406493 <lcp_layer_free+0x83>

    406460: 48 8b 46 08 mov 0x8(%rsi),%rax

    406464: 48 8b 16 mov (%rsi),%rdx

    406467: 48 89 df mov %rbx,%rdi

    40646a: 48 89 42 08 mov %rax,0x8(%rdx)

    40646e: 48 89 10 mov %rdx,(%rax)

    406471: 48 8b 46 20 mov 0x20(%rsi),%rax

    406475: 48 c7 06 00 00 00 00 movq $0x0,(%rsi)

    40647c: 48 c7 46 08 00 00 00 movq $0x0,0x8(%rsi)

    406483: 00

    406484: ff 50 50 callq *0x50(%rax)

    406487: 48 8b b3 08 01 00 00 mov 0x108(%rbx),%rsi

    40648e: 48 39 ee cmp %rbp,%rsi

    406491: 75 cd jne 406460 <lcp_layer_free+0x50>

    406493: 48 8d 7b 50 lea 0x50(%rbx),%rdi

    406497: e8 c4 ea ff ff callq 404f60 <ppp_fsm_free>

    40649c: 48 8b 83 00 01 00 00 mov 0x100(%rbx),%rax

    4064a3: 48 8d 35 f6 fb ff ff lea -0x40a(%rip),%rsi # 4060a0 <_lcp_layer_finished>

     

    libtriton.so падает в функции triton_terminate по смещению 0x4750:

     

    471b: f0 41 83 46 18 01 lock addl $0x1,0x18(%r14)

    4721: e9 3a ff ff ff jmpq 4660 <triton_terminate+0x40>

    4726: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)

    472d: 00 00 00

    4730: 48 8d 3d 89 2f 20 00 lea 0x202f89(%rip),%rdi # 2076c0 <ctx_list_lock>

    4737: 48 8d 2d 12 2e 20 00 lea 0x202e12(%rip),%rbp # 207550 <threads>

    473e: e8 f5 df ff ff callq 2738 <pthread_mutex_unlock@plt>

    4743: 48 8b 1d 06 2e 20 00 mov 0x202e06(%rip),%rbx # 207550 <threads>

    474a: 48 39 eb cmp %rbp,%rbx

    474d: 74 14 je 4763 <triton_terminate+0x143>

    474f: 90 nop

    4750: 48 8b 7b 20 mov 0x20(%rbx),%rdi

    4754: 31 f6 xor %esi,%esi

    4756: e8 3d e0 ff ff callq 2798 <pthread_join@plt>

    475b: 48 8b 1b mov (%rbx),%rbx

    475e: 48 39 eb cmp %rbp,%rbx

    4761: 75 ed jne 4750 <triton_terminate+0x130>

    4763: 31 c0 xor %eax,%eax

    4765: e8 26 e4 ff ff callq 2b90 <md_terminate>

     

    если смотреть в коде:

    void __export triton_terminate()

    {

    struct _triton_context_t *ctx;

    struct _triton_thread_t *t;

    int r;

     

    need_terminate = 1;

     

    spin_lock(&ctx_list_lock);

    list_for_each_entry(ctx, &ctx_list, entry) {

    spin_lock(&ctx->lock);

    ctx->need_close = 1;

    r = triton_queue_ctx(ctx);

    if ®

    triton_thread_wakeup(ctx->thread);

    spin_unlock(&ctx->lock);

    }

    spin_unlock(&ctx_list_lock);

     

    list_for_each_entry(t, &threads, entry)

    pthread_join(t->thread, NULL);

     

    md_terminate();

    timer_terminate();

    }

     

    то падает t->thread перед вызовом pthread_join. похоже указатель t - неверный

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

    igb - 2.2.9 тоже вводит ядро в панику.

    ОС: Debian 5

    ядро: 2.6.32-bpo.3-amd64 и 2.6.32-bpo.5-amd64

     

    Причем впадает в kernel panic когда на VLAN интерфейс назначаю IP адрес и через него начинает идти обычный IP трафик.

    Когда на VLAN интерфейсах нет адресов и ходит PPPoE - работает нормально

     

    Irqbalance выключен

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

    Добрый день, господа!

     

    Имеется брас с 2-х портовой сетевой картой Broadcom Corporation NetXtreme II BCM5716 Gigabit Ethernet .

    Один порт смотрит в сеть для терминации PPPoE другой в мир (IP трафик)

     

    Сейчас молотит порядка 900 мбит дуплесного трафика.

     

    Драйвер bnx2 version: 2.0.2

    По 8 очередей на каждый порт. естественно на порту с PPPoE задействована только одна очередь. Вероятно хеш функция работает только по заголовкам 3,4-го уровней.

    Эту одну очередь припил к конкретному ядру CPU. Остальные очереди распределяются между оставшимися.

     

    Суммарная загрузка CPU не более 50% по всем ядрам.

     

    Стоит задача увеличить количество трафика через него.

    В наличии есть 2-х портовая сетевая Intel 82576EB. Насколько мне известно, то интеловский RSS также работает только по залаговкам 3,4-уровней.

     

    Как считаете, что лучше поставить в сеть с PPPoE, а что в IP мир? Intel или Broadcom?

     

    З.Ы: Какая версия igb для linux более стабильная? igb версии 2.4.х и 2.3.х приводили к kernel panic совместно с irqbalance.