Снимаю шляпу перед полётом мысли вашей статьи. Собственно самое обидное это то, что в спецификации OSPF искомая фича есть, но по загадочной причине отказывается работать. Правда с учётом нынешней стоимости железа на вторичном рынке и цены ошибки/бага подобные инженерные выкрутасы становятся менее актуальными.
Я вас, наверное, удивлю еще больше, если скажу что у нас везде all-flash VSAN и бэкапы на Veeam. Наша ниша — SMB решения и мы практически не занимаемся VPS. Когда-то существовала конкурирующая VPS платформа на KVM, но в поддержке она требовала бОльших затрат, чем генерировала дохода и мы всё перенесли в VMware. У меня коллеги работают в конкурирующей компании с OpenStack — штат сотрудников там в три раза больше при примерно одинаковом профите.
Если сравнивать цены моей в компании и, например, AWS/GCS/Azure — мы в конечном счёте дешевле, так как не ограничиваем/биллим ни IOPS ни траффик. Уже не один и не два «бывших» вернулись к нам из облачных «драконов». Как вишенку на торте все клиенты могут пользоваться консультационной поддержкой за почасовую плату, без отдельных договоров — достаточно просто позвонить. Для нашей компании это не основная часть дохода, но для клиентов без своего сильного IT департамента — еще один плюс. Есть много параметров почему выбирают именно нас — опишите конкурента, а я попытаюсь сказать почему мы лучше.
Согласен, весьма интересные железки. Вариантов производителей и моделей на самом деле масса, но все-таки моя идея была не об этом, а о том что этот маршрутизаторный хоп на самом деле не выполняет в некоторых случаях никакой полезной работы за исключением собственно BGP сессии и в этих случаях можно от него отказаться.
Я не отрицаю, что возможность передавать другой next-hop могла быть заложена разработчиками протокола. Здесь только одно «но» — спецификация и реализация иногда не совпадают. Кстати, о forwarding address и как его видит Cisco я упоминал в статье и вот еще раз ссылка http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13682-10.html. Почитайте — там от описанного выше изящества ровным счетом ничего плюс куча ограничений. Поймите меня правильно — я не пытаюсь защищаться отрицанием предложений, наоборот — мне нравится Ваши идеи, настрой и в общем наш спор.
Ну а если трактовать RFC как таковой, то да — это именно то, что нужно. Если удастся реализовать на практике — готовое решение для мелких стаб-СП. Я как уже упоминалось в посте смотрел на этот функционал, но только у Cisco он работает не совсем так, как мне нужно, а у Juniper примеров реализации не нашел. Тем не менее, благодарю за настойчивость и выдержку из RFC — в ближайшее время появится натурный стенд и чуть больше времени для обкатки, будем пробовать.
Raspberry вообще штука интересная. К тому же для него стандартен Raspbian, то есть урезаный Debian. Не удивлюсь, если Quagga или BIRD уже портированы для него плюс идея с exabgp из комментария. Ограничение даного варианта я уже описал.
Ваше понимание верно — получая FW на виртуалку (raspberry?) мы получаем возможность самостоятельно фильтровать и приоритезировать маршруты. И таки да, большинство L3 свичей без проблем держат 10+ тысяч маршрутов. Агрегируя FW к примеру в 4 маршрута по /2 можно объединить таблицу и уже оперировать этими маршрутами. Я кстати думал так сделать в начале своей работы на текущем мпесте, но потом оказалось, что основной провайдер + резервный — это максимум, что необходимо для наших потребностей.
Докупать ли лицензию и получить нативную возможность манипуляции next-hop или использовать мой «костыль» это уже дело личных преференций. А wire-speed маршрутизация при отсутствии потребности в продвинутых фичах довольно весомый агрумент «за».
Одобрение коммента немного растянулось во времени, поэтому на часть вопросов уже ответил…
Если под «То есть вы готовы платить за два 10г Линка...» вы имели ввиду оплату линка к провайдеру, то они на самом деле не очень дорогие, во всяком случае не 20тыс.долл. со старта. Если имелось ввиду оборудование, которое в принципе может терминировать 10Гб/с, то частично ответ выплывает из предыдущих комментариев — ядро агрегирует сервера с виртуалками и там необходимо иметь порты 10Гб/с. Позаимствовать пару портов под задачу подключения к провайдеру не проблема и виртуальная машина соответвенно тоже есть. Кроме этого, если 10Гб/с устройства нет, всегда есть модули аплинков на младших моделях свичей, например EX4200, на котором тоже можно запустить BGP. Можно еще посмотреть в сторону exabgp из комментариев, если цена виртуальной машины смущает.
По поводу distance-vector протоколов проверю и отпишусь, но уточню, что моей задачей было избежать использования BGP, так как с ним все и так работает, однако стоит дополнительных денег на лицензию.
FRR ( Free Range Routing) если я правильно прочитал это еще одна «вариация на тему». До тех пор пока они не будут поддерживать изменения всего-и-везде, это просто еще один из вариантов, не более. Итак, если с помошью FRR нельзя поменять forwarding address в OSPF или подобное, эта технология не для данной задачи. Поймите меня правильно — я не обсираю проект как таковой, но у меня четко определенная задача с которой на текущий момент не справились Quagga и BIRD.
Позволю себе повториться еще раз — ЕСТЬ решения данной проблемы, однако они требуют поддержки со стороны сети, что выливается или в стоимость лицензии или в закупку нового оборудования. Моя идея — отказ от необходимости покупки оборудования или модулей, которые не будут использоваться остальной сетью: у меня есть 10Гб/с свич, который мне нужен by-design и мне хочется, чтобы покупка этого свича была единственными расходами на инфраструктуру. Не потому, что денег нет, а потому что зачем платить 17к долларов за устройство, которое будет принимать несколько фулл-вью и отдавать ядру 0/0 или PatrialView?
Чтобы не было двусмыслености под «third-party nexthop». В моем случае это передача достижимости сети через next-hop, который не является адресом интерфейса, соединяющего маршрутизаторы. Ни Quagga ни BIRD не позволяют изменить next-hop в этом смысле. Испробованые варианты я описал, вроде других доступных мест для изменения нет.
1. Если вы имели ввиду приведенный мной линк о forwarding address (http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13682-10.html), тогда это не то. Во-первых топология отличается, а с ней и вся логика. Во-вторых его нельзя настроить вручную — он либо работает сам или нет — решает железка согластно своим «ощущениям».
2. К вопросу о «жутком костыле» из предыдущего коммента. Но на самом деле это именно то, куда я двигаюсь.
p.p.s. Если под маршрутизатором вы имеете ввиду устройство ядра (колторое на самом деле L3 свич), то нет FullView он держать не сможет и я упоминал об этом. Вопрос передачи FullView через IGP туда же — это может и реально, но слишком нереально.
Но давайте подучаем вот о чем — а зачем нам собственно FullView? И раз уж в комментариях появились недовольства моими упрощениями, проанализируем ситуацию с несколькими FullView от нескольких провайдеров. Тем не менее, тип моего ISP важен: это провайдер прежде всего для конечных пользователей, не агрегатор других ISP или транзит. Итак, FullView нам нужен для оптимального выбора маршрута из множества возможных, которые нам высылают провайдеры — где-то дешевле, где-то быстрее, где-то короче. В таком случае апстримов будет два-три — в основном для избыточности, но и для балансировки тоже. В случае моего ISP необходимо будет наделять приоритетом достаточно ограниченое количество сетей — к примеру принадлежащих стране или датацентру (Amazon во Франкфурте как один из вариантов). На самом деле это вполне себе экзотика — многие пользуются обычным 0/0 ко всем провайдерам, но все же. Я пока не имел опыта с приоритезацией выхода на страну/датацентр, но рискну предположить, что это вполне может уложиться в те 14-16 тыс маршрутов, поддерживаемых устройствами ядра.
Дело не в eBGP, его можно крутить и на Квагге и на Mikrotik CHR. Вариантов масса и все они упираются в одну стену — необходимость докупать BGP лицензию для ядра или ограничения IGP о которых я упомянул в посте. К тому же Mikrotik CHR сам по себе стоит денег — зачем, если есть Квагга/БИРД?
Я конечно может неправильно сделал, что опустил этот момент — думал это маловажная информация, так как я сосредотачивался больше на границе и взаимодействию устройств. Но давайте я исправлюсь.
Ядро у меня будет состоять из двух EX4550, соответственно 10Гб/с интерфейсы у меня уже в наличии. К ядру будут подключаться сервера с VMWare — виртуалки у меня тоже есть.
Ядро объединено в виртуальное шасси, соответственно стоимость лицензии возрастает в два раза — ее нужно покупать для каждого routing-engine в шасси. Итого 20 тыс.долл. Вот вам и стоимость ASR. У циски думаю ситуация не будет отличаться — если объединять нексусы в VSS или подобное решение, feature set должен совпадать, итого 18тыс.долл. согласно GPL.
По поводу костыля с доставкой не соглашусь — так любую манипуляцию можно назвать: препенд, приоритет, изменение административного расстояния. А мои идеи особо не отличаются от скажем препенда, разве что не реализованы нативно на оборудовании. К тому же я не заставляю поступать именно так — вариант крутить iBGP между виртуалкой и ядром в описании присутствует.
Формально Skyroger2 прав, в правилах получения АС указано, что должны быть договоренности с минимум двумя пирами для получения AS. Что это за договоры, будут ли они выполнятся и можно ли по-другому вопрос другой, но положение такое есть.
По комменту: что я собираюсь делать я писал — на даный момент обойдусь статикой на ядре. Если аплинков несколько можно сделать floating static, если линки идут к разным пирам. Для моей стаб-АС этого достаточно, по крайней мере пока.
Я посмотрел на AS3216 и они отдают или 0/0 или FullView. Ничего по поводу фильтрации по /16 (как в изначальном комменте) не увидел. И я очень сильно сомневаюсь, что они такое предложат каждому клиенту. «две строчки в конфигурации» помноженное на количество пиров превратятся в неподъемную работу. А если «мне» потом понадобится что-то поменять? В любом случае, мой пир такого делать не будет да и не об этом был пост.
Признаю, не слышал про exabgp, как и о многих других вещах — глупо это пытаться скрыть. Однако если я правильно толкую «exabgp можеть менять любые bgp атрибуты что in что out» нам нужен BGP между устройствами. Соответственно в моей статье это будет пункт 2 или 3. Для пункта 2 это избыточно — просто менять атрибуты я могу и на ядре. Для пункта 3 слишком мало — там идея в организации машины, которая будет иметь FullView или несколько для возможности локалькой сумаризации/приоритезации. К тому же целью моих изысканий являлся полный уход от BGP из-за лицензионной стоимости. И таки да, raspberry pi — сомнительно, что он вместит таблицу и будет обрабатывать достаточно быстро.
Я писал, что это только один из вариантов. Если вам интересно как может решение масштабироваться, что и зачем нужно, и как изменится, можем подумать вместе.
Получать на кору через BGP? Такой вариант приведен на втором рисунке. Признаю, там он называется PartView, он же PartialView. Однако в вырожденом варианте PartialView=0/0.
«Получать» статикой? Тогда я действительно некстати, но я об этом писал вначале статьи.
1. Да, пира должно быть два, чтобы выдали АС, но она у меня есть. Вы упустили из вида, что два интерфейса «на борту» и кроме них есть еще интерфейсный концентратор как у Juniper, так и у Cisco. У MX80 вообще 4 интерфейса и два слота под концентраторы. Как вариант я могу пирится с двумя провайдерами в точке обмена и одного интерфейса хватит. Но я писал не совсем о выборе подходящей платформы для задачи Х.
2. Фуллвью наверное не нужен, тем более поначалу. Тем не менее уже при двух соседях поднимется вопрос приоритезации. Уж не знаю как ваши провайдеры, а мне с трудом верится, что каждый из моих будет фильтровать как мне хочется — таких клиентов как я у них десятки и под каждого не нафильтруешься. И я не утверждал, что FullView жизненно необходим.
3. Ответили ниже )
Интересная идея с Distribution frame. Не скажу, что я не мыслил в данном направлении, но пока что идея конфликтует с моими ограниченными познаниями в оптике — ведь для нормальной организации DF, оптику нужно резать+полировать/паять/клеить, а это подразумевает наличие специализированного оборудования, коего в датацентре пока не предвидится. Ну и определенный уровень персонала или закупку на стороне, что учитывая специфику компании довольно проблематично.
Бобины сверху стойки — почти что мое решение с рогами, но все равно принимается. Бобины красивее. Бобины рядом с сервером — нереально.
Вот представьте себе hyperconverged сервер (у нас стоят от SuperMicro, но более яркий пример VxRail от Dell EMC) — это 4 картриджа по 2 порта 10Гб/с в каждом, плюс 2 медных гигабитных менеджмент порта. Все это, то есть 8 портов оптики на пространстве 2U. А если таких серверов пяток в стойке — 40 бобин… Где держать это хозяйство? Если унифицировать бобину на несколько серверов, возникнут проблемы с обслуживанием кабелей.
Не подумайте, что я отвергаю идею или пытаюсь оправдаться. Просто иногда реалии слегка сложнее, нежели на рекламной картинке.
Согласен. Нет, это не лаба — это ядро сети. С одной стороны вроде как есть весь задел для чистого датацентра (само помещение, каналы для кабелей, патч-панели). С дургой — частые изменения в топологии/устройствах и непонимание со стороны младшего обслуживающего персонала и правилах приличия. Из лично моего опыта в этом датацентре могу сказать, что будет только хуже — с появлением оптики (и стандартных длин кабелей, которые тяжело укоротить) начались проблемы с «соплями» и «кольцами» для компенсации избыточной длины. Я сейчас пробую всю оптику, идущую к стойке навивать на «рога» из стоечных креплений в каналах под потолком, чтобы избежать соплей. Посмотрим как дело пойдет.
Если есть идеи или предложения как организовать правильно оптику, буду признателен за советы.
Если сравнивать цены моей в компании и, например, AWS/GCS/Azure — мы в конечном счёте дешевле, так как не ограничиваем/биллим ни IOPS ни траффик. Уже не один и не два «бывших» вернулись к нам из облачных «драконов». Как вишенку на торте все клиенты могут пользоваться консультационной поддержкой за почасовую плату, без отдельных договоров — достаточно просто позвонить. Для нашей компании это не основная часть дохода, но для клиентов без своего сильного IT департамента — еще один плюс. Есть много параметров почему выбирают именно нас — опишите конкурента, а я попытаюсь сказать почему мы лучше.
Ну а если трактовать RFC как таковой, то да — это именно то, что нужно. Если удастся реализовать на практике — готовое решение для мелких стаб-СП. Я как уже упоминалось в посте смотрел на этот функционал, но только у Cisco он работает не совсем так, как мне нужно, а у Juniper примеров реализации не нашел. Тем не менее, благодарю за настойчивость и выдержку из RFC — в ближайшее время появится натурный стенд и чуть больше времени для обкатки, будем пробовать.
Ваше понимание верно — получая FW на виртуалку (raspberry?) мы получаем возможность самостоятельно фильтровать и приоритезировать маршруты. И таки да, большинство L3 свичей без проблем держат 10+ тысяч маршрутов. Агрегируя FW к примеру в 4 маршрута по /2 можно объединить таблицу и уже оперировать этими маршрутами. Я кстати думал так сделать в начале своей работы на текущем мпесте, но потом оказалось, что основной провайдер + резервный — это максимум, что необходимо для наших потребностей.
Докупать ли лицензию и получить нативную возможность манипуляции next-hop или использовать мой «костыль» это уже дело личных преференций. А wire-speed маршрутизация при отсутствии потребности в продвинутых фичах довольно весомый агрумент «за».
Если под «То есть вы готовы платить за два 10г Линка...» вы имели ввиду оплату линка к провайдеру, то они на самом деле не очень дорогие, во всяком случае не 20тыс.долл. со старта. Если имелось ввиду оборудование, которое в принципе может терминировать 10Гб/с, то частично ответ выплывает из предыдущих комментариев — ядро агрегирует сервера с виртуалками и там необходимо иметь порты 10Гб/с. Позаимствовать пару портов под задачу подключения к провайдеру не проблема и виртуальная машина соответвенно тоже есть. Кроме этого, если 10Гб/с устройства нет, всегда есть модули аплинков на младших моделях свичей, например EX4200, на котором тоже можно запустить BGP. Можно еще посмотреть в сторону exabgp из комментариев, если цена виртуальной машины смущает.
По поводу distance-vector протоколов проверю и отпишусь, но уточню, что моей задачей было избежать использования BGP, так как с ним все и так работает, однако стоит дополнительных денег на лицензию.
FRR ( Free Range Routing) если я правильно прочитал это еще одна «вариация на тему». До тех пор пока они не будут поддерживать изменения всего-и-везде, это просто еще один из вариантов, не более. Итак, если с помошью FRR нельзя поменять forwarding address в OSPF или подобное, эта технология не для данной задачи. Поймите меня правильно — я не обсираю проект как таковой, но у меня четко определенная задача с которой на текущий момент не справились Quagga и BIRD.
Позволю себе повториться еще раз — ЕСТЬ решения данной проблемы, однако они требуют поддержки со стороны сети, что выливается или в стоимость лицензии или в закупку нового оборудования. Моя идея — отказ от необходимости покупки оборудования или модулей, которые не будут использоваться остальной сетью: у меня есть 10Гб/с свич, который мне нужен by-design и мне хочется, чтобы покупка этого свича была единственными расходами на инфраструктуру. Не потому, что денег нет, а потому что зачем платить 17к долларов за устройство, которое будет принимать несколько фулл-вью и отдавать ядру 0/0 или PatrialView?
1. Если вы имели ввиду приведенный мной линк о forwarding address (http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13682-10.html), тогда это не то. Во-первых топология отличается, а с ней и вся логика. Во-вторых его нельзя настроить вручную — он либо работает сам или нет — решает железка согластно своим «ощущениям».
2. К вопросу о «жутком костыле» из предыдущего коммента. Но на самом деле это именно то, куда я двигаюсь.
p.p.s. Если под маршрутизатором вы имеете ввиду устройство ядра (колторое на самом деле L3 свич), то нет FullView он держать не сможет и я упоминал об этом. Вопрос передачи FullView через IGP туда же — это может и реально, но слишком нереально.
Но давайте подучаем вот о чем — а зачем нам собственно FullView? И раз уж в комментариях появились недовольства моими упрощениями, проанализируем ситуацию с несколькими FullView от нескольких провайдеров. Тем не менее, тип моего ISP важен: это провайдер прежде всего для конечных пользователей, не агрегатор других ISP или транзит. Итак, FullView нам нужен для оптимального выбора маршрута из множества возможных, которые нам высылают провайдеры — где-то дешевле, где-то быстрее, где-то короче. В таком случае апстримов будет два-три — в основном для избыточности, но и для балансировки тоже. В случае моего ISP необходимо будет наделять приоритетом достаточно ограниченое количество сетей — к примеру принадлежащих стране или датацентру (Amazon во Франкфурте как один из вариантов). На самом деле это вполне себе экзотика — многие пользуются обычным 0/0 ко всем провайдерам, но все же. Я пока не имел опыта с приоритезацией выхода на страну/датацентр, но рискну предположить, что это вполне может уложиться в те 14-16 тыс маршрутов, поддерживаемых устройствами ядра.
Ядро у меня будет состоять из двух EX4550, соответственно 10Гб/с интерфейсы у меня уже в наличии. К ядру будут подключаться сервера с VMWare — виртуалки у меня тоже есть.
Ядро объединено в виртуальное шасси, соответственно стоимость лицензии возрастает в два раза — ее нужно покупать для каждого routing-engine в шасси. Итого 20 тыс.долл. Вот вам и стоимость ASR. У циски думаю ситуация не будет отличаться — если объединять нексусы в VSS или подобное решение, feature set должен совпадать, итого 18тыс.долл. согласно GPL.
По поводу костыля с доставкой не соглашусь — так любую манипуляцию можно назвать: препенд, приоритет, изменение административного расстояния. А мои идеи особо не отличаются от скажем препенда, разве что не реализованы нативно на оборудовании. К тому же я не заставляю поступать именно так — вариант крутить iBGP между виртуалкой и ядром в описании присутствует.
По комменту: что я собираюсь делать я писал — на даный момент обойдусь статикой на ядре. Если аплинков несколько можно сделать floating static, если линки идут к разным пирам. Для моей стаб-АС этого достаточно, по крайней мере пока.
Я посмотрел на AS3216 и они отдают или 0/0 или FullView. Ничего по поводу фильтрации по /16 (как в изначальном комменте) не увидел. И я очень сильно сомневаюсь, что они такое предложат каждому клиенту. «две строчки в конфигурации» помноженное на количество пиров превратятся в неподъемную работу. А если «мне» потом понадобится что-то поменять? В любом случае, мой пир такого делать не будет да и не об этом был пост.
Получать на кору через BGP? Такой вариант приведен на втором рисунке. Признаю, там он называется PartView, он же PartialView. Однако в вырожденом варианте PartialView=0/0.
«Получать» статикой? Тогда я действительно некстати, но я об этом писал вначале статьи.
2. Фуллвью наверное не нужен, тем более поначалу. Тем не менее уже при двух соседях поднимется вопрос приоритезации. Уж не знаю как ваши провайдеры, а мне с трудом верится, что каждый из моих будет фильтровать как мне хочется — таких клиентов как я у них десятки и под каждого не нафильтруешься. И я не утверждал, что FullView жизненно необходим.
3. Ответили ниже )
Бобины сверху стойки — почти что мое решение с рогами, но все равно принимается. Бобины красивее. Бобины рядом с сервером — нереально.
Вот представьте себе hyperconverged сервер (у нас стоят от SuperMicro, но более яркий пример VxRail от Dell EMC) — это 4 картриджа по 2 порта 10Гб/с в каждом, плюс 2 медных гигабитных менеджмент порта. Все это, то есть 8 портов оптики на пространстве 2U. А если таких серверов пяток в стойке — 40 бобин… Где держать это хозяйство? Если унифицировать бобину на несколько серверов, возникнут проблемы с обслуживанием кабелей.
Не подумайте, что я отвергаю идею или пытаюсь оправдаться. Просто иногда реалии слегка сложнее, нежели на рекламной картинке.
Если есть идеи или предложения как организовать правильно оптику, буду признателен за советы.