diff --git a/404.html b/404.html index 99d2b69c..49b47088 100644 --- a/404.html +++ b/404.html @@ -14,7 +14,7 @@ - + diff --git a/Contact/index.html b/Contact/index.html index e95c2fee..157f84d6 100644 --- a/Contact/index.html +++ b/Contact/index.html @@ -18,7 +18,7 @@ - + @@ -2516,7 +2516,7 @@
I have decided not to port any previous content to this site. I'm starting from scratch.
I'm Luke. Currently employed as a Network Architect in London.
Here you will find my Resume, my new Blog, and some Network related content.
I'm open to new and compelling opportunities in the Network Automation realm
If you have a role that you think I might be interested in, please get in touch. You have my thanks and appreciation.
My door is open. You can Hire Me
I'm open to new opportunities in London.
Luke's LinkedIn
Luke's Mail
Luke's GitHub
Luke's Acclaim
Resume Word Download
Resume PDF Download
Book a Meeting
You can Read my Blog
It's, unapologetically, of dubious quality.
Some highlights you may consider:
AutoCon Zero 2023
Cisco Live EMEA 2023
Cisco Live Vegas 2022
Or, for something even more frivolous:
Here's my Book Recommendations
And my Favourite Quotes
Other than that, these pages provide a rudiment of information covering my interests in Network Automation as a career journey captured by the Epics:
This content is limited. It's less than MVP. And nothing close to MLP. It's Dev in progress.
Basic Network Theory
The fundamentals of TCP/IP Networks.
Some initial content you may consider:
Introduction to CIDR & VLSM ...
Introduction to DNS ...
Introduction to NAC ...
Infrastructure as Code
The path to Network as Code.
Introduction to Version Control ...
These Pages are built with Mkdocs ...
The Network Sources of Truth ...
Luke Richardson is currently employed as Network Architect in London.
Network Architect Hello@Lukeoson.com Linkedin +447376209455 lukeoson Acclaim
Network Architect Hello@Lukeoson.com Linkedin +447376209455 lukeoson Acclaim Please don't hesitate to book time with my Calendly.
Luke's Employment in the Technology Industry includes WeWork & Dimension Data.
gantt\ndateFormat YYYY\ntitle Luke's Career Path\n\nsection Dimension Data\nProject Management & Network Engineer :done, 2012, 2017\n\nsection Redstone\nNetwork Engineer :done, 2017, 2018\n\nsection Sabbatical\nPeace & Quiet :done, 2018, 2019\n\nsection WeWork\nNetwork Architect - Global :done, 2019, 2023\n\nsection Lloret Control Systems\nNetwork Architect :active, 2023, 2025
Luke's Education includes a BA in Politics prior to his various Tech Industry roles.
This chart shows a timeline of Luke's Professional Certifications and upcoming expiry.
gantt\ndateFormat YYYY\ntitle Luke's Learning Path \n\nsection You Tube \nStay Curious :active, 2019, 2025\n\nsection CCNA \nCisco Route & Switch :done, 2019, 2022\n\nsection JNCIA-Junos \nJuniper Networks Certified Associate - Junos :active, 2020, 2025\n\nsection JNCIA-DevOps \nJuniper Networks Certified Associate - DevOps :active, 2020, 2025\n\nsection JNCIA-Secuirty \nJuniper Networks Certified Associate - Security :active, 2020, 2025\n\nsection JNCIA-Mist \nJuniper Networks Certified Associate - Mist :active, 2020, 2025\n\nsection Juniper Associate x 4 \nJuniper JNCIA x 4 :active, 2021, 2025 \n\nsection JNCIS-DevOps \nJuniper Networks Certified Specialist - DevOps :active, 2021, 2025 \n\nsection JNCIS-ENT \nJuniper Networks Certified Specialist - ENT :active, 2023, 2025 \n\nsection JNCIS-Mist \nJuniper Networks Certified Specialist - Mist :active, 2023, 2025 \n\nsection Juniper Specialist x3 \nJuniper JNCIS x 3 :active, 2023, 2025 \n\nsection Juniper Innovator\nJuniper Networks Innovator :done, 2023, 2024 \n\nsection GitLab Associate \nGitLab Certified Git Associate :active, 2021, 2025 \n\nsection AWS Certified Cloud\nAWS Certified Cloud :active, 2021, 2025 \n\nsection Okta Professional \nOkta Certified Professional :done, 2021, 2024 \n\nsection GitHub\nGitHub Foundations :active, 2023, 2025\n\nsection Allied Telesis \nAllied Telesis Professional ENT :active, 2023, 2025\n\nsection Lost to Time\nMultiple others not stored in Credly :done, 2020, 2025
Luke's Career story is of accending rigour & complexity (1) Smartly Summarised
Lloret Control Systems
Greenfield Architecture of Cisco, Meraki, Aruba, & Allied Telesis.
At Lloret, i'm regretfully unfulfilled with the industry segment. I'm looking for something more inspiring that embraces the paradigm shift toward Infrastructure as Code.
Network Design mapping Client Specifications to constraints. Requirements delivered in strict adherence to defined budget. Managed multitudinous stakeholders expectations. Built a frame of reference for future project pipelines. Delivered in strict adherence to defined timeline.
WeWork
Key contributor to the global Network Architecture.
Circa 750 Branches spanning >100 Countries with x4 Data Centres in x3 Continents.
Transition the Global Branch Network to Juniper Full Stack. Radically reduced outages & increased network performance. Accommodations for budget & logistics constraints. Enabled the Golden Config for global standardisation. Completed refresh of First Generation Branches by 2023.
Key contributor to the global Network Automation & Orchestration Strategy.
Much nuance here, lessons learnt and all that jazz.
Incorporate the Branch Network into a code pipeline. Reduce the time to deploy a change from days to minutes. Built block by block. Source of Truth & Assurance first. Radically reduce team toil & increased Member MPS. Complete the transition to Infrastructure as Code by 2023.
Owner & Keeper of Nautobot & Netbox Sources of Truth & IPFabric Network Assurance.
Network to Code & IPFabric are wonderful companies - I joyfully advocate for!
Built Nautobot in AWS & IPFabric as distributed On-Premise. Accurate Database of >10,000 network devices. No Diff. Cross Functional collaboration with DevOps & Security. Ensure we have viable Sources of Truth both actual & desired. Complete the transition to Infrastructure as Code by 2023.
Administrative duties of Splunk Cloud Observability & Okta SSO.
An unexpected void following Layoffs - I was eager to help!
Be the gateway for SSO configuration & access in Network Systems. Configuration & Access verified by Cyber Compliance Team. Training & Documentation for Okta & Splunk. Ensured the Network Team had the correct access to the correct systems. Completed the transition to SSO Okta for capable Systems by 2023.
Luke's Hobbies occupied much of his twenties as he pursued adventure sports.
Alas, time flies, he is now 38 years old and primarily focused on his career.
Luke's life tree looks like this:
\u279c Interests tree\n.\n\u251c\u2500\u2500 Adventure\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 Mountains\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 Rock Climbing\n\u251c\u2500\u2500 Politics\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 Influential-People\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 Power-Structures # Non polarizing! Curiosity devoid of emotion. \n\u2514\u2500\u2500 Technology\n \u251c\u2500\u2500 Infrastructure as Code\n \u2514\u2500\u2500 Network Engineering\n
Luke's 2022 WeWork Performance Review
If you would like a reference, Brandon Ross would be a useful starting point.
Describe how Luke has successfully delivered business impact:
\"Luke is exceptionally good at identifying technology business opportunities and delivering on them. Luke's management of IPFabric and Netbox have been stellar.\"
Brandon Ross, Network Architecture Director, WeWork
Describe how Luke could work to further elevate their business impact:
\"Luke should continue his excellent progress at building relationships with other stakeholders around Wework.\"
Categorize Luke's proficiency across each impact driver:
>>>>>>>>>>>>>>
`>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Thanks for taking the time to read my resume. Please get in touch. \ud83c\udf89
pending
pedning
IPv4 addresses are assigned by IANA (Internet Assigned Numbers Authority).
They allocate routable IP addresses to ISPs (Internet Service Providers).
ISPs assign routable IP addresses to customers.
Google IPv6 Adoption Tracker
Example IPv6 Address: 2001:0db8:85a3:0000:0000:8a2e:0370:7334
2001:0db8:85a3:0000:0000:8a2e:0370:7334
2001:db8:85a3:0:0:8a2e:370:7334
::
2001:db8:85a3::8a2e:370:7334
Note
Dropping leading zeros in IPv6 addresses still makes sense because each field in an IPv6 address is understood to be a fixed size of 16 bits, represented in hexadecimal. When you see a field like 0db8, it's clear that it represents four hexadecimal digits, even if it's written as db8. The leading zero doesn't add any additional information because the size of the field is already established.
graph LR\n A[IPv6 Address] --> B[Group 1]\n A --> C[Group 2]\n A --> D[Group 3]\n A --> E[Group 4]\n A --> F[Group 5]\n A --> G[Group 6]\n A --> H[Group 7]\n A --> I[Group 8]\n\n B --> B1[16 bits<br>Hex: 2001]\n C --> C1[16 bits<br>Hex: 0db8]\n D --> D1[16 bits<br>Hex: 85a3]\n E --> E1[16 bits<br>Hex: 0000]\n F --> F1[16 bits<br>Hex: 0000]\n G --> G1[16 bits<br>Hex: 8a2e]\n H --> H1[16 bits<br>Hex: 0370]\n I --> I1[16 bits<br>Hex: 7334]\n\n style A fill:#f9f,stroke:#333,stroke-width:4px\n style B fill:#ccf,stroke:#f66,stroke-width:2px\n style C fill:#ccf,stroke:#f66,stroke-width:2px\n style D fill:#ccf,stroke:#f66,stroke-width:2px\n style E fill:#ccf,stroke:#f66,stroke-width:2px\n style F fill:#ccf,stroke:#f66,stroke-width:2px\n style G fill:#ccf,stroke:#f66,stroke-width:2px\n style H fill:#ccf,stroke:#f66,stroke-width:2px\n style I fill:#ccf,stroke:#f66,stroke-width:2px
Network Congestion: Broadcast packets are sent to all devices on a network segment, regardless of whether they're the intended recipient. This means every device has to process these packets, even if they're irrelevant. On a busy network, this can lead to a lot of unnecessary data traffic, congesting the network.
Resource Drain: Each device on the network must process and determine the relevance of broadcast packets. This can be a drain on resources, especially on devices that might already be running heavy tasks. It's like getting a bunch of irrelevant group emails; you have to check each one, just in case.
Reduced Performance: High levels of broadcast traffic can slow down the overall network performance. Devices spend time and processing power handling these broadcasts, which could be better spent on actual data transmission relevant to their tasks.
Security Concerns: Broadcasts can be a security risk. They can potentially be used for malicious activities like broadcast storms or as a method to discover devices on a network by an attacker.
The goal in network design and management is, therefore, to keep broadcast traffic as minimal as possible. This can be achieved by:
In essence, minimizing broadcast packets helps maintain a smoother, faster, and more secure network. It's like keeping public announcements in a big building to only the floors that need to hear them, rather than blasting them everywhere!
CIDR stands for \"Classless Inter-Domain Routing.\" It's a method used for allocating IP addresses and routing Internet Protocol packets. CIDR replaced the older system based on classes A, B, and C in the 1990s.
We call slash notation \"CIDR notation\" because it's a key component of Classless Inter-Domain Routing (CIDR), which is a method for allocating IP addresses and routing decisions. The slash notation is a concise way to represent an IP address and its associated routing prefix.
Class A: Large networks, 0-126.
0xxxxxxx | First bit is OFF.
Class B: Medium networks, 128-191.
10xxxxxx | First bit is ON, Second bit is OFF.
Class C: Small networks, 192-223.
110xxxxx | First two bits are ON, Third bit is OFF.
Class D: Multicast groups, 224-239.
1110xxxx | First three bits are ON, Fourth bit is OFF.
Class E: Experimental use, 240-255.
1111xxxx | First four bits are ON.
Luke's favourite Visual Subnet Calc from davidc.net.
A common Book and associated YouTube.
A common introductory source of info at How to Network.com.
Lets start with a Class C network stealing 2 bits from Hosts.
How about 192.168.100.0/26
Let's start with a Class B network stealing 3 bits from Hosts.
How about 172.16.0.0/19
Let's start with a Class A network stealing 4 bits from Hosts.
How about 10.0.0.0/12
MAC Addresses are 48 bits long.
IPv6 Addresses are 128 bits long.
Made of 16 Symbols
More User-Friendly Than Binary
Base-16 Numbering System: Hexadecimal is a base-16 system. Power of 16.
Binary is Base-2: Binary is a base-2 system. Power of 2.
Decimal is Base-10: Power of 10. 10 Digits! Caveman Counting.
graph TD\n subgraph A[Decimal]\n A1[0]\n A2[1]\n A3[2]\n A4[3]\n A5[4]\n A6[5]\n A7[6]\n A8[7]\n A9[8]\n A10[9]\n A11[10]\n A12[11]\n A13[12]\n A14[13]\n A15[14]\n A16[15]\n end\n\n subgraph B[Hexadecimal]\n B1[0]\n B2[1]\n B3[2]\n B4[3]\n B5[4]\n B6[5]\n B7[6]\n B8[7]\n B9[8]\n B10[9]\n B11[A]\n B12[B]\n B13[C]\n B14[D]\n B15[E]\n B16[F]\n end\n\n A1 --> B1\n A2 --> B2\n A3 --> B3\n A4 --> B4\n A5 --> B5\n A6 --> B6\n A7 --> B7\n A8 --> B8\n A9 --> B9\n A10 --> B10\n A11 --> B11\n A12 --> B12\n A13 --> B13\n A14 --> B14\n A15 --> B15\n A16 --> B16
set ip 10.1.0.1 255.255.0.0 #LAN\nset ip 10.70.0.1 255.255.0.0 #STAFF\nset ip 10.110.0.1 255.255.0.0 #BYOD\nset ip 10.120.0.1 255.255.0.0 #GUEST\n
site002 $ get system arp \nAddress Age(min) Hardware Addr Interface\n10.70.3.5 0 64:79:f0:45:eb:56 lloret_staff\n10.70.3.72 15 c4:9d:ed:ad:27:d9 lloret_staff\n10.120.0.32 1 d2:eb:db:14:f6:d5 lloret_guest\n10.70.241.1 1 c0:56:e3:50:32:94 lloret_staff\n10.120.0.44 1 66:c9:6a:28:bd:73 lloret_guest\n10.70.3.29 0 d8:bb:c1:0e:e7:8e lloret_staff\n10.70.3.41 0 f4:a8:0d:5c:e5:82 lloret_staff\n10.120.0.68 1 ce:d9:90:ca:85:38 lloret_guest\n10.70.0.206 0 00:0c:29:95:86:5a lloret_staff\n10.70.0.17 0 00:11:32:b4:fd:93 lloret_staff\n10.70.3.53 3 e0:4f:43:e3:c0:b3 lloret_staff\n10.110.0.40 3 26:39:93:9a:9c:c0 lloret_byod\n10.70.240.100 12 6c:4b:90:6b:a1:d6 lloret_staff\n10.120.0.25 1 ce:91:23:e7:02:c0 lloret_guest\n10.70.3.10 3 d8:5e:d3:ae:d4:3c lloret_staff\n10.70.3.77 0 28:16:a8:04:d8:a7 lloret_staff\n10.70.3.22 0 08:3a:88:6d:d2:45 lloret_staff\n10.70.1.69 0 1c:69:7a:64:db:5f lloret_staff\n10.70.3.34 0 6c:24:08:2c:05:dd lloret_staff\n10.110.0.21 0 5a:20:ea:cb:62:b7 lloret_byod\n10.70.3.46 0 f8:75:a4:7f:21:f2 lloret_staff\n10.70.0.10 0 9c:8e:99:4b:9d:68 lloret_staff\n10.1.0.241 1 78:bc:1a:ad:ed:52 lan\n10.120.0.73 1 ba:cc:77:f4:f0:2b lloret_guest\n10.70.3.70 0 f8:75:a4:7f:40:25 lloret_staff\n10.120.0.30 1 0e:4a:68:ac:9d:e3 lloret_guest\n10.70.3.15 1 50:a4:d0:61:13:bd lloret_staff\n10.70.243.153 1 58:fd:b1:56:7c:81 lloret_staff\n10.1.0.21 3 24:9a:d8:2b:16:79 lan\n10.70.3.27 1 6c:4b:90:59:5e:b7 lloret_staff\n10.70.3.39 0 98:ee:cb:ea:0a:70 lloret_staff\n10.70.3.51 0 44:39:c4:34:ee:5c lloret_staff\n10.70.0.15 0 00:11:32:e9:02:2b lloret_staff\n10.1.0.246 1 08:4f:a9:fd:86:c4 lan\n10.120.0.23 0 a2:60:df:48:18:97 lloret_guest\n10.70.2.248 0 b8:27:eb:3f:36:43 lloret_staff\n10.70.3.8 0 50:a4:d0:61:3b:5f lloret_staff\n10.70.3.20 0 50:a4:d0:61:3b:68 lloret_staff\n10.70.3.32 0 04:ec:d8:26:6b:cd lloret_staff\n10.70.3.44 0 48:2a:e3:aa:f5:e4 lloret_staff\n10.70.3.56 1 50:a4:d0:61:3b:44 lloret_staff\n10.120.0.83 1 3e:93:08:cd:7d:00 lloret_guest\n10.70.3.13 1 50:a4:d0:61:3a:6c lloret_staff\n10.70.243.151 8794 88:c9:b3:d0:17:4f lloret_staff\n10.120.0.40 2 62:ca:9e:c2:99:c6 lloret_guest\n10.70.3.25 0 24:9a:d8:0d:1d:d1 lloret_staff\n10.70.3.49 0 28:16:a8:01:87:f5 lloret_staff\n10.1.0.244 1 5c:5a:c7:57:c4:20 lan\n10.70.3.61 0 a4:f9:33:4d:7c:68 lloret_staff\n10.70.3.6 0 f4:a8:0d:32:44:12 lloret_staff\n10.70.3.18 1 50:a4:d0:61:3a:e4 lloret_staff\n86.188.216.217 0 54:a2:74:27:f7:11 wan1\n10.120.0.45 2 56:c0:73:c9:11:da lloret_guest\n10.70.3.30 0 d8:5e:d3:ae:d4:3b lloret_staff\n10.70.243.101 3 00:0e:c6:d3:f1:e4 lloret_staff\n10.70.0.6 2670 9c:b6:54:74:9c:ca lloret_staff\n10.70.3.42 0 10:60:4b:68:0a:8f lloret_staff\n10.70.3.66 0 0c:37:96:15:9e:c7 lloret_staff\n10.70.3.11 0 10:b5:88:06:96:67 lloret_staff\n10.120.0.93 0 26:61:e0:70:54:60 lloret_guest\n10.120.0.38 3 5e:7e:9c:18:45:d0 lloret_guest\n10.70.3.23 3 02:11:32:2f:e9:be lloret_staff\n10.120.0.50 1 42:16:3f:ae:69:02 lloret_guest\n10.70.3.35 0 04:ec:d8:7c:db:de lloret_staff\n10.70.3.47 0 5c:e9:1e:6b:54:a9 lloret_staff\n10.70.0.11 0 02:11:32:27:bb:b6 lloret_staff\n10.1.0.242 1 10:b3:d6:46:49:ee lan\n10.70.3.83 1 e8:eb:1b:11:af:f7 lloret_staff\n10.70.3.28 0 00:0a:b0:07:25:83 lloret_staff\n10.70.3.40 22 40:16:3b:c1:a3:d1 lloret_staff\n10.70.3.52 0 e4:a8:df:95:98:b8 lloret_staff\n10.70.0.16 0 00:11:32:d2:1d:9e lloret_staff\n10.1.0.247 1 78:bc:1a:ad:ee:28 lan\n10.70.3.64 0 d4:3d:7e:7d:fa:89 lloret_staff\n10.70.2.249 0 b8:27:eb:9a:44:39 lloret_staff\n10.70.3.9 0 d8:5e:d3:ae:d2:34 lloret_staff\n10.70.3.21 1 44:39:c4:34:f8:28 lloret_staff\n10.70.3.33 0 14:d6:4d:1f:e5:fa lloret_staff\n10.70.3.45 0 f4:a8:0d:31:df:d1 lloret_staff\n10.70.242.100 52 00:80:f4:46:e9:a2 lloret_staff\n10.70.3.57 2 98:ee:cb:a5:d7:b6 lloret_staff\n10.1.1.12 4 30:b5:c2:cd:9c:6e lan\n10.70.3.2 8432 9c:50:d1:20:49:01 lloret_staff\n10.70.3.69 0 98:ee:cb:b7:23:61 lloret_staff\n10.120.0.29 0 a2:9b:d9:63:07:4f lloret_guest\n10.70.3.14 2 08:3a:88:69:34:be lloret_staff\n10.70.3.81 5 98:ee:cb:9c:3c:48 lloret_staff\n10.70.3.26 5 60:70:c0:48:f6:e4 lloret_staff\n10.70.3.38 0 d8:80:83:3f:58:fb lloret_staff\n10.70.0.14 5 00:11:32:8a:ac:85 lloret_staff\n10.1.0.245 1 08:4f:a9:ae:44:d4 lan\n10.70.3.62 1 8c:89:a5:3c:bf:bf lloret_staff\n192.168.1.1 0 00:1e:42:15:a3:64 wan2\n10.120.0.22 17 68:ec:c5:b1:8f:0f lloret_guest\n10.120.0.89 1 2a:2a:5d:c2:a0:82 lloret_guest\n10.70.3.74 0 cc:48:3a:c3:2a:67 lloret_staff\n10.70.3.19 0 08:3a:88:6d:6c:59 lloret_staff\n10.70.3.31 0 e0:4f:43:25:04:ab lloret_staff\n10.70.3.55 3 e8:ea:6a:83:df:49 lloret_staff\n10.120.0.82 2 4a:bc:2b:b8:12:89 lloret_guest\n10.120.0.27 0 ca:12:b5:1c:71:18 lloret_guest\n10.70.3.12 1 6c:3c:8c:7a:25:46 lloret_staff\n10.70.243.150 2 00:0a:b0:09:66:11 lloret_staff\n10.70.3.24 0 74:97:79:ec:a4:29 lloret_staff\n10.70.3.36 3 50:a4:d0:61:3b:62 lloret_staff\n10.70.0.12 2 02:11:32:27:ba:55 lloret_staff\n\nsite002 $ \n
This example is specific to the 10.1.0.1/16 subnet, detailing its characteristics and addressing within a Class A network.
Binary: Base-2, uses 0 and 1.
Hexadecimal: Base-16, uses 0-9 and A-F.
Decimal: Base-10, uses 0-9.
What is The OSI Model by Cloudflare ?
The Open Systems Interconnect Model from the International Organization for Standardization
The OSI model was first defined in raw form in Washington, D.C., in February 1978 by French software engineer Hubert Zimmermann, and the refined but still draft standard was published by the ISO in 1980.
It is a reference model. Ultimately, the TCP/IP model is the more practical model for today's networks, but the OSI model is still used to describe network layers and protocols. The US DoD invented the TCP/IP model in the 1970s, and it was used to build the internet. The OSI model was created in the 1980s by the International Organization for Standardization (ISO), and it was designed to be an abstract model for describing network protocols, not a practical model for building networks.
+-----------------------------------+\n | Layer 7: Application |\n | - Data generated by app |\n +-----------------------------------+\n | Layer 6: Presentation |\n | - Data conversion and encoding|\n +-----------------------------------+\n | Layer 5: Session |\n | - Session management |\n +-----------------------------------+\n | Layer 4: Transport |\n | - Segmentation/Reassembly |\n | - Ports and error checking |\n +-----------------------------------+\n | Layer 3: Network |\n | - Routing |\n | - Logical addressing |\n +-----------------------------------+\n | Layer 2: Data Link |\n | - Frame creation/interpretation|\n | - MAC addressing |\n +-----------------------------------+\n | Layer 1: Physical |\n | - Transmission of raw bits |\n +-----------------------------------+\n
Here is my go to Visual Subnet Calc.
But it is handy to know the basic theory. \u2406
In most programming languages, arrays and sequences start at index 0. This convention carries over to how we count positions in a binary number. It aligns with the way memory addresses and offsets are calculated in computer systems.
When we talk about aggregating subnets, we're basically trying to find a bigger subnet that can neatly fit all these smaller subnets inside it.
We're looking for the common ground here, the starting point that fits all these ranges. If we look closely, all the addresses start with \"10.\", which is our first clue. After the \"10.\", things start to get different, so that's where we need to focus.
When we do a bit of magical binary conversion and comparison, we find that the common bits in all these addresses go up to the first 8 bits (that's the \"10\" part). After that, the bits start to differ.
So, if we were to aggregate these networks, our new subnet would start at 10.0.0.0. But what about the mask? Well, since we only have the first 8 bits in common, our new mask would be 255.0.0.0.
Therefore, your aggregated subnet would be 10.0.0.0 with a subnet mask of 255.0.0.0. This big subnet umbrella can cover all your smaller subnets like a cozy blanket! \ud83c\udf10\ud83d\udcbb\ud83c\udf89
traceroute bad.horse\ntraceroute to bad.horse (162.252.205.157), 64 hops max, 52 byte packets\n 1 192.168.200.254 (192.168.200.254) 2.121 ms 2.470 ms 2.295 ms\n 2 79.173.166.153 (79.173.166.153) 2.599 ms 3.316 ms 2.614 ms\n 3 195.167.176.78 (195.167.176.78) 3.516 ms 3.514 ms 3.220 ms\n 4 lon00-br0.as5631.net (83.143.228.238) 4.232 ms 3.710 ms 3.021 ms\n 5 xe-9-1-2.edge3.london2.level3.net (212.113.9.201) 3.169 ms 3.103 ms 2.936 ms\n 6 ae1.8.bar4.toronto1.level3.net (4.69.218.54) 90.796 ms 90.944 ms 90.892 ms\n 7 level3-gw.core02.tor1.prioritycolo.com (4.16.51.30) 91.740 ms 91.998 ms 91.592 ms\n 8 67.223.96.90 (67.223.96.90) 91.401 ms 91.863 ms 91.377 ms\n 9 bad.horse (162.252.205.130) 91.974 ms 91.953 ms 91.525 ms\n10 bad.horse (162.252.205.131) 97.062 ms 96.838 ms 98.465 ms\n11 bad.horse (162.252.205.132) 101.131 ms 98.995 ms 99.642 ms\n12 bad.horse (162.252.205.133) 106.636 ms 106.428 ms 106.886 ms\n13 he.rides.across.the.nation (162.252.205.134) 111.930 ms 112.171 ms 131.932 ms\n14 the.thoroughbred.of.sin (162.252.205.135) 116.678 ms 116.763 ms 116.639 ms\n15 he.got.the.application (162.252.205.136) 129.628 ms 121.732 ms 119.512 ms\n16 that.you.just.sent.in (162.252.205.137) 127.010 ms 127.023 ms 125.168 ms\n17 it.needs.evaluation (162.252.205.138) 129.663 ms 131.599 ms 131.342 ms\n18 so.let.the.games.begin (162.252.205.139) 137.167 ms 136.652 ms 134.110 ms\n19 a.heinous.crime (162.252.205.140) 142.548 ms 140.485 ms 141.390 ms\n20 a.show.of.force (162.252.205.141) 146.570 ms * 146.862 ms\n21 a.murder.would.be.nice.of.course (162.252.205.142) 150.387 ms 152.285 ms 148.757 ms\n22 bad.horse (162.252.205.143) 156.445 ms 156.839 ms 156.380 ms\n23 bad.horse (162.252.205.144) 161.859 ms 161.328 ms 161.561 ms\n24 bad.horse (162.252.205.145) 167.209 ms 166.741 ms 165.658 ms\n25 he-s.bad (162.252.205.146) 171.489 ms 169.464 ms 169.579 ms\n26 the.evil.league.of.evil (162.252.205.147) 175.822 ms 176.793 ms 176.918 ms\n27 is.watching.so.beware (162.252.205.148) 181.350 ms 181.487 ms 181.877 ms\n28 the.grade.that.you.receive (162.252.205.149) 186.980 ms 186.881 ms 183.815 ms\n29 will.be.your.last.we.swear (162.252.205.150) 191.504 ms 192.136 ms 191.605 ms\n30 so.make.the.bad.horse.gleeful (162.252.205.151) 194.137 ms 196.883 ms 196.596 ms\n31 or.he-ll.make.you.his.mare (162.252.205.152) 201.546 ms 201.798 ms 201.274 ms\n32 o_o (162.252.205.153) 206.265 ms 207.723 ms 206.742 ms\n33 you-re.saddled.up (162.252.205.154) 323.803 ms 211.544 ms 211.737 ms\n34 there-s.no.recourse (162.252.205.155) 216.559 ms 217.206 ms 216.652 ms\n35 it-s.hi-ho.silver (162.252.205.156) 223.292 ms 333.837 ms 248.602 ms\n36 signed.bad.horse (162.252.205.157) 221.292 ms 221.970 ms 297.960 ms\n
Here is an image showing a group of diverse cavemen inventing the decimal system, with thought bubbles depicting their dreams of future computers, branded with \"Lloret Control Systems\", and used for counting a vast number of antelopes. The scenes blend primitive settings with futuristic elements.
0.0.0.255
255.255.255.0
permit 192.168.1.0 0.0.0.255
192.168.1.0/24
CAT-ENT Training
The Training Instructions 2020 - Student 4 from Allied Telesis.
The CAT-ENT.pptx from Allied Telesis.
The CAT-ENT-INTRO from Allied Telesis.
CAP-ENT Training
The CAP-ENT.pptx from Allied Telesis.
The CAP-ENT-INTRO).pdf from Allied Telesis.
The CAP-ENT-EXTENDED.pdf from Allied Telesis.
Alas, my Company has a preference for Allied Telesis, as a cheaper alternative.
Value Engineering, so they say.
So I have to learn it.
Manager Friendly
I have touched Allied Telesis before. My former employer had a lucky dip smattering of Allied Telesis in the Network i would occasionally stumble upon. I remember them well because they were known by the slang manager friendly due to the default credentials being manager:friend! that chimed with the lower price point... to the chagrin of the Network Team.
manager:friend
The CAP/ENT training course provides knowledge of the AlliedWare Plus operating system.
The course ends with an open-book multiple-choice exam.
Monday 5th February 2024 - Wednesday 7th February 2024
A remote lab is provided for the course. You SHH to a Linux box and onward to the console of the Allied Telesis Firewall & Switches.
Host AT-LAB-FW\n Hostname uk-1.training.alliedtelesis.com\n User training41\n # Welcome 4 (1)\n # manager (2)\n # friend (3)\n\nHost AT-LAB-530-ONE\n Hostname uk-1.training.alliedtelesis.com\n User training42\n\nHost AT-LAB-530-TWO\n Hostname uk-1.training.alliedtelesis.com\n User training43\n
Use lsof -i tcp:22 to see the SSH sessions to the lab devices. In our case we have x2 per lab device as we are passing a linux jump box to reach the device console.
lsof -i tcp:22
The command lsof -i tcp:22 is used in Unix-like operating systems to list open files and network connections. The components of this command (lsof, -i, tcp:22) each have specific meanings:
lsof: This stands for \"List Open Files\". lsof is a command-line utility that provides information about files that are opened by processes. In Unix and Linux systems, almost everything is treated as a file, including physical devices, directories, and network sockets.
lsof
-i: This option tells lsof to show network connections. When used without any additional parameters, -i lists all network files. However, it can be further narrowed down with additional parameters like protocol type (TCP or UDP) and port numbers.
-i
tcp:22: This further filters the lsof output to show only TCP connections (due to tcp) that are using port 22. Port 22 is the default port for SSH (Secure Shell) connections, which are used for securely accessing remote machines.
tcp:22
\u279c ~ lsof -i tcp:22\n\nCOMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME\nssh 94715 lukeoson 4u IPv4 0x52af948b88c31015 0t0 TCP 192.168.1.108:61894->194.73.86.54:ssh (ESTABLISHED)\nssh 94715 lukeoson 5u IPv4 0x52af948b88c31015 0t0 TCP 192.168.1.108:61894->194.73.86.54:ssh (ESTABLISHED)\nssh 94838 lukeoson 4u IPv4 0x52af948b8986327d 0t0 TCP 192.168.1.108:61928->194.73.86.54:ssh (ESTABLISHED)\nssh 94838 lukeoson 5u IPv4 0x52af948b8986327d 0t0 TCP 192.168.1.108:61928->194.73.86.54:ssh (ESTABLISHED)\nssh 94938 lukeoson 4u IPv4 0x52af948b8862e705 0t0 TCP 192.168.1.108:61965->194.73.86.54:ssh (ESTABLISHED)\nssh 94938 lukeoson 5u IPv4 0x52af948b8862e705 0t0 TCP 192.168.1.108:61965->194.73.86.54:ssh (ESTABLISHED)\n
And you get a topology like this:
The first thing we did was unstack the switches. Couple of reboots required to remove the provisioned devices and renumber to 1. This exercise was to prepare the lab for the content to follow.
awplus(config)#no stack 1 enable\nawplus(config)#no switch 2 provision\nawplus(config)#end\nawplus#write memory\nawplus#reload # (1)\n
With the devices unstacked we can proceed to the course content.
The first module covered some Spanning Tree features.
awplus# configure terminal\nawplus(config)# interface port1.0.1\nawplus(config-if)# spanning-tree guard root # (1)\n
Verify with show spanning-tree brief.
show spanning-tree brief
awplus# configure terminal\nawplus(config)# interface port1.1.2\nawplus(config)# spanning-tree portfast\nawplus(config-if)# spanning-tree portfast bpdu-guard enable (1)\n
awplus# configure terminal\nawplus(config)# spanning-tree errdisable-timeout enable (1)\nawplus(config)# spanning-tree errdisable-timeout interval 50 (2)\n
Usage:
specifies the time interval after which a port is brought back up when it has been disabled by the BPDU guard feature
awplus(config)# loop-protection loop-detect ldf-interval 5 (1)\nawplus(config-if)# loop-protection action link-down (2)\nawplus(config-if)# loop-protection timeout 10 (3)\n
Warning
Always remove loop-protection loop-detect ldf-interval 5 when enabling EPSR.
loop-protection loop-detect ldf-interval 5
2017 Feb 24 00:58:39 user.warning RACK1 HSL[877]: Thrash-limiting: Disabled learning on port2.0.26 by 0202.0ayy.xxxx on VLAN 20\n2017 Feb 24 00:58:39 user.warning RACK1 HSL[877]: Thrash-limiting: Disabled learning on port1.0.25 by 0202.0ayy.xxxx on VLAN 2\n2017 Feb 24 00:58:39 user.warning RACK1 HSL[877]: Thrash-limiting: Disabled learning on sa50 by 0202.0ayy.xxxx on VLAN 2\n
Spanning tree Ports blocked by a spanning tree protocol can still transmit and receive LLDP advertisements. 802.1x Ports blocked by 802.1x port authorization cannot transmit or receive LLDP advertisements. If LLDP has stored information for a neighbor on the port before it was blocked, this information will eventually time out and be discarded. VLAN tagging LLDP packets are untagged; they do not contain 802.1Q header information with VLAN identifier and priority tagging. Virtual Chassis Stacking (VCStack) resiliency link When a port is configured as a VCStack resiliency link port, LLDP does not operate on the port; LLDP neither transmits nor receives advertisements, and any LLDP configuration and data stored for the port, including counters, is discarded. Mirror ports * LLDP does not operate on mirror analyzer ports
``` py linenums=\"1\" title=\"LLDP\" hl_lines=\"1 2\"