BGP

Comware 7: Configuração de VXLAN com BGP EVPN

Diego DiasLeave a comment

O Ethernet Virtual Private Network (EVPN) é uma tecnologia VPN de Camada 2 VPN que fornece conectividade entre dispositivos tanto em Camada 2 como para Camada 3 através de uma rede IP. A tecnologia EVPN utiliza o MP-BGP como plano de controle (control plane) e o VXLAN como plano de dados/encaminhamento (data plane) de um switch/roteador. A tecnologia é geralmente utilizada em data centers em ambiente multitenant ( com múltiplos clientes e serviços) com grande tráfego leste-oeste.

A configuração do EVPN permite ao MP-BGP automatizar a descoberta de VTEPs, assim como o estabelecimento de tuneis VXLAN de forma dinâmica, a utilização de IRB (Integrated Routing and Bridging) anuncia tanto as informações  de Camada 2 e 3 para acesso ao host, fornecendo a utilização do melhor caminho através do ECMP e minimizando flood do trafego multidestination (BUM: broadcast,unicast unknown e multicast)  .

Em resumo o EVPN possui um address Family que permite que as informações de MAC, IP, VRF e VTEP sejam transportadas sobre o MP-BGP, que assim permitem aos VTEPs aprender informações sobre os hosts (via ARP/ND/DHCP etc.).

O BGP EVPN distribui e fornece essa informação para todos os outros pares BGP-EVPN dentro da rede.

Relembrando o VXLAN

O VXLAN prove uma rede de camada 2 sobreposta (overlay) em uma rede de camada 3 (underlay). Cada rede sobreposta é chamada de segmento VXLAN e é identificada por um ID único de 24 bits chamado VNI – VXLAN Network Identifier ou VXLAN ID.

A identificação de um host vem da combinação do endereço MAC e o VNI.  Os hosts situados em VXLANs diferentes não podem comunicar entre si (sem a utilização de um roteador). O pacote original enviado por um host na camada 2 é encapsulado em um cabeçalho VXLAN que inclui o VNI associado ao segmento VXLAN que aquele host pertence.

Os equipamentos que transportam os tuneis VXLAN são chamados de VTEP (VXLAN tunnel endpoints).

Quando um VXLAN VTEP ou tunnel endpoint comunica-se com outros VXLAN VTEP, um túnel VXLAN é estabelecido. Um túnel é meramente um mecanismo de transporte através de uma rede IP.

Todo o processamento VXLAN é executado nos VTEPs. O VTEP de entrada encapsula o tráfego com cabeçalho VXLAN, mais um cabeçalho UDP externo , mais um cabeçalhos IP externo, e então encaminha o tráfego por meio de túneis VXLAN. O VTEP do destino remove o encapsulamento VXLAN e encaminha o tráfego para o destino.

Os dispositivos da rede IP de transporte encaminham o tráfego VXLAN apenas com base no cabeçalho IP externo dos pacotes VXLAN (eles não precisam ter suporte à tecnologia VXLAN).

Uma imagem contendo screenshot, texto Descrição gerada automaticamente

Um outro ponto importante é que a tecnologia VXLAN supera as limitações de apenas 4 mil domínios de broadcast fornecido por VLANs para até 16 milhões de domínios de broadcast com VNIs. Já para as limitações do Spanning-Tree que coloca os caminhos redundantes em estado de bloqueio, a tecnologia VXLAN permite a construção de todos os uplinks como parte de um backbone IP (rede underlay), utilizando protocolos de roteamento dinâmico para escolha do melhor caminho ao destino, assim fazendo uso do ECMP (Equal Cost Multipath) em uma topologia Spine-Leaf, por exemplo.

BGP EVPN

O BGP EVPN difere do comportamento “Flood and Learn” executado por tuneis VXLANs em diversas maneiras. Enquanto o tráfego multidestination (BUM: broadcast,unicast unknown e multicast) encaminhado pelo VXLAN sem o BGP EVPN necessita de utilizar grupos multicast, o EVPN permite a replicação da identificação dos dispositivos finais com o MP-BGP , assim como as informações do VTEP que ele está associado. As comunicações ARP para IPv4 também pode ser suprimida, aprimorando assim a eficiência do transporte dos dados.

LAB

No laboratório abaixo utilizamos os roteadores HP VSR no release R0621P18-X64, no EVE-NG.

Ambos os Spines estão configurados como VTEP e encaminharão o tráfego do VXLAN VNI 10. A instancia criada para esse cliente, chamamos de ‘clientea’.

O Spine está configurado como BGP Router Reflector fechando peerring com ambos Leafs. Nenhum Leaf fecha peering BGP entre si, somente como Spine.

Texto preto sobre fundo branco Descrição gerada automaticamente

Configuração SPINE 1

#
 sysname Spine-01
#
interface LoopBack0
description OSPF_UNDERLAY
 ip address 192.168.0.1 255.255.255.255
#
interface LoopBack1
description BGP_EVPN_UNDERLAY
 ip address 192.168.0.11 255.255.255.255
#
interface GigabitEthernet1/0
description CONEXAO_LEAF3
 ip address 192.168.13.1  255.255.255.0
#
interface GigabitEthernet2/0
description CONEXAO_LEAF4
 ip address 192.168.14.1 255.255.255.0
#
ospf 1 router-id 192.168.0.1
 description UNDERLAY_OSPF
 area 0.0.0.0
  network 192.168.0.1 0.0.0.0
  network 192.168.0.11 0.0.0.0
  network 192.168.14.0 0.0.0.255
  network 192.168.13.0 0.0.0.255
#
bgp 65001
 group evpn internal
 peer evpn connect-interface LoopBack1
 peer 192.168.0.33 group evpn
 peer 192.168.0.44 group evpn
 #
 address-family l2vpn evpn
  undo policy vpn-target
  peer evpn enable
  peer evpn reflect-client
#

Configuração LEAF 3

#
 sysname Leaf-03
#
interface LoopBack0
description OSPF_UNDERLAY
 ip address 192.168.0.3 255.255.255.255
#
interface LoopBack1
description BGP_EVPN_UNDERLAY
 ip address 192.168.0.33 255.255.255.255
#
interface GigabitEthernet1/0
description CONEXAO_SPINE1
 ip address 192.168.13.3 255.255.255.0
 ospf network-type p2p
#
ospf 1 router-id 192.168.0.3
 description UNDERLAY_OSPF
 area 0.0.0.0
  network 192.168.0.3 0.0.0.0
  network 192.168.0.33 0.0.0.0
  network 192.168.13.0 0.0.0.255
#
bgp 65001
 peer 192.168.0.11 as-number 65001
 peer 192.168.0.11 connect-interface LoopBack1
 #
 address-family l2vpn evpn
  peer 192.168.0.11 enable
#
 vxlan tunnel mac-learning disable
#
 l2vpn enable
#
vsi clientea
 arp suppression enable
 vxlan 10
 evpn encapsulation vxlan
  route-distinguisher auto
  vpn-target auto export-extcommunity
  vpn-target auto import-extcommunity
  quit
#
interface GigabitEthernet3/0
 xconnect vsi clientea
#

Configuração LEAF 4

#
 sysname Leaf-04
#
interface LoopBack0
description OSPF_UNDERLAY
 ip address 192.168.0.4 255.255.255.255
#
interface LoopBack1
description BGP_EVPN_UNDERLAY
 ip address 192.168.0.44 255.255.255.255
#
interface GigabitEthernet2/0
description CONEXAO_SPINE2
 ip address 192.168.14.4 255.255.255.0
  ospf network-type p2p
#
ospf 1 router-id 192.168.0.4
 area 0.0.0.0
  network 192.168.0.4 0.0.0.0
  network 192.168.0.44 0.0.0.0
  network 192.168.14.0 0.0.0.255
#
bgp 65001
 peer 192.168.0.11 as-number 65001
 peer 192.168.0.11 connect-interface LoopBack1
 #
 address-family l2vpn evpn
  peer 192.168.0.11 enable
#
 vxlan tunnel mac-learning disable
#
 l2vpn enable
#
vsi clientea
 arp suppression enable
 evpn encapsulation vxlan
  route-distinguisher auto
  vpn-target auto export-extcommunity
  vpn-target auto import-extcommunity
  quit
  vxlan 10
  quit
#
interface GigabitEthernet3/0
 xconnect vsi clientea
#

Comandos Display bgp l2vpn evpn

Tela de computador com texto preto sobre fundo branco Descrição gerada automaticamente

Comando display vxlan tunnel

Uma imagem contendo desenho Descrição gerada automaticamente

Referências

R2702-HPE FlexFabric 5940 & 5930 Switch Series EVPN Configuration Guide

KRATTIGER, Lukas; KAPADIA, Shyam; JANSEN, David; Building Data Centers with VXLAN BGP EVPN – A Cisco NX-OS Perspective – 2017 CiscoPress

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

Diego DiasLeave a comment

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

Diego DiasLeave a comment

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

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

Diego Dias1 Comment

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

Diego Dias1 Comment

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

Diego DiasLeave a comment

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

Diego Dias1 Comment

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 😉

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

Diego Dias1 Comment

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

Diego Dias1 Comment

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.

Alterando a distancia administrativa para os protocolos de Roteamento em Switches e Roteadores HPN (Comware)

Diego Dias2 Comments

Há alguns posts atrás comentamos sobre a diferença da Distância Administrativa para as rotas aprendidas dinâmicamente em Switches e Roteadores dos fabricantes Cisco e HPN (H3C/3Com) e a atenção que deve ser dada em ambientes com Protocolos de Roteamento que possuem Switches e Roteadores  de ambos fabricantes

http://www.comutadores.com.br/distancia-administrativa-em-switches-l3-e-roteadores-h3c3comhp-serie-a/

A Distância Administrativa possui apenas função local e não é compartilhada pelo protocolo de roteamento.

Como por exemplo, em um Roteador utilizando o OSPF (como IGP) e o BGP para aprender as “rotas externas”, se uma mesma rota fosse aprendida via OSPF e BGP, o comportamento para escolha do melhor caminho seria diferente em Rotadores Cisco (a distancia administrativa para o OSPF é 110 e o  eBGP é 20) e HPN ( o OSPF é 10 e o eBGP é 255). Lembrando que para prefixos iguais aprendido por diferentes protocolos o Roteador escolhe a rota com menor distância administrativa.

Uma coisa bacana do Comware é poder alterar o valor da distância administrativa  baseado no processo de Roteamento, por exemplo, se tivermos 2 processos OSPF rodando no Router/Switch é possível alterar a distancia administrativa em um dos processos sem afetar o outro ( muito útil quando se utiliza VRFs [ vpn-instance] em um mesmo roteador) .

Para redes que utilizam MP-BGP, tambem é possível alterar a distância administrativa no address-family do cliente.

Veja o exemplo abaixo para a tabela de roteamento Global (eBGP e iBGP com a distância adminstrativa em 255) e a tabela de roteamento da vpn-instance cliente-A (com o eBGP como 7 e o iBGP como 100).

<Router>display ip routing-table
Routing Tables: Public
Destinations : 18177     Routes : 18177

Destination/Mask    Proto  Pre  Cost         NextHop         Interface
0.0.0.0/0           BGP    255  0            10.180.226.197  GE3/1/6.100
192.168.9.0/24      BGP    255  0            10.180.226.197  GE3/1/6.100
192.168.10.0/24     BGP    255  0            10.180.226.197  GE3/1/6.100
192.168.11.0/24     BGP    255  0            10.180.226.197  GE3/1/6.100
<saída omitida>

<Router>display ip routing-table vpn-instance cliente-A
Routing Tables: cliente-A
Destinations : 1789      Routes : 1789
Destination/Mask    Proto  Pre  Cost         NextHop         Interface
1.1.1.1/32          BGP    7    0            192.168.176.217  GE9/1/7
2.2.2.0/29          BGP    7    0            192.168.176.217  GE9/1/7
192.168.80.0/30     BGP    100  0            192.168.229.193  NULL0
10.1.1.1/32         BGP    7    0            192.168.176.217  GE9/1/7
<saída omitida>

Para configurar a distancia administrativa dentro processo BGP ou dentro do processo “ipv4-family vpn-instance [nome da vrf]” no BGP use a sintaxe:

[Router-bgp]preference ?
INTEGER<1-255>  External preference
!Distancia administrativa para rotas aprendidas via eBGP

[Router-bgp]preference 7 ?
INTEGER<1-255>  Internal preference
!Distancia administrativa para rotas aprendidas via iBGP

[Router-bgp]preference 7 100 ?
INTEGER<1-255>  Local preference
!Distancia administrativa para rotas aprendidas via iBGP (locais)

[Router-bgp]preference 7 100 9

Para o OSPF  utilize o commando preference para alterar a distância administrativa de rotas OSPF e OSPF ASE:

[Router-ospf-1]preference ?
INTEGER<1-255>  Preference value
ase             AS external link states

[Router-ospf-1]preference ase ?
INTEGER<1-255>  Preference value

Até logo!