Integração de Equipamentos com BGP

Prévia do material em texto

1
MikrotikBrasil
Consultoria e Treinamentos 
Integração de Equipamentos
2
BGP – Border Gateway Protocol
3
Um AS é uma coleção de redes e roteadores sob a mesma administração técnica e 
que apresenta ao mundo exterior uma política de roteamento coerente. 
Autonomous System (AS) e a Internet
Cada AS possui um número único que é atribuido por entidades da governança 
da Internet (No caso da América Latina, a LACNIC). Os números de AS de 
64512 a 65535 são reservados para AS’s privados.
AS 300
4
Um Internet nada mais é que um conjunto de AS’s interligados e que estão cada um 
sob administrações técnicas distintas. 
Autonomous System (AS), a Internet e o BGP
O Protocolo BGP foi pensado exatamente para lidar com o tráfego entre AS’s 
sob diferentes administrações.
BGP
BGP
BGP
BGP
5
Cenários de uso do BGP
Cliente Single Homed
Internet
Provedor de 
Acesso
Cliente final ou 
pequeno provedor 
de acesso
Porque esse pequeno cliente precisaria de BGP ?
BGP
6
Cenários de uso do BGP
Cliente Multi Homed
InternetProvedor de 
Acesso 1
Cliente final ou 
provedor multihomed
BGP
Provedor de 
Acesso 2
BGP
7
Cenários de uso do BGP
AS de transito
InternetProvedor de 
acesso e transito
Cliente final ou 
provedor multihomed
BGP
Provedor de 
acesso e transito
BGP
BGP
Cliente final BGP
8
Protocolo BGP
 O protocolo BGP (Border Gateway Protocol) é um protocolo do tipo “Distance 
Vector”utilizado para fazer a interconexão dos AS’s. 
 A versão corrente do BGP é a versão 4, especificada na RFC 1771. 
 Os prefixos de rede são anunciados com uma lista dos AS’s que estão no caminho 
(AS Path) 
 A topologia interna de cada AS não é informada, mas somente as informações 
sobre como encontrar as redes (reacheability) 
9
Implementação Path Vector
AS 100
AS 200
AS 300
AS 400
10
Implementação Path Vector
AS 100
AS 200
AS 300
AS 400
Rede 10.100.0.0/24
11
Implementação Path Vector
AS 100
AS 200
AS 300
AS 400
Rede 10.100.0.0/24
Adiciona 100 ao path
12
Implementação Path Vector
AS 100
AS 200
AS 300
AS 400
Rede 10.100.0.0/24
Adiciona 100 ao path
Adiciona 200 ao path
13
Implementação Path Vector
AS 100
AS 200
AS 300
AS 400
Rede 10.100.0.0/24
Adiciona 100 ao path
Adiciona 200 ao path
Adiciona 300 ao path
14
Implementação Path Vector
AS 100
AS 200
AS 300
AS 400
Rede 10.100.0.0/24
Adiciona 100 ao path
Adiciona 200 ao path
Adiciona 300 ao path
O AS 400 sabe que, para alcançar a rede 10.100.0.0/24 tem que passar por 300 e 200
15
Implementação Path Vector
tratamento de loopings
AS 100
AS 200
AS 300
AS 400
Rede 10.100.0.0/24
Adiciona 100 ao path
Adiciona 200 ao path
Adiciona 300 ao path
Anuncio do próprio AS
16
BGP princípios básicos 
O BGP opera trocando informações sobre a “encontrabilidade” de redes por 
mensagens de NLRI (Network Layer Reachability Information) 
As NLRI incluem um conjunto de atributos do BGP e um ou mais prefixos com os 
quais esses atributos estão associados. 
O BGP utiliza o protocolo TCP, porta 179 para garantir a confiabilidade das 
informações. 
Ao contrário de protocolos como o RIP e OSPF, o BGP precisa que os vizinhos 
configurem de forma estática seus vizinhos (Peers)
17
Peering BGP
Uma vez que é estabelecido um Peer BGP, os AS’s trocam informações de rotas e 
uma vez que todas elas tenham sido trocadas, somente se realiza a manutenção das 
mesmas através de mensagens de UPDATE.
Periodicamente os vizinhos BGP mandam também mensagens de KEEPALIVE para 
verificar o estado do vizinho.
AS 100 AS 200Peer BGP
18
Debug do estado do BGP
Ativar o log com debug para BGP em /system logging
19
Mensagens do BGP
Para promover o aprendizado sobre rotas para prefixos IP alcançáveis, um BGP 
speaker está engajado no intercambio de informações de alcançabilidade de redes 
com seus vizinhos BGP. Durante um intercambio, uma sessão BGP pode cair e 
devido a isso a operação básica do BGP também precisa saber como lidar com 
essas situações. Para possibilitar várias atividades do BGP o protocolo define 4 tipos 
de mensagens obrigatórias para todos os sistemas BGP:
 OPEN
 UPDATE
 KEEPALIVE
 NOTIFICATION
E ainda um tipo de mensagem adicional:
 ROUTE-REFRESH
20
Mensages do BGP
Open – Primeira mensagem enviada após a conexão TCP ser estabelecida, e 
confirmada com um keepalive. 
· 
 Holdtime - tempo máximo entre mensagens sucessivas de keepalive e 
update do remetente. 180s de default. Se o holdtime fo zero os routers não 
enviaram Keepalive;
 BGP router ID - Identifica o remetente, é o maior ip da interface ou da 
loopback. Igual ao OSPF;
My AS - O numero da AS do remetente;
Version - Versão do BGP, a utilizada é a 4;
Authentication – caso seja usada autenticação entre os peers.
21
Mensagens (cont.)
Keepalive - Mensagens trocadas de 60 em 60s para verificar se o router está OK, 
com tempo mais rápido que o holdtime;
Update - Contem informações sobre um caminho, diversos caminhos exige diversas 
mensagens;
 Withdrawn routes – Lista dos prefixos de endereço IP que estão sendo 
retiradas de serviço;
 Path attributes – Atributos de caminhos, são: As-Path, Origin, Local 
Preference, etc;
 Network layer reachability Information – Esse campo contém uma lista 
dos prefixos de endereço IP alcançáveis por esse caminho;
Notification - Enviada quando ocorre um erro, a conexão é fechada 
imediatamente 
22
Mensagens do BGP
Common header
OPEN message
UPDATE message
NOTIFICATION message
23
Estados do vizinho BGP
Idle – Estado inicial;
 Connect – Conexão TCP e aguardo;
Active – Realiza tentativas de conexão TCP;
OpenSent – Estado de espera da resposta de conexão do vizinho;
OpenConfirm – Conexão estabelecida;
 Estabilished – Troca de mensagem de atualização, keepalive e 
notificação. 
24
Debug do estado do BGP
Ativar o log com debug para BGP em /system logging
25
BGP - Atributos
Para possibilitar que os roteadores selecionem a melhor rota para um destino 
específico quando mais de uma existe, as rotas aprendidas por BGP carregam alguns 
atributos . Os atributos do BGP são divididos em:
 Atributos Well-known 
Devem ser reconhecidos por todos as implementações de BGP
 Opcionais
Não são obrigatóriamente reconhecidos por todas as implementações de BGP 
26
BGP – Atributos Well-Known
Os atrbutos do tipo Well Known, por sua vêz são divididos em mandatórios e 
discricionários:
Atributos Well-Known mandatórios
Devem estar presentes em todas as mensagens de update 
Atributos Well-Known discricionários
Podem estar ou não presentes nas mensagens de update.
** Todos os atributos do tipo Well-Known são propagados para outros vizinhos
27
Atributos Well-Known Mandatórios
Origin (Origem da rota BGP)
- Rota originada por um IGP
- Rota originada por um EGP
- Rota foi redistribuida no BGP
AS-Path
Sequencia de números de AS’s para acessar a rede
 Next Hop 
Endereço IP do roteador do próximo salto.
28
Atributos Well-Known Discricionários
Local Preference
Utilizado para uma política de roteamento consistente dentro do AS. 
Atomic Aggregate
Informa o AS vizinho que foi feitas sumarização (agregação) de rotas.
29
BGP - Atributos opcionais
Os atributos opcionais do BGP podem ser transitivos e intransitivos
 Atributos opcionais transitivos 
São propagados para outros roteadores, mesmo se não reconhecidos 
Atributos opcionias intransitivos
Não são propagados.
30
Atributo AS-Path
O Atributo AS-Path está vazio quando uma rota local é inserida na tabela BGP
 O número AS do remetente é adicionado (“prependado”) ao AS-Path, sempre que 
um update de roteamento atravessa a borda de um AS.
 O recipiente da informação de roteamento pode usar o atributo AS-Path para 
determinar através de qual AS a informação passou.
 Um AS que recebe informações de roteamento com seu próprio número AS no AS-
Path, silenciosamente ignora e descarta a informação.
31
AS-Path
AS 100 AS 200
AS 300
Rede 10.100.0.0/16Rede 10.100.0.0/16
AS-Path 100
Rede 10.100.0.0/16
AS-Path 200, 100Rede 10.100.0.0/16
AS-Path 300 200, 100
32
Atributo Next-Hop
Indica o endereço IP do próximo salto para encaminhamento de pacotes
Usualmente setado para o IP do roteador externo do BGP (EBGP)
Em muitos casos o roteador pode setar a si próprio como next-hop
 Esse atributo pode ainda ser modificado para um terceiro roteador.
33
Atributo Next hop
AS 100
Rede 10.100.0.0/16
Rede 10.100.0.0/16
AS-Path 100
Next hop 10.0.0.110.0.0.1
AS 200
10.0.0.2
10.0.0.5
10.0.0.6
Rede 10.100.0.0/16
AS-Path 200 100
Next hop 10.0.0.5
34
Next hop com mídia compartilhada
AS 100
Rede 10.100.0.0/16 Rede 10.100.0.0/16
AS-Path 100
Next hop 10.0.0.1
10.0.0.1
AS 200
10.0.0.2
10.0.0.3
Rede 10.100.0.0/16
AS-Path 200 100
Next hop 10.0.01
AS 300
Se o roteador que recebe a rota está na mesma subnet do atual next-hop, este se 
mantém inalterado para otimizar o encaminhamento de pacotes.
35
eBGP e iBGP
eBGP – peering entre roteadores de diferentes AS’s
iBGP – peering entre roteadores do mesmo AS
Questões para discussão:
1 ) Qual é a diferença de configuração que faz com que o Roteador “saiba” que ele 
está usando iBGP ou eBGP ?
2 ) Se tenho um protocolo de roteamento interno ao meu AS distribuindo todas as 
rotas, porque existe a necessidade do iBGP ?
3 ) Porque não utilizar a distribuição dentro do IGP (OSPF, RIP, etc), das rotas 
aprendidas pelo BGP ?
36
eBGP e iBGP 
Split horizon é uma técnica utilizada em roteamento que elimina a possibilidade de 
um esquema de roteamento criar loops, tornando efetivamente roteamento mais 
eficiente. 
Quando um roteador em uma rede recebe um pacote de informação de roteamento, 
ele não envia a mesma informação de volta pelo caminho no qual a informação foi 
recebida (ou seja, ao roteador adjacente que enviou a informação). Ele somente 
envia as informações para outros caminhos para que não haja a possibilidade do 
pacote ser roteado de volta ao caminho originador.
No BGP, o roteador tem dois “mundos” – o que é eBGP e o que iBGP
37
Split Horizon 
38
Regras do Split Horizon para BGP
1) Um BGP speaker pode anunciar para seus vizinhos iBGP os prefixos IP que 
aprendeu a partir de eBGP speakers. 
2) Um BGP speaker pode anunciar para seus vizinhos eBGP os prefixos IP que 
aprendeu a partir de iBGP speakers 
3) Um iBGP speaker não pode anunciar para iBGP speakers, os prefixos IP que 
aprendeu de iBGP speakers 
39
eBGP
 Formado quase sempre por peers diretamente conectados.
 Configuração Multihop é necessária quando os peers não são diretamente 
conectados
 Adiciona o AS ao caminho anunciado.
 Por padrão o Next-Hop é mudado para o IP do próprio roteador.
40
Cenário de LAB de BGP
41
BGP Lab – Detalhe da Infra
42
BGP Lab – Divisão de AS’s
AS65XXX AS650X1
AS650X6
AS65000
43
BGP Lab – Divisão de AS’s
GRUPO X = 1
AS65111 AS65011
AS65016
AS65000
44
Endereços de Loopback
Eliminam a dependencia da interface física
45
Roteiro
(Exemplo Grupo 1)
1) Levantar o IGP (OSPF) dentro do AS 65111 e certificar-se que todos os 
endereços de loopback estão sendo devidamente encontrados. 
46
Estabelecendo os Peerings
47
Roteiro
(Grupo X)
1) Levantar as sessões eBGP entre os AS’s 
65000  650X1 e 65X6 certificando-se do seu estabelecimento
650X1  65XXX
650X2  65XXX
2) Levantar o iBGP dentro do AS 65XXX fazendo uma full mesh
48
BGP Lab – Divisão de AS’s - Detalhe
Peer eBGPPeer iBGP
49
Algorítimo de decisão do BGP
O BGP faz balanceamento “automático” de links ?
O BGP utiliza o melhor caminho para chegar a um destino ?
AS 100
AS 200
AS 300
50
Como influenciar na escolha das rotas ?
AS 100
AS 200
AS 300
Imaginando que o AS 200 é detentor de um bloco /20 que está igualmente 
distribuido, qual seria uma política adequada para o balanceamento do download ?
E quanto ao upload ?
51
Networks
 Indica quais redes o BGP deve originar (anunciar) a partir desse roteador
Com Synchronization habilitada uma rede é anunciada somente se a 
correspondente rota esteja presente na FIB.
Desabilitando o Syncrhonization, a rede é anunciada independentemente de estar 
na tabela 
Desabiltar a Sincronização ajuda o BGP convergir mais rapidamente
52
Networks
 Indica quais redes o BGP deve originar (anunciar) a partir desse roteador
53
Algorítimo de decisão do BGP
54
Atributos do BGP para a seleção do melhor caminho 
Maior WEIGHT (default = 0)
 Maior LOCAL-PREF (default = 100)
 Menor AS-PATH 
 Path gerado localmente (aggregate, Rede BGP)
 Menor tipo de Origin (IGP, EGP, incomplete)
 Menor MED (default = 0) 
 Prefere eBGP sobre iBGP
 Prefere a rota gerada no Roteador com o menor Router ID ou menor 
ORIGINATOR_ID
 Prefere o menor cluster de route reflector
 Prefere o caminho que vem do vizinho com menor IP 
55
Roteiro
1) Escolher um dos participantes para anunciar uma rede 
Exemplo, o Roteador 13 anuncia a rede 13.13.13.0/24
2) Habilitando nesse anunciante a opção Synchronize, o que acontece ? 
3) Como estão as rotas em todos os outros roteadores ? Qual é a diferença 
entre os roteadores de borda dos AS’s e os internos que somente falam iBGP ?
4) Qual foi o roteador escolhido para receber os downloads relativos a rede 
anunciada ?
56
Problemas encontrados
1) Os Roteadores internos aos AS 65XXX tem uma rota válida para a rede 
13.13.13.0/24 ?
 Porque o problema ocorre ?
 Qual é a solução ?
2) A Partir de qualquer roteador de fora, por exemplo o R22, existe um caminho 
para a rede 16, que pode não ser o ideal 
 Porque foi escolhido o roteador em questão ?
 Como influenciar para que o outro tenha preferencia ?
57
Algorítimo de decisão do BGP
 O BGP utilitza o “melhor caminho: para chegar a um destino 
 Diferentes atributos do prefixo são utilizados para determinar o “melhor 
caminho”, como: 
 weight (peso)
 next-hop
 as-path
 local-pref
etc... 
58
Solução para o primeiro problema
1) Os Roteadores internos ao AS 65XXX não tem uma rota válida para a rede 
13.13.13.0/24 
 Porque o problema ocorre ?
 Qual é a solução ?
59
Atributo Next-Hop
Endereço IP que é utilizado para atingir um certo destino
 Para o eBGP o next hop é o IP do vizinho
 O next-hop anunciado pelo eBGP é carregado pelo iBGP, 
que não o modifica.
60
Next-Hop Self
 Força o BGP a utilizar o próprio roteador como next-hop
61
Segundo problema
2) A Partir de qualquer roteador de fora, por exemplo o R22, existe um caminho 
para a rede 16, que pode não ser o ideal 
 Porque foi escolhido o roteador em questão ?
 Como influenciar para que o outro tenha preferencia ?
62
Filtros de BGP
Os Filtros do BGP são a principal ferramenta para controlar e modificar as 
informações de roteamento.
 Os filtros são organizados em canais semelhantes ao Firewall
 Na configuração dos Peers são informados quais filtros utilizar.
63
Filtros de Rotas no Mikrotik
64
Filtros de Roteamento 
65
Exemplo - Filtrando Prefixos
66
Estudo dos principais atributos do BGP
 WEIGHT
 LOCAL-PREFERENCE 
 AS-PATH 
67
Estudo dos principais atributos do BGP
 WEIGHT
68
Weight
 De fato, weight não é um atributo verdadeiro pois não é propagado nas NLRI
 O “atributo” Weight é atribuido localmente ao roteador e não é propagado pelo 
BGP, constituindo uma política local desse Roteador
 Prefixos sem um weight atribuido tem o valor default 0 
 Rotas com maior weight são preferidas.
 O weight influi no tráfego de upstream.
Em R2 configura-se os pesos dos 
neighboors 
69
Weight
InternetISP de backup
Outro cliente
ISP primário
BGP
Cliente 
Multihomed
Link normal
Link Backup 
70
Implementação do Weight no Mikrotik
Cliente 
Multihomed
71
Weight
Aplicação do Filtro
72
Estudo dos principais atributos do BGP
 LOCAL PREFERENCE
AS 200AS 100
73
Seleção de rotas consistentes em um AS
É possível fazer a seleção de Rotas acima usando weight ?
AS 3001 mbps
10 mbps
100 mbps
Tráfego desejado
Tráfego default
AS 200AS 100
74
Seleção de rotas consistentes em um AS
Em um cenário como o acima é impossível a utilização de weights
Para isso o BGP RouterOS trabalha com o atributo Local Preference
AS 300
1 mbps
10 mbps
100 mbps
Tráfego desejado
512 kbps
75
Local Preference
 Indica qual caminho tem preferencia para deixar o AS.
 Caminhos com maior Local Preference, tem preferência (default = 100)
 Lembrando que o primeiro critério do BGP para a seleção de rotas é o Weight, este 
não deve ser usado, caso se use Local Preference. 
76
Local Preference
 Qualquer roteador BGP pode setar a Local Preference quando processando 
updates de rotas que estão chegando, quando fazendo a redistribuição ou quando 
mandando updates de rotas
 A Local Preference é anunciada dentro do AS entre os roteadores que tem sessão 
iBGP 
 A Local Preference é retirada das mensagens de saída de eBGP, exceto updates 
com peers em Confederations (visto mais adiante)
AS 200AS 100
77
Seleção de rotas consistentes em um AS
AS 300
1 mbps
10 mbps
100 mbps
Tráfego desejado
Roteador A
Local-pref = 150
78
Local Preference - Lab
 Utilizando Local Preference, faça com que as rotas para as redes 
de AS’s externos sejam modificadas.
79
Estudo dos principais atributos do BGP
 AS PATH
AS 200AS 100
80
Atributo AS-Path
Weight e Local Preference manipulam tráfego de upstream.
Como influenciar no tráfego de downstream ?
AS 300
1 mbps
10 mbps
100 mbps
Tráfego desejado
AS 200AS 100
Network 
10.0.0.0/8
81
Atributo AS-Path
O AS 300 irá enviar o seu tráfego diretamente pois através do AS 200 o 
caminho é 2 vezes “mais longo”
Como fazer com que o fluxo saia pelo link de 10 megas ? Pedindo para o 
administrador do AS 300 mudar seu weight ou local pref ????
AS 300
1 mbps
10 mbps
100 mbps
Tráfego desejado
10.0.0.0/8
AS Path 100
10.0.0.0/8
AS Path 100
10.0.0.0/8
AS Path 200, 100
82
Critérios de seleção do melhor caminho no BGP
 Maior WEIGHT (default = 0)
 Maior LOCAL-PREF (default = 100)
 Menor AS-PATH 
….
83
AS-Path
 Lista de números de AS’s que um update atravessou
84
AS-Path prepend
 Manipulações de AS-Path podem ser utilizadas para influenciar a 
decisão de roteamento de roteadores de outros AS’s 
AS 200AS 100
Network 
10.0.0.0/8
85
Atributo AS-Path
O AS 300 irá “prependar” no link menor n vezes mais seu próprio AS para 
que o AS 300 o enxergue com distancia de 3 saltos ao invés de apenas 1
AS 300
1 mbps
10 mbps
100 mbps
Tráfego desejado
10.0.0.0/8
AS Path 100
10.0.0.0/8
AS Path 100 100 100
10.0.0.0/8
AS Path 200, 100
86
AS-Path Prepend - Lab
Utilizando a técnica de AS Path Prepending, faça com que as rotas de AS’s 
vizinhos sejam invertidas
87
Solução para o segundo problema
2) A Partir de qualquer roteador de fora, por exemplo o R22, existe um caminho 
para a rede 16, que pode não ser o ideal 
 Porque foi escolhido o roteador em questão ?
 Como influenciar para que o outro tenha preferencia ?
Utilizando as técnicas vistas até agora (Weight, Local-Preference e AS-Path 
Prepending), como fazer para mudar esse caminho para o R21 ? 
88
AS-Path Prepend - Lab
 Utilizando AS-Path Prepend, faça com que a mesma utilize o R12
O retorno dos pacotes para a rede 
16.16.16.0/24 se faz por R11.
89
Considerações acerca do uso de AS-Path Prepending
No nosso exemplo, simplesmente adicionar mais um AS-Path é o suficiente 
para atingir o objetivo. No entanto se estivermos lidando com a situação de 
vários AS’s interligados (Internet) teremos que manipular adequadamente o 
número de Prepend’s. 
1) Cenário em que queremos fazer balanceamento de carga
)Comece com um pequeno AS-Path prepend, monitore o link e vá 
aumentando aos poucos até atingir o balanceamento desejado.
) Monitore constantemente o link e modifique o número de prepends 
sempre que necessário.
90
Considerações acerca do uso de AS-Path Prepending
2) Cenário em que queremos um link ativo e outro de Backup
 Usar vários AS-Path no link de backup para garantir que o primário seja o 
utilizado sempre
 AS-Paths longos consomem memória em todos roteadores da Internet
 Faça o prepend por tentativa e erro até achar um número ideal.
 Coloque ainda alguns mais por segurança (topologia na Internet pode 
mudar) 
91
Problemas no uso do AS-Path prepending
AS 200AS 100
Network 
10.0.0.0/8
AS 300
1 mbps
10 mbps
100 mbps
10.0.0.0/8
AS Path 100 100 100
Operadoras usualmente setam filtros para que seus clientes somente anunciem o 
seu próprio AS ou AS’s de quem este cliente faz transito. 
Para possibilitar que isso funcione e que ainda estes possam utilizar AS-Path 
prepending, pode-se fazer uso de expressões regulares nos filtros.
92
Filtros de AS-Path com regexp
Podem ser configurados para permitir updates apenas para algum AS 
ou a partir de algum AS 
Suporta expressões regulares:
“.” – qualquer caracter simples
“^” – começo do AS-Path
“$” – fim do AS-Path
“_” – encontra vírgula, espaço, começo e final do AS-Path
93
Filtros de AS-Path com regexp
Exemplo 1:
A expressão regular abaixo 
^([0-9])+)(_\1)*$
Encontrará qualquer AS-Path começando com qualquer número AS e 
continua com ou sem múltiplas do mesmo número AS (a variável “\1” 
repete o valor nos parenteses.
Assim a expressão acima irá permitir por exemplo:
123 123 123 … ou 100 100 100 100 100, etc mas não permitirá 123 100
94
Filtros de AS-Path com regexp
No nosso caso a expressão regular ^100(_100)*$ aplicada no roteador 
do AS 387 permitirá o setup abaixo, podendo ainda ter mais prepends 
do número 213
AS 200AS 100
Network 
10.0.0.0/8
AS 300
1 mbps
10 mbps
100 mbps
10.0.0.0/8
AS Path 100 100 100
95
.* - Todas as rotas BGP
^$ - Rotas que se originam no meu AS
^(100|200|300)$ - Rotas originadas no 100, 200 ou 300
^1002$ - Rotas que se originam no AS 1002 , adjacente ao meu AS
_1002$ - Rotas que terminam no AS 1002
^1002_ - Rotas originadas no AS 1002
_1002_ - Rotas que passaram no AS 1002
(...)+(...) – Uma ou várias ocorrências do caracter especificado antes ( + = ou )
Alguns outros exemplos de regexp
96
Laboratório de Regexp
 Fazer filtros nos Roteadores dos AS’s 65011, 65012, 65021, 6522, etc permitindo 
apenas receber respectivamente os AS’s 65111, 65222, etc 
 Os roteadores dos AS’s 65111 e 65222 deverão forçar o envio de AS prepend’s 
diferentes do seu e testar a eficácia do filtro.
97
Mais considerações sobre o AS-Path
AS 100
AS 200
AS 300
AS 400
Rede 10.100.0.0/24
10.100.0.0/24
AS Path 400 300 100
10.100.0.0/24
AS Path 100
10.100.0.0/24
AS Path 100 300
Ataque
O mecanismo de evitar loopings do BGP pode ser utilizado para bloquear ataques 
provenientes de determinado AS. (Filtros podem inviabilizar essa técnica)
98
Laboratório de AS-Path
 Simular um ataque de UDP R21 para a rede 13.13.13.0/24 e parar esse ataque 
com a técnica do slide anterior. 
OBS: Os filtros para receber somente um ou mais AS-Path do vizinho impedirão o 
uso dessa técnica.
99
Laboratórios adicionais de Filtros de BGP
Configurar regras de filtro para:
 Enviar somente o seu número AS e seu bloco de IP’s, evitando assim 
virar AS de transito (AS’s 65111, 65222, etc)
Descartar recebimento de seu próprio prefixo
 Descartar recebimento de blocos privados
 Descartar Bogons
100
Laboratórios adicionais de Filtros de BGP
0.0.0.0/8
5.0.0.0/8
10.0.0.0/8
23.0.0.0/8
36.0.0.0/7
39.0.0.0/8
42.0.0.0/8
100.0.0.0/8
192.0.0.0/24
192.0.2.0/24
192.168.0.0/16
198.18.0.0/15
198.51.100.0/24
203.0.113.0/24
224.0.0.0/3
102.0.0.0/7
104.0.0.0/7
106.0.0.0/8
127.0.0.0/8
169.254.0.0/16
172.16.0.0/12
179.0.0.0/8
185.0.0.0/8
Lista de Bogons agregada:
fonte http://www.team-cymru.org/Services/Bogons/bogon-bn-agg.txt
101
BGP - Lab
 Utilizando as técnicas aprendidas nos slides anteriores, 
faça um setup de forma que o tráfego de upload saia pelo 
link 1 e o tráfego de download pelo link 2. 
102Estudo de atributos do BGP
 Origin 
103
Critérios de seleção do melhor caminho no BGP
Maior WEIGHT (default = 0)
 Maior LOCAL-PREF (default = 100)
 Menor AS-PATH 
 Path gerado localmente (aggregate, Rede BGP)
 Menor tipo de Origin (IGP, EGP, incomplete)
…
104
Origin
 Informação de origin da rota:
 IGP – A rota foi originada internamente por um IGP
 EGP – A rota foi aprendida por um protocolo EGP
 Incomplete – A origem da rota é desconhecida, ocorre 
quando uma rota é redistribuida dentro do BGP.
Critério de preferencia:
igp > egp > incomplete (pior)
105
Estudo de atributos do BGP
MED (Multi Exit Discriminator)
(Ou Métrica) 
106
Critérios de seleção do melhor caminho no BGP
Maior WEIGHT (default = 0)
 Maior LOCAL-PREF (default = 100)
 Menor AS-PATH 
 Path gerado localmente (aggregate, Rede BGP)
 Menor tipo de Origin (IGP, EGP, incomplete)
 Menor MED (default = 0) 
…
AS 100
107
Seleção de rotas consistentes em um AS
O atributo MED é uma sinalização para o AS vizinho sobre o caminho preferencial 
de entrada do AS quando existem múltiplos caminhos de entrada. 
1 mbps
10 mbps
100 mbps
Tráfego desejado
Tráfego default
AS 200
108
Exemplo de MED
 R1, R2 e R3 anunciam a mesma rede para R4 com diferentes valores de MED. 
 R4 apenas compara os MED’s oriundos de R2 e R3 e o MED vindo de R1 é 
ignorado (outros atributos são utilizados para selecionar o melhor caminho)
109
MED
 MED pode ser usado para influenciar a seleção de caminhos para AS’s vizinhos 
 Um AS pode especificar seu ponto de entrada preferencial usando o MED nas 
mensagens de update das sessões eBGP 
 O MED NÃO é propagado para fora do AS que o recebeu 
 O valor default do MED é 0 
 O MED em outros sistemas é conhecido como “Métrica” do BGP 
 Um valor menor do MED é preferido.
 O MED pode ser considerado uma métrica “fraca” pois é um critério que vem 
depois de Weight, Local Preference e AS-Path. Caso o AS vizinho tenha setado 
esses valores, o MED não terá qualquer efeito. 
110
MED
 MED – Multi Exit Discriminator ou Métrica é uma Informação 
para o AS vizinho sobre a preferencia dentro do AS.
O MENOR MED é escolhido (default = 0)
 Informação trocada entre AS’s vizinhos e utilizado para 
tomada de decisão dentro daquele AS. Não é repassada para 
um terceiro AS.
 Ignorado se recebido a partir de diferentes AS’s 
111
Laboratório de MED
Em nossa topologia, qual seria a proposta de laboratório de MED ?
112
BGP COMMUNITIES 
113
BGP Communities
 BGP communities são meios de rotular rotas com o objetivo 
de assegurar filtros consistentes e políticas de seleção de 
rotas.
 Qualquer roteador BGP pode rotular os updates de rotas que 
entram e ou que saem quando fazendo a redistribuição.
 Qualquer roteador BGP pode filtrar rotas que entram e ou que 
saem ou selecionar rotas preferenciais, baseadas em 
communities. 
 Por padrão as communities, são retiradas dos updates de 
BGP que saem do roteador. 
114
BGP Communities
 BGP communities são meios de rotular rotas com o objetivo 
de assegurar filtros consistentes e políticas de seleção de 
rotas.
 Qualquer roteador BGP pode rotular os updates de rotas que 
entram e ou que saem quando fazendo a redistribuição.
 Qualquer roteador BGP pode filtrar rotas que entram e ou que 
saem ou selecionar rotas preferenciais, baseadas em 
communities. 
 Por padrão as communities, são retiradas dos updates de 
BGP que saem do roteador. 
115
Exemplo de Community
 Assumindo que não se quer que R2 propague as rotas 
aprendidas de R1 
116
BGP Communities (cont.)
Definindo suas próprias comunidades
 Um valor de community de 32 bits é dividido em 2 partes
 AS que definiu a community
 Significancia da community
Exemplo: 200:123
O AS 200, define uma community 123 que terá significancia local para ele. Exemplo, 
quando receber um anúncio com a community 200:123, irá setar a local-pref em 150. 
117
BGP Communities (exemplo)
Brasil Telecom
8167:90 Set Local Preference 90
8167:100 Set Local Preference 100
8167:110 Set Local Preference 110
* (default é Local Preference 200)
8167:3xy controle de anúncios
x: ação { 0 = não anuncia, 1,2,3 = insere x prepends)
y: peerings { 0=demais peerings, 1=internacionais, 2=Embratel,
3=Intelig, 4=Telemar, 5=Telefônica }
(exemplo: 312 = muda para 1 prepend o anúncio para a Embratel)
AS 200AS 100
118
Exemplo de uso de communities
O administrador do AS 200 utiliza a community definida por 100 e manda 
os updates de rotas com essa community
AS 300
1 mbps
10 mbps
100 mbps
Tráfego desejado
Tráfego default
119
Atributo BGP Communities
De acordo com a RFC 1977:
Uma community é um grupo de destinos que compartilham uma propriedade 
em comum.
Cada Administrador de AS pode definir à quais comunidades (communities) 
um destino pertence. Por padrão, todos destinos pertencem à comunidade 
Internet.
120
BGP Communities
 BGP communities são meios de rotular rotas com o objetivo 
de assegurar filtros consistentes e políticas de seleção de 
rotas.
 Qualquer roteador BGP pode rotular os updates de rotas que 
entram e ou que saem quando fazendo a redistribuição.
 Qualquer roteador BGP pode filtrar rotas que entram e ou que 
saem ou selecionar rotas preferenciais, baseadas em 
communities. 
 Por padrão as communities, são retiradas dos updates de 
BGP que saem do roteador. 
121
BGP Communities (cont.)
 O Atributo community é transitivo e opcional e seu valor é um número de 32 bits 
(0 a 4.294.967.200)
 Cada rede em uma tabela de roteamento BGP pode ser rotulada com um 
conjunto de communities.
 Por padrão são pré definidas as seguintes communities:
 no-advertise: Não anuncie rotas para qualquer Peer
 no-export: Não anuncie rotas para peers eBGP reais (só para eBGP peers 
em confederação.
 local-as: Não anuncie rotas para qualquer peer eBGP
 internet: Anuncie essa rota para a Internet community
 Roteadores que não suportam communities, as repassam sem modificação
122
Exemplo de Community
 Assumindo que não se quer que R2 propague as rotas 
aprendidas de R1 
123
BGP Communities (cont.)
Definindo suas próprias comunidades
 Um valor de community de 32 bits é dividido em 2 partes
 AS que definiu a community
 Significancia da community
Exemplo: 65111:123
O AS 65111, define uma community 123 que terá significancia local para ele. 
Exemplo, quando receber um anúncio com a community 65111:123, irá setar a local-
pref em 50. 
124
Laboratório de Community
Um AS define uma política para mudar sua Local Preference e o AS vizinho 
usa essa facilidade para inverter a forma como está recebendo o download.
125
BGP Route Reflector
 Re – anuncia as rotas iBGP sem mudar o next hop para 
a rota.
 Utilizado para evitar a necessidade de fazer full mesh no 
iBGP.
126
Configuração de Route Reflector
 RR é configurada habilitando client to client relfection
 / routing bg instance
set default client-to-client-reflection-yes
/routing bgp peer
add route-reflect=yes remote-peer= x.x.x.x
 Route-reflect deve ser habilitado apenas no roteador que 
faz a reflexão de rotas. 
127
BGP Confederation
 Uma confederação divide um AS em múltiplos AS’s 
 
Para o mundo externo uma confederação aparece como sendo um simples 
AS 
Cada AS deve ser um full mesh iBGP
 EBGP entre AS’s confederados trocam informações de roteamento, como 
no iBGP 
128
BGP Confederation
129
BGP - Multiprotocolos
 O BGP foi projetado para o IPV4
 O atributo Address Family foi criado para transportar novos tipos de 
endereços. 
 Mikrotik RouterOS suporta os seguintes tipos de address families 
 IPV6
 L2VPN
 VPN4
 Cisco Style L2VPN
130
BGP - Multiprotocolos
Laboratório:
Configurar endereços IPV6 nos distintos AS’s e verificar a conectividade
131
Algumas boas práticas no BGP
132
Empregar Endereços de Loopback
Eliminam a dependencia da interface física para efetuar a conexão TCP
Utilizada com maisfrequencia entre peers iBGP
133
Endereços de Loopback
No caso de eBGP será necessária a configuração de Multihop
A configuração exige rotas estáticas ou algum IGP que garanta a 
alcancabilidade dos neighboors..
134
Utilizar a autenticação MD5 entre os peers
135
Filtros básicos de BGP
Configurar regras de filtro para:
 Enviar somente o seu número AS e seu bloco de IP’s, evitando assim 
virar AS de transito
Descartar recebimento de seu próprio prefixo
 Descartar recebimento de blocos privados
 Descartar Bogons
136
Filtrando redes “invalidas” 
/routing filter
add action=discard chain=redes_invalidas prefix=0.0.0.0/8 prefix-length=8-32
add action=discard chain=redes_invalidas prefix=10.0.0.0/8 prefix-length=8-32
add action=discard chain=redes_invalidas prefix=127.0.0.0/8 prefix-length=8-32
add action=discard chain=redes_invalidas prefix=169.254.0.0/16 prefix-length=16-32
add action=discard chain=redes_invalidas prefix=172.16.0.0/12 prefix-length=12-32
add action=discard chain=redes_invalidas prefix=192.168.0.0/16 prefix-length=16-32
add action=discard chain=redes_invalidas prefix=224.0.0.0/3 prefix-length=3-32
137
Filtro automático de BOGONS
138
Filtro automático de Full Bogons
Marcando as rotas entrantes do peer com o Cymru como blackhole
139
Filtro automático de Full Bogons
Descartanto envio de rota para o Cymru
Descartando as restantes
MPLS
Multi Protocol Label 
Switching
140
Discussão sobre topologias usuais de redes 
Switching, Bridging, Redes IP, etc
141
ANEXO
Túneis IPIP, EOIP, PPTP, L2TP, SSTP, 
VLAN e MME
142
Tunelamento
A definição de Tunneling é a capacidade de criar túneis entre dois hosts, por 
onde trafegam dados.
O Mikrotik implementa diversos tipos de Tunelamento, podendo ser tanto 
servidor como cliente desse protocolos.
O Mikrotik ROS também possui suporte nativo aos serviços de tunelamento:
➔Túneis IPIP
➔Túneis EoIP
Entre os serviços comuns de tunelamento no Mikrotik ROS temos os baseados 
no PPP:
➔PPP (Point To Point Protocol)
➔PPPoE (Point to Point Protocol over Ethernet)
➔PPtP (Point to Point Tunneling Protocol
➔L2TP ( Layer 2 Tunneling Protocol )
➔SSTP (Secure Socket Tunneling Protocol)
143
MTU/MRU: unidades máximas de transmissão/recepção em bytes, refere-se ao 
tamanho do maior datagrama que uma camada de um protocolo de comunicação 
pode transmitir. O protocolo IP permite a fragmentação de pacotes, possibilitando 
que um datagrama seja dividido em pedaços. Em serviços PPP que precisam 
encapsular os pacotes, deve se definir valores menores para evitar a 
fragmentação.
Keepalive Timeout: define o período de tempo em segundos após o qual o 
roteador começa enviar pacotes de keepalive a cada segundo. Se nenhuma 
resposta de keepalive é recebida pelo período de tempo de 2 vezes o keep-alive-
timeout o cliente é considerado desconectado.
Authentication:
➔ Pap: usuário/senha passa em texto plano, sem criptografia
➔ Chap: usuário/senha com criptografia
➔ mschap1: versão chap da Microsoft conf. RFC 2433
➔ mschap2: versão chap da Microsoft conf. RFC 2759
Definições comuns para os serviços PPP
144
PMTUD: Se durante uma comunicação alguma estação enviar pacotes IP maiores 
do que a rede pode suportar, ou seja, maiores que o menor MTU (Maximum 
Transmission Unit) do caminho, então será necessário que haja algum mecanismo 
para avisar que esta estação deverá diminuir o tamanho dos pacotes para que a 
comunicação ocorra com sucesso. O processo interativo de envio de pacotes em 
determinados tamanhos, a resposta dos roteadores intermediários (possivelmente 
com pacotes do tipo ICMP Packet Tôo Big) e a adequação do tamanho dos pacotes 
posteriores é chamada Path MTU Discovery ou PMTUD. Normalmente esta 
funcionalidade está presente em todos os roteadores comerciais e sistemas Unix 
Like, assim como no Mikrotik ROS.
MRRU: tamanho máximo do pacote, em bytes, que poderá ser recebido no link. Se 
um pacote ultrapassa o valor definido ele será divido em pacotes menores, 
permitindo o melhor dimensionamento do túnel. Especificar MRRU significa permitir 
MP (Multilink PPP) sobre um túnel simples. Essa configuração é útil para o 
protocolo PMTU Discovery superar falhas. O MP deve ser ativado em ambos os 
lados (cliente e servidor).
Definições comuns para os serviços PPP
145
Change MSS (Máximum Segment Size Field, ou seja o tamanho máximo do 
segmento de dados.).
Quando uma conexão TCP é inicializada, cada lado dos agentes/clientes do TCP 
pode ter o seu próprio tamanho de fragmentação do seu pacote (MSS - Maximum 
Segment Size). O TCP é responsável por negociar esses fragmentos, enquanto o 
MSS determina o tamanho máximo para que ele seja aceito. Por padrão, o MSS é 
escolhido como o MTU a partir de uma interface de saída menos usual do TCP e 
cabeçalhos IP (40 bytes), que resulta num MSS de 1460 bytes para a interface de 
Ethernet.
Um pacote com MSS que ultrapassa o MSS dos roteadores por onde um túnel está 
estabelecido deve ser fragmentado antes de enviá-lo. Em alguns casos o PMTUD 
está quebrado ou os roteadores não conseguem trocar as informações de maneira 
eficiente e causam uma série de problemas com transferência HTTP, FTP, E-MAIL 
além de mensageiros instantâneos.
Neste caso o Mikrotik ROS proporciona ferramentas onde é possível intervir e 
configurar uma diminuição do MSS dos próximos pacotes através do túnel visando 
resolver o problema.
Definições comuns para os serviços PPP
146
IP Pool
 
Para criação de faixas de IPs para operação em conjunto com os 
profiles do PPP (ppp, pppoe, pptp, l2tp, etc).
Definições comuns para os serviços PPP
147
Local Address: Endereço IP ou pool de endereços 
IP a ser utilizado no servidor.
Remote Address: Pool de endereços IP a ser 
utilizado pelos clientes.
Bridge: bridge para associar ao perfil.
Incoming/Outgoing Filter: nome do canal do 
Firewall para pacotes entrando/saindo.
 
Address List: lista de endereços IPs para associar 
ao perfil.
DNS Server: configuração dos servidores DNS a 
atribuir nos clientes. Pode se configurar mais de 
um endereço IP.
Use Compression/Encryption/Change TCPMSS: 
caso estejam default associam ao valor que está 
configurado no perfil DEFAULT-PROFILE.
Profiles
Definições comuns para os serviços PPP
148
Session Timeout: é a duração máxima de uma 
sessão pppoe.
Idle Timeout: é o período de ociosidade na 
transmissão de uma sessão. Se não houver tráfego 
IP dentro do período configurado a sessão é 
terminada.
Rate Limit: limitação da velocidade na forma rx-
rate/tx-rate; rx é o upload do cliente
OBS: Pode ser usada a sintaxe:
rx-rate/tx-rate rx-burst-rate/tx-burst-rate rx-burst-
threshold/tx-burst-threshold rx-burst-time/tx-burst-
time priority rx-rate-min/tx-rate-min
Only One: permite apenas uma sessão para o 
mesmo usuário.
Profiles
Definições comuns para os serviços PPP
149
Service: Especifica o serviço disponível para esse 
cliente em particular.
Caller ID: MAC address do cliente
Local Address/Remote Address: endereço IP 
local(servidor) e remote(cliente) que poderão ser 
atribuídos a um cliente em particular.
Limit Bytes In/Out: Quantidades de Bytes que o 
cliente pode trafegar por sessão PPPoE
Routes: Rotas que são criadas no lado servidor 
para esse cliente específico.Várias rotas podem 
ser adicionadas separadas por vírgula.
Definições comuns para os serviços PPP
User Database (secrets)
150
PPPoE (point-to-point protocol over Ethernet) é uma adaptação do PPP para 
funcionar em redes Ethernet.
 
➔ Muito usado para autenticação de clientes com Base em Login e senha. O PPPoE 
estabelece a sessão e realiza a autenticação com o provedor de acesso a Internet.
➔ O cliente não tem IP configurado, o qual é atribuído pelo PPPoE server 
(concentrador), normalmente operando em conjunto com um servidor Radius. No 
Mikrotik ROS, não é obrigatório o uso de servidor Radius, pois o mesmo permite a 
criação e gerenciamento de usuários e senhas em uma tabela local (/ppp secrets).
➔ PPPoE, por padrão,não é criptografado (pode-se lançar mão do método MPPE, 
desde que o cliente suporte este método)
➔ O cliente “descobre” o servidor através do protocolo “PPPoE discover”, que tem o 
nome do serviço a ser utilizado.
➔ Precisa estar no mesmo barramento físico ou os dispositivos passarem para frente 
as requisições PPPoE (pppoe relay).
➔ No Mikrotik ROS o valor padrão do Keep Alive Timeout é 10, e funcionará bem na 
maioria dos casos. Se configurarmos para 0, o servidor não desconectará os 
clientes até que os mesmos solicitem ou o servidor for reiniciado.
PPPoE – Servidor ou Cliente
151
PPTP e L2TP
Point-to-Point Tunneling Protocol e Layer 2 Tunneling Protocol
➔L2TP – Layer 2 Tunnel Protocol – Protocolo de tunelamento de camada 2 é 
um protocolo de tunelamento seguro para transportar tráfego IP utilizando 
PPP. O protocolo L2TP trabalha no layer 2 de forma criptografada ou não e 
permite enlaces entre dispositivos de diferentes redes unidos por diferentes 
protocolos.
➔O tráfego L2TP utiliza protocolo UDP tanto para controle como para pacotes 
de dados. A porta UDP 1701 é utilizada para o estabelecimento do link e o 
tráfego em si utiliza qualquer porta UDP disponível, o que significa que L2TP 
pode ser usado com a maioria dos Firewalls e Routers, funcionando também 
através de NAT.
➔L2TP e PPTP possuem as mesmas funcionalidades.
152
Configure um faixa de endereços IP, em IP POOL, um perfil para o PPTP e um 
usuário em PPP Secrets, conforme as imagens.
Configuração do Servidor PPtP e L2TP
153
Configure os servidores PPTP e L2TP
Atente-se para o perfil a utilizar
Configure nos hosts locais 
um cliente PPTP e realize a 
conexão com um servidor 
de outra rede diferente da 
rede conectada.
Ex.: hosts da rede 
192.168.100.0/24 
conectarem-se a servidores 
da rede 192.168.200.0/24 e 
vice-versa.
Configuração do Servidor PPtP e L2TP
154
As configurações para o cliente PPTP ou L2TP 
são bastante simples, conforme observamos 
nas imagens.
Configuração do Cliente PPtP e L2TP
155
SSTP – Secure Socket Tunneling Protocol é um mecanismo para 
transportar frames de camada 2 em HTTP sobre SSL (HTTPS).
O SSTP foi desenvolvido pela Microsoft e as especificações completas 
podem ser encontradas em:
 
http://msdn.microsoft.com/en-su/library/cc247338(PROT.10).aspx
Atualmente existem clientes SSTP somente para os sistemas operacionais
Windows Vista, Windows 7 e RouterOS.
SSTP (Secure Socket Tunneling Protocol)
156
Cenário de uso do SSTP
Acesso remoto a Intranet
157
Cenário de uso do SSTP
Acesso remoto Site to Site
158
Estabelecimento do SSTP
1) Uma conexão TCP é estabelecida do cliente para o servidor (porta 443);
2) O SSL valida o certificado do servidor. Se o certificado é válido, uma 
conexão é estabelecida, caso contrário a conexão é abortada.
3) O cliente envia pacotes de controle SSTP dentro da sessão HTTPS.
4) Ocorre uma negociação PPP sobre SSTP. O cliente autentica no servidor 
e um IP é associado à interface SSTP.
5) O túnel SSTP é nesse momento estabelecido e o encapsulamento dos 
pacotes pode ser iniciado.
159
Sendo dois roteadores Mikrotik:
➔ O túnel SSTP pode ser estabelecido sem o uso de Certificados Digitais.
➔ Qualquer método de autenticação disponível pode ser utilizado.
➔Não sendo os dois lados Mikrotik
➔Devem ser utilizados certificados cliente/servidor
➔ O método de autenticação deve ser o mschap
Nota: O SSTP no mkrotik não requer certificados para operar (desde a 
versão v5.0beta2). Essa funcionalidade somente irá operar entre dois 
roteadores MikroTik, e é incompatível com as especificações standard do 
SSTP.
Estabelecimento do SSTP
160
É possível autenticar 2 Mikrotik’s com SSTP sem Certificados e nesse caso:
➔Será utilizado a autenticação anônima Diffie Helmann (DH) sem certificados 
(mesmo método utilizado em autenticação EAP sem certificados)
➔Esse método é inseguro e permite que se faça o ataque do “Homem do meio”
➔Método incompatível com clientes Windows
Uso de Certificados
Também é possível fazer conexões seguras SSTP adicionando certificados no 
lado do cliente. Nesse caso, os requisitos são:
➔Certificados dos dois lados – cliente e servidor
➔Opções de verificar certificado também habilitadas nos dois lados.
Este cenário também não é possível com clientes Windows, pois não há como 
adicionar Certificado cliente no Windows.
161
Quando a negociação do SSL fallha, podem ser geradas as seguintes mensagens 
de erro:
certificate is not yet valid - O Certificado foi emitido para uma data posterior à 
presente.
certificate has expired - O certificado já expirou (a máxima de validade é anterior 
à presente)
invalid certificate purpose - O tipo de certificado não é apropriado para essa 
aplicação.
self signed certificate in chain - Embora certificados auto assinados possam ser 
utilizados, o Certificado root não foi encontrado localmente.
unable to get issuer certificate locally - O certificado da CA não foi importado 
localmente.
Uso de Certificados
162
Configuração do SSTP
163
Configuração do SSTP
164
Configuração do SSTP
165
SSTP Server (Interface)
Interfaces estáticas são 
configuradas manualmente 
quando há a necessidade de 
referenciar uma interface em 
particular (em regras de 
firewall por exemplo).
Interfaces dinâmicas são 
adicionadas automaticamente 
quando um usuário se 
conecta e seu nome não está 
usando uma entrada estática 
ou não tenha outra entrada 
ativa para o mesmo usuário 
(não podem haver 2 túneis 
separados para o mesmo 
nome)
166
O Mikrotik RouterOS suporta o BCP 
(Bridge Control Protocol) para 
interfaces PPP, PPTP, L2TP, PPPoE e 
SSTP.
O BCP permite uma bridge para os 
pacotes que trafegam através de um 
túnel PPP. Após estabelecido o BCP, 
ele é independente do túnel PPP, não 
fica relacionado a qualquer endereço IP 
da interface. 
Requisitos:
O BCP necessita de suporte em ambos os lados (servidor e cliente) para 
funcionar adequadamente.
BCP bridging (PPP tunnel bridging)
167
Adicione uma bridge e 
configure conforme a 
imagem.
Atente para a 
configuração do RSTP.
BCP bridging (PPP tunnel bridging)
168
Adicione a interface 
da rede local, 
utilizando a opção 
ports da bridge
BCP bridging (PPP tunnel bridging)
169
Acesse a bridge 
novamente e 
certifique-se que o 
MAC-ADDRESS é o 
mesmo da interface 
que foi adicionada em 
ports. Se não for, 
altere.
A razão para esta 
configuração é 
simples:
quando se utiliza o 
BCP a porta da bridge 
PPP não possui 
endereço MAC.
BCP bridging (PPP tunnel bridging)
170
Altere o endereço IP 
da interface local 
para a bridge.
Verifique se o 
endereço IP da 
interface pública 
está correto.
BCP bridging (PPP tunnel bridging)
171
Configure o perfil 
PPP adicionando 
a bridge ao 
mesmo.
BCP bridging (PPP tunnel bridging)
172
Configure, no 
secrets, o 
usuário com o 
perfil correto
BCP bridging (PPP tunnel bridging)
173
Configure o 
PPTP server 
com o MRRU 
em 1600 e o 
perfil correto
BCP bridging (PPP tunnel bridging)
174
No lado cliente as 
configurações são as mesmas, 
necessitando apenas criar um 
PPTP client, conforme a 
imagem.
BCP bridging (PPP tunnel bridging)
175
IPIP é um protocolo que encapsula pacotes IP sobre o próprio protocolo IP 
baseado na RFC 2003. É um protocolo simples que pode ser usado para ligar 
duas Intranets através da Internet usando 2 roteadores.
A Interface do túnel IPIP aparece na lista de interfaces como se fosse uma 
interface real.
Vários roteadores comerciais, incluindo Cisco e roteadores baseados em Linux 
suportam esse protocolo.
Um exemplo prático de uso de IPIP seria a necessidade de monitorar hosts 
através de um NAT, onde o túnel IPIP colocaria a rede privada disponível para 
o host que realiza o monitoramento, sem necessidade de criação de usuário e 
senha como nas VPNs.
Túneis IPIP
176
Exemplo:
Supondo que temos de unir as redes que estão por trás dos 
roteadores 200.200.200.1 e 200.200.100.1. Para tanto basta 
que criemos as interfacesIPIP em ambos, da seguinte 
forma: 
Túneis IPIP
177
Túneis IPIP
Em seguida atribui-se endereço IP às interfaces criadas 
(de preferência ponto a ponto )
Pronto, está criado o túnel IPIP e agora as redes fazem parte do mesmo 
domínio de broadcast.
178
Túneis EOIP
EoIP ( Ethernet over IP ) é um protocolo proprietário Mikrotik 
para encapsulamento de todo tipo de tráfego sobre o 
protocolo IP. Quando habilitada a função de bridge dos 
roteadores que estão interligados através de um túnel EoIP, 
todo o tráfego é passado de um lado para o outro como se 
houvesse um cabo de rede interligando os pontos, mesmo 
roteando pela Internet e por vários protocolos.EoIP possibilita:
➔Interligação em bridge de LAN’s remotas através da Internet
➔Interligação em bridge de LAN’s através de túneis criptografados
➔Possibilidade de “bridgear” LAN’s sobre redes Ad Hoc 802.11
Características:
➔A interface criada pelo túnel EoIP suporta todas as funcionalidades de uma interface 
Ethernet. Endereços IP e outros túneis podem ser configurados na interface EoIP.
➔O protocolo EoIP encapsula frames Ethernet através do protocolo GRE.
➔O número máximo de túneis suportados no Mikrotik ROS são 65536.
179
Túneis EOIP
Criando um túnel EoIP entre as redes que estão 
por trás dos roteadores 200.200.200.1 e 
200.200.100.1.
OBS:
➔Os MAC’s devem ser diferentes e estar entre o 
range 00-00-5E-80-00-00 to 00-00-5E-FF-FF-
FF, pois são endereços reservados para essas 
aplicações.
➔O MTU deve ser deixado em 1500 para evitar 
fragmentações.
➔O túnel ID deve ser o mesmo em ambos os 
lados. 180
Túneis EOIP
➔Adicione a interface EoIP à bridge, 
juntamente com a interface da rede que 
fará parte do mesmo domínio de broadcast 
(normalmente uma interface da rede 
privada – LAN).
181
➔VLANs permitem múltiplas LANs virtuais em uma única interface 
ethernet ou wireless, separando/isolando de forma eficiente as 
mesmas.
➔São suportadas até 4.095 interfaces VLAN com ID exclusivo para 
cada interface física.
➔Também é possível configurar prioridade utilizando VLAN.
➔Vários roteadores, incluindo Cisco e roteadores baseados em 
Linux, e vários swicthes layer 2 suportam VLAN.
➔Um exemplo básico são múltiplas redes isoladas configuradas na 
mesma rede física.
➔VLAN é uma maneira de agrupar um conjunto de portas de um 
switch, onde as mesmas formam uma rede lógica, separada de 
qualquer outro grupo.
➔Também podemos analisar com uma quebra do switch em várias 
partes independentes. Dentro de um único switch esta é uma 
configuração local simples. Quando a VLAN estende-se por mais 
de um switch, as conexões entre os mesmos, devem se tornar 
troncos, onde os pacotes serão marcados para indicar a VLAN que 
eles pertencem.
VLAN 802.1q
182
VLAN 802.1q
➔O Mikrotik ROS pode realizar marcas (tags) nos pacotes que 
atravessam a VLAN, assim como ler as marcas realizadas por outros 
dispositivos/sistemas.
➔As VLANs operam no Layer2 (OSI) e portanto podem ser utilizados 
como qualquer interface outra interface de rede.
➔VLANs também podem ser configurados em interfaces sem fio.
Nota: Como VLAN não é um protocolo de túnel (ele não possui 
campos para o transporte de endereços MAC de origem e destino), 
esta limitação se aplica a bridge sobre VLAN em interfaces sem fio. 
Em outras palavras, enquanto os clientes wireless podem participar de 
VLANs configuradas em uma interface wireless, não é possível 
configurar uma VLAN em uma interface wireless em modo station 
configurado em bridge com outra interface. 183
Originalmente o modo 802.1q permite apenas um cabeçalho VLAN, ao 
contrário Q-in-Q, permite dois ou mais cabeçalhos VLAN.
No Mikrotik RouterOS, o Q-in-Q pode ser configurado adicionando 
uma interface VLAN sobre outra interface VLAN. 
Exemplo:
Se qualquer pacote é enviado pela “vlan2”, duas marcas (tags) serão 
adicionadas ao cabeçalho ethernet - "11" and "12".
VLAN 802.1q
/interface vlan
add name=vlan1 vlan-id=11 interface=ether1
add name=vlan2 vlan-id=12 interface=vlan1
184
VLAN 802.1q
MTU
O MTU padrão para a VLAN deve ser configurado para 1500, da mesma forma 
que em interfaces ethernet. Mas esta configuração pode não funcionar com 
algumas adaptadoras Ethernet que não suportam a transmissão/recepção de 
pacotes ethernet com o cabeçalho VLAN adicionado (1500 bytes de dados + 4 
bytes do cabeçalho VLAN + 14 bytes do cabeçalho Ethernet). Neste caso a valor 
do MTU pode ser configurado em 1496, mas isso provorcará uma fragmentação 
maior dos pacotes, caso sejam maiores que este valor. Também devemos 
lembrar que a MTU configurada em 1496 bytes pode causar problemas se o 
protocolo PMTU Discover não estiver funcionando corretamente entre a origem e 
destino.
185
VLAN 802.1q
Digamos que temos um ou mais roteadores Mikrotik RouterOS 
conectados a um hub. Iremos utilizar a interface ether1 
conectada à rede física e onde criaremos a VLAN (isto não é 
obrigatório, mas apenas para simplificar o exercício). 
Para conectarmos os hosts através da VLAN, eles devem estar 
conectados fisicamente e ter um endereço IP atribuido de forma 
que possuam conectividade IP entre os mesmos. Em seguida, 
em cada um deles, uma interface VLAN deve ser criada.
[admin@MikroTik] interface vlan> add name=test vlan-id=32 interface=ether1
[admin@MikroTik] interface vlan> print
Flags: X - disabled, R - running
# NAME MTU ARP VLAN-ID INTERFACE
186
VLAN 802.1q
Se todas as configurações foram executadas e os dispositivos 
estão conectados adequadamente as VLANs estarão funcionando. 
Agora devemos configurar o endereço o IP em cada host.
[admin@MikroTik] ip address> add address=10.10.10.1/24 interface=test 
[admin@MikroTik] ip address> print
Flags: X - disabled, I - invalid, D – dynamic
# ADDRESS NETWORK BROADCAST INTERFACE
0 10.0.0.204/24 10.0.0.0 10.0.0.255 ether1
1 10.20.0.1/24 10.20.0.0 10.20.0.255 pc1
2 10.10.10.1/24 10.10.10.0 10.10.10.255 test
Host 1
[admin@MikroTik] ip address> add address=10.10.10.2/24 interface=test 
[admin@MikroTik] ip address> print
Flags: X - disabled, I - invalid, D – dynamic
# ADDRESS NETWORK BROADCAST INTERFACE
0 10.0.0.201/24 10.0.0.0 10.0.0.255 ether1
1 10.10.10.2/24 10.10.10.0 10.10.10.255 test
Host 2
187
Dúvidas
?
188
Implementações de Mesh em 
camada 3
MME
189
MME - Mesh Made Easy
MME (Mesh Made Easy) é um protocolo de roteamento Mikrotik, inspirado no 
projeto B.A.T.M.A.N (Better Approach To Mobile Ad Hoc Networking) - 
https://www.open-mesh.net
O protocolo MME trabalha propagando periodicamente mensagens de 
originadores.
Estas mensagens contém o endereço IP do originador e opcionalmente uma 
lista de anúncios de rotas.
190
MME - Propagação de rotas
Assim como em protocolos tradicionais como o RIP e OSPF os nós com MME 
habilitado “aprende as rotas” para as redes dos nós que as publicaram.
191
Cenário MME
Rota “aprendida por MME”
10.10.XY.0/24 gw 192.168.100.XY
192
Exemplo de implementação
193
MME - Como são definidos os gateways
➔ Diferentemente de outros protocolos tradicionais 
como o RIP e OSPF em uma configuração de 
MME normalmente não se propaga a rota default 
(até é possível propagá-la, porém não é 
recomendável)
➔ Para fazer a rota dos pacotes para um nó que 
não faça parte da nuvem MME o administrador 
configura os nós que “pretendem” ser roteadores 
e define a banda que este pode fornecer.
➔ O nó não gateway deve selecionar o critério de 
escolha do gateway.
194
Estabelecimento do Gateway
➔O protocolo MME escolhe o melhor gateway para um determinado nó, 
criando um túnel IPIP entre o nó e o gateway.
➔É adicionada uma rota default apontando para a interface ipip
195
Cenário MME
Túnel IPIP estabelecido entre
192.168.100.XY e 172.16.255.1
196
Dúvidas
?
197
Laboratório Final
Abram um new terminal
/system reset configuration
198
Obrigado!!
 Edson Veloso Sergio Souza Wardner Maia
edson@mikrotikbrasil.com.br sergio@mikrotikbrasil.com.br maia@mikrotikbrasil.com.br
199
	Slide 1
	Slide 2
	Slide 3Slide 4
	Slide 5
	Slide 6
	Slide 7
	Slide 8
	Slide 9
	Slide 10
	Slide 11
	Slide 12
	Slide 13
	Slide 14
	Slide 15
	Slide 16
	Slide 17
	Slide 18
	Slide 19
	Slide 20
	Slide 21
	Slide 22
	Slide 23
	Slide 24
	Slide 25
	Slide 26
	Slide 27
	Slide 28
	Slide 29
	Slide 30
	Slide 31
	Slide 32
	Slide 33
	Slide 34
	Slide 35
	Slide 36
	Slide 37
	Slide 38
	Slide 39
	Slide 40
	Slide 41
	Slide 42
	Slide 43
	Slide 44
	Slide 45
	Slide 46
	Slide 47
	Slide 48
	Slide 49
	Slide 50
	Slide 51
	Slide 52
	Slide 53
	Slide 54
	Slide 55
	Slide 56
	Slide 57
	Slide 58
	Slide 59
	Slide 60
	Slide 61
	Slide 62
	Slide 63
	Slide 64
	Slide 65
	Slide 66
	Slide 67
	Slide 68
	Slide 69
	Slide 70
	Slide 71
	Slide 72
	Slide 73
	Slide 74
	Slide 75
	Slide 76
	Slide 77
	Slide 78
	Slide 79
	Slide 80
	Slide 81
	Slide 82
	Slide 83
	Slide 84
	Slide 85
	Slide 86
	Slide 87
	Slide 88
	Slide 89
	Slide 90
	Slide 91
	Slide 92
	Slide 93
	Slide 94
	Slide 95
	Slide 96
	Slide 97
	Slide 98
	Slide 99
	Slide 100
	Slide 101
	Slide 102
	Slide 103
	Slide 104
	Slide 105
	Slide 106
	Slide 107
	Slide 108
	Slide 109
	Slide 110
	Slide 111
	Slide 112
	Slide 113
	Slide 114
	Slide 115
	Slide 116
	Slide 117
	Slide 118
	Slide 119
	Slide 120
	Slide 121
	Slide 122
	Slide 123
	Slide 124
	Slide 125
	Slide 126
	Slide 127
	Slide 128
	Slide 129
	Slide 130
	Slide 131
	Slide 132
	Slide 133
	Slide 134
	Slide 135
	Slide 136
	Slide 137
	Slide 138
	Slide 139
	Slide 140
	Slide 141
	Slide 142
	Tunelamento
	Definições comuns para os serviços PPP
	Definições comuns para os serviços PPP
	Definições comuns para os serviços PPP
	Definições comuns para os serviços PPP
	Definições comuns para os serviços PPP
	Definições comuns para os serviços PPP
	Definições comuns para os serviços PPP
	Slide 151
	Slide 152
	Slide 153
	Slide 154
	Slide 155
	Slide 156
	Cenário de uso do SSTP
	Cenário de uso do SSTP
	Estabelecimento do SSTP
	Estabelecimento do SSTP
	Slide 161
	Slide 162
	Configuração do SSTP
	Configuração do SSTP
	Configuração do SSTP
	SSTP Server (Interface)
	BCP bridging (PPP tunnel bridging)
	BCP bridging (PPP tunnel bridging)
	BCP bridging (PPP tunnel bridging)
	BCP bridging (PPP tunnel bridging)
	BCP bridging (PPP tunnel bridging)
	BCP bridging (PPP tunnel bridging)
	BCP bridging (PPP tunnel bridging)
	BCP bridging (PPP tunnel bridging)
	BCP bridging (PPP tunnel bridging)
	Slide 176
	Slide 177
	Slide 178
	Slide 179
	Slide 180
	Slide 181
	Slide 182
	Slide 183
	Slide 184
	Slide 185
	Slide 186
	Slide 187
	Slide 188
	Implementações de Mesh em camada 3 MME
	MME - Mesh Made Easy
	MME - Propagação de rotas
	Slide 192
	Exemplo de implementação
	MME - Como são definidos os gateways
	Estabelecimento do Gateway
	Slide 196
	Slide 197
	Slide 198
	Slide 199