[prev in list] [next in list] [prev in thread] [next in thread]
List: cifs-protocol
Subject: Re: [cifs-protocol] Test fixtures for the KCC [REG:115030412472722]
From: Edgar Olougouna <edgaro () microsoft ! com>
Date: 2015-03-31 22:13:00
Message-ID: CY1PR0301MB11794629BDF7141005C2960ADBF40 () CY1PR0301MB1179 ! namprd03 ! prod ! outlook ! com
[Download RAW message or body]
Andrew,
Per [MS-ADTS] Section 6.2, which provides a lot of details on Windows-based KCC \
implementation, KCC runs produce or update the following: • Config NC objects: \
nTDSConnection • Abstract attributes of NC replicas: repsFrom, repsTo
• Variables of DCs: kCCFailedConnections, kCCFailedLinks
Referring to the simplified example in Section 3.1.1.1.13 NC Replica Graph, the \
output would be specific to a given topology and configuration for that \
implementation. As you alluded to, a given implementation may produce a different \
output and that should be fine provided the end outcome is achieved. This clearly \
seems a potential area of innovation for implementers.
[MS-ADTS]
6.2 Knowledge Consistency Checker
https://msdn.microsoft.com/en-us/library/cc223795.aspx
6.2.2 Overview
The KCC automates management of the NC replica graph for each NC in the forest. In \
doing so, it maintains the following requirements: • There exists a path from each \
writable replica to every other NC replica (writable, read-only full, or read-only \
partial) of the same NC. • No path from a writable replica to another writable \
replica passes through a read-only replica. • For each domain NC, the path from a \
writable replica to another writable replica utilizes only the RPC transport (never \
SMTP [MS-SRPL]). • For each domain NC, the path from a writable replica to a \
read-only full replica utilizes only the RPC transport (never SMTP [MS-SRPL]). \
• Replication latency is short between NC replicas on DCs in the same site, at the \
expense of additional replication traffic within the site. • Replication traffic \
between sites is low, at the expense of additional replication latency between sites. \
• A state in which one or more DCs are offline or unreachable (temporarily or \
indefinitely) does not cause the replication latency across the remaining DCs to grow \
without bound. • Edges between DCs in different sites constitute a least cost \
spanning tree for an administrator-defined cost metric. The KCC performs this work in \
a sequence of tasks called a "run". These runs execute periodically and on receipt of \
an IDL_DRSExecuteKCC request. The first periodic run of the Windows KCC begins 5 \
minutes after system startup. Subsequent runs execute such that the interval between \
the end of one run and the beginning of the next run is 15 minutes. These tasks \
utilize the following inputs: • Config NC objects: crossRef, interSiteTransport, \
nTDSDSA, nTDSConnection, site, nTDSSiteSettings, siteLink, siteLinkBridge \
• Abstract attributes of NC replicas: repsFrom, repsTo • Variables of DCs: \
kCCFailedConnections, kCCFailedLinks • Current date/time
And produce or update the following:
• Config NC objects: nTDSConnection
• Abstract attributes of NC replicas: repsFrom, repsTo
• Variables of DCs: kCCFailedConnections, kCCFailedLinks
The KCC individual tasks are detailed in the remainder of this section, and are \
executed in the sequence in which they appear in this document. In summary, these \
tasks are: • Refresh kCCFailedLinks and kCCFailedConnections.
• Create intra-site connections.
• Create inter-site connections.
• Remove unnecessary connections.
• Translate connections.
• Remove unnecessary kCCFailedLinks and kCCFailedConnections.
To simplify the task descriptions, the following concepts are used:
• An NC replica that "is present" on a DC. Given NC replica r of NC n and a DC with \
nTDSDSA object o, r "is present" on the DC if both of the following conditions is \
true: o o!hasMasterNCs contains n or o!msDS-hasFullReplicaNCs contains n or \
o!hasPartialReplicaNCs contains n. o One of the following two conditions is true:
 o!msDS-HasInstantiatedNCs contains no value v where the dsname portion of v = n. \
(In this case n is in the process of being instantiated.) \
 o!msDS-HasInstantiatedNCs contains a value v, where the dsname part of v = n, and \
the binary part of v (DWORD in big-endian byte order) is an integer such that the \
IT_NC_GOING bit is clear. (In this case n is instantiated, and is not in the process \
of being uninstantiated.) • An NC replica that "should be present" on a DC. Given \
NC replica r of NC n and a DC with nTDSDSA object o, r "should be present" on the DC \
if r is one of the following: o A writable replica of the config NC, the schema NC, \
or the DC's default NC on a writable DC. o A full read-only replica of the config NC, \
the schema NC, or the DC's default NC on an RODC. o A writable replica of an \
application NC for which there exists a crossRef object cr such that cr!nCName = n \
and cr!msDS-NC-Replica-Locations contains a reference to o. o A full read-only \
replica of an application NC for which there exists a crossRef object cr such that \
cr!nCName = n and cr.ms-DS-NC-RO-Replica-Locations contains a reference to o. o If \
the DC is a GC server (that is, if bit NTDSDSA_OPT_IS_GC is set in o!options), a \
partial replica of a domain NC n such that n ≠the DC's default NC, and there \
exists a crossRef object cr such that cr!nCName = n. • An nTDSConnection object \
"implies" a tuple in the repsFrom abstract attribute of an NC replica (and a \
corresponding edge in an NC replica graph). An nTDSConnection object cn implies a \
tuple in r!repsFrom for NC replica r of NC n on the DC with nTDSDSA object t, if each \
of the following is true: o cn is a child of t.
o cn!fromServer references an nTDSDSA object s.
o An NC replica of n "is present" on s.
o r "should be present" on t.
o The NC replica on s is a full replica or r is a partial replica.
o n is not a domain NC, or r is a partial replica, or cn!transportType has no value, \
or cn!transportType has an RDN of CN=IP.
. . .
Thanks,
Edgar
-----Original Message-----
From: Edgar Olougouna
Sent: Wednesday, March 4, 2015 4:09 PM
To: Andrew Bartlett
Cc: cifs-protocol@lists.samba.org; MSSolve Case Email
Subject: RE: Test fixtures for the KCC [REG:115030412472722]
Andrew,
I will work with you on this inquiry.
Thanks,
Edgar
-----Original Message-----
From: Josh Curry
Sent: Wednesday, March 04, 2015 11:14 AM
To: Andrew Bartlett
Cc: cifs-protocol@lists.samba.org; MSSolve Case Email
Subject: RE: Test fixtures for the KCC [REG:115030412472722]
Hi Andrew, thank you for your question. Case 115030412472722 has been created to \
track your issue. A member of the protocol documentation team will be in touch with \
you soon.
Josh Curry | Escalation Engineer | Open Specifications Support Team P +1 469 775 2321 \
One Microsoft Way, 98052, Redmond, WA, USA http://support.microsoft.com
-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@samba.org]
Sent: Tuesday, March 3, 2015 9:56 PM
To: Interoperability Documentation Help
Cc: cifs-protocol@lists.samba.org
Subject: Test fixtures for the KCC
We are working on making Samba's KCC much, much smarter than the full-mesh topology \
we currently have. (For those familiar with Samba, the particular task involves \
finsishing the work on the samba_kcc script).
One thing that has come to our attention, is the need for really good and diverse \
text fixtures, and expected outputs for the KCC algorithm.
That is, while the docs really are great, they are incredibly detailed and at points \
appear to have errors at some point. To be sure one way or the other, we need to \
test a variety of network topologies against the reference implementation in Windows, \
or the output thereof.
The trouble I've got is that unlike so many other aspects of the protocol, the output \
isn't a network response, but instead one part of a distributed algorithm, which the \
author warns must be implemented exactly (or else replication will fail in horrible \
ways).
So I'm looking for suggestions as to how to handle this, and wondering if a \
documented algorithm such as this should have some expected output values, to \
validate against.
In particular, the challenge is how to assert not just by looking at a running \
windows server, but to do the same in our as part of our internal make test.
I realise this is a little open-ended, but I figured I would ask.
Thanks,
Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
_______________________________________________
cifs-protocol mailing list
cifs-protocol@lists.samba.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic