O access-point Xirrus XR520H, bem como outros modelos (acho que todos) não possui porta dedicada para console, assim o único modo para acessar a interface de gerenciamento é através da rede (Web ou CLI). Com isso não temos um processo de “hard reset”, caso precisemos recuperar a senha para acesso administrativo. Mas ainda há esperança. É possível redefinir a senha do usuário admin (mesmo que ele não exista), via SNMP, desde que você saiba qual é a comunidade SNMP configurada no access-point. Configurações padrão de fábrica para o Xirrus XR520H: Login: admin Senha: admin Comunidade SNMP v2c (RW): xirrus Endereço IP da interface de rede: configurado para obter via servidor DHCP Redefinindo a senha do access-point Para fazer reset da senha do usuário admin precisamos de um Linux (neste exemplo estamos usando o Debian) com SNMP instalado (o pacote varia de acordo com a distribuição), e saber qual é a comunidade SNMP configurada no access-point. 1) Para instalar o pacote SNMP no Debian basta rodar o comando apt-get –y install snmp. 2) Com o pacote SNMP instalado, usamos o comando snmpset, sendo que: A senha será configurada como admin. Não há possibilidade escolhermos outra senha. Se existirem outros usuários configurados no AP, os mesmos serão removidos deixando somente o usuário admin. Parâmetros utilizados: -v2c: versão do SNMP configurada no equipamento AP Xirrus -c: especifica o nome da comunidade read-write (xirrus) 10.0.1.52: Endereço IP do AP 1.3.6.1.4.1.21013.1.2.4.2.0: oid que tem acesso as informações que vamos alterar. i 1: indica o tipo de valor passado pela oid, no caso dizendo ao AP Xirrus para redefinir o login default do equipamento para admin / admin. 3) Após executar reset da senha, podemos efetuar login no equipamento via interface Web. Usuário: admin Senha: admin 4) Na tela abaixo podemos verificar que o usuário admin foi criado/redefinido e que não existe nenhum outro usuário configurado. ATENÇÃO: APÓS ESTE PROCEDIMENTO É NECESSÁRIO SALVAR A CONFIGURAÇÃO VIA INTERFACE WEB, OU CLI. Obrigado Luciano Silagi pela colaboração. Até a próxima.
Recuperando access-point Xirrus
(Onde acha documentação?) Quando um access-point Xirrus perde o software, ele entra no modo XBL – Xirrus Boot Loader, que fornece uma interface mínima para recuperação do equipamento. É através do modo XBL que faremos o procedimento de recuperação de software do equipamento. Testei esse procedimento nos access-points das séries XR500 e XR2000, mas acredito que funcione para os demais modelos. Xirrus Software Recovery 1) Conecte o cabo de rede no computador e no access-point (com power injector) e então abra a console usando o XirCon, software que emula a console através da conexão de rede. No computador você precisará de um TFTP Server e do software do access-point. 2) Ligue o power injector. O access-point vai inicializar e você verá a mensagem abaixo. Xirrus Boot Loader 6.3.0-6166 (May 19 2014 – 11:01:18) Board | Xirrus CN5020-CP CPU BoardClocks | CPU : 300 MHz DDR : 666 MHz I2C Bus | 384 KHz, sampling at 11 MHzReset | Reset requestedWatchdog | Enabled (5 secs)System DDR | 512 MB, DDR2 Unbuffered non-ECCFLASH | 2 MB, CRC: OKRTC | Thu 2017-Apr-27 21:07:55 GMTCPU BIST | passPCI | PCI 32-bit, BAR 0: 0x08000000Radios | 0 1Network | eth0USB | 1 Storage Device foundEnvironment | Saving SCD settings to SCD Flash … done, Initialized In: ser_xcOut: ser_xcErr: ser_xc Press space bar to exit to bootloader: 1 Username: adminPassword: admin Quando aparecer a opção “Press space bar to exit to bootloader” pressione a barra de espaço e então informe o usuário e senha (admin/admin). 3) No XBL vamos configurar os parâmetros de rede para fazer a transferência do arquivo via TFTP. Neste exemplo 10.0.0.2 é o IP do computador com o TFTP Server. XBL>env set ipaddr 10.0.0.3XBL>env set netmask 255.255.255.0XBL>env set gatewayip 10.0.0.1XBL>env set serverip 10.0.0.2 4) Com a rede configurada, informe o nome do arquivo que será enviado (já selecionado no TFTP Server) e inicie a transferência. XBL>tftp XS-7.0.2-4948.bin[TFTP ] Device : eth0 – 1000 Mbps Full Duplex [TFTP ] Client : 10.0.0.3[TFTP ] Server : 10.0.0.2[TFTP ] File : XS-7.0.2-4948.bin[TFTP ] Address : 0x6000000[TFTP ] Loading : ################################################## [TFTP ] Loading : ################################################## [TFTP ] Loading : ################################################## [TFTP ] Loading : ################################################## [TFTP ] Loading : ################################################## [TFTP ] Loading : ### done [TFTP ] Complete: 18.2 sec, 4.1 MB/sec[TFTP ] Bytes : 77350634 (49c46ea hex), 4145 Kbytes/secXBL> 5) Para finalizar sete o commandset para full, informe o nome do arquivo que deverá ser usado e então use o comando bootm para instruir o access-point a inicializar por este software, e não pela flash. XBL>env set commandset fullXBL>env set bootfile_active XS-7.0.2-4948.binXBL>bootm[Boot ] Address : 0x06000000[Image ] Name : XR-7.0.2-4948[Image ] Created : 2014-07-04 8:40:07 UTC[Image ] Type : MIPS Linux Multi-File Image (uncompressed)[Image ] Size : 77350530 Bytes = 73.8 MB[Image ] Contents: File 0: 17248620 Bytes = 16.4 MB [Image ] Contents: File 1: 48472766 Bytes = 46.2 MB [Image ] Contents: File 2: 11629126 Bytes = 11.1 MB [Boot ] Image : Verifying image ……. OK[Boot ] Loading : Multi-File Image …. OK[Boot ] Watchdog: Disabling …. OK[Boot ] Execute : Transferring control to OS Initializing hardware ……….. OK Xirrus Wi-Fi ArrayArrayOS Version 7.0.2-4948Copyright (c) 2005-2014 Xirrus, Inc.http://www.xirrus.com Username: adminPassword: suasenha Observações: Se o access-point estiver com a configuração zerada, o usuário e senha serão admin/admin. Se ele já tiver configuração, o usuário e senha serão os definidos anteriormente na sua configuração. É recomendado não usar um software muito diferente do que estava em uso, caso contrário o access-point pode não conseguir carregar a imagem. Se o access-point voltar para o modo XBL, repita o procedimento. 6) Agora, com o access-point ligado e com o novo software carregado, precisamos fazer a segunda parte do procedimento. Observe que apesar de termos transferido o arquivo, ele não foi salvo na flash (carregou apenas na RAM), e por isso precisamos enviá-lo novamente. 6.1) Acesse o access-point pelo browser e vá em Tools > System Tools. 6.2) Selecione o arquivo (opção Software Upgrade). 6.3) Então clique Save e Reboot. Pronto. Só aguardar o AP reiniciar e utilizá-lo. Até a próxima.
Configurando MPLS L3VPN (OSPF + LDP + VRF + BGP)
(Acredite, é um resumo extremamente simplificado) MPLS L3VPN é para mim o tópico mais complicado do CCIE R&S. E olha que o conteúdo nem é tão aprofundado, já que MPLS é mais detalhada no CCIE SP. Mesmo assim, para a MPLS L3VPN funcionar precisamos “juntar” várias partes que individualmente já são complicadas (IGP, LDP, VRF, BGP,…). MPLS – Multi Protocol Label Switching, é um protocolo de tunelamento, multi-protocolo (suporta IP, IPv6, PPP,…) que permite o encaminhamento de pacotes com base em label layer 2. MPLS L3VPN é a junção da MPLS com o BGP, onde passamos a ter roteamento entre o roteador da “operadora” e do “cliente” (daí a parte L3 do nome) e a separação do tráfego do cliente em VRF (e por isso chamado de VPN). VRF – Virtual Routing and Forwarding, é uma forma de virtualização do roteador. Com VRFs passamos a ter tabelas de roteamento separadas, e por isso o tráfego de clientes diferentes não se misturam (e podem até ter o mesmo endereçamento). Em uma MPLS L3VPN temos os roteadores CE falando com os roteadores PE, que então traduzem as rotas para rotas VPNv4 e enviam para os outros PE via MP-BGP. E o tráfego entre os PE (no backbone) é encaminhado com base no labels MPLS. 1) Configuração inicial dos roteadores do Backbone. Vamos começar configurado os IPs e hostnames dos roteadores que serão nosso backbone MPLS. Este passo não é específico da configuração de MPLS L3VPN. Configuração em cada roteador do backbone: hostname R1-PE interface Loopback0 ip address 200.10.1.1 255.255.255.255 interface Ethernet0/0 ip address 205.5.12.1 255.255.255.0 interface Ethernet0/1 ip address 205.5.15.1 255.255.255.0 hostname R2-PE interface Loopback0 ip address 200.10.2.2 255.255.255.255 interface Ethernet0/0 ip address 205.5.12.2 255.255.255.0 interface Ethernet0/1 ip address 205.5.23.2 255.255.255.0 hostname R3-P interface Loopback0 ip address 200.10.3.3 255.255.255.255 interface Ethernet0/0 ip address 205.5.34.3 255.255.255.0 interface Ethernet0/1 ip address 205.5.23.3 255.255.255.0 hostname R4-PE interface Loopback0 ip address 200.10.4.4 255.255.255.255 interface Ethernet0/0 ip address 205.5.45.4 255.255.255.0 interface Ethernet0/1 ip address 205.5.34.4 255.255.255.0 hostname R5-P interface Loopback0 ip address 200.10.5.5 255.255.255.255 interface Ethernet0/0 ip address 205.5.45.5 255.255.255.0 interface Ethernet0/1 ip address 205.5.15.5 255.255.255.0 2) Configurando MPLS (OSPF + LDP) no Backbone. Para termos uma rede MPLS funcional, precisamos que os roteadores do backbone sejam capazes de fazer o roteamento entre eles. Neste exemplo vamos usar OSPF, habilitando o roteamento em todas as interfaces (ethernets e loopbacks) na área 0. O backbone é composto por roteadores P e PE, sendo que P (Provider Router) são os roteadores responsáveis por fazerem o encaminhamento com base nos labels MPLS. Provider Edge (PE) é o roteador do backbone mais próximo do cliente, tem MPLS habilitada, VRFs, e é responsável pela MP-BGP (VPN). Junto com o OSPF vamos configurar o LDP – Label Distribution Protocol, que será o responsável por gerar e distribuir labels entre os roteadores. Cada roteador gera labels para seus prefixos e então faz o anuncio para seus vizinhos (os labels tem significado local apenas). Felizmente, quando usamos OSPF e LDP podemos automatizar o processo, de maneira que cada rota/interface conhecida pelo roteador (prefixos que estão na RIB) receba um label. Configuração em todos os roteadores do backbone: router ospf 1 mpls ldp autoconfig network 200.10.0.0 0.0.255.255 area 0 network 205.5.0.0 0.0.255.255 area 0 Podemos verificar a configuração com os comandos normais de OSPF e também com comandos específicos de MPLS. R1#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 200.10.5.5 1 FULL/DR 00:00:31 205.5.15.5 Ethernet0/1 200.10.2.2 1 FULL/DR 00:00:39 205.5.12.2 Ethernet0/0 R1-PE#show ip route ospf Codes: L – local, C – connected, S – static, R – RIP, M – mobile, B – BGP D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2 E1 – OSPF external type 1, E2 – OSPF external type 2 i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2 ia – IS-IS inter area, * – candidate default, U – per-user static route o – ODR, P – periodic downloaded static route, H – NHRP, l – LISP a – application route + – replicated route, % – next hop override Gateway of last resort is not set 200.10.2.0/32 is subnetted, 1 subnets O 200.10.2.2 [110/11] via 205.5.12.2, 01:47:27, Ethernet0/0 200.10.3.0/32 is subnetted, 1 subnets O 200.10.3.3 [110/21] via 205.5.12.2, 01:47:27, Ethernet0/0 200.10.4.0/32 is subnetted, 1 subnets O 200.10.4.4 [110/21] via 205.5.15.5, 01:47:27, Ethernet0/1 200.10.5.0/32 is subnetted, 1 subnets O 200.10.5.5 [110/11] via 205.5.15.5, 01:47:27, Ethernet0/1 O 205.5.23.0/24 [110/20] via 205.5.12.2, 01:47:27, Ethernet0/0 O 205.5.34.0/24 [110/30] via 205.5.15.5, 01:47:27, Ethernet0/1 [110/30] via 205.5.12.2, 01:47:27, Ethernet0/0 O 205.5.45.0/24 [110/20] via 205.5.15.5, 01:47:27, Ethernet0/1 R1-PE# O LDP forma vizinhança, semelhante à protocolos de roteamento. R1-PE#show mpls ldp neighbor Peer LDP Ident: 200.10.2.2:0; Local LDP Ident 200.10.1.1:0 TCP connection: 200.10.2.2.42678 – 200.10.1.1.646 State: Oper; Msgs sent/rcvd: 203/203; Downstream Up time: 02:41:04 LDP discovery sources: Ethernet0/0, Src IP addr: 205.5.12.2 Addresses bound to peer LDP Ident: 205.5.12.2 205.5.23.2 200.10.2.2 Peer LDP Ident: 200.10.5.5:0; Local LDP Ident 200.10.1.1:0 TCP connection: 200.10.5.5.49563 – 200.10.1.1.646 State: Oper; Msgs sent/rcvd: 198/197; Downstream Up time: 02:34:48 LDP discovery sources: Ethernet0/1, Src IP addr: 205.5.15.5 Addresses bound to peer LDP Ident: 205.5.45.5 200.10.5.5 205.5.15.5 R1-PE# Verifique também se o roteador está alocando labels para os prefixos conhecidos. R1-PE#show mpls forwarding-table Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 16 Pop Label 200.10.2.2/32 0 Et0/0 205.5.12.2 17 17 200.10.3.3/32 0 Et0/0 205.5.12.2 18 19 200.10.4.4/32 0 Et0/1 205.5.15.5 19 Pop Label 200.10.5.5/32 0 Et0/1 205.5.15.5 20 Pop Label 205.5.23.0/24 0 Et0/0 205.5.12.2 22 22 205.5.34.0/24 0 Et0/0 205.5.12.2 24 205.5.34.0/24 0 Et0/1 205.5.15.5 23 Pop Label 205.5.45.0/24 0 Et0/1 205.5.15.5 R1-PE#show ip cef 200.10.4.4 200.10.4.4/32 nexthop 205.5.15.5 Ethernet0/1 label 19 R1-PE# Por fim,
Vulnerabilidade no Telnet afeta switches Cisco (e isso é o menos importante)
(Alguém ainda usa Telnet?) No último dia 7 o Wikileaks vazou mais de 8 mil páginas de documentos com inúmeros exploits zero-day, que possivelmente afetam IOS, Android, Windows e SmartTVs, além de outros sistemas e equipamentos de rede. Segundo o Wikileaks estas informações foram vazadas diretamente da CIA (e de agencias parceiras), que teoricamente utiliza esses exploits para acessar dispositivos de seus alvos. As empresas estão verificando se esses exploits são efetivos, e a Cisco já se manifestou confirmando uma vulnerabilidade zero-day (CVE-2017-3881) que afeta mais de 300 modelos de switches. A vulnerabilidade no CMP – Cluster Management Protocol, que é utilizado pelo Telnet, permite um usuário remoto reiniciar o equipamento e executar comandos com privilégio elevado (incluído ter acesso completo). No momento a única maneira de se proteger desta vulnerabilidade é desabilitar o Telnet. Verificando se o Telnet está habilitado Basta usar o comando show running-config para verificar se seu switch Cisco está com o Telnet habilitado. Podemos ainda usar o comando show running-config | include ^line vty|transport input para ir direto à parte que interessa. Equipamento não vulnerável (permite conexão apenas via SSH) BrainSW01#show running-config | include ^line vty|transport inputline vty 0 4 transport input sshline vty 5 15 transport input sshBrainSW01# Equipamento vulnerável (permite conexão via Telnet, config padrão) BrainSW01#show running-config | include ^line vty|transport inputline vty 0 4line vty 5 15 BrainSW01# Além dos exemplos acima, se no seu output tiver a opção “Telnet” ou “All” na linha transport, o seu equipamento está vulnerável. O comunicado oficial da Cisco, com a lista de equipamentos afetados pode ser visto aqui. Vault 7 Este vazamento foi batizado de Vault 7, e a primeira parte da operação chamada Year Zero, cujo foco é fazer o maior vazamento de todos os tempos de documentos confidenciais da CIA. Já com este primeiro vazamento dá para notar que entre outras coisas a CIA é uma fábrica de malware/vírus, capaz de ter acesso aos mais famosos sistemas operacionais. Segundo as informações disponibilizadas pelo Wikileaks o CCI – Center for Cyber Intelligence, conta com mais de 5000 usuários e seus hackers já codificaram mais linhas do que o necessário para manter o Facebook funcionando. Essas técnicas permitem a CIA ignorar a criptografia do WhatsApp, Signal, Telegram, Weibo, Confide e Cloackman, coletando tráfego de áudio e mensagens antes que a criptografia seja aplicada”, Wikileaks sobre técnicas para acessar dados em smartphones. Além dos APPs citados acima, e dos já mencionados sistemas operacionais, o Skype é outro software que pode ser hackeado. E não para por ai. A CIA ainda seria capaz de fazer com que SmartTVs se tornem “SpyTVs”. A CIA pode hackear as TVs inteligentes da Samsung e depois colocá-las no modo “falso desligado” para que um dono inocente acredite que sua TV está desligada – quando na verdade está ligada, gravando todos os sons na sala e transmitindo-os através da rede para um servidor secreto da CIA. Nos próximos dias devemos ter mais informações, com confirmações ou não das vulnerabilidades apresentadas. Até a próxima.
Show ip ospf database
(Complementando o último post) Agora que sabemos os tipos de LSAs e qual a função de cada um, vamos ver como identificá-los no output do comando show ip ospf database. Considerando a topologia acima, vamos dar o comando no roteador 5, e ver como as informações são mostradas. Nas primeiras 4 partes (em verde), temos as informações da área 0. Podemos ver os LSAs tipo 1, gerados pelos roteadores que estão na área 0, os LSAs tipo 2, gerados pelo DR (R4) e também os LSAs tipo 3, que são gerados pelos ABRs (R2 e R5 neste exemplo). Na área 0 ainda temos o LSA tipo 4, anunciado pelo ABR R2, informando como chegar ao ASBR R1. Na sequencia temos as informações da área 5 (em azul). Note que por esta área ser NSSA, não temos LSAs tipo 4 e tipo 5. Ao invés disso temos o LSA tipo 7, gerado pelo R6, e que é convertido para LSA tipo 5 pelo R5. Temos também variações deste comando, que mostram as informações detalhadas. show ip ospf database router: Mostra os detalhes dos LSAs tipo 1. show ip ospf database network: Informações dos LSAs tipo 2. show ip ospf database summary: Mostra as informações dos LSAs tipo 3. show ip ospf database asbr-summary: Mostra os LSAs tipo 4. show ip ospf database external: Mostra informações dos LSAs tipo 5. show ip ospf database nssa-external: Mostra informações dos LSAs tipo 7. Mais informações sobre os comandos acima e outros, neste link. Até a próxima.
Tipos de LSAs e áreas OSPF
(Deu trabalho!) O OSPF usa o algoritmo SPF – Shortest Path First, para encontrar o melhor caminho para cada nó (roteador) no gráfico (rede), e consequentemente o melhor caminho para cada rede. Diferente dos protocolos Distance Vector, cada nó (roteador) anuncia o estado de seus links, e após receber a informação de todos os links cada roteador cria a sua visão da topologia da rede (roteadores na mesma área, apesar de fazerem o cálculo de forma independente, tem a mesma visão da rede). Para divulgar o estado de seus links os roteadores usam LSAs – Link State Advertisement. E aqui a coisa começa a complicar, pois existem vários tipos de LSAs. Chamado Router LSA, o tipo 1 é gerado por todos os roteadores e é enviado para todos os roteadores na mesma área (não passa de uma área para outra). Neste LSA temos a lista de todos os links conectados no roteador. Se um roteador tem interfaces em mais de uma área, ele gera LSAs tipo 1 para cada área (bem como mantém LSDB – Link State Data Base, para cada área). Network LSA (tipo 2) é gerado apenas pelo DR – Designed Router. Ou seja, só existe em redes do tipo multi-access (broadcast ou não broadcast), onde temos a figura do DR. Lembre-se que o DR é um nó virtual (como o pseudonode no ISIS), e logicamente todos os roteadores estão conectados nele. No Network LSA temos todos os roteadores que estão conectados ao DR (conectados à rede multi-access), o próprio DR e prefixos e máscaras de rede. O LSA tipo 2 não passa de uma área para outra. Note que até o momento, considerando os LSAs 1 e 2, as redes que estão em áreas diferentes não se falariam. E é ai que entra o LSA tipo 3, o Summary LSA. Este LSA é gerado pelos ABRs – Area Border Router (R2 e R5 no nosso exemplo), representando os LSAs tipo 1 e 2, e é injetado na área vizinha. Quando olhamos a tabela de roteamento e vemos rotas com a indicação “O IA” (OSPF Inter Área), estas são as rotas de outras áreas aprendidas através dos LSAs tipo 3. Apesar do nome, o LSA tipo 3 não sumariza nenhuma rede quando estas são anunciadas entre áreas (há como fazer a sumarização de redes, justamente no ABR, mas este é outro assunto). O nome Summary LSA tem a ver com o fato do ABR esconder os detalhes da rota quando ela é anunciada para outra área. Por exemplo, o R2 executa o cálculo SPF para saber o custo para chegar à interface loopback do R1 (que também está na área 10). Então o R2 anuncia na área 0 “meu custo para loopback do R1 é X, quem quiser chegar à esta rede, fale comigo”. Os roteadores da área 0, sem conhecer a topologia da área 10, executam o SPF para achar o custo para chegar ao R2, e então somam este custo à X. Interessante notar que neste caso (roteamento entre áreas) o OSPF age como um protocolo Distance Vector. Além das rotas inter e entre áreas, podemos ter rotas externas. Na nossa topologia temos R6 redistribuindo EIGRP no OSPF, o que torna R6 um ASBR – Autonomous System Boundary Router. E neste caso passamos a ter os LSAs 4 e 5. O R6 muda seu LSA tipo 1, de maneira que o R5 passa a identificá-lo como um ASBR. Por conta disso o R5 (ABR) passa a gerar o LSA tipo 4, Summary ASBR LSA, divulgando para a área 0 (e desta para as demais áreas), como chegar ao ASBR. Além disso, o próprio R6 (ASBR) passa a enviar LSAs tipo 5, Autonomous system external LSA, informando que ele conhece redes/rotas “externas”. Notamos redes externas na tabela de roteamento através dos indicadores “O E1” e “O E2” (rotas OSPF externas, tipo 1 e tipo 2). Custo para rotas E1 e E2: Por padrão, quando fazemos redistribuição, as rotas são inseridas no domínio OSPF como rotas tipo E2. Rotas deste tipo tem custo fixo, anunciado pelo ASBR. Já o custo para rotas E1 é calculado com a soma do custo anunciado pelo ASBR mais a custo para chegar ao ASBR. Se o ASBR estiver em outra área, o custo para uma rota tipo E1 é a soma do custo para chegar ao ABR + custo para chegar ao ASBR + custo anunciado pelo ASBR. O LSA tipo 6, Multicast OSPF LSA, como o nome sugere, é utilizado pelo MOSPF – Multicast OSPF, extensão do OSPF pouco utilizada e não é suportada por roteadores Cisco. E então chegamos no LSA tipo 7, Not-so-stubby area LSA. Mas antes de falar dele precisamos falar dos tipos de áreas que temos no OSPF. Tipos de Área no OSPF Note que até agora o exemplo considerava o uso de áreas “normais” (aquelas que permitem LSAs 3, 4 e 5 fluírem entre elas), onde todos os roteadores tem visibilidade de todos os links/rotas do domínio OSPF. Porém este tipo de cenário impacta diretamente no processamento e tempo de convergência (LSDB fica maior, mudanças em uma área podem requerer o recálculo SPF em outras áreas,…), e por isso temos outras opções de áreas, que podem ser interessantes e muito recomendadas em alguns casos. Área Stubby: Configurada com o comando area “x” stub, este tipo de área não permite a entrada de LSAs tipo 4 e 5. Ou seja, um roteador em uma área Stubby não conhece redes fora do domínio OSPF (injetadas pelo ASBR). Para continuar com acesso à estas redes o ABR passa a injetar uma rota default na área Stubby ao invés de divulgar os LSAs 4 e 5. Área Totally Stubby: Além de não aceitar LSAs tipo 4 e 5, áreas Totally Stubby também não aceitam LSAs tipo 3. Configurada com o comando area “x” stub no-summary. O ABR divulga rota default para este tipo de área. Área NSSA: Temos a opção também de área No So Stubby Area (configurada com
