Cisco CCNA Study – Day 13 | Stuff that a middle age man is still learning

The final day of videos!!, time to get this done and start with the review of data for the test.

Section 38 continued…

APIs (Application Programming Interfaces) – CRUD, REST and SOAP
- NETCONF and RESTCONF are APIs specifically desigened to work with network devices.
- CRUD – Create – Read – Update – Delete
- SOAP – Simple Object Access Protocol
  - Statndared communicatoin protocol system taht permits processes using different OS like Linux and Windows to talk.
  - typically uses HTTP(S) and data is always formatted as XML
  - It has strict standard to adhere to
- REST – Representational State Transfer
  - Is an architecture, not a protocol
    - Gives guidelines for structure and organization of an API
  - Support any transport and data format
  - Commonly uses http(s) as transport and commonly uses JSON (or XML) data formats
  - Typically has faster performation and is easier to use than SOAP
  - Contraints
    - Client- Server architecture
      - Send & response model
    - Uniform interface
    - Statelessness
      - no client context is stored on the sever between requests
    - Cacheability
      - responses need to be define cacheable or non-cacheable
    - Layered system
      - devices between client and server must be transparent
    - Optional – Code on demand
      - Server can temporarily extend or customze the functionality of a client by transferriing executable code.
  - REST Response Codes
    - Success
      - 1xx: Informational
      - 2xx: Success
        
        200: OK
        
        201: Created
        
        204: No Content/Deleted
      - 3xx: Redirection
    - Errors
      - 4xx
        
        400: Bad request/malforned syntax
        
        401: Unauthorized
        
        403: Forbidden
        
        404: Not Found
      - 5xx: Server Error
        
        400: Internal Server Error
      - Responses to Get requests include data in the body
      - Headers can also be included in the response
Configuration managemetn Tools
- System to make managing large number of devices easy
- Automate many different systems from one location
- Popular free options (Enterprise paid options)
  - Ansible
    - Any machine with python 2 or 3
    - Agentless
    - Push Model
    - Uses SSH by default
    - Simpler than othe tools
    - Modules are pre-built python scripts
    - Inventory files define all hosts to be managed
    - Playbooks are YAML files that outline the instructions it needs to run
  - Puppet
    - Uses agent on the target
    - Runs on Linux
    - Pull model so agent checks in every 30 minutes by default
    - Programmed in Tuby
    - Proprietary DSL rather than YAML
    - ‘Manifest’ defines the device’s properties
    - Can check config consistency
  - Chef
    - Uses agent on the target
    - Pull model
    - Programmed in Ruby
    - Terminology is Cook Book > Recipe
- Automate provisioning an deployment of servers and network devices
- Require little program knowldege
- Development practices
  - version control
  - testing
SDN – Software Defined Networking
- Router and Switch Planes
  - Data (Forwarding) Plane: Traffic which is forwarded through the device
  - Control Plane: Makes decisions about how to forward traffic.
    - Packets such as routing protocol or spanning tree updates are destined to or locally originated on the device itself.
  - Management Plane
    - The device is configured and moniorted in this plane.
- SDN – Data and Control Plane Separation
  - Traditionally network infrastructure devices are responsible for thier own control and data planes
  - SDN decouple the data and control plans
  - Network Devices are still responsible for forwarding traffic, but control plane moves to a centralised SDN controller.
- Data and control plane separation
  - Rules for packet handling are sent to the network devices from the controller
  - The network devices query the controller for guidance as needed and provide the controller with info about traffic being handled.
- Pure SDN vs Hybrid SDN
  - Pure SDN
    - The control plane runs purely on the SDN controller
    - Data plane runs purely on the network device
  - Hybrid SDN
    - Majority of the Control plane intelligence is provided by an SND controller
    - Network Devices retain some control plane intelligence as well as the data plane operations
    - Most implementations use a hybrid SDN
- SDN Architecture
- Cisco SDN Controllers
  - APIC – Application Policy Infrastructure Controller
    - Main component of the Cisco ACI (Application Centric Infrastructure) solution
    - made to manage data center environments with Nexus Switches
  - DNA Center – Digital Network Architecture
    - mad to manage enterprise environment
      - Campus
      - Branch
      - WAN
    - Upgrade to APIC-EM (Application Policy Infrastructure Controller – Enterprise Module
DNA Center
- One part of three building blocks of Cisco DNA and Software Defined Architecture
- “Cisco DNA enables you to streamline operation and facilitate IT and business innovation.”
- Intent-based networking (IBN) built on Cisco DNA takes a software-delivered approach to automate and assuring services across your WAN, Campus, and Branch networks
- A Cisco SDN controller which is designed to manage enterprise environments (campus, branch and WAN)
  - Opposed to APIC which manages data center environments with Nexus Switches
- DNA Center Appliance
  - Runs on Cisco UCS server hardware
  - Built Linux OS
  - Can cluster for redundancy
- IBN – Intent Based Networking
  - Controller led network that translates the business needs into policies that can be automated and applied consistently
  - Goal is to continuously monitor and adjust network performance to help assure desired business
  - Example 1
    - a QoS policy roll-out
      - The Intent: The network policy is first defined, guaranteed service to voice and video across network locations
      - Traditional method
        
        Network team researches and plans the implementation, then configures each network device individually
        
        Different network device models require different commands
        
        Very time consuming and prone to mistakes
      - IBN
        
        Network team creates a application policy in DNA Center specifying voice and video as business relevant apps.
        
        DNA Center auto configures the best practice QoS setting on devices
        
        Reduce time from potentially months to minutes
  - Example 2
    - SSecurity traffic flows in the campus
      - The intent: Users in DeptA and DeptB must have connectivity to other users in the own department and the company servers
      - the must not have connection to the users in the other department.
      - Traditional
        
        Plan VLAN, IP subnet and ACL implementation, the configure each switch individually
        
        Users will stay in the same access port, and they are assigned a VLAN and IP address based on their physical location
        
        Time consuming, liable to mistakes and does not support mobility
      - IBN
        
        Create a group-based access control policy in DNA which specifies the allowed traffic flows
        
        User log in from and can move to any physical location on campus
        
        User are Authenticated by Cisco ISE Identity Services Engine and assigned a Security Group Tag controlling their access
- Network Plug and Play
  - Allows routers, switches and WAP to be deployed in remote offices with zero touch config
  - Device is physically installed at location and connected to the network.
  - It discovers DNA Center through various methods
    - DHCP option 43
    - DNS ‘pnpserver.domain-name.com’
  - Device registers with and downloads its configuration from DNA Center
  - This ensure correct config in remote devices and can keep a engineer to be onsite.
- Assurance
  - Guarantees that the infrastructure is doing what was intended
  - Receives info from all devices and ISE
  - Correlation engine can identify 150+ different types of network and client issues
    - Report problems and provides recommended remediation actions
  - Admins can drill down into the health status of devices and clients
  - See current and historical status info
  - Userful for troubleshooting intermittent problems and/or issues which occurred in the past.
- Path Trace
  - Use to query DNA center for the path that traffic takes over the network
  - This aids troubleshooting
- API Support
  - Can provide Northbout REST API
  - Supports East and West bound APIs for integration for items like reporting and analytics
Software Defined Architecture – SD Access
- Traditional Access Control
  - Control access to and traffic flows within a network is fixed VLANs, IP addresses and ACLs
  - User expect to connect to the same physical port and assigned VLAN and IP subnet
  - ACL controls traffic flows
  - More complex with each device
  - Does not support mobility for the user
- SD-Access – Software Devined Access
  - Newer method of network access control wich solves the limitation of the traditional implementation
  - Traffic flow security is base on user identity, not physical location and IP address
  - User log in from and can move to any physical location in the network.
  - Tow components required
    - ISE (Identity Service Engine) for user authentication
    - Security Policy configured on DNA Center
      - Permit and deny communication between groups
  - Underlay and overlay Network
    - Underlay network is the underlying physical network. Provides the underlying physical connection which the overlay network is built on top of.
    - Overlay network is a logical eopolgy used to virtually connect devices. It is built over the physical underlay network.
    - The combination of underlay and overlay forms the SD0Access ‘network fabric’
  - Underlay Network
    - Any existing (‘brownfield’) underlying physical network can be deployed.
      - Links between devices can be layer 2 or layer 3 and any routing protocol can be used
      - DNA center can be used to auto provision the underlay network in new (‘greenfield’) sites. Layer 3 links are used between devices and IS-IS is used as the routing protocol
  - Overlay Network
    - LISP is used for Control Plane
    - VXLAN is used for the Data Plane
    - Cisco TrustSec CTS is used for the policy
      - Each technology has been optimized for SD-Access
  - Policy Plane – Cisco TrustSec CTS
    - Users are authed by ISE
    - Polciy configured on DNA Center
    - Users are allocated an SGT – Scalable Group Tag
    - Cisco TurstSec secures traffic flows based on the security policy and SGTs
    - Standard Trust Sec needs end-to-end TrustSec devices, SD-Access uses overlay tunnels so can work with other devices.
SD-WAN
- Traditional WAN Deployment
  - Individual device conf
  - conf is not standard
  - Focus on link connectivity notthe required performance for apps
  - Typically difficult to migrate to another WAN service
- It provides automated setup of WAN connectivity between sites
- Monitoring and ailover is automated
- Traffic flow control is application aware
- SD-WAN Benefits
  - Auto, standardized setup of connectivity between sites
  - Transport independent
  - Simplified, integrated operations
  - More flexibility and easier to migrate WAN services
  - The required, predictable performance for important applications
  - Integration with the latest cloud and network tech
  - Lower Cost
- Data Plane – vEdge Routers
  - vEdge router run the data plane
  - They are physical or virtual routers
  - They form an IPsec encrypted data plane between each other
  - A site can have 2 vEdge routers for redundancy
- Control Plane – vSmart Controllers
  - vSmart controllers run the control plane
  - The are the centralized brain of the solution
  - They run as virtual machines
  - They distribute policy and forwarding info to the vEdge routers inside TLS tunnels
  - Each vEdge router connects to two vSmart controllers for redundancy
- Management Plane – vManage NMS
  - The vMange NMS provides the management plane GUI
  - It enables centralized configuration and simplifies changes
  - It provides real time alerting
  - It runs as a virtual machine
  - Multiple vMange NMS are clusters for redundancy
- Orchastration – vBond orchestrator
  - The Bond orchestrator authenticates all vSmart controllers, vManage NMS and VEdge routers that join the SD-Wan network
  - It enable vEdge routers to discover each other, vMange and Vsmart
  - It ahs a public IP address and is deployed in DMZ
  - It runs a virtual machine (can run on a router in smaller deployments)
  - Multiple vBond orchestrators can be deployed with round robin DNS
- ZTP Zero Touch Provisioning service
  - Cloud based shared service hosted by Cisco
  - Utilized on first boot of vEdge router only
  - Directs it to vBond to orchestrate joining it to the network.
  - On Premises and Cloud
    - vBond, vSmart and vMange can be deployed
      - On premises
      - Hosted in Cisco (or partner) cloud
    - Most deployments are in the cloud
  - Building the Data Plane
    - VSmart Controller directs the vEdge router to build a full mesh (default) of IPsec VPN tunnels between themsleves
    - VSmart propagest policy and routing info to the vEdge routers with Overylay management Protocol (OMP)
  - BF (Bidirection Forwading) VPN Tunnel Monitoring
    - BF Detection packets are sent over all VPN tunnels
    - this detects if a tunnel goes down, and also provides latency, jitter and loss statistics
  - Traffic Forwading Option
    - If multiple tunnels are available (MPLS and Internet) traffic can be load balanced over the tunnels
      - Active/Active
      - Weighted Active/Active
      - Applicaation pinning Active/Standby
      - Application Aware Routing
  - App Aware Routing
    - BFD monitors the latency, jitter and loss across the VPNtunnels
    - You can set minimum req. for an for an app with SLA classes
    - SD-WAN ensures the app is sent over a link which meets its SLA
    - By default traffic will fall back to another link if no suitable link is available.
Further Learning Resources
- Network programmability Basics video course: https://developer.cisco.com/video/net-prog-basics/
- DevNet Sandbox: https://devnetsandbox.cisco.com
- DevNet Learning Labs: https:developer.cisco.com/learning/
- Further Cert: Cisco Certified DevNet Associate

That was a rough section and there was a lot new stuff that I had to learn… Now time for practice test and lots of review.