[GTER] Implantação IGP / OSPF

Jonatas M. Victor jonatasmv at gmail.com
Tue Nov 9 13:07:36 -02 2010 

 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

More information about the gter mailing list