[GTER] Implantação IGP / OSPF
Diogo Montagner
diogo.montagner at gmail.com
Tue Nov 9 13:07:29 -02 2010
Oi Danilo,
ele deveria funcionar desta forma pois este comportamento está descrito na RFC.
Item 7.3 da RFC2328 (http://www.rfc-editor.org/rfc/rfc2328.txt):
" The Designated Router is elected by the Hello Protocol. A
router's Hello Packet contains its Router Priority, which is
configurable on a per-interface basis. In general, when a
router's interface to a network first becomes functional, it
checks to see whether there is currently a Designated Router for
the network. If there is, it accepts that Designated Router,
regardless of its Router Priority. (This makes it harder to
predict the identity of the Designated Router, but ensures that
the Designated Router changes less often. See below.)
Otherwise, the router itself becomes Designated Router if it has
the highest Router Priority on the network. A more detailed
(and more accurate) description of Designated Router election is
presented in Section 9.4.
"
As novas eleições podem estar sendo estimuladas por instabilidade em
ambos (DR e BDR). Mas se a rede está estável, não deve haver nova
eleição de DR/BDR com a entrada de uma nova interface com prioridade
maior.
[]s
./diogo -montagner
2010/11/9 Danilo Bedani <dbedani at gmail.com>:
> 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
>
More information about the gter
mailing list