Mutiprotocol Label Switching (MPLS)

Transcrição

1 Mutiprotocol Label Switching (MPLS) Paradigima de Roteamento Tradicional Sabemos que a arquitetura tradicional de roteamento utiliza como base o IP de destino de um pacote para tomar a descisão de roteamento (rotear) o pacote. Tal paradigma foi utilizado por muito tempo e altamente desenvolvido e implementado em redes tradicionais, principalmente na maior rede do mundo a internet, portanto tal paradigma tem seu crédito, pois foi competente suficiente para escalar. Redes tracionais fazem o roteamento de pacotes via o IP de destino inserido cabeçalho IP, cada roteador através de seus protocolos de roteamento montam suas tabelas de roteamento(estático, OSPF, BGP, IS-IS, EIGRP e etc) e encaminham tráfego de forma independente. Todos os pacotes seguem sempre o mesmo caminho entre a origem e destino do tráfego quando temos somente uma melhor rota para o destino, quando temos duas ou mais rotas com mesmos parametros (mascara, métrica e AD) temos um empate e podemos efetuar ECMP (Equal Cost Mutiple Path) o famoso compatrtilhamento de carga (loadsharing). Porem tal paradgima de encaminhamento de tráfego tem restrições e tais restrições diminui a flexibilidade de uma rede, principalmente de um Provedor de Serviço (Service Provider). Problemas com Engenharia de Tráfego na Rede Agora que revisamos como uma rede tradicional IP funciona, vamos ver suas ineficiencias, a primeira que podemos citar é o que diz respeito a engenharia de tráfego. Vejamos a figura abaixo: CCNA SP V1.0 Pag. 540

2 CLIENTE A CLIENTE A R4 R5 5Mbps 5Mbps PE PE 10Mbps R1 R2 10Mbps 10Mbps PE 10Mbps 10Mbps R7 R3 CLIENTE B R6 CLIENTE B Figura 215 Problemática Engenharia de Tráfego Veja que temos dois clientes na figura acima cliente A e cliente B, se levarmos em consideração a soma da banda de cada cliente temos um total de 15Mbps, porem os links de backbone entre os equipamentos da operadora são somente de 10Mbps cada, tanto entre R1 e R2, R1 e R2 e R3 e R2. Podemos perceber que temos um problema nesta rede, de acordo com o paradgima de encaminhamento padrão do IP que é IP de destino ambos os clientes tendem a trafegar pelo mesmo link, vejamos: CCNA SP V1.0 Pag. 541

3 CLIENTE A 5Mbps CONGESTIONAMENTO 15Mbps em um link de 10Mbps 5Mbps descartados CLIENTE A R4 R5 5Mbps PE PE 10Mbps R1 R2 10Mbps 10Mbps 10Mbps PE 10Mbps 10Mbps R7 R3 CLIENTE B R6 CLIENTE B Figura 216 Congestinamento em links Para resolver tais problemas podemos pensar: Se eu alterar o custo do roteamento da rede aumentando o custom entre o link R1 - R2, ou então, diminindo o custo nos links entre R1- R3 e R3 R2, vejamos o que acontece: CLIENTE A 5Mbps CONGESTIONAMENTO 15Mbps em um link de 10Mbps 5Mbps descartados CLIENTE A R4 R5 5Mbps PE PE 10Mbps R1 R2 10Mbps 10Mbps 10Mbps PE 10Mbps 10Mbps R7 R3 CLIENTE B R6 CLIENTE B Figura 217 Congestinamento em links CCNA SP V1.0 Pag. 542

4 Percebemos então que o paradgima de roteamento IP tradicional impoem alguns problemas no que diz respeito à engenharia de tráfego da rede, pois cada equipamento da rede faz o encamihamento de forma independente. É claro que existem soluções para tal problemática como Policy Based Routing (PBR) entre outras, porem tais soluçoes não são escaláveis em uma rede de grande porte como um Backbone de um Provedor de Serviço (Service Provider). Para resolver tal situação fica evidente que temos que fazer o encaminhamento de pacotes na rede utilizando outra informação em vez do IP de destino, foi então que foi introduzido o conceito de label (rótulo), utilizando label o dispositivo de entrada de tráfego pode sinalizar a rede por onde tal tráfego irá trafegar de sua origem a seu destino, com a utilização de label podemos tomar descição de encaminhamento de tráfego baseado em outros parametros alem do IP de destino (legado), como por exemplo, QoS, Custo monetário, SLA dos links e etc. Problemas Rotas Externas(BGP) Propagadas no Core da Rede Utilizando o paradigma de encaminhamento IP tradicional, faz-se necessário que rotas externas da rede de um provedor, como tabela completa do BGP da internet (BGP Full-Routing) seja propagado para sua rede interna como roteadores de core e borda, pois caso tal roteador não tenha uma rota para o destino final, tal equipamento irá descartar pacotes, vejamos: CLIENTE A UPSTREAM INTERNET R4 R5 PE R8 PE R1 R2 PE R7 R3 CLIENTE B R6 UPSTREAM INTERNET Figura 218 BGP Full Routing em Roteadores de Core CCNA SP V1.0 Pag. 543

5 Tal arquitetura de encaminhamento de tráfego traz diversos problemas para a rede no que diz respeito a processamento e memória, no exemplo acima temos dois links de UPSTREAM recebendo a tabela completa BGP Full-Routing, nos dias atuais tal tabela completa esta em torno de 500 mil rotas, o que necessita de aproximadamente 512MB de memória por tabela complexa, como no exemplo acima temos duas tabelas precisamos de aproximadamente 1GB de memória RAM, sem contar o processamento do equipamento, o protocolo BGP executa um processo chamado BGP Scanner, tal processo tem é dispendioso para a CPU do equipamento. Percebendo tais ineficiencias faz-se necessário alivar a quantiade de informações que o core da rede necessita receber, precebemos então que o roteamento tradicional baseado IP deve ser alterado e ser baseado em outra informação chamada label. MPLS Como Solução para todos os problemas Multiprotocol Label Switching (MPLS) é o resultado de um grande trabalho de membros da IETF que desenvolveram inicialmente o documento (draft-ietf-mplsframework) tal documento descreve um novo paradigma de encaminhamento de tráfego baseado em label (Rótulos em português). Tal paradigma é a solução para todas as ineficiencias citadas no paragrafo anterior, mas como isso funciona na prática. Na prática a idéia do MPLS é combiner o melhor do mundo de switching de camada 2, com o melhor do roteamento de camada 3, o encaminhamento daqui pra frente não é mais realizado via o IP de destino do frame e sim via um label MPLS de tamanho fixo. Alem de resolver todas as ineficiencias citadas acima que veremos em detalhes o MPLS habilita uma serie de aplicações na rede, que é um dos maiores motivadores para o uso do MPLS como: L3-VPN: VRF L2-VPN: ATOM, EoMPLS Engenharia de Trafego: MPLS-TE Transporte de IPv6: 6PE / 6VPE Entre outras Para entendermos como o MPLS funciona na prática precisamos entender sua arquitetura. Arquitetura do MPLS A Arquitetura do MPLS é baseada em dois componentes, Plano de Controle (Control-Plane) e Plano de encaminhamento de Dados (Data-Plane). Plano de Controle (Control-Plane ) É uma abastração que descreve todos os calculos que são realizados pela CPU de um equipamento, é onde temos os CCNA SP V1.0 Pag. 544

6 algoritimos sendo executados, por exemplo: BGP, OSPF, STP entre outros. Quando falamos de calculos em software falamos de Plano de Controle (Control-Plane). Plano de encaminhamento de dados é abastração que descreve o processo de encaminhamento de pacotes, frames, dados e etc. Por exemplo, em redes ip tradicionais, apos todos os calculos é montada a tabela de roteamento, quando roteador recebe um pacote, faz-se uma pesquisa nesta tabela de roteamento que irá informar qual interface deve encaminhar o pacote, toda esta ação de pesquisa na tabela de roteamento é chamado de Plano de Encaminhamento de Dados (Data Plane). O Plano de Controle é responsável por todos os calculos da rede, após tais calculos serem realizados, é criada uma tabela chamada de Label Forwarding Information Base (LFIB), tal tabela é utilizado pelo Plano de Encaminhamento de Dados para encaminhar pacotes MPLS. O Plano de Controle é responsável por criar e manter a LFIB que sera utlizado pelo Plando de encaminhamento de Dados (Data-Plane). Plano de Controle (Control-Plane) Protocolos de Roteamento (OSPF, IS-IS, EIGRP, RIP) Troca de informações de Protocolos de Roteamento Tabela de Roteamento Protocolo de Controle MPLS Troca de informações de Label (Rótulos), Pacotes MPLS Plano de Encaminhamento de Dados (Data Plane) Tabela de Encaminhamento do MPLS Label Forwarding Information Base (LFIB) Pacotes MPLS Figura 219 Arquitetura MPLS CCNA SP V1.0 Pag. 545

7 Protocolos de roteamento Com MPLS não eliminamos os protocolos de roteamento, mesmo afirmando no paragrafo acima que não realizamos mais o encaminhamento de tráfego baseado em IP de destino e sim em label, ainda necessitamos da tabela de roteamento para provissionar os caminhos na rede chamados de Label Switching Path (LSP), porem veremos o quão eficiente sera nossa tabela de roteamento daqui em diante, para adiantar afirmo que praticamente necessitamos somente da tabela de roteamento de prefixos internos, roteados pelo IGP de nossa rede, mais precisamente dos prefixos /32 de todas as loopback, ok vamos com calma, entenderemos mais a frente esta afirmação. Tabela de Roteamento Mesma lógica descrita acima, ainda manteremos nossa tabela de roteamento, mas veremos mais a frente que sera mais eficiente. Troca de informações de Label () Veremos com mais detalhes que este componente do plano de controle, mas especificamente o protocolo chamado Label Distribution Protocol é responsável por trocar label entre equipamentos vizinhos para que toda rede tenha mapeamento de label. Label Information Forwarding Tabel (LFIB) É uma tabela que é reponsável que será utilizada pelos equipamentos para pesquisas e serivrá como base para o encaminhamento de pacotes MPLS. Componentes e Terminologia em Rede MPLS Assim como qualquer tecnologia temos as terminologias e componetes que fazem parte da arquitetura. Domínio MPLS (MPLS Domain) É a parte da sua rede onde temos o encaminhamento de dados baseado em label. Label Switch Router () Terminologia atribuída a todos os switches que efetuam encaminhamento de pacotes baseado em label pode ser um roteador, switch L3, Switch ATM etc. Temos diversos subtipos de : Edge-: Equipamento localizado na borda da rede, onde delimita o final da rede tradicional IP e o inicio da Rede MPLS ou vice versa. Tal equipamento tem duas funções principais: Label Imposition Ação de inserir um ou mais (label stack) label em um pacote IP tradicional. Label Disposition Ação de retirar um ou mais label (label stack) de um pacote MPLS deixando somente o IP. Qualquer equipamento que tem pelo menos uma interface e um vizinho em um rede IP Tradicional e atual também no dominio MPLS é considerado um Edge-, tal equipamento atua tanto com a tabela de roteamento padrão quanto com as informações a LFIB, pois encaminhará tráfego para ambas as direções (Rede IP Tradicional e MPLS). Na figura abaixo podemos verificar cada componente descrito de uma rede MPLS. CCNA SP V1.0 Pag. 546

8 Edge- R2 R4 R8 Edge- DOMÍNIO MPLS (MPLS DOMAIN) Edge- R6 R7 R1 R3 R5 R9 Figura 220 Domínio MPLS Adicionando Label na Borda da Rede Confrome ja apresentado label imposition é o termo que descreve a ação de um Edge- adicionar um ou mais label em um pacote IP antes de envia-lo pelo dominio MPLS, em uma rede IP tradicional o processo de roteamento é baseado em duas partes: Primeiro é associar todos os prefixos de rede a uma determinada rota encontrada na tabela de roteamento, em ultimo caso utilizando a rota default. Segunda função é associar cada prefixo a uma interface ou endereço de próximo salto (next-hop) que indica para onde devemos encaminhar um determinado pacote que com ip de destino associado a um determinado prefixo. Em MPLS temos a associação da primeira função descrita acima nomeada agora como Forwarding Equivalence Class (FEC), que significa pacotes que são encaminhados pelo mesmo caminho, recebendo a mesma tratativa de encaminhamento, porem em MPLS o conceito de FEC é mais abrangente se comparado a primeira função de IP, pois podemos classicar tal conjunto de pacotes não somente de acordo com o IP de destino porem podemos utilizar outros parametros como por exemplo: Todos os pacotes que tem o DSCP igual a EF, ou todos os prefixos do BGP recebidos de um peer externo (ebgp) em resumo FEC em MPLS é classificado pelo Edge- de acordo com sua escolha e definição. Mas como isto é possivel? Pelo seguinte fato em IP tradicional após pesquisar a tabela de roteamento e achar uma comparação com um prefixo o pacote e encaminhado e desta trativa e forma sera realizado em cada salto da rede até seu destino. Em MPLS quando o Edge- classifica o pacote pertencente a um FEC é adicionado um label e inserido tal pacote que agora é MPLS no dominio MPLS, dentro do dominio CCNA SP V1.0 Pag. 547

9 MPLS iremos encaminhar o pacote através de pesquisa em label e não mais em pacote, veja que este label tem uma maior abrangencia, ou seja, pode siginificar pacotes com os mesmos parametros de QoS, ou pacotes com o mesmo ebgp Next-HOP, ou como o ip pertencente ao mesmo prefixo, ou seja, utilizando label eu dessasocio o encaminhamento de tráfego baseado em IP de destino e habilito outras classificações para encaminhar o tráfego. Label Binding Até o momento explicamos como funciona uma rede MPLS e sabemos que o encaminhamento de tráfego é baseado em label, porem como tais label são criados ou alocados, veremos com detalhes neste paragrafo. Para iniciar conforme explicado anteriormente temos o conceito de FEC que é uma associação de pacotes que sera dada a mesma trativa e podemos expandir tais tratativas, pois bem para cada FEC criada em um roteador é associado um label a mesma, veja que cada roteador atribui seu label para sua classificação de FEC de forma independente, para enteder melhor vamos dizer que um roteador classifica uma FEC da mesma forma que o IP tradicional, ou seja, cada prefixo na tabela de roteamento. É criado então um label para cada prefixo na tabela de roteamento e inserido em uma tabela chamada Label Information Base (LIB), indepente do protocolo utilizado (RIP, IS-IS, OSPF, EIGRP, ROTAS ESTÁTICAS). OBS: Por padrão label não são atribuído por rotas apreendidas via BGP, as rotas BGP herdarão por padrão o label de seu proximo salto (Next-Hop) que será normalmente um prefixo apreendido via igp. A Tabela FIB esta sempre sincronizada com a table de roteamento, ou seja, quando um novo prefixo é inserido, na tabela um label é criado para o mesmo. CCNA SP V1.0 Pag. 548

10 Tabela de Roteamento Tabela de Roteamento /24 via R /24 via R /24 via R /24 via R /24 via R /24 via R /24 via R /24 CONECTADO R /24 CONECTADO /24 via R /24 CONECTADO /24 CONECTADO /24 via R /24 via R /24 via R /24 via R /24 Edge- R / /24 OSPF /24 Edge- R6 R7 R / / / /24 R3 R5 LIB /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local 77 LIB /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local 87 R9 Figura 221 Tabela LFIB Faz-se necessário então a troca de informações entre vizinhos desta forma cada roteador saberá o label utilizado pelo seu vizinho, tal distribuição de label entre equipamentos é feito via o protocolo chamado Label Distribution Protocol () que estabelece sessões TCP entre vizinhos e envia toda sua LIB para os mesmos. CCNA SP V1.0 Pag. 549

11 LIB /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local 97 LIB /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local 207 LIB /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local 307 Edge- R7 LIB /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 R1 LIB /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local / /24 R2 LIB R /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 OSPF /24 R4 R /24 LIB / /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local 407 Edge- R /24 R9 LIB /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local 507 Figura 222 Tabela LFIB Local CCNA SP V1.0 Pag. 550

12 LIB /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R1 87 Edge / /24 R /24 OSPF R /24 Edge- R6 R7 R / / / /24 R3 R5 LIB LIB LIB /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local 107 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R3 107 Figura 223 Tabela Após troca do CCNA SP V1.0 Pag. 551

13 Todos os equipamentos então saberão tanto os label atribuidos locais, como recebidos de vizinhos, ou seja, temos todas as informações de label da rede, como fazemos então para saber qual label utilizar? Por padrão ocorre uma sincronia entre a tabela de roteamento e a LIB, é realizado calculos na tabela de roteamento, convencionalmente via os protocolos de roteamento, para melhor rota escolhida teremos um vizinho (nexthop) então verifica se se este vizinho informou seu label para tal rota e tal label será utilizado para encaminhamento de tráfego, é montado uma outra tabela final somente com os label que realmente são utilizado no momento, chamada de label forwarding information base (LFIB). Esta tabela LFIB é um subset da tabela LIB somente com as informações relevantes e que serão realmente utilizadas, porem perceba que temos que manter a LIB ainda, pois em caso de falha e convergencia da rede os caminhos da tabela de roteamento IGP podem mudar e então teremos alteração da tabela LFIB que utilizará agora outros prefixos da LIB. CCNA SP V1.0 Pag. 552

14 Tabela de Roteamento /24 CONECTADO /24 CONECTADO /24 via R /24 via R /24 via R /24 via R /24 via R /24 CONECTADO / /24 R /24 OSPF Edge- R /24 Edge- R6 R7 R / / / /24 R3 R5 LIB /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R /24 R3 107 LFIB /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 R /24 R /24 R /24 R /24 R3 104 R9 Figura 224 LFIB Final Podemos perceber então que a LFIB final será guiada pela tabela de roteamento do IGP e formaremos o que chamamos de Label Switch Path na rede que sinifica um caminho entre uma origem e um destino onde o encaminhamento de tráfego será via Labels MPLS. CCNA SP V1.0 Pag. 553

15 Encaminhamento MPLS e Label Switch Path (LSP) Agora que sabemos como funciona a troca de label e a montagem das tabelas LIB e LFIB que são montadas por mecanismos do Plano de Controle (Control-Plane), veremos então como funciona o encaminhamento de dados na rede (Data-Plane). Todo pacote que entra no dominio MPLS via um Edge-lSR é inserido um label, tal label sera utilizado como parametro base de encaminhamento, em cada salto da rede tal label sera trocado (veremos mais a frente) e no Edge- de destino do pacote, ou seja, no final do dominio MPLS o label é retirando e enviado a rede IP tradicional. A cada equipamento que o pacote atravessa é efetuado a ação de label swapping, que significa que o label de entrada é subistituido pelo label de saída, até que tal frame chege na saída da rede. Vejamos: LIB LOCAL LIB LOCAL LIB /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local 77 Tabela de Roteamento LIB /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local 97 Tabela de Roteamento /24 via R /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local 207 Tabela de Roteamento /24 via R6 LIB LOCAL /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 via R1 Tabela de Roteamento /24 via R /24 PACOTE /24 R2 PACOTE /24 OSPF Edge- R / /24 via CONECTADO PACOTE 306 Tabela de Roteamento R6 Edge- R7 PACOTE 86 R / / / /24 R3 R5 LFIB LFIB LFIB LFIB /24 local /24 R /24 local /24 R /24 local /24 R /24 local /24 R6 306 LFIB R9 IGNORE O PROCESSO DE PHP SIMPLIFICAÇÃO DA EXPLICAÇÃO /24 local 306 Figura 225 Trafegando pelo Domínio MPLS Este mecanismos cria o conceito de Label Switch Path (LSP) que seria o caminho que o trafego MPLS atravessa até chegar em seu destino. Um LSP sera sempre unidirectional, ou seja, para ida e volta do tráfego, necessitamos de um dois LSP. O Estabelecimento de um LSP é orientado a conexão pois o LSP tem que ser criado antes do fluxo de pacotes MPLS, porem tal conexão é criada CCNA SP V1.0 Pag. 554

16 de acordo com as informações da topologia e não baseado no fluxo de tráfego na rede. LABEL SWITCH PATH (LSP) PACOTE 206 PACOTE 306 PACOTE 96 R2 R4 PACOTE 86 MPLS R6 R7 R1 R3 R5 IGNORE O PROCESSO DE PHP SIMPLIFICAÇÃO DA EXPLICAÇÃO R9 Figura 226 Trafegando pelo Domínio MPLS Penultimate Hop Popping Conforme explicado até o momento vimos que em MPLS fazemos então o encaminhamento de tráfego baseado em label, quando tal pacote MPLS chega no final da rede, ou seja, Edge- de saída temos que retirar o label e enviar tal frame a rede tradicional IP, percebemos então que tal equipamento Edge- retira o label final e faz-se necessário efetuar uma pesquisa em sua tabela de roteamento tradicional, vejamos: CCNA SP V1.0 Pag. 555

17 LABEL SWITCH PATH (LSP) 1 - RETIRA-SE O LABEL 2- PESQUISA A TABELA DE ROTEAMENTO PACOTE 206 PACOTE 306 PACOTE 96 R2 R4 PACOTE 86 MPLS R6 PACOTE IP R7 R1 R3 R5 IGNORE O PROCESSO DE PHP SIMPLIFICAÇÃO DA EXPLICAÇÃO R9 Figura 227 Trafegando pelo Domínio MPLS Perceba que R6 ao contrário dos outros s tem que fazer o trabalho em dobro, pois alem de fazer parte o do label swaping que seria retirar o label, necessita ainda fazer um lookup na tabela de roteamento, tais ações tendem a aumentar o processamento caso seja um roteador que fazer o encaminhamento baseado em software (Software Based Router) e para implementar ambas funções (retirada do label e pesquisa da tabela de roteamento) em hadrware que são a maioria dos equipamentos atuais (hardware based router) sua implementação torna-se complexa e exigira processadores ASCII mais complexos e caros. Desta forma foi otimizado tal funcionamento na rede utilizando um conceito chamado de Penultimate Hop Popping. Tal conceito tem a seguinte teoria, retiramos o label do pacote um salto antes (hop antes) do destino final, ou seja, ultimo roteador, desta forma dividimos pela metado o trabalho para cada equipamento: Penultimo roteador (PHP) realiza o trabalho de retirada do label, que seria a mesmo trabalho que faz atualmente de label swapping, porem trocando label de entrada por nenhum de saída (retirando o label). Último roteador - faz a outra metade do trabalho fazendo somente pesquisa na tabela de roteamento. Desta forma podemos implementar a mesma função porem de forma mais simplificada para os processadores, tanto para roteadores baseado em Software (Software Based Router) como para roteadores baseado em hardware (Hardware Based Router). Vejamos: CCNA SP V1.0 Pag. 556

18 LIB LOCAL AÇÃO DE PHP /24 local /24 local /24 local /24 local /24 local /24 local /24 local /24 local 307 Edge- Tabela de Roteamento PACOTE /24 via CONECTADO /24 PACOTE /24 R /24 OSPF R4 PACOTE /24 R6 Edge- R7 PACOTE 86 R / / / /24 R3 R5 LFIB LFIB LFIB LFIB /24 local /24 R /24 local /24 R /24 local /24 R /24 local /24 R6 3 (POP) LFIB R9 IGNORE O PROCESSO DE PHP SIMPLIFICAÇÃO DA EXPLICAÇÃO /24 local 3 Figura 228 Trafegando pelo Domínio MPLS LABEL SWITCH PATH (LSP) 1 - RETIRA-SE O LABEL PACOTE 206 PACOTE 2- PESQUISA A TABELA DE ROTEAMENTO PACOTE 96 R2 R4 PACOTE 86 MPLS R6 PACOTE IP R7 R1 R3 R5 IGNORE O PROCESSO DE PHP SIMPLIFICAÇÃO DA EXPLICAÇÃO R9 Figura 229 LSP Com PHP Label Distribution Protocol Agora ja temos uma boa visão e conhecimento de como o MPLS realmente funciona, pois bem agora iremos nos aprofundar em seus protocolos, principalmente no que diz respeito a novos protocolos como o Label Distribution Protocol (). CCNA SP V1.0 Pag. 557

19 Tal protocolo é reponsável por realizar a troca de label entre equipamentos, em outras palavras pela troca da LIB (Label Information Base). Neste livro não abordaremos o protocolo Tag Distribution Protocol (TDP) proprietário da Cisco System, pois o mesmo ja foi descontinuado e não é mais utilizado. O estabelece sessões TCP entre equipamentos e realiza a troca da LIB entre os mesmos. Novamente para lembras o conteúdo da LIB são as FEC que são agrupamentos de IPs que serão encaminhados da mesma maneira no ambiente de rede. Estabelecimento de sessões Quando é habilitado MPLS em um roteador o processo do é iniciado junto, configuramos então interfaces que farão parte do dominio MPLS e habilitamos em tais interfaces o protocolo para troca de label, tais interfaces iniciaram então o processo de descoberta de possiveis vizinhos conectados ao ambiente de rede, tal mecanismo se baseia no envio de frames UDP com IP e MAC de destino Multicast. Vizinhos conectado no mesmo dominio de broadcast (vlan) se descobriram pois perceberão o pacote hello um dos outros. Após a descoberta de vizinhos o pacote hello informará a cada vizinhos quais são os parametros dos mesmos, será então estabelecido sessão TCP entre os vizinhos, no caso do é utilizado a porta TCP 616 (O antigo TDP utilizava para hello frames broadcast e para sessão TCP 717). O protocolo é baseado no frameword de implementação chamado TLV (Type, Length, Value). Suas principais mensagens são: Hello Responsável pelo estabelecimento de vizinhaça do Notification Responsável por notificar vizinhos que divergencias Keapalive Responsável por manter a vizinhaça, detectar continuamente a presença de seu vizinho. Label Mapping Responsável por informar a associação de label com uma FEC. Address Responsável por informar ao vizinho os Endereços IP associados a cada interface. Address Withdraw - Responsável por informar ao vizinho um ou mais Endereço(s) IP(s) associado(s) a uma interface não existe mais. Label Mapping Responsável por enviar uma associação entre FEC e seu label correspondente (LIB). Label Request Responsável por solicitar a um vizinho um determindo Label CCNA SP V1.0 Pag. 558

20 Label Withdraw Responsável por informar um vizinho que um determinado mapeamento de label e FEC que foi previamente informado não pode ser mais utilizado. Label Release Responsável por informar um vizinho que um local não necessita mais de um label requisitado e/ou informado por um vizinho previamente. Associação de Label e Distribuição (Label Binding and Distribution) Já sabemos que para cada prefixo na tabela de roteamento apreendido via IGP (FEC), temos um label associado e ja sabemos que a distribuição de label entre roteadores vizinhos e via o protocolo, pois bem agora veremos algumas considerações em relação a como alocar, manter e distribuir label. Assim que o roteador tem uma nova entrada na tabela de roteamento um label local é atribuído ao mesmo e anuncioado a seus vizinhos via este método de alocação e label é chamado de Controle Independente (independent control label assignment) e este método de distribuição de label chama-se Distribuição de Label sem Prévia Solicitação de Downstream(unsolicited downstream label distribution). Ou seja: Um Label é alocado a um prefixo é realizado indepdentemente se o roteador recebeu um label via para o next-hop do prefixo, por isso Controle Independente (independent control label assignment). A distribuição de label não necessita de uma previa solicitação pois um distribui sua associação de Prefixos (FEC) e label, ou seja, sua LIB independente se seu vizinho solicitou por isso Distribuição de Label sem Prévia Solicitação de Downstream(unsolicited downstream label distribution). Uma observação importante é que não existe nenhum mecanismo de splithorizon para distribuição de labels, ou seja, posso distribuir meu label a um viznho mesmo que minha melhor rota para tal prefixo seja para este mesmo vizinho e não temos a possibilidade de loop na rede pois a tabela de roteamento irá ser o guia para montagem da LFIB final e sabemos que na tabela de roteamento temos varios mecanismo de proteção contra loops, então indiretamente a LFIB também herda esses controles. CCNA SP V1.0 Pag. 559