Custo OSPF

O protocolo OSPF permite a todos roteadores em uma área ter a visão completa da topologia. O protocolo possibilita assim a decisão do caminho mais curto baseado no custo que é atribuído a cada interface, com o algoritmo Dijkstra. O custo de uma rota é a soma dos custos de todas as interfaces de saída para um destino. Por padrão, os roteadores calculam o custo OSPF baseado na fórmula Cost =Reference bandwidth value / Link bandwidth.

Caso o valor da “largura de banda de referência” não seja configurado, os roteadores usarão o valor de 100Mb para cálculo. Por exemplo, se a interface for 10Mb, calcularemos 100Mb dividido por 10Mb, então o custo da interface será 10. Já os valores fracionados, serão arredondados para valor inteiro mais próximo e toda velocidade maior que 100Mb será atribuído o custo 1.

Veja no exemplo abaixo o custo que o R1 atribui as suas interfaces:

R1#show ip ospf interface ethernet 1/1
Ethernet1/1 is up, line protocol is up
 Internet Address 192.168.13.1/24, Area 0
 Process ID 1, Router ID 1.1.1.1,Network Type BROADCAST,Cost: 10
! saída omitida

R1#show ip ospf interface ethernet 1/0
Ethernet1/0 is up, line protocol is up
 Internet Address 192.168.12.1/24, Area 0
 Process ID 1, Router ID 1.1.1.1,Network Type BROADCAST,Cost: 10
! saída omitida  e o custo atribuído para a Loopback é 1
R1#show ip ospf interface loo 1
Loopback1 is up, line protocol is up
 Internet Address 1.1.1.1/24, Area 0
 Process ID 1, Router ID 1.1.1.1, Network Type LOOPBACK, Cost: 1

O custo do Roteador R1 para a Loopback do Roteador R2 será 11.

R1#show ip route | inc 2.2.2.2
O       2.2.2.2 [110/11] via 192.168.12.2, 01:01:46, Ethernet1/0

Alterando o custo de uma interface …

R1#interface Ethernet1/0
ip ospf cost 200
! Alterando o custo da interface para 200

R1#show ip route 2.2.2.2
Routing entry for 2.2.2.2/32
Known via "ospf 1", distance 110, metric 21, type intra área
Last update from 192.168.13.3 on Ethernet1/1, 00:10:06 ago
Routing Descriptor Blocks:
* 192.168.13.3, from 2.2.2.2, 00:10:06 ago, via Ethernet1/1
Route metric is 21, traffic share count is 1


Caso seja necessário alterar a referência para largura de banda utilize o seguinte comando em um roteador Cisco IOS:

R1(config)# router ospf 100
R1(config-router)#auto-cost reference-bandwidth ?
    The reference bandwidth in terms of Mbits per second

O “auto-cost reference-bandwidth 100″ é o default para 100Mb, onde 100Mb na topologia tem o custo = 1 .  Assim, para ter links 1G com o custo = 1 , o “auto-cost…” deve ser configurado como 1000. Se a referência for links 10G , “auto-cost…” seria 10000 , para 100G, seria 100000 .

Obs: Lembre-se de sempre manter o “auto-cost reference-bandwidth” consistente em todos os roteadores para evitar comportamentos inesperados no roteamento.

Até logo!

VLAN – Trunk utilizando 802.1q (dot1q)

A utilização de VLAN (Virtual Local Area Network) permite que uma rede física seja dividida em várias redes lógicas dentro de um Switch. A partir da utilização de VLANs, uma estação não é capaz de comunicar-se com estações que não são pertencentes a mesma VLAN (para isto, é necessário a utilização de uma sub-rede por VLAN e que o tráfego passe primeiro por um roteador para chegar a outra rede [ou utilizando um Switch Multicamada para efetuar o Roteamento]).

Se não utilizássemos uma interface como Trunk e precisássemos passar o tráfego da VLAN para o outro Switch, seria necessário a passagem de um cabo de cada VLAN para o outro dispositivo, como no exemplo abaixo.

Como a maioria dos Switches possui entre 24 e 48 portas a solução ficaria inviável, inutilizando a maioria das portas para conexões entre os dispositivos.

O protocolo IEEE 802.1q permite utilizarmos apenas um cabo na comunicação entre os Switches, marcando cada Frame (quadro) com o ID de cada VLAN.

A marcação efetuada (chamada de TAG) adiciona aos quadros Ethernet 4 bytes no frame original e calculam um novo valor de checagem de erro para o campo FCS.

Dos valores contidos dentro do campo TAG o número da VLAN é adicionado ao campo VLAN id permitindo a identificação da VLAN entre os Switches.

Uma observação relevante é a utilização do campo Priority (também dentro da TAG) para função de QoS em camada 2 para Ethernet, chamado de 802.1p ou CoS (Class of Services), permitindo a diferenciação de classes de serviços por Switches sem a necessidade de leitura do campo IP.

Já a comunicação entre computadores no mesmo Switch que pertencem a mesma VLAN não são “tagueadas” (untagged). Muitas placas de rede para PC’s e impressoras não são compatíveis com o protocolo 802.1Q e ao receberem um frame tagged, não compreenderão o TAG de VLAN e descartarão a informação.
Os Switches que recebem na sua interface Trunk um frame com TAG, irão remover o campo e entregar o quadro ao destino sem a marcação.

A regra é bem simples para a maioria dos casos (salvo exceções):

  • Para comunicação entre Switches, configure as interfaces como Trunk ( Tagged)
  • Para comunicação entre Switches e hosts, servidores, impressoras; configure as interfaces como Access (untagged) com o ID da VLAN

Configuração

Para a maioria dos Switches Cisco IOS, configure as portas como trunk da seguinte maneira (desde que as VLANs  já tenham sido criadas no Switch ou aprendidas via VTP):

interface GigabitEthernet 1/0/x
! acesso a interface GigabitEthernet
port link-type trunk
! configuração da interface como trunk (frames encaminhados como tagged)
port trunk permit vlan all
! configuração da porta permitindo todas as VLANs no trunk

Um detalhe importante a ser percebido é  sintaxe switchport trunk encapsulation dot1q . Apesar do protocolo 802.1q não encapsular o quadro Ethernet, a sintaxe Cisco solicita a configuração do protocolo via o comando   .  Suponho que a sintaxe deva ter surgido quando a Cisco apostava na utilização de interfaces Trunk utilizando o protocolo ISL  que efetivamente encapsulava o quadro Ethernet.

Portas de acesso:

interface GigabitEthernet 1/0/x
! acesso a interface GigabitEthernet
port link-type access
! configuração da interface como acesso (frames encaminhados como untagged)
port access vlan 2
! configuração da porta na vlan 2

Obs: Por default os frames da VLAN 1 não são encaminhados com TAG dentro do Trunk.

Abraços a todos!!!

DHCP Snooping

A feature DHCP Snooping permite a proteção da rede contra Servidores DHCP não autorizados.

Com o DHCP Snooping configurado, o Switch inspeciona as mensagens DHCP entre uma máquina cliente e servidor com a troca das mensagens: DHCP Discover, DHCP Offer, DHCP Request e o DHCP Ack, como o desenho abaixo:

O comando “ip dhcp snooping” configurado globalmente habilita o serviço no Switch.

Com o serviço habilitado, informe explicitamente qual VLAN deverá filtrar as mensagens DHCP Offer e DHCP Ack ; com o comando “ip dhcp snooping vlan vlan-range”.

ip dhcp snooping
! Habilitando o processo globalmente
ip dhcp snooping vlan 20
! Habilitando o dhcp snooping na vlan 20

Os comandos listados restringirão todas as portas do Switch na VLAN 20 como untrusted (não confiável). Filtrando todas as mensagens de oferta do serviço DHCP (a solicitação de serviço DHCP pela máquina cliente não sofrerá nenhuma restrição).

Para o funcionamento do “Servidor DHCP válido” deveremos configurar a porta do Servidor como trusted (confiável) , incluíndo as portas de UpLink.
No Exemplo, configuraremos o dhcp-snooping no Switch com a porta GigabitEthernet 1/8 conectada ao servidor DHCP válido como trust.

Configuração

Switch#conf t
Switch(config)#interface GigabitEthernet1/8
Switch(config-if)#ip dhcp snooping trust

Visualisando

O DHCP-Snooping constrói uma tabela que contém o endereço IP liberado pelo servidor DHCP vinculado ao endereço MAC.

Switch# show ip dhcp snooping binding
MacAddress   IpAddress      Lease(sec) Type  VLAN  Interface
00:FF:16:89:E6:88 192.168.20.2 86250   dhcp-snooping  10  Gi1/12

Switch# show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
20
DHCP snooping is configured on the following Interfaces:
Insertion of option 82 is enabled
   circuit-id format: vlan-mod-port
    remote-id format: MAC
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
Interface                    Trusted     Rate limit (pps)
------------------------     -------     ----------------
GigabitEthernet 1/8          yes         unlimited
GigabitEthernet 1/12         no          unlimited

Dúvidas e sugestões, deixe um comentário! ;)

Referências
https://supportforums.cisco.com/pt/blog/153731

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

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.

Rota estática flutuante (floating static route)

Uma rota estática flutuante é uma rota com uma distância administrativa maior do que a estabelecida por padrão em Switches e Roteadores. Por exemplo, no IOS da Cisco as rotas estáticas possuem distância administrativa com o valor 1 e o protocolo OSPF com o valor 110, nesse caso pelo fato da menor distância administrativa ser escolhida quando duas rotas idênticas (com a mesma “rede” e “máscara de rede”) são aprendidas de maneiras distintas pelo roteador, o dispositivo 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 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 (incluindo novamente a rota 192.168.1.0/24 de maneira dinâmica), a rota estática deixará de ser utilizada.

Rt(config)# ip route 192.168.1.0 255.255.255.0 172.17.1.2 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, deixe um comentário.

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

Cisco IOS: Pseudowires com L2TPv3

O protocolo L2TPv3 (Layer 2 Tunneling Protocol Version 3) é um padrão do IETF que pode ser usado como um protocolo alternativo ao MPLS para encapsulamento de vários protocolos de camada 2 em comunicações de redes IP e MPLS. o L2TPv3 oferece um serviço de pseudo-wire (PW) que simula o tráfego como se fosse um cabo ou fibra apagada entregue entre 2 pontos.

Os Pseudo-wires carregam o quadro Ethernet completo, incluindo o cabeçalho MAC. O quadro é inserido dentro do pacote L2TPv3 e transmitido para o seu roteador Par. O Roteador Par remove o cabeçalho do protocolo L2TPv3 e encaminha o quadro Ethernet intacto. Caso seja necessário o encaminhamento de TAGs 802.1q o mapeamento do VLAN ID deverá ser efetuado para cada VLAN.

Nesse post focaremos o uso do L2TPv3 sobre uma rede IP, para simular uma conexão de “Camada 2” entre dois sites distintos (o domínio de Broadcast será estendido).

Segue abaixo a configuração

Os seguintes passos abaixo deverão ser levados em conta na configuração ao iniciar a configuração do L2TPv3 em um Roteador com IOS Cisco.

  • Habilite o CEF
  • Use uma interface Loopback para uso da conexão do ponto-a-ponto para o pseudo-wire
  • Certifique-se que o roteamento entre os roteadores esteja ok.
  • Configure o peudowire class
  • Vincule o pseudowire à interface

Validação

R2#  show l2tun tunnel l2tp
L2TP Tunnel Information Total tunnels 1 sessions 1
LocID RemID Remote Name   State  Remote Address  Port  Sessions L2TP Class/
                                                                VPDN Group
54490 54540 R3            est    10.3.3.3         0     1        l2tp_default_cl

Como teste utilizamos a rede 192.168.45.0/24 nos sites R4 e R5
R4#ping 192.168.45.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.45.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 172/197/228 ms

Referências
http://www.shafagh.com/2009/10/ccie-sp-l2tpv3.html
http://tools.ietf.org/html/rfc3931
http://prol2tp.com/documentation.php?page=l2tpv3.html
http://www.networkworld.com/community/node/26272

Cisco IOS: Configurando QinQ

A feature QinQ (802.1Q sobre 802.1Q), conhecido também como Stacked VLAN ou VLAN sobre VLAN, suporta a utilização de duas TAGs 802.1Q no mesmo quadro Ethernet para trafegar uma VLAN dentro de outra VLAN – sem alterar o TAG 802.1Q original.

No caso do QinQ(802.1ad), a visão do o cliente é como se a Operadora tivesse estendido um cabo (como uma fibra apagada ou cabo UTP) entre 2 equipamentos, Switches por exemplo.

Já para a Operadora não importa se o cliente está mandando o tráfego (entre 2 filiais) com TAG ou sem TAG, pois ele adicionará mais uma TAG ao cabeçalho e removerá na outra ponta apenas a ultima TAG inserida.

Em resumo, o tráfego no sentido de entrada na porta configurada com QinQ adicionará uma TAG 802.1Q ao quadro (TAG da Operadora/Provedor), mesmo em casos que já houver a marcação de VLANs, entretanto no sentido de saída, é removido apenas a última TAG acrescentada, sendo mantida a TAG 802.1Q inserida pelo cliente.

Configurando

No Exemplo acima, com Switches Cisco, para o tráfego ser “tunelado” com a TAG adicional, devemos configurar os Switches A e B com uma VLAN para cada cliente , a configuração das interfaces conectadas aos Switches também deverão usar o comando “switchport mode do1q-tunnel”.

Em caso de necessidade de transporte de protocolos da camada enlace como CDP, LACP e STP, é possivel utilizar na interface algum dos comandos abaixo:

l2protocol-tunnel [cdp | stp | vtp]

A configuração dos Switches de cada cliente, nessa topologia, não sofre nenhuma alteração em particular; e a visão de cada cliente  será  como se os Switches estivessem diretamente conectados.

O “encapsulamento”  do QinQ adiciona 4 bytes ao cabeçalho para cada quadro. Os Switches que recebem e encaminham os quadros  QinQ devem aumentar o MTU para 1504.  O MTU configurado, será verificado  utilizando o comando show system mtu.  Para aumentar o MTU  utilize o commando system mtu 1504, entretanto, essa mudança requer que o Switch seja reiniciado.

Os frames com a TAG 802.1Q possuem o TPID 0x8100, no caso do QinQ (IEEE 802.1ad) o TPID poderá ter outros valores, como 0x9100.

Abraços a todos!