[j-nsp] st0.13 Interface won't come up - ipsec VPN issue

[sameer mughal]

Hi Team,

I was disable st interface and when I am going to active this interface, it
won't coming up and remote site st interface is up.
Can anyone please help me to fix this issue?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX Forwarding Scale/Monitoring

[James Bensley]

On 5 September 2017 at 17:29, Harry Reynolds  wrote:
> The memory is dynamic and can be allocated as needed. I think the key is that 
> NH is limited to a maximum of 11 double mega words. What matters is overall 
> utilization, and then how close NH is to having 11DMW, and if so, how much of 
> that is used. To survive negative events we suggest that no more than 80-85% 
> of the maximum 11 DMW be used.
>
> Here is OP from a box that is getting full. It has near 80% of the 11 DMW 
> maximum allocated and of that, its 84% full.
>
> Regards
>
>
>
> NPC7(gallon vty)# sho jnh 0 poo usage
> EDMEM overall usage:
> [NH//|FW|CNTR///|HASH|ENCAPS|]
> 08.012.018.0 24.7   
> 28.8 32.0M
>
> Next Hop
> [***|]
>  8.0M (84% | 16%)
>
> Firewall
> [*|--|] 4.0M (3% | 97%)
>
> Counters
> [***|] 6.0M (38% | 
> 62%)
>
> HASH
> [***] 6.7M 
> (100% | 0%)
>
> ENCAPS
> [] 4.1M (100% | 0%)
>
> Shared Memory - NH/FW/CNTR/HASH/ENCAPS
> [**|--]
>  7.2M (48% | 52%)
>
> DMEM overall usage:
> [-]
> 0 0.0M


Hi Harry,

Sorry for the delay in my response!

I am still plugging away with JTAC with only moderate success so
thankyou kindly for this info it is very useful.

Cheers,
James.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] EX 3300 vs EX 3400 for access layer

[John Kristoff]

Friends,

Our engineering team is reviewing and contemplating whether to stick
with the Juniper EX 3300 switch at the edge access layer (to user wired
ports, some VoIP phones, and some wireless APs also connect to these).

Typically these devices can last out in the field for five or more
years.  There are at least two potential concerns about this series of
switches.  One, when stacking them into a larger virtual chassis (i.e.
six or more), the management plan performance appears to be horribly
slow and burdened by this extra maintenance work.  Two, will these
devices sustain the future PoE requirements that we may see from edge
devices?

I suspect the answer to the latter question is probably yes, but the
first issue is what bothers me the most.

The link access speeds and up links are probably OK given our traffic
projections.

Curious what others are using or have considered if you're running
Juniper devices at the edge.

Note, we're very cost conscious so the 3300 is much more appealing over
the 3400 or higher end line.  Also note, while a different vendor may
be a long term option, consider that out of scope for this thread.

Thank you,

John
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX 3300 vs EX 3400 for access layer

[Chuck Anderson]

On Thu, Sep 14, 2017 at 10:54:54AM -0500, John Kristoff wrote:
> Typically these devices can last out in the field for five or more
> years.  There are at least two potential concerns about this series of
> switches.  One, when stacking them into a larger virtual chassis (i.e.
> six or more), the management plan performance appears to be horribly
> slow and burdened by this extra maintenance work.  Two, will these
> devices sustain the future PoE requirements that we may see from edge
> devices?

For your large VC concern, break up the VCs so none is larger than 4
or 5 units and interconnect multiple VCs at each site with LAGs.
We've done this with some EX4200 VCs that were 8-10 units for the same
reasons.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp