Highly doubt that the network you reference is lager then the ones I'm referring to. OSPF scales well to many multiples of 1000's of devices.
David > On Jun 25, 2018, at 2:04 PM, Payam Chychi <pchy...@gmail.com> wrote: > > Not sure if I agree with this, this (ospf) certainly would not scale in my > network. the point being, different use cases, different environments. Always > design your network to allow for forward progression else you will be wasting > more time and dealing with more problems > > On Mon, Jun 25, 2018 at 11:19 AM David Sinn <ds...@dsinn.com > <mailto:ds...@dsinn.com>> wrote: > At most networks scale you won't notice the difference, but OSPF will also > converge faster then BGP at very large scale. Adding on top the costs of > re-using AS's in a eBGP world, verses mutual-RR with iBGP, having a good > summarization plan with OSPF is a bit more trivial and retains a overall net > smaller configuration on-box even if you are generating it programatically. > The concerns about chattiness is also overblown as even Quagga can keep up > with massive Leaf/Spine deployments on really small CPU's in a only OSPF > world. > > I would caution that the auto-discovery can also have a downside as it more > readily opens you up to mis-cabling, which can be fairly negative in a > Leaf/Spine topology. It's one of the reasons Cumulus came up with PTM so > that you can deploy a described version of your topology and have the device > alert/react when the actual version is different. Some embodiment of that is > useful, but need not be on-box. > > David > > > > On Jun 25, 2018, at 10:37 AM, Scott Whyte <swh...@gmail.com > > <mailto:swh...@gmail.com>> wrote: > > > > In balance then, we have better filtering versus less config, which has > > already been noted can (must) be completely automated. Where one's shop is > > on the NetDevOps curve probably has a lot of impact on the decision, which > > is unfortunate. > > > > > > On 6/25/18 10:29 AM, Thomas Bellman wrote: > >> On 2018-06-25 18:22, Scott Whyte wrote: > >>> BGP, as you say, provides excellent filtering capabilities. What > >>> does OSPF/ISIS bring to the table? > >> Automatic discovery of peers, and thus less unique configuration. You > >> don't need to configure each peer individually, just the interface. If > >> you do unnumbered links, you don't even need to allocate link networks > >> for your routing links, giving even less unique configuration. Just > >> set interfaces xe-0/0/17.1 family inet unnumbered-address lo0.1 > >> set interfaces xe-0/0/17.1 family inet6 > >> set protocols ospf area A.B.C.D interface xe-0/0/17.1 interface-type p2p > >> set protocols ospf3 area A.B.C.D interface xe-0/0/17.1 interface-type p2p > >> and you're done. The nice thing is that the only unique piece of > >> configuration is the interface name. > >> Doing unnumbered links for BGP seems to at least be more complicated, > >> but Cumulus Linux is supposed to have support for it, making it as easy > >> to configure as OSPF. > >> (https://blog.ipspace.net/2015/02/bgp-configuration-made-simple-with.html > >> <https://blog.ipspace.net/2015/02/bgp-configuration-made-simple-with.html>; > >> I've never used Cumulus, just read about it.) > >> /Bellman > > _______________________________________________ > > juniper-nsp mailing list juniper-nsp@puck.nether.net > > <mailto:juniper-nsp@puck.nether.net> > > https://puck.nether.net/mailman/listinfo/juniper-nsp > > <https://puck.nether.net/mailman/listinfo/juniper-nsp> > > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > <mailto:juniper-nsp@puck.nether.net> > https://puck.nether.net/mailman/listinfo/juniper-nsp > <https://puck.nether.net/mailman/listinfo/juniper-nsp> > > > -- > Payam Tarverdyan Chychi > Network Security Specialist / Network Engineer _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
