Ano ang dapat magtugma bago matapos ng MX ang IPsec
Ang commit na tumatanggap sa configuration ay nagpapatunay sa parser, hindi sa landas. Limang bahagi ng tuple ng plataporma ang nagtatakda kung talagang tumatakbo ang serbisyo.
Malinis na nag-commit ang configuration, bumabangon ang mga interface, at ayaw pa ring maitayo ng tunnel. Walang linyang nagsasabi sa log na hindi ito kaya ng plataporma; hindi lang talaga nito ginagawa. Sa Junos, ang IPsec ay isang serbisyong kayang isagawa lamang ng isang partikular na kombinasyon ng chassis, service hardware o software path, at release, at ang pahina ng feature ay naglalarawan ng kakayahan ng software, hindi ng iyong device. Kailangang suriin ang tuple nang bahagi-bahagi, dahil ang resulta ng commit ay nagpapatunay lamang sa parser.
Saan talaga napupunta ang packet
Ang trapikong pinili para sa IPsec ay kailangang umabot sa component na nag-encrypt nito. Sa mga platapormang may service module, ang piniling flow ay itinuturo sa module na iyon at pagkatapos ay bumalik sa forwarding path. Kung wala ang module, kulang ang kakayahan nito o hindi ito nakakabit sa interface, umiiral ang configuration at walang kahit isang packet na napoproseso. Walang anuman sa output ng commit ang naghihiwalay sa kasong iyon mula sa isang malusog.
Ang mga implementasyong naka-host sa software ay nag-iiwan ng trabaho sa routing engine o sa inline hardware, na may ibang-ibang limitasyon sa resources. Ang tunnel na nakikita sa configuration ay hindi nagsasabi kung alin sa mga landas na iyon ang talagang nagdadala nito.
Ang limang bahagi ng tuple
Isulat ang kombinasyon bago magbasa ng anumang rekomendasyon, dahil ang isang bahagi ay maaaring magpawalang-bisa sa iba. Ang numero ng bahagi na sumuporta sa isang serbisyo tatlong taon na ang nakalipas ay walang sinasabi tungkol sa card at release sa chassis na ito. Basahin ang mga hilera sa ibaba bilang checklist, pagkatapos ay punan ang mga halagang hindi maipakita ng configuration sa iyo.
| 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 |
Ang mga pamilya ng address at ang workload ang dalawang hilerang nilalaktawan ng mga tao, at parehong mura ang pagsuri at mahal ang matuklasan nang huli. Basahin ang tuple mula sa device, hindi mula sa spreadsheet, dahil iniuulat ng configuration ang hiningi mo, hindi ang naka-install. Dalawang command ang nagdadala ng halos lahat: pinapangalanan ng show chassis hardware ang card na talagang nakalagay, at ibinibigay ng show version ang eksaktong release. Wala sa dalawa ang nakadepende sa kung tama ang configuration, at iyon ang punto.
show chassis hardware
show versionAng mga gate ng release ay totoong gate
Ang detalye ng release ay hindi pormalidad. Itinatakda ng pangkalahatang-tanaw ng IPsec ng Juniper ang suporta sa AES-GCM para sa multiservice cards sa Junos 17.3R1, na nagsisimula ang FIPS mode sa 17.4R1. Kaya ang parehong feature ay may dalawang hangganan depende sa kung paano pinapatakbo ang plataporma, at ang mode na pinapatakbo mo ang nagtatakda kung alin ang naaangkop. Suriin ang mode bago suriin ang listahan ng features.
Basahin ang mga release note para sa eksaktong naka-install na bersyon, hindi para sa pinakabagong dokumentado. Ang kakayahang dumating sa mas huling build ay hindi maaaring ipagpalagay na naroroon sa naunang build, at ang pahayag na isinulat para sa isang card ay hindi lumilipat sa isa pa. Kopyahin ang linya ng release note sa design record upang ang pahayag ay may sariling pinagmulan, dahil ang pahayag ng suporta na isinulat para sa isang pamilya ng plataporma ay hindi pahayag tungkol sa mode na pinapatakbo mo o sa card na mayroon ka.
Ang kapasidad ay workload, hindi headline
Ang figure ng throughput sa headline na walang mga kondisyon ng pagsukat nito ay numero ng marketing. Mahal ang maliliit na packet kada bit kaysa sa malalaki, kumokonsumo ng memory ang sabay-sabay na associations, at bawat ibang serbisyong nagbabahagi ng card ay nagpapababa sa natitira.
Tantiyahin mula sa trapikong inaasahan mo: karaniwan at pinakamasamang laki ng packet, bilang ng mga peer, at kung tinatapos din ng card na iyon ang NAT o ibang serbisyo. Pagkatapos ay mag-iwan ng espasyo para sa araw na mas malaki ang dadalhin ng isang landas kaysa sa inaasahan ng disenyo. Ang plano ng kapasidad na nagpapalagay ng walang ginagawa na hardware ay hangarin, hindi plano. Kung mahalaga ang numero para sa business case, sukatin ito nang isang beses sa device sa ilalim ng representatibong karga at itago ang pagsukat na iyon kasama ng disenyo.
Isulat ang record bago ang disenyo
Para sa bawat kakayahang kailangan ng disenyo, itago ang reference ng plataporma, ang dokumentasyong tumutugma sa release, at anumang hindi pa nalutas na paghihigpit sa isang lugar. Kapag nabigo ang isang hilera ng tuple, ihambing ang isa pang aprubadong gateway sa halip na itayong muli ang disenyo sa paligid ng lumang shopping list. Dapat sabihin ng record kung aling eksaktong sistema ang gumagawa ng trabaho at sa ilalim ng anong mga limitasyon.
Pagkatapos lamang suriin ang peer, dahil ang compatibility ng protocol sa malayong dulo ang susunod na tanong at hindi kailanman pumapalit sa lokal na suporta. Ang peer na sumasang-ayon sa mga proposal ay hindi pa rin matutulungan ang chassis na hindi kailanman nag-encrypt ng packet.