Re: [j-nsp] Spine & leaf

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

Re: [j-nsp] Spine & leaf

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 n

Re: [j-nsp] Ipsec tunnel flapping

Dear Alexandre, Please guide how can I fix this issue? It raise suddenly before this on same configuration ipsec tunnel was working fine for more than 5 to 6 months. On Mon, Jun 25, 2018, 8:22 PM Alexandre Guimaraes < alexandre.guimar...@ascenty.com> wrote: > Sameer > > > Reason: IPSec SA delete

Re: [j-nsp] Spine & leaf

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

Re: [j-nsp] Ipsec tunnel flapping

Dear Koyle, I have already configure static route towards destination. On Mon, Jun 25, 2018, 6:50 PM Eldon Koyle wrote: > Do you have a default route over that tunnel? If so, once the tunnel > comes up it will try to route the ipsec connection through the tunnel, > which will break the tunnel.

Re: [j-nsp] Spine & leaf

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 un

Re: [j-nsp] Spine & leaf

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 11:22

Re: [j-nsp] Spine & leaf

> 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

Re: [j-nsp] Spine & leaf

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 L2s

Re: [j-nsp] terminate endless loop in SLAX

Martin T writes: >Hi! > >Is there a way to terminate endless loop in SLAX? For example, if I >configure something as simple as that: > >match / { > { >while ( true() ) { >terminate; >} It's processing the terminate, but then it continues to "skip" over the rest of t

Re: [j-nsp] Spine & leaf

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 f

Re: [j-nsp] Spine & leaf

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 9

Re: [j-nsp] Spine & leaf

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, progre

Re: [j-nsp] Spine & leaf

> 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

Re: [j-nsp] Ipsec tunnel flapping

Sameer Reason: IPSec SA delete payload received from peer, corresponding IPSec SAs cleared This is a phase 2 problem, maybe deadpeerdetection failure, VPN monitoring failure, a failure during rekey when old SA is deleted notification sent to delete old SA. Most of the cases. att Alexandre

Re: [j-nsp] Spine & leaf

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.

Re: [j-nsp] Which versions of Space support Spotlight

Check out this link: https://www.juniper.net/documentation/en_US/release-independent/spotlight-secure/information-products/pathway-pages/spotlight-secure/index.html

[j-nsp] terminate endless loop in SLAX

Hi! Is there a way to terminate endless loop in SLAX? For example, if I configure something as simple as that: match / { { while ( true() ) { terminate; } } } ..then according to the debugger, the while loop does not seem to be looping but simply hangs. tha