Comware7: Template para IPv6 Prefix-list

Um prefixo ‘bogon’ é uma rota que nunca deve aparecer na tabela de roteamento da Internet. Um pacote roteado pela Internet pública nunca deve ter um endereço de origem em um intervalo ‘bogon'(não incluindo VPNs ou outros tipos túneis). Estes são geralmente encontrados como  endereços de origem de ataques DDoS.

A equipe 6Bogon mantém recomendações atualizadas para Filtro de Pacotes e para Filtro de rotas IPv6 para xSP, descrevendo as recomendações para filtragem de pacotes e filtragem de rotas para uso em roteadores de borda que falam IPv6 em/com xSPs. Continue reading

Perguntas e Respostas: VRF x VPN-instance

Galera, segue abaixo um pequeno resumo sobre a nomenclatura utilizada nas documentações Cisco x HP sobre o assunto VRF. Acredito que possa ajudar de forma rápida a entender alguns conceitos:

VRF: Virtual Routing and Forwarding
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. Utilizado em cenários MPLS L3VPN com MP-BGP.

PeR-VRF

VRF Lite
A mesma funcionalidade que a VRF para criação de tabelas de roteamento independentes, mas nomeado para cenários sem MPLS L3VPN. Chamado também de Multi-VRF.

PeR-VRF-lite

VPN-Instance
Termo utilizado nas documentações HP para VRF no Comware.

MCE (Multi CE)
Termo utilizado nas documentações HP para VRF-Lite.

 

Dúvidas e colocações, deixe um comentário.

Roteadores HP: OSPF Virtual Link

O desenho de uma rede OSPF requer que todas as áreas estejam diretamente conectadas à Area Backbone (Area 0 [zero]) e que os roteadores da Area 0 estejam sempre conectados com roteadores da mesma área.

Para conexão entre roteadores de diferentes áreas, o tráfego deve passar sempre pela Area 0.

OSPF Areas

Um virtual link é um link lógico que permite a conexão entre equipamentos da Area 0 que estão separados logicamente mas podem utilizar uma outra Area OSPF como trânsito, ou entre áreas não-Backbone que precisam utilizar outra área como transito:

OSPF Virtual link

O OSPF virtual link deve ser usado somente em casos específicos, conexões temporárias ou cenários de backup em caso de falha.

Configurando OSPF Virtual link

No exemplo abaixo, o virtual link servirá na conexão entre dois roteadores da Area 0 que estão separados por uma falha no link.

OSPF Virtual link - AREA 0

R1
#
ospf 1
  area 0.0.0.0
  network 192.168.1.0 0.0.0.255
  network 192.168.11.0 0.0.0.255
 area 0.0.0.1
  network 192.168.12.0 0.0.0.255
  vlink-peer 192.168.3.3
#
R3
#
ospf 1
 area 0.0.0.0
  network 192.168.3.0 0.0.0.255
  network 192.168.33.0 0.0.0.255
 area 0.0.0.1
  network 192.168.23.0 0.0.0.255
  vlink-peer 192.168.1.1
#

Comandos display

[R1]display  ospf vlink
         OSPF Process 1 with Router ID 192.168.1.1
                 Virtual Links
 Virtual-link Neighbor-ID  -> 192.168.3.3, Neighbor-State: Full
 Interface: 192.168.12.1 (GigabitEthernet0/0)
 Cost: 2  State: P-2-P  Type: Virtual
 Transit Area: 0.0.0.1
 Timers: Hello 10, Dead 40, Retransmit 5, Transmit Delay 1

#
 [R1]display ospf peer
         OSPF Process 1 with Router ID 192.168.1.1
               Neighbor Brief Information
 Area: 0.0.0.1
 Router ID       Address         Pri Dead-Time  State             Interface
 192.168.12.2    192.168.12.2    1   35         Full/DR           GE0/0
 Virtual link:
 Router ID       Address         Pri Dead-Time  State             Interface
 192.168.3.3     192.168.23.3    1   36         Full              GE0/0

Até breve

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 7 – Configurando o GRE

O GRE (Generic Routing Encapsulation) é um protocolo de tunelamento que pode encapsular diversos protocolos dentro de tuneis IP, criando links ponto-a-ponto virtuais entre roteadores remotos.

O protocolo é extremamente funcional em diversos cenários, pois foi desenvolvido para permitir que redes remotas pareçam estar diretamente conectadas. Como o GRE não faz a criptografia, o GRE pode trabalhar em conjunto com IPsec para garantir a integridade das informações quando necessário.

Abaixo podemos observar a representação do encapsulamento de um pacote IP pelo GRE como também a inclusão de um novo cabeçalho.

GRE header

O interessante é que o protocolo de transporte poderia ser o IPv6 e o protocolo encapsulado poderia ser o IPX, tráfego Multicast, etc; E ao ser entregue ao roteador de destino, o novo cabeçalho é removido e o pacote é entregue intacto.

Segue abaixo um exemplo de configuração de um túnel GRE para Roteadores com o Comware 7, fechando a adjacência OSPF entre 2 roteadores separados por uma rede MPLS. Nos testes usamos o roteador HP VSR1000.

comware 7 GRE

Tabela de Rotas e tracert do Roteador R2

[R2]disp ip routing-table | inc O
192.168.1.0/24     O_INTRA 10  1563        192.168.13.1    Tun0

<R2>tracert 192.168.13.1
traceroute to 192.168.13.1 (192.168.13.1), 30 hops at most, 52 bytes each packet, press CTRL_C to break
 1  192.168.23.2 (192.168.23.2)  0.488 ms  0.523 ms  1.668 ms
 2  192.168.13.1 (192.168.13.1)  0.962 ms  5.463 ms  0.881 ms

<R2>tracert 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 30 hops at most, 52 bytes each packet, press CTRL_C to break
 1  192.168.1.1 (192.168.1.1)  1.116 ms  2.588 ms  1.731 ms

Referências

http://www.comutadores.com.br/roteadores-hp-6600-protocolo-de-tunelamento-gre/

http://www.rotadefault.com.br/protocolo-de-tunelamento-gre/

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.

Perguntas e Respostas: Substituindo roteamento entre redes do firewall para o Switch L3

Galera, gostaria de compartilhar uma dúvida frequente sobre como alterar o roteamento entre redes que esteja sendo executado por um firewall e mover essa função para um “Switch Core”.

Segue abaixo um dos e-mails:

  “Estou com uma dúvida com relação a gateway padrão da rede. Recentemente adicionei ao core de rede um switch L3, com isto estou projetando adicionar VLANs, mas para haver roteamento entre VLANs é necessário que o gateway padrão seja o switch, assim o firewall que atualmente é o gateway da rede, o deixará de ser. Como posso encaminhar os pacotes o quais atualmente são tratados pelo firewall? ”

Para melhor entendimento dos cenários, fiz um desenho com a topologia das redes sendo roteadas pelo firewall (cenário A) e o roteamento entre a rede executado pelo Switch L3 (cenário B).

Perguntas e respostas Firewall e Switch L3

No cenário A, temos todo tráfego entre redes sendo processado pelo firewall.

Em um cenário que o Switch possa fazer o roteamento entre as redes, você configurará a VLAN e a Interface-VLAN para as respectivas redes (cenário B). Cada rede terá uma VLAN e uma Interface-VLAN. Dessa forma você trabalhará para que o endereço IP da interface-vlan seja o gateway das máquinas (ao invés do firewall). Assim então o Switch fará o roteamento automático das redes, pelo fato de tê-las em sua tabela de roteamento, como diretamente conectadas.
O Switch também deverá ter uma rede de trânsito exclusiva com o firewall e deve apontar uma rota default para o Firewall.

Já o Firewall deverá ter uma rota de retorno para cada rede apontando como next-hop o endereço IP da rede de trânsito, com o IP do Switch (próximo salto).

As regras de Segurança, tradução de endereço, etc, continuam no firewall.

O roteamento entre VLANs acontecerá sem restrições no Switch Core. O Switch só encaminhará para o firewall o tráfego de saída da LAN.

Dúvidas e colocações, deixe um comentário.

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