OTV சேர்ப்பதற்கு முன், உங்களுக்குத் தேவையான Ethernet ஒப்பந்தத்தை எழுதுங்கள்

ஒரு workload இரண்டாவது தரவு மையத்திற்கு நகர்கிறது, முதல் மையத்திலிருந்து நன்றாகப் பதிலளித்த ஒரு சேவையில் நேர வரம்பு மீறத் தொடங்குகிறது. யாரோ OTV பரிந்துரைக்கிறார், ஏனெனில் ஏற்கனவே உள்ள Layer 2 VPN «broadcast செய்யாது». அந்த முடிவு பொதுவாக அவசரமானது. சேவை வகை மற்றும் நீங்கள் வாங்கிய குறிப்பிட்ட ஒப்பந்தம் இரண்டு வேறுபட்ட கேள்விகள், நேர வரம்பு மீறல் இன்னும் எதற்கும் காரணமாகக் கூறப்படவில்லை.

ஒப்பீட்டைத் தொடங்கும் அறிகுறி

தயாரிப்புகளை ஒப்பிடுவதற்கு முன் பயன்பாட்டிற்கு உண்மையில் என்ன தேவை என்பதை எழுதுங்கள். தளங்களின் எண்ணிக்கை, VLAN வரம்பு, முகவரி கற்றல், flooding சகிப்புத்தன்மை மற்றும் தோல்வி நடத்தை தேவையை விவரிக்கின்றன. «Layer 2» மற்றும் «OTV» கட்டமைப்புகளை விவரிக்கின்றன, அவற்றில் எதுவும் தனியாக ஒரு தேவை அல்ல. ஒரு பக்கத்தில் ஐந்து பண்புகள் எந்த விற்பனையாளர் ஒப்பீட்டையும் விட நீண்ட காலம் நிலைக்கும்.

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

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

லேபிள் உங்களிடம் சொல்லாதது

Layer 2 VPN ஒரு வகை, தயாரிப்பு அல்ல. புள்ளி-க்கு-புள்ளி VPWS மற்றும் multipoint VPLS வேறு விதமாக அனுப்புகின்றன, மேலும் இந்த வகையில் கட்டுப்பாட்டு அடுக்கு கற்றல் மற்றும் சுழற்சி நிர்வாகம் கொண்ட சேவைகளும் எளியவையும் அடங்கும். ஒவ்வொரு Layer 2 VPN ஆரும் சரியாக இரண்டு தளங்களை இணைத்து எல்லாவற்றையும் flood செய்கிறது என்று கருதுவதே தவறான ஒப்பீட்டை உருவாக்கும் வழி. ஒப்பந்தத்தில் உள்ள பெயர் அதன் பின்னால் உள்ள அனுப்புதல் அட்டவணையைப் பற்றி எதுவும் சொல்லவில்லை.

தற்போதைய சேவை எந்த அனுப்புதல் மாதிரியைச் செயல்படுத்துகிறது என்றும், பயன்பாட்டிற்கு எது தேவை என்றும் கேளுங்கள். hub-and-spoke தேவையும் full-mesh தேவையும் இரண்டும் Layer 2 என்று விவரிக்கப்பட்டாலும் வெவ்வேறு வடிவமைப்புகளைத் தருகின்றன.

OTV தன் எல்லையை எங்கு வரைகிறது

OTV IP போக்குவரத்தின் மேல் இயங்குகிறது, கட்டுப்பாட்டு அடுக்கில் MAC அணுகல் மற்றும் வரையறுக்கப்பட்ட edge பாத்திரங்களுடன். உள்ளூர் spanning-tree தகவல் உள்ளூரிலேயே இருக்கும், போக்குவரத்து முழுவதும் ஒரு கட்டுப்படுத்தப்படாத டொமைனாக விரிவாக்கப்படுவதில்லை. இது எளிய பாலம் விரிவாக்கத்திலிருந்து உண்மையான வேறுபாடு, அதனால்தான் மக்கள் இதை நோக்கிச் செல்கிறார்கள்.

எல்லை பயனின் அளவுக்கே முக்கியம். அறியாத unicast, broadcast மற்றும் multicast கையாளுதல் தளம் மற்றும் அதன் உள்ளமைவைப் பொறுத்தது, மேலும் edge இணை ஆதரிக்கப்படும் multihoming முறையின் மூலம் ஒத்துழைக்க வேண்டும். ஒரே VLAN ஐ அனுப்பும் இரண்டு சுயாதீன சாதனங்கள் ஒரே வடிவமைப்பு அல்ல, அவை வேறு தோல்வி முறையை உருவாக்குகின்றன.

Flooding குறைகிறது, நீக்கப்படுவதில்லை

சில தேவையற்ற flooding ஐ அடக்குவது, எந்த broadcast அல்லது multicast சட்டகமும் ஒருபோதும் விரிவாக்கத்தைக் கடக்காது என்பதற்கான உத்தரவாதத்திற்குச் சமமல்ல. ஒரு தளத்தில் தொடங்கும் புயல் இன்னும் போக்குவரத்தை உண்ணும், மேலும் ஒரு போக்குவரத்து வகுப்பை வடிகட்டும் தள அம்சம் மற்றவற்றை வடிகட்டாது. எந்த overlay பற்றிய பெரும்பாலான ஏமாற்றம் இந்த வேறுபாட்டிலிருந்தே வருகிறது.

எனவே கேள்வி OTV broadcast புயல்களை நிறுத்துகிறதா என்பது அல்ல. எந்த போக்குவரத்து வகுப்புகள் கடக்கின்றன, எந்த நிபந்தனைகளில், கடக்கும்போது வேகத்தை எது கட்டுப்படுத்துகிறது என்பதே.

அங்கு இருக்கும்போது underlay ஐ உறுதிப்படுத்துங்கள்: ஆதரிக்கப்படும் விநியோகம், பொதி அளவு, வழிநடத்தல் மற்றும் தேர்ந்தெடுத்த வெளியீட்டிற்குத் தேவையான அண்டை நிலை. இவை எதுவும் overlay உடன் இலவசமாக வருவதில்லை, 1500 பைட் சட்டகம் பொருந்தும் சுரங்கப்பாதை தானாகவே உங்கள் குறியிடப்பட்ட சட்டகங்கள் பொருந்தும் சுரங்கப்பாதை அல்ல.

எழுத்துப்பூர்வமாகக் கோர வேண்டிய ஒப்பந்தம்

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

தற்போதைய சேவை வெளிப்படையாகப் பூர்த்தி செய்ய முடியாத தேவைக்கு மட்டுமே மாற்றத்தைத் தேர்ந்தெடுங்கள். VLAN ஐ மேலும் விரிவாக்குவது பயன்பாட்டின் மற்றும் Ethernet இன் சார்புகளையும் அதனுடன் விரிவாக்குகிறது; புதிய overlay பெயர் அவற்றை நீக்காது.

RFC 4664 கட்டமைப்பு சேவை வகைகளையும் அவற்றின் அனுப்புதல் மாதிரிகளையும் விளக்குகிறது, அதுவே சரியான கேள்வியைக் கேட்கத் தேவையான சொற்களஞ்சியம். ஆறு பதில்களையும் தோல்வியடைந்த சோதனையையும் ஒரே கூட்டத்திற்குக் கொண்டு வாருங்கள், முடிவு இனி லேபிள்களைப் பற்றியதாக இருக்காது.