Azure
GCP
Mục lục
Giao thức EIGRP (Part 3)
Tiếp nối series “Tự Học CCNAx” hôm nay mình xin chia sẻ về một giao thức định tuyến EIGRP(Enhanced Interior Gateway Routing Protocol) và cách thức mà giao thức EIGRP hoạt động trong một hệ thống mạng. Thực hiện các vai trò khá quan trọng trong hệ thống mạng – vai trò định tuyến(Routing). Mọi người cùng theo dõi với mình nhé.
Bài viết nên xem qua :
Series “Tự học CCNA”
1. EIGRP Default Route
Trong phần này mình sẻ gửi đến cách bạn một cái nhìn tổng quan về cấu hình default route trong EIGRP. Có 2 cách để cấu hình:
- Cấu hình một static route sau đó quảng bá route này vào EIGRP
- Cấu hình Redistribute Default route vào EIGRP
Cấu hình:
Cách 1: Static route sau đó quảng bá route này vào EIGRP
R2-ITFORVN(config)#router eigrp 23
R2-ITFORVN (config-router)#net 172.16.23.0 0.0.0.255
R2-ITFORVN (config-router)#no auto-summary
R3-ITFORVN(config)#router eigrp 23
R3-ITFORVN (config-router)#net 172.16.23.0 0.0.0.255
R3-ITFORVN (config-router)#no auto-summary
Cấu hình 1 default route trên R2 để Clients đi đến được 1.1.1.1/32 và quảng bá route này vào EIGRP.
R2-IFFORVN(config)#ip route 0.0.0.0 0.0.0.0 e0/1
R2-IFFORVN(config)#router eigrp 23
R2-IFFORVN(config-router)#net 0.0.0.0 0.0.0.0
Sau đó ta tiến hành “show ip route eigrp | begin 0.0.0.0” để xem R3 đã nhận được default route chưa.
Ta thấy Default Route đã được quảng bá vào EIGRP.
Ở đây có một lưu ý. Khi tạo default route ta nên tạo outbound interface hơn là dùng net-hops IP nếu muốn quảng bá vào EIGRP. Ở đây mình cũng không biết nguyên nhân vì sao. Mong các cao nhân dị sĩ giúp mình giải thích.
R2-IFFORVN(config)#ip route 0.0.0.0 0.0.0.0 172.16.12.1
Bằng chứng là khi R2 dùng net-hops IP thì R3 không nhận được default route.
Sau khi test xong thì tháo ra cấu hình ban đầu nhé.
R2-IFFORVN(config)#router eigrp 23
R2-IFFORVN(config-router)#no ne
R2-IFFORVN(config-router)#no net 0.0.0.0 0.0.0.0
R2-IFFORVN(config-router)#ex
R2-IFFORVN(config)#no ip route 0.0.0.0 0.0.0.0 e0/1
R2-IFFORVN(config)#
Cách 2: Redistribute Default route vào EIGRP
R2-IFFORVN(config)#ip route 0.0.0.0 0.0.0.0 172.16.12.1
R2-IFFORVN(config)#router eigrp 23
R2-IFFORVN(config-router)#redistribute static metric 1 1 1 1 1
R2-IFFORVN(config-router)#ex
Các thông số sau metric chính là Bw,delay….. của EIGRP nhé các bạn.
“show ip route eigrp”
Ta thấy thông số AD = 170 do Redistributed External route vào EIGRP.
Và trên R2 ta thấy cờ “Exterior Flag” đã được bật lên.
Bên cạnh đó ta có thể dùng “Ip default-network” để quảng bá vào EIGRP nhưng với Ciso ISO từ 12.4 trở lên đã không còn hộ trợ tính năng này nữa. Trong bài lab này mình sử dụng IOS 15.4
Trên R3: ping thành công 1.1.1.1/32
2. EIGRP Queries and Stuck
Phần này chúng ta sẻ tìm hiểu về Các gói tin queries của EIGRP và vấn đề stuck-in-active. Kế tiếp là những lợi ích khi sử dụng EIGRP Stub.
Đầu tiên ta biết đến EIGRP được thiết kế cho các mạng doanh nghiệp lớn. Nhưng với một mạng lớn chạy EIGRP(lớn hơn 5000 prefixes and hops) có thể dẫn đến một vài vấn đề:
- Topology table và Routing table sẻ rất “khủng” do ta có rất nhiều EIGRP prefixes.
- Tính toán “best-route” trở nên lâu hơn vì sẻ có rất nhiều EIGRP neighbor và nhiều đường đi tới mạng đích.
- Tính toán ra nhiều Feasible Successor à mất nhiều thời gian tính toán.
- Các Routers chạy EIGRP phải chạy nhiều process để xử lý nhiều thông tin định tuyến trao đổi trong EIGRP.
- Khi Router mất Route và không có Feasible Successor nó sẻ “bắn” queries ra tận cùng ngỏ ngách để truy route đã mất.
- EIGRP “bắn” queries ra tất cả các interfaces chạy EIGRP trừ interface của Successor.
Ta xét Topology sau:
Sơ đồ trên chạy EIGRP. Route 1.1.1.1/32 của R1 bị mất và không có đường Feasible để Back-up cho route này. Sau khi không có Back-up route R1 sẻ bắn Queries ra các Router neighbors R2, R3 – các trường hợp sau sẻ xảy ra
- R2 hoặc R5 có thông tin về route này và nó sẻ gửi gói replies về R1 cho biết thông tin về route này. Tới đây R1 sẻ ngưng không bắn query nữa.
- R2 và R6 không có bất cứ thông tin nào của Route này. R2 hoặc R5 sẻ tự phát ra bản tin query đến R3, R4, R6 để truy vấn Route này. Nếu R2 hoặc R5 nhận được replies từ các R4, R5, R6 nó sẻ gửi Queries về cho R1 về thông tin route này.
Mô hình trên mô tả quá trình bắn query để truy tìm route của R1.
Không có bất kì Router nào nằm sau R3, R4, R6. Chúng sẻ gửi reply trở ngược lại R2 và R5 để báo là chúng không biết thông tin về route này. Tiếp tục R2, R5 cũng sẻ gửi trả lời lại R1 rằng R2 và R5 cũng không biết thông tin về route 1.1.1.1/32.
Giả sử gói tin reply từ R5 gửi về R1 bị mất. EIGRP là giao thức reliable nên với mỗi gói query gửi đến neighbor nó phải nhận lại được một gói tin reply “trong 3 phút”. Nếu R1 không nhận được bất cứ bản tin reply nào. Nó sẻ đưa Route này vào trạng thái SIA (Stuck-In-Active) và xóa mối quan hệ neighbor với R5.
Sẻ như thế nào nếu gói tin reply không bao giờ được nhận bởi R1?
Từ IOS 12.1 Cisco đã thay đổi quá trình SIA để giảm “lost neighbor adjacencies”. Họ thiết kế ra 2 gói tin SIA query và SIA reply
Trước khi có SIA query và SIA reply thì hoạt động “bắn” queries và nhận replies sẻ diễn ra như sau:
- R1 mất route và không có feasible successor để backup
- R1 gửi query đến R2 và R5 để truy route bị mất
- R2 và R5 không biết thông tin về route này nên tiếp tục bắn query đến R3, R4, R6 để truy vấn thông tin route này.
- R3, R4, R6 không biết thông tin về route này sau đó gửi gói tin reply đến R2 và R5 để báo tin rằng nó cũng không có thông tin về route này.
- R2 và R5 lại tiếp tục gửi reply về R1 để báo R1 biết rằng nó cũng không biết thông tin nào về route mà R1 tìm.
- Tuy nhiên do một số nguyên nhân như nghẽn, mất gói…nên gói tin reply từ R5 à R1 không đến được R1.
- Sau 3 phút kể từ khi R1 không nhận được Reply sau khi bắn query từ R5 nó sẻ xóa R5 ra khỏi neighbor và xóa toàn bộ route hoặc được tử R5.
Sau khi có SIA query và SIA reply thì hoạt động “bắn” queries và nhận replies sẻ diễn ra như sau:
Quá trình cũng sẻ diễn ra tương tự từ bước 1 à 6
-
- Sau 1,5 phút R1 sẻ tự động gửi bản tin SIA query đến R5 để hỏi về trạng thái của R5
- R5 sẻ phản hồi bằng bản tin SIA reply để trả lời về trạng thái của nó và neighbor sẻ không bị drop nữa.
3. EIGRP Stub
Ta xét sơ đồ sau:
Khi R2 bị mất route 8.8.8.8/32 và không có backup-path nó sẻ như thường lệ bắn Query ra các neighbor để tìm lại thông tin về route này.
Tuy nhiên ta có thể thấy rằng việc gửi Query ra R3, R4, R5 là không cần thiết. Các R này được gọi là các EIGRP Router Stubs. Tức là nó không có bất kì neighbor nào sau lưng nó nữa. Đúng chất Stub “ngõ cụt”. Nếu các R này được cấu hình thành EIGPR Stub thì các gói tin Query chỉ thấy được như hình.
Vì khi cấu hình Stub, các Stub Routers sẻ không nhận gói tin query từ R1 và R2. Stub Routers là một kỹ thuật để stop query traffic.
Một số đặc tính của EIGRP Stub:
- Receive-only: Stub Router sẻ không quảng bá bất cứ network nào.
- Connected: cho phép Stub Router quảng bá các “directly connected route”
- Static: cho phép Stub Router quảng bá các static routes (redistributed)
- Summary: cho phép các Stubs advertise summary routes
- Redistribute: Các Stubs router sẻ advertise redistributed routes.
Default trên Router Cisco là connected + summary.
Cấu hình Stub, ta xét sơ đồ sau:
R1-ITFORVN(config)#router eigrp 1
R1-ITFORVN(config-router)#net 10.1.12.0 0.0.0.255
R1-ITFORVN(config-router)#net 1.1.1.0 0.0.0.255
R1-ITFORVN(config-router)#ex
R2-ITFORVN(config)#router eigrp 1
R2-ITFORVN(config-router)#net 10.1.12.0 0.0.0.255
R2-ITFORVN(config-router)#ex
Debug query trên 2 Device.
R1-ITFORVN(config)#do debug eigrp packets query
(QUERY)
EIGRP Packet debugging is on
R2-ITFORVN(config)#do debug eigrp packets query
(QUERY)
EIGRP Packet debugging is on
Giờ ta tiến hành shutdown interface loopback trên R1 để tạo TH mất route để xem các gói tin query. Ta sẻ thấy thiết bị báo log
R1-ITFORVN(config)#int lo0
R1-ITFORVN(config-if)#shut
R1-ITFORVN#
*Aug 1 06:56:49.386: EIGRP: Enqueueing QUERY on Et0/0 – paklen 0 tid 0 iidbQ un/rely 0/1 serno 3-3
*Aug 1 06:56:49.394: EIGRP: Sending QUERY on Et0/0 – paklen 44 tid 0
*Aug 1 06:56:49.394: AS 1, Flags 0x0:(NULL), Seq 3/0 interfaceQ 0/0 iidbQ un/rely 0/0 serno 3-3
R2-ITFORVN#
*Aug 1 06:56:49.395: EIGRP: Received QUERY on Et0/0 – paklen 44 nbr 10.1.12.1
*Aug 1 06:56:49.395: AS 1, Flags 0x0:(NULL), Seq 3/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Giờ tiến hành cấu hình Stub
R1-ITFORVN(config)#int lo0
R1-ITFORVN(config-if)#no shut
R1-ITFORVN(config)#router eigrp 1
R1-ITFORVN(config-router)#eigrp stub
Sau khi cấu hình stub thì EIGRP sẻ clear neighbor và thiết lập lại
Nhưng đã nói ở trên thì trạng thái mặc định của stub là connected + summary
R1-ITFORVN(config)#int lo0
R1-ITFORVN(config-if)#shut
R1-ITFORVN(config-if)#
*Aug 1 08:21:25.206: EIGRP: Received QUERY on Et0/0 – paklen 44 nbr 10.1.12.2
*Aug 1 08:21:25.206: AS 1, Flags 0x0:(NULL), Seq 12/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
R2-ITFORVN(config)# route: 1.1.1.0/24
*Aug 1 08:28:59.572: EIGRP: Enqueueing QUERY on Et0/0 – paklen 0 tid 0 iidbQ un/rely 0/1 serno 11-11
*Aug 1 08:28:59.580: EIGRP: Sending QUERY on Et0/0 – paklen 44 tid 0
*Aug 1 08:28:59.580: AS 1, Flags 0x0:(NULL), Seq 14/0 interfaceQ 0/0 iidbQ un/rely 0/0 serno 11-11
Ta thấy R2 gửi Query sang R1 vì nó mất route 1.1.1.0/24. R2 không nhận Query nữa vì nó là Stub Router.
————————————————————————————————————————-
Lời Kết bài 15
Bài chia sẻ về“Giao thức định tuyến EIGRP part 3“của mình xin tạm dừng tại đây. Bài chia sẻ tiếp theo mình xin chia sẻ về “Giao thức định tuyến EIGRP part 4 và cách thức hoạt động của giao thức định tuyến này trong hệ thống mạng“. Hãy theo dõi bài viết tiếp theo trong Series Tự học CCNA tại website và blog itforvn.vcode.ovh nhé. Nếu có thắc mắc hay đóng góp các Anh em hãy comment bên dưới nhé! Thân ái!
Tác giả: Quân Lê – ITFORVN.COM
Bạn có thể tương tác và cập nhật thông tin mới nhất của Nhóm Facebook ITFORVN, Các khóa học mới do group tổ chức tại «Portal»
