හෙලෝ, හබ්ර්. මම ලිපි මාලාවක් අවසන් කරමි, පාඨමාලාව දියත් කිරීම සඳහා කැපවී ඇත
මාලාවේ පෙර කොටස් පහත සබැඳිවලින් සොයාගත හැකිය:
චක්රයේ 1 කොටස - සේවාදායකයන් අතර L2 සම්බන්ධතාවය මාලාවේ 2 කොටස - VNIs අතර මාර්ගගත කිරීම මාලාවේ 2.5 කොටස - න්යායික අපගමනය
අද අපි දිගටම VxLAN රෙදි ඇතුලේ routing logic අධ්යයනය කරමු. කලින් කොටසේදී අපි බැලුවේ තනි VRF එකක් ඇතුලේ intra-fabric routing ගැන. කෙසේ වෙතත්, ජාලය තුළ සේවාදායක සේවා විශාල සංඛ්යාවක් තිබිය හැකි අතර, ඒවා අතර ප්රවේශය වෙන්කර හඳුනා ගැනීම සඳහා ඒවා සියල්ලම විවිධ VRF වෙත බෙදා හැරිය යුතුය. ජාල වෙන් කිරීමට අමතරව, මෙම සේවාවන් අතර ප්රවේශය සීමා කිරීමට ව්යාපාරයකට ෆයර්වෝලයක් සම්බන්ධ කිරීමට අවශ්ය විය හැකිය. ඔව්, මෙය හොඳම විසඳුම ලෙස හැඳින්විය නොහැකිය, නමුත් නූතන යථාර්ථයන් සඳහා "නවීන විසඳුම්" අවශ්ය වේ.
VRF අතර මාර්ගගත කිරීම සඳහා විකල්ප දෙකක් සලකා බලමු:
- VxLAN රෙදිවලින් ඉවත් නොවී මාර්ගගත කිරීම;
- බාහිර උපකරණ මත මාර්ගගත කිරීම.
VRF අතර routing logic එකෙන් පටන් ගනිමු. නිශ්චිත VRF සංඛ්යාවක් ඇත. VRF අතර ගමන් කිරීමට, ඔබ සියලු VRFs (හෝ මාර්ගගත කිරීම අවශ්ය වන කොටස් අතර) ගැන දැනගත හැකි උපාංගයක් ජාලය තුළ තෝරාගත යුතුය. එවැනි උපාංගයක්, උදාහරණයක් ලෙස, Leaf switches (හෝ සියල්ල එකවර) විය හැකිය. . මෙම ස්ථලකය මේ ආකාරයෙන් පෙනෙනු ඇත:
මෙම ස්ථලකයේ අවාසි මොනවාද?
ඒක හරි, සෑම ලීෆ් එකක්ම ජාලයේ ඇති සියලුම VRF (සහ ඒවායේ ඇති සියලුම තොරතුරු) ගැන දැනගත යුතුය, එය මතකය නැතිවීමට සහ ජාල භාරය වැඩි කිරීමට හේතු වේ. ඇත්ත වශයෙන්ම, බොහෝ විට සෑම කොළ ස්විචයක්ම ජාලයේ ඇති සියල්ල ගැන දැන ගැනීමට අවශ්ය නොවේ.
කෙසේ වෙතත්, මෙම ක්රමය වඩාත් විස්තරාත්මකව සලකා බලමු, මන්ද කුඩා ජාල සඳහා මෙම විකල්පය බෙහෙවින් සුදුසු ය (විශේෂිත ව්යාපාරික අවශ්යතා නොමැති නම්)
මෙම අවස්ථාවෙහිදී, 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
VRF අතර මාර්ගගත කිරීම සඳහා දෙවන විකල්පය සලකා බලමු - බාහිර උපකරණ හරහා, උදාහරණයක් ලෙස ෆයර්වෝල්.
බාහිර උපාංගයක් හරහා වැඩ කිරීමට විකල්ප කිහිපයක් තිබේ:
- උපාංගය VxLAN යනු කුමක්දැයි දන්නා අතර අපට එය රෙදි කොටසකට එකතු කළ හැකිය;
- උපාංගය VxLAN ගැන කිසිවක් දන්නේ නැත.
ඉහත පෙන්වා ඇති ආකාරයටම තර්කනය බොහෝ දුරට සමාන වන බැවින් අපි පළමු විකල්පය මත රැඳී නොසිටිමු - අපි සියලුම VRFs ෆයර්වෝල් වෙත ගෙන එන අතර එය මත VRF අතර මාර්ගගත කිරීම වින්යාස කරමු.
අපි දෙවන විකල්පය සලකා බලමු, අපගේ ෆයර්වෝලය VxLAN ගැන කිසිවක් නොදන්නා විට (දැන්, ඇත්ත වශයෙන්ම, VxLAN සහය ඇති උපකරණ දිස්වේ. උදාහරණයක් ලෙස, Checkpoint R81 අනුවාදයේ එහි සහය නිවේදනය කළේය. ඔබට ඒ ගැන කියවිය හැකිය.
බාහිර උපාංගයක් සම්බන්ධ කරන විට, අපට පහත රූප සටහන ලැබේ:
රූප සටහනෙන් ඔබට පෙනෙන පරිදි, ෆයර්වෝල් සමඟ අතුරු මුහුණතේ බාධකයක් දිස්වේ. ජාලය සැලසුම් කිරීමේදී සහ ජාල ගමනාගමනය ප්රශස්ත කිරීමේදී අනාගතයේදී මෙය සැලකිල්ලට ගත යුතුය.
කෙසේ වෙතත්, VRF අතර මාර්ගගත කිරීමේ මුල් ගැටලුව වෙත ආපසු යමු. ෆයර්වෝල් එක එකතු කිරීමේ ප්රතිඵලයක් ලෙස, අපි නිගමනය කරන්නේ ෆයර්වෝලය සියලුම වීආර්එෆ් ගැන දැන සිටිය යුතු බවයි. මෙය සිදු කිරීම සඳහා, සියලුම VRFs මායිම් පත්ර මත ද වින්යාසගත කළ යුතු අතර, ෆයර්වෝල් එක එක් එක් VRF වෙත වෙනම සබැඳියක් සමඟ සම්බන්ධ කළ යුතුය.
ප්රතිඵලයක් වශයෙන්, ෆයර්වෝල් සමඟ යෝජනා ක්රමය:
එනම්, ෆයර්වෝල් මත ඔබ ජාලයේ පිහිටා ඇති එක් එක් VRF සඳහා අතුරු මුහුණතක් වින්යාසගත කළ යුතුය. පොදුවේ ගත් කල, තර්කනය සංකීර්ණ නොවන අතර මෙහි මා කැමති නැති එකම දෙය වන්නේ ෆයර්වෝල් හි විශාල අතුරුමුහුණත් සංඛ්යාවයි, නමුත් මෙහිදී ස්වයංක්රීයකරණය ගැන සිතීමට කාලයයි.
හොඳයි. අපි ෆයර්වෝල් සම්බන්ධ කර එය සියලුම VRF වලට එකතු කළෙමු. නමුත් දැන් අපි එක් එක් පත්රයෙන් ගමනාගමනයට මෙම ෆයර්වෝල් හරහා යාමට බල කරන්නේ කෙසේද?
ෆයර්වෝල් වෙත සම්බන්ධ වූ පත්රයේ, සියලුම මාර්ග දේශීය බැවින් කිසිදු ගැටළුවක් මතු නොවනු ඇත:
0.0.0.0/0, ubest/mbest: 1/0
*via 10.254.13.55, [1/0], 6w5d, static ! маршрут по-умолчанию через Firewall
කෙසේ වෙතත්, දුරස්ථ කොළ ගැන කුමක් කිව හැකිද? ඒවා පෙරනිමි බාහිර මාර්ගය හරහා ගමන් කරන්නේ කෙසේද?
එය හරි, EVPN route-type 5 හරහා, VxLAN රෙදි මත වෙනත් ඕනෑම උපසර්ගයක් මෙන්. කෙසේ වෙතත්, මෙය එතරම් සරල නැත (අපි Cisco ගැන කතා කරන්නේ නම්, මම වෙනත් වෙළෙන්දන් සමඟ පරීක්ෂා කර නැත)
ෆයර්වෝල් සම්බන්ධ කර ඇති පත්රයේ සිට පෙරනිමි මාර්ගය ප්රචාරණය කළ යුතුය. කෙසේ වෙතත්, මාර්ගය සම්ප්රේෂණය කිරීම සඳහා, කොළ එයම දැන සිටිය යුතුය. මෙහිදී යම් ගැටළුවක් පැන නගී (සමහර විට මට පමණක්), ඔබට එවැනි මාර්ගයක් ප්රචාරය කිරීමට අවශ්ය වීආර්එෆ් හි මාර්ගය ස්ථිතිකව ලියාපදිංචි කළ යුතුය:
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
EVPN මාර්ග-වර්ගය 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
මෙය EVPN සඳහා කැප වූ ලිපි මාලාව අවසන් කරයි. මෙම ක්රමය වඩාත් පරිමාණය කළ හැකි යැයි සලකන බැවින් (මේ මොහොතේ මතභේදාත්මක ප්රකාශයක්) Multicast සමඟ එක්ව VxLAN හි ක්රියාකාරිත්වය සලකා බැලීමට අනාගතයේදී මම උත්සාහ කරමි.
ඔබට තවමත් මාතෘකාව පිළිබඳ ප්රශ්න/යෝජනා තිබේ නම්, EVPN හි කිසියම් ක්රියාකාරීත්වයක් සලකා බලන්න - ලියන්න, අපි එය තවදුරටත් සලකා බලමු.
මූලාශ්රය: www.habr.com