You're brave soul, trying ISSU at all and what-not... Mark.
On 28/May/18 04:49, Jeffrey Nikoletich wrote: > Scratch that. Problem still exist. ☹ > > > > > > > > *From:* Jeffrey Nikoletich <je...@xfernet.com> > *Sent:* May 27, 2018 07:43 PM > *To:* juniper-nsp@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 <je...@xfernet.com> > *Sent:* May 27, 2018 07:02 PM > *To:* juniper-nsp@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 > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp