74,68
рейтинг
24 декабря 2013 в 12:19

Разработка → IPv6-адреса в мобильной сети «Билайн»: тест в Воронеже

image

Пространство адресов IPv4 практически исчерпано. В 2014 году возникает уже реальная угроза невозможности подключения ряда абонентских устройств, в частности M2M-датчиков для нефтегазовой сферы, охранных устройств и других терминалов, нуждающихся в уникальных ip-адресах. Не говоря о принтерах, фотоаппаратах, холодильниках и других устройствах.

Поэтому внедрение IPv6 в мобильной сети – одна из наших приоритетных задач. На рынке достаточно велико количество оборудования, не умеющего работать с IPv6. Тем не менее, это не повод задерживаться с внедрением. Сейчас сделана одна тестовая зона в Воронеже и области, где уже раздаются IPv6-адреса (и вы тоже можете их получить – детали ниже).

При внедрении протокола IPv6 для абонентов мобильной сети мы остановились на технологии Dual-stack IPv4v6. Любому устройству может назначаться как IPv4, так и IPv6-адрес.

Зачем нужен переходный период от v4 к v6?


Пока не все ресурсы интернета, а также не все контент-провайдеры используют IPv6. Много устройств не поддерживают протокол IPv6. Технология Dual-stack обладает гибкостью, что позволяет использовать в рамках абонентской сессии один из трёх вариантов работы: только протокол IPv4, только протокол IPv6, и одновременно оба протокола IPv4 и IPv6 (Dual-stack).

Что это даёт?


Кроме очевидных плюсов IPv6 — доступ к ресурсам и контенту интернета, которые поддерживают IPv6, без дополнительного туннелирования и трансляции. Ну и сама возможность получить «белый» индивидуальный IPv6 адрес для каждого абонентского устройства – это огромный шаг вперёд. Плюс более простая реализация шифрования и увеличение скорости обмена между P2P (peer-to-peer) IPv6 -устройствами. Каждому пользователю, который планирует использовать Dual-Stack — выделяется подсеть IPv6 с размерностью /64 (согласно спецификациям консорциума 3GPP).

Что влечет внедрение IPv6 и IPv4v6 Dual-Stack для оператора?


Внедрение нового формата адресов естественно повлияли на системы внутри «ВымпелКома». Изменения коснулись опорной, транспортной сетей, сервисных платформ, биллинга, СОРМа, и т.д. Сейчас мы исследуем и разрабатываем целевую архитектуру сети с поддержкой IPv4/IPv6 Dual Stack для мобильной сети.

Пилотный проект


Первая задача – развернуть пилотный проект на мобильной сети в одном регионе. Результаты пилотного проекта будут транслироваться всем подразделениям в Группе Компаний (VimpelCom Ltd.). Универсальное решение будет утверждено на уровне штаб-квартиры для дальнейшего распространения в остальных сетях группы.

География внедрения


На данный момент пилотный регион — это город Воронеж и область. По результатам пилота и в дальнейшей перспективе — все регионы России.

Это будет требовать каких-то доплат?


Дополнительной платы за услугу нет, тарифный план не меняется.

Что нужно для начала работы в IPv6-пространстве?


Иметь устройство, поддерживающее IPv4v6 Dual-Stack.

Вот список телефонов и модемов
Телефоны:
  • Acer E350 (Liquid Gallant)
  • Alcatel 3041D (Tribe)
  • Alcatel One Touch 2010D
  • Alcatel One Touch 2010X
  • Alcatel One Touch 2040D
  • Alcatel One Touch 4010D
  • Alcatel One Touch 4030D (s'POP)
  • Alcatel One Touch 5035D
  • Alcatel One Touch 5040X (View)
  • Alcatel One Touch 6010D (Star)
  • Alcatel One Touch 6010X (Star)
  • Alcatel One Touch 6030X (Idol)
  • Alcatel One Touch 6033X (Idol Ultra)
  • Alcatel One Touch 7025D (Snap)
  • Alcatel One Touch 8000D (Scribe Easy)
  • Alcatel One Touch 8008D (Scribe HD)
  • Alcatel One Touch 918D
  • Alcatel One Touch 997D
  • ASUS ME371MG (Fonepad)
  • Beeline E600
  • Fly IQ 441 (Radiance)
  • Fly IQ235 (Uno)
  • Fly IQ236 (Victory)
  • Fly IQ240 (Whizz)
  • Fly IQ245 (Wizard)
  • Fly IQ245+ (Wizard Plus)
  • Fly IQ255 (Pride)
  • Fly IQ256 (Vogue)
  • Fly IQ270
  • Fly IQ275 (Marathon)
  • Fly IQ280 (Tech)
  • Fly IQ285 (Turbo)
  • Fly IQ440 (Energie)
  • Fly IQ442 (Miracle)
  • HTC Windows Phone 8S
  • HTC Windows Phone 8X
  • Huawei Ascend Y210
  • Huawei S10 (MediaPad 10 FHD)
  • Huawei U8950 (Honor Pro)
  • Huawei Y101
  • Lenovo S720 (IdeaPhone)
  • LG E435 (Optimus L3 II Dual)
  • LG E610 (Optimus L5)
  • LG E612 (Optimus L5)
  • LG E975 (Optimus G)
  • LG P725 (Optimus 3D MAX)
  • LG P768 (Optimus L9)
  • LG P880 (Optimus 4X HD)
  • LG P895 (Optimus Vu)
  • Megafon SP-AI (Login)
  • MTS 960
  • Nokia 510 Lumia
  • Nokia 520 Lumia
  • Nokia 620 Lumia
  • Nokia 720 Lumia
  • Nokia 800.2 Lumia
  • Nokia 820 Lumia
  • Nokia 900 Lumia
  • Nokia 920 Lumia
  • Nokia 925.1 Lumia
  • Philips W626
  • Philips Xenium W632
  • Philips Xenium W737
  • Sony Ericsson Live (WT19i)
  • Sony Xperia Go (ST27i)
  • Sony Xperia V (LT25i)
  • Sony Xperia ZL (C6503)
  • ZTE V807 (Blade C)
  • ZTE V889M
  • ZTE V970 (Grand)
  • ZTE V970M (Grand X)


Модемы:
  • Huawei 3272
  • ZTE MF823


Если вашего устройства (например, планшета) нет в списке, а оно обладает поддержкой IPv6 и Dual-Stack – то скорее всего это, не проблема. Перед этим лучше уточнить возможность данного устройства и при необходимости обновиться на версию прошивки, с поддержкой данной функциональности. На iPhone для мобильной сети опция IPv6 на текущий момент пока не доступна.

Какие настройки использовать?


Следует выбрать в настройке APN internet.beeline.ru PDP type (или тип сети): IPv4v6 -для Dual-stack (будут доступны интернет ресурсы и контент IPv4 и IPv6) или IPv6 — только для IPv6 (будут доступны интернет ресурсы и контент только IPv6). Если поменять тип APN не удается, то просто параллельно можно создать новую APN internet.beeline.ru с параметром типа сети IPv4v6 или IPv6.

Ниже приведен пример для аппарата Nokia Lumia 820 (OS Windows phone):

image

Пример Dual-stack на Sony Xperia Z ultra (OS Android 4.2.2):

image

Пример настройки Dual-stack на USB-модеме (модель ZTE MF823):

image

После проведения настроек можно проверить подключение, заглянув на internet.yandex.ru и увидеть два адреса IPv4 и IPv6.

Пример www.v6.facebook.com:

image

Участие в пилотном тестировании


  1. Если вы живёте в Воронеже или области.
  2. Если вы подключены к мобильной сети «Билайн» (у вас есть SIM-карта «Билайн»).
  3. И если у вас есть или будет устройство, которое поддерживает IPv4v6 (Dual-Stack) и IPv6, вы можете получить адрес уже сейчас в рамках теста.

Подписка на тестирование будет проходить до 27 декабря 2013 включительно. Затем, после новогоднего пика, 10 января, снова можно будет записаться на тестирование на 5-6 дней. То есть можно писать до конца праздников, но просьба принять во внимание, что подписка новых желающих и получение ответов на интересующие вопросы возобновится в рабочие дни января.

Позже, после завершения тестов, возможность работы по протоколу IPv6 и IPv4v6 планируется у всех пользователей пилотного региона.

Чтобы подключиться, нужно отправить на IPv6@beeline.ru письмо с указанием вашего имени, абонентского номера телефона и типа терминала (телефона и его ОС, либо модели модема, камеры, планшета и т.п).
Автор: @mexicanplayer

Комментарии (164)

  • +3
    С моей точки зрения, IPv6 это прогрессивно, но не приватно.
    В IPv4 есть проверенный годами NAT. И я им пользуюсь не для экономии адресов, а чтобы спрятать устройства домашней сети. В IPv6 пока прятаться не так комфортно. Учитывая любопытство «больших братьев», нормальный NAT в IPv6 может надолго задержаться.
    • +23
      чувак, открой для себя firewall.
      • 0
        Понимаете, тут принципиальная разница в том, что firewall надо ещё настроить (на самом устройстве его может и не быть вообще) и к вашему аппарату можно обратиться извне (пропустят к нему или нет, это уже другой вопрос). А за NAT девайса не видно “из коробки”, в ряде случаев это плюс, а не минус.
        • +8
          строго говоря, NAT тоже надо настроить, однако все домашние роутеры умеют это более-менее правильно делать из коробки.

          с IPv6 тоже ничего не мешает из коробки на вход разрешать только ESTABLISHED и RELATED пакеты. получится почти как nat (на выход можно, на вход нельзя), только адрес у каждого свой.
        • 0
          firewall надо ещё настроить

          NAT/PAT фактически ведет себя как стейтфульный файрвол, можно поднять аналогичные механизмы и без включения функционала трансляции адресов. И NAT/PAT не добавляет ни малейшей защиты.
          • 0
            Дима, следуя простейшей логике (Если A == B and A == C, то и B == C) из твоих слов понятно что «стейтфульный файрвол» «не добавляет ни малейшей защиты».
            • 0
              PAT = [механизм трансляции адресов и портов] + [некое кастрированное подобие стейтфульного файрвола с базовым ALG, чтобы через него хоть что-то могло работать].
              Возможно, я плохо выразился, поправлюсь: этот механизм трансляции адресов не добавляет ни малейшей защиты, но многое ломает. Так почему бы не обойтись без него, оставив только собственно полноценный стейтфульный файрвол?
              • 0
                Дима, я понял что ты имел ввиду. Просто немного прицепился к словам. Твои утверждения выглядели забавно. Извини :)
        • 0
          Провайдер начал давать IPv6, как полагается, подсетью /64.
          На роутере стоит галочка Advertise Address, и машины за роутером получают случайный IP из множества размером 2^64.
          Если основная проблема отсутствия NAT — то, что зловреды будут сканить сеть и обнаруживать сервисы, то пусть хоть обсканятся — найту пару компьютеров в такой огромной домашней сети нереально.
          • 0
            хм. посмотреть таблицу хостов в сети зловредам ума не хватит? ;)
            • 0
              Это можно сделать снаружи роутера?
              • 0
                А, теперь я понял о каком сканировании идет речь. Будут искать другой способ. Например будут вести базу хостов, которые в Интернет лезут и на их сайт/сайты заходят. Организуют свою базу активных хостов, будут за деньги ее продавать. Короче не защита этот адрес, а security by obscurity. Firewall ставить надо :) И «наслаждаться» всеми проблемами firewall-а.
                • 0
                  Если юзер сидит только на яндексе, ютюбе и вконтакте (последние два кстати по ipv6 уже хорошо работают), то зловред его не обнаружит. В ipv4 можно просто сканить диапазоны домашних провайдеров и найдётся куча машин.
                  • 0
                    Ок. Я с Вами согласен. Но почему Вы рассматриваете только один вектор атаки «зловреда» Что с остальными векторами атаки?
                    • 0
                      В остальном ipv6 не хуже ipv4.
                      Проблема была только в том, что в ipv4 можно сканить адреса и без NAT напрямую получать доступ к клиентским машинам. В ipv6 якобы нет преграды в виде NAT (но оказывается есть ничуть не слабее преграда)

                      Случай целенаправленной атаки я не рассматриваю, тут соц. инженерия эффективнее будет, чем обход NAT/firewall
                • 0
                  Например будут вести базу хостов, которые в Интернет лезут и на их сайт/сайты заходят.

                  Ну здрасьте… А как же privacy extensions?

                  Далее. Стейтфульных файрволов что, не существует? Да пусть хоть обсканируются — маршрутизатор ничего лишнего снаружи не пустит. Или даже банальные пакетные фильтры, не пускающие SYN и любые ICMP кроме reply, unreachable и time exceeded, сгодятся. Хотя они для ack scan уязвимы, но это не поможет врагу установить соединение с любым из открытых портов.
                  • 0
                    Privacy extensions еще включить надо + они ничего не гарантируют.

                    По остальному это не ко мне, это к хабраюзеру qw1. Я тоже недоумевал, зачем ждать ipv6 чтобы спрятаться за firewall-ом.
                    • 0
                      Privacy extensions еще включить надо + они ничего не гарантируют.

                      Ну в винде они изначально включены.
                      Они гарантируют, что нехорошим людям бесполезно запоминать адреса хостов, все равно эти адреса вскоре сменятся. И да, сканировать сети как это делается сейчас — нереалистично.
    • 0
      Вас пугает что кто-то сможет определить с какого именно устройства в квартире вы вышли в интернет? В IPv4 можно определить конкретного абонента, не думаю что большому брату сильно важно с какого из ноутбуков вы запостили коммент )
      • +6
        При использовании privacy extensions (а они по дефолту включены во всех основных операционных системах) не получится определить даже этого — адреса будут случайными и изменяющимися во времени.
      • +1
        меня лично пугает что кто-то сможет определить (пускай даже потенциально) сколько и каких устройств у меня дома находится.
        под устройствами понимаются, кстати, не только ноуты, планшеты и прочие телевизоры — хотя этого уже не мало, огромный простор для домушников — возможность ремоутно выбирать жертву.
        • +6
          когда вы браузером с разных устройств ходите по разным сайтам, вы и так всем рассказываете какие устройства у вас дома находятся.

          блин, народ, вы либо шапочку из фольги наденьте, либо прекратите глупостями заниматься.
          • +2
            это просто у вас дома ничто кроме компов и планшетов к сети не подключено. пока не подключено.

            вы знаете, бывают устройства, в которых нету браузера. и бывают криво настроенные файрволы и/или уязвимости в них (особенно если это дешевая мыльница, коих большинство). IPv6 добавляет потенциальную возможность очень весело и радостно на этом поживиться на новом уровне удобства для атакующего. вы будете с этим спорить?

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

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

            я не говорю, что IPv6 это плохо. это очень даже хорошо. я просто поддерживаю автора изначального коммента о том, что NAT решает множество неочевидных проблем, помимо нехватки адресов.

            а паранойя тут вообще ни при чем, просто, есть потенциальная проблема, которую вы не хотите видеть.
            • +2
              это просто у вас дома ничто кроме компов и планшетов к сети не подключено.

              ну почему же, ещё телефоны, телевизор и NAS с архивами.

              есть потенциальная проблема, которую вы не хотите видеть.

              да вижу я проблему. я принципиальной разницы между NAT и фаерволом не вижу. вы прям вот уверены, что все домашние роутеры правильно реализуют upnp и не позволят пробросить порт на произвольный внутренний IP? в такой ситуации что есть NAT, что его нет… с чего вы взяли что NAT вот прям нерушим, а фаерволы сплошь дырявые? ещё раз: разрешаем на вход только ESTABLISHED и RELATED и всё.

              решение есть, а надёжность и уязвимость домашних роутеров — вопрос отдельный и к дискуссии отношения не имеет.
              • +1
                я так не считаю — что NAT это панацея а файрволлы дырявые. я вижу принципиальную разницу между наличием и отсутствием у устройства адреса, который можно глобально роутить.

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

                честно, я пока не видел ни одного SOHO-роутера, где бы нормально IPv6 поддерживался, не говоря уже о адекватных правилах файрвола для него. если вы знаете — поделитесь, мне интересно будет поковырять на досуге, может все действительно не так плохо.
                • –1
                  пользователю об этом и не нужно знать, об этом должна голова у производителей и провайдеров голова болеть. я всего лишь хотел показать что есть настройки вполне подходящие в качестве дефолтных.

                  про soho-роутеры и текущее их состояние мало чего могу сказать, так как не пользуюсь.
                • +7
                  Ребята, вы меня расстраиваете.
                  Глобально маршрутизируемый адрес это всегда плюс. В IPv6 есть и «приватные» адреса, которые могут маршрутизироваться либо в одном линке, либо просто в «офисе» (здании).
                  NAT это ужасно. Это действительно ужасно, как на это не смотри. То, что «реализуется» NATом, решается одной строкой в ip6tables.
                  Без NAT у нас сразу будут корректно работать:
                  • Торрент-клиент
                  • VoIP
                  • Всякие серверы

                  Никто не сможет понять, сколько у вас устройств и идентифицировать конкретное, если ваша сеть настроена правильно и используются Privacy Extensions.
                  Скажем, у меня когда-то были белые IPv4-адреса для устройств, и я очень радовался, хоть и пришлось делать one-to-one (full cone) NAT. Никаких забот по поводу «пробросить порт», никаких особых костылей, весь софт работает так, как должен работать, это было счастливое время.
                  • 0
                    вы зря так. я же не говорю, что ipv6 надо выкинуть.
                    я к тому как это сейчас реализовано в SOHO железе и что перспективы пока не радужные. в текущем варианте — всплывают описанные мной проблемы в полный рост
                    • 0
                      Ну, скажем, в OpenWRT отличный файрволл, и каких-либо проблем с настройкой IPv6 я не замечал. В Tomato тоже все замечательно. Аналогично хорошо работает IPv6 в Wive-NG, но там только 6rd и 6to4.
                      • –1
                        OpenWRT и обычный домашний пользователь? Вы шутите?
                        • +1
                          Обычный пользователь не настраивает роутер вообще. Он обычно и слово это с трудом произносит. Настройка роутера («мне поставили эту штуку, сделай мне чтобы соседи не подключались на эту, как его») ~ $30 в Одессе, стандартно, либо пиво другу.
                          • 0
                            «Настраивая» за $10 я сильно продешевил )))
                    • 0
                      Хм, ну ведь сейчас у роутеров по умолчанию дропаются пакеты приходящие «не в тему» и разрешены на вход только RELATED, ESTABLISHED, от наличия или отсутствия трансляции адресов эти правила в цепочке FORWARD не меняют своей сути. Не понимаю в чем тут дыра то, ведь фаервол как был так и остался. Если в конкретных прошивках, конкретных роутеров производитель что-то сделал для ipv6 не так как следует, то это скорее его вина и он её исправит. В функционировании iptables разницы никакой.
    • 0
      NAT — это такой костыль, который «ломает» кучу приложений создает большой такой геморрой для end-to-end подключений, разработчиков сетевых приложений и в некоторых случаях добавляет проблем сетевым инженерам.
      • 0
        Если firewall не будет знать о вашем приложении, оно тоже «сломает» ваше приложение.
        Дима там правильно написал выше — nat это такой stateful firewall который еще умеет и адреса переписывать.
        • 0
          Не факт, приложения разные бывают. Рекомендую почитать, для чего нужен тот же ALG. Кроме того, не будем забывать про всякие load-balancer'ы и возможные ограничения на серверах (количество открытых соединений с одного IP адреса, скорость установки новых подключений и тд и тп).
          • 0
            Ну так и в NAT/PAT-ах есть механизм подобный ALG.

            Что касается load-balancer-ов и серверов, то nat тут и обратную службу сослужить может — размазать одного клиента на много внешних адресов.

            В итоге, что я хочу сказать — NAT это сетевой инструмент, который бывает полезен в том или ином случае. Не надо его называть костылем. В сетевых технологиях есть вещи «покостылестие» ната.

            P.S.: Да и про то что NAT — костыль — это тоже маркетинг :)
            • 0
              Я не просто так упомянул про ALG, речь идет как раз в контексте NAT/PAT. И проблема здесь заключается в том, что payload может содержать данные, которые взаимоувязаны с dst и src IP адресами в оригинальном IP пакете. Кроме того функции ALG заточены под конкретные приложения и далеко не факт, что новые приложение будет хорошо функционировать при встрече с NATом. Хотел бы напомнить, что в некоторых случаях и ALG не спасает (например IPSec + HA).

              Что касается балансировки средствами NAT/PAT, то это далеко не лучший вариант, а вот проблем он тянет за собой вагон и маленькую тележку (например, ограничения на маршрутизацию, масштабирование и резервирование (в том числе самого NAT устройства)).

              Что касается маркетинга, обратное утверждение (NAT это сетевой инструмент) не менее маркетинговое.
              • 0
                И проблема здесь заключается в том, что payload может содержать данные, которые взаимоувязаны с dst и src IP адресами в оригинальном IP пакете.

                Ну объективности ради — и обычный стейтфульный файрвол может иметь ту же проблему (открытие дополнительных соединений). Иногда нельзя узнать, что они согласовали (например, FTPS), надо фиксировать диапазон портов и полностью его разрешать на файрволе. А для обычного FTP достаточно control channel открыть и включить инспектирование трафика, дальше файрвол сам разберется.
                Что касается балансировки средствами NAT/PAT, то это далеко не лучший вариант

                Он как раз оптимален — позволяет разместить балансировщики не на пути трафика, нет проблем с пролетом обратки мимо балансировщика. Теряется видимость приложением адреса отправителя пакета, но его можно и в L7 засунуть в случае HTTP. С резервированием как бы тоже проблем нет — балансировщики работают в A/S с репликацией сессий, а если один их кластер сдох — другой может сразу засветить тем же VIP адресом в IGP.
                • 0
                  Ну объективности ради — и обычный стейтфульный файрвол может иметь ту же проблему (открытие дополнительных соединений). Иногда нельзя узнать, что они согласовали (например, FTPS), надо фиксировать диапазон портов и полностью его разрешать на файрволе. А для обычного FTP достаточно control channel открыть и включить инспектирование трафика, дальше файрвол сам разберется.


                  Проблема бывает не только в согласовании диапазона портов.

                  Он как раз оптимален — позволяет разместить балансировщики не на пути трафика, нет проблем с пролетом обратки мимо балансировщика. Теряется видимость приложением адреса отправителя пакета, но его можно и в L7 засунуть в случае HTTP. С резервированием как бы тоже проблем нет — балансировщики работают в A/S с репликацией сессий, а если один их кластер сдох — другой может сразу засветить тем же VIP адресом в IGP.


                  Расскажите это Google или Facebook.
                  • 0
                    Проблема бывает не только в согласовании диапазона портов.

                    Да может произойти вообще что угодно, особенно если файрвол — TCP proxy.
                    Но основная проблема именно в дополнительных, динамических соединениях.
                    Расскажите это Google или Facebook.

                    А у вас есть информация о топологиях сети Google или Facebook?
                    Если рисовать логическую схему, то балансировщик рисуют на пути трафика вне зависимости от того, как он размещен физически и есть ли на нем source nat и destination nat для входящих соединений.

                    Да и вообще — к чему упоминание данных контор? Вы ведь осознаете, что подавляющее большинство клиентов покупают такие железки для сотен мегабит либо в крайнем случае гигабита трафика, а гуглов-фейсбуков единицы? Я работал с inline размещением балансировщиков — это неудобно. Source nat (и всего одно плечо на балансировщике) — это удобно.
                    • 0
                      Да может произойти вообще что угодно, особенно если файрвол — TCP proxy.
                      Но основная проблема именно в дополнительных, динамических соединениях.


                      Как минимум (в случае с NAT/PAT), здесь есть еще две проблемы, это security (в том числе на стороне сервера) и admission control.

                      А у вас есть информация о топологиях сети Google или Facebook?
                      Если рисовать логическую схему, то балансировщик рисуют на пути трафика вне зависимости от того, как он размещен физически и есть ли на нем source nat и destination nat для входящих соединений.

                      Да и вообще — к чему упоминание данных контор? Вы ведь осознаете, что подавляющее большинство клиентов покупают такие железки для сотен мегабит либо в крайнем случае гигабита трафика, а гуглов-фейсбуков единицы? Я работал с inline размещением балансировщиков — это неудобно. Source nat (и всего одно плечо на балансировщике) — это удобно.


                      Ну как минимум Google использует гораздо более хитрые схемы, которые имеют сразу несколько уровней балансировки. Самый первый это DNS Round Robin Policy. Если мне память не изменяет, то они в свое время работали над механизмом, когда DNS на основе src IP выдавал региональный IP адрес кэширующего сервера. Далее, на этом сервере уже функционирует свой балансировщик, который перенаправляет запросы на менее загруженные сервера. Как видите, NAT/PAT'ом там и не пахнет.

                      Собственно об этом написано в той же wikipedia по запросу Google Platform, больше чем уверен, что остальные материалы можно найти в каком-нибудь Google TechTalks.

                      From an operation standpoint, when a client computer attempts to connect to Google, several DNS servers resolve www.google.com into multiple IP addresses via Round Robin policy. Furthermore, this acts as the first level of load balancing and directs the client to different Google clusters. A Google cluster has thousands of servers and once the client has connected to the server additional load balancing is done to send the queries to the least loaded web server. This makes Google one of the largest and most complex content delivery networks


                      Что касается inline балансировщиков… Имено NAT/PAT костыль и является таким inline балансировщиком… И главное, он не решает главных проблем. Это загрузку не только полосы пропускания, но и системных ресурсов.
                      • 0
                        Если мне память не изменяет, то они в свое время работали над механизмом, когда DNS на основе src

                        Стандартный GSLB.
                        на этом сервере уже функционирует свой балансировщик, который перенаправляет запросы на менее загруженные сервера. Как видите, NAT/PAT'ом там и не пахнет.

                        А откуда уверенность, что первыми L7 устройствами трафик встречают сервера, а не балансировщики, будь то Cisco или F5?
                        У фейсбука совершенно точно F5 стоят. Соединения приходят на виртуальный IP адрес, дальше destination nat на N фронтендов. А заодно и source nat скорее всего, хотя тут возможны варианты, и я говорю (вместе с вендорами), что если нет адских объемов трафика, то схема с source nat оптимальна. А без destination nat жить нельзя в принципе
                        больше чем уверен, что остальные материалы можно найти в каком-нибудь Google TechTalks.

                        Вы ничего не найдете. Гугл тщательно скрывает свою сетевую архитектуру. Известно две вещи.
                        1) В ЦОДах трафиком управляет нечто похожее на SDN (это всё, что известно по этому направлению)
                        2) Они сами производят свое сетевое железо. Один даже утек налево, но ничего сделать с ним не смогли — загрузочного образа не было.
                        Имено NAT/PAT костыль и является таким inline балансировщиком… И главное, он не решает главных проблем.

                        Наоборот, прекрасно решает.
                        Тут есть несколько уровней.

                        Один — GSLB. Клиенту в ответ на DNS запрос по определенным критериям выдается адрес. Обычно это будет ближайший к нему ЦОД, или наименее нагруженный, и так далее. Задачи — грубое первичное распределение нагрузки и хоть какая-то катастрофоустойчивость.

                        Второй — распределение нагрузки и отказоустойчивость в пределах ЦОДа. Тут обычно ставят аппаратные балансировщики вроде таких — от единиц гигабит до сотен гигабит пропускной способности, возможно — с глубоким анализом трафика для выбора, что дальше делать с трафиком, ну и с приятными плюшками вроде работы с SSL, чтобы серверам не приходилось ничего шифровать. Разумеется, никто из крупных парней не выдает клиентам сразу IP адреса самих фронтенд серверов, это был бы идиотизм, а балансировщик позволяет линейно масштабировать производительность, без ущерба для сервиса выводить сервера из эксплуатации, за секунды фейловериться при аварии на сервере или на самом балансировщике и так далее.

                        В результате — destination nat бывает абсолютно незаменим (поговаривают о реализации схожего функционала с помощью SDN и без трансляции адресов, однако получить что-либо навороченнее встроенного в каталисты IP SLB не удастся). Но я полностью согласен, что в остальных случаях это бяка.
                        • 0
                          Стандартный GSLB.


                          И? Вы спросили про реализацию, я Вам ответил, что балансировка у Google или Facebook имеет многоуровневую иерархию. А то, что я для Вас не открыл «америки», ну это какбы уже не моя вина :)

                          А откуда уверенность, что первыми L7 устройствами трафик встречают сервера, а не балансировщики, будь то Cisco или F5?
                          У фейсбука совершенно точно F5 стоят. Соединения приходят на виртуальный IP адрес, дальше destination nat на N фронтендов. А заодно и source nat скорее всего, хотя тут возможны варианты, и я говорю (вместе с вендорами), что если нет адских объемов трафика, то схема с source nat оптимальна. А без destination nat жить нельзя в принципе


                          Ок. Возвращаемся в начало. Давайте представим себе другой вариант с балансировкой без NAT'а, которая позволяет масштабироваться лучшем чем решение на базе NAT.

                          Сценарий первый c NAT'ом.

                          Наиболее узкое место, это производительность конкретной NAT коробки. А именно производительность сетевого интерфейса (полоса пропускания). Допустим у нас используется интерфейс подключения 10 Gigabit Ethernet и это является существенным ограничением. Далее у нас имеются и другие сдерживающие факторы, которые напрямую влияют на производительность решения, а именно — тактовая частота процессора и количество оперативной памяти. Это влияет на размер NAT таблицы или количество NAT трансляций, а также такой не менее важный показатель как connection per second.

                          Вариант второй — назовем его Anycast :)

                          Представьте себе ЦОД, который имеет несколько точек подключения к глобальной сети Интернет. К слову ЦОДы проектируются таким образом, чтобы обеспечивалась стройная иерархия, которые имеют древовидную структуру и топологию сети. Подобный подход позволяет обеспечить одинаковый диаметр сети практически до любого сервера. Под диаметром сети, подразумевается количество переходов и характеристики каналов (тип и скорость подключения).

                          Например, у нас имеется четыре группы серверов. Каждая группа серверов состоит из двух физических разных серверов. Все сервера, во всех группах имеют одинаковый IP адрес. Каждая группа серверов подключается к одному и тому же коммутатору. Каждый коммутатор подключается с помощью EtherChannel к маршрутизатору. Маршрутизатор видит эту сеть как directly connected и анонсирует ее вышестоящему маршрутизатору по IGP, который в свою очередь подключается к агрегирующему маршрутизатору и т.д. и т.п.

                          В точке «входа», маршрутизатор уровня ядра видит, что нужный IP адрес доступен через несколько магистральных интерфейсов и как следствие может принимать решение по балансировке трафика. Балансировка трафика в этом случае настраивается таким образом, чтобы обеспечивалась:

                          а) неразрывность сессии (например на основе комбинаций src IP + src port или src IP + dst port)
                          б) семетричность (согласованность настроек режимов балансировки трафика, чтобы обеспечивалось согласованность при балансировке).

                          Что мы имеем на выходе?

                          1. Возможность безболезненого масштабирования сервиса. Тем не менее мы можем добавлять новые элементы без остановки сервиса или серьезного вмешательства вышестоящие схемы балансировки трафика и нагрузки.
                          2. Лучшую масштабируемость. Как по полосе пропускания, так и по системным ресурсам. Мы не ограничены производительностью NAT.
                          3. Унифицированную конфигурацию и скорость развертывания. Человек пришел, воткнул коробку, залил стандартный конфиг и ушел. Нам не надо каждый раз мучаться с настройками NAT + ALG.

                          К слову, далее сервер можно заменить L7 балансировщиком в виде умного прокси сервера, но опять же не NATом :)

                          И этот кстати пример, может являться кейсом для разработки собственного телекоммуникационного оборудования со стороны Google и Facebook, а не какой-то там NAT…

                          Вы ничего не найдете. Гугл тщательно скрывает свою сетевую архитектуру. Известно две вещи.
                          1) В ЦОДах трафиком управляет нечто похожее на SDN (это всё, что известно по этому направлению)
                          2) Они сами производят свое сетевое железо. Один даже утек налево, но ничего сделать с ним не смогли — загрузочного образа не было.


                          1) SDN это отдельная тема для разговоров.
                          2) А причем здесь коммутатор, который утек налево и NAT? :) Почитайте пример c Anycast схемой, вот в нее как раз таки и укладывается «Они сами производят свое сетевое железо.»

                          PS: Остальное я уже просто не вижу смысла комментировать…
                          • 0
                            Небольшое дополнение. Если сервера в одной группе имеют одинаковые IP адреса (которая подключается к одному и тому же коммутатору), то в этом случае их нужно разделять и сегментировать на уровне VLAN + VRF Lite или объединять в какой-нибудь кластер.
                          • 0
                            Наиболее узкое место, это производительность конкретной NAT коробки. А именно производительность сетевого интерфейса (полоса пропускания).

                            Несколько 10G интерфейсов в порт-ченнеле. Так как при таких масштабах клиентов обычно очень много — распределение нагрузки по линкам будет относительно равномерным.
                            у нас имеются и другие сдерживающие факторы, которые напрямую влияют на производительность решения, а именно — тактовая частота процессора и количество оперативной памяти.

                            Посмотрим на конкретные железки.
                            www.f5.com/pdf/products/big-ip-platforms-datasheet.pdf
                            L7 requests per second: 2.5M
                            L4 connections per second: 1M
                            Throughput: 42 Gbps/40 Gbps L4/L7

                            Это 32/48гб памяти, что немного. Процессоры там тоже типичные, 12 ядер суммарно по сокетам. И миллион CPS — это очень большая цифра. Что до ната — типично тратить на одну трансляцию несколько сотен байт, т.е. не так много.
                            Что мы имеем на выходе?

                            1. Возможность безболезненого масштабирования сервиса. Тем не менее мы можем добавлять новые элементы без остановки сервиса или серьезного вмешательства вышестоящие схемы балансировки трафика и нагрузки.
                            2. Лучшую масштабируемость. Как по полосе пропускания, так и по системным ресурсам. Мы не ограничены производительностью NAT.
                            3. Унифицированную конфигурацию и скорость развертывания. Человек пришел, воткнул коробку, залил стандартный конфиг и ушел. Нам не надо каждый раз мучаться с настройками NAT + ALG.

                            1. Крайне болезненные и ввод, и вывод серверов из эксплуатации. Любое изменение может изменить и результат хеширования, перераскидав соединения по другим серверам. Нельзя сказать «не принимать новых соединений на вон тот сервер, но старые с session persistence пусть доработают». На старых супах (в случае 6500 — 720 и старше) будут перекосы, если число серверов не равно 2^n.
                            2. Ограничения: ECMP (т.е. более 16-и серверов на одном свитче не поднять) и аплинки.
                            3. Вам доводилось работать с балансировщиками? :)
                            далее сервер можно заменить L7 балансировщиком в виде умного прокси сервера, но опять же не NATом :)

                            Т.е. было: некое устройство принимает на свой IP адрес соединение, затем переправляет соединение на другой адрес.
                            Стало: некое устройство принимает на свой IP адрес соединение, затем переправляет соединение на другой адрес.
                            Вопрос. А что изменилось-то, и почему балансировщик c NAT в обе стороны не умный прокси сервер?
                            И этот кстати пример, может являться кейсом для разработки собственного телекоммуникационного оборудования со стороны Google и Facebook

                            Фейсбук пользуется балансировщиками F5 и, соответственно, натом. Инфа 100%.
                            Гугл производит свое железо, потому что сам разрабатывает свои протоколы и традиционно делает максимально дешевое железо, и в итоге хвастается 90-95% утилизацией линков, без простоев и перегрузок.
                            • 0
                              Несколько 10G интерфейсов в порт-ченнеле. Так как при таких масштабах клиентов обычно очень много — распределение нагрузки по линкам будет относительно равномерным.


                              Это зависит не только от количества пользователей, но и от типа сервиса. Вы же пользовались сервисам типа megaupload, mail.ru files и тд и тп. Скажите, в этом случае линк 10G это много или мало?

                              Мне почему-то кажется, что Ваш NAT умрет быстрее.

                              Посмотрим на конкретные железки.
                              www.f5.com/pdf/products/big-ip-platforms-datasheet.pdf
                              L7 requests per second: 2.5M
                              L4 connections per second: 1M
                              Throughput: 42 Gbps/40 Gbps L4/L7

                              Это 32/48гб памяти, что немного. Процессоры там тоже типичные, 12 ядер суммарно по сокетам. И миллион CPS — это очень большая цифра. Что до ната — типично тратить на одну трансляцию несколько сотен байт, т.е. не так много.


                              40 Гигабит, Вы это серьезно? :) А что если у нас пользователей 1,000,000 и суммарно они генерируют более 1 Террабита трафика (возьмем например YouTube)?

                              А теперь главный вопрос, зачем мне дополнительно покупать ненужное железо, если я могу справиться с этим подручными средствами?

                              Вам на подумать. Почему Cisco объявила ACE End-Of-Sale.

                              1. Крайне болезненные и ввод, и вывод серверов из эксплуатации. Любое изменение может изменить и результат хеширования, перераскидав соединения по другим серверам..


                              Чушь, ибо в этом то и суть. Система сама перераспределит нагрузку между остальными блоками. В случаях с NAT'ом, нам потребуется изменить конфигурацию балансировщика. Все это отрицательно влияет на управляемость и TCO.

                              Нельзя сказать «не принимать новых соединений на вон тот сервер, но старые с session persistence пусть доработают».


                              В случаях с web application (да и в большинстве других случаях) — это необязательно.

                              На старых супах (в случае 6500 — 720 и старше) будут перекосы, если число серверов не равно 2^n.


                              Вы забывает про такие штуки, как unequal cost load-balancing.

                              2. Ограничения: ECMP (т.е. более 16-и серверов на одном свитче не поднять) и аплинки.


                              Первое — overlay network снимает данное ограничение.
                              Второе — leaf можно ограничить соответствующим образом.
                              Третье — ни кто не мешает разруливать routing внутри ЦОД с помощью BGP.

                              3. Вам доводилось работать с балансировщиками? :)


                              Нет, это что-то меняет?

                              Т.е. было: некое устройство принимает на свой IP адрес соединение, затем переправляет соединение на другой адрес.
                              Стало: некое устройство принимает на свой IP адрес соединение, затем переправляет соединение на другой адрес.
                              Вопрос. А что изменилось-то, и почему балансировщик c NAT в обе стороны не умный прокси сервер?


                              Чистый NAT обеспечивает балансировку на уровне src ip и dst ip, но при этом добавляет проблем в плане управляемости и масштабируемости.

                              Аналогичную задачу можно решить с помощью обычного routing + алгоритмы балансировки внутри маршрутизаторов и коммутаторов. В этом случае мы не привязаны к размеру NAT таблиц, CPS'у, в меньшей степени к bandwidth и тд и тп.

                              Комбинация anycast + proxy даст гораздо более оптимальные результаты, нежели NAT.

                              Фейсбук пользуется балансировщиками F5 и, соответственно, натом. Инфа 100%.
                              Гугл производит свое железо, потому что сам разрабатывает свои протоколы и традиционно делает максимально дешевое железо, и в итоге хвастается 90-95% утилизацией линков, без простоев и перегрузок.


                              Я открою Вам секрет. Facebook тоже производит свое железо.

                              • 0
                                Скажите, в этом случае линк 10G это много или мало?

                                Любая сессия будет меньше 10G, и в интернет ведет наверняка несколько 10G, так что это «достаточно». И не уверен, но вроде кто-то выпускал недавно линейку балансировщиков с 40G интерфейсами.
                                Мне почему-то кажется, что Ваш NAT умрет быстрее.

                                Вы читали описание? А ведь VIP адресов может быть много. Условно: каждый держит миллион CPS.
                                А что если у нас пользователей 1,000,000 и суммарно они генерируют более 1 Террабита трафика (возьмем например YouTube)?

                                Навскидку.
                                зачем мне дополнительно покупать ненужное железо, если я могу справиться с этим подручными средствами?

                                Не можете. С такой архитектурой у посетителей будут постоянно рваться сессии.
                                Вам на подумать. Почему Cisco объявила ACE End-Of-Sale.

                                Ответ тут, а также в мизерной доле рынка. ACE на много лет отставал от конкурентов.
                                Система сама перераспределит нагрузку между остальными блоками

                                Какая система? Вы про CEF? Вот допустим кто-то смотрит часовой ролик с котятами на ютубе. В этот момент вы добавляете новый сервер. С большой вероятностью человека перекинет на другой сервер, и ему прилетит RST.
                                В случаях с NAT'ом, нам потребуется изменить конфигурацию балансировщика.

                                Легко. Скрипт выполняет всю конфигурацию. Запускаются кипалайвы. Проверяется, что сервер жив. Он вводится с минимальным weight для отслеживания возможных проблем. Если все хорошо, то подается полная нагрузка. Все это прозрачно для пользователей.
                                В случаях с web application (да и в большинстве других случаях) — это необязательно.

                                В случае веб-приложений session persistence как раз огромная тема. Обычно решается куками.
                                Вы забывает про такие штуки, как unequal cost load-balancing.

                                Ого! Операторский сетевик пиарит EIGRP — это забавно.
                                Набросайте грубо конфигурацию. Задача: в железку приходит трафик до 1.1.1.1, этот адрес назначен двум серверам, они, разумеется, не умеют EIGRP, на один сервер должно идти в два раза больше трафика, чем на другой.
                                Первое — overlay network снимает данное ограничение.
                                Второе — leaf можно ограничить соответствующим образом.
                                Третье — ни кто не мешает разруливать routing внутри ЦОД с помощью BGP.

                                1. Дайте конкретное решение для приходящего извне сети трафика.
                                2. А именно? 16 серверов?
                                3. А BGP может выпулить трафик более чем в 16 сторон?
                                Нет, это что-то меняет?

                                Да. Вы не понимаете, что это такое, и утверждаете странные вещи.
                                Чистый NAT обеспечивает балансировку на уровне src ip и dst ip, но при этом добавляет проблем в плане управляемости и масштабируемости.

                                Чистый NAT (какой можно настроить, скажем, на ISRах) для балансировки никто не использует.
                                NAT на стероидах (см. балансировщики) дает несравнимо большую управляемость и масштабируемость, чем L3 решения.
                                Аналогичную задачу можно решить с помощью обычного routing + алгоритмы балансировки внутри маршрутизаторов и коммутаторов.

                                Нельзя. Любые изменения — и хеши начинают считаться по-иному. CEF load-sharing в режиме per-destination придумывали исходя из того, что не должно быть постоянного размазывания пакетов одной сессии по разным линкам — но разовое переключение раз в какое-то время допустимо.
                                Facebook тоже производит свое железо.

                                И использует балансировщики F5, с NATом…
                                • 0
                                  Любая сессия будет меньше 10G, и в интернет ведет наверняка несколько 10G, так что это «достаточно». И не уверен, но вроде кто-то выпускал недавно линейку балансировщиков с 40G интерфейсами.


                                  Этого «не достаточно» когда пользователей 1,000,000 и у некоторых подключение к глобальной сети от 2 Мбит и выше.

                                  Вы читали описание? А ведь VIP адресов может быть много. Условно: каждый держит миллион CPS.


                                  Вы готовы дать гарантию того, что все пользователи из китая «ломануться» равномерно, на разные IP адреса еще на этапе балансировки DNS Round Robin? :) Может быть еще поговорим на тему DNS кэша на стороне клиента?

                                  Анекдот в тему:

                                  Китайцы взломали сервер Пентагона, вот как это было:
                                  1. Каждый китаец попробовал один пароль.
                                  2. Каждый второй пароль был «Мао Цзедун»
                                  3. На 74357181-й попытке- сервер согласился, что у него пароль «Мао Цзедун»

                                  Навскидку.


                                  Почитаю, отвечу позже. Но на первый взгляд статья имеет явно маркетинговый характер :)

                                  Не можете. С такой архитектурой у посетителей будут постоянно рваться сессии.


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

                                  Какая система? Вы про CEF? Вот допустим кто-то смотрит часовой ролик с котятами на ютубе. В этот момент вы добавляете новый сервер. С большой вероятностью человека перекинет на другой сервер, и ему прилетит RST.


                                  В свое время, YouTube транслировал видео с помощью собственного видео плеера, который функционировал на базе технологии flash. По факту, код flash плеера исполняется на стороне пользователя. По мимо всего прочего, он способен кэшировать данные на локальном компьюетере пользователя. Кроме того, код плеера исполняется не на серевере, а конечном устройстве пользователя. Отсюда вывод, что ни кто не мешает разработчику встроить механизм переподключения и восстановления потока к серверу.

                                  Вы похоже перечитали книжку Cisco Press — Cisco Express Forwarding… Ибо дизайн должен учитывать не сколько особенности технологии, сколько особенности бизнеса и сервисов.

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


                                  Вы знаете происхождение закона Мерфи? Изначально он был сформулирован следующим образом:

                                  Если что-то можно подключить двумя способами, правильным и неправильным. То в большинстве случаях это будет подключено неправильно.

                                  Как я уже говорил ранее, в случаях с anycast потребуется всего лишь воткнуть линк. настроить IP адреса и объявить сеть.

                                  В случаях с NAT трансляцией, потребуется перенастроить правила. Риск допустить ошибку здесь гораздо выше.

                                  В случае веб-приложений session persistence как раз огромная тема. Обычно решается куками.


                                  ОООоооо. Без комментариев. Внимательный читатель сделает соответствующие выводы.

                                  Ого! Операторский сетевик пиарит EIGRP — это забавно.


                                  Упс. Забавно здесь другое. Например, unequal cost load balancing для MPLS TE :)

                                  Набросайте грубо конфигурацию. Задача: в железку приходит трафик до 1.1.1.1, этот адрес назначен двум серверам, они, разумеется, не умеют EIGRP, на один сервер должно идти в два раза больше трафика, чем на другой.


                                  Например, MPLS TE :)

                                  1. Дайте конкретное решение для приходящего извне сети трафика.


                                  От VRF-Lite и MTR до SDN.

                                  2. А именно? 16 серверов?


                                  Больше. Например, QinQ позволяет обслуживать сети, в которых встречается более 4000 возможных комбинаций VLAN идентификаторов (пускай и за счет наличия второго тега).

                                  К слову, Вы так любите вспоминать здесь CEF и даже написали вроде бы сносную статью, но как-то про recursive забываете.

                                  3. А BGP может выпулить трафик более чем в 16 сторон?


                                  Сегментация наше все :)

                                  Да. Вы не понимаете, что это такое, и утверждаете странные вещи.


                                  А Вы понимаете? Повторюсь еще раз — NAT — костыль. Горбатого могила исправит.

                                  Чистый NAT (какой можно настроить, скажем, на ISRах) для балансировки никто не использует.
                                  NAT на стероидах (см. балансировщики) дает несравнимо большую управляемость и масштабируемость, чем L3 решения.


                                  В пределах 40G? Не смешите…

                                  Нельзя. Любые изменения — и хеши начинают считаться по-иному.


                                  И дальше что? Ну посчитал он иначе. Валилось все на сервер А, после добавления новго сервера стало валиться на сервер А и Б.

                                  Алгоритм для посчетов хеша всегда один и тот же, там не используются генераторы случайных чисел :)

                                  CEF load-sharing в режиме per-destination придумывали исходя из того, что не должно быть постоянного размазывания пакетов одной сессии по разным линкам — но разовое переключение раз в какое-то время допустимо.


                                  Свечку держали? :) А еще для чего?

                                  И использует балансировщики F5, с NATом…


                                  Скажите, а Вам случаем не продавали решение на базе F5? :))))
                                  • 0
                                    Этого «не достаточно» когда пользователей 1,000,000 и у некоторых подключение к глобальной сети от 2 Мбит и выше.

                                    Я говорю с учетом того, что 10G не вызовет проблем с толстыми потоками. И его без проблем можно масштабировать добавлением новых 10G линков.
                                    Вы готовы дать гарантию того, что все пользователи из китая «ломануться» равномерно, на разные IP адреса еще на этапе балансировки DNS Round Robin?

                                    Смотря что считать «равномерно». Перекосы будут, но не катастрофические.
                                    А в случае anycast они могут размазаться ровным слоем по всей планете?
                                    Может быть еще поговорим на тему DNS кэша на стороне клиента?

                                    Один товарищ из Highloadlab убеждал меня, что за 10-20 минут 99% клиентов всосут обновление записей при TTL равным нулю или около того. Вроде проверяли, и не раз.
                                    Еще раз повторюсь, что для большинства пользователей такие процессы протекают практические незаметно.

                                    В случае HTTP, RST ведет к «невозможно отобразить страницу».
                                    В свое время, YouTube транслировал видео с помощью собственного видео плеера, который функционировал на базе технологии flash

                                    А сейчас активно идут к HTML5…
                                    Ибо дизайн должен учитывать не сколько особенности технологии, сколько особенности бизнеса и сервисов.

                                    Золотые слова. Почаще их повторяйте :)
                                    Как я уже говорил ранее, в случаях с anycast потребуется всего лишь воткнуть линк. настроить IP адреса и объявить сеть.

                                    В случаях с NAT трансляцией, потребуется перенастроить правила. Риск допустить ошибку здесь гораздо выше.

                                    Нет…
                                    Вы добавляете новый сервер. Под него нужен новый VLAN, а то и новый VRF. Под них надо править IGP, либо отдавать их все BGP. И при этом ни малейшей уверенности в том, что на новом сервере с боевым адресом вообще запущена нужная служба, а это ведет к очень мерзкой проблеме «у части пользователей сервис не работает, у части работает». IP SLA на каждый сервер? :)
                                    А в случае балансировщика это в общем случае делается так: открываем настройки server farm, жмем кнопку «добавить сервер», вводим его имя (лучше с IP адресом, но можно и без), нажимаем «применить», и готово. К серверу автоматически понесутся кипалайвы. Если они получают отклик, то на него начинает идти трафик. Без ущерба для остальных. Если отклика нет, то это не вызовет никаких проблем, сервер лишь пометится как failed.

                                    Что проще? Где больше шансов накосячить?
                                    Например, unequal cost load balancing для MPLS TE

                                    А как планируете с помощью него рассылать пакеты на несколько серверов с одинаковыми адресами? Вы заботитесь об аплинках, или о нагрузке на сами сервера? Аплинки масштабировать не проблема, и там ECMP хватит.
                                    От VRF-Lite и MTR до SDN.

                                    Более конкретно. Напоминаю: снаружи вашей сети никто таких слов не знает.
                                    Больше. Например, QinQ позволяет обслуживать сети, в которых встречается более 4000 возможных комбинаций VLAN идентификаторов

                                    Так что в итоге? По VLANу на сервер, вы серьезно?
                                    Сегментация наше все

                                    А мне вот больше нравится иметь на уровне доступа две огромные центральные железки (физически огромные или виртуально огромные, см. FEX), и к ним дуал-хомить всё. KISS. Очень удобно в сопровождении.
                                    Повторюсь еще раз — NAT — костыль.

                                    То есть балансировщик с NAT — костыль, а по VLANу/VRFу на сервер — не костыль. Я вас все-таки не понимаю.
                                    В пределах 40G? Не смешите…

                                    Это всего одна железка.
                                    Как вы думаете, какова ширина аплинков у среднестатистического гуглового ЦОДа?
                                    Вон у цитрикса есть модели под 120G.
                                    Алгоритм для посчетов хеша всегда один и тот же

                                    При одинаковых вводных — да. Однако, добавление всего лишь одного нового пути меняет результаты до неузнаваемости. К примеру, если было 15 путей, и добавили 16-й, то может оказаться и что ВСЕ потоки перехешировало на другие направления.
                                    А еще для чего?

                                    Этого достаточно.
                                    Скажите, а Вам случаем не продавали решение на базе F5?

                                    Нет, сидим на ACEах, по ряду причин посматриваем на решения другого вендора, не F5. Я говорю «F5» просто потому, что они наиболее навороченные по функционалу из всех, и они есть у фейсбука, раз уж вы его постоянно упоминаете.
                  • 0
                    Проблема бывает не только в согласовании диапазона портов.

                    Ок. В чем еще бывает проблема? И в чем ограничение NAT-а и плюс Firewall-а, который позволяет эту проблему обойти.

                    Расскажите это Google или Facebook.

                    Расскажите нам что вы имеете ввиду этой фразой?
                    • 0
                      Ок. В чем еще бывает проблема? И в чем ограничение NAT-а и плюс Firewall-а, который позволяет эту проблему обойти.


                      Security. Возможность однозначно сопоставить информацию src и dst IP адресов во время расследования инцидентов информационной безопасности. Блокировка пользователей по IP адресам. Применение автоматизированных средств (скриптов) в случаях DOS и DDOS атак.

                      Admission control. Гранулярность и гарантированное SLA при доступе к ресурсам (например ограничение на полосу пропускания per IP address у публичных ресурсов). Различные ограничение на connection per second, connection per IP address при подключении к серверу и т.д. и т.п.

                      Расскажите нам что вы имеете ввиду этой фразой?


                      Уточняю — деньги. Давайте представим себе некоторое web приложение. Очевидно, что одному пользователю может потребоваться один тип данных, а другому другой. Запросы к web серверу могут отличаться. Где-то идут «тяжелые» запросы к БД, а где-то данные идут статические. Представим себе ситуацию, когда у нас есть NAT балансировщик и скажем два внутренних веб сервера. Так вот, в случае с NAT балансировщиком легко получить ситуацию при которой один сервер может быть перегружен, а другой недогружен с точки зрения утилизации системных ресурсов конечного сервера. А теперь представьте, что у Вас таких серверов тысячи и каждый из них «кушает» электроэнергию, занимает место в стойке, требует обслуживания и т.д. и т.п.
                      • 0
                        Так вот, в случае с NAT балансировщиком легко получить ситуацию при которой один сервер может быть перегружен, а другой недогружен с точки зрения утилизации системных ресурсов конечного сервера

                        Заблуждаетесь. NAT балансировщик способен оценивать загрузку серверов по множеству критериев, включая время отклика на кипалайвы, время между syn и syn ack, время между отправкой HTTP запроса и получением отклика (это все по реальным соединениям, а не по кипалайвам), по количеству распределенных соединений и так далее.

                        А вот без NAT балансировщика у вас будут огромные проблемы с распределением нагрузки, особенно если серверов много.
                        • 0
                          Заблуждаетесь. NAT балансировщик способен оценивать загрузку серверов по множеству критериев, включая время отклика на кипалайвы, время между syn и syn ack, время между отправкой HTTP запроса и получением отклика (это все по реальным соединениям, а не по кипалайвам), по количеству распределенных соединений и так далее.


                          Неа, не заблуждаюсь.

                          Первое. Сам по себе NAT не может оценить скорость отклика SYN и SYN + ACK.

                          Второе. L7 балансировщик это уже другая песня. Я еще раз хотел бы повториться, что давайте не будем путать яйца в корзине. Кроме того время отклика SYN и SYN + ACK еще не гарантирует того, что пользователь получит данные быстрее, хотя бы потому что где-то данные уже закешированы в памяти, а где-то лежат на диске. В этих случаях требуется более тесная интеграция с приложением.

                          А вот без NAT балансировщика у вас будут огромные проблемы с распределением нагрузки, особенно если серверов много.


                          Чушь :) Смотрите пример с Anycast схемой. Там вопрос «сетевой балансировки» решается на уровне дизайна сетевой топологии и ее архитектуры без применения какого-либо NAT'а.
                          • 0
                            Сам по себе NAT не может оценить скорость отклика SYN и SYN + ACK.

                            NAT — просто механизм. Ну поставьте вместо него «CEF», суть останется прежней. Это не их задача.
                            Кроме того время отклика SYN и SYN + ACK еще не гарантирует того, что пользователь получит данные быстрее

                            Тогда кипалайвим данные, которым вручную запрещено кешироваться.
                            Чушь :) Смотрите пример с Anycast схемой.

                            Чушь :) Попробуйте задействовать anycast для долгоживущих соединений либо при потребности в session persistence любого рода, при условии наличия ECMP (а так и будет, если вы собираетесь балансировать им в пределах площадки, иначе балансировки просто не будет)…
                            • 0
                              NAT — просто механизм. Ну поставьте вместо него «CEF», суть останется прежней. Это не их задача.


                              Брр.

                              Тогда кипалайвим данные, которым вручную запрещено кешироваться.


                              Ага, особенно динамические данные, которые от пользователя к пользователю могут меняться :)

                              Чушь :) Попробуйте задействовать anycast для долгоживущих соединений либо при потребности в session persistence любого рода, при условии наличия ECMP (а так и будет, если вы собираетесь балансировать им в пределах площадки, иначе балансировки просто не будет)…


                              Легко. Особенно в условиях когда комбинация src ip + src port и dst ip + dst port не меняется. Это связано как раз с реализацией алгоритмов балансировки в телекоммуникационном оборудовании, ибо для сочетания src ip + src port и dst ip + dst port хеш всегда будет один и тот же. В общем, обеспечить балансировку per flow не такая уж и большая проблема.
                              • 0
                                Особенно в условиях когда комбинация src ip + src port и dst ip + dst port не меняется. Это связано как раз с реализацией алгоритмов балансировки в телекоммуникационном оборудовании

                                Вам это очень поможет, скажем, в случае того же FTP :) А если выдернуть один линк — часть клиентов потеряют свои сессии. Поднял/опустил метрики IGP => катастрофа для всех пользователей. Отличное решение :)

                                Скажите — вы сейчас говорите теоретически, или вы имели дело с anycast балансировкой чего угодно помимо простых и короткоживущих соединений?
                                • 0
                                  Вам это очень поможет, скажем, в случае того же FTP :) А если выдернуть один линк — часть клиентов потеряют свои сессии.


                                  Если бы да кабы во рту росли грибы. А если выдернуть шнурок из NAT устройства, то отвалятся все клиенты… По-этому не так страшен выход из строя одного элемента в случаях с Anycast, как выход из строя одного элемента в случаях с NATом (центрально элемента). К тому же, клиенту ни кто не мешает заново подключится и получить свою услугу, чего нельзя сказать с решением на базе NAT.

                                  Поднял/опустил метрики IGP => катастрофа для всех пользователей.


                                  Первое. Зачем крутить IGP метрики в такой сети? Там и так все работает так как надо, это ЦОД. При добавлении нового leaf, там даже не надо крутить метрики. Такие вопросы решаются еще на этапе дизайна (модульность и унификация компонентов).

                                  А если дурная голова, рукам покоя не дает, то в этом случае катастрофа для сервиса не в IGP, а скорее администратор.

                                  Скажите — вы сейчас говорите теоретически, или вы имели дело с anycast балансировкой чего угодно помимо простых и короткоживущих соединений?


                                  Скажем так, мой опыт связан с операторами связи и видел (и крутил) стыки по 200 Gigabit с 80 Гигабитами живого трафика, в том числе и с балансировкой для DPI решений.

                                  Что касается схемы anycast, то вполне себе живое и работоспособное решение:

                                  labs.umbrella.com/2013/01/10/high-availability-with-anycast-routing/
                                  • 0
                                    А если выдернуть шнурок из NAT устройства, то отвалятся все клиенты…

                                    Есть такая штука, как «1:1 redundancy с репликацией сессий»…
                                    По-этому не так страшен выход из строя одного элемента в случаях с Anycast

                                    С anycast проблемы станут нормой жизни :)
                                    При добавлении нового leaf, там даже не надо крутить метрики

                                    Невозможно добавить leaf, не вызвав маленького факапа для многих пользователей сервиса…
                                    и видел (и крутил) стыки по 200 Gigabit с 80 Гигабитами живого трафика, в том числе и с балансировкой для DPI решений.

                                    Ну наверное все-таки там не было ни anycast'а, ни NATа за ненадобностью в рамках данной задачи?
                                    то вполне себе живое и работоспособное решение:

                                    Эта ссылка у меня открылась со второго раза — забавно…
                                    Вы хорошо себе понимаете разницу между DNS (типично — очень быстрые обмены по одному пакету в каждую сторону) и долгоживущими TCP сессиями? Я вот вообще не нашел в той статье слова «TCP»…

                                    Yandex.st — тоже anycast. Но он расчитан на выдачу статики размером в килобайты, соединения поднимаются и завершаются в пределах сотен миллисекунд, и никакая привязка сессий к серверам не нужна. Риски минимальны, выгода заметна. В случае более сложных сценариев яндекс категорически не использует anycast, ибо безумие.
                                    • 0
                                      Есть такая штука, как «1:1 redundancy с репликацией сессий»…


                                      А еще есть такие штуки, как:

                                      1. Three-way handshake в TCP и флаг RST
                                      2. Клиенты поддерживающие докачку файлов по FTP, HTTP и т.д и т.п.
                                      3. Кнопка обновить страницу в браузере у пользователя
                                      4. Репликация данных (в том числе authenticated users) на уровне приложения cookies + данные в БД

                                      С anycast проблемы станут нормой жизни :)


                                      Например?

                                      Невозможно добавить leaf, не вызвав маленького факапа для многих пользователей сервиса…


                                      Легко, ибо факап практически незаметен для end user'а.

                                      Ну наверное все-таки там не было ни anycast'а, ни NATа за ненадобностью в рамках данной задачи?


                                      Скажем так, эксплуатировал я сеть одного оператора связи, где все клиенты NATились и NATились в нескольких точках.

                                      Скажите, а Вам знакома концепция hot potato routing и cold potato routing? Например в концепции hot potato routing как раз и применяется концепция anycast. К слову, концепция hot potato routing до сих пор популярна и живет у SP.

                                      Эта ссылка у меня открылась со второго раза — забавно…


                                      Поменяйте оператора.

                                      Вы хорошо себе понимаете разницу между DNS (типично — очень быстрые обмены по одному пакету в каждую сторону) и долгоживущими TCP сессиями?


                                      А вы хорошо понимаете разницу между per flow и per packet балансировкой, что такое symmetrical и asymmetrical routing?

                                      И как Вы думаете, понимаю ли я?

                                      image

                                      Yandex.st — тоже anycast. Но он расчитан на выдачу статики размером в килобайты, соединения поднимаются и завершаются в пределах сотен миллисекунд, и никакая привязка сессий к серверам не нужна. Риски минимальны, выгода заметна. В случае более сложных сценариев яндекс категорически не использует anycast, ибо безумие.


                                      Вы сами себе противоречите. Ибо статика тоже отдается по TCP (это я про «Вы хорошо себе понимаете разницу между DNS и долгоживущими TCP сессиями?»), HTTP он и в Африке HTTP.

                                      Более того, я Вам открою небольшой секрет. С точки зрения web application, привязка к серверу вообще необязательна. Знаете почему? Потому что на стороне пользователя имеются cookies файлы + информация об авторизации сохраняется в БД. Веб сервер в данном случае, представляет собой всего лишь интерфейс взаимодействия с данными.
                                      • 0
                                        А еще есть такие штуки, как:

                                        1. Three-way handshake в TCP и флаг RST
                                        2. Клиенты поддерживающие докачку файлов по FTP, HTTP и т.д и т.п.
                                        3. Кнопка обновить страницу в браузере у пользователя

                                        1. Реплицируются на соседа.
                                        2-3 — вы правда считаете, что правильно заставлять пользователя задействовать эти инструменты?
                                        Например?

                                        Опишите с точки зрения CEF (и его bucket'ов и хеша), что происходит, когда к двум существующим ECMP маршрутам добавляется третий. Вы, видимо, думаете, что те, кто раньше хешировались в те два пути, останутся на нем же, а новые плавно потекут на третий (как это происходит с NAT балансировщиками)?
                                        Скажем так, эксплуатировал я сеть одного оператора связи, где все клиенты NATились и NATились в нескольких точках.

                                        Это до сих пор довольно типично. Но разве это имеет какое-то отношение к вопросу SLB?
                                        Например в концепции hot potato routing как раз и применяется концепция anycast.

                                        Замечательно. Но какое отношение anycast имеет к чему-либо кроме быстрых и коротких сессий?
                                        А вы хорошо понимаете разницу между per flow и per packet балансировкой

                                        Вполне.
                                        И как Вы думаете, понимаю ли я?

                                        Нет, вы не знаете даже как CEF считает хеши, раз предлагаете такую архитектуру. А еще каждый сервер выносить в свой VLAN/VRF… В принципе, я не удивлен — в последнее время я встречаю немало абсолютно некомпетентных CCIE и готовящихся, благо сдампить лабу не так уж сложно, все выложено, причем даже бесплатно. Я уж не говорю о том, что CCIE — довольно базовый уровень знаний, не требуется знать на глубоком уровне современное состояние концепций и протоколов, не надо уметь разрабатывать архитектуру, надо просто быстро и без фантазии набивать много типовых конфигов.
                                        Вас я не обязательно назову некомпетентным, потому что есть определенная пропасть между ентерпрайзом и SP, вы, возможно, неплохо знаете SP, но вы сейчас лезете в ту область, которой вообще не понимаете, и предлагаете архитектуры, от которых хочется смеяться.
                                        Вы сами себе противоречите. Ибо статика тоже отдается по TCP

                                        По TCP отдаются жалкие килобайты, сессия отрабатывает за доли секунды и нет никакой надобности в session persistence/любых иных наворотах. Риски посреди сессии перелететь в другой ЦОД минимальны. И кстати, anycast задействуют лишь в рамках глобальной балансировки, а на входе в ЦОД запрос ударяется в тот же балансировщик и натится как обычно.
                                        HTTP он и в Африке HTTP.

                                        Вообще-то есть много вариантов того, как работает HTTP. Вплоть до «соединение будет висеть часами».
                                        С точки зрения web application, привязка к серверу вообще необязательна. Знаете почему? Потому что на стороне пользователя имеются cookies файлы + информация об авторизации сохраняется в БД.

                                        Далеко не сразу сохраняется в БД, потому что очень дорого писать каждый клик каждого пользователя. Есть даже традиционные примеры с веб-магазином и его корзиной. А репликация сессий силами апачей — тоже дорогое удовольствие.

                                        Вообще, советую для общего развития почитать, скажем, эту книгу.
                                        • 0
                                          1. Реплицируются на соседа.


                                          Реплицируются и дальше что? Ниточка как была 40G, так и осталось 40G. А пользователей сегодня 1,000, а завтра 1,000,000 и трафика сегодня 30G, а завтра терррабит.

                                          2-3 — вы правда считаете, что правильно заставлять пользователя задействовать эти инструменты?


                                          Если пользователь этого не заметит, то я не вижу в этом ни какой проблемы.

                                          Опишите с точки зрения CEF (и его bucket'ов и хеша), что происходит, когда к двум существующим ECMP маршрутам добавляется третий.


                                          Ок. Действительно, такая проблема существует для нечетного количества линков, но существуют способы ее обойти :) И такие кейсы тоже успешно решали в комбинациях с unequal cost load balance.

                                          А Вы в курсе, что например на платформе Cisco IOS XR для Cisco ASR 9000, количество token bucket может динамически меняться (в том числе по нечетному количеству)?

                                          Вы, видимо, думаете, что те, кто раньше хешировались в те два пути, останутся на нем же, а новые плавно потекут на третий (как это происходит с NAT балансировщиками)?


                                          Первое — это Вы так думаете, я так не думаю.
                                          Второе — это не страшно, потому что:

                                          есть такие штуки, как:

                                          1. Three-way handshake в TCP и флаг RST
                                          2. Клиенты поддерживающие докачку файлов по FTP, HTTP и т.д и т.п.
                                          3. Кнопка обновить страницу в браузере у пользователя
                                          4. Репликация данных (в том числе authenticated users) на уровне приложения cookies + данные в БД


                                          Это до сих пор довольно типично. Но разве это имеет какое-то отношение к вопросу SLB?


                                          Имеет. Ибо какая разница между направлениями user to server и server to users? Особенности нужно учитывать и в том и в другом случае. NAT категорически несовместим с asymmetrical routing.

                                          Вполне.


                                          Тогда чего Вы понять не можете? И почему до сих пор утверждали, что это схема не работает с привязкой к TCP или UDP сессии?

                                          Нет, вы не знаете даже как CEF считает хеши, раз предлагаете такую архитектуру. А еще каждый сервер выносить в свой VLAN/VRF…


                                          Вы ошибаетесь. В свое время поработав в компании Cisco Systems, я знаю не только как CEF работает, но и как осуществляется хеширование на таких платформах как Cisco 7600 и CRS.

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


                                          А у Вас есть CCIE?

                                          image

                                          Я уж не говорю о том, что CCIE — довольно базовый уровень знаний, не требуется знать на глубоком уровне современное состояние концепций и протоколов, не надо уметь разрабатывать архитектуру, надо просто быстро и без фантазии набивать много типовых конфигов.


                                          Я понял, CCNA это круче. Вам копию CCNA сертификата тоже выдать?

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


                                          На тему «некомпетентности», именно это Вы и пытаетесь сделать, показав свою «крутизну».

                                          Что касается смеха… Смех без причины, признак сами знаете чего. И как я уже Вам говорил ранее (в другом посте): энтерпрайз, энтерпрайзу рознь. И Google с Facebook'ом тому пример.

                                          По TCP отдаются жалкие килобайты, сессия отрабатывает за доли секунды и нет никакой надобности в session persistence/любых иных наворотах.


                                          Извините, но здесь уже и faceplam'а мало. Session persistence очень актуален для TCP трафика, чего нельзя сказать о UDP. А еще расскажите нам про session persistence с точки зрения спецификации HTTP/1,1, которая подразумевает под собой «постоянное соединение».

                                          Риски посреди сессии перелететь в другой ЦОД минимальны. И кстати, anycast задействуют лишь в рамках глобальной балансировки


                                          Это потому, что Вы так прочитали в той статье? Скажите, а что Вас смущает в той статье? Наличие BGP и Интернет? Дык, Вам ни кто не мешает вообще побиться на confideration. У Вас какое-то туннельной мышление…

                                          а на входе в ЦОД запрос ударяется в тот же балансировщик и натится как обычно.


                                          Не факт.

                                          Вообще-то есть много вариантов того, как работает HTTP. Вплоть до «соединение будет висеть часами».


                                          Например, веб сервер с поддержкой спецификации HTTP/1.1.

                                          Далеко не сразу сохраняется в БД, потому что очень дорого писать каждый клик каждого пользователя. Есть даже традиционные примеры с веб-магазином и его корзиной.


                                          По этому и существуют cookie. Это логично. Ибо зачем грузить «не нужными» user данными сервер, если их можно сохранять на стороне клиента?

                                          А репликация сессий силами апачей — тоже дорогое удовольствие.


                                          Очередной facepalm, вместо тысячи эмоций. Apache сам по себе ни чего не реплецирует, это веб сервер. Данные об авторизации записываются в БД, у которых в том числе имеется собственный кеш.

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


                                          Лучший совет — это тот, о котором Вас попросили.
                                          • 0
                                            А пользователей сегодня 1,000, а завтра 1,000,000 и трафика сегодня 30G, а завтра терррабит.

                                            Ну так продублирую ссылку. Иных способов масштабироваться до терабитов нет.
                                            такая проблема существует для нечетного количества линков

                                            Вы не поняли.
                                            При добавлении нового линка изменяется механизм вычисления хеша. Большинство старых соединений перераскидает по другим маршрутам.
                                            Особенности нужно учитывать и в том и в другом случае. NAT категорически несовместим с asymmetrical routing.

                                            Балансировщик может либо стоять на пути трафика (обратка непременно вернется через него), либо в стороне, но сначала сделав source nat. А есть и иные механизмы, позволяющие балансировщику пропускать через себя только прямой трафик, и это с NAT…
                                            И почему до сих пор утверждали, что это схема не работает с привязкой к TCP или UDP сессии?

                                            Внимательно перечитайте, что именно я писал. Речь шла о «сложных» сессиях, т.е. долгоживущих, требующих привязки к серверу и так далее.
                                            В свое время поработав в компании Cisco Systems, я знаю не только как CEF работает, но и как осуществляется хеширование на таких платформах как Cisco 7600 и CRS.

                                            Ну так расскажите. Вот есть два равнозначных маршрута. Допустим, по 8 токенов на каждый. К ним есть 16 соединений, и так фишка легла, что они хешировались в разные значения, и были ровно размазаны по обоим маршрутам. И вот появляется третий Что произойдет со старыми соединениями? Возможны ли перемещения с первого маршрута на третий? С первого маршрута на второй?
                                            А у Вас есть CCIE?

                                            Нет. Несколько лет назад, когда был молодой и зеленый, ходил, ничего сложного не увидел. Никакой реальной надобности иметь CCIE у меня нет, если получу — это будет лишь для себя и за свой счет.
                                            именно это Вы и пытаетесь сделать, показав свою «крутизну».

                                            Ну вот начинается… Это я достал члесертификат и начал им размахивать? :)
                                            И Google с Facebook'ом тому пример.

                                            Ага — те самые, погрязшие в NATе, а не anycast'е почему-то.
                                            Session persistence очень актуален для TCP трафика, чего нельзя сказать о UDP.

                                            Вы пытаетесь повторять мои слова, но несколько неправильно.
                                            Я говорю про это. Тема важная. Если же задача — скачать одну картинку и забыть про эту сессию навеки, то требования session persistence нет.
                                            Скажите, а что Вас смущает в той статье?

                                            Только то, что она не относится к обсуждаемой теме. Да, DNS давно использует anycast. А вы попробуйте таким образом организовать доступ к опубликованным на томкате приложениям.
                                            Не факт.

                                            Фейсбук — факт.
                                            Гугл — скорее всего факт.
                                            По этому и существуют cookie. Это логично. Ибо зачем грузить «не нужными» user данными сервер, если их можно сохранять на стороне клиента?

                                            Открою секрет.
                                            В куках обычно хранится идентификатор сессии клиента, и всё. Того, кто запихивает в куки килобайты данных, принято подвешивать за яйца.
                                            Apache сам по себе ни чего не реплецирует, это веб сервер

                                            Ага.
                                            Лучший совет — это тот, о котором Вас попросили.

                                            Иногда требуется и unsoilicited совет, когда дела совсем плохи :)
                                            • 0
                                              Ну так продублирую ссылку. Иных способов масштабироваться до терабитов нет.


                                              image

                                              Вы не поняли.
                                              При добавлении нового линка изменяется механизм вычисления хеша.


                                              Это Вы не поняли. Алгоритм для вычисления хеша всегда один и тот же (A+B=C). Так что механизм никогда не меняется. Меняется результирующий хеш и то в случаях изменения:

                                              1. Количества ECMP линков
                                              2. src ip, dst ip, src port, dst port в зависимости от настроек.

                                              Большинство старых соединений перераскидает по другим маршрутам.


                                              А Вы хотели бы, чтобы ели дышащий сервер продолжал их обслуживать? :)

                                              Балансировщик может либо стоять на пути трафика (обратка непременно вернется через него), либо в стороне, но сначала сделав source nat.


                                              При точка входа и выходе больше единицы далеко не факт, что трафик уйдет и вернется через одну и ту же точку. Это особенно актуально при наличии BGP. Не верите мне? Спросите операторов связи :) В интернете такие ситуации встречаются сплошь и рядом :) И чем больше у Вас сеть и количество NAT точек, тем серьезнее кошмар и его последствия.

                                              И еще… балансировка трафика всегда осуществляется в том месте, где этот трафик есть, а не в стороне и выполнив сначала source nat.

                                              А есть и иные механизмы, позволяющие балансировщику пропускать через себя только прямой трафик, и это с NAT…


                                              или routed режим в ACE, или ECMP, или Anycast :)))

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


                                              Нет понятия сложные или простые сессии. Есть UDP и TCP, которые описаны в рамках соответствующих RFC и если схема укладывается в эти стандарты, то ни каких проблем здесь нет. А если кто-то изобретаете себе велосипед, то он сам себе злобный буратино.

                                              Ну так расскажите. Вот есть два равнозначных маршрута. Допустим, по 8 токенов на каждый. К ним есть 16 соединений, и так фишка легла, что они хешировались в разные значения, и были ровно размазаны по обоим маршрутам. И вот появляется третий Что произойдет со старыми соединениями? Возможны ли перемещения с первого маршрута на третий? С первого маршрута на второй?


                                              Отвечаю про конкретно данный случай (классическую реализацию) ;) Ни чего не произойдет :) Пакет «прилетит» до конечного хоста с отличающейся задержкой (длинна линка + задержка на коммутацию пакет (если используется другая линейная карт) + задержка SFP модуля (если таковой имеется) и тд и тп). В рамках TCP сессии это не страшно, тем более в рамках TCP она reliable.

                                              Что касается anycast схемы произойдет сброс сесcии, стек TCP/IP об этом должен просигнализировать. Далее на усмотрение разработчиков ПО.

                                              Нет. Несколько лет назад, когда был молодой и зеленый, ходил, ничего сложного не увидел. Никакой реальной надобности иметь CCIE у меня нет, если получу — это будет лишь для себя и за свой счет.


                                              Ну вот когда получите, тогда и будите говорить про «бумажных» CCIE, сложность и актуальность лабы и тд и тп.

                                              Ну вот начинается… Это я достал члесертификат и начал им размахивать? :)


                                              Я достал, что это меняет?

                                              Ага — те самые, погрязшие в NATе, а не anycast'е почему-то.


                                              www.usenix.org/legacy/events/lisa10/tech/full_papers/Weiden.pdf

                                              Fernanda Weiden <nanda@google.com>, Google Switzerland GmbH
                                              Peter Frost <pfrost@google.com>, Google Switzerland GmbH

                                              We use Anycast for failover between Load Balancing clusters, providing the benefits of Anycast to any service behind our Load Balancers.

                                              This reduces a lot the network environment complexity, given the reduced number of machines
                                              advertising routes. Our solution uses BGP because it allows creation of a hierarchy for the route
                                              advertising
                                              , but other protocols work as well. Using Anycast, there is no longer need for remote
                                              failover using proxies
                                              , providing a cleaner solution since the client connects directly to the failover
                                              location, whilst proxying usually makes you lose the client identifying information. It also saves the
                                              proxy overhead between servers and users.


                                              Вы пытаетесь повторять мои слова, но несколько неправильно.
                                              Я говорю про это. Тема важная. Если же задача — скачать одну картинку и забыть про эту сессию навеки, то требования session persistence нет.


                                              Очередной Facepalm… Пока существует TCP сессия, требование session persistence актуально. Это также справедливо и для NAT трансляции.

                                              Только то, что она не относится к обсуждаемой теме. Да, DNS давно использует anycast. А вы попробуйте таким образом организовать доступ к опубликованным на томкате приложениям.


                                              Вы сами привели пример с Yandex'ом, когда схема с Anycast используется для раздачи статики (читай gif, jpg, doc, pdf и тд).

                                              Фейсбук — факт.
                                              Гугл — скорее всего факт.


                                              Аргументы выше.

                                              Открою секрет.
                                              В куках обычно хранится идентификатор сессии клиента, и всё. Того, кто запихивает в куки килобайты данных, принято подвешивать за яйца.


                                              Первое — RFC этому не противоречит. По этому свое желание «подвесить за яйца» оставьте при себе.
                                              Второе — информация может сохраняться не только в cookie, но и в URL. Например как ссылка на этот пост или поисковый запрос в форме поиска.

                                              Ага.


                                              Репликация authenticated users и tcp socket не одно и тоже.

                                              Иногда требуется и unsoilicited совет, когда дела совсем плохи :)


                                              image
                                              • 0
                                                Меняется результирующий хеш и то в случаях изменения:

                                                1. Количества ECMP линков

                                                Скорее не линков, а next hop'ов. Вы ведь фактически предлагаете вал статических маршрутов в разные стороны. Добавляется новый => все существующие результаты хеширования вылетают в трубу.
                                                Я уж не говорю, что такая архитектура абсолютно не поддается сопровождению…
                                                А Вы хотели бы, чтобы ели дышащий сервер продолжал их обслуживать?

                                                Старые? Конечно. Пусть доработают. А новые уже можно частично распределить и на новый сервер. Это не ломает сервис.
                                                При точка входа и выходе больше единицы далеко не факт, что трафик уйдет и вернется через одну и ту же точку.

                                                Факт. У получаемого сервером пакета source IP — это VIP адрес на балансировщике. Куда этот пакет денется?
                                                балансировка трафика всегда осуществляется в том месте, где этот трафик есть, а не в стороне и выполнив сначала source nat.

                                                Всегда ли? Этот механизм самый простой из всех. Вот например типичная ситуация, с которой ко мне обращаются: есть некий сервис, состоящий из N серверов, раскиданных по разным VLANам (и не факт что в пределах одного ЦОДа), катастрофоустойчивость не имеет значения, надо просто выделить один IP адрес, при обращении к которому соединения будут размазываться по тем серверам. Не вопрос. Пара минут — и все настроено. Еще немного времени — на проверку инициаторами обращения работоспособности. Затем переключение клиентов на VIP адрес. И при всем этом — никаких настроек на сервере вообще. Удобно.
                                                Есть UDP и TCP, которые описаны в рамках соответствующих RFC и если схема укладывается в эти стандарты, то ни каких проблем здесь нет.

                                                Хорошо. Представим себе какой-нибудь ютуб. У него один виртуальный IP адрес соответствует сотне серверов. Допустим, каждый час добавляется по новому серверу (ну вот решили расшириться). Вы считаете допустимым, что раз в час у большинства пользователей будет рваться TCP соединение?
                                                Между короткоживущими и долгоживущими сессиями огромная разница. Жаль, что вы этого не понимаете.
                                                Что касается anycast схемы произойдет сброс сесcии, стек TCP/IP об этом должен просигнализировать. Далее на усмотрение разработчиков ПО.

                                                Ну то есть постоянный сброс сессий — это нормально, а что там разработчики наворотили — не ваша забота.
                                                Знаете, я вам советую НИКОГДА не заниматься ничем вроде дизайна сетей :)
                                                когда получите, тогда и будите говорить про «бумажных» CCIE, сложность и актуальность лабы и тд и тп.

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

                                                Да. Обычно авторитетом пытаются давить те, кому больше нечего сказать. И я не вижу причин, по которым можно продолжать гордиться CCIE, сданным много лет назад. Ну разве что он был из первой тысячи, т.е. задолго до того, как сдача экзамена встала на поток, но это не ваш случай.
                                                We use Anycast for failover between Load Balancing clusters, providing the benefits of Anycast to any service behind our Load Balancers.

                                                Как раз то, о чем я говорил. Anycast используется совместно с GSLB, но дальше — традиционные балансировщики. Никто не задействует anycast в пределах площадки для таких вещей.
                                                Using Anycast, there is no longer need for remote
                                                failover using proxies, providing a cleaner solution since the client connects directly to the failover
                                                location, whilst proxying usually makes you lose the client identifying information.

                                                Снова вопрос стоит в распределении нагрузки между площадками.
                                                Еще:
                                                We configured the network environment so there is one subnet reserved for all Anycast virtual IPs
                                                (VIPs).

                                                Ага. Сами сервера имеют другие адреса, а VIPы — термин балансировщиков, которые делают destination nat.
                                                Ну а то, что отдается таким образом — та самая легковесная статика.
                                                Кстати — в каком веке была выпущена та бумага?
                                                Пока существует TCP сессия, требование session persistence актуально

                                                Вы путаете понятия.
                                                Session persistence — это когда первое TCP соединение установилось с сервером, отработало, завершилось — и следующее TCP соединение должно попасть в точности на тот же сервер, а не на соседа.
                                                Вы же думаете, что это — «все пакеты TCP потока должны попадать на один и тот же сервер», что логично, однако при этом вы агитируете за нарушение этого принципа под предлогом «ну прилетит RST, ничего страшного».
                                                Вы сами привели пример с Yandex'ом, когда схема с Anycast используется для раздачи статики (читай gif, jpg, doc, pdf и тд).

                                                Да, именно статики. Если хотите, можете спросить их, по какой причине они предоставляют доступ ко всему более сложному (от поиска до почты) только по старинке. Я уже устал объяснять элементарные вещи — может, у них получится. Ах да — у них никакого anycast в пределах, только балансировщики. Anycast лишь для выбора ближайшей площадки.
                                                RFC этому не противоречит. По этому свое желание «подвесить за яйца» оставьте при себе.

                                                То есть вы не против того, что веб-сервис может выдавать полсотни куков общим весом в пару килобайт, и при каждом новом запросе клиент будет слать их все?
                                                Объяснить, почему это печально?
                                                информация может сохраняться не только в cookie, но и в URL.

                                                Какая информация?
                                                Рассмотрим тот самый типовой пример с интернет-магазином. Вы говорите, что всё, что человек положил в корзину, надо хранить в куках либо в URL?
                                                Репликация authenticated users и tcp socket не одно и тоже.

                                                Тоже аргумент кстати. Вот человека кинуло на сервер, он аутентифицировался. Дальше вы добавили в ECMP новый сервер, того человека перекинуло на новый сервер, и он должен заново аутентифицироваться? Это ли не кошмар?
                                                Да, про IP Source Route прошу не воспринимать серьезно, это я уже разогнался

                                                Вот тут полностью согласен :) Осталось дописать что-то вроде «поднять TE туннели до серверов», и я окончательно выпаду в осадок :)
                                                • 0
                                                  Скорее не линков, а next hop’ов.


                                                  А это еще как посмотреть.

                                                  С точки зрения ECMP — Equal Cost Multi Path. Как это не странно, но сам по себе Path включает в себя не только NHOP на конце, но и множество других атрибутов. Ибо метрика может рассчитываться с учетом таких вещей как: bandwidth, delay, reliability, age, type, origin, hop count и т.д. и т.п. Естественно в зависимости от протокола маршрутизации и его алгоритмов. И раз на то уж пошло, то конкретно в данном случае, ECMP определяется не NHOP’ом, а метрикой маршрута (читайте как metric path). NHOP по факту является составной частью данного понятия (точно также, как и линк).

                                                  Со стороны CEF. Запись включает в себя не только NHOP, но и множество другой сопутствующей информации (например интерфейсы маршрутизатора). Надеюсь мне не надо объяснять, что такое LookUp Engine/Rewrite Engine/Multiple LookUp Operations/Recursive Entries и как это работает в связке с CEF во время forwarding decision? Поэтому в данном контексте будет правильнее говорить CEF Entry.

                                                  Если в качестве примера брать L2 балансировку, то там вообще может быть монописуально наличие IP NHOP’а.

                                                  По-этому давайте Вы таки свои неуместные и нелепые уточнения оставите при себе?

                                                  Вы ведь фактически предлагаете вал статических маршрутов в разные стороны.


                                                  Это Ваша больная фантазия так в очередной раз разыгралась? Скажите, а Вам религия не позволяет использовать в схеме с anycast динамические протоколы маршрутизации?

                                                  Специально для тех кто ездит на бронепоезде, еще раз объясняю, что предлагал (я даже не поленился и нарисовал для Вас схему):

                                                  “image"/

                                                  Пояснения к схеме:

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

                                                  Второе — в этой схеме leaf, как ты ни крути, но диаметр сети одинаковый и это утверждение справедливо как для intra, так и для inter traffic direction. В качестве примера рассмотрим направление intra для маршрутизаторов R1 и R4. Графы будут выглядеть следующим образом:

                                                  R1-to-R4 Path #1 = 1 <> 5 <> 4
                                                  R1-to-R4 Path #2 = 1 <> 6 <> 4

                                                  Аналогичный пример я Вам разрисовал для inter направления на примере R1-R7 и R3-R7.

                                                  Третье — в этой схеме как раз таки и следует использовать динамику, так как она обеспечивает автоматический adjustment при установке или отказе отдельных элементов.

                                                  Четвертое — здесь используется максимально упрощенное резевирование. Тем не менее у нас нет необходимости городить огород в виде HA кластера для NAT устройств, ибо сама сеть справляется с этой задачей ни чуть не хуже, а с точки зрения некоторых аспектов даже лучше.

                                                  Пятое — как вариант, имено эта идея и являлась, как один из возможных вариантов для разработки схемы с DR балансировкой и как следствие привело к разработке собственных коммутаторов у Google и Facebook.

                                                  Добавляется новый => все существующие результаты хеширования вылетают в трубу.


                                                  Как уже было сказано ранее, в некоторых случаях — не страшно. А там где страшно, существует workaround. Вы нам лучше расскажите, как Вы будите бегать с банкой вазелина, когда произойдет split brain у Вашего HA кластера из кучи NAT устройств в следствии ошибок инженеров или разработчиков балансировщика.

                                                  Я уж не говорю, что такая архитектура абсолютно не поддается сопровождению…


                                                  Я бы Вас не взял на работу, просто потому что:

                                                  1. Для Вас такая архитектура абсолютно не поддается сопровождению.
                                                  2. У Вас там механизмы балансировки сами по себе меняются.
                                                  3. Дальше вала статических маршрутов ничего не видно.
                                                  4. Вы готовы “а бы как” и “а бы где” крутить метрики маршрутов без какого-либо понимания когда это необходимо делать, а когда не стоит.
                                                  5. С любовь к NAT и готовностью его ставить как папало и где попало (об этом поговорим ниже).
                                                  6. Слабое понимание routing & switching, шаг влево и Вы поплыли (Вас это характеризует скорее как copy & past инженера).

                                                  Тем не менее, заниматься large scalable networks или проектами на данном этапе, для Вас противопоказанно. И конкретно в данном случае не важно, что это, сеть OTT, SP или large transnational enterprise.

                                                  Старые? Конечно. Пусть доработают. А новые уже можно частично распределить и на новый сервер. Это не ломает сервис.


                                                  Пусть. Ни кто не мешает опять же переключить этих клиентов плавно на другой Virtual IP (или даже ЦОД) через тот же DNS. И кстати этот workaround позволяет обойти так вами ненавистный “перерасчет хеша”.

                                                  Факт. У получаемого сервером пакета source IP — это VIP адрес на балансировщике. Куда этот пакет денется?


                                                  Это очевидно — пакет дропнется. В сотый раз повторяю, не питайте иллюзий. NAT очень чувствителен к symmetrical и asymmetrical routing. Как я уже говорил ранее, в Интернете сплошь и рядом встречается ситуации с asymmetrical routing, сегодня пакет от клиента прилетает через один пир, а выходит через другой, завтра ситуация вообще может поменяться координальным образом. Поймите одну простую вещь, что в случаях bi-directional сессий, очень важно чтобы пакеты ходили в обе стороны через один и тот же NAT. И если пакет в обратную сторону улетит через другой NAT, то он там благополучно канет в лету (просто потому, что другой NAT не имеет записи об этой трансляции и как следствие он об этом ничего не знает). Это настолько очевидная вещь, что об этом должен знать любой маломальский CCNA, а про CCNP я вообще молчу.

                                                  По факту, особенности с symmetrical и asymmetrical routing накладывают ограничения на routing. И как я уже говорил ранее, чем больше точек пиринга с внешними сетями и различных NAT устройств, тем ужаснее кошмар.

                                                  Всегда ли?


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

                                                  Анекдот в тему:

                                                  Идут по пустыне Карлос Кастанеда и Дон Хуан.
                                                  Кастанеда — Дону Хуану:
                                                  — Дон Хуан, что такое «необычная pеальность»?
                                                  Дон Хуан:
                                                  — Смотpи, видишь — заяц? Стpеляй в него.
                                                  Кастанеда стpеляет, естественно, пpомахивается, заяц бежит дальше.
                                                  Дон Хуан:
                                                  — Это и есть «необычная pеальность». Ты попал в него, убил, а он побежал дальше…

                                                  Этот механизм самый простой из всех.


                                                  Мне не интересн этот механизм, ибо смысл сказанного Вами ранее, в буквальном смысле, был инной.

                                                  Вот например типичная ситуация, с которой ко мне обращаются: есть некий сервис, состоящий из N серверов, раскиданных по разным VLANам (и не факт что в пределах одного ЦОДа), катастрофоустойчивость не имеет значения, надо просто выделить один IP адрес, при обращении к которому соединения будут размазываться по тем серверам. Не вопрос. Пара минут — и все настроено. Еще немного времени — на проверку инициаторами обращения работоспособности. Затем переключение клиентов на VIP адрес. И при всем этом — никаких настроек на сервере вообще. Удобно.


                                                  Из Вашего примера следует, что Вы готовы поставить NAT или L7 балансировщик не особо задумываясь о последствиях. Тем не мнее это говорит всего лишь о Вашей недальновидности. Ваш пример с несколькими ЦОД как минимум неудачен, потому что в этой ситуации возникает проблема suboptimal routing. Иначе говоря, весь трафик будет валиться в то место, где находится Ваш Virtual IP и как следствие создавать не нужную нагрузку на каналы связи. В случае с Anycast схемой между площадками, подобной проблемы вообще не возникает. Вторая потенциальная проблема — это end-to-end qos propаgation, особенно если Вы оказываете услуги на базе своего ЦОД’а другим заказчикам. По-этому дизайнер сетей из Вас вообще ни какой и тут сразу видно, что Вы действительно не имеет опыта работа с large scalable networks.

                                                  Я почему-то не удивлюсь, если внутри Вашей сети NAT на NAT’е и NAT’ом погоняет.

                                                  Скажите, а что будет когда у Вашего клиента станет 70,000 одновременных пользователей, а на Вашем NAT устройстве с этим Virtual IP закончятся tcp socket’ы. Или Вы думаете, что ограничение в 65 535 портов это не про Вас, а магические цифры в несколько млн. NAT трансляций Вас как-то спасут? Вы лучше подумайте над тем, почему появились такие механизмы как DR и Anycast.

                                                  Хорошо. Представим себе какой-нибудь ютуб. У него один виртуальный IP адрес соответствует сотне серверов. Допустим, каждый час добавляется по новому серверу (ну вот решили расшириться). Вы считаете допустимым, что раз в час у большинства пользователей будет рваться TCP соединение?


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

                                                  Второе — любое изменение на сети, это потенциальный риск возникновения outage (out of service). Избежать наличие человеческого фактора к сожалению нельзя, но его можно минимизировать (опять же плавно перенаправить клиентов на резервный ЦОД через тот же DNS механизм).

                                                  Между короткоживущими и долгоживущими сессиями огромная разница. Жаль, что вы этого не понимаете.


                                                  Я это прекрасно понимаю и даже лучше, чем Вы себе можете это представить. А вот меня Вы упорно не хотите слушать. Поймите одну простую вещь, что Network Design это всегда процесс trade-in vs trade-off.

                                                  Ну то есть постоянный сброс сессий — это нормально, а что там разработчики наворотили — не ваша забота.


                                                  У Вас опять разыгралось воображение? Есть SLA и требования, если что-то укладывается в эти требования (например потеря одного — двух пакетов или единичный разрыв сессии), то в рамках SLA такая ситуация считается нормальной. И как я уже сказал ранее, защита от подобных инцидентов может быть предусмотрена в программном обеспечении, таким образом если ПО легко справляется с подобного рода проблемой и без видимых проблем для пользователя, то это не является препятствием. В любых других ситуациях, изыскиваются варианты, которые устраивают обе стороны и без диалога с разработчиком или владельцем бизнеса это не представляется возможным. А если больная фантазия какого-то там “сетевого администратора” из enterprise решила иначе, то это сугубо его личные проблемы. Все остальное является ни кому не нужной демагогией.

                                                  Знаете, я вам советую НИКОГДА не заниматься ничем вроде дизайна сетей :)


                                                  А я бы на данном этапе Вашего развития, вообще бы запретил самостоятельно крутить “гайки”, не говоря уже про Network Design. Я не нуждаюсь в советах от человека, который:

                                                  1. плавает в routing & switching (не способен применять полученные знания далее copy & past)
                                                  2. не понимает как работает балансировка по ECMP (ибо понимающий человек не будет утверждать, что у него сами по себе меняются механизмы балансировки оборудования)
                                                  3. не понимает какие ограничения накладывает NAT
                                                  4. не понимает разницу между symmetrical и asymmetricl routing
                                                  5. не понимает как и когда таки нужно ставить NAT
                                                  6. не понимает где и когда нужно крутить метрики маршрутов

                                                  и я этот список могу продолжать. Поэтому знаете чего я Вам скажу? А не пойти бы Вам куда-нибудь в направлении default route?

                                                  Я и так прекрасно знаю сложность лабы. Так а зачем мне получать статус?


                                                  Откуда? Вы же сами написали, что не сдавали лабораторную работу. Просматривали дампы? О так Вы быть может дамповый CCNP? Знаете, очень похоже.

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


                                                  Форумные аналитики нынче доставляют :)

                                                  Плохо свечку держали. Я сдавал CCIE за свой счет и даже под это дело брал кредит в Росбанке и в партнерах не работал. Сдавал для себя.

                                                  А мне вот единственная причина получать шайбу — для себя. Никакого профита я от нее не получу.


                                                  Видели мы “таких”, одни не знают как работают таймеры в протоколах маршрутизации, а других (как у Вас) механизмы балансировки меняются сами по себе.

                                                  Да. Обычно авторитетом пытаются давить те, кому больше нечего сказать.


                                                  Если бы мне нечего было сказать по делу, то этого ответа бы и не было. Это как минимум логично и очевидно.

                                                  И я не вижу причин, по которым можно продолжать гордиться CCIE, сданным много лет назад.


                                                  А я вижу. Сдадите (если сдадите), тогда поговорим, а пока лучше молчите.

                                                  Ну разве что он был из первой тысячи, т.е. задолго до того, как сдача экзамена встала на поток, но это не ваш случай.


                                                  Не беспокойтесь, номер в пределах 10,000 Вы тоже не получите и даже меньше моего. И уж тем более это не про Ваш случай.

                                                  Как раз то, о чем я говорил. Anycast используется совместно с GSLB, но дальше — традиционные балансировщики.


                                                  Первое — про многоуровневую иерархию балансировки — это были мои слова
                                                  Второе — про DNS (GSLB) упомянул опять же я.

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

                                                  Никто не задействует anycast в пределах площадки для таких вещей.


                                                  Потому что так сказали Вы?

                                                  Anycast можно использовать в пределах одной площадки, ибо существуют такие понятия, как: hierarchical routing, routing topology hiding, route suppression, segmentation и т.д. и т.п. А в древовидной топологии и архитектуре, что называется сам бог велел использовать подобные инструменты. И если Вы не понимаете как пользоваться данными инструментами, то лучше сидите и молчите.

                                                  Using Anycast, there is no longer need for remote
                                                  failover using proxies, providing a cleaner solution since the client connects directly to the failover
                                                  location, whilst proxying usually makes you lose the client identifying information.

                                                  Снова вопрос стоит в распределении нагрузки между площадками.


                                                  Не стоит. Процитирую:

                                                  Services can be added to Anycast by simply configuring their
                                                  backends in a VIP on an Anycast enabled Load Balancer.

                                                  Там сказанно
                                                  Еще:
                                                  We configured the network environment so there is one subnet reserved for all Anycast virtual IPs
                                                  (VIPs).

                                                  Ага. Сами сервера имеют другие адреса, а VIPы — термин балансировщиков, которые делают destination nat.


                                                  Не знаю, что у Вас там NAT головного мозга или таки его Enterprise. В документе описано, как работают балансеры. А именно:

                                                  Раз

                                                  ip_vs is the Linux Kernel module for Load Balancing[0]. It currently supports tunnelling, half NAT and
                                                  Direct Routing (DR) modes. In our setup, all VIPs are configured using DR.

                                                  Два

                                                  Services can be added to Anycast by simply configuring their
                                                  backends in a VIP on an Anycast enabled Load Balancer.

                                                  И я хотел бы повториться, что это является кейсом для разработки собственного оборудования у Google. Что собственно ни как не противоречит моим словам.

                                                  Кстати, если сделать поиск по словам NAT или PAT, то это слово в документе встречается ровно один раз, слово “prox” — шесть раз и около 25 упоминаний при поиске по слову anycast. Но это так, к слову…

                                                  Ну а то, что отдается таким образом — та самая легковесная статика.


                                                  У них таким образом отдается как минимум:

                                                  DNS,
                                                  HTTP Proxy,
                                                  Radius,
                                                  Web SSO,
                                                  NTP,
                                                  LDAP

                                                  Об этом написано опять же в том документе. И ровно об этом же я Вам говорил ранее и повторюсь в очередной раз, схему с Anycast можно использовать не только для отдачи “легковесной статики”.

                                                  Кстати — в каком веке была выпущена та бумага?


                                                  Не беспокойтесь, документ был написан в этом веке, ибо в прошлом веке такие вопросы стояли не так актуально, как сейчас.

                                                  Вы путаете понятия.
                                                  Session persistence — это когда первое TCP соединение установилось с сервером, отработало, завершилось — и следующее TCP соединение должно попасть в точности на тот же сервер, а не на соседа.


                                                  Вы хоть понимаете, что за ересь Вы сейчас написали?

                                                  Во-первых, далеко не факт, что соединение должно попасть на тот же самый сервер.
                                                  Во-вторых, в схеме с балансировкой на базе NAT или L7 балансера, абсолютно нет ни какой гарантии того, что опять же этот клиент попадет в следующий раз на предыдущий сервер. Не в этом ли смысл (чтобы перенаправлять запросы с более загруженных элементов системы, на менее загруженные)?

                                                  Если говорить относительно термина Session persistence, то рассматривать его можно совершенно под разным углом. Ибо с точки зрения TCP новая сессия, это новая сессия, а вот, что там с точки зрения приложения, зависит уже от самого приложения. По-этому большинство distribute application или distribute services допускают переподключение или повторные tcp соединения (естественно в рамках RFC) на других элементах системы. Таким образом, в большинстве своих случаях, требование session persistence наиболее актуально для tcp соединения и уже гораздо реже для application (ибо как уже было сказано ранее, чаще всего application session ограничивается tcp session.

                                                  Вы же думаете, что это — «все пакеты TCP потока должны попадать на один и тот же сервер», что логично, однако при этом вы агитируете за нарушение этого принципа под предлогом «ну прилетит RST, ничего страшного».


                                                  Как уже было сказано ранее, единичный случай может быть не страшен, особенно если предусмотрен connection retry.

                                                  www.datadirect.com/resources/resource-library/odbc-developer-center/odbc-tutorials/failover-support-in-datadirect-connect-for-odbc-drivers/connection-retry

                                                  Да, именно статики.


                                                  И вполне возможно, что не только статики, просто Вы об этом не догадываетесь или не знаете.

                                                  Если хотите, можете спросить их, по какой причине они предоставляют доступ ко всему более сложному (от поиска до почты) только по старинке.


                                                  Не беспокойтесь, если надо будет, спрошу. Благо точки входа есть.

                                                  Я уже устал объяснять элементарные вещи — может, у них получится.


                                                  В этих элементарных вещях, Вы начинаете плавать. Да и слишком большую роль на себя берете.

                                                  Ах да — у них никакого anycast в пределах, только балансировщики. Anycast лишь для выбора ближайшей площадки.


                                                  Опять свечку держали? :)

                                                  То есть вы не против того, что веб-сервис может выдавать полсотни куков общим весом в пару килобайт, и при каждом новом запросе клиент будет слать их все?
                                                  Объяснить, почему это печально?


                                                  Это предмет для дискусси между разработчиками браузеров и веб приложений (я таковым не являюсь).

                                                  Объяснить, почему это печально?


                                                  Предпочитаю послушать мнение людей, которые на этом съели собаку. В данном случае, это явно не Ваше мнение.

                                                  Какая информация?


                                                  Например текст данной статьи располагается по конкретному адресу, к которому заинтересованный пользователь всегда может обратиться и получить необходимую информацию. Я уже молчу про всякие подобия RPC интерфейсов с реализацией через web. Или вы думаете, что кроме ODBC и SQL больше ничего не существует? В общем-то мне очень и очень странно слышать это от человека, работающего в enterprise.

                                                  Рассмотрим тот самый типовой пример с интернет-магазином. Вы говорите, что всё, что человек положил в корзину, надо хранить в куках либо в URL?


                                                  Я этого не говорил, опять же, это Ваш пример. В этом случае ни кто не мешает сохранить эти данные во временный “контейнер” в СУБД и связать эти данные с сессией пользователя.

                                                  Тоже аргумент кстати. Вот человека кинуло на сервер, он аутентифицировался. Дальше вы добавили в 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 процессов, коим обычно выступает СУБД.

                                                  Вот тут полностью согласен :)


                                                  Единственная причина, по которой я попросил проигнорировать решение на базе IP Source Route — это Security. И опять же, это не значит, что данное решение не будет работать, будет (но это сферический конь в ваккуме). Не удивлюсь, если Вы и этого не понимаете.

                                                  Осталось дописать что-то вроде «поднять TE туннели до серверов», и я окончательно выпаду в осадок :)


                                                  Первое — вы вообще догадываетесь про существование one hop MPLS TE туннелей? Или Ваша логика в очередной раз не позволяет Вам использовать one hop MPLS TE туннель между маршрутизаторами уровня агрегации и доступа?

                                                  Второе — если на сервере в виртуальной машине крутится какой-нибудь Cisco CSR 1000v и туда требуется привести MPLS TE туннель, то почему нет?

                                                  В целом, я уже устал Вам разжевывать и писать очередную простыню. Тем более мне за это денег не платят и на сей ноте я конкретно с Вами прощаюсь.
                                                  • 0
                                                    Итить твою налево какую простыню я пропустил…

                                                    Ну очень вкратце:
                                                    По-этому давайте Вы таки свои неуместные и нелепые уточнения оставите при себе?

                                                    Вы для начала покажите мне примерную конфигурацию, которой вы будете балансировать. Перечисление PA BGP и не только — это здорово, но на мой взгляд неуместно, да и CEF сам по себе не живет…
                                                    еще раз объясняю, что предлагал (я даже не поленился и нарисовал для Вас схему):

                                                    Смотрю на схему. Вижу следующее. Допустим, надо распределить нагрузку на адрес 1.1.1.1. На каждом leaf будет по одному серверу. Первые две картинки позволяют завести аж целых 4 сервера под VIP 1.1.1.1, если считать, что трафик проходит через «7», а коммутаторов всегда будет больше, по картинкам — аж семь. Ну здорово, экономичненько.
                                                    как один из возможных вариантов для разработки схемы с DR балансировкой и как следствие привело к разработке собственных коммутаторов у Google и Facebook.

                                                    Но у гугла и фейсбука нет TCP anycast. У них есть DNS.
                                                    в некоторых случаях — не страшно

                                                    Вы назвали какие-то мифические приложения… Хотя да, вот Outlook, работающий с exchange, при получении RST всего лишь кратковременно засветит сообщением «попытка подключения к серверу», ничего особо страшного. Но вы же про HTTP говорите. Там разрыв сессии неприятен. И собственные обработчики сложно сделать, учитывая повсеместный отказ от Flash. А уж сколько случаев, требующих sticky…
                                                    Вы нам лучше расскажите, как Вы будите бегать с банкой вазелина, когда произойдет split brain у Вашего HA кластера из кучи NAT устройств в следствии ошибок инженеров или разработчиков балансировщика.

                                                    А что вы сделаете, если из-за ошибки инженеров или бага в софте один сервер из нескольких десятков резко станет самым предпочтительным с точки зрения доставки трафика, и захлебнется?
                                                    Split brain в пределах площадки — зверь редкий и малоизученный. Если пара балансировщиков (из многих) разом возомнят себя главными, то страдает лишь часть VIPов, и проблема решается отключением одного из них. Но, честно говоря, я не слышал о таких авариях без серьезных факапов на сети, которые затронут еще и транспорт до самих серверов, и до интернета, и менеджмент вдобавок до кучи.
                                                    1. Для Вас такая архитектура абсолютно не поддается сопровождению.
                                                    2. У Вас там механизмы балансировки сами по себе меняются.
                                                    3. Дальше вала статических маршрутов ничего не видно.
                                                    4. Вы готовы “а бы как” и “а бы где” крутить метрики маршрутов без какого-либо понимания когда это необходимо делать, а когда не стоит.
                                                    5. С любовь к NAT и готовностью его ставить как папало и где попало (об этом поговорим ниже).
                                                    6. Слабое понимание routing & switching, шаг влево и Вы поплыли (Вас это характеризует скорее как copy & past инженера).

                                                    1. Вы никогда не сталкивались с подобными задачами, отсюда наивность и изобретание велосипедов, несмотря на то, что даже указываемые вами в качестве примеров компании не желают иметь ничего общего с вашим подходом.
                                                    2. У вас CEF всегда выдает один и тот же результат вне зависимости ни от чего…
                                                    3. Боюсь, что так. Вы предлагаете динамику — это по серверу на коммутатор, не более. А ведь можно было бы сделать и «по серверу на VLAN в пределах одного VRF», и эта схема даже могла бы работать, но вы этого не видите…
                                                    4. Человеческих ошибок не бывает, страховаться от ситуаций «одна команда на одном устройстве способна положить всё» не нужно. Все с вами понятно.
                                                    5. Ага.
                                                    6. И это мне говорит человек, который от меня узнал, что такое CEF и какие применения бывают у NAT.
                                                    Ни кто не мешает опять же переключить этих клиентов плавно на другой Virtual IP (или даже ЦОД) через тот же DNS

                                                    То есть чтобы ввести новый сервер в кластер, мы стопим кластер.
                                                    Это очевидно — пакет дропнется.

                                                    Да, вы не знаете, что такое NAT. Подумайте еще раз. Итак: к серверу прилетает пакет. Source IP принадлежит одному устройству, расположенному где угодно в том же ЦОДе. Вопрос. С какой стати пакету дропаться, и как он может разминуться с тем устройством?

                                                    Кстати, прочитайте про хак под названием «Direct Server Return».
                                                    в Интернете сплошь и рядом встречается ситуации с asymmetrical routing, сегодня пакет от клиента прилетает через один пир, а выходит через другой, завтра ситуация вообще может поменяться координальным образом.

                                                    Да, конечно. Но какая разница, что происходит между балансировщиком и клиентом, если пакеты хоть как-то достигают цели? Ни прямой, ни обратный пакет не могут миновать балансировщик, потому что на соответствующих этапах пути они нацелены на его IP адрес.

                                                    А у вас пакет улетит в ебеня… Ну собственно да, на дампах многому не научишься, могу посоветовать начать тот самый CCNA :)
                                                    Вы похоже живете в паралельной вселенной. Балансировка всегда осуществляется там, где есть трафик и пользователи.

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

                                                    Нет, тот же. Вам просто непонятны банальнейшие вещи, мы будто на разных языках говорим.
                                                    Вы готовы поставить NAT или L7 балансировщик не особо задумываясь о последствиях.

                                                    И это мне говорит человек, готовый ежеминутно дропать чужие сессии, и игонирирующий существование всех случаях, когда с его архитектурой сервис вообще не будет работать. Ну дела…
                                                    в этой ситуации возникает проблема suboptimal routing. Иначе говоря, весь трафик будет валиться в то место, где находится Ваш Virtual IP и как следствие создавать не нужную нагрузку на каналы связи. В случае с Anycast схемой между площадками, подобной проблемы вообще не возникает.

                                                    Ох…
                                                    В случае с anycast клиент рискует внезапно посреди сессии оказаться на другой площадке. Это является стоп-фактором для большинства архитектур, включая гугловую, фейсбучную, яндексную и прочие. Маленькие исключения делаются для маленьких задач вроде легкой килобайтной статики и DNS, и то в первом случае не всеми.

                                                    Задача распределения нагрузки по площадкам на самом деле решается GSLB, про который я вам уже рассказывал, но вы, кажется, забыли. Снова пример гибкости: если первый ЦОД в два раза мощнее второго, то и трафика на него можно пустить примерно в два раза больше. Если половина первого ЦОДа взяла и умерла, то пропорции трафика на лету можно изменить. Удобно. А anycast неуправляем вообще. Либо анонсишь, либо не анонсишь, либо анонсишь с препендами — всё.
                                                    Вторая потенциальная проблема — это end-to-end qos propаgation

                                                    «Нет, сынок, это — фантастика». Мы ведь говорим о фейсбуках? Впрочем, end-to-end qos может работать между площадками (где пользовательскому трафику делать нечего), если DF или очень-очень честный оператор.
                                                    а что будет когда у Вашего клиента станет 70,000 одновременных пользователей, а на Вашем NAT устройстве с этим Virtual IP закончятся tcp socket’ы

                                                    Подключений куда? К одному VIP? Знаете, я однажды разговаривал с человеком, уверенным, что к одному серверу может быть не более 64к коннектов к одному порту, потом порты заканчиваются…
                                                    Открою тайну. В целом, адреса, которые подставляются в source nat, могут быть совершенно произвольными. Это может быть хоть один адрес (я лишь для удобства говорил, что он равен VIP адресу), хоть целая сеть класса B. Требование лишь одно — чтобы сервера знали, что на эти адреса идти в сторону балансировщика. Так как анонсироваться наружу они не будут, глобальная маршрутизируемость им не требуется.
                                                    Шокирует, правда? И настраивается это тоже парой команд.
                                                    Если у Вас есть необходимость каждый час где-то, что-то ставить или подкручивать, то это говорит о явных проблемах в архитектуре, отсутствии дальновидности, а также планировании через одно место.

                                                    Вы знаете, сколько гугл ежедневно вводит в эксплуатацию серверов? Нагуглите, это впечатляет.
                                                    Избежать наличие человеческого фактора к сожалению нельзя, но его можно минимизировать (опять же плавно перенаправить клиентов на резервный ЦОД через тот же DNS механизм).

                                                    Итак, гугл, поднимая очередной сервер, уводит весь трафик из ЦОДа на случай, если что-то навернется. Я в восторге, честно!
                                                    Network Design это всегда процесс trade-in vs trade-off.

                                                    Так в чем trade-off NAT балансировщиков? Вы ведь ничего не назвали. Ну кроме split brain, что можно парировать массой возможных проблем с роутингом.
                                                    Есть SLA и требования, если что-то укладывается в эти требования (например потеря одного — двух пакетов или единичный разрыв сессии), то в рамках SLA такая ситуация считается нормальной.

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

                                                    Браузер входит в этот список? Или вы, как обычно, теоретизируете, не имея ни малейшей практики?
                                                    Вы же сами написали, что не сдавали лабораторную работу

                                                    Почему? Ходил в Крылатское. Потом, когда я говорил, что принципиально не открывал даже вполне легальные workbook'и, на меня косились как на сумасшедшего. А что поделать? Я не вы, у меня не было цели получить шайбу любой ценой, я скорее шел проверить собственный уровень.
                                                    Я сдавал CCIE за свой счет и даже под это дело брал кредит в Росбанке и в партнерах не работал. Сдавал для себя.

                                                    Судя по номеру, вы в то время работали в циске, так что это вполне отбилось… Ну а я как-то без кредита шел. Недешево, но интересно.
                                                    а других (как у Вас) механизмы балансировки меняются сами по себе.

                                                    Ну что поделать? CEF он такой, изменчивый, token bucket'ы имеют свойство метаться туда-сюда при изменениях входных данных…
                                                    А я вижу.

                                                    А вы считаете CCIE высоким уровнем квалификации? Мне казалось, это — скорее базовый уровень, не предполагающий глубокого погружения ни в одну из тем. Мне перечислить, сколько всего из общих концепций и деталей конкретных протоколов, а также аппаратных особенностей там пропущено? Да и что это за бред, когда достаточно знать на самом базовом уровне архитектуру простейшего 3750-го?
                                                    Второе — про DNS (GSLB) упомянул опять же я.

                                                    Очень странно. Ну да, вы его упомянули, но в предложенной вами архитектуре его нет. Есть такое сплошное дерево, расходящееся от клиентов до конечных серверов. Ну и вы с помощью GSLB забиваете гвозди — делаете то, чего легко добиться изменением файла зоны.
                                                    Потому что так сказали Вы?

                                                    Потому что это так и есть. Попробуйте найти пример — поймете.
                                                    Не стоит. Процитирую:

                                                    Ё-мое… Ну вы хоть читать научитесь.

                                                    Зайдем с другой стороны. Опишите детально роль, которую играют балансировщики в указанной архитектуре. Объясните, почему нельзя просто взять и убрать их, позволив клиентам сразу общаться с сервером.
                                                    Во-первых, далеко не факт, что соединение должно попасть на тот же самый сервер.

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

                                                    Опять глупость. Изучите механизмы session persistence — от запоминания балансировщиком адреса клиента до выдачи клиенту куки, которую тот при следующем обращении покажет, сообщая балансировщику, куда его кидать.
                                                    Если говорить относительно термина Session persistence, то рассматривать его можно совершенно под разным углом.

                                                    Смотрим на L5. В контексте балансировщика он очень четко понимается.
                                                    большинство distribute application или distribute services допускают переподключение или повторные tcp соединения (естественно в рамках RFC) на других элементах системы.

                                                    Ценой нечеловеческих усилий по репликации данных. То есть обычно так не делают. Из недостатков такого подхода лишь потеря небольшого числа сессий при аварии на сервере.
                                                    в большинстве своих случаях, требование session persistence наиболее актуально для tcp соединения и уже гораздо реже для application

                                                    И снова вы говорите глупость, которую не произнесет никто, решающий подобные задачи.
                                                    единичный случай может быть не страшен, особенно если предусмотрен connection retry.

                                                    Но этот единичный случай будет происходить постоянно. И всегда исходите из того, что приложение — говно, а потеря одного TCP соединения может обернуться многочасовым поэтапным перезапуском нескольких систем, потому что иначе они не поднимутся. Я серьезно. Мне с таким приходится жить, ничего не поделаешь, и даже архитекторы, знающие, насколько это плохо, не могут скомандовать это исправить. Надо ли говорить о стоимости простоя при разрыве такого соединения, и о том, с какой тщательностью у нас планируют изменения? Но в вашем мире, где единороги скачут по радугам, такого не бывает, и софт написан идеально :)
                                                    И вполне возможно, что не только статики, просто Вы об этом не догадываетесь или не знаете.

                                                    Нет, только статики. Я знаю.
                                                    Например текст данной статьи располагается по конкретному адресу, к которому заинтересованный пользователь всегда может обратиться и получить необходимую информацию

                                                    То есть и слово «безопасность» вам неведомо. Долой куки, используем URL для идентификации пользователя, нда…
                                                    Единственная причина, по которой я попросил проигнорировать решение на базе IP Source Route — это Security.

                                                    То есть, например, отсутствие актуальных реализаций, или хотя бы неконтролируемый размер заголовков — это мелочи? Я, кстати, не уверен, что такие пакеты вообще смогут хардварно передаваться современными платформами…
                                                    Или Ваша логика в очередной раз не позволяет Вам использовать one hop MPLS TE туннель между маршрутизаторами уровня агрегации и доступа?

                                                    А, ну да. В ситуации «по одному серверу на свитч» это может работать :)

                                                    Вкратце не получилось :(
                                                    • 0
                                                      Split brain в пределах площадки — зверь редкий и малоизученный.


                                                      Сталкивался с таким кейсом. Полностью резериврования коробока с процессорными картами. Поломался внутри IPC Communication, коробка ушла в цеклический ребут и не поднималась несколько часов. Помог cold power restart. Это Вам на подумать.

                                                      Судя по номеру, вы в то время работали в циске, так что это вполне отбилось…


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

                                                      Так в чем trade-off NAT балансировщиков? Вы ведь ничего не назвали. Ну кроме split brain, что можно парировать массой возможных проблем с роутингом.


                                                      На подумать — blogerator.ru/page/ddos-v-100-gbits-reportazh-s-linii-fronta-ot-ocevidca

                                                      Так, к слову… с Anycast такую атаку легче «абсорбировать»…

                                                      Решение на базе NAT просто умрет под такой атакой.

                                                      Остальные минусы были озвучены ранее.

                                                      Знаете, я однажды разговаривал с человеком, уверенным, что к одному серверу может быть не более 64к коннектов к одному порту, потом порты заканчиваются…


                                                      Речь не про это, а NAT-to-NAT communication. С 4 tuple механизмом все хорошо ровным счетом до тех пор, пока src и dst IP разные. К слову с этой проблемой иногда таки сталкиваются различные enterprise (особенно при подключении друг к другу).

                                                      Теперь по делу, Google использует свои LB на базе Linux с модулем lp_vs в режиме direct routing и как это не странно в anycast конфигурации. И как я уже говорил ранее для session persistance существует workaround, читайте:

                                                      www.linuxvirtualserver.org/docs/persistence.html

                                                      Вы бы таки этот вопрос изучили более детально.

                                                      Второе на top spine уровне может стоять high-end hardware решение на базе Cisco или Juniper, ибо там редко чего добавляется-меняется.

                                                      На тему всего остального ссылки по теме

                                                      1. Презентация Google — Anycast as a load balancing feature

                                                      www.usenix.org/legacy/events/lisa10/tech/slides/weiden.pdf

                                                      2. На тему Anycast в LAN окружении (внутри площадки)

                                                      blog.cloudflare.com/cloudflares-architecture-eliminating-single-p

                                                      2. На тему L3 Design презентация Microsoft от Петра Лапухова (бывший сотрудник Facebook, сейчас работает в подразделении Bing):

                                                      Драфт в ITEF — tools.ietf.org/html/draft-lapukhov-bgp-routing-large-dc-01
                                                      Презеентация к Draft'у — www.nanog.org/meetings/nanog55/presentations/Monday/Lapukhov.pdf

                                                      Изучайте, просвещяйтесь. У меня нет желания Вам чего-либо разжевывать.

                                                      Остальное стоит денег, ибо мое личное время.

                                                      До свиданья.
                                                      • 0
                                                        Поломался внутри IPC Communication, коробка ушла в цеклический ребут и не поднималась несколько часов. Помог cold power restart.

                                                        А я между тем говорил про две независимые коробки, реплицирующие состояние между собой… Одна ушла в циклический ребут? Мгновенный фейловер, и пусть себе ребутается — сервис не страдает.
                                                        На подумать — blogerator.ru/page/ddos-v-100-gbits-reportazh-s-linii-fronta-ot-ocevidca

                                                        О да, прекрасная статья.
                                                        с Anycast такую атаку легче «абсорбировать»…

                                                        Решение на базе NAT просто умрет под такой атакой.

                                                        Вам на подумать:
                                                        1) Компании, способные просто принять такой трафик, можно пересчитать по пальцам.
                                                        2) Это — UDP флуд. Цель — просто засрать все каналы. Его не надо натить. Его надо сразу дропать, и чем ближе к отправителю, тем лучше, чтобы он по внутренней сети не ползал. Соответственно, если каналы не загадились, то достаточно L4 ACL на периметре, чтобы справиться с ним.
                                                        3) В статье писалось, что куда бы ни направили этот флуд, всё падало…
                                                        Google использует свои LB на базе Linux с модулем lp_vs в режиме direct routing и как это не странно в anycast конфигурации.

                                                        Так когда была выпущена та статья, и какую роль там играют балансировщики? Зачем они нужны? Подумайте.
                                                        www.linuxvirtualserver.org/docs/persistence.html

                                                        Вы бы таки этот вопрос изучили более детально.

                                                        Чего и вам советую.
                                                        «For persistent ftp service, the template is created in the form like <cip, 0, vip, 0, rip, 0>, where cip is client IP address, vip is virtual IP address and rip is real server IP address.»
                                                        Это destination nat. VIP отличается от серверного IP. Коробка принимает обращения на собственный адрес и передает обращения серверам.
                                                        1. Презентация Google — Anycast as a load balancing feature
                                                        www.usenix.org/legacy/events/lisa10/tech/slides/weiden.pdf

                                                        Так это как раз самая простая схема. LAN окружение. N локаций, с точки зрения метрик идти до любого хоста из своей локации ближе, чем до других. Под каждый сервис на каждой локации поднят кластер серверов с обычным NAT балансировщиком поверх них, слушается anycast VIP. Смысл anycast исключительно в фейловере.
                                                        2. На тему Anycast в LAN окружении (внутри площадки)
                                                        blog.cloudflare.com/cloudflares-architecture-eliminating-single-p

                                                        «The routes to these servers are announced via the border gateway protocol (BGP) from the servers themselves»
                                                        Нет, спасибо.
                                                        «Beyond failover, we are beginning to experiment with BGP to do true load balancing»
                                                        Фейловера у них пока нет, только резервирование? Я не очень в курсе специфики работы Cloudflare, но, по-моему, их кейс нетипичен.
                                                        На тему L3 Design презентация Microsoft от Петра Лапухова

                                                        Ctrl+f, «anycast». Раздел «Traffic Engineering», фантазирование на тему перспектив SDN, всё.

                                                        Так по каким именно темам мне просвящаться?
                                                        • 0
                                                          А я между тем говорил про две независимые коробки, реплицирующие состояние между собой… Одна ушла в циклический ребут? Мгновенный фейловер, и пусть себе ребутается — сервис не страдает.


                                                          А что между двумя коробоками не бывает своего IPC? Ну, ну, ну…
                                                          Вы очень наивны.

                                                          Вам на подумать:
                                                          1) Компании, способные просто принять такой трафик, можно пересчитать по пальцам.
                                                          2) Это — UDP флуд. Цель — просто засрать все каналы. Его не надо натить. Его надо сразу дропать, и чем ближе к отправителю, тем лучше, чтобы он по внутренней сети не ползал. Соответственно, если каналы не загадились, то достаточно L4 ACL на периметре, чтобы справиться с ним.
                                                          3) В статье писалось, что куда бы ни направили этот флуд, всё падало…


                                                          1. В случае с Anycast, трафик таки будет перераспределяться между дата-центрами. От отправителя к ближайшему DC.
                                                          2. Для какой-то части мира (если DC недостаточное количество) сервис все еще может быть доступен, а не полностью лежать. Сюрприза, да?

                                                          Так когда была выпущена та статья, и какую роль там играют балансировщики? Зачем они нужны? Подумайте.


                                                          Представьте себе, что презентация была сделана между 7 и 12 ноября 2010 года.

                                                          Это destination nat. VIP отличается от серверного IP. Коробка принимает обращения на собственный адрес и передает обращения серверам.


                                                          У Вас NAT головного мозга :) Я уже Вам об этом говорил. Разжевываю на пальцах — CIP — Client IP Address, RIP — Real IP address на физическом интерфейсе, VIP — Virtual IP Interface коим может выступать loopback. Или Вы думаете, что Loopback может быть только у Cisco?

                                                          Так это как раз самая простая схема. LAN окружение. N локаций, с точки зрения метрик идти до любого хоста из своей локации ближе, чем до других. Под каждый сервис на каждой локации поднят кластер серверов с обычным NAT балансировщиком поверх них, слушается anycast VIP. Смысл anycast исключительно в фейловере.


                                                          Ой ли?

                                                          Нет, спасибо.


                                                          Процитирую ранее сказанное.

                                                          Вам кто-то мешает на сервере поднять квагу и с него выбросить virtual IP в routing domain? К слову в этом случае на физике даже у каждого сервера может быть свой IP. Я уже молчу про всякие бенифисы с route withdraw, если чего-то поломается внутри application на самой node, ибо реализовать подобный conditional advertisment можно с учетом множества параметров (начиная от PID state, заканчивая доступностью backend и IPC внутри самого приложения (например HTTP 500)). Вы такое ни на одном NAT'е не сделаете динамически!

                                                          Ctrl+f, «anycast». Раздел «Traffic Engineering», фантазирование на тему перспектив SDN, всё.


                                                          Some service providers build and operate data centers that support
                                                          over 100,000 servers. In this document, such data-centers are
                                                          referred to as «large-scale» data centers to differentiate them the
                                                          from more common smaller infrastructures. The data centers of this
                                                          scale have a unique set of network requirements, with emphasis on
                                                          operational simplicity and network stability.

                                                          This document attempts to summarize the authors' experiences in
                                                          designing and supporting large data centers, using BGP as the only
                                                          control-plane protocol.
                                                          The intent here is to describe a proven and
                                                          stable routing design that could be leveraged by others in the
                                                          industry.

                                                          Угу, Google, Facebook и Microsoft Bing со своим BGP — это все фантазии на тему перспектив SDN, а запрос в Google на самом деле отправляется через широкополосный кабель напрямую.

                                                          Так по каким именно темам мне просвящаться?


                                                          Позвольте отвечу Вам так —

                                                          image

                                                          По остальным темам можете не просвящаться…
                                                          • 0
                                                            Прежде чем я отвечу на остальное, все-таки попробуйте подумать над одним вопросом.
                                                            Разжевываю на пальцах — CIP — Client IP Address, RIP — Real IP address на физическом интерфейсе, VIP — Virtual IP Interface коим может выступать loopback.

                                                            Какую роль в данной архитектуре играет LinuxDirector, как осуществляется функционал «The connections for any port from the client will send to the server» и почему его нельзя выбросить из схемы? Если несколько серверов слушают один адрес, то каким же образом балансировщик-LinuxDirector избирательно направляет клиентские сессии на конкретные сервера? Как выглядят адреса в IP заголовке на внутреннем и внешнем плечах балансировщика?
                                                            • 0
                                                              • 0
                                                                Почитал. «The load balancer simply changes the MAC address of the data frame to that of the chosen server and restransmits it on the LAN. This is the reason that the load balancer and each server must be directly connected to one another by a single uninterrupted segment of a LAN
                                                                Как думаете, does it scale? Я вот как-то сразу откинул этот вариант, ведь вы вроде говорили о серьезных нагрузках, о красивом дизайне, а тут сплошной L2… Нет, не думаю, что кто-то так делает. Почитайте про DSR (Direct Server Return), который я уже упоминал. Концепция идентична: в одну сторону идем через балансер, обратно — нет. Только это уже L3, что отменяет требование «всех в один огромный VLAN» (а это всегда единая точка отказа вне зависимости от того, STP там, агрегация или нечто TRILL-образное). И назовите недостатки задействования NAT в L3 схеме по сравнению с L2 схемой, если все равно необходимо хранить весь state.

                                                                Вот что делать с указанными вами проблемами вида «весь трафик должен идти через один балансировщик»? Они все поголовно встречаются в DR. Как организовано резервирование балансировщиков? Как балансировщик переживет DDOS, о котором вы так нервничаете? Ну да, обратный трафик с него снят — во многих случаях это несущественно.
                                                                • 0
                                                                  Как думаете, does it scale?


                                                                  Вполне.

                                                                  Я вот как-то сразу откинул этот вариант, ведь вы вроде говорили о серьезных нагрузках, о красивом дизайне, а тут сплошной L2…


                                                                  L2 только на последнем хопе.

                                                                  Нет, не думаю, что кто-то так делает.


                                                                  Google делает, CloudFlare делает.

                                                                  Только это уже L3, что отменяет требование «всех в один огромный VLAN» (а это всегда единая точка отказа вне зависимости от того, STP там, агрегация или нечто TRILL-образное).


                                                                  per leaf, да и вообще сегментироваться ни кто не мешает.

                                                                  Только это уже L3, что отменяет требование «всех в один огромный VLAN» (а это всегда единая точка отказа вне зависимости от того, STP там, агрегация или нечто TRILL-образное).


                                                                  Пффф, всегда можно собирать полукольцами свитчи и «приземлять» их на L3 интерфейсы. Ни какой STP в этом случае не нужен. Кроме того, LAG ни кто не отменял.

                                                                  И назовите недостатки задействования NAT в L3 схеме по сравнению с L2 схемой, если все равно необходимо хранить весь state.


                                                                  Ранее уже было все озвучено, я Вам не попугай.

                                                                  Вот что делать с указанными вами проблемами вида «весь трафик должен идти через один балансировщик»? Они все поголовно встречаются в DR. Как организовано резервирование балансировщиков?


                                                                  Anycast + BGP

                                                                  Как балансировщик переживет DDOS, о котором вы так нервничаете? Ну да, обратный трафик с него снят — во многих случаях это несущественно.


                                                                  Абсолютно нормально переживет. Живой пример — CloudFlare на базе Anycast сервиса помогли восстановить работу сервиса Spamhaus и справиться с DDOS атакой в 300 Гбит/сек.

                                                                  blog.cloudflare.com/the-ddos-that-knocked-spamhaus-offline-and-ho
                                                                  habrahabr.ru/post/174483/

                                                                  Ну и напоследок:

                                                                  TCP Anycast — Don’t believe the FUD
                                                                  Operational experience with TCP and Anycast.

                                                                  www.nanog.org/meetings/nanog37/presentations/matt.levine.pdf

                                                                  Выдержки из презентации:

                                                                  Other presentations have made reference to existing deployments..that’s us!
                                                                  TCP Anycast not only works, it has been used in production for years.

                                                                  Результаты исследования по данному вопросу:

                                                                  30k download sampled from 31 locations every 5 minutes. (or an average of 1 poll every 9.6 seconds)
                                                                  Methodology: Analyze packet captures — look for new TCP sessions not beginning with SYN.
                                                                  Compare that against global active connection table.

                                                                  ‘POP Switch’ failure rates:
                                                                  Overall: 0.0006%
                                                                  Long-Lived: 0.017%

                                                                  Conclusions

                                                                  In our experience, stateful anycast is not
                                                                  inherently unstable
                                                                  , and failure/disconnect
                                                                  rates are inline with offering unicast services.

                                                                  “Trust us, it works.” (tm)

                                                                  Stop telling people anycast doesn’t work for
                                                                  TCP if you haven’t tested it, it just makes us
                                                                  mad. :)))

                                                                  Ну и собственно то, о чем я говорил раннее:

                                                                  If your application cannot handle TCP/IP
                                                                  failures gracefully, do not run anycast — in
                                                                  fact, don’t run it on the internet.
                                                                  • 0
                                                                    Добавлю на тему резервирования, если очень хочется, то ни кто не мешает балансировщики ставить в кластеры.
                                                                    • 0
                                                                      А что, можно их не ставить хотя бы в A/S кластер? Не знал, даже как-то не задумывался о таком :)

                                                                      Но опять же, буквально только что вы уверяли меня, что никаких балансировщиков, только равномерное ветвление трафика от точки входа в сеть до серверов. Что изменилось?
                                                                  • 0
                                                                    L2 только на последнем хопе.

                                                                    Сразу за балансировщиком. Будете оверлеи пиарить? :) Кстати, Amazon хвастался, что у них почти нет L2…
                                                                    Google делает, CloudFlare делает.

                                                                    Google делает DR для собственных внутренних сервисов. Да, в кампусах у них стоят обычные шеститонники, насколько мне известно, и их вариация на тему SDN вряд ли есть.
                                                                    Про Cloudflare — покажите, где у них L2 DR…
                                                                    per leaf, да и вообще сегментироваться ни кто не мешает.

                                                                    Опять же — на каждом leaf будет по балансировщику. Не очень хорошо.
                                                                    всегда можно собирать полукольцами свитчи и «приземлять» их на L3 интерфейсы. Ни какой STP в этом случае не нужен. Кроме того, LAG ни кто не отменял.

                                                                    Мне ли вам объяснять, сколько всего интересного может нарушить работу L2 сегмента помимо штормов? Да и шторм даже с полукольцом не исключен. Всегда есть шанс напутать в процессе кроссировки и организовать полное кольцо. Предваряя возражения: сочувствую, если вы в процессе проектирования сетевой архитектуры исходите из «все поголовно сетевые администраторы и осуществляющие кроссировку инженеры — роботы, не знающие ошибок». Инфраструктура должна прощать небольшие и средние ошибки и не становиться от них колом.
                                                                    Ранее уже было все озвучено, я Вам не попугай.

                                                                    Ранее было озвучено про боттлнеки и DDOS. Так что повторите — я настаиваю. В случае простых сервисов вроде HTTP я не представляю себе и связанные с собственно трансляцией адресов/портов проблемы.

                                                                    Вы, кстати, осознаете, что схема с DR вообще не является anycast? Anycast при таком подходе может быть лишь на участке от клиента или предыдущего L7 звена до балансировщика. А между балансировщиком и серверами нет маршрутизации, потому и anycast'а быть не может.
                                                                    Anycast + BGP

                                                                    То есть много балансировщиков, много локаций. Это в точности то, что я предлагал выше, но вам эта архитектура почему-то не понравилась, а сейчас нравится. Нда…
                                                                    CloudFlare на базе Anycast сервиса помогли восстановить работу сервиса Spamhaus и справиться с DDOS атакой в 300 Гбит/сек.

                                                                    Замените «anycast» на «GSLB». Что изменится помимо гораздо большей управляемости?
                                                                    При таком флуде вопрос в каналах. Их каналы широкие, выдержали. Но благодаря anycast'у они не могли сделать так, чтобы, скажем, 10% трафика с ЦОД «А» перетекло на ЦОД «Б». В итоге повезло — скажем, не было такого, что расположенная в Китае площадка загнулась под напором миллиарда китайцев, пока остальные площадки загружены на 50-60%. Препендами уводить трафик — ну очень не гибко.
                                                                    Выдержки из презентации

                                                                    Сейчас другими поделюсь.
                                                                    «Anycast nodes that do not keep state must be geographical separated»
                                                                    «Nodes that are near by could possibly require state between each node if routes are unstable.»
                                                                    ‘POP Switch’ failure rates:
                                                                    Overall: 0.0006%
                                                                    Long-Lived: 0.017%

                                                                    А я натыкался на иные материалы — вплоть до фактически неработоспособного сервиса у части юзеров. Поищу.
                                                                    • 0
                                                                      Сразу за балансировщиком. Будете оверлеи пиарить? :)


                                                                      Всегда есть different approach, как с оверлеем, так и без. Вопрос лишь заключается в оптимальности.

                                                                      Кстати, Amazon хвастался, что у них почти нет L2…


                                                                      Послушайте, в CDN есть множество других способов организовать Anycast-Aware Transport и как я уже говорил ранее, тут многое зависит от реализации приложений… Это был всего лишь один из примеров.

                                                                      В конце концов судя по всему, Вы вообще даже не подозреваете о существовании или имеет слабое представление о таких вещей, как Trickles или TCP Socket Migration (TCP Offload). Да и вообще, если мы с Вами говорим про Web, то и там есть очень простые способы перекинуть нагрузку и сделать load-balancing средствами самого http протокола (например сделать http redirect на unicast ноду), в этом случае «длинна» первоначальной сессии вообще будет в пределах 100мс.

                                                                      Google делает DR


                                                                      Ну хорошо, хоть не NAT уже :)

                                                                      для собственных внутренних сервисов.


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

                                                                      Да, в кампусах у них стоят обычные шеститонники,


                                                                      Причем здесь кампус и ЦОД?

                                                                      насколько мне известно, и их вариация на тему SDN вряд ли есть.


                                                                      Вы про OpenFlow? А что OpenFlow теперь закрытый протокол?
                                                                      К слову многие их разработки или доступны или имеют open-source аналоги (например таже реализация СУБД big table).
                                                                      Опять же — на каждом leaf будет по балансировщику. Не очень хорошо.


                                                                      Послушайте, наличие distributed модели надиктовано как раз минусами централизованного подхода, который имеет вполне конкретные ограничения — pps, количество тех же translations-states, memory, control-plane overall system performance и system scalability. Вам кажется, что 1 Террабит или 20 млн. трансляций это уже чудовищные цифры, поверьте это еще не предел и если Вы со своей конторой не сталкивались с такими цифрами, это еще не значит, что перед другими конторами не стоят подобные вопросы и проблемы.

                                                                      Мне ли вам объяснять, сколько всего интересного может нарушить работу L2 сегмента помимо штормов? Да и шторм даже с полукольцом не исключен. Всегда есть шанс напутать в процессе кроссировки и организовать полное кольцо. Предваряя возражения: сочувствую, если вы в процессе проектирования сетевой архитектуры исходите из «все поголовно сетевые администраторы и осуществляющие кроссировку инженеры — роботы, не знающие ошибок». Инфраструктура должна прощать небольшие и средние ошибки и не становиться от них колом.


                                                                      А вот тут уже сразу видно полное отсутствие опыта эксплуатации в операторах связи и больших l2 сетей :) Вы думаете ни кто не использует такие технологии, как Metro Ethernet (Carrier Ethernet)? Вы очень и очень сильно ошибаетесь. В том числе используют дизайны без STP, как раз из-за fast convergency l2 topology. Да и вообще, чего Вы знаете про Metro Ethernet и его эксплуатацию, сидя в своем enterprise? Лучше почитайте про всякие storm-control, WDM, кольцевые и полукольцевые топологии, VPLS split-horizont, EVC, Mac-in-Mac encapsulation, QinQ, bpdu-guard, udld и err-disable и тд и тп. И кстати L2 полукольцевые топологии тоже можно делать, с резервированием ни чуть не хуже кольцевых (в том числе с учетом требований географической распределенности обходных маршрутов), sic без STP.

                                                                      Ранее было озвучено про боттлнеки и DDOS. Так что повторите — я настаиваю.


                                                                      Повторяю:

                                                                      overall system performance
                                                                      overall system scalability
                                                                      CPU performance
                                                                      Memory size and performance
                                                                      Bandwidth Interface
                                                                      PPS Performance (потенциально еще и performance degradation with multiple features (например NAT+FW+uRPF check+multicast и тд и тп)
                                                                      Number of Translations
                                                                      Number of States
                                                                      Single point of failure (Split Brain, Geographical location)
                                                                      Customization for service availability & performance signalling
                                                                      Suboptimal routing
                                                                      Routing (и другие entries) table
                                                                      Routing domain design with NAT implementation
                                                                      потенциально additional latency & delay (но это скорее интересно всяким HFT)
                                                                      ну и куча других потенциальных Architectural Hardware Limitations и Bottlenecks
                                                                      и тд. и тп.

                                                                      Ну и кстати, на подумать (цифры для медитации) статистика failures у Google:

                                                                      Typical first year for a new cluster:

                                                                      ~0.5 overheating (power down most machines in <5 mins, ~1-2 days to recover)
                                                                      ~1 PDU failure (~500-1000 machines suddenly disappear, ~6 hours to come back)
                                                                      ~1 rack-move (plenty of warning, ~500-1000 machines powered down, ~6 hours)
                                                                      ~1 network rewiring (rolling ~5% of machines down over 2-day span)

                                                                      ~20 rack failures (40-80 machines instantly disappear, 1-6 hours to get back)

                                                                      ~5 racks go wonky (40-80 machines see 50% packetloss)

                                                                      ~8 network maintenances (4 might cause ~30-minute random connectivity losses)
                                                                      ~12 router reloads (takes out DNS and external vips for a couple minutes)

                                                                      ~3 router failures (have to immediately pull traffic for an hour)

                                                                      ~dozens of minor 30-second blips for dns

                                                                      ~1000 individual machine failures

                                                                      ~thousands of hard drive failures

                                                                      slow disks, bad memory, misconfigured machines, flaky machines, etc.

                                                                      Long distance links: wild dogs, sharks, dead horses, drunken hunters, etc.

                                                                      В случае простых сервисов вроде HTTP я не представляю себе и связанные с собственно трансляцией адресов/портов проблемы.


                                                                      Точно также нет ни каких проблем с первоначальным http-redirect'ом c anycast сервера на unicast node (L7 балансировка средствами самого HTTP-Web сервера).

                                                                      Ну и как уже было сказанно ранее, классический NAT не обладает функционалом Web Application Firewall, Caching и т.д. и т.п.

                                                                      Вы, кстати, осознаете, что схема с DR вообще не является anycast?

                                                                      Ну сам по себе, отдельно взятый хост тоже не является Anycast. Речь идет о routing & design approach.
                                                                      То есть много балансировщиков, много локаций. Это в точности то, что я предлагал выше, но вам эта архитектура почему-то не понравилась, а сейчас нравится. Нда…


                                                                      Вы утверждали обратное, что Anycast ни кто не применяет локально. Я Вам говорю о том, что применяют в том числе с использованием BGP для сигнализации доступности конкретной ноды внутри сети. Поэтому речь идет не только о multiple location, но и в том числе об anycast внутри сети.

                                                                      Замените «anycast» на «GSLB». Что изменится помимо гораздо большей управляемости?


                                                                      Эммм?? Мне кажется, какой-то странный пример, да еще и в отрыве от реалий.

                                                                      При таком флуде вопрос в каналах. Их каналы широкие, выдержали. Но благодаря anycast'у они не могли сделать так, чтобы, скажем, 10% трафика с ЦОД «А» перетекло на ЦОД «Б». В итоге повезло — скажем, не было такого, что расположенная в Китае площадка загнулась под напором миллиарда китайцев, пока остальные площадки загружены на 50-60%. Препендами уводить трафик — ну очень не гибко.

                                                                      Вы опять не поняли. Вам бы следовало подумать над следующими вопросами:

                                                                      а) какой интерфейс сможет прокачать через себя 300 Гигабит/сек
                                                                      б) какой оператор сможет принять столько трафика в одной точке и потом транзитом его выплюнуть.

                                                                      Тут не так давно наши магистральщики ложился от атаки в 100 Гбит/сек, а Вы про жирные каналы в ЦОД… Мда… Сразу видно, Вы в курсе всего.

                                                                      У CloudFlare более 20 ЦОД’ов, которые раскиданы по всему миру, с Anycast enabled services (в том числе для web). И конкретно в данном кейсе, они не скрывают, что атаку абсорбировали благодаря Anycast.
                                                                      Кроме того, необязательно prepend’ить свои маршруты, у нормальных операторов для этого уже есть реализованные routing policy на базе тех же bgp communities.

                                                                      И вообще, зачем им кидать 10% трафика из ЦОД А, в ЦОД Б? Ну и если даже надо, опять же… решаемо.

                                                                      А что в Китае нельзя поставить несколько ЦОДов в разных местах? Часть страны запросто может идти на один ЦОД, а другая часть на другой.

                                                                      Сейчас другими поделюсь.
                                                                      «Anycast nodes that do not keep state must be geographical separated»
                                                                      «Nodes that are near by could possibly require state between each node if routes are unstable.»


                                                                      И? Мы об этом уже с Вами битый день разговариваем. В том числе и workaround’ах и solution’ах по данной проблематике.

                                                                      А я натыкался на иные материалы — вплоть до фактически неработоспособного сервиса у части юзеров. Поищу.


                                                                      Ну с дуру можно и кое что другое сломать :)

                                                                      PS: Резюмирую беседу.

                                                                      1. Используют схемы с иерархической балансировкой — DNS — Anyacst between multiple location — Anycast inside location, далее возможны развилки fully anycast service (если приложение позволяет), partial anycast with LB
                                                                      2. NAT стараются не использовать, ибо по возможностям уступает proxy и имеет целый ряд ограничений. Да и сами Вы уже признали NAT злом ранее.
                                                                      3. Распределенная архитектура приложений (в том числе предусматривающая tcp socket migration/tcp offload и тд и тп).
                                                                      4. Custom TCP/IP Stack — Server Side или Statless Network Stack (например реализация Trickles).
                                                                      5. BGP as Signalling mechanism
                                                                      6. L7 балансировка средствами high level protocols

                                                                      На этом отваливаюсь из топика.
                                                    • 0
                                                      Первые две картинки позволяют завести аж целых 4 сервера под VIP 1.1.1.1, если считать, что трафик проходит через «7», а коммутаторов всегда будет больше, по картинкам — аж семь. Ну здорово, экономичненько.


                                                      Вы или глупы или прикидываетесь? Вам кто-то мешает на сервере поднять квагу и с него выбросить virtual IP в routing domain? К слову в этом случае на физике даже у каждого сервера может быть свой IP. Я уже молчу про всякие бенифисы с route withdraw, если чего-то поломается внутри application на самой node, ибо реализовать подобный conditional advertisment можно с учетом множества параметров (начиная от PID state, заканчивая доступностью backend и IPC внутри самого приложения (например HTTP 500)). Вы такое ни на одном NAT'е не сделаете динамически!
                                                      • 0
                                                        Вам кто-то мешает на сервере поднять квагу и с него выбросить virtual IP в routing domain?

                                                        Наверное, в первую очередь то, что это требует, собственно, поднятия роутинга на сервере. Такое когда-то было модно, потом от этого начали массово отказываться.

                                                        И вы получаете не более 16 серверов на vrf на предпоследнем хопе, без гибкого распределения нагрузки, без session persistence.
                                                        реализовать подобный conditional advertisment можно с учетом множества параметров (начиная от PID state, заканчивая доступностью backend и IPC внутри самого приложения (например HTTP 500)). Вы такое ни на одном NAT'е не сделаете динамически!

                                                        Балансировщик может оценивать живость сервера не только по кипалайвам, но и по более сложным схемам. От «ответил ли сервер на реальный SYN пакет» до «вернул ли он клиенту нормальные данные, или 500-е ошибки». Есть, кстати, и варианты с динамическим перераспределением нагрузки в зависимости от времени между запросом клиента и ответом сервера.
                                                        • 0
                                                          Наверное, в первую очередь то, что это требует, собственно, поднятия роутинга на сервере. Такое когда-то было модно, потом от этого начали массово отказываться.


                                                          Кто-то отказался, а кто-то нет.

                                                          И вы получаете не более 16 серверов на vrf на предпоследнем хопе, без гибкого распределения нагрузки, без session persistence.


                                                          Вернемся к схеме —

                                                          image

                                                          Маршрутизаторы 1, 2, 3 и 4 анонсируют префикс А.

                                                          Маршрутизаторы 5 и 6 имеет по четыре маршрута на префикс А.

                                                          Sic! Маршрутизатор 7 имеет всего два маршрута на префикс А (через 5 и 6).

                                                          Ооо, поглядите, а тут оказывается у нас с Вами Hierarchical Token Bucket, правда замечательно?

                                                          Посчитаете?

                                                          Мы еще не учли backbone, а смотрим только на отдельно взятый leaf… К тому же, а кто Вам сказал, что у LB на базе ip_vs, бакетов может быть только 16 (подсказка, у LVS количество бакетов ограничено 2^12)?

                                                          Дальше считать будем?

                                                          Балансировщик может оценивать живость сервера не только по кипалайвам, но и по более сложным схемам. От «ответил ли сервер на реальный SYN пакет» до «вернул ли он клиенту нормальные данные, или 500-е ошибки». Есть, кстати, и варианты с динамическим перераспределением нагрузки в зависимости от времени между запросом клиента и ответом сервера.


                                                          Если в ответ веб-сервер выдает 200ый ответ, а пользователь на самом деле получает хрен с маслом, то увы не спасет :) Так что, в плане кастомизации, вариант с BGP Signalling не так уж и плох.
                                                        • 0
                                                          без session persistence.


                                                          Читаем — www.linuxvirtualserver.org/docs/persistence.html
                                                  • 0
                                                    И да, забыл:
                                                    Я почему-то не удивлюсь, если внутри Вашей сети NAT на NAT’е и NAT’ом погоняет.

                                                    Ярость затмила вам разум :) Я ведь изначально писал, что NAT — отстой. И я вообще сторонник назначать прямо на интерфейсы серверов глобально маршрутизируемые адреса, пусть это и лишает некоторой гибкости.

                                                    Однако, есть один случай, когда NAT реально полезен, повсеместно используется и никуда не денется даже в IPv6, потому что без него нельзя…

                                                    А у вас какая-то религиозная война против NAT. Вы его отвергаете даже там, где альтернативы куда кошмарнее, не задумываясь над тем, что это просто инструмент, который иногда может сослужить хорошую службу, в зависимости от задачи.
                                                    • 0
                                                      NAT нужен только для двух вещей:

                                                      1. Address conservation — костыль
                                                      2. Protocol Translation (NAT-PT) или как его еще называют CGN — Carrier Grade NAT — костыль

                                                      Для остального есть лучше варианты.
                                                      • 0
                                                        Для остального есть лучше варианты.

                                                        Но нет. Для балансировки вы рассмотрели ровно один сценарий — «колоссальных масштабов трафик, какого 99% покупателей балансировщика не просто не видели, а по техническим причинам даже увидеть не могут, каналы не те» + «приложение простое как кувалда, вроде DNS, не требует session persistence» + «клиенту хочется иметь десятки свитчей там, где можно обойтись парой».

                                                        Как думаете, существуют ли другие кейсы, в которых ECMP + anycast является не просто кошмарным костылем, но просто не будет работать, а вот приткнуть в уголке балансировщик с source и destination nat окажется самым правильным решением? Помните, я рассказывал, как в моем случае выглядит задача «забабахать балансировку сервиса»?
                                        • 0
                                          Опишите с точки зрения CEF (и его bucket'ов и хеша), что происходит, когда к двум существующим ECMP маршрутам добавляется третий. Вы, видимо, думаете, что те, кто раньше хешировались в те два пути, останутся на нем же, а новые плавно потекут на третий (как это происходит с NAT балансировщиками)?


                                          Кстати… ни кто не запрещает воспользоваться опцией IP Source Route (например Loose Source Routing) в качестве техники pining для привязки конкретного flow к конкретному серверу. В этом случае переход будет выполняться плавно и без каких либо балансировщиков.
                                          • 0
                                            Да, про IP Source Route прошу не воспринимать серьезно, это я уже разогнался ;)))
                                    • 0
                                      Слежу за вашей перепиской. Вы начинаете придираться к словам Игоря. Что вы пытаетесь доказать?
                                      • 0
                                        Я нигде стараюсь не придираться к словам. Просто Игорь пишет ну очень забавные вещи… Скажем, если бы я обратился к интегратору с просьбой разработать архитектуру, и мне предложили бы нечто вроде сказанного Игорем, то я бы больше не работал с тем интегратором.
              • 0
                Если в вашем абзаце про ALG слово NAT/PAT заменить на Stateful Firewall получим _то же_ самое. Вы с этим не согласны?

                NAT — это сетевой инструмент (точка). Почему вы его воспринимаете только как метод выпустить локалку наружу? Это самый распространенный, но не единственный способ использования NAT-а.

                И еще.
                Давайте проведем эксперимент? Хотя бы мысленный?
                Возьмем роутер, не покажем вам настройки, не покажем вам какая за ним локалка. Угадаете что на это роутере настроено firewall или NAT — с одной попытки?
                • 0
                  Если в вашем абзаце про ALG слово NAT/PAT заменить на Stateful Firewall получим _то же_ самое. Вы с этим не согласны?


                  Нет. Есть разница. Stateful Firewall по большей части занимается тем, что отслеживает состояния сессий и проводит проверку/фильтрацию сетевого подключения согласно правилам. Реализация ALG для NAT/PAT может подразумевать под собой более глубокое «внедрение» в подключение, вплоть до подмены информации внутри сессии (src и dst IP).

                  NAT — это сетевой инструмент (точка). Почему вы его воспринимаете только как метод выпустить локалку наружу? Это самый распространенный, но не единственный способ использования NAT-а.


                  Потому что NAT как балансировщик не достаточно умен. Иначе говоря, он оперирует только информацией сетевого уровня и исключает особенности приложений.

                  И еще.
                  Давайте проведем эксперимент? Хотя бы мысленный?
                  Возьмем роутер, не покажем вам настройки, не покажем вам какая за ним локалка. Угадаете что на это роутере настроено firewall или NAT — с одной попытки?


                  Вы не поверите, но таки наличие NATа можно определить с большой долей вероятности. Более того существуют вполне себе рабочие методы.
                  • 0
                    Потому что NAT как балансировщик не достаточно умен. Иначе говоря, он оперирует только информацией сетевого уровня и исключает особенности приложений.

                    Изучите возможности тех же F5, или цитриксовых нетскейлеров, или даже цискиных ACEов. Они прекрасно работают на L7 с массой разных протоколов. Несколько некорректно говорить «NAT» в данном контексте, хотя можно сказать, что просто у всех балансировщиков неимоверно навороченные ALG с морем настроек.
                    • 0
                      Давайте не будем мешать яйца в корзинах? По факту да, это уже не совсем NAT, а скорее аппаратная реализация прокси сервера или некоторое подобие DPI load-balance. Кстати именно по этой причине и существует такой класс устройств, как — балансировщики.

                      Тот же ACE может проводить проверку health check при балансировке, а это уже явно не функционал NAT, ALG или Stateful Firewall.

                      Собственно вся речь и сводится к тому что, NAT как средство балансировки далеко не является оптимальным решением.
                      • 0
                        По факту да, это уже не совсем NAT, а скорее аппаратная реализация прокси сервера

                        А почему встроенный в любую адекватную NATилку ALG нельзя назвать аппаратной реализацией прокси сервера? Они ведь и TCP proxy нередко являются.
                        (да и вообще сейчас хардварные балансировщики на самом деле очень даже софтверные, просто с предельно оптимизированным и специализированным кодом, и с небольшим количеством вспомогательной логики под задачи вроде шифрования)
                        NAT как средство балансировки далеко не является оптимальным решением.

                        Но NAT как механизм балансировки прекрасен. Вы сможете без него принять на один IP адрес сотни тысяч CPS, десятки/сотни гигабит трафика и так далее?

                        Никто не спорит, что NAT балансировка, при которой входящие соединения вслепую разбрасываются по нескольким серверам, является злом. Но я не думаю, что кто-то такое делает.
                        • 0
                          А почему встроенный в любую адекватную NATилку ALG нельзя назвать аппаратной реализацией прокси сервера?


                          Потому что модель OSI, потому что NAT+ALG не обеспечивает кэширование, потому что ALG это ALG а не специализированное прокси приложение. Оно всегда будет проигрывать в возможностях прокси серверу :)

                          Они ведь и TCP proxy нередко являются.


                          И не более того.

                          (да и вообще сейчас хардварные балансировщики на самом деле очень даже софтверные, просто с предельно оптимизированным и специализированным кодом, и с небольшим количеством вспомогательной логики под задачи вроде шифрования)


                          У которых свои ограничения, например специфика приложения, скорость реакции и костамизация под конкретные нужды клиента со стороны производителя. :)

                          Но NAT как механизм балансировки прекрасен. Вы сможете без него принять на один IP адрес сотни тысяч CPS, десятки/сотни гигабит трафика и так далее?


                          Он ужасен и чем серьезнее нагрузка, тем он ужаснее :) С anycast схемой я смогу принять даже больше, чем Вы сможете принять со своим NAT'ом.

                          Никто не спорит, что NAT балансировка, при которой входящие соединения вслепую разбрасываются по нескольким серверам, является злом. Но я не думаю, что кто-то такое делает.


                          Ну и как уже было сказано ранее, сам по себе NAT зло и костыль :)
    • 0
      Да есть там NAT:
      1 IPv6 transition mechanisms
      2 NAT — In Depth
      Другой момент, что применения NAT для сокрытия содержимого будет маловато, хорошо бы ещё проксировать всякое http c ftp.
      Самое главное — зачем вам это? Скрывать планшетник и домашний компьютер? Так они со всеми этими наворотами выдадут себя с головой.
  • +5
    Извиняюсь за занудство, но список поддерживаемых телефонов, отсортированный по производителю (или даже просто по алфавиту) выглядел бы куда лучше, а то сейчас очень сложно что-то там найти.
    • +1
      Fixed. Спасибо!
      • +1
        <здесь был ошибочный комментарий>
  • +3
    Сдаётся мне, что когда придумывали IPv4, точно никак не предполагали, что принтерам, фотоаппаратам и уж тем более холодильникам понадобится доступ в сеть.
    • 0
      так же как нам сложно представить чему еще понадобится IPv6 адреса… ручкам, окнам, органам?
      • 0
        Сейчас, судя по dual-stack, IPv6-адреса понадобились IPv4-адресам.
    • 0
      IPv4 придумывали для «полномасштабного эксперимента» и ожидали, что он достаточно быстро будет заменён на следующую версию (версии с 0й по 3ю использовались в подобных же экспериментах с 1974 по 1977й год — примерно по одной версии в год). К сожалению или к счастью эксперимент с IPv4 оказался слишком успешным и он со всеми своими ограничениями умудрился прорасти в самые разные места инфраструктуры.
  • 0
    У меня ощущение, что с таким вот «интернетом вещей» даже IPv6 надолго не хватит. Тут нужен какой нить IPv100
    • 0
      Всего 281474976710656 адресов — по 40 000 адресов на человека
      • –1
        Это сейчас 40 000. А если на другие планеты полетим? А если население вырастет на Земле? А если станут IP совать в каждую пачку с маслом? Мало ли какой новый тренд будет.
        • 0
          и правда наврал, как всегда смущает цифра 6(автоматически думается 6 байт),
        • +1
          Не уверен, что протокол IP пригоден для межпланетных коммуникаций.
          • +1
            Между планетами NAT поставят.
      • +2
        неправда, в ipv6 2^128 адресов.
        • 0
          Это все равно что сказать что в IPv4 = 2^32 адресов. Но как мы знаем многие «адреса» использовать нельзя, а некоторые нарезаны так крупно, что непоиспользуешь особо.

          А вообще про ipv6 — там какая минимальная длина сети выделяемой клиенту знаете? Там совсем другие цифры. Поэтому прежде чем говорить что в сети IPv6 2^128 адресов — лучше почитать документацию и прикинуть сколько там на самом деле.
          Я не спорю что и все равно _очень_ много. Я спорю с тем что IPv6 это про 2^128 адресов.
          • 0
            Зря спорите. Часть, которая сейчас выделена под реальное пользование ничтожна. «Зарезервировано для будущих поколений» больше, чем 2127 адресов. А что сегодня, сейчас, не все они роутятся — ну так то дело наживное. Когда-то и в IPv4 использовалась классовая адресация.
            • +1
              Отказ от правила «не более /64» в будущем вызовет не меньше проблем, чем сейчас — задействование класса E под глобальную маршрутизацию. Так что pavelsh абсолютно прав — фраза «в ipv6 2^128 адресов», будучи формально правдой, не имеет никакого отношения к реальности.
              • 0
                по крайней мере 2^128 значительно ближе к реальности, чем 281474976710656 =)

                ну и было бы интересно услышать ответ реальнее, чем 2^128.
                • +1
                  Можно посчитать так.
                  1) Минимальный размер сети — /64. Т.е. формально нижняя оценка — 2^64 (но надо отнять несколько битов на, скажем, мультикаст, link local и другие зарезервированные блоки адресов)
                  2) В одной сети /64 будет в среднем (беру с потолка) 30-60 хостов. Это еще 5-6 битов.

                  Навскидку, вычитая из 64 битов п.1 и добавляя п.2, получим приметно те же 2^64. Это 18446744073709551616. Разница с указанной вами цифрой по словам calc.exe — в 65536 раз, что немного. Разница между 2^64 и 2^128 малость посерьезнее…

                  На точность вычислений не претендую, безусловно ошибаюсь на много порядков, вот только учитывая размер обсуждаемых цифр, «много порядков» — мелочь.
                  • 0
                    Ну так а какие принципиальные проблемы с тем, чтобы лет через 30 (ну или когда припрёт) уменьшить минимальную сеть раза эдак в два? Памяти в роутерах добавится, вычислительных мощностей тоже…

                    Кстати, мне помнится, что выдавать по /64 это рекомендация, провайдеры ей следовать не обязаны и могут выдавать меньше, разве нет?
                    • 0
                      Ну так а какие принципиальные проблемы с тем, чтобы лет через 30 (ну или когда припрёт) уменьшить минимальную сеть раза эдак в два?

                      Я не зря упомянул класс Е IPv4 адресов. Как думаете, что мешает задействовать сразу 16 (или около того) совершенно валидных блоков /8? Да и мультикасту тоже не надо столько адресов — мы так и не увидели глобального мультикаста, и вряд ли когда-нибудь увидим.
                      выдавать по /64 это рекомендация

                      Почитайте rfc2373. Это — вполне себе стандарт.

                      Одной из целей IPv6 было забыть про тот бардак, который творится в IPv4. И говорят, те смелые люди, которые все-таки решили действовать по старинке и считать маски исходя из требуемого количества хостов, напарывались на самые презабавные проблемы. А все потому, что rfc2373 уважается девелоперами. А еще EUI-64 адреса реально удобны. А еще privacy extensions требует 64 битов (а без него возбудятся те, кто не хочет жить с постоянными адресами на каждом компьютере). И так далее. В общем, отказа от правила «не более /64 на конечные сети» не будет.
                      • 0
                        Почитайте rfc2373.

                        В свою очередь порекомендую посмотреть на rfc6177. Раздача префиксов длиннее /64 не запрещена.

                        Сравнивать эту ситуацию с классом E на мой взгляд некорректно. Тут то на уровне стандарта всё поддерживается, просто в best practices не попадает.

                        Понятно, что без проблем не обойтись, но принципиальных трудностей в случае исчерпания адресов я не вижу. Заранее допилить автогенерируемые адреса и privacy extensions чтобы генерировались в произвольное количество бит будет проще, чем всем миром переходить на следующий протокол.
                        • 0
                          Раздача префиксов длиннее /64 не запрещена.

                          rfc6177 говорит про раздачу адресов площадкам, и на протяжении всего документа подразумевается, что конечные подсети будут /64. Прямо об этом не говорится, потому что это выходит за рамки обсуждения.
                          Заранее допилить автогенерируемые адреса и privacy extensions чтобы генерировались в произвольное количество бит будет проще, чем всем миром переходить на следующий протокол.

                          Нет, это будет намного сложнее :) Всегда есть legacy устройства и софт. Как отслеживать, кто обновлен и переживет замену, а кто — нет?

                          Вот с IPv7+ проще. Он либо будет поддерживаться, либо не будет поддерживаться, всегда можно запулить dual stack с предыдущим протоколом. Результат более предсказуем.
      • 0
        По приблизительным оценкам сейчас в интернете вещей порядка 20*10^9 устройств. В ближайжем будущем (3 — 5 года) их будет порядка 200*10^9. Цифры по памяти, более подробно в статьях у преподобного Михаила Ваннаха.
        Так что с таким ростов числа не исключено что и адресов пула IPv6 будет не хватать.
        • 0
          То есть с ростом в 10 раз за 3-5 лет не будет хватать адресов?
          • 0
            Примерно как-то так
            Здесь точнее
            • 0
              Мне очень сложно понять, как грубо 2^32 адресов хватало до сих пор, но через 3-5 лет 2^128 адресов перестанет хватать? Где-то в рассуждениях ошибка.
              • 0
                Сейчас адресов фактически сильно больше чем 2^32. NAT же, за одним адресом может скрываться сеть из тысяч устройств.
              • 0
                Лиха беда начало. Ну и было уже: начнут раздавать блоками /16 да /8, резервировать под себя и т. п. Вон если у некоторых по сусекам поскрести, адрески найдутся.
  • 0
    Помимо увеличения количества адресов, есть и другие преимущества IPv6 над IPv4. Например возможность автоконфигурирования IP адресов, упрощение маршрутизации, повышенная безопасность за счет встроенного IPSEC, улучшенная поддержка QoS.
    • 0
      ipsec и в ipv4 неплохо работает.
      • +1
        В отличие от IPv4, поддержка IPsec является в IPv6 обязательным требованием. IPsec предусматривает два режима работы: транспортный режим и туннельный режим. Согласно Cisco site-to-site tunnel mode is only supported in IPv6.
        • +1
          это проблемы исключительно cisco. site-to-site вполне нормально реализуется даже на банальных микротиках.
          • +1
            извиняюсь, неправильно прочитал комментарий и скорее всего сморозил глупость.
        • +1
          Согласно Cisco site-to-site tunnel mode is only supported in IPv6.

          Поясните.

          Я вот вижу, что на цискиных железках туннельный режим IPSec работает не первый и не второй год. И этот механизм еще даже в RFC2401 описан.
          • 0
            Небольшая опечатка. «site-to-site tunnel mode only is supported in IPv6». Имеется в ввиду IPv6 поддерживает только туннельный режим. Я не говорю что v4 не поддерживает его.
            • 0
              С чего вы взяли? Мне помнится, там и транспортный режим есть.
              • 0
                С того взял, что черным по белому написано написано, что транспортный режим не поддерживается. На практике сам не использовал IPsec для IPv6. Буду благодарен если вы найдете информацию доказывающее обратное.
                • 0
                  черным по белому написано написано, что транспортный режим не поддерживается.

                  www.cisco.com/en/US/tech/tk583/tk372/technologies_tech_note09186a0080bce520.shtml — пример конфигурации.
                  crypto isakmp key cisco address ipv6 ::/0

                  crypto ipsec transform-set TRA esp-aes esp-sha-hmac
                  mode transport

                  Может, вы просто смотрели устаревшую документацию? И даже в считающейся актуальной бывает полно косяков.
                  • 0
                    Наличие mode transport еще ничего не доказывает. Дмитрий, посмотрите этот пример, где при наличии mode transport конечные устройства продолжают использовать туннельный режим.

                    Могу привести в пример следующий документ, где Bryant Newby пишет что:

                    If you look closely at the last paragraph, transport mode actually encrypts the data twice. It is encrypted at the transport layer and then authenticated at the next layer (network layer). This leads to two different levels of security. Unfortunately, this additional level added an unnecessary level of complexity. IPv4 realized this unneeded complexity and was usually implemented in tunnel mode. IPv6 further realized there was no substantial gain in using transport mode. Therefore, IPv6 only supports tunnel mode because of it’s reduced complexity, yet still secure method. It is interesting to see the compromise they made for IPv6.
                    • 0
                      Согласен. По дебагам я как-то пропустил, что там тоже tunnel mode согласовало :)
            • 0
              нет, процитированная фраза переводится именно как «site-to-site tunnel поддерживается только в IPv6».
              • 0
                «site-to-site tunnel mode only is supported in IPv6» можно перефразировать как «only site-to-site tunnel mode is supported in IPv6» Что переводится как, только туннельный режим поддерживается в IPv6. Я понимаю, что трудно сразу уловить суть :)
                • –1
                  Всё, разобрался. Но перефразировать так нельзя, получается «поддерживается site-to-site tunnel и больше ничего».
                  • +1
                    Правильно, так и получается, что поддерживается tunnel и больше ничего, если идет речь o IPsec для IPv6.
                    • –1
                      только tunnel — для site-to-site. но есть же ещё как минимум host-to-host.
                      • +1
                        Ну я же изначально писал o site-to-site. Речь о host-to-host не идет.
    • 0
      Хм. А можете раскрыть тему? Потому что сейчас это больше похоже на маркетинг.
      Например
      1. В чем такое большое отличие ipv6 от ipv4 в плане автоконфигурирования адресов? Чего вам в ipv4 не хватало?
      2. В чем упрощение маршрутизации ipv6 над ipv4?
      3. В чем встроенность ipsec помогают повышаться безопасности?
      4. В чем _улучшенность_ поддержки QoS?
      • 0
        Прочитать можно здесь например.
        Там же есть ссылки на RFC.
        • +1
          То есть:
          1) Да, есть SLAAC и EUI-64. Неплохо.
          2) Никакого упрощения маршрутизации нет (ну не смешите меня — и так примерно нулевая выгода от меньшего числа чексумм перечеркивается повышенными требованиями к структурам хранения FIB, т.е. TCAM, просто возьмите любой хардварный роутер и сравните число поддерживаемых маршрутов IPv4 vs IPv6)
          3) Никакого реального профита относительно IPv4 в плане IPSec нет.
          4) В плане QoS IPv6 ничем не отличается от IPv4.
          • 0
            Ага, Дима, ты прав. Я специально спрашивал эти вопросы у пользователя elmanr, чтобы понять насколько он владеет темой дальше рекламы ipv6.

            К твоим ответам добавлю чуть-чуть своих мыслей.
            1) У IPv4 тоже есть технологии для автоконфигурирования адресов. Теже RARP, BOOTP, DHCP, LinkLocal адреса (169.254). Соотнесите их с технологиями IPv6, которые суть те же, только реализованы поверх другого протокола.
            • 0
              По 1: из stateless механизмов назначения себе адреса есть APIPA (тот самый 169.254). Кто-нибудь может охарактеризовать его любым словом кроме «бесполезный»? На сетевом железе он вообще не поддерживается…
              • 0
                А нужен ли он на сетевом железе? Насколько я понимаю он нужен для того, чтобы ipv4 сетка конфигурировалась самостоятельно в отсутствие этого самого железа.

                Просто я что хотел сказать и тут IPv6 не дает никаких преимуществ.

                Единственные преимущества IPv6 которые вижу я это:
                1. Расширение адресного пространства
                2. Попытка ввести иерархию в адресное пространство (пока непонятно как это будет работать на достаточно длинной дистанции)
                3. Более простой для разбора процессором заголовок пакета (хотя, я думаю, ASIC-у все равно как и в каком порядке идут поля заголовка)
                4. Более простое расширение заголовков протокола.

                Может еще что забыл…
                • 0
                  А то, что убрали broadcast, не считаете плюсом?
                  • 0
                    Вот честно. За свою практику я особо видимого _практического_ вреда от broadcast-a не видел. Зато видел что broadcast _очень_ прост.

                    А с multicast-ом всегда были какие-то проблемы, сложности и т.д. Протокол сложный.

                    Поэтому лично для себя я не ощутил что то, что убрали broadcast-это такое благо. Неоднозначно для меня. В чем то хорошо, в чем то нет.
                    • 0
                      Не скажу, чтобы немаршрутизируемый L2 мультикаст был сложным… Но на мой взгляд, меняют шило на мыло. Грубо говоря: был 255.255.255.255, стал ff02::1, толку-то? Идеологически изменение правильное, но фактически ничего не изменилось.
                      • 0
                        Так любой мультикаст не сложен — not a rocket science at all.
                        Но, по сравнению с broadcast в multicast уже есть интеллект, который нужно учитывать при отладке.

                        Что касается шила — на мыло — с тобой согласен. Еще одна причина, почему это изменение не прописал в плюсы (да и не помнил для себя как плюс).
                        • 0
                          После ваших слов, складывается ощущение, что в IETF неучи сидят.
                          • 0
                            Идея-то в целом правильная. Просто не надо объявлять отказ от броадкастов как решение всех мировых проблем, так как разницу мало кто заметит. В общем, так себе плюс, неубедительный.
                          • 0
                            А почему вам так показалось?

                            Я, лично, так не считаю. Мое мнение ipv6 multicast это такой более advanced ipv4 broadcast, только переименованный.

                            Дает он плюсы — может в дальнейшем он и даст свои плюсы (или свои минусы, кто знает?). В данный момент на существующих L2 технологиях он работает в 99 процентах случаях как ipv4 broadcast

                            P.S.: Странно, что не заявляется что IPv6 круче, потому что в нем нет ARP. Ах какой маркетинговый ход пропадает :)
  • +7
    Билайн, вы молодцы! Огромные-огромные, без преувеличения, молодцы!
    Месяц назад T-Mobile по умолчанию сделала свой APN IPv6-only по умолчанию (видимо, с трансляцией в IPv4 каким-то образом), а тут вы!

    Стоит ли нам ждать IPv6 Proxy Mobile IP?
    Для тех, кто не знает об этой технологии (я думаю, большинство), эта технология позволяет использовать вашу домашнюю IPv6-подсеть в любом месте без проксификации (без прогона трафика через один из компьютеров в вашей сети туннелем), и, соответственно, ваше мобильное устройство (да и не только мобильное) может без туннеля, да и вообще без особых нестандартных настроек на стороне клиента, иметь IPv6-адрес из вашей домашней подсети.
    • 0
      Стоит ли нам ждать IPv6 Proxy Mobile IP?

      Наверняка умрет. LISP вполне успешно развивается и даже где-то работает в продакшне.
    • 0
      Спасибо.
      Если T-Mobile использует APN IPv6-only, значит они по всей видимости используют технологию трансляции NAT64 в сочетании с DNS64.

      По поводу IPv6 Proxy Mobile IP — это технология в большей своей части применима для технологий WLAN, WiMAX. В архитектуре сетей GPRS/EDGE/UMTS отсутствуют промежуточные узлы третьего уровня (которые, в том числе принимают участие в маршрутизации) все взаимодействие строится с одним узлом — GGSN.
  • 0
    Судя по bgp.he.net также планируется еще одна тестовая зона в Новосибирске.
  • +3
    Навеяно картинкой в начале статьи.

    Дорогой, у нас проблема. Собака не пингуется.
  • 0
    я у себя настраивал нативный ipv6 на openwrt.

    могу с уверенностью сказать, что это дело далеко не тривиальное. вооружившись tcpdump-ом и техподдержкой провайдера потратили не один час.

    так что не думаю, что в ближайшее время будет массовый переход на ipv6, хотя подвижки есть и это радует.
  • 0
    Как-то пытался настроить подключение к интернету с домашнего компа ОС Linux к интернету beeline — вот это была не тривиальная задача. Думал, что включил комп, получил адрес и доступ готов. Как оказалось надо было ещё туннель до интернет шлюза поднимать, который просто так не поднимается (избалован Cisco VPN и OpenVPN).
    Потом при общении с техподдержкой (ответа ожидать приходится в среднем по 20 минут) поинтересовался почему такой выверт с финтом ушами для подключения к интернету сделали, как посетовали — ограниченность адресного пространства. Обсудили возможность введения IPv6, но не ожидал, что так скоро за это возьмутся.
    На юге тоже начинайте. Давно пора.
  • 0
    Начальная картинка радует. Взяли картинку дома, к каждой мелочи на ней подписали «IPv6 addr» — и вот, «здравствуй, новый мир!»

    Лучше бы уж плясали от задач. Сотовому оператору оно выгодно, адреса экономятся, железо под NAT не нужно апгрейдить. Но юзерам домашним — и правда, на уровне теста почти всем.

    Кстати, еще вопрос ответственности — если все в тесте, то нет гарантий, что будет хоть как-то работать. Раз нет гарантий — нет смысла переходить.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка