Guia de Design Detalhado e Exemplos de Configuração da Política de Caminho Explícito SR-TE com EVPN VPWS, IOS XR Release - 7.5.x
Contents
Introdução
Este documento descreve o guia de projeto detalhado com descrições técnicas baseadas nos requisitos das redes XYZ e também fornece um modelo de configuração de baixo nível e configuração para os casos de uso de Política de caminho explícito de Engenharia de tráfego de roteamento de segmento (SR-TE - Segment Routing Traffic Engineering) com VPN Ethernet (EVPN - Virtual Private Wired Service) (VPWS - Virtual Private Wired Service).
1. Informações gerais
1.1. Fora do âmbito
Este documento não cobre os requisitos de políticas SR-TE "sob demanda" centralizadas que usam o controlador XTC, EVPN ELAN e assim por diante, mas focaliza apenas as políticas SR-TE orientadas por nó de fim de cabeçalho com sobreposição EVPN VPWS.
1.2. Pressuposto
O leitor deste documento deve estar familiarizado com os conceitos de IP/MPLS e Ethernet juntamente com as tecnologias de roteamento de segmento e engenharia de tráfego.
1.3. Âmbito técnico
O escopo técnico principal deste documento está limitado a:
- OSPF com TI-LFA FRR
- Políticas SR-TE controladas pelo headend (distribuídas)
- Caminho primário explícito e caminhos de failover baseados em IGP dinâmico
- EVPN VPWS single-homed
Os modelos de configuração fornecidos neste documento são chamados de Cisco IOS®-XR 7.5.x.
1.4. Resumo do documento
Tabela 1. Seções do documento
| Tipo de tópico |
Nome do tópico |
Número da Seção |
| Introdução |
Informações de Apoio |
1 |
| Requisitos |
Requisitos do usuário |
2 |
| Resumo da tecnologia |
Roteamento de segmento |
3 |
| Visão geral do SR-TE |
4 |
|
| TI-LFA FRR |
5 |
|
| Sobreposição de EVPN |
6 |
|
| Balanceamento de carga e BoB |
7 |
|
| Modelos de configuração |
A solução de design completa |
8 |
| Exemplo de configuração e comandos show |
9 |
Requisitos
2. Requisitos do usuário
2.1. Resumo dos requisitos
O provedor de serviços XYZ Networks tem um requisito para criar uma rede de campo verde por meio de dispositivos Cisco NCS 5500.
A finalidade é transportar um fluxo de dados multicast (voz, vídeo) como um serviço através de uma rede de transporte da camada 2 com determinados requisitos, um deles é projetar os caminhos de tráfego através da rede.
Eles preferiram SR para rótulos de transporte, SR-TE para engenharia de tráfego e EVPN como uma sobreposição para fornecer rótulos de serviço.
2.2. Componentes utilizados
O usuário XYZ convergiu nos roteadores e nas placas de linha do NCS 5500:
Tabela 2. Requisitos de hardware do projeto
| Nós PE |
PIDs |
| Chassi |
NCS-5504 |
| MPA/LCs conectando nós P |
NC55-36X100G-A-SE |
| MPA/LCs conectando nós CE |
NC55-36X100G-A-SE |
| Nós P |
PIDs |
| Chassi |
NCS-5508 |
| MPA/LCs conectando outros nós P |
NC55-36X100G-A-SE |
| MPA/LCs conectando nós PE |
NC55-36X100G-A-SE |
Esta seção apresenta uma visão geral das tecnologias a serem usadas com descrições breves.
Resumo da tecnologia
3. Roteamento de Segmento
3.1. O que é roteamento de segmento?
O roteamento de segmento é a mais recente tecnologia avançada de MPLS que está no processo para substituir os protocolos LDP e RSVP-TE tradicionais pela introdução da distribuição de rótulo e engenharia de tráfego sob um único guarda-chuva e para fazer isso acontecer apenas através de protocolos IGP/BGP link-state.
O roteamento de segmentos é um método para encaminhar pacotes na rede com base no paradigma de roteamento de origem. A origem escolhe um caminho e o codifica no cabeçalho do pacote como uma lista ordenada de segmentos. Os segmentos são um identificador para qualquer tipo de instrução. Por exemplo, os segmentos de topologia identificam o próximo salto para um destino. Cada segmento é identificado pelo ID do segmento (SID) que consiste em um inteiro de 20 bits simples e sem sinal.
3.2. Identificadores de segmentos
Figura 1. SIDs de nó SR e SIDs de adjacência
Segmentos: o Interior gateway protocol (IGP) distribui dois tipos de segmentos: segmentos de prefixo e segmentos de adjacência. Cada roteador (nó) e cada link (adjacência) tem um identificador de segmento (SID) associado.
SID de prefixo: um segmento de prefixo é um segmento global, portanto um SID de prefixo é globalmente exclusivo dentro do domínio de roteamento de segmento, como ilustrado na Figura 1. Um SID de prefixo está associado a um prefixo IP. O SID do prefixo é configurado manualmente a partir do intervalo de rótulos do bloco global de roteamento de segmentos (SRGB) e é distribuído pelo IS-IS ou OSPF. O segmento de prefixo orienta o tráfego ao longo do caminho mais curto até seu destino.
- Usa o Bloco Global SR (SRGB)
- SRGB anunciado com TLV de recursos do roteador - na configuração, o Prefix-SID pode ser configurado como um valor absoluto ou um índice
- No anúncio do protocolo, Prefix-SID é sempre codificado como um índice globalmente exclusivo. O índice representa um deslocamento da base SRGB, numeração baseada em zero, ou seja, 0 é o 1º índice. Por exemplo, o índice 1 à SID é 16.000 + 1 = 16.001
SID do nó: um SID do nó é um tipo especial de SID de prefixo que identifica um nó específico. Ele é configurado na interface de loopback com o endereço de loopback do nó como o prefixo. Um segmento de prefixo é um segmento global, portanto um SID de prefixo é globalmente exclusivo dentro do domínio de roteamento de segmento.
Em outras palavras, o segmento de Nó é um segmento de Prefixo associado a um prefixo de host que identifica um nó.
- Equivalente a um prefixo router-id, que é um prefixo que identifica um nó
- Node-SID é Prefix-SID com N-flag definido no anúncio
- Por padrão, cada SID de prefixo configurado é um SID de nó
- 'regular' (isto é, não-Node-SID) Prefix-SID é configurável para IS-IS
SID de adjacência: um segmento de adjacência é identificado por um rótulo chamado SID de adjacência, que representa uma adjacência específica, como uma interface de saída, para um roteador vizinho. O SID de adjacência é distribuído por IS-IS ou OSPF. O segmento de adjacência direciona o tráfego para uma adjacência específica. Um segmento de adjacência é um segmento local, portanto, o SID de adjacência é localmente exclusivo em relação a um roteador específico.
- Localmente significativo
- Alocado automaticamente para cada adjacência
- Sempre codificado como um valor absoluto (ou seja, não indexado)
SID ou BSID de vinculação: é um SID localmente significativo associado à Política SR. Ele ajuda a direcionar os pacotes para sua política de SR associada. O segmento de ligação é um segmento local que identifica uma política SR-TE. Cada política SR-TE é associada a um ID de segmento de ligação (BSID).
O BSID é um rótulo local que é alocado automaticamente para cada política SR-TE quando a política SR-TE é instanciada. O BSID pode ser usado para direcionar o tráfego para a política SR-TE e entre fronteiras de domínio, o que cria políticas SR-TE de ponta a ponta contínuas entre domínios.
4. Visão geral do SR-TE
4.1. O que é SR-TE?
O Segment Routing Traffic Engineering (SR-TE) transforma o mecanismo de roteamento de origem simples e stateless do SR em um nível avançado para programar e orientar o tráfego de dados através de caminhos predefinidos que evitam congestionamentos e fornecem caminhos alternativos, assim como um mapa de tráfego de via expressa.
Isso é obtido quando você configura administrativamente as políticas definidas por meio de uma combinação de várias restrições que programam os caminhos principal e de backup dos nós de origem para destino. O controlador pode ser centralizado (SDN) ou distribuído (headend), o que depende do requisito de rede.
Vamos considerar a topologia apresentada na Figura 2. Suponha que o custo dos links sejam valores padrão e que o caminho mais curto para alcançar D de A seja A-B-C-D, mas o caminho de latência baixa seja A-E-F-G-H-D. O operador pode definir o caminho projetado pelo tráfego conforme o requisito (por exemplo, Latência) e expressá-lo na forma de uma lista de ID de segmento - (A, E, F, G, H, D). Diferentemente do RSVP-TE, o estado dessa política é mantido somente no roteador A e não nos roteadores inteiros pelos quais os pacotes passam (isto é, E, F, G e H).
Figura 2. Exemplo de caminho definido administrativamente por SR-TE
4.2. Política SR-TE
O roteamento de segmento para engenharia de tráfego (SR-TE) usa uma 'política' para orientar o tráfego através da rede. Um caminho de política SR-TE é expresso como uma lista de segmentos que especifica o caminho, chamada de lista de ID de segmento (SID). Cada segmento é um caminho de ponta a ponta da origem até o destino e instrui os roteadores na rede a seguir o caminho especificado em vez de seguir o caminho mais curto calculado pelo IGP. Se um pacote for direcionado para uma política SR-TE, a lista SID será enviada no pacote pelo headend. O restante da rede executa as instruções incorporadas na lista de SID.
Uma política SR-TE é identificada como uma lista ordenada (head-end, cor, end-point):
- Head-end - onde a política SR-TE é instanciada
- Cor - Um valor numérico que distingue entre duas ou mais políticas para os mesmos pares de nós (Head-end - Endpoint)
- Ponto final - o destino da política SR-TE
- Cada política SR-TE tem um valor de cor. Cada política entre os mesmos pares de nós requer um valor de cor exclusivo.
Uma política SR-TE é configurada com um ou mais caminhos candidatos que incluem caminhos principais e de backup.
Por exemplo, o caminho principal da política pode ser explicitamente definido com os SIDs de adjacência e, em caso de cenários de falha, o caminho de backup pode ser dinâmico, tomado pela métrica IGP.
5. RRF TI-LFA
5.1. Panorâmica
A Topologia Independent Loop-Free Alternative (TI-LFA) é um recurso que protege links, nós e SRLGs. É simples de configurar; somente duas linhas de configuração são necessárias para implementar uma configuração TI-LFA simples no roteador. Ele não exige nenhuma alteração nos protocolos que existem usados no roteador. A Figura 3 mostra o caminho de tráfego principal e o caminho de backup pré-calculado pelo TI-LFA para cenários de falha de link local e falha de nó.
Figura 3. Cenário de failover de link TI LFA
Figura 4. Cenário de failover de nó TI LFA
Cada nó e caminho protegido tem um caminho de backup pré-calculado que pode ser ativado rapidamente. O tempo de convergência de um caminho protegido é de 50 milissegundos ou menos. Isso significa que até mesmo os aplicativos com maior sensibilidade à perda de latência ou de pacotes podem funcionar sem interrupções caso um nó ou um link falhe. O TI-LFA calcula o caminho de backup e remove temporariamente o link ou nó protegido do banco de dados. Depois disso, ele calcula o caminho de backup com o caminho mais curto primeiro. Isso garante que o caminho de backup tenha o menor custo de métrica possível enquanto evita o caminho protegido. Um túnel de engenharia de tráfego que segue o caminho de backup é usado para tráfego se ocorrer uma falha. Uma lista de rótulos de reparo determina o caminho para os pacotes que precisam de uma nova rota para seu destino. Uma lista de rótulos de reparo é uma pilha de rótulos normal, mas só é usada quando ocorre uma falha na rota protegida.
5.2. Impacto do método de detecção de anomalias na RRF
O Fast Reroute para caminhos com engenharia de tráfego SR-TE é configurado como um meio de comutar o tráfego no caso de situações de failover do caminho principal para caminhos de backup dentro de 50 ms, o mais próximo possível. O recurso de redirecionamento rápido é configurado no protocolo IGP (OSPF/ISIS). O tempo de convergência depende do método pelo qual ocorre a detecção de falha do link. No caso de um corte de fibra, a detecção é imediata e a possibilidade de obter uma convergência abaixo de 50 ms é alta. No entanto, caso a detecção de falha do link tenha que ser feita pelo BFD com um intervalo de 15 ms (multiplicador x3). O tempo de convergência é maior que 50 ms.
5.3. Prevenção de microlaço com SR
Os microloops são pequenos loops de pacote que ocorrem na rede que segue uma alteração de topologia (eventos de link inativo, link ativo ou alteração de métrica). Os microloops são causados pela convergência não simultânea de nós diferentes na rede. Se os nós convergirem e enviarem o tráfego para um nó vizinho que ainda não convergiu, o tráfego pode ser colocado em loop entre esses dois nós, o que resulta em perda de pacotes, instabilidade e pacotes fora de ordem.
O recurso Segment Routing Microloop Avoidance detecta se os microloops são possivelmente seguidos por uma alteração de topologia. Se um nó computa que um microloop pode ocorrer na nova topologia, o nó cria um caminho de política SR-TE sem loops para o destino com o uso de uma lista de segmentos. Depois que o temporizador de retardo de atualização RIB expira, a política SR-TE é substituída por caminhos de encaminhamento regulares. Há um temporizador padrão para o atraso de atualização da RIB que é atendido pelo TI-LFA.
6. Sobreposição de EVPN
O EVPN é uma tecnologia projetada inicialmente para serviços multiponto Ethernet, com recursos avançados de multihoming, com o uso do BGP para distribuir informações de alcançabilidade de endereço MAC através da rede MPLS, enquanto traz as mesmas características operacionais e de escala de VPNs IP para L2VPNs. Hoje, além dos aplicativos DCI e E-LAN, a família de soluções EVPN fornece uma base comum para todos os tipos de serviços Ethernet, que inclui E-LINE e E-TREE, bem como cenários de roteamento e bridging de data center. O EVPN também oferece opções para combinar serviços L2 e L3 na mesma instância.
O EVPN é uma solução de última geração que fornece serviços multiponto Ethernet sobre redes MPLS. O EVPN opera em contraste com o Virtual Private LAN Service (VPLS) que existe, o que permite o aprendizado de MAC baseado em plano de controle BGP no núcleo. No EVPN, os PEs que participam das instâncias do EVPN aprendem as rotas MAC do usuário no plano de controle com o uso do protocolo MP-BGP.
O EVPN traz vários benefícios como mencionado:
- Redundância por fluxo e balanceamento de carga
- Provisionamento e operação simplificados
- Encaminhamento ideal
- Convergência rápida
- Escalabilidade de endereço MAC
- Soluções de vários fornecedores sob padronização IETF
Os endereços MAC aprendidos em um dispositivo precisam ser aprendidos ou distribuídos em outros dispositivos em uma VLAN. O recurso Aprendizado de MAC do Software EVPN permite a distribuição dos endereços MAC aprendidos em um dispositivo para os outros dispositivos conectados a uma rede. Os endereços MAC são aprendidos dos dispositivos remotos com o uso do BGP.
Nestas seções, você aprenderá sobre alguns dos benefícios e tipos de rota do EVPN em geral e, em seguida, entenderá os componentes específicos da solução que são aplicados ao projeto dos serviços de rede XYZ.
6.1. Benefícios da EVPN
O L2VPN e o L3VPN não apenas fornecem serviços sob um único guarda-chuva de soluções com a ajuda de vários tipos de rotas, as EVPNs resolvem duas limitações de longa data para serviços Ethernet em redes de provedores de serviços:
- Acesso Ethernet multilocal e totalmente ativo
- Rede do provedor de serviços—integração com o escritório central ou com o data center
6.1.1. Acesso Ethernet multilocal e totalmente ativo
A figura demonstra a maior limitação das soluções L2 Multipoint tradicionais, como VPLS.
Figura 5. Acesso EVPN All-Ative
Quando o VPLS é executado no núcleo, a prevenção de loop exige que PE1/PE2 e PE3/PE4 forneçam apenas redundância de Atividade Única para seus respectivos CEs. Tradicionalmente, técnicas como mLACP ou protocolos L2 legados, como MST, REP, G.8032, etc., eram usadas para fornecer redundância de acesso Single-Ative.
A mesma situação ocorre com o Hierarchical-VPLS (H-VPLS), em que o nó de acesso é responsável por fornecer acesso de H-VPLS de Atividade Única por pseudofio de spoke ativo e de backup (PW).
Os modelos de redundância de acesso totalmente ativo não são implantáveis, pois a tecnologia VPLS não tem a capacidade de impedir loops L2 que derivam dos mecanismos de encaminhamento empregados no núcleo para determinadas categorias de tráfego. O tráfego de broadcast, unicast desconhecido e multicast (BUM) originado do CE é inundado por todo o núcleo VPLS e é recebido por todos os PEs, que, por sua vez, o inundam para todos os CEs conectados. Em nosso exemplo, PE1 pode inundar o tráfego de BUM de CE1 para o núcleo e PE2 pode enviá-lo de volta para CE1 quando recebido.
O EVPN usa técnicas de plano de controle baseadas em BGP para resolver esse problema e permite modelos de redundância de acesso ativo-ativo para acesso Ethernet ou H-EVPN.
6.2. Tipos de rota EVPN
O EVPN define um novo BGP NLRI que é usado para transportar todas as rotas EVPN. O NLRI de EVPN é transportado no BGP com o uso de extensões multiprotocolo com um AFI de 25 (L2VPN) e um SAFI de 70. O anúncio de capacidades de BGP é usado para garantir que dois alto-falantes suportem EVPN NLRI.
Figura 6. NLRI EVPN
Os tipos de rota EVPN relevantes necessários para esta implementação são descritos aqui:
6.2.1. Tipo de rota 1 - Rota de descoberta automática (AD) de Ethernet
As rotas de descoberta automática Ethernet (AD) são anunciadas por EVI e por ESI. Essas rotas são enviadas por ES. Eles carregam a lista de EVIs que pertencem ao ES. O campo ESI é definido como zero quando um CE é single-homed. Esse tipo de rota é usado para uma retirada em massa de endereços MAC, aliasing para balanceamento de carga e Filtragem Split Horizon.
6.2.2. Tipo de Rota 4 - Rota de Segmento Ethernet
As rotas de segmento Ethernet permitem a conexão de um dispositivo CE a dois ou PE dispositivos. A rota ES permite a descoberta de dispositivos PE conectados que estão conectados ao mesmo segmento Ethernet, ou seja, descoberta de grupo de redundância. Também é usado para a eleição do encaminhador designado (DF).
6.3. Conectividade do host EVPN
Estes modos EVPN são suportados:
- Single homing - Isso permite que você conecte um dispositivo de borda do usuário (CE) a um dispositivo de borda do provedor (PE). Neste ESI, o valor é nulo para cada link PE-CE.
- Multihoming - Isso permite que você conecte um dispositivo de borda do usuário (CE) a dois ou mais dispositivos de borda do provedor (PE) para fornecer conectividade redundante. Nenhum link Interchasis é necessário. O dispositivo PE redundante garante que não haja interrupção de tráfego quando houver uma falha de rede. Os tipos de multihoming são:
Figura 7. EVPN Single Homing
Multihoming - Estes são os tipos de multihoming:
1. Único-Ativo - Em um modo único-ativo, apenas um único PE entre um grupo de PEs conectados ao Segmento Ethernet específico tem permissão para encaminhar o tráfego de e para esse Segmento Ethernet.
Figura 8. EVPN Single-Ative
2. Ativo-Ativo - No modo ativo-ativo, todos os PEs conectados a um Segmento Ethernet específico têm permissão para encaminhar o tráfego de e para esse Segmento Ethernet.
Figura 9. EVPN dupla ativa
7. Balanceamento de carga e BoB
7.1. BFD sobre o pacote (BoB)
A Detecção de Encaminhamento Bidirecional (BFD - Bidirectional Forwarding Detection) fornece detecção de falhas de baixa sobrecarga e curta duração no caminho entre mecanismos de encaminhamento adjacentes. O BFD permite que um único mecanismo seja usado para detecção de falhas em qualquer meio físico e em qualquer camada de protocolo, com uma ampla gama de tempos de detecção e sobrecarga. A detecção rápida de falhas fornece uma reação imediata à falha no caso de um link ou vizinho com falha.
Isso acionaria o IGP para começar a encaminhar o tráfego para o caminho de backup já calculado com o uso de FRR (no caso do IGP) e PIC (no caso do BGP).
No recurso BFD Over Bundle (BoB), a sessão BFD IPv4 é executada em cada membro ativo do pacote.
Figura 10. Diagrama Lógico de BoB
O Bundlemgr considera os estados BFD, além dos estados L1/L2 existentes, para determinar a usabilidade do link do membro. O Estado-Membro do pacote é uma função de:
Estado L1 (link físico)
Estado L2 (LACP)
Estado L3 (BFD)
O agente BFD ainda é executado na placa de linha. Os estados BFD dos enlaces de membros do pacote são consolidados no RP. Os links membros devem ser conectados back-to-back, sem qualquer switch L2 no meio. O recurso BoB é configurado em todas as interfaces Bundle Ethernet na rede XYZ.
7.2. Balanceamento de carga
O balanceamento de carga ECMP por fluxo na rede em questão abrange as interfaces Ethernet entre pacotes e as ethernets entre pacotes (entre membros físicos de uma interface de pacote). Isso é aplicável em toda a rede de PE para PE (Balanceamento de carga do núcleo), bem como de PE para CE (Balanceamento de carga de CA), conforme discutido.
7.2.1. Balanceamento de carga do núcleo com rótulo FAT
De acordo com o escopo da rede XYZ, você deve considerar apenas o balanceamento de carga ECMP (multicaminho de custo igual) por fluxo como mencionado:
Os roteadores normalmente fazem o balanceamento de carga do tráfego com base no rótulo mais baixo na pilha de rótulos, que é o mesmo rótulo para todos os fluxos em um determinado pseudofio. Isso pode levar a um balanceamento de carga assimétrico. O fluxo, nesse contexto, se refere a uma sequência de pacotes que têm o mesmo par de origem e destino. Os pacotes são transportados de uma extremidade de provedor de origem (PE) para uma extremidade de provedor de destino PE.
O Flow-Aware Transport Pseudowire (FAT PW) oferece a capacidade de identificar fluxos individuais dentro de um pseudofio e fornece aos roteadores a capacidade de usar esses fluxos para balancear a carga do tráfego. Os PWs FAT são usados para balancear a carga do tráfego no núcleo quando são usados ECMP (Equal-Cost Multipaths, vários caminhos de custo igual). Um rótulo de fluxo é criado com base em fluxos de pacotes indivisíveis que entram em um pseudofio e é inserido como o rótulo mais baixo no pacote. Os roteadores podem usar o rótulo de fluxo para balanceamento de carga, que fornece uma melhor distribuição de tráfego através de caminhos ECMP ou caminhos de link agrupados no núcleo.
Um rótulo extra é adicionado à pilha, chamado de rótulo de fluxo, que é gerado para cada fluxo de entrada exclusivo no PE. Um rótulo de fluxo é um identificador exclusivo que distingue um fluxo no PW e é derivado dos endereços MAC origem e destino e dos endereços IP origem e destino. O rótulo de fluxo contém o final do conjunto de bits da pilha de rótulos (EOS). A etiqueta de fluxo é inserida depois da etiqueta VC e antes da palavra de controle (se houver). O PE de entrada calcula e encaminha o rótulo de fluxo. A configuração FAT PW ativa o rótulo de fluxo. O PE de saída descarta o rótulo de fluxo de modo que nenhuma decisão seja tomada.
7.2.2. Balanceamento de carga do circuito de ligação
No entanto, para o balanceamento de carga dos membros do pacote CA, você precisa de uma abordagem diferente devido à ausência de SR-MPLS nesta seção da rede.
O balanceamento de carga por fluxo aqui pode ser obtido quando botões específicos de configuração de l2vpn em todos os roteadores PE são ajustados explicitamente. Pode ser por MAC SRC/DST ou IP SRC/DST conforme o requisito.
Modelos de configuração e Exemplos de Comando
8. A solução de projeto completa
Esta seção discute os detalhes completos do projeto ajustados por todos os diferentes componentes individuais que foram explicados em seções anteriores. Esta seção descreve a topologia e o modelo de configuração relevante com referência ao Cisco IOS-XR 7.5.x.
8.1. Requisitos de baixo nível
Para o cenário de tráfego normal, o fluxo de tráfego é projetado para propagar-se sempre entre as terminações de serviço de PE1 e PE3 e somente entre PE2 e PE4. O objetivo principal nessa situação é manter o caminho de tráfego totalmente desarticulado, como mostrado na Figura 12.
O tráfego em questão aqui seria de fluxos multicast encapsulados através da sobreposição de EVPN. A partir dos nós CE1 e CE2, os fluxos de mídia multicast (voz/vídeo) chegam e podem ser encapsulados nos nós PE1 e PE2 e transportados pela sobreposição EVPN L2 para os nós CE3 e CE4 respectivamente depois de serem desencapsulados nos nós PE3 e PE4 respectivamente.
Portanto, o par de tráfego origem-destino é considerado como PE1-PE3 e PE2-PE4 de agora em diante em todas as circunstâncias, a menos que seja mencionado de outra forma. Para obter os detalhes do requisito, consulte a subseção 2.2.
8.2. Resumo do projeto
Para atender aos requisitos, o OSPF é escolhido como IGP subjacente, conforme desejado pelas redes XYZ. Para direcionar o fluxo multicast encapsulado através do par de tráfego origem-destino através do caminho desejado, o SR-TE precisa ser implementado entre nós PE.
As políticas SR-TE foram projetadas com caminhos IGP explícitos e dinâmicos.
Os Caminhos Explícitos abrangem:
- Cenário de tráfego normal
- Cenário de failover até que opções de caminho alternativo estejam disponíveis
Os Caminhos IGP Dinâmicos abrangem:
- Caminho de Backup para Cenário de Failover em que opções de caminho alternativo NÃO estão disponíveis
Os recursos como BFD, TI-LFA e Prevenção de Microloop são configurados no OSPF, conforme mostrado nas subseções dos modelos de configuração.
Para cenários de tráfego normal, o modelo de configuração e outros detalhes são mencionados na subseção 8.5.1.
Para cenários de failover de tráfego, o modelo de configuração e outros detalhes são mencionados na subseção 8.5.2.
Além disso, os requisitos como a prevenção de microloops e menos de 50 ms de convergência em caso de cenários de falha também são cuidados.
8.3. Elementos de projeto
Esta subseção captura todos os blocos de design que são posteriormente abordados minuciosamente nessas seções.
Visão geral do projeto (Camada 1):
- O tamanho da MTU na rede XYZ é fixado em '9216' com o objetivo de suportar até 5 a 6 pilhas de rótulos SR
- O 'BFD over Bundle' é implementado com um intervalo de 15 ms para detectar cortes de fibra inferiores a 50 ms
Visão geral do design do OSPF/SR-TE:
- OSPF como protocolo IGP com TI-LFA configurado para fornecer FRR abaixo de 50 ms de tempo de convergência
- Camada de Transporte baseada no Roteamento de Segmento como Plano de Encaminhamento e no OSPF como o protocolo de roteamento
- Na rede XYZ, o caminho explícito da engenharia de tráfego de roteamento de segmento orienta o tráfego em todas as direções do caminho principal necessárias. No caso de cenários de failover de link/nó, o tráfego é roteado por um caminho igp dinâmico
- A Prevenção de Microloop e a Métrica Máxima do OSPF também fazem parte desse projeto
Visão geral do design de BGP/RR:
- Há dois RRs configurados em um cluster para fornecer redundância
- A rede XYZ, o processo BGP em cada PE forma o peering 'IPv4' e 'L2VPN EVPN' com ambos os RRs separadamente
Visão geral do design do serviço:
- As camadas de serviço são criadas sobre o plano de controle baseado em BGP e o EVPN ponto a ponto da camada 2 (EVPN-VPWS)
- O tráfego de vídeo multicast (UDP) é enviado encapsulado através dos PWs EVPN-VPWS ponto a ponto
- O balanceamento de carga ECMP é obtido pela configuração do rótulo FAT na seção EVPN
- O serviço tem como objetivo suportar até 5 a 6 pilhas de rótulos SR que incluem rótulos de transporte SR, rótulos EVPN e rótulos FAT para balanceamento de carga
8.4. Exemplo de topologia física
A topologia física das redes XYZ é descrita nesta figura. Por uma questão de simplicidade, apenas 4 nós PE e 4 P são mostrados. Há dois nós RR que atuam em clusters para fornecer redundância.
Figura 11. Topologia física
8.5. Detalhes do projeto da camada 1
No projeto genérico da camada 1, há um pacote Ethernet com pelo menos dois links membros por pacote configurado. Para a detecção rápida de falhas de link, escolha BFD em vez do recurso de pacote. O intervalo de tempo pode variar idealmente entre 5 e 15 ms. Depende da capacidade de descarregamento do hardware.
Para obter detalhes sobre BFD, consulte https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/routing/73x/b-routing-cg-ncs5500-73x/implementing-bfd.html. Observe que esse recurso deve ser configurado somente na interface Ethernet do pacote e não é necessário configurá-lo no IGP. O tamanho da MTU é fixo em 9216 com o objetivo de suportar até 5 a 6 pilhas de rótulos SR.
8.5.1. Modelos de configuração
Os modelos de configuração de BFD sobre pacote para todos os nós são mostrados aqui:
interface Bundle-Ether <Intf-Number>
bfd address-family ipv4 timers start 60
bfd address-family ipv4 timers nbr-unconfig 60
bfd address-family ipv4 multiplier 3
bfd address-family ipv4 destination <Connected-Intf-IP>
bfd address-family ipv4 fast-detect
bfd address-family ipv4 minimum-interval <Time in msec>
mtu <Value as per requirement>
ipv4 address <Intf IP> <Subnet Mask>>
bundle minimum-active links 1
!
8.6. Visão geral do design do OSPF/SR-TE
Todos os roteadores OSPFv2 na rede estão na área 0 e, portanto, a rede trata de um único domínio IGP.
No OSPF do roteador, o roteamento de segmentos é ativado e as interfaces relevantes do Bundle Ethernet são configuradas. Da mesma forma, em Bundle Interfaces, os parâmetros de tipo de rede e redirecionamento rápido são ativados. O mais importante é que uma Interface de Loopback está ativada no modo passivo com o Prefix-SID configurado.
O OSPF é um protocolo de estado de link, portanto, deve ser uma prioridade para identificar imediatamente os downlinks e criar um caminho de backup é necessário. Para cuidar disso, o BFD sobre o pacote na interface do pacote e o TI-LFA FRR no OSPF são configurados, o que mantém o tempo de convergência em 50 ms no caso de cenários de corte de fibra.
Estas subseções descrevem os cenários normal e de failover dos caminhos de tráfego em detalhes:
8.6.1. Cenário de tráfego normal SR-TE
Para manter um caminho primário muito estrito, as políticas SR-TE devem ser projetadas com caminhos explícitos de ponta a ponta entre os pares de tráfego de origem-destino mencionados anteriormente. Além disso, são necessários vários caminhos candidatos de preferência em uma política SR-TE para fornecer provisão para vários cenários de failover.
Esta figura representa os detalhes da rede do usuário em alinhamento com os blocos de design mencionados na subseção 8.3.
- Links entre os nós PE para P e P para P
- Endereços de Loopback de todos os nós
- Endereços de interface de todos os nós
- Direção do caminho de tráfego normal direcionado por SR-TE
- Sobreposição de EVPN entre nós PE
Os RRs não foram mostrados intencionalmente para reduzir a aglomeração na topologia.
Os links entre PE e P foram marcados com azul e os links entre P e P foram marcados com cor verde. O custo OSPF de enlaces PE-para-P é 100 e o custo de enlaces P-para-P é 10.
O fluxo de tráfego SR-TE primário foi marcado com setas azuis entre o par PE1-PE3 e com setas violetas entre o par PE2-PE4.
Figura 12. Detalhes da Topologia
8.6.1.1. Modelos de configuração
Esta subseção contém os modelos de configuração relevantes do OSPF/SR-TE para os nós PE1 e PE2 conforme fornecido:
# PE1 Node: OSPF & SR-TE configs
router ospf CORE
nsr
distribute link-state Command to distribute OSPF database into SR-TE database
log adjacency changes
router-id <Router-ID-PE1> OSPF Router-ID
segment-routing mpls
nsf cisco
microloop avoidance segment-routing Command to enable microloop avoidance with TI-LFA
area 0
interface Bundle-Ether<Intf-Number> OSPF PE to P Link
cost 100 OSPF PE to P Metric
authentication keychain <Key-Chain> Command to enable OSPF Authentication per link
network point-to-point
fast-reroute per-prefix Commands to enable TI-LFA
fast-reroute per-prefix ti-lfa enable
fast-reroute per-prefix tiebreaker node-protecting index <Index-Value>
prefix-suppression
!
interface Loopback <Loopback-ID-PE1>
passive enable
prefix-sid index <SID-Index-Number1> OSPF Loopback Prefix SID
O comando source address na configuração de roteamento de segmento conforme mostrado é necessário em cenários específicos onde, no mesmo PE, como origem da política SR-TE, precisamos escolher um endereço de loopback entre vários ou quando ISIS e OSPF são executados com loopbacks separados, e precisamos congelar em um deles. Caso contrário, em cenários normais, em que há apenas um IGP executado com um loopback exclusivo, a configuração do endereço de origem é opcional.
segment-routing
global-block 16000 23999 Default SRGB Value (Need not be configured). Needs to be configured only if non-default value is assigned
local-block 15000 15999 Default SRLB Value (Need not be configured). Needs to be configured only if non-default value is assigned
traffic-eng
candidate-paths
all
source-address ipv4Configure SR-TE source address as OSPF loopback (Global Option)
!
!
segment-list name <SIDLIST1> Primary/Normal Path SID-LIST1
index <Index ID> mpls adjacency <Remote-IP-Address-Link1>
index <Index ID> mpls adjacency <Remote-IP-Address-Link2>
index <Index ID> mpls adjacency <Remote-IP-Address-Link3>
!
segment-list name <SIDLIST2> Primary Back Up Path SID-LIST2
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
segment-list name <SIDLIST3> Secondary Back Up Path SID-LIST3
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
policy <Pol-Name1>
source-address ipv4 Configure SR-TE source address as OSPF loopback (Policy Specific Option)
color <Color-ID> end-point ipv4 <Destn-PE3>
candidate-paths
preference 50 Tertiary Back Up Path with least preference
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference
explicit segment-list <SIDLIST3>
!
!
preference 150 Primary Back Up Path with 2nd highest preference
explicit segment-list <SIDLIST2>
!
!
preference 200 Primary/Normal Path with highest preference (Active Path for PE1 in this scenario)
explicit segment-list <SIDLIST1>
!
!
!
!
!
!
# PE2 Node: OSPF & SR-TE configs
router ospf CORE
nsr
distribute link-state Command to distribute OSPF database into SR-TE database
log adjacency changes
router-id <Router-ID-PE2> OSPF Router-ID
segment-routing mpls
nsf cisco
microloop avoidance segment-routing Command to enable microloop avoidance with TI-LFA
area 0
interface Bundle-Ether<Intf-Number> OSPF PE to P Link
cost 100 OSPF PE to P Metric
authentication keychain <Key-Chain> Command to enable OSPF Authentication per link
network point-to-point
fast-reroute per-prefix Commands to enable TI-LFA
fast-reroute per-prefix ti-lfa enable
fast-reroute per-prefix tiebreaker node-protecting index <Index-Value>
prefix-suppression
!
interface Loopback <Loopback-ID-PE2>
passive enable
prefix-sid index <SID-Index-Number2> OSPF Loopback Prefix SID
segment-routing
traffic-eng
!
!
segment-list name <SIDLIST1> Primary/Normal Path SID-LIST1
index <Index ID> mpls adjacency <Remote-IP-Address-Link1>
index <Index ID> mpls adjacency <Remote-IP-Address-Link2>
index <Index ID> mpls adjacency <Remote-IP-Address-Link3>
!
segment-list name <SIDLIST2> Primary Back Up Path SID-LIST2
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
segment-list name <SIDLIST3> Secondary Back Up Path SID-LIST3
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
policy <Pol-Name1>
source-address ipv4 Configure SR-TE source address as OSPF loopback (Policy Specific Option)
color <Color-ID> end-point ipv4 <Destn-PE4>
candidate-paths
preference 50 Tertiary Back Up Path with least preference
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference
explicit segment-list <SIDLIST3>
!
!
preference 150 Primary Back Up Path with 2nd highest preference
explicit segment-list <SIDLIST2>
!
!
preference 200 Primary/Normal Path with highest preference (Active Path for PE2 in this scenario)
explicit segment-list <SIDLIST1>
!
!
!
!
!
!
No caso de qualquer link remoto, além do link local de um nó PE, falhar, o caminho permanecerá válido. Ele é projetado e não pode ser modificado até o XR 7.5.x
# PE Node: SR-TE configs
router ospf <Process-Name>
address-family ipv4 unicast
area 0
interface <Core BE Intf1>
adjacency-sid absolute <Adj-SID1>
interface <Core BE Intf2>
adjacency-sid absolute < Adj-SID2>
interface <Core BE Intf3>
adjacency-sid absolute < Adj-SID3>
segment-routing
traffic-eng
policy <Pol-Name1>
color <Color-ID> end-point ipv4 <Destn-PE>
candidate-paths
preference 10
explicit segment-list <SIDLIST1>
!
preference 20
dynamic
metric
type igp
!
segment-list name <SIDLIST1>
index 10 mpls label <Adj-SID-Link1>
index 20 mpls label <Adj-SID-Link2>
index 30 mpls label <Adj-SID-Link3>
8.6.2. SR-TE para cenários de failover
Para entender os cenários de failover de tráfego, é necessário examinar atentamente o tráfego do caminho principal sob condições de tráfego normais, conforme mencionado no diagrama de topologia na subseção anterior.
O objetivo principal em caso de cenários de failover é manter a disjunção do caminho de tráfego na extensão máxima possível, dada a infraestrutura de topologia atual. A rede XYZ tem requisitos rigorosos para administrativamente orientar o tráfego por meio de nós específicos em caminhos de backup, de modo a manter a separação máxima entre os pares de nós origem-destino. Esse design é feito para evitar que os links usados fiquem sobrecarregados e para manter o mínimo de links não usados.
Estas subseções mostram os vários cenários de failover como link único, link duplo, nó único e nó duplo com o caminho de failover que o tráfego usa para manter a máxima desjunção.
8.6.3. Cenário de failover de link único
Este é o cenário de falha de link único onde o link local entre PE1 e P1 falha e o tráfego faz um desvio através dos nós P2 e P1 do núcleo. Ele é administrativamente orientado por meio da lista de segmentos <SIDLIST1>, que forma o caminho de backup principal entre os nós PE1 e PE3
Figura 13. Cenário de failover de link único
Disjunção: para falha de link único, o número de links comuns compartilhados é zero (0), como mostrado na topologia anterior.
8.6.3.1. Modelos de configuração
Esta subseção contém os modelos de configuração relevantes do OSPF/SR-TE para os nós PE1 e PE2, conforme indicado aqui:
# PE1 Node: OSPF & SR-TE configs
segment-routing
traffic-eng
!
!
segment-list name <SIDLIST1> Primary/Normal Path SID-LIST1
index <Index ID> mpls adjacency <Remote-IP-Address-Link1>
index <Index ID> mpls adjacency <Remote-IP-Address-Link2>
index <Index ID> mpls adjacency <Remote-IP-Address-Link3>
!
segment-list name <SIDLIST2> Primary Back Up Path SID-LIST2
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
segment-list name <SIDLIST3> Secondary Back Up Path SID-LIST3
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
policy <Pol-Name1>
source-address ipv4 Configure SR-TE source address as OSPF loopback (Policy Specific Option)
color <Color-ID> end-point ipv4 <Destn-PE3>
candidate-paths
preference 50 Tertiary Back Up Path with least preference
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference
explicit segment-list <SIDLIST3>
!
!
preference 150 Primary Back Up Path with 2nd highest preference (Active Path for PE1 in this scenario)
explicit segment-list <SIDLIST2>
!
!
preference 200 Primary/Normal Path with highest preference
explicit segment-list <SIDLIST1>
!
!
!
!
!
!
# PE2 Node: OSPF & SR-TE configs
segment-routing
traffic-eng
!
!
segment-list name <SIDLIST1> Primary/Normal Path SID-LIST1
index <Index ID> mpls adjacency <Remote-IP-Address-Link1>
index <Index ID> mpls adjacency <Remote-IP-Address-Link2>
index <Index ID> mpls adjacency <Remote-IP-Address-Link3>
!
segment-list name <SIDLIST2> Primary Back Up Path SID-LIST2
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
segment-list name <SIDLIST3> Secondary Back Up Path SID-LIST3
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
policy <Pol-Name1>
source-address ipv4 Configure SR-TE source address as OSPF loopback (Policy Specific Option)
color <Color-ID> end-point ipv4 <Destn-PE4>
candidate-paths
preference 50 Tertiary Back Up Path with least preference
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference
explicit segment-list <SIDLIST3>
!
!
preference 150 Primary Back Up Path with 2nd highest preference
explicit segment-list <SIDLIST2>
!
!
preference 200 Primary/Normal Path with highest preference (Active Path for PE2 in this scenario)
explicit segment-list <SIDLIST1>
!
!
!
!
!
!
8.6.4. Cenário de failover de enlace duplo
Este é o cenário de falha de link duplo onde o link local entre PE1 e P1 e o link local entre PE2 e P2 falham. O tráfego de PE1 faz um desvio através dos nós P2 e P1 do núcleo e o tráfego de PE2 faz um desvio através dos nós P1 e P2 do núcleo.
Eles são administrativamente orientados através da respectiva lista de segmentos <SIDLIST2> de PE1 e PE2 que formam os caminhos de backup secundários entre os nós PE1 e PE3 e PE2 e PE4, respectivamente.
Figura 14. Cenário de failover de link duplo
Disjunção: para falha de link duplo, o número de links comuns compartilhados é um (1), como mostrado na topologia mencionada anteriormente.
8.6.4.1. Modelos de configuração
Esta subseção contém os modelos de configuração relevantes do OSPF/SR-TE para os nós PE1 e PE2, conforme indicado aqui:
# PE1 Node: OSPF & SR-TE configs
#show run router ospf
router ospf CORE
distribute link-state
log adjacency changes
router-id 11.11.11.11
segment-routing mpls
microloop avoidance segment-routing
area 0
interface Bundle-Ether11
cost 100
authentication keychain XYZ-CONT-PE1
network point-to-point
fast-reroute per-prefix
fast-reroute per-prefix ti-lfa enable
fast-reroute per-prefix tiebreaker node-protecting index 200
prefix-suppression
!
interface Bundle-Ether12
cost 100
authentication keychain XYZ-CONT-PE1
network point-to-point
fast-reroute per-prefix
fast-reroute per-prefix ti-lfa enable
fast-reroute per-prefix tiebreaker node-protecting index 200
prefix-suppression
!
interface Loopback0
passive enable
prefix-sid index 11
!
!
!
segment-routing
traffic-eng
!
!
segment-list name <SIDLIST1> Primary/Normal Path SID-LIST1
index <Index ID> mpls adjacency <Remote-IP-Address-Link1>
index <Index ID> mpls adjacency <Remote-IP-Address-Link2>
index <Index ID> mpls adjacency <Remote-IP-Address-Link3>
!
segment-list name <SIDLIST2> Primary Back Up Path SID-LIST2
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
segment-list name <SIDLIST3> Secondary Back Up Path SID-LIST3
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
policy <Pol-Name1>
source-address ipv4 Configure SR-TE source address as OSPF loopback (Policy Specific Option)
color <Color-ID> end-point ipv4 <Destn-PE3>
candidate-paths
preference 50 Tertiary Back Up Path with least preference
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference
explicit segment-list <SIDLIST3>
!
!
preference 150 Primary Back Up Path with 2nd highest preference (Active Path for PE1 in this scenario)
explicit segment-list <SIDLIST2>
!
!
preference 200 Primary/Normal Path with highest preference
explicit segment-list <SIDLIST1>
!
!
!
!
!
!
# PE2 Node: OSPF & SR-TE configs
segment-routing
traffic-eng
!
!
segment-list name <SIDLIST1> Primary/Normal Path SID-LIST1
index <Index ID> mpls adjacency <Remote-IP-Address-Link1>
index <Index ID> mpls adjacency <Remote-IP-Address-Link2>
index <Index ID> mpls adjacency <Remote-IP-Address-Link3>
!
segment-list name <SIDLIST2> Primary Back Up Path SID-LIST2
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
segment-list name <SIDLIST3> Secondary Back Up Path SID-LIST3
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
policy <Pol-Name1>
source-address ipv4 Configure SR-TE source address as OSPF loopback (Policy Specific Option)
color <Color-ID> end-point ipv4 <Destn-PE4>
candidate-paths
preference 50 Tertiary Back Up Path with least preference
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference
explicit segment-list <SIDLIST3>
!
!
preference 150 Primary Back Up Path with 2nd highest preference (Active Path for PE2 in this scenario)
explicit segment-list <SIDLIST2>
!
!
preference 200 Primary/Normal Path with highest preference
explicit segment-list <SIDLIST1>
!
!
!
!
!
!
8.6.5. Cenário de failover de nó único
Este é o cenário de falha de nó único onde o nó P1 falha e o tráfego faz um desvio através dos nós P2 e P4 do núcleo. Ele é administrativamente orientado por meio da lista de segmentos <SIDLIST3>, que forma o caminho de backup secundário entre os nós PE1 e PE3.
O tráfego entre PE2 e PE4, no entanto, permanece o mesmo que o caminho principal, como mostrado nesta topologia.
Figura 15. Cenário de failover de nó único
Disjunção: para falha de nó único, o número de links comuns compartilhados é um (1), como mostrado na topologia mencionada anteriormente.
8.6.5.1. Modelos de configuração
Esta subseção contém os modelos de configuração relevantes do OSPF/SR-TE para os nós PE1 e PE2 conforme fornecido:
segment-routing
traffic-eng
!
!
segment-list name <SIDLIST1> Primary/Normal Path SID-LIST1
index <Index ID> mpls adjacency <Remote-IP-Address-Link1>
index <Index ID> mpls adjacency <Remote-IP-Address-Link2>
index <Index ID> mpls adjacency <Remote-IP-Address-Link3>
!
segment-list name <SIDLIST2> Primary Back Up Path SID-LIST2
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
segment-list name <SIDLIST3> Secondary Back Up Path SID-LIST3
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
policy <Pol-Name1>
source-address ipv4 Configure SR-TE source address as OSPF loopback (Policy Specific Option)
color <Color-ID> end-point ipv4 <Destn-PE3>
candidate-paths
preference 50 Tertiary Back Up Path with least preference
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference (Active Path for PE1 in this scenario)
explicit segment-list <SIDLIST3>
!
!
preference 150 Primary Back Up Path with 2nd highest preference
explicit segment-list <SIDLIST2>
!
!
preference 200 Primary/Normal Path with highest preference
explicit segment-list <SIDLIST1>
!
!
!
!
!
!
# PE2 Node: OSPF & SR-TE configs
segment-routing
traffic-eng
!
!
segment-list name <SIDLIST1> Primary/Normal Path SID-LIST1
index <Index ID> mpls adjacency <Remote-IP-Address-Link1>
index <Index ID> mpls adjacency <Remote-IP-Address-Link2>
index <Index ID> mpls adjacency <Remote-IP-Address-Link3>
!
segment-list name <SIDLIST2> Primary Back Up Path SID-LIST2
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
segment-list name <SIDLIST3> Secondary Back Up Path SID-LIST3
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
policy <Pol-Name1>
source-address ipv4 Configure SR-TE source address as OSPF loopback (Policy Specific Option)
color <Color-ID> end-point ipv4 <Destn-PE4>
candidate-paths
preference 50 Tertiary Back Up Path with least preference
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference
explicit segment-list <SIDLIST3>
!
!
preference 150 Primary Back Up Path with 2nd highest preference
explicit segment-list <SIDLIST2>
!
!
preference 200 Primary/Normal Path with highest preference (Active Path for PE2 in this scenario)
explicit segment-list <SIDLIST1>
!
!
!
!
!
!
8.6.6. Cenário de failover de nó duplo
Este é o cenário de falha de nó duplo onde os nós P1 e P3 falham e o tráfego faz um desvio através dos nós P2 e P4 do núcleo. Ele é administrativamente orientado por meio da lista de segmentos <SIDLIST3>, que forma o caminho de backup secundário entre os nós PE1 e PE3. Como os caminhos explícitos são definidos apenas para os dois cenários mencionados anteriormente, aqui o caminho IGP dinâmico forma o caminho de backup terciário e assume a função de rotear o tráfego através dos nós P2 e P4.
O tráfego entre PE2 e PE4, no entanto, permanece o mesmo que o caminho principal, como mostrado nesta topologia.
Figura 16. Cenário de failover de nó duplo.
Disjunção: para falha de nó duplo, o número de links comuns compartilhados é um (1), como mostrado nesta topologia.
8.6.6.1. Modelos de configuração
Esta subseção contém os modelos de configuração relevantes do OSPF/SR-TE para os nós PE1 e PE2 conforme fornecido:
# PE1 Node: OSPF & SR-TE configs
segment-routing
traffic-eng
!
!
segment-list name <SIDLIST1> Primary/Normal Path SID-LIST1
index <Index ID> mpls adjacency <Remote-IP-Address-Link1>
index <Index ID> mpls adjacency <Remote-IP-Address-Link2>
index <Index ID> mpls adjacency <Remote-IP-Address-Link3>
!
segment-list name <SIDLIST2> Primary Back Up Path SID-LIST2
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
segment-list name <SIDLIST3> Secondary Back Up Path SID-LIST3
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
policy <Pol-Name1>
source-address ipv4 Configure SR-TE source address as OSPF loopback (Policy Specific Option)
color <Color-ID> end-point ipv4 <Destn-PE3>
candidate-paths
preference 50 Tertiary Back Up Path with least preference (Active Path for PE1 in this scenario -
Policy chooses Least Cost IGP Back Up Path in absence of Valid Explicit Path)
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference
explicit segment-list <SIDLIST3>
!
!
preference 150 Primary Back Up Path with 2nd highest preference
explicit segment-list <SIDLIST2>
!
!
preference 200 Primary/Normal Path with highest preference
explicit segment-list <SIDLIST1>
!
!
!
!
!
!
# PE2 Node: OSPF & SR-TE configs
segment-routing
traffic-eng
!
!
segment-list name <SIDLIST1> Primary/Normal Path SID-LIST1
index <Index ID> mpls adjacency <Remote-IP-Address-Link1>
index <Index ID> mpls adjacency <Remote-IP-Address-Link2>
index <Index ID> mpls adjacency <Remote-IP-Address-Link3>
!
segment-list name <SIDLIST2> Primary Back Up Path SID-LIST2
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
segment-list name <SIDLIST3> Secondary Back Up Path SID-LIST3
index <Index ID> mpls adjacency <Remote-IP-Address-Link4>
index <Index ID> mpls adjacency <Remote-IP-Address-Link5>
index <Index ID> mpls adjacency <Remote-IP-Address-Link6>
!
policy <Pol-Name1>
source-address ipv4 Configure SR-TE source address as OSPF loopback (Policy Specific Option)
color <Color-ID> end-point ipv4 <Destn-PE4>
candidate-paths
preference 50 Tertiary Back Up Path with least preference
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference
explicit segment-list <SIDLIST3>
!
!
preference 150 Primary Back Up Path with 2nd highest preference
explicit segment-list <SIDLIST2>
!
!
preference 200 Primary/Normal Path with highest preference (Active Path for PE2 in this scenario)
explicit segment-list <SIDLIST1>
!
!
!
!
!
!
8.7. Visão geral do projeto de BGP/RR
O BGP (Border Gateway Protocol) é o protocolo que toma as principais decisões de roteamento na Internet. Ele mantém uma tabela de redes IP ou "prefixos" que designam a alcançabilidade de rede entre sistemas autônomos (AS). Ele é descrito como um protocolo de vetor de caminho. O BGP não usa as métricas tradicionais do Interior Gateway Protocol (IGP), mas toma decisões de roteamento com base no caminho, nas políticas de rede e/ou nos conjuntos de regras. Por esse motivo, é mais apropriado denominá-lo como um protocolo de alcance do que como um protocolo de roteamento.
O MP-BGP pode ser usado para propagar prefixos de IPv4, IPv6, VPNv4, VPNv6, EVPN e Link-state pela rede. Isso é feito com uma configuração de refletor de rota que forma vizinhos iBGP com dispositivos de núcleo, agregação, acesso e dispositivos SR-PCE.
Através do RR, os prefixos aprendidos do BGP são propagados internamente através do iBGP. As rotas BGP nunca são redistribuídas em IGPs. Os refletores de rota são totalmente isolados do plano de dados e dedicados para fins do plano de controle.
8.7.1. Modelos de configuração
Esta subseção contém os modelos de configuração relevantes para BGP/RR como mostrado:
# PE Node: Relevant BGP configs
router bgp <PE-ASN>
address-family l2vpn evpn
!
neighbor-group <RR-EVPN> Neighbor group of Route Reflector (RR)
remote-as <RR-ASN>
update-source <PE-Self-Loopback>
!
address-family l2vpn evpn AF L2VPN EVPN Neighborship with RR
maximum-prefix <PREFIX> <PERCENT> warning-only
!
address-family ipv4 rt-filter
!
neighbor <RR1-Loopback> Neighborship with RR1 using the above neighbor group
use neighbor-group <RR-EVPN>
neighbor <RR2-Loopback> Neighborship with RR2 using the above neighbor group
use neighbor-group <RR-EVPN>
# RR Nodes: Relevant BGP configs
router bgp <RR-ASN>
address-family l2vpn evpn
!
neighbor-group <PE-EVPN> Neighbor group of Provider Edge (PE)
remote-as <PE-ASN>
update-source <RR-Self-Loopback>
!
address-family l2vpn evpn AF L2VPN EVPN Neighborship with PE
route-reflector-client
!
address-family ipv4 rt-filter
!
neighbor <PE1-Loopback> Neighborship with PE1 using the above neighbor group
use neighbor-group <PE-EVPN>
neighbor <PE2-Loopback> Neighborship with PE2 using the above neighbor group
use neighbor-group <PE-EVPN>
8.8. Visão geral do projeto do serviço
Esta subseção descreve o serviço de sobreposição de EVPN VPWS junto com a representação da pilha de rótulos suportada e os modelos de configuração.
O EVPN-VPWS é uma solução de plano de controle BGP para serviços ponto a ponto. Ele implementa as técnicas de sinalização e encapsulamento que estabelecem uma instância de EVPN entre um par de PEs. Ele tem a capacidade de encaminhar tráfego de uma rede para outra sem consulta MAC. O uso de EVPN para VPWS elimina a necessidade de sinalização de PWs de segmento único e de vários segmentos para serviços Ethernet ponto a ponto. A tecnologia EVPN-VPWS funciona em IP e núcleo MPLS; o núcleo IP suporta núcleo BGP e MPLS para comutação de pacotes entre os pontos finais.
8.8.1. Representação da pilha de rótulos
O serviço tem como objetivo suportar até 5 a 6 rótulos de pilha SR, incluindo rótulos de transporte SR, rótulos EVPN e rótulos FAT para balanceamento de carga. Este é o número máximo de rótulos analisados em Cenários Normais onde o tráfego flui por um Caminho Primário Explícito:
| ADJ SID1 |
|
| ADJ SID2 |
|
| ADJ SID3 |
|
| RÓTULO EVPN |
|
| RÓTULO DO FLUXO (S=1) |
Este é o número máximo de rótulos analisados nos cenários de failover em que o tráfego flui pelo caminho explícito de backup ou pelo caminho de backup dinâmico definido pelo IGP:
| TI-LFA SID1 |
| TI-LFA SID2 |
| TI-LFA SID3 |
| RÓTULO EVPN |
| RÓTULO DO FLUXO (S=1) |
8.8.2. Modelos de configuração
Esta subseção contém os modelos de configuração relevantes para EVPN-VPWS, conforme mostrado:
# PE Node: EVPN configs
evpn
evi <EVI-ID> Ethernet Virtual Identifier
bgp
rd <RD-Value>
route-target import <RT-Value>
route-target export <RT-Value>
!
load-balancing
flow-label static Generates bottom-most label (S=1) for load balancing between intra & inter BE end-to-end
!
!
interface <AC-Interface>
l2vpn
pw-class <PW-Class-Name1>
encapsulation mpls
preferred-path sr-te policy <Pol-Name1> Attaching SR-TE policy as the traffic path of EVPN
!
!
xconnect group <Group-Name>
p2p <P2P-Name>
interface <AC-Subinterface> EVPN Attachment Circuit Interface towards CE
neighbor evpn evi <EVI-ID> service <Service-ID> Service ID defined should match at both the end PEs
pw-class <PW-Class-Name1>
!
9. Configuração de Exemplo e Comandos Show
Esta seção final contém a configuração relevante e os comandos show dos nós PE somente para o cenário de tráfego normal. Eles são capturados aqui alinhados com os parâmetros fornecidos nesta figura como uma referência que ajuda a entender os modelos de configuração explicados nas seções anteriores.
9.1. Exemplo de configuração em nós PE
Figura 17. Topologia com parâmetros de configuração.
# PE1 Node: OSPF & SR-TE Config
#show run router ospf
router ospf CORE
distribute link-state Command to distribute OSPF database into SR-TE database
log adjacency changes
router-id 11.11.11.11 OSPF Router ID
segment-routing mpls
microloop avoidance segment-routing Command to enable microloop avoidance with TI-LFA
area 0
interface Bundle-Ether111 OSPF PE to P Link
cost 100 OSPF PE to P Metric
authentication keychain XYZ-CONT-PE1 Command to enable OSPF Authentication per link
network point-to-point
fast-reroute per-prefix Commands to enable TI-LFA
fast-reroute per-prefix ti-lfa enable
fast-reroute per-prefix tiebreaker node-protecting index 200
prefix-suppression
!
interface Bundle-Ether211
cost 100
authentication keychain XYZ-CONT-PE1
network point-to-point
fast-reroute per-prefix
fast-reroute per-prefix ti-lfa enable
fast-reroute per-prefix tiebreaker node-protecting index 200
prefix-suppression
!
interface Loopback0
passive enable
prefix-sid index 11 OSPF Loopback Prefix SID
!
!
!
#show run segment-routing
Sat Apr 16 23:22:42.727 UTC
segment-routing
traffic-eng
segment-list PrimaryPath Primary/Normal Path
index 10 mpls adjacency 10.1.11.0
index 20 mpls adjacency 10.1.3.1
index 30 mpls adjacency 10.3.13.1
!
segment-list PrimaryBackUpPath Primary Back Up Path
index 10 mpls adjacency 10.2.11.0
index 20 mpls adjacency 10.1.2.0
index 30 mpls adjacency 10.1.3.1
!
segment-list SecondaryBackUpPath Secondary Back Up Path
index 10 mpls adjacency 10.2.11.0
index 20 mpls adjacency 10.2.4.1
index 30 mpls adjacency 10.3.4.0
!
policy SR-TE_POLICY_PE1-to-PE3 SR-TE Policy Towards PE3
color 10 end-point ipv4 33.33.33.33 SR-TE Policy End-Point PE3 Loopback
candidate-paths
preference 50 Tertiary Back Up Dynamic IGP Path with 4th highest preference
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference
explicit segment-list SecondaryBackUpPath
!
!
preference 150 Primary Back Up Path with 2nd highest preference
explicit segment-list PrimaryBackUpPath
!
!
preference 200 Primary and Active Path with highest preference
explicit segment-list PrimaryPath
!
!
!
!
!
!
# PE2 Node: OSPF & SR-TE Config
#show run router ospf
router ospf CORE
distribute link-state Command to distribute OSPF database into SR-TE database
log adjacency changes
router-id 22.22.22.22 OSPF Router ID
segment-routing mpls
microloop avoidance segment-routing Command to enable microloop avoidance with TI-LFA
area 0
interface Bundle-Ether112 OSPF PE to P Link
cost 100 OSPF PE to P Metric
authentication keychain XYZ-CONT-PE2
network point-to-point
fast-reroute per-prefix Commands to enable TI-LFA
fast-reroute per-prefix ti-lfa enable
fast-reroute per-prefix tiebreaker node-protecting index 200
prefix-suppression
!
interface Bundle-Ether222
cost 100
authentication keychain XYZ-CONT-PE2 Command to enable OSPF Authentication per link
network point-to-point
fast-reroute per-prefix Commands to enable TI-LFA
fast-reroute per-prefix ti-lfa enable
fast-reroute per-prefix tiebreaker node-protecting index 200
prefix-suppression
!
interface Loopback0
passive enable
prefix-sid index 22 OSPF Loopback Prefix SID
!
!
!
#show run segment-routing
Sat Apr 16 23:22:42.727 UTC
segment-routing
traffic-eng
segment-list PrimaryPath Primary/Normal Path
index 10 mpls adjacency 10.2.12.0
index 20 mpls adjacency 10.2.4.1
index 30 mpls adjacency 10.4.14.1
!
segment-list PrimaryBackUpPath Primary Back Up Path
index 10 mpls adjacency 10.1.12.0
index 20 mpls adjacency 10.1.2.1
index 30 mpls adjacency 10.2.4.1
!
segment-list SecondaryBackUpPath Secondary Back Up Path
index 10 mpls adjacency 10.1.12.0
index 20 mpls adjacency 10.1.3.1
index 30 mpls adjacency 10.3.4.1
!
policy SR-TE_POLICY_PE2-to-PE4 SR-TE Policy Towards PE4
color 10 end-point ipv4 44.44.44.44 SR-TE Policy End-Point PE4 Loopback
candidate-paths
preference 50 Tertiary Back Up Dynamic IGP Path with 4th highest preference
dynamic
metric
type igp
!
!
!
preference 100 Secondary Back Up Path with 3rd highest preference
explicit segment-list SecondaryBackUpPath
!
!
preference 150 Primary Back Up Path with 2nd highest preference
explicit segment-list PrimaryBackUpPath
!
!
preference 200 Primary and Active Path with highest preference
explicit segment-list PrimaryPath
!
!
!
!
!
!
# PE1 Node: BGP Config
#show run router bgp
router bgp 64848
bgp router-id 11.11.11.11 BGP Router-ID
address-family l2vpn evpn
!
neighbor-group RR-EVPN
remote-as 64848
update-source Loopback0
address-family l2vpn evpn BGP AF L2VPN EVPN
!
!
neighbor 10.10.10.10 Neighbor Route Reflector
use neighbor-group RR-EVPN
!
!
# PE2 Node: BGP Config
#show run router bgp
router bgp 64848
bgp router-id 22.22.22.22 BGP Router-ID
address-family l2vpn evpn
!
neighbor-group RR-EVPN
remote-as 64848
update-source Loopback0
address-family l2vpn evpn BGP AF L2VPN EVPN
!
!
neighbor 10.10.10.10 Neighbor Route Reflector
use neighbor-group RR-EVPN
!
!
# PE1 Node: EVPN-VPWS Config
evpn
evi 100 Ethernet Virtual Identifier
bgp
rd 11:11
route-target import 100:100
route-target export 100:100
!
load-balancing Generates bottom-most label (S=1) for load balancing between intra & inter BE end-to-end
flow-label static
!
!
interface Bundle-Ether99 Interface Attachment Circuit
ethernet-segment
identifier type 0 00.00.00.00.00.00.00.00.00
!
!
!
# PE2 Node: EVPN-VPWS Config
evpn
evi 100 Ethernet Virtual Identifier
bgp
rd 11:11
route-target import 100:100
route-target export 100:100
!
load-balancing Generates bottom-most label (S=1) for load balancing between intra & inter BE end-to-end
flow-label static
!
!
interface Bundle-Ether99 Interface Attachment Circuit
ethernet-segment
identifier type 0 00.00.00.00.00.00.00.00.00
!
!
!
9.1. Comandos show relevantes nos nós PE
# PE1 Node: SR-TE Show Command
#show segment-routing traffic-eng policy
Sat Apr 16 23:35:32.731 UTC
SR-TE policy database
---------------------
Color: 10, End-point: 33.33.33.33
Name: srte_c_10_ep_33.33.33.33
Status:
Admin: up Operational: up for 00:12:54 (since Apr 16 23:22:38.278)
Candidate-paths:
Preference: 200 (configuration) (active) Active Path (Path in use)
Name: SR-TE_POLICY_PE1-to-PE3
Requested BSID: dynamic
Protection Type: protected-preferred
Maximum SID Depth: 12
Explicit: segment-list PrimaryPath (valid) Only the Active Path shows valid
Weight: 1, Metric Type: TE
24007 [Adjacency-SID, 10.1.11.0 - 10.1.11.1]
24007 [Adjacency-SID, 10.1.3.0 - 10.1.3.1]
24005 [Adjacency-SID, 10.3.13.0 - 10.3.13.1]
Preference: 150 (configuration)
Name: SR-TE_POLICY_PE1-to-PE3
Requested BSID: dynamic
Protection Type: protected-preferred
Maximum SID Depth: 12
Explicit: segment-list PrimaryBackUpPath (invalid) All inactive paths show invalid
Weight: 1, Metric Type: TE
Preference: 100 (configuration)
Name: SR-TE_POLICY_PE1-to-PE3
Requested BSID: dynamic
Protection Type: protected-preferred
Maximum SID Depth: 12
Explicit: segment-list SecondaryBackUpPath (invalid)
Weight: 1, Metric Type: TE
Preference: 50 (configuration) All inactive paths show invalid
Name: SR-TE_POLICY_PE1-to-PE3
Requested BSID: dynamic
Protection Type: protected-preferred
Maximum SID Depth: 12
Dynamic (invalid)
Metric Type: IGP, Path Accumulated Metric: 0
Attributes:
Binding SID: 24020
Forward Class: Not Configured
Steering labeled-services disabled: no
Steering BGP disabled: no
IPv6 caps enable: yes
Invalidation drop enabled: no
# PE2 Node: SR-TE Show Command
#show segment-routing traffic-eng policy
Sat Apr 16 23:35:32.731 UTC
SR-TE policy database
---------------------
Color: 10, End-point: 44.44.44.44
Name: srte_c_10_ep_44.44.44.44
Status:
Admin: up Operational: up for 00:12:54 (since Apr 16 23:22:38.278)
Candidate-paths:
Preference: 200 (configuration) (active) Active Path (Path in use)
Name: SR-TE_POLICY_PE1-to-PE3
Requested BSID: dynamic
Protection Type: protected-preferred
Maximum SID Depth: 12
Explicit: segment-list PrimaryPath (valid) Only the Active Path shows valid
Weight: 1, Metric Type: TE
24007 [Adjacency-SID, 10.2.12.0 - 10.2.12.1]
24007 [Adjacency-SID, 10.2.4.0 - 10.2.4.1]
24005 [Adjacency-SID, 10.4.14.0 - 10.4.14.1]
Preference: 150 (configuration)
Name: SR-TE_POLICY_PE1-to-PE3
Requested BSID: dynamic
Protection Type: protected-preferred
Maximum SID Depth: 12
Explicit: segment-list PrimaryBackUpPath (invalid) All inactive paths show invalid
Weight: 1, Metric Type: TE
Preference: 100 (configuration)
Name: SR-TE_POLICY_PE1-to-PE3
Requested BSID: dynamic
Protection Type: protected-preferred
Maximum SID Depth: 12
Explicit: segment-list SecondaryBackUpPath (invalid)
Weight: 1, Metric Type: TE
Preference: 50 (configuration) All inactive paths show invalid
Name: SR-TE_POLICY_PE1-to-PE3
Requested BSID: dynamic
Protection Type: protected-preferred
Maximum SID Depth: 12
Dynamic (invalid)
Metric Type: IGP, Path Accumulated Metric: 0
Attributes:
Binding SID: 24020
Forward Class: Not Configured
Steering labeled-services disabled: no
Steering BGP disabled: no
IPv6 caps enable: yes
Invalidation drop enabled: no
# PE1 Node: BGP Show Command
#show bgp l2vpn evpn summary
Sun Apr 17 07:16:23.574 UTC
Address Family: L2VPN EVPN
--------------------------
BGP router identifier 11.11.11.11, local AS number 64848
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 25
BGP NSR Initial initsync version 1 (Reached)
BGP NSR/ISSU Sync-Group versions 25/0
BGP scan interval 60 secs
BGP is operating in STANDALONE mode.
Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer
Speaker 25 25 25 25 25 25
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
10.10.10.10 0 64848 9500 9484 25 0 0 5d16h 1
# PE2 Node: BGP Show Command
#show bgp l2vpn evpn summary
Sun Apr 17 07:16:23.574 UTC
Address Family: L2VPN EVPN
--------------------------
BGP router identifier 22.22.22.22, local AS number 64848
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 25
BGP NSR Initial initsync version 1 (Reached)
BGP NSR/ISSU Sync-Group versions 25/0
BGP scan interval 60 secs
O BGP opera no modo STANDALONE.
Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer
Speaker 25 25 25 25 25 25
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
10.10.10.10 0 64848 9500 9484 25 0 0 5d16h 1
Troubleshooting
Atualmente, não existem informações disponíveis específicas sobre Troubleshooting para esta configuração.
Informações Relacionadas
- https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-5/segment-routing/configuration/guide/b-segment-routing-cg-asr9000-75x/about-segment-routing.html
- https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-5/lxvpn/configuration/guide/b-l2vpn-cg-asr9000-75x/evpn-features.html
- Suporte Técnico e Documentação - Cisco Systems
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
1.0 |
01-Jul-2022 |
Versão inicial |
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)