I agree that this sounds like an automated process in some way. I would suspect that either a vendor code update changed something such that a given command that would not cause session reset now does, or they changed their automation to include a command that would cause a reset without realizing it/slipped through the cracks / etc.
On Thu, Nov 21, 2019 at 9:18 AM Mel Beckman <m...@beckman.org> wrote: > No. There should be no reason to bounce the session. Do you have soft > updates turn on? > > -mel via cell > > > On Nov 21, 2019, at 1:46 AM, Christopher Morrow <morrowc.li...@gmail.com> > wrote: > > > > Howdy! > > A question of interest to me, currently, is whether it's normal for > > providers to cause BGP flaps to their customers nightly... This seems, > > in my case, to be the provider PROBABLY updating prefix-filters on my > > session(s). > > > > Particularly AS56554 is currently getting v4/v6 transit from 2 > > providers, one of which we have 2 links toward. That provider appears > > to flap both of our ipv6 (only) bgp peers each night at about the same > > time each night. This smells like: "filter updates', but something > > that's different than the v4 filter update? (or perhaps they have no > > v4 filtering to update?) > > > > In the end, should customers expect nightly (or on a regular cadence) > > to see their sessions bounce? It hasn't been my experience in other > > situations... > > > > -chris >
