IPv4 Subnet — เส้นแบ่งบิตที่ทุกคนท่องได้แต่ไม่ค่อยเข้าใจ

255.255.255.0 เป็นเลขที่คนทำงานไอทีทุกคนพิมพ์ได้โดยไม่ต้องคิด และเป็นเลขที่คนจำนวนมากอธิบายไม่ได้ว่ามันคืออะไร

ปัญหาไม่ได้อยู่ที่เรื่องนี้ยาก แต่อยู่ที่วิธีเขียนมันหลอกตา — การเขียนเป็นเลขสี่ชุดคั่นจุดทำให้ดูเหมือนตัวเลข ทั้งที่มันไม่ใช่ตัวเลข มันคือเส้นแบ่ง และพอเห็นเป็นเส้นแบ่งเมื่อไหร่ /25 /26 /30 จะเข้าใจได้ในสามนาที

หน้านี้ต่อจาก Internet Protocol ซึ่งวางเรื่อง "เลขที่อยู่คือบิต 32 ตัว" ไว้แล้ว ถ้ายังไม่ได้อ่านให้อ่านตรงนั้นก่อน

เครื่องของคุณเขียน mask ไว้ตรงกว่าที่คุณคิด

ลองดูเลขที่เครื่องตัวเองใช้อยู่

$ ifconfig en0 | grep 'inet '
  inet 192.168.1.134 netmask 0xffffff00 broadcast 192.168.1.255

สังเกตว่าแมคไม่ได้เขียน 255.255.255.0 แต่เขียน 0xffffff00 ซึ่งเป็นเลขฐานสิบหก และเป็นการเขียนที่ใกล้ความจริงมากกว่า เพราะ ff แต่ละคู่คือบิต 1 แปดตัวติดกัน

0x ff       ff       ff       00
   11111111 11111111 11111111 00000000
   └──────── 24 บิตแรกเป็น 1 ────────┘└─ 8 บิตท้ายเป็น 0 ─┘

บนลินุกซ์ ip addr เขียนสั้นกว่านั้นอีกคือ 192.168.1.134/24 ซึ่งบอกตรง ๆ เลยว่า 24 คือจำนวนบิตที่เป็นหนึ่ง

สามวิธีเขียน เลขเดียวกัน และวิธีที่เราคุ้นที่สุดคือวิธีที่บอกความจริงน้อยที่สุด

คำถามเดียวที่ mask มีไว้ตอบ

การ AND ที่อยู่ของเครื่องกับ mask ทีละบิต บิตที่ตรงกับหนึ่งถูกเก็บไว้ บิตที่ตรงกับศูนย์ถูกล้างทิ้ง ได้ผลลัพธ์เป็นเลขวง

เครื่องคุณใช้ mask ทำงานเดียว — เอาที่อยู่มา AND กับ mask ทีละบิต เพื่อหาว่าตัวเองอยู่วงไหน

192.168.1.134   11000000 10101000 00000001 10000110
255.255.255.0   11111111 11111111 11111111 00000000
                --------------------------------- AND
192.168.1.0     11000000 10101000 00000001 00000000

กฎของ AND คือได้ 1 ก็ต่อเมื่อทั้งสองฝั่งเป็น 1 ผลคือบิตที่ตรงกับ 1 ใน mask ถูกเก็บไว้ทั้งหมด ส่วนบิตที่ตรงกับ 0 ถูกล้างเป็นศูนย์

จากนั้นเครื่องทำแบบเดียวกันกับปลายทางที่จะส่งไป

ได้เลขวงเท่ากัน → อยู่วงเดียวกัน ส่งตรงไปหาได้เลย
ได้เลขวงไม่เท่ากัน → คนละวง ต้องส่งให้เกตเวย์

ทั้งหมดของ subnet mask คือประโยคนี้ประโยคเดียว ที่เหลือในหน้านี้เป็น ผลพวงจากมัน

สิงหาคม 1985 — และเหตุผลที่ไม่ใช่เรื่องเลขหมด

subnet นิยามไว้ใน RFC 950 เขียนโดย Jeff Mogul จากสแตนฟอร์ด กับ Jon Postel จาก ISI เผยแพร่เดือนสิงหาคม 1985

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

ก่อนหน้านั้น องค์กรที่มีเครือข่ายภายในหลายวงต้องขอเลขวงแยกกันทุกวง และเลขวงทุกเลขนั้นต้องถูกประกาศออกไปทั่วอินเทอร์เน็ต RFC 950 เขียนว่า วิธีนั้น "ทำให้ขนาดของตารางเส้นทางในอินเทอร์เน็ตระเบิด"

โครงสร้างภายในองค์กรไม่ได้มีประโยชน์กับใครข้างนอกเลย แต่กลับต้องถูกกระจาย ไปให้ทุกเราเตอร์บนโลกจำ

subnet แก้ปัญหานี้ด้วยการให้องค์กรได้เลขวงเดียว แล้วแบ่งย่อยกันเองข้างใน โดยข้างนอกไม่ต้องรู้ ทั้งองค์กรปรากฏต่อโลกภายนอกเป็นรายการเดียว

น่าสังเกตว่าแรงกดดันเดียวกันนี้กลับมาอีกครั้งในอีกแปดปีต่อมา และคำตอบรอบนั้น คือ CIDR

แนวคิดการออกแบบ — ทำไมต้องเป็นเส้นแบ่งบิต

1. เพราะการรวมเส้นทางต้องอาศัยมัน

ถ้าให้แบ่งวงเป็นช่วงตัวเลขอะไรก็ได้ เช่น "เครื่องหมายเลข 40 ถึง 190 คือวงหนึ่ง" เราเตอร์จะต้องเก็บทั้งเลขเริ่มและเลขจบของทุกวงบนโลก

แต่ถ้าบังคับให้เส้นแบ่งตกที่ขอบของบิตเสมอ หลายวงที่อยู่ติดกันจะยุบรวม เป็นรายการเดียวได้ทันที สี่วง /26 ที่ต่อกันคือ /24 หนึ่งวง สองวง /24 ที่ต่อกันคือ /23 หนึ่งวง

การยุบรวมนี้คือสิ่งที่ทำให้ตารางเส้นทางของอินเทอร์เน็ตยังมีขนาดที่จัดการได้ ทั้งที่มีเลขที่อยู่เป็นพันล้าน

2. บิตของ mask ไม่จำเป็นต้องติดกัน — ตามสเปกปี 1985

ข้อนี้แทบไม่มีใครรู้ RFC 950 เขียนไว้ว่า

บิตของ subnet ไม่จำเป็นต้องอยู่ติดกันในที่อยู่ อย่างไรก็ตาม เราแนะนำให้บิตของ subnet อยู่ติดกันและอยู่ในตำแหน่งบิตที่มีนัยสำคัญสูงสุด

แปลว่า mask แบบ 255.0.255.0 เคยถูกต้องตามมาตรฐาน มันแค่ถูกแนะนำว่า ไม่ควรทำ

ทุกวันนี้อุปกรณ์แทบทั้งหมดไม่ยอมรับ mask แบบนั้นแล้ว และ CIDR ก็ตัดความ เป็นไปได้นั้นทิ้งไปโดยสมบูรณ์ เพราะการเขียน /24 สื่อได้แค่บิตที่ติดกัน เท่านั้น — สัญกรณ์ที่เราใช้ทุกวันนี้บังคับความถูกต้องให้เราโดยที่เราไม่รู้ตัว

3. เลขแรกกับเลขสุดท้ายถูกกันไว้ตั้งแต่ต้น

RFC 950 ระบุว่า "ค่าที่เป็นศูนย์ทั้งหมดและหนึ่งทั้งหมดในส่วนของ subnet ไม่ควรถูกกำหนดให้กับ subnet จริง"

นั่นคือที่มาของกฎที่ทุกคนท่องกันว่าเลขแรกคือเลขวง เลขสุดท้ายคือ broadcast และใช้กับเครื่องไม่ได้ — ซึ่งมีข้อยกเว้นที่สำคัญมากอยู่สองข้อ อยู่ในหัวข้อถัดไป

ก่อนปี 1993 เส้นแบ่งมีให้เลือกแค่สามที่

ระบบคลาสกำหนดเส้นแบ่งไว้ตายตัวที่บิตที่ 8 16 และ 24 องค์กรที่ต้องการ 400 เลขจึงต้องเลือกระหว่างน้อยเกินไปกับมากเกินไป

เดิม IP แบ่งที่อยู่เป็นคลาสตามบิตแรก ๆ และแต่ละคลาสมีเส้นแบ่งตายตัว

  Class A   วง 8 บิต    เครื่อง 24 บิต   16,777,214 เลขต่อวง
  Class B   วง 16 บิต   เครื่อง 16 บิต   65,534 เลขต่อวง
  Class C   วง 24 บิต   เครื่อง 8 บิต    254 เลขต่อวง

องค์กรที่ต้องการ 400 เลขจึงมีทางเลือกสองทางที่แย่ทั้งคู่ — ขอ Class C ที่ให้ 254 ซึ่งไม่พอ หรือขอ Class B ที่ให้ 65,534 ซึ่งเหลือทิ้งไปหกหมื่นกว่าเลข

ผลคือช่วงต้นทศวรรษ 1990 เกิดวิกฤตสองอย่างพร้อมกัน — Class B ใกล้หมด และตารางเส้นทางโตเร็วเกินกว่าอุปกรณ์จะรับไหว

CIDR เข้ามาแก้ด้วยการทิ้งระบบคลาสไปเลย แล้วให้เส้นแบ่งอยู่ที่บิตไหนก็ได้ องค์กรที่ต้องการ 400 เลขจึงขอ /23 ซึ่งให้ 510 ได้ตรง ๆ

ทุกวันนี้คำว่า Class A/B/C ไม่มีความหมายทางเทคนิคแล้ว เหลือเป็นแค่คำที่คน ยังติดปาก และการพูดว่า "วงนี้เป็น Class C" มักหมายถึงแค่ "เป็น /24"

ข้างในวงหนึ่งวงมีอะไร

ในหนึ่งวงมีเลขแรกที่เป็นชื่อของวงเอง ช่วงกลางที่ใช้กับเครื่องได้ และเลขสุดท้ายที่เป็น broadcast

  192.168.1.0/24
    192.168.1.0     เลขวง — ชื่อของวงเอง ไม่ใช่ของเครื่องไหน
    192.168.1.1     เลขแรกที่ใช้กับเครื่องได้
    192.168.1.254   เลขสุดท้ายที่ใช้กับเครื่องได้
    192.168.1.255   broadcast — หมายถึงทุกเครื่องในวงพร้อมกัน

ทั้งหมด 256 เลข ใช้กับเครื่องได้ 254

สูตรคือ จำนวนเลขทั้งหมดเท่ากับ 2 ยกกำลังจำนวนบิตที่เหลือ แล้วลบสอง

  /24   2^8  = 256    ใช้ได้ 254
  /25   2^7  = 128    ใช้ได้ 126
  /26   2^6  = 64     ใช้ได้ 62
  /27   2^5  = 32     ใช้ได้ 30
  /28   2^4  = 16     ใช้ได้ 14
  /29   2^3  = 8      ใช้ได้ 6
  /30   2^2  = 4      ใช้ได้ 2

ข้อที่มองข้ามบ่อย — ยิ่งแบ่งย่อย ยิ่งเสียเลขรวมมากขึ้น เพราะทุกวงย่อย ต้องเสียเลขหัวและเลขท้ายของตัวเอง แบ่ง /24 เป็นสี่วง /26 จะเหลือใช้ได้ 62×4 = 248 แทนที่จะเป็น 254 หายไปหกเลขเพียงเพราะการแบ่ง

เส้นแบ่งเลื่อนได้ทีละบิต

แถบแสดงการแบ่งบิต 32 ตัว ยิ่งให้บิตกับส่วนวงมากขึ้น เลขที่เหลือให้เครื่องยิ่งน้อยลงครึ่งหนึ่งทุกครั้ง

เลื่อนเส้นแบ่งไปขวาหนึ่งบิต จำนวนเลขในวงหายไปครึ่งหนึ่ง และได้วงเพิ่มมาอีกวง

  /24   หนึ่งวง   .0 – .255
  /25   สองวง     .0 – .127     .128 – .255
  /26   สี่วง     .0 – .63      .64 – .127
                  .128 – .191   .192 – .255

เส้นแบ่งต้องตกที่ขอบของขนาดตัวเองเสมอ วง /26 มี 64 เลข จึงเริ่มได้ เฉพาะที่เลขซึ่งหารด้วย 64 ลงตัวคือ .0 .64 .128 .192 เท่านั้น เขียน 192.168.1.130/26 ก็ได้ แต่ความหมายคือเครื่องหมายเลข 130 ที่อยู่ในวง 192.168.1.128/26 ไม่ใช่วงที่เริ่มที่ 130

VLSM — วงในวงเดียวกันไม่ต้องขนาดเท่ากัน

หนึ่งวง /24 ถูกแบ่งเป็น /25 หนึ่งวง /26 หนึ่งวง และ /27 สองวง โดยความกว้างเป็นสัดส่วนกับจำนวนเลขจริง

ก่อนปี 1985 ทั้งองค์กรใช้ mask เดียวได้เท่านั้น ทุกวงจึงต้องขนาดเท่ากันหมด แม้บางวงจะมีเครื่องสามตัวก็ตาม

VLSM คือการยอมให้แต่ละวงมี mask ของตัวเอง แบ่ง 192.168.10.0/24 ได้แบบนี้

  192.168.10.0/25     .0   – .127   ใช้ได้ 126   ฝ่ายที่คนเยอะ
  192.168.10.128/26   .128 – .191   ใช้ได้ 62    ฝ่ายขนาดกลาง
  192.168.10.192/27   .192 – .223   ใช้ได้ 30    ห้องเซิร์ฟเวอร์
  192.168.10.224/27   .224 – .255   ใช้ได้ 30    เผื่อไว้
                                    รวม 256 เลขพอดี

กฎการแบ่งคือเริ่มจากวงใหญ่ที่สุดก่อนเสมอ ถ้าจัดวงเล็กลงไปก่อน จะเหลือช่องว่างที่กระจัดกระจายจนวางวงใหญ่ไม่ลง ทั้งที่จำนวนเลขรวมยังพอ

กรณีพิเศษที่กฎเลขแรกเลขสุดท้ายใช้ไม่ได้

ลิงก์ระหว่างเราเตอร์สองตัวใช้ /30 จะเสียเลขไปครึ่งหนึ่ง แต่ใช้ /31 ได้เลขทั้งสองเป็นโฮสต์

/31 บนลิงก์ระหว่างอุปกรณ์สองตัว

ลิงก์ระหว่างเราเตอร์สองตัวต้องการเลขแค่สอง แต่ถ้าใช้ /30 ต้องจองสี่เลขเพื่อให้ได้สองเลขที่ใช้ได้ — เสียเปล่าครึ่งหนึ่ง

RFC 3021 ปี 2000 แก้เรื่องนี้ด้วยการอนุญาตให้ใช้ /31 บนลิงก์แบบ สองจุด เหตุผลคือลิงก์แบบนี้ "ไม่มีแนวคิดเรื่อง broadcast" อยู่แล้ว เพราะมีปลายทางที่เป็นไปได้อยู่ตัวเดียว จึงไม่ต้องกันเลขไว้ทำ broadcast

เอกสารระบุว่าทั้งสองเลขใน /31 ต้องถูกตีความเป็นเลขของเครื่อง และยกตัวอย่างว่าเครือข่ายที่มีลิงก์แบบนี้ 500 เส้น จะประหยัดได้ 1000 เลข

/32 และ /0

/32 คือวงที่มีเลขเดียว ใช้กับลูปแบ็กของอุปกรณ์และกับเส้นทางที่ชี้ไป เครื่องเดียวเจาะจง ที่นี่กฎเลขแรกเลขสุดท้ายไม่มีความหมายเลย เพราะมีเลขอยู่ตัวเดียว

/0 คือ mask ที่ไม่มีบิต 1 เลย แปลว่า "ทุกที่อยู่บนโลก" ซึ่งก็คือ เส้นทางค่าเริ่มต้น 0.0.0.0/0 ที่อธิบายไว้ในบทความ Internet Protocol

เมื่อตรงกันหลายเส้น ใครชนะ

ปลายทางหนึ่งตรงกับสี่เส้นทางพร้อมกัน และเส้นที่มี prefix ยาวที่สุดชนะ

ปลายทาง 10.20.30.40 ตรงกับทั้งสี่เส้นนี้พร้อมกัน

  0.0.0.0/0        ตรง   เจาะจงน้อยที่สุด
  10.0.0.0/8       ตรง
  10.20.0.0/16     ตรง
  10.20.30.0/24    ตรง   ยาวที่สุด จึงชนะ

กฎมีข้อเดียวคือ prefix ยาวที่สุดชนะ ไม่เกี่ยวกับลำดับในตาราง ไม่เกี่ยวกับว่าใครถูกใส่ก่อน และไม่เกี่ยวกับค่า metric ใด ๆ ทั้งสิ้น ในขั้นตอนนี้

ปัญหาเกิดเมื่อมีสองเส้นที่ยาวเท่ากันและทับกันพอดี ซึ่งเป็นสิ่งที่เกิดขึ้น ตอนต่อ VPN แล้วเน็ตที่บ้านใช้วงเดียวกับที่ออฟฟิศ

ความเชื่อที่ผิด

"เลขแรกกับเลขสุดท้ายใช้ไม่ได้เสมอ" — ไม่จริงสำหรับ /31 และ /32

"/24 เป็นค่ามาตรฐาน" — ไม่มีอะไรพิเศษเลย มันแค่ตรงกับขอบไบต์พอดี คนเลยคำนวณง่ายและคุ้นเคย ในเครือข่ายจริงที่ออกแบบดี ๆ จะเห็น /23 /26 /29 เต็มไปหมด

"วงนี้เป็น Class C" — ระบบคลาสตายไปตั้งแต่ปี 1993 ประโยคนี้แปลว่า "เป็น /24" เท่านั้น และการคิดแบบคลาสจริง ๆ จะทำให้เข้าใจ CIDR ผิด

"192.168.x.x คือเลขที่ใช้ในบ้าน" — เลขวงส่วนตัวมีสามช่วงคือ 10.0.0.0/8, 172.16.0.0/12 และ 192.168.0.0/16 ช่วงกลางถูกลืมบ่อยที่สุด และการจำผิดว่าเป็น 172.x.x.x ทั้งหมดทำให้เขียนกฎไฟร์วอลล์ผิดได้

"เลขที่ลงท้ายด้วย .0 คือเลขวงเสมอ" — จริงเฉพาะเมื่อ mask เป็น /24 ถ้าเป็น /20 เลขวงคือเลขที่หารด้วย 16 ลงตัวในออกเตตที่สาม เช่น 10.20.30.40/20 อยู่ในวง 10.20.16.0/20 ไม่ใช่ 10.20.30.0

ตัวอย่างจริงจากงานจริง

กรณีที่ 1 — คุยกันได้ทางเดียว

เครื่อง A ตั้ง 192.168.1.10/24 เครื่อง B ตั้ง 192.168.1.200/25 อยู่บนสวิตช์ตัวเดียวกัน

อ่านอย่างไร ทำ AND ทั้งสองฝั่งเพื่อดูว่าแต่ละเครื่องคิดยังไง

  A มองปลายทาง .200 :  .200 AND /24  = 192.168.1.0   = วงเดียวกับ A
                        → A ส่งตรงหา B
  B มองปลายทาง .10  :  .10  AND /25  = 192.168.1.0
                        B เองอยู่วง   192.168.1.128
                        → คนละวง B ส่งให้เกตเวย์แทน

A ส่งตรงถึง B ได้ แต่ B ตอบกลับผ่านเกตเวย์ ซึ่งอาจไม่มีเส้นทางกลับมา อาการที่เห็นคือ ping ไปทางเดียวได้ อีกทางไม่ได้

สิ่งที่ยังไม่ได้พิสูจน์ ยังไม่รู้ว่าเครื่องไหนตั้งผิด ต้องดูเอกสาร ออกแบบวงก่อนว่าตั้งใจให้เป็น /24 หรือ /25

กรณีที่ 2 — เลขวงที่ไม่ได้ลงท้ายด้วยศูนย์อย่างที่คิด

$ ipcalc 10.20.30.40/20 2>/dev/null || python3 -c "
import ipaddress as i
n = i.ip_interface('10.20.30.40/20').network
print(n, n.network_address, n.broadcast_address, n.num_addresses)"
10.20.16.0/20 10.20.16.0 10.20.31.255 4096

อ่านอย่างไร หลายคนเดาว่าวงคือ 10.20.30.0 แต่ /20 แบ่งออกเตตที่สาม กลางคัน วงจึงมีขนาด 16 ในออกเตตนั้น และเริ่มที่เลขที่หารด้วย 16 ลงตัว เลข 30 ตกอยู่ในช่วง 16 ถึง 31

นี่คือกับดักที่ทำให้เขียนกฎไฟร์วอลล์หรือ ACL ผิดบ่อยที่สุด เพราะคนเขียนคิดว่ากำลังอนุญาตวงหนึ่ง แต่จริง ๆ อนุญาตอีกวงหนึ่ง

สิ่งที่ยังไม่ได้พิสูจน์ การคำนวณถูกต้องไม่ได้แปลว่าค่าที่ตั้งไว้บนอุปกรณ์ ตรงกับที่ออกแบบ ต้องไปดูของจริงบนอุปกรณ์ด้วย

กรณีที่ 3 — VPN ที่ทำให้เน็ตที่บ้านหาย

ออฟฟิศใช้ 192.168.1.0/24 และเน็ตที่บ้านของพนักงานก็ใช้ 192.168.1.0/24

อ่านอย่างไร เมื่อต่อ VPN เครื่องจะมีสองเส้นทางที่ยาวเท่ากันและทับกันพอดี กฎ prefix ยาวที่สุดตัดสินไม่ได้ ผลจะขึ้นกับว่าซอฟต์แวร์ VPN ใส่เส้นทางแบบไหน

อาการที่เห็นได้บ่อยคือต่อ VPN แล้วเข้าเราเตอร์ที่บ้านไม่ได้ หรือหนักกว่านั้น คือเข้าออฟฟิศไม่ได้ทั้งที่ VPN ขึ้นแล้ว

$ netstat -rn -f inet | grep 192.168.1

ดูตอนต่อ VPN อยู่จริงว่ามีกี่เส้นและชี้ไปไหนบ้าง

วิธีเลี่ยง องค์กรควรหลบช่วงยอดนิยมอย่าง 192.168.0.0/24 กับ 192.168.1.0/24 แล้วเลือกช่วงที่คนใช้น้อยใน 10.0.0.0/8 เช่น 10.73.42.0/24 ซึ่งโอกาสชนกับเน็ตที่บ้านใครแทบเป็นศูนย์

สิ่งที่ยังไม่ได้พิสูจน์ ยังไม่รู้ว่าซอฟต์แวร์ VPN ตัวนั้นจัดการอย่างไร บางตัวใส่เส้นทางที่เจาะจงกว่าเพื่อแย่งชนะ ต้องดูของจริงขณะต่ออยู่

กรณีที่ 4 — วงเล็กเกินไปจนขยายไม่ได้

ห้องเซิร์ฟเวอร์ตั้งเป็น /29 ได้ 6 เลข ใช้ไป 6 พอดี วันหนึ่งต้องเพิ่มเครื่อง

อ่านอย่างไร จะขยายเป็น /28 ได้ต้องมีเลขต่อจากวงเดิมว่างอยู่ และ วงเดิมต้องเริ่มที่ขอบของ /28 พอดีด้วย

  10.0.0.8/29    →  ขยายเป็น /28 ไม่ได้
                    เพราะ /28 ต้องเริ่มที่ .0 หรือ .16
  10.0.0.16/29   →  ขยายเป็น 10.0.0.16/28 ได้
                    ถ้า .24 – .31 ยังว่าง

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

สิ่งที่ยังไม่ได้พิสูจน์ ยังไม่รู้ว่าเลขที่อยู่ถัดไปว่างจริงหรือไม่ ต้องตรวจกับเอกสารการจัดสรรเลขขององค์กร

เมื่อคำนวณเองไม่ไหว

ipcalc หรือ sipcalc — คำนวณให้ครบทุกค่าในคำสั่งเดียว
python3 -c "import ipaddress ..." — มีอยู่แล้วในเครื่องส่วนใหญ่ และเชื่อถือได้กว่าการคำนวณด้วยมือ
ip route get <ปลายทาง> — ถามเครื่องตรง ๆ ว่าจะส่งออกทางไหน ซึ่งตอบคำถามที่แท้จริงได้ดีกว่าการเดาจาก mask
เอกสารการจัดสรรเลขขององค์กร — เครื่องมือที่สำคัญที่สุดในรายการนี้ และเป็นตัวเดียวที่ไม่ได้อยู่ในคอมพิวเตอร์

255.255.255.0 ไม่ใช่ตัวเลข มันคือเส้นแบ่ง และมันตอบคำถามเดียวคือ ปลายทางอยู่วงเดียวกับฉันหรือเปล่า

ทุกอย่างที่เหลือ — การแบ่งย่อย การรวมเส้นทาง กฎ prefix ยาวที่สุด และกรณีพิเศษทั้งหมด — เป็นผลพวงจากการตัดสินใจครั้งเดียวเมื่อปี 1985 ว่าจะให้เส้นแบ่งนั้นเลื่อนได้

อ้างอิง

เอกสารมาตรฐาน

RFC 950 — Internet Standard Subnetting Procedure J. Mogul และ J. Postel, สิงหาคม 1985 — ที่มาของ subnet ทั้งหมด รวมถึง เหตุผลเรื่องขนาดตารางเส้นทาง กฎเลขแรกเลขสุดท้าย และข้อที่ว่าบิตของ mask ไม่จำเป็นต้องติดกัน
RFC 4632 — CIDR: The Internet Address Assignment and Aggregation Plan แทนที่ RFC 1519 — การเลิกใช้ระบบคลาสและการรวมเส้นทาง
RFC 3021 — Using 31-Bit Prefixes on IPv4 Point-to-Point Links A. Retana, R. White, V. Fuller, D. McPherson, ธันวาคม 2000
RFC 1918 — Address Allocation for Private Internets ที่มาของสามช่วงส่วนตัว
RFC 6890 — Special-Purpose IP Address Registries รายการเลขที่ถูกกันไว้ทั้งหมด
RFC 791 — Internet Protocol ต้นทางของระบบคลาสที่ CIDR มาแทนที่ในภายหลัง

คู่มือ

man ifconfig บนแมค ซึ่งเขียน mask เป็นเลขฐานสิบหก และ man ip บนลินุกซ์ ซึ่งเขียนเป็นความยาว prefix — สองวิธีที่บอกความจริงตรงกว่าเลขสี่ชุด
man ipcalc ถ้าติดตั้งไว้

อ่านหน้านี้เป็นภาษาอังกฤษ

← กลับไปหน้าความรู้พื้นฐาน