[j-nsp] Spine & leaf

[David Sinn]

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 <pchychi at 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 <dsinn at dsinn.com <mailto:dsinn at 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 <swhyte at gmail.com <mailto:swhyte at 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 at puck.nether.net <mailto:juniper-nsp at 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 at puck.nether.net <mailto:juniper-nsp at 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