Rotulado e sem rótulo em um vizinho BGP no IOS-XR

Este documento descreve o comportamento de receber e anunciar caminhos sem rótulo e rotulados em uma sessão de BGP no Cisco IOS^® XR.

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento é específico do Cisco IOS^® XR, mas não está restrito a uma versão ou hardware de software específico.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Introduction

Address Family Identifier (AFI) é uma indicação do tipo de rota BGP. Exemplos são 1 para IPv4 e 2 para IPv6.

O SAFI (Identificador da Família de Endereços Subsequente) é mais uma indicação do tipo de rota. Os exemplos são 1 para uma rota não rotulada e 4 para uma rota rotulada.

O unicast não rotulado para IPv4 é AFI 1 e SAFI 1.

O unicast rotulado para IPv4 é AFI 1 e SAFI 4.

O unicast não rotulado para IPv6 é AFI 2 e SAFI 1.

O unicast rotulado para IPv6 é AFI 2 e SAFI 4.

A LU (Labeled unicast) é frequentemente chamada de RFC 3107 "Transportando informações de rótulo em BGP-4".

Aqui, U se refere a unicast não rotulado, portanto SAFI 1 e LU se referem a unicast rotulado, portanto SAFI 4.

Observe que o Cisco IOS^® XR precisa de "alocar rótulo tudo| política de rota ..." ou a rota não será originada ou propagada para o próximo locutor de BGP como SAFI 4.

O unicast IPv4/v6 e o unicast rotulado em uma sessão BGP não eram suportados no Cisco IOS^® XR .

No Cisco IOS^® XR, o suporte para ter não rotulado e rotulado em uma sessão BGP foi feito em 6.2.1.

Quando a execução de ambos em uma sessão não é suportada, isso é problemático, pois a última atualização/retirada recebida substitui a anterior, mesmo que ela tenha sido recebida em outro SAFI.

Quando você configura o SAFI 1 e 4 na mesma sessão BGP em um roteador executando o código IOS-XR antes do IOS-XR 6.2.1, o roteador emite o seguinte aviso:

bgp[1051]: %ROUTING-BGP-4-INCOMPATIBLE_AFI : IPv4 Unicast and IPv4 Labeled-unicast Address families together are not supported under the same neighbor.

Essa mensagem de aviso foi apresentada no IOS-XR 5.3.0 e no IOS-XR 5.2.2.

Intercâmbio de recursos

Os recursos trocados entre os peers BGP devem corresponder. Caso contrário, a sessão do BGP não será exibida.

Esta é uma captura do Wireshark da capacidade trocada para AFI 1/SAFI 1 e AFI 1/SAFI 4 na mensagem BGP Open:

Imagem 1

Aqui está um exemplo para IOS-XR configurado com LU somente em uma sessão para IOS configurada somente com U.

IOS-XR:

RP/0/0/CPU0:R4#show bgp neighbor 10.100.1.8
 
BGP neighbor is 10.100.1.8
 Remote AS 65003, local AS 65003, internal link
 Remote router ID 0.0.0.0
  BGP state = Idle
…

  Connections established 0; dropped 0
  Local host: 10.100.1.4, Local port: 179, IF Handle: 0x00000000
  Foreign host: 10.100.1.8, Foreign port: 33396
  Last reset 00:00:14, due to BGP Notification sent: unsupported/disjoint capability
  Time since last notification sent to neighbor: 00:00:14
  Error Code: unsupported/disjoint capability
  Notification data sent:
    None

O roteador IOS imprime uma mensagem de syslog para este erro de configuração:

*Aug  8 12:40:44.719: %BGP-3-NOTIFICATION: received from neighbor 10.100.1.4 active 2/7 (unsupported/disjoint capability) 0 by

Especificações de implementação do IOS-XR

Configurando U ou LU

Você configura "address-family ipv4 unicast" sob o comando BGP neighbor para ativar o unicast ipv4 para a sessão BGP.

Você configura "address-family ipv6 unicast" sob o comando BGP neighbor para ativar o unicast ipv6 para a sessão BGP.

Você configura "address-family ipv4 labeled-unicast" no comando BGP neighbor para ativar o ipv4 rotulado unicast para a sessão BGP.

Você configura "address-family ipv6 labeled-unicast" no comando BGP neighbor para ativar o ipv6 rotulado unicast para a sessão BGP.

No IOS-XR, a combinação AFI/SAFI é configurada por peer BGP.

Este é um exemplo de uma sessão BGP com SAFI 1 e 4:

router bgp 65003
 address-family ipv4 unicast
  redistribute connected
  allocate-label all unlabeled-path
   …
  neighbor 10.100.1.7
   remote-as 65003
   update-source Loopback0
   address-family ipv4 unicast
    route-reflector-client
   !
   address-family ipv4 labeled-unicast
    route-reflector-client

Observe que ainda há apenas o "address family unicast" e não "address-family label-unicast" no roteador BGP. Os caminhos SAFI 1 e 4 são armazenados nesta única tabela BGP.

Tabela de BGP

Independentemente do IOS-XR ser mais antigo ou mais recente que 6.2.1, há apenas uma tabela BGP para armazenar as rotas U e LU. Isso é evidente pelo fato de que você só pode configurar (ativar) "address-family ipv4 unicast" ou "address-family ipv6 unicast" no roteador bgp. Você não pode configurar "address-family ipv4 labeled-unicast" ou "address-family ipv6 labeled-unicast" no roteador bgp.

O caminho U e LU pode ser idêntico. Antes do IOS-XR 6.2.1, receber o mesmo caminho novamente, mas desta vez com ou sem um rótulo, substituiria o caminho recebido anteriormente. Depois do IOS-XR 6.2.1, os dois caminhos idênticos serão vistos como diferentes se diferirem apenas pelo rótulo. As adições, exclusões ou modificações do caminho são executadas por SAFIs diferentes.

Aqui está um exemplo de uma rota na tabela BGP com AFI 1/SAFI 4. Como a alocação de rótulo está habilitada para todos os prefixos, esse caminho será armazenado com um rótulo local. Como há apenas uma tabela BGP para armazenar rotas U e LU, o prefixo aparece com ambos os comandos "show bgp ipv4 unicast" e "show bgp ipv4 labeled-unicast"!

RP/0/0/CPU0:R4#show bgp ipv4 unicast 10.100.1.1/32
BGP routing table entry for 10.100.1.1/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                  5           5
    Local Label: 24000
Last Modified: Aug  6 15:03:59.574 for 16:06:13
Paths: (1 available, best #1)
  Advertised to update-groups (with more than one peer):
    0.3 0.4
  Advertised to peers (in unique update groups):
    10.1.45.5
  Path #1: Received by speaker 0
  Advertised to update-groups (with more than one peer):
    0.3 0.4
  Advertised to peers (in unique update groups):
    10.1.45.5
  65002 65001
    10.1.24.2 from 10.1.24.2 (10.100.1.2)
      Received Label 24003
      Origin IGP, localpref 100, valid, external, best, group-best, labeled-unicast
      Received Path ID 0, Local Path ID 0, version 5
      Origin-AS validity: not-found

Observe que o caminho está marcado com "rotulado-unicast".

RP/0/0/CPU0:R4#show bgp ipv4 labeled-unicast 10.100.1.1/32
BGP routing table entry for 10.100.1.1/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                  5           5
    Local Label: 24000
Last Modified: Aug  6 15:03:59.574 for 16:08:41
Paths: (1 available, best #1)
  Advertised to update-groups (with more than one peer):
    0.3 0.4
  Advertised to peers (in unique update groups):
    10.1.45.5
  Path #1: Received by speaker 0
  Advertised to update-groups (with more than one peer):
    0.3 0.4
  Advertised to peers (in unique update groups):
    10.1.45.5
  65002 65001
    10.1.24.2 from 10.1.24.2 (10.100.1.2)
      Received Label 24003
      Origin IGP, localpref 100, valid, external, best, group-best, labeled-unicast
      Received Path ID 0, Local Path ID 0, version 5
      Origin-AS validity: not-found

Observe que o caminho está marcado com "rotulado-unicast".

Se o caminho estiver presente como U e LU, o ID do caminho local será diferente.

RP/0/0/CPU0:R4#show bgp ipv4 labeled-unicast 10.100.1.1/32 detail
BGP routing table entry for 10.100.1.1/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                 30          30
    Local Label: 24003 (no rewrite);
    Flags: 0x00003028+0x00010000;
Last Modified: Aug 30 10:45:50.502 for 00:01:59
Paths: (2 available, best #1)
  Advertised IPv4 Unicast paths to peers (in unique update groups):
    10.100.1.8      10.100.1.9
  Advertised IPv4 Labeled-unicast paths to update-groups (with more than one peer):
    0.8
  Path #1: Received by speaker 0
  Flags: 0x4000000009060205, import: 0x20
  Advertised IPv4 Unicast paths to peers (in unique update groups):
    10.100.1.8      10.100.1.9
  Advertised IPv4 Labeled-unicast paths to update-groups (with more than one peer):
    0.8
  65001, (Received from a RR-client)
    10.100.1.9 (metric 2) from 10.100.1.9 (10.100.1.9)
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
      Received Path ID 0, Local Path ID 1, version 29
  Path #2: Received by speaker 0
  Flags: 0x4080000008020205, import: 0x20
  Not advertised to any peer
  65001, (Received from a RR-client)
    10.100.1.9 (metric 2) from 10.100.1.9 (10.100.1.9)
      Received Label 24001
      Origin IGP, metric 0, localpref 100, valid, internal, labeled-unicast
      Received Path ID 0, Local Path ID 0, version 0

Habilitando a alocação de rótulo local

Você deve configurar o comando "Allocation-label" para que os caminhos recebidos ou originados no BGP tenham um rótulo MPLS local. Sem esse comando, as rotas não terão um rótulo local.

RP/0/0/CPU0:R4#conf t
RP/0/0/CPU0:R4(config)#router bgp 65003
RP/0/0/CPU0:R4(config-bgp)# address-family ipv4 unicast
RP/0/0/CPU0:R4(config-bgp-af)#allocate-label ?
  all           Allocate labels for all prefixes
  route-policy  Use a route policy to select prefixes for label allocation

A alocação de rótulo ocorre para todas as rotas ou de acordo com a política de rota configurada.

Nova implementação no IOS-XR

Na antiga implementação no IOS-XR, um aviso é dado ao configurar a U e a LU na mesma sessão de BGP. O aviso é apresentado nas versões 5.3.0 e 5.2.2 do IOS-XR. O aviso é removido no IOS-XR versão 6.2.1, porque rotulados e não rotulados são suportados na mesma sessão BGP.

Exemplo:

RP/0/0/CPU0:ios#conf t
RP/0/0/CPU0:ios(config)#router bgp 65001
RP/0/0/CPU0:ios(config-bgp)#add ipv4 unicast
RP/0/0/CPU0:ios(config-bgp-af)#exit
RP/0/0/CPU0:ios(config-bgp)#neighbor 10.0.0.1
RP/0/0/CPU0:ios(config-bgp-nbr)#remote-as 65001
RP/0/0/CPU0:ios(config-bgp-nbr)#exit
RP/0/0/CPU0:ios(config-bgp)#neighbor 10.0.0.1
RP/0/0/CPU0:ios(config-bgp-nbr)#address-family ipv4 unicast
RP/0/0/CPU0:ios(config-bgp-nbr-af)#exit
RP/0/0/CPU0:ios(config-bgp-nbr)#address-family ipv4 labeled-unicast
RP/0/0/CPU0:ios(config-bgp-nbr-af)#commit

RP/0/0/CPU0:Aug 21 14:14:22.222 : bgp[1052]: %ROUTING-BGP-4-INCOMPATIBLE_AFI : IPv4 Unicast and IPv4 Labeled-unicast Address families together are not supported under the same neighbor. 

A explicação para esta mensagem de erro:

Essa mensagem indica que o usuário configurou as famílias de endereços IPv4 unicast e IPv4 unicast rotulado ou IPv6 unicast e IPv6 unicast rotulado juntas sob o mesmo vizinho. Esta configuração específica não é suportada. 

Ação recomendada: configurar duas sessões de vizinhos no roteador. Configure a família de endereços unicast sob a primeira sessão vizinha e configure a família de endereços unicast rotulada sob a segunda sessão vizinha.

Exemplo de configuração para duas sessões BGP entre um par de roteadores IOS-XR. Use um endereço diferente (loopback) para cada sessão BGP.

hostname R1

interface Loopback0
 ipv4 address 10.100.1.1 255.255.255.255
!
interface Loopback1
 ipv4 address 10.100.1.101 255.255.255.255
!
router bgp 65001
 address-family ipv4 unicast
 !
 neighbor 10.100.1.2
  remote-as 65001
 update-source Loopback0
  address-family ipv4 unicast
  !
 !
 neighbor 10.100.1.102
  remote-as 65001
  update-source Loopback1
  address-family ipv4 labeled-unicast
  !
 ! 
   
hostname R2

interface Loopback0
 ipv4 address 10.100.1.2 255.255.255.255
!
interface Loopback1
 ipv4 address 10.100.1.102 255.255.255.255
!
router bgp 65001
 address-family ipv4 unicast
 !
neighbor 10.100.1.1
  remote-as 65001
 update-source Loopback0
  address-family ipv4 unicast
  !
 !
 neighbor 10.100.1.101
  remote-as 65001
  update-source Loopback1
  address-family ipv4 labeled-unicast
  !
 !

No IOS-XR 6.2.1, U e LU são suportados na mesma sessão BGP no VRF padrão!

Não importa se a sessão BGP é um BGP interno ou externo.

U e LU na mesma sessão não são suportadas para alto-falantes BGP em qualquer VRF não padrão.

Atualizar grupos

Antes do IOS-XR 6.2.1, todos os alto-falantes U, LU e U + LU BGP eram mantidos em grupos de atualização separados. Depois da versão 6.2.1 do IOS-XR, isso não é mais verdade. Alguns alto-falantes BGP em um grupo de atualização podem ser apenas U, ou apenas LU, ou U e LU.

Propagação de rota

A tabela a seguir mostra o comportamento de anúncio e retirada para diferentes cenários. Há 16 cenários.

Todos se aplicam ao IOS-XR versão 6.2.1 e posterior, a menos que mencionado de outra forma na coluna de comentários.

Caso	Tipo de caminho/endereço	Rótulo local presente?	NHS ou NHU	SAFI de grupo de atualização	Anunciar ou retirar?	Comentários
1	Caminho não rotulado, ou seja, sem rótulo rx	Yes	NHS	SAFI-1	Anunciar por padrão Retirar com comando advertise local-labeled-route (safi-unicast)disable	Só é possível após 6.5.1.
2				SAFI-4	Publicidade	Só é possível após 6.5.1. Rotas de redist IPv4/v6 e 6PE: NHS implícito sempre
3			NHU	SAFI-1	Publicidade	Só é possível após 6.5.1.
4				SAFI-4	Retirar	Só é possível após 6.5.1. Rotas de redist IPv4/v6 e 6PE: NHU ignorada; NHS implícito sempre
5		No	NHS	SAFI-1	Publicidade
6				SAFI-4	Retirar
7			NHU	SAFI-1	Publicidade
8				SAFI-4	Retirar
9	Caminho rotulado, ou seja, com rótulo rx	Yes	NHS	SAFI-1	Anunciar por padrão Retirar com o comando advertise local-labeled-route (safi-unicast) disable	Antes de 6.2.1: o comportamento padrão é para Anunciar.
10				SAFI-4	Publicidade
11			NHU	SAFI-1	Retirar	Antes de 6.2.1:  comportamento é anunciar.
12				SAFI-4	Publicidade
13		No	NHS	SAFI-1	Publicidade
14				SAFI-4	Retirar
15			NHU	SAFI-1	Retirar	Antes de 6.2.1:  comportamento é anunciar.
16				SAFI-4	Publicidade

Tabela 1 Comportamento de anúncio para sessões iBGP e eBGP

NHS = Próximo salto

NHU = Next Hop Unchanged.

Se a NHU estiver em vigor, isso significa que o autossuficiência do próximo salto não está configurado para uma sessão iBGP.

Observe que o NHS é sempre o caso quando o alto-falante BGP envia para um peer eBGP.

Pode haver NHS ou NHU para um alto-falante iBGP, dependendo da configuração do Next-Hop-Self. O comportamento padrão para peers iBGP é NHU.

Para a segunda coluna: observe que o caminho é considerado não rotulado ou rotulado somente se o melhor caminho ou um dos caminhos marcados com caminho adicional não estiver rotulado ou rotulado.

Para a propagação da rota, importa quais características o melhor caminho tem. Dependendo das características (colunas 2 a 4), ele determina se o caminho é anunciado como U, ou LU, ou ambos.

Se o recurso Caminhos adicionais (ADD-PATH) estiver ativado e um caminho estiver marcado com "caminho adicional", as características desse caminho também desempenharão um papel no modo como esse caminho será anunciado.

"Rótulo local presente?: Não" significa o seguinte: é possível que um rótulo seja recebido com a atualização recebida, mas o rótulo não está instalado. O rótulo local não será instalado se o comando "alocar rótulo" não estiver lá.

Você pode verificar se o rótulo local está presente observando o prefixo em detalhes. Use "show bgp <prefix> detail" ou "show route <prefix> detail".

No exemplo a seguir, o prefixo é recebido sem um rótulo (portanto, sobre um peering SAFI 1) e nenhum rótulo local é atribuído:

RP/0/0/CPU0:R2#show bgp ipv4 labeled-unicast 10.100.1.5/32 detail
BGP routing table entry for 10.100.1.5/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                  3           3
    Flags: 0x04001001+0x00000000;
Last Modified: Sep  5 03:44:45.647 for 01:01:27
Paths: (1 available, best #1)
  Advertised to update-groups (with more than one peer):
    0.3
  Path #1: Received by speaker 0
  Flags: 0x4000000001040207, import: 0x00
  Advertised to update-groups (with more than one peer):
    0.3
  Local, (Received from a RR-client)
    10.100.1.1 (metric 2) from 10.100.1.1 (10.100.1.1)
      Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best
      Received Path ID 0, Local Path ID 1, version 3

RP/0/0/CPU0:R2#show route 10.100.1.5/32 detail

Routing entry for 10.100.1.5/32
  Known via "bgp 65001", distance 200, metric 0, type internal
  Installed Sep  5 03:44:45.480 for 01:01:37
  Routing Descriptor Blocks
    10.100.1.1, from 10.100.1.1
      Route metric is 0
      Label: None
      Tunnel ID: None
      Extended communities count: 0
      NHID:0x0(Ref:0)
  Route version is 0x23 (35)
  No local label
  IP Precedence: Not Set
  QoS Group ID: Not Set
  Flow-tag: Not Set
  Route Priority: RIB_PRIORITY_RECURSIVE (12) SVD Type RIB_SVD_TYPE_LOCAL
  Download Priority 4, Download Version 52
  No advertising protos.

Alocando um rótulo local

Alocar rótulo para caminhos não rotulados

Por padrão, os caminhos sem rótulo (SAFI 1) nunca são rotulados, mesmo quando o comando "alocar rótulo" está configurado.

A partir da versão 6.5.1 do IOS-XR, há a palavra-chave "caminho sem rótulo" para o comando "rótulo de alocação", de modo que também os caminhos sem rótulo possam receber um rótulo.

RP/0/0/CPU0:R4#conf t
RP/0/0/CPU0:R4(config)#router bgp 65003
RP/0/0/CPU0:R4(config-bgp)# address-family ipv4 unicast
RP/0/0/CPU0:R4(config-bgp-af)#allocate-label all ?
  unlabeled-path  Allocate label for unlabeled paths too
  <cr>
RP/0/0/CPU0:R4(config-bgp-af)#allocate-label all unlabeled-path ?
  <cr>
RP/0/0/CPU0:R4(config-bgp-af)#allocate-label all unlabeled-path
RP/0/0/CPU0:R4(config-bgp-af)#commit

O caminho é um caminho SAFI 1, portanto, não há rótulo recebido.

Devido ao comando "unlabel-path", agora há um rótulo local.

RP/0/0/CPU0:R4#show bgp ipv4 labeled-unicast 10.100.1.1/32 detail
BGP routing table entry for 10.100.1.1/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                 16          16
    Local Label: 24003 (no rewrite);
    Flags: 0x01303028+0x00000000;
Last Modified: Aug 27 19:08:47.502 for 00:00:59
Paths: (1 available, best #1)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.3
  Advertised IPv4 Labeled-unicast paths to update-groups (with more than one peer):
    0.7
  Advertised IPv4 Labeled-unicast paths to peers (in unique update groups):
    10.1.45.5
  Path #1: Received by speaker 0
  Flags: 0x4000000009040207, import: 0x20
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.3
  Advertised IPv4 Labeled-unicast paths to update-groups (with more than one peer):
    0.7
  Advertised IPv4 Labeled-unicast paths to peers (in unique update groups):
    10.1.45.5
  65001, (Received from a RR-client)
    10.100.1.10 (metric 2) from 10.100.1.10 (10.100.1.10)
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
      Received Path ID 0, Local Path ID 1, version 16

RP/0/0/CPU0:R4#show route 10.100.1.1/32 detail

Routing entry for 10.100.1.1/32
  Known via "bgp 65003", distance 200, metric 0
  …
  Route version is 0x4 (4)
  Local Label: 0x5dc3 (24003)
  IP Precedence: Not Set
  …

Isso permitirá os casos 1 a 4 na tabela 1.

Para descobrir por que um rótulo local ainda é atribuído quando o comando "alocar rótulo" é removido, execute o comando debug "debug bgp label".

Aqui está um exemplo:

RP/0/0/CPU0:R4#debug bgp label

RP/0/0/CPU0:R4#show debug

####  debug flags set from tty 'con0_0_CPU0'  ####
ip-bgp default label flag is ON with value '##########'

É melhor habilitar essa depuração para um prefixo específico ou grupo de prefixos. Aqui está um exemplo:

RP/0/0/CPU0:R4#sh running-config route-policy match-prefix
route-policy match-prefix
  if destination in (10.100.1.1/32) then
    pass
  else
    drop
  endif
end-policy
!

RP/0/0/CPU0:R4#debug bgp label route-policy match-prefix 

RP/0/0/CPU0:R4#show debug

####  debug flags set from tty 'con0_0_CPU0'  ####

ip-bgp default label flag is ON with value '######match-prefix####'

RP/0/0/CPU0:R4#con t
RP/0/0/CPU0:R4(config)#router bgp 65003
RP/0/0/CPU0:R4(config-bgp)# address-family ipv4 unicast
RP/0/0/CPU0:R4(config-bgp-af)#no   allocate-label all
RP/0/0/CPU0:R4(config-bgp-af)#commit

RP/0/0/CPU0:Aug 23 12:43:02.786 : bgp[1048]: [default-lbl] (ip4u): Label computation done: table=TBL:default (1/1), net=10.100.1.1/32: netfl=0x05043001, path=0x1073ed5c(10.1.24.2/32,10.1.24.2,0,0x400000000d060001), pathrcvdlabel=24002: asbr=1, rr=0/1, nhselfcount=1: result="label required"

Você pode ver que esse roteador recebeu um rótulo para o prefixo 10.100.1.1/32, é um ASBR, não é um RR e tem o Next-Hop-Self para pelo menos uma sessão BGP. Isso faz com que o prefixo precise de um rótulo local.

O rótulo local permanece:

RP/0/0/CPU0:R4#show bgp ipv4 unicast 10.100.1.1/32 detail
BGP routing table entry for 10.100.1.1/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                 13          13
    Local Label: 16002 (no rewrite);
    Flags: 0x05043001+0x00000200;
Last Modified: Aug 23 12:37:11.133 for 00:05:53
Paths: (1 available, best #1)
  Advertised to update-groups (with more than one peer):
    0.6
  Advertised to peers (in unique update groups):
    10.1.46.6       10.100.1.8      10.100.1.7
  Path #1: Received by speaker 0
  Flags: 0x400000000d060001, import: 0x1f
  Advertised to update-groups (with more than one peer):
    0.6
  Advertised to peers (in unique update groups):
    10.1.46.6       10.100.1.8      10.100.1.7
  65002 65001
    10.1.24.2 from 10.1.24.2 (10.100.1.2)
      Received Label 24002
      Origin IGP, localpref 100, valid, external, best, group-best, import-candidate
      Received Path ID 0, Local Path ID 1, version 13
      Origin-AS validity: not-found


RP/0/0/CPU0:R4#show route 10.100.1.1/32 detail 
Routing entry for 10.100.1.1/32
  Known via "bgp 65003", distance 20, metric 0, [ei]-bgp, labeled unicast (3107)
  Tag 65002, type external
  Installed Aug 23 12:37:11.440 for 00:06:02
  Routing Descriptor Blocks
    10.1.24.2, from 10.1.24.2, BGP external
      Route metric is 0
      Label: 0x5dc2 (24002)
      Tunnel ID: None
      Extended communities count: 0
      NHID:0x0(Ref:0)
  Route version is 0x4 (4)
  Local Label: 0x3e82 (16002)
  IP Precedence: Not Set
  QoS Group ID: Not Set
  Route Priority: RIB_PRIORITY_NON_RECURSIVE_LOW (11) SVD Type RIB_SVD_TYPE_LOCAL
 Download Priority 4, Download Version 28
  No advertising protos.

A depuração mostra a seguinte mensagem quando um rótulo local não é necessário:

RP/0/0/CPU0:Aug 23 13:01:15.801 : bgp[1048]: [default-lbl]: Prefix 10.100.1.1/32:()doesn't require label, releasing

RP/0/0/CPU0:Aug 23 13:01:15.801 : bgp[1048]: [default-lbl]: bgp_label_release_label: perform label release onnet 10.100.1.1/32net retain 0 label_retain 0

Se o prefixo estiver no LFIB depende se o prefixo foi recebido rotulado ou não e se o rótulo de alocação se aplica a esse prefixo.

O rótulo recebido é 24002 para o seguinte prefixo.  Ele não está instalado no LFIB, porque o BGP não tem o comando de alocação de rótulo.

RP/0/0/CPU0:R4#show bgp ipv4 unicast  10.100.1.1/32
BGP routing table entry for 10.100.1.1/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                  4           4
    Local Label: 24002
Last Modified: Aug  8 13:52:57.276 for 00:00:36
Paths: (1 available, best #1)
  Advertised to update-groups (with more than one peer):
    0.6
  Advertised to peers (in unique update groups):
    10.100.1.7
  Path #1: Received by speaker 0
  Advertised to update-groups (with more than one peer):
    0.6
  Advertised to peers (in unique update groups):
    10.100.1.7
  65002 65001
    10.1.24.2 from 10.1.24.2 (10.100.1.2)
      Received Label 24002
      Origin IGP, localpref 100, valid, external, best, group-best, labeled-unicast
      Received Path ID 0, Local Path ID 0, version 4
      Origin-AS validity: not-found

router bgp 65003
 bgp unsafe-ebgp-policy
 address-family ipv4 unicast
 !

RP/0/0/CPU0:R4# show mpls forwarding
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
24000  Aggregate   10.1.24.0/24       default                      0
24001  Aggregate   10.1.45.0/24       default                      0

Se o comando alocar rótulo estiver presente, o rótulo local estará presente no LFIB:

router bgp 65003
 bgp unsafe-ebgp-policy
 address-family ipv4 unicast
  allocate-label all
 !

RP/0/0/CPU0:R4#show mpls forwarding
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
24000  Aggregate   10.1.24.0/24       default                      0
24001  Aggregate   10.1.45.0/24       default                      0
24002  24002       10.100.1.1/32                   10.1.24.2       0

Mesmo que o prefixo BGP seja recebido em uma sessão de LU, mas nenhum rótulo local seja atribuído, a rota não será anunciada em outra sessão de LU, caso o NHS esteja concluído. Este é o caso 14 na tabela 1.Este é o caso se a sessão BGP de saída for eBGP.

Exemplo:

RP/0/0/CPU0:R2#show bgp ipv4 unicast 10.100.1.1/32 detail
BGP routing table entry for 10.100.1.1/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                  3           3
    Flags: 0x00001001+0x00000000;
Last Modified: Aug 22 09:00:20.646 for 00:10:56
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Flags: 0x4080000001060001, import: 0x20
  Not advertised to any peer
  65001
    10.1.12.1 from 10.1.12.1 (10.100.1.1)
      Received Label 3
      Origin IGP, metric 0, localpref 100, valid, external, best, group-best, labeled-unicast
      Received Path ID 0, Local Path ID 0, version 3
      Origin-AS validity: not-found

RP/0/0/CPU0:R2#show route 10.100.1.1/32 detail

Routing entry for 10.100.1.1/32
  Known via "bgp 65002", distance 20, metric 0, labeled unicast (3107)
  Tag 65001, type external
  Installed Aug 22 09:00:20.416 for 00:10:59
  Routing Descriptor Blocks
    10.1.12.1, from 10.1.12.1, BGP external
      Route metric is 0
      Label: 0x100004 (1048580)
      Tunnel ID: None
      Binding Label: None
      Extended communities count: 0
      NHID:0x0(Ref:0)
  Route version is 0x1 (1)
  No local label
  IP Precedence: Not Set
  …

Isso é provavelmente causado por não ter o comando "Allocation-label" para endereço-família unicast no roteador BGP.

Você precisará reiniciar o processo BGP ao remover o comando "Allocation-label" para que o roteador remova os rótulos locais das rotas BGP.

O novo comando advertise local-labeled-route na tabela 1 é um novo comando para indicar que uma rota com rótulo local não deve ser anunciada como uma rota não rotulada via SAFI-1.

Esse comando é o seguinte:

   anunciar local-labeled-route [disable]

Esse comando é configurado na família de endereços vizinha. A função desse comando é indicar se uma rota IPv4/v6 com um rótulo local deve ser anunciada ou não para o vizinho BGP via unicast IPv4/v6 (SAFI 1).

O comportamento padrão é anunciar rotas com um rótulo local.

O novo comando também pode ser configurado como:

   anunciar local-labeled-route safi-unicast [disable]

Esse comando é configurado no grupo af da seção BGP. Sua função é a mesma acima e se aplica a todos os vizinhos de BGP.

O comportamento padrão é anunciar rotas com um rótulo local.

A linha "Anunciar rotas com rótulo local via SAFI Unicast"ou "Não anunciar rotas com rótulo local via SAFI Unicast" está presente no comando" show bgp neighbor" na família de endereços IPv4 Unicast para indicar que o alto-falante BGP permite ou não o anúncio de rotas com rótulo local.

Exemplo para o comportamento padrão:

RP/0/0/CPU0:R4#show bgp neighbor 10.1.45.5
…
For Address Family: IPv4 Unicast
  BGP neighbor version 5
  Update group: 0.1 Filter-group: 0.5  No Refresh request being processed
    Extended Nexthop Encoding: advertised and received
  Route refresh request: received 0, sent 0
  0 accepted prefixes, 0 are bestpaths
  Exact no. of prefixes denied : 0.
  Cumulative no. of prefixes denied: 0.
  Prefix advertised 2, suppressed 0, withdrawn 0
  Maximum prefixes allowed 1048576
  Threshold for warning message 75%, restart interval 0 min
  An EoR was not received during read-only mode
  Last ack version 5, Last synced ack version 0
  Outstanding version objects: current 0, max 1, refresh 0
  Additional-paths operation: None
  Advertise routes with local-label via Unicast SAFI
…

or

RP/0/0/CPU0:R4# conf t
RP/0/0/CPU0:R4(config)#router bgp 65003
RP/0/0/CPU0:R4(config-bgp)# neighbor 10.1.45.5
RP/0/0/CPU0:R4(config-bgp-nbr)#  address-family ipv4 unicast
RP/0/0/CPU0:R4(config-bgp-nbr-af)#advertise local-labeled-route disable
RP/0/0/CPU0:R4(config-bgp-nbr-af)#commit


RP/0/0/CPU0:R4#show bgp neighbor 10.1.45.5

BGP neighbor is 10.1.45.5
…
For Address Family: IPv4 Unicast
  BGP neighbor version 5
  Update group: 0.1 Filter-group: 0.5 (Update-group Change
pending)
  No Refresh request being processed
    Extended Nexthop Encoding: advertised and received
  Route refresh request: received 0, sent 0
  0 accepted prefixes, 0 are bestpaths
  Exact no. of prefixes denied : 0.
  Cumulative no. of prefixes denied: 0.
  Prefix advertised 2, suppressed 0, withdrawn 0
  Maximum prefixes allowed 1048576
  Threshold for warning message 75%, restart interval 0 min
  An EoR was not received during read-only mode
  Last ack version 5, Last synced ack version 0
  Outstanding version objects: current 0, max 1, refresh 0
  Additional-paths operation: None
  Do not advertise routes with local-label via Unicast SAFI

Cálculo do caminho de base

Não há alterações no processo de cálculo do melhor caminho. Se um caminho for SAFI 1 ou SAFI 4 ou se o caminho tiver um rótulo ou não, não fará diferença no processo de cálculo do melhor caminho. Portanto, não há preferência entre um caminho SAFI 1 ou SAFI 4. Isso independentemente se houver SAFI 1/SAFI 4 na mesma sessão BGP ou em sessões diferentes. Assim, se uma sessão BGP for SAFI 1 e 4, e um prefixo for recebido em ambas as famílias de endereços, o cálculo do melhor caminho escolherá um como o melhor caminho, já que todos os atributos são iguais. Se todos os atributos BGP forem os mesmos entre o caminho U e LU, o caminho recebido por último se tornará o melhor caminho.

Se os caminhos SAFI 1 e SAFI 4 forem recebidos de diferentes peers BGP, há sempre uma diferença nos caminhos que levam ao BGP sempre escolhendo o mesmo melhor caminho dos dois caminhos. Mesmo que nesse caso todos os atributos sejam iguais, o endereço vizinho é diferente. Olhando para o algoritmo de seleção de caminho do melhor BGP, o caminho do vizinho com o endereço do vizinho mais baixo (etapa final 13) é escolhido como o melhor caminho.

Use o comando "show bgp <AFI> <SAFI> <prefix> bestpath-compare" para verificar o motivo pelo qual o melhor caminho é melhor.

Essa preferência pode ser feita pelo usuário, usando RPL.

Aqui está um exemplo desse RPL.

RP/0/0/CPU0:R7#show bgp ipv4 un 10.100.1.1/32 detail
BGP routing table entry for 10.100.1.1/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                682         682
    Flags: 0x00003001+0x00010000;
Last Modified: Aug 28 13:16:26.826 for 00:00:10
Paths: (2 available, best #2)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Flags: 0x4000000000020005, import: 0x20
  Not advertised to any peer
  65001
    10.100.1.4 (metric 2) from 10.100.1.4 (10.100.1.10)
      Origin IGP, metric 0, localpref 100, valid, internal
      Received Path ID 1, Local Path ID 0, version 0
      Originator: 10.100.1.10, Cluster list: 10.100.1.4
  Path #2: Received by speaker 0
  Flags: 0x4080000001060005, import: 0x20
  Not advertised to any peer
  65001
    10.100.1.4 (metric 2) from 10.100.1.4 (10.100.1.10)
      Received Label 24003
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, labeled-unicast
      Received Path ID 1, Local Path ID 0, version 682
      Originator: 10.100.1.10, Cluster list: 10.100.1.4

O caminho da LU é o melhor.

RPL com peso é usado para preferir o caminho U.

route-policy weight
  if destination in (10.100.1.1/32) then
    set weight 60000
  endif
end-policy

router bgp 65003
 address-family ipv4 unicast
  additional-paths receive
  additional-paths send
 !
 neighbor 10.100.1.4
  remote-as 65003
  update-source Loopback0
  address-family ipv4 unicast
   route-policy weight in
  !
  address-family ipv4 labeled-unicast
  !
 !

RP/0/0/CPU0:R7#show bgp ipv4 un 10.100.1.1/32 bestpath-compare
BGP routing table entry for 10.100.1.1/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                726         726
Last Modified: Aug 28 13:39:27.826 for 00:04:54
Paths: (2 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  65001
    10.100.1.4 (metric 2) from 10.100.1.4 (10.100.1.10)
      Origin IGP, metric 0, localpref 100, weight 60000, valid, internal, best, group-best
      Received Path ID 1, Local Path ID 0, version 726
      Originator: 10.100.1.10, Cluster list: 10.100.1.4
      best of AS 65001, Overall best
  Path #2: Received by speaker 0
  Not advertised to any peer
  65001
    10.100.1.4 (metric 2) from 10.100.1.4 (10.100.1.10)
      Received Label 24003
      Origin IGP, metric 0, localpref 100, valid, internal, labeled-unicast
      Received Path ID 1, Local Path ID 0, version 0
      Originator: 10.100.1.10, Cluster list: 10.100.1.4
      Lower weight than best path (path #1)

O caminho da U é agora o melhor.

Não há nenhum comando novo para preferir caminhos rotulados em vez de caminhos não rotulados. Você pode configurar o RPL em address-family unicast ou labeled-unicast sob um vizinho BGP.

Verificação do comportamento no BGP

Para depurar a propagação de atualização do BGP no IOS-XR, você pode ativar o seguinte comando de depuração: debug bgp update <vizinho BGP> in | saída.

Isso mostrará a atualização BGP de entrada ou saída de ou para esse alto-falante BGP. A família de endereços é mostrada como (ip4u) para IPv4 não rotulado (AFI 1/SAFI 1) ou como (ipv4lu) para IPv4 unicast rotulado (AFI 1/SAFI 4). O equivalente ocorre para IPv6.

Há um novo campo "rotulado-unicast" que indica que o caminho é aprendido via SAFI 4.

Exemplo:

RP/0/0/CPU0:R1#show bgp ipv4 unicast 10.100.1.7/32
BGP routing table entry for 10.100.1.7/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                 26          26
Last Modified: Sep  4 10:45:44.551 for 00:29:11
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  Local
    10.100.1.4 (metric 3) from 10.100.1.102 (10.100.1.4)
      Received Label 24000
      Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, labeled-unicast
      Received Path ID 0, Local Path ID 1, version 26
      Originator: 10.100.1.4, Cluster list: 10.100.1.2

Para verificar se o prefixo é anunciado, você pode usar o comando "show bgp ... neighbors" com a palavra-chave "advertised-routes" no final.

Exemplo:

O R4 anuncia 10.100.1.1/32 ao vizinho 10.100.1.7 duas vezes porque o caminho adicional está ativado (os dois caminhos são diferentes).

RP/0/0/CPU0:R4#show bgp ipv4 labeled-unicast neighbors 10.100.1.7 advertised-routes
Network            Next Hop        From            AS Path
10.1.24.0/24       10.100.1.4      Local           ?
10.1.34.0/24       10.100.1.4      Local           ?
10.1.45.0/24       10.100.1.4      Local           ?
10.1.46.0/24       10.100.1.4      Local           ?
10.1.47.0/24       10.100.1.4      Local           ?
10.1.48.0/24       10.100.1.4      Local           ?
10.1.49.0/24       10.100.1.4      Local           ?
10.1.104.0/24      10.100.1.4      Local           ?
10.1.114.0/24      10.100.1.4      Local           ?
10.100.1.1/32      10.100.1.4      10.100.1.9      65001i
                                   10.100.1.10     65001i
10.100.1.4/32      10.100.1.4      Local           ?

Processed 11 prefixes, 12 paths

iBGP e Next Hop-Self - MPLS unificado

São aplicáveis as regras do quadro 1. Com o Unified MPLS ou o Seamless MPLS, um roteador de borda de área (ABR) atua como refletor de rota, mas também é o próximo salto para as rotas iBGP. Os ABRs estão no caminho de encaminhamento do tráfego rotulado. Os ABRs devem ter a configuração explícita para o Next-Hop-Self.

Soluções

• Se não houver suporte para U e LU em uma sessão BGP, uma solução alternativa é ter duas sessões BGP entre um par de roteadores. Duas interfaces (loopback) devem ser usadas em cada roteador.

Exemplo de configuração para IOS-XR.

interface Loopback0
 ipv4 address 10.100.1.7 255.255.255.255
!
interface Loopback1
 ipv4 address 10.100.1.107 255.255.255.255
!
router bgp 65003
 address-family ipv4 unicast
!
 neighbor 10.100.1.4   -> towards loopback0 on peer
  remote-as 65003
  update-source Loopback0
  address-family ipv4 unicast
  !
 !
 neighbor 10.100.1.104  -> towards loopback1 on peer
  remote-as 65003
  update-source Loopback1
  address-family ipv4 labeled-unicast
  !

Os caminhos U e LU são enviados/recebidos por duas sessões BGP diferentes.

RP/0/0/CPU0:R7#show bgp ipv4 unicast 10.100.1.1/32 detail
BGP routing table entry for 10.100.1.1/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                753         753
    Flags: 0x00001001+0x00010000;
Last Modified: Aug 28 14:06:40.826 for 00:22:10
Paths: (2 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Flags: 0x4000000001060005, import: 0x20
  Not advertised to any peer
  65001
    10.100.1.4 (metric 2) from 10.100.1.4 (10.100.1.10)
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
      Received Path ID 1, Local Path ID 0, version 753
      Originator: 10.100.1.10, Cluster list: 10.100.1.4
  Path #2: Received by speaker 0
  Flags: 0x4080000000020005, import: 0x20
  Not advertised to any peer
  65001
    10.100.1.104 (metric 2) from 10.100.1.104 (10.100.1.10)
      Received Label 24003
      Origin IGP, metric 0, localpref 100, valid, internal, labeled-unicast
      Received Path ID 1, Local Path ID 0, version 0
      Originator: 10.100.1.10, Cluster list: 10.100.1.4