none
Hub and spoke topology with sites and services

    Question

  • In a hub and spoke topology with satelite offices connecting to a central hub it is best to disable bridge all site links and manually set up site links from the branch offices to the hub correct? Are there any pitfalls in doing this?
    Tuesday, February 09, 2010 9:46 PM

Answers

  • i agree with both jorge and marcin.  in most scenarios it is okay to leave it enabled and generally speaking preferred.  to add on to what marcin said, if your network is not fully routable then you may see some errors in the event logs and extra churn on the dcs (depending on the size of your environment, this may not always be enough reason to disable basl).  fully routable means that any dc can communicate to any other dc.  this doesn't require that they have a direct connection just a logical route.  so, if from any dc in your environment you could telnet on 135 to any other dc in your environment, you meet the criteria for basl.  

    basl has a lot of upside.  one, it can reduce the amount of site links that you have to create and maintain.  the flip side is that if your site links from the spokes all have the same cost to the hub, then you should understand that your redundant site topology is pretty much open to full mesh.  two, basl is great because it can protect against human error.  there are a lot of complexities to ad replication and if for some reason we fail to create a site link to cover a partition we could wind up islanding a partition (or a full dc).  basl allows the KCC to make sure that no one gets islanded (assuming network connectivity is there).  

    /rich

    http://cbfive.com/blog
    Wednesday, February 10, 2010 1:07 AM
  • a site link from each spoke to the hub is correct.  generally i would recommend that you either create a redundant site link (you would create it with a higher cost than the primary site link) to another site OR to create site link bridges to join two site links together.  but if your spoke sites truly cannot communicate anywhere outside the hub, that really doesn't matter much.
    http://cbfive.com/blog
    • Marked as answer by red888 Tuesday, February 23, 2010 4:12 PM
    Monday, February 22, 2010 3:41 PM
  • Unless you want to direct the flow of replication traffic, possibly because of Firewalls in your design that require it, I dont see why you would want to disable bridging all sites.  I see that as adding additional complexitiy in the design.

    Other than the Firewall scenario, I cant really think of a valid reason to disable it. 
    Visit my blog: anITKB.com, an IT Knowledge Base.
    Tuesday, February 09, 2010 9:54 PM
  • Bridge all site links is typically disabled in scenarios where traffic is not routed between spokes. Disabling it gives you also more control over how KCC creates connection objects (keep in mind that you can create site link bridges manually if needed). On the flipside, in situations where routing between spokes is possible, failure of DCs in the hub site might break your replication...

    hth
    Marcin
    Tuesday, February 09, 2010 10:58 PM

All replies

  • Unless you want to direct the flow of replication traffic, possibly because of Firewalls in your design that require it, I dont see why you would want to disable bridging all sites.  I see that as adding additional complexitiy in the design.

    Other than the Firewall scenario, I cant really think of a valid reason to disable it. 
    Visit my blog: anITKB.com, an IT Knowledge Base.
    Tuesday, February 09, 2010 9:54 PM
  • Bridge all site links is typically disabled in scenarios where traffic is not routed between spokes. Disabling it gives you also more control over how KCC creates connection objects (keep in mind that you can create site link bridges manually if needed). On the flipside, in situations where routing between spokes is possible, failure of DCs in the hub site might break your replication...

    hth
    Marcin
    Tuesday, February 09, 2010 10:58 PM
  • i agree with both jorge and marcin.  in most scenarios it is okay to leave it enabled and generally speaking preferred.  to add on to what marcin said, if your network is not fully routable then you may see some errors in the event logs and extra churn on the dcs (depending on the size of your environment, this may not always be enough reason to disable basl).  fully routable means that any dc can communicate to any other dc.  this doesn't require that they have a direct connection just a logical route.  so, if from any dc in your environment you could telnet on 135 to any other dc in your environment, you meet the criteria for basl.  

    basl has a lot of upside.  one, it can reduce the amount of site links that you have to create and maintain.  the flip side is that if your site links from the spokes all have the same cost to the hub, then you should understand that your redundant site topology is pretty much open to full mesh.  two, basl is great because it can protect against human error.  there are a lot of complexities to ad replication and if for some reason we fail to create a site link to cover a partition we could wind up islanding a partition (or a full dc).  basl allows the KCC to make sure that no one gets islanded (assuming network connectivity is there).  

    /rich

    http://cbfive.com/blog
    Wednesday, February 10, 2010 1:07 AM
  • Thanks for all of your responses. So if I had a policy that ALL traffic from the branch offices (non of which are connected to each other via wan links) had to pass through the hub to go though a firewall/traffic filter before reaching another branch I still would not have to disable basl? Specifically what sort of replication errors would I see in the logs?

    Wednesday, February 17, 2010 9:41 PM
  • i am terrible with remembering numbers but as i recall, you'll see events like 1311, 1865, 1566, 13508, and maybe some others.

    when you say that you have a policy that all traffic must pass through the hub, is that a network policy?  though the spoke sites are not directly connected, does that policy then allow the domain controllers to be logically connected?  for instance, from a dc in one spoke site can you ping a dc in another spoke site?  if you can you are logically connected, and if this is true around the horn then basl should cause you any kcc related issues if site links are created properly.

    hth

    /rich

    http://cbfive.com/blog
    Wednesday, February 17, 2010 10:17 PM
  • Im sorry my last question was all mixed up. Where I said traffic had to pass from a branch through the hub to go to another branch I meant to say internet. The branches cannot communicate with each other ie ping or anything else. All communication between branches is cut off- they may only communicate with the hub.
    Friday, February 19, 2010 9:52 PM
  • no problem at all.  

    okay, in that case your environment would not be considered fully routable.  BASL in this situation will cause these events to be logged in a failure scenario.  you may want to disable it and create your own redundant links (though i am not even sure what those would be if your spokes can only communicate with a hub site).

    hth

    /rich

    http://cbfive.com/blog
    Friday, February 19, 2010 11:41 PM
  • Cool, thanks for the response. I'm still getting a handle on the nuances of AD replication. I was just going to create a single site link (or site link bridge?) for every branch office to hub physical link.
    Sunday, February 21, 2010 4:30 PM
  • a site link from each spoke to the hub is correct.  generally i would recommend that you either create a redundant site link (you would create it with a higher cost than the primary site link) to another site OR to create site link bridges to join two site links together.  but if your spoke sites truly cannot communicate anywhere outside the hub, that really doesn't matter much.
    http://cbfive.com/blog
    • Marked as answer by red888 Tuesday, February 23, 2010 4:12 PM
    Monday, February 22, 2010 3:41 PM
  • This is an old thread, but I have another question about this.

    We have deleted the defaultipsitelink and have manually created site links between the hub and all of the spokes. I believe the KCC has also been disabled.

    We have 4 DCs in the hub site and 2 DCs in each spoke site (about 40 spokes total). Right now we are manually creating connection object between every DC in every spoke site to every DC in the Hub site- a lot of tedious manual work.

    My question is if we can have the KCC automatically create the connection objects for us while still using our manually created site links.

    I previously thought that when you delete the defaultipsitelink the KCC will no longer automatically generate connection objects- is this correct?

    Friday, December 30, 2011 7:04 PM
  • As your environment is not fully routed, you only have to :
    - create all Site Links, one for each spoke and the hub. For one of those links, you can reuse/rename DefaultSiteLink instead of deleting it ;
    - if possible, create alternate/redundant Site Links, so with a higher Cost ;
    - disable BASL ;
    Then let KCC/ISTG generates connection objects between DCs based on your manual topology.
    If :
    - some DCs are used too for other roles and are so busy that you want to prevent them from the load of inter-site replication ;
    - or routing/firewalling rules permits DCs from a Site to connect only a subset of DCs on another Site ;
    on each Site, you can define one or more (at least two is recommanded) DCs as prefered Bridgehead Servers.


    Axel Limousin, ITSI - IT Training School, 93500 Pantin, France

    Thursday, February 28, 2013 10:20 PM