Möchte man bei einer Fortigate zweit WAN Zugänge oder ISPs anschliessen, z.B. für Backup oder Lastverteilung kommt man zu dem Punkt: Wie geht das?

Szenario:
Einen Provider am WAN1 (schnelle Leitung)
zweiten Provider am WAN2 (langsamere Verbindung)

Wie kann man vorgehen?
Legt man zwei default Routen mit unterschiedlichen Metriken an ist nur die mit der besseren Metrik in der Routingtabelle, d.h. es wird nur die bessere Route genutzt, Verbindungen über die andere Leitung schlägt fehl (RPF wird das wohl verhindern).

Also trägt man zwei default Routen mit gleicher Metrik an!
Jetzt macht die Fortigate standardmäßig ECMP – also Lastverteilung. Beide Leitungen werden genutzt. Leider schert sich die Fortigate nicht um die Bandbreite (ggf kann man da in den aktuellen Versionen mit weightend ECMP was drehen), wird also recht fix die langsamere Leitung überlasten.

Die Lösung: Prioritäten für Routen. Das ist ähnlich wie Metriken, verhindert aber nicht das die Route aus der Routing Tabelle verschwindet. Sind zwei Routen zum Ziel da wird die mit der niedrigeren Priorität gewählt. bei gleicher Prio greift wieder ECMP.
Dadurch die Route in der Routing Tabelle vorhanden ist kann man Sessions über beide WAN Verbindungen aufbauen und mittel Policy Routing auch einzelnen Traffic über eine WAN Strecke forcieren (z.B. http Traffic über die langsamere Verbindung).

Die Prioritäten kann man nur über die CLI einrichten.
Beispiel:

config router static
show

Die entsprechenden Einträge anpassen
edit 1
" set device ""wan1"""
set gateway 192.168.1.100
set priority 1
next
edit 2
" set device ""wan2"""
set priority 5
set gateway 172.16.31.254
next
In diesem Fall würde der Traffic defaultmäßig über WAN1 gehen (niedrigere Priorität), aber eingehender Verkehr über WAN2 wird erlaubt. Fällt WAN1 weg geht der Verkehr über WAN2.

Natürlich muss man sich noch um passende VIPs/ACLs an den entsprechenden Interfaces kümmern und auch DNS im Hinterkopf behalten.

Die ASA von Cisco hat sowas meines Wissens nicht, es gibt immer nur eine aktive Defaultroute Loadbalancing kann sie nicht. Ein Failover kann man ggf mit SLAs.

Zur redundanten Anbindung und zur Erhöhung der Ausfallsicherheit verbindet man Gerät gern mit mehr als einem Kabel sowohl in Ringstrukturen als auch zu einem anderen Gerät. Spanning Tree verhindert dabei Loops. Verbindet man z.B. 2 Core Switche mit mehreren Kabeln kann man auch einer höhere Bandbreite nutzen.

Switch 1:
# conf t
(config)#int port-channel 1
(config-if)#
(config-if) description "Channel zu Core-2"
(config-if) switchport
(config-if) switchport mode trunk
(config-if)exit
(config)#int range te1/1-2
(config-if-range)# description "10gig to Core2
(config-if-range) switchport mode trunk
(config-if-range) channel-group 1 mode desirable
(config-if-range)end

Switch 2 ist analog, also:
# conf t
(config)#int port-channel 1
(config-if)#
(config-if) description "Channel zu Core-2"
(config-if) switchport
(config-if) switchport mode trunk
(config-if)exit
(config)#int range te1/1-2
(config-if-range)# description "10gig to Core2
(config-if-range) switchport mode trunk
(config-if-range) channel-group 1 mode desirable
(config-if-range)end


Verifizieren:
#sh etherchannel summary
Flags: D - down P - bundled in port-channel
I - stand-alone s - suspended
R - Layer3 S - Layer2
U - in use f - failed to allocate aggregator

M - not in use, minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
Number of channel-groups in use: 1
Number of aggregators: 1
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
1 Po1(SU) PAgP Te1/1(P) Te1/2(P)


Defaultmäßig wird ein anhand von Destination Mac bzw. Destination IP im Load Balancing Algorithmus festgelegt welcher Link im Etherchannel benutzt wird. Das kann bei genutzt das kann aber bei vielen Verbindungen zwischen den selben Systemen zu einer einseitigen Nutzung des Channels kommen. mittels
port-channel load-balance src-dst-port
kann man z.B. Src und Destination Port als Kriterium wählen.

Firmware auf beide ASAs kopieren, ggf passendes asdm auf die ASA bringen.

Diese beim nächsten Start benutzen
boot system disk0:/asa804-k8.bin
asdm image disk0:/asdm-61551.bin
Abspeichern nicht vergessen !!!:
wr mem

ACHTUNG: die firmwares werden nicht auf die standby Unit gesynct, die Konfiguration schon.. daher müssen die Firmwares auf beide ASAs kopiert werden. einfach geht das per ASDM einmal auf die aktiv einmal auf die passive IP und dann hochladen per Browser alternativ tftp o.ä.

wir vergewissern uns das wir auf der activen ASA sind:

ASA# sh failov state
State Last Failure Reason Date/Time
This host - Primary
Active None
Other host - Secondary
Standby Ready None
====Configuration State===
Sync Done - STANDBY
====Communication State===
Mac set


This host Primary Active.. gut!

Wir starten die stanby unit neu:
failover reload-standby
warten bis die Replikation der Konfig abgeschlossen ist (mit sh failover state vergewissern das die andere standby ready ist) und geben die Active Rolle im Cluster an die neugebootete Kiste ab:
no failover active

Dann starten wir die, jetzt im Standby laufende, Maschine (noch alte Firmware) neu indem wir uns wieder auf die aktive ASA verbinden und dann wieder
failover reload-standby
eingeben.

Generell ist es aber egal welche Maschine gerade aktiv ist, daher braucht man danach nicht wieder zurückzuschwenken (außer man will das immer die aktive ASA in Rack X steht)