Boa leitura, abaixo texto da documentação oficial que tenho da subscrição gold.
Boa leitura
Layer 2 Redundancy
The diagrams earlier in this chapter did not describe layer 2 (switch) redundancy, to avoid throwing
too many concepts at readers simultaneously. Now that you have an understanding of hardware
redundancy with pfSense, this section covers the layer 2 design elements you should consider when
planning a redundant network. This chapter assumes a two system deployment, though this scales to
as many installations as you require.
If both your redundant pfSense systems are plugged into the same switch on any interface, that switch
becomes a single point of failure. To avoid this single point of failure, the best choice is to deploy two
switches for each interface (other than the dedicated pfsync interface).
The Routed IPs diagram is network-centric, not showing the switch infrastructure. The Figure 25.12,
“Diagram of HA with Redundant Switches” illustrates how that environment looks with a redundant
switch infrastructure.
Switch Configuration
When using multiple switches, you should interconnect them. As long as you have a single connection
between the two switches, and do not bridge on either of the firewalls, this is safe with any type of
switch. Where using bridging, or where multiple interconnections exist between the switches, care
must be taken to avoid layer 2 loops. You will need a managed switch that is capable of using Spanning
Tree Protocol (STP) to detect and block ports that would otherwise create switch loops. When using
STP, if an active link dies, e.g. switch failure, then a backup link can automatically be brought up
in its place.
In pfSense 2.0 and higher, support also exists for lagg(4) link aggregation and link failover interface
which will allows you to have multiple network interfaces plugged into one or more switches for
increased fault tolerance. See the section called “LAGG (Link Aggregation)” for more information
on configuring link aggregation.
Host Redundancy
It is more difficult to obtain host redundancy for your critical systems inside the firewall. Each system
could have two network cards and a connection to each group of switches using Link Aggregation
Control Protocol (LACP) or similar vendor-specific functionality. Servers could also have multiple
network connections, and depending on the OS you may be able to run CARP on a set of servers so
that they would be redundant as well. Providing host redundancy is more specific to the capabilities
of your switches and your server operating system, which is outside the scope of this book.
Other Single Points of Failure
When trying to design a fully redundant network, there are many single points of failure that sometimes
get missed. Depending on the level of uptime you are hoping to achieve, there are more and more
things to consider than a simple switch failure. Here are a few more examples for redundancy on a
wider scale:
• Each redundant segment should have isolated power.
Firewall Redundancy /
High Availability
487
• Redundant systems should be on separate breakers.
• Use multiple UPS banks/generators.
• Use multiple power providers, entering opposite sides of the building where possible.
• Even a Multi-WAN configuration is no guarantee of Internet uptime.
• Use multiple Internet connection technologies (DSL, Cable, T1, Fiber, Wireless).
• If any two carriers use the same pole/tunnel/path, they could both be knocked out at the same time.
• Have backup cooling, redundant chillers or a portable/emergency air conditioner.
• Consider placing the second set of redundant equipment in another room, another floor, or another
building.
• Have a duplicate setup in another part of town or another city. Why buy one when you can buy
two for twice the price?
• I hear hosting is cheap on Mars, but the latency is killer.
