[GTER] Implantação IGP / OSPF
Jonatas M. Victor
jonatasmv at gmail.com
Tue Nov 9 14:17:30 -02 2010
Humm é um problema realmente isso. E para resolver isso teria que
fazer nbma com ips unicast?
2010/11/9 Danilo Bedani <dbedani at gmail.com>:
> Os equipamentos M5 possuem uma função 'Airmax' proprietário da Ubiquiti. Com
> isso habilitado, os pacotes Multcast responsáveis pelo tráfego do OSPF são
> dropados, gerando assim uma total instabilidade de neighbors..
>
> 2010/11/9 Jonatas M. Victor <jonatasmv at gmail.com>
>>
>> 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
>
>
>
> --
> 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