Re: [j-nsp] LACP is not running between two VMX

❦ 25 avril 2019 09:31 +01, : > I haven't tried MC-LAG, but I used standard LAG (with LACP). > The problem I faced was that the standard Linux bridges (usually used to > simulate virtual p2p links between vMX-es won't forward BPDUs including LACP > (and I did not find a way to hack around at that

Re: [j-nsp] LACP is not running between two VMX

> omar sahnoun > Sent: Wednesday, April 24, 2019 8:55 AM > > Hello all, > > I tried to mount a MC-LAG between two VMXs (using EVE-NG). I note that > the lacp protocol is not operational. > I did some research (including on this forum). The explanations I find are a > little complicated. That's

Re: [j-nsp] LACP is not running between two VMX

Sorry I don't have mc-lag configs for vMX, but I did do mc-lag on vQFX... Here is some quick outputs from my eve-ng lab... I have mc-lag between (2) vQFX devices... and actually, the lag client side is one vMX node... Here's one side of the mc-lag pair... I grabbed some commands that I recall

[j-nsp] LACP is not running between two VMX

Hello all, I tried to mount a MC-LAG between two VMXs (using EVE-NG). I note that the lacp protocol is not operational. I did some research (including on this forum). The explanations I find are a little complicated. That's why I post this message. If anyone among you has a simple solution for

Re: [j-nsp] LACP hashing algorithm

Hello, I saw a similar issue, and the JTAC traced it to a software issue whereby a LACP member would be incorrectly programmed on the ASIC for random VLAN tags. Disable / Re-enable the interface did not fix it, but removing the port from LACP and adding it back fixed the ASIC programming

Re: [j-nsp] LACP hashing algorithm

To troubleshoot this kind of condition, you need to understand 1) the complete structure of the headers (is there any tunneling, MPLS, pseudowires etc) 2) what kind of forwarding decision your MX performs for those packets: IP LPM only, Ethernet switching, IP + Ethernet (irb-based L3), MPLS,

Re: [j-nsp] LACP hashing algorithm

ok update. We restarted the MPC4E on our 960 and voila, all 4 links being used- LOL !!! The MPC4E that we restarted also had another AE bundle exhibiting the same issue across other ports. Anyways, working now, cant even begin to explain what the problem might have been. Many thanks JfD On 10

Re: [j-nsp] LACP hashing algorithm

Guys thanks for all the replies, when I took an sflow sample, I oculd see at least 100+ flows with varying src/dst tuple and flow sizes, so cant understand why flows are stuck on one link. I can understand if tuples were hashing to one link, but these are varies sources/destinations... makes no

Re: [j-nsp] LACP hashing algorithm

I am assuming the traffic has MPLS labels, yes?? On 8/9/18, 7:17 AM, "Luis Balbinot" wrote: How many flows are there in total? Is there a test appliance involved? We had many issues with those in the past during service delivery tests. Also I assume you are using MPCs and not

Re: [j-nsp] LACP hashing algorithm

Have you tried load-balance adaptive? set interfaces aeX aggregated-ether-options load-balance adaptive tolerance 10 Regards, 2018-08-08 20:32 GMT-03:00 junos fordummies via juniper-nsp : > Hi all, > > This will sound like a very weird question, but has anyone seen a scenario > whereby an

Re: [j-nsp] LACP hashing algorithm

How many flows are there in total? Is there a test appliance involved? We had many issues with those in the past during service delivery tests. Also I assume you are using MPCs and not DPCs and also that you are talking about IP traffic. Please correct me if not. Luis On Wed, 8 Aug 2018 at

Re: [j-nsp] LACP hashing algorithm

Yes, have seen this, but need to check how we resolved this. Will get back to you. On 8/8/18, 7:32 PM, "junos fordummies" wrote: Hi all, This will sound like a very weird question, but has anyone seen a scenario whereby an MX960 with 4 x 10G links always hashes (uses) a

[j-nsp] LACP hashing algorithm

Hi all, This will sound like a very weird question, but has anyone seen a scenario whereby an MX960 with 4 x 10G links always hashes (uses) a single link out of the 40G bundle ? We have restarted the device, traffic flows in one direction only use a single link, the reverse path is all 4 links in

[j-nsp] LACP between router VMs

Hi folks, Slightly off topic but I'm gonna give it a shot anyways. Would anyone know how can I make linux bridges or better OVS to forward LACP PDUs instead of swallowing 'em? Basically "l2protocol forward lacp" equivalent. Couldn't find a single article on this and just can't believe I'm

Re: [j-nsp] LACP on mixed virtual chassis QFX5100/EX4300

novembre 2015 19:12 > To: Michael Loftis > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] LACP on mixed virtual chassis QFX5100/EX4300 > > Hello, > > Pretty sure QFX in 10G only, so if you want to achieve that, you'll have > to use a uplink module to have 10G on 4300

Re: [j-nsp] LACP on mixed virtual chassis QFX5100/EX4300

juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf >> Of Vincent Clement >> Sent: mercredi 4 novembre 2015 19:12 >> To: Michael Loftis >> Cc: juniper-nsp@puck.nether.net >> Subject: Re: [j-nsp] LACP on mixed virtual chassis QFX5100/EX4300 >> >> H

Re: [j-nsp] LACP on mixed virtual chassis QFX5100/EX4300

: [j-nsp] LACP on mixed virtual chassis QFX5100/EX4300 Auto-correct: seems I was wrong, I thought that because no negocation options on xe interfaces, but should be supported as you said. I'll make more tests, but I had trouble trying to connect 1G/100M on QFX5100-48T with old devices. Vincent

Re: [j-nsp] LACP on mixed virtual chassis QFX5100/EX4300

It isn't 10G only. They support 10g/1g/100m but I don't know if they do tri rate. And when you insert a 1G SFP it enumerates as ge-n/n/n not as xe- -- I have something like a dozen of these in production and a few 1G SFPs so not just guessing here. On Wednesday, November 4, 2015, Vincent Clement

Re: [j-nsp] LACP on mixed virtual chassis QFX5100/EX4300

Hi, On Wed, Nov 4, 2015 at 7:28 PM, Tobias Heister wrote: > Hi, > > Am 03.11.2015 um 23:23 schrieb ThienDuc Nguyen: > >> I was trying to create a LACP bundle between two ports : one on a EX4300, >> the other on a QFX5100. >> Both link have their speed negotiated at 1GE

Re: [j-nsp] LACP on mixed virtual chassis QFX5100/EX4300

] On Behalf Of Tobias Heister Sent: Wednesday, November 04, 2015 10:28 AM To: ThienDuc Nguyen; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] LACP on mixed virtual chassis QFX5100/EX4300 Hi, Am 03.11.2015 um 23:23 schrieb ThienDuc Nguyen: > I was trying to create a LACP bundle between two po

Re: [j-nsp] LACP on mixed virtual chassis QFX5100/EX4300

To: Chris Burton Cc: Tobias Heister; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] LACP on mixed virtual chassis QFX5100/EX4300 On Wed, Nov 4, 2015 at 11:03 PM, Chris Burton <chris.bur...@speakeasy.net> wrote: As far as I know there is no way to set the link speed (only the lin

Re: [j-nsp] LACP on mixed virtual chassis QFX5100/EX4300

Hello, Pretty sure QFX in 10G only, so if you want to achieve that, you'll have to use a uplink module to have 10G on 4300 side. Vincent 2015-11-04 2:23 GMT+01:00 Michael Loftis : > I'd take a closer look at show interfaces. When a link is 1gig QFX calls it > ge-. So you can

Re: [j-nsp] LACP on mixed virtual chassis QFX5100/EX4300

Hi, Am 03.11.2015 um 23:23 schrieb ThienDuc Nguyen: I was trying to create a LACP bundle between two ports : one on a EX4300, the other on a QFX5100. Both link have their speed negotiated at 1GE (but the interface name on the QFX is xe-, I can't force it to ge-, and their are no way to force

[j-nsp] LACP on mixed virtual chassis QFX5100/EX4300

Hi I was trying to create a LACP bundle between two ports : one on a EX4300, the other on a QFX5100. Both link have their speed negotiated at 1GE (but the interface name on the QFX is xe-, I can't force it to ge-, and their are no way to force the speed on the QFX). if I set the lacp speed to

Re: [j-nsp] LACP on mixed virtual chassis QFX5100/EX4300

I'd take a closer look at show interfaces. When a link is 1gig QFX calls it ge-. So you can have an ex-0/0/1 and a ge-0/0/1 but only one is active as I do not believe tri rate SFP+ is supported. On Tuesday, November 3, 2015, ThienDuc Nguyen wrote: > Hi > > I was trying

[j-nsp] LACP

Hi all. I need to create an LACP between two ex3300-24t. This can be done if one of the links transport provider allows me only 802.1Q and the other only 802.1ad. It might be possible to configure the LACP? I appreciate any insight that can be provided. Thank you, David

Re: [j-nsp] LACP

You do not want to do LACP (or any ae) over dissimilar links. You will be on a trail of tears of poor performance and wonky behavior. LACP/ae is NOT designed for dissimilar links. On Wed, Oct 14, 2015 at 8:15 AM, David Samaniego wrote: > Hi all. I need to create an LACP

Re: [j-nsp] LACP

On 10/14/15 2:54 PM, Michael Loftis wrote: > You do not want to do LACP (or any ae) over dissimilar links. You > will be on a trail of tears of poor performance and wonky behavior. > LACP/ae is NOT designed for dissimilar links. if they are nominally similar capacity l3 ecmp with and igp or bfd

Re: [j-nsp] LACP accept-data

Right but this is actually for LACP not the VRRP. adam -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of ashish verma Sent: 19 January 2015 22:09 To: juniper-nsp Subject: Re: [j-nsp] LACP accept-data yes we use it, haven't faced any

Re: [j-nsp] LACP accept-data

On Tuesday, January 20, 2015 08:56:25 AM Adam Vitkovsky wrote: Right but this is actually for LACP not the VRRP. Same. We have a ton of LACP-based LAG's between MX480's and EX4550's that are running VRRP with accept-data. No problem. I will say that feature parity between native and LAG

Re: [j-nsp] LACP accept-data

no? adam -Original Message- From: Mark Tinka [mailto:mark.ti...@seacom.mu] Sent: 20 January 2015 16:01 To: juniper-nsp@puck.nether.net Cc: Adam Vitkovsky; ashish verma Subject: Re: Re: [j-nsp] LACP accept-data On Tuesday, January 20, 2015 08:56:25 AM Adam Vitkovsky wrote: Right

Re: [j-nsp] LACP accept-data

On Monday, January 19, 2015 12:06:23 PM Adam Vitkovsky wrote: Is anyone using the accept-data knob under the lacp config on AE interfaces running as L3 please? Should be safe right? Yes, and yes. Mark. signature.asc Description: This is a digitally signed message part.

Re: [j-nsp] LACP accept-data

yes we use it, haven't faced any problems. You wont be able to ping the VRRP IP otherwise, required for testing etc. On Tue, Jan 20, 2015 at 12:33 AM, Daniel Roesen d...@cluenet.de wrote: Hi, On Mon, Jan 19, 2015 at 12:06:23PM +, Adam Vitkovsky wrote: Is anyone using the accept-data

[j-nsp] LACP accept-data

Hi Folks, Is anyone using the accept-data knob under the lacp config on AE interfaces running as L3 please? Should be safe right? adam --- This email has been scanned for email related threats and delivered

Re: [j-nsp] LACP/LAG

On Thursday, October 17, 2013 11:07:25 PM Bill Blackford wrote: I recently had to form a bundle between an EX and a Palo Alto Firewall. The PAN does *not* support LACP. Personally, I'd rather use LACP whenever and where ever it's supported. It too would be interested in hearing others views

[j-nsp] LACP/LAG

Hi. Any reason not to run LACP on a LAG link? Setting up a new LAG with some gear on our MX and have setup the AE interface and turned it up, but have not actually cut traffic over to it yet. They were saying run in passive or no LACP, with it just On cisco one does: channel-group x mode

Re: [j-nsp] LACP/LAG

I recently had to form a bundle between an EX and a Palo Alto Firewall. The PAN does *not* support LACP. Personally, I'd rather use LACP whenever and where ever it's supported. It too would be interested in hearing others views on the need for it. On Thu, Oct 17, 2013 at 2:00 PM, Keith

Re: [j-nsp] LACP/LAG

Resending with edits...doh. On 10/17/2013 2:00 PM, Keith wrote: Hi. Any reason not to run LACP on a LAG link? Setting up a new LAG with some gear on our MX and have setup the AE interface and turned it up, but have not actually cut traffic over to it yet. The vendor of the gear the MX is

Re: [j-nsp] LACP/LAG

LACP is great until you hit a box that is busy and doesn't offload this to the line card - for busy switches and firewalls, use periodic-slow instead of fast - I've had instances of EX and SRX that can't keep up with periodic-fast and the LAG ends up being torn down during commits. Bear in mind

Re: [j-nsp] LACP/LAG

Unless you like losing traffic or looping traffic stay away from unconditional channeling. There are a number of situations ranging from a failing linecard/port to a simple misconfig that will leave the links up but not properly functional. Possible issues... All traffic going down link X

Re: [j-nsp] LACP/LAG

Like most of the replies here, I usually run LACP where ever possible. Its a worth it for the added assurance that things are cabled correctly and both sides agree on port pairs. Having said that, there are some caveats: - On some hardware, certain features are not supported on AE interfaces,

Re: [j-nsp] LACP/LAG Between MX and Cisco

, September 24, 2013 1:38 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] LACP/LAG Between MX and Cisco Hi. We have a 3750X and an MX480 connected together. As the gig link between the two is now approaching capacity we will be turning up a LAG between the two. As the traffic is all coming in from

[j-nsp] LACP to NetApp

We have a mixed virtual chassis of two EX4500s and two EX4200s. They are connected to two NetApp filers. Each filer has a LACP aggregate to the VC consisting of two 10-Gig links to each of the 4500s (so four xe interfaces in each one). Once things are up and running, it works fine, but things do

Re: [j-nsp] LACP to NetApp

Date: Tue, 19 Feb 2013 10:43:07 -0800 From: Crist Clark cjc+j-...@pumpky.net Subject: [j-nsp] LACP to NetApp aggregated-ether-options { lacp { active; periodic slow; } } I prefer to always set fast active on either side. So far it has

Re: [j-nsp] LACP reliability?

On Thursday 20 December 2012 14:56:59 Morgan McLean wrote: Hi, I was just curious if anybody had feedback regarding LACP reliability when a system is under load etc. Wondering if its common for a box to come under load, stop sending LACP packets at their expected intervals and get dropped

[j-nsp] LACP reliability?

Hi, I was just curious if anybody had feedback regarding LACP reliability when a system is under load etc. Wondering if its common for a box to come under load, stop sending LACP packets at their expected intervals and get dropped by the upstream switch etc. I'm more interested about this

Re: [j-nsp] LACP reliability?

2012 9:57 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] LACP reliability? Hi, I was just curious if anybody had feedback regarding LACP reliability when a system is under load etc. Wondering if its common for a box to come under load, stop sending LACP packets at their expected intervals

Re: [j-nsp] LACP reliability?

On Thu, Dec 20, 2012 at 5:56 PM, Morgan McLean wrx...@gmail.com wrote: I'm more interested about this exchange between switch and linux server side, as I'm considering changing all of our ethernet bonds on the servers to LACP once I have all the top of rack switches VC'd. Definitely more

[j-nsp] LACP support on forwarding plane on M10i?

Is LACP supported on forwarding plane on M10i? According to Disabling Distributed Periodic Packet Management on the Packet Forwarding Engine(http://goo.gl/uDwYm) document LACP is supported on packet forwarding engine only on MX series. On the other hand, show pfe statistics traffic displays LACP

Re: [j-nsp] LACP support on forwarding plane on M10i?

@orange.com JNCIE-MT/SP #703 - JNCIE-ENT #305 - JNCIP-SEC -Message d'origine- De : juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] De la part de Martin T Envoyé : mardi 30 octobre 2012 16:16 À : juniper-nsp@puck.nether.net Objet : [j-nsp] LACP support

Re: [j-nsp] LACP support on forwarding plane on M10i?

#305 - JNCIP-SEC -Message d'origine- De : juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] De la part de Martin T Envoyé : mardi 30 octobre 2012 16:16 À : juniper-nsp@puck.nether.net Objet : [j-nsp] LACP support on forwarding plane on M10i? Is LACP

Re: [j-nsp] LACP Load Balance

Hi , Thanks all for the replies Regarding the version Router# run show version Hostname: Router Model: mx240 JUNOS Base OS boot [10.0R3.10] JUNOS Base OS Software Suite [10.0R3.10] JUNOS Kernel Software Suite [10.0R3.10] JUNOS Crypto Software Suite [10.0R3.10] JUNOS Packet Forwarding Engine

Re: [j-nsp] LACP Load Balance

Hi, You will not require symmetrical hashing. Just configure, set forwarding-options hash-key family inet layer-3 set forwarding-options hash-key family inet layer-4 Regards, On Wed, Aug 29, 2012 at 12:33 PM, Mohammad Khalil eng.m...@gmail.comwrote: Hi , Thanks all for the replies Regarding

Re: [j-nsp] LACP Load Balance

I have small question , should i implement this on family mpls as well ? Router# show interfaces ae1 flexible-vlan-tagging; mtu 1600; encapsulation flexible-ethernet-services; aggregated-ether-options { lacp { active; } } unit 0 { family bridge { interface-mode trunk;

Re: [j-nsp] LACP Load Balance

Yes, you can enable it for family mpls as well ... you need family mpls label-1, label-2 and payload ip under hash keys ... https://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/nog-mpls-frr/mpls-load-balancing-hash-key.html Remember, hash-keys are only

[j-nsp] LACP Load Balance

Hi I have two links connected between mx240 and EX4200 The configuration on the mx240 side router# show interfaces ge-2/0/1 speed 1g; link-mode full-duplex; gigether-options { 802.3ad ae1; router# show interfaces ge-2/1/0 speed 1g; link-mode full-duplex; gigether-options { 802.3ad ae1; }

Re: [j-nsp] LACP Load Balance

Also, you need to send a sizable number of flows to effect a proper distribution. A handful of flows is just not going to cut it, based on the below mentioned hash. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate Sent

Re: [j-nsp] LACP timers

On 02/05/12 12:27, bit.gos...@chello.nl wrote: Experts, do you know the values for the keepalive and holdtime timers for this protocol in the slow mode and fast mode? 1/3 and 30/90 for fast and slow, respectively. Assuming that is that by keepalive you mean interval between LACP PDUs and by

[j-nsp] LACP Mux State detached on MX960

Hi, I came across a new issue today which shows the lacp state detached on an AE/Physical interface on one of our mx960s. I bounced that interface, troubleshot physicals, removed the config out of the AE and put it back on, it's still the same. Has anyone seen this before? I'd like to know why

Re: [j-nsp] LACP Mux State detached on MX960

Hi, On Mon, Jan 17, 2011 at 12:04:42PM +0530, sanz wrote: I came across a new issue today which shows the lacp state detached on an AE/Physical interface on one of our mx960s. I bounced that interface, troubleshot physicals, removed the config out of the AE and put it back on, it's still the

[j-nsp] LACP issues with Microsoft Server and EX

Has anyone run into this error message with LACP configured between a EX and a Windows 2003 server? If so any corrections for it ? Jan 29 15:46:20 CLGRABMI-02-SW1 /kernel: ge-1/0/9: received pdu - length mismatch for lacp : len 128, pdu 124 Jan 29 15:46:20 CLGRABMI-02-SW1 /kernel:

[j-nsp] LACP

Hi all, I've A GEC established between a T640 and Cisco Switch CatOS On the Cisco CatOS, LACP is configured in mode ON and on the T640 I've no LCAP configuration on my AE. My AE is UP/UP on the T640 and on the CatOS. All it's fine, but I don't understand why, because in the Juniper config