> ## Documentation Index
> Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Tabelas de rotas e rotas

> A tabela que uma sub-rede usa é o que a torna pública ou privada — e exatamente uma rota por destino.

<a id="route-tables" />

## Tabelas de rotas

Cada VPC recebe uma tabela padrão chamada `<vpc-name>-private-rt` quando é criado. Sub-redes usam-no a menos que eles fornecem um `route_table` Os nomes das tabelas são exclusivos por VPC. Nomes longos gerados são encurtados com um hash.

As tabelas padrão existentes anteriormente chamadas de `main` são renomeadas no lugar; seus IDs, rotas e associações de sub-rede permanecem inalteradas. Um sufixo numérico resolve colisões de nomes. A função padrão é identificada por `is_main`, independentemente do seu nome. O nome histórico `main` permanece reservado.

<Tabs>
  <Tab title="Console">
    Vá para **Networking → Route Tables** e escolha **Create Route Table**. Em **Route table details**, escolha o **VPC** e dê um **Name**.
  </Tab>

  <Tab title="API">
    ```bash theme={null}
    POST /v1/route-tables
    { "vpc": "<vpc>", "name": "private" }
    ```
  </Tab>

  <Tab title="CLI">
    ```bash theme={null}
    basaltic network route-table create --vpc <vpc-id> --name private
    ```
  </Tab>

  <Tab title="Go">
    ```go theme={null}
    rt, err := network.New(cfg).CreateRouteTable(ctx, &network.RouteTableCreateRequest{
        VPC: vpcID,
        Name:  "private",
    })
    ```
  </Tab>
</Tabs>

As respostas da tabela de rotas incluem o objeto `vpc` completo em vez de `vpc_id`, então `vpc.id` e `vpc.name` identificam o pai sem uma pesquisa somente de exibição. A criação ainda leva uma referência de string `vpc`.

Uma sub-rede incorpora apenas um resumo da tabela de rotas (`id`, `crn`, `name`), que pode ser nulo; ela não contém rotas nem repete a VPC. Obter as rotas da tabela ao verificar a acessibilidade. Respostas de rotas individuais ainda carregam `route_table_id` para identificar sua tabela.

Excluir uma tabela é recusado em dois casos: a tabela principal não pode ser excluída de todo, e uma tabela ainda associada a sub-redes é recusada com "reassocie-as primeiro". As rotas em uma tabela desaparecem com ela.

<a id="routes" />

## Rotas

<Tabs>
  <Tab title="Console">
    Abra a tabela em **Networking → Route Tables** e escolha **Add
    Route**. Preencha **Destination CIDR** e escolha um **Target type** — **IP
    address**, **Internet Gateway**, **NAT Gateway** ou **Egress-Only
    Gateway** — e o campo abaixo dele será alterado para corresponder. Confirme com **Add
    Route**.
  </Tab>

  <Tab title="API">
    ```bash theme={null}
    POST /v1/route-tables/{route_table_id}/routes
    { "destination_cidr": "10.1.0.0/16", "next_hop_ip": "10.0.1.9" }
    ```
  </Tab>

  <Tab title="CLI">
    ```bash theme={null}
    basaltic network route create <route-table-id> \
      --destination-cidr 10.1.0.0/16 --next-hop-ip 10.0.1.9
    ```

    Troque `--next-hop-ip` por `--target-internet-gateway`, `--target-nat-gateway` ou `--target-egress-only-gateway`. Exatamente um.
  </Tab>

  <Tab title="Go">
    ```go theme={null}
    r, err := network.New(cfg).CreateRoute(ctx, routeTableID, &network.RouteCreateRequest{
        DestinationCIDR: "10.1.0.0/16",
        NextHopIP:    basaltic.String("10.0.1.9"),
    })
    ```
  </Tab>
</Tabs>

`destination` é um CIDR, e **exatamente um** campo de destino deve ser definido:

<ResponseField name="next_hop_ip" type="string">
  Um próximo salto de unicast **dentro do CIDR dessa VPC**, da mesma família que o destino. Endereços de loopback, link-local, multicast e não especificados são rejeitados, assim como qualquer coisa fora da VPC. Isso é para dispositivos e NICs que você executa sozinho. A saída da Internet não pode ser expressa dessa maneira, porque um destino de gateway é o que fixa a rota ao uplink da sua própria VPC.
</ResponseField>

<ResponseField name="target_internet_gateway" type="string">
  O gateway deve estar conectado e conectado a **esta** VPC. Caso contrário, a criação falha com "gateway de internet de destino não está conectado a uma VPC" ou "gateway de internet de destino está conectado a uma VPC diferente".
</ResponseField>

<ResponseField name="target_nat_gateway" type="string">
  Suporta IPv4 e IPv6. Use `0.0.0.0/0` e `::/0` para saída de internet compartilhada. Uma rota IPv6 requer IPv6 na sub-rede de hospedagem do gateway. Adicionar uma rota não aloca os endereços do gateway.
</ResponseField>

<ResponseField name="target_egress_only_gateway" type="string">
  Destinos IPv6 apenas, e recusou o contrário.
</ResponseField>

<Note>
  No console, isso é **Target type → Egress-Only Gateway** em **Add
  Route**. A caixa de diálogo verifica o emparelhamento à medida que você digita: nomear um destino IPv4 com um alvo somente de saída é recusado antes de enviar.
</Note>

<a id="one-route-per-destination" />

### Uma rota por destino

Uma tabela contém no máximo uma rota para um determinado destino. Um segundo é recusado com `409`.

Não há par de custo igual e não há desempate entre duas rotas para o mesmo prefixo, porque a segunda nunca é criada.

O `destination` e o target de uma rota são imutáveis; `PATCH` só leva `description` e `tags`. Para reposicionar uma rota, exclua-a e crie a substituição.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.