[GTER] Implantação IGP / OSPF
Danilo Bedani
dbedani at gmail.com
Tue Nov 9 09:16:41 -02 2010
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