Private connection
A private connection is a logical link of your on-prem infrastructure to a virtual network in a cloud. A private connection’s destination in the cloud network is a routing instance.
Here is an example of using two private connections to set up fault-tolerant IP connectivity:
Warning
However, you cannot set up multiple private connections to a single cloud network at the same point of presence. For redundancy purposes, you can set up multiple private connections per cloud network in different points of presence.
The main components of a private connection are:
The cloud network and on-prem infrastructure will then exchange routes via the configured BGP to start sending traffic between on-prem and cloud network resources.
A private connection is set up within a trunk. You can have multiple private connections to different cloud networks in a single trunk.
A private connection is set up inside a trunk and has its own unique VLAN ID.
The maximum IP MTU for a private connection is 8,910 bytes. Yandex Cloud equipment does not support changing the IP MTU.
Point-to-point subnet
To set up a private connection, you need a point-to-point subnet. It is used to configure IP connectivity between the Yandex Cloud equipment and the customer or telecom provider equipment.
A point-to-point subnet can be either /30 or /31 in size. You cannot use subnets of other sizes.
You can use the following IP address ranges in your point-to-point subnet:
10.0.0.0/8172.16.0.0/12192.168.0.0/16169.254.0.0/16
IP addressing in other ranges is not allowed.
Note
When setting up a private connection, you can only use IPv4 addresses.
Currently, you cannot use IPv6 addresses.
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.
Private connection topologies
The following options for setting up private connections are supported:
- Private connection through a direct customer connection.
- Private connection through a telecom provider connection (L2 transit).
- Private connection through a telecom provider connection (L3VPN).
Private connection through a direct customer connection
This scenario implies setting up L3 and BGP connectivity between the customer equipment at the point of presence and the Yandex Cloud equipment. In this case, the following applies:
- You independently provide L3 connectivity between your equipment in your data center and your equipment at the point of presence.
- Your equipment at the point of presence establishes BGP peering with the Yandex Cloud equipment.
- All BGP route announcements from your equipment at the point of presence enter all Yandex Cloud availability zones.
Private connection through a telecom provider connection (L2 transit)
This scenario assumes you do not have your own equipment at the point of presence and you use the services of a telecom provider that ensures connectivity between Yandex Cloud and your own equipment. In this case, the following applies:
- The telecom provider sets up L2 connectivity between its equipment at the point of presence and the Yandex Cloud equipment.
- Your equipment in your data center establishes L3 connectivity and BGP peering with the Yandex Cloud equipment at the point of presence.
- All BGP route announcements from your equipment in your data center enter all Yandex Cloud availability zones.
Private connection through a telecom provider connection (L3VPN)
This scenario also assumes you do not have your own equipment at the point of presence and you use the services of a telecom provider that ensures connectivity between Yandex Cloud and your own equipment. You cannot technically set up BGP peering with the Yandex Cloud equipment on your own. In this case, the following applies:
- The telecom provider sets up L2 connectivity between its equipment at the point of presence and the Yandex Cloud equipment.
- The telecom provider equipment establishes L3 connectivity and BGP peering with the Yandex Cloud equipment at the point of presence. This connection integrates into the customer L3VPN, which ensures direct connectivity between your equipment in your data center and Yandex Cloud.
- All BGP route announcements from the telecom provider equipment at the point of presence enter all Yandex Cloud availability zones.
- While providing L3VPN, the telecom provider can use both static and dynamic routing protocols.