BGP – Mandatory Well-Known (Path Attributes)

O Protocolo BGP utiliza diversos parâmetros para escolha de melhor rota quando há diversos caminhos para o mesmo destino, esses parâmetros são chamados de Path Atributes.

Cada atualização do BGP consiste em uma ou mais sub-redes (prefixos) vinculadas aos seus atributos.

Os Path Atributes são classificados em Well-Known ( bem conhecido ) ou Optional (opcional). Alguns desses atributos são obrigatórios e outros opcionais com validade local na tabela de roteamento, local no AS, etc.

Os atributos Well-Known são classificados em Mandatory(obrigatório ) e Discretionary ( arbitrário).

No tópico de hoje citaremos os atributos MandatoryWell-Known (bem conhecidos e obrigatórios).

Mandatory Well-Known

São 3 os atributos Mandatory Well-Known – Origin, AS-Path e Next-hop:

Origin: Relaciona a maneira que a rota foi aprendida pelo BGP. Se a rota foi declarada com o comando network ou via agregação de rotas ela será exibida com a letra “i”, para as rotas aprendidas via redistribuição é utilizado o caracter “?”. Há ainda a possibilidade da rota ser aprendida via o protocolo EGP,”e” mas atualmente o mesmo está em desuso.

AS-Path: Quando um prefixo é injetado no BGP e compartilhado entre os AS, inicialmente o AS-Path é atribuído como vazio, cada vez que a rota atravessa um AS(Sistema Autônomo) é adicionado pelos roteadores de Borda o numero do AS que ele pertence. É possível rastrear a sequencia de Sistemas Autônomos utilizando o atributo AS-Path.

Next-hop: Indica o endereço do próximo salto do Roteador que recebeu o prefixo. Geralmente o roteador que anuncia determinado prefixo repassa com o next-hop o seu próprio IP, exceto em sessões iBGP.

SHOW

O comando show ip bgp exibirá a saída da tabela BGP do Roteador com Cisco IOS:

Router>show ip bgp
BGP table version is 2709, local router ID is 172.16.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop        Metric LocPrf Weight Path
   Network          Next Hop        Metric LocPrf Weight Path
* i1172.31.1.0/29   0.0.0.0              0    100  32768 i
* i1172.16.10.0/24  0.0.0.0              0    100  32768 ?
* i1172.16.11.0/24  192.168.85.22        0    100      0 65510 65544 65516 65541 ?
*>                  192.168.85.23        0             0 65510 65544 65516 65541 ?
* i1172.16.12.0/22  192.168.85.22        0    100      0 65510 65544 65516 65541 ?
*>                  192.168.85.23        0             0 65510 65544 65516 65541 ?

[saída omitida]

! A rede 172.31.1.0/29 está diretamente conectada no Roteador e inserida processo via comando Network ! Já a rede 172.16.10.0/24 foi inserida na tabela BGP via processo de redistribuição

Peering BGP

O comando show ip bgp summary exibe os “peerings” BGP:

Router>show ip bgp summary
BGP router identifier 172.16.1.1, local AS number 65500
BGP table version is 2709, main routing table version 2709
258 network entries using 29154 bytes of memory
510 path entries using 24480 bytes of memory
6725/10 BGP path/bestpath attribute entries using 672500 bytes of memory
2 BGP rrinfo entries using 48 bytes of memory
856 BGP AS-PATH entries using 32108 bytes of memory
270 BGP community entries using 7536 bytes of memory
12 BGP extended community entries using 304 bytes of memory
197 BGP route-map cache entries using 6304 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 772434 total bytes of memory
BGP activity 449536/418807 prefixes, 1538082/1477309 paths, scan interval 60 secs

Neighbor      V    AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down  State/PfxRcd
192.168.85.22 4 65510  962698  517851  2701   0    0 1w2d         24
192.168.85.23 4 65510  517865  517853  2701   0    0 1w2d         25
Router>

Até logo!

Flexible Netflow

Netflow é uma tecnologia disponível no Cisco IOS que fornece estatísticas dos pacotes que atravessam um roteador ou Switch. O Netflow coleta e exporta os dados para fins de monitoração, segurança da rede, análise de trafego, análise de capacidade, IP accounting e etc.

Ao invés de apenas contar os pacotes, o NetFlow considera esses pacotes como parte de um fluxo, monitorando o início, meio e fim. Podemos definir um fluxo como uma sequência unidirecional de pacotes que possuem características comuns entre a origem e o destino.

Flexible Netflow (FNF)

Flexible Netflow (FNF) aprimora o NetFlow com a possibilidade de personalização dos parâmetros para análise do tráfego e facilita a criação de configurações com uma granularidade bem bacana. O FNF é dividido em três funções: a seleção de dados que queremos analisar (flow record), a coleta de dados (flow monitor) e a exportação dos dados para um coletor (flow export).

Para concluir a configuração, um monitor de fluxo pode ser aplicado a uma ou várias interfaces.

Segue abaixo o script bem intuitivo e o resultado da coleta.

Configuração

flow exporter EXPORTER
 description Netflow Collector
 destination 10.10.10.10
 source Loopback0
 transport udp 9996
 template data timeout 60
! Configuração do Flow Exporter
!
flow record QoS
match ipv4 tos
match ipv4 precedence
match ipv4 dscp
match ipv4 protocol
match ipv4 source address
match ipv4 destination address
match transport source-port
match transport destination-port
collect counter bytes long
collect counter packets long
! Configuração do Flow Record
!
flow monitor MONITOR-QoS
cache timeout inactive 30
record QoS
exporter EXPORTER
exit
! Configuração do Flow Monitor
!
ip cef
!
interface e0/0.45
ip flow monitor MONITOR-QoS input
! Aplicando o Flow Monitor a interface
!
 

Output

R5#sh flow monitor MONITOR-QoS cache format ta
  Cache type:                               Normal
  Cache size:                                 4096
  Current entries:                               5
  High Watermark:                               12
  Flows added:                                 398
  Flows aged:                                  393
    - Active timeout      (  1800 secs)          2
    - Inactive timeout    (    30 secs)        391
    - Event aged                                 0
    - Watermark aged                             0
    - Emergency aged                             0
IPV4 SRC ADDR    IPV4 DST ADDR    TRNS SRC PORT  TRNS DST PORT  IP TOS  IP DSCP  IP PREC  IP PROT            bytes long             pkts long
===============  ===============  =============  =============  ======  =======  =======  =======  ====================  ====================
155.1.45.4       224.0.0.10                   0              0  0xC0    0x30           6       88                 18000                   300
155.1.146.6      155.1.45.5               16384          52366  0xB8    0x2E           5       17                 60000                  1000
150.1.6.6        150.1.5.5                   80          63906  0x40    0x10           2        6                   385                     5
150.1.6.6        155.1.45.5                1967          54932  0xB8    0x2E           5       17                    52                     1
155.1.146.6      155.1.45.5               16384          54932  0xB8    0x2E           5       17                 13740                   229
R5#

Até logo!

Distância Administrativa

por Woshington Silva

Os roteadores utilizam a distância administrativa para escolher o melhor caminho quando aprendem mais de uma rota para o mesmo destino através de protocolos distintos.  A confiabilidade de um protocolo de roteamento é definida através da distância administrativa.

Quanto menor o valor da distância administrativa mais confiável o protocolo. Esses valores variam de 0 à 255, onde 0 é mais confiável e 255 é menos confiável

Exemplo:
Em um roteador temos duas rotas aprendidas por protocolos distintos para uma determinada rede, a primeira rota foi descoberta pelo protocolo de roteamento RIP e  a segunda pelo protocolo de roteamento OSPF. Baseando-se na tabela abaixo, qual caminho o roteador irá escolher?

*Valores padrão de distância administrativa dos protocolos suportados pela Cisco

Ao verificarmos a tabela acima vimos que a rota onde apresenta o protocolo OSPF será escolhida como melhor caminho e assim inserida na tabela de roteamento, já que o valor 110 do protocolo OSPF está mais próximo de 0 do que o valor  120 do protocolo RIP. Portanto o protocolo OSPF é mais confiável do que o protocolo RIP.

Porém se por algum motivo quiséssemos alterar o valor padrão da distancia administrativa, isso é possível através do comando  “distance”, conforme veremos abaixo:

Router(config)#router rip
Router(config-router)# distance 80
Router(config-router)# end

Se aplicarmos essa configuração no exemplo acima o roteador adicionará na tabela de roteamento a rota do protocolo RIP ao invés da rota do protocolo OSPF, já que agora o valor da distância administrativa do RIP passará a ser de 80, portanto menor que 110 da distância administrativa do OSPF.

Obs: Caso haja uma alteração no valor padrão para 255, o roteador não incluirá a rota na tabela de roteamento, ele irá entender que a rota é totalmente não-confiável.

E se a duas rotas fossem descobertas pelo mesmo protocolo de roteamento?
Quando isso acontece, o roteador irá escolher a rota que tiver a melhor métrica e assim inseri-la na tabela de roteamento.

 Uma informação importante é que a distância administrativa tem um significado local, sendo assim, ela não é anunciada nas atualizações de roteamento, se você alterar o valor padrão só o roteador onde ocorreu a mudança sentirá o efeito.

Por fim…
Podemos verificar a distância administrativa com aos seguintes comandos show ip route e show ip protocols, conforme veremos nas imagens abaixo:

Até o próximo artigo!

MPLS (Multi Protocol Label Switching) – parte 2

Como iniciado no primeiro post, em uma rede com arquitetura MPLS cada roteador da topologia possui uma designação que define a sua posição e atribuição na topologia:

  • CE (Customer Edge Router) – possui a função de prover conectividade para a rede MPLS e é situado na “borda do cliente”. Não encaminha e nem troca labels.
  • PE (Provider Edge Router) – é responsável pela conexão entre uma rede IP (rede do cliente) e a rede MPLS (rede da Operadora/Provider)
  • P (Provider Edge Router) – é responsável pelo encaminhamento de pacotes baseando-se nos labels.

Label Switch Router

Diversas documentações também atribuem um nome mais genérico para roteadores que tratam o recebimento e encaminhamento de pacotes MPLS, chamados de Label Switch Routers(LSR). Na topologia, os LSR podem ser chamados de:

  • Ingress LSRs – responsáveis por receber um pacote não “rotulado” e inserir o Label
  • Egress LSRs – responsáveis por receber um pacote “rotulado” e remover o Label
  • Intermediate LSRs – responsáveis por inserir, encaminhar e trocar Labels.

Os Roteadores LSRs são responsáveis por três operações principais para encaminhamento de pacotes e/ou labels: POP (remover o label), PUSH (inserir o label) ou SWAP (trocar o label).

A seqüência de Roteadores LSRs que são responsáveis pela comutação de um pacote com label em uma rede MPLS, é chamada de LSP (Label Switched Path).

O LSP é definido como o caminho por onde os pacotes irão passar numa rede MPLS. No momento em que um pacote entra numa rede MPLS, este é associado a uma classe de equivalência (FEC) e assim é criado um LSP relacionado a esta FEC.

Como a criação de uma LSP só ocorre na entrada de uma rede MPLS, os LSR ( Label Switch Router) da nuvem só terão o trabalho de fazer as trocas dos rótulos (swap), encaminhando assim o pacote de acordo com o LSP determinado anteriormente, não havendo mais a necessidade de fazer o roteamento dos pacotes (somente a comutação via Label).

Protocolos de distribuição de Labels

Atualmente são utilizados 2 principais protocolos para distribuição de Rótulos em uma rede MPLS, (daremos um foco especial no LDP):

  • Label Distribution Protocol (LDP)
  • Resource Reservation Protocol – Traffic Engineering (RSVP-TE)

O vinculo de Rótulos é a associação de um label a um prefixo (rota). O LDP trabalha em conjunto com um IGP (OSPF, IS-IS, etc) para anunciar os vínculos de labels (binding) para as rotas, como por exemplo, em um backbone. Conforme desenho abaixo:

Resumidamente, é atribuído um valor de label para cada prefixo. No exemplo abaixo segue o exemplo da configuração do LDP em um Roteador P com o processo OSPF em um roteador com IOS Cisco.

Exemplo de Configuração do Roteador P

ip cef
mpls ip
mpls ldp router-id loopback 0
!
int loo 0 
ip add 10.2.2.2 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.1.1.5 255.255.255.252
 mpls label protocol ldp
 mpls ip
!
interface FastEthernet0/1
 ip address 10.1.1.1 255.255.255.252
 mpls label protocol ldp
 mpls ip
!
!
router ospf 1
 log-adjacency-changes
 network 10.1.1.0 0.0.0.3 area 0
 network 10.1.1.4 0.0.0.3 area 0
 network 10.2.2.2 0.0.0.0 area 0
!
----------------------------------------------

R2#show mpls forwarding-table 
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
23     Pop tag     10.1.1.0/30       636      Fa0/0      point2point
24     Pop tag     10.1.1.4/30       641          Fa0/1      point2point
25     26          192.168.1.0/24    234          Fa0/0      point2point
26     30         192.168.1.0/24     143          Fa0/1      point2point
27     28         192.168.2.0/30     143          Fa0/1      point2point
-
R2#show mpls ldp neighbor
    Peer LDP Ident: 10.1.1.2:0; Local LDP Ident 10.1.1.5:0
        TCP connection: 10.1.1.2.646 - 10.1.1.1.11012
        State: Oper; Msgs sent/rcvd: 21/21; Downstream
        Up time: 00:10:29
        LDP discovery sources:
          FastEthernet0/0, Src IP addr: 10.1.1.2
        Addresses bound to peer LDP Ident:
          10.1.1.2        
    Peer LDP Ident: 10.1.1.6:0; Local LDP Ident 10.1.1.5:0
        TCP connection: 10.1.1.6.11000 - 10.1.1.5.646
        State: Oper; Msgs sent/rcvd: 28/31; Downstream
        Up time: 00:16:00
        LDP discovery sources:
          FastEthernet0/1, Src IP addr: 10.1.1.6
        Addresses bound to peer LDP Ident:
          10.1.1.6        192.168.1.0      192.168.2.0


Referências

http://www.gta.ufrj.br/grad/04_2/MPLS/conceitos.htm
http://blog.ccna.com.br/2008/09/12/multi-protocol-label-switching-mpls-parte-3/

BGP Communities

O protocolo BGP possui a versatilidade de agregar redes e atributos; anunciando e modificando cada prefixo de maneira individual. Um desses atributos, o Community permite “taguear”  o anuncio de cada rede individualmente de acordo com o negócio, políticas de roteamento ou para fins de troubleshooting.

De forma básica o uso de community (ou “comunidade BGP” em português) pode ser usado como uma flag para marcar um determinado grupo de rotas.

Provedores de Serviço utilizam essas marcações para aplicar políticas de roteamento específicas em suas redes, por exemplo alterando o Local PreferenceMED ou Weight.

O atributo community é opcional e transitivo (optional transitive)  e de tamanho variável, isto é, implementações BGP não necessitam reconhecer o atributo e fica ao critério do administrador de rede alterar ou reencaminhar para outros pares . O atributo consiste em um número de 32 bits que específica uma community. Sendo que sua representação é feita AA:NN onde o AA é o Autonomous System (AS) e o NN é o número da community.

Um prefixo pode participar de mais de uma community e  os roteadores BGP podem tomar uma ação em relação à um prefixo baseado em uma, algumas ou todas as communities associadas ao prefixo.

O comando utilizado para configurar uma community em um Roteador Cisco (baseado no IOS) é via set community dentro de um route-map:

R1(config-route-map)#set community ?
  <1-4294967295>  community number
  aa:nn           community number in aa:nn format
  additive        Add to the existing community
  internet        Internet (well-known community)
  local-AS        Do not send outside local AS (well-known community)
  no-advertise    Do not advertise to any peer (well-known community)
  no-export       Do not export to next AS (well-known community)
  none            No community attribute

O comando “set community” apaga a comunidade existente vinculada a um prefixo substituindo-o pela nova community, a menos que seja especificado o comando additive após o valor da community.

 R1(config-route-map)#set community 65535:1 additive

A community pode ser aplicada em um ou mais prefixos  com a utilização de route-maps nos seguintes itens do processo BGP:

  • No peering BGP de in/out
  • Redistribuição
  • Comando network

Três communities são definidas e reservadas na RFC 1997 para implementações  BGP: NO-EXPORT (0xFFFFFF01 ), NO-ADVERTISE (0xFFFFFF02 ), and NO-ADVERTISE-SUBCONFED (0xFFFFFF03 ). Adicionalmente, NO-PEER (0xFFFFFF04 ) tem sido proposta em um draft para Internet [3].

NO-EXPORT é geralmente utilizado dentro de um AS para instruir os roteadores para não exportar o prefixo para vizinhos eBGP.

NO-ADVERTISE instrui um roteador BGP para não encaminhar o prefixo “tagueado” para qualquer vizinhos, seja iBGP ou eBGP.

NO-ADVERTISE-SUBCONFED é utilizado para prevenir um prefixo de ser anunciado para outros membros dentro da confederação.

NO-PEER é usado em situações onde é necessário o controle de engenharia de tráfego ao longo de um prefixo “mais específico”,  restringindo a sua propagação apenas aos prestadores de trânsito e não seus pares. Ou seja, o prefixo é anunciado de AS para AS, desde que haja uma relação de trânsito / cliente, ao contrário do NO-EXPORT, que restringe a propagação do prefixo somente ao AS adjacente.  Atualmente tal comunidade não é reconhecido pela maioria dos fabricantes e requer uma implementação manual.

Durante processos complexos de redistribuição de IGPs no BGP, o uso de community pode ser usado para detectar o protocolo de origem (por exemplo, uma community para IS-IS outra definida para OSPF, etc).

Community List

A Community-list é como uma ACL, só que para communities. Essas listas são adicionadas com o comando “ip community-list ” onde o valor é representado por “AA:NN” ou por caracteres especiais como, por exemplo, “*” que representa tudo.

Exemplo de configuração

No exemplo abaixo iremos anunciar 3 prefixos do ASN 65524, dois serão marcados com community e um sem  community. No ASN 65525 iremos atribuir um valor de local preference para cada prefixo de acordo com a comunidade atribuída.

Roteador R4
!
ip bgp-community new-format
! Exibe o valor da community de 32 bits dividido em 2 de 16 separados por ":"
!
! Configurando as route-maps para atribuir o valor de community
route-map SET_COMM_B permit 10
 set community 65524:2
!
route-map SET_COMM_A permit 10
 set community 65524:1
!
router bgp 65524
 no synchronization
 bgp log-neighbor-changes
 network 172.16.100.0 mask 255.255.255.0 route-map SET_COMM_A
 network 172.16.101.0 mask 255.255.255.0 route-map SET_COMM_B
 network 172.16.102.0 mask 255.255.255.0
! Anunciando as redes no processo BGP de acordo com as communities atribuídas 
 neighbor 192.168.45.5 remote-as 65525
 neighbor 192.168.45.5 send-community
! Permitindo o envio de community para o peer BGP 
 no auto-summary
!
ip classless
ip route 172.16.100.0 255.255.255.0 Null0
ip route 172.16.101.0 255.255.255.0 Null0
ip route 172.16.102.0 255.255.255.0 Null0
!
end
Roteador R5
!
ip bgp-community new-format
! Exibe o valor da community de 32 bits dividido em 2 de 16 separados por ":"
!
! Community-list para filtro de valores de Communities
ip community-list standard LOCAL_PREF_150 permit 65524:1
ip community-list standard LOCAL_PREF_200 permit 65524:2
!
!
route-map SET_LOCAL_PREF permit 10
 match community LOCAL_PREF_150
 set local-preference 150
! Atribuindo o local preference aos prefixos da community-list
!
route-map SET_LOCAL_PREF permit 20
 match community LOCAL_PREF_200
 set local-preference 200
! Atribuindo o local preference aos prefixos da community-list
!
route-map SET_LOCAL_PREF permit 30
!
router bgp 65525
 neighbor 192.168.45.4 remote-as 65524
 neighbor 192.168.45.4 send-community
 neighbor 192.168.45.4 route-map SET_LOCAL_PREF in
! Atribuíndo os route-maps configurados no peering BGP
 no auto-summary
!
ip classless
!
end
!
! Verificando o valor de Local Preference atribuído a cada prefixo
R5#show ip bgp
BGP table version is 4, local router ID is 192.168.45.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure
Origin codes: i - IGP, e - EGP, ? – incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.100.0/24  192.168.45.4             0    150      0 65524 i
*> 172.16.101.0/24  192.168.45.4             0    200      0 65524 i
*> 172.16.102.0/24  192.168.45.4             0             0 65524 i
!
! Verificando o valor de community atribuído ao prefixo
R5#show ip bgp 172.16.100.0
BGP routing table entry for 172.16.100.0/24, version 2
Paths: (1 available, best #1)
  Not advertised to any peer
  65524
    192.168.45.4 from 192.168.45.4 (192.168.45.4)
      Origin IGP, metric 0, localpref 150, valid, external, best
      Community: 65524:1

Até logo!!!

Referências

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

http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_6-2/bgp_communities.html

http://www.rfc-editor.org/rfc/rfc1997.txt

IKE Fase 1: Resumo

Quando você está tentando fazer a uma conexão segura entre 2 hosts através da Internet, um caminho seguro deverá ser estabelecido, como por exemplo, por uma conexão VPN IPSec. Além dos mecanismos de autenticação e validação da informação a VPN IPSec necessita de um mecanismo eficiente de gestão de chaves.

O processo de gestão de chaves diz respeito à criação, eliminação e alteração das chaves. A implementação de uma solução VPN IPSec  utliza-se de um processo de criptografia que envolve uma periódica troca de chaves, embora o IPSec não integre um mecanismo de gestão de chaves, o IETF definiu como norma de gestão o protocolo híbrido ISAKMP/Oakley também denominado IKE, Internet Key Exchange para autenticar os dispositivos e  gerar as chaves criptografadas. O protocolo IKE utiliza o termo security association (SA), que é um acordo entre os equipamentos pares para troca de tráfego IPSec utilizando os requerimentos necessários para estabelecer as proteções aplicadas em uma conexão.

No estabelecimento de uma comunicação segura, passa-se pelas seguintes fases IKE:

Fase 1: Ocorre num meio inseguro. Tem o objetivo de estabelecer um canal seguro que irá proteger as trocas da Fase 2. É executada uma vez para várias fases 2;
Fase 2: Ocorre no canal seguro criado na fase 1. As suas negociações têm o objetivo de estabelecer as associações de segurança que irão proteger a comunicação.

Após estas duas fases, encontra-se estabelecido um canal seguro através do qual ocorre comunicação segura. Nesse post abordaremos apenas a Fase 1.

IKE Fase 1

A principal finalidade dessa primeira troca é permitir que os equipamentos finais consigam definir os parâmetros SA para estabelecer um canal seguro para futuramente estabelecer uma conexão IPSec. Tal canal é chamado IKE SA. Esse canal tem a função de criar criptografia e autenticação bidirecional para as outras trocas IKE e passagem de pacotes IPSec.

O IKE SA pode ser realizado de duas formas:

  • Modo Principal (Main Mode): negocia a criação da conexão através da troca de três pares de mensagem.
    • primeira troca de mensagens é relativa as formas de criptografia, autenticação (escolha dos algoritmos) e criação de chaves assimétricas.
    • segunda troca de mensagens utiliza o algoritmo Diffie-Hellman para trocas das chaves criadas, da assinatura digital ou da chave pública, de acordo com os parâmetros definidos.
    • terceiro par de mensagens verifica a identidade do outro lado. O valor de identidade é o endereço IP do par IPSec na forma criptografada. A principal  função do main mode é combinar IKE SA (security association)  entre os pares para fornecer uma conexão protegidas para posteriores trocas ISAKMP entre os peers IKE. O IKE SA especifica valores para a troca IKE: o método de autenticação usado, a criptografia, os algoritmos de hash, o grupo Diffie-Hellman (DH) utilizado, a vida útil do IKE SA em segundos ou quilobytes, e os valores de chaves secretas compartilhadas para os algoritmos de criptografia. O IKE SA em cada par é bi-direcional.
  • Modo Agressivo(Agressive Mode): é uma alternativa mais rápida ao modo principal, já que negocia a criação IKE SA através de três mensagens, ao invés de três pares de mensagens. A primeira mensagem de um dos extremos manda os parâmetros de segurança, juntamente com sua porção da chave criada por Diffie-Hellman e sua identidade. O outro extremo envia sua parte da chave, parâmetros de segurança e sua autenticação (geralmente por assinatura digital). Na última mensagem o primeiro extremo envia sua autenticação ao outro. Com essas três mensagens a conexão IKE SA está criada. Se ganha em velocidade, mas perde-se em segurança, por exemplo, as chaves podem ser interceptadas e forjadas.

No cenário abaixo, utilizando o Cisco IOS como exemplo, com o estabelecimento de uma conexão segura entre roteadores de uma empresa para uma VPN IPsec, em vez de negociarmos cada protocolo para criptografia, autenticação, etc , individualmente; podemos agrupar os protocolos em conjunto de politicas IKE (IKE policy).

O comando crypto isakmp policy define o IKE Fase 1, com os parâmetros utilizados durante a negociação. A sintaxe do comando crypto isakmp policy “priority” define a prioridade da policy. Caso os valores de criptografia, hash, DH e lifetime não sejam configurados, serão escolhidos os valores default (des, sha, rsa-sig, 1 e 86400 respectivamente).

Para configurar a pre-shared key (PSK) utilize a sintaxe:

 crypto isakmp key “tipo de cifragem da senha na configuração”  senha hostnameaddress endereço.

Nos próximos posts daremos continuidade no script para a Fase 2 e modos IPSec.

Referência

http://www.gta.ufrj.br/grad/08_1/vpn/ipsecelementos.html#_Toc200023677

http://civil.fe.up.pt/acruz/Mi99/asr/IPSec.htm

Implementing Cisco IOS Network Security , Cisco press – Catherine Paquet
Network Security Technologies and Solutions, Cisco press – Yusuf Bhaiji

Ambiente de Lab Gratuito – Cisco Devnet Sandbox

O ambiente Cisco DevNet Sandbox permite que engenheiros, desenvolvedores, administradores de rede, arquitetos ou qualquer pessoa que queira desenvolver e testar as APIs, controladores, equipamentos de rede, suíte de colaboração e muito mais da ferramentas da Cisco, possa fazê-lo gratuitamente!

Cisco DevNet Sandbox
https://developer.cisco.com/site/sandbox/

Outros Links
Meraki API V1: https://developer.cisco.com/meraki/api-v1/
Postman, API development tool: https://www.postman.com/
Meraki API V1 Postman Documentation (import from here): https://documenter.getpostman.com/view/897512/SzYXYfmJ
Getting started with Postman: https://developer.cisco.com/meraki/build/meraki-postman-collection-getting-started/
https://documenter.getpostman.com/view/897512/SzYXYfmJ#intro

SD-WAN – QUAIS SÃO OS DESAFIOS DA WAN QUE A TECNOLOGIA VEM SOLUCIONAR?

SD-WAN é a sigla para se referir ao termo “Software-Defined Wide Area Network”. Trata-se de uma abordagem onde as definições de tráfego são controladas por software de forma a se criar uma rede overlay para permitir a conectividade no âmbito de redes WAN.

Podendo ser composta de links dedicados, Internet de banda larga e serviços sem fio, a tecnologia SD-WAN permite gerenciar aplicativos de maneira eficiente, em particular aqueles na nuvem.

O tráfego é encaminhado de maneira automática e dinâmica pelo caminho WAN mais adequado e eficiente com base nas condições de rede, demandas das aplicações, requisitos de QoS e custo de circuito.

Como escolher um transceiver para o seu switch, controladora e roteador Cisco?

A página https://tmgmatrix.cisco.com/ auxilia os administradores de rede e parceiros a identificar quais são os transceivers compatíveis para cada equipamento Cisco. O site possui um mecanismo de busca que auxilia a pesquisa por tipo de transceiver, Part Number, modulo ou dispositivo de rede.

Uma vez identificado os transceivers compatíveis a página ainda oferece mais detalhes para cada um dos tipos de transceivers como padrões, distâncias, compatibilidade com DOM, IOS, se o transceiver é EoS/EoL e assim por diante.

Configuração de rota estática IPv6

Durante o recebimento de pacotes para acessar outras Redes externa a LAN para comunicação entre máquinas IPv6, o roteador efetuará uma consulta na sua tabela de roteamento IPv6 para verificar se existe alguma rota para o destino. Se a rota existir o pacote será encaminhado, senão, o pacote será descartado.

A maior parte dos parâmetros de configuração de rotas estáticas em IPv6 são idênticos ao IPv4. Como por exemplo, rota estática padrão, sumarizada e flutuante.

Abaixo a sintaxe de um roteador Cisco IOS:

Router(config)# ipv6 route rede/prefixo [próximo-salto]

O next-hop (ou próximo salto) pode ser identificado por um endereço IPv6, interface de saída ou ambos.

É possível verificar a tabela de roteamento IPv6 com o comando show ipv6 route.

A rota “ipv6 route ::0 0 [próximo-salto]” é uma “rota padrão” e corresponde a qualquer prefixo IPv6 (utilizado quando uma rota específica não é encontrada na tabela de roteamento).

Exemplo de Configuração

Antes de iniciar a configuração de rotas estáticas IPv6, habilite o encaminhamento de pacotes  IPv6 configurando ipv6 unicast-routing no modo de configuração global.

Endereço do next-hop como link-local

Caso haja a necessidade de configurar o endereço de next-hop como endereço IPv6 link-local, é necessário configurar a interface de saída, como no exemplo abaixo:

Router(config)#ipv6 route 2001:DB8:222::/64 FastEthernet0/0 FE80::C802:71FF:FEFC:

Testes

Para validar as rotas configuradas resumimos alguns comandos abaixo:

Router# ping ipv6 [endereço do host em IPv6]
!Testes de Ping

Router# traceroute [endereço do host em IPv6]
!Testes de tracerout

Router# show ipv6 route
!Verificar tabela de roteamento IPv6

Router# show ipv6  interface [interface com endereço IPv6 no roteador]
! Verifique todos os endereços IPv6 da interface ( global, link-local, etc)

Até logo.