**************************************

1-Describe Software-Defined Networking

**************************************

SDA Aware Catalyst switches can be configured and managed by DNAC.

We can run the SDA aware switches in Non-SDA mode or in SDA mode.

VXLAN - Data Plane

LISP - Control Plane
CTS - Integrated Security

UNDERLAY - What we have.

OVERLAY - What we want. (Overlay is bunch of network tunnel that creates the
architecture that I want.) VXLAN is used to accomplish this.

SDA = CAMPUS FABRIC (VXLAN, LISP, Cisco Trust Sec (ISE)) + DNA - CENTER

Cisco uses Declarative Model, other vendor uses Imperative model (if controller
goes down the switches cannot forward traffic)

*********************************************
2-Explain Software-Defined Access Principles
*********************************************
==================
FOUR LAYERS OF SDA
==================

PHYSICAL - SWITCHES, ROUTERS, WLC, AP

NETWORK - UNDERLAY, OVERLAY
CONTROLLER - DNA-CENTER, ISE
MANAGEMENT - Web, REST APIs

FABRIC EDGE NODE - (WIRED USERS CONNECTS) Where the destination is or Which tunnel
i will sent to?
CONTROL PLANE NODE - (These reqponsible for knowing where all the end devices are.)
FABRIC BORDER NODE - (CONNECTS TO OUTSIDE) It is reponsible for advertising the
fabric routes to rest of the n/w also advertising the rest of n/w routes to fabric.
FABRIC WLC - (It connects through underlay - FABRIC BORDER NODE or L3 Network) -
CAPWAP tunnel is formed b/w WLC and AP to transmit control plane information also
APs forms VXLAN tunnels with upstream Fabric Edge nodes to pass data traffic.
INTERMIDIATE NODE - L3 device can be non cisco, It faciliates tunnel communication
among other SDA devices.

**FABRIC BORDER NODE can take on the role of CONTROL PLANE NODE, However its not
recommended in large enterprise and when users are doing lot of roaming**

UADP (Unified access data plane). It is critical to have UADP on our Fabric Edge
Nodes.
We do not require UADP to be Fabric border nodes.

FABRIC EDGE NODES:

------------------
9200-9500
3650,3850
4500E (SUP8E,SUP9E)
FABRIC BORDER NODES & CONTROL PLANE NODES:
------------------------------------------
9300-9600
3850
6807,6500 (SUP 2T, SUP 6T)
6880-X, 6840-X
ASR 1000
ISR 4300/4400

FABRIC WLCs:
-----------
9800 (has UADP)
3504,5520,8510

APs:
---
9100
x700, x800
1540, 1560

CONTROLLERS
-----------

DNA CENTER (Physical)

ISE (Virtual, Physical)

A Fabric is an overlay and the overlay is build with tunnel, over a physical
architecture which is called underlay.

VXLAN is used to build the SDA DATA PLANE, VXLAN is a unique tunneling mechanism
that allows to carrying layer 2 information (we can have clients in same vlan
seperated by layer 3).
This turns the network end devices to VTEP (VXLAN Tunneling endpoint), It
encapsulates the packet in VXLAN header and sends it across the network. Other
switch will decapsulate that packet and send it to host.

How does VTEP know where the destination endpoint lives?

A) SDA Control plane (The control plane information maintained by Control plane
node).

Once the endpoint location is shared by control plane node, now the VTEP will
remember the location of th host in its endpoint table (now on send traffic
directly).

LISP is used as control plane protocol.

SDA POLICY PLANE - The role of POLICY plane is to emmbed security into the solution
from ground up.
The control we are going to use is Cisco Trust Sec (CTS), The idea of CTS is to
take a traffic flow and apply a TAG to that, this TAG is called (SCALABLE GROUP
TAG) SGT,
as the traffic arrives on the switch it looks at the tag and we can look at policy
that is associated to the tag (we can drop or allow the traffic by looking at SGT).

SDA going to rely on ISE in order to build out SGTs, However we are going to
perform configurations on DNA-center and DNAC will push the configuration to ISE
adn ISE will deploy the configruation to the fabric.
SDA UNDERLAY NETWORK
====================

We building our overlay as tunnels between fabric edge nodes (VXLAN tunnels).
The purpose of underlay is to get us from one edge switch to other (VTEP).

We can build our underlay using two options:

1) Automated:

- It requires DNA-Center, which will do the automated deployment for us. It is for
Green field deployment.
- Automated process is going to leverage PNP (Plug and Play) technology, switches
tries to DNAC and pull configurations. It uses global IP pool that we configure in
DNAC.
- In automated deployment DNAC will use ISIS as an IGP.
- It simplies the deployment as DNAC does all work.

2) Maunal:
- Underlay can be Layer 2 or Layer 3, Cisco recommends Layer 3 underlay.
- We will need an IGP protocol, technically we can use any IGP we want. However
Cisco recommends using ISIS.

MTU SIZE:
VXLAN requries a 50 bytes of overhead in order to prevent fragmentation, if we dont
increase the MTU by 50 bytes VXLAN will work fine but it is going to fragment the
packet as it sends it into underlay and
that is extra CPU cycles we can save on our egress and ingress switches.
- Increase MTU by 50 bytes on every layer 3 link in underlay.

SDA Controller Layer

====================

- DNAC is the heart of SDA infrastructure, DNAC is the SDN controller that is going
to push all of our configruation/policies down to the network.
- DNAC is currently physical applicance only and we have a option to deployment
either 1 or 3 of DNAC.If we deploy 3 that will be a cluster and we will be dealing
only 1 DNAC logically.
- DNAC is OOB management i.e if it goes down the network will be up and functional
because all the intelligence is in the network switches.
- There are two different subsystem of DNAC:
* Network Control Platform (NCP) [APIC-EM] - NCP perfomrs configurations leveraging
CLI, SNMP and NETCONF.
* Network Data Platform (NDP) - Responsible primarily of Network Assurance, NDP
pulls infomration from switches like syslog, SNMP, Netflow, Streaming Telementary.
We will put all of the data into Assurance Engine, It is look all data and derive
value from it.
eg: We are running out of IP addresses or TCAM space on a switch, NDP will
proactively alert us via Network Assurance concept.

DNAC configures/control ISE for us using REST APIs.

ISE also has subsystems one of which is Policy Administration Node (PAN) the REST
APIs will be directed to PAN that is how DNAC communicates with ISE.

SDA Management Layer

====================

When we are managing SDA fabric we are going to leverage the SDN controller DNAC.
We have two primary ways of interfacing with this controller.
1) WEB GUI to manage and maintain SDA fabric, However on the backend of WEB GUI it
is simply using REST APIs inorder to configure and make changes to DNAC.
2) REST APIs - We can use applications like POSTMAN and run direct REST API calls
in order to exact same thing as WEB GUI.

Whatever methodology we use (WEB GUI or REST APIs) DNAC will then take that
configuration and push it out into the network.

As part of the management layer, Cisco builds a four step workflow for us to follow
when setting up and maintaining our SDA fabric.
This four workflows shows up inside of DNAC, WEB GUI specifically has these four
workflows available to us click on and to perform configuration with in each one.
So in a way these four workflows are simply different secitons of WEB GUI itself.

1) DESIGN WORKFLOW:
-------------------
- This is where we going to setup our Network Hierarchy i.e we going to define
SITES (GEOGRAPHICAL LOCATION, BUILDING, FLOOR NO)
- We are also going to create NETWORK SETTINGS here i.e IP POOLS, DNS, DHCP
- Image Management - A centralized way of managing images that we push out to all
of our network devices.
- Network Profiles - Network Profiles allows us to standardize network
configuration for different locations.

2) Policy WORKFLOW:
-------------------
Policy workflow is going to be focused on two main configruation points.
- Macrosegmentation :
* Macrosegmentation is equivalent of VRF and SDA fabric it is called VIRTUAL
NETWORK (VNs).
* Macrosegmentation is all about keeping separate network seperated from one
another e.g. two different organization or two different departments in an
organization.
- Microsegmentation : Microsegmentation has do with SCALABLE GROUP TAG this is what
defines if the devices in the same network can speak to one another.

3) Provision WORKFLOW:
---------------------
We define what our devices are and we discover them on the network, we then connect
the policies we defined in the policy workflow and connect them to sites we defined
in design workflow.
We can also deploy services here as part of this workflow.

4) Assurance WORKFLOW:
---------------------
NDP pulls infomration from switches, It looks at the all data and derive value from
it and tries to figure out whats going in our network.
This delivers benfit to us such as a health dashboard which gives us at a glance
picture of the state of our network.
It also gives us trends and insights happening in our network.
It provide us 360 views - gives us really indepth look at a particular client or a
network device, It gives us everything that is there to know about whats happening
about a network node.
This will be instrumental for us when we are trying to solve a problem.

***************************************************
3-Explain Software-Defined Access Fabric Operation
***************************************************
========================
SDA Control Plane - LISP
========================

LISP was developed by Cisco for service provider space and not for Campus network,
yet Cisco found a way to repurpose it in new way with new benefits.
We have a problem in large networks that is every single device in the network
should know, where every single subnet is.

LISP Terminology
----------------

* Endpoint Identifier (EID) = IP address

* Routing Locator (RLOC) - This how we will locate a network device, The RLOC
essentially equivates to a Layer 3 interface on the switch i am attached to could
be a physical interface or loopback.
- RLOC represents the switch that connects (the endpoint) to
fabric.
We are going to build a Mapping Server on the network that tracks all of the
endpoint identifier (EID) to RLOC mappings as such the switch will check in with
mapping server and say
i know the EID where i am going but i need to know the Routing Locator (RLOC) ,
(the packet is not send to EID it will send to RLOC).
So the devices in the path only needs to know RLOC they dont need to know where all
the EID are any more.

So once the destiantion switch receives it how will it know to send the packet to
actual EID (as the destination IP was set to RLOC of switch).
We will acheive it by tunnel encapsulation, we will add a new IP header (with RLOC
as destination IP) on the actaul IP packet, when received by RLOC it will open and
check the actually header.

Hence will need tunnels between all of the Fabric edge switches.
But LISP as tunneling mechansim is Layer 3 only, Hence we use VXLAN to create layer
2 tunnel and share subnets between two endpoint devices.

======================
SDA Data Plane - VXLAN
======================

- Virtual Extensible Local Area Network

VXLAN is tunneling mechanism that gives us layer 2 connectivity.

Part of the Goal of SDA faric is to eliminate protocols such as the STP, FHRP.
These protocols are necessary when our network is layer 2 but we are going to
deploy a layer 3 underlay.

Layer 3 network is great until we want to share VLAN and subnets.

As discussed we going to take loopbacks on our edge switches and are going to turn
them to RLOC that is part of LISP mechanism for tracking the EIDs, LISP going
create a database that maps RLOCs and EIDs.
We create our overlay by building tunnels as full mesh among all of the fabric edge
nodes. We no longer care what the underlay is we care what overlay is.
If overlay is layer2 capable that means we can still share our subnets and VLANs
between our switches.

VXLAN carries the original ethernet header which allows for layer 2 transport that
means we can share VLANs.
VXLAN also supports layer 3 segmentation this would be for Virtual Routing and
Forwarding instances (VRFs).
So not only we could differentiate between subnets with the network like VLANs, we
can also differentiate between networks themselves like different organizations
sharing a space (multi-tenant).

Cisco needed VXLAN to carry one more piece of information that is SGTs that are
managed by Cisco Trust Sec (CTS). so to carry SGT information Cisco tweaked VXLAN
so we call Cisco VXLAN deployment as
VXLAN-GPO (Group Policy Option).

These VXLAN tunnels are going to be UDP based, We going to build these tunnels
between devices we call VXLAN TUNNELING ENDPOINT (VTEP).

Fabric Edge nodes or called VTEP (in VXLAN) connects to end users and down stream
devices that are not part of the fabric.

======================
SDA Policy Plane - CTS
======================

In earlier networks the security was not built in it was layered on top, Cisco knew
that the security has been to foundational with SDA solution and they included
security in form of CTS.
Network security is not a simple task there are lot of different areas of security
in a network any given time.
However the base level is the concept called ACCESS-CONTROL (Who can talk to who
within a network?)
This is built-in to SDA solution from ground up to control who can talk to whom, we
dont need to rely on ACLs and firewalls to do our access control for us, we can do
that in the network itself.

There are two different levels of ACCESS CONTROL:

* MICROSEGMENTATION
-------------------
- MICROSEGMENTATION is concerned with ACCESS CONTROL within a network.
- a VLAN/SUBNET or within a single Organization. We can get granular and specify
which host can talk to which host.
- MICROSEGMENTATION is managed with SCALABLE GROUPS (SGs).
- We are going to identify SCALABLE GROUPS (SGs) using SCALABLE GROUP TAGS (SGTs),
SGTs are also added to VXLAN header.

* MACROSEGMENTATION
-------------------
- MACROSEGMENTATION is concerned with ACCESS CONTROL between networks.
- Between Departments of same organization or two different organizations sharing
same network.
- for MACROSEGMENTATION we use a concept called VIRTUAL NETWORKS (VNs). We are
going to identify this using VIRTUAL NETWROK ID (VNID), this a specify field in
VXLAN header that we are going to carry with us
when we are transporting traffic.

We might have a single physical network shared among multiple entities those
entities could be different organizations or could different departments within our
organization.
We are going to create multiple Virtual networks (VNs) (think of it as VRFs),
multiple VNs in the space physical space.
When traffic is traversing through network we identify which Virtual Network (VN)
you are part of and we make sure that traffic streams never cross one another (i.e.
there are walls erected between VNs).
However we want certain VLANS within our organization (VN representing my
organization) should not talk to one other, that is where we are going to
implement the concept of Scalable Group (SG).
We can have multiple Scalable Groups (SGs) within my fabric and then i can define
policy between those SGs. eg - I will allow SG(A) to talk to SG(B) and SG(B) to
talk to SG(C) but i will allow SG(A) to talk to SG (C).

So when we have our SDA network and we have fabric edge nodes attached when a
packet arrives one of the fabric edge node it assigns it appropriate VNID and
appropriate SGT and once traffic has traversed
the fabric and it lands on egress fabric edge node its going to evaluate that
policy to find out can this VNID speak out this port or can that SGT speak out that
port.
We define this policy inside DNAC and network enforces this policy at the switch
layer, we dont need firewalls and ACLs that are manually created to do this instead
we focus on our policy.
e.g Guest user can only access Internet and not internal resources, Teh policy is
built around who can talk to whom.
All configuration is performed on DNAC however DNAC is not reponsible for pushing
that configuration out instead we connect DNAC to ISE and ISE responsible for
pushing the configuration out to the infrastructure component.

===================
User Authentication
===================
Anybody can login to our network and claim to be whom whoever they want unless we
lock down our authentication process.
SDA there is a bigger problem we are aassign the SGTs we got the VNID for Virtual
Network (VNs), So if we are going to assign appropriate SGTs and VNIDs we need to
know Who you are.
Now we will see how SDA authenticates its user.

We have three primary mechanism for authenticating users when they login to the
network.

802.1x :
------
- 802.1x has three main components that are part of the process
1) SUPPLICANT - (endpoint or software running on the endpoint that will perform
802.1x authentication)
2) AUTHENTICATOR - AUTHENTICATOR is going to be upstream networking device and we
call it Network Authentication device (NAD)
3) AUTHENTICATION SERVER - Authentication server is the database that knows all of
the users on the network, In the case of SDA we use ISE. ISE can be tied to
existing directory services like Active Directory (AD).

When device connects to this network, the NETWORK AUTHENTICATION DEVICE (NAD) is
going to send Extensible Authentication Protocol (EAP) message it requests the
credential from the user attached to the network.
So the user is going to send the credential upto the NETWORK AUTHENTICATION DEVICE
(NAD), AUTHENTICATOR is going to use RADIUS protocol to send that credentials to
AUTHENTICATION SERVER.
It the credentials are valid then the server is going to respond with a access
accept message and then the authenticator know to allow that traffic on the
network.
Futher more in SDA environment we now know the VNID and SGT to assign to this user.
(If the credentials are invalid the authenticator will block access on that port).

There are some device that cannot do 802.1x authentication.

eg IP Phone depending upon manufacturer might not have 802.1x built in and might
not support installing supplicant on to it, this scenario requires use of different
authentication methodology.

MAC AUTHENTICATION BYPASS (MAB):

--------------------------------

This methodology is used for any device that does not support 802.1x such as card
reader, printers, IP cameras, Phones.

The way it is going to work is that the NETWORK AUTHENTICATION DEVICE (NAD) i.e.
SWITCH is still going to attempt send that EAP message however after a certain
amount of time its going to realize you havent responded to EAP messages
therefore i am going to attempt backup process MAC AUTHENTICATION BYPASS (MAB) we
are still going to engage AUTHENTICATION SERVER (ISE) and we going to send the MAC
ADDRESS,
In order this to work ISE needs database of all the MAC addresses that we going to
use for MAC AUTHENTICATION BYPASS (MAB) which means we have to assemble this
database and is not the easiest method to deploy.
So we assume that the database is populated and ISE receives a request from NAD
with a specific MAC ADDRESS that is in the database, ISE will send a message that
allows the device to access the network.
Since ISE is the one sending message we can still assign SGTs and VNIDs
accordingly.

WEB AUTHENTICATION (WEB AUTH):

------------------------------

What if our device dont have the capability to speak 802.1x and we have to install
software in all device it can be painful process, WEB AUTH seems to solve this
problem for us.
The way it works is by allowing the Endpoints to have access to a website that
allows the user to login, The way this is going to work we are going to pass DHCP
and DNS to the host.
At that point the next web request going out the network with this specific website
that allows the uers too login and user provides credentials.
And if the credentails are valid the NAD allows that particular device on to the
network and we can assgin sGTs and VNIDs.

===================
Endpoint Onboarding
===================

SDA = FABRIC EDGE NODE

VXLAN = VXLAN TUNNELING ENDPOINT (VTEP)
LISP = INGRESS TUNNELING ROUTER (ITR) and EGRESS TUNNELING ROUTER (ETR)

When traffic arrives on ITR we are going to assign it a tag and when that traffic
arrives at ETR and wants to be forwarded down stream before we forward it we need
to enforce the policy we have set.

How do we know where to send this traffic?

Keep in mind we have tunnels that have been established among all of the fabric
edge nodes.
So we need to know where the RLOC are (we need send the packet with destination IP
of destination RLOC).
But how do we know which RLOC we sending this traffic to? - This is where the
control plane node comes into play its job is to tell us where to send the traffic.
For Control Plane Node to tell us this information it needs to RLOC to EID mapping.

Lets say we have two clients trying to communicate with each other with IP address
a.a.a.a and b.b.b.b, when a client (Client B) is attached to the fabric edge node,
that fabric edge node is going to send
a map-register to the control plane node the map-register includes EID (Endpoint
Identifier) which in this case is b.b.b.b, so we map our EID to the RLOC (loopback
address of source FEN).

Now lets say we are going to initiate traffic between these hosts, client A
(a.a.a.a) sends the packet to the network with a destination IP address of b.b.b.b,
now the ITR receives that traffic and its going to
send a message to control plane node and that type of message called a map-request
we are providing to control plane node destination IP address and we need the RLOC
(which switch the endpoint belong to).
As such the controlplane will send a map-reply back to the orginating ITR this
message contains EID to RLOC mapping and ITR is going to save it in its CACHE this
entry will remain in cache upto 24 hours of inactivity.
Once we have no activity on that particular EID we will drop it from our cache that
means when needed we need to request the information again from upstream control
plane node.
Any other node on the ITR needs to traffic to client B will rely on the cached
entry we no longer need to bother the control plane node.
So now we have everything we need, when the packet arrives on the ITR it going to
encapsulate that packet into VXLAN tunnel and send it across to appropriate RLOC
which belongs to the ETR for that EID.
At ETR we are going to de-encapsulate it and enforce any policy defined based on
those tags and assuming the traffic is allowed it will forward down to IP address
b.b.b.b

Keep in mind one of the benefits of LISP in SDA is that our core network does need
to know where client B lives all we need to is where the RLOC is in the core
network.

What about Wireless endpoints how does those get onboarded on SDA fabric

In a SDA fabric we are going to have wireless APs connected directly to fabric edge
nodes that this point FEN is going to register with control plane node the EID for
the access point and beacause AP has received the IP address by DHCP or static.
The EID gets mapped to its RLOC, now at this phase AP is concerned with finding the
Wireless LAN Controller so AP is going to reach out and form a CAPWAP tunnel to
where ever the WLC lives on the network.
However here is where the things get a bit different this AP is going to form a
VXLAN tunnel to upstream Fabric Edge Node, now when a client associates this WAP
the AP is going to send the client info through the CAPWAP tunnel
and WLC is going to register the device with the control plane node from a mac
address perspective its going to say that EID from layer 2 perspective belongs to
APs RLOC.
However the wireless client is also going to show up on the upstream switch (FEN)
and the FEN will perform another MAC register message and this is our typical EID
and therefore the control plane node will also have that clients EID mapped to the
switchs RLOC.
At this point wireless clients will be dropped on to the wired fabric as if they
are directly attached to that switch this is different from traditional LWAP
because in those environments the wireless clients are send through the CAPWAP
tunnel but not so in SDA fabric.
NUTSHELL
--------
1. ETR sends map-register to Control Plane Node.
2. ITR sends map-request to Control Plane Node.
3. CP node sends map-reply to the ITR.
4. ITR caches entry, forwards traffic.

Wireless
--------
5. Wireless APs forms VXLAN tunnels to Fabric Edge Nodes. (Control traffic -->
CAPWAP tunnel, Data traffic --> VXLAN tunnel)

================
Endpoint Roaming
================

When we move from one switch to another in SDA fabric what does it mean from
roaming perspective.

We know how endpoints become onboarded on a SDA fabric part of that is reporting to
control plane node when a new client shows up.
To understand We will start from a place where all of the endpoints are registered,
So control plane node knows that IP a.a.a.a (EID) is mapped to switch 1 (RLOC).
We also know that IP b.b.b.b (EID) is mapped to switch 2 (RLOC).

As we know all of the fabric edge nodes have VXLAN tunnel between them when Client
A sends a packet towards Ip address of Client B (b.b.b.b), switch 1 is going to
reach out to control plane node and
ask where is IP address b.b.b.b (that will be map-request message) the control
plane node will forward the map-request to switch 2, switch 2 will send map-reply
to switch 1 and switch 1 will know
IP address b.b.b.b is mapped to switch 2, so the packet is forwarded out of
appropriate tunnel.

Now lets say IP address b.b.b.b moves from switch 2 to switch 3, its no longer on
switch 2 and therefore the fabric needs to be updated.

Here is the process:

- switch 3 is going to regular process a new client showed up it will send MAP-
REGISTER MESSAGE to control plane node and say IP address b.b.b.b is attached to
me.
- Control plane node will look into its database and say i have already got entry
for IP address b.b.b.b via switch 2, so i will remove that entry and create a new
entry via switch 3.
- Furthermore the Control plane node is going to send an update to switch 2 to say
IP address b.b.b.b is no longer on your device (because as far switch 2 is
concerned it may think Client B is silent it does not know if the client has left
the switch).
- So the switch 2 updates its table as well, now if any new request comes to
control plane node for IP address b.b.b.b its going to send a reply specifying
switch 3.
- But we still have one problem the (client b.b.b.b via switch 2) entry is still
cached on the other switches in the fabric like switch 1.
- The control plane node can send a update to switch 1 as well but imagine a fabric
with thousands of switches, if the control plane will send thousand of message
every time a client roams it will waste resources.
- So instead we adopt a methodology that will update the enteries on a as needed
basis, so next time client a.a.a.a sends something to client b.b.b.b switch 1 is
going to receive that check the destiantion IP address and check its cache entry it
will send it to switch 2 (as per cache entry).
- Switch 2 will receive that packet and will send a update back that IP address
b.b.b.b is longer attached to me (switch 2) it is now attached to switch 3.
- At this point switch 1 will update its cache entry as IP address b.b.b.b is
attached to switch 3.
- Also in meantime switch 2 will forward the packet to switch 3 on behalf of switch
1 this way we dont loose any traffic as part of dynamic updating process.

NUTSHELL
--------
1. New ETR updates the CP node and CP node will update its own table.
2. CP node will send update to original ETR (where client was original attached).
3. Original ETR now knows where the client is so it can update the other Fabric
edge nodes as they send traffic to it.
3(same point).Original ETR updates other ITR dynamically.

=================
External Networks
=================

Until now our focus was on deliverying traffic from one side of fabric to other.
However we also need to interface with other networks beside our own fabric e.g. we
may look outside the fabric for Data center resources, or Internet.
In order to connect to those external networks we will need FABRIC BORDER NODES.
Cisco defines three different types of fabric border nodes that we need to be aware
of:

1) Internal Fabric Border Node - Internal Fabric Border node connects to other
parts of our own network that happens to not be part of our SDA fabric.
With help of FUSION router an Internal Fabric Border Node will exchange routes
upstream with internal networks. It is responsible specifically for forwarding our
SDA routes out to rest of the network, so they know were to go when need to speak
to SDA subnet.
Meanwhile its also responsible for forwarding external routes into the fabric but
we cant use IGP for this as we are not using IGP inside the fabric.
So how do we get this route inside the fabric?
So in this case we are going to acts a Fabric Edge Node we will follow the same
process we send a MAP-REGISTER message to Control Plane Node, CP Node will then map
subnets being advertised to RLOC of Fabric Border Node that is advertising it.

2) External Fabric Border Node - External Fabric Border Node is often thought as
the default-gateway of the fabric, Cisco refers to External Border Node as Default
Border Node.
It is responsible for forwarding traffic to unknown destinations e.g. Internet,
Beacuse the External Fabric Node is responsible for unknown IP addresses we are not
advertising anything into the SDA fabric.
However External Fabric Border Node participates in IGP so any upstream network
devices can be aware of SDA subnets.
When a fabric attached endpoint wants to speak to unknown subnets it will send a
map-request to control plane node, CP node will realize it does not have any idea
where that endpoint identifier is.
Therefore the CP node will send a NEGATIVE MAP REPLY to the requesting fabric edge
nodes at this point the switch is going to encapsulate that traffic and send it
upto external border node which will de-encapsulate and forward it on according to
its routing table.
3) HYBRID Fabric Border Node: Cisco calls it ANYWHERE FABRIC BORDER NODE, It will
perform the roles of both internal and external border nodes on a single device. So
if we have smaller network
and we want one device to be connected to internal routes and internet we can do
this by some special configuration.

=================
The Fusion Router
=================

Fusion router a device that isnt strictly required in SDA fabric, however Cisco
does recommends we deploy one.

Fabric Border nodes are going to connect us the rest of the network and we might
need IGP support to bring our routes in and translate those over to LISP mappings
on the control plane node.
How did we translate between IGP and LISP on the border node? (Later in course we
will learn about VRF leaking in order to make this happen)

The concept is this we might have shared services such as DNS, DHCP or NTP servers
and Intenet on the external fabric border node. We might have many different
organization on the fabric and we want this organizations to have access to the
shared resources.
This will the Macrosegmentation concept and VNID how we are going to differentiate
between our different organizations in our SDA fabric, again if we have different
organization therefore differnet VNIDS and different VRFs then how do it deliver
these services such a
way that every single VRF can access them, WE USE VRF LEAKING TO IN ORDER TO
ACCOMPLISH THAT.
But here is the problem deploying VRF leaking dierectly on the border node can
create some configuration challenges and we might not want to deploy this directly
on our border node, this is where the concept of Fusion router comes in to play.
Fusion routers sits in between our existing network and border node it can alsos
sit between internet and external border node, Fusion router is going to run EBGP
peering with our border node and then the FUsion router participates via IGP with
the rest of our network (non-sda).
Fusion router performs redistribution between our IGP and BGP this is how we get
the other network routes into our SDA fabric by advertising them to border node via
BGP and then the border node will register those a ENDPOINT IDENTIFIERS with
control plane node.

IMP:
1) Fusion router is not managed via DNA Center. It will be manually configured for
this purpose.
2) As the Fusion router is not managed by DNAC we dont have restrict requirements
on the type of device we deploy as a Fusion router. We just need to make sure it is
a LAYER3 device and it supports VRF and VRF leaking.
3) As infomred earlier Cisco does not require us to have a Fusion router we could
connect our internal border node upto the core devices and perform the VRF route
leaking directly on fabric border node, but that cause complication with the
configuration.
So Cisco recommends we use fusion router at atleast in medium and large scal
environments.

NUTSHELL
--------
1. The Fusion router performs VRF route leaking.
2. The Fusion router redistributes between IGP and BGP.
3. The Fusion router is not strictly required, but it is recommended by Cisco.
4. The Fusion router is not managed by DNAC.

=================
Anycast Gateways
=================

Anycast is basically sending message out in the network saying somebody help me out
with this i dont care who response as long as somebody does.
Now we will have look into now SDA fabric leverages anycast in order to stream line
default gateway operations, we are going to make those communication more efficient
to our end devices.

Concept of Anycast: Lets we have a network in which two routers both share ip
address 1.1.1.1, this is not good as the downstream third router (connected to both
the other routers via separate interfaces)
needs to choose between those router as far as where 1.1.1.1 lives and maybe we
will load balance or may be we will pick one let say we pick the one on the right
the reason duplicate ip address is bad because what if i need to go to one on the
left.
I can never get there i am always going to the right because the routing table on
the down stream router say that 1.1.1.1 is living on the right.

But that if the two upstream routers share a database what if they have the exact
same information that i am trying to access dont i now care which routers response
to my request and the answer in world of anycast is NO.
I dont care as long as one of these router response and gives me the information
that i need i dont care which one that receives my request.

Now lets apply this to the world of SDA.

In a SDA fabric just like any other network we are going to have switches with
multiple vlans so lets say we have two vlans - Green & Blue so in order for these
clients to get off of there network and out to the rest of the world we need to
assign them a default gateway.
In traditional network we would apply that default gateway to distribution layer
and as the distribution layer contains multiple switches we will assign a First HOP
Redundancy Protocol to split the default gateway to multiple switches, that how we
used to do things.
We dont do this now because we dont have the distribution layer any more, this is
now the underlay and as mentioned many times the underlay has no idea where the
client live as result we cannot put the gateway inside the underlay where the
distribution lay used to be.
So where are we going to put those default gateways?
So lets say for a moment we are going to put the default gateway in one location,
lets suppose we add our default gateways on switch 1, the problem with this setup
is inorder to communicate with vlan we have to go through our gateway on switch 1.
So in order for two clients communicate we have to follow a very inefficient
traffic pattern which includes travelling upto the default gateway getting routed
over to other SVI and then being pass down to other host.
Certianly this isnt a ideal situation how do we get around of this problem of where
we put our default gateway?

This is where the concept of anycast gateway comes to play the idea of anycast
gateway is to say yes we will install the vlan 10 interface on switch 1, we are
also going to install the vlan 10 interface on switch 2 and switch 3 and every
other fabric edge node in the domain.
the same is done for vlan 20. Now lets look in the traffic pattern, if the two host
wants to communicate with each other we send it upto the default gateway (on FEN)
we get routed to other SVI and we get pass down to other switch. (the traffic stays
local).

But what happens if the host migrates to another switch now e.g switch 3 and we
need to connect to default gateway on switch 3 for this to happen the default
gateway IP address on switch 2 and 3 must be same.
Otherwise we will need a new default gateway when we migrate and we dont want to
change gateways as we roam around the network, therefore we need to use exact ip
address for all the fabric edge node on each vlan interface.
So is it a problem duplicating all this IP address? Answer is No because we using
this IP address for local communications only.
If we needed to use this SVI for something else lets say i needed to telnet to one
of these switches for example then i could use this duplicated ip address because
as i come into the fabric it forward me out to one of the switches.
This is isnt the purpose of SVI, so long as the communication is focused on using
this as our default gateways and then we are absolutely fine and this is a brillant
solution,
not only it keeps traffic local to the switch but also eliminate the needo of FHRP.

NUTSHELL
---------
1. Each SVI gets assigned to every Fabric Edge Nodes.
2. Local endpoints use the local SVI.
3. FHRPs are not required in SDA.

===============
SDA Packet Walk
===============

Lets suppose we have established VXLAN tunnels among our Fabric Edge Nodes, and
host A comes on the network (connected to switch 1).
Switch 1 will only come to know that host A is on the network when host A sends
traffic, so may be host A sends ARP for its default gateway.
We recall that our default gateway is going to exist on the upstream FEN regardless
of where in the network host A is that is because we are using anycast gateways on
every single FEN in the environment.
Let say traffic is received if switch 1 will send a MAP-REGISTER message to the
control plane node, the control node will now know to map ip address of Host A to
RLOC of SW1.
likewise control plane node will also know that host B is connect to SW2 and will
create a endpoint entry for it.
So now the host A has received the ARP response it know where its gateway is and it
is ready send traffic through the fabric to get to host B, incidentally it will
make SW1 as ingress tunneling router (ITR) and SW2 will be ETR (Egress).
So host A will send its packet upto switch 1, SW1 will receive that and check its
local cache to see if it knows where the destination IP address lives in the
fabric, in this case we dont have entry for B in our cache so we are going to send
map request to control plane node.
MAP REQUEST will specifes host B is endpoint identifier and control plane node is
going to check its database to see where host B lives on the fabric. Control Plane
node will send the information to SW1 in form of MAP REPLY.
MAP REPLY includes EID to RLOC mapping and SW1 will update its cache saying host B
is attached to RLOC 2.2.2.2.

So the packet arrives on SW1 after process we just described, SW1 has a cache entry
for host B so it knows host B is attached to 2.2.2.2. What we are going to do in
this point is we are going to encapsulate it using VXLAN as our encapsulation
method.
What this means is we have change IP address of source and destination so what we
are going to do is take that packet with original source as ip address of host A
and the destination ip address of host B.
Now we are going to place a new header infront of the original header with source
ip address of SW1 (1.1.1.1) and destination ip address of SW2 (2.2.2.2) we are also
going to add the SGT, VNID both of these tags will be included in VXLAN header.
We are now ready send us packet to the fabric, So the packet will arrive on
underlay switch with source (1.1.1.1) and destination (2.2.2.2), the underlay
switch does not pay any attention to the tag it is simply going to pay attention to
DEST IP address.
Do i know where 2.2.2.2 lives?, underlay switch will check its routing table to
find route for 2.2.2.2 (because we are running IGP specifically ISIS in most
cases), therefore that packet makes throught the underlay and arrives safely on
fabric edge node which is the ETR.
The ETR will deencapsulate the packet and remove the VXLAN header in the process of
removing the VXLAN header it will check the SGT and VNID tags if that tag says we
cannnot communicate to host B it will drop that packet. however assuming it is
allowed we going to send this original packet to the host.

Now lets see another scenario:

Now lets say Host A wants communicate to unknown host could be public ip address on
internet, so SW1 will send map request to control plane node, control plane node
will realize it doesnt know where the host is, control plane node will send
NEGATIVE MAP REPLY (NMR) it tells the requesting switch
to send its traffic to external or default border node. in our network it will be
switch 3 with RLOC 3.3.3.3, SW1 will add the details to its cache.
SW1 will encapsulate its packet to VXLAN and its going to make sure to include SGT
and VNID tags, it will forward it up towards 3.3.3.3.
When packet arrives at SW3 it remove the VXLAN header and checks the tags to see to
permit or drop the traffic

**************************************
4-Explain LISP
**************************************

Locator-ID Separation
=====================

As the size of the internet routing table grows it requires the service provider to
deploy very large and expensive router into internet core. We need a solution and
Cisco came up with LOCATION ID SEPARATOR PROTOCOL (LISP).
In organizational network typically have a layer 3 device or router at network edge
in most cases this router will have default route that points to internet, but in
the internet we know we have thousands of routers and they cannot rely on a default
route.

In basic rouring (Destination IP address = ID + Locator). None of the router cares

about identifier they care about locator, Routers are trying to answer where do i
send this traffic next.

Identifier cannot change, we need IP address to be identifier in the network. Wont

it be great if we had different locator, then internet routers will only need to
know the locator to reach the identifier and not the route of identifier itself.
Hence we will tunnel the traffic directly to the destination router i.e we will
take the orginal packet and encapsulate it such that our destination address now is
loopback address of the destination router (locator).
So what does the other routers in path need to know to get the packet to
destination, it needs to the locator (i.e. destiantion router loopback address).
So the packet will travel hop by hop with a destiantion ip address of (destination
router) and once arrived on router it will de-encapsulate and forward it to
ultimate destiantion.

Nutshell
--------
1. Problem: Growing Internet Routing Table.
2. LISP Solution: Locator/ID separation.

LISP Control and Data Planes

=============================

Most of routing protocol prefer to push information out everywhere just incase we
need that information out there, LSIP operates a litte differently it prefer to
pull that information down in an as needed basis.

LISP control plane

------------------
LISP control plane leverages a pull operation rather than a push operation. LISP
will have a mapping server which tracks all of the information so the routers
unlike the traditional routing will have no routes until it needs it.
When a packet arrives on a router which is destined to a particular network at that
point router is going to go out and request that information, that information is
called Routing Locator (RLOC).
RLOC is loopback address of a device that we want to send traffic towards and so
the router will create a packet send it through a tunnel interface that will land
on routing locator.

LISP Data Plane

---------------
LISP has a tunneling mechanism that is used in internet service provider space, As
with most tunneling mechanism we are going to take that packet and encapsulate it
inside another header with new destination address of RLOC.
As routers only needs to know the RLOC hence the routing table size will be much
smaller in LISP domain. Inside the LISP header we will also have UDP header as we
are running LISP on UDP and then we have the LISP header itself.
LISP tunneling mechanism supports both IPv4 and IPv6, UDP port is choosen to be
4341 for the destination source port will vary depends upon how we want to load
balance this with the network.
Inside the LISP heaer we have the concept of instance ID, this instance ID has the
same role as VNID in VXLAN tunnel and its role is to differntiate between different
VRFs.

So when we have traffic that shows up on particular router , the router will reach
out to mapping server and obtain RLOC information this router is called Ingress
tunneling router (ITR) and it sends to destination RLOC which is called Egress
tunneling router (ETR).
Generic LISP term for these routers are XTR meaning it can be ITR or ETR.

Ethernet header is not included in LISP tunneling mechanism therefore LISP is layer
3 only and we cannot use LISP to transfer layer 2 information between two XTRs.

Nutshell
--------
1. LISP control plane pulls information as needed.
2. LISP Data plane is L3-only supports IPv4/Ipv6 uses UDP 4341.
3. LISP tunnels are formed between ITRs and ETRs (XTRs).

LISP Roles and Terminology

==========================

LISP is tracing two primary construct in this environment. 1) Enpoint Identifier

(EID) 2) Routing Locator (RLOC).
Remember LISP wants to separate the concept of identifier from locator. EID in a
LISP environmet is typically going to be a subnet, RLOC is going to be location of
that subnet i.e a loopback interface on ETR.
MAP server saves the EID - RLOC mapping, When a new route shows either via routing
protocol or directly attached. The router will report that subnet to the map server
this subnet is EID and RLOC is loopback on the router.

When traffic arrives at ITR and it needs to know where the subnet lives i.e RLOC
(we might expect that ITR will check with the map server) however for the sake of
scaling in LISP architecture we have another device role that will run on another
router
called MAP RESOVLER. The ITR will check with MAP RESOVLER and not MAP server
directly and MAP RESOVLER will use this information to send back a response to
ITR.
MAP server and MAP resolver can be combined into a single device for smaller
environment.

But what about the domain that exists outside the LISP domain in this case we need
different type of device that sits in boundary between LISP and non LISP domains
this routers is called PROXY (i.e PITR, PETR) = PXTR
PXTR are responsible for translating non LISP communication into LISP fabric and
vice versa, the difference between PETR ad traditionally ETR is PETR does not send
map register message to mapping server instead we going to use it as a it is
default route.
If traffic arrives at ITR and mapping server has no idea where that route best we
can do is to hope that PETR (or default route) has path to that destiantion, so we
going to tunnel that traffic over to PETR and allow it to forward to non LISP
domain.

As PITR its behaviour is pretty similar to ITR where traffic is coming and destined
for a subnet inside LISP domain its going to send its map request to MAP resolver
so it can form a tunnel with proper ETR and forward into LISP domain.

Nutshell
--------
1. MAP server stores the EID-RLOC mappings.
2. MAP resolver handles ITR requests.
3. Proxy ITR/ETR sits at the LISP boundary.

**************************************
5-Explain VXLAN
**************************************

Problems with L2
================

VXLAN is focused solving problems aroudnb building out layer 2 networks, when we
thing about where we deploy layer 2 in out networks two different locations comes
to mind.
1) CAMPUS environmnet (between distribution and access layer).
It creates large broadcast domain as such any broadcast that shows up on one side
of the network will be delivered to every single port that belongs to that VLAN
even if it is in other side of network.
Other problem we start to see is need spanning tree if we have loop in here, if
layer 2 loop we need to block one of the interfaces. we need redundancy we have to
bundle it in ehtherchannel.
2)DATA CENTER we have similar problems with large broadcast domain and STP.

We have only 1-4094 VLANS and in traditional networks VLAN is our best way to
segregate traffic, causing not enough vLANs in Data Center space (multi tenant
environment).

If we use layer 3 between edge and distribution in traditinal network we cannot

share subnets between edge switches.
So we use layer 2 tunneling to solve this problem. The idea of layer 2 tunneling is
to still convert the links between edge and distribution to layer 3 links however
we will then build layer 2 tunnel through the fabric and stretch from switch to
switch.
But the problem is most of the tunneling techniques we have like GRE, IP in IP,
LISP are all layer 3 tunneling only we dont have capbalility in our traditional
tunneling to forward ethernet header inside a tunnel.

Virtual Extensible Local Area Network (VXLAN) gives us layer 2 reachability over a
layer 3 network.
VXLAN supports 16 Million VLANs. 1 VXLAN segment can support all 4094 VLANs,
typically we are going to assign each customer one VXLAN tag and it gives them
access to all 4094 VLANs.

Nutshell
--------

1. VXLAN allows for sharing subnets across L3 boundaries.

2. 4094 VLANs allowed per VXLAN segment.

VXLAN Operation
===============

Suppose our switches are connected via layer 3 fabric and this switches can be
access layer switches or data center rack switches and we want to share same
subnets between the two switches.
Sharing same subnets are typically not possible over layer 3 fabric, however as
discussed before if we build a layer 2 tunnel between two switches now we can
encapsulate this layer 2 traffic in the tunnel
and it shows up on other switch and is part of same broadcast domain. We already
know VXLAN is capable of doing this.

How VXLAN do this and how is different from other tunneling mechanism?

The secret for VXLAN sucess we are going to encapsulate the ethernet header as part
of payload.

NORMAL FRAME
-------------

|Ethernet Header|IP Header|UDP or TCP| PAYLOAD|

If we going to encapsulate this packet into GRE or LISP we are going to strip off
the ethernet header and apply whatever header we are using (LISP or GRE).

Encapsulation information
<------------------------------------->
|Ethernet Header|IP Header| UDP | LISP |IP Header|UDP or TCP| PAYLOAD|
This packet will be send into fabric and then tunneled across to remote device, the
problem is we loose the original ethernet header we need to preserve this if we are
going to transport layer 2 service across the tunnel.

VXLAN will treat entire frame as payload.

VXLAN Encapsulation information

<---------------------------------------------->
|Ethernet Header|IP Header| UDP | VXLAN Header | Ethernet Header | IP Header|UDP or
TCP| PAYLOAD|

By preserving the original ethernet header maintaining the mac address in there we
now call this a MAC-IN-IP/UDP encapsulation. UDP destination port is 4789.

MTU is important or a lot of fragmentation will happen in the network, packets will
reach the otherside after fragmentation but the devices CPU cycles will be affected
if every packet in tunnel has to fragmented and defragmented.

We will typically want to increase the MTU inside this layer 3 space, so question
is how much we will have to increase the MTU inorder to make sure we dont fragment.

Before adding the original ethernet header the payload including the IP header can
be 1500 bytes, that before we add ethernet header which isnt typically considered
part of MTU.

So now for the new payload with new ethernet header in front of it, we need to
figure out what the MTU size could be.

IP header = 20 Bytes
UDP Header = 8 Bytes
VXLAN Header = 8 Bytes
Ethernet Header = 14 Bytes
Orginal Payload = 1500 Bytes
50 Bytes additional header.

If ethernet header has VLAN tag, tag is 4 Bytes, in most cases including Cisco SDA
we can remove the VLAN tag and include that infoamtion inside the VXLAN tag.
Outside SDA VXLAN can carry 50 or 54 additional bytes depending on our
configuration.

VXLAN Header carries space for VNID (virtual network identifier) the spaces
provider for this identifier is 24 bits, we can have upto 16 million different
VXLAN identifer in a network.
Cisco SDA adds VXLAN-GPO it carries SGT which is important to SDA fabric, so both
identifiers VNID and SGT are carried inside the VXLAN header.

In VXLAN VTEP are going to have layer 3 interface that is used to establish tunnel
across the fabric, VTEP also have LAN interfaces, LAN interfaces face the
traditional layer 2 network.

When a pakcet arrives on a VTEP, how does the VTEP knows to send it to which VTEP
(desination), VXLAN is data plane only it is not interested to know how we discover
where the in network these devices are.

If we deploy only VXLAN it will use a concept of flood and learn to every single
VTEP in order to figure out where the destiantion lives.
We can use MP-BGP but in SDA we use LISP as a control plane protocol.

Nutshell
--------

1. VXLAN preserves the orginal ethernet header uses MAC-in-IP/UDP encapsulation

(UDP destiantion 4789).
2. MTU should be increased by 50B or 54B.
3. VXLAN needs a control plane.

VXLAN Use-Cases
===============

How we can apply VXLAN to the networks today?

We can have customers on different switches throughtout the domain, first of all we
want to make sure these organisations cannot speak to each other.
second of all we want to provide as much as VLAN possible to these organisations
for their use, with VXLAN we can built tunnel relationships with other switches in
environment.
We can use VNIDs in order to identify which organization is communicating, when
traffic come in from a host in organization (eg. A) it gets tagged with VNID of
organization A transmit it to other side of the
network. When that traffic lands on remote switch it will deencapsulate the traffic
and only gets forwarded to interfaces that belongs to organization A.
This allows us to deliver entire range 4094 VLAN to each organization, so this
allows us to scale our data center to as many access switches as needed in order to
support all the client that exists in that data center.

For Data Center Cisco build ACI, ACI works similarly by creating VXLAN tunnels
among edge devices, topology will be spine and leaf.
APIC controller will perform configuration of all the VXLAN tunnels.
Another place we benefit from VXLAN is Campus fabric i.e SDA. DNAC is controller
used in SDA.

**********************************************
6-Identify Software-Defined Access Components
**********************************************

Catalyst 9K Family
==================

Unified Access Data Plane - UADP is programmbale ASIC, it is the secret sauce of
Catalyst 9K.
UADP 1.0 was put into 3650/3850 line of switches, when this switches were out SDA
was not on the horizon for Cisco as such these switches miss the key functionality
i.ie VXLAN.
Without the ability to built VXLAN tunnel these switches cannot be part of a SDA
fabric, however as UADP is programmable Cisco was able to push a firmware update
that enabled VXLAN in hardware on these switches.

Catalyst 9k has the latest version of UADP , and they are built on x86 technology
and the reason for this is Cisco wants 9k to used to support local application
running on these switches.
These switches also run IOS-XE ( is a version of IOS that runs on Linux) i.e Linux
is the foundational OS and IOS runs on it as an application.
WLAN = 9800 - WLC, 9100 - APs
Catalyst 9200 has UADP mini, this is a replacement for Catalyst 2k switches.
Catalyst 9300, we are going to see a lot of these in campus environment as
effectively 9300 switches are replacement for Catalyst 3K, these are stackable and
modular.
Catalyst 9400, are replacement for Catalyst 4K. These are chasis switches
Catalyst 9600 these are also chassis switches with higher features and
functionality, 9600 replaces the Catalyst 6K switches.
Catalyst 9500, the best series to compares these are Catalyst 4500x & 6880x these
are fixed configuration switches they are not chasssis and modular, but they are
intended for Core functionality.
9500 are high performance, fixed configuration lower port count and you will find
lot of these switch in core and distribution layer in network design.

9100 - APs - replaces 1K,2K, 3K

9800 - WLCs- replaces 3K, 5K, 8K

Nutshell
--------
1. Cat 9Ks are the product family for campus.
2. Cat 9Ks leverage the programmable UADP as well as support applications.
3. Cat 9Ks products align with classic Cisco families.

Implement an SD-Access Fabric

=============================

Cisco has two different family of routers that we will like to explore: ISR
(Integrated services router) and ASR (Aggreagation services router).

ISR was primarily built for branch deployment, they look integrating several
technologies in one platform, like Unified Communication - POTS, PRIs, PSTN.
(provides ports neccessary).
We have switching modules, wireless modules, server modules that we can plug into
ISR routers. ISR routers are focused on features more than performance.

ASR line of routers are built to give us performance these are built primarily for
service provider environments and they are focused on table sizes more than
features.
We will not see UC, WLC, server features on ASR.

If we want to deploy ISR into our SDA fabric we need to make sure the right models
that are supported ISR - 4300, 4400
ASR - 1000 are supported in a SDA fabric, 9000 are built for service provider
space.

CSR - 1000v
CSR virtual version of ASR i.e IOS-XE, it simply runs it on virtual environment
(Cloud, our private virtual data center).Either way CSR can function inside SDA.

When it comes to role that we are going to deploy these router into we are talking
about two different roles. i.e. FABRIC BORDER NODES & CONTROL PLANE NODE.
CSR can only be deployed as a control plane node.

Nutshell
--------
1. Features = ISR, Performance = ASR
2. Routers can be a Fabric Border Node or a Fabric Control Plane Node.
3. CSR virtual option, Control Plane Node only.
Other Platforms Supported in SDA
================================

It will be great if we can buy bunch of 9K switches built a brand new isolated SDA
fabric and move all our users into it that would be ideal but not likely.
Can we repurpose the legacy devices to SDA fabric, it is going to be a big part of
our design conversation.

Fabric Edge Nodes Fabric Border & Control Plane Nodes

Wireless
----------------- ----------------------------------
--------

3650} 3850 - supported as fabric border or

control plane node.
3850} UADP
control plane node.
compatible to SDA fabric.
plane node.
4500E -SUP8E, SUP9E
SUP7E will not work as it dont have UADP.
802.11ac Wave 1, Wave 2 devices.
6807 - SUP2T, SUP6T} fabric border or
Any APs that fits to above two category can be
6880-X, 6840-X} fabric border or control
WAVE 1 - 1700, 2700, 3700
6500 - SUP2T, SUP6T
WAVE 2 - 1800, 2800, 3800, 1540, 1560 & 4800
6500 & 6800 does not support IPv6.
WLCs - 3504, 5520, 8540

NEXUS 7700 - can only be a Border node

specifically EXTERNAL Border node.

Extended nodes - the idea of extended nodes is to provide reachability to what

Cisco calls "Non carpeted work spaces" - hostile environments
Cisco has specific products that are built for these environments unfortunetly Cat
9K does not fit into this spaces.
As such Cisco wants to extend the SDA functionality by attaching the products that
Cisco has already developed for the non carpeted spaces into the SDA fabric.
However the way they are going to do this is by having a Fabric Edge Node (FEN)
that extend down to one of these edge node, DNAC will be able to manage and
maintain this relationship however keep in mind
that Extended Nodes are not VXLAN capable and network traffic is passed up a trunk
before getting received and passed on to the SDA fabric via VXLAN.

Non Carpeted work space compatible with SDA

-------------------------------------------
- Industrial Ethernet (IE) switch - 3300, 3400, 4000, 5000.
- Catalyst Digital Building (CDB) - all CDB model are supported in this role.
- 3560-CX ( Quite environment, POE, fanless)

Always Check data sheets.

Extended nodes fit where Cat 9Ks do not.

Trunk
|FABRIC EDGE NODE|--------------|EXTENDED NODE|

DNA CENTER and ISE

==================

The two controllers of SDA fabric - DNA Center and ISE

DNAC is going to be responsible for automation and assurance, where as ISE will be
responsible for policy plane - specifically managing the Scalable Group Tag (SGT).
Currently DNAC is Hardware only and current version of hardware is 2. so if we do
SDA design we have to make sure to get the right version of hardware.
There are three different sizes of DNAC appliances, the size of appliance we need
depends on number of nodes in the network.
DNAC center can be installed as standalone or in a cluster of three. DNAC is out of
band solution that means if DNAC goes down our network will still stay up but we
cannot make changes to our network without DNAC.
So its best to deploy DNAC in a cluster of three so that we have continous access
to our SDA fabric from a management perspective.

ISE has option for hardware and software (Cisco only supports ESXi, KVM, Hyper-V),
Physical appliance is Secure Network Server (SNS) most recent series is 3600
specifically 3615, 3655 and 3695.
ISE is typically deployed as clustered infrastructure if we have to deploy at scale
when we deploy it as clustered application there will be four different nodes that
will be deployed into the environment.
That will be
Policy Services Node (PSN) - responsible for Radius TACCAS communication.
Policy Administration Node (PAN) - which how we will login and manage ISE.\
Manging and Troubleshooting Node (MnT)
PXG - is the PX-GRID controller, PX Grid is the open framework that allows ISE to
integrate with other third party platforms.

Nutshell
--------
1. DNAC is physical only.
2. ISE can be physical or virtual.

*****************************************
7-Design a Software-Defined Access Fabric
*****************************************

Hardware and Software Verification

==================================
Cisco SDA compatibility matrix

1. Cisco updates the SDA compatibility matrix regularly.

2. Always refer to this document when making SDA hardware and software decisions.

SDA Licensing
=============

Cisco has taken a unique approach in licensing a SDA fabric and specifically we
might expect all the licensing is part of our controller (DNAC) however the
licensing is not attached to controller (DNAC) but
the network nodes themselves. We have license the device to participate in SDA
fabric (e.g. Cat 9K or 3650/3850).
The methodology to license these device is split into two different categories:
First of all we have the Hardware or Base license (this is the license that is
applied to hardware itself) but then we also need a software license known as DNA
license.
Hardware/Base license is a perpetual license that will live on the device and
there are two different levels - NETWORK ESSENTIALS (eq LAN BASE), NETWORK
ADVANTAGE (eq IP SERVICES).
This licenses which are perpetual and part of hardware when we buy them these are
going to determine the actual network feature set that we can deploy.
Example if we purchase network essential switch we will not be able to deploy VXLAN
as a technology because that is only included in Network Advantage license and that
functionality is independent of our
interactions with DNA center.

DNA license is for interaction with DNA Center, first thing we want to know about
DNA license is that it is a SUBSCRIPTION with 3/5/7 year options and it must be
purchased as part of a hardware procurement.
These DNA license are primarily going to be concerned how we are going to interact
with DNA Center, because my features are decided by my hardware licensing.

In DNA licensing we have three different tiers:

1 - DNA Essentials package - Basic interactivity with DNA Center, basic level of
automation, basic levels of monitoring, maintenance and managability.
2 - DNA Advantage - Full automation package, this also gives us access to encrypted
traffic and analytics (which is advanced security feature that exists on most CAT9K
platforms (not supported on 9200)).
3 - DNA Premier - is DNA advantage package + security feature, so we get STEALTH
WATCH licenses and importantly we get ISE licenses as part of that package.

When it comes to pairing the software licensing with hardware licensing we have to
always pair ESSENTIALS with ESSENTIALS and ADVANTAGE with ADVANTAGE, we are not
able to place DNA ESSENTIALS licensing on
top of network advantage and we are not able to place DNA advantage on top of
ESSENTIALS that will not work that not an option when ordering a hardware.

As far as DNA Premier is concerned it is essentially Advantage licensing and it

will go on top of Network Advantage.

VXLAN, LISP are only avaiable with Network Advantage licensing, We need full
automation feature of DNA Center to participate in SDA fabric.

However there is one more license we need that will be ISE licensing, ISE is a non
negotiable required part of a SDA fabric as such i need ISE licensing and i have
two ways to get there
1 - Go with DNA Premier licensing that will give me ISE licensing as part of switch
procurement.
2 - Procure ISE licensing directly and purchase additional ISE licenses or i have
it as part another package, unless i dont want Stealth Watch i will not choose DNA
Premier.

Every thing shown in above licensing applies perfectly to CAT9Ks.

Traditional Platforms
---------------------

LAN Base will not cut it in SDA fabric we need atleast IP Base to apply DNA
Advantage licensing.
We can apply DNA Essentials, DNA Advantage and DNA Premier to traditional plaforms.
By the way we can apply DNA licensing to traditional platform that arent supported
in SDA fabric e.g. 2960, 4500-X we still apply DNA Essential licensing to these
platforms this allows basic automation,
management and monitoring of these switches even if they dont participate in SDA
fabric.
ISR/ASR
-------

ISR and ASR mostly follow same concepts, however one thing to keep in mind of this
is that when it comes to SD-WAN licensing that is going to be tied to the DNA
licensing level so DNA Advantage and Premier
will give me better functionality within a SD-WAN environment then a DNA essentials
package would.

Wireless
--------

Key thing to remember is when i apply DNA licensing to access point that is going
to be a license applied to a WLC, when accesspoint show up on WLC they bring their
own licensig to be able to be managed by
that WLC, the license APs bring along with them is DNA license, so we have to keep
our subscription up on wireless APs DNA licensing we want them to particpate in
light weight environment.

Nutshell
--------
1. SDA requires Network Advantage.
2. SDA requires DNA Advantage.
3. SDA requires ISE licensing (DNA Premier is a option).
4. Work closely with Cisco when procuring licenses.

Sizing the DNA Center and ISE

=============================

Cisco DNA center data sheet --> scroll to features and benefit
---------------------------
DN2-HW-APL [Entry] -> Cisco UCS C220 M5 (44 Cores)
DN2-HW-APL-L [Mid-size] -> Cisco UCS C220 M5 (56 Cores)
DN2-HW-APL-XL [Large] -> Cisco UCS C480 M5 (112 Cores)

Cisco ISE Ordering Guide

------------------------

Virtual or Physical

Nutshell
--------
1. Size of DNA Center according to the size of the network - nodes, endpoint, ports
etc.
2. ISE can be virtual or physical and sizing is based on the number of endpoints.

Underlay Design
===============

Underlay is mostly going to be Layer 3 switches that forms layer 3 environment that
allows us to build the VXLAN tunnels.
These underlay devices are typically going to be configured in some kind of
topology does not really matter as far as its a underlay, we going to build overlay
regardless of what the underlay looks like.
First of all this underlay can be layer 2 or layer 3, However Cisco highly
recommends layer 3 (best pratice), for running layer 3 we need routing protocol and
Cisco recommends ISIS.
With automation ISIS is used however if we are doing it manually we can choose our
routing protocol (ISIS recommended, Cisco will support EIGRP and OSPF), we have to
make sure we advertising loopback of devices into the underlay.

When we deploy the WLC its going to be off of the fabric in other words it part of
the underlay, we might have fabric border and WLC hang off that directly attached
or connected either way WLC is not part of \
Fabric overlay, because of that the we need to make sure our wireless access points
needs to reach WLC when they comes online to form CAPWAP tunnel, default route may
not cut it because we may have External Border node
that is connected to fabric and default route will carry that traffic to external
border node and not the internal border node which is probably where WLC is
connected.

Next we need to think about MTU, VXLAN requires either 50 Bytes or 54 Bytes
depending upon if we carrying a VLAN tag, Cisco says our MTU should be set at 9100
Bytes with this even if we are running jumbo frames
we have plently of overhead (100 Bytes).

Cisco recommends point to point link between underlay devices (direct connectivity
between Fabric edge node and underlay devices with minimum 10 G throughput).

IGP timers we know we can tune IGP timers to improve convergence i.e if link goes
down we rapidly convey to rest of the networks to keep everything online however
Cisco does not want us to do this in a SDA fabric.
Instead they want us to use BFD.

As part of rapid convergence we also have to consider the (Stateful switchover)

SSO/NSF (Non Stop Forwarding) protocols this is primarily going to be used in
Chassis switches with nultiple route processors.

Nutshell
--------
1. Recommended: L3 underlay with ISIS.
2. L3 links = Point to point links & 9100 MTU
3. Leverage BFD for fast convergence, plus NSF/SSO.

Fabric Sites and Domains

========================

Fabric is going to be unique collections of edge devices, border nodes and control
plane nodes.
We will have one centralized WLC and unique WLC is not required for fabric site and
it will be shared among multiple sites.
Fabric site is independent of a physcial location, we can have one fabric site that
can spread across multiple physical buildings on a single campus.
We can have multiple fabric sites managed by a DNAC center instance.

For a site with single switch we will not use separate border node and control
node, we use a single device called as Fabric in a box (FIAB).
FIAB is a single device that have Control Plane node, Border node and edge node
functionality in a single box. in this way we can hang endpoints from a single
switch and still be considered a fabric site.

When we have multiple fabric sites managed by a single DNAC instance it is called
a Fabric Domain and when we have a Fabric domain with multiple fabric sites we need
to connect all of the different fabric sites to each other.

So lets take a look how we connect all of the fabric sites within a fabric domai,in
order to connect all the fabric sites we will leverage of something called a
Transit network.
Transit netowrk will connect all of the fabric sites via there external or default
border nodes.
We have two different way of connecting these transit network. First option and
most desirable option is going to be SDA TRANSIT NETWORK, when we deploy a SDA
transit network what we are doing is maintaining VXLAN configuration between sites.
If we are maintaining VXLAN encapsulation that means we are carrying VNIDs and
SGTs, that means if traffic enters in one site goes throught the transit network
and exits out another site and any policy we created is going to be enforced at
that point.
We are able to enforce the policy as we are carrying the VNID and SGT throug ht the
transist network, one other thing to know is when we are using sda for our tranist
network we will need special configured node called as transit control plane nodes.
Transit control plane nodes can hang out of any part of our network however ideally
they are hanging off of transit network. However in order do this we need some
level of control over transit network, Cisco usually recommends this be dark fiber
which means
we are essentially connecting our border nodes to each other directly over the
transit network. However in some cases like Metro Ethernet, VPLS or other layer 2
sevice provider technologies we are also able to bulid SDA transit network in those
environment.
In many cases we dont have control over the network between our sites in those
place we need to leverage IP BASED TRANSIT NETWORK this will be tradintional WAN
service provider options like MPLS or anything that involves routing and you dont
have full control over transit network.
as a result we cannot control MTU, QoS so we will not be able to carry VXLAN Header
as we propogate traffic among our sites, beacuse we not carrying VXLAN we also lose
out VNIDs and SGTs and therefore whenever traffic enters and leaves transit network
and arrives at other site
we are going to have to reidentify at this point if we want to enforce that
traffic.

Nutshell
--------

1. Fabric Site = Unique set of Control Plane, Border and Edge nodes. Fabric Domain
= Many fabric sites managed by a DNA-C instance.
2. Fabric sites can span multiple physcial sites and a physical site can contain
multiple fabric sites.
3. Transit Network: SDA vs IP

************************************
8-Migrate to Software-Defined Access
************************************

Network Migration Principles

============================

Any time we are talking about migration it can be a part of network or entire
network, if we are swapping out core of the network in that case we are probably
dealing with layer 3 connections.
Layer 3 migraton are not that bad, beacuse we are going to have existing layer 3
connections (to existing core) but then we are going to deploy our new core
switches, we connect the existing core to new core via layer 3 and all we have to
do is to connect
the downstream devices to new core this will also be layer 3 connections and as
such we converge on routing protocol the IGP is going to take care of that for us,
once we have layer 3 convergence it is as simple as disconnecting the old lines to
existing core and shutdown device.

Unfortunately layer 2 migration is not as easy, for example when deply new
distribution switches we have to not only connect them at layer 3 but we also have
to connect them at layer 2 this will be a trunk that enables all of the VLANs in
the environment.
Typically the SVI or default gateways are situated in the distribution layer it
will stay old distribution switches for some time, at this point we are ready to
migrate the access layer switches.
One of the two things will happen here either we are going to replace the old
access layer switch with a new switch or we are swinging the connections over, if
we are deploying new switch ideally we have a rack space to install the new switch
next to the old one and we connect it to new distribution.
At this point we are going to take the existing client connection and connect them
to new switch,w can decommission the old switch once all connections are moved.
However if the exisitng access layer switches stay we are going to then migrate the
uplinks to new distribution switch.
But we still have the SVIs on the old distribution layer switches, if we can migrte
all of our access layer switches to new distribution layer switches in a go then we
can shutdown the old distributon layer switches however it is not possible in large
enterprises we have to do this in series of cut overs.
So there will a season where we are running on old distribution and new
distribution at same time, eventually we would have moved enough access layer
switches to new distribution in order to move the SVIs, this is a pivitol point
migration because when we move the SVIs to new distribution layer
thats going to make a lot of changes, first of all we have to consider moving the
spanning tree root over to these new devices as well, second of all we have to
decide whether we are using FHRP we are not using FHRP then we are not using
virtual mac adrress and mac address will cahnge as part of migration process.
So if the mac adress changes for the SVI or default gateways all of the devices we
have to RE-ARP for their default gateways and depending upon client type this can
take a long time so we can expect a pretty heavy outage once we migrate these SVIs
if thats the case, however if we are using FHRP scuh as
HRSP V2 then we are using virtual mac addresses and as the virtual address is going
tobe same whether on old or new switch its no tgoing to change and we dont need to
worry of RE-ARPING process.
Unfortunately even if we are usng FHRP that does not mean we can douge this it can
be we are using HSRP V1, and for moving from V1 to V2 the virtual mac address is
still going to change, or for migrating from VRRP to HSRP and vice versa so always
have to pay close attention to what mac address we are using
in old SVIs and whether we are able to use the same mac address in new SVIs. Now
once the new SVIs are migrated and they are located on new devices at that point we
need to migrate any other layer 3 link on the old distribution switches to the new
distribution layer and decommision the old distribution switches.

Here are some considerations that we need to take as part of this process:

1- First of all we need to think as every network layer as being independent

migration, we saw how migrating a layer 3 core is different from migrating a
distribution layer and migrating distribution layer switches is different from
migrating access layer.
2- We have to think about Rack/Power/Cooling.
3- Port count
4- Port type (what connections are we going to make between old and new devices).
5- Downtime
6- Range of downtime (simple migrations can take time)
7- Backout (possible ROLLBACK)

NUTSHELL
--------

1. Each network layer migrates differently.

2. L2 migrations are complex.
3. Consider and document the full process.

SDA Migration Planning

======================

There are two main types of SDA migration, in general speaking this applies to
normal network migrations as well.

Green Field Deployment

----------------------

-NETNEW (new installation)

- Brand new equipments

Biggest consideration we need to make is the idea of using LAN automation, which is
a feature set that resides inside of DNAC all we need to do is attach our devices
in configuration we want using layer 3 communications, making sure DNAC can reach
those devices
and from there the DNAC will use that automation capabilities to push all of the
configurations down and configure our SDA fabric our us.

Brown Field Deployment

----------------------

- Has Old network - we can either setup a parallel new SDA network or we can
convert old to SDA.
- In brown field we are using brand new equipment we can leverage LAN automation
however that is not the case if we are going to convert our existing hardware into
new fabric we cannot use LAN automation in that case.

Brownfield ocnsiderations:

- Are configured for layer 2 or layer 3 access layer

- Is our old hardware compatible with SDA (if our old hardware are 3650/3850 we can
convert between to SDA). Also check software version.
- Scaling (e.g how many VRFs will be supported on different platforms).

Regardless of it a greenfield of brownfield deployment we need to ask few

questions.
1- Where are we deploying SDA (doesnot fit in DC and WAN space, What we need is a
Global view of our network as part of deploying this SDA fabric, How does SDA fit
in our current network.
2- Second question we need ask is WHAT ABOUT SHARED SERVICES this is specially true
in multi tenant environment we are going to deliver shared services to all of the
tenants at once like DHCP, DNS. SDA allows this its going to take some VRF
configuration in Fusion router to make this happen.
3- What about the security policy? - one of the key benefits of SDN is to implement
security across the entire domain.

Nutshell
--------
1. Greenfield can use DNA Center LAN automation.
2. Converted hardware must be compatible: Hardware, Software and Scaling
3. Think end-to-end big picture. Details matter! Dont add new policies during the
migration (to make sure how it was working before migration it should work after
migration as well).

L2 Border Handoff
=================

If we are going to migrate to a SDA environment that migration can take several
weeks or months, and if we are doing phased migration there can be time that user
on traditional network wants reach user in same vlan on new SDA network, so how
will we acheive this?
Thats what layer 2 border handoff will do for us.
So suppose we have migrated some of our access layer switches to be fabric edge
nodes and we have moved some of VLAN 100 clients to fabric edge nodes so they are
now part of SDA fabric but we havent moved th subnet yet to SDA and some users in
VLAN 100 are still part of old network.
So from routing and switching perspective we know we need layer 2 connectivity
between these two sets of hosts and the problem is if we look at our network the
internal border node will connect us to the rest of the network but this internal
border node will operate at layer 3.
Internal border node or External border node will not help us to reach rest of the
VLAN 100 clients in traditional network, this is where we introduce new device
called Layer 2 BORDER HANDOFF, LAYER 2 Border Handoff will hang off the fabric as
rest of the other nodes
but it will allow for layer 2 extension outside of the fabric. This is going to be
a critical part of any SDA migration because we will need layer 2 extension during
multi phase migration aproach.
Its worth pointing out this is not a normal function of a border node we are using
a special configuration and special node type to make this happen.

ONE KEY REQUIREMENT TO LEVERAGING A LAYER 2 BORDER HANDOFF IS THAT THE SVI's for
the VLANs thats translating must reside ont the LAYER 2 Border Handoff Node, that
means the VLAN 100 SVI that used to be on distribution layer can no longer be
hosted there we need to migrated that SVI to L2 Border handoff node.
As much as possible we would want to move entire subnet to SDA if thats not
possible then we need Layer 2 Border Handoff.

NOTES:
-----
- Layer 2 Border Handoff needs to be a single device, it can be single logical
device which means we can do a stack and multiple physical connection that are
ether-channeled together.
- We have to dedicate this device to be Layer 2 border handoff, Cisco says
technically it can serve as internal border node or control plane node but its best
that we dedicate this for the purpose.
- Layer 2 Border Handoff is vulnnerable to STP as its connected via Layer 2 to
exisitng network.
- We have some RESERVED VLAN that we need to be aware of, VLANs that are reserved
in SDA fabric are VLAN 1, 1002-1005, 2045-2047, 3000-3500 these VLANs are reserved
by SDA and used to specific purposes inside the fabric and as such we are not able
to translate these VLANs between our SDA fabric and legacy environment.
That means if we have VLAN 3100 we need to migrate it to (e.g. VLAN 2900) before we
start SDA migration.

Nutshell
--------
1. The L2 Border Handoff extends VLANs outside SDA.
2. The L2 Border Handoff must be a single logical device and should be in dedicated
role.
3. Some VLANs are reserved in SDA and cannot be extended.

SDA Migration Methods

=====================

Cisco outlines two primary methods to migrate to SDA:

1- Parallel migration - In parallel migration i can build my SDA fabric physically

alongside my legacy network, then move user connections from existing access layer
switch to new fabric border node. This is a wonderful way migrate because i am
building my SDA fabric completely independent from legacy network.
In fact as it is isolated i can use DNAC to use LAN automation at that point i will
connect my Border node to Layer 3 core and supposing that internet is hanging off
from the old core the border will be anywhere border node (functions as both
internal and default border node).
Also the Layer 2 border handoff is only required if we are going to span VLANs
between our legacy network and SDA fabric.

So if i am going to deploy a parallel SDA network thenwhat exactly is my underlay?

We can use the exisitng distribution layer switch as underlay by connecting SDA
nodes (border nodes, fabric edge nodes, layer 2 border handoff ) via layer 3
conneciton connected to distribution layer. Check for available ports and port
type.
layer 2 border handoff will also be connected to distribution switch (layer 2 as
well as lyer 3 connection).

2- Incremental migration - In a incremental migration we are not deploying a fabric

edge switch to existing access layer switch, instead we are going to take that
access layer switch and convert it to fabric edge node.
In order to do this we are going to add the device in DNAC and DNAC will perform
conversion when we are ready, benefit of conversion is our user does not need to be
swung over to another switch.
Another consideration is we are using existing network as underlay then the uplinks
has to be converted from layer 2 links to layer 3 links. (no switchport command on
interfaces)
In most incremental migration we are going to leverage the distribution layer or
core layer as our underlay and connect border node, control plane node, edge node
via layer 3 link and L2 border handoff via layer 2 and layer 3 links.

As we are converting the access layer switches to SDA we need to make sure that SDA
suppots the hardware and software that we are running.

3- Cisco also technically gives us third migration method i.e. HYBRID - use some
new fabric edge nodes and then migrate user to new switch, also convert some of
existing access layer switches. We will use mostly this method in real world.

Nutshell
--------
1. Parallel Migration = Side-by-side deployment (can leverage LAN automation).
2. Incremental = Access switch conversion
3. Hybrid = Mixing both methods

********************
9-Set Up an ISE Lab
********************

Services > Set Wired Auto Config to Automatic to get Authentication tab in Windows
IPv4 client properties.

Coomands to verify if ISE wokring properly after installation:

# show application status ise

# show ip route
# show interfaces

**********************
10-802.1X Fundamentals
**********************

Network Authentication and Authorization

========================================

When we have networks and we have devices that want to connect to those networks,
do we want to allow anything or anybody to connect? In the corporate environment
the answer is NO, we want to know as soon as possible who that individual is behind
the device and then based on that we will
authorize them the access they need, if not authenticated we will perhaps cut the
connection right there, we can acheive this with a technique called 802.1x

There are two methods by which an user can connect to network - 1. Wired 2.
Wireless, it will be ideal to identify an user whether connected by wired or
wireless before the user gets access on to the network, the standard set of
protocol used to do this is 802.1x.

--------- ----------- ------------------

| |-----1------>| | | |
| | | |--------2-------->| |
| USER |<----4-------| | | AUTHENTICATION |
| | | SWITCH |<-------3---------| SERVER |
| | | | | (ISE) |
--------- ----------- ------------------
| -------------------------
<---------5---------->| |
|ACCESS TO LAN RESOURCES|
-------------------------

By default switches have ports in access VLAN once the user connects they are on
the network. Switch can act as an AUTHENTICATOR (Device will ask user who is
connecting for credentials), the users laptop will have a software called as
SUPPLICANT, that software can be third-party or built in the OS
when it gets request from switch it may prompt the user for their identity or may
be preconfigured in the SUPPLICANT
In 802.1x we have Authenticator who is asking questions through 802.1x protocol to
the Supplicant whos is answering those questions, but one of the problems is user
can connecting to one switch one day and other switch another day so how do we
centrally manage, by using an AUTHENTICATION SERVER.
As supplicant on user computer supplies the information that the AUthenticator is
asking for, the authenticator will forward that information to a identity server
(authentication server/AAA server) in this example ISE protocol use on this is
RADIUS.
Authentication server checks the credentials and informs the authenticator to
allow/deny the access based on the success of authentication, beside authentication
of user we can also push down roles regarding authorization as well (e.g user has
got this donloadable ACL or uer is supposed to bein VLAN 30 or 80 or
for using a feature called Trustec we can also push down the switch security groups
that user is associated with to further enforce policy).

Not every device connecting to our network will support supplicant may be its a OS
that doesnt have a built in supplicant or may its device that cant run a supplicant
(printer, IP camera), we can also setup our switch to try 802.1x and if the device
does not respond after short time-out,
use mac-address to do authentication this is referred as MAC AUTHENTICATION BYPASS
(MAB) (MAB is not as secure as 802.1x but its very important to have).

Options for Authentication

==========================

The heart and soul of getting 802.1x to work is having a supplicant on the end
device that can interact with our switch or device acting as our authenticator who
then checks the credentials with our authentication server who verifies the
credentials and allows us to authorize the user on the network.
When we are setting up 802.1x there is a suite of protocol in the family of EAP
(Extensible Authentication Protocol) [options should be supported by supplicant and
ISE]

On Windows
----------

Enable IEEE 802.1x authentication then we can select the method we wan to use.

Microsoft Protected EAP (PEAP) (Protected EAP)

Microsoft EAP-SIM
Microsoft EAP-TTLS (Tunneled TLS)
Microsoft EAP-AKA
Microsoft EAP-TEAP

If we click on Settings, In settings we can also select the authentication method.

- Secured password (EAP-MSCHAP-V2)
- Smart Card or other certificate

We can Use the Replace Credentials tab to change the credentials.

On Switch
---------

# show authentication sessions

# show authentication sessions mac aaaa.bbbb.cccc details

ON ISE
------

We can view logs from Operations > Radius > live logs

Options after Authentication

============================

Once the user authenticates based on our authorization policy on ISE we can do a
lot of stuff,

AV pairs - Attribute Value Pairs instructs the authenticator (switch) what to do.

The port on which user is connected here are few options we can push down the
switch for the port user is connected on.

1- Assign a VLAN (based on authorization profile).

2- Downloadable ACL.
3- Security Group Tag (SGT)

We can also apply policies on MAB (MAC authentication bypass).

****************************
11-Configure ISE for 802.1X
****************************

Identity Stores
===============

One of the very 1st thing we have to have before going to do authentication who
somebody is, is to have that persons record that information somewhere that can be
stored in ISE as local entity or local identity or you can have that information in
active directory and pull the information from there.

To see the local user database on ISE:

-------------------------------------
Work Centers > Network Access > Identites - here we can store information about
Endpoints, Users.

In a enterprise environment we will centrailized solution to get user identity like

AD.

To see the integrate user database on ISE:

-----------------------------------------

Work Centers > Network Access > Ext id sources

Configure ISE to use AD

=======================

Work Centers > Network Access > Ext id sources > Active Directory > Add

Join Point Name: Our-DC

------
Active Directory Domain: ogit.com
--------
Would you like to join all ISE nodes to this Active Directory Domain?
AD Username:
Password:

Specify Organizational Unit:

We can also add AD groups to ISE.

Adding Network Devices to ISE

=============================

Work Centers > Network Access > Network Resources > Network Devices > Add

IP Address:
Device Profile: Cisco
Model Name:

# RADIUS Authentication Settings (Select RADIUS Protocol between NAD and ISE).
# TACACS Authentication Settings (Select TACACS Protocol between NAD and ISE).
# SNMP Settings
# Advanced TrustSec Settings

PROTOCOL: RADIUS
Shared Secret: ****** (Same shared secret should also be added in switch).

Work Centers > Network Access > Network Resources > Device Groups > Add (we can
group devices based on Device Locations, Device Type).

Policy Set Overview

===================
-----------
| ISE |
-----------
|
-------- -----------
|Client|---------------| Switch |
-------- -----------
|
--------
| AD |
--------

Policy > Policy Sets

A Policy set has two major parts 1- Authentication Policy 2- Authorization Policy
(What access you will get once you are authenticated).

Authentication and Authorization Policies is matched from top to bottom approach.

If the authentication is successful then it drops down to authorization profiles

(decide user VLANs, downloadable ACLs).

-----------------------------------------------------------------------------------
--------------------------------------------------------
|Suppress Repeated Failed Clients: Work Centers > Network Access > Settings >
RADIUS > De-select Check on Suppress Repeated Failed Clients| (To see the
difference each time in logs).
-----------------------------------------------------------------------------------
--------------------------------------------------------

Creating a Policy Set

=====================

Policy > Policy Sets > +

To Additionl to Policy Set > Click + under condition (e.g. Policy kicks in if
device is from Site 1, its a Switch)

Authorization Policies
======================

We can use authorization policies and profiles to control what an user can do on
the network.

Work Center > Network Access > Policy Elements

> Results (Policy Elements)

----------

> Allowed Protocols

> Authorization Profiles
> Downloadable ACLs

Authorization Profiles
----------------------

We created two authorization profiles.

ise-admins > Vlan 30

ise-operators > Vlan 80 > DACL applied

Now just having the authorization profile will not going to do us too much good
unless we apply them as part of a policy set.

Policy > Policy sets > Authorization Policy

*********************************
12-Configure a Switch for 802.1X
*********************************

Configure Global AAA Parameters

===============================

conf t
username admin priviledge 15 secret Cisco!23
aaa new-model
aaa authentication login default login
aaa authentication dot1x default group radius
aaa authentication network default group radius
aaa accounting dot1x default start-stop group radius
radius server Our-ISE
address ipv4 192.168.1.105 auth-port 1812 acct-port 1813
key Cisco!23
automate-tester username testuser
exit

aaa group server radius Our-Group

server name Our-ISE
exit

radius-server dead-criteria time 3 tries 3

radius-server deadtime 15
aaa server radius dynamic-author
client 192.168.1.133
server-key Cisco!23
exit

ip radius source-interface gig0/1

radius-server vsa send authentication}
radius-server vsa send accounting } (Helps us send vendor specific attributes)

dot1x system-auth-control (allow switch do 02.1x authentication).

ip device tracking (periodically use arp messages just to verify that address used
by that device is still present and responding)

Configure VLANs on the switch:

-----------------------------

conf t
vlan 10,20,30,80,999

int range fa 0/1-8

switchport host (access port and enables port fast)
switchport access vlan 999
authentication priority dot1x mab
authentication order dot1x mab
authentication event fail action next-method --> (if dot1x fails try mab)
authentication event server dead action authorize vlan 10 --> (in event of server
failure assign VLAN 10).
authentication event server alive action reintialize (when server comes back
online)
authentication host-mode multi-domain --> ( voice and data VLAN device has to
authenticate).(other options single host, multi host[first one authorize remaining
go free], mutli-auth (authorize neeed for all)).
authentication violation restrict --> (violation action > restrict or shutdown)
authentication open (careful - when the switch times out trying 802.1x and mab the
client is simply let through the network). (because of open command the client will
get in even if not using 802.1x)
mab (for mab authentication).
dot1x pae authenticator ( on this port the switch should be authenticator).
dot1x timeout tx-period 5 (time-out to check next method)
authentication port-control auto (let implement 802.1x and control this port
based on whatever ISE says).

Testing and Verifying

=====================
show authentication sessions interface fa0/1

To verify server's identitiy on the client we will need to have a trusted CA that
can validate the certificate

ISE Radius logs

---------------

Operations > Radius > Live logs

******************************************
13-Configure ISE MAC Authentication Bypass
******************************************

MAB Overview
============

Not every device has the ability to support 802.1x supplicant (software that
interacts with switch for authentication and authorization) so what can we do
answer is MAC Authentication Bypass (MAB).
MAB cna be used by IP camera, Printers

So at the switch we have enabled the switch ports to use 802.1x if that times out
it will try MAB, ISE will need the Layer 2/MAC address in some kind of Identity
store an Endpoint Identity store.
ISE will also need to have a policy set for authentication and authorization.

Configure MAB
=============

ISE
---

Operations> Livelogs (to check the reason of authentication failure)

Workcenters > Identities > Endpoints > Inactive Endpoints (To check inactive
endpoints)

Network Access > Identities > Endpoints > + Add and Paste the MAC address. (To add
Endpoint for MAB)

Policy > Policy Sets > Authentication Policy > + (To add new Authentication Policy
for MAB)
} For both the
profiles we need to add Conditions and Profiles.
Policy > Policy Sets > Authorization Policy > + (To add new Authorization Policy
for MAB)

Can we spoof source MAC address, Yes we can so its better using 802.1x

# show authentication session int fa0/1 ( to find downloadable ACL, authentication

method)

****************************
14-Configure Cisco TrustSec
****************************
TrustSec Overview
==================

If we are using dot1x or MAB we can identify who that device is or who that user is
by coordinating with ISE, in addition to knowing who they are we can also use
leverage in TrustSec called Security Group.
Think of Security Group as logical group, it will have members in the group, For
example user Bob who is part of the ISE-operation is authenticate and as part of
authentication and authorization policy we
have aasigned BOB security group called ISE-operations, EACH SECURITY GROUP HAS A
SGT NUMBER (Security Group Tag or Scalable group tag).

User/device Security Group SGT

----------- -------------- ---
LOUIS ISE-Admins 18

BOB ISE-Operations 19

RASBERRY PIE PCB-PCs 20

When the packets from these individuals who are part of security groups are send
into network not only its going to know who they are but it going to include the
SGT tags, this tag is include in CMD field
in the frame of the packets.

TrustSec Security Groups

========================

Their are some security groups that exists by default and we can leverage those, we
can also create security groups.

Workcenter > Trustsec

Components > Security Groups > + (To create new security group)

Name SGT (Dec/Hex)

Auditors 9/0009 ---> (9 is SGT)

Security Group is useless, unless it is part of policy.

Security Group ACLs

===================

Security ACLs specifies what is allowed.

Workcenters > TrustSec > Components > Security Group ACLs > + Add

Name : NO_ICMP
-----

Security Group ACL content:

--------------------------
deny icmp (rule 1)
permit ip (rule 2)

Name : NO_TELNET
-----

Security Group ACL content:

--------------------------
deny tcp dst eq 23 (rule 1)
permit ip (rule 2)

Next we have to implement TrustSec policy calls upon Security Groups and Security
Group ACLs.

TrustSec Policies
==================
Deny Telnet
ISE Admin & ISE Operations -----------------> PCB-PC

Deny Telnet
PCB- PC -----------------> PCB- PC

Work Centers > TrustSec > TrustSec Policy > Egress Policy > Matrix > + Add

Source Security Group: ISE_Admins

Destination Security Group : PCB_PCs
Status: Enabled
Assigned Security Group ACLs: No_Telnet

Source Security Group: ISE_Ops

Destination Security Group : PCB_PCs
Status: Enabled
Assigned Security Group ACLs: No_Telnet

Use View > Conensed with SGACL names (to view only SGACL with relationships).
Use View > Full with SGACL names (to view all)

Configure Network Devices for TrustSec

======================================

There is a matrix of support where it talks about which devices based on hardware
and operating system, which one support Trustsec and which features of Trustsec.

cts= Cisco TrustSec

conf t
cts authorization list OURSGLIST
aaa authorization network OURSGLIST group Our-group ( Our-group is previously
specified, it talks to ISE).
cts logging verbose (for troubleshooting purpose of DACL or SGACL syntax)
cts role-based enforcement
cts role-based enforcement vlan-list all (which VLANs you want to enforce the
policy, all is every VLAN).
radius-server vsa send authentication (vendor specific attributes)
dot1x system-auth-control

radius server Our-ISE

pac key Cisco!23 (protected access credentials, it has to match with PAC in ISE).
exit

# cts credentials id SW2-3750-136 password Cisco!23 (done for priviledge mode not
config mode, id and password for switch, has to match ISE).

show cts pacs

cts refresh environment-data

cts refresh polic

show cts environment-data ( to view security group available from switch).

show cts security groups
show cts role-based sgt-map all

ISE and NAD TrustSec Integration

================================
Tell ISE about network devices

Work Centers > TrustSec > Components > Network Devices

Name: SW2-3750x-136
IP addres: 192..168.1.136

Device Profile: Cisco

Network Device Group

--------------------
Location: site1
Ipsec: NO
Device Type: Switch

Radius Authentication Settings

------------------------------
Protocol: RADIUS
Shared Secret: *****

> Advanced TrustSec Settings

Device Authentication Settings
------------------------------
_
Use Device ID for TrustSec Identification |_|
Device Id: SW2-3750x-136
Password: Cisco!23

CoA: for ISE to communicate/push down the updates and new policies down to the
switch.

Device Configuration Deployment

-------------------------------

Include this device when deploying Security _

Group Tag Mapping Updates |_|

Device Interface Credentials:

EXEC Mode Username: admin
EXEC Mode Password: ********
Enable Mode Password: ********

Out of Band (OOB) TrustSec PAC

------------------------------
______________
|Generate PAC|
|____________|

Click on Generate PAC.

Identity: SW2-3750x-136
Encryption Key : Cisco!23
PAC Time to live: 1 Week

Now this switch is also capable of understanding, cooperating and enforcing policy
based on TrustSec.

Verify TrustSec
===============

SXP is a method of communicating Security Group Tags (SGT) mappings to switches

over network that dont completely support end to end Cisco TrustSec.

Operations > Live logs

Policy > Policy Sets (Policy sets regarding initial authentication, what is
supported and if it is matched then we go to individual authentication and
authorization policies).
Work Centers > TrustSec > TrustSec Policy (which Security Groups can talk to which
Security Groups)

show cts security groups

show cts role-based sgt-map all (client SGT mappings)
show cts role-based permissions ( SGACL policy )
show cts role-based counters (counters for SGT policies permit and deny).

SGT eXchange Protocol (SXP)

===========================

One of the important features of TrustSec is that its embedded the SGT inside the
frame, Cisco devices can forward this frame however in many environment we dont
have all Cisco devices.
So if we have a non Cisco device along the path from point A to point Z it will not
be able to propogate SGT properly, so to solve this problem we have a method to
advertise the tag so it will be
routed and forwarded on non cisco devices and at the every end destination you an
ship over with a protocol over the network to tell the network access device (NAD)
here the tags involved so that the end device
switch can till enforce policy, this is done by a protocol called SGT eXchange
Protocol (SXP).

We can setup in such a way that ISE is the SXP SPEAKER, SW-A & SW-Z are SXP
LISTENER in this way they can get all the group information, this will be above and
beyond the relation they already have with ISE.
So we will have to configure ISE and Switch to support SGT eXchange Protocol.

SWITCH
------

conf t
cts sxp enable
cts sxp default password Cisco!23
cts sxp connection peer 192.168.1.105 password default mode peer speaker hold-time
0 0

show cts role-based sgt-map all details

On ISE: Work Centers > TrustSec > SXP > SXP Devices > + Add
------

Name: SW2
IP address: 192.168.1.136
Peer Role: Listener
SXP Doamin: Default
Status: Enabled
Password: *****

Go to ALL SXP MAPPINGS (to see all the SGT mappings that will be advertised)

We using SXP with DNAC

----------------------
On ISE:

_
Administration > System > Deployment for SXP and pxGrid enabling > Select the ISE
server > Under Policy Service > |_| Enable SXP Service
_
|_| PX Grid

show ip device tracking all

show cts role-based sgt-map all

show role-based permissions

******************************************************
15-Complete Day 0 Preparations with DNA Center and ISE
******************************************************

Understanding Our Objectives and Attack Plan

============================================
Before doing any thing on DNAC we must have plan, what we going to accomplish.

Day 0 Plan
----------

1. Configure DNA Network - Access to DNAC GUI.

2. Configure communication between ISE and DNA.
3. Configure IPAM integration within DNAC. (IPAM servers like Inflobox, Bluecap -
IPAM provides DDI services, IP address management).
4. Basic User administration (Role-based access)

Using Maglev to Set the IP Address and Password (Maglev is basically CLI for DNA-C
i.e Maglev is equivalent to Cisco IOS)
===============================================

When you turn on DNAC for the first time it goes through a console session where
you have a keyboard and monitor plugged in to it and you need to give the DNAC
appliance a password and a IP address.
The rest of the administration from the DNAC appliance can come from GUI front end,
so when you connect the DNAC for first time you have to walk through a setup
wizard.

Step 1: Select or Start DNA-C Cluster.

You will have to create a cluster even if you have only one DNAC appliance.
You will have one physical IP address for DNAC and a cluster IP address.

This is one of the last step in entire Maglev setup wizard, where you need to
assign subnets for Services and Cluster Services.

-----------------------
MAGLEV ADNACED SETTINGS
-----------------------

Services Subnet: *
192.168.0.0/21

Cluster Services Subnet: *

192.168.8.0/21

Very Important - These network shouldn't overlap with the existing enterprise
network. It this overlaps it will break entire DNAC center appliance cluster
themselves.

At the end of day DNAC is Gigantic Kubernetes host, if you have multiple DNAC host
you are creating Kubernetes cluster.
On the kubernetes host it runs a ton of Docker containers.

If you SSH in to DNAC after all the network configuration is completed, with this
command you can quickly check the status of each of the docker containers.

$ magctl appstack status

if the status is anything other than RUNNING than it would highlight a potenial
problem you are having with your DNAC.

$ magctl appstack status | grep -v -E '([0-9]+)/\1.*Running' (for any container

that dont show successful running status).

Also it can take up to an hour for all the container to be in ready status.

Prepping Cisco ISE for Integration with DNA Center

==================================================

Integration of Cisco ISE with DNAC is critical, for DNAC to do what is designed to
perform i.e implementing a SD-access fabric.
Cisco DNAC uses ISE to create or push policies out to the network its going to use
that SGT to implement SGACLs, ISE is the orchestation plane that makes all of this
happen.

DNAC
----
Settings (RHS top icon) > System settings > Externally Connected Systems ->
Identity Services Engine (ISE) -> IP Address Manager (IPAM)

ISE
---
Administration > pxGrid Services

If this is a green-field deployment these are steps we have to go through inorder

for ISE to be managed by DNAC.

Step 1: Enable pxGrid Services on ISE.

--------------------------------------
Click on ISE node name > Scroll down > Enable pxGrid by checking the box.

Step 2: Integrate ISE with Active Directory

-------------------------------------------

Administration > External Identity Sources > under Active Directory folder you can
ADD an Active Directory Domain

Once you add check the status of AD domain it must be operational.

You also test the login of a user in the domain by clicking TEST USER > Check for
AUTHENTICATION SUCCESS, you can also see their Group membership and Attributes.

You can also import the user groups that you want to use within DNAC environment
(from GROUPS tab).

***Check the pxGrid if any client joined pxGrid services.***

Step 3 : Patch Cisco ISE

------------------------
Make sure ISE is on the right firmware version.

Adminsitration > System > Upgrade (check version)

Adminsitration > System > Maintenance > Install Patches

Configuring ISE Integration with DNA Center

===========================================

So now our ISE environment has been upgraded we have enabled pxGrid and we even
intregated ISE with active directory.

On DNAC Center
==============

System 360 > External Connected Systems > Identity Services Engine (ISE) > Click on
Configure

It will take us to Settings > Authentication and Policy servers > Add (AAA/ISE
server)

Server IP address: ISE IP address

Shared Secret: Used between DNAC and ISE

Turn on CISCO ISE Server

Username:
Password:
FQDN: (of ISE server - to get on ISE go to Administration > Deployment > FQDN)
Subscriber Name: (How we are going to unqiuely identify DNAC in ISE)

Check Status it should be ACTIVE (this active is only on DNAC, we will have to do
some configuration to make status active in ISE).

ON ISE now if go the status on pxGrid ( Administration > pxGrid Services)

On TOTAL PENDING APPROVAL > Approve All

Client Name
-----------
dnac > this will be DNAC front end where you are going to create and push policies

dnac_dnac_ndp > is for assurance

Now if we go and check on DNAC.

System 360 > Externally connected Systems > Identity Services Engine (ISE) - it
will show PRIMARY and PXGRID available. If click on update (it will take us to
Settings > Authentication)

If we run in to some problems with this integration.

---------------------------------------------------
Some what you need to do is under ISE (Administration > pxGrid services - delete
dnac and dnac_dnac_ndp)
Then on DNAC server Settings > Authentication and Policy servers > Edit ISE server
and RETYPE the password it will resync or reprovsion the AAA device.

Configuring IPAM Integration

============================

Another common integration with DNAC is integrating with IPAM and DDI services
[DNS, DHCP, and IPAM (IP Address Management)]

DNAC supports two primary IPAM/DDI service provider i.e. INFOBLOX and BLUECAT,
there is also a generic connector for other IPAM services.

System 360 > External Connected Systems > IP Address Manager (IPAM) > Configure

It will take us to Settings > IP Address Manager

Use this form to set your IPAM server settings

----------------------------------------------

Server Name: infoblox

Server URL: https://192.168.10.6
Username: admin
Password: ******
Provider: Select INFOBLOX or BLUECAT
View: (to create network views within Infoblox)

Click on Apply

Administering Users, Permissions, and RBAC

==========================================

DNAC is your one stop shop for all the network configuration and administration,
Assurance is one of the main reason we want DNAC.

Cisco DNA Center > Settings icon > System Settings > Settings
> Account Lockout - Set account lockout policy
> Password Expiry - Set the password expiration policy

On Users Tab
------------

> Change Password - Update current password

> User Maangement - Create users and assign roles to them
> Role Based Access Control - Manage user roles
> External Authentication - Configure authentication DNAC and ISE server

************************************************
16-Prepare Your Network for DNA Center Discovery
************************************************

We need to make sure that DNAC can communicate with all the components its going to
manage, so we have understand the basics of device discovery and LAN automation.

DNAC is going to communicate to all the devices its going to manage and vice versa
devices also needs to communicate with DNAC.
This communication is going to happen over layer 3 connectivity, so if we dont have
correct routing DNAC will not be able to communicate to devices or vice versa.

DNAC finds the devices by using something called Discovery.for Discovery there
should be layer 3 reachability b/w DNAC and devices.
Discovery task attempts to discover all of the devices that DNAC can manage.
How DNAC does discovery?

Discovery Type: CDP IP Address/Range LLDP

CDP level: Default 16

for Discovery we need to specify CLI/SNMP/NETCONF credentials, after initially

discovering seed device, it will try discover the connected devices.

LAN Automation: With LAN automation we take Discovery a notch up, just like
discovery we have to discovery our initial seed device, but then what LAN
automation can do for us
it can connect in all of the devices and build our underlay fabric for us from
scratch, Discovery was about finding the device DNAC manage, LAN automation can
build the entire underlay fabric
using ISIS protocol with end to end network capabilities and routing.

There are some key steps we have to do before we can use LAN automation:

- We will have to configure network devices to be able reach DNAC.

- Even if device does not have IP address LAN automation will give them IP address,
when the device will have ip address it should be able to communicate with DNAC.
- We need to make sure routing exists between our seed node and DNAC.

At a minimum we can enable static routing between 1) Fusion routers and shared
services block 2) Fusion routers and inital seed node.
But best pratice can actually be to enable IGP like EIGRP between Fusion routers
and shared services block.

Configuring Routing to the Shared Services Block

================================================

Configuring Eigrp between Shared services block and Fusion router

-----------------------------------------------------------------

Shared services switch

----------------------
conf t
router eigrp To-Fusion
address-family ipv4 unicast autonomous-system 100
af-interface default
passive-interface (all eigrp interface passive)
af-interface vlan 2
no passive-interface
network 192.168.1.0 0.0.0.3
network 192.168.10.0 0.0.0.255

show ip eigrp interfaces (confirm hello packets are send only via vlan 2).

Fusion Router
-------------

conf t
router eigrp To-Sharedservices
address-family ipv4 unicast autonomous-system 100
af-interface default
passive-interface (all eigrp interface passive)
af-interface vlan 2
no passive-interface
network 192.168.1.0 0.0.0.3

sh ip route

Configuring Routing to the Seed Node

====================================

Border node is going to be our seed node when it comes to Discovery and LAN
automation.

Between Fusion router and Border Router

---------------------------------------

Border Router
-------------

hostname Border-Router1
ip routing
ip domain-name nuggetlab.local
crypto key generate rsa modulus 1024
username knox priviledge 15 secret cisco

****Any device which is being used in DNAC fabric it should not have IP address on
VLAN 1 ,VLAN 1 is going to be used for UNDERLAY FABRIC when LAN automation comes
into play****
When DNAC goes to discover and create your LAN underlay using LAN automation its
going to use VLAN 1 for that network connectivity links it will also create
loopback addresses on that device too.
****For all the devices that will be participating in SD-access fabric you shouldnt
use any VLAN that is greater VLAN 1000, DNAC can use VLANs greater than VLAN 1000
to represent each of VRFs in SD-access fabric.****

Hence we will use VLAN 101 between Fusion router and Border Router

vlan 101
name To-FusRtr

int vlan 101

ip add 192.168.101.2 255.255.255.252
no sh

int gig1/0/1
switchport mode access
switchport access vlan 101

Fusion Router
-------------

vlan 101
name To-BdrRtr

int vlan 101

ip add 192.168.101.1 255.255.255.252
no sh

int gi0/1/1
switchport mode access
switchport access vlan 101

router eigrp To-Sharedservices

address-family ipv4 unicast autonomous-system 100
network 192.168.101.0 0.0.0.3

Border Router
-------------

ip route 192.168.10.0 255.255.255.0 192.168.101.1

Configuring the Seed Node for LAN Automation

============================================

For LAN automation the devices shouldnt have any configuation.

LAN automation uses Plug and play agents on devices that will allow DNAC to connect
and configure the devices from scratch.
So what we are talking about LAN automation is Green field deployment where
everything is configured the first time.

1st step is to have reachability to seed node (in our case Border router 1)
2nd step is some basic configuration on network device in order for DNAC to be able
to use that device for configuring all of other devices in our SDA fabric.

In order for border router to server as effective seed node we have checklist we
need to go through to make sure device is configured properly.
1st step - MTU 9100 or greater (DNAC center going to send lot of traffic to seed
device, In fact if DNAC detects any of the devices dont have proper image it will
upgrade that device during automation).
This MTU needs to exits in entire path from DNAC all the way to seed device.

2nd step is to enable IP routing.

3rd step is Connectivity to DNAC appliance.

4th step is our interfaces that is connected to all of devices we want to discover
they need to be in default configuration mode.

5th step is Configure device credentials for both CLI and SNMP. (SSH was configured
before)

6th step is no overlapping IP address range with either overlay or underlay IP

address pool.

7th No IP address assigned to VLAN 1 and VLAN 1 will not be able to connect to a
DHCP server.

8th DNAC will configuring a loopback address during LAN automation process.

We we are going to perform LAN automation right now and start creating the underlay
of 192.168.168.0, both the Fusion router and the shared services switch wouldnt
know how to get there.
Border router will know how to get there are it is physically participating in the
underaly environment.
It will be critical to have our Fusion router and shared services switch to have
static route towards our seed device for 192.168.168.x underlay.

MTU 9100
=============================
Border Router |
------------- |
conf t |
system mtu 9100 |
|
|
Shared services switch |
---------------------- |
conf t |
system mtu 9100 |
==============================

Credentials
==============================
|
Border Router |
------------- |
conf t |
|
snmp-server community cisco rw|
==============================

Static route
=================================================
Border Router |
------------- |
conf t |
ip route 192.168.168.0 255.255.255.0 192.168.101.2|
|
|
Shared services switch |
---------------------- |
conf t |
ip route 192.168.168.0 255.255.255.0 192.168.101.1|
==================================================

*******************************************
17-Understand the 4 Workflows of DNA Center
*******************************************

DNAC gives a kind of guided workflow to go through in order to end up on our final
product which is going to be our SD access fabric.
The way DNAC does this is by working through the four workflows and these workflows
is all about designing or preparing our fabric before we actually click submit and
it goes out and builds the SD-access fabric.

The Design Workflow

===================

* First workflow we encouter.

* Setting up what is the design of our campus - Building layout, what is addresses
of our building, floor plan of each building.
****Any configuration that may be specific to any site or building that is what we
are setting up in design itself****

DESIGN
------

Network Hierarchy - Within DNAC we have global hierarchy and down beneath that we
would setup SITES, sites are generic region anywhere around the world we may wan to
choose e.g California, South Africa
Next thing we will prompted to do within that sites is create BUILDING also we can
specify address, we can also specify floors for each of the building.
At each tier of network hierarchy we would make some basic network configuration.
Eg: at global site we can specify what are our CLI credentails.

Network Settings - Here we can configure each of our sites. (You can configure SNMP
and syslog server by default DNAC is SNMP and syslog servers).
The adjacent tabs you can find - * Device Credentails, * IP address pools (you can
assign it to individual sites it will work in conjunction with IPAM, if i have IPAM
integrated),
* QoS - when we have WAN specific QoS requirements, * Wireless

Image Repository - We can upload our custom images in DNAC and specify which
images are our golden images for individual sites.

Network Profiles and Authentication Template - We will create profiles and

templates on how our network should behave or be configured

The Policy Workflow

===================

This is where are going to spend a lot of time in DNAC, which virtual networks
(VN's) needs to exist to create our macro segmentation and which Scalable groups
needs to exist within those virtual network
talking about microsegmentation policy, there will alot communication going on
between DNAC and ISE.

Policy
|
________________________________________________________|
__________________________________________________
| | | | |
Group-Based Access Control IP Based Access Control Application
Traffic Copy Virtual Network

Virtual Network: This is where we are going to define what our Macro segementation
policy is going to be, what are the VRFs that need to exist with in out SDA fabric.
Eg: We may create a VRF for IT and a VRF for HR, within that we will assign users
and groups to this VRF.

First we will create oru Virtual Networks (VN's) and then we will add which groups
needs to be in that VN's.
Now can this group talk to each other or resource within the virtual network that
we will setup when we talk about micro-segmentation.

We can configure microsegmentation by going to GROUP-BASED ACCESS CONTROL >

POLICIES
Acitons: Permit, Deny, Custom and Default
Permit and Deny are called as CONTRACTS
When we choose to create a policy on this scalable groups and contracts this is
going to implemented in Cisco ISE, thats how we can do access based on Groups.

We can also do access control based on IP in IP Based Access Control. It works very
similar to ACLs.

IP Based Access Control

___________|_____________________
| |
IP Networks Groups Access Contract
(Group based on IP add) (Premit or Deny)

APPLICATION POLICIES: This is going to be Queuing and QoS

TRAFFIC COPY: It will use RSPAN and ERSPAN to copy traffic from individual
destiantions all the way back to a PCAP functionality within DNAC.

The Provision Workflow

======================

This is where we actually get to create overlay and underlay networks which
ultimately creates SDA fabric.

Provision begins with discovering what devices are in our network, what are the
devices DNAC can manage and do some basic configuration to atleast establish
connectivity to.
When we discover and do base provisioning of our devices, DNAC will create CLI,
SNMP credentials and NETCONF configurations so it can start streaming telemetry in
ASSURANCE this is before we created
underlay fabric or overlay fabric at this point atleast bring it into inventory and
some basic provisioning DNAC center can then start managing those devices.

It all begins with a discovery, Discovery takes place either by CDP, LLDP or an IP
based discovery. Once those devices are in our inventory we gonna have to go
through LAN automation if there isnt IP connectivity
all the way down to edge node.

PROVISION > DEVICES > INVENTORY > ACTIONS > PROVISION > LAN AUTOMATION (Starting
point will be a border node which has IP connectivity, from there it will jump from
one device to another using
Plug and Play features in order to actually configured LAN connectivity all they
way end to end the entire underlay fabric will created and routable because it will
be implementing the ISIS protocol.

FABRIC TAB
----------
After all the devices are disovered it will then have a logical topology ready for
us to start working with now we can create our overlay fabric, we specify which
virtual network and which devices are connected
to which sites within the design section and the overlay fabric will be created by
DNAC at that point we will have SD access fabric up and running with DNAC

Service TAB
-----------
We can provision our devices to do Stealth Watch Security Analytics, Application
visiblity and APP Hosting (Host and manage APPs)

The Assurance Workflow

======================

So the SD access fabric is up and running, the devices are provisioned, virtual
networks are created, micro-segmentation policies are being enforce by ISE, users
can now plugin and start using SD access fabric.
Now we have to maintain that SD-access fabric, we need to know whats going on in
our environment we need to troubleshoot problems when they come up and this is what
ASSURANCE work flow is all about.

The ASSURANCE workflow is powerful, because it connects in each one of the devices
and it constantly streams data back to Cisco DNAC and not just the network devices
themselves but also about the client -
people who are connected into the network.

DNAC works in conjunction with network devices as well as ISE and it tracks whats
happening on your network at any given time, beyond that it leverages AI and ML to
figure out when there is anomaly or anything
that it should alert of. Assurance is one of biggest feature why you buy DNAC.

In Assurance workflow we can get the Health status of our devices, we can see both
wired and wireless devices and we can also see TOP 10 ISSUE which are discovered by
DNAC (show why it occured and what to do to fix it).
You can view what happened in your network in specific set of time.

DASHBOARD > HEALTH > ISSUE > Wireless Sensors

> Rogue Management > Dashboard Library
| | Whats going with WIFI
- OVERALL HEALTH - OPEN
- NETWORK HEALTH - RESOLVED
- CLIENT HEALTH - IGNORED
 - APPLICATION HEALTH

Beyond this as it is using machine learning and AI it can develop whats normal and
whats not normal for your entire environment using TRENDS and INSIGHTS.

TRENDS and INSIGHTS

|
> Network Insights - Whats going on in our network.
> Network Heatmap
> Peer Comparison
> Site Comparison

Beyodn that we can configure how our sensors or health scores should be behaving
from manage section.

Manage
|
> Issue Settings
> Health Score Settings
> Sensors
> Intellgent Capture Settings

The Platform Workflow

=====================
It allows us to integrate other application within to DNAC, DNAC Platform is the
automation tier of DNAC, basically all of the things we doing within DNAC can be
exposed to a REST API.
So we can pull data out of DNAC and send data into DNAC with DNAC platform.

Platform
|
> Overview
> Manage
> Developer Toolkit
> Runtime Dashboard

****************************************************************
18-Design Create and Configure a Network Hierarchy in DNA Center
****************************************************************

Understanding the Plan for Design

=================================

When it comes to design workflow we need to understand what is the design or layout
for our campus, how are service handled in that cmapus.
We should have a plan for the design workflow.

Design workflow is all about Network Hierarchy, this is talking about what are our
specific sites and location the geopgraphy themselves.
It is possible to have multiple location and DNAC manages multiple locations.

We defined something first called as AREA, area could be as large as you want.
Eg: Area - Lousiana
|-> New Orleans (City)
|-> Buildings (give atleast close address)
|-> Floor

We can now also create entirely different hierarchy for California.

Eg: Area - California
|-> San Jose (City)
|-> Buildings (give atleast close address)
|-> Floor

**** Once we have our network hierarchy established we can start creating site
specific settings, we can have settings that only applies for San Jose, or only for
California****
**** We you set something up in one of these levels it is inherited by the level
beneath it, on top of that you can overwrite those settings in each of the
individual levels****

Within the design implementation we will create configurations that points SD

access site back to shared services, which contains our DC, ISE, IPAM & WLC.

We will also assign the IP addressing for underlay and overlay for this site in
design workflow. (We are going to setup a IP pool for our underlay automation, DNAC
will subnet the pool to /30 subnets for underlay automation.)

Creating a Network Hierarchy

============================

Any site we create beneath the Global site can inherit policy from it, Global is
default site that exists across the entire world e.g: CLI credentials to exists on
every single device around the world you can configure in Global.
So every single site beneath it that does not overwrite inheritance will inherit
it.

To add a site
-------------

Design > Network Hierarchy > + Add Site

|
> Add Area
> Add Building
> Add Floor

You can also import the sites with CSV file.

Add Area
--------
Area Name: Louisiana
Parent: Global

Click on Louisiana
Add Area

Area Name: New Orleans

Parent: Louisiana

Add Building
------------
Click on Gear Symbol near New Orleans
Add Building

Building Name: Nola Main

Parent: New Orleans
Add Floor
---------
Click on Gear Symbol near Nola Main
Add Floor

Building Name: Main Floor

Parent: Nola Main
Type (RF Model): To correctly model RF signal coming from the Wireless AP.
> Cubes and Walled Offices
> Drywall Office Only
> Indoor High Ceiling
> Outdoor Open Space

You can upload a floor map into DNAC and then you can physically place APs on that
floor plan

Floor Plan is also very helpful when you get to DNAC Assurance, you can view where
people are physically located based on the wireless signal in floor plan itself.

You can configure all of the settings at building level or the area level, to
overide that inherited settings.

Creating Basic Site Settings

============================

Now that we have defined our location in DNAC, its going to be important for us to
define where those locations can reach critical network services this is going to
be for each specific sites where is the DNS server, DHCP server, NTP server all of
this is going to be critical site specific function.
Our goal now that we have established network hierarchy we need to tell DNAC for
these buildings they can get their resources from these IP addresses.

Design > Network Settings > Network >

DHCP SERVER: _________________

DNS SERVER
DOMAIN NAME: __________________
PRIMARY:_______________________

Configuring Other Site Settings

===============================

Once we have configured basic services there are additional services that we want
to configure e.g AAA (we will try to configure site specific AAA server).

Design > Network Settings > Network > + Add Servers

_
|_| AAA
_
|_| Netflow Collector
_
|_| NTP

We will choose AAA server and clock.

_ _
AAA SERVER |_| Network |_| Client/Endpoint (Whether AAA server is used by Network
devices or also by Client for authentication).

NETWORK
-------

Server
_ _
|_| ISE |_| AAA

Protocol
_ _
|_| RADIUS |_| TACACS

Network __________ IP Address (PRIMARY) _____________

CLIENT/ENDPOINT
---------------

Server
_ _
|_| ISE |_| AAA

Protocol
_ _
|_| RADIUS |_| TACACS

Network __________ IP Address (PRIMARY) _____________

Now additionally when we begin device discovery and implementation doing LAN
automation, DNAC is going to provision new switches from scratch, as part its going
to provision device credentials and AAA.

****You cannot specify site specific credentials wihout specifying global

credentials first.****

Design > Network Settings > Global > Device Credentials >
CLI> + Add
SNMP v2c > + Add

Whenever DNAC goes to provision our new underlay fabric its going to set VTY line,
AAA, RADIUS, so what we want to have happen is username and password that we have
just created we also want it to be a user that is also accessible in ISE, that way
when device gets provisioned we still access those devices from ssH.

So to create that new user account on ISE

Adminsitration > Identity management > Identity > Users > + ADD

So now we access the devices via CLI (SSH) once they are provisioned via LAN
automation.

Creating a Global Address Block

===============================

In the design workflow we identify the pools of IP addresses that DNAC can use for
end user client activity, virtual networks or LAN underlay and automation section.
Now its time to associate IP address spaces with our individual sites.

First we start with declaring a big pool of IP address from our Global site, and
then in each of the area below you can reserve a subnet.

Careful planning is needed to avoid any accidental IP address overlap.

Design > Network Settings > IP address Pools

If we reserve 192.168.0.0/16 in global it can create IP conflict as our SHARED

SERVICES are in 192.18.1.0/24 and FUSION routers are in 192.168.4.0/24 this will
create routing conflict and address conflict.

Hence to avoid conflict we will reserve 192.168.128.0/17

CIDR Address Range: 192.168.128.0 - 192.168.255.255

So from the Global we will ADD IP POOL

FOR UNDERLAY
************

IP POOL NAME: NOLAUnderlay

TYPE: Generic

IP Address Space:
_ _
|_| IPv4 |_| IPv6

IP Subnet: 192.168.128.0

Prefix Length: /17

Optional
--------
Gateway IP Address:
DHCP Server(s):
DNS Server(s):

FOR OVERLAY
************

IP POOL NAME: VNPool

TYPE: Generic

IP Address Space:
_ _
|_| IPv4 |_| IPv6

IP Subnet: 172.17.0.0

Prefix Length: /16

Optional
--------
Gateway IP Address:
DHCP Server(s):
DNS Server(s):

Reserving Site IP Address Pools

===============================

We will now reserve subnets from out of the blocks we created and will used for LAN
automation and virtual network.
DNAC will connect to one of our Border nodes which will be our seed node and from
there it is going to provisioning all of the devices using plug and play technology
even though these devices are not configured yet.
Its going to be configuring point to point layer 3 routed links between each one of
these interface and it needs to know what ip address space it use to configure ip
addresses on these interface.

Design > Network Settings > IP address Pools

From New Orleans > + RESERVE ( To reserve same IP Pool for Building 1 and Building
2)

Reserve IP Pool
---------------

IP address Pool Name: NolaUnderlay168

Type: LAN (Set type to LAN so that it can be used for LAN automation)

LAN: Assigns IP address to LAN interfaces applicable VNFs and underlay LAN
automation.
Management: Assigns IP address to management interfaces. A management network is a
dedicated network connected to VNFs for VNF management.
Service: Assigns IP address to service interfaces. A service network are used for
communication within VNFs.
WAN: Assigns IP address to NFVIS for UCS-E provisioning.

IP Address Space:
_ _
|_| IPv4 |_| IPv6

IPv4: 192.168.128.0/17

Prefix length/Number of IP addresses:

_ _
|_| Prefix |_| Number of IP

Prefix Length: /24

IPv4 Subnet: 192.168.168.0

Optional
--------
Gateway IP Address:
DHCP Server(s):
DNS Server(s):

===================================================================================
==========================================================
IP address Pool Name: HRVNF
Type: LAN (Set type to LAN so that it can be used for LAN automation)

LAN: Assigns IP address to LAN interfaces applicable VNFs and underlay LAN
automation.
Management: Assigns IP address to management interfaces. A management network is a
dedicated network connected to VNFs for VNF management.
Service: Assigns IP address to service interfaces. A service network are used for
communication within VNFs.
WAN: Assigns IP address to NFVIS for UCS-E provisioning.

IP Address Space:
_ _
|_| IPv4 |_| IPv6

IPv4: 171.17.0.0/16

Prefix length/Number of IP addresses:

_ _
|_| Prefix |_| Number of IP

Prefix Length: /24

IPv4 Subnet: 172.17.20.0

Gateway IP Address: 172.17.20.1

DHCP Server(s): 192.168.10.5
DNS Server(s): 192.168.10.5

Managing Site-Specific Software Inventories

===========================================

We have declare at each site what is the operating system that our network devices
should be running (Golden image). This is not necessarily mandatory its probably
something you should look at.

Design > Image Repository > Global > IMPORT ( You can import images to the
repository)

Now assign the image to category of device that will be able to run it.

Select Golden image for corressponding device model upgrade image to golden image
when otehr version is detected.

*******************************************
Policy Define Business Intent in DNA Center
*******************************************

When we talk about INTENT based networking what we are saying is that our business
has intent how our network should behave.
This could be simple as our IOT devices should never be able to communicate with
servers that has PCI services or health care patient data.
Cisco DNAC true value comes into play when it comes to implementing our business
intent, Policy workflow is where we define our business intent.

The Plan for Policy

===================

Difference between Micro-segmentation and Macro-segmentation

Macro-segmentation Policy:
-------------------------
The devices that exists on certain subnets/groups should never be able to
communicate with other devices on a different subent/group. Eg: Camera, Sensors
Under the hood whats really happening is that DNAC is configuring VRFs on each of
these devices for each of these network and then configuring routing and IGPs in
between these devices but still contained in the VRF.

Micro-segmentation Policy:
-------------------------

When we create virtual networks we create GROUPS that are attached to that Virtual
network in that way we know which user are allowed to be accessing and being on a
virtual network.
By default when we put users or endpoints or devices in any group in a virtual
network they are allowed to communicate to any other group within the same virtual
network.

_______________________
| |
| IT Virtual Network |
| |
| (NOC) (Domain Admin)|
| (Help Desk) |
|_______________________|

Each of the group in DNAC is called SCALABLE GROUPS in ISE it is called SECURITY
GROUP, and with SGACLs (scalable group ACLs) we can specify within the virtual
network which scalable group are allowed to communicate which other scalable group.
we specify a source a destiantion and tell to permit this type of traffic, ISE is
the one who implement this policies, they use scalable group tages within the
header of Data packet themselves and endpoint switches will check with ISE and
enforce
the policy as data moves throughout the SD-access fabric.
We will reserve IP address from Overlay Block for each virtual network.

Creating Virtual Networks

=========================

Depending on which guid you use you can either begin with your micro-segmentation
policy or you can begin with your macro-segmentation policy defining virtual
networks.

The first time you open up your policy workflow we get a warning which says in
order to use SCALABLE GROUPS, DNAC has to import everything from ISE first, so we
need to click START MIGRATION button.

By default you have Default_VN (includes every single scalable group in the Virtual
Network) and INFRA_VN (default reserve for infrastructure, this is the place where
you find edge nodes or your wireless AP)

Policy > Virtual Networks > + ADD

Virtual Network Name: IoT_VN

Avialable Scalable Groups: select the SG to be added in VN.

Policy > Virtual Networks > + ADD

Virtual Network Name: HR_VN

Avialable Scalable Groups: select the SG to be added in VN.

Policy > Virtual Networks > + ADD

Virtual Network Name: IT_VN

Avialable Scalable Groups: select the SG to be added in VN.

Managing Scalable Groups

========================

Scalable Groups are those groups of user that comes from ISE and in this case we
can setup policies within virtual network that controls which scalable groups can
communicate to each other.
Out of the box we get a bunch of scalable groups with DNAC and ISE, we can custom
create our own scalable group with our own custom group of user and even associate
them to AD.

We now create our own scalable group and associate them with Virtual network.

A scalable group can participate in more than one virtual network.

Policy > Group-Based Access Control > Scalable groups > + Create Scalable Group

Create Scalable Group

---------------------

Name: DomainAdmin
Tag value: 18
Description: IT Domain Admin
Virtual Networks: IT_VN
_
|_| Propogate to ACI

To verify on ISE:
----------------

Work Centers > TrustSec > Components > Security Groups

check for DomainAdmin

click on DomainAdmin to check the associated Virtual Network as IT_VN.
Create Scalable Group
---------------------

Name: Helpdesk
Tag value: 19
Description: IT Help Desk staff
Virtual Networks: IT_VN
_
|_| Propogate to ACI

Name: HRStaff
Tag value: 20
Description: HR Staff
Virtual Networks: HR_VN
_
|_| Propogate to ACI

Name: HRManagers
Tag value: 21
Description: HR Managers
Virtual Networks: HR_VN
_
|_| Propogate to ACI

To verify on ISE:
----------------

Work Centers > TrustSec > Components > Security Groups

check for Helpdesk, HRStaff, HRManagers

click on above Security Groups to check the associated Virtual Network.

The Scalable Groups which we created has been synced to ISE and can be implemented
in an overlay SD-access fabric.

Creating SGACLs
===============

Consider for a moment that any Scalable Groups we put into a Virtual Network cna
communicate to any other Scalable Groups that we put into a Virtual Network.
Sometimes we need to control the granularity, some users in Virtual Network can
access some endpoints like servers in a virtual network.

This is where the microsegmentation policy really comes into play, we start
creating SGACL, we can even custom create contracts if we want to do that.

By default the scalable groups in a Virtual network are allowed to communicate with
each other.

So example Domain Admins may need access to PCI Servers, but Helpdesk users will
not need access to PCI Server inside IT_VN.

Policy > Group-Based Access Control > Policies

Change contract from default to Permit for Domain Admins to PCI Servers.
Change contract from default to Permit for PCI Servers to Domain Admins.
Change contract from default to deny for Helpdesk to PCI Servers.

So now we have created a microsegmentation policy for which group should

communicate within a virtual network.
All this changes we built on DNAC will be pushed to ISE and ISE can implement these
policies on our network with scalable group tags.

To verify on ISE
----------------

Workcenter > Trustsec > Trustsec Policy > Matrix > (Check policies)

This further proves we can use DNAC as single plane of glass to create our entire
enterprise network from scratch.

A Note About Virtual Networks

=============================

You associate a IP Pool with virtual network when you go to provision your overlay
fabric in HOST ONBOARDING SECTION.

**************************************************************
20-Policy Create Dynamic Authentication Profiles for SD-Access
**************************************************************

The Plan
========

In this nugget we will shift our focus away from configuration and design of SDA
fabric towards end-user experience that is it really going to be like for them sit
down on the computer
plug into the network and get authenticated into a virtual network for the first
time.

Till now we have deployed a IP address pool, our business intent was to have three
virtual network 1- IOT devices 2- HR Employees 3- IT Staff
what we want is these 3 VN's should be completely segmented away from each other,
these are going to be VRFs.

But we havent associated the IP address pool with these virtual networks yet.

On DNAC
-------

Policy > Virtual Network (we can see we have created IOT_VN, HR_VN & IT_VN and
there are some Scalable groups associated with them to.)

Design > Network Settings > IP Address Pools ( we can see IP Address Pools for
IOT_VN, HR_VN & IT_VN)

We dont bring our IP Pools and Virtual Network together until all the way to end of
PROVISIONING STEP (HOST ONBOARDING SECTION).

But we need to have these upfront inorder to configure AUTHENTICATION POLICY.

Lets say a user connect his PC first time to the network, the switch will serve as
802.1x authenticator, user PC will supplicant and ISE will authentication server.
1. PC will ask the user to type an username and password to be allowed on to the
network, in this case we will create a user account in ISE and also associate user
to a group.
2. Once credentials are provided ISE will allow or deny the traffic. (Contract -
Pemrit/Deny).
3. Associate the user with a VLAN, that VLAN will be identified and specified by
name. [DNAC has a specific way of naming its VLAN - 0_0_0_0-VN (Octets seperated by
_ followed by - and Virtual Network)]. eg: 172_17_30_0-IT_VN
4. We have to specify a Scalable Group for user to be in.

Creating Users and Groups in ISE

================================

To create user through ISE:

--------------------------

Administration > Identity Management > Idenities > +ADD

Network Access User

-------------------

Name: Bob
Status: Enabled

PASSWORD
Password Type:
Login Password:
Enable Password:

USER INFORMATION
First Name:
Last Name:

To create group through ISE:

--------------------------

Administration > Identity Management > Group > +ADD

Identity Group
Name:
Description:

Endpoint Identity Groups are going to be for devices.

User Identity groups are where we can categoerize or group our user accounts
together.

Now we add user bob to the Identity groups

Member Users > +Add

Creating Authentication Policies for SD-Access

==============================================

We have now users and groups, Virtual networks and Scablable Groups, the
authentication policy the policy set itself is what glues them altogether.
Above we have created a user, we have to associate that user to virtual network
that it is trying to join as well as Scalable Group Tags so it can enforce policie
associated with that.

On ISE:
------

Policy > Policy Sets > Click into Policy set on RHS for Default

> Authentication Policy

> Authorization Policy - Local Expections
> Authorization Policy - Global Expections
> Authorization Policy

We trying to work with here is Authorization Policy - This is where we go to

configure our Authorization rule, this is how we are going to associate
DomainAdmins_ISEIG identity group
with Scalable Group and the VLAN we trying to access.

Click on (+)

For Conditions in the Condition Studio we can select the attribute for condition.

Rule Name Conditions Profiles

Security Groups
--------- ---------- --------
---------------

DoaminAdminSDA Identity Group =

User Identity Group DomainAdmins_ISEIG Click + Add
DomainAdmin

Wired_802.1x This profile allows them

access but also
assigns VLAN to them

Name:
DomainAdminPrOF
Description: 172_17_30_0-
IT_VN
Access Type :
ACCESS_ACCEPT
ACCESS_REJECT
COMMON TASKS:
VLAN - 172_17_30_0-
IT_VN

So now the end user whose in DomainAdmin group can now plug in wired into a edge
node authenticate 802.1x be place in correct VLAN and associate it with Scalable
Group Tag.

Creating Scalable Group Endpoint Policies

=========================================

So we have got users and groups nailed down, we have got Domain Admins group and
Policy Set in place. What about the devices?
PCI_servers wont autheticate with username and password they are going to MAC
AUTHENTICATION BYPASS (MAB).

On ISE
------

Policy > Policy Sets > Expand the default policy > Authorization Policy

Rule Name Conditions Profiles

Security Groups
--------- ---------- --------
---------------

PCI_Server SDA Identity Group =

Endpoint Identity Group: PCI_Servers_ISEIG Click + Add
PCI_Server

Wired_MAB This profile allows them

access but also
assigns VLAN to them

Name:
Description:
Access Type :
ACCESS_ACCEPT
ACCESS_REJECT
COMMON TASKS:
VLAN -

Creating AAA Policies for Network Devices

=========================================

So we have got users and groups who can be authenticated by ISE via 802.1x and we
got endpoint devices themselves who can now be authenticated by MAB.
But what about the network devices themselves? - Remember DNAC will provision AAA
server settings on each of the devices it discovers and provisions.
So that way when you to administratively SSH into our devices how then the ISE
knows to authenticate the users that were SSH in the device.
So we have to create an authentication policy to allow AAA and RADIUS services from
network device to ISE and allow the users we created to login.

ON ISE
------

So earlier we have created an user in DNAC called dnac and we have also specified
dnac user in ISE, but ISE hasnt been configured yet to allow user account to access
network devices using a RADIUS authentication profile

Policy > Policy Set > Default Policy > Authorization Policy

Rule Name Conditions Profiles

Security Groups
--------- ---------- --------
---------------

RADIUS-DNAC Network Access Username = dnac Permit Access

 RADIUS NAS-Port-Type = Virtual

Policy Sets Done the Easy Way

=============================

Once you have completely deployed an overlay fabric and you have a SDA fabric that
is working, you then come back to ISE and then choose all of the setting from
dropdown.

There is a great chance you will be changing your network after you deployed a
fabric you want to add virtual network to it, add a scalable group to it, you have
to go back and create these authentication
policy to allow those changes to your existing SDA fabric. Once the SDA fabric
exists its easier to change or add things to it because ISE is dynamically able to
pull down information.

Once we deploy overlay fabric we are going to change things down the road, we going
to add virtual networks, scalable groups and they need to be authenticated.

Policy > Policy Set > Default Policy > Authorization Policy > + ADD

In Profiles we dont have to memorize the VLANS, we create we Authorization Profile,

remember before in COMMON TASKS we had to configure VLAN but if it is already
deployed in the fabric you can choose a Security group.

Security Group: Virtual Network:

Subnet/IP Address Pool Name:

As in security group check box we are already associating a scalable group, virtual
network and a specific VLAN we dont need to configure Secuirty Group in
Authorization Policy rule as Scalable group will be set in Profile itself.

********************************************************
21-Provision Perform Device Discovery and LAN Automation
********************************************************
Provision workflow is where our network comes alive we will start with discover
process finding out what the devices are we can manage and then figuring out if
they need to be upgaraded to latest version IOS XE first before we can even
implement a SD access fabric
then we are going to dive into LAN automation and let DNAC provision our entire LAN
underlay from scratch.