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

லேபிளை அகற்றிய பிறகு வெளியேறும் திசைவி பாக்கெட்டுடன் என்ன செய்ய வேண்டும் என்பதையும் தேர்வு சார்ந்துள்ளது. முடிவை லேபிள் கணிதம் அல்ல, அந்த செயல்பாட்டு வேறுபாடே வழிநடத்த வேண்டும்.

ஒவ்வொரு ஒதுக்கீடும் உண்மையில் எதைச் சேமிக்கிறது

முன்னொட்டுக்கு ஒரு ஒதுக்கீடு லேபிளில் அனுப்புதல் தகவலைக் கொண்டு செல்கிறது. வெளியேறும் திசைவி இலக்குத் தேடல் இல்லாமல் பாக்கெட்டை நேரடியாக சரியான அடுத்தடுத்துக்கு அனுப்ப முடியும், அதனால்தான் இது பெரிய VRF வழித்தடத் தொகுப்புகளுக்கு நன்கு அளவிடப்படுகிறது, அதனால்தான் ஒவ்வொரு VRF இலும் விளம்பரப்படுத்தப்பட்ட ஒவ்வொரு முன்னொட்டுக்கும் ஒரு லேபிளைச் செலவிடுகிறது. VRF க்கு ஒரு ஒதுக்கீடு, எடுத்துக்காட்டாக Junos vrf-table-label, ஒவ்வொரு ரூட்டிங் நிகழ்வுக்கும் ஒரு லேபிளை விளம்பரப்படுத்தி, VRF அட்டவணையைத் தேர்ந்தெடுக்க அந்த லேபிளைப் பயன்படுத்துகிறது; பின்னர் திசைவி அட்டவணைக்குள் IP தேடலைச் செய்கிறது.

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

லேபிள் பேரேடு சிறியது

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

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

வழித்தட ஊட்டங்கள் லேபிள்களுக்கு முன் நினைவகத்தைச் செலவிடுகின்றன

பெறப்பட்ட ஒவ்வொரு பாதையும் கட்டுப்பாட்டுத் தள நினைவகம், புதுப்பிப்புச் செயலாக்கம் மற்றும் ஒருங்கிணைப்பு நேரத்தைச் செலவிடுகிறது, VRF ஒரு லேபிளைப் பயன்படுத்தினாலும் பத்தாயிரத்தைப் பயன்படுத்தினாலும். VRF க்குள் முழு இணைய ஊட்டம் BGP பாதைகள், RIB, FIB பதிவுகள் மற்றும் அவற்றின் பின்னால் உள்ள குழப்பம் காரணமாக விலை உயர்ந்தது, அட்டவணைக்கு முன்னால் உள்ள லேபிள் காரணமாக அல்ல. அதே ஊட்டம் அந்தக் குத்தகைதாரருக்குள் வழித்தடக் கசிவு அல்லது கொள்கைத் தவறின் தாக்க ஆரத்தையும் அதிகரிக்கிறது.

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

VRF க்கு லேபிளிடல் எப்போது சரியான இயல்புநிலை

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

தளத்தின் ஆவணங்கள் இந்த அம்சத்தை குறிப்பிட்ட வன்பொருள் அல்லது வெளியீட்டுக் கட்டுப்பாடுகளுடன் இணைக்கும்போது, அல்லது வடிவமைப்பு வெளியேற்றத்தில் முன்னொட்டுக்கு அனுப்புதல் முடிவுகளைச் சார்ந்திருக்கும்போது இது தவறான இயல்புநிலை. நடத்தையை ஊகிப்பதற்கு முன் தளத்தின் சொந்த statement குறிப்பைப் படியுங்கள்; Junos கட்டளை ஆவணப்படுத்தப்பட்டுள்ளது, ஆனால் அதைச் சுற்றியுள்ள வன்பொருள் மற்றும் வெளியீட்டு வரம்புகளே பயன்பாட்டை உண்மையில் தீர்மானிக்கின்றன.

நீங்கள் பாதுகாக்கக்கூடிய பட்ஜெட்

திறன் வழக்கை ஐந்து தனித்தனி எண்களாக உருவாக்குங்கள்: பெறப்பட்ட பாதைகள், தேர்ந்தெடுக்கப்பட்ட வழித்தடங்கள், நிறுவப்பட்ட அனுப்புதல் பதிவுகள், சேவை லேபிள்கள் மற்றும் போக்குவரத்து லேபிள்கள். next-hop மற்றும் அடுத்தடுத்து நிலை, குத்தகைதாரர்களின் எண்ணிக்கை மற்றும் மிகைப்படுத்தல் மாதிரியைச் சேர்க்கவும். ஒரு VRF இன் சீரான பாதையின் ஸ்னாப்ஷாட் அளவு எண் அல்ல, லேபிள் இடத்தின் பெயரளவு அளவு கிடைக்கும் வன்பொருள் அட்டவணை அல்ல.

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

வெளியேற்றச் செயல் மற்றும் தள வரம்புகளிலிருந்து ஒதுக்கீட்டைத் தேர்ந்தெடுத்து, பின்னர் வழித்தட ஊட்டத்தை வெளிப்படையான சேவை முடிவாக்குங்கள். லேபிள் வடிவமைப்பின் தெரியும் பகுதி; வழித்தடங்கள் ஒவ்வொரு நாளும் செலுத்த வேண்டிய பகுதி.

தொடர்புடைய கட்டுரைகள்