Routing Instance

The Routing Instance (RI) object is a core resource in the Cloud Router resource model. It is designed to create network topologies enabling network connectivity between cloud resources in different networks.

General rules and recommendationsGeneral rules and recommendations

When using Cloud Router and Cloud Interconnect, we strongly recommend to follow these rules and guidelines:

1. All network segments (both cloud and on-prem sides) connected via Routing Instance (RI) must use non-overlapping, coordinated IP addressing. Subnet IP prefixes you add to an RI must be coordinated between themselves. You cannot add two identical IP prefixes to a single RI. On-Prem IP addressing must be aligned with IP addressing in the virtual cloud networks. IP address overlapping will cause IP connectivity problems. Plan IP addressing carefully.

2. Network communication across virtual networks is strictly confined to a single cloud organization. All Cloud Router and Cloud Interconnect resources, as well as the virtual cloud networks that are going to be integrated into a network topology using an RI, must reside in cloud folders within the same cloud organization. For network connectivity between virtual cloud networks belonging to different cloud organizations, consider migrating clouds from several organizations into a single one.

   If such migration is not feasible, you have to obtain formal written consents (on paper) from owners of all such cloud organizations for cross-organization networking. For detailed information about the verification procedure, contact Yandex Cloud support.

3. No direct exchange of routing info between any private connections (PRCs) within an RI is allowed.

4. The IP prefixes announced by the customer’s network hardware also get into the RI and from there to the virtual networks connected to that RI. Currently, you cannot view these IP prefixes at the RI level. We recommend getting this information from the customer's network hardware. In some cases, if routing issues arise, you may want to contact support for this information.

5. You can only add a VPC network ID, vpc_network_id, to one Routing Instance at a time. An attempt to add the same ID to another Routing Instance will fail.

6. You can only add a private connection ID, cic_private_connection_id, to one Routing Instance at a time. An attempt to add the same ID to another Routing Instance will fail.

Tips for configuring private connectionsTips for configuring private connections

1. Always set up two Cloud Interconnect communication circuits through two points of presence. This will keep your services up and running if one of the circuits fails.

2. To simplify the setup of fault-tolerant BGP routing, consider using the same BGP ASN for multiple customer edge routers connecting to Cloud Interconnect. You can use different BGP ASNs, e.g., when setting up connections via telecom providers. Keep in mind that Yandex Cloud is not responsible for configuring the customer and telecom provider network hardware.

3. If the customer's two Cloud Interconnect communication circuits connect to different routers, ensure iBGP connectivity is configured between these customer routers. Without such connectivity, if one of the communication circuits fails on one of the routers, the remaining one will learn nothing about the failure and the dead circuit's traffic will not be automatically rerouted to the live circuit over BGP.

4. Use prefixes of different lengths for BGP announcements on customer edge routers if you need to distribute outgoing traffic from cloud networks across multiple Cloud Interconnect communication circuits:

   • Short prefixes, such as /8, have the lowest route priority.
   • Long prefixes, such as /32, have the highest route priority.

   For more information on traffic distribution between multiple communication circuits, see use cases.

5. When selecting a communication circuit for outgoing traffic from the customer infrastructure to cloud networks, consider using the Local Preference BGP attribute on the customer edge router. For more information on traffic distribution between multiple communication circuits, see use cases.

Networking limitationsNetworking limitations

1. You can use Cloud Interconnect along with a NAT gateway if customer edge routers do not announce the 0.0.0.0/0 default route over BGP to Yandex Cloud. If customer edge routers do announce the 0.0.0.0/0 default route over BGP to Yandex Cloud, you cannot use a NAT gateway.

2. Currently, Yandex Cloud does not support routing of outgoing traffic from cloud subnets to the customer infrastructure using BGP community attributes.

Working with security groupsWorking with security groups

Security groups are used to protect Yandex Cloud resources and cannot be used for filtering traffic outside Yandex Cloud.

Security group rules should be set up for the prefixes announced by customer edge routers to Yandex Cloud. For example, to allow access from the customer infrastructure to a web application (port 443) deployed in Yandex Cloud, set up a security group as follows:

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"]
    }

The Egress security group rule allows any cloud resources to access customer infrastructure resources on any port without any restriction.

If required, you can use more granular rules to only allow access to specific IP addresses or subnets and ports:

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"]
    }