[Yandex Cloud documentation](../../index.md) > [Yandex Cloud Interconnect](../index.md) > [Concepts](index.md) > Public connection

# Public connection

A public connection provides access to Yandex Cloud [services](#svc-list). A public connection is set up within a [trunk](trunk.md) and has its own unique **VLAN-ID**. A single trunk can host multiple public connections enabling access to various combinations of [services](#svc-list).

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 {#svc-list}

Each Yandex Cloud service has its own entry point: `API Endpoint`. You can view the list of entry points for Yandex Cloud services [here](https://api.cloud.yandex.net/endpoints). 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/index.md) | storage.yandexcloud.net
[Container Registry](../../container-registry/index.md) | container-registry.api.cloud.yandex.net, cr.yandex
[Yandex SpeechKit](https://aistudio.yandex.ru/docs/en/speechkit/overview) | transcribe.api.cloud.yandex.net<br>tts.api.cloud.yandex.net<br>stt.api.cloud.yandex.net
[Yandex Monitoring](../../monitoring/index.md) | monitoring.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](../../storage/index.md) 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](../../storage/index.md).

You need to set up traffic routing in your infrastructure so that traffic to Yandex Cloud [services](#svc-list) goes through the devices handling [NAT functions](#pub-nat) for the public connection.


## Point-to-point subnet {#pub-address}

You can set up a point-to-point subnet for public connection using the following methods:

1. Using IPv4 addresses from the Yandex Cloud [address pool](../../vpc/concepts/ips.md). With this method, the customer is assigned a `/31` **point-to-point subnet** from the Yandex Cloud address pool. The customer must use a private BGP ASN to set up BGP peering.
1. 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](#pub-bgp) for setting up BGP peering listed below.


{% note alert %}

[Services](#svc-list) accessible through a public connection are hosted in [our own data centers](../../overview/concepts/geo-scope.md). Traffic within a public connection between your infrastructure and the [services](#svc-list) stays within Yandex Cloud.

{% endnote %}

## BGP connectivity {#bgp-peering}

BGP connectivity is configured within each private or public connection between the client equipment and Yandex Cloud equipment at the [point of presence](pops.md) for exchanging subnet (prefix) data. After exchanging this routing data, the sides can distribute IPv4 traffic across the subnets they communicated to each other.

{% note warning %}

On the Yandex Cloud equipment side, there is a [limit](limits.md#interconnect-limits) 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.

{% endnote %}

### BGP ASN {#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](https://datatracker.ietf.org/doc/rfc6996) 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](https://datatracker.ietf.org/doc/rfc5398) 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.

{% note 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.

{% endnote %}



### BGP authentication (optional) {#bgp-auth}

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 {#bfd}

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](https://en.wikipedia.org/wiki/Bidirectional_Forwarding_Detection).

The BFD protocol is always enabled on the Yandex Cloud equipment side and has the following parameter values:
* `timer`: 300ms
* `multiplier`: 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 {#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 {#pub-bgp}

If you need to announce your own public IP prefixes for setting up BGP peering for a public connection, follow these rules:

1. Your public IP prefixes must be properly registered. This involves creating the [Route Object](https://docs.db.ripe.net/entire-documentation-HTML.html#creating-route-objects) and [Route Origin Authorization](https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/resource-certification-roa-management/) objects with the regional registrar.
1. 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.
1. Your IP prefixes must be longer than or equal to `/24`. Yandex Cloud equipment will discard any more specific prefixes, i.e., `/25` to `/32`.

## NAT functions {#pub-nat}

When setting up a public connection (type 1 point-to-point subnet) with IPv4 addresses provided by Yandex Cloud, you need to implement [NAT](https://en.wikipedia.org/wiki/Network_address_translation) 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](#pub-address). 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 (`/32` prefix), 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.


## Use cases {#examples}

* [Creating a direct trunk and a public connection in it](../tutorials/trunk-pub-add.md)
* [Creating a new partner trunk and a public connection in it](../tutorials/partner-trunk-pub-add.md)
* [Adding a public connection to a trunk](../tutorials/pub-add.md)
* [Deleting a public connection](../tutorials/pub-del.md)