spb-architecture-tech-brief-en en pt

Prévia do material em texto

Ponte do caminho mais curto
Guia de arquitetura
Resumo técnico
Guia de Shortest Path Bridging Architecture
Índice
1. Sobre este guia de arquitetura ............................................ ........................................... 4
1.1 Objetivo ................................................ .................................................. ....................... 4
1.2 Público ................................................ .................................................. ..................... 4
1.3 Glossário ................................................ .................................................. ...................... 4
1.4 Referências ................................................ .................................................. .................. 5
2. A rede precisa evoluir ........................................... ............................................ 5
3. Apresentando SPB .............................................. .................................................. .................. 6
3.1 Estrutura escalável, de rápida convergência, de múltiplos caminhos ....................................... ............ 7
3.2 Multilocação .............................................. .................................................. .............. 7
3.3 Instanciação de serviço dinâmico .............................................. ............................... 8
3.4 Provisionamento de serviço apenas de borda ............................................ ............................... 8
3.5 Microssegmentação .............................................. .................................................. 0,8
3.6 Núcleo não IP ............................................. .................................................. ................... 9
4. O Plano de Dados: Ponte de backbone do Provedor IEEE 802.1ah ............................. 9
5. O Plano de Controle: RFC 6329 IS-IS Equal-cost trees ................................... ......
6. A estrutura de serviço ............................................. .................................................. ..
7. Tráfego BUM .............................................. .................................................. .........................
8. Criando um backbone SPB ............................................ ..............................................
9. Serviços L2 .............................................. .................................................. ........................
10. Conceitos de roteamento .............................................. .................................................. ..........
11. Serviços L3 .............................................. .................................................. ......................
11.1 VPN Lite ............................................... .................................................. .................
11.2 VPN L3 ............................................... .................................................. ....................
11.3 VPN Lite versus VPN L3 ............................................ .......................................
12. VPN de serviços compartilhados e vazamento de rota .......................................... ..................
13. Automação ............................................... .................................................. ....................
13.1 Auto-Fabric .............................................. .................................................. ............
13.2 SAPs Dinâmicos ............................................... .................................................. ......
13.3 Serviços Dinâmicos ............................................... .................................................
11
13
15
16
20
26
29
29
30
34
34
36
36
38
42
Resumo técnico
Guia de Shortest Path Bridging Architecture 2
14. Gestão ............................................... .................................................. ..................
15. Operação e manutenção ............................................. ........................................
15.1 Gerenciamento de falha de conectividade: 802.1ag ........................................... ......
15.2 Desempenho da rede: Agente de garantia de serviço ..................................
15.3 Manutenção de rede ............................................... .........................................
16. Redundância do anexo de serviço ............................................. ...............................
17. Prevenção e supressão de loop ............................................ ..............................
18. Diretrizes gerais de design ............................................. ............................................
18.1 BVLANs ................................................ .................................................. ..................
18.2 Mapeamento de VLAN para serviço ........................................... .....................................
18.3 Chassi Virtual ............................................... .................................................. .....
18.4 Agregação de link ............................................... .................................................. .
18.5 Link Metric ............................................... .................................................. ............
18.6 QoS ................................................ .................................................. ..........................
19. Diretrizes de segurança .............................................. .................................................. ......
19.1 Gerenciamento VRF ............................................... ..................................................
19.2 MACSec ................................................ .................................................. ..................
19.3 NAC ................................................ .................................................. .........................
19.4 Autenticação do roteador ............................................... .........................................
20. Conclusão ............................................... .................................................. ......................
43
45
45
47
48
48
51
52
52
52
53
53
54
54
54
55
55
55
55
56
Resumo técnico
Guia de Shortest Path Bridging Architecture 3
1. Sobre este guia de arquitetura
1.1 Objetivo
O objetivo deste guia de arquitetura é apresentar os conceitos de rede SPB (802.1aq) junto com as diretrizes de 
design e implantação. Não tenta cobrir todos os aspectos, nem todas as opções de arquitetura possíveis, 
apenas as arquiteturas mais comuns, validadas e recomendadas. Recomendamos que você consulte a 
documentação do Alcatel-Lucent Operating Software (AOS) para
detalhes, opções e orientações adicionais.
1.2 Público
O público-alvo deste documento inclui clientes e profissionais de rede de parceiros de negócios envolvidos 
no projeto e implantação de redes corporativas.
1.3 Glossário
AG
BCB
B-DA
BEB
BGP
BMAC
B-SA
BSN
B-VID
Guardião de acesso
Ponte do núcleo do backbone
Endereço de destino do backbone 
Backbone Edge Bridge
Border Gateway Protocol 
Backbone MAC
Número de serviço básico do 
endereço de origem do backbone
Backbone VLAN ID
Backbone VLAN
Cliente MAC
Plano de Controle
Negação de serviço
Plano de Dados
Árvore de igual custo
Banco de Dados de Encaminhamento
Tecido inteligente da força-tarefa de 
engenharia da Internet
Identificador de serviço de instância 
de protocolo de gateway interior
Protocolo de distribuição de rótulo de sistema 
intermediário para sistema intermediário
Controle de acesso de mídia
Move, adiciona e altera o 
BGP multiprotocolo
BVLAN
CMAC
PC
DoS
DP
ECT
FDB
IETF
iFab
IGP
ISID
IS-IS
LDP
MAC
MACs
MP-BGP
Resumo técnico
Guiade Shortest Path Bridging Architecture 4
MSTP
NAC
OSPF
PBB
Q-in-Q
RAIO
ROI
RSTP
SEIVA
SDP
SPB
SPB-M
SPB-V
SPF
STP
TLV
UNP
Controle de admissão de rede do protocolo IEEE 
802.1s Multiple Spanning Tree
abrir o caminho mais curto primeiro
Ponte de backbone de provedor IEEE 802.1ah 
Ponte de provedor IEEE 802.1ad
Retorno sobre o investimento do serviço de usuário 
de acesso remoto por discagem
Ponto de acesso do serviço de protocolo IEEE 802.1w 
Rapid Spanning Tree
Ponto de Distribuição de Serviço
IEEE 802.1aq Shortest Path Bridging SPB 
MAC-in-MAC
SPB Q-in-Q
Caminho mais curto primeiro
Tipo, comprimento e valor do protocolo 
Spanning Tree IEEE 802.1D
Perfil de rede do usuário
1.4 Referências
[1] Serviços IP / IPVPN com redes IEEE 802.1aq SPB - draft-unbehagen-spb-ip-ipvpn-00.txt
[2] Provisionamento baseado em modelo Alcatel-Lucent OmniSwitch® com Alcatel-Lucent OmniVista® 
2500 Network Management System (NMS)
[3] Práticas recomendadas de segurança de infraestrutura de rede
2. A rede precisa evoluir
As redes locais (LAN) tradicionalmente contam com o Spanning Tree Protocol (STP) e suas variantes (RSTP, 
MSTP), coletivamente chamadas de “STP” para simplificar, para prevenção de loop. O STP obtém uma 
topologia sem loop ao eleger uma “ponte raiz” e construir uma árvore de menor custo ligando a ponte raiz a 
outros nós não raiz. Esta árvore de menor custo é criada pela poda (desabilitação) de todos os ramos (links) 
que não estão no caminho de menor custo em direção à raiz. O princípio de design do STP apresenta várias 
desvantagens para redes empresariais modernas:
• Links não utilizados: A criação de uma topologia sem loop desativando os links de rede resulta em uso 
ineficiente de largura de banda e baixo retorno do investimento (ROI)
• Caminhos abaixo do ideal: Embora a comunicação de e para a ponte raiz siga o caminho de menor 
custo, a comunicação entre pontes não raiz pode precisar atravessar uma rota subótima que transita 
pela ponte raiz em vez de rotas alternativas melhores sobre links que foram desabilitados
• Convergência lenta: O STP é um protocolo de décadas projetado quando os dispositivos de rede eram muito menos 
poderosos do que são hoje. Mesmo com a versão “rápida” do STP, os tempos de convergência típicos são da ordem de 
segundos. Enquanto o STP converge novamente para uma nova topologia, podem se formar loops transitórios, resultando 
em quedas de pacotes, saturação de link e tempo limite de sessão.
Resumo técnico
Guia de Shortest Path Bridging Architecture 5
Figura 1. Os problemas com STP
Ineficiente
rotas
Destino 2 MACs
M1 ... M100
Fonte
Ponte raiz
Todos os nós da rota 
precisam aprender M1-
M100 do MAC
Não pode usar
esses links
Destino 1
Além dos pontos fracos do STP, a escalabilidade da Ethernet além da LAN é limitada pela falta de um plano de 
controle coordenado e pelo uso de um espaço de endereço plano (em oposição ao hierárquico). As redes 
Ethernet legadas apresentam os seguintes desafios:
• Inundações: O aprendizado de endereço de “inundação e aprendizado” da Ethernet inunda o tráfego unicast desconhecido até 
que o endereço de destino seja aprendido a partir do tráfego de retorno
• Aprendizagem MAC: Todos os nós na LAN aprendem todos os endereços MAC do dispositivo final, representando assim um 
desafio de escalabilidade
Por último, o IEEE 802.1ad (Provider Bridging ou Q-in-Q) é limitado a um máximo de 4.096 
instâncias de serviço.
3. Apresentando o SPB
802.1aq Shortest Path Bridging (SPB) é um padrão de rede IEEE cujo foco principal era abordar os desafios no 
STP. Mas o SPB é muito mais do que a evolução do STP: o SPB fornece serviços VPN do tipo MPLS, mas é 
significativamente mais simples de implantar e manter. E ao contrário do MPLS, que requer uma “pilha” de 
protocolos (por exemplo: LDP, OSPF, MP-BGP, entre outros), o SPB conta com um único protocolo para fornecer 
esta funcionalidade: IS-IS (Intermediate System to Intermediate System). IS-IS é o único protocolo de plano de 
controle necessário para construir uma topologia de múltiplos caminhos, realizar aprendizado de endereço e 
transportar rotas VPN através do backbone. O Intelligent Fabric (iFab) da Alcatel-Lucent Enterprise traz mais 
simplificação ao automatizar o provisionamento de nós de rede,
conexão de dispositivo cliente e instanciação dinâmica de serviço. Devido a essa simplicidade e automação, uma 
solução SPB com tecnologia ALE oferece serviços de ponta por um custo total de propriedade (TCO) mais baixo. 
Vamos analisar os benefícios do SPB em mais detalhes.
Resumo técnico
Guia de Shortest Path Bridging Architecture 6
3.1 Tecido escalável, de rápida convergência e de múltiplos caminhos
Figura 2. Lidando com os desafios de STP
1
Múltiplo
o mais curto
caminhos
Destino 2 MACs
M1 ... M100PBB
encapsulamento
nas bordas
PBB
encapsulamento
nas bordas 2
MACs M1-M100
aprendizagem restrita
para as bordas
Todos os links
são utilizáveis3
PBB
encapsulamento
nas bordas Destino 1
A topologia sem loop do SPB é construída por um protocolo de roteamento link-state que executa o algoritmo 
Shortest Path First (SPF) de Dijkstra: IS-IS. Com o IS-IS, nenhum link de rede é desabilitado, todos os caminhos estão 
disponíveis e o tráfego entre qualquer par de nós segue o caminho mais curto. Além disso, com o encapsulamento 
MAC-in-MAC, os nós de backbone não aprendem nenhum endereço MAC do dispositivo final, aumentando assim a 
escalabilidade e estabilidade da rede. Com o encapsulamento IS-IS e MAC-in-MAC, o SPB cria uma “malha” escalável e 
de rápida convergência, qualquer para qualquer, que oferece suporte a vários caminhos otimizados ativos para 
tráfego interligado e roteado.
3.2 Multilocação
O SPB oferece suporte nativo para multilocação: A rede física é particionada em vários “segmentos” virtuais 
chamados VPNs, “contêineres” ou “comunidades”. Os clientes, ou grupos de dispositivos IoT, segregados em 
VPNs diferentes são isolados e não interferem uns com os outros. Na verdade, eles podem usar o espaço de 
endereço sobreposto sem conflito. A comunicação entre VPN, se necessária, é rigidamente controlada por 
políticas de firewall. Essa capacidade de multilocação torna o SPB adequado para casos de uso como cidades 
inteligentes, transporte, ensino superior, vigilância por vídeo ou centros de dados, para citar alguns. A 
escalabilidade do SPB não se limita a 4.096 locatários porque seu identificador de serviço, o
ISID, é um campo de 24 bits que pode diferenciar até 16M de serviços.
Figura 3. Multilocação
Resumo técnico
Guia de Shortest Path Bridging Architecture 7
3.3 Instanciação dinâmica de serviço
Os serviços SPB não precisam estar estaticamente vinculados a uma porta do switch. O SPB está totalmente integrado à 
classificação da Alcatel-Lucent Enterprise e à estrutura de controle de admissão de rede (NAC) conhecida como Access 
Guardian (AG). Após a conexão, os dispositivos finais podem ser classificados (por exemplo; com base nas regras de 
“impressão digital” MAC OUI ou IoT) ou autenticados (por exemplo; por meio de 802.1x ou MAC) em um servidor 
RADIUS. O serviço apropriado é instanciado dinamicamente de acordo com o dispositivo ou classificação do usuário, ou 
atributo de função retornado pelo servidor RADIUS. Da mesma maneira, essa ligação de usuário para serviço é 
removida quando o usuário / dispositivo se desconecta. Esta instanciação dinâmica de serviço tem as seguintes 
vantagens:
• Mobilidade do usuário / dispositivo: A configuração de rede se adapta dinamicamente a usuários e dispositivos móveis ou 
migrações de máquinas virtuais (VMs) sem a necessidade de mover, adicionar ou alterar solicitações
• Maior segurança: Os serviços são instanciados apenas conforme a necessidade e apenas para dispositivos / 
usuários autenticados, se aplicável. Essa associação é mantida enquanto o usuário / dispositivo permanecer 
conectado e / ou autenticado, e é desativada na desconexão / logoff. Esses serviços efêmeros são 
inerentemente maisseguros: eles não podem ser verificados, DoSd ou hackeados de outra forma, enquanto 
não estiverem ativos.
• Modelos de dispositivo: Esta instanciação dinâmica de serviços de rede facilmente se presta à configuração 
baseada em modelos de nós de rede. Todos os nós de borda podem compartilhar o mesmo modelo de 
configuração de base e ajustar dinamicamente as configurações de serviço em tempo real.
3.4 Provisionamento de serviço somente de borda
Quer sejam instanciados estática ou dinamicamente, os serviços SPB precisam ser provisionados apenas em nós de 
extremidade, não em nós centrais. Os nós centrais são efetivamente isolados de Movimentações, Adições e Mudanças de 
serviço e não requerem nenhum toque enquanto essas atividades são realizadas. Na verdade, os MACs de serviço podem ser 
realizados durante o horário comercial e não exigem o agendamento de uma janela de manutenção, reduzindo o tempo de 
serviço.
3.5 Microssegmentação
Os firewalls filtram e controlam a comunicação entre diferentes “locatários” ou “contêineres” de VPN. Mas, como você 
protege a comunicação dentro da mesma VPN? Por exemplo, se um dispositivo foi comprometido, como você evita o 
movimento lateral para outros recursos dentro da mesma VPN? Quando os usuários / dispositivos são vinculados 
dinamicamente a um serviço, eles também são mapeados para um Perfil de Rede do Usuário (UNP). O UNP é um 
conjunto de políticas de Listas de Controle de Acesso (ACLs) e Qualidade de Serviço (QoS) que são aplicadas ao 
dispositivo / usuário de acordo com a categoria do dispositivo ou função do usuário. Vamos tomar as câmeras de CFTV 
como exemplo: ACLs contidos no UNP podem permitir a comunicação entre
a câmera e os servidores de vigilância, mas ao mesmo tempo bloqueiam a comunicação de câmera para câmera,
evitando a propagação de malware, “pivoting” e outras técnicas de hacking que dependem de 
movimento lateral.
Resumo técnico
Guia de Shortest Path Bridging Architecture 8
Figura 4. Microssegmentação
Perfil audiovisual
Autenticar
Classificar
Provisão de automóveis
✓ Recipiente
✓ Qualidade
✓ Segurança
Perfil de operação do campus
Autenticar
Classificar
Provisão de automóveis
✓ Recipiente
✓ Qualidade
✓ Segurança
Perfil de segurança
Autenticar
Classificar
Provisão de automóveis
✓ Recipiente
✓ Qualidade
✓ Segurança
3.6 Núcleo não IP
Mesmo ao fornecer serviços L3 para pacotes IP, os nós centrais SPB não roteiam o tráfego, eles fazem a ponte. 
Na verdade, os nós centrais SPB não têm endereços IP e o protocolo de controle IS-IS, ao contrário do OSPF e 
do BGP, não é executado sobre o IP. Isso torna o núcleo da rede inerentemente mais seguro e o protege de 
ataques baseados em IP, como varredura, falsificação, DoS e outros. Obviamente, os nós SPB ainda precisam 
de um endereço IP para fins de gerenciamento, mas a interface IP de gerenciamento é isolada em seu próprio 
serviço e VRF, não em linha com o tráfego do usuário.
4. O plano de dados: ponte de backbone do provedor IEEE 802.1ah
A missão do Data Plane (DP) é encaminhar o tráfego do usuário entre portas diferentes. O DP não toma 
decisões sobre para qual porta um quadro deve ser encaminhado. Ele simplesmente executa pesquisas na 
Base de Dados de Encaminhamento (FDB). As entradas FDB indicam para qual porta, ou grupo de portas, 
cada quadro deve ser encaminhado e qual encapsulamento usar. Construir, ou preencher entradas no FDB, é 
uma função do Plano de Controle (CP), que é discutido na próxima seção.
O plano de dados SPB utiliza IEEE 802.1ah Provider Backbone Bridging (PBB), também conhecido como 
encapsulamento MAC-in-MAC. O cabeçalho PBB inclui os seguintes campos:
B-VID: Ou Backbone VLAN (BVLAN) ID. Uma VLAN que serve como uma VLAN de transporte para as 
instâncias de serviço SPB e para conectar pontes SPB por meio de conjuntos SPT. Ao contrário do domínio 
VLAN padrão que usa “flood and learn” ou source learning no DP para popular o FDB, o FDB do domínio 
BVLAN é pré-populado pelo CP.
ISID: Identificador de instância de serviço. O ISID é um número de 24 bits que designa a instância do serviço, 
locatário, contêiner ou VPN. Diferentes serviços SPB são atribuídos a diferentes ISIDs e isolados uns dos outros. 
Cada serviço SPB ou ISID está vinculado a uma BVLAN.
B-SA e B-DA: Ou endereços MAC de origem e destino do backbone. Os endereços MAC associados a nós SPB 
(BMACs). Dentro do backbone SPB, o tráfego é encaminhado com base no destino BMAC (B-DA). Os MACs 
internos do cliente não são aprendidos ou usados para encaminhamento dentro do backbone.
Resumo técnico
Guia de Shortest Path Bridging Architecture 9
Ethertype: 0x88E7
Ao entrar no domínio SPB, o cabeçalho PBB envolve o quadro de entrada, que pode ser desmarcado, único 
(IEEE 802.1q) ou duplo (IEEE 802.1ad). A Figura 5 ilustra o caso de um quadro com marcação dupla (Q-in-Q). 
Observe que os endereços MAC e BMAC
são encurtados para 2 bytes para simplificar neste diagrama.
Figura 5. Plano de dados PBB
Carga útil
Ethertype (IP)
C-VID
Ethertype 802.1q
S-VID
Ethertype 802.1ad
00:01
00:02
Carga útil Carga útil
Ethertype (IP) Ethertype (IP)
Carga útil Carga útil
C-VID
Ethertype 802.1q
S-VID
Ethertype 802.1ad
00:01
I-SID
Ethertype 802.1ah
B-VID
Ethertype 802.1ad
00: 0A
C-VID
Ethertype 802.1q
S-VID
Ethertype 802.1ad
00:01
Ethertype (IP)
C-VID
Ethertype 802.1q
00:01
00:02
Ethertype (IP)
C-VID
Ethertype 802.1q
00:01
00:0200:02 00: 0B 00:02
MAC: 00: 01 MAC: 00: 0A MAC: 00: 0B MAC: 00: 02
Cliente
rede
Ponte do provedor
rede
Backbone do provedor
rede de ponte
Ponte do provedor
rede
Cliente
rede
Vamos definir alguns termos-chave.
BEB: Um switch SPB posicionado na extremidade da rede PBB que aprende e encapsula (adiciona um 
cabeçalho de backbone 802.1ah a) frames do “cliente” para transporte através da rede de backbone. O BEB 
interconecta o espaço da rede do cliente com o espaço da rede PBB.
BCB: Um nó SPB que reside dentro do núcleo da rede PBB. O BCB emprega o mesmo BVLAN em duas ou mais 
portas de rede. Este BVLAN não termina no próprio switch; o tráfego recebido em uma porta de rede SPB é 
comutado para outras portas de rede SPB. Como resultado, o BCB não precisa aprender nenhum dos 
endereços MAC do cliente. Ele serve principalmente como uma ponte de trânsito para a rede PBB.
Dentro do domínio SPB, isto é, entre os nós BEB e BCB, o encaminhamento de quadros depende inteiramente 
do cabeçalho PBB 802.1ah externo (BMAC e BVLAN) e não do cabeçalho interno ou dos endereços MAC do 
“cliente” (CMAC). Na verdade, os nós de backbone SPB não aprendem CMACs e isso torna as redes SPB mais 
escaláveis e estáveis (CMACs não são aprendidos e, portanto, não precisam ser liberados e reaprendidos 
quando mudam ou se movem).
O DP implementa um mecanismo de mitigação de loop adicional pelo qual um nó não aceitará quadros 
inesperados de seus vizinhos. Este mecanismo de mitigação de loop adicional é mais rápido durante as 
mudanças de topologia. Em resumo, o SPB implementa dois mecanismos de prevenção de loop: prevenção 
de loop e mitigação de loop.
Resumo técnico
Guia de Shortest Path Bridging Architecture 10
5. O plano de controle: árvores de custo igual RFC 6329 IS-IS
Conforme afirmado anteriormente, a função do CP é preencher as tabelas FDB usadas pelo DP. O SPB usa IS-IS, ou 
Sistema Intermediário para Sistema Intermediário (ISO / IEC 10589: 2002); um protocolo bem conhecido, comprovado 
e amplamente implantado, particularmente em backbones de provedores de serviços. IS-IS é responsável pela 
topologia e descoberta de serviço. IS-IS é um protocolo de estado de link extensível que implementa o algoritmo 
Shortest Path de Dijkstra para computação de caminho. As extensões IS-IS para SPB são descritas na RFC 6329 e 
incluem um novo Network Layer Protocol Identifier (NLPID), bem como um conjunto de Type-Length-Values (TLVs). 
Em suma, essas extensões adicionam suporte para várias topologias, permitindo o compartilhamento de carga em 
vários caminhos de custo iguale descoberta de associação de serviço, ou em
outras palavras: Comunicar quais serviços estão habilitados em cada nó SPB.
Figura 6. Extensões RFC 6329 IS-IS
Novo!
Existir!
Extensões SPB
Descoberta e computação
NLPI, TLVs, PDUs
Descoberta - pacotes Hello e LSP, computação - SPF e SPT
SPB-ISIS
Ao contrário do STP, que cria uma única árvore com raiz na ponte raiz, nas redes SPB cada nó constrói uma 
árvore de topologia com raiz em si mesmo. Este é o principal motivo pelo qual, em uma rede SPB, o tráfego 
entre qualquer par de nós sempre viaja pelo caminho mais curto. Ao usar o STP, o tráfego entre dois nós não 
percorre necessariamente o caminho mais curto, a menos que um dos dois nós envolvidos seja a bridge raiz. 
Isso é ilustrado na figura 7, na qual B1 é a ponte raiz. O tráfego entre os nós B5 e B2, por exemplo, nenhum 
dos quais é a bridge raiz, não pode usar o caminho de salto único direto porque esse link está desabilitado 
pelo STP. Tráfego entre esses dois nós
deve fazer um desvio de 3 saltos atravessando a ponte raiz.
Figura 7. Árvores múltiplas
Spanning Tree
Ponte de raiz única
SPB
Cada ponte é a raiz
B2B2
B1 B5 B1 B5
B3 B3
B4 B4
Caminho B5 a B2 = B5 - B2Caminho B5 a B2 = B5 - B3 - B1 - B2
Em contraste, ao usar o SPB, nenhum link é desabilitado: cada nó é a raiz de sua própria árvore. Os nós B2 e B5 podem 
simplesmente se comunicar por meio do caminho de salto único direto enquanto, ao mesmo tempo, podem se 
comunicar com outros nós por meio de caminhos diferentes (por exemplo; entre B4 e B5). O suporte do SPB para várias 
árvores e vários caminhos ativos desbloqueia a utilização da largura de banda em caminhos ideais que, de outra forma, 
seriam desperdiçados, aumentando o rendimento e reduzindo a latência.
Uma rede SPB suporta até 16 BVLANs e cada nó constrói uma árvore SPF para cada BVLAN. O balanceamento de 
carga é realizado mapeando diferentes serviços de locatário (ISIDs) para diferentes BVLANs. O tráfego de serviço 
entre qualquer par de nós usa um único caminho e esse caminho muda apenas se a topologia mudar, por 
exemplo, na falha do nó ou do link e subsequente recálculo do caminho. Em outras palavras: as redes SPB não 
equilibram as cargas pacote a pacote como fazem as redes IP. Desde que a topologia física suporte vários 
caminhos mais curtos (mesmo custo e mesmo salto
Resumo técnico
Guia de Shortest Path Bridging Architecture 11
contagem) entre dois nós, diferentes BVLANs podem construir diferentes árvores e os serviços mapeados para essas 
BVLANs podem usar caminhos diferentes. E esses caminhos permanecerão os mesmos enquanto a topologia 
permanecer a mesma. Uma propriedade importante das redes SPB é que os caminhos da rede são determinísticos e 
os quadros são entregues na ordem em que foram enviados. Esta propriedade é importante
para determinados aplicativos, como armazenamento e tráfego de aplicativos em tempo real.
Figura 8. Uma árvore por nó e por BVLAN
Árvore de B1 no BVLAN A
B2
Árvore de B1 no BVLAN B
B2
Árvore de B1 em BVLAN C
B2
B1 B3 B5 B1 B3 B5 B1 B3 B5
B4 B4 B4
Árvore de B5 no BVLAN A
B2
Árvore de B5 em BVLAN B
B2
Árvore de B5 em BVLAN C
B2
B1 B3 B5 B1 B3 B5 B1 B3 B5
B4 B4 B4
As árvores mostradas na figura 8 são árvores de custo igual (ECTs) do SPB. Cada nó constrói uma árvore por 
BVLAN e o custo para alcançar outros nós é o mesmo em todas as BVLANs. O ECT-ID é um número atribuído a 
cada BVLAN no momento da criação da BVLAN e é usado para desempate durante o cálculo do caminho. Atribuir 
diferentes ECT-IDs a diferentes BVLANs ajuda essas BVLANs a construir árvores diferentes, desde que a 
topologia subjacente suporte múltiplos custos iguais ou caminhos mais curtos.
Outra propriedade importante das redes SPB é a simetria do caminho. Se você examinar atentamente a 
imagem acima, notará que o caminho do nó X ao nó Y é idêntico ao caminho do
nó Y a nó X. A simetria do caminho é a chave para Operações e Manutenção (OAM). Por exemplo, cálculos 
de atraso unilateral podem ser facilmente derivados de medições de atraso de ida e volta. Observe que 
esse não é o caso de outras tecnologias baseadas em IP, como MPLS, nas quais o caminho inverso pode ser 
diferente.
Resumo técnico
Guia de Shortest Path Bridging Architecture 12
Figura 9. Caminhos simétricos, balanceamento de carga por BVLAN
B1 <–> B5 caminho BVLAN A B1 <–> B5 caminho BVLAN B B1 <–> B5 caminho BVLAN C
B2 B2 B2
B1 B3 B5 B1 B3 B5 B1 B3 B5
B4 B4 B4
O resultado do cálculo do caminho IS-IS para cada BVLAN e nó é o FDB que é usado pelo plano de dados para 
o encaminhamento de quadros. A Figura 10 mostra o FDB unicast de BEB5. O FDB multicast irá
ser discutido na Seção 7.
Figura 10. Unicast FDB de B5
BVID
BVID A
BVID B
BVID C
BVID A
BVID B
BVID C
BVID A
BVID B
BVID C
BVID A
BVID B
BVID C
Nó
B1
B1
B1
B2
B2
B2
B3
B3
B3
B4
B4
B4
Porta de saída
Porta 1
Porta 2
Porta 3
Porta 1
Porta 1
Porta 1
Porta 2
Porta 2
Porta 2
Porta 3
Porta 3
Porta 3
B2
B1 B3 B5
B4
6. A estrutura de serviço
Um serviço SPB representa uma VPN, ou locatário, e é identificado exclusivamente por seu identificador de 
serviço, o ISID. Um serviço SPB só precisa ser criado, ou instanciado, em nós BEB, não em nós BCB, e apenas 
naqueles nós BEB que atendem aos locais de serviço associados ao serviço. As informações de associação de 
serviço SPB são compartilhadas através do backbone SPB por meio de IS-IS TLVs de modo que todos os nós 
SPB tenham uma visão consistente dos serviços que estão ativos em cada BEB. Cada nó
em seguida, constrói um banco de dados de serviço.
Figura 11. O banco de dados de serviço
ISID 66
B2
ISID
66
66
66
66
77
77
BVID
BVID A
BVID A
BVID A
BVID A
BVID B
BVID B
Nó
B1
B2
B4
B5
B1
B5
B1 B5
B3
ISID 66
ISID 77
ISID 66
ISID 77
B4
ISID 66
Resumo técnico
Guia de Shortest Path Bridging Architecture 13
Em cada nó BEB, existem dois tipos de portas virtuais:
Ponto de acesso de serviço: O SAP é uma porta lógica do lado UNI que vincula uma porta física e tipos de 
tráfego de cliente específicos (sem etiqueta, etiqueta única, etiqueta dupla ou todos) a um serviço SPB. Vários 
SAPs podem ser associados à mesma porta física, multiplexando e mapeando diferentes encapsulamentos de 
tráfego do cliente para diferentes serviços SPB.
Ponto de distribuição de serviço: O SDP é uma porta lógica do lado NNI que liga um serviço SPB a
um BEB de ponta remota no qual o serviço é instanciado. Os SDPs são criados dinamicamente no CP e apenas 
para os BEBs remotos com SAPs para o serviço específico.
Vejamos a figura 12. Neste diagrama, B5 encerra 2 serviços SPB: um está associado ao ISID 66 e o outro 
ao ISID 77. Existem duas portas SAP, uma para cada serviço. SAP 1: 1 é definido na porta 1, corresponde 
ao tráfego marcado com VLAN 1 e o vincula ao serviço 66. SAP 2: 2 é definido na porta 2, corresponde ao 
tráfego marcado com VLAN 2 e o vincula ao ISID 77.
O ISID 66 também está habilitado nos nós B1, B2 e B4, enquanto o ISID 77 também está habilitado no nó B1.
Figura 12. A estrutura de serviço
ISID 66
B2
Identificador
SAP 1: 1
SAP 2: 2
SDP 32769: 66
SDP 32768: 66
SDP 32767: 66
SDP 32766: 77
BVID
-
-
BVID A
BVID A
BVID A
BVID B
Nó
-
-
B1
B2
B4
B1
B1 B5
SDP X: 66
SDP X: 77
SAP 1: 1
SAP 2: 2
ISID 66
ISID 77
ISID 66
ISID 77
B4
ISID 66
Deve-se observar que, embora o aprendizado de endereço do BMAC seja realizado no CP (por exemplo; não por meio 
de “flood and learn”), o aprendizado de endereço do CMAC é realizado no DP do BEB por meio de flood e aprender. 
CMACs de ponta próxima são vinculados a portas SAP e CMACs de ponta remota são vinculados a portas SDP. Os nós 
BCB não têm portas SAP nem SDP e, portanto, não aprendem nenhum CMAC.
Vamos expandir este exemplo adicionando alguns sites de clientes finais e CMACs associados a esses clientes. 
Continuaremos usando endereços MAC de 2 bytes para simplificar. Na figura 13, os endereços CMAC da extremidade 
próxima são vinculados às portas SAP, enquanto os endereçosCMAC da extremidade remota são vinculados às portas 
SDP. Dentro do domínio de serviço, um BEB executa o aprendizado de endereço de origem CMAC como um switch 
Ethernet padrão, exceto que não há “inundação” de tráfego BUM. O tráfego BUM é discutido na próxima seção.
Figura 13. Aprendizagem do endereço MAC do cliente
ISID 66
B2
MAC B: B Identificador
SAP 1: 1
SAP 2: 2
SDP 32769: 66
SDP 32768: 66
SDP 32767: 66
SDP 32766: 77
ISID
66
77
66
66
66
77
CMAC
A: A
E: E
C: C
B: B
D: D
G: G
MAC C: C MAC A: A
B1 B5
SDP X: 66
SDP X: 77
SDP 1: 1
SDP 2: 2
MAC G: G ISID 66
ISID 77
ISID 66
ISID 77
MAC E: E
B4
ISID 66
MAC D: D
Resumo técnico
Guia de Shortest Path Bridging Architecture 14
SDP Y: 66
SDP Y: 66
SD
P Z
: 6
6
SD
P Z
: 6
6
7. Tráfego BUM
O SPB oferece suporte a 3 métodos de encaminhamento e replicação de tráfego BUM (broadcast, unicast 
desconhecido e multicast):
Head-end: Nesse modo, o tráfego BUM recebido em uma porta SAP é replicado no BEB de entrada e 
convertido em vários quadros unicast: uma réplica é criada para todos os outros BEB no mesmo ISID e essas 
réplicas têm os BMACs BEB como B-DA e são encaminhado usando o FDB unicast. Por esse motivo, a replicação 
Head-End pode ser ineficiente em termos de consumo de largura de banda, mas é eficiente em termos de uso 
de recursos porque não requer uma árvore separada. No entanto, a replicação head-end pode ser ideal em 
algumas circunstâncias, particularmente quando combinada com IGMP Snooping. O tráfego BUM replicado 
head-end simplesmente usa o FDB unicast e, portanto,
viaja pelo mesmo caminho. Essa propriedade é conhecida como congruência.
Figura 14. Replicação BUM Head-end
BCB2 BEB3
ISID 77 Modelo
você
você
você
você
você
você
B-MAC
00:02
00:03
00:04
00:05
00:06
00:07
Porta
Porta 2
Porta 7
Porta 7
Porta 7
Porta 6
Porta 7
BVID
BVID B
BVID B
BVID B
BVID B
BVID B
BVID B
BEB1 BCB7 BEB4
ISID 77 ISID 77
ISID 77
BCB6 BCB5
Tandem (S, G):Neste modo, um multicast SPT e FDB separados são criados. O multicast SPT também é 
congruente com o unicast SPT, porém os B-DAs no multicast FDB são endereços multicast construídos como uma 
combinação de ISID e BEB BMAC de origem. Quando um quadro BUM é recebido em um BEB, ele é MAC-in-MAC 
encapsulado com este BMAC especial como o B-DA e encaminhado de acordo com o FDB multicast. O nó AB pode 
usar o FDB unicast para verificar se ele está no SPT entre um BEB de origem e outros BEBs no mesmo ISID. Se o 
nó B estiver no SPT, ele preencherá o FDB multicast de forma que o quadro seja replicado e encaminhado 
conforme necessário, para outros BEBs conectando-se ao mesmo serviço (ISID). A replicação em tandem é muito 
eficiente em termos de uso de largura de banda porque enviará apenas uma única réplica em um determinado 
link; Contudo,
use porque requer um SPT adicional e FDB multicast por ISID.
Figura 15. Replicação BUM em tandem (S, G)
Modelo
você
você
você
você
você
você
M
M
M
M
B-MAC
00:01
00:02
00:03
00:04
00:05
00:06
00: 0W
00: 0X
00: 0Y
00: 0Z
Porta
Porta 1
Porta 2
Porta 3
Porta 4
Porta 5
Porta 6
Porta 1
Porta 3
Porta 4
Porta 5
BVID
BVID B
BVID B
BVID B
BVID B
BVID B
BVID B
BVID B
BVID B
BVID B
BVID B
Out Intf
BCB2 BEB3
ISID 77
BEB1 BCB7 BEB4
ISID 77 ISID 77
Porta 3/4/5
Porta 1/5
Porta 1
Porta 1/3
ISID 77
BCB6 BCB5
Resumo técnico
Guia de Shortest Path Bridging Architecture 15
Tandem (*, G): Neste modo, uma árvore multicast separada é criada. Esta árvore não é uma árvore de caminho 
mais curto e não é congruente com o SPT unicast. Um multicast (*, G) é criado para cada BVLAN usando a 
replicação multicast Tandem (*, G). Esta árvore (*, G) é semelhante a uma Spanning Tree e tem sua raiz em um 
nó B de acordo com a prioridade da ponte. Neste modo, existe uma única árvore para a BVLAN e não uma árvore 
para cada nó. Portanto, o tráfego geralmente não segue o caminho mais curto. Este modo é um meio termo 
entre largura de banda e uso de recursos, no entanto, pode ser uma boa opção quando
todo o tráfego é originado ou destinado à bridge raiz. Consulte a 
Tabela 1 para comparar esses três modos.
Tabela 1. Modos de replicação multicast e usos sugeridos
Head-end Tandem (S, G) Tandem (*, G)
Operação Tráfego BUM replicado no 
ingresso BEB e encaminhado 
usando o FDB unicast.
Tráfego BUM encaminhado pelo FDB 
multicast e replicado conforme 
necessário nos pontos de fork-out do 
SPT.
Tráfego BUM encaminhado usando uma 
árvore compartilhada não SP e replicado 
em pontos de bifurcação.
Eficiência de largura de banda
Eficiência de recursos
Congruência
Uso sugerido
Baixo
Alto
sim
Alto
Baixo
sim
• Alta largura de banda multicast
Alto
Médio
Não
• Quando a bridge raiz é• Baixa largura de banda multicast
• Muitas fontes e poucos 
receptores *
• Poucas fontes e muitos receptores fonte ou receptor da maior 
parte do tráfego multicast
e congruência não é 
necessária
• Quando necessário para 
interoperar com 
equipamentos de terceiros
* Quando combinado com IGMP Snooping.
8. Criação de um backbone SPB
Nesta seção, fornecemos um exemplo de configuração do Backbone SPB e nos referimos à figura 16 como 
um exemplo de topologia. Continuaremos usando essa topologia de amostra no restante deste documento. 
Os nós BEB-1 a BEB-4 são chamados de nós “BEB” porque adicionaremos serviços a esses nós 
posteriormente. O nó BCB permanecerá um nó de trânsito puro e não encerrará nenhum serviço.
Se você observar esta topologia, notará que ela fornece até 3 caminhos mais curtos, por exemplo, entre os nós 
BEB-1 e BEB-3, ou entre os nós BEB-2 e BEB-4. Para tirar proveito desses 3 caminhos diversos para 
balanceamento de carga de tráfego, precisamos criar um mínimo de 3 BVLANs. Neste exemplo, no entanto, 
dedicaremos uma BVLAN puramente para controlar o tráfego e, portanto, criaremos um total de 4 BVLANs. No 
entanto, deve-se notar que isso não é estritamente necessário,
o controle BVLAN também pode ser usado para serviços.
A configuração do backbone envolve as seguintes tarefas:
• Criação de um ou mais BVLANs com seus ECT-IDs associados. Os ECT-IDs não precisam ser definidos 
explicitamente, os ECT-IDs padrão são aplicados
• Definindo o controle BVLAN
• Definição de uma ou mais interfaces SPB IS-IS
• Habilitando o protocolo SPB IS-IS
Resumo técnico
Guia de Shortest Path Bridging Architecture 16
Figura 16. Amostra de topologia de backbone
BEB2
1/1 / 54A
BEB1 1/1 / 50A
1/1 / 52A
BEB3
1/1 / 54A 1/1 / 49A 1/1 / 54A
BCB
1/1 / 53A
1/1 / 54A
BEB4
A seguir estão os snippets de configuração para todos os nós.
Snippet 1. Configuração de backbone do BEB-1
Snippet 2. Configuração de backbone do BEB-2
Snippet 3. Configuração de backbone do BEB-3
Snippet 4. Configuração de backbone do BEB-4
Resumo técnico
Guia de Shortest Path Bridging Architecture 17
1/1 / 50A
1/1 / 50A
1/1 / 50A
1/1 / 49A1/1
 / 4
9A
1/1
 / 4
9A
Snippet 5. Configuração do backbone BCB
Por meio dessa configuração, as VLANs 4000 a 4003 são definidas como VLANs de backbone SPB e, portanto, não 
usarão nenhuma forma de protocolo de árvore estendida. O AOS atribui automaticamente um ECT-ID diferente 
para cada BVLAN e isso maximiza a chance de que diferentes BVLANs criarão diferentes SPTs, até o número 
máximo de caminhos mais curtos suportados pela topologia física. Os nós trocarão mensagens “Hello” do IS-IS 
no BVLAN de controle (como 4000 neste exemplo) e formarão adjacências ponto a ponto. LSPs são trocados, um 
banco de dados de topologia é criado e um SPT é construído para cada BVLAN.
Vamos revisar esta configuração com alguns comandos show.
Snippet 6. “show SPB isis interface”
Na saída do comando “show spb isis interface”, podemos observar que três interfaces são SPB-ISIS habilitadas para 
adjacências L1. Todas as três interfaces estão ativas administrativa e operacionalmente. Por padrão, a métrica do 
link é 10, independentemente da velocidade do link. As mensagens “Hello” são enviadas em intervalosde nove 
segundos e as adjacências são declaradas perdidas se nenhuma mensagem “Hello” for recebida em três intervalos 
consecutivos (por exemplo; 27 segundos).
Snippet 7. “show SPB isis nodes”
Na saída do comando “show spb isis nodes”, podemos observar todos os nós SPB IS-IS descobertos, incluindo o 
nó local. Para cada nó, podemos ver o sistema ou nome do host, o ID do sistema (o BMAC), bem como o ID de 
origem e a prioridade da ponte. O ID de origem é um identificador de 20 bits que designa o nó como a origem 
do tráfego BUM e é derivado do menor ID do sistema
bytes significativos. O ID de origem é relevante ao usar a replicação BUM em tandem. A prioridade da ponte é um 
identificador de 16 bits e é usada como um desempatador durante a computação do caminho.
Resumo técnico
Guia de Shortest Path Bridging Architecture 18
Snippet 8. “show SPB isis adjacency”
Na saída do comando “show spb isis adjacency”, podemos observar todas as adjacências SPB IS-IS 
estabelecidas pelo nó local. Para cada adjacência, podemos ver o sistema ou nome do host,
o ID do sistema (o BMAC), bem como o tipo (sempre L1 para SPB IS-IS), o estado, o temporizador de espera 
(número de segundos até que a adjacência seja declarada perdida se nenhuma mensagem “Hello” for 
recebida) e a interface sobre o qual a adjacência é formada.
Snippet 9. “show SPB isis bvlans”
Na saída do comando “show spb isis bvlans” podemos observar, para cada BVLAN configurada, o algoritmo ECT 
em uso e se a BVLAN está em uso e possui serviços mapeados para ela. Até o momento não configuramos 
nenhum serviço, portanto a única BVLAN em uso é a BVLAN de controle, que é utilizada para mensagens IS-IS 
CP. Também podemos observar o número de ISIDs mapeados para o BVLAN. Para serviços que usam replicação 
BUM em tandem, podemos observar se é (S, G), que é o padrão, ou (*, G). Observe que, embora a escolha de 
replicação head-end versus tandem seja feita por serviço, a escolha entre replicação tandem (S, G) e (*, G) é feita 
por BVLAN. Por último,
o BMAC de bridge raiz é mostrado apenas para aqueles BVLANs usando replicação em tandem (*, G).
Snippet 10. “show SPB isis unicast-table”
Resumo técnico
Guia de Shortest Path Bridging Architecture 19
Na saída do comando “show spb isis unicast-table”, podemos observar, para cada nó, a interface de saída 
usada ao enviar tráfego unicast para esse nó. Observe que a interface de saída pode ser diferente para 
diferentes BVLANs porque diferentes BVLANs podem construir diferentes SPTs. Por exemplo, o caminho 
para BEB-3 passa pela interface 1/1 / 49A no caso de BVLAN
4000, interface 1/1 / 54A no caso de BVLANs 40001 e 4002, e interface 1/1 / 50A no caso de BVLAN 4003.
Snippet 11. “show SPB isis spf bvlan”
Na saída do comando “show spb isis spb bvlan” podemos observar, para um determinado BVLAN, a interface de 
saída, o próximo nó de salto, bem como a métrica SPB e o número total de saltos necessários para atingir um nó 
de destino. Podemos observar nesta saída que o tráfego com destino a BEB-3 transitará por BEB-2 no caso do 
BVLAN 4000, BCB no caso dos BVLANs 4001 e 4002 e BEB-4 no caso do BVLAN 4003.
9. Serviços L2
Um serviço L2 refere-se a um tipo de serviço VPN que conecta vários sites em um único domínio de ponte 
qualquer-para-qualquer. Nesta seção, continuamos construindo sobre o exemplo anterior e criamos um 
serviço L2 em cima da configuração de backbone criada anteriormente.
Os serviços só precisam ser criados em BEBs, não em BCBs, e apenas naqueles BEBs onde o serviço precisa ser 
prestado. A criação de um serviço SPB envolve as seguintes tarefas:
• Criar um serviço e associar o serviço a um IS-IS e BVLAN - as BVLANs especificadas
SPF será usado para o tráfego do serviço
• Definindo uma Porta de Acesso de Serviço (SAP)
• Definição de SAPs correspondentes ao tráfego de clientes específicos
Resumo técnico
Guia de Shortest Path Bridging Architecture 20
Figura 17. Serviço L2
Site 2
01/01/48
BEB2
BEB1 BEB3
01/01/48 ISID 1001
BVLAN 4001
1/1 / 54A 01/01/48
Site 1 Site 3
BEB4
01/01/48
Site 4
Com relação à figura 17, fornecemos as configurações do BEB nos trechos a seguir. Além disso, 
observe:
• O número de serviço é significativo apenas localmente e pode diferir entre diferentes BEBs
• O número ISID é globalmente significativo e deve corresponder a todos os BEBs que conectam um 
determinado serviço
• A BVLAN que o serviço é mapeado também deve corresponder em todos os BEBs que conectam um 
determinado serviço
• Diferentes serviços podem ser mapeados para diferentes BVLANs para atingir o balanceamento de carga de tráfego
Snippet 12. Configuração de serviço do BEB-1
Snippet 13. Configuração de serviço do BEB-2
Snippet 14. Configuração de serviço do BEB-3
Snippet 15. Configuração de serviço do BEB-4
Resumo técnico
Guia de Shortest Path Bridging Architecture 21
Nos quatro snippets de configuração acima, podemos observar o seguinte:
• O serviço 1 está associado ao ISID 1001 e mapeado para a árvore SPF do BVLAN 4001
• A porta 1/1/48 é definida como SAP
• Um SAP é definido na porta 1/1/48 mapeando o tráfego não marcado (: 0) para o serviço 1
Vamos agora verificar o status do serviço.
Snippet 16. “show service spb” - visualização BEB
Na saída do comando “show service spb” podemos observar, para um determinado BEB, os serviços SPB 
definidos localmente, seu status administrativo e operacional, o número de SAPs (locais) e SDPs (remotos) junto 
com o número ISID e BVLAN que o serviço está mapeado. Também podemos observar o modo de replicação 
multicast, que é head-end por padrão. O modo de replicação multicast pode ser alterado para tandem por 
serviço.
Snippet 17. “show service spb” - visualização BCB
Na saída do comando “show service spb” podemos observar que, por definição, um BCB não possui serviços 
definidos localmente.
Snippet 18. “show spb isis services” - visualização BEB
Na saída do comando “show spb isis services”, podemos observar os serviços SPB conhecidos para o nó junto 
com seu número ISID e BVLAN e o nome do nó, e BMACs nos quais o serviço está habilitado. Devemos notar que 
estes serviços são aprendidos graças ao IS-IS CP. Um “*” indica que o serviço também corresponde a um serviço 
criado localmente no BEB.
Resumo técnico
Guia de Shortest Path Bridging Architecture 22
Snippet 19. “show spb isis services” - visão BCB
Na saída do comando “show spb isis services” podemos observar a mesma saída agora da perspectiva de um 
BCB. Devemos observar que o BCB ainda está ciente de todos os serviços existentes com o IS-IS CP.
Snippet 20. “show service spb”
A saída do comando “show service spb” fornece alguns detalhes adicionais sobre um determinado serviço 
SPB. Podemos destacar o seguinte:
• RemoveIngressTag: Conforme explicado na seção 3, por padrão, um quadro PBB inclui todas as tags 
originais do quadro. No entanto, podemos escolher remover essas tags com o “serviçoservice_id
comando remove-ingress-tag enable ”.
• Tradução de VLAN: Um determinado serviço pode exigir diferentes encapsulamentos em diferentes SAPs. Por exemplo, 
um servidor pode marcar o tráfego com uma VLAN específica, enquanto os dispositivos cliente podem exigir
SAPs não marcados. Em tal situação, a tradução de VLAN pode ser habilitada para permitir que ambos 
os dispositivos se comuniquem. Devemos observar que a tradução de VLAN deve ser habilitada tanto 
no nível de serviço com o comando “serviçoservice_id vlan-translation enable ” e no SAP com o 
comando “service access port vlan-xlation enable”.
• Tipo de Alocação: Os serviços podem ser criados estaticamente ou dinamicamente. Abordaremos a 
criação dinâmica de serviços na seção 13.3.
Snippet 21. “mostrar acesso ao serviço”
Resumo técnico
Guia de Shortest Path Bridging Architecture 23
Na saída do comando “show service access” podemos observar, para um determinado BEB, a lista de SAPs 
juntamente com seu tipo (manual ou dinâmico), o número de SAPs definidos e se a tradução de VLAN está 
habilitada ou não. Abordaremos a criaçãodinâmica de SAP na seção 12.2. Também podemos observar o 
L2Profile atribuído ao SAP. O L2Profile define como os quadros de protocolo de controle L2 recebidos em um 
SAP serão tratados. O tráfego pode ter peering, drop ou tunelamento. As configurações de perfil L2 padrão são 
mostradas na Tabela 2. Perfis L2 adicionais podem ser criados com o comando “serviço l2profile nome stp ação 
802.3ad ação mvrp ação gvrp ação amap ação 802.1ab ação” e atribuídos ao SAP com o comando “ acesso ao 
serviço l2profile
nome". Abordaremos os SAPs e perfis na seção 12.2.
Tabela 2. Perfis L2 padrão
Protocolo perfil de acesso-def unp-def-access-profile
STP
802.1x
802.3ad
MVRP
GVRP
UM MAPA
802.1ab
túnel
solta
par
túnel
túnel
solta
solta
solta
par
par
túnel
túnel
solta
solta
Snippet 22. “show service spb ports”
Na saída do comando “show service spb ports”, podemos observar as portas locais (SAP) e remotas (SDP) para 
um determinado serviço. Para cada porta, podemos ver o status administrativo e operacional, o ID do sistema 
(BMAC) e BVLAN, bem como o nome do sistema e interface local associada. As portas SDP sempre exibirão um 
“*” próximo a elas porque as portas SDP são sempre criadas dinamicamente
pelo IS-IS CP. O nome de um SDP é uma combinação de um número gerado dinamicamente, seguido 
por dois pontos e o número do serviço.
Resumo técnico
Guia de Shortest Path Bridging Architecture 24
Snippet 23. “show service mesh-sdp spb”
Na saída do comando “show service mesh-sdp spb”, podemos observar os SDPs da extremidade oposta para cada 
serviço junto com o número ISID e o ID do sistema da extremidade oposta (BMAC), BVLAN, nome do sistema e 
interface associada.
Snippet 24. “show mac-learning domain spb” - visualização BEB
Na saída do comando “show mac-learning domain spb”, podemos observar a lista de endereços CMAC 
aprendidos no domínio SPB junto com o número do serviço e ISID, bem como a porta de interface (SAP 
ou SDP) à qual o endereço CMAC está vinculado para.
Snippet 25. “show mac-learning domain spb” - visão BCB
Na saída do comando “show mac-learning domain spb”, podemos observar a mesma saída agora do ponto de 
vista de um nó BCB. Como esperado, os nós do BCB não aprendem nenhum CMAC.
Resumo técnico
Guia de Shortest Path Bridging Architecture 25
10. Conceitos de roteamento
Antes de nos aprofundarmos nos serviços L3, que são abordados na próxima seção, precisamos discutir certos 
conceitos de roteamento em relação ao SPB. A linha de produtos Alcatel-Lucent OmniSwitch® tem suporte para 
SPB desde AOS 7.3.1, lançado em 2012. Desde então, várias plataformas habilitadas para SPB foram lançadas e 
cada nova plataforma incorporou novos avanços em ASICs.
Os ASICs de primeira geração não eram capazes de rotear e realizar o encapsulamento MAC-in-MAC em uma 
operação de passagem única. Conseqüentemente, o roteamento entre as interfaces IP associadas a dois 
serviços SPB diferentes, ou para uma VLAN e um serviço SPB, teve que atravessar a malha de switch duas vezes. 
Isso exigia um loopback físico externo conectando duas portas de switch diferentes: uma porta no domínio 
VLAN e outra SAP no domínio SPB. As interfaces IP só podem ser associadas a uma VLAN, não diretamente a um 
serviço SPB. Deve-se observar que esses loopbacks físicos podem ser portas físicas ou linkaggs. Ao usar o VC, as 
portas do membro linkagg podem abranger diferentes unidades no VC para redundância. Chamamos isso de 
roteamento de duas passagens com loopback físico externo.
A geração mais recente de ASICs oferece suporte a um conceito semelhante a um loopback físico externo sem 
a necessidade de uma conexão de cabo. A largura de banda de uma ou mais portas físicas é dedicada à 
função de loopback sem a necessidade de conectar um cabo. Múltiplas portas podem ser dedicadas a esta 
função para largura de banda adicional e redundância. Ao usar portas múltiplas, as portas são configuradas 
como linkagg e, ao usar VC, as portas membro linkagg podem abranger unidades diferentes no VC. 
Chamamos isso de roteamento de duas passagens com loopback interno do painel frontal. Uma diferença 
adicional entre o loopback interno do painel frontal e o loopback físico externo descrito no parágrafo anterior 
é que o loopback interno do painel frontal é uma única porta lógica, não duas portas (uma porta VLAN e uma 
SAP) como no caso de o loopback físico externo. Contudo, mesmo na única porta lógica, há uma função 
“VLAN” e uma função “SAP”. Isso ficará mais claro ao examinar os trechos de configuração posteriormente 
nesta seção.
Os ASICs de última geração suportam roteamento e bridging integrados no domínio SPB exatamente da 
mesma maneira que no domínio VLAN. Isso significa que as interfaces IP podem ser associadas a um serviço 
SPB diretamente e o tráfego pode ser roteado entre dois serviços SPB ou entre uma VLAN e um serviço SPB em 
uma operação de passagem única sem loopbacks. Nós nos referimos a isso como passagem única
roteamento inline.
Figura 18. Opções de roteamento - visão física
Passagem única
ou em linha
Duas passagens com externo
loopback físico
Duas passagens com interno
loopback físico
ISID 1 VLAN + SAP
tudo em um
porto ou LAG
Porta VLAN
01/01/1
Porta SAP
1/1/2
ISID 2 ISID 1 ISID 1
VLAN 1 VLAN 1
VLAN 1
A Figura 18 fornece uma visão física dessas opções de roteamento. O diagrama mais à esquerda representa um 
switch com suporte para roteamento em linha de passagem única. Este exemplo mostra uma ponte com 2 serviços 
SPB, designados por seus ISIDs e uma VLAN. As interfaces IP são representadas por pontos. Como podemos ver,
as interfaces IP são vinculadas a VLANs ou serviços e o switch executa o roteamento inter-VLAN, inter-
Service ou inter-VLAN-Service diretamente em uma única operação.
Resumo técnico
Guia de Shortest Path Bridging Architecture 26
VL
AN
 1
1
VL
AN
 1
1
O diagrama do meio ilustra o caso de roteamento de duas passagens com um grampo de cabelo físico. Neste 
diagrama, você pode observar que as interfaces IP estão vinculadas à VLAN 1 e à VLAN 11, mas não diretamente 
ao serviço. O cabo de loopback físico externo cria o link entre o serviço e a VLAN “fictícia”, VLAN 11 neste 
exemplo, onde reside a interface IP. Este loopback físico externo é configurado com um lado SAP, onde SAPs são 
definidos para cada serviço que requer roteamento, e um lado VLAN, onde mapeamento de VLANs fictícios para 
esses serviços são marcados.
O diagrama à direita ilustra o caso de roteamento de duas passagens com loopback interno do painel frontal. 
Neste diagrama, a linha pontilhada representa um loopback externo físico imaginário, o que não é 
necessário. Além de não exigir um cabo de loopback físico externo, o loopback do painel frontal requer no 
mínimo uma porta apenas. A configuração CLI é diferente entre o loopback externo físico e o loopback 
interno do painel frontal. No entanto, os conceitos são muito semelhantes. Você ainda deve pensar sobre a 
porta ou portas de loopback interno do painel frontal como tendo um SAP
e uma função VLAN, tudo em uma porta ou linkagg.
Figura 19. Opções de roteamento - visão lógica
Passagem única
ou em linha
Duas passagens com externo
loopback físico
Duas passagens com interno
loopback físico
ISID 1 VLAN + SAP
tudo em uma portaPorta VLAN Porta SAP
ISID 2 ISID 1 ISID 1
VLAN 1 VLAN 1
VLAN 1
A Figura 19 fornece uma representação lógica dessas opções. O diagrama à esquerda representa o caso de 
roteamento de passagem única ou em linha. Nestes produtos, as funções de roteamento e bridging são totalmente 
integradas no domínio do serviço exatamente da mesma maneira como são integradas no domínio VLAN. Por esse 
motivo, esses produtos são representados por um ícone de roteador.
O diagrama do meio representa o caso de roteamento de duas passagens com um loopback físico externo. 
Nestes produtos, as funções de roteamento e ponte são separadas e representadas por ícones de roteador 
e ponte. Você pode observar que a função de roteador, onde existem pontos que representaminterfaces IP, 
se conecta à função de ponte usando uma porta VLAN e um SAP.
O diagrama à direita ilustra o caso de roteamento de duas passagens com loopback interno do painel frontal. 
Como você pode ver, este caso é quase igual ao caso de roteamento de duas passagens com um loopback 
físico externo de um ponto de vista lógico. No entanto, a função de roteamento se conecta à função de ponte 
usando uma única porta ou grupo de portas. Esta porta de loopback do painel frontal ou grupo de portas ainda 
executa uma função SAP e uma função VLAN. Além disso, esta conexão entre as funções de roteamento e 
ponte é criada internamente no switch ASIC e não requer um
cabo externo.
Vamos revisar alguns exemplos de configuração para confirmar esses conceitos.
Snippet 26. Exemplo de passagem única ou de roteamento em linha
Resumo técnico
Guia de Shortest Path Bridging Architecture 27
VL
AN
 1
1
VL
AN
 1
VL
AN
 1
1
VL
AN
 1
O fragmento de configuração 26 mostra que, em produtos que suportam roteamento de passagem única ou em 
linha, as interfaces IP podem ser vinculadas a serviços da mesma forma que podem ser vinculadas a VLANs. O switch 
simplesmente executa o roteamento no mesmo domínio (VLAN ou serviço) ou entre domínios diferentes (VLAN e 
serviço). Observe que o backbone e a configuração do serviço não são mostrados neste exemplo.
Snippet 27. Roteamento de duas passagens com exemplo de loopback físico externo
O fragmento de configuração 27 mostra a configuração equivalente para produtos que suportam roteamento 
de duas vias com loopback físico externo. Uma vez que as interfaces IP não podem ser vinculadas a um serviço 
diretamente, criamos 2 VLANs “fictícios” adicionais para vincular essas interfaces. A VLAN 11 será associada ao 
serviço 1 e a VLAN 12 será associada ao serviço 2. O loopback físico externo usa a porta 1/1/1 como porta VLAN 
e a porta 1/1/2 como SAP. Ao criar as interfaces IP vinculadas a essas VLANs fictícias, usamos a opção rtr-port. 
Isso evita que essas VLANs sejam vinculadas a outras portas e desabilita o STP nessas VLANs. Observe que, 
conforme explicado anteriormente, linkaggs podem ser usados em vez de portas únicas e portas membro 
linkagg podem abranger diversas unidades em um VC para redundância.
Snippet 28. Roteamento de duas passagens com exemplo de loopback do painel frontal interno
O fragmento de configuração 28 mostra a configuração equivalente para produtos que suportam roteamento 
de duas vias com loopback interno do painel frontal. Em primeiro lugar, a porta 1/1 / 51A é designada como a 
porta de loopback do painel frontal. VLANs fictícias são criadas e SAPs que ligam essas VLANs fictícias a seus 
serviços associados são definidos na porta de loopback. Ao criar as interfaces IP vinculadas às VLANs fictícias, 
usamos a opção rtr-port e referenciamos a porta de loopback. Outra vez,
o exemplo mostra o caso de uma única porta de loopback do painel frontal, mas os linkaggs podem ser usados 
para largura de banda adicional e resiliência no caso de VC.
Resumo técnico
Guia de Shortest Path Bridging Architecture 28
11. Serviços L3
Um serviço L3 se refere a um tipo de serviço VPN que conecta vários sites em um único domínio de roteamento 
qualquer para qualquer. Sites diferentes utilizam sub-redes diferentes e requerem roteamento para se 
comunicarem. Para multilocação e para manter diferentes clientes isolados em L3, cada serviço ao cliente é
associado à sua própria instância VRF.
Figura 20. Serviço L3 do cliente A
10.0.1.0/24 BEB1 BEB2 10.0.2.0/24
. 254 . 254
. 1 . 2
Site 1 Site 2
10.0.0.0/24
SPB Service A
VRF A
10.0.3.0/24 10.0.4.0/24
. 254 . 254
. 3 . 4
Site 3 Site 4BEB3 BEB4
A Figura 20 ilustra um exemplo de um Serviço L3 conectando quatro dos sites do cliente A: Sites 1 a
4. Você notará que cada site usa uma sub-rede diferente e, portanto, o roteamento entre sites é necessário. Os nós BEB 
que conectam as instalações do cliente são representados com ícones de roteador para simplificar. Esses BEBs têm uma 
interface voltada para “LAN” que atua como o gateway padrão do site local, bem como uma interface voltada para 
“WAN” para alcançar sites remotos. Todas as interfaces “WAN” estão vinculadas a um único serviço SPB e estão na 
mesma sub-rede “WAN”. Por último, todas as interfaces LAN e WAN IP associadas ao cliente A são vinculadas ao mesmo 
cliente A VRF para fornecer isolamento L3 entre diferentes clientes.
Os serviços de VPN L3 baseados em SPB contam com roteamento de borda: o roteamento é executado apenas na 
entrada e saída de BEBs e com ponte entre eles. Em L3, a WAN representa um único salto L3, independentemente do 
número de saltos L2 intermediários (BCBs) entre eles. O SPB simplesmente conecta o tráfego do BEB de entrada ao BEB 
de saída ao longo do caminho mais curto.
Até este ponto, descrevemos apenas o DP. E quanto ao CP? No nível CP, os serviços L3 VPN vêm em duas 
variantes: VPN Lite e L3 VPN. Vamos elaborar essas duas variantes.
11.1 VPN Lite
Um serviço VPN Lite L3 é criado sobrepondo um protocolo de roteamento L3 no topo do serviço L2 WAN SPB. 
Este protocolo de roteamento pode ser OSPF, BGP ou até mesmo roteamento estático. O protocolo de 
roteamento é executado dentro do VRF do cliente e uma instância separada e configuração associada é criada 
para cada cliente. A Figura 21 mostra um exemplo de como o serviço L3 do cliente A pode ser criado
como um serviço VPN Lite executando OSPF em nós BEB.
Figura 21. Serviço VPN Lite do cliente A
10.0.1.0/24 BEB1 BEB2 10.0.2.0/24
. 254 . 254
. 1 . 2
Site 1 Site 2
SPB Service A
VRF A
OSPF área 0
10.0.0.0/24
10.0.3.0/24 10.0.4.0/24
. 254 . 254
. 3 . 4
Site 3 Site 4BEB3 BEB4
Resumo técnico
Guia de Shortest Path Bridging Architecture 29
Devemos destacar que, em um tipo VPN Lite de serviço L3, o serviço L2 SPB simplesmente fornece conectividade 
L2 às interfaces IP “WAN”. Continuando com o OSPF como exemplo, isso significa que o OSPF está configurado 
normalmente. Além disso, como todas as interfaces WAN IP estão conectadas a um único serviço L2 SPB, no 
caso do OSPF, uma escolha de DR / BDR ocorrerá como de costume.
11.2 VPN L3
O SPB L3 VPN aproveita a instância SPB IS-IS existente para transportar as rotas VPN do cliente sem exigir 
um protocolo de roteamento adicional, como OSPF. Isso é realizado com extensões IS-IS TLVs adicionais. 
Devemos observar que cada cliente ou locatário ainda está associado ao seu
Os próprios VRF e IS-IS TLVs fazem referência ao ISID do cliente para preservar o isolamento L3 entre diferentes 
clientes ou locatários. Este mecanismo é descrito em um rascunho da IETF [1]. Consulte a figura 22.
Para aqueles familiarizados com MPLS ou EVPN, essas tecnologias contam com um IGP (por exemplo; OSPF ou 
IS-IS) para acessibilidade de nó de backbone e MP-BGP (RFC 4760) para transporte de rota VPN do cliente. No 
SPB L3 VPN, o IS-IS pode desempenhar ambas as funções; acessibilidade de nó de backbone e transporte de rota 
VPN do cliente. Usar um único protocolo em vez de dois resulta em uma rede mais simples de implantar e 
operar.
Além disso, ao comparar SPB e MPLS, os nós SPB BEB desempenham uma função semelhante aos nós MPLS PE, 
enquanto os nós SPB BCB são semelhantes aos nós MPLS P. Em particular, os nós SPB BCB não aprendem nenhuma 
rota VPN do cliente e não exigem que VRFs sejam criados neles. Os VRFs precisam ser criados apenas em nós BEB e as 
rotas VPN do cliente são aprendidas apenas nos BEBs aos quais esses clientes se conectam.
Figura 22. Serviço de VPN L3 do cliente A
10.0.1.0/24 BEB1 BEB2 10.0.2.0/24
. 254 . 254
. 1 . 2
Site 1 Site 2
SPB Service A
VRF A
SPB IS-IS
10.0.0.0/24
10.0.3.0/24 10.0.4.0/24
. 254 . 254
. 3 . 4
Site 3 Site 4BEB3 BEB4
Ao contrário do caso de um VPN Lite, um SPB L3 VPN não requer a adição de nenhum protocolo de roteamento. 
As rotas VRF do cliente são exportadas para a instância SPB IS-IS, associada ao ISID do cliente e vinculadas ao IP 
WAN como um endereço de gateway. Os BEBs de ponta remota importarão essasrotas para sua tabela de 
roteamento VRF local. Portanto, essas rotas apontarão para o endereço IP WAN como o próximo salto. Devemos 
observar que este mecanismo é aplicável e idêntico para IPv4 e IPv6. Isso é ilustrado na figura 23 da perspectiva 
do BEB-1. Devemos observar essa rota-
os mapas podem ser usados para filtragem de rota de baixa granularidade.
Figura 23. Importação / Exportação de Rota
Exportar rotas VRF do cliente local para SPB IS-IS, associar ao 
ISID do cliente e vincular ao endereço WAN
10.0.1.0/24 BEB1
. 254
. 1 SPB Service A
VRF A
SPB IS-IS
10.0.0.0/24
Site 1
Importe rotas SPB IS-IS de ponta remota associadas ao ISID do cliente para o VRF do 
cliente e defina o endereço IP WAN de ponta remota como próximo salto
Resumo técnico
Guia de Shortest Path Bridging Architecture 30
Um serviço VPN L3 baseia-se em um serviço L2 e envolve as seguintes etapas:
• Criação de um serviço L2 SPB
• Criação de um locatário VRF
• Criação de interfaces IP do lado da LAN e do lado da WAN no VRF do locatário. As interfaces IP do lado da LAN 
normalmente residem em uma VLAN. As interfaces IP do lado WAN podem residir diretamente nos próprios serviços 
SPB em produtos que suportam roteamento em linha de passagem única ou em uma VLAN “fictícia” em produtos que 
requerem loopback físico externo ou interno no painel frontal.
• Ligar a interface WAN IP ao ISID do serviço L2 SPB
• Importação / exportação de rotas entre a tabela de roteamento VRF local e a instância IS-IS ISID do SPB
Vamos voltar ao exemplo de topologia usado para serviços L2 na seção 9 e configurar um serviço VPN L3 
para que possamos dar uma olhada na configuração. Veremos dispositivos com suporte interno
loopback do painel frontal.
Figura 24. Exemplo de serviço VPN L3
Site 2
192.168.22.0/24
01/01/48
. 254
BEB2
. 2
BEB1 ISID 1002
VRF A
BVLAN 4002
BEB3 10.0.2.0/24
01/01/48
. 254
01/01/48
. 1 192.168.30.0/24 . 3 . 254
Site 1
192.168.21.0/24
Site 3
192.168.23.0/24
. 4
BEB4
. 254
01/01/48
Site 4
192.168.24.0/24
Agora forneceremos trechos de configuração para todos os BEBs. Como sua contraparte L2, os serviços de VPN 
L3 não requerem configuração em BCBs. Vamos fornecer alguns detalhes sobre este exemplo:
• Os sites dos clientes se conectam ao seu BEB local por meio da interface 1/1/48
• Interfaces de IP do lado da LAN ou do gateway padrão do site estão vinculadas à VLAN 3001, que é o padrão
VLAN na porta 1/1/48
• A porta 1/1 / 54A é designada como uma porta de loopback
• As interfaces de IP do lado WAN são vinculadas a uma VLAN 3100 fictícia
Resumo técnico
Guia de Shortest Path Bridging Architecture 31
Snippet 29. Exemplo de VPN L3 - BEB-1
Snippet 30. Exemplo de VPN L3 - BEB-2
Snippet 31. Exemplo de VPN L3 - BEB-3
Resumo técnico
Guia de Shortest Path Bridging Architecture 32
Snippet 32. Exemplo de VPN L3 - BEB-4
Tendo criado o serviço VPN L3 em todos os nós, podemos agora prosseguir para verificá-lo com os comandos show. 
Vamos começar verificando a importação e exportação da rota correta. O snippet 33 mostra as rotas no VRF 
“Customer_A” do BEB-1. Ambas as sub-redes LAN e WAN locais são rotas LOCAIS, enquanto as sub-redes LAN de ponta 
remota são rotas IMPORT cujo endereço de gateway do próximo salto é o endereço WAN do BEB remoto.
Snippet 33. Exemplo de VPN L3 - Verificando importação / exportação de rota
O trecho 34 mostra as entradas arp no VRF “Customer_A” do BEB-1. Os endereços de gateway de WAN de ponta remota são aprendidos 
dinamicamente.
Snippet 34. Exemplo de VPN L3 - Verificando a acessibilidade do gateway L2
Além dessas etapas de verificação relacionadas a L3, todas as etapas cobertas na seção 9 podem ser usadas para 
verificar o serviço L2 subjacente.
Resumo técnico
Guia de Shortest Path Bridging Architecture 33
11.3 VPN Lite versus VPN L3
Tendo apresentado VPN Lite e VPN L3, agora podemos discutir os prós e contras e fornecer orientações 
para ajudá-lo a escolher um ou outro.
Vamos começar com as vantagens da VPN L3:
• Simplicidade: O L3 VPN não requer configuração de protocolo de roteamento, pois simplesmente aproveita a 
instância SPB IS-IS existente. O VPN Lite, por outro lado, requer uma instância do protocolo de roteamento 
por locatário / VRF e BEB. Por exemplo, se estiver usando OSPF, 4 serviços ao cliente abrangendo 8 nós BEB 
requerem 4 x instâncias OSPF por nó: Um total de 32 x configurações OSPF em todos os nós. Caso o suporte 
IPv4 e IPv6 de pilha dupla seja necessário, isso se traduz em uma instância OSPFv2 e OSPFv3 por BEB e VRF: 
Um total de 64 configurações OSPF, todos os nós incluídos. Mais configurações de protocolo de roteamento 
resultam em tempos de provisionamento de serviço mais longos e maiores chances de cometer erros.
• Escalabilidade: O L3 VPN é significativamente mais eficiente do que o VPN Lite do ponto de vista do CP, pois usa 
uma única instância de roteamento. Isso resulta em uma carga de CP mais leve e permite maior escalabilidade do 
que o VPN Lite.
• Convergência: A convergência L3 VPN pode ser mais rápida do que VPN Lite porque depende de um único protocolo. A 
convergência do VPN Lite pode ser mais lenta porque o empilhamento de protocolos de roteamento tem um efeito de 
combinação sobre o tempo de convergência: o IS-IS deve convergir antes que o OSPF possa convergir.
Com argumentos tão convincentes a favor do VPN L3, você pode se perguntar por que alguém escolheria usar o 
VPN Lite em vez disso. A razão é que, embora L3 VPN seja a opção recomendada dentro do domínio SPB, L3 VPN 
depende do SPB IS-IS e não pode interoperar diretamente com redes externas. É aqui que entra o VPN Lite. O 
VPN Lite pode ser configurado em nós BEB de fronteira que ligam o domínio SPB a redes externas sem 
capacidade SPB. Esses nós BEB de fronteira usam L3 VPN para se comunicar com outros nós BEB e VPN Lite para 
interoperar com nós não SPB externos por meio de protocolos de roteamento comuns, como OSPF ou BGPv4.
Resumindo, o L3 VPN é recomendado dentro do domínio SPB e o VPN Lite é necessário apenas em nós de 
fronteira que se conectam ao mundo externo.
12. VPN de serviços compartilhados e vazamento de rota
Em designs de VPN L3 em que cada VPN mapeia para seu próprio VRF, é comum que certos serviços, como 
DHCP, DNS e acesso à Internet sejam compartilhados entre dois ou mais desses VPNs. Isso pode ser 
implementado por meio de vazamento VRF.
A Figura 25 mostra o mesmo diagrama familiar que temos usado até agora, mas agora com dois clientes, A e 
B. Cada cliente está associado ao seu próprio ISID (1002 para o Cliente A e 1003 para o Cliente B) e VRF 
(Cliente_A e Cliente_B ) nos BEBs 1 a 4. As rotas são propagadas pelo backbone, conforme explicado na seção 
11.2.
Vamos agora imaginar que esses clientes também precisam acessar alguns serviços compartilhados e Internet
Acesso. Um L3_VPN adicional é criado em BEB1 e BEB2, os BEBs de “fronteira”. Esses são os nós por meio 
dos quais esses serviços compartilhados são acessados. O L3VPN “shared_services” está associado ao seu 
próprio ISID (1004) e VRF (shared_services). Observe que este L3VPN não precisa ser estendido para BEBs 
2 e 4.
BEB1 e BEB2 podem trocar rotas com entidades externas, como os firewalls, usando um protocolo padrão, 
como o BGP4. Essas rotas podem vazar para os VRFs dos clientes A e B. Por sua vez, as rotas VRF do cliente 
A e B podem vazar para o VRF “shared_services”. Como pré-requisito, o espaço de endereço do cliente A e B 
não deve se sobrepor um ao outro nem aos serviços compartilhados.
Resumo técnico
Guia de Shortest Path Bridging Architecture 34
Snippet 35. Vazamento de rota
O trecho 35 fornece os comandos necessários para realizar isso nos BEBs de borda, BEB1 e BEB2.
Podemos resumir o processo conforme abaixo:
• As rotas compartilhadas são exportadas do VRF shared_services e para a tabela de roteamento IP global. Ao 
fazer isso, um mapa de rotas filtra as rotas de modo que apenas as rotas externas sejam exportadas. Isso 
evita a reexportação de rotas importadasda outra fronteira BEB.
• As rotas compartilhadas são importadas da tabela de roteamento IP global e para os VRFs do cliente. Observe que 
esta etapa só é necessária se os sites do cliente estiverem conectados aos BEBs de fronteira.
• As rotas do cliente são importadas da tabela de roteamento IP global e para o VRF shared_services. Observe 
que esta etapa só é necessária se os sites do cliente estiverem conectados aos BEBs de fronteira.
• As rotas de clientes remotos são importadas da instância SPB IS-IS e ISID associado a esses clientes e para o 
VRF shared_services.
• As rotas compartilhadas são redistribuídas do shared_services VRF para a instância SPB IS-IS e ISIDs 
associados aos clientes. Essas rotas serão propagadas pelo backbone e
importados para VRFs de clientes em BEBs remotos.
Figura 25. Serviços compartilhados
Cliente B
Site 1
Cliente B
Site 2
Cliente A
Site 1
BEB1 BEB2 Cliente A
Site 2
SPB
IS-IS
Cliente B
Site 3
Cliente B
Site 4
Cliente A
Site 3
Cliente A
Site 4BEB3 BEB4
Resumo técnico
Arquitetura de Bridging do Caminho Mais Curto guia 35
13. Automação
Até este ponto, explicamos os conceitos do SPB e configuramos o backbone e os serviços do SPB 
manualmente. No entanto, o AOS incorpora recursos que podem construir o backbone SPB e os serviços 
automaticamente. Nesta seção, explicaremos os vários mecanismos que tornam possível uma rede SPB quase 
zero-touch. Um Alcatel-Lucent OmniSwitch padrão de fábrica tem esses mecanismos ativados por padrão e 
tentará automaticamente criar um backbone SPB e serviços conforme explicado nas subseções subsequentes, 
a menos que esses recursos de automação sejam explicitamente desativados. Este conjunto de recursos às 
vezes é conhecido como “Tecido Inteligente” ou “iFab” para abreviar. Nesta seção, fornecemos uma visão geral 
simplificada e de alto nível desses recursos. Para uma descrição detalhada, consulte o Alcatel-Lucent 
OmniSwitch Switch Management Guide.
13.1 Auto-Fabric
A Figura 26 é uma visão simplificada de um processo de inicialização do OmniSwitch padrão de fábrica. Para 
um fluxograma mais detalhado, consulte o Alcatel-Lucent OmniSwitch Switch Management Guide.
Este processo envolve as seguintes etapas:
• Chassi Virtual Automático (VC)
• Download automático da configuração remota (RCD)
• Auto LACP
• SPB automático
• MVRP automático
• IP automático
Os recursos do Auto-Fabric são habilitados por padrão em um OmniSwitch padrão de fábrica. No entanto, 
esses recursos podem ser totalmente desativados ou por protocolo ou porta. Por padrão, a configuração 
aprendida e criada automaticamente não é salva no arquivo vcboot.cfg, mas esta opção
pode ser ativado.
Figura 26. Diagrama de estado de inicialização
Auto-VC Sucesso
com AF
Desativado
Auto-IP
Assim que IP
Falha ou
tem sucesso com
AF habilitado
Auto-RCD PARE
interface está ativa
se AF está habilitado
Auto-LACP Auto-SPB Auto-MVRP
Link ?? ap
Vamos descrever esses estágios um por um.
13.1.2 Auto-VC
Na inicialização, e na ausência do arquivo vcsetup.cfg, um OmniSwitch usa LLDP para detectar outros nós compatíveis 
com VC conectados às portas VFL automáticas padrão. As portas VFL automáticas padrão dependem da família de 
produtos. Algumas famílias, como o Alcatel-Lucent OmniSwitch® 6860 Stackable LAN Switch, têm 2 portas VFL 
designadas que assumem essa função como padrão. Em outras famílias, como o Alcatel-Lucent OmniSwitch® 6900 
Stackable LAN Switch, que suporta VC de até 6 unidades, as últimas 5 portas qualificadas para VFL são padronizadas 
para portas VFL automáticas. Se outros produtos da mesma família forem detectados na outra extremidade, eles 
tentarão criar um VC automaticamente. Um nó mestre será escolhido por meio de um mecanismo de eleição e os nós 
não mestre serão reinicializados. Desde este processo
cria um arquivo vcsetup.cfg em todos os nós envolvidos, o auto-VC não iniciará em eventos de reinicialização de nó 
subsequentes.
Resumo técnico
Guia de Shortest Path Bridging Architecture 36
13.1.3 Auto-RCD
Em seguida, e na ausência de um arquivo vcboot.cfg, um OmniSwitch tenta obter um endereço IP por meio de 
DHCP em qualquer uma de suas portas operacionais não VFL. Ele tentará fazer isso usando a VLAN padrão não 
marcada e a VLAN 127 marcada e tentará novamente três vezes. Se o switch obtiver um endereço IP e 
dependendo das opções de DHCP da concessão, o switch tentará subsequentemente buscar um arquivo de 
instrução de um servidor TFTP ou entrará em contato com o Sistema de gerenciamento de rede Alcatel-Lucent 
OmniVista® 2500. Em seguida, o switch tentará fazer o download do firmware e vcboot.cfg de um servidor FTP / 
SFTP ou OmniVista. Se o switch obtiver seu firmware e configuração, ele irá reinicializar e carregar sua 
configuração. Dependendo das opções configuradas, o switch pode ou não continuar com os estágios 
subsequentes.
13.1.4 Auto-LACP
Todas as portas não VFL são habilitadas com LACP automático por padrão. O LACP automático é ativado em um switch padrão de 
fábrica ou em um switch não padrão de fábrica, a menos que explicitamente desabilitado. O Auto-LACP pode ser desabilitado 
globalmente ou apenas em portas específicas.
Durante o estágio auto-LACP, um switch usa LLDP para identificar switches conectados a portas habilitadas para 
autoLACP. Quaisquer portas compatíveis com LACP vinculando o mesmo par de switches serão automaticamente 
adicionadas a um linkagg. Mesmo se houver apenas um único link conectando dois nós, ele ainda será configurado 
como um linkagg porque isso permite que links adicionais sejam adicionados posteriormente sem a necessidade de 
alterações na configuração. Por exemplo, criando um linkagg de 1 porta membro e referenciando o linkagg (lógico) 
em oposição à porta (física) em outros comandos de configuração, esses comandos de configuração não precisam 
ser alterados quando portas membro adicionais são adicionadas ao linkagg. Esta é uma prática recomendada.
Observe que, mesmo que o switch remoto não seja um OmniSwitch, mas seja (manualmente) configurado para 
LACP, o OmniSwitch detecta PDUs LACP e configura automaticamente seu lado do linkagg. Isso simplifica a 
implantação, mesmo quando switches de terceiros são usados.
13.1.5 Auto-SPB
Todas as portas e linkaggs não VFL são habilitados para SPB automático por padrão. O SPB automático é ativado em um switch padrão 
de fábrica ou um switch não padrão de fábrica, a menos que explicitamente desabilitado. O SPB automático pode ser desabilitado 
globalmente ou apenas em portas ou linkaggs específicos.
O SPB automático também usa LLDP para detectar a presença de switches compatíveis com SPB. Quando um switch 
compatível com SPB é detectado, o switch tentará configurar a porta ou linkagg como uma interface de backbone 
SPB. Ao fazer isso, ele usará certos padrões.
Em switches executando AOS versão 8.7R1 e posterior, esses padrões são:
• BVLANs 4000 a 4003 são criados e mapeados para ECT IDs 1 a 4, respectivamente
• BVLAN 4000 é designado como o BVLAN de controle
Se o switch conseguir estabelecer pelo menos uma adjacência SPB, todas as portas de backbone não-VFL e não-SPB 
restantes são configuradas automaticamente como portas de acesso UNP auto, a menos que explicitamente
Desativado. Consulte a seção 13.3 para obter detalhes sobre as portas de acesso UNP automático.
13.1.6 Auto-MVRP
O MVRP automático é habilitado nas chaves padrão de fábrica. No entanto, nos switches que inicializam a partir 
de um arquivo vcboot.cfg, esse recurso precisa ser habilitado explicitamente. Quando o MVRP automático está 
habilitado, e se o switch falhar em estabelecer qualquer adjacência SPB, o MVRP será habilitado em todas as 
portas não VFL restantes e operacionais. Isso permite a instanciação dinâmica de VLANs aprendidas de switches 
vizinhos.
Resumo técnico
Guia de Shortest Path Bridging Architecture 37
13.1.7 Auto-IP
Os recursos Auto-IP são executados em paralelo com outros recursos descritos nesta seção e, quando ativados, 
são ativados assim que uma