Minha jornada até o CCIE RS — MPLS

E vamos nessa série de artigos compartilhando as minhas anotações acumuladas durante anos de trabalho e estudos até passar no lab de CCIE RS. Quase 400 páginas de cadernos acumuladas com informações e observações que considero importantes ao trabalhar com Routing and Switching por quase 15 anos.

Como já disse, acredito que estas informações possam ajudar mais do que passar em certificações, mas no dia-a-dia de outras pessoas como eu ao lidar com infraestrutura Cisco.

Para quem não leu os artigos anteriores, seguem os links sobre “Switching”, “PPP”, “IP Routing”, “RIP”, “EIGRP”, “OSPF”, “BGP” e “Redistribuição”. Abaixo segue a parte sobre MPLS e uma lista de comandos show + filtros que considero eficiente.

Fique a vontade para comentar e entrar em contato comigo no LinkedIn. Se gostou do que leu, incentivo a compartilhar com colegas do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow lá em cima :)

MPLS

• Multiprotocol Label Switching é um protocolo Open Standard definido pela RFC 3031 “Multiprotocol Label Switching Architecture”.
• MPLS é derivado de uma feature antiga chamada tag switching.
• Multiprotocol porque pode transportar diferentes tipos de payload incluindo diversos protocolos L2 e L3:
• — L2 — ethernet, HDLC, PPP, frame-relay, ATM.
• — L3 — IPv4, IPv6.

Pelo fato de ser multiprotocol, o MPLS permite emular um circuito L2 entre o PE-CE enquanto transporta tudo em L3 dentro do ISP.

Label Switching é devido ao modo que o tráfego é transportado dentro do ISP. O tráfego é comutado entre as interfaces baseado em labels localmente significantes, usando um modo similar a como o Frelay e ATM usam DLCIs e VPN/VCI de entrada e saída.

Principal vantagem do MPLS é que o CORE não precisa ter “full reachability” da rede completa. O core só precisa conhecer os edge routers (PEs). O Edge Router se comunica com o cliente (CEs) através de qualquer protocolo suportado (transparente para o CORE).

Formato da Label

• A label é um header de 4 bytes usado para comutar os pacotes.
• Documentada pela RFC 3032 “MPLS Label Stack Encoding”
• — 20 bits de label — localmente significante pro router
• — 3 bits EXP — Class of Service para marcação de QoS
• — S bit — define a última label na pilha usada para edge router
• — 8 bits de TTL — time to live

Operação do MPLS

• MPLS atrela labels aos FECs (Forwarding Equivalent Class). Neste caso, FECs são prefixos IPv4.
• A comutação no MPLS se baseia na LFIB que é basicamente a CEF table + uso da label.
• A lógica da comutação se baseia na label de entrada, localmente significante para cada router.

OBS: FEC é um conjunto de pacotes (tráfego) com características semelhantes que podem ser encaminhados da mesma forma.

Provider Edge Router (PE)

• Antigamente chamado de Label Edge Router (LER).
• PE é o router que conecta com os Customer Edge (CE) routers.
• Nele roda o protocolo de roteamento PE-to-CE trocando informações de roteamento entre o Customer e o ISP.

PE recebe pacotes sem label do Customer e adiciona uma label antes de encaminhar através do ISP, chamado de Label Push ou Label Imposition.

Provider Router (P)

• Antigamente chamado de Label Switch Router (LSR)
• P routers são os roteadores internos à rede MPLS. Eles se conectam a outros roteadores P e PE, mas não a routers CE.
• Portanto comutam o tráfego baseado somente nas labels e não possuem nenhuma informação a respeito dos CEs.

Operações com Labels

• Push — PE router adiciona label para pacote entrante.
• Swap — P router substitui uma label por outra em pacote entrante.
• Pop — PE router remove a label e encaminha pacote para o CE.

Distribuição de Labels

Antes de rotear o tráfego através do MPLS, roteadores P/PE devem concordar nas labels para cada FEC (no caso, prefixos IPv4).

A distribuição dinâmica de labels pode ser realizada através de:

• TDP (Tag Distribution Protocol) — proprietário Cisco.
• LDP (Label Distribution Protocol) — protocolo Open Standard.
• Resource Reservation Protocol (RSVP) — usado para MPLS — Traffic Engineering (MPLS-TE).
• MP-BGP (Multiprotocol BGP) — pode ser usado para propagar o prefixo e as labels associadas.

Label Distribution Protocol (LDP)

• LDP é especificado na RFC 3036 “LDP Specification”
• Utilizar “Neighbor Discovery” com porta UDP 646 e 224.0.0.2 (all-routers) e “Neighbor Adjacency” na porta TCP 646 para o router-id do peer remoto.
• Router-ID do LDP é escolhido como loopback ou interface com IP mais alto (mesmo que OSPF e BGP)
• — OBS: Router-ID devem ser únicos na topologia MPLS.
• A propagação de labels no LDP ocorre por FEC. As FECs propagadas (neste caso, IPv4) são aquelas das interfaces rodando IGP e de rotas aprendidas através de IGP. Portanto LDP é baseado em IGP.

OBS: IOS antigo usa TDP por default, enquanto IOS novo usa LDP por default.

OBS: Como TDP e LDP são significantes somente entre os neighbors, podemos ter um mix destes protocolos nas redes (mas não há motivos para fazer isso, tirando um lab de CCIE rss).

Penultimate Hop Popping (PHP)

Pelo comportamento normal, o router de destino ao receber um pacote com label deve realizar duas pesquisas: uma para retirar a label e outra na tabela de roteamento para definir interface de saída.

O PHP permite ao router adjacente ao router de destino retirar a label antes de encaminhar o pacote ao router de destino. Isso acarreta uma otimização de pesquisa no router de destino que só realiza uma pesquisa (de roteamento).

• OBS: Este comportamento vale para qualquer router no domínio MPLS.

MPLS Tunnels

Uma grande vantagem do MPLS é possibilitar aos P routers conhecer apenas as rotas IGP para os PE routers, desconhecendo completamente as rotas BGP externas ao ISP. Característica conhecida como BGP free core.

As rotas externas ao ISP (AS) são comutadas por labels baseadas no next-hop BGP enquanto os P/PE routers se comunicam e controlam as labels através de IGP.

Principais Problemas

O next-hop BGP propagado deve ser a interface loopback do PE remoto. Isso porque o tráfego não é destinado ao next-hop, ele vai além do next-hop. Se o next-hop BGP propagado for a interface conectada do PE ao P, o P router irá divulgar Implicit Null por questão de otimização. Ao receber o tráfego destinado para além do PE, o pacote chegará sem label e o P router irá descartá-lo assim como não terá rota para retornar ICMP unreachable à origem. Neste momento o control-plane parece perfeito, mas o problema é um black hole no data-plane.

Resumindo, NÃO podemos usar como next-hop BGP a interface do PE com P router porque teremos o POP tag 1 peer antes, causando um black hole na topologia MPLS.

• OBS: Podemos corrigir isso alterando o next-hop das rotas através de um route-map, mas não é o ideal.

MPLS VPN Layer 3

Essa funcionalidade combina a lógica de túneis MPLS e separação de roteamento L3.

Neste cenário, o PE aprende rotas vindas do CE e propaga estas rotas para outros PEs através do BGP apontando os next-hops BGP através dos túneis MPLS (geralmente loopbacks dos PEs). P routers no interior do AS continuam desconhecendo as rotas dos CEs.

As informações de roteamento do CE são separadas pelo PE em tabelas de roteamento virtuais chamadas de Virtual Routing and Forwarding (VRF). Cada Customer tem então sua própria instância VRF.

Os PE routers agregam todas as informações recebidas dos CEs e propagam entre si através de MP-BGP. O core pode ser BGP free (e geralmente é).

Como cada VRF é uma instância de roteamento separada, isso implica que os endereços entre as diferentes VRFs podem se sobrepor e que não há comunicação entre as VRFs.

A funcionalidade de VRF pode ser utilizada independente do MPLS e neste caso é chamada de VRF lite. Neste caso faz uso apenas de tabelas de roteamento isoladas.

OBS: Obviamente, ao usar VRF todos os serviços agregados (DNS, NAT, etc) precisam ser VRF aware.

Dentro de um VRF o roteamento pode ser realizado através de:

• rotas estáticas no VRF
• IGPs VRF aware — RIP, EIGRP, OSPF, IS-IS
• MP-BGP
• Policy Routing

Ao usar VRF lite , todos os dispositivos no caminho devem conhecer todas as rotas (usando a mesma lógica de roteamento IP normal).

Na MPLS VPN somente os PEs devem conhecer as rotas dos CEs. Roteamento na MPLS VPN é realizado utilizando:

• Rota VPNv4 — (RD + prefixo) tornam as rotas VPN únicas globalmente no router.
• Transport Label (outer label) — label informando o next-hop BGP do PE (geralmente loopback do PE).
• Label MPLS VPN (inner label) — roteadores PE trocam labels entre si para cada rota de CE via VPNv4.

| Transport Label (1) | VPN Label (2) | IP | TCP | WWW |

1 -> Para qual PE devemos encaminhar?

2 -> Para qual CE o PE deve encaminhar quando receber o pacote?

Multiprotocol BGP (MP-BGP)

MP-BGP é definida na RFC 4364 “BGP/MPLS IP Virtual Private Networks (VPNs)”

MP-BGP define VPN-IPv4 (ou VPNv4) como AFI 1 (address family identifier) e sub-AFI 128.

Usa Route Distinguisher (RD) para tornar a rota do CE única dentro do MPLS (única por VPN ou por site VPN) e somente para isso.

Usa a extended community Route Target (RT) para controlar o que entra e o que sai da VRF table (import/export). Neste caso export redistribui as rotas do VRF para o BGP (MPLS) enquanto import re-insere as rotas do BGP novamente na VRF.

Route-targets permitem controle granular sobre quais sites possuem quais rotas. Import-maps e Export-maps permitem controle por prefixo.

OBS: Caso os PE routers não estejam roteando através da tabela BGP global podemos ativar a address-family VPNv4 e desativar a address-family IPv4.

OBS: Em ambientes reais, os ISPs geralmente tem caixas separadas para IPv4 e VPNv4 principalmente para larga escala. Neste caso VPNv4 é utilizado para clientes enquanto a topologia IPv4 é utilizada para tráfego de Internet (tabela completa BGP).

Route Target

• Extended community de 8 bytes definida RFC 4360 “ BGP Extended Communities Attribute”.
• Formato similar ao Route Distinguisher (AS:nn ou IP:nn)
• Utiliza mecanismo de prevenção de loops cujo speaker VPNv4 somente aceita rotas VPNv4 com RT fazendo matching em um VRF local.

OBS: Há basicamente 2 cenários para desabilitarmos o filtro de RT. Se houver route-reflector onde os RT não são utilizados em VRF local mas devem ser propagados adiante. Outro caso é troca de rotas VPN entre ASs.

Rotas VPNv4 podem ter mais de um RT, o que permite a criação de políticas complexas (topologias):

• Full mesh — importar e exportar mesmo RT de todos os locais permitindo completo conhecimento dos caminhos.
• Hub and Spoke — spokes importam somente as rotas do hub permitindo um gerenciamento centralizado.
• Central Services VPN — múltiplas VPNs podem importar rotas de um site central ou servidor central. Este cenário é particularmente encontrado quando o ISP oferece um recurso centralizado aos clientes (VOIP, email, etc).
• VPNs de gerenciamento — loopbacks de gerenciamento nos roteadores do CE podem ser exportados para uma VPN de gerenciamento especial.

Principais passos para MPLS VPNv4

• Trocar informações de roteamento entre PE-CE
• Estabelecer adjacências entre PEs (MP-BGP)
• Redistribuir rotas do CE na rede MPLS (VRF <-> MP-BGP)

OBS: Peer VPNv4 usa mecanismo de prevenção de loops por default, mesmo recebendo todas as rotas ele filtra todos os RTs que não precisa importar.

OBS: Não é possível vazar tráfego localmente entre as VRFs. Para isso é necessário criar um loop físico entre as VRFs, conectando um cabo entre interfaces de diferentes VRFs.

OBS: O RT (import) é quem realmente define se o VRF é membro de uma VPN.

OBS: Ao redistribuir do MP-BGP para a VRF, sempre limpe a RIB porque pode ocorrer “erros de sincronização” durante a redistribuição (#clear ip route vrf).

As rotas presentes na VRF informam a VPN label (inner label), porém a transport label (outer label) (substituída hop by hop) é aprendida através da recursividade do next-hop BGP na tabela principal.

Após definido VPN label e transport label, o pacote é enviado e a transport label é substituída hop by hop até chegar ao PE, onde a VPN label define a VRF de destino.

| Transport label | VPN label | Payload |

OBS: Na realidade podemos exportar e importar os RTs como quisermos, o que permite fazer a bagunça que quisermos (roteamento simétrico, assimétrico, em círculo, etc).

Resumo — Habilitando MPLS VPNv4

• VRF (definição)
• — RD único
• — RTs import e export
• Atrelar VRF as interfaces
• Habilitar roteamento na VRF
• Estabelecer adjacências entre peers VPNv4
• Redistribuição VRF <-> MP-BGP (assumindo que todos os passos anteriores estão ok)

OSPF como Protocolo CE em Redes MPLS VPNv4

DOC: RFC 4577 “OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)”

OSPF utiliza novos campos como mecanismo de prevenção de loop quando utilizado com MPLS.

Permite o uso de Sham-links que são links virtuais, porém configurados entre PEs sobre a rede BGP. São adjacências unicast que permitem traffic engineering.

OBS: A natureza da segurança da MPLS VPN se baseia na política de RTs, portanto os ISPs usam ferramentas e sistemas complexos para administrar os RDs e RTs de cada Customer. Qualquer confusão nos valores pode resultar em vazamento de tráfego. Para quem nunca viu acontecer, os tráfegos de clientes diferentes se misturam (baita falha de segurança).

OBS: RIP, EIGRP e BGP usam apenas um processo global e as VRFs são especificadas dentro do processo. OSPF usa um processo diferente para cada tabela VRF. Isso pode significar uma limitação de recurso se inúmeros customers rodam OSPF em um mesmo PE visto que precisa de um processo para cada um (design issue).

OBS: Lembrar que por default OSPF não redistribui rotas externas no BGP.

MP-BGP utilizam diferentes extended-communities ao redistribuir OSPF: OSPF domain-id, route type e router-id. Estas communities são usadas pelo router remoto OSPF ao receber as rotas de retorno vindas do BGP para definir como divulgar tais rotas (Tipo O, O IA, E1, E2, etc).

• Se o domain-id é o mesmo (mesma área OSPF) a rota recebida é tipo 3.
• Se o domain-id for diferente usa tipo 5.

• Ao alterar a área entre A e B, router passa a receber rotas tipo 3 (O IA) dos dois vizinhos mas deve escolher um ABR preferencialmente na área 0 ao invés de ABR de uma área não-trânsito. A solução alterando área é interessante para migrações VPN L2 (Frelay, ATM) (onde os sites estão diretamente conectados via L3) para MPLS L3. Enorme ponto negativo é que precisa alterar as áreas de todos os circuitos antigos (puta trampo!!!).

Sham-links OSPF

Sham-links são adjacências unicast OSPF sobre MPLS permitindo aos PEs trocarem rota dentro da mesma área (redistribuindo como intra-áreas) para traffic engineering.

Obviamente sham-link deve trafegar sobre MPLS BGP do ISP e não sobre o OSPF do cliente. Portanto a loopback do sham-link criada na VRF do PE (redistribuída como tipo 5) deve ser filtrada no OSPF durante a redistribuição do BGP no OSPF (via route-map) (por isso sham-link sempre precisa de filtro).

As RIBs dos PE passam a usar OSPF (porque tem DA 110 contra 200 do iBGP) resultando em rotas redistribuídas via MPLS como intra-área (tipo O), e aí a questão depois é ajustar custos.

Grande ponto negativo é que estende o domínio OSPF entre todos os sites na mesma área, resultando em que qualquer alteração gera recálculo na área toda (em todos os sites).

Loop Prevention — MPLS <-> OSPF

Quando PE redistribui rotas tipo 3 no OSPF, o Downward Bit (DN) garante que esta rota não será redistribuída por outro PE no MPLS, evitando loops em ambiente multi-homed. Para rotas do tipo 5 a tag do LSA é comparada com VPN-tag.

OBS: Mesmo havendo redistribuição, se o domain-id é o mesmo entre CE e PE, o PE é encarado como ABR (e não ASBR).

VRF-lite também checa o DN bit e não adiciona a rota na RIB se o DN estiver setado (porque o router acredita que é um PE). Como não adiciona as rotas na RIB, as rotas não são redistribuídas (e assim funciona prevenção de loop).

Outra solução é alterar o domain-id do PE porque ele é herdado do processo. Se o domain-id da rota e do PE rodando OSPF forem diferentes, a rota é redistribuída como tipo 5.

Usar sham-link também funciona porque rotas do tipo 1 não checam DN.

O BGP ajusta automaticamente a tag no OSPF por default para impedir o retorno da rota. Para cancelar o mecanismo precisa alterar a tag manualmente.

Documentação

DOC: Ótimo livro sobre os padrões e diferentes cenários MPLS “MPLS-Enabled Applications” (mais recomendado que os livros da Cisco).

DOC: MPLS Label Distribution Protocol

DOC: MPLS: Layer 3 VPNs

Comandos Show para MPLS

• sh ip vrf
• sh ip vrf det
• sh ip vrf int
• sh ip route vrf XXX a.a.a.a
• sh ip cef vrf XXX a.a.a.a
• sh mpls int
• sh mpls int det
• sh mpls ip bind
• sh mpls ldp nei
• sh mpls ldp nei det
• sh mpls for
• sh ip cef vrf ABC x.x.x.x (det)
• sh bgp vpnv4 uni all
• sh bgp vrf ABC vpnv4 uni
• sh ip rip data vrf ABC
• sh ip os X
• sh ip os sha
• sh ip nat sta (NAT entre VRFs)
• sh ip nat tra (NAT entre VRFs)
• sh ip nat tra ver (NAT entre VRFs)

Esse artigo sobre MPLS te ajudará no dia-a-dia?

Faltou algum ponto importante?

Fala pra gente nos comentários?

Se gostou do conteúdo, peço para compartilhar com outros do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow aí embaixo :)

Sobre o autor:

Giuliano Barros é Network Consultant & Founder da Control Plane — Network Services.

Graduado em Ciência da Computação, certificado CCIE RS pela Cisco Systems e trabalha há 15 anos como Network Engineer em projetos para grandes e médias empresas. linkedin.com/in/giulianobarros