Apostila Treinamento DmOS-MPLS PDF

GUIA OFICIAL DE CAPACITAÇÃO
Switches DmOS
MPLS
Conceito
Configuração
Operação
Atividades práticas
www.datacom.com.br
© 2022 Datacom / Teracom Telemática S.A.
Este material foi desenvolvido pelo Centro de Treinamento DATACOM exclusivamente para o curso de Switches
DmOS – MPLS.
Todos os direitos reservados. Nenhuma parte desta publicação poderá ser reproduzida ou transmitida de qualquer
modo ou por qualquer outro tipo de sistema de armazenamento e transmissão de informação, sem prévia
autorização expressa da DATACOM.
Apesar de terem sido tomadas todas as precauções na elaboração deste material, a DATACOM não assume qualquer
responsabilidade por eventuais erros ou omissão bem como nenhuma obrigação é assumida por danos resultantes
do uso das informações contidas neste guia. As especificações fornecidas neste documento estão sujeitas a
alterações sem aviso prévio e não são reconhecidas como qualquer espécie de contrato.
Versão da Apostila: 8.0.4 2

DATACOM
• Líder no mercado de equipamentos para comunicação de dados no
Brasil
• Presença nacional e em mais de 45 países
• Tecnologia 100% nacional
• Maior área de Pesquisa e Desenvolvimento do Brasil
• 13.000m2 de área construída e 120.000m2 de área total com

construção verde
• Treinamento presencial e EaD
• Suporte técnico
A Datacom desde a sua fundação, em 1998, sempre teve seu foco no desenvolvimento de produtos e soluções
tecnológicas. O investimento constante e crescente em pesquisa e desenvolvimento é uma marca em sua história e
principalmente uma diretriz que sustenta nossas ações no dia a dia.
A Datacom tem a maior equipe de desenvolvimento da América Latina entre os fabricantes de produtos para
Telecomunicações, com centenas de desenvolvedores atuando diretamente na criação de novos produtos.
Situada em Eldorado do Sul/RS, a planta fabril da Datacom opera com as mais modernas linhas de montagem SMT e
conta com equipamentos de última geração para a inspeção e controle de montagem, que aliados a um sistema
automatizado de testes asseguram a qualidade do processo e do produto final.
Os produtos Datacom são produzidos dentro dos mais modernos padrões e certificações. Fomos a primeira empresa na
América Latina a certificar seus produtos no Metro Ethernet Fórum.
A Datacom oferece soluções completas do backbone ao acesso, através de um amplo portfólio. Contemplam nossas
linhas de produtos tecnologias como Switches Metro Ethernet, MSAN, GPON, Plataformas de Acesso Multisserviço, SDH
NG e uma grande variedade de produtos de acesso sobre infraestruturas de cobre ou fibra.
Serviços tecnológicos também fazem parte do portfólio de soluções da Datacom. Por isso oferecermos soluções como
projetos de design de redes do alto e baixo nível (HLD e LLD), análise de viabilidade, ampliação, monitoramento e
gerenciamento de redes, suporte técnico 24x7 local e remoto, operação assistida, instalação de equipamentos e
treinamentos.
A busca constante na satisfação dos clientes é o grande diferencial da Datacom. Através da comunicação direta e ágil,
não medimos esforços para fornecer um atendimento de qualidade técnica diferenciada com profissionais treinados e
capacitados para responder as demandas cada vez mais urgentes desse mercado.

Portfólio DATACOM
Diante de um cenário de crescente competitividade, no qual o acesso Internet se tornou uma commodity disponível em
múltiplos fornecedores, é preciso construir redes com alta relação custo x benefício, e que principalmente ofereça
diversas opções de topologia para todos os tamanhos de orçamento.
Entendendo esta demanda, desenvolvemos um portfolio completo desde o backhaul até o acesso, com tecnologias
Metro Ethernet, GPON e xDSL que atendem às necessidades de comunicação e conectividade. A DATACOM possui
soluções completas.
Apresentaremos na sequência as linhas de produtos DATACOM com as suas principais características de hardware e
software. Ao final deste capítulo você saberá:
• Identificar e diferenciar os equipamentos pertencentes as linhas de atuação da DATACOM;

• Posicionar os equipamentos conforme a necessidade de cada aplicação;
• Desenhar novas soluções e realizar propostas de equipamentos.

Portfólio DATACOM
Multiplexadores e Serviços
GPON, ONUs
Conversores TDM Especializados
e WiFi
Ethernet Switches Gerenciamento de

e Roteadores Rede e Servidores
Cada produto conta com funcionalidades singulares que satisfazem aos mais diferentes cenários, desde pequenos e
médios negócios até aplicações Carrier Class complexas em redes Metro Ethernet, implementando uma solução
completa para redes de core, edge, corporativo e usuário final.

Ethernet Switches & IP – Linha LAN
DM1200E Series DM1105E Series DM1205E Series
Switch LAN – L2 Switch LAN – L2 Switch LAN – L2
24GE Elétricas 24GE Elétricas 48GE Elétricas
1GE / 10GE Uplinks SFP 1GE Uplinks SFP 1GE / 10GE Uplinks SFP
Stackable/Empilhamento AC Full Range AC Full Range
AC Full Range PoE+ PoE+
Alimentação de Redundância Interface WEB Rota Estática IPv4/IPV6

PoE Interface WEB
Rota Estática IPv4/IPv6
Interface WEB
A linha de comutação DM1200E da DATACOM oferece uma solução Gigabit Ethernet para atender a demanda crescente
em aplicações de redes corporativas. Possui funcionalidades L2 completas e roteamento estático. Formada por
diferentes modelos de configuração fixa para instalação em rack de 19“, permite a criação de redes de baixo custo com
alta capacidade de tráfego. Suportam uma série de funcionalidades avançadas, como configuração simultânea de
VLANs, Link Aggregation e protocolo de proteção e redundância de rede spanning-tree e para redes multicast suporta a
funcionalidade de IGMP.
Na tabela a seguir é possível verificar as capacidades da linha de switches LAN.
Modelos GE Uplink Tipo
DM1105E 24GT+2GX 24 2x GE SFP L2
DM1105E 24GP+2GX 24 PoE 2x GE SFP L2
DM1200E 24GT+4XS 24 4x 10GE SFP+ L2/L3
DM1200E 24GP+4XS 24 PoE 4x 10GE SFP+ L2/L3
DM1205E 48GT+4GX 48 4x GE SFP L2/L3
DM1205 48GT+2XS 48 2x 10GE SFP+ L2/L3
DM1205 48GP+2XS 48 PoE 2x 10GE SFP+ L2/L3

Ethernet Switches & IP - EDD
DM2100 Series DM2300 Series DM4360 Series DM4370 Series DM4380 Series
Switch Acesso – L2 Switch Acesso – L2 Switch Acesso - L2/L3/MPLS Switch Acesso - L2/L3/MPLS Switch Acesso - L2/L3/MPLS
GE Uplinks GE Uplinks 8x1GE Uplink 8x1GE Uplink 12x10GE Uplink
Emulação de E1 / CESOP Emulação de E1 / CESOP AC/DC 4x10GE Uplink 3x100GE Uplink
ACR 1588v2 (GPS) Redundância 12V AC/DC AC ou DC – PSU 125
AC/DC RFC2544/Y.1564 DmOS Based Redundância 12V Alimentação de Redundância
AC/DC DmOS Based DmOS Based

Interface WEB
O DM2100-EDD (Dispositivo de Demarcação Ethernet) é uma família de switches DATACOM destinada a oferecer serviços
inteligentes de demarcação LAN/WAN na última milha de redes de acesso Metro Ethernet. Com o DM2100-EDD é possível
monitorar e controlar os serviços Ethernet e TDM com ferramentas de OAM até o equipamentos CPE, facilitando o
atendimento de SLA em toda a rede.
Os switches da família DM2300 oferecem uma solução Carrier Grade que atende as crescentes demandas dos
provedores de acesso, que exigem níveis elevados de SLA (Service Level Agreement) para os serviços Ethernet oferecidos
aos seus clientes. São equipamentos de mesa compactos de 1U de altura em gabinete metálico e não requerem
ventilação forçada. Contam ainda com uma fonte de alimentação interna full-range AC/DC com seleção automática.
Os switches da família DM4360 oferecem alta capacidade de comutação para o atendimento das crescentes demandas
de demarcação de acesso na prestação de serviços Metro Ethernet com desempenho e confiabilidade. Esta linha é opera
com o sistema operacional DmOS, com suporte a um conjunto completo de funcionalidades L2/L3, incluindo suporte a
MPLS.
O DM4370 é um switch compacto e de alto desempenho pronto para atender a crescente demanda pela migração dos
serviços para altas capacidades até 10 Gbps. O switch baseia-se no sistema operacional modular de rede DmOS, com
suporte a um conjunto completo de funcionalidades L2/L3, incluindo suporte a MPLS, tornando o produto a solução
perfeita para aplicações corporativas e de backhaul móvel de alta capacidade e alto valor agregado. O switch contém
4 interfaces 10GE ópticas baseadas em conectores SFP+, 4 interfaces ópticas 1GE baseadas em conectores SFP e mais
4 interfaces GE elétricas. O produto contém um módulo de alimentação integrado AC/DC universal e uma entrada
opcional 12V DC para operação em redundância, atendendo os requisitos de serviços de alta disponibilidade.
O switch DM4380 é baseado no sistema operacional DmOS com interfaces 10GE, 40GE e 100GE para aplicações de acesso
e agregação Metro Ethernet de alta capacidade e valor agregado. Fornece alta capacidade de comutação para o
atendimento das crescentes demandas de agregação de tráfego IP em redes de acesso e agregação Metro Ethernet,
redes corporativas de alta capacidade e agregação de servidores e redes em Datacenters, sempre fornecendo alto
desempenho e confiabilidade.

Ethernet Switches & IP
DM3000 Series DM4100 Series DM4050 Series DM4170 Series DM4000 Series
L2/L3 Fast Ethernet L2/L3/MPLS L2/L3 L2/L3/MPLS L2/L3/MPLS Modular
4GE Uplinks Combo 10GE Uplinks 6x10GE Uplinks 24GE + 12x10GE Placas GE/10GE
Versão Elétrico e Óptico Stackable/Empilhamento Versão Elétrico e Óptico 24GE + 4x10GE + 2x40GE 32E1/4STM-1
AC/DC – PSU 85 Versão Elétrico e Óptico AC/DC – PSU 85 AC ou DC – PSU 125 1588v2 (GPS)
Alimentação de Redundância PoE+ Alimentação de Redundância Alimentação de Redundância MPU de Redundância
AC/DC – PSU 85 DmOS Based DmOS Based DC

Alimentação de Redundância Alimentação de Redundância
Chassis AC + PSU AC
A linha de switches DM3000 é composta por 4 diferentes modelos. São equipamentos de 1U de altura, para instalação
em racks de 19". Possuem comutação wire speed e opções de modelos voltados para aplicações L2 e L3.
A linha de Switches Empilháveis Gigabit Ethernet e 10 Gigabit Ethernet DM4100 é composta por vários modelos,
oferecendo portas elétricas, inclusive com PoE+ e óticas. São equipamentos de 1U de altura, para instalação em racks de
19". Possuem comutação wire speed e opções de modelos voltados para aplicações L2/L3 e MPLS.
A família DM4050 é composta por dois modelos de switches Gigabit Ethernet, um com interfaces óticas e outro com
interfaces elétricas, com seis interfaces de uplink 10Gigabit Ethernet e sistema operacional de redes DmOS. Através de
um conjunto completo de funcionalidades L2 e L3, os switches DM4050 são direcionados para aplicações de acesso e
agregação em redes Metro Ethernet ou redes corporativas. Os switches têm 1U de altura, prontos para instalação em
racks padrão 19 polegadas. Ambos modelos contêm dois slots para instalação de fontes de alimentação universal AC/DC
para operação em modo redundante, garantindo uma criação de serviços de alta disponibilidade.
A família DM4170 é composta por dois modelos de switches GE, baseados no sistema operacional modular de redes
DmOS. Um dos modelos contém 12 interfaces 10GE e o outro contém 4 interfaces 10GE mais 2 interfaces 40GE, sendo
que ambos contêm adicionalmente 24 interfaces 1GE óticas. Com um conjunto completo de funcionalidades L2/L3,
incluindo suporte a MPLS, os switches são a escolha perfeita para diversas aplicações de acesso e agregação GE e 10GE
nas redes corporativas e metro ethernet. Os switches têm 1U de altura e são projetados para instalação em rack padrão
de 19". Ambos os modelos têm dois slots com suporte a inserção a quente para instalação de fontes de alimentação
redundantes AC ou DC, garantindo alta disponibilidade de operação e serviços.
A linha de Switches DM4000 oferece uma ampla gama de equipamentos para as mais variadas aplicações em redes
Metro Ethernet e redes corporativas de alto desempenho, do acesso ao core, oferecendo tecnologias como 10 Gigabit
Ethernet, Gigabit Ethernet e Fast Ethernet com suporte para cobre ou fibra, assim como E1 e STM-1. Trabalhando em
diversas camadas, os switches permitem a implementação de qualidade de serviço (QoS), redes privativas virtuais (VPN),
funções de alta disponibilidade e segurança, emulação de circuitos TDM sobre redes IP, além de comutação Wire Speed
L2, L3 e MPLS.

Ethernet Switches & IP
DM4250 Series DM4270 Series DM4770 Series
L2/L3 L2/L3/MPLS L2/L3/MPLS
24x10GE + 2x40GE Uplinks 24x10GE + 3x100GE or 4x40GE 2x10GE + 32x100GE/40GE
AC ou DC – PSU 125 48x10GE + 6x100GE/40GE 4x10GE/25GE +

16x100GE/40GE
Alimentação de Redundância AC ou DC – PSU 400
48x25GE + 8x100GE/40GE
DmOS Based Alimentação de Redundância
AC ou DC – PSU 400/600
DmOS Based
Alimentação de Redundância
DmOS Based
O switch DM4250 é baseado no sistema operacional de redes DmOS, com interfaces de 10GE e 40GE para aplicações de
agregação Metro Ethernet de alta capacidade e valor agregado. Fornece alta capacidade de comutação para o
atendimento das crescentes demandas de agregação de tráfego e acesso a serviços em redes Metro Ethernet e redes
locais de alta capacidade, sempre fornecendo alto desempenho e confiabilidade.
A família de switches DM4270 fornece alta capacidade de comutação para o atendimento das crescentes demandas de
agregação de tráfego IP em redes de acesso e agregação Metro Ethernet, redes corporativas de alta capacidade e
agregação de servidores e redes em Datacenters, sempre fornecendo alto desempenho e confiabilidade. Baseado no
sistema operacional de redes DmOS, os switches DM4270 garantem robustez e alta disponibilidade de serviços em uma
plataforma com suporte a uma série de funcionalidades L2, L3 e MPLS.
A família DM4770 fornece alta capacidade de comutação para o atendimento das crescentes demandas de agregação de
tráfego IP em redes de acesso e agregação Metro Ethernet, redes corporativas de alta capacidade e agregação de
servidores e redes em Datacenters, sempre fornecendo alto desempenho e confiabilidade.

DWDM
DM936 D8CH33 DM936 S16CH19 DM936 D32CH19 Módulos Coloridos
Mux/Demux DWDM Passivo Mux/Demux DWDM Passivo Mux/Demux DWDM Passivo Módulos dedicados para os
canais DWDM
Canais 1/10 Gb Canais 1/10 Gb Canais 1/10 Gb
8 Canais (Duas Fibras) 16 Canais (Uma Fibra) 32 Canais (Duas Fibras)
Canais DWDM CH33 ao CH40 Canais DWDM CH19 ao CH50 Canais DWDM CH19 ao CH50
Até 65km sem amplificação e Até 65km sem amplificação Até 65 km sem amplificação e
110km com módulos EDFA e 80km com módulo EDFA
DCM
10
DM936 DWDM – Solução DWDM para amplificação de capacidade de links óptico, com opção de amplificação e
compensação cromática.
A solução DWDM permite a ampliação da capacidade de links ópticos instalados, otimizando significativamente o uso
das fibras ópticas metropolitanas, gerando retorno sobre o investimento feito na infraestrutura de cabeamento óptico. É
composta por módulos ópticos GE e 10GE coloridos em canais DWDM, por um dispositivo passivo que faz a
multiplexação e a de-multiplexação. Adicionalmente a solução contém o amplificador DM936 EDFA baseado na
tecnologia Erbium Doped Fiber Amplifier e um módulo de compensação de dispersão cromática DM936 DCM40,
permitindo desta forma a ampliação do alcance dos links 10GE para até 110km (verificar a disponibilidade).
Capacidade de
Modelo Descrição Portas e Canais Tráfego Alcance Típico Amplificável
(Portas 10G)
8 Portas
Mux/Demux DWDM de
D8CH33 8 Canais 80Gbps 65km Sim – 110km
8 portas duas fibras
DW33 a DW40
32 Portas
Mux/Demux de 32
D32CH19 32 Canais 320Gbps 55km Sim – 80km
portas duas fibras
DW19 a DW50
16 Portas
Mux/Demux de 16
S16CH19 32 Canais 160Gbps 65km -
portas uma fibra
SW19 a DW50

Network Appliance, Router e Wi-Fi
DM8630 NFV Universal DM2500 Series DM955
Network Functions 4GE Dual Band Wi-Fi 2,4GHZ e 5GHz

Virtualization
6GE + 2GE Combo (SFP/RJ45) 4 antenas de 5dBi
Intel Processor
NAT, ACL, GRE MU-MIMO 2x2
Dual Core / Quad Core
VLAN Beamforming
SD-WAN
RIP, OSPF and BGP LAN Gigabit
6GE / 2 USB
AC/DC IPv4/IPv6
AC/DC
Redundância 12V UPnP e DMZ
TR-069
Easy Mesh
11
Appliance NFV - A tecnologia tem inúmeras utilidades e funções. Embutida em um software que roda em uma CPE
virtual, a SD-WAN pode monitorar as condições de todos os serviços de linhas públicas e privadas, e determinar como
rotear cada tipo de aplicação do modo mais adequado. Linha composta por diversos modelos de forma a ajustar-se às
necessidades de performance das aplicações, através de processadores dual core ou quad core e diferentes capacidades
de memória RAM e memória de armazenamento. Plataforma com suporte opcional a expansões Wi-Fi e também LTE/3G.
Os modelos disponíveis são:
Modelos Processor Cores RAM Storage

DM8630 6GT – C2RE4M16T C3308 2 4GB DDR4 ECC 16GB
Os roteadores da família DM2500 fornecem a solução ideal para o atendimento das demandas das operadoras de
telecomunicações que comercializam soluções IP para clientes corporativos. Com gabinete metálico compacto de 1U de
altura, contam com uma fonte de alimentação interna universal AC/DC com seleção automática e redundância através
de fonte externa opcional. Até dois dispositivos podem ser instalados lado a lado em um rack de 19″ através de um
adaptador MA-01.
O DM955, com tecnologia Wi-Fi 802.11ac dual band, disponibiliza uma rede confiável e extremamente rápida para os
usuários. A banda de 2,4 GHz oferece velocidades de até 300Mbps, atendendo perfeitamente tarefas do dia a dia como e-
mails e navegação na web, enquanto a banda de 5GHz oferece throughput de até 867Mbps, ideal para streamings de
vídeo UHD e jogos on-line. Possui quatro antenas externas, utiliza a tecnologia MU-MIMO de múltiplas antenas e conta
com o recurso de gerência remota através do protocolo TR-069.

Servidores OCP
DM-SV01
2 Processors AMD EPYCTM 7002

Series (Rome)
8 slots DIMM 3200MHZ
OCP Rack or 19’
8 to 64 CORES per Processor
Interface 25G // 50G // 100Gbps
OCP – Open Compute Project
Microsoft // VMware
12
DM-SV01 – É um servidor com dois processadores baseado na linha de processadores AMD EPYCTM 7002 Series (Rome).
Com opções de 8 a 64 cores por processador, os AMD EPYCTM são os processadores mais avançados no mercado. Sendo
baseados em tecnologia de 7nm, são também muito eficientes do ponto de vista energético. O servidor tem o seu design
baseado no padrão Open Compute Project (OCP), trazendo diversas otimizações em termos de consumo de potência e
uma significativa simplificação na parte de operação do equipamento, trazendo assim reduções significativas nos custos
de operação do Datacenter.
O sistema é hot-pluggable e pode ser todo operado pela face frontal, evitando o trabalho no corredor quente do
Datacenter e concentrando toda a operação em apenas um dos lados. Por ser baseado no padrão OCP, pode ser
instalado em três unidades a cada 20U (96mm) em Racks padrão OCP. Opcionalmente pode ser instalado em Racks
padrão 10” através do chassis DM1904, que comporta 4 servidores em 4,5U de altura.
Na parte de armazenamento:
• Um disco M.2 (até 4TB) NVMe embarcado;
• Um módulo para até 4 SSDs E1.S NVMe hot swap;
• Placa PCIe para dois SSDs E1.S NVMe, não jot swap;
• Placa PCIe com quatro soquetes M.2, até 4TB SSD NVMe cada.
Slots de Expansão:
• Um slot PCIe x16 FHHL (Full Height Half Length);
• Um slot PCIe x8 FHHL (Full Height Half Length);
• Opção para instalar uma placa de expansão (riser card) com três slots x8 FHHL, ao invés dos dois slots acima.
Rede:
• Um slot OCP 2.0 (mezzanine card) PCIe x16 para placa de rede (NIC). Aceita placas de interface de rede com até 2
portas QSFP de 100Gbit/s;
• As portas SFP e QSFP podem ser conectadas dentro do rack com cabos de cobre, sem a necessidade de módulos
ópticos, reduzindo o custo e o consumo de energia.
Especificações técnicas:
• Fornecimento de energia: 12Vdc fornecido pelo Rack OCP ou fornecido pelo DM1904;
• Consumo de até 750W, dependendo dos processadores e periféricos instalados;
• Uso de dissipadores de calor altamente eficientes com dois ventiladores de 80nm que permite a operação de 0ºC a
40ºC (nível do mar);
• Dimensões: 89x174x724mm.

GPON - OLTs
DM4615 DM4610 DM4612 DM4611 DM4618
16xGPON 8xGPON 8xGPON 4xGPON 64xGPON // 32xGPON +

32xGPON
2048 assinantes/clientes 1024 assinantes/clientes 1024 assinantes/clientes 512 assinantes/clientes
4x10G/25GE Uplink
4GE 8GE Elétrico / Óptico 2GE 2GE
2x40G/100GE Uplink
4x10GE Uplink 4GE Elétrico 2x10GE Uplink 2x10GE Uplink
AC ou DC
AC ou DC – PSU 125 2x10GE Uplink AC/DC – PSU 85 AC/DC - Interna
Alimentação de Redundância
Alimentação de Redundância AC ou DC – PSU 120 Alimentação de Redundância Redundância 12V
2U
Sistema Operacional: DmOS Alimentação de Redundância Sistema Operacional: DmOS Sistema Operacional: DmOS
Sistema Operacional: DmOS
Sistema Operacional: DmOS
13
O DM4615 OLT GPON é uma solução compacta e com ótimo custo benefício para prover serviços FTTx. O modelo
DM4615 16GPON suporta até 2048 assinantes em 16 portas GPON (1:128 split ratio), possui 4 portas 1GbE (elétricas em
RJ45) e 4 portas 10 GbE em conectores SFP+. É totalmente compatível com o padrão ITU-T G.984 e ITU-T.988. Cada
enlace GPON suporta taxas de downstream 2,488 Gbit/s e upstream 1,244 Gbit/s e oferece alocação dinâmica de banda
(DBA).
O DM4610 OLT GPON é uma solução compacta de 1U de altura e com ótimo custo benefício para prover serviços FTTx.
Possui 8 portas GPON, 12 portas 1GbE e 2 portas 10 GbE em conectores SFP+. É compatível com o padrão ITU-T G.984 e
ITU-T G.988. Cada enlace GPON suporta taxas de downstream 2,488 Gbps e upstream 1,244 Gbps além de oferecer
alocação dinâmica de banda (DBA). A configuração dos requisitos de rede é realizada remotamente pelo protocolo OMCI.
Suporta alimentação AC ou DC em fontes de alimentação independentes, redundantes e hot-swappaple.
O DM4612 OLT GPON é uma solução compacta de 1U de altura para instalação em rack 19’, contendo 8 interfaces GPON
para suporte até 1024 assinantes (1:128 split ratio), 2 interfaces GE elétricas RJ45 e 2 interfaces 10GE/GE SFP+. Contém
dois slots para fonte de alimentação full range AC/DC redundantes e hot swap.
O DM4611 OLT GPON é uma solução compacta de 1U de altura para instalação desktop ou rack 19’, contendo 4
interfaces GPON para suporte até 512 assinantes (1:128 split ratio), 2 interfaces GE elétricas RJ45 e 2 interfaces 10GE/GE
SFP+. Fonte de alimentação interna full range AC/DC e opção de redundância de alimentação através de entrada auxiliar
12V.
DM4618 é uma solução modular com 32 portas GPON fixas e um slot de expansão que permite equipá-lo com mais 32
portas GPON. Suporta um Split ratio de 1:128 nas portas GPON. Como uplink possui duas portas de 100GbE (QSFP28) e
quatro portas 25GbE/10GbE em SFP28/SFP+.

GPON - Módulo e ONUs
SFP GPON ONU Bridge ONU Router ONU Router com Wi-Fi ONU Router com Wi-Fi
Laser B+ // C+ // D DM984-100B DM984-420 DM984-422 DM985-424 / DM986-414
Opção de Temperatura Laser C+ PTO integrado 2,4GHz Dual Band

Estendida: 85ºC
PTO integrado SC APC PTO integrado SC APC
SC PC
SC APC FXS SC APC FXS
FXS
DM985-100 / DM986-100 DM985-100 / DM986-100
DM986-204
Bridge e Router Bridge e Router
Dual Band
SC APC SC APC
SC APC
14
A família DM984 GPON ONU oferece solução de acesso em fibra ótica de alta velocidade. Permite que sejam oferecidos
serviços de dados, voz e vídeo sobre IP para usuários empresariais e residenciais. Os dados Ethernet são transportados
de forma transparente pelo link GPON e entregues a uma OLT. Possui capacidade de adicionar, remover e alterar VLANs,
além de suportar QoS e multicast para o transporte de vídeo. Estão disponíveis 3 modelos, DM984-100B – ONU Bridge,
DM984-420 – ONU Router e DM984-422 ONU Router com WiFi.
O DM985-100 GPON ONU é uma solução compacta e de alta capacidade para redes de acesso FTTx. Oferece solução de
acesso em fibra óptica de alta velocidade, sendo totalmente compatível com os padrões ITU-T G.984 e ITU-T.988.
Permite que sejam oferecidos serviços de dados, voz e vídeo sobre IP para usuários residenciais.
A ONU DM986 pode ser fornecida em dois modos de operação diferentes, sendo um deles para operações em modo
Bridge e com suporte a GPON/EPON e outro para operações em modo Router PPPoE ou DHCP com suporte a IPv4 e IPv6
com gerenciamento por TR-069. Também é possível trocar o modo de operação da ONU entre bridge ou router através
de atualização de firmware.
O modelo DM985-424 possui uma interface Wi-Fi avançada para suportar aplicações que exigem alto tráfego de dados.
Quatro antenas externas de alto ganho (duas para 2,4 GHz e duas para 5 GHz) oferecem cobertura superior, que junto
com o MIMO 2x2 e Beamforming em 5,8 GHz, criam uma conexão Wi-Fi rápida e estável.
A DM986-414 é uma ONU GPON completa com uma interface Wi-Fi avançada para suportar aplicações que exigem alto
tráfego de dados. Quatro antenas externas de alto ganho (duas para 2,4 GHz e duas para 5 GHz) instaladas em duas
hastes oferecem cobertura superior, que junto com o MIMO 2x2 e Beamforming em 5 GHz, criam uma conexão Wi-Fi
rápida e estável.
A ONU DM986 – 204 oferece uma solução de acesso em fibra óptica de alta velocidade com suporte a duas (02) interfaces
LAN Gigabit Ethernet e também suporte a Wi-Fi 2.4GHz e 5.8Ghz (802.11 b/g/n/ac) com duas antenas externas,
garantindo um excelente desempenho e ampla cobertura na rede wireless dos clientes residenciais. Quatro antenas
externas de alto ganho (duas para 2,4 GHz e duas para 5 GHz) instaladas em duas hastes oferecem cobertura superior,
que junto com o MIMO 2x2 e Beamforming em 5 GHz, criam uma conexão Wi-Fi rápida e estável. Conta ainda com o
recurso de gerência remota através do protocolo TR-069.

MultiProtocol Label Switching
Apresentaremos os conceitos envolvidos na tecnologia MPLS tradicional e por Engenharia de Tráfego, bem como os
comandos necessários para a sua configuração. Ao término você estará apto à:
• Compreender os conceitos da tecnologia e a nomenclatura utilizada;

• Configurar a infraestrutura do MPLS através da distribuição de labels realizada pelo LDP e RSVP-TE;
• Analisar o funcionamento da infraestrutura MPLS;
• Identificar possíveis falhas e atuar de rapidamente na sua solução.

MPLS – MultiProtocol Label Switching
O MPLS é definido como uma tecnologia e não um protocolo, desenvolvido pelo IETF na RFC 3031 com o objetivo de criar
uma rede de trânsito, transportando pacotes entre pontos de entrada e saída.
Alguns benefícios da sua implantação são:

1. Redução do esforço operacional;
2. Redução do risco de indisponibilidade;
3. Aumento da escalabilidade;
4. Utilização de uma única infraestrutura;
5. Facilidade de entrega de serviços ao cliente;
6. Melhor acomodação dos fluxos e utilização dos links;
7. Rápida viabilidade para IPv6;
8. Tecnologia madura.
Utiliza marcações simples e específicas chamadas de labels, que orientam como os pacotes serão encaminhados. 16
O MPLS proporciona a combinação das características do processo de roteamento como flexibilidade, imunidade a loops e
escalabilidade com as características da comutação sobre a camada 2, que aborda a eficiência do encaminhamento. Além
dos benefícios citados acima, temos:
• Gerência: Facilidade de visualizar os requisitos de desempenho e disponibilidade;

• Desempenho: Garantia de QoS para diferentes tráfegos e aplicações;
• Disponibilidade: Capacidade de prover acesso ininterrupto;
• Segurança: Redução dos riscos e ameaças as informações trafegadas;
• Escalabilidade: Capacidade de crescer e se ajustar a novas topologias.
A presença da palavra multiprotocol remete a capacidade de integração e transporte que a tecnologia possui, visto ser
compatível com diversos protocolos de camada 3, bem como as tecnologias envolvidas na camada 2.
Realizando um paralelo com a tecnologias vigentes, temos:
Tecnologias de Camada 2 Tecnologias de Camada 3 MPLS
Encaminhamento Baseado em endereços Baseado em endereços IP Baseado em labels

MAC de destino de destino
Control Plane Protocolos de prevenção Protocolos de roteamento Protocolo de roteamento e

de loops (xSTP, EAPS, (OSPF, BGP) MPLS
ERPS)
Encapsulamento do Pacote Cabeçalho 802.3 Cabeçalho IP MPLS shim header
QoS 3 bits no campo PCP 8 bits no campo TOS no 3 bits no campo EXP do
contido no TAG de VLAN cabeçalho IP shim header
TTL Não há suporte Há suporte Há suporte
Outras soluções viabilizadas pelo uso MPLS são uma infraestrutura melhor alinhada e compatível com os padrões Metro
Ethernet, utilização de VPNs de camada 2 e camada 3, combinação do transporte puramente L2 e MPLS em uma mesma
porta de acesso, implementação de parâmetros de QoS e melhores tempos de convergência em caso de falhas.

Topologia MPLS
Cabeçalho L2
Cabeçalho LSR1 / PHP

MPLS Label 25
Cabeçalho IP
Dados
LSR3 / PHP
LSP
CE PE1 (LER/Edge LSR) CE
Site 1 Site 3
CE
Cabeçalho L2
Cabeçalho IP PE2 (LER/Edge LSR)

Site 2
Dados
Cabeçalho L2
Domínio MPLS Cabeçalho IP

Dados
17
A imagem acima demonstra uma topologia típica MPLS.
Os equipamentos conectados diretamente ao cliente, são chamados de PEs e realizam a inserção deste tráfego na rede
MPLS para o transporte. Os dispositivos contidos no interior da nuvem ou do domínio, de acordo com o desenho acima,
são chamados de LSRs e tomam as decisões de encaminhamento apenas com base nos labels ou rótulos.
O caminho ao longo do domínio MPLS é chamado de LSP e são constituídos de forma unidirecional.

Shim Header
O cabeçalho do MPLS é o elemento fundamental desta tecnologia.
Cabeçalho L2 Cabeçalho MPLS Cabeçalho L3 Dados
Label EXP S TTL
4 bytes / 32 bits
Campo Descrição
Label Utilizado para decisão de encaminhamento
EXP ou TC Qualidade de Serviço
S Bit de “stack” utilizado para o empilhamento de cabeçalhos MPLS, indica o último cabeçalho
TTL Tempo de vida do pacote
18
Label - Rótulo/Etiqueta: Identificador curto, de tamanho fixo e de valor local que é utilizado para identificar uma FEC.
Este campo possui um total de 20 bits, o qual totaliza 1.048.576 possibilidades locais de identificação. Alguns valores são
reservados ao protocolo e com significados especiais, conforme definido na RFC 3032 e visualizado a seguir.
Labels Aplicações
0 a 15 Outras aplicações / reservados

16 a 239 Liberados para uso
240 a 255 Reservado para P&D
256 a 1.048.575 Expansão / Reserva
Cada shim header MPLS acrescenta 4 bytes ao tamanho do pacote.
EXP - Experimental bits: Este campo é composto por três bits e é destinado para a sinalização de CoS - Class of Service.
Corresponde a uma cópia dos bits de precedência IP do indicador de QoS - Quality of Service em um pacote.
CoS L2
DSCP L3
EXP MPLS
S - Bottom of stack: Formado por apenas um bit, permite a criação de uma pilha hierárquica de labels e indica se o
cabeçalho ao qual o pacote pertence é o último ou não da pilha.
TTL - Time to Live: Este campo é formado por oito bits e tem a função de evitar que o pacote fique em loop na rede MPLS,
a cada tomada de decisão por um LSR será subtraído deste campo o valor um no label do topo da pilha, independente se a
ação a ser realizada seja um push, swap ou pop.

Shim Header – Label Space
Campo com tamanho de 20 bits, totalizando 1.048.576 possibilidades. O label é alocado de forma dinâmica e possui
significado apenas local.
Labels Descrição Uso

0 IPv4 Explicit Null O label é removido, porém o cabeçalho/shim
Label header necessita ser enviado ao último
equipamento por questões de QoS ou TTL.
Labels Aplicações 1 Router Alert Label Avisa o que next-hop deve analisar o pacote
0 a 15 Reservado ao protocolo MPLS e que o seu encaminhamento será
definido pelo próximo label da pilha MPLS
16 a 239 Liberados para uso
2 IPv6 Explicit Null Mesma função do label zero, porém aplicada
240 a 255 Reservado para P&D
Label ao protocolo IPv6 (6PE /6VPE)
256 a 1.048.575 Expansão / Reserva
3 Implicit Null Label Sinaliza ao penúltimo LSR que retire o label
antes de encaminhar o pacote ao next-hop,
executando a ação de PHP
4 a 15 Reservados para OAM Alert Label (label 14) - Utilizado para
definições futuras funções de manutenção, operação e
administração. Não é obrigatório o seu uso.
19
O espaço do label é um intervalo de valores regido de acordo com a tabela acima.
Explicit Null Label – Significa que o label não é necessário, porém o shim header precisa ser enviado, por questões de
QoS, desta forma, o label sinalizado será zero. Válido para IPv4, para IPv6 o label sinalizado é o dois. O DmOS não possui
suporte a este valor de label.
Router Alert Label – Possui o propósito de avisar o next-hop para que analise com maior atenção o pacote MPLS. Se este
valor estiver no top label de um pacote MPLS recebido, o LSR deverá encaminhá-lo para processamento local. O pacote
poderá ser retransmitido com base no label inferior.
Implicit Null Label – É exclusivo do LDP (Label Distribution Protocol) e sinaliza ao penúltimo LSR que retire o label antes
de encaminhar o pacote, executando assim a ação de penultimate hop popping.
Os valores 4 a 15, com exceção do 14, estão reservados para uso futuro e podem ser consultados através da RFC 3032.

Shim Header – Label Stacking
Dispositivos operando com MPLS podem necessitar de mais labels para realizar o encaminhamento do pacote e para o
atendimento deste requisito, utiliza-se o conceito de empilhamento ou stacking.
S=0 S=0 S=1
Top Middle Bottom

Cabeçalho L2 Cabeçalho IP Payload
label label label
Ethertype 0x8847
20
O MPLS suporta o empilhamento de vários labels, onde o mais próximo do cabeçalho da Camada 2 é identificado como o
label do topo da pilha, é o mais externo e refere-se ao protocolo de distribuição de labels. Já o label próximo ao cabeçalho
da Camada 3 é identificado como label interno ou inner e como exemplos temos o label de uma VPN ou de outro serviço,
como o FAT.
Frame Header
TE / LDP Label (LSP) Outer Label
VPN Label
Inner Label
FAT Label
IP Header

Shim Header
A estrutura do cabeçalho MPLS pode ser observada através da captura de pacotes com aplicativos específicos.
Próximo cabeçalho
Cabeçalho MPLS (top label)
Label de Infraestrutura
(LDP ou RSVP)
Qualidade de serviço
Empilhamento de labels
S=0 - não é a último label
S=1 - último label (bottom)
TTL
Label VPN
Label FAT 21
No cabeçalho Ethernet, o Ethertype como visualizado abaixo, informa que o pacote possui um label, onde é sinalizado com
o valor de 0x8847 para o tráfego unicast, definindo assim, que o dispositivo faça a consulta a LFIB e o valor 0x8848 para o
tráfego multicast.
O outer label (top ou mais externo) é utilizado na decisão de encaminhamento do pacote na rede MPLS e os inners labels
são utilizados para separar o pacotes no ponto de saída, tipicamente utilizados para erviços L2VPN, por exemplo.

Protocolos de Distribuição de Labels
A geração de labels ou rótulos no MPLS pode ser realizada através de três
protocolos:
• LDP - Label Distribution Protocol: Protocolo responsável por alocar e distribuir

labels para prefixos/rotas IGP, através de vizinhanças
• RSVP-TE - Resource Reservation Protocol Traffic Engineering: Extensão do

RSVP utilizada para distribuir labels baseado em restrições ou critérios.
• MP-BGP: Extensão do BGP que permite distribuir labels.
22
O protocolo LDP é bastante utilizado para fornecer serviços através de VPNs devido a sua simplicidade de configuração,
pela capacidade de estabelecer caminhos de forma dinâmica com base em informações de roteamento e na capacidade
de suportar vários caminhos.
A engenharia de tráfego dentro do RSVP, possui o objetivo de melhorar a utilização dos recursos presentes na
infraestrutura, gerando maior rendimento e reduzindo o custo da rede. A distribuição de labels baseia-se em restrições,
critérios e se necessário, a largura de banda para definição do melhor caminho.
A distribuição de labels baseada na extensão do BGP é utilizada no contexto de L3VPNs para prefixos IPv4 e IPv6 e as
informações de mapeamento de labels são transportadas como parte do NLRI – Network Layer Reachability Information.

PE – Provider Edge
São os pontos de entrada e saída do domínio MPLS, com o objetivo de adicionar ou retirar o cabeçalho MPLS/Labels.
• Denominado como equipamento que recebe as conexões dos CEs – Customer Edges;
• Também conhecido por LER - Label Edge Router, Edge LSR ou Ingress/Egress LSR;
• Adiciona cabeçalho MPLS quando um pacote ingressa no domínio MPLS - push e remove cabeçalho MPLS quando um
pacote deixa o domínio MPLS - pop.
Cabeçalho L2 Cabeçalho L2
Cabeçalho L2 Cabeçalho Cabeçalho
MPLS Label 34 MPLS Label 3 Cabeçalho L2
Cabeçalho IP
Cabeçalho IP Cabeçalho IP Cabeçalho IP
Dados
Dados Dados Dados
CE1- Site 1 PE1 (LER/Edge LSR) PE2 (LER/Edge LSR) CE2 – Site 2
In Out Out Domínio MPLS

Prefix Action Label Label interface
---------------------------------------------
PE2 psh - 34 LSR1
23
PE (Provider Edge): Recebe as conexões do cliente. Adiciona ou retira o cabeçalho MPLS.
Ingress: Recebe o pacote ainda sem label e insere o label;

Egress: Recebe o pacote com o label, remove o label stack e o encaminha.
Edge LSR : Conhecido também por LSR de borda, tem a mesma função do PE, inserindo ou retirando as labels do MPLS.

LSR – Label Switching Router
Dispositivo que exerce a função de inspecionar o label de entrada e mapeá-lo em label de saída.
• A decisão de encaminhamento é baseada exclusivamente nos labels;

• Não considera as informações encapsuladas - camada 3;
• Sempre ao passar por um LSR o pacote sofrerá uma ação, conforme a sua posição na topologia – Swap / Pop;
• Os labels possuem significado local.
Cabeçalho L2 Cabeçalho L2 Cabeçalho L2
Cabeçalho Cabeçalho Cabeçalho

MPLS Label 34 MPLS Label 45 MPLS Label 3
Cabeçalho IP Cabeçalho IP Cabeçalho IP
Dados Dados Dados
PE1 LSR1 LSR2 PE2
Domínio MPLS
In Out Out In Out Out
Prefix Action Label Label interface Prefix Action Label Label interface
--------------------------------------------- ---------------------------------------------
PE2 swp 34 45 LSR2 PE2 php 45 3 PE2
24
O equipamento posicionado como LSR - Label Switch Router tem a função de inspecionar o label de entrada e mapeá-lo
em um label de saída utilizando o Incoming Label Map ou ILM, sem considerar as informações encapsuladas.
Sempre ao passar por um LSR o pacote sofrerá uma ação, conforme a seguir:
• Push: Insere um ou mais labels na pilha;

• Swap: Troca o label do topo da pilha;
• Pop: Remove um ou mais labels da pilha.
Os labels possuem significado local e são negociados pelos LSRs adjacentes, por tanto, não mantém o mesmo valor em
todo o trajeto, mas sim, altera-se a cada LSR, podendo inclusive, ser utilizado em mais de uma vez por trecho. Para
garantir a singularidade do valor de um label, o LSR não poderá associar um mesmo ID a duas diferentes FECs para
distribuição em uma mesma interface de saída.

LSP – Label Switched Path
O LSP é composto pela sequência ordenada de todos os labels que serão utilizado para encaminhar o tráfego entre o PE de
entrada e o PE de saída e comporta-se de forma unidirecional.
O caminho utilizado é derivado das informações de roteamento.
LSP
LSP do PE1 até o PE2
LABEL 34 LABEL 45 LABEL 3
LABEL 34 >> LABEL 45 >> LABEL 3
O LSP é unidirecional, então teremos LABELs de IN e OUT
PE1 LSR1 LSR2 PE2
Domínio MPLS
Direção do Tráfego
25
O LSP é definido como o caminho percorrido entre dois PEs quaisquer dentro do domínio MPLS, conforme a determinação
de uma FEC. Este caminho é unidirecional e contém todas as sequências de labels que serão utilizadas para encaminhar o
tráfego.
O primeiro label é inserido pelo PE de entrada, que pertence a um determinado caminho/LSP. Por todo o transporte, os
labels do top da pilha são alterados a cada passagem por um LSR intermediário. O PE de saída retira os labels e encaminha
o pacote. Os LSRs devem concordar sobre qual label utilizar para cada prefixo IGP. Cada LSR deve ser capaz de descobrir
com qual label de saída o label de entrada deve ser trocado. Para que o LSP seja criado é necessário habilitar um protocolo
de distribuição de labels, como o LDP ou RSVP.
O equipamento aloca um label para cada rota ou possibilidade de caminho. Esta informação pode ser consultada através
do show mpls ldp database.

FEC – Forwarding Equivalence Class
Consiste no agrupamento de pacotes que possuem algum tipo de equivalência com o objetivo de fornecer o mesmo
tratamento/label, seja por possuírem o mesmo próximo salto, mesma origem IP, tipo de fluxo, porta TCP/UDP, QoS ou outros
atributos.
Cada endereço IP de destino dentro da rede MPLS receberá uma FEC e cada FEC é definida por um label. O dispositivo ao
receber um pacote faz a verificação de qual FEC pertence e o encaminha através de um LSP correspondente.
LSP
Tráfego CE2
Tráfego CE3
Tráfego CE2
CE1- Site 1 PE1 LSR1 LSR2 PE2 CE2 – Site 2
In Out Out CE3 – Site 3

Prefix Action Label Label interface Domínio MPLS
-------------------------------------------
PE2 psh - 34 LSR1
In Out Out In Out Out
Prefix Action Label Label interface Prefix Action Label Label interface
------------------------------------------- -------------------------------------------
PE2 swp 34 45 LSR2 PE2 php 45 3 PE2 26
A FEC (Forwarding Equivalence Class) é um grupo de pacotes com características similares. Criada para facilitar e
direcionar pacotes com mesmo destino de próximo salto.
A regra de formação de uma FEC pode ser baseada, por exemplo, no endereço IP de destino, ou ainda na porta pela qual os
pacotes foram recebidos pelo PE. Pacotes pertencentes a uma FEC comum, sempre seguem pelo mesmo caminho. Um
label identifica uma FEC.

FTN – FEC to NHLFE
Realiza o mapeamento dos pacotes que ingressam na rede MPLS sem label para uma FEC e esta a um NHLFE (LFIB) através da
ação de push.
FTN
Push
Cabeçalho L2
Cabeçalho
Cabeçalho L2 MPLS Label 34
Cabeçalho IP Cabeçalho IP
Dados Dados
CE1- Site 1 PE 1 LSR1 LSR2 PE2 CE2 – Site 2
Pacote recebido sem LABEL. O PE realizará

o mapeamento FTN, que consultará o NHLFE CE3 – Site 3
(tabela LFIB), que encaminhará o tráfego Domínio MPLS
por uma FEC específica, associada a um
label. Operação: PUSH
Direção do Tráfego 27
O PE receberá um pacote sem label que deverá ser transmitido pela rede MPLS. A sua primeira ação, será obter o valor da
FEC correspondente com os registros contidos na sua LFIB, de onde será extraído o label de saída e acrescentado ao
pacote MPLS e encaminhado a interface de saída.
O processo de mapeamento na LFIB é chamado de FTN (FEC-to-NHLFE) e definido na RFC 3031.
Não há leitura dos campos de camada 2 e camada 3 dentro do transporte MPLS, o campo Ethertype será identificado com
o código 0x8847 – MPLS label switched packet.
Cada FEC possui um conjunto de NHLFEs no PE de entrada que será utilizado para definir quais labels serão atribuídos e
como serão encaminhados. Também orienta como o PE de saída desencapsulará o cabeçalho MPLS.
A ação realizada nesta etapa é o PUSH, onde é adicionado um cabeçalho MPLS com um determinado valor de label/rótulo.
Essa operação ocorre no PE de entrada.

ILM – Incoming Label Map
Realiza o mapeamento de um label de entrada, permitindo que o LSR tome as decisões de encaminhamento. As ações
executadas são swap e pop. Cada label é mapeado para uma NHLFE (LFIB).
ILM ILM
Swap PHP/POP
Cabeçalho L2 Cabeçalho L2 Cabeçalho L2
Cabeçalho Cabeçalho Cabeçalho

MPLS Label 34 MPLS Label 45 MPLS Label 3 Cabeçalho L2
Cabeçalho IP Cabeçalho IP Cabeçalho IP Cabeçalho IP
Dados Dados Dados Dados
CE1- Site 1 PE 1 LSR1 LSR2 PE2 CE2 – Site 2
CE3 – Site 3
Pacote recebido com LABEL. O PE realizará
o mapeamento ILM, que consultará o NHLFE
Domínio MPLS Pacote recebido com LABEL. O PE realizará
(tabela LFIB), que encaminhará o tráfego o mapeamento ILM, que consultará o NHLFE
por uma FEC específica, associada a um (tabela LFIB), que encaminhará o tráfego
label. Operação: SWAP por uma FEC específica, associada a um
label. Operação: PHP
Direção do Tráfego 28
Não há leitura dos campos de camada 2 e camada 3 dentro do transporte MPLS, o campo Ethertype será identificado com
o código 0x8847 – MPLS label switched packet.
O LSR ao receber um pacote com o cabeçalho MPLS, realizará o mapeamento de acordo com o label recebido - incoming
em um registro NHLFE da sua LFIB, onde obterá um label de saída e encaminhará a interface de saída associada. A ação
executada é a de troca de labels ou swap. O processo de mapeamento nesta etapa é chamado de ILM - Incoming Label Map
e definido na RFC 3031.
O penúltimo equipamento, identificado com a função de PHP, realizará o mapeamento do label de entrada, porém sem
obter valores de label de saída, indicando o label especial Implicit null - ID 3.
As ações realizadas são:
SWAP: Troca o valor do label/rótulo. Essa operação é realizada para comutação dentro do domínio MPLS. Mesmo que o
valor do novo label seja idêntico ao anterior, esta operação é realizada, pois o valor do label tem significado local e não é
propagado salto-a-salto.
POP: Remove o cabeçalho MPLS quando o pacote sai do domínio MPLS. Esta operação é realizada pelo PE de saída.

NHLFE – Next Hop Label Forwarding Entry
A NHLFE exerce a função de descrever a operação a ser executada e a interface de saída por onde ocorrerá o encaminhamento
dos pacotes.
DmOS# show mpls forwarding-table

In In Out Out Out
Prefix or Tunnel-Name Action Label Proto Label Proto interface Status
-----------------------------------------------------------------------------------------------
22.22.22.22/32 fwd -- -- ImpNull ldp l3-vlan 2122 active
22.22.22.22/32 php 115 ldp ImpNull ldp l3-vlan 2122 active
23.23.23.23/32
23.23.23.23/32
psh
swp
--
110
--
ldp
25
25
ldp
ldp
l3-vlan 2135 active
l3-vlan 2135 active
Mapeamento realizado pelo FTN
24.24.24.24/32 psh -- -- 24 ldp l3-vlan 2135 active
24.24.24.24/32
35.35.35.35/32
swp
fwd
111
--
ldp
--
24 ldp
ImpNull ldp
l3-vlan 2135 active
l3-vlan 2135 active
Mapeamento realizado pelo ILM
70.70.70.70/32 swp 113 ldp 27 ldp l3-vlan 2135 active
29
A NHLFE é a entrada de encaminhamento de labels ou rótulos de próximo salto utilizada para orientar o encaminhamento
de pacotes MPLS. Uma NHLFE realiza a especificação da interface de saída, do próximo salto, do label de saída e a sua
ação e pode ser consultada através da LFIB, onde pode-se observar todo o mapeamento ILM e FTN.
Diferentemente do roteamento baseado no endereçamento IP, o próximo saldo para um LSR representa não apenas a
interface de saída e endereço MAC, mas também a operação que será executada na pilha MPLS onde o pacote está
encapsulado.

PHP – Penultimate Hop Popping
A função PHP consiste na retirada do cabeçalho MPLS referente ao top/outer label no penúltimo LSR da topologia, não
comprometendo o funcionamento de um LSP.
Com esta técnica, o PE inspeciona apenas o inner label.
Cabeçalho L2
Cabeçalho
MPLS Label 45 Cabeçalho L2
Cabeçalho IP Cabeçalho IP
Dados Dados
CE1- Site 1 PE1 LSR1 LSR2/PHP PE2 CE2 – Site 2
Implicit-null
Label 3 CE3 – Site 3
Domínio MPLS
In Out Out
Prefix Action Label Label interface
--------------------------------------------------
PE2 php 45 ImpNull PE2
30
Para que o penultimate hop popping ocorra é necessário que o PE de destino solicite este recurso ao penúltimo salto,
mediante ao envio de um implicit null, oferecendo maior escalabilidade em redes MPLS uma vez que diminui o número de
ILMs necessárias em um dispositivo de borda e também, alivia o esforço do PE ter que consultar a tabela ILM, remover o
rótulo MPLS e analisar o pacote para determinar o próximo passo a ser realizado.
Quando o PE escolher implicit-null, nenhum label precisa ser adicionado ao pacote (todavia o pacote pode conter outros
labels MPLS que não devem ser removidos).
O label ”3” é um label reservado e tem signiﬁcado apenas para os protocolos de divulgação de labels (LDP, RSVP). Um
pacote nunca poderá ser encaminhado com este label.
O label atribuído por um PE de saída compatível com a função PHP pode ser:
• Label 0 (zero): A saída atribui um label nulo explícito a uma FEC e anuncia a vinculação do label ao LSR upstream
(anterior). Ao encaminhar um pacote MPLS, o LSR upstream substitui o label no topo da pilha pelo label de ID zero e
envia o pacote para a interface de saída. Utilizado em conjunto com QoS. O sistema operacional DmOS não possui
suporte a este recurso.
• Label 3: Este label não é visível (não aparece) na pilha de rótulos. Um LSR executa diretamente a operação de pop para
os pacotes que correspondem ao label nulo implícito (ID 3), em vez de substituir o label pelo rótulo original no topo da
pilha, na sequência o LSR encaminha o pacote para ao PE de saída.

LDP – Label Distribution Protocol
Protocolo específico e responsável pela distribuição de labels, desenvolvido pelo IETF na RFC 5036, que define um conjunto
de procedimentos e mensagens para o estabelecimento de LSPs pelo LSR, enviadas por PDUs, que são compostas por um
cabeçalho seguido de uma ou mais mensagens encapsuladas em TLVs (Type-Length-Value).
Os labels são distribuídos do sentido downstream para o upstream.
Para 4.4.4.4/32 Para 4.4.4.4/32 Para 4.4.4.4/32

Label = Z Label = Y Label = 3
PE1 LSR1 LSR2/PHP PE2
Domínio MPLS
31
A troca de mensagens LDP ocorre pelo envio de PDUs - Protocol Data Units LDP sobre as sessões LDP já estabelecidas. Cada
PDU LDP é composta por um cabeçalho seguido de uma ou mais mensagens LDP, encapsuladas em TLVs. As mensagens
LDP transportadas em uma mesma PDU não precisam ter relação entre si, por exemplo, uma PDU LDP pode transportar
uma mensagem de LABEL REQUEST para um determinado conjunto de FECs e outra mensagem de LABEL MAPPING para
outro conjunto de FECs e se necessário, ainda uma terceira mensagem de NOTIFICATION.
Cada LDP PDU tem um cabeçalho seguido por uma ou mais mensagem LDP, conforme abaixo.
Onde o cabeçalho LDP contém:
• Version – Versão do protocolo LDP;

• PDU Length – Tamanho total da PDU LDP em octetos, excluindo os campos version e PDU Lenght e é negociado no
estabelecimento de uma sessão;
• LDP Identifier – Identificados único que contém o LSR-ID e o espaço do label em uso pelo LSR, por exemplo
35.35.35.35:0;
• Label Space – Pode ser por interface ou plataforma. Por interface identifica cada interface do LSR e é utilizado entre
LSRs diretamente conectados. Quando por plataforma, as interfaces do LSR podem compartilhar o mesmo espaço de
etiquetas.

LDP - PDU
MAC Destino = Multicast 01-00-5E-00-00-02 ou específico da interface
MAC Origem = Endereço da interface de envio
Cabeçalho L2 Cabeçalho IP UDP/TCP Cabeçalho LDP
Version PDU Length

LDP PDU
IP Origem = endereço da interface de envio Header LDP Identifier (LSR-ID + Label Space)
IP Destino = Multicast 224.0.0.2 ou específico da interface
Protocolo = 17 (UDP) ou 6 (TCP)
LDP Message
U Message Type Message Length

Message Header
Message ID
Mandatory Parameters (TLVs)
TLVs
Optional Parameters (TLVs) 32
O LDP utiliza TLVs para codificar a maioria das informações de uma mensagem LDP, sendo:
• U Bit – Unknown TLV bit: Se a mensagem recebida conter o valor zero, uma mensagem de notificação é retornada ao
LSR que a originou. Se o valor for igual a um, o campo é ignorado;
• Type: Indica o tipo de mensagem;
• Length: Especifica o tamanho em octetos dos próximos campo;
• Message ID: Representa um número sequencial, utilizado para identificar uma mensagem, o que permite enviar uma
mensagem correta de notificação;
• Mandatory Parameters: Parâmetros obrigatórios a serem informados;
• Optional Parameters: Contém informações adicionais e não obrigatórias de algumas mensagens LDP.
A RFC 5036 define o uso de TLVs apenas para as mensagens LDP que justifiquem a sua aplicação e alguns dos seus tipos
são visualizados abaixo.
TLV Código Aplicação
FEC 0x0100 Contém elementos que definem cada FEC.
Address List 0x0101 Utilizado nas mensagens de address e address withdraw, onde indicam a família
de endereços utilizados.
Hop Count 0x0103 Utilizados em mensagens de label request ou label mapping e possui o propósito
de implementar mecanismos de detecção de loops.
Path Count 0x0104
Generic Label 0x0200 Estão associados às mensagens de advertisement.
Status 0x0300 Utilizado nas mensagens de notification com o propósito de especificar eventos.
Extended Status 0x0301 Complementa informações de status das mensagens de notification.
Returned PDU 0x0302 Retorna parte de um LDP PDU ao LSR que a enviou. Faz parte da mensagem de
notification.
Returned Message 0x0303 Retorna parte de uma mensagem LDP ao LSR que a enviou. Faz parte da
mensagem de notification.
Common Hello Parameters 0x0400 Especifica parâmetro comuns a todas as mensagens de Hello.
Common Session Parameters 0x0500 Especifica os valores propostos pelo LSR a serem negociados.
Label Request Message ID 0x0600 Resposta a mensagem de solicitação de label.

LDP – Mensagens
Há quatro categorias de mensagens:
• Descoberta – Discovery Messages: Anunciar e manter a presença de um LSR;

• Sessão – Session Messages: Estabelecer, manter e encerrar as sessões LDP entre dois LSRs;
• Anúncio de Etiquetas – Advertisement Messages: Criar, modificar, gerenciar e excluir associações de labels à FECs;
• Notificação – Notification Messages: Fornecer informações de estado e sinalizar erros.
O LDP utiliza o TCP – Transmission Control Protocol para garantir uma transmissão confiável das mensagem de sessão, anúncio
e notificação. O UDP – User Datagrama Protocol é utilizado apenas nas mensagens de descoberta.
33
Há 13 tipos de mensagens LDP, de acordo com a tabela a seguir.
Mensagem Código
Notification 0x0001
Hello 0x0100
Initialization 0x0200
Keepalive 0x0201
Address 0x0300
Address Withdraw 0x0301
Label Mapping 0x0400
Label Request 0x0401
Label Withdraw 0x0402
Label Release 0x0403
Label Abort Request 0x0404
Vendor- private extensions 0x3F00

0x3EFF
Experimental extensions 0x3F00
0x3FFF

LDP – Adjacência
1.1.1.1 2.2.2.2
A primeira mensagem enviada pelo protocolo LDP é o
Discovery Messages, que ocorre através do envio de
um Hello para o endereço de multicast 224.0.0.2,
com o objetivo de anunciar e manter a presença de Hello
UDP Porta 646
10.1.2.1:y para
Hello 224.0.0.2:646
um LSR na rede, através de uma sessão UDP na porta
646. Hello
10.1.2.0:x para
UDP Porta 646 Adjacência formada
224.0.0.2:646 Hello
Os parâmetros hello interval (5 segundos) e hold

time (15 ou 45 segundos) visam manter a adjacência,
mesmo após o estabelecimento da sessão.
34
A mensagem Hello contém informações importantes como o Router ID (4 bytes), que por default é definido pelo endereço
IP da loopback e o Label Space (2 bytes), que visa informar se o label trocado é por plataforma (valor de zero) ou por
interface (valores diferentes de zero).
Constantemente o protocolo envia mensagens de Hello com o objetivo de verificar se a adjacência está ativa, caso ocorra
a falha de três hellos consecutivos, a sessão será encerrada. Se houver falha na interface diretamente conectada, a sessão
será excluída imediatamente.

LDP – Descoberta de Peers
A descoberta pode ser realizada através de dois mecanismos:
• Basic: Utilizado para os vizinhos diretamente conectados e ocorre pela mensagem chamada de Link Hello no endereço de
multicast;
• Extended: Para os vizinhos indiretos ou remotos, com a mensagem Targeted Hello via unicast para um endereço IP
específico.
Adjacência remota
Adjacência local Extended
Basic
PE1 LSR1 LSR2 PE2
Domínio MPLS
35
A adjacência diretamente conectada é identificada pelo LSR através do envio periódico de Hellos de Link LDP pela
interface diretamente conectada, via UDP na porta 646 no endereço de multicast 224.0.0.2 (all routers on this subnet) e é
chamada de Basic Discovery Process.
As sessões LDP entre LSRs indiretos são suportados pelo mecanismo de Extended Discovery, onde o LSR envia
periodicamente Hellos utilizando mensagens targeted direcionadas para um endereço IP específico/unicast sobre UDP
na porta 646. Diferente do mecanismo Basic, o LSR remoto decide se deve ou não responder o Hello. Após a troca de
mensagens, o LSR ativo inicia conexão TCP porta 646 para o IP informado pelo peer através do campo Transport Address.
Se o mecanismo de descoberta Basic falhar, o Extended pode manter uma sessão entre os peers LDP. As duas sessões
podem coexistir.
Se o hold time expirar, o LSR identifica que a sessão estabelecida via link ou targeted encontra-se em falha ou não é mais
necessária, removendo assim a adjacência. Caso o LSR não receba a mensagem de Hello do seu vizinho antes do
temporizador expirar, o LSR em questão, exclui a adjacência e envia uma mensagem de notificação para encerrar a sessão.

LDP – Hello Message Cabeçalho UDP para estabelecimento de
adjacência – Porta 646
Versão do LDP
LSR ID / IP da Loopback
Tipo de Mensagem: Hello

Hold time de 15 segundos para Link Hello, se
targeted são 45 segundos
Mensagem de Link Hello para o endereço de

multicast 224.0.0.2 na porta UDP 646 para
descoberta com mecanismo Basic
Utilizado apenas para mensagens de Hello
Targeted, para solicitar o envio de hellos
periódicos
Endereço de transporte, utilizado para a

sessão TCP
36
Abaixo, segue um exemplo de captura para de uma mensagem de Hello utilizando o mecanismo Extended com a opção de
Targeted Hello.

LDP – Sessão TCP e LDP
1.1.1.1 2.2.2.2
O LSR com maior endereço IP de transporte será
chamado de ativo e iniciará a conexão TCP através
da porta 646, realizando assim, o envio da segunda Passivo Ativo
mensagem que possui o propósito de estabelecer,
manter e encerrar as sessões. LDP Hello LDP Hello
IPv4 Transport IPv4 Transport

Address = 1.1.1.1 Address = 2.2.2.2
Todo o processo de handshake three-way será
realizado.
Conexão TCP 2.2.2.2:y para

TCP Porta 646 1.1.1.1:646
1.1.1.1:x para Conexão TCP Estabelece, mantém e

2.2.2.2:646 TCP Porta 646 termina as adjacências
37
Para o estabelecimento da sessão TCP é necessário que cada dispositivo conheça o endereço de transporte do vizinho,
identificado na mensagem Hello. Este endereço precisa estar divulgado na tabela de roteamento, de forma que seja
alcançável para posterior troca de labels. Caso contrário, as mensagens Hello são enviadas, mas não haverá adjacência.

LDP – Sessão TCP e LDP
1.1.1.1 2.2.2.2
O LSR ativo envia a mensagem de inicialização, a
qual contém alguns parâmetros para o
funcionamento da sessão, se aceito pelo LSR Passivo Ativo
passivo, a confirmação é realizada com a mensagem
de inicialização seguida do keepalive.
Initalization Message
Características suportadas,
versão do protocolo,
Se a mensagem recebida por confirmada pelo LSR método de distribuição de
labels e outras informações
Initalization Message
ativo, um keepalive será enviado como resposta e o
status do LDP será sinalizado como operacional.
Keepalive
Keepalive LDP operacional/Sessão

estabelecida
Keepalive
38
O objetivo da Session Messages é a de estabelecer, manter e encerrar as sessões entre os dispositivos vizinhos através de
uma sessão TCP na porta 646. O LSR que possuir o endereço IP de transporte de maior valor numérico, inicia a
comunicação TCP, sendo chamado de ativo e o de menor valor numérico, chama-se passivo, que aguarda o emissor da
comunicação.
Os parâmetros a serem negociados pela mensagem de inicialização contém a versão do LDP, o modo de distribuição do
rótulo, temporizador keepalive, comprimento máximo da unidade de dados do pacote (PDU) e espaço do label. Se o LSR
passivo rejeitar os parâmetros, enviará uma mensagem de notificação para o LSR ativo, para parar o processo.
Depois do LSR ativo e passivo aceitarem os parâmetros e aceitarem os keepalive um do outro, a sessão LDP é estabelecida.
O LDP possui mecanismos para monitorar a integridade de uma sessão LDP, a qual baseia-se no recebimento regular de
keepalive. Caso um LSR não receba a mensagem de keepalive antes do seu temporizador expirar, o LSR encerrará a
conexão TCP e enviará uma mensagem de notificação.
As sessões LDP podem ser protegidas com o uso de autenticação MD5.

LDP – Initialization Message
Cabeçalho TCP para estabelecimento
de sessão – Porta 646
Tipo de mensagem: Initialization
Especifica o tempo máximo entre

o recebimento de PDUs
Modo de distribuição de labels
Detecção de loops
39
A mensagem de initialization faz parte do estabelecimento de sessões no LDP e contém parâmetros mandatórios como os
visualizados em parameters.
As mensagens de keepalive são enviadas com o propósito de monitorar a integridade das conexões de transporte da
sessão LDP e não utiliza parâmetros mandatórios e nem opcionais. Abaixo, pode-se conferir a captura do keepalive.
Caso expire o timer do keepalive, o LSR identificará que há um problema e encerra a sessão TCP, que pode ser originada
por uma falha ou por falta do envio de mensagens initialization ou keepalive dentro do tempo esperado.
Um LSR pode tomar a decisão de encerrar uma sessão enviando uma mensagem de shutdown notification.

LDP – Anúncio de Endereços e Labels
1.1.1.1 2.2.2.2
A terceira mensagem - Advertisement visa anunciar
os endereços IP do LSR, a distribuição ou
mapeamento de labels e o seu gerenciamento. Passivo Ativo
Address Messages
O método de anúncio/distribuição de labels é
identificado durante a troca de mensagens de Indica todos os endereços
do LSR
inicialização do LDP. O método utilizado pelo DmOS Address Messages
é modo não solicitado/Unsolicited Downstream.
Label Mapping
Anúncio/distribuição dos
Os LSRs distribuem os rótulos vinculados aos labels
prefixos presentes na tabela de roteamento. Por Label Mapping
padrão, o sistema operacional DmOS atribui rótulos
apenas para máscaras de 32 bits.
Anúncio, Remoção e Liberação de Controla do mapeamento de
Labels FECs em labels
40
Para que a Advertisement Message ocorra, a sessão TCP necessita estar ativa. Abaixo é possível visualizar a captura a
mensagem Label Mapping.

LDP – Address Message
Cabeçalho TCP para estabelecimento
de sessão – Porta 646
Tipo de Mensagem: Address
Família de endereços utilizada
Lista de IPs associados a interfaces

locais que possuem o LDP
habilitado. Utilizado também para
vincular um next hop
41
As mensagens do tipo address são enviadas para comunicar os endereços IPs associados a uma interface que possui o
protocolo LDP habilitado e também a família de endereços utilizada. Como parâmetro obrigatório temos o campo Address
list TLV.
Para remover um IP da lista, o LSR envia uma mensagem Address Withdraw indicando o endereço a ser retirado, conforme
captura abaixo.

LDP – Label Mapping Message
Cabeçalho TCP para
estabelecimento de sessão – Porta
646
Tipo de Mensagem: Label Mapping
Endereço IP/FEC
Valor do label em hexadecimal

(115 em decimal)
42
Uma mensagem Label Mapping é utilizada para divulgar um vínculo (bind) de um label com uma FEC. Como parâmetros
mandatórios há o FEC TLV e o Label TLV.
Para sinalizar que um vínculo entre um label e uma FEC foi desfeito, uma mensagem Label Withdraw é enviada contendo o
parâmetro mandatório FEC TLV. Como resposta a esta solicitação há a mensagem Label Release Message, sinalizando que
não necessita mais dos vínculos, como parâmetro mandatório há o FEC TLV e opcional o Label TLV.

LDP – Notificações
A última mensagem é chamada de Notification e visa
fornecer informações a respeito de:
1. Erros – Error Notification: O LSR ao receber a

notificação de erro encerra a sessão LDP fechando o
transporte TCP e descartando todos os mapeamentos
de labels aprendidos.
2. Consultivas – Advisory Notification: Utilizada para

transmitir informações do LSR a respeito da sessão
LDP ou do status de alguma mensagem recebida pelo
seu par.
43
A notificação tem o propósito de sinalizar um possível erro, trazer a informação de uma mensagem LDP ou o estado de
uma sessão. O seu formato é observado na captura abaixo.
Abaixo, o detalhamento de alguns campos.
• U Bit: Em mensagens de notificação tem valor zerado, em outros tipos de mensagens LDP possui o valor igual a um;
• Status: Apresenta o valor 0x0300 indicando o status TLV;
• Length: Informa o comprimento do status TLV;
• Status Code: É subdividido no E bit que é um valor que quando setado em 1 notifica erros fatais e zerado para
notificações de aviso. O F bit com valor 1, permite que o receptor reenvie a notificação para o next-hop, caso o seu
valor for igual a zero, a permissão é negada;
• Status Data: Especifica o tipo de notificação, como nos exemplos a seguir.
Status Code Types E Bit Status Data Codes
Sucess 0 0x00000000
Bad LDP Identifier 1 0x00000001
Bad Protocol Version 1 0x00000002
Unknown TLV 0 0x00000006

Hold Timer Expired 1 0x00000009
Shutdown 1 0x0000000A
Loop Detected 0 0x0000000B
Unknown FEC 0 0x0000000C
Session Rejected / No Hello 1 0x00000010

LDP – Notification Message
Mensagem de vínculo desfeito
Endereço IP local
Tipo de mensagem: Notification
Status da mensagem de
notificação
44
Quanto ao tipo de mensagens de notificação, temos:
1. Erros – Error Notification: O LSR ao receber esta informação de erro fatal encerra a sessão LDP fechando o
transporte TCP e descartando todos os mapeamentos de labels aprendidas.
• Identificador LDP desconhecido ou não associado ao receptor
• Versão do protocolo inválida
• Comprimento do PDU muito pequeno ou muito grande
• TLV desconhecido ou malformado
• Keepalive expirado
• Eventos na mensagem de inicialização, na parte de negociação dos parâmetros
2. Consultivas – Advisory Notification: Utilizada para transmitir informações do LSR a respeito da sessão LDP ou do
status de alguma mensagem recebida pelo seu par.
• Mensagens do protocolo

Estratégia de Distribuição de Labels
A distribuição de labels ocorre do sentido downstream para o upstream, ou seja, o LSR downstream informará o LSR
upstream qual label será utilizada.
FEC 4.4.4.4
Label 3
Label mapping
PE1 LSR1 LSR2/PHP PE2
Label Request
Label Mapping Domínio MPLS
FEC 4.4.4.4
Label 34
Existem dois modos de distribuição:
• Unsolicited (DU): Distribui proativamente um label para cada prefixo/FEC conhecido sem receber uma mensagem de
solicitação do LSR upstream. Aqui o LDP anuncia rótulos para todos os vizinhos;
• On Demand (DoD): Distribui um label para o prefixo/FEC somente após receber a solicitação do LSR upstream. 45
No método de distribuição não solicitada - Downstream Unsolicited (DU), o LSR-A envia para o LSR-B uma atribuição de
label para uma FEC, sem que o LSR-B tenha requisitado ou solicitado explicitamente, ou seja, o envio é realizado
ativamente com uma mensagem de label mapping.
Quando o modo Unsolicited é utilizado, o LDP distribui labels para todos os vizinhos por padrão. Cada LSR envia
mensagens de mapeamento para todos os seus vizinhos sem distinguir LSRs upstream e downstream. Se os LSRs
distribuírem rótulos apenas para vizinhos upstream, eles deverão identificar seus LSRs upstream e downstream com base
nas informações de roteamento antes do envio de mensagens de mapeamento de labels. Os LSRs upstream não podem
enviar mensagens de mapeamento para seus vizinhos downstream.
No modo de distribuição Downstream On Demand (DoD), o LSR-A envia para o LSR-B uma solicitação de atribuição de
label para uma determinada FEC, após o recebimento de uma requisição do LSR-B – Label Request Message. O upstream
solicita um label somente ao LSR adjacente pelo qual ele aprendeu o prefixo e somente um label será recebido pelo
Upstream LSR para este prefixo/FEC. Este modo de distribuição não está disponível para o sistema operacional DmOS.
O DmOS utiliza o modo Unsolicited, ou seja, o LSR posterior/downstream gera e atribui o label para o LSR
anterior/upstream, onde o LSR anuncia um label para cada prefixo/FEC conhecida para todos os LSRs adjacentes, sem que
tenha ocorrido uma solicitação. Este processo ocorre na mensagem de label mapping.
O método de distribuição de labels é escolhido durante a fase de inicialização de sessão no protocolo LDP.
Consulte regularmente o datasheet e o release notes das versões.

Estratégia de Alocação de Labels
O modo de alocação é utilizado pelo LSR durante o estabelecimento do LSP e existem dois modos:
Modo de Distribuição - Downstream Modo de Distribuição - Downstream On

Unsolicited (DU) Demand (DoD)
Modo de Alocação – O LSR upstream responsável pelo envio da mensagem

O LSR upstream atribuir um label a um prefixo/FEC
de requisição de label, atribuir um rótulo a um
Independet // sem receber a mensagem Label Mapping enviada
prefixo/FEC e a envia sem receber a mensagem Label
Independente pelo LSR downstream.
Mapping do LSR downstream.
O LSR upstream responsável pelo envio da mensagem

O LSR upstream atribui um label a um prefixo/FEC
Modo de Alocação – de requisição de label, atribui um label a um prefixo/FEC
apenas após o recebimento da mensagem de
Ordered // Ordenado apenas após o recebimento da mensagem de Label
Label Mapping do LSR downstream.
Mapping do LSR downstream.
46
No controle independente, o LSR pode atribuir um label a uma FEC sem a necessidade da mensagem de Label Mapping.
Um vínculo local é criado para uma FEC independente de outros LSRs, podendo inclusive, criar um vínculo para cada
prefixo que está em sua tabela de roteamento.
No modo ordenado, o LSR atribui um label a uma FEC somente após o recebimento da mensagem de mapeamento do
próximo salto ou se o LSR é o nó de saída da FEC.
Os sistema operacional DmOS não possui suporte para LDP Allocation mode Independent.

Estratégia de Retenção de Labels
A estratégia de retenção refere-se como o LSR se comportará ao receber mapeamentos de label que não são utilizadas
imediatamente ou quando houver alguma alteração na topologia da rede.
Definição Exemplo
FEC 4.4.4.4
Label 34
Retêm os mapeamentos de labels recebidos do seu vizinho,
Liberal Label
independente se o LSR é o próximo salto do LSR local.
Retention //
Apenas um populará a LFIB. Esta estratégia reestabelece
Liberal FEC 4.4.4.4
LSPs de forma mais rápida.
Label 28
FEC 4.4.4.4
Label 34
Retêm apenas o label enviado pelo melhor próximo salto (o
Conservative
caminho de melhor custo perante o roteamento), como
Label Retention
consequência o reestabelecimento de LSPs pode ser mais
// Conservadora FEC 4.4.4.4
lento e possibilita menor utilização da memória RAM.
Label 28
47
No modo de retenção liberal a associação é mantida visando atender a possibilidade de que um eventual LSR upstream se
torne o próximo salto, geralmente nas situações de alteração de topologia. O LSR mantém todos os vínculos recebidos na
sua LIB e populará apenas um label na LFIB. Permite a atualização rápida da LFIB. Ao receber uma mensagem Label
Mapping de um LSR vizinho, o LSR local retém o label independentemente do LSR vizinho ser seu próximo salto.
O modo conservador mantém apenas as associações de label e FEC recebidas de um LSR downstream quando este LSR é
o próximo salto para a FEC. O LSR mantém na LIB apenas o vínculo utilizado na LFIB. Ao receber uma mensagem de Label
Mapping de um LSR vizinho, o LSR local retém o label somente quando o LSR vizinho é seu próximo salto.
Os sistema operacional DmOS não possui suporte para LDP Retention mode Conservative.

Estabelecimento do LSP via LDP
A distribuição de labels ocorre do sentido downstream para o upstream e o fluxo de dados acontece do sentido upstream
para o downstream.
LSP
FEC 4.4.4.4 FEC 4.4.4.4 FEC 4.4.4.4 FEC 4.4.4.4

In/Out Action In/Out In/Out Action In/Out In/Out Action In/Out In/Out Action In/Out
Label Interf Label Interf Label Interf Label Interf
-/34 push -/G1 34/45 swap G1/G2 45/3 Pop G2/G3 -/- - G3/-
CE1- Site 1 PE1 LSR1 LSR2/PHP PE2 CE2 – Site 2
Lo 1.1.1.1 Lo 2.2.2.2 Lo 3.3.3.3 Lo 4.4.4.4

CE3 – Site 3
FEC 4.4.4.4 FEC 4.4.4.4 FEC 4.4.4.4

Label 34 Label 45 Label 3
Label mapping Label mapping Label mapping
48
Os labels são distribuídos do sentido downstream para o upstream.
O LSR identifica as FECs com base na tabela de roteamento e aloca um rótulo para cada entrada, na sequência registra o
mapeamento entre os labels e FECs. O LSR downstream encapsula este mapeamento em uma mensagem e a envia ao LSR
upstream. Conforme este processo progride em todos os LSRs do domínio MPLS, cada LSR cria a sua tabela de
encaminhamento de labels e estabelece um LSP.
Dentro do domínio MPLS não há consulta aos endereços IPs, apenas as LABELs direcionam o pacote a ser transmitido,
não há intervenção de outros protocolos. O controle das rotas IPs continua sendo realizado por protocolos de roteamento,
como por exemplo, OSPF.

Estabelecimento do LSP via LDP
Construção da tabela de roteamento
Através de um protocolo de roteamento, como o OSPF, a tabela de roteamento será populada com a melhor rota para um
determinado destino, essa operação ocorre em todos os equipamentos que estão no domínio MPLS.
PE2# show ip route ospf
LSR1# show ip route ospf
Type Dest Address/Mask Next-hop Age AD Metric Output Interface
------ ------------------- --------------- -------- --- ------ ----------------
O Loopback_PE1 10.23.24.0 01:52:47 30 2 l3-vlan 2324
------ ------------------- --------------- -------- --- ------ ----------------
O Loopabck_LSR1 10.23.24.0 01:52:47 30 3 l3-vlan 2324
O Loopback_LSR2 10.23.24.0 01:52:47 30 4 l3-vlan 2324
CE1- Site 1 PE1 LSR1/PHP LSR2/PHP PE2 CE2 – Site 2
CE3 – Site 3
PE1# show ip route ospf
Domínio MPLS
------ ------------------- --------------- -------- --- ------ ----------------
O Loopback_LSR1 10.21.22.1 01:52:47 30 2 l3-vlan 2122
LSR2# show ip route ospf

------ ------------------- --------------- -------- --- ------ ----------------
O Loopback_PE2 10.23.24.1 01:52:47 30 4 l3-vlan 2324 49

LIB – Label Information Base
Consiste em uma tabela gerada pelo protocolo de distribuição de labels, que contém todos os vínculos originados localmente
e os recebidos por um LSR com suas interfaces de entrada e saída, proporcionando o encaminhamento correto dos pacotes.
É consultada pela sintaxe show mpls ldp database.
LSR1
CE1 PE1 PE2 CE2
LSR2
PE1# LIB
PE2 → 77 A
PE2 → 57
50
O Label Information Base é gerado pelo protocolo de distribuição de labels, como o LDP e utilizada para gerenciar os
rótulos. O LDP utiliza as informações do roteamento IP para criar suas tabelas de labels, associando um rótulo de entrada
e um de saída a cada FEC extraída da tabela de rotas.
Um label é vinculado a cada prefixo IPv4 conhecido pelo LSR, que estes distribuem para todos os neighbors LDP através da
mensagem Label Mapping. Os neighbors armazenam os vínculos locais e remotos na Label Information Base (LIB), desde
que exista uma rota exata para a FEC.
O LSR seleciona apenas um único vínculo recebido dos LSR downstream. A tabela de roteamento determina qual é a
melhor rota e apresentará a informação de A (active).

LFIB – Label Forwarding Information Base
Tabela utilizada para encaminhamento de pacotes com labels, que contém instruções simples como push, swap e pop. O
resultado do mapeamento FTN e ILM é apresentado na LFIB e segue as recomendações da RFC 3031.
O label utilizado para encaminhamento está associado ao melhor caminho estabelecido pelo protocolo de roteamento. A sua
visualização ocorre pelo comando show mpls forwarding-table.
LSR1
CE1 PE1 PE2 CE2
LSR2
PE1# LFIB
PE2 → 77
51
O LFIB é uma tabela utilizada para encaminhar pacotes com rótulos, o qual contém os labels de entrada e saída dos LSPs.
Nesta tabela, teremos apenas uma saída possível para todas as possibilidades de caminhos até um determinado LSR. A
saída escolhida é a melhor rota definida pelo protocolo de roteamento.
O Label Forwarding Information Base é criado pelo protocolo de distribuição de labels em um LSR e utilizado para
encaminhar pacotes MPLS.

LIB x LFIB
DmOS# show mpls ldp database DmOS# show mpls forwarding-table
In In Out Out Out
State codes: A - active, NS - not selected Prefix or Tunnel-Name Action Label Proto Label Proto interface Status
----------------------------------------------------------------------------------------------
DownStream 22.22.22.22/32 fwd -- -- ImpNull ldp l3-vlan 2122 active
Network Prefix UpStream LSR-ID Label LSR-ID Label Stat 22.22.22.22/32 php 41 ldp ImpNull ldp l3-vlan 2122 active
e 23.23.23.23/32 psh -- -- 26 ldp l3-vlan 2135 active
-------------------------------------------------------------------------------- 23.23.23.23/32 swp 42 ldp 26 ldp l3-vlan 2135 active
21.21.21.21/32 22.22.22.22 3 -- -- A 24.24.24.24/32 psh -- -- 28 ldp l3-vlan 2135 active
21.21.21.21/32 35.35.35.35 3 -- -- A 24.24.24.24/32 swp 45 ldp 28 ldp l3-vlan 2135 active
22.22.22.22/32 22.22.22.22 41 -- -- A 35.35.35.35/32 fwd -- -- ImpNull ldp l3-vlan 2135 active
22.22.22.22/32 35.35.35.35 41 -- -- A 35.35.35.35/32 php 44 ldp ImpNull ldp l3-vlan 2135 active
23.23.23.23/32 22.22.22.22 42 -- -- A 70.70.70.70/32 psh -- -- 31 ldp l3-vlan 2135 active
23.23.23.23/32 35.35.35.35 42 -- -- A 70.70.70.70/32 swp 43 ldp 31 ldp l3-vlan 2135 active
24.24.24.24/32 22.22.22.22 45 -- -- A
24.24.24.24/32 35.35.35.35 45 -- -- A
35.35.35.35/32 22.22.22.22 44 -- -- A
35.35.35.35/32 35.35.35.35 44 -- -- A
70.70.70.70/32 22.22.22.22 43 -- -- A
70.70.70.70/32 35.35.35.35 43 -- -- A
21.21.21.21/32 -- -- 22.22.22.22 29 NS
21.21.21.21/32 -- -- 35.35.35.35 38 NS
22.22.22.22/32 -- -- 22.22.22.22 3 A
22.22.22.22/32 -- -- 35.35.35.35 29 NS
23.23.23.23/32 -- -- 22.22.22.22 53 NS
23.23.23.23/32 -- -- 35.35.35.35 26 A
24.24.24.24/32 -- -- 22.22.22.22 54 NS
24.24.24.24/32 -- -- 35.35.35.35 28 A
35.35.35.35/32 -- -- 35.35.35.35 3 A
70.70.70.70/32 -- -- 22.22.22.22 56 NS
70.70.70.70/32 -- -- 35.35.35.35 31 A
52

Laboratório 1 - LDP
Domínio MPLS DmOS-22 DmOS-23

Lo 22.22.22.22/32 LAG Lo 23.23.23.23/32
.1 .0 .1
.0
VLAN 2223 .0
VLAN 2370
.0
10.22.23.x/31 10.23.70.x/31
LAG VLAN 2122
10.21.22.x/31
DmOS-21 .1
Lo 21.21.21.21/32 .0
VLAN 2324 LAG
VLAN 2335
10.23.24.x/31
.0 10.23.35.x/31 OLT-70
.0
Lo 70.70.70.70/32
VLAN 2135
LAG 10.21.35.x/31
VLAN 2140 A1 OSPF
VLAN 3524 A0 OSPF
10.21.140.x/31 Normal 10.35.24.x/31
.1 .1
Backbone
.1 .1
.1 .0
LAG DmOS-24
DmOS-35
Lo 35.35.35.35/32 Lo 24.24.24.24/32
OLT-140
Lo 140.140.140.140/32
53

Ativando a Licença MPLS
Adicionar a licença MPLS ao equipamento – Necessário MAC e Serial Number
DmOS(config)#license mpls enabled key
(<string>):
Verificar a licença
DmOS#show running-config license
DmOS#show license
54
Para verificar a licença, utilize:
DmOS#show license
Feature Status
---------- ----------
mpls enabled
Caso a licença não esteja instalada no equipamento, solicite a aquisição via comercial.
Para obter as licenças informe o número de série e o endereço MAC do equipamento. Estas informações podem ser
obtidas no comando show inventory conforme abaixo:

Laboratório 2 – LDP e OSPF Multiáreas

Lo 22.22.22.22/32 LAG Lo 23.23.23.23/32
.1 .0 .1
.0
VLAN 2223 .0
VLAN 2370
.0
10.22.23.x/31 10.23.70.x/31
LAG VLAN 2122
10.21.22.x/31
DmOS-21 .1
Lo 21.21.21.21/32 .0
VLAN 2324 LAG
VLAN 2335
10.23.24.x/31
.0 10.23.35.x/31 OLT-70
.0
Lo 70.70.70.70/32
VLAN 2135
LAG 10.21.35.x/31
VLAN 2140 A1 OSPF
VLAN 3524 A0 OSPF
10.21.140.x/31 Normal 10.35.24.x/31
.1 .1
Backbone
.1 .1
.1 .0
LAG DmOS-24
DmOS-35
Lo 35.35.35.35/32 Lo 24.24.24.24/32
OLT-140
Lo 140.140.140.140/32
55

Laboratório 3 – Análise da Topologia

Lo 22.22.22.22/32 LAG Lo 23.23.23.23/32
.1 .0 .1
.0
VLAN 2223 .0
VLAN 2370
.0
10.22.23.x/31 10.23.70.x/31
LAG VLAN 2122
10.21.22.x/31
DmOS-21 .1
Lo 21.21.21.21/32 .0
VLAN 2324 LAG
VLAN 2335
10.23.24.x/31
.0 10.23.35.x/31 OLT-70
.0
Lo 70.70.70.70/32
VLAN 2135
LAG 10.21.35.x/31
VLAN 2140 A1 OSPF
VLAN 3524 A0 OSPF
10.21.140.x/31 Normal 10.35.24.x/31
.1 .1
Backbone
.1 .1
.1 .0
LAG DmOS-24
DmOS-35
Lo 35.35.35.35/32 Lo 24.24.24.24/32
OLT-140
Lo 140.140.140.140/32
56

LDP: Configurações
Associar a interface loopback ao LSR-ID
DmOS(config)#mpls ldp lsr-id <loopback-id>
Interface L3 participante do domínio MPLS - Mecanismo de descoberta do tipo Basic (Diretamente Conectada / Hello
linked)
DmOS(config-lsr-id-loopback-0)#interface l3-<name>
57
O protocolo LDP deve obrigatoriamente ser habilitado na interface de loopback que inclusive é a mesma utilizada pelo
roteamento dinâmico OSPF.
Abaixo, segue um exemplo de configuração:
DmOS(config)#mpls ldp lsr-id loopback-0

DmOS(config-lsr-id-loopback-0)#interface l3-Infra-OSPF-MPLS
Observação: Toda a infraestrutura do roteamento dinâmico deverá estar finalizada e testada para a aplicação do MPLS.
Subida de pacotes ARP para CPU com tráfego acima do valor de rate-limit pode afetar o estabelecimento de sessões LDP.

LDP: Verificação dos Parâmetros
DmOS#show mpls ldp parameters
LSR_ID: 21.21.21.21; Versão do protocolo

Protocol version: 1;
Allocation mode: Ordered;
Encapsulation mode: PHP implicit-null; Modo de alocação
Distribution mode: Unsolicited;
Retention mode: Liberal; Modo de encapsulamento
Local addresses:
21.21.21.21 Modo de distribuição
10.21.140.0
10.21.22.0
10.21.35.0 Modo de retenção
Endereços locais
58
DmOS#show mpls ldp parameters | tab

LOWER LOWER
LOOPBACK ALLOCATION LAYER LAYER
NAME LSR ID MODE L3 NAME IF TYPE IF ID L3 IP ADDR
----------------------------------------------------------------------------------------------
loopback-0 21.21.21.21 ordered l3-INFRA-OSPF-SW21_OLT140 l3-vlan 2140 10.21.140.0
l3-Infra-OSPF-MPLS-SW21-SW22 l3-vlan 2122 10.21.22.0
l3-Infra-OSPF-MPLS-SW21-SW35 l3-vlan 2135 10.21.35.0

LDP: Verificação dos Parâmetros
DmOS#show running-config mpls ldp | tab
mpls ldp
KEEP KEEP
INTERFACE ALIVE HELLO ALIVE HELLO
NAME INTERFACE NAME HOLDTIME HOLDTIME TARGETED HOLDTIME HOLDTIME PASSWORD
----------------------------------------------------------------------------------------------------
loopback-0 l3-INFRA-OSPF-SW21_OLT140 40 15
l3-Infra-OSPF-MPLS-SW21-SW22 40 15
l3-Infra-OSPF-MPLS-SW21-SW35 40 15
Loopback local
Interface L3 Temporizações
Associada ao MPLS LDP
59
Abaixo, segue o comando sem a utilização do recurso “| tab”
DmOS# show running-config mpls ldp

mpls ldp
lsr-id loopback-0
interface l3-INFRA-OSPF-SW21_OLT140
!
interface l3-Infra-OSPF-MPLS-SW21-SW22
!
interface l3-Infra-OSPF-MPLS-SW21-SW35
!
neighbor targeted 23.23.23.23
!
neighbor targeted 70.70.70.70
!
!
!

LDP: Verificação das Sessões Estabelecidas
DmOS#show mpls ldp neighbor brief
Neighbor LDP-ID State Nbr type

----------------- ------------- ---------------
22.22.22.22:0 Operational linked Neighbor diretamente conectado //
35.35.35.35:0 Operational linked mecanismo de descoberta basic
Status da sessão
Vizinhos LDP
60
show mpls ldp neighbor: Mostra as sessões LDP estabelecidas (TCP - porta 646). A informação de targeted será
apresentada para os vizinhos adicionados através da configuração neighbor targeted seguido do endereço IP da loopback
e os membros linked estarão disponíveis apenas os diretamente conectados.

LDP: Verificação das Sessões Estabelecidas
DmOS#show mpls ldp neighbor detail
Endereço IP da loopback do neighbor
Local LDP-ID: 21.21.21.21:0; Peer LDP-ID: 22.22.22.22:0; Equipamento passivo na comunicação
Last change: 29ds 05:28:55; State: operational; Role: passive; TCP
Max ldp pdu: 1440; Protocol version: 1;
Local configured KeepAlive (KA) hold time: 40s; Versão do protocolo LDP
Peer's advertised KA hold time: 40s;
Negotiated KeepAlive (KA) hold time: 40s; Temporizações
Negotiated time between KA messages: 7s;
KA hold time remaining for this session: 00:00:36s; Endereços IP remotos
Remote addresses:
10.21.22.1
22.22.22.22
10.22.23.0
Mecanismo de descoberta
Adjacency: 22.22.22.22:0; - Basic Discovery Mechanism
Adjacency discovery hello hold time: 15s;
Local discovery hello hold time: 15s;
Negotiated discovery hello hold time: 15s;
Remaining hello hold time: 14s;
Última alteração e status

61
Endereço IP da loopback local
Abaixo, segue o show mpls ldp neighbor do equipamento vizinho de endereço IP 22.22.22.22 para analise.
DmOS#show mpls ldp neighbor detail
Local LDP-ID: 22.22.22.22:0; Peer LDP-ID: 21.21.21.21:0;

Last change: 10ds 17:19:02; State: operational; Role: active;
Max ldp pdu: 1440; Protocol version: 1;
Local configured KeepAlive (KA) hold time: 40s;
Peer's advertised KA hold time: 40s;
Negotiated KeepAlive (KA) hold time: 40s;
Negotiated time between KA messages: 7s;
KA hold time remaining for this session: 00:00:39s;
Remote addresses:
10.21.22.0
10.21.140.0
21.21.21.21
10.21.35.0
Adjacency: 21.21.21.21:0; - Basic Discovery Mechanism

Adjacency discovery hello hold time: 15s;
Local discovery hello hold time: 15s;
Negotiated discovery hello hold time: 15s;
Remaining hello hold time: 12s;

MPLS: Verificação LFIB
DmOS#show mpls forwarding-table
In In Out Out Out
------------------------------------------------------------------------------------
23.23.23.23/32 swp 87 ldp 145 ldp l3-vlan 2122 active Status
Protocolo em Interface de saída

PE de destino que o label de (VLAN de Infra)
entrada foi
Ação
gerado Protocolo que o label
Label de de saída foi gerado
saída
Label de
62
entrada
show mpls forwarding-table: Mostra para todos os neighbors de destino as ações a serem executadas conforme a
orientação a seguir:
• SWP – Swap: troca de label;

• PHP – Penultime hop popping: penúltimo switch antes do PE, realiza a retirada do cabeçalho MPLS, através do
ImpNull, que é o label reservado de número 3;
• FWD – Forward: retirada de label / LSP originado com Implicit Null label;
• PSH – Push: inserção de labels.

MPLS: Verificação LIB
DmOS#show mpls ldp database
State codes: A - active, NS - not selected
DownStream
Network Prefix UpStream LSR-ID Label LSR-ID Label State
--------------------------------------------------------------------------------
21.21.21.21/32 22.22.22.22 3 -- -- A
21.21.21.21/32 35.35.35.35 3 -- -- A
22.22.22.22/32 22.22.22.22 17 -- -- A
22.22.22.22/32 35.35.35.35 17 -- -- A
23.23.23.23/32 35.35.35.35 87 -- -- A
24.24.24.24/32 22.22.22.22 90 -- -- A
35.35.35.35/32 22.22.22.22 89 -- -- A
70.70.70.70/32 35.35.35.35 88 -- -- A
21.21.21.21/32 -- -- 22.22.22.22 112 NS
22.22.22.22/32 -- -- 22.22.22.22 3 A
22.22.22.22/32 -- -- 35.35.35.35 26 NS
23.23.23.23/32 -- -- 22.22.22.22 145 A
23.23.23.23/32 -- -- 35.35.35.35 25 NS
24.24.24.24/32 -- -- 22.22.22.22 146 NS
24.24.24.24/32 -- -- 35.35.35.35 24 A
35.35.35.35/32 -- -- 22.22.22.22 155 NS
35.35.35.35/32 -- -- 35.35.35.35 3 A
70.70.70.70/32 -- -- 22.22.22.22 148 A 63
70.70.70.70/32 -- -- 35.35.35.35 27 NS
show mpls ldp database: Mostra todas as FECs e os seus respectivos labels, os quais foram gerados pelo LSR downstream
e enviado ao LSR upstream através da mensagem Label Mapping.
A sinalização de NS, traz a segunda opção de caminho, porém não selecionada.
Na tabela apresentada acima, há duas informações importantes para a leitura dos labels:
• Upstream: Label gerada pelo LSR e distribuída para o LSR upstream. É o label que é “ensinada”;
• Downstream: Label aprendida através da mensagem de Label Mapping do LSR downstream;
É possível filtrar o comando show mpls ldp database para mostrar apenas as rotas com status ativo “A”.
DmOS#show mpls ldp database | select state A

DownStream
----------------------------------------------------------------------------
21.21.21.21/32 22.22.22.22 3 -- -- A
21.21.21.21/32 24.24.24.24 3 -- -- A
22.22.22.22/32 24.24.24.24 17 -- -- A
23.23.23.23/32 22.22.22.22 18 -- -- A
24.24.24.24/32 22.22.22.22 16 -- -- A
22.22.22.22/32 -- -- 22.22.22.22 3 A
23.23.23.23/32 -- -- 24.24.24.24 21 A
24.24.24.24/32 -- -- 24.24.24.24 3 A

MPLS: LIB x LFIB
Database (LIB) x Forwarding-table (LFIB)
DmOS#show mpls ldp database

DownStream
--------------------------------------------------------------------------------
...
23.23.23.23/32 35.35.35.35 87 -- -- A
24.24.24.24/32 22.22.22.22 90 -- -- A
...
24.24.24.24/32 -- -- 22.22.22.22 146 NS
24.24.24.24/32 -- -- 35.35.35.35 24 A
...

In In Out Out Out
----------------------------------------------------------------------------------------------
24.24.24.24/32 swp 90 ldp 24 ldp l3-vlan 2135 active 64
...

LOGs e Debugs
DmOS#show log | include LDP
In In Out Out Out
2022-09-01 18:04:05.546 : 1-1 : <Info> %ROUTER-LDP_ADJACENCY_STATE : Router[5177] : LDP adjacency
change - Neighbor 22.22.22.22:0, Session DOWN (shutdown)
change - Neighbor 22.22.22.22:0, Session UP

change - Neighbor 70.70.70.70:0, Session DOWN (hello hold timer expired)

change - Neighbor 22.22.22.22:0, Session DOWN (keepalive timer expired)
DmOS#debug enable proto-mpls
2022-09-01 18:04:05.545663 [proto-mpls] : LDP adjacency change - Neighbor 22.22.22.22:0, Session DOWN
(shutdown)
2022-09-01 18:04:44.863672 [proto-mpls] : LDP adjacency change - Neighbor 22.22.22.22:0, Session UP
65

Análise de Falhas
show running-config interface l3
show ip interface brief show running-config interface loopback
show interface link show running-config dot1q show ip host-table show ip interface brief
Interface Física Dot1q/VLAN Interface L3 Loopback
LIB IP Routing Table – RIB

OSPF
Label Information Base Routing Information Base
show mpls ldp database show ip route show ip ospf

Show mpls ldp neighbor brief show ip route destination a.b.c.d/x show ip ospf neighbor
show ip rib
FIB
LFIB Forwarding Information Base
Label Forwarding Information
Base show ip fib brief
show ip host-table brief
show mpls forwarding-table
show mpls forwarding-table prefix-or-tnl-name a.b.c.d/x
show mpls forwarding-table status <active | pending> 66
RIB – Routing Information Base: Consiste em uma tabela com as informações recebidas através dos protocolos de
roteamento, que será a base para o cálculo da definição do melhor caminho.
LIB – Label Information Base: Consiste em uma tabela que contém a correlação dos labels locais que um LSR recebe do
protocolo LDP e suas interfaces de entrada e saída, proporcionando o encaminhamento correto dos pacotes.
FIB – Forwarding Information Base: Permite que o dispositivo controle a decisão de encaminhamento através das
informações contidas na FIB, desta forma, ao localizar um endereço IP saberá para qual interface encaminhar. É o estado
atual da topologia. Um PE ao receber um pacote para um determinado destino, fará a consulta na FIB para que possa
receber a instrução de encaminhamento.
LFIB – Label Forwarding Information Base: A LFIB é consultada na situação onde o pacote já ingressa com um label
associado, a qual contém instruções mais simples, como swap, pushing ou poping de um label. O resultado do processo de
mapeamento da LFIB é denominado ILM, conforme a RFC 3031.

Por que Engenharia de Tráfego?
Uma das características dos protocolos de roteamento é a de encaminharem o tráfego através de caminhos com o melhor
custo, o que ocasiona um tráfego ou utilização maior destes links, deixando outros ociosos.
Utilizando um IGP - Interior Gateway Protocol como o OSPF, o caminho escolhido entre dois pontos sempre será o caminho
com o menor custo.
Mesmo que o caminho 1 esteja saturado, ele será utilizado para todo o tráfego entre R1 e R5, e o caminho 2 ficará subutilizado.
67
Os dispositivos que operam com protocolos de roteamento interno - IGP, sempre encaminham o tráfego através de
caminhos com melhor custo ou de menor métrica, porém, nem sempre a rota de menor custo é a única opção disponível
entre uma origem e um destino ou a que possui recursos suficientes para suportar a carga de tráfego.
Caso sejam alterados os custos dos links, o problema simplesmente muda de lugar e não é resolvido. O roteamento
baseia-se no endereço IP ou Rede de destino e não promove mecanismos de balanceamento de carga por caminhos
redundantes. Essas limitações estão atreladas a própria característica do protocolo.
A infraestrutura MPLS construída apenas com LDP, que é um protocolo específico e responsável pela distribuição de
labels definido pelo IETF na RFC 5036, tem como característica utilizar o melhor caminho definido no protocolo de camada
3, consequentemente, também não explorando todo o potencial dos links disponíveis.
Desta forma, não há como acomodar de forma planejada ou justa toda a carga do tráfego desejada, causando
congestionamento, o que impacta diretamente na qualidade dos serviços ofertados ao cliente.
O uso da engenharia de tráfego visa prover flexibilidade na construção de caminhos, evitando possíveis
congestionamentos causados pela alocação desigual de recursos.

Por que Engenharia de Tráfego?
A ideia da engenharia de tráfego em redes MPLS é a de buscar o uso mais eficiente dos recursos presentes na infraestrutura
do provedor ou da operadora, como equipamentos já instalados, a redução da ociosidade de links próprios ou contratados e
do melhor balanceamento da carga do tráfego entre as diversas velocidades das interfaces/transceivers, sem a necessidade de
atualização do hardware, consequentemente, reduzindo os custos de implantação.
68
Alguns dos objetivos da engenharia de tráfego são o de facilitar e tornar confiável a operação de rede e simultaneamente
otimizar a utilização dos recursos para um melhor desempenho do tráfego. O foco da engenharia de tráfego é a longo
prazo e não na resolução de problemas momentâneos.
Um eficiente gerenciamento dos recursos físicos no que tange a largura de banda é crucial para minimizar
congestionamentos constantes, que se manifestam por dispositivos de rede insuficientes ou inadequados e por fluxos de
tráfego mapeados de forma incorreta. Quando o congestionamento é minimizado, a perda de pacotes diminui, bem como
o atraso/delay, trazendo ao cliente final uma maior percepção de qualidade de serviços.
Consulte a RFC2702 para observar os requisitos para engenharia de tráfego sobre MPLS.

Implementação do MPLS-TE
O MPLS-TE é implementado em 4 etapas:
1. Anúncio de informações baseado no IGP para a coleta de informações de engenharia de tráfego;
2. Cálculo do caminho com base nas informações coletadas, que atendam as restrições ou atributos estabelecidos;
3. Configuração do caminho realizada através da troca de mensagens de sinalização entre os pontos de entrada - head end e
saída - tail end;
4. Encapsulamento e encaminhamento do tráfego em um túnel MPLS-TE estabelecido.
69
Referente as etapas, temos:
1. Anúncio: O IGP, como por exemplo, o OSPF anuncia informações de engenharia de tráfego, que incluem largura de
banda máxima do link, largura de banda máxima reservável e reservada e os atributos do link. Cada equipamento
coleta as informações sobre todos os links em uma área e gera um banco de dados de engenharia de tráfego – TEDB;
2. Cálculo do caminho: Utiliza o algoritmo CSPF – Constraint Shortest First e os dados de TEDB para calcular um
caminho que atenda as restrições configuradas;
3. Configuração do caminho: Utiliza-se o protocolo RSVP-TE para configurar os túneis. As mensagens do protocolo
trazem informações como largura de banda, caminho explicito e atributos de afinidade;
4. Encaminhamento: Direciona e encaminha o tráfego para um túnel MPLS-TE.
No MPLS-TE as FECs são compostas por outros elementos, representados pelos diferentes atributos de classe de tráfego,
diferentemente do visto pelo método LDP.

OSPF–TE
Para a operação correta do MPLS-TE é necessário que o IGP
- Interior Gateway Protocol seja capaz de enviar o estado do
link aos demais dispositivos presentes na área em que o TE
for habilitado.
Age Options Type = 10
Opaque Type = 1 Opaque ID
A RFC 3630 especifica a adição de extensões ao protocolo
Advertising Router
OSPF para a operação e a RFC 2370 define as melhorias do
protocolo OSPF para suportar uma nova classe de estado Sequence Number
de link, o LSA – Link-State Advertisements chamado de Checksum Length
opaque. Opaque Information
Para o MPLS-TE é utilizado em específico o LSA type 10

opaque, que abrange a sua atuação a uma área OSPF.
70
O MPLS-TE utiliza extensões do protocolo de roteamento IGP do tipo Link State, como por exemplo o OSPF, para anunciar
informações a respeito do estado dos links, como a largura de banda máxima, a banda reservada e a disponível, além dos
atributos do link, de forma que seja possível construir um database para a determinação dos caminhos.
Este tipo de LSA é chamado de opaque e enviado pelas interfaces dos LSRs para todos os seus vizinhos por meio de
flooding ou inundação, compartilhando informações de forma que seja interoperável e com três escopos:
1. LSA opaque type 9 – Enlace/link/subrede;

2. LSA opaque type 10 – Área;
3. LSA opaque type 11 – Um sistema autônomo e não são permitidas em áreas do tipo STUB e NSSA.
A RFC 3630 engloba apenas o LSA type 10, restringindo a aplicação para uma área OSPF.
O OSPF-TE gera e anuncia o LSA do tipo opaque contendo informações a respeito do link MPLS-TE para a área local. Os
demais equipamentos pertencentes a essa mesma área devem suportar as extensões TE e necessitam anunciar as
informações de recursos, gerando assim um bando de dados chamado de TEDB, que é independente do banco de dados
de estado do link (LSDB).
Cada LSR, além de enviar os seus LSAs, repassa adiante os LSAs recebidos dos seus vizinhos, resultando no recebimento
de todos os LSAs emitidos na área pertencente a utilização da engenharia de tráfego. Com base nessas informações, o
head end as compara aos atributos para obter os caminhos que satisfazem a cada restrição e os LSRs devem originar TE
LSAs sempre que ocorrerem alterações de estado na rede.
O OSPF-TE ao contrário do tradicional, centraliza as informações em uma base de dados localizada no PE de entrada -
head end LSR, a qual conterá todos os dados referentes a engenharia de tráfego e a partir dele que são selecionados os
caminhos a serem percorridos.
Os dois bancos de dados, o TE e o tradicional, são gerados por inundações, mas registram informações diferentes e
exercem funções distintas. O TEDB armazena informações do TE e é utilizado para o cálculo do melhor LSP para um túnel
MPLS-TE e o LSDB é utilizado para calcular o melhor caminho.
Ao enviar pacotes Link State Update, um vizinho não opaco pode (inadvertidamente) receber esses LSAs, os quais serão
descartados.

OSPF–TE
Tipo do LSA
Indica traffic engineering LSA
Endereço IP do dispositivo que

enviou o LSA
Tipo de
mensagem TLV
Características e atributos do link,

de acordo com o tipo de mensagem
TLV
71
Dentro do LSA tipo 10 há o campo Link State ID Opaque Type, exclusivo para o uso com TE e identificado pelo valor 1
(um), o qual descreve dispositivos e tipo de links (ponto-a-ponto ou multiaccess) de forma similar ao LSA type 1 – Router
LSA no OSPF tradicional.
Em Opaque Information visualizamos o conteúdo anunciado no LSA, em formato TLV – tipo, comprimento e valor. Na
mensagem TLV do tipo 2, encontramos:
• Link Type: Tipo de link. O valor 1 identifica link ponto-a-ponto e o valor 2 um link multiacesso;
• Link ID: Para links ponto-a-ponto indica o Router-ID do dispositivo vizinho e em links multiacesso sinaliza o endereço
IP do equipamento DR;
• Local Interface IP Address: Endereço IP da interface local;
• Remote Interface IP Address: Endereço IP da interface vizinha. Se link ponto-a-ponto é o endereço IP e para
multiacesso será apresentado 0.0.0.0;
• Traffic Engineering Metric: Especifica a métrica utilizada em um link com TE;
• Maximum Bandwidth: Largura de banda máxima de um link, medida em bytes por segundo;
• Maximum Reservable Bandwidth: Largura de banda máxima que pode ser reservada de um link no sentido desejado;
• Unreserved Bandwidth: Especifica a quantidade de largura de banda ainda não reservada ou disponível, separada em
8 classes de serviço;
• Resource Class/Color: Atributo do link.

Cálculo do Caminho no MPLS-TE
O MPLS-TE utiliza o algoritmo CSPF – Constrained Shortest Path First para o cálculo do melhor caminho, que leva em
consideração:
• Restrições para configuração de LSP: largura de banda, caminho explícito, prioridade de configuração e atributos de
afinidade
• Explícitos: Configurados ou declarados manualmente por quais LSRs o LSP deve ser estabelecido, realizando o seu controle com
precisão;
• Afinidade: Permite inserir atributos ou características que serão analisadas para o estabelecimento do LSP.
• Banco de dados de engenharia de tráfego – TEDB.
Diferentemente do LDP, que utiliza o melhor caminho escolhido pelo roteamento para alcançar o destino, no MPLS-TE o
caminho dos túneis é configurado pelo administrador da rede.
72
Para selecionar o caminho mais curto até um determinado destino, o CSPF primeiramente exclui todos os links cujos
atributos não atendam às restrições de configuração do LSP no banco de dados de engenharia de tráfego (TEDB), para na
sequência calcular as métricas usando o algoritmo SPF. O resultado desta operação é concentrado no head end LSR, os
quais são capazes de definir os caminhos explícitos e os selecionarem por ordem de preferência para na sequência,
acionar o RSVP-TE para constituir os túneis desejados.
O banco de dados de engenharia de tráfego – TEDB só é gerado quando o OPSF-TE está configurado.
O CSPF é específico para o cálculo do caminho MPLS TE e difere do SPF nos seguintes aspectos:
• Calcula apenas o caminho mais curto de um head end para um tail end, enquanto o SPF calcula o caminho mais curto
de um nó para todos os outros nós em uma rede;
• Utiliza restrições de caminho, como largura de banda de link, atributos de link e de afinidade como métricas, enquanto
o SPF utiliza o custo do link como métrica;
• Não oferece suporte ao balanceamento de carga e utiliza políticas de desempate para determinar um caminho em
caso de empate ou mesma métrica.
O encaminhamento do tráfego é realizado pelos labels adicionados aos pacotes nos equipamentos que comportam-se
como PEs da topologia e são estabelecidos com base em critérios, de acordo com a estratégia de cada ISP ou operadora.

RSVP-TE: Resource reSerVation Protocol Traffic Engineering
O RSVP com a extensão TE - Traffic Engineering é definido através da RFC 3209, onde incorpora ao protocolo a permissão para
o estabelecimento de LSPs em MPLS com base em restrições.
O caminho a ser estabelecido para um túnel TE é unidirecional.
O PE de entrada é chamado de Head End LSR e realiza todos os cálculos para a definição do melhor caminho e o PE de saída é
conhecido por Tail End LSR.
Head End LSR Transit LSR Transit LSR Tail End LSR
Domínio MPLS
73
Resource reSerVation Protocol Traffic Engineering ou RSVP-TE é uma extensão do RSVP utilizada para criar um LSP
baseado em restrições, como largura de banda, caminho explícito, prioridade de configuração e atributos de afinidade.
As extensões presentes no RSVP possuem o propósito de apoiar a implementação do MPLS-TE, nos quesitos de:
• Adiciona o Label Request na mensagem de Path para solicitar os rótulos/labels;

• Adiciona o Label na mensagem de RESV para alocar do rótulo/label;
• Uma mensagem RSVP estendida pode conter restrições de caminho e informações de vinculação de labels;
• Os objetos estendidos carregam restrições de largura de banda, com o propósito de implementar a reserva de
recursos, se assim for necessário.
O RSVP não é um protocolo de roteamento e as reservas são sempre unidirecionais.

Requisição de Labels
O processo de requisição de labels, inicia no Head End e segue pelo caminho até alcançar o Tail End, através de mensagens
RSVP path. No caminho inverso, o Tail End envia uma mensagem de RSVP resv contendo as informações.
RSVP Path RSVP Path RSVP Path

Head End LSR Tail End LSR
RSVP Resv RSVP Resv RSVP Resv

Label 33 Label 16 Implicit Null
Domínio MPLS
O RSVP define uma “sessão” como um fluxo de dados com um destino e protocolo e a trata de maneira independente.
74
O protocolo RSVP-TE utiliza a distribuição de labels pelo modo Downstream on Demand com controle ordenado.
A requisição de labels é originada pelo head end através de uma mensagem Path para o tail end, contendo os campos
label request, explicit route e record route. Como resposta, é enviado pelo tail end a mensagem Resv com os campos label e
record route preenchidos. Após essa troca de mensagens é estabelecida uma sessão RSVP.
As mensagens Refresh carregam informações que já foram anunciadas de forma a manter o sincronismo do estado e
também é utilizada para detectar e manter a vizinhança RSVP.
Quanto aos tipos de mensagens temos:
• Path: Solicitação de reserva;

• Resv (reservation request): Resposta à mensagem Path e para solicitar reserva de recursos;
• PathErr: Erro de caminho ou caminho ambíguo;
• ResvErr: Solicitante não tem permissão para fazer reserva, banda indisponível, serviço não suportado e má formação
de fluxo. Aviso de erro a ser reportado para o head end, outro exemplo é o unacceptable label;
• PathTear: Exclui as informações de caminho;
• ResvTear: Retira o estado de reserva do recurso;
• ResvConf (reservation confirmation): Confirma uma solicitação de reserva de recurso hop-a-hop. Esta mensagem é
enviada somente quando a mensagem Resv contém o objeto RESV_CONFIRM;
• Resv Patherr: Informação que não há labels disponíveis para alocação;
• Srefresh: Atualiza o estado de RSVP.

Requisição de Labels: Mensagem Path
Versão do RSVP
Suporte a
mensagem Srfresh
Tipo de mensagem
Informações de
sessão RSVP
Endereço IP da
interface de saída que
enviou a mensagem
Intervalo de atualização
Endereço pelo qual o LSP é
encaminhado ou recebido
no LSR remoto
Requisição de label
Lista de endereços IPs que Endereço do head end

o LSP é encaminhado e o ID do túnel MPLS 75
O RSVP-TE utiliza as mensagens de Path para criar sessões de RSVP e manter estados de caminho. Detalhando alguns
campos temos:
• Session: Contém as informações da sessão RSVP, como o endereço IP do destino e ID do túnel;

• HOP: Contém o endereço IP do nó RSVP que enviou a mensagem;
• Time Values: Valores de refresh, utilizada nas mensagens path e resv;
• Explicit Route: Especifica o caminho pelo qual um LSP é encaminhado ou constituído, inclusive se é do tipo strict ou
loose:
• Label Request: Requisição do label, utilizado apenas em mensagens Path;

• Session Attribute: Especifica a prioridade de configuração e retenção, estilo da reserva, afinidade e outros atributos;
• Sender Template: Contém o endereço do remetente IP/head end e o ID do túnel MPLS;
• Sender TSPEC: Define as características do fluxo de dados do remetente;
• ADSPEC: Coleta parâmetros de QoS de um caminho, como largura de banda, atraso e MTU;
• Record Route: Lista os endereços IPs por onde o LSP é encaminhado.
Cada dispositivo remetente envia de forma periódica uma mensagem de Path para cada fluxo de dados que origina.
Quando ocorre um erro ou o head end decide remover a reserva da sessão, o RSVP utiliza a mensagem Path Tear, abaixo,
segue um exemplo, sinalizando a exclusão das informações do caminho do túnel ID 1.
O tail end ao receber a mensagem, responde com um Resv Tear, notificando todos os LSR da remoção.

Requisição de Labels: Mensagem Resv
Versão do RSVP
Suporte a menagem
Srfresh
Tipo de mensagem
Informações de
sessão RSVP
Endereço IP da
interface de saída que
enviou a mensagem
Intervalo de atualização
Estilo de reserva de
recurso
Endereço do remetente
IP e o ID do LSP
Label atribuído
76
Após receber a mensagem Path, o tail end retorna com uma mensagem Resv, que carrega informações de reserva de
recursos e é enviada salto a salto até o head end. Cada equipamento intermediário cria e mantém um bloco de estado de
reserva e aloca um rótulo. Quando a mensagem Resv atinge o nó de ingresso, um LSP é configurado com sucesso.
As mensagens de Resv possuem os pedidos de reserva salto-a-salto.
Detalhando alguns campos temos:
• Session: Contém o endereço IP do destino e ID do túnel;

• HOP: Contém o endereço IP do nó RSVP que enviou a mensagem;
• Time Values: Valores de refresh, utilizada nas mensagens path e resv;
• Style: Estilo de reserva de recurso. O tipo fixo realiza uma reserva exclusiva para cada remetente e não compartilha
com os demais, já o tipo shared explicit cria uma reserva única para uma série de remetentes upstream selecionados;
• Flowspec: Características de QoS de um fluxo de dados;
• Filterspec: Endereço IP do remetente e o ID do túnel;
• Label: Desempenha a mesma função da mensagem Label Mapping do protocolo LDP, distribuindo os labels aos LSRs
que compões o túnel MPLS-TE;
• Record Route: Lista de endereços que compõe o caminho/LSP com os respectivos labels.
Um LSR só deve aceitar um label caso tenha sido solicitado.

Requisição de Labels: Mensagem Path Error
Endereço de destino e
ID do túnel
Mensagem de erro
Endereço IP que
detectou o
problema/erro
Tipo de erro
ocorrido
Endereço IP de origem
e ID do túnel
77
A captura acima foi identificada após o link principal no tail end ficar fora de operação (down).

Interface Túnel
A interface túnel é uma interface lógica ou virtual ponto-a-ponto, utilizada para encapsular os pacotes que serão
transportados via engenharia de tráfego.
Outros pontos envolvidos na sua construção são:
• ID do túnel: Identificador exclusivo de um túnel, expresso em um valor decimal;

• ID do LSP: Valor expresso em decimal que identifica exclusivamente um LSP.
LSP
Head End Tail End
Interface túnel – ID X
Domínio MPLS
78
Um túnel pode possuir mais de uma opção de caminho, como por exemplo, o principal e o de backup. Se nenhuma das
alternativas possuir os recursos desejados, o túnel não será constituído.
O ID do túnel é um campo com 32 bits e tem significado apenas local.
Um túnel TE possuirá atributos como:
• Endereço IP de destino, por exemplo a loopback;

• Critérios de afinidade ou explícitos;
• Prioridades entre os caminhos a serem utilizados.

Critérios para Estabelecimento de Túneis: Explicit Path
Como o próprio nome indica Explicit-Path é a definição de caminhos de forma explícita do Head End LSR até o Tail End LSR.
Strict Routes: Consiste na declaração ordenada de todo o caminho a ser percorrido, salto-a-salto. O túnel obedecerá fiel e
rigorosamente o caminho determinado e não o indicado pelo roteamento.
DmOS-2
10.1.2.2
10.2.4.2
DmOS-1 DmOS-3 DmOS-5
DmOS-4
79
Como os túneis são unidirecionais será necessário configurá-lo nos dois sentidos, tanto do equipamento DmOS-1 para o 5,
como do DmOS-5 para o 1.
Caso não seja especificado o tipo, por padrão será assumido que o hop é strict.
O DmOS permite combinar hops loose e strict no mesmo path.

Critérios para Estabelecimento de Túneis: Explicit Path
Loose Routes: Não é necessário determinar todos os saltos entre o Head End LSR e o Tail End LSR, mas sim, endereços IPs
intermediários como pontos obrigatórios e estratégicos para a formação do LSP. Os equipamentos não precisam estar
conectados diretamente. A escolha do caminho, será uma combinação entre a tabela de roteamento e o endereço IP
informado.
DmOS-2
DmOS-1 DmOS-3 DmOS-5
DmOS-4
80
Em uma loose route o encaminhamento do tráfego obedece ao roteamento IGP, por exemplo o OSPF.
Como os túneis são unidirecionais será necessário configurá-lo nos dois sentidos, tanto do equipamento DmOS-1 para o 5,
como do DmOS-5 para o 1.
Caso não seja especificado o tipo, por padrão será assumido que o hop é strict.
O DmOS permite combinar hops loose e strict no mesmo path.

Laboratório 4 – RSVP e Túnel Explicit Path Strict

Lo 22.22.22.22/32 LAG Lo 23.23.23.23/32
.1 .0 .1
VLAN 2223 .0 .0
10.22.23.x/31
LAG VLAN 2122
10.21.22.x/31
DmOS-21
Lo 21.21.21.21/32 .0
VLAN 2324 LAG
VLAN 2335
10.23.24.x/31
.0 10.23.35.x/31
VLAN 2135
LAG 10.21.35.x/31
VLAN 3524 A0 OSPF
.1 10.35.24.x/31 .1
Backbone
.1
.1 .0
LAG DmOS-24
DmOS-35
Lo 35.35.35.35/32 Lo 24.24.24.24/32
81

Laboratório 4 – RSVP e Túnel Explicit Path Strict
DmOS-22 DmOS-23
Lo 22.22.22.22/32 Lo 23.23.23.23/32
.1 .0 .1
1
.0
VLAN 2223
1 VLAN 2122 10.22.23.x/31
10.21.22.x/31
DmOS-21
Lo 21.21.21.21/32 .0
VLAN 2324
10.23.24.x/31
2
.0
VLAN 2135
10.21.35.x/31
2 VLAN 3524
10.35.24.x/31
.1
.1
.1
2 .0
DmOS-35 DmOS-24
Lo 35.35.35.35/32 Lo 24.24.24.24/32
1 Caminho principal
2 Caminho secundário/backup
82
A respeito da criação do túnel com o critério explicit path do tipo strict, teremos as premissas:
1. Um túnel MPLS-TE deverá ser criado no DmOS-21 com destino ao DmOS-23, sendo que o caminho principal será o
sinalizado em verde e o secundário em vermelho, que atuará em caso de falhas;
2. O DmOS-23 também deverá ser configurado;
3. Como o critério é do tipo strict, você deverá ter em mãos todos os endereços ou a lista de IPs das interfaces dos LSRs
por onde o túnel será estabelecido;
4. Simularemos uma falha em um ponto do caminho principal, para que seja possível visualizarmos a atuação do
caminho secundário.

OSPF-TE e RSVP-TE: Configurações
Habilitar o LSA do tipo Opaque no OSPF
DmOS(config)#router ospf <1-65535>
DmOS(config-ospf-21-vrf-global)#mpls-te router-id loopback-<0-7>
'router ospf 21 global': Enabling mpls-te will cause OSPF process to be restarted Proceed? [yes,no]
Associar as interfaces L3 ao RSVP

DmOS(config)#mpls rsvp
DmOS(config-rsvp)#interface l3-<name>
Verificar as configurações
DmOS#show running-config router ospf mpls-te | tab
DmOS#show running-config mpls rsvp
DmOS#show ip ospf database opaque-area
83
As informações dos atributos de cada link são divulgadas através do OSPF. O protocolo RSVP define um caminho e sinaliza
o túnel com base nas informações do OSPF.
Somente são suportados túneis na mesma área do OSPF (intra-area).
Os recursos de Fast Reroute (FRR) e reserva de banda não são suportados.
Túneis podem não subir caso o equipamento tenha mais de uma área configurada. Para resolver é necessário remover as
áreas excedentes e reiniciar o processo do OSPF utilizando o comando clear ospf process <process_id>.
Consulte regularmente o release notes.
Configuração do MTU nas interface l3 ip-mtu não reflete no protocolo RSVP, será considerado o valor de 1500 bytes.

OSPF-TE e RSVP-TE: Verificação
DmOS# show running-config router ospf mpls-te | tab
PROCESS
ID VRF ROUTER ID
-----------------------------
21 global loopback-0
VRF associada
ID da loopback
Processo OSPF
DmOS# show running-config mpls rsvp | tab

mpls rsvp
INTERFACE NAME
------------------------------
l3-Infra-OSPF-MPLS-SW21-SW22 Interfaces
l3-Infra-OSPF-MPLS-SW21-SW35 associadas ao RSVP
84

LSA Type 10 Opaque: Verificação
Router ID e
DmOS# show ip ospf database opaque-area
processo OSPF
OSPF Router with ID (10.21.21.21) Process ID (21)
Área com MPLS-TE habilitada
Area 0.0.0.0;
Link type Link ID ADV router Age (secs) Sequence Checksum
--------- ------- ---------- ---------- -------- --------
10 - area opq 1.0.0.1 21.21.21.21 1503 0x800002A3 0x000017EA
10 - area opq 1.0.0.1 22.22.22.22 1110 0x800000D1 0x0000C409
10 - area opq 1.0.0.1 23.23.23.23 1070 0x800000D1 0x0000C8FC
10 - area opq 1.0.0.1 24.24.24.24 1047 0x800000D1 0x0000CCF0
10 - area opq 1.0.0.1 35.35.35.35 912 0x8000008A 0x00008725
10 - area opq 1.0.0.2 22.22.22.22 321 0x8000008B 0x0000AB10
...
Número de sequência do
Router ID do equipamento que LSA, quanto maior o
Tipo do LSA originou o LSA número, mais recente
Tempo em segundos desde

Tipo do LSA opaque que o LSA foi gerado
1 = Descreve links ponto-a-ponto
2 = Descreve características dos enlaces
85

LSA Type 10 Opaque: Verificação
Router ID que
DmOS# show ip ospf database opaque-area detail anunciou o LSA
Link state ID: 1.0.0.2; Advertising router: 23.23.23.23;
Age: 943 secs; Sequence number: 0x8000065B; Checksum: 0x0000807A
Advertisement length: 144 (first 58 chars displayed) Idade do LSA, sequência e checksum
Advertisement: 0x024f020a01000002171717178000065b807a0090000200780001000101
Options: E
Opaque type: Traffic Engineering LSA; Opaque ID: 2 LSA opaque do tipo link
Opaque Information length: 124 (first 50 chars displayed)
Opaque Information:
Informações de estado de
Link Information:
Link Type: Point-To-Point (0x1) link de um determinado
Link ID: 24.24.24.24 enlace, informadas pelo
Local Interface IP Address List: Advertising Router acima
Local Interface Address: 10.23.24.0
Remote Interface IP Address List:
Remote Interface Address: 10.23.24.1
Traffic Engineering Metric: 1
Características de banda
Maximum Bandwidth: 4294967040 (bytes/sec) do enlace
Maximum Reservable Bandwidth: 4294967040 (bytes/sec)
Unreserved Bandwidth:
Pri (or TE-Class) 0: 4294967040 (bytes/sec) Valor de affinity bit
...
Pri (or TE-Class) 7: 4294967040 (bytes/sec)
Affinity: 0x00000008 Identificação do
Link Local Identifier: 201328916 (0x0c000914) (l3-vlan 2324)
link/enlace
Link Remote Identifier: 0 (0x00000000) (l3-vlan 2324) 86
Link Protection Type: Unprotected (0x02)
A saída deste comando é muito similar a uma captura obtida via analisador de pacotes, como o wireshark.

Explicit-Path Strict: Configurações
Definir os caminhos explícitos
DmOS(config)#mpls traffic-eng
DmOS(config-traffic-eng)#explicit-path <name>
DmOS(config-explicit-path-CAMINHO_PRINCIPAL)#hop <1-65535> ipv4 next-address <ipv4_address> strict
DmOS#show running-config mpls traffic-eng | tab
DmOS#show running-config mpls traffic-eng explicit-path | tab
87
A configuração do túnel baseado em critérios de explicit-path é realizada apenas no equipamento de origem e destino.
A quantidade de túneis e opções de caminho podem ser consultadas no descritivo do sistema operacional DmOS.

Explicit-Path Strict: Verificações
NEXT HOP
PATH NAME ID ADDRESS TYPE
---------------------------------------------
CAMINHO-PRINCIPAL 1 10.21.22.1 strict
2 10.22.23.1 strict
CAMINHO-SECUNDARIO 1 10.21.35.1 strict
2 10.35.24.0 strict
3 10.23.24.0 strict Tipo de critério
ID do caminho
Próximo
Nome do caminho salto/endereço
IP do caminho
88

Interface Túnel TE com Explicit-Path: Configurações
Criação do túnel com engenharia de tráfego
DmOS(config)#interface tunnel-te <1-65535>
DmOS(config-tunnel-te-1)#name <name_tunnel>
DmOS(config-tunnel-te-1)#description <text>
DmOS(config-tunnel-te-1)#destination <ip_loopback_destination>
DMOS(config-tunnel-te-1)#path-option <1-255> explicit name <name_path_option>
*** A criação do túnel é unidirecional, portanto é necessário realizar a mesma configuração no outro vizinho da VPN ***
Para verificar:
DmOS#show running-config interface tunnel-te
DmOS#show running-config interface tunnel-te | tab
DmOS#show mpls traffic-eng tunnel-te <brief | id | name>
89
A ordem de prioridade dos caminhos é definida por um número ao associar o caminho ao túnel. Por exemplo, o path-option 10 tem
prioridade sobre o path-option 20.
Abaixo, segue um exemplo de configuração, utilizou-se como referência o equipamento sinalizado como DmOS-1.
DmOS#router ospf 21
DmOS(config-ospf-21-vrf-global)#mpls-te router-id loopback-0
DmOS#mpls rsvp
DmOS#(config-rsvp)#interface l3-Infra-OSPF-MPLS-SW21-SW22
DmOS#(config-rsvp)#interface l3-Infra-OSPF-MPLS-SW21-SW35
DmOS(config-traffic-eng)#explicit-path CAMINHO-PRINCIPAL
DmOS(config-explicit-path-CAMINHO-PRINCIPAL)#hop 10 ipv4 next-address 10.21.22.1 strict
DmOS(config-explicit-path-CAMINHO-PRINCIPAL)#hop 20 ipv4 next-address 10.22.23.1 strict
DmOS(config-traffic-eng)#explicit-path CAMINHO-SECUNDARIO
DmOS(config-explicit-path-CAMINHO-SECUNDARIO)#hop 10 ipv4 next-address 10.21.35.1 strict
DmOS(config)# interface tunnel-te 1

DmOS(config-tunnel-te-1)#name TUNEL-1_SW21_PARA_SW23
DmOS(config-tunnel-te-1)#description TUNEL-1_SW21_PARA_SW23
DmOS(config-tunnel-te-1)# destination 23.23.23.23
DmOS(config-tunnel-te-1)#path-option 1 explicit name CAMINHO-PRINCIPAL
DmOS(config-tunnel-te-1)#path-option 2 explicit name CAMINHO-SECUNDARIO

Interface Túnel: Verificações
ADMINISTRATIVE ATTRIBUTE
ID NAME DESCRIPTION DESTINATION STATUS PRIO SET NAME STATUS
--------------------------------------------------------------------------------------------------------------------
1 T1_Strict-DmOS21_DmOS23 - 23.23.23.23 up 1 - CAMINHO-PRINCIPAL enable
2 - CAMINHO-SECUNDARIO enable
Nome da interface túnel Destino do túnel

Prioridade do Opção de caminho
ou tail end
path-option habilitada ou não
ID da interface
túnel Status
administrativo
Descrição do
(UP ou Down) Nome dos caminhos explícitos
túnel
90

DmOS# show mpls traffic-eng tunnel-te brief
In In Out Out
ID Name Destination Inst label vlan label vlan Backup Status
-----------------------------------------------------------------------------------------------
1 T1_Strict-DmOS21_DmOS23 23.23.23.23 1 -- -- 16 2122 none up Status
1 T1_Strict-DmOS21_DmOS23 23.23.23.23 2 -- -- -- -- none down instância
1 T1-Strict-DmOS23_DmOS21 21.21.21.21 10 ImpNull 2122 -- -- none up principal “1”
– path
option
Loopback de
destino Interface de
Backup do túnel* Status
Identificação da interface túnel ou nome, sendo: entrada do túnel (ainda não disponível)
(VLAN de infra) instância
secundária “2”
T1_Strict-DmOS21_DmOS23 => Destino equipamento remoto
– path option
T1_Strict-DmOS23_DmOS21 => Destino equipamento local
Label e VLAN de infra de
O túnel é unidirecional! saída
ID do Path
option
Label do túnel conforme path option ativo

ID da interface túnel DmOS-21 para DmOS-23 fluxo de entrada não possui label
DmOS-23 para DmOS-21 é implicit null (label 3) 91
Quando houver alguma falha no path option 1, o tráfego será direcionado para o path option 2, conforme observado a
seguir em vermelho (convergência do tráfego):

In In Out Out
-----------------------------------------------------------------------------------
1 T1_Strict-DmOS21_DmOS23 23.23.23.23 1 -- -- -- -- none down
1 T1_Strict-DmOS21_DmOS23 23.23.23.23 2 -- -- 17 2135 none up
1 T1-Strict-DmOS23_DmOS21 21.21.21.21 10 ImpNull 2135 -- -- none up
*Túnel de backup não disponível.

Identificação da
DmOS#show mpls traffic-eng tunnel-te id 1
interface túnel
Id: 1 Name: T1_Strict-DmOS21_DmOS23 [Active instance 1]
Src: 21.21.21.21 Dst: 23.23.23.23
Origem e destino do túnel
Status:
Admin: up Oper: up Role: head Dir: out
Status do túnel
Path option:
Path-option attribute: PATH_1 , type: explicit (active, instance 1) Informações das
Tunnel LSP: Inlabel: -- , Outlabel: l3-2122 16 características do
primeiro caminho
Path-option attribute: PATH_2 , type: explicit (holding, instance 2)
Tunnel LSP: Inlabel: -- , Outlabel: --
Informações das
Path Info for active instance: características do
1: 10.21.22.1 segundo caminho
2: 10.22.23.1
Caminho ativo para o túnel 1 com a

respectiva sequência de endereços IPs
92
Em caso de falha do caminho principal – PATH_1, verificamos abaixo a atuação do PATH_2, bem como os novos
saltos/caminhos assumidos.
DmOS# show mpls traffic-eng tunnel-te id 1

Id: 1 Name: T1_Strict-DmOS21_DmOS23 [Active instance 2]
Src: 21.21.21.21 Dst: 23.23.23.23
Status:
Path option:
Path-option attribute: PATH_1 , type: explicit (holding, instance 1)
Path-option attribute: PATH_2 , type: explicit (active, instance 2)

Tunnel LSP: Inlabel: -- , Outlabel: l3-2135 17
Path Info for active instance:

1: 10.21.35.1
2: 10.35.24.0
3: 10.23.24.0

LFIB: Verificações
Prefix or In In Out Out Out

Tunnel-Name Action Label Proto Label Proto interface Status
--------------------------------------------------------------------------------
T1_Strict-DmOS21_DmOS23 psh -- -- 16 rsvp l3-vlan 2122 active
Status
Ação
Interface túnel de Protocolo em Interface de saída
destino ou nome que o label de Label de Protocolo que (VLAN de Infra)
Label de
da interface entrada foi saída o label de saída 93
entrada
gerado foi gerado

LFIB: Verificações
DmOS-22# show mpls forwarding-table
In In Out Out Out
------------------------------------------------------------------------------------
T1-Strict-DmOS23_DmOS21 php 19 rsvp ImpNull rsvp l3-vlan 2122 active
T1_Strict-DmOS21_DmOS23 php 16 rsvp ImpNull rsvp l3-vlan 2223 active
VLAN 2223
DmOS-22 10.22.23.x/31 DmOS-23
Lo 22.22.22.22/32 Lo 23.23.23.23/32
.1 .0 .1
1
1 VLAN 2122
10.21.22.x/31
DmOS-21
Lo 21.21.21.21/32 .0 DmOS-23# show mpls forwarding-table
In In Out Out Out
------------------------------------------------------------------------------------
T1-Strict-DmOS23_DmOS21 psh -- -- 19 rsvp l3-vlan 2223 active

In In Out Out Out
----------------------------------------------------------------------------------
*Apenas as informações referentes ao protocolo RSVP, o

94
protocolo LDP foi omitido da visualização
Caso ocorra uma falha no caminho principal e exista um segundo path-option, serão criadas todas as labels necessárias
para o protocolo RSVP.

Laboratório 5 – Explicit Path Loose
DmOS-22 DmOS-23
Lo 22.22.22.22/32 Lo 23.23.23.23/32
.1 .0 .1
.0 .0
VLAN 2223
VLAN 2122 10.22.23.x/31
10.21.22.x/31
DmOS-21
Lo 21.21.21.21/32 .0
VLAN 2335 VLAN 2324
10.23.35.x/31 10.23.24.x/31
.0
VLAN 2135
10.21.35.x/31
VLAN 3524
10.35.24.x/31
.1 .1
.1
.1 .0
DmOS-35 DmOS-24
Lo 35.35.35.35/32 Lo 24.24.24.24/32
95
A respeito da criação do túnel com o critério explicit loose, teremos as premissas:
1. Um túnel MPLS-TE deverá ser criado no DmOS-21 com destino ao DmOS-23, sendo que o ponto de passagem para o
estabelecimento deste caminho deve ser o equipamento DmOS-35, sinalizado aqui em laranja;
3. Como o critério é do tipo loose, o roteamento OSPF estabelecerá o melhor caminho até o DmOS-35;
4. Simularemos uma falha em um dos caminhos utilizados para chegar até o DmOS-35, para que seja possível
visualizarmos a atuação de redundância.

Explicit-Path Loose: Configurações
Definir os caminhos explícitos
DmOS(config-traffic-eng)#explicit-path <name>
DmOS(config-explicit-path-CAMINHO_PRINCIPAL)#hop <1-65535> ipv4 next-address <ipv4_address> loose
DmOS#show running-config mpls traffic-eng | tab
96
A configuração do túnel baseado em critérios de explicit-path é realizada apenas no equipamento de origem e destino.
A quantidade de túneis e opções de caminho podem ser consultadas no descritivo do sistema operacional DmOS.

Explicit-Path Strict: Verificações
NEXT HOP
PATH NAME ID ADDRESS TYPE
---------------------------------------------
CAMINHO-LOOSE-DMOS35 1 35.35.35.35 loose
Tipo de critério
ID do caminho
Próximo
Nome do caminho salto/endereço
IP do caminho
97

Interface Túnel: Configurações
DMOS(config-tunnel-te-1)#path-option <1-255> explicit name <name_path_option>
Para verificar:
98
A ordem de prioridade dos caminhos é definida por um número ao associar o caminho ao túnel. Por exemplo, o path-
option 10 tem prioridade sobre o path-option 20.

--------------------------------------------------------------------------------------------------------------------
2 T2-Loose-DmOS35 - 23.23.23.23 up 10 - CAMINHO-LOOSE-DMOS35 enable

Prioridade do Opção de caminho
ou tail end
path-option habilitada ou não
ID da interface
túnel Status
administrativo
Descrição do
(UP ou Down) Nome do caminho explícito
túnel
99

In In Out Out
-----------------------------------------------------------------------------------------------
2 T2-Loose-DmOS35 23.23.23.23 10 -- -- 19 2135 none up Status
2 T2-LOOSE_DmOS23_DmOS21 21.21.21.21 10 ImpNull 2135 -- -- none up instância
principal
“10” – path
option
Loopback de
destino Interface de
Backup do túnel*
Identificação da interface túnel ou nome, sendo: entrada do túnel (ainda não disponível) Status instância
(VLAN de infra) remota “10” –
T2-Loose-DmOS35 => Destino equipamento remoto path option
T2-Loose_DmOS23_DmOS21 => Destino equipamento local
Label e VLAN de infra de
O túnel é unidirecional! saída
ID do Path
option

ID da interface túnel DmOS-21 para DmOS-23 fluxo de entrada não possui label
DmOS-23 para DmOS-21 é implicit null (label 3) 100
Quando houver alguma falha no path option 10, o roteamento deverá encontrar um novo melhor caminho até o endereço
IP da loopback configurada. O túnel em questão se manterá up.
DmOS-23# show mpls traffic-eng tunnel-te brief

In In Out Out
------------------------------------------------------------------------------------------------
2 T2-Loose-DmOS35 23.23.23.23 10 ImpNull 2324 -- -- none up
2 T2-LOOSE_DmOS-3_DmOS-1 21.21.21.21 10 -- -- 24 2324 none up

Identificação da
interface túnel
Id: 2 Name: T2-Loose-DmOS35 [Active instance 10]
Src: 21.21.21.21 Dst: 23.23.23.23
Status:
Status do túnel
Path option:
Path-option attribute: PATH_1 , type: explicit (active, instance 10) Informações das
Tunnel LSP: Inlabel: -- , Outlabel: l3-2135 19 características do
primeiro caminho
1: 10.21.35.1
2: 10.23.35.0
Caminho ativo para o túnel 1 com a

101
Em caso de falha do caminho principal – PATH_1, verificamos abaixo a atuação do PATH_2, bem como os novos
saltos/caminhos assumidos.
DmOS# show mpls traffic-eng tunnel-te id 2

Id: 2 Name: T2-Loose-DmOS35 [Active instance 10]
Src: 21.21.21.21 Dst: 23.23.23.23
Status:
Path option:
Path-option attribute: PATH_1 , type: explicit (active, instance 10)

1: 10.21.35.1
2: 10.35.24.0
3: 10.23.24.0

Explicit-Path Loose: Verificações
Prefix or In In Out Out Out

Tunnel-Name Action Label Proto Label Proto interface Status
--------------------------------------------------------------------------------------
T1_Strict-DmOS21_DmOS23 psh -- -- 17 rsvp l3-vlan 2135 active Status
T2-Loose-DmOS35 psh -- -- 19 rsvp l3-vlan 2135 active
Ação Interface de saída

Interface túnel de Protocolo em que
(VLAN de Infra)
destino ou nome Label de o label de entrada Label de Protocolo que o label de 102
da interface entrada foi gerado saída saída foi gerado

Explicit-Path Loose: Verificações
DmOS-21# show mpls forwarding-table DmOS-23
In In Out Out Out Lo 23.23.23.23/32
------------------------------------------------------------------------------------
T2-Loose-DmOS35 psh -- -- 19 rsvp l3-vlan 2135 active
.0
DmOS-21
Lo 21.21.21.21/32
VLAN 2335
10.23.35.x/31 DmOS-23# show mpls forwarding-table
.0 In In Out Out Out
VLAN 2135
------------------------------------------------------------------------------------
10.21.35.x/31
T2-LOOSE_DmOS-3_DmOS-1 psh -- -- 24 rsvp l3-vlan 2335 active
.1
.1
DmOS-35
Lo 35.35.35.35/32

In In Out Out Out
------------------------------------------------------------------------------------
T2-LOOSE_DmOS-3_DmOS-1 php 24 rsvp ImpNull rsvp l3-vlan 2135 active
T2-Loose-DmOS35 php 19 rsvp ImpNull rsvp l3-vlan 2335 active

103
Caso ocorra uma falha no caminho escolhido pelo roteamento tradicional para alcançar o equipamento sinalizado na
configuração do loose, será escolhido um nova opção, conforme a métrica do protocolo OSPF para alcançar o endereço IP,
seja ele de uma interface física ou da loopback.

Laboratório 6 – Explicit Path Loose + Strict
DmOS-22 DmOS-23
Lo 22.22.22.22/32 Lo 23.23.23.23/32
.1 .0 .1
2
.0 .0
VLAN 2223
2 VLAN 2122 10.22.23.x/31
10.21.22.x/31
DmOS-21
Lo 21.21.21.21/32 .0
VLAN 2335 VLAN 2324
10.23.35.x/31 10.23.24.x/31
.0
VLAN 2135
10.21.35.x/31
VLAN 3524
10.35.24.x/31
.1
1 .1
.1
.1 .0
DmOS-35 DmOS-24
Lo 35.35.35.35/32 Lo 24.24.24.24/32
1 Caminho principal
2 Caminho secundário/backup
104
A respeito da criação do túnel com o critério explicit loose e strict, teremos as premissas:
1. Um túnel MPLS-TE deverá ser criado no DmOS-21 com destino ao DmOS-23, sendo que o ponto de passagem para o
estabelecimento deste caminho deve ser o equipamento DmOS-35, sinalizado aqui em laranja;
3. Como o critério é do tipo loose, o roteamento OSPF estabelecerá o melhor caminho até o DmOS-35;
4. Se houverem problemas nos dois enlaces que chegam ao DmOS-35, deverá existir uma segunda opção de caminho,
utilizando o caminho explicito strict.
5. Simularemos duas falhas par analisarmos a atuação das redundâncias.

Decimal x Binário x Hexadecimal
Decimal – Sistema numérico base 10, que equivale a quantidade de símbolos utilizados, compostos por valores de zero a nove.
Binário - Utiliza a base 2 e contém apenas dois elementos: ZERO (0) e UM (1).
Posição 2^7 2^6 2^5 2^4 2^3 2^2 2^1 2^0

Valor
128 64 32 16 8 4 2 1
Decimal
Número
0 0 0 0 1 1 0 0
Binário
Número
0 0 0 0 8 4 0 0
Decimal
Hexadecimal - Sistema numérico de base 16, compostos por números 0 até 9 e letras A até F.
Valor Decimal 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Valor Hexa 0 1 2 3 4 5 6 7 8 9 A B C D E F 105

Decimal x Binário x Hexadecimal
Decimal Binário Hexadecimal Decimal Binário Hexadecimal Decimal Binário Hexadecimal Decimal Binário Hexadecimal
0 0000 0 8 1000 8 16 0001 0000 10 24 0001 1000 18
1 0001 1 9 1001 9 17 0001 0001 11 25 0001 1001 19
2 0010 2 10 1010 A 18 0001 0010 12 26 0001 1010 1A
3 0011 3 11 1011 B 19 0001 0011 13 27 0001 1011 1B
4 0100 4 12 1100 C 20 0001 0100 14 28 0001 1100 1C
5 0101 5 13 1101 D 21 0001 0101 15 29 0001 1101 1D
6 0110 6 14 1110 E 22 0001 0110 16 30 0001 1110 1E
7 0111 7 15 1111 F 23 0001 0111 17 31 0001 1111 1F
106

Critérios para Estabelecimento de Túneis: Affinity Bit
Os caminhos utilizados pelos túneis podem ser configurados com base em características, as quais informam por onde pode
ou não estabelecer um LSP.
São atributos definidos em forma de valores configurados e expressos em hexadecimal (0x0 - 0xffffffff) nas interfaces
associadas ao RSVP.
107

Affinity Bit: Definição dos Atributos do Link
Tipo de Link Cor Hexadecimal Binário
Alta Capacidade
Verde 0x1 0000 0001
(100G)
Média Capacidade
Rosa 0x2 0000 0010
(25 e 40G)
Baixa Capacidade
Laranja 0x4 0000 0100
(1 e 10G)
Alta Latência Vermelho 0x8 0000 1000
Link de Rádio Azul 0x10 0001 0000
Link Satélite Preto 0x20 0010 0000
Link de Terceiro Lilás 0x40 0100 0000
Link com Incidências de 1000 0000

Marrom 0x80
Instabilidade 108
O atributo de affinity é definido como um estado do link, que contém 32 bits e que deve representar conceitualmente uma
cor (ou um conjunto de cores) em um link MPLS, e estas “cores” possuem um significado específico no seu designer de
rede. Por exemplo, links de alta latência podem ser sinalizados pela cor vermelha.
O ideal, é organizar um mapeamento de cores para bits, elaborando uma lógica binária combinatória, que pode ser usada
para definir um requisito de restrição de alto nível ou excluir um tipo de link. Como consequência, será necessário fazer as
contas/organizar as cores para segmentar em uma combinação.
O valor de affinity 0 (zero) representa um link sem cor. Além disso, observe que cada link poderá ter várias cores, se
necessário, dependendo da complexidade dos requisitos de restrição que você deseja especificar. No entanto,
normalmente, casos de uso simples terão links de cor única e/ou sem cor.
O link somente será incluido no LSP se a string de afinidade do link for compatível com os atributos do de afinidade do
caminho.

Affinity Bit: Exemplo
Link: Rosa e Lilás – 40G com link de terceiro
Rosa = 0x02
Lilás = 0x40
-------
0x42
Rosa = 0000 0010

Lilás = 0100 0000
---------------
0100 0010
109
Um link pode possuir duas ou mais características simultaneamente: Baixa Capacidade e Alta Latência ao mesmo tempo.
Neste caso, o seu atributo será a soma de 0x4 e 0x8, sendo seu valor final 0x12.
Os atributos podem conter valores de 0x0 a 0xFFFFFFF, representando 32 atributos para classificação dos links, estes
valores são de livre escolha.

Link Attribute e Path Attribute
Link Attribute: Atributo do link, conforme as suas características e informado pelo administrador da rede. Pode ser definido
como a pontuação do link/enlace ou relacionado a uma cor.
Path Attribute: Atributo considerado para a formação do caminho do túnel.
110
Caso um dispositivo encaminhe o tráfego para um outro que não possua uma interface com marcação selecionada para
aquele Path Attibute, o túnel não ficará em estado UP.
O atributo de afinidade referente ao caminho é definido no equipamento sinalizado como head end para a formação do
LSP de acordo com as características configuradas na máscara de 32 bits. Cada um desses bits é configurado com um valor
de mesmo significado para seja possível a sua comparação, permitindo determinar se o link será ou não selecionado ou
até evitado um determinado trajeto.
Qualquer um dos bits pode causar a eliminação do link.

Parâmetro de Afinidade: Include-Any
Para a utilização deste parâmetro é necessário que ocorra match pelo menos em um dos bits.
Hexadecimal Binário Hexadecimal Binário

Path atribute 0x6 0000 0110 0x6 0000 0110
↓↓↓↓ ↓↓↓↓ ↓↓↓↓ ↓↓↓↓
Link atribute 0x2 0000 0010 0x4 0000 0100
Este indicador utilizar o operador lógico OR (ou).
Caso o valor do parâmetro include-any seja zero, o link é aceito independente do valor do seu atributo de affinity.
111
Se fizermos a analogia a cores, ao utilizar o critério de “include any”, todos os links que tiverem essa cor desejada serão
selecionados, mesmo que também possuam outras cores. Por exemplo, ao selecionar links de baixa capacidade – cor
laranja para include any, links sinalizados com baixa capacidade – cor laranja e alta latência – vermelho, serão utilizados.

Parâmetro de Afinidade: Include All
Para o parâmetro include-all é necessário que ocorra match de todos os bits do path.
Hexadecimal Binário Hexadecimal Binário

Path atribute 0x6 0000 0110 0x1 0000 0001
↓↓↓↓ ↓↓↓↓ ↓↓↓↓ ↓↓↓↓
Link atribute 0x2 0000 0010 0x1 0000 0001
Este indicador utilizar o operador lógico AND ou E.
Caso o valor do parâmetro include-all seja zero, o link é aceito independente do valor do seu atributo de affinity.
112
A máscara de 32 bits identifica os bits a serem comparados nos atributos de afinidade do link com o do caminho. Na
operação include all, se o resultado for igual, o LSR seleciona o link, se forem diferentes, o link não é selecionado como um
trajeto válido.
Os bits setados com valor zero não são analisados.
Para um path attribute definido como, 0x00000005 e um link attribute com valor de 0x00000006, observaremos que não
ocorrerá o match em todos os bits, apenas o terceiro bit possuirá o mesmo valor, porém, o link não será utilizado para este
caminho.
Se fizermos a analogia a cores, ao utilizar o critério de “include all”, apenas o link da cor desejada será selecionado, caso
este link tenha outras cores, será descartado. Por exemplo, ao selecionar links de baixa capacidade – cor laranja para
include all, links sinalizados com baixa capacidade – cor laranja e alta latência – vermelho, não serão utilizados.

Parâmetro de Afinidade: Exclude Any
Links que possuam qualquer um dos bits especificados serão excluídos.
Este indicador utilizar o operador lógico OR (ou) para a exclusão de links.
113

Operação com Affinity Bit
DmOS-C
0x4 0x4
0x4
DmOS-A DmOS-B DmOS-E

0x1 0x4 0x8
0x1
0x8
0x1
DmOS-D
AC BC AL
114

Operação com Affinity Bit
Rompimento entre DmOS-A e DmOS-B:
Túnel utilizando apenas os caminhos de alta capacidade:
Rompimento entre DmOS-C e DmOS-E:
115
Com base nas premissas estabelecidas para os links (AC, BC, AL), o RSVP-TE criará automaticamente um túnel com o caminho A-B-D-E
como túnel principal.
Como estamos utilizando os atributos affinity, não será necessário especificar o caminho salto a salto (hop-a-hop). Apenas a declaração
das características para a seleção do caminho precisa ser informada.
Caso ocorra a queda de um link que impeça o estabelecimento deste caminho somente por links com o atributo de alta capacidade, há a
possibilidade de um segundo caminho (path-option 2) com menor prioridade que utilizará tanto links alta como de baixa capacidade.
Este caminho também excluirá links sinalizados como alta latência.
Ao simular uma falha no link entre os equipamentos DmOS-A e DmOS-B (caminho do túnel principal), teremos a convergência sendo
estabelecida pelo caminho A-C-E, conforme visualizado a seguir.
Caso ocorra uma segunda falha, entre os equipamentos DmOS-C e DmOS-E, o caminho de backup seguirá o sentido A-C-B-D-E. O
caminho A-C-B-E teria menor custo, porém o link B-E está sinalizado como alta latência, com isso, foi excluído das opções para
estabelecimento do túnel.
Observe que, com a utilização dos atributos do affinity, o RSVP-TE foi capaz de estabelecer o túnel através de diferentes opções de
caminho, sempre obedecendo as restrições adicionadas a configuração, tornando assim, a operação mais flexível, autônoma e eficaz.

Laboratório 7 e 8 – Affinity Bit
VLAN 2223
DmOS-22 10.22.23.x/31 DmOS-23
Lo 22.22.22.22/32 Lo 23.23.23.23/32
.1 .0 .1
0010 2
.0 .0
0100 4
VLAN 2122
DmOS-21
10.21.22.x/31
Lo 21.21.21.21/32 .0
VLAN 2335 VLAN 2324

0001 1 1000 8
.0 10.23.35.x/31 10.23.24.x/31
VLAN 2135
10.21.35.x/31
0001 1
.1 .1
1000 8
.1
.1 .0
Tipo de Link Cor Binário Hexadecimal
DmOS-35 DmOS-24
Alta Capacidade Lo 35.35.35.35/32 VLAN 3524 Lo 24.24.24.24/32
Azul 0001 0x1 10.35.24.x/31
(40G +LAG)
Média Capacidade
Laranja 0010 0x2
Longa Distância (LAG)
Média Capacidade
Lilás 0100 0x4
Curta Distância (LAG)
Link de
Verde 1000 0x8 116
Terceiros/Transporte
A respeito da criação do túnel com o critério affinity bit, teremos as premissas:
1. Um túnel MPLS-TE deverá ser criado no DmOS-21 com destino ao DmOS-23 para o transporte de um fluxo de voz,
sendo que o caminho principal é o sinalizado em azul, ou seja, o que contém o Hexadecimal 0x1;
2. Em caso de falha, o caminho de backup deverá correr pelos links próprios, ou seja, pelas cores laranja e lilás;
3. Se houver uma falha neste trajeto também, a última opção de caminho deverá ser pelo link de terceiros ou o de
transporte.
5. Simularemos duas falhas, uma no caminho principal e outra no primeiro backup para que seja possível visualizarmos
a convergência do túnel para os caminhos configurados com base nos critérios propostos.

Link Attribute: Configuração
Definir os atributos do link para as interfaces L3
DmOS(config-traffic-eng)#interface l3-<name>
DmOS(config-interface-l3-Infra-OSPF-MPLS-SW21-SW22)#affinity-flags <0x0-0xffffffff>
DmOS#show running-config mpls traffic-eng interface | tab
117
As informações dos atributos de cada link são divulgadas através do OSPF. O protocolo RSVP define um caminho e sinaliza
o túnel com base nas informações do OSPF.
Os recursos de Fast Reroute (FRR) e reserva de banda não são suportados.
A partir da versão 5.12.0 há suporte a interoperabilidade de LSPs com banda do Juniper incluindo as LSPs com auto
bandwidth.
Após habilitado o RSVP e os atributos affinity estão configurados, é possível subir os túneis. A configuração do túnel
precisa ser feita somente no equipamento de origem/Head End LSR.
Abaixo, segue um exemplo de configuração.
DmOS(config)# mpls traffic-eng

DmOS(config-traffic-eng)# interface l3-Infra-OSPF-MPLS-SW21-SW35 affinity-flags 0x1
DmOS(config-interface-l3-Infra-OSPF-MPLS-SW21-SW35)# exit
DmOS(config-traffic-eng)# interface l3-Infra-OSPF-MPLS-SW21-SW22 affinity-flags 0x4

Link Attribute: Verificações
DmOS#show running-config mpls traffic-eng interface | tab
AFFINITY
INTERFACE NAME FLAGS
----------------------------------------
l3-Infra-OSPF-MPLS-SW21-SW22 0x4
l3-Infra-OSPF-MPLS-SW21-SW35 0x1
Nome da interface L3 Valor hexadecimal do atributo

que receberá o atributo
118

Path Attribute: Configuração
Definição das opções de caminhos para Engenharia de Tráfego
DmOS(config-traffic-eng)#attribute-set
DmOS(config-attribute-set)#path-option <name_path>
DmOS(config-path-option-caminho-alta-capacidade)#affinity-flags <exclude-any | include-all | include-
any> <0x0-0xffffffff>
Para verificar:
DmOS#show running-config mpls traffic-eng atribute-set| tab
119
DmOS(config-attribute-set)#path-option AFF_CAMINHO_PRINCIPAL
DmOS(config-path-option-AFF_CAMINHO_PRINCIPAL)#affinity-flags include-all 0x1
DmOS(config-path-option-AFF_CAMINHO_PRINCIPAL)#exit
DmOS(config-attribute-set)#path-option AFF-BACKUP-CAMINHO-INFERIOR
DmOS(config-path-option-AFF-BACKUP-CAMINHO-INFERIOR)#affinity-flags include-any 0x9
DmOS(config-path-option-AFF-BACKUP-CAMINHO-INFERIOR)#exit
DmOS(config-attribute-set)#path-option AFF-BACKUP-CAMINHO-SUPERIOR
DmOS(config-path-option-AFF-BACKUP-CAMINHO-SUPERIOR)#affinity-flags include-any 0x6

Affinity: Verificações
DmOS#show running-config mpls traffic-eng attribute-set | tab
EXCLUDE INCLUDE INCLUDE
PATH NAME ANY ALL ANY
---------------------------------------------------------
AFF_CAMINHO_PRINCIPAL - 0x1 -
AFF_BACKUP-CAMINHO-INFERIOR - - 0x9
AFF_BACKUP-CAMINHO-SUPERIOR - - 0x6
Critério exclude Critério

Nome do caminho include-any
Critério
include-all
120

Interface Túnel: Configuração
DMOS(config-tunnel-te-1)#path-option <1-255> dynamic attribute-set <name_path_option>
Para verificar:
121
Somente são suportados túneis na mesma área do OSPF (intra-area).
DmOS(config-interface-l3-Infra-OSPF-MPLS-SW21-SW22)#affinity-flags 0x00000002
DmOS(config-interface-l3-Infra-OSPF-MPLS-SW21-SW22)#interface l3-Infra-OSPF-MPLS-
SW21-SW24
DmOS(config-interface-l3-Infra-OSPF-MPLS-SW21-SW24)#affinity-flags 0x00000003
DmOS(config-attribute-set)#path-option caminho-alta-capacidade
DmOS(config-path-option-caminho-alta-capacidade)#affinity-flags include-any 0x1
DmOS(config-path-option-caminho-alta-capacidade)#affinity-flags exclude-any 0x4
DmOS(config-path-option-caminho-alta-capacidade)#exit
DmOS(config-attribute-set)#path-option caminho-baixa-capacidade
DmOS(config-path-option-caminho-baixa-capacidade)#affinity-flags include-any 0x3
DmOS(config-path-option-caminho-baixa-capacidade)#affinity-flags exclude-any 0x4
DmOS(config)# interface tunnel-te 1

DmOS(config-tunnel-te-1)#description TUNEL-RSVP
DmOS(config-tunnel-te-1)#destination 24.24.24.24
DmOS(config-tunnel-te-1)#path-option 1 dynamic attribute-set caminho-alta-capacidade
DmOS(config-tunnel-te-1)#path-option 2 dynamic attribute-set caminho-baixa-capacidade
Caso ocorra a queda de um link que impeça o estabelecimento deste caminho somente por links com o atributo de alta
capacidade, há a possibilidade de um segundo caminho (path-option 2) com menor prioridade que utilizará tanto links
alta como de baixa capacidade. Este caminho também excluirá links sinalizados como alta latência.

-------------------------------------------------------------------------------------------------------------------------------
3 T3-AFF_TUNEL_VOIP_DMOS21_DMOS23 - 23.23.23.23 up 10 AFF_CAMINHO_PRINCIPAL - enable
20 AFF_BACKUP-CAMINHO_SUPERIOR - enable
30 AFF_BACKUP-CAMINHO-INFERIOR - enable

ou tail end Opção de caminho
Prioridade do
ID da interface habilitada ou não
path-option
túnel Status
administrativo
Descrição do
(UP ou Down)
túnel Nome do utilizado para o
caminho
122

Interface Túnel: Verificações Status
instância
principal “10” –
DmOS#show mpls traffic-eng tunnel-te brief path-option
In In Out Out
-----------------------------------------------------------------------------------------------
3 T3-AFF_TUNEL_VOIP_DMOS21_DMOS23 23.23.23.23 10 -- -- 17 2135 none up
3 T3-AFF_TUNEL_VOIP_DMOS23_DMOS21 21.21.21.21 10 ImpNull 2135 -- -- none up
3 T3-AFF_TUNEL_VOIP_DMOS21_DMOS23 23.23.23.23 20 -- -- -- -- none down
Loopback de
destino Interface de Status instância
Identificação da interface túnel ou nome, sendo: entrada do túnel remota “10” –
(VLAN de infra) path-option
T3-AFF_TUNEL_VOIP-DMOS21-DMOS23 => Destino equipamento remoto
T3-AFF_TUNEL-VOIP-DMOS23-DMOS21 => Destino equipamento local
Label e VLAN de Backup do túnel*
O túnel é unidirecional! (ainda não disponível)
ID do Path infra de saída
option

ID da interface túnel
DmOS-21 para DmOS-23 fluxo de entrada não possui label
123
DmOS-23 para DmOS-21 é implicit null (label 3)
Quando houver alguma falha no path option 10 (principal), o tráfego será direcionado para o próximo path option, para
este exemplo, será o de ID 20, conforme observado a seguir em vermelho (convergência do tráfego):
DmOS#show mpls traffic-eng tunnel-te brief

In In Out Out
-------------------------------------------------------------------------------------
3 T3-AFF_TUNEL_VOIP_DMOS21_DMOS23 23.23.23.23 20 -- -- 199 2122 none up
3 T3-AFF_TUNEL_VOIP_DMOS23_DMOS21 21.21.21.21 20 ImpNull 2122 -- -- none up
Caso ocorra uma falha nos trajetos do path-option 20 o path-option 30 assume o envio do tráfego.

Identificação da
interface túnel
Id: 3 Name: T3-AFF_TUNEL_VOIP_DMOS21_DMOS23 [Active instance 10]
Src: 21.21.21.21 Dst: 23.23.23.23
Status:
Status do túnel
Path option:
Path-option attribute: PATH_1 , type: dynamic (active, instance 10) Informações das
Affinity (AFF_CAMINHO_PRINCIPAL): 0x0 [Incl.Any] 0x1 [Incl.All] 0x0 [Excl.Any] características do
Tunnel LSP: Inlabel: -- , Outlabel: l3-2135 17 primeiro caminho
Path-option attribute: PATH_2 , type: dynamic (holding, instance 20)

Affinity (AFF_CAMINHO_SECUNDARIO_VoIP): 0x6 [Incl.Any] 0x0 [Incl.All] 0x0 [Excl.Any]
Informações
das
características
Affinity (AFF_CAMINHO_SECUNDARIO_PPPoE): 0x9 [Incl.Any] 0x0 [Incl.All] 0x0 [Excl.Any]
do segundo
caminho
Path Info for active instance: Informações das características do terceiro
1: 10.21.35.1 caminho
2: 10.23.35.0
Caminho ativo para o túnel com a 124
SW-21# show mpls traffic-eng tunnel-te id 3

Id: 3 Name: AFFINITY_SW21_SW23_VoIP [Active instance 20]
Src: 21.21.21.21 Dst: 23.23.23.23
Status:
Path option:
Affinity (AFF_CAMINHO_PRINCIPAL): 0x0 [Incl.Any] 0x1 [Incl.All] 0x0
[Excl.Any]
Path-option attribute: PATH_2 , type: dynamic (active, instance 20)

Affinity (AFF_CAMINHO_SECUNDARIO_VoIP): 0x6 [Incl.Any] 0x0 [Incl.All] 0x0
[Excl.Any]

Affinity (AFF_CAMINHO_SECUNDARIO_PPPoE): 0x9 [Incl.Any] 0x0 [Incl.All] 0x0
[Excl.Any]

1: 10.21.22.1
2: 10.22.23.1

In In Out Out Out
---------------------------------------------------------------------------------------------
T2-Loose-DmOS35 psh -- -- 39 rsvp l3-vlan 2135 active Status
T3-AFF_TUNEL_VOIP_DMOS21_DMOS23 psh -- -- 17 rsvp l3-vlan 2135 active
Ação Interface de saída

Interface túnel de Protocolo em que
(VLAN de Infra)
destino ou nome Label de o label de entrada Label de Protocolo que o label de 125
da interface entrada foi gerado saída saída foi gerado

In In Out Out Out
DmOS-23
Lo 23.23.23.23/32
-------------------------------------------------------------------------------------------
T3-AFF_TUNEL_VOIP_DMOS21_DMOS23 psh -- -- 17 rsvp l3-vlan 2135 active
.0
DmOS-21
Lo 21.21.21.21/32
VLAN 2335
10.23.35.x/31 DmOS-23# show mpls forwarding-table
.0
In In Out Out Out
VLAN 2135 Prefix or Tunnel-Name Action Label Proto Label Proto interface Status
10.21.35.x/31 --------------------------------------------------------------------------------------------
T3-AFF_TUNEL_VOIP_DMOS-3_DMOS-1 psh -- -- 36 rsvp l3-vlan 2335 active
.1
.1
DmOS-35
Lo 35.35.35.35/32

In In Out Out Out
-------------------------------------------------------------------------------------------
T3-AFF_TUNEL_VOIP_DMOS-3_DMOS-1 php 36 rsvp ImpNull rsvp l3-vlan 2135 active
T3-AFF_TUNEL_VOIP_DMOS21_DMOS23 php 17 rsvp ImpNull rsvp l3-vlan 2335 active

126

LOGs
DmOS#show log | include RSVP
2020-07-14 10:45:38.201 : 1-1 : <Info> %ROUTER-RSVP_TUNNEL_STATE : Router[5202] : RSVP tunnel status

change - Tunnel 1, Instance 2, Local TE router-id 23.23.23.23, Destination 21.21.21.21, Status UP
change - Tunnel 1, Instance 1, Local TE router-id 21.21.21.21, Destination 23.23.23.23, Status DOWN

127

DEBUG
DmOS#debug enable proto-rsvp
2020-07-14 10:32:15.225526 [proto-rsvp] : RSVP tunnel status change - Tunnel 2, Instance 2, Local TE
router-id 23.23.23.23, Destination 21.21.21.21, Status UP
router-id 21.21.21.21, Destination 23.23.23.23, Status DOWN
128

DEBUG
DmOS#debug enable cpu-tx cpu-rx
2020-07-15 12:01:28.198443 [cpu-tx] PKT TX <Proto L3_IP_RSVP, VLAN ID 2124, VLAN Pri 0, COS 0, Len
74, SrcPort CPU, Flags [], Ports []>
2020-07-15 12:02:23.721421 [cpu-rx] PKT RX <Proto L3_IP_RSVP, VLAN ID 2124, VLAN Pri 0, Len 74,
SrcPort lag-2, DstPort cpu-port 1/1/1, SrcIP 10.21.24.0, DstIP 10.21.24.1, Flags [DstPort], Reasons
[Nhop FilterMatch]>
129

TCP DUMP
Habilitar a captura dos pacotes
DmOS#tcpdump <rx | rx-and-tx | tx>
[TX Mode: VLAN, TX] - 16:53:15.636831 IP 10.23.24.0 > 10.23.24.1: RSVPv1 Refresh Message, length: 36
[Interface: cpu-port-1/1/1, RX] - 16:53:15.638259 IP 10.23.24.0 > 10.23.24.1: RSVPv1 Refresh Message,
length: 36
Gerar o arquivo PCAP

DmOS#tcpdump rx-and-tx save-pcap
Exportar o arquivo para um servidor TFTP

DmOS#copy pcap tftp://<server_address>
130

Análise de Falhas
show running-config interface l3
show ip interface brief show running-config interface loopback
show interface link show running-config dot1q show ip host-table show ip interface brief
Interface Física Dot1q/VLAN Interface L3 Loopback
RSVP Tabela de Roteamento OSPF
show mpls forwarding-table show ip route show ip ospf

show mpls traffic-eng tunnel-te brief show ip route destination a.b.c.d/x show ip ospf neighbor
show mpls traffic-eng tunnel-te id <id>
131

DATACOM. Command Reference DmOS. 2022.
DATACOM. Descritivo dos Produtos DmOS. 2022.
DATACOM. Guia de Configuração Rápida DmOS. 2022.
DATACOM. Manual de Instalação dos Produtos com sistema Operacional DmOS. 2022.
ENNE, Antonio José Figueiredo. TCP/IP sobre MPLS. Rio de Janeiro: Editora Ciência Moderna Ltda, 2022.
GHEIN, Luc de. MPLS Fundamentals. Cisco Press, 2013.
LACOSTE, Raymond; EDGEWORTH, Bradley. CCNP Enterprise Advanced Routing ENARSI 300-410. Cisco Press, 2020.
OLIVEIRA, José Mário. Redes MPLS: fundamentos e aplicações. Rio de Janeiro: Brasport, 2012.

Contatos Datacom

DmSupport – Atendimento Inteligente DATACOM
O DmSupport é um sistema de atendimento online simples e eficiente que auxilia os clientes DATACOM na
abertura de chamados, na aquisição de documentação oficial e na obtenção de dicas de configuração para toda
a linha de produtos.
O acesso está disponível por computador ou celular, através do link:
https://supportcenter.datacom.com.br/qualitor/loginUsuario.php
134
Os serviços disponíveis estão organizados por linhas de produtos e o para acesso as informações apenas coloque o mouse
sobre o item desejado.
Nas laterais estão disponíveis dois menus:
Lado esquerdo
Serviços – Acesso ao menu de serviços por equipamentos;
Solicitações – Consulta as solicitações realizadas com status de aberta, aguardando atuação
ou encerradas;
Novo Chamado – Abertura de chamados para a equipe de suporte;
Base de Conhecimento – Acesso a base de documentos;
Pesquisa de Satisfação – Realização da pesquisa de satisfação referente ao atendimento
recebido;
Links Personalizados – Ferramentas e aplicativos gratuitos.

Rua América, 1000 | Eldorado do Sul | RS | Brasil
+55 51 3933 3000
www.datacom.com.br

Apostila Treinamento DmOS-MPLS PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila Treinamento DmOS-MPLS PDF

Enviado por

Direitos autorais:

Formatos disponíveis

GUIA OFICIAL DE CAPACITAÇÃO

Versão da Apostila: 8.0.4 2

• Presença nacional e em mais de 45 países

• Tecnologia 100% nacional

• Maior área de Pesquisa e Desenvolvimento do Brasil

• 13.000m2 de área construída e 120.000m2 de área total com

• Treinamento presencial e EaD

Versão da Apostila: 8.0.4 3

• Identificar e diferenciar os equipamentos pertencentes as linhas de atuação da DATACOM;

Versão da Apostila: 8.0.4 4

Ethernet Switches Gerenciamento de

Versão da Apostila: 8.0.4 5

DM1200E Series DM1105E Series DM1205E Series

Switch LAN – L2 Switch LAN – L2 Switch LAN – L2

24GE Elétricas 24GE Elétricas 48GE Elétricas

Stackable/Empilhamento AC Full Range AC Full Range

AC Full Range PoE+ PoE+

Alimentação de Redundância Interface WEB Rota Estática IPv4/IPV6

Rota Estática IPv4/IPv6

Na tabela a seguir é possível verificar as capacidades da linha de switches LAN.

Modelos GE Uplink Tipo

DM1105E 24GT+2GX 24 2x GE SFP L2

DM1105E 24GP+2GX 24 PoE 2x GE SFP L2

DM1200E 24GT+4XS 24 4x 10GE SFP+ L2/L3

DM1200E 24GP+4XS 24 PoE 4x 10GE SFP+ L2/L3

DM1205E 48GT+4GX 48 4x GE SFP L2/L3

DM1205 48GT+2XS 48 2x 10GE SFP+ L2/L3

DM1205 48GP+2XS 48 PoE 2x 10GE SFP+ L2/L3

Versão da Apostila: 8.0.4 6

GE Uplinks GE Uplinks 8x1GE Uplink 8x1GE Uplink 12x10GE Uplink

Emulação de E1 / CESOP Emulação de E1 / CESOP AC/DC 4x10GE Uplink 3x100GE Uplink

ACR 1588v2 (GPS) Redundância 12V AC/DC AC ou DC – PSU 125

AC/DC RFC2544/Y.1564 DmOS Based Redundância 12V Alimentação de Redundância

AC/DC DmOS Based DmOS Based

Versão da Apostila: 8.0.4 7

L2/L3 Fast Ethernet L2/L3/MPLS L2/L3 L2/L3/MPLS L2/L3/MPLS Modular

Alimentação de Redundância PoE+ Alimentação de Redundância Alimentação de Redundância MPU de Redundância

AC/DC – PSU 85 DmOS Based DmOS Based DC

Versão da Apostila: 8.0.4 8

DM4250 Series DM4270 Series DM4770 Series

L2/L3 L2/L3/MPLS L2/L3/MPLS

24x10GE + 2x40GE Uplinks 24x10GE + 3x100GE or 4x40GE 2x10GE + 32x100GE/40GE

AC ou DC – PSU 125 48x10GE + 6x100GE/40GE 4x10GE/25GE +

Versão da Apostila: 8.0.4 9

DM936 D8CH33 DM936 S16CH19 DM936 D32CH19 Módulos Coloridos

8 Canais (Duas Fibras) 16 Canais (Uma Fibra) 32 Canais (Duas Fibras)

Versão da Apostila: 8.0.4 10

DM8630 NFV Universal DM2500 Series DM955

Network Functions 4GE Dual Band Wi-Fi 2,4GHZ e 5GHz

Modelos Processor Cores RAM Storage

Versão da Apostila: 8.0.4 11

2 Processors AMD EPYCTM 7002

8 slots DIMM 3200MHZ

OCP Rack or 19’

8 to 64 CORES per Processor

Interface 25G // 50G // 100Gbps

OCP – Open Compute Project

Versão da Apostila: 8.0.4 12

DM4615 DM4610 DM4612 DM4611 DM4618

16xGPON 8xGPON 8xGPON 4xGPON 64xGPON // 32xGPON +

Versão da Apostila: 8.0.4 13

Laser B+ // C+ // D DM984-100B DM984-420 DM984-422 DM985-424 / DM986-414

Opção de Temperatura Laser C+ PTO integrado 2,4GHz Dual Band