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: 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

 

Comware 7 : Configurando PBR (Policy-Based Routing)

A maneira como efetuamos o roteamento de pacotes baseado endereço de destino do cabeçalho IP  possui algumas restrições que não permitem o balanceamento de tráfego de maneira granular de acordo com perfis das aplicações, dessa forma todos os pacotes são roteados para o mesmo lugar sem levarmos em conta a rede de origem, protocolo, etc.

A utilização de PBR, policy-based routing, permite ao engenheiro de rede a habilidade de alterar o comportamento padrão de roteamento baseando-se em diferentes critérios ao invés de somente a rede de destino, incluindo o endereço de rede de origem, endereços TCP/UDP de origem e/ou destino, tamanho do pacote, pacotes classificados com fins de QoS, etc.

Mas por qual razão utilizaremos PBR ?

O PBR pode ser utilizado em diversos cenários, para os mais diversos fins. No exemplo abaixo a rede 192.168.1.0/24 acessa a rede 172.16.0.1 com uma rota default configurada para o Link A, imaginando que uma segunda demanda surge para que a rede de homologação 192.168.2.0/24 acesse assim a Internet pelo Link A mas já o acesso para rede 172.16.0.1, deva ocorrer preferivelmente pelo link B. Nesse caso o PBR entraria para corrigir essa questão (lembrando que na tabela de roteamento o acesso para rede 172.16.0.1 é apontado para o Link A, criaríamos uma exceção somente para a nova rede).

PBR

Segue exemplo da configuração:

#
acl number 2000
 rule 0 permit source 192.168.2.0 0.0.0.255
! ACL para match na rede 192.168.2.0
#
policy-based-route XYZ permit node 10
 if-match acl 2000
 apply next-hop 192.168.223.3
! PBR dando match na ACL 2000 e encaminhar o 
! tráfego para o next-hop do link B
#
#
interface GigabitEthernet0/0/3
 port link-mode route
 ip address 192.168.12.2 255.255.255.0
 ip policy-based-route XYZ
! Aplicando o PBR na interface Giga0/0/3
#

A implementação da PBR é bastante simples, ele é definido para ser configurado usando o processo policy-based routing que é muito similar a configuração de uma route-policy (route-map) . O tráfego a ser tratado pelo PBR será comparado (match) utilizando uma ACL e em seguida tem o novo destino ou parâmetros alterados usando um comando apply + atributo.

Se o pacote não corresponder à política de PBR ou se o encaminhamento baseado em PBR falhar, o dispositivo utilizará a tabela de roteamento para encaminhar os pacotes.

Outros parametros dentro do PBR

PBR options Comware

Entre os outros parametros do PBR está o output-interface, default-next-hop e o default-output-interface.

Output-interface: Esse comando permite atribuir a interface de saída do trafego ao invés do IP do next-hop.

Default-next-hop / default-output-interface:Se o processo de roteamento baseado na tabela de rotas falhar, o equipamento utilizará o default next hop ou default output interface definido no PBR para encaminhar os pacotes.

Ao utilizar qualquer combinação destes comandos dentro de um PBR os comandos são avaliados na seguinte ordem:

apply next-hop
apply output-interface
apply default-next-hop
apply default-output-interface

O PBR é uma ferramenta muito poderosa que pode ser usada para controlar os caminhos específicos de tráfego de rede, porém certifique-se de usar apenas PBR quando for necessário. Como muitas outras features oferecidas em qualquer tipo de roteador, elas são projetadas para um conjunto específico de circunstâncias, o mesmo e deve ser utilizado para esses fins para assim manter a eficiência.

Referências

http://blog.pluralsight.com/pbr-policy-based-routing

HP 5920 & 5900 Switch Series- Layer 3 – IP Routing – Configuration Guide

Comware: Rota estática flutuante (floating static route)

Uma rota estática flutuante é uma rota estática com uma distância administrativa maior do que a estabelecida por padrão em Switches e Roteadores. Por exemplo, no Comware da HP as rotas estáticas possuem distância administrativa com o valor 60 e o protocolo OSPF com as rotas externas com o valor 150, nesse caso pelo fato da menor distância administrativa ser escolhida quando duas rotas idênticas são aprendidas de maneiras distintas pelo roteador, o equipamento escolherá o processo com menor AD ( administative distance/ distancia administrativa).

Como exemplo, poderíamos imaginar um roteador com 2 links, em um deles a rota 192.168.1.0/24 pode ser aprendida via rotas externas OSPF e nesse caso precisaremos encaminhar o tráfego para esse link como principal. Já como backup configuraríamos a rota estática 192.168.1.0/24 com a distância administrativa com o valor 250 apontando para o next-hop do segundo link.

Quando o primeiro link apresentar problemas, o processo OSPF perceberá a falha e removerá a rota 192.168.1.0/24 aprendida dinamicamente e começará a utilizar a rota estática (não utilizada anteriormente) com o mesmo endereço 192.168.1.0/24 configurada para encaminhar os pacotes para o segundo link.

Quando o OSPF voltar a funcionar com o restabelecimento do primeiro link, a rota estática deixará de ser utilizada, voltando para o encaminhamento de pacotes pela rota aprendida dinamicamente.

[Comware]  ip route-static 192.168.1.0 255.255.255.0 172.17.1.2 preference 250

Obs: Lembre-se que a rota estática só entrará na tabela de roteamento se a interface correspondente ao próximo salto (next-hop) estiver UP.

Caso tenham alguma dúvida sobre o assunto, deixem um comentário.

http://pt.wikipedia.org/wiki/Dist%C3%A2ncia_administrativa

http://www.rotadefault.com.br/rota-estatica-flutuante-floating-static-route/

Abração a todos

 

Resumo: BGP – Router Reflector em Roteadores HP

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

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

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

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

iBGP rule HP

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

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

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

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

iBGP rule and RR HP

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

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

Cluster_List e Originator_ID

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

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

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

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

Router Reflector cluster id HP

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

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

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

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

Até logo

Referências

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

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

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

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

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

Dicionário de Comandos BGP: Comware vs Cisco

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

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

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

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

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

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

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

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

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

Troubleshooting

Comware                                           IOS

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

Reset e Refresh

Comware                                           IOS

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

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

Video: Roteamento entre VLANs e configuração de rota estática para Switches HPN, 3Com e H3C

Fala Galera, tudo bom!?

Segue mais uma vídeo-aula produzida por nós, contendo dessa vez o assunto Roteamento entre VLANs utilizando Switches ou Roteadores, além de falarmos também sobre roteamento estático, Topologia, etc.. para equipamentos baseados no Comware (HP , 3Com e H3C) .

Ainda estou apanhando um pouco no formado das vídeo-aulas, mas espero que o vídeo seja útil. 😉




Abração

Roteadores HP 6600 – MPLS L2VPN com Martini através de um Túnel GRE

O script abaixo permite a extensão de um domínio de Broadcast através de uma rede IP utilizando o protocolo MPLS sobre um Túnel GRE sem a utilização de BGP em um roteador HP 6600.

Utilizei o cenário durante uma demanda para a extensão de um domínio de Broadcast entre 2 Data Centers Pares em quem o link dedicado para o Serviços de Computação em Nuvem sofreu atraso. O sincronismo dos Serviços  utilizando a camada de enlace (camada 2 do modelo OSI) foi estabelecido com a solução abaixo, visto que haviam restrições para configurar o mesmo serviço com MP-BGP por políticas de roteamento.

A solução permite o trânsito de quadros tagueados com 802.1q.

Obs: Antes de estabelecer o túnel GRE, certifique que as interfaces Loopback estejam acessíveis via Roteamento.

MPLS L2VPN Martini atraves de GRE

Espero ter sido útil. 🙂