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 >>>>> >>>>> >>>> >>>> >> >>
