Redes MPLS Fundamentos e Aplicações

Miolo_Redes_MPLS_17 x 24_OK.indd 1 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 OliveiraDiretora: Rosa Maria Oliveira de QueirozGerente de Produção Editorial: Marina dos Anjos Martins de OliveiraRevisão de Texto: Maria Helena dos Anjos Martins de OliveiraEditoraçã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 – Tijuca20270-280 Rio de Janeiro-RJTels. Fax: (21)2568.1415/2568.1507e-mails: [email protected] [email protected] [email protected]

site: www.brasport.com.br

Filial SPAv. Paulista, 807 – conj. 91501311-100 São Paulo-SPTel. Fax (11): 3287.1752e-mail: [email protected]


mailto:[email protected]




http://www.brasport.com.br


Às nossas famílias.


VII

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. É funda-mental acompanhar as tendências do mercado, com o objetivo de entregar sem-pre 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 emer-gente 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, propician-do 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.


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 ma-terial didático, referências para atualizações, ponteiros para fabricantes de equi-pamentos 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])


https://sites.google.com/a/cin.ufpe.br/mpls-brasport/




IX

VIII Redes MPLS

Lista de Acrônimos

AAL ATM Adaptation LayerADSL Asymmetric Digital Subscriber LineAF Assured ForwardingAS Automonous SystemASIC Application-Specific Integrated CircuitASON Automatically Switched Optical Network ATM Asynchronous Transfer Mode BGP Border Gateway ProtocolBoS Bottom of StackCBWFQ Class-Based Weighted Fair QueuingCE Customer Edge CEF Cisco Express ForwardingCIDR Classless Inter-Domain RoutingCQ Custom Queuing CSPF Constrained Shortest Path FirstCU Currently Unused DiffServ Differentiated Services DLCI Data Link Connection IdentifierDS Differentiated Service DSCP DiffServ Code PointeBGP external BGPECPM Equal-Cost MultipathEF Expedited ForwardingEGP Exterior Gateway ProtocolEIGRP Enhanced Interior Gateway Routing ProtocolEXP Experimental BitsFEC Forwarding Equivalent ClassFIB Forwarding Information BaseFIFO First-In First-Out


X Redes MPLS

FQ Fair QueuingFR Frame RelayFRR Fast RerouteGRE Generic Routing EncapsulationGTS Generic Traffic ShapingHDLC High Level Data Link ControlIANA Internet Assigned Numbers AuthorityiBGP internal BGPICMP Internet Control Message ProtocolIETF Internet Engineering Task ForceIGP Interior Gateway ProtocolIGRP Interior Gateway Routing ProtocolIOS Internetwork Operation SystemIP Internet ProtocolIPSec IP Security ProtocolIS-IS Intermediate System to Intermediate SystemISO International Organization for StandardizationISP Internet Service ProviderLAN Local Area NetworkLDP Label Distribution ProtocolLER Label Edge RouterLFIB Label Forwarding Information BaseLIB Label Information BaseLLQ Low Latency QueuingLMI Local Management InterfaceLSA Link-State AdvertisementLSP Label Switched PathLSR Label Switch RouterL2TP Layer 2 Tunneling ProtocolMPB-GP MultiProtocol BGPMPLS MultiProtocol Label SwitchingMTU Maximum Transfer UnitNSAP Network Service Access PointOID Object IDentifierOSI Open Systems InterconnectionOSPF Open Shortest Path FirstP ProviderPDH Plesiochronous Digital Hierarchy


Lista de Acrônimos XIX Redes MPLS

PDU Protocol Data UnitPE Provider EdgePHB Per-Hop BehaviorPHP Penultimate Hop PoppingPLR Point of Local RepairPOP Point of PresencePOS Packet Over SONETPPP Point-to-Point ProtocolPQ Priority QueuingPW PseudoWireQoS Quality of ServiceRD Router DistinguisherRED Random Early DetectionRFC Request For CommentsRIP Routing Information ProtocolRSVP Resource reSerVation ProtocolRT Route TargetSDH Synchronous Digital HierarchySLA Service Level AgreementSNMP Simple Network Management ProtocolSONET Synchronous Optical NETworkingSPF Shortest Path FirstSTM Synchronous Transport ModuleTCP Transmission Control ProtocolTDM Time Division MultiplexingTE Traffic EngineeringTLV Type-Length-VariableToS Type of ServiceTTL Time To LiveUDP User Datagram ProtocolUNI User Network InterfaceVC Virtual Circuit/ChannelVLAN Virtual Local Area NetworkVLSM Variable Length Subnet MaskVoIP Voice over IPVCI Virtual Circuit IdentifierVPI Virtual Path IdentifierVPN Virtual Private Network


XII Redes MPLS

VRF Virtual Routing and ForwardingWAN Wide Area NetworkWDM Wavelength Division MultiplexingWFQ Weighted Fair QueuingWRED Weighted Random Early Detection


XIII

XII Redes MPLS

S umário

Introdução ...........................................................................................................1

Organização do livro .................................................................................................................... 2

Capítulo 1. Conceitos Fundamentais .............................................................. 5

1.1 – Redes IPs ................................................................................................................................ 51.2 – O protocolo IPv4 ................................................................................................................. 61.3 – Comutação e roteamento ..............................................................................................121.4 – Protocolos de roteamento .............................................................................................15

1.4.1 – O protocolo OSPF ................................................................................................211.4.2 – O protocolo IS-IS ..................................................................................................231.4.3 – O protocolo BGP ..................................................................................................24

Capítulo 2. A Arquitetura IP sobre MPLS ...................................................... 25

2.1 – Surgimento da tecnologia .............................................................................................252.2 – Roteamento convencional x baseado em rótulos ................................................262.3 – O cabeçalho MPLS ............................................................................................................292.4 – Estrutura do MPLS ............................................................................................................322.5 – Componentes da arquitetura .......................................................................................332.6 – Funcionamento .................................................................................................................382.7 – Vantagens do MPLS ..........................................................................................................412.8 – Desvantagens do MPLS ..................................................................................................42

Capítulo 3. MPLS – VPN ........................................................................................................43

3.1 – VPN – Conceitos ................................................................................................................433.2 – Tipos de VPN .......................................................................................................................453.3 – Modelos de VPN ................................................................................................................48

3.3.1 – O modelo overlay .................................................................................................483.3.2 – O modelo par-a-par ............................................................................................50


XIV Redes MPLS

3.4 – Arquitetura MPLS VPN .....................................................................................................513.5 – Propagação de rotas VPNv4 no backbone VPN MPLS ..........................................55

Capítulo 4. PseudoWire MPLS ....................................................................... 58

4.1 – PseudoWire – Conceito ....................................................................................................584.2 – Modelo de referência PseudoWire ...............................................................................604.3 – Terminologias do PseudoWire .......................................................................................604.4 – Como o PseudoWire trabalha ........................................................................................614.5 – Benefícios do PseudoWire ..............................................................................................63

Capítulo 5. Qualidade de Serviço (QoS) com MPLS ..................................... 64

5.1 – Fundamentos do QoS .....................................................................................................645.2 – Arquiteturas de QoS.........................................................................................................65

5.2.1 – Serviços integrados (IntServ) ...........................................................................655.2.2 – Serviços diferenciados (DiffServ) ....................................................................67

5.3 – Mecanismos de QoS ........................................................................................................715.4 – Qualidade de serviços nas redes MPLS .....................................................................81

Capítulo 6. Engenharia de Tráfego com MPLS ............................................. 85

6.1 – Conceitos fundamentais ................................................................................................856.2 – A engenharia de tráfego sobre MPLS ........................................................................876.3 – Extensões do OSPF para TE ...........................................................................................896.4 – Extensões do IS-IS para TE .............................................................................................916.5 – Protocolo RSVP-TE ............................................................................................................916.6 – Operação do MPLS-TE .....................................................................................................926.7 – Atributos de túneis MPLS-TE .........................................................................................936.8 – Proteção e restauração – FRR .......................................................................................936.9 – GMPLS ...................................................................................................................................94

Capítulo 7. IPv6 sobre MPLS .......................................................................... 96

7.1 – O protocolo IPv6 ...............................................................................................................967.2 – Endereçamento IPv6 ..................................................................................................... 1017.3 – Transporte IPv6 sobre um backbone MPLS ........................................................... 103

7.3.1 – Técnica 6PE ......................................................................................................... 1047.3.2 – Técnica 6VPE ....................................................................................................... 106


XIV Redes MPLS Sumário XV

Capítulo 8. Implementando Redes MPLS .............................................. 108

8.1 – A ferramenta de simulação dos ambientes .......................................................... 1088.2 – Topologia de base utilizada ........................................................................................ 110

8.2.1 – Recursos utilizados .......................................................................................... 1118.3 – Escolha do protocolo IGP/EGP e esquema de endereçamento IP ............... 112

8.3.1 – Protocolo IS-IS – endereços NSAP .............................................................. 1128.3.2 – Protocolo IS-IS – áreas ..................................................................................... 1138.3.3 – Protocolo BGP .................................................................................................... 1138.3.4 – Definição do sistema autônomo ................................................................. 1148.3.5 – Configuração do MP-iBGP ............................................................................. 1148.3.6 – Configuração geral do BGP ........................................................................... 1148.3.7 – Configuração do Address Family VPNv4 ................................................... 115

8.4 – Testes realizados e observações ............................................................................... 1158.4.1 – Comportamento básico do MPLS .............................................................. 1158.4.2 – Configurações .................................................................................................... 1178.4.3 – Verificações e testes de conectividade ..................................................... 1198.4.4 – PseudoWire MPLS .............................................................................................. 1248.4.5 – MPLS VPN ............................................................................................................ 1338.4.6 – QoS no MPLS ...................................................................................................... 1458.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


1

Introdução

Novas tecnologias estão sendo constantemente desenvolvidas para aten-der à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 backbo-nes atuais, a robustez e confiabilidade são uma evidência de um grande avanço no desenvolvimento das tecnologias de redes espalhadas geograficamente, co-nhecidas 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 tec-nologias de camada 2, que provocam problemas de escalabilidade, desempenho e administração. O MPLS também possibilita o uso de aplicações convergentes,


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 for-ma 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 me-lhorias. 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 ser-viços, objetivando facilitar o aprendizado e servindo de base para o leitor desen-volver seus próprios cenários, suas configurações e aplicações.

Organização do livroO 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 à tecno-logia MPLS, dando uma visão dos principais componentes de uma rede MPLS, buscando identificar e entender o funcionamento da tecnologia, suas vantagens e desvantagens.


2 Redes MPLS 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 ar-quiteturas 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 utili-zada 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 de-senvolvimento 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.


5

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 IPsEm 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 des-sas 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 aplica-tivo de uso simples que “escondia” do usuário toda a complexidade da rede, possi-bilitou um rápido crescimento do número de usuários da Internet.

O principal protocolo de rede da Internet é o IP (Internet Protocol). O proto-colo 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 mecanis-mos de notificação ( acknowledgement) ou correção de erro. O protocolo IP não tem mecanismos que permitam realizar consultas de gerenciamento, é sem con-trole 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 es-forç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.


6 Redes MPLS

Existem dois problemas importantes que precisam ser resolvidos quan-do 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 en-tender o problema de escalabilidade, é necessário considerar o crescimento da Internet, que praticamente dobrou de tamanho a cada ano durante os últi-mos 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 IPv4O formato do datagrama IPv4 é exibido na Figura 1.1. Ele tem um compri-

mento 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 roteamen-to 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


6 Redes MPLS 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 inter-pretados 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 to-tal 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 pa-cotes 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


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) mu-dou 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 prece-dê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 con-gestionado 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 Descrição

0000 Normal (padrão)

0001 Minimizar custo

0010 Maximizar confiabilidade

0100 Minimizar throughput

1000 Minimizar atraso

Na interpretação com os serviços diferenciados os seis primeiros bits for-mam 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 defi-ne 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 compri-mento 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.



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 con-seguir ser transmitido por essas redes. Como exemplo, o protocolo Ethernet apre-senta 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 identifi-cador é 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 de-sencapsula 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 de-pendem 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 trans-mite 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 de-cidiram 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 da-tagrama 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


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ísi-ca 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 datagra-ma 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, sig-nifica 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, fragmen-tados em três partes.

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 des-cartado, evitando assim um laço de roteamento de longa duração. Um datagra-ma tem um tempo de vida útil limitado em sua transmissão por uma rede de

Figura 1.4 – Exemplo de fragmentação



computadores. Este campo foi projetado originalmente para armazenar um regis-tro de horas, que era reduzido pelos roteadores visitados. O datagrama era des-cartado 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 (check-sum) 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 en-capsulam 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 par-te 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 ende-reços IP do host que envia o datagrama (fonte) e do host que receberá o datagra-ma (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,


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 roteamentoRoteamento é o nome dado ao processo de escolha do caminho a ser se-

guido pelos dados a serem transmitidos numa rede espalhada geograficamente (WAN). Vários aspectos podem ser levados em consideração, desde a velocida-de 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 re-des 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 infor-maçõ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 atra-vé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 co-nectada 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 di-zer 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



roteadores sobre o evento. Em se tratando de um roteamento estático, o admi-nistrador é 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 topo-logia 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 in-terface 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 in-terface 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 roteamen-to, 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 enca-minhamento. Inicialmente o roteador “D” anuncia a rede 130.10, que está dire-tamente conectada a ele, para o roteador B. O roteador C faz o mesmo procedi-mento, 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.


14 Redes MPLS

Figura 1.7 – Encaminhamento de pacotes

A comutação de pacotes oferece um novo modelo para o encaminhamen-to 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 proto-colos existentes.

Figura 1.6 – Geração das tabelas de encaminhamento



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 roteamentoO roteamento dos pacotes em uma rede depende das regras estabelecidas

por cada protocolo de roteamento, portanto os protocolos de roteamento defi-nem 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 transmis-são sendo interditadas ou reativadas, falha de roteadores e outras mudanças es-truturais, assim como informações de falha em linhas (enlaces) de transmissão como, por exemplo, um circuito de STM (Synchronous Transport Module) que es-teja 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 inter-valo 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 interio-res 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


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 fa-zendo 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 infor-maçõ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 pro-pagam 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 lite-ratura 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



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 diretamen-te. 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 maio-ria 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 com-pleta 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


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” res-ponde 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 enla-ces 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 recebi-do 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 roteamen-to 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,



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, enca-minha-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 da-dos 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 quantida-de 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


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 gran-de 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 al-guns outros meios, como um protocolo de roteamento por vetor caminho (path vector). Dentro da Internet, existe a exigência de conectar redes e sistemas au-tô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 mui-to mais escaláveis e flexíveis. Para esse tipo roteamento, entre sistemas autôno-mos, é 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 rotea-mento. 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 rote-adores aplicassem políticas diferentes um do outro ou diferentes da política de menor custo.



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 Hierarquia Requerida

OSPF IGP Estado de enlace Sim

IS-IS IGP Estado de enlace Sim

BGP EGP Vetor caminho Não

1.4.1 – O protocolo OSPF

Criado pelo IETF (Internet Engineering Task Force) em 1988, o OSPF é um proto-colo 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 algo-ritmo SPF (Shortest Path First) para calcular o caminho mais curto para cada nó. Trata-se 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 re-des grandes e escaláveis, as quais não eram abrangidas pelo RIP. A versão mais recen-te 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;


tpo

Realce

tpo

Realce

tpo

Realce

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 rotea-mento 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 ca-minho 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ên-cia que todos os roteadores usem o mesmo mecanismo para calcular os cami-nhos 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 tam-bé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 mes-mo custo. Esse roteamento é chamado de ECMP (Equal-Cost Multi-Path), que é



uma boa solução quando se trata de protocolos de roteamento por estado de en-lace. 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 pro-tocolo 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 ba-lanceamento 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 atual-mente 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 es-tado 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 ape-nas 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,


24 Redes MPLS

apenas por possuírem nomenclaturas diferentes, pode haver o mapeamento en-tre 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.

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 roteado-res 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 cone-xã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 in-formaçõ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.

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


25

24 Redes MPLS

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 so-bre os aspectos ligados à tecnologia MPLS. Descreveremos o surgimento da tec-nologia, 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 con-trole 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 tecnologiaNa 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 tecno-logia 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 que-bra 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


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 adiciona-dos a cada pacote.

Algumas empresas começaram a desenvolver tecnologias baseadas na uti-lização de rótulos. Porém, devido à incapacidade de interação entre essas tecno-logias 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ótulosA tecnologia IP deverá continuar sendo a principal ferramenta adotada por

provedores de serviços. Tal tecnologia, aliada ao MPLS e à possibilidade de unifi-car 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 pa-cotes 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) au-mentou 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 au-mento 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


26 Redes MPLS 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 ofe-recem 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 sim-ples, tornando o processo de encaminhamento dos segmentos muito mais rápi-do, 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 data-gramas 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 enca-minhar o datagrama é tomada (Rosen et al, 2001a).

Figura 2.1 – Backbone de uma rede ATM


tpo

Realce

28 Redes MPLS

Segundo Rosen (Rosen et al, 2001a), a comutação de rótulos multiprotoco-los 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 cami-nho. 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 encaminhamen-to 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.

Necessita de somente um algoritmo de encaminhamento.

Decisão de roteamento

Baseado no endereço de destino no cabeçalho do pacote IP.

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


tpo

Realce

tpo

Realce


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

2.3 – O cabeçalho MPLSO 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


tpo

Realce

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 uti-lizados para alterar os algoritmos de enfileiramento (queuing) e descar-te; 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á ba-seado em MPLS ou IP.

• TTL (Time To Live): este campo é formado por 8 bits e funciona de manei-ra semelhante ao TTL do protocolo IP. Ele especifica um limite de quan-tos 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



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 ca-beç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 trans-missã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)).


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, base-adas 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 MPLSPor se tratar de uma ligação entre as camadas 2 e 3, já que o MPLS utili-

za o sistema de endereçamento dos protocolos de nível 3 e o sistema de comu-taçã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 com-patí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


tpo

Realce


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 encami-nhamento. 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 arquiteturaA seguir descreveremos os principais termos e componentes de uma ar-

quitetura MPLS, para em seguida explicar o seu funcionamento. A Figura 2.6 exi-be 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.


34 Redes 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 aloca-do pelo LDP com base na tabela de roteamento, e isso ocorre até a chegada à rede de destino. Por padrão, o LDP é configurado para for-mar 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 des-cobertos 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ín-culos de rótulos que um LSR (Label Switch Router) recebe sobre o proto-colo LDP, ou seja, uma tabela que apresenta informações correlacionan-do 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.

Figura 2.6 – Componentes da arquitetura MPLS


tpo

Realce

tpo

Realce


• FIB (Forwarding Information Base): é uma tabela que controla a deci-sã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 ro-teamento, 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 per-tencentes 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 ende-reços de origem e destino são os mesmos. Pacotes de um mesmo fluxo de dados geralmente pertencem à mesma FEC. Uma FEC é representa-da 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

Figura 2.7 – Tabela de encaminhamento


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 “paco-te-FEC” ocorre apenas quando o pacote entra na rede MPLS, proporcio-nando 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 encami-nhamento 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 cami-nhos estabelecidos. Ao receber um pacote, cada LSR troca o rótulo exis-tente 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



realiza o processamento e a classificação inicial do pacote e apli-ca 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 co-mutação em alta velocidade, sendo este um processo que mais contribui para o ganho de desempenho na utilização do pro-tocolo 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) tam-bé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 unidi-recional no sentido da origem para o destino, podendo ser estático ou dinâmico.


38 Redes MPLS

2.6 – FuncionamentoNas 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 cami-nho. Os roteadores tomam decisão de encaminhamento com base em tais rótu-los, evitando assim o esquema de intenso processo de pesquisa de dados utili-zado 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 de-finir 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 protoco-los 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



serviços de nível 3 e valor agregado, tais como QoS, e em seguida acres-centa 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 rotea-dores 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.


40 Redes MPLS

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.11 – Inserção dos rótulos aos pacotes IPs

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écni-ca não compromete o funcionamento de um LSP e propicia um ganho de desem-penho nos roteadores de borda.



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 reti-rada 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écni-ca 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 infor-mações do cabeçalho de rede ou do próximo cabeçalho MPLS.

2.7 – Vantagens do MPLSO MPLS é uma tecnologia utilizada em backbones. Embora a grande moti-

vaçã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 ago-ra 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.


tpo

Realce

tpo

Realce

tpo

Realce

tpo

Realce

tpo

Realce

tpo

Realce

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 utili-zando 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 engenha-ria de tráfego.

2.8 – Desvantagens do MPLSA 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 clien-te pode ser vista no backbone MPLS.


tpo

Realce

tpo

Realce

tpo

Realce

tpo

Realce

tpo

Realce

tpo

Realce

tpo

Realce

tpo

Realce

43

42 Redes MPLS

CAPÍTULO 3. MPLS – VPN

Atualmente existem algumas aplicações, também chamadas de serviços asso-ciados à 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 di-fíceis de implementar, ou operacionalmente quase impossíveis de realizar com as re-des 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 – ConceitosPode-se dizer que uma VPN (Virtual Private Network) é um conjunto de po-

líticas que controlam a conectividade e a qualidade de serviço de uma rede pri-vada. São redes que compartilham um meio físico comum, porém possuem pri-vacidade 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 se-gurança de enlaces dedicados. As VPNs consistem em soluções simples e flexíveis, tratando-se de uma poderosa ferramenta de tunelamento oferecida pelos prove-dores 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 de-senvolvidas 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).


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 irres-trito. Porém, existem muitas situações tais como transações financeiras, paga-mentos, etc. nas quais se exige privacidade das informações e uma conectivi-dade 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 in-ter-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 en-tre 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.


44 Redes MPLS MPLS – VPN 45

3.2 – Tipos de VPNHá 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.

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

Figura 3.1 – VPN Intranet

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 re-moto e o servidor de VPN corporativo através da Internet, conforme Figura 3.3.


46 Redes MPLS

Para maiores detalhamentos sugerimos consultar a referência (Guimarães et al, 2006).

Todos os tipos de VPNs citados se baseiam na tecnologia de tunela-mento, 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 usa-dos 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 é uti-lizado para criar um túnel, através de LSRs, com o objetivo de conectar redes re-motas, como pode ser visualizado na Figura 3.5. Esse tipo de VPN assegura a se-paração de tráfego em um backbone MPLS. Na Figura 3.5 o túnel é estabelecido

Figura 3.3 – VPN acesso remoto



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.4 – Processo de tunelamento – VPN

Figura 3.5 – Processo de tunelamento – VPN MPLS

O MPLS pode ser utilizado para estabelecer VPNs de camada 3, e es-sas 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 trans-portados pelo núcleo do backbone. Esta segunda opção pode ser particu-larmente ú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 diferen-ciar as VPNs.


48 Redes MPLS

3.3 – Modelos de VPNO termo VPN é bastante utilizado e as definições variam, mas intuiti-

vamente é possível definir uma VPN considerando primeiro a ideia de rede privada. As empresas com muitas filiais distribuídas geograficamente normal-mente 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, embo-ra 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 partici-pa 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 pro-ver 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) inter-ligados por vários Circuitos Virtuais Privados (PVCs), formando uma rede com-pletamente 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.



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á en-volvimento por parte do provedor em tal processo, conforme mostra a Figura 3.7.

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

Figura 3.7 – VPN overlay – ponto de vista do cliente


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 ou-tros 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 atra-vé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 parti-cipam diretamente dos mecanismos funcionais das VPNs, proporcionando o rotea-mento 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



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 configu-raçõ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 provisiona-mento 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, en-tre 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 desvanta-gem 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 escalabili-dade e boa convergência de roteamento.

3.4 – Arquitetura MPLS VPNO MPLS é utilizado para estabelecer VPN par-a-par. Uma VPN MPLS é cons-

tituí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.


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 ro-teador 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 iso-lar 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 ro-teamento global. Esses roteadores de backbone, conhecidos como P (Provider), fazem a comutação de rótulos entre os PEs e não requerem quaisquer configu-raçõ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 ob-servar na Figura 3.9.

Figura 3.9 – Arquitetura MPLS VPN



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, tam-bé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 atri-butos 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çamen-tos 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 resul-tante (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 va-lores de RD, no caso, 1:100 e 1:101.


54 Redes 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

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

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



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 im-portadas e exportadas pelo MP-BGP, permitindo assim que possa haver conver-sação entre diferentes VRFs e que também possam ser feitas restrições de impor-taçã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 identifi-caçã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 MPLSA 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)


56 Redes MPLS

De acordo com a Figura 3.12, o roteador PE recebe rotas IPv4 do rotea-dor 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 rotea-dor P. Os rótulos são retirados no roteador PE de saída e os pacotes são encami-nhados pela interface VRF de saída para o roteador CE, sendo este encontrado



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ótu-lo, 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


58

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 – ConceitoA 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)


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 inte-grada 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 es-trutura 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)


60 Redes MPLS

4.2 – Modelo de referência PseudoWireO 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 rotea-dores 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 ca-beç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 PseudoWireAs 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)


60 Redes MPLS PseudoWire MPLS 61

Um circuito de acesso (AC) é um circuito virtual (VC) ou um circuito físi-co 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 meca-nismo 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 encap-sulamento: cabeçalho de tunelamento, campo de demultiplexação e encapsula-mento de circuito virtual.

4.4 – Como o PseudoWire trabalha Em uma rede MPLS provendo serviço PseudoWire, os quadros nível 2 são re-

cebidos 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 en-trada. 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.

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


62 Redes MPLS

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), identifi-cando 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 apropria-da. 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 de-vido ao comportamento do PHP (Penultimate Hop Popping) entre o último ro-teador 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.

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


62 Redes MPLS PseudoWire MPLS 63

4.5 – Benefícios do PseudoWirePodemos 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áfe-go sobre o backbone e comporta todos os tipos de clientes;

• Adere aos padrões desenvolvidos para transporte de pacotes nível 2 so-bre 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.

Figura 4.6 – Encaminhamento de um pacote PseudoWire


64

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 QoSA 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 indiscrimi-nadamente, 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, ne-cessitam 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 cres-cimento, 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 transpor-tam 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).


Qualidade de Serviço (QoS) com MPLS 65

5.2 – Arquiteturas de QoSMuitos provedores de serviços, devido à necessidade dos clientes, começa-

ram 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 back-bone MPLS são capazes de permitir QoS através desta infraestrutura.

O IETF (Internet Engineering Task Force) define dois modelos para implemen-taçã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 ne-cessá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 apro-priado 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 (Colc her et al, 2005).

Figura 5.1 – Componentes da arquitetura IntServ

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


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 aten-dida 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 ser-viç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 acor-do 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 apli-caçã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 de-sempenha 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


66 Redes MPLS Qualidade de Serviço (QoS) com MPLS 67

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 cami-nho 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 inse-ridas no roteador.

Nesse período de tempo, o emissor daquele serviço tem uma faixa da lar-gura 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 en-viando 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 pro-cessamento 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, diferente-mente 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 presen-tes nos roteadores de borda da rede e, eventualmente, adicionados aos roteado-res de núcleo da rede.


68 Redes MPLS

• Classificador de pacotes: identifica pacotes que são mapeados para classes.

• Medidor: verifica conformidade com parâmetros de tráfego e passa o re-sultado 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 perma-neç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 cam-po 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.3 – Blocos funcionais do DiffServ

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



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 rotea-dor, 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 rela-tiva disponível e políticas de descarte de pacotes. O serviço AF é com-posto 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 garan-tia 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 AF1 AF2 AF3 AF4

1. Baixa 001010 010010 011010 100010

2. Média 001100 010100 011100 100100

3. Alta 001110 010110 011110 100110

• Classe EF (Expedited Forwarding) (RFC 2598): oferece um serviço de re-des com baixa perda, baixo atraso, baixo jitter e banda garantida. É indica-do 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 ca-minhos que os pacotes EF poderão seguir.


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 defini-dos de maneira que seus PHBs se aproximem dos tratamentos de pacotes defini-dos 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 processa-dos segundo a codificação rotulada no cabeçalho do pacote DSCP. As deci-sõ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 é simplifi-car o processamento nos roteadores de núcleo (Core), tornando-os mais rápi-dos. 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 defini-das através de policiamento e da conformidade.



• 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 QoSDiversos mecanismos de QoS são utilizados para provimento da qualida-

de de serviço em redes de computadores. Estes mecanismos compreendem: classificação e marcação, gerenciamento de congestionamento, policiamen-to, 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 ori-gem, IP de destino, endereço MAC, porta de aplicação, tipo de protocolo e outros critérios.

Figura 5.5 – Arquitetura de serviços diferenciados


72 Redes MPLS

Já a marcação, dependendo do tipo de interface em questão e das caracte-rí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 apresen-tados 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

Figura 5.7 – Marcação em camada 3

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

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.

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



Gerenciamento de congestionamento

O controle de congestionamento ocorre na medida em que um conges-tionamento se estabelece em uma comunicação de rede. Os elementos de rede usam os algoritmos de enfileiramento para ordenar o excesso de tráfego (over-flow) 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 deve-mos 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 diver-sos mecanismos de enfileiramento para controle e prevenção de congestiona-mento 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 me-canismo 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 ban-da é 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 atra-sos 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


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 tra-tamento 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), colo-cando 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 iden-tificar tráfego dentro de conversações e determinar quanto de banda de cada



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.


76 Redes MPLS

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

Figura 5.12 – Filas CQ (Custom Queuing)

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 meca-nismo de esvaziamento interrompe o atendimento às demais filas e transmite



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)

Figura 5.14 – Mecanismo de policiamento (policing)

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 des-cartar os pacotes, o que efetivamente impossibilita o tráfego acima da banda dis-ponibilizada, 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.


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 meca-nismo, 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 li-mite 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 congestionamen-tos na rede (BECN, FECN).



Evitar congestionamento (Congestion Avoidance)

Alguns dos principais mecanismos para evitar congestionamentos são:

• RED (Random Early Detection) é o mecanismo através do qual o rotea-dor 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 pro-porcional 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 ultra-passado, aciona o mecanismo de descarte aleatório, enquanto o segun-do 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 pa-cote. 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 pa-cote 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 esquemati-zado 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.


80 Redes MPLS

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.

Figura 5.17 – Efeito Global Sync

Figura 5.16 – Funcionamento do WRED



5.4 – Qualidade de serviços nas redes MPLSTodas as políticas de classificação e marcação, gerenciamento de con-

gestionamento, 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 é converti-da 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 inseri-dos 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 pou-co 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 com-portamento pode ser alterado para manter o valor de QoS quando os rótulos são retirados.


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 configu-raçã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



A MPLS QoS regra 4 dá origem ao seguinte comportamento: indiferente-mente do valor dos bits EXP introduzidos pelo LSR de entrada ou em qualquer ou-tro 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 fa-zer 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 va-lor 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ótu-los 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ânsi-to 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


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 importan-tes 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.


85

84 Redes MPLS

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 fundamentaisO protocolo MPLS oferece a capacidade de roteamento baseado na ori-

gem, 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 enge-nharia de tráfego, denominado “ problema do peixe” devido à sua forma.

Figur a 6.1 – Rede exigindo roteamento explícito


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 determina-do 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 capaci-dade 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 determina-do 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 en-laces 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áfe-go 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 robus-tas, 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 distribuin-do o tráfego na rede, evitando pontos de congestionamento e otimizando a uti-lizaçã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


86 Redes MPLS Engenharia de Tráfego com MPLS 87

o estabelecimento de caminhos alternativos nessas redes – diferentes dos cami-nhos 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 mape-amento 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 eficien-te 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 estabe-lecimento 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 MPLSO roteamento baseado no IP de destino não provê qualquer mecanismo

para balanceamento de carga por caminhos redundantes. Nesse encaminha-mento 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 tra-dicional, 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 enca-minhamento 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 encami-nhamento forem modificadas, então os roteadores na rede terão de ser mantidos


88 Redes MPLS

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 ori-gem 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.2 – Encaminhamento IP tradicional

Figura 6.3 – Balanceamento de carga com MPLS-TE



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, con-forme os LSPs são estabelecidos, e podem ser atualizados dinamicamen-te, 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 no-vos 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 fa-lha e indicando como e quando LSPs de backup e espera devem ser con-figurados 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 TEA 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.


90 Redes MPLS

Os roteadores que não “entendem” os LSAs opacos não os precisam exa-minar nem os usar em seus cálculos de caminho. Esse roteadores necessitam apenas armazenar e reencaminhar os LSAs recebidos. Isso provê um modo ele-gante 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, iden-tificado 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 rotea-mento 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 basea-do 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 conven-cional 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.



6.4 – Extensões do IS-IS para TEPara 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 algu-mas 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-TEO 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 signi-ficativo do que quando usado para o RSVP.


92 Redes MPLS

6.6 – Operação do MPLS-TEO 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 forne-ce 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 ou-tros 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 denomina-da 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 ma-peados 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 ori-gem ao invés do roteamento baseado em IP de destino.



6.7 – Atributos de túneis MPLS-TEAlguns dos atributos de túneis MPLS-TE são da mesma natureza que os atri-

butos 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 protoco-los envolvidos na convergência. Este tempo de convergência é resultante, prin-cipalmente, 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 por-que 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


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 por-que 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



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 disso-ciado 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 tecnolo-gias 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 expectati-va 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 segun-do 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.


96

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 IPv6Ao passo que ocorre o crescimento da emergente tecnologia MPLS, o pro-

tocolo 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ômi-cos 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 à escas-sez 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 continuida-de 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


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 ende-reços, identificação de uma quantidade muito maior de dispositivos na rede e implementação de mecanismos de autoconfiguração. A escalabi-lidade 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 à quanti-dade 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 deter-minados fluxos de tráfegos, para os quais podem ser requeridos trata-mentos 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 frag-mentaçã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.


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

Endereço IPv6 de destino do pacote

Opções Raramente utilizado. Existem opções para

segurança, timestamps, roteamento mandatório,

etc.

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

Complemento Garantir que o cabeçalho tem um

tamanho múltiplo de 4 bytes

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

Identificador de fluxo --------------------- Identificar um tipo de fluxo de dados


98 Redes MPLS IPv6 sobre MPLS 99

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 exten-são do IPv6; deste modo, os campos Opções e Complementos puderam ser remo-vidos. 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 remo-vidos 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 roteado-res, 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.

Figura 7.1 – Formato de um datagrama IPv6


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 funcionali-dades e definições do campo Tipo de serviço do IPv4.

• Identificador de Fluxo (20 bits): identifica e diferencia pacotes do mes-mo fluxo na camada de rede. Esse campo permite ao roteador identifi-car 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 ca-beç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 des-cartado, 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 se-gundos, 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.



7.2 – Endereçamento IPv6No 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 surgimen-to 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 ve-zes 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 ante-riormente 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 as-sim, 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.


102 Redes MPLS

Assim como existem as classes dos endereços IPv4, há classes dos ende-reços IPv6 para endereçamentos dos hosts. São elas: Global Unicast, Unique-Local 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 en-dereç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 usa-dos 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 cha-mar 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 MP-BGP (MultiProtocol Border Gateway Protocol).

Diversos estudos mostram que a penetração do protocolo IPv6 tem au-mentado gradativamente; no entanto, é preciso avançar muito mais, pois adiar por mais tempo sua implantação poderá trazer diversos prejuízos para o desen-volvimento de toda a Internet.



7.3 – Transporte IPv6 sobre um backbone MPLSDevido à necessidade cada vez mais intensa do protocolo IPv6, os prove-

dores 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, po-rém esta solução gera algumas desvantagens. Entre elas:

• Alguns dos roteadores podem não ter um sistema operacional que su-porte o protocolo IPv6, sendo necessária a atualização do parque de equipamentos.

• Como muitos clientes ainda estarão usando o protocolo IPv4, será neces-sário o funcionamento em dual-stack (executar IPv4 e IPv6).

• Para executar o protocolo IPv6 em um backbone, o IPv6 precisaria do su-porte ao LDP, o qual ainda não foi implementado.

Portanto, tal solução requer uma completa atualização de todos os rotea-dores 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 trans-portar 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 necessida-de 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 des-vantagens 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 desvanta-gem 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


104 Redes MPLS

o backbone em risco, já que os provedores de serviços possuem backbones bas-tante 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 re-configuraçã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 rotea-mento 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 aumen-tando 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 inte-raçõ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 atra-vé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.



É 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 comutan-do 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 back-bone, é 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 encaminha-mento 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

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


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 prefi-xos de outros clientes que conectam-se à mesma rede MPLS.

Os provedores de serviços que já tenham desenvolvido o serviço MPLS-VPN 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.



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 se-paradas 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 encaminha-dos 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 comu-tação dos pacotes IPv6 rotulados.

Figura 7.4 – Desenvolvimento 6VPE (Cisco, 2011)


108

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 am-bientes, fazendo uso da ferramenta de emulação GNS3 (GNS3, 2012), que será des-crita 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 ambientesPoderíamos citar alguns dos principais fabricantes de equipamentos dis-

poní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 dis-positivos de redes reais, mas nem tudo é permitido, os emuladores são softwares cria-dos 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).


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 re-quisitos necessários para emulação das funcionalidades que serão exibidas. Trata-se de um emulador gráfico que é fortemente utilizado com o Dynamips (um emu-lador 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-2FE-TX”, “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”.


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 utilizadaA 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 utili-zar uma topologia suficiente para exibição dos serviços aqui propostos, podendo servir em sua integridade a um backbone real.


110 Redes MPLS Implementando Redes MPLS 111

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, leva-mos em consideração todas as características necessárias para a imple-mentação dos serviços utilizados nessa demonstração. Para os roteado-res 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

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


112 Redes MPLS

(Object IDentifiers) SNMP em tempo real. Pode ser adaptado para se co-nectar 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) re-comendados 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:

49.0172.0001.0000.0001.00

Area ID System ID NSELAFI

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.00zzUsado 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.



8.3.2 – Protocolo IS-IS – áreas

Com relação às áreas utilizadas pelo IS-IS, foi usada apenas uma área (back-bone 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 ende-reç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, supor-tando 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

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.


114 Redes MPLS

BGP entre os PEs. Esses protocolos são: IPv4, IPv6, VPNv4, entre outros, todos co-nhecidos 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 estabele-cerá: neighbor x.x.x.x update-source loopback0.



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 (<route--distinguisher><ip-address>). 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 con-tê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-fa-mily 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: nei-ghbor x.x.x.x send-community extended.

8.4 – Testes realizados e observaçõesNos próximos itens serão exibidos todos os testes e configurações realiza-

dos 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 demons-trar 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 ca-mada 3 de um pacote IP puro, conforme mostra a Figura 8.2:


116 Redes MPLS

Nesse modo, os roteadores são diretamente conectados através de interfa-ces 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.2 – MPLS frame-mode

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 equipa-mentos do backbone MPLS (PE1, PE2, P1 e P2), e os testes serão executados a par-tir dos clientes, CE11 e CE22, estabelecendo uma comunicação entre eles através do backbone MPLS.



8.4.2 – Configurações

São aqui apresentados os passos para configurações dos equipamentos de backbone:

Habilitar CEF Router(config)#ip cef [distributed]

Configurar o pro-tocolo IS-IS

Router(config)#router Isis area-tagRouter(config-router)#net network-entity-titleRouter(config)#interface interface-type numberRouter(config-if)#ip router isis area-tag

Configurar o pro-tocolo BGP

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

Definir o protocolo de distribuição de

labelsRouter(config)#mpls label protocol ldp

Configurar MPLS na interface

Router(config)#interface interface-type numberRouter(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 rotea-dores 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 back-bone MPLS. Por exemplo, a configuração para o roteador PE1 segue:

router isis net 49.0172.0001.0000.0001.00is-type level-2-onlyinterface loopback 0ip router isisinterface serial1/2ip router isisinterface serial1/3ip router isis


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 65500no synchronizationredistribute staticneighbor 172.2.0.1 remote-as 65500neighbor 172.2.0.1 update-source loopback0neighbor 172.2.0.1 next-hop-self

O comando “redistribute static” foi utilizado neste caso porque foram usa-das 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 sincroni-zaçã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 protoco-lo 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 in-terfaces entre os PEs e os Ps através do comando “mpls ip” para a interface se-rial1/2 do PE1:

interface serial1/2mpls ip

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



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, fize-mos 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 alter-na 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 acres-centado 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


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 propa-gaçã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 <output truncaded> 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 Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Pop tag 172.1.0.1/32 8852 Se1/0 point2point 17 16 172.2.0.1/32 9401 Se1/2 point2point 19 Pop tag 192.168.0.24/30 0 Se1/2 point2point 20 Pop tag 172.20.0.1/32 142 Se1/2 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 Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Pop tag 172.2.0.1/32 9319 Se1/1 point2point



17 16 172.1.0.1/32 9381 Se1/2 point2point 18 Pop tag 172.10.0.1/32 44 Se1/2 point2point 20 Pop tag 192.168.0.12/30 0 Se1/2 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 Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Untagged 20.30.40.0/24 0 Se1/1 point2point 17 Untagged 200.2.0.2/32 0 Se1/1 point2point 18 18 172.10.0.1/32 0 Se1/3 point2point 19 17 172.1.0.1/32 0 Se1/3 point2point 20 20 192.168.0.12/30 0 Se1/3 point2point 21 Pop tag 192.168.0.28/30 0 Se1/3 point2point 23 Pop tag 172.20.0.1/32 0 Se1/3 point2point

Assim, podemos afirmar que PE2 irá inserir o rótulo 17 no pacote IP com desti-no 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 subnetsB 200.2.0.2 [200/0] via 172.2.0.1


122 Redes MPLS

hostname CE22

ip cef


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 subnetsB 200.1.0.1 [200/0] via 172.1.0.1

Para os testes de conectividade utilizamos os comandos “ping” e “tracerou-te”, 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 150.1.1.1 460 msec 312 msec 308 msec2 192.168.0.14 [MPLS: Label 17 Exp 0] 144 msec 548 msec 240 msec3 192.168.0.30 [MPLS: Label 16 Exp 0] 432 msec 932 msec 296 msec4 192.168.0.25 192 msec 128 msec 168 msec5 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 pa-cote para o IP 172.2.0.1 (loopback 0 do PE2). Porém, o endereço 172.2.0.1 é apren-dido pelo PE1 via protocolo IS-IS através do IP 192.168.0.14 (serial1/0 do P1), con-forme informações a seguir:



PE1#show ip route 172.2.0.1Routing entry for 172.2.0.1/32Known via “isis”, distance 115, metric 40, type level-2Redistributing via isisLast update from 192.168.0.14 on Serial1/2, 02:52:33 agoRouting 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 Bytes tag Outgoing Next Hop Tag tag or VC or Tunnel Id switched interface 16 Untagged 10.20.30.0/24 0 Se1/0 point2point 17 Untagged 200.1.0.1/32 0 Se1/0 point2point 18 Pop tag 172.10.0.1/32 0 Se1/2 point2point 19 17 172.2.0.1/32 0 Se1/2 point2point 21 Pop tag 192.168.0.28/30 0 Se1/2 point2point 22 19 192.168.0.24/30 0 Se1/2 point2point 23 20 172.20.0.1/32 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.


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.



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 pa-cote. Em todos os roteadores do backbone habilitamos o protocolo IS-IS, esco-lhido 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úl-timo 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 ro-teadores 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, portan-to, 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 so-bre 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.



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 comentare-mos antes da demonstração.

A Figura 8.5 será utilizada para demonstração do PseudoWire transportan-do 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 rotea-dor 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 ro-teadores 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


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-pon-to, 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.



PE1#show mpls l2transport vcLocal intf Local circuit Dest address VC ID Status ---------- -------------- ----------- ---------- ----------Se1/0 HDLC 172.2.0.1 10 UP

PE1#show mpls l2transport vc 10 detailLocal 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, as-sim como constatamos o VC type – nesse caso, HDLC.

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


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 deter-minada 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 dispo-sitivo 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 perma-nente (PVC) em um dispositivo Frame Relay.



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

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


130 Redes MPLS

PE1#show mpls l2 transport vc Local intf Local circuit Dest address VC ID Status ----------- ----------------- ----------- ---------- ----------Se1/0 FR DLCI 30 172.2.0.1 100 UP

PE1#show mpls l2transport vc 100 detailLocal 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: 0 MTU: 1500, Interface Desc: connected to CE11 Remote Label: 23 Cbit: 1, VC Type: FR DLCI, GroupID: 0 MTU: 1500, Interface Desc: connected to 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 co-nectado 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 State =======================================================2 FR Serial1/0 30 172.2.0.1 100 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

Verificações do PseudoWire para transporte do Frame Relay sobre MPLS

Com os dois comandos a seguir, verificamos que o PseudoWire está fun-cional para transporte de Frame Relay sobre MPLS, mostrando o estado do PseudoWire.

PE1#show mpls l2 transport vc Local intf Local circuit Dest address VC ID Status ----------- ---------------- ----------- ---------- ----------Se1/0 FR DLCI 30 172.2.0.1 100 UP

PE1#show mpls l2transport vc 100 detailLocal 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: 0 MTU: 1500, Interface Desc: connected to CE11 Remote Label: 23 Cbit: 1, VC Type: FR DLCI, GroupID: 0 MTU: 1500, Interface Desc: connected to CE22


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 State =======================================================2 FR Serial1/0 30 172.2.0.1 100 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 tra-ceroute, desde o cliente CE11 até o cliente CE22, comprovando assim a conectivi-dade ponto-a-ponto entre os clientes, trafegando como se de fato fossem conec-tados diretamente.

CE11#ping 150.1.1.1Type 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


1 150.1.1.2 860 msec 448 msec 732 msec



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, po-demos perceber a funcionalidade do PseudoWire através do transporte dos proto-colos 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 pas-sa 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 di-ferentes 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, fa-zendo com que a rede seja mais segura e tenha maior agilidade no tráfego, per-mitindo também a integração de qualquer tipo de rede, planos de endereçamen-tos e roteamento.

As VPNs fazem uso do conceito de Roteador Virtual, o que reduz signifi-cativamente 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 segu-ranç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.


134 Redes MPLS

Para esta simulação, configuraremos duas VPNs, VPN_A e VPN_B, para si-mular 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 rotea-mento 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.

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

Tabela 8.1 – Relação entre os clientes, VRFs e roteadores

Cliente VRF Roteadores

A VPN_A CE11, CE13 e CE22

B VPN_B CE12 e CE21

Configurações

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



Configurar instância VRF

Router(config)#ip vrf vrf-name

Configurar o router

distinguisher

Router(config-vrf)#rd route-distinguisher

Definir import e export de rotas

Router(config-vrf)#router target {import|export|both} router-target-ext-community

Associar a VRF para uma

interface

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.


rd 65500:1

rd 65500:2

Passo 3: configurar o RT para importação e exportação das comunidades esten-didas MP-BGP nos roteadores PEs.


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/0ip vrf forwarding VPN_A


136 Redes MPLS

interface serial 2/0ip vrf forwarding VPN_A

interface serial1/1ip 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 usan-do MP-iBGP. Para o roteador P, esse processo é transparente, pois ele não trans-porta nenhuma rota de clientes. Seguem os passos para configuração do BGP:

Configurar processo BGP

Router(config)#router bgp as-number

Configurar o vizinho VPNv4

BGP

Router(config-router)#neighbor {ip address | peer-group- name} remote-as as-numberRouter(config-router)#neighbor {ip address | peer-group- name} update-source interface-type interface-number

Configurar o BGP VPNv4

address family

Router(config-router)#address-family vpnv4 [unicast]Router(config-router-af)#neighbor {ip-address | peer- group-name} activateRouter(config-router-af)#neighbor {ip-address | peer- group-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 ati-var 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:



hostname PE1

router bgp 65500address-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) pre-serva 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 direta-mente 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 VPN_A redistribute connected exit-address-family

address-family ipv4 vrf VPN_B redistribute connected exit-address-family

As configurações nos roteadores Ps já foram feitas também na demons-traçã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.


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 Default RD Interfaces VPN_A 65500:1 Se1/0 Se2/0 VPN_B 65500:2 Se1/1

PE1#show ip vrf interfaces Interface IP-Address VRF ProtocolSe1/0 150.1.1.1 VPN_A up Se2/0 150.1.1.9 VPN_A up Se1/1 150.1.1.5 VPN_B up



Vejamos a tabela de roteamento global do PE1:

PE1#show ip route

172.1.0.0/32 is subnetted, 1 subnetsC 172.1.0.1 is directly connected, Loopback0 172.2.0.0/32 is subnetted, 1 subnetsi L2 172.2.0.1 [115/30] via 192.168.0.18, Serial1/3 172.10.0.0/32 is subnetted, 1 subnetsi L2 172.10.0.1 [115/20] via 192.168.0.14, Serial1/2 172.20.0.0/32 is subnetted, 1 subnetsi L2 172.20.0.1 [115/20] via 192.168.0.18, Serial1/3 192.168.0.0/30 is subnetted, 5 subnetsC 192.168.0.12 is directly connected, Serial1/2i L2 192.168.0.24 [115/20] via 192.168.0.18, Serial1/3i L2 192.168.0.28 [115/20] via 192.168.0.18, Serial1/3 [115/20] via 192.168.0.14, Serial1/2C 192.168.0.16 is directly connected, Serial1/3i L2 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 ta-bela 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

200.1.0.0/32 is subnetted, 2 subnetsS 200.1.0.1 [1/0] via 150.1.1.2S 200.1.0.3 [1/0] via 150.1.1.10 200.2.0.0/32 is subnetted, 1 subnetsB 200.2.0.2 [200/0] via 172.2.0.1, 00:36:28 150.1.0.0/30 is subnetted, 3 subnetsB 150.1.2.4 [200/0] via 172.2.0.1, 01:08:31C 150.1.1.0 is directly connected, Serial1/0C 150.1.1.8 is directly connected, Serial2/0

Podemos perceber que as tabelas de roteamento só exibem rotas específi-cas 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 roteamen-to BGP configurado entre os PEs e os CEs.


140 Redes MPLS

PE1#show ip route vrf VPN_A

200.1.0.0/32 is subnetted, 2 subnetsB 200.1.0.1 [20/0] via 150.1.1.2, 00:28:00B 200.1.0.3 [20/0] via 150.1.1.10, 00:45:16 200.2.0.0/32 is subnetted, 1 subnetsB 200.2.0.2 [200/0] via 172.2.0.1, 00:39:46 150.1.0.0/30 is subnetted, 3 subnetsB 150.1.2.4 [200/0] via 172.2.0.1, 00:39:46C 150.1.1.0 is directly connected, Serial1/0C 150.1.1.8 is directly connected, Serial2/0

PE1#show ip route vrf VPN_B

200.1.0.0/32 is subnetted, 1 subnetsB 200.1.0.2 [20/0] via 150.1.1.6, 00:47:14 200.2.0.0/32 is subnetted, 1 subnetsB 200.2.0.1 [200/0] via 172.2.0.1, 00:16:48 150.1.0.0/30 is subnetted, 2 subnetsC 150.1.1.4 is directly connected, Serial1/1B 150.1.2.0 [200/0] via 172.2.0.1, 00:16:48PE1#

Podemos novamente perceber a independência nas tabelas de roteamen-to, ou seja, cada VPN possui sua tabela independente, sem recebimento de quais-quer 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 configu-raçõ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:



CE11#ping 200.1.0.3Type 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 dife-rentes VPNs:

CE11#ping 200.1.0.2Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 200.1.0.2, timeout is 2 seconds:U.U.USuccess 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.USuccess rate is 0 percent (0/5)

Assim, podemos comprovar que não há conectividade entre clientes per-tencentes 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.1Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 200.1.0.1, timeout is 2 seconds:!!!!!


142 Redes MPLS

Para o processo dinâmico, usando o protocolo BGP

Novamente foram efetuados testes de conectividade entre mesmas e dife-rentes 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 msCE11#

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á co-nectividade 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 con-centrador, 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:



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) te-nham 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 impor-tadas 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 ro-tas provenientes do CE11 (HUB); portanto, não há conectividade entre os SPOKES.

CE22#show ip route

200.1.0.0/32 is subnetted, 1 subnetsB 200.1.0.1 [20/0] via 150.1.2.5, 00:31:11 200.2.0.0/32 is subnetted, 1 subnetsC 200.2.0.2 is directly connected, Loopback0 150.1.0.0/30 is subnetted, 2 subnetsC 150.1.2.4 is directly connected, Serial1/0B 150.1.1.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:

Figura 8.9 – Topologia Hub and Spoke


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, tornan-do-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, usan-do 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;



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 cer-tificando 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 fle-xibilidade 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, garan-tindo uma boa flexibilidade.

8.4.6 – QoS no MPLS

Os mecanismos de QoS usados no interior de um backbone servem exclu-sivamente 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 penali-dades 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 backbo-ne 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 si-mulação do ambiente QoS seguem na Tabela 8.2:


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.



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 po-dem variar, dependendo do tipo de chassi do equipamento e da versão do IOS:

Definir a classe Router(config)#class-map {match-all | match-any} name

Definir critério utilizado para

associar os pacotes às

classes

Router(config-cmap)#match anyRouter(config-cmap)#match [not] access-group {access-list--number | Name access-list-name}Router(config-cmap)#match [not] cos cos-value-1 [cos- value-2] [cos-value-3] [cos-value-4]Router(config-cmap)#match [not] atm clpRouter(config-cmap)#match [not] dscp dscp-value-1 [dscp- value-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-exp-value-1 [MPLS-exp-value-2] [MPLS-exp-value-3] [MPLS-exp-value-4] [MPLS-exp-value-5] [MPLS-exp-value-6] [MPLS-exp-value-7] [MPLS-exp-value-8]

Router(config-cmap)#match [not] protocol protocol-identifier-nameRouter(config-cmap)#match [not] qos-group qos-group-valueRouter(config-cmap)#match [not] vlan vlan-id

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


148 Redes MPLS

Defina a política

Router(config)#policy-map policy-map-name

Configure os parâmetros de

QoS por classes

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

Configure garantia de

banda por classe

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

Configure prioridade estrita para uma classe

Router(config-pmap-c)#priority

Defina a marcação do

pacote

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}]

Configure WRED

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



Configure policiamento

(policing)

Router(config-pmap-c)#police {cir cir} [bc conform-burst] {pir pir} [be peak-burst] [conform-action action [exceed-action action [violate-action action]]ORRouter(config-pmap-c)#police bps [burst-normal] [burst-max] conform-action action exceed-action action [violate-action action]ORRouter(config-pmap-c)#police cir percent percent [bc conform--burst-in-msec] [pir-percent percent] [bc peak-burst-in-msec]

Configure moldagem (shaping)

Router(config-pmap-c)#shape {average | peak} cir [bc] [be]ORRouter(config-pmap-c)#shape {average | peak} percent percent [bc] [be]ORRouter(config-pmap-c)#shape {average | peak} mean-rate [[burst-size] [excess-burst-size]]

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

Associar a po-lítica para uma

interface

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

Como a qualidade de serviço deve ser feita fim-a-fim, configuramos as po-lí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 ser-viç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 remar-cado 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 transmi-tido 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


150 Redes MPLS

caso de congestionamento, o tráfego de melhor esforço deve experimen-tar descarte aleatório.

• Saída do P1: o roteador P1 não precisa de uma política de entrada por-que 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 nes-ta 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 apli-caçõ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 ingres-so 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



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 defi-nido 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 trata-mento 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 implemen-taçã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 conhe-cidos 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.


152 Redes MPLS

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.

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



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 habilita-do em cada interface que possa alcançar um túnel TE.

Router(config)#mpls traffic-eng tunnelsRouter(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 re-servada 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-engRouter(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}


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 head- end, 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 ca-sos, o balanceamento de carga também poderá ser realizado entre os dois tipos.

Router(config)#ip explicit-path name {name} enableorRouter(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-idRouter(config-router)#network ip-address wild-card mask area area-idRouter(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-idRouter(config-router)#net network-entity-tittleRouter(config)#interface type numberRouter(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



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 rotea-dores 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.

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 back-bone. As rotas necessárias para este teste também foram inseridas no roteador PE1.

Observação: todas as configurações efetuadas nos roteadores e os testes rea-lizados encontram-se no Apêndice E desta obra.

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


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 estabelecimen-to 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



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 cami-nhos 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, utili-zado 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 é completa-mente 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.




158 Redes MPLS

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 propician-do 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 requeri-mento 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.


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





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


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 uni-direcionais 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 par-tindo 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ávelN(N-1)/2

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

Escalável – Full Mesh

QoS Apenas nas bordas Apenas nas bordas Fim-a-fim

TE ---- ---- Criação de túneis para distribuição de

carga



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

8.5 – IPv6 sobre MPLSPara 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ís-tica muito importante durante o atual período de transição.

As topologias utilizadas para as simulações dos ambientes 6PE e 6VPE es-tã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-labelRouter(config)#mpls ipv6 source-interface type number

Os comandos para configuração do 6VPE é similar aos comandos já vis-tos 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 protoco-lo de roteamento BGP.


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, IS-IS, BGP e até mesmo um roteamento estático, poderiam ser utilizados. Vale salien-tar 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 proces-so, é importante que seja feita uma filtragem de roteamento, para que apenas as rotas necessárias sejam transmitidas aos roteadores CEs, evitando grandes tabe-las 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 roteado-res 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



Tabela 8.4 – Endereços IPs utilizados para simulação

Roteador Int. Loopback0

Int. Serial1/0

Int. Serial1/1

Int. Serial1/2 Int. Serial1/3

CE11 2012:100::1/128 2012:11::2/64

CE22 2012:200::1/128 2012:22::2/64

E1 172.1.0.1/32 2012:11::1/64 192.168.0.13/30 192.168.0.17/30

PE2 172.2.0.1/32 2012:22::1/64 192.168.0.21/30 192.168.0.25/30

P1 172.10.0.1/32 192.168.0.14/30 192.168.0.22/30 192.168.0.29/30

P2 172.20.0.1/32 192.168.0.18/30 192.168.0.26/30 192.168.0.30/30

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 2C 2012:11::/64 [0/0] via ::, Serial1/0L 2012:11::2/128 [0/0]

Figura 8.23 – Topologia utilizada para o laboratório IPv6 – 6VPE


164 Redes MPLS

via ::, Serial1/0R 2012:22::/64 [120/2] via FE80::C808:14FF:FEC8:0, Serial1/0LC 2012:100::1/128 [0/0] via ::, Loopback0R 2012:200::1/128 [120/3] via FE80::C808:14FF:FEC8:0, Serial1/0L FE80::/10 [0/0] via ::, Null0L FF00::/8 [0/0] via ::, Null0

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 labelRoute 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 routeIPv6 Routing Table - 7 entriesCodes: 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 2C 2012:11::/64 [0/0] via ::, Serial1/0L 2012:11::2/128 [0/0] via ::, Serial1/0B 2012:22::/64 [20/0] via FE80::C807:19FF:FE18:0, Serial1/0LC 2012:100::1/128 [0/0] via ::, Loopback0B 2012:200::1/128 [20/0] via FE80::C807:19FF:FE18:0, Serial1/0



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

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 2012:11::1 48 msec 52 msec 40 msec 2 ::FFFF:192.168.0.18 116 msec 92 msec 92 msec 3 2012:22::1 108 msec 60 msec 100 msec 4 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.


167

Referências Bibliográfi cas

(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 ap-proach. 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


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.


168 Redes MPLS 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: <http://www.wireshark.org>. Acesso em: 25 abril 2012.

(Cisco, 2010) CISCO. Disponível em : <http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/iosip_an.pdf>. Acesso em: 28 abril 2012.

(Cisco, 2011) CISCO. Disponível em: <http://www.cisco.com/en/US/docs/net_mgmt/ip_solution_center/5.1/mpls_vpn/user/guide/ipv6.html>. Acesso em: 30 abril 2012.

(Cisco, 2012) CISCO. Disponível em: <http://www.cisco.com>. Acesso em: 28 abril 2012.

(Freesco, 2012) FREESCO. Disponível em: <http://www.freesco.org>. Acesso em: 28 abril 2012.


http://www.wireshark.org

http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/iosip_an.pdf

http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/iosip_an.pdf

http://www.cisco.com/en/US/docs/net_mgmt/ip_solution_center/5.1/mpls_vpn/user/guide/ipv6.html

http://www.cisco.com/en/US/docs/net_mgmt/ip_solution_center/5.1/mpls_vpn/user/guide/ipv6.html

http://www.cisco.com

http://www.freesco.org

170 Redes MPLS

(GNS3, 2012) GNS3. Disponível em: <http://www.gns3.net>. Acesso em: 29 abril 2012.

(Huawei, 2012) HUAWEI. Disponível em: <http://www.huawei.com>. Acesso em: 28 abril 2012.

(HP, 2012) HP. Disponível em: <http://h17007.www1.hp.com.> Acesso em: 28 abril 2012.

(Juniper, 2012) JUNIPER. Disponível em: <http://www.juniper.net>. Acesso em: 28 abril 2012.

(RFC 1058). Disponível em: <http://www.ietf.org/rfc/rfc1058.txt>. Acesso em: 28 abril 2012.

(RFC 1247) Disponível em: <http://www.ietf.org/rfc/rfc1247.txt>. Acesso em: 28/04/2012.












http://www.gns3.net

http://www.huawei.com

http://h17007.www1.hp.com

http://www.juniper.net

http://www.ietf.org/rfc/rfc1058.txt












170 Redes MPLS Referências Bibliográficas 171





(RFC 4271) Disponível em: <http://www6.ietf.org/rfc/rfc4271>. Acesso em: 28/04/2012.



(RFC 4364) Disponível em: <http://www6.ietf.org/rfc/rfc4364>. Acesso em28/04/2012.



(TFGEN, 2012) Disponível em: <http://www.st.rim.or.jp/~yumo/pub/tfgen.html>. Acesso em: 28/04/2012.

(Vytta, 2012) Disponível em: <http://www.vyatta.com>. Acesso em: 28/04/2012.

(YouTube, 2010) Disponível em: <http://www.youtube.com/watch?v=IzLPKuAOe50>. Acesso em: 28/04/2012.

(Zebra, 2012) Disponível em: <http://www.zebra.org>. Acesso em: 28/04/2012.






http://www6.ietf.org/rfc/rfc4271






http://www.st.rim.or.jp/~yumo/pub/tfgen.html

http://www.vyatta.com

http://www.youtube.com/watch?v=IzLPKuAOe50

http://www.youtube.com/watch?v=IzLPKuAOe50

http://www.zebra.org

173

APÊNDICE A. Confi guraçõ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 Loopback0ip address 172.1.0.1 255.255.255.255 ip router isis

interface Serial1/0 description connected to CE11 ip address 150.1.1.1 255.255.255.252

interface Serial1/2description connected to P1ip address 192.168.0.13 255.255.255.252 ip router isis mpls ip

interface Serial1/3description connected to P2ip 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


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


interface Loopback0 ip address 172.2.0.1 255.255.255.255 ip router isis

interface Serial1/1 description connected to CE22 ip address 150.1.2.5 255.255.255.252 interface Serial1/2description connected to P1ip address 192.168.0.21 255.255.255.252 ip router isis mpls ip interface Serial1/3description connected to P2ip address 192.168.0.25 255.255.255.252 ip router isis mpls ip


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



174 Redes MPLS Configurações – Funcionamento do MPLS 175

interface Serial1/0description connected to PE1 ip address 192.168.0.14 255.255.255.252 ip router isis mpls ip

interface Serial1/1description connected to PE2 ip address 192.168.0.22 255.255.255.252 ip router isis mpls ip

interface Serial1/2description connected to P2 ip address 192.168.0.29 255.255.255.252 ip router isis mpls ip


hostname P2

ip cef



interface Serial1/0description connected to PE1 ip address 192.168.0.18 255.255.255.252 ip router isis mpls ip interface Serial1/1description connected to PE2 ip address 192.168.0.26 255.255.255.252 ip router isis mpls ip interface Serial1/2description 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


176 Redes MPLS

Comandos para visualização:

Através do comando “show mpls interfaces”, podemos verificar se o enca-minhamento MPLS está habilitado nas interfaces. Vejamos o exemplo para o ro-teador P1:

P1#show mpls interfaces Interface IP Tunnel OperationalSerial1/0 Yes (ldp) No Yes Serial1/1 Yes (ldp) No Yes Serial1/2 Yes (ldp) No Yes

A coluna IP exibe “Yes” sempre que a comutação de rótulo está habilita-da 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 posterior-mente. 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


177

176 Redes MPLS

APÊNDICE B. Verifi caçã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/0Interface 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


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


179

178 Redes MPLS

APÊNDICE C. Confi guraçõ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


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 synchronizationredistribute 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


180 Redes MPLS 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 Loopback0ip address 200.1.0.1 255.255.255.255

interface Serial1/0 description Connected to PE1ip 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 Serial1/0 description Connected to PE1ip address 150.1.1.6 255.255.255.252 ip route 0.0.0.0 0.0.0.0 150.1.1.


182 Redes MPLS

hostname CE13

ip cef

interface Loopbackip address 200.1.0.3 255.255.255.255

interface Serial1/0 description connected to PE1ip 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 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 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.2ip route vrf VPN_A 200.1.0.3 255.255.255.255 150.1.1.10ip route vrf VPN_B 200.1.0.2 255.255.255.255 150.1.1.6



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.6ip 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 CE12router 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 synchronizationnetwork 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


184 Redes MPLS

hostname CE21

router bgp 200 no synchronizationnetwork 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-summaryhostname CE22

router bgp 100 no synchronizationnetwork 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 65500neighbor 150.1.2.5 allowas-in no auto-summary

hostname CE22

router bgp 100 no synchronizationnetwork 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 65500neighbor 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



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

As configurações do MP-iBGP podem ser visualizadas através dos coman-dos a seguir. Neste caso, para o roteamento estático. Vemos que só existe adja-cência BGP entre os PEs.

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

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd172.2.0.1 4 65500 317 315 11 0 0 00:55:46 2PE1#

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

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd172.1.0.1 4 65500 318 320 11 0 0 00:58: 3PE2#

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.


186 Redes MPLS

Com o comando a seguir podemos ver os rótulos das VPNs que são acres-centados no PE1:

PE1#show ip bgp vpnv4 all tags Network Next Hop In tag/Out tagRoute 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/17Route 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 65500BGP table version is 44, main routing table version 44

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd150.1.1.2 4 100 53 55 44 0 0 00:24:15 2150.1.1.6 4 200 45 45 44 0 0 00:40:08 2150.1.1.10 4 100 47 50 44 0 0 00:41:33 2172.2.0.1 4 65500 70 68 44 0 0 00:58:08 4

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

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd150.1.2.2 4 200 16 16 93 0 0 00:11:51 2150.1.2.6 4 100 43 44 93 0 0 00:37:59 2172.1.0.1 4 65500 307 289 93 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



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


188

APÊNDICE D. Confi gurações – MPLS – QoS

1. Política de entrada no PE1:class-map match-all BUSINESS-IP match ip dscp af21 af22 af23 class-map match-all PREMIUM-IP match 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


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 2 class-map match-all PREMIUM-MPLS match mpls experimental topmost 5

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 ipservice-policy output OUT-POLICY

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

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


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-all BUSINESS-IP match ip dscp af21 af22 af23 class-map match-all PREMIUM-IP match 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)


190 Redes MPLS 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


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 Transmitted Random drop Tail drop Minimum Maximum Mark pkts/bytes pkts/bytes pkts/bytes thresh thresh prob0 143/99866 0/0 0/0 20 40 1/101 0/0 0/0 0/0 22 40 1/102 0/0 0/0 0/0 24 40 1/103 0/0 0/0 0/0 26 40 1/104 0/0 0/0 0/0 28 40 1/105 0/0 0/0 0/0 30 40 1/106 162/10363 0/0 0/0 32 40 1/107 0/0 0/0 0/0 34 40 1/10rsvp 0/0 0/0 0/0 36 40 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 confir-mar 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.2Repeat count [5]: 50Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: ySource address or interface: 200.1.0.1Type 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/236/376 ms


Serial1/0.101




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.


194 Redes MPLS

CE11#pingProtocol [ip]: Target IP address: 200.2.0.2Repeat count [5]: 100Datagram size [100]: 10000Timeout in seconds [2]: 0Extended commands [n]: ySource address or interface: 200.1.0.1Type of service [0]: 0xB8Set 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)





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 funciona-lidade do PE1.



Vejamos também a constatação dos pacotes na classe business-ip, marcan-do o pacote com AF21 (ToS = 0x48) no CE11.

CE11#pingProtocol [ip]: Target IP address: 200.2.0.2Repeat count [5]: 50Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: ySource address or interface: 200.1.0.1Type of service [0]: 0x48Set 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


Serial1/0.101



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 <omitted>


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.2Repeat count [5]: 10Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: ySource address or interface: 200.1.0.1Type of service [0]: 0xB8Set 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



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<omitted>



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#pingProtocol [ip]: Target IP address: 200.2.0.2Repeat count [5]: 10Datagram size [100]: Timeout in seconds [2]: y% A decimal number between 0 and 3600.Timeout in seconds [2]: Extended commands [n]: ySource address or interface: 200.1.0.1Type of service [0]: 0xB8Set 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



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 (%)


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

<omitted>

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#pingProtocol [ip]: Target IP address: 200.2.0.2Repeat count [5]: 50Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: ySource address or interface: 200.1.0.1Type of service [0]: 0xB8Set 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



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<omitted>

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#pingProtocol [ip]: Target IP address: 200.2.0.2Repeat count [5]: 50Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: ySource address or interface: 200.1.0.1Type of service [0]: 0xB8Set 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

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 fos-se retirado no P2 (implicit-null) e as marcações em EXP não fossem possíveis.


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

<ommited>


201

200 Redes MPLS

APÊNDICE E. Confi guraçõ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/2mpls traffic-eng tunnelsip rsvp bandwidth 256 256

interface Serial1/3mpls traffic-eng tunnelsip rsvp bandwidth 256 256


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/0ip rsvp bandwidth 256 256mpls traffic-eng tunnels




P2#





router isis net 49.0172.0020.0000.0001.00is-type level-2-only metric-style wide mpls traffic-eng router-id Loopback0 mpls traffic-eng level-2


202 Redes MPLS Configurações – Engenharia de Tráfego 203

PE2#





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 co-mando a seguir, efetuado no roteador PE1:

PE1#show ip rsvp interface interface allocated i/f max flow max sub max Se1/2 100K 256K 256K 0 Se1/3 100K 256K 256K 0


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: disabledTUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROTPE1_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.1Name: 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



Name: PE1_t1 (Tunnel1) Destination: 172.2.0.1 Status: Admin: up 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 <omitted>

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 flow max sub max Se1/2 150K 256K 256K 0 Se1/3 100K 256K 256K 0

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 2629 seconds Periodic auto-bw collection: disabledTUNNEL NAME DESTINATION UP IF DOWN IF

STATE/PROTPE1_t0 172.2.0.1 -

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


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á ocor-rendo, sendo o túnel o próximo salto.

PE1#show ip route 172.2.0.1Routing 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#pingProtocol [ip]: Target IP address: 172.2.0.1Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: ySource 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]: rNumber of hops [ 9 ]: 4Loose, 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



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


1 192.168.0.14 [MPLS: Label 16 Exp 0] 152 msec 192.168.0.18 [MPLS: Label 16 Exp 0] 192 msec 192.168.0.14 [MPLS: Label 16 Exp 0] 60 msec 2 192.168.0.25 120 msec 192.168.0.21 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/3PE1(config-if)#shutdown

PE1#sh int tunnel 1Tunnel1 is up, line protocol is down

PE1#show ip route 172.2.0.1Routing 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



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.


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.1Routing 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 cus-tos 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.



1 192.168.0.18 [MPLS: Label 16 Exp 0] 124 msec 192.168.0.14 [MPLS: Label 16 Exp 0] 248 msec 192.168.0.18 [MPLS: Label 16 Exp 0] 156 msec 2 192.168.0.21 456 msec 192.168.0.25 92 msec 192.168.0.30 [MPLS: Label 22 Exp 0] 92 msec


209

208 Redes MPLS

APÊNDICE F. Confi gurações – IPv6

Para o 6PE:

Seguem-se as configurações finais dos roteadores CE11, CE22, PE1, PE2, P1 e P2.

hostname CE11ip cef

ipv6 unicast-routingipv6 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 CE22ip cef

ipv6 unicast-routingipv6 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/0description Connected to PE2no ip address ipv6 address 2012:22::2/64


210 Redes MPLS

ipv6 rip RIP enable ipv6 router rip RIP

hostname PE1

ip cef

ipv6 unicast-routingipv6 cefmpls label protocol ldpmpls ipv6 source-interface Loopback0


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


210 Redes MPLS Configurações – IPv6 211

hostname PE2ip cef

ipv6 unicast-routingipv6 cefmpls label protocol ldpmpls ipv6 source-interface Loopback0


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


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


212 Redes MPLS

hostname P1

ip cef



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


mpls ldp router-id Loopback0

hostname P2

ip cef










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




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 cefipv6 unicast-routingipv6 cef



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




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 cef



interface Serial1/1 description Connected to CE22 vrf forwarding VPN_A


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 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





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


hostname P2

ip cef



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




219

Índice Remissivo

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

Aacknowledgement 5alcançabilidade 24, 104algoritmo de Dijkstra 22Anycast 101ARIS – Aggregate Route-based IP Switching 26armazenamento de rota 11arquitetura de Serviços Diferenciados (DiffServ) 67Arquitetura de Serviços Diferenciados (DiffServ) 65arquitetura de Serviços Integrados (IntServ) 65Arquitetura MPLS VPN XIV, 51AS (Autonomous System) 15, 53ASICs (Aplication Specific Integrated Circuits) 41ASON (Automatically Switched Optical Network) 95ATM IX, 1, 2, 25, 26, 27, 29, 31, 37, 41, 42, 46, 48, 50,

58, 59, 61, 92, 110, 116, 124, 144, 151, 160atraso (delay) 64, 65, 160Atributos de túneis 93

BBellman-Ford 16best-effort 64BGP 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) 56BoS (Bottom of Stack) 30broadcast 101Business 146, 196

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

cabeçalho MPLS 25, 28, 29, 30, 31, 40, 41, 124cabeçalhos de calço (shim) 116CE – Customer Edge 51CEF IX, 117cell-mode 115, 116CIDR (Classless Inter-Domain Routing) 113circuito de acesso (AC) 61Circuito de Acesso (AC) 60circuito ponto-a-ponto 47, 58Circuitos Virtuais Privados (PVCs) 48circuito virtual 37, 41, 48, 61, 62, 128Circuito Virtual 60Cisco Express Forwarding IX, 117Classe AF (Assured Forwarding) 69Classe EF (Expedited Forwarding) 69classes de serviços 30, 71, 72, 100, 145, 149classes de tráfegos 64classful 16classificação 37, 71, 73, 75, 81, 145Classificação 71, 146Classificador de pacotes 66, 68classless 16class map 146Class Selector Codepoints 70comutação 1, 13, 14, 15, 86Comutação XIII, 12, 60comutação de rótulos 14, 15, 28, 32, 52, 86, 87, 92,

95, 103comutação IP 25, 26comutador Ethernet 109conexão 5, 21, 22, 24, 42, 44, 50, 60, 61, 66, 94, 104,

125, 126, 128, 130, 132, 133, 142, 145, 155confiabilidade 1, 8, 12, 24congestionamento 8, 12, 15, 64, 66, 69, 71, 73, 77, 78,

79, 80, 86, 88, 150Congestion Avoidance 79, 80Construção das tabelas de roteamento 38Controle de admissão 66Controle de fila 73controle de fluxo 5control plane 119, 120


220 Redes MPLS

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

DDados (payload) 12datagrama 6, 7, 8, 9, 10, 11, 12, 13, 26, 27, 29, 30, 37,

98descarte total (tail drop) 79DiffServ IX, XIV, 8, 36, 65, 67, 68, 69, 70, 78, 83DLCI IX, 29, 130, 132domínio de roteamento 20DSCP IX, 36, 68, 69, 70, 71, 72, 80, 81, 82, 83, 145DS (Differentiated Service) 69dual-stack 103, 106Dynagem 109Dynamips 109

EECMP (Equal-Cost Multi-Path) 22Edge LSRs 37, 40EGP (Exterior Gateway Protocol) 16, 24, 104EIGRP (Enhanced Interior Gateway Routing Protocol)

18encaminhamento dos pacotes na rede 41Encaminhamento dos pacotes na rede 39Endereçamento IPv6 101enfileiramento 30, 73Enfileiramento 73, 74, 76Enfileiramento com baixa latência 76Enfileiramento com prioridade 73, 74, 76Enfileiramento customizado 76Enfileiramento justo 74, 75, 76engenharia de tráfego 1, 41, 42, 85, 86, 87, 88, 89, 90,

91, 92, 94, 95, 113, 153, 156, 157, 160, 176Engenharia de tráfego 151Engenharia de Tráfego XIV, XV, 3, 43, 85, 202Enhanced Interior Gateway Protocol (EIGRP) 16escalabilidade 20, 36, 41, 42, 50, 51, 54, 67, 97, 112,

113Escalonador de pacotes 65estado de enlace (link state) 16Ethernet 31, 32, 46, 58, 59, 61, 72, 109, 124, 125excesso de tráfego 73EXP (Experimental Bits) 30

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

FEC (Forwarding Equivalence Class) 35FIB (Forwarding Information Base) 35FIFO (First-In First-Out) 73Flag 9fluxos TCP 79fragmentação 8, 9, 10, 97, 99frame-mode 115, 116, 119Frame 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 109fronteira-a-fronteira (edge-to-edge) 60Full Mesh 48, 50, 142, 144, 145

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

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

IIANA (Internet Assigned Numbers Authority) 15IBGP (Interior Border Gateway Protocol) 118ICMP (Internet Control Message Protocol) 10, 11Identificação 9IETF X, 8, 21, 26, 60, 65, 83, 91, 95IGP X, XV, 3, 15, 16, 20, 21, 24, 34, 56, 62, 87, 93, 104,

112, 118, 119, 124, 152, 153, 154, 155IGRP (Interior Gateway Routing Protocol) 17implicit-null 120, 200Implicit NULL Label 30inanição (starvation) 74infraestrutura da rede 15Ingresso dos pacotes na rede 38inner label 62, 115Interior Gateway Protocol (IGP) 56Intermediate System to Intermediate System X, 91,

102, 112IntServ XIV, 65, 67, 92inundação (flooding) 19IP DiffServ Code Point (DSCP) 36IP (Internet Protocol) 1, 5IP Navigator 26


220 Redes MPLS Índice Remissivo 221

IP Precedence 29, 36, 70, 72IPSec X, 48IP Switching 26IPv4 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 29IPv6 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 29IPv6 Provider Edge over MPLS 104IPv6 VPN Provider Edge 106IS-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, 104ISO-IDRP 16ISO (International Organization for Standardization)

23

Jjitter 64, 65, 69, 87, 90

Kkeepalive 75

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

153, 176LSP fim-a-fim 87, 92LSR X, 30, 34, 35, 36, 37, 38, 39, 40, 41, 46, 81, 82, 83,

84, 90, 93, 151LSR de Borda de Entrada 36LSR de Borda de Saída 37LSR (Label Switch Router) 34, 36

Mmarcação 71, 72, 81, 84, 145, 193Marcação 146mecanismos de QoS 92, 145Mecanismos de QoS XIV, 71melhor esforço (best-effort) 5, 64MF (More Fragments) 10modelo overlay 48, 50, 51modelo par-a-par XIII, 48, 50, 51Modelo par-a-par 50Modelos de VPN XIII, 48Modo de tubo curto (Short Pipe Mode) 83Modo de tubo (Pipe Mode) 84Modo uniforme (Uniform Mode) 83moldagem 71, 81Moldagem 78Moldagem (Shaping) 78MP-BGP 53, 54, 55, 102, 104, 105, 107, 113, 135, 137,

161MPLS Generalizado (Generalized MPLS) 94MPLS IP VPN 44MPLS-TE XIV, 42, 86, 87, 88, 89, 90, 91, 92, 93, 95, 151,

152, 153, 154, 155MTU (Maximum Transfer Unit) 9multicast 19, 34, 97Multicast 36, 101, 102MultiProtocol Label Switching – Traffic Engineering

86

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

OOffset (deslocamento) do Fragmento 10Olive 109Open Shortest Path First (OSPF) 16, 35OSI (Open Systems Interconnection) 23OSPF X, XIII, XIV, 16, 20, 21, 22, 23, 33, 35, 38, 39, 89,

90, 91, 95, 102, 104, 107, 112, 154, 162OSPF (Open Shortest Path First) 11, 102, 112OSPFv2 20, 21OSPFv3 21, 102, 104overflow 73overlay XIII, 41, 48, 49, 50, 51

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


222 Redes MPLS

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

21, 22, 23, 28, 33, 35, 38, 51, 94Protocolos de roteamento XIII, 15protocolos TDP/LDP 50provedores de serviço de Internet (ISPs) 43Provider Edge (PE) 60próximo enlace 34PseudoWire VII, XI, XIV, XV, 3, 43, 47, 58, 59, 60, 61, 63,

125, 126, 127, 129, 177PseudoWire End-Services (PWES) 60PWE (PseudoWire Emulation Edge-to-Edge) 60

QQoS 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 62qualidade de serviço 1, 25, 26, 43, 66, 67, 71, 89, 90,

149, 150Qualidade de serviço 65, 81Qualidade de Serviço XIV, 64, 98

RR5 (Merge Point) 94RD (Route Distinguisher) 53rede completamente conectada (Full Mesh) 48, 50Rede de Comutação de Pacotes (PSN) 60rede espalhada geograficamente (WAN) 12rede geograficamente distribuída 43rede multisserviço 58RED (Random Early Detection) 79reflooding 91reserva de recursos na rede 66, 67retardos 90retirada do rótulo MPLS (popping) 41RFC 1247 20, 170RFC 1723 17RFC 1771 54RFC 1883 96RFC 2080 17RFC 2460 97RFC 2597 69RFC 2598 69RFC 2858 54RFC 3107 44RFC 3630 89, 90RFC 3784 91RFC 4203 95RFC 4258 95RFC 4271 20RFC 4364 44RFC 4760 44RFC 5063 95RIP XI, 16, 17, 21, 22, 33, 102, 162RIPng (Routing Information Protocol next generation)

17, 102RIP (Routing Information Protocol) 17, 21RIPv2 17rotas IPv4 53, 56roteador CE 47, 56, 62, 122, 128, 155roteador de borda 29, 30, 38, 39, 51, 81, 134roteadores na rota (hop count) 17roteador 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, 137roteamento convencional 25Roteamento convencional XIII, 26roteamento dinâmico 12

roteamento 12, 134, 140roteamento estático 12

roteamento 12, 52, 104, 134, 137, 139, 140, 162, 181


222 Redes MPLS Índice Remissivo 223

roteamento explícito 85, 86roteamento por estado de enlace 18, 20, 22, 23roteamento por estado de enlace (link-state) 18roteamento por vetor de distância 16, 18ró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) 62rótulo do topo (top label) 32round-robin 75Router Alert Label 29Router distinguishers 107Routing Information Protocol (RIP) 16RSVP (Resource reSerVation Protocol) 66, 91RSVP-TE (Resource Reservation Protocol – Traffic

Engineering) 36, 91RT (Route Target) 55RT (Route Targets) 53

SSaída do pacote na rede 39segurança 1, 11, 16, 20, 43, 44, 48, 133Serviços Diferenciados (DiffServ) 65Shortest Path First IX, X, XI, 11, 16, 21, 22, 35, 89, 102,

112, 151sistema autônomo XV, 23, 53, 89, 114Sistema Autônomo 15SITA 26SLA (Service Level Agreement) 93, 145soft-state 67Soma Verificadora do Cabeçalho (checksum) 11SPF (Shortest Path First) 21STM (Synchronous Transport Module) 15switch 26, 41Switch 26, 30, 34, 36, 144

Ttabela de roteamento 12, 13, 15, 17, 19, 20, 22, 28, 34,

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

ToS (Type of Service) 7, 8, 68, 72traceroute 122, 124, 132, 160Traffic Engineering LSA 90troca de rótulos (Label Swapping) 39troca (swap) 41TTL (Time To Live) 30túneis XIV, 41, 44, 46, 47, 48, 83, 88, 92, 93, 94, 103,

107, 151, 152, 157, 158, 160, 205, 207, 208tunelamento 43, 46, 47, 61, 83, 88, 126túnel de backup 93, 94

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

VVersão 7vetor caminho (path vector) 20vetor de distância (distance vector) 16Virtual Routing and Forwarding XII, 53VLAN (Virtual Local Area Network) 61VLSM (Variable Length Subnet Mask) 22VPI/VCI (Virtual Path Identifier/Virtual Circuit

Identifier) 29, 116VPN de Acesso Remoto 45VPN Extranet 45VPN híbrida 44VPN Intranet 45VPN MPLS XIV, 46, 48, 51, 53, 55, 56, 144VPN par-a-par 51VPN Routing and Forwarding 107VPNv4 XIV, XV, 53, 54, 55, 56, 114, 115, 136, 137VPN (Virtual Private Network) 43, 44, 60VRF XII, 53, 55, 56, 107, 134, 135, 137, 138, 141, 143,

144, 161, 179Vyatta 109

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

YYouTube 21

ZZebra 109


Redes MPLS Fundamentos e Aplicações

Documents

Transcript of Redes MPLS Fundamentos e Aplicações