Cisco DNA quick overview

SDN (Software Defined Networking) - attempts to centralize network intelligence in one network component (SDN Controller) by disassociating the forwarding process of network packets (data plane) from the routing process (control plane).

REST (Representational state transfer) is a software architectural style that defines a set of constraints to be used for creating Web services.

API (Application Programming Interface)

YANG (Yet Another Next Generation) is a data modeling language for the definition of data sent over network management protocols and it uses either XML or JSON encoding.

Cisco DNA (Digital Network Architecture) - is SDN for campus networks. DNA supports management through REST API using YANG model.

DNA Center (DNAC) is centralized network management system aimed to be simple and intuitive in order to be used for management of all network functions and optimization of network and applications. With DNA Cisco goes beyon traditional SDN and realizes Intent-Based Network.

SDA (Software Defined Access) - policies are applied to users and applications which makes management easier. SDA used for adding policies concerned with security, segmentation, access etc.

Cisco series used in SDA are:

1. Access - Catalyst 9200, 9300, 9400
2. Aggregation - Catalyst 9400, 9500, 9600
3. Core - Catalyst 9500, 9600, 9800

NDP (Network Data Platform and Assurance) - analytic platform responsible for data collecting. Collects and classifies huge amount of data sent over network (application, user and equipment data). Using data provided by NDP DNA Center Assurance produces analytics and operative information about network state and also makes forecasts. 

How typical network tasks are made with DNA:

1. Connecting network devices - device role is defined within DNAC or device can be bought with preinstalled Plug&Play agents which are needed for this particular device
2. Network devices software versioning - DNAC saves "gold" versions of software and administrator just applies update policies needed for particular devices or segments
3. Scale-able access policies - traditional access policies are IP or VLAN based. Big IP addresses pools add additional complexity. DNAC applies policies to the entire network - when some devices are changed - policies remain the same
4. Campus network segmentation - DNAC realizes that using access matrix for all device categories used in the network. When new device is added to the network segmentation is automatically made after adding this device to the needed group

MySQL DB-size, tables size

Size of all tables in particular DB (change NEEDED_DB_NAME to needed):

SELECT table_name AS "Table", 

data_length+index_length AS "Size in bytes" 

FROM information_schema.TABLES 

WHERE table_schema = "NEEDED_DB_NAME" 

ORDER BY (data_length + index_length) DESC;

Size of all DB in MySQL:

SELECT table_schema AS "Database", 

ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS "Size (MB)" 

FROM information_schema.TABLES 

GROUP BY table_schema;

Count of rows of all tables in particular DB ((change NEEDED_DB_NAME to needed):

SELECT table_name AS "Table", 

table_rows AS "Rows" 

FROM information_schema.TABLES 

WHERE table_schema = "NEEDED_DB_NAME" 

ORDER BY table_rows DESC;

Table size description (depends on system block size):

1. index_length=data_length=16384 (total size is 32768) - empty table with index
2. index_length=0, data_length=16384 - empty table without index (only primary key can exist)

In MySQL (INNODB):

KEY=INDEX

PRIMARY KEY=special case of UNIQUE KEY (identifies that row and also data can't be NULL)

To check index, engine, index_length, data_length, create_time (change NEEDED_TABLE_NAME):

show table status like 'NEEDED_TABLE_NAME';

DB Normal Forms (primitive description)

 Normal Forms (NF) helps to resolve possible problems with insert, update and delete DB operations. 

To be in the next level NF DB must already be in all previous levels of NF (to be in 3NF DB must already be in 1NF and 2NF).

There are plenty of normal forms but in most practical situations first three forms are enough to prevent possible problems.

1NF (first normal form)

1NFexample1: You have "children" table with "child" column storing something like "Child'sNameSurname"

1NFexample2: You have "children" table with "parent" column storing something like "Mom'sNameSurname, Dad'sNameSurname"

1NFexample3: You have "children" table with "parent1_name" and "parent2_name" columns storing something like "Mom'sName" and "Dad'sName"

To be in 1NF:

1. The relation has a Primary Key (PK), which uniquely identifies each row in the relation.
1. As in 1NFexample1 "child" may not be unique so you need to add "row_id" as PK
2. Every column stores Atomic Values
1. As in 1NFexample2 non-atomic values are in "parent" column, so we need to split this into to rows, each with "parent" column containing name of one parent
2. Also "parent" column must be separated into "parent_name" and "parent_surname" columns
3. There are no Repeating Groups.
1. As in 1NFexample3 "parent1_name" and "parent_name" are repeating groups, so we need to add "parent_name" column and for each parent add one row

2NF (first normal form)

2NFexample1: You have "children" table with CPK "child_name"+"zip" and also having "city" column

To be in 2NF:

1. DB must already be in 1NF
2. No partial dependencies (also called partial functional dependencies) are in table
1. That is, each non-key attribute is functionally dependent on the full PK (PK for 2NF can be only multi column PK - also called composite PK. If table is in 1NF and having single-column PK, then this table is also automatically in 2NF):
1. As in 2NFexample2 "city" is related to "zip" (part of CPK), but not related to the "child_name", so we must add new table "locations" with "location_id", "zip", "city" columns. And use "location_id instead of "zip" as part of CPK

3NF (first normal form)

3NFexample1: You have "children" table with "row_id" PK column and "city" and "zip" columns storing something like "Child'sCity" and "Child'sZip"

To be in 3NF:

1. DB must already be in 2NF
2. No transitive functional dependencies - non-key column depends (functionally) on another non-key column, which is (functionally) dependent on the PK
1. As in 3NFexample1 "zip" and "city" are related to "row_id" (PK), but also depend on each other, so we must add new table "locations" with "location_id", "zip", "city" columns. After that in "children" table we'll use "location_id" instead of "city" and "zip"