Link: Undocumented Cisco Commands

Não sei muito bem se uma lista de comandos não-documentados da Cisco pode ajudar em alguma coisa... No entanto, achei uma lista bastante completa e interessante (talvez um pouco desatualizada). Alguns comandos que figuram como não-documentado já possuem uma documentação e aparecem no prompt de ajuda interativa do IOS. Isso mostra também que alguns deles - tão utilizados hoje em dia - apareceram pela primeira vez um pouco, digamos, escondidos.

• Undocumented Cisco Commands

Entendendo NAT em Roteadores Cisco

Há alguns anos, com o esgotamento dos endereços IPv4 cada vez mais próximo, foi necessário encontrar uma alternativa para diminuir a velocidade de alocação de endereços IPv4 e aproveitar ainda melhor aqueles que já haviam sido alocados para os provedores de serviço (RFC-1631). Uma dessas alternativas foi a utilização de muitos endereços privados (conforme definido no RFC-1918) que posteriormente deveriam ser traduzidos para um (ou mais) endereço público para assim haver conectividade entre endereços públicos da Internet e endereços privados. Essa estratégia ficou conhecida como NAT (Network Address Translation).

A Cisco, por sua vez, possui uma terminologia e uma maneira particular de implementar os três principais tipos de NAT (estático, dinâmico e tradução de portas), no entanto, existem algumas informações importantes sobre roteamento e NAT Virtual Interfaces que devem ser entendidas também, e é isso que vamos tratar neste post. Para começar, é necessário entender a terminologia local e global, assim como inside e outside.

• Inside local address: é o endereço atribuído a interface de rede de uma estação, por exemplo (escopo local).
• Inside global address: é o endereço público que representa um ou mais endereços inside local (escopo global ou a Internet).
• Outside local address: é a forma como um endereço IP público é visto na rede interna. Geralmente este endereço é roteado somente pelos roteadores internos (não é roteado na Internet e, portanto, possui um escopo local).
  
• Outside global address: é um endereço público da Internet (é roteado na Internet).

É claro, também, que esta terminologia existe para nos auxiliar a entender onde estas definições e posteriores configurações serão utilizadas, já que os roteadores não possuem a inteligência necessária para distinguir um endereço público de um endereço privado (no final, serão somente zeros-e-uns). A figura abaixo (fornecida gentilmente pela Cisco) representa estas definições.


Essas definições serão importantes para escolher quais interfaces serão classificadas como inside e outside e como serão construídas as regras de tradução.

Seguindo o exemplo da figura abaixo, um host com endereço IP 192.168.0.1 (inside local) envia um pacote para o endereço 72.72.72.1 (DA - outside local e outside global). Ao passar (da interface INSIDE para OUTSIDE) por um roteador com NAT habilitado poderá ter traduzido o endereço de origem (SA) de 192.168.0.1 (inside local) para 200.200.200.1 (inside global). Esta tradução permite que o host 192.168.0.1 estabeleça uma comunicação com o host 72.72.72.1. O pacote com a resposta do host 72.72.72.1 terá como endereço de destino 200.200.200.1 (inside global) e novamente ao passar pelo roteador com NAT habilitado será traduzido - agora o endereço de destino - de 200.200.200.1 para 192.168.0.1 (inside local), fazendo com que os pacotes cheguem até o seu destino correto. Exemplo:


Com isso, podemos ver como fica a configuração para um ambiente com NAT estático como é exemplificado na figura acima.

ip nat inside source static 192.168.0.1 200.200.200.1

! interface INSIDE
interface fast0/0
ip nat inside

! interface OUTSIDE
interface serial0/0
ip nat outside

A utilização de "inside source" ou "outside source" na regra de tradução (NAT) altera a forma como é traduzido o endereço dos pacotes de acordo com o sentido do tráfego:

- ip nat inside source

• Traduz o endereço de ORIGEM dos pacotes que trafegam da interface inside para outside.
• Traduz o endereço de DESTINO dos pacotes que trafegam da interface outside para inside.

- ip nat outside source

• Traduz o endereço de ORIGEM dos pacotes que trafegam da interface outside para intside.
  
• Traduz o endereço de DESTINO dos pacotes que trafegam da interface inside para outside.
  

Podemos agora verificar se está tudo funcionando conforme o planejado com o seguinte comando:

Router#show ip nat translations

Pro     Inside global      Inside local       Outside local      Outside global
---     200.200.200.1      192.168.0.1            ---                 ---

Ainda temos dois tipos de NAT que não serão discutidos aqui, tal como o NAT dinâmico e a tradução de porta (também conhecido como PAT, ou Port Address Translation). Estes outros tipos de NAT seguem o padrão apresentado acima.

Vamos analisar uma outra questão importante quando estamos trabalhando com NAT...

NAT Virtual Interface

Um dos problemas que podemos enfrentar quando habilitamos NAT utilizando interfaces INSIDE e OUTSIDE é a necessidade de inserir rotas para os endereços traduzidos. Isso acontece pois a ordem de tradução e roteamento ocorre em momentos diferentes durante o processamento de um pacote dependendo do sentido do tráfego. No sentido inside-to-outside a tradução é feita DEPOIS da decisão de roteamento. No sentido contrário (outside-to-inside) a tradução acontece primeiro. A ordem completa pode ser encontrada aqui.

A partir da versão 12.3T a Cisco introduziu o conceito de NAT Virtual Interface (NVI)*. Dessa forma, a tradução dos endereços ocorre de forma simétrica e não é necessário inserir rotas para os endereços traduzidos. Quando uma interface está habilitada para fazer NAT utilizando NVI, o pacote que adentrar esta interface será roteado para a interface NVI (onde ocorre a tradução) e depois roteado mais uma vez utilizando a tabela de roteamento. A configuração utilizando NVI para o exemplo que citamos acima é a seguinte:

ip nat source static 192.168.0.1 200.200.200.1

interface fast0/0
ip nat enable

interface serial0/0
ip nat enable

Veja que dessa forma não é necessário declarar nenhuma interface como inside ou outside, ou mesmo declarar o sentido de tradução no comando de NAT estático. Esta nova funcionalidade resolve também o problema de tradução para endereços roteados para uma mesma interface de entrada (já que pode existir casos em que um pacote pode entrar por uma interface outside e nunca alcançar a interface inside correspondente, conforme descrito neste artigo).

Para encerrar este post, gostaria de reforçar que até aqui não foi apresentado nenhum mecanismo ou forma de segurança relacionada com a utilização (ou a não utilização) de NAT, apesar de, no passado, muitos profissionais acreditarem que a simples utilização de tradução de endereços poderia aumentar a segurança de um ambiente...

Veja também:

• Cisco NAT: Global and local definition.
• Cisco Configuring Network Address Translation: Getting Started.
  
• The Inside and Outside of NAT (Internetwork Expert’s CCIE Blog).
• Cisco NAT: Order of Operation.
• CiscoIOS 12.3T: NAT Virtual Interface.
  

(*) A interface NVI0 que está presente nos roteadores que possuem NAT habilitado (a partir da versão 12.3T) é a NAT Virtual Interface:

Router# show interfaces
(...)
NVI0 is up, line protocol is up
Hardware is NVI
Interface is unnumbered. Using address of NVI0 (0.0.0.0)
(...)

Um Pouco de História

Há algum tempo atrás, navegando por águas desconhecidas, encontrei a história do programa PING. Aquele que todos usamos para testar a conectividade entre um ponto e outro da rede e, ao contrário do que muitos acreditam, o nome PING não é nenhum acrônimo (ou coisa parecida). Este nome foi inspirado no som produzido por um sonar ao encontrar um objeto... Toda esta história está na página do criador do programa, o sr. Mike Muuss.

Esta história me fez lembrar uma outra história passada já em terras brasileiras e contada também por quem fez (e continua fazendo) história. "Os Primeiros Pings" é o título de uma reportagem publicada no jornal Estado de São Paulo em 1/11/2004 quando houve a "comemoração" dos 35 anos de "criação" da Internet e descreve como o Brasil - representado na época pela Fapesp - conectou-se pela primeira vez à Internet. Demi Getschko, um dos responsáveis pelos primeiros pings disparados do Brasil, é quem assina esta reportagem.

Duas histórias que valem a pena, nem que seja para puxar um papo high-tech com o seu avô na macarronada do próximo domingo! :-)

Atualizado em 24/03/2008: Como o link para a reportagem "Os Primeiros Pings" geralmente não funciona, estou colocando ela aqui na íntegra:



Os primeiros "pings"

Demi Getschko

A Bitnet já estava em uso há uns dois anos. Na linha que ligava a Fundação de Amparo à Pesquisa do Estado de São Paulo (Fapesp) ao FermiLab, em Batavia, Illinois, rodava um procolo da DEC (o DecNet) e, sobre ele, o protocolo da IBM usado para o Bitnet (o RSCS). E isso em 4800 bps!

Um belo dia, entra em minha sala o Geraldo (prof. dr. Geraldo Lino de Campos): - Demi, a tendência clara nos EUA é uma migração em massa para TCP/IP, Internet. Precisamos incluir TCP/IP na linha.

Se havia alguém que podia fazer isso – colocar três protocolos, sérios e pesados, numa linha de 4800 – era Gomide (Alberto Courrege Gomide), o mago do software na Fapesp. Ele foi atrás de soluções e encontrou o MultiNet, do melhor jeito que dava. E o troço nem barato era, especialmente para os padrões acadêmicos!

Afinal, chegou a caixa com as fitas (DecTape à época). O Joseph (Joseph Tannous Moussa, um libanês que tinha feito computação na USP e trabalhava na Fapesp) não resistiu à tentação e começou a instalar o pacote. Janeiro, período de férias coletivas na Fapesp e, ainda por cima, sábado. Passamos a tarde inteira instalando o Multinet. Afinal, funcionou! Restava acertar o lado de lá. Gomide, numa visita ao Fermilab, soube que o laboratório estava também em fase de passar ao TCP/IP, integrando a EsNet (Energy Sciences Network): “assim que o Fermi estivesse conectado à internet, nos também estaremos!”

Agora, buscar endereços!: para estar na rede, alguém precisa de números IP. E números IP quem distribui é a IANA (Internet Assigned Numbers Authority). IANA é a outra forma com que era conhecido Jon Postel, um dos criadores da rede e uma das ausências ainda hoje mais sentidas e difíceis de suprir na Internet (Postel morreu em 1998).

Michael, da PUC do Rio (prof. Michael Stanton) já havia pedido e conseguido o primeiro subconjunto de números IP para uma instituição brasileira: a rede classe B 139. 82.*.*. Pedimos ao Postel, de cara, três classes B: para a Unicamp, a USP e a Fapesp, e recebemos as 143.106.*.*; 143.107.*.*; 143.108.*.* . Cenário completo e armado. Nossa "poderosa" linha de 4800 bpd transportaria também pacotes TCP/IP sobre o DecNet básico, via software. A linha já estava com 100% de ocupação, 98% do tempo mas, mesmo assim, alguns pacotes conseguiram pingar entre o fpsp.fapesp.br e o fnal.gov. Era janeiro de 1991 e a Internet chegava, em conta-gotas, ao Brasil...

Demi Getschko, é pioneiro da internet no Brasil.

NANOG 42 - Vídeos

Mais um feriado se aproxima e se você está sem o que fazer pode aproveitar para ver algumas apresentações da última reunião da NANOG. Os vídeos estão disponíveis através da Agenda de apresentações.

Cisco IOS - Nomenclatura e Versões (Parte 2)

Para completar as informações sobre o sistema operacional da Cisco é necessário citar a classificação que é atribuída a cada imagem e as famílias principais utilizadas pela Cisco atualmente.

A classificação que cada imagem recebe permite-nos avaliar qual versão deverá ser utilizada em uma infraestrutura de rede, dado os requisitos de funcionalidade e estabilidade. Toda a trilha de classificações abaixo têm início em uma major release do IOS. Lembrando que a major release é a versão principal do IOS, por exemplo, 12.1, 12.2, 12.3, etc. São elas:

• Limited Deployment (LD): uma major release do IOS é classificada como LD após o seu lançamento comercial (FCS ou First Commercial Shipment) e antes de alcançar a classificação GD (General Deployment).
• General Deployment (GD): em um determinado momento no ciclo de vida do desenvolvimento de uma major release a Cisco poderá classificar uma versão como GD. Esta classificação pode ser atribuída somente à uma major release e é baseada principalmente no feedback recebido dos clientes sobre a estabilidade da versão. Durante o ciclo de vida de uma versão GD, todas as versões subsequentes (somete com correções de bugs e problemas de segurança) serão consideradas GD.
  
• Early Deployment (ED): são as versões baseadas em major releases que, no entanto, possuem novas funcionalidades, atualizações de segurança e correção de bugs. O propósito das versões ED é permitir que os clientes possam utilizar novas funcionalidades mais rapidamente. Como as versões classificadas como ED não são totalmente estáveis, é aconselhável utilizá-las somente caso não haja uma versão GD ou LD que possua suporte a uma determinada funcionalidade.
  
• Deferral (DF): O propósito de classificar uma verão como DF é anunciar que esta versão não estará mais disponível para download e que já existe uma nova imagem para substituí-la. A partir deste momento a Cisco aconselha que todos os seus clientes atualizem uma possível versão DF para a sua substituta.

Com o passar do tempo, a Cisco restringiu o desenvolvimento do IOS para três famílias principais. São elas: T, S e XR. Estas famílias seguem objetivos (funcionalidades e suporte a hardware) e ciclo de vida diferenciados e, portanto, são aconselhadas para diferentes propósitos, como poderemos ver a seguir:

-Train T: Possui basicamente duas trilhas (12.3/12.4 e 12.4T) com várias funcionalidades para (principalmente) roteadores de acesso e redes comerciais.

• 12.3/12.4: possui as novas funcionalidades adicionadas às versões T anteriores e as correções de bugs e problemas de segurança.
• 12.4T: possui suporte a novos hardwares e funcionalidades.

-Train S: Esta família é dedicada para os provedores de serviço (Service Provider) e possui maior suporte para roteadores (e/ou switches) do núcleo destes provedores (por exemplo, os modelos 7600 ou 6500).

• 12.2SB: Broadband and Leased-Line Aggregation, and MPLS Provider Edge (PE).
• 12.2SX: functionality and hardware for high-end Ethernet LAN switching for Enterprise access, distribution, Core and data center networks.
• 12.2SE/12.2SG: for mid-range and low-end Ethernet LAN switching for Enterprise access and distribution networks, and mid-range and low-end Metro Ethernet for Service Provider edge networks.
• 12.2SR: for high-end Metro Ethernet and MPLS PE for Service Provider

-Train XR: desenvolvida para o Cisco CRS-1 (Carrier Routing System) e para o Cisco XR 12000 Series para provedores de serviço, visando principalmente plataformas que necessitam de alto desempenho (possivelmente chegando a escala de terabits). Atualmente na versão 3.2.

Além disso, a Cisco recomenda a instalação de um tipo de imagem de acordo com a plataforma. As principais recomendações estão dispostas abaixo (uma lista completa e atualizada pode ser encontrada aqui):

• Roteadores 800, 1700, 2600, 2800, 3700 e 3800 (low-range): 12.4 ou 12.4T;
• Roteadores 7200 e 7301: 12.4T ou 12.2SB;
• Roteadores 7500: 12.4 ou 12.0S;
• Roteadores 7600: 12.2SR;
• Roteadores 12000: IOS-XR ou 12.0S;
• Roteadores CRS-1: IOS-XR;
• Switches Catalyst 2970, 3560 e 3750: 12.2SE;
• Switches Catalyst 4500 e 4900: 12.2SG;
• Switches Catalyst 6500:12.2SX;

Com isso encerramos este pequeno resumo sobre como a Cisco trata a nomeclatura, a classificação (dentre as plataformas) e as versões do Cisco IOS.

Veja também:

• Cisco IOS - Nomenclatura e Versões (Parte 1)
• White paper que descreve a nomenclatura, versões e life cycle do IOS e IOS XR.

Cisco IOS - Nomenclatura e Versões (Parte 1)

Entender como funciona a nomenclatura e as versões do Cisco IOS é importante quando estamos instalando um novo equipamento e mais ainda quando estamos fazendo uma atualização. Isso por que uma simples confusão pode resultar em um serviço que, "sem um motivo aparente", parou de funcionar depois da atualização.

_Versões

Primeiro veremos como funiona a numeração das versões do Cisco IOS. O formato geral para a numeração é a.b(c.d)e, onde:

• "a" e "b" identificam a versão principal ou main version ("a" é chamado de major version e "b" minor version).
• "c" é a versão de lançamento (release).
  
• "d" (que é muitas vezes omitido) representa o número da versão intermediária (interim build number).
• "e" (podendo ser nenhuma, uma ou duas letras) representa qual train pertence o IOS. Neste caso, podemos encontrar nenhuma letra (representa a train principal ou mainline), T (para Technology), E (para Enterprise), etc. Mais detalhes adiante.
  

Vejamos um exemplo: 12.3(1)T é a primeira release da train T da versão principal 12.3. A imagem 12.3(2)T é a release subsequente neste caso.

Juntamente com este padrão de numeração para as versões a Cisco adota um padrão de desenvolvimento onde as novas funcionalidades são adicionadas às versões da train T que, no final de seu ciclo de desenvolvimento e testes, irão integrar uma nova main release. Esta nova main release só receberá correções de bugs, ficando a cargo da nova train T receber a implementação de novas funcionalidades. Este processo está descrito na figura abaixo:

Ainda é importante citar as versões rebuilds, que são versões liberadas geralmente com apenas uma correção e de forma mais rápida e constante. Por exemplo, 12.1(8)E14 é a décima-quarta rebuild da imagem 12.1(8)E.

Ainda temos que destacar as seguintes trains:

• A train mainline (que não possui letra) é a mais estável dentre as demais e o seu conjunto de funcionalidades não cresce durante o seu tempo de vida. As novas versões dentro desta train possuem apenas correções para bugs e problemas de segurança.
  
• A train T (Technology train) recebe atualizações de bugs, problemas de segurança e novas funcionalidades e, portanto, é menos estável que a train mainline.
  
• A train S (Service Provider) é aconselhada para equipar os roteadores do núcleo principal de provedores de serviço e é personalizada para tanto.
  
• A train E (Enterprise) é personalizada para ambientes Enterprise.
  
• A train B (Broadband) possui suporte especial para funcionalidades de banda-larga (broadband access).
• As trains X* (XA, XB, ...) possuem funcionalidades especiais que devem ser documentadas conforme o lançamento das mesmas.
  

_Nomenclatura

Até meados de 2006 a Cisco utilizava um conjunto de códigos de letras para especificar as diversas funcionalidades disponíveis no IOS que hoje são agrupudas em pacotes (ou packages). A lista abaixo reúne os códigos de letras mais utilizados na nomeclatura das imagens do IOS até 2006:

• i - IP routing
• j - Enterprise
• p - Service Provider
• y/y5 - IP Routing (low-end routers, missing some IP routing/features like BGP)
• k2/k8/k9 - Encryption(DES=k8, 3DES=k9)
• o - Firewall
• s - Plus, or "LAN Only" on Cat6K/7600
• l - Runs from Flash
• m - Runs from RAM
• z - Compressed image

Para uma lista completa de códigos deve-se consultar a documentação clicando aqui. Nada melhor que um bom exemplo para clarear as idéias; c2600-ik9o3s3-mz.122-15.T9.bin é o nome do arquivo de uma imagem do IOS com as seguintes características:

• c2600 = Imagem para a plataforma 2600 series.
• i = versão com funcionalidades de IP routing.
  
• k9 = possui suporte a criptografia.
  
• o3 = versão com suporte a firewall/ids.
• s3 = versão "Basic limited routing / limited memory"
  
• mz = é executada da memória RAM e está comprimida.
• 122-15.T9 = é a versão 12.2, já houve 15 atualizações, train T e está na 9a. compilação.

É importante entender esta nomenclatura para saber quais os pacotes de funcionalidades necessários no caso de um upgrade de uma imagem que ainda está no modelo antigo para uma imagem do IOS que segue o novo modelo de nomenclatura.

Este novo modelo segue um padrão um pouco menos complicado e com menos opções, além de poder ser utilizado em todas as plataformas de roteadores igualmente (cross-plataform). Os pacotes disponíveis para os roteadores são (nomes dos arquivos correspondentes entre parênteses):

• IP Base (cxxxx-ipbase-mz)
  
• IP Voice (cxxxx-ipvoice-mz)
  
• Advanced Security (cxxxx-advsecurityk9-mz)
  
• Service Provider Services, also known as SP Services (cxxxx-spservicesk9-mz)
  
• Enterprise Base (cxxxx-entbase-mz)
  
• Advanced IP Services (cxxxx-advipservicesk9-mz)
  
• Enterprise Services (cxxxx-entservicesk9-mz)
  
• Advanced Enterprise Services (cxxxx-adventerprisek9-mz).

Já as funcionalidades estão distribuídas entre os diversos pacotes de acordo com o diagrama abaixo, onde o pacote Advanced Enterprise Services é um conjunto completo de todas as funcionalidades disponíveis em uma versão do IOS:
Lembre-se que até agora estamos falando do IOS para roteadores. A forma de pacotes e funcionalidades para switches segue um padrão ligeiramente diferente. Para maiores informações é necessário consultar a documentação oficial da Cisco aqui. Este documento também pode ser consultado para saber mais detalhes sobre as funcionalidades existentes em cada pacote. Sempre que estivermos trabalhando com imagens de IOS é importante consultar as ferramentas web oficiais da Cisco:

• Cisco Software Advisor
• Cisco IOS Upgrade Planner
• Cisco IOS Feature Navigator

Para finalizar, se você quiser verificar qual a imagem está em execução no seu equipamento, basta entrar com o comando show version no modo de execução global e procurar por uma descrição semelhante a que vemos abaixo:

System image file is "flash:c3725-entbase-mz.124-6.T.bin"

Veja também:

• Cisco IOS - Nomenclatura e Versões (Parte 2)
  
• White paper que descreve a nomenclatura, versões e life cycle do IOS e IOS XR.
  
• Um documento com um resumo dos pacotes e funcionalidades no IOS.
• Uma apresentação sobre como funciona os pacotes e o histórico do IOS.

Atualizações de Segurança da Cisco

A Cisco anunciou recentemente que irá mudar a política de liberação de atualizações de segurança para o seu sistema operacional carro-chefe Cisco IOS. As atualizações serão liberadas duas vezes ao ano (na quarta quarta-feira de março e de setembro) começando no próximo dia 26 de março. De acordo com as informações do site da Cisco, esta ação é uma resposta aos pedidos dos clientes para que as atualizações fossem liberadas ao público seguindo um calendário pré-definido.

A reação nas listas de discussão foi imediata. Há aqueles que gostaram e há aqueles que não gostaram. À primeira vista pode parecer estranho atualizar as brechas de segurança duas vezes ao ano, no entanto, essa visão pode não ser tão clara quanto parece. Atualmente a Oracle e a Microsoft (duas empresas que também possuem um parque instalado muito grande) também seguem um padrão para liberação de correções de segurança; quadrimestral e mensal, respectivamente. Entretanto, nenhuma destas empresas deixou de responder a um problema crítico de segurança da forma mais ágil possível e é isso que a Cisco está prometendo:

"This schedule change will not restrict us from promptly publishing an individual IOS Security Advisory for a serious vulnerability which is publicly disclosed or for which we are aware of active exploitation." (Ufa!)

Até o momento a Cisco tem liberado as atualizações de vulnerabilidades com pouco intervalo de tempo. Esse processo continuará para as vulnerabilidades publicamente conhecidas. As correções para as vulnerabilidades desconhecidas serão publicadas de acordo com o cronograma pré-definido. É certo que esta alteração simplificará o processo de instalação de atualizações de segurança, principalmente em grandes redes non-stop com centanas (possivelmente milhares) de equipamentos, onde o planejamento é certamente mais complicado. Afinal de contas, todos os equipamentos estão com as últimas correções, não? :-)

Veja também:

• Anúncio sobre as atualizações de segurança do Cisco IOS.
• Política de divulgação de vulnerabilidades de segurança para outros produtos Cisco.