Как стать автором
Обновить

Комментарии 50

Интересно, что слово Fabric, которое часто в русской литературе переводят как «Фабрика», в данном случае больше соответствует слову «ткань», «остов», «каркас» — как полносвязная структура.
Представьте себе плетение ткани и сравните с картинкой в статье :)
Фраза «на 76-й циске ткань слишком загружена» звучала бы диковато.
Если честно я так и не понял какую плату мне выбрать.
Уже не говоря про DFC, разные RSP и почему их можно/нужно две, зачем ES/SIP-платы и т.д.

П.С.: у меня были платы с DFC: в масштабах ISP/DC, где объем трафика велик, а еще надо NetFlow собирать — без DFC никак.
На самом деле не все так трудно, особенно, если вы опишите, что именно хотите.

ES-карты — карты с оптическими интерфейсами формфактора XFP, SFP+
SIP-карты — карты с кучей разных интерфейсов. Нпапример, Вам надо карточку, на которой сразу был интерфейс STM-4 и ATM.
RSP можно ставить две для резервирования головы, выбрать их можно попробовав посмотреть на cisco feature navigatore.
Ну а уж DFC — Вам должно быть виднее, что вы хотите. У нас 10GE платы стоят с DFC.
ES-карты — карты с оптическими интерфейсами формфактора XFP, SFP+
SIP-карты — карты с кучей разных интерфейсов.


Для вас реально эти карты характеризуются только этим или вы над нами тонко прикалываетесь?
У нас их не пользовали. Я просто посмотрел на картинки.
Без комментариев.
Задам наводящий вопрос — есть 7600, надо сделать VPLS в сторону клиента, какую карту надо купить?
Не хочу обидеть, но вам не стоило писать эту статью, ибо вы в ней ничего не понимаете.

ES — расширенные ethrenet-сервисы
SIP — IP-сервисы.
Это очень кратко, остальное популярно расписано на cisco.com, могу найти вам пруф.
Н-р если используется EoMPLS и приходится делать xconnect либо на SVI, либо к множеству сабов, то либо приходится колхозить, либо иметь эти (эту плату) и т.п. Буквально сегодня вперся в то, что на 7600 L2TPv3 может быть только с SIP-400.

DFC не увеличивает кол-во портов (в вашей статье), она позволяет «сменить политику хождения трафика» для снижения нагрузки на фабрику и т.п.

От статьи я ожидал увидеть н-р почему не стоит покупать 4-ехпортовую 10G-плату, а лучше купить восьми и выключить 4 из них, зачем нужно 2 управляющих модуля (ISSU) ну и т.п. «фишечки»
Только начал в этом разбираться, и сделал некоторый обзор для таких же, как я. Зачем ждать от обзорной статьи чего-то большего, чем обзор.
Как хотите, но в статье масса ошибок и еще больше не рассмотренного.
В 2012 году мне региональный менеджер Cisco сказала что 7600 в 2013 станет EoL, так что даже не перспективная статья :) 6500 останется, но мы же все знаем разницу между роутером и L3-коммутатором? ;)
Сколько различий сумеете назвать между 6500 и 7600, если считать, что можно под каждый брать любые модули?
Sup2T уже и VPLS с IRB держит нативно…
1. MPLS-фичи, но в свете " Sup2T уже и VPLS с IRB держит нативно… " могу усомниться, что отличия остались
2. Не все платы 7600 «лезут» в 6500 (поискать какие, по памяти не скажу?)
3. CatOS :)
1. Более того — вроде 7600 такого не может нативно. Или ошибаюсь?
2. Не все платы 6500 лезут в 7600. А под 6500 тоже есть SIPы…
3. У кого? У 6500 давно не CatOS. Лет 10 как, а то и больше.
1. С модулями может :)
2. Да, в обратную сторону правило тоже верно.
3. Там смайлик был, не новость так-то…
1. То есть свитч может A-VPLS на родных линейных картах без всяких умных SIPов, а роутер — ни в какую. Забавно.

«мы же все знаем разницу между роутером и L3-коммутатором?»
Я вот смотрю на те самые 6500 и 7600, и не знаю :)
Я тут писал что 7600 сворачивают, вместо нее позиционирует ASR-серию, что логично. Возможно или даже наверняка это связано. Я имею ввиду то, что 6500 развивают как-то, а 7600 доживает свои дни. Примерно так мне и рассказывали в полуприватной беседе…
ASR — штука хорошая. Что 9k, что 1k.
На самом деле, я вижу планомерный отказ от классического IOS. Для операторов предлагают те самые ASR 9k с IOS XR. Для ЦОДов есть нексусы с NX-OS. Для кампусных сетей — да, пока еще есть шеститонник, но cat4500 уже обзавелся IOS XE, и новая линейка свитчей с фиксированной конфигурацией (cat3850) будет на нем же. Под корпоративный internet edge и терминацию VPN — ASR1k с IOS XE вместо застреленного 7200.
То есть на IOS остались фактически только бюджетные ISR и тот самый шеститонник. Который, кстати, обещают очень сильно развивать в обозримом будущем, включая некоторый весьма офигительный функционал, опробованный на нексусах (инфа 100%, но детальнее говорить не буду). Правда, шансы увидеть на нем TRILL (aka fabricpath) или OTV близки к нулю (несмотря на наличие полной аппаратной поддержки, и это даже в роадмапах год-два назад мелькало, но пока передумали, гады).
Ничего ответить не могу: ASR-ов у меня не было, Nexus вроде обещали, но пока всё мутно :(
почему не стоит покупать 4-ехпортовую 10G-плату, а лучше купить восьми и выключить 4 из них
Да, Janus он такой, нехороший. Superman, Tycho, меня сейчас на слезу пробьёт))
Сейчас используется два основных типа этих плат: Supervisor 720 и Supervisor 32. Первый Cisco рекомендует использовать в ядре сети, второй же на пограничных узлах.
Не, я, конечно всё понимаю, но…
Какого года статья?
Где SUP 2T (применительно к 6500)?
Где можно увидеть разницу между CFC и DFC?
Где нюанс 7613, связанный с ёмкостью бэкплэйна в разных слотах при использовании SUP720/RSP720?

бывает 7603, 7606, 7609, 7613.
Ещё 7604 есть.
1)2013
2)SUP 2T не знал
3)CFC и DFC можно почитать по ссылке в конце статьи. Если бы я стал описывать это, статья была бы не ознакомительной.
4)Если вы расскажите, про что это, буду весьма признателен.
5)сейчас поправлю
1) Вы видели хотя бы раз SUP32 в 7600, купленном в последние несколько лет?
2) cisco.com.
3) Ок, засчитано.
4) 40Gbps с фабрикой умеют только слоты с 9 по 13. Соответственно, при необходимости иметь полнодуплексные 40Gbps на лайнкарте, её надобно пихать только в упомянутые слоты. Есть карты, требующие 40Gbps до фабрики, такие просто не заработают в других слотах.
5) cisco.com.
Я все прекрасно понимаю, что все есть на cisco.com. Ну а 40GE пользовать не приходилось. Из 76-й серии есть только 7609 b 7606.
Имелась ввиду скорость доступа до шины: 2х20Gbps
2)Кстати, 720 (не 10G) и 32 уже EOS :)
3) Фишка DFC в том, что не надо передавать на суп заголовки пакетов, карта имеет полную реплику таблицы CEF и сама способна принимать решения, сразу отправляя пакет целиком в нужную сторону.
на 6500 нет ничего лучше VSS :)
Если VSS ни разу вас не подводил — значит, вы недостаточно долго им пользовались :)
В нексусах циска наконец-то отказалась от ущербной концепции «один мозг на двоих».
думаю sh ver скажет сам всё за себя :)

cs6509-1 uptime is 4 years, 15 weeks, 2 days, 1 hour, 57 minutes
Uptime for this control processor is 1 year, 14 weeks, 5 days, 21 hours, 23 minutes
Не… По этому выводу непонятно, VSS там или просто пара супов в SSO… Вы лучше сделайте show switch virtual link, ну и текущую версию IOS…
У меня тоже есть:

6509# uptime is 1 year, 15 weeks, 4 days, 22 hours, 10 minutes
Uptime for this control processor is 1 year, 10 weeks, 2 days, 17 hours, 11 minutes

6509#show switch virtual link
VSL Status: UP
VSL Uptime: 1 year, 10 weeks, 2 days, 17 hours, 5 minutes

И я реально не верю, что оно аж целый год не глючило — SXI8 хороший софт :)

Радует, что вскоре quad-sup станет человеческим, с полностью прогруженными 4-мя супами.
VSL Status: UP
VSL Uptime: 1 year, 14 weeks, 5 days, 21 hours, 9 minutes

s72033-adventerprisek9_wan-mz.122-33.SXI7
ISSU? Помню первую попытку: все 4 супа попадали как доминошки после loadversion, причем 3 из них пришлось через консоль вытаскивать. И в процессе этого фейла я не допустил ошибок. Слава яйцам кластер был тестовый. Повторить факап на заказ не удалось ни мне, ни TACу. Собственно, это был первый из длинного списка былинный отказ VSS на моей практике.
В каждом каталисте по одному VS-S720-10G
И такая пара шасси у нас есть. Вроде всего один раз ломалась целиком (а не было бы VSS — одно из шасси выжило бы, и факап никто бы не заметил).

В-общем, я предпочитаю не использовать VSS там, где нельзя рядом поставить еще один такой же VSS с полным резервированием.
Это я намекнул что об ISSU не может идти и речи :)
Не совсем…
www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/vss.html#wp1169499
Само собой, при любом апдейте VSS каждое из шасси хоть так, хоть эдак упадет, но при правильном дизайне control plane останется на месте, ни одно соседство не упадет.
Кстати, вот еще недостаток VSS. Если в одно шасси вставить два супа, то, во-первых, при апдейте порты ложатся на куда меньшее время (если вообще ложатся), а во-вторых, любого рода фейловер автоматически подразумевает полный перезапуск одного из шасси. На данный момент при VSS полностью прогружается только по одному супу на шасси, а если вставить второе — оно будет лишь cold standby, готовое через несколько минут после падения основного возобновить работу шасси, но ребут в любом случае случится.
Хотя честно скажу, я ни разу не пробовал ISSU кроме как того несчастного случая: апдейты как правило делаются мажорные, и надежнее бывает согласовать даунтайм железки и обновление методом reload. Даже TAC рекомендует по возможности делать именно так.
Для себя запомнил кратко:
PFC — for switching and QoS
MSFC — for routing.

DFC — набор MSFC+PFC
CFC — пустышка. Если стоит CFC, то весь свичинг делается на супервизоре.

Если не прав, поправьте.
Что-то уж больно коротко 8) Половина топика — две большие картинки, одна из которых не несёт информации по теме.
Позволю себе добавить еще одну ссылочку на материал. Последние две картинки информативно показывают разницу между Centralized Forwarding и Distributed Forwarding.

www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd80673385.html
быть может вы знаете, как устроена программная часть этих коммутаторов? есть же там какая-то ОС, софт какой-то? я так понимаю, что всё закрыто от посторонних, но может все-таки какая-то информация проскакивала?
Нда…

Информации об устройстве IOS, IOS-XE, IOS-XR, SAN-OS, NX-OS и т.д. (как самих ОС, так и их подсистем) очень даже полно. Базовое понимание дается в рамках курса CCNA, за который даже платить не обязательно.

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

Какого рода интеграция и с какой целью?
мы реализуем софт на базе ICAP. Сейчас это отдельный nix-сервер с установленной программой. Что, естественно, не позволяет достичь должной производительности.

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

Я также догадываюсь, что работа коммутатора с пакетами на седьмом уровне модели OSI вместо второго-третьего мерьезно снизит производительность железки, но все равно надо пробовать.

Я не уверен, пойдет ли производитель на то, чтобы допустить нас к телу. Скорее всего нет. А вот если будет готовый работающий софт — тогда разговор может пойти проще. Как-то так.
В идеале было бы неплохо перенести этот код в программную часть коммутатора.

Вы же понимаете, что когда речь идет об анализе пакетов выше L4 (именно ваш случай), то даже мой мобильник будет мощнее 7600-го, как и практически любого другого коммутатора, за исключением совсем недавних супов?

Но есть WCCP, который способен перенаправлять часть трафика на сервера.
т.е. 7600 (а именно такие стоят у провайдера) заворачивают весь (и только) HTTP траффик к нам на сервер, а сервер возвращает его уже измененный обратно к 7600.

правильно ли я понял схему?
Да. В качестве одного из вариантов. Под это (передача HTTP на устройство, в том числе способное кешировать трафик) специально заточен протокол WCCP. Опять же, документации полно, изучайте.

Реализовывать какую-то продвинутую обработку на свитче, особенно в условиях «ресурсов сервера не хватает» — заведомо безнадежная идея, даже не рассматривайте ее.
Большое спасибо, сейчас будем разбираться с мануалами.

Такой еще вопрос — какую примерно долю в общем трафиике занимает HTPP-траффик для сферического пользователя в вакууме?
Понятия не имею.
Для сферического провайдера в вакууме объём HTTP-трафика на вход составляет 40-60% от суммарного. Из этого объёма более половины — потоковое видео.
Из личного опыта.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории