"Andrew Story" <andrewDOTstoryATjameswalkerDOTbiz> wrote in message
Hi Herb,
Some sites are fully routed on an MPLS platform (no errors on these sites
DC's), some are connected via IPSec VPN Tunnels (some errors on these
sites
DC, depending on spec of firewall installed, regarding amount of support
VPN
tunnels). Some of the VPN sites that are connected to the MPLS network
via
the VPN Tunnels have low spec firewalls that do not have the ability to
have
more than a few tunnels setup.
These particular sites have a DC installed on each, but the DC's on these
sites have no direct route (e.g. not every DC is pingable from these
sites)
to every DC in the organisation, due to the spec of the firewalls, which
means in turn that we cannot have many VPN IPSec tunnels.
These limitations cause me to consider the network not fully
routed since the DCs cannot route between each other across
all possible (physical or logical) paths.
This is one of the main purposes for custom Site Link Bridge-grouping:
You put only those SitesLinks that would actually be usuable into the
same transitive SiteLinkBridge-group(s).
This means that each sites DCs can (IF necessary) use those double,
triple, etc., 'virtual SiteLinks' to bypass any intermediate sites with
down DC while still preferring those direct and lower cost explicit
links.
In ADS&S these VPN sites with DC's are defined, and have a site link back
to
the main 'Hub' AD site, where all AD replication goes through, and is
defined in ADS&S via site links back to every site (e.g. every AD
site is
defined in ADS&S, every AD site has the relevent site DC associated with
it,
and every AD site has a site link back to the 'Hub' AD site ONLY). So,
the
sites that are connected via VPN have only a site link back to the
Hub
sites
DC.
It seems to be just a simple Hub architecture with site links
back to, and only back to, the hub from each remote location.
Perfectly normal and usually reasonable.
Sorry if I worded the original question badly (had a long day), I
understand and appreciate the purpose of Auto site link bridging,
I didn't find it particularly difficult to understand your
description so don't worry about it. On the other hand,
I do make a practice of correcting misstatements or places
where the terminology or wording is not helping to solve
the problem someone is not facing.
As you explain below, that lack of routing is likely causing the
errors you see....
and as far
as I am aware the VPN sites AD servers event log errors are telling
me
that
there would be no replication possible to some AD sites, due to there
being
no direct route to these AD sites (please correct me if I'm wrong), but
will
these errors go away in time,
Probably not. Even if they do go away, they will return from
time to time as the situation (current status of your DCs and
networks) changes.
will they cause any harm (you answered that
already), can they be stopped?
(To recap: No serious harm from the errrors except to possibly
mask 'real' problems by filling up or cluttering your event logs
and by causing you to get in the habit of ignoring them -- this latter
is a separate psychological issue that we ALL suffer from when
we leave error messages for innocuous problems.)
I know not all sites can be contacted
directly by the VPN sites, and as such no such links are defined in ADS&S.
If you wanted to "fix it" you would turn off the default
full SiteLikeBridge-grouping, and only include those
SiteLinks (in each custom group) which are full routable
(for DC purposes).
IF you have simply that central-Hub and unconnected spoke
topology you would do LITTLE harm by just turning off the
SiteLink Bridging.
The downside would be that were the central (hub) DCs to
all go down WHILE the network and routing continued to function
then you would not replicate remote-to-remote without being
able to stage the replications through the hub.
For times when the network is non-functional (likely if ALL of the
DCs in the hub are down AND the routers live in the same physical
networks) then nothing would be lost since it would be all or nothing
anyway.
For networks where there are SOME paths "across" the hub (or
around, which you don't seem to have) then NEW "site link bridge-
groups" would allow those pairs of sites to replicate without involving
the central hub DCs.
You could also (while disabling the bridge-grouping) just put in
additional SiteLinks with higher costs and control it that way.
(This becomes complicated as the number of SiteLinks grows and
the KCC is usually better at calculating this dynamically for you,
but you are also free to just set your own links and turn off that
transitivity.)
If I'm making no sense please let me know. Thanks for your response
No, you are doing fine -- just ask anything specific that doesn't
make sense to you yet, or that you think of as you continue to
work your design.
--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
"Andrew Story" <andrewDOTstoryATjameswalkerDOTbiz> wrote in message
Hello NG,
I have some sites connected to our main MPLS platform (fully
routed
network)
via VPN. Not all the VPN sites have physical connectivity to all the
other
sites, due to the amount of tunnels allowed due to the spec of the
firewalls
we are using.
Then presumably your Site Link follow ONLY the
Physical WAN links. (Other designes are technically
legal but seldom make sense.)
[Actually after reading your whole message below, you do NOT
have a fully "routable" network from the point of view of the DCs
-- those VPN firewalls which prevent the DCs from communcating
with each other make their traffic unroutable across such links.]
On the some of the VPN sites I have alot of errors in event
viewer
(Event
ID:1331 and 1556) advising that some other sites cannot be contacted.
We don't know your Site Links.
I
appreciate that some of the VPN sites cannot contact all the other
sites
directly due to the firewall specs,
Then they should have no direct Site Links, nor in general
are you going to remove this error COMPLETELY if you
allow for the default SiteLink Bridging (grouping of SiteLinks)
but most of the time those transitive "virtual SiteLinks" will
never be attempted.
and I don't want to have to remove auto
site link bridging and manually specify site link bridges for the
entire
domain. My question is, will these errors disappear in time, e.g. will
AD
simply 'give up' trying to contact these other sites?
No, but they are largely unimportant except for that fact
that such 'irrelevant' errors tend to mask real problems if
you get in the habit of just 'ignoring' them.
and if so, will it cause any issues?
Just the tendency to ignore real errors.
But you haven't explained WHY the DCs in unreachable sites
are making an attempt to actually CONTACT those other DCs.
In general, they should be using the "closest" site DCs until
(all of) the DCs in that site are down.
My suspicion is that you have either/both too many Site Links
(across non-existent, unroutable links) OR some of your DCs
are not properly placed within the correct site (in Sites and
Services) or similar DCs problems.
--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
