DSL, Cable, and another Cable Connection Question
-
RFC-1918 stipulates 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. All of the subnets you enumerated end up in 172.16.0.0 after applying the /16 mask.
-
So my internal network should be as follows:
Internal: 172.16.1.x/255.240.0.0
WAN1: 172.16.2.x/255.240.0.0
WAN2: 172.16.3.x/255.240.0.0
Or, do I need to break it down further?
-
You're still not quite getting it. /12 means the upper twelve bits of the network address are significant. You need to make the second octet unique in the range of 16-31. e.g. that block of private IP is in the range of 172.16.0.0/12 to 172.31.0.0/12. So for example, 172.16.0.0/12, 172.17.0.0/12 and 172.18.0.0/12.
-
Sad that I have forgotten as much as I have….
172.16.x.x = 10101100.00010000.x.x
... meaning
From here > 0001| < To here -- is usable -- 0001, 0010, 0011, etc.
So, for my subnet mask I would use 255.240.0.0 to reflect this?
Eg:
172.16.1.x/255.240.0.0 for Internal.
172.17.1.x/255.240.0.0 for WAN1
172.18.1.x/255.240.0.0 for WAN2Forgive how much I have forgotten here.
Thanks
-
Yes, this should work :)
-
Could I continue to use /16 – so much easier? 8)
Again, thank-you for the quick and positive responses, even to stupid questions I really should have known the answer to (/me looks at Cisco certs and shakes fist) -
Sure, as long as you keep the upper 16 bits unique. BTW, this pain is one reason I hate the 172.16-31 address block :) I always use either 10.x.x.x or 192.168.x.x :)
-
Thanks – never been a fan either.
However, the company I work uses both the 192.168.x.x and 10.x.x.x ranges so the VPN application pukes when I try to connect.
Ty, I'll make these changes and get back to you with (hopefully positive) results.
-
Keep us posted…
-
Could I continue to use /16 – so much easier? 8)
Again, thank-you for the quick and positive responses, even to stupid questions I really should have known the answer to (/me looks at Cisco certs and shakes fist)You could just use /24 instead and be done with it - that gives you 3 unique networks (172.16.1.0/24, 172.16.2.0/24 and 172.16.3.0/24). I'm not sure why danswartz is so tied to it having to be treated as a single /12 - the whole point of CIDR is that you don't need to do that.
I'd also point out that 172.16/12 covers 172.16.0.0 to 172.31.255.255 as a single network. The examples he provided of 172.16.0.0/12, 172.17.0.0/12 and 172.18.0.0/12 are all the same network - 172.16.0.0/12:
172.016.000.000 - 10101100.00010000.00000000.00000000
255.240.000.000 - 11111111.11110000.00000000.00000000
network - 10101100.00010000.00000000.00000000 (172.16.0.0)172.018.000.000 - 10101100.00010010.00000000.00000000
255.240.000.000 - 11111111.11110000.00000000.00000000
network - 10101100.00010000.00000000.00000000 (172.16.0.0) -
Havoc, you misunderstood my point. I was not advocating for /12 or anything else, just pointing out that the /12 defines the RFC-1918 network range (one of the three, at any rate.) Certainly he can subnet it as he wishes, as long as his netmask is correct.
-
Your posts were very confusing on that point, particularly here:@danswartz:
You're still not quite getting it. /12 means the upper twelve bits of the network address are significant. You need to make the second octet unique in the range of 16-31. e.g. that block of private IP is in the range of 172.16.0.0/12 to 172.31.0.0/12. So for example, 172.16.0.0/12, 172.17.0.0/12 and 172.18.0.0/12.
and@danswartz:
Your subnet masks are wrong. For the 172 range, the usual is /12, not /16. You have overlapping networks.
Yes, your point about wrong subnet masks and overlapping networks is right, but there is no "usual" subnet for any prefix and the prefix you provided was not helpful to the OP. Particularly your response to@np247:
Eg:
172.16.1.x/255.240.0.0 for Internal.
172.17.1.x/255.240.0.0 for WAN1
172.18.1.x/255.240.0.0 for WAN2saying@danswartz:
Yes, this should work :)
is obviously wrong.
-
Ugh, this should teach me to post on low blood sugar :( Yes, the /12 is not in fact correct in that context. As far as CIDR goes, I agree with you, my point (not well put) was historical. His /16 would have been fine if he had moved the 16, 17 and 18 up one octet (172.16.0.0/16, 172.17.0.0/16 and 172.18.0.0/16).
-
I wonder how this will end with IPv6 and RFC4193 if there are already confusions with /8, /12, /16 subnets.
Where will this end with /48 ~ /64 subnets? :D
