I wanted to reach out to the community regarding a best practice or some insight / advice moving to 10G SFP's in our environment on 5200 Series. We have a CISCO Switch for Inet connected via 1G and utilizing 2 ports on the CISCO switch and 2 ports on the 5220 Via interface 5 and 6. I want to upgrade the SFP's from 1G Lag to a 10G Lag and wanted to see whats the best practice. We have 2 FW's in each data center so of course fail over and swap out the SFP from 1G to 10G and is there any configuration that needs to change for link speed if set to auto? Thank YOU!
Currently setup on ethernet 1/5 and ethernet 1/6 as a Internet LAG - 1G Copper SFP (active)
On the one hand you have to consider the correct detail of the interfaces: PA-5220: 100/1000/10G Cu (4), 1G/10G SFP/SFP+ (16), 40G QSFP+ (4).
In this case you need SFP+ to reach Tengiga on one of the 16 compatible interfaces you have available.
The next point is the end of the switch you need to have a SFP+, i.e. a Tengiga compatible module, for connectivity between Palo Alto and your switch. Example for the PA GBIC SFP+ Palo Alto Networks - 10GBASE-SR - Multimode Fiber.
On the Palo Alto side consider, if you are going to set up the Portchannel/Aggregate Ethernet (known in Palo Alto), you should consider 2 ports for each Firewall, i.e. 2 ports on the Active side and 2 ports on the Passive side, thinking about the HA.
Now on the switch side you must generate two portchannels using LACP, 1 for the Active that includes the two interfaces to the Active, and another two for the passive, for connectivity with the secondary.
Now recommendations, at the HA level, I recommend two configurations when you are setting this up.
1.- Set passive state interface to Auto, this will help you when you make connections to the secondary and validate that the interfaces between the secondary and the portchannel interfaces with the switch are up.
So you can check the detail:
2.- Pre-negotiation of LACP in the secondary equipment. With this you gain speed at the time of computation in case of a FailOver and on the other hand, when you connect to the secondary, it can be negotiating LACP, this helps a lot to tshoot issues to validate that both the portchannel of the active and the secondary are negotiating. This helps a lot because otherwise, you would have to perform a failover test just to validate that the LACP portchannel is set up correctly.
Thank you apologies for the late response this is my current configuration with 1G in copper but in a LAG,see screenshot i assume its recommended to have a lag in place? Keep in mind This is our internet FW and connected to our cisco internet switch. Utilizing LACP do you have any other recommendations or anything to look out for? Thanks!
Hello @Kenneth716 of course.
Now thinking about Internet access not the LAN/Trust side.
Let's say "Ideal" or something more ambitious.
If you have a stack of switches, for example Cisco, you connect your ISP links to the stack.
You can have your LAG/AE/portchannel in cross-stack ethernchannel (e.g. two switches).
Create a LACP portchannel in the stack.
Portchannel 1 ( Active ):: One interface on the upper switch and one on the lower switch.
Portchannel 2( Passive ):: One interface on the upper switch and one on the lower switch.
Then in the PA you configure LACP with two interfaces, one that will connect in the upper switch of the stack and another one in the lower switch.
The same with the passive, one interface on the top stack and one on the bottom switch.
With this you have on one side high availability of links, in case of failure of the switch one of the stack the traffic continues in the active FW and flowing through the lower switch of the stack in a transparent way and also when it is all operative the fact of having more bandwidth capacity by the LAG.
If you do not have a switch stack, just remember to set up two port.channels, one for the active and one for the passive.
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 LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!