Cabling and link layer planning

How to draw on L2* pages

Link checks

NDAT analyses drawn links. It tries to find these and some other errors:

  • ports/portsets are not connected;

  • PPPx are asymmetric; ports count are asymmetric;

  • port physical type mimatch;

  • L2 type mismatch; multiplicator usage errors;

  • etc.

Error messages can be found under links “Show description” context menu item.

Supported link configurations are on “Supported links” page.

L2 node types

There are following L2 physical node shapes to use on L2* pages:

  • l2devicenode – L2 node which corresponds to standalone device (l1device);

  • l2clusternode – L2 cluster node which corresponds to clustered device (l1clusternode), differs by fields Cluster ID and In-cluster ID;

  • l2bladenode – L2 blade node which corresponds to bladedevice (l1bladenode), differs by fields Bay ID and Chassis Hostname;

  • l2bladeclusternode – L2 blade cluster node which corresponds to blade cluster device (l1bladeclusternode), differs by fields Cluster ID and In-cluster ID, Bay ID and Chassis Hostname.

There are following L2 virtual node shapes to use on L2* pages:

  • l2contextnode – shape that corresponds to virtual context of a physical device; in current NDAT version only a single physical device can be set as context host (e.g. no context migration);

  • l2virtualnode – shape that corresponds to virtual machine, opposite to context, it is possible to define Cluster as host, so it means that VM does not have defined physical placement (Rack and units);

  • l2vsnode – shape that corresponds to Virtual switch – e.g. Virtual switch of single host;

  • l2vdsnode – shape that corresponds to Virtual distributed switch – e.g. virtual switch of virtualization cluster (hosted on cluster).

Clustered nodes

General recommendations

Clustered nodes basic usage scenarios (l2clusternode, l2bladeclusternode):

  • Stackable switches – in this case there will be only one hostname for several physical devices, so additional fields are needed for unique device identification – these are Cluster ID and In-cluster ID.

  • Virtualization cluster that allows VM migration – in that case in VMs Host-ID appropriate Cluster-ID can be defined.

  • All other cases, when architect wants to define cluster parameters on diagrams and in reports.

  • Clustered nodes feature is very optional (see below).

Case study

Once there was a necessity to design:

  • F5 SLB (DCS group) with several Route Domains;

  • Fortigate FW with VDOMs, and VDOM migration during cluster switchover;

  • Checkpoint Maestro in dual orchestrator config, with several Security Appliance and single Security Group.

All three cases were depicted using only l1device and l2devicenode – so clusters were treated as sets of standalone devices on Racks and L2 diagrams.

As separate entities, RD/VDOM/SG appeared only on L3 diagrams.

So cluster node usage – is very optional. Even if devices are actually clustered. Cluster nodes should be considered as an additional feature for architect, which he may use or not.

L2 ports

Port is a shape that should be glued to l2 node connection point on one side, and on other side l2link or l2linkset should be connected to port.

Besides l2links and l2linksets, patch-panel ports (ppp), VLAN lists and callouts (generaladdinfo) can be glued to ports.

Ports have predefined set of available physical types and L2 modes (Routed, Access, Trunk, Routed/Trunk (sub-if), Inspect);

Most often ports connected to each other with single link (but other options are available too – see Supported links page in sample file);

Sets of physical types and L2 modes may be extended/redefined by architect using Visio embedded shape data definition feature.

Break-out cables

Break-out shapes are intended to depict «break-out transceivers» or passive optic brake-out cables, in cases when single device interface splits to 4 separate interfaces.

If break-out cables used just as part of cabling to transform MPO to LC – then Break-out shapes should not be used. In this case break-out tail IDs should be encoded in PPP UIDs

Each break-out tail works as a single port – not a portset.

Link that has Break-out shapes and does not have PPPs at both ends, considered inconsistent.

Break-out shapes are optional. All the data can be encoded in Port ID/PPP UID.

In patch-cord summaries break-outs counted by number of tails. Break-out length estimated as a summary length – head length + tail length.

Portsets

When using ports every single link must be drawn on diagram. To save some space one may use portset and linkset shapes and draw a bunch of parallel links of same type.

Single linkset can contain from 1 to 16 links.

linksest support branching – e.g. single portset can terminate multiple linksests. To define correspondence between ports on different ends of link «Subset ID» property must be used.

Port count on both ends of linkset must be the same. If not, link will be marked as inconsistent.

Portset and linkset use samples are on “Supported links” page in sample file.

Port, Break-outs and Portsets properties extendibility

If nedeed user can define available values of following Port/Portset/Break-out properties:

  • Physical type;

  • L2 type.

If necessary Physical type or L2 type are not defined then:

  1. Select port shapes on stencils page and run Shape Data definition dialog;

  2. Edit available values for fields Physical Port Type and L2 Port type;

  3. Edit linked color legend;

  4. Repeat procedure for portsets.

Important: it is possible to prepare port/portsets for FC, SAS and any other technology.

L2 interface descriptions

NDAT generates descriptions for L2 ports and [M]LAGs and includes them into L2 links report.

Descriptions are generated according to “Formulas” that consist of some text and substitutable values:

  • L2-$RHostname-$RPortID;

  • L2-$RHostname-$RLAGID.

NDAT uses separate description formulas for ports and [M]LAGs.

Following substitutable values can be used:

  • LHostname - local hostname;

  • RHostname - remote hostname;

  • LPortID - local Port ID (e.g. Gi1/0/1);

  • RPortID - remote Port ID (e.g. Gi1/0/1);

  • LLAGID - local LAG ID (e.g. Po100);

  • RLAGID - remote LAG ID (e.g. Po100);

  • LL2Type - local port L2 type (A, T, R, R/T, I);

  • RL2Type - remote port L2 type (A, T, R, R/T, I);

  • LRackID - local rack ID;

  • RRackID - remote rack ID;

  • LUnits - local units;

  • RUnits - remote units.

VLAN list and [M]LAG ID

Each link may belong to a LAG and transfer some set of VLANs. To define these link properties universal shape “vlanlist” must be used.

“vlanlist” shapes must be glued with their Controls to ports or portsets.

VLAN list should be defined in “Edit” form (as long as it supports multi-line values editing). Each single VLAN must be defined in format “name_conventional (VLAN ID)”. Round brackets must be present. name_conventional shoud be taken from IP address plan.

Strictly speaking, VLAN list and [M]LAG ID are optional. Links table can be built without them. VLAN list and [M]LAG ID usage examples can be found on “Supported links” page in sample file.

"vlanlist" shape contex menu allows to choose shape mode. See "Switch LAG ID usage" and "Switch VLAN list usage" items. These switches allow to independently enable/disable VLAN list and [M]LAG ID usage.

[M]LAG ID must be defined on both ends of link, VLAN list may be defined only on one end.

Single “vlanlist” shape may be linked to both ends of link.

MLAG ID can include multiplicator index ($A, $B or $C). Even if multiplicator container is used only on single side of the link, MLAG ID on both sides can be multiplied.

Multiplicators

Multiplicators are Visio containers, so other shapes (L2 nodes) should be put into them.

Each multiplicator has three indexes in its shape data - $A, $B, $C. Values of these indexes will be substituted to shape data of shapes inside the container, or to shape data of glued shapes (to [M]LAG ID for example).

"Multiplied" port count on both ends of link must be the same. If not, link will be marked as inconsistent.

Portsets can not be multiplied.

Indexes in port IDs are ignored.

Multiplicator usage examples can be found on “Supported links” page in sample file.

Callouts and profiles

L2 diagrams support linking profiles and callouts to L2 nodes, ports and portsets.

Contents of profiles and callouts that attached/glued to L2 nodes will be included to L2 node profiled reports (NDAT -> L2 -> Reports -> L2 nodes reports).

Contents of profiles and callouts that attached/glued to port/portsets will be included to L1/L2 links profiled reports (NDAT -> L1 -> Reports -> L1 links reports , NDAT -> L2 -> Reports -> L2 links reports).

Multi-page L2 diagrams

Each L2 node can be drawn several times on single or multiple pages.

It is allowed to duplicate L2 nodes on multiple pages.

So L2 diagram may be split to several pages, but it’s not allowed to duplicated links, because they will be put into reports twice.

It is not allowed to duplicate links on multiple pages.

Also, it is not supported to draw a link between L2 nodes on different pages.

Symmetric and asymmetric reports

L1 link and L2 link reports can be generated in two forms:

  • Symmetric – each single link will be included in report twice – in forward and reverse direction; patch-cords will be counted only once.

  • Asymmetric – each link will be included only in one direction.

Report symmetricity can be set in settings.

In asymmetric reports it’s important to explicitly define which device must be located on the left side of the links table (side that marked as [s]ource). Usually if it’s a link between server and switch, then it’s desirable to put the switch on the left. If it’s a link between access switch and core/distribution switch, then it’s desirable to put the core/distribution switch on the left.

There are two ways to set device’s position in links table – on the left or on the right.

  • Way 1: Devices with lower #Px value (P stands for priority) in Description field are put into the left side of links table. If #Px value is not defined, the it is the lowest priority.

    • Examples:

      • «DCA DC spine 1 #P1» and «DCA DC spine 2 #P2» - «DCA DC spine 1 #P1» has higher priority.

      • «DCA DC spine 2 #P2» и «DCA DC border leaf 2» - «DCA DC spine 2 #P2» has higher priority.

  • Way 2: Devices with lower but bigger then 0 value in Linking Priority field are put into the left side of links table. If Linking Priority or lower or equal to 0, then #Px value in Description field works. If #Px value is not defined too, then it’s a device with lowest priority.

If priorities are not set on both sides of the link then direction will be set at random (strictly speaking, according to link/linkset shape direction).

Custom stencils

It is supported to use any arbitrary formatted shapes as L1 or L2 nodes. The main scenario for this feature is to allow vendor stencil usage.

Select any custom share and run NDAT -> General -> Format Shape.

It is possible to clone already drawn L1 node to custom shape (define fields and copy all shape data).

Ports and portsets with free formatting are already on Stencils page. These port/portset shapes must be glued to L2 nodes with Control point.

Info X fields

L1 and L2 shapes have three fields with arbitrary text data: Info 1, Info 2, Info 3. These fields are included into L1 links, L2 links, Devices reports and L2 nodes reports. These fields allow flexible report rows filtering in Excel.

Info X fields reports inclusion is optional (see Settings). But they are included/Excluded together with fields “Model” and “Description”.

In settings it is possible to define custom captions for Info X fields (see Device info x caption and L2 node info x caption settings).

Info X fields can optionally be synchronized from Racks* pages to L2 pages. Synchronization can be enabled/disabled separately for each field Info {1|2|3}.

L2 node’s management IP address

L2 node shapes on L2* pages have fields:

  • Mgmt IP address – main device’s management IP;

  • Mgmt interface name – management interface name (this name is used for mgmt IP auto update from L3 diagrams);

  • Allow mgmt IP auto update (enables or disables mgmt IP auto update from L3 diagrams).

To allow mgmt IP auto update, mgmt interface name must be correctly set. Use one of node’s L3 interface names drawn on L3 diagrams (L2 and L3 node’s hostnames must be the same).

Mgmt interface name, Allow mgmt IP auto update, Mgmt IP address values are optionally copied from L1 shapes (Racks* pages) to L2 node shapes (L2* pages) (see NDAT -> L1 -> Other -> Sync data from devices to L2 nodes).

If NDAT will not find IP address for particular Hostname and mgmt interface name on L3 diagrams – it will leave defined mgmt IP intact.

Mgmt IP address update performed every time when user clicks L2 -> Refresh -> Refresh all L2 nodes mgmt IPs, and when L2 nodes reports generated.

Mgmt IP update is supported for multiplied L2 nodes. Substitutable value ($A, $B, $C) can be in IP address itself, mgmt interface name, or just in node’s hostname. NDAT will process them in following ways:

  • If substitutable value will be in hostname and/or interface name, then NDAT will try to find corresponding IP address on L3* pages, and if succsed include this address to report.

  • If substitutable value will be in IP address, then address will be multiplied directly – NDAT will not try to find anything on L3* pages;

  • If L2 node is multiplied, and substitutable value is in hostname and/or interface, then on update Mgmt IP field will be replaced with “Multiple IPs” value.

Links coloring

NDAT supports automatic link coloring with color of connected ports. Feature can be enabled/disabled with “Mark links with port color” option. If NDAT founds link inconsistent it will color it with red anyway.

Default ports color scheme includes some light colors, which are not contrast enough on white background. If NDAT encounters such light links (criteria – more than 510 over RGB channels in summary), then it makes them darker.

NDAT colors links when it analyses them – e.g. when creates L1/L2 links report, on link checks, or on “Show description” action.

If link auto coloring usage planned it’s recommended to edit port default color scheme and choose more dark colors.

PreviousRacks* pages actions referenceNextWorking with cabling info

Last updated