On Sat, 15 Dec 2018 at 04:54, Randy via cisco-nsp <[email protected]> wrote:
>b)There is Zero-Value in having *soft-reconfig-inbound* for your session with >your ISP(this is 2018 and I dare say, every BGP speaker supports soft-reset >in/out! > > *soft-reconfig* makes sense on Customer-Sessions; if you are an ISP(so you > can prove to customer "what-you-are-receiving" prior to any-modification by > your router; to end the "This-is-Your-Problem" issue. Zero seems exaggeration, the more data you have access to, the better? Are you comfortable your policies are perfect and do exactly what you planned and you have no need to verify this? Are you confident software interprets and implements the policies correctly? Do you want to contact your upstream when they send you trash, even if you filter that trash? Do you turn off this on platforms where it's on by default (keep none in JunOS) to have harmonised platform independent configurations? I'd rather say, it's 2018, DRAM is cheap and premature optimisation is source of many problems. If I have the DRAM for it, I prefer to know what my policies rejected. But you also need to consider can you limit pre-policy max-prefix and if not, are you comfortable having this attack vector open. Likely you (we) are comfortable, considering how little interest industry has on protecting the control-plane. I'd also like to add that I view network statements undesirable. In static routes you can use tags to communicate what should happen to the static route during redistribution. Unfortunately we do not have communities or tags for connected/direct route, yet. So there is no avoiding double entries for connected routes, but I'd still prefer to add them to prefix-list instead of network-statement. -- ++ytti _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
