Vofffka

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

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

Не столько перспектива самого бордера, как перспектива купленного оборудования, вложение средств так сказать если сравнивать 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).

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

1) Juniper MX80 2) Cisco 7600 + RSP720-3CXL-10G

Наверное придется разбивать на группы по pvc. Сейчас на все 3 интерфейса заходит одинаковый набор pvc. Замечено что через MIC + SFP немного позже отвечает на PADI запросы чем через built-in порты. Про 11.2.4 интересно. Как там с лицензированием для уже существующих обладателей? Слышал что всякие плюшки а-ля CG-NAT отдельно лицензируется.

Поделитесь опытом распределения нагрузки для 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?

BGP 4-byte ASN, AToM L2 QoS, MVR

Шейпер какого типа? policer, ubrl, etc? Используем aggregate policers, после перехода на 15.1 - нормально работают.

Обновил до 15.1(3)S2 - полет нормальный. Весь функционал и конфиг роутер проглотил без проблем.

Есть 7600 платформа с RSP720-3CXL. Сейчас на ней крутится Version 12.2(33)SRE2 Появилась необходимость обновить до 15.1(3)S2 или 15.2(1)S. Возникут ли проблемы с лицензиями?

Как и где можно получить этот релиз? Письмо писал, ответа нет, как и доступа к разделу :)

Коллеги, какой на сегодня последний стабильный релиз софта для PPPoE BRAS + NAT конфигурации? Реализовали уже persistent NAT? P.S. Здесь рассказывали про закрытый раздел. Как туда попасть? Письмо писал, ответа нет.

Версия 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 - неверный

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 выключен