RIP Routing protocol Bangla Tutorial
Routing Information Protocol (RIP) (Part-1)
আসসালামু আলাইকুম। আশা করি আপনারা সবাই ভাল আছেন। ব্যস্ততার কারণে বেশ কিছু দিন ধরেই আমার ব্লগ এ কোন কিছু লিখতে পারি নাই। তবে এখন থেকে আবার শুরু করবো। আমার পরবর্তী লক্ষ্য হলো এ্যাডভান্স আইপি রাউটিং এর উপর ধারাবাহিকভাবে লিখে যাওয়া। আর সেই লক্ষ্যকে সামনে রেখে আমি রাউটিং প্রটোকল RIP থেকে শুরু করবো। অনেকেই বলতে পারেন যে, RIP কেন? এটা তো রিয়েল লাইফে ব্যবহার করা হয় না! কিন্তু আমার কথা হলো, কোন কিছু খুব ভালভাবে শিখতে চাইলে বেসিক থেকেই শুরু করতে হয়। আর এখন থেকে শুরু হওয়া আমাদের RIP সিরিজে আমরা RIP এর খুঁটিনাটি অনেক বিষয় নিয়ে বিস্তারিত আলোচনা করবো। আশা করি অনেকের ভাল লাগবে এবং অনেকেই ভাল কিছু শিখতে পারবেন। তবে CCIE Lovers-রা ই হলো আমার টার্গেট অডিয়েন্স।
ডাইনামিক রাউটিং প্রটোকলগুলোর মধ্যে RIP একটি পুরোনো প্রটোকল। ১৯৮৮ সালে এর ব্যবহার শুরু হয় এবং এটিকে RFC 1058 এর মাধ্যমে স্ট্যান্ডার্ডাইজ করা হয়েছে।
RIP এর কিছু বৈশিষ্ঠ্য
Distance Vector: RIP একটি Distance Vector রাউটিং প্রটোকল। এর অর্থ হলো কোন নির্দিষ্ট নেটওয়ার্কে যাওয়ার জন্য RIP শুধুমাত্র নেটওয়ার্কটি "কতদূরে রয়েছে?" (Distance) এবং "কোন দিক দিয়ে যেতে হবে?" (Vector) তার উপর ভিত্তি করে কাজ করে। একটি RIP এনাবলড রাউটারের কাছে এর চেয়ে আর বেশি কোন তথ্য থাকে না। ব্যাপারটি অনেকটা এরকম- আমি অপরিচিত কোন জায়গায় গিয়ে কিছু খাওয়ার জন্য KFC তে যেতে চাচ্ছি, কিন্তু আমি জানি না KFC কোথায়? ঐ জায়গায় থাকে এমন কোন লোকের কাছে আমি জিজ্ঞেস করলাম আর ঐ লোক আমাকে ডানের রাস্তা ধরে এগিয়ে যেতে বললো। আমি ডানের রাস্তা ধরে এগিয়ে গিয়ে আরেকটি মোড় পেলাম। সেখানে আরেক জনকে জিজ্ঞেস করাতে সে আমাকে বামের রাস্তা দেখিয়ে দিয়ে সেই রাস্তা ধরে এগিয়ে যেতে বললো, আমি এগিয়ে গেলাম। এভাবে বেশ কয়েকটি মোড়ে বেশ কয়েক জনের কাছে জিজ্ঞেস করে করে আমি KFC তে পৌছে গেলাম। এখানে একটি বিষয় উল্লেখ্য যে, KFC তে যাওয়ার পথটির কোন ক্লিয়ার পিকচার আমার কাছে ছিল না, মানুষ আমাকে যেভাবে পথ বলে দিয়েছে আমি তার উপর নির্ভর করে বেশ ককেয়টি রাস্তা/মোড় পাড় হয়ে আমার গন্তব্যে পৌছেছি। RIP রাউটিং প্রটোকলের ক্ষেত্রেও ব্যাপারটি অনেকটা একই রকম। কোন RIP এনাবলড রাউটারের কাছে কোন গন্তব্যে যাওয়ার জন্য রাউটিং পাথের ক্লিয়ার পিকচার থাকে না। তার পার্শ্ববর্তী রাউটার তাকে যে তথ্য দেয় তার উপর নির্ভর করে সে রাউটিং টেবিল তৈরী করে।
Hop Count: একটু আগে আমরা জানলাম কোন নির্দিষ্ট নেটওয়ার্কে যাওয়ার জন্য RIP শুধুমাত্র নেটওয়ার্কটি "কতদূরে রয়েছে?" (Distance) এবং "কোন দিক দিয়ে যেতে হবে?" (Vector) তার উপর ভিত্তি করে কাজ করে। এখন নেটওয়ার্কটি কতদূরে আছে তা স্পেসিফাই করার জন্য RIP রাউটার তার নিজের অবস্থান থেকে ডেষ্টিনেশন নেটওয়ার্কটি কত HOP অর্থাৎ কতগুলো রাউটার দূরে আছে তা গননা করে। যদি কোন ডেষ্টিনেশন নেটওয়ার্কে যাওয়ার জন্য একাধিক পাথ থাকে তাহলে কোন পাথ দিয়ে HOP এর সংখ্যা কম তা নির্ধারণ করে এবং অপেক্ষাকৃত কম HOP এর পাথটিকে রাউটিং টেবিলে যুক্ত করে। আর যদি দুইটি পাথের মধ্যে HOP বা রাউটার সংখ্যা সমান হয় তাহলে RIP রাউটার দুইটি পাথকেই রাউটিং টেবিলে যুক্ত করে। এখানে একটি কথা উল্লেখ্য যে, যদি RIP রাউটার কোন ডেষ্টিনেশন নেটওয়ার্কে যাওয়ার জন্য এমন কোন পাথের তথ্য পায় যে পাথে ১৫ টির বেশি রাউটার রয়েছে, সেক্ষেত্রে রাউটার ঐ পাথটিকে তার রাউটিং টেবিলে যুক্ত করবে না। এটি RIP রাউটিং প্রটোকলের একটি সীমাবদ্ধতা, কারণ যারা RIP তৈরী করেছে তাদের মাথায় বর্তমান যুগের নেটওয়ার্কের আকার এবং জটিলতা সম্পর্কিত কোন ধারণা ছিল না।
Periodic Update: একটি RIP রাউটার তার পার্শ্ববর্তী RIP রাউটারের কাছে নিয়মিতভাবে প্রতি ৩০ সেকেন্ড পর পর রাউটিং আপডেট পাঠাতে থাকে। নেটওয়ার্কে যদি কোন পরিবর্তন নাও হয় তারপরও এই আপডেট প্রতি ৩০ সেকেন্ড পর পর যেতেই থাকবে। এটিও RIP রাউটিং প্রটোকলের আরেকটি সীমাবদ্ধতা। কারণ অপ্রয়োজনীয় আপডেট নেটওয়ার্কে বাড়তি ঝামেলা (Overhead) তৈরী করে এবং এই অপ্রয়োজনীয় আপডেটগুলো প্রসেস করার জন্য রাউটারসমূহের রিসোর্স (সিপিইউ/মেমোরী) নষ্ট হয়।
RIP Version: RIP রাউটিং প্রটোকলের দুইটি ভার্সন রয়েছে: Version 1 এবং Version 2 । RIP রাউটারে বাই ডিফল্ট Version 1 এনাবল হয়ে থাকে।
টপোলজি
বেসিক কনফিগারেশন
চিত্রে প্রদত্ত টপোলজি অনুযায়ী আমরা প্রথমে R1 এবং R2 এর আইপি কনফিগার করবো।R1#conf t R1(config)#interface fastEthernet 0/0 R1(config-if)#ip address 192.168.12.1 255.255.255.0 R1(config-if)#no shutdown R1(config-if)#description R2 R1(config-if)#exit R1(config)#interface loopback 1 R1(config-if)#ip address 172.16.0.1 255.255.255.0 R2(config-if)#exit
R2#conf t R2(config)#interface fastEthernet 0/0 R2(config-if)#ip address 192.168.12.2 255.255.255.0 R2(config-if)#no shutdown R2(config-if)#description R1 R2(config-if)#exit
আইপি কনফিগার করার পর আমরা প্রথমে R1 এ RIP কনফিগার করবো।
R1(config)#router rip R1(config-router)#network 192.168.12.0 R1(config-router)#network 172.16.0.0
#router rip কমান্ড দেওয়ার সাথে সাথে R1 এ RIP রাউটিং প্রসেস শুরু হবে এবং R1 একটি RIP Database তৈরী করবে।
*Sep 2 17:23:06.499: RIP-DB: database initializedঅতঃপর আমরা #network কমান্ডের মাধ্যমে R1 এর দুইটি কানেক্টেড নেটওয়ার্ক 192.168.12.0 এবং 172.16.0.0 কে RIP রাউটিং প্রসেস যুক্ত করলাম। R1 এখন 192.168.12.0 এবং 172.16.0.0 কে নিজের RIP Database এ যুক্ত করবে। আমরা এখন R1 এর RIP Database দেখবো।
R1#show ip rip database 172.16.0.0/16 auto-summary 172.16.0.0/24 directly connected, Loopback1 192.168.12.0/24 auto-summary 192.168.12.0/24 directly connected, FastEthernet0/0
R1 এর RIP Database এ 192.168.12.0 এবং 172.16.0.0 এর স্পেসিফিক নেটওয়ার্কের পাশাপাশি দুইটি ক্লাসফুল সামারাইজড নেটওয়ার্কও যুক্ত হয়েছে। RIP রাউটারে বাই ডিফল্ট Version 1 এনাবল হয় এবং এই Version 1 হলো ক্লাসফুল।
RIPv1 এর ক্ষেত্রে R1 শুধুমাত্র ক্লাসফুল সামারাইজড নেটওয়ার্ক 172.16.0.0/16 কে RIP Update এর মাধ্যমে FastEthernet0/0 এর মধ্য দিয়ে পাঠাবে। R1 এখানে 192.168.12.0/24 এর আপডেট FastEthernet0/0 এর মধ্য দিয়ে পাঠাবে না। এটি RIP এর Split Horizon রুলস, যা আমরা পরবর্তীতে আলোচনা করবো।
এখন আমরা R2 এ RIP কনফিগার করবো।
R2(config)#router rip R2(config-router)#network 192.168.12.0
RIP কনফিগার করা শেষ হলে আমরা যদি R1 এবং R2 তে #debug ip rip events কমান্ড দেই তাহলে নিচের ডিবাগ লগ দেখতে পাবো।
RIP event debugging is on R1# *Sep 2 17:27:05.639: RIP: sending v1 update to 255.255.255.255 via Loopback1 (172.16.0.1) *Sep 2 17:27:05.643: RIP: Update contains 1 routes *Sep 2 17:27:05.643: RIP: Update queued *Sep 2 17:27:05.647: RIP: Update sent via Loopback1 R1# *Sep 2 17:27:17.519: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (192.168.12.1) *Sep 2 17:27:17.523: RIP: Update contains 1 routes *Sep 2 17:27:17.523: RIP: Update queued *Sep 2 17:27:17.527: RIP: Update sent via FastEthernet0/0 R1#
R1 তার Loopback1 এবং FastEthernet0/0 ইন্টারফেস দিয়ে v1 (Version 1) update পাঠাচ্ছে এবং Update প্যাকেটের মধ্যে একটি রাউট আছে। এখানে R1 শুধুমাত্র 172.16.0.0/16 এর আপডেট পাঠাবে, 192.168.12.0/24 এর আপডেট পাঠাবে না (RIP এর Split Horizon রুলস)। আর এই আপডেট প্রতি 30 সেকেন্ড পর পর Loopback1 এবং FastEthernet0/0 ইন্টারফেস দিয়ে ব্রডকাষ্ট হবে। কারণ RIP Version 1 এ Update প্যাকেটের সোর্স আইপি হলো 192.168.12.1 এবং ডেষ্টিনেশন আইপি হলো 255.255.255.255 । অর্থাৎ RIP Version 1 এ আপডেট প্যাকেট ইন্টারফেস দিয়ে বের হয়ে যদি কোন মাল্টি-এক্সেস (সুইচ যুক্ত) নেটওয়ার্ক পায় তাহলে ঐ আপডেট প্যাকেটটি উক্ত মাল্টি-এক্সেস নেটওয়ার্কের সব হোষ্টের কাছে যাবে।
RIP এর আপডেট টাইমার থিওরীটিক্যালী 30 সেকেন্ড বলা হলেও প্র্যাকটিক্যালী এটা 30 সেকেন্ডের থেকে 0% থেকে 15% সময় কম হয়। অর্থাৎ 25 থেকে 30 এর মধ্যে একটি র্যান্ডম সময় হয়ে থাকে। RIP Jitter নামক একটি বিশেষ ফিচারের কারণে এটি এরকম হয়, পরবর্তীতে আমরা এটি নিয়ে বিস্তারিত আলোচনা করবো।
এখন আমরা R2 এর ডিবাগ লগ দেখবো।
R2# *Sep 2 18:43:17.675: RIP: received v1 update from 192.168.12.1 on FastEthernet0/0 *Sep 2 18:43:17.679: RIP: Update contains 1 routes R2# *Sep 2 18:43:19.955: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (192.168.12.2) - suppressing null update R2#
এখানে দেখা যাচ্ছে যে, R2 তার FastEthernet0/0 ইন্টারফেস দিয়ে R1 এর কাছে থেকে একটি আপডেট রিসিভ করছে যার মধ্যে একটি রাউট রয়েছে। এবং FastEthernet0/0 ইন্টারফেস দিয়ে যে আপডেট পাঠাচ্ছে তা একটি Null আপডেট। এখানে R2 #network কমান্ডের মাধ্যমে 192.168.12.0/24 নেটওয়ার্কটি এ্যাডভার্টাইজ করেছে কিন্তু এই নেটওয়ার্কের আপডেট R2 তার FastEthernet0/0 ইন্টারফেস দিয়ে পাঠাবে না। RIP এর Split Horizon রুলসটি হলো, রাউটার তার যে ইন্টারফেস দিয়ে কোন নেটওয়ার্ককে নিজের RIP Database এ যুক্ত করে একই নেটওয়ার্কের আপডেট সে ঐ ইন্টারফেস দিয়ে আর পাঠায় না।
R2#show ip rip database
172.16.0.0/16 auto-summary
172.16.0.0/16
[1] via 192.168.12.1, 00:00:00, FastEthernet0/0
192.168.12.0/24 auto-summary
192.168.12.0/24 directly connected, FastEthernet0/0এখানে R2 তে #network কমান্ডের মাধ্যমে 192.168.12.0/24 নেটওয়ার্কটি এ্যাডভার্টাইজ করার কারণে R2 নেটওয়ার্কটিকে তার RIP Database এ যুক্ত করেছে এবং R2 তে 192.168.12.2/24 আইপি টি এর FastEthernet0/0 ইন্টারফেসে এ্যাসাইন থাকার কারণে R2 এর RIP Database এ উক্ত নেটওয়ার্কের বিপরীতে FastEthernet0/0 ইন্টারফেসটি চিহ্নিত করা আছে। আর একারণে R2 192.168.12.0/24 নেটওয়ার্কের আপডেট FastEthernet0/0 ইন্টারফেস দিয়ে কাউকে পাঠাবে না। নেটওয়ার্কে যাতে কোন রাউটিং লুপ না হয় সে কারণে RIP রাউটিং প্রটোকলে এই Split Horizon রুলসটি রাখা হয়েছে।
R2 এর RIP Database এ দেখা যাচ্ছে যে, R2 তার FastEthernet0/0 ইন্টারফেস দিয়ে 172.16.0.0/16 নেটওয়ার্কের আপডেট R1 এর কাছ থেকে পেয়েছে যা একটি HOP দূরে আছে। R2 এই আপডেটটি নিজের রাউটিং টেবিলে এন্ট্রি দিবে কিন্তু এই আপডেটটি নিজের FastEthernet0/0 ইন্টারফেস দিয়ে কখনো পাঠাবে না, তবে অন্যান্য RIP এনাবলড ইন্টারফেস দিয়ে পাঠাবে (যদি থাকে)।
এখন আমরা R2 এর রাউটিং টেবিল চেক করবো।
R2#show ip route rip R 172.16.0.0/16 [120/1] via 192.168.12.1, 00:00:11, FastEthernet0/0
R ঃ R দ্বারা এখানে বুঝানো হচ্ছে যে রাউটটি RIP এর মাধ্যমে এসেছে
172.16.0.0/16 ঃ R1 এ যদিও 172.16.0.0/24 আছে কিন্তু RIP v1 এর কারণে R2 তে 172.16.0.0/16 এর রাউটিং আপডেট এসেছে, কারণ RIPv1 একটি ক্লাসফুল রাউটিং প্রটোকল
[120/1] ঃ এখানে 120 হলো RIP এর ডিফল্ট Adminsitrative Distance (AD) এবং 1 হলো 172.16.0.0/16 নেটওয়ার্ককে যাওয়ার জন্য Intermediary HOP এর সংখ্যা
via 192.168.12.1 ঃ 172.16.0.0/16 ডেষ্টিনেশনে যাওয়ার জন্য R2 এর Next-Hop হলো 192.168.12.1
00:00:11 ঃ 172.16.0.0/16 নেটওয়ার্কটির সর্বশেষ আপডেটটি এসেছে 11 সেকেন্ড আগে
FastEthernet0/0 ঃ 172.16.0.0/16 নেটওয়ার্ককে যাওয়ার জন্য R2 এর Exit Interface হলো FastEthernet0/0
এখন আমরা চাইলে R2 থেকে 172.16.0.1 আইপি কে Ping দিয়ে কানেক্টিভিটি চেক করতে পারি।
R2#ping 172.16.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 56/64/68 ms
আমাদের এই নেটওয়ার্ককে RIP কনফিগার করার পর R1 রাউটার R2 এর সাথে নিজের রাউটিং ইনফোরমেশন শেয়ার করেছে। তাহলে কি R1 এবং R2 একে অন্যের Neighbor?
R1 এবং R2 একে অন্যের সাথে রাউটিং ইনফোরমেশন শেয়ার করলেও কেউ কারো Neighbor নয়। কারণ, অন্যান্য রাউটিং প্রটোকলের মতো RIP এ Neighbor Relationship এর কোন ধারণা নেই। একটি RIP এনাবলড রাউটার অন্ধভাবে তার ইন্টারফেস দিয়ে RIP আপডেট পাঠায়। এবং যদি নিজের কোন ইন্টারফেসে RIP আপডেট আসে তাহলে তা রিসিভ করে। কিন্তু যার সাথে RIP আপডেট আদান-প্রদান হলো তার সাথে কোন ধরণের Neighbor Relationship তৈরী করে না। তবে RIP এ Unicast আপডেট পাঠানোর জন্য Static Neighbor কনফিগার করা যায়। কিন্তু সেক্ষেত্রেও Neighbor Relationship বা Neighbor Adjecency তৈরী হয় না।
এখন আমরা #show ip protocol কমান্ডের মাধ্যমে RIP এর ভার্সন সম্পর্কিত একটি তথ্য জানবো।
R1#show ip protocols
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 26 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 1, receive any version
Interface Send Recv Triggered RIP Key-chain
FastEthernet0/0 1 1 2
Loopback1 1 1 2
Automatic network summarization is in effect
Maximum path: 4
Routing for Networks:
172.16.0.0
192.168.12.0
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 120)RIPv1 এনাবলড রাউটার শুধুমাত্র v1 আপডেট পাঠাতে পারে, কিন্তু আপডেট রিসিভ করার ক্ষেত্রে এটি v1 এবং v2 উভয় ধরণের রাউটারের কাছ থেকেই আপডেট রিসিভ করতে পারে।
এখন আমরা আমাদের নেটওয়ার্ককে একটু বড় করবো।
চিত্রের টপোলজি অনুসারে আমরা R2 এবং R3 তে আইপি কনফিগার করবো এবং পরবর্তীতে RIP কনফিগার করবো।
R2#conf t R2(config)#interface fastEthernet 0/1 R2(config-if)#ip address 192.168.13.1 255.255.255.0 R2(config-if)#no shutdown R2(config-if)#description R3 R2(config-if)#exit
R3#conf t R3(config)#interface fastEthernet 0/0 R3(config-if)#ip address 192.168.23.2 255.255.255.0 R3(config-if)#no shutdown R3(config-if)#description R2 R3(config-if)#exit R3(config)#interface loopback 1 R3(config-if)#ip address 172.16.1.1 255.255.255.0 R3(config-if)#exit
R2#conf t R2(config)#router rip R2(config-router)#network 192.168.23.0 R2(config-router)#exit
R3#conf t R3(config)#router rip R3(config-router)#network 192.168.23.0 R3(config-router)#network 172.16.1.0 R3(config-router)#exit
নেটওয়ার্কের বর্ধিত অংশে RIP কনফিগার করার পর আমরা R3 এর রাউটিং টেবিল চেক করবো সেখানে R1 এর Loopback1 এর 172.16.0.0 নেটওয়ার্কটি এসেছে কিনা?
R3#show ip route rip R 192.168.12.0/24 [120/1] via 192.168.23.1, 00:00:28, FastEthernet0/0
আসে নাই!!
এখন R1 এর রাউটিং টেবিলে আমরা দেখবো R3 এর Loopback1 এর 172.16.1.0 নেটওয়ার্কটি এসেছে কিনা?
R1#show ip route rip R 192.168.23.0/24 [120/1] via 192.168.12.2, 00:00:16, FastEthernet0/0
আসে নাই!! কিন্তু কারণ কি? কনফিগারেশন তো সব ঠিকই আছে!
এই রহস্য উদঘাটন করতে হলে আমদেরকে R2 এর রাউটিং টেবিল দেখতে হবে।
R2#show ip route rip
R 172.16.0.0/16 [120/1] via 192.168.23.2, 00:00:07, FastEthernet0/1
[120/1] via 192.168.12.1, 00:00:07, FastEthernet0/0R2 এর রাউটিং টেবিলে দেখা যাচ্ছে, এটি 172.16.0.0/16 নেটওয়ার্কটি দুই দিক থেকে লার্ণ করেছে। একটি R1 এর কাছ থেকে এবং অপরটি R3 এর কাছ থেকে। কিন্তু এই রাউটিং আপডেট সে R1 এবং R3 কারো কাছে পাঠাচ্ছে না। কারণ কি?
এর কারণ হলো, R1 এ RIP v1 কনফিগার করায় R1 তার 172.16.0.0/24 নেটওয়ার্কের তথ্য R2 এর কাছে পাঠানোর সময় 172.16.0.0/16 ক্লাসফুল হিসেবে পাঠিয়েছে। আবার, R3 তেও RIP v1 কনফিগার করায় R3 তার 172.16.1.0/24 নেটওয়ার্কের তথ্য R2 এর কাছে পাঠানোর সময় 172.16.0.0/16 ক্লাসফুল হিসেবে পাঠিয়েছে।
R1#show ip protocols | include summarization
Automatic network summarization is in effectR2#show ip protocols | include summarization
Automatic network summarization is in effectR3#show ip protocols | include summarization
Automatic network summarization is in effectR2#show ip rip database
172.16.0.0/16 auto-summary
172.16.0.0/16
[1] via 192.168.23.2, 00:00:20, FastEthernet0/1
[1] via 192.168.12.1, 00:00:13, FastEthernet0/0
192.168.12.0/24 auto-summary
192.168.12.0/24 directly connected, FastEthernet0/0
192.168.23.0/24 auto-summary
192.168.23.0/24 directly connected, FastEthernet0/1R2 এর RIP Database এ এই 172.16.0.0/16 নেটওয়ার্কের ক্লাসফুল আপডেটটি FastEthernet0/0 এবং FastEthernet0/1 দুই ইন্টারফেস দিয়ে আসায় R2 RIP এর Split Horizon রুলস অনুযায়ী তা আর FastEthernet0/0 এবং FastEthernet0/1 ইন্টারফেস দিয়ে ব্রডকাষ্ট করছে না। তাই R1 এর আপডেট R3 এর কাছে যাচ্ছে না এবং R3 এর আপডেটও R1 এর কাছে যাচ্ছে না। এথেকে সমাধানের উপায় কি? Split Horizon রুলস বন্ধ করে দেওয়া? ..... না.....। RIP এর Split Horizon রুলস বন্ধ করলে এ সমস্যার সমাধান তো হবেই না উল্টো বিশেষ ক্ষেত্রে নেটওয়ার্কে অনাকাঙ্খিত লুপ হতে পারে, তাই এটি বন্ধ করা উচিৎ নয়। এই সমস্যা সমাধানের একমাত্র উপায় হলো রাউটারসমূহে RIP v2 এনাবল করা। RIPv1 এর বেশ কিছু সীমাবদ্ধতা দূর করার জন্য 1994 সালে RIPv2 এর আবির্ভাব হয়েছিল।
RIP v2 এনাবল করার জন্য রাউটারসমূহের RIP কনফিগারেশন মুডে দুইটি বাড়তি কমান্ড দিতে হবে।
R1#conf t R1(config)#router rip R1(config-router)#version 2 R1(config-router)#no auto-summary R1(config-router)#exit
R2#conf t R2(config)#router rip R2(config-router)#version 2 R2(config-router)#no auto-summary R2(config-router)#exit
R3#conf t R3(config)#router rip R3(config-router)#version 2 R3(config-router)#no auto-summary R3(config-router)#exit
R1, R2 এবং R3 তে RIPv2 এনাবল করার কারণে এই রাউটারসমূহে Auto Summrization বন্ধ হয়ে গেছে।
R1#show ip protocols | include summarization
Automatic network summarization is not in effectR2#show ip protocols | include summarization
Automatic network summarization is not in effectR3#show ip protocols | include summarization
Automatic network summarization is not in effectএবং R2 এখন R1 এর কাছ থেকে 172.16.0.0/24 নেটওয়ার্কের এবং R3 এর কাছ থেকে 172.16.1.0/24 নেটওয়ার্কের স্পেসিফিক আপডেট পাচ্ছে। এবং পরবর্তীতে R2 রাউটার R1 এর কাছ থেকে পাওয়া 172.16.0.0/24 নেটওয়ার্কের আপডেট R3 এর কাছে পাঠাচ্ছে এবং R3 এর কাছ থেকে পাওয়া 172.16.1.0/24 নেটওয়ার্কের আপডেট R1 এর কাছে পাঠাচ্ছে। আর এভাবে R1 এবং R3 একে অপরের আপডেট রিসিভ করে নিজেদের RIP Database এবং রাউটিং টেবিল তৈরী করছে।
R1#show ip route rip
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
R 172.16.1.0/24 [120/2] via 192.168.12.2, 00:00:11, FastEthernet0/0
R 192.168.23.0/24 [120/1] via 192.168.12.2, 00:00:11, FastEthernet0/0R2#show ip route rip
172.16.0.0/24 is subnetted, 2 subnets
R 172.16.0.0 [120/1] via 192.168.12.1, 00:00:00, FastEthernet0/0
R 172.16.1.0 [120/1] via 192.168.23.2, 00:00:16, FastEthernet0/1R3#show ip route rip
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
R 172.16.0.0/24 [120/2] via 192.168.23.1, 00:00:29, FastEthernet0/0
R 192.168.12.0/24 [120/1] via 192.168.23.1, 00:00:29, FastEthernet0/0আমরা রাউটারসমূহের রাউটিং টেবিল চেক করলে আমাদের কাঙ্খিত আউপুট পাবো। RIP v2 এনাবল করে কাঙ্খিত আউপুট পাওয়ার জন্য আমাদেরকে বেশ কিছুক্ষন অপেক্ষা করতে হবে। যেহেতু RIP খুবই Slow Convergence প্রটোকল তাই Flush Timer এক্সপায়ারড (চার মিনিট) না হওয়া পর্যন্ত অপেক্ষা করতে হবে।
RIPv1 এবং RIPv2 এর মধ্যে Automatic Summrization ছাড়াও আরো বেশ কিছু পার্থক্য রয়েছে। যেমনঃ RIPv1 রাউটার 255.255.255.255 আইপি ব্যবহার করে Broadcast আপডেট পাঠায়। কিন্তু RIPv2 রাউটার Broadcast আপডেট না পাঠিয়ে Multicast আপডেট পাঠায়। আর এ জন্য এটি মাল্টিকাষ্ট গ্রুপ আইপি 224.0.0.9 ব্যবহার করে।
R1#debug ip rip events *Sep 3 00:09:24.499: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (192.168.12.1) *Sep 3 00:09:24.507: RIP: Update contains 1 routes *Sep 3 00:09:24.507: RIP: Update queued *Sep 3 00:09:24.511: RIP: Update sent via FastEthernet0/0
এই মাল্টিকাষ্ট আপডেটটি কোন মাল্টি-এক্সেস নেটওয়ার্কের শুধুমাত্র RIPv2 এনাবলড রাউটারসমূহের কাছে যাবে কিন্তু কোন হোষ্টের কাছে যাবে না।
আমরা আগেই জেনেছি যে, RIPv1 এনাবলড রাউটার শুধুমাত্র v1 আপডেট পাঠাতে পারে, কিন্তু আপডেট রিসিভ করার ক্ষেত্রে এটি v1 এবং v2 উভয় ধরণের রাউটারের কাছ থেকে আপডেট রিসিভ করতে পারে। পক্ষান্তরে RIPv2 এনাবলড রাউটার শুধুমাত্র v1 আপডেট পাঠাতে পারে এবং শুধুমাত্র v2 এনাবলড রাউটারের কাছ থেকে আপডেট রিসিভ করতে পারে। আমাদের রাউটারসমূহে আমরা ইতিমধ্যে v2 এনাবল করেছি, তাই চাইলে আমরা ভার্সন ক্যাপাবিলিটি দেখে নিতে পারি।
R1#show ip protocols
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 18 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Interface Send Recv Triggered RIP Key-chain
FastEthernet0/0 2 2
Loopback1 2 2
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
172.16.0.0
192.168.12.0
Routing Information Sources:
Gateway Distance Last Update
192.168.12.2 120 00:00:10
Distance: (default is 120)এছাড়াও RIPv2 রাউটার Manual Route Summarization এবং Authentication সাপোর্ট করে, যা RIPv1 রাউটার করে না।
Passive Interface in RIP
আমরা CCNA লেভেলে RIP পড়ার সময় Passive Interface সম্পর্কে জেনেছি। আমরা জানি যে, রাউটারের যে সকল ইন্টারফেস সমূহে RIP এনাবল করা হয় রাউটার সেই সকল ইন্টারফেস দিয়ে নিজের RIP Database পাঠায়। কিন্তু সব ইন্টারফেস দিয়ে RIP Database পাঠানোর দরকার নাও হতে পারে। যেমনঃ রাউটারের ল্যান ইন্টারফেস। আমরা রাউটারের ল্যান ইন্টারফেসের নেটওয়ার্ককে RIP এ এ্যাডভার্টাইজ করি যাতে করে পার্শ্ববর্তী রাউটারসমূহ RIP এর মাধ্যমে নেটওয়ার্কটির আপডেট পায় এবং নিজেদের রাউটিং টেবিল তৈরী করে পরবর্তীতে এই নেটওয়ার্কের দিকে ট্রাফিক পাঠাতে পারে। কিন্তু রাউটারের ল্যান ইন্টারফেসের নেটওয়ার্ককে RIP এ এ্যাডভার্টাইজ করার সাথে সাথেই রাউটার ঐ ল্যান ইন্টারফেস দিয়েও Periodic Update পাঠাতে শুরু করে। ল্যান ইন্টারফেস এ যুক্ত নেটওয়ার্ক সেগমেন্টে যদি কোন রাউটার না থাকে এবং কোন রাউটারের সাথে যদি RIP আপডেট আদান-প্রদানের কোন ব্যাপার না থাকে তাহলে ঐ ল্যান ইন্টারফেস দিয়ে আপডেট পাঠানো বন্ধ করে রাখাই ভাল। আর এজন্য উক্ত ল্যান ইন্টারফেসটিকে Passive Interface হিসেবে কনফিগার করা যেতে পারে।
RIP event debugging is on R1# *Sep 3 01:31:38.651: RIP: sending v2 update to 224.0.0.9 via Loopback1 (172.16.0.1) R1# *Sep 3 01:31:57.975: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (192.168.12.1) R1# *Sep 3 01:32:07.179: RIP: sending v2 update to 224.0.0.9 via Loopback1 (172.16.0.1) R1# *Sep 3 01:32:23.895: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (192.168.12.1) R1#
R1 এর ডিবাগ লগে দেখা যাচ্ছে যে, R1 তার FastEthernet0/0 এবং Loopback1 ইন্টারফেস দিয়ে মাল্টিকাষ্ট আপডেট পাঠাচ্ছে। যেহেতু আমাদের ল্যাবটি আমরা GNS3 তে করছি তাই এখানে হোষ্ট ল্যান হিসেবে রিপ্রেজেন্ট করার জন্য আমরা ফিজিক্যাল ইন্টারফেসের বদলে Loopback ইন্টারফেস ব্যবহার করছি। রিয়েল নেটওয়ার্কে ফিজিক্যাল ইন্টারফেস ব্যবহার করলে সেই ফিজিক্যাল ইন্টারফেস দিয়েও একইভাবে Periodic Update যেতেই থাকবে। এখন আমরা এই Loopback ইন্টারফেস দিয়ে আপডেট যাওয়া বন্ধ করতে ইন্টারফেসটিকে Passive Interface হিসেবে কনফিগার করবো।
R1#conf t R1(config)#router rip R1(config-router)#passive-interface loopback 1 R1(config-router)#exit
এখন যদি আমরা আবার ডিবাগ লগ চেক করি তাহলে দেখবো যে, R1 আর loopback 1 ইন্টারফেস দিয়ে RIP আপডেট পাঠাচ্ছে না।
R1# *Sep 3 01:35:43.799: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (192.168.12.1) R1# *Sep 3 01:36:11.759: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (192.168.12.1) R1# *Sep 3 01:36:41.423: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (192.168.12.1) R1#
অর্থাৎ, loopback 1 ইন্টারফেসটিকে Passive করার কারণে R1 এই ইন্টারফেস দিয়ে আর কখনোই RIP আপডেট পাঠাবে না। প্রোডাকশন নেটওয়ার্কে অনেকেই এটিকে একটি সিকিউরিটি ফিচার হিসেবে মনে করেন। কিন্তু অন্যান্য রাউটিং প্রটোকলের ক্ষেত্রে এটি কিছুটা সিকিউরিটি দিলেও RIP এর ক্ষেত্রে তা দেয় না। কারণ অন্যান্য রাউটিং প্রটোকলে Passive Interface ফিচার ব্যবহার করে কোন নির্দিষ্ট ইন্টারফেস দিয়ে Hello প্যাকেট পাঠানো বন্ধ করা হয়, যাতে করে ঐ ইন্টারফেস দিয়ে কোন অননুমোদিত রাউটারের সাথে Neighborship তৈরী না হয়। কিন্তু RIP যেহেতু কোন Hello প্যাকেট পাঠায় না বা কোন রাউটারের সাথে Neighborship মেইনটেইন করে না তাই RIP এর ক্ষেত্রে এটিকে সিকিউরিটি ফিচার হিসেবে ব্যবহার করা যায় না। কারণ, Passive Interface এর কারণে রাউটার কোন ইন্টারফেস দিয়ে আপডেট না পাঠালেও যদি ঐ ইন্টারফেসে কোন আপডেট আসে তাহলে তা রিসিভ করে!
ব্যাপারটিকে একটু ভালভাবে বুঝার জন্য আমরা R1 এর FastEthernet0/0 ইন্টারফেসটিকে Passive Interface হিসেবে কনফিগার করবো। আমরা আপাতত মনে করি যে, R1 এর FastEthernet0/0 ইন্টারফেস দিয়ে R2 এর কাছে আপডেট পাঠানোর কোন দরকার নাই।
R1#conf t R1(config)#router rip R1(config-router)#passive-interface fastEthernet 0/0 R1(config-router)#exit
R1 এর FastEthernet0/0 ইন্টারফেসটিকে Passive Interface হিসেবে কনফিগার করার পর R1 এই ইন্টারফেস দিয়ে আপডেট পাঠানো বন্ধ করে দিয়েছে। তাই R2 রাউটার R1 এর কাছ থেকে কোন আপডেট পাচ্ছে না এবং Flush Timer (চার মিনিট) এক্সপায়ারড হওয়ার পর R1 এর কাছ থেকে প্রাপ্ত 172.16.0.0/24 রাউটটিকে রাউটিং টেবিল থেকে মুছে দিয়েছে। কিন্তু R1 এখনো FastEthernet0/0 ইন্টারফেস দিয়ে R2 এর পাঠানো আপডেট রিসিভ করছে।
R1#show ip route rip
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
R 172.16.1.0/24 [120/2] via 192.168.12.2, 00:00:18, FastEthernet0/0
R 192.168.23.0/24 [120/1] via 192.168.12.2, 00:00:18, FastEthernet0/0R2#show ip route rip
172.16.0.0/24 is subnetted, 1 subnets
R 172.16.1.0 [120/1] via 192.168.23.2, 00:00:05, FastEthernet0/1আমরা যদি কোন ভ্যালিড ল্যান ইন্টারফেসে (উদাহরণস্বরূপ FastEthernet0/0) আগত RIP আপডেট R1 এ রিসিভ করতে না চাই তাহলে নিচের মতো করে একটি ACL এ্যাপ্লাই করতে পারি।
R1#conf t R1(config)#access-list 100 deny ip any host 224.0.0.9 R1(config)#access-list 100 permit ip any any R1(config)#interface fastEthernet 0/0 R1(config-if)#ip access-group 100 in R1(config-if)#exit
ACL টি ঠিকভাবে কনফিগার করতে পারলে R1 তার FastEthernet0/0 ইন্টারফেসে আগত কোন RIP আপডেট রিসিভ করবে না। এবং Flush Timer (চার মিনিট) এক্সপায়ারড হয়ে গেলে R2 এর কাছ থেকে ইতিমধ্যে প্রাপ্ত রাউটগুলোও মুছে ফেলবে।
R1#show ip route rip
এখানে RIPv2 কনফিগার করার কারণে ACL এ মাল্টিকাষ্ট গ্রুপ আইপি 224.0.0.9 ব্যবহার করা হয়েছে। RIPv1 হলে এর পরিবর্তে 255.255.255.255 আইপি ব্যবহার করতে হবে।
যেহেতু আমরা শুধুমাত্র প্রায়োগিগ উদাহরণ দেখানোর জন্য ACL ব্যবহার করেছি তাই বুঝা শেষ হলে আবার ACL টি তুলে দিব। কারণ আমাদের টপোলজিতে R1 এবং R2 এর মধ্যে RIP আপডেট আদান-প্রদান করতে হবে।
R1#conf t R1(config)#no access-list 100 R1(config)#interface fastEthernet 0/0 R1(config-if)#no ip access-group 100 in R1(config-if)#exit R1(config)#router rip R1(config-router)#no passive-interface fastEthernet 0/0 R1(config-router)#exit
Comments
Post a Comment