Sok esetben a kisirodák is két internetszolgáltatót használnak a nagyobb rendelkezésre állás végett. Dinamikus routing protokollt ezekben az esetekben viszont nem lehet használni arra, hogy hibatűrő megoldást hozzunk létre, mely terheléselosztást is végez a linkek között. A következő példában az iroda egy Micro és egy MLLN kapcsolattal rendelkezik.

A következő feladatokat kell megoldanunk:

• NAT
• Terheléselosztás a két linken
• Bizonyos forgalmakat az egyik linken, másokat a másik linken kell kiküldeni
• Link meghibásodás detektálása

A NAT-olás megoldása egy picit trükkös. Normál esetben a forrás címek alapján tudnánk megmondani azt, hogy melyik publikus interfészre natoljuk a csomagokat. Ebben az esetben viszont a routing folyamat fogja meghatározni, hogy melyik interfészre küldje ki a router a csomagot, és ennek a döntésnek az eredménye szerint kell a NAT-ot elvégezni. Kimenő csomag esetén a NAT order of operation alapján először történik routing, aztán NAT.

A következő WAN és LAN interfészekkel rendelkezik a router:

interface FastEthernet0/1
description MLLN WAN
ip address 195.70.50.51 255.255.255.248
no ip redirects
no ip proxy-arp
ip nat outside     

interface Dialer1
description ADS Wan Dialer
ip address negotiated
ip nat outside
ip virtual-reassembly
encapsulation ppp
ip tcp adjust-mss 1452
no ip mroute-cache
dialer pool 1
dialer-group 1
no cdp enable
ppp authentication chap callin
ppp chap hostname ****
ppp chap password ****
ppp pap sent-username ****

Látható, hogy a Micro összeköttetés PPPoE kapcsolat, ezért a logikai beállításokat a dialer interfészen kell megtennünk. A router 3 switch porttal is rendelkezik, melyeket külön VLAN-ba raktunk a példa kedvéért.

interface FastEthernet0/0/0
description Workstation VLAN
switchport access vlan 100
!
interface FastEthernet0/0/1
description Shell VLAN
switchport access vlan 200
!
interface FastEthernet0/0/2
description Server VLAN
switchport access vlan 300

…

A VLAN interfészek konfigurációja:

interface Vlan100
description Workstation VLAN
ip address 10.0.10.254 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
 ip nat inside
ip virtual-reassembly
ip policy route-map InsideRoutes
!
interface Vlan200
description VLAN 200
ip address 10.0.100.254 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat inside
ip virtual-reassembly
ip policy route-map InsideRoutes
!
interface Vlan300
description Server VLAN
ip address 10.0.200.254 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat inside
ip virtual-reassembly
ip policy route-map InsideRoutes

Vegyük észre, hogy minden VLAN interfészen szerepel az ip nat inside parancs, hiszen a LAN oldal NAT szemszögből a belső hálózatot jelenti. A másik fontos parancs az ip policy route-map InsideRoutes , mely segítségével policy-route szolgáltatást rendelünk az interfészhez. Később bővebben szó lesz erről, de lényegében a policy-route segítségével felül tudjuk bírálni a globális routing táblát.

A csomagok címfordítását a következő parancsok segítségével állíthatjuk be:

ip nat inside source route-map MICRO interface Dialer1 overload
ip nat inside source route-map MLLN interface FastEthernet0/1 overload

Láthatjuk, hogy a NAT feltételt egy-egy route-map-hoz kötjük, melyek felépítése igen egyszerű:

route-map MLLN permit 10
match interface FastEthernet0/1

route-map MICRO permit 10
match interface Dialer1

A logika: Akkor natolom ki a csomagot a dialer1 interfész IP címére, ha a csomagot arra az interfészre route-olom. A NAT szabályok timeout-ját célszerű lehet csökkenteni a következő paranccsal:

ip nat translation timeout 60

A routing beállításánál szükségünk lesz két darab default route-ra, melyeknek köszönhetően az IOS terheléselosztást végez a két linken. Arra is oda kell figyelni azonban, hogy ha megszakad az egyik link, a router ne routoljon abba az irányba csomagokat. A PPPoE kapcsolat esetén ez nem probléma, abban az esetben ha megszakad, a dialer interfész down-ba megy. A bérelt vonallal az a probléma, hogy ott a fizikai interfész nem fog down-ba menni akkor, ha megszakad a kapcsolat a modem (mely egy külön eszköz) és a telco központ között. Ezért itt úgy nevezett object tracking feature-t kell használni. A statikus route-ok beállítása:

ip route 0.0.0.0 0.0.0.0 195.70.50.50 track 100
ip route 0.0.0.0 0.0.0.0 Dialer1
ip route 195.70.58.242 255.255.255.255 195.70.50.50

Fent a 195.70.50.50 cím az MLLN szolgáltató next-hop címe. A 195.70.58.242 cím az az MLLN szolgáltató hálózatának egy állomása, amit monitorozásra használunk (ICMP). A monitorozást IP SLA funkcióval lehet kivitelezni a következő módon:

Track objektumok létrehozása:

track 100 rtr 100 reachability
delay down 10 up 20
!
track 101 rtr 101 reachability
delay down 10 up 20

IP SLA funkciók:

ip sla 100
icmp-echo 195.70.58.242 source-interface FastEthernet0/1
timeout 500
frequency 3
ip sla schedule 100 life forever start-time now

ip sla 101
icmp-echo 195.70.50.94 source-interface Dialer1
timeout 500
frequency 3
ip sla schedule 101 life forever start-time now

Az IP SLA funkcióról bővebben itt olvashattok.

A forgalmakat különböző irányba route-olhatjuk policy-based routing segítségével.

route-map InsideRoutes permit 10
 match ip address Route_TO_MLLN
set ip next-hop verify-availability 195.70.50.50 5 track 100
!
route-map InsideRoutes permit 20
 match ip address Route_TO_MICRO
set ip next-hop verify-availability 195.70.50.94 5 track 101
!

Az InsideRoutes route-map segítségével ACL-ben határozhatjuk meg azokat a forgalmakat, melyeket máskép szeretnénk kezelni (match kulcsszó). Amennyiben nem elérhető a next-hop, az adott route-map rész nem lesz érvényes, és a global routing alapján dönt a csomag sorsáról a router. Az ACL-ek például a következő módon nézhetnek ki:

ip access-list extended Route_TO_MICRO
deny   tcp any any eq www
deny   tcp any any eq ftp
 permit tcp any any eq smtp

ip access-list extended Route_TO_MLLN
deny   tcp any any eq www
deny   tcp any any eq ftp

 permit   tcp any any eq 443
permit   tcp any any eq domain
permit   udp any any eq domain 

A fenti ACL-ek alapján a HTTPS és a DNS szerverek forgalmát a router az MLLN kapcsolatra, az SMTP forgalmat a MICRO kapcsolatra irányítja. A HTTP, FTP (és minden más forgalom) esetén a router forgalom-elosztást végez a két internet kapcsolat között a két default-route miatt.

Popularity: 37% [?]

Related posts:

1. BGP load-balancing serial linken Csináltam egy gyors tesztet a BGP működésével kapcsolatban. Két router...
2. DMZ network cisco PIX/ASA- val A következőkben röviden leírom hogy, lehet létrehozni DMZ network-öt...
3. MPLS VPN Labor Sikerült leadnom végre az önlab doksit, és el is fogadták....
4. Voice2: SIP Voice Gateway Úgy néz ki mostanában csak Voice-al kell foglalkoznom. Sajnos ez...
5. IPsec VPN Cisco PIX-el         Először egy egyszerűbb kisvállalati topológiával kezdeném,...