Multi-area SPB Considerations and Restrictions

The following list identifies the restrictions and considerations that apply to the Multi-area SPB feature:

Two boundary nodes can be either in a vIST configuration (paired with each other) or in a non-vIST configuration. Three or more boundary nodes can only exist in a non-vIST configuration. Any other combination of boundary nodes is not supported.

Note

Only two boundary nodes can be in a vIST configuration.
Up to four nodes can function as boundary nodes between any given pair of areas.

Note

5520 Series and 5720 Series support a maximum of two nodes that can function as boundary nodes.
You must not connect the same Protocol Independent Multicast (PIM) domain to the SPB-PIM Gateway nodes that are in different Intermediate-System-to-Intermediate-System (IS-IS) areas, to avoid the inter-area redistribution of the same multicast information.
You can enable the Dynamic Nickname server on the boundary nodes in the home area, but the boundary nodes cannot be clients in any of the two areas. The boundary nodes do not support the Dynamic Nickname server in the remote area.
You must manually configure the backbone VLANs (B-VLAN) on the boundary nodes, so the system does not learn the dynamic values that it receives through the Link Layer Discovery Protocol (LLDP). However, the system sends the manually configured B-VLANs on the BN through LLDP, so that other neighbors can learn them (both in home and remote areas).
Each time the port receives a Fabric Connect TLV, the port is configured as NNI in the home area. You must disable Auto-sense on the IS-IS remote area ports. For more information, see Auto-sense Port States.
If the system forms an adjacency between two boundary nodes that are part of the home and remote area, the hello packets in the home area use the home manual area and the hello packets in the remote area use the remote manual area.
If the system forms a home and a remote adjacency on the same port then the Multi-area SPB feature uses different Backbone VLAN IDs (B-VIDs) for each adjacency, the home adjacency uses the primary B-VID and the remote adjacency uses the secondary B-VID.
If the system forms an IS-IS adjacency in both the home and remote areas on a boundary node of the same port then the remote adjacency stays up only with another boundary node that also has IS-IS configured on both the home and remote areas of the same port.
If a boundary node connects to a Backbone Edge Bridge (BEB) in the remote area and if you configure IS-IS in the home area on the same interface, then the remote adjacency goes down.
On the boundary node, to install a route from a remote area in the routing table manager (RTM), the route must pass the accept policy and the Multi-area SPB redistribution policy that you configure on the specific Virtual Router Forwarding (VRF) instance.
On the boundary node, to install an inter-VRF route from a remote area in the routing table manager (RTM), the inter-VRF route must pass the accept policy and the Multi-area SPB redistribution policy that you configure on both the source and destination VRF instances.
Nickname and system ID for the physical node and virtual node must be different.
When enabling Remote IS-IS Instance, make sure that the physical node nickname, virtual node nickname and system ID are different.
You cannot establish an SSH connection to the boundary node from an IS-IS remote area.

Multi-area Deployment Guidelines

Use the following guidelines to design a Multi-area network:

In order to achieve optimal convergence performance, use the following order of preference for inter-connecting Boundary nodes:
1. Direct links between all Boundary Nodes with adjacencies configured for both home and remote area.
2. Reliable and redundant high bandwidth forwarding path between any two Boundary nodes in both areas.
3. Reliable and redundant high bandwidth forwarding path between any two Boundary nodes in home area and Virtual NNI Links in remote area.
4. Reliable and redundant high bandwidth forwarding path between any two Boundary nodes in remote area and Virtual NNI Links in home area.
Manually configure the Virtual NNI Links IS-IS metric to reflect the most desired traffic forwarding pattern. As a general rule, physical NNIs are preferred over Virtual NNI Links.
Manually configure the IS-IS metric of any relevant NNI in order to avoid using Virtual NNI Links to forward unicast and multicast traffic, when possible.
In a non-vIST configuration with three or more boundary nodes, use the following guidelines to ensure there is a robust Fabric path between them in both areas (home and remote):
- If a direct connection exists between the boundary nodes, configure both areas NNIs onto the link or links.
- If there is no direct connection between the boundary nodes, make sure a robust Fabric connectivity exists in both areas.
- If a WAN with low bandwidth exists on one side, you can create a virtual NNI link and establish a virtual Fabric adjacency over the area with the robust connection. With this, you can interconnect your WAN area over the LAN area with high performance connectivity and avoid the path between the boundary nodes in the WAN area.
  
  For more information, see Virtual NNI Links for Multi-Area Boundary Nodes.