Redes MPLS Fundamentos e Aplicações

Miolo_Redes_MPLS_17 x 24_OK.indd 1

29/10/2012 14:57:14


29/10/2012 14:57:14

Copyright© 2012 por Brasport Livros e Multimídia Ltda. Todos os direitos reservados. Nenhuma parte deste livro poderá ser reproduzida, sob qualquer meio, especialmente em fotocópia (xerox), sem a permissão, por escrito, da Editora. Editor: Sergio Martins de Oliveira Diretora: Rosa Maria Oliveira de Queiroz Gerente de Produção Editorial: Marina dos Anjos Martins de Oliveira Revisão de Texto: Maria Helena dos Anjos Martins de Oliveira Editoração Eletrônica: Ingrafoto Produções Gráficas (Michelle Paula) Capa: Ingrafoto Produções Gráficas (Rebeca Baroni) Projeto Gráfica: Ingrafoto Produções Gráficas (Alexandra Mattos) Produção de ebook: S2 Books Técnica e muita atenção foram empregadas na produção deste livro. Porém, erros de digitação e/ou impressão podem ocorrer. Qualquer dúvida, inclusive de conceito, solicitamos enviar mensagem para [email protected], para que nossa equipe, juntamente com o autor, possa esclarecer. A Brasport e o(s) autor(es) não assumem qualquer responsabilidade por eventuais danos ou perdas a pessoas ou bens, originados do uso deste livro.

BRASPORT Livros e Multimídia Ltda. Rua Pardal Mallet, 23 – Tijuca 20270-280 Rio de Janeiro-RJ Tels. Fax: (21)2568.1415/2568.1507 e-mails: [email protected] [email protected] [email protected] site:

www.brasport.com.br

Filial SP Av. Paulista, 807 – conj. 915 01311-100 São Paulo-SP Tel. Fax (11): 3287.1752 e-mail: [email protected]


29/10/2012 14:57:15

Às nossas famílias.


29/10/2012 14:57:15

Apresentação A crescente demanda de tráfego e o dinamismo do mercado de Redes de Computadores, necessitando a cada dia de maior integração entre serviços (voz, vídeo e dados), fazem com que os provedores de acesso à Internet (ISPs – Internet Service Providers) estejam sempre em constante atualização tecnológica. É fundamental acompanhar as tendências do mercado, com o objetivo de entregar sempre a melhor tecnologia para o cliente, com isto provendo uma boa qualidade nos serviços ofertados. A tecnologia MPLS (MultiProtocol Label Switching) é indicada para prover evolução, otimização e flexibilidade ao núcleo da rede que une vários enlaces de alta velocidade (backbones) atuais, mostrando-se como uma tecnologia emergente a ser empregada nos provedores de acesso à Internet. Este livro apresenta a tecnologia MPLS, desde seus fundamentos às suas aplicações. São apresentados os benefícios obtidos com sua utilização, propiciando flexibilidade e otimização, deixando o backbone dos ISPs muito mais eficientes devido à capacidade de efetuar o roteamento dos pacotes baseado em rótulos, acelerando o processo de transmissão das informações e provendo alguns serviços agregados, tais como: VPNs (Virtual Private Networks), TE (Traffic Engineering), PseudoWire e QoS (Quality of Service). São tratados aspectos relacionados ao protocolo IPv6, novo protocolo da Internet e base para todos os backbones futuros, são descritas as características fundamentais deste protocolo, assim como algumas arquiteturas IPv6 utilizadas para o seu transporte em um backbone MPLS. O emulador de domínio público GNS3 foi utilizado para simulação das aplicações MPLS, permitindo um melhor entendimento dos conceitos apresentados.

VII


29/10/2012 14:57:16

VIII

Redes MPLS

No website https://sites.google.com/a/cin.ufpe.br/mpls-brasport/ o leitor pode encontrar material suplementar que acompanha este texto, incluindo material didático, referências para atualizações, ponteiros para fabricantes de equipamentos MPLS, etc. Os autores fizeram o máximo esforço para oferecer um texto amigável, preciso e atualizado. Comentários, críticas e sugestões são bem-vindos. Contate-nos via e-mail. Boa leitura. José Mário Oliveira ([email protected]) Rafael Dueire Lins ([email protected]) Roberto Mendonça ([email protected])


29/10/2012 14:57:16

Lista de Acrônimos AAL ADSL AF AS ASIC ASON ATM BGP BoS CBWFQ CE CEF CIDR CQ CSPF CU DiffServ DLCI DS DSCP eBGP ECPM EF EGP EIGRP EXP FEC FIB FIFO

ATM Adaptation Layer Asymmetric Digital Subscriber Line Assured Forwarding Automonous System Application-Specific Integrated Circuit Automatically Switched Optical Network Asynchronous Transfer Mode Border Gateway Protocol Bottom of Stack Class-Based Weighted Fair Queuing Customer Edge Cisco Express Forwarding Classless Inter-Domain Routing Custom Queuing Constrained Shortest Path First Currently Unused Differentiated Services Data Link Connection Identifier Differentiated Service DiffServ Code Point external BGP Equal-Cost Multipath Expedited Forwarding Exterior Gateway Protocol Enhanced Interior Gateway Routing Protocol Experimental Bits Forwarding Equivalent Class Forwarding Information Base First-In First-Out IX


29/10/2012 14:57:16

X Redes MPLS

FQ Fair Queuing FR Frame Relay FRR Fast Reroute GRE Generic Routing Encapsulation GTS Generic Traffic Shaping HDLC High Level Data Link Control IANA Internet Assigned Numbers Authority iBGP internal BGP Internet Control Message Protocol ICMP Internet Engineering Task Force IETF Interior Gateway Protocol IGP Interior Gateway Routing Protocol IGRP IOS Internetwork Operation System IP Internet Protocol IP Security Protocol IPSec IS-IS Intermediate System to Intermediate System International Organization for Standardization ISO ISP Internet Service Provider Local Area Network LAN Label Distribution Protocol LDP Label Edge Router LER Label Forwarding Information Base LFIB Label Information Base LIB LLQ Low Latency Queuing Local Management Interface LMI LSA Link-State Advertisement LSP Label Switched Path Label Switch Router LSR L2TP Layer 2 Tunneling Protocol MPB-GP MultiProtocol BGP MultiProtocol Label Switching MPLS Maximum Transfer Unit MTU Network Service Access Point NSAP OID Object IDentifier OSI Open Systems Interconnection OSPF Open Shortest Path First P Provider Plesiochronous Digital Hierarchy PDH


29/10/2012 14:57:17

Lista de Acrônimos XI

PDU Protocol Data Unit PE Provider Edge PHB Per-Hop Behavior PHP Penultimate Hop Popping PLR Point of Local Repair POP Point of Presence POS Packet Over SONET PPP Point-to-Point Protocol PQ Priority Queuing PseudoWire PW Quality of Service QoS Router Distinguisher RD RED Random Early Detection RFC Request For Comments RIP Routing Information Protocol RSVP Resource reSerVation Protocol Route Target RT SDH Synchronous Digital Hierarchy Service Level Agreement SLA Simple Network Management Protocol SNMP Synchronous Optical NETworking SONET Shortest Path First SPF Synchronous Transport Module STM Transmission Control Protocol TCP Time Division Multiplexing TDM TE Traffic Engineering TLV Type-Length-Variable Type of Service ToS TTL Time To Live UDP User Datagram Protocol User Network Interface UNI Virtual Circuit/Channel VC Virtual Local Area Network VLAN VLSM Variable Length Subnet Mask VoIP Voice over IP Virtual Circuit Identifier VCI Virtual Path Identifier VPI Virtual Private Network VPN


29/10/2012 14:57:17

XII

Redes MPLS

VRF WAN WDM WFQ WRED

Virtual Routing and Forwarding Wide Area Network Wavelength Division Multiplexing Weighted Fair Queuing Weighted Random Early Detection


29/10/2012 14:57:17

Sumário Introdução...........................................................................................................1 Organização do livro .................................................................................................................... 2 Capítulo 1. Conceitos Fundamentais .............................................................. 5 1.1 – Redes IPs ................................................................................................................................ 5 1.2 – O protocolo IPv4 ................................................................................................................. 6 1.3 – Comutação e roteamento..............................................................................................12 1.4 – Protocolos de roteamento .............................................................................................15 1.4.1 – O protocolo OSPF ................................................................................................21 1.4.2 – O protocolo IS-IS ..................................................................................................23 1.4.3 – O protocolo BGP ..................................................................................................24 Capítulo 2. A Arquitetura IP sobre MPLS ...................................................... 25 2.1 – Surgimento da tecnologia .............................................................................................25 2.2 – Roteamento convencional x baseado em rótulos ................................................26 2.3 – O cabeçalho MPLS ............................................................................................................29 2.4 – Estrutura do MPLS ............................................................................................................32 2.5 – Componentes da arquitetura .......................................................................................33 2.6 – Funcionamento .................................................................................................................38 2.7 – Vantagens do MPLS..........................................................................................................41 2.8 – Desvantagens do MPLS ..................................................................................................42 Capítulo 3. MPLS – VPN ........................................................................................................43 3.1 – VPN – Conceitos ................................................................................................................43 3.2 – Tipos de VPN .......................................................................................................................45 3.3 – Modelos de VPN ................................................................................................................48 3.3.1 – O modelo overlay.................................................................................................48 3.3.2 – O modelo par-a-par ............................................................................................50 XIII


29/10/2012 14:57:17

XIV Redes MPLS

3.4 – Arquitetura MPLS VPN......................................................................................................51 3.5 – Propagação de rotas VPNv4 no backbone VPN MPLS...........................................55 Capítulo 4. PseudoWire MPLS........................................................................ 58 4.1 – PseudoWire – Conceito.....................................................................................................58 4.2 – Modelo de referência PseudoWire................................................................................60 4.3 – Terminologias do PseudoWire........................................................................................60 4.4 – Como o PseudoWire trabalha.........................................................................................61 4.5 – Benefícios do PseudoWire...............................................................................................63 Capítulo 5. Qualidade de Serviço (QoS) com MPLS...................................... 64 5.1 – Fundamentos do QoS......................................................................................................64 5.2 – Arquiteturas de QoS.........................................................................................................65 5.2.1 – Serviços integrados (IntServ)............................................................................65 5.2.2 – Serviços diferenciados (DiffServ).....................................................................67 5.3 – Mecanismos de QoS.........................................................................................................71 5.4 – Qualidade de serviços nas redes MPLS......................................................................81 Capítulo 6. Engenharia de Tráfego com MPLS.............................................. 85 6.1 – Conceitos fundamentais.................................................................................................85 6.2 – A engenharia de tráfego sobre MPLS.........................................................................87 6.3 – Extensões do OSPF para TE............................................................................................89 6.4 – Extensões do IS-IS para TE..............................................................................................91 6.5 – Protocolo RSVP-TE.............................................................................................................91 6.6 – Operação do MPLS-TE......................................................................................................92 6.7 – Atributos de túneis MPLS-TE..........................................................................................93 6.8 – Proteção e restauração – FRR........................................................................................93 6.9 – GMPLS....................................................................................................................................94 Capítulo 7. IPv6 sobre MPLS........................................................................... 96 7.1 – O protocolo IPv6................................................................................................................96 7.2 – Endereçamento IPv6...................................................................................................... 101 7.3 – Transporte IPv6 sobre um backbone MPLS............................................................ 103 7.3.1 – Técnica 6PE.......................................................................................................... 104 7.3.2 – Técnica 6VPE........................................................................................................ 106


29/10/2012 14:57:17

Capítulo 8.

Sumário XV

Implementando Redes MPLS............................................... 108

8.1 – A ferramenta de simulação dos ambientes........................................................... 108 8.2 – Topologia de base utilizada......................................................................................... 110 8.2.1 – Recursos utilizados........................................................................................... 111 8.3 – Escolha do protocolo IGP/EGP e esquema de endereçamento IP................ 112 8.3.1 – Protocolo IS-IS – endereços NSAP............................................................... 112 8.3.2 – Protocolo IS-IS – áreas...................................................................................... 113 8.3.3 – Protocolo BGP..................................................................................................... 113 8.3.4 – Definição do sistema autônomo.................................................................. 114 8.3.5 – Configuração do MP-iBGP.............................................................................. 114 8.3.6 – Configuração geral do BGP............................................................................ 114 8.3.7 – Configuração do Address Family VPNv4.................................................... 115 8.4 – Testes realizados e observações................................................................................ 115 8.4.1 – Comportamento básico do MPLS............................................................... 115 8.4.2 – Configurações..................................................................................................... 117 8.4.3 – Verificações e testes de conectividade...................................................... 119 8.4.4 – PseudoWire MPLS............................................................................................... 124 8.4.5 – MPLS VPN............................................................................................................. 133 8.4.6 – QoS no MPLS....................................................................................................... 145 8.4.7 – Engenharia de tráfego com MPLS............................................................... 151 8.5 – IPv6 sobre MPLS.............................................................................................................. 161 Referências Bibliográficas............................................................................. 167 Apêndice A. Configurações – Funcionamento do MPLS............................. 173 Apêndice B. Verificação – PseudoWire........................................................ 177 Apêndice C. Configurações – MPLS-VPN..................................................... 179 Apêndice D. Configurações – MPLS – QoS................................................... 188 Apêndice E. Configurações – Engenharia de Tráfego................................. 201 Apêndice F. Configurações – IPv6............................................................... 209 Índice Remissivo............................................................................................. 219


29/10/2012 14:57:17

Introdução Novas tecnologias estão sendo constantemente desenvolvidas para atender às demandas causadas pelo aumento da utilização da Internet, assim como um aumento das exigências por serviços de comunicação de dados, capazes de integrar dados, voz e imagem com qualidade de serviço e segurança. Os canais troncos utilizados no tráfego em grande volume e velocidade são conhecidos como backbones. Apesar da complexidade de muitos backbones atuais, a robustez e confiabilidade são uma evidência de um grande avanço no desenvolvimento das tecnologias de redes espalhadas geograficamente, conhecidas pelo acrônimo de WAN (Wide Area Network), assim como da adoção de uma metodologia de consenso em relação a aspectos de projeto por parte dos desenvolvedores. Combinando o processo de roteamento de nível 3 com a comutação sobre a camada 2, de acordo com o modelo de referência OSI (Open Systems Interconnection), a arquitetura IP (Internet Protocol) sobre MPLS (MultiProtocol Label Switching) oferece maior possibilidade de gerenciamento e engenharia de tráfego, reduzindo o processamento necessário para realizar o roteamento de datagramas de rede. Essa tecnologia vem crescendo bastante e ganhando força como alternativa à combinação do protocolo IP sobre tecnologias de camada 2, tais como: Ethernet, Asynchronous Transfer Mode (ATM) e Frame Relay, sendo largamente oferecida no mercado, de maneira que a demanda se intensificou e vem estimulando os clientes a solicitar tais serviços, não se tratando de mera oportunidade de negócio, mas de requisito imprescindível para atendimento das demandas dos clientes atuais. O acompanhamento e a adaptação às mudanças tecnológicas que surgem e que se firmam em um cenário global são essenciais para que os provedores se mantenham presentes na disputa por novos clientes. Em backbones modernos, o uso da tecnologia MPLS traz grandes benefícios, evitando a complexidade de tecnologias de camada 2, que provocam problemas de escalabilidade, desempenho e administração. O MPLS também possibilita o uso de aplicações convergentes, 1


29/10/2012 14:57:18

2 Redes MPLS

o que o torna bastante atrativo para o mercado atual, que procura soluções que possibilitem a implementação de redes práticas, econômicas e interoperáveis. É importante também salientar que a tecnologia MPLS permite a integração de várias tecnologias usadas em grandes provedores, tais como: Frame Relay, ATM (Asynchronous Transfer Mode), linhas dedicadas e ADSL (Asymmetric Digital Subscriber Line), viabilizando assim a otimização da infraestrutura instalada. O fato de MPLS ser, por essência, uma tecnologia de camada dois e meio – isto porque adiciona um cabeçalho de 32 bits (que contém um rótulo) entre as camadas de enlace de dados e redes (dois e três no modelo OSI), dessa forma trabalhando com a tecnologia IP – provocou uma significante evolução nas tecnologias de núcleo da rede, sendo extremamente fácil de operar, oferecendo muitos mecanismos de controle e gerência de tráfego e provocando um melhor uso do meio físico. Seus equipamentos são bem mais baratos que equipamentos ATM e permitem velocidades bem maiores, tendo impacto direto nos negócios dos provedores de serviços de rede de longa distância – ISPs. Este livro apresenta um estudo abrangente sobre a tecnologia MPLS e uma análise dos seus principais serviços, seus benefícios, suas facilidades e suas melhorias. Além disso, também explora as características do protocolo IPv6, com abordagem de algumas arquiteturas utilizadas para transporte deste protocolo no núcleo dos ISPs. É feito também um estudo prático, com a ferramenta de emulação GNS3, através de diversas simulações de ambientes com a tecnologia MPLS e seus serviços, objetivando facilitar o aprendizado e servindo de base para o leitor desenvolver seus próprios cenários, suas configurações e aplicações.

Organização do livro O capítulo 1 deste livro trata os conceitos fundamentais das redes IPs, abrangendo o protocolo IP e a Internet, os conceitos de roteamento e comutação e uma breve descrição dos principais protocolos de roteamento utilizados no mercado, base para o entendimento e a funcionalidade da tecnologia MPLS e que é apresentada ao longo deste livro. No capítulo 2 são apresentados conceitos e definições referentes à tecnologia MPLS, dando uma visão dos principais componentes de uma rede MPLS, buscando identificar e entender o funcionamento da tecnologia, suas vantagens e desvantagens.


29/10/2012 14:57:18

Introdução 3

Nos capítulos 3, 4, 5 e 6 são discutidos os serviços fundamentais ofertados pela tecnologia MPLS (VPN – Virtual Private Network –, PseudoWire, QoS – Quality of Service – e Engenharia de Tráfego), descrevendo com detalhes como cada serviço trabalha, suas terminologias utilizadas, seus benefícios e suas implementações. No capítulo 7 são tratados aspectos relacionados ao IPv6, novo protocolo da Internet, base para todos os backbones futuros. São descritas as características fundamentais do protocolo IPv6, assim como são também abordadas algumas arquiteturas IPv6 utilizadas para transporte deste protocolo em um backbone MPLS. No capítulo 8 apresentamos um experimento, sua montagem e composição, que serve de exemplo ao leitor para metodologia de projeto e análise de desempenho de uma rede MPLS. Inicialmente, é apresentada a ferramenta utilizada para elaboração dos ambientes simulados e, em seguida, são apresentados a topologia e os recursos utilizados. Mostramos a escolha dos protocolos IGP/EGP (Interior Gateway Protocol/Exterior Gateway Protocol) e todos os testes realizados, com as observações para cada ambiente e serviço simulado. Seguem-se as referências bibliográficas que serviram como base para o desenvolvimento desta publicação. Por fim, os apêndices apresentam os arquivos de configuração, verificações e alguns testes efetuados para cada uma das simulações realizadas neste experimento.


29/10/2012 14:57:18

CAPÍTULO 1. Conceitos Fundamentais

Neste capítulo são definidos os conceitos fundamentais das redes IPs, abrangendo o protocolo IP e a Internet, os conceitos de roteamento e comutação e uma breve descrição dos principais protocolos de roteamento utilizados no mercado. É apresentado o protocolo IP (Internet Protocol) e como ele pode ser usado para a montagem de uma inter-rede escalável e heterogênea.

1.1 – Redes IPs Em primeiro de janeiro de 1983, o TCP/IP (Transmission Control Protocol/ Internet Protocol) se tornou o protocolo oficial na ARPANET, que, em seguida, foi interconectada à NSF (National Science Foundation). A partir daí, o crescimento dessas redes se tornou exponencial (Tanenbaum, 2011). Essa rede de redes (Kurose e Ross, 2010) se tornou a Internet, não mais se restringindo a ambientes acadêmicos. O aparecimento do navegador (ou browser) Mosaic (Tanenbaum, 2011), um aplicativo de uso simples que “escondia” do usuário toda a complexidade da rede, possibilitou um rápido crescimento do número de usuários da Internet. O principal protocolo de rede da Internet é o IP (Internet Protocol). O protocolo IP foi criado com o objetivo simples de tornar possível a comunicação entre máquinas independentemente do meio de transmissão, não possuindo mecanismos de notificação (acknowledgement) ou correção de erro. O protocolo IP não tem mecanismos que permitam realizar consultas de gerenciamento, é sem controle de fluxo, não orientado a conexão e não era prevista qualidade de serviço, ou seja, um protocolo desenvolvido para trabalhar em uma rede de melhor esforço (best-effort) (Forouzan, Benhrouz A., 2008). Durante o seu desenvolvimento, esse protocolo sofreu várias modificações em seu projeto inicial para se adequar às novas necessidades de serviços de voz sobre uma rede de dados e serviço de vídeo sob demanda. 5


29/10/2012 14:57:19

6 Redes MPLS

Existem dois problemas importantes que precisam ser resolvidos quando se conectam redes: heterogeneidade e escalabilidade (Peterson e Davie, 2004). O desafio da heterogeneidade é oferecer um serviço ponta-a-ponta, útil e bastante previsível através desse emaranhado de redes diferentes. Para entender o problema de escalabilidade, é necessário considerar o crescimento da Internet, que praticamente dobrou de tamanho a cada ano durante os últimos vinte anos. Essa taxa de crescimento traz inúmeros desafios, e um deles é o roteamento. A Internet se tornou um bem pervasivo, cujo funcionamento é assumido como certo, tal qual o fornecimento de eletricidade ou água, para a população, como também para empresas e centros de pesquisas, modificando de maneira radical muitos setores da atividade humana. Hoje, sem Internet pouco se faz.

1.2 – O protocolo IPv4 O formato do datagrama IPv4 é exibido na Figura 1.1. Ele tem um comprimento variável e é dividido em duas partes: cabeçalho e dados. O cabeçalho tem comprimento de 20 a 60 bytes e contém informações essenciais para o roteamento e a entrega (Forouzan, Benhrouz A., 2008a). O cabeçalho contém as informações administrativas do datagrama; já o campo de dados contém as informações das aplicações. Os principais campos desse datagrama são os seguintes:

Figura 1.1 – Formato do datagrama IP


29/10/2012 14:57:19

Conceitos Fundamentais 7

Versão (4 bits): este campo de 4 bits define a versão do protocolo IP. Atualmente, a versão mais amplamente utilizada é a 4. Entretanto, a versão 6 (IPng) deverá substituir completamente a versão 4 em um futuro próximo. Observe-se que a colocação deste campo diretamente no início do datagrama facilita para que tudo mais no formato do pacote seja redefinido em versões posteriores. Este campo informa ao software do IPv4, que roda na máquina em processamento, que o datagrama tem o formato da versão 4. Todos os campos devem ser interpretados conforme especificado na quarta versão do protocolo. Se a máquina estiver usando alguma outra versão do IP, o datagrama é descartado em vez de ser interpretado incorretamente. Tamanho do Cabeçalho (4 bits): este campo define o comprimento total do cabeçalho do datagrama em palavras de 32 bits e é necessário porque o comprimento do cabeçalho é variável. Quando não se faz uso do campo opções, o que quase sempre acontece, o comprimento do cabeçalho é de 20 bytes e o valor desse campo é 5 (5 x 4 = 20 bytes) de extensão. Quando o campo de opções estiver em seu tamanho máximo, seu valor é 15 (15 x 4 = 60 bytes) de extensão (Forouzan, Benhrouz A., 2008a). Tipo de Serviço (8 bits): o campo ToS (Type of Service) teve diversas definições diferentes no decorrer dos anos, mas sua função básica é permitir que os pacotes sejam tratados de modo diferente, com base nas necessidades da aplicação. Este campo é utilizado pelos roteadores para determinar como o datagrama deve

Figura 1.2 – Tipo de serviço ou serviços diferenciados


29/10/2012 14:57:19

8 Redes MPLS

ser tratado, podendo diferenciar os vários tipos de datagramas IPs. Por exemplo, pode ser útil distinguir os datagramas de tempo real (ex.: Telefonia IP) dos tráfegos que não são de tempo real (ex.: FTP). O IETF (Internet Engineering Task Force) mudou a interpretação e o nome deste campo de 8 bits. Este campo, anteriormente denominado tipo de serviço, agora se chama serviços diferenciados (Forouzan, Benhrouz A., 2008a) e na Figura 1.2 é possível visualizar as duas interpretações. No tipo de serviço, os três primeiros bits são denominados bits de precedência. Os 4 bits seguintes são chamados bits ToS (Type of Service) e o último bit não é usado. A precedência é um subconjunto de três bits no intervalo que vai de 0 (000 em binário) a 7 (111 em binário). A precedência define a prioridade do datagrama em questões como congestionamento. Se um roteador estiver congestionado e precisar descartar alguns pacotes, aqueles com menor precedência serão descartados primeiro. O ToS é um subcampo de 4 bits, onde cada bit tem um significado especial. Embora um bit possa ser 0 ou 1, um e somente um dos bits do subcampo pode ter valor 1 em cada datagrama. Os padrões de bits e suas interpretações são apresentados na Tabela 1.1. Tabela 1.1 – Tipos de serviços

Bits ToS 0000 0001 0010 0100 1000

Descrição Normal (padrão) Minimizar custo Maximizar confiabilidade Minimizar throughput Minimizar atraso

Na interpretação com os serviços diferenciados os seis primeiros bits formam o subcampo ponto de código e os últimos 2 bits não são usados. No capítulo 5 abordaremos esses bits com detalhes para uso com a arquitetura DiffServ (Serviços Diferenciados). Tamanho total do datagrama (16 bits): trata-se de um campo que define o comprimento total do datagrama IPv4, incluindo o cabeçalho. O tamanho máximo de um datagrama IP é de 65.535 bytes. Porém, a rede física em cima da qual o IP está sendo executado não pode admitir pacotes tão grandes. Por esse motivo, o IP admite um processo de fragmentação e remontagem. Para descobrir o comprimento dos dados provenientes da camada superior, subtrai-se o comprimento do cabeçalho do comprimento total. O comprimento do cabeçalho pode ser encontrado multiplicando-se o valor do campo tamanho do cabeçalho por 4.


29/10/2012 14:57:19


Alguns padrões físicos não são capazes de encapsular um datagrama de 65.535 bytes em seus quadros. O datagrama tem que ser fragmentado para conseguir ser transmitido por essas redes. Como exemplo, o protocolo Ethernet apresenta uma restrição mínima e máxima no tamanho dos dados que podem ser encapsulados em um quadro (46 a 1.500 bytes). Se o tamanho de um datagrama IPv4 for menor que 46 bytes, serão acrescidos alguns bits de preenchimento para atender a essa exigência. Identificação (16 bits): utilizado para identificação do datagrama IP no processo de fragmentação do pacote, para que este seja remontado na mesma ordem em que foi fragmentado. Quando um datagrama é maior do que o MTU (Maximum Transfer Unit) de uma determinada tecnologia, ele precisa ser dividido em fragmentos para que possa ser transmitido na rede. Assim, o campo identificador é utilizado para que seja possível saber a qual datagrama cada fragmento pertence. Um dos problemas de oferecer um modelo de serviço uniforme ponta-a-ponta por uma coleção heterogênea de redes é que cada tecnologia de rede costuma ter sua própria definição quanto ao tamanho que um pacote pode ter. Um datagrama pode trafegar por várias redes diferentes. Cada roteador desencapsula o datagrama IP, a partir do quadro que ele recebe, o processa e então o encapsula em outro quadro. O formato e o tamanho do quadro recebido dependem do protocolo usado pela camada física por meio do qual o quadro acaba de passar. Se, por exemplo, um roteador interliga uma LAN (Local Area Network) a uma WAN (Wide Area Network), ele recebe um quadro no formato da LAN e transmite um quadro no formato da WAN. A ideia central é que cada tipo de rede tenha um MTU (Maximum Transfer Unit), que é o maior datagrama IP que ele pode transportar em um quadro. Para tornar o protocolo IP independente da rede física, os projetistas decidiram fazer o comprimento máximo de um datagrama IP igual a 65.535 bytes. Isso torna a transmissão mais eficiente quando se utiliza um protocolo com MTU desse tamanho. Entretanto, para outras redes físicas, é necessário dividir o datagrama para tornar possível sua passagem por essas redes. Isso é denominado fragmentação. O interessante é que a nova versão do protocolo IP, o IPv6, não permite fragmentação em roteadores (Kurose e Ross, 2010). Flag (3 bits): trata-se de um campo de 3 bits. O primeiro é reservado. O segundo é denominado bit DF (Don’t Fragment), não fragmentado, e é utilizado para indicar aos roteadores que não fragmentem o pacote, porque o destino


29/10/2012 14:57:19

10 Redes MPLS

não os saberá reconstruir. Se seu valor for 1, a máquina não poderá fragmentar o datagrama. Se não puder passar o datagrama por meio de qualquer rede física disponível, ele descarta o datagrama e envia uma mensagem de erro ICMP (Internet Control Message Protocol) ao host de origem. Se seu valor for 0, o datagrama pode ser fragmentado se necessário. O terceiro bit é chamado de bit MF (More Fragments), mais fragmentos. Se seu valor for 1, significa que esse datagrama não é o último fragmento; existem mais fragmentos após este. Se seu valor for 0, significa que esse é o último ou único fragmento (Forouzan, Benhrouz A., 2008a). A Figura 1.3 mostra os flags usados na fragmentação.

Figura 1.3 – Flags usados na fragmentação

Offset (deslocamento) do Fragmento (13 bits): este campo de 13 bits mostra a posição relativa desse fragmento em relação ao datagrama inteiro. É o offset dos dados no datagrama original medido em unidades de 8 bytes. A Figura 1.4 mostra um datagrama cujo tamanho dos dados é igual a 4000 bytes, fragmentados em três partes.

Figura 1.4 – Exemplo de fragmentação

Tempo de Vida (TTL) (8 bits): é utilizado para garantir que datagramas não fiquem circulando para sempre na rede. Ao receber um datagrama, todo roteador deve ler esse campo – se seu valor for maior que zero, ele deverá decrementá-lo em uma unidade; se seu valor for igual a zero, esse datagrama deverá ser descartado, evitando assim um laço de roteamento de longa duração. Um datagrama tem um tempo de vida útil limitado em sua transmissão por uma rede de


29/10/2012 14:57:19


computadores. Este campo foi projetado originalmente para armazenar um registro de horas, que era reduzido pelos roteadores visitados. O datagrama era descartado quando o valor se tornava zero. Entretanto, para implementar este método todas as máquinas devem ter relógios sincronizados e devem saber quanto tempo leva para um datagrama ir de uma máquina a outra. Protocolo (8 bits): este campo define o protocolo de nível superior que está utilizando os serviços da camada de rede. Um datagrama IP pode encapsular dados de vários protocolos superiores como: TCP (Transmission Control Protocol), UDP (User Datagram Protocol), ICMP (Internet Control Message Protocol) e OSPF (Open Shortest Path First). Este campo especifica o protocolo de destino final para o datagrama IP que será entregue. A Figura 1.5 mostra os detalhes do campo.

Figura 1.5 – Campo de protocolo e dados encapsulados

Soma Verificadora do Cabeçalho (checksum) (16 bits): a paridade (checksum) no datagrama IP cobre apenas o cabeçalho, e não todos os dados. Há duas razões para isso. Em primeiro lugar, todos os protocolos de nível superior que encapsulam dados em um datagrama IP têm um campo de paridade que cobre o pacote inteiro. Portanto, a paridade para um datagrama IP não precisa verificar os dados encapsulados. Em segundo lugar, o cabeçalho de um datagrama IP muda a cada roteador visitado, mas não os dados. Portanto, a paridade inclui apenas a parte alterada. Se dados forem incluídos, cada roteador terá que recalcular a paridade para o pacote inteiro, significando um aumento no tempo de processamento. Endereços IP de Origem e Destino (32 bits cada): representam os endereços IP do host que envia o datagrama (fonte) e do host que receberá o datagrama (destino). Opções (0 a 320 bits): permite que o cabeçalho IP seja ampliado. Existem opções para segurança, armazenamento de rota, roteamento obrigatório,


29/10/2012 14:57:19

12 Redes MPLS

timestamp, etc. Uma vez que alguns datagramas podem requerer processamento de opções e outros não, a quantidade de tempo necessária para processar um datagrama IP em um roteador pode variar bastante. Por essas razões, este campo foi descartado no cabeçalho da versão IPv6. Dados (payload): espaço reservado para os dados a serem transmitidos.

1.3 – Comutação e roteamento Roteamento é o nome dado ao processo de escolha do caminho a ser seguido pelos dados a serem transmitidos numa rede espalhada geograficamente (WAN). Vários aspectos podem ser levados em consideração, desde a velocidade dos enlaces até o número de saltos (hops) envolvidos, passando pelo custo de transmissão e a confiabilidade dos canais. No roteamento há a retransmissão, processo pelo qual os pacotes são encaminhados de um canal para outro. Nas redes de datagrama, incluindo as redes IP, o roteamento é tratado pacote a pacote. O protocolo IP, com sua simplicidade e flexibilidade, possui grande sucesso na função do roteamento, sendo este protocolo responsável pela entrega das informações geradas pelas aplicações aos seus destinos de forma correta e eficiente. Roteamento IP é o termo utilizado para descrever as ações efetuadas pela rede TCP-IP para enviar um pacote de um dispositivo a outro, ou seja, os endereços IPs de origem e destino devem ser diferentes. Os roteadores obtêm conhecimento da topologia das redes remotas através dos pares vizinhos ou das informações configuradas manualmente por um administrador. Assim, esses equipamentos constroem uma tabela de rotas que descreve como encontrar o endereço remoto. Estando uma rede diretamente conectada ao roteador, este saberá como alcançá-la, não sendo necessário nenhum mecanismo de criação de rotas. Caso a rede não esteja diretamente conectada, será necessário o uso de um processo de roteamento estático, o que significa dizer que um administrador inseriu manualmente todas as localizações das redes na tabela de roteamento, ou de um processo de roteamento dinâmico. Nesse caso, o administrador pode fazer uso de algum protocolo de roteamento no qual as rotas são divulgadas automaticamente. A grande vantagem do uso de protocolos de roteamento dinâmico sobre o roteamento estático é a possibilidade de adaptação das rotas em situações de falhas ou congestionamentos detectados. Se alguma mudança ocorrer na rede, os protocolos de roteamento dinâmico informam automaticamente a todos os


29/10/2012 14:57:19


roteadores sobre o evento. Em se tratando de um roteamento estático, o administrador é responsável por atualizar todas as mudanças manualmente em todos os roteadores. Tipicamente, nas grandes redes, uma combinação do roteamento dinâmico e estático é usada (Doyle e Carroll, 2006). O mecanismo de aprendizado e manutenção do conhecimento da topologia de rede é considerado como a função de roteamento. O movimento real do tráfego transiente por meio do roteador, da interface de entrada para uma interface de saída, é uma função separada considerada uma função de comutação (Paquet e Teare, 2003). Comutação é o processo de apanhar um quadro de uma entrada e enviá-lo por uma saída apropriada, com base na informação da camada de enlace de dados. Os métodos para a comutação de quadros baseiam-se nas informações de endereço da camada de enlace de dados. Os recursos e as funcionalidades dos comutadores (switches) de camada 3 e dos roteadores têm diversas semelhanças. Um roteador só precisa responder a uma pergunta muito simples: dado um datagrama IP que transporta um endereço de host de destino específico, por qual interface o datagrama deve ser enviado e para qual salto seguinte? Portanto, ao receber um pacote, o roteador precisa ler o cabeçalho IP, determinar a que rede de destino o pacote pertence e, através da leitura de uma tabela de roteamento, encaminhá-lo para o próximo salto. A construção das tabelas e seu uso para o encaminhamento podem ser separados por operações lógicas, conforme as Figuras 1.6 e 1.7. Durante a transmissão de um pacote na rede, este passa por roteadores intermediários, que verificam o endereço de destino, consultam sua tabela de roteamento e o transmitem para o próximo roteador na rota; logo, cada roteador possui sua tabela de roteamento, e a informação que consta na tabela informa qual o próximo roteador para o qual os pacotes devem ser enviados, o que é chamado de next-hop. Na Figura 1.6 pode-se ver como os roteadores geram as tabelas de encaminhamento. Inicialmente o roteador “D” anuncia a rede 130.10, que está diretamente conectada a ele, para o roteador B. O roteador C faz o mesmo procedimento, ou seja, envia a rede 170.33 para o roteador B. Ao receber as redes 130.10 e 170.33, através das respectivas interfaces 0 e 1, o roteador B as divulga para o roteador A, que recebe em sua interface 1. A Figura 1.7 mostra que, para a rede da Figura 1.6, quando um pacote chega ao roteador A, destinado à rede 130.10, no caso o endereço 130.10.20.5, o roteador A, através da leitura do endereço de destino em sua tabela de rotas, envia o pacote através da interface 1. O roteador B receberá o pacote e terá o mesmo comportamento, enviando o pacote para o roteador D, a quem pertence a rede, que enviará ao dispositivo final.


29/10/2012 14:57:20

14 Redes MPLS

Figura 1.6 – Geração das tabelas de encaminhamento

A comutação de pacotes oferece um novo modelo para o encaminhamento de dados na rede. Em vez de encaminhar cada pacote com base no endereço da camada de rede e nas informações distribuídas por protocolos de roteamento, os nós na rede podem usar rótulos transportados nos pacotes e informações de comutação de rótulos distribuídas por novos protocolos ou extensões dos protocolos existentes.

Figura 1.7 – Encaminhamento de pacotes


29/10/2012 14:57:20


A comutação de pacotes IPs é o processo de encaminhar pacotes de dados dentro de uma rede, com base em algum rótulo associado com cada pacote. O roteamento IP tradicional é uma forma de comutação de pacotes – cada pacote transporta um endereço IP de destino que pode ser usado para determinar o próximo salto no caminho em direção ao destino, realizando uma consulta na tabela de roteamento. Há, no entanto, muitas limitações para o roteamento, e a comutação de rótulos foi desenvolvida para resolver algumas delas.

1.4 – Protocolos de roteamento O roteamento dos pacotes em uma rede depende das regras estabelecidas por cada protocolo de roteamento, portanto os protocolos de roteamento definem as rotas que os pacotes devem seguir para alcançar determinado destino. Os protocolos também devem estabelecer o procedimento a ser tomado em caso de mudanças repentinas na infraestrutura da rede, tais como linhas de transmissão sendo interditadas ou reativadas, falha de roteadores e outras mudanças estruturais, assim como informações de falha em linhas (enlaces) de transmissão como, por exemplo, um circuito de STM (Synchronous Transport Module) que esteja mudando seu estado repentinamente e caminhos que estão com alto nível de congestionamento. Por esse motivo, as tabelas de roteamento normalmente são recalculadas em tempos definidos ou quando uma quantidade mínima de mudança na rede estiver sendo observada, pois em casos de várias mudanças isso acarretaria uma alta necessidade do processamento dos roteadores. Cada agrupamento organizacional de computadores é definido como um Sistema Autônomo ou AS (Autonomous System), ou seja, um sistema que pode operar isoladamente de todos os outros agrupamentos. Um Sistema Autônomo (AS) é uma coleção de redes sob uma administração comum (Doyle e Carrol, 2006) identificado por um número. Esse número é composto por 16 bits, com um intervalo de 1 até 65.535, atribuído pelo IANA (Internet Assigned Numbers Authority). A Internet é uma união de sistemas autônomos e, dentro dos sistemas autônomos, as rotas são atribuídas de forma estática e/ou através de protocolos interiores e exteriores de roteamento. Dentro de um AS, as informações de roteamento, em geral, são bastante distribuídas, e um roteador pode claramente ver o caminho pela rede até outro roteador dentro do mesmo AS. Os protocolos de roteamento dentro de um AS e entre ASs são diferentes. Roteadores dentro de um AS trocam informações de roteamento através de um protocolo comum conhecido como IGP (Interior Gateway Protocol); já os roteadores que fazem comunicação entre


29/10/2012 14:57:20

16 Redes MPLS

ASs, o fazem através de um protocolo de roteamento chamado de EGP (Exterior Gateway Protocol) (Doyle e Carrol, 2006). Essa divisão se dá porque os protocolos possuem objetivos diferentes. Dentro de um AS o maior objetivo é calcular rotas eficientes, assim como efetuar atualizações rapidamente quando ocorrer uma mudança na rede, por exemplo, provocada por uma falha na linha de transmissão, interrupção temporária de um roteador, etc. Os roteadores que trabalham com os protocolos EGPs possuem uma maior preocupação com questões administrativas, políticas, econômicas e de segurança, sendo essas manualmente configuradas nos roteadores, não fazendo parte diretamente do protocolo. Tais diferenças fazem com que o IGP e EGP, em sua maioria, façam uso de tecnologias diferentes. Como exemplos de protocolos IGPs podemos citar: Open Shortest Path First (OSPF), Intermediate System-to-Intermediate System (IS-IS), Routing Information Protocol (RIP) e Enhanced Interior Gateway Protocol (EIGRP). Já como exemplos de protocolos EGPs podemos citar: ISO-IDRP e o protocolo BGP (Border Gateway Protocol), este último utilizado pelos provedores de serviços para troca de informações entre os sistemas autônomos na Internet, conforme Figura 1.8.

Figura 1.8 – Roteamento interior (IGP) e exterior (EGP)

Os protocolos de roteamento possuem um grande conjunto de informações e características diferenciadas que são possíveis de categorizar: classful (não propagam as sub-redes nas atualizações de rotas) versus classless (propagam as sub-redes nas atualizações de rotas) e protocolos que trabalham com o algoritmo de vetor de distância (distance vector) versus algoritmo de estado de enlace (link state). O nome roteamento por vetor de distância é encontrado também na literatura como algoritmo de Bellman-Ford (Paquet e Teare, 2003). A ideia por trás do algoritmo com vetor de distância é sugerida por seu nome: cada nó constrói


29/10/2012 14:57:20


um array unidimensional (um vetor) contendo as “distâncias” (custos) até todos os outros nós e distribui esse vetor aos seus vizinhos imediatos, conforme Figura 1.9. A suposição inicial para o roteamento com vetor de distância é que cada nó conhece o custo do enlace para cada um de seus vizinhos conectados diretamente. O melhor caminho pode estar relacionado com várias medidas, sendo que o número de roteadores na rota (hop count) é a mais utilizada. Um enlace que esteja inativo recebe o custo infinito.

Figura 1.9 – Exemplo do algoritmo de vetor de distância

As rotinas periódicas de atualizações de roteamento geradas pela maioria dos protocolos de roteamentos por vetor de distância vão apenas para os dispositivos de roteamento conectados diretamente. Num ambiente de vetor de distância puro, as atualizações de roteamento incluem uma tabela completa de roteamento, a qual pode ser chamada de atualização integral, ou seja, a troca de toda a tabela de roteamento. Ao receber uma tabela completa de um vizinho, um roteador pode verificar todas as rotas conhecidas e, em seguida, fazer as alterações na tabela local, com base nas informações atualizadas recebidas. Esse processo de roteamento é muito simples e na prática pode ser lento, gerando um alto tempo de convergência na rede (tempo que os roteadores levam para estabilizar as tabelas de roteamento de acordo com uma mudança ocorrida na topologia) e possíveis loops de roteamento. Como exemplos de protocolos de vetor de distância existem o RIP (Routing Information Protocol) definido na RFC 1058 (RFC 1058), o RIPv2 definido na RFC 1723 (RFC 1723) e o RIPng (Routing Information Protocol next generation) para IPv6, definido na RFC 2080 (RFC 2080). Já o IGRP (Interior Gateway Routing Protocol), de propriedade da Cisco, embora também seja um protocolo de vetor de distância, é pouco usado no mercado, pois foi substituído por um


29/10/2012 14:57:20

18 Redes MPLS

protocolo de roteamento mais avançado, o EIGRP (Enhanced Interior Gateway Routing Protocol), que exibe algumas características de estado de enlace. O roteamento por estado de enlace (link-state) não distribui rota alguma, mas troca informações de topologia que descrevem a rede. Cada nó é responsável por anunciar os detalhes dos enlaces que aceita e por passar adiante informações semelhantes que recebem de outros roteadores. Desse modo, cada roteador na rede monta um banco de dados completo dos enlaces disponíveis e quais nós eles interconectam, com cada roteador possuindo o mapa completo e idêntico da rede. No roteamento por vetor de distância, cada roteador envia informações de roteamento por seus enlaces – não importa se existe um roteador no enlace para receber as informações ou não. No roteamento por estado de enlace, existe uma ligação mais próxima entre os roteadores vizinhos – eles precisam estabelecer um relacionamento de parceria, a fim de haver a troca de informações de estado de enlace. Essa primeira etapa é obtida por meio de um protocolo de “Hello”, onde cada roteador envia uma mensagem “Hello” a cada enlace para se apresentar aos vizinhos. O formato e o conteúdo exato da mensagem de “Hello” dependem do protocolo de roteamento por estado de enlace em uso, mas ele precisa identificar com exclusividade o enlace em que a mensagem foi enviada (usando o endereço IP) e o roteador que enviou a mensagem. O receptor de mensagem “Hello” responde com seu próprio “Hello”, de modo que ambos os roteadores conheçam um ao outro. Após a troca inicial da mensagem “Hello”, os roteadores trocam e negociam os parâmetros que usarão para controlar sua associação e depois se declaram parceiros. A primeira coisa que os parceiros fazem é sincronizar o banco de dados de estado de enlace (Link State Database), trocando mensagens que relatam cada enlace que conhecem. Para um roteador novo, isso começará apenas com enlaces locais que sabem que estão ativos – os enlaces das sub-redes conectadas e os enlaces recentemente abertos até o parceiro –, mas, se o roteador já tiver recebido informações de outros roteadores, o sincronismo incluirá informações sobre outros enlaces dentro da rede. As informações sobre cada enlace são enviadas com LSA (Link State Advertisement) ou LSP (Link State Packet), que é formatado e embutido em uma mensagem de acordo com regras do protocolo de roteamento específico (Farrel, 2005). Dessa forma, dois roteadores que se tornam parceiros rapidamente alcançam uma posição de ter os bancos de dados de estado de enlace idênticos, ou seja, ambos conhecem a mesma lista de enlaces dentro da rede. Daí por diante,


29/10/2012 14:57:20


como funcionalidade desse algoritmo, sempre que um enlace muda de estado, o dispositivo que detecta a alteração cria um LSA que diz respeito àquele enlace (rota) e, em seguida, o LSA é propagado para todos os dispositivos vizinhos que usam um endereço especial de multicast (endereço de um roteador para um grupo de roteadores). Cada dispositivo de roteamento recebe uma cópia do LSA, encaminha-o para todos os dispositivos vizinhos e, em seguida, atualiza a sua base de dados topológica. Esse encaminhamento de LSA é conhecido como inundação (flooding) e é necessário para garantir que todos os dispositivos de roteamento aprendam sobre as alterações, para que eles possam atualizar seus bancos de dados e criar uma tabela de roteamento atualizada, que irá refletir a nova topologia (Paquet e Teare, 2003). Este processo pode ser visualizado na Figura 1.10.

Figura 1.10 – Exemplo do algoritmo de estado de enlace

O processo de inundação (flooding) poderia ocupar uma grande quantidade de largura de banda da rede e resultar em LSAs enviados aos roteadores que já possuem a informação. Por isso, a maioria dos protocolos de roteamento que usam o algoritmo de estado de enlace requer um projeto hierárquico e, assim, é possível reduzir a necessidade de flooding de LSA para todos os dispositivos do


29/10/2012 14:57:20

20 Redes MPLS

domínio de roteamento, porque o uso de áreas (segmentação lógica formada por alguns roteadores) restringe o flooding ao limite lógico da área, e não a todos os dispositivos do domínio. Em resumo, quaisquer mudanças que ocorram em uma área devem causar o recálculo da tabela de roteamento apenas naquela área, e não em todo o domínio. Um exemplo de um protocolo de roteamento por estado de enlace é o OSPFv2, definido na RFC 1247 (RFC 1247), que é um dos protocolos IGPs de grande utilização no mercado, inclusive em backbones MPLS (Enne, 2009), por se tratar de um protocolo de larga escalabilidade. Os sistemas autônomos trocam informações de roteamento usando alguns outros meios, como um protocolo de roteamento por vetor caminho (path vector). Dentro da Internet, existe a exigência de conectar redes e sistemas autônomos divergentes que compõem a Internet em geral, e isso é feito usando protocolos EGPs. Esses protocolos utilizam uma propriedade de resumo de rota dos protocolos de roteamento por vetor caminho para permitir que os sistemas autônomos sejam caracterizados dentro das rotas anunciadas, tornando-os muito mais escaláveis e flexíveis. Para esse tipo roteamento, entre sistemas autônomos, é utilizado o protocolo BGP (Border Gateway Protocol), que foi definido na RFC 4271 (RFC 4271). O roteamento vetor caminho tem uma vantagem significativa, uma vez que ele permite que um roteador escolha uma rota com base não apenas na distância ou custo associados à rota, mas também examinando os roteadores e enlaces que compreendem o caminho, ou seja, as decisões são tomadas em políticas de roteamento. Essas políticas podem ser elaboradas por meio de regras locais, baseadas no conhecimento de enlaces que são passíveis de erro, vulneráveis a ataque de segurança ou dispendiosos financeiramente. Desse modo, é possível determinar os melhores caminhos para encaminhamento de pacotes. Um problema sério com o roteamento baseado em vetor caminho é que cada roteador na rede pode aplicar diferentes políticas. Os roteamentos por vetor de distância e estado do enlace são técnicas de roteamento, mas utilizam uma política de menor custo (métrica), e todas as rotas na rede se utilizam da mesma política – isso significa que é possível prever o comportamento da rede e saber a rota que o diagrama seguirá em uma rede estável, uma vez iniciada. Não é difícil ver como essa previsibilidade poderia falhar catastroficamente assim que roteadores aplicassem políticas diferentes um do outro ou diferentes da política de menor custo.


29/10/2012 14:57:21


Um exemplo deste tipo de ocorrência foi o sequestro do prefixo do YouTube. No YouTube pode ser visto um vídeo gerado para esse caso (YouTube, 2010). Por determinação do governo paquistanês, o tráfego do YouTube deveria ser bloqueado para evitar o acesso ao trailer de um filme anti-islâmico. Para cumprir essa ordem, a operadora Pakistan Telecom gerou o anúncio de um prefixo mais específico do que o utilizado pelo YouTube, com o intuito de direcionar todos os acessos a ele para uma página que dizia “YouTube was blocked”. No entanto, a operadora anunciou essa nova rota a seu upstream provider (primeiro erro), que, além de não verificar a nova rota (segundo erro), propagou-a por toda a Internet (terceiro erro). Com isso, todo o tráfego do YouTube passou a ser direcionado para o Paquistão e foi descartado (Santos, Rodrigo et al, 2009). Na Tabela 1.2 são descritas as características dos principais protocolos de roteamento que serão utilizados no decorrer deste livro. Em seguida, faremos uma breve descrição destes protocolos.

Tabela 1.2 – Comparação dos protocolos de roteamento escaláveis

Protocolo

IGP ou EGP

Algoritmo

OSPF IS-IS BGP

IGP IGP EGP

Estado de enlace Estado de enlace Vetor caminho

Hierarquia Requerida Sim Sim Não

1.4.1 – O protocolo OSPF Criado pelo IETF (Internet Engineering Task Force) em 1988, o OSPF é um protocolo de roteamento do tipo estado de enlace, que envia anúncios sobre o estado da conexão a todos os outros roteadores em uma mesma área hierárquica e usa o algoritmo SPF (Shortest Path First) para calcular o caminho mais curto para cada nó. Tratase um protocolo IGP, de código aberto e amplamente divulgado na literatura. Foi projetado com o objetivo de substituir o protocolo RIP (Routing Information Protocol), resolvendo diversas limitações que este apresenta, e abordar as necessidades das redes grandes e escaláveis, as quais não eram abrangidas pelo RIP. A versão mais recente do protocolo para funcionalidade com o IPv4 é o OSPF versão 2 (OSPFv2), sendo o OSPF versão 3 (OSPFv3) utilizado para o IPv6 (Doyle e Carroll, 2006). Podemos citar algumas das principais características desse protocolo: •• Não há limite no custo máximo de uma rota;


29/10/2012 14:57:21

22 Redes MPLS

•• O OSPF pode efetuar o balanceamento de carga; •• A convergência é mais rápida do que o RIP, já que as alterações de roteamento são difundidas imediatamente e são calculadas em paralelo; •• Tem suporte a VLSM (Variable Length Subnet Mask), ou máscara de sub-redes de tamanho variável, técnica que permite a divisão de sub-redes em sub-redes, com o objetivo de reduzir a perda de endereços IPs. O protocolo OSPF envia anúncios sobre o estado da conexão a todos os outros roteadores em uma mesma área hierárquica e usa o algoritmo SPF para calcular o caminho mais curto para cada nó. O cálculo do OSPF seleciona o caminho de menor custo para uma rede, da origem ao destino, usando apenas os enlaces ativos. O roteamento por estado de enlace apresenta um problema totalmente diferente dos protocolos de roteamento por vetor distância e vetor caminho. No protocolo de roteamento por estado de enlace, cada roteador possui uma visão completa da rede, fornecida pelas informações de todos os roteadores na rede, mas os roteadores precisam construir uma tabela de roteamento “do zero”, usando apenas a informação do caminho mais curto. Não é uma exigência que todos os roteadores usem o mesmo mecanismo para calcular os caminhos mais curtos, porque todos eles chegam em resultados coerentes. Apesar disso, essa coerência é tão importante que os dois principais protocolos de roteamento por estado de enlace, o OSPF e o IS-IS, exigem o uso do algoritmo Shortest Path First. O algoritmo de Dijkstra (como também é conhecido o algoritmo SPF) é um modo relativamente eficaz e simples de criar uma tabela de roteamento a partir de um conjunto de informações de estado de enlace. Um ponto importante é que o algoritmo deve preencher totalmente a tabela de roteamento de uma só vez, calculando os caminhos mais curtos para todos os destinos. A partir de um nó específico, cada roteador vizinho é acrescentado a uma lista de candidatos, que é ordenada por custos (métricas) dos enlaces até os vizinhos, com o enlace de menor custo em primeiro lugar. Em muitos backbones, há a necessidade de fazer cálculos de SPF que também consideram outros atributos do tráfego nos enlaces disponíveis. Essas outras considerações oferecem restrições ao algoritmo SPF, transformando-o em cálculo de CSPF (Constrained Shortest Path First). No SPF é valido usar diferentes caminhos para o destino contendo o mesmo custo. Esse roteamento é chamado de ECMP (Equal-Cost Multi-Path), que é


29/10/2012 14:57:21


uma boa solução quando se trata de protocolos de roteamento por estado de enlace. Como exemplo, em um backbone de uma operadora de telecomunicações, pode-se decidir oferecer um balanceamento de carga de tráfego entre diferentes enlaces de diferentes velocidades usando um recurso de roteamento ECMP, cujo objetivo é fazer balanceamento de carga do tráfego entre diferentes caminhos de forma a melhor distribuir o tráfego pela rede.

1.4.2 – O protocolo IS-IS O protocolo IS-IS foi concebido pela ISO (International Organization for Standardization) e, portanto, pode ser mapeado diretamente ao modelo OSI (Open Systems Interconnection). De acordo com (Martey e Sturgess, 2002), o protocolo IS-IS tem maior popularidade na Internet que na arquitetura OSI. Trata-se de um protocolo que faz roteamento por estado de enlace, tendo suporte ao balanceamento de carga e a VLSM, sendo um protocolo para atuação intradomínio (dentro de um mesmo sistema autônomo). Embora tenha sido projetado para roteamento ISO, ele foi adaptado para uso em ambientes IPs, daí a origem do termo Integrated IS-IS, muito utilizado atualmente para se referir ao uso desse protocolo nas redes IPs. Existem diversas semelhanças entre o protocolo IS-IS com o protocolo OSPF, das quais podemos destacar: •• ambos são protocolos de roteamento que fazem uso do algoritmo de estado de enlace; •• aceitam VLSM; •• possuem tipos específicos de roteadores definidos em diferentes partes da rede; •• seguem uma hierarquia, portanto são hierárquicos; •• podem fazer balanceamento de carga; •• ambos possuem capacidades de autenticação. Existem também algumas diferenças entre os dois protocolos, das quais poderíamos citar a forma como ambos manipulam pacotes de “Hello”, que são utilizados para formação das adjacências entre os vizinhos, já que no OSPF apenas um tipo de “Hello” é definido, e em redes IS-IS os roteadores são capazes de enviar dois tipos distintos de pacotes “Hello”: Nível 1 e Nível 2. Outra diferença é com relação aos tipos de roteadores que são utilizados por esses protocolos, pois,


29/10/2012 14:57:21

24 Redes MPLS

apenas por possuírem nomenclaturas diferentes, pode haver o mapeamento entre eles, devido às suas funcionalidades (Doyle e Carroll, 2006).

1.4.3 – O protocolo BGP O BGP é um protocolo utilizado para comunicação inter-AS, ou seja, para comunicação entre sistemas autônomos, também denominado de EGP (Exterior Gateway Protocol). Na Figura 1.11 podemos perceber a atuação desse protocolo na interligação entre os sistemas autônomos 65000, 65500, 65250 e 65520, os quais têm influência direta na determinação do caminho que será utilizado pelo BGP, já que o BGP toma decisão de roteamento com base no caminho percorrido entre os ASs, chamado de protocolo de vetor caminho.

Figura 1.11 – O protocolo BGP – utilizado entre AS da Internet

Seu principal objetivo é fornecer um sistema de roteamento entre domínios que garanta a troca, livre de loops, das informações de roteamento entre os sistemas autônomos. A divulgação das informações de roteamento BGP é feita entre roteadores que estabelecem uma relação de vizinhança, o que chamamos de peers (pares). Para que tal estabelecimento ocorra é necessário que dois roteadores tenham conexão direta entre eles ou que algum protocolo IGP trate de garantir a alcançabilidade. Para garantir a alcançabilidade e a confiabilidade entre todas as redes da Internet faz-se necessário que seja utilizada uma forma confiável de troca de informações deste protocolo. Para tanto, o BGP faz uso do protocolo TCP (porta 179) para o transporte das informações de roteamento entre dois roteadores que trocam informações deste protocolo.


29/10/2012 14:57:21

CAPÍTULO 2. A Arquitetura IP sobre MPLS

Para entendimento da tecnologia MPLS, é necessário que tenhamos em mente alguns conceitos fundamentais. Este capítulo é dedicado à discussão sobre os aspectos ligados à tecnologia MPLS. Descreveremos o surgimento da tecnologia, a diferença entre o roteamento convencional e baseado em rótulos, o formato do cabeçalho MPLS, a estrutura do MPLS, detalhando o plano de controle e encaminhamento, e os principais componentes da sua arquitetura. Para concluir, exibimos como se dá o funcionamento da tecnologia, suas vantagens e desvantagens.

2.1 – Surgimento da tecnologia Na segunda metade da década de 1990, a tecnologia ATM, embora ainda com preço elevado e protocolo complexo em planos e camadas (Tanenbaum, 2011), já era a tecnologia dominante para a construção de backbones. Ao mesmo tempo, já se sabia que a pilha de protocolos TCP/IP era um padrão de fato no mundo, e que todas as tecnologias que fossem desenvolvidas a partir de então deveriam ser compatíveis com esses protocolos. No entanto, a natureza da tecnologia ATM, com células de tamanho fixo e qualidade de serviço intrínseca, difere totalmente da natureza do protocolo IP. O mapeamento de pacotes IPs no ATM é uma tarefa complexa, já que os processos de segmentação em pequenas células e a remontagem dos pacotes acarretam desperdício de banda passante, acrescentando informações adicionais e exigindo mais processamento dos roteadores. Desse modo, a união desses dois mundos nunca permitiu uma utilização plena e harmônica das duas tecnologias. Nessa mesma década (1990) surgiram pesquisas que levaram a uma quebra total de paradigma e foram inicialmente chamadas de “comutação IP”. Alguns fabricantes entendiam que pacotes IPs não precisavam ser roteados nos núcleos 25


29/10/2012 14:57:22

26 Redes MPLS

da rede e que era possível adquirir a qualidade de serviço de redes ATM por meio da comutação de pacotes IPs. Tal comutação seria realizada por rótulos adicionados a cada pacote. Algumas empresas começaram a desenvolver tecnologias baseadas na utilização de rótulos. Porém, devido à incapacidade de interação entre essas tecnologias desenvolvidas, das quais podemos citar: IP Switching (Ipsilon) (Newman et al, 1996), CSR – Cell Switched Router (Toshiba), Tag Switching Architecture (Cisco) (Rekhter et al, 1997), ARIS – Aggregate Route-based IP Switching (IBM), SITA – Switching IP Through ATM (Telecom Finland) e IP Navigator (Ascend) (Davie e Rekhter, 2000), a IETF (Internet Engineering Task Force) criou, em dezembro de 1996, um grupo de trabalho visando à padronização dessas tecnologias. Assim, o MPLS é uma tecnologia desenvolvida no âmbito do IETF (Lucek e Minei, 2005), inicialmente como uma tentativa de padronizar a comutação de pacotes baseada na troca de rótulos e, com isso, melhorar a eficiência de fluxos de tráfegos através da rede, modificando um paradigma fundamental até então existente nas redes IPs com a inserção de um rótulo ao datagrama, propiciando assim a comutação IP.

2.2 – Roteamento convencional x baseado em rótulos A tecnologia IP deverá continuar sendo a principal ferramenta adotada por provedores de serviços. Tal tecnologia, aliada ao MPLS e à possibilidade de unificar as comunicações de voz, vídeo e dados, proporciona benefícios econômicos e tecnológicos para as operadoras. Por padrão, o protocolo IP possui como base para encaminhamento de pacotes a análise do endereço IP de destino existente no cabeçalho do pacote da camada de rede. “Este processo também é tradicionalmente chamado de hop-by-hop packet forward” (Pepelnjak e Guichard, 2000). Principalmente devido ao crescimento mundial da Internet (Harnedy, 2002), a demanda de tráfego requerida pelos provedores de serviços (ISPs) aumentou bastante. Para suportar esse crescimento, os ISPs precisam de roteadores de alto desempenho, pois, além da crescente demanda por banda, eles precisam lidar com o crescente número de nós na rede e, consequentemente, com um aumento nas tabelas de roteamento. O processo de roteamento efetuado pelo elemento roteador é complexo e suporta vários protocolos e tipos de interfaces. Os switches (comutadores) são


29/10/2012 14:57:22

A Arquitetura IP sobre MPLS 27

mais simples, fazendo com que a sua relação custo/desempenho seja melhor do que a dos roteadores. De acordo com a referência (Pepelnjak e Guichard, 2000), os switches oferecem um desempenho muito superior na comutação de células ou segmentos que os roteadores para encaminhamento de pacotes. Isso se deve ao fato de que o tipo das informações a serem analisadas pelos switches é basicamente mais simples, tornando o processo de encaminhamento dos segmentos muito mais rápido, fato esse que levou a maior parte dos backbones IPs a serem implementados utilizando uma rede ATM em seu núcleo, de acordo com a Figura 2.1. O surgimento de uma nova tecnologia normalmente dar-se-á porque a tecnologia atual não atende às necessidades requeridas, podendo ser funcionais ou por desempenho. O MPLS surgiu como uma tecnologia que oferece algumas funcionalidades não existentes em redes IPs convencionais. O MPLS é uma tecnologia aberta que foi apresentada inicialmente como uma solução que possibilitava melhorar o desempenho das redes IPs na função de encaminhamento de pacotes IPs, combinando o processo de roteamento de nível 3 com a comutação de nível 2 para realizar o encaminhamento de datagramas através de pequenos rótulos de tamanho fixo. Tais rótulos são números utilizados no protocolo MPLS e, através destes, a decisão de qual interface encaminhar o datagrama é tomada (Rosen et al, 2001a).

Figura 2.1 – Backbone de uma rede ATM


29/10/2012 14:57:22

28 Redes MPLS

Segundo Rosen (Rosen et al, 2001a), a comutação de rótulos multiprotocolos combina a funcionalidade dos protocolos de roteamento da camada de rede e a comutação por rótulos, além de fornecer benefícios significativos às redes com IP e ATM, ou uma combinação de outras tecnologias no nível da camada de rede. Portanto, em uma arquitetura IP sobre MPLS, as informações necessárias para o encaminhamento são obtidas do cabeçalho MPLS (32 bits), que é bem menor e menos complexo que o cabeçalho IP (20 bytes), com isso contribuindo para que os equipamentos de menor poder de processamento e armazenamento tenham desempenho melhor nesse tipo de arquitetura em relação a outras arquiteturas. Outra vantagem significativa da arquitetura IP sobre MPLS que podemos destacar diz respeito ao encaminhamento de datagramas ao longo de um caminho. Em redes IPs convencionais, todos os roteadores da topologia precisam saber a melhor rota em sua tabela de roteamento para encaminhar o pacote ao seu destino pelo melhor caminho possível. Já o protocolo MPLS trabalha com encaminhamento dos pacotes baseado em rótulos, pois os roteadores de núcleo, conhecidos como P (Provider), não têm acesso ao endereço IP de destino do pacote; assim, não há inteligência de roteamento nesses roteadores de núcleo, e sim o encaminhamento local, de uma interface para outra, tomando como base os valores dos rótulos dos pacotes, ou seja, fazendo um processo apenas de comutação de rótulos. A Tabela 2.1 mostra uma comparação entre a arquitetura IP convencional e a arquitetura IP baseada em rótulos: Tabela 2.1 – Arquitetura IP convencional e arquitetura IP baseada em rótulos

Tipos de roteamento IP Convencional

Baseado em rótulos

Análise de todo cabeçalho IP

Verificação dos pacotes a cada salto em todo caminho na rede.

Verificação dos pacotes apenas uma vez no ingresso do caminho virtual.

Suporte para dados Unicast e Multicast

Necessita de roteamento especial para Multicast e algoritmos de encaminhamento. Baseado no endereço de destino no cabeçalho do pacote IP.

Necessita de somente um algoritmo de encaminhamento.

Decisão de roteamento


Baseado em vários parâmetros: endereço de destino no cabeçalho IP, QoS, tipo de dados, etc.

29/10/2012 14:57:22


Hoje, porém, a tecnologia MPLS vem sendo considerada de grande importância, não só por oferecer um mecanismo rápido de encaminhamento de pacotes, mas também por oferecer novas potencialidades, as quais serão descritas no decorrer deste livro.

2.3 – O cabeçalho MPLS O item mais importante para o MPLS é o rótulo (De Ghein, 2007). O rótulo é um identificador curto, de 4 bytes, e com significado local no roteador que é usado para identificar uma FEC (Forwarding Equivalent Class), isto é, um grupo de pacotes IPs que são enviados na mesma maneira, sobre o mesmo trajeto e com o mesmo tratamento de transmissão. Uma FEC pode corresponder a uma subnet do endereço IP de destino, mas pode igualmente corresponder a qualquer classe de tráfego que o roteador de borda considera significativo. Como exemplo, todo tráfego com o mesmo valor de “IP Precedence” pode constituir uma FEC. O rótulo associa pacotes às respectivas conexões; é algo semelhante ao VPI/VCI (Virtual Path Identifier/Virtual Circuit Identifier) no ATM e DLCI no Frame Relay. Seu formato é apresentado na Figura 2.2 e, em seguida, é descrita a função de cada campo. Na Figura 2.3 podemos visualizar os campos do cabeçalho MPLS através de uma captura feita com o analisador Wireshark (Wireshark, 2012). •• Label (Rótulo): contém o valor do rótulo MPLS. Como o tamanho é de 20 bits, esse valor pode variar de 0 a (220 -1), ou 1.048.575. Existem alguns valores que são reservados ao protocolo e têm significados especiais (Rosen et al, 2001b). ○○ 0 – IPv4 Explicit NULL Label: indica que o rótulo deve ser retirado, e, desse ponto em diante, o roteamento será feito com base no endereço de rede. ○○ 1 – Router Alert Label: indica que o datagrama deve ser analisado pelo software local. O encaminhamento seguinte é definido pelo próximo rótulo da pilha MPLS. ○○ 2 – IPv6 Explicit NULL Label: mesma funcionalidade do valor 0, mas aplicada ao protocolo IPv6.

Figura 2.2 – Cabeçalho MPLS


29/10/2012 14:57:22

30 Redes MPLS

○○ 3 – Implicit NULL Label: valor utilizado pelos LSRs (Label Switch Routers) para a distribuição de rótulos (LDP – Label Distribution Protocol). ○○ 4 a 15 – Reservados para definições futuras. ○○ 16 a (220 -1) – Rótulos utilizáveis para roteamento. •• EXP (Experimental Bits): este campo é composto por três bits e são utilizados para alterar os algoritmos de enfileiramento (queuing) e descarte; dessa forma é possível dar prioridade a determinados pacotes. Usado atualmente por classes de serviços (CoS). •• BoS (Bottom of Stack): formado por apenas um bit, este campo permite a criação de uma pilha hierárquica de rótulos. Indica se o cabeçalho ao qual o pacote pertence é o último da pilha MPLS. Todos os cabeçalhos MPLS devem ter esse bit em 0, e através desse campo um roteador de saída tem condições de decidir se o próximo encaminhamento será baseado em MPLS ou IP. •• TTL (Time To Live): este campo é formado por 8 bits e funciona de maneira semelhante ao TTL do protocolo IP. Ele especifica um limite de quantos saltos o pacote pode atravessar. Quando um datagrama entra em um roteador de borda MPLS, o valor inicial do TTL no cabeçalho MPLS deve ser igual ao valor do TTL do cabeçalho IP e decrementado de 1 em cada roteador. Na saída do caminho, o roteador deve copiar o valor do TTL do cabeçalho MPLS para o TTL do cabeçalho IP.

Figura 2.3 – Campos do cabeçalho MPLS – captura via Wireshark


29/10/2012 14:57:22


Um cabeçalho MPLS pode ser encapsulado em diversos protocolos de nível 2 e pode encapsular qualquer protocolo de nível 3 (Rosen et al, 2001a). Alguns desses protocolos possuem campos que podem ser utilizados para transportar o rótulo MPLS. Como exemplo poderíamos citar os campos VPI e VCI do cabeçalho ATM. Em protocolos que não possuem esses campos, tais como Ethernet e PPP (Point-to-Point Protocol), o cabeçalho MPLS é inserido entre os cabeçalhos de nível 2 e nível 3. A Figura 2.4 ilustra três exemplos de inserção do protocolo MPLS em uma arquitetura de rede. (A)

(B)

(C)

Figura 2.4 – Cabeçalho MPLS em diferentes protocolos da camada

A Figura 2.4(A) exibe uso do MPLS em redes ATM. Nesse caso, o valor do rótulo desse cabeçalho é armazenado nos campos VPI/VCI, e o valor do rótulo desse cabeçalho MPLS deve ser zero e ignorado pelos roteadores durante a transmissão, sendo considerado apenas o valor do VPI/VCI. Os valores EXP, BoS e TTL devem ser obtidos no primeiro cabeçalho da pilha MPLS. Já nos casos em que não há um campo específico para o valor do rótulo, o cabeçalho MPLS deve ser inserido entre os cabeçalhos das camadas 2 e 3; como exemplo, temos o Ethernet (Figura 2.4(B)) e PPP (Figura 2.4(C)).


29/10/2012 14:57:23

32 Redes MPLS

No transporte de datagramas rotulados pelo MPLS, o protocolo PPP atribui o valor hexadecimal 0281 ao campo “protocolo” no seu cabeçalho, enquanto que, no Ethernet, o campo “tipo” pode receber o valor hexadecimal 8847. A Tabela 2.2 exibe o nome do protocolo identificador no cabeçalho de camada 2 e valores para os diferentes tipos de encapsulamento de camada 2. Tabela 2.2 – Valores do protocolo identificador MPLS para tipos de encapsulamento de camada 2

Tipo de encapsulamento de camada 2

Nome do protocolo odentificador de camada 2

Valor (Hex)

PPP

PPP Protocol Field

0281

Ethernet/802.3 LLC/SNAP encapsulation

Ethertype value

8847

HDLC

Protocol

8847

Frame Relay

NLPID (Network Level Protocol ID)

80

O MPLS suporta comutação de rótulos com operações hierárquicas, baseadas na habilidade do pacote de carregar mais de um rótulo. O processamento de um pacote rotulado é completamente independente do nível de hierarquia, ou seja, o nível do rótulo é irrelevante para o roteador MPLS. O processamento é sempre baseado no rótulo do topo (top label), abstraindo-se dos outros rótulos que existam abaixo deste.

2.4 – Estrutura do MPLS Por se tratar de uma ligação entre as camadas 2 e 3, já que o MPLS utiliza o sistema de endereçamento dos protocolos de nível 3 e o sistema de comutação da camada 2, o MPLS pode ser considerado um protocolo de camada 2,5 (Harnedy, 2002). Assim, por ser uma camada de integração, é necessário que esta seja compatível com diversos protocolos da camada 3, assim como tecnologias de camada 2, o que justifica o “MultiProtocol” do MPLS. É possível separar o plano de controle do plano de encaminhamento na tecnologia MPLS, conforme Figura 2.5, podendo, dessa forma, tratar os planos


29/10/2012 14:57:23


separadamente. Devido a essa característica, caso se deseje mudar a estratégia de roteamento na rede, não será necessário mudar os dispositivos de encaminhamento. O plano precisa reagir quando houver mudanças na rede, mas não é envolvido no processamento individual dos pacotes. No plano de controle é construída e mantida a tabela de encaminhamento do nó em uso. É nesse plano que estão localizadas as funções de controle, tais como sinalização, roteamento, policiamento de tráfego, conversão de endereços, dentre outras. Os protocolos de roteamento, tais como RIP, OSPF, IS-IS e BGP, atuam nesse plano e são usados para trocar informações de roteamento entre os componentes de controle. Já o plano de encaminhamento, que tem sua operação ditada pelo plano de controle, é responsável pelo encaminhamento do tráfego baseado apenas em rótulos. Em resumo, o que os roteadores da rede MPLS fazem é utilizar o plano de controle para, através de um protocolo de roteamento, descobrir e escolher os melhores caminhos até o destino.

Figura 2.5 – Componentes de controle/encaminhamento

2.5 – Componentes da arquitetura A seguir descreveremos os principais termos e componentes de uma arquitetura MPLS, para em seguida explicar o seu funcionamento. A Figura 2.6 exibe os principais dispositivos que fazem parte da arquitetura MPLS. •• Label (rótulo): os rótulos são pequenos identificadores de tamanho fixo, colocados nos pacotes durante seu tráfego pela rede, sendo facilmente processável.


29/10/2012 14:57:23

34 Redes MPLS

Figura 2.6 – Componentes da arquitetura MPLS

•• LDP (Label Distribution Protocol): o protocolo LDP é o responsável pela distribuição de rótulos para os prefixos IPs em uma rede MPLS. Os rótulos são atribuídos a cada prefixo IGP aprendido na tabela de rotas global de um roteador. Todos os prefixos anunciados por um mesmo equipamento vizinho recebem o mesmo rótulo. Com isso, os elementos intermediários em uma rede MPLS (elementos conhecidos como P) não precisam conhecer a tabela de roteamento completa da rede. Um pacote IP com rótulo é encaminhado para o próximo enlace (next-hop) baseado somente no rótulo externo, isto é, aquele alocado pelo LDP com base na tabela de roteamento, e isso ocorre até a chegada à rede de destino. Por padrão, o LDP é configurado para formar adjacências somente com seus vizinhos diretamente conectados. Isso é realizado através de um pacote com o endereço de multicast 224.0.0.2 (“all routers”) e TTL igual a 1. Assim que os vizinhos são descobertos inicia-se a troca de rótulos, e as sessões são mantidas através de “Hellos” periódicos. A perda de três “Hellos” faz com que a sessão seja desfeita. Uma falha direta na interface faz com que a sessão seja excluída imediatamente. •• LIB (Label Information Base): é uma tabela que contém os diversos vínculos de rótulos que um LSR (Label Switch Router) recebe sobre o protocolo LDP, ou seja, uma tabela que apresenta informações correlacionando os rótulos às interfaces do roteador. É através desta tabela que o LSR determina para qual interface deverá encaminhar o pacote recebido. A Figura 2.7 exibe a tabela de encaminhamento.


29/10/2012 14:57:23


Figura 2.7 – Tabela de encaminhamento

•• FIB (Forwarding Information Base): é uma tabela que controla a decisão de encaminhamento de um roteador. Para todo possível endereço IP de destino, uma pesquisa de prefixo longo é executada pela FIB. Se um endereço é localizado na tabela, o roteador saberá para qual interface de saída deverá enviar o pacote. Se nenhum endereço é localizado, o pacote é descartado. Os conteúdos da FIB refletem o estado atual da topologia IP que cerca o roteador, como determinado pelos protocolos IPs de roteamento, por exemplo, Open Shortest Path First (OSPF) ou Protocolo de Gateway de Borda versão 4 (BGP4). •• LFIB (Label Forwarding Information Base): é uma tabela que indica onde e como encaminhar os pacotes. É criada por equipamentos pertencentes a um domínio MPLS. A LFIB contém uma lista de entradas que consistem de uma subentrada de ingresso e uma ou mais subentradas de egresso, rótulo de saída, interface de saída, componentes de saída de nível de enlace. É baseada nas informações obtidas pelo LSR através da interação com os protocolos de roteamento. •• FEC (Forwarding Equivalence Class): uma FEC consiste em um grupo de pacotes que podem ser tratados de forma equivalente para propósitos de encaminhamento. Como exemplo, um grupo de pacotes cujos endereços de origem e destino são os mesmos. Pacotes de um mesmo fluxo de dados geralmente pertencem à mesma FEC. Uma FEC é representada por um rótulo e cada LSP (Label Switch Path) é associado a uma FEC. Quando um LER (Label Edge Router) recebe um pacote, verifica a qual FEC


29/10/2012 14:57:23

36 Redes MPLS

ele pertence e o encaminha através do LSP correspondente. Portanto, existe uma associação “pacote-rótulo-FEC-LSP”, e esta associação “pacote-FEC” ocorre apenas quando o pacote entra na rede MPLS, proporcionando grande flexibilidade e escalabilidade a este tipo de rede, conforme é exibida na Figura 2.8.

Figura 2.8 – Associação “pacote-rótulo-FEC-LSP”

Seguem alguns exemplos de FECs (De Ghein, 2007): •• Pacotes com um endereço IP de destino combinando com um certo prefixo; •• Pacotes de Multicast pertencentes a um certo grupo; •• Pacotes com o mesmo tratamento de encaminhamento, baseados no campo IP Precedence ou IP DiffServ Code Point (DSCP). •• LSR (Label Switch Router): é um equipamento capaz de realizar encaminhamento de datagramas de rede através de rótulos MPLS. Ele participa ativamente no estabelecimento de LSP, usando protocolo de sinalização de rótulo, tais como: LDP, RSVP-TE (Resource Reservation Protocol – Traffic Engineering) e BGP, e no encaminhamento de tráfego baseado nos caminhos estabelecidos. Ao receber um pacote, cada LSR troca o rótulo existente por outro, passando o pacote para o próximo roteador e assim por diante. Existem basicamente três tipos de LSRs: ○○ LSR de Borda de Entrada: é um LSR (roteador ou switch com funções de roteamento) de entrada de uma rede MPLS. Ele


29/10/2012 14:57:23


realiza o processamento e a classificação inicial do pacote e aplica o primeiro rótulo na entrada (ingress) do pacote no domínio MPLS. Os ingress LSRs analisam as informações do cabeçalho de rede e associam cada datagrama a uma FEC. Toda FEC tem um rótulo associado que será utilizado no encaminhamento para o próximo nó. ○○ LSR de Trânsito: são LSRs intermediários que têm a função de apenas fazer a comutação, ou seja, a troca de rótulos, e encaminhar o datagrama para o próximo nó. Eles oferecem comutação em alta velocidade, sendo este um processo que mais contribui para o ganho de desempenho na utilização do protocolo MPLS, já que não precisam mais analisar cabeçalhos da camada de rede (IP). ○○ LSR de Borda de Saída: é um LSR responsável pela retirada do rótulo do pacote e encaminhamento ao seu destino final.

Observação: os LSRs de Entrada (Ingresso) e os LSRs de Saída (Egresso) também são conhecidos como Edge LSRs, LER (Label Edge Router) ou PE (Provider Edge). Já o LSR de Trânsito é também conhecido com P (Provider).

Apesar de não fazer parte do domínio MPLS, os roteadores que fazem parte do ambiente dos clientes possuem uma nomenclatura no cenário MPLS, sendo conhecidos como CEs (Customer Edges). Tais elementos não têm conhecimento da tecnologia MPLS, e o tráfego gerado é baseado apenas nos protocolos roteáveis, dos quais destacamos o protocolo IP. •• LSP (Label Switched Path): conforme pode-se observar na Figura 2.6, um LSP é uma sequência ordenada de LSRs, sendo o primeiro um LSR de ingresso e o último um LSR de saída, ou seja, é o caminho entre o nó de ingresso, possíveis nós intermediários, e o nó de egresso de uma rede MPLS. É similar a um circuito virtual ATM ou Frame Relay, sendo unidirecional no sentido da origem para o destino, podendo ser estático ou dinâmico.


29/10/2012 14:57:23

38 Redes MPLS

2.6 – Funcionamento Nas redes MPLS os pacotes são rotulados assim que entram na rede e são encaminhados apenas com base no conteúdo desses rótulos ao longo do caminho. Os roteadores tomam decisão de encaminhamento com base em tais rótulos, evitando assim o esquema de intenso processo de pesquisa de dados utilizado no roteamento convencional. É possível também que, em vez de um único rótulo, o MPLS permita que os pacotes de dados carreguem uma pilha de rótulos, segundo a ordem de que o último rótulo a ser colocado no pacote deverá ser o primeiro a ser retirado (Lobo, 2008). Comentaremos com maiores detalhes esse processo no capítulo seguinte, que trata dos serviços da tecnologia. Podemos definir basicamente a operação do MPLS em quatro etapas, conforme a Figura 2.9:

Figura 2.9 – Operação do MPLS

•• Etapa 1 – Construção das tabelas de roteamento. Através dos protocolos de roteamento, tais como OSPF e IS-IS, são construídas as tabelas de roteamento, que irão determinar os melhores caminhos para atingir as redes de destino por toda a rede do provedor. Nesta etapa também há a atuação do protocolo LDP, que irá fazer o mapeamento entre rótulos e IPs de destino. Os rótulos serão atribuídos automaticamente, de acordo com os valores citados no item 2.3. •• Etapa 2 – Ingresso dos pacotes na rede. O roteador de borda (Edge LSR) de ingresso recebe os pacotes que irão entrar na rede, executando


29/10/2012 14:57:24


serviços de nível 3 e valor agregado, tais como QoS, e em seguida acrescenta o rótulo aos pacotes. •• Etapa 3 – Encaminhamento dos pacotes na rede. O LSR encaminha pacotes usando o mecanismo de troca de rótulos (Label Swapping). Ao receber o pacote com rótulo, o LSR lê o rótulo, o substitui de acordo com a tabela LFIB e o encaminha, sendo essa ação repetida por todos os roteadores no núcleo do backbone. •• Etapa 4 – Saída do pacote na rede. O roteador de borda (Edge LSR) de saída remove o rótulo e entrega pacotes IPs. Nas Figuras 2.10, 2.11 e 2.12, poderemos acompanhar um exemplo prático de encaminhamento de pacotes baseado em rótulos, de acordo com as etapas citadas. A Figura 2.10 apresenta um processo de roteamento convencional, onde é exibida a entrada de dois pacotes IPs em uma rede MPLS. Através da atuação de um protocolo de roteamento (OSPF, IS-IS), as informações da rede são propagadas e as tabelas de roteamento são construídas. Por exemplo, podemos observar que, no roteador central, todos os pacotes destinados à rede 192.168 serão enviados pela interface 0 e, para a rede 172.16, serão enviados pela interface 1.

Figura 2.10 – Construção da tabela de roteamento IP

Na Figura 2.11 mostra-se a inserção dos rótulos aos pacotes IPs. Através do protocolo LDP, estas associações são anunciadas para os roteadores vizinhos. Por exemplo, vemos que no roteador central o rótulo de saída para a rede 192.168 terá o valor 9, e o rótulo de saída para a rede 172.16 terá o valor 7. Já os rótulos de entrada para tais redes serão 4 e 5, respectivamente.


29/10/2012 14:57:24

40 Redes MPLS

Figura 2.11 – Inserção dos rótulos aos pacotes IPs

Na Figura 2.12, vemos que, quando todas as tabelas estão atualizadas, é estabelecido um LSP pelo qual serão encaminhados os pacotes correspondentes a esta FEC. Podemos notar que a inserção e retirada dos rótulos serão feitas pelos Edge LSRs, e que o roteador de trânsito, ou P (Provider), fará a troca dos rótulos.

Figura 2.12 – Pacotes encaminhados baseados nos rótulos

É importante salientar a existência de uma técnica conhecida como PHP (Penultimate Hop Popping) (Rosen et al, 2001a), que consiste na configuração da retirada do cabeçalho MPLS no penúltimo LSR, e não no LSR de saída. Esta técnica não compromete o funcionamento de um LSP e propicia um ganho de desempenho nos roteadores de borda.


29/10/2012 14:57:24


Sem o uso desta técnica, ou seja, fazendo a retirada do cabeçalho MPLS no LSR de saída, tem-se duas análises do cabeçalho: a análise do valor do rótulo ao receber o pacote rotulado e a análise do próximo cabeçalho MPLS ou do cabeçalho de rede. Porém, fazendo uso da técnica, se o penúltimo LSR fizer a retirada do rótulo MPLS (popping), em vez de uma troca (swap), apenas uma análise do cabeçalho é realizada. Se for um pacote rotulado, será feita a análise e retirada do cabeçalho MPLS; se for um pacote de rede sem cabeçalho MPLS, será feita a análise das informações do cabeçalho de rede. Portanto, trata-se de uma técnica bastante viável, uma vez que, encaminhado para o LSR de saída, o cabeçalho MPLS não tem mais utilidade, pois será removido e encaminhado segundo informações do cabeçalho de rede ou do próximo cabeçalho MPLS.

2.7 – Vantagens do MPLS O MPLS é uma tecnologia utilizada em backbones. Embora a grande motivação de uso da tecnologia seja melhorar a velocidade de encaminhamento dos pacotes na rede, apenas este fator não seria um motivo suficiente para adoção da tecnologia, visto que a capacidade computacional existente nos equipamentos atuais responsáveis pelo roteamento é suficiente para um rápido atendimento ao tráfego. Os algoritmos de encaminhamento de pacotes com alta velocidade agora são implementados no hardware, usando ASICs (Aplication Specific Integrated Circuits); portanto, uma pesquisa de rótulos de 20 bits não é significativamente mais rápida do que uma pesquisa IP de 32 bits (Osborne e Simha, 2002). O MPLS possibilita a melhoria do desempenho no encaminhamento dos pacotes, já que existe uma separação do plano de controle do plano de dados. Existe um ganho na diminuição da latência, já que não há roteamento e sim a comutação dos rótulos. No MPLS há possibilidade de criar túneis. Tal mecanismo é útil para permitir que muitos LSPs sejam tratados da mesma forma no núcleo da rede sem perder sua individualidade nas bordas. Dessa forma, tem-se um ganho na escalabilidade dos LSRs do núcleo da rede. Um dos usos mais importantes do MPLS é facilitar a engenharia de tráfego nas redes IPs de provedores de serviços de telecomunicações. A principal capacidade que o MPLS traz às redes com engenharia de tráfego é a possibilidade de configurar um circuito virtual overlay comutado para o modelo de roteamento da Internet. Outro beneficio no MPLS é a possibilidade de transformar um switch ATM em um LSR.


29/10/2012 14:57:24

42 Redes MPLS

As redes corporativas baseadas em WANs tradicionais podem se beneficiar com MPLS na utilização dos enlaces e otimizar o rendimento bruto da rede utilizando MPLS-TE. De um modo geral, podemos listar alguns benefícios da tecnologia MPLS: • Desacoplamento de roteamento e encaminhamento; • Melhor integração dos mundos IP e ATM; • Redução de custo com a utilização de VPN baseada no protocolo IP; • Escalabilidade; • Flexibilidade; • Priorização de tráfego, assegurando transmissão de dados de modo mais eficiente; • Garantia de níveis de serviços; • Convergência de dados, voz e imagem; • Utilização de serviços, tais como QoS (Quality of Service), VPN e engenharia de tráfego.

2.8 – Desvantagens do MPLS A tecnologia MPLS tem como desvantagem o aumento das informações de controle ocasionado pela adição de rótulos, com a consequente redução de carga útil das informações. Outra desvantagem que podemos apontar é o fato da conexão do cliente ao provedor de serviços passar a ser uma conexão de nível 3, herdando com isto suas vulnerabilidades. Por exemplo, a tabela de rotas do cliente pode ser vista no backbone MPLS.


29/10/2012 14:57:25

CAPÍTULO 3. MPLS – VPN

Atualmente existem algumas aplicações, também chamadas de serviços associados à tecnologia MPLS, que a tornam 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. A motivação real para implantação da tecnologia MPLS na rede são as aplicações que ela permite. Tais aplicações são difíceis de implementar, ou operacionalmente quase impossíveis de realizar com as redes IPs tradicionais (Osborne e Simha, 2002). Alguns desses serviços são: VPNs MPLS, PseudoWire MPLS, QoS MPLS e Engenharia de Tráfego. Detalharemos esses serviços a partir deste capítulo, iniciando pelo serviço MPLS – VPN.

3.1 – VPN – Conceitos Pode-se dizer que uma VPN (Virtual Private Network) é um conjunto de políticas que controlam a conectividade e a qualidade de serviço de uma rede privada. São redes que compartilham um meio físico comum, porém possuem privacidade dos dados através de criptografia. São redes virtuais, pois não possuem enlaces ou linhas dedicados entre as suas extremidades; no entanto, para os usuários e clientes, são “transparentes” e possuem as mesmas funcionalidades de segurança de enlaces dedicados. As VPNs consistem em soluções simples e flexíveis, tratando-se de uma poderosa ferramenta de tunelamento oferecida pelos provedores de serviço de Internet (ISPs). As VPNs foram originalmente introduzidas para permitir aos provedores de serviços o uso de uma mesma infraestrutura comum na emulação de enlaces ponto-a-ponto entre os sites dos clientes, e foram desenvolvidas nos moldes de uma rede geograficamente distribuída ou WAN (Wide Area Network), podendo abranger uma ampla área geográfica, frequentemente um país ou continente, com todos os atributos de segurança, gerenciamento e processamento (Ricci, 2007). 43


29/10/2012 14:57:25

44 Redes MPLS

Uma rede privada virtual ou VPN (Virtual Private Network) é uma área de crescimento importante na Internet. Usando protocolos padronizados, as empresas são capazes de conectar suas redes privadas com segurança usando os recursos econômicos e altamente disponíveis da Internet. O objetivo da Internet é proporcionar comunicação entre os nós das redes de modo irrestrito. Porém, existem muitas situações tais como transações financeiras, pagamentos, etc. nas quais se exige privacidade das informações e uma conectividade controlada. A maneira de baixo custo e eficiente de obter tal resultado é a utilização de VPNs (Guimarães et al, 2006). O crescimento das VPNs tem sido acompanhado por uma explosão nas técnicas disponíveis para prover essa função. A maior parte dessas técnicas utiliza abordagens padronizadas, mas cada uma utiliza protocolos diferentes e possui suas próprias vantagens e desvantagens. O MPLS vem se tornando um suporte fundamental para a disseminação de VPNs, devido a sua aceitação pelas operadoras de telecomunicações em separar os tipos de tráfegos de usuários comuns do tráfego de serviços legados. Uma solução de VPN híbrida que utiliza BGP e MPLS IP VPN é descrita na RFC 4364 (RFC 4364). Esta denominação deriva do fato de que o roteamento inter-AS e a distribuição de rótulos se efetivam com base na RFC 4760 (RFC 4760) e na RFC 3107 (RFC 3107). O MPLS pode ser utilizado para estabelecer VPNs de camada 2 e 3, pois esse protocolo possibilita a criação de túneis, onde as mensagens ponto-a-ponto são criptografadas. O MPLS fornece um mecanismo eficaz para suporte a VPNs. VPNs MPLS utilizam um rótulo adicional para determinar a rede de destino. A grande motivação das VPNs foi o fator custo, pois, ao invés de se utilizar de um grande número de linhas dedicadas para a interconexão entre seus diversos pontos, uma VPN faz uso dos serviços existentes das redes IPs espalhadas mundialmente, para estender as redes corporativas de uma empresa a pontos distantes, como outros escritórios, filiais, parceiros e até mesmo residências. Outro fator motivacional que podemos destacar é que as VPNs podem permitir o acesso a qualquer lugar alcançado pela Internet; e, como a Internet está hoje onipresente, conexões podem ser facilmente estabelecidas.


29/10/2012 14:57:25

MPLS – VPN 45

3.2 – Tipos de VPN Há vários tipos de redes privadas virtuais, das quais iremos destacar: •• VPN Intranet: utilizada, por exemplo, para facilitar a comunicação entre diferentes sites de uma empresa; ver Figura 3.1.

Figura 3.1 – VPN Intranet

•• VPN Extranet: utilizada para conectar uma empresa a seus fornecedores, clientes, etc., conforme ilustrado na Figura 3.2.

Figura 3.2 – VPN Extranet

•• VPN de Acesso Remoto: utilizada para conectar uma empresa a seus empregados que estejam fisicamente distantes. Neste caso, a estação remota disca para o provedor de acesso, conectando-se à Internet, e o software de VPN cria uma rede virtual privada entre o usuário remoto e o servidor de VPN corporativo através da Internet, conforme Figura 3.3.


29/10/2012 14:57:25

46 Redes MPLS

Figura 3.3 – VPN acesso remoto

Para maiores detalhamentos sugerimos consultar a referência (Guimarães et al, 2006). Todos os tipos de VPNs citados se baseiam na tecnologia de tunelamento, que pode ser definida como o processo de encapsular um protocolo dentro de outro; porém, antes de encapsular, este deverá ser criptografado, de forma que, caso seja interceptado durante o transporte, não possa ser lido. O pacote que é criptografado e encapsulado é enviado pela Internet até ao destino, onde é desencapsulado e decriptografado, para entrega ao destinatário. Portanto, o túnel é a denominação do caminho lógico que é percorrido pelos pacotes ao longo da rede. Após alcançar o destino, o pacote é desencapsulado e encaminhado ao seu destino final, conforme ilustrado na Figura 3.4. O MPLS pode ser considerado um meio de montar túneis, e isso o torna adequado para montagem de VPNs de vários tipos. Tais túneis podem ser usados para estabelecer as VPNs de camada 2 para redes Ethernets, ATM, Frame Relay e outros túneis capazes de usar o MPLS como transporte. A forma mais simples de VPN MPLS é uma VPN de camada 2. Neste tipo de VPN, o MPLS é utilizado para criar um túnel, através de LSRs, com o objetivo de conectar redes remotas, como pode ser visualizado na Figura 3.5. Esse tipo de VPN assegura a separação de tráfego em um backbone MPLS. Na Figura 3.5 o túnel é estabelecido


29/10/2012 14:57:25

MPLS – VPN 47

Figura 3.4 – Processo de tunelamento – VPN

do roteador PE (Provider Edge) de entrada, passando pelo roteador P (Provider) até o roteador PE de saída. Cada túnel estabelece um canal virtual (PseudoWire) entre a origem e o destino, para conectar diferentes partes da VPN. O roteador CE (Customer Edge) na rede do cliente vê o backbone MPLS como um circuito ponto-a-ponto.

Figura 3.5 – Processo de tunelamento – VPN MPLS

O MPLS pode ser utilizado para estabelecer VPNs de camada 3, e essas utilizam pilhas de rótulos MPLS para enviar pacotes por túnel através de uma rede IP. Como alternativa, os pacotes MPLS podem ser encapsulados em algum outro mecanismo de tunelamento, para permitir que sejam transportados pelo núcleo do backbone. Esta segunda opção pode ser particularmente útil quando o MPLS for usado dentro da VPN, ou quando muitos pontos da borda oferecem, cada um, acesso a várias VPNs e for desejável reduzir o número de túneis pela rede. As VPNs então serão separadas pelo rótulo acrescentado nos pacotes. Como no exemplo apresentado na Figura 3.5, o roteador PE de entrada acrescenta os rótulos “65” e “13” para diferenciar as VPNs.


29/10/2012 14:57:26

48 Redes MPLS

3.3 – Modelos de VPN O termo VPN é bastante utilizado e as definições variam, mas intuitivamente é possível definir uma VPN considerando primeiro a ideia de rede privada. As empresas com muitas filiais distribuídas geograficamente normalmente criam redes privadas contratando circuitos dedicados de operadoras de telecomunicações, como, por exemplo, E1, E3, STM-1 e STM-4. Nesse tipo de rede a comunicação é restrita apenas aos pontos remotos e à matriz da empresa, o que normalmente é desejável por motivos de segurança, embora o volume de tráfego raramente justifique o custo. Para montar uma rede privada virtual, os circuitos dedicados devem ser substituídos por uma rede compartilhada com outras empresas – compartilhamento de multiplexadores ou switches Frame-Relay e ATM (Gallaher, 2003). Frame Relay e ATM foram as primeiras tecnologias a serem adotadas largamente como VPN. Esse modelo é conhecido como overlay e nele a operadora de telecomunicações não participa do roteamento. Essas redes consistem de vários dispositivos, pertencentes aos clientes e às operadoras de telecomunicações, que são componentes da solução VPN (Lobo, 2008). Um segundo modelo de VPN é o par-a-par (peer-to-peer), onde a operadora de telecomunicações participa do roteamento dos pacotes na rede. Um exemplo de VPNs no modelo par-a-par são as VPNs BGP/ MPLS IP. Uma VPN MPLS combina as melhores características do modelo de VPN overlay e par-a-par.

3.3.1 – O modelo overlay No modelo overlay para VPNs, toda a lógica funcional das VPNs ocorre nos equipamentos dos usuários, limitando a operadora de telecomunicações a fornecer circuitos físicos como, por exemplo, E1, E3 e STM ou circuitos virtuais de redes como Frame Relay ou ATM, mas também o modelo overlay pode prover protocolos de camada 3 – nesse caso, são utilizados túneis para construir as redes overlay, como exemplo, túneis GRE (Generic Routing Encapsulation), L2TP e IPSec para interconectar sites dos clientes. Na Figura 3.6 é possível visualizar um backbone Frame Relay, com comutadores FR (Frame Relay) interligados por vários Circuitos Virtuais Privados (PVCs), formando uma rede completamente conectada (Full Mesh), onde cada circuito virtual tem um custo adicional para ser estabelecido. Portanto, neste modelo, nenhum processo de roteamento ocorre entre o roteador do cliente e o provedor de serviços; dessa forma o provedor de serviços nunca visualiza as rotas do cliente.


29/10/2012 14:57:26

MPLS – VPN 49

Figura 3.6 – VPN overlay com Frame Relay (De Ghein, 2007)

Considerando o roteamento IP e a formação de pares, do ponto de vista do cliente, os roteadores parecem estar diretamente conectados, já que não há envolvimento por parte do provedor em tal processo, conforme mostra a Figura 3.7.

Figura 3.7 – VPN overlay – ponto de vista do cliente


29/10/2012 14:57:26

50 Redes MPLS

O modelo overlay apresenta alguns problemas, entre eles o fato de que, para clientes que precisam de um grande número de pontos interconectados e precisam de conectividade completa entre todos os pontos, seria necessária a configuração de vários canais individuais, o que iria gerar custo adicional para o cliente e custo em nível de configuração, já que cada um desses pontos necessitaria de uma conexão e um roteamento ponto-a-ponto com todos os outros pontos da VPN. Isso torna o modelo não escalável. Comparando o modelo tradicional do overlay das tecnologias ATM ou Frame Relay, as VPNs de camada 3 MPLS fornecem mais escalabilidade em termos operacionais e de gerenciamento, pois elas fazem seus encaminhamentos através dos protocolos TDP/LDP, que geram uma malha completa, ou seja, uma rede completamente conectada (Full Mesh) com vários LSPs, que, no modelo overlay ATM ou Frame Relay, só é possível na criação de vários circuitos virtuais privados.

3.3.2 – O modelo par-a-par No modelo par-a-par para VPNs, as operadoras de telecomunicações participam diretamente dos mecanismos funcionais das VPNs, proporcionando o roteamento entre os roteadores dos clientes e da operadora de telecomunicações. Os CEs (Customer Edges) e PEs (Provider Edges) das tecnologias das VPNs constituem-se em pares no que concerne o processo de roteamento das VPNs. Um exemplo desse tipo de VPN pode ser visualizado na Figura 3.8, onde há os roteadores CEs (Customer Edges), PEs (Provider Edges) e Ps (Providers). Nesse serviço, o backbone da operadora de telecomunicações provê uma conexão Full Mesh de forma a otimizar o encaminhamento dos pacotes entre os pontos.

Figura 3.8 – Modelo par-a-par


29/10/2012 14:57:26

MPLS – VPN 51

O modelo par-a-par não requer a criação de circuitos virtuais e também garante privacidade e isolamento entre os diferentes clientes através de configurações de filtros de pacotes, tais como as listas de acesso (access lists), controlando assim os dados para os clientes e os dados originados destes. Outra maneira de proporcionar o isolamento e a privacidade entre os clientes é através de filtros de rotas, anunciando ou parando rotas para determinados clientes. Os dois métodos podem também trabalhar em conjunto (De Ghein, 2007). Podemos citar algumas das principais vantagens desse modelo em relação ao modelo overlay: •• Oferece serviços em grande escala. •• O roteamento do ponto de vista do cliente se torna mais simples, pois o roteador do cliente troca informações de roteamento com um ou poucos roteadores de borda do provedor de serviços. •• A adição de um novo ponto ou site se torna mais simples, pois o provisionamento pelo provedor de serviços é unicamente adicionar um ponto ou site com um roteador do cliente e configurar um dos protocolos de roteamento entre esse roteador e o roteador do provedor. Já no modelo overlay de VPN, o provedor de serviços precisa provisionar um conjunto inteiro de circuitos virtuais do ponto de origem para o ponto de destino do cliente da VPN. Embora poucas, existem também desvantagens do modelo par-a-par, entre elas o fato de o cliente compartilhar rotas com o provedor e, com isso, não ter controle das rotas fim-a-fim, como no caso do modelo overlay. Outra desvantagem que poderíamos citar diz respeito à sobrecarga que o roteador de borda do provedor poderá enfrentar, já que deverá estar apto a transportar todas as rotas de muitos clientes que deverão estar conectados a ele, além de prover escalabilidade e boa convergência de roteamento.

3.4 – Arquitetura MPLS VPN O MPLS é utilizado para estabelecer VPN par-a-par. Uma VPN MPLS é constituída dos seguintes equipamentos: •• CE – Customer Edge; •• PE – Provider Edge; •• P – Provider. O VPN MPLS é um dos principais serviços oferecidos por essa tecnologia e faz uso do modelo par-a-par.


29/10/2012 14:57:26

52 Redes MPLS

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ária qualquer alteração das configurações da VPN, e sim apenas habilitar um protocolo de roteamento ou efetuar um roteamento estático para que troque informações com o PE. Já o roteador PE executa múltiplas funções, pois ele deve ser capaz de isolar o tráfego se mais de um cliente estiver conectado a ele 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 pode-se observar na Figura 3.9.

Figura 3.9 – Arquitetura MPLS VPN


29/10/2012 14:57:26

MPLS – VPN 53

Portanto, redes MPLS permitem uma total separação das redes VPNs dos clientes. Essa 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. O 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 chamado de Virtual Routing and Forwarding table ou VRF. Um roteador PE tem uma instância de VRF para cada cliente conectado a ele. Funciona como se existissem roteadores dedicados para cada cliente que se conecta ao provedor de serviços, porém há 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. A grande vantagem do uso do roteador virtual é a redução da quantidade de equipamentos físicos que um provedor necessita disponibilizar. Seu uso não altera o modelo da VPN, apenas permite que um único roteador seja fisicamente compartilhado por vários roteadores virtuais. Pode-se observar na Figura 3.9 que os roteadores PEs possuem duas tabelas de roteamento isoladas, uma para cada VPN, no caso para os clientes A e B. Para realizar uma VPN MPLS é necessário o conhecimento de alguns atributos utilizados nos roteadores PEs, que são: RD (Route Distinguisher), RT (Route Targets) e MP-BGP (MultiProtocol 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 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 (Lobo, 2008). O formato do endereço resultante (Figura 3.10), com 96 bits no total (32 bits do IPv4 + 64 bits do RD), é conhecido como endereço VPNv4 e é trocado entre os roteadores PEs no backbone. A Figura 3.10 mostra que existem dois formatos para o RD. Se o provedor não tem um número de AS (Autonomous System) BGP, o formato com endereço IP pode ser usado; e se o provedor tem um número de AS, o formato com o número do sistema autônomo pode ser usado. Na Figura 3.11, observa-se que o mesmo prefixo, 172.16.10.0/24, recebido de dois diferentes clientes, se torna único no backbone ao ser adicionado aos valores de RD, no caso, 1:100 e 1:101.


29/10/2012 14:57:26

54 Redes MPLS

Figura 3.10 – Formato VPNv4 (AS – Number + VPN ID ou IP Address + VPN ID)

Figura 3.11 – Operação do RD na VPN MPLS

O protocolo usado para trocar essas rotas VPNv4 entre os roteadores PEs é o multiprotocolo BGP (MP-BGP). O protocolo BGP-4 foi descrito na RFC 1771 (RFC 1771), porém essa RFC descreve apenas o uso do BGP no transporte de prefixos IPv4. A RFC 2858 (RFC 2858), Multiprotocol Extensions for BGP-4, foi escrita para estender o BGP e torná-lo apto a transportar outras informações de roteamento, além dos prefixos IPv4. O protocolo BGP foi escolhido para troca de rotas VPNv4 devido a sua alta escalabilidade para transportar rotas, por ser um protocolo


29/10/2012 14:57:27

MPLS – VPN 55

de roteamento bastante flexível e por permitir que políticas estendidas sejam implementadas. 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 possam ser feitas restrições de importação e exportação de rotas. Os identificadores RT são implementados usando comunidades estendidas do BGP, logo, quando uma rota VPN aprendida de um CE é injetada no VPNv4 BGP, uma lista de VPN route targets é utilizada na identificação de um membro VPN e é associada com cada VRF. O formato de um RT é o mesmo que o formato do RD, já exibido na Figura 3.10.

3.5 – Propagação de rotas VPNv4 no backbone VPN MPLS A Figura 3.12 mostra passo a passo como se dá a propagação das rotas VPNv4 no backbone VPN MPLS.

Figura 3.12 – Propagação de rotas VPNv4 no backbone MPLS VPN passo a passo (De Ghein, 2007)


29/10/2012 14:57:27

56 Redes MPLS

De acordo com a Figura 3.12, o roteador PE recebe rotas IPv4 do roteador CE, normalmente através de um Interior Gateway Protocol (IGP) ou BGP Externo (eBGP). Essas rotas IPv4 provenientes do site VPN são inseridas na tabela de roteamento da VRF. A VRF é definida na interface do roteador PE que está conectada ao roteador CE. Essas rotas são adicionadas ao RD, que é designado para a VRF específica. Dessa forma, as rotas se tornam rotas VPNv4 para todos os roteadores PEs no backbone VPN MPLS. No PE de saída do backbone as rotas VPNv4 são separadas do RD e inseridas na tabela de roteamento da VRF como rotas IPv4. Essa inserção de rotas após retirada do RD irá depender se o RT permite importar essas rotas na VRF. As rotas IPv4 são anunciadas para o CE através de um IGP ou eBGP, que está sendo executado entre PE e CE. O tráfego de VRF para VRF tem dois rótulos na rede VPN MPLS. O top label é o rótulo do IGP e é distribuído pelo LDP entre todos os roteadores Ps e PEs. O bottom label é o rótulo da VPN que é anunciado pelo MP-iBGP de PE para PE. Os roteadores Ps usam o rótulo do IGP para encaminhar os pacotes para o PE de saída correto, e o PE de saída usa o rótulo da VPN para encaminhar o pacote IP para o CE correto, conforme podemos observar na Figura 3.13.

Figura 3.13 – Encaminhamento de pacotes na rede VPN MPLS

A Figura 3.13 mostra que o pacote entra no PE em uma interface VRF como um pacote IP. Ele é encaminhado através da rede VPN MPLS com dois rótulos. O roteador P encaminha o pacote olhando o top label, que é trocado a cada roteador P. Os rótulos são retirados no roteador PE de saída e os pacotes são encaminhados pela interface VRF de saída para o roteador CE, sendo este encontrado


29/10/2012 14:57:27

MPLS – VPN 57

através do rótulo da VPN (De Ghein, 2007). A Figura 3.14 exibe a captura, através do Wireshark, de dois rótulos MPLS: um deles (17) é o rótulo do IGP e o outro é o rótulo da VPN (24). Podemos observar que, no primeiro rótulo, o campo BoS está em 0 (zero), o que significa que há outro rótulo para ser lido. Já no segundo rótulo, o campo BoS está setado (1), indicando que este é o último rótulo, não tendo mais nenhum a ser lido.

Figura 3.14 – Captura de dois rótulos MPLS através do Wireshark


29/10/2012 14:57:27

CAPÍTULO 4. PseudoWire MPLS

Neste capítulo daremos um detalhamento sobre outro importante serviço provido pela tecnologia MPLS, o PseudoWire, o qual permite o transporte de quaisquer tecnologias (Frame Relay, ATM, Ethernet, etc.) sobre um backbone MPLS, tornando o backbone transparente ao transporte do tráfego IP.

4.1 – PseudoWire – Conceito A ideia do serviço PseudoWire do MPLS é permitir que a tecnologia MPLS possa ser usada como uma infraestrutura de rede multisserviço, que agrega e pode transportar diversas tecnologias, tais como ATM, Ethernet e Frame Relay, de maneira integrada sobre uma só rede, uniformemente gerenciada. Para isso são criados circuitos virtuais, que emulam um circuito ponto-a-ponto e provêm um serviço único no backbone MPLS, que é visto pelo usuário como um circuito dedicado de um determinado serviço. Como exemplo, temos a Figura 4.1.

Figura 4.1 – PseudoWire MPLS. Adaptado de (De Ghein, 2007)

58


29/10/2012 14:57:28

PseudoWire MPLS 59

O PseudoWire habilita provedores de serviço a conectar sites de clientes à rede da camada de enlace de dados utilizando uma única infraestrutura integrada de rede baseada em pacotes: uma rede MPLS. Em vez de isolar as redes em ambientes de gerenciamento, os provedores de serviço podem distribuir conexões da camada 2 sobre um backbone MPLS. Esse serviço provê uma estrutura comum para encapsular e transportar modalidades suportadas de tráfego da camada 2 sobre um núcleo de rede MPLS, com os seguintes tipos de transportes: • ATM AAL5 sobre MPLS; • ATM Cell Relay sobre MPLS; • Ethernet sobre MPLS; • Frame Relay sobre MPLS; • PPP sobre MPLS; • HDLC sobre MPLS. A Figura 4.2 exibe o uso do PseudoWire para diferentes tecnologias.

Figura 4.2 – PseudoWire – diferentes tecnologias de nível 2. Adaptado de (De Ghein, 2007)


29/10/2012 14:57:28

60 Redes MPLS

4.2 – Modelo de referência PseudoWire O modelo de referência PseudoWire, mostrado na Figura 4.3, é utilizado para transportar tráfego de nível 2 através de um backbone MPLS. O modelo é baseado no trabalho do grupo IETF PWE (PseudoWire Emulation Edge-to-Edge), que provê o framework para emulação fronteira-a-fronteira (edge-to-edge) sobre uma rede baseada em pacotes de um provedor. O PseudoWire é uma conexão lógica entre dois dispositivos Provider Edge (PE), que conectam dois PseudoWire End-Services (PWES) do mesmo tipo. Os roteadores PEs são configurados como os pontos finais ou extremos de uma conexão PseudoWire. Após a formação do PseudoWire, PDU (Protocol Data Unit) de camada 1 ou camada 2 são encapsulados no dispositivo PW (PseudoWire) de entrada. O PDU encapsulado é enviado sobre o PW para o dispositivo PW de saída, onde cabeçalhos de camada 2 ou camada 3 são reconstruídos, e os quadros são enviados no formato original para o dispositivo CE (Lobo, 2008).

Figura 4.3 – Modelo de referência PseudoWire. Adaptado de (De Ghein, 2007)

4.3 – Terminologias do PseudoWire As seguintes terminologias são frequentemente usadas em redes VPN (Virtual Private Network) baseadas em PseudoWire, conforme Figura 4.4 (Lobo, 2008): •• Circuito de Acesso (AC) •• Rede de Comutação de Pacotes (PSN) •• Circuito Virtual Emulado (VC)


29/10/2012 14:57:28

PseudoWire MPLS 61

Figura 4.4 – Terminologia – PseudoWire. Adaptado de (De Ghein, 2007)

Um circuito de acesso (AC) é um circuito virtual (VC) ou um circuito físico que interliga um CE a um PE. Pode ser, entre outras coisas, um VC, como, por exemplo, o Frame Relay ou ATM, uma porta Ethernet, uma VLAN (Virtual Local Area Network), um enlace HDLC (High Level Data Link Control), ou uma conexão PPP (Point–to-Point Protocol). Uma rede de comutação de pacotes (PSN) usa IP ou MPLS como um mecanismo para encaminhamento de pacotes. As extremidades de um PseudoWire são dois roteadores PEs conectados para AC de um mesmo tipo ou não. Um circuito virtual emulado (VC) é usado para prover uma conexão nível 2 entre dois dispositivos CEs. Os circuitos emulados usam três camadas de encapsulamento: cabeçalho de tunelamento, campo de demultiplexação e encapsulamento de circuito virtual.

4.4 – Como o PseudoWire trabalha Em uma rede MPLS provendo serviço PseudoWire, os quadros nível 2 são recebidos na interface de entrada do roteador PE. Esses quadros são encapsulados dentro de um pacote MPLS usando uma pilha de rótulos pelo roteador PE de entrada. O roteador PE de entrada encapsula os quadros dentro da pilha de rótulos MPLS e reencapsula o quadro através do backbone para o roteador PE de saída, conforme Figura 4.5.


29/10/2012 14:57:29

62 Redes MPLS

Figura 4.5 – Túnel LSP. Adaptado de (De Ghein, 2007)

O roteador de saída desencapsula o pacote e reproduz o quadro nível 2 na interface de saída apropriada. Os quadros PseudoWire são transportados através do backbone MPLS usando a pilha de rótulos com dois rótulos. No framework PseudoWire, o rótulo mais externo é chamado de rótulo do túnel. Esse rótulo mais externo propaga o pacote do roteador PE de entrada para o roteador PE de saída, sendo este rótulo mais externo do túnel usado para a criação do LSP PE-PE. O rótulo do túnel é associado com o prefixo IGP (Interior Gateway Protocol), identificando o PE remoto. O segundo rótulo (inner label), conhecido como rótulo VC, é usado pelo roteador PE de saída para encaminhar pacotes na interface de saída apropriada. Portanto, o roteador PE recebe um quadro do roteador CE e encaminha o quadro através do backbone MPLS para o roteador PE de saída com dois rótulos: o rótulo de túnel (tunnel label) e o rótulo de circuito virtual (VC label). Podemos observar esse pacote PseudoWire na Figura 4.6. Quando o pacote alcança o roteador de saída, o rótulo do túnel já foi removido. Isso ocorre devido ao comportamento do PHP (Penultimate Hop Popping) entre o último roteador P e o PE de saída. Assim, o PE de saída inspeciona o rótulo de circuito virtual (VC) na LFIB, retira o rótulo VC e encaminha o quadro no AC correto. Os roteadores Ps nunca olham o rótulo VC, eles são completamente alheios ao serviço PseudoWire.


29/10/2012 14:57:29

PseudoWire MPLS 63

Figura 4.6 – Encaminhamento de um pacote PseudoWire

4.5 – Benefícios do PseudoWire Podemos citar algumas vantagens de habilitar pacotes de camada 2 para serem transmitidos na rede MPLS: •• Torna o provedor de serviços capaz de transportar todos os tipos de tráfego sobre o backbone e comporta todos os tipos de clientes; •• Adere aos padrões desenvolvidos para transporte de pacotes nível 2 sobre MPLS; •• A expansão para o PseudoWire é transparente para o usuário. Como a rede do provedor de serviço fica isolada da rede do cliente, o provedor pode expandir para PseudoWire sem interrupção de serviço para o usuário. Os clientes presumem que estão usando um backbone tradicional de camada 2.


29/10/2012 14:57:29

CAPÍTULO 5. Qualidade de Serviço (QoS) com MPLS

Neste capítulo estudaremos os conceitos, as arquiteturas e os mecanismos de Qualidade de Serviço, mostrando como estas características são incorporadas às redes MPLS para garantir o tratamento diferenciado a algumas aplicações.

5.1 – Fundamentos do QoS A Internet fornece um serviço apenas do tipo melhor esforço (best-effort), no qual todos os pacotes que trafegam são tratados de maneira uniforme para entregá-los ao destino. A Internet funciona com o protocolo IP, que trabalha com essa filosofia de melhor esforço, onde cada usuário da rede envia seus dados e compartilha a largura de banda com todos os demais fluxos de dados dos outros usuários. Quando há um congestionamento, pacotes são descartados indiscriminadamente, não havendo garantia de que o serviço será realizado com sucesso, nem que haverá bom desempenho (Odom e Carnavaugh, 2004). Aplicações em tempo real, tais como tráfego de voz, vídeo e multimídia, necessitam de garantia estrita de banda e são aplicações sensíveis a atraso (delay), variação do atraso dos pacotes (jitter) e perda de pacotes (Lins et al, 2011). À época da criação do protocolo TCP-IP, não se vislumbrava que a Internet se tornaria a grande rede mundial que hoje é conhecida, e, desse rápido crescimento, temos a tendência cada vez maior da integração de todos os dados e serviços numa única infraestrutura de redes de pacotes, a rede IP. Portanto, no contexto atual das redes, de integração e convergência, onde as redes transportam todo tipo de informação, é fundamental a utilização da qualidade de serviço, para melhor atendimento às aplicações que requerem tratamento diferenciado. De uma forma simples, QoS é a habilidade de diferenciar diversas classes de tráfegos com critérios predefinidos e designar prioridades baseadas em vários tipos de tráfegos que afetam o tratamento em cada roteador na rede (Lobo, 2008). 64


29/10/2012 14:57:29

Qualidade de Serviço (QoS) com MPLS 65

5.2 – Arquiteturas de QoS Muitos provedores de serviços, devido à necessidade dos clientes, começaram a comercializar produtos com níveis de serviços diferenciados que atendam a aplicações e requisitos cada vez mais específicos. Qualidade de serviço em redes IPs são mecanismos que permitem o controle e a manipulação dos parâmetros de banda, atraso (delay), variação do atraso (jitter) e perda de pacotes, sendo uma arquitetura fim-a-fim. Os provedores que oferecem serviços baseados em IP através de um backbone MPLS são capazes de permitir QoS através desta infraestrutura. O IETF (Internet Engineering Task Force) define dois modelos para implementação de QoS numa rede IP (Sverzut, 2008): A arquitetura de Serviços Integrados (IntServ) e a Arquitetura de Serviços Diferenciados (DiffServ).

5.2.1 – Serviços integrados (IntServ) O objetivo desta arquitetura é obter a largura de banda e a latência necessárias para uma determinada aplicação (Davidson et al, 2007). É tipicamente utilizado para garantir que um fluxo em especial receba o nível de QoS apropriado ao longo da rede inteira antes de enviar esse tráfego. A arquitetura de Serviços Integrados baseia-se em quatro componentes, conforme Figura 5.1 (Colcher et al, 2005).

Figura 5.1 – Componentes da arquitetura IntServ

• Escalonador de pacotes: gerencia o buffer das filas de saída dos roteadores usando alguma política de atendimento.


29/10/2012 14:57:30

66 Redes MPLS

•• Controle de admissão: implementa o algoritmo utilizado pelo roteador para determinar se a solicitação de QoS de um novo fluxo pode ser atendida sem interferir nas garantias de outros fluxos já alocados. •• Classificador de pacotes: reconhece os fluxos segundo suas identificações, mapeia os pacotes desses fluxos nas diferentes categorias de serviço, notifica a função de policiamento e, caso os pacotes estejam em conformidade com o controle imposto pelo policiamento, os coloca nos buffers das filas de saída apropriadas. •• Policiamento: verifica se o fluxo está de acordo com as especificações negociadas na fase de estabelecimento da conexão. Fluxos fora do acordo podem ter seus pacotes descartados para evitar congestionamentos. O princípio desta arquitetura é que a qualidade de serviço seja garantida através de mecanismos de reserva de recursos na rede. Isso é tipicamente obtido através do protocolo RSVP (Resource reSerVation Protocol) (Chowdhury, 2002). O RSVP foi criado como um protocolo de sinalização para que aplicações fossem capazes de reservar recursos, ou seja, é um protocolo usado por uma aplicação para informar à rede seus requisitos de QoS e efetuar a reserva de recursos ao longo do caminho que o pacote irá percorrer. A Figura 5.2 exibe o processo de sinalização utilizado pelo RSVP, que desempenha as seguintes operações:

Figura 5.2 – Processo de sinalização – RSVP

O dispositivo de origem envia uma mensagem PATH para o computador destino especificando as características do tráfego que ele deseja enviar. Cada roteador intermediário ao longo do caminho passa a mensagem PATH para o próximo salto, determinado pelo protocolo de roteamento. A mensagem PATH prepara os roteadores intermediários para o roteamento reverso, mas não faz


29/10/2012 14:57:30


reserva de recursos. Quando o dispositivo de destino recebe a mensagem PATH, ele responde com uma mensagem RESV (para requisitar recursos para o fluxo) que percorre a mesma rota no sentido reverso. Cada roteador ao longo do caminho pode aceitar ou rejeitar a reserva de recursos; porém, se ela for rejeitada, o roteador enviará uma mensagem de erro RESVERR para o destino, encerrando o processo de sinalização. Sendo aceita, a largura de banda e o espaço em buffer são alocados para o fluxo, e as informações de estado do fluxo relatado são inseridas no roteador. Nesse período de tempo, o emissor daquele serviço tem uma faixa da largura de banda disponível para transmitir as informações (Odom e Canavaugh, 2004). É importante salientar que as reservas de recursos utilizadas pelo RSVP são soft-state, ou seja, tanto o transmissor quanto o receptor devem continuar enviando essas mensagens de tempos em tempos, a fim de manter o estado da sessão; caso contrário, a reserva será cancelada. A grande vantagem do Serviço Integrado é que previamente é feita uma alocação de banda, já que cada roteador é consultado ao longo do caminho para fazer essa reserva, garantindo assim a entrega, caso a reserva seja aceita por todos. A arquitetura IntServ tem como principal desvantagem o fato de não ser uma arquitetura escalável, pois a quantidade de informações de estado aumenta proporcionalmente com o número de fluxos, exigindo uma sobrecarga de processamento nos roteadores. Para grandes redes, como backbones de operadoras, torna-se inviável o uso desta arquitetura, devido à grande troca de mensagens e à necessidade de guardar estados dos fluxos nos roteadores.

5.2.2 – Serviços diferenciados (DiffServ) A arquitetura de Serviços Diferenciados (DiffServ) foi introduzida como uma alternativa para a arquitetura de Serviços Integrados, evitando problemas de escalabilidade e complexidade. A qualidade de serviço na arquitetura DiffServ é garantida através de mecanismos de priorização de pacotes na rede, diferentemente da arquitetura IntServ, onde a qualidade de serviço é garantida através de reserva de recursos na rede. Na Figura 5.3 são exibidos os blocos funcionais principais em um roteador utilizando a arquitetura DiffServ. Todas as funções desse diagrama estão presentes nos roteadores de borda da rede e, eventualmente, adicionados aos roteadores de núcleo da rede.


29/10/2012 14:57:30

68 Redes MPLS

Figura 5.3 – Blocos funcionais do DiffServ

•• Classificador de pacotes: identifica pacotes que são mapeados para classes. •• Medidor: verifica conformidade com parâmetros de tráfego e passa o resultado para o marcador e o condicionador de pacotes, para disparar uma ação específica para pacotes que estão fora ou dentro do perfil definido. •• Marcador de pacotes: escreve/sobrescreve o valor do DSCP. •• Condicionador de pacotes: atrasa alguns pacotes para que eles permaneçam em conformidade com o perfil definido, ou descarta pacotes que excederam o perfil definido. Os serviços diferenciados são implementados com base na definição de tipos de serviços. Através do campo ToS (Type of Service) do cabeçalho IP pode-se representar o tipo de serviço. As aplicações podem fazer uso de 3 bits do campo ToS para especificar a necessidade de baixo atraso, alta largura de banda ou pouca perda, sendo essas opções bastante limitadas (Odom e Cavanaugh, 2004); porém, na arquitetura DiffServ foi definida uma nova interpretação para o campo ToS, conforme podemos observar na Figura 5.4.

Figura 5.4 – DSCP (Differentiated Service Code Point) e CU (Currently Unused)


29/10/2012 14:57:30


Os serviços diferenciados fazem uso dos 6 bits mais significativos do campo ToS, chamado de campo DS (Differentiated Service) pelo serviço diferenciado. Os últimos bits atualmente inutilizados (CU) no campo DiffServ não foram definidos dentro da arquitetura do DiffServ; eles têm sido utilizados como bits de notificação de congestionamento explícito (ECN). O campo DS retira do pacote informações do tipo de tratamento que o pacote deve obter em um determinado roteador, o que é chamado de PHB (Per-Hop Behavior). No campo DS, são codificadas as classes para os serviços diferenciados. Dois novos tipos de classes especiais surgiram com o modelo diferenciado: •• Classe AF (Assured Forwarding) (RFC 2597): consiste de um grupo PHB com serviços especificados em termos de largura de banda relativa disponível e políticas de descarte de pacotes. O serviço AF é composto de várias subclasses de serviço que possuem diferentes níveis de precedência em relação ao descarte de pacotes. É indicado para as aplicações que não são tão sensíveis ao atraso e requerem garantia de banda (DSCP = “001,” “010,” “011”, ou “100”). Pode-se considerar que o DSCP seja codificado no formato aaadd0, onde “aaa” define a classe de serviço e o “dd” define a precedência de descarte, conforme a Tabela 5.1. Tabela 5.1 – Classes AF do DSCP

Precedência de descarte/Classe 1. Baixa 2. Média 3. Alta

AF1 001010 001100 001110

AF2 010010 010100 010110

AF3 011010 011100 011110

AF4 100010 100100 100110

•• Classe EF (Expedited Forwarding) (RFC 2598): oferece um serviço de redes com baixa perda, baixo atraso, baixo jitter e banda garantida. É indicado para aplicações de tempo real. Para indicar PHB EF é utilizado apenas um DSCP: 101110. É importante observar que, apesar deste PHB ser fácil de definir, um serviço baseado em PHB EF necessita de uma cuidadosa coordenação entre policiamento, conformação e escalonamento nos caminhos que os pacotes EF poderão seguir.


29/10/2012 14:57:30

70 Redes MPLS

Para fornecer compatibilidade com a antiga definição de precedência do campo ToS (IP Precedence), são utilizados Class Selector Codepoints, que são definidos de maneira que seus PHBs se aproximem dos tratamentos de pacotes definidos pelos níveis de precedência IPv4. Na Tabela 5.2 pode-se visualizar os níveis de precedência e os Class Selector Codepoints equivalentes. Tabela 5.2 – Class Selector Codepoints

Class Selector Codepoint

Precedência IPv4

000000

000 Routine

001000

001 Priority

010000

010 Immediate

011000

011 Flash

100000

100 Flash Override

101000

101 Critical

110000

110 Internet Control

111000

111 Network Control

Na solução DiffServ os pacotes são classificados, marcados e processados segundo a codificação rotulada no cabeçalho do pacote DSCP. As decisões mais complexas nesta arquitetura são efetuadas pelos equipamentos de borda do domínio DiffServ, e serviços fim-a-fim são construídos a partir de um conjunto restrito de tratamentos nos roteadores de núcleo. A ideia é simplificar o processamento nos roteadores de núcleo (Core), tornando-os mais rápidos. Podemos separar as funções entre os equipamentos de borda e núcleo, conforme Figura 5.5. •• Funções dos equipamentos de borda: ○○ Examinar os pacotes que chegam e classificá-los de acordo com a política em vigor; ○○ Marcar os pacotes com um DSCP que reflita o nível de serviço desejado; ○○ Garantir que o tráfego dos clientes siga as especificações definidas através de policiamento e da conformidade.


29/10/2012 14:57:30


Figura 5.5 – Arquitetura de serviços diferenciados

•• Funções dos roteadores de núcleo: ○○ Examinar os pacotes que chegam e verificar o DSCP marcado em seus cabeçalhos; ○○ Classificar e encaminhar os pacotes que chegam de acordo com seus DSCPs.

5.3 – Mecanismos de QoS Diversos mecanismos de QoS são utilizados para provimento da qualidade de serviço em redes de computadores. Estes mecanismos compreendem: classificação e marcação, gerenciamento de congestionamento, policiamento, moldagem e evitar congestionamento. Alguns desses mecanismos são aqui apresentados de forma resumida.

Classificação e marcação A classificação fornece um serviço preferencial a um determinado tipo de tráfego. Sua principal função é separar/classificar os fluxos em classes de serviços (Sverut, 2008). A classificação pode ser feita com base em portas físicas, IP de origem, IP de destino, endereço MAC, porta de aplicação, tipo de protocolo e outros critérios.


29/10/2012 14:57:30

72 Redes MPLS

Já a marcação, dependendo do tipo de interface em questão e das características do equipamento, pode ser feita na camada 2 (802.1p/q), na camada 3 (IP Precedence ou DSCP) ou no rótulo MPLS (Campo EXP). Na Figura 5.6 são apresentados os campos do quadro Ethernet, no qual está destacado o campo TAG, de 4 bytes, utilizado para marcação dos quadros, podendo criar classes de serviços em camada 2.

Figura 5.6 – Marcação em camada 2

Na Figura 5.7 é visto um pacote IPv4, sendo destacado o campo ToS (Type of Service), de 1 byte, utilizado para marcação dos pacotes, podendo ser utilizado para criação de classes de serviços na camada 3.

Figura 5.7 – Marcação em camada 3

Na Figura 5.8, é apresentado o cabeçalho do MPLS, inserido entre as camadas 2 e 3 do modelo OSI, sendo destacado o campo EXP, de 3 bits, utilizado para marcação dos rótulos.

Figura 5.8 – Marcação no rótulo MPLS


29/10/2012 14:57:31


Gerenciamento de congestionamento O controle de congestionamento ocorre na medida em que um congestionamento se estabelece em uma comunicação de rede. Os elementos de rede usam os algoritmos de enfileiramento para ordenar o excesso de tráfego (overflow) que chega, determinando alguns métodos de priorização para o fluxo de saída. Há uma grande necessidade de que o tráfego seja compartilhado entre aplicações, de modo que não venha a afetar o desempenho delas, por isso devemos considerar a utilização de técnicas de gerenciamento de congestionamento para assegurar o tratamento através de vários tipos de tráfegos. Existem diversos mecanismos de enfileiramento para controle e prevenção de congestionamento em interfaces de roteadores, aplicáveis tanto em LANs quanto em WANs. Apresentamos alguns deles a seguir:

Controle de fila – FIFO (First-In First-Out) Este tipo de gerenciamento de congestionamento utiliza uma fila na qual o primeiro pacote a entrar será o primeiro pacote a sair da interface. É um mecanismo de armazenamento e repasse também conhecido como FIFO (First-In First-Out), que não implementa nenhum tipo de classificação. A alocação de banda é determinada pela ordem de chegada dos pacotes. Normalmente é utilizada para fazer o controle do tráfego nas conexões seriais dos roteadores e não é uma boa indicação para aplicações sensíveis a retardo, pois pode causar longos atrasos para tráfegos em rajadas (Odom e Cavanaugh, 2004), conforme ilustrado na Figura 5.9.

Figura 5.9 – Fila FIFO (First In First Out)

Enfileiramento com prioridade – PQ (Priority Queuing) O mecanismo de controle PQ dá ao tráfego mais importante a mais alta prioridade, sempre levando precedência sobre o tráfego de menor importância. Neste caso, os pacotes são classificados segundo critérios especificados pelo usuário, tais como: tipo do protocolo, interface de entrada e saída, tamanho do pacote, fragmentos e listas de acesso. Após esta classificação os pacotes são enviados


29/10/2012 14:57:31

74 Redes MPLS

para uma das quatro filas de saída criadas pelo PQ – alta, média, normal e baixa –, de acordo com a prioridade definida. Por padrão, os pacotes não classificados caem na fila normal, conforme esquematizado na Figura 5.10.

Figura 5.10 – Enfileiramento com prioridade PQ (Priority Queuing)

A fila alta é sempre servida primeiro, até que seja esvaziada e as filas de menor prioridade possam ser servidas em sequência. Apesar de o PQ prover tratamento preferencial absoluto para tráfego de prioridade alta, assegurando que o tráfego de missão crítica atravesse vários enlaces com prioridade, seu uso pode resultar no tráfego de mais baixa prioridade nunca ser atendido, causando o que é chamado de morte por inanição (starvation).

Enfileiramento justo e enfileiramento justo ponderado Nesses algoritmos de enfileiramento, a proposta é oferecer uma alocação mais equitativa da banda entre os fluxos de dados, proporcionando uma ordenação de mensagens em sessões e alocando uma fração da banda para cada sessão. O mecanismo de enfileiramento justo ponderado (Weighted Fair Queuing – WFQ) utiliza o algoritmo de enfileiramento justo (Fair Queuing), colocando o tráfego prioritário para frente da fila, reduzindo o tempo de resposta e, de forma justa, compartilhando o restante da banda com os outros tipos de fluxos (Odom e Cavanaugh, 2004). É um algoritmo empregado para interfaces seriais abaixo de 2 Mbps e trabalha de forma automática, prevendo tratamento de alocação de banda para todo o tráfego de rede, aplicando pesos para identificar tráfego dentro de conversações e determinar quanto de banda de cada


29/10/2012 14:57:31


conversação é relativamente permitida para outras conversações. A classificação dos fluxos de dados pode ser realizada por endereço de origem ou destino, por protocolo, pelo campo de precedência IP, pela porta ou outros parâmetros, conforme Figura 5.11.

Figura 5.11 – Enfileiramento justo ponderado (WFQ)

CQ (Custom Queuing) Este mecanismo permite especificar para uma determinada aplicação uma percentagem de banda, permitindo que a banda reservada seja compartilhada de forma proporcional entre as aplicações e os usuários, porém no percentual que foi definido. A banda restante poderá ser compartilhada entre os outros tipos de tráfegos. O algoritmo CQ controla o tráfego alocando uma determinada parte da fila para cada fluxo que é classificado, sendo as filas ordenadas ciclicamente num esquema round-robin (Chowdhury, 2002). Existe um contador associado a cada fila que estabelece quantos bytes podem ser enviados antes de passar para a próxima fila. Até dezessete filas podem ser definidas, conforme Figura 5.12, sendo a fila zero reservada para mensagens do sistema como sinalização, keepalive, etc. A classificação pode ser feita pelo endereço de origem ou destino, protocolo, precedência IP, interface de entrada e através de listas de acesso.


29/10/2012 14:57:31

76 Redes MPLS

Figura 5.12 – Filas CQ (Custom Queuing)

A Tabela 5.3 exibe uma comparação entre as filas WFQ-PQ e CQ: Tabela 5.3 – Comparação entre WFQ-PQ e CQ

Enfileiramento justo ponderado (Weighted Fair Queuing)

Enfileiramento com prioridade (Priority Queuing)

Enfileiramento customizado (Custom Queuing)

Sem limites de filas

4 filas

16 filas

Prioridade para pequenos volumes de tráfego

Prioridade alta servida primeiro

Serviço Round-robin

Prioridade para tráfego interativo

Indicado para tráfego crítico

Alocação de banda disponível

Transferência de arquivos consegue acesso balanceado

Projetado para enlaces de banda estreita

Mais adequado para enlaces de banda larga

Habilitado por padrão

--------------

-------------

Enfileiramento com baixa latência – LLQ (Low Latency Queuing) As filas de baixa latência são de altíssima prioridade, com limitação de banda máxima a ser utilizada. O roteador atende à fila de baixa latência (quando essa contiver pacotes a serem transmitidos) em detrimento de quaisquer outras existentes, até o limite da banda máxima. Esse mecanismo cria uma fila de alta prioridade, conforme esquematizado na Figura 5.13, com garantia e limitação de banda total permitida. Na presença de um único pacote nesta fila, o mecanismo de esvaziamento interrompe o atendimento às demais filas e transmite


29/10/2012 14:57:31


os pacotes desta fila, até o limite de banda definido. Pacotes que excedam esse limite somente serão transmitidos caso a interface não possua nenhum tipo de congestionamento.

Figura 5.13 – Mecanismo de enfileiramento de baixa latência (LLQ)

Policiamento (Policing) Para disciplinar o tráfego que entra no backbone, usa-se o mecanismo de policiamento, que limita a banda que uma determinada classe de tráfego pode utilizar. Para os excessos gerados de banda, podem ser definidas as ações de descartar os pacotes, o que efetivamente impossibilita o tráfego acima da banda disponibilizada, ou pode-se remarcar esse tráfego com uma prioridade menor antes de transmiti-lo, o que não interrompe o serviço, porém o penaliza com um maior tempo de resposta às aplicações que não estão com o comportamento dentro do perfil contratado. A Figura 5.14 apresenta o comportamento do mecanismo de policiamento, onde se pode observar o descarte de pacotes.

Figura 5.14 – Mecanismo de policiamento (policing)


29/10/2012 14:57:32

78 Redes MPLS

Moldagem (Shaping) O mecanismo de moldagem, conhecido como shaping, ajusta o tráfego para um perfil definido, o regula e o submete a um domínio DiffServ. Este mecanismo, em vez de descartar os pacotes que excederem o perfil definido, armazena num buffer as informações excedentes, causando um atraso de forma a ajustar as suas características ao perfil definido. A Figura 5.15 apresenta um gráfico dos mecanismos de moldagem.

Figura 5.15 – Mecanismo de moldagem (shaping)

A comparação entre os mecanismos de policiamento e moldagem permite afirmar: •• Ambos os mecanismos verificam se o tráfego não excede uma banda limite contratada; •• Ambos limitam a banda, mas com diferentes impactos no tráfego: ○○ Policiamento (Policing) descarta mais frequentemente – mais retransmissões. ○○ Moldagem (Shaping) adiciona variáveis de retardo (buffering). ○○ Policiamento (Policing) causa retransmissões TCP. ○○ Policiamento (Policing) pode também ser um marcador. ○○ Policiamento (Policing) age na interface de entrada ou saída. ○○ Moldagem (Shaping) age somente na interface de saída. ○○ Moldagem (Shaping) pode ser adaptada para congestionamentos na rede (BECN, FECN).


29/10/2012 14:57:32


Evitar congestionamento (Congestion Avoidance) Alguns dos principais mecanismos para evitar congestionamentos são: •• RED (Random Early Detection) é o mecanismo através do qual o roteador monitora o tamanho das filas e descarta aleatoriamente pacotes para evitar que o tamanho da fila aumente demasiadamente. Com isso, as aplicações TCP recebem uma resposta da rede em relação às condições de tráfego, reduzindo a utilização de banda e diminuindo a situação de congestionamento (Odom e Cavanaugh, 2004). •• WRED (Weighted Random Early Detection) usa o mecanismo do RED, aliado a uma avaliação do pacote pelo seu peso, que é inversamente proporcional ao campo de prioridade (priority) dentro do ToS no cabeçalho IP. Desta forma, pacotes com maior prioridade terão menor peso e, por consequência, menor probabilidade de descarte. O WRED também usa dois limites para cada peso de pacote. O primeiro limite, quando ultrapassado, aciona o mecanismo de descarte aleatório, enquanto o segundo aciona o descarte total (tail drop). O funcionamento geral do algoritmo WRED é similar ao do RED. O RED se baseia no cálculo do tamanho médio da fila a cada vez que chega um novo pacote. O tamanho da fila é então comparado com os limites mínimo e máximo. Se o tamanho médio estiver entre o valor mínimo e o máximo, a probabilidade de descarte de pacotes é calculada. Já a probabilidade de descarte de um pacote no WRED é baseada nos limites mínimo e máximo e no peso do pacote. A probabilidade de descarte aumenta à medida que o tamanho médio se aproxima do tamanho máximo da fila e o peso do pacote é menor. Se o tamanho médio da fila estiver acima do valor máximo, o pacote é descartado, conforme esquematizado na Figura 5.16. É possível haver situações específicas em que, mesmo dentro dos limites contratados, o tráfego agregado dos clientes provoca um acúmulo muito grande de pacotes nas filas dos roteadores do núcleo. Nesta situação, é importante o uso dos mecanismos para evitar congestionamentos (Congestion Avoidance – WRED) para sinalizar essa situação às aplicações, evitando o efeito chamado de Global Sync. O Global Sync ocorre quando as filas dos roteadores começam a chegar ao limite de tail drop, onde os pacotes são descartados sem controle, fazendo com que todos os fluxos TCP parem sua transmissão simultaneamente. Isso leva a um efeito em cascata que impede a eficiência no uso da banda, como apresentado na Figura 5.17.


29/10/2012 14:57:32

80 Redes MPLS

Figura 5.16 – Funcionamento do WRED

Figura 5.17 – Efeito Global Sync

Os mecanismos para evitar congestionamentos (Congestion Avoidance) atuam no final da fila, descartando aleatoriamente pacotes, respeitando a prioridade de descarte do DSCP (ou seja, descartando antes pacotes com maior prioridade de descarte), mantendo assim a fila dentro de um tamanho médio e sinalizando às aplicações TCP para diminuírem a taxa de transmissão de pacotes.


29/10/2012 14:57:32


5.4 – Qualidade de serviços nas redes MPLS Todas as políticas de classificação e marcação, gerenciamento de congestionamento, evitar congestionamento, policiamento e moldagem podem ser utilizadas no backbone MPLS. Porém, quando configuramos QoS em redes MPLS, o roteador de borda LSR irá traduzir o domínio IP QoS para o domínio MPLS QoS e vice-versa. Isso significa que o pacote IP puro, que será recebido de um CE (Customer Edge) com marcação em Precedência IP ou DSCP, ao entrar no backbone MPLS, é remarcado como EXP. Ou seja, o roteador de borda LSR copia o valor dos bits de precedência IP para os bits EXP. No roteador de borda de saída é feito um processo contrário, ou seja, a marcação em EXP é convertida em marcação em Precedência IP ou DSCP para entrega ao CE final (Odom e Cavanaugh, 2004). Nada muda com relação ao comportamento do QoS, porém é importante observar que, se a marcação for em DSCP, somente os três bits mais significativos desse campo serão copiados para o EXP do cabeçalho MPLS, o que nos leva à primeira regra de QoS sobre MPLS (De Ghein, 2007). •• Regra 1: os bits de precedência ou os três primeiros bits do campo DSCP no cabeçalho IP são copiados para os bits EXP de todos os rótulos inseridos no LSR de entrada. O encaminhamento do pacote com rótulo é um pouco mais complicado. É importante distinguir dois casos: a troca de rótulo com a possibilidade de adicionar um ou mais rótulos ao pacote e, por outro lado, a troca de rótulo com a possibilidade de remover um ou mais rótulos do pacote. No primeiro caso, os bits EXP são copiados do rótulo de entrada para o rótulo de saída, sendo também verdadeiro quando um rótulo é trocado e são adicionados um ou mais rótulos. Nesses casos, o valor dos bits EXP é copiado do rótulo de entrada para o rótulo de saída e também para os rótulos que são empilhados no pacote encaminhado. Já o encaminhamento de pacotes com a retirada do rótulo é um pouco diferente; isso porque, quando o roteador retira o rótulo do topo da pilha de um pacote que encaminha, o valor dos bits EXP não é copiado para o novo rótulo do topo ou para os bits de precedência do cabeçalho do pacote IP sem rótulo. Isso significa que, por padrão, os bits EXP do novo rótulo do topo ou o campo DSCP do cabeçalho IP não são alterados, ditando o novo QoS do pacote, que o leva à segunda, terceira e quarta regras do QoS sobre MPLS (Odom e Cavanaugh, 2004). Porém, esse comportamento pode ser alterado para manter o valor de QoS quando os rótulos são retirados.


29/10/2012 14:57:32

82 Redes MPLS

•• Regra 2: os bits EXP do rótulo de entrada são copiados para o rótulo de saída e para qualquer outro rótulo empilhado no pacote. •• Regra 3: os bits EXP do rótulo do topo da pilha não são copiados para o rótulo de saída quando o rótulo do pacote de entrada é removido. •• Regra 4: os bits EXP do rótulo de entrada não são copiados para os bits de precedência ou os bits DSCP quando a pilha de rótulos é removida e o cabeçalho IP é exposto. Quando o QoS de um pacote rotulado é alterado manualmente em algum LSR, este valor de QoS será novamente alterado na rede algum tempo depois, ou seja, quando um rótulo é retirado do topo da pilha, o valor do campo EXP não é copiado para o novo rótulo exposto, conforme regra 3, significando que o antigo valor de QoS do pacote está novamente ativo, nos levando à quinta regra. •• Regra 5: quando o valor do campo EXP é alterado por meio de configuração, os rótulos que estão abaixo do topo da pilha não recebem o novo valor do campo EXP. A Figura 5.18 mostra alguns exemplos das regras citadas (De Ghein, 2007):

Figura 5.18 – Tratamento padrão do Cisco para os bits EXP


29/10/2012 14:57:33


A MPLS QoS regra 4 dá origem ao seguinte comportamento: indiferentemente do valor dos bits EXP introduzidos pelo LSR de entrada ou em qualquer outro LSR, este não é copiado para o pacote IP no LSR de saída da rede MPLS. Os bits de precedência ou DSCP do pacote IP são preservados, por padrão. É possível fazer um tunelamento de QoS, fazendo com que o valor de QoS do pacote IP possa ser transportado através da rede MPLS sem sofrer alteração. A grande vantagem é que a rede MPLS pode ter um esquema diferente de QoS do esquema com que o cliente se conecta a ele, porque o esquema MPLS QoS pode ser independente do esquema IP QoS dos clientes (De Ghein, 2007). Esse modelo se chama tunelamento DiffServ e é oferecido por uma rede MPLS para transportar o valor DiffServ de um pacote IP, de forma transparente, de uma borda a outra da rede MPLS. O túnel tem início quando o rótulo é adicionado ao pacote e termina quando o rótulo é removido, conforme Figura 5.19. O IETF define três modos de túneis DiffServ (Lobo, 2008): •• Modo uniforme (Uniform Mode): neste modo, as mudanças feitas no valor do campo EXP do rótulo do topo da pilha são propagadas tanto para os rótulos inseridos na pilha como para os rótulos de baixo, quando os rótulos da pilha são removidos. A premissa é que a rede está em um domínio DiffServ; logo, qualquer mudança feita no campo EXP do pacote em trânsito será aplicada a todos os rótulos do pacote, bem como ao pacote IP. •• Modo de tubo curto (Short Pipe Mode): modo útil para aplicação de políticas de QoS nos provedores, independentemente da política de QoS

Figura 5.19 – Tunelamento DiffServ


29/10/2012 14:57:33

84 Redes MPLS

do cliente. Os bits de precedência do pacote IP são propagados para cima na pilha de rótulos. Quando o rótulo é trocado, o valor do campo EXP é mantido. Se o valor do campo EXP do rótulo do topo da pilha é alterado, esta mudança é propagada para todos os rótulos da pilha, mas não para o pacote IP. • Modo de tubo (Pipe Mode): neste modo duas marcações são importantes para um pacote quando ele percorre a rede MPLS. Primeiro, a marcação usada pelos LSRs intermediários ao longo do LSP, incluindo o LSR de saída. Segundo, a marcação original do pacote antes da entrada na rede MPLS, que continuará sendo usada quando o pacote sair da rede MPLS. No LSR de saída todos os rótulos são removidos, mas, a fim de preservar a marcação transportada no rótulo, o LSR de borda copia este valor antes de remover os rótulos. Esta cópia interna é utilizada para classificar os pacotes na interface de saída.


29/10/2012 14:57:33

CAPÍTULO 6. Engenharia de Tráfego com MPLS

Este capítulo trata dos conceitos e funcionalidades desse importante serviço provido pela tecnologia MPLS, o serviço de engenharia de tráfego.

6.1 – Conceitos fundamentais O protocolo MPLS oferece a capacidade de roteamento baseado na origem, que é conhecido na rede MPLS como roteamento explícito. Apesar de o protocolo IP possuir a característica de roteamento baseado na origem, ele não é muito utilizado por diversos motivos, incluindo o fato de que apenas um número limitado de saltos pode ser especificado, e que normalmente ele é processado fora do “caminho rápido” na maioria dos roteadores. A Figura 6.1 apresenta como a capacidade de roteamento explícito do MPLS pode ser aplicada para resolver um problema bastante conhecido na engenharia de tráfego, denominado “problema do peixe” devido à sua forma.

Figura 6.1 – Rede exigindo roteamento explícito

85


29/10/2012 14:57:33

86 Redes MPLS

Ao observarmos a Figura 6.1, vemos que existem dois caminhos entre os roteadores R1 e R5: •• R1 à R2 à R5; •• R1 à R3 à R4 à R5. Na rede da Figura 6.1, suponha-se que um administrador tenha determinado que qualquer tráfego fluindo de R6 para R5 deve seguir o caminho R1 è R3 è R4 è R5, e que qualquer tráfego indo de R7 para R5 deve seguir o caminho R1 è R2 è R5. Um motivo para tal escolha seria fazer o melhor uso da capacidade disponível ao longo dos dois caminhos distintos de R1 a R5. Essa requisição não pode ser feita facilmente com roteamento IP normal, pois R1 não examina de onde o tráfego veio ao tomar suas decisões de encaminhamento. Já com o protocolo MPLS, que utiliza a comutação de rótulos para encaminhar pacotes, é possível conseguir o roteamento desejado. Uma das aplicações do roteamento explícito é na engenharia de tráfego, onde o objetivo é apresentar como é possível garantir que os diversos caminhos possam ser utilizados para o envio do tráfego sem sobrecarregar um determinado caminho, deixando o outro subutilizado. Um dos maiores problemas numa rede é que as rotas preferidas tendem a convergir pelos caminhos de maior banda. Tal decisão causa o desperdício de recursos de forma a haver muito tráfego em poucos enlaces, enquanto outros enlaces permanecem ociosos. Uma premissa importante da engenharia de tráfego é distribuir o tráfego por meio dos enlaces disponíveis para garantir que a carga seja dividida segundo critérios. Um fato importante é que a engenharia de tráfego está utilizando cada vez mais o MPLS. Uma boa engenharia de tráfego é essencial para a eficiência dos backbones das operadoras de telecomunicações. Assim como os backbones devem suportar alta utilização da capacidade de transmissão, as redes devem ser bastante robustas, de forma que possam suportar falhas de enlaces ou de um roteador. A engenharia de tráfego é um importante serviço na operação de grandes backbones, permitindo direcionar o tráfego da rede para caminhos diferentes dos que foram estabelecidos por um roteamento IP convencional, melhor distribuindo o tráfego na rede, evitando pontos de congestionamento e otimizando a utilização de recursos de rede. O MPLS-TE (acrônimo de MultiProtocol Label Switching – Traffic Engineering) é uma tecnologia que implementa engenharia de tráfego em redes IPs ao permitir


29/10/2012 14:57:34

Engenharia de Tráfego com MPLS 87

o estabelecimento de caminhos alternativos nessas redes – diferentes dos caminhos definidos pelo protocolo IGP – com base em critérios de recursos disponíveis, métricas sensíveis ao atraso ou, por exemplo, características físicas do enlace como velocidades diferentes. O MPLS-TE pode trazer benefício para todas as tecnologias e/ou aplicações que requerem banda, atraso ou variação dos níveis (jitter) de eficiência no mapeamento de fluxos de recursos. A aplicação do MPLS-TE não cria banda e não reduz os problemas com insuficiência de recursos na rede, mas ajuda no mapeamento mais eficiente desses recursos, como, por exemplo, o mapeamento de caminhos redundantes. O MPLS-TE permite um esquema de engenharia de tráfego onde o roteador conhecido como head-end (HE) do LSP pode calcular a rota de forma mais eficiente através da rede em direção ao roteador conhecido como tail end. O head-end (HE) pode fazer isso se ele conhece a topologia da rede e a banda disponível de todos os enlaces na rede. É necessário habilitar MPLS nos roteadores para estabelecimento do LSP fim-a-fim. O fato da comutação de rótulos ser utilizada, e não o encaminhamento baseado em IP, permite roteamento baseado em origem em vez do roteamento baseado em IP de destino (De Ghein, 2007).

6.2 – A engenharia de tráfego sobre MPLS O roteamento baseado no IP de destino não provê qualquer mecanismo para balanceamento de carga por caminhos redundantes. Nesse encaminhamento tem-se uma superutilização dos enlaces principais e de maior banda; já os enlaces redundantes são subutilizados. Analisando a rede da Figura 6.2, onde o enlace principal possui uma banda de 10 Gbps, que é superior em relação ao enlace redundante de banda de 2,5 Gbps, é verificado que o roteamento IP tradicional, apenas baseado no endereço de destino, terá o encaminhamento por apenas o enlace de maior banda, como, por exemplo, o tráfego entre as redes dos pontos de presença A e B. As políticas de roteamento e balanceamento de carga baseadas no encaminhamento dos pacotes podem ser empregadas ou é possível utilizar outros parâmetros, mas isso não ocorre em redes com alto volume de tráfego devido às limitações de desempenho. Há algumas limitações distintas do modo como a engenharia de tráfego pode ser realizada usando basicamente o protocolo IP. Se as regras de encaminhamento forem modificadas, então os roteadores na rede terão de ser mantidos


29/10/2012 14:57:34

88 Redes MPLS

Figura 6.2 – Encaminhamento IP tradicional

sincronizados e todos deverão operar com o mesmo nível de função, ou então poderão acontecer loops e maior congestionamento. O roteamento baseado na origem do IP é limitado tanto pela quantidade de nove enlaces (hops) quanto pelo fato de que nem todos os roteadores admitem o roteamento baseado na origem de uma maneira consistente. Como solução para esses problemas, o MPLS apresenta o roteamento explícito (Osborne e Simha, 2002). O MPLS pode ser utilizado para criar túneis de engenharia de tráfego com base na análise do tráfego e com objetivo de fornecer balanceamento de carga entre caminhos de diferentes taxas de transmissão, como apresentado na Figura 6.3. Dessa forma, a engenharia de tráfego está utilizando cada vez mais o MPLS para atender às suas necessidades de tunelamento.

Figura 6.3 – Balanceamento de carga com MPLS-TE


29/10/2012 14:57:34


O MPLS possui muitos componentes que o tornam atraente para uso em uma rede com engenharia de tráfego, entre eles: •• O MPLS tem a capacidade de estabelecer um LSP que segue um caminho diferente do oferecido como “preferido” pelo protocolo de roteamento. •• Os recursos dentro da rede podem ser reservados dinamicamente, conforme os LSPs são estabelecidos, e podem ser atualizados dinamicamente, conforme mudam as necessidades dos LSPs, para que esses fluxos de tráfego possam ter garantia de nível e qualidade de serviço. •• O tráfego pode ser ordenado para LSPs “paralelos”, ou seja, vários LSPs podem ser estabelecidos de origem e destino, e o tráfego pode ser distribuído entre os LSPs de acordo com qualquer número de algoritmos. Os LSPs “paralelos” podem tomar caminhos significativamente diferentes por meio da rede. •• Os recursos de rede podem ser automaticamente gerenciados com novos LSPs, configurados para atender às exigências imediatas da rede e com recursos liberados novamente quando os LSPs antigos não são mais necessários e liberados. •• Procedimentos de recuperação podem ser definidos, descrevendo como o tráfego pode ser transferido para LSPs alternativos no caso de uma falha e indicando como e quando LSPs de backup e espera devem ser configurados e roteados. Na engenharia de tráfego (TE) é determinado o caminho por meio da rede que diversos fluxos de dados seguirão. Com TE as operadoras de telecomunicações podem oferecer um backbone para os seus clientes com mais eficiência.

6.3 – Extensões do OSPF para TE A RFC 3630 (RFC 3630) define as extensões do protocolo OSPF versão 2 para engenharia de tráfego aplicáveis a redes IP, sendo também totalmente válidos para o MPLS-TE. O OSPF-TE (Open Shortest Path First – Traffic Engineering) inclui o conceito de LSAs (Link State Advertisements) opacos. Eles permitem que os roteadores compartilhem informações privadas ou proprietárias pela rede de uma maneira interoperável. Foram definidos três tipos de LSAs opacos: 1. LSA opaco tipo 8 – abrange apenas um enlace; 2. LSA opaco tipo 10 – abrange uma área; 3. LSA opaco tipo 11 – abrange um sistema autônomo OSPF.


29/10/2012 14:57:34

90 Redes MPLS

Os roteadores que não “entendem” os LSAs opacos não os precisam examinar nem os usar em seus cálculos de caminho. Esse roteadores necessitam apenas armazenar e reencaminhar os LSAs recebidos. Isso provê um modo elegante de acrescentar função a uma rede de maneira compatível e é usado para acrescentar informações de engenharia de tráfego ao OSPF, de modo que os roteadores cientes da engenharia de tráfego possam descobrir e atuar sobre a informação de TE em cooperação com roteadores mais antigos, que continuam a implementar o OSPF padrão (Farrel, 2005). A RFC 3630 engloba apenas o LSA opaco tipo 10, ou seja, restringe a sua aplicabilidade ao interior de uma área OSPF (Enne, 2009). Dentro do LSA opaco tipo 10 foi definido Traffic Engineering LSA, identificado pelo código 1. Esse LSA descreve roteadores, enlaces ponto-a-ponto e conexões para redes multiacesso, de forma similar a um roteador LSA do OSPF convencional. Essas extensões, partindo da descrição da topologia e dos parâmetros de qualidade de serviço da rede que suporta o TE, proveem os mecanismos de distribuição dessas informações dentro de uma área de roteamento OSPF. O OSPF-TE descreve e define uma forma de distribuição de atributos de enlaces estendidos (extended links attributes) que se baseia em roteamento baseado em restrições (constraint-based routing). Ao contrário do OSPF convencional, onde cada salto (hop) realiza o roteamento de pacotes com base em tabelas de roteamento local, o OSPF-TE centraliza as informações em uma base de dados localizada no head-end LSR, no caso do MPLS-TE, denominada base de dados de TE (TE database). O formato do corpo do LSA opaco é criado por meio de construções TLV (Type-Length-Variable), que formam uma sequência, mas também podem ser sobrepostas de modo que o tamanho de TLV de nível superior cubra toda uma série de sub-TLVs. Todos os sub-TLVs são encontrados na variável do TLV de nível superior. Existe a possibilidade da utilização conjunta da métrica do OSPF convencional e de uma métrica TE no MPLS-TE para diferentes classes de tráfego. Uma aplicação de voz pode utilizar a métrica OSPF-TE relativa a retardos e a jitters na rede, enquanto uma transferência de grandes arquivos pode utilizar uma métrica OSPF convencional.


29/10/2012 14:57:34


6.4 – Extensões do IS-IS para TE Para que o MPLS-TE funcione sobre uma rede com protocolo IS-IS (Intermediate System to Intermediate System) preexistente, é preciso atualizá-lo para uma nova versão de IS-IS; já com OSPF não é necessária a transição. As extensões de engenharia de tráfego para o IS-IS-TE (Intermediate System to Intermediate System Traffic Engineering) estão descritas na RFC 3784 (RFC 3784). Os procedimentos no IS-IS-TE são semelhantes aos do OSPF-TE, com algumas pequenas diferenças. Por exemplo: o período padrão para reflooding periódico de informações de roteamento, que é de trinta minutos para o OSPF-TE, assume o valor de quinze minutos para IS-IS-TE. Para o IS-IS-TE foram criados novos TLVs definidos como: •• Extended IS Reachability TLV, com o valor de tipo 22. •• Traffic Engineering Router ID TLV, com o valor de tipo igual a 134. •• Extended IP Reachability TLV, com o valor de tipo igual a 135.

6.5 – Protocolo RSVP-TE O RSVP-TE (Resource Reservation Protocol – Traffic Engineering) é o protocolo apropriado para distribuição de rótulos em redes MPLS com engenharia de tráfego, baseado no RSVP (Resource reSerVation Protocol). O RSVP é adequado para extensão ao mundo MPLS porque lida com reservas de recursos fim-a-fim para fluxos de tráfego de forma muito semelhante com o MPLS com engenharia de tráfego. Por outro lado, ele não atende a todas as exigências necessárias para o MPLS – principalmente a distribuição de rótulo e controle de caminhos por meio de rotas explícitas (Farrel, 2005). O RSVP foi inicialmente estendido para esse tipo de aplicação pela Cisco Systems quando ela estava desenvolvendo a comutação por TAG. Desde então, o IETF tem publicado o RSVP-TE. O RSVP-TE consegue reutilizar o RSVP de maneira bastante completa. Todas as sete mensagens RSVP encontram um uso no RSVP-TE, embora o ResvConf, que é a mensagem para reservar os recursos ao longo do caminho, seja menos significativo do que quando usado para o RSVP.


29/10/2012 14:57:34

92 Redes MPLS

6.6 – Operação do MPLS-TE O MPLS-TE é usado para otimizar a utilização dos recursos de redes com enlaces redundantes e com velocidades diferentes. Além disso, o MPLS-TE fornece mecanismos para a recuperação rápida (Fast ReRoute) em caso de enlace ou de um roteador entrar em falha. O MPLS-TE também pode ser combinado com outros mecanismos de QoS para fornecer garantias para VPNs ou classes de tráfego. O MPLS-TE combina a capacidade de engenharia de tráfego do ATM com a flexibilidade do IP. Basicamente, a ativação dos caminhos no MPLS-TE ocorre pela configuração de túneis de TE unidirecionais, sendo a origem do túnel denominada de head-end e o destino do túnel, denominado tail end. O encaminhamento do tráfego pelos roteadores será baseado na comutação de rótulos, que são mapeados pelo RSVP. Tal protocolo, como vimos no item de QoS, é utilizado pelo serviço IntServ, no qual a aplicação do cliente sinaliza na rede a reserva de banda necessária; porém, extensões foram feitas para permitir ao RSVP o transporte de rótulos MPLS para a aplicação de MPLS-TE, conforme Figura 6.4.

Figura 6.4 – RSVP – MPLS-TE

O MPLS-TE permite um esquema de engenharia de tráfego onde o head-end do LSP pode calcular a rota de forma mais eficiente através da rede em direção ao tail end, necessitando conhecer a topologia da rede e a banda disponível de todos os enlaces na rede. Faz-se necessário habilitar MPLS nos roteadores para estabelecimento do LSP fim-a-fim. O fato da comutação de rótulos ser utilizada, e não o encaminhamento baseado em IP, permite o roteamento baseado em origem ao invés do roteamento baseado em IP de destino.


29/10/2012 14:57:34


6.7 – Atributos de túneis MPLS-TE Alguns dos atributos de túneis MPLS-TE são da mesma natureza que os atributos dos enlaces distribuídos pelos protocolos IGP estendidos para TE. Alguns outros atributos dos túneis MPLS-TE são configurados pelos administradores da rede, transparentemente ao protocolo de roteamento utilizado. Os atributos são listados a seguir: •• endereço do tail end LSR; •• largura de banda desejada; •• atributo de preempção; •• atributo de reotimização; •• fast rerouting.

6.8 – Proteção e restauração – FRR As redes são projetadas com um alto nível de redundância para garantir a oferta dos serviços disponíveis aos clientes. No entanto, muitas vezes a falha em um circuito de comunicação faz com que a recuperação de um serviço gaste um tempo na ordem de dezenas de segundos, dada a quantidade de protocolos envolvidos na convergência. Este tempo de convergência é resultante, principalmente, do tempo de propagação do protocolo IGP, responsável por fazer o rerroteamento rápido para contornar as falhas, efetuando a convergência na rede. Dependendo do tamanho da rede, este tempo pode levar de cinco a dez segundos. Durante esta convergência há perda de pacotes e, consequentemente, uma indisponibilidade do serviço oferecido ao usuário, o que pode afetar o SLA (Service Level Agreement) acordado entre o usuário e o provedor. Fast Reroute (FRR) é uma ferramenta integrante do MPLS-TE. Ela permite que circuitos e roteadores sejam protegidos pelos túneis do MPLS-TE com rápido tempo de convergência. A proteção dos circuitos é denominada Link Protection e a dos roteadores, Node Protection. Ambos os tipos de proteção são conhecidos como proteção local, isso porque os túneis de backup protegem apenas um segmento do caminho. A Figura 6.5 exibe a proteção local entre R3 e R5, denominada de proteção do enlace, e a proteção do nó R5, denominada de proteção do nó. Para a proteção do enlace, o head-end do túnel de backup é o R3, que será o PLR (Point of Local Repair), e o fim


29/10/2012 14:57:34

94 Redes MPLS

do túnel é o roteador R5 (Merge Point). Já para a proteção do nó, o head-end (HE) do túnel é o R3, e o fim do túnel é o roteador R7.

Figura 6.5 – Proteção do enlace e proteção do nó. Adaptado de (Osborne e Simha, 2002)

O enlace R3-R5 é considerado o enlace crítico sobre o qual o túnel primário é sinalizado. Esse enlace será o enlace protegido e, para sua proteção e proteção do túnel principal, um túnel de backup é sinalizado em torno do enlace. A proteção do enlace usa túneis de backup NHop (Next Hop Router) e conta com o fato de que, embora o enlace protegido tenha sido rompido, o roteador na outra ponta desse enlace protegido ainda está ativo; portanto, a proteção do enlace protege de uma falha do enlace, mas não contra uma falha de nó (Osborne e Simha, 2002). A proteção do nó é semelhante à proteção do enlace, porém ela difere porque o MP não é NHop, e sim o NNHop (Next Next Hop Router). No caso da Figura 6.5, o túnel principal faz uso do caminho R1 à R3 à R5 à R7. O enlace R3 à R5 está protegido pelo Túnel 1, e o roteador R5 está protegido pelo Túnel 2. No caso de falha da conexão R3 à R5, o tráfego ocorrerá pelo Túnel 1 até que o túnel principal seja reestabelecido. Já em caso de falha do roteador R5, o tráfego será transmitido através do Túnel 2 até que o túnel principal seja reestabelecido.

6.9 – GMPLS O MPLS Generalizado (Generalized MPLS) é um conjunto de extensões aos protocolos de sinalização de engenharia de tráfego MPLS e aos protocolos de


29/10/2012 14:57:35


roteamento de engenharia de tráfego, com o objetivo de promover um conjunto padronizado e comum para controlar as redes de núcleo. GMPLS é desenvolvido sobre MPLS porque as noções de comutação são muito semelhantes e devido à vantagem de potencializar a reconhecida tecnologia MPLS (Farrel, 2005). A sinalização GMPLS é desenvolvida sobre a sinalização MPLS-TE. Isso não é apenas uma conveniência que reduz a quantidade de novo desenvolvimento de protocolo necessário, mas reflete o fato de o GMPLS ser um conceito advindo do MPLS-TE e usar muitos dos mesmos termos e conceitos. O MPLS possui dois protocolos de sinalização, e ambos foram estendidos para o uso no GMPLS. O GMPLS é uma tecnologia de engenharia de tráfego. Com base no fato de que no MPLS o plano de controle é totalmente dissociado do plano de dados, surgiu no IETF a ideia de se estender o uso do plano de controle do MPLS, com as devidas adequações, para a generalidade de tecnologias de transmissão de dados, incluindo-se aquelas que se baseiam em comutação por circuitos (Enne, 2009). O GMPLS se utiliza do mesmo conceito de comutação de rótulos do MPLS, sendo que o seu objetivo é integrar as tecnologias TDM (Time Division Multiplexing) e WDM (Wavelength Division Multiplexing) com a comutação de pacotes do MPLS. Deve ser observado que no GMPLS a comutação de pacotes é apenas um tipo de GMPLS. Ele se encontra em fase de implantação, havendo uma grande expectativa quanto ao seu uso futuro. As extensões do MPLS para GMPLS definidas nas RFC 4203 (RFC 4203) e RFC 5063 (RFC 5063) relativas às extensões dos protocolos, respectivamente, OSPF-TE e RSVP-TE não são, contudo, suficientes para suportar certas demandas requeridas pelo plano de controle para pleno funcionamento de uma ASON (Automatically Switched Optical Network). O plano de controle das ASONs foi especificado segundo a recomendação G.8080 do ITU-T. Para a extensão da aplicação dos processos de roteamento do GMPLS no sentido de atender essa recomendação do ITU-T, o IETF emitiu a RFC 4258 (RFC 4258), que trata desse assunto específico.


29/10/2012 14:57:35

CAPÍTULO 7. IPv6 sobre MPLS

Este capítulo trata dos fundamentos básicos do protocolo IPv6, assim como de algumas arquiteturas para transporte IPv6 sobre a tecnologia MPLS.

7.1 – O protocolo IPv6 Ao passo que ocorre o crescimento da emergente tecnologia MPLS, o protocolo IP deverá continuar sendo a principal ferramenta adotada por provedores de serviços. Tal protocolo, aliado ao uso da tecnologia MPLS e à possibilidade de unificar as comunicações de voz, vídeo e dados, proporciona benefícios econômicos e tecnológicos para as operadoras. O sucesso do IP como protocolo padrão em nível mundial e base para interligação das redes de computadores é inegável, porém, devido à escassez dos endereços IPv4 existentes hoje, motivada pelo rápido crescimento da Internet, passa a ser de fundamental importância que os provedores de serviços estejam preparados para a adoção e implementação do protocolo IPv6 em seu backbone. Apesar do protocolo IPv6 já existir há mais de uma década, agora é que sua implantação está sendo acelerada, já que ele é imprescindível para a continuidade do crescimento e da evolução da Internet. Vários governos têm incentivado a implantação do IPv6 na Internet através do envolvimento das áreas de comunicações, energia, ciência e tecnologia, educação, dentre outras. No Brasil, estima-se que os endereços IPv4 devam se esgotar entre 2012 e 2014. Segundo dados do CGI (Comitê Gestor da Internet no Brasil), mais de oitenta sistemas autônomos brasileiros já possuem alocações IPv6. As especificações do IPv6 foram apresentadas inicialmente na RFC 1883 (RFC 1883), de dezembro de 1995. No entanto, em dezembro de 1998, esta RFC 96


29/10/2012 14:57:35

IPv6 sobre MPLS 97

foi substituída pela RFC 2460 (RFC 2460). Como principais mudanças do IPv6, destacam-se: • Maior espaço de endereçamento: um endereço IPv6 tem 128 bits de comprimento, permitindo níveis mais específicos de agregação de endereços, identificação de uma quantidade muito maior de dispositivos na rede e implementação de mecanismos de autoconfiguração. A escalabilidade de roteamento multicast também foi melhorada através da adição do campo “escopo” no endereço multicast. • Simplificação no formato do cabeçalho: alguns campos existentes no cabeçalho IPv4 foram removidos ou tornaram-se opcionais, com o intuito de reduzir o custo do processamento dos pacotes nos roteadores. • Suporte a cabeçalhos de extensão: o campo de opções (existente no IPv4) não faz mais parte do cabeçalho base, permitindo um roteamento mais eficaz, limites menos rigorosos em relação ao tamanho e à quantidade de opções e uma maior flexibilidade para a introdução de novas opções no futuro. • Capacidade de identificar fluxos de dados: foi adicionado um novo recurso que permite a identificação de pacotes que pertençam a determinados fluxos de tráfegos, para os quais podem ser requeridos tratamentos especiais. • Suporte a autenticação e privacidade: foram especificados cabeçalhos de extensão, capazes de fornecer mecanismos de autenticação e garantir a integridade e a confidencialidade dos dados transmitidos. Além dessas, o IPv6 também apresenta mudanças no tratamento da fragmentação dos pacotes, que passa a ser realizada apenas no dispositivo de origem, evitando assim um maior processamento nos roteadores ao longo do caminho. O protocolo também trouxe recursos que facilitam a configuração de redes, além de outros aspectos que foram melhorados em relação ao IPv4. Na Tabela 7.1 tem-se uma breve comparação entre os cabeçalhos dos protocolos IPv4 e IPv6. O formato do cabeçalho base IPv6 é apresentado na Figura 7.1.


29/10/2012 14:57:35

98 Redes MPLS Tabela 7.1 – Comparação entre os cabeçalhos IPv4 e IPv6

Campos

IPv4

IPv6

Versão

Identifica a versão do datagrama

Identifica a versão do datagrama

Comprimento do cabeçalho

Informa o comprimento do cabeçalho em palavras de 32 bits

--------------

Tipo de serviço/Classe de tráfego

Usado para fazer a marcação dos pacotes quando do uso de Qualidade de Serviço

Usado para fazer a marcação dos pacotes quando do uso de Qualidade de Serviço

Comprimento total/Comprimento do campo de informação

Define o tamanho total do datagrama

Identifica o tamanho dos dados enviados

Identificação/Flags/Deslocamento do fragmento

Usados em conjunto para fazer fragmentação do datagrama IP

-----------------

Tempo de vida/Limite de encaminhamento

Tempo de vida do pacote na rede

Limite de saltos que o pacote pode dar antes de ser descartado

Protocolo/Próximo cabeçalho

Define o protocolo seguinte usado numa porção de dados do datagrama IP

Identifica o cabeçalho que se segue ao cabeçalho IPv6

Soma de verificação

Campo de verificação do cabeçalho do datagrama

----------------

Endereço de origem

Endereço IP de origem do pacote

Endereço IPv6 de origem do pacote

Endereço de destino

Endereço IP de destino do pacote Raramente utilizado. Existem opções para segurança, timestamps, roteamento mandatório, etc. Garantir que o cabeçalho tem um tamanho múltiplo de 4 bytes ---------------------

Endereço IPv6 de destino do pacote ---------------

Opções

Complemento

Identificador de fluxo


--------------

Identificar um tipo de fluxo de dados

29/10/2012 14:57:35

IPv6 sobre MPLS 99

Figura 7.1 – Formato de um datagrama IPv6

Podemos observar que sete campos do cabeçalho IPv4 foram removidos (Comprimento do cabeçalho, Identificação, Flags, Deslocamento do fragmento, Soma de verificação, Opções e Complemento), uma vez que essas funções não são mais necessárias no cabeçalho base do IPv6. No IPv6, as opções adicionais agora fazem parte dos cabeçalhos de extensão do IPv6; deste modo, os campos Opções e Complementos puderam ser removidos. O campo Tamanho do cabeçalho também foi removido porque o tamanho do cabeçalho IPv6 é fixo em 40 bytes. Os campos Identificação, Flags e Deslocamento do fragmento foram removidos porque as informações referentes à fragmentação são indicadas agora em um cabeçalho de extensão apropriado. Com o intuito de aumentar a velocidade do processamento dos roteadores, o campo Soma de verificação foi retirado, pois esse cálculo já é realizado pelos protocolos das camadas superiores. O campo Identificador de fluxo foi adicionado no IPv6 com o objetivo de acrescentar um mecanismo extra de suporte a QoS ao protocolo IP. Resumindo, as mudanças em termos de cabeçalho entre o IPv4 e IPv6 foram: •• Sete campos do cabeçalho IPv4 foram removidos. •• Quatro campos tiveram seus nomes alterados e seus posicionamentos modificados.


29/10/2012 14:57:36

100 Redes MPLS

•• O campo Identificador de fluxo foi acrescentado. •• Três campos foram mantidos. A seguir descreveremos um resumo sobre cada campo do cabeçalho base do IPv6: •• Versão (4 bits): identifica a versão do protocolo IP utilizado. No caso do IPv6, o valor desse campo é 6. •• Classe de Tráfego (8 bits): identifica e diferencia os pacotes por classes de serviços ou prioridade. Ele continua provendo as mesmas funcionalidades e definições do campo Tipo de serviço do IPv4. •• Identificador de Fluxo (20 bits): identifica e diferencia pacotes do mesmo fluxo na camada de rede. Esse campo permite ao roteador identificar o tipo de fluxo de cada pacote, sem a necessidade de verificar sua aplicação. •• Tamanho dos dados (16 bits): indica o tamanho, em bytes, apenas dos dados enviados junto ao cabeçalho IPv6. Substituiu o campo Tamanho total do IPv4, que indica o tamanho do cabeçalho mais o tamanho dos dados transmitidos. Os cabeçalhos de extensão também são incluídos no cálculo do tamanho. •• Próximo cabeçalho (8 bits): identifica cabeçalho que se segue ao cabeçalho IPv6. Este campo foi renomeado (no IPv4 chama-se Protocolo), refletindo a nova organização dos pacotes IPv6, pois agora este campo não contém apenas valores referentes a outros protocolos, mas também indica os valores dos cabeçalhos de extensão. •• Limite de encaminhamento (8 bits): indica o número máximo de roteadores pelos quais o pacote IPv6 pode passar antes de ser descartado, sendo decrementado a cada salto. Padronizou o modo como o campo Tempo de vida (TTL) do IPv4 tem sido utilizado, apesar da definição original do campo TTL dizer que este deveria indicar, em segundos, quanto tempo o pacote levaria para ser descartado caso não chegasse ao seu destino. •• Endereço de origem (128 bits): indica o endereço de origem do pacote. •• Endereço de destino (128 bits): indica o endereço de destino do pacote.


29/10/2012 14:57:36

IPv6 sobre MPLS 101

7.2 – Endereçamento IPv6 No IPv4, o campo do cabeçalho reservado para o endereçamento possui 32 bits. Este tamanho possibilita um máximo de 4.294.967.296 (2^32) endereços distintos. Na época do seu desenvolvimento, esta quantidade era considerada suficiente para identificar todos os computadores na rede e suportar o surgimento de novas sub-redes. No entanto, com o rápido crescimento da Internet, surgiu o problema da escassez dos endereços IPv4, motivando a criação de uma nova geração do protocolo IP. O IPv6 possui um espaço para endereçamento de 128 bits, sendo possível obter 340.282.366.920.938.463.463.374.607.431.768.211.456 endereços (2^128). Este valor representa aproximadamente 79 octilhões (7,9x10^28) de vezes a quantidade de endereços IPv4 e representa, também, mais de 56 octilhões (5,6x10^28) de endereços por ser humano na Terra, considerando-se a população estimada em 6 bilhões de habitantes, de acordo com o CGI (Comitê Gestor da Internet no Brasil). O endereço IPv6 possui 128 bits e é escrito no seguinte formato: x:x:x:x:x:x:x:x, sendo cada x um valor em hexadecimal de 16 bits. Um exemplo de endereço IPv6 é: 2012:985A:0456:7CAF:0000:0000:F0CA:0872 Apesar de bastante extenso em comparação com o endereço IPv4, no qual temos 32 bits, formados por quatro octetos, é possível a aplicação de técnicas para sua abreviação. É permitido omitir os zeros à esquerda de quaisquer blocos de 16 bits, além de ser possível substituir uma sequência longa de zeros por “::”, porém uma única vez por endereço. Como exemplo, o endereço IPv6 citado anteriormente poderia ser escrito como 2012:985A:456:7CAF::F0CA:0872. Existem três categorias de endereços IPv6: Unicast, Anycast e Multicast. O endereço Unicast é utilizado para identificação individual de uma interface simples. O endereço Anycast é designado para múltiplas interfaces; sendo assim, um pacote que é destinado para um endereço IPv6 de Anycast é enviado para uma interface mais próxima com aquele endereço de Anycast. Neste caso, mais próxima significa com o caminho mais curto, de acordo com o protocolo de roteamento. Já o endereço Multicast é designado para múltiplas interfaces. Um pacote destinado a um endereço IPv6 de Multicast é entregue a todas as interfaces associadas a esse endereço. Os endereços de broadcast não mais existem no IPv6.


29/10/2012 14:57:36

102 Redes MPLS

Assim como existem as classes dos endereços IPv4, há classes dos endereços IPv6 para endereçamentos dos hosts. São elas: Global Unicast, UniqueLocal e Link-Local. Os endereços Global Unicast são endereços públicos, roteáveis e acessíveis na Internet IPv6. O bloco reservado para o endereço Global Unicast é 2000::/3, que corresponde aos intervalos de endereços 2000::/4 a 3000::/4. Os endereços Unique-Local são privados, similares aos endereços privados do IPv4 (RFC1918), e sua faixa é FC00::/7, que compreende o intervalo de FC00::/8 a FD00::/8. Já os endereços Link-Local podem ser usados apenas em um enlace específico, onde a interface está conectada, sendo um endereço atribuído automaticamente. O bloco para estes endereços é FE80::/64 (Florentino, 2012). A Tabela 7.2 resume estes endereços. Tabela 7.2 – Endereços IPv6 Unicast

Tipo do Endereço

Prefixo

Global Unicast

2000::/3 ou 2000::/4 a 3000::/4

Unique Local

FC00::/7 ou FC00::/4 a FD00::/8

Link Local

FE80::/64

O bloco dos endereços de Multicast (utilizados para identificar grupos de interfaces) corresponde a FF00::/8. Em se tratando dos protocolos de roteamento, estes já foram adotados para trabalhar com o protocolo IPv6. O protocolo RIP para IPv6 passou a se chamar RIPng (Routing Information Protocol next generation); já o protocolo OSPF (Open Shortest Path First) para IPv6 passou a se chamar OSPFv3. O protocolo IS-IS (Intermediate System to Intermediate System) também já possui versão para IPv6 (IS-ISv6); assim como o protocolo exterior BGP, que passou a se chamar de MPBGP (MultiProtocol Border Gateway Protocol). Diversos estudos mostram que a penetração do protocolo IPv6 tem aumentado gradativamente; no entanto, é preciso avançar muito mais, pois adiar por mais tempo sua implantação poderá trazer diversos prejuízos para o desenvolvimento de toda a Internet.


29/10/2012 14:57:36

IPv6 sobre MPLS 103

7.3 – Transporte IPv6 sobre um backbone MPLS Devido à necessidade cada vez mais intensa do protocolo IPv6, os provedores de serviços precisam atualizar a sua infraestrutura de modo a transmitir tal protocolo, já que haverá demanda de tráfego IPv6, proveniente dos clientes conectados em sua rede. Para atender a esta necessidade, uma primeira solução seria a configuração do protocolo IPv6 em todos os roteadores do backbone, porém esta solução gera algumas desvantagens. Entre elas: •• Alguns dos roteadores podem não ter um sistema operacional que suporte o protocolo IPv6, sendo necessária a atualização do parque de equipamentos. •• Como muitos clientes ainda estarão usando o protocolo IPv4, será necessário o funcionamento em dual-stack (executar IPv4 e IPv6). •• Para executar o protocolo IPv6 em um backbone, o IPv6 precisaria do suporte ao LDP, o qual ainda não foi implementado. Portanto, tal solução requer uma completa atualização de todos os roteadores pertencentes ao backbone, o que os provedores de serviços preferem evitar. Por se tratar de uma tecnologia que transporta rótulos, o MPLS pode transportar informações além do protocolo IPv4 em seu payload, ou seja, o pacote rotulado pode ser um pacote IPv6, sem a necessidade de que os roteadores Ps executem o protocolo IPv6. Com base nesta ideia, há algumas técnicas ou soluções disponíveis para integrar serviços IPv6 sobre o núcleo dos provedores de serviços, tais como: 6PE, 6VPE e PseudoWire. Todas essas soluções possuem a vantagem da não necessidade de executar o protocolo IPv6 nos roteadores de núcleo (Ps); estes farão apenas um processo de comutação de rótulos. A solução PseudoWire tem algumas desvantagens em relação às soluções 6PE e 6VPE – uma delas é o fato de adicionar cabeçalho de camada 2 para transporte num backbone MPLS. Outra desvantagem seria o fato de ser uma solução ponto-a-ponto, enquanto o 6PE e o 6VPE são soluções multipontos. Embora existam alguns outros mecanismos de integração (IPv6 usando túneis nos roteadores CEs (Customer Edges) e IPv6 sobre um circuito de transporte sobre MPLS), ambos possuem limitações que impactam diretamente a sua adoção. Condições são favoráveis para a introdução de um serviço IPv6 na borda da rede, de forma escalável, sem qualquer restrição de endereços IPv6 e sem colocar


29/10/2012 14:57:36

104 Redes MPLS

o backbone em risco, já que os provedores de serviços possuem backbones bastante estáveis com uma infraestrutura IPv4, e vários cenários de integração são possíveis para ofertar serviços IPv6 na rede MPLS.

7.3.1 – Técnica 6PE Desenvolvida pelo fabricante Cisco Systems, o método de integração conhecido como 6PE (IPv6 Provider Edge over MPLS) permite que domínios IPv6 se comuniquem com outros domínios IPv6 sobre um backbone MPLS-IPv4. Sua implementação não requer atualização nos roteadores de núcleo e nenhuma reconfiguração, devido ao encaminhamento ser baseado em rótulo, o que provê um baixo custo no desenvolvimento do IPv6 no backbone. Podemos citar alguns outros benefícios do uso desse método de integração, tais como: •• Não há impacto na rede IPv4 existente e nos serviços MPLS. •• Não há impacto para o cliente, podendo o provedor fazer uso de roteamento estático ou dinâmico para conexão. •• Não é necessário qualquer parada na rede, podendo os roteadores 6PE serem adicionados ao backbone em qualquer momento. •• Apenas os roteadores de borda, conhecidos como roteadores PE (Provider Edge), necessitam de atualização de software, caso o software atual não possa efetuar tal implementação. 6PE é o método de integração escolhido e recomendado para futura adoção do IPv6 no backbone, eliminando o impacto na operação da rede e aumentando o lucro gerado pela infraestrutura IPv4 já existente. Na Figura 7.2 pode-se visualizar a arquitetura global do método 6PE, onde se percebe que quatro interações de roteamento podem ser encontradas no caminho entre as estações IPv6: •• A nuvem IPv6 rodando um IGP IPv6 (RIPng, IS-ISv6, OSPFv3); •• Os roteadores CEs e os PEs trocando informações de roteamento IPv6 através de um IPv6 EGP (Exterior Gateway Protocol) – MP-BGP (MultiProtocol Border Gateway Protocol), IGP ou rota estática; •• Os roteadores PEs formando um par de roteamento IPv6 através do MP-BGP; •• O roteamento na nuvem MPLS/IPv4 rodando um IPv4 IGP (IS-IS, OSPF) para estabelecer alcançabilidade entre os PEs.


29/10/2012 14:57:36

IPv6 sobre MPLS 105

Figura 7.2 – Arquitetura global 6PE (Cisco, 2010)

É importante ressaltar que o método 6PE não tem nenhum impacto nos roteadores de núcleo, pois estes não têm conhecimento de que estão comutando pacotes IPv6, já que eles apenas usam encaminhamento de rótulo MPLS no backbone. Para que o transporte IPv6 possa ocorrer de forma transparente no backbone, é necessário impor uma hierarquia de rótulos no roteador 6PE de ingresso. O rótulo de mais alto nível (top label) provê conectividade no núcleo MPLS-IPv4, sendo distribuído pelo protocolo LDP (Label Distribution Protocol). O próximo rótulo é utilizado pelo roteador 6PE de saída para encaminhamento IPv6, sendo este distribuído pelo protocolo MP-BGP. Na Figura 7.3 é observado o encaminhamento de um pacote IPv6 através do backbone MPLS com 6PE. Percebe-se, nesse caso, a saída do pacote IPv6 puro da Estação 1, sendo acrescentados rótulos IPv4 (L1) e IPv6 (L2) no 6PE1, efetuada a troca do rótulo de mais alto nível (L1) pelo rótulo L3 pelo roteador de núcleo (P1) e retirado o rótulo no P2. No 6PE2 o rótulo L2 é retirado para entrega do IPv6 puro à Estação 2. Há também uma solução para transporte do IPv6 no backbone MPLS em uma VPN, o qual é chamado de 6VPE. Esta solução é similar para a operação do MPLS-VPN para IPv4. A diferença entre o 6PE e o 6VPE é que no 6VPE o prefixo


29/10/2012 14:57:36

106 Redes MPLS

IPv6 do cliente pertence a uma VPN e é completamente separado dos prefixos de outros clientes que conectam para a mesma rede MPLS-VPN (De Ghein, 2007).

Figura 7.3 – Encaminhamento 6PE (Cisco, 2010)

7.3.2 – Técnica 6VPE A solução MPLS-VPN para IPv6 ou IPv6 VPN Provider Edge (6VPE) é similar à operação do MPLS-VPN para IPv4. Como já explicamos o MPLS-VPN para IPv4 no capítulo 3, torna-se desnecessário repetir todos os aspectos. Sugerimos a leitura do capítulo 3 antes da leitura desta parte do livro. A diferença básica entre a técnica 6PE e 6VPE é que, na 6VPE, os prefixos IPv6 do cliente pertencem a uma VPN e são completamente separados dos prefixos de outros clientes que conectam-se à mesma rede MPLS. Os provedores de serviços que já tenham desenvolvido o serviço MPLSVPN sobre um backbone IPv4 podem desenvolver o MPLS-VPN para IPv6 sobre o mesmo backbone apenas atualizando o sistema operacional e configurando o dual-stack, sem quaisquer mudanças nos roteadores de núcleo. O enlace PE-CE pode ser um enlace IPv4, um enlace IPv6 ou uma combinação de IPv4 e IPv6, conforme Figura 7.4.


29/10/2012 14:57:36

IPv6 sobre MPLS 107

Figura 7.4 – Desenvolvimento 6VPE (Cisco, 2011)

6VPE oferece a mesma arquitetura que o MPLS-VPN IPv4 e usa os mesmos componentes, tais como: •• Multi Protocol BGP (MP-BGP) VPN address family •• Router distinguishers •• Instâncias de VPN Routing and Forwarding (VRF) •• Extended community •• MP-BGP O roteador 6VPE troca informações com o outro roteador 6VPE no domínio MPLS, usando o MP-BGP, e compartilha um protocolo de roteamento (ex.: OSPF ou IS-IS) com o outro dispositivo P e PE do domínio. Tabelas de roteamento separadas são mantidas para a pilha IPv4 e IPv6. Pacotes IPv6 de entrada do cliente na interface que pertence a uma VRF 6VPE são transparentemente encaminhados do núcleo IPv4 do provedor de serviços, somente com a leitura do rótulo MPLS, eliminando a necessidade de túneis para pacotes IPv6. Este processo é transparente aos roteadores de núcleo (P), desde que eles apenas façam a comutação dos pacotes IPv6 rotulados.


29/10/2012 14:57:37

CAPÍTULO 8. Implementando Redes MPLS

Este capítulo trata da implementação do MPLS, bem como de alguns dos seus principais serviços e do uso de duas técnicas para transporte do IPv6 em um backbone MPLS. Toda a implementação foi efetuada através das simulações de ambientes, fazendo uso da ferramenta de emulação GNS3 (GNS3, 2012), que será descrita em seguida. A ideia deste capítulo é oferecer ao leitor o conhecimento prático da tecnologia, consolidando assim todo o conhecimento teórico já adquirido nos capítulos anteriores, podendo todo o ambiente ser reproduzido integralmente.

8.1 – A ferramenta de simulação dos ambientes Poderíamos citar alguns dos principais fabricantes de equipamentos disponíveis no mercado para implementação da tecnologia MPLS: Cisco Systems (Cisco, 2012), Juniper Networks (Juniper, 2012), Huawei Technologies (Huawei, 2012) e HP (HP, 2012). Devido à sua maior popularidade, à facilidade de software para emulação e à grande gama de provedores de serviços fazerem uso do fabricante Cisco Systems em seu backbone, todos os testes realizados serão exemplificados com base nos comandos e equipamentos deste fabricante. Foi utilizado um ambiente de simulação para os testes através do software emulador GNS3. Ao contrário dos simuladores, que reproduzem algumas características de dispositivos de redes reais, mas nem tudo é permitido, os emuladores são softwares criados para transcrever instruções de um determinado processador para o processador no qual ele está sendo executado, sendo capaz de reproduzir funções de circuitos integrados e arquiteturas do sistema de hardware. Tais softwares têm a capacidade de transformar um computador comum em um dispositivo de rede, como um roteador real, replicando praticamente todas as suas funções (Filippetti, 2008). 108


29/10/2012 14:57:37

Implementando Redes MPLS 109

Existem vários softwares que fazem emulação para geração de elementos virtuais, os quais podemos citar: Olive (Juniper, 2012) e GNS3. Freesco (Freesco, 2012), Zebra (Zebra, 2012) e Vyatta (Vyatta, 2012) são na realidade softwares que fazem roteamento em Linux, porém não emulam roteadores, não atendendo à necessidade desta obra. O emulador Olive permite emular parcialmente um roteador do fabricante Juniper em um PC, tendo algumas limitações, pois só executa uma instância por computador e não é executável em sistemas operacionais distintos. O software GNS3 será o emulador aqui utilizado, pois atende a todos os requisitos necessários para emulação das funcionalidades que serão exibidas. Tratase de um emulador gráfico que é fortemente utilizado com o Dynamips (um emulador Cisco IOS) e o Dynagem (um front-end para Dynamips baseado em texto). Seguem algumas características do GNS3: • Cada roteador virtual criado é, de fato, uma emulação completa de um roteador Cisco, suportando todos os protocolos e RFCs que um roteador Cisco real suportaria. • Várias instâncias de roteadores virtuais podem ser criadas e executadas em um mesmo PC. • Permite a comunicação entre elementos emulados e elementos físicos. • Trata-se de um software de domínio público. • Pode ser utilizado em quaisquer tipos de computadores e sob os mais diversos sistemas operacionais, tais como: Linux, Windows e FreeBSD. O emulador GNS3 permite a reprodução fiel das características de diversos modelos de roteadores do fabricante Cisco Systems, possibilitando a criação de diversos cenários, com plataformas de roteadores 1700, 2600, 3600, 3700 e 7200. O GNS3 também permite a adição virtual de alguns módulos disponíveis para cada plataforma de roteador. Seguem alguns desses módulos de hardware que são suportados: • Módulos Ethernet: “NM-1E”, “NM-4E”, “NM-1FE-TX”, “PA-FE-TX”, “PA-2FETX”, “PA-4E” e “PA-8E”. • Módulo de comutador Ethernet: “NM-16ESW”. • Módulos GigabitEthernet: “PA-GE”, “PA-4T+” e “PA-8T”. • Módulo Serial: “NM-4T”.


29/10/2012 14:57:37

110 Redes MPLS

•• Módulo ATM: “PA-A1”. •• Módulo POS (Packet Over SONET): “PA-POS-OC3”. É possível emular os seguintes elementos internos do roteador com o software GNS3: •• Dynamic Random Access Memory (DRAM). •• Non-Volatile Random Access Memory (NVRAM). •• Signetics SCN 2681 DUART (portas console e auxiliar no roteador série 7200). •• National Semiconductors NS16552 DUART (portas console e auxiliar nos roteadores Cisco séries C3600/C3700/C2600). •• EEPROM NMC93C46. •• Bootflash de 8 MB (Intel 28F016SA). •• Controladores PCI Galileo GT64010/GT64120/GT96100. •• Disco ATA PCMCIA (por enquanto, disponível apenas no roteador Cisco série 7200). Uma das grandes vantagens em adotar um software de emulação como o GNS3 é permitir a interconexão do ambiente virtual com um ambiente real, além da possibilidade de interação com um ambiente idêntico ao proporcionado por elementos de rede reais. O GNS3 transcreve instruções de processadores de alguns modelos de roteadores para que sejam interpretadas pelo processador presente no computador no qual o software está sendo executado. Devido ao processo ser bastante intenso, o desempenho de um roteador emulado jamais será igual ao de um roteador real, sendo esta uma das limitações identificadas no uso desse emulador.

8.2 – Topologia de base utilizada A topologia completa que servirá como base para todas as implementações e testes realizados é apresentada na Figura 8.1. Embora essa topologia não reflita, em termos de dimensão, a realidade de um backbone de um provedor de serviços, normalmente composto de centenas de roteadores, procuramos utilizar uma topologia suficiente para exibição dos serviços aqui propostos, podendo servir em sua integridade a um backbone real.


29/10/2012 14:57:37


Figura 8.1 – Topologia base para simulação dos ambientes

8.2.1 – Recursos utilizados •• Hardware: quatro roteadores – modelo 7206VXR. Estes farão função de PE e P da rede MPLS, com 160 MB de memória RAM e 64 MB de memória flash. Cinco roteadores – modelo 3640. Estes farão função de CE, com 128 MB de memória RAM e 8 MB de memória flash. •• Versões de software: para escolha da versão do software utilizado, levamos em consideração todas as características necessárias para a implementação dos serviços utilizados nessa demonstração. Para os roteadores 7206VXR, utilizamos a versão do Sistema Operacional (IOS) 12.4-7a. Para os roteadores 3640, utilizamos a versão 12.4-13b. •• Gerador de tráfego: TfGen (Traffic Generator) (TFGEN, 2012). Trata-se de uma ferramenta gratuita para geração de tráfego. •• Gerador de gráficos: SNMP (Simple Network Management Protocol) Traffic Grapher (STG) é um programa que permite controlar até dois OIDs


29/10/2012 14:57:38

112 Redes MPLS

(Object IDentifiers) SNMP em tempo real. Pode ser adaptado para se conectar a praticamente qualquer OID SNMP e controlar outras métricas.

8.3 – Escolha do protocolo IGP/EGP e esquema de endereçamento IP Para a utilização do MPLS, os protocolos IGPs (Interior Gateway Protocols) recomendados são o OSPF (Open Shortest Path First) ou o IS-IS (Intermediate System to Intermediate System). Tanto o OSPF quanto o IS-IS são excelentes protocolos de roteamento link-state, estáveis e escaláveis, porém, de acordo com o fabricante Cisco Systems, o IS-IS é tecnicamente superior, por oferecer melhor escalabilidade e se mostrar mais estável para redes com mais de quatrocentos roteadores. Por este motivo, o protocolo de roteamento interno utilizado para essa simulação será o IS-IS.

8.3.1 – Protocolo IS-IS – endereços NSAP O endereço NSAP (Network Service Access Point) identifica cada roteador na topologia de roteamento. Existem vários formatos de NSAP, e para essa simulação foi adotado o seguinte formato: AFI

Area ID

System ID

NSEL

49.0172.0001.0000.0001.00 AFI

49

Authority and Format Identifier. O valor 49 indica administração local.

Area ID

172

Identificador da área IS-IS.

System ID

00xx.00yy.00zz

Usado para identificar o dispositivo. Sendo: xx = segundo octeto da loopback 0. yy = terceiro octeto da loopback 0. zz = quarto octeto da loopback 0.

NSEL

00

NSAP Selector. Para roteadores o valor padrão é 00.


29/10/2012 14:57:38


Observação: Vale salientar que todos os esquemas de endereçamentos e parâmetros utilizados são fictícios. Utilizamos endereços de loopbacks para todos os roteadores, com o objetivo de divulgação de rotas e testes de conectividade.

8.3.2 – Protocolo IS-IS – áreas Com relação às áreas utilizadas pelo IS-IS, foi usada apenas uma área (backbone ou nível 2). Na prática, normalmente se usa apenas uma área no backbone para evitar a perda de funcionalidades de engenharia de tráfego dinâmicas, como fast reroute. Definido o endereçamento IPv4 da rede, serão tomados como base os endereços de loopback para formação do area ID e do system ID. Exemplo: para o P1 (loopback 172.10.0.1) utilizado nas simulações, o endereço NSAP será: 49.0172.0010.0000.0001.00. Para definição da área única, é necessário inserir o comando “is-type level2-only” no modo de roteamento IS-IS, em todos os roteadores do backbone.

8.3.3 – Protocolo BGP O BGP (Border Gateway Protocol) é um protocolo robusto e escalável, suportando atualmente algo em torno de 200.000 rotas – por isso é o protocolo mais utilizado na Internet. Para atingir essa escalabilidade, o BGP utiliza diversos parâmetros, chamados de atributos, que definem políticas de roteamento e mantêm a estabilidade do ambiente. Além desses atributos, o BGP utiliza o CIDR (Classless Inter-Domain Routing) para reduzir o tamanho das tabelas de roteamento. Os vizinhos BGPs trocam todas as informações de roteamento após o estabelecimento de uma sessão TCP entre eles. Após isso, quando uma alteração na tabela é detectada, os vizinhos somente trocam informações a respeito do que se alterou. Não há uma troca periódica de informações, e as atualizações que ocorrem somente anunciam o melhor caminho existente para a rede de destino. O BGP permitiu a adição de extensões no protocolo criando o MP-BGP (Multi Protocol BGP). Estas extensões permitem e facilitam a troca de informações associadas aos clientes MPLS VPN entre os roteadores PEs do backbone. Assim, é possível trocar informações de diferentes protocolos através de uma única sessão


29/10/2012 14:57:38

114 Redes MPLS

BGP entre os PEs. Esses protocolos são: IPv4, IPv6, VPNv4, entre outros, todos conhecidos como Address Families.

8.3.4 – Definição do sistema autônomo O sistema autônomo utilizado no backbone MPLS simulado foi de âmbito privado. De acordo com a recomendação da RFC 1930 (RFC 1930), o intervalo a ser usado para sistemas autônomos privados deve estar entre 64512 e 65535. Será aqui adotado o sistema autônomo 65500.

8.3.5 – Configuração do MP-iBGP A configuração do Multi Protocol BGP consiste em dois elementos: •• Configuração geral das sessões, como: Neighbor address, Source interface, Remote AS number, etc. •• Configuração e ativação do Address Families de VPNv4, incluindo as políticas associadas (route-maps, filters, etc.).

8.3.6 – Configuração geral do BGP Os vizinhos BGP precisam ser explicitamente ativados, pois não há uma descoberta automática de adjacência como no IS-IS, por exemplo. Por essa razão, os vizinhos BGP não precisam ser diretamente conectados. A sessão BGP precisa ser ativada configurando-se os seguintes parâmetros em ambos os lados: •• Configuração do processo BGP com o AS 65500: router bgp 65500. •• Endereço IP do vizinho e o número de AS remoto. O endereço IP utilizado também será o de loopback 0, e o número do AS será o 65500: neighbor x.x.x.x remote-as 65500. •• Por padrão, o IOS utiliza o endereço IP da interface de saída em direção ao vizinho como IP de origem. Como utilizaremos para ambos os vizinhos da mesma sessão um endereço de loopback, é necessário explicitamente configurar o comando a seguir; caso contrário, a sessão não se estabelecerá: neighbor x.x.x.x update-source loopback0.


29/10/2012 14:57:38


8.3.7 – Configuração do Address Family VPNv4 Conforme já mencionado, os prefixos de VPNv4 consistem em 32 bits do endereço IPv4 mais 64 bits do campo route distinguisher – RD (). A adição do RD permite a sobreposição de endereços IPs em VPNs distintas. Além do prefixo de VPNv4, as atualizações desse Address Family contêm: um rótulo MPLS, que é o rótulo da VPN, também chamado de inner label; e alguns atributos de BGP extended community, como por exemplo os route targets, que são usados pelos roteadores PEs para construírem a topologia da VPN. Os comandos a seguir são necessários para ativar o Address Family de VPNv4 para um vizinho. Todos eles devem ser executados dentro do address-family vpnv4, no modo de configuração do BGP: •• Ativar o vizinho dentro do Address Family: neighbor x.x.x.x activate. •• Habilitar o envio de atributo de extended community para os vizinhos: neighbor x.x.x.x send-community extended.

8.4 – Testes realizados e observações Nos próximos itens serão exibidos todos os testes e configurações realizados para diversas implementações da tecnologia MPLS, desde as funcionalidades básicas da tecnologia até os serviços fornecidos.

8.4.1 – Comportamento básico do MPLS De acordo com a topologia base, exibida na Figura 8.1, iremos demonstrar a funcionalidade básica da tecnologia MPLS sem qualquer implementação de serviços oferecidos, os quais serão demonstrados isoladamente mais adiante. Basicamente, o MPLS pode operar em dois modos: frame-mode e cell-mode. O modo frame-mode consiste na inserção de um rótulo entre a camada 2 e a camada 3 de um pacote IP puro, conforme mostra a Figura 8.2:


29/10/2012 14:57:38

116 Redes MPLS

Figura 8.2 – MPLS frame-mode

Nesse modo, os roteadores são diretamente conectados através de interfaces frame-mode, tais como o PPP. Os cabeçalhos PPP e LAN exibem o rótulo sendo inserido entre os cabeçalhos da camada 2 e da camada 3, sendo chamados de cabeçalhos de calço (shim). Portanto, nesse modo é sempre visto um cabeçalho de calço, mesmo quando se está simplesmente conectando roteadores por PVC ATM e realizando MPLS em um ambiente clássico de IP sobre ATM (Osborne e Simha, 2002). Já no modo cell-mode, os LSRs no núcleo da rede MPLS são comutadores ATM, que encaminham dados baseados no cabeçalho ATM. Nesse caso, diz-se que o rótulo está codificado nos campos de VPI/VCI (Virtual Path Identifier/Virtual Circuit Identifier) de uma célula, conforme Figura 8.3.

Figura 8.3 – MPLS cell-mode

Para essa simulação, iremos utilizar o modo frame-mode, por ser o modo usado pelos ISPs atuais, trabalhando no nível de IP. Iremos configurar os equipamentos do backbone MPLS (PE1, PE2, P1 e P2), e os testes serão executados a partir dos clientes, CE11 e CE22, estabelecendo uma comunicação entre eles através do backbone MPLS.


29/10/2012 14:57:38


8.4.2 – Configurações São aqui apresentados os passos para configurações dos equipamentos de backbone: Habilitar CEF Configurar o protocolo IS-IS Configurar o protocolo BGP

Router(config)#ip cef [distributed] Router(config)#router Isis area-tag Router(config-router)#net network-entity-title Router(config)#interface interface-type number Router(config-if)#ip router isis area-tag

Router(config)#router bgp autonomous-system Router(config-router)#neighbor {ip-address | peer-group-name} remote-as number

Definir o protocolo de distribuição de labels

Router(config)#mpls label protocol ldp

Configurar MPLS na interface

Router(config)#interface interface-type number Router(config-if)#mpls ip

Passo 1: habilitar o CEF O CEF é o acrônimo para Cisco Express Forwarding (Bollapragada et al, 2000). É basicamente utilizado para acelerar o processo de comutação dos roteadores, diminuindo a carga de processamento nos roteadores. É um componente chave da arquitetura Tag Switching da Cisco e passa a ser fundamental a sua utilização nos roteadores da Cisco ao se fazer uso da tecnologia MPLS. Em todos os roteadores do backbone deveremos habilitar o CEF através do comando “ip cef” ou “ip cef distributed”, conforme descrito antes. Passo 2: configurar o IS-IS É necessário configurar o protocolo IS-IS em todos os roteadores do backbone MPLS. Por exemplo, a configuração para o roteador PE1 segue: router isis net 49.0172.0001.0000.0001.00 is-type level-2-only interface loopback 0 ip router isis interface serial1/2 ip router isis interface serial1/3 ip router isis


29/10/2012 14:57:38

118 Redes MPLS

Passo 3: configurar o BGP A configuração do BGP é necessária nos roteadores de borda do backbone. Como exemplo, o roteador PE1 foi assim configurado: router bgp 65500 no synchronization redistribute static neighbor 172.2.0.1 remote-as 65500 neighbor 172.2.0.1 update-source loopback0 neighbor 172.2.0.1 next-hop-self

O comando “redistribute static” foi utilizado neste caso porque foram usadas rotas estáticas para comunicação entre os CEs e os PEs, sendo necessária a redistribuição do tráfego para dentro do backbone MPLS. O comando “next-hop-self” força o BGP a usar o seu próprio endereço BGP como próximo salto, em vez de deixar que o protocolo escolha o endereço do próximo salto a ser usado. Já o comando “no synchronization” desativa a sincronização do protocolo BGP, permitindo que um roteador use e anuncie para um BGP externo as rotas vizinhas aprendidas pelo IBGP (Interior Border Gateway Protocol). Isto ocorre antes do roteador receber a informação das rotas vizinhas do protocolo IGP. Os demais comandos já foram explicados. Passo 4: definir o protocolo de distribuição de rótulo O protocolo de distribuição de rótulo precisa ser configurado em todos os LSRs, conforme comando inserido no PE1: mpls label protocol ldp

Passo 5: configurar MPLS na interface É necessário habilitar o comando para encaminhamento do rótulo nas interfaces entre os PEs e os Ps através do comando “mpls ip” para a interface serial1/2 do PE1: interface serial1/2 mpls ip

Observação: as configurações finais detalhadas dos roteadores se encontram no Apêndice A deste livro.


29/10/2012 14:57:38


8.4.3 – Verificações e testes de conectividade Analisamos a operação do “control plane” no modo frame-mode MPLS para o prefixo 172.1.0.1/32, do PE1 para o PE2, passando pelo P1 e pelo P2. Segue o passo a passo do processo de propagação do rótulo. Para uma melhor demonstração e visualização da funcionalidade MPLS, fizemos com que o tráfego do PE1 para o PE2 fosse encaminhado através do caminho PE1 à P1 à P2 à PE2, contrariando o caminho escolhido pelo IGP IS-IS, que alterna entre os caminhos PE1 à P1 à PE2 e PE1 à P2 à PE2. Porém, apenas para essa demonstração, fizemos tal alteração. Para essa mudança de roteamento, foi acrescentado o comando “is-is metric 30”, na interface serial1/3 do PE1 e serial1/1 do P1, aumentando assim o custo por esses caminhos e evitando o seu uso. Analisemos o comportamento do backbone, de acordo com a Figura 8.4:

Figura 8.4 – Porção do backbone extraída da topologia representativa para demonstração da funcionalidade básica da tecnologia MPLS


29/10/2012 14:57:39

120 Redes MPLS

A Figura 8.4 exibe a operação do control plane para o prefixo 172.1.0.1/32, com origem em PE1 e destino no PE2. Segue o passo a passo para melhor entendimento do processo de propagação do rótulo MPLS. Passo 1: O roteador PE1 envia um implicit-null ou o POP rótulo para P1. PE1 propaga o rótulo implicit-null para o penúltimo roteador, o P1, que irá efetuar a função POP no encaminhamento dos dados de PE2 para o prefixo 172.1.0.1/32. Vejamos a tabela LIB do PE1. PE1#show mpls ldp bindings tib entry: 172.1.0.1/32, rev 10 local binding: tag: imp-null remote binding: tsr: 172.10.0.1:0, tag: 16

Passo 2: O roteador P1 designa um rótulo de valor 16 para o prefixo 172.1.0.1/32. Esse valor de rótulo é enviado para P2 e será usado para encaminhamento ao prefixo 172.1.0.1/32. Vejamos a tabela LFIB do P1: P1#show mpls forwarding-table Local Outgoing Prefix tag tag or VC or Tunnel Id 16 Pop tag 172.1.0.1/32 17 16 172.2.0.1/32 19 Pop tag 192.168.0.24/30 20 Pop tag 172.20.0.1/32

Bytes tag switched 8852 9401 0 142

Outgoing interface Se1/0 Se1/2 Se1/2 Se1/2

Next Hop point2point point2point point2point point2point

Passo 3: No roteador P2, o prefixo 172.1.0.1/32 foi associado a um rótulo local de 17 e um rótulo de saída 16. O rótulo de saída foi recebido do P1. O rótulo local de 17 será enviado para o PE2 durante o processo de distribuição de rótulo e será usado para encaminhamento ao prefixo 172.1.0.1/32. Vejamos a tabela LFIB do P2: P2#show mpls forwarding-table Local Outgoing Prefix tag tag or VC or Tunnel Id 16 Pop tag 172.2.0.1/32


Bytes tag switched 9319

Outgoing interface Se1/1

Next Hop point2point

29/10/2012 14:57:39


17 18 20

16 Pop tag Pop tag

172.1.0.1/32 172.10.0.1/32 192.168.0.12/30

44 0

9381

Se1/2 Se1/2 Se1/2

point2point point2point point2point

Sendo assim, podemos observar o encaminhamento do tráfego destinado ao prefixo 172.1.0.1/32 originando do PE2. Primeiramente, vamos observar a tabela de encaminhamento LFIB do PE2: PE2#show mpls forwarding-table Local Outgoing Prefix tag tag or VC or Tunnel Id 16 Untagged 20.30.40.0/24 17 Untagged 200.2.0.2/32 18 18 172.10.0.1/32 19 17 172.1.0.1/32 20 20 192.168.0.12/30 21 Pop tag 192.168.0.28/30 23 Pop tag 172.20.0.1/32

0

Bytes tag switched 0 0 0 0 0 0

Outgoing Next Hop interface Se1/1 point2point Se1/1 point2point Se1/3 point2point Se1/3 point2point Se1/3 point2point Se1/3 point2point Se1/3 point2point

Assim, podemos afirmar que PE2 irá inserir o rótulo 17 no pacote IP com destino ao prefixo 172.1.0.1/32, o que pode ser visto também na Figura 8.4. O roteador P2 faz um lookup na LFIB, troca o rótulo de 17 para 16 e encaminha o pacote para P1. O roteador P1 recebe o pacote do P2, executa a função PHP (Penultimate Hop Popping), remove o rótulo 16 e encaminha o pacote para o PE1, conforme Figura 8.4. Para efetuarmos os testes de conectividade, inserimos rotas estáticas no PE1 e PE2 para atingir os loopbacks do CE11 e CE22. Como já habilitamos o BGP e redistribuímos as rotas estáticas, essas rotas já deverão aparecer nas tabelas de roteamento BGP dos roteadores PEs. Vejamos as configurações dos CEs e as tabelas de roteamento BGP dos PEs: hostname CE11 ip cef interface Loopback0 ip address 200.1.0.1

255.255.255.255

interface Serial1/0 ip address 150.1.1.2

255.255.255.252

ip route 0.0.0.0 0.0.0.0 150.1.1.1

PE1#show ip route bgp 200.2.0.0/32 is subnetted, 1 subnets B 200.2.0.2 [200/0] via 172.2.0.1


29/10/2012 14:57:39

122 Redes MPLS hostname CE22 ip cef interface Loopback0 ip address 200.2.0.2

255.255.255.255

interface Serial1/0 ip address 150.1.2.6

255.255.255.252

ip route 0.0.0.0 0.0.0.0 150.1.2.5 PE2#show ip route bgp 200.1.0.0/32 is subnetted, 1 subnets B 200.1.0.1 [200/0] via 172.1.0.1

Para os testes de conectividade utilizamos os comandos “ping” e “traceroute”, com origem em CE11 e destino em CE22. CE11#ping 200.2.0.2 source 200.1.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 200.2.0.2, timeout is 2 seconds: Packet sent with a source address of 200.1.0.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 264/506/752 ms CE11#traceroute 200.2.0.2 source 200.1.0.1 Type escape sequence to abort. Tracing the route to 200.2.0.2 1 2 3 4 5

150.1.1.1 460 msec 312 msec 308 msec 192.168.0.14 [MPLS: Label 17 Exp 0] 144 msec 548 msec 240 msec 192.168.0.30 [MPLS: Label 16 Exp 0] 432 msec 932 msec 296 msec 192.168.0.25 192 msec 128 msec 168 msec 150.1.2.6 160 msec 256 msec 1152 msec

Podemos observar o caminho percorrido pelo pacote, partindo do CE11 para o CE22. Através da rota padrão inserida no roteador CE11, o pacote IP chega ao roteador PE1. O roteador PE1 tem, em sua tabela BGP, rota para 200.2.0.2, enviando o pacote para o IP 172.2.0.1 (loopback 0 do PE2). Porém, o endereço 172.2.0.1 é aprendido pelo PE1 via protocolo IS-IS através do IP 192.168.0.14 (serial1/0 do P1), conforme informações a seguir:


29/10/2012 14:57:39


PE1#show ip route 172.2.0.1 Routing entry for 172.2.0.1/32 Known via “isis”, distance 115, metric 40, type level-2 Redistributing via isis Last update from 192.168.0.14 on Serial1/2, 02:52:33 ago Routing Descriptor Blocks: * 192.168.0.14, from 172.2.0.1, via Serial1/2 Route metric is 40, traffic share count is 1

Desta forma, o pacote será encaminhado ao P1 e, de acordo também com a tabela LFIB do PE1, será utilizado o rótulo 17 e o pacote será enviado para a interface serial1/2. PE1#show mpls forwarding-table Local Outgoing Prefix Tag tag or VC or Tunnel Id 16 Untagged 10.20.30.0/24 17 Untagged 200.1.0.1/32 18 Pop tag 172.10.0.1/32 19 17 172.2.0.1/32 21 Pop tag 192.168.0.28/30 22 19 192.168.0.24/30 23 20 172.20.0.1/32

Bytes tag Outgoing Next Hop switched interface 0 Se1/0 point2point 0 Se1/0 point2point 0 Se1/2 point2point 0 Se1/2 point2point 0 Se1/2 point2point 0 Se1/2 point2point 0 Se1/2 point2point

O roteador P1 receberá o pacote com rótulo 17 e fará a função de troca de rótulo (label swapping), trocando o rótulo de 17 por 16 e encaminhando para a interface serial1/2. P1#show mpls forwarding-table Local Outgoing Prefix tag tag or VC or Tunnel Id 16 Pop tag 172.1.0.1/32 17 16 172.2.0.1/32 19 Pop tag 192.168.0.24/30 20 Pop tag 172.20.0.1/32

Bytes tag switched 25399 26290 0 142

Outgoing interface Se1/0 Se1/2 Se1/2 Se1/2


O roteador P2 receberá o pacote e, de acordo com sua LFIB, irá retirar o rótulo, enviando IP puro para a interface serial1/1. P2#show mpls forwarding-table Local Outgoing Prefix tag tag or VC or Tunnel Id 16 Pop tag 172.2.0.1/32 17 16 172.1.0.1/32 18 Pop tag 172.10.0.1/32 20 Pop tag 192.168.0.12/30


Bytes tag Outgoing switched interface 25294 Se1/1 26274 Se1/2 44 Se1/2 0 Se1/2


29/10/2012 14:57:39

124 Redes MPLS

Assim, o pacote chegará até o PE2, que, através da rota estática definida previamente, envia o pacote para a loopback do CE22 (200.2.0.2). Pelo comando traceroute executado, vemos a passagem pelos roteadores P1 e P2 usando os rótulos 17 e 16, efetuando um processo de comutação. Outros comandos de visualização podem ser encontrados no Apêndice A. Dessa forma, podemos demonstrar a funcionalidade básica da tecnologia MPLS, exibindo o processo que ocorre no backbone para transmissão de um pacote. Em todos os roteadores do backbone habilitamos o protocolo IS-IS, escolhido como protocolo IGP. Nos roteadores de borda (PEs) também habilitamos o protocolo BGP. Observa-se que, na entrada do backbone, um rótulo é inserido através do roteador PE de entrada. Nos roteadores Ps o rótulo é trocado através de um processo conhecido como label swapping, e na saída o rótulo é retirado para entrega do pacote IP puro ao cliente (CE). Vimos também a funcionalidade da técnica PHP (Penultimate Hop Popping), retirando o cabeçalho MPLS no penúltimo roteador (em nossa simulação, o roteador P1), fazendo com que execute um popping, ao invés de um swap, com isso retirando o cabeçalho MPLS e evitando que o roteador de saída, no caso PE1, efetue a análise do rótulo e do cabeçalho de rede, tendo que ler duas tabelas. Os roteadores do núcleo da rede não precisam conhecer rotas para os roteadores CEs, o que reduz o tamanho da sua tabela de rotas e melhora o seu desempenho. Ao invés de um processo de roteamento, os roteadores do núcleo efetuam o processo de switching (comutação). Esse é o processo fundamental de funcionalidade da tecnologia MPLS, portanto, como já foi aqui comentado, a tecnologia tem foco em seus serviços como grande atrativo aos provedores. Iremos demonstrar os principais nos próximos itens.

8.4.4 – PseudoWire MPLS Em virtude de trabalhar com diversas tecnologias de acesso, tais como ATM, FR e Ethernet, o PseudoWire MPLS também poderá ser útil a qualquer momento que seja necessário transmitir quaisquer dessas tecnologias de acesso citadas sobre o backbone MPLS. Para essa simulação, primeiramente iremos utilizar a configuração de um transporte HDLC (High-level Data Link Control) sobre o MPLS, provendo um PseudoWire para comunicação entre dois clientes Frame Relay, representado na topologia pelos roteadores CE11 e CE22.


29/10/2012 14:57:39


Em seguida, iremos demonstrar o PseudoWire para transmissão do Frame Relay sobre o MPLS utilizando a conexão do tipo dlci-to-dlci, a qual comentaremos antes da demonstração. A Figura 8.5 será utilizada para demonstração do PseudoWire transportando HDLC sobre o MPLS. A transmissão bem-sucedida dos frames de camada 2 entre os roteadores PE provém da configuração dos roteadores PEs. A conexão entre os roteadores, denominada PseudoWire, deve especificar a seguinte informação em cada roteador PE: •• Tipo de dado da camada 2 a ser transportado através do PseudoWire, como por exemplo: Ethernet, Frame Relay, HDLC, PPP, ATM. •• O endereço IP da interface loopback do roteador par PE, que torna os roteadores PEs capazes de estabelecer comunicação. •• Uma combinação única de endereço IP do par PE e VC ID, que identifica o PseudoWire. Para configuração básica do PseudoWire em um roteador PE, devemos seguir os passos adiante. Para cada tipo de transporte há passos ligeiramente distintos.

Figura 8.5 – Topologia para testes do serviço PseudoWire MPLS


29/10/2012 14:57:39

126 Redes MPLS

1. Definir a interface ou subinterface no roteador PE. Router(config)#interface interface-type interface-number

2. Especificar o tipo de encapsulamento para a interface. Router(config-if)#encapsulamento encapsulation-type

3. Executar as seguintes ações: •• Criar uma conexão ao roteador par PE, especificando o ID do roteador de LDP no par PE. •• Apontar um identificador único, compartilhando entre os dois PEs. VCID é um identificador de 32 bits. •• Especificar o método de tunelamento usado para encapsular dados no PseudoWire, sendo o MPLS o método para o PseudoWire. Router(config-if)#xconnect peer-router-id vcid encapsulation mpls

Observação: opcionalmente, é possível estabelecer um PseudoWire class para especificar o método de tunelamento e outras características.

Apresentamos, na Figura 8.6, as configurações inseridas nos roteadores de backbone, assim como as configurações dos clientes para testes do PseudoWire. Em seguida, mostraremos as verificações através de comandos de visualizações relativas ao serviço. Para os clientes, utilizamos uma configuração de Frame Relay ponto-a-ponto, com o CE11 fazendo a função também de switching Frame Relay.

Verificações do PseudoWire para transporte do HDLC sobre MPLS Com os dois comandos a seguir, verificamos que o PseudoWire está funcional para transporte de HDLC sobre MPLS, mostrando o estado do PseudoWire.


29/10/2012 14:57:39


Figura 8.6 – Configurações PseudoWire para transporte HDLC sobre MPLS

PE1#show mpls l2transport vc Local intf Local circuit ----------------------Se1/0 HDLC

Dest address ----------172.2.0.1

VC ID Status ---------- ---------10 UP

PE1#show mpls l2transport vc 10 detail Local interface: Se1/0 up, line protocol up, HDLC up Destination address: 172.2.0.1, VC ID: 10, VC status: up Next hop: point2point Output interface: Se1/3, imposed label stack {20 16} Create time: 02:27:28, last status change time: 02:23:28 Signaling protocol: LDP, peer 172.2.0.1:0 up MPLS VC labels: local 16, remote 16 Group ID: local 0, remote 0 MTU: local 1500, remote 1500 Remote interface description: Sequencing: receive disabled, send disabled VC statistics: packet totals: receive 1015, send 1021 byte totals: receive 66978, send 68288 packet drops: receive 0, send 0

Com o próximo comando, verificamos o rótulo local e o rótulo remoto, assim como constatamos o VC type – nesse caso, HDLC.


29/10/2012 14:57:40

128 Redes MPLS PE1#show mpls l2transport binding Destination Address: 172.2.0.1, VC ID: 10 Local Label: 16 Cbit: 1, VC Type: HDLC, GroupID: 0 MTU: 1500, Interface Desc: n/a Remote Label: 16 Cbit: 1, VC Type: HDLC, GroupID: 0 MTU: 1500, Interface Desc: n/a

Vejamos agora a configuração do serviço PseudoWire para transmissão do Frame Relay sobre o MPLS utilizando a conexão do tipo “dlci-to-dlci”. Frame Relay sobre MPLS encapsula unidades de dado do protocolo Frame Relay (PDU) em pacotes MPLS e os encaminha através da rede MPLS. É possível estabelecer conexões “dlci-to-dlci” ou “port-to-port”. Na modalidade “port-to-port”, todas as conexões virtuais de uma determinada porta serão transportadas para o destino de forma transparente. Já na modalidade “dlci-to-dlci”, as conexões virtuais de uma determinada porta serão transportadas individualmente para o destino de forma transparente (Lobo, 2008). A principal diferença entre o modo “dlci-to-dlci” e “port-to-port” é o dispositivo no qual o LMI (Local Management Interface) irá executar. No modo “port-to-port”, os roteadores CEs executam o LMI entre eles, e os roteadores PE não participam do LMI. No modo “port-to-port” os roteadores PEs usam o HDLC como um modo de transporte na interface com o roteador CE. No modo “dlci-to-dlci” os roteadores PEs participam ativamente executando o LMI; dessa forma, o LMI é executado entre os roteadores PE e CE. Apresentamos na Figura 8.7 as configurações inseridas nos roteadores de backbone, assim como as configurações dos clientes para esta implementação. Em seguida, mostraremos as verificações através de comandos de visualizações relativas ao serviço.

Configurações do PseudoWire para o transporte Frame Relay sobre MPLS Para o modo que iremos usar nessa simulação (“dlci-to-dlci”), será necessário utilizar os seguintes comandos adicionais nos roteadores PEs: •• Frame Relay switching – Habilita a comutação de circuito virtual permanente (PVC) em um dispositivo Frame Relay.


29/10/2012 14:57:40


Figura 8.7 – Configurações do PseudoWire para o transporte Frame Relay sobre MPLS

•• Frame Relay intf-type dce – Especifica que a interface é um switch DCE. •• connect connection-name interface dlci l2transport – Define as conexões entre PVCs do Frame Relay. Através da palavra-chave l2transport, define-se que o PVC não será do tipo comutado, e sim encapsulado sobre a rede do backbone.

Verificações do PseudoWire para transporte do Frame Relay sobre MPLS Com os dois comandos logo a seguir, verificamos que o PseudoWire está funcional para transporte de Frame Relay sobre MPLS, mostrando o estado do PseudoWire.


29/10/2012 14:57:40

130 Redes MPLS PE1#show mpls l2 transport vc Local intf Local circuit --------------------------Se1/0 FR DLCI 30

Dest address ----------172.2.0.1

VC ID Status ---------- ---------100 UP

PE1#show mpls l2transport vc 100 detail Local interface: Se1/0 up, line protocol up, FR DLCI 30 up Destination address: 172.2.0.1, VC ID: 100, VC status: up Next hop: point2point Output interface: Se1/2, imposed label stack {20 23} Create time: 00:42:48, last status change time: 00:41:24 Signaling protocol: LDP, peer 172.2.0.1:0 up MPLS VC labels: local 24, remote 23 Group ID: local 0, remote 0 MTU: local 1500, remote 1500 Remote interface description: connected to CE22 Sequencing: receive disabled, send disabled VC statistics: packet totals: receive 51, send 55 byte totals: receive 15202, send 16296 packet drops: receive 0, send 0

Com o próximo comando, verificamos o label local e o label remoto, assim como constatamos o VC type – neste caso, Frame Relay dlci mode. PE1#show mpls l2transport binding Destination Address: 172.2.0.1, VC ID: 100 Local Label: 24 Cbit: 1, VC Type: FR DLCI, GroupID: MTU: 1500, Interface Desc: connected to Remote Label: 23 Cbit: 1, VC Type: FR DLCI, GroupID: MTU: 1500, Interface Desc: connected to

0 CE11 0 CE22

Os comandos a seguir também são de grande utilidade para verificação, pois mostram os dois segmentos existentes. O segmento 1, que é o circuito conectado a serial1/0, com DLCI 30. O segmento 2, que é a conexão remota do PseudoWire, no PE2. PE1#show connection all ID Name Segment 1 Segment 2 ======================================================= 2 FR Serial1/0 30 172.2.0.1 100

State UP

PE1#show connection id 2 FR/Pseudo-Wire Connection: 2 - FR Status - UP Segment 1 - Serial1/0 DLCI 30


29/10/2012 14:57:40


Segment status: UP Line status: UP PVC status: ACTIVE NNI PVC status: ACTIVE Segment 2 - 172.2.0.1 100 Segment status: UP Requested AC state: UP PVC status: ACTIVE NNI PVC status: ACTIVE

Verificações do PseudoWire para transporte do Frame Relay sobre MPLS Com os dois comandos a seguir, verificamos que o PseudoWire está funcional para transporte de Frame Relay sobre MPLS, mostrando o estado do PseudoWire. PE1#show mpls l2 transport vc Local intf Local circuit -------------------------Se1/0 FR DLCI 30

Dest address ----------172.2.0.1

VC ID Status ---------- ---------100 UP

PE1#show mpls l2transport vc 100 detail Local interface: Se1/0 up, line protocol up, FR DLCI 30 up Destination address: 172.2.0.1, VC ID: 100, VC status: up Next hop: point2point Output interface: Se1/2, imposed label stack {20 23} Create time: 00:42:48, last status change time: 00:41:24 Signaling protocol: LDP, peer 172.2.0.1:0 up MPLS VC labels: local 24, remote 23 Group ID: local 0, remote 0 MTU: local 1500, remote 1500 Remote interface description: connected to CE22 Sequencing: receive disabled, send disabled VC statistics: packet totals: receive 51, send 55 byte totals: receive 15202, send 16296 packet drops: receive 0, send 0

Com o comando adiante, verificamos o rótulo local e o rótulo remoto, assim como constatamos o VC type, nesse caso, Frame Relay dlci mode. PE1#show mpls l2transport binding Destination Address: 172.2.0.1, VC ID: 100 Local Label: 24 Cbit: 1, VC Type: FR DLCI, GroupID: MTU: 1500, Interface Desc: connected to Remote Label: 23 Cbit: 1, VC Type: FR DLCI, GroupID: MTU: 1500, Interface Desc: connected to


0 CE11 0 CE22

29/10/2012 14:57:40

132 Redes MPLS

Os comandos a seguir também são de grande utilidade para verificação, pois mostram os dois segmentos existentes. O segmento 1, que é o circuito conectado a serial1/0, com DLCI 30. O segmento 2, que é a conexão remota do PseudoWire; no PE2. PE1#show connection all ID Name Segment 1 Segment 2 ======================================================= 2 FR Serial1/0 30 172.2.0.1 100

State UP

PE1#show connection id 2 FR/Pseudo-Wire Connection: 2 - FR Status - UP Segment 1 - Serial1/0 DLCI 30 Segment status: UP Line status: UP PVC status: ACTIVE NNI PVC status: ACTIVE Segment 2 - 172.2.0.1 100 Segment status: UP Requested AC state: UP PVC status: ACTIVE NNI PVC status: ACTIVE

Testes de conectividade Para os testes de conectividade, foram utilizados os comandos ping e traceroute, desde o cliente CE11 até o cliente CE22, comprovando assim a conectividade ponto-a-ponto entre os clientes, trafegando como se de fato fossem conectados diretamente. CE11#ping 150.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 150.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 568/905/1040 ms CE11#traceroute 150.1.1.2 Type escape sequence to abort. Tracing the route to 150.1.1.2 1 150.1.1.2 860 msec 448 msec 732 msec


29/10/2012 14:57:40


Como pode-se observar através da demonstração, o serviço PseudoWire MPLS cria um “falso fio”, dessa forma criando uma conexão lógica e permitindo o transporte de diversas tecnologias sobre o backbone MPLS. Nesta simulação, podemos perceber a funcionalidade do PseudoWire através do transporte dos protocolos HDLC e Frame Relay, porém, como já citado, tal serviço poderá ser utilizado para transporte de quaisquer tecnologias sobre o backbone MPLS. Através dos testes de conectividade observamos que, de fato, tudo se passa como se os clientes tivessem uma conexão direta, sem quaisquer elementos intermediários. Com o uso do PseudoWire também é possível mantermos tecnologias diferentes no backbone simultaneamente, sendo um fator de extrema importância para migração dos serviços para o backbone do MPLS.

8.4.5 – MPLS VPN Com o uso da tecnologia MPLS, as VPNs oferecem grandes benefícios, fazendo com que a rede seja mais segura e tenha maior agilidade no tráfego, permitindo também a integração de qualquer tipo de rede, planos de endereçamentos e roteamento. As VPNs fazem uso do conceito de Roteador Virtual, o que reduz significativamente a necessidade de equipamento para cada enlace do usuário na operadora. As VPNs constituem um dos principais serviços oferecidos aos clientes para interligação das suas redes locais, provendo uma rede de transporte com segurança, confiança, comportamento previsível e menor custo. Os rótulos do MPLS podem ser usados para isolar o tráfego entre as VPNs. Todas as VPNs dos clientes compartilham o mesmo meio físico que compõe o núcleo da rede. Os dados de cada VPN são isolados entre si, e, também, todo o núcleo é oculto/isolado para as VPNs. Isto significa que usuários de uma VPN não têm acesso e desconhecem as outras VPNs e o núcleo da rede, conforme Figura 8.8.


29/10/2012 14:57:40

134 Redes MPLS

Figura 8.8 – Isolamento do tráfego através da VPN em um backbone representativo

Para esta simulação, configuraremos duas VPNs, VPN_A e VPN_B, para simular o acesso de dois diferentes clientes ao backbone MPLS, visualizando assim o isolamento do tráfego entre eles. A relação entre clientes, VRFs e roteadores pode ser vista na Tabela 8.1. Faremos uso de dois processos de roteamento entre os roteadores dos clientes (CEs) e o roteador de borda do provedor (PE), pois o processo de roteamento pode variar de cliente para cliente. Utilizamos primeiramente o processo de roteamento estático e em seguida utilizamos o roteamento dinâmico, com o uso do protocolo BGP. Tabela 8.1 – Relação entre os clientes, VRFs e roteadores

Cliente A B

VRF VPN_A VPN_B

Roteadores CE11, CE13 e CE22 CE12 e CE21

Configurações Seguem os passos para configuração da VRF dos roteadores PEs.


29/10/2012 14:57:41


Configurar instância VRF Configurar o router distinguisher Definir import e export de rotas Associar a VRF para uma interface

Router(config)#ip vrf vrf-name Router(config-vrf)#rd route-distinguisher

Router(config-vrf)#router router-target-ext-community

target

{import|export|both}

Router(config-if)#ip vrf forwarding vrf-name

Passo 1: configurar a VRF nos roteadores PEs para cada VPN conectada. Como exemplo para o roteador PE1: ip vrf VPN_A ip vrf VPN_B

Passo 2: configurar o RD nos roteadores PE. Como exemplo para o roteador PE1: rd 65500:1 rd 65500:2

Passo 3: configurar o RT para importação e exportação das comunidades estendidas MP-BGP nos roteadores PEs. Como exemplo para o roteador PE1: route-target both 65500:1 route-target both 65500:2

Passo 4: associar a VRF para a interface específica. Como exemplo para as interfaces do PE1: interface serial1/0 ip vrf forwarding VPN_A


29/10/2012 14:57:41

136 Redes MPLS interface serial 2/0 ip vrf forwarding VPN_A

interface serial1/1 ip vrf forwarding VPN_B

Observação: as configurações completas das VRFs nos roteadores PE1 e PE2 encontram-se no Apêndice C deste livro.

É necessário também configurar o BGP entre os PEs, com o propósito de garantir que as rotas VPNv4 possam ser transportadas através do backbone usando MP-iBGP. Para o roteador P, esse processo é transparente, pois ele não transporta nenhuma rota de clientes. Seguem os passos para configuração do BGP: Router(config)#router bgp as-number

Configurar processo BGP Configurar o vizinho VPNv4 BGP Configurar o BGP VPNv4 address family

Router(config-router)#neighbor {ip address | peer-groupname} remote-as as-number Router(config-router)#neighbor {ip address | peer-groupname} update-source interface-type interface-number Router(config-router)#address-family vpnv4 [unicast] Router(config-router-af)#neighbor {ip-address | peergroup-name} activate Router(config-router-af)#neighbor {ip-address | peergroup-name} send-community [extended | both]

Os dois primeiros passos já foram efetuados durante a demonstração das configurações básicas do MPLS. O Passo 3 permite que seja configurado o “VPNv4 address family” para ativar os vizinhos VPNv4. Esse passo é essencial para o transporte de prefixos VPNv4 através do backbone do provedor de serviços. Segue exemplo para o roteador PE1:


29/10/2012 14:57:41


hostname PE1 router bgp 65500 address-family vpnv4 neighbor 172.2.0.1 activate neighbor 172.2.0.1 send-community extended neighbor 172.2.0.1 next-hop-self

Observação: o comando next-hop-self é utilizado quando o provedor tem um roteamento eBGP com o cliente, porque a sessão internal BGP (iBGP) preserva o atributo next-hop aprendido do par eBGP. Nesse caso, se o “next-hop-self” não for utilizado, a rota BGP ficará inalcançável.

É necessário também configurar o par VRF IPv4 address family dentro do processo BGP. Isso irá permitir que as redes IPv4 sejam convertidas em rotas VPNv4 nas atualizações do MP-BGP. Neste caso, redistribuímos as rotas diretamente conectadas, mas a redistribuição irá depender do processo de roteamento utilizado, conforme exibiremos mais adiante. Segue exemplo para o PE1: hostname PE1 address-family ipv4 vrf redistribute connected exit-address-family address-family ipv4 vrf redistribute connected exit-address-family

VPN_A

VPN_B

As configurações nos roteadores Ps já foram feitas também na demonstração das configurações básicas do MPLS e consistem em habilitar o MPLS nas interfaces e configurar o processo de roteamento IS-IS.

Roteamento estático entre CE e PE Após configurações da VRF e do MP-BGP, iremos simular um ambiente usando o processo de roteamento estático entre o cliente e o provedor (CE – PE). As configurações de todos os CEs, assim como as configurações que foram acrescentadas nos PEs com as devidas rotas estáticas para as VRFs, encontram-se no Apêndice C deste livro.


29/10/2012 14:57:41

138 Redes MPLS

Configurações com roteamento BGP entre CE e PE Trocaremos o processo de roteamento para uso do BGP entre os clientes e o provedor e em seguida também faremos verificações e testes de conectividade. Utilizamos o AS 100 para os roteadores pertencentes à VPN_A e o AS 200 para os roteadores pertencentes à VPN_B. Do ponto de vista do provedor de serviço, o BGP usado entre os roteadores CE e PE é o protocolo preferido, pois oferece várias vantagens, tais como: •• A redução do overhead, a manutenção do roteador PE e as configurações são simplificadas. •• A redistribuição entre protocolos de roteamento não é necessária se as rotas são aprendidas por meio do BGP.

Observação: as configurações do BGP para os CEs e os PEs se encontram no Apêndice C.

Verificações Podemos visualizar as configurações das VRFs com os comandos a seguir, executados no roteador PE1: PE1#show ip vrf Name VPN_A VPN_B PE1#show ip vrf interfaces Interface IP-Address Se1/0 150.1.1.1 Se2/0 150.1.1.9 Se1/1 150.1.1.5


Default RD 65500:1 65500:2

VRF VPN_A VPN_A VPN_B

Interfaces Se1/0 Se2/0 Se1/1

Protocol up up up

29/10/2012 14:57:41


Vejamos a tabela de roteamento global do PE1: PE1#show ip route C i L2 i L2 i L2 C i L2 i L2 C i L2

172.1.0.0/32 is subnetted, 1 subnets 172.1.0.1 is directly connected, Loopback0 172.2.0.0/32 is subnetted, 1 subnets 172.2.0.1 [115/30] via 192.168.0.18, Serial1/3 172.10.0.0/32 is subnetted, 1 subnets 172.10.0.1 [115/20] via 192.168.0.14, Serial1/2 172.20.0.0/32 is subnetted, 1 subnets 172.20.0.1 [115/20] via 192.168.0.18, Serial1/3 192.168.0.0/30 is subnetted, 5 subnets 192.168.0.12 is directly connected, Serial1/2 192.168.0.24 [115/20] via 192.168.0.18, Serial1/3 192.168.0.28 [115/20] via 192.168.0.18, Serial1/3 [115/20] via 192.168.0.14, Serial1/2 192.168.0.16 is directly connected, Serial1/3 192.168.0.20 [115/20] via 192.168.0.14, Serial1/2

* Podemos perceber que não são mostradas as rotas de clientes na tabela global. Para visualizarmos as rotas dos clientes efetuamos os comandos a seguir. Nesse caso, as tabelas mostram os testes com o uso do processo de roteamento estático: PE1#show ip route vrf VPN_A S S B B C C

200.1.0.0/32 200.1.0.1 200.1.0.3 200.2.0.0/32 200.2.0.2 150.1.0.0/30 150.1.2.4 150.1.1.0 150.1.1.8

is subnetted, 2 subnets [1/0] via 150.1.1.2 [1/0] via 150.1.1.10 is subnetted, 1 subnets [200/0] via 172.2.0.1, 00:36:28 is subnetted, 3 subnets [200/0] via 172.2.0.1, 01:08:31 is directly connected, Serial1/0 is directly connected, Serial2/0

Podemos perceber que as tabelas de roteamento só exibem rotas específicas para a VPN em questão, o que garante o isolamento total de tráfego entre os clientes. Vejamos as mesmas tabelas de rotas, agora com o protocolo de roteamento BGP configurado entre os PEs e os CEs.


29/10/2012 14:57:41

140 Redes MPLS PE1#show ip route vrf B B B B C C

200.1.0.0/32 200.1.0.1 200.1.0.3 200.2.0.0/32 200.2.0.2 150.1.0.0/30 150.1.2.4 150.1.1.0 150.1.1.8

is subnetted, 2 subnets [20/0] via 150.1.1.2, 00:28:00 [20/0] via 150.1.1.10, 00:45:16 is subnetted, 1 subnets [200/0] via 172.2.0.1, 00:39:46 is subnetted, 3 subnets [200/0] via 172.2.0.1, 00:39:46 is directly connected, Serial1/0 is directly connected, Serial2/0

PE1#show ip route vrf B B C B PE1#

200.1.0.0/32 200.1.0.2 200.2.0.0/32 200.2.0.1 150.1.0.0/30 150.1.1.4 150.1.2.0

VPN_A

VPN_B

is subnetted, 1 subnets [20/0] via 150.1.1.6, 00:47:14 is subnetted, 1 subnets [200/0] via 172.2.0.1, 00:16:48 is subnetted, 2 subnets is directly connected, Serial1/1 [200/0] via 172.2.0.1, 00:16:48

Podemos novamente perceber a independência nas tabelas de roteamento, ou seja, cada VPN possui sua tabela independente, sem recebimento de quaisquer prefixos provenientes de outras VPNs. Outros comandos de visualização podem ser encontrados no Apêndice C desta obra.

Testes de conectividade A seguir, mostraremos os testes de conectividade após todas as configurações das VPNs, tanto para o processo de roteamento estático quanto para o processo de roteamento dinâmico entre o CE e o PE.

Para o processo estático Para os testes de conectividade iremos usar o comando “ping” e comprovar que não há conectividade entre clientes pertencentes às VPNs diferentes. Primeiro, vamos efetuar um “ping” entre os clientes participantes da VPN_A, conforme segue:


29/10/2012 14:57:41


CE11#ping 200.1.0.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 200.1.0.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 88/124/172 ms CE11#ping 200.2.0.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 200.2.0.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 100/214/308 ms

Podemos notar que há conectividade entre CE11, CE13 e CE22, pois eles pertencem à mesma VPN. Vamos tentar conectividade agora entre dispositivos pertencentes a diferentes VPNs: CE11#ping 200.1.0.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 200.1.0.2, timeout is 2 seconds: U.U.U Success rate is 0 percent (0/5) CE11#ping 200.2.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 200.2.0.1, timeout is 2 seconds: U.U.U Success rate is 0 percent (0/5)

Assim, podemos comprovar que não há conectividade entre clientes pertencentes a diferentes VPNs. É importante observar que, em qualquer teste de conectividade partindo do PE, é necessário especificar a qual VRF o endereço destino pertence, já que as tabelas de roteamento são diferentes para cada VRF e diferentes da tabela de roteamento global, conforme o exemplo: PE1#ping 200.1.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 200.1.0.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) PE1#ping vrf VPN_A 200.1.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 200.1.0.1, timeout is 2 seconds: !!!!!


29/10/2012 14:57:41

142 Redes MPLS

Para o processo dinâmico, usando o protocolo BGP Novamente foram efetuados testes de conectividade entre mesmas e diferentes VPNs. CE11#ping 200.1.0.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 200.1.0.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 96/287/548 ms

CE11#ping 200.2.0.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 200.2.0.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 284/481/756 ms CE11#

CE11#ping 200.1.0.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 200.1.0.2, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) CE11#

Mais uma vez pode-se constatar o isolamento do tráfego, já que não há conectividade entre clientes participantes de diferentes VPNs.

Cenário Hub and Spoke Uma das grandes vantagens do uso das VPNs MPLS no backbone, além do isolamento de tráfego entre clientes, é a facilidade de manipulação para distribuição de rotas, ou seja, apenas fazendo alterações nos atributos RD e RT podemos negar ou permitir acesso a determinados pontos. Como exemplo, iremos retomar a topologia da Figura 8.8 e fazer uma conexão do tipo Hub and Spoke, bastante difundida quando utilizada a tecnologia Frame Relay. No cenário anterior, fazendo uso de rotas estáticas ou fazendo uso do protocolo BGP, percebemos que todos os roteadores da VPN_A se falavam diretamente, sem a necessidade de um ponto concentrador, o que garante otimização, pois o cliente já recebe uma rede Full Mesh. Vejamos como ficaria a conexão Hub and Spoke na Figura 8.9:


29/10/2012 14:57:41


Figura 8.9 – Topologia Hub and Spoke

Através dos testes anteriormente realizados, podemos notar que todos os clientes conectados na mesma VPN possuem conectividade entre si. A partir do CE11, foi possível atingir o CE13 e CE22, pois ambos pertencem à VPN_A. A ideia, neste caso, é fazer com que os clientes CE13 e CE22 (Spokes) tenham conectividade apenas com o CE11 (Hub), e não entre si. Assim, para facilidade da demonstração, criamos duas VRFs no PE1 (HUB e SPOKE13) e uma VRF no PE2 (SPOKE22). As rotas do HUB são exportadas e importadas pelos SPOKES através do RD 65500:1; já as rotas dos SPOKES são exportadas através do RD 65500:2 e importadas apenas pelo HUB. Não há importação de rotas entre os SPOKES, pois eles só importam a rota que é exportada do HUB. Observamos agora que o CE22 só possui em sua tabela de roteamento rotas provenientes do CE11 (HUB); portanto, não há conectividade entre os SPOKES. CE22#show ip route B C C B

200.1.0.0/32 200.1.0.1 200.2.0.0/32 200.2.0.2 150.1.0.0/30 150.1.2.4 150.1.1.0

is subnetted, 1 subnets [20/0] via 150.1.2.5, 00:31:11 is subnetted, 1 subnets is directly connected, Loopback0 is subnetted, 2 subnets is directly connected, Serial1/0 [20/0] via 150.1.2.5, 00:31:11

CE22#ping 200.1.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 200.1.0.1, timeout is 2 seconds:


29/10/2012 14:57:41

144 Redes MPLS !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 336/448/548 ms CE22#ping 200.1.0.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 200.1.0.3, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)

Ou seja, através de configurações simples dos atributos RD e RT, podemos fazer quaisquer manipulações de rotas entre as VRFs no backbone MPLS, tornando-o bastante flexível e garantindo otimização. Tal implementação é conhecida como VPN complexa.

Observação: as configurações dos roteadores PE1 e PE2, para essa simulação, se encontram no Apêndice C.

A VPN MPLS é a implementação mais popular da tecnologia MPLS. O seu crescimento tem ocorrido de forma exponencial desde a sua criação (De Ghein, 2007). Na simulação aqui apresentada, podemos observar o isolamento do tráfego através da criação das VPNs, fazendo uso de dois processos de roteamento: estático e dinâmico. Para o processo dinâmico, foi utilizado o protocolo BGP, embora outros protocolos, tais como RIP, OSPF e IS-IS, pudessem ser utilizados. Também pode-se observar que, por padrão, a conectividade entre os pontos pertencentes à mesma VPN é completa (Full Mesh), o que facilita a integração das redes, já que a interligação de roteadores através de uma rede Frame Relay ou ATM requer a configuração de vários circuitos virtuais, no pior caso N(N-1)/2 circuitos virtuais, onde N é o número de roteadores. Portanto, usando roteadores previamente preparados com MPLS, é possível integrar ambas as tecnologias: o isolamento oferecido pelos Switches ATM ou Frame Relay e as flexibilidades oferecidas pelos roteadores LSR (Label Switch Routers), fazendo o encaminhamento baseado em rótulos. Neste teste mostramos a capacidade de separação de endereçamento e roteamento, independentemente do processo de roteamento utilizado entre o CE e o PE. No primeiro “ping” tentamos conectar, a partir do CE11, ao CE13 e CE22;


29/10/2012 14:57:41


nesse caso todos os objetivos foram alcançados, o que comprova a conectividade Full Mesh na mesma VPN – no caso, VPN_A. Quando o “ping” foi gerado, a partir do CE11, para o CE12 e CE21, percebemos que não havia conectividade, nos certificando de que os planos de endereços estão completamente isolados, já que pertencem a diferentes VPNs. Utilizamos também, em nossa simulação, uma topologia Hub and Spoke para exibir a facilidade de manipulação de rotas no backbone, o que garante flexibilidade e otimização. Neste caso, notamos que, com pequenas alterações nas configurações, mais precisamente alterando os parâmetros de RD e RT, podemos efetuar manipulações de forma a permitir ou negar conexão entre clientes, garantindo uma boa flexibilidade.

8.4.6 – QoS no MPLS Os mecanismos de QoS usados no interior de um backbone servem exclusivamente para garantir o SLA (Service Level Agreement) contratado no momento em que o backbone estiver congestionado. SLAs, ou níveis de acordo de serviços, são contratos para prestação de serviços com garantia, geralmente feitos entre o prestador de serviços e o cliente, definindo os requisitos do cliente e as penalidades para os fornecedores em caso de não cumprimento do acordo (Blake et al, 2007). Nesta simulação faremos o controle de admissão do tráfego no backbone MPLS de um cliente com base nas classes de serviços criadas. Iremos fazer a classificação e marcação dos pacotes nos roteadores CEs, conforme topologia da Figura 8.10, e analisar todo o percurso e tratamento dos pacotes dentro do backbone, até a sua entrega no CE de destino, fazendo um controle de admissão do tráfego na entrada do backbone através de um mecanismo de policiamento e verificando a conformidade ou não do tráfego do cliente. Faremos a marcação em DSCP nos CEs e no backbone faremos a marcação em EXP nos PEs, sendo esta última efetuada através do mecanismo de policiamento. Os tráfegos analisados de forma simulada e as marcações utilizadas na simulação do ambiente QoS seguem na Tabela 8.2:


29/10/2012 14:57:42

146 Redes MPLS Tabela 8.2 – Classes utilizadas na simulação do ambiente QoS

Classe

Perfil do tráfego

Marcação em DSCP

Marcação em EXP

Limite de banda

Premium

Mínima garantia de banda, baixo delay, baixo jitter e sem perda de pacotes.

EF

EXP 5 – Dentro do perfil. Descarte – Fora do perfil.

128 Kbps

Business

Mínima garantia de banda e baixa perda de pacotes.

AF21, AF22 ou AF23

EXP 2 – Dentro do perfil. EXP 1 – Fora do perfil.

512 Kbps

Best-Effort

Nenhuma garantia.

0

Figura 8.10 – Porção da topologia representativa para demonstração do QoS

Configurações A configuração nos roteadores será feita via MQC (Modular QoS Command Line Interface) (Davidson et.al, 2007), que implementa uma arquitetura simples para configurar QoS de acordo com os seguintes critérios: •• Classificação dos pacotes usando class map; •• Definir a política de QoS para ser aplicada por classe, usando Policy Map; •• Atribuir uma política de serviços de QoS por interface.


29/10/2012 14:57:42


Segue o passo a passo:

Ou seja, o processo consiste basicamente em separar o tráfego em classes, definir ações (políticas) a essas classes e aplicar estas ações às interfaces físicas ou lógicas. Para classificar pacotes IPs utilizando uma class map, os comandos a seguir podem ser utilizados. Vale salientar que as opções disponíveis no roteador podem variar, dependendo do tipo de chassi do equipamento e da versão do IOS: Definir a classe

Definir critério utilizado para associar os pacotes às classes

Router(config)#class-map {match-all | match-any} name Router(config-cmap)#match any Router(config-cmap)#match [not] access-group {access-list-number | Name access-list-name} Router(config-cmap)#match [not] cos cos-value-1 [cosvalue-2] [cos-value-3] [cos-value-4] Router(config-cmap)#match [not] atm clp Router(config-cmap)#match [not] dscp dscp-value-1 [dscpvalue-2] [dscp-value-3] [dscp-value-4] Router(config-cmap)#match [not] ip {dscp | precedence} {dscp-value-1 | IP precedence-value-1} [dscp-value-2 | IP precedence-value-2} [dscp-value-3 | IP precedence-value-3} {dscp-value-4 | IP precedence-value-4} Router(config-cmap)#match [not] mpls experimental MPLS-expvalue-1 [MPLS-exp-value-2] [MPLS-exp-value-3] [MPLS-expvalue-4] [MPLS-exp-value-5] [MPLS-exp-value-6] [MPLS-expvalue-7] [MPLS-exp-value-8] Router(config-cmap)#match [not] protocol protocol-identifier-name Router(config-cmap)#match [not] qos-group qos-group-value Router(config-cmap)#match [not] vlan vlan-id

Para definir a política de QoS para ser aplicada por classe, seguem os comandos. Tais opções também podem variar de acordo com a versão do IOS.


29/10/2012 14:57:42

148 Redes MPLS Router(config)#policy-map policy-map-name

Defina a política

Router(config-pmap)#class class-map-name

Configure os parâmetros de QoS por classes

Configure garantia de banda por classe

Router(config-pmap-c)#bandwidth {bandwidth-in-kbps | percent percentage-of-total-bandwidth | remaining percentage-of-remaining-bandwidth]

Router(config-pmap-c)#priority

Configure prioridade estrita para uma classe

Defina a marcação do pacote

Configure WRED


Router(config-pmap-c)#set {dscp dscp-value | IP dscp dscp-value | IP precedence precedence-value | precedence precedence-value | atm-clp | cos cos-value | discard-class discar-class-value | fr-de | qos-group qos-group value | MPLS experimental {exp-value | imposition exp-value | topmost exp-value}]

Router(config-pmap-c)#random-detect {prec-based |dscp-based} Router(config-pmap-c)#random-detect precedence precedence-value min-threshold {cells | milliseconds | packets | microseconds] mark-probability-denominator Router(config-pmap-c)#random-detect dscp dscp-value min-threshold [cells | milliseconds | packets | microseconds] mark-probability-denominator

29/10/2012 14:57:42


Configure policiamento (policing)

Configure moldagem (shaping)

Router(config-pmap-c)#police {cir cir} [bc conform-burst] {pir pir} [be peak-burst] [conform-action action [exceed-action action [violate-action action]] OR Router(config-pmap-c)#police bps [burst-normal] [burst-max] conform-action action exceed-action action [violate-action action] OR Router(config-pmap-c)#police cir percent percent [bc conform-burst-in-msec] [pir-percent percent] [bc peak-burst-in-msec] Router(config-pmap-c)#shape {average | peak} cir [bc] [be] OR Router(config-pmap-c)#shape {average | peak} percent percent [bc] [be] OR Router(config-pmap-c)#shape {average | peak} mean-rate [[burst-size] [excess-burst-size]]

Para aplicar a política criada na interface, segue: Associar a política para uma interface

Router(config)#interface interface-type number Router(config-if)#service-policy {in | out} policy-map-name

Como a qualidade de serviço deve ser feita fim-a-fim, configuramos as políticas desde a entrada no roteador PE1 até a saída do PE2, e as marcações serão efetuadas nos CEs. Tais políticas serão feitas nos dois sentidos, porém mostraremos passo a passo para o tráfego na direção CE11 à PE1 à P1 à P2 à PE2 e CE22. Políticas adotadas: •• Entrada do PE1: conforme Tabela 8.2, foram criadas duas classes de serviços, uma delas para limitar em 512 Kbps o tráfego marcado com AF21, AF22 ou AF23. O tráfego em conformidade deve ser transmitido e remarcado com EXP 2. O tráfego acima do perfil definido deve ser transmitido e remarcado com EXP1. A segunda classe, para limitar em 128 Kbps o tráfego marcado como EF. O tráfego em conformidade deve ser transmitido e remarcado com EXP5. O tráfego acima do perfil definido deve ser descartado. •• Saída do PE1: esta política garante, no mínimo, 5% da banda do enlace para o tráfego premium e, no mínimo, 50% para o tráfego business. Em


29/10/2012 14:57:42

150 Redes MPLS

caso de congestionamento, o tráfego de melhor esforço deve experimentar descarte aleatório. •• Saída do P1: o roteador P1 não precisa de uma política de entrada porque os pacotes já foram marcados no roteador PE1. A política de saída do P1 é similar à política de saída do roteador PE1. •• Saída do P2: o roteador P2 também não irá precisar de uma política de entrada porque os pacotes já foram marcados no roteador PE1. A política de saída do P2 é similar à política de saída do roteador P1. •• Saída do PE2: no PE2, os pacotes voltam a ser IPs puros devido à retirada do rótulo MPLS; consequentemente, a política a ser implementada nesta tarefa deve estar atuando nos pacotes IPs puros. Configuramos, neste caso, uma política de saída do PE2 para o CE22 com garantia mínima de 50% do enlace para a classe premium e 25% para a classe business. A classe de melhor esforço terá descarte aleatório em caso de congestionamento.

Observação: todas as configurações podem ser visualizadas no Apêndice D deste livro.

Verificações e testes Todos os comandos de testes e visualizações desta parte foram definidos no Apêndice D. A qualidade de serviço na rede MPLS é também um grande atrativo que esta tecnologia provê (Colcher et al, 2005), permitindo aprimorar a qualidade no serviço prestado e realizar um controle mais efetivo do tráfego para os clientes. Com a qualidade de serviços no backbone, é possível o uso de serviços tais como videoconferência, voz sobre IP, dados e multimídia, por exemplo, em uma base única, sendo transmitidos como pacotes de dados e sendo possível tratar as aplicações de forma diferente, priorizando o tráfego crítico de clientes e aplicações sensíveis a retardo. Com o MPLS é possível termos um QoS fim-a-fim, garantindo o nível de SLA acordado com o cliente, o que podemos comprovar através da simulação realizada. Nesta simulação, efetuamos o controle de admissão de tráfego no ingresso ao backbone através do mecanismo de policiamento, sendo uma facilidade que permite que o nível de tráfego acordado com um determinado cliente seja


29/10/2012 14:57:43


respeitado, isto é, se o tráfego do usuário ultrapassar um determinado limite, o conteúdo será descartado ou poderá sofrer algum outro tipo de penalidade definido pelo provedor de serviços. Fizemos a configuração de um QoS fim–a-fim, partindo do cliente CE11 até o cliente CE22, fazendo o controle de admissão na entrada do PE1, marcando os pacotes da saída através do mecanismo de policiamento e fazendo as tratativas PHB ao longo do backbone até a saída do PE2, podendo observar de fato o tratamento fim–a-fim do QoS IP, o que não é possível nas tecnologias legadas (ATM e Frame Relay). A implementação de QoS sobre o backbone MPLS proporciona diferentes níveis de serviços para diferentes tipos de tráfegos na rede, podendo classificar o tráfego de acordo com o tipo, a interface de entrada e outros fatores, sem alterar o valor original dos bits de precedência do cabeçalho IP – preservando assim as políticas internas de QoS dos clientes. Desse modo, o backbone torna-se mais modular e escalável, podendo dar um tratamento diferenciado para diferentes tráfegos e permitindo a implementação de diversos mecanismos de QoS que garantem a qualidade no tráfego dos clientes.

8.4.7 – Engenharia de tráfego com MPLS Para esta simulação, usamos a topologia da rede apresentada na Figura 8.11. São criados, a princípio, dois túneis (túnel 0 e túnel 1), com requerimento de banda de 100 Kbps, sendo o primeiro de forma dinâmica, no qual o IS-IS efetuará o cálculo CSPF (Constrained Shortest Path First) e irá identificar o LSP apropriado; e o segundo de forma explícita, no qual o caminho PE1 à P2 à PE2 será usado. Dessa forma, implementa-se um balanceamento de carga que será efetuado entre os dois caminhos, assim como a redundância no caso de um dos túneis se tornar inativo. Os roteadores definidos como head-end e tail-end são, respectivamente, o PE1 e o PE2. É possível desenvolver MPLS-TE em quaisquer redes que tenham LSRs. Entretanto, porque a banda e outros atributos dos enlaces precisam ser conhecidos pelo head-end LSR do LSP, o protocolo de roteamento usado entre os dois pontos extremos (os MPLS-TE endpoints head-end e tail-end LSR) tem que ser um protocolo de roteamento link state (De Ghein, 2007). Em nossa demonstração usaremos o protocolo IS-IS.


29/10/2012 14:57:43

152 Redes MPLS

Figura 8.11 – Porção da topologia representativa para demonstração do MPLS-TE

Em seguida criaremos o túnel 2, de forma explícita, no qual o caminho PE1 à P1 à P2 à PE2 será utilizado com requerimento de banda de 50 Kbps. Desta forma, faremos um balanceamento com custos desiguais entre os três túneis.

Configurações Supondo que a configuração básica do MPLS, assim como a configuração do protocolo IGP, já está efetuada, segue o passo a passo para configuração do MPLS-TE.


29/10/2012 14:57:43


Passo 1: configurar a interface para associação do túnel. Uma interface loopback é recomendável para usar como ID do roteador para engenharia de tráfego MPLS, pois ela está sempre ativa, não importando o estado das outras interfaces do roteador. Router(config)#interface Loopback {number} Router(config-if)#ip address {ip-address} {mask}

Passo 2: ativar TE globalmente e por interface. É necessário, além de configurar o MPLS TE globalmente, que seja habilitado em cada interface que possa alcançar um túnel TE. Router(config)#mpls traffic-eng tunnels Router(config))#interface {type} {number} Router(config-if)#ip address {ip address} {mask} Router(config-if)#mpls traffic-eng tunnels

Passo 3: definir parâmetros do RSVP nas interfaces usadas no TE. Configurar o RSVP bandwidth que será usado na interface para sinalização e alocação de recursos para sessões de engenharia de tráfego. Este comando pode utilizar dois parâmetros: o primeiro é a quantidade de largura de banda total reservada na interface e o segundo é a quantidade máxima de largura de banda que pode ser reservada por fluxo na interface, em Kbps. Este segundo parâmetro é irrelevante para o MPLS-TE. Router(config)#interface {type} {number} Router(config-if)#ip rsvp bandwidth {reservable bandwidth 1-10000000 kbps} {maximum reservable bandwidth per flow 1-10000000 kbps}

Passo 4: configurar parâmetros da interface túnel. O passo 4 trata das configurações dos parâmetros que serão utilizados pela interface túnel. Neste caso, se o caminho escolhido para o LSP é feito usando IGP e CSPF, a path option é escolhida para ser dynamic. Router(config)#interface Tunnel {number} Router(config-if)#ip unnumbered loopback {number} Router(config-if)#tunnel mode mpls traffic-eng Router(config-if)#tunnel destination {IP address of remote loopback} Router(config-if)#tunnel mpls traffic-eng path-option {priority}[dynamic [bandwidth {override bandwidth config value} | attributes {lsp attribute list name} | lockdown | explicit { identifier|name name]] Router(config-if)#tunnel mple traffic-eng bandwidth {number kbps} Router(config-if)#tunnel mpls traffic-eng priority {setup priority-value} {hold-priority value}


29/10/2012 14:57:43

154 Redes MPLS

Passo 5 (opcional): configurar o caminho explícito que será usado para o túnel. Conforme informado, esse passo é opcional e pode ser definido no headend, de forma que o túnel dinâmico possa ser escolhido para encaminhamento do tráfego, e um túnel explícito pode ser um caminho alternativo. Em alguns casos, o balanceamento de carga também poderá ser realizado entre os dois tipos. Router(config)#ip explicit-path name {name} enable or Router(config)#ip explicit-path identifier {number} enable Router(cfg-ip-expl-path)#next-address {ip-address} Router(cfg-ip-expl-path)#next-address {ip-address} Router(cfg-ip-expl-path)#next-address {ip-address} Router(cfg-ip-expl-path)#exit

Passo 6: anunciar a interface túnel para uso pelo IGP. Por padrão, a interface túnel não é anunciada no IGP para uso na tabela de roteamento, sendo necessária a sua configuração explicitamente para que possa ser usada como próximo salto na tabela de roteamento. Router(config)#interface tunnel {number} Router(config-if)#tunnel mpls traffic-eng autoroute announce

Passo 7: configurar o IGP para suporte ao MPLS-TE O passo final é a configuração do IGP para suporte a TE. O IGP, nesse caso, pode ser o OSPF ou IS-IS. Para OSPF: Router(config)#router ospf process-id Router(config-router)#network ip-address wild-card mask area area-id Router(config-router)#no auto-summary Router(config-router)#mpls traffic-eng area number Router(config-router)#mpls traffic-eng router-id interface number

Para IS-IS: Router(config)#router isis process-id Router(config-router)#net network-entity-tittle Router(config)#interface type number Router(config-if)#ip router isis process-id Router(configirouter)#mpls traffic-eng level [1 | 2] Router(config-router)#mpls traffic-eng router-id interface number Router(config-router)#metric-style wide


29/10/2012 14:57:43


As configurações básicas do IGP e do MPLS já foram efetuadas, portanto iremos exibir as configurações efetuadas com foco no MPLS-TE em todos os roteadores do backbone. Utilizamos 256 Kbps como máxima banda reservável e também como a máxima alocada por cada fluxo. Para a banda requerida pelo túnel 0 e túnel 1 definimos 100 Kbps, e para o túnel 2 definimos 50 Kbps. Observação: todas as configurações efetuadas nos roteadores e os testes realizados encontram-se no Apêndice E desta obra.

Análise gráfica Para uma melhor análise dos comandos efetuados nesta seção, através da ferramenta SNMP Traffic Grapher extraímos os gráficos nas saídas das interfaces serial1/2 e serial1/3, do PE1, e serial1/2, do P1, conforme podemos analisar na Figura 8.12. O tráfego foi gerado a partir da ferramenta TfGen. Para geração do tráfego e visualização dos gráficos, foi feita uma conexão lógica entre a placa de rede de uma estação real e a placa de rede virtual do roteador CE11, conforme Figura 8.12. Todo tráfego foi gerado com origem no PC (10.1.1.2) e destino a loopback0 do CE22 (200.2.0.2), fazendo o tráfego percorrer todo o backbone. As rotas necessárias para este teste também foram inseridas no roteador PE1.

Figura 8.12 – Conexão entre o PC e o CE11 para geração de tráfego e coleta dos gráficos


29/10/2012 14:57:44

156 Redes MPLS

Inicialmente foi feita uma análise sem a aplicação da engenharia de tráfego, onde percebemos que, como o protocolo de roteamento IS-IS escolhe o melhor caminho, os demais ficarão ociosos e apenas serão utilizados como redundância. Neste caso, o caminho utilizado pelo IS-IS do PE1 para o PE2 foi via P2, escolhido aleatoriamente por este protocolo em virtude dos caminhos PE1 à P1 à PE2 e PE1 à P2 à PE2 terem o mesmo custo. Neste caso, ocorreria um balanceamento, mas por sessão (o protocolo utiliza sempre o mesmo enlace após estabelecimento da sessão entre origem e destino), deixando os demais enlaces ociosos. A geração de tráfego para todos os testes desta seção foi feita conforme a Figura 8.13. Podemos visualizar os gráficos obtidos através das Figuras 8.14 e 8.15.

Figura 8.13 – Tráfego gerado do PC para o CE22

Figura 8.14 – Visualização do tráfego na saída da interface serial1/2 do PE1


29/10/2012 14:57:44



Pode-se observar que só há tráfego efetivo na interface serial1/3, pois o caminho escolhido pelo protocolo foi PE1 à P2 à PE2, deixando os demais caminhos ociosos – inclusive podendo ter perda de pacotes quando o tráfego excede o limite permitido pela interface. Após criação dos dois túneis iniciais para engenharia de tráfego (túnel 0 e túnel 1), conforme Figura 8.12, fizemos os mesmos testes e podemos perceber que, nesse caso, dois caminhos estão sendo utilizados. Um deles é o caminho PE1 à P1 à PE2, utilizado pelo túnel 0, e o outro é o caminho PE1 à P2 à PE2, utilizado pelo túnel 1. Há também um caminho ocioso, conforme podemos verificar no gráfico de saída da interface serial1/2 do P1, Figura 8.18, o que é completamente aceitável, pois os túneis definidos não fazem uso desse caminho. Podemos visualizar todos os gráficos nas Figuras 8.16, 8.17 e 8.18.



29/10/2012 14:57:44

158 Redes MPLS


Figura 8.18 – Visualização do tráfego na saída da interface serial1/2 do P1

Com a criação de um terceiro túnel (túnel 2), observamos que agora temos tráfego também através do caminho PE1 à P1 à P2 à PE2. Sendo assim, os três caminhos estão sendo utilizados, balanceando a carga no backbone e propiciando redundância, pois, caso um dos túneis venha a falhar, os demais assumem a carga normalmente, o que pode ser visto no Apêndice E. A menor utilização de recursos através do túnel 2 ocorre devido ao túnel ter sido criado com requerimento de banda menor, o que comprova que a distribuição de carga está sendo feita conforme definido pelo administrador. Os gráficos podem ser visualizados nas Figuras 8.19, 8.20 e 8.21.


29/10/2012 14:57:44




Figura 8.21 – Visualização do tráfego na saída da interface serial1/2 do P1


29/10/2012 14:57:45

160 Redes MPLS

A engenharia de tráfego habilita os ISPs a rotear o tráfego na rede para prover melhor serviço aos usuários, em termos de taxa de transferência (throughput) e atraso (delay). Tornando o provedor mais eficiente, a engenharia de tráfego reduz o custo na rede, tendo como grande vantagem o melhor aproveitamento dos enlaces. Nesta simulação, podemos observar que, através da criação de túneis unidirecionais dinâmicos e/ou explícitos, podemos distribuir o tráfego no backbone de forma a permitir o balanceamento de carga e redundância na rede. Inicialmente, criamos dois túneis (túnel 0 e túnel 1) e observamos o comportamento do roteamento no backbone. Vimos que o tráfego foi distribuído igualmente pelos dois caminhos utilizados, sendo um deles dinâmico e o outro explícito. Tal comportamento se dá devido aos parâmetros de configuração dos túneis serem idênticos. Nesta simulação vimos também que, caso um dos túneis fique inativo, o tráfego será enviado normalmente pelo túnel ativo, garantindo também a redundância na comunicação. Em seguida mantivemos os dois túneis e criamos um terceiro túnel, o qual chamamos de túnel 2, que iria seguir por um outro caminho, mas com o mesmo destino, solicitando metade da banda requisitada pelos túneis iniciais. Após sua criação, notamos o balanceamento de carga entre os três túneis através do gráfico fornecido, porém distribuído de acordo com a razão da banda alocada entre eles. Através da tabela de roteamento e testes com o traceroute partindo do head-end em direção ao tail-end, podemos constatar o balanceamento, nesse caso, entre os três caminhos. Para melhor entendimento, fizemos toda uma análise gráfica desse cenário de engenharia de tráfego. Tabela 8.3 – Tabela comparativa das tecnologias e serviços agregados

Serviços/Tecnologias

ATM

FR

MPLS

Limite – Banda comercializada

622 Mbps

2 Mbps

Ilimitada

PseudoWire

----

----

Transporte de quaisquer tecnologias

VPN

Não escalável N(N-1)/2

Não escalável N(N-1)/2

Escalável – Full Mesh

QoS TE


Apenas nas bordas Apenas nas bordas ----

----

Fim-a-fim Criação de túneis para distribuição de carga

29/10/2012 14:57:45


Na Tabela 8.3 foram resumidas as informações relativas aos serviços utilizados pela tecnologia MPLS em comparação com as tecnologias legadas, ATM e Frame Relay.

8.5 – IPv6 sobre MPLS Para simulação do tráfego IPv6 em um backbone MPLS, foram estudadas as técnicas utilizadas para migração IPv4-IPv6. Observamos que as técnicas 6PE e 6VPE realizam o suporte IPv6 estendendo apenas os PEs para tráfego IPv6 na rede MPLS, provendo conectividade para os clientes sem a necessidade de atualizar toda a rede para IPv6. Isso proporciona um baixo impacto nessa rede, característica muito importante durante o atual período de transição. As topologias utilizadas para as simulações dos ambientes 6PE e 6VPE estão descritas nas Figuras 8.22 e 8.23, respectivamente. O transporte do protocolo IPv6 foi efetuado entre CE11 e CE22, fazendo uso primeiramente da técnica 6PE e em seguida da técnica 6VPE. Os endereços utilizados para estas simulações são apresentados na Tabela 8.4. A solução 6PE é simples e direta para configurar, bastando apenas ativar a adjacência iBGP no IPv6 address family do BGP, adicionando um comando extra (send-label). Além deste comando, é necessário ativar o envio de rótulos MPLS via MP-BGP para o IPv6 address family e para o par BGP. Portanto, basicamente apenas dois comandos são necessários: Router(config-router-af)#neighbor ip-address send-label Router(config)#mpls ipv6 source-interface type number

Os comandos para configuração do 6VPE é similar aos comandos já vistos neste capítulo para configuração do MPLS-VPN para IPv4, porém, no lugar do IPv4 usa-se o IPv6. Seguem os passos para configuração: •• Configurar MPLS no núcleo da rede IPv4. •• Configurar o MPLS-VPN para IPv4. •• Configurar a instância de VRF para IPv6 no PE. •• Associar a instância de VRF IPv6 para uma interface do PE. •• Configurar address family vpnv6 e address family IPv6 VRF para o protocolo de roteamento BGP.


29/10/2012 14:57:45

162 Redes MPLS

•• Configurar um protocolo de roteamento IPv6 entre o PE e o CE. Para a simulação do 6PE, optamos por usar o protocolo RIPng (Routing Information Base next generation), ou seja, o protocolo de roteamento RIP para o protocolo IPv6, entre os CEs e o PEs. Porém, outros protocolos, tais como OSPF, ISIS, BGP e até mesmo um roteamento estático, poderiam ser utilizados. Vale salientar que, para aprendizado das rotas, foi utilizado um processo de redistribuição entre os protocolos RIPng e BGP, no backbone. Quando da utilização deste processo, é importante que seja feita uma filtragem de roteamento, para que apenas as rotas necessárias sejam transmitidas aos roteadores CEs, evitando grandes tabelas de roteamento nestes e consequentemente uma perda em seu desempenho. Para a simulação do 6VPE utilizamos o protocolo BGP entre os CEs e os PEs.

Observação: para a simulação do 6VPE foi utilizado outro IOS nos roteadores 7200VXR (c7200-adventerprisek9-mz.124-22.T4.bin), pois o IOS utilizado para as demais simulações (c7200-jk9o3s-mz.124-7.bin) não contempla esta característica.

Figura 8.22 – Topologia para o laboratório IPv6 – 6PE


29/10/2012 14:57:45


Figura 8.23 – Topologia utilizada para o laboratório IPv6 – 6VPE Tabela 8.4 – Endereços IPs utilizados para simulação

Roteador

Int. Loopback0

Int. Serial1/0

Int. Serial1/1

Int. Serial1/2

CE11 CE22 E1 PE2

2012:100::1/128

2012:11::2/64

2012:200::1/128

2012:22::2/64

172.1.0.1/32

2012:11::1/64

192.168.0.13/30

192.168.0.17/30

2012:22::1/64

192.168.0.21/30

192.168.0.25/30

P1 P2

172.10.0.1/32 172.20.0.1/32

192.168.0.14/30

192.168.0.22/30

192.168.0.29/30

192.168.0.18/30

192.168.0.26/30

192.168.0.30/30

172.2.0.1/32

Int. Serial1/3

Seguem alguns testes e verificações efetuados para o 6PE: CE11#show ipv6 route Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 C 2012:11::/64 [0/0] via ::, Serial1/0 L 2012:11::2/128 [0/0]


29/10/2012 14:57:46

164 Redes MPLS via ::, Serial1/0 2012:22::/64 [120/2] via FE80::C808:14FF:FEC8:0, Serial1/0 2012:100::1/128 [0/0] via ::, Loopback0 2012:200::1/128 [120/3] via FE80::C808:14FF:FEC8:0, Serial1/0 FE80::/10 [0/0] via ::, Null0 FF00::/8 [0/0] via ::, Null0

R LC R L L

CE11#traceroute 2012:200::1 Type escape sequence to abort. Tracing the route to 2012:200::1 1 2012:11::1 52 msec 88 msec 60 msec 2 * * * 3 2012:22::1 92 msec 88 msec 136 msec 4 2012:200::1 120 msec 124 msec 152 msec

Seguem alguns testes e verificações efetuados para o 6VPE: PE1#show bgp vpnv6 unicast vrf VPN_A labels Network Next Hop In label/Out label Route Distinguisher: 65500:1 (VPN_A) 2012:11::/64 :: 16/nolabel(VPN_A) 2012:22::/64 ::FFFF:172.2.0.1 nolabel/16 2012:100::1/128 2012:11::2 17/nolabel 2012:200::1/128 ::FFFF:172.2.0.1 nolabel/17 CE11#sh ipv6 route IPv6 Routing Table - 7 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 C 2012:11::/64 [0/0] via ::, Serial1/0 L 2012:11::2/128 [0/0] via ::, Serial1/0 B 2012:22::/64 [20/0] via FE80::C807:19FF:FE18:0, Serial1/0 LC 2012:100::1/128 [0/0] via ::, Loopback0 B 2012:200::1/128 [20/0] via FE80::C807:19FF:FE18:0, Serial1/0


29/10/2012 14:57:46


L

FE80::/10 [0/0] via ::, Null0 FF00::/8 [0/0] via ::, Null0

L

PE1#ping vrf VPN_A ipv6 2012:200::1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2012:200::1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 84/98/112 ms CE11#ping 2012:200::1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2012:200::1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 140/144/152 ms CE11#traceroute 2012:200::1 Type escape sequence to abort. Tracing the route to 2012:200::1 1 2 3 4

2012:11::1 48 msec 52 msec 40 msec ::FFFF:192.168.0.18 116 msec 92 msec 92 msec 2012:22::1 108 msec 60 msec 100 msec 2012:200::1 152 msec 140 msec 140 msec

Observação: as configurações completas dos roteadores encontram-se no Apêndice F desta obra.


29/10/2012 14:57:46

Referências Bibliográficas

(Blake et al, 2007) Blake, S.; Blake, D.; Carlson, M.; Davies, E. An Architecture of Differentiated Services. RFC 2475, December 1998. (Bollapragada et al, 2000) Bollapragada, Vijay; Murphy, Curtis; White, Russ. Inside Cisco IOS Software Architecture. Indianápolis: Cisco Press, 2000. (Chowdhury, 2002) Chowdhury, Dhiman D. Projetos Avançados de Redes IP. 1 ed. Rio de Janeiro: Campus, 2002. (Colcher et al, 2005) Colcher, Sérgio; Gomes, Antonio Tadeu A.; Silva, Anderson Oliveira; Filho, Guido L. De Souza Filho; Soares, Luiz Fernando G. VoIP: Voz sobre IP. 3 ed. Rio de Janeiro: Campus, 2005. (Davidson et al, 2007) Davidson, Jonathan; Peters, James; Bhatia, Manoj; Kalindindi, Satish; Mukherjee, Sudipto. Voice over IP Fundamentals. 2 ed. Indianápolis: Cisco Press, 2007. (Davie e Rekhter, 2000) Davie, B.; Rekhter, Y. MPLS Technology and Applications. Massachusetts: Morgan Kaufmann, 2000. (De Ghein, 2007) De Ghein, Luc. MPLS Fundamentals. Indianapolis: Cisco Press, 2007. (Doyle e Carroll, 2006) Doyle, Jeff; Carroll, Jennifer. Routing TCP/IP. 2 ed. Indianápolis: Cisco Press, 2006. 1 v. (Enne, 2009) Enne, Antonio. TCP/IP sobre MPLS. 1 ed. Rio de Janeiro: Ciência Moderna, 2009. (Farrel, 2005) Farrel, Adrian. The Internet and Its Protocols: a comparative approach. Massachusetts: Morgan Kaufmann, 2005. (Filippetti, 2008) Filippetti, Marco Aurélio. Uma arquitetura para a construção de laboratórios híbridos de redes de computadores remotamente 167


29/10/2012 14:57:46

168 Redes MPLS

acessíveis. Instituto de Pesquisas Tecnológicas do Estado de São Paulo (IPT), 2008. (Florentino, 2012) Florentino, Adilson Aparecido. IPv6 na prática. 1 ed. São Paulo: Linux New Media do Brasil LTDA, 2012. (Forouzan, Benhrouz A., 2008) Forouzan, Benhrouz A. Comunicações de Dados e Redes de Computadores. 4 ed. São Paulo: McGraw-Hill, 2008. (Forouzan, Benhrouz A., 2008a) Forouzan, Benhrouz A. Protocolo TCP/IP. 3 ed. São Paulo: McGraw Hill Brasil, 2008. (Gallaher, 2003) Gallaher, Rick. MPLS Training Guide. 1 ed. Waltham: Syngress, 2003. (Guimarães et al, 2006) Guimarães, Alexandre; Lins, Rafael Dueire; Oliveira, Raimundo. Segurança em Redes Privadas Virtuais - VPNs. Rio de Janeiro: Brasport, 2006. (Hardeny, 2002) Hardeny, S. The MPLS Primer. New Jersey: Prentice Hall, 2002. (Kurose e Ross, 2010) Kurose, James; Ross, Keith. Computer Networking: a top down approach featuring the Internet. 4. ed. Boston: Addison-Wesley, 2010. (Lins et al, 2011) Lins, Rafael Dueire; Barbosa, Douglas; Nascimento, Victor. VoIP – Conceitos e Aplicações. 1 ed. Rio de Janeiro: Brasport, 2011. (Lobo, 2008) Lobo, Lancy. MPLS Configuration on Cisco IOS Software. Indianápolis: Cisco Press, 2008. (Lucek e Minei, 2005) Lucek, Julian; Minei, Ina. MPLS – Enabled Applications: emerging developments and new technologies. Indianápolis: Wiley, 2005. (Martey e Sturgess, 2002) Martey, A.; Sturgess, S. IS-IS Network Design Solutions. Indianápolis: Cisco Press, 2002. (Newman et al, 1996) Newman, P.; Edwards, W. L.; Hinden, R.; Hoffman, E.; Ching Liaw, F.; Lyon, T.; Minshall, G. RFC 1953: Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0. Network Working Group, 1996. (Odom e Cavanaugh, 2004) Odom, Wendell; Cavanaugh, Michael. IP Telephony Self-Study Cisco DQOS. Indianápolis: Cisco Press, 2004. (Osborne e Simha, 2002) Osborne, Eric; Simha, Ajay. Traffic Engineering with MPLS. Indianápolis: Cisco Press, 2002.


29/10/2012 14:57:46

Referências Bibliográficas 169

(Paquet e Teare, 2003) Paquet, Catherine; Teare, Diane. Building Scalable Cisco Networks. New Jersey: Pearson Education, 2003. (Pepelnjak e Guichard, 2000) Pepelnjak, I; Guichard J. MPLS and VPN Architectures. Indianapolis: Cisco Press, 2000. (Peterson e Davie, 2004) Peterson, Larry; Davie, Bruce. Redes de Computadores: uma abordagem de sistemas. 3 ed. Rio de Janeiro: Elsevier, 2004. (Rekhter et el, 1997) Rekhter, Y.; Davie, B.; Katz, D.; Rosen, E.; Swallow, G. RFC 2105: Cisco Systems’ Tag Switching Architecture Overview. Network Working Group, 1997. (Ricci, 2007) Ricci, Bruno. Rede Segura: VPN Linux. 1 ed. Rio de Janeiro: Ciência Moderna, 2007. (Rosen et al, 2001) Rosen, E.; Viswanathan, A.; Callon, R. RFC 3031: MultiProtocol Label Switching Architecture. The Internet Society, 2001. (Rosen et al, 2001) Rosen, E.; Tappan, D.; Fedorkow, G.; Rekhter, Y.; Li, T.; Conta, A. RFC 3032: MPLS Label Stack Encoding. The Internet Society, 2001. (Santos, Rodrigo et al, 2009) Santos, Rodrigo Regis; Moreiras, Antonio Marcos; Rocha, Ailton Soares. Curso IPv6 básico. 1 ed. São Paulo: Comitê Gestor da Internet no Brasil, 2009. (Sverzut, 2008) Sverzut, José Umberto. Redes Convergentes. 1 ed. São Paulo: Artliber, 2008. (Tanenbaum, 2011) Tanenbaum, Andrew. Redes de Computadores. 5. ed. São Paulo: Pearson, 2011. (Wireshark, 2012) wireshark. Disponível em: . Acesso em: 25 abril 2012. (Cisco, 2010) CISCO. Disponível em : . Acesso em: 28 abril 2012. (Cisco, 2011) CISCO. Disponível em: . Acesso em: 30 abril 2012. (Cisco, 2012) CISCO. Disponível em: . Acesso em: 28 abril 2012. (Freesco, 2012) FREESCO. Disponível em: . Acesso em: 28 abril 2012.


29/10/2012 14:57:46

170 Redes MPLS

(GNS3, 2012) GNS3. Disponível em: . Acesso em: 29 abril 2012. (Huawei, 2012) HUAWEI. Disponível em: . Acesso em: 28 abril 2012. (HP, 2012) HP. Disponível em: Acesso em: 28 abril 2012. (Juniper, 2012) JUNIPER. Disponível em: . Acesso em: 28 abril 2012. (RFC 1058). Disponível em: . Acesso em: 28 abril 2012. (RFC 1247) Disponível em: . Acesso em: 28/04/2012. (RFC 1723) Disponível em: . Acesso em: 30/04/2012. (RFC 1771) Disponível em: . Acesso em: 30/04/2012. (RFC 1883) Disponível em: . Acesso em: 30/04/2012. (RFC 1918) Disponível em: . Acesso em: 28/04/2012. (RFC 1930) Disponível em: . Acesso em: 28/04/2012. (RFC 2080) Disponível em: . Acesso em: 30/04/2012. (RFC 2460) Disponível em: . Acesso em: 28/04/2012. (RFC 2475) Disponível em: . Acesso em: 28/04/2012. (RFC 2597) Disponível em: . Acesso em: 28/04/2012. (RFC 2598) Disponível em: . Acesso em: 28/04/2012.


29/10/2012 14:57:47

Referências Bibliográficas 171

(RFC 2858) Disponível em: . Acesso em: 28/04/2012. (RFC 3107) Disponível em: . Acesso em: 28/04/2012. (RFC 3630) Disponível em: . Acesso em: 28/04/2012. (RFC 3784) Disponível em: . Acesso em: 28/04/2012. (RFC 4271) Disponível em: . Acesso em: 28/04/2012. (RFC 4203) Disponível em: . Acesso em: 28/04/2012. (RFC 4258) Disponível em: . Acesso em: 28/04/2012. (RFC 4364) Disponível em: . Acesso em 28/04/2012. (RFC 4760) Disponível em: . Acesso em: 28/04/2012. (RFC 5063) Disponível em: . Acesso em: 28/04/2012. (TFGEN, 2012) Disponível em: . Acesso em: 28/04/2012. (Vytta, 2012) Disponível em: . Acesso em: 28/04/2012. (YouTube, 2010) Disponível em: watch?v=IzLPKuAOe50>. Acesso em: 28/04/2012.

(Zebra, 2012) Disponível em: . Acesso em: 28/04/2012.


29/10/2012 14:57:47

APÊNDICE A. Configurações – Funcionamento do MPLS

São aqui apresentadas as configurações finais dos roteadores do backbone (PE1, PE2, P1 e P2): hostname PE1 ip cef mpls label protocol ldp interface Loopback0 ip address 172.1.0.1 ip router isis

255.255.255.255

interface Serial1/0 description connected to CE11 ip address 150.1.1.1 255.255.255.252 interface Serial1/2 description connected to P1 ip address 192.168.0.13 255.255.255.252 ip router isis mpls ip interface Serial1/3 description connected to P2 ip address 192.168.0.17 255.255.255.252 ip router isis mpls ip router isis net 49.0172.0001.0000.0001.00 is-type level-2-only router bgp 65500 no synchronization bgp log-neighbor-changes redistribute static neighbor 172.2.0.1 remote-as 65500 neighbor 172.2.0.1 update-source Loopback0

173


29/10/2012 14:57:47

174 Redes MPLS neighbor 172.2.0.1 next-hop-self no auto-summary ip route 200.1.0.1 255.255.255.255 150.1.1.2 hostname PE2 ip cef mpls label protocol ldp interface Loopback0 ip address 172.2.0.1 ip router isis

255.255.255.255

interface Serial1/1 description connected to CE22 ip address 150.1.2.5 255.255.255.252 interface Serial1/2 description connected to P1 ip address 192.168.0.21 255.255.255.252 ip router isis mpls ip interface Serial1/3 description connected to P2 ip address 192.168.0.25 255.255.255.252 ip router isis mpls ip router isis net 49.0172.0002.0000.0001.00 is-type level-2-only router bgp 65500 no synchronization bgp log-neighbor-changes redistribute static neighbor 172.1.0.1 remote-as 65500 neighbor 172.1.0.1 update-source Loopback0 neighbor 172.1.0.1 next-hop-self no auto-summary ip route 200.2.0.2 255.255.255.255 150.1.2.6 hostname P1 ip cef mpls label protocol ldp interface Loopback0 ip address 172.10.0.1 255.255.255.255 ip router isis


29/10/2012 14:57:47

Configurações – Funcionamento do MPLS 175

interface Serial1/0 description connected to PE1 ip address 192.168.0.14 255.255.255.252 ip router isis mpls ip interface Serial1/1 description connected to PE2 ip address 192.168.0.22 255.255.255.252 ip router isis mpls ip interface Serial1/2 description connected to P2 ip address 192.168.0.29 255.255.255.252 ip router isis mpls ip router isis net 49.0172.0010.0000.0001.00 is-type level-2-only hostname P2 ip cef mpls label protocol ldp interface Loopback0 ip address 172.20.0.1 255.255.255.255 ip router isis interface Serial1/0 description connected to PE1 ip address 192.168.0.18 255.255.255.252 ip router isis mpls ip interface Serial1/1 description connected to PE2 ip address 192.168.0.26 255.255.255.252 ip router isis mpls ip interface Serial1/2 description connected to P1 ip address 192.168.0.30 255.255.255.252 ip router isis mpls ip router isis net 49.0172.0020.0000.0001.00 is-type level-2-only


29/10/2012 14:57:47

176 Redes MPLS

Comandos para visualização: Através do comando “show mpls interfaces”, podemos verificar se o encaminhamento MPLS está habilitado nas interfaces. Vejamos o exemplo para o roteador P1: P1#show mpls interfaces Interface IP Serial1/0 Yes (ldp) Serial1/1 Yes (ldp) Serial1/2 Yes (ldp)

Tunnel No No No

Operational Yes Yes Yes

A coluna IP exibe “Yes” sempre que a comutação de rótulo está habilitada na interface. A coluna Tunnel exibe “Yes” se o túnel LSP estiver habilitado na interface – nesse caso não estamos fazendo uso, então na coluna aparece “No”. O mesmo será utilizado para engenharia de tráfego, que será descrito posteriormente. A coluna Operational exibe “Yes” se os pacotes são rotulados na interface. Com o comando “show mpls ldp neighbor” verificamos o status do vizinho LDP. Podemos observar a seguir a sessão LDP entre P1 e seus vizinhos LDP (PE1, PE2 e P2). P1#show mpls ldp neighbor Peer LDP Ident: 172.1.0.1:0; Local LDP Ident 172.10.0.1:0 TCP connection: 172.1.0.1.646 - 172.10.0.1.19357 State: Oper; Msgs sent/rcvd: 71/74; Downstream Up time: 00:49:01 LDP discovery sources: Serial1/0, Src IP addr: 192.168.0.13 Addresses bound to peer LDP Ident: 150.1.1.1 172.1.0.1 192.168.0.13 192.168.0.17 Peer LDP Ident: 172.2.0.1:0; Local LDP Ident 172.10.0.1:0 TCP connection: 172.2.0.1.646 - 172.10.0.1.62275 State: Oper; Msgs sent/rcvd: 70/75; Downstream Up time: 00:48:59 LDP discovery sources: Serial1/1, Src IP addr: 192.168.0.21 Addresses bound to peer LDP Ident: 150.1.2.5 172.2.0.1 192.168.0.21 192.168.0.25 Peer LDP Ident: 172.20.0.1:0; Local LDP Ident 172.10.0.1:0 TCP connection: 172.20.0.1.55457 - 172.10.0.1.646 State: Oper; Msgs sent/rcvd: 66/67; Downstream Up time: 00:48:11 LDP discovery sources: Serial1/2, Src IP addr: 192.168.0.30 Addresses bound to peer LDP Ident: 192.168.0.18 172.20.0.1 192.168.0.26 192.168.0.30


29/10/2012 14:57:48

APÊNDICE B. Verificação – PseudoWire

Para ver quais características do PseudoWire a interface suporta para cada tipo de encapsulamento, utiliza-se o seguinte comando: PE1#show mpls l2transport hw-capability interface serial1/0 Interface Serial1/0 Transport type FR DLCI Core functionality: MPLS label disposition supported Control word processing supported Sequence number processing not supported Edge functionality: MPLS label imposition supported Control word processing supported Sequence number processing not supported Transport type ATM AAL5 Core functionality: MPLS label disposition supported Control word processing supported Sequence number processing not supported Edge functionality: Not supported Transport type Ethernet Core functionality: MPLS label disposition supported Control word processing supported Sequence number processing not supported Edge functionality: Not supported Transport type HDLC Core functionality: MPLS label disposition supported Control word processing supported

177


29/10/2012 14:57:48

178 Redes MPLS Sequence number processing not supported Edge functionality: MPLS label imposition supported Control word processing supported Sequence number processing not supported Transport type PPP Core functionality: MPLS label disposition supported Control word processing supported Sequence number processing not supported Edge functionality: MPLS label imposition supported Control word processing supported Sequence number processing not supported


29/10/2012 14:57:48

APÊNDICE C. Configurações – MPLS-VPN

Configurações das VRFs para os roteadores PE1 e PE2: hostname PE1 ip vrf VPN_A rd 65500:1 route-target export 65500: 1 route-target import 65500:1 ip vrf VPN_B rd 65500:2 route-target export 65500:2 route-target import 65500:2 interface Serial1/0 description connected to CE11 ip vrf forwarding VPN_A ip address 150.1.1.1 255.255.255.252 interface Serial2/0 description connected to CE13 ip vrf forwarding VPN_A ip address 150.1.1.9 255.255.255.252 interface Serial1/1 description connected to CE12 ip vrf forwarding VPN_B ip address 150.1.1.5 255.255.255.252 hostname PE2 ip vrf VPN_A rd 65500:1 route-target export 65500:1 route-target import 65500:1 ip vrf VPN_B rd 65500:2

179


29/10/2012 14:57:48

180 Redes MPLS route-target export 65500:2 route-target import 65500:2 interface Serial1/0 description connected to CE21 ip vrf forwarding VPN_B ip address 150.1.2.1 255.255.255.252 interface Serial1/1 description connected to CE22 ip vrf forwarding VPN_A ip address 150.1.2.5 255.255.255.252

Configurações finais do roteamento BGP entre os PEs: hostname PE1 router bgp 65500 no synchronization redistribute static neighbor 172.2.0.1 remote-as 65500 neighbor 172.2.0.1 update-source Loopback0 neighbor 172.2.0.1 next-hop-self no auto-summary address-family vpnv4 neighbor 172.2.0.1 activate neighbor 172.2.0.1 send-community extended neighbor 172.2.0.1 next-hop-self exit-address-family address-family ipv4 vrf VPN_A redistribute connected redistribute static no synchronization exit-address-family address-family ipv4 vrf VPN_B redistribute connected redistribute static no synchronization exit-address-family hostname PE2 router bgp 65500 no synchronization redistribute static neighbor 172.1.0.1 remote-as 65500 neighbor 172.1.0.1 update-source Loopback0 neighbor 172.1.0.1 next-hop-self no auto-summary


29/10/2012 14:57:49

Configurações – MPLS-VPN 181

address-family vpnv4 neighbor 172.1.0.1 activate neighbor 172.1.0.1 send-community extended neighbor 172.1.0.1 next-hop-self exit-address-family address-family ipv4 vrf VPN_A redistribute connected redistribute static no synchronization exit-address-family address-family ipv4 vrf VPN_B redistribute connected redistribute static no synchronization exit-address-family

Configurações dos CEs e PEs para roteamento estático: hostname CE11 ip cef interface Loopback0 ip address 200.1.0.1 255.255.255.255 interface Serial1/0 description Connected to PE1 ip address 150.1.1.2 255.255.255.252 ip route 0.0.0.0 0.0.0.0 150.1.1.1 hostname CE12 ip cef interface Loopback0 ip address 200.1.0.2 255.255.255.255 interface Serial1/0 description Connected to PE1 ip address 150.1.1.6 255.255.255.252 ip route 0.0.0.0 0.0.0.0 150.1.1.


29/10/2012 14:57:49

182 Redes MPLS hostname CE13 ip cef interface Loopback ip address 200.1.0.3 255.255.255.255 interface Serial1/0 description connected to PE1 ip address 150.1.1.10 255.255.255.252 ip route 0.0.0.0 0.0.0.0 150.1.1.9 hostname CE21 ip cef interface Loopback0 ip address 200.2.0.1 255.255.255.255 interface Serial1/0 description connected to PE2 ip address 150.1.2.2 255.255.255.252 ip route 0.0.0.0 0.0.0.0 150.1.2.1 hostname CE22 ip cef interface Loopback0 ip address 200.2.0.2 255.255.255.255 interface Serial1/0 description connected to PE2 ip address 150.1.2.6 255.255.255.252 ip route 0.0.0.0 0.0.0.0 150.1.2.5 hostname PE1 router bgp 65500 address-family ipv4 vrf VPN_A redistribute connected redistribute static no synchronization exit-address-family address-family ipv4 vrf VPN_B redistribute connected redistribute static no synchronization exit-address-family ip route vrf VPN_A 200.1.0.1 255.255.255.255 150.1.1.2 ip route vrf VPN_A 200.1.0.3 255.255.255.255 150.1.1.10 ip route vrf VPN_B 200.1.0.2 255.255.255.255 150.1.1.6


29/10/2012 14:57:49


hostname PE2 router bgp 65500 address-family ipv4 vrf VPN_A redistribute connected redistribute static no synchronization exit-address-family address-family ipv4 vrf VPN_B redistribute connected redistribute static no synchronization exit-address-family ip route vrf VPN_A 200.2.0.2 255.255.255.255 150.1.2.6 ip route vrf VPN_B 200.2.0.1 255.255.255.255 150.1.2.2

Configurações dos CEs e PEs para roteamento BGP: hostname CE11 router bgp 100 no synchronization network 150.1.1.0 mask 255.255.255.252 network 200.1.0.1 mask 255.255.255.255 neighbor 150.1.1.1 remote-as 65500 neighbor 150.1.1.1 allowas-in no auto-summary hostname CE12 router bgp 200 no synchronization bgp log-neighbor-changes network 150.1.1.4 mask 255.255.255.252 network 200.1.0.2 mask 255.255.255.255 neighbor 150.1.1.5 remote-as 65500 neighbor 150.1.1.5 allowas-in no auto-summary hostname CE13 router bgp 100 no synchronization network 150.1.1.8 mask 255.255.255.252 network 200.1.0.3 mask 255.255.255.255 neighbor 150.1.1.9 remote-as 65500 neighbor 150.1.1.9 allowas-in no auto-summary


29/10/2012 14:57:49

184 Redes MPLS hostname CE21 router bgp 200 no synchronization network 150.1.2.0 mask 255.255.255.252 network 200.2.0.1 mask 255.255.255.255 neighbor 150.1.2.1 remote-as 65500 neighbor 150.1.2.1 allowas-in no auto-summary hostname CE22 router bgp 100 no synchronization network 150.1.2.4 mask 255.255.255.252 network 200.2.0.2 mask 255.255.255.255 neighbor 150.1.2.5 remote-as 65500 neighbor 150.1.2.5 allowas-in no auto-summary hostname CE22 router bgp 100 no synchronization network 150.1.2.4 mask 255.255.255.252 network 200.2.0.2 mask 255.255.255.255 neighbor 150.1.2.5 remote-as 65500 neighbor 150.1.2.5 allowas-in no auto-summary hostname PE1 router bgp 65500 address-family ipv4 vrf VPN_A neighbor 150.1.1.2 remote-as 100 neighbor 150.1.1.2 update-source Serial1/0 neighbor 150.1.1.2 activate neighbor 150.1.1.10 remote-as 100 neighbor 150.1.1.10 update-source Serial2/0 neighbor 150.1.1.10 activate neighbor 150.1.1.10 next-hop-self no synchronization exit-address-family address-family ipv4 vrf VPN_B neighbor 150.1.1.6 remote-as 200 neighbor 150.1.1.6 update-source Serial1/1 neighbor 150.1.1.6 activate no synchronization exit-address-family


29/10/2012 14:57:49


hostname PE2 router bgp 65500 address-family ipv4 vrf VPN_A neighbor 150.1.2.6 remote-as 100 neighbor 150.1.2.6 update-source Serial1/1 neighbor 150.1.2.6 activate neighbor 150.1.2.6 next-hop-self no synchronization exit-address-family address-family ipv4 vrf VPN_B neighbor 150.1.2.2 remote-as 200 neighbor 150.1.2.2 update-source Serial1/0 neighbor 150.1.2.2 activate neighbor 150.1.2.2 next-hop-self no synchronization exit-address-family

Observação: o comando “allowas-in” foi utilizado nos roteadores CEs e serve para permitir múltiplas ocorrências do mesmo AS no caminho sem negar a rota. As configurações do MP-iBGP podem ser visualizadas através dos comandos a seguir. Neste caso, para o roteamento estático. Vemos que só existe adjacência BGP entre os PEs. PE1#show ip bgp vpnv4 all summary BGP router identifier 172.1.0.1, local AS number 65500 BGP table version is 11, main routing table version 11 Neighbor 172.2.0.1 PE1#

V AS MsgRcvd MsgSent TblVer 4 65500 317 315 11

InQ OutQ Up/Down State/PfxRcd 0 0 00:55:46 2

PE2#show ip bgp vpnv4 all summary PE2BGP router identifier 172.2.0.1, local AS number 65500 BGP table version is 11, main routing table version 11 Neighbor 172.1.0.1 PE2#


V AS MsgRcvd MsgSent TblVer InQ 4 65500 318 320 11 0

OutQ Up/Down State/PfxRcd 0 00:58: 3

29/10/2012 14:57:49

186 Redes MPLS

Com o comando a seguir podemos ver os rótulos das VPNs que são acrescentados no PE1: PE1#show ip bgp vpnv4 all tags Network Next Hop In tag/Out tag Route Distinguisher: 65500:1 (VPN_A) 150.1.1.0/30 150.1.1.2 16/aggregate(VPN_A) 150.1.1.8/30 150.1.1.10 17/aggregate(VPN_A) 150.1.2.4/30 172.2.0.1 28/16 200.1.0.1/32 150.1.1.2 18/notag 200.1.0.3/32 150.1.1.10 19/notag 200.2.0.2/32 172.2.0.1 29/17 Route Distinguisher: 65500:2 (VPN_B) 150.1.1.4/30 150.1.1.6 20/aggregate(VPN_B) 150.1.2.0/30 172.2.0.1 30/18 200.1.0.2/32 150.1.1.6 21/notag 200.2.0.1/32 172.2.0.1 31/19

Configurações do MP-iBGP para o processo de roteamento dinâmico BGP: Nesse caso, percebemos que existem adjacências BGP entre os PEs e entre o PE e o CE. PE1#sh ip bgp vpnv4 all summary BGP router identifier 172.1.0.1, local AS number 65500 BGP table version is 44, main routing table version 44 Neighbor V AS MsgRcvd MsgSent 150.1.1.2 4 100 53 55 150.1.1.6 4 200 45 45 150.1.1.10 4 100 47 50 172.2.0.1 4 65500 70 68

TblVer 44 44 44 44

InQ OutQ Up/Down State/PfxRcd 0 0 00:24:15 2 0 0 00:40:08 2 0 0 00:41:33 2 0 0 00:58:08 4

PE2#show ip bgp vpnv4 all summary BGP router identifier 172.2.0.1, local AS number 65500 BGP table version is 93, main routing table version 93 Neighbor 150.1.2.2 150.1.2.6 172.1.0.1

V 4 4 4

AS MsgRcvd MsgSent 200 16 16 100 43 44 65500 307 289

TblVer 93 93 93

InQ OutQ Up/Down State/PfxRcd 0 0 00:11:51 2 0 0 00:37:59 2 0 0 00:59:59 6

Configurações do PE1 e do PE2 para funcionalidade da topologia Hub and Spoke: hostname PE1 ip vrf HUB rd 65500:1 route-target export 65500:1 route-target import 65500:2 ip vrf SPOKE13


29/10/2012 14:57:49


rd 65500:2 route-target export 65500:2 route-target import 65500:1 router bgp 65500 address-family ipv4 vrf HUB neighbor 150.1.1.2 remote-as 100 neighbor 150.1.1.2 update-source Serial1/0 neighbor 150.1.1.2 activate neighbor 150.1.1.2 next-hop-self no synchronization exit-address-family address-family ipv4 vrf SPOKE13 neighbor 150.1.1.10 remote-as 100 neighbor 150.1.1.10 update-source Serial2/0 neighbor 150.1.1.10 activate neighbor 150.1.1.10 next-hop-self no synchronization exit-address-family hostname PE2 ip vrf SPOKE22 rd 65500:3 route-target export 65500:2 route-target import 65500:1 address-family ipv4 vrf SPOKE22 neighbor 150.1.2.6 remote-as 100 neighbor 150.1.2.6 update-source Serial1/1 neighbor 150.1.2.6 activate neighbor 150.1.2.6 next-hop-self no synchronization exit-address-family


29/10/2012 14:57:49

APÊNDICE D. Configurações – MPLS – QoS

1. Política de entrada no PE1: class-map match ip class-map match ip

match-all BUSINESS-IP dscp af21 af22 af23 match-all PREMIUM-IP dscp ef

policy-map IN-POLICY class PREMIUM-IP police cir 128000 bc 32000 be 32000 conform-action set-mpls-exp-topmost-transmit 5 exceed-action drop class BUSINESS-IP police cir 512000 bc 128000 be 128000 conform-action set-mpls-exp-topmost-transmit 2 exceed-action set-mpls-exp-topmost-transmit 1 class class-default set mpls experimental imposition 0 interface Serial1/0.101 point-to-point description connected to CE11 ip address 150.1.1.1 255.255.255.252 frame-relay interface-dlci 101 service-policy input IN-POLICY

2. Política de saída do PE1: class-map match-all PREMIUM-MPLS match mpls experimental topmost 5 class-map match-all BUSINESS-MPLS match mpls experimental topmost 1

2

policy-map OUT-POLICY class PREMIUM-MPLS priority percent 5 class BUSINESS-MPLS

188


29/10/2012 14:57:50

Configurações – MPLS – QoS 189 bandwidth percent 50 class class-default fair-queue random-detect interface Serial1/2 description connected to P1 ip address 192.168.0.13 255.255.255.252 ip router isis mpls ip service-policy output OUT-POLICY

3. Política de saída do P1: class-map match-all BUSINESS-MPLS match mpls experimental topmost 1 class-map match-all PREMIUM-MPLS match mpls experimental topmost 5

2

policy-map OUT-POLICY class PREMIUM-MPLS priority percent 5 class BUSINESS-MPLS bandwidth percent 50 class class-default fair-queue random-detect interface Serial1/2 description connected to P2 ip address 192.168.0.29 255.255.255.252 ip router isis mpls ip service-policy output OUT-POLICY

4. Política de saída do P2: class-map match-all BUSINESS-MPLS match mpls experimental topmost 1 class-map match-all PREMIUM-MPLS match mpls experimental topmost 5

2

policy-map OUT-POLICY class PREMIUM-MPLS priority percent 5 class BUSINESS-MPLS bandwidth percent 50 class class-default fair-queue random-detect


29/10/2012 14:57:50

190 Redes MPLS interface Serial1/1 description connected to PE2 ip address 192.168.0.26 255.255.255.252 ip router isis mpls ip service-policy output OUT-POLICY

5. Política de saída do PE2: class-map match ip class-map match ip

match-all BUSINESS-IP dscp af21 af22 af23 match-all PREMIUM-IP dscp ef

policy-map IP-OUT class PREMIUM-IP priority percent 50 class BUSINESS-IP bandwidth percent 25 class class-default fair-queue random-detect interface Serial1/1 description connected to CE22 no ip address encapsulation frame-relay frame-relay intf-type dce service-policy output IP-OUT

Comandos para visualização da simulação: PE1#show class-map Class Map match-any class-default (id 0) Match any Class Map match-all BUSINESS-IP (id 2) Match ip dscp af21 (18) af22 (20) af23 (22) Class Map match-all PREMIUM-IP (id 1) Match ip dscp ef (46) PE1#show class-map Class Map match-any class-default (id 0) Match any Class Map match-all BUSINESS-IP (id 2) Match ip dscp af21 (18) af22 (20) af23 (22) Class Map match-all PREMIUM-IP (id 1) Match ip dscp ef (46)


29/10/2012 14:57:50

Configurações – MPLS – QoS 191

Verificação do tráfego nas políticas de entrada e saída do PE1: PE1#show policy-map interface serial1/0.101 Serial1/0.101 Service-policy input: IN-POLICY Class-map: PREMIUM-IP (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip dscp ef (46) police: cir 128000 bps, bc 32000 bytes conformed 0 packets, 0 bytes; actions: set-mpls-exp-topmost-transmit 5 exceeded 0 packets, 0 bytes; actions: drop conformed 0 bps, exceed 0 bps Class-map: BUSINESS-IP (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip dscp af21 (18) af22 (20) af23 (22) police: cir 512000 bps, bc 128000 bytes conformed 0 packets, 0 bytes; actions: set-mpls-exp-topmost-transmit 2 exceeded 0 packets, 0 bytes; actions: set-mpls-exp-topmost-transmit 1 conformed 0 bps, exceed 0 bps Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any QoS Set mpls experimental imposition 0 Packets marked 0 PE1#show policy-map interface serial1/2 Serial1/2 Service-policy output: OUT-POLICY Class-map: PREMIUM-MPLS (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: mpls experimental topmost 5 Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 5 (%) Bandwidth 77 (kbps) Burst 1925 (Bytes) (pkts matched/bytes matched) 0/0 (total drops/bytes drops) 0/0


29/10/2012 14:57:50

192 Redes MPLS Class-map: BUSINESS-MPLS (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: mpls experimental topmost 1 2 Queueing Output Queue: Conversation 265 Bandwidth 50 (%) Bandwidth 772 (kbps)Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 Class-map: class-default (match-any) 358 packets, 130625 bytes 5 minute offered rate 1000 bps, drop rate 0 bps Match: any Queueing Flow Based Fair Queueing Maximum Number of Hashed Queues 256 (total queued/total drops/no-buffer drops) 0/0/0 exponential weight: 9 class 0 1 2 3 4 5 6 7 rsvp

Transmitted pkts/bytes 143/99866 0/0 0/0 0/0 0/0 0/0 162/10363 0/0 0/0

Random drop pkts/bytes 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0

Tail drop Minimum pkts/bytes thresh 0/0 20 0/0 22 0/0 24 0/0 26 0/0 28 0/0 30 0/0 32 0/0 34 0/0 36

Maximum thresh 40 40 40 40 40 40 40 40 40

Mark prob 1/10 1/10 1/10 1/10 1/10 1/10 1/10 1/10 1/10

Visualização e testes: Inicialmente, podemos confirmar se o tráfego de fato está caindo na classe correta. Para isso iremos fazer a marcação no CE11 em direção ao CE22 e confirmar o resultado. Primeiramente, geraremos um tráfego pertencente à classe PREMIUM-IP marcando o pacote no CE11 como DSCP EF (ToS = 0xB8). CE11#ping Protocol [ip]: Target IP address: 200.2.0.2 Repeat count [5]: 50 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 200.1.0.1 Type of service [0]: 0xB8


29/10/2012 14:57:50


Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 50, 100-byte ICMP Echos to 200.2.0.2, timeout is 2 seconds: Packet sent with a source address of 200.1.0.1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (50/50), round-trip min/avg/max = 140/236/376 ms PE1#show policy-map interface serial1/0.101 Serial1/0.101 Service-policy input: IN-POLICY Class-map: PREMIUM-IP (match-all) 50 packets, 5200 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip dscp ef (46) police: cir 128000 bps, bc 32000 bytes conformed 50 packets, 5200 bytes; actions: set-mpls-exp-topmost-transmit 5 exceeded 0 packets, 0 bytes; actions: drop conformed 0 bps, exceed 0 bps Class-map: BUSINESS-IP (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip dscp af21 (18) af22 (20) af23 (22) police: cir 512000 bps, bc 128000 bytes conformed 0 packets, 0 bytes; actions: set-mpls-exp-topmost-transmit 2 exceeded 0 packets, 0 bytes; actions: set-mpls-exp-topmost-transmit 1 conformed 0 bps, exceed 0 bps

Observamos que, como esperado, o tráfego gerado no CE11 marcado como EF (0xB8) de fato está caindo na classe PREMIUM-IP. Podemos notar também que, como o tráfego gerado foi abaixo do tráfego de admissão definido (128 Kbps), nada foi descartado pela política de admissão. A partir do CE11, iremos gerar um tráfego mais intenso, marcado com EF (0xB8), para verificação do tráfego em não conformidade com a política de admissão.


29/10/2012 14:57:50

194 Redes MPLS CE11#ping Protocol [ip]: Target IP address: 200.2.0.2 Repeat count [5]: 100 Datagram size [100]: 10000 Timeout in seconds [2]: 0 Extended commands [n]: y Source address or interface: 200.1.0.1 Type of service [0]: 0xB8 Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 100, 10000-byte ICMP Echos to 200.2.0.2, timeout is 0 seconds: Packet sent with a source address of 200.1.0.1 ...................................................................... .............................. Success rate is 0 percent (0/100) PE1#show policy-map interface serial1/0.101 Service-policy input: IN-POLICY Class-map: PREMIUM-IP (match-all) 85 packets, 124420 bytes 5 minute offered rate 17000 bps, drop rate 4000 bps Match: ip dscp ef (46) police: cir 128000 bps, bc 32000 bytes conformed 28 packets, 40592 bytes; actions: set-mpls-exp-topmost-transmit 5 exceeded 57 packets, 83828 bytes; actions: drop conformed 2000 bps, exceed 4000 bps Class-map: BUSINESS-IP (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip dscp af21 (18) af22 (20) af23 (22) police: cir 512000 bps, bc 128000 bytes conformed 0 packets, 0 bytes; actions: set-mpls-exp-topmost-transmit 2 exceeded 0 packets, 0 bytes; actions: set-mpls-exp-topmost-transmit 1 conformed 0 bps, exceed 0 bps

Nesse caso, podemos observar pela saída do comando efetuado no PE1 anterior que alguns pacotes foram descartados, já que foi ultrapassado o limite admitido na definição do controle de admissão à rede, o que garante a funcionalidade do PE1.


29/10/2012 14:57:50


Vejamos também a constatação dos pacotes na classe business-ip, marcando o pacote com AF21 (ToS = 0x48) no CE11. CE11#ping Protocol [ip]: Target IP address: 200.2.0.2 Repeat count [5]: 50 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 200.1.0.1 Type of service [0]: 0x48 Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 50, 100-byte ICMP Echos to 200.2.0.2, timeout is 2 seconds: Packet sent with a source address of 200.1.0.1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (50/50), round-trip min/avg/max = 168/241/360 ms PE1#show policy-map interface serial1/0.101 Serial1/0.101 Service-policy input: IN-POLICY Class-map: PREMIUM-IP (match-all) 50 packets, 5200 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip dscp ef (46) police: cir 128000 bps, bc 32000 bytes conformed 50 packets, 5200 bytes; actions: set-mpls-exp-topmost-transmit 5 exceeded 0 packets, 0 bytes; actions: drop conformed 0 bps, exceed 0 bps Class-map: BUSINESS-IP (match-all) 50 packets, 5200 bytes 5 minute offered rate 1000 bps, drop rate 0 bps Match: ip dscp af21 (18) af22 (20) af23 (22) police: cir 512000 bps, bc 128000 bytes conformed 50 packets, 5200 bytes; actions: set-mpls-exp-topmost-transmit 2 exceeded 0 packets, 0 bytes; actions: set-mpls-exp-topmost-transmit 1 conformed 1000 bps, exceed 0 bps


29/10/2012 14:57:50

196 Redes MPLS

Analisando o tráfego agora na saída do PE1 para o P1, podemos observar também que os pacotes marcados como EF no CE11, por exemplo, estão caindo na classe correta, conforme segue: CE11#ping Protocol [ip]: Target IP address: 200.2.0.2 Repeat count [5]: 10 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 200.1.0.1 Type of service [0]: 0xB8 Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 200.2.0.2, timeout is 2 seconds: Packet sent with a source address of 200.1.0.1 !!!!!!!!!! PE1#show policy-map interface se 1/2 Serial1/2 Service-policy output: OUT-POLICY Class-map: PREMIUM-MPLS (match-all) 10 packets, 1080 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: mpls experimental topmost 5 Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 5 (%) Bandwidth 77 (kbps) Burst 1925 (Bytes) (pkts matched/bytes matched) 1/108 (total drops/bytes drops) 0/0 Class-map: BUSINESS-MPLS (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: mpls experimental topmost 1 2 Queueing Output Queue: Conversation 265 Bandwidth 50 (%) Bandwidth 772 (kbps)Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0


29/10/2012 14:57:50


A mesma conduta ocorre quando marcamos os pacotes com AF21, AF22 ou AF24 no CE11. Analisando o tráfego agora na saída do P1 para o P2, podemos observar também que os pacotes marcados como EF no CE11, por exemplo, estão caindo na classe correta, conforme segue: CE11#ping Protocol [ip]: Target IP address: 200.2.0.2 Repeat count [5]: 10 Datagram size [100]: Timeout in seconds [2]: y % A decimal number between 0 and 3600. Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 200.1.0.1 Type of service [0]: 0xB8 Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 200.2.0.2, timeout is 2 seconds: Packet sent with a source address of 200.1.0.1 !!!!!!!!!! Success rate is 100 percent (10/10), round-trip min/avg/max = 156/222/292 ms P2#show policy-map interface serial1/1 Serial1/1 Service-policy output: OUT-POLICY Class-map: PREMIUM-MPLS (match-all) 50 packets, 5400 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: mpls experimental topmost 5 Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 5 (%) Bandwidth 77 (kbps) Burst 1925 (Bytes) (pkts matched/bytes matched) 2/216 (total drops/bytes drops) 0/0 Class-map: BUSINESS-MPLS (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: mpls experimental topmost 1 2 Queueing Output Queue: Conversation 265 Bandwidth 50 (%)


29/10/2012 14:57:50

198 Redes MPLS Bandwidth 772 (kbps)Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0

Analisando o tráfego agora na saída do P2 para o PE2, podemos observar também que os pacotes marcados como EF (0xB8) no CE11, por exemplo, estão caindo na classe correta. CE11#ping Protocol [ip]: Target IP address: 200.2.0.2 Repeat count [5]: 50 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 200.1.0.1 Type of service [0]: 0xB8 Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 50, 100-byte ICMP Echos to 200.2.0.2, timeout is 2 seconds: Packet sent with a source address of 200.1.0.1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (50/50), round-trip min/avg/max = 160/258/404 ms P2#show policy-map interface serial1/1 Serial1/1 Service-policy output: OUT-POLICY Class-map: PREMIUM-MPLS (match-all) 50 packets, 5400 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: mpls experimental topmost 5 Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 5 (%) Bandwidth 77 (kbps) Burst 1925 (Bytes) (pkts matched/bytes matched) 2/216 (total drops/bytes drops) 0/0 Class-map: BUSINESS-MPLS (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: mpls experimental topmost 1 2 Queueing Output Queue: Conversation 265


29/10/2012 14:57:50


Bandwidth 50 (%) Bandwidth 772 (kbps)Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0

Observação: para que os pacotes fossem marcados em EXP na saída do P2, inserimos o comando “mpls ldp explicit-null” em PE2, evitando que o label fosse retirado no P2 (implicit-null) e as marcações em EXP não fossem possíveis.

Analisando o tráfego agora na saída do PE2 para o CE22, podemos observar que os pacotes marcados como EF no CE11, por exemplo, estão caindo na classe correta, conforme segue: CE11#ping Protocol [ip]: Target IP address: 200.2.0.2 Repeat count [5]: 50 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 200.1.0.1 Type of service [0]: 0xB8 Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 50, 100-byte ICMP Echos to 200.2.0.2, timeout is 2 seconds: Packet sent with a source address of 200.1.0.1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (50/50), round-trip min/avg/max = 140/222/412 ms


29/10/2012 14:57:51

200 Redes MPLS PE2#sh policy-map interface serial1/1 Service-policy output: IP-OUT Class-map: PREMIUM-IP (match-all) 50 packets, 5200 bytes 5 minute offered rate 1000 bps, drop rate 0 bps Match: ip dscp ef (46) Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 50 (%) Bandwidth 772 (kbps) Burst 19300 (Bytes) (pkts matched/bytes matched) 0/0 (total drops/bytes drops) 0/0 Class-map: BUSINESS-IP (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip dscp af21 (18) af22 (20) af23 (22) Queueing Output Queue: Conversation 265 Bandwidth 25 (%) Bandwidth 386 (kbps)Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0


29/10/2012 14:57:51

APÊNDICE E. Configurações – Engenharia de Tráfego

Configurações dos roteadores de núcleo para a simulação do MPLS TE: PE1# mpls traffic-eng tunnels interface Tunnel0 ip unnumbered Loopback0 tunnel destination 172.2.0.1 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng bandwidth 100 tunnel mpls traffic-eng path-option 1 explicit name PE1-P1-PE2 no routing dynamic interface Tunnel1 ip unnumbered Loopback0 tunnel destination 172.2.0.1 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 2 2 tunnel mpls traffic-eng bandwidth 100 tunnel mpls traffic-eng path-option 1 explicit name PE1-P2-PE2 no routing dynamic router isis net 49.0172.0001.0000.0001.00 is-type level-2-only metric-style wide mpls traffic-eng router-id Loopback0 mpls traffic-eng level-2 interface Serial1/2 mpls traffic-eng tunnels ip rsvp bandwidth 256 256 interface Serial1/3 mpls traffic-eng tunnels ip rsvp bandwidth 256 256

201


29/10/2012 14:57:51

202 Redes MPLS ip explicit-path name PE1-P1-PE2 enable next-address 192.168.0.14 next-address 192.168.0.21 next-address 172.2.0.1 ip explicit-path name PE1-P2-PE2 enable next-address 192.168.0.18 next-address 192.168.0.25 next-address 172.2.0.1 P1# mpls traffic-eng tunnels interface Serial1/0 ip rsvp bandwidth 256 256 mpls traffic-eng tunnels interface Serial1/1 ip rsvp bandwidth 256 256 mpls traffic-eng tunnels interface Serial1/2 ip rsvp bandwidth 256 256 mpls traffic-eng tunnels router isis net 49.0172.0010.0000.0001.00 is-type level-2-only metric-style wide mpls traffic-eng router-id Loopback0 mpls traffic-eng level-2 P2# mpls traffic-eng tunnels interface Serial1/0 ip rsvp bandwidth 256 256 mpls traffic-eng tunnels interface Serial1/1 ip rsvp bandwidth 256 256 mpls traffic-eng tunnels interface Serial1/2 ip rsvp bandwidth 256 256 mpls traffic-eng tunnels router isis net 49.0172.0020.0000.0001.00 is-type level-2-only metric-style wide mpls traffic-eng router-id Loopback0 mpls traffic-eng level-2


29/10/2012 14:57:51

Configurações – Engenharia de Tráfego 203

PE2# mpls traffic-eng tunnels interface Serial1/2 ip rsvp bandwidth 256 256 mpls traffic-eng tunnels interface Serial1/3 ip rsvp bandwidth 256 256 mpls traffic-eng tunnels router isis net 49.0172.0002.0000.0001.00 is-type level-2-only metric-style wide mpls traffic-eng router-id Loopback0 mpls traffic-eng level-2

Configuração do terceiro túnel (túnel 2), criado com reserva de banda de 50 Kbps: PE1# interface Tunnel2 ip unnumbered Loopback0 tunnel destination 172.2.0.1 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 3 3 tunnel mpls traffic-eng bandwidth 50 tunnel mpls traffic-eng path-option 1 explicit name PE1-P1-P2-PE2 no routing dynamic ip explicit-path name PE1-P1-P2-PE2 enable next-address 192.168.0.14 next-address 192.168.0.30 next-address 192.168.0.25 next-address 172.2.0.1

Podemos visualizar a informação do RSVP que foi configurada com o comando a seguir, efetuado no roteador PE1: PE1#show ip rsvp interface interface allocated i/f max Se1/2 100K 256K Se1/3 100K 256K


flow max sub max 256K 0 256K 0

29/10/2012 14:57:51

204 Redes MPLS

Para verificarmos o status dos túneis criados, segue o comando: PE1#show mpls traffic-eng tunnels brief Signalling Summary: LSP Tunnels Process: running RSVP Process: running Forwarding: enabled Periodic reoptimization: every 3600 seconds, next in 2462 seconds Periodic auto-bw collection: disabled TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT PE1_t0 172.2.0.1 Se1/2 up/up PE1_t1 172.2.0.1 Se1/3 up/up Displayed 2 (of 2) heads, 0 (of 0) midpoints, 0 (of 0) tails

Os parâmetros utilizados pelos túneis podem ser vistos com o comando a seguir, efetuados no PE1. Nesse comando, além dos parâmetros utilizados pelos túneis, podemos perceber também os caminhos tomados – nesse caso, o túnel 0 fará uso do caminho PE1 à P1 à PE2, obtido automaticamente, e o túnel 1 fará uso do caminho PE1 à P2 à PE2, definido de forma explícita. PE1#show mpls traffic-eng tunnels destination 172.2.0.1 Name: PE1_t0 (Tunnel0) Destination: 172.2.0.1 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 20) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 1 1 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: disabled InLabel : OutLabel : Serial1/2, 16 RSVP Signalling Info: Src 172.1.0.1, Dst 172.2.0.1, Tun_Id 0, Tun_Instance 9 RSVP Path Info: My Address: 172.1.0.1 Explicit Route: 192.168.0.14 192.168.0.21 172.2.0.1 Record Route: NONE Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: NONE Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits History: Tunnel: Time since created: 39 minutes, 33 seconds Time since path change: 38 minutes, 47 seconds Current LSP: Uptime: 38 minutes, 49 seconds


29/10/2012 14:57:51


Name: PE1_t1 Status: Admin: up

(Tunnel1) Destination: 172.2.0.1 Oper: up

Path: valid

Signalling: connected

path option 1, type explicit PE1-P2-PE2 (Basis for Setup, path weight 20) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 2 2 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: disabled InLabel : OutLabel : Serial1/3, 16 RSVP Signalling Info: Src 172.1.0.1, Dst 172.2.0.1, Tun_Id 1, Tun_Instance 13 RSVP Path Info: My Address: 172.1.0.1 Explicit Route: 192.168.0.18 192.168.0.25 172.2.0.1 Record Route: NONE Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: NONE Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits

Após criação do terceiro túnel, vejamos as saídas dos comandos a seguir: PE1#show ip rsvp interface interface allocated i/f max Se1/2 150K 256K Se1/3 100K 256K

flow max sub max 256K 0 256K 0

PE1#show mpls traffic-eng tunnels brief Signalling Summary: LSP Tunnels Process: running RSVP Process: running enabled Forwarding: Periodic reoptimization: every 3600 seconds, next in 2629 seconds Periodic auto-bw collection: disabled TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT 172.2.0.1 PE1_t0 Se1/2 up/up PE1_t1 172.2.0.1 Se1/3 up/up PE1_t2 172.2.0.1 Se1/2 up/up Displayed 3 (of 3) heads, 0 (of 0) midpoints, 0 (of 0) tails


29/10/2012 14:57:52

206 Redes MPLS

A partir do PE1, podemos perceber, através da sua tabela de rotas para o endereço 172.2.0.1 (loopback do PE2), que o balanceamento de carga está ocorrendo, sendo o túnel o próximo salto. PE1#show ip route 172.2.0.1 Routing entry for 172.2.0.1/32 Known via “isis”, distance 115, metric 30, type level-2 Redistributing via isis Last update from 172.2.0.1 on Tunnel1, 01:50:21 ago Routing Descriptor Blocks: * 172.2.0.1, from 172.2.0.1, via Tunnel0 Route metric is 30, traffic share count is 1 172.2.0.1, from 172.2.0.1, via Tunnel1 Route metric is 30, traffic share count is 1

Através do comando “ping”, partindo do PE1 com destino ao loopback0 do PE2, podemos visualizar que os pacotes são balanceados igualmente através dos dois túneis. Isso ocorre porque os túneis foram configurados com os mesmos parâmetros. PE1#ping Protocol [ip]: Target IP address: 172.2.0.1 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 172.1.0.1 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: r Number of hops [ 9 ]: 4 Loose, Strict, Record, Timestamp, Verbose[RV]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.2.0.1, timeout is 2 seconds: Packet sent with a source address of 172.1.0.1 Packet has IP options: Total option bytes= 19, padded length=20 Record route: <*> Reply to request 0 (284 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (172.2.0.1) (192.168.0.21) (192.168.0.14) (172.1.0.1) <*> End of list


29/10/2012 14:57:52


Reply to request 1 (236 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (172.2.0.1) (192.168.0.25) (192.168.0.18) (172.1.0.1) <*> End of list PE1#traceroute 172.2.0.1 source 172.1.0.1 Type escape sequence to abort. Tracing the route to 172.2.0.1 1 192.168.0.14 192.168.0.18 192.168.0.14 2 192.168.0.25 192.168.0.21

[MPLS: Label 16 Exp 0] 152 msec [MPLS: Label 16 Exp 0] 192 msec [MPLS: Label 16 Exp 0] 60 msec 120 msec 120 msec *

Vejamos como se comporta o backbone em caso de queda de um dos túneis. Para isso iremos efetuar um shutdown na interface S1/3 do PE1, simulando uma queda no enlace entre PE1 e P2, deixando o túnel 1 inativo. PE1(config)#int s 1/3 PE1(config-if)#shutdown PE1#sh int tunnel 1 Tunnel1 is up, line protocol is down PE1#show ip route 172.2.0.1 Routing entry for 172.2.0.1/32 Known via “isis”, distance 115, metric 30, type level-2 Redistributing via isis Last update from 172.2.0.1 on Tunnel0, 00:01:41 ago Routing Descriptor Blocks: * 172.2.0.1, from 172.2.0.1, via Tunnel0 Route metric is 30, traffic share count is 1 PE1#traceroute 172.2.0.1 source 172.1.0.1 Type escape sequence to abort. Tracing the route to 172.2.0.1 1 192.168.0.14 [MPLS: Label 16 Exp 0] 16 msec 188 msec 192 msec 2 192.168.0.21 172 msec * 116 msec

Nesse caso, todo o tráfego será escoado através do túnel 0, garantindo a redundância. O mesmo ocorre caso o túnel 0 seja desconectado.


29/10/2012 14:57:52

208 Redes MPLS

Após criação do terceiro túnel (túnel 2), vejamos como fica a entrada na tabela de roteamento do roteador PE1 para 172.2.0.1/32. PE1#show ip route 172.2.0.1 Routing entry for 172.2.0.1/32 Known via “isis”, distance 115, metric 30, type level-2 Redistributing via isis Last update from 172.2.0.1 on Tunnel2, 00:27:56 ago Routing Descriptor Blocks: * 172.2.0.1, from 172.2.0.1, via Tunnel0 Route metric is 30, traffic share count is 2 172.2.0.1, from 172.2.0.1, via Tunnel1 Route metric is 30, traffic share count is 2 172.2.0.1, from 172.2.0.1, via Tunnel2 Route metric is 30, traffic share count is 1

Nesse caso, a cada cinco pacotes enviados, o balanceamento de carga é realizado de forma que dois pacotes sejam enviados pelo túnel 0, dois pacotes, pelo túnel 1 e um pacote, pelo túnel 2. Logo, o balanceamento de carga a custos desiguais ocorre entre os três túneis. Observamos, assim, que a proporção de pacotes ou fluxos enviados para cada túnel será proporcional à razão da banda alocada entre eles. PE1#traceroute 172.2.0.1 source 172.1.0.1 Type escape sequence to abort. Tracing the route to 172.2.0.1 1 192.168.0.18 192.168.0.14 192.168.0.18 2 192.168.0.21 192.168.0.25 192.168.0.30


[MPLS: Label [MPLS: Label [MPLS: Label 456 msec 92 msec [MPLS: Label

16 Exp 0] 124 msec 16 Exp 0] 248 msec 16 Exp 0] 156 msec 22 Exp 0] 92 msec

29/10/2012 14:57:52

APÊNDICE F. Configurações – IPv6

Para o 6PE: Seguem-se as configurações finais dos roteadores CE11, CE22, PE1, PE2, P1 e P2. hostname CE11 ip cef ipv6 unicast-routing ipv6 cef interface Loopback0 ip address 200.1.0.1 255.255.255.255 ipv6 address 2012:100::1/128 ipv6 rip RIP enable interface Serial1/0 description Connected to PE1 no ip address ipv6 address 2012:11::2/64 ipv6 rip RIP enable ipv6 router rip RIP hostname CE22 ip cef ipv6 unicast-routing ipv6 cef interface Loopback0 ip address 200.2.0.2 255.255.255.255 ipv6 address 2012:200::1/128 ipv6 rip RIP enable interface Serial1/0 description Connected to PE2 no ip address ipv6 address 2012:22::2/64

209


29/10/2012 14:57:52

210 Redes MPLS ipv6 rip RIP enable ipv6 router rip RIP hostname PE1 ip cef ipv6 ipv6 mpls mpls

unicast-routing cef label protocol ldp ipv6 source-interface Loopback0

interface Loopback0 ip address 172.1.0.1 255.255.255.255 ip router isis interface Serial1/0 no ip address ipv6 address 2012:11::1/64 ipv6 enable ipv6 rip RIP enable interface Serial1/2 ip address 192.168.0.13 255.255.255.252 ip router isis mpls ip interface Serial1/3 ip address 192.168.0.17 255.255.255.252 ip router isis mpls ip router isis net 49.0172.0001.0000.0001.00 is-type level-2-only router bgp 65500 no synchronization bgp log-neighbor-changes neighbor 172.2.0.1 remote-as 65000 neighbor 172.2.0.1 update-source Loopback0 no auto-summary address-family ipv6 neighbor 172.2.0.1 activate neighbor 172.2.0.1 send-community both neighbor 172.2.0.1 send-label redistribute connected redistribute rip RIP no synchronization exit-address-family ipv6 router rip RIP redistribute bgp 65500


29/10/2012 14:57:52

Configurações – IPv6 211

hostname PE2 ip cef ipv6 ipv6 mpls mpls

unicast-routing cef label protocol ldp ipv6 source-interface Loopback0

interface Loopback0 ip address 172.2.0.1 255.255.255.255 ip router isis interface Serial1/1 no ip address ipv6 address 2012:22::1/64 ipv6 enable ipv6 rip RIP enable interface Serial1/2 ip address 192.168.0.21 255.255.255.252 ip router isis mpls ip interface Serial1/3 ip address 192.168.0.25 255.255.255.252 ip router isis mpls ip router isis net 49.0172.0002.0000.0001.00 is-type level-2-only router bgp 65500 no synchronization bgp log-neighbor-changes neighbor 172.1.0.1 remote-as 65000 neighbor 172.1.0.1 update-source Loopback0 no auto-summary address-family ipv6 neighbor 172.1.0.1 activate neighbor 172.1.0.1 send-community both neighbor 172.1.0.1 send-label redistribute connected redistribute rip RIP no synchronization exit-address-family ipv6 router rip RIP redistribute bgp 65500


29/10/2012 14:57:52

212 Redes MPLS hostname P1 ip cef mpls label protocol ldp interface Loopback0 ip address 172.10.0.1 255.255.255.255 ip router isis interface Serial1/0 ip address 192.168.0.14 255.255.255.252 ip router isis mpls ip interface Serial1/1 ip address 192.168.0.22 255.255.255.252 ip router isis mpls ip interface Serial1/2 ip address 192.168.0.29 255.255.255.252 ip router isis mpls ip router isis net 49.0172.0010.0000.0001.00 is-type level-2-only mpls ldp router-id Loopback0 hostname P2 ip cef mpls label protocol ldp interface Loopback0 ip address 172.20.0.1 255.255.255.255 ip router isis interface Serial1/0 ip address 192.168.0.18 255.255.255.252 ip router isis mpls ip interface Serial1/1 ip address 192.168.0.26 255.255.255.252 ip router isis mpls ip


29/10/2012 14:57:52


interface Serial1/2 ip address 192.168.0.30 255.255.255.252 ip router isis mpls ip router isis net 49.0172.0020.0000.0001.00 is-type level-2-only mpls ldp router-id Loopback0

Para o 6VPE: hostname CE11 ip cef ipv6 unicast-routing interface Loopback0 ip address 200.1.0.1 255.255.255.255 ipv6 address 2012:100::1/128 interface Serial1/0 description Connected to PE1 ip address 150.1.1.2 255.255.255.252 ipv6 address 2012:11::2/64 serial restart-delay 0 router bgp 10 bgp log-neighbor-changes neighbor 2012:11::1 remote-as 65500 address-family ipv4 no neighbor 2012:11::1 activate no auto-summary no synchronization exit-address-family address-family ipv6 neighbor 2012:11::1 activate network 2012:100::1/128 exit-address-family hostname CE22 ip cef ipv6 unicast-routing interface Loopback0 ip address 200.2.0.2 255.255.255.255


29/10/2012 14:57:53

214 Redes MPLS ipv6 address 2012:200::1/128 interface Serial1/0 description Connected to PE2 ip address 150.1.2.2 255.255.255.252 ipv6 address 2012:22::2/64 serial restart-delay 0 router bgp 20 no synchronization bgp log-neighbor-changes neighbor 2012:22::1 remote-as 65500 no auto-summary address-family ipv6 neighbor 2012:22::1 activate network 2012:200::1/128 exit-address-family hostname PE1 vrf definition VPN_A rd 65500:1 address-family ipv6 route-target export 65500:1 route-target import 65500:1 exit-address-family ip cef ipv6 unicast-routing ipv6 cef mpls label protocol ldp interface Loopback0 ip address 172.1.0.1 255.255.255.255 ip router isis interface Serial1/0 description Connected to CE11 vrf forwarding VPN_A ip address 150.1.1.1 255.255.255.252 ipv6 address 2012:11::1/64 interface Serial1/2 ip address 192.168.0.13 255.255.255.252 ip router isis mpls ip interface Serial1/3 ip address 192.168.0.17 255.255.255.252 ip router isis mpls ip


29/10/2012 14:57:53


router isis net 49.0172.0001.0000.0001.00 is-type level-2-only router bgp 65500 bgp log-neighbor-changes neighbor 172.2.0.1 remote-as 65500 neighbor 172.2.0.1 update-source Loopback0 address-family ipv4 no neighbor 172.2.0.1 activate no auto-summary no synchronization exit-address-family address-family vpnv6 neighbor 172.2.0.1 activate neighbor 172.2.0.1 send-community both exit-address-family address-family ipv6 vrf VPN_A neighbor 2012:11::2 remote-as 10 neighbor 2012:11::2 activate neighbor 2012:11::2 as-override redistribute connected no synchronization exit-address-family mpls ldp router-id Loopback0 force hostname PE2 vrf definition VPN_A rd 65500:1 address-family ipv6 route-target export 65500:1 route-target import 65500:1 exit-address-family ip cef ipv6 unicast-routing ipv6 cef mpls label protocol ldp interface Loopback0 ip address 172.2.0.1 255.255.255.255 ip router isis interface Serial1/1 description Connected to CE22 vrf forwarding VPN_A


29/10/2012 14:57:53

216 Redes MPLS ip address 150.1.2.1 255.255.255.252 ipv6 address 2012:22::1/64 interface Serial1/2 ip address 192.168.0.21 255.255.255.252 ip router isis mpls ip interface Serial1/3 ip address 192.168.0.25 255.255.255.252 ip router isis mpls ip serial restart-delay 0 router isis net 49.0172.0002.0000.0001.00 is-type level-2-only router bgp 65500 bgp log-neighbor-changes neighbor 2012:22::2 remote-as 20 neighbor 172.1.0.1 remote-as 65500 neighbor 172.1.0.1 update-source Loopback0 address-family ipv4 no neighbor 172.1.0.1 activate no auto-summary no synchronization exit-address-family address-family vpnv6 neighbor 172.1.0.1 activate neighbor 172.1.0.1 send-community both exit-address-family address-family ipv6 vrf VPN_A neighbor 2012:22::2 remote-as 20 neighbor 2012:22::2 activate neighbor 2012:22::2 as-override redistribute connected no synchronization exit-address-family mpls ldp router-id Loopback0 force hostname P1 ip cef mpls label protocol ldp interface Loopback0 ip address 172.10.0.1 255.255.255.255 ip router isis


29/10/2012 14:57:53


interface Serial1/0 ip address 192.168.0.14 255.255.255.252 ip router isis mpls ip interface Serial1/1 ip address 192.168.0.22 255.255.255.252 ip router isis mpls ip interface Serial1/2 ip address 192.168.0.29 255.255.255.252 ip router isis mpls ip router isis net 49.0172.0010.0000.0001.00 is-type level-2-only mpls ldp router-id Loopback0 hostname P2 ip cef mpls label protocol ldp interface Loopback0 ip address 172.20.0.1 255.255.255.255 ip router isis interface Serial1/0 ip address 192.168.0.18 255.255.255.252 ip router isis mpls ip interface Serial1/1 ip address 192.168.0.26 255.255.255.252 ip router isis mpls ip interface Serial1/2 ip address 192.168.0.30 255.255.255.252 ip router isis mpls ip router isis net 49.0172.0020.0000.0001.00 is-type level-2-only mpls ldp router-id Loopback0


29/10/2012 14:57:53

Índice Remissivo

6PE XIV, 104, 161, 162, 163, 210 6VPE XIV, 103, 105, 106, 161, 162, 164, 214

A acknowledgement 5 alcançabilidade 24, 104 algoritmo de Dijkstra 22 Anycast 101 ARIS – Aggregate Route-based IP Switching 26 armazenamento de rota 11 arquitetura de Serviços Diferenciados (DiffServ) 67 Arquitetura de Serviços Diferenciados (DiffServ) 65 arquitetura de Serviços Integrados (IntServ) 65 Arquitetura MPLS VPN XIV, 51 AS (Autonomous System) 15, 53 ASICs (Aplication Specific Integrated Circuits) 41 ASON (Automatically Switched Optical Network) 95 ATM IX, 1, 2, 25, 26, 27, 29, 31, 37, 41, 42, 46, 48, 50, 58, 59, 61, 92, 110, 116, 124, 144, 151, 160 atraso (delay) 64, 65, 160 Atributos de túneis 93

B Bellman-Ford 16 best-effort 64 BGP IX, XIII, XV, 16, 20, 21, 24, 33, 36, 44, 48, 53, 54, 55, 56, 102, 104, 105, 107, 113, 114, 115, 117, 118, 121, 122, 124, 134, 135, 136, 137, 138, 139, 142, 144, 161, 162, 180, 183, 185 BGP Externo (eBGP) 56 BoS (Bottom of Stack) 30 broadcast 101 Business 146, 196

C cabeçalho IP 11, 13, 28, 30, 68, 79, 81, 82, 97, 99, 100, 151

cabeçalho MPLS 25, 28, 29, 30, 31, 40, 41, 124 cabeçalhos de calço (shim) 116 CE – Customer Edge 51 CEF IX, 117 cell-mode 115, 116 CIDR (Classless Inter-Domain Routing) 113 circuito de acesso (AC) 61 Circuito de Acesso (AC) 60 circuito ponto-a-ponto 47, 58 Circuitos Virtuais Privados (PVCs) 48 circuito virtual 37, 41, 48, 61, 62, 128 Circuito Virtual 60 Cisco Express Forwarding IX, 117 Classe AF (Assured Forwarding) 69 Classe EF (Expedited Forwarding) 69 classes de serviços 30, 71, 72, 100, 145, 149 classes de tráfegos 64 classful 16 classificação 37, 71, 73, 75, 81, 145 Classificação 71, 146 Classificador de pacotes 66, 68 classless 16 class map 146 Class Selector Codepoints 70 comutação 1, 13, 14, 15, 86 Comutação XIII, 12, 60 comutação de rótulos 14, 15, 28, 32, 52, 86, 87, 92, 95, 103 comutação IP 25, 26 comutador Ethernet 109 conexão 5, 21, 22, 24, 42, 44, 50, 60, 61, 66, 94, 104, 125, 126, 128, 130, 132, 133, 142, 145, 155 confiabilidade 1, 8, 12, 24 congestionamento 8, 12, 15, 64, 66, 69, 71, 73, 77, 78, 79, 80, 86, 88, 150 Congestion Avoidance 79, 80 Construção das tabelas de roteamento 38 Controle de admissão 66 Controle de fila 73 controle de fluxo 5 control plane 119, 120

219


29/10/2012 14:57:53

220 Redes MPLS correção de erro 5 CQ (Custom Queuing) 75, 76 criptografia 43 CSPF IX, 22, 151, 153 CSR – Cell Switched Router 26 Custom Queuing 75

D Dados (payload) 12 datagrama 6, 7, 8, 9, 10, 11, 12, 13, 26, 27, 29, 30, 37, 98 descarte total (tail drop) 79 DiffServ IX, XIV, 8, 36, 65, 67, 68, 69, 70, 78, 83 DLCI IX, 29, 130, 132 domínio de roteamento 20 DSCP IX, 36, 68, 69, 70, 71, 72, 80, 81, 82, 83, 145 DS (Differentiated Service) 69 dual-stack 103, 106 Dynagem 109 Dynamips 109

E ECMP (Equal-Cost Multi-Path) 22 Edge LSRs 37, 40 EGP (Exterior Gateway Protocol) 16, 24, 104 EIGRP (Enhanced Interior Gateway Routing Protocol) 18 encaminhamento dos pacotes na rede 41 Encaminhamento dos pacotes na rede 39 Endereçamento IPv6 101 enfileiramento 30, 73 Enfileiramento 73, 74, 76 Enfileiramento com baixa latência 76 Enfileiramento com prioridade 73, 74, 76 Enfileiramento customizado 76 Enfileiramento justo 74, 75, 76 engenharia de tráfego 1, 41, 42, 85, 86, 87, 88, 89, 90, 91, 92, 94, 95, 113, 153, 156, 157, 160, 176 Engenharia de tráfego 151 Engenharia de Tráfego XIV, XV, 3, 43, 85, 202 Enhanced Interior Gateway Protocol (EIGRP) 16 escalabilidade 20, 36, 41, 42, 50, 51, 54, 67, 97, 112, 113 Escalonador de pacotes 65 estado de enlace (link state) 16 Ethernet 31, 32, 46, 58, 59, 61, 72, 109, 124, 125 excesso de tráfego 73 EXP (Experimental Bits) 30

F Fair Queuing IX, X, XII, 74, 76 Fast Reroute (FRR) 93


FEC (Forwarding Equivalence Class) 35 FIB (Forwarding Information Base) 35 FIFO (First-In First-Out) 73 Flag 9 fluxos TCP 79 fragmentação 8, 9, 10, 97, 99 frame-mode 115, 116, 119 Frame Relay X, 1, 2, 29, 32, 37, 46, 48, 49, 50, 58, 59, 61, 124, 125, 126, 128, 129, 130, 131, 133, 142, 144, 151, 161 Freesco 109 fronteira-a-fronteira (edge-to-edge) 60 Full Mesh 48, 50, 142, 144, 145

G G.8080 95 GigabitEthernet 109 Global Sync 79 Global Unicast 102 GMPLS XIV, 94, 95 GNS3 VII, 2, 108, 109, 110 GRE (Generic Routing Encapsulation) 48

H HDLC 59, 61, 124, 125, 126, 128, 133 head-end 87, 90, 92, 93, 94, 151, 160 heterogeneidade 6 Hub and Spoke 142, 145, 186

I IANA (Internet Assigned Numbers Authority) 15 IBGP (Interior Border Gateway Protocol) 118 ICMP (Internet Control Message Protocol) 10, 11 Identificação 9 IETF X, 8, 21, 26, 60, 65, 83, 91, 95 IGP X, XV, 3, 15, 16, 20, 21, 24, 34, 56, 62, 87, 93, 104, 112, 118, 119, 124, 152, 153, 154, 155 IGRP (Interior Gateway Routing Protocol) 17 implicit-null 120, 200 Implicit NULL Label 30 inanição (starvation) 74 infraestrutura da rede 15 Ingresso dos pacotes na rede 38 inner label 62, 115 Interior Gateway Protocol (IGP) 56 Intermediate System to Intermediate System X, 91, 102, 112 IntServ XIV, 65, 67, 92 inundação (flooding) 19 IP DiffServ Code Point (DSCP) 36 IP (Internet Protocol) 1, 5 IP Navigator 26

29/10/2012 14:57:54

Índice Remissivo 221

IP Precedence 29, 36, 70, 72 IPSec X, 48 IP Switching 26 IPv4 XIII, 6, 7, 8, 9, 21, 29, 53, 54, 56, 70, 72, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 113, 114, 115, 137, 161 IPv4 Explicit NULL Label 29 IPv6 VII, XIV, XV, 2, 3, 9, 12, 17, 21, 29, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 114, 161, 162, 163, 210 IPv6 Explicit NULL Label 29 IPv6 Provider Edge over MPLS 104 IPv6 VPN Provider Edge 106 IS-IS X, XIII, XIV, XV, 16, 21, 22, 23, 33, 38, 39, 91, 102, 104, 107, 112, 113, 114, 117, 119, 122, 124, 137, 144, 151, 154, 156, 162 IS-ISv6 102, 104 ISO-IDRP 16 ISO (International Organization for Standardization) 23

J jitter 64, 65, 69, 87, 90

K keepalive 75

L L2TP X, 48 label 32, 56, 62, 105, 115, 123, 124, 130, 161 Label VII, X, 1, 29, 30, 33, 34, 35, 36, 37, 39, 86, 144 LAN X, 9, 116 LDP X, 30, 34, 36, 38, 39, 50, 56, 103, 105, 126, 176 LER X, 35, 37 LFIB (Label Forwarding Information Base) 35 LIB (Label Information Base) 34 Link-Local 102 Link Protection 93 listas de acesso (access lists) 51 LLQ (Low Latency Queuing) 76 loops 17, 24, 88 loops de roteamento 17 LSA (Link State Advertisement) 18 LSP X, 18, 35, 36, 37, 40, 41, 50, 62, 84, 87, 89, 92, 151, 153, 176 LSP fim-a-fim 87, 92 LSR X, 30, 34, 35, 36, 37, 38, 39, 40, 41, 46, 81, 82, 83, 84, 90, 93, 151 LSR de Borda de Entrada 36 LSR de Borda de Saída 37 LSR (Label Switch Router) 34, 36


M marcação 71, 72, 81, 84, 145, 193 Marcação 146 mecanismos de QoS 92, 145 Mecanismos de QoS XIV, 71 melhor esforço (best-effort) 5, 64 MF (More Fragments) 10 modelo overlay 48, 50, 51 modelo par-a-par XIII, 48, 50, 51 Modelo par-a-par 50 Modelos de VPN XIII, 48 Modo de tubo curto (Short Pipe Mode) 83 Modo de tubo (Pipe Mode) 84 Modo uniforme (Uniform Mode) 83 moldagem 71, 81 Moldagem 78 Moldagem (Shaping) 78 MP-BGP 53, 54, 55, 102, 104, 105, 107, 113, 135, 137, 161 MPLS Generalizado (Generalized MPLS) 94 MPLS IP VPN 44 MPLS-TE XIV, 42, 86, 87, 88, 89, 90, 91, 92, 93, 95, 151, 152, 153, 154, 155 MTU (Maximum Transfer Unit) 9 multicast 19, 34, 97 Multicast 36, 101, 102 MultiProtocol Label Switching – Traffic Engineering 86

N next-hop 13, 34, 118, 137 NHop (Next Hop Router) 94 NNHop (Next Next Hop Router) 94 Node Protection 93 NSAP (Network Service Access Point) 112

O Offset (deslocamento) do Fragmento 10 Olive 109 Open Shortest Path First (OSPF) 16, 35 OSI (Open Systems Interconnection) 23 OSPF X, XIII, XIV, 16, 20, 21, 22, 23, 33, 35, 38, 39, 89, 90, 91, 95, 102, 104, 107, 112, 154, 162 OSPF (Open Shortest Path First) 11, 102, 112 OSPFv2 20, 21 OSPFv3 21, 102, 104 overflow 73 overlay XIII, 41, 48, 49, 50, 51

P par-a-par (peer-to-peer) 48

29/10/2012 14:57:54

222 Redes MPLS paridade 11 PDU (Protocol Data Unit) 60 PE (Provider Edge) 37, 47, 104 perda de pacotes 64, 65, 93, 146, 157 PHB (Per-Hop Behavior) 69 PHP (Penultimate Hop Popping) 40, 62, 121, 124 pilha de rótulos 38, 61, 62, 82, 84 ping 132, 140, 144, 145, 207 plano de controle 25, 32, 33, 41, 95 plano de encaminhamento 32 PLR (Point of Local Repair) 93 policiamento 33, 66, 69, 70, 71, 78, 81, 145, 150, 151 Policiamento 77 policing 149 Policing 77, 78 Policy Map 146 política de menor custo 20 POP XI, 120 POS (Packet Over SONET) 110 PPP XI, 31, 32, 59, 61, 116, 125 PPP (Point-to-Point Protocol) 31 P (Provider) 28, 40, 47, 52 PQ (Priority Queuing) 73, 74 precedência 8, 69, 73, 75, 82, 83, 84, 151 Precedência 69, 70, 81 Premium 146 problema do peixe 85 proteção 94 Proteção XIV, 93, 94 proteção local 93 Protocolo de Gateway de Borda versão 4 (BGP4) 35 protocolo de nível 3 31 protocolos 11 Protocolos XIII, 15 protocolos de nível 2 31 protocolos de roteamento 2, 5, 12, 14, 16, 17, 19, 20, 21, 22, 23, 28, 33, 35, 38, 51, 94 Protocolos de roteamento XIII, 15 protocolos TDP/LDP 50 provedores de serviço de Internet (ISPs) 43 Provider Edge (PE) 60 próximo enlace 34 PseudoWire VII, XI, XIV, XV, 3, 43, 47, 58, 59, 60, 61, 63, 125, 126, 127, 129, 177 PseudoWire End-Services (PWES) 60 PWE (PseudoWire Emulation Edge-to-Edge) 60

Q QoS VII, XI, XIV, XV, 3, 28, 39, 42, 43, 64, 65, 66, 71, 81, 82, 83, 92, 99, 145, 146, 147, 148, 150, 151, 160, 189 quadros PseudoWire 62 qualidade de serviço 1, 25, 26, 43, 66, 67, 71, 89, 90, 149, 150 Qualidade de serviço 65, 81 Qualidade de Serviço XIV, 64, 98


R R5 (Merge Point) 94 RD (Route Distinguisher) 53 rede completamente conectada (Full Mesh) 48, 50 Rede de Comutação de Pacotes (PSN) 60 rede espalhada geograficamente (WAN) 12 rede geograficamente distribuída 43 rede multisserviço 58 RED (Random Early Detection) 79 reflooding 91 reserva de recursos na rede 66, 67 retardos 90 retirada do rótulo MPLS (popping) 41 RFC 1247 20, 170 RFC 1723 17 RFC 1771 54 RFC 1883 96 RFC 2080 17 RFC 2460 97 RFC 2597 69 RFC 2598 69 RFC 2858 54 RFC 3107 44 RFC 3630 89, 90 RFC 3784 91 RFC 4203 95 RFC 4258 95 RFC 4271 20 RFC 4364 44 RFC 4760 44 RFC 5063 95 RIP XI, 16, 17, 21, 22, 33, 102, 162 RIPng (Routing Information Protocol next generation) 17, 102 RIP (Routing Information Protocol) 17, 21 RIPv2 17 rotas IPv4 53, 56 roteador CE 47, 56, 62, 122, 128, 155 roteador de borda 29, 30, 38, 39, 51, 81, 134 roteadores na rota (hop count) 17 roteador PE 47, 52, 53, 55, 56, 61, 62, 117, 118, 120, 124, 125, 126, 135, 136, 138, 149, 150, 155, 204 roteamento VII, XIII, 1, 2, 5, 6, 10, 11, 12, 13, 14, 15, 17, 18, 19, 20, 21, 22, 23, 24, 25, 27, 28, 29, 30, 33, 34, 35, 36, 38, 39, 41, 44, 48, 50, 51, 53, 56, 66, 85, 86, 87, 88, 90, 95, 97, 104, 112, 121, 137, 138, 143, 144, 151, 160, 181, 185 Roteamento 16, 26, 137 roteamento convencional 25 Roteamento convencional XIII, 26 roteamento dinâmico 12 roteamento 12, 134, 140 roteamento estático 12 roteamento 12, 52, 104, 134, 137, 139, 140, 162, 181

29/10/2012 14:57:55

Índice Remissivo 223

roteamento explícito 85, 86 roteamento por estado de enlace 18, 20, 22, 23 roteamento por estado de enlace (link-state) 18 roteamento por vetor de distância 16, 18 rótulo 2, 15, 25, 29, 30, 31, 33, 34, 35, 36, 37, 39, 41, 47, 56, 62, 72, 81, 82, 83, 84, 91, 105, 107, 115, 116, 120, 121, 124, 127, 131, 150 rótulo de túnel (tunnel label) 62 rótulo do topo (top label) 32 round-robin 75 Router Alert Label 29 Router distinguishers 107 Routing Information Protocol (RIP) 16 RSVP (Resource reSerVation Protocol) 66, 91 RSVP-TE (Resource Reservation Protocol – Traffic Engineering) 36, 91 RT (Route Target) 55 RT (Route Targets) 53

S Saída do pacote na rede 39 segurança 1, 11, 16, 20, 43, 44, 48, 133 Serviços Diferenciados (DiffServ) 65 Shortest Path First IX, X, XI, 11, 16, 21, 22, 35, 89, 102, 112, 151 sistema autônomo XV, 23, 53, 89, 114 Sistema Autônomo 15 SITA 26 SLA (Service Level Agreement) 93, 145 soft-state 67 Soma Verificadora do Cabeçalho (checksum) 11 SPF (Shortest Path First) 21 STM (Synchronous Transport Module) 15 switch 26, 41 Switch 26, 30, 34, 36, 144

T tabela de roteamento 12, 13, 15, 17, 19, 20, 22, 28, 34, 52, 53, 56, 139, 141, 143, 154, 160, 209 tabela LFIB 39, 120, 123 tabelas de encaminhamento 13 Tag Switching Architecture 26 tail end 87, 92, 93 Tamanho do Cabeçalho 7 Tamanho total do datagrama 8 TCP XI, 5, 11, 12, 24, 25, 64, 78, 79, 80, 113 TCP-IP 12, 64 TCP (Transmission Control Protocol) 11 TDM (Time Division Multiplexing) 95 Tempo de vida (TTL) 100 Tempo de Vida (TTL) 10 Tipo de Serviço 7 TLV (Type-Length-Variable) 90 top label 32, 56, 105


ToS (Type of Service) 7, 8, 68, 72 traceroute 122, 124, 132, 160 Traffic Engineering LSA 90 troca de rótulos (Label Swapping) 39 troca (swap) 41 TTL (Time To Live) 30 túneis XIV, 41, 44, 46, 47, 48, 83, 88, 92, 93, 94, 103, 107, 151, 152, 157, 158, 160, 205, 207, 208 tunelamento 43, 46, 47, 61, 83, 88, 126 túnel de backup 93, 94

U UDP (User Datagram Protocol) 11 um LER (Label Edge Router) 35 Unicast 101, 102 Unique-Local 102

V Versão 7 vetor caminho (path vector) 20 vetor de distância (distance vector) 16 Virtual Routing and Forwarding XII, 53 VLAN (Virtual Local Area Network) 61 VLSM (Variable Length Subnet Mask) 22 VPI/VCI (Virtual Path Identifier/Virtual Circuit Identifier) 29, 116 VPN de Acesso Remoto 45 VPN Extranet 45 VPN híbrida 44 VPN Intranet 45 VPN MPLS XIV, 46, 48, 51, 53, 55, 56, 144 VPN par-a-par 51 VPN Routing and Forwarding 107 VPNv4 XIV, XV, 53, 54, 55, 56, 114, 115, 136, 137 VPN (Virtual Private Network) 43, 44, 60 VRF XII, 53, 55, 56, 107, 134, 135, 137, 138, 141, 143, 144, 161, 179 Vyatta 109

W WAN (Wide Area Network) 1, 9, 43 WDM (Wavelength Division Multiplexing) 95 Weighted Fair Queuing – WFQ 74 Wireshark 29, 30, 57 WRED (Weighted Random Early Detection) 79

Y YouTube 21

Z Zebra 109

29/10/2012 14:57:55

Redes MPLS Fundamentos e Aplicações

Recommend Documents