Cisco NAT, Load Balancing, Policy Routing, Failover – част 3
производител: cisco
Тази статия е продължение на:
NAT Cisco router с един или два провайдера на Интернет част 1 и част 2
Cisco Load Balancing
Терминът Load Balancing представлява функционалностa на един рутер, който препраща пакети през два или няколко маршрута по подразбиране default gateway в layer 3 мрежов слой.
Cisco IOS софтуера основно поддържа два режима на load balancing: На база дестинация (per-destination), или за всеки пакет (per-packet). Тук ще обсъдим load balancing per-destination като по надеждно и ефективно решение.
CEF Load-Balancing
Cisco Express Forwarding представлява информация за комбинацията между източник и дестинация на пакети. CEF позволява да се оптимизират ресурсите с преноса на данни по множество маршрути.
Per-Destination Load Balancing
Per-destination load balancing позволява на рутера да използва множетсво маршрути споделяйки натоварването между много източници и дестинации. Пакетите от един определен източник към определена дестинация са гарантирани дори ако има други налични маршрути на разположение. Пакетите от един определен източник към две различни дестинации вероятно ще поемат по различни маршрути ако има налични такива.
Per-destination load balancing се активира по подразбиране ако разрешите Cisco Express Forwarding (CEF). За да използвате per-destination load balancing няма нужда да изпълнявате други команди освен ip cef в конфигурационен режим.
Ако използвате per-destination load balancing, ви се гарантира, че пакети към определен хост ще пристигнат винаги подредени и, че всички пакети, предназначени за определен хост ще преминат през един и същ маршрут.
Cisco Express Forwarding (CEF) е съвремена layer 3 IP технология за маршрутизация. CEF оптимизира мрежoвата производителност в мрежи с големи натоварвания и множество връзки. Не е подходяща за тесни канали тъй като не може да гарантира равни порции пакети между интерфейсите, в случай, че се повиши трафика към определена дестинация ще се препълни канала и съответно ще се влоши свързаноста.
Топология на мрежата
Конфигурация
! ip cef ! ip dhcp pool pool1 network 192.168.10.0 255.255.255.0 default-router 192.168.10.1 dns-server 208.67.222.222 208.67.220.220 ! ip name-server 208.67.222.222 ip name-server 208.67.220.220 ! track 100 rtr 100 reachability delay down 10 up 20 ! track 200 rtr 200 reachability delay down 10 up 20 ! interface FastEthernet0 description GCN ip address 10.125.3.2 255.255.255.0 ip nat outside ip virtual-reassembly ip policy route-map GCN duplex auto speed auto ! interface FastEthernet1 description MTEL ip address 85.118.95.35 255.255.255.224 no ip proxy-arp ip nat outside ip virtual-reassembly ip policy route-map MTEL duplex auto speed auto ! interface Vlan10 description LAN ip address 192.168.10.1 255.255.255.0 no ip proxy-arp ip nat inside ip virtual-reassembly ip tcp adjust-mss 1452 ! ip route 0.0.0.0 0.0.0.0 85.118.95.33 track 100 ip route 0.0.0.0 0.0.0.0 10.125.3.1 track 200 ip route 8.8.4.4 255.255.255.255 85.118.95.33 ip route 8.8.8.8 255.255.255.255 10.125.3.1 ! ip nat inside source route-map GCN interface FastEthernet0 overload ip nat inside source route-map MTEL interface FastEthernet1 overload ! ip sla 100 icmp-echo 8.8.4.4 source-interface FastEthernet1 timeout 500 frequency 10 ip sla schedule 100 life forever start-time now ip sla 200 icmp-echo 8.8.8.8 source-interface FastEthernet0 timeout 500 frequency 10 ip sla schedule 200 life forever start-time now ! access-list 1 permit 192.168.10.0 0.0.0.255 ! route-map MTEL permit 10 match ip address 1 match interface FastEthernet1 set ip next-hop 85.118.95.33 ! route-map GCN permit 10 match ip address 1 match interface FastEthernet0 set ip next-hop 10.125.3.1 ! |
no ip proxy-arp
Трябва да се обърне специално внимание на no ip proxy-arp в горната конфигурация на interface часта. Задължително е когато правим load balancing или policy local правила да се опише на WAN порта, че не искаме proxy-arp защото в противен случай може да очаквате изненади от доставчика си на Интернет сигнализирайки му неговия Spanning Tree Protocol
Състояние на маршрутите
Важно е да обърнем внимание на реда universal per-destination load sharing algorithm
cisco#show ip cef detail IP CEF with switching (Table Version 58), flags=0x0 30 routes, 0 reresolve, 0 unresolved (0 old, 0 new), peak 4 14 instant recursive resolutions, 0 used background process 30 leaves, 21 nodes, 26456 bytes, 61 inserts, 31 invalidations 1 load sharing elements, 376 bytes, 1 references universal per-destination load sharing algorithm, id 6593AC3E 3(0) CEF resets, 5 revisions of existing leaves Resolution Timer: Exponential (currently 1s, peak 1s) 8 in-place/0 aborted modifications refcounts: 5724 leaf, 5632 node Table epoch: 0 (30 entries at this epoch) Adjacency Table has 11 adjacencies 0.0.0.0/0, version 45, epoch 0, per-destination sharing 0 packets, 0 bytes via 85.118.95.33, 0 dependencies, recursive traffic share 1 next hop 85.118.95.33, FastEthernet1 via 85.118.95.33/32 valid adjacency via 10.125.3.1, 0 dependencies, recursive traffic share 1 next hop 10.125.3.1, FastEthernet0 via 10.125.3.1/32 valid adjacency |
Състояние на интерфейсите
Тук е събрана информацията само която ни интересува
cisco#show ip interface fastEthernet 0 FastEthernet0 is up, line protocol is up [...] Internet address is 10.125.3.2/24 Broadcast address is 255.255.255.255 IP CEF switching is enabled IP CEF Feature Fast switching turbo vector IP route-cache flags are Fast, CEF Policy routing is enabled, using route map GCN Network address translation is enabled, interface in domain outside [...] |
cisco#show ip interface fastEthernet 1 FastEthernet1 is up, line protocol is up [...] Internet address is 85.118.95.35/27 Broadcast address is 255.255.255.255 IP CEF switching is enabled IP CEF Feature Fast switching turbo vector IP route-cache flags are Fast, CEF Policy routing is enabled, using route map MTEL Network address translation is enabled, interface in domain outside [...] |
Тест към различни дестинации
Изпълнявайки traceroute от клиент зад рутера към различни дестинации забелязвам, че пътя до тях винаги е един и същ
Графика на натоварването
Policy Base Routing с Failover
Load balancing е хубаво нещо но в реални условия понякога се налага той да се изключи за определен потребител или мрежа, тоест да ползва само единия доставчик на Интернет. Причини за това да имаш изходящ трафик винаги от един и същи адрес има много. В същото време този потребител или мрежа безусловно трябва да участва във fajlover-a за да се гарантира тяхната свързаност при отпадане на маршрута по подразбиране. Как може да стане това като запазим цялоста на конфигурацията до тук. Създавам нов route-map PBR, с ip next-hop същите маршрути по подразбиране с опцията verify-availability метрика и track. Съответния route-map го закчвам с ip policy зебележете вече в LAN интерфейса VLAN 10.
! access-list 110 permit ip host 192.168.10.99 any access-list 120 permit ip host 192.168.10.98 any ! route-map PBR permit 10 match ip address 110 set ip next-hop verify-availability 85.118.95.33 1 track 100 set ip next-hop verify-availability 10.125.3.1 2 track 200 ! route-map PBR permit 20 match ip address 120 set ip next-hop verify-availability 85.118.95.33 2 track 100 set ip next-hop verify-availability 10.125.3.1 1 track 200 ! interface Vlan10 description LAN ip address 192.168.10.1 255.255.255.0 ip nat inside ip virtual-reassembly ip tcp adjust-mss 1452 ip policy route-map PBR ! |
Естествено трябва да проверим нашите нови маршрутни таблици какво ще ни покажат. Всичко което е в access-lists 110 ще има маршрут по подразбиране 85.118.95.33 а при отпадането му 10.125.3.1. Всичко което е в access-lists 120 ще има маршрут по подразбиране 10.125.3.1 а при отпадането му 85.118.95.33
cisco#show route-map PBR route-map PBR, permit, sequence 10 Match clauses: ip address (access-lists): 110 Set clauses: ip next-hop verify-availability 85.118.95.33 1 track 100 [up] ip next-hop verify-availability 10.125.3.1 2 track 200 [up] Policy routing matches: 951 packets, 141746 bytes route-map PBR, permit, sequence 20 Match clauses: ip address (access-lists): 120 Set clauses: ip next-hop verify-availability 10.125.3.1 1 track 200 [up] ip next-hop verify-availability 85.118.95.33 2 track 100 [up] Policy routing matches: 7163 packets, 1393938 bytes |
Отново ако направим тест от потребителя с ип адрес от address-lista-та 110 който е 192.168.10.99 ще забележим, че дестинацията винаги е една и съща.
policy routing from outgoing interface
Тъй като load balancing с ip cef сам избира маршрутите възможно е в някои ситуации един от WAN адресите да не е достъпен от Интернет защото ние сме попаднали на маршрут който е асоцииран към другия WAN. Това е много неприятно когато се изисква отдалечен достъп до самия рутер от глобалната мрежа със snmp, telnet, ssh или дори VPN. Разбира се има решение на този проблем като направим още един route-map само на адреса на избрания WAN.
! ip access-list extended MTEL-OUT permit ip host 85.118.95.35 any ! ip local policy route-map MTEL-OUT-MAP ! route-map MTEL-OUT-MAP permit 10 match ip address MTEL-OUT set ip next-hop 85.118.95.33 set interface FastEthernet1 ! |
Адреса на рутера 85.118.95.35 винаги ще е достъпен от Интернет без това да пречи на load balancing но нека все пак да проверим като изпълним един traceroute към host 87.121.124.6 от самият рутер
И от същия host 87.121.124.6 изпълним един traceroute към нашия WAN с адрес 85.118.95.35
От теста по горе е видно, че маршрутите са различни и route-map MTEL-OUT-MAP не влияе на маршрутната таблица на рутера като същевременно ние винаги имаме достъп до него.
Cisco NAT, Load Balancing, Policy Routing, Failover – част 3