[j-nsp] Strange Behavior after ISSU from 13.3R8 to 17.4R1.16

[Jeffrey Nikoletich]

Scratch that. Problem still exist. ☹







*From:* Jeffrey Nikoletich <jeffn at xfernet.com>
*Sent:* May 27, 2018 07:43 PM
*To:* juniper-nsp at puck.nether.net
*Subject:* RE: Strange Behavior after ISSU from 13.3R8 to 17.4R1.16



All,



So after I sent this email I noticed a had a rogue rib-group in place. I
removed that and it seems traffic is fine now. I am testing and will let
you know.



Apparently it helps me to email the whole group just to “hopefully” find
the answer 5 seconds late.



Thanks,



Jeffrey Nikoletich



*From:* Jeffrey Nikoletich <jeffn at xfernet.com>
*Sent:* May 27, 2018 07:02 PM
*To:* juniper-nsp at puck.nether.net
*Subject:* Strange Behavior after ISSU from 13.3R8 to 17.4R1.16



Hello all,



So I have been scratching my head at a weird issue I am seeing on only 1 of
our devices after a ISSU rollout to 17.4. It seems that all peering session
links are not passing traffic. Here is what I know so far:



   1. Peering sessions (via exchanges) connect just fine.
   2. If the exchange is prepended, traffic flows just fine.
   3. No policy changes were made during the upgrade.
   4. When looking at the looking glass of direct peers, the next hop is
   set correctly to our IP on the exchanges.
   5. Don’t believe it is in interface/card issue as this is a trunk port
   and transit is working just fine.
   6. Routes received from peer are fine as well.



Here is my import and export policies, I  broke them down to extremely
simple and they still do not work:



show configuration policy-options policy-statement default-peering-out

term get-routes {

    from {

        prefix-list XXX;

    }

    then {

        community add XXX;

        community add XXXXX;

        accept;

    }

}

term from_bgp_customers {

    from {

        protocol bgp;

        as-path [ XXX-routes XXX-routes XXX-routes ];

    }

    then accept;

}

term others {

    then reject;

}



show configuration policy-options policy-statement pubpeer-in

term set-consistancy {

    then {

        metric 100;

        local-preference 200;

        community set type_pubpeer;

        next-hop peer-address;

    }

}

then accept;



Here is a test bgp group I created with just a few peers:



show configuration protocols bgp group ipv4-xxxx-xxxx-xxxx

type external;

import pubpeer-in;

export default-peering-out;

neighbor 206.53.XXX.XXX {

    description "XXXX";

    family inet {

        unicast {

            prefix-limit {

                maximum 600;

                teardown idle-timeout 5;

            }

        }

        any {

            prefix-limit {

                maximum 1000;

            }

        }

    }

    peer-as XXXX;

}

neighbor 206.53.XXX.XXX {

    description "XXXX";

    family inet {

        unicast {

            prefix-limit {

                maximum 600;

                teardown idle-timeout 5;

            }

        }

        any {

            prefix-limit {

                maximum 1000;

            }

        }

    }

    peer-as XXXX;

}

neighbor 206.53.XXX.XXX {

    description "XXXX.";

    family inet {

        unicast {

            prefix-limit {

                maximum 1100;

                teardown idle-timeout 5;

            }

        }

    }

    peer-as XXXX;

}





I have a feeling it is something simple and I am just missing it. Any ideas
or help would be appreciated. Thanks.



Jeffrey Nikoletich