DSCP గుర్తింపు లేదా ప్రదాత QoS వాగ్దానమా? రెండూ ఒప్పందం కాదు

ఏదో గుర్తించబడుతుంది, ఒక క్యూ కాన్ఫిగర్ చేయబడుతుంది, ఆపై డిజైన్ నిజంగా ఏ నాణ్యతకు హామీ ఇస్తుందని ఎవరో అడుగుతారు. నిజాయితీగా సమాధానం ఏమిటంటే మీరు సరిహద్దులో కలిసే ఒప్పందం యొక్క రెండు భాగాలను వివరించారు. ప్రదాత అంగీకరించే తరగతిని మరియు అతను వర్తించే చికిత్సను పేర్కొనే వరకు, స్థానిక కాన్ఫిగరేషన్ ఒక ఉద్దేశం, వాగ్దానం కాదు. రెండు భాగాలు ముఖ్యమైనవి, ఒకదాని నుండి మరొకటి ఊహించలేము.

local match → queue and marking → provider classifier
  → provider treatment → destination

సరైన గుర్తింపు ఎక్కడ నిశ్శబ్దంగా చనిపోతుంది

ప్రతి పనిభారానికి స్థానిక సరిపోలిక షరతు, సొరంగం లోపల జరిగే ఏ గుర్తింపు అయినా, ప్రదాత అంగీకరించే విలువ మరియు ఆ విలువ ఎంచుకునే సేవా తరగతిని రాయడం ద్వారా ప్రారంభించండి. నాలుగు నిలువు వరుసలు, మరియు వైఫల్యాలు సాధారణంగా రెండవ మరియు మూడవ మధ్య నివసిస్తాయి.

లోపలి నుండి బయటి శీర్షికకు గుర్తింపు ప్రవర్తన సాంప్రదాయ సమస్య. ఎన్‌క్రిప్ట్ చేయబడిన లేదా సొరంగ మార్గంలోని ప్యాకెట్ మీ వర్గీకర్త చూడగలిగే లోపలి శీర్షికను మరియు ప్రదాత పరికరాలు చూడగలిగే బయటి శీర్షికను కలిగి ఉంటుంది, ఒకదాన్ని మరొకదానిలోకి కాపీ చేయడం కాన్ఫిగరేషన్ నిర్ణయం, స్వయంచాలక లక్షణం కాదు. లోపలి శీర్షికను మాత్రమే గుర్తించండి మరియు ప్రదాత బయటి దాన్ని వర్గీకరిస్తారు, సాధారణంగా డిఫాల్ట్‌గా, అందుకే సరిగ్గా గుర్తించిన ప్రవాహం మీ వైపు ఒక్క తప్పు కాన్ఫిగర్ చేసిన పంక్తి లేకుండానే తప్పు తరగతికి చేరుకోవచ్చు.

స్థానికంగా పేరు పెట్టిన తరగతి కూడా ఖాళీగా ఉండవచ్చు, ఎందుకంటే దాని సరిపోలిక షరతు నిజమైన ప్యాకెట్లపై ఎప్పుడూ సక్రియం కాదు. పోర్టులు కదులుతాయి, అనువర్తనాలు అనేక ప్రవాహాలను ఉపయోగిస్తాయి, విక్రేత రెండు విడుదలల క్రితం ఉపయోగించడం ఆపిన ప్రసిద్ధ పోర్ట్‌పై సరిపోలిక సున్నా కౌంటర్లతో క్యూ మరియు నడుస్తున్న కాన్ఫిగరేషన్‌లో పరిపూర్ణంగా కనిపించే విధానాన్ని ఉత్పత్తి చేస్తుంది.

గుర్తింపులు ఎక్కడ నమ్మబడతాయో స్పష్టంగా నిర్ణయించండి. సొరంగాన్ని పంచుకునే ప్రతిదీ పెంచడం కాల్‌లతో పాటు బల్క్ బదిలీలను కూడా పెంచుతుంది, మరియు ధృవీకరణ లేకుండా మీ గుర్తింపును అంగీకరించే ప్రదాత మీకు మీరే హాని చేసుకోవడానికి మార్గాన్ని అందిస్తారు. ఒప్పందం గేట్‌వేను అప్పగింతలో తిరిగి గుర్తించడానికి అనుమతిస్తే, దాన్ని లిఖితపూర్వకంగా చెప్పండి, ఎందుకంటే రెండు జట్ల ఊహలు సాధారణంగా అక్కడే భిన్నమవుతాయి.

షెడ్యూలర్ నిజంగా ఏమి విభజిస్తుంది

స్థానిక విధానానికి దాని స్వంత అర్థశాస్త్రం ఉంది, మరియు ఎక్కువ అపార్థాన్ని “remaining” అనే పదం సృష్టిస్తుంది. IOS XE షెడ్యూలింగ్ గైడ్ వివరించే ప్లాట్‌ఫారమ్‌లలో bandwidth remaining percent అదనపు బరువును సెట్ చేస్తుంది, ప్రతి తరగతి మునుపటి తరగతి వదిలిన దాని నుండి వాటా తీసుకునే క్రమంలో ఒక అడుగు కాదు. కేటాయించని శాతాలు ఫైల్‌లోని చివరి తరగతికి రిజర్వ్ చేయబడకుండా అర్హత గల కాన్ఫిగర్ చేయని క్యూలలో పంపిణీ చేయబడతాయి.

ఆ భేదం ముఖ్యం ఎందుకంటే క్రమ మానసిక నమూనా కౌంటర్లతో ఎప్పుడూ సరిపోలని అంచనాలను ఇస్తుంది. ఇంజనీర్లు ఫలితాన్ని మార్చడానికి తరగతులను పునర్వ్యవస్థీకరిస్తారు, భేదం కనిపించదు, ప్లాట్‌ఫారమ్ పాడైందని నిర్ధారిస్తారు, కానీ కాన్ఫిగరేషన్ వారు ఊహించినది ఎప్పుడూ అర్థం చేసుకోలేదు.

మాతృ ఆకారకుడు మరొక సాధారణ ఆశ్చర్యం. నియంత్రిత క్యూను ఉపయోగించగల సేవా రేటుకు ఆకారం చేయడం తరచుగా ఉద్దేశపూర్వకం, ఎందుకంటే అది రద్దీ బిందువును మీరు నిర్వహించే పరికరానికి తరలిస్తుంది, మీరు నిర్వహించని పై ప్రవాహ క్యూకు కాదు. ఆకారం ఆలస్యాన్ని జోడిస్తుందని ఆకారకుడిని తీసివేయడం నష్టాన్ని తీసివేయడం బదులు స్థానభ్రంశం చేయవచ్చు, మరియు ఓవర్‌హెడ్ అకౌంటింగ్ లేదా ప్రదాత పోలీసర్ ప్రభావవంత రేటును ఇంటర్‌ఫేస్ సూచించిన దానికంటే తక్కువగా చేయగలవు.

కౌంటర్లు ఏ భాగం విఫలమైందో చెబుతాయి

ప్రభావిత దిశలో నాలుగు సంఖ్యలను పోల్చండి: ఏమి అందించబడింది, తరగతి ఏది సరిపోలింది, ఏది క్యూలోకి వెళ్ళింది లేదా విసిరివేయబడింది, మరియు సేవ నిజంగా ఏమి పంపిణీ చేసింది. పనిభారం వివరణ మరియు విధానం సంస్కరణను పరిశీలన పక్కన ఉంచండి, ఎందుకంటే అవి లేకుండా కౌంటర్ల స్క్రీన్‌షాట్ పునరుత్పత్తి చేయలేము.

శాఖలు వేర్వేరు యజమానుల వేర్వేరు సమస్యలు. దేనితోనూ సరిపోలని స్థానిక తరగతి మీ వైపు వర్గీకరణ బగ్. సరిపోలి, క్యూలో చేరి, విసిరివేసే తరగతి, ప్రదాత శుభ్రమైన పంపిణీని నివేదిస్తున్నప్పుడు, మీ స్వంత షెడ్యూలర్ లేదా ఆకారకుడిని సూచిస్తుంది. స్థానికంగా సరిగ్గా కనిపించే తరగతి, నష్టం అప్పగింత దాటి కనిపించినప్పుడు, క్యారియర్ మ్యాపింగ్ మరియు ఒప్పందంలో కొలిచిన సరిహద్దును సూచిస్తుంది. మూడింటిలో ఏదీ మిగతావాటిని సవరించడం ద్వారా సరిచేయబడదు, అందుకే సంఖ్యలు కలిసి సేకరించాలి.

RFC 2475 వర్గీకరణ మరియు కండిషనింగ్‌ను పరిపాలనా డొమైన్‌ల లోపల చేసే పనిగా రూపొందిస్తుంది, అందుకే గుర్తింపు క్యూలను చివరి నుండి చివరి వరకు రిజర్వ్ చేయలేదు. IOS XE షెడ్యూలింగ్ గైడ్ పైన వివరించిన అదనపు బరువు ప్రవర్తనకు సూచన, మరియు మోడళ్ల మధ్య లెక్కించిన రేటును తరలించే ముందు దాని ప్లాట్‌ఫారమ్ పోలికలను చదవడం విలువైనది.

ఒప్పందాన్ని ఒకే చోట రాయండి

స్థానిక సరిపోలిక, విశ్వాస సరిహద్దు, ప్రదాత తరగతి మరియు కొలిచిన సేవా స్థాయిని రెండు పక్షాలు సంతకం చేసే ఒకే పత్రంలో ఉంచండి. అప్పుడు శాతం మార్పుకు సందర్భం ఉంటుంది, నాణ్యత ఫిర్యాదుకు యజమాని ఉంటారు.

స్థానిక శాతాన్ని మార్చడం మరొక క్యూ హామీని సరిచేయలేదు, ప్రదాత గౌరవించని మ్యాపింగ్ నుండి ఏ గుర్తింపు పథకం తప్పించుకోదు. రెండు భాగాలను పోల్చండి, సరిహద్దుకు పేరు పెట్టండి, ఆపై మాత్రమే సంఖ్యను ఉటంకించండి.