sábado, 25 de abril de 2015

Visão básica do pop corn time

https://www.youtube.com/watch?v=U5__6cIN8gU

 

Usando Keep AssX para salvar suas senhas com segurança

https://www.youtube.com/watch?v=9jGQblZWls0

 

domingo, 19 de abril de 2015

Pergunta LPI - SPLIT com exemplo

José tem um arquivo grande que excede a capacidade de armazenamento de um disquete. Ele quer colocar o arquivo em dois disquestes, para que possa ter com ele quando se juntar a uma competição. Qual comando ele pode executarr para que o arquivo caiba em dois disquetes?

Escolha uma das seguintes respostas:
Pergunta obrigatória.

1    fmt
2   split
3    cut
4    nl

resposta split

exemplo:

1) compactando uma revista em pdf com gzip:  gzip 11_edicao_dezembro_20_12_2013.pdf

2) Checando o tamanho do arquivo com:  ls -lha
-rw-rw-r--  1 gustavofranco gustavofranco  15M Jun  4  2014 11_edicao_dezembro_20_12_2013.pdf.gz

3) Usando o comando split para dividir o arquivo em três parte de 5 megas.

root@TuX:/home/gustavofranco/Segurança Digital# split --bytes=5M 11_edicao_dezembro_20_12_2013.pdf.gz

4) Checando o que foi criado no diretório

root@TuX:/home/gustavofranco/Segurança Digital# ls
11_edicao_dezembro_20_12_2013.pdf     2_edicao_setembro_27_09_2011.pdf  5_edicao_marco_31_03_2012.pdf  8_edicao_setembro_30_09_2012.pdf  xaa
11_edicao_dezembro_20_12_2013.pdf.gz  3_edicao_novembro_27_11_2011.pdf  6_edicao_maio_31_05_2012.pdf   9_edicao_novembro_30_11_2012.pdf  xab
1_edicao_julho_01_07_2011.pdf         4_edicao_janeiro_29_01_2012.pdf   7_edicao_julho_31_07_2012.pdf  teste.gz                          xac

Como podemos analisar foi criado no seguinte formato, XAA, XAB, XAC,

5)Gustavo como faço para montar agora que eu sei splitar( segregar) o arquivo

Fazemos isso com nosso velho amigo cat unido ao ( > )

Exemplo:  root@TuX:/home/gustavofranco/Segurança Digital# cat x* > teste.gz

Usei expressões básicas com o X* (X QUALQUER COISA) e criamos o arquivo teste.gz

Desta maneira você tem seu arquivo de 15 megas novamente.

-rw-r--r--  1 root          root           15M Abr 19 19:06 teste.gz

sexta-feira, 17 de abril de 2015

Mysql parte 1

Criando banco de dados.
CREATE DATABASE testes;

Visualizando a base de dados criada.

Os nomes das tabelas são sensíveis à caixa (case sensitive). Ou seja, teste e TESTE são dois nomes totalmente diferentes pro MySQL.
SHOW DATABASES;

mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| GUSTAVOFRANCO |
| banco |
| my_wiki |
| mysql |
| performance_schema |
| testes |
+--------------------+
7 rows in set (0.07 sec)

 

 

quinta-feira, 16 de abril de 2015

Descobrindo a arquitetura do processador no Linux

Maneira 1

root@TuX:/home/gustavofranco# file /bin/bash | awk {'print $3'}
64-bit

Maneira 2

cat /proc/cpuinfo

ou cat /proc/cpuinfo | grep 64

Modo 3

cat /proc/cpuinfo | awk '/ 64/'
clflush size    : 64
cache_alignment    : 64
clflush size    : 64
cache_alignment    : 64
clflush size    : 64
cache_alignment    : 64
clflush size    : 64
cache_alignment    : 64

 

É isso abraços!

 

 

 

 

segunda-feira, 13 de abril de 2015

Roteamento Dinâmico no Linux Usando o Quagga

Blog que sempre acompanho: http://labcisco.blogspot.com.br/2015/04/roteamento-dinamico-no-linux-usando-o.html

Bom meu blog tem por finalidade passar informações ultimamente tenho adicionado novamente as coisas cisco pois perdi meu antigo domínio que tinha bastante coisa, e como hoje em dia estou mais engajado em softwares opensouce linux, freeswitch, opensips, asterisk, elastix o blog tem mais cara de Linuxzero e realmente é, porém eu fiz algumas especializações cisco também no passado gosto também desta área de rede então segue uma união desses dois ambientes roteamento e Linux.
Quagga é um software open source para ambientes Unix (Linux, FreeBSD, Solaris, etc) que provê suporte aos principais protocolos de roteamento dinâmico abertos: RIPv2 (IPv4), RIPng (IPv6), OSPFv2 (IPv4), OSPFv3 (IPv6) e BGP-4 (famílias IPv4 e IPv6). O software especializado em roteamento foi desenvolvido por Kunishiro Ishiguro e atulmente está na versão 0.99.24. O Quagga é na verdade uma suíte composta por um daemon principal denominado zebra, além de outro daemons adicionais responsáveis por cada um dos protocolos de roteamento dinâmico, a destacar: ripdripngdospfdospf6d e bgpd, além de outros. Um detalhe é que o suporte a OSPFv3 para IPv6 ainda não é considerado estável porque possui problemas.




Embora haja outras soluções open source de roteamento no Linux, a exemplo do BIRD e do XORP, o Quagga é uma das soluções mais populares porque sua interface de linha de comando é bastante similar ao sistema IOS da Cisco, o que torna sua operação natural para aqueles que já trabalham com caixas da Cisco. O objetivo deste artigo é listar os passos necessários para instalar o Quagga e manipular seus principais arquivos de configuração para reproduzir aquelas configurações de roteamento dinâmico tradicionalmente realizadas nos roteadores Cisco. Por isso nosso foco está na ferramenta em si, não nas configurações de roteamento propriamente ditas.


A primeira etapa consiste na instalação do Quagga, tarefa bastante simples e rápida através do APT em distribuições Linux baseadas no Debian:


root@Router:/# apt-get install quagga


Observação: Antes de fazer qualquer configuração de roteamento, é importante lembrar que o Linux não se comporta como roteador por padrão, negando todo o encaminhamento de pacotes entre redes distintas. Para instruir o kernel do Linux a permitir roteamento entre redes, tanto em ambientes IPv4 como IPv6, podemos utilizar os comandos abaixo:


root@Router:/# echo "1" > /proc/sys/net/ipv4/ip_forward

root@Router:/# echo "1" > /proc/sys/net/ipv6/conf/all/forwarding


Depois de instalado, os arquivos de configuração ficam armazenados em /etc/quagga. Uma boa prática para facilitar as configurações futuras é criar um diretório dentro do próprio diretório de configurações (/etc/quagga) com exemplos dos arquivos de configuração (disponíveis na documentação) para cada um dos daemons, procedimento que pode ser realizado através dos comandos abaixo:


root@Router:/# mkdir /etc/quagga/examples

root@Router:/# cp /usr/share/doc/quagga/examples/* /etc/quagga/examples


O primeiro arquivo de configuração importante que fica em /etc/quagga é denomindo daemons. Esse arquivo é bastante simples e deve ser editado para permitir aqueles daemons associados com os protocolos de roteamento dinâmico que o administrador pretende configurar na rede. Por exemplo, se queremos configurar o OSPF na rede, temos que ativar os daemons zebra (a base do Quagga) e o ospfd (responsável pelo OSPF).


#--- em /etc/quagga/daemons

# This file tells the quagga package which daemons to start
zebra=yes

bgpd=no

ospfd=yes

ospf6d=no

ripd=no

ripngd=no


Sempre que houver alguma alteração nesse arquivo ou nos demais arquivos de configuração do Quagga, o serviço deve ser reinicializado para que as alterações sejam aplicadas, procedimento que pode ser realizado através do comando abaixo:


root@Router:/# /etc/init.d/quagga restart


Os demais arquivos de configuração existentes no diretório /etc/quagga vão depender dos protocolos de roteamento dinâmico que serão utilizados na rede. Continuando com o exemplo do OSPF, precisamos criar dois arquivos de configuração que podem ser copiados a partir daquele diretório de exemplos. Além disso, é interessante dedicar um usuário/grupo para a ferramenta e é importante dar os devidos privilégios de acesso para que as configurações possam ser devidamente interpretadas pelo SO:


root@Router:/# cp /etc/quagga/examples/zebra.conf /etc/quagga

root@Router:/# cp /etc/quagga/examples/ospfd.conf /etc/quagga

root@Router:/# chown quagga.quagga /etc/quagga/*.conf

root@Router:/# chmod 640 /etc/quagga/*.conf


Se estivéssemos trabalhando com outros protocolos de roteamento seria necessário criar o respectivo arquivo de configuração associado ao daemon, por ex.: ripd.conf (RIP), ripngd.conf (RIPNG), bpgd.conf (BGP-4) e ospf6d.conf (OSPFv3). As configurações de roteamento dinâmico são realizadas através de edição nos arquivos de configuração (.conf). Outra opção é deixar o arquivo de configuração em branco para que as configurações sejam posteriormente realizadas via interface de linha de comando (acesso telnet), similar o que ocorre nas caixas Cisco. Cada daemon do Quagga, quando executado, passa a responder acessos telnet do localhost em suas respectivas portas padrões, que são:




  • 2601 - zebra

  • 2602 - ripd

  • 2603 - ripng

  • 2604 - ospfd

  • 2605 - bgpd

  • 2606 - ospf6d


 
Ou seja, para configurar o OSPF na máquina Linux executando o Quagga basta editar manualmente o arquivo ospfd.conf ou mesmo realizar um acesso telnet ao localhost na porta 2604, lógica que vale para o daemon zebra na configuração de roteamento estático (e configurações gerais) e para os demais daemons associados aos outros protocolos de roteamento dinâmico:


root@Router:/# telnet localhost 2604


Por padrão, o acesso telnet aos daemons do Quagga somente são permitidos através do próprio localhost. Para permitir esse acesso através de outras máquinas da rede, o arquivo de configuração /etc/quagga/debian.conf tem que ser editado para permitir outros endereços. Por exemplo, no arquivo de configuração abaixo estamos permitindo acesso telnet aos daemons zebra e ospfd também a partir do host 192.168.100.11, além do localhost (127.0.0.1).



#--- em /etc/quagga/debian.conf

vtysh_enable=yes
zebra_options=" --daemon -A 127.0.0.1 192.168.100.11"
bgpd_options=" --daemon -A 127.0.0.1 "
ospfd_options=" --daemon -A 127.0.0.1 192.168.100.11"
ospf6d_options="--daemon -A 127.0.0.1"
ripd_options=" --daemon -A 127.0.0.1"
ripngd_options="--daemon -A 127.0.0.1"
isisd_options=" --daemon -A 127.0.0.1"



Outro detalhe importante é que essa configuração via telnet através da linha de comando acaba sendo ruim na prática porque fica fragmentada por daemon, ou seja, para configurações relacionadas a rotas estáticas temos que realizar um acesso telnet na porta 2601 (zebra), enquanto que para realizar as configurações do OSPF temos que fazer outro acesso telnet na porta 2604 (ospfd). Para contornar essa dificuldade, existe uma ferramenta integrada de linha de comando denominada vtysh que permitimos na primeira linha de configuração do exemplo anterior (vtysh_enable=yes).


A ferramenta vtysh salva todas as configurações realizadas via linha de comando em um arquivo único denominado Quagga.conf. Para organizar melhor as configurações dos daemons individuais, podemos definir nas configurações do vtysh que as configurações dos daemons sejam salvas nos respectivos arquivos de configuração, ou seja, uma configuração de OSPF ficará salva apenas no arquivo ospfd.conf e assim por diante. Para fazê-lo é necessário editar o arquivo vtysh.conf e comentar sua primeira linha que permite a integração da configuração:


#--- em /etc/quagga/vtysh.conf

!service integrated-vtysh-config

hostname Quagga-Router

username root

password SENHA


Observação.: Uma dica útil em relação à ferramenta vtysh é que, por padrão, a cada vez que o administrador executa um comando aparece a palavra "END" na tela, o que requer que seja pressionada a tecla "q" para continuar. Para evitar que isso aconteça, basta incluir a seguinte linha no arquivo /etc/environment:  VTYSH_PAGER=more

Apesar das configurações poderem ser realizadas via linha de comando através de acesso remoto (telnet ou vtysh) aos daemons do Quagga, de maneira similar ao que ocorre nas caixas Cisco, particularmente acho que é ainda mais prático fazer essas configurações diretamente nos arquivos de configuração (.conf), afinal a sintaxe é a mesma. Por exemplo, com base no cenário apresentado na figura abaixo, para realizar uma configuração simples do OSPF podemos editar o arquivo /etc/quagga/ospfd.conf da seguinte maneira:


#--- em /etc/quagga/ospfd.conf

!
hostname Quagga-Router
password SENHA
!

interface eth0

  description "Link to Router B"

  ip address 192.168.200.1/30

  link-detect

!

interface eth1

  description "Link to Network 192.168.100.0/24"

  ip address 192.168.100.1/24

  link detect

!

router ospf

  network 192.168.200.0/30 area 0

  network 192.168.100.0/24 area 0

!


Por fim, vale reforçar que qualquer alteração nos arquivos de configuração requer a reinicialização do serviço Quagga e seus daemons: /etc/init.d/quagga restart. Agora é com vocês...


Samuel.

BGP - Básico

O BGP é um protocolo de roteamento advanced distance vector chamado de Path Vector desenvolvido para ISP's trocarem rotas isentas de loops. Ele  antém uma tabela separada da tabela de roteamento “IP BGP Table” e “Route Table”, se não for bem configurado pode fazer com que o meio externo influencie nas decisões de roteamento. Sua conexão com vizinho é configurada manualmente e possui atualizações confiáveis via TCP na porta 179 com envio de keepalive periódico. Não exige topologia hierárquica.

Possui uma lista do caminho completo até a rede de destino incluindo os AS's. O mecanismo para evitar loop é o Split Horizon, onde rotas aprendidas por um IBGP não são propagadas para os IBGPS vizinhos, sendo assim é necessário Full-Mesh ou o uso de roteadores refletores ou confederações.

Assim como os endereços IPs privados, os AS privados são 64512 to 65535. Seu roteamento não é aplicado nas interfaces e sim no router inteiro. Passive-interface não funciona.

O roteamento é baseado em políticas, porém, as políticas não podem influenciar como o AS vizinho irá rotear o seu tráfego, mas pode influenciar a forma como o seu trafego chega até o AS vizinho.

Quando não usar BGP? - Use rota estática

  • Tiver uma conexão simples com Internet (ISP) ou outro AS;

  • Não há preocupação com políticas e seleção de rotas;

  • Mesma política de roteamento utilizada pelo ISP (Bloco CIDR pertencente ao ISP);

  • Roteador com pouca memória;

  • Compreensão limitada de filtro de rotas e seleção de caminhos;

  • Baixa largura de banda entre AS's.


Tipos de BGP

  • IBGP - Internal BGP opera entre vizinhos no mesma AS. Não necessariamente precisam estar conectados físicamente;

  • EBGP - External BGP opera entre dois vizinhos conectados em diferentes ASs, não precisam estar diretamente conectados;

  • Quando o EBGP anuncia uma rota do seu vizinho ele anuncia o vizinho como um next-hop;

  • Somente rotas originadas no router IBGP são passadas para um vizinho IBGP, rotas aprendidas não são;

  • Rotas IBGP aprendidas por outro IBGP são passadas apenas para o EBGP (solução: route-reflector).



Atributos

São informações sobre as métricas BGP incluídas nas mensagens de atualização do BGP
Well-Known mandatory - atributos bem conhecidos mandatórios - devem aparecer na descrição da rota. É aquele que todas as implementações do BGP devem reconhecer, se propaga para os vizinhos.

  • Origin - Tipo 1 - Indica a origem da rota. Na tabela BGP aparece como: I= quando aprendida por IGP, E= Quando aprendida por EGP e ?= Quando a origem da rota é desconhecida (para rotas estáticas e de redistribuição);

  • AS-path - Tipo 2 - Sempre que uma atualização de rota passa através de uma AS o N.º da AS é pré-anexado aquela atualização (colocado no inicio da lista de AS's que foram atravessadas até chegar o destino. Os routers que divulgam para IBGP não mudam o atributo AS-Path. Garante o ambiente Isento os loops. Para manipular o tráfego com As-path usa-se o prepend.

  • Next-Hop - Tipo 3 - Anuncia o próximo salto para alcançar a rede de destino. Geralmente o Next-Hop é o endereço da rede /30. O router EBGP anuncia para o IBGP (routers internos) o Next-Hop como o endereço da rede /30 (endereço da rede entre os AS's), os routers do IBGP tem que conhecer a rede /30 entre os As's (EBGP) por um IGP ou rota estática. Em NBMA o router se anuncia.



Well-Known discretionary - atributos bem conhecidos arbitrário - Não precisa aparecer nas descrições de rotas.

  • Local Preference - Tipo 5 - Roda internamente na AS, não é passado para os peers EBGP e Informa no AS qual o melhor caminho para sair do AS. Um caminho com Local preference maior é preferido. Default Cisco = 100;

  • Atomic aggregate - Tipo 6 - Informa o AS vizinho que o router de origem agregou as rotas;



Optional Transitive - Opcional Transitivo - Opcional, caso o router não possua, deve ser passado inalterado. Propaga-se entre os AS's. Apenas os Opcionais Transitivos podem ser marcados como parciais;

  • Community - Tipo 8 - Serve para filtrar rotas de entrada e saída baseado na comunidade, 32bits (community Filters);

  • Aggregator - Tipo 7 - Informa o ID do router e o AS que executou a agregação da rota.


Optional nontransitive - Opcional não-transitivo - Roda dentro da AS e deve ser excluído se não implementado

  • MED - Tipo 4 - Chamado de métrica. É a divulgação de um caminho preferido dentro de um AS para AS’s externos. É uma forma de influenciar outro AS onde ele deve optar para atingir determinada rota.  Utilizado quando tem 2 entradas para o mesmo AS, quanto mais baixo melhor. Se não estiver habilitado a opção de verificar o MED, em routers CISCO é colocado por default o 0 que indica a melhor rota, mas no padrão IETF é colocado como infinito, a pior rota. Pode-se configurar para manter o padrão: bgp bestpath missing-as-worst;

  • Originator-ID – Tipo 9 - Atributo que carrega o router ID e o AS de quem originou a rota;


Weight - Particular CISCO, uso local somente no router para definir o peso da rota (preferencia) 0 - 65535, default=32768 e 0 para rotas aprendidas por outro BGP speaker, mais alto melhor. Não é propagado para nenhum vizinho, é apenas para uso local. Esse atributo tem prioridade sobre o Local Preference.

Synchronization

  • Um router não deve anunciar uma rota fora da AS antes que todos os outros tenham aprendido;

  • Gera consistência das informações dentro da AS;

  • Evita buracos negros dentro da AS;

  • Ligado por Default;

  • Não é necessário se o AS não é um AS de transito (AS que liga ASs);

  • Desabilitado a convergência é mais rápida;

  • Pode ser desabilitado se todos os routers de trânsito estiverem em full-mesh;

  • Quando estiver implementado o multihome, deve-se usar a sincronização.


Tipos de Mensagens
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;

  • BGP identifier (Router ID) – É o identificador do remetente. O ID do router é definido igual no OSPF, pelo maior IP ativo de todas as interfaces a menos que exista um IP no loopback

  • Authentication – Se usado;


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, se houver uma;


Path attributes – Atributos de caminhos, são: As-Path, Origin, Local Preference,... todos os atributos;


Network layer reachability Information – Esse campo contém uma lista dos prefixos de endereço IP que podem ser atingidos por esse caminho;

Notification - Enviada quando ocorre um erro, a conexão é fechada imediatamente

Estado do vizinho BGP

O protocolo BGP é uma máquina de estados, que leva um router através dos seguintes estados:

  • Idle – Estado inicial;

  • Connect – Conexão TCP e aguardo;

  • Active – Realiza tentativas de conexão TCP;

  • OpenSent – Estado e espera da resposta de conexão do vizinho;

  • OpenConfirm – Conexão estabelecida;

  • Estabilished – Troca de mensagem de atualização, keepalive e notificação.


Processo de Seleção de Rotas
Depois do BGP receber todas as informações de todos os AS’s e destinos as começam a ser decididas. Apenas 1 rota para cada destino. A decisão das melhores rotas baseia-se nos atributos.

  1. Se o caminho for interno não deve preferir se a rota não estiver sincronizada, ou seja, não esta na tabela de roteamento IGP;

  2. Não deve preferir se o endereço de Next-Hop não puder ser acessado;

  3. Preferir rota de maior Peso (weight), Preferencia local para roteadores Cisco System;

  4. Preferir rota com Local Preference mais alto dentro da AS (melhor caminho pra sair da AS);

  5. Se o Local Preference for igual, preferir rota originada pelo router local;

  6. Se nenhuma rota foi originada localmente, preferir rota com o AS-Path mais curto para o destino;

  7. Se os caminhos de AS’s forem iguais, preferir o código de origem mais baixo sendo as rotas aprendidas por IGP o melhor (IGP (I) < EGP (E) < incompleto (?));

  8. Se todos os códigos de origem forem iguais, preferir o caminho com o MED mais baixo (MED é enviado por outro AS);

  9. Se as rotas têm o mesmo MED, preferir caminhos Externos (EBGP) em vez dos internos (IBGP);

  10. Se a sincronização estiver desativada apenas existirá caminhos internos, nesse caso escolher o caminho até o vizinho IGP mais próximo, caminho interno mais curto;

  11. Para caminhos externos EBGP escolher a rota mais antiga para minimizar o efeito flapping  (up down);

  12. Preferir o caminho com o ID do router vizinho mais baixo;

  13. Preferir a rota com o endereço IP do vizinho mais baixo.


Peer Groups
Muitos vizinhos são configurados com as mesmas políticas de atualização (por exemplo, mesmo filtro). Em routers CISCO os vizinhos com a mesma política de atualização podem ser agrupados em peer groups. É definida uma política para o peer Group e todos os vizinhos vinculados a esse peer group adotam as políticas.

O nome de um Peer Group é local do router onde ele é configurado e não é passado para nenhum outro router.

  • Simplifica a configuração dos vizinhos;

  • Utilizado nas conexões iBGP e eBGP;

  • Todos os vizinhos recebem o mesmo update;

  • Updates são gerados uma vez para cada  grupo.

  • Politicas podem ser modificadas individualmente somente para informações de rotas entrante e não para sainte.


Route Reflectors
Os refletores de rota modificam a regra do split-horizon que existe por default onde nenhum router replica as rotas aprendidas por um vizinho para outro vizinho, IBGP não replica para IBGP. No entanto uma rota BGP aprendida por um vizinho EBGP é replicada para vizinhos EBGP e IBGP.

Benefícios

  • Habilita um router para propagar as rotas aprendidas por um IBGP para seus vizinhos;

  • Resolve o problema do split horizon;

  • Retira a necessidade do Full-Mesh;

  • Diminui o n.º de relacionamentos entre vizinhos, minimizando assim o n.º de conexões TCP;

  • Muito usado por ISP's quando o n.º de declarações internas de vizinhos se torna excessivo;

  • Não afeta os caminhos que os pacotes seguem, somente a atualização de rotas;

  • Dentro de um AS podem ter vários refletores de rotas;

  • Migração fácil, pois é protocolo aberto;

  • Pode-se ter mais de um route-reflector server em um Cluster. Todos devem ter o mesmo Cluster-ID.


Terminologias

  • Router reflector - O router refletor de rotas que tem a permissão de repassar as rotas aprendidas;

  • Clients - quem recebe os anúncios de rotas sempre;

  •  Cluster - A relação entre os clientes e o router refletor;

  • Nonclients - Não são cliente definidos pelo router refletor, mas recebe algumas atualizações de rotas;

  • Originator-ID - Atributo que carrega o router ID e o AS de quem originou a rota;

  • Cluster ID - Usado quando se tem mais de um router refletor, para reconhecer de quem veio a atualização. Default =Router ID.


Operação

  • Refletores recebem atualizações de peer clients e nonclients

  • Se a atualização for de um peer client ele reflete para os peer clients e nonclients (exceto para o router que originou);

  • Se a atualização for de um nonclient ele reflete para todos os peer clients do cluster;

  • Se a atualização for de um parceiro EBGP (outro AS) ele reflete para todos os peer clients e todos nonclients


Dicas de migração do Refletor de Rota

  • A primeira consideração é decidir quais routers devem ser os refletores e quais devem ser clientes observando a topologia, pois os refletores precisam de full mesh com os clientes.


Restrições

  • Os refletores de rota clientes não são compatíveis com os grupos de parceiros (peer-groups), isso acontece porque um router configurado com um peer-group deve enviar todas as atualizações para todos do peer-group.



Confederation

É a forma de dividir uma AS em várias ASs. Em determinado router configura-se o AS privado (confederation) e dentro do config-router se indica o AS Publico que esse AS privado pertence. Depois adiciona-se os vizinhos de acordo com os ASs privados ou publicos (no caso de uma conexão eBGP).

  • Cria-se Sub-AS privados dentro do AS principal;

  • Todos os vizinhos internos do AS pertencem ao mesmo Sub-Grupos ao qual estão relacionados.


Multihoming
É o termo usado quando um AS está conectado a mais de um ISP. Os ISP’s aos quais você conecta devem anunciar os seus prefixos na Internet:

  • Aumenta a confiabilidade da conexão com a Internet com redundância;

  • Aumenta o desempenho com distribuição.

  • Tipos de configuração Multihoming mais comuns:

  • Multihoming sem BGP usa um router conectado a 2 ISPs com configuração de rota statica e NAT;

  • Multihoming com BGP usa-se um AS privado para conectar aos ISPs;

  • Todos os ISPs passam somente as rotas default para o AS

  • O ISP que o AS usa para atingir a Internet será determinado pela métrica IGP, ou seja, do protocolo de roteamento interno;

  • Todos os ISPs passam as rotas default e as rotas específicas selecionadas (Clientes que o AS troca muito tráfego);


Anunciando Redes no BGP

 

  • Usando o comando Network ele permite anunciar uma rede que está na tabela IP. A lista de comandos Network deve incluir todas as redes do AS que você deseja anunciar;

  • Redistribuindo as rotas estáticas para null 0, usado para anunciar as rotas agregadas. O problema do uso do null 0 é a possível criação de black hole;

  • Redistribuição das rotas estáticas do IGP para o BGP. Não recomendado, pois causa instabilidade e propaga para a Internet as oscilações em rotas internas;

  • Redistribuição de rotas do BGP para o IGP, deve se tomar cuidado pois a tabela BGP é muito grande. Nos AS’s de ISP a redistribuição do BGP normalmente não é requerida.


Manipulação de Tráfego
Filtros de AS-Path - Muitas das coisas feitas em BGP é baseado na construção desses filtros. Ele cria um filtro para selecionar um caminho específico (rotas) através da rede. Funciona como Access-Lists onde o caractere “^” funciona como o início do path e o “$” como o final do path.

  • .*  -  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 )


Community Filters - O atributo Community habilita políticas de roteamento a serem aplicadas para o destino.

Pode-se criar communities de acordo com o tráfego que deseja-se anunciar para os peers ou usar algumas communities pré definidas:

  • No-export – Não anuncia para eBGP peers;

  • No-advertise – Não anuncia para todos os peers;

  • Internet – Anuncia para a comunidade Internet.

  • Método de se agrupar rotas com políticas comuns de roteamento;

  • Uma rota pode fazer parte de várias communities;

  • RFC 1997 – Descreve ações pré definidas;

  • 32 bits, sendo 16 bits para a AS e outros 16 específicos.


Route-map

  • Conjunto de instâncias numeradas;

  • Maior facilidade para criação e edição de conjuntos de comandos;

  • Normalmente cada instância é composta de comandos “match” e/ou “set”;

  • Pode se editar cada instância sem influenciar as demais da Route-map;

  • O número seqüencial padrão é 10, esses números são automáticos de 10 em 10 para cada regra;

  • Possui um Deny-all no final de cada lista;

  • Se uma entrada for criada sem permit ou Deny, o permit é colocado por padrão.


Prefix List - É uma política de controle que restringe as informações de roteamento que o IOS aprende ou anuncia.

Características:

  • Performance significante;

  • Suporta modificações incrementais;

  • Linha de comando mais amigável;

  • Maior flexibilidade;

  • Uma lista de prefixo vazia permite tudo;

  • Se um prefixo for permitido a rota é usada, caso contrario a rota não é usada;

  • O router inicia a pesquisa por uma coincidência na parte superior da lista, a qual é o numero de seqüência mais baixo;

  • Se ocorrer uma coincidência o router não procura o resto da lista;

  • Negativa implícita ocorre quando o prefixo não coincide com nada;

  • Deve ser numerada manualmente sendo o primeiro numero é automaticamente o 5


Cenário

Objetivo
Seis roteadores (R1, R2, R3, R4, R5 e R6) são conectados fisicamente R1-R2-R3-R4-R5-R6-R1 e devem ser configurados com roteamento BGP seguindo os criterios abaixo:

  • Os roteadores R1, R2 e R3 possuem como IGP o OSPF na área 0 divulgando suas interfaces físicas;

  • Os roteadores R4, R5 e R6 possuem como IGP o ISIS, Level-2 somente, na área 49.0456 divulgando suas interfaces físicas;

  • O R1 (AS 123) faz conexão EBGP com o R4 (AS 456);

  • O R3 (AS 123) faz conexão EBGP com o R6 (AS 456);

  • Os roteadores R2 e R4 deverão ser Router-reflectors dos seus respectivos AS;

  • O router-ID de todos os roteadores é o endereço IP das loopbacks;

  • Somente as interfaces loopbacks deverão ser divulgadas no BGP em todos os roteadores;

  • Os roteadores de borda do AS 123 deverão ser o next-hop para as rotas externas.


Topologia

BGP-basico

 

IOS utilizados

  • R1, R2, R3, R4, R5 e R6 – c7200-js-mz.123-7.T.bin


Configuração dos Roteadores
Em todos os roteadores, antes de configurar o roteamento BGP, deve-se configurar o IGP, ou seja, o roteamento interno para que os roteadores possam conhecer o endereço IP para fechar a conexão BGP e também para que a rota seja divulgada na tabela de roteamento BGP. Esse IGP pode ser OSPF, ISIS, estático, etc.

Configurações do OSPF
Para o OSPF a configuração é feita pelo comando “router ospf ” onde o “processo” é um numero do processo OSPF. Para adicionar interfaces usa-se o comando “network
area ”. Para o roteador fazer vizinhança OSPF é necessário que a rede da interface esteja no comando “network” e a interface não esteja configurada como “passive-interface”.

As interfaces de borda dos roteadores de borda são configuradas como “passive-interface” dentro das configurações de roteamento.

Configurações do ISIS
Para o ISIS, independente da área e level, é configurado pelo comando “router Isis” e não possui o número de área no comando principal como o OSPF. Na configuração de roteamento é adicionado o endereço NSAP, que é o endereço único do roteador no ISIS configurado pelo comando “net” com o formato “49.XXXX.0000.0000.000Y.00. O “49” indica ser uma área privada e o “Y” um valor diferente dos demais roteadores.

Por padrão, todos os roteadores são Level-1-2. Deve-se alterar o level do roteador dentro do “router Isis” ou nas interfaces.

As interfaces de borda dos roteadores de borda são configuradas como “passive-interface” dentro das configurações de roteamento.

Configurações do BGP
Voltando ao BGP, agora que os roteadores conhecem os endreços IPs de seus vizinhos pelo IGP, configura-se o BGP em todos os roteadores pelo comando “router bgp ” onde o “AS” é o Autonomous System do provedor. Dentro da configuração de BGP adicionam-se os vizinhos estaticamente com o comando “neighbor remote-as ”, onde se o “as_vizinho” for igual ao AS do roteador a conexão é IBGP, se for diferente será EBGP.

Adiciona-se o IP da interface loopback como Router-ID pelo comando “router-id ”. Para divulgar rede no BGP é necessário que a rede exista na tabela de roteamento interna adicionando o comando “network mask ” ou redistribuindo rotas para o BGP com o comando “redistribute”.

Os roteadores dentro do mesmo AS não divulgarão as rotas IBGP entre eles, pois o BGP só divulga para o vizinho rotas aprendidas por EBGP, ou seja, rotas externas. Para isso configura-se os roteadores centrais como Router-reflectors adicionando os demais roteadores como clientes pelo comando “neighbor router-reflector-client”.

Para que os roteadores de borda sejam o next-hop das rotas externas, usa-se o comando “neightbor next-hop-self”, assim as rotas são divulgadas com endereço de destino interno ao AS.

As configurações de BGP atualmente podem ser feitas dentro da família de endereçamento IPv4, ou seja, dentro da configuração de roteamento entra-se no “address-family ipv4” e configuram-se as vizinhanças, router-reflector, community, route-map, etc.

Observações e Bugs
Observe as tabelas de roteamento e o caminho das rotas.

Documentação: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml
Comandos Importantes de Verificação
R5#show ip bgp

BGP table version is 7, local router ID is 5.5.5.5

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path

* i1.1.1.1/32       36.36.36.3               0    100      0 123 i

*>i                 14.14.14.1               0    100      0 123 i

* i2.2.2.2/32       36.36.36.3               0    100      0 123 i

*>i                 14.14.14.1               0    100      0 123 i

* i3.3.3.3/32       36.36.36.3               0    100      0 123 i

*>i                 14.14.14.1               0    100      0 123 i

*>i4.4.4.4/32       45.45.45.4               0    100      0 i

*> 5.5.5.5/32       0.0.0.0                  0         32768 i

*>i6.6.6.6/32       56.56.56.6               0    100      0 i

R2#show ip bgp summary

BGP router identifier 2.2.2.2, local AS number 123

BGP table version is 14, main routing table version 14

6 network entries using 678 bytes of memory

9 path entries using 432 bytes of memory

4/3 BGP path/bestpath attribute entries using 464 bytes of memory

1 BGP AS-PATH entries using 24 bytes of memory

0 BGP route-map cache entries using 0 bytes of memory

0 BGP filter-list cache entries using 0 bytes of memory

BGP using 1598 total bytes of memory

BGP activity 9/3 prefixes, 12/3 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

12.12.12.1      4   123      21      28       14    0    0 00:12:06        4

23.23.23.3      4   123      24      32       14    0    0 00:08:53        4

R2#show ip bgp neighbors 12.12.12.1 advertised-routes

BGP table version is 14, local router ID is 2.2.2.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path

*>i1.1.1.1/32       12.12.12.1               0    100      0 i

*> 2.2.2.2/32       0.0.0.0                  0         32768 i

*>i3.3.3.3/32       23.23.23.3               0    100      0 i

*>i4.4.4.4/32       14.14.14.4               0    100      0 456 i

*>i5.5.5.5/32       14.14.14.4               0    100      0 456 i

*>i6.6.6.6/32       14.14.14.4               0    100      0 456 i

R2#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets

B       1.1.1.1 [200/0] via 12.12.12.1, 00:12:20

2.0.0.0/32 is subnetted, 1 subnets

C       2.2.2.2 is directly connected, Loopback0

3.0.0.0/32 is subnetted, 1 subnets

B       3.3.3.3 [200/0] via 23.23.23.3, 00:12:24

4.0.0.0/32 is subnetted, 1 subnets

B       4.4.4.4 [200/0] via 12.12.12.1, 00:01:27

5.0.0.0/32 is subnetted, 1 subnets

B       5.5.5.5 [200/0] via 12.12.12.1, 00:01:27

36.0.0.0/24 is subnetted, 1 subnets

O       36.36.36.0 [110/2] via 23.23.23.3, 00:21:44, FastEthernet1/0

6.0.0.0/32 is subnetted, 1 subnets

B       6.6.6.6 [200/0] via 12.12.12.1, 00:01:27

23.0.0.0/24 is subnetted, 1 subnets

C       23.23.23.0 is directly connected, FastEthernet1/0

12.0.0.0/24 is subnetted, 1 subnets

C       12.12.12.0 is directly connected, FastEthernet0/0

14.0.0.0/24 is subnetted, 1 subnets
Configuração

R1






!router ospf 1

passive-interface FastEthernet1/0

network 12.12.12.0 0.0.0.255 area 0

network 14.14.14.0 0.0.0.255 area 0

!

router bgp 123

bgp router-id 1.1.1.1

network 1.1.1.1 mask 255.255.255.255

neighbor 12.12.12.2 remote-as 123

neighbor 12.12.12.2 next-hop-self

neighbor 14.14.14.4 remote-as 456

!

R2






!router ospf 1

network 12.12.12.0 0.0.0.255 area 0

network 23.23.23.0 0.0.0.255 area 0

!

router bgp 123

bgp router-id 2.2.2.2

network 2.2.2.2 mask 255.255.255.255

neighbor 12.12.12.1 remote-as 123

neighbor 12.12.12.1 route-reflector-client

neighbor 23.23.23.3 remote-as 123

neighbor 23.23.23.3 route-reflector-client

!


R3








!router ospf 1

passive-interface FastEthernet0/0

network 23.23.23.0 0.0.0.255 area 0

network 36.36.36.0 0.0.0.255 area 0

!

router bgp 123

bgp router-id 3.3.3.3

network 3.3.3.3 mask 255.255.255.255

neighbor 23.23.23.2 remote-as 123

neighbor 23.23.23.2 next-hop-self

neighbor 36.36.36.6 remote-as 456

!


R4








!clns filter-set AS-456 permit 49.0456.****.****.****.**

!

interface FastEthernet0/0

ip router isis

isis adjacency-filter AS-456

!

interface FastEthernet1/0

ip router isis

isis adjacency-filter AS-456

!

router isis

net 49.0456.0000.0000.0004.00

is-type level-2-only

passive-interface FastEthernet1/0

!

router bgp 456

bgp router-id 4.4.4.4

network 4.4.4.4 mask 255.255.255.255

neighbor 14.14.14.1 remote-as 123

neighbor 45.45.45.5 remote-as 456

!


R5








!clns filter-set AS-456 permit 49.0456.****.****.****.**

!

!

interface FastEthernet0/0

ip router isis

isis adjacency-filter AS-456

!

interface FastEthernet1/0

ip router isis

isis adjacency-filter AS-456

!

router isis

net 49.0456.0000.0000.0005.00

is-type level-2-only

!

router bgp 456

bgp router-id 5.5.5.5

network 5.5.5.5 mask 255.255.255.255

neighbor 45.45.45.4 remote-as 456

neighbor 45.45.45.4 route-reflector-client

neighbor 56.56.56.6 remote-as 456

neighbor 56.56.56.6 route-reflector-client

!


R6








!clns filter-set AS-456 permit 49.0456.****.****.****.**

!

!

interface FastEthernet0/0

ip router isis

isis adjacency-filter AS-456

!

interface FastEthernet1/0

ip router isis

isis adjacency-filter AS-456

!

router isis

net 49.0456.0000.0000.0006.00

is-type level-2-only

!

router bgp 456

bgp router-id 6.6.6.6

network 6.6.6.6 mask 255.255.255.255

neighbor 36.36.36.3 remote-as 123

neighbor 56.56.56.5 remote-as 456

!

 

Fonte: http://babarata.blogspot.com.br/2010/05/bgp-basico_28.html