<div dir="ltr">I agree that this sounds like an automated process in some way. <div><br></div><div>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. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 21, 2019 at 9:18 AM Mel Beckman <<a href="mailto:mel@beckman.org">mel@beckman.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">No. There should be no reason to bounce the session. Do you have soft updates turn on?<br>
<br>
-mel via cell<br>
<br>
> On Nov 21, 2019, at 1:46 AM, Christopher Morrow <<a href="mailto:morrowc.lists@gmail.com" target="_blank">morrowc.lists@gmail.com</a>> wrote:<br>
> <br>
> Howdy!<br>
> A question of interest to me, currently, is whether it's normal for<br>
> providers to cause BGP flaps to their customers nightly... This seems,<br>
> in my case, to be the provider PROBABLY updating prefix-filters on my<br>
> session(s).<br>
> <br>
> Particularly AS56554 is currently getting v4/v6 transit from 2<br>
> providers, one of which we have 2 links toward. That provider appears<br>
> to flap both of our ipv6 (only) bgp peers each night at about the same<br>
> time each night. This smells like: "filter updates', but something<br>
> that's different than the v4 filter update? (or perhaps they have no<br>
> v4 filtering to update?)<br>
> <br>
> In the end, should customers expect nightly (or on a regular cadence)<br>
> to see their sessions bounce? It hasn't been my experience in other<br>
> situations...<br>
> <br>
> -chris<br>
</blockquote></div>