Tweet
Trong bài lab 4 này, chúng ta sẽ tiếp tục cấu hình các thành phần cơ bản trong LISP. Chúng ta sẽ thêm một cổng RLOC thứ 2 trên router đóng gói xTR ở SITE 1. Bài lab này mô phỏng một tình huống thực tế, doanh nghiệp yêu cầu tăng băng thông đường truyền và mong muốn kết nối qua nhiều nhà cung cấp dịch vụ bằng việc sử dụng multi-homing.
Ta tiếp tục dùng lại sơ đồ và cấu hình của bài 2:
Mục tiêu
Qua việc thực hiện bài lab này, chúng ta sẽ học được cách cấu hình multihoming cơ bản của LISP và thiết lập một chính sách cho lượng traffic đi vào Site. Hai đường kết nối sẽ ở trạng thái active/active và chia tải 50%/50%.
Hướng dẫn làm lab
Bước 1: Cấu hình đường kết nối thứ 2 RLOC của LISP ở Site 1 (đường kết nối R112 với R113).
Hãy đảm bảo rằng cả 2 cổng WAN E1/1 và E1/2 đều ở trạng thái “up” và cấu hình default route trên đường còn lại (các bài lab trước chưa cấu hình trên đường E1/1).
Cấu hình locator-set có thêm đường E1/1. Việc cấu hình đường kết nối còn lại giữa 2 router này để phục vụ cho multihomed về sau. Trong trường hợp này, cần cho các lưu lượng truy cập vào/ra Site 1 thực hiện Load Sharing (chia tải).
Bây giờ, các prefix EID kết nối với site này được liên kết với 2 RLOC (10.0.1.2 và 10.0.2.2), với mỗi đường được đặt giá trị priority và weight cùng bằng 1.
Ghi nhớ: LISP sử dụng giá trị priority và weight (trọng số) để tạo một chính sách mô tả cách 1 site muốn nhận lưu lượng với đích đến là dãy EID của nó.
Khi một Site trong LISP có nhiều router định vị, mỗi router định vị sẽ chỉ định cùng hoặc khác giá trị priority (từ 0 đến 255). Khi nhiều bộ định vị cùng chỉ định các giá trị priority khác nhau, giá trị priority thấp hơn sẽ biểu thị đường đi thích hợp hơn. Giá trị 255 chỉ ra rằng bộ định vị đó không được sử dụng để chuyển tiếp lưu lượng truy cập unicast.
Khi các bộ định vị có cùng một giá trị priority, chúng sẽ chạy chia sẽ tải. Đối với mức độ ưu tiên nhất định, trọng số được gán cho mỗi bộ định vị được sử dụng để xác định cách tải các luồng unicast giữa các bộ định vị. Giá trị trọng số từ 0 đến 100 được sử dụng để biểu thị phần trăm lưu lượng được chia tải cho trình định vị đó.
Trong bài lab, router sẽ tính toán tỉ lượng dựa trên các giá trị trọng số. Điều này cần thiết cho các tình huống lỗi xảy ra khi RLOC có thể không “sẵn sàng” và LISP phải cân bằng lại việc chia tải. Ví dụ, Nếu Router đóng/mở gói có ba bộ định vị (locators) và rồi 1 đường bị down, router đó phải tính toán lại việc chia tải của mình. Dưới đây là bản tính trong bài lab này.)
Bước 2:
Xác minh rằng LISP Site 1 hiện đang sử dụng thông tin mới này trong cơ sở dữ liệu của nó. Dùng lệnh “show ip lisp database” để kiểm tra database LISP R112. Thông tin output phải khớp với những lệnh cấu hình ánh xạ trước đó:
Quan sát map-cache trên router R116 (LISP xTR) sử dụng lệnh “show ip lisp map-cache”. Thông tin ánh xạ mới với R112 được ghi nhận:
(Nếu không có thông tin trên, hãy thực hiện lệnh ping source từ R111 đến R117 sử dụng các IP loopback của 2 router để LISP cập nhật map-cache)
Chú ý thông tin map-cache trên LISP xTR R116 đã được cập nhật và sử dụng chính sách mới từ R112. Nếu điều này xảy ra thì:
Đầu tiên, hãy nhớ rằng các site chỉ duy trì những giá trị đầu vào map-cache cho những EID chúng từng “giao tiếp”. Mặc định thì các giá trị đầu vào map-cache có time to live (TTL) là 24 giờ. Ngoài ra mỗi đầu vào map-cache sẽ có 1 “state”( tạm gọi là trạng thái) “active” hoặc “idle” – chỉ ra cách các lưu lượng thực sự đi đến các EID từ xa. Điều này sẽ thể hiện chi tiết ở lệnh show ip lisp map-cache.
Cũng lưu ý ở trên rằng việc dò tìm của RLOC đang truy vấn đến trạng thái các router định vị (locators) trên R112. Router R112 cũng được kích hoạt tính năng thăm dò ( rloc-probing). Sau khi được kích hoạt, router xTR (ở đây là R112) tự động thông báo cho những xTR khác mà nó đang “kết nối”, được xác định bởi danh sách các bộ định vị có độ ưu tiên cao trong map-cache của nó. Trong trường hợp này, khi chúng ta thêm 1 router định vị (RLOC) thứ 2 trên R112 locator-set, R112 sẽ yêu cầu R116 “update” map-cache của nó cho R112. R112 làm việc này bằng cách gửi đi 1 “SMR” (solicit map-request) đến R116. SMR sẽ yêu cầu bên nhận bắt đầu tiến trình “map-request” để yêu cầu nó cập nhật map-cache đã được thay đổi của Site.
Nếu điều đó không xảy ra: Các đoạn thảo luận trên dựa trên giả định rằng các đầu vào map-cache đến một site từ xa (ở đây là với R116) vẫn còn trên R112.
Nếu đầu vào map-cache không còn tồn tại trên R112, R112 sẽ không thông báo đến R116 sự thay đổi các chính sách ngay lập tức. Trong trường hợp này:
a/ Nếu R116 không có bất kỳ ánh xạ nào, nó sẽ có 1 ánh xạ mới qua tiến trình map-request/map-reply
b/ Nếu R116 còn lưu trữ các ánh xạ cũ, nó sẽ được update từ R112 đến R116 , R112 bắt đầu chuyển lưu lượng đi và R112 sẽ truyền 1 đầu vào map-cache đến R116.
Trên R116 , tiến hành ping EID của R112. Ta có thể thấy ping thành công:
Trên R116, sử dụng lệnh “show ip lisp forwarding eid remote” để kiểm tra việc đóng gói của LISP sẽ sử dụng cả 2 RLOCS trên R112:
Lưu ý rằng “các bit mô tả trạng thái định vị”( Locator-Status-Bits – LSB) là 0x00000003, chỉ ra rằng các site từ xa (R112) có 2 bộ định vị (locators) và cả 2 đều ở trạng thái up, sẵn sàng như là 1 đích đến cho các gói tin đóng gói LISP đến 192.168.1.0/24.
Bởi vì việc chia tải trong LISP được thực hiện bằng cách phân luồng sử dụng hàm băm “five-tuple” của các gói tin nguồn, để thực hiện và quan sát việc load sharing trên R112, chúng ta cần bắt đầu gửi luồng traffic từ các nguồn khác nhau và đích khác nhau. Chúng ta có thể xác minh cách R116 gửi lưu lượng bằng việc quan sát kết quả câu lệnh “show adjacency lisp0 detail” hoặc kiểm tra cách R112 nhận lưu lượng trên các cổng RLOCs qua lệnh “show interface e1/1 | in pack”.
Cùng thử lại việc gửi 500 gói ICMP từ 192.168.7.3 đến 192.168.1.2 (lưu ý việc clear counters đề kiểm tra chính xác hơn):
Chú ý rằng R116 đóng gói các gói tin đến cả 2 RLOCs trên LISP R112, thỏa mãn việc chính sách chia tải 50/50 các lưu lượng đi vào (ingress traffic) trên R112.
Ta tiếp tục dùng lại sơ đồ và cấu hình của bài 2:
Mục tiêu
Qua việc thực hiện bài lab này, chúng ta sẽ học được cách cấu hình multihoming cơ bản của LISP và thiết lập một chính sách cho lượng traffic đi vào Site. Hai đường kết nối sẽ ở trạng thái active/active và chia tải 50%/50%.
Hướng dẫn làm lab
Bước 1: Cấu hình đường kết nối thứ 2 RLOC của LISP ở Site 1 (đường kết nối R112 với R113).
Hãy đảm bảo rằng cả 2 cổng WAN E1/1 và E1/2 đều ở trạng thái “up” và cấu hình default route trên đường còn lại (các bài lab trước chưa cấu hình trên đường E1/1).
Code:
R112-xTR#[B]show ip interface brief | exclude un|down[/B] Interface IP-Address OK? Method Status Protocol Ethernet0/0 172.16.1.2 YES TFTP [B]up up[/B] Ethernet1/1 10.0.1.2 YES TFTP [B]up up[/B] Ethernet1/2 10.0.2.2 YES TFTP [B] up up[/B] Loopback0 192.168.1.254 YES TFTP [B]up up[/B] R112-xTR#conf t Enter configuration commands, one per line. End with CNTL/Z. R112-xTR(config)#[B]ip route 0.0.0.0 0.0.0.0 10.0.2.1[/B]
Code:
R112-xTR(config)#router lisp R112-xTR(config-router-lisp)#locator-set SITE1 R112-xTR(config-router-lisp-locator-set)#10.0.2.2 priority 1 weight 1 R112-xTR(config-router-lisp-locator-set)#end
Ghi nhớ: LISP sử dụng giá trị priority và weight (trọng số) để tạo một chính sách mô tả cách 1 site muốn nhận lưu lượng với đích đến là dãy EID của nó.
Khi một Site trong LISP có nhiều router định vị, mỗi router định vị sẽ chỉ định cùng hoặc khác giá trị priority (từ 0 đến 255). Khi nhiều bộ định vị cùng chỉ định các giá trị priority khác nhau, giá trị priority thấp hơn sẽ biểu thị đường đi thích hợp hơn. Giá trị 255 chỉ ra rằng bộ định vị đó không được sử dụng để chuyển tiếp lưu lượng truy cập unicast.
Khi các bộ định vị có cùng một giá trị priority, chúng sẽ chạy chia sẽ tải. Đối với mức độ ưu tiên nhất định, trọng số được gán cho mỗi bộ định vị được sử dụng để xác định cách tải các luồng unicast giữa các bộ định vị. Giá trị trọng số từ 0 đến 100 được sử dụng để biểu thị phần trăm lưu lượng được chia tải cho trình định vị đó.
Trong bài lab, router sẽ tính toán tỉ lượng dựa trên các giá trị trọng số. Điều này cần thiết cho các tình huống lỗi xảy ra khi RLOC có thể không “sẵn sàng” và LISP phải cân bằng lại việc chia tải. Ví dụ, Nếu Router đóng/mở gói có ba bộ định vị (locators) và rồi 1 đường bị down, router đó phải tính toán lại việc chia tải của mình. Dưới đây là bản tính trong bài lab này.)
Bước 2:
Xác minh rằng LISP Site 1 hiện đang sử dụng thông tin mới này trong cơ sở dữ liệu của nó. Dùng lệnh “show ip lisp database” để kiểm tra database LISP R112. Thông tin output phải khớp với những lệnh cấu hình ánh xạ trước đó:
Code:
R112-xTR#[B]show ip lisp database[/B] LISP ETR IPv4 Mapping Database for EID-table default (IID 0), LSBs: 0x3, 1 entries [B]192.168.1.0/24, locator-set SITE1 Locator Pri/Wgt Source State 10.0.1.2 1/1 cfg-addr site-self, reachable 10.0.2.2 1/1 cfg-addr site-self, reachable[/B]
Code:
R116-xTR#[B]show ip lisp map-cache[/B] LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries 0.0.0.0/0, uptime: 00:14:34, expires: never, via static send map-request Negative cache entry, action: send-map-request [B]192.168.1.0/24, uptime: 00:00:14, expires: 23:59:45, via map-reply, complete Locator Uptime State Pri/Wgt 10.0.1.2 00:00:14 up 1/1 10.0.2.2 00:00:14 up 1/1[/B]
Chú ý thông tin map-cache trên LISP xTR R116 đã được cập nhật và sử dụng chính sách mới từ R112. Nếu điều này xảy ra thì:
Đầu tiên, hãy nhớ rằng các site chỉ duy trì những giá trị đầu vào map-cache cho những EID chúng từng “giao tiếp”. Mặc định thì các giá trị đầu vào map-cache có time to live (TTL) là 24 giờ. Ngoài ra mỗi đầu vào map-cache sẽ có 1 “state”( tạm gọi là trạng thái) “active” hoặc “idle” – chỉ ra cách các lưu lượng thực sự đi đến các EID từ xa. Điều này sẽ thể hiện chi tiết ở lệnh show ip lisp map-cache.
Code:
R116-xTR#[B]show ip lisp map-cache 192.168.1.0/24[/B]
LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries
192.168.1.0/24, uptime: 00:03:01, expires: 23:56:58, via map-reply, complete
Sources: map-reply
State: complete, last modified: 00:03:01, map-source: 10.0.2.2
Active, Packets out: 3 (~ 00:02:20 ago)
[B]Locator Uptime State Pri/Wgt
10.0.1.2 00:03:01 up 1/1[/B]
Last up-down state change: 00:03:01, state change count: 1
Last route reachability change: 00:03:01, state change count: 1
Last priority / weight change: never/never
RLOC-probing loc-status algorithm:
Last RLOC-probe sent: never
[B] 10.0.2.2 00:03:01 up 1/1[/B]
Last up-down state change: 00:03:01, state change count: 1
Last route reachability change: 00:03:01, state change count: 1
Last priority / weight change: never/never
RLOC-probing loc-status algorithm:
Last RLOC-probe sent: never
R116-xTR#
Nếu điều đó không xảy ra: Các đoạn thảo luận trên dựa trên giả định rằng các đầu vào map-cache đến một site từ xa (ở đây là với R116) vẫn còn trên R112.
Nếu đầu vào map-cache không còn tồn tại trên R112, R112 sẽ không thông báo đến R116 sự thay đổi các chính sách ngay lập tức. Trong trường hợp này:
a/ Nếu R116 không có bất kỳ ánh xạ nào, nó sẽ có 1 ánh xạ mới qua tiến trình map-request/map-reply
b/ Nếu R116 còn lưu trữ các ánh xạ cũ, nó sẽ được update từ R112 đến R116 , R112 bắt đầu chuyển lưu lượng đi và R112 sẽ truyền 1 đầu vào map-cache đến R116.
Trên R116 , tiến hành ping EID của R112. Ta có thể thấy ping thành công:
Code:
R116-xTR#[B]ping 192.168.1.254 so 192.168.7.254[/B] Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.254, timeout is 2 seconds: Packet sent with a source address of 192.168.7.254 !!!!! [B]Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms[/B]
Code:
R116-xTR#[B]show ip lisp forwarding eid remote 192.168.1.1[/B]
Prefix Fwd action Locator status bits
[B]192.168.1.0/24 encap 0x00000003[/B]
packets/bytes 8/730
path list C63B1D0C, 3 locks, per-destination, flags 0x49 [shble, rif, hwcn]
ifnums:
LISP0(11): 10.0.1.2, 10.0.2.2
2 paths
path C4A5EF20, share 1/1, type attached nexthop, for IPv4
nexthop 10.0.1.2 LISP0, IP midchain out of LISP0, addr 10.0.1.2 C3FC3B38
path C4A5EEB0, share 1/1, type attached nexthop, for IPv4
nexthop 10.0.2.2 LISP0, IP midchain out of LISP0, addr 10.0.2.2 C3FC3A08
1 output chain
chain[0]: loadinfo C2CF812C, per-session, 2 choices, flags 0083, 5 locks
flags [Per-session, for-rx-IPv4, 2buckets]
2 hash buckets
[B] < 0 > IP midchain out of LISP0, addr 10.0.1.2 C3FC3B38
IP adj out of Ethernet0/1, addr 10.0.9.1 C61096B8
< 1 > IP midchain out of LISP0, addr 10.0.2.2 C3FC3A08
IP adj out of Ethernet0/1, addr 10.0.9.1 C61096B8[/B]
Subblocks:
None
Bởi vì việc chia tải trong LISP được thực hiện bằng cách phân luồng sử dụng hàm băm “five-tuple” của các gói tin nguồn, để thực hiện và quan sát việc load sharing trên R112, chúng ta cần bắt đầu gửi luồng traffic từ các nguồn khác nhau và đích khác nhau. Chúng ta có thể xác minh cách R116 gửi lưu lượng bằng việc quan sát kết quả câu lệnh “show adjacency lisp0 detail” hoặc kiểm tra cách R112 nhận lưu lượng trên các cổng RLOCs qua lệnh “show interface e1/1 | in pack”.
Code:
R112-xTR#[B]clear counters[/B]
Clear "show interface" counters on all interfaces [confirm]
R112-xTR#
*[B]Oct 26 21:33:02.744: %CLEAR-5-COUNTERS: Clear counter on all interfaces by console[/B]
R112-xTR#
R116-xTR#[B]clear counters[/B]
Clear "show interface" counters on all interfaces [confirm]
R116-xTR#
[B]*Oct 26 21:33:17.105: %CLEAR-5-COUNTERS: Clear counter on all interfaces by console[/B]
R116-xTR#
R117-Host2#ping 192.168.1.1 so 192.168.7.1 rep 500
Type escape sequence to abort.
Sending 500, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.7.1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!
[B]Success rate is 100 percent (500/500), round-trip min/avg/max = 1/1/5 ms[/B]
R117-Host2#
R116-xTR#show adjacency lisp0 detail
Protocol Interface Address
IP LISP0 [B]10.0.1.2(5)
500 packets[/B], 68000 bytes
epoch 0
sourced in sev-epoch 0
Encap length 36
450000000000400000115CEA0A000902
0A000102000010F500000000C068A6CF
00000001
LISP
Next chain element:
IP adj out of Ethernet0/1, addr 10.0.9.1
IP LISP0 [B]10.0.2.2(5)
0 packets[/B], 0 bytes
epoch 0
sourced in sev-epoch 0
Encap length 36
450000000000400000115BEA0A000902
0A000202000010F500000000C068A6CF
00000001
LISP
Next chain element:
Protocol Interface Address
IP adj out of Ethernet0/1, addr 10.0.9.1
R116-xTR#
R112-xTR#show interface ethernet 1/1 | in pack
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
[B]501 packets input, 75376 bytes, 0 no buffer[/B]
0 input packets with dribble condition detected
5 packets output, 300 bytes, 0 underruns
R112-xTR#show interface ethernet 1/2 | in pack
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
3 packets input, 600 bytes, 0 no buffer
0 input packets with dribble condition detected
[B] 509 packets output, 75947 bytes, 0 underruns[/B]
R112-xTR#
Code:
R112-xTR#[B]clear counters[/B]
Clear "show interface" counters on all interfaces [confirm]
R112-xTR#
R116-xTR#[B]clear counters[/B]
Clear "show interface" counters on all interfaces [confirm]
R116-xTR#
R117-Host7#[B]ping 192.168.1.2 so 192.168.7.3 rep 500[/B]
Type escape sequence to abort.
Sending 500, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
Packet sent with a source address of 192.168.7.3
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!
[B]Success rate is 100 percent (500/500), round-trip min/avg/max = 1/1/2 ms[/B]
R117-Host7#
R116-xTR#show adjacency lisp0 detail
Protocol Interface Address
IP LISP0 [B] 10.0.1.2(5)
0 packets[/B], 0 bytes
epoch 0
sourced in sev-epoch 0
Encap length 36
450000000000400000115CEA0A000902
0A000102000010F500000000C068A6CF
00000001
LISP
Next chain element:
IP adj out of Ethernet0/1, addr 10.0.9.1
IP LISP0 [B]10.0.2.2(5)
500 packets[/B], 68000 bytes
epoch 0
sourced in sev-epoch 0
Encap length 36
450000000000400000115BEA0A000902
0A000202000010F500000000C068A6CF
00000001
LISP
Next chain element:
Protocol Interface Address
IP adj out of Ethernet0/1, addr 10.0.9.1
R116-xTR#
R112-xTR#[B]show interface ethernet 1/1 | in pack[/B]
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
4 packets input, 1504 bytes, 0 no buffer
0 input packets with dribble condition detected
[B] 23 packets output, 2640 bytes, 0 underruns[/B]
R112-xTR#[B]show interface ethernet 1/2 | in pack[/B]
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
511 packets input, 77258 bytes, 0 no buffer
0 input packets with dribble condition detected
[B]530 packets output, 78031 bytes, 0 underruns[/B]
R112-xTR#
Comment