Author: kbmarco

4.6 Configure and verify NETCONF and RESTCONF

Router(config)# netconf-yang
Router# show netconf-yang sessions 
Router# show platform software yang-management process
Router(config)# restconf

5.3 Describe REST API security

HTTPS / TLS

REST APIs should use HTTPS, not plain HTTP.
TLS provides encryption, integrity, and server authentication.

Authentication

• Verifies who the client is.
• Common methods:
• username/password
• API key
• token
• OAuth 2.0 / bearer token
• Cisco APIs often return a token after authentication, which is then included in later requests.

Authorization

Determines what an authenticated user/application is allowed to do.
Think RBAC / least privilege.
Authentication ≠ authorization.

Tokens

Usually sent in an HTTP header, commonly:
Authorization: Bearer <token>
Tokens may expire and need renewal.
Better than repeatedly sending credentials with every request.

Certificates

HTTPS relies on digital certificates.
The client should validate the server certificate to avoid connecting to an impersonated server.
Self-signed certificates may appear in labs but are less trustworthy unless explicitly trusted.
Sensitive data
Do not expose passwords, tokens, API keys, or credentials in:
URLs logs source code public repositories Least privilege

API accounts should receive only the permissions required for their task.

6.1 Interpret basic Python components and scripts

Idk just read it

6.3 Describe the high-level principles and benefits of a data modeling language, such as YANG

Yet Another Next Generation (YANG)= Data models are used

to describe whatever can be configured on a device, everything that can be monitored on a device, and all the administrative actions that can be executed on a device, such as resetting counters or rebooting the device. This includes all the notifications that the device is capable of generating. All these variables can be represented within a YANG model.

list = the name of something with multiple instances/items

key = uniquely name of the item in the list

leaf = single data field

type = allowed data type

enumeration = value must come from predefined choices

config false = read-only/state data, not configurable

Network Configuration Protocol (NETCONF)

NETCONF is an automation protocol that uses YANG data models to describe device configurations

• Runs over SSH, TLS, and not commonly Simple Object Access Protocol (SOAP)
• Uses paths in the data tree to describe resources, instead of OIDs like SNMP
• Either the complete configuration transaction succeeds, or it doesn’t get committed
  • NETCONF should reject the configuration rather than leaving you with half of the requested configuration.

NETCONF Operation Description

• <get> Requests running configuration and state information of the device
• <get-config> Requests some or all of the configuration from a datastore
• <edit-config> Edits a configuration datastore by using CRUD operations
• <copy-config> Copies the configuration to another datastore
• <delete-config> Deletes the configuration

Representational State Transfer (REST) CONF RESTCONF

The main difference is how they talk to the device.

Both can manipulate YANG-modeled data, but they use different mechanisms:

NETCONF = sophisticated network-config protocol using SSH/XML.

RESTCONF = simpler web/API-style access to YANG data using HTTPS and JSON/XML.

netconf = RPC, restconf = http

6.7 Compare agent vs agentless orchestration tools

• Puppet
  • Puppet server communicates with devices with agents, puppet clients
  • Changes and automation tasks are executed in a puppet console
  • Then shared with server and puppet agents
  • Each Puppet Agent communicates with the Puppet Server on a unique TCP port
  • Code is called Manifests
  • Server pushes manifests to clients using SSL and require certificates for secure communication between server and clients
• Chef
  • Open source config-management tool
  • End devices are called clients, not agents
  • Written in ruby and ErlangChanges can be pushed to devices
  • Those devices can check in with server and pull to see if there is any change in configuration
  • Cookbooks and recipes
  • Cookbook is a collection of code or files
  • Recipe is code for configuration change
  • Cookbook is the whole package, recipe is one set of config changes inside that cookbook
• Salt/SaltStack
  • Built on Python
  • Masters and minions
  • Beacons are agents that live on minions,
  • Pillars/grains
    • Grains = facts about the minion
    • Pillars = data provided by the Salt master that the minion should use
      • Can be different for each minion

5.2 Configure and verify infrastructure security features

                              5.2.a     ACLs

ACLs are processed top-down

ACL effectively ends with:

deny ip any any

even though you don’t see it.

Can use wildcard masks

eq = equal
neq = not equal
lt = less than
gt = greater than
range = range of ports

                              5.2.b    CoPP

ACL - identifies specific traffic
 ↓
class-map - matches that traffic into a QoS class
 ↓
policy-map - define what to do with matching traffic
 ↓
control-plane - enter control-plane config
 ↓
service-policy input -  apply this QoS policy to traffic entering the router’s control plane/CPU

ip access-list extended SSH-TRAFFIC
 permit tcp any any eq 22
class-map match-all SSH-CLASS
 match access-group name SSH-TRAFFIC
policy-map COPP-POLICY
 class SSH-CLASS
  police 64000 conform-action transmit exceed-action drop
control-plane
 service-policy input COPP-POLICY

Verification of CoPP commands

R1# show policy-map control-plane input

APIs

Northbound vs Southbound

Controller is in the middle

Northbound – lives on the controller, information is conveyed to the network management applications “north-bound”

Southbound- also lives on the controller, when management configuration is pushed from the Controller to the devices, that is Southbound traffic

RESTful APIs

An API that uses REST is often referred to a RESTful API. RESTful APIs use HTTP methods to gather and manipulate data.

6.3 Describe the high-level principles and benefits of a data modeling language, such as YANG

Yet Another Next Generation (YANG)= Data models are used

to describe whatever can be configured on a device, everything that can be monitored on a device, and all the administrative actions that can be executed on a device, such as resetting counters or rebooting the device. This includes all the notifications that the device is capable of generating. All these variables can be represented within a YANG model.

• list = the name of something with multiple instances/items
  • key = uniquely name of the item in the list
• leaf = single data field of the item in list
  • type = allowed data type
  • enumeration = value must come from predefined choices
  • config false = read-only/state data, not configurable

6.5 Interpret REST API response codes and results in payload using Cisco Catalyst Center and RESTCONF

HTTP Status Codes

2xx = okay

4xx = client messed up

5xx = server messed up

	1.4 Interpret QoS configurations 

Best-effort = no attempt made, once queue is full packets are dropped

IntegratedServices (intserv) = qos built into apps that signal to the endhost and network devices how much bandwidth is needed to function, uses RSVP (resource reservation protocol). This RSVP’d bandwidth cannot be shared, if not used is wasted. All devices in the path must support IntServ. Does not scale well on large networks because of how many reservations would be made and wasted

Differentiated Services (DiffServ) = QoS is managed on a hop-to-hop basis
IP traffic is divided into classes, and classes have different levels of service
Each packet, when received, has its class read and then treated accordingly (like VIP, manager, regular employee, random nobody)

Modular QoS (MQoS) = cisco’s approach to implementing QoS on cisco devices

Class maps = define the traffic classifications, command class-map

Policy maps = provide the actions per class (e.g. for VIPs, prioritize highest), command policy-map
Policy maps at its most fundamentals include: 1. A class, with command class [name] and 2. The QoS action

Service policies = applied to interfaces to determine if its applied on inbound or outbound traffic), command service-policy
Can apply the same policy map to multiple interfaces

1. Identify traffic by creating the class map
2. Create policy action with class map
3. Apply policy map with service policy

"I have a good theoretical/practical understanding of wired QoS, including LLQ, CBWFQ, class-maps/policy-maps, and policing versus shaping."
As someone who took the exam and passed a few days ago, this is all you need to know. Without breaking the NDA, the questions I encountered on QoS were a couple and so very basic, they were out of place in a professional level certification exam. – a reddit post

Policy maps have no effect until applied with command service-policy [input | output] [policy-map-name]

All traffic that doesn’t match a class map is unclassified traffic, and the default for unclassified traffic is best-effort. However, unclassified traffic can have QoS actions applied by default

Classification is predominantly
• Layer 2: Mac addresses and 802.1p/q bits
• Layer 3: DSCP bits in packets, source/destination IP addresses
• Layer 4: TCP or UDP ports
• Layer 7: NGFW inspection/ Network Based Application Recognition (NBAR) identify traffic based on source application

Marking is coloring/dyeing a packet so that it can be distinguished even after other operations
• Internal: QoS groups
• Layer 2: 802.1Q/p class of service bits in the frame
• Layer 3: DSCP bits

802.1Q frame fields: PCP, DEI, VLAN ID

Per-Hop Behavior (PHB): Class selector (CS) so DSCP can be backwards compatible with IP Precedence, Default Forwarding (DF): best-effort (aka normal), Assured Forwarding (AF): guaranteed bandwidth, Expedited Forwarding (EF): Used for low delay
AF > EF > DF

Trust boundary: For best results packets should be colored/dyed AT THE SOURCE or AS CLOSE TO THE SOURCE as possible

Class-based marking configuration: use the set command for a traffic class in a policy-map

Policing: STOP! YOU ARE UNDER ARREST FOR EXCEEDING BANDWIDTH! I AM DROPPING YOU!

Best placed on edge devices to prevent traffic from wasting precious bandwidth on the core

Shaping: Gordon Ramsey: Oh dear how precious, I will buffer and delay your traffic to get your message across

Best placed on the egress of the network – it passed QoS checks anyways, we don’t want to drop it, we want to send it eventually

Markdown – when the traffic police notice bandwidth is exceeded they can do two things:

1. Drop the traffic entirely (arrest)
2. Lower the priority (slow down)

Queuing Algorithms:

1. FIFO = first in first out no differentiation
2. Round robin = Each queue takes a turn sending one packet, no prioritization of traffic
3. Weighted round robin (WRR) = Assign a weight to each queue, they get a proportion of the bandwidth according to the weight (e.g. voice 50%, video 30%, other 20%)
4. Custom queuing (CQ) = Combination of Round robin and FIFO. 16  queues and each queue has FIFO
5. Priority queuing (PQ) = four queues (high, medium, normal, low). Highest queues are ALWAYS served first, and the next queue isn’t served until the higher one is done. FIFO within each queue. Low priority queue can be starved if High is never emptied
6. Weighted fair queuing (WFQ) = The link bandwidth is actually just divided and each queue gets their respective weight % of bandwidth (e.g. audio gets 70% of the link, data gets 30%)

2.3.a LISP =WHERE

EID = endpoint ID RLOC = Routing Locator EID + RLOC = who + location on network ITR, ETR, xTR, ingress egress, router doing both Map server = holds the database of mappings Map resolver = answers to queries about where (RLOC) is something (EID) located

2.3.b VXLAN = GET IT THERE

                                   VNI = VXLan Network Identifier, 24 bits, identifies each individual VXLAN, about 16 million of them

                                   VTEP = VXLAN Tunnel EndPoint, the actual device (physical or virtualized) that encapsulates or de-encapsulates the layer 2 data into VXLAN layer 3 packets

                                                            Can be software (virtualized, as a v-Switch in hypervisor) or hardware (switch, router, firewall) that supports VXLAN

[images removed due to not having permission from original owner to reproduce image]

VNI on the layer 2 side, VTEP IP interface on the overlay side

1. H1 transmits a frame for H2
2. Frame arrives on the VNI of SW1
3. There exists a tunnel between H1 and H2 (VNI 5012) so SW1 prepare the frame for the VXLAN tunnel
   1. Find the mapping of H2’s MAC Address to the what VTEP it’s connected to
   1. Add the VXLAN header, which contains the VNI
   1. Add the UDP header (source and destination ports of 4789 and rarely 8472)
   1. Add the overlay SRC and DST IP addresses
4. Send the packet across the underlay
5. SW2 receives and de-encapsulates the data

How do VTEPs know the MAC address of the foreign host?

1. Essentially each VNI is mapped to a multicast IP address
2. Before encapsulation, the VTEP sends an ARP request to the Destination VTEP(specifically, its multicast address)
3. It’s transferred over network thru underlay which has routes
4. Destination VTEP receives ARP request, notes H1’s MAC address and IP mapping for later, and sends the ARP Request to H2
5. H2 replies with ARP Response, and uses the IP-MAC (VTEP, VNI) mapping from the first trip to respond