DSCP таңбалауы немесе провайдердің QoS уәдесі? Екеуі де шарт емес

Бірдеңе таңбаланады, кезек конфигурацияланады, содан кейін біреу дизайн шын мәнінде қандай сапаны кепілдейтінін сұрайды. Шынайы жауап — сіз шекарада кездесетін шарттың екі жартысын сипаттадыңыз. Провайдер қабылдайтын класты және ол қолданатын өңдеуді атай алмайынша, жергілікті конфигурация уәде емес, ниет. Екі жарты да маңызды және бірі екіншісінен туындамайды.

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

Дұрыс таңбалау қайда үнсіз өлуі мүмкін

Әр жұмыс жүктемесі үшін жергілікті сәйкестік шартын, туннель ішінде болатын кез келген таңбалауды, провайдер қабылдайтын мәнді және сол мән таңдайтын қызмет класын жазудан бастаңыз. Төрт баған, ал ақаулар әдетте екінші мен үшіншінің арасында тұрады.

Ішкіден сыртқы тақырыпқа таңбалау мінез-құлқы — классикалық мәселе. Шифрланған немесе туннельді жолдағы пакет сіздің жіктеушіңіз көретін ішкі тақырыпты және провайдер жабдығы көретін сыртқы тақырыпты алып жүреді, ал бірін екіншісіне көшіру конфигурация шешімі, автоматты қасиет емес. Тек ішкі тақырыпты таңбалаңыз, сонда провайдер сыртқысын жіктейді, әдетте әдепкі ретінде, сондықтан дұрыс таңбаланған ағын сіз жақта бірде-бір қате конфигурацияланған жолсыз қате класқа келуі мүмкін.

Жергілікті аталған класс та бос қалуы мүмкін, өйткені оның сәйкестік шарты нақты пакеттерде ешқашан іске қосылмайды. Порттар жылжиды, қосымшалар бірнеше ағынды пайдаланады, ал жеткізуші екі шығарылым бұрын пайдалануды тоқтатқан белгілі портқа сәйкестік нөлдік санауыштары бар кезек пен жұмыс істеп тұрған конфигурацияда мінсіз көрінетін саясатты тудырады.

Таңбалауға қайда сенетінін анық шешіңіз. Туннельді бөлісетіннің бәрін көтеру қоңыраулармен бірге жаппай тасымалдауды да көтереді, ал таңбалауыңызды тексерусіз қабылдайтын провайдер сізге өзіңізге зиян келтірудің жолын ұсынады. Егер шарт шлюзге тапсыру кезінде қайта таңбалауға рұқсат берсе, мұны жазбаша айтыңыз, өйткені екі топтың болжамдары әдетте дәл осы нүктеде алшақтайды.

Жоспарлаушы шын мәнінде нені бөледі

Жергілікті саясаттың өз семантикасы бар, ал ең көп түсінбеушілік туғызатыны — “remaining” сөзі. IOS XE жоспарлау нұсқаулығында сипатталған платформаларда bandwidth remaining percent артық салмақты белгілейді, әр класс алдыңғы кластан қалғанның үлесін алатын реттіліктегі қадам емес. Бөлінбеген пайыздар файлдағы соңғы класс үшін сақталудың орнына қолайлы конфигурацияланбаған кезектерге таратылады.

Бұл айырмашылық маңызды, өйткені реттік ойлау моделі санауыштарға ешқашан сәйкес келмейтін болжамдар береді. Инженерлер нәтижені өзгерту үшін кластарды қайта реттейді, айырмашылық көрмейді және платформа бұзылған деп қорытындылайды, ал конфигурация олардың болжағанын ешқашан білдірген емес.

Ата-аналық қалыптастырғыш — тағы бір жиі кездесетін тосынсый. Бақыланатын кезекті пайдалануға болатын қызмет жылдамдығына дейін қалыптастыру көбіне әдейі жасалады, өйткені ол кептелу нүктесін сіз басқаратын құрылғыға жылжытады, сіз басқармайтын жоғары ағындағы кезекке емес. Қалыптастыру кідіріс қосады деп қалыптастырғышты алып тастау шығынды жоюдың орнына орын ауыстыруы мүмкін, ал үстеме шығынды есепке алу немесе провайдердің полисері тиімді жылдамдықты интерфейс меңзегеннен төмен ете алады.

Санауыштар қай жартының құлағанын айтады

Әсер еткен бағытта төрт санды салыстырыңыз: не ұсынылды, класс неге сәйкестенді, не кезекке қойылды немесе тасталды және қызмет шын мәнінде нені жеткізді. Жұмыс жүктемесінің сипаттамасын және саясат нұсқасын бақылаудың қасында ұстаңыз, өйткені оларсыз санауыштардың скриншотын қайта жаңғырту мүмкін емес.

Тармақтар — әр түрлі иелердің әр түрлі мәселелері. Ештеңеге сәйкеспейтін жергілікті класс — сіз жақтағы жіктеу қатесі. Сәйкесіп, кезекке тұрып, тастайтын класс, ал провайдер таза жеткізуді хабарлағанда, сіздің жеке жоспарлаушыңызды немесе қалыптастырғышыңызды меңзейді. Жергілікті дұрыс көрінетін, бірақ шығын тапсырудан әрірек пайда болатын класс тасымалдаушының бейнеленуіне және шарттағы өлшенген шекараға меңзейді. Үшеуінің ешқайсысы басқаларын өңдеумен түзелмейді, сондықтан сандарды бірге жинау керек.

RFC 2475 жіктеу мен шарттандыруды әкімшілік домендер ішінде жасалатын жұмыс ретінде қарастырады, сондықтан таңбалау кезектерді ұшынан ұшына резервтей алмайды. IOS XE жоспарлау нұсқаулығы жоғарыда сипатталған артық салмақ мінез-құлқының анықтамасы, және есептелген жылдамдықты модельдер арасында жылжыту алдында оның платформалық салыстыруларын оқыған жөн.

Шартты бір жерде жазыңыз

Жергілікті сәйкестікті, сенім шекарасын, провайдер класын және өлшенген қызмет деңгейін екі тарап қол қоятын бір құжатқа салыңыз. Сонда пайыз өзгерісінің контексті, ал сапа шағымының иесі болады.

Жергілікті пайызды өзгерту басқа кезектің кепілдігін жөндей алмайды, және провайдер сақтамайтын бейнелеуден ешбір таңбалау схемасы аман қалмайды. Екі жартыны салыстырыңыз, шекараны атаңыз, содан кейін ғана санды келтіріңіз.