Cisco DevNet Associate Exam 200-901 cheats

Most other REST APIs use Content-Type and Accept headers to indicate the data format to be used. Not ACI REST API.

Different from other authentication methods APIC does use tokens for authenticating API calls, but the controller responds with a cookie, and that becomes your token.

To get a token from APIC, you send a POST request with username and password. The token is then returned as a cookie. POSTMAN automatically adds the credentials as POSTMAN environment variables. See the eyeball for the updated token. The POST request has a body, as shown below.

• POST https://{{apic}}/api/aaaLogin.json
• POST https://{{apic}}/api/aaaLogin.json # to get a cookie
• POST https://{{apic}}/api/aaaLogin.json
• POST https://{{apic}}/api/aaaLogin.json

With this body:

{
    "aaaUser": {
        "attributes": {
	   "name": {{username}},
	   "pwd": {{password}}
        }
     }
}

After getting a 200 OK, you will get a token in the body of the response.

Because ACI uses cookies for the token, you do NOT have to include this ACI API Token as a header, in any subsequent requests. Unlike DNAC where you have to send the token as a header in every request to DNAC.

API will target a specific class type or mo. If you are working with a specific

Architectural Patterns There are several relevant patters, and many others too. Architectures are an abstraction of the application overall organization. They are where you also define API that will be used to communicate between components and outside systems.

The waterfall model is a breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of the previous one and corresponds to a specialisation of tasks. The approach is typical for certain areas of engineering design. In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction ("downwards" like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance.

One of the differences between agile software development methods and waterfall is the approach to quality and testing. In the waterfall model, work moves through Software Development Lifecycle (SDLC) phases —with one phase being completed before another can start—hence the testing phase is separate and follows only after the build phase. Also with waterfall, the detailed requirements analysis up-front is supposed to lay out the details of all the requirements that will be needed up front, so head-count and timelines can be allocated. It rarely works out like this though, and since there is no flexibilty to return to a completed phase it is very inflexible.

(In agile software development, however, testing is completed in the same iteration as programming.)

• The rapid and continuous delivery of software releases helps customers to better understand what the final piece will look like. This capability also provides a fully working code improved week after week, leading to customer satisfaction.
• Thanks to Scrum, people interaction is emphasized.
• Late project changes are more welcome.

• This kind of approach lacks emphasis on good documentation, because the main goal is to release new code quickly and frequently.
• Without a complete requirement-gathering phase at the beginning of the process, customer expectations may be unclear, and there is a good chance for scope creep.
• Rapid development increases the chance for major design changes in the upcoming sprints, because not all the details are known.

Start wtih capturing design requirements as tests, then writing software to pass those tests. This is called Test-Driven Development (TDD).

First off the Gang of Four published a book on s/w design patterns that revolutionized s/w development. They classified three main categories of design patterns:

1. Creational - Patterns used to guide, simplify, and abstract software object creation at scale.
2. Structural - Patterns describing reliable ways of using objects and classes for different kinds of software projects.
3. Behavioral - Patterns detailing how objects can communicate and work together to meet familiar challenges in software engineering.

Model maps to Model : i.e. the data Template maps to View : i.e. the layout View maps to Controller : i.e. the business logic

Common desing pattersn in MVC

• Observer # see section here
• Strategy
• Composite
• Factory
• Adapter

Remember to try to stick to loose coupling between the model, view and controller so that they can be developed/updated/changed independently. Even to the point that views and controllers can be interchanged during runtime!!

• ASP.NET MVC
• Django, Pyramid, web2py
• Symfony, Laravel, Zend Framework
• AngularJS, Ember.js, Wakanda
• Spring

and modules

See my org file on XML <key> value </key> and JSON "Key":Value and YAML Key:Value as well as key-value-notation.html

• minidom for XML

  from xml.dom.minidom import parse, parseString
  datasource = open('c:\\temp\\mydata.xml')
  dom2 = parse(datasource)
  

• xml.etree.ElementTree

  import xml.etree.ElementTree as ET
  tree = ET.parse('acme-employees.xml')
  tree2 = ET.fromstring(acme-employees-long-string-of-xml)      # if a string
  

  ET has two classes, ElementTree class represents the whole xml document as a tree. While Element represents a single node in this tree. So interactions to the whole document use ElementTree while single elements and its sub-elements use Element.

  Could also use xmltodict

  • json:

  Read (json.load) and write (json.dump)

  with open('/Users/zintis/eg/code-examples/mydevices.json', 'r') as readdevices:
     ingest_dict = json.load(readdevices)
  
  with open('/Users/zintis/eg/code-examples/sample.json', 'w') as dumpback2json:
      json.dump(ingest_dict, dumpback2json)
  
  

• json.load(filehandle) to read
• json.dump(jsonobject, filehandle) to write

A real-life example of an ip table read in from a router. The file is [file:///Users/zintis/eg/code-examples/show-ip-route-response.json]

After the json is parsed into a python dictionary, say X, then 172.16.17.18 could be retrieved as:

• IPaddr = X["ietf-interfaces"]
• YAML writing:

  with open(r'E:\data\store_file.yaml', 'w') as file:
    documents = yaml.dump(dict_file, file)
  

  You can also dump in a sorted keys order:

  with open(r'E:\data\store_file.yaml') as file:
    documents = yaml.load(file, Loader=yaml.FullLoader)
  
  sort_file = yaml.dump(doc, sort_keys=True)
  print(sort_file)
  

1. collaboration
2. backups / versions
3. documented changes

git sees a project directory as a root of a tree, with sub-directories as trees, and files as blobs.

1.8.a Clone git clone <url> Takes the whole repository and copies it into a new directory. The repository could be a remote one or a local one. If local it will just create hard-links to the files in the repository, rather than duplicate space. (if you are taking a backup, you can add option -no hard-links and the copies will be true copies.

1.8.b Add/remove git add <new or modified files> to the respository (from the staging area)

1.8.c Commit git commit -m "Commit message" takes staging area files and creates a point in time state of all the files in the staging area (that your are adding)

1.8.d Push / pull The git pull command is used to fetch i.e. download, content from a remote repository and immediately update the local repository to match that content. The git pull command is actually a combination of two other commands, git fetch followed by git merge. In the first stage of operation git pull will execute a git fetch scoped to the local branch that HEAD is pointed at. Once the content is downloaded, git pull will enter a merge workflow. A new merge commit will be-created and HEAD updated to point at the new commit.

git push # will send the locally modified files to the git repository git pull # will receive a copy of the latest version from the git repository

1.8.e Branch git branch will display all the available branches as well as the branch currently active. git branch -vv will be extra verbose about it.

git branch covid-19 creates a new branch called covid-19, which points to the same place where HEAD is pointing. At this point HEAD will point to master as well as covid-19. (HEAD -> master, covid-19)

git checkout covid-19 will replace the current directory contents with the contents of what covid-19 is pointing to, (which at this point is the same, so no change really) but git log --all --graph --decorate shows us that we are now (HEAD -> covid-19, master) ie. that HEAD is pointing to covid-19 which is also the same place where master is.

Now if you start editing and adding files, the changes will be committed into the covid-19 branch, where HEAD is pointing. Master will still be pointing to the master snapshot.

any changes are committed to covid-19. i.e. (HEAD -> covid-19) and (master) is beside the snapshot it was on before. i.e. master stays the same

If we issue git checkout master, the current directory is overwritten with what was in the master commit, and HEAD -> master, Covid-19 is unchanged.

So you can flip back and forth between two developments streams.

• git checkout master
• git checkout covid-19

1.8.f Merge and handling conflicts git merge is the opposite of git branch. After you have 1 or more branches and you want to re-combine them into the master train, you use the git merge.

1. git checkout master # to git you back on the master train.
2. git log –all –graph –decorate –oneline # just to take bearings
3. git merge covid-plots If there are no merge conflicts, you are done. However if conflicts arise between master and covid-plots, a human has to decide what changes take precedence and what changes will be discarded.
4. git merge --abort if you get messed up.
5. git mergetool # start comparing what changes over-write each other.
6. if you configure git properly, you can tell it to use vimdiff every time you run git mergetool. OR, you can manually run vimdiff
7. vimdiff
8. git merge --continue to proceed where you left off to make the human conflict resolution change.

1.8.g diff git diff filename is the same as saying git diff HEAD filename i.e. it compares the current file to the file as it was in the last commit.

Similarly git diff 42bcdea8 main.py will compare the current main.py file to the state it was in the commit identifited by commit-id 42bcdea8

zp: checkout gitcheckout -b <new branch name> git checkout covid-19 will replace the current directory contents with the contents of what covid-19 is pointing to, (which at this point is the same, so no change really) but git log --all --graph --decorate shows us that we are now (HEAD -> covid-19, master) ie. that HEAD is pointing to covid-19 which is also the same place where master is.

From wikipedia: Webhooks are "user-defined HTTP callbacks". They are usually triggered by some event, such as pushing code to a repository or a comment being posted to a blog. When that event occurs, the source site makes an HTTP request to the URL configured for the webhook.

Webhooks are the solution to otherwise continually polling a webserver with a request, then parsing the response to see if there was any change. Like a kid asking "are we there yet? are we there yet? are we there yet?".

Webhooks is like the kid asking the parent, "can you tell me when we are there?"

Webhooks use the server to asynchronously notify the client about changes. So, greatly reduced number of web requests are sent, and the client is notified of a change, or an event very close to real-time.

Polling is pull and Webhooks is a push.

There are two ways your apps can communicate with each other to share information: polling and webhooks.

• Polling is like knocking on your friend’s door and asking if they have any sugar (aka information), but you have to go and ask for it every time you want it.
• Webhooks are like someone tossing a bag of sugar at your house every time they have some. You never have to ask for it. They are automated messages sent from apps when something happens.
• They have a message, or payload, and are sent to a unique URL, essentially the app's phone number or address.
• Webhooks are almost always faster than polling, and require less work on your end. you can say webhooks are efficient and low latency, because when the event happens, you don't have to wait the polling interval to ask "did this happen?" repeatedly. The event happens, and BAM, the notice is sent.

https://yourapp.com/data/dude42?Customer=cleese&value=105&item=pens

To: yourapp.com/data/dude42
Message: Customer:   Cleese
            Value:   105
	     Item:   Pens

1. A client needs to subscribe to a specific webhook, by creating a POST request to the webhook endpoint. The POST usually contains
   • authentication data
   • which events the client is subscribing to
   • which address and port should be notified (i.e. telling the server where to send the notice of change
2. the server

Take another look at our example message about a new order. Cleese opened your store's website, added $105 of pens to his shopping cart, and checked out. Boom, something happened, and the app needs to tell you. Time for the webhook.

Wait: who's the app gonna call? Just like you need to tell the bank your phone number before they can text you, for webhooks, you need to tell the originating app—your eCommerce store, in this case—the webhook URL of the receiving app, the app where you want the data to be sent.

Say you want to make an invoice for this new order. The app that creates this invoice is on the receiving end—it’s the app that needs the order data.

You'd first open your invoice app, make an invoice template, and copy its webhook URL—something like yourapp.com/data/12345. Then open your eCommerce store app, and add that URL to its webhook settings. That URL is your invoice app's phone number, essentially. If another app pings that URL (or if you enter the URL in your browser's address bar), the app will notice that someone is trying to send it data.

Ok. Back to the order. Your eCommerce store got the order and knows it needs to send the details to yourapp.com/data/12345. It then writes the order in a serialization format. The simplest of those formats is called “form-encoded”, and means your customer's order would look something like this:

Customer=bob&value=10.00&item=paper

Now your eCommerce store needs to send the message. The simplest way to send data to a webhooks URL is with an HTTP GET request. Literally, that means to add the data to the URL and ping the URL (or enter it in your browser's address bar). The same way you can open Zapier's about page by typing /about after zapier.com, your apps can send messages to each other by tagging extra text with a question mark on the end of a website address. Here's the full GET request for our order:

https://yourapp.com/data/12345?Customer=cleese&value=105&item=pens

Deep inside your invoice app, something dings and says "You've got mail!" and the app gets to work, making a new invoice for Cleese's $105 pen order. That's webhooks in action.

Remember when you had to check your email to see if you had new messages—and how freeing push email (“You’ve got mail!”) was? That's what webhooks are for your apps. They don't have to check for new info anymore. Instead, when something happens, they can push the data to each other and not waste their time checking and waiting.

Then there's REST Hooks: REST Hooks itself is not a specification, it is a collection of patterns that treat webhooks like subscriptions. These subscriptions are manipulated via a REST API just like any other resource. That's it. Really.

From developer.cisco.com learning:

Meraki Webhooks are a powerful and lightweight new way to subscribe to alerts sent from the Meraki Cloud when an event occurs. These include a JSON formatted message and are sent to a unique URL where they can be processed, stored or used to trigger powerful automations. For a comprehensive list of alerts, please see our general documentation on Monitoring and Alerting.

TO use webex webhooks you must first subscribe to a webex webhook as follows:

1. Authenticate your request, just as you would when consuming the API.
2. Pick a name for your webhook subscription.
3. Set the target URL. This URL (or IP address) will be notified when the webhook triggers.
4. Select the subscription resource. This, together with the event parameter/ determines about which events you will be notified.
5. Add filters. In this case, you only care about messages, posted in a specific room, so you add a room filter.

   From Devnet:

This POST request modifies the resource. If you change that to a GET your response will be a list of all the webhooks currently subscribed

If that POST request was successful, the server will send a webhook notification to your listener, that you have to setup. Several good s/w packages exist, your you can write your own using python,

• pagination
• authentication
• rate limiting

See HTTP Response Codes

documentation

From RFC 6750: use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport.

See API Authentication file.

• response = requests.post(url,data=json.dumps(payload), headers=myheaders, auth=(switchuser,switchpassword)).json() # nx-api
• response = requests.request("GET", url, headers=headers, data=payload, timeout=400) # amp
• response = requests.request('GET', url, headers=headers, data = payload) # dna-c
• response = requests.request('POST', url, headers=headers, data = payload # dna-c
• response = session.push_toapic(tenant.get_url(), data=tenant.get_json()) # aci (pre-standard REST API)

See 3.1 Construct a Python script that uses a Cisco SDK given SDK documentation in the api.org file

(Meraki, Cisco DNA Center, ACI, Cisco SD-WAN, and NSO)

(UCS Manager, UCS Director, and Intersight)

(Webex Teams, Webex devices, Cisco Unified Communication Manager including AXL and UDS interfaces, and Finesse)

Umbrella, AMP, ISE and ThreatGrid)

ThreatGrid

• Module - a pluggable and configurable code component that handles API communication with an integrated product or data source.
• Observable - any identifiable network or system artifact that can be observed. Eg; File hashes, IP and other addresses, user accounts, etc.
• Judgement - an opinion held by an integrated product or data source about an observable at a given time.
• Verdict - a single Judgement deemed by Threat Response to be the most accurate/trustworthy at the current time.
• Sighting - an observation of an observable. For example, an endpoint detecting a file hash detected on a filesystem, or on the network by a firewall.
• Target - a system that interacted with an observable. All local sightings will involve one or more targets.
• CTIM - Cisco Threat Intelligence Model. A data model that lays out items, parameters, and relationships, in order to encapsulate security knowledge.
• CTIA - Cisco Threat Intelligence Architecture. An instance of a database housing data in CTIM format.
• Scopes - Granular permissions that control what various user accounts and API clients can do. For example, trigger responses or write to the private data store.

The API is actually a suite of APIs. They are documented at https://visibility.amp.cisco.com/#/help/integration.

The APIs available at the time of this lab's creation are:

• inspect - take text input and find observables within it
• enrich - various lookups on observables, including finding sightings and judgements
• response - catalog and take response actions
• settings - manage user account setting
• oauth - handle authentication for Threat Response users and API clients
• global-intel - manages retrieval of a wide variety of data types in the public CTIA
• private-intel - manages creation and retrieval of a wide variety of data types in the user-private CTIA

Example script to generate Threat Grid API Token Https://visibility.amp.cisco.com/iroh/oauth2/token

import requests
import time

client_id = 'client-asdf12-34as-df12-34as-df1234asdf12'
client_password = 'asdf1234asdf1234asdf1234asdf1234asdf1234asdf1234asdf12'
url = 'https://visibility.amp.cisco.com/iroh/oauth2/token'
headers = {'Content-Type':'application/x-www-form-urlencoded', 'Accept':'application/json'}
payload = {'grant_type':'client_credentials'}

response = requests.post(url, headers=headers, auth=(client_id, client_password), data=payload)

print(response.json())

Code Exchange, support, forums, Learning Labs, and API documentation) See the file: api.org

NETCONF) in a Cisco environment

requirements and given API reference documentation such as these:

• private cloud,
• public cloud,
• hybrid cloud,
• edge

( see also 5.4) and ci-cd.org file.

See Unit Tests

import unittest
from circles import circle_area
from math import pi

class TestCircleArea(unittest.TestCase):
  def test_area(self):
    # Test areas when radius >=0
    self.assertAlmostEqual(circle_area(1), pi)
    self.assertAlmostEqual(circle_area(2.1), pi*2.1**2)
    self.assertAlmostEqual(circle_area(0 ), 0)

  def test_values(self):
    # Make sure value errors are raised
    self.assertRaises(ValueError, circle_area, -2)
    self.assertRaises(ValueError, circle_area, -2)

See Containers vs VMs

encryption (storage and transport), and data handling

deployment

OWASP is Open Web Application Security Project, a non-profit international organization. About web application security.

1. Injection: Injection attacks happen when untrusted data is sent to a code

interpreter through a form input or some other data submission to a web application. For example, an attacker could enter SQL database code into a form that expects a plaintext username. If that form input is not properly secured, this would result in that SQL code being executed. This is known as an SQL injection attack.

1. Injection attacks can be prevented by validating and/or sanitizing

user-submitted data. (Validation means rejecting suspicious-looking data, while sanitization refers to cleaning up the suspicious-looking parts of the data.) In addition, a database admin can set controls to minimize the amount of information an injection attack can expose.

1. Broken Authentication

Vulnerabilities in authentication (login) systems can give attackers access to user accounts and even the ability to compromise an entire system using an admin account. For example, an attacker can take a list containing thousands of known username/password combinations obtained during a data breach and use a script to try all those combinations on a login system to see if there are any that work.

Some strategies to mitigate authentication vulnerabilities are requiring two-factor authentication (2FA) as well as limiting or delaying repeated login attempts using rate limiting.

1. Sensitive Data Exposure

If web applications don’t protect sensitive data such as financial information and passwords, attackers can gain access to that data and sell, or utilize it for nefarious purposes. One popular method for stealing sensitive information is using an on-path attack.

Data exposure risk can be minimized by encrypting all sensitive data as well as disabling the caching* of any sensitive information. Additionally, web application developers should take care to ensure that they are not unnecessarily storing any sensitive data.

1. XML External Entities (XEE)

This is an attack against a web application that parses XML* input. This input can reference an external entity, attempting to exploit a vulnerability in the parser. An ‘external entity’ in this context refers to a storage unit, such as a hard drive. An XML parser can be duped into sending data to an unauthorized external entity, which can pass sensitive data directly to an attacker.

The best ways to prevent XEE attacks are to have web applications accept a less complex type of data, such as JSON**, or at the very least to patch XML parsers and disable the use of external entities in an XML application.

*XML or Extensible Markup Language is a markup language intended to be both human-readable and machine-readable. Due to its complexity and security vulnerabilities, it is now being phased out of use in many web applications.

**JavaScript Object Notation (JSON) is a type of simple, human-readable notation often used to transmit data over the internet. Although it was originally created for JavaScript, JSON is language-agnostic and can be interpreted by many different programming languages.

1. Broken Access Control

Access control refers a system that controls access to information or functionality. Broken access controls allow attackers to bypass authorization and perform tasks as though they were privileged users such as administrators. For example a web application could allow a user to change which account they are logged in as simply by changing part of a url, without any other verification.

Access controls can be secured by ensuring that a web application uses authorization tokens* and sets tight controls on them.

*Many services issue authorization tokens when users log in. Every privileged request that a user makes will require that the authorization token be present. This is a secure way to ensure that the user is who they say they are, without having to constantly enter their login credentials.

1. 6. Security Misconfiguration

Security misconfiguration is the most common vulnerability on the list, and is often the result of using ~default configurations~ or displaying excessively verbose errors. For instance, an application could show a user overly-descriptive errors which may reveal vulnerabilities in the application. This can be mitigated by removing any unused features in the code and ensuring that error messages are more general.

1. Cross-Site Scripting

Cross-site scripting vulnerabilities occur when web applications allow users to add custom code into a url path or onto a website that will be seen by other users. This vulnerability can be exploited to run malicious JavaScript code on a victim’s browser. For example, an attacker could send an email to a victim that appears to be from a trusted bank, with a link to that bank’s website. This link could have some malicious JavaScript code tagged onto the end of the url. If the bank’s site is not properly protected against cross-site scripting, then that malicious code will be run in the victim’s web browser when they click on the link.

Mitigation strategies for cross-site scripting include escaping untrusted HTTP requests as well as validating and/or sanitizing user-generated content. Using modern web development frameworks like ReactJS and Ruby on *Rails also provides some built-in cross-site scripting protection.

1. Insecure Deserialization

This threat targets the many web applications which frequently serialize and deserialize data. Serialization means taking objects from the application code and converting them into a format that can be used for another purpose, such as storing the data to disk or streaming it. Deserialization is just the opposite: converting serialized data back into objects the application can use. Serialization is sort of like packing furniture away into boxes before a move, and deserialization is like unpacking the boxes and assembling the furniture after the move. An insecure deserialization attack is like having the movers tamper with the contents of the boxes before they are unpacked.

An insecure deserialization exploit is the result of deserializing data from untrusted sources, and can result in serious consequences like DDoS attacks and remote code execution attacks. While steps can be taken to try and catch attackers, such as monitoring deserialization and implementing type checks, the only sure way to protect against insecure deserialization attacks is to prohibit the deserialization of data from untrusted sources.

1. Using Components With Known Vulnerabilities

Many modern web developers use components such as libraries and frameworks in their web applications. These components are pieces of software that help developers avoid redundant work and provide needed functionality; common example include front-end frameworks like React and smaller libraries that used to add share icons or a/b testing. Some attackers look for vulnerabilities in these components which they can then use to orchestrate attacks. Some of the more popular components are used on hundreds of thousands of websites; an attacker finding a security hole in one of these components could leave hundreds of thousands of sites vulnerable to exploit.

Component developers often offer security patches and updates to plug up known vulnerabilities, but web application developers don’t always have the patched or most-recent versions of components running on their applications. To minimize the risk of running components with known vulnerabilities, developers should remove unused components from their projects, as well as ensuring that they are receiving components from a trusted source and ensuring they are up to date.

1. Insufficient Logging And Monitoring

Many web applications are not taking enough steps to detect data breaches. The average discovery time for a breach is around 200 days after it has happened. This gives attackers a lot of time to cause damage before there is any response. OWASP recommends that web developers should implement logging and monitoring as well as incident response plans to ensure that they are made aware of attacks on their applications.

environmental variables)

automation

(such as VIRL and pyATS)

automation. (See also 4.4)

Chef, and Cisco NSO

APIs including ACI, Meraki, Cisco DNA Center, or RESTCONF

packages, user management related to services, basic service configuration, and start/stop)

management, app install, user management, directory navigation)

* unified diff mode When run in unified diff mode with the -u option you get:

• First two lines are
  • — from-file from-file-modification-time
  • + to-file to-file-modification-time

  --- 1stfile	2020-05-22 11:32:48.000000000 -0400
  +++ 2ndfile	2021-02-02 16:20:15.000000000 -0500
  

Next come one or more hunks of differences with this syntax: @@ from-file-line-numbers to-file-line-numbers @@

@@ -1,12 +1,10 @@
line-from-either-file
line-from-either-file…

If a hunk and its context contain two or more lines, its line numbers look like ‘start,count’. Otherwise only its end line number appears.

The lines common to both files begin with a space character. The lines that actually differ between the two files have one of the following indicator characters in the left print column:

• ‘+’ A line was added here to the first file.
• ‘-’ A line was removed here from the first file.

So it is always relative to the *first* file.

Here is a larger example:

$ diff -u 1stfile 2ndfile
--- 1stfile	2020-05-22 11:32:48.000000000 -0400
+++ 2ndfile	2021-02-02 16:20:15.000000000 -0500
@@ -1,12 +1,10 @@
 #
-# macOS Notice
+# macOS Notice  : this can be deleted
 #
 # This file is not consulted for DNS hostname resolution, address
 # resolution, or the DNS query routing mechanism used by most
 # processes on this system.
 #
-# To view the DNS configuration used by this system, use:
-#   scutil --dns
 #
 # SEE ALSO
 #   dns-sd(1), scutil(8)
@@ -17,3 +15,5 @@
 nameserver 208.67.220.220
 You can get so confused that you'll start in to race
 down long wiggled roads at a break-necking pace
+And
+On and on.

There are many ways to do code reviews. Each one has its own benefits, but most of them can get the job done. The most common types of code review processes include:

Formal code review Change-based code review Over-the-shoulder code review Email pass-around

Formal code review A formal code review is where developers have a series of meetings to review the whole codebase. In this meeting, they go over the code line by line, discussing each one in detail. This type of code review process promotes discussion between all of the reviewers.

A formal code review enables reviewers to reach a consensus, which may result in better feedback. It usually requires a series of meetings; because it is going through the whole codebase, there is a lot of code to review and therefore takes more time than a single meeting can accommodate. Also, you might do a new code review every time the comments are addressed.

Details of the code review meetings, such as the attendees, the comments, and comments that will be addressed, are documented. This type of code review is often called Fagan inspection and is common for projects that use the waterfall software development methodology.

A modern adaptation of the formal code review is to have a single meeting to review only the code changes. This way, the code can benefit from the live discussion amongst reviewers. This is sometimes known as a walkthrough.

Change-based code review A change-based code review, also known as a tool-assisted code review, reviews code that was changed as a result of a bug, user story, feature, commit, etc.

In order to determine the code changes that need to be reviewed, a peer code review tool that highlights the code changes to be reviewed is typically used. This type of code review is initiated by the developers who made the code changes and are responsible for addressing the agreed upon comments. In this type of code review process, the reviewers usually perform the review independently and provide the comments via the peer code review tool.

A change-based code review makes it is easy to determine the actual code changes to be reviewed and enables multiple reviewers to get a diverse look into the code.

Over-the-shoulder code review An over-the-shoulder code review is exactly what it sounds like. A reviewer looks over the shoulder of the developer who wrote the code. The developer who wrote the code goes through the code changes line by line and the reviewer provides feedback.

With this method, if the fix is not difficult, the code may be changed on the spot so that the reviewer can re-review it on the spot. The benefit of an over-the-shoulder code review is that there is direct interaction between the author of the code and the reviewer, which allows for discussion about what is the right fix. The downside of this type of code review is that it typically involves only one reviewer, so the comments can be one-sided.

Email pass-around An email pass-around piggybacks on the automatic emails sent by source code management systems when a checkin is made. When the emails are sent, it is up to the other developers to review the code changes that were made in that checkin. The downside of this type of code review is that sometimes a single checkin can be just a piece of the whole code change, so it may not include the proper context to fully understand the code changes.

and gateways

routers, firewalls, and load balancers)

routers, firewalls, load balancers, and port values

device

and NETCONF)

• ssh: 22
• telnet: 23
• ftp-data: 20
• ftp: 21 (ftp-data and ftp resp.)
• smtp: 25
• http: 80
• https: 443
• dns: 53

Port blocked, proxy, and VPN)

• curl -s http://checkip.dyndns.org/ | sed 's/[a-zA-Z<>/ :]//g'
• curl https://api.icndb.com/jokes/random?limitTo=nerdy
• curl https://api.icndb.com/jokes/random
• curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
• curl https://deckofcardsapi.com/api/deck/dec40fca2d5/draw/?count=3 | python -m json.tool=
• curl -i -k -X "POST" "https://10.85.116.30:443/restconf/data/Cisco-IOS-XE-native:native/logging/monitor"
• curl -i -X GET http://localhost:8080/api -u admin:admin*

SDN is Software Defined Networking that has a controller that configures all network devices in a centralized fashion, and pushes the configs out to the remote networking devices. Let's one manage the whole network as a whole from the centralized controller.

Cisco SDN are implemented in ACI, DNAC, NSO, SD-WAN, Meraki

Each implements the 3 layers:

1. Infrastructure Layer
2. Control Layer
3. Application Layer

• Reduces complexity Mgt and maintenance become easy
• Simplifies deployment. Only need to declare the final state, the IBN takes care of the details of devices along the way.
• Security improved ML algorithms and AI can learn and respond to new threats before they become an issue.
• Improved agility quick to adapt to changes, as they all happen on the centralized controller
• Eliminates repetition The details of configuration along all the device is automatic, so you are left with littel repetition

• Cisco ACI
• Cisco DNA Center
• Cisco SD-WAN
• Cisco Software-Defined Access (SD-Access)
• Cisco NSO

• Network devices: Physical and virtual devices that participate in the network, responsible only for forwarding packets based on instructions from the SDN controller. They communicate with SDN controller's southbound interface.
• SDN controller: The brains of SDN, responsible for communicating with network devices and applications and services using application programming interfaces (APIs). The SDN controller has full awareness of the network state by keeping information in a local database.
• Southbound interface: This interface is a layer of device drivers that the SDN controller uses for interacting with physical and virtual devices in the network.
• Northbound interface: Representational State Transfer (REST) APIs facing outside the network so applications and services can interact with the SDN controller and use resources in the network.
• Network management applications and services: Clients accessing resources in the network using REST APIs. Clients can be automation user applications, automation servers, or software libraries for many programming languages like Python, Java, Ruby, and others.

• Consistency
• Fast changes
• Dynamic changes
• Better security through dynamic isolation of threats, and consistency
• programmable