MX, IPsec-ను ముగించడానికి ముందు ఏవి సరిపోలాలి
కాన్ఫిగరేషన్ను అంగీకరించే commit పార్సర్ను మాత్రమే రుజువు చేస్తుంది, మార్గాన్ని కాదు. ప్లాట్ఫారమ్ tupleలోని ఐదు భాగాలు సేవ నిజంగా నడుస్తుందా లేదా అని నిర్ణయిస్తాయి.
కాన్ఫిగరేషన్ శుభ్రంగా commit అవుతుంది, ఇంటర్ఫేస్లు పైకి వస్తాయి, టన్నెల్ మాత్రం ఇప్పటికీ ఏర్పడటానికి నిరాకరిస్తుంది. లాగ్లో ఏ వరుసా ప్లాట్ఫారమ్ ఇది చేయలేదని చెప్పదు; అది చేయదు అంతే. Junosలో, IPsec అనేది చాసిస్, సేవా హార్డ్వేర్ లేదా సాఫ్ట్వేర్ మార్గం, మరియు విడుదల యొక్క నిర్దిష్ట కలయిక మాత్రమే నిర్వహించగల సేవ, మరియు ఫీచర్ పేజీ సాఫ్ట్వేర్ సామర్థ్యాన్ని వివరిస్తుంది, మీ పరికరాన్ని కాదు. tuple భాగం భాగంగా తనిఖీ చేయాలి, ఎందుకంటే commit ఫలితం పార్సర్ను మాత్రమే రుజువు చేస్తుంది.
ప్యాకెట్ నిజంగా ఎక్కడికి వెళ్తుంది
IPsec కోసం ఎంచుకున్న ట్రాఫిక్ దాన్ని గుప్తీకరించే భాగానికి చేరాలి. సేవా మాడ్యూల్ ఉన్న ప్లాట్ఫారమ్లలో, ఎంచుకున్న ప్రవాహం ఆ మాడ్యూల్కు మళ్లించబడుతుంది, తర్వాత ఫార్వార్డింగ్ మార్గానికి తిరిగి వస్తుంది. మాడ్యూల్ లేకపోతే, సామర్థ్యం తక్కువగా ఉంటే లేదా ఇంటర్ఫేస్కు కట్టబడకపోతే, కాన్ఫిగరేషన్ ఉంటుంది, ఒక్క ప్యాకెట్ కూడా ప్రాసెస్ కాదు. commit అవుట్పుట్లో ఏదీ ఆ స్థితిని ఆరోగ్యకరమైన స్థితి నుండి వేరు చేయదు.
సాఫ్ట్వేర్లో హోస్ట్ చేసిన అమలులు పనిని రూటింగ్ ఇంజిన్లో లేదా ఇన్లైన్ హార్డ్వేర్లో ఉంచుతాయి, వనరుల పరిమితులు చాలా భిన్నంగా ఉంటాయి. కాన్ఫిగరేషన్లో కనిపించే టన్నెల్ ఈ మార్గాలలో ఏది నిజంగా దాన్ని మోస్తోందో చెప్పదు.
tupleలోని ఐదు భాగాలు
ఏ సిఫారసు చదవకముందే కలయికను రాయండి, ఎందుకంటే ఒక భాగం మిగిలినవాటిని చెల్లనివి చేయవచ్చు. మూడు సంవత్సరాల క్రితం సేవకు మద్దతిచ్చిన భాగ సంఖ్య ఈ చాసిస్లోని కార్డు మరియు విడుదల గురించి ఏమీ చెప్పదు. క్రింది వరుసలను చెక్లిస్ట్గా చదివి, కాన్ఫిగరేషన్ చూపలేని విలువలను నింపండి.
| Part | What to record | Where it fails quietly |
|---|---|---|
| Chassis and service hardware | Model plus the installed PIC, MPC or MIC | Card absent or not bound to the interface |
| Implementation | Services card, inline or software path | Configuration accepted, no processing |
| Release | Exact Junos version | The feature arrives in a later build |
| Address families and mode | Outer and inner family, tunnel mode, peer authentication | Half the traffic silently unprotected |
| Entitlement and capacity | Licence state and the workload profile | Ceiling reached only under load |
చిరునామా కుటుంబాలు మరియు పనిభారం ప్రజలు దాటవేసే రెండు వరుసలు, రెండూ తనిఖీకి చవకైనవి, తర్వాత కనుగొనడానికి ఖరీదైనవి. tupleను పరికరం నుండి చదవండి, స్ప్రెడ్షీట్ నుండి కాదు, ఎందుకంటే కాన్ఫిగరేషన్ మీరు అడిగినదాన్ని నివేదిస్తుంది, ఇన్స్టాల్ చేసినదాన్ని కాదు. ఎక్కువ భాగాన్ని రెండు ఆదేశాలు మోస్తాయి: show chassis hardware నిజంగా బిగించిన కార్డును పేర్కొంటుంది, show version ఖచ్చితమైన విడుదలను ఇస్తుంది. ఏదీ కాన్ఫిగరేషన్ సరైనదా అనే దానిపై ఆధారపడదు, అదే అసలు విషయం.
show chassis hardware
show versionవిడుదల గేట్లు నిజమైన గేట్లు
విడుదల వివరం అధికారికం కాదు. Juniper IPsec అవలోకనం బహుళ సేవా కార్డులకు AES-GCM మద్దతును Junos 17.3R1కి తేదీ ఇస్తుంది, FIPS మోడ్ 17.4R1లో ప్రారంభమవుతుంది. కాబట్టి అదే ఫీచర్కు ప్లాట్ఫారమ్ ఎలా నడుపబడుతుందనే దానిపై రెండు హద్దులు ఉన్నాయి, మీరు నడిపే మోడ్ ఏది వర్తిస్తుందో నిర్ణయిస్తుంది. ఫీచర్ జాబితాను తనిఖీ చేయకముందే మోడ్ను తనిఖీ చేయండి.
విడుదల గమనికలను ఖచ్చితంగా ఇన్స్టాల్ చేసిన వెర్షన్ కోసం చదవండి, డాక్యుమెంట్ చేసిన కొత్తదానికి కాదు. తర్వాతి buildలో వచ్చిన సామర్థ్యం మునుపటిలో ఉందని భావించలేము, ఒక కార్డు కోసం రాసిన ప్రకటన మరొకదానికి మారదు. విడుదల గమనిక లైన్ను డిజైన్ రికార్డులో కాపీ చేయండి, దావా తన మూలాన్ని తనతో తీసుకెళ్లేలా, ఎందుకంటే ప్లాట్ఫారమ్ కుటుంబం కోసం రాసిన మద్దతు ప్రకటన మీరు నడిపే మోడ్ లేదా మీ వద్ద ఉన్న కార్డు గురించి ప్రకటన కాదు.
సామర్థ్యం అనేది పనిభారం, శీర్షిక కాదు
కొలత నిబంధనలు లేని శీర్షిక థ్రూపుట్ సంఖ్య మార్కెటింగ్ సంఖ్య. చిన్న ప్యాకెట్లు బిట్కు పెద్దవాటి కంటే చాలా ఖరీదు, ఒకేసారి ఉన్న అసోసియేషన్లు మెమరీ తీసుకుంటాయి, కార్డును పంచుకునే ప్రతి ఇతర సేవ మిగిలినదాన్ని తగ్గిస్తుంది.
ఆశించిన ట్రాఫిక్ నుండి అంచనా వేయండి: సాధారణ మరియు అత్యంత దారుణమైన ప్యాకెట్ పరిమాణాలు, సహచరుల సంఖ్య, ఆ కార్డు NAT లేదా మరో సేవను కూడా ముగిస్తుందా. తర్వాత ఏదో రోజు ఒక మార్గం డిజైన్ ఊహించిన దానికంటే ఎక్కువ భారం మోసే రోజు కోసం చోటు వదలండి. నిష్క్రియ హార్డ్వేర్ను ఊహించే సామర్థ్య ప్రణాళిక ఒక కోరిక, ప్రణాళిక కాదు. ఈ సంఖ్య వ్యాపార కేసుకు ముఖ్యమైనదైతే, పరికరంలో ప్రాతినిధ్య భారం క్రింద ఒకసారి కొలవండి, ఆ కొలతను డిజైన్తో ఉంచండి.
డిజైన్ కంటే ముందు రికార్డును రాయండి
డిజైన్కు అవసరమైన ప్రతి సామర్థ్యానికి ప్లాట్ఫారమ్ సూచన, విడుదలకు సరిపోలే పత్రాలు మరియు పరిష్కరించని పరిమితి ఏదైనా ఒకే చోట ఉంచండి. tupleలో ఏదైనా వరుస విఫలమైతే, పాత కొనుగోలు జాబితా చుట్టూ డిజైన్ను తిరిగి నిర్మించే బదులు వేరే ఆమోదిత గేట్వేతో పోల్చండి. ఏ ఖచ్చితమైన వ్యవస్థ ఈ పని చేస్తుంది, ఏ హద్దుల్లో చేస్తుంది అని రికార్డు చెప్పాలి.
అప్పుడే సహచరుడిని తనిఖీ చేయండి, ఎందుకంటే దూరపు చివరతో ప్రోటోకాల్ అనుకూలత తదుపరి ప్రశ్న, స్థానిక మద్దతుకు ప్రత్యామ్నాయం ఎప్పుడూ కాదు. అంగీకరించే సహచరుడు కూడా ఒక్క ప్యాకెట్ను కూడా గుప్తీకరించని చాసిస్కు సహాయపడలేడు.