0

In theory, can a subnet mask have zeros between ones (e.g. 255.255.0.248) or it need to be strictly 1's followed by 0's?

As stated in RFC 950, there is only an "example" to interpret an IP as <network-number><subnet-number><host-number> (see 2.1). And in the pseudo-code given in 2.2:

IF bitwise_and(dg.ip_dest, my_ip_mask)
                               = bitwise_and(my_ip_addr, my_ip_mask)
         THEN
             send_dg_locally(dg, dg.ip_dest)
         ELSE
             send_dg_locally(dg,
                    gateway_to(bitwise_and(dg.ip_dest, my_ip_mask)))

This seems to work with both cases as well.

My NE teacher says masks like 255.255.0.248 "are correct but not used commonly". So I'm asking here after digging around Internet with null result.

Improve this question
0

2 Answers 2

Reset to default
4

For a network, the mask needs to be contiguous. Some vendors allow you to specify a prefix length instead of a mask. The prefix length denotes the number of leftmost bits set to 1 in the mask, so a prefix length of 24 denotes a mask of 255.255.255.0. Prefix lengths are contiguous and there is no way to specify a non-contiguous mask. Some routing protocols such as BGP use prefix length (and not mask) within the updates, so there is no way to even advertise a non-contiguous mask with BGP.

Wildcard masks used in ACLs are similar to inverse subnet masks. Their job is to show which bits of an address are relevant. It is perfectly OK to use non-contiguous bits in a wildcard masks. Wildcard masks are not subnet masks though and cannot be used when specifying a network on an interface configuration

Also, see https://superuser.com/questions/979915/are-subnets-always-contiguous-1s for more answers

Improve this answer
3
  • If we are only considering theory here, I think that while the prefix length concept implicitly makes a subnet mask all ones and therefore contiguous, there is nothing that prevents someone refusing to go the CIDR path and coming up with a mask that is non-contiguous. It would be operationally nutty, but I don't see that the rfcs ban it. And if you start to think about routing summarization across physically discontigous networks, there might even be a case for using one. I certainly would not do it myself as it would be a maintenance nightmare but that's not what the OP is asking.
    – AlwaysLearning
    Commented Nov 26, 2016 at 3:11
  • Hi, yes technically you could write your own code that would support non-contiguous masks. What we see in real world network and client operating systems is that only contiguous ones are supported. BGP definitely doesn't support non-contiguous masks and potentially vendor implementations of IGPs may not support them (would need testing). Would be interesting to test though.
    – user27899
    Commented Nov 26, 2016 at 9:35
  • Also, RFC 950 recommends that the bits should be contiguous: Since the bits that identify the subnet are specified by a bitmask, they need not be adjacent in the address. However, we recommend that the subnet bits be contiguous and located as the most significant bits of the local address.
    – user27899
    Commented Nov 26, 2016 at 9:48
1

Yes. This can be done and does work on a number of Cisco platforms. It is specifically applicable in access control situations (traffic filters, route distribution control, etc). It is not supported for interface addressing.

That said, it's not very readable and - in my experience, is usually a way to save a few lines of ACL and is a classic example of how preoptimization is the root of all evil.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.