[GTER] Implantação IGP / OSPF
Jonatas M. Victor
jonatasmv at gmail.com
Tue Nov 9 08:03:39 -02 2010
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
More information about the gter
mailing list