Desvendando o MPLS - Webcast FAQ

 


Introdução


   



 

Leonardo Furtado é Instrutor e Facilitador do High Touch Delivery Learning Services (Cisco Advanced Services' Education), onde atua em diversos países lecionando para clientes da Cisco sobre treinamentos avançados de plataformas tais como ASR 9000, Carrier Routing System (CRS), ASR 1000, ASR 900, dentre outras, além das tecnologias determinantes para as arquiteturas Carrier Ethernet de última geração. Possui formação em Ciência da Computação e 21 anos de experiência no mercado nas funções de engenheiro de redes e arquiteto de soluções, com passagens em empresas como Banco Bozano Simonsen, Banco Santander, New York Stock Exchange e American Stock Exchange (NYSE Euronext), 2R Datatel, Algar Tech e Gifará Serviços Avançados em TIC. Possui ampla vivência em arquiteturas de Service Providers e Data Centers, sendo estes seus segmentos de maior especialidade e interesse. É um Certified Cisco Systems Instructor (CCSI).
 
Você pode fazer o download da  apresentação em formato PDF aqui

 




Desvendando o MPLS



 

Q: Trabalho na SEEDUC RJ e estamos deixando o MPLS para usar internet local devido ao corte de custos no Estado do RJ.
A pergunta que faço é, qual seriam as perdas e ganhos com essa mudança de tecnologia?

A: Antes de responder a sua pergunta diretamente, aproveitarei a oportunidade para fornecer uma visão mais ampla deste caso que você está reportando, e conectarei os pontos lá na frente. Será mais produtivo!

As facilidades e capacidades do MPLS que foram apresentadas neste Webcast são primariamente notadas em suas propriedades pelas Operadoras/Provedores, ficando o MPLS, no ponto de vista de clientes e usuários finais destes provedores, praticamente "invisível", particularmente no que tange ao que ocorre dentro da rede MPLS da operadora. É comum alguns profissionais de redes afirmarem que "temos um link MPLS lá na empresa", embora na verdade o enlace físico e lógico que conecta o roteador do cliente com a operadora não possua qualquer configuração de MPLS. O que vemos claramente aqui é um termo de "marketing": a operadora "XYZ" tem um backbone MPLS e fornece serviços de conectividade através de "links MPLS" para clientes corporativos, fornecendo então serviços tais como L3VPNs ou extensões LAN-to-LAN ponto a ponto ou multiponto (ex: L2VPNs). Para os equipamentos de rede do usuário final/clientes, isto é (o MPLS) transparente.

Pois bem, respondendo a sua pergunta agora bem diretamente: a contratação de circuitos de dados junto a uma operadora, seja para uma L3VPN ou L2VPN, obviamente tem um custo. A interconexão de diversas filiais através de uma rede privativa através de uma operadora, embora fundamental em diversos segmentos de mercado e de negócios, representa um custo que pode pesar nas despesas operacionais da empresa.

Se a sua empresa eliminar o serviço de WAN com a sua operadora atual (por exemplo, cancelando os circuitos MPLS contratados), qual opção restaria para a sua empresa? Como uma das hipóteses mais óbvias e prováveis, uma simples VPN ponto a ponto ou multiponto usando a própria Internet, certo? Este seria o caminho de migração mais óbvio. Só que ao fazermos isto usando a Internet, além da perda de algumas vantagens e benefícios técnicos que os circuitos privativos oferecem, outros desafios de ordem técnica surgirão. Portanto, substituir os circuitos privativos contratados junto a uma operadora por links de Internet padrão, incluindo banda larga, introduz novos desafios e complexidades que precisam ser estudadas corretamente. As VPNs que você estabelecer pela Internet tem que ser flexíveis, seguras, escaláveis e transparentes, sendo estes os principais desafios de natureza técnica.

Felizmente a Cisco tem uma excelente solução para este desafio: como fazer com que circuitos de Internet, notoriamente menos confiáveis, consigam transportar aplicações de missão crítica para uma organização? E com privacidade, confidencialidade, resiliencia, usabilidade, transparência e gerenciamento?

Sugiro que você consulte as áreas a seguir que tratam da solução Cisco Intelligent WAN (IWAN)!

Cisco Intelligent WAN
http://www.cisco.com/c/en/us/solutions/enterprise-networks/intelligent-wan/index.html

IWAN Wed: What is Intelligent WAN?
http://blogs.cisco.com/enterprise/iwan-wed-what-is-intelligent-wan

Espero não somente ter respondido a sua pergunta, mas completado a sua linha de raciocínio com base no que foi apresentado hoje em nosso webcast! E espero que você curta a proposta da solução Cisco Intelligent WAN (IWAN)!

Q: FIB se mantem em hardware e RIB em software?

A: A arquitetura do Cisco Express Forwarding (CEF) implementa duas estruturas de dados: a Forwarding Information Base (FIB) e a Adjacency Table (ADJ). Em redes MPLS, implementa também a Label Forwarding Information Base (LFIB).

O CEF é um mecanismo de "switching path" que visa implementar uma estrutura de dados contendo prefixos de redes (FIB) em uma disposição que promove melhor eficiência computacional. Essencialmente, a FIB é um "espelho" da RIB, no entanto permite consultas/lookups mais eficientes ou menos computacionalmente onerosos. E cada prefixo listado na FIB deverá apontar para uma ou mais adjacências pré-computadas (ADJ). A FIB é construída com base em informações aprendidas da RIB (tabela de roteamento), e por sua vez a tabela de adjacências (ADJ) é mantida por outros processos e serviços (principalmente o ARP). Novamente, a idéia é ter todas as informações já prontas e pré-computadas, e fazendo a separação sistêmica entre os dois planos. Por exemplo, a RIB (tabela de roteamento) e LIB (tabela de labels) são mantidas no Control Plane, enquanto a FIB, LFIB, e ADJ são mantidas no Data Plane. E todas as ações de processamento de pacotes (L2 lookup, L3 lookup, ACL, QoS, etc.) são feitas no Data Plane.

Quando uma nova rota é publicada na tabela de roteamento, o processo que gerencia a RIB se encarrega de produzir e publicar esta informação para que outro processo consuma esta informação e atualize a tabela FIB ainda em software, em primeiro momento, e tipicamente implementando um IPC para este procedimento. Uma vez a entrada na software FIB tiver sido criada e a respectiva adjacência tiver sido resolvida, as novas entradas na software FIB são então programadas na HARDWARE FIB do equipamento, cuja localização, tipo, qualidade, etc., depende da plataforma ou modelo do router em questão.

Ilustrando aqui: Rota --> RIB --> SW FIB + ADJ --> HW FIB + ADJ.

Espero ter respondido a sua dúvida!

Q: A instrução de colocar uma label no frame fica na FIB "atrelada" a uma rota especifica (que utilize uma interface usando mpls)?

A: O critério que determina se um pacote deverá ser consultado na FIB ou na LFIB é muito simples: se o frame mencionar um Ethertype que denote a presença de label (0x8847), então o pacote é verificado contra a LFIB. Caso contrário (não haja labels no pacote), o pacote é verificado contra a FIB.

Quanto ao colocar um label (push) ou não para pacotes consultados contra a FIB, isto dependerá das seguintes condições:

- Pacote é recebido sem Label;
- O prefixo mais específico existe na FIB;
- A interface de saída que está associada ao prefixo está habilitada para o MPLS;
- O next hop da referida rota/prefixo através desta mesma interface anunciou um Label para este prefixo.

É neste momento em que ocorrerá o "push" do label ou de um stack de labels para o pacote. Note que em arquiteturas Frame Mode MPLS, há o que chamamos de "retenção liberal de labels". Isto significa que um roteador poderá receber labels referentes a um mesmo prefixo (ex: 192.168.1.0/24) de vários neighbors de LDP, mesmo daqueles roteadores que na tabela de roteamento não sejam next hop para este prefixo, conforme determinado pelo IGP. E que este roteador manterá em sua LIB todos os labels recebidos referentes ao prefixo-exemplo 192.168.1.0/24, tanto do neighbor que é next-hop quanto de outros neighbors que não são next hop. No entanto, no que tange à programação da FIB para ações de label push, a instrução para a imposição de Label considerará somente labels que tiverem sido anunciados por next-hops para aquele prefixo IP. Este modelo "retenção liberal de labels" é uma característica que visa acelerar a convergência da rede em caso de quedas do link primário, pois, quando a rede convergir para caminhos alternativos, o roteador já possui de forma antecipada a informação de outros labels para aquele prefixo, previamente anunciadas pelos demais neighbors LDP, o que permite encurtar o tempo de downtime durante esta convergência.

Em resumo:

- Pacotes recebidos sem label são consultados na FIB, e ali poderá decidir se o pacote será transmitido sem label, ou fazendo push de um ou mais labels;
- Pacotes recebidos com label são consultados na LFIB, e ali poderá determinar se ocorrerá um swap, ou pop do top label, ou ainda o push de um ou mais labels.

Espero ter esclarecido!

Q: Pelo o que eu entendi, as labels são distribuidas por um protocolo, por exemplo, LDP, a minha duvida é a seguinte, eu preciso me preocupar em saber quais labels estão sendo utilizadas e etc?

A: Você está correto no que diz respeito da necessidade em termos um protocolo para realizar a distribuição de labels. Para MPLS label switching "tradicional", o protocolo usado é o LDP. Para áreas da rede onde houver MPLS TE, o protocolo RSVP é usado para fazer o path setup e a distribuição de labels entre os nós presentes no LSP, cuja sinalização foi ditada pelo headend do túnel. Para L3VPN, o protocolo BGP é quem anuncia para os demais roteadores PE participantes sobre quais labels usar para identificar pacotes dentre as diversas VPNs. E o LDP também é usado para distribuir labels em L2VPN através de sessões diretas multihop do tipo "targeted sessions", mas há também a especificação de L2VPNs cujas descobertas de vizinhos e distribuição de labels se dá por BGP.

No que tange a saber "quais labels" são usados para quais serviços ou FECs (ex: prefixos), você realmente não precisa se preocupar em "controlar" ou "manter" isto. Até mesmo porque a alocação e distribuição de labels é completamente arbitrária. O único momento onde você precisará saber exatamente quais labels são usados (local e remote) para um determinado serviço é quando fazendo algum troubleshooting ou resolvendo problemas! Fora isto, você realmente não precisa se preocupar em saber quais labels estão sendo utilizados.

No entanto, você talvez tenha preocupação em controlar para quais prefixos você precisa gerar labels, e para quais peers estes labels deverão ser anunciados! É o que chamamos de "conditional label distribution". Em muitos casos, você realmente não precisa gerar labels para todos os prefixos IGP da sua rede, mas é quase certo que você precisará de labels referentes somente aos prefixos host-routes (/32) na grande maioria dos casos! Talvez você queira controlar a alocação e distribuição de labels quanto a este cenário. De fato, pouco importa "qual valor de label está sendo usado para associar qual prefixo IP ou FEC". Exceto durante uma ação de troubleshooting, onde comandos específicos nas duas pontas do serviço informarão quais são os labels Local e Remoto daquele serviço, e com isto você poder fazer a validação desta troca de labels no sentido oposto, verificar os seus LSPs, fazer testes de conectividade, etc.

Esperto ter contribuído!

Informação relacionada

 

 

Histórico de versão
Revisão #
2 de 2
Última actualização:
‎08-31-2017 01:52 AM
Actualizado por:
 
Etiquetas (1)
Contribuintes