Alright, I'm being a bit OCD on this, but... If you're going to use the 10.0.0.0/16 subnet off-prem, and want to set the broadest catchall you can for on-prem for the rest of the 10.0.0/8 range, this is the most compact way I see of setting up your on-site subnets:
10.1.0.0/16 10.2.0.0/15 10.4.0.0/14 10.8.0.0/13 10.16.0.0/12 10.32.0.0/11 10.64.0.0/10 10.128.0.0/9 This should cover all of the 10.0.0.0/8 subnets, EXCEPT for 10.0.0./16. Kurt On Wed, Feb 8, 2017 at 12:31 PM, Kurt Buff <[email protected]> wrote: > Sorry, my netmasking was incorrect. > > What I meant is that your subnets would need to be in the range above > 10.0.255.255, which means 10.1.0.0/16 and above, which indeed does > include 10.128.0..0/9, but also includes a lot more subnets. > > I'm not aware of a shorthand way to note that with CIDR.It would > likely be a set of /16s from 10.1/16 to 10.127/16, plus 10.128/9. > > Kurt > > On Wed, Feb 8, 2017 at 12:06 PM, Kurt Buff <[email protected]> wrote: >> So your subnets are in the 10.128.0.0/9 (10.128.0.1-10.255.255.254) range? >> >> Then yes, you should be fine. >> >> Kurt >> >> On Wed, Feb 8, 2017 at 11:28 AM, Charles F Sullivan >> <[email protected]> wrote: >>> Yes, so I'm set with that. >>> >>> For the on-prem site, there are no computers in the 10.0.0.0/16 subnet. >>> Another way to put it is that the subnet doesn't even actually exist in the >>> on-prem network. We have about twenty 10.x.x.x subnets on-prem and none have >>> a subnet mask of less than /16. >>> >>> Thanks. >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] >>> On Behalf Of Kurt Buff >>> Sent: Wednesday, February 8, 2017 1:25 PM >>> To: ntsysadm <[email protected]> >>> Subject: Re: [NTSysADM] Blocking AD Client Traffic to a Certain Site >>> >>> Sorry - just to be absolutely clear, my response is meant only to apply >>> computers with addresses in that 10.0.0.0/16 subnet. Machines in other >>> subnets would talk according to the other definitions in ADS&S. >>> >>> >>> Kurt >>> >>> On Wed, Feb 8, 2017 at 10:17 AM, Kurt Buff <[email protected]> wrote: >>>> Right. >>>> >>>> So if his off-prem site is 10.0.0.0/16, and his on-prem site is >>>> 10.0.0.0/8, then his on-prem computers in the 10.0.0.0/16 defined >>>> subnet(s) (i.e., from 10.0.0.1-10.0.255.254) will go off-prem, since >>>> the on-prem site definition is less specific than the off-prem >>>> definition. >>>> >>>> So, like i said, he needs to fix that, if he doesn't want his on-prem >>>> computers to talk to the off-prem DCs. >>>> >>>> amirite? >>>> >>>> Kurt >>>> >>>> On Wed, Feb 8, 2017 at 6:43 AM, Brian Desmond <[email protected]> >>>> wrote: >>>>> AD will match the most specific subnet so in this case the 10.0.0.0/16 >>>>> subnet will match anyone who is 10.0.X.X. IP. >>>>> >>>>> Thanks, >>>>> Brian Desmond >>>>> >>>>> (w) 312.625.1438 | (c) 312.731.3132 >>>>> >>>>> -----Original Message----- >>>>> From: [email protected] >>>>> [mailto:[email protected]] On Behalf Of Kurt Buff >>>>> Sent: Tuesday, February 7, 2017 6:55 PM >>>>> To: ntsysadm <[email protected]> >>>>> Subject: Re: [NTSysADM] Blocking AD Client Traffic to a Certain Site >>>>> >>>>> And there's your problem, if you didn't typo your response. >>>>> >>>>> 10.0.0.0/8 overlaps with (actually includes) 10.0.0.0/16 >>>>> >>>>> That's why some clients will go to your second site (AWS) at random. >>>>> >>>>> You probably need to list out your subnets more carefully for your main >>>>> site. >>>>> >>>>> Kurt >>>>> >>>>> On Tue, Feb 7, 2017 at 11:33 AM, Charles F Sullivan >>>>> <[email protected]> wrote: >>>>>> I’ve only been able to do very limited testing. >>>>>> >>>>>> >>>>>> >>>>>> - I had about 8 member servers in a site which were actually >>>>>> all in >>>>>> the same subnet as each of and the one DC we had for testing, let’s >>>>>> call the subnet 198.168.17.0/24. In that site I included the usual >>>>>> private ranges: >>>>>> 192.168.0.0/16, 172.16.0.0/12 and 10.0.0.0/8 >>>>>> >>>>>> - At AWS I had a subnet with one DC and just a couple of member >>>>>> servers in the 10.0.0.0/16 subnet, which was defined as the only AWS >>>>>> site. >>>>>> >>>>>> Note that the AWS subnet is a subset of one that I defined at the >>>>>> main site, but this absolutely is supported by MS and others have >>>>>> told me that this works for them. Despite all of this I did see one >>>>>> member server in the main site use the AWS DC after a reboot even >>>>>> though the local DC was clearly present and being used by the other >>>>>> member servers. So that means 1 out 8 member servers I had for >>>>>> testing crossed sites. This made me wonder how often it might happen >>>>>> in our production environment where there are thousands of member >>>>>> computers. >>>>>> >>>>>> >>>>>> >>>>>> I do have to say that I recently got to test this again, this time >>>>>> having 5 DCs at the main site and 2 at AWS. Again, I had just a >>>>>> handful of member servers and a workstation and this time I didn’t >>>>>> see any of them using an AWS DC. The AWS admin didn’t see his one >>>>>> member server use anything besides an AWS DC. >>>>>> >>>>>> >>>>>> >>>>>> From: [email protected] >>>>>> [mailto:[email protected]] >>>>>> On Behalf Of Michael B. Smith >>>>>> Sent: Tuesday, February 7, 2017 1:32 PM >>>>>> To: [email protected] >>>>>> Subject: RE: [NTSysADM] Blocking AD Client Traffic to a Certain Site >>>>>> >>>>>> >>>>>> >>>>>> Doesn’t make sense to me. >>>>>> >>>>>> >>>>>> >>>>>> The only reason you should have cross-site connections at this point >>>>>> is because you don’t have all of the relevant subnets defined in ADS&S. >>>>>> >>>>>> >>>>>> >>>>>> From: [email protected] >>>>>> [mailto:[email protected]] >>>>>> On Behalf Of Charles F Sullivan >>>>>> Sent: Tuesday, February 7, 2017 11:40 AM >>>>>> To: [email protected] >>>>>> Subject: [NTSysADM] Blocking AD Client Traffic to a Certain Site >>>>>> >>>>>> >>>>>> >>>>>> I’d like to get some ideas and opinions regarding this, especially >>>>>> if anyone has had a similar need….. >>>>>> >>>>>> >>>>>> >>>>>> Our AD topology to this point has been as simple as can be. Since >>>>>> just about everything on our extended network is connected at high >>>>>> speeds, we have never had to have more than one AD site. We are >>>>>> about to put a couple of DCs at AWS, which of course will require a >>>>>> second site to be defined. This will still be pretty >>>>>> straightforward. Everything but AWS will be on the one existing site and >>>>>> a second site will be added for the one subnet at AWS. >>>>>> >>>>>> >>>>>> >>>>>> I know that even with the two sites defined, some clients may at >>>>>> times use the remote site. This is what I have seen in testing, for >>>>>> whatever reason, but I don’t consider it to be a real problem >>>>>> because I assume it would not happen often. The problem is that our >>>>>> director wants absolutely no cross-site traffic except in the case of a >>>>>> disaster. >>>>>> >>>>>> >>>>>> >>>>>> It is being proposed that the firewall between the sites allow only >>>>>> AD traffic between the DCs themselves. AD clients would be stopped >>>>>> at the firewall. I’m not comfortable with that as a solution because >>>>>> I’m concerned that when clients do try to use DCs at the remote >>>>>> site, it will cause slowness if not failure. Does this seem like a >>>>>> bad idea for that or any other reason? >>>>>> >>>>>> >>>>>> >>>>>> I was thinking that maybe I could use weight and priority within SRV >>>>>> records so that the DCs at AWS would be weight=0 and priority=65535. >>>>>> If I did that, would the clients at AWS honor the site rules over >>>>>> the SRV records weight and priority? I’m guess that would be >>>>>> unpredictable, thus also not a good solution. >>>>>> >>>>>> >>>>>> >>>>>> Thanks in advance for any help. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Charlie Sullivan >>>>>> >>>>>> Sr. Windows Systems Administrator >>>>>> >>>>>> >>>>> >>>>> >>> >>>
