[GTER] Implantação IGP / OSPF
Jonatas M. Victor
jonatasmv at gmail.com
Tue Nov 9 14:03:01 -02 2010
A rede nesse ponto é toda Fast e Fibra. Mas atrás dos routers é OSPF
que vai ser expandido depois em areas
para cima da rede Wireless e rede cabeada. Qual seria o problema com os M5?
2010/11/9 Danilo Bedani <dbedani at gmail.com>:
> Quanto a RFC, é isso mesmo! Se manda, deveria ser assim! hehe... mas como
> disse, é uma característica do MK que há tempos percebo...
>
> Jonatas, hoje tenho rodando aqui um server de 'borda' DR com Quagga e mais
> 15 Routerboards com MK... a rede é estável, não há queda de neighbors,
> re-eleição de DR/BDR... Aconselho o uso.
>
> Um detalhe... Jonatas, vc disse que possui uma rede via rádio... os enlaces
> estão sendo feito com qual radio? Utiliza algum equipamento Ubiquiti M5?
>
> Abraço!
>
> 2010/11/9 Jonatas M. Victor <jonatasmv at gmail.com>
>>
>> Sim para os roteadores que não são principais e eu já setei alguns a
>> zero. Para eles nunca serem eleitos.
>> E na opnião de vocês o funcionamento do protocolo é tranquilo no
>> dia-a-dia?
>>
>> 2010/11/9 Rafael Ganascim <rganascim at gmail.com>:
>> > Para remediar o caso da nova eleição, você poderia deixar todos os
>> > roteadores que você não quer que sejam nem DR nem BDR com prioridade 0.
>> > Assim, eles estando ou não na rede não haverá uma nova eleição, pois se
>> > tornam inelegíveis.
>> >
>> >
>> > Em 9 de novembro de 2010 09:16, Danilo Bedani <dbedani at gmail.com>
>> > escreveu:
>> >
>> >> Diogo, concordo com vc, a teoria é essa pra equipamentos Cisco e creio
>> >> que
>> >> Juniper tbm, pois nunca trabalhei com estes.
>> >>
>> >> Jonatas, no caso das Routerboards Mikrotik, a condição explicada pelo
>> >> Diogo
>> >> não se aplica, pois assim que um router com um ID mais alto sobe, os
>> >> RouterOS promovem uma nova eleição, e o ID mais alto vence,
>> >> independente da
>> >> ordem de chegada.
>> >>
>> >> Tente subir os routers com prioridade maior, que voce verá que os MK
>> >> irão
>> >> re-eleger o DR/BDR...
>> >> se a sua instabilidade permanecer, tente baixar a versão do quagga...
>> >>
>> >> Abraço.
>> >>
>> >>
>> >> 2010/11/9 Jonatas M. Victor <jonatasmv at gmail.com>
>> >>
>> >> > Olá Danilo,
>> >> >
>> >> > Pode ser algo com a última versão do Quagga. Estou usando a versão
>> >> > quagga-0.99.17, no BGP está 100% mas no ospf
>> >> > muitas dores de cabeça.
>> >> > Esse router que eu mandei a conf é um dos dr/other da area 0, no dr
>> >> > eu setei a prioridade na interface que está com ospf para 10
>> >> > e um segundo router eu setei como 5 para ficar esses 2 como DR e BDR.
>> >> >
>> >> > Sem adicionar meus 2 routers principais até o momento estou estável:
>> >> >
>> >> > # show ip ospf neighbor
>> >> >
>> >> > Neighbor ID Pri State Dead Time Address
>> >> > Interface RXmtL RqstL DBsmL
>> >> > 192.168.0.35 0 2-Way/DROther 30.214s 192.168.0.35
>> >> > sk0:192.168.0.40 0 0 0
>> >> > 192.168.0.50 1 2-Way/DROther 35.315s 192.168.0.50
>> >> > sk0:192.168.0.40 0 0 0
>> >> > 192.168.0.52 1 2-Way/DROther 35.315s 192.168.0.52
>> >> > sk0:192.168.0.40 0 0 0
>> >> > 192.168.0.54 0 2-Way/DROther 35.316s 192.168.0.54
>> >> > sk0:192.168.0.40 0 0 0
>> >> > 192.168.0.58 1 2-Way/DROther 30.632s 192.168.0.58
>> >> > sk0:192.168.0.40 0 0 0
>> >> > 192.168.0.59 1 Full/Backup 30.213s 192.168.0.59
>> >> > sk0:192.168.0.40 0 0 0
>> >> > 192.168.0.60 1 Full/DR 30.223s 192.168.0.60
>> >> > sk0:192.168.0.40 0 0 0
>> >> >
>> >> > Pretendo adicionar os 2 routers com prioridades diferentes para eles
>> >> > assumirem. Mas agora nesse
>> >> > cenário se eu inserir primeiro um router com prioridade 10 terá uma
>> >> > nova eleição? Ou eu teria que
>> >> > reiniciar o processo do .60 para que o novo router com prioridade 10
>> >> > assuma?
>> >> >
>> >> > 2010/11/8 Diogo Montagner <diogo.montagner at gmail.com>:
>> >> > > Não existe nova eleição de DR se um roteador com prioridade mais
>> >> > > alta
>> >> > > entra no processo.
>> >> > >
>> >> > > O processo é o seguinte:
>> >> > >
>> >> > > BDR se torna DR em caso de falha do DR. Ocorre uma nova eleição
>> >> > > para
>> >> > > definir o novo BDR. Se o roteador que tem a maior prioridade para
>> >> > > eleição de DR volte a ficar online, ele não será eleito a DR até
>> >> > > que
>> >> > > ocorra uma nova falha no DR.
>> >> > >
>> >> > > No caso do ISIS é exatamente o contrário: a eleição do DIS é
>> >> > > preemptiva, isto é, se um roteador com maior prioridade volte a
>> >> > > ficar
>> >> > > online, ele será automaticamente eleito o novo DIS do segmento.
>> >> > >
>> >> > > []s
>> >> > >
>> >> > > ./diogo -montagner
>> >> > >
>> >> > >
>> >> > >
>> >> > > 2010/11/9 Danilo Bedani <dbedani at gmail.com>:
>> >> > >> Jonatas,
>> >> > >>
>> >> > >> Na configuração do quagga, qual a prioridade do router que voce
>> >> > >> deseja
>> >> > que
>> >> > >> fique como DR? Isto não está especificado! Lembrando que a
>> >> > >> prioridade
>> >> > padrão
>> >> > >> para qualquer dispositivo executando o ospf é 1. A prioridade para
>> >> > eleição
>> >> > >> do DR/BDR vem do maior endereço IP configurado na caixa. Se o
>> >> > >> maior IP
>> >> > >> estiver em uma interface que estiver flapando, o ID da caixa vai
>> >> > >> ficar
>> >> > se
>> >> > >> alternando.. portando, a melhor maneira é definir o ID e Priority
>> >> > >> das
>> >> > caixas
>> >> > >> que voce deseja que fiquem como DR/BDR manualmente.
>> >> > >>
>> >> > >> Outra informação... qual a versão do quagga está utilizando? Já
>> >> > >> tive
>> >> > esse
>> >> > >> mesmo cenário com a ultima versão disponivel, há uns 4 meses
>> >> > >> atras,
>> >> qdo
>> >> > fui
>> >> > >> migrar um router/quagga... hoje estou usando a version 0.99.15 sem
>> >> > nenhum
>> >> > >> tipo de problema (pois é, na época tive que fazer um "downgrade"),
>> >> > >> com
>> >> o
>> >> > >> mesmo cenário (quagga, routerboar, rede broadcast via rádio,
>> >> > >> netmask
>> >> > /27)...
>> >> > >>
>> >> > >> espero ter ajudado!
>> >> > >>
>> >> > >>
>> >> > >> 2010/11/5 Jonatas M. Victor <jonatasmv at gmail.com>
>> >> > >>
>> >> > >>> Fazendo testes agora, estabeleci todos os enlaces com broadcast
>> >> > >>> e
>> >> > >>> tudo funcional e fui testando
>> >> > >>> router por router e ao reiniciar o DR que estava igual para todos
>> >> > >>> na
>> >> > >>> nova eleição 2 router pegaram
>> >> > >>> um router X e outros um router Y que era o mesmo BDR anterior.
>> >> > >>> Um
>> >> > >>> router ficou com as rotas inativas
>> >> > >>> com custo infinito. Nesse lab tem 4 FreeBSD com Quagga e 4
>> >> > >>> Routerboards com Mikrotik ligados diretamente
>> >> > >>> no switch. Seria essa a reação normal ?
>> >> > >>>
>> >> > >>> Conf exemplo quagga:
>> >> > >>>
>> >> > >>> interface sk0
>> >> > >>> ip address 192.168.1.60/27
>> >> > >>> ip address 192.168.1.61/32
>> >> > >>> ip ospf authentication-key teste
>> >> > >>> ipv6 nd suppress-ra
>> >> > >>>
>> >> > >>> router ospf
>> >> > >>> ospf router-id 192.168.1.60
>> >> > >>> ospf abr-type standard
>> >> > >>> log-adjacency-changes
>> >> > >>> redistribute kernel
>> >> > >>> redistribute connected
>> >> > >>> redistribute static
>> >> > >>> network 192.168.1.32/27 area 0.0.0.0
>> >> > >>> area 0.0.0.0 authentication
>> >> > >>>
>> >> > >>> Conf MKT:
>> >> > >>>
>> >> > >>> /routing ospf instance
>> >> > >>> set default comment="" disabled=no distribute-default=never
>> >> > >>> in-filter=ospf-in metric-bgp=auto \
>> >> > >>> metric-connected=20 metric-default=1 metric-other-ospf=auto
>> >> > >>> metric-rip=20 metric-static=20 \
>> >> > >>> name=default out-filter=ospf-out redistribute-bgp=no
>> >> > >>> redistribute-connected=no \
>> >> > >>> redistribute-other-ospf=no redistribute-rip=no
>> >> > >>> redistribute-static=no router-id=192.168.1.35
>> >> > >>> /routing ospf area
>> >> > >>> set backbone area-id=0.0.0.0 comment="" disabled=no
>> >> > >>> instance=default
>> >> > >>> name=backbone type=default
>> >> > >>> /routing ospf interface
>> >> > >>> add authentication=simple authentication-key=teste
>> >> > >>> authentication-key-id=1 comment="" cost=10 \
>> >> > >>> dead-interval=40s disabled=no hello-interval=10s instance-id=0
>> >> > >>> interface=ether1 network-type=\
>> >> > >>> broadcast passive=no priority=1 retransmit-interval=5s
>> >> > >>> transmit-delay=1s use-bfd=no
>> >> > >>> /routing ospf network
>> >> > >>> add area=backbone comment="" disabled=no network=192.168.1.32/27
>> >> > >>>
>> >> > >>> Posso estar errando em algum ponto que não vejo?
>> >> > >>>
>> >> > >>> 2010/11/5 Jonatas M. Victor <jonatasmv at gmail.com>:
>> >> > >>> > Baixei toda a rede ospf e estou levantando agora passo a passo
>> >> para
>> >> > >>> > tentar encontrar o erros. Estou
>> >> > >>> > fazendo tudo com broadcast agora.
>> >> > >>> >
>> >> > >>> > 2010/11/4 Jonatas M. Victor <jonatasmv at gmail.com>:
>> >> > >>> >> Eu já revisei o switch e não tem nada habilitado, até tenho
>> >> > >>> >> que
>> >> > >>> >> habilitar algumas propriedades
>> >> > >>> >> após resolver esse problema. Para ethernet diretamente num
>> >> > >>> >> switch
>> >> > com
>> >> > >>> >> um agrupamento de
>> >> > >>> >> vlan untag nas portas tendo 9 routers. A melhor implantação
>> >> > >>> >> seria
>> >> > >>> >> broadcast ou nbma ?
>> >> > >>> >>
>> >> > >>> >> 2010/11/3 Ronaldo Cardoso <ronaldoc at gmail.com>:
>> >> > >>> >>> Olá Jonatas,
>> >> > >>> >>>
>> >> > >>> >>> Você tem alguma implementação de segurança neste switch,
>> >> > >>> >>> controle
>> >> > de
>> >> > >>> storm
>> >> > >>> >>> de broadcast ou alguma coisa do tipo?
>> >> > >>> >>>
>> >> > >>> >>> Atenciosamente,
>> >> > >>> >>> Ronaldo Cardoso
>> >> > >>> >>>
>> >> > >>> >>> 2010/11/2 Jonatas M. Victor <jonatasmv at gmail.com>
>> >> > >>> >>>>
>> >> > >>> >>>> Olá, os links são um switch vlan local nada demais, tudo
>> >> ethernet.
>> >> > O
>> >> > >>> >>>> maior problema pode ser instabilidade
>> >> > >>> >>>> no software quagga do que no protocolo em si. Em alguns
>> >> > >>> >>>> testes
>> >> que
>> >> > eu
>> >> > >>> >>>> fiz parece que o problema é usar o quagga
>> >> > >>> >>>> com broadcast. Usando nbma parece estar mais estável. Estou
>> >> > >>> >>>> em
>> >> > testes
>> >> > >>> >>>> ainda. Acho que em cima de ethertnet
>> >> > >>> >>>> puramente não deveria ter problemas dessa forma.
>> >> > >>> >>>>
>> >> > >>> >>>> 2010/11/1 Gustavo Santos <gustkiller at gmail.com>:
>> >> > >>> >>>> > Qual o tipo de enlace que você utiliza? não esta ocorrendo
>> >> > flapping
>> >> > >>> >>>> > nestas
>> >> > >>> >>>> > interfaces? Pois não é tão comum instabilidade no OSPF a
>> >> > >>> >>>> > não
>> >> ser
>> >> > que
>> >> > >>> >>>> > seus
>> >> > >>> >>>> > links estejam instáveis.
>> >> > >>> >>>> >
>> >> > >>> >>>> > Em 1 de novembro de 2010 14:36, Jonatas M. Victor <
>> >> > >>> jonatasmv at gmail.com>
>> >> > >>> >>>> > escreveu:
>> >> > >>> >>>> >>
>> >> > >>> >>>> >> Sim a parte da Area 0 entendi como funciona. Será que
>> >> > >>> >>>> >> dentro
>> >> > de um
>> >> > >>> /27
>> >> > >>> >>>> >> com
>> >> > >>> >>>> >> neighbors específicados ficaria mais estável que depender
>> >> > >>> >>>> >> de
>> >> > >>> broadcast
>> >> > >>> >>>> >> e para migrar
>> >> > >>> >>>> >> hoje trabalhandeo de broadcast para neigbors configurados
>> >> teria
>> >> > que
>> >> > >>> >>>> >> fazer todos juntos
>> >> > >>> >>>> >> ou poderia ser migrado um a um e sendo estabelecido o
>> >> > >>> >>>> >> peer?
>> >> > >>> >>>> >>
>> >> > >>> >>>> >> 2010/11/1 Rubens Kuhl <rubensk at gmail.com>:
>> >> > >>> >>>> >> > O mais estável seriam ligações ponto-a-ponto (/30 em
>> >> > >>> >>>> >> > IPv4 e
>> >> > >>> OSPFv2)
>> >> > >>> >>>> >> > entre os roteadores configurado de forma a não haver
>> >> > >>> >>>> >> > DR/BDR
>> >> > >>> >>>> >> > (Designated Router/Backup Designated Router) em nenhuma
>> >> > >>> >>>> >> > das
>> >> > >>> conexões.
>> >> > >>> >>>> >> > Com ponto-a-ponto não é necessário especificar
>> >> > >>> >>>> >> > neighbor,
>> >> mas
>> >> > se
>> >> > >>> >>>> >> > houverem links Wi-Fi pode ser melhor mesmo especificar
>> >> > neighbor e
>> >> > >>> não
>> >> > >>> >>>> >> > depender mais de multicast/broadcast.
>> >> > >>> >>>> >> >
>> >> > >>> >>>> >> > Um ponto que pode estar te confundindo é que a área 0
>> >> > >>> >>>> >> > não é
>> >> > uma
>> >> > >>> única
>> >> > >>> >>>> >> > sub-net, ela é o conjunto de sub-nets designada à área
>> >> > >>> >>>> >> > 0
>> >> > mesmo
>> >> > >>> que
>> >> > >>> >>>> >> > com
>> >> > >>> >>>> >> > comunicação indireta.
>> >> > >>> >>>> >> >
>> >> > >>> >>>> >> >
>> >> > >>> >>>> >> > Rubens
>> >> > >>> >>>> >> >
>> >> > >>> >>>> >> >
>> >> > >>> >>>> >> >
>> >> > >>> >>>> >> > 2010/11/1 Jonatas M. Victor <jonatasmv at gmail.com>:
>> >> > >>> >>>> >> >> Srs,
>> >> > >>> >>>> >> >>
>> >> > >>> >>>> >> >> Estou trabalhando na melhoria do meu IGP implantando
>> >> OSPF.
>> >> > Mas
>> >> > >>> >>>> >> >> estou tendo instabilidades em um ponto
>> >> > >>> >>>> >> >> crítico que seria a area 0 ( backbone ). To com todos
>> >> > >>> >>>> >> >> os
>> >> > routers
>> >> > >>> >>>> >> >> falando OSPF c/ quagga, mikrotik e cisco. Dois
>> >> > >>> >>>> >> >> routers falando BGP externo e repassando para interna
>> >> > >>> >>>> >> >> OSPF
>> >> > mas
>> >> > >>> >>>> >> >> somente
>> >> > >>> >>>> >> >> routa default ainda não estou repassando
>> >> > >>> >>>> >> >> as rotas do BGP. Mas qual seria a implementação mais
>> >> > estávei?
>> >> > >>> Estou
>> >> > >>> >>>> >> >> utilizando hoje com broadcast mas estou tendo
>> >> > >>> >>>> >> >> instabilidades ao reiniciar algum router da area todos
>> >> > >>> >>>> >> >> os
>> >> > >>> adjacentes
>> >> > >>> >>>> >> >> caem mas não voltam como deveriam fazer o processo.
>> >> > >>> >>>> >> >> Será que usando OSPF sem broadcast especificando o
>> >> > >>> >>>> >> >> neigbor
>> >> > seria
>> >> > >>> >>>> >> >> mais
>> >> > >>> >>>> >> >> estavel? Como o pessoal tem configurado
>> >> > >>> >>>> >> >> geralmente?
>> >> > >>> >>>> >> >>
>> >> > >>> >>>> >> >> Obrigado,
>> >> > >>> >>>> >> >>
>> >> > >>> >>>> >> >> --
>> >> > >>> >>>> >> >> .:Abraços:.
>> >> > >>> >>>> >> >>
>> >> > >>> >>>> >> >> <<< Jonatas M. Victor >>>
>> >> > >>> >>>> >> >> jonatas at jmv.eti.br / jonatasmv at gmail.com
>> >> > >>> >>>> >> >> UIN: 138431258 / MSN: jonatasmv at msn.com
>> >> > >>> >>>> >> >> BSD User: BSD051240 / Linux User: #278922
>> >> > >>> >>>> >> >> --
>> >> > >>> >>>> >> >> gter list
>> >> https://eng.registro.br/mailman/listinfo/gter
>> >> > >>> >>>> >> >>
>> >> > >>> >>>> >> > --
>> >> > >>> >>>> >> > gter list
>> >> > >>> >>>> >> > https://eng.registro.br/mailman/listinfo/gter
>> >> > >>> >>>> >> >
>> >> > >>> >>>> >>
>> >> > >>> >>>> >>
>> >> > >>> >>>> >>
>> >> > >>> >>>> >> --
>> >> > >>> >>>> >> .:Abraços:.
>> >> > >>> >>>> >>
>> >> > >>> >>>> >> <<< Jonatas M. Victor >>>
>> >> > >>> >>>> >> jonatas at jmv.eti.br / jonatasmv at gmail.com
>> >> > >>> >>>> >> UIN: 138431258 / MSN: jonatasmv at msn.com
>> >> > >>> >>>> >> BSD User: BSD051240 / Linux User: #278922
>> >> > >>> >>>> >> --
>> >> > >>> >>>> >> gter list
>> >> > >>> >>>> >> https://eng.registro.br/mailman/listinfo/gter
>> >> > >>> >>>> >
>> >> > >>> >>>> >
>> >> > >>> >>>> >
>> >> > >>> >>>> > --
>> >> > >>> >>>> > Gustavo Santos
>> >> > >>> >>>> > Analista de Redes
>> >> > >>> >>>> > CCNA , MTCNA , JUNCIA-ER
>> >> > >>> >>>> >
>> >> > >>> >>>> >
>> >> > >>> >>>>
>> >> > >>> >>>>
>> >> > >>> >>>>
>> >> > >>> >>>> --
>> >> > >>> >>>> .:Abraços:.
>> >> > >>> >>>>
>> >> > >>> >>>> <<< Jonatas M. Victor >>>
>> >> > >>> >>>> jonatas at jmv.eti.br / jonatasmv at gmail.com
>> >> > >>> >>>> UIN: 138431258 / MSN: jonatasmv at msn.com
>> >> > >>> >>>> BSD User: BSD051240 / Linux User: #278922
>> >> > >>> >>>> --
>> >> > >>> >>>> gter list https://eng.registro.br/mailman/listinfo/gter
>> >> > >>> >>>
>> >> > >>> >>>
>> >> > >>> >>>
>> >> > >>> >>> --
>> >> > >>> >>> Abraços
>> >> > >>> >>> Ronaldo Cardoso
>> >> > >>> >>>
>> >> > >>> >>> "Saying, don't worry about a thing. Cause every little thing
>> >> > >>> >>> is
>> >> > gonna
>> >> > >>> be all
>> >> > >>> >>> right!"
>> >> > >>> >>>
>> >> > >>> >>>
>> >> > >>> >>>
>> >> > >>> >>
>> >> > >>> >>
>> >> > >>> >>
>> >> > >>> >> --
>> >> > >>> >> .:Abraços:.
>> >> > >>> >>
>> >> > >>> >> <<< Jonatas M. Victor >>>
>> >> > >>> >> jonatas at jmv.eti.br / jonatasmv at gmail.com
>> >> > >>> >> UIN: 138431258 / MSN: jonatasmv at msn.com
>> >> > >>> >> BSD User: BSD051240 / Linux User: #278922
>> >> > >>> >>
>> >> > >>> >
>> >> > >>> >
>> >> > >>> >
>> >> > >>> > --
>> >> > >>> > .:Abraços:.
>> >> > >>> >
>> >> > >>> > <<< Jonatas M. Victor >>>
>> >> > >>> > jonatas at jmv.eti.br / jonatasmv at gmail.com
>> >> > >>> > UIN: 138431258 / MSN: jonatasmv at msn.com
>> >> > >>> > BSD User: BSD051240 / Linux User: #278922
>> >> > >>> >
>> >> > >>>
>> >> > >>>
>> >> > >>>
>> >> > >>> --
>> >> > >>> .:Abraços:.
>> >> > >>>
>> >> > >>> <<< Jonatas M. Victor >>>
>> >> > >>> jonatas at jmv.eti.br / jonatasmv at gmail.com
>> >> > >>> UIN: 138431258 / MSN: jonatasmv at msn.com
>> >> > >>> BSD User: BSD051240 / Linux User: #278922
>> >> > >>> --
>> >> > >>> gter list https://eng.registro.br/mailman/listinfo/gter
>> >> > >>>
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >> --
>> >> > >> Danilo Bedani
>> >> > >> dbedani at gmail.com
>> >> > >> --
>> >> > >> gter list https://eng.registro.br/mailman/listinfo/gter
>> >> > >>
>> >> > > --
>> >> > > gter list https://eng.registro.br/mailman/listinfo/gter
>> >> > >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > .:Abraços:.
>> >> >
>> >> > <<< Jonatas M. Victor >>>
>> >> > jonatas at jmv.eti.br / jonatasmv at gmail.com
>> >> > UIN: 138431258 / MSN: jonatasmv at msn.com
>> >> > BSD User: BSD051240 / Linux User: #278922
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Danilo Bedani
>> >> dbedani at gmail.com
>> >> --
>> >> gter list https://eng.registro.br/mailman/listinfo/gter
>> >>
>> > --
>> > gter list https://eng.registro.br/mailman/listinfo/gter
>> >
>>
>>
>>
>> --
>> .:Abraços:.
>>
>> <<< Jonatas M. Victor >>>
>> jonatas at jmv.eti.br / jonatasmv at gmail.com
>> UIN: 138431258 / MSN: jonatasmv at msn.com
>> BSD User: BSD051240 / Linux User: #278922
>> --
>> gter list https://eng.registro.br/mailman/listinfo/gter
>
>
>
> --
> Danilo Bedani
> dbedani at gmail.com
>
--
.:Abraços:.
<<< Jonatas M. Victor >>>
jonatas at jmv.eti.br / jonatasmv at gmail.com
UIN: 138431258 / MSN: jonatasmv at msn.com
BSD User: BSD051240 / Linux User: #278922
More information about the gter
mailing list