[GTER] Implantação IGP / OSPF

Danilo Bedani dbedani at gmail.com
Tue Nov 9 13:56:42 -02 2010


Quanto a RFC, é isso mesmo! Se manda, deveria ser assim! hehe... mas como
disse, é uma característica do MK que há tempos percebo...

Jonatas, hoje tenho rodando aqui um server de 'borda' DR com Quagga e mais
15 Routerboards com MK... a rede é estável, não há queda de neighbors,
re-eleição de DR/BDR... Aconselho o uso.

Um detalhe... Jonatas, vc disse que possui uma rede via rádio... os enlaces
estão sendo feito com qual radio? Utiliza algum equipamento Ubiquiti M5?

Abraço!

2010/11/9 Jonatas M. Victor <jonatasmv at gmail.com>

>  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
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 
Danilo Bedani
dbedani at gmail.com



More information about the gter mailing list