[GTER] Implantação IGP / OSPF
Danilo Bedani
dbedani at gmail.com
Tue Nov 9 14:12:11 -02 2010
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
More information about the gter
mailing list