Комментарии 87
1. Я так понимаю, это Brocade?
2. В общем-то статья ниочем, увы :( Это не обзор железки, с другой стороны — это не принциальный разбор современного маршрутизатора, с блок-схемами, разбором подситем свитчинга и маршрутизации. В общем-с, плохо
2. В общем-то статья ниочем, увы :( Это не обзор железки, с другой стороны — это не принциальный разбор современного маршрутизатора, с блок-схемами, разбором подситем свитчинга и маршрутизации. В общем-с, плохо
во-первых, это не "«роутер»". Это маршрутизатор.
во-вторых, L3 там куцое донельзя, об этом говорит хотя бы размер RIB: в 128к префиксов даже 1FV не влезет. Чисто OSPF гонять, не более того.
в-третьих, даже L2-функционал у него не самый большой для ядра: не умеет балансировку по L4 в lacp, а IGMP Snooping групп всего 256! Это вообще бред — на сети провайдера их порядка нескольких сотен (в лучшем случае) — на каждого клиента задействуется пара src ip-мультикаст группа. Конечно, есть способы сократить их количество (заменяя src ip на коммутаторе доступа), но это сильно поднимает трафик (особенно если делать это на агрегации).
как добивающий агрумент: в спецификации не указан даже размер таблицы мак-адресов! Зато перечисление отдельными пунктами ipv4 telnet и ipv6 telnet есть обязательно.
вердикт: мне кажется, что основное применение этой железяки — агрегация в ДЦ без особых изысков, просто коммутировать виланы. И ни в коем случае не ставить ее в качестве L3.
З.З.Ы. юзаем серверы Etegro, так вот многие компоненты от них совершенно идентичны тем, что на фотках :) Блоки питания и радиаторы для процессоров точно.
во-вторых, L3 там куцое донельзя, об этом говорит хотя бы размер RIB: в 128к префиксов даже 1FV не влезет. Чисто OSPF гонять, не более того.
в-третьих, даже L2-функционал у него не самый большой для ядра: не умеет балансировку по L4 в lacp, а IGMP Snooping групп всего 256! Это вообще бред — на сети провайдера их порядка нескольких сотен (в лучшем случае) — на каждого клиента задействуется пара src ip-мультикаст группа. Конечно, есть способы сократить их количество (заменяя src ip на коммутаторе доступа), но это сильно поднимает трафик (особенно если делать это на агрегации).
как добивающий агрумент: в спецификации не указан даже размер таблицы мак-адресов! Зато перечисление отдельными пунктами ipv4 telnet и ipv6 telnet есть обязательно.
вердикт: мне кажется, что основное применение этой железяки — агрегация в ДЦ без особых изысков, просто коммутировать виланы. И ни в коем случае не ставить ее в качестве L3.
З.З.Ы. юзаем серверы Etegro, так вот многие компоненты от них совершенно идентичны тем, что на фотках :) Блоки питания и радиаторы для процессоров точно.
Основное применение — вычислительные кластеры, я бы сказал. Поставить такую штучку под 47 машин с Hive — ой-ёй!
1376 ядер сцепленных по 10G — это очень и очень круто.
1376 ядер сцепленных по 10G — это очень и очень круто.
А сдюжит нагрузку?
сетевой стек системы не вытащит (ну, т.е. его программно-аппаратная часть). Насколько мне известно, максимальная производительность сетевой карты, которую выжимали в freebsd (в линуксе даже этого нет, увы) — порядка 5,5 гигабит/сек.
такие вещи обычно реализуются при помощи infiniband.
такие вещи обычно реализуются при помощи infiniband.
В линуксе выжимали 10G. Год назад на nag-е была статья.
На синтетике с multipath и 50Gbps выжимали.
на нетюненной вообще intel 82599eb на синтетике сразу выжал 8.8 гбит. ЧЯДНТ?
5,5 гигабит получалось на 10Г карточках первых поколений.
Сейчас 9.6-9.8 на наших дочках получаем.
Сейчас 9.6-9.8 на наших дочках получаем.
Да и вообще в стойки где это стоит вместо свича можно селить очень интересные вещи.
елки, писалось в 3 часа ночи, поэтому я оговорился. Это, конечно же, коммутатор :)
основное применение этой железяки
мы используем 10G для бэкапов
вообще-то это коммутатор 3 уровня.
да, у него есть зачатки роутинга, но в первую очередь это коммутатор.
да, у него есть зачатки роутинга, но в первую очередь это коммутатор.
Указан, мак таблица — 128К записей.
Вы правы, основная цель дизайна — аггрегация в ДЦ.
Сейчас в процессе обновления линейки, новые модели еще более ориентированы на ДЦ и виртуальные среды.
ЗЫ унификация, унификация и еще раз унификация!
Вы правы, основная цель дизайна — аггрегация в ДЦ.
Сейчас в процессе обновления линейки, новые модели еще более ориентированы на ДЦ и виртуальные среды.
ЗЫ унификация, унификация и еще раз унификация!
Хотелось бы обзора возможностей, нагрузочного тестирования и т.д. А так… рад что вы умеете фотографировать. Даже цену не указали.
450 000р мне тоже интересно стало, нашел конфигуратор
Честно говоря рассчитывал на ценник погуманнее.
А так Brocade 6650 в сравнимой конфигурации стоит не сильно дороже (если поставщика прогнуть, а это нормальная практика), транссиверы Brocade — тоже стоят сравнимо с ETegro. Но там будет более гибкое и более функциональное решение. За не сильно бОльшие деньги.
А так Brocade 6650 в сравнимой конфигурации стоит не сильно дороже (если поставщика прогнуть, а это нормальная практика), транссиверы Brocade — тоже стоят сравнимо с ETegro. Но там будет более гибкое и более функциональное решение. За не сильно бОльшие деньги.
проще уже взять extreme x670.
там, конечно, своих тараканов полно, но L3 там вполне рабочий.
там, конечно, своих тараканов полно, но L3 там вполне рабочий.
Ну вот тут хз, если честно, Extreme даже вблизи не видел.
Я вот хотел еще написать, что еще можно взять несколько, господи прости, DXS-3600, но потом глянул ценник, и честно говоря ужаснулся. 14 килобаксов за D-Link, в моей голове не укладывается никак.
Я вот хотел еще написать, что еще можно взять несколько, господи прости, DXS-3600, но потом глянул ценник, и честно говоря ужаснулся. 14 килобаксов за D-Link, в моей голове не укладывается никак.
у нас стоят — вполне нормально железо, хотя и не без глюков.
для L2 так вообще песня.
для L2 так вообще песня.
Ещё есть Dell PowerConnect 8100, он тоже недорогой.
Вы сравниваете розницу с «если поставщика прогнуть»?
Зря :)
Кстати, скоро будет обновление — 40 гигабит в массы!
Зря :)
Кстати, скоро будет обновление — 40 гигабит в массы!
Да фигли, извините, там обзора-то.
Обычный русско-китайский свитч. Ну L3. Ну 10G. Все равно русско-китайский свитч.
Обычный русско-китайский свитч. Ну L3. Ну 10G. Все равно русско-китайский свитч.
А что пишется на флешку? Лог чего? И для кого, с учетом недоступности без разбирания?
Это коммутатор, поэтому пишется лог коммутатора.
Включился порт, поднялся STP, сработал какой-нибудь trap, сдох OSPF-сосед — да мало ли.
Включился порт, поднялся STP, сработал какой-нибудь trap, сдох OSPF-сосед — да мало ли.
Если быть до конца честным, то CF (CardFlash) в данном случае используется, для хранения образа (или нескольких) ОС. Т.е. по сути это жесткий диск компьютера, на котором файл логов это всего лишь один из немногих файлов. На рисунке ниже видно примерно каким образом разбивается такой диск на коммутаторах серии Summit от Extreme Networks
А программируемая FPGA матрица (та которая 32Мb) хранит, в том числе, образ загрузчика операционной системы т.н. BootRom
А программируемая FPGA матрица (та которая 32Мb) хранит, в том числе, образ загрузчика операционной системы т.н. BootRom
Там же вроде не твердотельные конденсаторы?
Тупая пакетодробилка, полноценного L3 нет и близко, как расширение количества портов более мощной железки использовать можно, но тогда почему нет хотя-бы функциональной возможности установить пару портов 40G или 100G. Странная железка, применение в таком формате очень под вопросом, хотя может у крупных провайдеров и приживется транки гонять.
48 портов по 10G — это 480Гбит трафика. Маркетинговые 960 засуньте поглубже тем кто их придумал.
Full-duplex — это не миф, а реальность.
Скорее всего имелось с виду то, что сам свич данные не генерирует и реальная пропускная способность действительно 480Гбит, объясню на примере 2х портов, предположим в порт 1 приходит 10Г трафика и они же уходят с порта 2, на порт 2 приходит 10Г трафика и они уходят с порта 1 (Обычный транк). Как считают маркетологи? 10+10+10+10=Ура 40 гигабит на фулдуплексе. Как считают сетевики? 10Г через свич в одну сторону, 10Г через свич в другую сторону итого 20Г — это просто разные подходы к подсчету не более.
Это не подходы к подсчету, а желание нае^Wвпарить. Если я с 1000 рублей зашел в комнату через одну дверь и вышел через другую, то у меня их стало 2?
Я с Вами абсолютно согласен, просто те, кто от сетей чуть дальше чем полностью не понимают этого нюанса, попробовал объяснить на пальцах.
Вы горячны и безаппеляционны, это редко когда сочетается с глубокими знаниями.
А теперь представьте, что одновременно в две двери входят два человека с ворохом разных денег, а в комнате сидит бухгалтер, который должен принять выручку у них обеих, персчитать, разложить по порядку, учесть, и выдать им эти деьги в качестве зарплаты, после чего они выходят в другие двери.
«Пропускная сопобность» в данном случае — расторопность и скорость работы этого бухгалтера-процесора.
А теперь представьте, что одновременно в две двери входят два человека с ворохом разных денег, а в комнате сидит бухгалтер, который должен принять выручку у них обеих, персчитать, разложить по порядку, учесть, и выдать им эти деьги в качестве зарплаты, после чего они выходят в другие двери.
«Пропускная сопобность» в данном случае — расторопность и скорость работы этого бухгалтера-процесора.
Да и маркетологи их посчитают как 4 человека они ведь вошли в 1 дверь, а вышли в другую. Ну как же 2 человека вошло и 2 вышло, итого 4 — так?
Только вот Бухгалтер сделал 2 операции на каждого — принял документы и отдал деньги, так что хоть и пришло 2 человека, но информационных единиц через бухгалтера прошло 4.
Опять же как считать, бухгалтер обслужил 2х человек, а не 4х. В самом идеальном варианте через свич нельзя передать более 480Гбит трафика и именно эта цифра будет фигурировать в расчете архитектуры сети. Я лично спрашивал у представителей трех вендоров, почему пишут завышенный вдвое показатель. Ответ:«Все так делают, пользователь купит то, где цифра больше», то-есть чистый маркетинг.
Прекратите бредить. Никого не волнует сколько действий делает бухгалтер. Количество документов/денег от этого не увеличивается.
Допустим бухгалтер суперкрут и его скорость работы бесконечность. Но вот в дверь может войти 1 человек в час. Дверей таких 2. Сколько человек обслужит бухгалтер за 10 часов?
Допустим бухгалтер суперкрут и его скорость работы бесконечность. Но вот в дверь может войти 1 человек в час. Дверей таких 2. Сколько человек обслужит бухгалтер за 10 часов?
Хорошо. Забудем на время про существование неблокирующих коммутаторов и для простоты вспомним политику Store and Forward.
Что делает коммутатор, когда получает кадр? Он сохраняет его в память. Что делает коммутатор, когда отправляет кадр? Он читает его из памяти. Сколько данных проходит по шине памяти для передачи одного кадра? Правильно! Два, умножить на размер кадра. Какая пропускная способность памяти требуется? Правильно! Двойная, так как пропускную способность памяти не меряют в дуплексе.
Вернемся к неблокирующим коммутаторам. Нам нужно 10Г на нее подать и 10Г с нее снять, следовательно с точки зрения внутрикомпьютерных принципов измерения скоростей нам требуется двойная пропускная способность.
Так что я все таки вынужден не согласиться с Вами и считать, что на обработку 10Г потока в одну сторону через два порта нам нужна матрица производительностью 20Г.
Что делает коммутатор, когда получает кадр? Он сохраняет его в память. Что делает коммутатор, когда отправляет кадр? Он читает его из памяти. Сколько данных проходит по шине памяти для передачи одного кадра? Правильно! Два, умножить на размер кадра. Какая пропускная способность памяти требуется? Правильно! Двойная, так как пропускную способность памяти не меряют в дуплексе.
Вернемся к неблокирующим коммутаторам. Нам нужно 10Г на нее подать и 10Г с нее снять, следовательно с точки зрения внутрикомпьютерных принципов измерения скоростей нам требуется двойная пропускная способность.
Так что я все таки вынужден не согласиться с Вами и считать, что на обработку 10Г потока в одну сторону через два порта нам нужна матрица производительностью 20Г.
Ваши рассуждения базируются на том, что есть память и скорость ее работы измеряется в симплексе. Все хорошо. Предположим завтра изобретут хитрую матрицу где памяти не будет (оптический свитч для примера)? И как быть дальше? Так что такой подход считаю ошибочным и ведущим к заблуждениям. Но если Вам больше нравится ваш подход — пусть так. Только не забывайте писать, что 960Т измерены в симплексе.
когда это будет «хитрая матрица» — тогда не будет «store and forward». Будет cut-through.
более того, тогда не будет механизма коммутации, это будет обычный повторитель а-ля хаб, потому что для того, чтобы распарсить mac-адрес, его необходимо прочитать.
более того, тогда не будет механизма коммутации, это будет обычный повторитель а-ля хаб, потому что для того, чтобы распарсить mac-адрес, его необходимо прочитать.
В cut-through стратегии мои рассуждения в принципе тоже справедливы, так как пропускную способность внутренних шин традиционно меряют в полудуплексе, так как они чаще полудуплексные.
Бывает коммутация не только по МАС адресам.
в случае коммутации пакетов нам в любом случае этот пакет нужно вскрыть, для того, чтобы определить, куда его там скоммутировать.
если все заранее определено и у нас коммутация каналов — тогда да, все проще.
но как-то оно с ethernet слегка не согласуется, не находите?
если все заранее определено и у нас коммутация каналов — тогда да, все проще.
но как-то оно с ethernet слегка не согласуется, не находите?
Матрица коммутации вскрытием пакетов не занимается. Исходящий интерфейс известен _до_ начала коммутации.
хм. Ну, возможно, я не совсем четко представляю себе механизм работы коммутации пакетов в современных коммутаторах (поправите меня, если я в чем-то неправ): в любом случае после выкусывания src/dst mac на входе (чем вполне могут заниматься asic'и) нам необходимо произвести lookup в таблице мак-адресов для того, чтобы определить выходной интерфейс для dst mac (ну или flood в случае, если dst mac в таблице нет).
вполне вероятно, что это не задача самой «матрицы коммутации» как таковой, но некоего аналога routing engine (из маршрутизатора).
но как бы то ни было, вычисления произвести надо и память будет нужна.
можно контрпример?
вполне вероятно, что это не задача самой «матрицы коммутации» как таковой, но некоего аналога routing engine (из маршрутизатора).
но как бы то ни было, вычисления произвести надо и память будет нужна.
можно контрпример?
Ну все так. Только лукап — это не матрица. Он может быть рядом, может быть в одной микросхеме, но это не матрица. В матрицу приезжает пакет с уже известным выходным интерфейсом и задача матрицы до этого интерфейса ее доставить. Будет ли внутри матрицы запись/чтение в память точно утверждать нельзя, варианты бывают всякие. Вариант с памятью просто наиболее дешевый и простой.
Когда изобретут матрицу работающую на совершенно иных принципах, то вполне нормально, что для нее потребуются другие принципы определения пропускной способности, а полностью оптическая матрица будет 100% работать на других принципах.
Мне как пользователю коммутатора нет дела до того, что происходит внутри коммутатора, как организована его работа.
Мне важно, чтобы коммутатор принял пакет в один порт и выплюнул его из другого порта, возможно — чуточку модифицировав. L2 форвардинг, L3 форвардинг — неважно.
Если у коммутатора 2 порта по 10G, то он сможет пропустить через себя лишь 20 гигабит трафика в секунду, 10 в одну сторону и 10 в другую.
Аналогия «входит в одну дверь и выходит через другую» абсолютно уместна.
Что до расторопности бухгалтера. Мы будем считать, что их много, всегда ровно столько, чтобы обслужить то число народа, которое сможет ввалиться в одну из дверей за единицу времени (так как речь про line-rate свитч). Разумеется, они могут работать медленно, так что среднее время обслуживания клиента составит час. В случае low-latency свитчей бухгалтеров меньше, и работают они со сверхчеловеческой скоростью, тратя по 30 секунд на клиента, клиенты довольны. Но в любом случае, они могут пропустить через себя только N клиентов за единицу времени. Расторопность бухгалтеров не влияет на количество клиентов, лишь на время ожидания (забудем, что RTT способно снизить скорость передачи данных по TCP при недостаточном окне).
Мне важно, чтобы коммутатор принял пакет в один порт и выплюнул его из другого порта, возможно — чуточку модифицировав. L2 форвардинг, L3 форвардинг — неважно.
Если у коммутатора 2 порта по 10G, то он сможет пропустить через себя лишь 20 гигабит трафика в секунду, 10 в одну сторону и 10 в другую.
Аналогия «входит в одну дверь и выходит через другую» абсолютно уместна.
Что до расторопности бухгалтера. Мы будем считать, что их много, всегда ровно столько, чтобы обслужить то число народа, которое сможет ввалиться в одну из дверей за единицу времени (так как речь про line-rate свитч). Разумеется, они могут работать медленно, так что среднее время обслуживания клиента составит час. В случае low-latency свитчей бухгалтеров меньше, и работают они со сверхчеловеческой скоростью, тратя по 30 секунд на клиента, клиенты довольны. Но в любом случае, они могут пропустить через себя только N клиентов за единицу времени. Расторопность бухгалтеров не влияет на количество клиентов, лишь на время ожидания (забудем, что RTT способно снизить скорость передачи данных по TCP при недостаточном окне).
Вы плохо разбираетесь в том, как происходит работа коммутатора на самом деле. Отсюда ваша ошибка.
Никакой ошибки нет.
Еще раз: да, я знаю, как устроена работа коммутатора, но мне как пользователю нет дела до этого. Я отправляю пакет в один порт и получаю его из другого порта. Генерируемым самим коммутатором трафиком можно пренебречь. Суммарно коммутатор пропускает через себя столько трафика, сколько каждый порт может принять в одну сторону (для простоты смотрим только ethernet).
Вам же маркетологи запудрили мозги, и вы забываете про само назначение сетевого устройства, излишне зациклившись на его архитектуре. От этого и взаимное непонимание.
Есть ли возражения по поводу «свитч с двумя 10G портами никак не прокачает сквозь себя более 20гб/с данных»?
Еще раз: да, я знаю, как устроена работа коммутатора, но мне как пользователю нет дела до этого. Я отправляю пакет в один порт и получаю его из другого порта. Генерируемым самим коммутатором трафиком можно пренебречь. Суммарно коммутатор пропускает через себя столько трафика, сколько каждый порт может принять в одну сторону (для простоты смотрим только ethernet).
Вам же маркетологи запудрили мозги, и вы забываете про само назначение сетевого устройства, излишне зациклившись на его архитектуре. От этого и взаимное непонимание.
Есть ли возражения по поводу «свитч с двумя 10G портами никак не прокачает сквозь себя более 20гб/с данных»?
Вам же маркетологи запудрили мозги
Спасибо вам за то, что вы ведете дискуссию в вежливом, взвешенном тоне, избегая оскорблений и навешиваний ярлыков.
Вы плохо разбираетесь
Вы горячны и безаппеляционны, это редко когда сочетается с глубокими знаниями.
Что там про мычащую корову говорилось? Lite-версия вашего собственного оскорбления вывела вас из себя. Соответственно, ваши знания, исходя из ваших же критериев, близки к нулю :)
Есть еще одна маленькая проблема. Вам нечего ответить по существу, и поэтому вы сходу переключаетесь на личности. Жаль.
навеяло ситуацию с машинами
— некоторым пользовательницам нет дела до того как работает машина, но они знают что если залить топливо и нажимать на педали — то она будет ехать ;)
— некоторым пользовательницам нет дела до того как работает машина, но они знают что если залить топливо и нажимать на педали — то она будет ехать ;)
Простое знание владельцем всех шестеренок автомобиля плюс наличие к него исходников управляющего инжектором кода как-то влияет на скоростные характеристики автомобиля? Нет? Тогда к чему этот пример?
Любой человек, работающий с сетевым железом, обязан знать архитектуру этого железа, ибо эти данные сильно помогут как при выборе железа, так и при траблшутинге. Однако, помимо этого любой сетевик обязан обладать собственным мозгом, а желательно и изредка включать его, иначе он, как некоторые отписавшиеся выше товарищи, рискует не заметить лес за деревьями.
Любой человек, работающий с сетевым железом, обязан знать архитектуру этого железа, ибо эти данные сильно помогут как при выборе железа, так и при траблшутинге. Однако, помимо этого любой сетевик обязан обладать собственным мозгом, а желательно и изредка включать его, иначе он, как некоторые отписавшиеся выше товарищи, рискует не заметить лес за деревьями.
Включите мозги. Каждый пакет проходит 2 порта.
Блин, не туда ответил.
Хм. А питание как всегда только 220 или 12 вольт? Ох не любят производители операторов связи с их гарантированным питанием 48/60В.
Сколько 10G коммутаторов не использовал — ни разу не интересовался, что там внутри. Максимум — в какую сторону вентиляторы дуют.
Потому что для коммутатора все эти игрушки в «ой, а вот тут вот блестящий разъёмчик», «а вот тут офигительная ребристая чёрная штучка», " а вот тут вот много интересных параллельных линий" никаким образом не влияют на работу.
А влияют на работу всякие тонкие нюансы, вроде поддержки современных стандартов (EVB), умение адеватно реагировать на неадекватные ситуации, нормальная работа с Jumbo, большая таблица ARP, вменяемая командная строка (желательно, классом выше, чем цисковый ужас).
Потому что для коммутатора все эти игрушки в «ой, а вот тут вот блестящий разъёмчик», «а вот тут офигительная ребристая чёрная штучка», " а вот тут вот много интересных параллельных линий" никаким образом не влияют на работу.
А влияют на работу всякие тонкие нюансы, вроде поддержки современных стандартов (EVB), умение адеватно реагировать на неадекватные ситуации, нормальная работа с Jumbo, большая таблица ARP, вменяемая командная строка (желательно, классом выше, чем цисковый ужас).
Можно поподробнее про цисковый ужас? до жути интересно где cli вменяемее.
Если ответ будет «Juniper» предвещаю холивар! :)
п.с.: Сам ничего логичнее циски не встречал. Самые яркие лучи испускал на свитчи хуавей.
п.с.: Сам ничего логичнее циски не встречал. Самые яркие лучи испускал на свитчи хуавей.
Показываю цисковый ужас:
conf t
int F0/0
ip access-list BAN-IN in
ip access-list BAN-OUT out
ip acce e BAN-IN
Write failed: Broken pipe
Коммиты изменений — часть интерфейса cli.
conf t
int F0/0
ip access-list BAN-IN in
ip access-list BAN-OUT out
ip acce e BAN-IN
Write failed: Broken pipe
Коммиты изменений — часть интерфейса cli.
Ну видимо вы давно не работали с настоящим ужасом. Понимаю к хорошему привыкаешь быстро. Поэтому кажется что это не нормально, поэтому у цыски все более менее в рамках нормального, но не без своих изъянов.
Я честно говоря не очень понял в чем проблема в том что вы указали как и про коммиты изменений.
Я честно говоря не очень понял в чем проблема в том что вы указали как и про коммиты изменений.
Проблема в том, что на цисках нельзя делать транзакции конфигов, то есть помимо «офигенный конфиг» нужно ещё думать «ничего не сломать в середине». Это фатальная проблема, и чем конфиг крупнее, тем хуже.
Вторая проблема — отсутствие диффов. (да-да, я про прелесть джуниперовского интерфейса).
Я видел более ужасные конфиги (включая и 3com, и allied telesyn), но речь-то о том, что адекватная работа с оборудованием подразумевает адекватную среду для работы.
А тут — шаг влево, шаг в право (в процессе написания конфига!) и всё пропало.
Вторая претензия к циске — какая-то дикая уродливая легаси, торчащая из всех углов (те же no arp proxy).
Вторая проблема — отсутствие диффов. (да-да, я про прелесть джуниперовского интерфейса).
Я видел более ужасные конфиги (включая и 3com, и allied telesyn), но речь-то о том, что адекватная работа с оборудованием подразумевает адекватную среду для работы.
А тут — шаг влево, шаг в право (в процессе написания конфига!) и всё пропало.
Вторая претензия к циске — какая-то дикая уродливая легаси, торчащая из всех углов (те же no arp proxy).
эмм, на циско есть reload in 5 :)
ну и на новых что-то там есть, связанное именно с коммитами, тарщ freefd рассказывал, кажыся.
ну и на новых что-то там есть, связанное именно с коммитами, тарщ freefd рассказывал, кажыся.
А ну в смысле чтобы работать не на живую, а на файл а потом применять уже его, это да не очень удобно. Для таких случаев есть «reload in» ну или «configure revert timer», луче чем ничего все же.
Дифы есть начиная с 12.4М если память не изменяет.
show archive config differences nvram:startup-config system:running-config
Легаси, да согласен arp-proxy хороший пример, хотя они сейчас начиная с 15.0 начали лучше подчищать дефалты. В IOS XE с этим получше ибо большинство функционала заново писалось.
Дифы есть начиная с 12.4М если память не изменяет.
show archive config differences nvram:startup-config system:running-config
Легаси, да согласен arp-proxy хороший пример, хотя они сейчас начиная с 15.0 начали лучше подчищать дефалты. В IOS XE с этим получше ибо большинство функционала заново писалось.
на цисках нельзя делать транзакции конфигов
Да хотя бы классический copy tftp run. На случай, если потребуется ввести N команд, из которых N-1'я сломает связь, а N'ная восстановит.
Однако, да, предварительной проверки синтаксиса в IOS не будет, ошибаться нельзя. К счастью, есть роллбэк, который можно запрограммировать через 1 минуту. Не reload, а именно роллбэк, добивающий команды до полного соответствия startup-config. По диффам.
Но у циски есть не только IOS, действительно безнадежно устаревший :) Есть NX-OS, в котором имеются те самые коммиты и много чего другого вкусного. Есть и IOS-XR, еще более радикально улучшенный в лучшую сторону.
Помимо данных элементов на материнской плате распаян разъем с модулем на 512 мегабайт оперативной памяти (используется ноутбучный формат SO-DIMM), которая обеспечивает хранение таблицы маршрутизации (до 129 тысяч строк, то есть по 2600+ записей для каждого порта, если делить поровну)
Скорее всего автор не знаком с архитектурой сетевых устройств, так как в коммутаторах таблица префиксов IP, FDB, mcast групп хранится непосредственно в ASIC, где под это выделена ТСАМ память. При этом, так как реализация такой памяти является достаточно дорогостоящим удовольствием, то все данные перед помещением в саму таблицу хешируются. Часть оперативки также может задействоваться под хранение маршрутов, но нужно понимать что шина между data plane (ASIC) и Control plane (CPU) имеет ограниченную пропускную способность (как правило это шина PCIe) и много траффика в этом случае не пропустишь. Основное предназначение оперативки это непосредственная работа самой ОС.
Скорее всего автор не знаком с архитектурой сетевых устройств, так как в коммутаторах таблица префиксов IP, FDB, mcast групп хранится непосредственно в ASIC, где под это выделена ТСАМ память. При этом, так как реализация такой памяти является достаточно дорогостоящим удовольствием, то все данные перед помещением в саму таблицу хешируются. Часть оперативки также может задействоваться под хранение маршрутов, но нужно понимать что шина между data plane (ASIC) и Control plane (CPU) имеет ограниченную пропускную способность (как правило это шина PCIe) и много траффика в этом случае не пропустишь. Основное предназначение оперативки это непосредственная работа самой ОС.
Часть оперативки также может задействоваться под хранение маршрутов
Так ведь и написано «память для RIB» :) Таблица маршрутизации по-любому будет в RAM. А вот таблица коммутации загружается на ASICи.
шина между data plane (ASIC) и Control plane (CPU) имеет ограниченную пропускную способность (как правило это шина PCIe) и много траффика в этом случае не пропустишь.
Дело даже не в шине, а в самом CPU. Он слишком слаб, чтобы пропускать через себя транзитный трафик. Несколько (десятков) мегабит может потянуть, но не более того.
Однако, дальше написана уж точно глупость:
до 129 тысяч строк, то есть по 2600+ записей для каждого порта, если делить поровну
Ну кто делит маршруты на количество портов?
ага, мы в нашей конторе сделали 10G сетку ;)
10G — в массы!
10G — в массы!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Внутренности 10G «роутера»