[GTER] Implantação IGP / OSPF
Danilo Bedani
dbedani at gmail.com
Tue Nov 9 14:21:00 -02 2010
É uma alternativa, ou então desabilitar o AirMax! Que não muda nada o
throughput do rádio-enlace, até aumenta.
Se precisar de mais alguma informação, creio que seja interessante mantermos
contato em pvt...
2010/11/9 Jonatas M. Victor <jonatasmv at gmail.com>
> 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
>
--
Danilo Bedani
dbedani at gmail.com
More information about the gter
mailing list