Провайдерское оборудование Cisco

В рамках экзамена от вас потребуется, на мой взгляд, немножко странная вещь. От вас потребуется знание линеек ЦИСКа, которые предлагаются для задач провайдерского уровня. На мой взгляд, это немножко странное действие, потому что, с одной стороны, понятно, почему ЦИСК это делает. ЦИСК хочет, чтобы ее оборудование продавалось, и для того, чтобы оно продавалось, нужно, чтобы кто-то понимал, что он вообще существует, что есть разные оборудования, которые адаптированы под разные задачи. И, как следствие, если вы знаете, как устроена линейка ЦИСКа, то, когда вам нужно решить провайдерскую задачу, вы в первую очередь, конечно, будете иметь в виду то оборудование, с которым вы умеете работать, с которым вы знаете. При этом, естественно, что на рынке, кроме оборудования ЦИСКа провайдерского уровня, есть еще огромное количество оборудования других производителей, которые, на самом деле, не хуже, а зачастую даже лучше, которые дешевле зачастую, опять же. Поэтому, по факту, провайдеров, которые строят свои сети на основе оборудования ЦИСКа, не так много.

Именно потому, что можно найти альтернативное оборудование, которое и дешевле, и лучше. Ну, то есть, да, здесь как бы вкусовщина, конечно, но, тем не менее, бывает такое, что некоторые специалисты считают, что некоторое оборудование других вендоров лучше, чем ЦИСКа. Но, соответственно, на экзамене от вас потребуется знать, какие линейки бывают, какие операционные системы работают поверх этого оборудования, знать приблизительно хотя бы отличительные особенности каждой линейки, то есть понимать, почему эти линейки вообще сделаны. И поэтому мы сейчас кратенько пробежимся по тем продуктам, которые ЦИСКа предлагает провайдерам для построения их сетей, которые ЦИСКа предлагала в прошлом. И, соответственно, как следствие, то, что можно встретить достаточно немаленькое количество сетей, которые построены на оборудовании, которые сейчас уже end of sale и вообще end of life, end of все. Но, тем не менее, да, этого всего еще добра в реальности можно встретить навалом, поэтому мы сейчас пробежимся, посмотрим, что это вообще такое за железо. Основных, скажем, сегментов провайдерского железа мы будем разбирать три штуки.

Первое — это железки под управлением операционной системы ЦИСКа-ИОС. Это достаточно старая операционная система с хорошей давней историей. Но, соответственно, под задачей провайдерского уровня она заточена очень слабо. Мы разберем чуть попозже, почему это так, но, тем не менее, да, вот это действительно так. К этой линейке можно отнести устройство серий Metro Ethernet, то есть все коммутаторы Metro Ethernet, которые иногда не совсем даже и коммутаторы, но, тем не менее, они как-то называются коммутаторами, и поэтому мы тоже будем считать, что это коммутаторы. Metro Ethernet — линеек 26.00, 34.00 — это все древнее-древнее дремо мамонта, но, тем не менее, оно все еще бывает. И почти все эти линейки, к слову сказать, они end of все, то есть они end of support, end of sale, end of life. Но, тем не менее, некоторые железки все еще продаются и все еще саппортятся. Понятное дело, что есть некоторое количество провайдеров, которые используют такое старое железо, потому что оно все еще хорошо работает, с задачами своими справляется на рынке этого бывшего оборудования навалом,

и оно дешевое, поэтому мы, безусловно, будем рады, если вам никогда не придется сталкиваться со старым оборудованием. Но, скорее всего, если вы работаете в провайдере, то вот с такого рода железками вам работать все-таки когда-нибудь доведется. Сюда же можно отнести старые добрые железки, в общем-то, совершенно не провайдерских серий, но, тем не менее, они как бы позиционировались в свое время как железки для предприятий, но они оказались настолько удачными, настолько удобными в работе, что провайдеры с удовольствием эти железки используют даже до сих пор для своих провайдерских задач. Это, в первую очередь, старички и холодильники 65-е каталисты. Понятное дело, что у них есть наследники 68-е каталиста, но ЦИСКО даже не пытается их предлагать провайдерам, потому что они получаются довольно дорогие, и, главное, они ничем не будут лучше специализированного провайдерского железа. А вот шеститонники 65-е каталисты, в частности, это достаточно старые рабочие лошадки, но, тем не менее, они, а, сравнительно дешевые,

и, б, они действительно очень удобные в работе. Да, у них есть свои косяки, да, у них как бы есть особенности, но с этими особенностями вполне можно работать. Поэтому, скорее всего, если вы работаете в провайдере, особенно если этот провайдер не гнушается работать на бывшем железе, шеститонники вам наверняка где-то довстретятся. В принципе, сюда же можно отнести и четырехтонники. Если у вас совсем мелкий какой-то провайдер, то 45-я линейка, в принципе, тоже иногда бывает у провайдеров в ходу. Есть роутеры, которые основаны на операционной системе ЦИСКИУС. Естественно, мы не разбираем самые младшенькие роутеры, там, типа, 29-39 линеек в провайдерских сетях. Это все не в ходу. Если говорить про то, что в провайдерах встретить можно, это 7000-я линейка, 7200-я, 7600 роутеры, и иногда 7300-я, там, на брасах тоже можно будет встретить. Далее. Понятное дело, что ИУС — это система довольно старая, и для современного железа она не очень хорошо подходит,

потому что она, во-первых, монолитная, во-вторых, она не параллелится. То есть у нее есть ряд своих неприятных особенностей. Более новая, назовем это, ветка ИУСа, это не совсем ветка, это полноценная операционная система ЦИСКИУС-ХЕ, но, тем не менее, она в большой степени заимствует идеи, которые были в ИУСе. Это оборудование, которое более новое, более свежее, и, соответственно, сюда относятся железо, которое основано на этой операционной системе ЦИСКИУС-ХЕ, это каталисты 4500-е. Они тоже в провайдерах как бы не предполагались, что они должны бы работать, но, тем не менее, опять же, многие провайдеры по привычке, 4000-е каталисты все еще согласны использовать. Ну, как правило, это происходит именно потому, что там четырехтоники каталиста, их можно встретить в бэушные, сравнительно недорогие. Сюда же можно будет отнести линейки именно специфического провайдерского железа, NCS, Network Convergence System. Большая часть линейок в продуктовой линейке NCS,

большая часть конкретного оборудования будет на работе, на самом деле, на операционной системе ИУС-ХЕР, но некоторые железки в NCS линейке, они будут работать под ИУС-ХЕР. Это, в частности, 500-ки и 4200-й линейки. Они будут с ИУСом, ну, практически обычным ИУС-ХЕР. АСРы, Aggregating Services Routers, 900-я и 1000-я линейка, они очень не похожи друг на друга. 900-я линейка — чисто провайдерская тема, 1000-я линейка — это, в общем-то, линейка для предприятий. Но по мощности они примерно похожи, и в некоторых случаях 1000-ю линейку можно будет встретить и в провайдерских сетях тоже, потому что они как бы наиболее популярны, они достаточно мощные. Кроме того, они делают всякие разные клевые штуки, которые, в общем-то, создавались для предприятий. Но в некоторых экзотических довольно сценариях, но тем не менее в некоторых сценариях провайдеры тоже могут их использовать. Тысячные ИС-АРы, например, могут шифровать трафик. Они достаточно такие неплохие числа-дробилки. Если вы используете какую-нибудь линейку со старшим ESP,

со старшим специализированным процессором для выполнения какой-то задачи, то эти товарищи могут шифровать достаточно большое количество трафика. Там они пережевывают, по-моему, в 80 гигабит, что ли, шифрованного трафика. Это серьезная такая заявка на решение некоторых специализированных задач. Если вдруг вы хотите передавать трафик по своей провайдерской сети с использованием шифрования в силу каких-то ограничений, например, регулятора, то в этом случае тысячные роутеры в принципе могут быть неплохим решением. В основном нас будет интересовать операционная система Cisco EUS-XR. И в принципе железо, которое именно такое специализированное для провайдерских задач, которые делаются сегодня Cisco, оно все ориентировано на эту систему. Эта операционная система абсолютно не похожа на обычный EUS. То есть у нее ничего общего с обычным EUS-ом нет. То синтаксис другой, все другое. Есть, конечно, общие какие-то сходства, но тем не менее они не похожи.

Друг другу не родственники, даже не однофамильцы. И, соответственно, эта операционная система специально создана для сверхвысокопроизводительных роутеров. Изначально она создавалась для линейки Career Routing System. Это такие огромные шкафы, которые можно собрать в несколько шкафную систему. Мы по них посмотрим в конце этого модуля слайдик. Но впоследствии эту же операционную систему, поскольку она получилась довольно удачной, адаптировали и под линейки других, под оборудование других серий. Есть нюанс, почему эта операционная система оказалась такой хорошей. Она, в общем, по большому счету, слизана с операционной системой Junos. То есть те, кто работал с Juniper, с XR окажутся в очень-очень хороших взаимоотношениях, просто потому, что это, да, близнецы-братья. Junos – операционная система с давней историей, которая изначально делалась для удобства управления, которая логична, которая комфортна в работе. И XR, она все хорошие идеи, которые в Junos были,

совершенно абсолютно не сомневаясь, слезала один в один. Поэтому вот, если вы хотите работать с Cisco, и вам нравится Cisco консоль, работайте с EOS обычным, или EOS XE. Если вам нравится Juniper, но вы вынуждены работать с Cisco, вот EOS XR – это фактически твой свет Junosa в мире цисковского железа. Давайте посмотрим, быстренько пробежимся по тем линейкам, которые есть для каждой операционной системы. Начнем мы с коммутаторов серии Metro Ethernet. Это именно коммутаторы. То есть фактически, если посмотреть на их содержимое, это на самом деле коммутаторы-каталист. Те самые 2960-е, 3750-е, 3560-е каталисты – это вот те же самые модели, только в другом корпусе и с немножко измененной логикой работы. То есть у них точно такая же операционная система Cisco EOS. У них точно тот же самый фактический форм-фактор. То есть зачастую можно взять и просто посмотреть на коммутатор Metro Ethernet, посмотреть на коммутатор соответствующей линейки там 3750-й, и вы увидите, что это очень похожие модели.

У них содержимое практически одинаковое. Процессоры все одинаковые, память все одинаковая. То есть все, сами платы одинаковые. Ну, немножко разные образы операционных систем и небольшие, минорные отличия по железу. Ну и корпус немножко отличается. А так, в общем-то, одно и то же железо. Почти все линейки Metro Ethernet, свечей, Cisco перестало производить, перестало продавать по той причине, что, в общем-то, актуальные тенденции в мире провайдерских технологий заключаются в том, что вы трафик обрабатываете на IP-уровне. Коммутацию кадров Ethernet сегодня делать уже практически не принято, по-честному. Прямо вот в том виде, в котором коммутатор обычный, не провайдерский, обрабатывает и коммутирует кадры. Логика вида мы разбрасываем копии кадров по всем портам, кроме некоторых, которые используют абсолютно любой коммутатор Ethernet, она ущербная, и Cisco, наконец, это признала. Поэтому классических, чистых провайдерских коммутаторов Cisco больше не делает. За редкими исключениями. Одним из исключений будет являться вот эта вот железочка,

которая нарисована. Ну, она по совершенно очевидной причине Cisco сохранена пока в портфолио. Она называется роутер. То есть он Metro Ethernet carrier switch роутер. И switch, и роутер в том числе. То есть это железка, у которой достаточно большое количество портов, 24 порта пользовательских. Ну, и, соответственно, она фактически занимается маршрутизацией между этими портами. Но визуально она довольно похожа на коммутатор. Поэтому, да, она и сохранена в портфолио, потому что это роутер. И, по сути своей, она не сильно отличается от коммутатора серии Metro Ethernet. Если говорить про как бы изначальное позиционирование различных свечей этой серии, то в 2600, в 3400, в 3600 свечи предназначались на уровень доступа. То есть это абонентские свечи, не абонентские, а свечи, которые смотрят вас напрямую на абонентов. Это, понятное дело, достаточно простые модели. То есть они не могут детально анализировать трафик, они не могут расковыривать его, не могут выполнять

Deep Packet Inspection. Ну, то есть они могут только коммутировать трафик и больше особо ничего. 3800 и 4900 свечи – это железки более производительные. То есть это фактически роутеры, равно как и каталисты, допустим, 4900. Это не совсем свечи, это, в общем, по большому счету уже роутер. Ну и, соответственно, вот актуальные железки, которые вы сейчас можете купить, и все еще можете купить, потому что, скорее всего, будущее этой линейки достаточно туманное, это вот железки, которые неплохо справляются с обработкой именно айтишного трафика. Они уже не просто коммутируют трафик, они уже его маршрутизируют. Семитоники и шеститоники. Семитоники роутера, шеститоники свечи – на самом деле это все одно и то же. Если мы говорим про 7600 роутеры и 6500 свечи, то это, по большому счету, одни и те же коробки, просто немножко разные форм-факторы. Это модульные устройства, которые позволяют вам

собрать тот конструктор, который решает задачи именно ваши. То есть у вас есть какая-то конкретная задача, которую вы хотите решить, вам нужно для решения это задача определенный набор портов, определенный набор сервисных модулей. Вы покупаете определенный набор портов, определенный набор сервисных модулей, вставляете в вашу коробку, ваша коробка может делать ту задачу, которая вам нужна. Эти модульные устройства, они позволяют именно собрать под вас ту конфигурацию, которая будет удовлетворять вашей нужде. При этом вы покупаете фактически шасси, вы покупаете отдельно блоки питания к этому шасси, вы покупаете отдельно вентиляторы к этому шасси, Вы покупаете отдельно линейные карты, которые вам нужны. Линейная карта выглядит примерно вот таким вот образом. Это как бы порты, которые вы можете купить к вашему устройству. Ну и вот такой классический пример. У вас шеститонник, в нем стоит штатность завода, просто заглушка. Заглушку вытаскиваете, вставляете линейную карту, и у вас свитч получается там на какое-то количество портов.

Я не знаю, сколько здесь еще. Порт 16, наверное, на этой линейной карте. Захотели еще портов, вытащили свободную заглушку, вставили на ее место линейную карту с новым типом портов. И таким образом вы можете набирать ту функциональность, которая вам нужна. Обычно используются такого рода свитчи либо с платами с высокой плотностью, допустим, на 48 портов, либо с высокопроизводительными портами, то есть, допустим, плата на 4, там, 10-гигабитных порта. Ну, точно такого плана. На 8-10-гигабитных портов. Помимо того, вы должны будете приобрести своего рода думалку. Вот эти линейные карты – это просто делалка. У нее есть какая-то программируемая микросхема, которую вы можете задать набор инструкций, она в соответствии с этим набором инструкций будет обрабатывать трафик. То есть у самой линейной карты никакой логики о специальной нету, которую вы можете поменять. Эту линейную карту программирует некий другой модуль. И вот этот другой модуль будет называться либо супервизором,

либо роут-процессором. Если на свече это супервизор, если на роут – это роут-процессор. Но это по сути своей вот этот вот модуль. Вот он как раз нарисован здесь. Вот это супервизор. Это думалка. Это мозг всего свеча, и он управляет поведением всех остальных линейных карт, всех остальных модулей, вентиляторов, блоков питания и всего остального. То есть если вам нужно повысить надежность вашей системы, вы в определенные линейки, в определенные железки, в определенные шасси можете вставить две таких думалки, два таких модуля супервизора или роут-процессора, и тем самым повысить надежность вашей системы. Вот здесь на картинке нарисован 7600 роутер. Вот у него супервизор один, супервизор другой. Вы купили два супервизора, поставили в одно шасси. В каждый конкретный момент один супервизор работает, второй на подхвате сидит ждет, пока первый сдохнет. Если первый сдох, сгорел, неважно, что с ним случилось, второй на себя забрал функции программирования линейных карт. Ну и, соответственно, надежность такой системы, она, соответственно, достаточно высока.

Во-первых, у вас резервирование по питанию, потому что чаще всего такие железки, у них даже не два блока питания, а там четыре, шесть. То есть один сдох вы вообще даже не заметили, продолжаете работать, как ни в чем не бывало. У них резервирование по вентиляторам, и эти вентиляторы на лету можно менять. То есть вытащили блок вентиляторов на лету, вставили новый, у вас железка продолжает работать. Да, она сгорела, да, там вентилятор один сгорел, два сгорела, неважно. У вас их там 10 штук, вытащили, вставили новый, продолжает все работать. Здесь резервирование на уровне роуд-процессоров. То есть один роуд-процессор сгорел, у вас процессор, блин, сгорел. Прям вот из него дым пошел. Ничего страшного, вытащили старый, вставили новый. Пока вытащили, вставили, у вас продолжает все работать. Понятное дело, что этот процесс переключения с одного роут-процессора на другой, он не всегда проходит гладко, и бывают с ним некие сложности, но в целом как бы система заточена под то, чтобы, если у вас есть возможность резервирования роут-процессоров, если вы воспользовались этой возможностью, чтобы железо у вас продолжало работать даже тогда,

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

без подключения супервизора, то он обрабатывается крайне быстро. Если же у вас кадр приходит, не кадр, ну, пакет, кадр, неважно, приходит на линейную карту, а карта говорит, а я не могу с ним справиться. То есть это надо отправить на супервизор. Тот супервизор скажет, опа, ничего себе, тут ничего, работать надо. Ну, начинает тут работать, думает, думает, думает, думает, обрабатывает этот кадр, потом, соответственно, обработал, отправляет обратно на линейную карту, через которую он должен выйти, и с другой линейной карты трафик уходит. То есть этот процесс намного более медленный. Почему я вам это рассказываю? Потому что, например, на тех же самых шеститониках и семитониках есть, например, ограничение по количеству маршрутов, которые вы можете загрузить на вот эту самую линейную карту. То есть на некоторых версиях супервизора, на некоторых версиях линейных карт вы не можете на вот эту вот линейную карту дать слишком много разных инструкций. Если вы обрабатываете, ну, например, полную картину интернета, у вас там будет, ну, по состоянию на сегодня порядка 700-800 тысяч маршрутов,

не в любую линейную карту, не в любой супервизор такое количество маршрутов влезет. И, соответственно, да, в супервизор, в принципе, мог бы и влезть любое количество маршрутов, у него там память эта и сколько угодно. Но в линейную карту оно не влезает чаще всего, если мы говорим про какие-то старые линейные карты. И, как следствие, если вы пытаетесь носовать в карту маршрут, они туда не влезают, кадр какой-то приходит, и что у вас происходит? У вас линейная карта говорит, а я не знаю, что с этим делать, у меня маршрутов нету, потому что то, что хотел супервизор мне носовать, оно мне не влезло, я просто все проигнорировал. И у вас весь трафик начинает ходить через супервизор. А супервизор к такой нагрузке вообще ни разу не готов. Он какое-то небольшое количество трафика проживать может, напрягаясь, но в целом это такой офисный сотрудник, который никогда в руках ничего тяжелее, крандаша не держал. Поэтому если ему предлагают пойти и покопать от забора до обеда, как это делают линейные карты нормально, он, конечно, на этом немножко теряется. Ну и, как правило, у вас просто уходит на стопроцентную загрузку, вы теряете железку по управлению. То есть ничего хорошего не приходит.

Вы должны будете знать возможности вашего оборудования, вы должны будете примерно понимать, соответственно, что ваши линейные карты могут, что может ваш супервизор. И если вдруг вы понимаете, что у вас как-то оборудование работает некорректно, то, чтобы вы понимали, из-за чего это может быть. На основе ИОСа же у нас будут работать и другие железки, но в целом в провайдерских сетях их встретить достаточно редко приходится, поэтому дальше мы переходим к операционной системе ИОС-XE. Это железо чуть более свежее, чем железо на основе обычного ИОСа. ИОС-XE — это более новая операционная система, которая специально сделана таким образом, чтобы выглядеть очень похоже на обычный ИОС. Но, тем не менее, она позволяет делать какие-то вещи, которые обычный ИОС не реализует вообще, не может реализовать в принципе. Обычный ИОС — это операционная система монолитная. Это значит, что все-все-все процессы пользуются единым общим пространством памяти.

То есть, в принципе, если у вас, например, условный EGRP хочет взять, посмотреть, какие маршруты есть у ОСПФа, он может взять, пойти напрямую, посмотреть в адресное пространство ОСПФа и там сделать все, что угодно. Он может записать в адресное пространство ОСПФа чего-нибудь. Понятное дело, что сам ОСПФ может не ожидать такой подлости, что в его адресном пространстве, в его отсутствии кто-то может копаться. И от этого все может пойти как-то сильно наперекосяк. Гипотетически, если бы под ИОС были вирусы, то любой вирус, который мог бы быть запущен в операционке с ИОС, он мог бы сделать абсолютно все, что угодно. Потому что адресное пространство одно, и оно доступно вообще всем. Ну, как следствие, если какой-то процесс у вас начинает работать некорректно, то есть ошибки программирования со всеми компаниями случаются, даже с ИСкой, у вас, как правило, железка просто падает, и падает очень крепко. В случае с ИОС-XE, процесс ИОС выдален в отдельный юзерленд процесс. То есть, да, у вас ИОСовские процессы, именно нативные ИОСовские, по-прежнему продолжают работать в едином пространстве,

но при этом оно не может затронуть какие-то критично важные функции системы. Потому что в ИОСе классическом обычном у вас и драйверы процесса, и драйверы всех систем, и вся сама операционная система, и все процессы, в кавычках, пользовательские, там те самые OSPF, BGP и прочее, они все действительно живут в одном пространстве, и как следствие ошибка в условном BGP может повлиять на работу ядра операционной системы. В ИОС-XE этого не может произойти, операционная система абсолютно изолирована, и все функции, которые мы видим, классические и ИОСовские, они на самом деле выполняются изолированно, обособленно от всего остального. Первое устройство, которое нам здесь предлагается посмотреть, это линейки Network Convergence System, самые младшие, 500-е, то есть бывают и другие, но в провайдерских задачах можно встретить 500-е. Это такой простенький свитч, который предлагается в качестве замены серии Метрезернет. Соответственно, тут есть три линейки на самом деле, то есть 500-ая линейка,

линейка, это на самом деле три линейки, 520-ые, 540-ые, 560-ые устройства. И, соответственно, в 520-й линейке там будет от 4 до 20 гигабитных портов и 4 10 гигабитных порта Аплинка. Эти штуки, они достаточно простые, достаточно дешевые, но это фактически, да, замена серии Метрезернет. У них один роуд-процессор, он занимает один юнит, ну и обрабатывает она вот сколько трафика на ней написано, столько обрабатывает. Математическая сумма скоростей портов, здесь у нас 4 10-гигабитных порта, это 40 гигабит, и 20 портов по гигабиту, это 20 гигабит. Вот действительно она все 60 гигабит может проживать. Более старшая, чуть более старшая линейка, 540-ая, она будет иметь 24 10-гигабитных порта, 8 25-гигабитных портов и 200-гигабитных портов. Здесь уже есть определенная переподписка, то есть мы можем взять, посчитать, что вот здесь вот у нас 200 гигабит,

здесь у нас тоже 200 гигабит, и здесь у нас там 240 гигабит. То есть всего как бы номинально математическая сумма скоростей портов 640 гигабит в секунду. Но по факту 640 гигабит от железка не может проживать, у нее производительность примерно ограничена 300 гигабитами в секунду. По факту в некоторых сценариях вы можете увидеть даже меньше. То есть до 300 гигабит в секунду, это в идеальном раскладе, когда вы самыми большими пакетами отправляете через нее, вот она действительно может профарвардовать столько трафика. В реальности вы наверняка, если попытаетесь на нее 300 гигабит носовать, вы будете отправлять пакетики маленькие, вы будете отправлять пакетики какие-то специальные, и в этой ситуации у вас железка захлебнется несколько раньше. То есть в реальности 300 гигабит от нее ожидать бесполезно, но вот эта вот цифра, она куда-то где-то больше похожа на реальность, честно говоря. Но тем не менее, да, вот смотря, как читать эти гигабиты. Если вам требуется детальная спецификация, как конкретное устройство, сколько трафика оно может проживать, ну, в этом случае, возможно, имеет смысл обратиться к менеджеру, который для вас попытается эти цифры достать.

Мне в свободном доступе это не удалось. То есть Cisco пишет, что до 300 гигабит в секунду, но по факту в 300 гигабит верится с трудом. В идеальных условиях может быть. Если вам нужно будет на основе линейки 500 обрабатывать много портов, то, соответственно, вы можете использовать 560 платформу. Это модульная платформа на 7 ракюнентов. У нее резервируются роуд-процессоры, и в нее вы можете вставить 16 линейных карт. И линейные карты вам позволят иметь столько портов, сколько вы захотите. Но производительность этой штуки достаточно ограничена. То есть у нее Cisco заявляет до 800 гигабит в секунду. Это, в принципе, хорошая скорость. Но если вы используете 16 линейных карт, там в каждой будет, условно, 24 10-гигабитных порта, и у вас 24 умножить на 10 умножить на 16, это будет действительно много. И это означает, что действительно вы не можете загрузить эту железку полностью на математическую сумму скоростей портов никогда.

Но в то же время в провайдерских сценариях очень редко бывает нужно загрузить железку прямо вот целиком и полностью на всех портах, чтобы все порты лежали в 100% нагрузке. Это абонентское устройство. То есть это железка, которая смотрит напрямую на абонентов. Да, у нее может быть 10-гигабитные порты, потому что мало ли вдруг у вас абоненты хотят подключаться на скорости до 10 гигабит в секунду. Но 10-гигабитный порт гипотетически позволяет вам, например, использовать тариф 2 гигабита или полтора гигабита. То есть там, где гигабитный порт уже не вывозят, и нужен более скоростной порт. А вот в Ethernet более скоростных, чем гигабит, это только 10-гигабитная софишка. Ну вот, соответственно, порт у вас как бы 10-гигабитный, и вы можете в него отправлять немножко трафика. Ну, например, вот полтора гигабита. Ну, опять же, максимальная мощность вашего устройства в этом случае все равно ограничена. Опять же, вот это 800 гигабит, в нее верится с трудом, ну, там 500 гигабит она проживать, наверное, сможет наверняка. В каких ситуациях использовать эту штуку?

Ну, вот везде, где у вас раньше использовались свечи в линейке Ethernet, здесь же можно использовать эту линейку. Это фактически замена. Пример, который можно будет вот здесь вот увидеть, это как-то 540-ая железка. То есть вот эти вот порты 10-гигабитные, вот эти порты 25-гигабитные, и вот здесь вот два соточных плюсов и порта. Так. Следующая линейка – это специфическое железо для так называемых legacy-технологий. То есть сама CISCO говорит на самом деле, что если вы строите какую-то новую провайдерскую сеть, не парьте никому мозг, строите ее на Ethernet. Если вам почему-то нужно использовать какие-то кривые косые технологии, ATM, TDM, Sunnet, оптические какие-то сети вы хотите строить, именно не Ethernet-овские, а какие-то вот именно специфические провайдерские, то в этом случае вам нужно будет железка, в которую можно вставить эти кривые косые модули,

с которыми можно будет работать. Всякие VDM-ы хитрые. Это все сюда же. И специальные, адаптированные для вот таких вот кривых косых модулей линейки – это будет NCS 4200. Здесь два устройства на самом деле. 4206 и 4216. В 4216 есть вариант с продувом воздуха спереди-назад, front to back, или сбоку-набок. Ну вот, соответственно, вот это вот 4206 железка, это 4216 с обдувом сбоку-набок, и вот это вот она же, но с обдувом спереди-назад. В зависимости от того, как устроен ваш узел связи, как там сделано охлаждение, вы можете по-разному продувать, соответственно, ваше оборудование. Где у вас холодный воздух можно забрать, куда можно выплюнуть горячий воздух. Если у вас спереди забор холодного воздуха, то вам нужна вот эта штука. Это устройство тоже с высокой плотностью портов, но не такое высокое, естественно,

как у предыдущей линейки, потому что порты для этой линейки, как правило, кривые косы специфические, и там 48 портов на один линейный модуль просто невозможно сделать в силу ограничений технологии. Ну, то есть, да, идею, я думаю, вы поняли. Затем на основе iOS XE можно будет увидеть 900-е роутеры. Это роутеры-агрегаторы, то есть роутеры, которые ставятся на уровень агрегации для того, чтобы собирать трафик с железок доступа. И, соответственно, в принципе, они же могут быть и IP-Edge устройствами. Здесь у нас есть три основные платформы. Это 902, 903, 907. 902 самый маленький, самый младшенький, 903 побольше, 907 самый большой. Последняя циферка означает количество юнитов, которые занимает железка. У 902 один роут-процессор, у остальных по два. Ну, и, соответственно, кроме роут-процессора, кроме думалки,

все остальные места можно будет занять делалками. Ну, и в каждый юнит влезает, на самом деле, по две железки, по два модуля, плюс-минус километр. В 902 влезает один роут-процессор, который скрыт, и четыре интерфейсные карты, четыре модуля. Раз, два, а, ну, поспите, раз, два, три, четыре. В 903 влезает, соответственно, шесть модулей, и в 907 влезает 16 модулей. Ну, вот она, 907. Тысячные роутеры — это, как уже было сказано, вообще-то железки не провайдерские, а железки для предприятий. И вообще-то они заточены под какие-то вычисления, скажем так. То есть у них есть специализированная штука, которая называется ESP, Embedded Service Processor. И эти самые ESP, они могут быть разные в зависимости от того, какие задачи вы хотите на этом роутере решать. Хотите заниматься шифрованием? Пожалуйста.

Хотите заниматься каким-то специфическим Stateful Firewall? Пожалуйста. То есть это железки, которые оказывают дополнительные услуги по сравнению с обычной маршрутизацией. Но в некоторых случаях и провайдерам те же самые Firewallы могут быть небезинтересны. Поэтому они в некоторых случаях с удовольствием эти железки закупают и для своих задач. Здесь в тысячной линейке большое количество устройств на самом деле продается. Они делятся на два набора. Первый набор — это железки с одним роут-процессором. То есть вот это вот, это вот они. Различаются они помимо того, что у них там сколько процессоров есть. То есть они делятся вот. Здесь у нас один роут-процессор, здесь у нас два роут-процессора. В том классе, где один роут-процессор, они различаются производительностью. То есть там 1001х и 1001h. Они различаются тем количеством трафика, который они вывозят. Правильно, там 1002х, 1002h. Это все. Они различаются именно количеством трафика, который они могут обработать и специфика этого трафика. То есть нужен ли вам Firewall,

нужен ли вам шифрование и так далее. А вот эти вот товарищи, они различаются тоже между собой количеством трафика, который они могут проживать и фактически они различаются вот этим вот ESP, Embedded Service Processor. На них, на этой линейке по два процессора ставятся, ESP. Соответственно, если один выходит из строя, второй подхватывает на себя знамя из выпавшего рук первого. Самая младшенькая линейка, самая младшенькая железка, 1001 роутер может обработать 2,5 гигабита фаерволла. Самая жирненькая, вот эта вот, она может обработать вот столько, 200 гигабит фаерволла. То есть зависит от процессора, который у вас используется. Вот так. Дальше. Следующая линейка — это уже XR-ные роутеры. Они уже визуально прямо больше. То есть хорошо видно, что на предыдущем слайде, вот у нас предыдущий слайд, самая большая линейка, самая большая железка была, там, сколько, 13 юнитов.

Ну, 13 юнитов — это много, это как тумбочка. Но 9-тонники, они прям большие, они занимают целый шкаф. 44 юнита, если быть точным. Вот это вот, товарищ, 44 юнита — это больше, чем 42-юнитовая стойка. Это все модульное устройство. То есть вы, опять же, можете сделать конструктор, сделай сам, который будет решать именно ваши задачи. В этой линейке есть железки маленькие, есть железки большие. Маленькая железка — это вот эта фиговинка. Фиговинка. Это 9001 роутер. Он занимает 2 рак-юнита и способен проживать 800 гигабит трафика. То есть это IP-шный трафик, это не коммутация, это IP. Но понятное дело, что все остальные железки, которые есть в этой линейке, они все более производительные. И самый жирный, самый толстый вот этот вот товарищ 99-22, который занимает 44 рак-юнита, у него циферка по производительности весьма и весьма приятная. Понятное дело, что вот это такое количество трафика, 160 терабит в секунду,

это для современных небольших провайдеров цифра недостижимая. Поэтому такое железо, естественно, заточено под работу именно крупных, очень крупных провайдеров, когда в одной точке у вас стекается очень-очень-очень много каналов связи. И вам нужны эти каналы связи где-то совместить между собой, просчитать трафик, который идет между этими каналами, промаршетизировать его, каналы все быстрые. И, соответственно, если вам нужна сверхвысокая плотность портов, причем портов быстрых, то вот в этом случае 9-тонники старше вас, в принципе, могут спасти. Понятное дело, что если вы крупный провайдер, не знаю, условный Vodafone или, не знаю, Teleasonera, и у вас есть такой узел связи, куда приходит какое-то колоссальное количество там 10-гигабитных, 100-гигабитных портов, то вы, покупив такую железку, естественно, очень не хотите, чтобы она в какой-то момент сказала «мяу» и перестала бы работать. Потому что на этой железке у вас фактически вся ваша сеть будет завязана.

И, естественно, что Cisco отвечает на такой вызов, она обеспечивает максимальную отказоустойчивость по всем элементам конструкции такого роутера. То есть у нее резервируются процессоры, роут-процессоры, у нее резервируются фан-модули, у нее резервируются блоки питания, у нее резервируется вообще все, что только можно зарезервировать. И сама операционная система, естественно, тоже. Вот. К девятитонникам полагается бонус. Это моделька, которая называется ISR-9000V. Вообще, если обычно у Cisco что-то, что заканчивается на V, означает, что это что-то виртуальное, то есть, например, у той же CSR-1000V, это виртуальная машина, которая может быть роутером. Nexus-1000V – это виртуальный свитч. Он в виртуалке запускается. Но вот 9000V – это не виртуальная железка, это абсолютно настоящая реалистичная железка. Вот она здесь нарисована. Это модуль расширения на 44 порта гигабитных и 4 аппли 10 гигабитных SFP+.

То есть вы в один порт такого жирного свитча можете вставить провод, который с другой стороны вы втыкаете в модуль расширения, и у вас появляются порты, которые управляются одним большим вот этим вот роутером. Вы можете этот модуль расширения использовать с любой линейкой девятитонника. И, соответственно, если у вас есть, например, тот же самый 9001-й роутер, у него своих портов может быть не очень много, но вы втыкаете в эти порты модуль расширения, и у вас получается вот этот вот маленький роутер, который визуально как бы небольшой, он обрастает огромным количеством портов. У вас будет там, не знаю, 8 портов в нем, а вы в каждой из этих 8 портов втыкаете модуль расширения на 44 порта. И у вас получается в этом роутере физических портов становится, сколько получается, 500 штук. Да, а-ля фикс для Nexus, если вы работали с Nexus. То есть это фактически вот там у Nexus это двухтысячная линейка, а здесь это 9000V. Так, и, наконец, жирные товарищи пошли.

То есть первый жирный товарищ 99.44. Это вот как бы пример того, с чем мы будем сталкиваться, если мы хотим потратить очень много денег. Ну, NCS 4000 — это железки чуть покомпактнее. Они тоже очень дорогие, и если говорить про вот эту вот линейку 4000, она адаптирована специально под оптические сети с уплотнением каналов. То есть если мы используем DVD, мы можем использовать, в принципе, 4200 линейку, которые на iOS XE, а можем использовать 4000 линейку, которые на iOS XR. Здесь две железки продаются, 4900 и 4016. Различается с количеством интерфейсных карт, которые могут в них влезть. То есть в 4009 влезает 9 линейных карт, в 4016 влезает 16 линейных карт. Ну, или интерфейс модулей IC, интерфейс карт. Понятное дело, что все резервируется. Понятное дело, что если у вас используются модули, которые очень хорошо уплотнены,

то даже если вы используете линейную карту, у которой там может быть один порт физически, таких карт нет, но гипотетически представим себе, что у вас есть линейная карта, которая занимает там почти один юнит, и у нее всего один порт. Но фишка в том, что этот один порт может работать на совершенно колоссальной скорости, потому что он одновременно внутри себя обрабатывает много разных каналов. Если вы используете DVD, спектральное уплотнение каналов, то у вас одна как бы SFP-шка может принимать совершенно сумасшедшее количество трафика, совершенно сумасшедшие объемы. Поэтому для того, чтобы обработать такое большое количество трафика, и для того, чтобы это количество трафика можно было промарштизировать, у этих товарищей есть отдельный фабрик карты. То есть вы можете купить к этим товарищам по началу, например, если вы планируете, что у вас на начальном этапе трафика будет не очень много, вы покупаете нужное вам количество линейных карт, и вы покупаете один модуль фабрик карты. А потом у вас начинают расти запросы, вы говорите, о, у нас сейчас трафика становится больше, наши фабрик карты не справляются, вы вот докупаете к ней фабрик карты,

и вот этих фабрик карт можно поставить 4 штуки. Ну, в принципе, в старших Nexus'ах та же история. Так, пятитонники, NCS 5000 и 5500. Компактное устройство с высокой плотностью. Можно использовать для ядра, можно использовать для агрегации. Сумасшедшие какие-то цифры производительности, то есть самый старший товарищ, вот этот вот, 55-16. Ну, я не буду комментировать, сами все видите, 50 терабит трафика. Я не знаю, где столько взять. Я не видел никогда столько трафика вживую. Но, тем не менее, вот бывают железки, которые одна железка может столько проживать. Опять же, если вам нужно где-то принять в одной точке очень много каналов, и эти каналы будут очень быстрые, то вот это вот устройство, которое имеет много портов, 10-гигабитных, и позволяет обработать действительно много-много трафика. Если у вас портов столько, что они не влезают в пятитонник,

что они не влезают в 16 линейных карт, или сколько там еще, то есть портов действительно много, то Cisco еще в 2004 году придумала такую штуку, как Carrier Routing System. Вот на картинке нарисовано три шкафчика. Это не три разных роутера. Это один роутер, который соединен из трех различных шкафов в единую систему. Эта штука называется CRS Multi-Shell System. То есть вы можете купить одну такую стойку, или вы можете купить две таких стойки, или три таких стойки, и соединить их в один мега-роутер, который будет обрабатывать много, действительно много трафика. Самые первые линейки, эти самые CRS, они уже давно сняты с производства, с поддержки, но тем не менее, до сих пор они еще показывают совершенно сумасшедшие цифры по скорости. Но в этой линейке CRS уже давным-давно предложены более новые модели. Вот актуальная модель, которая сейчас продается, она обеспечивает производительность вот такую вот на одну стойку, на один шкаф.

И вы этих шкафов можете собрать, по-моему, 64, что ли, штуки в единую систему, и итоговая производительность у вас будет вот такая вот. То есть это... Я уже не помню, сколько это. Вот есть гигабит, есть терабит, а что там следующее, я уже не помню. Ну, короче, это очень много. Понятное дело, что в реальной сети, в которой вы ходите на курсы с PNG N1, вряд ли вам дадут с такой штукой поработать. Но, по крайней мере, чисто так это поразвлекаться, посмотреть на то, что такое в принципе бывает, можно. Понятное дело, что если у вас вот такое количество интерфейсных карт в такой системе торчит, и в каждой карте у вас там 48 портов, то есть вот я сейчас это буду реально умножать в столбик. Я не буду умножать, это в столбик, это, короче, очень много. Это там тысяча примерно умножить на 50, это порядка 50 тысяч портов может быть в такой системе. Естественно, не предполагается, что вы этими портами рулите вручную. Естественно, предполагается, что все это работает с системой какой-то автоматизации, то есть у вас робот будет управлять поведением этой системы,

будет программировать ее, и все это предназначено для работы с сетями следующего поколения, с software-н-defined, все. Дальнейшее развитие этой идеи породило линейку NCS 6000. Здесь продается две железки. Это железка, которая называется LCC и FCC. LCC — это железки, в которые втыкаются линейные карты. В каждую линейную карту, в каждую железку можно воткнуть, соответственно, там, если меня память не изменяет, 8 интерфейсных карт. Но там интерфейсные карты, они большие. Это не то, что там один юнит, это одна интерфейсная карта. И, соответственно, на одну вот такую LCC у вас производительность до 16 терабит в секунду. И, соответственно, вы можете этих LCC, можете их соединять между собой. То есть так же самая история, что в CRS, но только немножко по-другому сделано. Вы можете взять и две LCC-шки поставить бок к боку.

Ну, то есть просто вы будете соединять их, ну, не то чтобы одним проводом, да, но соединять их между собой. И у вас получается один роутер, который занимает две стойки. При этом, если вы хотите соединить, допустим, три шкафа между собой, вы уже не можете их соединить просто прямым проводом. Вам потребуется вот эта вот штука, которая называется FCC — Fabric Card Chassis. Это интерконект, который позволяет соединить между собой четыре стойки LCC. Но вы можете соединить их не просто как бы, у вас будет там четыре LCC-шки, это FCC, это LCC, это тоже LCC, это тоже LCC. Вот вы можете сказать, оно подключается вот как-то вот так вот. И вы можете взять и FCC-шки тоже между собой соединить. И у вас это такой свитч для вот этих роутеров. И опять же, вы можете носовать в единую систему. Я, честно говоря, тоже не помню, сколько там этих LCC-шек можно носовать в единую систему, но предположу, что их тоже там может быть 64 штуки. 64 штуки умножить на 16 терабит в секунду.

Петабит. Вот. Я здесь себе сам написал, как называется, та самая единица измерения трафика, которая следующая за терабитом. Петабит. Пожалуйста. Понятное дело, что 64 шкафа таких — это, ну, такой здоровенный маш-зал. То есть в обычном дата-центре обычный там ряд стоек, ну, сколько, 10 стоек стоит. Вот он уже такой хороший, длинный, вытянутый. Вот здесь 6 рядов стоек. По 10 стоек в каждой. Это только LCC-шки. Плюс еще на каждые там примерно 3 LCC у вас будет стоять отдельный FCC-шкаф. То есть на 64 стойки LCC вам понадобится там 20 стойок FCC. То есть это всего получается 80 шкафов. Но это единая система на охрененное количество портов, которые обрабатывают охрененное количество трафика. Понятное дело, что таких штук в мире не очень много. То есть вы вряд ли будете когда-либо работать в компании, в которой это вам дадут потрогать. Вряд ли вы увидите это вживую когда-нибудь. Я не видел. Но тем не менее, как бы, производители вот такие вот штуки делают. Понятно, штука эта скорее имиджевая, статусная.

Но в некоторых ситуациях, может быть, кому-то это и будет интересно. Ну, скорее всего, это какие-то операторы сверхкрупные, типа тех же самых TR1. Так. Мы с вами посмотрели кратенько обзор железа CISC, который предлагается для нужд провайдеров. Мы посмотрели с вами три операционные системы. CISC EOS, EOS XE и EOS XR. И кратенько сейчас пробежимся по ним, чем они отличаются друг от друга, почему CISC сделала три разные операционные системы, то есть зачем вообще потребовалось плодить сущности. Начнем с самой старой операционки. Это CISC EOS обычная. Как уже было сказано, она монолитная. То есть это единый процесс, который позволяет переключаться между разными контекстами. Но эти самые контексты между собой, они переключаются немножко не по-честному. То есть у вас, если есть какой-то контекст, куда вы переключились, дальше он должен закончить обработку того дела, которым он занимался, и вернуть управление кому-то другому.

То есть у вас, в принципе, может быть, не очень справедливая ситуация в EOS, когда какой-то процесс получает фокус, и он его не отдает. Вот это получается не параллелизм, а какая-то вот такая попытка договориться между разными процессами, как должны они одновременно между собой работать. У вас может быть такое, что у SPF вы дали управление, и все, и у SPF никогда не отдал. И у вас нитил нет не работает, ничего не работает. Фактически железка дохнет от этого. То есть у вас все ломается. Когда какая-то нитка берет эксклюзивно себе управление процессором, и дальше с ней что-то происходит. Понятное дело, что такие штуки, они достаточно быстро ловятся, что баг, когда у вас система перестает внезапно отвечать, ну, как правило, да, это баг, который очень неприятный, и в большинстве ситуаций пользователь, который сталкивается с таким багом, он звонит в Cisco так, говорит, что у вас за фигня, почему же Cisco ваша дохнет? Типа денег заплатили, а она не работает. Ну, тяжелое наследие. Cisco EOS — это очень старая операционная система.

Она создавалась в конце 80-х годов, и, соответственно, старые версии EOS, они даже не были похожи на современные версии. Я уже говорил, что управлялись они по протоколу TFTP. Вы должны были для того, чтобы изменить конфигурацию EOS старых-старых версий до 92-го года, вы должны были по TFTP скормить ей новый файлик Startup.Config и перезагрузить железку. Такого понятия, как Running.Config, у таких железок просто не было. У них был только Startup.Config. И вы могли только перезагрузить железку и заставить железку работать в новом файлике, который вы ей скормили. В 92-м году у EOS классического появляется консоль, в которой можно изменить состояние устройства, и появляется отдельная сущность Startup.Config, и отдельная сущность Running.Config. И появляется возможность управления железкой в том виде, в котором мы ее знаем. Но изначально EOS создавался под классовые системы. Поэтому в очень-очень-очень многих сущностях мы видим те самые классовые следы. То есть мы видим, что EOS несет в себе багаж

всех легоси-технологий, которые когда-то давным-давно были, когда-то в 80-х годах, в 90-х годах это все еще было актуально. А вот в 2020 году, в 2019, какой сейчас там год идет, мы вынуждены терпеть все это в EOS, потому что, мало ли, вдруг какой-нибудь наркоман купит свою циску и скажет, а чего в ней не поддерживается старый протокол IPX, который вот у меня там использовался. И вот для того, чтобы обеспечить обратную совместимость, все это дело тянется, тянется, тянется. И это уже обросло таким количеством костылей, что уже непонятно, почему оно так. Классический пример — это команда Network в настройке Root.Roy SPF. Она вообще никакого отношения к сетям не имеет. Ни к префиксам, ни к сетям, ни к чему. Это вообще условия аксесс-листа. Но называется Network, потому что когда-то давно в классовом мире эта команда действительно имела смысл, там действительно задавалась сеть. Вы задавали классовую сеть, в которой должен был находиться ровно один интерфейс. Ровно на одном интерфейсе вы тем самым включали динамическую маршрутизацию. Но потом, когда классовые сети отмерли, когда надо было работать уже с безклассовыми сетями, команду оставили, потому что не переделывать же команду.

Ну и она современный смысл полностью изменила. Синтаксис остался старый, а смысл изменился полностью. Вот таких вот костылей в более новой операционной системе естественно, циск хотела бы избежать. Но возникала проблема. Проблема следующего характера, что все, кто работал с классическим ИОСом, который создан для обычных предприятий, они уже научились работать со всеми этими командами. Для всех уже нормально является то, что OSPF включается на интерфейсах команды Network, хотя ничего имеющего отношения к сетям не происходит при этом. И переучивать людей, соответственно, оказалось долго-дорого некомфортно. И циск сказал, ладно, будем продолжать жрать кактус, будем продолжать выпускать систему с тем синтаксисом, к которому все уже привыкли. Давайте только откажемся от всех костылей, которые прямо вот сильно мешают жить. Откажемся от того, что у нас монолитная операционка, то есть у нас в одном адресном пространстве и ядро, и пользовательские процессы, и все на свете. Давайте сделаем какую-нибудь операционочку, возьмем, например, какой-нибудь там, не знаю, Linux, например, и запустим в UserLand процесс,

который бы очень вел себя похожий на операционную систему EOS. И действительно вот так и сделали. То есть Cisco EOS XE — это фактически Linux-овый процесс, который ведет себя как монолитная Cisco EOS, но без операционной системы. То есть все, с чем может взаимодействовать пользователь, все, с чем может взаимодействовать линейные карты, вытащили в отдельный процесс, который назвали EOS D, а все, что касается инфраструктурной части системы, оставили в ядре в операционной системе. Благодаря этому у нас появилась отдельно как бы думалка, отдельный процесс думалка и отдельный процесс делалка. Соответственно, у нас есть линейные карты для таких устройств и есть те самые супервизоры, которые управляются операционной системой в целом и процессом EOS D в частности. И вот этот вот самый процессор, он фактически программирует линейные карты, программирует порты, если хотите, для того, чтобы они корректно обрабатывали трафик. И у нас на уровне архитектуры операционной системы появляется разделение на control plane и data plane. То есть у нас трафик идет согласно политикам,

которые прописаны для обработки этого пользовательского трафика, то, что называется data plane, и есть какой-то управляющий трафик, который не обрабатывается на уровне data plane, он обойдет на центральный процессор. И вот, соответственно, с этим трафиком идут какие-то другие действия. Условно говоря, от control plane страдает центральный процессор, потому что он работает и обрабатывает такой трафик, и трудится над ним. А от data plane страдают линейные карты, потому что это вот то, с чем им приходится работать. Они копают от забора до обеда, взяли лопату в руки и вперед. И вот data plane — это то, как линейные карты должны копать. EOS XE появилась в 2008 году с появлением линейки ISR 1000, то есть те самые роутеры, которые создавались для сетей предприятия. Фактически EOS XE — это попытка освежить немножко EOS, избавиться от архитектурных костылей, которые в EOS'е понарождались за время, там, с конца 80-х годов, сколько? 30 лет операционки. Ну, то есть она немножко изменилась внутри,

но при этом она осталась абсолютно такой же снаружи. Синтакси с EOS'а в EOS XE сохранился целиком. Если вы будете работать с EOS'ом обычным или с EOS XE, вы, скорее всего, даже разницы не заметите. То есть там есть разница. Show, version немножко другой. Немножко другие выводы команды Show иногда бывают. Но в целом абсолютно идентичные ощущения, абсолютно идентичный эксперт работы EOS XE создается. EOS XR, в свою очередь, это операционная система, которая изначально создавалась для нужд провайдеров. Она решала провайдерские задачи. Здесь не написано, но неплохо было бы указать, что авторы вдохновлялись операционной системой Junus, которая была создана не просто для нужд провайдеров, а для нужд людей, которые работают в провайдерских сетях. Она была уже нормальная. У нее изначально логика была вполне определенная. Уже не было какого-то странного, кривого, костыльного файлика стартап-конфиг, в котором все записывалось. То есть там конфигурация была вполне определенно выстроена в иерархию.

И вот все хорошие идеи, которые на тот момент, в 2004 году, Cisco смогла своровать у Junus, она, соответственно, своровала и сделала свою операционную систему. Ну, своровала не хорошее слово, но она вдохновлялась этими идеями. Вот. EOS XR изначально использовал проприетарную систему CoinX до пятой версии, и на основе ядра крутились уже пользовательские процессы. То есть все процессы, которые отвечают за работу операционной системы, именно ядра операционной системы, они были обособлены. Все процессы, которые отвечали за взаимодействие с пользователем, с железом, со всеми, с программированием этих самых линейных карт, это было все отдельно вынесено в пользовательское адресное пространство. Ну и все процессы, естественно, были изолированы. То есть на те же ошибки, которые CISCO наступала на грабли с обычной операционной системой CISCO EOS, она уже повторно наступать не стала. В пятой версии CISCO поняла, что вот эта вот самая прориетарная операционка QNX им не очень подходит, и они перешли на Linux.

То есть шестая версия CISCO EOS XR использует операционную систему Linux, и дальше все, что работает поверх этого самого Linux, оно разнесено уже по отдельным процессам. Создавалось все это дело для CRS, не CSR, CRS, Carrier Routing System 1 первого поколения, ну и сейчас вот пускается CRS 3. Если говорить про обычный EOS, ну я уже все рассказал, да, что общее пространство памяти, что все процессы на самом деле живут в том же месте, где все остальные, то есть есть компоненты, и у вас OSPF может взять и заглянуть в пространство памяти EGRP, или заглянуть в пространство памяти SNMP, может там что-то поправить, может взять и сказать, вот здесь у тебя единичка лежит, мне не нравится, что у тебя там лежит единичка, я тебе хочу туда нолик прописать. То есть OSPF залез в чужое адресное пространство и там что-то натворил. Это возможно в результате либо какой-то ошибки программирования, либо в результате, скажем, упрощения работы программистов, когда программисты говорят, вот нам надо, допустим, сказать, что у нас есть OSPF процесс, и нам нужно в SNMP отдать указание, что он запущен, он у нас запущен с таким-то номером.

Типа давайте мы по SNMP будем отдавать, что у нас OSPF запущен, давайте процесс OSPF при запуске будет лезть в место, куда SNMP будет смотреть в свое адресное пространство, и дальше будет считывать то, что мы туда запишем. По-хорошему, конечно, это делается через межпроцессные вызовы, но в EOS нет такого понятия межпроцессный вызов, у них есть просто общее адресное пространство, и каждый пишет в чужое адресное пространство, в чужую область памяти, как захочет. Вторая проблема — это планировщик-шедулер. Когда у нас есть несколько процессов, которые должны выполняться плюс-минус километр одновременно, ну или не совсем параллельно, но хотя бы сначала один, потом второй, потом третий, чтобы это было по-честному, плюс-минус километр опять же, то в EOS это сделать нельзя. Если у вас какой-то процесс скажет, а я не хочу отдавать фокус, я не хочу передавать управление следующему процессу в очереди, все, система встает. То есть до тех пор, пока процесс добровольно фокус не отдаст, следующий процесс свой фокус не получит. Отдельной проблемой является то, что этот EOS действительно монолитный получается, то есть он будет заточен адресно под конкретное все.

У вас получается EOS, сам образ операционной системы, он должен хранить и все вот эти вот самые штуки, там OSPF, EGRP, BGP, что там еще есть, то, ради чего мы EOS покупаем. Плюс он должен хранить все драйвера для железа. Плюс он должен быть предназначен для работы для конкретной операционной, для конкретной платформы с конкретным типом архитектуры процессора, с конкретным количеством памяти. То есть если у вас есть железка, там, не знаю, Cisco, EOS, там, не знаю, 7301 роутер. 7301. У него есть конкретный процессор, у него есть конкретная оперативка, на которую EOS может рассчитывать. Поэтому для именно 7301 роутера вы должны будете сначала, не вы, а Cisco должна будет скомпилировать специальный файлик, в котором будет храниться образ операционной системы именно под 7301 заточенный. Потом вы этот файлик должны будете загрузить на роутер и запустить, если вы хотите операционную систему EOS обновить. То есть вам придется целиком перекомпилировать образ вместе со всеми его компонентами, вместе со всеми драйверами, вместе с операционной системой, вместе с всеми вот этими вот штуками, там, не знаю, с NMP, RPE.

Все, все, все придется сделать. Это единый файл, одна штука. Нельзя сказать, давайте обновим только EGRP. Нам не нравится, как EGRP работает, новая версия EGRP нас более бы устроила, но вы не можете это сделать. Вы должны будете перезаменить целиком EOS одну штуку. В EOS XE, соответственно, то, что не относится к работе операционной системы, самой по себе, вынесли в отдельный монолитный модуль, который называется EOS D. То есть фактически взяли, ну, по-хорошему, сделали виртуальную машину и в нее запихали обычный EOS, и назвали это EOS D. Но то, что отвечает за работу железки в целом, то есть драйверы, операционная система, все вот это вот, оно осталось обособлено, и за это отвечает операционная система Linux. Учитывая, что EOS D это фактически виртуалка, в которой запущен обычный EOS, на основе этого же механизма запуска виртуалок вы в EOS XE можете носовать и другие виртуалки. Это, на самом деле, очень прикольная вещь. Вы можете взять натурально, создать виртуальную машину и запихать в нее, что захотите.

ЦИФКОС штабно предлагает запихивать в EOS XE в качестве нагрузки такой вот левой, если хотите, в AirShark. То есть у вас на самом свитче, на самом роутере будет работать в AirShark. Вы можете взять и практически любую нагрузку использовать через Linux контейнеры на роутере, на свитче. То есть у вас есть роутер с EOS XE, вы можете туда запихать все, что захотите. Хотите, винду на него поставьте, если сможете найти такую винду, которая сможет запускаться на роутере. Вот, то есть это действительно Linux, в котором можно запустить совершенно произвольную нагрузку. Вы можете взять и получить доступ к этому контейнеру сравнительно просто. То есть вы получаете сначала доступ к консольке вашей ЦИСКе, а потом вы говорите, а покажи-ка мне гостевой shell такого-то контейнера. И вы попадаете внутрь shell контейнера. И у вас вот здесь вот линуксовая машина, с которой вы можете что-то сделать. Можете, не знаю, веб-сервер на ней запустить. Все пользовательские штуки, которыми располагает EOS XE,

то есть вся полезная нагрузка, ради которой мы на самом деле запускаем роутер или свитч, в EOS XE хранится в отдельной базе данных. Она называется CrimsonDB. И если вдруг вам понадобится что-то, допустим, перезапустить, допустим, вы понимаете, что у вас EOS PF плохо работает, вы можете сказать, окей, записываем какое-то актуальное состояние EOS PF в базу данных, прибиваем процесс EOS PF, запускаем новый и считываем актуальное состояние EOS PF из базы. И нам не надо повторно по новой переустанавливать соседские взаимоотношения, кричать соседям, ребята, я сдох, давайте наформите меня новыми LSA, я вас тоже новыми LSA накормлю. Вы запускаете новый процесс EOS PF, и никому ничего не говорите. Соседи ваши не видят моргания у SPF. У вас один процесс EOS PF помер, второй запустился, но у него все содержимое, условно говоря, оперативной памяти, считалось из базы, и поэтому он ведет себя точно так же, как тот процесс, который сдох. Таким образом, можно будет резервировать отдельные процессы в рамках EOS.

Можно будет изолировать эти процессы, можно будет сделать так, что если один процесс сдох, не страшно, завис, не завис, прибиваем, запускаем новый. В обычном EOS это было сделать нельзя. Если у вас один процесс плохо себя чувствовал, у вас падала железка целиком. Kernel Panic обычно шел. EOS XE будет состоять из отдельных модулей. Эти модули я уже вам, в принципе, рассказал. Ключевой модуль EOS D, ради которого все затевается. Помимо этого EOS D есть база, в которой все хранится. Помимо этого есть такая штука, как Hostetabs. Ну, это фактически Linux контейнеры, в которых вы можете что-нибудь носовать полезного. Хотите, носуйте в Airshark. Хотите, носуйте просто виртуалку. Хотите, поднимите на ней чего-нибудь. Если вы хотите обновить операционную систему, EOS XE, то вы можете обновлять это не монолитным файлом, как это происходило в случае с обычным EOS, а вы можете обновлять все попакетно. Пакеты бывают следующие. RP-Base — это базовая операционная система, сама вот Linux.

Дальше. RP-EOS — это тот самый демон EOS D. То есть у нас отдельная операционная система, которая отвечает за корректную работу самой платформы. И отдельно то, ради чего мы запускаем EOS XE. Это сам EOS. EOS как отдельный процесс будет управлять поведением линейных карт, поведением портов. И для взаимодействия EOS D и вот этих самых линейных карт используется пакет, который называется RP-Control. Он фактически как прокладка между железом и операционной системой CISC-EOS. Его тоже можно отдельно обновлять. Дальше. За управление вашей CISC-EOS будет отвечать отдельный модуль, который называется RP-Access. Вы можете обновить какой-нибудь, например, тот же самый EOS, и при этом не потерять управление через Telnet вашей железкой. Потому что фактически административные все процессы, вот эти всякие Telnet, SSH и прочее — это все отдельная штука. И вот за взаимодействие с этими штуками отвечает отдельный пакет.

Его обновлять надо редко, и если вы вдруг захотите его обновить, ну, значит, возможно, вам придется переподключиться. Если вы обновляете что-то еще, то это вообще никак не повлияет на вашу контроль над железкой. Дальше. Если говорить про EOS XE, то линейные карты, они будут содержать в себе модули. И вот есть отдельно драйвера своего рода линейных карт. Это, соответственно, Shared Port Adapter в терминологии EOS XE, SIP SPA пакет. И есть сами порты, с которыми можно будет работать. SPA Interface Processor — это работа с линейной картой в целом. Понятное дело, что вот эту штуку можно понадобиться обновлять чаще, а вот эту штуку немножко пореже. Если у вас есть EOS-овская железка с ESP, то есть с отдельным процессором, который решает какие-то кастомные задачи, например, шифрование драйвера или firewall, то обновить это дело можно с помощью пакета ESP Base.

Если у вас есть операционная система EOS XR, то с ней все, соответственно, еще лучше, чем с EOS XE. То есть там вообще все изолировано. Как уже было сказано, используется ядро Linux. То есть операционная система вот отдельно Linux-овая, отдельно драйверы, отдельно у вас запущены все процессы. Тот же самый, допустим, OSPF — это уже не демон EOS D, а внутри которого есть какая-то нагрузка, напоминающая OSPF. Это прямо отдельный OSPF процесс. И сама операционная система может рулить отдельным процессом. Сказать, OSPF нам не нужен, выкидываем его. В случае с EOS XR, более того, есть такая штука, как резервирование процессов. То есть вы можете сказать, что вы хотите, чтобы у вас OSPF был запущен, но на самом деле давайте запустим OSPF-а два. Один сдохнет, а мы второй сразу из бэкапа поднимем. То есть у нас будет этот самый бэкап, у нас будет прямо два процесса одновременно. Один живой, а второй вот про запас на всякий случай, если пригодится. Это все в рамках одного роуд-процессора происходит. Это не то, что у нас отдельная думалка запущенная,

на ней там то же самое все есть. Нет, это в рамках одного роуд-процессора у нас запущены два OSPF-а. Один настоящий, а второй двойник зеркальный. Один сдохнет, а у нас второй уже сразу готовый. Так, это вот что касается операционной системы EOS. Обычный, EOS XE, EOS XR. Давайте теперь поговорим более детально про операционную систему XR и попробуем выполнить первые лабораторные работы с ней. ИНТРИГУЮЩАЯ МУЗЫКА