Install A2billing on Debian Squeezy

 A long time ago I performed my first A2billing setup. At that time I was totaly involved with Asterisk and find that Asterisk billing was very important to turn Asterisk in a more atractive product for sale.
 I remember that at that time I had no enough skill to setup A2billing from scratch. And at that time I could find someone that nicely helped me.
 In the times that follows I successfully deployed two A2billing and did it by my self. Actually, A2billing changes a little bit the way to administrate Asterisk as it controlls the system as a whole and not only tickets. You don´t need to edit extensions.conf or sip.conf anymore and this make me disaprove the software once all I wanted was setup Asteisk system through command line interface.
 I found and still find really sex to control a such complex system using commands. It is amazing how Asterisk allows you control and administrate a so sensible application using only a few piece of texts.
 Besides that, A2billing, just like any other Billing software, is very difficult to tune. We have a very complex sistem of charging phone calls and setup that in a Billing software is very very challanger. Personaly I never liked it, although I did for such a long time.
 I still believe that the best way to work with Asterisk is write your own customization. A good knowledge about Mysql, PHP and Linux can allow you setup a really good system with all the necessary tools.
 But, so far, all I am willing to do is try to setup someone else´s software and maybe I will do that as long as I stay in this area.
 So, today I decided go farther and setup a brand new A2billing in the server I am playing. And, as I like to do, I will  put here some information about this experiences.
 It is mandatory to have LAMP up and running in you system. If you don´t know about LAMP, take some time to seach and read some material about. It is very simple and necessary.
 After download A2billing software and put it in /usr/local/src/a2billing, unpack it. Make sure that A2billing don´t create another folder inside /a2billing. As you will see, the INSTALL.rst file refers to /usr/local/src/a2billing only and to have another folder can produce differente results for some commands.
 If it creates a new forder and sure it is, just copy and paste that folder´s file into a2billing folder. Like that,
 In my case, after unpack, the folder a2billing-master have been created. What I did is:
 cp -rf a2billing-master* /usr/local/src/a2billing/

 The final result must be:

root@debian:/usr/local/src/a2billing# ls -la
total 11620
drwxrwsrwx 13 root   staff     4096 Aug  6 06:26 .
drwxrwsr-x  3 root   staff     4096 Aug  6 05:14 ..
-rwxr-xr-x  1 root   staff     1571 Aug  6 06:26 a2billing.conf
-rw-r--r--  1 root   staff   140451 Aug  6 06:26 a2billing_dashboard.png
drwxrwxr-x 12 root   root      4096 Jul  3 03:14 a2billing-master
-rw-r--r--  1 flavio staff 11422927 Aug  6 05:19 a2billing-master.tar.gz
-rwxr-xr-x  1 root   staff     7631 Aug  6 06:25 a2billing_monitoring.php
-rwxr-xr-x  1 root   staff    80828 Aug  6 06:25 a2billing.php
drwxr-sr-x  9 root   staff     4096 Aug  6 06:26 addons
drwxr-sr-x  5 root   staff     4096 Aug  6 06:26 admin
drwxr-sr-x  4 root   staff     4096 Aug  6 06:26 agent
drwxr-sr-x  2 root   staff     4096 Aug  6 06:26 AGI
-rw-r--r--  1 root   staff     1912 Aug  6 06:26 AUTHORS
drwxr-sr-x  3 root   staff     4096 Aug  6 06:26 CallBack
-rw-r--r--  1 root   staff   112842 Aug  6 06:26 CHANGELOG
drwxr-sr-x  8 root   staff     4096 Aug  6 06:26 common
-rw-r--r--  1 root   staff    33652 Aug  6 06:26 COPYING
drwxr-sr-x  2 root   staff     4096 Aug  6 06:26 Cronjobs
drwxr-sr-x  7 root   staff     4096 Aug  6 06:26 customer
drwxr-sr-x  4 root   staff     4096 Aug  6 06:26 DataBase
-rw-r--r--  1 root   staff    18112 Aug  6 06:26 INSTALL.rst
-rw-r--r--  1 root   staff     1262 Aug  6 06:26 README.rst
-rw-r--r--  1 root   staff      544 Aug  6 06:26 REQUIREMENTS.rst
drwxr-sr-x  4 root   staff     4096 Aug  6 06:26 webservice

Ensure that you have all the necessary files and folders.

As you can see, between this files we have one very important and usefull : INSTALL.rst

There you can find all the information you need to have A2billing up and running.

Follow all the steps and instructions and you will be ready to go. Maybe the only extra command you will need is that:

 chown www-data:www-data /var/www/a2billing/admin/templates_c

In case of you try to access the A2billing web page and you get nothing but a big white page.

But, more important then that, take a close look at /var/log/apache2  folder. There you will find at least two important files: access.log  error.log.

 They are your friends. tail -f error.log can give you a very good ideia about what is going wrong inside.

And that´s it. This is the nessary to have A2billing up and running. I will take a close look at its configurations after going any father. It was a long time I  handled  it  and I dont remember too much.

 As soon as  I learn something interesting I will write another article:

 Sorry for any typo and/or mistakes. If you are native in English and/or have a expert skill on it, please feel free to correct me. That´s the only way I have to improve.

 Thanks a lot.

APT-GET UPDATE behind Proxy

 Hi there!  Again we are here bringing one more article for you folks and, this time, we will play a little bit with Linux. Debian Wheezy to be more specific.

Ultimately I am playing with Asterisk again. Asterisk has inspired me to write down this Blog and I never forgot how amazing Asterisk is. So, as soon as my projets gives me a bit of time, I decided to look around and see how things are going on Asterisk world.
 Therefore, after successfully installed my Debian, I got stuck in a problem:

This error repeat after a lot of configuration. First, I realized that the DNS was resolving to an IPv6 address, so, I decide to disable IPv6, then, I fell in the error above.
 The problem is, here within  the company network, we use proxy and that´s the problem. Despite the fact that my source list was all ok, I was unable to access any site on 80 port.
The solution applied was to configure a file at /etc/apt/apt.conf.d called ´02proxy with the following script:

Acquire {

HTTP::proxy "http://proxy.xxxxx.local:8080";

}

Everything is fine!!

That´s it. A very simple solution but also very usefull if you need to setup a Linux server behind a web proxy.
 I hope this was informing for you as it was for me!

Cisco ISE - Registrando Nodes

 Uma das coisas que eu valorizo em materiais na internet é quando eles ajudam em pontos específicos de algum problema.
 Eu pressuponho que um técnico deve esgotar todas as possibilidades através dos materiais técnicos fornecidos pelos fabricantes antes de sair perguntando em Blogs. Quando se trata de Cisco, ninguém pode reclamar de material. Se alguem o faz, recomento tentar aprender algo sobre Centrais Telefonicas Philips, Ericsson,etc. Estes fabricantes sim escondem seus materiais em algum cofre dentro da empresa.
 Estou trabalhando em um projeto onde teremos um Cluster de ISEs, primario e secundário. Em uma implantação clássica, estou deixando o primário com Adminstration e Logging e o secundário com Policing. Todo o processo de configuração de um ISE é bem interessante mas não vale a pena escrever um Post sobre isso. Existem muitos materiais disponíveis na internet e eu recomendo os Videos do Lab Minutes. São definitivamente bons.
 Porém, nem sempre você conseguirá tudo o que precisa. Nuancias em seu implantação ou mesmo a forma de fazer, pode lhe trazer surpresas. E aqui entram os Post úteis, como acredito que será este.
 Existem alguns pré requisitos para registrar um novo node. O link abaixo explica ítem a ítem:

http://www.cisco.com/en/US/docs/security/ise/1.0/user_guide/ise10_dis_deploy.html#wp1145033

Ao realizar suas configurações, confira ítem a ítem e tenha certeza que você atende todos os pré requisitos. Se não entender algum deles, entenda isso como um ponto a ser melhorado e estude sobre o assunto. Mais importante que conseguir fazer é entender o que você está fazendo. Isso é fundamental para adminstrar depois de pronto.
Uma vez tendo os requitos atendidos, vamos fazer as configuraçoes.
Duas etapas importantes são:
Criar um usuário admin e colocar nos grupos super admin, rbac admin e system admin
Criar um certificado novo no ISE primário.
Eu briguei com a integração quase um dia todo sem sucesso porque não fiz isso. Usei o usuário de adminstração que eu havia criado na instalação do ISE, esse usuário está apenas no grupo system admin e também usei o certificado default do ISE.
 Esse "pulo do gato" e  os passos que colocarei abaixo, muito provavelmente lhe ajudará a ter os ISEs integrados sem maiores problemas.

 Usuários administradores podem ser criados em :

Administration > Admin Acess >Administrator.

Nesta página são listados os Administradores configurados e a possibilidade de adicionar um novo:

Na imagem acima, vemos o dashboard de criação de Administradores. O único usuário administrador que vemos, foi criado durante o setup inicial. Durante minha tentativa de registrar o segundo node, eu cheguei a usar esse usuário, porem, existe um problema com o mesmo. Como podemos ver em Admin Groups ele pertence apenas ao grupo Super Admin. De acordo com o link indicado acima, os requisitos para o usuário em questão são:
 - Super Admin, System Admin, or RBAC Admin

Desta forma, eu preferi adicionar um novo usuário e usá-lo. Lembrando que isso é necessário apenas no node secundário.

Apos preencher algumas informações básicas, temos que selecionar os grupos.

Criado  o usuário, vamos para a segunda etapa que é criar e trocar os certificados entre os nodes.
 Eu tive um outro problema aqui porque o domínio que configurei durante o setup inicial está incorreto. Ao final do processo, um certificado foi gerado e eu tentei usá-lo, porém, não aceitava por ter havido uma mudança no FQDN.
 Para resolver, criei um novo certificado em ambos os ISEs e importei.

Em Administration > Certificate vamos ter a seguinte tela:

 Para adicionar um novo Certificado, clicar em Add:

  Temos alguns parâmetros interessantes, como o TTL. Quando o certificado é criado no setup inicial, o TTL é 365. Obviamente isso não é desejável. O ideal é um tempo maior.

 A troca dos certificados criados é extremamente simples.

 Na janela onde é criado o certificado é possível ver, além do botão Add, o botão exporte. Desta forma, uma vez criado o certificado, basta fazer o Exporte do mesmo para a máquina local.
 Na janela mostrada acima, podemos ver o botão importe. Ao clicar em importe, podemos mapear o arquivo em nossa máquina e carregar.

 Concluído essas etapas, nos resta apenas sincronizar os ISEs. Para isso, vamos em:

System > Deployment

Entre com o hostname seguido do domínio. O usuário e senha é o user criado como informado acima. Pertencente aos três grupos informados.

Se tudo correr bem, a tela acima será a tela final. Temos dois ISEs integrados.

Como disse, o objetivo deste Artigo é ajudar em uma dificuldade específica. Um tutorial sobre "como subir um ISE do zero" não é produtivo. Existem muitos vídeos ótimos na Internet.
 Eu tive problemas e consegui resolver. Caso alguém tenha alguma outra dificuldade, basta informa ,podemos encontrar uma solução e adicionar ao artigo posteriormente.

High Availability - Com cisco WLC 5508

 Após um longo período sem escrever nada no meu blog, estou de volta e trago um assunto bem interessante para quem gosta de Wi-fi.
 Apenas um breve comentário,  Fiz algumas mudanças na minha vida profissional recentemente mas foi no intuito de adequar ao meu objetivo de focar mais e mais em Wi-fi.
 Recentemente deixei uma posição de Analista de Suporte na empresa AT&T e assumi uma posição de Consultor na empresa Promonlogicalis. Posição voltada para projetos de redes Wireless, mas estou lá para o que der e vier. Quando o assunto é tecnologia de redes, qualquer coisa me interessa.
 Em um dos meus projetos tive a necessidade de implantar um Cluster de Controllers usando HA. A partir das versões 7.3 a Cisco implantou a feature nas Wireless Lan Controllers. Até então, Controllers eram implantadas de forma independentes e na configuracao do AP, em High Availability, era feito os apontamentos para Controllers diferentes afim de conseguir a redundância.

 Obviamente, a possibilidade de Configurar o AP com até três Controllers continua nas Controllers em HA, não houve qualquer diferença nesse aspecto. Essa imagem foi retirada de uma Controller que possui suporte para HA.
  A tela acima nos dá a possibilidade de apontar os APs para até três Cluster de Controller em HA ou para um Cluster e para Controllers em Standalone e assim por diante. Depende da arquitetura que se tenha. O que estou explicando aqui é que a mudança não alterou outros aspectos já existentes.
 A função dessa feature é óbiva. Possibilitar que Controllers trabalhem no esquema Active/Standby, assim como os Firewalls ASA já fazem.
 A versão que utilizei em meu projeto é a 7.4. Nessa versão ainda não é possível fazer Client SSO, apenas AP SSO. Isso significa que a tabela de APs é totalmente replicada entre as  Controllers mas a de Client não.  Ou seja, nas versões anteriores a 7.5, se houver falha em uma Controller, os usuários conectados terão que se reconectar. O ponto positivo é que  não há um downtime dos APs. Como a reconexão de Clients é muito rápido, o ambiente se recupera com muita facilidade e rapidez.

 A configuração de High Availability é simples. Na verdade, se for comprado uma das Controllers como HA SKU, ela já será a standby por default. Caso compre duas controllers normais, veremos a frente que é preciso definir a relação Primary/Secondary.
 Antes das configurações é preciso solicitar ao time de Cabling que passe um cabo adicional interligando as duas Controllers. Esse cabo é um cado direto normal mas é exigido em ambiente com HA. As portas a serem conectadas é identificada com as letras RD de Redundanty Port, com pode ser visto abaixo:

Podemos então observar que as duas portas situadas a esquerda da Controler, possuem funções distintas sendo:
Porta superior esquerda: Service Port
Porta inferior esquerda: Redundanty Port. (Seta em Azul )

 Service Port é usado para gerenciamento da Controller. Seria como uma porta console porem com conexão IP. A Redundancy Port tem a função de "Linkar" as duas Controller que farão parte do cluster.
 A Cisco recomenda que a comunicação entre as duas Controllers para redundancia seja feita em camada dois, não é recomendado roteamento nessa comunicação. Se o projeto prever Controller em datacenters diferentes, é preciso ter um link Lan-to-Lan entre ambos possibilitando uma interligação em camada dois.
Uma vez realizado a conexão física, o próximo passo é configurar.
As Controller com suporte a HA, possui um tipo especial de Interface chamada de Redundancy Management Interface :

 Essa interface precisa ser configurada com um endereço IP. É preciso que esse IP esteja na mesma subnet da Management Interface. Em termos de endereçamento é apenas isso. Agora vamos a configuração do Cluster em si:

Na tela acima temos os parâmetros mostrados. O primeiro deles, Redundancy Management IP é o que informei na figura anterior. Quando o passo anterior for executado, nesse campo que agora aparece com um valor default de 0.0.0.0 irá aparecer com o IP previamente configurado.
 O campo Peer Redundancy Mgmt IP é o IP da outra Controller. Ou seja, é o Redundancy IP da outra Controller que fará parte do cluster. Esse apontamento precisa ser feito em ambas.
 O IP 169.x.x.x não precisa e não tem com ser alterado. A própria Controller irá preenche-lo usando os octetos do endereço adicionado em Redundancy Mgmt IP.
  Após esses passos, é preciso definir a Controller como Primary ou Secondary, caso ela não seja por default através da lincença HA-SKU.
  Apenas esclarecendo que mesmo com HA SKU, a opção de definir como primary e secondary permanece, porem, não é necessário se preocupar. No momento da sincronização, elas saberão se entender sozinhas.
  Por último temos o campo AP SSO. Apenas altere esse campo após todas as configuração prévias estiverem ok. Também é importante validar se as Controllers estejam com conectividade entre si, com o Gateway, ou seja, com a rede em geral.
 Após a alteração do AP SSO de disabled para enabled, em ambas as Controllers, elas irão rebootar e o processo de formação do Cluster terá início. Caso alguma coisa não esteja correta e impeça a sincronização, o acesso às Controller pela interface Web  irá ficar prejudicado. Eu tive esse problema e a solução foi acessar por Console e desativar o AP SSO na mão usando o comando :

config redundancy mode SSO disable

E com isso concluímos esse Post. Como pode ser visto, o processo é simples de compreender e configurar, porém, o resultado é muito vantajoso.
 Como já disse muitas e muitas vezes, rede Wireless há muito deixou de ser uma rede secundária. Impactos na rede Wireless resultam em muitos tickes abertos e muita reclamação porque afeta e muito o cotidiano das pessoas hoje em dia. Em qualquer ambiente corporativo e mesmo fora dele, as pessoas querem mais e mais estarem conectadas a rede.

Aplicando Filtro e Monitorando pacotes em Juniper Parte 2

 No artigo anterior nos falamos sobre filtro no JUNOS e como monitorar o trafico passante pela interface. Ação comum e necessária em trobleshooting de redes.
 Hoje vou mostrar um filtro um pouco mais elaborado. A idéia dessa filtro é bloquear o acesso http ao device e permitir  o resto.
  Vamos a config:

root@Sinapse# edit firewall family inet

[edit firewall family inet]
root@Sinapse# show
filter Block_HTTP {
    term port-80 {
        from {
            source-address {
                192.168.62.0/24;
            }
            protocol tcp;
            destination-port http;
        }
        then {
            reject;
        }
    }
    term Permit_all_else {
        then accept;
    }
}

 Vamos lá. Foi criado um filtro chamado Block_HTTP e dentro desse filtro foram criados dois term. O primeiro term bloqueia acessos vindo da rede 192.168.62.0/24 com protocolo tcp na porta http.
O segundo term não permite nada específico. Porém, a não adicao desse term, causaria todas as portas serem bloqueadas.
Não podemos esquecer que, assim como nas ACL do IOS, os term do  JUNOS também possui um deny any implícito. Desta forma, adicionar um filtro permitindo, após um único filtro bloqueando, é fundamental.


Agora vamos ver os tráfico passando pela interface:









root@Sinapse> monitor traffic detail interface em0 matching "port  80"
Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on em0, capture size 1514 bytes

Reverse lookup for 192.168.62.100 failed (check DNS reachability).
Other reverse lookup failures will not be reported.
Use <no-resolve> to avoid reverse lookups on IP addresses.

02:51:15.038586  In IP (tos 0x0, ttl 128, id 13151, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.62.151.58473 > 192.168.62.100.http: S 3234236900:3234236900(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
02:51:15.295991  In IP (tos 0x0, ttl 128, id 13152, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.62.151.58474 > 192.168.62.100.http: S 1097943701:1097943701(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
02:51:16.327213  In IP (tos 0x0, ttl 128, id 13154, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.62.151.58475 > 192.168.62.100.http: S 2398065096:2398065096(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
02:51:16.581450  In IP (tos 0x0, ttl 128, id 13155, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.62.151.58476 > 192.168.62.100.http: S 2117150508:2117150508(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
02:51:17.982157  In IP (tos 0x0, ttl 128, id 13157, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.62.151.58473 > 192.168.62.100.http: S 3234236900:3234236900(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>

 Como existem outros fluxos passando pela interface, fiz um filtro para capturar apenas a porta 80. O monitor é como o tcpdump e como tal é muito flexível.

 E assim concluo esse artigo. Simples mas de importância em um trobleshooting. A medida que for estudando sobre esse magnífico JUNOS, vou postando mais configurações aqui.

Aplicando Filtro e Monitorando pacotes em Juniper.

 Tenho estudado Juniper nos últimos dias e estou realmente impressionado.  Juniper surpreende em muitos aspectos. Umas das funcionalidades que mais me chamou a impressão, logo de cara, foi a possibilidade de ter um "tcpdump" a nível de Junos com o comando 'monitor traffic interface'. Para quem realiza constantes troubleshooting em equipamentos de redes, essa funcionalidade é realmente uma mão na roda.

root@sre-sc-a> monitor traffic interface em0 detail
Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on em0, capture size 1514 bytes

Reverse lookup for 172.16.1.1 failed (check DNS reachability).
Other reverse lookup failures will not be reported.
Use <no-resolve> to avoid reverse lookups on IP addresses.

20:57:50.855750  In IP (tos 0x0, ttl  64, id 8762, offset 0, flags [none], proto: ICMP (1), length: 84) 172.16.1.2 > 172.16.1.1: ICMP echo request, id 774, seq 0, length 64
20:57:50.855996 Out IP (tos 0x0, ttl 255, id 6372, offset 0, flags [DF], proto: ICMP (1), length: 56) 172.16.1.1 > 172.16.1.2: ICMP host 172.16.1.1 unreachable - admin prohibited filter, length 36
        IP (tos 0x0, ttl  64, id 8762, offset 0, flags [none], proto: ICMP (1), length: 84) 172.16.1.2 > 172.16.1.1: ICMP echo request, id 774, seq 0, length 64
20:57:51.890619  In IP (tos 0xc0, ttl   1, id 8763, offset 0, flags [none], proto: OSPF (89), length: 80) 172.16.1.2 > 224.0.0.5: OSPFv2, Hello, length 60 [len 48]
       
 A saída do comando acima é um  exemplo da funcionalidade. Vejam que a saída é parecida com o tcpdump. Nesse caso, um dos fluxos registrado foi um ping vindo do IP 172.16.1.2 e veja que interessante:
ICMP host 172.16.1.1 unreachable - admin prohibited filter

 O equipamento está avisando que houve um bloqueio devido a uma ACL, ou, Filtro, como é referido pela Juniper. Agora vejamos onde o ping foi originado:

64 bytes from 172.16.1.1: icmp_seq=11 ttl=64 time=29.344 ms
64 bytes from 172.16.1.1: icmp_seq=12 ttl=64 time=9.431 ms
36 bytes from 172.16.1.1: Communication prohibited by filter
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 216b   0 0000  40  01 ff1a 172.16.1.2  172.16.1.1

36 bytes from 172.16.1.1: Communication prohibited by filter
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 216c   0 0000  40  01 ff19 172.16.1.2  172.16.1.1

36 bytes from 172.16.1.1: Communication prohibited by filter
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 216e   0 0000  40  01 ff17 172.16.1.2  172.16.1.1

 Podemos ver que o ping está acontecendo com sucesso até que um filtro foi aplicado no destino. Imediatamente a origem passou a ser avisada que a comunicação foi proibida devido a uma ACL.

 Como é inevitável  a comparação, isso não se vê em equipamentos Cisco.
Existem muitas situações em que nos vemos obrigados a provar que não há bloqueio em Firewall. Com Juniper, isso não se faz necessário.

 Vamos ver agora como criar um Filtro e como aplicar esse filtro.



edit firewall filter sample-filter term block-bad-subnet from

 Essa primeira linha cria um filtro chamado sample-filter. Ao inves de linhas, como  o IOS, o Junos usa 'term' para diferenciar as váras entradas em um filtro. Em nosso exemplo, usamos o term block-bad-subner


set source-address 172.16.1.2/32




 Com essa linha, definimos o trafico que queremos permitir ou bloquear. Reparem que, até aqui, ainda não definimos qual vai ser a política.

edit firewall filter sample-filter term block-bad-subnet then reject


Nessa linha,então, definimos que nossa política é reject.

edit interfaces em0 unit 0 family inet filter
set input sample-filter

Por último, nós aplicamos o filtro a uma das interfaces.


64 bytes from 172.16.1.1: icmp_seq=10 ttl=64 time=1.393 ms
64 bytes from 172.16.1.1: icmp_seq=11 ttl=64 time=29.344 ms
64 bytes from 172.16.1.1: icmp_seq=12 ttl=64 time=9.431 ms
36 bytes from 172.16.1.1: Communication prohibited by filter
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 216b   0 0000  40  01 ff1a 172.16.1.2  172.16.1.1

36 bytes from 172.16.1.1: Communication prohibited by filter
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 216c   0 0000  40  01 ff19 172.16.1.2  172.16.1.1

 E aqui podemos ver o ping informando que está sendo barrado por um filtro.


Desta forma concluímos nosso primeiro post técnico sobre Juniper. Como disse acima, Juniper é surpreendente.

Emulando JUNOS no QEMU em Windows 7.

   QEMU, em conjunto com GNS3, é uma das maiores invensões em termos de software que eu já vi. Se não pela complexidade, é pela importância. Todos que buscam aperfeiçoamento na área de redes, como eu, e não dispoe de recurso para comprar equipamentos reais,como eu, GNS3 é uma plataforma fundamental.
 Hoje vou escrever um artigo rápido para ajudar quem tiver interessado em emular o Sistema Operacional JUNOS com QEMU.
 Eu levei algum tempo para conseguir emular o meu, mas seguindos as dicas não é complicado.
Antes de qualquer coisa é preciso ter os seguintes softwares:

freebsd-4.11.img
junos-auto-fix-checkpic 
 jinstall-9.6R1.13-domestic-signed.tgz.

Pode ser que a versão do jinstall encontrada na Internet seja diferente dessa mas isso não é um problema.

Não é obrigatório, mas os tutoriais na Internet recomendam alterar o nome da imagem :

copy freebsd-4.11.img olive-9.6R1.13.img

Descompacte todos os programas acima em uma pasta. Importante que esta pasta tenha o programa junos-auto-fix-checkpic, a pasta "bin" que aparecerá assim que o software for descompactado. Alem da imagem criada no passo anterior.
   Na pasta onde for descompactado os programas acima, execute o seguinte comando

junos-auto-fix-checkpic-v1.0.bat jinstall-9.6R1.13-domestic-signed.tgz

Copie o arquivo gerado para a pasta onde fica o QEMU e
execute o seguinte comando. No meu caso, o QEMU fica em: C:\Program Files\GNS3>

qemu.exe  -m 1G -hda olive-9.6R1.13.img -cdrom jinstall-9.6R1.13-domestic-olive.iso

 Se tudo correu bem até aqui, o QEMU irá bootar a imagem criada. Ele irá executar o FreeBSD como se fosse um CD em um driver. É preciso logar como root usando usuário root e senha root.
 Uma vez logado no FreeBSD, faça a montagem do CDROM:

mount /cdrom

Feito isso, vem o último e mais emocionante passo:

pkg_add -f /cdrom/jinstall-9.6R1.13-domestic-olive.tgz

Com esse comando, você irá instalar o JUNOS no FreeBSD.
 Esse comando leva um bom tempo, algo em torno de meia hora e o sistema pode pedir para rebootar. Pode ser usado o comando halt para isso. No final, uma imagem de quase um Giga é criado.

 A partit daí, basta configurar o GNS3 para usar essa imagem e você terá um JUNOS rodando em seu PC.

 

 
 Detalhe, o JUNOS demora uma enormidade para subir e consome muita memoria e muita CPU. Esteja preparado para isso e aproveite os estudos.