BGP

• Fluxo v4 e v6

• Neighbor

• Route Map

• Prefix-list

• ASN
 ASN
• Tabela asn

• Name: ASN

• Description: nome do rack/

nome acordado

• Tabela asn_equipment
(relaciona o equipamento ao
seu asn)

• Id do equipamento

• Id do asn
 Prefix-list
Equipamento DELL: Template DELL:

ip prefix-list web-media-cloud_dev1 ip prefix-list {{ NAME }}

seq 10 permit [Link]/16 le 25 {{ CONFIG }}
seq 100 deny any

ip prefix-list web-media-cloud_dev2
seq 20 permit [Link]/24
seq 100 deny any

ip prefix-list web-media-cloud_devout
seq 100 deny any
 Prefix-list
• Tabela list_config_bgp

• Name: identificador do
prefix-list

• Type: P (permit) ou D (deny)

• Config: sendo uma string

deve respeitar a forma
como o template foi criado
e os comandos/expressões
que o equipamento usa.
 Route Map
• Tabela route_map

• Name: identificador do route-

map

• Tabela route_map_entry

• Action: P(permit) ou D(deny)

• Order: ordenação

• id_list_config_bgp: associa ao
prefix_list

• id_route_map: indica o
identificador do route_map
 Route Map
• Tabela equipment_route_map:
semelhante à flag “created”

• id_equipment: id do
equipamento “local" onde o
neighbor foi configurado

• id_route_map: id do route-
map que já foi configurado
no switch

São duas entradas para cada

equipamento, um para o route-
map in e outro para o out
 Route Map
Equipamento DELL: Template DELL:

route-map WEBMEDIACLOUD_DEV_IN permit 1 {% for ENTRY in ENTRIES %}

match ip address web-media-cloud_dev1 route-map {{ NAME }} {{ [Link] }}
{{ [Link] }}
route-map WEBMEDIACLOUD_DEV_IN permit 2 match ip address prefix-list {{ [Link] }}
match ip address web-media-cloud_dev2 {% endfor %}

route-map WEBMEDIACLOUD_DEV_OUT permit 1

match ip address web-media-cloud_devout
 Peer Group
• Tabela peer_group (agrupa a
informação sobre os route-
maps

• Name: nome do peer group

• id_route_map_in: id do
route-map das rotas
recebidas

• id_route_map_out: id do
route-map das rotas
anunciadas
 Neighbor
• Tabela neighbor_v4 (ipv4)

• Local: equipamento que vai ser

configurado

• id_local_asn: id do asn

• id_local_ip: id do ip da config do
bgp

• Remoto: peer bgp

• id_remote_asn: id do asn do peer

• id_remote_ip: id do ip do peer

• id_peer_group: associa aos route-maps

•
 Neighbor
Template DELL:
Equipamento DELL:
router bgp {{ AS_NUMBER }}
vrf {{ VRF_NAME }}
neighbor [Link] remote-as 65040 neighbor {{ REMOTE_IP }}
description {{ DESCRIPTION }}
neighbor [Link] description None remote-as {{ REMOTE_AS }}
neighbor [Link] fall-over {% if not PASSWORD == None %}
password {{ PASSWORD }}
neighbor [Link] route-map {% endif %}
{% if not TIMER_KEEPALIVE == None %}
WEBMEDIACLOUD_DEV_IN in timers {{ TIMER_KEEPALIVE }} {{ TIMER_TIMEOUT }}
neighbor [Link] route-map {% endif %}
{% if REMOVE_PRIVATE_AS %}
WEBMEDIACLOUD_DEV_OUT out remove-private-AS
{% endif %}
neighbor [Link] next-hop-self {% if COMMUNITY %}
send-community extended
neighbor [Link] send-community {% endif %}
neighbor [Link] soft-reconfiguration fall-over

inbound address-family ipv4 unicast

{% if NEXT_HOP_SELF %}
neighbor [Link] no shutdown next-hop-self
{% endif %}

{% if SOFT_RECONFIGURATION %}
soft-reconfiguration inbound
{% endif %}

{% if not ROUTE_MAP_IN == None %}

route-map {{ ROUTE_MAP_IN }} in
{% endif %}

{% if not ROUTE_MAP_OUT == None %}

route-map {{ ROUTE_MAP_OUT }} out
{% endif %}

no shutdown
 Plugin
• A netapi gera três arquivos de configuração. Um para configurar o neighbor, um para
configurar o route-map e outro para configurar o prefix-list.

• A configuração do neighbor sempre vai acontecer. Pra configurar os filtros, a netapi

utiliza a tabela equipment_route_map para o controle. Se os filtros forem utilizados em
mais de um neighbor do mesmo switch, ela não tenta configurar novamente. Exemplo:

• Se há mais de um peer com os mesmos route-maps no mesmo switch (o

equipamento que a netapi conhece como ”local”), ao configurar o primeiro, a api vai
deployar o neighbor, o route-map e o prefix-list. No segundo, vai configurar apenas
o neighbor pois, através da entrada na tabela equipment_route_map ela sabe que
os filtros já foram configurados.

• Na remoção é semelhante, se há mais de um neighbor deployado no mesmo

equipamento com o mesmos route-maps, a netapi vai remover apenas as
configurações do neighbor. Se há apenas um, vai remover o neighbor, os route-
maps e o prefix-list.
 Exemplos
1. Criar o neighbor para o servidor

POST /api/v4/neighborv4/ - Essa chamada vai retornar um ID de neighbor.

{
"neighbors": [
{
"local_asn": <ID do AS do switch - vamos decidir e passar pra voces de acordo com onde rodaremos os testes>,
"local_ip": <ID ip do router/switch ToR que sera utilizado para o bgp>,
"remote_asn": <ID do ASN para testes - vamos decidir e passar pra voces>,
"remote_ip": <ID ip do host tsuru que será utilizado para bgp>,
"soft_reconfiguration": true,
"community": true,
"next_hop_self": true,
"peer_group": <vamos decidir e passar pra voces>,
"remove_private_as": false,
"kind": "I"
}
]
}

Ex: [{"id": 3}]

2. Fazer deploy da config do neighbor para o switch

POST /api/v4/neighborv4/deploy/<id>

REMOCAO
1. Remover deploy da config do neighbor para o switch:
DELETE /api/v4/neighborv4/deploy/<id>/
{}

2. Remover entrada do neighbor da networkapi

DELETE /api/v4/neighborv4/<id>/
{}
 Exemplos
Exemplo passo a passo incluindo buscas que possam ser necessárias para ter o id de ips, asns e afins para o json de criação do neighbor:

Dado a seguinte máquina:

node: [Link]
ip: [Link]

## Passo 1:
Fazer uma consulta na api pelo ip do host para descobrir o id da rede que esse host se encontra.

GET {{network-api}}/api/v3/ipv4/?fields=networkipv4,id&search={"extends_search":[{"oct1":10,"oct2":224,"oct3":158,"oct4":200}]}

## Passo 2
Utilizando esse id e o nome do ToR extraído do hostname e seguindo a regra de formação combinada (no caso al08, forma-se o nome 'LF-CM-<RACK>-<1|2>'
para os dois leafs).

Com esses dados fazer essa consulta para descobrir o ip do ToR nessa rede.
OBS: O ip do ToR é o último resultado. O primeiro é o ip do ToR em uma rede entre os leafs.

GET {{network-api}}/api/v3/ipv4/?fields=id,networkipv4&search={"extends_search":[{"networkipv4":322656, "ipequipamento__equipamento__nome":"LF-CM-

AL08-1"}]}

Fazer essa consulta para os dois ToR.

## Passo 3
O passo anterior retorna o id do ip, então é necessário fazer a consulta abaixo para cada leaf.

GET {{network-api}}/api/v3/ipv4/2634097
 Exemplos
## Passo 4
Descobrir id do ASN do rack

GET {{network-api}}/api/v4/as/?fields=id&search={'custom_search': 'AL08', 'searchable_columns': ['description']}

## Passo 5
Criar o neighbor

POST {{network-api}}/api/v4/neighborv4/
{"neighbors": [{
"local_asn": 3, # Id do AS do switch do rack retornado no passo 4,
"local_ip": 2634097, # Id do IP retornado no passo 2
"remote_asn": <a definir>, # Id do ASN do cluster definido e criado por suptel.
"remote_ip": 2634260, # id do ip retornado no passo 1
"soft_reconfiguration": true,
"community": true,
"next_hop_self": true,
"peer_group": <a definir>, # Id do peer_group criado para o neighbor por suptel
"remove_private_as": false,
"kind": "I" }]}