OSPF on Cisco Redes

Já ouviu falar sobre BFD?

Fri, 04 Nov 2016 00:00:00 +0000

Olá Pessoal,

Hoje vou explicar um pouco sobre esse protocolo chamado BFD ( Bidirectional Foward Detect ), baseando-se na RFC 5880.

BFD é um protocolo de rede usado para detectar falhas entre dois equipamentos que estão conectados por um link. Ele fornece detecção em meios físicos que não suportam a detecção de falha, tais como Ethernet, circuitos virtuais, túneis e MPLS. O grande divisor de “água” desse protocolo esta na sua capacidade de detectar falhas de links em milésimos de segundos ou até microssegundos. Todos protocolos de roteamento têm algum tipo de mecanismo para detectar falhas de link. OSPF usa pacotes de Hello, Dead Interval, o EIGRP usa Hello e temporizador de holddown, etc.

BFD roda independente de qualquer outro protocolo de roteamento. Uma vez que está instalado e funcionando, você pode configurar protocolos como OSPF, EIGRP, BGP, HSRP, MPLS LDP etc. para usar BFD para detecção de falha no link, em vez de seus próprios mecanismos. Quando a link falhar, BFD irá informar o protocolo. Veja abaixo um exemplo:

Existem dois modos de operação para BFD, ” asynchronous mode e demand mode “. O modo assíncrono é semelhante aos hello e holddown, onde BFD vai continuar enviando pacotes Hello (chamados de pacotes de controle do BFD) e quando você não receber alguns deles, a sessão é considerada down. Para o demand mode eu não conheço nenhum fabricante que trabalhe com essa funcionalidade,

Agora como todos nos gostamos, vamos ver isso em linha de comando, lembrando que para cada protocolo temos uma forma de configurar, porém sempre quando vamos trabalhar com BFD a configuração na interface física sempre será da mesma forma:

!
interface gig 0/1
bfd interval milliseconds min_rx milliseconds multiplier interval-multiplier
!
bfd interval = seria com que frequencia eu envio hello

min_rx = com que frequência você espera receber o hello ( se você não receber dentro desse periodo será considerado como down )

multiplier = quantas vezes eu posso perder essa notificação

Com isso agora podemos trabalhar dentro dos protocolos para obter a performance de comutação mais rapida. No OSPF podemos aplicar dessa forma:

!
router ospf 1
bfd all-interface
!
Se quiser pode habilitar por interface que esteja participando do roteamento.
!
interface gig0/1
ip ospf bfd
!

Segue abaixo menções para o BGP:

!
router bgp 65400
neighbor 192.168.1.1 remote-as 65400
neighbor 192.168.1.1 fall-over bfd
!

Como não poderia faltar, segue sobre nosso EIGRP:

!
router eigrp 1
bfd all-interface
!
Se quiser pode habilitar por interface que esteja participando do roteamento, mas agora dentro do processo.
!
router eigrp 1
bfd interface gig0/1
!

Com isso conseguimos abordar os principais procolos, bem como vocês já podem analisar ambiente e validar se é interessante aplicar na sua topologia, fazendo com que você tenha uma convergência melhor do que qualquer outro ” fine tunning ” implementando dentro de seu protocolo de roteamento. 😉

Espero que vocês tenham gostado e deixem seus comentários abaixo.

Abs,
Rodrigo

Fonte: http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/fs_bfd.html

5 Anos como Instrutor

Wed, 18 Sep 2013 00:00:00 +0000

Olá Pessoal,

Gostaria de compartilhar com todos um reconhecimento que a Cisco esta distribuindo esse ano para todos os instrutores que estão completando alguns anos de dedicação a essa função, que é muito reconhecedora pelo fato de ensinar ao próximo aquilo que você tem de mais valioso ” conhecimento “.

Não posso negar que nesses 5 Anos como Instrutor ensinei muitos alunos e juntos conseguimos que cada um com dedicação e esforço alcançasse a certificação. Eu gosto de lembrar que também aprendi muito muito com meus alunos, trazendo informações e ideias novas a cada dia.

Parabéns a todos os instrutores e alunos.

Atenciosamente,
Rodrigo

Novidades no BLOG!!!

Fri, 30 Nov 2012 00:00:00 +0000

Olá Pessoal,

Enfim gostaria de anunciar mais uma ferramenta que temos disponibilizado em nosso site. Eu já estava tentando habilitar esse Fórum à algum tempo atrás, entretanto eu havia montado todo o site, mas no final não funcionou a integração da base dados entre as duas ferramentas. Devido a este fato tive que montar um novo Fórum para conseguir integrar as duas base de dados ( BLOG e Fórum ).

Em nosso Fórum temos diversos tópicos que poderão ser colocados as perguntas / discussões na qual iremos conversar sobre os problemas do nosso dia a dia e também dúvidas que podemos tirar com todos os participantes. O Fórum é uma ferramenta que agrega muitos valores, conhecimentos, dicas e sempre temos diversos assuntos sendo abordados para qual não conseguimos demonstrar diariamente em nosso BLOG.

Como nós já tínhamos usuários cadastrados em nosso BLOG, vocês precisam seguir algumas dicas para que a user/senha cadastrada no BLOG seja populada na base de dados do Fórum, fazendo desta forma um login único para ambas as plataformas. No primeiro passo você deve selecionar ” I forgot my password “

Você será direcionado para a página do Fórum conforme abaixo:

Nesses campos você deve preencher com suas informações cadastradas em nosso BLOG, lembrando-se que o user / e-mail tem que ser idêntico ao cadastrado no BLOG, pois você irá receber um e-mail automático do Fórum com uma nova senha para você registrar e autenticar-se. Com isso você irá ter permissão com o mesmo user, porém agora com as senhas sincronizadas. Você poderá alterar sua senha após esse processo para sua senha que melhor desejar. Depois de logado você pode ir ao Painel de Controle do Usuário -> Perfil – Informações de Registro.

Nosso Fórum pode ser acessado através do nosso Menu Superior ou através do link direto.

Espero que vocês participem e contribuam para nosso Fórum, pois ele foi feito pensando em vocês para ajudar cada vez mais nossos participantes e integrantes desse BLOG que cresce os acessos a cada dia. Tenho muito a agradecer vocês que participam e divulgam nosso trabalho.

Abs,
Rodrigo

Protocolo OSPF – parte 8

Fri, 27 Jul 2012 00:00:00 +0000

Olá Pessoal,

Conforme mencionado em nosso último post vamos finalizar nossa série de OSPF, mencionando rapidamente sobre os cálculos que são executados para trazer esses valores para a tabela de roteamento.

No post número 2, mencionamos sobre a formula que é utilizada para trazer o valor calculado. Consulte.

Baseado nesse principio iremos ter as diferenças de custo quando as redes são redistribuidas através de outro protocolo ( EIGRP, RIP e etc ) e as diferentes interfaces que estão sendo utilizadas para a troca de informações dentro do protocolo de roteamento. Segue abaixo um pequeno resumo dos valores de custo de cada interface.

Essa tabela tem os cálculos executados através da formula mostrada anteriormente em nosso capítulo 2. Todos esses valores podem ser obtidos através da mesma formula, entretanto alguns padrões já são reconhecidos e lembrados pois são utilizados em nosso dia a dia.

Como todos os recursos são alterados, temos duas formas de executar essa alteração de custo nas interfaces para que o valor seja influenciado e de uma forma tenha alteração na tabela de roteamento de seus vizinhos.

ip ospf cost [ interface-cos ] = Esse comando é o mais tradicional e mais utilizado, pois traz uma resposta mais real da situação. Esse recurso é aplicado dentro da interface e tem-se um range de 1 até 65535.

CiscoRedes>enable
CiscoRedes#conf t
CiscoRedes(conf-t)#interface fast1/0
CiscoRedes(conf-if)#ip ospf cost 10

bandwidth [ valor de banda ] = Esse comando irá alterar o valor que o protocolo utiliza de referência para utilizar no protocolo de roteamento, entretanto esse comando não é o mais recomendado, pois você pode alterar outras funcionalidades para qual é utilizado esse valor, como a falsa impressão da leitura de um MRTG, que irá trazer gráficos de utilização do circuito.

CiscoRedes>enable
CiscoRedes#conf t
CiscoRedes(conf-t)#interface fast1/0
CiscoRedes(conf-if)#bandwidth 1000

Para efetuar a validação dos custos que cada interface possui, iremos validar especificamente através da interface física.

Serial

CiscoRedes#show ip ospf interface s0

Serial0 is up, line protocol is up
Internet Address 128.213.10.2 255.255.255.0, Area 0
Process ID 10, Router ID 128.213.10.2, Network Type
POINT_TO_MULTIPOINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT,
Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
Hello due in 0:00:14
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 200.200.10.1

Ethernet

CiscoRedes#show ip ospf interface e0
Ethernet0 is up, line protocol is up
Internet Address 203.250.14.3 255.255.255.0, Area 0.0.0.0
Process ID 10, Router ID 203.250.12.1, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State DROTHER, Priority 1
Designated Router (ID) 203.250.15.1, Interface address 203.250.14.2
Backup Designated router (ID) 203.250.13.41, Interface address
203.250.14.1
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 0:00:03
Neighbor Count is 3, Adjacent neighbor count is 2
Adjacent with neighbor 203.250.15.1 (Designated Router)
Adjacent with neighbor 203.250.13.41 (Backup Designated Router)

Com isso chegamos ao fim de nossa serie sobre OSPF 😀 . Logicamente, temos outros conceitos que não foram abordados nesse pequeno tutorial, entretanto são tópicos interessantes que devem ajudar nossos leitores a descobrir e identificar os problemas nas redes que utilizam-se desse protocolo.

Espero que vocês tenham gostado 😉 e que esse ” tutorialzinho ” possa ter ajudado a interpretar um pouco sobre esse protocolo.

Abs,
Rodrigo

Protocolo OSPF – parte 7

Thu, 19 Jul 2012 00:00:00 +0000

Olá Caros,

Conforme nossa menção no post anterior, vamos hoje falar sobre a sumarização de rotas no OSPF.

Sumarização de rotas consiste na consolidação de múltiplas rotas em um único anúncio. Em uma rede OSPF, esta tarefa normalmente é realizada por um router de borda ( ABR ). Ainda que a sumarização possa ser configurada entre quaisquer duas áreas, a boa prática rege que a sumarização deve ocorrer preferencialmente no sentido do backbone ( Area 0 ). Desta forma, o backbone recebe todas as rotas agregadas e, por sua vez, pode anuncia-las sumarizadas para outras áreas.

Em uma rede OSPF, existem basicamente 2 tipos de sumarização:

Inter-area route summarization = Executado no ABR, cria os LSAs Tipo 3 e 4 e adverte os router IDs do ASBR, ou seja, a sumarização é aplicada as rotas internas do AS, na qual as rotas externas aprendidas via redistribuição não serão consideradas. Segue um exemplo onde teremos essa comunicação:

Para efetuar a configuração no roteador devemos sempre validar se as redes são contíguas e que o range escolhido para efetuar essa sumarização esteja dentro do escopo de suas redes, pois você pode efetuar loop na rede ou efetuar alguma assimetria dependendo de seu design. Segue o comando para efetuar a sumarização:

R2(config)#router ospf 100

R2(config-router)#area 1 range 192.168.10.0 255.255.254.0

Depois dessa configuração o roteador irá criar uma rota apontando para a Null0.

External route summarization= É totalmente específico para as rotas externas, inseridas na rede OSPF via redistribuição, ou seja, essas redes são redistribuídas através do ASBR, para qual irá fazer a troca de um protocolo não OSPF. Gostaria de reforçar que a sumarização deve ser contígua para que não tenhamos problemas de redes sobrepostas. Segue abaixo um exemplo:

Neste caso iremos ter o roteador R3 redistribuindo as redes RIP para a área OSPF, portanto neste roteador podemos fazer uma sumarização de todas as redes que será inserida dentro do OSPF, facilitando dessa forma a tabela de roteamento que iremos ter na tabela de roteamento. Para isso podemos executar dessa forma a sumarização:

R3(config)#router ospf 100

R3(config-router)#summary-address 60.60.60.0 255.255.255.0

Depois dessa configuração o roteador irá criar uma rota apontando para a Null0.

Dessa forma concluímos o processo de sumarização que pode ser executado no protocolo OSPF. Espero que tenham gostado e iremos ter nosso último post de OSPF mencionando sobre métricas ( cálculos ).

Aguardo comentários!!!

Abs,

Rodrigo

Protocolo OSPF – parte 6

Fri, 08 Jun 2012 00:00:00 +0000

Olá Pessoal,

Conforme mencionado anteriormente vamos prosseguir com nosso tutorial sobre OSPF. No último post havíamos falado sobre LSA e nesse post vamos tratar sobre os processos que acontecem quando temos eleição de DR e BDR em topologias de multiacesso.

Basicamente, routers que compartilham um mesmo segmento tornam-se neighbors neste segmento. O estabelecimento de uma relação de vizinhança ocorre por meio da mensagem “ Hello ”. Os roteadores tornam-se vizinhos assim que conseguem ver eles mesmos listados como vizinho no pacote Hello do router vizinho. Desta forma, uma comunicação de 2 vias é garantida. É importante ressaltar que a negociação de vizinhança utiliza apenas o endereço IP primário da interface, ou seja, se a mesma estiver configurada com endereços secundários, estes não serão utilizados no processo. Outro detalhe é que, se endereços secundários forem configurados, estes devem pertencer à mesma área OSPF do endereço primário.

Para a configuração de endereço secundário na interface devemos seguir esse processo:

ip address 10.1.7.252 255.255.255.0 secondary
ip address 10.1.2.252 255.255.255.0

Os roteadores para formar a adjacência entre si, exige que alguns parâmetros sejam validados:

Area-ID: Para 2 routers que possuem interfaces em um mesmo segmento, estas interfaces devem pertencer à mesma área OSPF, pertencer à mesma subrede e possuir a mesma máscara de rede.
Autenticação: Se autenticação estiver sendo utilizada, routers vizinhos devem trocar a mesma senha em um dado segmento.
Hello e “ Dead Intervals ”: Routers OSPF trocam mensagens Hello em cada segmento. O Keepalive HELLO configurado deve ser consistente em um mesmo segmento. O “ Dead Interval ” seria o intervalo de tempo entre o último pacote HELLO recebido e o router considerar o neighbor como “ down ”. Este intervalo também deve ser o mesmo em um mesmo segmento OSPF. Os comandos para configuração destes intervalos nas interfaces são: “ ip ospf hello-interval seconds ” e “ ip ospf dead-interval seconds ”
**“ Stub Area Flag ”:**Dois routers devem também possuir o mesmo valor no campo “ Stub Area Flag ”, no pacote Hello, para formarem uma relação de vizinhança.
MTU Size: Finalmente, temos o MTU Size das interfaces. Se estes valores forem diferentes em cada ponta, a adjacência não será formada. Se por algum motivo existir a necessidade de estabelecer a adjacência mantendo-se MTUs distintas em cada ponta, o comando “ ip ospf mtu-ignore ” configurado em cada interface envolvida no processo resolve o problema.

A adjacência é o processo de formação que ocorre imediatamente após a definição das relações de vizinhança. Roteadores adjacentes são aqueles que foram além da simples troca de pacotes HELLO, e iniciaram o processo de sincronismo da base de dados. Com o objetivo de reduzir a quantidade de informação trocada em um dado segmento, OSPF elege um router para ser o router designado ( Designated Router – DR ), e outro para assumir o papel de backup dele ( Backup Designated Router – BDR ), em cada segmento multi-acesso ( como segmentos Ethernet, por exemplo ). A idéia por trás deste princípio é criar um ponto central na rede multi-acesso para troca de informações.

As atualizações entre o DR e BDR são divulgadas através de um endereço multicast diferente do endereço que é utilizado para divulgação do tabela de roteamento ( LSDB ). O endereço multicast utilizado nesse segmento é 224.0.0.5. A definição de obter DR e BDR seria a redução de informações trocadas, pois utilizamos um cálculo básico para verificar no caso a crescente de adjancências entre os equipamentos.

n ( n-1 ) / 2

n = quantidade de roteadores no mesmo segmento

Veja pela figura como seria a adjacência:

A eleição do router DR é feita pelo pacote HELLO. Pacotes HELLO são trocados entre os routers via multicast, em cada segmento. O router que tiver o maior OID (OSPF ID) em um segmento é eleito o DR para aquele segmento. O mesmo processo é realizado para a eleição do BDR. Em caso de empate, o router com maior RID (Router ID) vence a disputa. A prioridade default para uma interface OSPF é 1. Este valor pode ser alterado pelo comando: “ ip ospf priority “. Uma prioridade “ 0 ″ significa que a interface em questão não será considerada no processo de eleição do DR / BDR.

Quando não temos a configuração de nenhuma loopback nos roteadores a eleição de DR e BDR é feita através dos endereços IPs configurados nas interfaces físicas, não esquecendo que teremos que considerar os endereços mesmo não pertencendo aquele mesmo segmento que está ocorrendo a validação.

Como mencionado sobre a adjacência temos alguns passos que são executados para a validação desse neighbor. Segue abaixo os 7 passos:

De que forma você pode avaliar a adjacência de seus vizinhos bem como o status de DR e BDR, seria através do comando ” show ip ospf neighbor “

Router2# show ip ospf neighbor 

Neighbor ID     Pri    State      Dead Time    Address     Interface
192.168.45.1    1      FULL/DR    00:00:36     10.0.0.1    Ethernet0

Com isso podemos mencionar que o OSPF em links ponto a ponto sempre irá formar adjacências entre eles, entretanto sem a necessidade de eleger um DR e BDR. Um cuidado especial é necessário quando configuramos OSPF em redes NBMA, como Frame Relay, X.25 ou ATM. Por default, OSPF considera estes redes como Broadcast (assim como uma rede Ethernet ). No entanto, redes NBMA geralmente são arquitetadas sob uma topologia “ hub & spoke ”, e não provê o tipo de acesso full mesh que OSPF acredita existir. Neste caso, a seleção do DR e BDR torna-se um problema, já que o DR e o BDR precisam ter uma conexão física entre eles. Além disso, devido à limitação de broadcast existente em redes deste tipo, o DR e o BDR precisam possuir uma lista estática de todos os roteadores pertencentes à rede frame relay.

Alguns pontos podem ser utilizados para evitar a eleição de DR e BDR em acesso NBMA, como a criação de sub-interfaces point-to-point e a configuração do tipo de interface dentro da configuração de interface ( broadcast | non-broadcast | point-to-multipoint ).

Espero que aproveitem as informações e fica a dica para nosso próximo post que seria voltado para a sumarização do OSPF, enfim o último post falando sobre os cálculos que OSPF utiliza para obter o custo e popular esses valores na tabela de roteamento.

Espero comentários.

Abs,
Rodrigo

DHCP Snooping

Sat, 05 May 2012 00:00:00 +0000

Olá caros,

Um servidor DHCP é necessário quando temos várias maquinas e outros equipamentos IP na rede, no qual o serviço DHCP disponibiliza dinamicamente IP/máscara de rede, default gateway, servidor DNS, entre outras informações para o solicitante, com isso facilitando o trabalho do administrador de rede.

Vamos imaginar o cenário onde um usuário malicioso adiciona um computador na rede com o serviço DHCP Server habilitado. Quando uma máquina qualquer precisar de IP ou expirar o lease time, ela vai enviar pacotes DHCP Request em broadcast, no qual esse “ novo ” Servidor DHCP envia o DHCP Reply com seu próprio IP como default-gateway. Quando a máquina “ enganada ” enviar um pacote para fora da rede, o pacote vai passar pelo falso default-gateway, o PC do atacante, e depois enviado para o destino correto. Será questão de tempo para o ” lease time ” dos outros PCs expirarem e o trafego da sua rede ser inteiramente interceptado. Esse é um ataque muito perigoso do tipo “ man-in-the-middle “, pois com um sniffer o atacante consegue coletar vários dados dos usuários inclusive conversas e senhas.

Para evitar este tipo de ataque, devemos primeiro mapear as portas dos switches que não estão sendo utilizadas, e adicioná-las em uma VLAN separada da rede em produção, ou mantê-las em “ shutdown ‘. Porém o atacante ainda pode utilizar o ponto de rede de uma máquina na VLAN correta. Nos switches Cisco ( 2960, 3560, 3750, 4000, 6000 ) temos um recurso chamado DHCP Snooping, que classifica cada porta como trusted ou untrusted ( confiável ou não confiável ). Os servidores DHCP ficam nas portas trusted, e o restante das portas como untrusted, e o switch intercepta todas as requisições DHCP nas portas untrusted antes de encaminhá-las, caso ele receba um DHCP Reply de uma porta não confiável, esse pacote será descartado.

O serviço DHCP é descrito através da RFC 2131 e um dos principais pontos nesse momento para entender seria visualizar as mensagens que são trocadas quando um cliente solicita endereço para o servidor. Segue abaixo as mensagens trocadas:

O DHCP snooping possui uma base de dados com endereço IP, endereço MAC, lease time, etc. Essa base é utilizada em outras features como DAI (Dynamic ARP Inspection) e o IP Source Guard que serão abortados nos próximos posts do Multihop.

Para habilitar o DHCP Snooping digite o seguinte comando no modo de configuração global:

Switchconfig)#ip dhcp snooping

Agora identifique as VLANs que serão protegidas:

Switch(config)#ip dhcp snooping vlan 100\ Switch(config)#ip dhcp snooping vlan 200

Todas as portas do switch ficam no modo untrusted por padrão quando habilitamos o DHCP snooping. Agora vamos configurar as portas onde estão os servidores DHCP da rede como trusted:

Switch#conf t\ Switch(config)#interface FastEthernet 0/0\ Switch(config-if)#ip dhcp snooping trust

Podemos também configurar um limite de requisições DHCP que passam em uma interface, o rate pode ser um valor de 1 a 2048 pacotes por segundo:

Switch(config)#interface FastEthernet 2/1\ Switch(config-if)#ip dhcp snooping limit rate 10

Por padrão é habilitado a opção 82 DHCP, que é descrita na RFC 3046 publicada em janeiro de 2001 ( http://www.rfc-archive.org/getrfc.php?rfc=3046 ). Quando uma requisição DHCP é interceptada em uma porta untrusted, o switch adiciona seu próprio MAC e um identificador da porta de origem no campo option-82, em seguida encaminha para o servidor DHCP. Quando retorna o pacote reply o switch compara o campo option-82 para confirmar que a requisição foi originada de uma porta válida:

Switch(config)#ip dhcp snooping information option

Para verificar as configurações do DHCP Snooping, utilize o comando “show ip dhcp snooping”. Somente portas que estão como trusted ou com rate-limit serão listadas:

Switch # show ip dhcp snooping\ DHCP Snooping is configured on the following VLANs:\ 20 30-40 100 200\ Insertion of option 82 information is enabled.\ Interface Trusted Rate limit (pps)\ --------- ------- ----------------\ FastEthernet2/1 yes 10\ FastEthernet2/2 yes none\ FastEthernet3/1 no 20\ Switch #

Com o comando “show ip dhcp snooping binding” conseguimos visualizar as entradas que correspondem as portas untrusted como MAC, lease time, VLAN, etc:

Switch # show ip dhcp snooping binding\ MacAddress IP Address Lease (seconds) Type VLAN Interface\ ----------- ----------- -------------- ----- ---- ----------\ 0010.01FF.0201 192.168.2.3 1600 dynamic 100 FastEthernet2/1\ 0010.01FA.1B31 192.168.2.4 1600 dynamic 100 FastEthernet2/2\ Switch #

Espero que essas informações possa ajudar em alguma implementação de segurança. 😀

Aguardo comentários.

Fonte:
http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.1/13ew/configuration/guide/dhcp.html

Protocolo OSPF – parte 5

Sun, 29 Apr 2012 00:00:00 +0000

Olá pessoal,

Como mencionado anteriormente, vamos continuar com a nossa sequencia de post relacionado a OSPF. Nesse post iremos tratar sobre os tipos de LSAs existentes dentro do protocolo OPSF.

Devido ao fato de existir nomenclaturas e funcionalidades diferenciadas entre o ABR e ASBR os LSAs tem um papel importante dentro do entendimento de como as rotas são distribuídas dentro do protocolo OSPF, bem como a menção sobre os diversos tipos de áreas existentes dentro do OSPF.

O LSA ( Link State Advertisement ) são pacotes que são distribuídos dentro das áreas OSPF com a funcionalidade de informar seus vizinhos sobre as redes e ao mesmo tempo fazer validações sobre o estado de cada rede ( alcançável e não alcançável ), ou seja, quando uma rede torna-se indisponível esses pacotes LSAs são inundados para que todos os roteadores tenham conhecimento sobre essa alteração de topologia.

Baseado nisto vamos mencionar os tipos de LSAs existentes dentro do protocolo OPSF:

Tipo de LSAs


LSA Type	Nome Comum	Descrição
1	Router	Um por router, listando RID e todas interfaces com endereço IP.
2	Network	Um por rota de rede. Criado pelo DR em uma subrede, e representa a sub-rede e interfaces conectadas ao roteador para a sub-rede configurada.
3	Sumarização Network	Criado pelo ABR para representar uma área do LSA tipo 1 e 2 quando sendo advertida dentro de outra área. Define os links ( sub-redes ) na área de origem e custos, mas não os dados de topologia.
4	Sumarização ASBR	Como o LSA tipo 3, exceto que anuncia uma rota usada para alcançar um ASBR.
5	AS Externo	Criado pelo ASBR para rotas externas injetadas dentro do OSPF.
6	Membros de grupo	Não suportado pelo IOS Cisco.
7	NSSA Externo	Criado pelo ASBR dentro de uma rede NSSA, ao invés de um LSA tipo 5.
8	Atributos Externos	Não esta implementado em roteadores Cisco.

Gostaria de mencionar mais dois pontos relacionados as menções anteriores:

Transit Network: Uma rede sobre a qual dois ou mais roteadores OSPF tem tornando-se vizinhos, então o trafego pode rotear de uma para a outra.
Stub network: Uma sub-rede na qual um router não formou qualquer relação com o vizinho.

Com isso podemos trazer alguns exemplos de topologia para qual temos a troca de LSAs entre os roteadores participantes do protocolo de roteamento OSPF.

Neste exemplo podemos observar todos os tipos de área do OSPF, para qual temos específicos LSAs sendo divulgado ou transportado dentro das áreas. Devemos analisar a utilização do ABR, para qual vai transportar na maioria das vezes tipo 3 e tipo 5, e quando temos o ASBR iremos ter a inserção do tipo 7 dentro da área NSSA.

Para a representação de propagação de LSAs segue abaixo um exemplo:

Neste exemplo podemos observar o tráfego de tipo 2 e 1 dentro da área 3, para qual o ABR da área 3 com a de backbone ( área 0 ) está encaminhando tipo 3. O roteador ABR que esta fazendo a conexão com a área 4 esta divulgando rotas externas vindo da Internet ( tipo 4 e tipo 5 ), ou seja, estaria influenciado com as redes que são distribuídas como external 1 ou 2, e rotas vindo da area 3 como tipo 3 e bem como as redes vindo da área de backbone.

Com base nessas informações os comandos de visualização dentro dos roteadores podem agora ajudar a resolver alguns problemas dentro do nosso dia a dia.

Podemos observar mais alguns comandos para ajudar na validação e detecção dos problemas dentro do protocolo OSPF:

router#show ip ospf border-routers

router#show ip route

router#show ip ospf

router#show ip ospf interface [ id ]

router#show ip ospf neighbor

router#show ip ospf summary-address

Dentro do conceito de LSA posso mencionar que devemos entender essa troca de LSA entre as áreas e os tipos de áreas no protocolo OSPF, para que posteriormente no design de uma rede OSPF essas particularidades não sejam esquecidas ocasionando erros e problemas dentro do protocolo de roteamento.

Para o próximo post iremos tratar sobre as adjacências e vizinhos do OSPF com a menção de DR e BDR.

Espero que tenham gostado e aguardo comentários.

Abs,
Rodrigo

Protocolo OSPF – parte 4

Fri, 13 Apr 2012 00:00:00 +0000

Olá Pessoal,

Conforme notificado nesse post iremos tratar um pouco sobre áreas dentro da arquitetura OSPF. Confira os posts anteriores para obter informações relevantes sobre o protocolo.

No OSPF sempre iremos escutar e trabalhar com a area 0, chamada de ” área de backbone “. Essa seria a área de transito entre as diferentes áreas que podemos criar dentro do protocolo OSPF. Quando estamos pensando em um projeto de redes utilizando o OSPF, sempre devemos iniciar do ponto central ( área 0 ) e expandir para as áreas subjacentes, fazendo assim uma rede escalável e organizada.

A área 0 deve ser o centro lógico da rede, ou seja, todas as outras áreas devem ter uma conexão física com o backbone. O motivo disso é que OSPF espera que todas as áreas encaminhem informações de tabela/sub-redes roteamento para o backbone, e este, por sua vez, se encarrega de disseminar estas informações para as outras áreas. Veja abaixo a demonstração dessa áreas.

Baseado nas informações acima podemos avaliar alguns conceitos sobre a distribuição dessas áreas e algumas nomenclaturas definidas como ABR e ASBR.

A definição para ABR e ASBR pode ser constituída como:

ABR = Area Border Router no qual é responsável por conectar duas ou mais áreas. Nesse tipo de equipamento nos temos os anúncios das redes ou database de topologia sendo anunciado através do LSA tipo 3.
ASBR = Autonomous System Border Router que conecta outros protocolos de roteamento ( redistribuição ) para dentro do protocolo OSPF. Normalmente isso é executado utilizando a area 0.

Outro detalhe que podemos avaliar seria observando os diferentes tipos de informações que são trafegadas. Informações sobre rotas que são geradas e utilizadas dentro de uma mesma área são chamadas de “ intra-area routes ”, e são precedidas pela letra “ O ” na tabela de roteamento. Rotas que são originadas em outras áreas são chamadas de “ inter-area routes ”, ou “ summary-routes ”. Estas são precedidas por “ O IA ”, na tabela de roteamento. Rotas originadas por outros protocolos de roteamento e redistribuídas em uma rede OSPF são conhecidas por “ external-routes ”. Estas são precedidas pelas letras “ O E1 ″ ou “ O E2 ″, na tabela de roteamento. Quando temos múltiplas rotas para um mesmo destino, o critério de desempate em uma rede OSPF obedece a seguinte ordem: intra-area, inter-area, external E1, external E2.

Quando mencionado sobre a redistribuição dos protocolos IGP ou EGP para o protocolo OSPF temos as diferenças sobre a nomenclatura ( E1 e E2 ), para qual podemos definir dessa forma:

E1 = As métricas definidas pelos protocolos anteriores a essa redistribuição ( ASBR ) serão incluídos para alcançar o próximo salto fora de seu AS.
E2 ( padrão ) = Os custos externos não são repassados para o protocolo interno que está rodando dentro do área interna.

Vocês lembram quando foi comentado que todas as áreas OSPF deveriam conectar passando pela área de backbone? Pois é, isso não é regra.

Como toda regra tem uma exceção e deveríamos ter nesse caso, pois não poderíamos ficar obrigatoriamente ” amarrados ” na condição de que qualquer área nova criada eu deveria ter uma conexão com nossa área de backbone, devido a algumas condições externas ( links, disponibilidade de viabilidade para chegar em seu ponto central, etc ) essa facilidade dentro do OSPF seria restrita. Para resolver esse problema existe as conexões através de link virtuais ” Virtual-link “.

O link virtual OSPF é como uma “ VPN ” que integra uma área que não tem como se conectar diretamente ao backbone, através de uma área diretamente conectada a ele. É importante ressaltar que o artifício de “ virtual links ” é paliativo, ou seja, ele resolve um erro de design, e deve ser encarado como uma solução temporária.

No exemplo acima podemos resolver da seguinte forma:

RouterA(config)# interface loopback 0
RouterA(config-if)# ip address 10.10.10.33 255.255.255.255
RouterA(config)# router ospf 100
RouterA(config-router)# network 172.16.20.128 0.0.0.7 area 0
RouterA(config-router)# network 10.10.10.33 0.0.0.0 area 0
RouterA(config-router)# area 0 range 172.16.20.128 255.255.255.192
RouterA(config-router)# area 1 virtual-link 10.10.10.30

RouterM(config)# loopback interface 0
RouterM(config-if)# ip address 10.10.10.30 255.255.255.255
RouterM(config)# router ospf 100
RouterM(config-router)# network 172.16.20.32 0.0.0.7 area 5
RouterM(config-router)# network 10.10.10.30 0.0.0.0 area 0
RouterM(config-router)# area 1 virtual-link 10.10.10.33

Na próxima parte iremos falar sobre os tipos de LSA ( link state advertisement ) que estão disponíveis no protocolo OSPF.

Espero que tenham gostado e aguardo comentários.

Abs,
Rodrigo

QoS Video – Networking 101

Sun, 08 Apr 2012 00:00:00 +0000

Olá caros,

Após nossos posts sobre QoS, gostaria de trazer mais um vídeo na qual adiciona mais alguns conceitos voltados para essa tecnologia. Esse vídeo é apresentado pelo famoso e engraçado Jimmy Ray, para qual explica um pouco sobre o QoS em Layer 2 e Layer 3.

Confira abaixo:

http://www.youtube.com/watch?v=LtNVmvv9ZUw&feature=player_embedded

Abs,
Rodrigo

Protocolo OSPF – parte 3

Tue, 03 Apr 2012 00:00:00 +0000

Olá Pessoal,

Vamos continuar com nosso tutorial sobre OSPF. O post anterior pode ser consultado aqui.

Neste episódio iremos comentar sobre a configuração que podemos executar dentro do protocolo OSPF. Como todo protocolo de roteamento IGP ( RIP, EIGRP, OSPF ) que é habilitado em equipamentos Cisco temos 2 passos essenciais para configurar esse serviço:

Habilitar o serviço através do comando router ospf [ id process ]
Divulgar as redes que seus vizinhos OSPF devem aprender associando-se as interfaces com a área desejada network [ IP ] [ MÁSCARA ] [ area ]

Quando definimos o [ id process ] estamos relacionando apenas com o processo local do roteador que você esta trabalhando, e o mesmo não tem nenhuma relação com os roteadores vizinhos que irão fazer a adjacência com ele. Vários processos OSPF podem ser executados em um mesmo router, mas este procedimento não é recomendado, entretanto, já que cada instância consome grandes porções de CPU e memória. Em suma, um bom design não utilizaria mais de um processo OSPF em um mesmo router.

Para comando [ network ] diferentemente do que ocorre na configuração de outros protocolos de roteamento, serve, no OSPF, para indicar quais interfaces participarão do processo, e quais as áreas OSPF a que pertencem. Esta é uma particularidade do protocolo.

O ID da área é definido por um número inteiro compreendido entre 0 e 4294967295, e também pode assumir a forma de um endereço IP (ex: área 0 = 0.0.0.0).

O campo referente a [ máscara ] é mencionada como uma ” máscara coringa “, que na verdade é a máscara padrão escrita de uma forma invertida. Nesse caso, como podemos calcular essa máscara?

A máscara coringa seria executada através de uma conta matemática simples que seria a subtração. Para esse cálculo sempre iremos subtrair utilizado a máscara como sendo um /32 ( 255.255.255.255 )

Padrão / 25 = 255.255.255.128
Subtração /32 = 255.255.255.255
Coringa /25 = 0 . 0 . 0 . 127

No protocolo de roteamento OSPF podemos trabalhar com dois tipos de autenticação, para qual tem a função de criar uma segurança maior para o tráfego das tabelas de roteamentos entre seus vizinhos OSPF.

**– Autenticação Simples:**Este método permite que chaves sejam configuradas por área OSPF. Routers em uma mesma área que desejem participar do processo de roteamento devem ser configurados com a mesma chave. A desvantagem deste método é que as chaves são trocadas pela rede, e podem ser facilmente interceptadas.

interface FastEthernet0/0
ip address 172.16.0.1 255.255.255.0
ip ospf authentication-key ciscoredes

router ospf 10
network 172.16.0.1 255.255.255.0 area 0
area 0 authentication

– Autenticação MD-5: Neste método, uma chave e uma senha são configurados em cada router. O router usa, então, um algoritmo baseado no próprio pacote OSPF, na chave e no ID da chave para gerar um “message digest”, que é inserido no pacote. Este método permite a troca de senha sem a interrupção da comunicação.

interface FastEthernet0/0
ip address 172.16.0.1 255.255.255.0
ip ospf message-digest-key 10 md5 ciscoredes

router ospf 10
network 172.16.0.1 255.255.255.0 area 0
area 0 authentication message-digest

Baseado nesses conceitos temos uma vídeo-aula, para qual traz um laboratório com os comandos de configurações e exemplos de como a rede se comporta utilizando-se o protocolo de roteamento OSPF.

Nessa vídeo aula temos informações que são mencionadas, para qual ainda não esta contemplado nessa parte, porém aguardem os próximos posts que iremos trazer as explicações.

Deixem seus comentários. 🙂 e iremos falar no próximo post sobre áreas.

Abs,
Rodrigo

Protocolo OSPF – parte 2

Mon, 12 Mar 2012 00:00:00 +0000

Olá caros,

Dando andamento ao nosso assunto sobre OSPF, hoje iremos comentar sobre o algoritmo utilizado e os processos que são executados para trazer a melhor métrica para a tabela de roteamento.

O post anterior pode ser consultado aqui.

– Algoritmo

Como mencionado anteriormente o nome dado para esse algoritmo é ” Dijkstra “, pelo qual o fundador ” Edsger Wybe Dijkstra ” foi o criador desse algoritmo. Ele foi fundado 1956, entretanto foi publicado apenas em 1959.

Abaixo podemos ter uma cronologia referenciando-se especificamente ao protocolo OSPF, ou seja, esse algoritmo utilizado para esse protocolo de roteamento ( OSPF ) foi desenvolvido a muito tempo atrás.

Segue abaixo uma demonstração simples sobre os cálculos exercidos nesse algoritmo.

O modo como o algoritmo opera é colocando o roteador na raiz da topologia, e então calcula o melhor caminho para um destino baseando-se no custo cumulativo até o destino em questão. Cada roteador na rede terá uma visão única da topologia lógica, ainda que todos os roteadores utilizem a mesma base de dados link-state (link-state database).

Uma analogia que podemos mencionar sobre esse protocolo seria: Alguém precisa se deslocar de uma cidade para outra. Para isso, ela dispõe de várias estradas, que passam por diversas cidades. Qual delas oferece uma trajetória de menor caminho?

Nós poderíamos colocar as contas e fórmulas executadas para esse cálculo matemático, porém acredito que não precisaríamos aprender as contas e sim o conceito desse protocolo. Para quem tiver interesse em descobrir os cálculo ou implementar em linguagem de programação esse método, pode consultar através desse link.

– Link State

Como mencionado anteriormente o OSPF utiliza-se de um protocolo chamado link-state. Devido a este fato ele toma algumas decisões sobre qual o melhor caminho a ser tomado. Abaixo menciono os passos de execução para a utilização desse protocolo.

Cada roteador obtém informações sobre seus próprios links e suas próprias redes diretamente conectadas. Isso é obtido pela detecção de uma interface no estado up (ativo).
Cada roteador é responsável por encontrar seus vizinhos em redes diretamente conectadas. Roteadores link-state fazem isso trocando pacotes Hello com outros roteadores link-state em redes diretamente conectadas.
Cada roteador cria um pacote link-state (LSP) que contém o estado de cada link diretamente conectado. Isso é feito com o registro de todas as informações pertinentes sobre cada vizinho, inclusive a ID do vizinho, o tipo de link e a largura de banda.
Cada roteador inunda o LSP para todos os vizinhos, que armazenam todos os LSPs recebidos em um banco de dados. Esses vizinhos, por sua vez, inundam os LSPs para todos os seus vizinhos até que todos os roteadores na área tenham recebido os LSPs. Cada roteador armazena uma cópia de cada LSP recebido de seus vizinhos em um banco de dados local.
Cada roteador usa o banco de dados para criar um mapa completo da topologia e computa o melhor caminho para cada rede de destino. Como se tivesse um mapa de estrada, o roteador tem agora um mapa completo de todos os destinos na topologia e as rotas para alcançá-los. O algoritmo SPF é usado para criar o mapa da topologia e determinar o melhor caminho para cada rede.

Baseado nesses conceitos ainda temos diversos termos dentro do OSPF que são utilizados e iremos tratar logo abaixo:

– Custo

O custo (também conhecido como métrica) de uma interface OSPF é uma indicação do overhead necessário para o envio de pacotes através desta interface. O custo de uma interface é inversamente proporcional a largura de banda desta interface. Uma largura de banda maior indica um custo menor.

Custo = 10^8/Banda (bps).

Por este motivo, é importante a correta configuração do parâmetro Bandwidth em interfaces rodando OSPF. Ela sempre irá pegar o valor configurado para efetuar o cálculo da métrica.

– Roteadores de Fronteira ( Área e Borda )

OSPF utiliza multicast para propagar os anúncios pela rede. O conceito de areas foi criado para criar fronteiras de propagação destes anúncios. A propagação de updates e o cálculo da topologia pelo algoritmo Dijkstra são restritos à área. Todos os roteadores em uma mesma área terão a mesma base de dados topológica. Roteadores que pertencem a mais de uma área terão as bases de dados de cada área a qual pertencem. Este é o caso dos roteadores de fronteira, como os ABRs (Area Border Routers) e os ASBRs (Autonomous System Border Routers). A figura abaixo ilustra a aplicação destes roteadores.

– Tipo de Pacotes Link State

Existem diferentes tipos de pacotes Link-State. Estes pacotes são ilustrados no diagrama abaixo.

Nesta figura temos vários conceitos para qual está envolvido todos os tipos de LSA dentro do protocolo OSPF, porém iremos tratar em outro post específico somente para este contexto. Lembrando-se que os conceitos de Multi-Area e tipos de LSA não são cobrados na certificação CCNA, por isso vou tratar diferenciado para focar em assuntos de CCNP.

No próximo post iremos discutir as configurações do OSPF e uma vídeo aula para adicionar maiores detalhes. Espero que gostem 🙂 .

Abs,
Rodrigo