Comments 89
Первое, во что обычно упираются, это ARP-кэш на роутере, который не хочет понимать, что IP-адрес переехал на другой MAC. Впрочем, современные реализации либо «пингуют» роутер с нового MAC'а (обновляя кэш таким образом), либо вообще используют виртуальный MAC, который не меняется во время работы.
К примеру, ifup-скрипты в CentOS используют arping для обновления ARP-кэшей соседей.
Второе, что бьёт по голове – это серверные ресурсы. Мы ведь не будем держать один сервер из двух в горячем standby? Сервер должен работать! Поэтому мы будет резервировать по VRRP два адреса на каждом сервере: один – primary и один backup. Если один из серверов пары сломается, второй примет на себя всю его нагрузку… может быть… если справится. И вот такая «парность» и будет главным недостатком, ибо не всегда есть возможность или целесообразность держать двойной запас серверной мощности.
А что мешает держать пару адресов и подхватывать по VRRP адрес упавшего?
Во-вторых, статические маршруты не подходят – ведь нам надо иметь возможность автоматически убирать сломанный сервер из кластера. Т.е. надо применять какой-либо протокол динамической маршрутизации.
Отлично подходят. У статических маршрутов есть возможность задать track из IP SLA, который может быть активной проверкой (даже коннектом на tcp-порт).
Увы, приходится констатировать недостаточную проработку предметной области со стороны автора.
А что мешает держать пару адресов и подхватывать по VRRP адрес упавшего?
Ничего не мешает. Вот только как ограничивать загрузку сервера не более 50%? А то если будет больше 50%, то оставшийся просто не выдержит, и сервис упадёт в полном составе.
Отлично подходят. У статических маршрутов есть возможность задать track из IP SLA, который может быть активной проверкой (даже коннектом на tcp-порт).
Не совсем. IP SLA словит только физическое пропадание сервера (сети). А это маловато будет.Нужно целяться на прикладном уровне. Если есть HTTP-проб, то да. Но как правило, такого нету. Поэтому состояние приложения проверяется на сервере, по большому количеству признаков «здоровья». А дальше — то же: сервер должен как-то сообщить роутеру о своём состоянии. Для этого берём динамический протокол маршрутизации.
Если не нужно проверять на прикладном уровне — тогда да, track.
Ничего не мешает. Вот только как ограничивать загрузку сервера не более 50%? А то если будет больше 50%, то оставшийся просто не выдержит, и сервис упадёт в полном составе.
Оставшийся из двух? А если балансировать как-то иначе, то, получается выдержит? Главный посыл в том, что вы утверждаете, что VRRP предполагает простаивающий сервер в резерве. Это, конечно, не правда. Как делится трафик — дело другое. Но если уж Вы упомянули деление его посредством DNS, то там тоже можно всё хорошо организовать посредством weighted round robin в DNS при отдаче единственного адреса. Отдача полного списка не годится в любом случае, она не даёт честного деления нагрузки по ряду причин.
IP SLA словит только физическое пропадание сервера (сети).
Нет
Если есть HTTP-проб, то да. Но как правило, такого нету.
Есть. А общем случае и tcp-connect достаточно.
switch-4900#show ip sla application
IP Service Level Agreement Technologies
IPSLAs Infrastructure version: Engine-II
Supported Operation Types:
802.1agEcho, 802.1agJitter, dhcp, dns, echo, ftp, http
jitter, mpls jitter, pathEcho, pathJitter, tcpConnect
udpEcho
Supported Features:
IPSLAs Event Publisher
Поэтому состояние приложения проверяется на сервере, по большому количеству признаков «здоровья». А дальше — то же: сервер должен как-то сообщить роутеру о своём состоянии.
Нет принципиальной разницы: убрать анонс или закрыть порт от опрашивателя.
Оставшийся из двух? А если балансировать как-то иначе, то, получается выдержит?
Речь о парности, которая присуща VRRP, о том, что либо сервер стоит «в запасе», либо работает, как все. В первом случае это экономически неинтересно. Во втором — при переключении нагрузка на выжившего удвоится (100% рост нагрузки). И не важно, сколько у меня серверов — они все разбиты на пары. А вот когда из 4 серверов выбывает 1, то на три оставшихся придётся +33% дополнительной нагрузки. Такую прибавку серверы, скорее всего выдержат. Это не +100%. С увеличением же количества серверов в кластере там ещё лучше получается.
Supported Operation Types:
802.1agEcho, 802.1agJitter, dhcp, dns, echo, ftp, http
jitter, mpls jitter, pathEcho, pathJitter, tcpConnect
udpEcho
Согласен, но не всегда и не везде.
Нет принципиальной разницы: убрать анонс или закрыть порт от опрашивателя.
Согласен.
В принципе, сигналить на роутер можно по-разному: хоть через CLI, хоть через XML. Что выбрать — дело вкуса.
Круто, интересно!
насколько я помню, Cisco ACE далеко не обязательно full-proxy, он может не проксировать соединение, а делать dnat/snat только.
и раз у вас есть cisco 65xx — почему не попробовали ip slb ( server load balancing)? оно точно работает с помощью nat и вроде бы на скорости карточки, т.к. nat реализован в железе
и раз у вас есть cisco 65xx — почему не попробовали ip slb ( server load balancing)? оно точно работает с помощью nat и вроде бы на скорости карточки, т.к. nat реализован в железе
не обязательно full-proxy, он может не проксировать соединение, а делать dnat/snat только.
Ну, значит всё равно весь трафик через него должен идти. А у нас его очень много. Не как в mail.ru (по донесениям разведки), но порядочно.
почему не попробовали ip slb ( server load balancing)?
Хрюша больше не придёт — нет больше такой функции. Да и когда была, мне про неё гадости рассказывали. Сам попробовать не успел.
Опять же, в регионах нет у нас 6500. И не будет.
оно точно работает с помощью nat и вроде бы на скорости карточки, т.к. nat реализован в железе
Не делайте NAT на Sup2T. Я уже плавал. Больше не хочется. Дело не в производительности. Может быть, как-нить напишу…
Да и ACE уже EoS. Cisco рекомендует цитриковый NetScaler в качестве замены.
1. ExaBGP
2. Очень удобно сервис цеплять на отдельные /32 IP, которые висят на loopback интерфейсе сервера. При езде с сервера на сервер нет проблем с ARP, только меняется маршрут до этого /32.
2. Очень удобно сервис цеплять на отдельные /32 IP, которые висят на loopback интерфейсе сервера. При езде с сервера на сервер нет проблем с ARP, только меняется маршрут до этого /32.
1) Ну, квагга понятно, как возникла? У нас тут есть несколько человек, которые конфигуряли циску. И никого, кто мучал бы BIRD (на тот момент, когда выбирали). Вот то же самое и про ExaBGP. :) Может быть, и до него дойдёт. Правда, если реализуется несколько бешеных идей, то только BIRD нам поможет.
2) Ага! :) И ещё есть несколько трюков — сделаю статью при случае.
2) Ага! :) И ещё есть несколько трюков — сделаю статью при случае.
Напишите статью, будет интересно почитать.
ramax может дать парочку «хороших» советов о том, как уложить Cisco 65xx с использованием NAT-а на ней ;-)
Приятно, когда на «L7» всё хорошо, нет требований абсолютной надежности к низлежащим уровням… А я вот не могу ECMP использовать для этой задачи, нужны балансировщики со sticky по кукам, терминацией SSL и так далее. У вас внезапный массовый переход на другой сервер посреди сессии останется незамеченным, у меня — в некоторых случаях вой поднимется на всю контору. То, что это происходит даже если новый сервер добавить в кластер, очень печально.
Да, мои соболезнования!
Но некоторые элементы этого метода можно перенять и вам. Я так понимаю, у вас всё равно стоит какое-то количество L7-балансировщиков, которые обеспечивают sticky cookie. А вот между ними можно балансировать / резервировать по такой методике, как у нас. Тогда, если между балансерами есть репликация состояний, то всё отработает, как надо.
Но некоторые элементы этого метода можно перенять и вам. Я так понимаю, у вас всё равно стоит какое-то количество L7-балансировщиков, которые обеспечивают sticky cookie. А вот между ними можно балансировать / резервировать по такой методике, как у нас. Тогда, если между балансерами есть репликация состояний, то всё отработает, как надо.
У нас объем трафика мизерный, A/S пара легко переварит всё имеющееся помноженное на 10, но характер трафика нередко достаточно тяжелый, чтобы, грубо говоря, несколько мегабит могли уложить высокопроизводительный сервер. И критичность высокая, как и цена ошибки. По опыту пользования CSS/ACE можно сказать, что они довольно железобетонные товарищи. К ACE за все время использования ни единой претензии не было. Но вот попытки катить на него бочку постоянно продолжаются. Каждый раз выясняется, что виновата серверная сторона, либо кто-то неправильно продумал способ кипалайвов, либо еще что в том роде, но сама железка работает идеально.
Железки только для внутреннего потребления, наружу не опубликованы, так что да, живут в тепличных условиях.
Железки только для внутреннего потребления, наружу не опубликованы, так что да, живут в тепличных условиях.
К ACE за все время использования ни единой претензии не было.
У меня к нему сейчас только одна претензия — новым клиентам больше не продаётся. В общем, убила его циска. Может, там и была нехватка производительности, ещё какие-то проблемы — этого я уже никогда не узнаю.
JDima, ничего не напоминает? Помнится у нас с Вами вышел знатный спор по данному вопросу года полтора назад ;) и ведь большинство вопросов я уже озвучивал ранее и (в том числе про bgp сигналинг + отслеживание состояние приложений, эдакое подобие sdn) ;)
Да, помню что-то подобное. Сводился спор вроде к тому, что в типовом случае ECMP работать не будет, разрыв сессии на L4 вызывает сбой на L7, что является проблемой. Так оно и есть. Но у ivi-то не типовой случай, у них приложение, которое незаметно для пользователя переустанавливает соединение. Много таких примеров назовете? Мне вот сейчас ничего другого в голову не приходит, и в моей сети нет ни одного такого приложения. Даже в случае голоса/видео, когда отказ сервера не обязан прервать общение между участниками, так как медиатрафик вообще не через сервер ходит (за исключением конференций и MTP), могут отвалиться определенные фичи управления.
Ну там спор был не только про приложения, но и про anycast внутри площадки. У Вас тогда знатный разрыв шаблона произошел. В целом, примеров существует больше чем статика у Яндекса или ivi.ru. Тот же сервис по защите от DDoS атак Qrator использует BGP Anycast подход (коим защищен сам habrahabr.ru). Я под линкую, чтобы напомнить о чем там тред был: — habrahabr.ru/company/beeline/blog/207162
PS: Для ivi.ru. Я бы порекомендовал смотреть в сторону дизайна аля IX. Поставить в серверный сегмент BGP RR (wtih NHOP unchannged). Пиринг с точки зрения BGP инфраструктуры выглядел бы так: router — bgp rr — server. Network Team в этом случае будет контролировать только две BGP сессии (от двух BGP RR'ов). А на самих серверах использовать ExaBGP для route injection'а в сторону RR (далее это будет централизовано разливаться внутри узла/сети).
Если нужна безопасность, можно еще посмотреть в сторону distributed firewall via BGP flow-spec :)
PS: www.slideshare.net/thomas_mangin/ukuug-spring-2011-mangin-bgp
PS: Для ivi.ru. Я бы порекомендовал смотреть в сторону дизайна аля IX. Поставить в серверный сегмент BGP RR (wtih NHOP unchannged). Пиринг с точки зрения BGP инфраструктуры выглядел бы так: router — bgp rr — server. Network Team в этом случае будет контролировать только две BGP сессии (от двух BGP RR'ов). А на самих серверах использовать ExaBGP для route injection'а в сторону RR (далее это будет централизовано разливаться внутри узла/сети).
Если нужна безопасность, можно еще посмотреть в сторону distributed firewall via BGP flow-spec :)
PS: www.slideshare.net/thomas_mangin/ukuug-spring-2011-mangin-bgp
Спасибо, уже копаем в этом направлении. :) Но чуть-чуть по-другому. По результатам беру на себя обязательство написать статью.
Насчет flow-spec — ждём обновления от циски. Обещали добавить в этом году.
Насчет flow-spec — ждём обновления от циски. Обещали добавить в этом году.
Возвращаясь к вопросу с flow-spec. В общем-то тема перспективная и стоит активно ее изучать. SDN в связке c BGP Based control-plane вполне себе решение. Сценариев может быть множество и это не только anti ddos или distributed firewall. Теоретически через bgp flow-spec можно решить проблему с server-affinity:
«Переходные процессы одного сервера (включение в кластер или исключение) влияют на весь кластер. Ведь роутер ничего не знает о серверах – он думает, что имеет дело с роутерами и каналами. Соответственно, все соединения распределяются на все доступные каналы. Никакого server-affinity. В результате при выключении сервера все соединения перетасовываются между всеми оставшимися серверами. И все активные TCP-сессий разрываются (строго говоря – не все, есть шанс, что часть вернётся на тот же сервер). Это плохо, но учитывая нашу защиту от таких ситуаций (плеер перезапрашивает контент при разрыве соединений) и некоторые финты ушами (о которых я ещё расскажу), жить можно.»
BGP Flow-spec по факту, позволяет сгрузить и просигнализировать PBR правила на маршрутизатор. Если обработать напильником тот же ExaBGP (например по событию — user connect+time (или rise condition завязанный на amount transfered data) на сервер), то в теории может получиться очень интересное решение проблематики sever affinity :-)
Ну или таки жить с «финтами ушами» или кастомными tcp/ip стэками не учитывающие состояние сессии на стороне сервера.
«Переходные процессы одного сервера (включение в кластер или исключение) влияют на весь кластер. Ведь роутер ничего не знает о серверах – он думает, что имеет дело с роутерами и каналами. Соответственно, все соединения распределяются на все доступные каналы. Никакого server-affinity. В результате при выключении сервера все соединения перетасовываются между всеми оставшимися серверами. И все активные TCP-сессий разрываются (строго говоря – не все, есть шанс, что часть вернётся на тот же сервер). Это плохо, но учитывая нашу защиту от таких ситуаций (плеер перезапрашивает контент при разрыве соединений) и некоторые финты ушами (о которых я ещё расскажу), жить можно.»
BGP Flow-spec по факту, позволяет сгрузить и просигнализировать PBR правила на маршрутизатор. Если обработать напильником тот же ExaBGP (например по событию — user connect+time (или rise condition завязанный на amount transfered data) на сервер), то в теории может получиться очень интересное решение проблематики sever affinity :-)
Ну или таки жить с «финтами ушами» или кастомными tcp/ip стэками не учитывающие состояние сессии на стороне сервера.
С переходными процессами проблема из-за того, что коннекшены распределяются round-robin, или по хэш-таблице с числом бакетов = числу линков, так? В этом случае проблему можно решить введением consistent hash, минусом будет только неидеальная балансировка.
В принципе так. Но как показывает практика, в большинстве кейсов, скорее по хэш-таблице с числом бакетов. На тему минусов… Все не так просто. Основной потребитель массового оборудования (вендорского, аля cisco, juniper и еже с ними) — операторы связи. Этим гаврикам, чем идеальнее размажется нагрузка между каналами, тем лучше. Для них каналы, это деньги. Достаточно вспомнить их мольбы о всяких Fat PW и еже с ними. Они же и основной потребитель данной продукции.
Что касается consistent hash, аля RFC 2991, о котором тут кто-то уже упоминал, то подозреваю, что тут не все так просто. Есть подозрение, что реализация в железе, выглядит дороже и сложнее. У Cisco реализация подобного хэша, была только на PIX'ах и CCS свитчах. А там голый CP/CPU, а не Forwarding Plane и ASIC'и. Но могу ошибаться, этот вопрос надо изучить.
Что касается consistent hash, аля RFC 2991, о котором тут кто-то уже упоминал, то подозреваю, что тут не все так просто. Есть подозрение, что реализация в железе, выглядит дороже и сложнее. У Cisco реализация подобного хэша, была только на PIX'ах и CCS свитчах. А там голый CP/CPU, а не Forwarding Plane и ASIC'и. Но могу ошибаться, этот вопрос надо изучить.
Кстати, теоретически, можно еще попробовать поиграться с таким эффектом, как поляризация FIB/CEF. Но это скорее может выправить ситуацию на отказах «между» (читай в середине/middle spine), а не на «концах».
В общем, надо перечитать RFC 2991 и пораскинуть мозгами над эффектом cef polarization (но опять же не во всех топологиях может быть применимо).
В общем, надо перечитать RFC 2991 и пораскинуть мозгами над эффектом cef polarization (но опять же не во всех топологиях может быть применимо).
>У Вас тогда знатный разрыв шаблона произошел
Угу. Вы там городили велосипед с квадратными колесами в виде петли Мёбиуса зачем-то, от непонимания куда более простых и давно проверенных дизайнов…
Проблема у них кстати ровно та же, что я описывал:
«Переходные процессы одного сервера (включение в кластер или исключение) влияют на весь кластер. Ведь роутер ничего не знает о серверах – он думает, что имеет дело с роутерами и каналами. Соответственно, все соединения распределяются на все доступные каналы. Никакого server-affinity. В результате при выключении сервера все соединения перетасовываются между всеми оставшимися серверами. И все активные TCP-сессий разрываются»
Но так как пользуется сервисом одно конкретное приложение, и это приложение запросто переживает разрыв сессии, этот дизайн работает. Повторяю: очень специфический дизайн, с кучей критических недостатков, неспособный работать в общем случае.
> Тот же сервис по защите от DDoS атак Qrator использует BGP Anycast подход (коим защищен сам habrahabr.ru)
Это не внутри ЦОДа, а между ЦОДами :) В случае DDOS такой подход разумен, так как не позволяет сконцентрировать атаку на единой точке входа, ну и провайдеры тоже рады уменьшению внешнего трафика. И DDOS — экстремальная ситуация, где «немного страдает сервис» предпочтительнее, чем «сервиса нет вообще».
>Я бы порекомендовал смотреть в сторону дизайна аля IX
Дизайн аля IX, где используется обширный L2 сегмент — безусловное зло. Но у IX-то вариантов особых и нет, приходится так делать, замена next hop добавила бы немерено головной боли.
https://chi.ams-ix.net/technical--7/specifications-descriptions/port-security-at-ams-ix
https://labs.ripe.net/Members/kistel/the-ams-ix-outage-as-seen-with-ripe-atlas
Насколько я помню, кто-то сделал L2 кольцо на 100G. Никакие костыли включая arp sponge не помогли. Вот он, изначально порочный дизайн, от которого невозможно отказаться и который обязательно время от времени приводит к факапам. С другой стороны есть ivi.ru, которые имеют возможность вообще всё на L3 сделать. Зачем советовать им сделать всё хуже?
>Если нужна безопасность, можно еще посмотреть в сторону distributed firewall via BGP flow-spec :)
Однажды Cloudflare посмотрел.
https://blog.cloudflare.com/todays-outage-post-mortem-82515/
Безопасность там конечно есть, но так себе. От флуда не защитит — политики применяются только внутри сети. Грохнуть нехорошую по мнению IDS сессию можно, только все равно нужен IDS для наблюдения за трафиком, и реакция будет запоздалой. Если защищаемся в первую очередь от внешних атак, то все-таки установленные на периметре файрволы покруче будут. Однако, надо обеспечить симметрию трафика. Тут есть разные варианты. Самым забавным мне показался дизайн кластера ASA 5585-X. Делается один большой port-channel, на 8 линков например. Каждый линк смотрит на отдельную ASA. За счет выставления одинакового механизма хеширования прямой и обратный трафик будут ходить симметрично. Если линк сдохнет, то сессии может раскидать по чужим файрволам, но state информация реплицируется, из влияния на сервис будет лишь небольшое снижение производительности перепрыгнувших на другой узел потоков из-за необходимости прыгать через мастер.
Угу. Вы там городили велосипед с квадратными колесами в виде петли Мёбиуса зачем-то, от непонимания куда более простых и давно проверенных дизайнов…
Проблема у них кстати ровно та же, что я описывал:
«Переходные процессы одного сервера (включение в кластер или исключение) влияют на весь кластер. Ведь роутер ничего не знает о серверах – он думает, что имеет дело с роутерами и каналами. Соответственно, все соединения распределяются на все доступные каналы. Никакого server-affinity. В результате при выключении сервера все соединения перетасовываются между всеми оставшимися серверами. И все активные TCP-сессий разрываются»
Но так как пользуется сервисом одно конкретное приложение, и это приложение запросто переживает разрыв сессии, этот дизайн работает. Повторяю: очень специфический дизайн, с кучей критических недостатков, неспособный работать в общем случае.
> Тот же сервис по защите от DDoS атак Qrator использует BGP Anycast подход (коим защищен сам habrahabr.ru)
Это не внутри ЦОДа, а между ЦОДами :) В случае DDOS такой подход разумен, так как не позволяет сконцентрировать атаку на единой точке входа, ну и провайдеры тоже рады уменьшению внешнего трафика. И DDOS — экстремальная ситуация, где «немного страдает сервис» предпочтительнее, чем «сервиса нет вообще».
>Я бы порекомендовал смотреть в сторону дизайна аля IX
Дизайн аля IX, где используется обширный L2 сегмент — безусловное зло. Но у IX-то вариантов особых и нет, приходится так делать, замена next hop добавила бы немерено головной боли.
https://chi.ams-ix.net/technical--7/specifications-descriptions/port-security-at-ams-ix
https://labs.ripe.net/Members/kistel/the-ams-ix-outage-as-seen-with-ripe-atlas
Насколько я помню, кто-то сделал L2 кольцо на 100G. Никакие костыли включая arp sponge не помогли. Вот он, изначально порочный дизайн, от которого невозможно отказаться и который обязательно время от времени приводит к факапам. С другой стороны есть ivi.ru, которые имеют возможность вообще всё на L3 сделать. Зачем советовать им сделать всё хуже?
>Если нужна безопасность, можно еще посмотреть в сторону distributed firewall via BGP flow-spec :)
Однажды Cloudflare посмотрел.
https://blog.cloudflare.com/todays-outage-post-mortem-82515/
Безопасность там конечно есть, но так себе. От флуда не защитит — политики применяются только внутри сети. Грохнуть нехорошую по мнению IDS сессию можно, только все равно нужен IDS для наблюдения за трафиком, и реакция будет запоздалой. Если защищаемся в первую очередь от внешних атак, то все-таки установленные на периметре файрволы покруче будут. Однако, надо обеспечить симметрию трафика. Тут есть разные варианты. Самым забавным мне показался дизайн кластера ASA 5585-X. Делается один большой port-channel, на 8 линков например. Каждый линк смотрит на отдельную ASA. За счет выставления одинакового механизма хеширования прямой и обратный трафик будут ходить симметрично. Если линк сдохнет, то сессии может раскидать по чужим файрволам, но state информация реплицируется, из влияния на сервис будет лишь небольшое снижение производительности перепрыгнувших на другой узел потоков из-за необходимости прыгать через мастер.
«Переходные процессы одного сервера (включение в кластер или исключение) влияют на весь кластер. Ведь роутер ничего не знает о серверах – он думает, что имеет дело с роутерами и каналами. Соответственно, все соединения распределяются на все доступные каналы. Никакого server-affinity. В результате при выключении сервера все соединения перетасовываются между всеми оставшимися серверами. И все активные TCP-сессий разрываются»
Да, да, да — это мы уже обсудили. И я тогда Вам сказал, что если application это допускает, то это зло с которым можно мириться, а при наличии кастомных TCP/IP стеков (типа Trickless — www.cs.cornell.edu/w8/~ashieh/trickles/trickles-paper/stcp.html), эту проблему можно нивилировать. Собственно, мое мнение по данному поводу не поменялось и как уже было сказано ранее (как с вашей стороны, так и с моей), надо смотреть на приложения.
Дизайн аля IX, где используется обширный L2 сегмент — безусловное зло. Но у IX-то вариантов особых и нет, приходится так делать, замена next hop добавила бы немерено головной боли.
Насколько я помню, кто-то сделал L2 кольцо на 100G. Никакие костыли включая arp sponge не помогли. Вот он, изначально порочный дизайн, от которого невозможно отказаться и который обязательно время от времени приводит к факапам. С другой стороны есть ivi.ru, которые имеют возможность вообще всё на L3 сделать. Зачем советовать им сделать всё хуже?
Well it's depends. Призимлить 1000 BGP сессий на одну коробку, может быть не меньшим злом. Trade-in/trade-off. Многое зависит от железа, кроме того… многое зависит от размера L2 домена и степени оптимизации. Вот тот же гугл пошел иначе (чтобы не городить огород), они просто запили свой IGP с лунопарком (в том числе из-за link-based server autodiscovery). Статья по теме clos topology (а это имеет прямое отношение к anycast ECMP based внутри площадки) SIGCOMM Google — Jupiter Rising — conferences.sigcomm.org/sigcomm/2015/pdf/papers/p183.pdf
Однажды Cloudflare посмотрел.
blog.cloudflare.com/todays-outage-post-mortem-82515
And?
Безопасность там конечно есть, но так себе. От флуда не защитит — политики применяются только внутри сети. Грохнуть нехорошую по мнению IDS сессию можно, только все равно нужен IDS для наблюдения за трафиком, и реакция будет запоздалой. Если защищаемся в первую очередь от внешних атак, то все-таки установленные на периметре файрволы покруче будут. Однако, надо обеспечить симметрию трафика. Тут есть разные варианты. Самым забавным мне показался дизайн кластера ASA 5585-X. Делается один большой port-channel, на 8 линков например. Каждый линк смотрит на отдельную ASA. За счет выставления одинакового механизма хеширования прямой и обратный трафик будут ходить симметрично. Если линк сдохнет, то сессии может раскидать по чужим файрволам, но state информация реплицируется, из влияния на сервис будет лишь небольшое снижение производительности перепрыгнувших на другой узел потоков из-за необходимости прыгать через мастер.
У CCL кластера есть один большой минус — shared control-plane (а это значит shared failure domain). Приведу пример с Juniper'ом (кстати опять же, полностью резервированная коробка:
For non-TX Matrix routing platforms, the router will continue to operate normally. However, the additional load imposed when the backup Routing Engine reboots and resynchronizes its routing database could represent a Denial-of-Service. The backup RE will continue to crash, reboot, and resynchronize as long as the route with the invalid NEXT_HOP is installed in the active RE's database.
For TX-Matrix platforms, all active and backup REs in all LCCs will continuously crash, reboot, and resynchronize. The LCC Packet Forwarding Engines will also reboot due to loss of communications with the Routing Engines. This will result in a complete loss of forwarding on TX-Matrix platforms.
kb.juniper.net/InfoCenter/index?page=content&id=JSA10387
Феерично? И это вся из себя сегментированная ОС JunOS. Припоминаете слова про IPC внутри коробки? ;-)
PPS: CCL Cluster имеет ряд особенностей, часть функционала все равно отрабатывает на master nod'е
>И я тогда Вам сказал, что если application это допускает, то это зло с которым можно мириться
Не… Вы доказывали, что это хорошо работает именно в общем случае. Я говорил, что это почти никогда не работает хорошо. Ну благодаря мне вы узнали, что не все дизайны применимы во всех условиях. Пожалуйста.
>Статья по теме clos topology (а это имеет прямое отношение к anycast ECMP based внутри площадки)
Вы снова путаете понятия — ECMP и anycast. ECMP используется повсеместно, anycast — почти нигде, это удел единичных организаций даже в рамках глобальной маршрутизации. А что clos отличная топология никто и не спорит. Ориентирована как раз на L3, как вариант — костыли вроде TRILL.
>And?
Да просто для понимания возможных рисков.
>У CCL кластера есть один большой минус — shared control-plane (а это значит shared failure domain).
Разумеется. Зато огромная производительность и приличная функциональность. Ну серьезно, отсутствие файрвола на периметре — паршивая идея, он нужен. В нарисованных в топике топологиях flowspec вообще никаким боком, нет в нем смысла, если точки фильтрации считаются по пальцам одной руки. Вот если есть огромная сеть с огромным числом точек входа трафика и асимметрией — другой разговор. Та же циска (огромная транснациональная контора с жутким бардаком) у себя не развернула flowspec, но использует BGP блэкхолинг плохих узлов внутри сети.
>Вполне себе живой дизайн, опять же этот пост тому пример.
Это — уникальный и чуть ли не единственный случай, когда этот дизайн может работать.
>Типичный сетап раздающей ноды Netflix у оператора — два cisco asr 9000 + два коммутатора nexus + n кэширующих серверов.
Я ничего не путаю, вроде бы Netflix фактически то же самое, что и ivi? :)
>CCL Cluster имеет ряд особенностей, часть функционала все равно отрабатывает на master nod'е
Причем на одном ядре той ноды, верно? Ну ничего, fast path и большинство фич CP распределены, вся нагрузка идет туда. Да и вообще, это был просто пример очень похожего подхода, лишенного тех недостатков, хотя не без своих недостатков.
>А еще забавно, что Вы тогда написали, что вы бы ко мне, как к интегратору не пошли из-за таких решений
Напомню точную цитату: «если бы я обратился к интегратору с просьбой разработать архитектуру, и мне предложили бы нечто вроде сказанного Игорем, то я бы больше не работал с тем интегратором». И напомню, что вы предлагали эту архитектуру для всего включая HTTP (я не про видео), говоря, что потеря сессии не страшна. Жуть.
Не… Вы доказывали, что это хорошо работает именно в общем случае. Я говорил, что это почти никогда не работает хорошо. Ну благодаря мне вы узнали, что не все дизайны применимы во всех условиях. Пожалуйста.
>Статья по теме clos topology (а это имеет прямое отношение к anycast ECMP based внутри площадки)
Вы снова путаете понятия — ECMP и anycast. ECMP используется повсеместно, anycast — почти нигде, это удел единичных организаций даже в рамках глобальной маршрутизации. А что clos отличная топология никто и не спорит. Ориентирована как раз на L3, как вариант — костыли вроде TRILL.
>And?
Да просто для понимания возможных рисков.
>У CCL кластера есть один большой минус — shared control-plane (а это значит shared failure domain).
Разумеется. Зато огромная производительность и приличная функциональность. Ну серьезно, отсутствие файрвола на периметре — паршивая идея, он нужен. В нарисованных в топике топологиях flowspec вообще никаким боком, нет в нем смысла, если точки фильтрации считаются по пальцам одной руки. Вот если есть огромная сеть с огромным числом точек входа трафика и асимметрией — другой разговор. Та же циска (огромная транснациональная контора с жутким бардаком) у себя не развернула flowspec, но использует BGP блэкхолинг плохих узлов внутри сети.
>Вполне себе живой дизайн, опять же этот пост тому пример.
Это — уникальный и чуть ли не единственный случай, когда этот дизайн может работать.
>Типичный сетап раздающей ноды Netflix у оператора — два cisco asr 9000 + два коммутатора nexus + n кэширующих серверов.
Я ничего не путаю, вроде бы Netflix фактически то же самое, что и ivi? :)
>CCL Cluster имеет ряд особенностей, часть функционала все равно отрабатывает на master nod'е
Причем на одном ядре той ноды, верно? Ну ничего, fast path и большинство фич CP распределены, вся нагрузка идет туда. Да и вообще, это был просто пример очень похожего подхода, лишенного тех недостатков, хотя не без своих недостатков.
>А еще забавно, что Вы тогда написали, что вы бы ко мне, как к интегратору не пошли из-за таких решений
Напомню точную цитату: «если бы я обратился к интегратору с просьбой разработать архитектуру, и мне предложили бы нечто вроде сказанного Игорем, то я бы больше не работал с тем интегратором». И напомню, что вы предлагали эту архитектуру для всего включая HTTP (я не про видео), говоря, что потеря сессии не страшна. Жуть.
Не… Вы доказывали, что это хорошо работает именно в общем случае. Я говорил, что это почти никогда не работает хорошо. Ну благодаря мне вы узнали, что не все дизайны применимы во всех условиях. Пожалуйста.
Специально подлинковал ведь топик ;) я сказал, если приложение допускает. Проспись и гонор сбавь. Там все написано.
Вы снова путаете понятия — ECMP и anycast. ECMP используется повсеместно, anycast — почти нигде, это удел единичных организаций даже в рамках глобальной маршрутизации. А что clos отличная топология никто и не спорит. Ориентирована как раз на L3, как вариант — костыли вроде TRILL.
Скажем так. Я не путаю ECMP и Anycast, когда кажется, креститься надо. Топология Клоза хорошо ложиться на дизайн с ECMP и Anycast, и мы этот вопрос тогда еще разбирали на примере с графами (а это пример очень даже работает в условиях торологии Клоза).
Остальное комментировать лень.
>я сказал, если приложение допускает.
А ссылку можно? Особенно интересно, в какой момент беседы это появилось… А какие еще приложения это допускают? Где хотя бы этот пример, чтобы фантазии о доставке трафика до серверов посредством anycast перестали быть фантазиями и базировались на реальных задачах? Не было же ничего. Было просто непонимание самой задачи и основных граблей с твоей стороны. Какие-то пионерские, оторванные от реальности идеи, «а давайте вот эдак сделаем».
>Топология Клоза хорошо ложиться на дизайн с ECMP и Anycast
Она в L2 плохо ложится, а выше я видел предложение забабахать большущий L2 сегмент по аналогии с тем, от чего все IX плюются :) А clos — это дело десятое. Классическая архитектура с уровнем ядра (два устройства) и агрегации/доступа тоже в каком-то смысле подвид clos, просто с двумя spine узлами. Таким образом сети строились не один десяток лет назад. Главное в той топологии — симметрия и задействование всех линков.
А ссылку можно? Особенно интересно, в какой момент беседы это появилось… А какие еще приложения это допускают? Где хотя бы этот пример, чтобы фантазии о доставке трафика до серверов посредством anycast перестали быть фантазиями и базировались на реальных задачах? Не было же ничего. Было просто непонимание самой задачи и основных граблей с твоей стороны. Какие-то пионерские, оторванные от реальности идеи, «а давайте вот эдак сделаем».
>Топология Клоза хорошо ложиться на дизайн с ECMP и Anycast
Она в L2 плохо ложится, а выше я видел предложение забабахать большущий L2 сегмент по аналогии с тем, от чего все IX плюются :) А clos — это дело десятое. Классическая архитектура с уровнем ядра (два устройства) и агрегации/доступа тоже в каком-то смысле подвид clos, просто с двумя spine узлами. Таким образом сети строились не один десяток лет назад. Главное в той топологии — симметрия и задействование всех линков.
А ссылку можно?
Можно. — habrahabr.ru/company/beeline/blog/207162
Поехали:
Ваш комментарий:
ссылка: habrahabr.ru/company/beeline/blog/207162/#comment_7142924
Циатата:
Крайне болезненные и ввод, и вывод серверов из эксплуатации. Любое изменение может изменить и результат хеширования, перераскидав соединения по другим серверам. Нельзя сказать «не принимать новых соединений на вон тот сервер, но старые с session persistence пусть доработают».
Мой ответ:
В случаях с web application (да и в большинстве других случаях) — это необязательно.
sic! в большинстве других случаях != (читай не равно) все случаи
Далее, начинаешь доказывать:
Ссылка — habrahabr.ru/company/beeline/blog/207162/#comment_7144176
«В случае веб-приложений session persistence как раз огромная тема. Обычно решается куками.»
Ответ:
ОООоооо. Без комментариев. Внимательный читатель сделает соответствующие выводы.
Чуть позже, понимая, что ты не понимаешь этот вопрос, я тебе уже начал разжевывать. Процитирую:
Тоже аргумент кстати. Вот человека кинуло на сервер, он аутентифицировался. Дальше вы добавили в ECMP новый сервер, того человека перекинуло на новый сервер, и он должен заново аутентифицироваться? Это ли не кошмар?
Нет, не кошмар. Приведу пример.
Раз:
BlackBox:~ XXXXX$ nslookup www.gmail.com
Server: XXX.XXX.XXX.XXX
Address: XXX.XXX.XXX.XXX#53
Non-authoritative answer:
www.gmail.com canonical name = mail.google.com.
mail.google.com canonical name = googlemail.l.google.com.
Name: googlemail.l.google.com
Address: 173.194.71.83
Name: googlemail.l.google.com
Address: 173.194.71.18
Name: googlemail.l.google.com
Address: 173.194.71.17
Name: googlemail.l.google.com
Address: 173.194.71.19
Два:
Я авторизовался на сервере Gmail и поставил галочку — запомнить меня.
Три:
Через три дня открыл свой компьютер, зашел на Gmail без авторизации, попав на один из четырех IP адресов.
Так вот, с точки зрения сервиса, я авторизовался ранее и сервис об этом знает, ибо у него есть информация о auth token. В distribution application или distribution services эти вопросы лежат на плечах backend процессов, коим обычно выступает СУБД.
И в конце концов, ответил:
У Вас опять разыгралось воображение? Есть SLA и требования, если что-то укладывается в эти требования (например потеря одного — двух пакетов или единичный разрыв сессии), то в рамках SLA такая ситуация считается нормальной. И как я уже сказал ранее, защита от подобных инцидентов может быть предусмотрена в программном обеспечении, таким образом если ПО легко справляется с подобного рода проблемой и без видимых проблем для пользователя, то это не является препятствием. В любых других ситуациях, изыскиваются варианты, которые устраивают обе стороны и без диалога с разработчиком или владельцем бизнеса это не представляется возможным.
Почитайте, освежите память. IVI, хороший пример бизнеса, в котором это работает.
Она в L2 плохо ложится, а выше я видел предложение забабахать большущий L2 сегмент по аналогии с тем, от чего все IX плюются :) А clos — это дело десятое. Классическая архитектура с уровнем ядра (два устройства) и агрегации/доступа тоже в каком-то смысле подвид clos, просто с двумя spine узлами. Таким образом сети строились не один десяток лет назад. Главное в той топологии — симметрия и задействование всех линков.
Я не сказал, что L2 нужно деплоить между маршрутизаторами в clos топологии. Я сказал, процитирую:
«Я бы порекомендовал смотреть в сторону дизайна аля IX. Поставить в серверный сегмент BGP RR (wtih NHOP unchannged). Пиринг с точки зрения BGP инфраструктуры выглядел бы так: router — bgp rr — server.»
Далее возможны варианты, RR per Server Segment или RR per Network.
1. Первый сценарий RR Per Server Segment. Выделяется подсеть на leaf. Не надо поднимать IGP на серверах, проще обслуживание, ибо DHCP + стандартный конфиг + ExaBGP. С точки зрения upstream маршрутизатора NHOP и RR directly connected. Выглядит достаточно просто и здесь ни кто не говорит о том, чтобы затянуть L2 еще выше (например на middle spine). Тот же RR функционал, можно поднять на парочке из серверов.
2. Второй сценарий. RR per Network (читай топологию clos). IGP/BGP или BGP Only Design с сервера (full routed). IGP для сигнализации доступности NHOP'ов, BGP recursive routes. И в том и в другом случае BGP нужно держать везде. IGP теоретически может упростить discovery и provisioning процессы, но не факт, что является оптимальным вариантом. Тот же Microsoft/Facebook, предпочитают BGP IP Fabric.
Как видишь, я не предлагаю деплоить full L2 тополгию Клоза.
Спасибо. Пожалуйста. До свиданья.
Поехали.
>Ваш комментарий:
Замечу — через существенное время после начала беседы.
>В случаях с web application (да и в большинстве других случаях) — это необязательно. sic! в большинстве других случаях != (читай не равно) все случаи
Это совершенно ошибочное представление. Тебе потребовалось целых полтора года, чтобы найти первый и пока единственный пример, где это может работать, а в той беседе примера не было :) Так как раньше тебя окунули носом в лужицу собственного невежества — ты в него и вцепился.
>Через три дня открыл свой компьютер, зашел на Gmail без авторизации, попав на один из четырех IP адресов.
Вот только это не имеет отношения к anycast в пределах площадки и между ними :) Да и в http://habrahabr.ru/company/ivi/blog/240237/#comment_8572237 тебе объяснили про то, как будет работать почта с anycast…
>Я не сказал, что L2 нужно деплоить между маршрутизаторами в clos топологии
Когда архитектура сервиса позволяет вполне забыть про L2 между более чем двумя узлами — какой смысл возвращаться к L2? Что конкретно это даст? Какой смысл вообще держать IGP, когда BGP даже по сходимости неотличим от IGP с FRR в рамках озвученной задачи? Зачем было городить какой-то ужас с VRF на сервер как ты ранее предлагал? Посмотри вид топологии у ivi, это же просто сказочная простота.
>Ваш комментарий:
Замечу — через существенное время после начала беседы.
>В случаях с web application (да и в большинстве других случаях) — это необязательно. sic! в большинстве других случаях != (читай не равно) все случаи
Это совершенно ошибочное представление. Тебе потребовалось целых полтора года, чтобы найти первый и пока единственный пример, где это может работать, а в той беседе примера не было :) Так как раньше тебя окунули носом в лужицу собственного невежества — ты в него и вцепился.
>Через три дня открыл свой компьютер, зашел на Gmail без авторизации, попав на один из четырех IP адресов.
Вот только это не имеет отношения к anycast в пределах площадки и между ними :) Да и в http://habrahabr.ru/company/ivi/blog/240237/#comment_8572237 тебе объяснили про то, как будет работать почта с anycast…
>Я не сказал, что L2 нужно деплоить между маршрутизаторами в clos топологии
Когда архитектура сервиса позволяет вполне забыть про L2 между более чем двумя узлами — какой смысл возвращаться к L2? Что конкретно это даст? Какой смысл вообще держать IGP, когда BGP даже по сходимости неотличим от IGP с FRR в рамках озвученной задачи? Зачем было городить какой-то ужас с VRF на сервер как ты ранее предлагал? Посмотри вид топологии у ivi, это же просто сказочная простота.
Замечу — через существенное время после начала беседы.
Без комментариев. Уже небъется с тем, что Вы говорите.
Это совершенно ошибочное представление. Тебе потребовалось целых полтора года, чтобы найти первый и пока единственный пример, где это может работать, а в той беседе примера не было :) Так как раньше тебя окунули носом в лужицу собственного невежества — ты в него и вцепился.
Ага, осталось вспомнить и статику у Яндекса, и Anycast DNS и гугловые примеры.
Вот только это не имеет отношения к anycast в пределах площадки и между ними :) Да и в habrahabr.ru/company/ivi/blog/240237/#comment_8572237 тебе объяснили про то, как будет работать почта с anycast…
Почта через pop3, imap, веб интерфейс по http или https (и другие протоколы) — не одно и тоже. Когда осознаешь, тогда и поговорим.
Когда архитектура сервиса позволяет вполне забыть про L2 между более чем двумя узлами — какой смысл возвращаться к L2? Что конкретно это даст? Какой смысл вообще держать IGP, когда BGP даже по сходимости неотличим от IGP с FRR в рамках озвученной задачи? Зачем было городить какой-то ужас с VRF на сервер как ты ранее предлагал? Посмотри вид топологии у ivi, это же просто сказочная простота.
Скажем так. Нельзя опускать потенциальные подводные камни. Например управление инфраструктурой и масштабируемость. Если говорить про full routed дизайн, то можно упереться в масштабируемость. Не каждая коробка, способна вытянуть 700+ BGP сессий, а как это еще сказывается на сходимости, нужно смотреть и разбирать конкретные кейсы. Очевидно, что нагрузка на control-plane с 2-4 bgp сессиями — меньше, сходиться будет быстрее.
Что касается управляемости, тот тоже не все так просто. Установка нового сервера в кейсе с full routed L3 with BGP, тянет за собой ряд нюансов. Например — назначить подсеть на маршрутизатор и сервер, сконфигурировать BGP пир, навесить полиси и тд и тп. Если мощности постоянно расширяются, это может быть проблемой.
Про IGP я уже сказал. Процитирую еще раз:
IGP теоретически может упростить discovery и provisioning процессы, но не факт, что является оптимальным вариантом.
По-этому, повторюсь еще раз, специально для тебя. Кейсы бывают разные, варианты тоже и в каждой ситуации свой драйвер. Если не понимаешь, продолжай крутить гайки, пастись в заповедниках и тд.
>осталось вспомнить и статику у Яндекса, и Anycast DNS и гугловые примеры.
Следующий шаг — узнай, как именно реализован яндекс статик внутри площадки — думаю, удивишься :) А DNS вообще сравнительно небольшой трафик. Городить под него отдельную архитектуру бессмысленно.
>Почта через pop3, imap, веб интерфейс по http или https (и другие протоколы) — не одно и тоже. Когда осознаешь, тогда и поговорим.
Фраза переводится как «я облажался, так как не понимаю разницы между DNS round robin и anycast».
>Не каждая коробка, способна вытянуть 700+ BGP сессий
А тут можно сообразить, что когда используются RR — можно делать несколько уровней, и не надо никаких сотен сессий :)
>Очевидно, что нагрузка на control-plane с 2-4 bgp сессиями — меньше, сходиться будет быстрее.
А вот тут ощущается некоторое непонимание внутреннего устройства BGP и того, какими факторами определяется сходимость протокола. Еще тут ощущается непонимание того, что такое control plane. Нагрузка на него? Какого рода? Память? Процессор? Скажу по секрету, в типичном случае (хардварный роутер, full view) время перестроения топологии может не упираться ни в ресурсы control plane, ни в таймеры, хотя уже-не-особо-новые фичи более-менее исправляют это :)
>Кейсы бывают разные, варианты тоже и в каждой ситуации свой драйвер
Я тебе это изначально и говорил. Сейчас ты как попугай повторяешь это, но продолжаешь отстаивать точку зрения «мой велосипед с квадратными колесами отлично работает в большинстве случаев» :)
Следующий шаг — узнай, как именно реализован яндекс статик внутри площадки — думаю, удивишься :) А DNS вообще сравнительно небольшой трафик. Городить под него отдельную архитектуру бессмысленно.
>Почта через pop3, imap, веб интерфейс по http или https (и другие протоколы) — не одно и тоже. Когда осознаешь, тогда и поговорим.
Фраза переводится как «я облажался, так как не понимаю разницы между DNS round robin и anycast».
>Не каждая коробка, способна вытянуть 700+ BGP сессий
А тут можно сообразить, что когда используются RR — можно делать несколько уровней, и не надо никаких сотен сессий :)
>Очевидно, что нагрузка на control-plane с 2-4 bgp сессиями — меньше, сходиться будет быстрее.
А вот тут ощущается некоторое непонимание внутреннего устройства BGP и того, какими факторами определяется сходимость протокола. Еще тут ощущается непонимание того, что такое control plane. Нагрузка на него? Какого рода? Память? Процессор? Скажу по секрету, в типичном случае (хардварный роутер, full view) время перестроения топологии может не упираться ни в ресурсы control plane, ни в таймеры, хотя уже-не-особо-новые фичи более-менее исправляют это :)
>Кейсы бывают разные, варианты тоже и в каждой ситуации свой драйвер
Я тебе это изначально и говорил. Сейчас ты как попугай повторяешь это, но продолжаешь отстаивать точку зрения «мой велосипед с квадратными колесами отлично работает в большинстве случаев» :)
Следующий шаг — узнай, как именно реализован яндекс статик внутри площадки — думаю, удивишься :) А DNS вообще сравнительно небольшой трафик. Городить под него отдельную архитектуру бессмысленно.
Anycast может сосуществовать в обычных сетях с более класическими подходами в вопросах маршрутизации трафика, а clos топологии это вообще не проблема. И как уже было сказано ранее, DNS не единственый пример.
Фраза переводится как «я облажался, так как не понимаю разницы между DNS round robin и anycast».
Говорите за себя. И причем здесь DNS round robin? DNS вообще стоит в самом-самом начале, когда еще пользователь только-только хочет попасть на сервис. Этот сервис, как сетевое приложение может функционировать поверх anycast архитектуры. И раз на то пошло, round robin может использоваться для балансировки между двумя разными anycast IP адресами (сегментация anycast сервиса), принадлежащих одному сервису. Опять же, это все из области многоуровневой балансировки на различных этапах взаимодействия пользователя — сервис.
Что касается фразы «почта», я уже сказал, что это слишком обобщенный термин.
А тут можно сообразить, что когда используются RR — можно делать несколько уровней, и не надо никаких сотен сессий :)
А еще можно сделать RR per AFI. Спасибо, я в курсе.
А вот тут ощущается некоторое непонимание внутреннего устройства BGP и того, какими факторами определяется сходимость протокола. Еще тут ощущается непонимание того, что такое control plane. Нагрузка на него? Какого рода? Память? Процессор? Скажу по секрету, в типичном случае (хардварный роутер, full view) время перестроения топологии может не упираться ни в ресурсы control plane, ни в таймеры, хотя уже-не-особо-новые фичи более-менее исправляют это :)
Действительно, вот тут чувствуется некоторые проблемы с BGP у JDima. Открою секрет, что сходимость в BGP определяется не только процессом выбора лучшего маршрута или наличием/отсутствием всяких плюшек вида BGP PIC Edge/Core, но и BGP Finite State Machine (надеюсь этот термин знаком?). На процесс сходимости BGP влияет достаточно много аспектов от производительности CPU и конфигурации, до MTU и количества Adj-RIB-in/Adj-RIB-out.
Я тебе это изначально и говорил. Сейчас ты как попугай повторяешь это, но продолжаешь отстаивать точку зрения «мой велосипед с квадратными колесами отлично работает в большинстве случаев» :)
Изначально ты мне затирал про дизайн с full L2 (о котором, как я уже сказал ранее, речи и не было) и как это плохо, а вот чистый L3 это очень хорошо. На что я тебе указал, что не всегда и везде.
>Anycast может сосуществовать в обычных сетях с более класическими подходами в вопросах маршрутизации трафика
Угу. Например, anycast перестает быть таковым на периметре площадки. Случай Яндекса например.
>И причем здесь DNS round robin?
Это к многократно повторенному nslookup на гмейл. Объяснить, в чем принципиальное отличие от anycast? Ты утверждаешь, что гмейл работает эникастом между локациями и/или внутри локации. Сможешь это доказать?
>Что касается фразы «почта», я уже сказал, что это слишком обобщенный термин.
В обывательском представлении, это вебморда. И ты, кажется, с вебморды начинал. Можно и продолжить. Про IMAP/SMTP сложнее говорить, там куда больше зависит от реализации клиента. Не впадет ли какой-нибудь BAT старой версии в ступор от получения RST? Все ли MTA перепошлют письмо? Не думаю, что тут вообще имеет смысл говорить об anycast, тем более что трафик там не такой существенный, как у веба.
>сходимость в BGP определяется не только процессом выбора лучшего маршрута или наличием/отсутствием всяких плюшек вида BGP PIC Edge/Core, но и BGP Finite State Machine (надеюсь этот термин знаком?).
Очень плохой ответ. Тебе этот термин совершенно непонятен, иначе ты знал бы, что всё указанное в первой половине предложения («выбор лучшего маршрута» особенно) фактически входит в понятие FSM, потому утверждение лишено смысла. В одном состоянии автомата происходит scan, на другом программируется TCAM.
Дам наводку на то, как узнать правильный ответ. Перечисли основные этапы сходимости (что конкретно происходит с процессом, когда что-то в сети меняется?) и заодно выясни, какие из них в типовой реализации происходят параллельно. Еще узнай, на что конкретно влияет добавление нового соседа (ты так и не сказал, что за ресурсы control plane тратятся, не говоря уже «на что тратятся»). Вдруг окажется, что всё не так плохо и число соседей само по себе почти никакого значения не имеет, только число событий в единицу времени, число различных примененных к ним политик и тому подобное?
А дальше можно будет перейти к практике использования BGP в реальных сетях. Тысячу соседств даже EIGRP легко переварит на более-менее современной платформе, если всё сделать правильно (из опыта говорю). В случае BGP одна коробка осилит десятки тысяч соседств. Ну а простейший пример сценария, где такое может потребоваться — DMVPN.
>Изначально ты мне затирал про дизайн с full L2
Конечно. Ты же приводишь IX в качестве примера хорошего дизайна — а там речь всегда про L2. Но даже они не считают это хорошим дизайном. Вот Amazon например не имеет L2 и благодаря этому почти не падает :)
Угу. Например, anycast перестает быть таковым на периметре площадки. Случай Яндекса например.
>И причем здесь DNS round robin?
Это к многократно повторенному nslookup на гмейл. Объяснить, в чем принципиальное отличие от anycast? Ты утверждаешь, что гмейл работает эникастом между локациями и/или внутри локации. Сможешь это доказать?
>Что касается фразы «почта», я уже сказал, что это слишком обобщенный термин.
В обывательском представлении, это вебморда. И ты, кажется, с вебморды начинал. Можно и продолжить. Про IMAP/SMTP сложнее говорить, там куда больше зависит от реализации клиента. Не впадет ли какой-нибудь BAT старой версии в ступор от получения RST? Все ли MTA перепошлют письмо? Не думаю, что тут вообще имеет смысл говорить об anycast, тем более что трафик там не такой существенный, как у веба.
>сходимость в BGP определяется не только процессом выбора лучшего маршрута или наличием/отсутствием всяких плюшек вида BGP PIC Edge/Core, но и BGP Finite State Machine (надеюсь этот термин знаком?).
Очень плохой ответ. Тебе этот термин совершенно непонятен, иначе ты знал бы, что всё указанное в первой половине предложения («выбор лучшего маршрута» особенно) фактически входит в понятие FSM, потому утверждение лишено смысла. В одном состоянии автомата происходит scan, на другом программируется TCAM.
Дам наводку на то, как узнать правильный ответ. Перечисли основные этапы сходимости (что конкретно происходит с процессом, когда что-то в сети меняется?) и заодно выясни, какие из них в типовой реализации происходят параллельно. Еще узнай, на что конкретно влияет добавление нового соседа (ты так и не сказал, что за ресурсы control plane тратятся, не говоря уже «на что тратятся»). Вдруг окажется, что всё не так плохо и число соседей само по себе почти никакого значения не имеет, только число событий в единицу времени, число различных примененных к ним политик и тому подобное?
А дальше можно будет перейти к практике использования BGP в реальных сетях. Тысячу соседств даже EIGRP легко переварит на более-менее современной платформе, если всё сделать правильно (из опыта говорю). В случае BGP одна коробка осилит десятки тысяч соседств. Ну а простейший пример сценария, где такое может потребоваться — DMVPN.
>Изначально ты мне затирал про дизайн с full L2
Конечно. Ты же приводишь IX в качестве примера хорошего дизайна — а там речь всегда про L2. Но даже они не считают это хорошим дизайном. Вот Amazon например не имеет L2 и благодаря этому почти не падает :)
Очень плохой ответ. Тебе этот термин совершенно непонятен, иначе ты знал бы, что всё указанное в первой половине предложения («выбор лучшего маршрута» особенно) фактически входит в понятие FSM, потому утверждение лишено смысла. В одном состоянии автомата происходит scan, на другом программируется TCAM.
Epic fail. Вот ты и показал свои знания BGP и вообще. BGP FSM и BGP Best Path Selection Algorigthm это не одно и то же. BGP FSM определяет процедуру установки соединения между BGP спикерами и не имеет какого либо отношения к BGP Best Path Selection Alorightm. Так на секундучку, BGP FSM вполне себе стандартизирован, чего нельзя сказать про BGP Best Path Selection Algorithm, который у каждого вендора может иметь свою реализацию (у Juniper и Cisco они отличаются).
Вот тебе краткое описание, что такое BGP FSM.
BGP peers transition through several states before becoming adjacent neighbors and exchanging routing information. During each of the states, the peers must send and receive messages, process message data, and initialize resources before proceeding to the next state. This process is known as the BGP Finite-State Machine (FSM).
А вот тебе схема BGP FSM:
А вот тебе описание BGP Best Path Selection Algorithm у Cisco:
www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html
Как видишь, BGP Best Path Selection Algorithm, ни разу не входит в BGP FSM и отрабатывает гораздо раньше.
Далее в конфигурациях по-умолчанию, каждому BGP Speaker отводится свои Adj-RIB-In и Adj-RIB-Out. Adj-RIB-in содержит маршрутную информацию, которая была получена от спикера/соседа, Adj-RIB-out содержит маршрутную информацию, которую нужно отправить спикеру/соседу. И связано это с наличием развитых механизмов фильтрации и манипуляции маршрутной информацией в BGP. Фактически, чем больше количество speaker'ов, тем больше будут занимать места в памяти различные версии БД Adj-RIB-in/Adj-RIB-out. Надо ли мне говорить, что это один из ключевых факторов в условиях масштабируемости BGP по количеству соседей? И надо ли мне акцентировать внимание на таких вещях, как передача маршрутной информации между этим БД в программной архитектуре и какую при этом нагрузку создает на control-plane? Ты лучше задумайся над тем, почему peer-group (и чем эта фича отличается от peer-template) не во всех случаях можно использовать. Вот тебе пара картинок на подумать:
Далее относительно программирования TCAM. TCAM программировать (читай сгружать маршруты в FIB) не всегда обязательно (и опять же это можно сконфигурировать) и зависит от кейсов, а вот сходимость это улучшает в разы. И чтобы ты понимал, речь идет о кейсах с BGP RR «с боку», который ни как не участвует в forwarding'е трафика (ибо by default для iBGP NHOP unchanged) и используется лишь для сигнализации маршрутной информации.
Так что не надо мне рассказывать про то, что такое bgp scanner, как он влияет на сходимость, какие у него таймеры и как это аффектит загрузку CPU на маршрутизаторах. Ок?
В случае BGP одна коробка осилит десятки тысяч соседств.
Еще один epic fail. Очевидно, что это не бьется с тем, что я сказал про adj-rib-in/adj-rib-out и производительностью tcp/ip стэка в control-plane маршрутизаторе. Более того, у Cisco (как и у любого другого вендора) есть вполне конкретные цифры по масштабируемости с точки зрения количества bgp соседей.
Нахватался верхушек, слышишь звон, но не знаешь где он. Короче — рука/лицо.
В общем остальное обсуждать с тобой не имеет смысла. Разговор закрыт.
>Вот ты и показал свои знания BGP и вообще. BGP FSM и BGP Best Path Selection Algorigthm это не одно и то же. BGP FSM определяет процедуру установки соединения между BGP спикерами
Сколько ты слов интересных вычитал — «best path»…
FSM — конечный автомат. Список состояний, в которых может быть процесс, и переходов между ними. Список несколько обширнее, чем ты думаешь — http://www.informit.com/library/content.aspx?b=CCIE_Practical_Studies_II&seqNum=79 например.
А откуда ты взял best path selection — вообще не понимаю. На глаза попалось знакомое слово scanner? :)
>Фактически, чем больше количество speaker'ов, тем больше будут занимать места в памяти различные версии БД Adj-RIB-in/Adj-RIB-out. Надо ли мне говорить, что это один из ключевых факторов в условиях масштабируемости BGP по количеству соседей?
Снова полное невежество.
В случае циски давно есть оптимизация, называемая dynamic update groups. Фактически все нейборы, на которых применяется одинаковая политика, попадают в одну группу и апдейты вычисляются один раз на всех. Когда-то давно ты мог читать в книжках, что если объединять нейборов в peer-groups, то можно нехило ресурсов сэкономить — уже много лет этот совет неактуален, то же самое выполняется автоматически где можно. И на самом деле стыдно этого не знать.
>Очевидно, что это не бьется с тем, что я сказал про adj-rib-in/adj-rib-out и производительностью tcp/ip стэка в control-plane маршрутизаторе.
Не бьется, потому что ты написал какую-то чушь.
>Более того, у Cisco (как и у любого другого вендора) есть вполне конкретные цифры по масштабируемости с точки зрения количества bgp соседей.
Ага. Навскидку, из того, что первым нашел — http://d2zmdbbm9feqrf.cloudfront.net/2013/usa/pdf/BRKSEC-4054.pdf, 15-я страница. Это не просто соседство по IGP/BGP. Это еще isakmp/ipsec SA и NHRP.
Почему тебе настолько яростно хочется хоть кому-то доказать, что ты хоть в чем-то прав?
Сколько ты слов интересных вычитал — «best path»…
FSM — конечный автомат. Список состояний, в которых может быть процесс, и переходов между ними. Список несколько обширнее, чем ты думаешь — http://www.informit.com/library/content.aspx?b=CCIE_Practical_Studies_II&seqNum=79 например.
А откуда ты взял best path selection — вообще не понимаю. На глаза попалось знакомое слово scanner? :)
>Фактически, чем больше количество speaker'ов, тем больше будут занимать места в памяти различные версии БД Adj-RIB-in/Adj-RIB-out. Надо ли мне говорить, что это один из ключевых факторов в условиях масштабируемости BGP по количеству соседей?
Снова полное невежество.
В случае циски давно есть оптимизация, называемая dynamic update groups. Фактически все нейборы, на которых применяется одинаковая политика, попадают в одну группу и апдейты вычисляются один раз на всех. Когда-то давно ты мог читать в книжках, что если объединять нейборов в peer-groups, то можно нехило ресурсов сэкономить — уже много лет этот совет неактуален, то же самое выполняется автоматически где можно. И на самом деле стыдно этого не знать.
>Очевидно, что это не бьется с тем, что я сказал про adj-rib-in/adj-rib-out и производительностью tcp/ip стэка в control-plane маршрутизаторе.
Не бьется, потому что ты написал какую-то чушь.
>Более того, у Cisco (как и у любого другого вендора) есть вполне конкретные цифры по масштабируемости с точки зрения количества bgp соседей.
Ага. Навскидку, из того, что первым нашел — http://d2zmdbbm9feqrf.cloudfront.net/2013/usa/pdf/BRKSEC-4054.pdf, 15-я страница. Это не просто соседство по IGP/BGP. Это еще isakmp/ipsec SA и NHRP.
Почему тебе настолько яростно хочется хоть кому-то доказать, что ты хоть в чем-то прав?
А откуда ты взял best path selection — вообще не понимаю. На глаза попалось знакомое слово scanner? :)
Процитирую:
Тебе этот термин совершенно непонятен, иначе ты знал бы, что всё указанное в первой половине предложения («выбор лучшего маршрута» особенно) фактически входит в понятие FSM
Тебе еще осталось понять, что такое термины «сходимость» и «сокорость сходимости».
Снова полное невежество.
В случае циски давно есть оптимизация, называемая dynamic update groups. Фактически все нейборы, на которых применяется одинаковая политика, попадают в одну группу и апдейты вычисляются один раз на всех. Когда-то давно ты мог читать в книжках, что если объединять нейборов в peer-groups, то можно нехило ресурсов сэкономить — уже много лет этот совет неактуален, то же самое выполняется автоматически где можно. И на самом деле стыдно этого не знать.
О ты таки прочитал, что такое peer-group и peer template! Вот только прикидываться слепым не хорошо. Пожалуй еще раз процитирую, то что сказал ранее:
Ты лучше задумайся над тем, почему peer-group (и чем эта фича отличается от peer-template) не во всех случаях можно использовать.
Кстати, написано было именно в нужном контексте.
А вообще, глядишь такими темпами ты скоро узнаешь про то, как tcp mss влияет на BGP и в каких случаях используется bgp neighbor transport connection-mode active/passive.
Цитата:
О сколько нам открытий чудных.
Готовит просвещенья дух.
Пушкин
Не бьется, потому что ты написал какую-то чушь.
А что еще я написал? :-)
Ага. Навскидку, из того, что первым нашел — d2zmdbbm9feqrf.cloudfront.net/2013/usa/pdf/BRKSEC-4054.pdf, 15-я страница. Это не просто соседство по IGP/BGP. Это еще isakmp/ipsec SA и NHRP.
Ага, ну прям десятки тысяч пиров с сотнями тысяч маршрутов :-)))
Почему тебе настолько яростно хочется хоть кому-то доказать, что ты хоть в чем-то прав?
Прое́кция (лат. projectio — бросание вперед) — психологический процесс, относимый к механизмам психологической защиты, в результате которого внутреннее ошибочно воспринимается как приходящее извне[1]. Человек приписывает кому-то или чему-то собственные мысли, чувства, мотивы, черты характера и пр., полагая, что он воспринял что-то приходящее извне, а не изнутри самого себя.
Оригинал — ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_(%D0%BF%D1%81%D0%B8%D1%85%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F)
>Процитирую:
А тут тебе почему-то померещилось, что я писал о конкретном алгоритме best path selection. Надеюсь, не надо объяснять, что в том или ином виде он есть у всех? :)
>Ты лучше задумайся над тем, почему peer-group (и чем эта фича отличается от peer-template) не во всех случаях можно использовать.
Так я же и объясняю, что у циски peer-group уже не дает выигрыша ни в чем кроме конфигурения, процесс создания апдейт-групп автоматический по дефолту, и даже документировано, в каких случаях оно работает (фактически, если нет исходящего роут-мапа — всё хорошо, остальные варианты не особо реалистичны).
>А вообще, глядишь такими темпами ты скоро узнаешь про то, как tcp mss влияет на BGP и в каких случаях используется bgp neighbor transport connection-mode active/passive.
Это начинает утомлять. Ты снова бросаешься словами, смысла которых не понимаешь, как будто открыл command reference и читаешь все интересно звучащие названия. Ну какие к чертовой матери несовпадения MTU внутри сети? За такое архитектору зубы выдирают без обезболивания. Мы обсуждали более-менее конкретный сценарий, и в нем все критерии для включения в update-group будут выполнены. И в случае DMVPN у всех будет одинаковый MTU.
>Ага, ну прям десятки тысяч пиров с сотнями тысяч маршрутов
В этом случае единицы тысяч, с кучей обвесов в виде других протоколов. Ты утверждал, что даже несколько сотен в простейшей схеме — ничего хорошего.
>Прое́кция
То есть это я спустя полтора года полтора года вспомнил про то, как меня посадили в лужу и инициировал повторное перебрасывание какашками в попытке отыграться, но снова сел в лужу на базовых вещах? :)
А тут тебе почему-то померещилось, что я писал о конкретном алгоритме best path selection. Надеюсь, не надо объяснять, что в том или ином виде он есть у всех? :)
>Ты лучше задумайся над тем, почему peer-group (и чем эта фича отличается от peer-template) не во всех случаях можно использовать.
Так я же и объясняю, что у циски peer-group уже не дает выигрыша ни в чем кроме конфигурения, процесс создания апдейт-групп автоматический по дефолту, и даже документировано, в каких случаях оно работает (фактически, если нет исходящего роут-мапа — всё хорошо, остальные варианты не особо реалистичны).
>А вообще, глядишь такими темпами ты скоро узнаешь про то, как tcp mss влияет на BGP и в каких случаях используется bgp neighbor transport connection-mode active/passive.
Это начинает утомлять. Ты снова бросаешься словами, смысла которых не понимаешь, как будто открыл command reference и читаешь все интересно звучащие названия. Ну какие к чертовой матери несовпадения MTU внутри сети? За такое архитектору зубы выдирают без обезболивания. Мы обсуждали более-менее конкретный сценарий, и в нем все критерии для включения в update-group будут выполнены. И в случае DMVPN у всех будет одинаковый MTU.
>Ага, ну прям десятки тысяч пиров с сотнями тысяч маршрутов
В этом случае единицы тысяч, с кучей обвесов в виде других протоколов. Ты утверждал, что даже несколько сотен в простейшей схеме — ничего хорошего.
>Прое́кция
То есть это я спустя полтора года полтора года вспомнил про то, как меня посадили в лужу и инициировал повторное перебрасывание какашками в попытке отыграться, но снова сел в лужу на базовых вещах? :)
А тут тебе почему-то померещилось, что я писал о конкретном алгоритме best path selection. Надеюсь, не надо объяснять, что в том или ином виде он есть у всех? :)
Извини, но выбор лучшего маршрута связан с реализацией BGP Best Path Algorithm и как я уже сказал ранее, не имеет какого-либо отношения к BGP FSM (который кстати не является частью процесса BGP Scanner, а скорее имеет отношение к процессу BGP Open). Более того, если возвращаться к процессу BGP Scanner, то это вообще особенности конкретной программной реализации (в данном случае Cisco IOS) и не факт, что в другой реализации (например у Juniper или Alcatel) он будет иметь аналогичную архитектуру программного кода (взять тот же процесс BGP Speaker в Cisco IOS XR).
Вот тебе пруф для Cisco IOS — www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/107615-highcpu-bgp.html#understandbgp
BGP Open Performs BGP peer establishment. At initialization, when establishing a TCP connection with a BGP peer.
BGP I/O Handles queueing and processing of BGP packets, such as UPDATES and KEEPALIVES. As BGP control packets are received.
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 Router Calculates the best BGP path and processes any route «churn». It also sends and receives routes, establishes peers, and interacts with the routing information base (RIB). Once per second and when adding, removing, or soft-reconfiguring a BGP peer.
И как принято говорить в таких случаях: «дьявол кроется в деталях», — а конкретно в данном случае — в нюансах связанных с программно-аппаратной реализацией. Опять же, если говорить про ссылку, которую ты привел ранее с упоминанием про isakmp, то это далеко не показатель. Тот же IPSec (шифрование) частично оффлоудится на QFP (читай hardware assist), а согласование и повторная аутентификация не происходят каждые 60 секунд. Я тебе тогда сказал и сейчас еще раз скажу — оставь свой менторский тон, для других. Ок?
Так я же и объясняю, что у циски peer-group уже не дает выигрыша ни в чем кроме конфигурения, процесс создания апдейт-групп автоматический по дефолту, и даже документировано, в каких случаях оно работает (фактически, если нет исходящего роут-мапа — всё хорошо, остальные варианты не особо реалистичны).
То есть ты думаешь, что человек, который упомянул про peer-group и peer template в контексте разговора Adj-RIB-In/Adj-RIB-out, подробно и популярно объяснив нюансы, не понимает о чем говорит? Тебе не кажется, что это слишком «надменно» считать всех тупыми, а себя самым умным?
Это начинает утомлять. Ты снова бросаешься словами, смысла которых не понимаешь, как будто открыл command reference и читаешь все интересно звучащие названия. Ну какие к чертовой матери несовпадения MTU внутри сети? За такое архитектору зубы выдирают без обезболивания. Мы обсуждали более-менее конкретный сценарий, и в нем все критерии для включения в update-group будут выполнены. И в случае DMVPN у всех будет одинаковый MTU.
Повторяю в 100 раз, не надо додумывать за собеседника. Когда речь идет про tcp mss с точки зрения BGP, речь идет о холодном старте BGP сессии и полном обмене информации (а не о сообщения типа конкретный Route Advertisement/Route Withdrawal). Посчитай, сколько пакетов нужно передать в случае передачи BGP Full View (каков размер BGP Full View) при различных значениях TCP Mss. О каком к черту «несовпадении MTU» идет речь? Здесь речь идет о производительности BGP в контексте TCP трубы. В конце-концов посмотри вывод комманды show ip bgp neighbor BLABLA detail и найди там информацию по MSS. На подумать, вот тебе интересный график:
В этом случае единицы тысяч, с кучей обвесов в виде других протоколов. Ты утверждал, что даже несколько сотен в простейшей схеме — ничего хорошего.
А ты думаешь, что мир такой весь радужный с пони и единорогами? Ну, ну, ну.
Хотел бы обратить внимание, что если ситуацию рассматривать с точки зрения BGP Scale факторов, то тесты в различных конфигурациях могут показывать разные цифры. И поверь мне, 4000 BGP нейбров с 1 префиксом на каждый, не одно и тоже, что и 4000 BGP пиров с 100 000 префиксов на борту. Я уже молчу про наличие или отсутствие в конфигах таких вещей, как peer-group или peer template.
То есть это я спустя полтора года полтора года вспомнил про то, как меня посадили в лужу и инициировал повторное перебрасывание какашками в попытке отыграться, но снова сел в лужу на базовых вещах? :)
>выбор лучшего маршрута связан с реализацией BGP Best Path Algorithm и как я уже сказал ранее, не имеет какого-либо отношения к BGP FSM (который кстати не является частью процесса BGP Scanner, а скорее имеет отношение к процессу BGP Open)
Так и запишем — BGP считает маршруты только при поднятии сессии, ок.
>Тот же IPSec (шифрование) частично оффлоудится на QFP (читай hardware assist)
Всё еще печальнее — ты даже не различаешь понятия control plane и data plane.
Все этапы согласования SA выполняются на обычном процессоре.
В случае платформы ASR1k весь data plane обрабатывается QFP. Правда, как раз шифрованием он вообще не занимается, там отдельный акселератор стоит :) Вот в новых ISR 43XX, эмулирующих QFP на general purpose ядрах, они и шифруют.
А еще в тех графиках есть и софтовый 3945E…
>То есть ты думаешь, что человек, который упомянул про peer-group и peer template в контексте разговора Adj-RIB-In/Adj-RIB-out, подробно и популярно объяснив нюансы, не понимает о чем говорит?
Ты, как всегда, повторяешь кажущиеся тебе умными слова, не вникая в их смысл. Я объясняю, в чем конкретно ты не прав. Ты утверждаешь, что раз ты умеешь повторять те слова — значит, ты прав. Потрясающе :)
>Посчитай, сколько пакетов нужно передать в случае передачи BGP Full View (каков размер BGP Full View) при различных значениях TCP Mss.
Меня не перестает поражать твой постоянный полет мысли. Теперь выясняется, что Switch'у на нижней картинке топика (вообще-то речь про нее идет, с возможным горизонтальным масштабированием) уже надо full view иметь. Вопрос — ты хоть раз в жизни занимался дизайном чего-либо? Или за тебя взрослые думали?
>И поверь мне, 4000 BGP нейбров с 1 префиксом на каждый, не одно и тоже, что и 4000 BGP пиров с 100 000 префиксов на борту.
Но откуда же ты берешь эти цифры? Да и проблема может возникать при cold boot, BGP обычно не делает периодический флад таблицы всем нейборам…
>Я уже молчу про наличие или отсутствие в конфигах таких вещей, как peer-group или peer template.
Ты все еще будешь настаивать на том, что peer-group дает выигрыш в каких-либо ресурсах помимо nvram?
Если хочешь перестать публично позориться в чужом корпоративном блоге, можем перейти в ЛС.
Так и запишем — BGP считает маршруты только при поднятии сессии, ок.
>Тот же IPSec (шифрование) частично оффлоудится на QFP (читай hardware assist)
Всё еще печальнее — ты даже не различаешь понятия control plane и data plane.
Все этапы согласования SA выполняются на обычном процессоре.
В случае платформы ASR1k весь data plane обрабатывается QFP. Правда, как раз шифрованием он вообще не занимается, там отдельный акселератор стоит :) Вот в новых ISR 43XX, эмулирующих QFP на general purpose ядрах, они и шифруют.
А еще в тех графиках есть и софтовый 3945E…
>То есть ты думаешь, что человек, который упомянул про peer-group и peer template в контексте разговора Adj-RIB-In/Adj-RIB-out, подробно и популярно объяснив нюансы, не понимает о чем говорит?
Ты, как всегда, повторяешь кажущиеся тебе умными слова, не вникая в их смысл. Я объясняю, в чем конкретно ты не прав. Ты утверждаешь, что раз ты умеешь повторять те слова — значит, ты прав. Потрясающе :)
>Посчитай, сколько пакетов нужно передать в случае передачи BGP Full View (каков размер BGP Full View) при различных значениях TCP Mss.
Меня не перестает поражать твой постоянный полет мысли. Теперь выясняется, что Switch'у на нижней картинке топика (вообще-то речь про нее идет, с возможным горизонтальным масштабированием) уже надо full view иметь. Вопрос — ты хоть раз в жизни занимался дизайном чего-либо? Или за тебя взрослые думали?
>И поверь мне, 4000 BGP нейбров с 1 префиксом на каждый, не одно и тоже, что и 4000 BGP пиров с 100 000 префиксов на борту.
Но откуда же ты берешь эти цифры? Да и проблема может возникать при cold boot, BGP обычно не делает периодический флад таблицы всем нейборам…
>Я уже молчу про наличие или отсутствие в конфигах таких вещей, как peer-group или peer template.
Ты все еще будешь настаивать на том, что peer-group дает выигрыш в каких-либо ресурсах помимо nvram?
Если хочешь перестать публично позориться в чужом корпоративном блоге, можем перейти в ЛС.
Так и запишем — BGP считает маршруты только при поднятии сессии, ок.
Ты опять на своей волне? Причем здесь локальные маршруты и тот же BGP FSM? Или уже просто настолько присел в свою лужу (в которой почему-то тебе мерещатся другие, но не собственная персона), что уже просто не знаешь как извернуться?
Всё еще печальнее — ты даже не различаешь понятия control plane и data plane.
Все этапы согласования SA выполняются на обычном процессоре.
В случае платформы ASR1k весь data plane обрабатывается QFP. Правда, как раз шифрованием он вообще не занимается, там отдельный акселератор стоит :) Вот в новых ISR 43XX, эмулирующих QFP на general purpose ядрах, они и шифруют.
Мне это напоминает цирк в исполнении Дженифер Псаки и заявления вида – «отправим флот к берегам Белоруссии». Стилистика похожая.
Единственное с чем согласен, надо было уточнить про шифрование на акселераторе (который, кстати, не на всех 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
Меня не перестает поражать твой постоянный полет мысли.
А меня ограниченность твоего мышления.
Теперь выясняется, что Switch'у на нижней картинке топика (вообще-то речь про нее идет, с возможным горизонтальным масштабированием) уже надо full view иметь. Вопрос — ты хоть раз в жизни занимался дизайном чего-либо? Или за тебя взрослые думали?
Мы вроде бы, пока еще говорим про масштабирование и сходимость BGP. Или ты думаешь, что ЦОД — это 2-3 сервера? Ну если у тебя ЦОД 2-3 сервера, то я в принципе не удивлен глубиной твоих познаний. Сразу видно какого масштаба задачи тебе приходилось решать. А про горизонтальное масштабирование, ты упомянул так, для красного словца? Ты смысл то понимаешь?
Да и главное, открою для тебя еще одну Америку. В некоторых ЦОД может присутствовать BGP Full View, его конечно не гоняют везде, но это не отменяет самого факта. Ну и существуют ЦОД, которые насчитывают сотни тысяч серверов (вот уж где присутствует, так присутствует горизонтальное масштабирование).
Но откуда же ты берешь эти цифры? Да и проблема может возникать при cold boot, BGP обычно не делает периодический флад таблицы всем нейборам…
Из личного опыта. А вот откуда ты взял цифру десятки тысяч, вот это мне до сих пор непонятно. Более того, я уверен, что ты не задавался вопросом — «а откуда взялась цифра 4000 BGP соседей и как выглядел этот тест».
Но в целом, уже хорошо, что начинаешь задаваться вопросом «откуда я беру эти цифры».
Ты все еще будешь настаивать на том, что peer-group дает выигрыш в каких-либо ресурсах помимо nvram?
Ага :-) Осталось еще разок сходить по этой ссылке:
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.
Если хочешь перестать публично позориться в чужом корпоративном блоге,
Я думаю, что тут прекрасно заметно, кто тут позорится и проявляет грязные инсинуации.
можем перейти в ЛС.
Мне от тебя ничего не нужно, а техническая информация полезна будет и для других людей.
>Причем здесь локальные маршруты и тот же BGP FSM?
Вопрос. Будет ли каждый роутер, загружающий лучшие маршруты в FIB, осуществлять процесс scan? Может, так понятнее.
>Смотрим 10ый слайд и читаем внимательно. И опаньки, сюрприз!:
Всего-то надо уметь читать…
1) SA DB загружается в ESP с RP. Это как бы очевидно.
2) Существует очень много фич, которые реализованы хардварно в ESP. К примеру, чтобы считать netflow, не требуется отправлять пакеты в RP.
>Мы вроде бы, пока еще говорим про масштабирование и сходимость BGP. Или ты думаешь, что ЦОД — это 2-3 сервера?
Так откуда ты взял цифру «4000 BGP пиров с 100 000 префиксов на борту»? Почему именно 100000 префиксов, а не 600000 или 10?
>В некоторых ЦОД может присутствовать BGP Full View, его конечно не гоняют везде, но это не отменяет самого факта.
Ага. И при правильном дизайне это не является проблемой, потому что со времен RIP мы несколько ушли вперед…
>Из личного опыта.
Несложно заметить, что у тебя нет личного опыта, раз «сотни соседств» тебя пугает.
>А вот откуда ты взял цифру десятки тысяч, вот это мне до сих пор непонятно
Где-то на Live слышал. Попробую поискать ссылку…
>Ссылка для медитации (смотрим количество IPSec туннелей и много думаем)
Угу. Возможности ESP. Что-то мне подсказывает, что та цифра споков (4000) уперлась именно в ESP, а у RP еще все хорошо. Даже с EIGRP. А BGP в такой топологии скейлится лучше. У меня с примерно тысячей EIGRP соседств, с таймерами 5/15, хорошо если RP у 1002-X на пару процентов задумается. Колд старт тоже не проблема, нагрузка от всего есть, но небольшая. У 7200 дела обстоят намного хуже, при колд старте расколбас (соседства то падают по отсутствию кипалайвов, то поднимаются) пару минут может продолжаться. Но помним, что там много чего одновременно происходит — согласование IPSec SA куда тяжелее, чем поднятие EIGRP соседства.
>И разобраться с тем, что делают процессы BGP I/O и BGP Router.
А я там должен что-то новое узнать?
>Я тебе еще оставлю оттуда одну цитату
Вот она проблема людей, обладающих бумажками и не обладающих боевым опытом. Они ни за чем не следят и не знают ничего что выходит за рамки необходимого для получения бумажки (а там очень мало на самом деле).
http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/s_bgpdpg.html
The introduction of the BGP Dynamic Update Peer-Groups feature separates BGP update generation from peer-group configuration. The BGP Dynamic Update Peer-Groups feature introduces an algorithm that dynamically calculates BGP update-group membership based on outbound routing policies. This feature does not require any configuration by the network operator. Optimal BGP update message generation occurs automatically and independently. BGP neighbor configuration is no longer restricted by outbound routing policies, and update-groups can belong to different address families.
А по твоей ссылке пишут не то чтобы неправду, но сильно устаревшую информацию, такое бывает. Ты можешь зайти в консоль любой железки и убедиться. Как можно этого не знать — понятия не имею. Ты же вроде был падаваном в операторе связи, должен знать BGP лучше моего, в первую очередь такие нюансы.
>Мне от тебя ничего не нужно, а техническая информация полезна будет и для других людей.
Ок.
ramax, если вам этот срач надоест — скажите.
Вопрос. Будет ли каждый роутер, загружающий лучшие маршруты в FIB, осуществлять процесс scan? Может, так понятнее.
>Смотрим 10ый слайд и читаем внимательно. И опаньки, сюрприз!:
Всего-то надо уметь читать…
1) SA DB загружается в ESP с RP. Это как бы очевидно.
2) Существует очень много фич, которые реализованы хардварно в ESP. К примеру, чтобы считать netflow, не требуется отправлять пакеты в RP.
>Мы вроде бы, пока еще говорим про масштабирование и сходимость BGP. Или ты думаешь, что ЦОД — это 2-3 сервера?
Так откуда ты взял цифру «4000 BGP пиров с 100 000 префиксов на борту»? Почему именно 100000 префиксов, а не 600000 или 10?
>В некоторых ЦОД может присутствовать BGP Full View, его конечно не гоняют везде, но это не отменяет самого факта.
Ага. И при правильном дизайне это не является проблемой, потому что со времен RIP мы несколько ушли вперед…
>Из личного опыта.
Несложно заметить, что у тебя нет личного опыта, раз «сотни соседств» тебя пугает.
>А вот откуда ты взял цифру десятки тысяч, вот это мне до сих пор непонятно
Где-то на Live слышал. Попробую поискать ссылку…
>Ссылка для медитации (смотрим количество IPSec туннелей и много думаем)
Угу. Возможности ESP. Что-то мне подсказывает, что та цифра споков (4000) уперлась именно в ESP, а у RP еще все хорошо. Даже с EIGRP. А BGP в такой топологии скейлится лучше. У меня с примерно тысячей EIGRP соседств, с таймерами 5/15, хорошо если RP у 1002-X на пару процентов задумается. Колд старт тоже не проблема, нагрузка от всего есть, но небольшая. У 7200 дела обстоят намного хуже, при колд старте расколбас (соседства то падают по отсутствию кипалайвов, то поднимаются) пару минут может продолжаться. Но помним, что там много чего одновременно происходит — согласование IPSec SA куда тяжелее, чем поднятие EIGRP соседства.
>И разобраться с тем, что делают процессы BGP I/O и BGP Router.
А я там должен что-то новое узнать?
>Я тебе еще оставлю оттуда одну цитату
Вот она проблема людей, обладающих бумажками и не обладающих боевым опытом. Они ни за чем не следят и не знают ничего что выходит за рамки необходимого для получения бумажки (а там очень мало на самом деле).
http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/s_bgpdpg.html
The introduction of the BGP Dynamic Update Peer-Groups feature separates BGP update generation from peer-group configuration. The BGP Dynamic Update Peer-Groups feature introduces an algorithm that dynamically calculates BGP update-group membership based on outbound routing policies. This feature does not require any configuration by the network operator. Optimal BGP update message generation occurs automatically and independently. BGP neighbor configuration is no longer restricted by outbound routing policies, and update-groups can belong to different address families.
А по твоей ссылке пишут не то чтобы неправду, но сильно устаревшую информацию, такое бывает. Ты можешь зайти в консоль любой железки и убедиться. Как можно этого не знать — понятия не имею. Ты же вроде был падаваном в операторе связи, должен знать BGP лучше моего, в первую очередь такие нюансы.
>Мне от тебя ничего не нужно, а техническая информация полезна будет и для других людей.
Ок.
ramax, если вам этот срач надоест — скажите.
Вопрос. Будет ли каждый роутер, загружающий лучшие маршруты в 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» знаком?
Ну и встречный вопрос, сможешь рассказать в деталях, как 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
Так откуда ты взял цифру «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:
Hold Queue Size = (Windows Size / 2 * MSS) * Peer Count
Уппс, правда интересно?
Где-то на Live слышал. Попробую поискать ссылку…
Ну я же говорю. Где-то слышал, где-то видел, нахватался верхушек и теперь строишь из себя хрен пойми чего, пытаясь лечить людей.
Угу. Возможности 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 лучше моего, в первую очередь такие нюансы.
Я думаю, что окружающие прекрасно видят всю глубину твоих познаний, в том числе, кто и о каких нюансах говорит.
ramax, если вам этот срач надоест — скажите.
Небольшое уточнение на тему:
В случае с примером для экспоненциального распределения, ось Y — это соседи, ось X — время. В противном случае график функции должен быть «перевернутый».
Y — это время, а ось X — количество соседей
В случае с примером для экспоненциального распределения, ось Y — это соседи, ось X — время. В противном случае график функции должен быть «перевернутый».
Так как с холодным стартом мы худо-бедно разобрались (можем конечно еще обсудить connection mode active/passive, всякие там FPD и другие интересные фичи), я тебе еще «наброшу» на тему BGP Scanner'а, если ты не против. А то ты прям тут про него так порывался рассказать. Я надеюсь тебе термин ATF знаком (это к вопросу о скорости сходимости на уровне IGP)?
>Так вот, если на BGP RR сконфигурировать функциональность BGP FIB Selective Download
Ух ты, ты сумел нагуглить правильное название для моего намека «загружающий лучшие маршруты в FIB» :)
>Мне кажется, что если бы ты знал это, то у тебя тут не случился батхерт на фоне моих слов о том, что IPSEC частично оффлоудится на QFP
Попробую объяснить на более простом примере. Ты утверждаешь, что если один из результатов работы OSPF (FIB) программируется в TCAM, то TCAM оффлоадит OSPF. Это — поразительное невежество.
>Более того, когда речь идет про 4000 IPSec туннелей в контексте «масштабирования», то как минимум речь идет про IPSec SA. Надо ли мне объяснять, что такое IPSec SA или таки сам погуглишь?
Что самое интересное — эти два слова «IPSec» и «SA» ты узнал от меня чуть выше, когда я объяснял, что сценарий DMVPN не только IGP/BGP, там много чего другого происходит.
>Кроме того, я хотел бы заметить, что QFP, это тебе не ASIC. В случае с ASIC, реализация логики осуществляется в железе. В случае с QFP, реализация логики осуществляется на основе микрокода
QFP — навороченный сетевой процессор. Он впечатляет своими возможностями, но обладает массой скрытых граблей в виде «фичи Х и Y можно использовать по отдельности и нельзя использовать вместе». Ну для примера: удачи реализовать per-tunnel qos на сабинтерфейсе портченнела. На сабинтерфейсе физического интерфейса — запросто. А еще я пользовался этими железками в те времена, когда не поддерживались object-group'ы в ACL. Угу, вот так вот печально всё иногда.
ASR1k — хардварная платформа, которая иногда успешно притворяется софтовой, как ISR, но успех выдавания себя за ISR варьируется. Многие фичи реализованы, многие фичи теоретически можно реализовать, многие — нельзя.
>сможешь рассказать в деталях, как QFP работает с IPSec SA DB или Flow? Со схемами и точным описанием? Как взаимодействует с внешним акселератором? Как PPE обрабатывает пакеты? Вот, я чего-то сомневаюсь, что ты сможешь достаточно детально описать всю логику. :-) И скажем так, детальнее того, что описано вот здесь
То, что ты не умеешь искать информацию, не значит, что никто не умеет :) Вся глубокая информация имеется на Cisco Live. К примеру, кучу наверняка вызовущих у тебя ступор картинок можно посмотреть в http://d2zmdbbm9feqrf.cloudfront.net/2015/usa/pdf/BRKCRS-3147.pdf, не вижу смысла дублировать. А теперь ты опиши, какие именно задачи установления SA QFP оффлоадит с RP (простыми словами: RP больше не занимается теми задачами, их берет на себя QFP).
Для справки повторю: SA DB сгружается в QFP, чтобы при появлении нового пакета не требовалось спрашивать RP «а вот с этим что делать?».
>А вообще, подобные вопросы показательны. Сразу видно, что полноценного тестирования оборудования ты никогда не делал.
Так сразу видно, что ты за пределами лабы ничего никогда и не видел. Я могу взять cat6500 с XL картами, потестировать на 100000 маршрутов, экстраполировать и внезапно обнаружить нерезиновость TCAM в реальном сценарии. Сколько месяцев назад был тот факап, когда кто-то нечаянно выплюнул в интернет агрегированные префиксы и число префиксов перевалило за 512k? Тестирования конкретных железок всегда проводят на конкретных, реальных примеров. В случае DMVPN например каждый спок будет отдавать не 100 префиксов (это нереалистично), а один-два. И даже PPS не зря тестируют на худо-бедно реалистичном IMIX трафике.
>Это примерно как классическая реализация STP и STP + вендорские расширения типа port-fast или MSTP. Надеюсь параллель понятна?
Параллель понятна — что ты и STP не знаешь :) Несмотря на внешнее сходство результата их деятельности, MST по принципу работы не имеет ничего общего с классическим STP. А еще MST — открытый стандарт, ты его с RSTP спутал.
> что будет с маршрутизатором, когда тебе одновременно прилетит от 4000 пиров TCP ACK и сколько времени потребуется на установку всех подключений. Ну и главное, вот тебе формула для расчетов hold-queue:
Hold Queue Size = (Windows Size / 2 * MSS) * Peer Count
Уппс, правда интересно?
Да, действительно интересно. Ты не в курсе даже следующих фактов:
1) «Одновременно» — относительное понятие. Все прилетели в течение одной миллисекунды? Это не будет проблемой. Современные RP куда больше переварят на настолько низком уровне в стеке.
2) Вообще-то hold-queue прекрасно правится на интерфейсах в любую сторону. Не замечал на хардварных платформах в конфиге интерфейса эту опцию? Вот-вот, оно и есть. Многие почему-то думают, что это размер очереди для data plane трафика, что неверно, те значения как правило либо фиксированные, либо изменяются крайне грубо. А фактическое значение этой очереди сильно зависит от конкретной платформы.
>И проблема носит более глубокий характер, потому что когда речь заходить про туннели, то это тянет за собой множество вопросов, начиная от Interface DB, заканчивая keepalive сообщениями по туннелями.
Именно это я тебе и говорил. DMVPN — куда более сложный сценарий, чем ЦОДовая сеть.
>А в топологии hub-spoke, вообще основная нагрузка ложится на центральное устройство.
И именно поэтому я и объясняю, что тысячи соседств не обязаны быть проблемой…
>Если ты видишь цифры в 4000 подключений, то это не значит, что скорость установки новых подключений будет иметь дискретное равномерное распределение, оно скорее будет иметь экспоненциальное распределение.
Опиши, каким образом (холодный старт не рассматриваем, про это я уже говорил). Сценарий — либо полноценный DMVPN, либо BGP без всех обвязок, как будет проще. Кажется, у тебя нет ни малейшего представления о том, чем определяется время поднятия соседства… Каким образом предыдущие N соседств (уже установленные, успокоившиеся, на полпроцентика иногда напрягающие RP кипалайвами) замедлят установление N+1-го?
>Ибо вся информация, до сих пор актуальна.
http://d2zmdbbm9feqrf.cloudfront.net/2014/usa/pdf/BRKRST-3321.pdf. Например, страница 33, снизу-слева. И кстати посмотри лучше эту запись целиком, немало интересного узнаешь про то, какие внутренние механизмы цискиной реализации BGP работают для максимального масштабирования. Может быть, в том видео было про десятков тысяч соседств.
>Первое — команда peer-group не является depricated, а это значит, что ее можно таки встретить в конфигах и на продакшене.
Можно. Никто не запрещает. Хуже от этого не будет, да и ресурсы NVRAM опять же экономятся, меньше строк в конфиге.
>Второе — dynamic peer group еще нужно настроить.
Ты читать вообще умеешь? Или через раз получается? Напиши, какими командами это настраивается.
>Третье — если кто-то реализовал этот функционал, то это не значит, что можно забить на проблематику.
На какую проблематику? Ты ведь совершенно неправильно ее описал.
>Ну ты продолжай «присаживаться» в свою же лужу, считая, что чтение «старых книг» это пустая трата времени, а сертификация уровня CCIE ни чего не дает.
Именно это я тебе и успешно доказываю. У тебя есть какие-то ошметки общих знаний из книг, но ты не имеешь ни малейшего представления о происходящем сейчас, в реальном мире.
>Я думаю, что окружающие прекрасно видят всю глубину твоих познаний, в том числе, кто и о каких нюансах говорит.
Мне кажется, или число картинок в твоих комментариях прямо пропорционально степени твоего отчаяния, злости на то, что твое ЧСВ снова до плинтуса опускают?
Ух ты, ты сумел нагуглить правильное название для моего намека «загружающий лучшие маршруты в FIB» :)
>Мне кажется, что если бы ты знал это, то у тебя тут не случился батхерт на фоне моих слов о том, что IPSEC частично оффлоудится на QFP
Попробую объяснить на более простом примере. Ты утверждаешь, что если один из результатов работы OSPF (FIB) программируется в TCAM, то TCAM оффлоадит OSPF. Это — поразительное невежество.
>Более того, когда речь идет про 4000 IPSec туннелей в контексте «масштабирования», то как минимум речь идет про IPSec SA. Надо ли мне объяснять, что такое IPSec SA или таки сам погуглишь?
Что самое интересное — эти два слова «IPSec» и «SA» ты узнал от меня чуть выше, когда я объяснял, что сценарий DMVPN не только IGP/BGP, там много чего другого происходит.
>Кроме того, я хотел бы заметить, что QFP, это тебе не ASIC. В случае с ASIC, реализация логики осуществляется в железе. В случае с QFP, реализация логики осуществляется на основе микрокода
QFP — навороченный сетевой процессор. Он впечатляет своими возможностями, но обладает массой скрытых граблей в виде «фичи Х и Y можно использовать по отдельности и нельзя использовать вместе». Ну для примера: удачи реализовать per-tunnel qos на сабинтерфейсе портченнела. На сабинтерфейсе физического интерфейса — запросто. А еще я пользовался этими железками в те времена, когда не поддерживались object-group'ы в ACL. Угу, вот так вот печально всё иногда.
ASR1k — хардварная платформа, которая иногда успешно притворяется софтовой, как ISR, но успех выдавания себя за ISR варьируется. Многие фичи реализованы, многие фичи теоретически можно реализовать, многие — нельзя.
>сможешь рассказать в деталях, как QFP работает с IPSec SA DB или Flow? Со схемами и точным описанием? Как взаимодействует с внешним акселератором? Как PPE обрабатывает пакеты? Вот, я чего-то сомневаюсь, что ты сможешь достаточно детально описать всю логику. :-) И скажем так, детальнее того, что описано вот здесь
То, что ты не умеешь искать информацию, не значит, что никто не умеет :) Вся глубокая информация имеется на Cisco Live. К примеру, кучу наверняка вызовущих у тебя ступор картинок можно посмотреть в http://d2zmdbbm9feqrf.cloudfront.net/2015/usa/pdf/BRKCRS-3147.pdf, не вижу смысла дублировать. А теперь ты опиши, какие именно задачи установления SA QFP оффлоадит с RP (простыми словами: RP больше не занимается теми задачами, их берет на себя QFP).
Для справки повторю: SA DB сгружается в QFP, чтобы при появлении нового пакета не требовалось спрашивать RP «а вот с этим что делать?».
>А вообще, подобные вопросы показательны. Сразу видно, что полноценного тестирования оборудования ты никогда не делал.
Так сразу видно, что ты за пределами лабы ничего никогда и не видел. Я могу взять cat6500 с XL картами, потестировать на 100000 маршрутов, экстраполировать и внезапно обнаружить нерезиновость TCAM в реальном сценарии. Сколько месяцев назад был тот факап, когда кто-то нечаянно выплюнул в интернет агрегированные префиксы и число префиксов перевалило за 512k? Тестирования конкретных железок всегда проводят на конкретных, реальных примеров. В случае DMVPN например каждый спок будет отдавать не 100 префиксов (это нереалистично), а один-два. И даже PPS не зря тестируют на худо-бедно реалистичном IMIX трафике.
>Это примерно как классическая реализация STP и STP + вендорские расширения типа port-fast или MSTP. Надеюсь параллель понятна?
Параллель понятна — что ты и STP не знаешь :) Несмотря на внешнее сходство результата их деятельности, MST по принципу работы не имеет ничего общего с классическим STP. А еще MST — открытый стандарт, ты его с RSTP спутал.
> что будет с маршрутизатором, когда тебе одновременно прилетит от 4000 пиров TCP ACK и сколько времени потребуется на установку всех подключений. Ну и главное, вот тебе формула для расчетов hold-queue:
Hold Queue Size = (Windows Size / 2 * MSS) * Peer Count
Уппс, правда интересно?
Да, действительно интересно. Ты не в курсе даже следующих фактов:
1) «Одновременно» — относительное понятие. Все прилетели в течение одной миллисекунды? Это не будет проблемой. Современные RP куда больше переварят на настолько низком уровне в стеке.
2) Вообще-то hold-queue прекрасно правится на интерфейсах в любую сторону. Не замечал на хардварных платформах в конфиге интерфейса эту опцию? Вот-вот, оно и есть. Многие почему-то думают, что это размер очереди для data plane трафика, что неверно, те значения как правило либо фиксированные, либо изменяются крайне грубо. А фактическое значение этой очереди сильно зависит от конкретной платформы.
>И проблема носит более глубокий характер, потому что когда речь заходить про туннели, то это тянет за собой множество вопросов, начиная от Interface DB, заканчивая keepalive сообщениями по туннелями.
Именно это я тебе и говорил. DMVPN — куда более сложный сценарий, чем ЦОДовая сеть.
>А в топологии hub-spoke, вообще основная нагрузка ложится на центральное устройство.
И именно поэтому я и объясняю, что тысячи соседств не обязаны быть проблемой…
>Если ты видишь цифры в 4000 подключений, то это не значит, что скорость установки новых подключений будет иметь дискретное равномерное распределение, оно скорее будет иметь экспоненциальное распределение.
Опиши, каким образом (холодный старт не рассматриваем, про это я уже говорил). Сценарий — либо полноценный DMVPN, либо BGP без всех обвязок, как будет проще. Кажется, у тебя нет ни малейшего представления о том, чем определяется время поднятия соседства… Каким образом предыдущие N соседств (уже установленные, успокоившиеся, на полпроцентика иногда напрягающие RP кипалайвами) замедлят установление N+1-го?
>Ибо вся информация, до сих пор актуальна.
http://d2zmdbbm9feqrf.cloudfront.net/2014/usa/pdf/BRKRST-3321.pdf. Например, страница 33, снизу-слева. И кстати посмотри лучше эту запись целиком, немало интересного узнаешь про то, какие внутренние механизмы цискиной реализации BGP работают для максимального масштабирования. Может быть, в том видео было про десятков тысяч соседств.
>Первое — команда peer-group не является depricated, а это значит, что ее можно таки встретить в конфигах и на продакшене.
Можно. Никто не запрещает. Хуже от этого не будет, да и ресурсы NVRAM опять же экономятся, меньше строк в конфиге.
>Второе — dynamic peer group еще нужно настроить.
Ты читать вообще умеешь? Или через раз получается? Напиши, какими командами это настраивается.
>Третье — если кто-то реализовал этот функционал, то это не значит, что можно забить на проблематику.
На какую проблематику? Ты ведь совершенно неправильно ее описал.
>Ну ты продолжай «присаживаться» в свою же лужу, считая, что чтение «старых книг» это пустая трата времени, а сертификация уровня CCIE ни чего не дает.
Именно это я тебе и успешно доказываю. У тебя есть какие-то ошметки общих знаний из книг, но ты не имеешь ни малейшего представления о происходящем сейчас, в реальном мире.
>Я думаю, что окружающие прекрасно видят всю глубину твоих познаний, в том числе, кто и о каких нюансах говорит.
Мне кажется, или число картинок в твоих комментариях прямо пропорционально степени твоего отчаяния, злости на то, что твое ЧСВ снова до плинтуса опускают?
я от вашего милого срача не отписываюсь только потому, что у меня этот поток терминов вызывает восторженное благоговение. Но о чём вы говорите, решительно непонятно
Ух ты, ты сумел нагуглить правильное название для моего намека «загружающий лучшие маршруты в 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 обрабатывает пакеты. Детальнее того, что написано в том документе, о котором я говорил ранее.
К примеру, кучу наверняка вызовущих у тебя ступор картинок можно посмотреть в d2zmdbbm9feqrf.cloudfront.net/2015/usa/pdf/BRKCRS-3147.pdf, не вижу смысла дублировать.
А что еще ты не видишь смысла делать? Я думаю, что тут люди прекрасно видят, у кого тут вызывает эти картинки ступор и идет разрыв шаблона, и про 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:
Being single-homed behind Level3 this morning
i1.wp.com/cdn.honestnetworker.com/tumblr_muvi2niGxf1slbjseo1_4002.gif
Кажется, у тебя нет ни малейшего представления о том, чем определяется время поднятия соседства… Каким образом предыдущие N соседств (уже установленные, успокоившиеся, на полпроцентика иногда напрягающие RP кипалайвами) замедлят установление N+1-го?
Надоело объяснять, ей богу. Открываем 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'у я вообще молчу. Это к слову про объективность тестов и реалии. Ну и вообщем-то, этот пример еще раз показывает, насколько актуальна или не актуальна информация об оптимизации.
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.
На какую проблематику? Ты ведь совершенно неправильно ее описал.
Я тебе ее достаточно доходчиво описал в этом комментарии. Ибо с понимаем вопроса у тебя туго.
Именно это я тебе и успешно доказываю. У тебя есть какие-то ошметки общих знаний из книг, но ты не имеешь ни малейшего представления о происходящем сейчас, в реальном мире.
Не знаю, чего ты там и кому доказал. Думаю, окружающее быстрее тебя понимают о чем идет речь, чем ты сам.
Мне кажется, или число картинок в твоих комментариях прямо пропорционально степени твоего отчаяния, злости на то, что твое ЧСВ снова до плинтуса опускают?
Просто подлинкую, тебе полезно будет ознакомиться
lurkmore.to/%D0%A7%D0%A1%D0%92
И кстати, чтобы у тебя не было возможности зацепиться вот за это:
Разбор сделай не только с точки зрения производительности DRAM на RP vs TCAM на различных картах, но и всякие там интересные режимы аля cef и dcef.
Домашнее задание — рассмотреть этот вопрос с точки зрения аппаратной реализации таких платформ, как — 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.
Угу. Вы там городили велосипед с квадратными колесами в виде петли Мёбиуса зачем-то, от непонимания куда более простых и давно проверенных дизайнов…
И кстати, на счет петли «Мебиуса». Вполне себе живой дизайн, опять же этот пост тому пример.
PS: Типичный сетап раздающей ноды Netflix у оператора — два cisco asr 9000 + два коммутатора nexus + n кэширующих серверов.
А если возвращаться к количеству ECMP маршрутов, то в XR оно равно 64ыем. Ну и мы с уже Вами тогда обсудили варианты Anycast enabled LB, сегментацию через VRF'ы и иерархический токен бакет.
PPS: А еще забавно, что Вы тогда написали, что вы бы ко мне, как к интегратору не пошли из-за таких решений, а вот ivi утверждает, что они не пошли бы к интегратору из-за решений, которые устраивают вас. Вот такая вот тавтология…
ИМХО, в наш век мифа о мобильном интернете, если приложение не обрабатывает разрыв какой-либо HTTP-сессии, я бы сказал, что автор приложения не прав.
А если приложение разумно такую ситуацию обрабатывает, то anycast в общем смысле не страшен. Кроме приложений, которые вот совсем никак не могут быть stateless (имею в виду — неотрывными от конкретного сервера, который обрабатывает запросы). Грубо говоря: статику с anycast качать — без проблем, а вот свою почту прочитать — наверное, на anycast никак не сделать. NTP сделать на anycast — да, а вот SIP — вряд ли.
А если приложение разумно такую ситуацию обрабатывает, то anycast в общем смысле не страшен. Кроме приложений, которые вот совсем никак не могут быть stateless (имею в виду — неотрывными от конкретного сервера, который обрабатывает запросы). Грубо говоря: статику с anycast качать — без проблем, а вот свою почту прочитать — наверное, на anycast никак не сделать. NTP сделать на anycast — да, а вот SIP — вряд ли.
Ну строго говоря, примерно тоже самое было сказано мной для JDima ранее. Многие вопросы из этой статье мы еще два года назад обсудили.
Он просто человек интересный. Сначала у него anycast не будет работать, потом только в масштабах «между площадками», потом таки на площадках и то только для днс, а потом появилась и статика Яндекса и т.д. Хотя, я попытался человеку объяснить, что требование session persistance не всегда появляется.
Он просто человек интересный. Сначала у него anycast не будет работать, потом только в масштабах «между площадками», потом таки на площадках и то только для днс, а потом появилась и статика Яндекса и т.д. Хотя, я попытался человеку объяснить, что требование session persistance не всегда появляется.
ramax, не совсем понял какие минусы у L7(nginx/haproxy) подхода в вашем конкретно случае?
Из схемы (интегратор/2схема) видно чточто ничего не видно балансировщик (L7?) никуда не передает траффик.
Из схемы (интегратор/2схема) видно что
не совсем понял какие минусы у L7(nginx/haproxy) подхода в вашем конкретно случае?
Да там же всё написано: дорого и ненужно.
Из схемы (интегратор/2схема) видно что что ничего не видно балансировщик (L7?) никуда не передает траффик.
Это физика. Балансировщик подключен к свитчу. Можно, конечно, и к двум свитчам подключать, но я не видел смысла это отображать.
> Балансировщик подключен к свитчу.
А. Ок. Я почему-то в голове нарисовал схему где между балансером и серверами другой свитч стоит.
> Да там же всё написано: дорого и ненужно.
Я правильно понимаю, что сервер балансировщик L7 не состоянии перемолоть больше чем 10gbps?
В сетях не разбираюсь на практике, интерес академический (:
А. Ок. Я почему-то в голове нарисовал схему где между балансером и серверами другой свитч стоит.
> Да там же всё написано: дорого и ненужно.
Я правильно понимаю, что сервер балансировщик L7 не состоянии перемолоть больше чем 10gbps?
В сетях не разбираюсь на практике, интерес академический (:
Я правильно понимаю, что сервер балансировщик L7 не состоянии перемолоть больше чем 10gbps?
1) на момент принятия решения я не имел данных об аппаратных балансировщиках, тянущих больше 10Гбит/с. Может, сейчас уже есть. Но ценник всё равно будет космический.
2) предположим, что сервер с Haproxy/nginx может тянуть 20Гбит. Ладно! Гуляем на все 40, как Нетфликс!!! Их всё равно надо купить много штук, поставить в стойку, как-то зарезервировать, обеспечить сетью (портами, полосой) на все эти гигабиты. И сделать это на каждом нашем узле — не только в Москве. Много. Дорого. Хреново в обслуживании (просто за счёт количества).
Да, если есть конкретные требования к server affinity, как у JDima, то да, там вариантов нет. Но если задача на прикладном уровне позволяет обойтись без привязки клиента к серверу (а я бы для всех веб-проектов рекомендовал делать без привязки), то нет смысла в «тяжелом» L7-балансировщике.
У нас Brocade ACX1016 имеет на борту две, кажется, десятки, и это самая младшая модель в одном юните. Есть и мощнее. Все L7-фишки, включая раскрытие сертификатов и sticky cookie. Но получается дорого, согласен.
Однако в общем случае описанный вами способ не годится — например, в случае необходимости балансировки Exchange/Lync и прочей корпоративщины
Однако в общем случае описанный вами способ не годится — например, в случае необходимости балансировки Exchange/Lync и прочей корпоративщины
На тот момент Brocade нам не предлагали. Да, и есть ещё такой момент: наличие 2 * 10Г не означает пропускную способность 20 Гбит. Я видел балансер, который имел на борту 2 десятки, но пропускная способность была 4Гбит «в зависимости от задействованных функций». Так что на это обязательно надо смотреть.
Про Exchange сказать ничего не могу — не боролся с ним. Я так понимаю, это всё тот же вопрос server affinity.
Про Exchange сказать ничего не могу — не боролся с ним. Я так понимаю, это всё тот же вопрос server affinity.
Спеку можно посмотреть здесь:
www.brocade.com/products/all/application-delivery-switches/product-details/serveriron-adx-series/specifications.page
9GBps на юнитовую модель с максимальной лицензией.
Для ваших объемов, конечно, маловато будет, но есть же еще 4к линейка.
С Exchange и другими MS продуктами вообще много особенностей. Вплоть до требований балансировки конкретного url
www.brocade.com/products/all/application-delivery-switches/product-details/serveriron-adx-series/specifications.page
9GBps на юнитовую модель с максимальной лицензией.
Для ваших объемов, конечно, маловато будет, но есть же еще 4к линейка.
С Exchange и другими MS продуктами вообще много особенностей. Вплоть до требований балансировки конкретного url
У вас же, по идее, трафик сильно асиметричный? У яндекса есть доклад, где они рассказывают, как они балансируют, если коротко, то софтово ядром линукса (т.е. быстро) и только входящий трафик, а исходящий идёт обратно нупрямую, т.е. в обход балансера. А ещё посмотрите yahoo l3dsr. и +1 ExaBGP.
Да, асимметричный. Сильно. Но только зачем увеличивать количество элементов в цепочке? Зачем вообще выделенный балансировщик на региональном узле?
Кроме того, если только в одну сторону — это уже сразу L3/L4 балансировка, никакого L7. Об это писал в статье.
Кроме того, если только в одну сторону — это уже сразу L3/L4 балансировка, никакого L7. Об это писал в статье.
Человек говорит про механизм TCP Offload. Смысл заключается в том, что все TCP пакеты по-умолчанию валятся на балансировщик, который имеет запись о TCP стейте, далее этот пакет пересылается на нужный сервер и уже он (сервер) напрямую отдает в сторону пользователя нужные данные минуя балансировщик. Этот механизм не лишен смысла, так как в кейсах с асимметричным профилем трафика профиль трафика имеется характерный перекос в сторону направления «сервер — пользователь», а не «пользователь-сервер». Иначе говоря, помогает справиться с раздачей тяжелого контента множеству пользователей. В кейсе с anycast балансировкой, придется реже добавлять Anycast Enabled Load-Balancer (соответственно реже будут разрывы у пользователей).
Если через балансер / offload проходит только половина трафика (от клиента к серверу), то такое устройство не может знать о состоянии TCP-соединения. Вдруг сервер уже давно RST послал? А ACK вообще был? Соответственно, это остаётся простой, тупой L3 балансер. Чем он лучше роутера? Без стейтов — ничем.
Польза была бы, если такое устройство могло «подсасывать» состояния TCP-соединений из серверов, из ядра ОС. Но я про такие устройства не слышал.
Почитал, кстати, про Yahoo и l3dsr. Бедняжки. Им бы MPLS на серверах…
Польза была бы, если такое устройство могло «подсасывать» состояния TCP-соединений из серверов, из ядра ОС. Но я про такие устройства не слышал.
Почитал, кстати, про Yahoo и l3dsr. Бедняжки. Им бы MPLS на серверах…
Речь про обычные сервисы типа http или https. Этот кейс рабочий, балансеру известны src port, src ip и dst port, dst ip, далее роутинг на балансере идет с учетом данной информации + мониторинг сервера. Если какой-то сервер вылетает, то работающие флоу не перестраиваются из-за изменений значния хешей. Я согласен с тем, что балансер не знает «наверняка» (надо гуглить детальное описание какого-нибудь ldirectord) полное состояние сессии, но это не значит, что кейс с асеммитричным роутингом на основе L4 информации — работать не будет. Работает и некоторые люди почему-то его используют (возможно там могут быть и другие драйверы, а не только проблемы с перерасчетом хэша).
Что касается ACK и RST, в теории да, проблема может всплыть (переполнение таблиц на балансировщике). Но опять же имея информацю о TCP окне пользователя, прикнуть размер окна не составляет особой проблемы. В итоге, мы можем сессию ограничить по таймауту, с учетом потенциального размера окна. Как-то так…
Что касается ACK и RST, в теории да, проблема может всплыть (переполнение таблиц на балансировщике). Но опять же имея информацю о TCP окне пользователя, прикнуть размер окна не составляет особой проблемы. В итоге, мы можем сессию ограничить по таймауту, с учетом потенциального размера окна. Как-то так…
Мои уроки пошли на пользу — приятно читать :)
>Я согласен с тем, что балансер не знает «наверняка» (надо гуглить детальное описание какого-нибудь ldirectord) полное состояние сессии
Может и знать. Он видит весь трафик в одну сторону. Если был пакет с флагом SYN, а затем начинают идти пакеты с флагом ACK, то сессия наверняка жива, клиент получил SYN ACK. Это может быть не так в случае подделки пакетов клиентом, но не вижу рисков в таком векторе атаки, кроме разве что возможности целенаправленно досить одну ноду пула ACK пакетами.
>возможно там могут быть и другие драйверы, а не только проблемы с перерасчетом хэша
Драйверы — возможность с полностью нулевым влиянием на сервис снять трафик с узла (старые сессии доработают, но новые уже не будут на него назначаться), возможность при включении узла дать ему сначала небольшой (главное — контролируемый) процент трафика, возможность кипалайвить узел и в случае проблем быстро всех переключить на другие сервера (вариант с BGP сложнее — надо внутри самого сервера организовывать watchdog, проверяющий доступность вебсервиса и рвущий соседство при недоступности). В общем, DSR дает гибкость с небольшими компромиссами там, где трафик к серверу радикально ниже, чем от сервера.
>Я согласен с тем, что балансер не знает «наверняка» (надо гуглить детальное описание какого-нибудь ldirectord) полное состояние сессии
Может и знать. Он видит весь трафик в одну сторону. Если был пакет с флагом SYN, а затем начинают идти пакеты с флагом ACK, то сессия наверняка жива, клиент получил SYN ACK. Это может быть не так в случае подделки пакетов клиентом, но не вижу рисков в таком векторе атаки, кроме разве что возможности целенаправленно досить одну ноду пула ACK пакетами.
>возможно там могут быть и другие драйверы, а не только проблемы с перерасчетом хэша
Драйверы — возможность с полностью нулевым влиянием на сервис снять трафик с узла (старые сессии доработают, но новые уже не будут на него назначаться), возможность при включении узла дать ему сначала небольшой (главное — контролируемый) процент трафика, возможность кипалайвить узел и в случае проблем быстро всех переключить на другие сервера (вариант с BGP сложнее — надо внутри самого сервера организовывать watchdog, проверяющий доступность вебсервиса и рвущий соседство при недоступности). В общем, DSR дает гибкость с небольшими компромиссами там, где трафик к серверу радикально ниже, чем от сервера.
Мои уроки пошли на пользу — приятно читать :)
ЧСВ убавь.
Может и знать.
Может предполагать.
Он видит весь трафик в одну сторону. Если был пакет с флагом SYN, а затем начинают идти пакеты с флагом ACK, то сессия наверняка жива, клиент получил SYN ACK. Это может быть не так в случае подделки пакетов клиентом, но не вижу рисков в таком векторе атаки, кроме разве что возможности целенаправленно досить одну ноду пула ACK пакетами.
Балансеру в этой схеме неизвестно количество переданных пакетов от сервера к пользователю, ибо флоу летит мимо балансера, это напрямую связанно с tcp sequence number пакетах (я уже молчу про всякие флаги типа RST, PSH, URG со стороны сервера). Это одна из причин, по которой большинство DPI коробок имеют ограничения в ситуациях с асимметричным трафиком. А с учетом мобильных пользователей, лучше вообще не заикаться.
Драйверы — возможность с полностью нулевым влиянием на сервис снять трафик с узла (старые сессии доработают, но новые уже не будут на него назначаться), возможность при включении узла дать ему сначала небольшой (главное — контролируемый) процент трафика, возможность кипалайвить узел и в случае проблем быстро всех переключить на другие сервера (вариант с BGP сложнее — надо внутри самого сервера организовывать watchdog, проверяющий доступность вебсервиса и рвущий соседство при недоступности). В общем, DSR дает гибкость с небольшими компромиссами там, где трафик к серверу радикально ниже, чем от сервера.
Обсуждали уже.
>ЧСВ убавь.
Прошлый диалог начался с твоего «балансер не нужен, ECMP его полностью заменит». Рад, что теперь у тебя чуть больше знаний.
>Балансеру в этой схеме неизвестно количество переданных пакетов от сервера к пользователю, ибо флоу летит мимо балансера
1) В данном случае это не принципиально.
2) Можно смотреть на сиквенсы.
Исключение — спуфинг со стороны клиента, который что угодно может сочинить в заголовке TCP. Если отмахиваемся от этого риска, то получаем информацию об установленных сессиях, так как легитимный клиент не станет слать пакет с флагом ACK не получив SYN ACK, и даже о переданных от сервера данных. Еще гипотетически можно расставить сенсоры по сети, которые будут сообщать об увиденном трафике со стороны сервера хоть даже в виде netflow (там и про флаги есть поля, и про сиквенсы).
>Обсуждали уже.
Ну повторить не мешает.
Прошлый диалог начался с твоего «балансер не нужен, ECMP его полностью заменит». Рад, что теперь у тебя чуть больше знаний.
>Балансеру в этой схеме неизвестно количество переданных пакетов от сервера к пользователю, ибо флоу летит мимо балансера
1) В данном случае это не принципиально.
2) Можно смотреть на сиквенсы.
Исключение — спуфинг со стороны клиента, который что угодно может сочинить в заголовке TCP. Если отмахиваемся от этого риска, то получаем информацию об установленных сессиях, так как легитимный клиент не станет слать пакет с флагом ACK не получив SYN ACK, и даже о переданных от сервера данных. Еще гипотетически можно расставить сенсоры по сети, которые будут сообщать об увиденном трафике со стороны сервера хоть даже в виде netflow (там и про флаги есть поля, и про сиквенсы).
>Обсуждали уже.
Ну повторить не мешает.
Я немного не понял…
1) У Вас же входящий трафик на сайт минимальный, а исходящий в 1000 раз больше… Тогда о каких 20Г на балансер идёт речь? А исходящий трафик вроде как распределяется по аплинкам роутером…
Я представлял, что главный узел(балансер) кластера принимает запрос на фильм, этот узел находит на каком из узлов кластера он находиться и перенаправляет на этот узел(если он есть на нескольких, тогда выбирает самый свободный).
2) Все фильмы есть на всех узлах кластера, количество узлов кластера увеличивает пропускную способность?
1) У Вас же входящий трафик на сайт минимальный, а исходящий в 1000 раз больше… Тогда о каких 20Г на балансер идёт речь? А исходящий трафик вроде как распределяется по аплинкам роутером…
Я представлял, что главный узел(балансер) кластера принимает запрос на фильм, этот узел находит на каком из узлов кластера он находиться и перенаправляет на этот узел(если он есть на нескольких, тогда выбирает самый свободный).
2) Все фильмы есть на всех узлах кластера, количество узлов кластера увеличивает пропускную способность?
1) Ну, соотношение не 1 к 1000, но да, исходящего сильно больше. Так вот если балансер в режиме полного проксирования, то он всю эту полосу должен через себя пропустить. Поэтому 20Гбит на балансер — не смешно.
Перенаправление — это редиректор. Это совсем другая история… С ним, конечно, по полосе уже не такие ограничения. Но по-прежнему остаётся проблема единой точки отказа.
Думаю, следующую статью напишу про внутренности кластера — там станет понятно, на чём мы остановились.
2) нет, ни в коем случае. В кэширующем кластере узлы неравноценны по контенту. Но количество узлов кластера увеличивает суммарную нагрузочную способность. Опять же, это внутренности кластера.
Перенаправление — это редиректор. Это совсем другая история… С ним, конечно, по полосе уже не такие ограничения. Но по-прежнему остаётся проблема единой точки отказа.
Думаю, следующую статью напишу про внутренности кластера — там станет понятно, на чём мы остановились.
2) нет, ни в коем случае. В кэширующем кластере узлы неравноценны по контенту. Но количество узлов кластера увеличивает суммарную нагрузочную способность. Опять же, это внутренности кластера.
По haproxy данные сильно устаревшие и частично неверные (что это исключительно l7 балансировщик).
Куда выше шанс упереться в производительность ядра, а не haproxy, хорошо, что решений этой проблемы предостаточно.
Куда выше шанс упереться в производительность ядра, а не haproxy, хорошо, что решений этой проблемы предостаточно.
Sign up to leave a comment.
Лишние элементы или как мы балансируем между серверами