VPLS com nota técnica de sinalização BGP
Contents
Introduction
Este documento descreve a descoberta automática baseada em BGP para um VPLS (Virtual Private LAN Service) com sinalização BGP. A descoberta automática é um meio para uma borda do provedor (PE) saber quais PEs remotos são membros de um determinado domínio VPLS.A sinalização é um meio para um PE aprender o rótulo de pseudoindicador esperado por um determinado PE remoto para um determinado domínio VPLS.
Consulte estes documentos da Internet Engineering Task Force:
- O RFC 4762 Virtual Private LAN Service (VPLS) usando a sinalização do protocolo de distribuição de rótulo (LDP - Label Distribution Protocol) descreve a descoberta automática de BGP com a sinalização do protocolo de distribuição de rótulo (LDP - Label Distribution Protocol) para VPLS (também conhecido como Martini).
- O RFC 4761 Virtual Private LAN Service (VPLS) usando BGP para detecção automática e sinalização descreve a detecção automática de BGP e a sinalização de BGP para VPLS (também conhecida como Kompella).
Este documento concentra-se no RFC 4761. Com o RFC 4761, as informações de alcance da camada de rede (NLRI - Network Layer Reachability Information) do BGP contêm as informações para detecção automática e sinalização. Quando os roteadores PE remotos recebem essa atualização de BGP, eles têm todas as informações necessárias para configurar uma malha completa de pseudofios para VPLS. A descoberta automática de BGP e a sinalização de BGP usam a mesma família de endereços BGP.
A interface de linha de comando (CLI) e a saída são do Cisco IOS® Software. A configuração e a funcionalidade são muito semelhantes no software Cisco IOS-XR e no software Cisco NX-OS.
Problema
O VPLS consiste em um conjunto de pseudofios (PW) de forma ponto a multiponto. Até agora, o LDP era usado para sinalizar os pseudofios entre os roteadores PE. Assim, uma sessão LDP direcionada sinalizou quais rótulos usar para qual pseudônimo está entre um par de roteadores PE. Você pode configurar manualmente o conjunto de roteadores PE que participaram de um domínio VPLS ou pode usar o BGP para descobrir a configuração automaticamente. Para executar essa descoberta automática, o BGP anunciou qual PE era um membro de qual domínio VPLS. No entanto, mesmo com a descoberta automática de BGP, o LDP foi usado para sinalizar as etiquetas de circuito virtual (VC) de Multiprotocol Label Switching (MPLS) e o ID de pseudo-ataque.
Agora é possível usar o BGP para sinalizar os pseudofios entre os roteadores PE.
Quando um pseudônimo deve ser configurado entre um par de roteadores, os outros roteadores não precisam das informações relacionadas a esse pseudônimo. Por exemplo, essas informações são o rótulo VC a ser usado.
Com o LDP como o protocolo de sinalização para configurar pseudofios, as informações são recebidas somente pelo par de roteadores, porque o LDP faz a sinalização de forma ponto a ponto.
Com o BGP como o protocolo de sinalização para configurar pseudofios, as informações são recebidas por todos os outros roteadores porque o BGP interno (iBGP) faz a sinalização de forma ponto a multiponto. O iBGP tem um requisito de malha completa, então um roteador envia uma atualização do iBGP para todos os outros roteadores iBGP. Isso também pode ser feito com um refletor de rota.
Com o iBGP como protocolo de sinalização, haveria dois métodos para enviar atualizações:
- Cada roteador PE anuncia uma atualização de BGP para todos os vizinhos do iBGP para cada PW; cada vez, um rótulo VC MPLS é anexado. Assim, um roteador PE enviaria tantas atualizações BGP quanto há roteadores PE. No entanto, o rótulo VC anexado à atualização do BGP pode ser usado por apenas um dos roteadores PE - o roteador PE na outra extremidade do PW.
- Para evitar esse problema de um grande número de atualizações de BGP, uma arquitetura foi projetada pela qual um roteador PE local envia um conjunto ou um bloco de rótulos de VC local para todos os roteadores PE remotos. Cada roteador PE remoto escolhe uma das etiquetas VC a ser usada como rótulo VC remoto para o PW em direção ao roteador PE local. O roteador PE remoto deve escolher um rótulo VC remoto de forma exclusiva para que nenhum outro roteador PE escolha o mesmo rótulo VC do bloco de rótulos anunciado. Como um bloco de etiquetas é enviado, deve haver etiquetas suficientes disponíveis para servir todos os possíveis PWs que possam ser configurados, mas não deve haver tantas etiquetas reservadas que não sejam usadas e desperdiçadas.
Este documento descreve como o BGP é usado para sinalizar os pseudofios; observe que o BGP também é usado para descoberta automática ao mesmo tempo.
Arquitetura da solução
Como esse é o VPLS, ainda há um protocolo de sinalização salto a salto necessário no núcleo para transportar os pacotes rotulados do roteador PE para PE. Essa função de transporte no núcleo ainda deve ser cumprida pela engenharia de tráfego LDP ou MPLS.
O BGP precisa enviar as informações necessárias para configurar os pseudofios de forma ponto a multiponto necessários para o VPLS. Essas informações de sinalização incluem:
- identificação de ponto final do roteador PE
- identidade VPLS
- Bloco de rótulos MPLS
- Informações de encapsulamento
Identificação do ponto de extremidade do roteador PE
A identificação do ponto final do roteador PE é determinada a partir do roteador PE que é o remetente BGP da atualização.
A atualização do BGP referente ao VPLS de Redes Virtuais Privadas (L2VPN - Virtual Private Networks) de Camada 2 é identificada pelo AFI/SAFI 25/65. Essa família de endereços é negociada quando o BGP envia a mensagem OPEN.
Identidade VPLS e etiquetas MPLS
O NLRI, também conhecido como prefixo, contém as informações sobre a identidade do VPLS e o bloco de rótulos MPLS. Sua codificação tem um comprimento total de 19 bytes:
+------------------------------------+
| Length (2 octets) |
+------------------------------------+
| Route Distinguisher (8 octets) |
+------------------------------------+
| VE ID (2 octets) |
+------------------------------------+
| VE Block Offset (2 octets) |
+------------------------------------+
| VE Block Size (2 octets) |
+------------------------------------+
| Label Base (3 octets) |
+------------------------------------+
O Route Distinguisher (RD) relaciona-se à identidade do VPLS.
A ID de expansão virtual (VE), o Deslocamento de bloco VE, o Tamanho do bloco VE e a Base de rótulos (LB) estão relacionados ao bloco de rótulos anunciado, como explicado na próxima seção.
Informações de encapsulamento
As informações de encapsulamento também são anexadas ao prefixo e são codificadas como uma comunidade estendida 'Layer2 Info Extended Community' para a atualização do BGP. O valor é 0x800A e é codificado como:
+------------------------------------+
| Extended community type (2 octets) |
+------------------------------------+
| Encaps Type (1 octet) |
+------------------------------------+
| Control Flags (1 octet) |
+------------------------------------+
| Layer-2 MTU (2 octet) |
+------------------------------------+
| Reserved (2 octets) |
+------------------------------------+
O tipo Encaps para VPLS é 19.
Os Sinalizadores de Controle (vetor de bit) são codificados desta forma:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |C|S| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+
| Nome | Valor | Significado |
| C | 1 | Uma palavra de controle DEVE estar presente quando os pacotes VPLS são enviados a este PE. |
| 0 | UMA palavra de controle NÃO DEVE estar presente quando os pacotes VPLS são enviados a este PE. | |
| S | 1 | A entrega sequenciada de quadros DEVE ser usada quando os pacotes VPLS são enviados a este PE. |
| 0 | A entrega sequenciada de quadros NÃO DEVE ser usada quando os pacotes VPLS são enviados a este PE. |
Há também RTs (Route Target, Alvos de Rotas) anexados à atualização do BGP. As RTs controlam a importação e a exportação do L2VPN, da mesma forma que o MPLS L3VPN.
Prefixo de descoberta automática de BGP VPLS e prefixo de sinalização de BGP de VPLS
Um prefixo de descoberta automática de BGP de VPLS é um prefixo /96, enquanto um prefixo de sinalização de BGP de VPLS é um prefixo /136. Estes são exemplos de cada um:
PE2#show bgp l2vpn vpls all
BGP table version is 264, local router ID is 10.100.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:100
*>i 1:100:VEID-1001:Blk-150/136
10.100.1.1 0 100 0 ?
*> 1:100:10.100.1.2/96
0.0.0.0 32768 ?
PE2#show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 150
BGP routing table entry for 1:100:VEID-1001:Blk-150/136, version 262
Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)
Not advertised to any peer
Refresh Epoch 1
Local
10.100.1.1 (metric 21) from 10.100.1.4 (10.100.1.4)
Origin incomplete, metric 0, localpref 100, valid, internal, best
AGI version(0), VE Block Size(50) Label Base(10105)
Extended Community: RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500
Originator: 10.100.1.1, Cluster list: 10.100.1.4
rx pathid: 0, tx pathid: 0x0
PE2#show bgp l2vpn vpls rd 1:100 10.100.1.2
BGP routing table entry for 1:100:10.100.1.2/96, version 43
Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)
Not advertised to any peer
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (10.100.1.2)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local,
best, AGI version(0)
Extended Community: RT:1:100 L2VPN AGI:1:100
rx pathid: 0, tx pathid: 0x0
Exemplo de configuração do software Cisco IOS
Este é um exemplo de configuração do software Cisco IOS:
!
l2vpn vfi context one
vpn id 100
autodiscovery bgp signaling bgp <<< "signaling ldp" would be RFC 4762
ve id 1001
ve range 50
route-target export 32:64
route-target import 32:64
mpls label range 10000 20000
!
bridge-domain 1
member Ethernet0/0 service-instance 100
member vfi one
!
l2 router-id 10.100.1.1
!
interface Ethernet0/0
no ip address
service instance 100 ethernet
!
!
router bgp 1
bgp log-neighbor-changes
neighbor 10.100.1.4 remote-as 1
neighbor 10.100.1.4 update-source Loopback0
!
address-family l2vpn vpls
neighbor 10.100.1.4 activate
neighbor 10.100.1.4 send-community extended
neighbor 10.100.1.4 suppress-signaling-protocol ldp
exit-address-family
Bloco de Rótulo Anunciado
Um roteador PE deve anunciar pelo menos um bloco de rótulo. O bloco de rótulo é um conjunto contínuo de rótulos MPLS e é usado pelos roteadores PE remotos para selecionar um rótulo VC remoto. O rótulo remoto é usado para o PW entre o roteador PE local e remoto. (Um roteador PE pode anunciar vários blocos de rótulo, como explicado em seções posteriores.)
O VE-ID deve ser configurado em cada PE. Identifica os roteadores PE dentro do domínio VPLS.
O tamanho do bloco de VE (VBS) é o tamanho do bloco de rótulo e tem um valor padrão de 10. Se 've range' estiver configurado, será esse valor. O 'intervalo de ve' pode ser configurado para ser [11 -100].
O LB (Label Base) é o primeiro valor de rótulo de um conjunto livre de rótulos que pode ser reservado pelo roteador PE para ser usado para este domínio VPLS.
Deslocamento de bloco VE (VBO) é o valor de deslocamento a ser usado quando vários blocos de rótulo devem ser criados por um roteador PE. O VBO é calculado com esta equação: VBO = RND(VE-ID/VBS) * VBS
Estes são exemplos de cálculos:
- Se VBS = 8 e VE-ID = 2, VBO = RND(2/8) * 8 = 1
- Se VBS = 8 e VE-ID = 20, VBO = RND (20/8) * 8 = 16
- Se VBS = 50 e VE-ID = 199, VBO = RND (199/50) * 50 = 150
- Se VBS = 50 e VE-ID = 1002, VBO = RND (1002/50) * 50 = 1000
O bloco de rótulo anunciado aos roteadores PE remotos é {LB, LB + 1, ? , LB + VBS - 1}. O bloco de rótulo é definido pelo LB e pelo VBS; o bloco começa em LB e termina com (LB + VBS - 1).
Vários blocos de rótulos podem ser criados por cada roteador PE, quando necessário. O roteador deve garantir que seja um conjunto contínuo de rótulos livres.
Destinos do Distinguista de Rota e da Rota
Exemplo de configuração de PE1
router bgp 1
l2vpn vfi context one
vpn id 100
autodiscovery bgp signaling bgp
ve id 1001
ve range 50
route-target export 32:64
route-target import 32:64
mpls label range 10000 20000
Esta é uma explicação dos valores de configuração:
- O ID da VPN está configurado como 100.
- O RD é retirado de [ASN:vpn id], a menos que um RD esteja explicitamente configurado. Aqui, a RD é 1:100.
- Os destinos da rota de importação/exportação são 32:64.
- O LB é da gama [10000 2000]. O valor exato do LB depende do primeiro conjunto de rótulos locais contínuos gratuitos suficientemente grandes para conter todos os rótulos determinados pelo VBS.
- O VE-ID está configurado como 1001.
- O VBS está configurado como 50.
- O VBO é calculado como: VBO = RND(VE-ID/VBS) * VBS ou RND(1001/50) * 50 = 1000.
Verificar intervalo de rótulo
Você pode verificar o intervalo de rótulo com o comando show mpls label range:
PE1#show mpls label range
Downstream Generic label region: Min/Max label: 10000/20000
Há um intervalo de rótulo padrão por plataforma, que você pode alterar com o comando mpls label range.
Verificar etiquetas
Você pode verificar os rótulos usados reais para um bloco de rótulo na base de informações de encaminhamento de rótulo (LFIB) com o comando show mpls forwarding-table.
PE1#show mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop Label
Label or Tunnel Id Switched interface
10000 No Label lbl-blk-id(1:0) 0 drop
10001 No Label lbl-blk-id(1:1) 0 drop
10002 No Label lbl-blk-id(1:2) 0 drop
?
10048 No Label lbl-blk-id(1:48) 0 drop
10049 No Label lbl-blk-id(1:49) 0 drop
10050 Pop Label 10.100.1.4/32 0 Et1/0 10.1.1.4
Neste exemplo, PE1, o roteador local, reservou 50 rótulos locais para o bloco de rótulos. 'lbl-blk-id(1:0)' significa um block-id igual a 1 e um block-instance de 0, que identifica o primeiro rótulo do bloco. A última etiqueta deste bloco é a etiqueta 10049.
A interface 'Outgoing' no LFIB é 'drop' desde que não haja nenhum PW configurado para esse rótulo local. Se um PW estiver configurado, a interface 'Saída' será 'none point2point'.
Verificar bloco de rótulo
O bloco de rótulo atribuído também pode ser verificado com o comando show mpls infrastructure lfd block-database summary quando 'service internal' é configurado.
PE1#show mpls infrastructure lfd block-database summary
Block-DB entry for block-id : 0x1
Block-size : 50, App-Key type : AToM PWID, Labels : 10000 - 10049
LB é 10000. Neste exemplo, o bloco de rótulo é de LB para (LB + VBS - 1) ou de 10000 para (10000 + 50 - 1) = 10049.
Verificar prefixo anunciado
Você pode verificar o prefixo anunciado com o comando show bgp l2vpn vpls rd 1:100:
PE1#show bgp l2vpn vpls rd 1:100
BGP table version is 3, local router ID is 10.100.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:100
*> 1:100:VEID-1001:Blk-1000/136
0.0.0.0 32768 ?
Exibir prefixo em detalhes
Para exibir esse prefixo em detalhes, use o comando show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 1000. Observe que você especifica o VE-ID e o bloco de rótulo, que podem ser encontrados no NLRI (Blk-1000).
PE1#show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 1000
BGP routing table entry for 1:100:VEID-1001:Blk-1000/136, version 3
Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)
Advertised to update-groups:
1
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (10.100.1.1)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
AGI version(0), VE Block Size(50) Label Base(10000)
Extended Community: RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500
rx pathid: 0, tx pathid: 0x0
O NLRI mostra o RD de 1:100, o VE-ID de 1001, o VBO de 1000, o VBS de 50 e o LB de 10000.
A comunidade de informações estendidas da camada 2 contém estas informações:
- O tipo Encap é 19 (VPLS)
- Sinais de controle: C = 0 (uma palavra de controle não deve ser definida); S = 0 (sem entrega sequenciada de quadros)
- MTU é 1500
A comunidade de RT estendida tem estas informações:
- T 1:100
- RT 32:64
Anuncie, receba e processe blocos de rótulo em mensagens de atualização de BGP
Quando um roteador PE local anuncia um bloco de prefixo/rótulo L2VPN VPLS, cada roteador PE remoto deve tentar escolher um rótulo desse intervalo para usar como um rótulo VC remoto.
- Se o roteador PE remoto for bem-sucedido, ele usará o rótulo VC remoto e o programará no plano de dados. Não há mais sinalização pelo BGP.
- Se o roteador PE remoto falhar, ele deve esperar que outro prefixo L2VPN VPLS seja anunciado pelo roteador PE local e, em seguida, tentar escolher outro rótulo VC remoto desse bloco de rótulo.
Suponha que PE1 é um PE local com a configuração anterior e que PE2 é um PE remoto com esta configuração:
l2vpn vfi context one
vpn id 100
autodiscovery bgp signaling bgp
ve id 1002
ve range 50
!
mpls label range 3000 60000
PE2: Receber atualização de BGP
O PE2 recebe esta atualização de BGP do PE1:
PE2#show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 1000
BGP routing table entry for 1:100:VEID-1001:Blk-1000/136, version 5
Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)
Not advertised to any peer
Refresh Epoch 2
Local
10.100.1.1 (metric 21) from 10.100.1.4 (10.100.1.4)
Origin incomplete, metric 0, localpref 100, valid, internal, best
AGI version(0), VE Block Size(50) Label Base(10000)
Extended Community: RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500
Originator: 10.100.1.1, Cluster list: 10.100.1.4
rx pathid: 0, tx pathid: 0x0
PE2: Localizar uma etiqueta
O PE2 precisa encontrar um rótulo que possa ser usado como um rótulo VC remoto para o PW em direção ao PE1.
O PE2 deve primeiro determinar se o VBO está dentro do intervalo de sua configuração. O PE2 verifica seu VE-ID em relação ao intervalo anunciado pelo PE1 com o cálculo VBO <= VE-ID < VBO + VBS. Nesse caso, 1000 <= 1002 < 1000 + 50, portanto, PE2 é bem-sucedido.
O PE2 precisa então escolher um rótulo VC remoto. O rótulo do desmultiplexador (VC) a ser usado pelo PE remoto é calculado como (LB + VE-ID - VBO).
A partir do prefixo anterior, LB é 10000 e VBO é 1000. O VE-ID é o do PE2 e é 1002. Então, PE2 escolhe rótulo (LB + VE-ID - VBO) = (10000 + 1002 - 1000) = 10002.
Use o comando show l2vpn vfi name one para verificar isso:
PE2#show l2vpn vfi name one
Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No
VFI name: one, state: up, type: multipoint, signaling: BGP
VPN ID: 100, VE-ID: 1002, VE-SIZE: 50
RD: 1:100, RT: 1:100
Bridge-Domain 100 attachment circuits:
Pseudo-port interface: pseudowire100001
Interface Peer Address VE-ID Local Label Remote Label S
pseudowire100002 10.100.1.1 1001 3101 10002 Y
PE2: Enviar prefixo para PE1
O PE2 envia seu prefixo ao PE1:
PE1#show bgp l2vpn vpls rd 1:100 ve-id 1002 block-offset 1000
BGP routing table entry for 1:100:VEID-1002:Blk-1000/136, version 4
Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)
Not advertised to any peer
Refresh Epoch 1
Local
10.100.1.2 (metric 21) from 10.100.1.4 (10.100.1.4)
Origin incomplete, metric 0, localpref 100, valid, internal, best
AGI version(0), VE Block Size(50) Label Base(3100)
Extended Community: RT:1:100 L2VPN L2:0x0:MTU-1500
Originator: 10.100.1.2, Cluster list: 10.100.1.4
rx pathid: 0, tx pathid: 0x0
PE1: Localizar uma etiqueta
O PE1 agora é o PE remoto e precisa encontrar um rótulo que possa ser usado como um rótulo VC remoto para o PW em direção ao PE2.
O PE1 deve primeiro determinar se o VBO está dentro do intervalo de sua configuração. O PE1 verifica seu VE-ID em relação ao intervalo anunciado pelo PE2 com o cálculo VBO <= VE-ID < VBO + VBS. Nesse caso, 1000 <= 1001 < 1000 + 50, portanto, PE1 é bem-sucedido.
PE1 precisa então selecionar um rótulo VC remoto. O rótulo do desmultiplexador (VC) a ser usado pelo PE remoto é calculado como (LB + VE-ID - VBO).
A partir do prefixo anterior, LB é 3100 e VBO é 1000. O VE-ID é o do PE1 e é 1001. Então, PE1 seleciona rótulo (LB + VE-ID - VBO) = (3100 + 1001 - 1000) = 3101.
Use o comando show l2vpn vfi name one para verificar isso:
PE1#show l2vpn vfi name one
Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No
VFI name: one, state: up, type: multipoint, signaling: BGP
VPN ID: 100, VE-ID: 1001, VE-SIZE: 50
RD: 1:100, RT: 1:100, 32:64
Bridge-Domain 1 attachment circuits:
Pseudo-port interface: pseudowire100001
Interface Peer Address VE-ID Local Label Remote Label S
pseudowire100002 10.100.1.2 1002 10002 3101 Y
Comandos de verificação adicionais
PE1#show mpls l2transport vc detail
Local interface: VFI one vfi up
Interworking type is Ethernet
Destination address: 10.100.1.2, VC ID: 100, VC status: up
Output interface: Et1/0, imposed label stack {17 3101}
Preferred path: not configured
Default path: active
Next hop: 10.1.1.4
Create time: 02:06:08, last status change time: 02:06:08
Last label FSM state change time: 02:06:08
Signaling protocol: BGP
Status TLV support (local/remote) : Not Applicable
LDP route watch : Not Applicable
Label/status state machine : established, LruRru
Last local dataplane status rcvd: No fault
Last BFD dataplane status rcvd: Not Applicable
Last BFD peer monitor status rcvd: Not Applicable
Last local AC circuit status rcvd: No fault
Last local AC circuit status sent: No fault
Last local PW i/f circ status rcvd: No fault
Last local LDP TLV status sent: Not Applicable
Last remote LDP TLV status rcvd: Not Applicable
Last remote LDP ADJ status rcvd: Not Applicable
MPLS VC labels: local 10002, remote 3101
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Control Word: Off
Dataplane:
SSM segment/switch IDs: 8195/4097 (used), PWID: 3
VC statistics:
transit packet totals: receive 0, send 0
transit byte totals: receive 0, send 0
transit packet drops: receive 0, seq error 0, send 0
PE1#show mpls infrastructure lfd block-database id 1
Block-DB entry for block-id : 0x1
Block-size : 50, App-Key type : AToM PWID
App-Key entries:
l2ckt(1) 10000
l2ckt(2) 10001
l2ckt(3) 10002
l2ckt(4) 10003
l2ckt(5) 10004
l2ckt(6) 10005
l2ckt(7) 10006
l2ckt(8) 10007
l2ckt(9) 10008
l2ckt(10) 10009
l2ckt(11) 10010
l2ckt(12) 10011
l2ckt(13) 10012
l2ckt(14) 10013
l2ckt(15) 10014
l2ckt(16) 10015
l2ckt(17) 10016
l2ckt(18) 10017
l2ckt(19) 10018
l2ckt(20) 10019
l2ckt(21) 10020
l2ckt(22) 10021
l2ckt(23) 10022
l2ckt(24) 10023
l2ckt(25) 10024
l2ckt(26) 10025
l2ckt(27) 10026
l2ckt(28) 10027
l2ckt(29) 10028
l2ckt(30) 10029
l2ckt(31) 10030
l2ckt(32) 10031
l2ckt(33) 10032
l2ckt(34) 10033
l2ckt(35) 10034
l2ckt(36) 10035
l2ckt(37) 10036
l2ckt(38) 10037
l2ckt(39) 10038
l2ckt(40) 10039
l2ckt(41) 10040
l2ckt(42) 10041
l2ckt(43) 10042
l2ckt(44) 10043
l2ckt(45) 10044
l2ckt(46) 10045
l2ckt(47) 10046
l2ckt(48) 10047
l2ckt(49) 10048
l2ckt(50) 10049
PE1#show l2vpn atom vc destination 10.100.1.2
Service
Interface Dest Address VC ID Type Name Status
--------- --------------- ---------- ------ ------------------------ ----------
pw100002 10.100.1.2 100 vfi one UP
PE1#show l2vpn atom vc destination 10.100.1.2 detail
pseudowire100002 is up, VC status is up PW type: Ethernet
Create time: 02:11:13, last status change time: 02:11:13
Last label FSM state change time: 02:11:13
Destination address: 10.100.1.2 VC ID: 100
Output interface: Et1/0, imposed label stack {17 3101}
Preferred path: not configured
Default path: active
Next hop: 10.1.1.4
Member of vfi service one
Bridge-Domain id: 1
Service id: 0xe7000001
Signaling protocol: BGP
Local VE ID: 1001, Remote VE ID: 1002
Status TLV support (local/remote) : Not Applicable
LDP route watch : Not Applicable
Label/status state machine : established, LruRru
Local dataplane status received : No fault
BFD dataplane status received : Not Applicable
BFD peer monitor status received : Not Applicable
Status received from access circuit : No fault
Status sent to access circuit : No fault
Status received from pseudowire i/f : No fault
Status sent to network peer : Not Applicable
Status received from network peer : Not Applicable
Adjacency status of remote peer : Not Applicable
Bindings
Parameter Local Remote
------------ ------------------------------ ------------------------------
Label 10002 3101
Group ID 0 0
Interface
MTU 1500 1500
Control word off off
PW type Ethernet Ethernet
VCCV CV type 0x32 0x32
LSPV [2], BFD/Raw [5] LSPV [2], BFD/Raw [5]
BFD/Raw + sig [6] BFD/Raw + sig [6]
VCCV CC type 0x07 0x07
CW [1], RA [2], TTL [3] CW [1], RA [2], TTL [3]
Status TLV disabled N/A
Dataplane:
SSM segment/switch IDs: 8195/4097 (used), PWID: 3
Rx Counters
0 input transit packets, 0 bytes
0 drops, 0 seq err
Tx Counters
0 output transit packets, 0 bytes
0 drops
PE1#show l2vpn signaling rib rd 1:100
+- Origin of entry (i=iBGP/e=eBGP)
| +- Provisioned (Yes/No)?
| | +- Stale entry (Yes/No)?
| | |
v v v
O P S RD VE-ID VBO VBS LB Next-Hop
-+-+-+-----------------+-------+-------+-------+---------+-----------------+
i Y N 1:100 1002 1000 50 3100 10.100.1.2
PE1#show l2vpn signaling rib rd 1:100 detail
Route 1:100:1002 (epoch:0) from iBGP peer 10.100.1.2
Provisioned (Y) Stale (N)
Route-Target: 1:100
NLRI [FF000001]
VE-ID:1002 VBO:1000 VBS:50 LB:3100
MTU: 1500 Control Word: off
RIB Filter [27000002]
RD: 1:100
VE-ID: 1001, VBO: 1000, VBS: 50 LB: 10000
Forwarder [58000001] VFI one
PE1#show l2vpn atom pwid
AToM Pseudowire IDs: In use: 50, In holddown: 0
Label Peer-Address VCID PWID In-Use FirstUse ResuedAt FreedAt
------ --------------- ---------- ---------- ------ -------- -------- --------
10000 0.0.0.0 0 1 Yes 00:00:15 Never Never
10001 0.0.0.0 0 2 Yes 00:00:15 Never Never
10002 10.100.1.2 100 3 Yes 00:00:15 Never Never
10003 0.0.0.0 0 4 Yes 00:00:15 Never Never
10004 0.0.0.0 0 5 Yes 00:00:15 Never Never
PE1#show l2vpn atom summary
Destination address: 10.100.1.2, total number of vc: 1
0 unknown, 1 up, 0 down, 0 admin down, 0 recovering, 0 standby, 0 hotstandby
1 active vc on MPLS interface Et1/0
Vários prefixos L2VPN VPLS anunciados pelo roteador PE para um VFI
É possível que um PE precise anunciar vários blocos de rótulo para uma instância de encaminhamento virtual (VFI).
Se o VE-ID do PE remoto não estiver no intervalo anunciado pelo PE local, o PE remoto não poderá escolher um rótulo remoto para o PW. Este cálculo, descrito anteriormente, é VBO <= VE-ID < VBO + VBS.
Se essa verificação falhar, o VE-ID do PE remoto está fora do intervalo. O PE remoto ignora o prefixo recebido do PE local. O PE local aprende que o PE remoto está fora do intervalo quando recebe o prefixo que o PE remoto está anunciando. O PE local precisa determinar qual rótulo remoto usar para esse roteador PE remoto. O PE local também envia um novo segundo prefixo para um novo bloco de rótulos locais para o PE remoto, que o PE remoto deve ser capaz de usar para selecionar um rótulo remoto.
Configuração do PE1
O exemplo anterior continua aqui; O PE1 ainda tem:
l2vpn vfi context one
vpn id 100
autodiscovery bgp signaling bgp
ve id 1001
ve range 50
route-target export 32:64
route-target import 32:64
!
mpls label range 10000 20000
Configuração do PE2
O PE2 agora tem um VE-ID de 1002 e esta configuração:
l2vpn vfi context one
vpn id 100
autodiscovery bgp signaling bgp
ve id 10002
ve range 50
!
mpls label range 3000 60000
Blocos iniciais de etiquetas
Tanto o PE1 quanto o PE2 começam com esses blocos iniciais de rótulo.
PE1#show bgp l2vpn vpls rd 1:100
BGP table version is 2, local router ID is 10.100.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:100
*> 1:100:VEID-1001:Blk-1000/136
0.0.0.0 32768 ?
PE2#show bgp l2vpn vpls rd 1:100
BGP table version is 3, local router ID is 10.100.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:100
*> 1:100:VEID-10002:Blk-10000/136
0.0.0.0 32768 ?
PE1 e PE2 Exchange
Use o comando debug bgp l2vpn vpls updates para examinar o PE1 e o PE2 exchange e, em seguida, use o comando show bgp l2vpn vpls rd 1:100 para revisar os detalhes.
PE1#
%BGP-5-ADJCHANGE: neighbor 10.100.1.4 Up
BGP(9): update formatted for 1:100:VEID-1001:Blk-1000:VBS-50:LB-10000/136 VE ID
1001 VE Block Offset 1000 VE Block Size 50 Label Base 10000 /136
BGP(9): (base) 10.100.1.4 send UPDATE (format) 1:100:VEID-1001:Blk-1000:VBS-50:
LB-10000/136, next 10.100.1.1, metric 0, path Local, extended community RT:1:100
RT:32:64 L2VPN L2:0x0:MTU-1500
BGP(9): 10.100.1.4 rcvd UPDATE w/ attr: nexthop 10.100.1.2, origin ?,
localpref 100, metric 0, originator 10.100.1.2, clusterlist 10.100.1.4, extended
community RT:1:100 L2VPN L2:0x0:MTU-1500
BGP(9): 10.100.1.4 rcvd 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136
BGP(9): bump net 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136, non bpath added
BGP(9): nettable_walker called for 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136
BGP(9): best path[0] 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136 source
10.100.1.1 nh 10.100.1.2 vpls-id: L2VPN L2:0x0:MTU-1500
BGP(9): add XC RIB route 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136 masklen 136
L2VPN L2:0x0:MTU-1500 pathcount: 1 [0] LDP source:10.100.1.1 nexthop:10.100.1.2
RT:1:100
BGP(9): bump net 1:100:VEID-1001:Blk-10000:VBS-50:LB-10053/136, non bpath added
BGP(9): nlri update add VBS 50 LB 10053
BGP(9): nlri update add export extcomm count 4
BGPSSA ssacount is 0
BGP(9): update formatted for 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136 VE ID
10002 VE Block Offset 10000 VE Block Size 50 Label Base 3000 /136
BGP(9): nettable_walker called for 1:100:VEID-1001:Blk-10000:VBS-50:LB-10053/136
BGP(9): nettable_walker 1:100:VEID-1001:Blk-10000:VBS-50:LB-10053/136 route sourced
locally
BGP(9): update formatted for 1:100:VEID-1001:Blk-10000:VBS-50:LB-10053/136 VE ID
1001 VE Block Offset 10000 VE Block Size 50 Label Base 10053 /136
BGP(9): (base) 10.100.1.4 send UPDATE (format) 1:100:VEID-1001:Blk-10000:VBS-50:
LB-10053/136, next 10.100.1.1, metric 0, path Local, extended community RT:1:100
RT:32:64 L2VPN L2:0x0:MTU-1500 L2VPN L2:0x0:MTU-1500
BGP(9): 10.100.1.4 rcvd UPDATE w/ attr: nexthop 10.100.1.2, origin ?, localpref 100,
metric 0, originator 10.100.1.2, clusterlist 10.100.1.4, extended community
RT:1:100 L2VPN L2:0x0:MTU-1500
BGP(9): 10.100.1.4 rcvd 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136
BGP(9): bump net 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136, non bpath added
BGP(9): nettable_walker called for 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136
BGP(9): best path[0] 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136 source 10.100.1.1
nh 10.100.1.2 vpls-id: L2VPN L2:0x0:MTU-1500
BGP(9): add XC RIB route 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136 masklen 136
L2VPN L2:0x0:MTU-1500 pathcount: 1 [0] LDP source:10.100.1.1 nexthop:10.100.1.2
RT:1:100
BGP(9): update formatted for 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136 VE ID
10002 VE Block Offset 1000 VE Block Size 50 Label Base 3053 /136
BGPSSA ssacount is 0
PE1#show bgp l2vpn vpls rd 1:100
BGP table version is 5, local router ID is 10.100.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:100
*> 1:100:VEID-1001:Blk-1000/136
0.0.0.0 32768 ?
*> 1:100:VEID-1001:Blk-10000/136
0.0.0.0 32768 ?
*>i 1:100:VEID-10002:Blk-1000/136
10.100.1.2 0 100 0 ?
*>i 1:100:VEID-10002:Blk-10000/136
10.100.1.2 0 100 0 ?
PE2#show bgp l2vpn vpls rd 1:100
BGP table version is 6, local router ID is 10.100.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:100
*>i 1:100:VEID-1001:Blk-1000/136
10.100.1.1 0 100 0 ?
*>i 1:100:VEID-1001:Blk-10000/136
10.100.1.1 0 100 0 ?
*> 1:100:VEID-10002:Blk-1000/136
0.0.0.0 32768 ?
*> 1:100:VEID-10002:Blk-10000/136
0.0.0.0 32768 ?
Análise do PE1 e do PE2 Exchange
O PE1 e o PE2 anunciaram dois blocos de rótulo um para o outro.
O PE1 primeiro anuncia uma atualização BGP inicial para o PE2:
BGP(9): update formatted for 1:100:VEID-1001:Blk-1000:VBS-50:LB-10000/136 VE ID
1001 VE Block Offset 1000 VE Block Size 50 Label Base 10000 /136
BGP(9): (base) 10.100.1.4 send UPDATE (format) 1:100:VEID-1001:Blk-1000:VBS-50:
LB-10000/136, next 10.100.1.1, metric 0, path Local, extended community
RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500
Essa atualização tem o NLRI definido de acordo com a configuração em PE1.
O PE1 recebe a atualização BGP inicial do PE2.
BGP(9): 10.100.1.4 rcvd UPDATE w/ attr: nexthop 10.100.1.2, origin ?, localpref
100, metric 0, originator 10.100.1.2, clusterlist 10.100.1.4, extended
community RT:1:100 L2VPN L2:0x0:MTU-1500
BGP(9): 10.100.1.4 rcvd 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136
O PE2 anuncia o prefixo inicial com os valores VE-ID 10002, VBO = 10000, VBS = 50, LB = 3000.
O PE1 nota que o PE2 está fora do intervalo desde que o PE1 começou com o bloco de etiquetas LB para (LB + VBS - 1) ou de 10000 para (10000 + 50 - 1) = 10049.
O PE1 deve determinar se o VBO está dentro do intervalo de sua configuração. Portanto, o VE-ID do PE2 precisa ser verificado em relação ao intervalo anunciado pelo PE1. O cálculo é VBO <= VE-ID < VBO + VBS. Nesse caso, 1000 <= 10002 < 1000 + 50, o que não é verdade. Portanto, o PE1 precisa enviar um novo bloco de rótulo para acomodar o VE-ID fora de alcance do PE2. Em reação à atualização inicial do PE2, o PE1 formata e envia uma nova atualização de BGP adicional ao PE2. O PE1 agora usa um novo VBO de 10000.
BGP(9): update formatted for 1:100:VEID-1001:Blk-10000:VBS-50:LB-10053/136
VE ID 1001 VE Block Offset 10000 VE Block Size 50 Label Base 10053 /136
BGP(9): (base) 10.100.1.4 send UPDATE (format) 1:100:VEID-1001:Blk-10000:
VBS-50:LB-10053/136, next 10.100.1.1, metric 0, path Local, extended
community RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500 L2VPN L2:0x0:MTU-1500
Para PE1, o VBO é 10000, VBS é 50, LB é 10053. A verificação para PE2 é VBO <= VE-ID < VBO + VBS. Nesse caso, 10000 <= 10002 < 10000 + 50, o que é verdade. O PE2 pode escolher um rótulo remoto desse novo bloco de rótulo [10053 - 10102] do PE1. Em outras palavras, PE1 adicionou um novo bloco de rótulo para acomodar PE2 e enviou duas mensagens de atualização BGP.
O mesmo acontece na direção oposta. O PE2 recebe a atualização BGP inicial do PE1. Esta atualização tem estes valores VE-ID 1001, VBO = 1000, VBS = 50, LB = 10000.
O PE2 nota que o VE-ID do PE1 está fora do alcance com a atualização inicial do PE2. A verificação de PE1 é VBO <= VE-ID < VBO + VBS ou 10000 <= 1001 < 10000 + 50. Em resposta, o PE2 envia essa segunda atualização de BGP, com um novo bloco de rótulo [3053 - 3102] que acomoda o VE-ID de 1001 de PE1 porque a verificação de PE1 é VBO <= VE-ID < VBO + VBS ou 1000 <= 1001 < 100 50.
BGP(9): 10.100.1.4 rcvd UPDATE w/ attr: nexthop 10.100.1.2, origin ?,
localpref 100, metric 0, originator 10.100.1.2, clusterlist 10.100.1.4,
extended community RT:1:100 L2VPN L2:0x0:MTU-1500
BGP(9): 10.100.1.4 rcvd 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136
Detalhes do prefixo
Estes são os detalhes dos dois prefixos originados pelo PE1:
PE1#show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 1000
BGP routing table entry for 1:100:VEID-1001:Blk-1000/136, version 2
Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)
Not advertised to any peer
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (10.100.1.1)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
AGI version(0), VE Block Size(50) Label Base(10000)
Extended Community: RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500
rx pathid: 0, tx pathid: 0x0
PE1#show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 10000
BGP routing table entry for 1:100:VEID-1001:Blk-10000/136, version 4
Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)
Not advertised to any peer
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (10.100.1.1)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
AGI version(0), VE Block Size(50) Label Base(10053)
Extended Community: RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500
L2VPN L2:0x0:MTU-1500
rx pathid: 0, tx pathid: 0x0
Aqui, dois roteadores PE têm esquemas de números não contíguos, o que faz com que cada PE envie duas atualizações BGP. Se houver muitos roteadores PE com esquemas numéricos não contíguos, o número de atualizações BGP cresce rapidamente muito.
www.cisco.com diz: "Por exemplo, sequências de numeração de ID de VE como 1, 2, 3 ou 501, 502, 503 são boas porque os IDs de VE são contíguos. Um esquema de numeração como 100, 200, 300 é ruim porque não é contíguo."
Os primeiros exemplos de 1, 2, 3 ou 501, 502, 503 são números contíguos, portanto cada roteador PE precisa enviar apenas um prefixo de VPLS L2VPN. Com o terceiro exemplo (100, 200, 300), cada PE precisa enviar muitos prefixos VPLS L2VPN. Para números não contíguos, um intervalo de VE suficientemente grande manteria o número de prefixos a serem anunciados abaixo. No entanto, a quantidade de etiquetas reservadas (desperdiçadas) é ainda maior.
Interoperabilidade
Se o Refletor de Rota BGP (RR - BGP Route Reflector) executa um software que não entende o RFC 4761, mas tem suporte para o RFC 4762, o comando de configuração vizinho de BGP x.x.x.x prefix-length-size 2 é necessário no RR para que ele possa refletir as atualizações de BGP usadas para o RFC 47766661.
Os prefixos geralmente são enviados com um comprimento de 1 byte. O software Cisco IOS implementou o rascunho 'draft-ietf-l2vpn-signaling-08', que posteriormente se tornou RFC 6074. Um campo de comprimento de 1 byte foi escolhido no momento, indicando o comprimento em bits.
O Provisionamento, a Identificação Automática e a Sinalização RFC 6074 em Redes Virtuais Privadas (L2VPNs - Virtual Private Networks) de Camada 2 especifica que a codificação NLRI para a descoberta automática de BGP deve ter um comprimento de 2 bytes. Os 2 bytes indicam quantos bytes de prefixo seguem no prefixo de comprimento variável.
A seção 7 do RFC 6074, "Interoperabilidade BGP-AD e VPLS-BGP", afirma:
"Tanto o BGP-AD como o VPLS-BGP [RFC4761] usam o mesmo AFI/SAFI. Para que o BGP-AD e o VPLS-BGP coexistam, o comprimento do NLRI deve ser usado como um demultiplexador.
O BGP-AD NLRI tem um comprimento de NLRI de 12 bytes, contendo somente um RD de 8 bytes e um VSI-ID de 4 bytes. O VPLS-BGP [RFC4761] usa um comprimento NLRI de 17 bytes. Portanto, as implementações de BGP-AD devem ignorar NLRI que são maiores que 12 bytes."
Se o comando neighbor x.x.x.x prefix-length-size 2 não estiver presente nos RR, o vizinho BGP não aparecerá e o RR interpreta o campo length como 1 byte apenas. Esta notificação aparece no RR:
%BGP-3-NOTIFICATION: sent to neighbor 10.100.1.2 3/10 (illegal network) 1 bytes FF
%BGP-4-MSGDUMP: unsupported or mal-formatted message received from 10.100.1.2:
FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 005E 0200 0000 4780 0E1C 0019 4104 0A64
0102 0000 1100 0000 0100 0000 6427 1227 1000 3200 BB80 4001 0102 4002 0080 0404
*Feb 15 12:14:11.561: %BGP_SESSION-5-ADJCHANGE: neighbor 10.100.1.2 L2VPN Vpls
topology base removed from session BGP Notification sent
*Feb 15 12:14:11.561: %BGP_SESSION-5-ADJCHANGE: neighbor 10.100.1.2 IPv4 Unicast
topology base removed from session BGP Notification sent
Essa notificação aparece no roteador PE:
%BGP-3-NOTIFICATION: received from neighbor 10.100.1.4 3/10 (illegal network)
1 bytes FD
Isso ocorre porque, na implementação original da descoberta automática de BGP no software Cisco IOS, o campo de comprimento era de 1 byte.
Se você colocar o comando neighbor x.x.x.x prefix-length-size 2 no RR, as notificações não serão exibidas.
router bgp 1
neighbor 10.100.1.2 remote-as 1
neighbor 10.100.1.2 update-source Loopback0
!
address-family l2vpn vpls
neighbor 10.100.1.2 activate
neighbor 10.100.1.2 send-community extended
neighbor 10.100.1.2 prefix-length-size 2
neighbor 10.100.1.2 route-reflector-client
Feedback