Serviço Experimental de CIrcuitos aPrOvisionados dinamicamente (SE-CIPÓ)

Skip to end of metadata
Go to start of metadata

OSCARS

Os arquivos que descrevem a topologia ainda são escritos manualmente ou existe uma forma de gerar esses XMLs?

Existe um software (https://code.google.com/p/topology-wizard/). Para descrever as topologias da UFRGS e PoP-RS, não foi utilizado, foi escrito o arquivo XML manualmente mesmo, pois essas topologias são simples. No momento, não podemos dar mais detalhes sobre a ferramenta, ela ainda é um experimento, mas pode ser testada.

Um circuito falha e apresenta a seguinte mensagem de erro aparece na WebGUI do OSCARS: "Unable to create LSP: Dest local-id Login Error: Unable to establish connection to <endereço_do_VLSR>"

Quando isso ocorre, deve-se verificar a conectividade entre a VM do OSCARS e a VM do VLSR que possui o endereço '<endereço_do_VLSR>'.

O OSCARS se conecta ao daemon 'dragon' do VLSRs para enviar os comandos de criação dos circuitos. O 'dragon' ouve na porta '2611'. Da VM do OSCARS deve ser possível se conectar na porta 2611 dos VLSRs. O comando 'nc' pode ser usado para testar a conectividade. De um terminal na  VM do OSCARS deve-se rodar o comando abaixo para cada VLSR:

nc -v <endereço_do_VLSR> 2611

A resposta esperada quando a comunicação funciona é: 'Connection to <endereço_do_VLSR> 2611 port [tcp/] succeeded!'*

Se a resposta acima não for obtida, deve-se verificar possíveis problemas que impeçam a conexão (ligações fisícas, mapeamento das interfaces das VMs, firewalls, etc).

Como renovar o certificado expirado da VM do OSCARS

Os certificados gerados pelo ICPEDU tem validade de 365 dias. Para verificar se o certificado está na validade deve-se executar o comando ./idc-certview de dentro da pasta /usr/local/oscars/tools/utils, escolher a opção "1. OSCARS.jks", e em seguida escolher a opção que identifica o alias do certificado do domínio OSCARS (se você seguiu o guia de criação de certificados do IDC-OSCARS, o alias provavelmente será no formato "pop-xx").

O resultado apresentado será semelhante ao exemplo abaixo, e o período de validade do certificado estará presente na primeira linha "Valid from: ... until: ...".

– Certificate details

Alias name: idc-cipo
Creation date: Aug 24, 2012
Entry type: keyEntry
Certificate chain length: 3
Certificate[1]:
Owner: L=YYYY, OU=RNP, O=ICPEDU, C=BR, ST=XX, CN=oscars.cipo.pop-xx.rnp.br
Issuer: L=Brasilia, O=RNP, O=ICPEDU, EMAILADDRESS=gopac@icp.edu.br, C=BR, ST=Distrito Federal, CN=AC-SSL da ICPEDU
Serial number: 28
Valid from: Thu Aug 23 19:13:04 BRT 2012 until: Fri Aug 23 19:13:04 BRT 2013
Certificate fingerprints:
MD5:  XXXXXXXX
SHA1: XXXXXXXX
Certificate[2]:
Owner: L=Brasilia, O=RNP, O=ICPEDU, EMAILADDRESS=gopac@icp.edu.br, C=BR, ST=Distrito Federal, CN=AC-SSL da ICPEDU
Issuer: EMAILADDRESS=gopac@icp.edu.br, L=Brasilia, ST=DF, CN=AC Raiz ICPEDU, OU=GOPAC, O=ICPEDU, O=RNP, C=BR
Serial number: 7
Valid from: Thu Oct 22 10:23:51 BRST 2009 until: Wed Oct 22 10:23:51 BRST 2014
Certificate fingerprints:
MD5:  XXXXXXXX
SHA1: XXXXXXXX
Certificate[3]:
Owner: EMAILADDRESS=gopac@icp.edu.br, L=Brasilia, ST=DF, CN=AC Raiz ICPEDU, OU=GOPAC, O=ICPEDU, O=RNP, C=BR
Issuer: EMAILADDRESS=gopac@icp.edu.br, L=Brasilia, ST=DF, CN=AC Raiz ICPEDU, OU=GOPAC, O=ICPEDU, O=RNP, C=BR
Serial number: 1
Valid from: Tue Nov 11 14:32:15 BRST 2008 until: Fri Nov 11 14:32:15 BRST 2033
Certificate fingerprints:
MD5:  XXXXXXXX
SHA1: XXXXXXXX

Para atualizar o prazo de validade do certificado é necessário gerar um novo .csr para ser enviado ao ICPEDU para a assinatura. Um novo .csr pode ser gerado com o comando ./idc-certsignreq como no exemplo abaixo:

cd /usr/local/oscars/tools/utils/
./idc-certsignreq
– Using keystore password from /usr/local/tomcat/shared/classes/repo/rampConfig.xml
– Using certificate with the alias pop-xx
— If this is not the correct alias please exit (Ctrl-C) and modify the <ramp:user> tag in rampConfig.xml
What filename should I give the CSR?: pop-xx.csr
– Certificate Signing Request saved in file pop-xx.csr

Depois disso o arquivo pop-xx.csr deve ser enviado ao ICPEDU para a assinatura. Para isso deve-se abrir um ticket enviando um email para se-cipo@rt.rnp.br. Ao receber de volta o certificado assinado (estou assumindo que o nome do arquivo do certificado assinado será 00-pop-xx-pem.cer), basta executar os comandos abaixo:

cd /usr/local/oscars/tools/utils/
./idc-certadd
What would you like to do?
    1. Create a new certificate my IDC will use in outgoing messages to other IDCs
    2. Import a certificate created using choice 1 that was signed by a CA
    3. Trust a CA or another IDC's certificate
Enter choice: 2

– You have chosen to import a signed certificate for talking to other domains.

Enter the filename of your signed certificate: 00-pop-xx-pem.cer
– Using keystore password from /usr/local/tomcat/shared/classes/repo/rampConfig.xml
– Using certificate with the alias pop-xx
— If this is not the correct alias please exit (Ctrl-C) and modify the <ramp:user> tag in rampConfig.xml
Certificate reply was installed in keystore
– Signed certificate imported
— Send the following X.509 subject to your neighboring IDCs: L=YYYY, OU=RNP, O=ICPEDU, C=BR, ST=XX, CN=oscars.cipo.pop-xx.rnp.br

Depois disso deve-se reiniciar o OSCARS com os comandos abaixo:

cd /usr/local/oscars
./oscars.sh

Lentidão no boot da VM do OSCARS causada pelo serviço sm-client

Deve-se adicionar a seguinte linha no arquivo /etc/hosts, com uma entrada associando o endereço IP_externo ao hostname do OSCARS. Esta lentidão geralmente é causada por problemas de comunicação com o servidor de DNS.

IP_externo    oscars    oscars.cipo.pop-xx.rnp.br

Mensagem de erro " [ERROR] scheduler.RegisterPublisherJob Exception when trying to register with NotificationBroker: org.apache.axis2.AxisFault: Unable to authenticate user" no oscars.log

Este erro ocorre pois, em alguns casos o OSCARS inverte a ordem dos campos e não consegue identificar corretamente o usuário pelo Subject do certificado.

Os seguintes passos devem ser executados:

1- Acesse a WebGUI do OSCARS (https://oscars.cipo.pop-xx.rnp.br:8443/OSCARS) com o usuário admin;
2- Vá para a aba User list e depois clique no usuário do PoP-XX (provavelmente, user-pop-xx);
3- No campo X.509 subject name verifique se o subject do usuário do PoP-XX está assim (com os campos nesta ordem): CN=oscars.cipo.pop-xx.rnp.br, ST=XX, C=BR, O=ICPEDU, OU=RNP, L=<cidade>. Se não estiver, mude para ficar deste jeito e clique em modify.
4- Reinicie o OSCARS (cd /usr/local/oscars; ./oscars.sh);

Corrigindo erro do script de inicialização do OSCARS no init.d

ATENÇÃO: O script de inicialização do OSCARS /etc/init.d/oscars que foi disponibilizado dentro da VM contém um erro que foi detectado posteriormente. Uma variável de ambiente está errada e deve ser corrigida. 

Você deve abrir o arquivo /etc/init.d/oscars em algum editor de sua preferência, por exemplo, o vim:

vim /etc/init.d/oscars

Depois deve editar a linha onde a variável prog_path é setada, como no exemplo abaixo:

Antes:

prog_path="/usr/local/dcn-software-suite/idc"

Depois:

prog_path="/usr/local/oscars"

Como alterar o contador usado no GRI dos circuitos de um domínio

 

O OSCARS numera os circuitos criados com um ID único e global (GRI). Esse GRI é uma concatenação do nome do domínio de onde o circuito foi criado e um número que é incrementado a cada novo circuito (domain_name-#).

No caso de reinicialização da base BSS do OSCARS, faz com que o OSCARS reinicie a contagem dos GRI's do zero. Em consequência, GRI's já usados no passado começam a ser usados novamente. Quando um circuito INTRA-domínio é criado, os demais domínios não tomam conhecimento daquele GRI, mas quando um circuito INTER-domínio é criado, o GRI do circuito é enviado aos outros domínios no caminho do circuito. Para resolver esse proble, é necessário alterar o valor inicial do contador. Para isso, sigam os passos:

i) como root, executar:

mysql

ii) no prompt do mysql, executar:

use bss;

insert into idSequence set id=<valor_inicial_do_contador>;

Instalar o agente de monitoramento de peerings (nb_check)

Para os administradores que já tem a VM do OSCARS instalada foi criado um script de instalação e configuração do agente nb_check. Para isso, o script instala e configura também o snmpd. Para instalar o agente, você deve executar de dentro da VM do OSCARS os seguintes comandos como root:

Depois disso você deve responder às perguntas abaixo:

  1.  Informe a instituicao (PoP-RJ, RNP, UFRJ, ...) - você deve responder com o nome da instituição que abriga o POD;
  2. Informe a comunidade a ser usada no snmpd - você deve informar a comunidade que foi configurada ou que será usada para as consultas snmp. Deve-se colocar o mesmo nome (case-sensitive) que foi usado na configuração da VM de monitoramento.
  3. Informe o email do administrador do POD.
  4. Quantos peerings este dominio possui - você deve informar a quantidade de peerings que o OSCARS possui. Para a maioria dos PoPs que fazem peering apenas com o domínio do backbone da RNP, o valor passado deve ser igual à 1.

Depois de executar o script e responder às perguntas, o agente estará instalado e rodando.


VLSR

Ao solicitar criação de circuitos através do OSCARS ou CLI do DRAGON, o circuito é aceito e fica ativo porém nenhuma vlan é configurada no switch

O problema é causado pela falta a descrição de pelo menos uma interface ospf-te, onde é indicado o ip do switch e o protocolo usado para configura-lo, no caso snmp.
Para resolver, deve-se adicionar as seguintes linhas no arquivo ospfd.conf da VLSR:

ospf-te interface Core-Narb # É interface do tunel GRE para o NARB
level gmpls
data-interface ip xxx.xxx.xxx.xxx protocol snmp switch-ip yyy.yyy.yyy.yyy switch-port n # Sendo: a) "x" uma string ou numero que é utilizada pelo DRAGON para controlar os links do data-plane. Geralmente usado no mesmo formato de IP para facilitar o entendimento. b) "y" o ip do switch c) "n" uma porta que não exista no switch. Por exemplo 28 em um switch de 24 portas. O correto é colocar a porta onde esta ligado esta data-interface, mas como na nossa topologia só existe 1 switch, não há nenhuma data-interface, então usamos uma porta falsa.
swcap l2sc encoding ethernet
\! 1Gbps = 125000000 bytes/sec
max-bw 125000000
max-rsv-bw 125000000
max-lsp-bw 0 125000000
max-lsp-bw 1 125000000
max-lsp-bw 2 125000000
max-lsp-bw 3 125000000
max-lsp-bw 4 125000000
max-lsp-bw 5 125000000
max-lsp-bw 6 125000000
max-lsp-bw 7 125000000
vlan 100 to 200
metric 10
exit

Como testar a criação de um circuito (LSP - Labeled Switch Path) via CLI (Command Line Interface) no DRAGON?

Os passos para o teste são mostrados abaixo.

Primeiro, conectar-se ao DRAGON (por padrão ele executa na porta 2611):# telnet <ip_vlsr> 2611
Ou, se já estiver logado na VM (máquina virtual), pode ser colocado o localhost:# telnet 127.0.0.1 2611
No DRAGON, os comandos básicos são os seguintes:

Para mostrar as portas clientes disponíveis para configurar o LSP (as portas aqui disponíveis são as que devem ser utilizadas no parâmetro <nr_porta> no comando logo abaixo, essas são as portas configuradas no arquivo /usr/local/dragon/etc/dragon.conf):vlsr> show local-id
Para criar o LSP, só substituir os parâmetros <nome>, <ip_vlsr1>, <ip_vlsr2>, <nr_porta> e <nr_vlan> (um detalhe: o VLSR de origem e destino pode ser o mesmo):vlsr> edit lsp <nome>
vlsr(edit-lsp-<nome>)> set source ip-address <ip_vlsr1> port <nr_porta> destination ip-address <ip_vlsr2> port <nr_porta>
vlsr(edit-lsp-<nome>)> set bandwidth eth100M swcap l2sc encoding ethernet gpid ethernet
vlsr(edit-lsp-<nome>)> set vtag <nr_vlan>
vlsr(edit-lsp-<nome>)> exit
vlsr> commit lsp <nome>
Para verificar os LSPs criados:vlsr> show lsp
Ou, para mostrar mais detalhes de um LSP específico:vlsr> show lsp <nome>
Depois de criado o LSP, se tudo tiver ocorrido com sucesso, poderá ser verificado no switch a VLAN criada pelo DRAGON.

Foi feito um teste tentando ligar 1 notebook em uma porta, outro notebook em outra e solicitar via CLI a criação do circuito, porém sem sucesso. O LSP ficou em status commit e retornou o ERROR 1 - source não foi encontrado. Como testar esse cenário? O que pode estar errado?

Verifique as configurações, se os IPs (VLSR e switch) estão configurados corretamente no arquivo /usr/local/dragon/etc/ospfd.conf. Verifique se as portas dos clientes estão configuradas no arquivo /usr/local/dragon/etc/dragon.conf, as portas válidas devem aparecer quando é executado o comando show local-id no DRAGON. Por último, verifique se na criação do LSP os IPs de origem e destino informados são do VLSR, e não do switch.

Problema no arquivo de logs "RSVP.log" do VLSR: "Error while reading VLAN/port mapping from Switch!"

Quando este erro aparecer no log do VLSR, pode ser problema de configuração de VLAN. Possíveis problemas:

  • PROBLEMA: Sujeira de configuração de VLAN da faixa de VLANs que o VLSR utiliza, ou seja, existem VLANs criadas no equipamento da faixa do VLSR que não tem circuitos associados.
    RESOLUÇÃO: Remova as configurações das VLANS que estão configuradas desnecessariamente;
  • PROBLEMA: Aparece a mensagem, mas foi verificado que não há VLANs extras que não estejam configuradas em circuitos.
    RESOLUÇÃO: Reiniciar switch, pode ter ficado sujeira de configuração no equipamento.

NARB

O NARB precisa ficar em uma VM (máquina virtual) separada? Existe algum problema de instalar ele na mesma VM do OSCARS?

Não necessariamente, na página de instalação está documentado para instalar na mesma VM. No cenário que foi construído para o curso no SCI 2011 foram instalados em VMs separadas.

Monitoramento

Caso encha alguma partição e pare de monitorar, pode ser que o ponteiro dos circuitos tenha se perdido

Executar os seguintes comandos:

 cd /opt/rnp-mon-dcn/files/
 rm list_circuits.txt-last
 touch list_circuits.txt-last

Infraestrutura

As VMs (máquinas virtuais) podem compartilhar a mesma interface de rede? Ou é necessário dedicar uma para cada VM?

As VMs podem compartilhar a mesma interface física sim, desde que se atribuam IPs diferentes. No servidor da UFRGS, por exemplo, foi feito o seguinte esquema (há um só VLSR, portanto não há NARB):

  • vmnic0:
    • VM OSCARS - eth0: 200.132.xx.yy (IP válido)
    • VM VLSR - eth0: 200.132.xx.zz (IP válido)
  • vmnic1:
    • VM OSCARS - eth1: 10.51.1.253 (rede interna)
    • VM VLSR - eth1: 10.51.1.251 (rede interna)

A vmnic1 está conectada diretamente ao switch, cujo IP é 10.51.1.250.

Ao importar as máquinas virtuais para um ambiente de testes com VirtualBox aparecero erro VEER_NOT_SUPPORTED ou Failed to open hard disk, o que fazer?

Caso apareça este erro ao tentar por um vmdk em uma nova máquina virtual no VirtualBox o arquivo vmdk deverá ser convertido, conforme procedimento abaixo:

VBoxManage clonehd <arquivo.vmdk> <arquivo.raw> --format RAW

Após esta conversão ainda é necessário converter mais uma vez para o formato vdi, para isto deverá ser executado o seguinte comando:

VBoxManage convertdd <arquivo.raw> <arquivo.vdi>

 

 

  • No labels