[GTER] RES: Cisco ASR 1006

[Ricardo Oliveira]

Mileto não foi sugerido nenhuma versão para a correção, veja a resposta da
Juniper.

Hi Ricardo,

Today I was able to decode the vmcore.1 uploaded to the case and confirm
that the issue is hitting the PR :
https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR1137955 which
is public and was reported before and closed as irreproducible

I found out the PR before decode the core-dump but today we confirmed the
match after decoded it, I went through the PR documentation and did not
find any workaround / solution for this below are  some details on the
reason why the crash happens:



* For every IFL that gets configured, depending on the protocol/config, a
destination route gets created and it gets deleted as soon as the

underlying IFL gets deleted. Also when for eg. there is a TCP connection
towards the dest, there is a clone route getting created. Clone

route is generally created for TCP/multicast destination only.( Tech pubs
link ref. for clone route :

http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/
 command-summary/show-route-forwarding-table.html).

* In the base configuration, there was a BGP session contributing to the
generation of the clone route.

* The clone routes have its associated expiry time. If the associated
IFL/destination route gets deleted, the clone route will still remain in

the routing-table till the timer expires.

* In the commit rollback compare, I see the modification of BGP neighbor
was done. This would trigger a deletion of the routes as sociated

with the routing-table and will get re-created and associated with the
table.

* During this operation, we might see the possible condition of clone
routes being present in the routing-table while the parent destination

route is cleaned up.

* Subsequently while deleting the route index, the cleaning up of
clone-routes would be triggered and it will search for an route on

same ifl, but ifl is not present now.( Because I see the change to the IFL
also).

* Hence, this hits a null value and triggers a panic.





One workaround I would think here is, before adding any configuration after
deleting the existing one, make sure there is no clone route present in the
forwarding table.



This issue was not reproduced in lab after multiple attempts. Closing this
case as un-reproducible.

Grato.
Ricardo Freitas.

Em 9 de junho de 2016 22:03, Mileto Tales <miletotalesgter at gmail.com>
escreveu:

> Olá Ricardo,
>
> no PR não consta fix em nenhuma versão, o JTAC lhe informou qual versão o
> bug está corrigido?
>
>
>
> > On 9 de jun de 2016, at 18:12, Ricardo Oliveira <ricardo.btu at gmail.com>
> wrote:
> >
> > Boa noite,
> >
> > Ontem também tivemos uma surpresa com um MX80, as 18:50 horário de pico,
> > procedimento trivial, desativamos uma unit e o danado rebootou, o pior é
> o
> > tempo para subir as rotas.
> >
> >
> https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR1137955
> >
> > Grato.
> > Ricardo Freitas
> >
> >
> > Em 9 de junho de 2016 17:52, Eduardo Schoedler <listas at esds.com.br>
> > escreveu:
> >
> >> Em 9 de junho de 2016 17:37, Rubens Kuhl <rubensk at gmail.com> escreveu:
> >>>> Também estou rodando uma versão 14.2R5 em outro roteador (com
> >>>> promessas de que essa versão iria convergir mais rapidamente quando
> >>>> houvesse uma queda de circuito), começaram muitos flaps de bgp sem
> >>>> motivos aparentes. Até estou rodando um traceoptions nele para tentar
> >>>> descobrir a causa.
> >>>> Mas desliguei umas sessões bgp e movi outras para outro roteador,
> >>>> aparentemente ele normalizou.
> >>>> Coisa que a 13.3R8 aguentava tranquilamente, sem soluços.
> >>>
> >>> O JTAC recomenda 13.3R9 para os roteadores Juniper MX-n com n < 100...
> >> para
> >>> rodar o 14.2R5 tem que ter um bom motivo, tipo hardware novo não
> >> suportado
> >>> pela 13.3, bug com seu cenário etc., um feature do qual sua rede
> depende
> >>> etc.
> >>>
> >>> Se a 14.2R5 tem algo legal, vai ser legal se/quando a 14.2 se tornar
> >>> recomendada pelo JTAC... por enquanto, só é recomendada para "Virtual
> >> Route
> >>> Reflector":
> >>
> http://kb.juniper.net/InfoCenter/index?page=content&id=KB21476&actp=search
> >>
> >> Sim Rubens, concordo com você.
> >>
> >> O lance foi justamente a tentativa de melhora da convergência, pois é
> >> horrível de lento nas 13.3.
> >>
> >> Se arrependimento matasse...
> >>
> >> Att,
> >>
> >> --
> >> Eduardo Schoedler
> >> --
> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>