Итак, в апреле-мае стал доступен к заказу MX80 с ценой от $40000 GPL, причем даже минимальная по стоимости конфигурация (MX80-48T-AC)  была очень богатой – 48x1000BaseT + 4xXFP 10G. Однако не все оказалось гладко – как оказалось, для полноценной работы в качестве операторского маршрутизатора, нужно также заказывать лицензию S-MX80-ADV-R за $20000 GPL. Что самое интересное, официальную информацию, что же дает эта лицензия, приходилось выпытывать или вообще искать сообщения инженеров Juniper в разных списках рассылки. Так вот, эта лицензия (якобы) снимает искусственное ограничение на 20 тысяч префиксов в таблице маршрутизации. Как мы все (или почти все) знаем, текущая роутинговая таблица содержит более 300-350 тысяч префиксов, а если у нас два-три аплинка, то наш роутер должен поддерживать несколько миллионов записей. На будущее, так сказать.

Потенциальные заказчики задумались.  Во-первых, MX80 – аппарат  новый, есть вероятность определенной «сырости» решения. Во-вторых, возникло ощущение, что нас, эээ, обманывают, предлагая Мерседес с искусственно ограниченной до 15 км/ч скоростью.

Судя по всему, подобные мнения были не только у меня и у коллег по цеху. И вот, буквально на прошлой неделе Juniper объявляет в своем новом прайс-листе о новых т.е. бандлах (bundle) линейки MX80. Используя модную приставку Жэ, теперь доступны следующие модели, причем в комплекте сразу идет эта не только эта злосчастная лицензия, но и почти все остальные из доступных:

• MX80-5G-AC-B/ MX80-5G-DC-B – 20x1G SFP, все лицензии, но при этом порты 10G (4 шт XFP) и слот для дополнительного модуля заблокирован. Цена – $29500 GPL.
• MX80-10G-AC-B/ MX80-10G-DC-B – аналогично MX80-5G, но дополнительны модуль (MIC) можно поставить, при этом 4хXFP заблокированы. Цена – $50000 GPL.
• MX80-40G-AC-B/ MX80-40G-DC-B – портов 1GE нет вообще, есть два пустых слота MIC, два порта 10GE можно использовать, два других – заблокированы. Цена – аж $80000 GPL.

Наблюдательный читатель заметит, что последний бандл имеет явно несбалансированную цену, даже с учетом включенных лицензий (3 шт – L3 Advanced Routing, Queuing, Inline Jflow), часть из которых нужна не всем – ведь за $60k можно взять MX80 в полной конфигурации с одной необходимой лицензией. Но, к сожалению, в конце прошлой недели прошел слух, что теперь маршрутизаторы MX80 можно будет заказать только в виде перечисленных выше bundle. Еще раз подчеркну, что это неподтвержденная информация.

Также один из источников, заслуживающих доверия, сообщил, что Juniper сделает путь миграции 5G-10G-40G, но при этом цен пока еще нет. Кроме того, несколько вызывает удивление комплектация бандлов – роутер в первую очередь интересен поддержкой интерфейсов 10G, а эта возможность доступна только лишь в старшем (40G) бандле. Остается вопрос, что-же означают цифры перед G – они для «красоты» или бандлы будут иметь какие-то дополнительные ограничения, помимо заблокированных портов или слотов.

]]> http://deineka.net/2010/11/16/juniper-mx80-novye-bandly-i-sluxi/feed/ 6 http://deineka.net/2010/08/19/juniper-srx100-i-ego-dmesg/ http://deineka.net/2010/08/19/juniper-srx100-i-ego-dmesg/#comments Thu, 19 Aug 2010 17:57:04 +0000 axl http://deineka.net/?p=1133 Мне совершенно справедливо поставили на вид, что я не выложил обещанный dmesg на Juniper SRX100. Каюсь – забыл и готов исправится. Мы несколько подобных аппаратов поставили клиентам, вот аппаратная конфигурация одного из девайсов:

[shell]Copyright (c) 1996-2010, Juniper Networks, Inc.
All rights reserved.
Copyright (c) 1992-2006 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
JUNOS 10.0R3.8 #0: 2010-04-15 03:13:36 UTC

builder@ormonth.juniper.net:/volume/build/junos/10.0/release/10.0R3.8/obj-octeon/bsd/sys/compile/JSRXNLE
JUNOS 10.0R3.8 #0: 2010-04-15 03:13:36 UTC

builder@ormonth.juniper.net:/volume/build/junos/10.0/release/10.0R3.8/obj-octeon/bsd/sys/compile/JSRXNLE
real memory  = 1073741824 (1024MB)
avail memory = 535977984 (511MB)
cpuid: 0, btlb_cpumap:0xffffffff
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
Initializing watchdog interupt

Loading RT Fifo module…..
Loaded RT Fifo module
pmap_helper loaded (interface version 6, syscall 210)
cpu0 on motherboard
: CAVIUM’s Octeon CPU Rev. 0.1 with no FPU implemented
L1 Cache: I size 32kb(128 line), D size 8kb(128 line), sixty four way.
L2 Cache: Size 128kb, ? way
obio0 on motherboard
uart0: <Octeon-16550 channel 0> on obio0
uart0: console (9600,n,8,1)
twsi0 on obio0
dwc0: <Synopsis DWC OTG Controller Driver> on obio0
usb0: DWC OTG Controller
Using DMA mode
Init: Port Power? op_state=1
Init: Power Port (0)
usb0: <USB Bus for DWC OTG Controller> on dwc0
usb0: USB revision 2.0
uhub0: vendor 0×0000 DWC OTG root hub, class 9/0, rev 2.00/1.00, addr 1
uhub0: 1 port with 1 removable, self powered
uhub1: vendor 0×0409 product 0x005a, class 9/0, rev 2.00/1.00, addr 2
uhub1: single transaction translator
uhub1: 2 ports with 1 removable, self powered
umass0: STMicroelectronics ST72682  High Speed Mode, rev 2.00/2.10, addr 3
pcib0: <Cavium on-chip PCI bridge> on obio0
Disabling Octeon big bar support
PCI Status: PCI 32-bit: 0xc041b
pcib0: Initialized controller
pci0: <PCI bus> on pcib0
pci0: <serial bus, USB> at device 2.0 (no driver attached)
pci0: <serial bus, USB> at device 2.1 (no driver attached)
pci0: <serial bus, USB> at device 2.2 (no driver attached)
cpld0 on obio0
gblmem0 on obio0
octpkt0: <Octeon RGMII> on obio0
cfi0: <AMD/Fujitsu – 4MB> on obio0
platform_cookie_read not implemented
Timecounter “mips” frequency 500000000 Hz quality 0
Timecounters tick every 1.000 msec
Loading the NETPFE ethernet module
Loading E1/T1/J1 driver
Loading the DS1/E1 Media Layer; Attaching to media services layer
Loading common multilink module.
Loading the NETPFE PPPoE module
Loading the netpfe services driver
Loading the XDSL Media Layer; Attaching to media services layer
Loading the IPSec driver
Loading the PTM driver

Loading the DIALER driver
Loading Link Services PICs module.
IPsec: Initialized Security Association Processing.
SMP: AP CPU #1 Launched!
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <ST ST72682 2.10> Removable Direct Access SCSI-2 device
da0: 40.000MB/s transfers
da0: 1000MB (2048000 512 byte sectors: 64H 32S/T 1000C)
Trying to create bootdev, rootpartition da0s1a
Trying to mount root from ufs:/dev/da0s1a
[/shell]
Как видно выше, в качестве CPU используется Octeon от Cavium. Судя по всему, портирование FreeBSD (которая является основой для операционной системы Junos) джунипер делал не сам – есть фирма Paxym, которая специализируется на портировании Linux и FreeBSD на многоядерные mips-камни.

Несмотря на “детский” процессор, который используется в “несерьезных” NAS, приставках и домашних роутеах, SRX100 очень бодр благодаря аппаратному ускорению IPSec. Без подобного специализированного контроллера (маркировку пока не знаю – устройства гарантийные, радиаторы не сдирал) никуда, так как в Octeon нет FPU Прибавим сюда простую, понятную конфигурацию и гуманную цену – получим очень достойный security appliance для небольших филиалов-офисов, банкоматов, удаленной работы.

p.s. Еще одна особенность – что SRX100B (512M памяти), что SRX100H (1G памяти) в “железе” идентичны и памяти установлен 1Гбайт. Только вот в модели B доступно только половину (см. начало dmesg), а если нужно памяти побольше – нужно купить ключик и “открыть” фичу. Маркетинг, что сказать

Скомно добавлю, что у Александра еще есть справка о том, что он Extreme Networks Certified Design Professional (ECDP)

Общий вид (извините, ракурс не очень удачный). Воздуховоды, батарея вентиляторов, виден слот под дополнительный модуль аппаратного ускорения шифрования:

Операционная система JunOS выглятит не как нибудь, а вот так:

Маркировка материнской платы:

p.s. Вследствие сборки/разборки ни один роутер не пострадал. Живет и трудится в поте лица:

axl@не_скажу> show version
Hostname: не_скажу
Model: j4350
JUNOS Software Release [9.0-20100109.0]

axl@не_скажу> show chassis forwarding
FWDD status:
  State                                 Online
  Microkernel CPU utilization         1 percent
  Real-time threads CPU utilization  36 percent
  Heap utilization                   35 percent
  Buffer utilization                  2 percent
  Uptime:                               79 days, 23 hours, 24 minutes, 14 seconds

axl@не_скажу>

Вшили нужный junos прямо вот сюда:

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

Ну а затем все прозаично – железка стоит и работает 

Пойти, что-ли, написать пару “независимых” сравнений разного железа ?

p.s. Я не говорю, что Cisco – это плохо. Это не так – линейка Aironet совершенно очаровательна, в качестве PPPoE BRAS линейка 2800/3800 наиболее привлекательна (у Juniper для этого нужно ставить минимум M7i), а у Cisco Unified Communications Manager просто нет, по моему мнению, конкурентов. Но свитчи у Cisco несколько, эээ, overpriced.

1. В JunOS нет поддержки NBAR (Network Based Application Recognition). Т.е. если в Cisco для шейперов по приложениям можно было использовать NBAR, ограничивая (а точнее – пытаясь ограничить, т.к. есть ограничения, в т.ч. достаточно большое увеличение загрузки CPU), допустим, torrent/emule, то в случае использования Juniper прийдется это делать на отдельном специализированном устройстве (например, на том же самом Fortinet UTM devices – благо его можно поставить в режиме бриджа) либо городить трафик-шейпер по портам. Только нужно помнить – torrent-over-ssl все равно просто и быстро поймать – очень серьезная задача.
2. Time-based access-lists. Если в Cisco IOS можно было достаточно просто реализовать шейпинг с изменением полосы по времени (т.е. для тарифного плана вида “10 Мбит/с днем, 20Мбит/с ночью и выходные”), то в JunOS подобные вещи “в коробке” реализовать нельзя. С использованием разнообразных подпорок в виде стоящего рядом компьютера с cron’ом и скриптами для изменения конфигов роутера Juniper, конечно, это реализуется.

Имейте в виду при планировании сети и услуг.

Результаты разбирательств прогнозируемы. Причины проблем у заказчиков:

• перегрузка “роутера” на базе FreeBSD. Ресурсы кушает pf, не хватает буферов, прерывания  и т.п. Результат – потери, деградация качества канала.
• промежуточное железо. Ставит заказчик ноутбук на интерфейс – все пучком. Включает свою инфраструктуру – чудеса. Причина – на трассе стоит свитч вендора “икс”, который почему-то не свитчит с необходимой производительностью.
• false negative. Мерять канал пингом или mtr для получения объективных данных – неверно в корне. Тот-же iperf – тоже не особая панацея, мы ведь живем не в зоопарке, не в замкнутой экосистеме. Реальный Интернет – это нечто другое, нежели лаба с парой свитчей и роутеров.

Подробнее о последнем. Если хочется померять мегабиты – можно сходить на speedtest.net, конечно. Но этот сервис предназначен для ориентировочной проверки скорости для бродбенд-пользователей, скорости между компьютером клиента и сервером speedtest’а. Здесь возникает масса моментов – антивирус на компьютере пользователя, операционные системы и настройки ip-стэка на сервере и у клиента, загруженность тестового сервера (мы, кстати, свой kharkiv.speedtest.net перевели на nginx и получили 20-25% прироста в скорости! Только заменой вэб-сервера!). Далее помним о зависимости расстояния (читай – времени, т.к. есть свои естественные задержки в связи со скоростью света и привнесенные задержки на каналообразующем и маршрутизирующем оборудовании) и TCP Window Size. Подробнее см. отличный материал на Wikipedia. Как ни крути, 10Мбит/с получить единичным TCP-соединением с достаточно удаленного источника  (а именно поверх TCP ходят протоколы FTP и WWW – ведь именно скачкой/закачком обычно пытаются измерять) НЕВОЗМОЖНО в принципе.

То есть, если нужно померять более-менее реально, запускаем пару-тройку десятков закачек с разных серверов. Можно это сделать на FreeBSD с помощью fetch или curl:

# fetch -o /dev/null http://remote.server.tld/iso/big_DVD_image.iso

# curl -o /dev/null http://another.server.tld/iso/big_DVD_image.iso

Далее – о мнимых “потерях”. Запустим любимый в народе mtr на, допустим, yahoo.eu (извините, вырвалось ):

Видим “страшные потери” на каком-то хопе. Звоним своему провайдеру и начинаем его ругать. А причина проста – там (как и у нас, собственно) стоит Juniper с отличной конструкцией в конфигурационном файле, в разделе filter:

term icmp {
from {
protocol icmp;
icmp-type [ echo-request echo-reply unreachable time-exceeded ];
}
then {
policer small-bw-policer;
accept;
}

term trace-route {
from {
protocol udp;
destination-port 33434-33523;
}
then {
policer small-bw-policer;
accept;
}
}

…где small-bw-policer выглядит как:

policer small-bw-policer {
  if-exceeding {
    bandwidth-limit 128k;
    burst-size-limit 15k;
  }
  then discard;
}

Умеющим читать на английском вышеизложенные куски конфига понятны. Неумеющим читать – конфиг нам говорит, что если общее количество трафика icmp или udp (на диапазон портов), предназначенного маршрутизатору, будет больше 128К, трафик уничтожается, а mtr показывает “мнимые” потери.

А проверить по-настоящему просто:

# ping -s 1500 -q -c 100 yahoo.eu
PING yahoo.eu (68.180.206.184): 1500 data bytes
--- yahoo.eu ping statistics ---
100 packets transmitted, 100 packets received, 0% packet loss
round-trip min/avg/max/stddev = 217.482/220.701/224.686/2.490 ms

То есть для корректного результата мы делаем icmp-эхо-запросы на хост, который нам интересен и смотрим на результат. И тогда в ряде случаев не прийдется паниковать и звонить провайдеру с сообщением, что “все пропало”.

Вышеизложенным я не в коей мере не хочу сказать, что у нас все идеально, что во всем мире интернет работает, как часы. Даже с учетом достаточно высокой надежности, к которой мы стремимся, интернет сложен и зависим от каждого – причем не только от каждого оператора/провайдера, но и от конечного пользователя или подключенного в интернет устройства. На моей памяти за последние два месяца были две или три достаточно неприятные проблемы со связностью у наших аплинков, причем это были проблемы вне их зоны влияния. Из-за роста нагрузки мы переводим бэкбон на Extreme – каталисты близки к потолку по надежной производительности и иногда выдают чудеса, о которых как-нибудь в другой раз. Просто хотелось бы видеть грамотную диагностику проблем. И не забываем о модели OSI

Cisco Catalyst 3560G

Классика – это Cisco Catalyst 3560G. Несмотря на то, что более бойкие конкуренты наступают на пятки ценой, производительностью и функциональностью, эти свитчи наиболее известны на рынке, популярны в операторских и корпоративных сетях.  Несомненным плюсом является огромное количество инженеров, которые знакомы с этим оборудованием, достаточно вменяемая поддержка вендора (при наличии, правда, саппорт-контракта), в т.ч. в случае необходимости замены оборудования.

Exteme Networks Summit X350-24t

Возьмем в наше соревнование Extreme Networks Summit X350-24t. Несмотря на то, что этот свитч поддерживает L2/L4 (т.е. в нем нет поддержки L3 роутинга), на него стоит обратить внимание. Extreme делают коммутаторы высокого класса, которые работают надежно и прогнозируемо. Добавим сюда поддержку EAPS (Ethernet Automatic Protection Switching), возможность управления настройками коммутаторов с использованием XML и ряд фирменных протоколов для сверхбыстрого переключения (в десятки, если не сотни раз быстрее, нежели обычный stp) – получим коммутатор для производительной, управляемой и надежной сети, с очень неплохим соотношением цена/возможности.

Juniper EX3200

Еще один вендор, который набирает обороты на Украине – Juniper Networks. Эта компания широко известна своими маршрутизаторами, а теперь предлагает коммутаторы L3. Младшая модель, EX3200, присутствует в нашем обзоре. Особенности Juniper EX3200 – дисплей на передней панели (мелочь, а приятно), первые восемь портов поддерживают PoE 802.13af, операционная система – JunOS. Стоит обратить внимание на то, что фишкой Juniper является встроенная защита операционной системы от атак и ряд функций, направленных на  безопасное удаленное изменение конфигурации (желающие могут вспомнить о том, как весело менять критичные access-list’ы на Cisco, которая стоит в другом городе).

Edge-Core ES4626

Не забудем популярного и недорогого вендора  – Edge-Core. Без шуток – Edge-Core очень неплохое оборудование, которое используют многие операторы. Вопрос в том – можно ли его ставить на бэкбон нагруженной сети ? А как насчет его функций по маршрутизации – будет ли достаточно коммутатора Edge-Core ES4626 для того, чтобы, например, использовать его для подключения в KH-IX ?

В таблице нет коммутаторов  ZyXEL, D-Link, HP. Причина этому проста – мы не используем гигабитые решения этих производителей, соответственно – нет данных о надежности, возможностях, проблемах и прочем.

Итак, таблица с данными. Ряд данных – с сайтов производителей, дистрибуторов, документации. Ряд – с самих коммутаторов. И совсем немного (о совместимости SFP-модулей) – из опыта работы.

Теперь перейдем к выводам. Субъективным. Начнем с Edge-Core – это достойное и наиболее дешевое решение среди представленных. Но есть “ложка дегтя” – слабый процессор, мало памяти, микроскопическая роутинговая таблица (использовать для пиринга с KH-IX нельзя – не влезут префиксы). Вменяемая поддержка в Харькове с одной стороны, обидные ошибки в софте – с другой. Я бы рекомендовал ставить его на уровень доступа. Кстати, немаловажный момент – возможность установки XFP без приобретения дополнительных промежуточных модулей. Типичный (и не самый худший) представитель “второго эшелона” вендоров.

Cisco Catalyst – дорого, солидно, известная марка. Выверенная, достаточно надежная аппаратная часть. Но с другой стороны – малая производительность, слабый CPU, memory-leaks в софте  (а это значит – клинчи, рост потребления памяти со временем, паузы передачи данных при пересчете spanning-tree). Добавим сюда невозможность поднять соединение 10G – за эти деньги лучше поискать что-то другое. Тем не менее – стоит рекомендовать для тех, у кого широко используются Cisco-based технологии (кластеры коммутаторов, системы управления сетью и т.п.).

Extreme Summit – это классический L2/L4, сравнительно недорогой, но прогнозируемо работающий. Есть весь функционал для оператора – защита сети, защита операционной системы коммутатора, шейперы, мониторинг нагрузки в реальном режиме времени и многое другое. Совершенно очаровательный web2.0 интерфейс, сделанный на Flash. Если нужна большая ethernet-сеть, с кольцами, байпасами и высокой надежностью – ее лучше строить на Extreme. А если сесть и нарисовать (или найти/скачать) систему управления, которая будет на необходимых узлах описывать VLANы, шейперы и прочее, загружая на коммутаторы  XML – работа будет в радость.

Juniper EX3200 – это отличный компаньйон для тех, кто уже использует J-series, M-series и другие роутеры Juniper. Но не только – если нужна L3-маршрутизация, аналогов по цене и возможностям, фактически, нет. Операционная система JunOS написана для инженеров – работать приятно и безопасно, функционал очень широкий. Интерфейс для мониторинга/настройки через браузер не хуже (а может, и лучше), чем у Summit – тот же web2.0, очаровательные анимированные графики загрузки и прочее. EX3200 расчитан для применения провайдерами и широко применяется именно ими.

Небольшое заключение. Если нужен скоростной L2-бэкбон провайдеру или надежная корпоративная сеть – мы ставим и рекомендует Extreme. Нужен ip routing – рекомендуем Juniper EX-series, тут альтернатив нет. Если финансы стеснены – Edge-Core отличный выбор (только не нужно от него требовать слишком много). Cisco Catalyst – это годами проверенные аппараты, но их цена явно завышена, а брать б/у неверно – конденсаторы сохнут в любом устройстве, вне зависимости от вендора.

Буду благодарен за указание на неточности и ошибки.