是否有太多的IP地址?


8

我们已经在办公室里进行了一次小型辩论,而现在我已经不再需要技术知识了。

是否有太多的IP地址?我不建议我们使用整个私有的10. * A类,但是我不明白为什么我们也不能这样做。

老实说,“子网碎片化”是一种过时的思维方式,但是我想继续进行技术讨论。

当前,我们的主要子网掩码配置为使用4个B类,对于我们的小型企业而言,就可用IP地址的绝对数量而言,这是过大的选择。

但是问题是,拥有广泛的私有IP空间会带来什么问题(如果有的话)?


1
十年来没有使用A / B / C / D类吗?这是您的第一个弹药:)
马克·亨德森

我糊涂了。我认为CIDR完全盛行,在过去十年中更是如此。也许我应该停止讲A / B / C / D课,而开始讲/ 8,/ 16,/ 24,/ 32?(我以为他们是同一回事,但也许那是我自己的错误。)
VxJasonxV

1
D类= / = / 32。我只是在说:)大多数人都知道您说“ A类”的意思,但是从技术上讲,它是指以00二进制开头的IP,而不是给定大小的网络。我通常说“ Slash 8”。
比尔·魏斯

Answers:


5

不可能遵守各种标准,保护网络变得更加困难,病毒更容易传播,服务质量变得更加困难,MAC / CAM表已满。

仅仅将所有内容混入一个存储桶中仍然存在各种各样的问题。

同样不要忘记,随着LAN速度的提高,其用途也会增加。特别是对于数据中心。许多地方的干线利用率达到50%以上。我已经看到一些在10gig中继线上连续运行超过65%的设备。告诉那些人增加不必要的流量。

如果您是一个很小的地方,实际上不需要两个以上的VLAN,那么除了“可以”之外,无条件地使用大型子网是可以的。离开小型企业世界后,您会发现事情的复杂性大大增加了。

另一个明显的原因是要阻止CAM表的填充,这可能会造成中断,具体取决于固件中对开关表填充如何处理的实现。


9

唯一的问题是在连接到合作伙伴的网络或合并/收购期间可能发生冲突。通过在边缘设备上使用源和目标NAT,可以缓解其中的某些问题。另外,仅仅因为您使用10.1.0.0/24并不意味着您不会遇到完全相同的问题。


1
为了安全起见,它也非常不错。更不用说您最终将继续进行过多的广播。随着交换机速度的提高和“需求的消失”,我们也越来越重视LAN始终保持正常运行。
sclarson

5

并非如此-只要您将实际设备的数量限制在网络可以处理的范围内...但是,如果您不使用所有节点,为什么还要在网络中拥有如此众多的节点呢?

分段网络在很多方面都有好处,包括提供逻辑结构和概述,通过将角色和/或位置分成不同的网络来加强安全性等等。

人们通常不会想到的一件事是将打印机和其他高度脆弱且不受保护的网络设备拆分为自己的网络-只能访问特定的打印服务器。然后,根据您的组织对信息安全的要求,通常会有所有这些。

安全性是随层而来的,网络分段是许多帮助之一,它们可以使内容免遭安全性问题(=访问,完整性和可用性)的侵害。


2
我普遍同意。除非有流量问题或需要过滤流量,否则我不会通过子网“逻辑地”组织设备。有趣的是,您提到将打印机置于带有受限访问权限的隔离第2层中。多年来,我一直试图将这种方法传播给人们,并获得不同程度的成功。一些(通常是非IT部门)处于权威位置的人暗中信任打印输出。这样,可能的“社会工程学”技巧将涉及修改/伪造打印输出。有没有听说过犯人因伪造的传真而被释放出监狱?它发生了!
埃文·安德森

我什至从未听说过有一名囚犯因传真而被释放。必须是本地问题。;)
John Gardeniers 2009年

好吧,这两个分别来自佛罗里达州和肯塔基州,所以我敢肯定有一些当地影响力... 呵呵 ... heraldtribune.com/article/20090716/ARTICLE/…freerepublic.com/focus/f-news / 1821482 / posts
Evan Anderson

1
Fark有一个专门的“佛罗里达”类别FWIW是有原因的。
VxJasonxV

哦,是的,恩。对肯塔基州的评论无评论; D.
VxJasonxV'2009年

2

我看到的许多IP的问题并不限制广播域。另一方面,对于1Gb交换机,除非您试图挖掘交换机和防火墙日志,否则我真的不能再这么说了。


1

除了与通过VPN连接的合作伙伴网络存在潜在冲突之外,没有任何问题。

我通常建议无论如何都要使用/ 24块,无论您要分割它们的范围如何。因此,假设您为办公室分配了10.27.1 / 24,为数据中心的DB子网分配了10.27.2 / 24,为数据中心的apps子网分配了10.27.3 / 24,为VPN分配了10.27.100 / 24客户,等等。


1
现在,这听起来像是毫无理由的额外工作,同时还会给第3层设备增加额外的负载。
Doug Luxem

1
是2009年;除非你过度矫kill过正,否则这不是问题。
duffbeer703

1
@DLux我假设使用路由网络,而不是平面拓扑。看一下我给出的示例,这些示例通常是物理上分离的网络,并且在它们之间进行路由。如果它是扁平的,那么您不必对其进行分段(但是如果您选择这样做,则仍然可以)。
Florin Andrei,2009年

1
我明白你现在在说什么。:)通常,我会在安全分区/区域中划分子网,这与您所说的差不多。
Doug Luxem

2
划分交换式以太网LAN的子网只有两个原因:缓解性能问题(过多的广播流量或将帧泛洪到未知目的地),或在路由器在其间移动数据包的“阻塞点”的第3层或更高层施加数据包过滤功能。子网(通常用于安全性)。任何其他原因(出于审美目的,主要是-“我希望所有xxx计算机都位于同一子网中,因为它看起来不错...”)是无效的原因。
埃文·安德森

1

取决于子网广播的大小,可能会出现问题,尽管取决于网络的速度,但这可能不是问题。

但是,缺点之一是限制了将来的扩展能力。您现在可能只需要一个子网,但是谁又说您将来将不需要更多子网呢?您可能会扩展,可能想为网络的某些部分设置单独的子网,依此类推。

我还将放弃“类”的思考,并将CIDR用于您的子网。在大学课程和历史书籍之外的课程已经不存在了,CIDR可以为您提供更大的灵活性。

这些事情的一个很好的经验法则是将您认为需要的东西加倍,因此,如果您有50台主机(并且不要忘记在此处包括服务器,打印机,交换机等),则使用25位网络掩码(可以为您提供) 128台主机,少2台用于网络和广播)将满足您的需求,并为您留出一些空间。


0

好吧,连接到您的Uber-IP服务器的Switch的ARP表中确实有有限数量的条目。同样,您会在Broadcast Domin上看到很多免费的ARP。


1
....并且swicthes不做ARP
哈维尔

1
如果可以的话,我会给你们两个代表。实际上,我支持DLux,所以我想我可以。当人们要说“桥接/ MAC表”时,我对听到有关交换机和“ ARP表”的消息感到厌烦。
埃文·安德森

2
@sparks:第3层设备具有ARP表。严格在第2层运行的交换机没有ARP表。如果交换机具有在第3层进行通信的管理接口或路由引擎,则这些设备将具有ARP表。
埃文·安德森

1
我发现将“第3层交换机”解释为第2层交换机(我将其解释为多端口网桥)非常有用,其中隐藏了非常快的路由器。我尝试与交换功能分开解释路由功能。盒子可以做两种事情,但是盒子的不同部分可以做不同的事情。(某些旧的Catalyst管理器模块也是如此工作-SUP刀片上装有路由器硅片,并且它具有自己的管理接口。)
Evan Anderson,2009年

1
交换机是一个多端口网桥。最好将其上的所有内容理解为集成在同一盒中的单独设备
Javier

0

除了设置(以及可能要进行管理)稍微困难一点之外,我没有想到其他任何东西。然后是IP地址数量减少的问题(直到IPV6)。


“专用IP寻址”的说明以及使用10/14的示例使“ IP地址的减少量”变得无关紧要。
VxJasonxV

0

我继承的一个网络充满了/ 16s ..即10.1.xx,10.2.xx。

分组IP范围非常好,您可以查看IP并确切知道它是什么。.10.4.20.Xs都是数据库,等等...但是...

最终,我们不得不清理它,并且发现所有随机的IP都是一件繁琐的事情。

进行/ 24的nmap ping扫描比/ 16容易得多。

在重新设计中,我们定为/ 22s。(1024 ips)

我认为分配当前所需的一般规则以及健康的成长开销是一个好习惯。


0

我将从网络上可能存在的最大设备数量开始,然后将其增加一倍或两倍,然后查看我是否有足够的网络。通过使用TEN网络,不难找到平衡。例如,假设最多100个设备。如果您选择/ 22作为掩码,您将拥有16,384个网络,其中可能有1022个设备:

Mask:255.255.252.0   Host/Net - 1022
Network          Broadcast
10.0.0.0         10.0.3.255
10.0.4.0         10.0.7.255
10.0.8.0         10.0.11.255
10.0.12.0        10.0.15.255
10.0.16.0        10.0.19.255
10.0.20.0        10.0.23.255
10.0.24.0        10.0.27.255
10.0.28.0        10.0.31.255
10.0.32.0        10.0.35.255
10.0.36.0        10.0.39.255
10.0.40.0        10.0.43.255
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.