A tecnologia MPLS se apresenta como um modelo que oferece diversas aplicabilidades, visto a possibilidade de transportar em seu cabeçalho informações adicionais, como parâmetros de QoS e orientações de tráfego, o que permite aos administradores das redes IPs empregá-lo em diversas finalidades. Atualmente existem algumas aplicações, ou podemos chamar de serviços associados à tecnologia MPLS, que tornam a mesma bastante atrativa aos provedores de serviços, inclusive suprindo a necessidade de um bom desempenho para atendimento a uma gama de serviços oferecidos atualmente pela Internet, tais como aplicações de voz, vídeo, e algumas aplicações críticas corporativas. Portanto, a real motivação para implantação da tecnologia MPLS na rede são as aplicações que ela permite.

Sendo assim, esse post tem a finalidade de tratar alguns dos serviços fundamentais ofertados pela tecnologia MPLS (VPN, QoS, TE e  Pseudowire). Como se trata de um post bastante extenso, mostraremos uma série de 04 ou mais, para que possamos entender como cada serviço trabalha, suas terminologias utilizadas, seus benefícios e suas implementações. O primeiro que trataremos será o serviço de VPN MPLS.

O Serviço VPN MPLS:

O Serviço VPN MPLS é um dos principais serviços oferecidos por essa tecnologia, e faz uso do modelo peer to peer, modelo no qual os roteadores do provedor de serviços formam adjacências de roteamento diretamente com os roteadores dos clientes.

Da perspectiva do roteador do cliente (CE) apenas atualizações de rotas e dados são encaminhados para o roteador de entrada do provedor (PE). Nesse roteador do cliente não é necessário quaisquer configurações da VPN, e sim apenas habilitar um protocolo de roteamento ou efetuar um roteamento estático para que o mesmo troque informações com o PE. Já o roteador PE executa múltiplas funções, pois o mesmo deve ser capaz de isolar o tráfego se mais de um cliente estiver conectado ao mesmo e, para cada cliente, é designada uma tabela de roteamento independente.

O roteamento através do backbone é desempenhado usando um processo de roteamento na tabela de roteamento global.  Esses roteadores de backbone, conhecidos como P (Provider), fazem a comutação de rótulos entre os PEs e não requerem quaisquer configurações de VPN. Os roteadores CEs não conhecem os roteadores Ps, e a topologia interna da rede do provedor é transparente para o cliente, conforme figura abaixo.

Portanto, redes MPLS permitem uma total separação das redes VPNs dos clientes. Essa total divisão se dá pela separação de tabelas de roteamento, plano de endereçamentos e tráfego, logo as VPNs de dois clientes distintos A e B podem possuir planos de endereçamento idênticos, cada um com sua própria tabela de roteamento e de modo que seus tráfegos jamais se misturem. Esse isolamento do tráfego entre os clientes, que é realizado nos roteadores PE, faz uso de um conceito conhecido como tabela de roteamento virtual, também conhecido como virtual routing and forwarding table ou VRF.

Um roteador PE tem uma instância de VRF para cada cliente conectado ao mesmo. A idéia é como se existissem roteadores dedicados para cada cliente que se conecta ao provedor de serviços, porém há o compartilhamento de CPU, largura de banda e recursos de memória com outros roteadores virtuais pertencentes ao mesmo PE. A função de uma VRF é similar a uma tabela de roteamento global, exceto que ela contém todas as rotas pertencentes para uma VPN específica.

É como se estivéssemos “quebrando o roteador” em várias partes e cada parte individualmente estivesse atendendo a um cliente, ou uma VPN, conforme figura logo abaixo. Essa é uma das grandes vantagens desse serviço, pois reduz a quantidade de equipamentos físicos que o provedor necessita disponibilizar.

 Para realizar uma VPN MPLS é necessário o conhecimento de alguns atributos que são utilizados nos roteadores PEs, que são: RD (Route Distinguisher), RT (Route Targets) e MP-BGP (Multi Protocol Border Gateway Protocol). O RD é um identificador único de 64 bits que é inserido na frente do IPv4, portanto sendo único dentro do backbone MPLS. A combinação dos endereçamentos IPv4 e esses identificadores de rotas, conhecido como endereço VPNv4,  fazem com que as rotas IPv4 sejam únicas através da rede VPN MPLS, dessa forma é possível aos clientes de diferentes VPNs o uso dos mesmos endereços privados.

O protocolo usado para trocar essas rotas VPNv4 entre os roteadores PEs é o multiprotocol BGP (MP-BGP). O RT (Route Target) é um atributo que indica uma coleção de VRFs pelo qual um roteador PE irá distribuir as rotas, ou seja, ele indica quais rotas devem ser importadas e exportadas pelo MP-BGP, permitindo assim que possa haver conversação entre diferentes VRFs, e que também possa ser feito restrições de importação e exportação de rotas.

As VPNs constituem um dos principais serviços oferecidos aos seus clientes para interligação das suas redes locais. As VPNs MPLS provêem uma rede de transporte com segurança, confiança, comportamento previsível e menor custo.

No próximo post, exibiremos um teste prático de VPN MPLS com uso de um Lab montado no Dynamips.

Fonte: Luc De Ghein, MPLS Fundamentals, Cisco Press.

Popularity: 5% [?]

Pessoal, este assunto surgiu ontem no curso CCNP ROUTE, na segunda aula de EIGRP ministrada pela Adilson. Passada a aula, o Adilson postou esta informação no Fórum de aula, que achei que valia replicar em forma de post, já que imagino que muitos não saibam disso… repasso, então, o post de autoria do Adilson Florentino:

A RFC 3021 descreve o uso de prefixos com 31 bits em links ponto-a-ponto. Isto reserva apenas um bit para a porção de host. Desta forma, o valor 0 representa o host de uma ponta e o valor 1 representa o outro host da conexão.

Quando se tem uma quantidade muito grande de links ponto-a-ponto, o desperdício de endereços é de 50% (perde-se um endereço de sub-rede e um de broadcast a cada link). Para se resolver isto, geralmente deixava-se a interface sem IP com o recurso IP UNNUMBERED, o que não é interessante do ponto de vista do gerenciamento da rede.

Com a máscara 255.255.255.254 Broadcasts locais (255.255.255.255) ainda são possiveis, mas broadcasts direcionados a uma determinada sub-rede não são mais possíveis com este tipo de máscara. (o que não é um problema pois muitos protocolos de roteamento utilizam multicast, broadcasts direcionados ou multicast).

A seguir, um exemplo de configuração num link PPP point-to-point:

!
interface Serial5/1
ip address 172.16.70.2 255.255.255.254
no ip directed-broadcast
!

Uma grande vantagem com este tipo de máscara é ficar imune a certos tipos de ataque, como Spoof, Smurf, que utilizam broadcasts direcionados para explorar vulnerabilidades. No exemplo abaixo, um trecho da configuração do recurso VPN Client in Client Mode em um router 806, a máscara /31 é usada:

!
interface Ethernet1
ip address 192.168.87.252 255.255.255.254
crypto ipsec client ezvpn test
Assigns the Easy VPN configuration to the interface.
!

Para se ter uma visão mais detalhada do uso dos Ips /31, sugiro a consulta dos links abaixo:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f33.shtml#using31bit
http://www.ietf.org/rfc/rfc3021.txt
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t2/feature/guide/ft31addr.html
http://www.informit.com/library/content.aspxb=Troubleshooting_Remote_Access&seqNum=163

Popularity: 3% [?]

Este post está um pouco atrasado com relação à notícia (que saiu em Janeiro de 2010), mas acabei nem me preocupando pois o assunto foi exaustivamente discutido no Fórum do blog. O problema é que vejo que muitos ainda estão com dúvidas sobre o que mudou e como ficam as coisas. Achei melhor escrever este post para esclarecer as coisas.

Basicamente, a Cisco divulgou alterações na estrutura de sua certificação CCNP em Janeiro passado. Saem os exames 642-901 BSCI (antiga Routing), 642-812 BCMSN (antiga Switching), 642-825 ISCW e 642-845 ONT. Cada uma destas estarão disponíveis para realização até 31/07/2010 para não alunos do NetAcad CCNP. Quem for aluno (ou ex-aluno) do NetAcad CCNP, valem as seguintes datas: ISCW e ONT disponiveis até Março de 2011 e BSCI e BCMSN disponiveis até Junho de 2011.

Os novos exames (válidos desde já, para quem se habilitar), são: ROUTE (642-902), SWITCH (642-813) e TROUBLESHOOT (642-832). Os valores dos exames também mudaram. Antes, cada prova custava US$150 (4 x US$150 = US$600). Agora, cada exame custa US$200 (3 x US$200 = US$600), ou seja, no fundo, financeiramente deu na mesma: Total de US$600 para certificar-se CCNP, com um exame a menos.

Em termos de mudanças, quem é mais vivo já percebeu que BSCI virou ROUTE e BCMSN virou SWITCH. Os conteúdos não devem sofrer grandes alterações, ou seja, se você já estava estudando para estas provas, não vai ser prejudicado. Uma novidade é que IS-IS deixa de ser tópico da BSCI, o que pode ser uma notícia muito bem-vinda para alguns ! Parece que multicast também deixa de fazer parte do “syllabus” - relação dos tópicos cobrados - do exame ROUTE.

Lembro que estas mudanças afetam também outras certs que têm algumas provas em comum com o CCNP, como o CCIP, que divide com o CCNP a prova BSCI (agora, ROUTE), e o CCDP, que divide as provas BSCI (ROUTE) e BCMSN (SWITCH).

A Cisco disponibiliza uma ferramenta online para verificar as combinações de exames possíveis neste novo cenário. Basta acessar e “brincar” um pouco com ela. Abaixo, listo os tópicos por novo exame.   Leia o resto deste Post »

Popularity: 3% [?]

Tenho certeza que alguns aqui já estavam sentindo falta de posts mais técnicos… ! Bom, vamos lá, então! Este tópico é um pouco avançado, mas bastante interessante. Alguns aqui já devem ter ouvido falar da sigla PBR. PBR significa Policy-based Routing, ou roteamento baseado em políticas. E o que seriam estas “políticas”? Nada mais do que regras…! O modo tradicional de roteamento dita que um router irá encaminhar um pacote para a interface de saída que conste em sua tabela de roteamento como destino para a rede presente no campo “Destination”, no cabeçalho do pacote. Ou seja, o router apenas examina o endereço IP de destino, verifica sua tabela e, se a rede em questão for conhecida ele irá encaminhar o pacote para a interface de saída. Se não for conhecida (e não existir uma rota menos específica ou uma rota default), o router irá descartar o pacote.

Graficamente, o processo padrão de roteamento é ilustrado no diagrama abaixo.

Neste caso, quando um pacote é originado na rede 10 com destino à rede 30, o mesmo é encaminhado aos roteadores existentes no caminho e estes examinam o destino em suas tabelas de roteamento. No retorno, as coisas se invertem… o que era destino (rede 30) passa a ser origem, e o que era origem (rede 10) passa a ser destino. O processo se repete no caminho de volta.

Agora, vamos complicar um pouco… suponha o diagrama abaixo, uma elaboração da rede anteriormente apresentada:

Vamos imaginar que, na rede 10, eu tenha 2 PCs (PC1 em amarelo e PC2, em verde), e que eu queira que os pacotes originados pelo PC1 com destino à rede 30 atravessem a rota em amarelo (A, B, C), e que os pacotes originados pelo PC2, com destino à rede 30 atravessem a rota em verde (A, C). Como podemos fazer para que isso ocorra, sendo que o processo normal de roteamento apenas examina as tabelas de rotas e segue os caminhos que lá se encontram? Em nosso diagrama, isso pode ser um problema, já que os routers têm apenas a rota verde em suas tabelas.

Existem formas de fazer com que o router utilize outros critérios para a seleção de rotas, além das informações que se encontram na tradicional tabela de roteamento. Uma destas formas é chamada de Policy-based Routing, ou roteamento baseado em políticas. Podemos determinar rotas específicas, à partir de informações específicas. Em nosso exemplo, podemos fazer com que os roteadores roteiem baseando-se nos endereços IP de origem, e não na tabela de roteamento (que examina o endereço IP de destino). Configuramos o roteador, portanto, para que, assim que um pacote com o endereço de ORIGEM 10.1.1.100 atravesse a interface Fa0/0, ele seja direcionado à interface de saída S0/1. Quanto aos pacotes gerados pelo PC2, podemos simplesmente nos dar ao luxo de não fazer nada! Isso fará com que pacotes gerados pelo PC2 caiam no processo padrão de roteamento, ou seja, o endereço de destino será examinado e, com base nas informações da tabela de roteamento, o pacote seguirá o caminho verde.

Este tipo de configuração é interessante para atingir um balanceamento de carga mais homogêneo, por exemplo. Mas pode também ser usado para outros fins.

As configurações de PBR em roteadores Cisco usam “route-maps” para especificar as políticas à serem seguidas. Para a rede ilustrada, a configuração do Router A  ficaria conforme abaixo:

ip access-list standard ACL_PC1
 permit host 10.1.1.100
!
route-map RM_PC1 permit 10
 description Desvia trafego originado pelo PC1 para rota A_B_C
 match ip address ACL_PC1
 set ip next-hop 40.1.1.2
!
interface Fa0/0
 ip address 10.1.1.1 255.255.255.0
 ip policy route-map RM_PC1
!
end

Podemos usar uma ACL padrão, pois o que nos interessa é determinar o IP de origem, apenas. Notem que o “match” que usamos foi no resultado da ACL criada. Indicamos que, se houver um “match”, o pacote seja direcionado para o Router B como “next-hop” (ip 40.1.1.2). Existem muitos outros “match” que podem ser usados, para a criação das mais diversas políticas. Mas por hoje, fiquemos por aqui

Espero que tenham gostado!

E se puderem, testem o cenário no Dynamips (não creio que o Packet Tracer suporte este tipo de config).

Um abs!

Marco Filippetti

Popularity: 5% [?]