Изьявил желание поехать на Сisco Live 2013 - с 28/01 по 01/02 в Лондоне (раз уж не поехал на European Peering Forum на прошлой неделе на Мальту).

Список тем : https://www.ciscolivelondon.com/scheduler/catalog.do

Любители фиш & чипс присоединяйтесь!

Хотя я до него доехал, нашел и оплатил парковку, зарегистрировался, успел выпить кофе и только начался первый семинар, как меня выдернули на работу по причине кризиса по проблеме стресс-теста LTE. Хотя еще со вчерашнего дня было ясно, что проблемы не на бекбоне, а где-то в агрегационной сети. Если вообще не с тестовым оборудованием. Так что тупо сижу, усиливая инженерную группу разве что своим присутствием.
То есть весь день проёбан зазря (не считая даже впустую оплаченной парковки). Не говоря уже о том, что ничего ну удалось услышать из желаемого - ни о Voice over LTE, ни о MPLS на линиях доступа, ни о Fabric Path / TRILL.

Бля!

ЗЫ. Да еще вставать пришлось в 7 утра, чтобы в пробках постоять...

По моим наблюдениям, Cisco сдает позиции в среде поставщиков сетевого оборудования для бекбонов. Их эпический фейл c багом в ASIC Janus на 10-гигабитных картах X6704, торможение во внедрении ряда давно необходимых фичей, посредственная производительность. Это не затрагивая финансовую сторону, в плане которой Cisco далеко не самый дешёвый поставщик. Смещение всё более и более идет в сторону Juniper (для Core) и Alcatel (роутеры PE). Cisco остается на переферии, как оборудование для сервисных платформ, GGSN, MME, S/P GW, но не на бекбоне. Прочее телекомовское оборудование, с переменным успехом, делят Ericsson, Alcatel и Huawei.

Все время Cisco казалась эталоном сетевого окружения. Оказывается и из Cisco можно вырасти.

Байка про аварию: http://dbg.livejournal.com/45329.html
Про FRR мультикаста (наивное): http://dbg.livejournal.com/48684.html
Про FRR мультикаста (эксперимент): http://dbg.livejournal.com/61417.html
Про TE и link state IGP: http://dbg.livejournal.com/50208.html
Про PBT: http://dbg.livejournal.com/2007/01/08/
Про LDP FRR от китайского вендора: http://dbg.livejournal.com/54339.html
Random ramblings про семантику MPLS-метки: http://dbg.livejournal.com/59929.html
Про path MTU: http://dbg.livejournal.com/58171.html
Про мониторинг MPLS forwarding plane http://dbg.livejournal.com/63344.html
Смотрим на кровавую гебню через tcpdump: http://dbg.livejournal.com/64577.ht....com/63762.html
Про MPLS и суммаризацию: http://dbg.livejournal.com/70327.html
Продолжение про MPLS и суммаризацию: http://dbg.livejournal.com/78073.html
Про OSI/ISO схоластику: http://dbg.livejournal.com/70601.html
Про DLink http://dbg.livejournal.com/71978.html
Про чтение из TCP-сокета http://dbg.livejournal.com/76148.html

До конца недели сижу на формасьёне по CDN (Content Delivery Network) - повышаю свою квалификацию. Сегодняшний день посвящен кодированию видео потоков в MPEG-2 и H.264. От математики голова пухнет, но опыт не пропьешь - всякие преобразования Фурье, разложения частот в спектр и алгоритмы кодирования/компрессии неожиданно всплывают в памяти, хотя в ВУЗе я был принципиальным опездалом и должного внимания наукам не уделял. Да и лет 15 прошло...
Но тем не менее интересно послушать точку зрения эксперта Cisco по видеопротоколам.

• Ethernet segments should not feature a sustained utilization of 40% or higher
• All Ethernet segments should be switched – no shared segments (hub-based)
• No WAN links should feature a sustained utilization of 70% or higher
• Response times should be generally less than 100 ms
• LAN response times should generally be 2 ms
• No segments have more than one cyclic redundancy check (CRC) error per million bytes of data.
• No segments should have more than one CRC (cyclic redundancy check) error per million bytes of data
• No segments should have more than 20 percent multicast or broadcast traffic
• For Ethernet segments, there should be less than .1 percent collisions
• Over 5 minute intervals, CPU utilization should not exceed 75%
• The number of output queue drops should not exceed 100 in an hour
• The number of input queue drops should not exceed 50 in an hour
• The number of buffer misses should not exceed 25 in an hour
• The number of ignored packets should not exceed 10 in an hour

>> link

Для интересующихся очень скорым приходом IPv6 - прошедшая 10-11 июня конференция Google по внедрению IPv6. Слайды по всем выступлениям, к некоторым - видео.

Вышел релиз Mainline (15.0M), начат 15.1T. Release Notes for Cisco IOS Release 15.1T
15.0 считается переходной с 12.x на 15.x, так что 15.1 - это пошло уже полноценное развитие 15.

Касательно жизненного цикла версий (из комментов на ioshints):

Phillip Remaker:

15.0M is a transition between 12 and 15. "M" indicates a long-lived mainline release. It is the first mainline release, long lived and bugfix only.

15.1T starts the ".1 epoch" of releases.

15.1(1)T, (2)T, (3)T will be shorter lived feature releases that each add new features. At some point, the .1 epoch will be feature complete and will graduate to the "M" marker at 15.1(x)M. That M release will be long lived. The value of x is not currently known.

When (or slightly before) 15.1 becomes a mainline, 15.2(1)T will be the first release of the ".2 epoch" of releases. 15.2(1)T, 15.2(2)T will each be shorter-lived feature-add releases that add features. 15.2T will graduate to "M" status once feature complete after some number of releases.

Repeat for each epoch, 15.3, 15.4, etc, etc. The "T" changed to "M" when the train is feature complete.

Logically, M and T are the same software base in this model - the M just serves as a lifecycle marker, like the Ubuntu LTS marker.

The "S" family of releases run a similar process, but all S releases are called "S" regardless of long lived or short lived status. The planned lifecycle of an S release is determined from the release notes.

It is critical to note that the 15.1 T and 15.1 S releases will NOT share the exact branch of code the same way that as in the 12.x families. There will be a lot of parts in common, but you cannot assume that 15.1(x)T and 15.1(x)S will be feature-for-feature or bug-for-bug compatible like you could in the 12 releases.

http://www.cisco.com/web/about/secu...ce/ios-ref.html is a pretty good reference. (Oh, snap, it doesn't cover the IOS 15 shift...)

The docs on the web site are lacking in detail. The "graduate to M" idea is not well covered. The new numbering scheme sought to shy away from "low numbers" on a mainline release - "M" now becomes a marker rather than an independent software release train.

Наткнулся на Cisco access list syntax checker. Хорошая утилита, жалко не включена в дебиан и нет готовых бинарников. Сурсы прилагаются, так что хотите - компилите сами.
Кстати, там же и Cisco ACL syntax highlighting для VIM лежит.

Cisco IOS Software Releases 15.0 : Introduction

Cisco IOS New, Modified, Removed, and Replaced Commands, Release 15.0

Хмм... неожиданный эффект, что в 15.0(1)M под dynamips отсутствуют команды ручной установки времени - нету ни clock set, ни calendar set, хотя обе команды присутствуют в документации. Ну и?
Timezone, кстати, выставляется без проблем, но так как считается, что изначально часы роутера выставлены в UTC, то смена timezone тут же изменяет отображаемое системное время. А поправить нечем.