UTILIZANDO FILTROS BGP COM MIKROTIK / CISCO

Objetivo: Proporcionar um melhor entendimento com relao ao funcionamento da Internet, trazendo um ponto de vista pouco explorado no roteamento entre sistemas autnomos, compartilhar experincias e solues de problemas comuns utilizando BGP
*Para baixar o PDF atualizado e acompanhar correes e novas verses, acesse o link da apresentao online e cadastre seu email:

https://docs.google.com/presentation/d/1MQMNg72ELyBNn3dcmirW_f_HUVURyF0N0QbQotnUqkU/edit

Palestrante:
Rinaldo Vaz Formado em redes de computador Trabalha na rea de redes desde 2001 Usurio avanado do RouterOS desde 2007 Usurio avanado do Cisco IOS desde 2008 Analista de Redes da Associao Nacional para Incluso Digital (ANID) desde 2010 Chefe de Operaes do NOC Responsvel tcnico pelo AS 28135 Certificado

Somos uma associao sem fins lucrativos, cujo objetivo promover incluso digital no Brasil, colaborando principamente com o acesso ao link dedicado para pequenos provedores

*Proponho aqui uma troca de experiencia sobre problemas enfrentados nessa rede, e discutir as solues empregadas

Algumas boas prticas com BGP:

1- AS's de transito
2- AS's de trnsito no PTT 3- Estudo de Caso

1-Boas prticas para um AS de transito

1.1 - Evitando receber dos clientes anncios indesejados

Quando precisamos propagar blocos de clientes, interessante no receber nada que no seja combinado, mas ao mesmo tempo permitir ao cliente uma certa "liberdade" para decidir quais sub-blocos anunciar para voc:

Exemlo para os prximos slides:

Cliente:

AS 100 Bloco CIDR 100.0.0.0/20

1-Boas prticas para um AS de transito

1.1 - Evitando receber dos clientes anncios indesejados

ROUTEROS CLI

/routing bgp peer> add default-originate=if-installed in-filter=as100-in out-filter=as100-out name=cliente_as100 nexthop-choice=force-self remoteaddress=192.168.0.2 remote-as=100 routing filter> add action=accept chain=as100-in prefix=100.0.0.0/20 prefixlength=20-24 set-bgp-local-pref=120 add action=discard chain=as100-in #traduzinho: quero receber a rede 100.0.0.0/20 ou qualquer sub-bloco /21, /22, /23 ou /24
*Evitamos com esse filtro que cheguem em nossa tabela anncios errados que o cliente venha a fazer, por exemplo, se ele desabilita seu filtro de sada, evitamos receber dele a tabelafull (360000 rotas em media), o impacto disso seria todo o meu upload subir pelo cliente, j que as rotas recebidas por ele recebem uma prioriodade maior do que as rotas recebidas pelas minhas operadoras.

1-Boas prticas para um AS de transito

1.1 - Evitando receber dos clientes anncios indesejados

CISCO CLI

R1(config-router)# neighbor 192.168.0.2 remote-as 100 neighbor 192.168.0.2 description Cliente AS 100 neighbor 192.168.0.2 next-hop-self neighbor 192.168.0.2 soft-reconfiguration inbound neighbor 192.168.0.2 route-map as100-in in neighbor 192.168.0.2 route-map as100-out out R1(config)# ip prefix-list BLOCOS-AS-100 seq 1 permit 10.0.0.0/20 le 24 R1(config)# route-map as100-in permit 10 match ip address prefix-list BLOCOS-AS-100 set local-preference 120

#traduzinho: quero receber a rede 100.0.0.0/20 ou qualquer sub-bloco /21, /22, /23 ou /24
*Evitamos com esse filtro que cheguem em nossa tabela anncios errados que o cliente venha a fazer, por exemplo, se ele desabilita seu filtro de sada, evitamos receber dele a tabelafull (360000 rotas em media), o impacto disso seria todo o meu upload subir pelo cliente, j que as rotas recebidas por ele recebem uma prioriodade maior do que as rotas recebidas pelas minhas operadoras.

1-Boas prticas para um AS de transito

1.2 - Evitando propagar anncios do seu cliente, mas que foram feitos para outra operadora.

Um filtro similar ao do slide anterior "as100-in" no "operadora-out" vai funcionar mas deixa espao para um problema: *Meu cliente anuncia 100.0.0.0/21 para mim e 100.0.8.0/21 para sua outra operadora(as400), e logo minha RIB teria uma rota apontando para meu cliente (100.0.0.0/21) e outra para minha operadora (100.0.8.0/21), e meu router acabaria fazendo os dois anncios para minha vizinhana cionforme slides a seguir...

1-Boas prticas para um AS de transito

1.2 - Evitando propagar anncios do seu cliente, mas que foram feitos para outra operadora.

[admin@R1] /ip route print detail where dst-address in 100.0.0.0/20

0 ADb dst-address=100.0.0.0/21 gateway=192.168.0.2 gateway-status=192.168.0.2 reachable ether2-cliente distance=20 scope=40 target-scope=10 bgp-as-path="100" bgp-med=0 bgp-origin=igp receivedfrom=cliente_as100
1 ADb dst-address=100.0.8.0/21 gateway=200.200.200.1 gatewaystatus=200.200.200.1 reachable ether1-operadora_as300 distance=20 scope=40 target-scope=10 bgp-as-path="300,400,100" bgporigin=igp received-from=peer_operadora_as300 Observem no "bgp-as-patch" que a rota #1 no foi recebida do meu cliente, mas sim da minha operadora A, e por estar sendo uma rota vlida em minha tabela, vai ser propagado para todos os meus peers

1-Boas prticas para um AS de transito

1.2 - Evitando propagar anncios do seu cliente, mas que foram feitos para outra operadora. *No posso anunciar 100.0.8.0/21 para o AS 900 como resolver esse problema?

1-Boas prticas para um AS de transito

1.2 - Evitando propagar anncios do seu cliente, mas que foram feitos para outra operadora.
Nesses casos precisamos adicionar mais uma condio de match com o que chamamos de expresses regulares: /routing filter> add action=accept chain=peer-operadora_as900-out prefix=100.0.0.0/20 prefix-length=20-24 bgp-as-path=^100$

*traduzinho: quero receber a rede 100.0.0.0/20 ou qualquer sub-bloco /21, /22, /23 ou /24 mas apenas que comecem com "100" no seu as-patch Evitamos assim que anncios recebidos por outra operadora sejam repassados indevidadmente Caso eu substitua "$" por "_" preservo ao meu cliente a libertade de utilizar um "as-patch-prepend" aceitando um AS-patch assim:

1-Boas prticas para um AS de transito

1.2 - Evitando propagar anncios do seu cliente, mas que foram feitos para outra operadora.
Cisco CLI
R1(config)# ip prefix-list BLOCOS-AS-100 seq 1 permit 10.0.0.0/20 le 24 R1(config)# ip as-path access-list AS-PATH-100 permit ^100$ ou ^100_ R1(config)# route-map as100-in permit 10 match ip address prefix-list BLOCOS-AS-100 match as-path AS-PATH-100

2-AS's de trnsito nas trocas de trfego

2.1 - Algumas precaues

Existem alguns pontos importantes serem considerados, pois a ausncia de alguns filtros podem causar prejuzos, aumento de latncia ou loops de roteamento.

Um bom exemplo disso aconteceu com uma grande operadora que participa do PTT-SP. Atualmente esse problema foi resolvido, mas ainda existem outras que no esto filtrando determinados anncios.

2-AS's de trnsito nas trocas de trfego

2.2- Quando meu cliente de transito participa do PTT

O que aconteceria com o transito IP desse cliente?

2-AS's de trnsito nas trocas de trfego

2.2- Quando meu cliente de transito participa do PTT

Rotas recebidas diretamente pelo cliente Rotas recebidas pela troca de trfego

100.0.0.0/20 => as-patch 100 100.0.0.0/21 => as-patch 100 100.0.8.0/21 => as-patch 100

1# 2# 3#

Com essa RIB, todo transito IP com destino ao cliente, originado da internet, chegar ao seu router de borda, consumir a banda da sua operadora, mas chegar at ele pela troca de trfego, e com um certo conhecimento, o cliente pode manipular certos anncios e fazer parecer que ele no est consumindo quase nenhum trnsito IP, quando na verdade, esse trfego est "driblando" seus equipamentos que controlam banda.

2-AS's de trnsito nas trocas de trfego

2.2- Quando meu cliente de transito participa do PTT

100.0.0.0/20 => as-patch 100 100.0.0.0/21 => as-patch 100 100.0.8.0/21 => as-patch 100

1# 2# 3#

Como evitar esse problema?

2-AS's de trnsito nas trocas de trfego

2.2- Quando meu cliente de transito participa do PTT

Trocar trfego algo muito bom...

...desde que no seja o trnsito IP do meu cliente

Soluo:
No receber nenhum anncio que tenha sido originado pelo meu cliente no PTT

2-AS's de trnsito nas trocas de trfego

2.2- Quando meu cliente de transito participa do PTT
Configurando no RouterOS:

/routing filter> add action=accept chain=ptt-sp-in bgp-as-path=_100_

Com esse filtro, qualquer rota exportada pelo AS 100 der ignorada

2-AS's de trnsito nas trocas de trfego

2.2- Quando meu cliente de transito participa do PTT
Configurando no CISCO:

... SP(config)# ip as-path access-list NAO-RECEBER-PTT-SP permit _100_ SP(config)# route-map PTT-SP-IN deny 10 match as-path NAO-RECEBER-PTT-SP ...

3-Um estudo de caso

3.1 - Vantagens e desvantagens de um modelo BGP-VPN
Cenrio simplificado da rede ANID

3-Um estudo de caso

3.1 - Prs e contras de um modelo BGP-VPN Contras

Impossibilidade de utilizar silnalizao MPLS, e informaes de layer 2

Prs
Possibilidade de balancear o uso de links ociosos Conectifidade IP independente entre as extremidades Clientes de trnsito trocam trfego com outros clientes de trnsito remotos

3-Um estudo de caso

3.2 - Transformando minha rede em um "PTT"
Vamos focar nossa ateno em 2 POPs para facilitar o entendimento:

3-Um estudo de caso

3.2 - Transformando minha rede em um "PTT"
[admin@SP] > ip route print detail where dst-address =10.0.0.0.0/24 0 ADb dst-address=10.0.0.0/24 gateway=192.168.1.1 gateway-status=192.168.1.1 reachable ether2-link_vpn distance=20 scope=40 target-scope=10 bgp-as-path="17379,65006" bgp-origin=igp received-from=peer_vpn 1 Db dst-address=10.0.0.0/24 gateway=172.16.0.1 gateway-status=172.16.0.1 reachable ether1-link_ip distance=20 scope=40 target-scope=10 bgp-as-path="6000,1000,28135" bgp-origin=igp received-from=peer_transito_ip [admin@SP] > ip route print detail where dst-address =222.222.222.0/24 0 ADb dst-address=222.222.222.0/24 gateway=192.168.1.1 gateway-status=192.168.1.1 reachable ether2-link_vpn distance=20 scope=40 target-scope=10 bgp-as-path="17379,65006,12345" bgp-origin=igp received-from=peer_vpn 1 Db dst-address=222.222.222.0/24 gateway=172.16.0.1 gateway-status=172.16.0.1 reachable ether1-link_ip distance=20 scope=40 target-scope=10 bgp-as-path="6000,1000,28135,12345" bgp-origin=igp received-from=peer_transito_ip

3-Um estudo de caso

3.2 - Transformando minha rede em um "PTT"
[admin@PARTICIPANTE_PTT> ip route print detail where dst-address =10.0.0.0.0/24 0 Db dst-address=10.0.0.0/24 gateway=172.16.200.1 gateway-status=172.16.200.1 reachable ether1-link_anid distance=20 scope=40 target-scope=10 bgp-as-path="28135,17379,65006" bgp-origin=igp received-from=peer_ANID 1 ADb dst-address=10.0.0.0/24 gateway=200.200.200.1 (ex participante cliente do AS 1000) gateway-status=200.200.200.1 reachable ether1-link_as1000 distance=20 scope=40 target-scope=10 bgp-as-path="1000,28135" bgp-origin=igp received-from=peer_as1000 [admin@PARTICIPANTE_PTT> ip route print detail where dst-address =222.222.222.0/24 0 Db dst-address=222.222.222.0/24 gateway=172.16.200.1 gateway-status=172.16.200.1 reachable ether1-link_anid distance=20 scope=40 target-scope=10 bgp-as-path="28135,17379,65006,12345" bgp-origin=igp received-from=peer_ANID 1 ADb dst-address=222.222.222.0/24 gateway=200.200.200..1 gateway-status=200.200.200.1 reachable ether1-link_as1000 distance=20 scope=40 target-scope=10 bgp-as-path="1000,28135,12345" bgp-origin=igp received-from=peer_as1000

3-Um estudo de caso

3.2 - Transformando minha rede em um "PTT"

SOLUO:

3-Um estudo de caso

3.2 - Transformando minha rede em um "PTT"

Configurando : RouterOS CLI admin@SP] /routing bgp peer> add name=ibgp-bahia remote-address=192.168.20.2 remote-as=28135 in-filter=ibgp-in out-filter=ibgp-out nexthop-choice=force-self

admin@BA] /routing bgp peer> add name=ibgp-sao_paulo remote-address=192.168.0.2 remoteas=28135 in-filter=ibgp-spo-in out-filter=ibgp-spo-out nexthopchoice=force-self

3-Um estudo de caso

3.2 - Transformando minha rede em um "PTT"

Configurando : CISCO CLI

SP(config-router)# neighbor 192.168.20.2 remote-as 28135 neighbor 192.168.20.2 description IBGP Bahia neighbor 192.168.20.2 next-hop-self neighbor 192.168.20.2 default-originate neighbor 192.168.20.2 soft-reconfiguration inbound neighbor 192.168.20.2 route-map IBGP-IN in neighbor 192.168.20.2 route-map IBGP-OUT out

BA(config-router)# neighbor 192.168.0.2 remote-as 28135 neighbor 192.168.0.2 description IBGP So Paulo neighbor 192.168.0.2 next-hop-self neighbor 192.168.0.2 soft-reconfiguration inbound neighbor 192.168.0.2 route-map IBGP-SPO-IN in neighbor 192.168.0.2 route-map IBGP-SPO-OUT out

3-Um estudo de caso

3.2 - Transformando minha rede em um "PTT"
Exemplo das rotas no router de So Paulo aps sesso IBGP [admin@SP] > ip route print detail where dst-address =10.0.0.0.0/24 0 ADb dst-address=10.0.0.0/24 gateway=192.168.1.1 gateway-status=192.168.1.1 reachable ether2-link_vpn distance=20 scope=40 target-scope=10 bgp-as-path="17379,65006" bgp-origin=igp received-from=peer_vpn 1 Db dst-address=10.0.0.0/24 gateway=172.16.0.1 gateway-status=172.16.0.1 reachable ether1-link_ip distance=20 scope=40 target-scope=10 bgp-as-path="6000,1000,28135" bgp-origin=igp received-from=peer_transito_ip 2 Db dst-address=10.0.0.0/24 gateway=192.168.20.2 gateway-status192.168.20.2 unreachable distance=200 scope=40 target-scope=30 bgp-local-pref=100 bgp-med=0 bgp-origin=igp received-from=ibgp_bahia PS: Caso haja uma rota padro instalada, o RouterOS troca o "unreachable" por "recursive via x.x.x.x" onde x.x.x.x o nexthop da rota padro, o que na prtica d no mesmo j que o router mandaria os pacotes para a sua rota padro, o que no nos interessa.

3-Um estudo de caso

3.2 - Transformando minha rede em um "PTT"
Exemplo das rotas no router de So Paulo aps sesso IBGP [admin@SP] > ip route print detail where dst-address =222.222.222.0/24 0 ADb dst-address=222.222.222.0/24 gateway=192.168.1.1 gateway-status=192.168.1.1 reachable ether2-link_vpn distance=20 scope=40 target-scope=10 bgp-as-path="17379,65006,12345" bgp-origin=igp received-from=peer_vpn 1 Db dst-address=222.222.222.0/24 gateway=172.16.0.1 gateway-status=172.16.0.1 reachable ether1-link_ip distance=20 scope=40 target-scope=10 bgp-as-path="6000,1000,28135,12345" bgp-origin=igp received-from=peer_transito_ip 2 Db dst-address=222.222.222.0/24 gateway=192.168.20.2 gateway-status=192.168.20.2 unreachable distance=200 scope=40 target-scope=30 bgp-as-path="12345" bgp-local-pref=100 bgp-origin=igp received-from=ibgp-bahia

3-Um estudo de caso

3.2 - Transformando minha rede em um "PTT"

Resolvendo o problema da rota inalcanvel:

Nesse caso, o nosso "next-hop" (192.168.20.2) no faz parte de uma rede diretamente conectada, mas sim de uma rede que foi recebida via BGP conforme print abaixo: [admin@SP] > ip route print detail where dst-address =192.168.20.0/30

0 ADb dst-address=192.168.20.0/30 gateway=192.168.0.1 gateway-status=192.168.0.1 reachable ether2-link_vpn distance=20 scope=40 target-scope=10 bgp-as-path="17379" bgp-origin=igp received-from=peer_vpn

admin@SP] /routing filter> add action=passthrough chain=ibgp-in set-target-scope=40 set-bgplocal-pref=120

3-Um estudo de caso

3.2 - Transformando minha rede em um "PTT"

CISCO CLI
SP(config)# route-map IBGP-IN permit 10 ... set ip next-hop 192.168.0.1

3-Um estudo de caso

3.2 - Transformando minha rede em um "PTT"
Exemplo das rotas no router de So Paulo aps sesso IBGP estabelecida [admin@SP] > ip route print detail where dst-address =10.0.0.0.0/24 0 Db dst-address=10.0.0.0/24 gateway=192.168.1.1 gateway-status=192.168.1.1 reachable ether2-link_vpn distance=20 scope=40 target-scope=10 bgp-as-path="17379,65006" bgp-origin=igp received-from=peer_vpn 1 Db dst-address=10.0.0.0/24 gateway=172.16.0.1 gateway-status=172.16.0.1 reachable ether1-link_ip distance=20 scope=40 target-scope=10 bgp-as-path="6000,1000,28135" bgp-origin=igp received-from=peer_transito_ip 2 ADb dst-address=10.0.0.0/24 gateway=192.168.20.2 gateway-status192.168.20.2 recursive via 192.168.0.1 distance=200 scope=40 target-scope=40 bgp-local-pref=120 bgp-med=0 bgp-origin=igp received-from=ibgp_bahia
PS: Como apenas a rota vlida repassada para os outros peers, o AS-Patch ser dessa vez propagado corretamente sem que apaream o AS privado nem o AS da minha operadora.

3-Um estudo de caso

3.2 - Transformando minha rede em um "PTT"
Exemplo das rotas no router de So Paulo aps sesso IBGP [admin@SP] > ip route print detail where dst-address =222.222.222.0/24 0 Db dst-address=222.222.222.0/24 gateway=192.168.1.1 gateway-status=192.168.1.1 reachable ether2-link_vpn distance=20 scope=40 target-scope=10 bgp-as-path="17379,65006,12345" bgp-origin=igp received-from=peer_vpn 1 Db dst-address=222.222.222.0/24 gateway=172.16.0.1 gateway-status=172.16.0.1 reachable ether1-link_ip distance=20 scope=40 target-scope=10 bgp-as-path="6000,1000,28135,12345" bgp-origin=igp received-from=peer_transito_ip 2 ADb dst-address=222.222.222.0/24 gateway=192.168.20.2 gateway-status=192.168.20.2 recursive via 192.168.0.1 distance=200 scope=40 target-scope=40 bgp-as-path="12345" bgp-local-pref=300 bgp-origin=igp received-from=ibgp-bahia Na tabela dos clientes de transito IP ou participantes do PTT-Metro a lgica seria a mesma, e os AS-Patch indesejado no iria mais ser propagado.

3-Um estudo de caso

3.2 - Transformando minha rede em um "PTT"
[admin@PARTICIPANTE_PTT> ip route print detail where dst-address =10.0.0.0.0/24 0 ADb dst-address=10.0.0.0/24 gateway=172.16.200.1 gateway-status=172.16.200.1 reachable ether1-link_anid distance=20 scope=40 target-scope=10 bgp-as-path="28135" bgp-origin=igp received-from=peer_ANID 1 Db dst-address=10.0.0.0/24 gateway=200.200.200.1 (ex participante cliente do AS 1000) gateway-status=200.200.200.1 reachable ether1-link_as1000 distance=20 scope=40 target-scope=10 bgp-as-path="1000,28135" bgp-origin=igp received-from=peer_as1000 [admin@PARTICIPANTE_PTT> ip route print detail where dst-address =222.222.222.0/24 0 ADb dst-address=222.222.222.0/24 gateway=172.16.200.1 gateway-status=172.16.200.1 reachable ether1-link_anid distance=20 scope=40 target-scope=10 bgp-as-path="28135,12345" bgp-origin=igp received-frompeer_ANID 1 Db dst-address=222.222.222.0/24 gateway=200.200.200..1 gateway-status=200.200.200.1 reachable ether1-link_as1000 distance=20 scope=40 target-scope=10 bgp-as-path="1000,28135,12345" bgp-origin=igp received-from=peer_as1000

3-Um estudo de caso

3.3 - Um problema de escalabilidade
Estabelecendo sesses ibgp entre todos os POPs

3-Um estudo de caso

3.3 - Um problema de escalabilidade
Comeando por Bahia:

3-Um estudo de caso

3.3 - Um problema de escalabilidade
Depois Rio Grande do Sul:

3-Um estudo de caso

3.3 - Um problema de escalabilidade
Ficamos assim diante de uma dificuldade extrema, por exemplo, tenho 35 POPs ativos hoje, quantas sesses BGP so necessrias?

3-Um estudo de caso

3.3 - Um problema de escalabilidade

Para evitar algumas dezenas de slides vamos fazer uma anlize combinatria enquanto nos resta tempo para "desistir" Quantas sesses BGP no total? vou chamar esse valor de T 6 POPS (elementos) que vou chamar de "e" Sesso BGP = agrupamento 1+1 (sem repeties nem AA nem BA) que vou chamar de "a"

T(e,a) = e! / [ (e-a)! * a!]

Aplicando a frmula para os 6 POPs do exemplo

fat(6) / [ fat(6-2) * fat(2) ] = 15

Aplicando a frmula na quantidade de POPs ativos na ANID

fat(35) / [ fat(35-2) * fat(2) ] = 595

Aplicando ao meu planejamento futuro de 60 POPs

fat(60) / [ fat(60-2) * fat(2) ] = 1770

3-Um estudo de caso

3.3 - Um problema de escalabilidade
Com "Route-Reflector" em SP podemos reduzir a quantidade de sesses iBGP dentro do meu AS para apenas 1 por POP, reduzinho ento de 15 para 5 sesses iBGP no total

3-Um estudo de caso

3.3 - Uma soluo e um novo problema
A soluo de route-reflector resolve o meu problema de escalabilidade, porm me traz um novo problema em um cenrio particular, porm relativamente comum: Meu cliente do AS-12345 compra Transito IP em 2 POPs diferentes E meus filtros precisam proporcionar liberdade para que ele decida para qual POP anunciar seus blocos, bem como modificar esses anuncios quando bem entender

3-Um estudo de caso

3.4 - Uma soluo e um novo problema
[admin@RS] /ip route print detail where dst-address in 100.0.0.0/20

0 ADb dst-address=100.0.0.0/21 gateway=172.16.40.2 gateway-status=172.168.40.2 reachable ether3-cliente distance=20 scope=40 target-scope=10 bgp-as-path="12345" bgp-med=0 bgp-origin=igp receivedfrom=cliente_as12345
1 ADb dst-address=100.0.8.0/21 gateway=192.168.20.2 gatewaystatus=192.168.20.2 recursive via 192.168.30.1 ether2-link_vpn distance=20 scope=40 target-scope=40 bgp-as-path="12345" bgporigin=igp received-from=ibgp-sao_paulo

Observem que nesse caso, o "bgp-as-patch" permanece o mesmo, tanto na rota recebita diretamente do cliente (#0) quanto na rota que o cliente anunciou no POP Bahia e foi "refletida" por SP, a condio de match utilizada o inicio dessa apresentao iria anunciar

3-Um estudo de caso

3.4 - Uma soluo e um novo problema

Vamos analizar as condies de match:

/routing filter> add action=accept chain=peerX-out prefix=100.0.0.0/20 prefixlength=20-24 bgp-as-path=^12345_ Note que as duas rotas comeam com ^12345, j que a rota que no quero anunciar foi recebida de um router do meu prprio AS, e por ser do meu AS no houve incremento no AS-Patch.

O que fazer?

3-Um estudo de caso

3.4 - Uma soluo e um novo problema
Existem vrias maneiras, porm muito difceis de escalar em sua maioria, vamos utilizar uma que exija o mnimo de configuraes:

Faremos o Route Reflector-SP inserir uma communite "999:999" em

3-Um estudo de caso

3.4 - Uma soluo e um novo problema

Adiciono ento um filtro que insere uma community em todas as rotas refletidas pelo Route-Reflector SP
Configurando: RouterOS CLI: admin@SP] /routing filter> ... add action=passthrough chain=ibgp-out set-bgpcommunities=999:999 ...

3-Um estudo de caso

3.4 - Uma soluo e um novo problema

Configurando: CISCO CLI: SP(config)# route-map IBGP-OUT permit 10 ... set community 999:999 ...

3-Um estudo de caso

3.4 - Uma soluo e um novo problema
Vamos verificar agora como ficou a tabela

[admin@RS] /ip route print detail where dst-address in 100.0.0.0/20

0 ADb dst-address=100.0.0.0/21 gateway=172.16.40.2 gateway-status=172.168.40.2 reachable ether3-cliente distance=20 scope=40 target-scope=10 bgp-as-path="12345" bgp-med=0 bgporigin=igp received-from=cliente_as12345 1 ADb dst-address=100.0.8.0/21 gateway=192.168.20.2 gatewaystatus=192.168.20.2 recursive via 192.168.30.1 ether2-link_vpn distance=20 scope=40 target-scope=40 bgp-as-path="12345" bgporigin=igp bgp-communities=999:999 received-from=ibgp-sao_paulo Agora tenho como proibir o anncio das rotas refletidas utilizando communities! Vejamos como:

3-Um estudo de caso

3.4 - Uma soluo e um novo problema
Adicionando mais uma condio de match na sada local:

[admin@RS] /routing filter>

add action=accept chain=peerX-out prefix=100.0.0.0/20 prefixlength=20-24 bgp-as-path=^12345_ bgp-communities=!999:999 Ou inserindo no topo uma regra de discard: [admin@RS] /routing filter> add action=discard chain=peerX-out bgp-communities=999:999

interessante negar esse anncio apenas para minha operadora local, e permitir para os meus clientes de transito IP

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante
Considere um link redundande para cada POP:

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante

No modelo do slide anterior h um grande desperdcio de dinheiro levando em conta que dificilmente todos os links cairo simultaneamente, sendo assim, podemos diminuir os custos se conectando a um PIX do PTT-Metro-SP, comprando um link maior para backup em So Paulo e trazendo esse link atraves de circuitos de transporte BGP-VPN conforme veremos a seguir:

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante

Por que apenas 240Mb de link backup em SP e 500Mb VPN?

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante

Segundo estatsticas, aproximadamente 40% do volume total de trfego dos clientes vem pela troca de trfego de So Paulo, sendo assim, posso dispobinbilizar 40% a menos de trnsito IP nos meus link.
Com relao aos 500Mb de VPN sou obrigado a ter em SP a soma do total que tenho nas 5 terminaes, ou seja, 100Mb de cada POP x 5=500Mb, porm uma boa negociao pode dimimuir muito o preo do Mb de VPN, por exemplo, aqui na ANID pagamos menos da metade desse valor. Vamos entender melhor:

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante

Situao Normal: 60% do trafego chegando pelos links IP locais

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante
Situao Normal:

Para facilitar vamos analizar um POP por vez:

60% de todo trfego chega pelo circuito IP local e 40% pelo link BGP-

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante
Circuito IP de PE fora

Agora 100% do me trfego chega em PE pelo link BPG-VPN

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante
Circuitos IP de PE e BA fora

Ainda me restam 60Mb de banda IP aguardando o PIOR dos casos...

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante
Circuitos IP de PE,BA e RS fora

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante
Circuitos IP de PE, BA e RS fora

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante
Configurando as sesses eBGP no RouterOS: admin@SP] /routing bgp peer> add name=link-SP-master remote-address=ip_do_peer_remoto remote-as=as_operadora in-filter=link-sp-master-in out-filter=link-spmaster-out nexthop-choice=force-self

add name=link-SP-backup remote-address=ip_do_peer_remoto remote-as=as_operadora in-filter=link-sp-backup-in out-filter=link-spbackup-out nexthop-choice=force-self

add name=ptt-sp-rs1 remote-address=187.16.216.254 remoteas=26162 in-filter=ptt-sp-in out-filter=ptt-sp-out nexthopchoice=force-self add name=ptt-sp-rs2 remote-address=187.16.216.253 remoteas=26162 in-filter=ptt-sp-in out-filter=ptt-sp-out nexthopchoice=force-self

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante
Configurando as sesses eBGP no CISCO:

SP(config-router)# neighbor ip_link_master remote-as as_link_master neighbor ip_link_master description Link Principal neighbor ip_link_master soft-reconfiguration inbound neighbor ip_link_master route-map LINK-SP-MASTER-IN in neighbor ip_link_master route-map LINK-SP-MASTER-OUT out SP(config-router)# neighbor ip_link_backup remote-as as_link_backup neighbor ip_link_backup description Link de Backup neighbor ip_link_backup soft-reconfiguration inbound neighbor ip_link_backup route-map LINK-SP-BACKUP-IN in neighbor ip_link_backup route-map LINK-SP-BACKUP-OUT out

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante
Configurando as sesses eBGP no CISCO:

#Vamos utilizar os mesmos filtros para 2 neighbors com PEER-GROUP SP(config-router)# neighbor PTT-SP peer-group neighbor PTT-SP next-hop-self neighbor PTT-SP soft-reconfiguration inbound neighbor PTT-SP route-map PTT-SP-IN in neighbor PTT-SP route-map PTT-SP-OUT out

SP(config-router)# neighbor 187.16.216.253 remote-as 26162 neighbor 187.16.216.253 peer-group PTT-SP neighbor 187.16.216.253 description PTT-SP-IPV4-RS2 #RS2, RS1 neighbor 187.16.216.254 remote-as 26162 neighbor 187.16.216.254 peer-group PTT-SP neighbor 187.16.216.254 description PTT-SP-IPV4-RS1 # LG SP(config-router)# neighbor 187.16.216.252 remote-as 20121

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante
Configurando as sesses iBGP no RouterOS: admin@SP] /routing bgp peer> add name=ibgp-PE remote-address=ip_do_pop_remoto remoteas=28135 in-filter=ibgp-in out-filter=ibgp-out route-reflect=yes defaultoriginate=always nexthop-choice=force-self

add name=ibgp-CE remote-address=ip_do_pop_remoto remoteas=28135 in-filter=ibgp-in out-filter=ibgp-out route-reflect=yes defaultoriginate=always nexthop-choice=force-self

add name=ibgp-MG remote-address=ip_do_pop_remoto remoteas=28135 in-filter=ibgp-in out-filter=ibgp-out route-reflect=yes defaultoriginate=always nexthop-choice=force-self

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante Configurando as sesses IBGP:
admin@SP] /routing bgp peer> add name=ibgp-RS remote-address=ip_do_pop_remoto remoteas=28135 in-filter=ibgp-in out-filter=ibgp-out route-reflect=yes defaultoriginate=always nexthop-choice=force-self

add name=ibgp-BA remote-address=ip_do_pop_remoto remoteas=28135 in-filter=ibgp-in out-filter=ibgp-out route-reflect=yes defaultoriginate=always nexthop-choice=force-self

Configurando iBGP no POP remoto (exemplo vale para todos) admin@PE] /routing bgp peer> add name=ibgp-SPO remote-address=ip_do_pop_remoto remoteas=28135 in-filter=ibgp-SPO-in out-filter=ibgp-SPO-out nexthopchoice=force-self

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante

Configurando as sesses iBGP no CISCO:

SP(config-router)# neighbor IBGP peer-group neighbor IBGP update-source vlan3 neighbor IBGP route-reflector-client neighbor IBGP next-hop-self neighbor IBGP default-originate neighbor IBGP soft-reconfiguration inbound neighbor IBGP route-map IBGP-IN in neighbor IBGP route-map IBGP-OUT out

#Para facilitar configuramos o PEER-GROUP apenas uma vez...

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante
Configurando as sesses iBGP no CISCO:
... neighbor ip_pop_PE remote-as 28135 neighbor ip_pop_PE peer-group IBGP neighbor ip_pop_PE description IBGP-RECIFE-PE neighbor ip_pop_CE remote-as 28135 neighbor ip_pop_CE peer-group IBGP neighbor ip_pop_PE description IBGP-FORTALEZA-CE neighbor ip_pop_MG remote-as 28135 neighbor ip_pop_MG peer-group IBGP neighbor ip_pop_MG description IBGP-MONTES-CLAROS-MG neighbor ip_pop_RS remote-as 28135 neighbor ip_pop_RS peer-group IBGP neighbor ip_pop_RS description IBGP-PORTO-ALEGRE-RS neighbor ip_pop_BA remote-as 28135 neighbor ip_pop_BA peer-group IBGP neighbor ip_pop_BA description IBGP-SALVADOR-BA

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante
... Configurando as sesses iBGP no CISCO:

BA(config-router)# neighbor ip_POP_spo remote-as 28135 neighbor ip_POP_spo description IBGP So Paulo neighbor ip_POP_spo next-hop-self neighbor ip_POP_spo soft-reconfiguration inbound neighbor ip_POP_spo route-map IBGP-SPO-IN in neighbor ip_POP_spo route-map IBGP-SPO-OUT out

#O exemplo o mesmo para todos os POPs remotos, PE, MG, CE e RS

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante

Configurando os filtros do canal ibgp-in RouterOS:

admin@SP] /routing filter> add action=accept chain=ibgp-in set-bgp-communities=1111:1111 set-bgp-local-pref=120 # Essa regra identifica com a community 1111:1111 e prioriza as rotas recebitas dos POPs remotos *quero que a prioridade dessas rotas seja maior que o padro (100) recebido das operadoras, mas ao mesmo tempo menor do que as rotas recebidas do PTT

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante

Configurando os filtros do canal ibgp-in no CISCO:

... SP(config)# route-map IBGP-IN permit 10 set local-preference 120 set community 1111:1111 ...

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante

Configurando os filtros do canal ibgp-out:

admin@SP] /routing filter> add action=discard chain=ibgp-out set-bgp-as-path=^17379$ add action=accept chain=ibgp-out bgp-communities=1111:1111 set-bgp-communities=999:999 # A primeira regra evita que rotas da nuvem BGP-VPN sejam enviadas para os POPs remotos pelo Route Reflector # A segunda reflete as rotas recebidas por IBGP e "reflete" com uma nova community 999:999

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante

Configurando os filtros do canal ibgp-out:

... SP(config)# ip as-path access-list IBGP permit ^17379$ SP(config)# route-map IBGP-OUT deny 9 match as-path IBGP ... ... SP(config)# ip community-list standard IBGP permit 1111:1111

SP(config)# route-map IBGP-OUT permit 10 match community IBGP set community 999:999
...

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante

Configurando os filtros do canal ptt-sp-in no RouterOS:

admin@SP] /routing filter> add action=accept chain=ptt-sp-in set-bgp-local-pref=110

# Essa regra prioriza as rotas recebidas do PTT-Metro em relao as rotas recebidas das operadoras, mas no em relao as rotas recebidas por IBGP que so meus clientes redes do meu AS

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante

Configurando os filtros do canal ptt-sp-in no CISCO:

SP(config)# route-map PTT-SP-IN permit 10 set local-preference 110

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante

Configurando os filtros do canal ptt-sp-out no RouterOS:

admin@SP] /routing filter> add action=accept chain=ptt-sp-out bgp-communities=1111:1111 add action=accept chain=ptt-sp-out prefix=redes_locais add action=discard chain=ptt-sp-out # A primeira regra permite anncio das redes recebidas por iBGP dos POPs remotos; # A segunda permite o anncio das redes do prprio POP que nao receberam a community 1111:1111 # A terceira descarta todo o resto

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante

Configurando os filtros do canal ptt-sp-out no CISCO

... SP(config)# route-map PTT-SP-OUT permit 10 match ip address prefix-list BLOCOS-LOCAIS

SP(config)# ip community-list standard ANUNCIAR-PTT-SP permit 1111:1111 SP(config)# route-map PTT-SP-OUT permit 20 match community ANUNCIAR-PTT-SP ...

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante

Configurando os filtros do canal link-sp-master-in no RouterOS:

admin@SP] /routing filter> add action=accept chain=link-sp-master-in set-bgp-local-pref=90

# Essa regra atribui um Local_preference de 90 para as rotas recebidas da operadora SP master com a finalidade de no permitir que os routers remotos utilizem essas rotas , mas sim as rotas recebidas das operadoras locais que tero Local_pref padro (100)

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante

Configurando os filtros do canal link-sp-master-in no CISCO:

SP(config)# route-map LINK-MASTER-SP-IN permit 10 set local-preference 90

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante

Configurando os filtros do canal link-sp-master-out no RouterOS:

admin@SP] /routing filter> add action=discard chain=link-sp-master-out bgpcommunities=1111:1111 add action=accept chain=link-sp-master-out prefix=redes_locais add action=discard chain=link-sp-master-out # A primeira regra evita o problema descrito na sesso 5.3

# A segunda permite o anncio dos blocos de cliente locais

# A terceira descarta todo o resto e evita por exemplo o anncio de redes recebidas do PTT-Metro

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante

Configurando os filtros do canal link-sp-master-out no CISCO

... SP(config)# ip community-list standard NAO-ANUNCIAR-LINK-MASTER-SP permit 1111:1111 SP(config)# route-map LINK-MASTER-SP-OUT deny 10 match community NAO-ANUNCIAR-LINK-MASTER-SP

SP(config)# route-map LINK-MASTER-SP-OUT permit 20 match ip address prefix-list BLOCOS-LOCAIS ...

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante

Configurando os filtros do canal link-sp-backup-in no RouterOS:

admin@SP] /routing filter> add action=accept chain=link-sp-backup-in set-bgp-local-pref=80

#Essa regra atribui um Local_preference de 80 para as rotas recebidas do link backup para que as mesmas no subam na FIB do RouterSP, a menos claro que o link master fique fora

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante

Configurando os filtros do canal link-sp-backup-in no CISCO:

SP(config)# route-map LINK-BACKUP-SP-IN permit 10 set local-preference 80

#Essa regra atribui um Local_preference de 80 para as rotas recebidas do link backup para que as mesmas no subam na FIB do RouterSP, a menos claro que o link master fique fora

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante

Configurando os filtros do canal link-sp-backup-out:

Primeiramente preciso ter em mente que o link BACKUP de So Paulo deve ficar em stand by, ou seja, no quero que nenhum trfego dos POPs remotos ou redes locais cheguem por esse circuito com exeo de uma eventual queda nos circuitos IP principais (local ou qualquer um dos remotos) Para isso iremos utilizar o AS-Patch-Prepend:

Vamos as configuraes:

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante
Configurando no RouterOS # A primeira regra anuncia as rotas recebidas dos POPs remotos repetindo 3 vezes o meu prprio AS e remove a community 1111:1111 # A segunda faz a mesma coisa com as redes locais # A Terceira no permite o anncio de nada mais admin@SP] /routing filter> add action=accept chain=link-sp-backup-out set-bgp-prepend=3 bgp-communities=1111:1111 set-bgpcommunities="" add action=accept chain=link-sp-backup-out refix=redes_locais set-bgp-prepend=3 add action=discard chain=link-sp-backup-out

3-Um estudo de caso

3.5 - Um modelo relativamente barato de link redundante
Configurando no CISCO

... SP(config)# ip community-list standard ANUNCIAR-LINK-BACKUP-MASTER-SP permit 1111:1111

SP(config)# route-map LINK-BACKUP-SP-OUT permit 10 match community ANUNCIAR-LINK-MASTER-SP set as-path prepend 28135 28135 28135 28135
SP(config)# route-map LINK-BACKUP-SP-OUT permit 20 match ip address prefix-list BLOCOS-LOCAIS set as-path prepend 28135 28135 28135 28135 ...

PERGUNTAS??
pessoal: rinaldopvaz@gmail.com empresa rinaldo@anid.com.br
http://rinaldovaz.blogspot.com http://www.linkedin.com/profile/edit?trk=hb_tab_pro_top @rinaldo_vaz

AGRADECIMENTOS
todos que participam do projeto ANID, associados, mantenedores e conselheiros e colaboradores especialmente equipe do NOC e Patrcia Correia pela valiosa contribuio na elaborao dessa apresentao!

OBRIGADO!