> Of David Sinn
> Sent: Tuesday, June 26, 2018 8:38 PM
> To: Payam Chychi
> Cc: juniper-nsp@puck.nether.net; bell...@nsc.liu.se
> Subject: Re: [j-nsp] Spine & leaf
>
> Highly doubt that the network you reference is lager then the ones I'm
> referring to. OSPF s
> Of David Sinn
> Sent: Wednesday, June 27, 2018 7:55 PM
>
>
> > On Jun 27, 2018, at 8:40 AM, Thomas Bellman wrote:
> >
> > On 2018-06-26 21:38, David Sinn wrote:
> >
> >> OSPF scales well to many multiples of 1000's of devices.
> >
> > Is that true even for Clos (spine & leaf) networks, and in
> On Jun 27, 2018, at 8:40 AM, Thomas Bellman wrote:
>
> On 2018-06-26 21:38, David Sinn wrote:
>
>> OSPF scales well to many multiples of 1000's of devices.
>
> Is that true even for Clos (spine & leaf) networks, and in a single area?
Yes for multi-tiered Clos, as that was the original ask
On 2018-06-26 21:38, David Sinn wrote:
> OSPF scales well to many multiples of 1000's of devices.
Is that true even for Clos (spine & leaf) networks, and in a single area?
My understanding, solely based on what others have told me, is that
the flooding of LSAs in a Clos network can start to
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 wrote:
>
> Not sure if I agree with this, this (ospf) certainly would not scale in my
> network.
On 25/Jun/18 23:04, Payam Chychi 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
On 25/Jun/18 19:37, Scott Whyte 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.
If you
On 25/Jun/18 18:33, Aaron Gould wrote:
> Is it true that OSPF/ISIS are needed for label advertisement in a SR/SPRING
> world?
I think you meant to say, "... are all that is needed ..."
Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
On 25/Jun/18 18:22, Scott Whyte wrote:
>
> BGP, as you say, provides excellent filtering capabilities. What does
> OSPF/ISIS bring to the table?
Simple, fast.
As long as you are using your IGP purely for infrastructure, it should
be easy to manage.
If you're using it to carry customer
On 25/Jun/18 17:50, Chris Boyd wrote:
> Other than the administrative controls of mature route filtering tools in
> BGP, I’m curious why people choose BGP over OSPF for route injection.
For our Anycast DNS, we actually use OSPF (Quagga) on FreeBSD, upstream
those to a router, and then
On 25/Jun/18 18:04, Aaron Gould wrote:
> I'm not sure of the overall context of the question but I will say that, over
> the last decade at least, BGP in general has evolved into the
> multiprotocol/multi-address family mechanism for doing many things of virtual
> networking internal to an
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
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
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
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
On 6/25/18 9:33 AM, Aaron Gould wrote:
Is it true that OSPF/ISIS are needed for label advertisement in a SR/SPRING
world?
Are you driving your overlay design via underlay requirements, or
modifying your underlay to do what is necessary for your overlay?
Aaron
On Jun 25, 2018, at
> On Jun 25, 2018, at 11:22 AM, Scott Whyte wrote:
>
> BGP, as you say, provides excellent filtering capabilities. What does
> OSPF/ISIS bring to the table?
Less configuration for peer sessions since OSPF is multicast, but I suppose
that tools like Ansible minimize that effort.
—Chris
Is it true that OSPF/ISIS are needed for label advertisement in a SR/SPRING
world?
Aaron
> On Jun 25, 2018, at 11:22 AM, Scott Whyte wrote:
>
>
>
> On 6/25/18 8:50 AM, Chris Boyd wrote:
>>> On Jun 23, 2018, at 10:56 PM, joel jaeggli wrote:
>>>
>>> Personally I'm kind of done with large
On 6/25/18 8:50 AM, Chris Boyd wrote:
On Jun 23, 2018, at 10:56 PM, joel jaeggli wrote:
Personally I'm kind of done with large L2s so I would probably just use
ebgp with a private asn per server and eschew all these l2 topologies.
Other than the administrative controls of mature route
Id also keep with L3/BGP over L2 or even L3/OSPF for DC. For ENT, you can
get away with L2 if you need and want to stay away from more advance
L3VPN/XVLAN
Really depends on what you are trying to do... however, most cases L3/BGP
will be a great start point and a friend =)
On Mon, Jun 25, 2018 at
I'm not sure of the overall context of the question but I will say that, over
the last decade at least, BGP in general has evolved into the
multiprotocol/multi-address family mechanism for doing many things of virtual
networking internal to an SP network and even some, what I would call,
> On Jun 23, 2018, at 10:56 PM, joel jaeggli wrote:
>
> Personally I'm kind of done with large L2s so I would probably just use
> ebgp with a private asn per server and eschew all these l2 topologies.
Other than the administrative controls of mature route filtering tools in BGP,
I’m curious
On 24/Jun/18 05:56, joel jaeggli wrote:
> Personally I'm kind of done with large L2s so I would probably just use
> ebgp with a private asn per server and eschew all these l2 topologies.
If I were running a large data centre, I'd do the same as well.
Mark.
Thanks for the info. I will defiantly check it out
Cheers !!!
Mehul
On Sun, Jun 24, 2018 at 9:26 AM joel jaeggli wrote:
> On 6/22/18 11:44 PM, Mehul Gajjar wrote:
> > Hello Juniper experts,
> >
> > I am new in Juniper.
> >
> > Can anyone help me the basic l2 spine & leaf configurations
On 6/22/18 11:44 PM, Mehul Gajjar wrote:
> Hello Juniper experts,
>
> I am new in Juniper.
>
> Can anyone help me the basic l2 spine & leaf configurations example. my
> concern is to high availability of server's connections.
High availability of a server's interface is typically achieved by
Hello Juniper experts,
I am new in Juniper.
Can anyone help me the basic l2 spine & leaf configurations example. my
concern is to high availability of server's connections.
Cheers !!!
Mehul
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
26 matches
Mail list logo
