ປ່ຽນ ACLs ໃນລາຍລະອຽດ

ACLs (Access Control List) ໃນອຸປະກອນເຄືອຂ່າຍສາມາດຖືກປະຕິບັດໄດ້ທັງໃນຮາດແວ ແລະຊອບແວ, ຫຼືໂດຍທົ່ວໄປແລ້ວ, ACLs ທີ່ໃຊ້ຮາດແວ ແລະຊອບແວ. ແລະຖ້າທຸກສິ່ງທຸກຢ່າງຄວນຈະມີຄວາມຊັດເຈນກັບ ACLs ທີ່ອີງໃສ່ຊອບແວ - ເຫຼົ່ານີ້ແມ່ນກົດລະບຽບທີ່ຖືກເກັບໄວ້ແລະປຸງແຕ່ງໃນ RAM (i.e. ໃນ Control Plane), ມີຂໍ້ຈໍາກັດທີ່ເກີດຂື້ນ, ຫຼັງຈາກນັ້ນພວກເຮົາຈະເຂົ້າໃຈວິທີການປະຕິບັດ ACLs ທີ່ອີງໃສ່ຮາດແວແລະເຮັດວຽກຂອງພວກເຮົາ. ບົດຄວາມ. ຕົວຢ່າງ, ພວກເຮົາຈະໃຊ້ສະວິດຈາກຊຸດ ExtremeSwitching ຈາກ Extreme Networks.

ເນື່ອງຈາກພວກເຮົາມີຄວາມສົນໃຈໃນ ACLs ທີ່ອີງໃສ່ຮາດແວ, ການປະຕິບັດພາຍໃນຂອງ Data Plane, ຫຼື chipsets ຕົວຈິງ (ASICs) ທີ່ໃຊ້, ແມ່ນມີຄວາມສໍາຄັນທີ່ສຸດສໍາລັບພວກເຮົາ. ທຸກໆສາຍສະຫຼັບເຄືອຂ່າຍ Extreme Networks ແມ່ນສ້າງຂຶ້ນໃນ Broadcom ASICs, ແລະດັ່ງນັ້ນຂໍ້ມູນສ່ວນໃຫຍ່ຂ້າງລຸ່ມນີ້ກໍ່ຈະເປັນຄວາມຈິງສໍາລັບສະວິດອື່ນໆໃນຕະຫຼາດທີ່ປະຕິບັດຢູ່ໃນ ASICs ດຽວກັນ.

ດັ່ງທີ່ເຫັນໄດ້ຈາກຮູບຂ້າງເທິງ, "ContentAware Engine" ແມ່ນຮັບຜິດຊອບໂດຍກົງຕໍ່ການເຮັດວຽກຂອງ ACLs ໃນ chipset, ແຍກຕ່າງຫາກສໍາລັບ "ingress" ແລະ "egress". ໃນສະຖາປັດຕະຍະກໍາ, ພວກມັນຄືກັນ, ພຽງແຕ່ "egress" ແມ່ນມີຂະຫນາດຫນ້ອຍແລະເຮັດວຽກຫນ້ອຍ. ທາງດ້ານຮ່າງກາຍ, ທັງສອງ "ContentAware Engines" ແມ່ນຫນ່ວຍຄວາມຈໍາ TCAM ບວກກັບເຫດຜົນ, ແລະຜູ້ໃຊ້ແຕ່ລະຄົນຫຼືກົດລະບຽບ ACL ແມ່ນຫນ້າກາກທີ່ງ່າຍດາຍທີ່ຂຽນໃສ່ຫນ່ວຍຄວາມຈໍານີ້. ນັ້ນແມ່ນເຫດຜົນທີ່ຊິບເຊັດປະມວນຜົນການຈາລະຈອນໂດຍແພັກເກັດແລະບໍ່ມີການເສື່ອມໂຊມການປະຕິບັດ.

ໃນທາງກາຍ, Ingress/Egress TCAM ດຽວກັນ, ໃນທາງກັບກັນ, ແບ່ງອອກຢ່າງມີເຫດຜົນເປັນຫຼາຍພາກສ່ວນ (ຂຶ້ນກັບຈໍານວນຫນ່ວຍຄວາມຈໍາຂອງມັນເອງແລະເວທີ), ອັນທີ່ເອີ້ນວ່າ "ACL slices". ຕົວຢ່າງເຊັ່ນ, ສິ່ງດຽວກັນເກີດຂື້ນກັບ HDD ດຽວກັນຢູ່ໃນຄອມພິວເຕີ້ຂອງທ່ານເມື່ອທ່ານສ້າງໄດທີ່ມີເຫດຜົນຫຼາຍ - C:>, D:>. ແຕ່ລະແຜ່ນ ACL, ໃນທາງກັບກັນ, ປະກອບດ້ວຍຈຸລັງຄວາມຊົງຈໍາໃນຮູບແບບຂອງ "ສາຍ" ບ່ອນທີ່ "ກົດລະບຽບ" (ກົດລະບຽບ / ຫນ້າກາກບິດ) ຖືກຂຽນ.

ການແບ່ງ TCAM ເປັນ ACL-slices ມີເຫດຜົນທີ່ແນ່ນອນຢູ່ເບື້ອງຫຼັງ. ໃນແຕ່ລະ ACL-slices, ພຽງແຕ່ "ກົດລະບຽບ" ທີ່ເຂົ້າກັນໄດ້ເຊິ່ງກັນແລະກັນສາມາດຂຽນໄດ້. ຖ້າ "ກົດລະບຽບ" ໃດໆທີ່ບໍ່ເຂົ້າກັນໄດ້ກັບອັນກ່ອນຫນ້າ, ມັນຈະຖືກຂຽນໃສ່ ACL-slice ຕໍ່ໄປ, ໂດຍບໍ່ຄໍານຶງເຖິງຈໍານວນເສັ້ນຟຣີສໍາລັບ "ກົດລະບຽບ" ຈະຖືກປະໄວ້ໃນອັນກ່ອນ.

ແລ້ວຄວາມເຂົ້າກັນໄດ້ ຫຼືຄວາມບໍ່ເຂົ້າກັນຂອງກົດລະບຽບ ACL ມາຈາກໃສ? ຄວາມຈິງແມ່ນວ່າຫນຶ່ງ TCAM "ເສັ້ນ", ບ່ອນທີ່ "ກົດລະບຽບ" ຖືກຂຽນ, ມີຄວາມຍາວ 232 bits ແລະແບ່ງອອກເປັນຫຼາຍຂົງເຂດ - Fixed, Field1, Field2, Field3. 232 bit ຫຼື 29 byte ຫນ່ວຍຄວາມຈໍາ TCAM ແມ່ນພຽງພໍທີ່ຈະບັນທຶກ bit-mask ຂອງ MAC ຫຼືທີ່ຢູ່ IP ສະເພາະ, ແຕ່ຫຼາຍຫນ້ອຍກ່ວາຊຸດ Ethernet header ເຕັມ. ໃນແຕ່ລະ ACL-slice, ASIC ດໍາເນີນການຊອກຫາເອກະລາດອີງຕາມ bit-mask ທີ່ກໍານົດໄວ້ໃນ F1-F3. ໂດຍທົ່ວໄປ, ການຊອກຫານີ້ສາມາດຖືກປະຕິບັດໂດຍໃຊ້ 128 bytes ທໍາອິດຂອງຫົວອີເທີເນັດ. ຕົວຈິງແລ້ວ, ແນ່ນອນ, ເພາະວ່າການຄົ້ນຫາສາມາດປະຕິບັດໄດ້ຫຼາຍກວ່າ 128 bytes, ແຕ່ສາມາດຂຽນໄດ້ພຽງແຕ່ 29 bytes, ສໍາລັບການຊອກຫາທີ່ຖືກຕ້ອງ, ການຊົດເຊີຍຕ້ອງຖືກຕັ້ງຄ່າທີ່ກ່ຽວຂ້ອງກັບຈຸດເລີ່ມຕົ້ນຂອງແພັກເກັດ. ການຊົດເຊີຍສໍາລັບແຕ່ລະ ACL-slice ຖືກກໍານົດເມື່ອກົດລະບຽບທໍາອິດຖືກຂຽນໃສ່ມັນ, ແລະຖ້າ, ເມື່ອຂຽນກົດລະບຽບຕໍ່ໄປ, ຄວາມຕ້ອງການສໍາລັບການຊົດເຊີຍອື່ນຖືກຄົ້ນພົບ, ຫຼັງຈາກນັ້ນກົດລະບຽບດັ່ງກ່າວຖືກພິຈາລະນາວ່າບໍ່ເຫມາະສົມກັບທໍາອິດແລະຖືກຂຽນໃສ່. ACL-slice ຕໍ່ໄປ.

ຕາຕະລາງຂ້າງລຸ່ມນີ້ສະແດງໃຫ້ເຫັນຄໍາສັ່ງຂອງຄວາມເຂົ້າກັນໄດ້ຂອງເງື່ອນໄຂທີ່ລະບຸໄວ້ໃນ ACL. ແຕ່​ລະ​ແຖວ​ຂອງ​ບຸກ​ຄົນ​ປະ​ກອບ​ດ້ວຍ bit-masks ທີ່​ຜະ​ລິດ​ທີ່​ເຂົ້າ​ກັນ​ໄດ້​ກັບ​ກັນ​ແລະ​ບໍ່​ເຂົ້າ​ກັນ​ໄດ້​ກັບ​ສາຍ​ອື່ນໆ​.

ແຕ່ລະແພັກເກັດທີ່ປະມວນຜົນໂດຍ ASIC ດໍາເນີນການຊອກຫາແບບຂະຫນານໃນແຕ່ລະ ACL-slice. ການກວດສອບແມ່ນດໍາເນີນການຈົນກ່ວາການຈັບຄູ່ທໍາອິດໃນ ACL-slice, ແຕ່ການຈັບຄູ່ຫຼາຍແມ່ນອະນຸຍາດໃຫ້ສໍາລັບຊອງດຽວກັນໃນ ACL-slice ທີ່ແຕກຕ່າງກັນ. ແຕ່ລະ "ກົດລະບຽບ" ມີການປະຕິບັດທີ່ສອດຄ້ອງກັນທີ່ຕ້ອງໄດ້ຮັບການປະຕິບັດຖ້າເງື່ອນໄຂ (ບິດຫນ້າກາກ) ຖືກຈັບຄູ່. ຖ້າການຈັບຄູ່ເກີດຂຶ້ນໃນຫຼາຍໆ ACL-slice ໃນເວລາດຽວກັນ, ຫຼັງຈາກນັ້ນໃນ "ການແກ້ໄຂບັນຫາການຂັດແຍ້ງ" ຕັນ, ໂດຍອີງໃສ່ຄວາມສໍາຄັນຂອງ ACL-slice, ການຕັດສິນໃຈຈະດໍາເນີນການ. ຖ້າ ACL ມີທັງ "ການກະ ທຳ" (ອະນຸຍາດ / ປະຕິເສດ) ແລະ "ຕົວແກ້ໄຂການກະ ທຳ" (ນັບ / QoS / ບັນທຶກ / ...), ຫຼັງຈາກນັ້ນ, ໃນກໍລະນີມີການຈັບຄູ່ຫຼາຍພຽງແຕ່ "ການກະ ທຳ" ທີ່ມີບູລິມະສິດສູງກວ່າຈະຖືກປະຕິບັດ, ໃນຂະນະທີ່ "ການກະ ທຳ. -modifier” ຈະ​ສໍາ​ເລັດ​ທັງ​ຫມົດ​. ຕົວຢ່າງຂ້າງລຸ່ມນີ້ສະແດງໃຫ້ເຫັນວ່າຕົວນັບທັງສອງຈະຖືກເພີ່ມຂຶ້ນແລະ "ປະຕິເສດ" ບູລິມະສິດທີ່ສູງກວ່າຈະຖືກປະຕິບັດ.

"ຄູ່ມືການແກ້ໄຂ ACL" ມີລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບການດໍາເນີນງານຂອງ ACL ຢູ່ໃນສາທາລະນະຢູ່ໃນເວັບໄຊທ໌ extremenetworks.com. ຄໍາຖາມໃດໆທີ່ເກີດຂື້ນຫຼືຍັງຄົງສາມາດຖາມໄດ້ກັບພະນັກງານຫ້ອງການຂອງພວກເຮົາ - [email protected].

ແຫຼ່ງຂໍ້ມູນ: www.habr.com