在最后一个八位字节中有0的IP地址是否有效?
10.6.43.0
在我的情况下,我有以下的networking掩码
255.255.252.0
那么对于其他八位字节呢?
这取决于有问题的IP地址的子网。 通常,子网中的第一个和最后一个地址分别用作networking标识符和广播地址。 子网中的所有其他地址都可以分配给该子网上的主机。
例如,子网掩码至less为24位,以.0或.255结尾的networking的IP地址永远不能分配给主机。 子网的这些“最后”地址被认为是“广播”地址,并且相应子网上的所有主机都会对其进行响应。
理论上,可能会出现以下情况:您可以分配以.0结尾的地址:例如,如果您有像192.168.0.0/255.255.0.0这样的子网,则可以分配主机地址192.168.1.0。 它可能会造成混乱,所以这不是一个普遍的做法。
在你的例子中
10.6.43.0 with subnet 255.255.252.0 (22 bit subnet mask)
意味着子网ID 10.6.40.0,主机地址范围从10.6.40.1到10.6.43.254,广播地址10.6.43.255。 所以在理论上,你的例子10.6.43.0将被允许作为有效的主机地址。
回答你的问题取决于networking掩码。 在一般声明中“以.0或.255结尾的IP地址是无效的”是错误的。 采取10.0.1.0/23 – 这是有效的IP地址。
也是10.6.43.0/255.255.252.0又名10.6.43.0/22是有效的。
那是理论。 最合理的networking设备[包括Linux服务器,windows box,cisco / hp / etc]可以正常工作,但是我看到dlink和其他低端networking设备[路由器,接入点]不接受这样的地址。
我发现这个,声称这是有效的,取决于你的子网掩码。
http://en.wikipedia.org/wiki/IPv4#Addresses_ending_in_0_or_255
我想为其他八位字节添加一个大约0:
这个很简单:完全没有问题,因为相当普通的私有networking地址192.168.0.1
显示。
当然,一个更明显的例子是127.0.0.1
。
如果远程networking拒绝来自我的networking的IP地址,如果它们以0(或255)结尾,并且它们来自C类范围,则会遇到问题,因为任何以0结尾的内容都将是无效的C类networking。
这是几年前, 我不知道是否有人仍然阻止这样的地址。
只是我发现这可能是值得注意的:
如果你正在为iptables运行R-fxnetworking的APF脚本,它将把所有的stream量都降到0.0.0.255
我们有一个BT客户,地址以.255结尾,前缀为/ 21 ..从技术上来说,这是一个有效的IP地址,但是R-fxnetworking的人认为这些地址有丢包的可能。