[j-nsp] Spine & leaf

[Payam Chychi]

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> 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> 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;
> >> I've never used Cumulus, just read about it.)
> >>      /Bellman
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


-- 
Payam Tarverdyan Chychi
Network Security Specialist / Network Engineer