Как писал выше, у нас используется по частям Tungsten Fabric с нашими изменениями.
Конечно, мы держали в голове разные схемы, но нам в том числе нужна была end-to-end mpls связность, поэтому иметь несколько схем (усложнение) и делать между ними какой-либо stitching (тоже усложнение) не хотелось, и в итоге остановились на том, на чем остановились.
1) по какой причине вы решили подключать сервера к двум коммутаторам вместо одного? Ведь это существенно дороже и сервер все равно остаётся единой точкой отказа.
На самом деле, стоимость второго коммутатора в серверной стойке не является сильно принципиальной на фоне стоимости самой стойки серверов в полной их набивке.
Зато такая конструкция снижает домен отказа в *количество серверов в стойке* раз, а также позволяет сравнительно безболезненно проводить различные работы.
2) Используете ли вы cut-through или store-n-forward режим коммутации? Если второе, то не беспокоит ли вас увеличивающаяся задержка в пути?
Нет, текущие значения нас совсем не беспокоят.
3) Ничего не сказано про максимальный размер пакета (MTU) доступный конечным пользователям
Внутри виртуальных пользователских сетей доступны jumbo frames.
4) Насколько использование MPLS ограничивает вас в выборе оборудования? На горизонте есть несколько разных поставщиков сетевых ASIC, но сможете ли вы их использовать со своими специфичными требованиями?
Конечно есть некоторые ограничения, но в основном они сводятся к софту. Однако наши требования не сильно специфичные, по большей части нужно просто уметь делать label swap, а с этим как правило все хорошо.
Есть места где нужно уметь делать label imposing на сетевом оборудовании, но их не так много, а там где много — мы делаем на наших сетевых appliances.
5) Возникали ли у вас какие либо трудности с взаимодействием между MPLS и балансировкой нагрузки между интерфейсами? Например поляризация трафика.
Как таковых трудностей в этом месте, которые заставили бы нас думать серьезно об этом, у нас не возникало.
6) Используете ли вы какую либо систему маркировки и приоритезации трафика?
QoS, несколько красок по типу трафика, но еще смотрим что тут можно сделать в нашей ситуации лучше.
Действительно, часть сервисов сидит на виртуальных роутерах и, соответственно, в виртуальной сети. Однако, немалая часть сервисов сидит в underlay-сети, это например само управление серверами, сетевой сторадж и др.
Я надеюсь, мы когда-нибудь про это напишем подробнее, а пока перечислю используемые у нас инструменты: netbox (ipam), git, ansible, естественно самописные python скрипты, jinja, netconf (как один из способов управления устройствами и получения информации с них), и еще различные сопутствующие внутренние вещи.
Вендоры используются разные, это не так принципиально в разрезе обсуждаемых в статье вопросов. У одних вендоров лучше одно, у других — другое. От комбинации факторов и отталкиваемся, выбирая под конкретные задачи. Если у вас чуть более конкретный вопрос, то вы задавайте, а я попробую на него ответить.
Я все прекрасно понимаю про апстримов — на самом деле предельно ясно, чем черевато анонсирование только части специфик, в случае проблем этого апстрима. И про участие на IX'е, хотя не совсем ясен смысл анонсирования только части специфик участникам. В общем я лишь идеализирую, хотя идеализирую — не совсем верное слово. Я имею ввиду, как кажется правильным поступать, чтобы в итоге не получить подобное тому, что имеем сейчас с ipv4.
ip-transit — проаносировали все специфики свои с разными метриками, например чтобы разнести нагрузку. Та AS, что выступает в роли апстрима агрегирует и уже дальше анонсирует в агрегированном виде. Я пока не могу сообразить, чем это плохо.
Не ip-transit, а простой пиринг — даже если опять анонсируем специфики, а не единый префикс — дальше AS куда анонсируем маршруты не уйдут.
Ох уж эти «хомячки-истерички», понятия не имеющие о работе телекома. Авария, такое бывает, и обрыв оптики это авария и не всегда легко и быстро устраняющаяся. От этого _нельзя_ застраховаться.
Ну правда — надоело это глупое, неадекватное негодование.
P.S. никакого отношения к билайну не имею, скорее даже наоборот.
Удивительно, я даже более-менее внимательно прочитал это. Но
«Транспортный уровень, описывающий путь, которым доставляются данные из исходной точки с финальному получателю (TCP, UDP)»
— транспортный уровень не описывает путь, которым доставляются пакеты. Это задача сетевого уровня. Хотя, если используется модель сети TCP/IP, то и уровни называются по-другому.
ХП имеет не самый удобный cli, например в нем никогда не увидишь маки по портам с инфой о вланах. Про хуавей ничего не могу сказать — не сталкивался. А так, на AG очень хорошо себя чувствует серия D-link DGS.
Это было сделано с целью разделить внешний трафик Яндекс.Облака и трафик самого Яндекса.
Как писал выше, у нас используется по частям Tungsten Fabric с нашими изменениями.
Конечно, мы держали в голове разные схемы, но нам в том числе нужна была end-to-end mpls связность, поэтому иметь несколько схем (усложнение) и делать между ними какой-либо stitching (тоже усложнение) не хотелось, и в итоге остановились на том, на чем остановились.
На самом деле, стоимость второго коммутатора в серверной стойке не является сильно принципиальной на фоне стоимости самой стойки серверов в полной их набивке.
Зато такая конструкция снижает домен отказа в *количество серверов в стойке* раз, а также позволяет сравнительно безболезненно проводить различные работы.
Нет, текущие значения нас совсем не беспокоят.
Внутри виртуальных пользователских сетей доступны jumbo frames.
Конечно есть некоторые ограничения, но в основном они сводятся к софту. Однако наши требования не сильно специфичные, по большей части нужно просто уметь делать label swap, а с этим как правило все хорошо.
Есть места где нужно уметь делать label imposing на сетевом оборудовании, но их не так много, а там где много — мы делаем на наших сетевых appliances.
Как таковых трудностей в этом месте, которые заставили бы нас думать серьезно об этом, у нас не возникало.
QoS, несколько красок по типу трафика, но еще смотрим что тут можно сделать в нашей ситуации лучше.
В качестве overlay используется Tungsten Fabric, переработанный и по частям.
Вендоры используются разные, это не так принципиально в разрезе обсуждаемых в статье вопросов. У одних вендоров лучше одно, у других — другое. От комбинации факторов и отталкиваемся, выбирая под конкретные задачи. Если у вас чуть более конкретный вопрос, то вы задавайте, а я попробую на него ответить.
Juniper на картинке из топика на самом деле является Cisco ASR 9000 series :)
forwarding-options {
hash-key {
family inet {
layer-3;
layer-4;
}
и т.д.
Не ip-transit, а простой пиринг — даже если опять анонсируем специфики, а не единый префикс — дальше AS куда анонсируем маршруты не уйдут.
А можно тут подробнее? Например ISP получает префикс IPv6 /32 — его и анонсит. Один префикс, а не стопицот IPv4 как сейчас. Откуда свалка?
Ну правда — надоело это глупое, неадекватное негодование.
P.S. никакого отношения к билайну не имею, скорее даже наоборот.
«Транспортный уровень, описывающий путь, которым доставляются данные из исходной точки с финальному получателю (TCP, UDP)»
— транспортный уровень не описывает путь, которым доставляются пакеты. Это задача сетевого уровня. Хотя, если используется модель сети TCP/IP, то и уровни называются по-другому.