Public connection
A public connection provides access to Yandex Cloud services. A public connection is set up within a trunk and has its own unique VLAN-ID. A single trunk can host multiple public connections enabling access to various combinations of services.
The maximum IP MTU for a public connection is 1,500 bytes. Yandex Cloud equipment does not support changing the IP MTU.
List of services
Each Yandex Cloud service has its own entry point: API Endpoint. You can view the list of entry points for services here. Each entry point has its own ID and address that consists of FQDN API Endpoint and the number of the port to which this service gets requests.
Below, you can see the list of Yandex Cloud services you can access through a public connection:
| Service name | API Endpoint (FQDN) |
|---|---|
| Object Storage | storage.yandexcloud.net |
| Cloud Functions | serverless-functions.api.cloud.yandex.net |
| Container Registry | container-registry.api.cloud.yandex.net, cr.yandex |
| Yandex SpeechKit | transcribe.api.cloud.yandex.net |
| Yandex Vision OCR | vision.api.cloud.yandex.net |
| Yandex Translate | translate.api.cloud.yandex.net |
| Cloud API Gateway | api.cloud.yandex.net |
| Yandex Monitoring | monitoring.api.cloud.yandex.net |
| Text generation API in Foundation Models | llm.api.cloud.yandex.net |
| All-Services | All Yandex Cloud services listed above |
Technically, a public connection ensures connectivity between your infrastructure and the IP address to which the respective service's FQDN API Endpoint is converted. FQDN is converted to an IP address through DNS.
For example, if you want to get access from your infrastructure to Object Storage through a service connection, the Yandex Cloud equipment will announce the 213.180.193.243/32 prefix to your router over BGP. This prefix maps to the storage.yandexcloud.net API Endpoint FQDN for Object Storage.
You need to set up traffic routing in your infrastructure so that traffic to Yandex Cloud services goes through the devices handling NAT functions for the public connection.
Point-to-point subnet
You can set up a point-to-point subnet for public connection using the following methods:
- Using IPv4 addresses from the Yandex Cloud address pool. With this method, Yandex Cloud assigns a
/31point-to-point subnet to the customer. The customer must use a private BGP ASN to set up BGP peering. - Using private (RFC-1918) or custom public IPv4 addresses. This method is used if the customer plans to announce their custom public IP prefixes via the point-to-point subnet. In this case, the customer must follow the recommendations for setting up BGP peering listed below.
Alert
Services accessible through a public connection are hosted in our own data centers. Traffic within a public connection between your infrastructure and the services stays within Yandex Cloud.
BGP connectivity
BGP connectivity is configured within each private or public connection between the client equipment and Yandex Cloud equipment at the point of presence for exchanging subnet (prefix) data. After exchanging this routing data, the sides can distribute IPv4 traffic across the subnets they communicated to each other.
Warning
On the Yandex Cloud equipment side, there is a limit on the number of prefixes received from the client router over BGP.
Once this limit is exceeded, the BGP session will be terminated for 30 minutes.
To maintain continuous BGP connectivity, we recommend setting up policies for routing information aggregation on the client router that will keep the number of prefixes announced over BGP towards the Yandex Cloud equipment at a reasonable and required level.
BGP ASN
To set up BGP connectivity, each side must specify the BGP autonomous system number (ASN) in ASPlain format. The BGP ASN value for Yandex Cloud is fixed at 200350.
On client equipment, you are allowed to use the public BGP ASN (if available). On client equipment, you are allowed to use any value from the following RFC 6996 ranges of private BGP ASNs:
64512 - 65534: For two-byte BGP ASNs.4200000000 - 4294967294: For four-byte BGP ASNs.
On client equipment, you are not allowed to use the following RFC 5398 ranges of BGP ASNs:
64496 – 64511: For two-byte BGP ASNs.65536 – 65551: For four-byte BGP ASNs.
On client equipment, you are not allowed to include any BGP ASN from the above ranges in the BGP AS_Path attribute.
Warning
On the Yandex Cloud side, a 4-byte BGP ASN value, 200350, is used. When using network equipment from different vendors, 2-byte BGP ASNs are often preferred as the most common option.
When setting up BGP connectivity on the client router side, make sure to explicitly allow 4-byte BGP ASNs in its configuration.
When setting up BGP interaction on the client router, for public connections on public IPv4 addresses owned by the client, make sure to specify the client's public BGP ASN.
BGP authentication (optional)
To increase security of a BGP connection, you can use BGP authentication based on BGP MD5 password. If you enable this feature, use a string of more than 20 characters as a password, which may include Latin letters, numbers, and special characters.
BFD protocol
If a client cannot connect their router directly to the Yandex Cloud equipment, they can use intermediate network devices (switches). For fast fault detection on the intermediate network devices, use the BFD protocol.
The BFD protocol is always enabled on the Yandex Cloud equipment side and has the following parameter values:
timer: 300msmultiplier: 3
These values are fixed and cannot be changed manually.
The client can configure the timer value on their equipment as needed. When establishing a BFD session, these parameters will be aligned over BFD between the client and Yandex Cloud equipment.
We do not recommend setting multiplier to anything other than 3, as this may cause BFD performance issues.
BGP timers
Below you can see the values (in seconds) of timers configured on the Yandex Cloud equipment by default:
minimum-hold-time=90
Using values below the specified ones on the client equipment side will cause issues with establishing a BGP adjacency.
Setting up BGP peering when announcing custom IP prefixes
If you need to announce your own public IP prefixes for setting up BGP peering for a public connection, follow these rules:
- Your public IP prefixes must be properly registered. This involves creating the Route Object and Route Origin Authorization objects with the regional registrar.
- A public BGP ASN can only be used for setting up BGP peering between your equipment and Yandex Cloud equipment. Using private BGP ASNs for such communication is not allowed.
- Your IP prefixes must be longer than or equal to
/24. Yandex Cloud equipment will discard any more specific prefixes, i.e.,/25to/32.
NAT functions
When setting up a public connection (type 1 point-to-point subnet) with IPv4 addresses provided by Yandex Cloud, you need to implement NAT on your equipment to route your traffic correctly across Yandex Cloud services. You can implement NAT in the following ways:
-
Running a NAT function on your equipment (router) which establishes the public connection. All public connection traffic originates from the IPv4 address of the router interface in the point-to-point subnet. In this case, your router handling the public connection must announce the point-to-point subnet prefix to the Yandex Cloud equipment over BGP.
-
Running a NAT function on your equipment that is not used for the public connection, e.g., on a server or firewall. In this case, Yandex Cloud additionally allocates an auxiliary IPv4 address (
/32prefix), and your router handling the public connection will announce this prefix over BGP to the Yandex Cloud equipment.
When using custom IPv4 addresses (type 2 point-to-point subnet), NAT functions must utilize those IP addresses.