VxLAN فیکٹری۔ حصہ 3

ہیلو، حبر۔ میں مضامین کا ایک سلسلہ ختم کر رہا ہوں، کورس کے آغاز کے لیے وقف ہے۔ "نیٹ ورک انجینئر" OTUS کی طرف سے، تانے بانے کے اندر روٹنگ کے لیے VxLAN EVPN ٹیکنالوجی کا استعمال اور اندرونی خدمات کے درمیان رسائی کو محدود کرنے کے لیے فائر وال کا استعمال

سیریز کے پچھلے حصے درج ذیل لنکس پر دیکھے جا سکتے ہیں۔

• سائیکل کا 1 حصہ - سرورز کے درمیان L2 رابطہ
• سیریز کا حصہ 2 - VNIs کے درمیان روٹنگ
• سیریز کا حصہ 2.5 - نظریاتی اختلاف

آج ہم VxLAN فیبرک کے اندر روٹنگ منطق کا مطالعہ جاری رکھیں گے۔ پچھلے حصے میں، ہم نے ایک ہی VRF میں انٹرا فیبرک روٹنگ کو دیکھا۔ تاہم، نیٹ ورک میں کلائنٹ کی خدمات کی ایک بڑی تعداد ہو سکتی ہے، اور ان سب کو مختلف VRFs میں تقسیم کیا جانا چاہیے تاکہ ان کے درمیان رسائی میں فرق کیا جا سکے۔ نیٹ ورک کی علیحدگی کے علاوہ، کسی کاروبار کو ان خدمات کے درمیان رسائی کو محدود کرنے کے لیے فائر وال کو جوڑنے کی ضرورت پڑ سکتی ہے۔ ہاں، اسے بہترین حل نہیں کہا جا سکتا، لیکن جدید حقائق کے لیے "جدید حل" کی ضرورت ہے۔

آئیے VRFs کے درمیان روٹنگ کے لیے دو اختیارات پر غور کریں:

1. VxLAN کپڑے چھوڑے بغیر روٹنگ؛
2. بیرونی آلات پر روٹنگ۔

آئیے VRFs کے درمیان روٹنگ منطق کے ساتھ شروع کریں۔ VRFs کی ایک مخصوص تعداد ہے۔ VRFs کے درمیان روٹ کرنے کے لیے، آپ کو نیٹ ورک میں ایک ایسا آلہ منتخب کرنے کی ضرورت ہے جو تمام VRFs (یا ان حصوں کے بارے میں جانتا ہو جن کے درمیان روٹنگ کی ضرورت ہے)۔ ایسا آلہ ہو سکتا ہے، مثال کے طور پر، Leaf سوئچز میں سے ایک (یا تمام ایک ساتھ) . یہ ٹوپولوجی اس طرح نظر آئے گی:

اس ٹوپولوجی کے نقصانات کیا ہیں؟

یہ ٹھیک ہے، ہر لیف کو نیٹ ورک پر موجود تمام VRFs (اور ان میں موجود تمام معلومات) کے بارے میں جاننے کی ضرورت ہوتی ہے، جس کی وجہ سے میموری کی کمی اور نیٹ ورک کا بوجھ بڑھتا ہے۔ سب کے بعد، اکثر ہر لیف سوئچ کو نیٹ ورک پر موجود ہر چیز کے بارے میں جاننے کی ضرورت نہیں ہوتی ہے۔

تاہم، آئیے اس طریقہ پر مزید تفصیل سے غور کریں، کیونکہ چھوٹے نیٹ ورکس کے لیے یہ آپشن کافی موزوں ہے (اگر کوئی خاص کاروباری تقاضے نہ ہوں)

اس موقع پر، آپ کے ذہن میں یہ سوال ہو سکتا ہے کہ معلومات کو VRF سے VRF میں کیسے منتقل کیا جائے، کیونکہ اس ٹیکنالوجی کا نقطہ بالکل درست ہے کہ معلومات کی ترسیل کو محدود کیا جانا چاہیے۔

اور جواب روٹنگ معلومات کی برآمد اور درآمد جیسے افعال میں ہے (اس ٹیکنالوجی کو ترتیب دینے پر غور کیا گیا تھا دوسری سائیکل کے حصے)۔ مجھے مختصراً دہرانے دو:

AF میں VRF سیٹ کرتے وقت، آپ کو بتانا ضروری ہے۔ route-target درآمد اور برآمد روٹنگ کی معلومات کے لیے۔ آپ اسے خود بخود بتا سکتے ہیں۔ پھر قیمت میں VRF سے وابستہ ASN BGP اور L3 VNI شامل ہوں گے۔ یہ اس وقت آسان ہے جب آپ کی فیکٹری میں صرف ایک ASN ہو:

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! В автоматическом режиме экспортируется RT-65001:99000
    route-target import auto

تاہم، اگر آپ کے پاس ایک سے زیادہ ASN ہیں اور آپ کو ان کے درمیان روٹس کی منتقلی کی ضرورت ہے، تو دستی کنفیگریشن زیادہ آسان اور قابل توسیع آپشن ہوگی۔ route-target. دستی سیٹ اپ کے لیے تجویز پہلا نمبر ہے، اس کا استعمال کریں جو آپ کے لیے آسان ہو، مثال کے طور پر، 9999.
دوسرا اس VRF کے لیے VNI کے برابر ہونا چاہیے۔

آئیے اسے مندرجہ ذیل ترتیب دیں:

vrf context PROD10
  address-family ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Пример 1 import из другого VRF
    route-target import 9999:88000         ! Пример 2 import из другого VRF

روٹنگ ٹیبل میں یہ کیسا لگتا ہے:

Leaf11# sh ip route vrf prod
<.....>
192.168.20.0/24, ubest/mbest: 1/0
    *via 10.255.1.20%default, [200/0], 00:24:45, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN          ! префикс доступен через L3VNI 99000

آئیے VRFs کے درمیان روٹنگ کے دوسرے آپشن پر غور کریں - بیرونی آلات کے ذریعے، مثال کے طور پر فائر وال۔

بیرونی ڈیوائس کے ذریعے کام کرنے کے کئی اختیارات ہیں:

1. آلہ جانتا ہے کہ VxLAN کیا ہے اور ہم اسے کپڑے کے حصے میں شامل کر سکتے ہیں۔
2. آلہ VxLAN کے بارے میں کچھ نہیں جانتا ہے۔

ہم پہلے آپشن پر توجہ نہیں دیں گے، کیونکہ منطق تقریباً وہی ہوگی جیسا کہ اوپر دکھایا گیا ہے - ہم تمام VRFs کو فائر وال پر لاتے ہیں اور اس پر VRFs کے درمیان روٹنگ ترتیب دیتے ہیں۔

آئیے دوسرے آپشن پر غور کریں، جب ہمارا فائر وال VxLAN کے بارے میں کچھ نہیں جانتا ہے (اب یقیناً VxLAN سپورٹ والے آلات ظاہر ہو رہے ہیں۔ مثال کے طور پر، چیک پوائنٹ نے ورژن R81 میں اپنی حمایت کا اعلان کیا۔ آپ اس کے بارے میں پڑھ سکتے ہیں۔ یہاںتاہم، یہ سب جانچ کے مرحلے پر ہے اور آپریشن کے استحکام پر کوئی بھروسہ نہیں ہے)۔

بیرونی ڈیوائس کو جوڑتے وقت، ہمیں درج ذیل خاکہ ملتا ہے:

جیسا کہ آپ ڈایاگرام سے دیکھ سکتے ہیں، فائر وال کے ساتھ انٹرفیس پر ایک رکاوٹ ظاہر ہوتی ہے۔ مستقبل میں نیٹ ورک کی منصوبہ بندی کرتے وقت اور نیٹ ورک ٹریفک کو بہتر بناتے وقت اس کا خیال رکھنا چاہیے۔

تاہم، آئیے VRFs کے درمیان روٹنگ کے اصل مسئلے پر واپس آتے ہیں۔ فائر وال کو شامل کرنے کے نتیجے میں، ہم اس نتیجے پر پہنچے ہیں کہ فائر وال کو تمام VRFs کے بارے میں جاننا چاہیے۔ ایسا کرنے کے لیے، تمام VRFs کو بھی بارڈر لیفس پر کنفیگر کیا جانا چاہیے، اور فائر وال کو ہر VRF سے علیحدہ لنک کے ساتھ منسلک ہونا چاہیے۔

نتیجے کے طور پر، فائر وال کے ساتھ اسکیم:

یعنی، فائر وال پر آپ کو نیٹ ورک پر واقع ہر VRF کے لیے ایک انٹرفیس ترتیب دینے کی ضرورت ہے۔ عام طور پر، منطق پیچیدہ نہیں لگتی ہے اور صرف ایک چیز جو مجھے یہاں پسند نہیں ہے وہ ہے فائر وال پر انٹرفیس کی بڑی تعداد، لیکن یہاں آٹومیشن کے بارے میں سوچنے کا وقت آگیا ہے۔

ٹھیک. ہم نے فائر وال کو منسلک کیا اور اسے تمام VRFs میں شامل کیا۔ لیکن اب ہم ہر ایک لیف سے ٹریفک کو اس فائر وال سے گزرنے پر کیسے مجبور کر سکتے ہیں؟

فائر وال سے منسلک لیف پر، کوئی مسئلہ پیدا نہیں ہوگا، کیونکہ تمام راستے مقامی ہیں:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, static       ! маршрут по-умолчанию через Firewall

تاہم، ریموٹ لیفس کا کیا ہوگا؟ انہیں پہلے سے طے شدہ بیرونی راستے سے کیسے گزارا جائے؟

یہ ٹھیک ہے، EVPN روٹ-ٹائپ 5 کے ذریعے، جیسے VxLAN تانے بانے پر کسی دوسرے سابقے کی طرح۔ تاہم، یہ اتنا آسان نہیں ہے (اگر ہم سسکو کے بارے میں بات کر رہے ہیں، جیسا کہ میں نے دوسرے دکانداروں سے چیک نہیں کیا ہے)

پہلے سے طے شدہ راستے کی تشہیر لیف سے ہونی چاہیے جس سے فائر وال منسلک ہے۔ تاہم، راستے کو منتقل کرنے کے لیے، لیف کو خود اس کا علم ہونا چاہیے۔ اور یہاں ایک خاص مسئلہ پیدا ہوتا ہے (شاید صرف میرے لیے)، روٹ کو VRF میں مستحکم طور پر رجسٹر کیا جانا چاہیے جہاں آپ ایسے راستے کی تشہیر کرنا چاہتے ہیں:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

اگلا، BGP کنفیگریشن میں، اس راستے کو AF IPv4 میں سیٹ کریں:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0

تاہم، یہ سب نہیں ہے. اس طرح پہلے سے طے شدہ راستہ خاندان میں شامل نہیں ہوگا۔ l2vpn evpn. اس کے علاوہ، آپ کو دوبارہ تقسیم کو ترتیب دینے کی ضرورت ہے:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0
            redistribute static route-map COMMON_OUT

ہم اشارہ کرتے ہیں کہ کون سے سابقے دوبارہ تقسیم کے ذریعے BGP میں داخل ہوں گے۔

route-map COMMON_OUT permit 10
  match ip address prefix-list COMMON_OUT

ip prefix-list COMMON_OUT seq 10 permit 0.0.0.0/0

اب سابقہ 0.0.0.0/0 ای وی پی این روٹ ٹائپ 5 میں آتا ہے اور باقی لیف میں منتقل ہوتا ہے:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.255.1.5%default, [200/0], 5w6d, bgp-65001, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN
    ! 10.255.1.5 - Виртуальный адрес Leaf(так как Leaf выступают в качестве VPС пары), к которому подключен Firewall

BGP ٹیبل میں ہم 5 کے ذریعے طے شدہ روٹ کے ساتھ نتیجے میں آنے والے روٹ ٹائپ 10.255.1.5 کا بھی مشاہدہ کر سکتے ہیں:

* i[5]:[0]:[0]:[0]:[0.0.0.0]/224
                      10.255.1.5                        100          0 i
*>i                   10.255.1.5                        100          0 i

یہ ای وی پی این کے لیے وقف کردہ مضامین کی سیریز کا اختتام کرتا ہے۔ مستقبل میں، میں ملٹی کاسٹ کے ساتھ مل کر VxLAN کے آپریشن پر غور کرنے کی کوشش کروں گا، کیونکہ یہ طریقہ زیادہ قابل توسیع سمجھا جاتا ہے (اس وقت ایک متنازعہ بیان)

اگر آپ کے پاس ابھی بھی موضوع پر سوالات/مشورے ہیں، تو EVPN کی کسی بھی فعالیت پر غور کریں - لکھیں، ہم اس پر مزید غور کریں گے۔

ماخذ: www.habr.com