/24 为什么是 254 台
一句话总结
CIDR是写出IP地址的前几位比特是网络的表示法。 这个数字决定了该网络可以容纳多少台。
为什么需要这个？
创建VPC时10.0.0.0/16如果照样按照插入的指示操作的话，现在
可以。问题是2年后。
- 其他团队的VPC和地址重叠，无法配对。
- 与现场带宽重叠，无法连接VPN。
- 与收购的公司重叠，导致合并受阻。
地址范围**以后不能更改。**必须重新创建并移动所有资源。 所以一开始制定计划的价值比任何其他决定都大。
用比特计数的方法
IPv4地址是32位。/24前24位表示网络，
剩下的8位是主机位。
10.0.1.0/24
└─ 네트워크 24비트 ─┘└ 호스트 8비트 ┘
호스트 자리 = 32 − 24 = 8비트 → 2^8 = 256개 주소
有256个，为什么是254个呢？第一个地址是网络地址，最后一个是 不能写成广播地址。所以254。
云在这里减少了。 AWS为每个子网预约5个
（网络、VPC路由器、DNS、备用、广播）。所以/24子网的
实际可用IP是251个。不知道这个，计划250台的话就很危险了。
| CIDR | 全部地址 | AWS可用 |
|---|---|---|
| /28 | 16 | 11 |
| /27 | 32 | 27 |
| /26 | 64 | 59 |
| /24 | 256 | 251 |
| /22 | 1,024 | 1,019 |
| /20 | 4,096 | 4,091 |
| /16 | 65,536 | — (VPC最大) |
记住的诀窍：/24如果加是256，每次预处理器减少1个，就会翻倍。
/23= 512，/22= 1,024。相反，增加1就等于一半。
私人广播
只有RFC 1918规定的三个部分在内部编写。
| 带宽 | 尺寸 | 常见用途 |
|---|---|---|
10.0.0.0/8 |
1,677万 | 大型组织。大部分云VPC |
172.16.0.0/12 |
104万 | Docker基本桥在这里 |
192.168.0.0/16 |
6.5万 | 家庭用共享器 |
172.17.0.0/16这个坞口的基本桥带这一事实在实际工作中经常
发生事故——内部网络172.17.x.x用的话，在容器里用那个地址
不能去。
制定计划的顺序
- 大幅度设定整体预算——对整个组织
10.0.0.0/8分配 开始。地址是免费的。省钱不是好处。 - 按环境切割 — 运营
10.0.0.0/12，舞台布置10.16.0.0/12， 开发10.32.0.0/12不要像这样重叠。 - 按阵营切割 — 每个阵营都有不同的频段。以后阵营间的连接会更容易。
- VPC 足够 —
/16像这个基本值一样使用。6.5万地址一般就足够了。 - 子网根据用途——在下面详细介绍。
- 在文件中写上现场·合作伙伴代理—以后不能与要连接的带宽重叠。
重叠的话会发生什么事呢？
两个VPC是相同的10.0.0.0/16使用的话无法配对。路由
因为桌子不能把两个目的地送到两个地方。解决办法是把一边
只是搬到新的广播频率，实际上那是重建。
所以组织里必须要有IP带宽大队长。只要一张电子表格就行了。 足够，没有的话一定会发生事故。
快速计算的方法和犯错的地方
熟练计算CIDR只需几秒钟，不熟练的话每次都要找计算器。记住 只有两行。
地址数量是2^(32-prefix)./24有256个，/23银512个，/25有128个。
如果prefix是1行的话，就会翻倍。
边界只从那个大小的排水开始。/24第三个四重奏无论什么价值都可以，
/23第二，第三个四重奏必须是偶数，/22必须是4的倍数。
10.0.3.0/23是错误的标记，实际上是10.0.2.0/23意味着。这就是
这是最常见的错误。
| 前缀 | 地址数 | 可以成为第三个四元组的值 |
|---|---|---|
| /24 | 256 | 任意值 |
| /23 | 512 | 0, 2, 4, … |
| /22 | 1024 | 0, 4, 8, … |
| /20 | 4096 | 0, 16, 32, … |
**云会前后带走几个。**大多数云每个子网带走5个
预约（网络地址、网关、DNS、备用、广播）。/28有16个
可以使用的有11个。分割小的子网，这个损失比例就越大。
为了看是否重叠，用大边的预剪裁切掉。10.1.0.0/16科
10.1.128.0/17是否重叠，把后面的东西/16用剪刀剪掉10.1.0.0这个会出来吗
看就可以了。出来的话会重叠。
python3 -c "
import ipaddress as ip
a = ip.ip_network('10.1.0.0/16'); b = ip.ip_network('10.1.128.0/17')
print(a.overlaps(b), list(a.subnets(new_prefix=18))[:2])"
留在计划书中的是规则，而不是替补。“哪个团队使用哪个替补” 票很快就会变旧。“每个阵营/16，每个AZ/20，每个用途/24”就像下一个人一样 写下自己可以选择的规则的话，即使不看表也不会发生冲突。
在现场相遇的样子
- 两队各自
10.0.0.0/16创建了VPC，1年后，当要连接两个服务时，被拒绝配对。重建了其中一个作为新的带宽。 - 内部网络
172.17.x.x在使用的公司，只有在容器中才能使用内部API。因为与docker基本桥接重叠，症状只在容器中出现，花了几天时间才找到原因。 - 子网
/28剪成好看的形状后，随着帕德的增长，IP变薄了。看起来有16个，但实际能用的只有11个。 - 收购的公司和代接公司重叠，系统整合推迟了半年。如果只有一张电子表格就从一开始就能避免。
下次要看的
将VPC内部分成子网，决定将什么放在哪里。