[GTER] Implantação IGP / OSPF

Diogo Montagner diogo.montagner at gmail.com
Mon Nov 8 23:39:51 -02 2010 

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
>

More information about the gter mailing list