поймал баг, что когда много дискавери - ему сносит крыш

и он на каждый делает по сессии

Уже R4 вышла

я знаю

пока не решаюсь))

думаю R5 подождать

14.2R1.9

R1, вы психи?)

а 14-ю ветку для браса зачем вообще юзать то?

там вроде как привели в порядок Subscriber Management, и его можно впродакшн

14-я ветка использовалась потому, что в ней работал MS-MIC-16G, а в 13-й ветке глючил

R1, вы психи?)

Нам ее интегратор рекомендовал, и потом апдейты делать после каждого нового релиза глупо

я сижу на 13.3R8

но очень страдаю

14-я для БРАС функционала гораздо лучше 13-й

13-я ветка - работает BRAS 14-я ветка - работает MS-MIC-16G 15-я ветка - работает BRAS и MS-MIC-16G

Нам ее интегратор рекомендовал, и потом апдейты делать после каждого нового релиза глупо

Интегратор налажал

14-я для БРАС функционала гораздо лучше 13-й

что значит лучше? мне ребята из джуна категорически не советовали 14-ю для SM

14.2 до r4 unstable

Интегратор налажал

Ну не знаю, у нас после этого больше года проблем нет

меня бесит в 13.3R8, что бай дефолт отдает по snmp динамик интерфейсы

а если исключать - виснет процесс

вот просто ужасно бесит

нет

misak@BRAS-Yerevan> show configuration snmp filter-interfaces { interfaces { demux.*; lsi.*; } }

у меня после этого все гуд

а у меня виснет)

ну и ae еще забыл

это в 13.3R8 такая беда

вот 14 не виснет

кстати 64 бита или нет?

а зачем ае исключать?

кстати 64 бита или нет?

там mx5

у меня на брасах много mx5

480 бордер

мы планировали поднимать на мх80, но пока эти два тянут

у меня было на 480 брас

еще по старой архитектуре они пару сотен тысяч могли тянуть

ол ин ван исп бокс

адочек был

у нас 480 и хорошие РЕ

там руки кривые у программистов Juniper

Я на 9200 (аналог 480) тестил 15.1

Шустрее железо работало кстати

MX5 - бомба по аппаратной начинке

Но не для продуктива пока

надо r5 как минимум

даа, я даже виртуальное шасси поднимал где был БРАС, МПЛС и все остальное

в один прекрасный день все заглючило, и пришлось разбирать все это

в один прекрасный день все заглючило, и пришлось разбирать все это

аналогично

сделали mc-lag

у нас 480 и хорошие РЕ

у меня такие же, если что)

проблема в том, что mpc2 текла

смотрим cpu0: Freescale e500v2 core revision 3.0 cpu0: HID0 8000 Во первых, программисты JUniper даже не подозревают, что этот процессор имеет два ядра Во вторых, программисты JUniper ничего не знают о Signal Processing Engine, которое присутствует в этом процессоре, а тупо эмулируют сопроцессор софтварно

смотрим cpu0: Freescale e500v2 core revision 3.0 cpu0: HID0 8000 Во первых, программисты JUniper даже не подозревают, что этот процессор имеет два ядра Во вторых, программисты JUniper ничего не знают о Signal Processing Engine, которое присутствует в этом процессоре, а тупо эмулируют сопроцессор софтварно

Программисты Juniper больше тебя знают

Вопрос почему они не реализовали

руки кривые ?

у нас только mpc2, и большинство проблем с ними как раз в 14 версии поправили

Просто глупо утверждать что вендор хуже пользователей знает свой продукт

Возможно руки, у них часто бывают косяки, но знать они обязаны

им много чего учитывать надо, в том числе и переносимость кода

Junos построена на FreeBSD, а в ней то я уж разбираюсь

Знать и делать - разные вещи. Перелопатить мегабайты кода для работы с новой фичей процессора - непростое развлечение

ну Фряха там просто как окружение

А использовать программную эмуляцию FPU - это нормально ?

А ничего, что фряха там управляет всем железом ?

а что там вообще считать на FPU? Может оно вообще не нужно

Насколько я помню програмную эмуляцию FPU - оно отрабатывает по прерыванию на неизвестную команду. И соответственно при наличии железного FPU все прозрачно работает на железе

Security policy loaded: JUNOS MAC/pcap (mac_pcap) Security policy loaded: JUNOS MAC/runasnonroot (mac_runasnonroot) Security policy loaded: Junos MAC/veriexec (mac_veriexec) MAC/veriexec fingerprint module loaded: SHA256 MAC/veriexec fingerprint module loaded: SHA1

тоесть управляет железом? PCI шину инициализирует? Там все железо нужное chassisd управляется по моему

а chassiыd наверное в вакууме работает ?

а что там вообще считать на FPU? Может оно вообще не нужно

http://netch80.livejournal.com/39929.html

не в вакууме, во фряхе, но от фряхи там всего ничего, под ту же винду надо будет быстро перепишут, не говоря о линуксах

не в вакууме, во фряхе, но от фряхи там всего ничего, под ту же винду надо будет быстро перепишут, не говоря о линуксах

Благородный дон пробовал переписывать низкоуровневые вещи с фряхи на венду?

фряха там на своем месте, но вот то, что на PowerPC платформе до сих пор у них стоит 6.1 - это ни в какие ворота не лезет

нет конечно. мысл свою я намеренно так написал, чтобы просто сказать, что фряха конечно хорошо, но ее выбор был наверное по предпочтениям туогдашнего системщика в Джуне

вон циска так же под линукс пишет

для x86 платформы они наконец-то обновили фряху до 10-STABLE. И сразу начали клепать vMX, vSRX, потому как в десятке появилась поддержка виртуализации

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

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

Люблю послушать пятничных искпертов

Циска и под фряху пишет. тот же Iron Port

Люблю послушать пятничных искпертов

Я вообще не эксперт. Просто болтаю, ни на что не претендую.

А IronPort ихняя или они купили?

Купили однозначно. Помню еще в 2008 году это было нециско оборудование, а уже где-то через год вдруг стало cisco

даже название менять не стали

Купили однозначно. Помню еще в 2008 году это было нециско оборудование, а уже где-то через год вдруг стало cisco

А гугль говорит, что циской оно стало в 2007м

может быть... точно не помню... но переход застал на своей старой работе... как раз купили iron port еще не у циски

железом там рулят процессы junos

по второму эзеру на re

так что фря - тупо запускалка процессов

ага

что я и говорил

ну и i2c вроде был

да, есть там i2c

который опять же junos'ом рулит

i2c0: <MPC85XX OnChip i2c Controller> iomem 0xf7f03000-0xf7f03014 irq 59 on ocpb us0 ds1672 rtc0: <DS1672 RTC> on i2c0 i2c1: <MPC85XX OnChip i2c Controller> iomem 0xf7f03100-0xf7f03114 irq 59 on ocpb us0 tsec0: <eTSEC ethernet controller> iomem 0xf7f24000-0xf7f24fff irq 45,46,50 on o cpbus0

http://www.opennet.ru/opennews/art.shtml?num=44748

переписать на линукс вполне можно, но с точки зрения бизнеса - затраты вполне понятны, профит - не очень

хотя для виртуальных srx может и будет