ప్రతి టన్నెల్కు QoS మీ hub యొక్క మొత్తం అప్లింక్ను పరిమితం చేయదు
ఒక్కొక్కటి 5 Mbit ఉన్న ఐదు స్పోక్లు 10 Mbit అప్లింక్ కాదు, టన్నెల్కు సంబంధించిన విధానం ఆ భేదాన్ని ఎప్పుడూ చూడలేదు. పంచుకున్న అడ్డంకిని విడిగా బడ్జెట్ చేయండి.
ఈ నమ్మకం గణితంలా వినిపిస్తుంది: ఐదు స్పోక్లు, ఒక్కొక్కటి 5 Mbit/s కు ఆకారం ఇవ్వబడ్డాయి, కాబట్టి hub గరిష్ఠంగా 25 Mbit/s మోస్తుంది. మొదటి సగం నిజం, ముగింపు కాదు. టన్నెల్కు సంబంధించిన విధానం ప్రతి టన్నెల్కు ఒకసారి వర్తిస్తుంది, ప్రతి hub కు ఒకసారి కాదు, మరియు ఐదు టన్నెల్లు దాటే పంచుకున్న అప్లింక్ ఆ లెక్కలో ఎప్పుడూ కనిపించదు. అప్లింక్పై రద్దీ అలాగే కొనసాగుతుంది.
ఈ నమ్మకం ఎక్కడి నుంచి వస్తుంది
గందరగోళం అర్థమవుతుంది, ఎందుకంటే NHRP గుంపు సమాచారం ఒక విధాన నిర్వచనాన్ని మొత్తం స్పోక్ సమితికి వర్తింపజేయడానికి అనుమతిస్తుంది. అది కాన్ఫిగరేషన్ ఫైల్లో పంచుకున్న బడ్జెట్లా చదవబడుతుంది. వాస్తవానికి దాని అర్థం ప్రతి స్పోక్ ఆ నిర్వచనం యొక్క తన స్వంత నకలును పొందుతుంది.
అందువల్ల ప్రతి స్పోక్కు 5 Mbit/s అనేది టన్నెల్కు ఒక పైపరిమితి, టన్నెల్లు ఎన్ని ఉన్నాయో అన్ని పరిమితులు ఉన్నాయి.
ఒక విధాన నకలు ఏమి నియంత్రిస్తుంది
Cisco యొక్క IOS XE లో DMVPN లో టన్నెల్కు QoS మార్గదర్శిని NHRP గుంపు సమాచారం ద్వారా ఎంపిక చేయబడి ప్రతి స్పోక్పై విడివిడిగా వర్తించే hub నిష్క్రమణ విధానాన్ని వివరిస్తుంది. ఆ వాక్యం నుంచి రెండు పరిమితులు వస్తాయి, రెండూ నిర్లక్ష్యం చేయబడతాయి. రేటు పంచుకున్న బకెట్కు కాదు, ఒక స్పోక్కు చెందుతుంది, మరియు ఈ లక్షణం hub నుంచి స్పోక్ వైపు ట్రాఫిక్ను నియంత్రిస్తుంది, దీనికి విరుద్ధంగా కాదు.
స్పోక్ యొక్క పంపే దిశను స్వతంత్రంగా ప్రణాళిక చేయండి. hub నిష్క్రమణ విధానంలో శాఖ అప్లోడ్ చేసేదాన్ని పరిమితం చేసే ఏదీ లేదు.
మొత్తం పరిమితిని పంచుకున్న అడ్డంకి వద్ద ఉంచండి
మొత్తం అది నిజంగా పోటీ పడే చోట ఆకారం పొందాలి: అన్ని టన్నెల్లు పంచుకునే భౌతిక ఇంటర్ఫేస్పై. Cisco ఈ లక్షణానికి మద్దతు ఉన్న ఏకకాల భౌతిక విధానంగా భౌతిక ఇంటర్ఫేస్పై class-default షేపర్ను నమోదు చేస్తుంది, ఇది మీరు టైప్ చేయగల ఏదైనా సోపానక్రమం కంటే సన్నని ప్రకటన. మీరు సృష్టించిన ఏకపక్ష రెండవ భౌతిక విధానం ఎవరైనా వ్యతిరేకం నిరూపించే వరకు మద్దతు లేదని ఊహించండి.
తర్వాత అన్ని స్పోక్లు ఒకేసారి బిజీగా ఉన్నప్పుడు ఏమి జరుగుతుందో నిర్ణయించండి. ఏ ట్రాఫిక్ అంగీకరించబడుతుంది, ఏ తరగతికి ప్రాధాన్యత లభిస్తుంది, మరియు ఏ క్యూ పోటీని కలిగి ఉంటుంది. స్పోక్కు పైపరిమితి ఈ ప్రశ్నలలో ఏ ఒక్కదానికీ సమాధానం ఇవ్వదు, ఎందుకంటే ప్రతి స్పోక్ విడిగా పరిగణించబడుతుంది.
ఆకారపు యూనిట్లను మరియు ఓవర్హెడ్ లెక్కను నిజమైన అప్పగింతకు సరిపోల్చండి. రేటు లెక్క నుంచి మీరు వదిలే ఎన్క్యాప్సులేషన్ ఓవర్హెడ్ కాన్ఫిగర్ చేసిన సంఖ్యకు ముందే నిండిపోయే లింక్గా కనిపిస్తుంది.
కౌంటర్లు ఒక నిర్దిష్ట విధంగా అబద్ధం చెబుతాయి
మీరు ఆకారం ఇస్తున్న పొరలో కౌంటర్లను చదవండి. అదే Cisco మార్గదర్శిని ఈ అమరికలో ప్రధాన ఇంటర్ఫేస్ విధాన కౌంటర్లు సరికానివి కావచ్చని హెచ్చరిస్తుంది. అది కౌంటర్ గురించిన హెచ్చరిక, ఒక తరగతి సరిపోతోంది లేదా విడిచిపెడుతోంది అనడానికి రుజువు కాదు. దాన్ని అప్లికేషన్ ఫలితం నుంచి వేరుగా ఉంచండి, వినియోగదారు అనుభవించేది అది ఒక్కటే.
పాత traffic-shape ఉదాహరణను సంబంధం లేని విధాన మ్యాప్ పక్కన కాపీ చేయడం రెండు రేట్లు ఒకే ప్యాకెట్లను నియంత్రిస్తాయని నిరూపించదు.
పైపరిమితిని మాత్రమే కాదు, మొత్తాన్ని పరీక్షించండి
ఒక బిజీ స్పోక్తో ప్రారంభించి అది తన పరిమితిని చేరుకుంటుందని నిర్ధారించుకోండి. తర్వాత ఆమోదించిన ప్రణాళిక ప్రకారం అందరి నుంచి ఒకేసారి ట్రాఫిక్ ఇవ్వండి, మరియు స్పోక్ వారీ సంఖ్యల పక్కన భౌతిక ఇంటర్ఫేస్ను గమనించండి. ప్రతి స్పోక్ తన పరిమితిలో కూర్చుని ఉండగా అప్లింక్ నిండిపోయి ఆలస్యం పెరుగుతుంటే, స్పోక్ వారీ విధానం రూపకల్పన ప్రకారమే పనిచేస్తోంది మరియు బడ్జెట్ ఇంకా తప్పే ఉంది.
ఆ దశలో పరిష్కారం సామర్థ్యం లేదా ప్రవేశ నిర్ణయం. స్పోక్ వారీ సంఖ్యలను తిరిగి సర్దుబాటు చేయడం ఏ శాఖ మొదట ఫిర్యాదు చేస్తుందో మాత్రమే మారుస్తుంది.