VxLAN தொழிற்சாலை. பகுதி 3

வணக்கம், ஹப்ர். நான் ஒரு தொடர் கட்டுரையை முடிக்கிறேன், பாடத்திட்டத்தின் துவக்கத்திற்காக அர்ப்பணிக்கப்பட்டது "நெட்வொர்க் பொறியாளர்" OTUS மூலம், துணிக்குள் ரூட்டிங் செய்ய VxLAN EVPN தொழில்நுட்பத்தைப் பயன்படுத்துதல் மற்றும் உள் சேவைகளுக்கு இடையே அணுகலைக் கட்டுப்படுத்த ஃபயர்வாலைப் பயன்படுத்துதல்

தொடரின் முந்தைய பகுதிகளை பின்வரும் இணைப்புகளில் காணலாம்:

• சுழற்சியின் 1 பகுதி - சேவையகங்களுக்கு இடையே L2 இணைப்பு
• தொடரின் பகுதி 2 - VNIகளுக்கு இடையே ரூட்டிங்
• தொடரின் பகுதி 2.5 - தத்துவார்த்த திசைதிருப்பல்

இன்று நாம் VxLAN துணிக்குள் உள்ள ரூட்டிங் லாஜிக்கை தொடர்ந்து படிப்போம். முந்தைய பகுதியில், ஒரு VRFக்குள் உள்ள இன்ட்ரா ஃபேப்ரிக் ரூட்டிங் பற்றி பார்த்தோம். இருப்பினும், நெட்வொர்க்கில் அதிக எண்ணிக்கையிலான கிளையன்ட் சேவைகள் இருக்கலாம், மேலும் அவற்றுக்கிடையேயான அணுகலை வேறுபடுத்துவதற்கு அவை அனைத்தும் வெவ்வேறு VRF களில் விநியோகிக்கப்பட வேண்டும். நெட்வொர்க் பிரிப்புக்கு கூடுதலாக, இந்த சேவைகளுக்கு இடையேயான அணுகலைக் கட்டுப்படுத்த ஒரு வணிகம் ஃபயர்வாலை இணைக்க வேண்டியிருக்கலாம். ஆம், இதை சிறந்த தீர்வு என்று அழைக்க முடியாது, ஆனால் நவீன யதார்த்தங்களுக்கு "நவீன தீர்வுகள்" தேவை.

VRF களுக்கு இடையில் ரூட்டிங் செய்வதற்கான இரண்டு விருப்பங்களைக் கருத்தில் கொள்வோம்:

1. VxLAN துணியை விட்டு வெளியேறாமல் ரூட்டிங்;
2. வெளிப்புற உபகரணங்களில் ரூட்டிங்.

VRFகளுக்கு இடையேயான ரூட்டிங் தர்க்கத்துடன் ஆரம்பிக்கலாம். குறிப்பிட்ட எண்ணிக்கையிலான VRFகள் உள்ளன. VRFகளுக்கு இடையே வழிசெலுத்த, நெட்வொர்க்கில் உள்ள ஒரு சாதனத்தை நீங்கள் தேர்ந்தெடுக்க வேண்டும், அது அனைத்து VRF களையும் (அல்லது ரூட்டிங் தேவைப்படும் பகுதிகளுக்கு இடையேயான பகுதிகள்) பற்றி அறியும். அத்தகைய சாதனம், எடுத்துக்காட்டாக, இலை சுவிட்சுகளில் ஒன்றாக இருக்கலாம் (அல்லது ஒரே நேரத்தில்) . இந்த இடவியல் இப்படி இருக்கும்:

இந்த இடவியலின் தீமைகள் என்ன?

அது சரி, ஒவ்வொரு இலையும் நெட்வொர்க்கில் உள்ள அனைத்து 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 களுக்கு இடையில் ரூட்டிங் செய்வதற்கான இரண்டாவது விருப்பத்தை கருத்தில் கொள்வோம் - வெளிப்புற உபகரணங்கள் மூலம், எடுத்துக்காட்டாக ஃபயர்வால்.

வெளிப்புற சாதனம் மூலம் வேலை செய்ய பல விருப்பங்கள் உள்ளன:

1. சாதனம் VxLAN என்றால் என்ன என்பதை அறிந்திருக்கிறது, அதை நாம் துணியின் ஒரு பகுதியில் சேர்க்கலாம்;
2. சாதனத்திற்கு VxLAN பற்றி எதுவும் தெரியாது.

தர்க்கம் மேலே காட்டப்பட்டுள்ளதைப் போலவே இருக்கும் என்பதால், முதல் விருப்பத்தில் நாங்கள் வசிக்க மாட்டோம் - நாங்கள் அனைத்து VRF களையும் ஃபயர்வாலுக்குக் கொண்டு வந்து அதில் VRF களுக்கு இடையில் ரூட்டிங் கட்டமைக்கிறோம்.

இரண்டாவது விருப்பத்தை பரிசீலிப்போம், நமது ஃபயர்வாலுக்கு VxLAN பற்றி எதுவும் தெரியாது (இப்போது, ​​நிச்சயமாக, VxLAN ஆதரவுடன் கூடிய சாதனம் தோன்றுகிறது. எடுத்துக்காட்டாக, செக்பாயிண்ட் பதிப்பு R81 இல் அதன் ஆதரவை அறிவித்தது. அதைப் பற்றி நீங்கள் படிக்கலாம். இங்கேஇருப்பினும், இது அனைத்தும் சோதனை கட்டத்தில் உள்ளது மற்றும் செயல்பாட்டின் நிலைத்தன்மையில் நம்பிக்கை இல்லை).

வெளிப்புற சாதனத்தை இணைக்கும்போது, ​​​​பின்வரும் வரைபடத்தைப் பெறுகிறோம்:

வரைபடத்திலிருந்து நீங்கள் பார்க்க முடியும் என, ஃபயர்வாலுடன் இடைமுகத்தில் ஒரு இடையூறு தோன்றும். நெட்வொர்க்கைத் திட்டமிடும்போது மற்றும் நெட்வொர்க் போக்குவரத்தை மேம்படுத்தும்போது இது எதிர்காலத்தில் கணக்கில் எடுத்துக்கொள்ளப்பட வேண்டும்.

இருப்பினும், VRFகளுக்கு இடையே ரூட்டிங் செய்வதில் உள்ள அசல் பிரச்சனைக்கு வருவோம். ஃபயர்வாலைச் சேர்ப்பதன் விளைவாக, ஃபயர்வால் அனைத்து விஆர்எஃப்களைப் பற்றியும் அறிந்திருக்க வேண்டும் என்ற முடிவுக்கு வருகிறோம். இதைச் செய்ய, அனைத்து VRFகளும் எல்லை இலைகளில் கட்டமைக்கப்பட வேண்டும், மேலும் ஃபயர்வால் ஒவ்வொரு VRF உடன் தனித்தனி இணைப்புடன் இணைக்கப்பட வேண்டும்.

இதன் விளைவாக, ஃபயர்வால் கொண்ட திட்டம்:

அதாவது, ஃபயர்வாலில் நீங்கள் நெட்வொர்க்கில் அமைந்துள்ள ஒவ்வொரு VRF க்கும் ஒரு இடைமுகத்தை உள்ளமைக்க வேண்டும். பொதுவாக, தர்க்கம் சிக்கலானதாகத் தெரியவில்லை, இங்கே நான் விரும்பாத ஒரே விஷயம் ஃபயர்வாலில் உள்ள பெரிய எண்ணிக்கையிலான இடைமுகங்கள், ஆனால் இங்கே ஆட்டோமேஷனைப் பற்றி சிந்திக்க வேண்டிய நேரம் இது.

நன்றாக. ஃபயர்வாலை இணைத்து அனைத்து VRFகளிலும் சேர்த்துள்ளோம். ஆனால் ஒவ்வொரு இலையிலிருந்தும் போக்குவரத்தை இந்த ஃபயர்வால் வழியாகச் செல்லும்படி இப்போது எப்படி கட்டாயப்படுத்துவது?

ஃபயர்வாலுடன் இணைக்கப்பட்ட இலையில், எல்லா வழிகளும் உள்ளூர் என்பதால், எந்த பிரச்சனையும் ஏற்படாது:

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 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