The Implementing and Administering Cisco Solutions (200-301 CCNA) v1.1 (200-301)

An endpoint is a host that acts as the source or destination of data traffic flowing through a network.

When you are at your PC, editing your CV and uploading it to a file server, you are sitting at an endpoint.

WPA3 uses stronger encryption and security mechanisms than WPA2. The protocol associated with WPA3 is GCMP.

GCMP (Galois/Counter Mode Protocol) is used with WPA3.

It provides stronger security and better performance than older protocols.

A. CCMP: associated mainly with WPA2, not WPA3.

B. MD5: a hashing algorithm, not a WPA3 wireless encryption protocol.

C. TKIP: older and insecure; used with WPA/WPA2 legacy environments, not WPA3.

WPA2 → CCMP

WPA3 → GCMP

Why D is correct:Why the others are incorrect:CCNA takeaway:

In an SDN architecture, the SDN controller sits between the network infrastructure and the applications.

There are two main API directions:

Northbound APIs: between the SDN controller and applications

Southbound APIs: between the SDN controller and network devices

Applications communicate with the controller using northbound APIs, and these are commonly implemented as REST APIs.

REST API is the common method used by applications to interact with the SDN controller.

It allows software and orchestration platforms to request network information or make policy changes through HTTP-based calls.

B. OpenFlow: used between the controller and network devices, not applications.

C. Southbound API: this refers to controller-to-device communication, not controller-to-application communication.

D. NETCONF: used for device configuration and management, typically between controllers/management platforms and devices, not primarily for app-to-controller communication.

Why A is correct:Why the others are incorrect:CCNA takeaway:If the question asks about applications talking to the SDN controller, think:

Northbound API → usually REST API

DHCPOFFER is used to identify spurious DHCP servers. A spurious DHCP server is any device that is configured to act as a DHCP server without the network administrator’s knowledge or permission. A spurious DHCP server can cause network problems by assigning incorrect or duplicate IP addresses to clients, or by redirecting traffic to malicious gateways. To prevent such attacks, the DHCP snooping feature can be enabled on switches to filter out invalid or unauthorized DHCP messages from untrusted sources1.

DHCP snooping works by intercepting and validating DHCP messages on a per-VLAN basis. The switch maintains a DHCP snooping binding database that contains information about the trusted hosts with leased IP addresses, such as MAC address, IP address, lease time, binding type, VLAN number, and interface information2. The switch also classifies its ports as trusted or untrusted. Trusted ports are those that connect to authorized DHCP servers or other trusted switches. Untrusted ports are those that connect to untrusted hosts or devices. The switch only allows DHCP messages from trusted ports, and drops any DHCP messages from untrusted ports that do not match the information in the binding database3.

The switch uses DHCPOFFER messages to identify spurious DHCP servers. A DHCPOFFER message is a response from a DHCP server to a client’s request for an IP address. The message contains the offered IP address, subnet mask, default gateway, and other configuration parameters for the client4. When the switch receives a DHCPOFFER message from an untrusted port, it compares the source MAC address and the offered IP address with the binding database. If there is no match, the switch considers the message as coming from a spurious DHCP server and drops it. The switch also logs an error message and increments a counter for the number of dropped messages5.

We have to configure the link which will need 2 IP addresses, 1 for each port on each Router. We also need 2 spare IPs for future growth, so overall we need 4 usable IP addresses. If we consider using the /30 (255.255.255.252) mask, it will give us 2^2 (=4) i.e., total 4 IPs and 2 usable IPs, which doesn’t fulfil the given requirements. So, we can consider using the next /29 (255.255.255.248) mask, which gives us 2^3 (=8) i.e., total 8 IP address and 6 usable IP addresses, which perfectly fulfil the given requirements.

PUT is most-often utilized for **update** capabilities, PUT-ing to a known resource URI with the request body containing the newly-updated representation of the original resource.

However, PUT can also be used to create a resource in the case where the resource ID is chosen by the client instead of by the server. In other words, if the PUT is to a URI that contains the value of a non-existent resource ID. Again, the request body contains a resource representation. Many feel this is convoluted and confusing. Consequently, this method of creation should be used sparingly, if at all.

Alternatively, use POST to create new resources and provide the client-defined ID in the body representation—presumably to a URI that doesn’t include the ID of the resource (see POST below).

On successful update, return 200 (or 204 if not returning any content in the body) from a PUT. If using PUT for create, return HTTP status 201 on successful creation. A body in the response is optional—providing one consumes more bandwidth. It is not necessary to return a link via a Location header in the creation case since the client already set the resource ID.

PUT is not a safe operation, in that it modifies (or creates) state on the server, but it is idempotent. In other words, if you create or update a resource using PUT and then make that same call again, the resource is still there and still has the same state as it did with the first call.

If, for instance, calling PUT on a resource increments a counter within the resource, the call is no longer idempotent. Sometimes that happens and it may be enough to document that the call is not idempotent. However, it’s recommended to keep PUT requests idempotent. It is strongly recommended to use POST for non-idempotent requests.

Examples:

https://www.restapitutorial.com/lessons/httpmethods.html

Firewalls are devices that are used to separate networks into different security domains. They act as a barrier between two networks and control the flow of traffic between them. Firewalls use a set of rules to determine what types of traffic are allowed to pass through and what is blocked. This helps protect a network from malicious traffic and unauthorized access. Additionally, firewalls can be configured to log traffic and provide additional security measures such as packet filtering and stateful inspection.

IPsec encryption mode is the way IPsec secures the data packets that are sent over an IP network. There are two main modes of IPsec encryption: tunnel mode and transport mode1. Tunnel mode encrypts the entire IP packet, including the original header, and adds a new IP header with the source and destination addresses of the security gateways (routers, firewalls, or VPN servers) that perform the encryption and decryption2. Transport mode encrypts only the payload (data) of the IP packet, leaving the original header intact, and uses the original source and destination addresses of the endpoints that generate and consume the data3. Therefore, transport mode is appropriate when the destination of a packet differs from the security termination point, as it does not change the original IP header information. Tunnel mode is more suitable when the security termination point is also the destination of the packet, as it provides more protection for the original IP header information.

The virtual router MAC address associated with a virtual router is an

  IEEE 802 MAC Address in the following format:

   00-00-5E-00-01-{VRID} (in hex in internet standard bit-order)