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

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

Vídeo: Tabela de Roteamento

A tabela de roteamento possui registro dos destinos para encaminhamento dos pacotes. As rotas  podem ser aprendidas manualmente (rotas estáticas ou redes diretamente conectadas) e dinamicamente (aprendidos via protocolo de roteamento dinâmico como OSPF, BGP,etc).

Nesse vídeo faremos uma breve descrição do funcionamento, aprendizado e escolha das rotas por um Roteador.

Valeu!

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

Resumo: T38 – Fax over IP (FoIP) em Roteadores HP MSR

O Fax (abreviação de fac-símile) é a transmissão telefônica de material impresso digitalizado (texto e imagens), normalmente para um número de telefone conectado a uma impressora ou outro dispositivo de saída.

O protocolo T.38 permite transmitir mensagens de fax através de uma rede IP em tempo real (na velocidade da transmissão). Os aparelhos de FAX não necessariamente precisam obter informações sobre a rede e podem continuar a enviar as suas mensanges no padrão T.30.

O padrão T.38 Fax Relay foi concebido em 1998 como uma maneira de permitir que a mensagem via fax a seja transportadas através de redes IP entre terminais de fax existentes no padrão do Grupo 3.

Existem outros protocolos de envio de FAX sobre IP mas o padrão do ITU é o T.38.

Como T.38 Fax Relay funciona?

Os dados modulados pelo fax analógico são digitalizados pelo DSP (Digital Signal Processor) no gateway e as informações são geradas em binário.

A informações em binário são encapsuladas no pacote T.38 e então transportada pela rede IP.

O DSP no gateway de destino extrai a informação transportada pelo pacote T.38 e modula dentro do sinal de fax analógico tradicional.

T38

Configuração

No exemplo abaixo utilizaremos o mesmo exemplo do Configuration Guide do MSR 3012 para Voz, utilizando SIP entre duas localidades.

Comware T38

 

<RouterA> system-view
[RouterA] voice-setup
[RouterA-voice] dial-program
[RouterA-voice-dial] entity 2000 voip
[RouterA-voice-dial-entity2000] match-template 2000
[RouterA-voice-dial-entity2000] address sip ip 10.2.2.2
[RouterA-voice-dial-entity2000] fax protocol standard-t38 ls-redundancy 4
[RouterA-voice-dial-entity2000] quit
[RouterA-voice-dial] entity 1000 pots
[RouterA-voice-dial-entity1000] match-template 1000
[RouterA-voice-dial-entity1000] line 2/1/1
[RouterA-voice-dial-entity1000] fax protocol standard-t38 ls-redundancy 4
####
<RouterB> system-view
[RouterB] voice-setup
[RouterB-voice] dial-program
[RouterB-voice-dial] entity 1000 voip
[RouterB-voice-dial-entity1000] match-template 1000
[RouterB-voice-dial-entity1000] address sip ip 10.1.1.1
[RouterB-voice-dial-entity1000] fax protocol standard-t38 ls-redundancy 4
[RouterB-voice-dial-entity1000] quit
[RouterB-voice-dial] entity 2000 pots
[RouterB-voice-dial-entity2000] match-template 2000
[RouterB-voice-dial-entity2000] line 2/1/1
[RouterB-voice-dial-entity2000] fax protocol standard-t38 ls-redundancy 4

Para visualizar as estatísticas utilize os comandos:

display voice fax statistics
reset voice fax statistics

Até logo

Referências

https://www.youtube.com/watch?v=GkVUGeaIXjg

HPE FlexNetwork MSR Router Series – Voice – Configuration Guide Document version: 6PW104-20151118

https://en.wikipedia.org/wiki/T.38

 

Configurando IRF em Roteadores HP MSR

Os novos Roteadores MSR da HP possuem suporte para a configuração em IRF. O IRF é uma tecnologia que permite transformarmos diversos Switches ou Roteadores físicos em um único equipamento lógico. Todos os equipamentos serão visualizados como uma única “caixa”, aumentando a disponibilidade da rede.

A recomendação é efetuar o IRF com equipamentos da mesma família e modelo, mas há dispositivos que suportam equipamento da mesma família, mas com diferentes modelos. É bom pesquisar caso a caso.

O cenário abaixo foi construído utilizando o simulador HCL utilizando 2 Roteadores em IRF conectando um Router-Aggregation com um Switch 5820.

MSR em IRF

Configurando o IRF

Segue abaixo o passo-a-passo da configuração:

1º altere o irf-member ID do segundo Roteador (por padrão o member ID é 1) e o priority de cada equipamento para eleição do Master (vence o maior valor).

R1
<ROUTER>system
[ROUTER]irf priority 31

R2
<ROUTER>system
[ROUTER]irf member 2
[ROUTER]irf priority 30

Configurando as IRF-port

R1
[ROUTER]irf-port 1
[ROUTER-irf-port1]port group interface GigabitEthernet 0/0
[ROUTER-irf-port1]quit

R2
[ROUTER]irf-port 2
[ROUTER-irf-port2]port group interface GigabitEthernet 0/0
[ROUTER-irf-port2]quit

Habilitando o IRF

R1
[ROUTER]chassis convert mode irf
The device will switch to IRF mode and reboot.
You are recommended to save the current running configuration and specify the configuration file for the next startup. Continue? [Y/N]:y
Do you want to convert the content of the next startup configuration file flash:/startup.cfg to make it available in IRF mode? [Y/N]:y
Now rebooting, please wait...

R2
[ROUTER]chassis convert mode irf
....

Comandos display

[ROUTER]display irf

MemberID   Role   Priority CPU-Mac       Description
*+1       Master 31       90eb-4082-0100 ---
2       Standby 30       94cc-d87d-0200 ---
--------------------------------------------------
* indicates the device is the master.
+ indicates the device through which the user logs in.
The Bridge MAC of the IRF is: 90eb-4082-0100
Auto upgrade               : yes
Mac persistent             : 6 min
Domain ID                   : 0
Auto merge                 : yes

 

[ROUTER]display irf configuration
MemberID NewID   IRF-Port1                    IRF-Port2
1       1       GigabitEthernet1/0/0         disable
2       2       disable                       GigabitEthernet2/0/0

 

Configurando o Router-Aggregation nos MSRs em IRF

[ROUTER]interface Route-Aggregation 1
[ROUTER-Route-Aggregation1]link-aggregation mode dynamic
[ROUTER-Route-Aggregation1]ipv6 address 2001:db8:1234::a 64
[ROUTER-Route-Aggregation1]disp this

#
interface Route-Aggregation1
link-aggregation mode dynamic
ipv6 address 2001:DB8:1234::A/64
#
return
[ROUTER-Route-Aggregation1]quit

[ROUTER]interface GigabitEthernet 1/0/1
[ROUTER-GigabitEthernet1/0/1]port link-aggregation group 1
[ROUTER-GigabitEthernet1/0/1]interface GigabitEthernet 2/0/1
[ROUTER-GigabitEthernet2/0/1]port link-aggregation group 1
[ROUTER-GigabitEthernet2/0/1]end

Configuração do Switch

#
interface Bridge-Aggregation1
link-aggregation mode dynamic
#
#
interface GigabitEthernet1/0/1
port link-mode bridge
combo enable fiber
port link-aggregation group 1
#
interface GigabitEthernet1/0/2
port link-mode bridge
combo enable fiber
port link-aggregation group 1
#
interface Vlan-interface1
ipv6 address 2001:DB8:1234::B/64
#
[Router]disp link-aggregation verbose
Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing
Port Status: S -- Selected, U -- Unselected, I – Individual
Flags: A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,
D -- Synchronization, E -- Collecting, F -- Distributing,
G -- Defaulted, H -- Expired

Aggregate Interface: Route-Aggregation1
Aggregation Mode: Dynamic
Loadsharing Type: Shar
System ID: 0x8000, 90eb-4082-0100

Local:
Port             Status Priority Oper-Key Flag
--------------------------------------------------------------------------------
GE1/0/1         S       32768   1        {ACDEF}
GE2/0/1         S       32768   1         {ACDEF}
Remote:
Actor           Partner Priority Oper-Key SystemID               Flag
--------------------------------------------------------------------------------
GE1/0/1         3       32768   1         0x8000, 94de-65c3-0300 {ACDEF}
GE2/0/1         2       32768   1         0x8000, 94de-65c3-0300 {ACDEF}

 

[Router]ping ipv6 2001:db8:1234::b
Ping6(56 data bytes) 2001:DB8:1234::A --> 2001:DB8:1234::B, press CTRL_C to break
56 bytes from 2001:DB8:1234::B, icmp_seq=0 hlim=64 time=2.000 ms
56 bytes from 2001:DB8:1234::B, icmp_seq=1 hlim=64 time=1.000 ms
56 bytes from 2001:DB8:1234::B, icmp_seq=2 hlim=64 time=0.000 ms
56 bytes from 2001:DB8:1234::B, icmp_seq=3 hlim=64 time=1.000 ms
56 bytes from 2001:DB8:1234::B, icmp_seq=4 hlim=64 time=1.000 ms

--- Ping6 statistics for 2001:db8:1234::b ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.000/1.000/2.000/0.632 ms
[Router]%Jan 26 13:40:07:783 2016 Router PING/6/PING_STATISTICS: Ping6 statistics for
2001:db8:1234::b: 5 packets transmitted, 5 packets received, 0.0% packet loss, round-trip
min/avg/max/std-dev = 0.000/1.000/2.000/0.632 ms.

Até logo