Aggregate Ethernet interface: LACP and PaGP support

Announcements

ATTENTION Customers, All Partners and Employees: The Customer Support Portal (CSP) will be undergoing maintenance and unavailable on Saturday, November 7, 2020, from 11 am to 11 pm PST. Please read our blog for more information.

Reply
Highlighted
L2 Linker

Aggregate Ethernet interface: LACP and PaGP support

Hello, Everybody,

we would like to aggregate ethernet interfaces of our PA-5050 (4.1.7 PANOS) in order to have a redundant physical connection towards our Cisco Catalyst switches.

Sound like LACP is not working with PAN and we had to set PaGP, which, on the other hand, cannot be configured to aggregate interfaces of different Catalyst switches, even if configured as a single virtual switch (i.e. Cisco VSS configuration for Catalyst 6500 and 3750 stack),

Do you confirm that LACP is not supported by 4.1.7 PA-5050? Is Cisco proprietary PaGP officially supported? Is there any roadmap for LACP too?

Thanks and Regards!


Accepted Solutions
Highlighted
L7 Applicator

A little more insight here:

Q1) Also even if PA link aggregation is static, how does this blend with equipment that doesnt understand link aggregation?

A1) Unpredictable results.  I do not recommend doing this.

Q2) As followup for above question, how does PA deal with when the switch can loadbalance on src-dst-ip (which a cisco can be put into with "port-channel load-balance src-dst-ip", or for that matter src-dst-port)?

A2) With link-aggregation, the sending/transmitting device decides independently which link to send certain packets down.  The receiving end is prepared to receive any packet on either port.  (Which is why #1 is not recommended).  The load-balancing algorithm does not need to match up, either.  If one side sends round-robin, and the other side does a hash on src/dst IP/mac/port, etc. that will work just fine.

Keep in mind that PAN-OS supports standards-based link aggregation.  I have successfully configured link-aggregation with Juniper, Cisco, and Brocade/Foundry equipment.  They all understand "static" link-aggregation.  In the Cisco world this is "mode on", in the Foundry world this is "trunk ethernet" or "lag static" and in the Juniper world you create the aggregate-ethernet interface w/o configuring LACP (from what I remember).  This works with single switches, as well as "stacks" of switches and "virtual chassis".

Hope that helps.

View solution in original post


All Replies
Highlighted
L6 Presenter

Here is a similar thread that can help you with this.

https://live.paloaltonetworks.com/thread/1459?tstart=0

Highlighted
L2 Linker

Thanks, I've found similar threads at , , Cisco Link Aggregation Traffic Through a PAN Device

Some people says "mode on" is working, someone else suggests "mode passive", but both sound like a workaround and I would be interested in knowing if PAN roadmap is with or without LACP support.

Highlighted
L6 Presenter

Currently PAN doesnot support LACP. I am not sure about the future implementations. Please make a feature request with your Sales team as this will increase the chances of future implementations.

Highlighted
L6 Presenter

1) Also even if PA link aggregation is static, how does this blend with equipment that doesnt understand link aggregation? Will there be a loop or is PA using TLB (transmission load balancing)?

2) As followup for above question, how does PA deal with when the switch can loadbalance on src-dst-ip (which a cisco can be put into with "port-channel load-balance src-dst-ip", or for that matter src-dst-port)?

Meaning packet PA -> switch goes over one physical link while switch -> PA goes over a different physical link (but part of the same aggregated interface in the PA configuration).

Or for that matter, how does the PA "loadbalance" between the physical interfaces which are part of the aggregated interface?

3) Speaking of link aggregation a far worse "feature" is that aggregated interfaces currently doesnt support QoS in PA.

So if you need QoS and aggregated interfaces at the same time (like for performance reasons) then you are screwed...

The good part is that (according to latest info from my sales engineer so this might change in future) this is said to be fixed hopefully in PANOS 5.1 - the bad part is that 5.1 is currently estimated not sooner than summer 2013...

Highlighted
L6 Presenter

I guess I can answer 2 above for myself :smileysilly:

https://live.paloaltonetworks.com/docs/DOC-3594

"

Sessions originating from the firewall will be sent through the links using a round-robin method.

"

So far so good, like src-dst-port if compare to cisco.

"

Device sending traffic to the firewall via the aggregated link also needs to be configured for load balancing.

"

Now what? Will the PA drop the traffic if the packet is sent on int1 PA->switch but the reply arrives at int2 switch->PA?

This also mean that if using cisco one MUST configure it to use src-dst-port as loadbalance method where the default src-dst-mac wont work at all (given that the PA will drop packets that returns at a different interface than it was sent on given that both interfaces are part of the same aggregated interface)?

Highlighted
L6 Presenter

""Now what? Will the PA drop the traffic if the packet is sent on int1 PA->switch but the reply arrives at int2 switch->PA? "". PA should not drop this traffic because it sees both the interfaces as one logical aggregate interface, although I have not tested this myself.



Highlighted
L7 Applicator

A little more insight here:

Q1) Also even if PA link aggregation is static, how does this blend with equipment that doesnt understand link aggregation?

A1) Unpredictable results.  I do not recommend doing this.

Q2) As followup for above question, how does PA deal with when the switch can loadbalance on src-dst-ip (which a cisco can be put into with "port-channel load-balance src-dst-ip", or for that matter src-dst-port)?

A2) With link-aggregation, the sending/transmitting device decides independently which link to send certain packets down.  The receiving end is prepared to receive any packet on either port.  (Which is why #1 is not recommended).  The load-balancing algorithm does not need to match up, either.  If one side sends round-robin, and the other side does a hash on src/dst IP/mac/port, etc. that will work just fine.

Keep in mind that PAN-OS supports standards-based link aggregation.  I have successfully configured link-aggregation with Juniper, Cisco, and Brocade/Foundry equipment.  They all understand "static" link-aggregation.  In the Cisco world this is "mode on", in the Foundry world this is "trunk ethernet" or "lag static" and in the Juniper world you create the aggregate-ethernet interface w/o configuring LACP (from what I remember).  This works with single switches, as well as "stacks" of switches and "virtual chassis".

Hope that helps.

View solution in original post

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!