Jest to bardzo popularny scenariusz. Załóżmy, że posiadasz dwa łącza: jedno Frame Relay i jedno Ethernet. Do obu dostałeś adresy połączeniowe (styk Twój router-router ISP) oraz adresy do użycia w ramach NATu.

Pierwszy dostawca przydzielił Ci adres połączeniowy 169.254.10.2/30 (jego router ma dla Ciebie adres 169.254.10.1), oraz zakres adresów 172.16.10.1-172.16.10.14 (172.16.10.0/28).

Drugi dostawca przydzielił Ci adres połączeniowy 169.254.20.2/30 (jego router ma dla Ciebie adres 169.254.20.1), oraz zakres adresów 172.16.20.1-172.16.20.14 (172.16.20.0/28).

W swojej sieci LAN (192.168.0.0/24), chcesz pierwszą połowę sieci NATować na pierwsze łącze, a drugą połowę na drugie łącze.

Notatka: Niestety, stosując statyczny mechanizm routingu wg zasad (ang. policy based routing), nie masz możliwości automatycznemu przeciwdziałaniu awarii łącza lub sieci ISP - tj. jeśli zawiedzie któreś z łącz, ruch generowany od jednej z połówek sieci LAN będzie po prostu odrzucany.

Poniżej konfiguracja przykładowa routera, uwzględniająca powyższe założenia:

no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
service password-encryption
!
hostname rtr_cisco
!
enable password jakies_trudne_haslo
!
username user_1 password haslo_usera_1
ip subnet-zero
no ip source-route
no ip domain-lookup
ip tcp path-mtu-discovery
!
interface Ethernet0
 description Polaczenie dla sieci LAN
 ip address 192.168.0.1 255.255.255.0
 ip nat inside
 ip policy route-map ruch_z_lan
!
interface Ethernet1
 description Lacze od ISP #1
 ip address 169.254.10.2 255.255.255.252
 ip nat outside
!
interface Serial0
 description Lacze od ISP #2
 no ip address
 encapsulation frame-relay
 frame-relay lmi-type ansi
!
interface Serial0.1 point-to-point
 description Lacze do Internetu 2Mbit/s
 ip address 169.254.20.2 255.255.255.252
 frame-relay interface-dlci 99 IETF  
 ip nat outside 
!
ip classless
ip route 0.0.0.0 0.0.0.0 169.254.10.1
no ip http server
!
ip nat pool ISP1 172.16.10.1 172.16.10.14 netmask 255.255.255.240
ip nat pool ISP2 172.16.20.1 172.16.20.14 netmask 255.255.255.240
!
ip nat inside source list 1polowkaLAN pool ISP1 overload
ip nat inside source list 2polowkaLAN pool ISP2 overload
!
ip access-list extended 1polowkaLAN
 permit ip 192.168.0.0 0.0.0.127 any
ip access-list extended 2polowkaLAN
 permit ip 192.168.0.128 0.0.0.127 any
!
route-map ruch_z_lan permit 10
 match ip address 2polowkaLAN
 set ip next-hop 169.254.20.1
!
no cdp run
!
line con 0
 exec-timeout 5 0
 login local
line vty 0 4
 exec-timeout 5 0
 login local
!
end

Jak to działa? Do interfejsu Ethernet0 dociera ruch z sieci LAN, adresowany do Internetu. Route-mapa ruch_z_lan sprawdza, czy pakiet nie pasuje do ACL 2polowkaLAN. Jeśli pakiet pasuje, wpis w route-mapie mówi, że należy go wyroutować przez adres, dla którego następnym "hopem" będzie 169.254.20.1, czyli interfejs Serial0.1 (podsieć 169.254.20.0/30). Jeśli nie pasuje, route-mapa kończy testy i przekazuje pakiet do normalnego procesu routingu. W tablicy routingu znajduje się tylko jeden wpis statyczny - trasa wskazuje na pierwsze łącze:

ip route 0.0.0.0 0.0.0.0 169.254.10.1

Ponieważ w trakcie podróży, pakiet przechodzi pomiędzy interfejsem oznaczonym jako ip nat inside (interfejs Ethernet0) a jednym z dwóch interfejsów oznaczonych jako ip nat outside wykonywany jest NAT.

O kolejności sprawdzania na jaki zakres adresów zNATować pakiet, decyduje kolejność wpisów ip nat inside [...]. W naszej konfiguracji są dwa:

ip nat inside source list 1polowkaLAN pool ISP1 overload
ip nat inside source list 2polowkaLAN pool ISP2 overload

Wpisy te wprost mówią: pakiety z adresami źródłowymi pasującymi do ACL o nazwie 1polowkaLAN mają zostać zNATowane na adresy z puli ISP1, a pakiety z adresami źródłowymi pasującymi do 2polowkaLAN na pulę adresów ISP2.

Notatka: Warto zwrócić uwagę, że ruch można rozkładać nie tylko ze względu na adres/podsieć IP. Mógłbyś na przykład zechcieć kierować ruch dla typowych usług kierować na jedno łącze, a całą resztę na drugie - dzięki temu, użytkownicy popularnych aplikacji P2P, czy namiętni ściągacze wszystkiego co tylko można za pomocą FTP nie będą przeszkadzać czytającym pocztę.

Musisz zmienić ACLkę 2polowkaLAN:

ip access-list extended 2polowkaLAN
 permit tcp 192.168.0.0 0.0.0.255 any eq 22
 permit tcp 192.168.0.0 0.0.0.255 any eq 23
 permit tcp 192.168.0.0 0.0.0.255 any eq 25
 permit udp 192.168.0.0 0.0.0.255 any eq 53
 permit tcp 192.168.0.0 0.0.0.255 any eq 80
 permit tcp 192.168.0.0 0.0.0.255 any eq 110
 permit tcp 192.168.0.0 0.0.0.255 any eq 143
 permit tcp 192.168.0.0 0.0.0.255 any eq 445
 permit tcp 192.168.0.0 0.0.0.255 any eq 465
 permit tcp 192.168.0.0 0.0.0.255 any eq 993
 permit tcp 192.168.0.0 0.0.0.255 any eq 995
 permit icmp 192.168.0.0 0.0.0.255 any

Teraz ruch do serwerów popularnych usług oraz ruch ICMP będzie wychodził łączem, na które wskazuje route-mapa ruch_z_lan, a całą resztę ruchu router skieruje tam gdzie wskazuje zwykły wpis w tablicy routingu.

A co jeśli mam więcej łącz - na przykład 3?

Musisz dodać kolejne wpisy w route-mapie, wskazujące dla jakiegoś unikalnego typu ruchu kolejne interfejsy.

A co z lokalnym ruchem do/z routera?

W zasadzie całą konfigurację routingu można wykonać za pomocą routingu wg zasad (bez statycznego wpisu w tablicy routingu dotyczącego trasy domyślnej), ale wtedy musisz dodatkowo określić politykę dla tzw. ruchu lokalnego, czyli ruchu do/z routera.

Poniżej taki przykład - do konfiguracji z przykładu powyżej dodajemy definicję route-mapy, która kieruje ruch lokalny na oba łącza w zależności od tego, ruchu do jakiego IP dotyczył. Innymi słowy, jeśli ktoś np. spinguje Twój drugi interfejs, pasować będzie dopiero drugi wpis w route-mapie (RuchLokalny permit 20) i dopiero on spowoduje skierowanie pakietu odpowiedzi drugim łączem.

ip local policy route-map RuchLokalny
!
! dodajemy route-mapę dla ruchu lokalnego - jeśli robisz to zdalnie,
! powyższą komendę dodaj NA KOŃCU!
!
route-map RuchLokalny permit 10
 match ip address 100 
 set ip next-hop 169.254.10.1
 ! cały ruch pasujący do ACL 10 przerzuć na interfejs, dla którego następnym
 ! "hopem" jest 169.254.10.1 i zakończ sprawdzanie route-mapy
!
route-map RuchLokalny permit 20
 match ip address 101
 set ip next-hop 169.254.20.1
 ! jeśli tu doszedłeś, cały ruch pasujący do ACL 10 przerzuć na interfejs,

 ! dla którego następnym "hopem" jest 169.254.20.1
!
ip access-list extended 100
 remark ACL pasuje do ruchu do puli łącza ISP #1
 permit ip any 169.254.10.0 255.255.255.252
ip access-list extended 101
 remark ACL pasuje do ruchu do puli łącza ISP #2
 permit ip any 169.254.20.0 255.255.255.252

W tym momencie, możesz usunąć z routera wpis statyczny domyślnego routingu, wskazujący na pierwsze łącze.