![350-701: Implementing and Operating Cisco Security Core Technologies Training Course](/design/img/courses/9828.jpg)
350-701: Implementing and Operating Cisco Security Core Technologies Certification Video Training Course
The complete solution to prepare for for your exam with 350-701: Implementing and Operating Cisco Security Core Technologies certification video training course. The 350-701: Implementing and Operating Cisco Security Core Technologies certification video training course contains a complete set of videos that will provide you with thorough knowledge to understand the key concepts. Top notch prep including Cisco SCOR 350-701 exam dumps, study guide & practice test questions and answers.
350-701: Implementing and Operating Cisco Security Core Technologies Certification Video Training Course Exam Curriculum
Cisco Certifications - CCNP SCOR
-
1. Cisco Certification Updates - FEB 2020
-
2. Cisco Re-Certifications
-
3. CCNP Certifications
-
4. CCIE Certifications
-
5. Cisco Certification Migration Options
-
6. CCNP Required Exams
Security Core - 350-701
-
1. CCNP Security Certifications
-
2. CCNP SCOR - 350-701
-
3. SCOR 350-701 Contents
Network Security Concepts
-
1. Network Security Terminology
-
2. Goals of Network Security
-
3. Threat Types - Mitigation
-
4. Assets - Classification of Assets
-
5. Classify Counter Measures
-
6. Classify Vulnerabilities
-
7. Network Security - Design Principles
Common Security Attacks - Mitigation
-
1. Motivations behind Network Attacks
-
2. Social Engineering Attacks
-
3. Phishing Attacks
-
4. Social Engineering Attacks
-
5. Denial of Service Attacks - DoS
-
6. Distributed Denial of Service Attakcs - DDoS
-
7. Spoofing Attacks
-
8. Spoofing Attacks - Mitigation
-
9. Man in the Middle Attacks -MiTM
-
10. Password Attacks
-
11. Password Attacks - Mitigation
-
12. Reflector Attacks
-
13. Amplification Attacks
-
14. Reconnaissance Attacks
-
15. Reconnaissance Attacks - Mitigation
Malicious Codes - Hacking
-
1. Malicious Codes - VIRUS
-
2. Malicious Codes - WORMS
-
3. Malicious Codes - TROJAN HORSES
-
4. Hacking
-
5. Hackers - Script Kiddies
-
6. Malware Service - DARKNET
Threat Defense Technologies
-
1. AAA - Network Security
-
2. Cisco Telemetry Services
-
3. Firewall
-
4. Intrusion Prevention System - IPS
-
5. Virtual Private Networks
-
6. Next Generation Firewalls
Virtual Labs - GNS3 Setup
-
1. Cisco Lab Options
-
2. About GNS3
-
3. Installing GNS3 - Windows
-
4. GNS3 - IOS Images
-
5. Default Topology - GNS3 - IOS initial Configs
-
6. IOS Default Topology
-
7. GNS3 Topology-HOST Computer
-
8. GNS3 - VMware Setup
-
9. GNS3 - IOSv L2-L3
-
10. GNS3 - ASAv Setup
-
11. GNS3 - IOU-L2-L3
Network Infrastructure Protection
-
1. Network Infrastructure Protection
-
2. Identify Network Device Planes
-
3. Data Plane
-
4. Control Plane
-
5. Management Plane
Remote Management- TELNET - SSH
-
1. Inband Vs OutBand Management
-
2. Remote Access - TELNET
-
3. Remote Access - SSH
Cisco Telemetry Services
-
1. Cisco Telemetry Services
-
2. Device- Network Events Logging
-
3. Syslog - Terminal Logging
-
4. Network Time Protocol
-
5. NTP Stratum Value
-
6. NTP Configuration - LAB
Control Plane Security
-
1. Control Plane Security - Possible Threats
-
2. Routing Protocol Authentication
-
3. Control Plane Policing - CoPP
-
4. Class-Map - Policy Map - Hierarchy
-
5. CoPP - Configuration Examples
L2-Security Basic
-
1. Switch Security - Overview
-
2. Disable Unused Ports
-
3. Dynamic Trunking Protocol - DTP
-
4. DTP Vulnerabilities - Mitigation
-
5. VLAN Hopping Attacks - Mitigation
-
6. Cisco Discovery Protocol - CDP
-
7. Link Layer Discovery Protocol - LLDP
-
8. CDP- LLDP Vulnerabilities - Mitigation
L2-Security Advanced
-
1. MAC Flooding Attack - Port Security
-
2. MAC Spoofing Attack - Port Security
-
3. Port Security - Configuration
-
4. Spanning Tree Port Fast
-
5. Native VLAN
-
6. DHCP Spoofing Attack - DHCP Spoofing
-
7. DHCP Snooping - Configuration
-
8. DHCP Starvation Attack - Mitigation
-
9. ARP Spoofing Attack - DAI
-
10. Dynamic ARP Inspection - Configuration
-
11. Protected Ports- Private VLAN Edge
-
12. Private VLAN
-
13. Private VLAN - Configuration
-
14. Private VLAN - LAB
Firewalls
-
1. What is Firewall
-
2. Statefull Packet Filtering
-
3. Stateless Packet Filtering
-
4. Application Level Gateways - Proxy Servers
-
5. Next Generation Firewalls
-
6. FIrewall Vendors in Market
Cisco ASA Firewall
-
1. Cisco Statefull Firewalls - IOS - ASA
-
2. ASA Supported Features _ PART1
-
3. ASA Supported Features _ PART2
-
4. ASS Compare Models
Cisco ASA Configuration
-
1. Manage Cisco CLI - ASA - GUI
-
2. Basic CLI Modes - Commands
-
3. ASA Security Levels
-
4. ASA Interface Configurations
-
5. ASA Security Policies - Default
-
6. ASA Routing
ASA ACLs - Object Groups
-
1. ASA ACls - Overview
-
2. ASA ACLS - Basic Example
-
3. Traffic Between Same Security Levels
-
4. ACL Object Groups
-
5. ACL Object Groups - LAB
ASA _ Network Address Translation (NAT)
-
1. PRivate IP - Public IP
-
2. What is NAT ?
-
3. NAT Types
-
4. Dynamic NAT - on ASA
-
5. Dynamic PAT- ASA
-
6. Dynamic PAT - with Exit interface
-
7. Dynamic NAT-PAT Combination
-
8. Static NAT - ASA
-
9. Static PAT- ASA
IOS - Zone Based Firewall
-
1. IOS - Zone Based Firewall
-
2. ZBF - Configuration Overview
-
3. ZBF - Security Zones
-
4. ZBF - Default Flow
-
5. Class-Map - Policy Map - Hierarchy
-
6. ZBF - Classify Traffic using Class-Maps
-
7. ZBF- Class-map Configuration
-
8. ZBF - POlicy Map - Zone Pairs
Cryptography
-
1. What is Cryptography
-
2. Goals of Cryptography
-
3. Hashing-How it Works
-
4. Hashing with HMAC
-
5. What is Encryption - Decryption
-
6. Encryption Algorithms - Symmetric vs Assymetric
-
7. Cryptanalysis - Attacks
-
8. Asymmetric Encryption - Drawbacks
-
9. Public Key Infrastructure - PKI
VPN foundations
-
1. Virutal Private Network - Introduction
-
2. VPN Types - Site to Site / Remote Access
-
3. VPN Logical Topologies
-
4. VPN Default Lab Setup - Routers
IPSec - IP Protocol Security
-
1. What is IPSec ?
-
2. IPsec Security Services
-
3. IPSec Modes - Tunnel vs Transport
Site to Site IPSEC VPN
-
1. How IPsec VPN Works
-
2. Step-1 - Interesting Traffic
-
3. Step-2 IKE Phase-1
-
4. Step-3 - IKE Phase 2
-
5. IKE Phase 2 - Configuration/ Verification
Remote Access VPN
-
1. Remote Access VPN
-
2. What is SSL-TLS
-
3. How SSL-TLS Works
-
4. What is SSL VPN
-
5. SSL VPN - Modes
Authentication, Authorization, Accounting - AAA
-
1. AAA - Network Security
-
2. AAA - Components
-
3. AAA Protocols - TACACS - RADIUS
-
4. AAA- Cisco Authentication Servers
AAA Authentication
-
1. AAA Authentication - Device Access
-
2. Authentication Local database
-
3. AAA External Servers
-
4. Authentication - External server (TACACS)
AAA Authorization
-
1. Authorization - Device Access
-
2. IOS Privilege Levels
-
3. Local Authorization using Privilege Levels
-
4. IOS Privilege Levels _ Limitations
-
5. Role based CLI Access - RBAC
-
6. RBAC Views - Types
-
7. RBAC Views - LAB1
-
8. Modify RBAC Views - LAB 2
-
9. Modify RBAC Views - LAB 3
-
10. RBAC - Super Views
WEb Traffic - Attacks- Solutions
-
1. Web Access - Possible Threats
-
2. Web Based Attacks-
-
3. Web Attack Examples
-
4. Web Security Solutions
CIsco Web Security Appliance - WSA
-
1. Cisco Web Security - WSA-CWS
-
2. What is WSA ?
-
3. WSA- HOw it Works
-
4. WSA Deployment Modes
-
5. WSA models - Physical -Virtual Appliance
-
6. WSA Licensing Options
Email Security _ ESA
-
1. Email Based Threats
-
2. Cisco Email Security Appliance - ESA
Intrusion Prevention System - IPS
-
1. Intrusion Prevention System - IPS
-
2. IDS vs IPS
-
3. Host Based IPS vs Network Based IPS
-
4. IPS Deployment Modes - INline vs Promiscious
-
5. Cisco IPS Solutions
-
6. IPS Threat Detection Methods
-
7. IPS Signature Alarm Types
-
8. IPS Signature Actions
-
9. IPS Evasion Methods - CounterMeasures
Network Management
-
1. What is Network Management
-
2. Past-Present Methods of Network Mangement- PART 1
-
3. Past-Present Methods of Network Mangement- PART 2
-
4. SNMP- Simple Network Mangement Protocol
Network Automation
-
1. Challenges - Traditional Management
-
2. Network Automation - Goals
-
3. Types of Network Automation
-
4. What can be Automated - PART 1
-
5. What can be Automated - PART 2
-
6. Impact of Network Automation
SDN & SDN Controllers
-
1. Automation Origination Points
-
2. SDN - Software Defined Networking
-
3. SDN Controllers
-
4. Networks Managed by SDN Controllers
SDN-Control-MGMT-DATA Plane
-
1. Management Plane
-
2. SDN-Management Plane
SDN Models - Architecture
-
1. SDN - Imperative Model
-
2. SDN - Declarative Model
-
3. SDN - Network Design Requirments
-
4. UNderlaY Networks
-
5. Overlay Networks
-
6. SDN Fabric
Application Programming Interface - API
-
1. Application Programming Interface - API
-
2. API Types
-
3. API - With SDN Networks
-
4. NorthBound API
-
5. SouthBound API
Cisco DEVNET - SANDBOXs
-
1. Cisco DevNet
-
2. DevNet Certifications
-
3. DevNet Sandbox
-
4. DevNet Sandbox LABS
-
5. Sandbox LAB Access - Reservations
Cisco DNA Center
-
1. Cisco DNA Center
-
2. DNA Center Appliance
-
3. DNA Center- What can do - PART 1
-
4. DNA Center- What can do - PART 2
Web Service API - REST API
-
1. Web Service API
-
2. Web Service API - Commonly Used
-
3. REST API
Network Automation Tools
-
1. Config Management Tools
-
2. Config Management Tools - Capabilities
-
3. Master-Agent
-
4. Agent Based vs Agentless
-
5. Push-Pull Model
-
6. Configuration Files
PUPPET - Config MGMT Tool
-
1. PUPPET - Config MGMT Tool
-
2. PUPPET-Master Agent Database
-
3. PUPPET - Manifest
-
4. PUPPET-Module-Forge
-
5. PUPPET-Agent- Agentless
-
6. PUPPET-PULL Model Steps
CHEF- Config MGMT Tool
-
1. CHEF- Config MGMT Tool
-
2. CHEF- Terminology
ANSIBLE- COnfig MGMT Tool
-
1. ANSIBLE- COnfig MGMT Tool
-
2. ANSIBLE- Control Station
-
3. ANSIBLE- PlayBook-Inventory
-
4. ANSIBLE- Templates-Variables
JSON Data Encoding
-
1. API Data Formats
-
2. JSON Overview
-
3. JSON Data Types
-
4. JSON Syntax Rules
-
5. JSON Data Interpretation
About 350-701: Implementing and Operating Cisco Security Core Technologies Certification Video Training Course
350-701: Implementing and Operating Cisco Security Core Technologies certification video training course by prepaway along with practice test questions and answers, study guide and exam dumps provides the ultimate training package to help you pass.
Cisco Telemetry Services
1. Cisco Telemetry Services
Okay, now in this video we'll discuss some of the multiple methods used by the administrator to monitor network activity. Because as an administrator, it's important for you to monitor the input activity and ensure that the network is up and running. So if any device fails, you probably need to get some alerts and reports, and based on that, we can troubleshoot.
So probably in this section we'll talk about some of the multiple options that we'll be using to do all these jobs and commands. We call it "telemetry methods" or "traffic." Telemetry methods: it's a word derived from the Greek roots where "Dele" stands for remote and "measure" is nothing but monitoring or calculating. So it's very important for the network administrator to detect what kind of traffic is actually moving into a network. If you find any unusual network traffic, like malicious traffic going on the network, you can monitor that and take appropriate action to prevent some kinds of attacks.
Also, if any kind of device fails, you need to get some alerts or have some information about the device for you to fix it if you get the information that the device is powered on. So there are multiple methods we'll be using here, like something called NTP. So NTP is an abbreviation for networks and protocol. It is primarily used for all devices that share a synchronised time because dates in time necessitate accurate and synchronised time across all devices. As a result, we will enable NTP, a common method of time synchronisation between networking devices. And apart from that, we are using something called SNMP or SNMP traps. Probably the SNMP feature allows you to monitor the securitization of the device, the memory utilisation of the device, or maybe the interface bandwidth—multiple things.
And these statistics can be filtered by the Snmb server, and based on that information, you can actually monitor the device status, the connectivity, and many other things. And also, we'll be engaging in something called logging. So logging is a feature that allows us to keep track of the events and changes that occur in the network.
We can specifically log and instruct the device to send log messages if any of the topic matching or incidents occur, such as the interface going down or the Eager neighborhood going down, or something similar. Apart from that, we can also use some other features, like Netflix. Netflix is a method used to collect network traffic statistics, and we can export selected traffic to some NetFlowcollective software, and based on that, it's going to give some statistics in a graphical way. So all these options are collectively referred to as "traffic elimination methods," and using these methods we can ensure that the network operates and is always available.
2. Device- Network Events Logging
So network devices by default generate log messages, and these log messages can be used to keep track of the events or changes occurring in your network. As an example, if I go to the command line whenever you make any changes, I'm currently in my device's console screen. So this is my console screen, let's say. And whenever you make any changes on this console screen, for example, if I try to shut down one of the interfaces, it is by default in upstate. So whenever you shut down the interface immediately, you'll see some messages appear here. This is an indication that this specific portfolio as one has been insured with these options on this date and time. And whenever I bring the interface up again, the interface comes back, and you see some messages here.
So like that, you'll see different types of messages in general on the console screen by default. Now these messages are typically referred to as "log messages," and these long messages are automatically generated. By using these messages, we can keep track of the events occurring in your network. Generally, some of the log messages that help us are like device failure notifications, like when you get a router and one of the interfaces fails or goes down, which is a log message. Or it could be another type of message, such as when you connect to a router and try to establish the EHRP neighborhood, and the neighbourhood fails, generating a message; or when you connect to a service portal network and have some BTB connections, and the neighbourhood fails, generating a log message in general.
Or you can also use specific log messages. For example, I can go to the router and configure the ACL to match a specific traffic pattern, and I can tell the router to generate log messages if any traffic matters, that particular pattern, which can be used for auditing or even troubleshooting. It's also useful if you have a router problem, such as when the neighbour ship goes down and the neighbour ship flails, or when the VPN fails to connect, something isn't working properly, and you just want to see what's going on in the back end. So we can enable the logging for the debug messages, and then we can see the back-end messages and what is going on in the back end. So there's also another reason for generating the log messages and keeping track of them.
And of course, you can also use it for foreign analysis, like for some kind of incident investigation. So let's say something occurred in your network, maybe some kind of attack, and you want to see some of these previous log messages that are generated on this particular device, where we can trace the victim and attacker and determine at which point it actually occurred. So we do enable some logging messages. Of course, the device generates some log messages to some extent, and we need to keep track of those messages for multiple reasons. We now have logging options such as console logging (VDI), a local buffer, and an external log service. Console logging is used whenever you connect to a device, such as a router, using a console cable.
Of course, I'm using GNS 3 to connect. But by default, when you open up the console, it's almost like a console connection here. As an example, suppose you connect your router to a physical console port and access the router through the console port. And by default, logging is enabled on this particular port. And whatever changes occur in your network will be displayed by default on the console port. But by default, these messages are not saved in general. So the console logging is by default enabled in all your router's features, and by default, they send the log messages to the console port, as I just discussed. And hence, only the users who are physically connected to the router console port can view these messages. So if I'm not using the console, I cannot see these messages. So the console access is currently on the router one. Now, by default, these messages are not saved.
For example, even if you try to enable some kind of debug messages in the back end, you will see some kind of debug messages in which hello messages are sent every 5 seconds. So those messages will also be displayed if you enable debug messages by using debug EHRP packets in production. It is recommended to enable console logging because a large amount of logging messages or outputs occur while in a debug process and are sent to the console. So a large amount of log data is sent to the console. By using some debugging, it will increase the necessary CPU load on the routers and can actually impact the control plane. Also, because it can prevent routers from forwarding packets or establishing the control plane. Or maybe it loses some kind of neighborhood. Issues may arise if the router receives too many log messages.
As a result, it is recommended to disable console logging because, in most operational networks, consoles are rarely used because we usually access a device via telnet or SSH from a remote device. And we only use console if there are any major issues, such as performing a password reversion or being unable to log into the web line, in which case you may need to troubleshoot a connectivity or other issue. So most of the time we don't use the console. So it's recommended to disable the console messages by using the no-login console.
So I can simply say "no login console," which is by default enabled. So once I disable this console, if I try to make some changes on the network, let's say my interface goes down, and as you can see, I don't see any log messages displayed here. Now, the other option in the console is that you can use something called buffer logging. In the case of buffer logging, whatever the log message is that is generated, we can tell the router to save these messages in the local buffer memory or the local RAM.
As a result, this type of log makes use of the router ramp to temporarily store log messages. And we can specify the buffer size—the number of bytes—as well as how many bytes should be used to store the log messages. So the buffer is nothing but the fixed size that we are going to allocate to generate the log messages, and the router is going to delete the old messages once it reaches the maximum size.
And let's say the router is receiving the log messages. Anything beyond this amount of memory would be allocated automatically. It will start removing the older entries. Now, buffer logging is by default not enabled. We can enable this by using a command called "log buffer." And if you want to verify the log messages, we can use something like the "Show login option." So let me just quickly enable this buffer logging here.
So in the previous step, I disabled the console login, so I'll try to enable the console login because at this point in time, I want to see the log messages in the logging buffer. And we can define what the buffer size is that you want to look at. Let's say I'm using just 4096, and if you want to verify, I can try deleting some messages, like I'll try to shut down the interface, and then I'll say no shutdown.
Also try to shut down one more interface, let's say "s one by zero," because on the router one, "s one by zero," interface, I'm connecting with router two and I have preconfigured EHRP here. So most likely, if I shut down the S-1 by Zero interface, I should also see that go down here. I think I didn't configure the EHRP. So I don't have EHRP configured. I simply don't have it. So you probably see the messages here; the interface has changed down; I'll make a backup, and now if you want to verify these log messages, we can use the showing logging option.
3. Syslog - Terminal Logging
The next logging option is something like Syslog Server Logging. In this option, we are going to tell the router to send those log messages to the external server or the external computer or PC, which is going to run some application called Syslog Server applications. So, of course, the log messages will be generated by the router.
So whatever the case, the log messages will be exported to some external device. Now we're going to run some external software, which will show you all of the log messages, as well as the date and time they were generated. Of course, if you're using some licence programs, you will have more options to log in again. So by default, this logging is not enabled. We need to login, and we need to enable this syslogging by using a command called Logging Host. You need to go to the login host, and then you need to tell it the IP address of that particular device. So you can also do the same thing on the router too, but make sure that from the router, you have reachability to this particular device that is routing reachable. Of course, in the production networks, we do have routing configured to provide readability between different networks. So I'll show you this option here. At this setup, I'm using my physical computer, which is using some software called Tftbd.
It's a free open source tool that I obtained from the internet. So here we need to select the appropriate interface. The first step is to select the syslog server because I want to use the syslog server application here and connect to the correct interface, which is your GM history. So in my scenario, I'm connecting this VM network to interface two, and it is using the IP address 110. So once you select the correct interface here, I can go to my router, and I can configure the router to generate the log messages. So I'm going to say simply "logging host," and I want all the log messages to be sent to the PC here. So you can see that some messages are appearing right away.
Whatever the message you see here—the same console message—it shows up here. And let's say I'm going to make some changes here. So let's say I'm trying to shut down this interface, and I should see the interface change to down. And again, I'm going to bring the interface back up. And you can see whatever log message is generated here automatically, the same message you normally see here, the production tools. You can use some kind of licence too. So with the licence to use, you will have more options to filter the log messages because in the production network, you have hundreds of devices, and maybe some of those devices send the log messages to a single server. As a result, you can filter those messages and see when they occurred.
And also, you can filter based on the date and time to see the actual events happening on the record. So based on these messages, you can at least come to know that this interface has been changed to "down" by some administrators. So Syslog is commonly used in production scenarios because you generally want all the log messages to be sent to the external server, where you have enough memory to save all those log messages. Now, the last option of the log messages is like terminal logging. Terminal logging is the equivalent of console logging. The only difference is that console logging is enabled by default, whereas terminal logging includes everything done from the VDP line. So let me take an example here. I'm going to use you to initiate a tenant connection to the outdoor one from your PC. I'm going to open the connection on port 23 and, I believe, enter the password.
So now I can see that this is my video line. And whatever you see on the screen is my console output. The screen is like my console, the one that I'm using here. And this is my video line. So most of the production networks use BTW lines to log in. Let's say I'm going to make some changes on the Internet. Let's say I'm trying to shut down. Of course, you can configure some EHRP and verify the neighbourhood and other things. And whenever I make any changes, you can see that it generates a log message. Of course, this log message is shown on the console screen. You can also see it on the syslog server if you have enabled the syslogs, but you don't see them on the PDF because by default the logging is disabled here. So, for the most part, we access the device remotely during the process. And whenever you are making any changes, you always want them to see them. If you're trying to configure some EHRP, you expect the neighbourhood to appear, or if you're making any changes to the interfaces or anything, you'd like to see these messages, some basic information messages. Now, for that, we need to enable the terminal pointer command.
So once I give the terminal point of command, if I make any changes, I'm going to bring the interface up. I can see the messages are displayed exactly the same way as you see them on the console screen. For most of the production network, it's recommended to disable console logging by using the no logging console command because, most of the time, you don't do anything on the console because most of the time we use Btwline. And we can enable this default logging, which is disabled, by using the terminal point of mine.
4. Network Time Protocol
NTP stands for "network time protocol." It's a protocol that allows you to have a common, synchronised time between the networking devices. Because when you're implementing a network, all the devices must have a common synchronised time. because there are some other services that are dependent on having a common time.
For example, you must have an accurate closing, which is required for accurate timestamp logging. In the previous sessions, we configured something like the Silog service, and all the devices sent log messages, whatever the log message is generated. As a result, these log messages can most likely be used to keep track of what is going on. Now it actually shows you the details of what event occurred and at what time on this device. Now, if you don't have a proper synchronised time, the problem is that you may not be able to see the correct details because you don't have a proper synchronised time.
So it will be difficult for the administrator to figure out those log messages and the events. Aside from that, you might be employing something akin to selves. You might want to deny a specific type of traffic, say ATV traffic, from 9:00 a.m. to 5:00 p.m. So, when the traffic is moving to the router, you must ensure that this device has a common or proper time, and that time must also match with the other devices, because if your server or the user who is sending the traffic has a different time and the router has a different time, the traffic will be lost. If you don't have a proper time, some time issues may not work.
Synchronization. Of course, if you're using some kind of advanced-security VPN, like we use some kind of digital certificate validation, or maybe for my web browsers, or maybe for VPNs, if you don't have a proper in-life certificate, your digital certificates may not be validated. And also for other mechanisms, like there's something called "single signal mechanisms." It's a kind of authentication used for multiple applications, and for them to work well, you also need to have a common synchronous time as well. In order to have a proper synchronous time, the NDP network usually gets its time from the source. We'll configure a device with an NDP server, and we expect all the devices to contact the NDP server.
And whatever the time present on this particular device, we can tell the device to synchronise the time between these devices. So we can either use our own internal server, where they can select any router, any server, any PC, or any device as an entity server, and synchronise the time from all the devices you can also contact. Or you can also configure an additional time source on the internet as well. So the NDP server usually gets the time from the authoritative time source. It's just like a radio clock or atomic clock attached to the time server, and then the server is responsible for distributing the time across the different computers across the complete network, which we call entity clients. With NTP, there is something called startup value.
Now, NTP servers can be of two types. A server on the internet, like the NTP server, is also an option. For example, we can configure a device or device to communicate with some external clocks via the internet. You'll find some external blocks on the Internet. For example, if you go to Google and search for some external clocks, NTP time servers, and servers, you'll probably find some different time servers. Now you can configure your device to contact this external clock service to synchronise the time.
So it can be an external clock that always has the starting value of zero. In terms of similar torpor, that is the hog; hop on us and we can configure my device. Let's say I have a router here, and this is my NDP client, and this device is going to contact my external clock server and get the time synchronized, and then I can configure my internal devices. Let's say I have some other routers and PCs that will contact this server, and this is my NTP server, and these are my clients.
So we can still configure this device to contact an additional server, but it is practically not scalable because you don't want each and every device to contact a regional clock and synchronise the time as per the region. That's the reason we can configure our own internal server, and we can either manually set the time on this particular server or I can configure this device to contact the external clock to synchronise the time from the external clock. So if I'm synchronising from an external clock, then this is going to be my client, and this is going to be my server. And then this is going to be a server for all my internal clients.
So by default, an external clock will have a default starter value of zero. That is the time server on the Internet. As a result, it will always be the first value of one on all servers that support NDP in general. So we can configure a startup value of two, like this server's external clock. If it is sending time to my server, which is my client, let's say this is my client. If this starter value is one here, then it becomes two, and it becomes a client for all the remaining devices. We have some other clients who are using this device to synchronise the time. And you can also configure this device to become a server for other clients. The starter value will increase automatically. So your starting value actually tells you how many potentially actual time sources you have. And the default starter value will be one for all the servers. We don't operate like time servers on the internet.
Prepaway's 350-701: Implementing and Operating Cisco Security Core Technologies video training course for passing certification exams is the only solution which you need.
Pass Cisco SCOR 350-701 Exam in First Attempt Guaranteed!
Get 100% Latest Exam Questions, Accurate & Verified Answers As Seen in the Actual Exam!
30 Days Free Updates, Instant Download!
![350-701 Premium Bundle](/design/img/content/popup/premium-training-study/premium-training-study_1x.png)
350-701 Premium Bundle
- Premium File 703 Questions & Answers. Last update: Aug 29, 2024
- Training Course 299 Video Lectures
- Study Guide 701 Pages
Free 350-701 Exam Questions & Cisco 350-701 Dumps | ||
---|---|---|
Cisco.realtests.350-701.v2024-06-19.by.holly.179q.ete |
Views: 491
Downloads: 523
|
Size: 1.88 MB
|
Cisco.examlabs.350-701.v2021-05-21.by.zachary.140q.ete |
Views: 799
Downloads: 1612
|
Size: 1.72 MB
|
Cisco.examcollection.350-701.v2021-04-26.by.austin.113q.ete |
Views: 324
Downloads: 1384
|
Size: 1.5 MB
|
Cisco.selftesttraining.350-701.v2021-03-22.by.giovanni.97q.ete |
Views: 353
Downloads: 1392
|
Size: 369.38 KB
|
Cisco.testkings.350-701.v2021-01-06.by.brahim.81q.ete |
Views: 526
Downloads: 1570
|
Size: 806.84 KB
|
Cisco.testking.350-701.v2020-10-09.by.caleb.61q.ete |
Views: 1087
Downloads: 2135
|
Size: 581.61 KB
|
Student Feedback
Can View Online Video Courses
Please fill out your email address below in order to view Online Courses.
Registration is Free and Easy, You Simply need to provide an email address.
- Trusted By 1.2M IT Certification Candidates Every Month
- Hundreds Hours of Videos
- Instant download After Registration
A confirmation link will be sent to this email address to verify your login.
Please Log In to view Online Course
Registration is free and easy - just provide your E-mail address.
Click Here to Register