Cấu hình DHCP

I : Cấu Hình DHCP Server

Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#service dhcp
Router1(config)#ip dhcp pool 192.168.6.128/25
Router1(dhcp-config)#network 192.168.6.128 255.255.255.128
Router1(dhcp-config)#default-router 192.168.6.200
Router1(dhcp-config)#dns-server 210.245.31.130
Router1(dhcp-config)#lease 2
Router1(dhcp-config)#exit
Router1(config)#ip dhcp excluded-address 192.168.6.129 192.168.6.140
Router1(config)#ip dhcp excluded-address 192.168.6.200 192.168.6.254
Router1(config)#end
Router1#

Ở đây :
– Service DHCP : khởi tạo dịch vụ DHCP Server .
– IP DHCP Pool : Xác định khoảng địa chỉ mà DHCP server sẽ cấp cho Client . cú pháp là địa chỉ Network liền với /Subnetmask bits . Có thể thay bằng tên Pool rồi xác định khoảng địa chỉ bằng lệnh Network ( ngay sau trong ví dụ )
– Các Options : Default-router tương đương Default-gateway , và DNS server
– Ip dhcp excluded-address : bỏ lại 1 số địa chỉ cho các mục đích sử dụng khác , như các Server – đăng ký riêng địa chỉ tĩnh , địa chỉ của DHCP Server …-à để tránh xung đột về địa chỉ sau này .
– Lease : Thời gian cliet giữ ip add , mặc định là 1 ngày . có thể thay đổi . trên ví dụ là để 2 ngày . Tối đa là 365 ngày 23 giờ 59 phút , tối thiểu là 1 phút . cú pháp : Lease [ngày] [giờ] [phút] _ giờ và phút là các options có hay ko cũng được.

*Các Options
– Các options thường được cấu hình là : default-router ( Default-gateway ) , DNS-server , Lease ….đã có trên ví dụ .
– Sau đây là 1 vài options thêm. ( Chỉ config options được khi ở trong mode DHCP-config – đã vào trong pool )
Router1(dhcp-config)#domain-name [ tên domain ]
Router1(dhcp-config)#netbios-name-server [ tên Wins Server ]
Router1(dhcp-config)#netbios-node-type [ loại node-type ]
Router1(dhcp-config)#client-name [ Tên client à chỉ sử dụng khi đăng ký riêng 1 địa chỉ tĩnh cho client )
Router1(dhcp-config)#host [ địa chỉ đăng ký riêng cho client và Subnetmask ]

Ngoài tên options , các options này còn được định số thứ tự để tiện cấu hình .
1 số options cơ bản và số thứ tự của options :

VD : như trên ví dụ trên cùng ta có thể thay :

Router1(dhcp-config)#default-router 192.168.6.200
Router1(dhcp-config)#dns-server 210.245.31.130
Router1(dhcp-config)#lease 2

Bằng .

Router1(dhcp-config)#option 3 ip 192.168.6.200
Router1(dhcp-config)#option 6 ip 210.245.31.130
Router1(dhcp-config)#option 58 2

1 số options khác :
Router1(dhcp-config)#option 66 ip 10.1.1.1
Router1(dhcp-config)#option 33 ip 192.0.2.1 172.25.1.3
Router1(dhcp-config)#option 31 hex 01
option 66 : TFTP server, option 33 : static routes, và option 31 buộc Client sử dụng ICMP Router Discovery Protocol (IRDP).

* 1 Số Điểm Cần Lưu Ý
– DHCP sử dụng port 67 và 68 , nếu hệt thống có xài tường lửa thì phải mở các port này .
– 1 Số options có thể gán nhiều hơn 1 giá trị . VD là default-router và dns-server . nhưng với option 3 ( default-router ) chỉ nên đặt 1 giá trị .
– Các options có tính thừa kế ( Inherited ) . bởi vậy khi cấu hình nhiều pool cấp địa chỉ cho nhiều subnet thì nên tạo 1 pool “ Cha “ bao gồm các pool “ con “ rồi cấu hình các options chung . sau đó tạo các pool con – có địa chỉ nằm trong pool cha . các options sẽ tự động được thừa kế .
– Nếu pool co có cấu hình cùng options nhưng khác value với pool cha . cấu hình của pool con được ưu tiên hơn .
– Có 1 option duy nhất không được thừa kế , đó là Lease . bởi vậy nếu pool con không cấu hình Lease . option này trả về giá trị DF là 1 (ngày)
– Không nên để giá trị Lease lâu : vì các cập nhật options mới từ DHCP server sẽ chậm được triển khai đến Client . cũng không nên đặt quá ngắn à tăng lưu lượng mạng . Giá trị DF=1 được nhiều người chấp nhận .

II : Cấu Hình DHCP Client

-Việc cấu hình DHCP Client đơn giản hơn nhiều . đơn giản là Set interface của router ở trạng thái DHCP Client là xong . Tuy nhiên, việc này không được khuyên dung cho Router . đơn giản là Router làm nhiều việc quan trọng , nên set địa chỉ tĩnh . vả lại , Client thì nhiều chứ Router thì có bao nhiêu
-Trong 1 số trường hợp , DHCP Server gởi luôn 1 DF route cho Client với AD cao à Client . Router sẽ sử dụng khi Destination không có trong routing table .Nhưng đã nói ở trên , không nên cho Router làm DHCP client nên options này không quan trọng lắm .
-1 Điểm nữa là hiện tại các router làm DHCP client không coi được mình đã nhận được các options gì từ DHCP Server . các IOS sau này có hay không thì chưa biết

Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#interface Ethernet0
Router1(config-if)#ip address dhcp client-id Ethernet0
Router1(config-if)#no shut
Router1(config-if)#end
Router1#
Interface Ethernet0 assigned DHCP address 192.168.6.141, mask 255.255.255.128
Router1#

Thông tin về interface sẽ có dạng như vầy :
Router1#show ip interface e0
Ethernet0 is up, line protocol is up
Internet address is 192.168.6.141/25
Broadcast address is 255.255.255.255
Address determined by DHCP
MTU is 1500 bytes
<removed for brevity>

III : Cấu Hình DHCP Relay Agent bằng lệnh IP Helper-address

Trong mô hình mạng nhiều Subnet , các client không cùng Network với DHCP Server . cần cấu hình DHCP relay Agent để forward DHCPdiscover đến DHCP Server .
Mô hình DHCP Server cùng net với client , mạng đơn giản thì không cần làm việc này .
Cú pháp cũng rất đơn giản : Trong ví dụ này mình cấu hình Router làm DHCP Server có địa chỉ F0/0 là 192.168.6.201

Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#interface Ethernet0
Router1(config-if)#ip helper-address 192.168.6.201
Router1(config-if)#end
Router1#

* 1 Số Diểm Cần Lưu ý
– Interface E0 là interface cùng Lan với DHCP Server .
– Khi 1 Client gởi DHCP Discover , nó dùng địa chỉ Source là 0.0.0.0 và đia chỉ Destination là 255.255.255.255 ( broadcast )
– Khi DHCP Relay Agent nhận được tín hiệu DHCP Discover , nó sẽ thay địa chỉ source của gói tin thành chính nó và địa chỉ đích là DHCP Server xác định trong lệnh ip helper-address . Địa chỉ MAC vẫn là của DHCP Client
– DHCP Server sẽ nhận ra được Subnet mà Client đang ở thông qua địa chỉ mà DHCP relay Agent gán vào . Nó sẽ chọn địa chỉ phù hợp và gởi lại cho DHCP relay agent ( tín hiệu unicast ) . DHCP RA sẽ gởi lại cho client ( qua Mac add trong gói tin )
– Có thể chỉ định nhiều DHCP Server ( mỗi lệnh ip helper-add chỉ định 1 DHCP server ) . khi đó tín hiệu DHCP Discover sẽ được forward đi nhiều hướng . Khi có nhiều hơn Response cho 1 DHCP discover, Client sẽ nhận địa chỉ IP trả về sớm hơn .
– Để coi thông tin về các IP helper-add đã xác định : coi trong output của : sh ip int [ int ]

-1 Lưu ý quan trọng là “ IP helper-add” không chỉ forward DHCP Discover đến DHCP server , các tín hiệu UDP khác cũng sẽ được forward theo ảnh hưởng đến hoạt động của DHCP Server . các tín hiệu UDP được forward bởi IP heler-add :

-Các client chạy Windows phát khá nhiều tín hiệu Netbios , những tín hiệu khác ít xảy ra hơn . Nếu không chặn hết thì nên chặn tín hiệu Netbios không thôi cũng được .

Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#no ip forward-protocol udp netbios-ns
Router1(config)#no ip forward-protocol udp netbios-dgm
Router1(config)#no ip forward-protocol udp tftp
Router1(config)#no ip forward-protocol udp nameserver
Router1(config)#no ip forward-protocol udp domain
Router1(config)#no ip forward-protocol udp time
Router1(config)#no ip forward-protocol udp tacacs
Router1(config)#end
Router1#
Có thể thay tên bằng số Port tương ứng phía trên .

 

IV : Cấu Hình Địa Chỉ Đăng Ký Riêng ( Static assign )

Việc này cũng thường phải làm để gán IP cho các Server cần ip static .
*1 Số lưu ý trước khi cấu hình .
– Đương nhiên là việc gán này dựa theo địa chỉ MAC . điểm khác biệt là router cisco xài Client-identifier có gán thêm giá trị 01 trước MAC add ( giá trị 01 được gán cho các interface chạy tốc độ 10/100/1000 )
– Địa chỉ MAC có thể viết liền tù tì , router tự cách ra khỏi lo .
– Phải tạo Pool riêng cho mỗi lần đăng ký địa chỉ tĩnh .
– Nên Exclue sẵn 1 số địa chỉ trong Root Pool cho việc này ( như ví dụ trên cùng )
-Các options sẽ được thừa hưởng từ pool cha, nếu canh thấy okie rồi thì khỏi config nữa …

– Trong VD mình lấy địa chỉ MAC card mạng của mình là 009099169EFC . tên là WebServer , ip 6.199 ,DF GW 6.200 , DNS 210.245.31.130 ,Lease 5 ( option này không được thừa kế )

Router1(config)#ip dhcp pool WEB
Router1(dhcp-config)#host 192.168.6.199 255.255.255.128
Router1(dhcp-config)#client-identifier 01009099169EFC
Router1(dhcp-config)#client-name WebServer
Router1(dhcp-config)#default-router 192.168.6.200
Router1(dhcp-config)#domain-name hohoho.com
Router1(dhcp-config)#dns-server 210.245.31.130
Router1(dhcp-config)#lease 5
Router1(dhcp-config)#end
Router1#

 

V : Lưu Trữ DHCP Database

– DHCP database được lưu trong RAM -> mất đi khi reload . nếu không có lưu trữ về database ở 1 điểm khác . Sauk hi Reload , DHCP Server bắt đầu như trạng thái mới hoạt động à sẽ cấp những địa chỉ mà client còn đang sử dụng ( vì nó có biết ai đang xài địa chỉ gì của nó đâu ) gây ra xung đột ( Conflic ip ) mạng
– Việc cấu hình như VD . ở đây mình lấy FTP Server , TFTP Server và RCP Server đều là 192.168.6.199 . đây là những DV được hỗ trợ , với TFTP ( Có lẽ thông dụng và dễ SD nhất ) thì nhớ bật sẵn TFTP Server lên chờ nó nhé

FTP :
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#ip dhcp database ftp://dhcp:bindsave@192.168.6.199/dhcp-r2a ( tên tùy thích )
Router1(config)#end
Router1#
(dhcp:bindsave : user + Pass )

TFTP :
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#ip dhcp database tftp://192.168.6.199/dhcp-r2a
Router1(config)#end
Router1#

RCP :
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#ip dhcp database rcp://dhcp@192.168.6.199/dhcp-r2a
Router1(config)#end
Router1#

– Khi đã up data lên data server , 1 khi reload , DHCP server sẽ tự lấy lại data và hoạt động tiếp tục 1 cách bình thường .
– Cấu hình dịa chỉ tĩnh đăng ký cho các server nằm trong NVRAM và không bị ảnh hưởng gì , reload thoải mái không sao

VI : Cấu Hình Nhiều DHCP Trên 1 Subnet

– Bình thường như cấu hình 1 DHCP Server trên 1 subnet vậy thôi . chẳng qua là làm trên 2 cái Router
– Lưu ý 1 chút là vì trên cùng Subnet , Pool giống nhau là đương nhiên . do đó , cần exclue đi 1 phần cho DHCP Server bên kia cấp . Tránh việc 2 DHCP cấp cùng 1 khoảng địa chỉ à Conflic IP ngay .
– Khi up data lên Data Server , đặt tên sao cho dễ nhận ra data nào là của DHCP nào , tiện việc sau này ……

VII : Theo Dõi Trạng Thái DHCP Server

Dùng các lệnh :

–SH ip DHCP Binding : thông tin về các địa chỉ đã cấp , các Mac add của địa chỉ được cấp , thời hạn còn lại ………
–SH ip DHCP Conflic : Tìm coi thằng nào đang xung đột với thằng nào
–SH ip DHCP Database : thông tin về các lần up data lên server
– SH ip DHCP Server Statistics : Chi tiết tỉ mỉ các thứ còn lại ….

-Không muốn DHCP Server ghi lại các sự kiện về xung đột địa chỉ : dùng lệnh
Router(config)#no ip dhcp conflict logging
– Xóa binding database :
Router#clear ip dhcp binding *
Có thể thay * bằng địa chỉ ip nếu muốn xóa 1 entry nào đó thôi .

VIII : Debugging DHCP

-Có 2 lệnh thôi
Router1#debug ip dhcp server events
(output thí dụ )
Router1#debug ip dhcp server events
Sep 15 00:58:17.218: DHCPD: returned 172.25.1.51 to address pool COOKBOOK
Sep 15 00:58:22.566: DHCPD: assigned IP address 172.25.1.51 to client 0100.0103.85e9.
87.
Sep 15 0115.056: DHCPD: writing bindings to ftp://dhcp:bindsave@172.25.1.1/dhcp-
leases-rtr1.
Sep 15 0115.132: DHCPD: writing address 172.25.1.51.
Sep 15 0115.148: DHCPD: wrote automatic bindings to ftp://dhcp:bindsave@172.25.1.
1/dhcp-leases-rtr1.
Sep 15 0158.816: DHCPD: checking for expired leases.
Sep 15 01:03:58.841: DHCPD: checking for expired leases.
Sep 15 0158.859: DHCPD: checking for expired leases.
Sep 15 0158.874: DHCPD: checking for expired leases.
Sep 15 01:09:58.885: DHCPD: checking for expired leases.
Sep 15 01:09:58.885: DHCPD: the lease for address 172.25.1.51 has expired.
Sep 15 01:09:58.885: DHCPD: returned 172.25.1.51 to address pool COOKBOOK.

Router1#debug ip dhcp server packet
(output thí dụ )
Router1#debug ip dhcp server packet
Sep 15 01:19:41.211: DHCPD: DHCPDISCOVER received from client 0100.0103.85e9.87 on
interface FastEthernet0/0.1.
Sep 15 01:19:43.212: DHCPD: Sending DHCPOFFER to client 0100.0103.85e9.87 (172.25.1.
51).
Sep 15 01:19:43.212: DHCPD: creating ARP entry (172.25.1.51, 0001.0385.e987).
Sep 15 01:19:43.212: DHCPD: unicasting BOOTREPLY to client 0001.0385.e987 (172.25.1.
51).
Sep 15 01:19:43.216: DHCPD: DHCPREQUEST received from client 0100.0103.85e9.87.
Sep 15 01:19:43.216: DHCPD: Sending DHCPACK to client 0100.0103.85e9.87 (172.25.1.
51).
Sep 15 01:19:43.216: DHCPD: creating ARP entry (172.25.1.51, 0001.0385.e987).
Sep 15 01:19:43.216: DHCPD: unicasting BOOTREPLY to client 0001.0385.e987 (172.25.1.
51).
Router1#

ST: nhatnghe.com

Use a TFTP Server to Backup and Restore CISCO iOS

1. Khởi động phần mềm TFTP server

2. Kiểm tra vị trí lưu IOS image, ghi nhận chính xác tên của IOS image hiện hành. Bên cạnh đó, kiểm tra xem dung lượng của Flash memory có đủ sức chứa IOS image mới hay không.

Switch#dir flash:
Directory of flash:/
2 -rwx 0 Mar 01 1993 00:59:13 env_vars
3 -rwx 3993344 Mar 01 1993 00:29:59 c3550-i5q3l2-mz.121-13.EA1a.bin
4 -rwx 43 Mar 01 1993 00:59:13 system_env_vars
6 -rwx 1625 Mar 01 1993 00:13:57 starup-config
15998976 bytes total (12001792 bytes free)
Ghi nhận đường dẫn: flash:c3550-i5q3l2-mz.121-13.EA1a.bin

3. Sao luu IOS image hiện hành lên TFTP server để dự phòng
Switch#copy flash:c3550-i5q3l2-mz.121-13.EA1a.bin tftp
Address or name of remote host []? 10.0.0.2
Destination filename [c3550-i5q3l2-mz.121-13.EA1a.bin]? y
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
3993344 bytes copied in 19.972 secs (199947 bytes/sec)

Trong quá trình sao chép, khai báo địa chỉ TFTP server, giữ nguyên tên của IOS image khi sao lưu lên TFTP server.

4. Chép IOS image từ TFTP server vào Flash memory. Cần chú ý là filename của các tâp tin loại này luôn phải kết thúc “.bin”.
Switch#copy tftp:c3550-i5q3l2-mz.121-13.EA1a.bin nvram
Address or name of remote host [10.0.0.2]?
Source filename [c3550-i5q3l2-mz.121-13.EA1a.bin]?
Destination filename [nvram]? c3550-i5q3l2-mz.121-13.EA1a.bin
%Warning:There is a file already existing with this name
Do you want to over write? [confirm]y
Accessing tftp://10.0.0.2/c3550-i5q3l2-mz.121-13.EA1a.bin…
Loading c3550-i5q3l2-mz.121-13.EA1a.bin from 10.0.0.2 (via Vlan1):
!O!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[OK – 3993344 bytes]
3993344 bytes copied in 105.760 secs (37759 bytes/sec)

Configuring Policy-Based Routing (PBR) with IP SLA Tracking – Auto Redirecting Traffic

What is Policy-Based Routing?

Policy-Based Routing (PBR) is a very popular feature in Cisco routers, it allows the creation of policies that can selectively alter the path  that packets take within the network. Policy-Based Routing can be used to mark packets so that certain types of traffic are prioritized over the rest, sent to a different destination or exist via a different physical interface on the router.

Classification of interesting traffic is performed using Access-Control Lists (ACLs). These can be standard, extended or named access lists as we know them.

Once the interesting traffic is ‘matched’ with the use of ACLs, the router will perform the configured ‘set’ function which is defined by the Administrator. This ‘set’ function essentially tells the router what to do with the matched traffic and can include sending it to another gateway, dropping it, prioritizing it over other traffic, and much more.

Policy-Based Routing with IP SLA Monitoring for Automatic Fail-over

This article will show how to use Policy-Based Routing to mark a specific type of traffic, for example http, and redirect it to a web proxy (usually Linux Squid) so all network web traffic is automatically filtered through the proxy.

In such setups, network users have no knowledge of the proxy’s existence as they are not required to configure their web browser to use the proxy. All user traffic is forwarded to a single gateway (Cisco ASA Firewall) and from there to router R1. This example is good solution for creating a transparent proxy with automatic failover.

Router R1, with the help of Policy-Based Routing, ‘marks’ all http traffic and then performs the appropriate ‘set’ function, which is to redirect the selected traffic to the Linux proxy with IP address 192.168.150.2.

The Linux proxy accepts the traffic, makes the necessary checks defined by the Administrator and forwards it to the Internet via R2 router.

To complement our solution we’ve added IP SLA tracking so that R1 will continuously monitor the Linux proxy to ensure it has not failed or gone offline.  If for any reason router R1 loses connectivity with the Linux proxy, the IP SLA & Policy-Based Routing mechanism will stop redirecting http traffic to it and forward it directly to the Internet via R2, effectively bypassing the failed proxy.

The next diagram shows how router R1 will respond to a failure of the Linux proxy as described above:

This solution smartly combines Cisco’s Policy-Based Routing with IP SLA tracking and provides a number of benefits, some of which are:

• Automatic redirection of selected (http) traffic to the Linux Proxy.
• Transparent web proxy to all network users, with web filtering according to company policy.
• Automatic failover in case proxy fails.  Near-zero downtime.
• Continuous monitoring of proxy after failure – automatic recovery if proxy is back online.

Note: More examples of IP SLA Tracking can be found in our Configuring Static Route Tracking using IP SLA (Basic) article.

How to Configure IP SLA Tracking for a Host

First step is to configure IP SLA tracking for the desired host. This will ensure R1 router will continuously monitor the Linux proxy and stop redirecting http traffic to it in the event it fails:

R1(config)# ip sla 1
R1(config-ip-sla)# icmp-echo 192.168.150.2
R1(config-ip-sla)# frequency 4
R1(config-ip-sla)# timeout 2000
R1(config-ip-sla)# threshold 100
R1(config-ip-sla)# ip sla schedule 1 life forever start-time now

The above configuration defines and starts an IP SLA probe on router R1.

The ICMP Echo probe sends an ICMP Echo (ping) packet to IP 192.168.150.2 every 4 seconds, as defined by the frequency parameter.

Timeout sets the amount of time (in milliseconds) the Cisco IOS IP SLAs operation waits for a response from its request packet. This has been set to 2000 milliseconds, or 2 seconds which gives the host ample time to respond.

Threshold sets the rising threshold that generates a reaction event and stores history information for the Cisco IOS IP SLAs operation.

After defining the IP SLA operation, our next step is to define an object that tracks the SLA probe. This can be accomplished by using the IOS Track Object as shown below:

R1(config)# track 1 ip sla 1 reachability

The above command will track the state of the IP SLA operation. If there are no ping responses from the monitored IP address (192.168.150.2), the track will go down and it will come back up when the IP SLA operation starts receiving ping responses once again.

To verify the track status, use the “show track” command as shown below:

R1# show track 1
Track 1
IP SLA 1 reachability
Reachability is Up
30 changes, last change 1d08h
Latest operation return code: OK
Latest RTT (millisecs) 1
Tracked by:
ROUTE-MAP 0

The command output verifies that the tracked object is UP and has a response time of 1ms.  A closer look shows that ,for the duration of the tracking, the state has changed 30 times and the last change was 1 day and 8 hours ago.  This information is extremely important should it be necessary to troubleshoot intermittent problems that might be reported by the users.

 How to Configure Policy-Based Routing to Redirect Selected (http) Traffic

Once we have IP SLA up and running the next step is to configure PBR so we can redirect http traffic.

First, we need to use Access-Control Lists to select the traffic we want to redirect. Keep in mind that PBR does not limit the type of ACL that can be used. This means you can use IP named ACLs, standard ACLs, extended ACLs, time-based ACLs and others. In our example we are going to use IP named ACLs:

R1(config)# ip access-list extended http-traffic
R1(config)# permit tcp 192.168.5.0 0.0.0.255 any eq www

We’ve decided to name our IP-named ACL ‘http-traffic‘. This unique ACL name will be used later in our route-map. By making the appropriate changes in the ACLs we can define different types of traffic that will be redirected. In our example all http traffic from the 192.168.5.0 network that is destined to the Internet (any) is selected.

Now we must create a route-map that will use the above defined ACLs and instruct the router to redirect the traffic to the Linux proxy:

R1(config)# route-map linux-proxy permit 1
R1(config-route-map)# match ip address http-traffic
R1(config-route-map)# set ip next-hop verify-availability 192.168.150.2 1 track 1

The above command creates a permissive route-map named linux-proxy. The match IP address parameter within the route-map informs the router which set of ACLs defines the traffic we are interested in.  Since we’ve defined our interesting traffic using IP named ACLs, all we need to do is reference the name of our ACL previously created.

The last command configures the route map to verify the reachability of the tracked object (192.168.150.2). If the tracked object is reachable (IP SLA reports it is reachable), then our policy-based route will redirect the defined traffic to it. If the tracked object is not reachable, (IP SLA reports the host is not reachable – down) then our policy-based route will stop redirecting traffic.

 Applying the Policy-Based Route

We are almost done. The very last step is to enable and identify the route-map to be use for policy routing. This is performed by selecting the router interface for which the policy routing will be enabled, and applying the policy-route:

R1(config)# interface Vlan1
R1(config-int)# ip policy route-map linux-proxy

In our scenario, R1’s  VLAN1 interface is connected to the 192.168.150.0/24 network where our ASA and Linux proxy reside so we apply the policy routing to that.

 

 Route-Map & IP SLA Statistics

Keeping a close eye on the router’s route-map & IP SLA  performance can be achieved with the use of a few simple commands.  Monitoring your route-map’s performance the first couple of days is a very good idea as it will help verify that traffic is still being redirected to the host.

On the other hand, looking at IP SLA statistics will help identify possible failures or changes of state which were not noticed by anyone.

The show route-map command is a favourite as it combines enough information to help verify everything is working as it should:

R1# show route-map

route-map linux-proxy, permit, sequence 1

  Match clauses:

    ip address (access-lists): http-traffic

  Set clauses:

    ip next-hop verify-availability 192.168.150.10 1 track 1  [up]

  Policy routing matches: 3864291 packets, 511957007 bytes

The numbers shown here verify immediately that our host is reachable (up) and that R1 has redirected more than 510MB of traffic through the Linux proxy!

The show IP SLA statistics command provides in a similar way useful information that helps verify the object tracking is working correctly and the tracked host is up:

R1# show ip sla statistics
IPSLAs Latest Operation Statistics

IPSLA operation id: 1
Latest RTT: 1 milliseconds
Latest operation start time: *21:36:47.855 UTC Tue Apr 3 2012
Latest operation return code: OK
Number of successes: 16
Number of failures: 0
Operation time to live: Forever

Configuring Static Route Tracking using IP SLA (Basic)

In today’s network environment, redundancy is one of the most important aspects, whether its on the LAN side or on the WAN side. In this topic I will be covering WAN redundancy with multiple WAN links terminating on a single router.

The best and simplest way to achieve WAN redundancy on Cisco devices is to use Reliable Static backup routes with IP SLA tracking.

IP SLAs is a feature included in the Cisco IOS Software that can allow administrators the ability to Analyze IP Service Levels for IP applications and services. IP SLA’s uses active traffic-monitoring technology to monitor continuous traffic on the network. This is a reliable method in measuring over head network performance. Cisco Routers provide IP SLA Responders that give accuracy of measured data across a network.

With IP SLAs, routers and switches perform periodic measurements. The number and type of available measurements are vast and in this article I will be covering just the ICMP ECHO feature. IP SLA in itself is a very big topic to cover J

Let us take an example of a basic redundant WAN link scenario as shown below:

In the above figure the Cisco device is connected to two WAN links ISP1 and ISP2. The most common setup that we use in day to day life is to have to default routes configured on the Cisco router pointing to the respective next hop IPs as shown below:

R1(config)# ip route 0.0.0.0 0.0.0.0 2.2.2.2
R1(config)# ip route 0.0.0.0 0.0.0.0 3.3.3.3 10

If you notice the Administrative Distance for the secondary route pointing to ISP2 is increased to 10 so that it becomes the backup link.

The above configuration with just two floating static routes partially accomplishes our requirement as it will work only in the scenario where the routers interfaces connected to the WAN link are in up/down or down/down status. But in a lot of situations we see that even though the links remain up but we are not able to reach the gateway, this usually happens when the issue is at the ISP side.

In such scenarios, IP SLAs becomes an engineer’s best friend. With around six additional IOS commands we can have a more reliable automatic failover environment.

Using IP SLA the Cisco IOS gets the ability to use Internet Control Message Protocol (ICMP) pings to identify when a WAN link goes down at the remote end and hence allows the initiation of a backup connection from an alternative port. The Reliable Static Routing Backup using Object Tracking feature can ensure reliable backup in the case of several catastrophic events, such as Internet circuit failure or peer device failure.

IP SLA is configured to ping a target, such as a publicly routable IP address or a target inside the corporate network or your next-hop IP on the ISP’s router. The pings are routed from the primary interface only. Following a sample configuration of IP SLA to generate icmp ping targeted at the ISP1s next-hop IP.

R1(config)# ip sla 1
R1(config)# icmp-echo 2.2.2.2 source-interface FastEthernet0/0
R1(config)# timeout 1000
R1(config)# threshold 2
R1(config)# frequency 3
R1(config)# ip sla schedule 1 life forever start-time now

Please note that the Cisco IP SLA commands have changed from IOS to IOS to know the exact command for IOS check the Cisco documentation. The above commands are for IOS 12.4(4)T, 15.(0)1M, and later releases.

The above configuration defines and starts an IP SLA probe.

The ICMP Echo probe sends an ICMP Echo packet to next-hop IP 2.2.2.2 every 3 seconds, as defined by the “frequency” parameter.

Timeout sets the amount of time (in milliseconds) for which the Cisco IOS IP SLAs operation waits for a response from its request packet.

Threshold sets the rising threshold that generates a reaction event and stores history information for the Cisco IOS IP SLAs operation.

After defining the IP SLA operation our next step is to define an object that tracks the SLA probe. This can be accomplished by using the IOS Track Object as shown below:

R1(config)# track 1 ip sla 1 reachability

The above command will track the state of the IP SLA operation. If there are no ping responses from the next-hop IP the track will go down and it will come up when the ip sla operation starts receiving ping response.

To verify the track status use the use the “show track” command as shown below:

R1# show track

Track 1
IP SLA 1 reachability
Reachability is Down
1 change, last change 00:03:19
Latest operation return code: Unknown

The above output shows that the track status is down. Every IP SLAs operation maintains an operation return-code value. This return code is interpreted by the tracking process. The return code may return OK, OverThreshold, and several other return codes.

Different operations may have different return-code values, so only values common to all operation types are used. The below table shows the track states as per the IP SLA return code.

Tracking	Return Code	Track State
Reachability	OK or over threshold (all other return codes)	Up Down

The Last step in the IP SLA Reliable Static Route configuration is to add the “track” statement to the default routes pointing to the ISP routers as shown below:

R1(config)# ip route 0.0.0.0 0.0.0.0 2.2.2.2 track 1
R1(config)# ip route 0.0.0.0 0.0.0.0 3.3.3.3 10

The track number keyword and argument combination specifies that the static route will be installed only if the state of the configured track object is up. Hence if the track status is down the secondary route will be used to forward all the traffic.