Contents

Introduction

Problema

Arquitetura da solução

Identificação do ponto de extremidade do roteador PE

Identidade VPLS e etiquetas MPLS

Informações de encapsulamento

Prefixo de descoberta automática de BGP VPLS e prefixo de sinalização de BGP de VPLS

Exemplo de configuração do software Cisco IOS

Bloco de Rótulo Anunciado

Destinos do Distinguista de Rota e da Rota

Exemplo de configuração de PE1

Verificar intervalo de rótulo

Verificar etiquetas

Verificar bloco de rótulo

Verificar prefixo anunciado

Exibir prefixo em detalhes

Anuncie, receba e processe blocos de rótulo em mensagens de atualização de BGP

PE2: Receber atualização de BGP

PE2: Localizar uma etiqueta

PE2: Enviar prefixo para PE1

PE1: Localizar uma etiqueta

Comandos de verificação adicionais

Vários prefixos L2VPN VPLS anunciados pelo roteador PE para um VFI

Configuração do PE1

Configuração do PE2

Blocos iniciais de etiquetas

PE1 e PE2 Exchange

Análise do PE1 e do PE2 Exchange

Detalhes do prefixo

Interoperabilidade

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:

1. 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.

2. 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.

Note: Na implementação do software Cisco IOS e Cisco NX-OS, todos os roteadores PE devem ter o mesmo RD no mesmo domínio 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

Note: O VBS padrão (10) é pequeno para que os rótulos locais não sejam desperdiçados.

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