เมื่อใด / เพราะเหตุใดจึงเริ่ม subnetting เครือข่าย


37

ภายใต้เงื่อนไขใดที่หนึ่งเริ่มพิจารณา subnetting เครือข่าย

ฉันกำลังมองหากฎง่ายๆโดยทั่วไปหรือทริกเกอร์โดยอิงจากตัวชี้วัดที่สามารถวัดค่าได้ซึ่งทำ subnetting สิ่งที่ควรพิจารณา

คำตอบ:


33

คำถามที่น่าสนใจ

ในอดีตก่อนที่จะมีการเปลี่ยนแปลงของเครือข่ายอย่างเต็มที่การพิจารณาหลักในการแบ่งเครือข่ายออกเป็นเครือข่ายย่อยต้องทำด้วยการ จำกัด จำนวนโหนดในโดเมนการชนกันครั้งเดียว นั่นคือถ้าคุณมีโหนดมากเกินไปประสิทธิภาพเครือข่ายของคุณจะถึงจุดสูงสุดและในที่สุดก็จะยุบลงภายใต้ภาระหนักเนื่องจากการชนที่มากเกินไป จำนวนโหนดที่แน่นอนที่สามารถนำไปใช้งานได้นั้นขึ้นอยู่กับหลายปัจจัย แต่โดยทั่วไปแล้วคุณไม่สามารถโหลดโดเมนการชนกันได้เกินกว่า 50% ของแบนด์วิดท์ทั้งหมดที่มีอยู่เป็นประจำและยังคงมีเครือข่ายที่เสถียรตลอดเวลา 50 โหนดในเครือข่ายเป็นโหนดจำนวนมากในสมัยนั้น ด้วยผู้ใช้ที่ใช้งานหนักคุณอาจมีการ จำกัด จำนวนโหนดที่ 20 หรือ 30 ก่อนที่จะต้องเริ่ม subnetting

แน่นอนว่าด้วยการ subnets ฟูลดูเพล็กซ์เต็มรูปแบบสลับการชนกันไม่ได้เป็นกังวลอีกต่อไปและสมมติว่าผู้ใช้ประเภทเดสก์ท็อปโดยทั่วไปคุณสามารถปรับใช้หลายร้อยโหนดในเครือข่ายย่อยเดียวโดยไม่มีปัญหาใด ๆ การมีทราฟฟิกออกอากาศจำนวนมากตามคำตอบอื่น ๆ ที่ได้กล่าวถึงอาจเป็นเรื่องที่น่ากังวลขึ้นอยู่กับโปรโตคอล / แอพพลิเคชั่นที่คุณใช้งานบนเครือข่าย อย่างไรก็ตามเข้าใจว่าการ subnetting เครือข่ายไม่จำเป็นต้องช่วยคุณในเรื่องการรับส่งข้อมูล โปรโตคอลจำนวนมากใช้การกระจายสัญญาณด้วยเหตุผล - นั่นคือเมื่อทุกโหนดในเครือข่ายจำเป็นต้องเห็นทราฟฟิกดังกล่าวเพื่อใช้คุณลักษณะระดับแอปพลิเคชันที่ต้องการ เพียงแค่ subnetting เครือข่ายไม่ได้ซื้ออะไรให้คุณเลยหากแพ็กเก็ตที่ถูกส่งออกไปนั้นจำเป็นที่จะต้องส่งต่อไปยัง subnet อื่นและทำการส่งออกอีกครั้ง

โดยทั่วไปในวันนี้เหตุผลหลักที่ทำให้เครือข่าย subnet นั้นมีส่วนเกี่ยวข้องกับการพิจารณาในระดับองค์กรการบริหารและความปลอดภัยมากกว่าสิ่งอื่นใด

คำถามเดิมจะถามถึงตัวชี้วัดที่สามารถวัดได้ซึ่งทำให้เกิดข้อควรพิจารณาในการแบ่งเครือข่ายย่อย ฉันไม่แน่ใจว่ามีตัวเลขใดเป็นพิเศษ สิ่งนี้จะขึ้นอยู่อย่างมากกับ 'แอปพลิเคชัน' ที่เกี่ยวข้องและฉันไม่คิดว่าจะมีจุดกระตุ้นใด ๆ ที่ใช้โดยทั่วไป

เกี่ยวข้องกับกฎของหัวแม่มือในการวางแผนเครือข่ายย่อย:

  • พิจารณาซับเน็ตสำหรับแต่ละแผนก / แผนกขององค์กรที่แตกต่างกันโดยเฉพาะอย่างยิ่งเมื่อพวกเขามีขนาดไม่เล็ก (50+ โหนด!)
  • พิจารณาซับเน็ตสำหรับกลุ่มของโหนด / ผู้ใช้โดยใช้ชุดแอปพลิเคชันทั่วไปที่แตกต่างจากผู้ใช้รายอื่นหรือประเภทโหนด (ผู้พัฒนาอุปกรณ์ VoIP, พื้นที่การผลิต)
  • พิจารณาเครือข่ายย่อยสำหรับกลุ่มผู้ใช้ที่มีข้อกำหนดด้านความปลอดภัยต่างกัน (การรักษาความปลอดภัยแผนกบัญชี Securing Wifi)
  • พิจารณาเครือข่ายย่อยจากการระบาดของไวรัสการละเมิดความปลอดภัยและมุมมองการจำกัดความเสียหาย มีกี่โหนดที่ได้รับการเปิดเผย / ละเมิด - ระดับการรับแสงที่ยอมรับได้สำหรับองค์กรของคุณคืออะไร การพิจารณานี้ถือว่าเป็นกฎ จำกัด การกำหนดเส้นทาง (ไฟร์วอลล์) ระหว่างเครือข่ายย่อย

จากทั้งหมดที่กล่าวว่าการเพิ่มซับเน็ตเพิ่มระดับของค่าใช้จ่ายในการดูแลระบบและอาจทำให้เกิดปัญหาเมื่อเทียบกับโหนดแอดเดรสในซับเน็ตหนึ่งและมีเหลืออยู่มากเกินไปในพูลอื่น ๆ เป็นต้นการตั้งค่าการกำหนดเส้นทางและไฟร์วอลล์ เครือข่ายและมีส่วนร่วมมากขึ้นสิ่งนั้น แน่นอนว่าแต่ละเครือข่ายย่อยควรมีเหตุผลที่มีอยู่ซึ่งมีค่ามากกว่าค่าใช้จ่ายในการบำรุงรักษาเชิงตรรกะที่ซับซ้อนมากขึ้น


7

หากเป็นไซต์เดียวอย่ากังวลจนกว่าคุณจะมีระบบมากกว่าโหลหลายระบบและถึงแม้ว่ามันอาจไม่จำเป็นก็ตาม

วันนี้กับทุกคนที่ใช้สวิตช์อย่างน้อย 100 Mbps และบ่อยขึ้น 1 Gbps เหตุผลเดียวที่เกี่ยวข้องกับประสิทธิภาพในการแบ่งกลุ่มเครือข่ายของคุณคือถ้าคุณมีปริมาณการรับสัญญาณออกอากาศมากเกินไป (เช่น> 2% จากส่วนหัวของฉัน)

เหตุผลอื่นที่สำคัญคือการรักษาความปลอดภัยเช่น DMZ สำหรับเซิร์ฟเวอร์สาธารณะหันหน้าไปทางซับเน็ตอื่นสำหรับการเงินหรือ VLAN / ซับเน็ตแยกต่างหากสำหรับระบบ VoIP


หลายสิบความหมายมากกว่า 50+? นอกจากนี้กิจกรรมการออกอากาศ - นั่นเป็นเมตริกที่ดีและวัดได้ง่าย คุณคิดว่ากิจกรรมการออกอากาศมีจำนวนเท่าใด
Adam Davis

ใช่ 50+ เป็นสิ่งที่ฉันคิด แต่ถึงอย่างนั้นความปลอดภัยก็ยังคงเป็นเหตุผลที่เป็นไปได้มากที่สุด
Alnitak

7

การ จำกัด ขอบเขตสำหรับข้อกำหนดความสอดคล้องใด ๆ ที่คุณอาจมี (เช่น PCI) เป็นตัวเร่งปฏิกิริยาที่ดีพอที่จะแบ่งกลุ่มบางส่วนของเครือข่ายของคุณ การแบ่งกลุ่มออกการยอมรับ / การประมวลผลการชำระเงินและระบบการเงินของคุณสามารถประหยัดเงินได้ แต่โดยทั่วไปเครือข่ายย่อยเครือข่ายขนาดเล็กจะไม่ทำให้คุณได้รับประสิทธิภาพมากนัก


4

อีกเหตุผลหนึ่งก็คือคุณภาพการบริการที่เกี่ยวข้อง เราเรียกใช้ vlans เสียงและข้อมูลแยกจากกันเพื่อให้เราสามารถนำ QoS ไปใช้กับปริมาณการใช้ voip ได้อย่างง่ายดาย

คุณรู้ไหมฉันคิดถึงคำถามนี้มากขึ้น มีเหตุผลที่ดีมากมายในการออกแบบเครือข่ายใหม่โดยใช้เครือข่ายที่แตกต่างกัน (ประสิทธิภาพความปลอดภัย QoS การ จำกัด ขอบเขต DHCP จำกัด การรับส่งข้อมูลออกอากาศ (ซึ่งอาจเกี่ยวข้องกับความปลอดภัยและประสิทธิภาพ)

แต่เมื่อคิดถึงตัวชี้วัดสำหรับการออกแบบใหม่เพื่อ subnet และการคิดถึงเครือข่ายที่ฉันต้องจัดการในอดีตสิ่งที่ฉันคิดได้ก็คือ "ว้าวนั่นต้องมีเครือข่ายหนึ่งที่ยุ่งเหยิงจริงๆเพื่อให้ฉันออกแบบใหม่ทั้งหมด มันสำหรับsubnetting " มีเหตุผลอื่น ๆ อีกมากมาย - แบนด์วิดท์การใช้งาน cpu ของอุปกรณ์ที่ติดตั้ง ฯลฯ แต่เพียง subnetting ตัวเองบนเครือข่ายข้อมูลที่บริสุทธิ์มักจะไม่ซื้อประสิทธิภาพมากมาย


3

ความปลอดภัยและคุณภาพส่วนใหญ่ (ตราบใดที่ส่วนของเครือข่ายที่มีปัญหาสามารถรองรับโหนดที่เป็นปัญหาได้แน่นอน) เครือข่ายที่แยกต่างหากสำหรับปริมาณการใช้เครื่องพิมพ์เสียง / โทรศัพท์แผนกแยกเช่น IT Ops และกลุ่มเซิร์ฟเวอร์แน่นอนส่วนที่เชื่อมต่ออินเทอร์เน็ต (หนึ่งต่อบริการอินเทอร์เน็ตที่ได้รับความนิยมในปัจจุบันไม่ใช่เพียงแค่ "หนึ่ง dmz จะทำ") เป็นต้น


3

หากคุณคาดว่าจะขยายตัว (คุณกำลังสร้างเครือข่ายไม่ใช่แค่ 5 เซิร์ฟเวอร์เท่านั้นและนั่นจะเป็นสิ่งนั้น) เริ่มต้นการกำหนดเส้นทางโดยเร็วที่สุด วิธีที่เครือข่ายจำนวนมากเกินไปไม่เสถียรและเติบโตได้ยากเพราะพวกเขาเติบโตแบบอินทรีย์และมีเลเยอร์ 2 มากเกินไป

ตัวอย่าง:

  • คุณมีสองเนมเซิร์ฟเวอร์ในเครือข่ายเดียวกัน ตอนนี้คุณไม่สามารถย้ายหนึ่งในนั้นไปยังเมืองอื่นได้เพราะคุณจะต้องแยกดี / 24 หรือเปลี่ยนหมายเลข DNS ใหม่ ง่ายขึ้นมากถ้าพวกเขาอยู่ในเครือข่ายที่แตกต่างกัน ฉันไม่ได้พูดถึงความจำเป็นในการกลายเป็นผู้ประกาศข่าว BGP เหล่านี้ไปทั่วโลก ตัวอย่างนี้สำหรับ ISP ทั่วประเทศ โปรดทราบว่าบางสิ่งในพื้นที่ผู้ให้บริการนั้นไม่ใช่เรื่องง่ายเหมือน "เพียงแค่ลงทะเบียน DNS ใหม่ที่นายทะเบียน"
  • ชั้นที่ 2 ลูปดูดตูด เช่นเดียวกับการขยายต้นไม้ (และ VTP) เมื่อต้นไม้ที่สแปนล้มเหลว (และมีหลายกรณีเมื่อมันทำ) มันจะเอาทุกอย่างลงไปด้วยเนื่องจากการท่วมสวิตช์ CPU / เราเตอร์ เมื่อ OSPF หรือ IS-IS ล้มเหลว (หรือโปรโตคอลการกำหนดเส้นทางอื่น ๆ ) มันจะไม่ผิดพลาดทั้งเครือข่ายและคุณสามารถแก้ไขได้ครั้งละหนึ่งส่วน การแยกความผิด

ดังนั้นโดยย่อ: เมื่อคุณขยายไปถึงตำแหน่งที่คุณคิดว่าคุณต้องการ spanning tree โปรดพิจารณาการกำหนดเส้นทางแทน


3

โดยส่วนตัวผมชอบแบ่งเลเยอร์ 3 ให้ใกล้กับสวิตช์การเข้าถึงมากที่สุดเพราะ

  • ฉันไม่ชอบ Spanning Tree (คุณสามารถทำให้มันตลกมากถ้าคุณชั่วร้าย)
  • โดยเฉพาะอย่างยิ่งในเครือข่าย Windoze การออกอากาศเป็นปัญหาที่แท้จริง
  • บนเครือข่ายส่วนตัวคุณมีพื้นที่ IP มากมายเหลือเกิน :)
  • แม้แต่สวิตช์ที่ถูกกว่าก็มีความสามารถในการกำหนดเส้นทางด้วยสายไว - แล้วทำไมไม่ลองใช้
  • ทำให้ชีวิตง่ายขึ้นเมื่อพูดถึงเรื่องความปลอดภัย (เช่น Auth และ ACL ที่ egde ฯลฯ )
  • ความเป็นไปได้ QoS ที่ดีขึ้นสำหรับ VoIP และเรียลไทม์
  • คุณสามารถบอกตำแหน่งของลูกค้าได้จาก IP

หากเป็นเรื่องของเครือข่ายสเปรดที่ใหญ่กว่า / กว้างกว่าที่มีสวิตช์หลัก / สวิตช์ไม่เพียงพอกลไกการสำรองซ้ำซ้อนอย่าง VRRP มีข้อบกพร่องมากมาย (ปริมาณการใช้งานส่งผ่านอัปลิงค์หลายครั้ง ... ) OSPF ไม่มี

อาจมีเหตุผลอื่น ๆ อีกมากที่จะสนับสนุนการใช้งานขนาดเล็กออกอากาศโดเมน - การตรวจสอบ


2

ฉันคิดว่าขอบเขตขององค์กรมีความสำคัญมาก หากมี 200 โฮสต์ทั้งหมดหรือน้อยกว่าในเครือข่ายและการรับส่งข้อมูลไม่จำเป็นต้องแบ่งกลุ่มด้วยเหตุผลใด ๆ เพิ่มความซับซ้อนของ VLANs และซับเน็ตทำไม แต่ขอบเขตที่ใหญ่กว่าก็ยิ่งสมเหตุสมผล

การแยกเครือข่ายที่ปกติไม่จำเป็นต้องทำอาจทำให้บางสิ่งง่ายขึ้น ตัวอย่างเช่น PDU ของเราที่จ่ายพลังงานให้กับเซิร์ฟเวอร์อยู่ใน VLAN หรือซับเน็ตเดียวกันกับเซิร์ฟเวอร์ ซึ่งหมายความว่าระบบการสแกนช่องโหว่ของเราที่ใช้ในช่วงเซิร์ฟเวอร์ของเรายังสแกน PDU ด้วย ไม่ใช่เรื่องใหญ่ แต่เราไม่ต้องการสแกน PDU นอกจากนี้ยังเป็นการดีที่ DHCP PDUs เนื่องจากพวกเขาจะเจ็บปวดในการกำหนดค่า แต่เนื่องจากพวกเขาอยู่ใน VLAN เดียวกันกับเซิร์ฟเวอร์ในขณะนี้จึงไม่เป็นไปได้มาก

แม้ว่าเราไม่ต้องการ VLAN อื่นสำหรับ PDU แต่ก็สามารถทำให้บางสิ่งง่ายขึ้น และสิ่งนี้จะกลายเป็นการโต้แย้งที่ยิ่งใหญ่กว่าและน้อยกว่าของ VLAN ที่จะดำเนินต่อไปเรื่อย ๆ

ฉันฉันแค่คิดว่ามี VLAN ที่มันสมเหตุสมผล ถ้าเช่นเราให้ PDUs ของตัวเอง VLAN มันไม่ได้หมายความว่าเราจะต้องให้อุปกรณ์กลุ่มเล็ก ๆ ของพวกเขาเอง VLAN แต่ในกรณีนี้มันอาจสมเหตุสมผล หากกลุ่มอุปกรณ์ไม่จำเป็นต้องมี VLAN เป็นของตัวเองและไม่มีข้อได้เปรียบในการทำเช่นนั้นคุณอาจต้องการพิจารณาทิ้งสิ่งต่าง ๆ ตามที่เป็นอยู่

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.