Re: [j-nsp] [c-nsp] LACP between router VMs (James Bensley)

2017-12-01 Thread Chris Burton 
Glad the conversation helped.  The note about the scripts was a general 
FYI in case there are others looking to use the scripts as there have 
been many conversations about the use of LLDP and LACP with the vMX in 
the past, both on this thread as well as other chats, forums, etc... 
just included for completeness.


LACP and LLDP (and the like) are link local only protocols (would need 
to dig through the specifications to find the exact rules), they should 
not be forwarded by the bridge, otherwise you could break the protocols 
themselves, in the case of LLDP it may be a simple as creating 
troubleshooting nightmare in terms of bad information, but in the case 
of LACP it could cause real harm, that is why they are only transmitted 
on the local link and not forwarded by the soft bridge by default (I do 
not know of any hardware bridges that allow you to disabled this 
restriction, if you know of any I would be interested.  Disabling this 
behavior on soft switch breaks that rule, that being said in the 
virtualized network world there are many things that have changed, so my 
statement was more of a general warning to not implement unless you 
understand and are willing to accept the possible consequences.


I have been running both OVS and Linux Bridge (with modified Kernel) in 
various labs, both large and small for quite some time without any 
issues, so my guess is it would be fine with the above caveats and ample 
precautions, though in production I use physical NICs and SR-IOV based 
NICs so I have not attempted to implement this bypass in production and 
do not know all of the consequences for production deployment.


Out of curiosity what is your use case that you need to use LACP to 
communicate with VMs?


Cheers,

-C


On 11/12/2017 05:36 AM, adamv0...@netconsultings.com wrote:

Chris Burton
Sent: Saturday, November 11, 2017 11:50 PM

This has been discussed a few times on this list and other forums. That being
said, if you are looking to do this with Linux bridge you will need to modify
the net/br_private.h header library to remove the mask restriction placed on
using group_fwd_mask setting in /sys/class/net and recompile the kernel to
allow it forward LACP BPDU's.


My question regarding the Linux bridge was out of curiosity and to my surprise 
spawned a very fruitful discussion which I learned a lot from.
So thank you everyone.
I'm actually using OVS and the "sudo ovs-vsctl set bridge br-1 
other-config:forward-bpdu=true" did the trick.


If you are looking to use Openvswitch you can do as Sergio mentioned and
set the OVS bridge to allow forwarding of LACP BPDU's after you manually
add each interface, but if you want to use the default vmx.sh script to bind
the interfaces with OVS you will need to modify the config/vmx-
junosdev.conf file and add in "use_ovs_transport: True" as a key, and
depending on what version of OS you are running (I presume Ubuntu 16.04)
you may also need to modify the sub-script that vmx.sh --bind-dev calls to
prevent it from checking for the "openvswitch-datapath-source" package. I
have only tested OVS 2.6 (Ubuntu cloud repo) with version 16.1 of VMX, but
unless the sub-scripts are different for earlier or later versions it should 
work
(but it is unlikely to be supported since I do not see mention of using OVS in
any of the official Juniper documents, and they likely will not support this
even if OVS is supported as it breaks standards, same goes for LB mod's).


I'm not using any juniper scripts at all, I need complete control about all 
aspects of the setup and there are VMs of different vendors so I'm using custom 
scripts and procedures to create XMLs, define and start VMs and to interconnect 
them in OVS.



It should be understood though that you are breaking standards
compatibility and could create massive problems on the network, so running
this type of configuration outside of a lab environment should fall under the
do not do it category. If you are going to do this production you should use
physical NICs and SR-IOV with VF’s which eliminates the issue as was
mentioned by James.


As I mentioned earlier, I don't need to talk LACP to PF just LACP between VFs.
Can you elaborate on the "breaking standards compatibility" please?
In my setup I just need hundreds of simple p2p links (basically emulating 
fibres) between VMs so I need the OVS (or other bridge) not to intervene.


adam






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

Re: [j-nsp] EX3400 or EX4600, and HPE FlexFabric-20/40, QSFP+ DAC's

2017-12-01 Thread Michael Loftis 
My experience with DACs in the wild is they're not worth the trouble. Even
if they "work" once you look closer you'll spot that they're not working
well. Lots of errors/corrections at higher rates etc. better luck with say
1m or truely active DACs but thing is (Q)SFP(+) was never meant to be more
than an interconnect between points on the same board and the signal timing
constraints, drive levels and basically every other design decision and
constraints reflect that. It's got a very short maximum distance.

On Fri, Dec 1, 2017 at 13:18 Emille Blanc 
wrote:

> To close this thread, DAC's appear to have been a wash.
> Using like-vendor branded optics on both sides, and we have a functioning
> 40Gbps link.
>
> Thanks for the feedback on, and off-list. :]
>
> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> Of Chuck Anderson
> Sent: November-21-17 7:10 AM
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] EX3400 or EX4600, and HPE FlexFabric-20/40, QSFP+
> DAC's
>
> On Tue, Nov 21, 2017 at 06:28:07AM -0800, Emille Blanc wrote:
> > Hello folks,
> >
> > Trudging through the woes that are cross-vendor compatibility issues,
> and failing completely at getting a link between an EX3400 or EX4600, and
> an HPE FlexFabric-20/40 F8 card in our c7000 enclosure using an HPE branded
> QSFP+ 3mtr DAC.  That is to say, Juniper on one side, HPE on the other.
> > As an added bonus, the HPE module seems to be allergic to Juniper's QSFP
> completely.
> >
> > After the inevitable "It's not us, it's them" back-and-forth between
> JTAC and HPE Support, I'm looking for any success (or failure) stories from
> the community.
> >
> > We've been testing with a pair of HPE DACs, and they each work fine when
> we loop it to two QSFP+ slots in the same chassis/module.
> >
> > Has anyone been successful in making such a connection in the wild?
>
> Buy cheap QSFP+ optics and use fiber?
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX3400 or EX4600, and HPE FlexFabric-20/40, QSFP+ DAC's

2017-12-01 Thread Emille Blanc 
To close this thread, DAC's appear to have been a wash.
Using like-vendor branded optics on both sides, and we have a functioning 
40Gbps link.

Thanks for the feedback on, and off-list. :]

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Chuck Anderson
Sent: November-21-17 7:10 AM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] EX3400 or EX4600, and HPE FlexFabric-20/40, QSFP+ DAC's

On Tue, Nov 21, 2017 at 06:28:07AM -0800, Emille Blanc wrote:
> Hello folks,
> 
> Trudging through the woes that are cross-vendor compatibility issues, and 
> failing completely at getting a link between an EX3400 or EX4600, and an HPE 
> FlexFabric-20/40 F8 card in our c7000 enclosure using an HPE branded QSFP+ 
> 3mtr DAC.  That is to say, Juniper on one side, HPE on the other.
> As an added bonus, the HPE module seems to be allergic to Juniper's QSFP 
> completely.
> 
> After the inevitable "It's not us, it's them" back-and-forth between JTAC and 
> HPE Support, I'm looking for any success (or failure) stories from the 
> community.
> 
> We've been testing with a pair of HPE DACs, and they each work fine when we 
> loop it to two QSFP+ slots in the same chassis/module.
> 
> Has anyone been successful in making such a connection in the wild?

Buy cheap QSFP+ optics and use fiber?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] IPV6 IPFIX Flow issues "nodata" on flow collector.

2017-12-01 Thread João Lyma . 

Hi Gustavo,

Same problem here...
I use nfdump with nfsen.
Router: MX480 with JUNOS 16.1R3.10 64-bit kernel 
JNPR-10.3-20160927.337663_build


Regards,

Lyma


Em 30/11/2017 00:13, Gustavo Santos escreveu:

Hi,

Anyone else had issues with Junos 16.1R4 with IPV6 and IPFIX?

Here we use Plixer Scrutinizer as Flow collector and analyzer. IPv4 
flow
monitoring is working as intended. With IPv6 , looks like the collector 
is

don´t know what to do with the data the Router is sending (MX480).

After a Call , looks like the router is not sending the correct 
templates

to Scrutinizer, the only information it can identify is the current
interface traffic from the flows. But no source and destination ipv6
address.

I already opened a JTAC support, but looks like the JTAC doesn´t even 
have
a clue... I asked a friend that have the same router at another ISP and 
he

have the same issue with NFSEN/FASTNETMON..
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] MX80 v MX104

2017-12-01 Thread Raphael Maunier 
Go for MX204 : 
https://www.juniper.net/us/en/products-services/routing/mx-series/mx204/

RFS 02/2018

Raphael

On 01/12/2017 19:42, "juniper-nsp on behalf of Jerry Jones" 
 wrote:

Go with MX104

Form factor much better. nothing on the back, have option for second RE if 
desired, RE is slightly better, 2 more MIC slots, cost is generally less on 104 
than 80, if using ay 10G then it for sure should be, and if I remember correct 
104 is quieter, but have not played on 80 for some timen ow as ony use 104s for 
last couple years


On Dec 1, 2017, at 12:09 PM, Catalin Dominte  
wrote:

MX104 has 4gb Memory and MX80 comes with 2. If you are running full BGP
tables, you might want to consider this too.


*Catalin Dominte | Senior Network Consultant*

Nocsult Ltd  | 11 Castle Hill  |  Maidenhead  |  Berkshire  |  SL6 4AA  |
Phone:  +44 (0)1628 302 007

VAT registration number: GB 180957674  |  Company registration number:
08886349
P Please consider the environment - Do you really need to print this email?

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the email and
its attachments from all computers.

On 1 December 2017 at 18:03:15, Alain Hebert (aheb...@pubnix.net) wrote:

   Hi,

   Beside the extra RE-slot of the 104 and a few more slots.


   Is there any more drawback (beside the knowned hella slow RE which
is the same as the 104) of opting for the MX80?

   It looks like 4 10Gb XFP + 2 slot of 2 10Gb XFP is the maximum in
the 80 case.  Which will be viable for the project.


   PS: With a small budget, and they're buying 2 boxes anyway... and
they're not interested in MS-MIC

-- 
-
Alain Hebert aheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443

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

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


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

Re: [j-nsp] MX80 v MX104

2017-12-01 Thread Jerry Jones 
Go with MX104

Form factor much better. nothing on the back, have option for second RE if 
desired, RE is slightly better, 2 more MIC slots, cost is generally less on 104 
than 80, if using ay 10G then it for sure should be, and if I remember correct 
104 is quieter, but have not played on 80 for some timen ow as ony use 104s for 
last couple years


On Dec 1, 2017, at 12:09 PM, Catalin Dominte  
wrote:

MX104 has 4gb Memory and MX80 comes with 2. If you are running full BGP
tables, you might want to consider this too.


*Catalin Dominte | Senior Network Consultant*

Nocsult Ltd  | 11 Castle Hill  |  Maidenhead  |  Berkshire  |  SL6 4AA  |
Phone:  +44 (0)1628 302 007

VAT registration number: GB 180957674  |  Company registration number:
08886349
P Please consider the environment - Do you really need to print this email?

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the email and
its attachments from all computers.

On 1 December 2017 at 18:03:15, Alain Hebert (aheb...@pubnix.net) wrote:

   Hi,

   Beside the extra RE-slot of the 104 and a few more slots.


   Is there any more drawback (beside the knowned hella slow RE which
is the same as the 104) of opting for the MX80?

   It looks like 4 10Gb XFP + 2 slot of 2 10Gb XFP is the maximum in
the 80 case.  Which will be viable for the project.


   PS: With a small budget, and they're buying 2 boxes anyway... and
they're not interested in MS-MIC

-- 
-
Alain Hebert aheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443

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

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

Re: [j-nsp] IPV6 IPFIX Flow issues "nodata" on flow collector.

2017-12-01 Thread sthaug 
> Anyone else had issues with Junos 16.1R4 with IPV6 and IPFIX?
> 
> Here we use Plixer Scrutinizer as Flow collector and analyzer. IPv4 flow
> monitoring is working as intended. With IPv6 , looks like the collector is
> don´t know what to do with the data the Router is sending (MX480).
> 
> After a Call , looks like the router is not sending the correct templates
> to Scrutinizer, the only information it can identify is the current
> interface traffic from the flows. But no source and destination ipv6
> address.

Can't comment on 16.1R4. We're running IPFIX flow collection on 15.1R6
and it seems to be working reasonably well, both for IPv4 and IPv6. No
problem showing IPv6 addresses with nfdump.

You may want to show your config.

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX80 v MX104

2017-12-01 Thread Catalin Dominte 
MX104 has 4gb Memory and MX80 comes with 2. If you are running full BGP
tables, you might want to consider this too.


*Catalin Dominte | Senior Network Consultant*

Nocsult Ltd  | 11 Castle Hill  |  Maidenhead  |  Berkshire  |  SL6 4AA  |
 Phone:  +44 (0)1628 302 007

VAT registration number: GB 180957674  |  Company registration number:
08886349
P Please consider the environment - Do you really need to print this email?

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the email and
its attachments from all computers.

On 1 December 2017 at 18:03:15, Alain Hebert (aheb...@pubnix.net) wrote:

Hi,

Beside the extra RE-slot of the 104 and a few more slots.


Is there any more drawback (beside the knowned hella slow RE which
is the same as the 104) of opting for the MX80?

It looks like 4 10Gb XFP + 2 slot of 2 10Gb XFP is the maximum in
the 80 case.  Which will be viable for the project.


PS: With a small budget, and they're buying 2 boxes anyway... and
they're not interested in MS-MIC

-- 
-
Alain Hebert aheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443

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

[j-nsp] MX80 v MX104

2017-12-01 Thread Alain Hebert 

    Hi,

    Beside the extra RE-slot of the 104 and a few more slots.


    Is there any more drawback (beside the knowned hella slow RE which 
is the same as the 104) of opting for the MX80?


    It looks like 4 10Gb XFP + 2 slot of 2 10Gb XFP is the maximum in 
the 80 case.  Which will be viable for the project.



    PS: With a small budget, and they're buying 2 boxes anyway... and 
they're not interested in MS-MIC


--
-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

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

Re: [j-nsp] EX4200 virtual chassis

2017-12-01 Thread Doug McIntyre 
On Mon, Nov 27, 2017 at 08:57:07AM +0700, Victor Sudakov wrote:
> We are planning to add backup switches in a Virtual Chassis
> configuration to our existing EX4200s.
...
> If I have a standalone EX4200, should I power it off before plugging
> in the Virtual Chassis Cable for the first time, and connecting
> another (powered off) EX4200? 
> 
> The links above say only that the desired master should be powered on
> first, but nothing is said about the possibility of hot plug
> connection.

I don't know about "should", but I've never had a problem moving VC cabling
around, unplugging, plugging. The cables aren't "smart"  (AFAIK), so its not
like the box can detect if a VC cable gets attached, only if there is something
on the other end.

I would expect changing from standalone to virtual chassis would be a
service affecting change though, so be prepared to stop passing traffic if
this isn't done in a maint window.

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

[j-nsp] IPV6 IPFIX Flow issues "nodata" on flow collector.

2017-12-01 Thread Gustavo Santos 
Hi,

Anyone else had issues with Junos 16.1R4 with IPV6 and IPFIX?

Here we use Plixer Scrutinizer as Flow collector and analyzer. IPv4 flow
monitoring is working as intended. With IPv6 , looks like the collector is
don´t know what to do with the data the Router is sending (MX480).

After a Call , looks like the router is not sending the correct templates
to Scrutinizer, the only information it can identify is the current
interface traffic from the flows. But no source and destination ipv6
address.

I already opened a JTAC support, but looks like the JTAC doesn´t even have
a clue... I asked a friend that have the same router at another ISP and he
have the same issue with NFSEN/FASTNETMON..
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] MIC-3D-4XGE-XFP in a MX104?

2017-12-01 Thread Tim St. Pierre 

Hello,

As anyone ever put a 4XGE MIC card in a MX104?  Only the 2XGE card is 
supported obviously, but I'm curious to know what would happen if 
someone did?  Is it just oversubscribed?  Would it not work at all?


-Tim

--

--
Tim St. Pierre
System Operator
Communicate Freely
289-225-1220 x5101

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

[j-nsp] MX Upgrade

2017-12-01 Thread Mohammad Khalil 
Hi all
Am trying to upgrade the software on my of my MX 240 routers
I have determined the image I need , what am trying to do is to use the run
copy file URL command but am unable to :

ssh: https: hostname nor servname provided, or not known
error: file-fetch failed
error: could not fetch local copy of file

I have configured name-server and a domain-name

Am I missing something?

Thanks

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

Re: [j-nsp] Anyone uses Adaptive Load Balancing?

2017-12-01 Thread Alex K. 
Hello Michael,

Thank you for sharing your experience. It's really useful.

Alex.

בתאריך 20 בנוב' 2017 17:11,‏ "Michael Hare"  כתב:

> Alex-
>
> I've used it AS wide in 14.1 for ~2+ years without observing any negative
> side effects.  My main driver was a connector's SAN replication MPLS
> service across an Nx10 bundle mixed with regular IP traffic with the SAN
> wanting to be one big flow.
>
> -Michael
>
> >>-Original Message-
> >>From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> >>Of Alex K.
> >>Sent: Saturday, November 18, 2017 1:09 AM
> >>To: serge vautour 
> >>Cc: juniper-nsp 
> >>Subject: Re: [j-nsp] Anyone uses Adaptive Load Balancing?
> >>
> >>Hello Serge and thank you.
> >>
> >>Yes, there are indeed, not that many cases for ALB. That's why I turned
> to
> >>community.
> >>
> >>Thank you for sharing your experience.
> >>
> >>בתאריך 18 בנוב' 2017 1:41 AM,‏ "serge vautour"
> >>
> >>כתב:
> >>
> >>> Hello,
> >>>
> >>> We have been using it for a while. Works great. We have a few small
> links
> >>> in a LAG bundle with a small number of fat flows over them. Without
> >>> adaptive LAG the flows would sometimes hash on the same link. With
> >>adaptive
> >>> LAG they are always split.
> >>>
> >>> I agree that there probably aren't many use cases for this. We ran into
> >>> one and this solution worked.
> >>>
> >>> Serge
> >>>
> >>>
> >>> On Fri, Nov 17, 2017 at 6:36 PM, Alex K.  wrote:
> >>>
>  Hello everyone,
> 
>  A customer of mine, is looking forward for a technology able to load
>  balance a traffic across a LAG.
> 
>  The LAG in question comprised of Ethernet link and can grow from a few
>  links (4) to say, 20 - as required bandwidth grows. The gear is MX
> boxes.
> 
>  Since I'm familiar with adaptive load balancing but never used it
> myself,
>  I'll glad if someone here can share his/her experience using it? Can
> it
>  deliver pretty good load balancing across a LAG between routers? Is it
>  stable? Is there any caveats one should avoid? Anything else we should
>  consider, before deploying this thing into production? Feel free to
> share
>  (off list/on list) your experience and everything else you think
> relevant.
> 
>  Thank you.
>  ___
>  juniper-nsp mailing list juniper-nsp@puck.nether.net
>  https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> >>>
> >>>
> >>___
> >>juniper-nsp mailing list juniper-nsp@puck.nether.net
> >>https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] EX4200 virtual chassis

2017-12-01 Thread Victor Sudakov 
Dear Colleagues,

We are planning to add backup switches in a Virtual Chassis
configuration to our existing EX4200s.

I have read
https://www.juniper.net/documentation/en_US/junos/topics/concept/virtual-chassis-ex4200-components.html
and
https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/virtual-chassis-ex4200-cli.html
so the configuration is more or less clear to me. There is one question left 
however. 

If I have a standalone EX4200, should I power it off before plugging
in the Virtual Chassis Cable for the first time, and connecting
another (powered off) EX4200? 

The links above say only that the desired master should be powered on
first, but nothing is said about the possibility of hot plug
connection.

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
AS43859
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Anyone uses Adaptive Load Balancing?

2017-12-01 Thread Alex K. 
Hello Daniel,

Thank you. My scenario close to yours, hence I glad to know this thing
really works.

Alex.

בתאריך 25 בנוב' 2017 9:36 AM,‏ "Daniel Rohan"  כתב:

Same.  Worked fine on 4x10Gb ring with large research flows.

On Mon, Nov 20, 2017 at 7:11 AM, Michael Hare  wrote:

> Alex-
>
> I've used it AS wide in 14.1 for ~2+ years without observing any negative
> side effects.  My main driver was a connector's SAN replication MPLS
> service across an Nx10 bundle mixed with regular IP traffic with the SAN
> wanting to be one big flow.
>
> -Michael
>
> >>-Original Message-
> >>From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> >>Of Alex K.
> >>Sent: Saturday, November 18, 2017 1:09 AM
> >>To: serge vautour 
> >>Cc: juniper-nsp 
> >>Subject: Re: [j-nsp] Anyone uses Adaptive Load Balancing?
> >>
> >>Hello Serge and thank you.
> >>
> >>Yes, there are indeed, not that many cases for ALB. That's why I turned
> to
> >>community.
> >>
> >>Thank you for sharing your experience.
> >>
> >>בתאריך 18 בנוב' 2017 1:41 AM,‏ "serge vautour"
> >>
> >>כתב:
> >>
> >>> Hello,
> >>>
> >>> We have been using it for a while. Works great. We have a few small
> links
> >>> in a LAG bundle with a small number of fat flows over them. Without
> >>> adaptive LAG the flows would sometimes hash on the same link. With
> >>adaptive
> >>> LAG they are always split.
> >>>
> >>> I agree that there probably aren't many use cases for this. We ran into
> >>> one and this solution worked.
> >>>
> >>> Serge
> >>>
> >>>
> >>> On Fri, Nov 17, 2017 at 6:36 PM, Alex K.  wrote:
> >>>
>  Hello everyone,
> 
>  A customer of mine, is looking forward for a technology able to load
>  balance a traffic across a LAG.
> 
>  The LAG in question comprised of Ethernet link and can grow from a few
>  links (4) to say, 20 - as required bandwidth grows. The gear is MX
> boxes.
> 
>  Since I'm familiar with adaptive load balancing but never used it
> myself,
>  I'll glad if someone here can share his/her experience using it? Can
> it
>  deliver pretty good load balancing across a LAG between routers? Is it
>  stable? Is there any caveats one should avoid? Anything else we should
>  consider, before deploying this thing into production? Feel free to
> share
>  (off list/on list) your experience and everything else you think
> relevant.
> 
>  Thank you.
>  ___
>  juniper-nsp mailing list juniper-nsp@puck.nether.net
>  https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> >>>
> >>>
> >>___
> >>juniper-nsp mailing list juniper-nsp@puck.nether.net
> >>https://puck.nether.net/mailman/listinfo/juniper-nsp
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Anyone uses Adaptive Load Balancing?

2017-12-01 Thread Daniel Rohan 
Same.  Worked fine on 4x10Gb ring with large research flows.

On Mon, Nov 20, 2017 at 7:11 AM, Michael Hare  wrote:

> Alex-
>
> I've used it AS wide in 14.1 for ~2+ years without observing any negative
> side effects.  My main driver was a connector's SAN replication MPLS
> service across an Nx10 bundle mixed with regular IP traffic with the SAN
> wanting to be one big flow.
>
> -Michael
>
> >>-Original Message-
> >>From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> >>Of Alex K.
> >>Sent: Saturday, November 18, 2017 1:09 AM
> >>To: serge vautour 
> >>Cc: juniper-nsp 
> >>Subject: Re: [j-nsp] Anyone uses Adaptive Load Balancing?
> >>
> >>Hello Serge and thank you.
> >>
> >>Yes, there are indeed, not that many cases for ALB. That's why I turned
> to
> >>community.
> >>
> >>Thank you for sharing your experience.
> >>
> >>בתאריך 18 בנוב' 2017 1:41 AM,‏ "serge vautour"
> >>
> >>כתב:
> >>
> >>> Hello,
> >>>
> >>> We have been using it for a while. Works great. We have a few small
> links
> >>> in a LAG bundle with a small number of fat flows over them. Without
> >>> adaptive LAG the flows would sometimes hash on the same link. With
> >>adaptive
> >>> LAG they are always split.
> >>>
> >>> I agree that there probably aren't many use cases for this. We ran into
> >>> one and this solution worked.
> >>>
> >>> Serge
> >>>
> >>>
> >>> On Fri, Nov 17, 2017 at 6:36 PM, Alex K.  wrote:
> >>>
>  Hello everyone,
> 
>  A customer of mine, is looking forward for a technology able to load
>  balance a traffic across a LAG.
> 
>  The LAG in question comprised of Ethernet link and can grow from a few
>  links (4) to say, 20 - as required bandwidth grows. The gear is MX
> boxes.
> 
>  Since I'm familiar with adaptive load balancing but never used it
> myself,
>  I'll glad if someone here can share his/her experience using it? Can
> it
>  deliver pretty good load balancing across a LAG between routers? Is it
>  stable? Is there any caveats one should avoid? Anything else we should
>  consider, before deploying this thing into production? Feel free to
> share
>  (off list/on list) your experience and everything else you think
> relevant.
> 
>  Thank you.
>  ___
>  juniper-nsp mailing list juniper-nsp@puck.nether.net
>  https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> >>>
> >>>
> >>___
> >>juniper-nsp mailing list juniper-nsp@puck.nether.net
> >>https://puck.nether.net/mailman/listinfo/juniper-nsp
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp