Small-Site Multihoming

Ivan Pepelnjak hat in seinen sehr lesenswerten Artikeln Small Site Multi-homing, Redundant Small Site Multi-homing und Servers in Small Site Multi-homing sehr schön beschrieben, wie man sich als kleiner Kunde mit mehreren Providern verbinden kann. Eine sehr wichtige Topologie fehlt allerdings: Wie implementiert man Server, wenn man mit zwei Routern an unterschiedlichen ISPs angeschlossen ist:

Dort ist das Problem des asymmetrischen Traffics etwas aufwendiger zu lösen.
Wie in dem Dokument Servers in Small Site Multi-homing beschrieben, hat der Server zwei zusätzliche IP-Adressen, für die auf den zwei Routern jeweils ein statischer NAT-Eintrag vorhanden ist.

Wenn man für den Server annimmt, daß dieser für das Mail-Handling zuständig ist, dann muss man annehmen, daß über beide ISPs Mails eingeliefert werden, egal ob der MX mit der höheren Priorität erreichbar ist oder nicht.

Die Grundkonfig der Router könnte folgendermaßen aussehen (anstelle des Intrerface-Trakings könnte man besser auch “ip sla” verwenden):

hostname R1
!
interface FastEthernet0/0
 ip address 10.10.10.1 255.255.255.0
 ip nat inside
 standby 0 ip 10.10.10.3
 standby 0 priority 105
 standby 0 preempt
 standby 0 track FastEthernet0/1
!
interface FastEthernet0/1
 ip address 192.168.1.1 255.255.255.0
 ip nat outside
!
ip nat pool ISP-A-POOL 192.168.1.11 192.168.1.11 prefix-length 24
ip nat inside source list INSIDE-HOSTS pool ISP-A-POOL overload
ip nat inside source static 10.10.10.101 192.168.1.101 extendable
!
ip access-list standard INSIDE-HOSTS
 permit 10.10.10.0 0.0.0.255

hostname R2
!
interface FastEthernet0/0
 ip address 10.10.10.2 255.255.255.0
 ip nat inside
 standby 0 ip 10.10.10.3
 standby 0 preempt
!
interface FastEthernet0/1
 ip address 192.168.2.1 255.255.255.0
 ip nat outside
!
ip nat pool ISP-B-POOL 192.168.2.12 192.168.2.12 prefix-length 24
ip nat inside source list INSIDE-HOSTS pool ISP-B-POOL overload
ip nat inside source static 10.10.10.102 192.168.2.102 extendable
!
ip access-list standard INSIDE-HOSTS
 permit 10.10.10.0 0.0.0.255

Der Traffic fließt hier folgendermaßen:

• Vom Server ausgehender Traffic (schwarz) fließt zum aktiven HSRP-Router und bekommt eine Adresse aus dem ISP-A-POOL.
• Von außen initiierter Traffic auf die 192.168.1.101 (grün) fließt über den aktiven Router zurück und NAT läuft wie erwartet.
• Von aussen initiierter Traffic auf die 192.168.2.102 (rot) fließt ebenfalls über den aktiven Router zurück. NAT behandelt diesen Traffic wie vom Server ausgehenden Traffic und das Antwort-Paket bekommt ebenfalls eine Absender-Adresse aus dem ISP-A-POOL, mit der der Client nichts anfangen kann.

Auf dem Switch PBR zu konfigurieren ist aufgrund der PBR-Implementierung vermutlich keine Option (3750: nur auf routed Interface oder SVI, IP Services Image, kein PBR bei gemeinsamen IPv4 und IPv6).
Auf dem Server die Konfiguration vorzunehmen ist evtl. auch nicht möglich oder gewollt.
Auf dem Router R1 ist es allerdings relativ einfach umzusetzen:

ip access-list extended TRAFFIC-FROM-102
 permit ip host 10.10.10.102 any
!
route-map POLICY-INSIDE-IN permit 10
 match ip address TRAFFIC-FROM-102
 set ip next-hop 10.10.10.2
!
interface FastEthernet0/0
 ip policy route-map POLICY-INSIDE-IN

Jetzt ergibt sich der Traffic-Fluß wie es gewünscht ist:

Jetzt kommt natürlich noch die IOS-Firewall und eingehende ACLs auf beiden Interfaces hinzu.
Dafür muss die Konfiguration noch etwas erweitert werden. Zum einen müssen sowohl eingehende, als auch ausgehende Antwortpakete per Inspection erlaubt werden, da die ACLs ein abschließendes deny any haben sollten. Zum anderen muss der Traffic, der per PBR umgeroutet wird, auch in der ACL erlaubt werden, da die ACL vor dem Policy-Based Routing abgearbeitet wird (hier könnte man natürlich zwischen einer aus- und eingehenden FW-Policy unterscheiden):

ip inspect name FW tcp router-traffic
ip inspect name FW udp router-traffic
ip inspect name FW icmp router-traffic
!
interface FastEthernet0/0
 ip access-group INSIDE-IN in
 ip inspect FW out
!
interface FastEthernet0/1
 ip access-group OUTSIDE-IN in
 ip inspect FW out
!
ip access-list extended INSIDE-IN
 permit ip host 10.10.10.102 any
 !permit whatever you want
ip access-list extended OUTSIDE-IN
 permit tcp any host 192.168.1.101 eq smtp

Abschließend natürlich noch der Hinweis, daß dieser Server sinnvollerweise als Mail-Relay in der DMZ implementiert sein sollte. Der “richtige” Mail-Server steht dann intern und bekommt seine Mails von dem Relay.