Comware – BGP Community

O atributo do BGP community é utilizado como para marcação para um determinado grupo de rotas. Provedores de Serviço utilizam essas marcações para aplicar políticas de roteamento específicas em suas redes, como por exemplo, alterando o Local Preference, MED, etc. O atributo simplifica a configuração das políticas de roteamento, gerenciamento e manutenção.

Os ISP’s podem também estabelecem um mapeamento de community com o cliente ou com outro provedor para que sejam aplicadas regras de roteamento.

O recebimento e envio de communities BGP em Roteadores HP necessitam da configuração explicita do comando advertise-community. No exemplo abaixo, segue a configuração de um peer BGP em um roteador com o Comware 7:

bgp 65500
 group AS65500 internal
 peer AS65500 connect-interface LoopBack1
 peer 192.168.2.2 group AS65500
 #
 address-family ipv4 unicast
  peer AS65500 enable
  peer AS65500 advertise-community
#

O atributo community é opcional e transitivo (optional transitive) de tamanho variável. O atributo consiste em um conjunto de 4 octetos ou um número de 32 bits que específica uma community. A representação de uma community BGP é geralmente feita no formato AA:NN onde o AA é o Autonomous System (AS) e o NN é o número da community.

Algumas communities tem significados pré-definidos como:

  • NO_EXPORT (0xFFFFFF01)
  • NO_ADVERTISE (0xFFFFFF02)
  • NO_EXPORT_SUBCONFED (0xFFFFFF03)

-A community  NO_EXPORT  diz ao roteador que ele deve  propagar os prefixos somente dentro de peers iBGP e que não deve propagar esses prefixos para roteadores pares eBGP.

-A community NO_EXPORT_SUBCONFED possui as mesmas funcionalidades do NO_EXPORT dentro de cenários com confederation.

-A community NO_ADVERTISE  diz ao roteador que ele não deve anunciar o prefixo para nenhum peer BGP.

Abaixo, deixamos um exemplo de configuração utilizando a community NO_EXPORT e o output:

Comware - BGP Community

R1	
#
 ip prefix-list COMM_iBGP index 10 permit 192.168.11.0 24
#
route-policy SET_COMM permit node 5
 if-match ip address prefix-list COMM_iBGP
 apply community no-export
#
route-policy SET_COMM permit node 65535
#
#
bgp 65500
 group AS65500 internal
 peer AS65500 connect-interface LoopBack1
 peer 192.168.2.2 group AS65500
 #
 address-family ipv4 unicast
  network 192.168.11.0 255.255.255.0
  network 192.168.111.0 255.255.255.0
  peer AS65500 enable
  peer AS65500 route-policy SET_COMM export
  peer AS65500 advertise-community
#

Verificando no Roteador R2 a marcação enviada por R1 para o prefixo 192.168.11.0/24 :

[R2]display bgp routing-table ipv4 192.168.11.0
 BGP local router ID: 192.168.22.2
 Local AS number: 65500
 Paths:   1 available, 1 best
 BGP routing table information of 192.168.11.0/24:
 From            : 192.168.1.1 (192.168.11.1)
 Rely nexthop    : 192.168.12.1
 Original nexthop: 192.168.1.1
 OutLabel        : NULL
 Community       : No-Export
 AS-path         : (null)
 Origin          : igp
 Attribute value : MED 0, localpref 100, pref-val 0
 State           : valid, internal, best
 IP precedence   : N/A
 QoS local ID    : N/A
 Traffic index   : N/A

Configurando os valores manualmente…

Um prefixo pode também participar de mais de uma community e com isso um roteador pode tomar uma ação em relação ao prefixo baseado em uma (algumas) ou todas as communities associadas ao prefixo. O roteador tem a opção de manter, adicionar ou modificar o atributo antes de passar para os outros roteadores.

#
 ip prefix-list COMM_eBGP index 10 permit 192.168.111.0 24
 ip prefix-list COMM_iBGP index 10 permit 192.168.11.0 24
#
route-policy SET_COMM permit node 5
 if-match ip address prefix-list COMM_iBGP
 apply community no-export
#
route-policy SET_COMM permit node 10
 if-match ip address prefix-list COMM_eBGP
 apply community 65500:90
#
route-policy SET_COMM permit node 65535
#
bgp 65500
 group AS65500 internal
 peer AS65500 connect-interface LoopBack1
 peer 192.168.2.2 group AS65500
 #
 address-family ipv4 unicast
  network 192.168.11.0 255.255.255.0
  network 192.168.111.0 255.255.255.0
  peer AS65500 enable
  peer AS65500 route-policy SET_COMM export
  peer AS65500 advertise-community
#

Verificando a marcação enviada por R1 do prefixo 192.168.111.0/24:

[R4] display bgp routing-table ipv4 192.168.111.0
 BGP local router ID: 192.168.44.4
 Local AS number: 65507
 Paths:   1 available, 1 best
 BGP routing table information of 192.168.111.0/24:
 From            : 192.168.24.2 (192.168.22.2)
 Rely nexthop    : 192.168.24.2
 Original nexthop: 192.168.24.2
 OutLabel        : NULL
 Community       : <65500:90>
 AS-path         : 65500
 Origin          : igp
 Attribute value : pref-val 0
 State           : valid, external, best
 IP precedence   : N/A
 QoS local ID    : N/A
 Traffic index   : N/A

Em resumo, as operadoras utilizam communities BGP para manipulação de grande quantidade de prefixos para fins de políticas de roteamento, blackhole, etc. Grandes corporações também as utilizam para identificação de rotas de empresas filiais, rotas aprendidas em fusões com outras empresas,  políticas de roteamento, redes de serviço e mais.

Referências

http://babarata.blogspot.com.br/2010/05/bgp-atributo-community.html

http://www.noction.com/blog/understanding_bgp_communities

Comware: Configurando o atributo Preferred_value (weight) em anúncios de prefixos BGP via route-policy

O atributo BGP Preferred_value permite ao roteador examinar internamente as atualizações BGP decidir a rota preferêncial.

O atributo não é encaminhado nas mensagens BGP e possui apenas função local em um roteador. Para aqueles que estão acostumados a configuração do protocolo BGP em roteadores Cisco com IOS, a funcionalidade é idêntica a configuração BGP weight, que é proprietária.

O Preferred_value é eficiente quando há a necessidade de manipular um destino na saída de um AS, em meio múltiplas rotas.

Vence a rota com maior valor do Preferred_value e é possível configurar valores entre 0 e 65535.

Por padrão os prefixos aprendidos via eBGP possuem o valor como 0 e o Preferred_Value é o parâmetro preferencial para escolha da melhor rota.

Seleção de rotas BGP

Segue abaixo a lista com a ordem para escolha da melhor rota na tabela BGP:

    1. Seleciona a rota com maior preferred_value (similar ao weight da Cisco).
    2. Seleciona a rota com maior Local_Pref.
    3. Seleciona a rota originada pelo roteador local.
    4. Seleciona a rota com menor AS-Path.
    5. ….

Exemplo de Configuração

No exemplo abaixo iremos manipular o roteamento do AS 64507 para o prefixo 2001:db8:3::/64 anunciado pelo AS 64500, para o roteador RA escolher o caminho via RC (next-hop 2001:db8:13::3). O exemplo de configuração é o mesmo para os prefixos IPv4.

Comware BGP Preferred_value
Script de configuração de um roteador MSR com o Comware 7

ipv6 prefix-list abc index 10 permit 2001:DB8:3:: 64
! Configurando a prefix-list da rede 2001:db8::3/64
#
route-policy SET_PV permit node 10
 if-match ipv6 address prefix-list abc
 apply preferred-value 200
! Criando a route-map para aplicar o Preferred_value 200 a prefix-list abc
#
bgp 64507
 peer 2001:DB8:12::2 as-number 64500
 peer 2001:DB8:13::3 as-number 64500
 #
 address-family ipv6 unicast
  network 2001:DB8:1:: 64
  peer 2001:DB8:12::2 enable
  peer 2001:DB8:13::3 enable
  peer 2001:DB8:13::3 route-policy SET_PV import
! Aplicando a route-policy SET_PV para os prefixos aprendidos pelo peer
#

Verificando a tabela de roteamento

[RA]display bgp routing-table ipv6
 Total number of routes: 3

 BGP local router ID is 192.168.11.1
 Status codes: * - valid, > - best, d - dampened, h - history,
               s - suppressed, S - stale, i - internal, e – external
               Origin: i - IGP, e - EGP, ? - incomplete
* >e Network : 2001:DB8:2::                            PrefixLen : 64
     NextHop : 2001:DB8:12::2                          LocPrf    :
     PrefVal : 0                                       OutLabel  : NULL
     MED     : 0
     Path/Ogn: 64500i
* >e Network : 2001:DB8:3::                             PrefixLen : 64
     NextHop : 2001:DB8:13::3                           LocPrf    :
     PrefVal : 200                                      OutLabel  : NULL
     MED     : 0                                     
     Path/Ogn: 64500i
*  e Network : 2001:DB8:3::                             PrefixLen : 64
     NextHop : 2001:DB8:12::2                           LocPrf    :
     PrefVal : 0                                        OutLabel  : NULL
     MED     :
     Path/Ogn: 64500i

Veja que a rota “best” para o prefixo 2001:db8:3::/64 está com o Preferred_value como 200.

Até logo

Comware: Configurando o atributo MED em anúncios de prefixos BGP via route-policy

O propósito do atributo MED (ou MULTI_EXIT_DISC) é permitir que rotadores em um determinado AS digam a roteadores em outro AS a preferência de caminho para determinado prefixo. Apesar de conseguir manipular o “custo” de decisão do melhor caminho em outro AS, o MED não está no topo das escolhas de prioridades do protocolo, mas em diversos casos é muito eficiente.

Apesar de eu já ter utilizado o parâmetro algumas vezes, sempre me esqueço do comando correto e não consigo encontrar nos “Configure Guide” da vida em cenários com a aplicação do MED dentro de uma route policy. Uma das coisas mais legais de ter um blog é poder salvar assuntos que no futuro também facilitarão minha vida. 🙂

Voltando ao assunto… há a possibilidade de configurar o atributo MED direto no processo BGP (já para a versão7 do Comware a configuração deverá ser feita dentro do address-family).

Entretando, para configurar o MED dentro de uma route-policy o comando correto para atribuir um valor para o BGP Multi-Exit Discriminator é apply cost [valor MED].

route-policy SET_MED permit node 10
 if-match ip address prefix-list abc
 apply cost 1000

Seleção de rotas BGP antes do atributo MED

Segue abaixo a lista com a ordem para escolha da melhor rota na tabela BGP antes do atributo MED:

    1. Seleciona a rota com maior preferred_value (similar ao weight da Cisco).
    2. Seleciona a rota com maior Local_Pref.
    3. Seleciona a rota originada pelo roteador local.
    4. Seleciona a rota com menor AS-Path.
    5. Seleciona a rota baseado na prioridade de origem.
    6. Seleciona a rota com o menor MED.

Obs: Caso as opções de melhor preferência estejam com os mesmos atributos, o MED será a sexta opção para desempate.

Exemplo de Configuração

Comware BGP MED

No cenário acima o roteador RB anuncia o prefixo 192.168.11.0/24 com o atributo MED com valor 10 e o roteador RC também anuncia o prefixo 192.168.11.0/24 mas com o atributo MED como 20.

Os Roteadores do AS 64500 comparam o menor MED e caso não exista melhor parâmetro para seleção, o atributo MED será escolhido para encaminhar o tráfego ao roteador (vence o menor valor MED).

Configuração do Roteador RB (com o Comware7)

#
ip prefix-list rede_192 index 5 permit 192.168.11.0 24
#
route-policy SET_MED_10 permit node 10
 if-match ip address prefix-list rede_192
 apply cost 10
#
bgp 64507
 peer 192.168.12.2 as-number 64500
#
 address-family ipv4 unicast
     peer 192.168.12.2 enable
     peer 192.168.12.2 route-policy SET_MED_10 export
#

Os roteadores do ASN 64500 terão em sua tabela BGP o seguinte cenário:

[RE]display bgp routing-table ipv4
 Total number of routes: 5
 BGP local router ID is 192.168.3.3
 Status codes: * - valid, > - best, d - dampened, h - history,
               s - suppressed, S - stale, i - internal, e – external
               Origin: i - IGP, e - EGP, ? - incomplete
     Network            NextHop         MED        LocPrf     PrefVal Path/Ogn
* >i 192.168.1.0        192.168.12.1    0          100        0       64507i
*  e                    192.168.13.1    0                     0       64507
  >i 192.168.2.0        192.168.2.2     0          100        0       i
* >i 192.168.11.0       192.168.12.1    10         100        0       64507i
*  e                    192.168.34.1    20                    0       64507i

Veja que a rota “best” em nosso cenário é o prefixo com menor valor do atributo MED.

Até logo!

Referências

CCIE Routing and Switching Certification Guide, 4th Edition, Cisco Press, Wendell Odom, Rus Healy, Denise Donohue

Comware7: Configuração básica para BGP

As configurações do BGP via CLI para os equipamentos baseados no Comware 7 diferem um pouco em relação aos Switches e Roteadores baseados no Comware 5.

Se você quiser saber um pouco mais sobre como funciona  o BGP, temos alguns artigos no blog. Os principais são:
http://www.comutadores.com.br/switches-3com-4800g-configuracao-basica-do-bgp/
http://www.comutadores.com.br/resumo-sobre-border-gateway-protocol-bgp-mase-parte1/

Basicamente para o Comware 7, uma vez dentro do processo BGP, basta habilitar o ‘peering’ com o roteador vizinho normalmente, mas a grande diferença está no anuncio de prefixos, pois uma vez que você necessite anunciar prefixos IPv4 ou IPv6, será necessário entrar no address-family, ativar o peering e aplicar o comando network, import (redistribute) etc.

Para ficar mais fácil, veja o exemplo abaixo o peering eBGP entre o Roteador R1 (AS 100) e R4 (AS 400):

BGP Comware 7

<R1> display current-configuration configuration bgp
bgp 100
peer 10.0.0.2 as-number 400
#
 address-family ipv4 unicast
    network 192.168.1.0 255.255.255.0
    peer 10.0.0.2 enable 
   
<R4> display current-configuration configuration bgp
bgp 400
peer 10.0.0.1 as-number 100
#
 address-family ipv4 unicast
  network 192.168.2.0 255.255.255.0
  peer 10.0.0.1 enable  

O ponto mais importante dessa configuração é definir o IPv4 unicast address family e ativar o peer. Perceba que as redes deverão ser anunciadas dentro do address family correto.
Para validar o peering:

<R1>display bgp peer ipv4 unicast
BGP local router ID: 192.168.1.1
Local AS number: 100
Total number of peers: 1 Peers in established state: 1
* - Dynamically created peer
Peer     AS   MsgRcvd MsgSent OutQ PrefRcv Up/Down State
10.0.0.2 400   125     118     0    2       01:47:39 Established

IPv6
O mesmo vale se o peering e/ou prefixos for para endereços IPV6

<R4>display current-configuration configuration bgp
#
bgp 400
 peer 2001:DB8:14::1 as-number 100
 #
  address-family ipv6 unicast
   network 2001:DB8:4:: 64
   network 2001:DB8:44:: 64
   peer 2001:DB8:14::1 enable

Para validar o peering BGP com endereço IPv6:

 <R4>display bgp peer ipv6 unicast
 BGP local router ID: 192.168.44.4
 Local AS number: 400
 Total number of peers: 1          Peers in established state: 1
  * - Dynamically created peer
Peer             AS  MsgRcvd  MsgSent OutQ PrefRcv Up/Down  State

2001:DB8:14::1   100 60       60      0     2 00:47:40 Established

Para validar a tabela BGP basta preencher conforme o output abaixo: IPv4, IPv6, vpnv4, vpnv6, etc..

<R4>display bgp routing-table ?
  dampened   Display dampened BGP routes
  flap-info  Display BGP route flap information
  ipv4       Specify the IPv4 address Family
  ipv6       Specify the IPv6 address Family
  vpnv4      Specify the VPNv4 address family
  vpnv6      Specify the VPNv6 address family

Até logo.

Sumarização manual com BGP aggregate

Para o anuncio de redes no processo BGP, utilizamos o comando “network” ou a redistribuição de rotas com o comando “import“.

Há também a possibilidade de manualmente sumarizarmos as redes no anuncio de prefixos para os roteadores vizinhos.  O comando BGP aggregate permite a sumarização manual (diferente do comando auto-summary), baseando-se em qualquer prefixo da tabela BGP.

No exemplo abaixo os ASN 11 e 12 anunciam cada um 2 prefixos /24 para o ASN 22.

BGP Aggregation

Sem a sumarização de rotas a tabela BGP estaria da seguinte forma para o Roteador do ASN 33:

 

[RoteadorASN33]display bgp routing-table ipv4
 Total number of routes: 4

 BGP local router ID is 192.168.23.3
 Status codes: * - valid, > - best, d - dampened, h - history,
               s - suppressed, S - stale, i - internal, e – external
               Origin: i - IGP, e - EGP, ? - incomplete
     Network            NextHop         MED        LocPrf     PrefVal Path/Ogn
* >e 192.168.0.0        192.168.23.2                          0       22 11i
* >e 192.168.1.0        192.168.23.2                          0       22 11i
* >e 192.168.2.0        192.168.23.2                          0       22 12i
* >e 192.168.3.0        192.168.23.2                          0       22 12i

Criando as rotas agregadas

O comando aggregate irá criar as rotas sumarizadas manualmente, iniciando o valor do AS path, simplesmente criando um novo anuncio de prefixos sumarizados sem omitir o anuncio das rotas mais especificas.

No exemplo abaixo, sumarizamos os prefixos do ASN 11 em apenas um prefixo /23:

! Configuração BGP do Roteador do ASN 22 com Comware 7

bgp 22
 peer 192.168.23.3 as-number 33
 peer 192.168.112.1 as-number 11
 peer 192.168.212.1 as-number 12
 #
 address-family ipv4 unicast
  aggregate 192.168.0.0 255.255.254.0
  peer 192.168.23.3 enable
  peer 192.168.112.1 enable
  peer 192.168.212.1 enable
#

Analisando a tabela BGP do Roteador do ASN 33 temos o seguinte output:

! tabela BGP do Roteador do ASN 33 com Comware 7
[RoteadorASN33]display bgp  routing-table ipv4
 Total number of routes: 5
 BGP local router ID is 192.168.23.3
 Status codes: * - valid, > - best, d - dampened, h - history,
               s - suppressed, S - stale, i - internal, e - external
               Origin: i - IGP, e - EGP, ? – incomplete

     Network            NextHop         MED        LocPrf     PrefVal Path/Ogn

* >e 192.168.0.0/23     192.168.23.2                          0       22i
* >e 192.168.0.0        192.168.23.2                          0       22 11i
* >e 192.168.1.0        192.168.23.2                          0       22 11i
* >e 192.168.2.0        192.168.23.2                          0       22 12i
* >e 192.168.3.0        192.168.23.2                          0       22 12i

Se quisessemos omitir o anuncio dos prefixos mais especificos para os roteadores do ASN 33 acrescentariamos o comando detail-suppressed

  aggregate 192.168.0.0 255.255.254.0 detail-suppressed

Analisando novamente a tabela BGP do Roteador do ASN 33 temos o seguinte output (sem as rotas mais especificas do /23):

[RoteadorASN33]display bgp  routing-table ipv4
 Total number of routes: 3
 BGP local router ID is 192.168.23.3
 Status codes: * - valid, > - best, d - dampened, h - history,
               s - suppressed, S - stale, i - internal, e - external
               Origin: i - IGP, e - EGP, ? - incomplete
     Network            NextHop         MED        LocPrf     PrefVal Path/Ogn

* >e 192.168.0.0/23     192.168.23.2                          0       22i
* >e 192.168.2.0        192.168.23.2                          0       22 12i
* >e 192.168.3.0        192.168.23.2                          0       22 12i

Mantendo os ASN

Observem que a rota sumarizada pelo ASN 22, inclui apenas o seu próprio ASN no AS_PATH. Os ASN 11 e 12 também receberão a rota sumarizada pelo simples fato de seus ASes serem omitidas na sumarização. Esta ação introduz a possibilidade da criação de loop de roteamento em determinados cenários.

O parametro AS_PATH AS_SET resolve essa questão adicionando os ASes de origem. No exemplo abaixo estamos sumarizando também com um /22 para exemplificar a diferença do comando com as-set:

  aggregate 192.168.0.0 255.255.252.0 detail-suppressed as-set
  aggregate 192.168.0.0 255.255.254.0 detail-suppressed as-set

Essa configuração gera uma rota sumarizada contendo o conjunto de ASes, de 11 e 12 para a rede /22, e AS 11 para o /23, uma vez que o agregado contém rotas provenientes desses sistemas autônomos. No roteador do AS 33, podemos ver o caminho dos Ases na tabela BGP:

[RoteadorASN33]display bgp routing-table ipv4
 Total number of routes: 2
 BGP local router ID is 192.168.23.3
 Status codes: * - valid, > - best, d - dampened, h - history,
               s - suppressed, S - stale, i - internal, e - external
               Origin: i - IGP, e - EGP, ? - incomplete
     Network            NextHop         MED        LocPrf     PrefVal Path/Ogn
* >e 192.168.0.0/22     192.168.23.2                          0       22 {11 12}i
* >e 192.168.0.0/23     192.168.23.2                          0       22 11i

A seguinte lista resume as ações do comando aggregate para o anuncio de rotas sumarizadas:

  • as-set: Cria um sumario com os ASes.
  • attribute-policy route-policy-name: Permite aplicar atributos BGP na sumarização (exceto AS_PATH)
  • detail-suppressed: Somente anuncia a rota sumarizada
  • suppress-policy route-policy-name: Omite rotas especificas definidas na route-map. Permitindo que você deixe o anuncio apenas de algumas rotas mais especificas.
  • origin-policy route-policy-name: Seleciona apenas as rotas que satisfaçam a política de roteamento para sumarização.

 

Até logo

Referências

http://packetlife.net/blog/2008/sep/19/bgp-route-aggregation-part-1/

HP A8800 Configuration Guide – IP Routing

CCIE Routing and Switching CERTIFICATION Guide, 4th Edition, Cisco Press, Wendell Odom, Rus Healy, Denise Donohue

 

Resumo: BGP – Router Reflector em Roteadores HP

O algoritmo do BGP não permite que rotas aprendidas via iBGP sejam anunciadas para roteadores vizinhos. Lembrando que uma rota aprendida via eBGP deve ser ensinada para um vizinho iBGP, mas uma rota aprendida via iBGP não deve ser anunciada para roteadores vizinhos.

Quando BGP foi projetado originalmente, não havia nenhuma provisão para a prevenção de loop dentro de um Sistema Autônomo (AS ou ASN). Em vez disso, a regra de prefixos iBGP proíbe o anuncio de rotas aprendidas via iBGP para outro peer BGP interno.

Esta é a razão principal pela qual a inteligência do  BGP necessita de conexões full mesh entre roteadores iBGP, isto é, todos roteadores devem estar conectados entre si. Mas a topologia iBGP com  full mesh, traz  problemas de escalabilidade na configuração, uma vez que o número de sessões para troca de tráfego irá ser N (N-1) / 2, onde N é o número de roteadores internos BGP

Perceba no diagrama abaixo que o prefixo aprendido por R3 via iBGP não é encaminhado para o roteador R4 devido a regra de prefixos aprendidos via iBGP citado acima.

iBGP rule HP

Utilizando Roteadores Refletores (Router Reflectors ou RRs) em uma topologia iBGP, permitirá ao protocolo BGP quebrar a regra de proibição ao ensinar rotas aprendidas via iBGP para vizinhos internos.

Os roteadores configurados como Router Reflector dividem os seus vizinhos iBGP em duas classes: clientes e não-clientes.

As rotas aprendidas por roteadores iBGP clientes serão anunciadas para roteadores clientes e não-clientes. No, entanto as rotas aprendidas a partir de não-clientes serão anunciadas apenas para clientes.

Perceba no diagrama abaixo o prefixo anunciado para o Roteador R4 pelo Roteador R3 configurado como RR.

iBGP rule and RR HP

A configuração do Router Reflector só é necessária no roteador RR “servidor”, nenhuma configuração é necessária nos equipamentos clientes. Segue abaixo a configuração de R3.

! Configuração R3
!
bgp 234
 peer 2.2.2.2 as-number 234
 peer 2.2.2.2 description R2
 peer 2.2.2.2 reflect-client
 peer 2.2.2.2 connect-interface LoopBack1
!

Cluster_List e Originator_ID

A configuração de Route Reflector é geralmente a atribuída a ambientes bem complexos. O BGP utiliza-se de alguns mecanismos para prevenção de loops como Cluster List e Originator ID:

– Cluster ID: O RR adiciona seu cluster ID ao encaminhar o update. Quando recebe um update BGP que contem o seu próprio Cluster ID os prefixos recebidos são descartados, evitando assim o gerar loop  de roteamento pelos anuncios entre clusters.

– Originator ID: Uma lista de clusters (cluster-list) é uma seqüência de cluster-IDs que a rota atravessou. Quando um RR reflete uma rota de seus clientes para non-clients fora do cluster, ele adiciona o cluster-id local no final da cluster-list. Usando este atributo, um RR pode identificar se uma informação de roteamento fez um loop e voltou ao mesmo cluster que a originou (por alguma falha de configuração). Se o cluster-id local é encontrado na cluster-list, o anúncio da rota será descartado.

Conforme diagrama abaixo, segue um exemplo do output com a lista do Cluster list:

Router Reflector cluster id HP

[R1]display bgp routing-table 55.55.55.0
 BGP local router ID : 1.1.1.1
 Local AS number : 234
 Paths:   1 available, 1 best
BGP routing table entry information of 55.55.55.0/24:
 RR-client route.
 From            : 4.4.4.4 (4.4.4.4)
 Relay Nexthop   : 192.168.45.5
 Original nexthop: 2.2.2.2
 AS-path          : 5
 Origin          : igp
 Attribute value : MED 0, localpref 100, pref-val 0, pre 255
 State           : valid, internal,
 Originator      : 2.2.2.2
 Cluster list    : 0.0.0.2, 0.0.0.1

Segue abaixo a configuração de R3 e R4 (lembrando que nenhuma configuração BGP adicional é necessária para o Roteador cliente Router Reflector

#
! Configuração R3
router bgp 234
 bgp cluster-id 1
 neighbor 2.2.2.2 remote-as 234
 neighbor 2.2.2.2 description R2
 neighbor 2.2.2.2 update-source Loopback1
 neighbor 2.2.2.2 route-reflector-client
!
 neighbor 4.4.4.4 remote-as 234
 neighbor 4.4.4.4 description R4
 neighbor 4.4.4.4 update-source Loopback1
!

#
! Configuração R4
router bgp 234
 bgp cluster-id 2
 neighbor 1.1.1.1 remote-as 234
 neighbor 1.1.1.1 description R1
 neighbor 1.1.1.1 update-source Loopback1
 neighbor 1.1.1.1 route-reflector-client
!
 neighbor 3.3.3.3 remote-as 234
 neighbor 3.3.3.3 description R3
 neighbor 3.3.3.3 update-source Loopback1
!

Até logo

Referências

http://blog.ipexpert.com/2012/02/20/understanding-bgp-originator-id-and-cluster-id/#top

http://www.rnp.br/newsgen/0109/bgp4_dicas2.html#ng-6

http://www.rotadefault.com.br/teste-mesa-para-router-reflectors/

http://www.rotadefault.com.br/resumo-bgp-router-reflectors/

CCIE Routing and Switching Certification Guide, 4th Edition, Cisco Press, Wendell Odom, Rus Healy, Denise Donohue

Roteamento entre VRFs com MP-BGP em Roteadores HP / H3C

A utilização de VRFs (Virtual Routing and Forwarding) em Roteadores permite a criação de tabelas de roteamentos virtuais que trabalham de forma independente da tabela de roteamento “normal”, protegendo os processos de roteamento de cada cliente de forma individual.

VRFs Comware

Empresas que prestam serviços de gerenciamento de rede ou monitoração, empresas que vendem serviços em Data Center e provedores de serviço utilizam largamente VRFs, otimizando assim a administração e o retorno financeiro no total do custo de um projeto.

A configuração de VRFs é bem simples e há um artigo aqui do blog que pode ser consultado no link [http://www.comutadores.com.br/vrf-em-switches-e-roteadores-hpn-vpn-instance/].

Já o Roteamento entre VRFs ocorre quando há a necessidade de comunicarmos diferentes tabelas de roteamento que estão segregadas por VRF, para compartilharem alguns ou todos os prefixos. Há diversas formas de configurarmos o roteamento entre VRFs, como por exemplo com a utilização de um cabo virado para o próprio roteador com as portas em diferente VRFs [apontando assim uma rota para  nexthop da proxima VRF; ou com algum IGP] e também com a utilização de um outro roteador, etc; nesse post explicaremos o roteamento interVRF com o processo MPBGP que é a maneira mais escalável… preparados? Então vamos lá… 😉

Habilitando o import e export das VRFs

Ao configurarmos o processo de roteamento entre VRFs em um mesmo roteador , dois valores de extrema importancia devem ser configurados na VRF: o RD (route distinguisher) e o RT (route target)

RD – Route Distinguisher

Como explicado anteriormente,  as VRFs permitem a reutilização de endereços IP em diferentes tabelas de roteamento. Por exemplo, suponha que você tenha que conectar a três diferentes clientes , os quais estão usando 192.168.1.0/24 em sua rede local. Podemos designar a cada cliente a sua própria VRF de modo que as redes sobrepostas são mantidas isoladas em suas VRFs .

O RD funciona mantendo o controle de quais rotas 192.168.1.0/24 pertencem a cada cliente  como um diferenciador de rota (RD) para cada VRF. O route distinguisher é um número único adiciondo para cada rota dentro de uma VRF para identificá-lo como pertencente a essa VRF ou cliente particular. O valor do RD é carregado juntamente com uma rota através do processo MP- BGP quando o roteador troca rotas VPN com outros Roteadores PE.

O valor RD é de 64 bits e é sugerido a configuração do valor do RD como ASN::nn ou endereçoIP:nn. Mas apesar das sugestões, o valor é apenas representativo.

 

[R1-vpn-instance-Cliente_A]route-distinguisher ?
  STRING  ASN:nn or IP_address:nn  VPN Route Distinguisher
!
! Configurando a VRF para os clientes A B e C 
ip vpn-instance Cliente_A
 route-distinguisher 65000:1
!
ip vpn-instance Cliente_B
 route-distinguisher 65000:2
!
ip vpn-instance Cliente_C
route-distinguisher 65000:3

Quando rotas VPN são anunciados entre os roteadores PE via MP-BGP, o RD é incluído como parte da rota, juntamente com o prefixo IP. Por exemplo, uma via para 192.0.2.0/24 na VRF Cliente_B é anunciado como 65000:2:192.0.1.0 / 24.

RT – Route-Target ou VPN-target

Considerando que o valor do RD é utilizado para manter a exclusividade entre rotas idênticas em diferentes VRFs, o RT (route target)é utilizado para compartilhar rotas entre eles. Podemos aplicar o RT para uma VRF com o objetivo de controlar a importação e exportação de rotas entre ela e outras VRFs.

O route target assume a forma de uma comunidade BGP estendida com uma estrutura semelhante à de um RD (que é, provavelmente, porque os dois são tão facilmente confundidos).

Segue abaixo um exemplo de configuração, onde o Cliente_A fará o roteamento entre VRFs com o Cliente_B, já o Cliente_C continuará com a sua VRF isolada dos outros clientes.

 

!
!
ip vpn-instance Cliente_A
 route-distinguisher 65000:1
 vpn-target 65000:1 export-extcommunity
 vpn-target 65000:1 import-extcommunity
 vpn-target 65000:2 import-extcommunity 
!
ip vpn-instance Cliente_B
 route-distinguisher 65000:2
 vpn-target 65000:2 export-extcommunity
 vpn-target 65000:2 import-extcommunity
 vpn-target 65000:1 import-extcommunity  
!
ip vpn-instance Cliente_C
 route-distinguisher 65000:3
 vpn-target 65000:3 export-extcommunity
 vpn-target 65000:3 import-extcommunity
!

Inter VRF Routing

Segue abaixo a configuração das interfaces de cada VRF , e o processo MP-BGP responsável por funcionar o import/export de prefixos das VRFs.

!
!
interface Loopback0
 ip address 192.168.1.1 255.255.255.0
!
interface Loopback1
 ip binding vpn-instance Cliente_A
 ip address 1.1.1.1 255.255.255.0
!
interface Loopback2
 ip binding vpn-instance Cliente_B
 ip address 2.2.2.2 255.255.255.0
!
interface Loopback3
 ip binding vpn-instance Cliente_C
 ip address 3.3.3.3 255.255.255.0
!
#
bgp 6500
 undo synchronization
#
 ipv4-family vpn-instance Cliente_A
  import-route direct
#
 ipv4-family vpn-instance Cliente_B
  import-route direct
#
 ipv4-family vpn-instance Cliente_C
  import-route direct
#
!

Segue abaixo os outputs das rotas aprendidas para o roteamento entre VRFs(vpn-instances) e o teste de ICMP

[R1]display ip routing-table vpn-instance Cliente_A
Routing Tables: Cliente_A
        Destinations : 4        Routes : 4
Destination/Mask    Proto  Pre  Cost         NextHop         Interface
1.1.1.1/32          Direct 0    0            127.0.0.1       InLoop0
2.2.2.2/32          BGP    130  0            127.0.0.1       InLoop0
127.0.0.0/8         Direct 0    0            127.0.0.1       InLoop0
127.0.0.1/32        Direct 0    0            127.0.0.1       InLoop0

[R1]ping -vpn-instance Cliente_A 2.2.2.2
  PING 2.2.2.2: 56  data bytes, press CTRL_C to break
    Reply from 2.2.2.2: bytes=56 Sequence=1 ttl=255 time=4 ms
    Reply from 2.2.2.2: bytes=56 Sequence=2 ttl=255 time=10 ms
    Reply from 2.2.2.2: bytes=56 Sequence=3 ttl=255 time=10 ms
    Reply from 2.2.2.2: bytes=56 Sequence=4 ttl=255 time=5 ms
    Reply from 2.2.2.2: bytes=56 Sequence=5 ttl=255 time=4 ms
 --- 2.2.2.2 ping statistics ---
    5 packet(s) transmitted
    5 packet(s) received
    0.00% packet loss
    round-trip min/avg/max = 4/5/10 ms

Segue abaixo a configuração completa do R1

Para dúvidas em sugestões deixe um comentário. Até logo 😉

Dicionário de Comandos BGP: Comware vs Cisco

Pessoal, segue abaixo a lista de alguns comandos para BGP quando há a necessidade de traduzir de Cisco IOS para HP Comware.

Comware                                                      Cisco IOS
------------                                                 --------------
bgp xxxxx                                                   router bgp xxxxx
router-id x.x.x.x                                           bgp router-id x.x.x.x 
preference 200 200 200 (valor recomendado, não é default)   distance 20 200 200 (default)
undo synchronization                                        no synchronization (not default)
v5: recomendado (não é default)
v7: default
undo summary automatic (default)                            no auto-summary (not default)
log-peer-change                                             bgp log-neighbor-changes
graceful-restart                                            bgp graceful-restart
bgp graceful-restart restart-time 120 (default)             bgp graceful-restart stalepath-time 360 (default)
balance n (default=1)                                       maximum-path (dependente do contexto, default=1)
v5: global BGP config
v7: in ipv4 address family
maximum-path n (n=numero de rotas paralelas)                 maximum-path ibgp m 
ebgp-interface-sensitive (default)                           bgp fast-external-fallover (default)
network x.x.x.x y.y.y.y                                      network x.x.x.x mask y.y.y.y
aggregate x.x.x.x y.y.y.y                                    aggregate-addresss x.x.x.x y.y.y.y
aggregate x.x.x.x y.y.y.y detail-suppressed                  aggregate-addresss x.x.x.x y.y.y.y summary-only
import-route static [route-policy name]                      redistribute static [route-map name]
import-route direct [route-policy name]                      redistribute connected [route-map name]
import-route ospf process_id [route-policy name]             redistribute ospf process_id [route-map name]
default-information originate                                 
reflector cluster-id x.x.x.x                                 bgp cluster-id x.x.x.x
dampening                                                    bgp dampening
peer x.x.x.x as-number AS-number                             neighbor x.x.x.x remote-as AS-number
peer x.x.x.x description blabla                              neighbor x.x.x.x description blabla
peer x.x.x.x connect-interface LoopBack0                     neighbor x.x.x.x update-source Loopback0
peer x.x.x.x next-hop-local                                  neighbor x.x.x.x next-hop-self
peer x.x.x.x advertise-community                             neighbor x.x.x.x send-community
peer x.x.x.x password simple|cipher string                   neighbor x.x.x.x password 7 string
(default)                                                    neighbor x.x.x.x version 4 (no negotiation)
peer x.x.x.x ebgp-max-hop                                    neighbor x.x.x.x ebgp-multihop hop_count
peer x.x.x.x preferred-value default_prefval                 neighbor x.x.x.x weight default_weight
peer x.x.x.x default-route-advertise route-policy name       neighbor x.x.x.x default-originate route-map name
peer x.x.x.x timer keepalive keepalive hold holdtime         neighbor x.x.x.x timers keepalive holdtime minholdtime
peer x.x.x.x route-policy name import | export               neighbor x.x.x.x route-map name in | out
peer x.x.x.x public-as-only                                  neighbor x.x.x.x remove-private-as
peer x.x.x.x fake-as AS-number                               neighbor x.x.x.x local-as no-prepend AS-number replace-as
peer x.x.x.x substitute-as                                  
peer x.x.x.x allow-as-loop AS_occurances                     neighbor x.x.x.x allowas-in AS_occurances  
peer x.x.x.x route-limit prefix_number % reconnect restart_interval 
                                              neighbor x.x.x.x maximum-prefix prefix_number % restart restart_interval
peer x.x.x.x reflect-client                                  neighbor x.x.x.x route-reflector-client
peer x.x.x.x ignore                                          neighbor x.x.x.x shutdown
group group_name internal | external                         neighbor group_name peer-group
peer x.x.x.x group group_name                                neighbor x.x.x.x peer-group group_name

compare-different-as-med                                     bgp always-compare-med
bestroute compare-med                                        bgp deterministic-med
bestroute as-path-neglect                                    bgp bestpath as-path ignore

undo default ipv4-unicast                                    no bgp default ipv4-unicast
(Default)                                                    bgp suppress-inactive
peer x.x.x.x capability-advertise orf ip-prefix both         neighbor x.x.x.x capability orf prefix-list both
peer x.x.x.x capability-advertise route-refresh (default)    neighbor x.x.x.x soft-reconfiguration inbound
peer x.x.x.x bfd                                             neighbor x.x.x.x fall-over bfd
peer x.x.x.x route-update-interval timer                     neighbor x.x.x.x advertisement-interval seconds
(iBGP default=5s, eBGP default=30s)                          iBGP default=0s, eBGP (na VRF) default=0s, eBGP default=0s)
peer x.x.x.x next-hop-local                                  neighbor x.x.x.x next-hop-self
peer x.x.x.x capability-advertise orf ip-prefix both         neighbor x.x.x.x capability orf prefix-list both
Deve ser usado no vpnv4 address-family.                      Deve ser usado no vpnv4 address-family.
peer x.x.x.x advertise-ext-community                         neighbor x.x.x.x send-community extended | both
undo peer x.x.x.x enable                                     no neighbor x.x.x.x activate

Verificando a troca de prefixos												
display bgp routing-table peer x.x.x.x received-routes      show ip bgp neighbors x.x.x.x received-routes
display bgp routing-table peer x.x.x.x advertised-routes    show ip bgp neighbors x.x.x.x advertised-routes

MPBGP
display bgp vpnv4 vpn-instance vpn-instance-name routing-table peer x.x.x.x received-routes
show ip bgp vpnv4 vrf vrf-instance-name neighbors x.x.x.x received-routes
display bgp vpnv4 all routing-table peer x.x.x.x received-routes
v5
show ip bgp vpnv4 all neighbors x.x.x.x received-routes

display bgp vpnv4 vpn-instance vpn-instance-name routing-table peer x.x.x.x advertised-routes
show ip bgp neighbors x.x.x.x advertised-routes
display bgp vpnv4 all routing-table peer x.x.x.x advertised-routes
show ip bgp

Comandos comparativos para Troubleshooting, Reset e Refresh do BGP : Comware v5 x IOS Cisco

Segue uma lista para rápida comparação de comandos para troubleshooting, reset e refresh para o processo BGP comparando os comandos entre equipamentos 3Com,H3C e HP baseados no Comware e Cisco IOS.

Troubleshooting

Comware                                           IOS

display ip routing-table                          show ip route
display ip routing-table x.x.x.x                  show ip route x.x.x.x
display ip routing-table x.x.x.x longer-match     show ip route x.x.x.x longer-prefixes
display ip routing-table protocol bgp             show ip route bgp
display bgp routing-table                         show ip bgp
display bgp routing-table x.x.x.x                 show ip bgp x.x.x.x
display bgp routing peer                          show ip bgp summary
display bgp routing regular-expression AS-number  show ip bgp regexp AS-number

Reset e Refresh

Comware                                           IOS

reset bgp x.x.x.x            (modo user-view)     clear ip bgp x.x.x.x
refresh bgp x.x.x.x import   (modo user-view)     clear ip bgp x.x.x.x in
                                                  clear ip bgp x.x.x.x soft in

refresh bgp x.x.x.x export                        clear ip bgp x.x.x.x out
                                                  clear ip bgp x.x.x.x soft out

Resumo sobre Border Gateway Protocol (BGP) – MASE Network Infrastructure – parte 1 de 2

Galera, esses dias participei de um treinamento para a certficação MASE Network Infrastructure voltado para a prova HP0-Y36.Fiz algumas anotações e conforme for organizando os “.txts” dos rascunhos, compartilharei aqui no blog para quem precisar da revisão para a prova. Espero que seja útil.

O Protocolo BGP é considerado o mais robusto Protocolo de  Roteamento para redes IP. Sua complexidade permite a conexão de múltiplos Sistemas Autônomos, chamados de AS (Autonomous systems), permitindo o roteamento dinâmico na Internet.

Um Sistema Autônomo é uma coleção de prefixos (rotas) sobre uma mesma política de roteamento e sobre o controle administrativo de uma mesma entidade (empresas, provedores de Internet [ISP’s]).

A Internet consiste em redes Comerciais conectadas por Provedores (ISP’s) como Telefônica,Embratel, Oi, CTBC e etc. Cada rede comercial ou Provedor deve ser identificado pelo Número do seu Sistema Autônomo (ASN) sobre controle do IANA .

O range disponível para o BGP é de 1 até 65635. Os ASN públicos disponíveis vão de 1 até 64511, já a utilização dentro de uma empresa do BGP, sem a comunicação com a Internet, poderá utilizar os valores de 64512 até 65535, chamados de uso privado.

A função primária de um sistema BGP é trocar informação de acesso à rede, inclusive informações sobre a lista das trajetórias dos ASes, com outros sistemas BGP. Esta informação pode ser usada para construir uma rede de conectividade dos ASes livre de loops de roteamento.

O BGP é considerado um Protocolo de Vetor de Distância avançado utilizando-se de vetores para contagem de saltos para cada destino. A contagem de saltos para o BGP é baseada em ASes.

  • O BGP é considerado um protocolo de roteamento externo usado para transmitir informações de roteamento entre ASes e como ponto de troca entre organizações.
  • Desenhado para grandes redes com necessidade complexas para políticas de roteamento.
  • O BGP roda sobre  TCP (porta 179) e requer a configuração manual  para conexão com o vizinho (peering).
  • BGP versão 4
  • Providencia uma série de atributos (métricas) para os prefixos anunciados, além de suportar CIDR. Também suporta diversas estratégias de filtro para o roteamento
  • Não gera informações periódicas de roteamento e sim atualizações engatilhadas (* triggered updates para os peers) além de mandar as atualizações em lote para os seus vizinhos  (* “batch” route updates).

Protocolos de roteamento interior (IGP) vs exterior (EGP)

  • Interior (RIP, OSPF, EIGRP, ISIS,etc)
    • descobrimento automático de vizinhos
    • os roteadores internos possuem informação completa da tabela de rotas
  • Exterior (BGP)
    •  os vizinhos são configurados estaticamente (não há um sub-processo como o Hello do OSPF para descoberta de vizinhos)
    • conexão com redes externas
    • demarcação clara de limites administrativos

Operação Geral

Roteadores BGP aprendem multiplos caminhos via BGP internos e externos.  Eles escolhem SOMENTE o melhor caminho e instala na tabela de roteamento IP. O Roteador BGP anuncia apenas as rotas que este utiliza (apesar da possibilidade de aprender sobre multiplos caminhos).

BGP peer

– A comunicação BGP entre roteadores é sobre uma conexão TCP.

– Roteadores são pares (peer) são classificados em:

  • … eBGP peer (external BGP)  se os roteadores estão em um Sistema Autonomo diferente
  • … iBGP peer (internal BGP)  se os roteadores estão em um  mesmo Sistema Autonomo.

– eBGP peer devem ter um link direto entre eles.

– iBGP peer não necessitam ter um link direto.

Obs: dentro de um AS os roteadores trocam roteamento interno via IGP, já os roteadores eBGP geralmente não trocam roteamento via IGP.

Configuração eBGP

Resumo BGP

As mensagens eBGP são encapsuladas no pacote IP com o TTL=1 por padrão. Caso seja necessário a conexão entre vizinhos eBGP por uma interface Loopback, o TTL deve ser alterado para 2: adicione o comando peer ebgpmax-hop 2

bgp 10
  peer <endereço da loopback do vizinho> as-number 20
  peer <endereço da loopback do vizinho> ebgp-max-hop 2
  peer <endereço da loopback do vizinho> connect-interface loopback0

Obs: Geralmente utilizado em cenários com redundância de Link. Certifique-se que o roteamento da interface Loopback do vizinho seja acessível pelos links redundantes.

Configuração iBGP

Devido ao fato de uma interface looopback estar sempre UP, ela é utilizada para configurar uma conexão TCP estável entre 2 vizinhos iBGP (geralmente a conexão é estabelecida via IGP).

Resumo iBGP

Observações

– Uma rota aprendida via iBGP não é ensinada para outros vizinhos iBGP como forma de prevenção de loop de roteamento

– Os roteadores iBGP de um AS devem formar uma conexão “full mesh” entre si ou utilizar outros mecanismos como Route Reflector e Confederation.

– Roteadores conectados via iBGP não necessitam estar diretamente conectado e sim acessivel via IGP (static, RIP, OSPF, etc.)

– Um Roteador iBGP não altera o next-hop de um prefixo aprendido via eBGP e que é ensinado na atualização para um vizinho iBGP. Certifique-se que o next-hop (endereço IP do próximo salto) seja acessível via IGP em todos roteadores do AS ou altere o next-hop para o vizinho das rotas aprendidas por eBGP com o comando “peer <endereço IP do peer iBGP> next-hop-local

Quando configurar um peer iBGP, lembre-se:

* Utilize o endereço da interface loopback do vizinho

* Utilize a sua interface loopback para conexão com o comando “connect interface
* Se o numero de vizinhos é grande, utilize a configuração de “groups

# Peer group Configuration
 bgp 10
 group as20 internal
 peer as20 as-number 20
 peer as20 connect-interface loopback0
 peer 192.1.254.2 group as20
 peer 192.1.254.3 group as20
 peer 192.1.254.4 group as20
 peer 192.1.254.5 group as20

Dica: O status correto para o “peering” entre 2 Roteadores iBGP e eBGP é Established

 Rotas BGP

Para uma rota ser anunciada no BGP, ela deve existir no Roteador (como estática, IGP, BGP)

1. redistribuição dinamica do IGP

– nem sempre a melhor opção
– requer configuração cuidadosas de filtragem de rotas
– caso um prefixo não esteja na tabela do IGP este deixa de ser anunciado
– mais utilizados em cenarios PE-CE

2. Redistribuição de rotas estáticas apontando para Null0 – mesmo que os prefixos estejam fora do IGP as redes são anunciadas

bgp 30
import-route static
quit
!
ip route 198.10.0.0 255.255.0.0 null 0

3. Comando network

– redes origininadas pelo roteador local
– rota deve existir no IGP

router bgp 30
network 192.168.0.0 255.255.0.0

Até logo! 🙂

No próximo post o resumo abordará algumas questões a manipulação e a escolha do melhor caminho para o BGP.