Neighborhoods exist to help define the topology of the routers within your Authority. There are two primary use cases for using neighborhoods. First, neighborhoods allow you to assign tenancy to ingress traffic in a more granular manner than simply applying a tenant label to a network-interface. The details of that configuration are included in this post.
Second, neighborhoods can be used to automate the 128T peering relationships between routers and to automatically create service-routes directing traffic to the peer 128T router that hosts a particular service.
For this use case, you can think of neighborhoods as a method to define on which interfaces should various 28T routers attempt to connect to each other. For example, if you have a deployment that consists of five locations and each site is connected to an isolated MPLS network as well as to the Internet through a Broadband connection, you most likely would use two neighborhoods, say 'MPLS' and 'Internet'. You would apply the 'MPLS' neighborhood to the network-interfaces that connect to the MPLS network and you would apply the 'Internet' neighborhood to the network-interfaces that connect to your Broadband provider(s).
When you enter this configuration and commit, the configuration generator on the Conductor will use the neighborhoods you've configured to automatically create adjacencies where appropriate. For example, the network-interfaces with the MPLS neighborhood would only have adjacencies built pointing to other remote 128T interfaces that are also in the MPLS neighborhood. The same for Internet. That ensures that the interfaces connected to the MPLS network aren't continually trying to setup connections to the interfaces connected to the Internet, which they would never be able to reach.
Neighborhoods also support the concept of topology. So you could configure a neighborhood with topology 'mesh' and the conductor's config generator would automatically setup adjacencies to all other remote 128T addresses within this neighborhood. The other options are 'spoke' and 'hub'. The logic for topology follows below:
* neighborhoods set to spoke connect to neighborhoods of the same name set to hub
* neighborhoods set to hub connect to neighborhoods of the same name set to spoke, but not to other neighborhoods set to hub.
* neighborhoods set to mesh connect to all neighborhoods with the same name
Another point to consider when allowing the conductor to auto-generate adjacencies between 128T routers with neighborhoods is that neighborhoods allow you to configure the options that should exist in the adjacencies. For example, you would configure an external-nat-address in the neighborhood consisting of the external public IP address of this interface and the config generator will ensure this exists on all adjacencies created on the local interface. Similarly, if only a range of ports are allowed inbound for SVR service, you can configure a port-range in the neighborhood. The config generator will use this to configure the port range on all the REMOTE adjacencies pointing to this interface.
Neighborhoods also allow you to configure a 'vector' which is an arbitrary label used to influence path selection via service-policy. Consider you have a large network with many neighborhoods. Perhaps you have two MPLS networks that do not connect (for whatever purpose). You create two neighborhoods: MPLSA and MPLSB to distinguish them and keep the routers on each separate MPLS network from trying to peer with each other. Now lets say you have specific services that you want to prefer to send over MPLS and disallow over Internet. You can give the same vector of 'mpls' to both neighborhoods MPLSA and MPLSB. Assuming you have vector 'internet' in all other neighborhoods, you can create a service-policy as shown below:
service-policy mpls-only
name mpls
vector mpls
name mpls
exit
vector internet
name internet
priority never
exit
exit
Any service that you apply this service-policy to will only attempt to use peer paths that traverse neighborhoods with vector 'mpls' when connecting between 128T routers.
Last but not least, neighborhoods allow for the automatic configuration of service-route objects. For this to occur there are a few requirements. First, the service must have the 'share-service-routes' flag set to true (enabled by default). Second, there must be a service-agent service-route configured for this service somewhere in the Authority.
Let's say you have a database service behind your HQ 128T. On that 128T you would configure a service-agent service-route pointing the traffic for this service to the database server. If this exists, and the share-service-routes flag is set, the config generator will use the neighborhoods to automatically generate a peering service route to all routers that are connected to the HQ router through neighborhoods. In this way, all your branches will automatically be able to reach the database service without manual configuration (provided the tenants have access to the service, of course).
There are often times you wish to disable the share-service-routes flag. If you want to do breakout Internet at each location, you most likely want to disable this setting to ensure that no peering service-rotues are generated which would force Internet traffic to other locations over SVR connections.
#Neighborhoods #ServiceRoutes