├── Course_Notes ├── Ansible_Puppet_Chef.md ├── CDP_and_LLDP.md ├── DHCP.md ├── DHCP_Snooping.md ├── DNS.md ├── DTP_VTP.md ├── DynamicRouting.md ├── Dynamic_Arp_Inspection.md ├── Etherchannel.md ├── Ethernet_LAN_Switching_Part1.md ├── Ethernet_LAN_Switching_Part2.md ├── Extended_Access_Control_Lists.md ├── FTP_and_TFTP.md ├── First_Hop_Redundancy_Protocols.md ├── IPv4_Addressing_Part1.md ├── IPv4_Addressing_Part2.md ├── IPv6_Part1.md ├── IPv6_Part2.md ├── IPv6_Part3.md ├── Interfaces_and_Cables.md ├── Intro_to_CLI.md ├── Introduction_to_Network_Automation.md ├── JSON_XML_YAML.md ├── LAN_Architectures.md ├── Life_of_a_Packet.md ├── NAT_Dynamic_Part2.md ├── NAT_Static_Part1.md ├── NTP.md ├── Network_Devices.md ├── OSI_Model_TCPSuite.md ├── OSPF_Part1.md ├── OSPF_Part2.md ├── OSPF_Part3.md ├── Port_Security.md ├── QoS_Quality_of_Service.md ├── QoS_VoiceLan.md ├── REST_APIs.md ├── RIP_and_EIGRP.md ├── Rapid_Spanning_Tree_Protocol.md ├── Routing_Fundamentals_Part1.md ├── SNMP.md ├── SSH.md ├── SYSLOG.md ├── Security_Fundamentals.md ├── Software_Defined_Networking.md ├── Spanning_Tree_Protocol_Part1.md ├── Spanning_Tree_Protocol_Part2.md ├── Standard_Access_Control_Lists.md ├── Static_Routing_Part2.md ├── Subnetting_Part1.md ├── Subnetting_Part2.md ├── Subnetting_VLSM_Part3.md ├── Switch_Interfaces.md ├── TCP_and_UDP.md ├── The_IPv4_Header.md ├── VLAN_Part1.md ├── VLAN_Part2.md ├── VLAN_Part3.md ├── Virtualization_Containers.md ├── Virtualization_VRF_Part3.md ├── Virtualizations_and_Cloud_Part1.md ├── WAN_Architectures.md ├── Wireless_Architecutres.md ├── Wireless_Configuration.md ├── Wireless_Fundamentals.md └── Wireless_Security.md └── README.md /Course_Notes/Ansible_Puppet_Chef.md: -------------------------------------------------------------------------------- 1 | # 63. ANSIBLE, PUPPET, AND CHEF 2 | 3 | CONFIGURATION DRIFT 4 | 5 | - CONFIGURATION DRIFT is when individual changes made over time causes a device’s configuration to deviate from the standard / correct configurations as defined by the company 6 | - Although each device will have unique parts of its configurations (IP Addresses, hostname, etc) most of a device’s configuration is usually defined in standard templates designed by the network architects / engineers of the company 7 | - As individual engineers make changes to devices (for example, to troubleshoot and fix network issues, test configurations, etc), the configuration of a device can drift away from the standard. 8 | - Records of these individual changes and their reasons aren’t kept 9 | - This can lead to future issues 10 | - Even without automation tools, it is best to have standard configuration management practices. 11 | - When a change is made, save the config as a text file and place it in a shared folder 12 | - A standard naming system like (*hostname_yyyymmdd)* might be used. 13 | - There are flaws to this system, as an engineer might forget to place the new config in the folder after making changes. Which one should be considered the “CORRECT” config? 14 | - Even if configurations are properly saved like this, it doesn’t guarantee that the configurations actually match the standard 15 | --- 16 | 17 | CONFIGURATION PROVISIONING 18 | 19 | - CONFIGURATION PROVISIONING refers to how configuration changes are applied to devices 20 | - This includes configuring new devices, too 21 | - Traditionally, configuration provisioning is done by connecting to devices one-by-one via SSH 22 | - This is not practical in large networks 23 | - Configuration management tools like Ansible, Puppet, and Chef allow us to make changes to devices on a mass scale with a fraction of time and effort. 24 | 25 | - TWO ESSENTIAL COMPONENTS: 26 | - Templates 27 | - Variables 28 | 29 | ![image](https://github.com/psaumur/CCNA/assets/106411237/0c74b2a6-1ce7-4758-b6b8-340594d567c3) 30 | 31 | --- 32 | 33 | INTRO TO CONFIGURATION MANAGEMENT TOOLS 34 | 35 | - CONFIGURATION MANAGEMENT TOOLS are network automation tools that facilitate the centralized control of large numbers of network devices 36 | - The option you need to be aware of for the CCNA are Ansible, Puppet, and Chef 37 | - These tools were originally developed after the rise of VMs, to enable server system admins to automate the process of creating, configuring, and removing VMs 38 | - However, they are also widely used to manage network devices 39 | 40 | - These tools can be used to perform tasks such as : 41 | - Generate configurations for new devices on a large scale 42 | - Perform configuration changes on devices (all devices in your network, or certain subset of devices) 43 | - Check device configurations for compliance with defined standards 44 | - Compare configurations between devices, and between different versions of configurations on the same device 45 | 46 | ![image](https://github.com/psaumur/CCNA/assets/106411237/f9eb7783-5e42-4cfe-aec8-8b57cd316f4d) 47 | 48 | --- 49 | 50 | ANSIBLE 51 | 52 | - ANSIBLE is a configuration management tool owned by Red Hat 53 | - Ansible itself is written in Python 54 | - Ansible is *agentless* 55 | - It doesn’t require any special software to run on the managed devices 56 | - Ansible uses SSH to connect to devices, make configuration changes, extract info, etc 57 | - Ansible uses a *push* model. The Ansible server (Control node) uses SSH to connect to managed devices and *push* configuration changes to them 58 | - Puppet and Chef use a *pull* model 59 | 60 | - After installing Ansible itself, you must create several text files: 61 | - PLAYBOOKS : 62 | - These files are “blueprints of automation tasks” 63 | - They outline the logic and actions of the tasks that Ansible should do 64 | - Written in YAML 65 | - INVENTORY : 66 | - These files list the devices that will be managed by Ansible, as well as characteristics of each device such as their device role (Access Switch, Core Switch, WAN Router, Firewall, etc.) 67 | - Written in INI, YAML, or other formats 68 | - TEMPLATES : 69 | - These files represent a device’s configuration file, but specific values for variables are not provided. 70 | - Written in JINJA2 format 71 | - VARIABLES : 72 | - These files list variables and their values. 73 | - These values are substituted into the templates to create complete configuration files. 74 | - Written in YAML 75 | 76 | ![image](https://github.com/psaumur/CCNA/assets/106411237/ba2a68b5-7661-4eff-bd5f-8c32bde354da) 77 | 78 | --- 79 | 80 | PUPPET 81 | 82 | - PUPPET is a configuration management tool written in RUBY 83 | - Puppet is typically agent-based 84 | - Specific software must be installed on the managed devices 85 | - Not all Cisco devices support a Puppet agent 86 | 87 | - It CAN be run *agentless,* in which a proxy agent runs on an external host, and a proxy agent uses SSH to connect to the managed devices and communicate with them 88 | - The Puppet server is called the “Puppet master” 89 | - Puppet uses a PULL model (clients “pull” configurations from the Puppet master) 90 | - Clients use TCP 8140 to communicate with the Puppet master 91 | - Instead of YAML, it uses a proprietary language for files 92 | - Text files required on the Puppet master include: 93 | - MANIFEST : 94 | - The file defines the desired configuration state of a network device 95 | - TEMPLATES : 96 | - Similar to Ansible templates. 97 | - Used to generate MANIFESTS 98 | 99 | ![image](https://github.com/psaumur/CCNA/assets/106411237/ec26ad33-7534-4f15-93f0-4557337bfaec) 100 | 101 | --- 102 | 103 | CHEF 104 | 105 | - CHEF is a configuration management tool written in RUBY 106 | - CHEF is Agent-Based 107 | - Specific software must be installed on the managed devices 108 | - Not all Cisco devices support a CHEF agent 109 | - CHEF uses a PULL model 110 | - The server uses TCP 10002 to send configurations to clients 111 | - Files use a DSL (Domain-Specific Language) based on Ruby 112 | - Text files used by CHEF include: 113 | - RESOURCES : 114 | - The “ingredients” in a RECIPE. 115 | - Configuration objects managed by CHEF 116 | - RECIPES : 117 | - The “recipes” in a COOKBOOK. 118 | - Outlines the logic and actions of the tasks performed on the resources 119 | - COOKBOOKS : 120 | - A set of related RECIPES grouped together 121 | - RUN-LIST : 122 | - An ordered list of RECIPES that are run to bring a device to the desired configuration state 123 | 124 | ![image](https://github.com/psaumur/CCNA/assets/106411237/eaf5be1b-3635-4806-bb7a-f397ffa1b411) 125 | 126 | --- 127 | 128 | MEMORIZE THIS CHART FOR THE CCNA 129 | 130 | ![image](https://github.com/psaumur/CCNA/assets/106411237/a4d212e6-df46-45d1-a2ca-3e55220c4b5c) 131 | -------------------------------------------------------------------------------- /Course_Notes/CDP_and_LLDP.md: -------------------------------------------------------------------------------- 1 | # 36. CDP and LLDP (Layer 2 Discovery Protocol) 2 | 3 | INTRO TO LAYER 2 DISCOVERY PROTOCOLS 4 | 5 | - LAYER 2 DISCOVERY PROTOCOL, such as CDP and LLDP share information WITH and DISCOVER information about NEIGHBORING (Connected) DEVICES 6 | 7 | - The SHARED INFORMATION includes: 8 | - Hostname 9 | - IP Address 10 | - Device Type 11 | - etcetera. 12 | 13 | - **CDP** is a Cisco Proprietary Protocol 14 | - **LLDP** is an Industry Standard Protocol (IEEE 802.1AB) 15 | 16 | - Because they SHARE INFORMATION about the DEVICES in the NETWORK, they can be considered a security risk and are often NOT used. It is up to the NETWORK ENGINEER / ADMIN to decide if they want to use them in the NETWORK or not. 17 | 18 | ![image](https://github.com/psaumur/CCNA/assets/106411237/65f39e9f-ae1a-42c6-8afb-5e79f939fe5d) 19 | 20 | --- 21 | 22 | CISCO DISCOVERY PROTOCOL (CDP) 23 | 24 | - CDP is a Cisco proprietary protocol 25 | - It is enabled on Cisco devices (routers, switches, firewalls, IP Phones, etc) by DEFAULT 26 | 27 | 31 | 32 | 33 | - When a DEVICE receives a CDP message, it PROCESSES and DISCARDS the message. It does NOT forward it to other devices. 34 | - By DEFAULT, CDP Messages are sent once every **60 seconds** 35 | - By DEFAULT, the CDP hold-time is **180 seconds.** If a message isn’t received from a neighbor for 180 seconds, the neighbor is REMOVED from the CDP Neighbor Table 36 | - CDPv2 messages are sent by DEFAULT 37 | 38 | ![image](https://github.com/psaumur/CCNA/assets/106411237/8a0552be-dbc7-4c7b-b011-e32dff75a57e) 39 | 40 | ![image](https://github.com/psaumur/CCNA/assets/106411237/26e180ec-da08-44d2-bb55-325fdc0c234f) 41 | 42 | --- 43 | 44 | CDP NEIGHBOR TABLES 45 | 46 | ![image](https://github.com/psaumur/CCNA/assets/106411237/00cd814e-0255-4fac-ac71-3e50054f813c) 47 | 48 | “Device ID” = What devices were DISCOVERED by CDP 49 | 50 | “Local Intrface” = What LOCAL device interface the neighbors are connected to 51 | 52 | “Holdtime” = Hold-time countdown in seconds (0 = device removed from table) 53 | 54 | “Capabilities” = Refers to Capability Codes table (located above output) 55 | 56 | “Platform” = Displays the MODEL of the Neighbor Device 57 | 58 | “Port ID” = Neighbor ports that LOCAL device is connected to 59 | 60 | --- 61 | 62 | MORE DETAILED OUTPUT 63 | 64 | ![image](https://github.com/psaumur/CCNA/assets/106411237/cd4fbedb-c12f-4e1e-8582-8db16985121f) 65 | 66 | “Version” = shows what version of Cisco’s IOS is running on the device 67 | 68 | --- 69 | 70 | SHOW SPECIFIC CDP NEIGHBOR ENTRY 71 | 72 | ![image](https://github.com/psaumur/CCNA/assets/106411237/83ef9488-e82c-4453-ae6e-02575039d0f9) 73 | 74 | --- 75 | 76 | CDP CONFIGURATION COMMANDS 77 | 78 | ![image](https://github.com/psaumur/CCNA/assets/106411237/393b2680-2304-4c8e-9180-88cc5fefbfd8) 79 | 80 | - CDP is GLOBALLY ENABLED, by DEFAULT 81 | - CDP is also ENABLED on each INTERFACE, by DEFAULT 82 | - To ENABLE / DISABLE CDP globally: `R1(config)# [no] cdp run` 83 | - To ENABLE / DISABLE CDP on specific interfaces : `R1(config-if)# [no] cdp enable` 84 | - Configure the CDP timer: `R1(config)# cdp time *seconds*` 85 | - Configure the CDP holdtime: `R1(config)# cdp holdtime *seconds*` 86 | - ENABLE / DISABLE CDPv2: `R1(config)# [no] cdp advertise-v2` 87 | 88 | 89 | 90 | --- 91 | 92 | LINK LAYER DISCOVERY PROTOCOL (LLDP) 93 | 94 | - LLDP is an INDUSTRY STANDARD PROTOCOL (IEEE 802.1AB) 95 | - It is usually DISABLED on Cisco devices, by DEFAULT, so it must be manually ENABLED 96 | - A device can run CDP and LLDP at the same time 97 | 98 | 102 | 103 | - When a DEVICE receives an LLDP message, it PROCESSES and DISCARDS the message. It does NOT forward it to OTHER DEVICES 104 | - By DEFAULT, LLDP Messages are sent once every **30 seconds** 105 | - By DEFAULT, LLDP Holdtime is **120 seconds** 106 | - LLDP has an additional timer called the ‘reinitialization delay’ 107 | - If LLDP is ENABLED (Globally or on an INTERFACE), this TIMER will DELAY the actual initialization of LLDP (**2 seconds,** by DEFAULT) 108 | 109 | --- 110 | 111 | LLDP CONFIGURATION COMMANDS 112 | 113 | - LLDP is usually GLOBALLY DISABLED by DEFAULT 114 | - LLDP is also DISABLED on each INTERFACE, by DEFAULT 115 | 116 | - To ENABLE LLDP GLOBALLY : `R1(config)# lldp run` 117 | 118 | - To ENABLE LLDP on specific INTERFACES (tx): `R1(config-if)# lldp transmit` 119 | - To ENABLE LLDP on specific INTERFACES (rx): `R1(config-if)# lldp receive` 120 | 121 | YOU NEED TO ENABLE BOTH TO SEND AND RECEIVE (Unless you want to only enable SEND or RECEIVE LLDP Messages) 122 | 123 | 124 | 125 | - Configure the LLDP timer: `R1(config)# lldp timer *seconds*` 126 | - Configure the LLDP holdtime: `R1(config)# lldp holdtime *seconds*` 127 | - Configure the LLDP reinit timer: `R1(config)# lldp reinit *seconds*` 128 | 129 | ![image](https://github.com/psaumur/CCNA/assets/106411237/25afc5ad-4d82-4472-b282-31ed2a65eae7) 130 | 131 | ![image](https://github.com/psaumur/CCNA/assets/106411237/78fab926-9fda-4c83-91eb-eda4bf4ec005) 132 | 133 | SHOW LLDP STATUS 134 | 135 | ![image](https://github.com/psaumur/CCNA/assets/106411237/32b11d7b-4050-422e-afd4-bec23e8db3a1) 136 | 137 | SHOW ALL LLDP NEIGHBORS 138 | 139 | ![image](https://github.com/psaumur/CCNA/assets/106411237/85a46d24-5574-4400-bc03-6b0568294940) 140 | 141 | SHOW LLDP NEIGHBORS in DETAIL 142 | 143 | ![image](https://github.com/psaumur/CCNA/assets/106411237/26751ca8-ed54-4e5c-9927-8c6eb0e2e3f7) 144 | 145 | SHOW SPECIFIC LLDP DEVICE ENTRY 146 | 147 | ![image](https://github.com/psaumur/CCNA/assets/106411237/b5332838-d112-4556-bee0-c3716a3d4f89) 148 | 149 | ![image](https://github.com/psaumur/CCNA/assets/106411237/2dd16e33-75a9-4e11-91aa-b507ed490e9b) 150 | -------------------------------------------------------------------------------- /Course_Notes/DHCP.md: -------------------------------------------------------------------------------- 1 | # 39. DHCP (Dynamic Host Configuration Protocol) 2 | 3 | THE PURPOSE OF DHCP 4 | 5 | - DHCP is used to allow HOSTS to automatically / dynamically learn various aspects of their NETWORK configuration; without MANUAL / STATIC configuration 6 | - It is an ESSENTIAL part of modern NETWORKS 7 | - When you connect a phone / laptop to WiFi, do you ask your NETWORK admin which IP ADDRESS, SUBNET MASK, DEFAULT GATEWAY, etc the phone / laptop should use ? 8 | - Typically used for CLIENT devices (workstations, phones, etc) 9 | - DEVICES (such as ROUTERS, SERVERS, etc) are usually MANUALLY configured 10 | - In small NETWORKS (such as Home NETWORKS), the ROUTER typically acts as the DHCP SERVER for HOSTS in the LAN 11 | - In LARGE NETWORKS, the DHCP SERVER is usually a Windows / Linux SERVER 12 | 13 | --- 14 | 15 | BASIC FUNCTIONS OF DHCP 16 | 17 | ![image](https://github.com/psaumur/CCNA/assets/106411237/81b1e260-d669-4944-aa7b-5b7e6a505233) 18 | 19 | ![image](https://github.com/psaumur/CCNA/assets/106411237/8e7ff968-f47f-4877-88ec-451a9828905e) 20 | 21 | ![image](https://github.com/psaumur/CCNA/assets/106411237/ca9253f6-3e97-42d8-9293-7b271488be78) 22 | 23 | ![image](https://github.com/psaumur/CCNA/assets/106411237/b4659586-9e8b-482e-a492-fab9f979aa40) 24 | 25 | ![image](https://github.com/psaumur/CCNA/assets/106411237/bd292766-0a22-4c0a-ac96-0262ba03d720) 26 | 27 | Note: ALL the IPs are the same because this is Jeremy’s Home ROUTER (it provides all these services) 28 | 29 | Command `ipconfig /release` 30 | 31 | ![image](https://github.com/psaumur/CCNA/assets/106411237/13c9528b-8ecb-43e3-a3be-9993c03e1fa5) 32 | 33 | ![image](https://github.com/psaumur/CCNA/assets/106411237/46821c80-1fa1-435c-b71f-f2a81a2a415a) 34 | 35 | Wireshark capture of the `ipconfig /release` mechanism 36 | 37 | ![image](https://github.com/psaumur/CCNA/assets/106411237/f9eb66a1-9c7e-4b5c-9393-9005f51ad172) 38 | 39 | ![image](https://github.com/psaumur/CCNA/assets/106411237/16e2b443-6ab6-49c4-bfde-2083c7b2185e) 40 | 41 | --- 42 | 43 | Command `ipconfig /renew` 44 | 45 | ![image](https://github.com/psaumur/CCNA/assets/106411237/de06e7a3-b011-48eb-a5c6-8a6295258fbc) 46 | 47 | Renewing Process has FOUR messages: 48 | 49 | ![image](https://github.com/psaumur/CCNA/assets/106411237/94febcd6-cd2b-4f6d-97db-69e33b1c1c4d) 50 | 51 | 1) DHCP DISCOVER 52 | 53 | - Are there any DHCP Servers in this NETWORK? I need an IP ADDRESS ? 54 | 55 | ![image](https://github.com/psaumur/CCNA/assets/106411237/70f7fc01-3222-4fec-8bd3-8b96cfbc086f) 56 | 57 | NOTE the use of DHCP Reserved Ports 67 and 68 58 | 59 | 2) DHCP OFFER: 60 | 61 | - How about THIS IP ADDRESS ? 62 | 63 | ![image](https://github.com/psaumur/CCNA/assets/106411237/0f6e38bc-5eb0-4538-b0d1-e5795ee3af3a) 64 | 65 | - The DHCP OFFER message can be either BROADCAST or UNICAST 66 | - NOTE OPTIONS at the bottom : Message Type, Server ID, Lease Time, Subnet, etc. 67 | 68 | 3) DHCP REQUEST 69 | 70 | - I want to use the IP ADDRESS that was offered 71 | 72 | ![image](https://github.com/psaumur/CCNA/assets/106411237/3023a977-2477-42ec-8890-283ef326bad1) 73 | 74 | 4) DHCP ACK 75 | 76 | - Okay! You may use THAT ADDRESS 77 | 78 | ![image](https://github.com/psaumur/CCNA/assets/106411237/543c77e8-326b-45c6-a149-2f3668dac3ff) 79 | 80 | --- 81 | DHCP RENEW PROCESS SUMMARY 82 | 83 | ![image](https://github.com/psaumur/CCNA/assets/106411237/a2f5cc4e-c949-4a8d-a985-29c6631c635e) 84 | 85 | --- 86 | 87 | DHCP RELAY 88 | 89 | - Some NETWORK engineers might choose to configure each ROUTER to act as the DHCP SERVER for its connected LANS 90 | - However, large enterprises often choose to use a CENTRALIZED DHCP SERVER 91 | - If the SERVER is centralized, it won’t receive the DHCP CLIENTS’ Broadcast DHCP messages 92 | - To FIX this, you can configure a ROUTER to act as a DHCP RELAY AGENT 93 | - The ROUTER will forward the clients’ Broadcast DHCP messages to the remote DHCP SERVER as a Unicast messages 94 | 95 | ![image](https://github.com/psaumur/CCNA/assets/106411237/3c0b188e-a120-499e-b089-18740d0d4559) 96 | 97 | ![image](https://github.com/psaumur/CCNA/assets/106411237/04c380f4-e1b4-46f3-89ab-1c89f16eed7a) 98 | 99 | --- 100 | 101 | CONFIGURING DHCP IN CISCO IOS 102 | 103 | Commands for configuring DHCP SERVERS in Cisco IOS 104 | 105 | ![image](https://github.com/psaumur/CCNA/assets/106411237/5cac378b-2769-4da2-bd46-1bd93dd5d144) 106 | 107 | Command `show ip dhcp binding` 108 | 109 | ![image](https://github.com/psaumur/CCNA/assets/106411237/2cb89226-c24f-4cac-86f0-5cfb5ba16575) 110 | 111 | ![image](https://github.com/psaumur/CCNA/assets/106411237/4e10257e-2ca8-466f-96fc-f4a02ab319a4) 112 | 113 | --- 114 | 115 | DHCP RELAY AGENT CONFIGURATION IN IOS 116 | 117 | ![image](https://github.com/psaumur/CCNA/assets/106411237/d1e1df72-85ef-4323-87f4-26cf14132bda) 118 | 119 | RELAY AGENT MUST HAVE CONNECTIVITY WITH DHCP SERVER 120 | 121 | --- 122 | 123 | DHCP CLIENT CONFIGURATION IN IOS 124 | 125 | ![image](https://github.com/psaumur/CCNA/assets/106411237/353e553c-b4a5-4f18-818f-3d7a395491b3) 126 | 127 | --- 128 | 129 | COMMANDS SUMMARY 130 | 131 | ![image](https://github.com/psaumur/CCNA/assets/106411237/41e4ab84-7d5d-42e6-93d7-4b982976dd16) 132 | -------------------------------------------------------------------------------- /Course_Notes/DHCP_Snooping.md: -------------------------------------------------------------------------------- 1 | # 50. DHCP SNOOPING (LAYER 2) 2 | 3 | WHAT IS DHCP SNOOPING? 4 | 5 | - DHCP SNOOPING is a security feature of SWITCHES that is used to filter DHCP messages received on UNTRUSTED PORTS 6 | - DHCP SNOOPING only filters DHCP MESSAGES. 7 | - Non-DHCP MESSAGES are not affected 8 | - All PORTS are UNTRUSTED, by DEFAULT 9 | - Usually UPLINK PORTS are configured as TRUSTED PORTS, and DOWNLINK PORTS remain UNTRUSTED 10 | 11 | 12 | ![image](https://github.com/psaumur/CCNA/assets/106411237/9ed71d09-d94c-4fc9-ad87-1b31acfdd132) 13 | 14 | ![image](https://github.com/psaumur/CCNA/assets/106411237/9d7d23a6-9d54-4234-a07e-a5caea136c94) 15 | 16 | --- 17 | 18 | ATTACKS ON DHCP 19 | 20 | DHCP STARVATION 21 | 22 | - An example of a DHCP-based ATTACK is a DHCP STARVATION ATTACK 23 | - An ATTACKER uses spoofed MAC ADDRESSES to flood DHCP DISCOVER messages 24 | - The TARGET server’s DHCP POOL becomes full, resulting in a DoS to other DEVICES 25 | 26 | ![image](https://github.com/psaumur/CCNA/assets/106411237/33dfbb8b-2b78-4700-b4ab-0dd95fc03eed) 27 | 28 | DHCP POISONING (Man-in-the-Middle) 29 | 30 | - Similar to ARP POISONING, DHCP POISONING can be used to perform a Man-in-the-Middle ATTACK 31 | - A *spurious DHCP SERVER* replies to CLIENTS’ DHCP Discover messages and assigns them IP ADDRESSES but makes the CLIENTS use the *spurious SERVER’S IP* as a DEFAULT GATEWAY 32 | 33 | ** CLIENTS usually accept the first DHCP OFFER message they receive 34 | 35 | - This will cause the CLIENT to send TRAFFIC to the ATTACKER instead of the legitimate DEFAULT GATEWAY 36 | - The ATTACKER can then examine / modify the TRAFFIC before forwarding it to the legitimate DEFAULT GATEWAY 37 | 38 | ![image](https://github.com/psaumur/CCNA/assets/106411237/d0cd7a5c-9ff4-4ab7-bec6-4edec4ea2646) 39 | 40 | ![image](https://github.com/psaumur/CCNA/assets/106411237/1573bcb7-6fa8-46d7-8cb8-46e30bac559d) 41 | 42 | --- 43 | 44 | DHCP MESSAGES 45 | 46 | - When DHCP SNOOPING filters messages, it differentiates between DHCP SERVER messages and DHCP CLIENT messages 47 | 48 | - Messages sent by DHCP SERVERS: 49 | - OFFER 50 | - ACK 51 | - NAK = Opposite of ACK - used to DECLINE a CLIENT’S REQUEST 52 | - Messages sent by DHCP CLIENTS: 53 | - DISCOVER 54 | - REQUEST 55 | - RELEASE = Used to tell the SERVER that the CLIENT no longer needs its IP ADDRESS 56 | - DECLINE = Used to DECLINE the IP ADDRESS offered by a DHCP SERVER 57 | 58 | --- 59 | 60 | HOW DOES IT WORK? 61 | 62 | - If a DHCP MESSAGE is received on a TRUSTED PORT, forward it as normal without inspection 63 | - If a DHCP MESSAGE is received on an UNTRUSTED PORT, inspect it and act as follows: 64 | - If it is a DHCP SERVER message, discard it 65 | - If it as a DHCP CLIENT message, perform the following checks: 66 | - DISCOVER / REQUEST messages : 67 | - Check if the FRAME’S SOURCE MAC ADDRESS and the DHCP MESSAGE’S CHADDR FIELDS match. 68 | - MATCH = FORWARD 69 | - MISMATCH = DISCARD 70 | - RELEASE / DECLINE messages: 71 | - Check if the PACKET’S SOURCE IP ADDRESS and the receiving INTERFACE match the entry in the *DHCP SNOOPING BINDING TABLE* 72 | - MATCH = FORWARD 73 | - MISMATCH = DISCARD 74 | 75 | - When a CLIENT successfully leases an IP ADDRESS from a SERVER, create a new entry in the *DHCP SNOOPING BINDING TABLE* 76 | 77 | --- 78 | 79 | DHCP SNOOPING CONFIGURATION 80 | 81 | ![image](https://github.com/psaumur/CCNA/assets/106411237/729466dc-9432-47d2-8799-652fa064b058) 82 | 83 | SWITCH 2’s CONFIGURATION 84 | 85 | ![image](https://github.com/psaumur/CCNA/assets/106411237/8d6cacb8-ffd8-4cf0-bd96-fe9978377989) 86 | 87 | SWITCH 1’s CONFIGURATION 88 | 89 | ![image](https://github.com/psaumur/CCNA/assets/106411237/bb11e4fd-a340-4dd3-a6f5-3cd280fc5a13) 90 | 91 | DHCP SNOOPING RATE-LIMITING 92 | 93 | - DHCP SNOOPING can limit the RATE at which DHCP messages are allowed to enter an INTERFACE 94 | - If the RATE of DHCP messages crosses the configured LIMIT, the INTERFACE is `err-disabled` 95 | - Like with PORT SECURITY, the interface can be manually re-enabled, or automatically re-enabled with `errdisable recovery` 96 | 97 | ![image](https://github.com/psaumur/CCNA/assets/106411237/6586df19-5a58-4ca3-a316-bd0aeb2ce67c) 98 | 99 | - You wouldn’t set the limit rate to 1 since it’s so low, it would shut the port immediately but this shows how RATE-LIMITING works 100 | 101 | `errdisable recovery cause dhcp-rate-limit` 102 | 103 | ![image](https://github.com/psaumur/CCNA/assets/106411237/83c324aa-baa0-4ae1-82ac-157e503e048a) 104 | 105 | DHCP OPTION 82 (INFORMATION OPTION) 106 | 107 | - OPTION 82, also known as a ‘DHCP RELAY AGENT INFOMRATION OPTION’ is one of MANY DHCP OPTIONS 108 | - It provides additional information about which DHCP RELAY AGENT received the CLIENT’S message, on which INTERFACE, in which VLAN, etc. 109 | - DHCP RELAY AGENTS can add OPTION 82 to message they forward to the remote DHCP SERVER 110 | - With DHCP SNOOPING enabled, by default Cisco SWITCHES will add OPTION 82 to DHCP messages they receive from CLIENTS, even if the SWITCH isn’t acting as a DHCP RELAY AGENT 111 | - By DEFAULT, Cisco SWITCHES will drop DHCP MESSAGES with OPTION 82 that are received on an UNTRUSTED PORT 112 | 113 | ![image](https://github.com/psaumur/CCNA/assets/106411237/2efc6edd-21fd-4c1a-bb11-9c1f761e1d32) 114 | 115 | THIS command disables OPTION 82 for SW1 but NOT SW2 116 | 117 | ![image](https://github.com/psaumur/CCNA/assets/106411237/84f1c3f2-9ad1-4367-97f3-95dab053b30c) 118 | 119 | TRAFFIC gets passed to R1 and is DROPPED because of “inconsistent relay information” (packet contains OPTION 82 but wasn’t dropped by SW2) 120 | 121 | ![image](https://github.com/psaumur/CCNA/assets/106411237/5c4b547e-c588-4d62-8098-76902199a131) 122 | 123 | By ENABLING OPTION 82 on both SWITCHES… 124 | 125 | ![image](https://github.com/psaumur/CCNA/assets/106411237/dda50cf6-ae86-47ec-9b4f-104669697f64) 126 | 127 | PC1’s DHCP DISCOVER message gets passed, through SW1 and SW2, to R1. 128 | R1 responds with an DHCP OFFER message, as normal 129 | 130 | ![image](https://github.com/psaumur/CCNA/assets/106411237/7e59cc5a-bf8e-482d-848d-5bfa0540c74b) 131 | 132 | --- 133 | 134 | COMMAND SUMMARY 135 | 136 | ![image](https://github.com/psaumur/CCNA/assets/106411237/308e32fa-52bd-4ee4-9356-f14e65416e17) 137 | -------------------------------------------------------------------------------- /Course_Notes/DNS.md: -------------------------------------------------------------------------------- 1 | # 38. DNS (Domain Name System) 2 | 3 | THE PURPOSE OF DNS 4 | 5 | - DNS is used to *resolve* human-readable names (google.com) to IP ADDRESSES 6 | - Machines such as PCs don’t use names, they use ADDRESSES (ie: IPv4/IPv6) 7 | - Names are much easier for us to use and remember than IP ADDRESSES 8 | - What is the IP ADDRESS of [youtube.com](http://youtube.com) ? 9 | - When you type ‘youtube.com` into a web browser, your device will ask a DNS SERVER for the IP ADDRESS of [youtube.com](http://youtube.com) 10 | - The DNS SERVER(S) your DEVICE uses can be manually configured or learned via DHCP 11 | 12 | --- 13 | 14 | BASIC FUNCTIONS OF DNS 15 | 16 | ![image](https://github.com/psaumur/CCNA/assets/106411237/059c6fa4-674c-47ce-a08e-0714b21cb39e) 17 | 18 | Command `ipconfig /all` (Show local IP configuration on current DEVICE) 19 | 20 | ![image](https://github.com/psaumur/CCNA/assets/106411237/b43b1d98-b510-4d05-be96-f706a3d090d1) 21 | 22 | ![image](https://github.com/psaumur/CCNA/assets/106411237/7f56b6f1-12c6-4096-9f73-28c9f8cfd570) 23 | 24 | Command `nslookup` (Shows IP information for a given DNS entry) 25 | 26 | ![image](https://github.com/psaumur/CCNA/assets/106411237/71e5cd97-528c-435f-86d3-29d6ad2808b6) 27 | 28 | WIRESHARK CAPTURE of above COMMANDS 29 | 30 | ![image](https://github.com/psaumur/CCNA/assets/106411237/9d9cd65c-8a8b-45b3-8914-28a53013618f) 31 | 32 | ![image](https://github.com/psaumur/CCNA/assets/106411237/469431b3-e981-47cf-994d-642f737e79a0) 33 | 34 | Command `ipconfig /displaydns` (Displays DNS cache) 35 | 36 | ![image](https://github.com/psaumur/CCNA/assets/106411237/da36bc07-d834-4c5e-b7ab-71da025b912f) 37 | 38 | Command `ipconfig /flushdns` (Clears DNS cache) 39 | 40 | ![image](https://github.com/psaumur/CCNA/assets/106411237/f8608c2f-840c-477d-9284-7060838f1f3e) 41 | 42 | HOSTS Files 43 | 44 | WINDOWS HOSTS location 45 | 46 | ![image](https://github.com/psaumur/CCNA/assets/106411237/771b6bd4-abe4-41b7-afc2-3984ccc23407) 47 | 48 | ![image](https://github.com/psaumur/CCNA/assets/106411237/ff56876a-3b80-482f-b73b-caa86e5d972f) 49 | 50 | --- 51 | 52 | CONFIGURING DNS IN CISCO IOS 53 | 54 | - For HOSTS in a NETWORK to use DNS, you don’t need to configure DNS on the ROUTERS. 55 | - They will simply FORWARD the DNS messages like any other packets 56 | - However, a CISCO ROUTER can be configured as a DNS SERVER, although it’s rare 57 | - If an INTERNAL DNS SERVER is used, usually it’s a WINDOWS or LINUX SERVER 58 | - A CISCO ROUTER can also be configured as a DNS CLIENT 59 | 60 | Command `ip dns server` and `ip host ` 61 | 62 | ![image](https://github.com/psaumur/CCNA/assets/106411237/f65a4118-ae59-4db5-8fc4-c83d39c3072d) 63 | 64 | ![image](https://github.com/psaumur/CCNA/assets/106411237/59743697-6347-41de-9359-ca7ef327af01) 65 | 66 | ![image](https://github.com/psaumur/CCNA/assets/106411237/8e9c34c4-1a53-4ce4-a268-8a6d801d45e9) 67 | 68 | Command `show hosts` 69 | 70 | ![image](https://github.com/psaumur/CCNA/assets/106411237/306aa507-1523-43e5-ac48-251e8a75b5f8) 71 | 72 | Command `ip name-server` and `ip domain lookup` 73 | 74 | ![image](https://github.com/psaumur/CCNA/assets/106411237/cf0deb90-f8be-4f11-9373-2b7ef4715baf) 75 | 76 | --- 77 | 78 | COMMAND REVIEW: 79 | 80 | ![image](https://github.com/psaumur/CCNA/assets/106411237/6c3e7873-04c4-407e-a851-cb74a9f78eb9) 81 | -------------------------------------------------------------------------------- /Course_Notes/DTP_VTP.md: -------------------------------------------------------------------------------- 1 | # 19. DTP / VTP (Not in Syllabus) 2 | 3 | DTP (Dynamic Trunking Protocol) 4 | 5 | - Protocol that allows SWITCHES to negotiate the status of their SWITCHPORTS, without manual configuration, to be: 6 | - ACCESS PORTS 7 | - TRUNK PORTS 8 | 9 | - DTP is ENABLED by default on all Cisco SWITCH interfaces 10 | 11 | We’ve been manually configuring SWITCHPORTS using : 12 | 13 | - “switchport mode access” 14 | - “switchport mode trunk” 15 | 16 | ``` 17 | 💡 'show interfaces switchport' will show you a switchport’s settings. 18 | ``` 19 | For security purposes, **manual configuration** is recommended. DTP should be disabled on ALL SWITCHPORTS 20 | 21 | ![image](https://github.com/psaumur/CCNA/assets/106411237/bf716a33-8e11-4c09-bb0b-336ba48ef26d) 22 | 23 | 24 | DYNAMIC DESIRABLE: 25 | 26 | - This MODE will actively try to form a TRUNK with other Cisco SWITCHES. 27 | - Will form a TRUNK if connected to another SWITCHPORT in the following modes: 28 | - “switchport mode trunk” 29 | - “switchport mode dynamic desirable” 30 | - “switchport mode dynamic auto” 31 | 32 | 33 | HOWEVER … if the other interface is set to “static access” (ACCESS mode), it will NOT form a TRUNK, it will be an ACCESS PORT 34 | 35 | DYNAMIC AUTO: 36 | 37 | - This MODE will NOT actively try to form a TRUNK with other Cisco SWITCHES 38 | - Will form a TRUNK if connected SWTICH is actively trying to form a TRUNK. 39 | - It will form a TRUNK with a SWITCHPORT in the following modes: 40 | - “switchport mode trunk” 41 | - “switchport mode dynamic desirable” 42 | 43 | TRUNK to ACCESS connection will operate in a **Mismatched Mode**. 44 | 45 | This configuration does NOT work and SHOULD result in an error. Traffic will NOT work. 46 | 47 | TABLE SHOWING THE DIFFERENT MODES AND COMPATIBILITY IN FORMING A TRUNK 48 | 49 | ![image](https://github.com/psaumur/CCNA/assets/106411237/93d5e4f4-cb24-4d3f-ba62-fd002581cfbb) 50 | 51 | --- 52 | 53 | DTP will NOT form a TRUNK with: 54 | 55 | a ROUTER 56 | 57 | a PC 58 | 59 | etcetera … 60 | 61 | The SWITCHPORT will be in ACCESS Mode only! 62 | 63 | OLD SWITCHES: 64 | 65 | - “switchport mode dynamic desirable” = Default administrative mode. 66 | 67 | NEWER SWITCHES: 68 | 69 | - “switchport mode dynamic auto” = Default administrative mode. 70 | 71 | HOW TO DISABLE DTP NEGOTIATION ON AN INTERFACE: 72 | 73 | - “switchport nonegotiate” 74 | - “switchport mode access” 75 | 76 | It is a security recommendation to disable DTP on all SWITCHPORTS and manually configure them as ACCESS or TRUNK ports. 77 | 78 | --- 79 | 80 | ENCAPSULATION: 81 | 82 | SWITCHES that support both: 83 | 84 | - 802.1Q 85 | - ISL 86 | 87 | TRUNK encapsulation can use DTP to negotiate the encapsulation they will use. 88 | 89 | - Negotiation is Enabled by default 90 | 91 | ``` 92 | 💡 'switchport trunk encapsulation negotiate' 93 | ``` 94 | 95 | - ISL is favored over 802.1Q 96 | - If BOTH SWITCHES support ISL, ISL will be selected. 97 | - DTP frames are sent in: 98 | - VLAN1 when using ISL 99 | - Native VLAN when using 802.1Q (the default native VLAN is VLAN1, however) 100 | 101 | --- 102 | 103 | VTP (VLAN Trunking Protocol) 104 | 105 | In Privileged EXEC mode: 106 | 107 | ``` 108 | 💡 #show vtp status 109 | ``` 110 | 111 | - Protocol for configuring VLANs on a Central SWITCH 112 | - A SERVER that other SWITCHES synch. to (auto configuring by connection) 113 | - Other switches (VTP CLIENTS) will synchronize their VLAN database to the SERVER 114 | - Designed for large networks with many VLANs (reduces manual configuration) 115 | - RARELY used. Recommended you DO NOT USE it 116 | - There are THREE VTP Versions : 117 | 118 | - v1 119 | - Does NOT supports Extended VLAN Range 1006-4094 120 | - v2 121 | - Does NOT supports Extended VLAN Range 1006-4094 122 | - Supports Token Ring VLANs ; otherwise similar to V1 123 | - v3 124 | - Supports Extended VLAN Range 1006-4094 125 | - CLIENTS store VLAN dBase in NVRAM 126 | 127 | - There are **THREE VTP modes**: 128 | - SERVER 129 | - CLIENT 130 | - TRANSPARENT 131 | 132 | - Cisco SWITCHES operate in VTP SERVER mode, by default 133 | 134 | --- 135 | 136 | ![image](https://github.com/psaumur/CCNA/assets/106411237/87dcd7ff-f3d3-4441-841c-a0506c249f03) 137 | 138 | --- 139 | 140 | VTP SERVERS: 141 | 142 | - Can ADD / MODIFY / DELETE VLANs 143 | - Store the VLAN dBase in NVRAM 144 | - Increase Revision Number every time VLAN is Added / Modified / Deleted 145 | - Advertises **Latest Version** of VLAN dBase on TRUNK interfaces. 146 | - VTP CLIENTS synchronize their VLAN dBase to it 147 | - **VTP SERVERS also function as VTP CLIENTS** 148 | - **THEREFORE, a VTP SERVER will synchronize to another VTP SERVER with a higher Revision Number** 149 | 150 | 155 | 156 | 157 | VTP CLIENTS: 158 | 159 | ``` 160 | 💡 (config)# vtp mode client 161 | ``` 162 | 163 | - Cannot Add / Modify / Delete VLANs 164 | - Does NOT store the VLAN database in NVRAM 165 | - **VTP v3 CLIENTS DO** 166 | - Will synchronize their VLAN dBase to the SERVER with the highest version number in their VTP Domain 167 | - Advertise their VLAN dBase and forward VTP Advertisements to other CLIENTS over TRUNK Ports 168 | 169 | VTP TRANSPARENT MODE: 170 | 171 | ``` 172 | 💡 (config)# vtp mode transparent 173 | ``` 174 | 175 | - Does NOT participate in VTP Domain (does NOT sync VLAN database) 176 | - Maintains own VLAN dBase in NVRAM. 177 | - Can Add / Modify / Delete VLANs 178 | - Won’t Advertise to other SWITCHES 179 | - Will forward VTP advertisements to SWITCHES in the same Domain as it. 180 | 181 | --- 182 | 183 | VTP DOMAINS 184 | 185 | If a SWITCH with no VTP Domain (Domain NULL) receives a VTP advertisement with a VTP Domain name, it will automatically join that VTP Domain 186 | 187 | If a SWITCH receives a VTP advertisement in the same VTP domain with a higher revision number, it will update it’s VLAN database to match 188 | 189 | --- 190 | 191 | REVISION NUMBERS: 192 | 193 | There are TWO ways to RESET a REVISION NUMBER to 0: 194 | 195 | - Change VTP Domain to an unused Domain 196 | - Change VTP mode to TRANSPARENT 197 | 198 | --- 199 | 200 | VTP VERSION NUMBER 201 | 202 | ``` 203 | 💡 (config)#vtp version 204 | ``` 205 | 206 | Changing the Version # will force sync/update all connected SWITCHES to the latest Version # 207 | -------------------------------------------------------------------------------- /Course_Notes/Dynamic_Arp_Inspection.md: -------------------------------------------------------------------------------- 1 | # 51. DYNAMIC ARP INSPECTION 2 | 3 | WHAT IS DYNAMIC ARP INSPECTION (DAI) ? 4 | 5 | ARP REVIEW 6 | 7 | - ARP is used to learn the MAC ADDRESS of another DEVICE with a known IP ADDRESS 8 | - For example, a PC will use ARP to learn the MAC ADDRESS of its DEFAULT GATEWAY to communicate with external NETWORKS 9 | - Typically, it is a TWO MESSAGE EXCHANGE : ARP REQUEST and ARP REPLY 10 | 11 | GRATUITOUS ARP 12 | 13 | - A GRATUITOUS ARP MESSAGE is an ARP REPLY that is sent without receiving an ARP REQUEST 14 | - It is SENT to the BROADCAST MAC ADDRESS 15 | - It allows other DEVICES to learn the MAC ADDRESS of the sending DEVICE without having to send ARP REQUESTS. 16 | - Some DEVICES automatically send GARP MESSAGES when an INTERFACE is enabled, IP ADDRESS is changed, MAC address is changed, etc. 17 | 18 | DYNAMIC ARP INSPECTION 19 | 20 | - DAI is a SECURITY FEATURE of SWITCHES that is used to filter ARP MESSAGES received on *UNTRUSTED PORTS* 21 | - DAI only filters ARP MESSAGES. Non-ARP MESSAGES are NOT affected 22 | - All PORTS are *UNTRUSTED*, by DEFAULT 23 | - Typically, all PORTS connected to other NETWORK DEVICES (SWITCHES, ROUTERS) should be configured as TRUSTED, while INTERFACES connected to END HOSTS should remain UNTRUSTED 24 | 25 | ![image](https://github.com/psaumur/CCNA/assets/106411237/02da32ef-654c-4755-abcd-ea8230df4029) 26 | 27 | ![image](https://github.com/psaumur/CCNA/assets/106411237/29744383-746e-47be-8220-ba1a641a7a11) 28 | 29 | ![image](https://github.com/psaumur/CCNA/assets/106411237/6848c2b5-e866-4023-9ad9-c18f63aa6bb5) 30 | 31 | --- 32 | 33 | ARP POISONING (MAN IN THE MIDDLE) 34 | 35 | - Similar to DHCP POISONING, ARP POISONING involved an ATTACKER manipulating TARGET’S ARP TABLES so TRAFFIC is sent to the ATTACKER 36 | - To do this, the ATTACKER can send GRATUITOUS ARP MESSAGES using another DEVICE’S IP ADDRESS 37 | - Other DEVICES in the NETWORK will receive the GARP and update their ARP TABLES, causing them to send TRAFFIC to the ATTACKER instead of the legitimate DESTINATION 38 | 39 | ![image](https://github.com/psaumur/CCNA/assets/106411237/aae80c8f-2673-4c04-a206-9b646f5c1f08) 40 | 41 | DYNAMIC ARP INSPECTION OPERATIONS 42 | 43 | - DAI inspects the SENDER MAC and SENDER IP fields of ARP MESSAGES received on UNTRUSTED PORTS and checks that there is a matching entry in the DHCP SNOOPING BINDING TABLE 44 | - If there is a MATCH, the ARP MESSAGE is FORWARDED 45 | - If there is NO MATCH, the ARP MESSAGE is DISCARDED 46 | 47 | ![image](https://github.com/psaumur/CCNA/assets/106411237/060f3d3a-b2fd-46a1-8b3c-7a6839985c87) 48 | 49 | - DAI doesn’t inspect messages received on TRUSTED PORTS. They are FORWARDED as normal. 50 | 51 | - ARP ACLs can be manually configured to map IP ADDRESSES / MAC ADDRESSES for DAI to check 52 | - Useful for HOSTS that don’t use DHCP 53 | 54 | - DAI can be configured to perform more in-depth checks also - but these are optional 55 | 56 | - Like DHCP SNOOPING, DAI also supports RATE-LIMITING to prevent ATTACKERS from overwhelming the SWITCH with ARP MESSAGES 57 | - DHCP SNOOPING and DAI both require work from the SWITCH’S CPU 58 | - Even if the ATTACKER’S messages are BLOCKED, they can OVERLOAD the SWITCH CPU with ARP MESSAGES 59 | 60 | --- 61 | 62 | DYNAMIC ARP INSPECTION CONFIGURATION 63 | 64 | ![image](https://github.com/psaumur/CCNA/assets/106411237/4a91bd7b-626a-4d64-b69a-308d65bbdda4) 65 | 66 | ![image](https://github.com/psaumur/CCNA/assets/106411237/774765fa-4918-4cd9-bb64-57130968c359) 67 | 68 | Command : `show ip arp inspection interfaces` 69 | 70 | ![image](https://github.com/psaumur/CCNA/assets/106411237/e64a568e-e5c6-442b-98f7-4fe829ff7519) 71 | 72 | DAI RATE LIMITING 73 | 74 | ![image](https://github.com/psaumur/CCNA/assets/106411237/6400e059-2c8c-4369-827d-7774fddd57eb) 75 | 76 | DAI OPTIONAL CHECKS 77 | 78 | ![image](https://github.com/psaumur/CCNA/assets/106411237/0e6b780a-16ef-466a-bfd3-8dd2cdace4ad) 79 | 80 | ![image](https://github.com/psaumur/CCNA/assets/106411237/1f109b81-9c9b-4acd-9557-0b652ba29b8d) 81 | 82 | ![image](https://github.com/psaumur/CCNA/assets/106411237/dd78740a-4f41-43aa-8ed2-3fa574acc0f9) 83 | 84 | ARP ACLs (Beyond Scope of CCNA) 85 | 86 | CREATE AN ARP ACL FOR SRV1 87 | 88 | ![image](https://github.com/psaumur/CCNA/assets/106411237/cf121a75-45b2-4e2d-a35f-320e3f5491fa) 89 | 90 | AFTER APPLYING IT TO SWITCH 2, SRV1 is able to send ARP REQUEST to R1 91 | 92 | ![image](https://github.com/psaumur/CCNA/assets/106411237/582feed0-1915-4f59-b3b9-9db37854c6e1) 93 | 94 | Command: `show ip arp inspection` 95 | 96 | Shows a summary of the DAI configuration and statistics 97 | 98 | ![image](https://github.com/psaumur/CCNA/assets/106411237/684e694a-5b0a-4f85-b135-b288a8c4c6ec) 99 | 100 | --- 101 | 102 | COMMAND REVIEW 103 | 104 | ![image](https://github.com/psaumur/CCNA/assets/106411237/4cb7dc28-b09d-4a98-8d43-aca2cdf6180b) 105 | -------------------------------------------------------------------------------- /Course_Notes/Ethernet_LAN_Switching_Part1.md: -------------------------------------------------------------------------------- 1 | # 5. ETHERNET LAN SWITCHING : PART 1 2 | 3 | ![image](https://github.com/psaumur/CCNA/assets/106411237/a40e81d9-c008-4fb4-8580-2eaf63003e63) 4 | 5 | ![image](https://github.com/psaumur/CCNA/assets/106411237/2db46525-98b8-4211-aeb3-efc34bd84222) 6 | 7 | 8 | LAN's 9 | 10 | - A LAN is a network contained in a relatively small area. 11 | - Routers are used to connect separate LAN's 12 | 13 | ![image](https://github.com/psaumur/CCNA/assets/106411237/2a4de9d4-3408-49b9-9492-42b7eb56fe27) 14 | 15 | 16 | An ETHERNET FRAME looks like: 17 | 18 | ![image](https://github.com/psaumur/CCNA/assets/106411237/ad579917-f9a0-4cd8-be25-351ecbfc87af) 19 | 20 | 21 | Ethernet Trailer --- PACKET --- Ethernet Header 22 | 23 | The Ethernet Header contains 5 Fields: 24 | 25 | Preamble -- SFD -- Destination -- Source -- Type 26 | 7 bytes -- 1 byte -- 6 bytes -- 6 bytes -- 2 bytes 27 | 28 | --- 29 | 30 | PREAMBLE: 31 | 32 | - Length: 7 bytes (56 bits) 33 | - Alternating 1's and 0's 34 | - 10101010 * 7x 35 | - Allows devices to synchronize their receiver clocks 36 | 37 | SFD : ‘Start Frame Delimiter’ 38 | 39 | - Length: 1 byte(8 bits) 40 | - 10101011 41 | - Marks end of the PREAMBLE and beginning of rest of frame. 42 | 43 | --- 44 | 45 | DESTINATION AND SOURCE 46 | 47 | - Layer 2 Address 48 | - Indicates the devices sending / receiving the frame 49 | - MAC = ’Media Access Control’ 50 | - = 6 byte (48-bit) address of the physical device 51 | 52 | --- 53 | 54 | TYPE / LENGTH 55 | 56 | - 2 bytes (16-bit) field 57 | - A value of 1**500 or less** in this field indicates the LENGTH of the encapsulated packet (in bytes) 58 | - A value of **1536 or greater** in this field indicates the TYPE of the encapsulated packet and length is determined via other methods. 59 | - IPv4 = 0x0800 (hexadecimal) = 2048 in decimal 60 | - IPv6 = 0x86DD (hexadecimal) = 34525 in decimal 61 | - Layer 3 protocol used in the encapsulated Packet, which is almost always Internet Protocol (IP) version 4 or version 6. 62 | 63 | --- 64 | 65 | The ETHERNET TRAILER contains: 66 | 67 | FCS 68 | 69 | - ‘FRAME CHECK SEQUENCE’ 70 | - 4 bytes (32 bits) in length 71 | - Detects corrupted data by running a 'CRC' algorithm over the received data 72 | - CRC = "Cyclic Redundancy Check" 73 | 74 | --- 75 | 76 | Altogether the ETHERNET FRAME = 26 bytes (header + trailer) 77 | 78 | ![image](https://github.com/psaumur/CCNA/assets/106411237/c8c1a143-0675-4aa4-83bc-6031d10cc0b8) 79 | 80 | 81 | --- 82 | 83 | MAC ADDRESS (48 bits long) 84 | 85 | - 6-bytes (48-bits) physical address assigned to the device when it is made. 86 | - AKA 'Burned-In Address' (BIA) 87 | - Is globally unique 88 | - First 3 bytes are the OUI (Organizationally Unique Identifier) which is assigned to the company making the device 89 | - The last 3 bytes are unique to the device itself 90 | - Written as 12 hexadecimal characters 91 | 92 | Example: 93 | 94 | E8:BA:70 // 11:28:74 95 | OUI // Unique Device ID 96 | 97 | HEXADECIMAL 98 | 99 | ![image](https://github.com/psaumur/CCNA/assets/106411237/65a5e84a-b8db-46f5-b288-518139e99453) 100 | 101 | 102 | INTERFACE NAMES 103 | 104 | F0/1, F0/2, F0/3... F stands for "Fast Ethernet" or 100 Mbps interfaces. 105 | 106 | --- 107 | 108 | MAC ADDRESS TABLE 109 | 110 | Each Switch stores a DYNAMICALLY LEARNED MAC ADDRESS TABLE, using the SOURCE MAC ADDRESS of frames it receives. 111 | 112 | ![image](https://github.com/psaumur/CCNA/assets/106411237/582421a9-6351-48b7-bfe1-c2153520920c) 113 | 114 | 115 | When a Switch doesn't know the DESTINATION MAC ADDRESS of a frame (UNKNOWN UNICAST FRAME), it is forced to FLOOD the frame - Forward the frame out of ALL it's interfaces, except the one it received the packet from. 116 | 117 | When a KNOWN Unicast Frame is known (MAC Address is recognized by the entry in the MAC ADDRESS TABLE), the frame is FORWARDED like normal. 118 | 119 | ![image](https://github.com/psaumur/CCNA/assets/106411237/ff731ab3-fad2-4e10-9fa7-ce583a6a0bb2) 120 | 121 | - Note: Dynamic MAC Addresses are removed from the MAC ADDRESS TABLE every 5 minutes of inactivity. 122 | -------------------------------------------------------------------------------- /Course_Notes/Ethernet_LAN_Switching_Part2.md: -------------------------------------------------------------------------------- 1 | # 6. ETHERNET LAN SWITCHING : PART 2 2 | 3 | An ETHERNET FRAME looks like: 4 | 5 | Ethernet Header --- DATA (Packet) --- Ethernet Trailer 6 | 7 | ![image](https://github.com/psaumur/CCNA/assets/106411237/27c1877f-57d7-44ea-8c64-b0ec2b308ad0) 8 | 9 | 10 | The Ethernet Header contains 5 Fields: 11 | 12 | Preamble -- SFD -- Destination -- Source -- Type/Length 13 | 7 bytes -- 1 byte -- 6 bytes -- 6 bytes -- 2 bytes 14 | 15 | Ethernet Trailer contains 1 Field: 16 | 17 | FCS (Frame Check Sequence) = 4 bytes 18 | 19 | - The PREAMBLE + SFD is not usually considered part of the ETHERNET HEADER. 20 | 21 | THEREFORE the size of the ETHERNET HEADER + TRAILER is 18 bytes 22 | 23 | (6 + 6 + 2 + 4 bytes for the FRAME CHECK SEQUENCE) 24 | 25 | --- 26 | 27 | The MINIMUM size for an ETHERNET FRAME (Header + Payload [PACKET] + Trailer) is 64 BYTES. 28 | 29 | 64 BYTES - 18 BYTES (Header + Trailer size) = 46 BYTES 30 | 31 | THEREFORE the MINIMUM DATA PAYLOAD (PACKET) size is 46 BYTES! 32 | 33 | IF the PAYLOAD is LESS than 46 BYTES then PADDING BYTES are added (padding bytes are a series of 0's) until it equals to 46 BYTES. 34 | 35 | --- 36 | 37 | When a PC sends a packet to a device with an unknown IP address, it uses an ARP Request. 38 | 39 | ![image](https://github.com/psaumur/CCNA/assets/106411237/e2d0e5d2-7c98-4671-b356-903132fd7525) 40 | 41 | 42 | - ARP stands for 'Address Resolution Protocol'. 43 | - It is used to discover the Layer 2 address (MAC address) of a known Layer 3 address (IP address) 44 | - Consists of two messages: 45 | - ARP REQUEST (Source message) 46 | - ARP REPLY (Destination message) 47 | - ARP REQUEST is BROADCAST = sent to all hosts on network, except the one it received the request from. 48 | 49 | An ARP REQUEST frame has: 50 | 51 | - Source IP Address 52 | - Destination IP Address 53 | - Source MAC address 54 | - BROADCAST MAC Address - FFFF.FFFF.FFFF 55 | 56 | An ARP REPLY frame has: 57 | 58 | - Source IP Address 59 | - Destination IP Address 60 | - Source MAC address 61 | - Destination MAC Address 62 | 63 | ARP REPLY is a known UNICAST frame = Sent only to the host that sent the ARP REQUEST. 64 | 65 | ![image](https://github.com/psaumur/CCNA/assets/106411237/914cdf2a-c631-47e5-80f9-46e32ebed311) 66 | 67 | 68 | --- 69 | 70 | PING 71 | 72 | - A network utility that is used to test reachability 73 | - Measures round-trip time 74 | - Uses two messages: 75 | - ICMP Echo REQUEST 76 | - ICMP Echo REPLY 77 | - Is UNICAST 78 | - Command to use ping: 79 | - ping 80 | 81 | By Default, a CISCO IOS sends 5 ICMP requests/replies 82 | (Default size is 100-bytes) 83 | 84 | - A period (.) is a failed ping 85 | - An exclamation mark (!) is a successful ping 86 | 87 | --- 88 | 89 | USEFUL CISCO IOS COMMANDS (from Privileged EXEC mode) 90 | 91 | PC1# show arp // shows hosts ARP table 92 | 93 | ![image](https://github.com/psaumur/CCNA/assets/106411237/da199d21-4f41-485e-8917-ca8e3d789617) 94 | 95 | 96 | --- 97 | 98 | SW1#show mac address-table // show the switches MAC table 99 | 100 | ![image](https://github.com/psaumur/CCNA/assets/106411237/c1cd95dd-7742-4703-9487-946652c95485) 101 | 102 | 103 | Will show: 104 | 105 | Vlan --- MAC Address --- Type --- Ports(interfaces) 106 | 107 | (Vlan = Virtual Local Area Network) 108 | 109 | --- 110 | 111 | ![image](https://github.com/psaumur/CCNA/assets/106411237/657b054b-a90c-4e5f-8544-2a51082cb631) 112 | 113 | 114 | SW1# clear mac address-table dynamic 115 | 116 | // clears the entire switches MAC table. 117 | // IF the optional MAC address is used, it will clear the SPECFIC MAC address. 118 | 119 | SW1 #clear mac address-table dynamic interface 120 | 121 | // clears the MAC table entry of the Switch by it's **INTERFACE n**ame. 122 | -------------------------------------------------------------------------------- /Course_Notes/Extended_Access_Control_Lists.md: -------------------------------------------------------------------------------- 1 | # 35. EXTENDED ACCESS CONTROL LISTS (EACL) 2 | 3 | ANOTHER WAY TO CONFIGURE NUMBERED ACLs 4 | 5 | - In DAY 34, you learned that numbered ACLs are configured in Global Config mode: 6 | 7 | ![image](https://github.com/psaumur/CCNA/assets/106411237/d5bbb9d7-5499-43e0-9ac8-b173e5bb5c50) 8 | 9 | - You learned that named ACLs are configured with subcommands in a separate config mode: 10 | 11 | ![image](https://github.com/psaumur/CCNA/assets/106411237/73104e31-0630-4b2a-a328-29adc5ceb418) 12 | 13 | - However, in modern IOS you can also configure numbered ACLs in the exact same way as named ACLs: 14 | 15 | ![image](https://github.com/psaumur/CCNA/assets/106411237/724638f3-1044-4476-96de-cda39fb51315) 16 | 17 | ![image](https://github.com/psaumur/CCNA/assets/106411237/a72df84e-262b-467c-a87e-b70699033076) 18 | 19 | --- 20 | 21 | ADVANTAGES OF NAMED ACL CONFIG MODE 22 | 23 | - You can easily DELETE individual entries in the ACL with NO *entry-number* 24 | - You can easily DELETE individual entries in the ACL with NO *sequence-number* 25 | 26 | ![image](https://github.com/psaumur/CCNA/assets/106411237/f7f85684-6300-495d-bde9-1e1ffcead85e) 27 | 28 | This doesn’t work with NUMBERED access lists 29 | 30 | ![image](https://github.com/psaumur/CCNA/assets/106411237/8e27f6f1-794b-45be-ac67-20b3f563f551) 31 | 32 | - You can insert NEW entries in-between other entries by specifying the SEQUENCE NUMBER 33 | 34 | ![image](https://github.com/psaumur/CCNA/assets/106411237/41fb1df8-b368-4349-b33a-ba0f8c768435) 35 | 36 | --- 37 | 38 | RESEQUENCING ACLs 39 | 40 | - There is a *resequencing* function that helps edit ACLs 41 | - The command is `R1(config)#ip access-list resequence *acl-id starting-seq-num increment*` 42 | 43 | ![image](https://github.com/psaumur/CCNA/assets/106411237/1c5e3f13-900a-4be4-99ba-db86b0128f57) 44 | 45 | --- 46 | 47 | EXTENDED NUMBERS AND NAMED ACLs 48 | 49 | - EXTENDED ACLs function mostly the same as STANDARD ACLs 50 | - They can be NUMBERED or NAMED, just like STANDARD ACLs 51 | - NUMBERED ACLs use the following ranges: **100 - 199, 2000 - 2699** 52 | - Processed from TOP to BOTTOM, just like STANDARD ACLs 53 | - However, they can match traffic based on MORE PARAMETERS, so they are more PRECISE (and more complex) than STANDARD ACLs 54 | - We will focus on matching based on these main parameters: 55 | - **LAYER 4 protocol / port** 56 | - **Source Address** 57 | - D**estination Address** 58 | 59 | --- 60 | 61 | EXTENDED NUMBERED ACL 62 | 63 | 67 | 68 | EXTENDED NAMED ACL 69 | 70 | 74 | 75 | 79 | 80 | --- 81 | 82 | MATCHING THE PROTOCOL 83 | 84 | ![image](https://github.com/psaumur/CCNA/assets/106411237/f6337620-5eb1-4ddc-837c-ae242a718f29) 85 | 86 | IP Protocol Number is the number used in the IPv4 Header Protocol field 87 | 88 | Examples: (1) ICMP, (6) TCP, (17) UDP, (88) EIGRP, (89) OSPF 89 | 90 | MATCHING THE SOURCE / DESTINATION IP ADDRESS 91 | 92 | ![image](https://github.com/psaumur/CCNA/assets/106411237/bbb38418-3276-485b-ba6b-5c4c7097d56f) 93 | 94 | This command: 95 | 96 | 100 | 101 | Deny ALL PACKETS that encapsulate a TCP segment from ANY source to DESTINATION 10.0.0.0/24 102 | 103 | --- 104 | 105 | PRACTICE QUESTIONS: 106 | 107 | 1) ALLOW ALL TRAFFIC 108 | 109 | `R1(config-ext-nacl)# permit ip any any` (ip is used for “all protocols”) 110 | 111 | 2) PREVENT 10.0.0.0/16 from SENDING UDP traffic to 192.168.1.1/32 112 | 113 | `R1(config-ext-nacl)# deny udp 10.0.0.0 0.0.255.255 host 192.168.1.1` 114 | 115 | 3) PREVENT 172.16.1.1/32 from pinging hosts in 192.168.0.0/24 116 | 117 | `R1(config-ext-nacl)# deny icmp host 172.16.1.1 192.168.0.0 0.0.0.255` 118 | 119 | MATCHING THE TCP / UDP PORT NUMBERS 120 | 121 | - When matching TCP / UDP, you can optionally specify the SOURCE and/or DESTINATION PORT NUMBERS to match 122 | 123 | ![image](https://github.com/psaumur/CCNA/assets/106411237/c059d148-b685-49b2-81e0-518a6d66c25b) 124 | 125 | eq = equal than 126 | 127 | gt = greater than 128 | 129 | lt = less than 130 | 131 | neq = not equal to 132 | 133 | range = range of ports 134 | 135 | You can use either the PORT NUMBER or the specific TYPE (that has a KNOWN PORT NUMBER) 136 | 137 | ![image](https://github.com/psaumur/CCNA/assets/106411237/03dd80be-1f0f-41ac-ae1a-bdb851579bb4) 138 | 139 | ![image](https://github.com/psaumur/CCNA/assets/106411237/f7a11d7b-aeb6-4528-b5cc-62ff515fe33c) 140 | 141 | --- 142 | 143 | PRACTICE QUESTIONS 2: 144 | 145 | 1) ALLOW TRAFFIC from 10.0.0.0/16 to access the server at 2.2.2.2/32 using HTTPS 146 | 147 | `R1(config-ext-nacl)# permit tcp 10.0.0.0 0.0.255.255 host 2.2.2.2 eq 443` 148 | 149 | 2) PREVENT ALL HOSTS using SOURCE UDP Port Numbers from 20000 to 30000 from accessing the server at 3.3.3.3/32 150 | 151 | `R1(config-ext-nacl)# deny udp any range 20000 30000 host 3.3.3.3` 152 | 153 | 3) ALLOW HOSTS in 172.16.1.0/24 using a TCP SOURCE Port greater than 9999 to access ALL TCP ports on server 4.4.4.4/32 EXCEPT port 23 154 | 155 | `R1(config-ext-nacl)# permit tcp 172.16.1.0 0.0.0.255 gt 9999 host 4.4.4.4 neq 23` 156 | 157 | EXAMPLE NETWORK 158 | 159 | ![image](https://github.com/psaumur/CCNA/assets/106411237/ddb40c27-b195-49fe-a12a-49e078166e30) 160 | 161 | ![image](https://github.com/psaumur/CCNA/assets/106411237/692f4a58-13d3-4c0a-8513-3dc76b014b65) 162 | 163 | REQUIREMENTS: 164 | 165 | - Hosts in 192.168.1.0/24 can’t use HTTPS to access SRV1 166 | - Hosts in 192.168.2.0/24 can’t access 10.0.2.0/24 167 | - NONE of the hosts in 192.168.1.0/24 or 192.168.2.0/24 can ping 10.0.1.0/24 OR 10.0.2.0/24 168 | 169 | EXTENDED ACL #1 (Applied at R1 G0/1 INBOUND interface) 170 | 171 | `R1(config)# ip access-list extended HTTP_SRV1` 172 | `R1(config-ext-nacl)# deny tcp 192.168.1.0 0.0.0.255 host 10.0.1.100 eq 443` 173 | 174 | `R1(config-ext-nacl)# permit ip any any` 175 | 176 | `R1(config-ext-nacl)# int g0/1` 177 | 178 | `R1(config-if)# ip access-group HTTP_SRV1 in` 179 | 180 | EXTENDED ACL #2 (APPLIED at R1 G0/2 INBOUND interface) 181 | 182 | `R1(config)# ip access-list extended BLOCK_10.0.2.0` 183 | 184 | `R1(config-ext-nacl)# deny ip 192.168.2.0 0.0.0.255 10.0.2.0 0.0.0.255` 185 | 186 | `R1(config-ext-nacl)# permit ip any any` 187 | 188 | `R1(config-ext-nacl)# int g0/2` 189 | 190 | `R1(config-if)# ip access-group BLOCK_10.0.2.0 in` 191 | 192 | EXTENDED ACL #3 (APPLIED at R1 g0/0 OUTBOUND interface) 193 | 194 | `R1(config)# ip access-list extended BLOCK_ICMP` 195 | 196 | `R1(config-ext-nacl)# deny icmp 192.168.1.0 0.0.0.255 10.0.1.0 0.0.0.255` 197 | 198 | `R1(config-ext-nacl)# deny icmp 192.168.1.0 0.0.0.255 10.0.2.0 0.0.0.255` 199 | 200 | `R1(config-ext-nacl)# deny icmp 192.168.2.0 0.0.0.255 10.0.1.0 0.0.0.255` 201 | 202 | `R1(config-ext-nacl)# permit ip any any` 203 | 204 | `R1(config-ext-nacl)# int g0/0` 205 | 206 | `R1(config-if)# ip access-group BLOCK_ICMP out` 207 | 208 | What the EXTENDED ACLs look like 209 | 210 | ![image](https://github.com/psaumur/CCNA/assets/106411237/cda064f2-b1ce-45ee-a660-04cdceb3514b) 211 | 212 | HOW TO SEE WHICH EXTENDED ACL’s ARE APPLIED TO AN INTERFACE 213 | 214 | ![image](https://github.com/psaumur/CCNA/assets/106411237/f596bca6-c06a-445e-84a3-8f8eb0c6baaf) 215 | -------------------------------------------------------------------------------- /Course_Notes/FTP_and_TFTP.md: -------------------------------------------------------------------------------- 1 | # 43. FTP and TFTP 2 | 3 | THE PURPOSE OF FTP / TFTP 4 | 5 | - FTP (File Transfer Protocol) and TFTP (Trivial File Transfer Protocol) are INDUSTRY STANDARD PROTOCOLS used to TRANSFER FILES over a NETWORK 6 | - They BOTH use a CLIENT-SERVER model 7 | - CLIENTS can use FTP / TFTP to COPY files FROM a SERVER 8 | - CLIENTS can use FTP / TFTP to COPY files TO a SERVER 9 | - As a NETWORK ENGINEER, the most common use for FTP / TFTP is in the process of UPGRADING the OPERATING SYSTEM of a NETWORK DEVICE 10 | - You can use FTP / TFTP to DOWNLOAD the newer version of IOS from a SERVER and then REBOOT the DEVICE with the new IOS image 11 | 12 | ![image](https://github.com/psaumur/CCNA/assets/106411237/c3f8288f-cc21-476b-ab36-685fa843f947) 13 | 14 | --- 15 | 16 | TFTP and FTP FUNCTIONS AND DIFFERENCES 17 | 18 | TFTP 19 | 20 | - TFTP first standardized in 1981 21 | - Named “Trivial” because it’s SIMPLE and has only basic features compared to FTP 22 | - Only allows a CLIENT to COPY FILES to / from a SERVER 23 | - Was released after FTP, but not a REPLACEMENT for FTP. 24 | - It’s another tool to use when LIGHTWEIGHT SIMPLICITY is more important than FUNCTIONALITY 25 | - NO AUTHENTICATION (Username / Password) so SERVERS will respond to ALL FTP REQUESTS 26 | - NO ENCRYPTION. All DATA is sent PLAIN TEXT 27 | - Best used in a CONTROLLED environment to transfer SMALL FILES quickly 28 | - TFTP SERVERS listen on UDP PORT 69 29 | - UDP is CONNECTIONLESS and doesn’t provided RELIABILITY with RETRANSMISSIONS 30 | - However, TFTP has SIMILAR built-in FEATURES within the PROTOCOL itself 31 | 32 | TFTP RELIABILITY 33 | 34 | - Every TFTP DATA message is ACKNOWLEDGED 35 | - If the CLIENT is transferring a FILE TO the SERVER, the SERVER will send ACK messages 36 | - If the SERVER is transferring a FILE TO the CLIENT, the CLIENT will send ACK messages 37 | - TIMERS are used, and if an EXPECTED message isn’t received in time, the waiting DEVICE will RESEND its previous message. 38 | 39 | ![image](https://github.com/psaumur/CCNA/assets/106411237/6b8f914e-0d8f-4cfd-bbbb-3552b5cebb3e) 40 | 41 | TFTP “CONNECTIONS” 42 | 43 | ![image](https://github.com/psaumur/CCNA/assets/106411237/d6634813-5132-4fd8-a712-7bc7b4ea21db) 44 | 45 | TFTP TID (Not in the CCNA exam) 46 | 47 | - When the CLIENT sends the FIRST message to the SERVER, the DESTINATION PORT is UDP 69 and the SOURCE PORT is a random EPHEMERAL PORT 48 | - This “random port” is called a “TRANSFER IDENTIFIER” (TID) and identifies the DATA TRANSFER 49 | - The SERVER then also selects a RANDOM TID to use as a SOURCE PORT when it replies, NOT UDP 69 50 | - When the CLIENT sends the NEXT message, the DESTINATION PORT will be the SERVER’S TID, NOT UDP 69 51 | 52 | UDP PORT 69 (TFTP) is only used at the initial request message 53 | 54 | ![image](https://github.com/psaumur/CCNA/assets/106411237/5976c631-4cba-4449-a2b4-912f90cb66e1) 55 | 56 | --- 57 | 58 | FTP 59 | 60 | - FTP was first standardized in 1971 61 | - FTP uses TCP PORTS 20 and 21 62 | - USERNAMES and PASSWORDS are used for AUTHENTICATION, however there is NO ENCRYPTION 63 | - For GREATER security, FTPS (FTP over SSL / TLS) can be used (Upgrade to FTP) 64 | - SSH File Transfer Protocol (SFTP) can also be used for GREATER security (New Protocol) 65 | - FTP is MORE complex than TFTP and ALLOWS not only FILE TRANSFERS but CLIENTS can also: 66 | - Navigate FILE DIRECTORIES 67 | - ADD / REMOVE FILES 68 | - LIST FILES 69 | - etc… 70 | - The CLIENT sends FTP *commands* to the SERVER to perform these functions 71 | 72 | FTP CONTROL CONNECTIONS 73 | 74 | - FTP uses TWO TYPES of connections: 75 | - An FTP CONTROL connection (TCP 21) is established and used to send FTP commands and replies 76 | - When FILES or DATA are to be transferred, separate FTP DATA (TCP 20) connections are established and terminated as needed 77 | 78 | ![image](https://github.com/psaumur/CCNA/assets/106411237/8ff1d9a5-785b-4fb4-86a4-766c1107812f) 79 | 80 | ACTIVE MODE FTP DATA CONNECTIONS 81 | 82 | - The DEFAULT method of establishing FTP DATA connections is ACTIVE MODE in which the SERVER initiates the TCP connection. 83 | 84 | ![image](https://github.com/psaumur/CCNA/assets/106411237/49909dbc-1ed5-425b-8958-03fcaf5b9eab) 85 | 86 | - In FTP PASSIVE MODE, the CLIENT initiates the DATA connection. 87 | - This is often necessary when the CLIENT is behind a FIREWALL, which could BLOCK the INCOMING CONNECTION from the SERVER 88 | 89 | ![image](https://github.com/psaumur/CCNA/assets/106411237/5872df1c-b97f-4f61-b0da-6a06e7f69f1a) 90 | 91 | FTP VERSUS TFTP 92 | 93 | ![image](https://github.com/psaumur/CCNA/assets/106411237/e7c11655-61be-40f0-943c-8c51998dc2e2) 94 | 95 | --- 96 | 97 | IOS FILE SYSTEMS 98 | 99 | - A FILE SYSTEM is a way of controlling how DATA is STORED and RETRIEVED 100 | - You can VIEW the FILE SYSTEM of a Cisco IOS DEVICE with `show file systems` 101 | 102 | ![image](https://github.com/psaumur/CCNA/assets/106411237/eb6e12b6-3c34-4e05-93cb-e4368764da74) 103 | 104 | --- 105 | 106 | USING FTP / TFTP IN IOS 107 | 108 | - You can VIEW the current version of IOS with `show version` 109 | 110 | ![image](https://github.com/psaumur/CCNA/assets/106411237/746859c5-d89d-42f5-b198-d0cba7f3682d) 111 | 112 | - You can VIEW the contents of flash with `show flash` 113 | 114 | ![image](https://github.com/psaumur/CCNA/assets/106411237/d131b08c-572d-46b3-8910-0d423b85dc94) 115 | 116 | --- 117 | 118 | COPYING FILES WITH TFTP 119 | 120 | STEP 1 121 | 122 | ![image](https://github.com/psaumur/CCNA/assets/106411237/f0ce7ea9-115e-4db8-9baf-55ee1bf0d548) 123 | 124 | STEP 2 125 | 126 | ![image](https://github.com/psaumur/CCNA/assets/106411237/9be3610d-3e22-476f-ab90-117ba7d93cf0) 127 | 128 | STEP 3 129 | 130 | ![image](https://github.com/psaumur/CCNA/assets/106411237/604528f7-af5d-44a4-a877-c9d82d7910d1) 131 | 132 | --- 133 | 134 | COPYING FILES WITH FTP 135 | 136 | STEP 1 137 | 138 | ![image](https://github.com/psaumur/CCNA/assets/106411237/0e9c1dc5-0dce-4cbb-b584-0509c2119f63) 139 | 140 | STEP 2 and 3 identical to TFTP above 141 | 142 | --- 143 | 144 | COMMAND SUMMARY 145 | 146 | ![image](https://github.com/psaumur/CCNA/assets/106411237/e5f525cd-6e98-4501-9e7c-1c1f4af1d23e) 147 | -------------------------------------------------------------------------------- /Course_Notes/First_Hop_Redundancy_Protocols.md: -------------------------------------------------------------------------------- 1 | # 29. FIRST HOP REDUNDANCY PROTOCOLS 2 | 3 | THE PURPOSE OF FHRPS 4 | 5 | 6 | ![image](https://github.com/psaumur/CCNA/assets/106411237/32c286ce-e042-4cda-9067-c232a210ec81) 7 | 8 | What happens when the configured DEFAULT GATEWAY for network HOSTS goes down ? 9 | 10 | What happens to the routed traffic? 11 | 12 | How can we route our traffic to the functional GATEWAY at R2 (.253) ? 13 | 14 | This is what the FIRST HOP REDUNDANCY PROTOCOL is designed to fix 15 | 16 | --- 17 | 18 | FIRST HOP REDUNDANCY PROTOCOL (FHRP) 19 | 20 | - Computer networking protocol 21 | - Designed to PROTECT the DEFAULT GATEWAY used on a SUBNET by allowing TWO or MORE ROUTERS to provide BACKUP for that ADDRESS 22 | - In the event of a FAILURE of the ACTIVE ROUTER, the BACKUP ROUTER will take over the ADDRESS (usually within seconds) 23 | 24 | --- 25 | 26 | HOW DOES FHRP WORK? 27 | 28 | - TWO (or more) ROUTERS share a VIP (A Virtual IP ADDRESS) 29 | - THIS VIP is used by HOSTS as the DEFAULY GATEWAY IP 30 | - The ROUTERS communicate with each other by sending “Hello” messages 31 | - One ROUTER becomes the ACTIVE ROUTER, the other(s) STANDBY 32 | - When a HOST sends traffic to an ADDRESS outside of the NETWORK, it sends an ARP REQUEST (Broadcast Flood) to the VIP to find out it’s MAC ADDRESS 33 | - Spanning Tree prevents BROADCAST STORM due to Broadcast Flood 34 | - The ACTIVE ROUTER sends the ARP REPLY back (it’s VIRTUAL MAC ADDRESS) to the HOST 35 | - The HOST now sends traffic OUTSIDE of the NETWORK with: 36 | - Source IP (HOST IP) 37 | - Destination IP (External IP ADDRESS) 38 | - Source MAC (HOST MAC ADDRESS) 39 | - Destination MAC (GATEWAY VIP MAC ADDRESS) 40 | 41 | ![image](https://github.com/psaumur/CCNA/assets/106411237/2a1c5df8-d4fa-44fa-b850-a8fd6bb69388) 42 | 43 | IF R1 goes down, R2 will switch from STANDY to ACTIVE after not receiving “Hello” messages from R1 44 | 45 | ![image](https://github.com/psaumur/CCNA/assets/106411237/5e54ee53-09bd-42a7-b89e-69892590913d) 46 | 47 | The HOST ARP TABLE doesn’t need to change since the MAC ADDRESS of the VIP is already known and traffic flows externally via R2 48 | 49 | R2 DOES need to update the SWITCHES with a GRATUITOUS ARP 50 | 51 | - GRATUITOUS ARP is an ARP REPLY sent without being REQUESTED (no ARP REQUEST received) 52 | - GRATUITOUS ARP uses BROADCAST (FFFF.FFFF.FFFF) - Normal ARP REPLY is Unicast 53 | 54 | ![image](https://github.com/psaumur/CCNA/assets/106411237/6a47dc71-544e-4e33-99cd-b6a8db90f56f) 55 | 56 | ![image](https://github.com/psaumur/CCNA/assets/106411237/6f36cdf9-d002-48d6-ae5b-6fb899431b46) 57 | 58 | What happens is R1 comes back ONLINE again? 59 | 60 | It becomes a STANDBY ROUTER 61 | 62 | R2 remains the ACTIVE ROUTER 63 | 64 | 70 | 71 | --- 72 | 73 | HSRP (HOT STANDBY ROUTER PROTOCOL) 74 | 75 | - **Cisco proprietary** 76 | - An ACTIVE and STANDBY ROUTER are elected 77 | - There are TWO VERSIONS : 78 | - version 1 79 | - version 2 : *adds IPv6 support* and increases # of *groups* that can be configured 80 | 81 | - Multicast IPv4 ADDRESSES : 82 | - **v1** : 224.0.0.2 83 | - **v2** : 224.0.0.102 84 | 85 | - VIRTUAL MAC ADDRESSES : 86 | - **v1** : 0000.0c07.acXX (XX = HSRP GROUP NUMBER) 87 | - **v2** : 0000.0c9f.fXXX (XXX = HSRP GROUP NUMBER) 88 | 89 | - In a situation with MULTIPLE SUBNETS / VLANS, you can configure a DIFFERENT ACTIVE ROUTER in EACH SUBNET / VLAN to LOAD BALANCE 90 | 91 | ![image](https://github.com/psaumur/CCNA/assets/106411237/a5795fa0-d57b-4037-8945-a39da7fb2d15) 92 | 93 | --- 94 | 95 | VRRP (VIRTUAL ROUTER REDUNDANCY PROTOCOL) 96 | 97 | - Open Standard 98 | - A MASTER and BACKUP ROUTER are elected 99 | 100 | - Multicast IPv4 ADDRESSES : 101 | - 224.0.0.18 102 | 103 | - VIRTUAL MAC ADDRESSES : 104 | - 0000.5e00.01XX (XX = VRRP GROUP NUMBER) 105 | - for GROUP NUMBERS > 99, you need to convert the number to HEX 106 | - Example: 200 = “c8” in Hex so the MAC would be 0000.5e00.01c8 107 | 108 | - In a situation with MULTIPLE SUBNETS / VLANS, you can configure a DIFFERENT MASTER ROUTER in EACH SUBNET / VLAN to LOAD BALANCE 109 | 110 | ![image](https://github.com/psaumur/CCNA/assets/106411237/4bd45dbc-fc51-4c45-818e-5274530accde) 111 | 112 | --- 113 | 114 | GLBP (GATEWAY LOAD BALANCING PROTOCOL) 115 | 116 | - Cisco Proprietary 117 | - LOAD BALANCES among MULTIPLE ROUTERS within a SINGLE SUBNET 118 | - An AVG (Active Virtual Gateway) is elected 119 | - Up to FOUR AVFs (Active Virtual Forwarders) are assigned BY the AVG (the AVG can be an AVF, too) 120 | - Each AVF acts as the DEFAULT GATEWAY for a portion of the HOSTS in the SUBNET 121 | 122 | - Multicast IPv4 ADDRESSES : 123 | - 224.0.0.102 124 | 125 | - VIRTUAL MAC ADDRESSES : 126 | - 0007.b400.XXYY (XX = GLBP GROUP NUMBER, YY = AVF NUMBER) 127 | 128 | --- 129 | 130 | MEMORIZE THIS CHART and the differences between the FHRPs 131 | 132 | ![image](https://github.com/psaumur/CCNA/assets/106411237/a5b5ee87-4c92-4b3e-9b98-3d0c09a1732d) 133 | 134 | --- 135 | 136 | BASIC HSRP CONFIGURATION 137 | 138 | R1s configuration 139 | 140 | ![image](https://github.com/psaumur/CCNA/assets/106411237/028b13d4-b258-4551-96ae-068adb931356) 141 | 142 | NOTE : group number has to match ALL ROUTERS being configured in a given SUBNET 143 | 144 | ![image](https://github.com/psaumur/CCNA/assets/106411237/d2e5eb5f-d105-4788-a869-d9e65f53eca7) 145 | 146 | R2’s configuration 147 | 148 | ![image](https://github.com/psaumur/CCNA/assets/106411237/65b999f6-eed8-45c3-89fe-bff749f40f11) 149 | 150 | NOTE : HSRP versions are not cross-compatible. All ROUTERS must use the same HSRP Version 151 | 152 | Output of the “show standby” command 153 | 154 | ![image](https://github.com/psaumur/CCNA/assets/106411237/99107301-2619-4454-b104-8aed3780924d) 155 | -------------------------------------------------------------------------------- /Course_Notes/IPv4_Addressing_Part2.md: -------------------------------------------------------------------------------- 1 | # 8. IPv4 ADDRESSING : PART 2 2 | 3 | MAXIMUM HOSTS PER NETWORK 4 | 5 | Let's take a Class C Network: 6 | 7 | 192.168.1.0/24 8 | 9 | (gives a range of 0 ---> 255) 10 | 11 | Said another way, the HOST portion (the .0) is equal to 8 bits so... 12 | 13 | Host portion = 8 bits = 2^8 = 256 14 | 15 | HOWEVER, since the Network Address (Network ID) 16 | 17 | 192.168.1.0 is Reserved 18 | 19 | AND 20 | 21 | 192.168.1.255 (BROADCAST ADDRESS) is ALSO reserved. 22 | 23 | The MAXIMUM Hosts per Network = 2^8-2 = 254 hosts 24 | 25 | --- 26 | 27 | What about a Class B Network ? 28 | 29 | 172.16.0.0/16 ----> 172.16.255.255/16 30 | 31 | Host portion = 16 bits = 2^16 = 65,536 32 | 33 | Maximum hosts per network = 2^16-2 = 65,534 hosts 34 | 35 | --- 36 | 37 | What about a Class A Network ? 38 | 39 | 10.0.0.0/8 -------------> 10.255.255.255/8 40 | 41 | Host portion = 24 bits = 2^24 = 16,777,216 42 | 43 | Maximum hosts per network = 2^24-2 = 16,777,214 hosts 44 | 45 | --- 46 | 47 | THEREFORE: 48 | 49 | The formula for calculating the number of HOSTS on a network is: 50 | 51 | 2 ^ N - 2 (2 to the power of N - 2) 52 | 53 | where N = number of HOST bits 54 | 55 | --- 56 | 57 | FIRST / LAST USABLE ADDRESSES 58 | 59 | Class C Network 60 | 61 | 192.168.1.0/24 (NETWORK ADDRESS) 62 | 63 | Add 1 so the Host Portion = 00000001 64 | 65 | 192.168.1.1/24 = FIRST USABLE ADDRESS 66 | 67 | --- 68 | 69 | 192.168.1.255/24 (BROADCAST ADDRESS) 70 | 71 | Subtract 1 from the BROADCAST ADDRESS = 11111110 72 | 73 | 192.168.1.254/24 = LAST USABLE ADDRESS 74 | 75 | --- 76 | 77 | Class B Network 78 | 79 | 172.16.0.0/16 (NETWORK ADDRESS) 80 | 81 | Add 1 to Host portion so 0000 0000 0000 0001 82 | 83 | 172.16.0.1/16 is the FIRST USABLE ADDRESS 84 | 85 | --- 86 | 87 | 172.16.255.255/16 (BROADCAST ADDRESS) 88 | 89 | Subtract 1 to Broadcast Address so 1111 1111 1111 1110 90 | 91 | 172.16.255.254/16 is the LAST USABLE ADDRESS 92 | 93 | --- 94 | 95 | Class A Network 96 | 97 | 10.0.0.0/8 (NETWORK ADDRESS) 98 | 99 | Add 1 to Host portion so 00000000 00000000 00000001 100 | 101 | 10.0.0.1/8 is the FIRST USABLE ADDRESS 102 | 103 | --- 104 | 105 | 10.255.255.255/8 (BROADCAST ADDRESS) 106 | 107 | Subtract 1 to Broadcast Address so 1111 1111 1111 1110 108 | 109 | 10.255.255.254/16 is the LAST USABLE ADDRESS 110 | 111 | --- 112 | 113 | CISCO CLI DEVICE CONFIGURATION 114 | 115 | R1> enable 116 | R1# show ip interface brief 117 | 118 | Lists the Interfaces, IP Addresses, Method, Status, and Protocol. 119 | 120 | Interfaces: 121 | 122 | - What port interfaces are available/connected 123 | 124 | IP Addresses 125 | 126 | - Self explanatory. What IP Address is assigned. 127 | 128 | Method 129 | 130 | - What method was the IP address assigned? 131 | 132 | Status (Layer 1 Status) 133 | 134 | - Current status of interface 135 | - 'administratively down' = Interface has been disabled with the 'shutdown' command 136 | 137 | Administratively down is the DEFAULT status of Cisco Router interfaces. 138 | 139 | Cisco Switch interfaces are NOT administratively down by DEFAULT. 140 | 141 | Protocol (Layer 2 Status) 142 | 143 | - Cannot operate if Status (Layer 1) is down 144 | 145 | ![image](https://github.com/psaumur/CCNA/assets/106411237/fa113ff0-a8ee-410b-ab3e-64684654cac6) 146 | 147 | 148 | --- 149 | 150 | // configure terminal cmd 151 | 152 | R1# conf t 153 | 154 | // This enters interface configuration mode 155 | 156 | R1(config)# interface gigabitethernet 0/0 157 | 158 | This can be shortened to 'g0/0' like they are listed in physical network maps. 159 | 160 | ![image](https://github.com/psaumur/CCNA/assets/106411237/df83bf09-c391-45b7-b1b4-41db061b84f4) 161 | 162 | 163 | // This sets the IP ADDRESS and SUBNET MASK of device 164 | 165 | R1(config-if) #ip address 10.255.255.254 255.0.0.0 166 | 167 | // This enables the device 168 | 169 | R1(config-if) #no shutdown 170 | 171 | --- 172 | 173 | Two messages should appear showing the state has changed to 'up' (Status). Second message should show line protocol is now 'up' (Protocol). 174 | 175 | // 'do' allows you to run a Privileged EXEC command from outside the mode. 176 | 177 | R1(config-if) #do show ip interface brief 178 | 179 | Good to confirm that the device/interface you have configured is up and running. 180 | 181 | --- 182 | 183 | More 'show' CLI Commands 184 | 185 | ![image](https://github.com/psaumur/CCNA/assets/106411237/bdc1152e-1946-4ddb-ae72-1e23b9c9defa) 186 | 187 | 188 | 'show interfaces ' 189 | 190 | - Shows Layer 1 and Layer 2 information about the interface and some Layer 3. 191 | - Shows MAC Address (or BIA address) 192 | - IP Address 193 | - ... and so much more 194 | 195 | 'show interfaces description' 196 | 197 | - Allows you to add descriptions for interfaces. 198 | 199 | Example: 200 | 201 | // Configure mode for interface Gigabyte Interface 0/0 202 | 203 | R1(config) #int g0/0 204 | 205 | R1(config) #description ## to SW1 ## 206 | 207 | This sets the 'Description' column to display: 208 | 209 | Interface Description 210 | 211 | Gi0/0 ## to SW1 ## 212 | -------------------------------------------------------------------------------- /Course_Notes/IPv6_Part1.md: -------------------------------------------------------------------------------- 1 | # 31. IPv6 : PART 1 2 | 3 | HEXIDECIMAL (Review) 4 | 5 | ![image](https://github.com/psaumur/CCNA/assets/106411237/df3e0c7f-5325-4c4c-9d88-197b588cdfe4) 6 | 7 | ![image](https://github.com/psaumur/CCNA/assets/106411237/a23caee6-492b-4226-ba9f-7b3e44578fd4) 8 | 9 | ![image](https://github.com/psaumur/CCNA/assets/106411237/1a7e0af8-4f19-483d-b75c-27fa452ce8e9) 10 | 11 | What about the reverse (Hex to Binary) ??? 12 | 13 | ![image](https://github.com/psaumur/CCNA/assets/106411237/ceced09e-175f-452d-87e8-5b10af7621a1) 14 | 15 | --- 16 | 17 | WHY IPv6? 18 | 19 | - The **MAIN REASON** is that there are simply not enough IPv4 addresses available 20 | - There are 2^32 IPv4 Addresses available (4,294,967,296) 21 | - When IPv4 was being designed 30 years ago, the creators had NO idea the Internet would be as large as today 22 | - VLSM, Private IPv4 ADDRESSES, and NAT have been used to conserve the use of IPv4 ADDRESS SPACE. 23 | - These are short-term solutions, however. 24 | - The LONG -TERM solution is IPv6 25 | 26 | - IPv4 ADDRESS assignments are controlled by IANA (Internet Assigned Number Authority) 27 | - IANA distributes IPv4 ADDRESS space to various RIRs (Regional Internet Registries), which then assign them to companies that need them. 28 | 29 | ![image](https://github.com/psaumur/CCNA/assets/106411237/98fdf256-dbbf-4884-825a-6124251da6a7) 30 | 31 | - On September 24th, 2015, ARIN declared exhaustion of the ARIN IPv4 address pool 32 | - On August 21st, 2020, LACNIC announced that it had made its final IPv4 allocation 33 | 34 | --- 35 | 36 | BASICS OF IPv6 37 | 38 | - An IPv6 ADDRESS is **128 bits (8 bytes)** 39 | 40 | ![image](https://github.com/psaumur/CCNA/assets/106411237/3e6fe314-c87f-4116-bf37-7f3cfd8e17b4) 41 | 42 | - An IPv6 ADDRESS uses the / prefix number 43 | 44 | SHORTENING (Abbreviating) IPv6 ADDRESSES 45 | 46 | ![image](https://github.com/psaumur/CCNA/assets/106411237/7796f62c-5daa-4e3c-a029-2c42e8abfc6c) 47 | 48 | ![image](https://github.com/psaumur/CCNA/assets/106411237/ee734193-9708-44a8-8702-c0d9d07afaad) 49 | 50 | ![image](https://github.com/psaumur/CCNA/assets/106411237/a19192b2-fcd9-4280-95c4-281ef08ffa5e) 51 | 52 | ![image](https://github.com/psaumur/CCNA/assets/106411237/07c413b6-1577-47c3-963c-4ccca8e20820) 53 | 54 | ![image](https://github.com/psaumur/CCNA/assets/106411237/ea5f5e40-1b4f-4fd8-942c-c17ca2535e35) 55 | 56 | EXPANDING (Abbreviating) IPv6 ADDRESSES 57 | 58 | ![image](https://github.com/psaumur/CCNA/assets/106411237/934a089e-6ec1-4297-b0da-154b8240af35) 59 | 60 | FINDING the IPv6 PREFIX (GLOBAL UNICAST ADDRESSES) 61 | 62 | - Typically, an Enterprise requesting IPv6 ADDRESSES from their ISP will receive a /48 BLOCK 63 | - Typically, IPv6 SUBNETS use a /64 PREFIX LENGTH 64 | - That means an Enterprise has 16 bits to use to make SUBNETS 65 | - The remaining 64 bits can be used for HOSTS 66 | 67 | ![image](https://github.com/psaumur/CCNA/assets/106411237/12448711-2636-4133-bed9-d655bedbd418) 68 | 69 | ![image](https://github.com/psaumur/CCNA/assets/106411237/fa872c5a-4d39-4519-9248-f4f552539bb8) 70 | 71 | (Each digit is 4 bits / each 4 digit block is 16 bits) 72 | 73 | **REMEMBER** : You can only remove the LEADING ZEROS !!! 74 | 75 | 2001 : 0DB8 : 8B00 : 0001 : FB89 : 017B : 0020 : 0011 /93 76 | 77 | Because 93 lands in the middle of a 4 bit number, we need to convert the last digit to binary and borrow a “bit” from the first binary digit. 78 | 79 | :: 017 [B] :: B = 0d11 = 0b1011 = 0b1000 (the first digit is borrowed, the remainder become 0) 80 | 81 | ![image](https://github.com/psaumur/CCNA/assets/106411237/1703e18d-da7a-4ee9-850e-d4e4a59ec72a) 82 | 83 | ![image](https://github.com/psaumur/CCNA/assets/106411237/c7e6fcec-ec8c-40df-86b6-72486e2a3165) 84 | 85 | --- 86 | 87 | CONFIGURING IPv6 ADDRESSES 88 | 89 | ![image](https://github.com/psaumur/CCNA/assets/106411237/7ee88c71-617f-4bfc-8220-a4ef5bbe89e3) 90 | 91 | This allows the ROUTER to perform IPv6 ROUTING 92 | 93 | 97 | 98 | Configuring an INTERFACE with an IPv6 Address 99 | 100 | 106 | 107 | You can also type out the full address (if necessary) 108 | 109 | ![image](https://github.com/psaumur/CCNA/assets/106411237/c83977d3-678f-4922-9be2-f52c6a679d64) 110 | 111 | NOTE ABBREVIATED IPv6 ADDRESSES SHOWN 112 | 113 | LINK-LOCAL ADDRESSES are automatically added when creating an IPv6 INTERFACE (Covered in IPv6 - PART 2 Lecture) 114 | -------------------------------------------------------------------------------- /Course_Notes/IPv6_Part2.md: -------------------------------------------------------------------------------- 1 | # 32. IPv6 : PART 2 2 | 3 | IPv6 ADDRESS CONFIGURATION (EUI-64) 4 | 5 | - EUI stands for Extended Unique Identifier 6 | - (Modified) EUI-64 is a method of converting a MAC address (48-bits) into a 64-bit INTERFACE identifier 7 | - This INTERFACE identifier can then become the “HOST portion” of a /64 IPv6 ADDRESS 8 | 9 | ![image](https://github.com/psaumur/CCNA/assets/106411237/bee8f7bf-3877-4307-9ca7-863af19aae6c) 10 | 11 | EUI-64 PRACTICE: 12 | ``` 13 | 782B CBAC 0867 >>> 782B CB || AC 0867 14 | 15 | 782B CBFF FEAC 0867 16 | 17 | 8 is the 7th bit so 1000 inverted becomes 1010 = A in hex 18 | 19 | so the EUI-64 Interface Identifier is : 7A2B CBFF FEAC 0867 20 | ``` 21 | 22 | ![image](https://github.com/psaumur/CCNA/assets/106411237/d4e90146-8c71-4c6c-b5aa-a9077bde2caf) 23 | 24 | --- 25 | CONFIGURING IPv6 ADDRESSES with EUI-64 26 | 27 | ![image](https://github.com/psaumur/CCNA/assets/106411237/e6c6da0b-def4-4764-a0a1-3f64855f319f) 28 | 29 | ![image](https://github.com/psaumur/CCNA/assets/106411237/bff1b2bc-9944-451a-972a-f8b3bd5f76ea) 30 | 31 | ![image](https://github.com/psaumur/CCNA/assets/106411237/4c69d97a-a611-4a94-9e11-9016ec456819) 32 | 33 | NOTE the “2001:DB8…” Address has “E” changed to “c”. This is the 7th bit getting flipped (1110 to 1100 = 12 = hex ‘C’) 34 | 35 | --- 36 | 37 | WHY INVERT THE 7th BIT ? 38 | 39 | - MAC addresses can be divided into TWO TYPES: 40 | - UAA (Universally Administered Address) 41 | - Uniquely assigned to the device of the manufacturer 42 | - LAA (Locally Administered Address) 43 | - Manually assigned by an Admin (with the mac-address command on the INTERFACE) or protocol. Doesn’t have to be globally unique. 44 | - You can INDENTIFY a UAA or LAA by the 7th bit of the MAC ADDRESS, called the U/L bit (Universal/Local bit) 45 | - U/L bit set to 0 = UAA 46 | - U/L bit set to 1 = LAA 47 | - In the context of IPv6 addresses/EUI-64, the meaning of the U/L bit is reversed: 48 | - U/L bit set to 0 = The MAC address the EUI-64 INTERFACE ID was made from was an LAA 49 | - U/L bit set to 1 = The MAC address the EUI-64 INTERFACE ID was made from was a UAA 50 | 51 | --- 52 | 53 | IPv6 ADDRESS TYPES 54 | 55 | 1) GLOBAL UNICAST ADDRESSES 56 | 57 | - **Global Unicast** IPv6 ADDRESSES are PUBLIC ADDRESSES which can be used over the INTERNET 58 | - Must REGISTER to use them. 59 | - They are PUBLIC ADDRESSES so need to be GLOBALLY UNIQUE 60 | 61 | 💡 Originally defined as the 2000 :: /3 block 62 | (2000:: to 3FFF : FFFF : FFFF : FFFF : FFFF : FFFF : FFFF : FFFF) 63 | 64 | - NOW defined as ALL ADDRESSES which are not RESERVED for other purposes 65 | 66 | Remember THESE THREE PARTS of a GLOBAL UNICAST ADDRESS 67 | 68 | ![image](https://github.com/psaumur/CCNA/assets/106411237/c5552f0e-eca2-4069-a656-611b5c196402) 69 | 70 | --- 71 | 72 | 2) UNIQUE LOCAL ADDRESSES 73 | 74 | - **Unique Local** IPv6 ADDRESSES are PRIVATE ADDRESSES which cannot be used over the internet 75 | - You do NOT need to REGISTER to use them 76 | - Can be used FREELY within INTERNAL NETWORKS 77 | - Do NOT need to be GLOBALLY UNIQUE (*) 78 | - CANNOT be ROUTED over the INTERNET 79 | 80 | 85 | 86 | - A later UPDATE required the 8th bit to be set to 1 so the FIRST TWO DIGITS must be FD 87 | 88 | (*) The GLOBAL ID should be UNIQUE so that ADDRESSES don’t overlap when companies MERGE 89 | 90 | ![image](https://github.com/psaumur/CCNA/assets/106411237/6e6f8af9-ee53-4e0d-90ec-9e137b10c851) 91 | 92 | --- 93 | 94 | 3) LINK-LOCAL ADDRESSES 95 | 96 | - **Link-Local** IPv6 ADDRESSES are AUTOMATICALLY generated on IPv6-enabled INTERFACES 97 | - Use command `R1(config-if)# ipv6 enable` on an interface to enable IPv6 on an INTERFACE 98 | 99 | 104 | 105 | - The STANDARD states that the 54-bits AFTER FE80/10 should be ALL 0’s so you won’t see Link-Local ADDRESSES beginning with FE9, FEA, or FEB - ONLY FE8(!) 106 | - The INTERFACE ID is generated using EUI-64 rules 107 | - Link-Local means that these addresses are used for communication within a single link (SUBNET) 108 | - ROUTER will not route PACKETS with a Link-Local DESTINATION IPv6 ADDRESS 109 | - Common uses of Link-Local Addresses: 110 | - Routing Protocol Peerings (OSPFv3 uses Link-Local Addresses for Neighbour Adjacencies) 111 | - NEXT-HOP ADDRESS for STATIC ROUTES 112 | - Neighbor Discovery Protocol (NDP, IPv6’s replacement for ARP) uses Link-Local ADDRESSES to function 113 | 114 | Network using Link-Local Addresses for “next-hop” routing 115 | 116 | ![image](https://github.com/psaumur/CCNA/assets/106411237/7d74c4fb-ef52-4436-8285-77ab571f2964) 117 | 118 | 119 | --- 120 | 121 | 4) MULTICAST ADDRESSES 122 | 123 | - **Unicast Addresses** are one-to-one 124 | - ONE SOURCE to ONE DESTINATION 125 | - ***Broadcast*** Addresses are one-to-all 126 | - ONE SOURCE to ALL DESTINATIONS (within the subnet) 127 | - **Multicast** Addresses are one-to-many 128 | - ONE SOURCE to MULTIPLE DESTINATIONS (that have joined the specific ***multicast*** group) 129 | 130 | 135 | 136 | - **IPv6 doesn’t use Broadcast** (there IS NO “Broadcast Address” in IPv6!) 137 | 138 | YOU MUST KNOW THE MULTICAST ADDRESS FOR EACH ROUTER TYPE 139 | 140 | NOTE that the IPv6 and IPv4 Addresses share the same last digit 141 | 142 | ![image](https://github.com/psaumur/CCNA/assets/106411237/e5efcdd7-5d7d-4020-a179-07ba267bf5ab) 143 | 144 | MULTICAST ADDRESS SCOPES 145 | 146 | - IPv6 defines multiple MULTICAST ‘scopes’ which indicate how far the PACKET should be forwarded 147 | - The ADDRESS in the previous slide all use the ‘link-local’ scope (FF02), which stays in the LOCAL SUBNET 148 | 149 | **IPv6 Multicast Scope Types:** 150 | 151 | - **Interface-Local (FF01)** 152 | - The PACKET doesn’t leave the LOCAL device 153 | - Can be used to SEND traffic to a SERVICE within the LOCAL device 154 | 155 | - **Link-Local (FF02)** 156 | - The PACKET remains in the LOCAL SUBNET 157 | - ROUTERS will not route the PACKET between SUBNETS 158 | 159 | - **Site-Local (FF05)** 160 | - The PACKET can be forwarded by ROUTERS 161 | - Should be limited to a SINGLE PHYSICAL LOCATION (not forwarded over a WAN) 162 | - **Organization-Local (FF08)** 163 | - Wider in scope than Site-Local (an entire company / ORGANIZATION) 164 | - **Global (FF0E)** 165 | - No boundaries 166 | - Possible to be ROUTED over the INTERNET 167 | 168 | ![image](https://github.com/psaumur/CCNA/assets/106411237/5d5f2d6e-3e21-4ab7-bf8e-dec5d12b6eed) 169 | 170 | 5) ANYCAST ADDRESS 171 | 172 | - **ANYCAST is a NEW feature of IPv6** 173 | - ANYCAST is ‘one-to-one-of-many’ 174 | - Multiple ROUTERS are configured with the SAME IPv6 ADDRESS 175 | - They use a ROUTING PROTOCOL to advertise the address 176 | - When HOSTS sends PACKETS to that DESTINATION ADDRESS, ROUTERS will forward it to the NEAREST ROUTER configured with THAT IP ADDRESS (based on ROUTING METRIC) 177 | - There is NO SPECIFIC ADDRESS range for ANYCAST ADDRESSES. 178 | - Use a regular UNICAST (Global Unicast, Unique Local) and specify THAT as an ANYCAST ADDRESS 179 | - `R1(config-if)# ipv6 address 2000:db8:1:1::99/128 anycast` 180 | 181 | ![image](https://github.com/psaumur/CCNA/assets/106411237/71729af9-6c02-49bd-b290-af7f5009bd6e) 182 | 183 | 6) OTHER IPv6 ADDRESSES 184 | 185 | - The :: Address = The *unspecified* IPv6 ADDRESS 186 | - Can be used when a DEVICE doesn’t yet know its IPv6 ADDRESS 187 | - IPv6 DEFAULT ROUTES are configured to ::/0 188 | - IPv4 equivalent: 0.0.0.0 189 | - The ::1 Address = The Loopback Address 190 | - Used to test the PROTOCOL STACK on the LOCAL DEVICE 191 | - Messages sent to THIS ADDRESS are processed within the LOCAL DEVICE but not SENT to other DEVICES 192 | - IPv4 equivalent : 127.0.0.0 /8 address range 193 | -------------------------------------------------------------------------------- /Course_Notes/Interfaces_and_Cables.md: -------------------------------------------------------------------------------- 1 | # 2. INTERFACES AND CABLES 2 | 3 | SWITCHES provide many PORTS for connectivity (usually 24) 4 | 5 | These PORTS tend to be RJ-45 (Registered Jack) ports. 6 | 7 | --- 8 | 9 | WHAT IS ETHERNET? 10 | 11 | - Ethernet is a collection of network protocols/standards. 12 | 13 | Why do we need network protocols and standards? 14 | 15 | - provide common communication standards over networks. 16 | - provide common hardware standards to allow connectivity between devices. 17 | 18 | 19 | 20 | Connections between devices operates at a set speed. 21 | 22 | These speeds are measured in "bits per second" (bps) 23 | 24 | A bit is a value of "0" or "1". 25 | A byte is 8 bits (0s and 1s) 26 | 27 | | Size | # of Bits | 28 | | --- | --- | 29 | | 1 kilobit (Kb) | 1,000 | 30 | | 1 megabit (Mb) | 1,000,000 | 31 | | 1 gigabit (Gb) | 1,000,000,000 | 32 | | 1 terabit (Tb) | 1,000,000,000,000 | 33 | 34 | Ethernet standards are: 35 | 36 | - Defined in the IEEE 802.3 standard in 1983 37 | - IEEE = Institute of Electrical and Electronics Engineers 38 | 39 | ETHERNET STANDARDS (COPPER) 40 | 41 | | Speed | Common Name | Standard | Cable Type | Max Transmission Distance | 42 | | --- | --- | --- | --- | --- | 43 | | 10 Mbps | Ethernet | 802.3i | 10BASE-T | 100m Max | 44 | | 100 Mbps | Fast Ethernet | 802.3u | 100BASE-T | 100m Max | 45 | | 1 Gbps | Gigabit Ethernet | 802.3ab | 1000BASE-T | 100m Max | 46 | | 10 Gbps | 10 Gigabit Ethernet | 802.3an | 10GBASE-T | 100m Max | 47 | 48 | BASE = refers to Baseband Signaling 49 | 50 | T = Twisted Pair 51 | 52 | Most Ethernet uses copper cables. 53 | 54 | UTP or Unshielded Twisted Pair 55 | (no metallic shield) 56 | Twist protects against EMI (Electromagnetic Interference) 57 | 58 | Most use 8 wires (4 pairs) however ... 59 | 60 | 10/100BASE-T = 2 pairs (4 wires) 61 | 62 | ![image](https://github.com/psaumur/CCNA/assets/106411237/00b27997-a78a-4e81-a878-7f8ab7e3279e) 63 | 64 | 65 | --- 66 | 67 | How do devices communicate via their connections? 68 | 69 | Each ethernet cable has a RJ-45 plug with 8 pins on the ends. 70 | 71 | ![image](https://github.com/psaumur/CCNA/assets/106411237/323930c9-3387-4bf9-aae1-f61db0fd9c04) 72 | 73 | 74 | - PCs Transmit(TX) data on Pins #1-2 75 | - Switches Receive(RX) data on Pins #1-2 76 | - PCs Receive(RC) data on Pins #3,6 77 | - Switches Transmit(TX) data on Pins #3,6 78 | 79 | This allows Full-Duplex transmission of data. 80 | 81 | --- 82 | 83 | What if a Router / Switch connect? 84 | 85 | ![image](https://github.com/psaumur/CCNA/assets/106411237/907259d9-1837-4d53-8f45-a42934fb66f2) 86 | 87 | 88 | - Routers Transmit(TX) data on Pins #1-2 89 | - Routers Receive(RX) data on Pins #3,6 90 | - Switches Transmit(TX) data on Pins #3,6 91 | - Switches Receive(RX) data on Pins #1-2 92 | 93 | Routers and PCs connect the same way with Switches. 94 | 95 | The cable used to connect is called a "Straight-Through" cable. 96 | 97 | --- 98 | 99 | What if we want to connect similar devices to each other? 100 | 101 | We CANNOT use a "Straight-Through" cable. 102 | We MUST use a "Crossover" cable. 103 | 104 | This cable swaps the pins on one end to allow connection to work. 105 | 106 | ![image](https://github.com/psaumur/CCNA/assets/106411237/d98646ad-366f-4e96-8c6f-f6b5f32f9bdc) 107 | 108 | 109 | PIN#1 -----> PIN#3 110 | PIN#2 -----> PIN#6 111 | 112 | PIN#3 -----> PIN#1 113 | PIN#6 -----> PIN#2 114 | 115 | --- 116 | 117 | | DEVICE TYPE | TRANSMIT (TX) PINS | RECEIVE (RX) PINS | 118 | | --- | --- | --- | 119 | | ROUTER | 1 and 2 | 3 and 6 | 120 | | FIREWALL | 1 and 2 | 3 and 6 | 121 | | PC | 1 and 2 | 3 and 6 | 122 | | SWITCH | 3 and 6 | 1 and 2 | 123 | 124 | --- 125 | 126 | Most modern equipment now has AUTO MDI-X which **automatically detects** which pins their neighbour is transmitting on and adjust the pins they receive data on. 127 | 128 | 1000BASE-T/10GBASE-T = 4 pairs (8 wires) 129 | 130 | Each wire pair is **bidirectional** so can transmit/receive much faster than 10/100BASE-T. 131 | 132 | ![image](https://github.com/psaumur/CCNA/assets/106411237/763c841a-d7b5-4e87-8500-b54d623af620) 133 | 134 | 135 | --- 136 | 137 | Fiber-Optic Connections: 138 | 139 | - Defined in the IEEE 802.3ae standard 140 | 141 | SFP Transceiver (Small Form-Factor Pluggable) allows fiber-optic cables to connect to switches/routers. 142 | 143 | - Have separate cables to transmit / receive. 144 | 145 | 4 parts to a fiber-optic cable. 146 | 147 | ![image](https://github.com/psaumur/CCNA/assets/106411237/70b81cde-265f-413b-815b-3e7184ea0586) 148 | 149 | 150 | There are TWO types of fiberoptic cable. 151 | 152 | Single-Mode: 153 | 154 | ![image](https://github.com/psaumur/CCNA/assets/106411237/d9a4b633-44c2-491d-92e4-329dd3b9074b) 155 | 156 | 157 | - Narrower than multimode 158 | - Lighter enters at a single angle (mode) from a laser-based transmitter. 159 | - Allows longer cables than both UTP and multimode fiber. 160 | - More expensive than multimode fiber (due to more expensive laser-based SFP transmitters) 161 | 162 | Multimode: 163 | 164 | ![image](https://github.com/psaumur/CCNA/assets/106411237/e73ec4d0-9aa1-4a75-848c-3af70e770dce) 165 | 166 | 167 | - Core is wider than Single-mode 168 | - Allows multiple angles (modes) of light waves to enter core 169 | - Allows longer cables than UTP but shorter than single-mode 170 | - Cheaper than single-mode fiber (due to cheaper LED-based SFP transmitter) 171 | 172 | --- 173 | 174 | Fiber Optic Standards: 175 | 176 | | Speed | Standard | Connection Speed | Mode Support | Max Transmission Distance | 177 | | --- | --- | --- | --- | --- | 178 | | 1000BASE-LX | 802.3z | 1 Gbps | Multimode / Single | 550 meters (Multi) / 5km (Single) | 179 | | 10GBASE-SR | 802.3ae | 10 Gbps | Multimode | 400 meters | 180 | | 10GBASE-LR | 802.3ae | 10 Gbps | Single | 10 kilometers | 181 | | 10GBASE-ER | 802.3ae | 10 Gbps | Single | 30 kilometers | 182 | 183 | --- 184 | 185 | UTP vs Fiber-Optic Cabling: 186 | 187 | UTP are: 188 | 189 | - Lower cost than fiber-optic. 190 | - Shorter maximum distance than fiber-optic (~100m). 191 | - Can be vulnerable to EMI (Electromagnetic Interference). 192 | - RJ45 ports used with UTP are cheaper than SFP ports. 193 | - Emit (leak) a faint signal outside of cable, which can be copied (security risk). 194 | 195 | Fiber-Optic: 196 | 197 | - Higher cost than UTP. 198 | - Longer maximum distance than UTP. 199 | - No vulnerability to EMI. 200 | - SFP ports are more expensive than RJ45 ports (single-mode is more expensive than multimode). 201 | - Does not emit any signal outside of the cable (no security risk). 202 | -------------------------------------------------------------------------------- /Course_Notes/Intro_to_CLI.md: -------------------------------------------------------------------------------- 1 | # 4. INTRO TO THE CLI 2 | 3 | ### What is a CLI? 4 | 5 | - A "Command-line Interface" 6 | - The interface you use to configure Cisco devices 7 | 8 | A GUI is a "Graphical User Interface" 9 | 10 | ### How do you connect to a Cisco Device? 11 | 12 | - Console Port : When you first configure a device, you have to connect via the Console Port. 13 | 14 | You can use a "Rollover cable" : DB9 serial connector to RJ45 OR a DB9 Serial to USB 15 | 16 | ![image](https://github.com/psaumur/CCNA/assets/106411237/0527c007-d607-4bef-8ce1-7b18a177614d) 17 | 18 | ### How do you actually access the CLI? 19 | 20 | - You need to use a TERMINAL EMULATOR (Example: PuTTy is a popular choice) and connect via "Serial" (default settings) 21 | 22 | ### Cisco Default Settings are: 23 | 24 | Speed (baud) : 9600 bits/second 25 | Data bits: 8 data bits 26 | Stop bits: 1 stop bit (sent after 8 data bits are sent) 27 | Parity: None 28 | Flow Control: None 29 | 30 | --- 31 | 32 | When you first enter the CLI you will DEFAULT be in what is called 'User EXEC' mode. 33 | 34 | USER EXEC MODE: 35 | 36 | (Hostname) > // Prompt looks like THIS // 37 | 38 | - User EXEC mode is very limited. 39 | - User can look at some things but can't make ANY changes to the configuration. 40 | - AKA 'User Mode' 41 | 42 | Using the 'enable' command, in User EXEC mode, switches you to 'Privileged EXEC' mode. 43 | 44 | --- 45 | 46 | PRIVILEGED EXEC MODE: 47 | 48 | - Provides complete access to view the device's configuration, restart the device, etc. 49 | - Cannot change the configuration, but can change the time on the device, save the configuration file, etc. 50 | 51 | (Hostname)# // Prompt looks like THIS // 52 | 53 | --- 54 | 55 | USE a Question Mark (?) to view the available commands in ANY mode. Combining ? with a letter or partial command will list all the commands with those letters. 56 | 57 | ![image](https://github.com/psaumur/CCNA/assets/106411237/52454e6f-d5b1-45f0-9a50-e412d356f6d2) 58 | 59 | 60 | USE the TAB key to complete partially entered commands IF the command exists. 61 | 62 | --- 63 | 64 | ### GLOBAL CONFIGURATION MODE: 65 | 66 | To enter Global Configuration Mode, enter the command, within Privileged EXEC mode 67 | 68 | 'configure terminal' (or 'conf t') 69 | 70 | Router# configure terminal 71 | Router(config) # 72 | 73 | Router(config) # run 74 | 75 | Router(config) # no 76 | 77 | Type 'exit' to drop back into 'Privileged EXEC' mode. 78 | 79 | --- 80 | 81 | ### To Enable Password for User EXEC mode: 82 | 83 | Router(config)# enable password (password) 84 | 85 | - Passwords ARE case-sensitive. 86 | 87 | // This command encrypts plain-text passwords, visible in the config files, using simple encryption. 88 | 89 | Router(config)# service password-encryption 90 | 91 | If you enable 'service password-encryption' 92 | 93 | - Current passwords WILL be encrypted. 94 | - Future passwords WILL be encrypted. 95 | - The 'enable secret' WILL NOT be effected. 96 | 97 | If you disable 'service password-encryption' 98 | 99 | - Current passwords WILL NOT be decrypted. 100 | - Future passwords WILL NOT be encrypted. 101 | - The 'enable secret' WILL NOT be effected. 102 | 103 | // This command enables passwords for the Privileged EXEC mode. 104 | 105 | Router(config)# enable secret (password) 106 | 107 | // enable secret will ALWAYS be encrypted (at level 5) 108 | 109 | --- 110 | 111 | There are TWO separate configuration files kept on the device at once. 112 | 113 | Running-config : 114 | 115 | - The current, ACTIVE configuration file on the device. As you enter commands in the CLI, you edit the active configuration. 116 | 117 | Startup-config : 118 | 119 | - The configuration file that will be loaded upon RESTART of the device. 120 | 121 | To see the configuration files, inside 'Privileged EXEC' mode: 122 | 123 | Router# show running-config // for running config // 124 | 125 | OR 126 | 127 | Router# show startup-config // for startup config // 128 | 129 | --- 130 | 131 | To SAVE the Running configuration file, you can: 132 | 133 | Router# write 134 | Building configuration... 135 | [OK] 136 | 137 | Router# write memory 138 | Building configuration... 139 | [OK] 140 | 141 | Router# copy running-config startup-config 142 | 143 | Destination filename [startup-config]? 144 | 145 | Building configuration... 146 | [OK] 147 | 148 | --- 149 | 150 | To encrypt passwords: 151 | 152 | Router# conf t 153 | 154 | Router(config)# service password-encryption 155 | 156 | This makes all current passwords *encrypted* 157 | 158 | Future passwords will ALSO be *encrypted* 159 | 160 | “Enable secret” will not be effected (it’s ALWAYS encrypted) 161 | 162 | ![image](https://github.com/psaumur/CCNA/assets/106411237/09c841fe-b5c0-4683-9082-baf060e24c03) 163 | 164 | 165 | Now you will see that the password is no longer in plaintext. 166 | 167 | “7” refers to the type of encryption used to encrypt the password. In this case, “7” uses Cisco’s proprietary encryption. 168 | 169 | “7” is fairly easy to crack since the encryption is weak. 170 | 171 | For BETTER / STRONGER encryption, use “enable secret” 172 | 173 | ![image](https://github.com/psaumur/CCNA/assets/106411237/346f3015-9211-47a9-888f-4e02a013a728) 174 | 175 | 176 | “5” refers to MD5 encryption. 177 | 178 | Can still be cracked but it’s much much stronger. 179 | 180 | Once you use “enable secret” command, this will override “enable password” 181 | 182 | --- 183 | 184 | To CANCEL or delete a command you entered, use the “no” keyword 185 | 186 | ![image](https://github.com/psaumur/CCNA/assets/106411237/2978d101-08d4-4ee3-8995-f36aa1c47d15) 187 | 188 | 189 | In this instance, disabling “service password-encryption”: 190 | 191 | - current passwords will NOT be decrypted (unchanged) 192 | - future passwords will NOT be encrypted 193 | - the “enable secret” will not be effected 194 | 195 | --- 196 | 197 | ![image](https://github.com/psaumur/CCNA/assets/106411237/e16966a3-674a-4376-bdab-2c06e3659e5f) 198 | 199 | ![image](https://github.com/psaumur/CCNA/assets/106411237/e449e074-bf4c-40f1-a61e-0442ad83f284) 200 | 201 | ![image](https://github.com/psaumur/CCNA/assets/106411237/4c1bdf58-7de6-4074-8189-1573a174474c) 202 | 203 | ![image](https://github.com/psaumur/CCNA/assets/106411237/e7771e65-5ed5-406d-9751-76520713210c) 204 | 205 | ![image](https://github.com/psaumur/CCNA/assets/106411237/5f7357d4-f44b-4a61-a24c-86f3368f30f7) 206 | -------------------------------------------------------------------------------- /Course_Notes/JSON_XML_YAML.md: -------------------------------------------------------------------------------- 1 | # 60. JSON, XML, AND YAML 2 | 3 | DATA SERIALIZATION 4 | 5 | - DATA SERIALIZATION is the process of converting DATA into a standardized format/structure that can be stored (in a file) or transmitted (over a network) and reconstructed later (ie: by a different application) 6 | - This allows the DATA to be communicated between applications in a way both APPLICATIONS understand. 7 | 8 | - DATA SERIALIZATION languages allow us to represent *variables* with text 9 | 10 | ![image](https://github.com/psaumur/CCNA/assets/106411237/f09eeeba-7779-40c8-af18-f1227bf0cf47) 11 | 12 | --- 13 | 14 | JSON (JAVASCRIPT OBJECT NOTATION) 15 | 16 | - JSON (JAVASCRIPT OBJECT NOTATION) **is an open standard FILE FORMAT and DATA INTERCHANGE FORMAT that uses human-readable text to store and transmit data objects 17 | 18 | - It is standardized in RFC 8259 (https://datatracker.ietf.org/doc/html/rfc8259) 19 | - It was derived from JavaScript, but it is language-independent and many modern programming languages are able to generate and read JSON data 20 | - REST APIs often use JSON 21 | - *Whitespace* is insignificant 22 | 23 | - JSON can represent FOUR “primitive” DATA Types: 24 | - String 25 | - Number 26 | - Boolean 27 | - Null 28 | 29 | - JSON also has TWO “structured” DATA Types: 30 | - Object 31 | - Array 32 | 33 | --- 34 | 35 | JSON PRIMITIVE DATA TYPES: 36 | 37 | - A STRING is a text value. It is surrounded by double quotes “ “ 38 | - “Hello” 39 | - “Five” 40 | - “5” 41 | 42 | - A NUMBER is a numeric value. It is NOT surrounded by quotes 43 | - 5 44 | - 100 45 | 46 | - A BOOLEAN is a DATA Type that has only TWO possible values, not surrounded by quotes 47 | - true 48 | - false 49 | 50 | - A NULL value represents the intentional absence of any object value. It is not surrounded by quotes 51 | - null 52 | 53 | --- 54 | 55 | JSON STRUCTURED DATA TYPES: 56 | 57 | - An OBJECT is an unordered list of *key-value pairs* (variables) 58 | - Sometimes called a DICTIONARY 59 | - OBJECTS are surrounded by curly brackets {} 60 | - The *key* is a STRING 61 | - The *value* is any valid JSON DATA Type (string, number, boolean, null, object, array) 62 | - The *key* and *value* are separated by a colon : 63 | - If there are multiple key-value pairs, each pair is separated by a comma 64 | 65 | ![image](https://github.com/psaumur/CCNA/assets/106411237/24a15571-bb9f-43b4-889f-69f23ffb91bc) 66 | 67 | ![image](https://github.com/psaumur/CCNA/assets/106411237/b66f041d-2449-43f0-8a04-2c0da5391411) 68 | 69 | ![image](https://github.com/psaumur/CCNA/assets/106411237/54d69eed-4369-4ef6-a437-6b5ecce14586) 70 | 71 | - An ARRAY is a series of *values* separated by commas 72 | - Not *key-value pairs* 73 | - The values do NOT have to be the same DATA Type 74 | 75 | ![image](https://github.com/psaumur/CCNA/assets/106411237/3212f472-f966-49e5-9b9a-7bedcfe47487) 76 | 77 | ![image](https://github.com/psaumur/CCNA/assets/106411237/f8075e93-2be7-4b2e-a2af-968961bbc5a7) 78 | 79 | --- 80 | 81 | XML (EXTENSIBLE MARKUP LANGUAGE) 82 | 83 | - XML (EXTENSIBLE MARKUP LANGUAGE) was developed as a MARKUP language, but is now used as a general data serialization language 84 | - Markup languages (ie: HTML) are used to format text (font, size, color, headings, etc) 85 | - XML is generally less human-readable than JSON 86 | - Whitespace is insignificant 87 | - Often used by REST APIs 88 | - value (similar to HTML) 89 | 90 | ![image](https://github.com/psaumur/CCNA/assets/106411237/f954b0ef-f563-4536-94c8-334b6d8f97c6) 91 | 92 | ![image](https://github.com/psaumur/CCNA/assets/106411237/948dae9e-b59b-4607-8e6d-b39837baba70) 93 | 94 | --- 95 | 96 | YAML (YAML AIN’T MARKUP LANGUAGE) 97 | 98 | - YAML originally meant *YET ANOTHER MARKUP LANGUAGE* but to distinguish its purpose as a data-serialization language rather than a markup language, it was repurposed to *YAML AINT MARKUP LANGUAGE* 99 | - YAML is used by the network automation tool ANSIBLE (covered later in the course) 100 | - YAML is VERY Human-Readable 101 | - Whitespace **is significant** (unlike JSON and XML) 102 | - Indentation is very important 103 | - YAML files start with - - - (three dashes) 104 | - - is used to indicate a list 105 | - Keys and Values are represented as key : value 106 | 107 | ![image](https://github.com/psaumur/CCNA/assets/106411237/ecfa3659-4bc3-4596-9f11-10d2644eac1a) 108 | 109 | COMPARISON BETWEEN JSON and YAML using the same DATA 110 | 111 | ![image](https://github.com/psaumur/CCNA/assets/106411237/16e0e98b-5653-4f8a-a388-1706f91a30d4) 112 | -------------------------------------------------------------------------------- /Course_Notes/LAN_Architectures.md: -------------------------------------------------------------------------------- 1 | # 52. LAN ARCHITECTURES 2 | 3 | - You have studied various NETWORK technologies: ROUTING, SWITCHING, STP, ETHERCHANNEL, OSPF, FHRPs, SWITCH SECURITY FEATURES, etc. 4 | - Now, let’s look at some BASIC NETWORK DESIGN / ARCHITECTURE 5 | - There are standard “BEST PRACTICES” for NETWORK DESIGN 6 | - However there are a few UNIVERSAL “CORRECT ANSWERS” 7 | - The answer to MOST general questions about NETWORK DESIGN is “IT DEPENDS” 8 | - In the early stages of your NETWORKING career, you probably won’t be asked to DESIGN NETWORKS yourself 9 | - However, to understand the NETWORKS you will be CONFIGURING and TROUBLESHOOTING, it’s important to know some BASICS of NETWORK DESIGN 10 | 11 | --- 12 | 13 | COMMON TERMINOLOGIES 14 | 15 | - STAR 16 | - When several DEVICES all connect to ONE CENTRAL DEVICE, we can draw them in a “STAR” shape like below, so this is often called a “STAR TOPOLOGY” 17 | 18 | ![image](https://github.com/psaumur/CCNA/assets/106411237/8aeb545d-3cc0-44bf-a01e-b7e5d47deaf2) 19 | 20 | - FULL MESH 21 | - When each DEVICE is connected to each OTHER DEVICE 22 | 23 | ![image](https://github.com/psaumur/CCNA/assets/106411237/cb2d12af-cf17-4ffe-a637-148014d20753) 24 | 25 | - PARTIAL MESH 26 | - When SOME DEVICES are connected to each other but not ALL 27 | 28 | ![image](https://github.com/psaumur/CCNA/assets/106411237/01ed7fe5-317b-45c7-8baa-0cc74e502433) 29 | 30 | --- 31 | 32 | 2-TIER AND 3-TIER LAN ARCHITECTURE 33 | 34 | - The TWO-TIER LAN DESIGN consists of TWO Hierarchical Layers: 35 | - ACCESS LAYER 36 | - DISTRIBUTION LAYER 37 | - Also called a “COLLAPSED CORE” DESIGN because it omits a layer that is found in the THREE TIER DESIGN : THE CORE LAYER 38 | - ACCESS LAYER 39 | - The LAYER that END HOSTS connect to (PCs, Printers, Cameras, etc) 40 | - Typically, ACCESS LAYER SWITCHES have lots of PORTS for END HOSTS to connect to 41 | - QoS MARKING is typically done here 42 | - Security Services like PORT SECURITY, DAI, etc are typically performed here 43 | - SWITCHPORTS might be PoE-Enabled for Wireless APs, IP Phones, etc. 44 | - DISTRIBUTION LAYER 45 | - Aggregates connections from the ACCESS LAYER SWITCHES 46 | - Typically is the border between LAYER 2 and LAYER 3 47 | - Connects to services such as Internet, WAN, etc 48 | - Sometimes called AGGREGATION LAYER 49 | 50 | ![image](https://github.com/psaumur/CCNA/assets/106411237/4592f4d8-5550-4428-923c-c805d2ca476f) 51 | 52 | ![image](https://github.com/psaumur/CCNA/assets/106411237/4fa26aec-536a-4ad8-8f39-e94dacc4cb3c) 53 | 54 | ![image](https://github.com/psaumur/CCNA/assets/106411237/72018e4f-113e-4921-8dc4-05079c590ee1) 55 | 56 | ![image](https://github.com/psaumur/CCNA/assets/106411237/c8326214-80e0-4702-a1c3-6dd2fbafb6e9) 57 | 58 | --- 59 | 60 | THREE-TIER CAMPUS LAN DESIGN 61 | 62 | - In large NETWORKS with many DISTRIBUTION LAYER SWITCHES (for example in separate buildings), the number of connections required between DISTRIBUTION LAYER SWITCHES grows rapidly 63 | 64 | ![image](https://github.com/psaumur/CCNA/assets/106411237/8b94c8e9-813b-40e0-bcd1-b27d73da31e8) 65 | 66 | - To help SCALE large LAN NETWORKS, you can add a CORE LAYER. 67 | 68 | ** Cisco recommends adding a CORE LAYER if there are more than THREE DISTRIBUTION LAYERS in a single location 69 | 70 | ![image](https://github.com/psaumur/CCNA/assets/106411237/d5c1a677-38ff-425f-b91a-65a8fa37c377) 71 | 72 | - The THREE-TIER LAN DESIGN consists of THREE HIERARCHICAL LAYERS: 73 | - ACCESS LAYER 74 | - DISTRIBUTION LAYER 75 | - CORE LAYER 76 | 77 | - CORE LAYER: 78 | - Connects DISTRIBUTION LAYERS together in large LAN NETWORKS 79 | - The focus is SPEED (”FAST TRANSPORT”) 80 | - CPU-INTENSIVE OPERATIONS, such as SECURITY, QoS Markings / Classification, etc. should be avoided at this LAYER 81 | - Connections are all LAYER 3. NO SPANNING-TREE! 82 | - Should maintain connectivity throughout the LAN even if DEVICES FAIL 83 | 84 | ![image](https://github.com/psaumur/CCNA/assets/106411237/633cee0a-8952-4b27-91a3-8653bb8e353c) 85 | 86 | 87 | --- 88 | 89 | SPINE-LEAF ARCHITECTURE (DATA CENTER) 90 | 91 | - CISCO ACI ARCHITECTURE (Application Centric Infrastructure) uses this architecture 92 | - DATA CENTERS are dedicated spaces / buildings used to STORE COMPUTER SYSTEMS such as SERVERS and NETWORK DEVICES 93 | - Traditional DATA CENTER designs used a THREE-TIER ARCHITECTURE (ACCESS-DISTRIBUTION-CORE) like we just covered 94 | - This worked well when most TRAFFIC in the DATA CENTER was NORTH-SOUTH 95 | 96 | ![image](https://github.com/psaumur/CCNA/assets/106411237/7e2ff784-d16f-4606-a186-c73223bf5582) 97 | 98 | - With the precedence of VIRTUAL SERVERS, applications are often deployed in a DISTRIBUTED manner (across multiple physical SERVERS) which increases the amount of EAST-WEST TRAFFIC in the DATA CENTER 99 | - The traditional THREE-TIER ARCHITECTURE led to bottlenecks in the BANDWIDTH as well as VARIABILITY in the SERVER-TO-SERVER latency depending on the PATH the TRAFFIC takes 100 | - To SOLVE this, SPINE-LEAF ARCHITECTURE (also called CLOS ARCHITECTURE) has become prominent in DATA CENTERS 101 | 102 | RULES FOR SPINE-LEAF ARCHITECTURE 103 | 104 | - Every LEAF SWITCH is connected to every SPINE SWITCH 105 | - Every SPINE SWITCH is connected to every LEAF SWITCH 106 | - LEAF SWITCHES do NOT connect to other LEAF SWITCHES 107 | - SPINE SWITCHES do NOT connect to other SPINE SWITCHES 108 | - END HOSTS (Servers, etc) ONLY connect to LEAF SWITCHES 109 | 110 | ![image](https://github.com/psaumur/CCNA/assets/106411237/73cbe190-f589-4307-8ce4-e3de8af2f1d5) 111 | 112 | - The PATH taken by TRAFFIC is randomly chosen to balance the TRAFFIC LOAD among the SPINE SWITCHES 113 | - Each SERVER is separated by the same number of “HOPS” (except those connected to the same LEAF) providing CONSISTENT LATENCY for EAST-WEST TRAFFIC 114 | 115 | --- 116 | 117 | SOHO (SMALL OFFICE / HOME OFFICE) 118 | 119 | - SMALL OFFICE / HOME OFFICE (SOHO) refers to the office of a small company, or a small home office with few DEVICES 120 | - Doesn’t have to be an actual home “office”; if your home has a NETWORK connected to the INTERNET it is considered a SOHO NETWORK 121 | 122 | - SOHO NETWORKS don’t have complex needs, so all NETWORKING functions are typically provided by a SINGLE DEVICE, often called a “HOME ROUTER” or “WIRELESS ROUTER” 123 | - The one DEVICE can serve as a: 124 | - ROUTER 125 | - SWITCH 126 | - FIREWALL 127 | - WIRELESS ACCESS POINT 128 | - MODEM 129 | 130 | ![image](https://github.com/psaumur/CCNA/assets/106411237/c9edf179-f333-4fec-9e95-ee291b5eb84c) 131 | 132 | ![image](https://github.com/psaumur/CCNA/assets/106411237/7d606552-8939-41c1-ad85-13face1d27f5) 133 | -------------------------------------------------------------------------------- /Course_Notes/Life_of_a_Packet.md: -------------------------------------------------------------------------------- 1 | # 12. LIFE OF A PACKET 2 | 3 | ![image](https://github.com/psaumur/CCNA/assets/106411237/ec16b9fd-4d90-4b73-b930-cd825ff13b00) 4 | 5 | 6 | EACH Network device's interfaces have a UNIQUE MAC Addresses. 7 | 8 | In a TCP HEADER 9 | 10 | SOURCE IP ADDRESS comes before DESTINATION IP ADDRESS 11 | 12 | while... 13 | 14 | in an ETHERNET HEADER 15 | 16 | DESTINATION MAC ADDRESS comes before SOURCE MAC ADDRESS 17 | 18 | --- 19 | 20 | ![image](https://github.com/psaumur/CCNA/assets/106411237/5eb94811-32f3-47f6-884e-f45a71456e84) 21 | 22 | 23 | ![image](https://github.com/psaumur/CCNA/assets/106411237/dc0d05cc-9b76-4921-895d-bfbe78ceb0a7) 24 | 25 | 26 | ![image](https://github.com/psaumur/CCNA/assets/106411237/884f7113-21a9-407f-a38e-44489ae3b47e) 27 | 28 | 29 | ![image](https://github.com/psaumur/CCNA/assets/106411237/36459aeb-e802-4347-b626-0c9cc168c624) 30 | 31 | 32 | ![image](https://github.com/psaumur/CCNA/assets/106411237/163bfaf6-15c7-4f7d-9429-4c62a28f0292) 33 | 34 | 35 | ![image](https://github.com/psaumur/CCNA/assets/106411237/1f7e5683-00e6-4ce0-b52a-ca8fdb24c87b) 36 | 37 | 38 | ![image](https://github.com/psaumur/CCNA/assets/106411237/18d04c9d-3734-44e7-995d-b53ab3aaa2a1) 39 | 40 | 41 | ![image](https://github.com/psaumur/CCNA/assets/106411237/07c44007-a208-47a2-a0e8-ca289f86be75) 42 | 43 | 44 | ![image](https://github.com/psaumur/CCNA/assets/106411237/4bcbdba0-234a-4cfa-aa25-cbc3c3c061e1) 45 | 46 | 47 | ![image](https://github.com/psaumur/CCNA/assets/106411237/81c2e8ad-be55-487c-b9da-02540f70b0d9) 48 | 49 | 50 | ![image](https://github.com/psaumur/CCNA/assets/106411237/91cfe407-28b5-48e8-b5f8-a60b324e0706) 51 | 52 | 53 | ![image](https://github.com/psaumur/CCNA/assets/106411237/4bf8c10b-1240-4e7d-8db4-85ea5f3f619f) 54 | 55 | 56 | ![image](https://github.com/psaumur/CCNA/assets/106411237/f938e440-ebdb-444c-b4c7-705d8fd2a4e9) 57 | 58 | 59 | ![image](https://github.com/psaumur/CCNA/assets/106411237/1f236bda-d2cf-4252-af3b-bdc5ec5c2aca) 60 | 61 | 62 | When a HOST sends a packet to another HOST, the SOURCE or DESTINATION IP doesn't change - even though ROUTERS may change the ETHERNET HEADER (SRC/DEST MAC ADDRESSES). 63 | -------------------------------------------------------------------------------- /Course_Notes/NAT_Dynamic_Part2.md: -------------------------------------------------------------------------------- 1 | # 45. NAT (DYNAMIC): PART 2 2 | 3 | MORE ABOUT STATIC NAT 4 | 5 | - STATIC NAT involves statically configuring one-to-one mappings of PRIVATE IP ADDRESSES to PUBLIC IP ADDRESSES 6 | - When traffic from the INTERNAL HOST is sent to the OUTSIDE NETWORK, the ROUTER will translate the SOURCE ADDRESS 7 | 8 | ![image](https://github.com/psaumur/CCNA/assets/106411237/60ba15dd-ee70-4bd9-b9a7-febf3ebbcd10) 9 | 10 | - HOWEVER, this one-to-one mapping also allows EXTERNAL HOSTS to access the INTERNAL HOST via INSIDE GLOBAL ADDRESS 11 | 12 | ![image](https://github.com/psaumur/CCNA/assets/106411237/09de8e06-249c-4185-9d09-ca5fc1435f5a) 13 | 14 | --- 15 | 16 | DYNAMIC NAT 17 | 18 | - In DYNAMIC NAT, the ROUTER dynamically maps INSIDE LOCAL ADDRESSES to INSIDE GLOBAL ADDRESSES, as needed 19 | - An ACL is used to identify WHICH traffic should be translated 20 | - If the SOURCE IP is PERMITTED; the SOURCE IP will be translated 21 | - If the SOURCE IP is DENIED; the SOURCE IP will NOT be translated 22 | 23 | 27 | 28 | - A NAT POOL is used to define the available INSIDE GLOBAL ADDRESS 29 | 30 | ![image](https://github.com/psaumur/CCNA/assets/106411237/98fe2d7d-345c-4d6b-9772-4b152f9bd7a3) 31 | 32 | 33 | 34 | - Although they are dynamically assigned, the mappings are still one-to-one (one INSIDE LOCAL IP ADDRESS per INSIDE GLOBAL IP ADDRESS) 35 | - If there are NOT enough INSIDE GLOBAL IP ADDRESSES available (=ALL are being used), it is called ‘NAT POOL EXHAUSTION’ 36 | - If a PACKET from another INSIDE HOST arrives and needs NAT but there are no AVAILABLE ADDRESSES, the ROUTER will drop the PACKET 37 | - The HOST will be unable to access OUTSIDE NETWORKS until one of the INSIDE GLOBAL IP ADDRESSES becomes available 38 | - DYNAMIC NAT entries will time out automatically if not used, or you can clear them manually 39 | 40 | NAT POOL EXHAUSTION 41 | 42 | ![image](https://github.com/psaumur/CCNA/assets/106411237/59c01575-b42f-475b-9502-2f9ed490ca8d) 43 | 44 | 192.168.0.167 TIMES OUT and 192.168.0.98 is assigned it’s TRANSLATED SOURCE IP 45 | 46 | ![image](https://github.com/psaumur/CCNA/assets/106411237/59e68f3b-8acc-4d7e-8d8e-f930dec3be5f) 47 | 48 | DYNAMIC NAT CONFIGURATION 49 | 50 | ![image](https://github.com/psaumur/CCNA/assets/106411237/6694689a-4880-497c-a1f6-838003810f0c) 51 | 52 | `show ip nat translations` 53 | 54 | ![image](https://github.com/psaumur/CCNA/assets/106411237/5b656147-f61c-4313-9a7e-34bec3ae6fbf) 55 | 56 | ![image](https://github.com/psaumur/CCNA/assets/106411237/04951fde-f130-43f8-b2ce-05eba6382329) 57 | 58 | ![image](https://github.com/psaumur/CCNA/assets/106411237/99bb39f3-2ea7-44d2-929e-223755726882) 59 | 60 | --- 61 | 62 | DYNAMIC PAT (NAT OVERLOAD) 63 | 64 | - PAT (NAT OVERLOAD) translates BOTH the IP ADDRESS and the PORT NUMBER (if necessary) 65 | - By using a unique PORT NUMBER for each communication flow, a single PUBLIC IP ADDRESS can be used by many different INTERNAL HOSTS 66 | - PORT NUMBERS are 16 bits = over 65,000 available port numbers 67 | - The ROUTER will keep track of which INSIDE LOCAL ADDRESS is using which INSIDE GLOBAL ADDRESS and PORT 68 | 69 | ![image](https://github.com/psaumur/CCNA/assets/106411237/8f720b58-9700-4908-bd8d-a1846191854b) 70 | 71 | PAT CONFIGURATION (POOL) 72 | 73 | ![image](https://github.com/psaumur/CCNA/assets/106411237/2a1acc30-658c-4479-9984-9c620b5e6ce3) 74 | 75 | `show ip nat translations` 76 | 77 | ![image](https://github.com/psaumur/CCNA/assets/106411237/088db6f4-a695-4765-b435-2f20a5e16c9e) 78 | 79 | PAT CONFIGURATION (INTERFACE) 80 | 81 | ![image](https://github.com/psaumur/CCNA/assets/106411237/8a3990ff-c58e-44a9-928d-e534f0cff690) 82 | 83 | ![image](https://github.com/psaumur/CCNA/assets/106411237/557d0217-80d2-4423-ba6a-041703568e13) 84 | 85 | `show ip nat translations` 86 | 87 | ![image](https://github.com/psaumur/CCNA/assets/106411237/cae56ec7-38b5-4053-beda-ff670083718e) 88 | 89 | --- 90 | 91 | COMMAND REVIEW 92 | 93 | ![image](https://github.com/psaumur/CCNA/assets/106411237/fe0655bb-4020-4ddc-bec4-b2fb198e2314) 94 | -------------------------------------------------------------------------------- /Course_Notes/NAT_Static_Part1.md: -------------------------------------------------------------------------------- 1 | # 44. NAT (STATIC): PART 1 2 | 3 | PRIVATE IPv4 ADDRESSES (RFC 1918) 4 | 5 | - IPv4 doesn’t provide enough ADDRESSES for all DEVICES that need an IP ADDRESS in the modern world 6 | - The long-term solution is to switch to IPv6 7 | - There are THREE MAIN short-term solutions: 8 | - CIDR 9 | - PRIVATE IPv4 ADDRESS 10 | - NAT 11 | - RFC 1918 specifies the following IPv4 ADDRESS RANGES as PRIVATE: 12 | 13 | ``` 14 | 10.0.0.0 /8 (10.0.0.0 to 10.255.255.255) CLASS A 15 | 172.16.0.0 /12 (172.16.0.0 to 172.31.255.255) CLASS B 16 | 192.168.0.0 /16 (192.168.0.0 to 192.168.255.255) CLASS C 17 | ``` 18 | 19 | - You are free to use these ADDRESSES in your NETWORKS. They don’t have to be GLOBALLY UNIQUE 20 | 21 | ![image](https://github.com/psaumur/CCNA/assets/106411237/c774460a-0479-40ed-ac62-1e9820960943) 22 | 23 | --- 24 | 25 | INTRO TO NAT 26 | 27 | - NETWORK ADDRESS TRANSLATION (NAT) is used to modify the SOURCE and / or DESTINATION IP ADDRESSES of packets 28 | - There are various reasons to use NAT, but the MOST common reason is to ALLOW HOSTS with PRIVATE IP ADDRESSES to communicate with other HOSTS over the INTERNET 29 | - For the CCNA you have to understand SOURCE NAT and how to configure it on CISCO ROUTERS 30 | 31 | ![image](https://github.com/psaumur/CCNA/assets/106411237/11cbc222-4b2d-4283-9a8f-86cfff2e109d) 32 | 33 | --- 34 | 35 | STATIC NAT 36 | 37 | - STATIC NAT involves statically configuring ONE-TO-ONE MAPPINGS of PRIVATE IP ADDRESSES to PUBLIC ADDRESSES 38 | 39 | ![image](https://github.com/psaumur/CCNA/assets/106411237/40867b28-66ff-4182-be97-8495a4c2de23) 40 | 41 | ![image](https://github.com/psaumur/CCNA/assets/106411237/b77177cc-f6e3-434f-87e0-fb5d0fe14c90) 42 | 43 | ![image](https://github.com/psaumur/CCNA/assets/106411237/daac56f4-5af8-482c-9d1d-63a0fb3bdcb1) 44 | 45 | PRIVATE IP CANNOT BE MAPPED TO THE SAME GLOBAL IP 46 | 47 | THE SECOND MAPPING WILL BE REJECTED 48 | 49 | ![image](https://github.com/psaumur/CCNA/assets/106411237/6dceb3c2-39d6-4299-b08d-90cbddb8d6b3) 50 | 51 | --- 52 | 53 | STATIC NAT CONFIGURATIONS 54 | 55 | ![image](https://github.com/psaumur/CCNA/assets/106411237/1b0d6780-56d8-4ea0-870b-abb65d3a6e66) 56 | 57 | ![image](https://github.com/psaumur/CCNA/assets/106411237/add755f6-2d2c-4fe8-aae1-6d1aeecb6ea2) 58 | 59 | Command `clear ip nat translation` 60 | 61 | ![image](https://github.com/psaumur/CCNA/assets/106411237/4266d928-0970-4386-82d7-159cc2b02df6) 62 | 63 | Command `show ip nat statistics` 64 | 65 | ![image](https://github.com/psaumur/CCNA/assets/106411237/2e70576f-3879-4ba6-8ffa-307fd0c243c9) 66 | 67 | --- 68 | 69 | COMMAND REVIEW 70 | 71 | ![image](https://github.com/psaumur/CCNA/assets/106411237/061f4c43-e755-41e8-b8b4-9e31e0723a19) 72 | -------------------------------------------------------------------------------- /Course_Notes/Network_Devices.md: -------------------------------------------------------------------------------- 1 | # 1. NETWORKING DEVICES 2 | 3 | ## What is a network? 4 | 5 | A computer network is a digital telecommunications network allows NODES to share RESOURCES. 6 | 7 | A CLIENT is a device that accesses a service made available by a SERVER. 8 | 9 | A SERVER is a device that provides functions or services for CLIENTS. 10 | 11 | - Note : The same device can be a CLIENT in some situations and a SERVER in other situations. Ex: A Peer-to-Peer network. 12 | 13 | SWITCHES (Level 2): 14 | 15 | - provide connectivity to hosts within the same LAN (Local Area Network) 16 | - Have many network interfaces/ports for End Hosts to connect to. 17 | - DO NOT provide connectivity between LANs/over the Internet. 18 | 19 | ROUTERS (Level 3): 20 | 21 | - have fewer network interfaces than switches. 22 | - are used to provide connectivity BETWEEN LANs. 23 | - are used to send data over the Internet. 24 | 25 | FIREWALL (Can be Level 3,4, and 7): 26 | 27 | - Firewalls are specialty hardware network security devices that control network traffic entering/exiting your network. 28 | - Can be places "inside" or "outside" the network. 29 | - Monitor and control network traffic based on configured rules. 30 | - Are known as "Next-Generation Firewalls" when they include more modern and advanced filtering capabilities. 31 | - Host-based firewalls are software applications that filter traffic entering and exiting a host machine, like a PC. 32 | -------------------------------------------------------------------------------- /Course_Notes/OSI_Model_TCPSuite.md: -------------------------------------------------------------------------------- 1 | # 3. OSI MODEL & TCP/IP SUITE 2 | 3 | ## What is a networking model? 4 | 5 | Networking models categorize and provide a structure for networking protocols and standards. 6 | 7 | (Protocols are a set of logical rules defining how network devices and software should work) 8 | 9 | ## OSI MODEL 10 | 11 | - Open Systems Interconnection Model 12 | - Conceptual model that categorizes and standardizes the different functions in a network. 13 | - Created by the "International Organization for Standardization" (ISO) 14 | - Functions are divided into 7 "Layers" 15 | - These layers work together to make the network work. 16 | 17 | ![image](https://github.com/psaumur/CCNA/assets/106411237/bbf46de2-e025-4ddd-b52b-614b280598da) 18 | 19 | As data moves from the top layer, downward, the process is called “encapsulation” 20 | 21 | As data moves from the bottom layer, upward, the process is called “de-encapsulation” 22 | 23 | When interactions occur on the same layer, it’s called “same-layer interaction” 24 | 25 | ![image](https://github.com/psaumur/CCNA/assets/106411237/b7cf4900-993c-49f0-b6ea-70f4f0719633) 26 | 27 | Mnemonic to help remember the Data Layer Names / Order 28 | 29 | ![image](https://github.com/psaumur/CCNA/assets/106411237/01f532f6-b636-4b7c-99d0-a67f7e483a99) 30 | 31 | 32 | ### The layers are : 33 | 34 | ### 7 - APPLICATION 35 | 36 | - This Layer is closest to end user. 37 | - Interacts with software applications. 38 | - HTTP and HTTPS are Layer 7 protocols 39 | 40 | Functions of Layer 7 include: 41 | 42 | - Identifying communication partners 43 | - Synchronizing communication 44 | 45 | --- 46 | 47 | ### 6 - PRESENTATION 48 | 49 | - Translates data to the appropriate format (between Application and Network formats) to be sent over the network. 50 | 51 | --- 52 | 53 | ### 5 - SESSION 54 | 55 | - Controls dialogues (sessions) between communicating hosts. 56 | - Establishes, manages, and terminates connections between local application and the remote application. 57 | 58 | --- 59 | 60 | Network engineers don't usually work with the top 3 layers. 61 | Application developers work with the top layers of the OSI model to connect their applications over networks. 62 | 63 | --- 64 | 65 | ### 4 - TRANSPORT 66 | 67 | - Segments and reassembles data for communication between end hosts. 68 | - Breaks large pieces of data into smaller segments which can be more easily sent over the network and are less likely to cause transmission problems if errors occur. 69 | - Provides HOST-TO-HOST (end to end) communication 70 | 71 | When Data from Layer 7-5 arrives, it receives a Layer 4 Header in the Transport layer. 72 | 73 | << DATA + L4 Header >> 74 | 75 | This is called a SEGMENT. 76 | 77 | --- 78 | 79 | ### 3 - NETWORK 80 | 81 | - Provides connectivity between end hosts on different networks (ie: outside of the LAN). 82 | - Provides logical addressing (IP Addresses). 83 | - Provides path selection between source and destination 84 | - **ROUTERS** operate at Layer 3. 85 | 86 | When Data and the Layer 4 Header arrive in the Network Layer, it receives a Layer 3 Header. 87 | 88 | << DATA + L4 Header + L3 Header >> 89 | 90 | This is called a **PACKET**. 91 | 92 | --- 93 | 94 | ### 2 - DATA LINK 95 | 96 | - Provides NODE-TO-NODE connectivity and data transfer (for example, PC to Switch, Switch to Router, Router to Router) 97 | - Defines how data is formatted for transmission over physical medium (for example, copper UTP cables) 98 | - Detects and (possibly) corrects Physical (Layer 1) errors. 99 | - Uses Layer 2 addressing, separate from Layer 3 addressing. 100 | - **SWITCHES** operate at Layer 2 101 | 102 | When the Layer 3 Packet arrives, a Layer 2 Trailer and Header are added. 103 | 104 | << L2 Trailer + DATA + L4 Header + L3 Header + L2 Header >> 105 | 106 | This is called a FRAME. 107 | 108 | All the steps leading up to transmission is called ENCAPSULATION. 109 | When the frame is sent to the receiver, it then goes through the reverse process, DE-ENCAPSULATION, stripping off layers while travelling from OSI Layer 1 to Layer 7. 110 | 111 | --- 112 | 113 | ### 1 - PHYSICAL 114 | 115 | - Defines physical characteristics of the medium used to transfer data between devices. For example : voltage levels, maximum transmission distances, physical connectors, cable specs. 116 | - Digital bits are converted into electrical (for wired connections) or radio (for wireless connections) signals. 117 | - All of the information in SECTION 2 (NETWORKING DEVICES) is related to the Physical Layer 118 | 119 | --- 120 | 121 | ### OSI MODEL - PDU's 122 | 123 | ![image](https://github.com/psaumur/CCNA/assets/106411237/9b885a51-91cd-4fe6-b1be-e7fa7aa220b5) 124 | 125 | A PDU is a Protocol Data Unit. Each step of the process is a PDU. 126 | 127 | | OSI LAYER # | PDU NAME | PROTOCOL DATA ADDED | 128 | | --- | --- | --- | 129 | | 7-5 | DATA | Data | 130 | | 4 | SEGMENT | Layer 4 Header Added | 131 | | 3 | PACKET | Layer 3 Header Added | 132 | | 2 | FRAME | Layer 2 Trailer and Header Added | 133 | | 1 | BIT | 0s and 1s Transmission | 134 | 135 | << L2 Trailer + DATA + L4 Header + L3 Header + L2 Header >> 136 | 137 | --- 138 | 139 | ### TCP/IP Suite 140 | 141 | - Conceptual model and set of communications protocols used in the Internet and other networks. 142 | - Known as TCP/IP because those are two of the foundational protocols in the suite. 143 | - Developed by the US Dept. of Defense through DARPA (Defense Advanced Research Projects Agency). 144 | - Similar structure to the OSI Model, but fewer layers. 145 | - THIS is the model actually in use in modern networks. 146 | - * Note : The OSI Model still influences how network engineers think and talk about networks. 147 | 148 | ![image](https://github.com/psaumur/CCNA/assets/106411237/e9593c06-46a3-4ff9-aa01-863e0aeb5df3) 149 | 150 | 151 | --- 152 | 153 | ### Layer Interactions 154 | 155 | ![image](https://github.com/psaumur/CCNA/assets/106411237/372c45a0-bb3e-4342-af2b-79d3606384ec) 156 | 157 | 158 | Adjacent-Layer Interactions: 159 | 160 | - Interactions between different layers of the OSI Model on same host. 161 | 162 | Example: 163 | 164 | Layers 5-7 sending Data to Layer 4, which then adds a Layer 4 header (creating a SEGMENT). 165 | 166 | Same-Layer Interactions: 167 | 168 | - Interactions between the same Layer on different hosts. 169 | - The concept of Same-Layer interaction allows you to ignore the other layers involved and focus on the interactions between a single layer on different devices. 170 | 171 | Example: 172 | 173 | The Application Layer of YouTube's web server and your PC's browser. 174 | -------------------------------------------------------------------------------- /Course_Notes/OSPF_Part1.md: -------------------------------------------------------------------------------- 1 | # 26. OSPF : PART 1 (IGP : LINK STATE) 2 | 3 | ![image](https://github.com/psaumur/CCNA/assets/106411237/f58477d1-f574-4195-8f6c-851823dedfbf) 4 | 5 | LINK STATE ROUTING PROTOCOLS 6 | 7 | - When using a LINK STATE ROUTING PROTOCOL, every ROUTER creates a ‘connectivity map’ of the NETWORK 8 | - To allow this, each ROUTER ADVERTISES information about its INTERFACES (connected NETWORKS) to its NEIGHBOURS. These ADVERTISEMENTS are passed along to the other ROUTERS, until all ROUTERS in the NETWORK develop the same map of the NETWORK 9 | - Each ROUTER independently uses this MAP to calculate the BEST ROUTES to each DESTINATION 10 | - LINK STATE PROTOCOLS use more resources (CPU) on the ROUTER, because MORE information is shared. 11 | - However, LINK STATE PROTOCOLS tend to be FASTER in reacting to CHANGES in the NETWORK than DISTANCES VECTOR PROTOCOLS 12 | 13 | --- 14 | 15 | BASIC OSPF OPERATIONS 16 | 17 | - Stands for **Open Shortest Path First** 18 | - Uses the **Shortest Path First** algorithm 19 | - Created by Dutch comp. scientist - Edsger Dijkstra 20 | - aka **Dijkstra’s Algorithm** (Could be Exam Question) 21 | 22 | THREE Versions: 23 | 24 | - OSPFv1 (1989) : OLD, not in use anymore 25 | - OSPFv2 (1998) : Used for IPv4 26 | - OSPFv3 (2008) : Used for IPv6 (can be used for IPv4, but v2 is usually used) 27 | 28 | - Routers store information about the NETWORK in LSAs (Link State Advertisements), which are organized in a structure called the LSDB (Link State Database) 29 | - Routers will **FLOOD** LSAs until all ROUTERS in the OSPF *area* develop the same map of the network (LSDB) 30 | 31 | ![image](https://github.com/psaumur/CCNA/assets/106411237/2a6a126b-74f1-49e2-96be-fc411c8812fd) 32 | 33 | 💡 LSA’s have an AGING TIMER of 30 Minutes, by Default). The LSA will be FLOODED again after the timer expires 34 | 35 | In OSPF, there are THREE MAIN STEPS in the process of sharing LSAs and determining the BEST ROUTE to each DESTINATION in the network 36 | 37 | 1) **BECOME NEIGHBORS** with other ROUTERS connected to same SEGMENT 38 | 39 | 2) **EXCHANGE LSAs** with neighbor ROUTERS 40 | 41 | 3) **CALCULATE THE BEST ROUTES** to each DESTINATION, and insert them into the ROUTING TABLE 42 | 43 | --- 44 | 45 | OSPF AREAS 46 | 47 | - OSPF uses **AREAS** to divide up the NETWORK 48 | - SMALL NETWORKS can be *single-area* without any negative effects on performance 49 | - LARGE NETWORKS, *single-area* design can have NEGATIVE effects: 50 | - SPF ALGORITHM takes more time to calculate ROUTES 51 | - SPF ALGORITHM requires exponentially more processing power on ROUTERS 52 | - Larger LSDB takes up more MEMORY on ROUTERS 53 | - Small changes in NETWORK cause every ROUTER to FLOOD LSAs and run the SPF algorithm again 54 | - By dividing up a large OSPF NETWORK into several SMALLER ***areas***, you can avoid the above NEGATIVE effects (sounds similar to VLANs re: broadcast domains) 55 | 56 | WHAT IS AN OSPF AREA? 57 | 58 | ![image](https://github.com/psaumur/CCNA/assets/106411237/0f5084fe-f7fb-4b33-a8d0-2ed0155d7502) 59 | 60 | - An **AREA is** a set of ROUTERS and LINKS that share the same LSDB 61 | - The **BACKBONE AREA** (Area 0) is an AREA that all other AREAS must connect to 62 | - ROUTERS with ALL INTERFACES in the SAME AREA are called INTERNAL ROUTERS 63 | - ROUTERS with INTERFACES in MULTIPLE AREAS are called **AREA BORDER ROUTERS** (ABRs) 64 | 65 | 66 | 💡 ABRs maintain a SEPARATE LSDB for each AREA they are connected to. 67 | 68 | 💡 It is recommended that you connect an ABR to a MAXIMUM of TWO AREAS. 69 | 70 | 💡 Connecting an ABR to 3+ AREAS can overburden the ROUTER 71 | 72 | - ROUTERS connected to the BACKBONE AREA (Area 0) are called **BACKBONE ROUTERS** 73 | - An **INTRA-AREA ROUTE** is a ROUTE to a DESTINATION inside the same OSPF AREA 74 | - An INTER-AREA ROUTE is a ROUTE to a DESTINATION in a DIFFERENT OSPF AREA 75 | 76 | --- 77 | 78 | OSPF RULES 79 | 80 | - OSPF AREAS should be CONTIGUOUS (no split AREAS) 81 | - All OSPF AREAS must have *at least* ONE ABR connected to the BACKBONE AREA 82 | - OSPF INTERFACES in the SAME SUBNET *must* be in the SAME AREA 83 | 84 | --- 85 | BASIC OSPF CONFIGURATION 86 | 87 | OSPF AREA 0 88 | 89 | ![image](https://github.com/psaumur/CCNA/assets/106411237/ad9648f4-736a-43b5-96de-8a30f6f800c8) 90 | 91 | Commands for configuring an OSPF 92 | 93 | ![image](https://github.com/psaumur/CCNA/assets/106411237/38fcce32-8d15-4db0-9a0c-170d6083a534) 94 | 95 | - The OSPF **Process ID** is **locally significant.** ROUTERS with different Process IDs can become OSPF Neighbors 96 | - The OSPF “network” command requires you to specify the AREA (in this case, it’s “area 0”) 97 | - For the CCNA, you only need to configure single-area OSPF (AREA 0) 98 | 99 | The “network” command tells OSPF to: 100 | 101 | - Look for ANY INTERFACES with an IP ADDRESS contained in the RANGE specified in the “network” command 102 | - Activate OSPF on the INTERFACE in the specified AREA 103 | - The ROUTER will then try to become OSPF neighbors with other OSPF-Activated neighbor ROUTERS 104 | 105 | ![image](https://github.com/psaumur/CCNA/assets/106411237/41da3fe8-f24a-468c-beeb-91cc12066c70) 106 | 107 | - Know this command from RIP and EIGRP 108 | - The “passive-interface” command tells the ROUTERS to stop sending OSFP ‘hello’ messages out of the INTERFACE 109 | - However, the ROUTER will continue to send LSA’s informing it’s neighbors about the SUBNET configured on the INTERFACE 110 | - You should ALWAYS USE this command on neighbors which don’t have any OSPF neighbors 111 | 112 | ![image](https://github.com/psaumur/CCNA/assets/106411237/a0422f88-dbd9-4965-8c73-16cfd438b05e) 113 | 114 | ![image](https://github.com/psaumur/CCNA/assets/106411237/aaa1daaa-8ab7-441a-bec2-9f0391a82ecc) 115 | 116 | “show ip protocols” 117 | 118 | ![image](https://github.com/psaumur/CCNA/assets/106411237/f02c3838-c9ad-4836-8c89-ecad42e205b2) 119 | 120 | NOTE the "no" in square brackets - this indicates this is the DEFAULT choice 121 | 122 | ![image](https://github.com/psaumur/CCNA/assets/106411237/c222d290-4d10-4e63-b7d5-8317ae5ccdfc) 123 | 124 | DISTANCE (AD) for OSPF is 110 (DEFAULT) but can be changed with the “distance” command 125 | 126 | ![image](https://github.com/psaumur/CCNA/assets/106411237/849a7fd3-457e-4310-be08-b4c8b4c8a8a2) 127 | -------------------------------------------------------------------------------- /Course_Notes/Port_Security.md: -------------------------------------------------------------------------------- 1 | # 49. PORT SECURITY 2 | 3 | INTRO TO PORT SECURITY 4 | 5 | - PORT SECURITY is a security feature of Cisco SWITCHES 6 | - It allows you to control WHICH SOURCE MAC ADDRESS(ES) are allowed to enter the SWITCHPORT 7 | - If an unauthorized SOURCE MAC ADDRESS enters the PORT, an ACTION will be TAKEN 8 | - The DEFAULT action is to place the INTERFACE in an “err-disabled” state 9 | 10 | ![image](https://github.com/psaumur/CCNA/assets/106411237/92f4ce9b-8fb4-4d57-b200-f41c7d5236ee) 11 | 12 | - When you enable PORT SECURITY on an INTERFACE with the DEFAULT settings, one MAC ADDRESS is allowed 13 | - You can configure the ALLOWED MAC ADDRESS manually 14 | - If you DO NOT configure it manually, the SWITCH will allow the first SOURCE MAC ADDRESS that enters the INTERFACE 15 | - You can CHANGE the MAXIMUM number of MAC ADDRESSES allowed 16 | - A COMBINATION of manually configured MAC ADDRESSES and DYNAMICALLY LEARNED ADDRESSES is possible 17 | 18 | ![image](https://github.com/psaumur/CCNA/assets/106411237/0b6e8053-6819-4e02-ae28-4699a5c9c92d) 19 | 20 | --- 21 | 22 | WHY USE PORT SECURITY? 23 | 24 | - PORT SECURITY allows NETWORK admins to control which DEVICES are allowed to access the NETWORK 25 | - However, MAC ADDRESS SPOOFING is a simple task 26 | - It is easy to configure a DEVICE to send FRAMES with a different SOURCE MAC ADDRESS 27 | - Rather than manually specifying the MAC ADDRESSES allowed on each PORT, PORT SECURITY’S ability to limit the number of MAC ADDRESSES allowed on an INTERFACE is more useful 28 | - Think of the DHCP STARVATION ATTACK (DAY 48 LAB video) 29 | - The ATTACKER spoofed thousands of fake MAC ADDRESSES 30 | - The DHCP SERVER assigned IP ADDRESSES to these fake MAC ADDRESSES, exhausting the DHCP POOL 31 | - The SWITCH’S MAC ADDRESS table can also become full due to such an attack 32 | - Limiting the NUMBER of MAC ADDRESSES on an INTERFACE can protect against those attacks 33 | 34 | ENABLING PORT SECURITY 35 | 36 | ![image](https://github.com/psaumur/CCNA/assets/106411237/b00765c2-f3a1-45be-8ed4-0a8dab68e43e) 37 | 38 | `show port-security interface` 39 | 40 | ![image](https://github.com/psaumur/CCNA/assets/106411237/787959b1-ffad-451d-ac65-11ea9a99db2d) 41 | 42 | ![image](https://github.com/psaumur/CCNA/assets/106411237/9a6dd39d-130e-411b-be46-ecfe93420813) 43 | 44 | ![image](https://github.com/psaumur/CCNA/assets/106411237/f071f447-a6ef-4ee6-8a40-2bde94030993) 45 | 46 | RE-ENABLING AN INTERFACE (MANUALLY) 47 | 48 | ![image](https://github.com/psaumur/CCNA/assets/106411237/706736d4-ee7c-42b2-b424-6cc30eb50905) 49 | 50 | RE-ENABLING AN INTERFACE (ERR-DISABLE RECOVERY) 51 | 52 | ![image](https://github.com/psaumur/CCNA/assets/106411237/6eb0d808-a989-4261-9b39-1ac9e1bf1460) 53 | 54 | ![image](https://github.com/psaumur/CCNA/assets/106411237/41d54ef0-7391-473e-9b51-87f44b9e3f3c) 55 | 56 | --- 57 | 58 | VIOLATION MODES 59 | 60 | - There are THREE DIFFERENT VIOLATION MODES that determine what the SWITCH will do if an unauthorized FRAME enters an INTERFACE configured with PORT SECURITY 61 | - SHUTDOWN 62 | - Effectively shuts down the PORT by placing it in an ‘err-disabled` state 63 | - Generates a SYSLOG and / or SNMP message when the INTERFACE is ‘disabled’ 64 | - The VIOLATION counter is set to 1 when the INTERFACE is ‘disabled’ 65 | - RESTRICT 66 | - The SWITCH discards traffic from unauthorized MAC ADDRESSES 67 | - The INTERFACE is NOT disabled 68 | - Generates a SYSLOG and / or SNMP message each time an unauthorized MAC is detected 69 | - The VIOLATION counter is incremented by 1 for each unauthorized FRAME 70 | 71 | - PROTECT 72 | - The SWITCH discards traffic from unauthorized MAC ADDRESSES 73 | - The INTERFACE is NOT disabled 74 | - It does NOT generate a SYSLOG / SNMP message for unauthorized traffic 75 | - It does NOT increment the VIOLATION counter 76 | 77 | --- 78 | 79 | VIOLATION MODE - RESTRICT 80 | 81 | ![image](https://github.com/psaumur/CCNA/assets/106411237/819f00b9-9694-442d-8459-8018f4277e45) 82 | 83 | 84 | VIOLATION MODE - PROTECT 85 | 86 | ![image](https://github.com/psaumur/CCNA/assets/106411237/20d17f97-056e-4e76-8566-bb49c10bb9e1) 87 | 88 | --- 89 | 90 | SECURE MAC ADDRESS AGING 91 | 92 | ![image](https://github.com/psaumur/CCNA/assets/106411237/4454fedf-f942-4b0d-9b6f-074765de653d) 93 | 94 | - By DEFAULT, SECURE MAC ADDRESSES will not ‘age out’ (Aging Time : 0 mins) 95 | - Can be configured with `switchport port-security aging time *minutes*` 96 | 97 | - The DEFAULT Aging Type is ABSOLUTE 98 | - ABSOLUTE 99 | - After the SECURE MAC ADDRESS is learned, the AGING TIMER starts and the MAC is removed after the TIMER expires, even if the SWITCH continues receiving FRAMES from that SOURCE MAC ADDRESS. 100 | - INACTIVITY 101 | - After the SECURE MAC ADDRESS is learned, the AGING TIMER starts but is RESET every time a FRAME from that SOURCE MAC ADDRESS is received on the INTERFACE 102 | - Aging type is configured with: `switchport port-security aging type {absolute | inactivity}` 103 | - Secure Static MAC AGING (address configured with `switchport port-security mac-address x.x.x`) is DISABLED by DEFAULT 104 | 105 | ![image](https://github.com/psaumur/CCNA/assets/106411237/93f11517-9d97-4e52-89ad-a0e590bca702) 106 | 107 | --- 108 | 109 | STICKY SECURE MAC ADDRESSES 110 | 111 | - ‘STICKY’ SECURE MAC ADDRESS learning can be enabled with the following command: 112 | - `SW(config-if)# switchport port-security mac-address sticky` 113 | 114 | - When enabled, dynamically-learned SECURE MAC ADDRESSES will be added to the running configuration, like this: 115 | - `switchport port-security mac-address sticky *mac-address*` 116 | 117 | - The ‘STICKY’ SECURE MAC ADDRESSES will NEVER age out 118 | - You need to SAVE the `running-config` to `startup-config` to make them TRULY permanent (or else they will not be kept if the SWITCH restarts) 119 | - When you issue the `switchport port-security mac-address sticky` command, all current dynamically-learned secure MAC addresses will be converted to STICKY SECURE MAC ADDRESSES 120 | - If you issue the `no switchport port-security mac-address sticky` command, all current STICKY SECURE MAC ADDRESSES will be converted to regular dynamically-learned SECURE MAC ADDRESSES 121 | 122 | ![image](https://github.com/psaumur/CCNA/assets/106411237/10d591f9-334c-4e3b-889e-16030c36c445) 123 | 124 | --- 125 | 126 | MAC ADDRESS TABLE 127 | 128 | - SECURE MAC ADDRESSES will be added to the MAC ADDRESS TABLE like any other MAC ADDRESS 129 | - STICKY and STATIC SECURE MAC ADDRESSES will have a type of STATIC 130 | - Dynamically-Learned SECURE MAC ADDRESSES will have a type of DYNAMIC 131 | - You can view all SECURE MAC ADDRESSES with `show mac address-table secure` 132 | 133 | 134 | ![image](https://github.com/psaumur/CCNA/assets/106411237/c9123729-541c-4363-ba19-d8e49f75c6c5) 135 | 136 | --- 137 | 138 | COMMAND REVIEW 139 | 140 | ![image](https://github.com/psaumur/CCNA/assets/106411237/716ce91d-d1bb-4f12-a8fd-226b65f22569) 141 | -------------------------------------------------------------------------------- /Course_Notes/QoS_VoiceLan.md: -------------------------------------------------------------------------------- 1 | # 46. QoS (Voice VLANs) : PART 1 2 | 3 | IP PHONES / VOICE LANS 4 | 5 | - Traditional phones operate over the *public switched telephone network* (PSTN) 6 | - Sometimes, this is called POTS (Plain Old Telephone System) 7 | - IP PHONES use VoIP (Voice Over IP) technologies to enable phone calls over an IP NETWORK, such as the INTERNET 8 | - IP PHONES are connected to a SWITCH, just like any other end HOST 9 | 10 | IP PHONES 11 | 12 | - Have an internal 3-PORT SWITCH 13 | - 1 PORT is the “UPLINK” to the EXTERNAL SWITCH 14 | - 1 PORT is the “DOWNLINK” to the PC 15 | - 1 PORT connects internally to the PHONE itself 16 | 17 | ![image](https://github.com/psaumur/CCNA/assets/106411237/0bba51c0-af57-49e4-ae29-fca2a1079a34) 18 | 19 | - This allows the PC and the IP PHONE to share a single SWITCH PORT. Traffic from the PC passes through the IP PHONE to the SWITCH 20 | - It is RECOMMENDED to separate “VOICE” traffic (from IP PHONE) and “DATA TRAFFIC” (from the PC) by placing them into SEPARATE VLANS (!) 21 | - This can be accomplished using a VOICE VLAN 22 | - Traffic from the PC will be UNTAGGED - but traffic from the PHONE will be tagged with a VLAN ID 23 | 24 | ![image](https://github.com/psaumur/CCNA/assets/106411237/12a1bfa5-036a-4eb6-b165-23fc8209a1f8) 25 | 26 | ![image](https://github.com/psaumur/CCNA/assets/106411237/b7c5b7e6-fa79-4405-b72f-b609ab56f216) 27 | 28 | ![image](https://github.com/psaumur/CCNA/assets/106411237/fc26e9dd-e19e-43cc-9f2a-4022b47f98b4) 29 | 30 | --- 31 | 32 | POWER OVER ETHERNET (PoE) 33 | 34 | - PoE allows Power Sourcing Equipment (PSE) to provide POWER to Powered Devices (PD) over an ETHERNET cable 35 | - Typically, the PSE is a SWITCH and the PDs are IP PHONES, IP CAMERAS, WIRELESS ACCESS POINTS, etc. 36 | - The PSE receives AC POWER from the outlet, converts it to DC POWER, and supplies that DC POWER to the PDs 37 | 38 | ![image](https://github.com/psaumur/CCNA/assets/106411237/4229e398-a50e-487c-adf3-66b235ea9189) 39 | 40 | - TOO much electrical current can damage electrical DEVICES 41 | - PoE has a process to determine if a CONNECTED DEVICE needs power and how much it needs. 42 | - When a DEVICE is connected to a PoE-Enabled PORT, the PSE (SWITCH) sends LOW POWER SIGNALS, monitors the response, and determines how much power the PD needs 43 | - If the DEVICE needs POWER, the PSE supplies the POWER to allow the PD to boot 44 | - The PSE continues to monitor the PD and SUPPLY the required amount of POWER (but not too much!) 45 | - *POWER POLICING* can be configured to prevent a PD from taking TOO much POWER 46 | - 'power inline police' configures power policing with the default settings: disable the PORT and send a SYSLOG message if a PD draws too much power 47 | - Equivalent to 'power inline police action err-disable' 48 | - The INTERFACE will be put in an ‘error-disabled’ state and can be re-enabled with 'shutdown' followed by 'no shutdown' 49 | 50 | ![image](https://github.com/psaumur/CCNA/assets/106411237/59914c0d-2c0e-4952-a4af-1f7ada02002d) 51 | - 'power inline police action log' does NOT shut down the INTERFACE if the PD draws too much power. It WILL restart the INTERFACE and send a SYSLOG message 52 | 53 | ![image](https://github.com/psaumur/CCNA/assets/106411237/9717fb1e-9129-41f9-90bb-613c2bdee460) 54 | 55 | ![image](https://github.com/psaumur/CCNA/assets/106411237/8fe2eb15-49be-4f63-9f6f-79c0d5fe052f) 56 | 57 | 58 | --- 59 | 60 | INTRO TO QUALITY OF SERVICE (QoS) 61 | 62 | - VOICE traffic and DATA traffic used to use entirely separate NETWORKS 63 | - VOICE TRAFFIC used the PSTN 64 | - DATA TRAFFIC used the IP NETWORK (Enterprise WAN, Internet, etc) 65 | - QoS wasn’t necessary as the different kinds of TRAFFIC didn’t compete for BANDWIDTH 66 | 67 | ![image](https://github.com/psaumur/CCNA/assets/106411237/8a21a767-5a93-42bd-a8d4-52453f8a7341) 68 | 69 | - Modern NETWORKS are typically *converged networks* in which IP PHONES, VIDEO TRAFFIC, REGULAR TRAFFIC, etc. all share the same IP NETWORK 70 | - This enables COST SAVINGS as well as more ADVANCED FEATURES for VOICE and VIDEO TRAFFIC (Example : Collaboration Software like Cisco WebEx, MS Teams, etc) 71 | - HOWEVER, the different kinds of TRAFFIC now have to compete for BANDWIDTH 72 | - **QoS** is a set of TOOLS used by NETWORK DEVICES to apply different TREATMENT to different PACKETS 73 | 74 | ![image](https://github.com/psaumur/CCNA/assets/106411237/8909efdb-bbbd-4f50-b412-7abe12a3bcef) 75 | 76 | QUALITY OF SERVICE (QoS) 77 | 78 | - QoS is used to manage the following characteristics of NETWORK TRAFFIC 79 | - BANDWIDTH 80 | - Overall CAPACITY of the LINK (measured in *bits per second*) 81 | - QoS TOOLS allow you to RESERVE a certain amount of a link’s BANDWIDTH for specific kinds of traffic 82 | - DELAY 83 | - One-Way Delay = Time it takes traffic to go from SOURCE to DESTINATION 84 | - Two-Way Delay = Time it takes traffic to go from SOURCE to DESTINATION and return 85 | 86 | ![image](https://github.com/psaumur/CCNA/assets/106411237/29ed6306-a6aa-46ba-af2f-5ebcd383d1d7) 87 | 88 | 89 | - JITTER 90 | - The variation in ONE-WAY DELAY between PACKETS SENT by the same APPLICATION 91 | - IP PHONES have a ‘jitter buffer’ to provide a FIXED DELAY to audio PACKETS 92 | - LOSS 93 | - The % of PACKETS sent that DO NOT reach their DESTINATION 94 | - Can be caused by FAULTY CABLES 95 | - Can also be caused when a DEVICE’S PACKET QUEUES get full and the DEVICE starts discarding PACKETS 96 | 97 | - The FOLLOWING STANDARDS are recommended for ACCEPTABLE INTERACTIVE AUDIO quality: 98 | - ONE-WAY DELAY : 150 milliseconds or less 99 | - JITTER : 30 milliseconds or less 100 | - LOSS : 1% or less 101 | 102 | - If these STANDARDS are not met, there could be a noticeable reduction in the QUALITY of the phone call 103 | 104 | 105 | 106 | QoS QUEUING 107 | 108 | - If a NETWORK DEVICE receives messages FASTER than it can FORWARD them out of the appropriate INTERFACE, the MESSAGES are placed in the QUEUE 109 | - By default, the QUEUED MESSAGES will be FORWARDED in a FIRST IN FIRST OUT (FIFO) manner 110 | - Message will be SENT in the ORDER they are RECEIVED 111 | - If the QUEUE is FULL, new PACKETS will be DROPPED 112 | - The is called *tail drop* 113 | 114 | ![image](https://github.com/psaumur/CCNA/assets/106411237/15de2fcd-5711-4014-8185-9975b2ce8a0d) 115 | 116 | - TAIL DROP is harmful because it can lead to TCP GLOBAL SYNCHRONIZATION 117 | 118 | ![image](https://github.com/psaumur/CCNA/assets/106411237/1d22afa7-91aa-4e86-9c5f-ad9506dcb44c) 119 | 120 | - When the QUEUE fills UP and TAIL DROP occurs, ALL TCP HOSTS sending traffic will SLOW DOWN the rate at which they SEND TRAFFIC 121 | - They will ALL then INCREASE the RATE at which they send TRAFFIC, which rapidly leads to MORE CONGESTION, dropped PACKETS, and the process REPEATS… 122 | 123 | ![image](https://github.com/psaumur/CCNA/assets/106411237/b75c2cac-043c-4df6-a1d6-f26d9110630a) 124 | 125 | - A SOLUTION to prevent TAIL DROP and TCP GLOBAL SYNCHRONIZATION is RANDOM EARLY DETECTION (RED) 126 | 127 | - When the amount of TRAFFIC in the QUEUE reaches a certain THRESHOLD, the DEVICE will start RANDOMLY dropping PACKETS from select TCP FLOWS 128 | - Those TCP FLOWS that dropped PACKETS will reduce the RATE at which TRAFFIC is sent, but you will avoid TCP GLOBAL SYNCHRONIZATION, in which ALL TCP FLOWS reduce and then increase the rate of transmission at the same time, in waves. 129 | - In STANDARD RED, all kinds of TRAFFIC are treated the SAME 130 | - WEIGHTED RANDOM EARLY DETECTION (WRED) - an improved version of RED, allows you control which PACKETS are dropped depending on the TRAFFIC CLASS 131 | 132 | ** TRAFFIC CLASSES and details about how QoS works will be covered in DAY 47 ** 133 | -------------------------------------------------------------------------------- /Course_Notes/Routing_Fundamentals_Part1.md: -------------------------------------------------------------------------------- 1 | # 11. ROUTING FUNDAMENTALS : PART 1 2 | 3 | 4 | 5 | 6 | ### WHAT IS ROUTING ? 7 | 8 | 9 | 10 | ROUTING is the process that routers use to determine the path that IP packets should take over a network to reach their destination. 11 | 12 | - ROUTERS store routes to all their known destinations in a ROUTING TABLE 13 | - When ROUTERS receive PACKETS, they look in the ROUTING TABLE to find the best route to forward that packet. 14 | 15 | There are two main routing methods (methods that routers use to learn routes): 16 | 17 | - DYNAMIC ROUTING : ROUTERS use Dynamic Routing Protocols (ie: OSPF) to share routing information with each other automatically and build their routing tables. 18 | - STATIC ROUTING : A network engineer / Admin manually configures routes on the router. 19 | 20 | A ROUTE tells the ROUTER : 21 | 22 | - to send a packet to Destination X, you should send the pack to ***next-hop*** Y 23 | - or if the Destination is directly connected to the router, *send the packet directly to the destination.* 24 | - or if the Destination is the router’s own IP address, *receive the packet for yourself (don’t forward it).* 25 | 26 | ![image](https://github.com/psaumur/CCNA/assets/106411237/8ceefb10-d70d-4530-969d-40347ed34297) 27 | 28 | 29 | WAN (Wide Area Network) = network that extends over a large geographic area. 30 | 31 | ![image](https://github.com/psaumur/CCNA/assets/106411237/b3555fdd-37a4-4bc8-b998-76e0b5455bb1) 32 | 33 | ![image](https://github.com/psaumur/CCNA/assets/106411237/99e75230-de1c-4f48-acd0-3482bba256af) 34 | 35 | ![image](https://github.com/psaumur/CCNA/assets/106411237/13a77d5c-497d-49ca-9717-ea3bb4a560d0) 36 | 37 | ![image](https://github.com/psaumur/CCNA/assets/106411237/6e3a2b3b-1590-4625-9bcf-cdaed95738d2) 38 | 39 | ![image](https://github.com/psaumur/CCNA/assets/106411237/891fcfbe-7dc5-4fb2-9b02-c6905236761e) 40 | -------------------------------------------------------------------------------- /Course_Notes/SNMP.md: -------------------------------------------------------------------------------- 1 | # 40. SNMP (Simple Network Management Protocol) 2 | 3 | SNMP OVERVIEW 4 | 5 | - SNMP is an INDUSTRY-STANDARD FRAMEWORK and PROTOCOL that was originally released in 1988 6 | 7 | These RFCs make up SNMPv1 (Do not need to memorize) 8 | 9 | ``` 10 | RFC 1065 - Structure and identification of management information for TCP/IP based internets 11 | RFC 1066 - Management information base for network management of TCP/IP based internets 12 | RFC 1067 - A simple network management protocol 13 | ``` 14 | 15 | - Don’t let the ‘Simple’ in the name fool you ! 16 | - SNMP can be used to monitor the STATUS of DEVICES, make CONFIGURATION CHANGES, etc. 17 | - There are TWO MAIN TYPES of DEVICES in SNMP: 18 | - MANAGED DEVICES 19 | - These are the DEVICES being managed using SNMP 20 | - Ex: ROUTERS, SWITCHES 21 | - NETWORK MANAGEMENT STATION (NMS) 22 | - The DEVICE / DEVICES managing the MANAGED DEVICES 23 | - THIS is the SNMP ‘SERVER’ 24 | 25 | --- 26 | 27 | SMNP OPERATIONS 28 | 29 | ![image](https://github.com/psaumur/CCNA/assets/106411237/bfa13793-5bc7-4344-8592-f38ef3a64784) 30 | 31 | --- 32 | 33 | SMNP COMPONENTS 34 | 35 | OVERVIEW 36 | 37 | ![image](https://github.com/psaumur/CCNA/assets/106411237/632a83c5-27c8-4adc-8b08-079030c5f52c) 38 | 39 | NMS 40 | 41 | ![image](https://github.com/psaumur/CCNA/assets/106411237/aa59534d-01d5-404c-bdf6-e0fd92cf9d98) 42 | 43 | MANAGED DEVICES 44 | 45 | ![image](https://github.com/psaumur/CCNA/assets/106411237/656e27b1-86a4-42c7-a1a1-94309aa19610) 46 | 47 | SNMP OIDs 48 | 49 | - SNMP Object IDs are ORGANIZED in a HIERARCHICAL STRUCTURE 50 | 51 | ![image](https://github.com/psaumur/CCNA/assets/106411237/79180299-7d9a-4607-a592-7e7d8d090cd1) 52 | 53 | --- 54 | 55 | SNMP VERSIONS 56 | 57 | - Many versions of SNMP have been proposed/developed, however, only three major versions have achieved wide-spread use: 58 | 59 | - **SNMPv1** 60 | - The ORIGINAL version of SNMP 61 | - **SNMPv2c** 62 | - Allows the NMS to retrieve LARGE AMOUNTS of information in a SINGLE REQUEST, so it is more efficient 63 | - ‘c’ refers to the ‘community strings’ used as PASSWORDS in SNMPv1, removed from SNMPv2, and then added BACK for SNMPv2 64 | - **SNMPv3** 65 | - A much more SECURE version of SNMP that supports STRONG ENCRYPTION and AUTHENTICATION. 66 | 67 | 71 | 72 | 73 | --- 74 | 75 | SNMP MESSAGES 76 | 77 | ![image](https://github.com/psaumur/CCNA/assets/106411237/25b15c81-931a-41a6-8033-dff07bfb5f15) 78 | 79 | 1) SNMP READ 80 | 81 | ![image](https://github.com/psaumur/CCNA/assets/106411237/e7d671f6-f2b0-468a-95a2-6678a52945c4) 82 | 83 | 2) SMNP WRITE 84 | 85 | ![image](https://github.com/psaumur/CCNA/assets/106411237/d8679ff7-5103-4e01-8f2e-25bb1bd25734) 86 | 87 | 88 | 3) SNMP NOTIFICATION 89 | 90 | ![image](https://github.com/psaumur/CCNA/assets/106411237/fe9266fc-12b8-41d3-8d8f-95f3f7b52ef6) 91 | 92 | 93 | SNMP AGENT listens for MESSAGES on UDP Port 161 94 | 95 | SNMP MANAGER listens for MESSAGES on UDP Port 162 96 | 97 | ![image](https://github.com/psaumur/CCNA/assets/106411237/23e6fd0a-ed1e-441b-b7b0-457a4e55f645) 98 | 99 | --- 100 | 101 | SNMPv2c CONFIGURATION (Basic) 102 | 103 | ![image](https://github.com/psaumur/CCNA/assets/106411237/caf4624e-9ca2-4c8e-82fe-53db2499a38f) 104 | 105 | WHAT HAPPENS WITH R1’s G0/1 INTERFACE GOES DOWN? 106 | 107 | ![image](https://github.com/psaumur/CCNA/assets/106411237/96341ab3-1ed3-4dd4-903c-fa57ab1f83be) 108 | 109 | NOTE: 110 | 111 | UDP message sent to Destination Port 162 (SNMP Manager) 112 | 113 | “version” is set to v2c 114 | 115 | community is “Jeremy1” (Read Only - no Set messages) 116 | 117 | snmpV2-trap : trap message sent due to interface G0/1 going down 118 | 119 | variable-bindings : contains the OID sent to identify the issue. 120 | 121 | --- 122 | 123 | SNMP SUMMARY 124 | 125 | - SNMP helps MANAGE DEVICES over a NETWORK 126 | - MANAGED DEVICES are the devices being managed using SNMP (such as ROUTERS, SWITCHES, FIREWALLS) 127 | - NETWORK MANAGEMENT STATIONS (NMS) are the SNMP “servers” that manage the devices 128 | - NMS receives notifications from Managed Devices 129 | - NMS changes settings on Managed Devices 130 | - NMS checks status of Managed Devices 131 | 132 | - Variables, such as Interface Status, Temperature, Traffic Load, Hostname, etc are STORED in the MANAGMENT INFORMATION BASE (MIB) and identified using Object IDs (OIDs) 133 | 134 | Main SNMP versions : SNMPv1, SNMPv2c, SNMPv3 135 | 136 | ``` 137 | SNMP MESSAGES : 138 | * Get / GetNext / GetBulk 139 | * Set 140 | * Trap 141 | * Inform 142 | * Response 143 | ``` 144 | -------------------------------------------------------------------------------- /Course_Notes/SSH.md: -------------------------------------------------------------------------------- 1 | # 42. SSH (Secure Shell) 2 | 3 | CONSOLE PORT SECURITY 4 | 5 | - By DEFAULT, no password us needed to access the CLI of a CISCO IOS DEVICE via the CONSOLE PORT 6 | - You can CONFIGURE a PASSWORD on the *console line* 7 | - A USER will have to enter a PASSWORD to ACCESS the CLI via the CONSOLE PORT 8 | 9 | ![image](https://github.com/psaumur/CCNA/assets/106411237/9609b0af-0fb1-4563-89e4-82b58b29325e) 10 | 11 | - Alternatively, you can configure the CONSOLE LINE to require USERS to LOGIN using one of the configured USERNAMES on the DEVICE 12 | 13 | ![image](https://github.com/psaumur/CCNA/assets/106411237/04588b3a-3640-41af-b19e-41768f63b2bc) 14 | 15 | --- 16 | 17 | LAYER 2 SWITCH MANAGEMENT IP 18 | 19 | - LAYER 2 SWITCHES do not perform PACKET ROUTING and build a ROUTING TABLE. They are NOT IP ROUTING aware 20 | - However, you CAN assign an IP ADDRESS to an SVI to allow REMOTE CONNECTIONS to the CLI of the SWITCH (using Telnet or SSH) 21 | 22 | ![image](https://github.com/psaumur/CCNA/assets/106411237/64a9e983-f353-4670-8a99-1e22129eb661) 23 | 24 | --- 25 | 26 | TELNET 27 | 28 | - TELNET (Teletype Network) is a PROTOCOL used to REMOTELY ACCESS the CLI of a REMOTE HOST 29 | - TELNET was developed in 1969 30 | - TELNET has been largely REPLACE by SSH, which is MORE Secure 31 | - TELNET sends data in PLAIN TEXT. NO ENCRYPTION(!) 32 | 33 | 37 | 38 | ![image](https://github.com/psaumur/CCNA/assets/106411237/9dffe7fb-4fa4-4ee9-90bf-d27461bb5190) 39 | 40 | --- 41 | 42 | VERIFY TELNET CONFIGURATION 43 | 44 | ![image](https://github.com/psaumur/CCNA/assets/106411237/e077b5fd-3130-4fb0-9b17-d28bdef665df) 45 | 46 | --- 47 | 48 | SSH 49 | 50 | - SSH (Secure Shell) was developed in 1995 to REPLACE LESS SECURE PROTOCOLS, like TELNET 51 | - SSHv2, a major revision of SSHv1, was released in 2006 52 | - If a DEVICE supports both v1 and v2, it is said to run ‘version 1.99’ 53 | - Provides SECURITY features; such as DATA ENCRYPTION and AUTHENTICATION 54 | 55 | CHECK SSH SUPPORT 56 | 57 | ![image](https://github.com/psaumur/CCNA/assets/106411237/441c38b7-4b79-4c80-8eca-0463960124b6) 58 | 59 | RSA KEYS 60 | 61 | - To ENABLE and use SSH, you must first generate an RSA PUBLIC and PRIVATE KEY PAIR 62 | - The KEYS are used for DATA ENCRYPTION / DECRYPTION, AUTHENTICATION, etc. 63 | 64 | ![image](https://github.com/psaumur/CCNA/assets/106411237/73bd5a86-32da-4ec6-b385-fe5425a72808) 65 | 66 | VTY LINES 67 | 68 | ![image](https://github.com/psaumur/CCNA/assets/106411237/04e9072f-ccde-476d-a84d-3034e0b39d19) 69 | 70 | --- 71 | 72 | SUMMARY ABOUT SSH CONFIGURATIONS 73 | 74 | ![image](https://github.com/psaumur/CCNA/assets/106411237/bb6d358f-e742-434b-835c-5c7cd762abdb) 75 | 76 | ![image](https://github.com/psaumur/CCNA/assets/106411237/bb2e760b-90c3-42a7-93f6-0ccc7e472d00) 77 | -------------------------------------------------------------------------------- /Course_Notes/SYSLOG.md: -------------------------------------------------------------------------------- 1 | # 41. SYSLOG 2 | 3 | SYSLOG OVERVIEW 4 | 5 | - SYSLOG is an INDUSTRY-STANDARD PROTOCOL for message logging 6 | - On NETWORK DEVICES, SYSLOG can be used to LOG EVENTS 7 | - Changes in INTERFACE status (UP / DOWN) 8 | - Changes in OSFP NEIGHBOUR STATUS (UP / DOWN) 9 | - System Restarts 10 | - etc… 11 | - The messages can be displayed in the CLI, saved in the DEVICE’S RAM or sent to an external SYSLOG SERVER 12 | 13 | ![image](https://github.com/psaumur/CCNA/assets/106411237/44a405e5-6cb1-41e3-b408-470afcaccd7e) 14 | 15 | - Logs are essential when troubleshooting issues, examining the cause of incidents, etc. 16 | - SYSLOG and SNMP are both used for MONITORING and TROUBLESHOOTING of DEVICES. They are complementary, but their functionalities are different 17 | 18 | --- 19 | 20 | SYSLOG MESSAGE FORMAT 21 | 22 | `seq: time stamp: %facility-severity-MNEMONIC:description` 23 | 24 | 28 | 29 | `seq` = A SEQUENCE NUMBER indicating the order / sequence of messages 30 | 31 | `time stamp` = A TIMESTAMP indicating the time the message was generated 32 | 33 | `facility` = A VALUE that indicates which process on the DEVICE generated the message 34 | 35 | `severity` = A NUMBER that indicates the severity of a logged event. 36 | 37 | Official RFC for SYSLOG severity levels 38 | 39 | 43 | 44 | ![image](https://github.com/psaumur/CCNA/assets/106411237/9ce46c98-a2b8-462b-ac6f-9bf13bfb3a99) 45 | 46 | 51 | 52 | `MNEMONIC` = A SHORT CODE for the message, indicating what happened 53 | 54 | `description` = Detailed information about the EVENT being reported 55 | 56 | ![image](https://github.com/psaumur/CCNA/assets/106411237/35413630-9194-4e63-8600-5847153e210e) 57 | 58 | SYSLOG LOGGING LOCATIONS 59 | 60 | - **CONSOLE LINE** 61 | - SYSLOG messages will be displayed in the CLI when connected to the DEVICE via the CONSOLE port. By DEFAULT, all messages (Level 0-7) are displayed 62 | - **BUFFER** 63 | - Syslog messages will be saved to RAM. By default, ALL messages (Level 0-7) are displayed 64 | - **VTY LINES** 65 | - SYSLOG messages will be displayed in the CLI when connected to the DEVICE via Telnet/SSH (coming in a later video). Disabled by default. 66 | 67 | - **EXTERNAL SERVER** 68 | - You can configure the DEVICE to send SYSLOG messages to an external server 69 | 70 | ** SYSLOG SERVERS will listen for messages on UDP PORT 514 ** 71 | 72 | --- 73 | 74 | SYSLOG CONFIGURATION 75 | 76 | ![image](https://github.com/psaumur/CCNA/assets/106411237/a5321bcf-d149-4a3d-82a2-197426cf484a) 77 | 78 | `level` works from the chosen level and upward toward Level 0 (EMERGENCY) 79 | 80 | `level` or `keyword` from the Severity Table works when choosing a level 81 | 82 | TERMINAL MONITOR 83 | 84 | - Even if `logging monitor level` is enabled, by default SYSLOG messages will not be displayed when connected via Telnet or SSH 85 | - For the messages to be displayed, you must use the following command: 86 | - `R1# terminal monitor` 87 | - The command must be used **every time you connect to the DEVICE via Telnet or SSH** 88 | 89 | LOGGING SYNCHRONOUS 90 | 91 | - By default, logging messages displayed in the CLI while you are in the middle of typing a command will result in something like this: 92 | 93 | ![image](https://github.com/psaumur/CCNA/assets/106411237/bf0ed51a-c8b4-4c96-806a-ba90f829edd0) 94 | 95 | - To prevent this, you should use `logging synchronous` on the appropriate *line* 96 | 97 | ![image](https://github.com/psaumur/CCNA/assets/106411237/350b34e5-8c87-417a-9e8d-fee7d3e57814) 98 | 99 | - This will cause a new line to be printed if your typing is interrupted by a message 100 | 101 | ![image](https://github.com/psaumur/CCNA/assets/106411237/09acecd5-b25b-4585-80da-950d69e284ad) 102 | 103 | SERVICE TIMESTAMPS and SERVICE SEQUENCE-NUMBERS 104 | 105 | ![image](https://github.com/psaumur/CCNA/assets/106411237/e1f9a979-eb27-47a7-af19-6496c74a4476) 106 | 107 | --- 108 | 109 | SYSLOG versus SNMP 110 | 111 | - SYSLOG and SNMP are both used for MONITORING and TROUBLESHOOTING of DEVICES. They are COMPLIMENTARY, but their FUNCTIONALITIES are different. 112 | 113 | - SYSLOG 114 | - Used for MESSAGE LOGGING 115 | - Events that occur within the system are categorized based on FACILITY / SEVERITY and LOGGED 116 | - Used for SYSTEM MANAGEMENT, ANALYSIS, and TROUBLESHOOTING 117 | - Messages are sent from the DEVICES to the SERVER. 118 | - The SERVER can’t actively pull information from the DEVICES (like SNMP ‘get’) or modify variables (like SNMP ‘set’) 119 | - SNMP 120 | - Used to retrieve and organize information about the SNMP managed DEVICES 121 | - IP ADDRESSES 122 | - Current INTERFACE status 123 | - Temperature 124 | - CPU Usage 125 | - etc… 126 | - SNMP SERVERS can use `Get` to query the CLIENTS and `Set` to MODIFY variables on the CLIENTS 127 | -------------------------------------------------------------------------------- /Course_Notes/Software_Defined_Networking.md: -------------------------------------------------------------------------------- 1 | # 62. SOFTWARE DEFINED NETWORKING (SDN) 2 | 3 | SD REVIEW 4 | 5 | - SOFTWARE DEFINED NETWORKING (SDN) is an approach to networking that centralizes the control plane into an application called a *controller* 6 | - Traditional control planes use a distributed architecture 7 | - A SDN controller centralizes control plane functions like calculating routes 8 | - The controller can interact programmatically with the network devices using APIs 9 | - The SBI (South Bound Interface) is used for communications between the controller and the network device it controls 10 | - The NBI (North Bound Interface) is what allows us to interact with the controller with our scripts and applications 11 | 12 | SDN ARCHITECTURE 13 | 14 | ![image](https://github.com/psaumur/CCNA/assets/106411237/9d7e1a89-3537-48cc-a410-cef352b6a2cb) 15 | 16 | --- 17 | 18 | CISCO SD-ACCESS 19 | 20 | - Cisco SD-ACCESS is Cisco’s SDN solution for automating campus LANs 21 | - ACI (Application Centric Infrastructure) is their SDN solution for automating data center networks 22 | - SD-WAN is their SDN solution for automating WANs 23 | - Cisco DNA (Digital Network Architecture) Center is the controller at the center of SD-Access 24 | 25 | ![image](https://github.com/psaumur/CCNA/assets/106411237/4c1662ee-490c-4eee-8970-550ca60feabb) 26 | 27 | - The UNDERLAY is the underlying physical network of devices and connections (including wired and wireless) which provide IP connectivity (ie: using IS-IS) 28 | - Multilayer Switches and their connections 29 | 30 | ![image](https://github.com/psaumur/CCNA/assets/106411237/41bb11dd-31c9-493e-9fec-af847f0732dc) 31 | 32 | - The OVERLAY is the virtual network built on top of the physical underlay network 33 | 34 | ![image](https://github.com/psaumur/CCNA/assets/106411237/99f48b9e-ed68-4c11-b456-d0f6ccf13fed) 35 | 36 | - The FABRIC is the combination of the OVERLAY and UNDERLAY; the physical and virtual network as a whole 37 | 38 | ![image](https://github.com/psaumur/CCNA/assets/106411237/35cf981c-337d-4117-9124-9f210e85bff3) 39 | 40 | --- 41 | 42 | SD-ACCESS UNDERLAY 43 | 44 | - The UNDERLAY’s purpose is to support the VXLAN tunnels of the OVERLAY 45 | - There are THREE different ROLES for switches in SD-ACCESS: 46 | - EDGE NODES : Connect to End HOSTS 47 | - BORDER NODES : Connect to devices outside of the SD-ACCESS Domain ; ie: WAN routers 48 | - CONTROL NODES : Uses LISP (Locator ID Separation Protocol) to perform various control plane functions 49 | 50 | - You can add SD-ACCESS on top of the existing network (*brownfield deployment*) if your network hardware and software supports it 51 | - Google ‘Cisco SD-ACCESS compatibility matrix’ if you are curious 52 | - In this case DNA CENTER won’t configure the UNDERLAY 53 | 54 | - A NEW deployment (*greenfield deployment)* will be configured by DNA CENTER to use the optimal SD-ACCESS UNDERLAY: 55 | - ALL Switches are LAYER 3 and use IS-IS as their ROUTING PROTOCOL 56 | - All Links between Switches are ROUTED PORTS. This means STP is not needed 57 | - EDGE NODES (ACCESS SWITCHES) act as the the DEFAULT GATEWAY of END HOSTS *(Routed Access Layer)* 58 | 59 | ![image](https://github.com/psaumur/CCNA/assets/106411237/0315f1e5-d9c6-47ce-acf2-1de6f14ac89c) 60 | 61 | ![image](https://github.com/psaumur/CCNA/assets/106411237/84d48992-30f9-45cf-856a-089ce00d0641) 62 | 63 | --- 64 | 65 | SD-ACCESS OVERLAY 66 | 67 | - LISP (Locator ID Separation Protocol) provides the control plane of SD-ACCESS 68 | - A list of mappings of EIDs (endpoint identifiers) to RLOCs (routing locators) is kept 69 | - EIDs identify END HOSTS connected to EDGE SWITCHES 70 | - RLOCS identify the EDGE SWITCH which can be used to reach the END HOST 71 | - There is a LOT more detail to cover about LISP but I think you can see how it differs from traditional CONTROL PLANE 72 | 73 | - Cisco TrustSec (CTS) provides policy control (QoS, Security Policy, etc.) 74 | 75 | - VXLAN provides the DATA PLANE of SD-ACCESS 76 | 77 | ![image](https://github.com/psaumur/CCNA/assets/106411237/8fd0bb65-31df-4db5-a79c-044c68c37b01) 78 | 79 | ![image](https://github.com/psaumur/CCNA/assets/106411237/b4c017b1-cc59-4305-9924-f25a5445a36b) 80 | 81 | ![image](https://github.com/psaumur/CCNA/assets/106411237/5adcaf16-4caf-4de2-9b8f-3e777c841bc6) 82 | 83 | --- 84 | 85 | CISCO DNA CENTER 86 | 87 | - Cisco DNA Center has TWO MAIN ROLES: 88 | - The SDN Controller in SD-ACCESS 89 | - A network manager in a traditional network (non-SD-ACCESS) 90 | - DNA Center is an application installed on Cisco UCS server hardware 91 | - It has a REST API which can be used to interact with DNA Center 92 | - The SBI supports protocols such as NETCONF and RESTCONF (as well as traditional protocols like Telnet, SSH, and SNMP) 93 | - DNA Center enables *Intent-Based Networking* (IBN) 94 | - The goal is to allow the engineer to communicate their intent for network behavior to DNA Center, and then DNA Center will take care of the details of the actual configurations and policies on devices 95 | 96 | - Traditional security policies using ACLs can become VERY cumbersome 97 | - ACLs can have thousands of entries 98 | - The intent of entries is forgotten with time and as engineers leave and new engineers take over 99 | 100 | - DNA Center allows the engineer to specify the intent of the policy 101 | - Examples : 102 | - THIS group of users can’t communicate with THAT group 103 | - THIS group can access THIS server but not THAT server 104 | - DNA CENTER will take care of the exact details of implementing this policy 105 | 106 | ![image](https://github.com/psaumur/CCNA/assets/106411237/30773f46-3564-4d66-a175-20962d1569dd) 107 | 108 | --- 109 | 110 | >For more details, you can check out [sandboxdnac.cisco.com](http://sandboxdnac.cisco.com) (User: devnetuser, Password: Cisco123!) 111 | 112 | --- 113 | 114 | DNA CENTER NETWORK MANAGEMENT VS. TRADITIONAL 115 | 116 | Traditional Management : 117 | 118 | - DEVICES are configured one-by-one via SSH or Console connection 119 | - DEVICES are manually configured via Console connection before being deployed 120 | - Configurations and polices are managed per-device 121 | - New network deployments can take a long time due to the manual labor required 122 | - Errors and failures are more likely due to increased manual effort 123 | 124 | DNA CENTER-based Network Management : 125 | 126 | - DEVICES are centrally managed and monitored from the DNA CENTER GUI or other applications using it’s REST API 127 | - The Administrator communicates their intended network behavior to DNA CENTER, which changes those intentions into configurations on the managed network devices 128 | - Configurations and policies are centrally managed 129 | - Software versions are also centrally managed. DNA CENTER can monitor cloud servers for new versions and then update the managed devices 130 | - New network deployments are much quicker. New devices can automatically receive their configurations from DNA CENTER without manual configuration 131 | 132 | ![image](https://github.com/psaumur/CCNA/assets/106411237/cb9e0184-6b45-4dcc-85ae-cef3245c1629) 133 | -------------------------------------------------------------------------------- /Course_Notes/Standard_Access_Control_Lists.md: -------------------------------------------------------------------------------- 1 | # 34. STANDARD ACCESS CONTROL LISTS (ACL) 2 | 3 | WHAT ARE ACLs 4 | 5 | - ACLs (Access Control Lists) have multiple uses 6 | - In DAY 34 and DAY 35, we will focus on ACL’s from a security perspective 7 | - ACLs function as a “packet filter” - instructing the ROUTER to ALLOW or DENY specific traffic 8 | - ACLs can filter traffic based on: 9 | - SOURCE / DESTINATION IP ADDRESSES 10 | - SOURCE / DESTINATION LAYER 4 PORTS 11 | - etc. 12 | 13 | --- 14 | 15 | HOW ACLs WORK 16 | 17 | ![image](https://github.com/psaumur/CCNA/assets/106411237/92d663ec-33a8-4ba4-b0a7-5d3942a9b67e) 18 | 19 | 25 | 26 | ACLs are configured GLOBALLY on the ROUTER (Global Config Mode) 27 | 28 | - They are an ordered sequence of ACEs (Access Control Entries) 29 | 30 | ![image](https://github.com/psaumur/CCNA/assets/106411237/2eb0c042-21d0-4a40-ade3-9715bd2b3bcb) 31 | 32 | - Configuring an ACL in Global Config Mode will not make the ACL take effect 33 | - The ACL must be applied to an interface 34 | - ACLs are applied either INBOUND or OUTBOUND 35 | - ACLs are made up of one or more ACEs 36 | - When a ROUTER checks a PACKET against the ACL, it processes the ACEs in order, from top to bottom 37 | - If the PACKET matches one of the ACEs in the ACL, the ROUTER takes the action and stops processing the ACL. All entries below the matching entry will be ignored 38 | 39 | ![image](https://github.com/psaumur/CCNA/assets/106411237/a4a86a8e-f73c-476b-b0e5-15bfb4f4748d) 40 | 41 | ![image](https://github.com/psaumur/CCNA/assets/106411237/6e4148e0-e908-4a44-9f23-358c9d7ade11) 42 | 43 | --- 44 | 45 | IMPLICIT DENY 46 | 47 | - What will happen if a PACKET doesn’t match any of the entries in an ACL ? 48 | - There is an INPLICIT DENY at the end of ALL ACL’s 49 | - The IMPLICIT DENY tells the ROUTER to DENY ALL TRAFFIC that doesn’t match ANY of the configured entries in the ACL 50 | 51 | --- 52 | 53 | ACL TYPES 54 | 55 | ![image](https://github.com/psaumur/CCNA/assets/106411237/4856845e-80b2-45dc-b30c-cc3b170db69c) 56 | 57 | --- 58 | 59 | STANDARD NUMBERED ACLs 60 | 61 | - Match traffic based only on the SOURCE IP ADDRESS of the PACKET 62 | - Numbered ACLs are identified with a number (ie: ACL 1, ACL 2, etc.) 63 | - Different TYPES of ACLs have a different range of numbers that can be used 64 | 65 | 69 | 70 | 71 | - The basic command to configure a STANDARD NUMBERED ACL 72 | - `R1(config)# access-list *number* {deny | permit} *ip wildcard-mask*` 73 | 74 | This is an example of denying a SPECIFIC host’s traffic 75 | 76 | REMEMBER : 0.0.0.0 wildcard is the same as 255.255.255.255 or a /32 host 77 | 78 | - Example : `R1(config)# access-list 1 deny 1.1.1.1 0.0.0.0` 79 | - Example : `R1(config)# access-list 1 deny 1.1.1.1`(identical to the above) 80 | - Example : `R1(config)# access-list 1 deny host 1.1.1.1` 81 | 82 | If you want to permit ANY traffic from ANY source 83 | 84 | - Example : `R1(config)# access-list 1 permit any` 85 | - Example : `R1(config)# access-list 1 permit 0.0.0.0 255.255.255.255` 86 | 87 | If you want to make a description for a specific ACL 88 | 89 | - Example : `R1(config)# access-list 1 remark ## BLOCK BOB FROM ACCOUNTING ##` 90 | 91 | ![image](https://github.com/psaumur/CCNA/assets/106411237/3e20e40c-6755-4638-9ef3-15fa747f93b6) 92 | 93 | Order is important. Lower Numbers are processed FIRST 94 | 95 | --- 96 | TO APPLY AN ACL TO AN INTERFACE 97 | 98 | `R1(config-if)# ip access-group *number* {in | out}` 99 | 100 | ![image](https://github.com/psaumur/CCNA/assets/106411237/eed38afa-f067-4153-80bb-b07c52a21e53) 101 | 102 | WHY WAS THIS RULE PLACED ON G0/2 OUT ? 103 | 104 | 108 | 109 | --- 110 | 111 | STANDARD NAMED ACLs 112 | 113 | - Standard ACLs match traffic based only on the SOURCE IP ADDRESS of the PACKET 114 | - NAMED ACLs are identified with a NAME (ie: ‘BLOCK_BOB’) 115 | - STANDARD NAMED ACLs are configured by entering ‘standard named ACL config mode’ then configuring EACH entry within that config mode 116 | - `R1(config)# ip access-list standard *acl-name*` 117 | - `R1(config-std-nacl)# [*entry-number*] {deny | permit} *ip wildcard-mask*` 118 | 119 | ![image](https://github.com/psaumur/CCNA/assets/106411237/94e9b58d-07f6-4ad6-9c92-b00c01ce311d) 120 | 121 | ![image](https://github.com/psaumur/CCNA/assets/106411237/a8a10f5f-8e5c-4e19-981f-862bf94b2788) 122 | 123 | ![image](https://github.com/psaumur/CCNA/assets/106411237/3b641f99-4c99-4d5f-a32b-1a626d1a02b4) 124 | 125 | ![image](https://github.com/psaumur/CCNA/assets/106411237/17a7d767-1052-4bc0-8a04-7278f16caeb6) 126 | 127 | Here are the configurations for the above: 128 | 129 | ![image](https://github.com/psaumur/CCNA/assets/106411237/bbdcff70-1fd4-46a4-a4c2-5d5485fe5695) 130 | 131 | Note, however, how the order is when viewing the ACLs 132 | 133 | ![image](https://github.com/psaumur/CCNA/assets/106411237/74ad9dd4-d56f-4845-83b1-44366b4b94f6) 134 | 135 | WHY THE REORDERING? 136 | 137 | ![image](https://github.com/psaumur/CCNA/assets/106411237/e5ed273d-1c24-4b78-884f-712e1cf6922a) 138 | 139 | CISCOs PACKET TRACER does not reorder these, however. 140 | -------------------------------------------------------------------------------- /Course_Notes/Static_Routing_Part2.md: -------------------------------------------------------------------------------- 1 | # 11. STATIC ROUTING : PART 2 2 | 3 | REVIEW: 4 | 5 | SWITCHES forward traffic WITHIN LAN's 6 | ROUTERS forward traffic BETWEEN LAN's 7 | 8 | WAN (Wide Area Network) 9 | 10 | - Network spread over a large area 11 | 12 | ![image](https://github.com/psaumur/CCNA/assets/106411237/e44ac71c-91e3-4963-85da-ac07e475b248) 13 | 14 | 15 | ![image](https://github.com/psaumur/CCNA/assets/106411237/289212da-6c94-44fb-a1e3-1c066b56d79c) 16 | 17 | 18 | ![image](https://github.com/psaumur/CCNA/assets/106411237/f8f7d58b-89b7-412c-9cf6-c038338e105d) 19 | 20 | 21 | ![image](https://github.com/psaumur/CCNA/assets/106411237/63611407-719e-46d3-8331-a18533616285) 22 | 23 | --- 24 | 25 | STATIC ROUTES: 26 | 27 | ![image](https://github.com/psaumur/CCNA/assets/106411237/10135afa-ace6-47f1-aada-1b73f243589b) 28 | 29 | --- 30 | 31 | STATIC ROUTE CONFIGURATION: 32 | 33 | ![image](https://github.com/psaumur/CCNA/assets/106411237/d375a428-e171-4212-9698-2f2589878884) 34 | 35 | 36 | ![image](https://github.com/psaumur/CCNA/assets/106411237/012f4134-2667-421b-9b36-f449faebf423) 37 | 38 | 39 | ![image](https://github.com/psaumur/CCNA/assets/106411237/0a3ed6cb-c414-4365-aef4-754b4b82483e) 40 | 41 | 42 | ![image](https://github.com/psaumur/CCNA/assets/106411237/4379f8fb-a366-4279-a31c-ff2ba3f6fdb8) 43 | 44 | 45 | ![image](https://github.com/psaumur/CCNA/assets/106411237/6fed6489-c53c-404e-b794-b71c2e9b8e4f) 46 | 47 | --- 48 | 49 | STATIC ROUTE CONFIGURATION with *exit-interface* 50 | 51 | ![image](https://github.com/psaumur/CCNA/assets/106411237/dc93b5f9-791c-44fc-8b88-2053491183a9) 52 | 53 | --- 54 | 55 | DEFAULT ROUTE 56 | 57 | ![image](https://github.com/psaumur/CCNA/assets/106411237/a0eef93a-b40b-409b-8b51-6cdbace4ff45) 58 | -------------------------------------------------------------------------------- /Course_Notes/Subnetting_Part1.md: -------------------------------------------------------------------------------- 1 | # 13. SUBNETTING : PART 1 2 | 3 | ![image](https://github.com/psaumur/CCNA/assets/106411237/a475e909-59b8-4615-a0b9-8a3c1fbdc313) 4 | 5 | 6 | HOWEVER, only Class A, B, C Addresses can be assigned to a device as an IP Address. 7 | 8 | CLASS PREFIX LENGTH 9 | 10 | A /8 11 | B /16 12 | C /24 13 | 14 | ![image](https://github.com/psaumur/CCNA/assets/106411237/f0836136-c4a9-475b-b6c2-d1c550b8cfdd) 15 | 16 | 17 | The IANA (Internet Assigned Numbers Authority) assigns IPv4 addresses/networks to companies based on their size. 18 | 19 | The problem with 'CLASSFUL' assignment is that it led to IP Address wastefulness. 20 | 21 | Example: A company requiring 5000 address was assigned a CLASS B IP, leaving 60000+ addresses unused. 22 | 23 | --- 24 | 25 | The IETF (Internet Engineering Task Force) introduce CIDR in 1993 to replace the "classful" addressing system. 26 | 27 | CIDR (Classless Inter-Domain Routing) removed the requirements of CLASS A, B, and C regarding size. 28 | 29 | - This allowed larger networks to be split into smaller networks, allowing greater efficiency. 30 | - These smaller networks are called "SUB-NETWORKS" or "SUBNETS" 31 | 32 | --- 33 | 34 | HOW MANY USABLE ADDRESSES ARE THERE IN EACH NETWORK? 35 | 36 | REMEMBER: 37 | 38 | 2^n - 2 = Usable Address 39 | n = number of host bits 40 | 41 | CIDR PRACTICE! 42 | 43 | 203.0.113.0/25 44 | 45 | /25 means the Subnetwork bit is 25 bits 46 | 47 | 203 . 0 . 113 . 0 is written in binary as : 48 | 49 | 1100 1011 . 0000 0000 . 0111 0001 . 0 | 000 0000 50 | 51 | (Subnet prefix is the first 25 bits) 52 | 53 | Flipping all the bits to 1’s, we get the SUBNET MASK for /25: 54 | 55 | 1111 1111 . 1111 1111 . 1111 1111 . 1 | 000 0000 56 | 57 | which is equal to: 58 | 59 | 255.255.255.128 (because the last octet is 1000 0000 = 128 in binary) 60 | 61 | SO - the based on previous definition of USABLE ADDRESSES, the number of hosts for 62 | 203.0.113.0 /25 is: 63 | 64 | 2^(7 bits) or (128) - 2 = 126 hosts. 65 | 66 | --- 67 | 68 | What about /28 ? 69 | 70 | 203 . 0 . 113 . 0 is written in binary as : 71 | 72 | 1100 1011 . 0000 0000 . 0111 0001 . 0000 | 0000 73 | 74 | (Subnet prefix is the first 28 bits) 75 | 76 | flipping all the bits to 1’s, we get the SUBNET MASK for /28: 77 | 78 | 1111 1111 . 1111 1111 . 1111 1111 . 1111 | 0000 79 | 80 | which is equal to: 81 | 82 | 255.255.255.240 (because the last octet is 1111 0000) = 128+64+32+16 = (128+32) + (64+16) = 160 + 80 = 240 83 | 84 | The SUBNET MASK for /28 is 255.255.255.240 85 | which has 16 hosts / group (2 * 4 bits = 16) - 2 Reserved IPs for Network and Broadcast 86 | 87 | --- 88 | 89 | SUBNETTING CHEATSHEET: 90 | 91 | | Group Size | 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 | 92 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | 93 | | Subnet Mask | 128 | 192 | 224 | 240 | 248 | 252 | 254 | 255 | 94 | | CIDR | /25 | /26 | /27 | /28 | /29 | /30 | /31 | /32 | 95 | | 3rd Octet | /17 | /18 | /19 | /20 | /21 | /22 | /23 | /24 | 96 | | 2nd Octet | /9 | /10 | /11 | /12 | /13 | /14 | /15 | /16 | 97 | | 1st Octet | /1 | /2 | /3 | /4 | /5 | /6 | /7 | /8 | 98 | 99 | --- 100 | 101 | 1. Use a given CIDR/Mask to find column on Cheat Sheet 102 | 103 | a) CIDR/Subnet Mask map to each other 104 | 105 | b) Locate Group Size 106 | 107 | c) Increase by Group Size until you PASS the Target IP (not less or equal !) 108 | 109 | d) If passing the Target IP reaches 256, increase the Octet BEFORE it by one and current Octet becomes 0 : IF NECESSARY 110 | 111 | Example: 10.2.2.256 → 10.2.3.0 112 | 113 | 114 | 1. Number BEFORE Target IP is NETWORK ID 115 | 2. Number AFTER Target IP is NEXT NETWORK 116 | 3. IP Address BEFORE Next Network is BROADCAST 117 | 4. IP Address AFTER Network ID is First Host 118 | 5. IP Address BEFORE Broadcast IP is Last Host 119 | 6. Group Size is total # of IP Addresses 120 | - Don’t forget to subtract 2 for USABLE # 121 | 122 | --- 123 | 124 | Solving CIDR/Subnet for 3rd Octet IPs : 125 | 126 | Every number LEFT of 3rd Octet is 255. Every number RIGHT of 3rd Octet is 0 127 | 128 | Example: 10.4.77.188 / 19 → Subnet : 255.255.224.0 129 | 130 | You use the SAME process as above except when finding Target IPs, you use the 3rd Octet for your Target. 131 | 132 | Example: 10.4.77.188 /19 → Subnet : 255.255.224.0 133 | 134 | 256 - 224 = 32 so… 135 | 136 | Using 32, we step through the address blocks 0, 32,64, and 96. 137 | Since 77 is between 64 and 96, there’s our range. 138 | 139 | Network: 10.4.64.0 (Start / First Block) 140 | 141 | Next: 10.4.96.0 (Second Block) 142 | … 143 | 144 | Number of IP Addresses is : 2^(32-CIDR). In this example 2^13 = 8192 145 | 146 | Solving for 2nd and 1st Octet is the same as above, keeping in mind the Octet column is USED to check for the Target number of a given address. 147 | 148 | --- 149 | Alternative method to "Cheat Sheet" 150 | 151 | ![image](https://github.com/user-attachments/assets/d1e103b8-142a-44cc-8ab4-f5337268c9de) 152 | 153 | 1. Find the "magic octet" where a given IP /Prefix lies, from the bit chart shown (boundary digits are inclusive of the octet preceding them) 154 | 2. Count the number of network bits (left to right) in that octet and count the same amount, using the red bit slot chart. This'll be your address group size. 155 | 3. Subtract that number from 256 to find your Subnet Mask number used in the "magic octet" (any octet LEFT of that "magic octet" will be 255, everything RIGHT of that octet will be 0) 156 | 4. Divide whatever IP octet number is in the "magic octet" by the address group size. 157 | - If there is a remainder, multiple the whole integer by the address group size - your Base Network Address is that value, with every octet to the right of that as all 0's 158 | - If there is NO remainder, the IP number in the "magic octet" IS the Base Network Address is that value, with every octet to the right of that as all 0's 159 | 5. The Base Broadcast Number will be Network Base Number + Group Size - 1 in the "magic octet", every value to the right of that octet will be 255. 160 | 6. Number of subnets is (2 to the power of the number of network bits in the "magic octet". ** 2^8 or 256 is equal to 0 **) 161 | 7. Total Useable Hosts size is (2 to the power of (32 - Prefix Length) -2) 162 | --- 163 | Example 1: 164 | ``` 165 | 154 . 219 . 154 . 180 /20 166 | 167 | Third Octet = Magic 168 | 169 | Address Group Size = 16 (L/R count of 4) 170 | 256 - 16 = 240 therefore Subnet Mask is 255.255.240.0 171 | 172 | Divide 3rd digit / Address Group Size (16) 173 | 154 / 16 = 9 (with remainder) 174 | 9 * 16 = 144 (Base Network #) 175 | 176 | Network : 154 . 219 . 144 . 0 177 | 178 | Broadcast Base # = 144 + 16 - 1 = 159 179 | 180 | Broadcast : 154. 219 . 159 . 255 181 | 182 | Subnets = 2^4 network bits = 16 183 | Total Host Size = (2^(32 - 20))-2 = 4094 184 | ``` 185 | --- 186 | Example 2: 187 | ``` 188 | 84 . 75 . 21 .6 /10 189 | 190 | Second Octet = Magic 191 | 192 | Address Group Size = 64 193 | 256 - 64 = 192 194 | 195 | Subnet = 255.192.0.0 196 | 197 | 75 / 64 = 1 + remainder 198 | 1 * 64 = 64 (Base Network #) 199 | 200 | Network : 84.64.0.0 201 | 202 | Broadcast Base # = 64 + 64 -1 = 127 203 | 204 | Broacast : 84.127.255.255 205 | 206 | Subnets : 2^2 = 4 Subnets 207 | Total Host Size = (2^(32-10))-2 = 4194302 208 | ``` 209 | -------------------------------------------------------------------------------- /Course_Notes/Subnetting_Part2.md: -------------------------------------------------------------------------------- 1 | # 14. SUBNETTING : PART 2 2 | 3 | CLASS C NETWORKS 4 | 5 | ![image](https://github.com/psaumur/CCNA/assets/106411237/08be5a37-fa2c-4483-94c9-6c3d05229894) 6 | 7 | 8 | CLASS B NETWORKS 9 | 10 | ![image](https://github.com/psaumur/CCNA/assets/106411237/44e8cdcb-16c2-41c4-8f22-a0a31071550a) 11 | -------------------------------------------------------------------------------- /Course_Notes/Subnetting_VLSM_Part3.md: -------------------------------------------------------------------------------- 1 | # 15. SUBNETTING (VLSM) : PART 3 2 | 3 | The process of subnetting Class A, Class B, and Class C is identical. 4 | 5 | SUBNETTING CLASS A NETWORKS 6 | 7 | Given a 10.0.0.0/8 network, you must create 2000 subnets which will distributed to various enterprises. What prefix length must you use? 8 | 9 | 2^10 = 1024 so 2^11 = 2048. We have to "borrow" 11 bits (Left to Right) to get enough subnets 10 | 11 | 0000 1010 . 0000 0000 . 000 | 00000 . 0000 0000 12 | 13 | 8 bits + 8 bits + 3 = 19 bits 14 | 15 | 0000 1010 . 0000 0000 . 000 | 00000 . 0000 0000 16 | 1111 1111 . 1111 1111 . 111 | 00000 . 0000 0000 17 | 18 | 255.255.224.0 is the Subnet mask 19 | 20 | The answer is /19 (/8 + /11 = /19) 21 | 22 | How many hosts per subnet? There are 13 host bits remaining so: 23 | 24 | 2^13 - 2 = 8190 hosts per subnet 25 | 26 | --- 27 | 28 | VARIABLE-LENGTH SUBNET MASKS (VLSM) 29 | 30 | - Until now, we have practiced subnetting using FLSM (Fixed-Length Subnet Masks). 31 | - This means that all of the subnets use the same prefix length (ie: Subnetting a Class C network into 4 subnets using /26) 32 | - VLSM (Variable-Length Subnet Masks) is the process of creating subnets of different sizes, to make your use of network addresses more efficient. 33 | - VLSM is more complicated than FLSM, BUT it's easy if you follow the steps correctly. 34 | 35 | ![image](https://github.com/psaumur/CCNA/assets/106411237/30a08f93-796a-4fe9-854e-58af0bcbd69b) 36 | 37 | ![image](https://github.com/psaumur/CCNA/assets/106411237/ad7d7ac0-5e00-4662-8192-f7f9db86f1d9) 38 | 39 | ![image](https://github.com/psaumur/CCNA/assets/106411237/dc006342-4bd9-40d4-b1c5-9ac7a670ed96) 40 | 41 | 42 | So, in order: 43 | ``` 44 | TOKYO LAN A (110 HOSTS) 45 | TORONTO LAN B (45 HOSTS) 46 | TORONTO LAN A (29 HOSTS) 47 | TOKYO LAN B (8 HOSTS) 48 | and 49 | THE POINT TO POINT CONNECTION (between the two ROUTERS) 50 | ``` 51 | 192.168.1.0 / 24 52 | 53 | 1000 0000 . 1010 1000 . 0000 0001 | 0000 0000 (last is host octet = 254 usable hosts) 54 | 55 | Shifting LEFT - we DOUBLE the # of hosts 56 | Shifting RIGHT - we HALF the # of hosts 57 | 58 | TOKYO LAN A (we need to borrow 1 host bits, to the RIGHT, to leave enough for 2^7 or 128 hosts. More than enough for TOKYO A) 59 | 60 | so: 61 | ``` 62 | 192.168.1.0/25 (Network Address) 63 | 1000 0000 . 1010 1000 . 0000 0001 . 0 | 000 0000 64 | 65 | Converting remaining Host Bits to 1s: 66 | 0111 1111, we get 127 so 67 | 68 | 192.168.1.127/25 is the Broadcast Address 69 | ``` 70 | --- 71 | TOKYO LAN A 72 | ``` 73 | NETWORK ADDRESS: 192.168.1.0/25 74 | BROADCAST ADDRESS: 192.168.1.127/25 75 | FIRST USABLE: 192.168.1.1/25 76 | LAST USABLE: 192.168.1.126/25 77 | TOTAL NUMBER OF USABLE HOSTS: 126 (2^7 -2) 78 | 79 | Since TOKYO LAN A is 192.168.1.127, the next Subnet (TOKYO LAN B) starts at 192.168.1.128 (Network Address) 80 | ``` 81 | --- 82 | TORONTO LAN B 83 | ``` 84 | NETWORK ADDRESS: 192.168.1.128 / 26 85 | BROADCAST ADDRESS: 192.168.1.191 / 26 86 | FIRST USABLE: 192.168.1.129 /26 87 | LAST USABLE: 192.168.1.190 / 26 88 | TOTAL NUMBER OF USABLE HOSTS: 62 (2^6 -2) 89 | ``` 90 | 91 | We need to borrow to get enough for 45 hosts. 92 | 93 | |128|64|32|16|8|4|2|1| 94 | |---|--|--|--|-|-|-|-| 95 | |x |x | 0| 0|0|0|0|0| 96 | ``` 97 | 1000 0000 . 1010 1000 . 0000 0001 . 10 | 00 0000 98 | 99 | 192 . 168 . 1 . 128 100 | 101 | 1000 0000 . 1010 1000 . 0000 0001 . 10 | 11 1111 102 | 103 | 192 . 168 . 1 . 191 (Broadcast Address) 104 | ``` 105 | --- 106 | 107 | TORONTO LAN A 108 | 109 | We need to borrow to get enough for 29 hosts. 110 | 111 | |128|64|32|16|8|4|2|1| 112 | |---|--|--|--|-|-|-|-| 113 | |x |x | x| 0|0|0|0|0| 114 | ``` 115 | 1000 0000 . 1010 1000 . 0000 0001 . 110 | 0 0000 116 | 117 | 192.168.1.192 (Net Address) 118 | 119 | 1000 0000 . 1010 1000 . 0000 0001 . 110 | 1 1111 120 | 121 | 192.168.1.224 (Broadcast address) 122 | 123 | NETWORK ADDRESS: 192.168.1.192 / 27 124 | BROADCAST ADDRESS: 192.168.1.223 / 27 125 | FIRST USABLE: 192.168.1.193 /27 126 | LAST USABLE: 192.168.1.222 / 27 127 | TOTAL NUMBER OF USABLE HOSTS: 30 hosts (2^5 - 2) 128 | ``` 129 | --- 130 | 131 | TOKYO LAN B 132 | We need to borrow to get enough for 8 hosts. Remember total usable hosts is equal to x - 2. 133 | 134 | |128|64|32|16|8|4|2|1| 135 | |---|--|--|--|-|-|-|-| 136 | |x |x | x| x|0|0|0|0| 137 | ``` 138 | 1000 0000 . 1010 1000 . 0000 0001 . 1110 | 0000 139 | 140 | 192.168.1.224 (Net Address) 141 | 142 | 1000 0000 . 1010 1000 . 0000 0001 . 1110 | 1111 143 | 144 | 192.168.1.239 (Broadcast address) 145 | 146 | NETWORK ADDRESS: 192.168.1.224 / 28 147 | BROADCAST ADDRESS: 192.168.1.239 / 28 148 | FIRST USABLE: 192.168.1.225 /28 149 | LAST USABLE: 192.168.1.238 / 28 150 | TOTAL NUMBER OF USABLE HOSTS: 14 hosts (2^4 - 2) 151 | ``` 152 | --- 153 | 154 | POINT TO POINT CONNECTIONS 155 | 156 | We need to borrow to get enough for 4 hosts. Remember total usable hosts is equal to x - 2. 157 | |128|64|32|16|8|4|2|1| 158 | |---|--|--|--|-|-|-|-| 159 | |x |x | x| x|x|x|0|0| 160 | ``` 161 | 1000 0000 . 1010 1000 . 0000 0001 . 1111 00 | 00 162 | 163 | 192.168.1.240 (Net Address) 164 | 165 | 1000 0000 . 1010 1000 . 0000 0001 . 1111 00 | 11 166 | 167 | 192.168.1.243 (Broadcast address) 168 | 169 | NETWORK ADDRESS: 192.168.1.240 / 30 170 | BROADCAST ADDRESS: 192.168.1.243 / 30 171 | FIRST USABLE: 192.168.1.241 / 30 172 | LAST USABLE: 192.168.1.242 / 30 173 | TOTAL NUMBER OF USABLE HOSTS: 2 hosts (2^2 - 2) 174 | ``` 175 | --- 176 | 177 | ADDITIONAL PRACTICE FOR SUBNETTING 178 | 179 | [http://www.subnettingquestions.com](http://www.subnettingquestions.com/) 180 | [http://subnetting.org](http://subnetting.org/) 181 | [https://subnettingpractice.com](https://subnettingpractice.com/) *** Preferred site *** 182 | -------------------------------------------------------------------------------- /Course_Notes/Switch_Interfaces.md: -------------------------------------------------------------------------------- 1 | # 9. SWITCH INTERFACES 2 | 3 | ![image](https://github.com/psaumur/CCNA/assets/106411237/5d0d80dc-74d1-4656-841c-fcaa2b89c760) 4 | 5 | 6 | CISCO CLI for SWITCHES 7 | 8 | ![image](https://github.com/psaumur/CCNA/assets/106411237/e3947ef5-9100-426f-8d62-fd4ce5224351) 9 | 10 | 11 | // enter Privileged EXEC mode 12 | 13 | SW1>enable 14 | 15 | // Show all interfaces of Switch 1. 16 | 17 | SW# show ip interface brief 18 | 19 | This will show the interfaces currently on Switch 1. It has the same information structure as Cisco Routers. 20 | 21 | Notice the Status (Layer 2) and Protocol (Layer 1) columns are showing "up/up". 22 | 23 | Unlike ROUTERS, SWITCHES do no DEFAULT to 'administrative down/down'(shutdown). 24 | 25 | Unconnected devices will show as "down" and "down" (not connected to another device) 26 | 27 | ![image](https://github.com/psaumur/CCNA/assets/106411237/e0fdc339-21d9-4313-b7d8-78303a7ba1ea) 28 | 29 | 30 | // Show the status of all interfaces on SW1 31 | 32 | SW1#show interfaces status 33 | 34 | This will list: 35 | 36 | - Ports 37 | - Name (which is description) 38 | - Status (connection status) 39 | - Vlan (can be used to divide up LANs) - Vlan 1 is the default. 40 | - Duplex (can the connection send/receive at same time?) - Auto is default 41 | - Speed (speed in bps) - Auto is default 42 | - Type (what medium is being used, speed of interface) 43 | 44 | --- 45 | 46 | ![image](https://github.com/psaumur/CCNA/assets/106411237/12a33be7-795f-467a-87a4-42c5b218960b) 47 | 48 | 49 | ![image](https://github.com/psaumur/CCNA/assets/106411237/7b5953f7-77d3-4826-8efc-072498a7f9c0) 50 | 51 | 52 | --- 53 | 54 | INTERFACE RANGE 55 | 56 | Unused Interfaces can pose a security risk so it's a good idea to deactivate them. 57 | 58 | However, if you have 28+ interfaces not in use, do you have to do them one at a time? 59 | 60 | Answer: No! There is a command to apply configurations to a range of interfaces. 61 | 62 | Inside Global Config Mode (config t): 63 | 64 | ![image](https://github.com/psaumur/CCNA/assets/106411237/06e2e267-1e07-48a1-8c8c-8edbd5bd48ae) 65 | 66 | 67 | SW1(config)#interface range f0/5 - 12 // Choose all interfaces from 0/5 to 0/12 68 | 69 | SW1(config-if-range)#description ## not in use ## 70 | 71 | SW1(config-if-range)#shutdown 72 | 73 | << this will list all the interfaces being set to administratively down >> 74 | 75 | Confirm with 'show interface status' in Privileged EXEC mode or if in CONFIG mode, use 'do show interface status' 76 | 77 | ![image](https://github.com/psaumur/CCNA/assets/106411237/8d1d49d3-e000-4570-ab7e-b994b959ebd5) 78 | 79 | --- 80 | 81 | FULL / HALF DUPLEX 82 | 83 | HALF DUPLEX: 84 | 85 | - Device cannot send / receive data at the same time. If it is receiving a frame, it must wait before sending a frame. 86 | 87 | FULL DUPLEX: 88 | 89 | - Device CAN send / receive data at the same time. It does NOT have to wait. 90 | 91 | MOST modern SWITCHES support FULL DUPLEX. 92 | 93 | --- 94 | 95 | WHERE is HALF DUPLEX used? Almost nowhere. 96 | 97 | In the past, LAN HUBS used HALF DUPLEX. 98 | 99 | When multiple packets were received by the HUB, the HUB would simple FLOOD the connections with frame data, causing a COLLISION (on the interface), and hosts would not receive the frame intact. 100 | 101 | All devices connected to a HUB are called a COLLISION DOMAIN. 102 | 103 | To DEAL with COLLISIONS, Ethernet devices use a mechanism called CSMA/CD. 104 | 105 | CSMA/CD = CARRIER SENSE MULTIPLE ACCESS with COLLISION DETECTION. 106 | 107 | - Before sending frames, devices 'listen' to the collision domain until they detect that other devices are not sending. 108 | - IF a collision occurs, the device sends a jamming signal to inform the other devices that a collision happened. 109 | - Each device will wait a random period of time before sending frames again. 110 | - The process repeats. 111 | 112 | --- 113 | 114 | SWITCHES are more sophisticated than HUBS. 115 | 116 | HUBS are Layer 1 Devices - Collisions are common and use CSMA/CD. 117 | SWITCHES are Layer 2 Devices - Collisions RARELY occur. 118 | 119 | --- 120 | 121 | ![image](https://github.com/psaumur/CCNA/assets/106411237/feff3816-1449-4282-bc44-71575333a1e0) 122 | 123 | 124 | SPEED / DUPLEX AUTONEGOTIATION 125 | 126 | - Interfaces that can run at different speeds (10/100 or 10/100/1000) have a default setting of SPEED AUTO and DUPLEX AUTO. 127 | - Interfaces 'advertise' their capabilities to the neighbouring device, and they negotiate the best SPEED and DUPLEX settings they are both capable of. 128 | 129 | WHAT if AUTONEGOTIATION is DISABLED on the device connected to the SWITCH ? 130 | 131 | ![image](https://github.com/psaumur/CCNA/assets/106411237/30519cf7-0a79-4996-a8d8-dfac689f4005) 132 | 133 | 134 | - SPEED: The SWITCH will try to send at the speed that the other device is operating at. 135 | If it fails to send the speed, it will use the slowest supported speed (ie: 10 Mbps on a 10/100/1000 interface). 136 | - DUPLEX: If the speed is 10 or 100 Mbps the SWITCH will use HALF DUPLEX. 137 | If the speed is 1000 Mbps or great, it will use FULL DUPLEX. 138 | 139 | --- 140 | 141 | INTERFACE COUNTERS AND ERRORS 142 | 143 | Show using the: 144 | 145 | // Privileged EXEC mode 146 | 147 | SW1#show interfaces 148 | 149 | Error stats will be at the bottom. 150 | 151 | ![image](https://github.com/psaumur/CCNA/assets/106411237/20d6affd-6014-427d-9ad9-c638ace358f8) 152 | 153 | 154 | **Packets Received / Total bytes received.** 155 | 156 | **Runts**: Frames that are smaller than the minimum frame size (64 bytes) 157 | 158 | **Giants**: Frames that are larger than the maximum frame size (1518 bytes) 159 | 160 | **CRC**: Frames that failed the CRC check (in the Ethernet FCS trailer) 161 | 162 | **Frame**: Frames that have an incorrect format (due to an error) 163 | 164 | **Input errors**: Total of various counters, such as the above four 165 | 166 | **Output errors**: Frames the SWITCH tried to send, but failed due to an error 167 | -------------------------------------------------------------------------------- /Course_Notes/TCP_and_UDP.md: -------------------------------------------------------------------------------- 1 | # 30. TCP and UDP (LAYER 4 PROTOCOLS) 2 | 3 | BASICS OF LAYER 4 4 | 5 | - Provides TRANSPARENT transfer of DATA between END HOSTS (Host To Host communication) 6 | 7 | ![image](https://github.com/psaumur/CCNA/assets/106411237/b0309c1e-a283-428b-9d8b-c9c1568e6a58) 8 | 9 | - Provides (or DOESN’T provide) various SERVICES to APPLICATIONS: 10 | - Reliable DATA Transfer 11 | - Error Recovery 12 | - Data Sequencing 13 | - Flow Control 14 | - Provides LAYER 4 ADDRESSING (PORT numbers) - NOT the physical interfaces / ports on network devices 15 | - IDENTIFY the APPLICATION LAYER protocol 16 | - Provides SESSION multiplexing 17 | 18 | --- 19 | 20 | WHAT IS A SESSION ? 21 | 22 | - A SESSION is an EXCHANGE of DATA between TWO or MORE communicating DEVICES 23 | 24 | ![image](https://github.com/psaumur/CCNA/assets/106411237/2d8c6c74-24e5-4574-b454-bc694f056bec) 25 | 26 | The FOLLOWING ranges have been designated by IANA (Internet Assigned Numbers Authority) 27 | 28 | - **Well-Known** Port Numbers : 0 - 1023 29 | - **Registered** Port Numbers : 1024 - 49151 30 | - **Ephemeral** / Private / Dynamic port numbers : 49152 - 65535 31 | 32 | ![image](https://github.com/psaumur/CCNA/assets/106411237/02d56940-33b6-40a8-8431-0a39c19bc66a) 33 | 34 | --- 35 | 36 | TCP (TRANSMISSION CONTROL PROTOCOL) 37 | 38 | - A CONNECTION-ORIENTED protocol 39 | - Before actually SENDING DATA to the DESTINATION HOST, the TWO HOSTS communicate to establish a CONNECTION. Once the CONNECTION is established, DATA exchange begins. 40 | 41 | ![image](https://github.com/psaumur/CCNA/assets/106411237/9fcb7294-da61-4fff-b483-c1da6a8d7b48) 42 | 43 | ![image](https://github.com/psaumur/CCNA/assets/106411237/1f5b0753-b625-463b-9d6f-79bf5b2454dc) 44 | 45 | Establishing connections 46 | 47 | ![image](https://github.com/psaumur/CCNA/assets/106411237/877a8e35-2e2d-4cf4-af65-1a1834308ba9) 48 | 49 | Terminating connections 50 | 51 | ![image](https://github.com/psaumur/CCNA/assets/106411237/3a0a9cff-8bc4-4c1f-a9b0-941807cf6f40) 52 | 53 | - TCP provides RELIABLE communication 54 | - The DESTINATION HOST must acknowledge that it RECEIVED each TCP SEGMENT (Layer 4 PDU) 55 | - If a SEGMENT isn’t ACKNOWLEDGED, it is sent again 56 | 57 | 58 | ![image](https://github.com/psaumur/CCNA/assets/106411237/d8349049-7a5a-40a3-95fa-7ad86ec1049d) 59 | 60 | - TCP provides SEQUENCING 61 | - SEQUENCE numbers in the TCP HEADER allow DESTINATION HOSTS to put SEGMENTS in the correct ORDER even if they arrive out of ORDER 62 | 63 | ![image](https://github.com/psaumur/CCNA/assets/106411237/a1df1c41-df4f-4211-ac56-144280a2d3bf) 64 | 65 | - TCP provides FLOW CONTROL 66 | - The DESTINATION HOST can tell the SOURCE HOST to increase / decrease the RATE that DATA is sent 67 | 68 | ![image](https://github.com/psaumur/CCNA/assets/106411237/f5f3f467-5b1f-4a30-9ef7-8a5c0de65139) 69 | 70 | ![image](https://github.com/psaumur/CCNA/assets/106411237/fafc82c7-21a2-46cf-b82b-702b2d8c1d52) 71 | 72 | --- 73 | 74 | UDP (USER DATAGRAM PROTOCOL) 75 | 76 | ![image](https://github.com/psaumur/CCNA/assets/106411237/773a7e94-50b1-4179-b2e6-0d45ec5c1b3d) 77 | 78 | - UDP is NOT a CONNECTION-ORIENTED PROTOCOL 79 | - The SENDING HOST does NOT establish a CONNECTION with the DESTINATION HOST before sending DATA. The DATA is simply SENT 80 | 81 | - UDP DOES NOT provide reliable COMMUNICATION 82 | - When UDP is used, ACKNOWLEDGEMENTS are NOT SENT for received SEGMENTS 83 | - If a SEGMENT is LOST, UDP has no mechanism to re-TRASMIT it 84 | - SEGMENTS are sent “best-effort” 85 | 86 | - UDP DOES NOT provide SEQUENCING 87 | - There is NO SEQUENCE NUMBER FIELD in the UDP header 88 | - If SEGMENTS arrive out of order, UDP has no MECHANISM to put them back in ORDER 89 | 90 | - UDP DOES NOT provide FLOW CONTROL 91 | - UDP has NO MECHANISM like TCP’s WINDOW SIZE to control the flow of DATA 92 | 93 | - UDP DOES provide ERROR CHECKING (via CHECKSUM) 94 | 95 | --- 96 | 97 | COMPARING TCP AND UDP 98 | 99 | Number of Fields in their Headers 100 | 101 | ![image](https://github.com/psaumur/CCNA/assets/106411237/90fb3d62-5011-4970-9cf6-167cccfe3449) 102 | 103 | - TCP provides MORE FEATURES than UDP but at a COST of ADDITIONAL OVERHEAD 104 | - For applications that require RELIABLE communications (for example, downloading a file), TCP is PREFERRED 105 | - For applications, like real-time voice and video, UDP is preferred 106 | - There are SOME applications that use UDP, but provide RELIABILITY, etc. within the APPLICATION itself. 107 | - Some applications use BOTH TCP and UDP, depending on the situation. 108 | 109 | ![image](https://github.com/psaumur/CCNA/assets/106411237/fcbef599-9277-4b06-8d59-2349ca70817a) 110 | 111 | IMPORTANT PORT NUMBERS 112 | 113 | ![image](https://github.com/psaumur/CCNA/assets/106411237/9e1f0422-d027-4a06-a359-d47c5c39dba1) 114 | -------------------------------------------------------------------------------- /Course_Notes/The_IPv4_Header.md: -------------------------------------------------------------------------------- 1 | # 10. THE IPv4 HEADER 2 | 3 | INTERNET PROTOCOL version 4 HEADER or IPv4 HEADER 4 | 5 | HEADER is used at LAYER 3 to help send data between devices on separate networks, even on other sides of the world over the Internet. 6 | 7 | This is known as ROUTING. 8 | 9 | THE IPv4 HEADER is used to ENCAPSULATE a TCP or UDP Segment. 10 | 11 | To Review: 12 | 13 | ![image](https://github.com/psaumur/CCNA/assets/106411237/64906e3c-0bae-4c2c-96ca-4e6850f3844a) 14 | 15 | 16 | --- 17 | 18 | FIELDS OF THE IPv4 HEADER 19 | 20 | ![image](https://github.com/psaumur/CCNA/assets/106411237/f2667488-2769-4e62-bee7-eddbf9e00058) 21 | 22 | 23 | | FIELD | # OF BITS | 24 | | --- | --- | 25 | | VERSION | 4 | 26 | | IHL | 4 | 27 | | DSCP | 6 | 28 | | ECN | 2 | 29 | | TOTAL LENGTH | 16 | 30 | | IDENTIFICATION | 16 | 31 | | FLAGS | 3 | 32 | | FRAGMENT OFFSET | 13 | 33 | | TIME TO LIVE | 8 | 34 | | PROTOCOL | 8 | 35 | | HEADER CHECKSUM | 16 | 36 | | SOURCE ADDRESS | 32 | 37 | | DESTINATION ADDRESS | 32 | 38 | | OPTIONS | 320 Max | 39 | 40 | --- 41 | 42 | VERSION: 43 | 44 | - LENGTH is 4 bits. 45 | - IDs version of IP used (IPv4 or IPv6) 46 | - IPv4 = 0100 in Binary (Decimal 4) 47 | - IPv6 = 0110 in Binary (Decimal 6) 48 | 49 | --- 50 | 51 | INTERNET HEADER LENGTH (IHL): 52 | 53 | - LENGTH is 4 bits. 54 | - Final field of IPv4 Header (Options) is variable in length so this field is necessary to indicate the total length of the header. 55 | - IDs the length of the header in 4-BYTE INCREMENTS. 56 | - The MINIMUM value is 5 (5 * 4-bytes = 20 bytes) - Empty OPTIONS Field 57 | - The MAXIMUM value is 15 (15 * 4-bytes = 60 bytes) 58 | 59 | MINIMUM IPv4 HEADER LENGTH = 20 Bytes! 60 | MAXIMUM IPv4 HEADER LENGTH = 60 Bytes! 61 | 62 | --- 63 | 64 | DSCP (Differentiated Services Code Point): 65 | 66 | - LENGTH is 6 bits. 67 | - Used for QoS (Quality of Service) 68 | - Used to prioritize delay-sensitive data (streaming voice, video, etc.) 69 | 70 | --- 71 | 72 | ECN (Explicit Congestion Notification): 73 | 74 | - LENGTH is 2 bits. 75 | - Provides end-to-end (between two endpoints) notification of network congestion WITHOUT dropping packets. 76 | - Optional feature that requires both endpoints, as well as the underlying network infrastructure to support it. 77 | 78 | --- 79 | 80 | TOTAL LENGTH: 81 | 82 | - LENGTH is 16 bits. 83 | - Indicates the TOTAL length of the packet (L3 Header + L4 Segment) 84 | - Measured in bytes (not 4-byte increments like IHL) 85 | - Minimum value of 20 Bytes (IPv4 Header with NO encapsulated data) 86 | - Maximum value of 65,535 (MAXIMUM 16-bit value) = 2^16 87 | 88 | --- 89 | 90 | IDENTIFICATION: 91 | 92 | - LENGTH is 16 bits. 93 | - If a packet is fragmented due to being too large, this field is used to identify which packet the fragment belongs to. 94 | - All fragments of the same packet will have their own IPv4 header with the same value in this field. 95 | - Packets are fragmented, if larger than the MTU (Maximum Transmission Unit) 96 | - The MTU is usually 1500 bytes (Max size of an Ethernet frame) 97 | - Fragments are reassembled by the receiving host. 98 | 99 | --- 100 | 101 | FLAGS: 102 | 103 | - LENGTH is 3 bits 104 | - Used to control/identify fragments. 105 | - Bit 0: Reserved, always set to 0. 106 | - Bit 1: Don't Fragment (DF bit), used to indicate a packet that should not be fragmented. 107 | - Bit 2: More Fragments (MF bit), set to 1 if there are more fragments in the packet, set to 0 for the last fragment or NO fragments. 108 | 109 | --- 110 | 111 | FRAGMENT OFFSET: 112 | 113 | - LENGTH is 13 bits 114 | - Used to indicated the position of the fragment within the original, unfragmented IP Packet. 115 | - Allows fragmented packets to be reassembled even if the fragments arrive out of order. 116 | 117 | --- 118 | 119 | TIME TO LIVE (TTL): 120 | 121 | - LENGTH is 8 bits 122 | - A router will drop a packet with a TTL of 0 123 | - Used to prevent infinite loops 124 | - Originally designed to indicated a packets maximum lifetime in seconds. 125 | - In practice, indicates a 'hop count': each time the packet arrives at a router, the router decreases the TTL by 1. 126 | - Recommended default TTL is 64. 127 | 128 | --- 129 | 130 | PROTOCOL: 131 | 132 | - LENGTH is 8 bits 133 | - Indicates the protocol of the encapsulated Layer 4 PDU 134 | - Value of 1 : ICMP 135 | - Value of 6 : TCP 136 | - Value of 17 : UDP 137 | - Value of 89 : OSPF (Dynamic Routing Protocol) 138 | - List of protocol numbers on Wikipedia : List of IP Protocol Numbers 139 | 140 | HEADER CHECKSUM: 141 | 142 | - LENGTH is 16 bits 143 | - A calculated checksum used to check for errors in the IPv4 header. 144 | - When a router receives a packet, it calculates the checksum of the header and compares it to the one in this field of a header. 145 | - If they do not match, the router drops the packet. 146 | - Used to check for ERRORS only in the IPv4 Header. 147 | - IP relies on the encapsulated protocol to detect errors in the encapsulated data. 148 | - Both TCP and UDP have their own checksum fields to detect errors in the encapsulated data. 149 | 150 | --- 151 | 152 | SOURCE and DESTINATION: 153 | 154 | - LENGTH is 32 bits each 155 | - SOURCE IP = IPv4 ADDRESS of the Sender of the Packet. 156 | - DESTINATION IP = IPv4 ADDRESS of the intended Receiver of the Packet. 157 | 158 | --- 159 | 160 | OPTIONS: 161 | 162 | - LENGTH is 0-320 bits 163 | - Optional / Rarely Used 164 | - If the IHL field is greater than 5, it means that Options are present. 165 | -------------------------------------------------------------------------------- /Course_Notes/VLAN_Part1.md: -------------------------------------------------------------------------------- 1 | # 16. VLANS : PART 1 2 | 3 | WHAT IS A LAN ? 4 | 5 | - A LAN is a single BROADCAST DOMAIN, including all devices in that broadcast domain. 6 | 7 | BROADCAST DOMAINS 8 | 9 | - A BROADCAST DOMAIN is the group of devices which will receive a BROADCAST FRAME (Destination MAC : FFFF.FFFF.FFFF) sent by any one of the members. 10 | 11 | Image of LAN with FOUR BROADCAST DOMAINS (192.168.1.0 / 24) 12 | 13 | ![image](https://github.com/psaumur/CCNA/assets/106411237/de712483-e881-41f5-9525-576216186498) 14 | 15 | 16 | Performance : 17 | 18 | Lots of unnecessary BROADCAST traffic can reduce network performance. 19 | 20 | ![image](https://github.com/psaumur/CCNA/assets/106411237/a807fdc5-27b9-4735-8b8d-51bdc0c91a8c) 21 | 22 | 23 | BROADCAST FRAME flooding all our subnets with unnecessary traffic. 24 | 25 | ![image](https://github.com/psaumur/CCNA/assets/106411237/fcd03904-a193-4423-8940-09be1df1bd2c) 26 | 27 | 28 | Security : 29 | 30 | Even within the same office, you want to limit who has access to what. You can apply security policies on a ROUTER / FIREWALL. Because this is one LAN, PC’s can reach each other directly, without traffic passing through the router. So, even if you configure security policies, they won’t have any effect. 31 | 32 | ![image](https://github.com/psaumur/CCNA/assets/106411237/7bd562fc-7dff-4692-81d7-c026b007df8f) 33 | 34 | --- 35 | 36 | WHAT IS A VLAN ? 37 | 38 | VLANS: 39 | 40 | - logically separate end-hosts at LAYER 2 41 | - are configured on Layer 2 SWITCHES on a per-interface basis. 42 | - any END HOST connected to that interface is part of that VLAN 43 | 44 | --- 45 | 46 | PURPOSE OF VLANs: 47 | 48 | Network Performance : 49 | 50 | - Reduce unnecessary BROADCAST traffic, which helps prevent network congestion, and improve network performance 51 | 52 | Network Security : 53 | 54 | - Limiting BROADCAST and unknown UNICAST traffic, also improves network security, since messages won’t be received by devices outside of the VLAN 55 | 56 | ![image](https://github.com/psaumur/CCNA/assets/106411237/fae2f1ed-ffc3-4d91-adf7-16a67c2dc5aa) 57 | 58 | 59 | SWITCHES do not forward traffic directly between HOSTS in different VLANS 60 | 61 | ![image](https://github.com/psaumur/CCNA/assets/106411237/2e5834e9-9096-46eb-bb96-ba8459338107) 62 | 63 | 64 | ![image](https://github.com/psaumur/CCNA/assets/106411237/3046f727-fad4-421e-85ef-63a73e109f83) 65 | 66 | 67 | Sending Packets to another VLAN (Routed through R1) 68 | 69 | ![image](https://github.com/psaumur/CCNA/assets/106411237/7090ef6d-ce8c-454f-b80d-f6dfd82745c8) 70 | 71 | 72 | ![image](https://github.com/psaumur/CCNA/assets/106411237/b7237602-5b46-4c31-bd75-2e50e0fb1017) 73 | 74 | --- 75 | 76 | HOW TO CONFIGURE VLANS ON CISCO SWITCHES 77 | 78 | #show vlan brief 79 | 80 | ![image](https://github.com/psaumur/CCNA/assets/106411237/13ce8382-6aea-484e-9580-d91c98189522) 81 | 82 | 83 | Shows which VLANS that exist on the SWITCH and what INTERFACES are in each VLAN 84 | 85 | VLANs 1 (DEFAULT), 1002-1005 exist by default and **cannot be deleted (5 VLANs)** 86 | 87 | --- 88 | 89 | HOW TO ASSIGN INTERFACES TO A VLAN 90 | 91 | ![image](https://github.com/psaumur/CCNA/assets/106411237/ed31145d-7949-4c68-b88a-97716beaf074) 92 | 93 | 94 | 1) Use the “interface range” command to select all the interfaces at once 95 | 96 | 2) Use the “switchport mode access” command to set the interface as an ACCESS PORT 97 | 98 | --- 99 | 100 | WHAT IS AN ACCESS PORT? 101 | 102 | - An ACCESS PORT is a SWITCHPORT which belongs to a single VLAN, and usually connects to end hosts like PCs. 103 | 104 | SWITCHPORTS which carry multiple VLANs are called “TRUNK PORTS” (more info on TRUNK in next chapter) 105 | 106 | 3) Use the “switchport access” command to assign a VLAN to a PORT 107 | 108 | ![image](https://github.com/psaumur/CCNA/assets/106411237/b1bdb937-3707-496f-bc49-445df354d16b) 109 | 110 | 111 | Use “#vlan <#>” to enter **Configuration Mode** for a given VLAN (this can also create a VLAN) 112 | 113 | Use “#name ” to configure a NAME for your VLAN 114 | 115 | To check your VLAN configuration, use “#show vlan brief” 116 | 117 | ![image](https://github.com/psaumur/CCNA/assets/106411237/2f7d26d8-9b2a-43a3-b213-fec4f984a309) 118 | 119 | 120 | Testing VLAN 10 121 | 122 | Pinging from PC1 using 255.255.255.255 (FFFF:FFFF:FFFF) floods broadcast packets to R1 and VLAN10 hosts only 123 | 124 | ![image](https://github.com/psaumur/CCNA/assets/106411237/5c64e485-f492-4436-9c1d-3a1ab20fbe05) 125 | -------------------------------------------------------------------------------- /Course_Notes/VLAN_Part2.md: -------------------------------------------------------------------------------- 1 | # 17. VLANS : PART 2 2 | 3 | Basic VLAN topology from PART 1 4 | 5 | ![image](https://github.com/psaumur/CCNA/assets/106411237/f6df37e0-d494-4e46-b6e8-6d2ba0cd0ff6) 6 | 7 | 8 | What about THIS Network Topology ? 9 | 10 | ![image](https://github.com/psaumur/CCNA/assets/106411237/e6aff877-3792-469f-8955-0f3e17c6f1ed) 11 | 12 | 13 | Notice this one has TWO Switches (SW1 and SW2) and ENGINEERING (VLAN 10) has two separate locations on the network. 14 | 15 | --- 16 | 17 | TRUNK PORTS 18 | 19 | - In a small network with few VLANS, it’s possible to use a separate interface for EACH VLAN when connecting SWITCHES to SWITCHES, and SWITCHES to ROUTERS 20 | 21 | - HOWEVER, when the number of VLANS increases, this is not viable. It will result in wasted interfaces, and often ROUTERS won’t have enough INTERFACES for each VLAN 22 | 23 | - You can use TRUNK PORTS to carry traffic from multiple VLANS over a single interface 24 | 25 | A TRUNK PORT carrying multiple VLAN connections over single interface 26 | 27 | ![image](https://github.com/psaumur/CCNA/assets/106411237/5cb7c933-689a-499b-9f30-51fe63d8b059) 28 | 29 | 30 | ![image](https://github.com/psaumur/CCNA/assets/106411237/8ea9a799-cf0d-4b1d-9706-db002772fe6d) 31 | 32 | 33 | How does a packet know WHICH VLAN to send traffic to over the TRUNK PORT ? 34 | 35 | VLAN TAGS ! 36 | 37 | SWITCHES will “tag” all frames that they send over a TRUNK LINK. This allows the receiving SWITCH to know which VLAN the frame belongs to. 38 | 39 | TRUNK PORT = “Tagged” ports 40 | 41 | ACCESS PORT = “Untagged” ports 42 | 43 | --- 44 | 45 | VLAN TAGGING 46 | 47 | - There are TWO main TRUNK protocols: 48 | - ISL (Inter-Switch Link) 49 | - IEEE 802.1Q (also known as “dot1q”) 50 | 51 | ISL is an old Cisco proprietary protocol created before industry standard IEEE 802.1Q 52 | 53 | IEEE 802.1Q is an industry standard protocol created by the IEEE (Institute of Electrical and Electronics Engineers) 54 | 55 | You will probably NEVER use ISL in the real world; even modern Cisco equipment doesn’t use it. 56 | 57 | For the CCNA, you will only need to learn 802.1Q 58 | 59 | --- 60 | 61 | ETHERNET HEADER with 802.1Q 62 | 63 | ![image](https://github.com/psaumur/CCNA/assets/106411237/00e817cd-1cac-44c5-a5f6-5459d383236d) 64 | 65 | 66 | - The 802.1Q TAG Is inserted between the SOURCE and TYPE/LENGTH fields in the ETHERNET FRAME 67 | - The TAG is 4 bytes (32 bits) in length 68 | - The TAG consists of TWO main fields: 69 | - Tag Protocol Identifier (TPID) 70 | - Tag Control Information (TCI) 71 | - TCI consists of THREE sub-fields: 72 | 73 | ![image](https://github.com/psaumur/CCNA/assets/106411237/8e52856b-58b9-448e-a007-254973fe707e) 74 | 75 | 76 | TPID (TAG Protocol Identifier) : 77 | 78 | - 16 bits (2 bytes) in length 79 | - Always set to a value of 0x8100. This indicates that the frame is 802.1Q TAG 80 | 81 | TCI / PCP (Priority Code Point) : 82 | 83 | - 3 bits in length 84 | - Used for Class of Service (CoS), which prioritizes important traffic in congested networks 85 | 86 | TCI / DEI (Drop Eligible Indicator) : 87 | 88 | - 1 bit in length 89 | - Used to indicated frames that can be dropped if the network is congested 90 | 91 | TCI / VID (VLAN ID) : 92 | 93 | - 12 bits in length 94 | - Identifies the VLAN the frame belongs to 95 | - 12 bits in length = 4096 total VLANS (2^12), range of 0 - 4095 96 | - VLANs 0 and 4095 are reserved and can’t be used 97 | - Therefore, the actual range of VLANs is 1 - 4094 98 | 99 | NOTE : Cisco’s ISL also had a VLAN range of 1 - 4094 100 | 101 | --- 102 | 103 | VLAN RANGES 104 | 105 | ![image](https://github.com/psaumur/CCNA/assets/106411237/1c55a830-bfdd-423a-9688-334a3dd2bfa3) 106 | 107 | 108 | --- 109 | 110 | NATIVE VLAN 111 | 112 | ![image](https://github.com/psaumur/CCNA/assets/106411237/8b1e09a1-e9c5-410e-ad87-581b95eaca81) 113 | 114 | 115 | ![image](https://github.com/psaumur/CCNA/assets/106411237/f8145795-b3f7-4766-9507-4fba7c743a14) 116 | 117 | 118 | ![image](https://github.com/psaumur/CCNA/assets/106411237/a1811276-c043-4035-9957-800873068615) 119 | 120 | --- 121 | 122 | TRUNK CONFIGURATION 123 | 124 | ![image](https://github.com/psaumur/CCNA/assets/106411237/d73b8f0b-2154-4e7f-8057-7c5b3f5078cc) 125 | 126 | 127 | ![image](https://github.com/psaumur/CCNA/assets/106411237/29313a87-cf16-439c-8a9e-90b518326954) 128 | 129 | Many modern switches do not support Cisco’s ISL at all. They only support 802.1Q (dot1q) 130 | 131 | However, SWITCHES that do support both (like the one I am using in this example) have a TRUNK encapsulation of “AUTO” by default 132 | 133 | To MANUALLY configure the INTERFACE as a TRUNK PORT, you must first set the encapsulation to “802.1Q” or “ISL”. On SWITCHES that only support 802.1Q, this is not necessary 134 | 135 | After you set the encapsulation type, you can then configure the interface as a TRUNK 136 | 137 | 1) Select the interface to configure 138 | 139 | 2) Use “#switchport trunk encapsulation dot1q” to set the encapsulation mode to 802.1Q 140 | 141 | 3) Use “#switchport mode trunk” to manually configure the interface to TRUNK 142 | 143 | ![image](https://github.com/psaumur/CCNA/assets/106411237/6b897fb0-14a3-4e6a-b4e8-e278a6aec08e) 144 | 145 | 146 | Use the “#show interfaces trunk” command to confirm INTERFACES on TRUNK 147 | 148 | ![image](https://github.com/psaumur/CCNA/assets/106411237/d3e144c7-90e3-4ab0-8021-7eb4d1420282) 149 | 150 | 151 | Commands to allow a VLAN on a given TRUNK 152 | 153 | ![image](https://github.com/psaumur/CCNA/assets/106411237/6a60f6ce-55be-4df5-a715-b871e5e461f4) 154 | 155 | 156 | ![image](https://github.com/psaumur/CCNA/assets/106411237/b39b091d-1ea9-4f72-b592-1eeb8ef25f90) 157 | 158 | 159 | Command to change the NATIVE VLAN 160 | 161 | ![image](https://github.com/psaumur/CCNA/assets/106411237/5109becb-27dd-4c63-9c7b-74b6f55e9d5f) 162 | 163 | 164 | ![image](https://github.com/psaumur/CCNA/assets/106411237/36abc437-69cb-4c56-8a59-87479ce01a7f) 165 | 166 | 167 | --- 168 | 169 | Setting up our TRUNKS for this Network 170 | 171 | ![image](https://github.com/psaumur/CCNA/assets/106411237/892b5322-807b-4d76-91cb-a039766794c5) 172 | 173 | 174 | We will need to configure : 175 | 176 | SW1 : g0/0 interface (already configure above this section) 177 | 178 | SW2: g0/0, and g0/1 interface 179 | 180 | SW2 g0/0 181 | 182 | ![image](https://github.com/psaumur/CCNA/assets/106411237/7b313959-b710-4bb6-a281-727ec9477c3e) 183 | 184 | 185 | SW2 g0/1 186 | 187 | ![image](https://github.com/psaumur/CCNA/assets/106411237/c26f17c8-0ec9-4406-ab66-83adf28c8550) 188 | 189 | 190 | What about the ROUTER, R1 ? 191 | 192 | --- 193 | 194 | ROUTER ON A STICK (ROAS) 195 | 196 | ![image](https://github.com/psaumur/CCNA/assets/106411237/66c4ace0-8341-4c9c-8ff5-7c171034df53) 197 | 198 | 199 | ![image](https://github.com/psaumur/CCNA/assets/106411237/b409165d-39e6-4fba-ade1-2451f7e2fa8c) 200 | 201 | 202 | ![image](https://github.com/psaumur/CCNA/assets/106411237/112a2089-5a9e-4b13-945c-6be7f188d6a8) 203 | 204 | 205 | NOTE the Sub-Interface names (like the network diagram) of 0.10, 0.20 and 0.30 206 | 207 | You assign them IP addresses identically like you would a regular interface (using the last usable IP address of a given VLAN subnet) 208 | 209 | Sub-interfaces will appear with the “show ip interface brief” command 210 | 211 | ![image](https://github.com/psaumur/CCNA/assets/106411237/9b7ecbd1-c5f4-4ed0-9988-8fd17e16c9ae) 212 | 213 | 214 | They also appear in the “show ip route” command (Route Table) 215 | 216 | ![image](https://github.com/psaumur/CCNA/assets/106411237/1e9bb3fa-5aca-4883-8aff-52a554dcfba6) 217 | 218 | 219 | ROAS is used to route between multiple VLANs using a SINGLE interface on a ROUTER and SWITCH 220 | 221 | The SWITCH interface is configured as a regular TRUNK 222 | 223 | The ROUTER interface is configured using SUB-INTERFACES. You configure the VLAN tag and IP address on EACH SUB-INTERFACE 224 | 225 | The ROUTER will behave as if frames arriving with a certain VLAN tag have arrived on the SUB-INTERFACE configured with that VLAN tag 226 | 227 | The ROUTER will TAG frames sent out of EACH SUB-INTERFACE with the VLAN TAG configured on the SUB-INTERFACE 228 | -------------------------------------------------------------------------------- /Course_Notes/VLAN_Part3.md: -------------------------------------------------------------------------------- 1 | # 18. VLANS : PART 3 2 | 3 | NATIVE VLAN ON A ROUTER (ROAS) 4 | 5 | ![image](https://github.com/psaumur/CCNA/assets/106411237/838b9835-d17d-4d57-bac1-52f7e3adfd77) 6 | 7 | Native VLAN untagged frames are faster and more efficient (smaller) than tagged ones. 8 | 9 | Let’s reset all SWITCHES (SW1 and SW2) to native vlan 10 10 | 11 | ![image](https://github.com/psaumur/CCNA/assets/106411237/1e903c1b-b814-40b5-aaea-1ba9f3f192c8) 12 | 13 | 14 | 15 | There are **TWO methods** of configuring the native VLAN on a router: 16 | 17 | - Use the command “encapsulation dot1q ” on a Sub-Interface 18 | 19 | ![image](https://github.com/psaumur/CCNA/assets/106411237/2ea65208-6b2a-4cac-a463-982a731c9e24) 20 | 21 | 22 | OR 23 | 24 | - Configure the IP address for the native VLAN on the router’s physical interface (the “**encapsulation dot1q** command is not necessary” 25 | 26 | ![image](https://github.com/psaumur/CCNA/assets/106411237/dabcc3b4-13c3-4d60-abe2-c7cbb5edd4c2) 27 | 28 | 29 | Output of “show running-config” of G0/0 Interface 30 | 31 | ![image](https://github.com/psaumur/CCNA/assets/106411237/37ce4f0f-0ac0-45ce-802f-5fd11057f69d) 32 | 33 | 34 | --- 35 | 36 | LAYER 3 (MULTILAYER) SWITCHES 37 | 38 | ICON APPEARANCE 39 | 40 | ![image](https://github.com/psaumur/CCNA/assets/106411237/0d63f5f9-5efe-4c61-a8e6-3cd6a1161d2a) 41 | 42 | 43 | - A MULTILAYER SWITCH is capable of both SWITCHING and ROUTING 44 | - It is LAYER 3 AWARE 45 | - You can assign IP Addresses to its L3 Virtual Interface, like a router 46 | - You can create Virtual Interfaces for each VLAN, and assign IP addresses to those interfaces 47 | - You can configure routes on it, just like a ROUTER 48 | - It can be used for inter-VLAN routing 49 | 50 | ![image](https://github.com/psaumur/CCNA/assets/106411237/af59481b-d0cb-41d7-9eba-7c8d47131c28) 51 | 52 | 53 | SW2 Replaced with a Layer 3 Switch 54 | 55 | Multi-VLAN connections to R1 removed and replaced with a point-to-point Layer 3 connection 56 | 57 | ![image](https://github.com/psaumur/CCNA/assets/106411237/8f3ad167-d774-4fcb-96a5-66e568edead8) 58 | 59 | 60 | - SVIs (Switch Virtual Interfaces) are the virtual interfaces you can assign IP addresses to in a MULTILAYER SWITCH. 61 | - Configure each HOST to use the SVI (NOT the ROUTER R1) as their Gateway Address 62 | - To send traffic to different SUBNETS / VLANS, the PCs will send traffic to the SWITCH, and the SWITCH will route the traffic. 63 | 64 | ![image](https://github.com/psaumur/CCNA/assets/106411237/5409b2cc-f876-4754-afe3-33298930fd7a) 65 | 66 | 67 | ![image](https://github.com/psaumur/CCNA/assets/106411237/953372de-579a-4803-9418-0bd1aeef229d) 68 | 69 | 70 | Clearing R1 configuration to set to work with the Layer 3 Point-to-Point connection 71 | 72 | ![image](https://github.com/psaumur/CCNA/assets/106411237/40354cbe-df39-4a78-97cd-bbb0bc10549c) 73 | 74 | 75 | #no interface : removes the VLAN interface 76 | 77 | #default interface g0/0 : resets the g0/0 interface to it’s default settings 78 | 79 | Then configure the default R1 G0/0 interface’s to IP address : 192.168.1.194 (as per the network diagram) 80 | 81 | Configuration of SW2 to use SVI and the Layer 3 Point-to-Point connection with R1 82 | 83 | ![image](https://github.com/psaumur/CCNA/assets/106411237/24d64087-f98c-4a1e-a07f-3f93f06f93a9) 84 | 85 | 86 | “default interface ” : resets settings on specified interface to defaults 87 | 88 | “ip routing” : **IMPORTANT** command to enable Layer 3 routing on the SWITCH 89 | 90 | “no switchport” : configures the interface from a Layer 2 Switchport to a Layer 3 “routed port” 91 | 92 | The sets the Default Route to R1 (192.168.1.194) so that all traffic leaving the network gets routed through R1’s Gateway of Last Resort (aka The Default Gateway) 93 | 94 | ![image](https://github.com/psaumur/CCNA/assets/106411237/7a682a2f-3ae3-420b-8f68-9e1050dd82c6) 95 | 96 | 97 | ![image](https://github.com/psaumur/CCNA/assets/106411237/c0b544b7-8f32-49ae-9a46-d09390a3d08c) 98 | 99 | 100 | SVI CONFIGURATION ON SW2 (Virtual LAYER 3 ROUTING INTERFACES) 101 | 102 | ![image](https://github.com/psaumur/CCNA/assets/106411237/7c1710fb-40d7-44a4-8336-b037e1c2ea77) 103 | 104 | 105 | 106 | SVIs are **shut down** by default, so remember to use “no shutdown” 107 | 108 | ![image](https://github.com/psaumur/CCNA/assets/106411237/2b5b13c3-1364-4296-886c-0bd9b00b4167) 109 | 110 | 111 | Creating an unknown SVI (VLAN 40) and the Status/Protocol is “down/down” 112 | 113 | What are the conditions for a SVI to be “up/up” ? 114 | 115 | - The VLAN must exist on the SWITCH 116 | - The SWITCH must have at least ONE access port in the VLAN in an “up/up” state AND/OR one TRUNK port that allows the VLAN that is in an “up/up” state 117 | - The VLAN must not be shutdown (you can use the “shutdown” command to disable a VLAN) 118 | - The SVI must not be shutdown (SVIs are disabled, by default) 119 | 120 | ![image](https://github.com/psaumur/CCNA/assets/106411237/558ef418-5902-42d0-b4a5-cce14b56b77e) 121 | 122 | 123 | The VLAN trunk has been successfully replaced by an Layer 3 SWITCH SVI. 124 | 125 | All hosts should be able to connect with each other (tested with “ping”) as well as reach the external internet (via the Cloud symbol attached to R1) 126 | -------------------------------------------------------------------------------- /Course_Notes/Virtualization_Containers.md: -------------------------------------------------------------------------------- 1 | # 54. VIRTUALIZATION (CONTAINERS): PART 2 2 | 3 | REVIEW OF VIRTUAL MACHINES (TYPE 1 and TYPE2 HYPERVISORS) 4 | 5 | ![image](https://github.com/psaumur/CCNA/assets/106411237/bfc801ca-a603-4957-a67c-316fb72e25cb) 6 | 7 | ![image](https://github.com/psaumur/CCNA/assets/106411237/da1b653d-f5f2-42d3-8088-dd3daa430913) 8 | 9 | - VIRTUAL MACHINES (VMs) allow multiple OS’s to run on a single PHYISCAL SERVER 10 | - A HYPERVISOR is used to manage and allocate HARDWARE RESOURCES to each VM 11 | - TYPE 1 HYPERVISORS (aka NATIVE or BARE-METAL) run directly on top of HARDWARE 12 | - TYPE 2 HYPERVISORS (aka HOSTED) run on top of a HOST OS (ie: WINDOWS) 13 | - TYPE 1 HYPERVISORS are widely used in DATA CENTER ENVIRONMENTS 14 | - TYPE 2 HYPERVISORS are commonly used on personal DEVICES 15 | - Running a virtual network lab on your PC using Cisco Modeling Labs (CML) 16 | 17 | - The OS in each VM can be the same or different (Windows, Linux, MacOS, etc) 18 | - *Bins / Libs* are the SOFTWARE libraries / services needed by the Apps running in each VM 19 | - A VM allows it’s app / apps to run in an ISOLATED environment, separate from the apps in other VMs. 20 | - VMs are easy to create, delete, move, etc. 21 | - A VM can be easily saved and moved between different physical SERVERS. 22 | 23 | ![image](https://github.com/psaumur/CCNA/assets/106411237/5ed6704c-f332-49bf-8ff9-ad17a7f74b76) 24 | 25 | --- 26 | 27 | CONTAINERS 28 | 29 | ![image](https://github.com/psaumur/CCNA/assets/106411237/4f350818-f030-46fe-8850-f2e633d22bfa) 30 | 31 | - CONTAINERS are software packages that contain an APP and all dependencies (*Bins/Libs* in the diagram) for the contained APP to run. 32 | - Multiple APPS can be run in a single CONTAINER, but this is not how CONTAINERS are usually used 33 | - CONTAINERS run on a CONTAINER ENGINE (ie: DOCKER ENGINE) 34 | - The CONTAINER ENGINE is run on a HOST OS (usually LINUX) 35 | - CONTAINERS are lightweight (small in size) and include only the dependencies required to run the specific APP 36 | - A CONTAINER ORCHESTRATOR is a software platform for automating the DEPLOYMENT, MANAGEMENT, SCALING, etc of CONTAINERS 37 | - KUBERNETES (originally design by Google) is the most popular CONTAINER ORCHESTRATOR 38 | - DOCKER SWARM is DOCKER’S CONTAINER ORCHESTRATION tool 39 | - In small numbers, MANUAL operation is possible, but large-scale systems (ie: with Microservices) can require THOUSANDS of CONTAINERS 40 | 41 | ![image](https://github.com/psaumur/CCNA/assets/106411237/07083826-c7b0-45c1-aefe-e05f63d7acfd) 42 | 43 | --- 44 | 45 | VIRTUAL MACHINES vs. CONTAINERS 46 | 47 | ![image](https://github.com/psaumur/CCNA/assets/106411237/98a4075d-ab70-4579-ba10-c129e935ca22) 48 | 49 | - VMs can TAKE MINUTES to boot up as each VM runs it’s own OS 50 | - CONTAINERS can boot up in milliseconds 51 | 52 | - VMs take MORE disk space (Gigabytes) 53 | - CONTAINERS take up VERY LITTLE disk space (Megabytes) 54 | 55 | - VMs use MORE CPU/RAM resources (each VM must run its own OS) 56 | - CONTAINERS use FEWER CPU/RAM resources (shared OS) 57 | 58 | - VMs are PORTABLE and can MOVE between physical systems running the same HYPERVISOR 59 | - CONTAINERS are MORE portable; they are SMALLER, FASTER to boot up, and DOCKER CONTAINERS can be run on nearly ANY CONTAINER SERVICE 60 | 61 | - VMs are more isolated because each VM runs it’s own OS 62 | - CONTAINERS are less isolated because they all run on the same OS; if the OS crashes, all CONTAINERS running on it are effected 63 | 64 | ![image](https://github.com/psaumur/CCNA/assets/106411237/128a8574-a555-4a3e-9e9c-62f33df2d34d) 65 | -------------------------------------------------------------------------------- /Course_Notes/Virtualization_VRF_Part3.md: -------------------------------------------------------------------------------- 1 | # 54. VIRTUALIZATION (VRF): PART 3 2 | 3 | INTRO TO VRF 4 | 5 | ![image](https://github.com/psaumur/CCNA/assets/106411237/e122f3c6-290f-4f33-a31d-f308f12140a3) 6 | 7 | - VIRTUAL ROUTING AND FORWARDING (VRF) is used to DIVIDE a SINGLE ROUTER into MULTIPLE VIRTUAL ROUTERS 8 | - Similar to how VLANs are used to divide a SINGLE SWITCH (LAN) into MULTIPLE VIRTUAL SWITCHES (VLANs) 9 | - It does this by allowing a ROUTER to build MULTIPLE SEPARATE ROUTING TABLES 10 | - INTERFACES (LAYER 3 only) and ROUTERS are configured to be in a specific VRF (aka *VRF INSTANCE*) 11 | - ROUTER INTERFACES, SVIs and ROUTED PORTS on MULTILAYER SWITCHES can be configured in a VRF 12 | - TRAFFIC in one VRF cannot be forwarded out of an INTERFACE in another VRF 13 | - As an exception, VRF LEAKING can be configured to allow traffic to pass BETWEEN VRFs 14 | - VRF is commonly used to facilitate MPLS (Multiple Protocol Label Switching) 15 | - The kind of VRF we are talking about is VRF-Lite (VRF without MPLS) 16 | - VRF is commonly used by SERVICE PROVIDERS to allow ONE DEVICE to carry traffic from MULTIPLE CUSTOMERS 17 | - Each CUSTOMER’S TRAFFIC is isolated from the OUTSIDE 18 | - CUSTOMER IP ADDRESSES can overlap without issue 19 | 20 | VRF CONFIGURATION 21 | 22 | ![image](https://github.com/psaumur/CCNA/assets/106411237/fec7669b-8868-4529-81fa-6f52e07ff6e4) 23 | 24 | Creation and Configuration of VRFs 25 | 26 | ![image](https://github.com/psaumur/CCNA/assets/106411237/624ebfc0-c7c0-498d-a00b-c19e2738585a) 27 | 28 | How to `show ip route` for VRFs 29 | 30 | ![image](https://github.com/psaumur/CCNA/assets/106411237/cbe724be-4497-4976-9927-18ff5c71a4c7) 31 | 32 | `ping` other VRFs 33 | 34 | ![image](https://github.com/psaumur/CCNA/assets/106411237/f29dd935-0ec7-4756-b24a-fc44391254c0) 35 | --------------------------------------------------------------------------------