Routing Instance

Объект Routing Instance (RI) — это основной ресурс в ресурсной модели сервиса Cloud Router, предназначенный для создания сетевых топологий, в рамках которых облачные ресурсы в разных сетях будут иметь сетевую связность между собой.

Общие правила и рекомендацииОбщие правила и рекомендации

При использовании сервисов Cloud Router и Cloud Interconnect настоятельно рекомендуется следовать следующим правилам и рекомендациям:

1. Во всех сегментах сети (как со стороны облака, так и со стороны On-Prem), которые будут объединяться с помощью Routing Instance (RI), должна использоваться согласованная и непересекающаяся IP-адресация. IP-префиксы подсетей, которые добавляются в RI, должны быть согласованы между собой. Нельзя добавить два одинаковых IP-префикса в один RI. IP-адресация на стороне On-Prem должна быть согласована с IP-адресацией в виртуальных облачных сетях. Пересечение IP-адресации всегда будет приводить к нежелательным потерям IP-связности. Тщательно планируйте IP-адресацию.

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

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

3. Прямой обмен маршрутной информацией между любыми приватными соединениями (PRC) в пределах RI не допускается.

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

5. Идентификатор сети VPC - vpc_network_id можно одновременно добавить только в одинRouting Instance. Добавить этот же идентификатор в другой Routing Instance не получится.

6. Идентификатор приватного соединения - cic_private_connection_id можно одновременно добавить только в одинRouting Instance. Добавить этот же идентификатор в другой Routing Instance не получится.

Рекомендации по настройке приватных соединенийРекомендации по настройке приватных соединений

1. Всегда организовывайте два канала связи Cloud Interconnect через две точки присутствия. Это поможет избежать отказов в работе ваших сервисов в случае отключения одного из каналов.

2. Для упрощения настройки отказоустойчивой BGP-маршрутизации на клиентских маршрутизаторах рекомендуется использовать одинаковый номер BGP ASN, если со стороны клиента используются несколько маршрутизаторов для подключения к услуге Cloud Interconnect. Допускается использовать разные номера BGP ASN, например, при организации подключений через операторов связи. Следует помнить, что настройка сетевого оборудования клиента и оператора связи лежит вне зоны ответственности Yandex Cloud.

3. Если у клиента два канала связи Cloud Interconnect подключаются к разным маршрутизаторам, то между этими клиентскими маршрутизаторами необходимо дополнительно установить взаимодействие (связность) по протоколу iBGP. В случае отсутствия такой связности при выходе из строя одного из каналов связи на одном из маршрутизаторов соседний маршрутизатор ничего не узнает об этом отказе, и трафик из отказавшего канала не будет перемаршрутизирован на оставшийся в работе канал связи средствами протокола BGP.

4. При необходимости распределения исходящего трафика из облачных сетей по нескольким каналам связи в Cloud Interconnect используйте на клиентских маршрутизаторах префиксы разной длины для BGP-анонсов:

   • длина префикса /8 (короткий префикс) соответствует самому низкому приоритету маршрута;
   • длина префикса /32 (длинный префикс) соответствует самому высокому приоритету маршрута.

   Подробнее о распределении трафика по нескольким каналам связи можно узнать в разделе сценарии использования.

5. Для выбора канала связи для исходящего трафика из инфраструктуры клиента в направлении облачных сетей на клиентском маршрутизаторе можно использовать, например, стандартный BGP-атрибут Local Preference. Подробнее о распределении трафика по нескольким каналам связи можно узнать в разделе сценарии использования.

Ограничения при сетевом взаимодействииОграничения при сетевом взаимодействии

1. Допускается совместное использование Cloud Interconnect и NAT-шлюза, если клиентские маршрутизаторы не анонсируют маршрут «по умолчанию» 0.0.0.0/0 по протоколу BGP в направлении Yandex Cloud. В случае анонса маршрута по умолчанию 0.0.0.0/0 по протоколу BGP со стороны клиентских маршрутизаторов в направлении Yandex Cloud использование NAT-шлюза не допускается.

2. Сейчас в Yandex Cloud нет возможности распределять исходящий трафик из облачных подсетей в направлении инфраструктуры клиента на основе метода BGP community.

Взаимодействие с группами безопасностиВзаимодействие с группами безопасности

Группы безопасности используются для защиты облачных ресурсов Yandex Cloud и не могут быть использованы для фильтрации трафика вне Yandex Cloud.

Правила в группах безопасности должны настраиваться для префиксов, которые анонсируют клиентские маршрутизаторы в направлении Yandex Cloud. Например, для разрешения доступа из инфраструктуры клиента к веб-приложению (порт 443), развернутому в Yandex Cloud, группа безопасности должна быть настроена следующим образом:

ingress {
      protocol       = "TCP"
      port           = 443
      description    = "Allow ingress traffic from Interconnect to Web server"
      v4_cidr_blocks = ["172.16.1.5/32"]
    }
egress {
      protocol       = "ANY"
      description    = "We allow any egress traffic"
      v4_cidr_blocks = ["10.0.0.0/8"]
    }

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

При необходимости можно использовать более гранулярные правила, открывая доступ только к отдельным IP-адресам или подсетям и портам:

ingress {
      protocol       = "TCP"
      port           = 443
      description    = "Allow ingress traffic from Interconnect to Web server"
      v4_cidr_blocks = ["172.16.1.5/32"]
    }
egress {
      protocol       = "TCP"
      port           = 3389
      description    = "Allow RDP traffic to server behind Interconnect"
      v4_cidr_blocks = ["10.10.10.10/32"]
    }