A utilização de um Roteador como “Router Reflector” permite que os prefixos aprendidos via iBGP de seus “Clientes” sejam anunciados para outros “vizinhos” iBGP.
O algoritmo do BGP não permite que rotas aprendidas via iBGP sejam anunciadas para Roteadores vizinhos. Em um cenário comum os Roteadores dentro do AS precisam precisam de uma conexão full mesh com os outros Roteadores. Conforme ocorre o crescimento da rede, o numero de peering, sessões BGP, entre os dispositivos torna-se bastante volumoso. O peering com o RRs (Router Reflectors) então minimiza o numero de sessões iBGP, sendo necessário apenas o peering com os RRs.
O site da RNP nos dá a seguinte definição para o assunto:
“Usando routereflection, determinados roteadores IBGP podem redistribuir rotas a vizinhos IBGP, possibilitando a todos os roteadores de um AS terem o conhecimento de todas as rotas, sem a necessidade de configuração de um fullmeshIBGP.”
A RFC 2796 (BGP Route Reflection) dá a seguinte regra para os Router Reflectors:
1) A Rota de um Non-Client IBGP peer:Reflete para todos os RR Clients.
2) A Rota de um Client IBGP peer:Reflete para todos Non-Clients peers e também para os RR Clients .
Para tirar algumas dúvidas de conceito, simulamos alguns cenários com a “regra” para Reflexão de Rotas para os prefixos aprendidos via RR Clients, non-Client e Router Reflector (Server). Alguns cenários podem parecer um pouco óbvios, mas são de grande ajuda quando se utiliza-se em cenários mais complexos. Em todos os casos o next-hop do prefixo segue a regra normal de um peering iBGP, isto é, não é alterado.
Lembrando que todas as conexões abaixo entre os 3 Roteadores são via iBGP, os supostos prefixos aprendidos são de Roteadores “ocultos” a topologia e as questões de next-hop dos prefixos estão resolvidas pelo IGP .
O professor Adilson Florentino lançou esse mês um livro bastante interessante sobre IPv6 (em português) com uma linguagem bem acessível e amigável. A cada dia mais encontramos escritores brasileiros escrevendo bons materiais técnicos para a área de TI tanto em inglês como em português.
O material vem em boa hora, visto que, os últimos blocos IPv4 foram entregues e o mercado precisará se adaptar a esse novo cenário.
Para quem desejar mais informações sobre o Adilson é possível encontrar diversos textos em seu blog http://netfindersbrasil.blogspot.com.br/ inclusive comprar o livro com desconto e assinatura direto do site do autor.
Dias atrás citei no Blog sobre o treinamento de atualização para as técnicas de transição para IPv6 que NIC.br ofereceu. O bacana é que o evento foi filmado e o conteúdo está disponível em capítulos no Zappiens. Vale a pena “perder” algumas horas assistindo os vídeos produzidos para IPv6 disponíveis no site.
O termo “openflow” tem sido cada vez mais abordado em sites de Tecnologia de Redes, Pesquisa, Trabalhos de Universidades e Datacenters. O Openflow é um padrão em desenvolvimento para a administração de Redes LAN e WAN com foco em equipamentos comerciais como Switches, Roteadores, Access Points, etc.
A idéia é bem simples, trazer o plano de Gerenciamento de todos dispositivos da rede para um único software que será responsável por criar VLANs, Roteamento, QoS e etc. (O protocolo não possui parentesco com o Netflow ou o Sflow)
A grande sacada do Openflow é permitir o trabalho com dispositivos de diversos fabricantes que suportem o padrão de forma que se possa incluir novas features e protocolos a partir do plano de Controle independente do hardware/software do Switch, manipulando o plano de dados e/ou encaminhamento desses dispositivos (chamado de flow-table); trazendo o conceito de Sistema Operacional de Rede, utilizado para realizar um gerenciamento centralizado, assim como faz uma Controladora wireless para os AP’s. Com isso termos como SDN (Software Defined Networking) ganham grande importância no assunto.
Essas funcionalidades torna possível a criação de um sistema operacional de rede que abstrai as inúmeras particularidades dos equipamentos e a grande complexidade dos sistemas, assim como o Linux e o Windows fazem em computadores pessoais.
O OpenFlow nos permite controlar o fluxo de cada tráfego de rede – escolhendo as rotas que seus pacotes deverão seguir e o processamento que receberão. Desta forma, o torna-se possível experimentar novos protocolos, novos modelos de segurança, e/ou novos esquemas de endereçamento, novos protocolos de rede, sem afetar a rede em produção, podendo-se segmentar/fatiar a rede em produção para testes, simulações e segmentações.
Diversos fabricantes como Arista Networks, Big Switch Networks, Cisco, Embrane, IBM, Juniper, Nicira e NEC trabalham em projetos envolvendo o protocolo, inclusive alguns desses fabricantes já possuem Switches no mercado com suporte ao protocolo.
Hoje vamos abordar um assunto bastante “conhecido” para técnicos, analistas e engenheiros de Rede, mas que dependendo da técnica/modelo utilizado pode tornar-se extremamente complexo, o NAT.
A RFC1918 cita o uso dentro do range 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16 em redes locais (LAN); e que não devem ser roteados pela Internet, chamado também de endereços privados.
Porém os pacotes com endereços privados podem ser roteados dentro de redes privadas(LAN). Diferente dos endereços IP públicos (endereços IP na Internet), os endereços privados são um bloco reservado que pode ser usados em qualquer rede.
Essa divisão foi desenvolvida para preservar a estrutura de endereços da Internet, pois não existem endereços públicos suficientes para permitir que as organizações forneçam um IP “valido” para cada computador.
Observando esse cenário precisamos que um mecanismo traduza os endereços privados para endereços públicos tanto para tráfegos de entrada quanto para tráfegos de saída, e ai que entra o NAT ( Network Address Translation).
Geralmente, os dispositivos configurados para fazer o NAT retêm menos endereços IP disponíveis para aquela empresa usar na Internet do que a quantidade de máquinas e Serviços que precisam de acesso à Internet. Quando um host enviar pacotes para a Internet, o NAT traduzirá o endereço IP interno (privado) para um endereço externo (publico). Todo esse processo é transparente para dispositivos em redes remotas, como por exemplo, um site na Internet (quando um pacote chegar a uma rede remota chegará com o endereço de origem “valido”).
Apesar de bem questionável, mas efetivo na maioria dos casos, a técnica de NAT também é usada como ferramenta de segurança para mascarar endereços de máquinas na rede local, via rede publica.
O NAT pode ser comparado em alguns casos como uma telefonista de uma Empresa. Imagine que nenhum funcionário possa efetuar ligações externas sem solicitar que a telefonista o faça; e que essa telefonista foi instruída a não encaminhar ligações para nenhum funcionário sem a identificação da pessoa externa que está procurando um funcionário da empresa.
Então, quando uma pessoa entra em contato com número da empresa, que é o único número que ele conhece, pede à recepcionista o nome de quem ele(a) procura e consequentemente a recepcionista verificará em sua tabela de ramal o numero corresponde a seu nome e transferirá a chamada. Configurando o NAT
Nesse primeiro post mostraremos um exemplos da técnica de NAT estático que permite um mapeamento permanente entre um endereço interno e um endereço público específico.
Exemplo:
Abaixo o script com as configurações necessárias para tradução do cenário acima.
ip nat inside source static 172.16.20.2 200.0.0.10
! Configurando o mapeamento do IP de origem "original" e o endereço IP que será traduzido
interface Fast 0/0ip address 172.16.20. 1 255.255.255.0
ip nat insideno shutinterface serial0/1ip address 200.0.0.1 255.255.255.0
ip nat outsideno shut
Output do comando show ip nat trasnslation no Roteador R1 durante uma conexão Telnet /ICMP iniciada pelo o Host 172.16.20.2 para o Servidor na Intenet 200.200.200.200
R1#show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 200.0.0.10:21 172.16.20.2:21 200.200.200.200:21 200.200.200.200:21
icmp 200.0.0.10:22 172.16.20.2:22 200.200.200.200:22 200.200.200.200:22
icmp 200.0.0.10:23 172.16.20.2:23 200.200.200.200:23 200.200.200.200:23
icmp 200.0.0.10:24 172.16.20.2:24 200.200.200.200:24 200.200.200.200:24
— 200.0.0.10 172.16.20.2 — —
tcp 200.0.0.10:1025 172.16.20.2:1025 200.200.200.200:23 200.200.200.200:23
no meu próximo post falarei sobre NAT dinâmico, espero que tenham gostado.
Outro dia me deparei com a situação de se criar um site backup para um grande Datacenter, neste artigo venho apresentar conceitos básicos que deverão ser analisados quando se precisa deste tipo de solução. Vamos supor que a empresa RotaDefault tenha uma aplicação de missão critica chamada rdef está aplicação é utilizada por usuários de várias filiais de nosso empresa que se conectam ao Datacenter RotaDefault via uma UP (Unidade Provedora) proprietária e ou contratada de alguma operadora qualquer.
A solução de site backup visa prover disponibilidade para o negócio rdef da empresa Rota Default e também deverá ter transparência para seus clientes quando o Datacenter principal ficar indisponível e o Datacenter backup assuma as requisições a aplicação rdef (de nosso exemplo) de forma automática e com baixo impacto para o usuário.
O crescimento da Infra-Estrutura acompanha o crescimento do negócio. O sucesso do negócio rdef não é afetado por problemas no Datacenter, porém de acordo com os serviços disponibilizados, em uma nova fase poderá ser necessário realizar um Upgrade no link ponto a ponto entre os prédios.
Toda Infra-Estrutura será montada de acordo com a parte relevante que atende ao negocio e desta forma poderemos manter o plano de endereçamento atual e as liberações de firewall controladas de acordo o site principal.
Ambos os sites irão possuir links redundantes que atuarão como UP (Unidade Provedora) para as filiais do Rotadefault provendo assim o negocio; Possuirão também links ponto a ponto redundantes que irão possibilitar a replicação dos dados e ou gravação simultânea dos registros inseridos no rdef. Desta forma A UP Secundaria sempre estará atualizada.
Topologia ilustrativa da solução
Infra-Estrutura básica para atender DATACENTER redundante
Os serviços disponibilizados no site backup necessitarão de:
Infra-Estrutura física e lógica similar ao DATACENTER principal
Possibilidade de aumento de Banda, mediante termo aditivo ao Contrato da operadora do link
Solução multi-layer, com possibilidade de expansão
Ativação de UP Secundária
Ativação de Link ponto a ponto entre site principal e site backup
Monitoramento de rede pró-ativo
Suporte técnico 24 x 7 x 365
Serviços de Backup com armazenamento de mídia em área segura
Firewalls assegurando proteção da rede
Acesso de pessoal restrito com alto nível de controle
A instalação física e lógica compreende a execução dos procedimentos técnicos necessários à preparação e à operacionalização da solução sendo que qualquer modificação e/ou adaptação da infra-estrutura física, lógica deverá obedecer às normas técnicas ABNT e da EIA/TIA aplicáveis. Lembrando que temos as seguintes situações:
Estrutura Física
Ambiente localizado longe do DATACENTER principal
Rede elétrica estabilizada e redundante
Roteadores
Switches
Firewalls
Cabeamento Estruturado
Servidores
Estrutura Lógica
Contratação de uma UP (Unidade Provedora) secundaria da rede de dados
Contratação de um Link ponto a ponto entre Matriz e site Backup para realizar a replicação dos dados
A operadora (órgão provedor do link ponto a ponto) precisara prover Infra-Estrutura técnica de DCI (Data Center InterConnect)
Esses dias o pessoal o NIC.br ofereceu um treinamento de atualização para as técnicas de transição do Protocolo IP para IPv6. O evento foi carinhosamente chamado de Café com IPv6.
Como o material é Creative Commons, efetuei abaixo alguns recortes do texto sobre a técnica de Pilha Dupla; diversos materiais podem ser encontrados no site http://www.ipv6.br/ . Boa leitura:
A importância deste tópico vem do fato de o IPv4 e o IPv6 não serem diretamente compatíveis entre si. O IPv6 não foi projetado para ser uma extensão, ou complemento, do IPv4, mas sim um substituto que resolve o problema do esgotamento de endereços.Embora não interoperem, ambos os protocolos podem funcionar simultaneamente nos mesmos equipamentos e com base nisto a transição foi pensada para ser feita de forma gradual.
No projeto inicial do IPv6, uma vez que o protocolo estivesse pronto, sua implantação começaria a ser feita gradualmente na Internet, de forma que funcionasse simultaneamente ao IPv4. A isso chamamos de pilha dupla, ou dual stack. Quando o IPv6 estivesse implantado em todos os dispositivos, o IPv4 deixaria de ser realmente útil e poderia ser abandonado paulatinamente.
No período de implantação do IPv6 haveria necessidade de técnicas auxiliares de transição, inicialmente para interconectar ilhas IPv6 em uma Internet majoritariamente IPv4 e, depois de algum tempo, para fazer o contrário. A transição feita desta forma seria muito simples de ser executada tecnicamente. Contudo, por diversas razões, não foi o que aconteceu. Atualmente o IPv6 ainda não está sendo amplamente utilizado na Internet e o esgotamento do IPv4 já se tornou uma realidade.
Hoje existe a necessidade de se implantar o IPv6 numa Internet sempre crescente, onde os novos usuários ainda precisam de conectividade IPv4, mas não há mais endereços IPv4 livres para atendê-los. Assim, novas técnicas auxiliares foram e continuam sendo,desenvolvidas para essa nova realidade.
Pode-se, então, classificar as técnicas de transição segundo sua funcionalidade, em:
Pilha dupla: consiste na convivência do IPv4 e do IPv6 nos mesmos equipamentos,de forma nativa, simultaneamente. Essa técnica é a técnica padrão escolhida para a transição para IPv6 na Internet e deve ser usada sempre que possível.
Túneis: Permitem que diferentes redes IPv4 comuniquem-se através de uma rede IPv6, ou viceversa.
Tradução: Permitem que equipamentos usando IPv6 comuniquem-se com outros que usam IPv4, por meio da conversão dos pacotes.
Pilha Dupla: IPv6 e IPv4 em todos os dispositivos
A utilização deste método permite que dispositivos e roteadores estejam equipados com pilhas para ambos os protocolos, tendo a capacidade de enviar e receber os dois tipos de pacotes, IPv4 e IPv6. Com isso, um nó Pilha Dupla, ou nó IPv6/IPv4, se comportará como um nó IPv6 na comunicação com outro nó IPv6 e se comportará como um nó IPv4 na comunicação com outro nó IPv4.
Cada nó IPv6/IPv4 é configurado com ambos endereços, utilizando mecanismos IPv4 (ex.DHCP) para adquirir seu endereço IPv4 e mecanismos IPv6 (ex. configuração manual, autoconfiguração stateless e/ou DHCPv6) para adquirir seu endereço IPv6.
Este método de transição permite uma implantação gradual, com a configuração de pequenas seções do ambiente de rede de cada vez. Além disso, caso no futuro o IPv4 não seja mais usado, basta simplesmente desabilitar a pilha IPv4 em cada nó.
Em relação ao DNS, é preciso configurar os novos endereços IPv6, usando registros do tipo AAAA (quadA), que armazenam seus endereços. Para mais detalhes sobre o suporte do DNS ao IPv6, consulte a RFC 3596.
Responder os endereços IPv6 (registros AAAA) quando disponíveis para um determinado nome de domínio é o comportamento padrão do servidor DNS, mesmo que ele opere apenas com IPv4. O protocolo por meio do qual é feita a consulta não interfere na resposta. Ao receber endereços IPv6 e IPv4 como resposta a uma consulta no DNS a aplicação decide qual protocolo usar. Normalmente a preferência é pelo protocolo IPv6 e, em caso de falha, tenta-se o IPv4. Mais recentemente têm sido experimentadas técnicas que implicam em tentativas simultâneas de conexão IPv6 e IPv4 e optam pela que for mais rápida (draftietfv6opshappyeyeballs07).
Em uma rede com pilha dupla, a configuração do roteamento IPv6 normalmente é independente da configuração do roteamento IPv4. Isto implica no fato de que, se antes de implementar-se o IPv6 a rede utilizava apenas o protocolo de roteamento interno OSPFv2 (com suporte apenas ao IPv4), será necessário migrar para um protocolo de roteamento que
suporte tanto IPv6 quanto IPv4 (como ISIS por exemplo) ou forçar a execução do OSPFv3 paralelamente ao OSPFv2.
É importante reforçar que configurações independentes para IPv4 e IPv6 são necessárias para diversos aspectos da rede, entre eles:
Informações nos servidores DNS autoritativos;
Protocolos de roteamento;
Firewalls;
Gerenciamento das redes.
Utilizar pilha dupla pode não ser possível em todas as ocasiões. Por exemplo, quando não há mais IPv4 disponíveis e o provedor precisa atender a usuários novos com IPv6 e IPv4.
Para redes corporativas que já utilizam NAT isso não é um impendimento: o IPv6 nativo pode ser utilizado em conjunto com o IPv4 compartilhado. Outra situação que dificulta a implantação do IPv6 usando pilha dupla é a existência de equipamentos que não o suportam e que não podem ser facilmente substituídos.Nesse caso deveremos utilizar outras técnicas de transição.
Amigos, disponibilizamos para a compra o nosso primeiro eBook (no formado PDF) que chamamos de “Guia Básico para Configuração de Switches“. Tentamos gerar uma material para suprir a carência no mercado de livros sobres Switches dos fabricantes 3Com, H3C e HP em português.
Além disso, esperamos que o eBook seja uma ferramenta de apoio para continuarmos com os Serviços oferecidos nos Blogs (comutadores.com.br e rotadefault.com.br) e que de forma direta e/ou indireta nos impulsione novos Projetos.
O “Guia” aborda assuntos já citados aqui no Blog, mas com um foco mais didático para administração de Switches com o Sistema Operacional Comware (3Com, H3C e HP Serie-A e alguns da Serie-E), configuração de VLANs, portas Access, Trunk, Hybrid, GVRP e Roteamento entre VLANs…. incluindo pequenos laboratórios com soluções para elucidar os exemplos:
Introdução aos Switches
Configurações Básicas
VLANs
Portas Access, Trunk e Híbrida
GVRP
Roteamento entre VLANs
A escolhemos o PagSeguro como ferramenta pela facilidade no cadastro e o suporte para pagamentos via Boleto, transferências de Pontos, transferências Bancária e Cartão de Crédito.
Após a conclusão da compra e a confirmação do PagSeguro , encaminharemos o eBook para o email cadastrado no site.
A agregação de diversas interfaces Ethernet (portas físicas) para a utilização de uma única porta lógica com o intuito de prover redundância e aumento de banda é uma atividade muito comum em redes de médio e grande porte .
Infelizmente o nome atribuído pelos fabricantes não segue um padrão, mas por outro lado todos possuem as mesmas funções citadas anteriormente: Etherchannel, Port-channel, Link-Aggregation, Bridge-Aggregation, Trunk [ nome dado antigamente para agregação de portas.(Não confundam com a utilização de interface Trunk atribuída pelos Switches Cisco e 3Com. Os Switches Procurve ainda utilizam essa terminologia) ] e etc.
Existem algumas formas de estabelecer a agregação de portas, como por exemplo:
- Manual : sem a certificação do meio por protocolos auxiliares
- PAgP : Protocolo disponível em equipamentos Cisco
- LACP : Protocolo padrão IEEE, disponível quase todos Switches gerenciáveis.
Modos de formação de um Etherchannel em Switches Cisco
Cisco(config-if)# channel-group 1 mode ?active Enable LACP unconditionally
auto Enable PAgP only if a PAgP device is detected
desirable Enable PAgP unconditionally
on Enable Etherchannel only
passive Enable LACP only if a LACP device is detected
No Script abaixo mostraremos a configuraçaõ de Link Aggregation/Etherchannel entre um Switch Cisco e um Switch HPN Serie-A
Switch HPN
#
interface Bridge-aggregation 1
link-aggregation mode dynamic
! Estabelecendo a conexão do Link-Aggregation utilizando o protocolo LACP
#
interface gigabitEthernet 1/0/1
port link-aggregation group 1
! Atribuindo a porta para negociar a agregação via protocolo LACP
#
interface gigabitEthernet 1/0/2
port link-aggregation group 1
! Atribuindo a porta para negociar a agregação via protocolo LACP
Switch Cisco
!
interface port-channel 1
!
interface gigabitEthernet 1/10
channel-group 1 mode active
! Estabelecendo a conexão do Etherchannel utilizando o protocolo LACP
!
interface gigabitEthernet 1/11
channel-group 1 mode active
! Estabelecendo a conexão do Etherchannel utilizando o protocolo LACP
!
Comandos show e display
Switches HPN
[HPN]display link aggregation verbose
Aggregation Interface: Bridge-Aggregation1
Aggregation Mode: Dynamic
Loadsharing Type: Shar
System ID: 0x8000, 3822-d6a2-5c00
Local:
Port Status Priority Oper-Key Flag
----------------------------------------------------
GE1/0/1 S 32768 8 {ACDEF}
GE1/0/2 S 32768 8 {ACDEF}
Remote:
Actor Partner Priority Oper-Key SystemID Flag
------------------------------------------------------------
GE1/0/1 516 32768 45 0x8000, 4055-39d4-8e13 {ACDEF}
GE1/0/2 517 32768 45 0x8000, 4055-39d4-8e13 {ACDEF}
Switches Cisco
Cisco#show etherchannel summary
Flags: D - down P - bundled in port-channel
I - stand-alone s – suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use f - failed to allocate aggregator
M - not in use, minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
Number of channel-groups in use: 2
Number of aggregators: 2
Group Port-channel Protocol Ports
------+-------------+-----------+--------------------------
1 Po1(SU) LACP Gi1/10(P) Gi1/11(P)
Não esqueça!!!
Sempre quando for necessario a alteração de VLANs das portas do Link Aggregation/Etherchannel faça a alteração somente na interface virtual ( port channel/ bridge-aggregation), que a configuração será replicada para as interfaces físicas.
Mantenha a consistência de VLANs nas 2 pontas do Link Aggregation/Etherchannel.
Use velocidades de portas idênticas como: interfaces 1Gb com interfaces 1G e interfaces 10Gb com interfaces 10Gb e assim por diante…
Rota default é administrado por Ricardo Pereira, Diego Dias e Roger Sales.
Ricardo é Pós-Graduado em Segurança da Informação, trabalha como Analista de Segurança em Redes de Computadores e possui as certificações CCSP, MSCE Security e ITILv2.
Diego Dias é Tecnólogo em Redes de Computadores, trabalha como Analista de Redes de Computadores e possui as certificações CCNP, HP ASE e ITILv2.
Roger Sales é bacharelando em Ciências da Computação, Analista de Redes de Computadores e possui as certificações CCNA e ITILv2.
.
