В данном случае речь идет в контексте «переподписка». Количество доступных портов без переподписки. Пять лет тому назад, со схожей тематикой, в Интернетах проскакивала хорошая статья (там, тема с radix достаточно хорошо раскрывалась), которая называлась — Facebook Fabric Networking Deconstructed — www.firstclassfunc.com/2014/11/facebook-fabric-networking-deconstructed
Слишком жирно набрасываете. Все о чем я там говорил, Yandex рассказал на NHOP в 2018 году, я об этом рассказывал на HighLoad в 2017 году. Удачи, Вам :)
Наличие большого количество резервных маршрутов + LSA Flooding внутри домена + сложность эксплуатации + масштабируемость. Если мои комментарии, доклад Дмитрия Афанасьева и RFC 7938 для Вас не авторитет, то рекомендую прочитать книгу автора Russ White — The Art of Network Architecture: Business-Driven Design, издательство Cisco Press (глава Clos and the Control Plane).
Опять же, это утверждение «Spine-Leaf Network Topology, то не забудьте упоминуть, что для этого очень желательно иметь железо Cisco Nexus» — тоже чушь.
И кстати, чтобы у тебя не было возможности зацепиться вот за это:
Домашнее задание — рассмотреть этот вопрос с точки зрения аппаратной реализации таких платформ, как — Cisco 7200 NPE-G2 (динозавр, который кстати до сих пор встречается), Cisco ASR 1000, Cisco Catalyst 6500 Sup720, Cisco Catalyst 6800 Sup2T и Cisco ASR 9000 RSP-440. Глядишь, ты откроешь для себя еще и дивный мир BGP PIC Edge/BGP PIC Core.
Разбор сделай не только с точки зрения производительности DRAM на RP vs TCAM на различных картах, но и всякие там интересные режимы аля cef и dcef.
Ух ты, ты сумел нагуглить правильное название для моего намека «загружающий лучшие маршруты в FIB» :)
Давай, я тебе процитирую, мой пост ранее от 16 сентября 2015 года, который написан был в 16:55:
Далее относительно программирования TCAM. TCAM программировать (читай сгружать маршруты в FIB) не всегда обязательно (и опять же это можно сконфигурировать) и зависит от кейсов, а вот сходимость это улучшает в разы. И чтобы ты понимал, речь идет о кейсах с BGP RR «с боку», который ни как не участвует в forwarding'е трафика (ибо by default для iBGP NHOP unchanged) и используется лишь для сигнализации маршрутной информации.
Расскажи еще нам про свои намеки спустя два дня, написанные 18 сентября 2015 в 14:34. Мы обязательно послушаем в очередной раз историю про лужу, про то как ты открываешь в очередной раз веб-сайт Cisco Live и какой ты молодец. Заодно не забудь нам рассказать про BGP FSM и выбор наилучшего маршрута.
Попробую объяснить на более простом примере. Ты утверждаешь, что если один из результатов работы OSPF (FIB) программируется в TCAM, то TCAM оффлоадит OSPF. Это — поразительное невежество.
Нет, я утверждаю другое (до сих пор, я тебе пытался тонко намекнуть, на толстые обстоятельства, но хочешь конкретики, пожалуйста). Я утверждаю, что ситуация с QFP не показатель, так как этот микропроцессор присутствует не во всех железках, и уж тем более эта история не про других производителей (например Juniper или Huawei). И уж тем более, это ну ни как не противоречит моим словам (от которых ты подпрыгиваешь с какашками в руках), цитирую (дословно):
Well it's depends. Призимлить 1000 BGP сессий на одну коробку, может быть не меньшим злом. Trade-in/trade-off. Многое зависит от железа
Я также утверждаю, что оперирование голыми цифрами по масштабируемости из спецификаций на оборудование без разбора конкретных ситуаций — слишком опрометчивое утверждение. Особенно без полного понимания того, как достигаются данные цифры, откуда они берутся и какие были условия во время тестирования. И главное, как это все коррелирует с таким понятиями, как скорость конвергенции и предъявляемые требования к сети.
Теперь, ты так у нас любишь вспоминать про FIB и особенно TCAM. Давай поговорим про TCAM. В чем основное отличие TCAM от DRAM на RP? Какую структуру имеет TCAM память, на каких операциях она выигрывает и за счет чего? Сколько занимает времени запись данных в ячейку памяти в случае с DRAM (которая к примеру стоит на RP2) и сколько в случае с TCAM? Это тебе к вопросу, почему BGP FIB Selective Download так эффективен и сколько времени занимает запись BGP Full View в TCAM на обычном пограничном маршрутизаторе.
Домашнее задание — рассмотреть этот вопрос с точки зрения аппаратной реализации таких платформ, как — Cisco 7200 NPE-G2 (динозавр, который кстати до сих пор встречается), Cisco ASR 1000, Cisco Catalyst 6500 Sup720, Cisco Catalyst 6800 Sup2T и Cisco ASR 9000 RSP-440. Глядишь, ты откроешь для себя еще и дивный мир BGP PIC Edge/BGP PIC Core.
Что самое интересное — эти два слова «IPSec» и «SA» ты узнал от меня чуть выше, когда я объяснял, что сценарий DMVPN не только IGP/BGP, там много чего другого происходит.
Нет, здесь интересно другое. Расскажи нам про аппаратную реализацию IPSec на других платформах, про то, как они работают с IPSec SA DB, как взаимодействуют с акселератором. И главное, ты нам расскажи, сколько будет сходиться вся эта конструкция на примере того же Cisco ASR 1000. Я тебе дам подсказку, когда я тестировал ASR 1000, в лаборатории, голый PPPoE, на заявленые значения в 48,000 сессий, это заняло около 16-18 минут. Спустя 6 лет, эта же операция занимает около 11-12 минут и это после серьезной оптимизации программной архитектуры Cisco IOS-XE (чего стоит один переход от 32 битной архитектуры, к 64 битной), увеличенного количества ядер на QFP и более производительного RP.
QFP — навороченный сетевой процессор. Он впечатляет своими возможностями,
Хорошо, что ты понимаешь, что QFP — это навороченный сетевой процессор, который впечатляет своими возможностями.
И плохо то, что ты не понимаешь, парадокса с примером аппаратной архитектуры на базе QFP процессора. Плохо, что ты не понимаешь, что система с QFP (например тот же Cisco ASR 1000) имеет достаточно размытые границы в части control-plane и forwarding-plane (которые размываются еще больше, по мере того, как разработчики допиливают софт и микрокод). Особенно, если рассматривать данные аспекты в сравнении с другими платформами. Потому что, если бы ты это понимал, то не хватался бы в очередной раз за «какашки» (кажется так ты говорил?), я тебе процитирую:
Всё еще печальнее — ты даже не различаешь понятия control plane и data plane.
Теперь перейдем к другой части твоего утверждения.
но обладает массой скрытых граблей в виде «фичи Х и Y можно использовать по отдельности и нельзя использовать вместе».Ну для примера: удачи реализовать per-tunnel qos на сабинтерфейсе портченнела. На сабинтерфейсе физического интерфейса — запросто. А еще я пользовался этими железками в те времена, когда не поддерживались object-group'ы в ACL. Угу, вот так вот печально всё иногда.
Я тебе могу рассказать про не менее интересные кейсы и нюансы на платформе Cisco Catalyst 6500 в конфигурациях с DFC и без DFC плат. И некоторые из них, могут иметь схожу проблематику вопроса. А чтобы понимать степень и глубину твоих познаний, задам несколько вопросов. Расскажи нам про нюансы, которые могут вылезать при распараллеливании задач, все ли задачи можно распараллелить и что подразумевает под собой термин «run to completion» (сможешь привести примеры?)?
То, что ты не умеешь искать информацию, не значит, что никто не умеет :) Вся глубокая информация имеется на Cisco Live.
Ну так найди нам на Cisco Live нужную презентацию, а потом расскажи, мы с удовольствием послушаем и посмотрим какой ты молодец. Про то, как QFP работает с аксселератором, как он работает с DB Flow кэшем, и как PPE обрабатывает пакеты. Детальнее того, что написано в том документе, о котором я говорил ранее.
А что еще ты не видишь смысла делать? Я думаю, что тут люди прекрасно видят, у кого тут вызывает эти картинки ступор и идет разрыв шаблона, и про tcp mss, и про peer-group'ы и про многое другое. Я тебе процитирую, как ты ответил на мой комментарий в самом начале:
А вот тут ощущается некоторое непонимание внутреннего устройства BGP и того, какими факторами определяется сходимость протокола. Еще тут ощущается непонимание того, что такое control plane. Нагрузка на него? Какого рода? Память? Процессор? Скажу по секрету, в типичном случае (хардварный роутер, full view) время перестроения топологии может не упираться ни в ресурсы control plane, ни в таймеры, хотя уже-не-особо-новые фичи более-менее исправляют это :)
Если люди пойдут по данной ссылке, они оценят. Ну да ладно, мы еще к этому вопросу вернемся.
А теперь ты опиши, какие именно задачи установления SA QFP оффлоадит с RP (простыми словами: RP больше не занимается теми задачами, их берет на себя QFP).
Я пока от тебя ничего не услышал, как говориться: «после вас». Тебя спросили, а ты начинаешь переводить стрелки. Тебе задали ряд наводящих вопросов, а именно — сможешь ли ты детально описать, как QFP взаимодействует с этим кэшем, как обрабатывает пакеты на PPE и как взаимодействует с аксселератором? Я уже молчу про «run to completion». Я тебе задам еще один наводящий вопрос — все ли ASIC и NPU умеют работать с таким кэшем, какой это дает эффект с точки зрения итоговой производительности и главное для чего реализовали данный функционал? На подумать, почему это разгружает CPU на RP и почему на Cisco ASR 1000 форвординг over tunnel идет без серьезного performance degradation with multiple features.
Так сразу видно, что ты за пределами лабы ничего никогда и не видел.
Ну в отличии от тебя, я и в лабе был (по обе стороны) и в реальности активно кручу гайки. Именно по этой причине до сих пор не верю «в розовые пони и единороги» и стараюсь сопоставить информацию, а не голословно утверждать, что ограничений нет и главное это BGP Scanner.
Я могу взять cat6500 с XL картами, потестировать на 100000 маршрутов, экстраполировать и внезапно обнаружить нерезиновость TCAM в реальном сценарии. Сколько месяцев назад был тот факап, когда кто-то нечаянно выплюнул в интернет агрегированные префиксы и число префиксов перевалило за 512k?
Рассказать про другие спецэффекты, связанные с изменением в Cisco IOS со стороны разработчиков относительно default behavior? Или быть может мне вспомнить про ситуации, в которых ломается IPC и коробка оживает только после cold restart'a (или ты думаешь такое встречается только у Juniper'а)? Я тебе могу еще рассказать про то, как на обычном Cisco Catalyst 6500, Supervisor может уйти в перезагрузку из-за ввода команды show ip helper или show interface такой-то transceiver detail, параллельно споткнуться об еще один баг и уложить частично forwarding на коробке после отработки всяких NSF/SSO.
Тестирования конкретных железок всегда проводят на конкретных, реальных примеров.
Не всегда и причин может быть множество. Например — маркетинг, которым ты тут размахиваешь во все стороны, утверждая, что это последняя инстанция. Для серьезных заказчиков, бывают делают и регрессивное тестирование, просто потому, что люди хотят понимать поведение коробки под серьезной нагрузкой и идентифицировать потенциальные узкие моменты в программной или аппаратной архитектуре оборудования, которое в свою очередь может накладывать ограничения на конкретный дизайн или сетевую архитектуру. Я уже молчу про регрессивное тестирование ближайших конкурентов, чтобы было потом чем «уколоть» конкурента во время тендера.
В случае DMVPN например каждый спок будет отдавать не 100 префиксов (это нереалистично), а один-два.
В случае с High Scale DMVPN есть не мало и других моментов, о которых я тебе напомню чуть ниже и в контексте hold-queue.
И даже PPS не зря тестируют на худо-бедно реалистичном IMIX трафике.
Чушь не надо пороть, ок? Тестируют не только на IMIX трафике, но и маленькими и большими пакетами. Ибо IMIX не покажет тебе наличие регрессии. Более того, понятие IMIX у каждого вендора может отличаться, я уже молчу про профиль трафика у конкретного заказчика. Например, у ivi.ru он один, у тебя другой, у меня другой, у оператора третий. Знаешь почему так происходит? Потому что бизнес решает разные задачи и набор приложений у всех разный. Так, что IMIX не показатель и скорее носит маркетинговый характер для непросвещенных.
Параллель понятна — что ты и STP не знаешь :) Несмотря на внешнее сходство результата их деятельности, MST по принципу работы не имеет ничего общего с классическим STP. А еще MST — открытый стандарт, ты его с RSTP спутал.
Нет, тебе не понятна. Дерево и в том и другом случае. У них общего, гораздо больше, чем ты себе судя по всему, можешь представить. Начиная от основополагающих принципов выбора root бриджа с некоторыми поправками, заканчивая BPDU сообщениями. И с RSTP я ничего не путал, поэтому гонор свой сбавь, ок? А то если мы сейчас начнем копать, то еще много чего интересного узнаем от тебя в стиле BGP FSM и выбор наилучшего маршрута.
Да, действительно интересно. Ты не в курсе даже следующих фактов:
Сейчас я тебе расскажу, кто не в курсе и каких факторов.
1) «Одновременно» — относительное понятие. Все прилетели в течение одной миллисекунды? Это не будет проблемой. Современные RP куда больше переварят на настолько низком уровне в стеке.
«А пацаны то и не в курсе» (читай 4000 споков), что им оказывается нужно слать пакеты медленнее, потому что так сказал некий JDima с хабрахабхр. Им оказывается еще нужно рассчитаться на первый, второй, третий и т.д., и ждать своей очереди прежде чем слать TCP ACK в сторону хаба и забыть про существование IPSec'а, а то вдруг RP обидеться или картина мира у JDima с хабрахабр не сойдется. Какие негодяи. Что за ущербная логика?
Так на секунду, в hold-queue могут попадать не только BGP пакеты. SPD был придуман не просто так. Далее, когда ты тут продолжаешь, что-то доказывать на тему — «посмотрите какие тут цифры и это все с IPSec и другими плюшками и очень круто живет с DMVPN», то упускаешь из виду очень важный момент, а именно — сколько времени эта конструкция будет взлетать.
2) Вообще-то hold-queue прекрасно правится на интерфейсах в любую сторону. Не замечал на хардварных платформах в конфиге интерфейса эту опцию? Вот-вот, оно и есть. Многие почему-то думают, что это размер очереди для data plane трафика, что неверно, те значения как правило либо фиксированные, либо изменяются крайне грубо. А фактическое значение этой очереди сильно зависит от конкретной платформы.
Ага замечал, более того, я не забыл тебе напомнить про hold-queue. И напомни, чего ты там говорил про оптимизацию и MTU? В каком контексте рассматривал проблематику MTU? И чего ты там сказал про мои слова, которые звучали так:
Открою секрет, что сходимость в BGP определяется не только процессом выбора лучшего маршрута или наличием/отсутствием всяких плюшек вида BGP PIC Edge/Core, но и BGP Finite State Machine (надеюсь этот термин знаком?). На процесс сходимости BGP влияет достаточно много аспектов от производительности CPU и конфигурации, до MTU и количества Adj-RIB-in/Adj-RIB-out.
Ничего такого не вспоминаешь? BGP Scanner ты наш.
Именно это я тебе и говорил. DMVPN — куда более сложный сценарий, чем ЦОДовая сеть.
А еще чего ты говорил?
Опиши, каким образом (холодный старт не рассматриваем, про это я уже говорил).
А чего это мы его не рассматриваем? Ты же сам говорил, процитирую:
Дам наводку на то, как узнать правильный ответ. Перечисли основные этапы сходимости (что конкретно происходит с процессом, когда что-то в сети меняется?) и заодно выясни, какие из них в типовой реализации происходят параллельно. Еще узнай, на что конкретно влияет добавление нового соседа (ты так и не сказал, что за ресурсы control plane тратятся, не говоря уже «на что тратятся»). Вдруг окажется, что всё не так плохо и число соседей само по себе почти никакого значения не имеет, только число событий в единицу времени, число различных примененных к ним политик и тому подобное?
Или ты думаешь у нас RR не может уйти в перезагрузку из-за бага или обслуживания, или hub имеет 100% uptime?
Сценарий — либо полноценный DMVPN, либо BGP без всех обвязок, как будет проще. Кажется, у тебя нет ни малейшего представления о том, чем определяется время поднятия соседства… Каким образом предыдущие N соседств (уже установленные, успокоившиеся, на полпроцентика иногда напрягающие RP кипалайвами) замедлят установление N+1-го?
Достаточно отлететь приличной части spok'ов, чтобы началось веселье. Например, упал BGP апстрим в Интернете или какой-нибудь Вася в очередной раз на границе с Финляндией решил вырыть траншею по глубже, чтобы враги не пролезли. Вполне себе реальный сценарий, который встречается давольно часто. Вот тебе про случай с Level 3:
Кажется, у тебя нет ни малейшего представления о том, чем определяется время поднятия соседства… Каким образом предыдущие N соседств (уже установленные, успокоившиеся, на полпроцентика иногда напрягающие RP кипалайвами) замедлят установление N+1-го?
Читаем раздел — CONTROL PLANE SCALING AND CONVERGENCE FOR ROUTEREFLECTOR
APPLICATION
Там будет написано, раз — This evaluation only focused on RR control plane benchmarking and no data forwarding tests were carried out since dedicated RR is normally never in the forwarding path of BGP learnt routes.
Читай между строк — использовали BGP FIB Selective Download.
Читаем далее —
In all convergence and route-scalability tests, BGP peer-groups (with each peer-group containing up to 1000 RR clients) were configured and interface maximum transmission unit was set to 9000 bytes.
Читай между строк — одна update peer group на всех соседей, MTU на интерфейсах 9000.
Далее, смотрим в таблицу и много-много думаем.
Не забываем в голове держать про 4000 BGP пиров и про DMVPN к которому ты так приципился. Я уже молчу про то, что даже обычный IPv4 AFI запросто может дотянуть или превысить длину значений VPNv6 из-за наличия дополнительных атрибутов.
Ну и поговорим про реалии, я думаю, что MTU 9000, это явно не про Интернет. BGP FIB Selective Download это не про DMVPN, а про единственную peer-group'у я вообще молчу. Это к слову про объективность тестов и реалии. Ну и вообщем-то, этот пример еще раз показывает, насколько актуальна или не актуальна информация об оптимизации.
d2zmdbbm9feqrf.cloudfront.net/2014/usa/pdf/BRKRST-3321.pdf. Например, страница 33, снизу-слева. И кстати посмотри лучше эту запись целиком, немало интересного узнаешь про то, какие внутренние механизмы цискиной реализации BGP работают для максимального масштабирования. Может быть, в том видео было про десятков тысяч соседств.
Я эту ссылку, уже прокомментировал в рамках данного комментария и не хочу повторяться. Давай, я тебе лучше расскажу, что было сделано относительно BGP Scanner'а. Раньше, BGP Scanner работал только по принципу poll, сейчас он poll + event driven. Погугли лучше на тему ATF и какое он имеет отношение к BGP Next-Hop Tracking и сходимости на уровне IGP.
Можно. Никто не запрещает. Хуже от этого не будет, да и ресурсы NVRAM опять же экономятся, меньше строк в конфиге.
О! Дошло, это хорошо.
Ты читать вообще умеешь? Или через раз получается? Напиши, какими командами это настраивается.
Функционал dynamic peer group был реализован совместно с фичей peer-template. В больших конфигурациях, сетевой инженер легко может забыть навесить нужный параметр на нейбра или повесить роут-мап, который дублирует функционал предыдущего. Это значит, что в теории Cisco IOS может не очень удачно распределить update группы между нейбрами — это раз. Второе, потенциально еще существуют проблемы с синхронизацией и всякие slow-peer'ы, которые могут заафектить производительность BGP относительно данной dynamic update group'ы. По этому на high scale конфигурациях, этот вопрос не оставляют на откуп Cisco IOS, а стараются причесать. И тот же функционал BGP slow-peer позволяет управлять поведением механизма dynamic update group.
На какую проблематику? Ты ведь совершенно неправильно ее описал.
Я тебе ее достаточно доходчиво описал в этом комментарии. Ибо с понимаем вопроса у тебя туго.
Именно это я тебе и успешно доказываю. У тебя есть какие-то ошметки общих знаний из книг, но ты не имеешь ни малейшего представления о происходящем сейчас, в реальном мире.
Не знаю, чего ты там и кому доказал. Думаю, окружающее быстрее тебя понимают о чем идет речь, чем ты сам.
Мне кажется, или число картинок в твоих комментариях прямо пропорционально степени твоего отчаяния, злости на то, что твое ЧСВ снова до плинтуса опускают?
Так как с холодным стартом мы худо-бедно разобрались (можем конечно еще обсудить connection mode active/passive, всякие там FPD и другие интересные фичи), я тебе еще «наброшу» на тему BGP Scanner'а, если ты не против. А то ты прям тут про него так порывался рассказать. Я надеюсь тебе термин ATF знаком (это к вопросу о скорости сходимости на уровне IGP)?
В случае с примером для экспоненциального распределения, ось Y — это соседи, ось X — время. В противном случае график функции должен быть «перевернутый».
Вопрос. Будет ли каждый роутер, загружающий лучшие маршруты в FIB, осуществлять процесс scan? Может, так понятнее.
Поведение маршрутизатора зависит от его конфигурации. Я бы хотел бы заметить, что уже упоминал про ситуацию с BGP RR сбоку. Так вот, если на BGP RR сконфигурировать функциональность BGP FIB Selective Download, то определенный набор префиксов (или все префиксы) полученные по BGP, дальше BGP RIB не пойдут и FIB загружаться не будут. И как я уже сказал ранее, это оказывает положительное влияние на скорость конвергенции BGP.
Что касается scan процесса. Зачем мне повторяться? Разве вот ранее сказнное не содержит ответа на твой вопрос? У тебя проблемы с пониманием? Я процитирую еще раз:
BGP Scanner. Walks the BGP table and confirms reachability of the next hops. BGP scanner also checks conditional-advertisement to determine whether or not BGP should advertise condition prefixes, performs route dampening. In an MPLS VPN environment, BGP scanner imports and exports routes into a particular VPN routing and forwarding instance (VRF). Once a minute.
Задам встречные вопросы. Какой процесс пишет маршруты в BGP RIB и как префикс попадает в FIB? Какой процесс осуществляет BGP Best-Path Selection Algorithm? А то ты как-то слишком рьяно утверждаешь, что весь процесс тюнинга BGP сводится к тюнингу bgp scan, а все остальное херня полная.
Всего-то надо уметь читать…
1) SA DB загружается в ESP с RP. Это как бы очевидно.
2) Существует очень много фич, которые реализованы хардварно в ESP. К примеру, чтобы считать netflow, не требуется отправлять пакеты в RP.
Дима, а зачем ты повторяешь за мной? Ты хочешь казаться умнее? Показать вид, что ты это знал? Мне кажется, что если бы ты знал это, то у тебя тут не случился батхерт на фоне моих слов о том, что IPSEC частично оффлоудится на QFP. Более того, когда речь идет про 4000 IPSec туннелей в контексте «масштабирования», то как минимум речь идет про IPSec SA. Надо ли мне объяснять, что такое IPSec SA или таки сам погуглишь? Кроме того, я хотел бы заметить, что QFP, это тебе не ASIC. В случае с ASIC, реализация логики осуществляется в железе. В случае с QFP, реализация логики осуществляется на основе микрокода. Надеюсь, тебе термин «run to completion» знаком?
Так откуда ты взял цифру «4000 BGP пиров с 100 000 префиксов на борту»? Почему именно 100000 префиксов, а не 600000 или 10?
Распространенный тест Cisco в лабе — 1000 пиров и 100000/1000000 маршрутов. Оперируя такими цифрами, гораздо легче производить расчеты и экстраполировать данные, которые были получены в ходе тестирования оборудования. Одно дело посчитать 15% от цифры 13734, и другое дело посчитать 15% скажем от значения в 10000.
А вообще, подобные вопросы показательны. Сразу видно, что полноценного тестирования оборудования ты никогда не делал.
Ага. И при правильном дизайне это не является проблемой, потому что со времен RIP мы несколько ушли вперед…
Со времен RIP мы действительно ушли далеко, но даже основы, которые были описаны 5-8 лет тому назад, до сих пор актуальны. У меня отец любит говорить, все новое, это хорошо забытое старое. Так вот, на старых железка cBus может быть был в районе 10-100 Мбит, а сейчас 10 Гбит и выше, но основополагающие принципы не сильно поменялись. Это примерно как классическая реализация STP и STP + вендорские расширения типа port-fast или MSTP. Надеюсь параллель понятна?
Несложно заметить, что у тебя нет личного опыта, раз «сотни соседств» тебя пугает.
Ага, действительно, несложно заметить, что у тебя нет ни какого личного опыта связанного с эксплуатацией действительно больших сетей. Меня не пугают сотни соседей, я сказал всего лишь, процитирую еще раз:
Well it's depends. Призимлить 1000 BGP сессий на одну коробку, может быть не меньшим злом. Trade-in/trade-off.
Если у тебя подобные слова вызывают страх, обратись к психологу. А если глючит и «кажется», то к психиатру.
Дальше, когда я вспомнил про MSS, у тебя почему в качестве основной ассоциации возникла проблема с обеспечением постоянного end-to-end MTU на сети. Далее, я тебе рассказал намекнул про MSS и TCP в контексте BGP протокола. Но как это не странно, MSS влияет не только на производительность TCP трубы. Это значение используется для расчета значений hold-queue, которая напрямую связана с тем, сколько маршрутизатор сможет обработать подключений и следовательно влияет на количество BGP соседей. А вот если бы ты это действительно понимал, то подумал бы над проблемой, что будет с маршрутизатором, когда тебе одновременно прилетит от 4000 пиров TCP ACK и сколько времени потребуется на установку всех подключений. Ну и главное, вот тебе формула для расчетов hold-queue:
Ну я же говорю. Где-то слышал, где-то видел, нахватался верхушек и теперь строишь из себя хрен пойми чего, пытаясь лечить людей.
Угу. Возможности ESP. Что-то мне подсказывает, что та цифра споков (4000) уперлась именно в ESP, а у RP еще все хорошо.
Как это не странно, в архитектуре Cisco ASR 1000, производительность ESP и RP имеет значение. Упереться можно как в RP, так и в ESP. И проблема носит более глубокий характер, потому что когда речь заходить про туннели, то это тянет за собой множество вопросов, начиная от Interface DB, заканчивая keepalive сообщениями по туннелями.
Даже с EIGRP. А BGP в такой топологии скейлится лучше.
В такой, это в какой? В partial-mesh, full-mesh? BGP RR был придуман не просто так. Я конечно понимаю, что в enterprise очень любят DMVPN, но херни не надо нести на фоне полного отсутствия какой-либо конкретики. Ок? BGP в топологии full-mesh не очень хорошо скайлится и все упирается в проблематику вертикального масштабирования. Ибо n * (n-1)/2. А в топологии hub-spoke, вообще основная нагрузка ложится на центральное устройство. И тот же BGP RR или BGP Confederation, позволяет перейти к схемам с горизонтальным масштабированием. Действие закона Амдала еще ни кто не отменял.
У меня с примерно тысячей EIGRP соседств, с таймерами 5/15, хорошо если RP у 1002-X на пару процентов задумается. Колд старт тоже не проблема, нагрузка от всего есть, но небольшая. У 7200 дела обстоят намного хуже, при колд старте расколбас (соседства то падают по отсутствию кипалайвов, то поднимаются) пару минут может продолжаться. Но помним, что там много чего одновременно происходит — согласование IPSec SA куда тяжелее, чем поднятие EIGRP соседства.
Я тебе расскажу, на что влияет все выше сказанное. Если ты видишь цифры в 4000 подключений, то это не значит, что скорость установки новых подключений будет иметь дискретное равномерное распределение, оно скорее будет иметь экспоненциальное распределение. Это опять же все к вопросам масштабируемости, производительности и скорости конвергенции. И если ты не понимаешь эти зависимости и не способен их отследить/осознать, тебе вообще противопоказано работать с высоконагруженными системами/сетями. Ну и чтобы было понятно, пара картинок (так как мне лень тебе рисовать картинку (надеюсь твой мозг это осилит), представь себе, что ось Y — это время, а ось X — количество соседей):
дискретное равномерное распределение
экспоненциальное распределение
Вот она проблема людей, обладающих бумажками и не обладающих боевым опытом. Они ни за чем не следят и не знают ничего что выходит за рамки необходимого для получения бумажки (а там очень мало на самом деле).
Нет, это проблема людей таких как ты. Которые не хотят учиться, этот тред лишнее тому доказательство. И если у тебя комплексы, то это твоя проблема.
А по твоей ссылке пишут не то чтобы неправду, но сильно устаревшую информацию, такое бывает. Ты можешь зайти в консоль любой железки и убедиться. Как можно этого не знать — понятия не имею. Ты же вроде был падаваном в операторе связи, должен знать BGP лучше моего, в первую очередь такие нюансы.
Ты глупый и наивный. Ибо вся информация, до сих пор актуальна. Первое — команда peer-group не является depricated, а это значит, что ее можно таки встретить в конфигах и на продакшене. Второе — dynamic peer group еще нужно настроить. Третье — если кто-то реализовал этот функционал, то это не значит, что можно забить на проблематику. Как раз таки, полное понимание проблематики данного вопроса, помогает в вопросах оптимизации и принятия решений, а не тупое следование design guid'ам. Иначе, у таких как ты, возникает bgp scanner головного мозга.
Ну ты продолжай «присаживаться» в свою же лужу, считая, что чтение «старых книг» это пустая трата времени, а сертификация уровня CCIE ни чего не дает.
Ты же вроде был падаваном в операторе связи, должен знать BGP лучше моего, в первую очередь такие нюансы.
Я думаю, что окружающие прекрасно видят всю глубину твоих познаний, в том числе, кто и о каких нюансах говорит.
Он видит весь трафик в одну сторону. Если был пакет с флагом SYN, а затем начинают идти пакеты с флагом ACK, то сессия наверняка жива, клиент получил SYN ACK. Это может быть не так в случае подделки пакетов клиентом, но не вижу рисков в таком векторе атаки, кроме разве что возможности целенаправленно досить одну ноду пула ACK пакетами.
Балансеру в этой схеме неизвестно количество переданных пакетов от сервера к пользователю, ибо флоу летит мимо балансера, это напрямую связанно с tcp sequence number пакетах (я уже молчу про всякие флаги типа RST, PSH, URG со стороны сервера). Это одна из причин, по которой большинство DPI коробок имеют ограничения в ситуациях с асимметричным трафиком. А с учетом мобильных пользователей, лучше вообще не заикаться.
Драйверы — возможность с полностью нулевым влиянием на сервис снять трафик с узла (старые сессии доработают, но новые уже не будут на него назначаться), возможность при включении узла дать ему сначала небольшой (главное — контролируемый) процент трафика, возможность кипалайвить узел и в случае проблем быстро всех переключить на другие сервера (вариант с BGP сложнее — надо внутри самого сервера организовывать watchdog, проверяющий доступность вебсервиса и рвущий соседство при недоступности). В общем, DSR дает гибкость с небольшими компромиссами там, где трафик к серверу радикально ниже, чем от сервера.
Так и запишем — BGP считает маршруты только при поднятии сессии, ок.
Ты опять на своей волне? Причем здесь локальные маршруты и тот же BGP FSM? Или уже просто настолько присел в свою лужу (в которой почему-то тебе мерещатся другие, но не собственная персона), что уже просто не знаешь как извернуться?
Всё еще печальнее — ты даже не различаешь понятия control plane и data plane.
Все этапы согласования SA выполняются на обычном процессоре.
В случае платформы ASR1k весь data plane обрабатывается QFP. Правда, как раз шифрованием он вообще не занимается, там отдельный акселератор стоит :) Вот в новых ISR 43XX, эмулирующих QFP на general purpose ядрах, они и шифруют.
Мне это напоминает цирк в исполнении Дженифер Псаки и заявления вида – «отправим флот к берегам Белоруссии». Стилистика похожая.
Единственное с чем согласен, надо было уточнить про шифрование на акселераторе (который, кстати, не на всех ESP есть), но основной сути это не меняет.
Смотрим 10ый слайд и читаем внимательно. И опаньки, сюрприз!:
Adaptation Layer extends to ESP to
incorporate all of the respective service databases used by the QFP.
E.g. FW session state, Netflow caches,
Voice terminations, IPsec SA DB …
• The QFP is fed and/or can build these
databases on the fly while it is
processing flows.
• Significant offload of RP resources
(flow exports, logs)
Осталось еще понять, что такое рециркуляция внутри чипа, между чипами и как это все связанно с масштабируемостью внутри коробки.
Меня не перестает поражать твой постоянный полет мысли.
А меня ограниченность твоего мышления.
Теперь выясняется, что Switch'у на нижней картинке топика (вообще-то речь про нее идет, с возможным горизонтальным масштабированием) уже надо full view иметь. Вопрос — ты хоть раз в жизни занимался дизайном чего-либо? Или за тебя взрослые думали?
Мы вроде бы, пока еще говорим про масштабирование и сходимость BGP. Или ты думаешь, что ЦОД — это 2-3 сервера? Ну если у тебя ЦОД 2-3 сервера, то я в принципе не удивлен глубиной твоих познаний. Сразу видно какого масштаба задачи тебе приходилось решать. А про горизонтальное масштабирование, ты упомянул так, для красного словца? Ты смысл то понимаешь?
Да и главное, открою для тебя еще одну Америку. В некоторых ЦОД может присутствовать BGP Full View, его конечно не гоняют везде, но это не отменяет самого факта. Ну и существуют ЦОД, которые насчитывают сотни тысяч серверов (вот уж где присутствует, так присутствует горизонтальное масштабирование).
Но откуда же ты берешь эти цифры? Да и проблема может возникать при cold boot, BGP обычно не делает периодический флад таблицы всем нейборам…
Из личного опыта. А вот откуда ты взял цифру десятки тысяч, вот это мне до сих пор непонятно. Более того, я уверен, что ты не задавался вопросом — «а откуда взялась цифра 4000 BGP соседей и как выглядел этот тест».
Но в целом, уже хорошо, что начинаешь задаваться вопросом «откуда я беру эти цифры».
Ты все еще будешь настаивать на том, что peer-group дает выигрыш в каких-либо ресурсах помимо nvram?
И разобраться с тем, что делают процессы BGP I/O и BGP Router.
Я тебе еще оставлю оттуда одну цитату:
BGP Peer Groups
While they help simplify BGP configuration, BGP peer groups also can enhance scalability. All peer group members must share a common outbound policy. Thus, the same update packets can be sent to each group member, reducing the number of CPU cycles that BGP requires to advertise routes to peers. In other words, with peer groups, BGP walks the BGP table only on the peer group leader, filters the prefixes through the outbound policies, and generates updates, which it sends to the peer group leader. In turn, the leader replicates the updates to group members with which it is synchronized. Without peer groups, BGP must walk the table for every peer, filter prefixes through outbound policies, and generate updates that are sent only to the one peer.
Если хочешь перестать публично позориться в чужом корпоративном блоге,
Я думаю, что тут прекрасно заметно, кто тут позорится и проявляет грязные инсинуации.
можем перейти в ЛС.
Мне от тебя ничего не нужно, а техническая информация полезна будет и для других людей.
Речь про обычные сервисы типа http или https. Этот кейс рабочий, балансеру известны src port, src ip и dst port, dst ip, далее роутинг на балансере идет с учетом данной информации + мониторинг сервера. Если какой-то сервер вылетает, то работающие флоу не перестраиваются из-за изменений значния хешей. Я согласен с тем, что балансер не знает «наверняка» (надо гуглить детальное описание какого-нибудь ldirectord) полное состояние сессии, но это не значит, что кейс с асеммитричным роутингом на основе L4 информации — работать не будет. Работает и некоторые люди почему-то его используют (возможно там могут быть и другие драйверы, а не только проблемы с перерасчетом хэша).
Что касается ACK и RST, в теории да, проблема может всплыть (переполнение таблиц на балансировщике). Но опять же имея информацю о TCP окне пользователя, прикнуть размер окна не составляет особой проблемы. В итоге, мы можем сессию ограничить по таймауту, с учетом потенциального размера окна. Как-то так…
PS: Я же говорю, слишком жирно набрасываете, аж через монитор течет (народ троллить, нужно тоньше) )))
Опять чушь.
Cisco всегда продвигала ISIS, а не BGP. На BGP в DC она скорее была вынуждена согласиться. BGP скорее двигал активно Juniper, а теперь уже RIFT.
Про сходимость так вообще чушь несусветная написана. Отвечу так:
Вы бы поменьше «шаловливыми» руками клавиши трогали и побольше книжки.
https://ru.wikipedia.org/wiki/%D0%9F%D0%B0%D1%80%D0%B0%D0%B4%D0%BE%D0%BA%D1%81_%D0%B2%D0%BE%D1%80%D0%BE%D0%BD%D0%BE%D0%B2
Разбор сделай не только с точки зрения производительности DRAM на RP vs TCAM на различных картах, но и всякие там интересные режимы аля cef и dcef.
Давай, я тебе процитирую, мой пост ранее от 16 сентября 2015 года, который написан был в 16:55:
Далее относительно программирования TCAM. TCAM программировать (читай сгружать маршруты в FIB) не всегда обязательно (и опять же это можно сконфигурировать) и зависит от кейсов, а вот сходимость это улучшает в разы. И чтобы ты понимал, речь идет о кейсах с BGP RR «с боку», который ни как не участвует в forwarding'е трафика (ибо by default для iBGP NHOP unchanged) и используется лишь для сигнализации маршрутной информации.
Расскажи еще нам про свои намеки спустя два дня, написанные 18 сентября 2015 в 14:34. Мы обязательно послушаем в очередной раз историю про лужу, про то как ты открываешь в очередной раз веб-сайт Cisco Live и какой ты молодец. Заодно не забудь нам рассказать про BGP FSM и выбор наилучшего маршрута.
Нет, я утверждаю другое (до сих пор, я тебе пытался тонко намекнуть, на толстые обстоятельства, но хочешь конкретики, пожалуйста). Я утверждаю, что ситуация с QFP не показатель, так как этот микропроцессор присутствует не во всех железках, и уж тем более эта история не про других производителей (например Juniper или Huawei). И уж тем более, это ну ни как не противоречит моим словам (от которых ты подпрыгиваешь с какашками в руках), цитирую (дословно):
Well it's depends. Призимлить 1000 BGP сессий на одну коробку, может быть не меньшим злом. Trade-in/trade-off. Многое зависит от железа
Я также утверждаю, что оперирование голыми цифрами по масштабируемости из спецификаций на оборудование без разбора конкретных ситуаций — слишком опрометчивое утверждение. Особенно без полного понимания того, как достигаются данные цифры, откуда они берутся и какие были условия во время тестирования. И главное, как это все коррелирует с таким понятиями, как скорость конвергенции и предъявляемые требования к сети.
Теперь, ты так у нас любишь вспоминать про FIB и особенно TCAM. Давай поговорим про TCAM. В чем основное отличие TCAM от DRAM на RP? Какую структуру имеет TCAM память, на каких операциях она выигрывает и за счет чего? Сколько занимает времени запись данных в ячейку памяти в случае с DRAM (которая к примеру стоит на RP2) и сколько в случае с TCAM? Это тебе к вопросу, почему BGP FIB Selective Download так эффективен и сколько времени занимает запись BGP Full View в TCAM на обычном пограничном маршрутизаторе.
Домашнее задание — рассмотреть этот вопрос с точки зрения аппаратной реализации таких платформ, как — Cisco 7200 NPE-G2 (динозавр, который кстати до сих пор встречается), Cisco ASR 1000, Cisco Catalyst 6500 Sup720, Cisco Catalyst 6800 Sup2T и Cisco ASR 9000 RSP-440. Глядишь, ты откроешь для себя еще и дивный мир BGP PIC Edge/BGP PIC Core.
Нет, здесь интересно другое. Расскажи нам про аппаратную реализацию IPSec на других платформах, про то, как они работают с IPSec SA DB, как взаимодействуют с акселератором. И главное, ты нам расскажи, сколько будет сходиться вся эта конструкция на примере того же Cisco ASR 1000. Я тебе дам подсказку, когда я тестировал ASR 1000, в лаборатории, голый PPPoE, на заявленые значения в 48,000 сессий, это заняло около 16-18 минут. Спустя 6 лет, эта же операция занимает около 11-12 минут и это после серьезной оптимизации программной архитектуры Cisco IOS-XE (чего стоит один переход от 32 битной архитектуры, к 64 битной), увеличенного количества ядер на QFP и более производительного RP.
Хорошо, что ты понимаешь, что QFP — это навороченный сетевой процессор, который впечатляет своими возможностями.
И плохо то, что ты не понимаешь, парадокса с примером аппаратной архитектуры на базе QFP процессора. Плохо, что ты не понимаешь, что система с QFP (например тот же Cisco ASR 1000) имеет достаточно размытые границы в части control-plane и forwarding-plane (которые размываются еще больше, по мере того, как разработчики допиливают софт и микрокод). Особенно, если рассматривать данные аспекты в сравнении с другими платформами. Потому что, если бы ты это понимал, то не хватался бы в очередной раз за «какашки» (кажется так ты говорил?), я тебе процитирую:
Теперь перейдем к другой части твоего утверждения.
Я тебе могу рассказать про не менее интересные кейсы и нюансы на платформе Cisco Catalyst 6500 в конфигурациях с DFC и без DFC плат. И некоторые из них, могут иметь схожу проблематику вопроса. А чтобы понимать степень и глубину твоих познаний, задам несколько вопросов. Расскажи нам про нюансы, которые могут вылезать при распараллеливании задач, все ли задачи можно распараллелить и что подразумевает под собой термин «run to completion» (сможешь привести примеры?)?
Ну так найди нам на Cisco Live нужную презентацию, а потом расскажи, мы с удовольствием послушаем и посмотрим какой ты молодец. Про то, как QFP работает с аксселератором, как он работает с DB Flow кэшем, и как PPE обрабатывает пакеты. Детальнее того, что написано в том документе, о котором я говорил ранее.
А что еще ты не видишь смысла делать? Я думаю, что тут люди прекрасно видят, у кого тут вызывает эти картинки ступор и идет разрыв шаблона, и про tcp mss, и про peer-group'ы и про многое другое. Я тебе процитирую, как ты ответил на мой комментарий в самом начале:
Если люди пойдут по данной ссылке, они оценят. Ну да ладно, мы еще к этому вопросу вернемся.
Я пока от тебя ничего не услышал, как говориться: «после вас». Тебя спросили, а ты начинаешь переводить стрелки. Тебе задали ряд наводящих вопросов, а именно — сможешь ли ты детально описать, как QFP взаимодействует с этим кэшем, как обрабатывает пакеты на PPE и как взаимодействует с аксселератором? Я уже молчу про «run to completion». Я тебе задам еще один наводящий вопрос — все ли ASIC и NPU умеют работать с таким кэшем, какой это дает эффект с точки зрения итоговой производительности и главное для чего реализовали данный функционал? На подумать, почему это разгружает CPU на RP и почему на Cisco ASR 1000 форвординг over tunnel идет без серьезного performance degradation with multiple features.
Ну в отличии от тебя, я и в лабе был (по обе стороны) и в реальности активно кручу гайки. Именно по этой причине до сих пор не верю «в розовые пони и единороги» и стараюсь сопоставить информацию, а не голословно утверждать, что ограничений нет и главное это BGP Scanner.
Рассказать про другие спецэффекты, связанные с изменением в Cisco IOS со стороны разработчиков относительно default behavior? Или быть может мне вспомнить про ситуации, в которых ломается IPC и коробка оживает только после cold restart'a (или ты думаешь такое встречается только у Juniper'а)? Я тебе могу еще рассказать про то, как на обычном Cisco Catalyst 6500, Supervisor может уйти в перезагрузку из-за ввода команды show ip helper или show interface такой-то transceiver detail, параллельно споткнуться об еще один баг и уложить частично forwarding на коробке после отработки всяких NSF/SSO.
Не всегда и причин может быть множество. Например — маркетинг, которым ты тут размахиваешь во все стороны, утверждая, что это последняя инстанция. Для серьезных заказчиков, бывают делают и регрессивное тестирование, просто потому, что люди хотят понимать поведение коробки под серьезной нагрузкой и идентифицировать потенциальные узкие моменты в программной или аппаратной архитектуре оборудования, которое в свою очередь может накладывать ограничения на конкретный дизайн или сетевую архитектуру. Я уже молчу про регрессивное тестирование ближайших конкурентов, чтобы было потом чем «уколоть» конкурента во время тендера.
В случае с High Scale DMVPN есть не мало и других моментов, о которых я тебе напомню чуть ниже и в контексте hold-queue.
Чушь не надо пороть, ок? Тестируют не только на IMIX трафике, но и маленькими и большими пакетами. Ибо IMIX не покажет тебе наличие регрессии. Более того, понятие IMIX у каждого вендора может отличаться, я уже молчу про профиль трафика у конкретного заказчика. Например, у ivi.ru он один, у тебя другой, у меня другой, у оператора третий. Знаешь почему так происходит? Потому что бизнес решает разные задачи и набор приложений у всех разный. Так, что IMIX не показатель и скорее носит маркетинговый характер для непросвещенных.
Нет, тебе не понятна. Дерево и в том и другом случае. У них общего, гораздо больше, чем ты себе судя по всему, можешь представить. Начиная от основополагающих принципов выбора root бриджа с некоторыми поправками, заканчивая BPDU сообщениями. И с RSTP я ничего не путал, поэтому гонор свой сбавь, ок? А то если мы сейчас начнем копать, то еще много чего интересного узнаем от тебя в стиле BGP FSM и выбор наилучшего маршрута.
Сейчас я тебе расскажу, кто не в курсе и каких факторов.
«А пацаны то и не в курсе» (читай 4000 споков), что им оказывается нужно слать пакеты медленнее, потому что так сказал некий JDima с хабрахабхр. Им оказывается еще нужно рассчитаться на первый, второй, третий и т.д., и ждать своей очереди прежде чем слать TCP ACK в сторону хаба и забыть про существование IPSec'а, а то вдруг RP обидеться или картина мира у JDima с хабрахабр не сойдется. Какие негодяи. Что за ущербная логика?
Так на секунду, в hold-queue могут попадать не только BGP пакеты. SPD был придуман не просто так. Далее, когда ты тут продолжаешь, что-то доказывать на тему — «посмотрите какие тут цифры и это все с IPSec и другими плюшками и очень круто живет с DMVPN», то упускаешь из виду очень важный момент, а именно — сколько времени эта конструкция будет взлетать.
Ага замечал, более того, я не забыл тебе напомнить про hold-queue. И напомни, чего ты там говорил про оптимизацию и MTU? В каком контексте рассматривал проблематику MTU? И чего ты там сказал про мои слова, которые звучали так:
Открою секрет, что сходимость в BGP определяется не только процессом выбора лучшего маршрута или наличием/отсутствием всяких плюшек вида BGP PIC Edge/Core, но и BGP Finite State Machine (надеюсь этот термин знаком?). На процесс сходимости BGP влияет достаточно много аспектов от производительности CPU и конфигурации, до MTU и количества Adj-RIB-in/Adj-RIB-out.
Ничего такого не вспоминаешь? BGP Scanner ты наш.
А еще чего ты говорил?
А чего это мы его не рассматриваем? Ты же сам говорил, процитирую:
Или ты думаешь у нас RR не может уйти в перезагрузку из-за бага или обслуживания, или hub имеет 100% uptime?
Достаточно отлететь приличной части spok'ов, чтобы началось веселье. Например, упал BGP апстрим в Интернете или какой-нибудь Вася в очередной раз на границе с Финляндией решил вырыть траншею по глубже, чтобы враги не пролезли. Вполне себе реальный сценарий, который встречается давольно часто. Вот тебе про случай с Level 3:
Being single-homed behind Level3 this morning
i1.wp.com/cdn.honestnetworker.com/tumblr_muvi2niGxf1slbjseo1_4002.gif
Надоело объяснять, ей богу. Открываем Test Report ISOCORE на ASR 1000, который доступен на сайте Cisco.
Вот ссылочка — www.cisco.com/c/dam/en/us/products/collateral/application-networking-services/wide-area-application-services-waas-software/ITD13029-ASR1000-RP2Validationv1_1.pdf
Читаем раздел — CONTROL PLANE SCALING AND CONVERGENCE FOR ROUTEREFLECTOR
APPLICATION
Там будет написано, раз — This evaluation only focused on RR control plane benchmarking and no data forwarding tests were carried out since dedicated RR is normally never in the forwarding path of BGP learnt routes.
Читай между строк — использовали BGP FIB Selective Download.
Читаем далее —
In all convergence and route-scalability tests, BGP peer-groups (with each peer-group containing up to 1000 RR clients) were configured and interface maximum transmission unit was set to 9000 bytes.
Читай между строк — одна update peer group на всех соседей, MTU на интерфейсах 9000.
Далее, смотрим в таблицу и много-много думаем.
Не забываем в голове держать про 4000 BGP пиров и про DMVPN к которому ты так приципился. Я уже молчу про то, что даже обычный IPv4 AFI запросто может дотянуть или превысить длину значений VPNv6 из-за наличия дополнительных атрибутов.
Ну и поговорим про реалии, я думаю, что MTU 9000, это явно не про Интернет. BGP FIB Selective Download это не про DMVPN, а про единственную peer-group'у я вообще молчу. Это к слову про объективность тестов и реалии. Ну и вообщем-то, этот пример еще раз показывает, насколько актуальна или не актуальна информация об оптимизации.
Я эту ссылку, уже прокомментировал в рамках данного комментария и не хочу повторяться. Давай, я тебе лучше расскажу, что было сделано относительно BGP Scanner'а. Раньше, BGP Scanner работал только по принципу poll, сейчас он poll + event driven. Погугли лучше на тему ATF и какое он имеет отношение к BGP Next-Hop Tracking и сходимости на уровне IGP.
О! Дошло, это хорошо.
Функционал dynamic peer group был реализован совместно с фичей peer-template. В больших конфигурациях, сетевой инженер легко может забыть навесить нужный параметр на нейбра или повесить роут-мап, который дублирует функционал предыдущего. Это значит, что в теории Cisco IOS может не очень удачно распределить update группы между нейбрами — это раз. Второе, потенциально еще существуют проблемы с синхронизацией и всякие slow-peer'ы, которые могут заафектить производительность BGP относительно данной dynamic update group'ы. По этому на high scale конфигурациях, этот вопрос не оставляют на откуп Cisco IOS, а стараются причесать. И тот же функционал BGP slow-peer позволяет управлять поведением механизма dynamic update group.
Я тебе ее достаточно доходчиво описал в этом комментарии. Ибо с понимаем вопроса у тебя туго.
Не знаю, чего ты там и кому доказал. Думаю, окружающее быстрее тебя понимают о чем идет речь, чем ты сам.
Просто подлинкую, тебе полезно будет ознакомиться
lurkmore.to/%D0%A7%D0%A1%D0%92
В случае с примером для экспоненциального распределения, ось Y — это соседи, ось X — время. В противном случае график функции должен быть «перевернутый».
Поведение маршрутизатора зависит от его конфигурации. Я бы хотел бы заметить, что уже упоминал про ситуацию с BGP RR сбоку. Так вот, если на BGP RR сконфигурировать функциональность BGP FIB Selective Download, то определенный набор префиксов (или все префиксы) полученные по BGP, дальше BGP RIB не пойдут и FIB загружаться не будут. И как я уже сказал ранее, это оказывает положительное влияние на скорость конвергенции BGP.
Что касается scan процесса. Зачем мне повторяться? Разве вот ранее сказнное не содержит ответа на твой вопрос? У тебя проблемы с пониманием? Я процитирую еще раз:
BGP Scanner. Walks the BGP table and confirms reachability of the next hops. BGP scanner also checks conditional-advertisement to determine whether or not BGP should advertise condition prefixes, performs route dampening. In an MPLS VPN environment, BGP scanner imports and exports routes into a particular VPN routing and forwarding instance (VRF). Once a minute.
Задам встречные вопросы. Какой процесс пишет маршруты в BGP RIB и как префикс попадает в FIB? Какой процесс осуществляет BGP Best-Path Selection Algorithm? А то ты как-то слишком рьяно утверждаешь, что весь процесс тюнинга BGP сводится к тюнингу bgp scan, а все остальное херня полная.
Дима, а зачем ты повторяешь за мной? Ты хочешь казаться умнее? Показать вид, что ты это знал? Мне кажется, что если бы ты знал это, то у тебя тут не случился батхерт на фоне моих слов о том, что IPSEC частично оффлоудится на QFP. Более того, когда речь идет про 4000 IPSec туннелей в контексте «масштабирования», то как минимум речь идет про IPSec SA. Надо ли мне объяснять, что такое IPSec SA или таки сам погуглишь? Кроме того, я хотел бы заметить, что QFP, это тебе не ASIC. В случае с ASIC, реализация логики осуществляется в железе. В случае с QFP, реализация логики осуществляется на основе микрокода. Надеюсь, тебе термин «run to completion» знаком?
Ну и встречный вопрос, сможешь рассказать в деталях, как QFP работает с IPSec SA DB или Flow? Со схемами и точным описанием? Как взаимодействует с внешним акселератором? Как PPE обрабатывает пакеты? Вот, я чего-то сомневаюсь, что ты сможешь достаточно детально описать всю логику. :-) И скажем так, детальнее того, что описано вот здесь — www.cisco.com/c/en/us/products/collateral/routers/asr-1000-series-aggregation-services-routers/solution_overview_c22-448936.html
Распространенный тест Cisco в лабе — 1000 пиров и 100000/1000000 маршрутов. Оперируя такими цифрами, гораздо легче производить расчеты и экстраполировать данные, которые были получены в ходе тестирования оборудования. Одно дело посчитать 15% от цифры 13734, и другое дело посчитать 15% скажем от значения в 10000.
А вообще, подобные вопросы показательны. Сразу видно, что полноценного тестирования оборудования ты никогда не делал.
Со времен RIP мы действительно ушли далеко, но даже основы, которые были описаны 5-8 лет тому назад, до сих пор актуальны. У меня отец любит говорить, все новое, это хорошо забытое старое. Так вот, на старых железка cBus может быть был в районе 10-100 Мбит, а сейчас 10 Гбит и выше, но основополагающие принципы не сильно поменялись. Это примерно как классическая реализация STP и STP + вендорские расширения типа port-fast или MSTP. Надеюсь параллель понятна?
Ага, действительно, несложно заметить, что у тебя нет ни какого личного опыта связанного с эксплуатацией действительно больших сетей. Меня не пугают сотни соседей, я сказал всего лишь, процитирую еще раз:
Well it's depends. Призимлить 1000 BGP сессий на одну коробку, может быть не меньшим злом. Trade-in/trade-off.
Если у тебя подобные слова вызывают страх, обратись к психологу. А если глючит и «кажется», то к психиатру.
Дальше, когда я вспомнил про MSS, у тебя почему в качестве основной ассоциации возникла проблема с обеспечением постоянного end-to-end MTU на сети. Далее, я тебе рассказал намекнул про MSS и TCP в контексте BGP протокола. Но как это не странно, MSS влияет не только на производительность TCP трубы. Это значение используется для расчета значений hold-queue, которая напрямую связана с тем, сколько маршрутизатор сможет обработать подключений и следовательно влияет на количество BGP соседей. А вот если бы ты это действительно понимал, то подумал бы над проблемой, что будет с маршрутизатором, когда тебе одновременно прилетит от 4000 пиров TCP ACK и сколько времени потребуется на установку всех подключений. Ну и главное, вот тебе формула для расчетов hold-queue:
Hold Queue Size = (Windows Size / 2 * MSS) * Peer Count
Уппс, правда интересно?
Ну я же говорю. Где-то слышал, где-то видел, нахватался верхушек и теперь строишь из себя хрен пойми чего, пытаясь лечить людей.
Как это не странно, в архитектуре Cisco ASR 1000, производительность ESP и RP имеет значение. Упереться можно как в RP, так и в ESP. И проблема носит более глубокий характер, потому что когда речь заходить про туннели, то это тянет за собой множество вопросов, начиная от Interface DB, заканчивая keepalive сообщениями по туннелями.
В такой, это в какой? В partial-mesh, full-mesh? BGP RR был придуман не просто так. Я конечно понимаю, что в enterprise очень любят DMVPN, но херни не надо нести на фоне полного отсутствия какой-либо конкретики. Ок? BGP в топологии full-mesh не очень хорошо скайлится и все упирается в проблематику вертикального масштабирования. Ибо n * (n-1)/2. А в топологии hub-spoke, вообще основная нагрузка ложится на центральное устройство. И тот же BGP RR или BGP Confederation, позволяет перейти к схемам с горизонтальным масштабированием. Действие закона Амдала еще ни кто не отменял.
Я тебе расскажу, на что влияет все выше сказанное. Если ты видишь цифры в 4000 подключений, то это не значит, что скорость установки новых подключений будет иметь дискретное равномерное распределение, оно скорее будет иметь экспоненциальное распределение. Это опять же все к вопросам масштабируемости, производительности и скорости конвергенции. И если ты не понимаешь эти зависимости и не способен их отследить/осознать, тебе вообще противопоказано работать с высоконагруженными системами/сетями. Ну и чтобы было понятно, пара картинок (так как мне лень тебе рисовать картинку (надеюсь твой мозг это осилит), представь себе, что ось Y — это время, а ось X — количество соседей):
дискретное равномерное распределение
экспоненциальное распределение
Нет, это проблема людей таких как ты. Которые не хотят учиться, этот тред лишнее тому доказательство. И если у тебя комплексы, то это твоя проблема.
Ты глупый и наивный. Ибо вся информация, до сих пор актуальна. Первое — команда peer-group не является depricated, а это значит, что ее можно таки встретить в конфигах и на продакшене. Второе — dynamic peer group еще нужно настроить. Третье — если кто-то реализовал этот функционал, то это не значит, что можно забить на проблематику. Как раз таки, полное понимание проблематики данного вопроса, помогает в вопросах оптимизации и принятия решений, а не тупое следование design guid'ам. Иначе, у таких как ты, возникает bgp scanner головного мозга.
Ну ты продолжай «присаживаться» в свою же лужу, считая, что чтение «старых книг» это пустая трата времени, а сертификация уровня CCIE ни чего не дает.
Я думаю, что окружающие прекрасно видят всю глубину твоих познаний, в том числе, кто и о каких нюансах говорит.
ЧСВ убавь.
Может предполагать.
Балансеру в этой схеме неизвестно количество переданных пакетов от сервера к пользователю, ибо флоу летит мимо балансера, это напрямую связанно с tcp sequence number пакетах (я уже молчу про всякие флаги типа RST, PSH, URG со стороны сервера). Это одна из причин, по которой большинство DPI коробок имеют ограничения в ситуациях с асимметричным трафиком. А с учетом мобильных пользователей, лучше вообще не заикаться.
Обсуждали уже.
Ты опять на своей волне? Причем здесь локальные маршруты и тот же BGP FSM? Или уже просто настолько присел в свою лужу (в которой почему-то тебе мерещатся другие, но не собственная персона), что уже просто не знаешь как извернуться?
Мне это напоминает цирк в исполнении Дженифер Псаки и заявления вида – «отправим флот к берегам Белоруссии». Стилистика похожая.
Единственное с чем согласен, надо было уточнить про шифрование на акселераторе (который, кстати, не на всех ESP есть), но основной сути это не меняет.
Ну и пожалуй главное:
Подлинкую:
www.cisco.com/web/DK/assets/docs/presentations/ASR_Enterprise_Solutions.pdf
Смотрим 10ый слайд и читаем внимательно. И опаньки, сюрприз!:
Adaptation Layer extends to ESP to
incorporate all of the respective
service databases used by the QFP.
E.g. FW session state, Netflow caches,
Voice terminations, IPsec SA DB …
• The QFP is fed and/or can build these
databases on the fly while it is
processing flows.
• Significant offload of RP resources
(flow exports, logs)
Осталось еще понять, что такое рециркуляция внутри чипа, между чипами и как это все связанно с масштабируемостью внутри коробки.
Ссылка для медитации (смотрим количество IPSec туннелей и много думаем) — www.cisco.com/c/en/us/products/collateral/routers/asr-1000-series-aggregation-services-routers/datasheet-c78-731640.html
А меня ограниченность твоего мышления.
Мы вроде бы, пока еще говорим про масштабирование и сходимость BGP. Или ты думаешь, что ЦОД — это 2-3 сервера? Ну если у тебя ЦОД 2-3 сервера, то я в принципе не удивлен глубиной твоих познаний. Сразу видно какого масштаба задачи тебе приходилось решать. А про горизонтальное масштабирование, ты упомянул так, для красного словца? Ты смысл то понимаешь?
Да и главное, открою для тебя еще одну Америку. В некоторых ЦОД может присутствовать BGP Full View, его конечно не гоняют везде, но это не отменяет самого факта. Ну и существуют ЦОД, которые насчитывают сотни тысяч серверов (вот уж где присутствует, так присутствует горизонтальное масштабирование).
Из личного опыта. А вот откуда ты взял цифру десятки тысяч, вот это мне до сих пор непонятно. Более того, я уверен, что ты не задавался вопросом — «а откуда взялась цифра 4000 BGP соседей и как выглядел этот тест».
Но в целом, уже хорошо, что начинаешь задаваться вопросом «откуда я беру эти цифры».
Ага :-) Осталось еще разок сходить по этой ссылке:
www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/107615-highcpu-bgp.html#understandbgp
И разобраться с тем, что делают процессы BGP I/O и BGP Router.
Я тебе еще оставлю оттуда одну цитату:
BGP Peer Groups
While they help simplify BGP configuration, BGP peer groups also can enhance scalability. All peer group members must share a common outbound policy. Thus, the same update packets can be sent to each group member, reducing the number of CPU cycles that BGP requires to advertise routes to peers. In other words, with peer groups, BGP walks the BGP table only on the peer group leader, filters the prefixes through the outbound policies, and generates updates, which it sends to the peer group leader. In turn, the leader replicates the updates to group members with which it is synchronized. Without peer groups, BGP must walk the table for every peer, filter prefixes through outbound policies, and generate updates that are sent only to the one peer.
Я думаю, что тут прекрасно заметно, кто тут позорится и проявляет грязные инсинуации.
Мне от тебя ничего не нужно, а техническая информация полезна будет и для других людей.
Что касается ACK и RST, в теории да, проблема может всплыть (переполнение таблиц на балансировщике). Но опять же имея информацю о TCP окне пользователя, прикнуть размер окна не составляет особой проблемы. В итоге, мы можем сессию ограничить по таймауту, с учетом потенциального размера окна. Как-то так…