# Identify, describe, and apply foundational networking architectures and technologies ### **I. Networking Models and Architectures** #### 1. **OSI Model (Open Systems Interconnection Model)** The **OSI model** is a framework that helps people understand how different parts of a computer network work together. It divides the networking process into **7 layers**, and each layer has its **own job**. Think of it like mailing a letter: - You write the letter (Layer 7), - Put it in an envelope (Layer 6), - Choose a language or code for it (Layer 5), - Send it through different services (Layers 4–1). Let’s go through each layer: ##### **Layer 1 – Physical Layer** - This is the **hardware** part of networking. - It includes: - **Cables** (Ethernet cables, fiber optics), - **Connectors** (RJ-45), - **Electrical signals** (voltage or light signals). - Devices: **Network Interface Cards (NICs)**, cables, hubs. **Example:** If a cable is unplugged, the issue is at Layer 1. ##### **Layer 2 – Data Link Layer** - Handles **local communication** (within the same LAN or switch). - Uses **MAC addresses** (a physical address burned into a network card). - Responsible for: - **Switching**, - **VLANs** (Virtual LANs), - Detecting and handling **errors** in data. **Example:** When a switch decides where to send a message based on a MAC address. ##### **Layer 3 – Network Layer** - Manages **IP addresses** and **routing** between different networks. - Devices like **routers** work here. - Responsible for finding the **best path** to send data from one network to another. **Example:** When you visit a website in another country, routers at Layer 3 decide how to reach it. ##### **Layer 4 – Transport Layer** - Controls **how data is sent and received**. - Two key protocols: - **TCP (Transmission Control Protocol):** Reliable, checks if data was delivered. - **UDP (User Datagram Protocol):** Faster but doesn’t check for delivery. - Adds **port numbers** to help deliver data to the right program (like a web browser). ##### **Layer 5 – Session Layer** - Manages **sessions** (communication between devices). - Starts, manages, and ends the connection. **Example:** Logging into a website and staying logged in. ##### **Layer 6 – Presentation Layer** - Prepares data to be understood by the **application layer**. - Handles: - **Data formatting** (e.g., converting images, encrypting data), - **Encryption/decryption** (like HTTPS). ##### **Layer 7 – Application Layer** - What users **see and interact with**. - Examples: web browsers, email apps, file transfer programs. ###### **Important Note for Aruba Networking:** Aruba switches mostly deal with: - **Layer 2** (MAC, VLAN), - **Layer 3** (IP, routing), - Some aspects of **Layer 4** (for traffic filtering and QoS). #### 2. **TCP/IP Model** The **TCP/IP model** is like a simplified, practical version of the OSI model. It has **4 layers**, and it’s the model that the real Internet uses. | OSI Layer | TCP/IP Layer | Role | | --------- | --------------------- | ------------------------- | | 5–7 | **Application** | User programs (HTTP, DNS) | | 4 | **Transport** | TCP/UDP | | 3 | **Internet** | IP addresses, routing | | 1–2 | **Network Interface** | Hardware, MAC, switching | **Key idea:** Most network engineers use TCP/IP in practice but use OSI as a reference model to understand problems. #### 3. **Network Types** ##### **LAN (Local Area Network)** - A small network, like your home or office. - Connects computers and printers. ##### **WLAN (Wireless LAN)** - Like LAN, but uses Wi-Fi instead of cables. ##### **WAN (Wide Area Network)** - Covers large areas (cities or countries). - The Internet is the biggest WAN. ##### **CAN (Campus Area Network)** - Connects buildings in a university or large company. ##### **MAN (Metropolitan Area Network)** - Bigger than a LAN but smaller than a WAN. - Covers a whole city. #### 4. **Enterprise Network Design (Three-Tier Architecture)** This is a design used in large organizations to manage networks better. ##### **a. Core Layer** - The high-speed backbone of the network. - Connects distribution layers together. - Very fast but doesn’t apply much filtering or policy. ##### **b. Distribution Layer** - Connects the access layer to the core. - Applies **routing, filtering, access policies**, etc. ##### **c. Access Layer** - Where users and devices (laptops, printers) connect. - Uses **switches** to link end-user devices to the network. **Aruba switches** often live in the **access and distribution layers**, and in some designs, in the core layer (CX 8400 series). ### **II. Addressing and Subnetting** Understanding how devices identify and communicate with each other in a network is essential. This section focuses on **IP addresses**, **subnetting**, and a basic introduction to **IPv6**. #### **1. IPv4 Addressing** ##### **What is an IP Address?** An **IP address** (Internet Protocol address) is a **unique identifier** given to each device on a network. It helps computers **send and receive data** over a network. IPv4 addresses are written in **dotted decimal** format like: `192.168.1.1` This address consists of **four numbers** (called octets), each between 0 and 255. Each number represents **8 bits**, and the total IP address is **32 bits long**. ##### **IP Address Classes (A to E)** Historically, IP addresses were divided into five "classes": | Class | Start Address | End Address | Default Subnet Mask | Usage | | ----- | ------------- | --------------- | ------------------- | -------------------------- | | A | 1.0.0.0 | 126.255.255.255 | 255.0.0.0 (/8) | Very large networks | | B | 128.0.0.0 | 191.255.255.255 | 255.255.0.0 (/16) | Medium networks | | C | 192.0.0.0 | 223.255.255.255 | 255.255.255.0 (/24) | Small networks | | D | 224.0.0.0 | 239.255.255.255 | — | Multicast (not normal IPs) | | E | 240.0.0.0 | 255.255.255.255 | — | Experimental | Most enterprise networks today use **Class A, B, or C** addresses within **private ranges**. ##### **Private IP Address Ranges** These are IP ranges you can use **within your own network**. They are not routable on the public Internet. | Class | Private IP Range | | ----- | ----------------------------- | | A | 10.0.0.0 – 10.255.255.255 | | B | 172.16.0.0 – 172.31.255.255 | | C | 192.168.0.0 – 192.168.255.255 | **Example:** Your home Wi-Fi router likely gives you an IP like `192.168.1.5`. #### **2. Subnetting** Subnetting is the process of **dividing a large network** into **smaller logical networks (subnets)**. This improves organization, performance, and security. ##### **a. Subnet Masks** A **subnet mask** defines which part of the IP address is the **network** and which part is the **host**. Example: - IP: `192.168.1.1` - Subnet Mask: `255.255.255.0` This means: - First 3 octets = **Network** (192.168.1) - Last octet = **Host** (1) ##### **b. CIDR Notation** CIDR (Classless Inter-Domain Routing) is a shorthand version of subnetting. Example: `192.168.1.0/24` The **"/24"** means 24 bits are for the network part, same as a mask of `255.255.255.0`. Common CIDR values: | CIDR | Subnet Mask | Number of Hosts | | ---- | --------------- | --------------- | | /8 | 255.0.0.0 | 16,777,214 | | /16 | 255.255.0.0 | 65,534 | | /24 | 255.255.255.0 | 254 | | /30 | 255.255.255.252 | 2 | The number of usable hosts is always **2 less** than the total, because the first address is for the **network ID**, and the last is the **broadcast address**. ##### **c. Wildcard Masks (for ACLs)** Used in **access control lists** to match IP ranges. Wildcard masks are the **opposite** of subnet masks. Example: - Subnet Mask: `255.255.255.0` - Wildcard Mask: `0.0.0.255` This tells the system to match any IP from `x.x.x.0` to `x.x.x.255`. #### **3. IPv6 (Basic Awareness)** IPv6 is the newer version of IP addressing. It was created because IPv4 addresses are running out. ##### **Key Features** - IPv6 addresses are **128 bits long** (IPv4 is 32 bits). - Written in **hexadecimal**: - Example: `2001:0db8:85a3:0000:0000:8a2e:0370:7334` - Shortened form: `2001:db8:85a3::8a2e:370:7334` ##### **Address Types** - **Link-local**: Starts with `fe80::`. Used for communication within the same local network. - **Global unicast**: Routable over the Internet. - **Multicast**: Starts with `ff00::`. Used to send to a group of devices. ### **III. Switching and Layer 2 Concepts** This section is all about **how devices communicate within the same local network**. These technologies mostly work at **OSI Layer 2**, and they are key to understanding how Aruba switches operate. #### **1. MAC Addressing** ##### **What is a MAC Address?** - A **MAC (Media Access Control) address** is a **unique hardware identifier** for a network interface card (NIC). - It's **assigned by the manufacturer** and “burned into” the network card. - Format: **6 pairs of hexadecimal numbers**, like `00:1A:2B:3C:4D:5E`. ##### **Why is MAC important?** - **Switches use MAC addresses** to decide where to forward traffic. - Every time a switch receives a frame, it **learns** the MAC address and the port it came from and builds a **MAC address table** (or CAM table). ##### **MAC Table Example:** | MAC Address | Port | | ----------------- | ---- | | 00:11:22:33:44:55 | 1/1 | | AA:BB:CC:DD:EE:FF | 1/2 | This table helps the switch send data **only to the correct device**, not to everyone. #### **2. VLANs (Virtual Local Area Networks)** ##### **What is a VLAN?** - A VLAN **logically divides a single physical network** into multiple smaller networks. - Even if devices are connected to the same switch, **VLANs keep them separate** — like having walls in an open office. ##### **Benefits of VLANs:** - Better **security**: Sensitive devices don’t share a broadcast domain. - Easier **management**: Group devices by department or function. - Improves **performance**: Reduces unnecessary traffic. ##### **VLAN Configuration Terms:** | Term | Description | | ----------------- | -------------------------------------------------------------------------- | | **Tagged Port** | Carries traffic from **multiple VLANs** (used in trunks between switches). | | **Untagged Port** | Belongs to **one VLAN**. Usually connects to end devices like PCs. | | **Native VLAN** | The default VLAN for untagged traffic on a trunk port. | ##### **Example:** If a port is **untagged VLAN 10**, it means: - All traffic on that port is part of VLAN 10. If a port is **tagged VLAN 10, 20**, it means: - The port can carry traffic for both VLANs (used between switches). ##### **Inter-VLAN Routing** - Devices in different VLANs **cannot talk to each other** unless you configure **routing** (Layer 3). - On Aruba switches, you do this with **SVIs (Switch Virtual Interfaces)**. #### **3. Spanning Tree Protocol (STP)** ##### **What is STP?** - **Spanning Tree Protocol** prevents **loops** in a Layer 2 network. - Loops are dangerous: if switches loop traffic endlessly, it can **crash your network**. ##### **How STP Works:** - Elects a **Root Bridge**. - Switches decide which ports are: - **Root Ports** (best path to Root Bridge), - **Designated Ports** (forwarding), - **Blocking Ports** (disabled to prevent loops). ##### **RSTP (Rapid STP)** - ArubaOS-CX uses **RSTP** by default. - It converges **faster** than classic STP — usually in **a few seconds** instead of 30+ seconds. ##### **Useful STP Commands:** - `show spanning-tree` - `spanning-tree priority 4096` → set a switch to be the Root Bridge #### **4. Link Aggregation (LAG)** ##### **What is Link Aggregation?** - **Combines two or more physical links** into **one logical link**. - Also called **Port Trunking**, **EtherChannel**, or **LAG** (Link Aggregation Group). ##### **Benefits:** - **Increased bandwidth**: Multiple links used together. - **Redundancy**: If one link fails, others stay active. ##### **What is LACP?** - **LACP (Link Aggregation Control Protocol)** is an open standard (IEEE 802.3ad). - It lets switches **automatically detect and manage LAGs**. ##### **LAG Example:** Let’s say you connect two switches using two cables: - Without LAG → it causes a loop (bad). - With LAG → the switch treats both cables as one **safe, fast link**. ##### **LAG Setup Basics (ArubaOS-CX):** ```shell interface 1/1/1 lag 1 mode active interface 1/1/2 lag 1 mode active ``` This config creates a LAG using ports 1/1/1 and 1/1/2. ### **IV. Routing and Layer 3 Concepts** Layer 3 deals with **routing** — the process of sending data from one network to another. While Layer 2 switches can only forward traffic within the same VLAN (or subnet), Layer 3 switches can **route traffic between VLANs or remote networks**. #### **1. Routing Fundamentals** ##### **What is Routing?** Routing is the process of choosing the **best path** for data to travel from one network to another. It’s done by devices like **routers** and **Layer 3 switches** (like ArubaOS-CX switches). ##### **Default Gateway** - A **default gateway** is the IP address of the router/switch that knows how to get out of the local network. - Every device in a subnet uses the **gateway IP** to send data **outside** its subnet. **Example:** - PC: `192.168.10.100` - Gateway: `192.168.10.1` - If PC wants to reach Google (8.8.8.8), it sends the traffic to the gateway first. ##### **Types of Routing** | Type | Description | | ----------- | -------------------------------------------------------------------------------- | | **Static** | Manually configured by the admin. Easy to set up, but doesn’t adjust to changes. | | **Dynamic** | Routes are learned automatically using routing protocols (e.g., OSPF). | #### **2. Static Routing** Static routing is used to manually define which path to use for specific destinations. It's simple and reliable for **small networks**. ##### **Static Route Example:** ```shell ip route 0.0.0.0/0 192.168.1.1 ``` This says: - “To reach **any destination** (0.0.0.0/0), send the traffic to **192.168.1.1**.” ##### **Command Breakdown:** - `0.0.0.0/0`: Matches **all destinations**. - `192.168.1.1`: The **next-hop IP** (usually a router). ##### **When to Use Static Routes:** - Connecting to a single default gateway. - Small branch offices. - When the network topology **doesn’t change often**. #### **3. Dynamic Routing (Introductory)** Dynamic routing is better for **larger or changing networks**. Instead of manually entering routes, devices **learn routes from each other** using protocols. ##### **OSPF (Open Shortest Path First)** - A **link-state protocol** that shares information about the network. - Devices **build a map** of the network and choose the shortest path. ##### **OSPF Concepts:** | Term | Meaning | | ---------------------------------- | ----------------------------------------------------------------- | | **Router ID** | A unique ID for the router (often its highest IP address). | | **Area** | OSPF networks are divided into **areas** (most commonly, area 0). | | **Hello Timer** | How often OSPF routers send “Hello” packets to check neighbors. | | **LSA (Link-State Advertisement)** | Info packets about routes and connections. | ##### **ArubaOS-CX OSPF Setup Example (Simplified):** ```shell router ospf 1 router-id 1.1.1.1 interface vlan 10 ip ospf 1 area 0.0.0.0 ``` This enables OSPF on VLAN 10. ##### **When to Use OSPF:** - In **multi-site networks** - When there are **redundant paths** - When **manual routes are too many to manage** #### **4. ARP (Address Resolution Protocol)** ##### **What is ARP?** - ARP is used to **find the MAC address** of a device when you only know its IP. - It works at Layer 3 (IP) to Layer 2 (MAC). ##### **How ARP Works:** 1. Device A wants to talk to `192.168.1.5`. 2. It sends an **ARP request**: "Who has 192.168.1.5?" 3. Device B replies with: "I do! My MAC is AA:BB:CC:DD:EE:FF" 4. Device A stores this info in its **ARP table** and sends the frame. ##### **Why ARP Matters:** - Without ARP, devices **can’t communicate** on the same subnet. - **Switches** need ARP to build MAC tables for IP-based communication. - Problems like **IP conflicts or ARP spoofing** can break communication or compromise security. #### Summary of Key Commands | Function | Example Command | | ---------------- | ------------------------------------ | | Show IP routes | `show ip route` | | Add static route | `ip route 10.1.1.0/24 192.168.1.1` | | Enable routing | `ip routing` | | Show ARP table | `show arp` | | Start OSPF | `router ospf 1` + interface commands | ### **V. Transport Layer Concepts** The **transport layer** (Layer 4 in the OSI model) is responsible for **moving data between devices reliably or efficiently**. This includes controlling: - **How data is sent**, - **How much data can be sent**, - **Whether the data was received**, - And **which application or service** the data is intended for. There are **two main transport protocols** you need to understand: #### **1. TCP vs. UDP** ##### **a. TCP (Transmission Control Protocol)** ###### **Key Features:** - **Connection-oriented:** Devices must "handshake" before exchanging data. - **Reliable:** Ensures all packets are delivered. - **Ordered:** Maintains the correct order of packets. - **Error-checked:** Retransmits lost packets. ###### **3-Way Handshake Process:** 1. **SYN** – Client asks to start communication. 2. **SYN-ACK** – Server agrees and replies. 3. **ACK** – Client confirms and starts data exchange. ###### **Use Cases:** - **Web browsing** (HTTP/HTTPS), - **Email** (SMTP, IMAP), - **File transfer** (FTP), - **Remote login** (SSH). ###### **Pros:** - Very reliable. - Guaranteed delivery. ###### **Cons:** - **Slower** due to connection setup and checks. ##### **b. UDP (User Datagram Protocol)** ###### **Key Features:** - **Connectionless:** No handshake; just sends data. - **Unreliable:** No confirmation that data arrived. - **No order or error correction.** - **Much faster** than TCP. ###### **Use Cases:** - **Streaming video/audio** (YouTube, Skype), - **Online games** (low latency), - **DNS** (fast lookup), - **VoIP (Voice over IP)**. ###### **Pros:** - Very fast, low overhead. ###### **Cons:** - Can lose packets. - No error checking or order enforcement. ###### **Summary Table:** | Feature | TCP | UDP | | ------------ | --------------- | ------------------------- | | Connection | Yes (Handshake) | No | | Reliable | Yes | No | | Packet Order | Guaranteed | Not guaranteed | | Speed | Slower | Faster | | Use Case | Web, Email, FTP | Video, Voice, DNS, Gaming | #### **2. Port Numbers** Every network service or application **uses a port number** so your device knows **which program should receive incoming data**. You can think of port numbers like **apartment numbers in a building** — the IP address brings the data to the building, and the **port number delivers it to the right room**. ##### **Well-Known Port Numbers (0–1023)** | Service | Protocol | Port | | -------------------- | -------- | ----- | | HTTP | TCP | 80 | | HTTPS | TCP | 443 | | FTP (File Transfer) | TCP | 21 | | SSH (Remote login) | TCP | 22 | | DNS (Name service) | UDP | 53 | | DHCP (IP assignment) | UDP | 67/68 | | SMTP (Email sending) | TCP | 25 | | Telnet (Not secure) | TCP | 23 | **Note**: Aruba switches often **block Telnet** and recommend **SSH** for security. ##### **How Ports Work** Imagine you go to a website: 1. Your browser connects to the **IP address** of the web server. 2. It sends a request to **port 80 (HTTP)** or **443 (HTTPS)**. 3. The server replies back using a **random port** on your device (like 56324). So, your device may have multiple connections open, each using a **different source port** but going to the same destination port. ### **VI. Multicast and Broadcast** These two terms describe **how network traffic is sent** from one device to others. Unlike unicast (one-to-one communication), broadcast and multicast are **one-to-many** communication methods — but they work in different ways. #### **1. Broadcast Traffic** ##### **What is Broadcast?** Broadcast means **sending a message to all devices** in a local network segment (VLAN). Think of it like a **loudspeaker announcement** in a building — everyone hears it, even if it’s not relevant to them. ##### **How Broadcast Works:** - The sender uses a **special destination address**: **IPv4 Broadcast IP**: `255.255.255.255` **Ethernet Broadcast MAC**: `FF:FF:FF:FF:FF:FF` - All devices in the subnet **receive and process** the message. ##### **Examples of Broadcast Protocols:** - **ARP** – Asking: “Who has IP 192.168.1.10?” - **DHCP Discover** – When a new device tries to get an IP address. ##### **Why Broadcast Can Be a Problem:** - **Creates unnecessary traffic** for all devices. - If too many broadcasts occur, it causes a **broadcast storm**, slowing down or crashing the network. ##### **How Aruba Switches Handle Broadcasts:** - Broadcasts stay **within the same VLAN**. - You can use **VLANs** and **storm control** to limit broadcast traffic. #### **2. Multicast Traffic** ##### **What is Multicast?** Multicast sends a message to **only a group of interested devices**, not to everyone. Think of it like **a group chat** — only group members get the message, not the entire contact list. ##### **How Multicast Works:** - Uses **special multicast IP addresses** (Class D: 224.0.0.0 to 239.255.255.255). - Devices **join multicast groups** to indicate interest. - The sender sends one copy, and the network **duplicates it only for group members**. ##### **Example Use Cases:** - **Streaming video in classrooms** - **Live webinars** - **Online games using group updates** #### **Multicast vs Broadcast Summary:** | Feature | Broadcast | Multicast | | ------------ | ------------------- | -------------------------------- | | Destination | All devices in VLAN | Only devices that join the group | | Network Load | Higher | Lower (more efficient) | | Use Cases | ARP, DHCP | IPTV, video conferencing | | IP Range | 255.255.255.255 | 224.0.0.0 – 239.255.255.255 | #### **IGMP (Internet Group Management Protocol)** ##### **What is IGMP?** IGMP is the protocol that helps switches know **which devices want to receive multicast traffic**. ##### **How IGMP Works:** 1. A PC wants to receive a multicast stream. 2. It sends an **IGMP Join** message. 3. The switch adds that PC to the multicast group. 4. Only that PC gets the stream — others are left alone. ##### **IGMP Snooping (on Aruba Switches):** - Monitors IGMP messages. - **Prevents multicast flooding** by only sending traffic to interested ports. - **Enabled by default** on many Aruba switches. ##### **Common IGMP Groups:** | IP Address | Purpose | | ---------- | ------------------------------ | | 224.0.0.1 | All hosts on the local network | | 224.0.0.2 | All routers | | 239.x.x.x | Organization-defined groups | ### **VII. Common Network Protocols** These are the essential **network communication protocols** that help devices perform important tasks such as getting an IP address, translating names to IPs, monitoring devices, and more. These protocols work across various layers (usually Layer 3 and above) and are critical for network functionality and troubleshooting. #### **1. DHCP (Dynamic Host Configuration Protocol)** ##### **What it does:** - **Automatically assigns IP addresses** to devices on a network. - Without DHCP, you’d have to manually configure each IP address. ##### **How DHCP Works (DORA process):** | Step | Description | | ------------ | -------------------------------------------------- | | **D**iscover | Client sends a **broadcast** to find a DHCP server | | **O**ffer | DHCP server offers an available IP address | | **R**equest | Client requests the offered address | | **A**ck | DHCP server confirms the assignment | ##### **Common Use Cases:** - Automatically configure computers, phones, printers, and IP cameras. ##### **Aruba Use:** - Aruba switches can be DHCP **clients**, **relays**, or even **servers** (in simple networks). #### **2. DNS (Domain Name System)** ##### **What it does:** - Converts **domain names** (like `www.google.com`) into **IP addresses** (like `142.250.190.68`). ##### **Why it's important:** - Humans remember names. - Computers need IP addresses. ##### **DNS Query Example:** - You type `www.arubanetworks.com` - Your computer asks the DNS server: “What is the IP for this site?” - DNS server responds: `34.236.4.84` ##### **Common DNS Ports:** - UDP 53 (most queries) - TCP 53 (for large responses) #### **3. ICMP (Internet Control Message Protocol)** ##### **What it does:** - Sends **control and error messages** between devices. - It’s the protocol used by tools like **ping** and **traceroute**. ##### **Use Cases:** - **Ping** checks if a device is online. - **Traceroute** shows the path traffic takes across the network. ##### **Not for actual data transfer**, but essential for **testing and diagnostics**. #### **4. SNMP (Simple Network Management Protocol)** ##### **What it does:** - Allows centralized systems to **monitor and manage network devices**. ##### **Aruba Uses:** - Aruba switches can send performance data (CPU, memory, interface stats) to: - **Aruba Central** - **Aruba AirWave** - **Third-party SNMP servers (e.g., SolarWinds)** ##### **SNMP Versions:** | Version | Description | | ------- | ---------------------------------------- | | v1 | Basic, no encryption | | v2c | Adds bulk transfers, still no encryption | | v3 | **Secure** (authentication + encryption) | ##### **SNMP Community Strings:** - Like a password. - Example: ```shell snmp-server community public ro ``` #### **5. NTP (Network Time Protocol)** ##### **What it does:** - Synchronizes the **time** on all network devices. - Important for: - Accurate **logs** - **Security certificates** - Coordinating time-sensitive tasks ##### **Typical Configuration:** ```shell ntp server 192.168.1.100 ``` ##### **Check time:** ```shell show time ``` #### **6. SSH (Secure Shell)** ##### **What it does:** - Provides **secure remote access** to network devices over an encrypted connection. ##### **Used Instead of Telnet:** - Telnet sends everything in **plain text** (not safe). - SSH encrypts the connection (safe). ##### **Aruba SSH Setup Example:** ```shell crypto key generate ssh ip ssh ``` Then you can connect securely using: ```bash ssh admin@192.168.1.1 ``` ##### **Common SSH Port:** - TCP **22** ##### Summary Table of Common Protocols: | Protocol | Purpose | Port | Notes | | -------- | --------------------------------------- | ----------- | ------------------------------- | | DHCP | Auto-assign IP addresses | UDP 67/68 | Broadcast-based | | DNS | Resolve names to IPs | UDP/TCP 53 | Critical for internet access | | ICMP | Connectivity testing (ping, traceroute) | — | Used for troubleshooting | | SNMP | Network monitoring | UDP 161/162 | Can be insecure unless using v3 | | NTP | Time synchronization | UDP 123 | Keeps logs and events aligned | | SSH | Secure device access | TCP 22 | Replaces insecure Telnet | ### **VIII. Network Topologies** A **network topology** refers to the **physical or logical layout** of how devices (like switches, routers, computers) are **connected** in a network. Understanding these patterns is important for **design**, **troubleshooting**, and **scalability**. We’ll look at the **four most common** topologies, focusing on those most relevant to enterprise environments like those using Aruba switches. #### **1. Star Topology (Most Common in Enterprises)** ##### **What it looks like:** - One central switch or hub is connected to all other devices. - Think of it like a **wheel with spokes** — the switch is the center. ##### **Pros:** - Easy to add/remove devices. - Easy to isolate and troubleshoot problems. - One device failure doesn’t affect the whole network. ##### **Cons:** - If the **central switch fails**, the whole network goes down. ##### **Where Aruba Uses It:** - **Access layer switches** often form a star topology by connecting PCs, printers, APs, etc. #### **2. Mesh Topology** ##### **What it looks like:** - Devices are **interconnected**, often with **multiple paths** between them. - There are two types: - **Full Mesh:** Every device connects to every other. - **Partial Mesh:** Only some devices are interconnected. ##### **Pros:** - **High availability** – if one link fails, traffic can use another path. - **Redundancy** improves reliability. ##### **Cons:** - More complex. - Requires more cabling and configuration. - Costlier. ##### **Where Aruba Uses It:** - **Core or distribution layers** may use mesh topologies with **VSX or LAGs** for redundancy. #### **3. Ring Topology (Older Technology)** ##### **What it looks like:** - Devices form a **closed loop** — each device connects to two others. ##### **Pros:** - Can offer redundancy if supported by protocol (e.g., **Token Ring**, or **Spanning Tree** blocks loops). ##### **Cons:** - A break in the ring can affect communication. - Not scalable or flexible. ##### **Modern Usage:** - Rare in enterprise LANs. - **Spanning Tree Protocol (STP)** can "simulate" ring protections in switch networks. #### **4. Bus Topology (Very Rare Today)** ##### **What it looks like:** - All devices share a **single communication line** (like a road with many buildings connected to it). ##### **Pros:** - Easy to set up for small networks. ##### **Cons:** - Only one device can send at a time. - A break in the line affects the whole network. - Difficult to troubleshoot. ##### **Modern Usage:** - **Obsolete** in wired networks, but some concepts apply to **wireless channels** (shared medium). #### **Quick Comparison Table:** | Topology | Pros | Cons | Used Today? | | -------- | -------------------------------- | --------------------------------- | ------------- | | **Star** | Easy to manage, isolate issues | Central point of failure | Very common | | **Mesh** | High redundancy and availability | Complex and expensive | Core/Backbone | | **Ring** | Predictable path | Breaks can disrupt the whole ring | Rare | | **Bus** | Simple for small setups | Break = full network down | Obsolete | ### **IX. Cabling and Media Types** Choosing the correct cable or media type is essential for building a **reliable, high-speed, and long-distance** network. This section introduces the **physical materials** used to connect Aruba switches to devices or to each other. #### **1. Copper Cabling (Twisted Pair)** Copper cables use **electrical signals** to transmit data. They are common for **short-distance connections**, like between a computer and a switch. ##### **a. UTP vs STP** | Type | Meaning | Shielding | Use Case | | ---- | ----------------------- | ------------- | ------------------------------ | | UTP | Unshielded Twisted Pair | No shielding | General-purpose office use | | STP | Shielded Twisted Pair | Has shielding | High-interference environments | ##### **b. Cable Categories (Cat)** | Category | Speed Supported | Max Distance | Use Case | | -------- | --------------- | ------------ | ----------------------------- | | Cat5e | 1 Gbps | 100 meters | Standard Ethernet | | Cat6 | 1–10 Gbps | 55–100 m | High-speed access, less noise | | Cat6a | 10 Gbps | 100 meters | Data centers or core uplinks | **Aruba switches support auto-negotiation**, but using a high-quality cable (Cat6 or Cat6a) is **recommended for reliable Gigabit or 10G links**. ##### **c. RJ-45 Connectors** - Standard connectors for Ethernet. - Used with Cat5e/6/6a cables. - Plug into ports on Aruba switches for **copper interfaces**. #### **2. Fiber Optic Cabling** Fiber optics use **light signals** to send data — ideal for **long distances** and **high speeds**. ##### **a. Types of Fiber** | Type | Core Size | Distance | Use Case | | ----------- | ------------------- | --------------- | ---------------------------- | | Single-Mode | Small (8–10 µm) | Up to 40+ km | Long-distance backbone links | | Multi-Mode | Larger (50–62.5 µm) | Up to 300–500 m | Shorter links in buildings | ##### **b. Advantages of Fiber:** - Immune to **electromagnetic interference** - Can transmit data over **much longer distances** than copper - Supports **very high speeds** (up to 100 Gbps and more) ##### **c. Connector Types** | Connector | Description | Use With | | --------- | ------------------ | -------------- | | LC | Most common, small | Aruba SFPs | | SC | Older, larger | Legacy systems | #### **3. SFP and SFP+ Modules** ##### **What are SFPs?** SFP = **Small Form-factor Pluggable** SFP+ = Enhanced version for **10 Gbps** These are **modular transceivers** used in Aruba switches to connect fiber or copper links. ##### **Use Cases:** - **Uplink** between switches - **Long-distance links** between buildings - Connecting to **service provider equipment** ##### **Common SFP Types:** | Module | Speed | Media | Max Distance | | ---------- | ------- | ------------- | ----------------- | | SFP-1G-SX | 1 Gbps | Multi-mode | ~550 meters | | SFP-1G-LX | 1 Gbps | Single-mode | ~10 kilometers | | SFP-10G-SR | 10 Gbps | Multi-mode | ~300 meters | | SFP-10G-LR | 10 Gbps | Single-mode | ~10–20 kilometers | | SFP-T | 1 Gbps | Copper (RJ45) | 100 meters (Cat6) | Aruba switches **auto-detect** SFPs and configure ports accordingly. #### **4. DAC (Direct Attach Cables)** - DACs are **pre-made cables with SFP ends** used to connect two switches directly (no transceiver needed). - Common in **data centers** for **short links (≤7m)**. ##### Summary Table: | Media Type | Max Speed | Max Distance | Common Aruba Use | | ---------- | ------------ | ------------ | ------------------------- | | Cat5e | 1 Gbps | 100m | PC/printer access | | Cat6a | 10 Gbps | 100m | Short server/switch links | | Fiber (SM) | 10–100+ Gbps | 40+ km | Long-distance uplinks | | Fiber (MM) | 10 Gbps | 300–500m | Building-to-building | | SFP/SFP+ | 1G/10G | — | Uplink modularity | ### **X. Foundational Security Concepts (Networking Level)** Network security starts at the **switch level**, especially in enterprise networks. Aruba switches include a variety of **Layer 2 and Layer 3 security features** to protect the network from unauthorized access, attacks, and misconfigurations. We’ll focus on three fundamental tools: - **ACLs (Access Control Lists)** - **Port Security** - **DHCP Snooping** #### **1. Access Control Lists (ACLs)** ##### **What is an ACL?** An ACL is a list of rules that **filters network traffic**. Each rule defines **what traffic is allowed or denied**, based on things like: - **IP address** - **Port number** - **Protocol type** ACLs operate at: - **Layer 2 (MAC ACLs)** – less common - **Layer 3 (IP ACLs)** – very common - **Layer 4 (TCP/UDP ports)** – for advanced control ##### **Where ACLs Are Applied:** - **Inbound or outbound** on: - VLAN interfaces - Physical ports - On **routing interfaces** for inter-VLAN or internet traffic ##### **ACL Example (IPv4):** ```shell ip access-list "BLOCK_HTTP" 10 deny tcp 192.168.1.0 0.0.0.255 any eq 80 20 permit ip any any ``` **Explanation:** - Rule 10: Denies HTTP (TCP port 80) from `192.168.1.0/24` to anywhere. - Rule 20: Allows everything else (important – ACLs are **implicit deny** by default). ##### **Applying the ACL:** ```shell interface vlan 10 ip access-group BLOCK_HTTP in ``` ##### **Tips:** - ACLs are **processed top-down**; first match wins. - Be **careful** with the order of rules. - Always add a **"permit all"** at the end if you don’t want to block everything. #### **2. Port Security** ##### **What is Port Security?** Port security **limits the number and identity of devices** that can connect to a switch port. ##### **Use Cases:** - Prevent unauthorized devices (e.g., rogue laptops) from connecting. - Lock a port to **only one known MAC address**. - Disable a port **if a new MAC address appears**. ##### **Basic Port Security Configuration:** ```shell interface 1/1/1 port-security port-security max 1 port-security mac-address sticky ``` **Explanation:** - Enables port security. - Allows only **1 device** on the port. - Learns the first MAC and “sticks” it (saves it automatically). ##### **Violation Actions:** You can set what happens when an unauthorized MAC appears: - **Protect** – drops unknown frames silently. - **Restrict** – drops and logs the event. - **Shutdown** – disables the port completely. #### **3. DHCP Snooping** ##### **What is DHCP Snooping?** DHCP Snooping **protects the network from rogue DHCP servers** (which can cause IP conflicts, DoS attacks, or misrouting). ##### **How it works:** - The switch **watches all DHCP messages**. - Only **trusted ports** (like uplinks to a known DHCP server) can offer IP addresses. - **Untrusted ports** (like user ports) are blocked if they try to act as DHCP servers. ##### **Basic Configuration:** ```shell dhcp-snooping dhcp-snooping vlan 10 interface 1/1/1 dhcp-snooping trust ``` **Explanation:** - Enables DHCP snooping globally. - Applies it to VLAN 10. - Marks port 1/1/1 as a **trusted uplink**. ##### **DHCP Snooping Table:** The switch keeps a table of: - MAC addresses - IP addresses - Port numbers - Lease times This table can also be used by: - **Dynamic ARP Inspection** - **IP Source Guard** --- # Identify, describe, and differentiate the functions and features of Aruba products and solutions ### **I. Aruba Product Families (Switching)** Aruba has a wide range of switches for different network sizes and roles. Some are older (legacy), while others are based on Aruba's **modern operating system (ArubaOS-CX)**. #### **Aruba Switch Series** ##### **1. Aruba 2530** - **Type:** Layer 2 only (no routing) - **Operating System:** ArubaOS (legacy) - **Features:** - Basic VLAN support - No dynamic routing (only Layer 2) - Limited security features - **Use Case:** - Small offices or very simple networks - **Budget-friendly** access layer switch ##### **2. Aruba 2540** - **Type:** Layer 2/3 Lite - **Operating System:** ArubaOS (legacy) - **Features:** - Supports **static routing** - Basic ACLs - Basic QoS - **Use Case:** - **Small-to-medium business (SMB)** edge deployments - Suitable for environments needing limited routing ##### **3. Aruba 2930F** - **Type:** Layer 3 switch - **Operating System:** ArubaOS (legacy) - **Features:** - **Static routing**, RIP, and OSPF (dynamic routing) - Supports **VSF** (Virtual Switching Framework) - Optional **PoE+** for powering devices - **Use Case:** - **Campus access or distribution** layer - Ideal for medium-to-large enterprise networks ##### **4. Aruba 2930M** - **Very similar to 2930F**, but with: - **Modular power supplies** (for redundancy) - **Hot-swappable fans** - Better for **high availability** setups - **Use Case:** - Larger networks needing **greater resilience** - Places where uptime is critical ##### **5. Aruba 3810** - **Type:** Advanced Layer 3 - **Operating System:** ArubaOS - **Features:** - High performance - Advanced routing (OSPF, VRRP) - VSF support - Hot-swappable components - **Use Case:** - **Distribution or small core layer** - Networks needing strong redundancy and Layer 3 capabilities ##### **6. Aruba CX 6200/6300** - **Type:** Full Layer 3 - **Operating System:** **ArubaOS-CX (modern)** - **Features:** - Dynamic routing: OSPF, BGP - Real-time telemetry - REST API and Python scripting - VSF supported (6300) - **Use Case:** - **Modern access/distribution** - High-performance enterprise switching 6200 is fixed power/non-modular; 6300 supports **VSF and hot-swappable hardware**. ##### **7. Aruba CX 8320/8400** - **Type:** High-end modular Layer 3 switches - **Operating System:** ArubaOS-CX - **Features:** - **VSX (active-active core switching)** - Deep analytics and telemetry - Redundant supervisors, line cards - **Up to 100Gbps ports** - **Use Case:** - **Enterprise core** - **Data centers** - Mission-critical networks ##### Summary Table: | Series | OS | Layer | Routing | Use Case | | ---------------- | ---------- | ----- | ----------------- | -------------------------- | | **2530** | ArubaOS | 2 | No | Basic access layer | | **2540** | ArubaOS | 2/3 | Static only | SMB edge switching | | **2930F/M** | ArubaOS | 3 | Static, RIP, OSPF | Campus access/distribution | | **3810** | ArubaOS | 3 | Advanced Routing | Distribution/Core | | **CX 6200** | ArubaOS-CX | 3 | Full Layer 3 | Modern access layer | | **CX 6300** | ArubaOS-CX | 3 | Full Layer 3 | Access/Distribution + VSF | | **CX 8320/8400** | ArubaOS-CX | 3 | Full + VSX | Core/Data Center | ### **II. ArubaOS vs. ArubaOS-CX** Understanding the **two major operating systems** used in Aruba switches is essential to choosing the right switch for your network. The differences between **ArubaOS (legacy)** and **ArubaOS-CX (modern)** go far beyond appearance — they affect performance, automation, and management capabilities. #### **1. ArubaOS (Legacy / Provision OS)** ArubaOS is the **older OS platform** used in switches like the 2530, 2540, 2930F, 2930M, and 3810. ##### **Key Characteristics:** | Feature | Description | | -------------------------- | ----------------------------------------------------------------------------- | | **Traditional CLI** | Similar to Cisco IOS; commands follow a **flat hierarchy**. | | **Limited telemetry** | Cannot store or display **historical data** (only real-time output). | | **Basic scripting** | No native support for Python or REST APIs. | | **Routing features** | Static routing, RIP, OSPF available depending on model. | | **Common in SMB networks** | Still widely deployed in **non-mission-critical** or **budget** environments. | ##### **Use Case Scenarios:** - Small to mid-size companies - Environments with **basic Layer 2/3 needs** - Simple manual configurations #### **2. ArubaOS-CX (Modern OS)** ArubaOS-CX is a **next-generation, modular, Linux-based OS**. It runs on switches like the **CX 6200, 6300, 8320, and 8400** and brings enterprise-grade capabilities into the switching fabric. ##### **Key Features:** | Capability | ArubaOS-CX Description | | --------------------------- | ------------------------------------------------------------------------------------ | | **Modular architecture** | Each system function (routing, QoS, logging) runs independently; improves stability. | | **Database-driven** | Real-time and historical **state database** — you can see what happened hours ago. | | **Python scripting** | Automate tasks directly from the switch using Python. | | **REST API support** | Full **programmatic control** over configuration, monitoring, and automation. | | **Event-driven automation** | Can trigger actions based on events (e.g., link down). | | **Error prevention tools** | **Config validation** and **transactional CLI** allow you to test and commit safely. | ##### **Why It's a Game-Changer:** | Legacy ArubaOS | ArubaOS-CX | | ------------------ | ------------------------------ | | Static config only | Live + historical monitoring | | No APIs | Full REST API + NetEdit | | No automation | Python scripting, ZTP, NetEdit | | No rollback | Config checkpoints + rollback | | Limited routing | Full Layer 3: OSPF, BGP, VRF | ##### **User Interface:** - ArubaOS-CX CLI is **structured and context-aware**. Example: ```shell config interface 1/1/1 description "Link to Core" no shutdown ``` - Also supports a **web GUI** for configuration and monitoring. ##### **Use Case Scenarios:** - Modern enterprise networks - **Access to core** switching - Automation-heavy or **cloud-integrated** environments - Network teams using **CI/CD principles** #### Summary Comparison Table: | Feature | ArubaOS | ArubaOS-CX | | ------------------- | --------------------- | ---------------------------- | | Architecture | Monolithic | Modular + database-driven | | Telemetry & History | No | Yes (real-time + historical) | | API Support | No | Yes (RESTful API) | | Scripting | No | Yes (Python) | | Automation | Manual only | Full automation pipeline | | Use Case | Basic/legacy networks | Modern enterprise networks | ### **III. Aruba Switching Features and Technologies** This section explains the **built-in technologies** that make Aruba switches powerful, flexible, and suited for enterprise environments. These features enable **resilience**, **traffic control**, and **high performance** in real-world networks. #### **1. VSF (Virtual Switching Framework)** ##### **What is VSF?** - VSF allows you to **stack multiple Aruba switches** into a **single logical switch**. - Managed as one device with **one IP address**. ##### **Benefits of VSF:** - **Redundancy**: If one switch fails, traffic continues through the others. - **Simplicity**: Manage 2–4 switches as if they were one. - **Scalability**: Easily add ports by adding another switch to the stack. ##### **VSF Supported Models:** - Aruba **2930F**, **2930M**, **3810**, **6300** ##### **Use Case:** - **Access or distribution layer** deployments needing **resilience** without complex configurations. #### **2. VSX (Virtual Switching Extension)** ##### **What is VSX?** - VSX is for **core switches**. - Creates an **active-active cluster** of **two switches**, each running independently but sharing routing information. ##### **Why it's better than VSF for the core:** - No single point of failure. - Supports **hitless upgrades** (you can upgrade one switch without affecting traffic). - Uses **LAG + dynamic routing** across both switches. ##### **VSX Supported Models:** - Aruba **CX 8320**, **CX 8400** ##### **Use Case:** - **Core and data center** deployments needing maximum uptime and live upgrades. #### **3. ACLs (Access Control Lists)** ##### **What are ACLs?** - ACLs **filter network traffic** based on: - **IP addresses** - **Ports** - **Protocols** They are used to **enforce security policies** and block unwanted traffic. ##### **Where to apply ACLs:** - On **VLAN interfaces** (SVIs) - On **physical interfaces** - **Inbound or outbound** directions ##### **Example Use Case:** - Block HTTP traffic from guest VLAN to internal servers: ```shell ip access-list "BLOCK_HTTP" 10 deny tcp any 192.168.1.0 0.0.0.255 eq 80 20 permit ip any any ``` #### **4. QoS (Quality of Service)** ##### **What is QoS?** QoS ensures that **important traffic (like VoIP)** gets priority over less critical traffic (like file downloads). ##### **Common QoS Features:** - **DSCP (Layer 3):** Marks packets with priority values. - **802.1p (CoS, Layer 2):** Marks Ethernet frames for switching priority. - **Queue scheduling**: Determines which traffic is sent first (e.g., strict priority, weighted round robin). ##### **Use Case:** - Guarantee **low delay and jitter** for voice traffic on VLAN 10. #### **5. Multicast Support** ##### **What is Multicast?** - Used to send data to **multiple specific devices** (like IPTV users or video streamers), not to all. ##### **IGMP Snooping:** - Monitors **IGMP Join/Leave** messages. - **Only forwards multicast traffic** to ports that have requested it. ##### **Use Case:** - In a classroom or campus where many devices watch the same **live video stream**. #### **6. LAG / LACP (Link Aggregation)** ##### **What is LAG?** LAG (Link Aggregation Group) combines **multiple physical links** into a **single logical connection**. ##### **LACP (Link Aggregation Control Protocol):** - Dynamically negotiates the LAG. - Helps avoid misconfigurations and link mismatches. ##### **Benefits of LAG:** - **Higher bandwidth** - **Redundancy** (if one link fails, the others continue working) - **Load balancing** ##### **Common Aruba LAG Commands:** ```shell interface 1/1/1 lag 1 mode active interface 1/1/2 lag 1 mode active ``` #### Recap of Aruba Switching Features: | Feature | Purpose | Use Case | | ------------- | ------------------------------------ | ------------------------------------------ | | **VSF** | Stack multiple switches | Campus access/distribution | | **VSX** | Active-active core switching | Core, data center | | **ACLs** | Filter traffic | Enforce security policies | | **QoS** | Prioritize important traffic | Voice/video over network | | **Multicast** | Efficient broadcast to groups | IPTV, streaming | | **LAG/LACP** | Aggregate links for speed/redundancy | Switch-to-switch or switch-to-core uplinks | ### **IV. Aruba Network Management Platforms** Aruba provides powerful tools for **centralized network management**, **monitoring**, and **automation**. Whether your environment is cloud-native, hybrid, or fully on-premises, Aruba has a platform to match. #### **1. Aruba Central (Cloud-Based NMS)** ##### **What is Aruba Central?** - A **cloud-based** platform to manage: - **Switches** - **Access Points (APs)** - **Gateways/Controllers** - Accessible through a web portal from anywhere. ##### **Key Features:** | Feature | Description | | ------------------------------------ | ------------------------------------------------------------------ | | **Zero-Touch Provisioning (ZTP)** | Automatically configure devices when they boot for the first time. | | **Monitoring & Troubleshooting** | Real-time stats, logs, and health scores. | | **AI Insights** | Identifies anomalies (e.g., interface flapping, broadcast storms). | | **Configuration Management** | Push global or device-level configurations via templates or GUI. | | **Firmware Updates** | Schedule and automate upgrades across devices. | | **Role-Based Access Control (RBAC)** | Assign different permissions to different admins. | | **Visual Topology Maps** | See how devices connect in real time. | ##### **Use Case:** - Ideal for **distributed networks**, such as: - Retail stores - Schools - Branch offices Aruba Central supports **both ArubaOS-CX and ArubaOS-based devices**. #### **2. Aruba NetEdit (On-Prem, CX-Focused)** ##### **What is NetEdit?** - An **on-premises network automation tool** focused on **ArubaOS-CX switches**. ##### **Key Features:** | Feature | Description | | ------------------------- | ------------------------------------------------------ | | **Multi-device editing** | Edit configurations across many switches at once. | | **Validation engine** | Detects errors **before** they go live. | | **Audit and history** | Tracks changes for **compliance and troubleshooting**. | | **Snapshot and rollback** | Save and revert configurations safely. | | **REST API integration** | Supports CI/CD and automation workflows. | ##### **Use Case:** - Enterprise networks using **CX 6200/6300/8320/8400** - IT teams that want **programmable, automated network changes** NetEdit is **complementary to Aruba Central**, not a replacement. #### **3. Aruba AirWave (Legacy NMS)** ##### **What is AirWave?** - A traditional **on-premises network management system**. - Designed for both **wired and wireless** infrastructure. ##### **Key Features:** | Feature | Description | | ---------------------- | -------------------------------------------------------- | | **Device Monitoring** | Status and health of APs, switches, controllers | | **Visual RF Planning** | Helps plan Wi-Fi deployments and detect coverage gaps | | **Alerts and Reports** | Custom alert rules, historical usage reports | | **Config Management** | Manage and push switch configurations | | **Client Tracking** | See which device is connected to which switch port or AP | ##### **Use Case:** - Enterprises with **older Aruba deployments** - Environments that **do not use Aruba Central** Aruba recommends **migrating to Central** for newer installations. #### Quick Comparison Table: | Platform | Deployment Type | Focus | Best for... | | ----------------- | --------------- | ------------------------------------ | ---------------------------------------- | | **Aruba Central** | Cloud | Full-stack (switches, APs, gateways) | New networks, distributed sites | | **NetEdit** | On-prem (local) | ArubaOS-CX switches | CX environments, automation-focused ops | | **AirWave** | On-prem | Legacy wired/wireless | Existing deployments, migration planning | ### **V. Key Aruba Features** Aruba offers advanced features that go **beyond traditional switching**, helping you build a **smarter, more secure, and automated network**. These features are built into the **ArubaOS-CX ecosystem** and are especially powerful when used alongside **Aruba Central** and **ClearPass**. #### **1. NAP (Network Analytics Processor)** ##### **What it is:** - An **onboard analytics engine** built into ArubaOS-CX switches. - Continuously collects **real-time and historical data** from the switch. ##### **What it does:** - Monitors: - Interface stats (errors, discards) - CPU and memory usage - Protocol events (e.g., OSPF flaps) - Supports **custom scripts and queries** to detect anomalies. ##### **Why it matters:** - Enables **faster troubleshooting** (you can see what happened before a ticket was raised). - No external agent or appliance is needed. - Works with **Aruba Central AI Insights** for smart alerting. #### **2. Dynamic Segmentation** ##### **What it is:** - A feature that **enforces access policies automatically** across both wired and wireless users. - Based on the user’s **identity, device type, role, or group membership**. ##### **How it works:** 1. User plugs into a port (or connects to Wi-Fi). 2. Aruba switch contacts **ClearPass** (Aruba’s NAC solution). 3. ClearPass tells the switch: - Which VLAN to assign - What ACL to apply - What QoS profile to enforce 4. The switch **dynamically segments** traffic based on policy — not physical port or SSID. ##### **Benefits:** - Users can **move between ports or sites** and keep the same access policy. - Great for **BYOD, guest, and IoT device control**. #### **3. NetEdit (Automation Platform)** We covered this in Section IV, but here’s a recap focused on features: | Function | Description | | ---------------------- | ---------------------------------------------- | | **Multi-device edits** | Change configs across many CX switches at once | | **Validation engine** | Prevents misconfigurations before deployment | | **Audit history** | Tracks who did what, and when | | **Integration** | Works with REST APIs and Git-based workflows | NetEdit is a **must-have for large ArubaOS-CX environments** with change control or compliance needs. #### **4. Colorless Ports** ##### **What it is:** - A port that **doesn’t need to be pre-configured** for a specific user or device type. ##### **How it works:** - When a device connects, the switch **automatically assigns VLAN, ACL, and QoS policies** based on: - Device MAC address - Authentication result from ClearPass - Device type or group ##### **Benefits:** - **Simplifies port configuration** — you no longer need to remember which port is for which department. - **Dynamic and scalable** — great for hot-desking, mobile users, and IoT devices. #### **5. Zero Touch Provisioning (ZTP)** ##### **What it is:** - A feature that **automates switch setup** — no manual configuration needed. ##### **How it works:** 1. Switch boots up and sends a DHCP request. 2. DHCP server provides: - IP address - Option for **ZTP server** (or Aruba Central link) 3. Switch downloads configuration and firmware. 4. Instantly becomes part of the network. ##### **Use Case:** - Large-scale deployments (e.g., branch rollouts) - **Non-technical staff** can simply rack and power on the switch — Aruba handles the rest. #### Recap Table of Key Features: | Feature | Purpose | ArubaOS-CX? | Aruba Central? | | ------------------------ | ---------------------------------------------------- | ----------- | -------------- | | **NAP** | Real-time and historical switch analytics | Y | Y (integrates) | | **Dynamic Segmentation** | Role-based, identity-aware access enforcement | Y | Y | | **NetEdit** | Multi-device automation with config validation | Y | — | | **Colorless Ports** | Automatically assign roles/policies to users/devices | Y | Y | | **ZTP** | Automatic provisioning on first boot | Y | Y | ### **VI. Security and Access Features** In enterprise networks, **security starts at the edge** — meaning the **switch ports** where users and devices connect. Aruba switches include built-in access control features that help enforce **who can connect**, **what they can access**, and **how to protect the network from attacks**. #### **1. MAC Authentication & 802.1X** ##### **MAC Authentication (MAC Auth)** - Authenticates a device **based on its MAC address**. - Used for **non-user devices** that don’t support usernames/passwords (e.g., printers, cameras, VoIP phones). - Requires integration with a **RADIUS server** (typically **ClearPass**). ###### **How it works:** 1. Device connects to a port. 2. Switch sends the MAC address to RADIUS. 3. RADIUS checks if the MAC is allowed and returns access decision. ###### **Use Case:** - IoT devices - Non-802.1X devices ##### **802.1X Authentication** - A **standards-based protocol** for **port-based network access control**. - Authenticates users/devices **before** they can send traffic through the switch. ###### **How it works:** 1. User connects a device to the switch. 2. The switch (authenticator) communicates with the **RADIUS server** (ClearPass). 3. The server checks credentials. 4. If authorized, the switch **opens the port**; otherwise, it stays **blocked**. ###### **Benefits:** - Strong security using **user credentials**, certificates, or tokens. - Works with **Dynamic VLAN Assignment** — each user gets their own VLAN and policy. ##### **Configuration Summary:** - Enable 802.1X on access ports: ```shell interface 1/1/10 aaa port-access authenticator aaa port-access enable ``` - Configure switch as authenticator and define RADIUS server. #### **2. Port Security** - Limits how many **MAC addresses** can be learned on a port. - Can **lock** the port to specific MAC addresses. ###### **Options:** | Setting | What It Does | | -------------------- | ----------------------------------------- | | `max 1` | Only one MAC allowed | | `mac-address sticky` | Learns the first MAC and remembers it | | `violation shutdown` | Disables port if unauthorized MAC appears | ###### **Use Case:** - Prevent rogue devices in office networks - Enforce "one user per port" policy #### **3. DHCP Snooping** - Protects against **rogue DHCP servers** in the network. - Ensures only **authorized DHCP servers** can respond to clients. ##### **How it works:** 1. Switch watches for DHCP traffic. 2. **Trusted ports** (e.g., uplinks) can send DHCP offers. 3. **Untrusted ports** (user ports) cannot act as DHCP servers. ##### **DHCP Snooping Table:** - Switch maintains a **binding table** of: - IP address - MAC address - VLAN - Interface This table can be used for other security features like **ARP Inspection** and **IP Source Guard**. ##### **Configuration Example:** ```shell dhcp-snooping dhcp-snooping vlan 10 interface 1/1/1 dhcp-snooping trust ``` #### **4. ARP Inspection & IP Source Guard** These features **protect Layer 2 and Layer 3 from spoofing attacks**. ##### **ARP Inspection** - Blocks **fake ARP replies** that try to redirect traffic (ARP spoofing). - Cross-checks ARP packets against the **DHCP snooping table**. ###### **Use Case:** - Prevent man-in-the-middle attacks in sensitive VLANs. ##### **IP Source Guard** - Prevents a device from using an IP address that doesn’t belong to it. - Uses DHCP snooping bindings to verify IP/MAC/interface combinations. ##### **Why These Matter:** | Feature | What It Protects Against | Common Use Case | | --------------------- | ------------------------------ | --------------------------- | | **MAC Auth / 802.1X** | Unauthorized users/devices | Secure enterprise access | | **Port Security** | Device spoofing / MAC flooding | Limiting users per port | | **DHCP Snooping** | Rogue DHCP servers | Prevent fake IP assignments | | **ARP Inspection** | ARP spoofing / MITM attacks | Secure VLANs (finance, HR) | | **IP Source Guard** | IP spoofing | Protect Layer 3 traffic | ### **VII. Aruba Switching Use Cases** To make good network design decisions, it’s essential to understand **which Aruba switch series fits best in which part of the network**. Aruba offers different switch families optimized for **cost, performance, scalability, or advanced features** — so choosing the right one ensures your network is reliable, scalable, and secure. #### **1. Small/Medium Business (SMB)** ##### **Recommended Models:** - **Aruba 2530** - **Aruba 2540** ##### **Why These Work:** | Criteria | Details | | ------------------------------------ | ---------------------------------------------- | | **Low cost** | Great for budget-conscious environments | | **Simple Layer 2 or static Layer 3** | Most small offices don’t need advanced routing | | **Fanless options** | Quiet, suitable for office closets | | **PoE support** | Can power phones and access points | ##### **Common Use Cases:** - Retail shops - Small offices - Remote branch deployments - Simple wired LANs with a few VLANs #### **2. Campus Access / Edge** ##### **Recommended Models:** - **Aruba 2930F** - **Aruba 2930M** - **Aruba CX 6200** ##### **Why These Work:** | Feature | Benefit | | ------------------------------ | --------------------------------------------- | | **VSF support** (2930F/M) | Stack multiple switches for redundancy | | **Static and dynamic routing** | Enables inter-VLAN routing at the edge | | **Advanced PoE** options | Power access points, VoIP phones, IoT devices | | **ArubaOS-CX on 6200** | Modern features + automation + telemetry | ##### **Common Use Cases:** - School classroom switches - Office floor edge switches - Access layer in hospitals or universities #### **3. Distribution Layer** ##### **Recommended Models:** - **Aruba 3810** - **Aruba CX 6300** ##### **Why These Work:** | Feature | Benefit | | -------------------------- | ----------------------------------------------------- | | **Layer 3 scalability** | Handles traffic aggregation from many access switches | | **VSF and LAG support** | High availability and bandwidth | | **Modular options (3810)** | Flexible power and cooling | | **Full CX OS (6300)** | Automation, scripting, and monitoring included | ##### **Common Use Cases:** - Aggregation switches in large buildings - Connecting multiple access switch stacks - Medium-size core/distribution for enterprises #### **4. Core Layer / Data Center** ##### **Recommended Models:** - **Aruba CX 8320** - **Aruba CX 8400** ##### **Why These Work:** | Feature | Benefit | | ----------------------------- | ----------------------------------------------------- | | **VSX** | Active-active core with hitless upgrades | | **Modular hardware** | Hot-swappable line cards, power, and fans | | **High-speed ports** | 40/100Gbps uplinks for maximum throughput | | **Full automation/telemetry** | Perfect for large-scale and cloud-integrated networks | ##### **Common Use Cases:** - Campus core switches - Data center spine-leaf architectures - High-density traffic aggregation and routing #### Quick Matching Table: | Use Case | Recommended Series | Notes | | ------------------------- | --------------------- | ------------------------------------------------- | | Small Office / Retail | 2530, 2540 | Basic Layer 2/3, low cost | | Enterprise Edge / Access | 2930F, 2930M, CX 6200 | PoE+, VSF, some Layer 3 | | Distribution Layer | 3810, CX 6300 | High performance, full Layer 3, stackable | | Campus Core / Data Center | CX 8320, CX 8400 | VSX, modular, high-speed uplinks, full automation | ### **VIII. Differentiators vs. Competitors** This section highlights what sets **Aruba switching solutions apart** from competitors like **Cisco**, **Juniper**, or **HP ProCurve**. These **unique features and design philosophies** are important to know — not just for the HPE6-A72 exam, but also for real-world conversations with customers or decision-makers. #### **1. ArubaOS-CX is Modular, Database-Driven, and Telemetry-Rich** ##### **How it's different:** - Most traditional switch OSs are **monolithic**: all services (routing, QoS, etc.) run together. - ArubaOS-CX is **modular**, meaning each function runs independently — if one crashes, others stay running. - Everything is backed by a **state database**, so you can query: - Interface states - Routing changes - Historical performance trends ##### **Benefits:** | Feature | Advantage Over Competitors | | ------------------------------- | ----------------------------------------------------- | | **Crash resilience** | One module can fail without killing the whole switch | | **Real-time + historical data** | View past CPU usage, interface errors, and link flaps | | **Structured CLI + REST API** | Full automation and DevOps integration out of the box | #### **2. Aruba Central Offers AI-Powered, Cloud-Native Network Management** ##### **Why it matters:** - Competing cloud NMS platforms often **lack deep AI or full-stack visibility**. - Aruba Central provides: - **End-to-end visibility** (switches, APs, gateways, clients) - **AI Insights**: Identifies and explains root causes - **Built-in security and segmentation tools** - **Scalable from one site to thousands** ##### **Differentiator:** Unlike Cisco DNA Center (which is expensive and complex), **Aruba Central is more accessible** and **100% cloud-native** — no on-prem appliances needed. #### **3. ClearPass Integration for Role-Based Access** - Aruba has **seamless integration** with **ClearPass Policy Manager**, its NAC (Network Access Control) solution. - You can apply **dynamic access policies** on both **wired and wireless ports** using: - User identity - Device type (IoT, BYOD, corporate laptop) - Location ##### **Why it’s unique:** - ClearPass is **vendor-agnostic** (works with Cisco, Juniper too). - Aruba switches support **colorless ports**, dynamic VLANs, ACLs, and more based on ClearPass policies. #### **4. Consistency Across Wired and Wireless** ##### **Unified Infrastructure Philosophy:** - Aruba treats **switches and access points as equal citizens**. - You can: - Use **one management platform** for wired + wireless. - Apply **the same policy framework** across both. - Analyze and troubleshoot **both layers** in Aruba Central. ##### **Competitor Comparison:** | Feature | Aruba | Cisco | | ------------------------------ | -------------------------- | ------------------------------------- | | One cloud for wired + wireless | Aruba Central | Separate tools (Meraki/DNAC) | | NAC integration | ClearPass (deep, flexible) | ISE (more complex, less flexible) | | Automation support | Native Python + REST | Often requires extra software | | Historical telemetry | Built-in | Requires DNA Center or external tools | #### Summary Table: Aruba Differentiators | Differentiator | What It Means in Practice | | ---------------------------------------- | ------------------------------------------------------- | | **ArubaOS-CX modular OS** | Reliable, resilient, easy to automate | | **Real-time + historical telemetry** | See trends and past issues natively | | **Aruba Central (cloud-native)** | Manage everything from anywhere, scale easily | | **AI-powered insights** | Fast root cause detection, fewer support tickets | | **ClearPass integration** | Unified security across wired and wireless | | **Colorless ports and dynamic policies** | No manual port configs; policies follow the user/device | | **Unified network stack** | One OS, one policy model, one management tool | --- # Install, configure, set up, and validate Aruba solutions ### **I. Initial Setup and Access** This is what you do **right after unpacking a switch**, when you're getting it online for the first time — whether you're setting it up on a bench (lab environment) or preparing it for live deployment. #### **1. Device Boot and Access Methods** ##### **a. Console Access (Serial)** - **Purpose:** Used for **first-time setup**, **troubleshooting**, or **when no IP is assigned yet**. - **Connection:** A console cable (usually USB to RJ-45 or USB-A to micro-USB) connects your PC to the switch's **console port**. - **Software:** Use a terminal program like: - **PuTTY** - **Tera Term** - **HyperTerminal** (older) ###### **Default Settings:** - Baud rate: `9600` - Data bits: `8` - Stop bits: `1` - Parity: `None` - Flow control: `None` ###### **Use Case:** - Resetting a switch - Setting initial hostname and IP - Recovering from misconfiguration ##### **b. Out-of-Band Management (Mgmt Port)** - Aruba switches (CX series especially) often include a **dedicated Mgmt port**. - This port is **separate from data traffic**, used **only for management**. - Assign it a **static IP** or let it obtain one via DHCP. - You can SSH or use HTTPS (if enabled) on this port. ##### **c. In-Band Management (via VLAN)** - You can also manage the switch through a **normal data port**, if it's: - In the **management VLAN** - Assigned an IP address ###### **Example:** ```shell interface vlan 100 ip address 192.168.100.10/24 ``` - This method uses the same interfaces that carry user/data traffic. #### **2. Basic CLI Navigation** Aruba uses two main OSs, and each has a slightly different CLI style: ##### **ArubaOS (Provision OS — Legacy)** - Uses a **traditional, flat command structure** like Cisco IOS. - Enter config mode with: ```shell configure terminal ``` - Example hierarchy: ```shell configure terminal interface 1/1/1 vlan 10 untagged exit write memory ``` ##### **ArubaOS-CX (Modern OS)** - CLI is **context-sensitive** and **modular**. - You can move into contexts like this: ```shell config interface 1/1/1 no shutdown ``` - Uses **transactional configuration**, so you can: - Preview changes - Commit them all at once #### **3. Initial Configuration Tasks** These are the **first things** you configure on a switch: ##### **a. Set Hostname and Domain Name** ```shell hostname Access-Switch-1 domain-name campus.example.com ``` - Helps identify the switch in logs, monitoring tools, and when using SSH certificates. ##### **b. Assign Management IP** **Static IP on VLAN interface:** ```shell interface vlan 1 ip address 192.168.1.10/24 ``` **Or use DHCP (usually on CX):** ```shell interface vlan 1 ip address dhcp-bootp ``` ##### **c. Configure Default Gateway** - Needed so the switch can reach **remote networks**, like Aruba Central or DNS servers. ```shell ip route 0.0.0.0/0 192.168.1.1 ``` ##### **d. Set User Credentials** **Create or reset an admin user:** ```shell user admin password plaintext MySecurePwd ``` ##### **e. Enable SSH (disable Telnet)** ```shell crypto key generate ssh ip ssh no telnet-server ``` - SSH is secure; Telnet is **not encrypted** and should always be disabled. #### Recap of Initial Setup and Access | Step | Command Example or Tool | Notes | | -------------------- | ------------------------------ | ---------------------------------------- | | Console access | PuTTY / Tera Term | Needed for first-time or recovery | | Assign hostname/IP | `hostname`, `ip address` | Use VLAN interface for mgmt | | Default route | `ip route 0.0.0.0/0 ` | Allows switch to reach external networks | | Secure remote access | `ip ssh`, `no telnet-server` | Always prefer SSH over Telnet | ### **II. VLAN and Interface Configuration** VLANs and interface configurations are **foundational** for network segmentation and traffic control. Aruba switches allow you to create **logical broadcast domains**, assign interfaces to them, and configure uplinks (trunks) and aggregated links (LAGs). #### **1. VLAN Creation and Assignment** VLANs (Virtual Local Area Networks) separate traffic at **Layer 2** to reduce broadcast domains and organize network roles (e.g., separating users, servers, and printers). ##### **Step 1: Define a VLAN** **ArubaOS (legacy):** ```shell vlan 10 name Sales ``` **ArubaOS-CX:** ```shell vlan 10 name Sales ``` Same command format — consistent across OS versions. ##### **Step 2: Assign VLAN to Interfaces** | VLAN Mode | Command Example | Use Case | | --------- | ------------------------ | -------------------------------------------------- | | Untagged | `vlan 10 untagged 1/1/1` | For devices that don’t tag VLANs (PCs, printers) | | Tagged | `vlan 10 tagged 1/1/48` | Used for uplinks or LAGs that carry multiple VLANs | **Explanation:** - **Untagged**: Port belongs to **one VLAN only**. Traffic exits without a VLAN tag. - **Tagged**: Port is part of a **trunk**, carrying **multiple VLANs** using 802.1Q tags. ##### **Step 3: Configure Native VLAN on Trunk Ports** Some devices send **untagged traffic** over a trunk (e.g., IP phones or APs). To handle this: ```shell interface 1/1/48 vlan 1 untagged vlan 10,20,30 tagged ``` - VLAN 1 is native (untagged). - VLANs 10, 20, 30 are tagged. #### **2. Interface Settings** You may want to **manually set speed, duplex**, or **describe the port role** for documentation. ##### **Common Interface Settings:** ```shell interface 1/1/5 speed 1000 duplex full description "Uplink to Core" no shutdown ``` ##### **Other Notes:** - Aruba switches **auto-negotiate** speed/duplex by default. - Use manual settings only if you're having negotiation problems or for specific uplinks. #### **3. Trunking and LAGs** ##### **a. Create a LAG (Link Aggregation Group)** A LAG combines **two or more ports** into one logical link, increasing bandwidth and redundancy. ###### **Step-by-step (ArubaOS-CX):** ```shell interface lag 1 no shutdown vlan 10,20,30 tagged ``` ##### **b. Assign Ports to the LAG** ```shell interface 1/1/1 lag 1 mode active interface 1/1/2 lag 1 mode active ``` - **Mode active** enables **LACP** (Link Aggregation Control Protocol). - LACP is the preferred way to negotiate LAGs **dynamically and safely**. ##### **Best Practices for LAGs:** - Always use **even-numbered links** (2, 4, etc.). - Make sure **both ends** (e.g., switches or servers) have identical configs. - Use **LACP mode active** instead of static LAGs when possible. #### Recap of VLAN and Interfaces | Task | Command Example / Note | | ---------------------- | ----------------------------------------------- | | Create VLAN | `vlan 10`, `name Sales` | | Assign VLAN to port | `vlan 10 untagged 1/1/5` | | Tag VLANs for trunk | `vlan 10,20,30 tagged 1/1/48` | | Set native VLAN | `vlan 1 untagged` (on trunk port) | | Set interface settings | `speed`, `duplex`, `description`, `no shutdown` | | Create LAG | `interface lag 1`, `vlan tagged`, `no shutdown` | | Add ports to LAG | `lag 1 mode active` on each member interface | ### **III. Routing Configuration** Routing is what enables **communication between VLANs** or **networks**. Aruba switches that support Layer 3 (like the **2930F/M**, **CX 6200/6300**, **3810**, and higher) can perform routing functions without needing a separate router. #### **1. Static Routing** ##### **What is Static Routing?** Static routes are **manually configured** routes used to tell the switch how to reach networks that are **not directly connected**. ##### **Why it’s important:** - Necessary for **inter-VLAN routing** - Required to reach the **internet** or **remote sites** ##### **Static Route Syntax:** ```shell ip route 0.0.0.0/0 192.168.1.1 ``` | Part | Meaning | | ------------- | ---------------------------------------------------- | | `0.0.0.0/0` | The default route (any unknown destination) | | `192.168.1.1` | The next-hop IP (typically your firewall or gateway) | ##### **Example:** Your switch has VLANs 10, 20, and 30 configured, and you want all traffic to exit through a firewall at `192.168.1.1`. ```shell ip route 0.0.0.0/0 192.168.1.1 ``` This ensures that devices in VLANs can **reach external destinations**, including the internet. #### **2. Inter-VLAN Routing** Aruba switches use **SVIs (Switch Virtual Interfaces)** to route between VLANs. ##### **Step 1: Enable Routing (CX Only)** ```shell ip routing ``` Required for CX switches to perform routing. ##### **Step 2: Create VLAN Interfaces (SVIs)** ```shell vlan 10 interface vlan 10 ip address 192.168.10.1/24 no shutdown vlan 20 interface vlan 20 ip address 192.168.20.1/24 no shutdown ``` ##### **Now what happens?** - Devices in VLAN 10 use `192.168.10.1` as their **default gateway**. - Devices in VLAN 20 use `192.168.20.1`. - The switch **routes between the two VLANs directly**, allowing communication. ##### **Verification:** ```shell show ip route ping 192.168.20.5 ``` #### **3. OSPF (Open Shortest Path First)** – Introductory Level ##### **What is OSPF?** A **dynamic routing protocol** used in **larger or redundant networks** where manual routes would be hard to manage. ArubaOS-CX supports **OSPFv2 (IPv4)** and **OSPFv3 (IPv6)**. ##### **Why use OSPF?** - Automatically learns and advertises routes. - Supports **loop prevention** and **cost-based path selection**. - Better for networks with **multiple routers** or **failover paths**. ##### **Basic OSPF Setup Example:** **Step 1: Enable OSPF and set router ID** ```shell router ospf 1 router-id 1.1.1.1 ``` **Step 2: Assign interfaces to areas** ```shell interface vlan 10 ip ospf 1 area 0.0.0.0 interface vlan 20 ip ospf 1 area 0.0.0.0 ``` **Area 0** is the **backbone area** and is required in most OSPF deployments. ##### **OSPF Terminology:** | Term | Description | | ---------------- | ------------------------------------------------------ | | **Router ID** | Unique identifier (can be loopback IP or manually set) | | **Area** | Logical grouping of OSPF-enabled interfaces | | **Hello Packet** | Sent regularly to discover neighbors | | **LSA** | Link-State Advertisement — contains routing info | #### Recap of Routing Section | Task | Command Example | | ------------------- | ----------------------------------------- | | Enable routing | `ip routing` (CX switches only) | | Add static route | `ip route 0.0.0.0/0 192.168.1.1` | | Create SVI for VLAN | `interface vlan 10`, `ip address` | | Enable OSPF | `router ospf 1`, `ip ospf 1 area 0.0.0.0` | | Check route table | `show ip route` | ### **IV. DHCP Configuration** Aruba switches can **receive**, **forward**, or even **serve** IP addresses using DHCP (Dynamic Host Configuration Protocol). Knowing when and how to configure each DHCP role is essential in deployments involving both ArubaOS and ArubaOS-CX. #### **1. DHCP Client** This allows the switch to **obtain its own IP address** automatically from a DHCP server — often used for **out-of-band management interfaces** or in **ZTP (Zero Touch Provisioning)** setups. ##### **Example:** ```shell interface vlan 1 ip address dhcp-bootp ``` The switch will request an IP address on VLAN 1 from any available DHCP server. ##### **Use Case:** - **First-time deployments** - Management ports in **DHCP-managed networks** - Environments using **Aruba Central for ZTP** #### **2. DHCP Relay (Helper Address)** Switches **forward DHCP requests** from clients to a DHCP server located **in another VLAN or subnet**. ##### **Why You Need DHCP Relay:** - DHCP uses **broadcasts**, which don’t cross routers. - If the DHCP server is in VLAN 100 and the clients are in VLAN 10, you must **relay the request**. ##### **Command Example:** ```shell interface vlan 10 ip helper-address 192.168.100.10 ``` This tells the switch to forward all DHCP Discover messages to `192.168.100.10`. ##### **Use Case:** - Central DHCP server serving **multiple VLANs** - Required in **inter-VLAN** routing environments #### **3. DHCP Server (Lightweight)** Some Aruba switches (usually **ArubaOS-based**, not CX) can act as a **basic DHCP server**. This is useful in small or isolated networks. ##### **Example Configuration:** ```shell dhcp-server pool "Sales" network 192.168.10.0 255.255.255.0 default-router 192.168.10.1 dns-server 8.8.8.8 ``` - **Pool name**: Sales - **Range**: 192.168.10.0/24 - **Default Gateway**: 192.168.10.1 (typically the SVI) - **DNS Server**: Google DNS (8.8.8.8) ##### **Limitations:** - Not scalable for large networks - Doesn’t support advanced options (like PXE boot) - Not available on all CX platforms #### Summary of DHCP Roles: | Role | Description | Command Example | | --------------- | ------------------------------------------- | ----------------------------------------------- | | **DHCP Client** | Switch gets its own IP via DHCP | `ip address dhcp-bootp` | | **DHCP Relay** | Forwards client requests to a remote server | `ip helper-address ` | | **DHCP Server** | Switch gives out IP addresses to clients | `dhcp-server pool`, `network`, `default-router` | ### **V. AAA and Access Control** This section introduces **authentication, authorization, and accounting (AAA)** — the foundation of **controlling who accesses the network**, **how they connect**, and **how access is managed or logged**. Aruba switches support both **basic local methods** and **enterprise integration** with **ClearPass Policy Manager**. #### **1. Local Authentication** This is the simplest method to control who can log into a switch (via SSH or console). Aruba lets you create **local usernames and passwords**, and assign **roles** (like operator or manager). ##### **Command Example:** ```shell user admin password plaintext MySecurePwd ``` ##### **Optional: Assign Role** ```shell user admin password plaintext MySecurePwd operator ``` - `manager`: Full privileges (default if role not specified) - `operator`: View-only access (no config commands) ##### **Use Case:** - Standalone switches - Temporary login before integrating with RADIUS/TACACS #### **2. 802.1X Configuration (Introductory)** 802.1X is the **industry-standard protocol** for **port-based authentication**. It’s used to ensure **only authorized users/devices can access the network**. Aruba switches act as **authenticators**, checking credentials with a **RADIUS server** like ClearPass. ##### **Components:** | Component | Role | | ------------- | --------------------------------------------- | | Supplicant | The device trying to connect (e.g., a laptop) | | Authenticator | The switch port (controls access) | | RADIUS Server | Verifies identity (e.g., ClearPass) | ##### **Step 1: Enable 802.1X Globally** ```shell aaa port-access authenticator ``` ##### **Step 2: Enable 802.1X on a Port** ```shell interface 1/1/1 aaa port-access authenticator aaa port-access enable ``` ##### **Step 3: Define RADIUS Server (if not using ClearPass Central Integration)** ```shell radius-server host 192.168.1.50 key MySecretKey ``` The key must match the one defined in ClearPass. #### **Optional Enhancements (ClearPass):** - **Role-based VLAN assignment** - **Downloadable ACLs (dACLs)** - **Device profiling** (IoT vs. user devices) - **Guest and BYOD onboarding** #### Summary of AAA Features: | Feature | Purpose | Use Case | | ------------------------ | -------------------------------------------- | ------------------------------- | | **Local Authentication** | Define users directly on switch | Small sites, initial setup | | **802.1X Auth** | Secure port access via identity verification | Enterprise wired access control | | **RADIUS Integration** | Use external server for centralized policy | ClearPass or Microsoft NPS | ### **VI. Monitoring and Validation** Once your switch is up and configured, you need to verify it’s working properly. Aruba switches offer a **comprehensive set of diagnostic and monitoring tools**, available through both **CLI and management platforms** like **Aruba Central**. #### **1. Show Commands** These commands are your **first line of visibility** into the switch’s operational state. Learn to use them **regularly** to confirm configurations or diagnose issues. ##### **a. show interface brief** - Displays summary info for all ports: - Link status (up/down) - Assigned VLANs - Port speeds ```shell show interface brief ``` Use this to quickly check if a port is physically connected and active. ##### **b. show vlan** - Lists all VLANs and their associated interfaces. - Confirms untagged/tagged port assignments. ```shell show vlan ``` ##### **c. show ip route** - Displays the current **routing table**. - Confirms static and dynamic routes. - Shows next-hop IPs and routing protocols in use. ```shell show ip route ``` ##### **d. show spanning-tree** - Shows **STP/RSTP** status per VLAN. - Identifies blocked ports, root bridges, and topology changes. ```shell show spanning-tree ``` ##### **e. show lag** - Displays LAG configuration and status: - Member interfaces - LACP status - Operational status ```shell show lag ``` #### **2. Ping and Traceroute** These are your basic **Layer 3 testing tools**. ##### **ping** - Verifies basic connectivity to another device. - Example: ```shell ping 192.168.1.1 ``` ##### **traceroute** - Shows the path traffic takes to reach a destination (e.g., external website). - Helpful for locating **routing loops** or **unreachable hops**. ```shell traceroute 8.8.8.8 ``` #### **3. Logs and Events** Switches generate logs to help you understand what's happening in real time and historically. ##### **a. show logging** - Displays **system logs**: interface changes, login attempts, errors. ```shell show logging ``` ##### **b. Configure Logging Level** - Adjusts the severity level of logs: ```shell logging level info ``` | Level | Meaning | | -------- | ----------------------------------- | | debug | Most detailed (for troubleshooting) | | info | General info (recommended) | | warning | Warnings only | | critical | Only major errors/failures | ##### **c. Export Logs** - You can send logs to an **external syslog server**: ```shell logging 192.168.100.50 ``` Always recommended in **production environments**. #### Monitoring Summary: | Task | Command | Purpose | | ----------------- | ---------------------------- | --------------------------------- | | Interface summary | `show interface brief` | Physical and link status | | VLAN check | `show vlan` | VLAN-to-port assignment | | Routing check | `show ip route` | View routing table | | STP check | `show spanning-tree` | Loop prevention and port blocking | | LAG status | `show lag` | LAG operational health | | Ping/traceroute | `ping`, `traceroute` | End-to-end reachability testing | | Log view | `show logging` | View switch-generated events | | Syslog export | `logging ` | Remote log storage | ### **VII. Firmware and File Management** Keeping your switches **up-to-date, backed up, and ready for quick deployment** is crucial for operational stability. Aruba switches support various tools and protocols for managing firmware and configuration files efficiently. #### **1. Software Update** Aruba switches support firmware updates via: - **USB drive** - **TFTP / FTP / SFTP server** - **Aruba Central** ##### **CLI Example — TFTP Method:** ```shell copy tftp flash 192.168.1.10 /firmware.swi ``` | Parameter | Description | | --------------- | ------------------------------ | | `tftp` | Protocol used | | `flash` | Destination (internal storage) | | `192.168.1.10` | IP of the TFTP server | | `/firmware.swi` | Filename of the firmware | ##### **Reboot into new image (if needed):** ```shell boot system flash primary ``` ##### **Alternative Methods:** - Use **USB drive** plugged into the switch. - Use **Aruba Central** to automate upgrades across multiple sites. #### **2. Configuration Backup and Restore** Regularly backing up switch configs is critical — especially after large changes. ##### **Backup Config to TFTP:** ```shell copy running-config tftp 192.168.1.10 backup.cfg ``` ##### **Restore Config from TFTP:** ```shell copy tftp running-config 192.168.1.10 restore.cfg ``` You can also use **startup-config** instead of `running-config` to make persistent changes. ##### **Tip:** Back up configs: - **Before firmware upgrades** - **After major topology or VLAN changes** - On a **weekly schedule** in production #### **3. Zero Touch Provisioning (ZTP)** ZTP allows you to deploy a switch **without manual configuration** — it **automatically pulls its configuration and firmware** from a server when it boots. ##### **How ZTP Works:** 1. Switch boots with factory settings. 2. It sends a **DHCP request**. 3. DHCP server replies with: - IP address - **TFTP/HTTP/FTP server info** - Optional config/firmware file path 4. Switch downloads config and firmware automatically. 5. It reboots (if needed) and joins the network. ##### **ZTP Can Use:** - USB drive (plugged in with config file) - DHCP server with specific **Option 66/67** - Aruba Central ZTP engine (cloud-based) ##### **Best Practices for ZTP:** - Always test your config in a **lab switch** first. - Document the DHCP options used. - Use **Aruba Central** when deploying **multiple remote sites**. #### Summary of Firmware & File Management | Task | Command or Method | Notes | | ---------------------- | ----------------------------------------------- | ----------------------------------- | | Firmware update (TFTP) | `copy tftp flash ` | Can also use USB or Aruba Central | | Reboot into new image | `boot system flash primary` | Confirms active image | | Backup config | `copy running-config tftp ` | Automate this for disaster recovery | | Restore config | `copy tftp running-config ` | Useful for fast redeployments | | Enable ZTP | Use DHCP server with options, or USB or Central | Hands-free provisioning | ### **VIII. Best Practices for Setup and Validation** These best practices help ensure that your Aruba switch deployments are **secure, maintainable, and scalable**. These principles apply whether you’re configuring a single switch or automating a large enterprise rollout. #### **1. Use Structured Naming Conventions** ##### Why it matters: - Helps identify devices quickly in **CLI**, **logs**, **management platforms**. - Useful in **large networks**, where dozens or hundreds of devices exist. ##### Example Naming Standards: ```shell hostname SW-EDG-B1-FL1-01 ``` - SW: Switch - EDG: Edge layer - B1: Building 1 - FL1: Floor 1 - 01: Switch #1 #### **2. Assign Unique Management IPs** ##### Best Practice: - Use **dedicated VLANs** for management (e.g., VLAN 100). - Assign **static IPs** to switches in predictable subnets. ##### Example: - Core: `10.100.0.1` - Distribution: `10.100.1.1–10.100.1.50` - Access: `10.100.2.1–10.100.2.200` #### **3. Always Enable Secure Protocols (SSH over Telnet)** ##### Why: - **Telnet is unencrypted** and exposes login credentials. - SSH provides **encryption** and **secure key exchange**. ##### Commands: ```shell crypto key generate ssh ip ssh no telnet-server ``` #### **4. Use VLANs to Separate Traffic Types** Segment network traffic to improve: - **Security** (keep guests off the production network) - **Performance** (reduce unnecessary broadcasts) - **Troubleshooting** (each VLAN has a clear purpose) ##### Example VLAN Plan: | VLAN | Name | Purpose | | ---- | ----- | -------------------- | | 10 | USERS | Employee PCs | | 20 | VOICE | IP Phones | | 30 | GUEST | Guest Wi-Fi | | 100 | MGMT | Switch/AP management | #### **5. Back Up Configurations Regularly** ##### Recommended Strategy: - After **every major change** - On a **weekly basis** - Before **firmware upgrades** Use TFTP/SFTP or **automate with scripts/NetEdit**. #### **6. Test Inter-VLAN Routing and ACLs Before Going Live** ##### Why: - Misconfigured VLANs or ACLs can cause: - **Broken connectivity** - **Blocked critical services** (DNS, DHCP, VoIP) - Use **ping**, **traceroute**, and **show commands** to validate traffic flow. ##### Pre-deployment Validation Checklist: - Ping default gateways (SVIs) - Confirm LAGs are up and working - Confirm DHCP relay works per VLAN - Confirm ACLs allow required traffic (and block unauthorized) - Check spanning-tree and LACP status #### Summary of Best Practices | Best Practice | Why It Matters | | -------------------------- | --------------------------------------------------- | | Structured names | Easy to manage and identify devices | | Unique management IPs | Avoids IP conflicts, easier remote access | | SSH only, no Telnet | Ensures secure access | | VLAN segmentation | Improves performance, security, and organization | | Config backups | Disaster recovery and rollback safety | | Validate before going live | Prevents outages, improves confidence in deployment | --- # Tune, optimize, and upgrade Aruba solutions ### **I. Performance Optimization** Performance tuning ensures **critical applications like VoIP, video conferencing, and cloud services** get the bandwidth and latency guarantees they need — even under load. #### **1. QoS (Quality of Service)** QoS is used to **classify, prioritize, and manage traffic**, especially when bandwidth is limited. ##### **Supported Mechanisms:** | Layer | Type | Description | | ----- | ------------------- | --------------------------------------- | | L3 | **DSCP** (DiffServ) | Marks IP packets to indicate priority | | L2 | **802.1p (CoS)** | Marks Ethernet frames with class values | ##### **Command Examples:** ```shell qos trust dscp qos dscp 46 local-priority 6 ``` - `trust dscp`: Honors DSCP values from upstream devices. - `dscp 46`: Typically used for **EF (Expedited Forwarding)** → VoIP. - `local-priority`: Maps DSCP value to internal priority queue (0–7). ##### **Queue Tuning:** - Aruba switches have **multiple output queues**. - You can configure: - **Strict priority** (e.g., VoIP always goes first) - **Weighted fair queuing** (shared among priorities) #### **2. Storm Control** Storm control protects your network from being overwhelmed by: - **Broadcast storms** - **Multicast floods** - **Unknown unicast floods** ##### **Why It Matters:** - Misconfigured devices (like loops or rogue DHCP servers) can generate **high volumes of Layer 2 traffic**. - Without control, it can **slow or crash** an entire VLAN. ##### **Command Example:** ```shell interface 1/1/1 storm-control broadcast level 5 ``` - `level 5` means broadcast traffic is limited to **5% of port bandwidth**. #### **3. Jumbo Frames** ##### **What They Are:** - Ethernet frames larger than the standard **1500 bytes** — often up to **9000 bytes**. ##### **Why Use Them:** - Efficient for **storage traffic**, **data backups**, **VMotion**, or **high-throughput links**. - Reduces CPU usage per byte transferred. ##### **Enable Jumbo Frames:** ```shell jumbo ``` This command typically applies globally on ArubaOS switches or per VLAN on ArubaOS-CX. #### Summary of Performance Optimization | Feature | Purpose | Command Example | | ------------------ | ------------------------------- | ------------------------------------------------ | | **QoS (DSCP/CoS)** | Prioritize VoIP/video | `qos trust dscp`, `qos dscp 46 local-priority 6` | | **Storm Control** | Block excessive Layer 2 traffic | `storm-control broadcast level 5` | | **Jumbo Frames** | Improve throughput efficiency | `jumbo` | ### **II. High Availability and Redundancy** High availability (HA) ensures your network **stays operational** even if hardware, links, or components fail. Aruba offers several mechanisms to maintain **resilient, fault-tolerant environments** from the access layer to the core. #### **1. Link Aggregation (LAG / LACP)** Combines multiple physical links into a **single logical interface**, increasing: - **Bandwidth** - **Redundancy** - **Failover speed** ##### **Key Concepts:** | Term | Description | | -------------- | -------------------------------------------- | | LAG | Logical interface made of 2+ physical links | | LACP | Protocol to auto-negotiate link aggregation | | Load balancing | Traffic distributed by MAC, IP, or port hash | ##### **Command Example (ArubaOS-CX):** ```shell interface lag 1 mode active vlan 10,20 tagged ``` ```shell interface 1/1/1 lag 1 mode active ``` - **Mode active** = use LACP - Assign VLANs to the LAG interface, not to individual ports #### **2. Spanning Tree Protocol (STP / RSTP)** Prevents **Layer 2 loops** that could crash your network. Aruba uses **RSTP** by default — it's faster than traditional STP. ##### **Key Features of RSTP:** - Convergence in **<2 seconds** - Elects a **Root Bridge** (central control) - **Blocks redundant paths** unless a failure occurs ##### **Command Examples:** ```shell spanning-tree spanning-tree priority 4096 ``` - Use lower priority to **force a switch to become root**. - 4096 is **higher priority** than the default (32768). ##### **Use Case:** - Access switches form redundant loops to distribution/core. - RSTP blocks one link **until needed**. #### **3. VSF (Virtual Switching Framework)** Allows **stacking** of Aruba switches to behave as **a single logical switch**. ##### **Benefits:** - Single configuration file - **Redundant control planes** for failover - **Link aggregation across switches** ##### **Supported Models:** - **Aruba 2930F**, **2930M**, **3810**, **CX 6300** ##### **Use Case:** - Campus access or distribution layers needing: - Simplified management - Uplink redundancy #### **4. VSX (Virtual Switching Extension)** Advanced **core switch redundancy** for **ArubaOS-CX switches** like **CX 8320** and **8400**. ##### **How It Works:** - Two switches operate as **active-active peers** - Configurations **synchronize** between them - Supports: - **Hitless upgrades** - **MAC/ARP/route sync** ##### **Key Benefits:** | Feature | Benefit | | --------------------- | ------------------------------------------ | | Active-Active Routing | Both switches forward traffic | | Hitless Upgrade | No traffic interruption during upgrades | | Consistent Forwarding | Avoids STP blocking in dual-topology links | #### Summary of HA and Redundancy | Feature | Purpose | Aruba Models | Key Command Example | | -------- | -------------------------------------- | ---------------------- | ---------------------------------- | | **LAG** | Bandwidth + failover via link grouping | All Aruba switches | `lag 1`, `mode active` | | **RSTP** | Loop prevention + fast convergence | Default in ArubaOS | `spanning-tree priority 4096` | | **VSF** | Switch stacking | 2930F/M, 3810, CX 6300 | `vsf member`, `vsf enable` | | **VSX** | Redundant core with active-active | CX 8320/8400 | `vsx`, `peer`, `inter-switch-link` | ### **III. Software and Firmware Upgrade Procedures** Keeping your Aruba switches up to date is critical for: - **Bug fixes** - **Security patches** - **New features** This section covers **how to perform upgrades**, **validate them**, and **roll back if needed**. #### **1. Upgrade Methods** Aruba supports multiple firmware upgrade methods: ##### **a. CLI-Based Upgrade** Transfer firmware via: - **TFTP** - **SFTP / FTP** - **USB** ###### **Example (TFTP):** ```shell copy tftp flash 192.168.1.10 /CX_10_13_1001.swi ``` This uploads the firmware file to the switch’s internal flash. ##### **b. Aruba Central** - Use **cloud GUI** to: - Schedule upgrades - Push firmware to **many switches at once** - Validate version consistency ##### **c. NetEdit (for CX switches)** - NetEdit automates: - **Image distribution** - **Version checks** - **Rollback (if needed)** ##### **Standard Upgrade Steps:** 1. **Back up config** `copy running-config tftp 192.168.1.10 backup.cfg` 2. **Upload firmware file** Use CLI or Central/NetEdit 3. **Set boot image** ```shell boot system flash primary ``` 4. **Reboot** ```shell reload ``` #### **2. Validating Upgrade** After upgrading, always verify: ##### **a. Software Version** ```shell show version ``` - Confirms new firmware is running. ##### **b. Config State** ```shell show running-config show startup-config ``` - Ensure your startup-config wasn’t erased or altered. - Always compare **before vs after** settings. #### **3. Dual Image Support** Aruba switches support **two firmware slots**: - **Primary** and **Secondary** ##### **Why it matters:** - Load new image to the **non-active slot** - Test the new image - Roll back if anything fails ##### **Example Commands:** ```shell show image boot system flash secondary ``` #### Summary of Upgrade Procedures | Task | Command / Tool | Notes | | --------------- | -------------------------------------- | -------------------------------- | | Upload firmware | `copy tftp flash ` | TFTP, FTP, SFTP, or USB | | Set boot image | `boot system flash primary` | Activates image on reboot | | Verify version | `show version` | Confirms successful upgrade | | Backup config | `copy running-config tftp ` | Always before upgrade | | Use dual image | `boot system flash secondary` | Enables rollback if needed | | Aruba Central | GUI-based upgrade management | Best for multi-site environments | | NetEdit | Automates upgrades + validation | ArubaOS-CX only | ### **IV. Configuration Optimization** Optimizing your Aruba switch configuration helps ensure: - **Security** - **Efficiency** - **Ease of management** It reduces clutter, prevents misbehavior, and improves long-term maintenance. #### **1. Remove Unused Features** ##### **Why?** - Minimizes **attack surface** - Frees up **system resources** ##### **Common Features to Disable:** ```shell no lldp no telnet-server no http-server ``` | Feature | Why Disable It | | --------------- | --------------------------------------- | | **LLDP** | Unused in some environments; leaks info | | **Telnet** | Insecure, sends credentials unencrypted | | **HTTP server** | Use HTTPS instead for web management | Only keep features **you actively use**. ##### **Other Best Practices:** - Apply **ACLs to restrict access** - Disable **unused interfaces** with: ```shell interface 1/1/10 shutdown ``` #### **2. Clean Configs** Over time, configurations can collect: - **Unused VLANs** - **Old ACLs** - **Inactive interfaces** This increases **complexity and potential misconfigurations**. ##### **Steps to Clean:** 1. **List VLANs and check usage** ```shell show vlan ``` 2. **Remove unused VLANs** ```shell no vlan 300 ``` 3. **Check ACLs** ```shell show access-list ``` 4. **Remove orphaned rules** ```shell no ip access-list "OLD_ACL" ``` ##### **Disable Unused Ports:** ```shell interface range 1/1/20 to 1/1/24 shutdown ``` #### **3. Use Templates and Automation** ##### **Why it helps:** - Reduces human error - Ensures **consistency** - Speeds up deployment ##### **Tools You Can Use:** | Tool | Purpose | ArubaOS-CX Only? | | ------------ | --------------------------------------- | ---------------- | | **NetEdit** | Multi-switch config editing, validation | Y | | **REST API** | Programmatic push of config templates | Y | ##### **Example Use Case – Standard Access Template:** Apply to all edge switches: - VLANs 10, 20 - Uplink on 1/1/48 (tagged) - Default route - SSH only You can push this with NetEdit or an API pipeline. #### Summary of Config Optimization | Task | Action | Benefit | | ----------------------- | --------------------------------- | ---------------------------------- | | Disable unused features | `no lldp`, `no telnet`, `no http` | Reduce exposure and save resources | | Clean up VLANs & ACLs | `no vlan`, `no access-list` | Eliminate unused configs | | Shut unused interfaces | `interface range ... shutdown` | Prevent rogue device access | | Use templates | NetEdit / REST API | Enforce consistency at scale | ### **V. Monitoring and Analytics** Monitoring and analytics help network admins **identify problems before they escalate**, optimize traffic, and enforce **proactive troubleshooting**. Aruba provides both **on-device analytics** and **cloud-assisted AI monitoring**. #### **1. Network Analytics Processor (NAP)** Available on **ArubaOS-CX switches**, NAP is an **onboard analytics engine** that tracks: | Metric | Description | | ------------------------ | ------------------------------------------ | | **Interface traffic** | Real-time input/output per port | | **Top talkers** | Which devices are sending the most traffic | | **Application patterns** | Traffic types by protocol or port usage | ##### **Use Case:** - Troubleshooting congestion or slow links - Identifying misbehaving devices - Monitoring long-term bandwidth trends ##### **Command Example:** ```shell show system resource-utilization ``` Displays CPU, memory, buffer usage — key for detecting system stress. #### **2. Aruba Central AI Insights** In Aruba Central, AI Insights provide **intelligent monitoring** across switches, APs, and gateways. ##### **What It Detects Automatically:** | Insight Area | Examples | | --------------------- | ------------------------------------- | | **High CPU/memory** | Abnormal system usage | | **Flapping ports** | Ports going up/down repeatedly | | **Link instability** | Packet loss, jitter, slow convergence | | **Misconfigurations** | Duplicate IPs, VLAN mismatch | ##### **Why It’s Powerful:** - Combines **data and machine learning** - Gives **explanations**, not just alerts - Works across **multi-site networks** via cloud #### **3. Threshold Alerts** Set **CPU, memory, or interface thresholds** to trigger alerts (locally or via SNMP/syslog). ##### **Example Scenario:** Set an alert when: - **CPU exceeds 80%** - **Interface 1/1/48 hits 90% utilization** These can be configured in: - Aruba Central - CLI (on-device) - SNMP traps to NMS platforms (AirWave, SolarWinds) #### Summary of Monitoring and Analytics | Tool / Feature | What It Does | Platform | | ---------------------------------- | ----------------------------------------- | -------------------- | | **NAP** | Real-time analytics on CX switches | ArubaOS-CX | | `show system resource-utilization` | See system health (CPU, memory) | ArubaOS-CX CLI | | **Aruba Central AI** | Detects issues automatically | Aruba Central | | **Threshold alerts** | Notifies admin of high usage or anomalies | CLI / SNMP / Central | ### **VI. Time Synchronization** Proper timekeeping is **essential** in network operations. Accurate timestamps are required for: - **Log correlation** - **Security audits** - **Troubleshooting (event sequencing)** - **Certificate validity (HTTPS, 802.1X)** Aruba switches support **NTP (Network Time Protocol)** to stay synchronized with trusted time sources. #### **NTP (Network Time Protocol)** NTP ensures all network devices share the **same accurate time**, typically synchronized with **internet NTP servers** or an **internal time source** (e.g., firewall, Windows DC). ##### **Basic Configuration Example:** ```shell ntp server 192.168.1.1 ``` - Sets `192.168.1.1` as the NTP server (can be internal or external). - You can configure **multiple servers** for redundancy. ##### **View Current Time:** ```shell show time ``` - Displays the local switch time — should match your time zone and be consistent with the NTP server. ##### **Validate NTP Sync:** ```shell show ntp ``` - Confirms: - Whether NTP is synchronized - Offset/delay values - Status of configured time servers ##### **Best Practices:** - Use **local NTP servers** (on your firewall or AD server) for speed and security. - Avoid public NTP unless secured and trusted (e.g., `time.google.com`, `pool.ntp.org`). - Use **redundant NTP entries**: ```shell ntp server 192.168.1.1 ntp server 192.168.1.2 ``` #### Summary of Time Synchronization | Task | Command | Purpose | | --------------------- | ------------------------------- | ------------------------------- | | Configure NTP server | `ntp server ` | Enables time sync | | Show current time | `show time` | Displays system clock | | Validate sync | `show ntp` | Confirms NTP operational status | | Use redundant servers | Add multiple `ntp server` lines | Increases reliability | ### **VII. Logging and Debugging** Logging and monitoring are vital for **security audits**, **performance troubleshooting**, and **compliance**. Aruba switches provide several methods to **log activity** and **send data to external monitoring platforms**. #### **1. Syslog Configuration** Syslog allows switches to **send logs to a central syslog server** for long-term storage, searchability, and analysis. ##### **Why It’s Important:** - Helps track **who did what and when** - Required for **incident response** - Allows integration with **SIEM tools** (e.g., Splunk, QRadar) ##### **Enable Syslog:** ```shell logging 192.168.1.10 ``` - Sends logs to the syslog server at `192.168.1.10`. ##### **Adjust Log Levels (Optional):** ```shell logging facility local4 logging level info ``` | Level | Meaning | | -------- | --------------------------- | | debug | Most detailed (for testing) | | info | General information | | warning | Potential problems | | critical | Only major failures | ##### **Verify Syslog Status:** ```shell show logging ``` #### **2. SNMP Configuration** **SNMP (Simple Network Management Protocol)** is used for: - **Monitoring device health** - **Receiving traps/alerts** - **Integrating with NMS tools** (like Aruba AirWave, PRTG, SolarWinds) ##### **SNMP Versions:** | Version | Security | Description | | ------- | ----------------- | --------------------------- | | v1/v2c | Community string | Basic, insecure (plaintext) | | v3 | Auth + encryption | Secure, modern standard | ##### **Basic SNMPv2c Setup:** ```shell snmp-server community public ro ``` - `public`: Community string (like a password) - `ro`: Read-only access ##### **SNMPv3 Example (Secure):** ```shell snmpv3 enable snmpv3 user admin auth sha MySecretPass priv aes MyPrivKey ``` - `auth`: Enables authentication (SHA, MD5) - `priv`: Enables encryption (AES, DES) ##### **Trap Destinations:** Send alerts (like link down, high CPU) to a trap receiver: ```shell snmp-server host 192.168.1.20 version 2c public ``` #### Summary of Logging and SNMP | Task | Command Example | Purpose | | -------------------- | --------------------------------- | ------------------------------ | | Send logs to syslog | `logging 192.168.1.10` | Forward logs to central server | | Adjust log level | `logging level info` | Control verbosity of logs | | Enable SNMP v2 | `snmp-server community public ro` | Allow monitoring by NMS tools | | Enable SNMP v3 | `snmpv3 user admin auth sha ...` | Use secure SNMP | | Set SNMP trap target | `snmp-server host ` | Enable alerting for NMS | ### **VIII. Upgrading Best Practices** Whether you're upgrading a single switch or an entire network of Aruba devices, following structured best practices ensures **smooth, safe, and reliable upgrades** — minimizing the risk of downtime or data loss. #### **1. Always Test Upgrades in Lab/Test Environment First** - Use **non-production switches** to test: - Firmware behavior - Compatibility with existing config - New features or commands Especially important before major version jumps (e.g., CX 10.12 → 10.13). #### **2. Back Up Configuration and Software Image** ##### **Back Up Config:** ```shell copy running-config tftp 192.168.1.10 preupgrade.cfg ``` ##### **Back Up Image (if supported):** ```shell copy flash tftp 192.168.1.10 backup-image.swi ``` #### **3. Schedule Upgrades During Maintenance Windows** - Avoid business hours. - Notify affected users in advance. - Coordinate with network monitoring teams (if using Central, AirWave, SolarWinds). #### **4. Monitor Switch Post-Upgrade for Anomalies** Use: - `show version` → confirm new image is active - `show system resource-utilization` → check CPU/memory - `show logging` → detect errors or warnings ##### **Key Areas to Watch:** | Component | What to Monitor | | ----------------- | ------------------------------------- | | Interfaces | Any ports that failed to come back up | | LAGs / Trunks | Consistency and member state | | Routing protocols | OSPF/BGP neighbors re-establishing | | Services | SSH, SNMP, DHCP relay, etc. | #### **5. Use Rollback Mechanisms If Available** ##### Dual Image Support: Aruba switches support: - **Primary and secondary boot images** - Manual selection of image before reboot Always keep the **last known working firmware** in one slot for safe fallback. ##### Rollback Example: ```shell boot system flash secondary reload ``` #### Summary of Upgrade Best Practices | Best Practice | Action / Tool | Why It Matters | | ---------------------------- | ------------------------------------ | ------------------------------- | | Test in lab | Use spare/test switch | Prevent surprises in production | | Back up config/image | `copy running-config` + `copy flash` | Enables full recovery | | Schedule downtime | Plan off-hours with user notice | Avoid productivity loss | | Monitor after reboot | `show logging`, `show version` | Confirm health and stability | | Use dual images for rollback | `boot system flash secondary` | Fast recovery if upgrade fails | --- # Troubleshoot, repair, and replace Aruba solutions ### **I. Troubleshooting Methodology** Troubleshooting is more than guesswork — it's a **structured process** that helps you isolate and resolve problems logically, efficiently, and safely. #### **Structured Troubleshooting Steps** ##### **1. Identify the Problem** - **Observe symptoms:** - No connectivity? - Slow application performance? - Intermittent packet loss? - **Collect initial input** from: - User reports - Monitoring systems (e.g., Aruba Central, AirWave) - SNMP traps or syslog alerts ##### **2. Define the Scope** - Is the issue: - **Local** (1 device or port)? - **VLAN-wide** (entire subnet)? - **Global** (all switches)? - Helps prioritize and reduce diagnostic scope. ##### **3. Gather Information** Use tools like: - CLI commands: ```shell show interfaces show vlan show logging ``` - Ping/traceroute - Aruba Central AI Insights - Port statistics and counters ##### **4. Hypothesize and Test** - Form **possible root causes** - Test one at a time: - Replace cable → does the link restore? - Change VLAN assignment → does ping succeed? Avoid changing multiple things at once. ##### **5. Implement the Solution** - Apply configuration change or hardware fix. - Always validate **after applying** the solution. ##### **6. Document the Fix** - Update: - **Change logs** - **Trouble tickets** - **Knowledge base articles** This ensures future engineers can learn from the resolution. #### Summary of Troubleshooting Process | Step | Action | | ---------------- | ----------------------------------------- | | Identify | Look at symptoms and alerts | | Define Scope | Is it isolated or widespread? | | Gather Info | Use show commands, logs, Central insights | | Hypothesize/Test | Try fixes one-by-one | | Implement | Make config or physical change | | Document | Record the fix for future reference | ### **II. Common Network Issues and Fixes** This section provides **real-world examples** of issues you'll likely face in Aruba environments, and how to **diagnose and fix them** using Aruba CLI and tools like Central. #### **1. Interface Issues** ##### **Symptoms:** - Port shows **“down”** or **“flapping”** (going up/down repeatedly). - Connected device has **no link or intermittent loss**. ##### **Troubleshooting Steps:** 1. **Check physical layer:** - Try a **known-good cable**. - Inspect connectors and SFPs. 2. **Use command:** ```shell show interfaces show interface counters ``` Look for: - High CRCs (bad cable) - Down/down status 3. **Match speed/duplex:** - Ensure both ends agree (auto or manual). ```shell speed 1000 duplex full ``` #### **2. VLAN and Trunking Problems** ##### **Symptoms:** - Devices on the same VLAN **can’t communicate**. - Inter-VLAN traffic fails despite routing being enabled. ##### **Troubleshooting Steps:** 1. **Check VLAN membership:** ```shell show vlan ``` 2. **Confirm trunk ports:** - Are correct VLANs **tagged** or **untagged**? ```shell vlan 10 tagged 1/1/1 ``` 3. **Check native VLAN consistency:** - Both sides of trunk should match. #### **3. IP Routing Problems** ##### **Symptoms:** - Devices in different VLANs **can’t reach each other**. - Default gateway **not reachable** from clients. ##### **Troubleshooting Steps:** 1. **Verify routing is enabled:** ```shell ip routing ``` 2. **Check SVI status and IPs:** ```shell show interface vlan 10 ``` 3. **Validate routing table:** ```shell show ip route ``` Missing static routes or misconfigured SVIs are common causes. #### **4. LAG / LACP Mismatches** ##### **Symptoms:** - Aggregated link **doesn’t come up** - Packets drop on **one or both sides** ##### **Troubleshooting Steps:** 1. **Check LAG/LACP status:** ```shell show lag show lacp ``` 2. **Confirm both sides:** - Use **same mode** (active/passive) - Same VLANs tagged - All ports added correctly 3. **Match hashing method** (on both ends) #### **5. ACL and Security Blocks** ##### **Symptoms:** - Certain traffic is **unexpectedly dropped** (e.g., DNS or HTTP blocked). - ACLs seem applied, but **not working as expected**. ##### **Troubleshooting Steps:** 1. **View ACLs:** ```shell show access-list ``` 2. **Check interface direction:** - Inbound or outbound must match design. 3. **Validate wildcard mask logic:** - A common mistake is using subnet mask instead of wildcard. #### **6. DHCP Issues** ##### **Symptoms:** - Clients fail to get IP addresses. - DHCP renewals randomly fail. ##### **Troubleshooting Steps:** 1. **Check if the DHCP server is reachable:** ```shell ping 192.168.1.100 ``` 2. **Verify DHCP relay configuration:** ```shell interface vlan 10 ip helper-address 192.168.1.100 ``` 3. **Look for rogue DHCP detection alerts (Aruba Central)** #### Summary of Common Fixes | Problem Area | Key Commands | Common Fix | | -------------- | ----------------------------------- | --------------------------------------- | | Interface Down | `show interfaces`, check cable | Replace cable or fix speed/duplex | | VLAN Mismatch | `show vlan`, check tagging | Correct trunk settings and VLAN mapping | | Routing Broken | `ip routing`, `show ip route` | Enable routing, fix SVI IPs | | LAG Failure | `show lag`, `show lacp` | Align mode and VLANs | | ACL Blocking | `show access-list`, check direction | Adjust rules, direction, or mask logic | | DHCP Fails | `ip helper-address`, ping server | Confirm relay, check reachability | ### **III. Monitoring Tools and Commands** Effective troubleshooting depends on knowing how to **monitor system status in real time** and **analyze patterns over time**. Aruba provides a rich set of **CLI tools**, along with **cloud-based insights** in Aruba Central. #### **1. Real-Time Monitoring** These commands give immediate visibility into device and interface status: ##### **a. show interfaces** - Displays: - Physical status (up/down) - Speed/duplex - MAC address - Errors and packet counters ```shell show interfaces brief show interface 1/1/1 ``` ##### **b. show logging** - Displays **system messages**, including: - Link up/down events - ACL denies - Configuration changes - System warnings/errors ##### **c. show spanning-tree** - Helps verify loop prevention is working. - Shows: - Root bridge ID - Blocked ports - STP roles and states ##### **d. show system resource-utilization** (CX only) - View CPU, memory, buffer usage - Helpful when diagnosing: - Performance bottlenecks - Overloaded switches - Memory leaks #### **2. Ping and Traceroute** Use these for **Layer 3 connectivity testing**: ##### **ping** ```shell ping 192.168.1.1 ``` - Confirms basic reachability - Use with source IP if needed: ```shell ping 192.168.1.1 source vlan 10 ``` ##### **traceroute** ```shell traceroute 8.8.8.8 ``` - Tracks the path packets take - Identifies where routing or reachability fails #### **3. Packet Captures (CX Only)** ArubaOS-CX supports **port-level packet capture** with the `monitor capture` feature — very useful for: - Capturing DHCP, ARP, or OSPF exchanges - Diagnosing ACL or NAT issues - Examining malformed traffic ##### **Basic Workflow:** ```shell monitor capture test interface 1/1/1 monitor capture test start monitor capture test stop monitor capture test export tftp://192.168.1.10/test.pcap ``` File can be analyzed in Wireshark. #### **4. Historical Monitoring (CX)** ArubaOS-CX has a **state database** that stores historical info like: - Interface up/down history - CPU/memory usage over time - Error counters ##### **Command Example:** ```shell show event-history ``` Also accessible via **Aruba Central's timeline view**. #### Summary of Monitoring Tools | Tool / Command | What It Does | Notes | | ---------------------------------- | -------------------------------- | ------------------------------- | | `show interfaces` | Real-time port/link info | Check errors, speed, status | | `show logging` | View recent system messages | Useful after issues | | `show spanning-tree` | See loop prevention status | Detect misconfig in topology | | `ping`, `traceroute` | Verify L3 connectivity | End-to-end reachability test | | `monitor capture` (CX) | Capture packets on an interface | Save as .pcap for Wireshark | | `show system resource-utilization` | Check performance stats | Memory, CPU, buffer utilization | | `show event-history` | Historical logs/events (CX only) | CLI or Aruba Central GUI | ### **IV. Log Analysis** Analyzing logs is critical for identifying: - **Root causes of outages** - **Security events** - **Performance anomalies** Aruba switches allow both **local log review** and **remote log forwarding** for long-term correlation and compliance. #### **1. Syslog and Event Logs** ##### **a. Viewing Logs Locally** ```shell show logging ``` - Displays system messages such as: - Interface up/down - Authentication failures - Configuration changes - System warnings or critical errors ##### **b. Sending Logs to Remote Syslog Server** ```shell logging 192.168.1.10 ``` - Sends logs to a central server (e.g., SIEM, Splunk, or syslog-ng) ##### **Best Practices:** - Use **internal syslog server** for compliance/security tracking - In Aruba Central: - Enable **log export** under device settings - View logs with **search and filters** #### **2. Log Levels** Log levels help filter **how much information** is shown or sent. | Level | Severity | Use When… | | ------------ | ------------------------------ | --------------------------------- | | **debug** | Most detailed | For deep problem inspection | | **info** | General system operations | Daily use and baseline monitoring | | **warning** | Warnings or potential problems | When tuning configurations | | **critical** | Only major failures | In production to reduce log noise | ##### **Command Examples:** ```shell logging level info logging monitor debug ``` - The first sets the **default system log level**. - The second adjusts what’s shown **on your current terminal**. ##### **Tips for Efficient Log Use:** - Use filters in Aruba Central’s **event log viewer** - Search for: - `link` - `fail` - `auth` - `denied` - In CLI, use: ```shell show logging | include vlan show logging | begin 10:00:00 ``` #### Summary of Log Analysis | Task | Command or Tool | Purpose | | ------------------------ | --------------------------- | ----------------------------------- | | View local logs | `show logging` | Real-time system messages | | Send to remote syslog | `logging ` | For central alerting/audit trail | | Adjust verbosity | `logging level info/debug` | Tailor based on environment | | Filter CLI logs | `show logging | include ` | | Aruba Central log viewer | GUI-based search and export | Easier log correlation and analysis | ### **V. Recovery and Repair Operations** This section is all about **resilience**: when things go wrong — like forgotten passwords, corrupted configs, or failed upgrades — you need reliable recovery methods to restore service quickly and safely. #### **1. Password Recovery** If the admin password is lost, you can recover access by interrupting the boot process and resetting credentials. ##### **ArubaOS (Provision OS) Recovery:** 1. Connect via **console cable**. 2. **Reboot the switch**. 3. Interrupt the boot process by pressing any key. 4. Enter the **boot menu**. 5. Choose **password recovery** or **skip authentication**. 6. Once in the CLI, reset the password: ```shell user admin password plaintext newpassword write memory ``` ##### **ArubaOS-CX Recovery:** 1. Interrupt boot sequence to enter **maintenance shell**. 2. Mount the config partition. 3. Reset admin password using recovery tools. 4. Reboot and log in with new credentials. This process varies slightly by model — always consult HPE Aruba’s official guide for exact commands per platform. #### **2. Factory Reset** Restores the switch to **default state** — used for decommissioning or recovering from config corruption. ##### **ArubaOS Switches:** ```shell erase startup-config reload ``` ##### **ArubaOS-CX:** - CLI: ```shell erase startup-config ``` - Physical method: - Hold **reset button** for 10+ seconds. - Watch for **LED indicators** confirming reset. #### **3. Configuration Restore** Restore a previously saved config using TFTP, USB, or Aruba Central. ##### **CLI Restore Example:** ```shell copy tftp running-config 192.168.1.10 restore.cfg ``` - Applies the config live (non-persistent until saved). ```shell copy tftp startup-config 192.168.1.10 restore.cfg ``` - Applies config on next boot. #### **4. Software Rollback** Aruba switches support **dual firmware images** to allow safe rollback in case an upgrade fails. ##### **Workflow:** 1. Load known-good firmware into **secondary slot**. 2. If the new firmware causes issues: ```shell boot system flash secondary reload ``` Always verify current image with: ```shell show version ``` And compare: ```shell show image ``` #### Summary of Recovery and Repair | Task | Command / Method | Purpose | | ------------------ | -------------------------------------- | --------------------------- | | Password recovery | Boot menu or maintenance shell | Regain access after lockout | | Factory reset | `erase startup-config` or reset button | Clear all configs | | Restore config | `copy tftp running-config` | Recover known-good config | | Roll back firmware | `boot system flash secondary` | Undo failed upgrades | | Show image info | `show version`, `show image` | Confirm current/backup OS | ### **VI. Hardware Replacement** Even the best networks face occasional **hardware failures**. Aruba designs its switching products with **redundancy**, **hot-swap capability**, and **automated provisioning** to ensure replacements are **quick and non-disruptive**. #### **1. Hot-Swappable Components** Certain Aruba switches (especially modular models) support **live replacement** of key hardware elements. ##### **Examples of Hot-Swappable Parts:** | Component | Supported on... | Notes | | ------------------ | ------------------------------- | ------------------------------------ | | **Power supplies** | Aruba CX 6300, 8320, 8400 | Replace without shutting down switch | | **Fans** | Aruba 8400, 6300, 3810, 5400R | Swap while system is running | | **Line cards** | Aruba 8400 only (chassis-based) | Requires slot-level shutdown | ##### **Best Practices:** - Use **matching PSU wattage and airflow**. - Verify **LED status** before removing a part. - Always follow **electrostatic discharge precautions**. #### **2. RMA and Device Swap** When a full switch needs replacement: ##### **Pre-Replacement Steps:** 1. **Record serial number and model** 2. **Back up configuration**: ```shell copy running-config tftp 192.168.1.10 backup.cfg ``` 3. **Note port/VLAN mappings** and uplink info ##### **Post-Replacement Steps:** 1. Boot new switch 2. Restore config: ```shell copy tftp running-config 192.168.1.10 backup.cfg ``` 3. Validate: - `show version` - `show interfaces` - `show vlan` #### **3. ZTP for Replacement (Zero Touch Provisioning)** ZTP allows a **replacement switch to auto-configure** on first boot using DHCP and a predefined template. ##### **ZTP Workflow:** 1. Replacement switch boots 2. Sends **DHCP request** 3. DHCP server provides: - IP address - Option 66/67 with **TFTP/HTTP config location** 4. Switch downloads: - Config file - Optional firmware 5. Applies settings, reboots, and joins the network ##### **Requirements for ZTP to Work:** - DHCP scope includes: - Option 66 (server name or IP) - Option 67 (config file name) - The config file matches device **MAC address or hostname** - Pre-staged switch config/template (in Aruba Central or on local server) #### Summary of Hardware Replacement | Task | Tool or Action | Purpose | | ---------------------- | -------------------------------------- | -------------------------------- | | Replace PSU/fan live | Hot-swap on supported models | Avoids downtime | | RMA full switch | Backup/restore config | Preserves VLANs, ACLs, IPs | | Use ZTP for auto-setup | DHCP + config template | No manual config needed | | Validate after install | `show interfaces`, `show vlan`, `ping` | Ensure network returns to normal | ### **VII. Best Practices for Troubleshooting** These best practices ensure that when issues arise, you can troubleshoot **efficiently**, **accurately**, and **safely**, while preserving **network integrity and uptime**. #### **1. Always Start at Layer 1 (Physical)** ##### Why: - The majority of issues are due to **simple things** like: - Bad cables - Loose connections - Incorrect patching ##### What to Check: - Link lights (green = good) - Use `show interfaces` for link state - Reseat cables or transceivers - Try known-good cable and port *Never assume Layer 1 is fine — always verify it first.* #### **2. Use Consistent Naming and Documentation** ##### Why: - Makes identifying devices, ports, and VLANs easier - Reduces confusion during live incident response ##### Examples: - Hostnames: `SW-CORE-BLD1-FL2` - Interface descriptions: ```shell interface 1/1/24 description Uplink to CX-Core-01 ``` - Maintain updated **network diagrams** and **config snapshots** #### **3. Keep a Baseline Configuration** A known-good config file helps you: - Spot recent changes - Restore quickly if needed ##### Best Practices: - Save regular backups: ```shell copy running-config tftp 192.168.1.10 backup.cfg ``` - Store **versioned snapshots**: e.g., `AccessSW_2025-05-01.cfg` #### **4. Apply Change Control in Production** Never make changes on-the-fly in live environments without: - Logging the change - Notifying stakeholders - Scheduling maintenance windows (if applicable) ##### Recommended Practice: - Use a **ticketing system** (e.g., Jira, ServiceNow) - Document: - What was changed - Why it was changed - Expected impact - Rollback plan #### **5. Test Each Fix Individually** If you're troubleshooting a problem: - Avoid making **multiple changes at once** - Apply one fix → test → observe results ##### Why: - Easier to isolate what actually resolved the issue - Reduces chance of introducing **new problems** #### Summary of Troubleshooting Best Practices | Best Practice | What It Prevents / Enables | | ------------------------- | ---------------------------------------------- | | Start at Layer 1 | Avoid wasting time chasing higher-layer issues | | Use consistent naming | Improves clarity in logs, diagrams, CLI | | Keep baseline config | Enables rapid comparison or rollback | | Follow change control | Protects uptime and accountability | | Test one change at a time | Clear cause/effect, avoids compounding errors | --- # Manage, monitor, administer and operate Aruba solutions ### **I. User and Role Management** Proper user management is key for **access control**, **accountability**, and **network security**. #### **1. User Accounts and Roles** ##### **Creating Local Users:** On both ArubaOS and ArubaOS-CX, you can define local users with specific access levels. ```shell user admin password plaintext MySecurePass manager user audit password plaintext ReadOnly123 operator ``` | Role | Privileges | | ---------- | ---------------------------------- | | `manager` | Full read-write access | | `operator` | Read-only or limited config access | Use `operator` role for junior staff or monitoring tools. ##### **Best Practices:** - Avoid using a single shared admin account. - Enforce **unique usernames per admin** for traceability. - Document user roles and expiration (e.g., for contractors). #### **2. Secure Management Access** ##### **Enable SSH (recommended):** ```shell crypto key generate ssh ip ssh ``` ##### **Disable insecure protocols:** ```shell no telnet no http-server ``` ##### **Enable HTTPS if Web UI is used:** ```shell ip http secure-server ``` SSH and HTTPS encrypt your credentials and sessions. Telnet and HTTP **transmit in plaintext** and should be disabled on all production switches. #### Summary of User & Access Control | Task | Command Example | Purpose | | -------------------------- | ------------------------------------------- | ------------------------------- | | Create user | `user password plaintext role` | Role-based privilege assignment | | Enable SSH | `ip ssh`, `crypto key generate ssh` | Secure remote CLI | | Disable insecure protocols | `no telnet`, `no http-server` | Harden management plane | | Use unique usernames | Per-person accountability | Audit and access tracking | ### **II. Remote Management and Automation Tools** Aruba provides robust tools for **centralized management**, **bulk configuration**, and **network automation**, making large-scale operations efficient and scalable. #### **1. Aruba Central** Aruba Central is a **cloud-based NMS** (Network Management System) for Aruba wired and wireless environments. ##### **Core Functions:** | Feature | Description | | -------------------------------- | ------------------------------------------------------- | | **Switch Monitoring** | Real-time health, port status, traffic utilization | | **AI Insights** | Root-cause detection for flapping links, high CPU, etc. | | **Firmware & Config Management** | Schedule and push updates | | **Topology Mapping** | Auto-discovers device interconnections | | **Role-Based Access** | Custom admin roles and device-level privileges | ##### **Use Case:** - Multi-site deployments - MSPs managing customer environments - Auto-provisioning (ZTP) for new hardware #### **2. Aruba NetEdit (for CX Switches)** NetEdit is Aruba’s **automation and validation platform** for **ArubaOS-CX environments**. ##### **Key Use Cases:** | Function | Description | | ---------------------------- | ------------------------------------------------ | | **Batch config editing** | Make changes across many switches at once | | **Validation before commit** | Detect errors like duplicate IPs, broken syntax | | **Compliance auditing** | Check that devices follow baseline configuration | | **Version control** | Track and compare past config states | Ideal for **change control and rollback** in large environments. #### **3. REST APIs** All ArubaOS-CX switches support **RESTful APIs**, allowing programmable access to config and state data. ##### **Common Use Cases:** - **Automated provisioning** (via Python or Ansible) - **CI/CD pipelines** for network changes - **Real-time monitoring tools** that query device state ##### **API Access:** - ArubaOS-CX uses a **Swagger-based API explorer** - Access via HTTPS (port 443) - Auth required via token or session ##### **Simple Python Example:** ```python import requests requests.get("https://10.1.1.1/rest/v10.04/system/interfaces") ``` #### Summary of Management Tools | Tool | Best For | ArubaOS / ArubaOS-CX | | ----------------- | --------------------------------------------- | -------------------- | | **Aruba Central** | Cloud-based monitoring, AI troubleshooting | All Aruba switches | | **NetEdit** | Bulk config, validation, compliance (on-prem) | ArubaOS-CX only | | **REST API** | Automation, CI/CD, external integration | ArubaOS-CX only | ### **III. Configuration and File Management** Aruba switches use **two main configuration types**: active (running) and persistent (startup). Proper management of these files ensures stability, version control, and easy recovery. #### **1. Configuration Files** ##### **Types of Config:** | Config Type | Location | Purpose | | ---------------- | --------------- | ---------------------------------- | | `running-config` | In RAM | Live configuration (temporary) | | `startup-config` | In flash memory | Loaded on next reboot (persistent) | ##### **Commands to Save Changes:** - **ArubaOS (legacy):** ```shell write memory ``` - **ArubaOS-CX:** ```shell copy running-config startup-config ``` *If you reboot without saving, changes are lost.* #### **2. Backups and Restore** Regular configuration backups prevent data loss and reduce recovery time. ##### **Backup to TFTP:** ```shell copy startup-config tftp 192.168.1.10 backup.cfg ``` ##### **Restore from TFTP:** ```shell copy tftp startup-config 192.168.1.10 restore.cfg ``` - Use `running-config` if you want to apply changes immediately. #### **3. Configuration Versioning (CX Only)** ArubaOS-CX maintains **configuration checkpoints** that allow: - **Rollbacks** - **Auditing** - **Comparison between snapshots** ##### **Common Commands:** ```shell show checkpoint checkpoint name before_vlan_change rollback checkpoint before_vlan_change ``` Useful for **change control**, especially in production environments. #### Summary of Config and File Management | Task | Command Example | Notes | | ------------------ | -------------------------------------- | ---------------------------------- | | Save config | `write memory` or `copy run start` | Prevent loss on reboot | | Backup config | `copy startup-config tftp ` | Save externally | | Restore config | `copy tftp startup-config ` | Restore after failure | | Use CX checkpoints | `checkpoint`, `rollback checkpoint` | Rollback to previous config states | ### **IV. Monitoring and Health Checking** Day-to-day network operations rely heavily on **proactive monitoring**. Aruba switches provide both **CLI-based tools** and **SNMP/log integration** for real-time and historical visibility into device health. #### **1. Show Commands for Health Monitoring** Use these CLI commands regularly to verify performance and catch issues early. ##### **a. Interface Status** ```shell show interface brief ``` - Lists link status, speed, and errors per port ##### **b. VLAN Assignments** ```shell show vlan ``` - Confirms port-to-VLAN mappings - Essential for troubleshooting communication issues ##### **c. CPU & Memory Usage** ```shell show system resource-utilization ``` - Monitor: - CPU load - Memory usage - Buffer statistics - Helps detect: - Memory leaks - High-load conditions - DoS attacks ##### **d. Routing/OSPF Status** ```shell show ip route show ospf ``` - Verifies: - Routing tables - Dynamic protocol neighbors - Route sources #### **2. Logging and Syslog** ##### **Store logs locally or remotely:** ```shell logging 192.168.1.100 ``` - Sends syslog messages to a remote server ##### **Adjust log severity:** ```shell logging level informational ``` | Level | Use Case | | ---------- | ------------------------------------ | | `debug` | Detailed troubleshooting (temp only) | | `info` | General monitoring | | `critical` | Only major system issues | ##### **View logs:** ```shell show logging ``` - CLI view of recent events #### **3. SNMP Monitoring** SNMP allows external NMS tools to: - Poll for status - Receive alerts (traps) - Visualize performance ##### **Basic SNMPv2 Setup:** ```shell snmp-server community public ro snmp-server host 192.168.1.50 version 2c public ``` `ro` = read-only access. Use a **custom community string** (not “public”) in production. ##### **For secure environments — SNMPv3:** ```shell snmpv3 enable snmpv3 user netops auth sha AuthPass123 priv aes PrivPass123 ``` - Enables authentication and encryption #### Summary of Monitoring & Health Checking | Task | Command / Tool | Purpose | | --------------------- | ---------------------------------- | ---------------------------------------- | | Check port status | `show interface brief` | View real-time link/speed/errors | | View CPU/memory usage | `show system resource-utilization` | Detect performance bottlenecks | | View logs | `show logging`, `logging level` | See system events | | Configure syslog | `logging ` | Forward logs to SIEM or syslog server | | Enable SNMP | `snmp-server` commands | Integrate with NMS tools (Central, etc.) | ### **V. Time and Event Synchronization** Consistent timekeeping and event correlation are essential for **accurate logging**, **security auditing**, and **event-driven automation**. Aruba switches support **NTP for clock sync** and **event-handlers for intelligent reactions**. #### **1. NTP Configuration** NTP (Network Time Protocol) keeps the switch’s clock synchronized with a central time source — critical for: - Aligning log entries across devices - Authenticating certificates - Tracking security events accurately ##### **Configure NTP Server:** ```shell ntp server 192.168.0.1 ``` - Server can be: - A local Windows domain controller - A firewall - An external server (e.g., `time.google.com`) ##### **Verify Time Settings:** ```shell show time show ntp ``` | Command | Purpose | | ----------- | ------------------------------------- | | `show time` | Displays system time | | `show ntp` | Shows NTP sync status and server info | ##### **Best Practices:** - Use **redundant NTP servers** - Avoid relying on public servers in secured networks - Always verify sync after power loss or firmware upgrade #### **2. Event Tracking (ArubaOS-CX Only)** **Event-handlers** allow CX switches to **automatically respond** to certain system events. ##### **Use Cases:** - Interface down → send alert via syslog - CPU spike → disable non-critical ports - Failed login attempt → log to external SIEM ##### **Example: Interface Down Alert** ```shell event-handler port-down event interface-down action syslog "ALERT: Interface went down" ``` ##### **Benefits:** - Automates incident notification - Reduces mean time to resolution (MTTR) - Enhances integration with monitoring platforms #### Summary of Time & Event Sync | Task | Command Example | Purpose | | ------------------------- | --------------------------------------- | ------------------------------------- | | Set NTP server | `ntp server 192.168.0.1` | Clock synchronization | | View time/sync status | `show time`, `show ntp` | Verify accuracy | | Define event handler (CX) | `event-handler`, `event interface-down` | Automate reactions to critical events | | Use syslog + NTP together | `logging`, `ntp` | Align event timing across logs | ### **VI. Port and Access Management** Day-to-day switch operation includes controlling **which devices can connect**, **when**, and **how**. Aruba switches offer powerful options for port-level control, authentication, and security enforcement. #### **1. Port Status Control** Control port availability to: - Prevent unauthorized access - Disable unused ports - Manually bring up downed interfaces ##### **Commands:** - **Disable a port:** ```shell interface 1/1/10 shutdown ``` - **Enable a port:** ```shell interface 1/1/10 no shutdown ``` - **Add a description:** ```shell description Connected to Finance-Printer ``` #### **2. Port Security** Restricts which MAC addresses can use a specific port — a key defense against: - Unauthorized devices - MAC flooding attacks ##### **Example:** ```shell interface 1/1/5 port-security mac-address sticky port-security max-mac-count 1 ``` - `mac-address sticky`: Learns and stores the first MAC that connects - Limits that port to **one device** #### **3. Authentication Methods** Aruba supports **user/device authentication** through ClearPass or other RADIUS servers. ##### **a. MAC Authentication:** - Used for non-interactive devices (printers, phones, IoT) - Switch sends device MAC address to RADIUS ##### **b. 802.1X Authentication:** - Used for user-based access (laptops, desktops) - Requires: - Supplicant on client device - Authenticator on the switch - RADIUS server (e.g., ClearPass) ##### **Configuration Example (802.1X):** ```shell aaa port-access authenticator interface 1/1/2 aaa port-access authenticator aaa port-access enable ``` #### **4. Dynamic VLAN Assignment (Guest/Contractor Access)** Via ClearPass, authenticated users can be assigned to different VLANs based on: - User group - Time of day - Device type This enables **automated role-based segmentation**. #### Summary of Port & Access Management | Task | Command / Feature | Purpose | | ------------------- | ------------------------------------- | --------------------------------------- | | Disable/enable port | `shutdown`, `no shutdown` | Control physical connectivity | | Limit MACs per port | `port-security`, `mac-address sticky` | Prevent unauthorized device connections | | Enable 802.1X | `aaa port-access authenticator` | Authenticate users via RADIUS | | MAC authentication | Integrated with ClearPass | Identify non-user devices | | Dynamic VLANs | Assigned by ClearPass policies | Segregate traffic by user/device type | ### **VII. Software and Image Operations** Managing software images properly ensures **safe upgrades**, **firmware consistency**, and the ability to **quickly roll back** in case of failures. Aruba switches (especially ArubaOS-CX) provide robust image handling features. #### **1. Upgrade Operations** You can upgrade Aruba switch firmware using **TFTP, SFTP, USB**, or through **Aruba Central**. ##### **Example – TFTP Upgrade:** ```shell copy tftp flash 192.168.1.10 CX_10_13_1010.swi ``` - `192.168.1.10` is your TFTP server - File will be uploaded to **flash memory** ##### **Verify Current Version:** ```shell show version ``` - Shows: - Current running image - Platform and OS version - Booted partition (primary/secondary ##### **Reboot into New Image:** ```shell boot system flash primary reload ``` This boots into the **primary image** (if it was the upgraded one). #### **2. Flash and Boot Management** Aruba switches support **dual image slots**: primary and secondary. This allows for **rollback protection**. ##### **Benefits:** - Upload new firmware to the **inactive slot** - Test the image by manually booting into it - Roll back easily if something breaks ##### **View Image Info:** ```shell show image ``` ##### **Set Boot Image:** ```shell boot system flash secondary ``` #### Summary of Software and Image Ops | Task | Command or Action | Purpose | | ------------------------- | ---------------------------------- | ---------------------------------- | | Upgrade firmware (TFTP) | `copy tftp flash ` | Upload new OS image to switch | | View current version | `show version` | Confirm OS version and slot | | Boot into image | `boot system flash ` | | Use dual image protection | Keep last-known-good in one slot | Roll back if the new version fails | ### **VIII. Daily Admin Best Practices** Daily operations should prioritize **security**, **stability**, and **recoverability**. Following these habits helps prevent outages, reduces troubleshooting time, and enforces good governance in network administration. #### **1. Back Up Configurations Weekly or Before Changes** ##### **Why:** - Prevents loss of config due to errors, reboots, or upgrades. - Ensures rapid recovery from hardware failure or misconfiguration. ##### **Best Practice:** - Use a naming convention with timestamps: ```shell copy startup-config tftp 192.168.1.10 accesssw-2025-05-22.cfg ``` #### **2. Review Logs Daily or Use Central Alerts** ##### **Why:** - Detects early signs of failure or misbehavior (e.g., port flapping, CPU spikes). - Identifies unauthorized access or rogue devices. ##### **Options:** - CLI: ```shell show logging ``` - Aruba Central: - Use **AI Insights**, **email alerts**, and **automated notifications** #### **3. Use Role-Based Access and Disable Unused Protocols** ##### **Secure Access Practices:** - Assign each admin their own **user account**: ```shell user alice password plaintext S3cur3! manager ``` - Disable unused or insecure services: ```shell no telnet no http-server ``` - Enforce **SSH/HTTPS-only** for remote sessions #### **4. Schedule Firmware Upgrades During Maintenance Windows** ##### **Why:** - Avoids interrupting users during business hours. - Allows for proper rollback if issues occur. ##### **Best Practice:** - Stage firmware on secondary slot - Plan upgrade windows with proper change control - Verify post-upgrade status with: ```shell show version show system resource-utilization ``` #### **5. Monitor Port Errors, CPU, and Memory** - Check **interface counters** regularly: ```shell show interface 1/1/24 ``` - Monitor for: - High CRC errors - Late collisions - Buffer drops - Track system health with: ```shell show system resource-utilization ``` #### Summary of Daily Best Practices | Best Practice | Command / Tool Example | Why It Matters | | ------------------------------ | ----------------------------------------------------- | ---------------------------------------- | | Back up configs weekly | `copy startup-config tftp ...` | Fast recovery from config loss | | Monitor logs daily | `show logging` / Central alerts | Detect issues before outages | | Use role-based access | `user role ` | | Disable unused protocols | `no telnet`, `no http-server` | Minimize attack surface | | Schedule firmware upgrades | `boot system flash secondary`, `reload` | Safe change control with rollback option | | Monitor system and port health | `show interfaces`, `show system resource-utilization` | Proactive performance management | --- # Identify, describe, and apply foundational networking architectures and technologies (Additional Content) ### **1. OSPF Neighbor States (for Convergence Troubleshooting)** Understanding OSPF (Open Shortest Path First) neighbor states is **crucial** for diagnosing routing issues, especially in convergence problems or when links don’t come up as expected. #### **Key OSPF Neighbor States:** - **DOWN**: No Hello packets received; neighbor is not detected. - **INIT**: Hello received, but the neighbor’s ID is not listed in the Hello packet — unidirectional communication. - **2-WAY**: Bidirectional Hello packets confirmed; adjacency will form only on multi-access links like Ethernet. - **EXSTART**: Routers negotiate who is the master/slave for DBD (Database Description) exchange. - **EXCHANGE**: Routers exchange DBD packets with LSAs summaries. - **LOADING**: Routers request any missing LSAs. - **FULL**: All LSAs exchanged, **full adjacency established** — **required for proper routing**. ##### **Why it Matters:** - If a neighbor is stuck in **EXSTART** or **EXCHANGE**, there may be: - MTU mismatch - Authentication mismatch - Unidirectional link issues - Only **FULL** state allows full OSPF route exchange and convergence. ##### **Command to Check State:** ```shell show ospf neighbor ``` ### **2. IPv6 Subnetting and NDP (Neighbor Discovery Protocol)** As more enterprises deploy dual-stack or IPv6-only networks, candidates should understand **IPv6 address planning** and **device discovery protocols**. #### **IPv6 Subnetting Overview:** - IPv6 addresses use **128-bit** structure. - Common subnet sizes: `/64` (default for LANs), `/48` (site allocation). - **Subnetting** is done by borrowing bits beyond the **prefix length** (e.g., from `/48` to `/64` gives 65,536 subnets). ##### **Example:** Given: ``` 2001:db8:1000::/48 ``` You can create: ``` 2001:db8:1000:0001::/64 2001:db8:1000:0002::/64 ... ``` #### **Neighbor Discovery Protocol (NDP):** NDP replaces ARP in IPv6 and provides the following: - **Router Discovery** – Hosts find routers automatically. - **Prefix Discovery** – Determines on-link prefixes. - **Address Autoconfiguration** – SLAAC. - **Neighbor Unreachability Detection** - **Duplicate Address Detection** ##### **NDP-Related Commands:** ```shell show ipv6 neighbors ``` ### **3. Troubleshooting Module (Ping/Traceroute Failures, MAC Table)** To align with “troubleshoot” exam objectives, build a **standalone diagnostic module** focusing on common tools and output interpretation. #### **1. Diagnosing Ping/Traceroute Failures** - **Ping fails**: Check for: - IP reachability - Gateway issues - ACLs blocking ICMP - DNS misresolution (if pinging hostname) ```shell ping 192.168.1.1 ping 8.8.8.8 source vlan 10 ``` - **Traceroute reveals**: - Routing loops - Blackhole hops (no response) - Asymmetric routing ```shell traceroute 8.8.8.8 ``` #### **2. MAC Address Table Inspection** Used to confirm whether a switch has **learned the correct MAC** on the correct port. ```shell show mac-address-table ``` Key output fields: - **MAC Address** - **VLAN** - **Port** - **Type (dynamic/static)** ##### **Why it Matters:** - Useful when devices can't reach each other on L2. - Helps detect: - Wrong VLAN membership - Loop or duplicate MAC - Broken links not forwarding traffic --- # Identify, describe, and differentiate the functions and features of Aruba products and solutions (Additional Content) ### **1. ArubaOS-CX Web UI Overview** The ArubaOS-CX Web Interface provides a **GUI-based management portal** for CX switches, offering a modern and responsive alternative to CLI. #### **Key Web UI Features:** - **Dashboard Overview** - Displays system health (CPU, memory, temperature) - Interface status and traffic graphs - Device uptime and firmware version - **Interface Configuration** - Enable/disable ports, set speed/duplex - Assign VLANs or trunk modes - View real-time counters - **VLAN and Layer 3 Features** - Create/assign VLANs - Configure IP interfaces (SVIs) - Static routing setup - **Monitoring Tools** - Live log viewer (equivalent of `show logging`) - Interface traffic history - Access to event-handler status (CX only) - **Management** - Firmware image selection and upgrades - Backup/restore config - Role-based access management ##### **Why This Matters for the Exam:** Many entry-level and mid-tier questions may ask about **management options** available on ArubaOS-CX, and Web UI is one of them alongside CLI and REST API. ### **2. Zero Touch Provisioning (ZTP) Process Flow** ZTP allows Aruba switches to be **provisioned automatically** upon first boot — ideal for scaling deployment without manual intervention. #### **Typical ZTP Flow (Step-by-Step):** 1. **Switch boots** with factory config 2. Sends **DHCP Discover** 3. DHCP server replies with: - IP address - Option 66: TFTP/HTTP server IP - Option 67: File name (config or script) 4. Switch downloads: - Startup configuration - Optional firmware image 5. Applies config and reboots (if required) 6. Registers with **Aruba Central** (if pre-provisioned) ##### **What ZTP Enables:** - Remote, hands-free switch setup - Consistent provisioning via Central or NetEdit - Ideal for distributed sites (e.g., retail, campus branches) ##### **Optional Addition for Visual Learners:** While a diagram isn’t shown here (as per instruction), students are encouraged to sketch a **simple line flow** from “switch boot” → “DHCP” → “config download” → “network join” to visualize the automation path. ### **3. Interaction Between Aruba Central and Instant APs** To make this section more **comprehensive and exam-relevant**, candidates should understand how **Aruba Central manages Instant APs (IAPs) and switches together**. #### **Central’s Role in Unifying AP & Switch Policy:** - **Groups & Templates**: - Devices are organized into **groups** (e.g., Branch, HQ) - Each group can apply: - **Global templates** (CLI-style config snippets) - **UI-based policies** (WLAN, VLANs, ACLs) - **Instant AP Management:** - Configure SSIDs, firewall rules, and radio profiles - Monitor client health and roaming - Apply **WLAN roles** and **band steering** - **Switch Management:** - Assign VLANs to uplinks - Control PoE ports for APs - Deploy ACLs and QoS policies - Sync time, syslog, and SNMP from Central templates - **Unified Monitoring:** - Both APs and switches appear on the same **topology map** - Cross-device AI Insights (e.g., detect if switch config is blocking AP registration) ##### **Why This Is Important:** Aruba Central isn’t just a GUI — it's a **central policy controller**. The exam may test how **switches and APs interact as one system** under Central’s management, not as isolated nodes. --- # Install, configure, set up, and validate Aruba solutions (Additional Content) ### **1. Time Synchronization (NTP Configuration)** While the provided commands are technically correct, several **critical contextual factors** should be clarified for exam-readiness: #### **Additional Key Points to Include:** - **Time Zone Configuration** (Often Missed in Exams): ```shell clock timezone PST -8 ``` Ensures logs and scheduled events match local operational context. - **NTP Redundancy**: ```shell ntp server 192.168.1.101 ntp server 192.168.1.102 ``` Always configure **multiple NTP sources** to protect against single-point-of-failure. - **Verification Commands**: ```shell show time show ntp associations show ntp ``` These verify not just that NTP is configured but that **sync status**, **offset**, and **peer reachability** are healthy. ##### **Why This Is Important for Exams:** Questions may focus on **how to detect NTP failure or misalignment**, not just on enabling the feature. ### **2. SNMP Configuration** The basic SNMP setup is covered, but there are **additional details critical for secure and exam-ready configuration**. #### **Supplementary Concepts:** - **Avoid Default Community Strings**: Never use `public` or `private` in production. Use randomized strings like: ```shell snmp-server community N3tw0rkMon1t0r ro ``` - **SNMPv3 Support (Recommended for Secure Networks):** ```shell snmpv3 enable snmpv3 user netops auth sha AuthPass123 priv aes PrivPass123 ``` - **Trap Destination Configuration**: ```shell snmp-server host 192.168.1.50 version 2c N3tw0rkMon1t0r ``` ##### **Security Considerations:** - Use **read-only (ro)** for monitoring platforms. - Use **SNMPv3** for environments requiring encrypted authentication and payloads. - Set **contact/location fields** to match operational documentation for audit compliance. ### **3. Loop Protection** The content is technically accurate but can benefit from **clarifying the role of spanning tree enhancements** and **clarifying command behaviors**. #### **Expand With These Points:** - **BPDU Guard (interface-level)** – Stops rogue switches: ```shell spanning-tree bpdu-protection ``` - **Loop Protection Timer** (ArubaOS): - Automatically disables a port if BPDUs are not received within the timeout. ```shell loop-protect interval 5 ``` - **Recovery Behavior:** - Once a loop condition clears, some platforms **auto-reenable** the port; others require **manual intervention**. ##### **Important for Exams:** Expect a question like: *A port is continuously going into a disabled state. What could cause this behavior with loop protection enabled?* ### **4. Port Security** The current explanation is correct. Here’s how to strengthen it for **edge-case handling** and exam-level comprehension. #### **Add the Following Details:** - **Sticky MAC Learning**: ```shell port-security mac-address sticky ``` Learns the first MAC addresses dynamically and writes them into the running config. - **Violation Actions**: - `shutdown`: Disables the port entirely. - `restrict`: Drops packets and logs. - `protect`: Silently drops violating traffic. - **Best Practice**: Apply port security only on **access ports** connecting to user devices, not uplinks. ### **5. Firmware Management** This section is solid. However, **clarifying firmware slot logic** and **adding rollback strategy** enhances exam readiness. #### **Key Enhancements:** - **Dual Firmware Slots**: Aruba switches maintain `primary` and `secondary` firmware images: ```shell show image ``` - **Safe Upgrade Strategy**: Upload new firmware to **inactive slot**, test, then switch boot image. - **Rollback Plan**: If an upgrade fails: ```shell boot system flash secondary reload ``` - **Don’t Forget Config Backup**: ```shell copy running-config tftp 192.168.1.10 before-upgrade.cfg ``` ##### **Exam Tip:** You may be asked: *“What is the safest way to upgrade firmware while allowing rollback if a bug is discovered?”* --- # Tune, optimize, and upgrade Aruba solutions (Additional Content) ### **I. DevOps Integration and Automation with ArubaOS-CX** ArubaOS-CX is designed with **automation-first principles**, making it essential for candidates to understand **programmable network capabilities**. #### **1. REST API Operations on ArubaOS-CX** ArubaOS-CX offers a **native REST API** for all configuration and state operations. - **Enable API Access**: - ArubaOS-CX REST API is enabled by default over HTTPS (port 443). - Use basic auth or API tokens. - **Sample REST GET Request** (with `curl`): ```bash curl -k -u admin:password https://10.1.1.1/rest/v10.04/system ``` #### **2. Python Script Example (Using Requests Library)** A simple script to retrieve interface status: ```python import requests url = "https://10.1.1.1/rest/v10.04/system/interfaces" headers = {"Accept": "application/json"} response = requests.get(url, auth=("admin", "password"), verify=False) print(response.json()) ``` - This script demonstrates **programmatic polling**, which is common in **CI/CD environments**. #### **3. Using Postman for API Testing** Postman allows GUI-based testing of ArubaOS-CX REST APIs: - **Steps**: - Set URL: `https:///rest/v10.04/system` - Use Basic Auth or Token - Send GET or PUT requests - View JSON responses and test behavior before scripting #### **4. YAML/JSON Configuration Push** Configuration blocks can be **structured in YAML or JSON**, then pushed via API: - **Example (Partial JSON for VLAN creation)**: ```json { "vlan_id": 20, "name": "Guest", "admin": "up" } ``` - This can be integrated with: - **Jenkins pipelines** - **Ansible playbooks** - **Git-based change management** #### **Why It Matters for Exams and Real Work:** - Exam scenarios may ask: *“How would you automate VLAN provisioning across 20 CX switches?”* - Real-world environments expect **infrastructure-as-code**. ### **II. Post-Upgrade Verification for HA and Core Services** It's not enough to upgrade firmware — validating **critical operational states** after the upgrade is essential to avoid silent failures. #### **1. LAG / LACP Status Validation** After a reboot or upgrade, verify that **link aggregation groups** are healthy: ```shell show lacp show lag brief ``` - Ensure: - All members are active - No mismatched hashing methods - Correct VLAN tagging #### **2. OSPF Neighbor and Route Validation** After upgrading routing-enabled switches, check for: ```shell show ospf neighbor ``` - Neighbors in FULL state - No flapping or retransmissions And verify routing table entries: ```shell show ip route ``` - Dynamic OSPF entries should be present - Next-hops must be reachable #### **3. Access Control List (ACL) State** Upgrades can sometimes **disrupt ACL bindings** or parsing. Check: ```shell show access-list interface 1/1/10 ``` - Ensure the ACL is still applied (in or out) - Check hit counters are incrementing (indicates match) #### **Best Practices for Upgrade Validation Summary:** | Component | Command | What to Look For | | --- | --- | --- | | LAG/LACP | `show lacp` | All links active, no mismatches | | Routing | `show ospf neighbor` | FULL state with peers | | ACLs | `show access-list interface` | ACL is still bound and functioning | --- # Troubleshoot, repair, and replace Aruba solutions (Additional Content) ### **I. Add a Common Troubleshooting Logic Path (Diagram-Oriented Thinking)** To complement the command list already provided, it’s important to emphasize **logical, layered problem analysis**. A visual chain of logic helps candidates **understand the correct sequence** in identifying root causes. #### **1. Sample Troubleshooting Flow for VLAN Communication Failure** ``` Symptom: Hosts in the same VLAN cannot communicate ↓ 1. Check physical link status (show interfaces) ↓ 2. Verify trunk port tagging (show vlan, show interface ) ↓ 3. Ensure VLAN exists and is active (show vlan brief) ↓ 4. Check ACL bindings (show access-list interface) ↓ 5. Inspect SVI status and IP (show interface vlan ) ↓ 6. Confirm routing table entries (show ip route) ↓ 7. Ping between gateways or hosts (ping, traceroute) ``` #### **2. Sample Flow for DHCP Failure (Client Can't Get IP Address)** ``` Symptom: Client is stuck in DHCP DISCOVER state ↓ 1. Confirm client is on correct VLAN (show mac-address) ↓ 2. Check if DHCP helper-address is configured (show run interface vlan ) ↓ 3. Verify DHCP server reachability (ping ) ↓ 4. Check ACLs blocking UDP 67/68 (show access-list) ↓ 5. Look for rogue DHCP servers (Aruba Central → DHCP rogue alerts) ↓ 6. Confirm no duplicate IPs (show ip arp, show logging) ``` These logic trees help candidates visualize how **a single symptom can cascade** across different OSI layers, speeding up root cause analysis. ### **II. Include Sample Command Output for Pattern Recognition** Reading **actual command output** helps learners **translate theory into action**. Sample output enables candidates to understand **what “normal” looks like**, and recognize anomalies. #### **1. Sample Output: `show logging`** ``` May 25 09:32:10 switch01 %IF-5-UPDOWN: Interface 1/1/24 changed state to down May 25 09:32:11 switch01 %DHCP-4-RELAY_FAIL: DHCP relay to 192.168.1.100 failed: Unreachable May 25 09:33:02 switch01 %SEC-6-PORT_SECURITY: MAC violation on port 1/1/5 ``` **Troubleshooting Tip:** Use `| include` and `| begin` to filter logs: ```shell show logging | include DHCP show logging | begin May 25 ``` #### **2. Sample Output: `show lag`** ``` LAG ID: 1 Type: dynamic (LACP) Port Members: 1/1/1(active), 1/1/2(active) Status: up Load Balance: src-dst-ip ``` **Key Indicators of Problems:** - Ports marked **"inactive"** - Mismatched **LAG mode** - One port up, another down #### **3. Sample Output: `show ip route`** ``` Destination Gateway VLAN Type 0.0.0.0/0 192.168.1.1 1 static 10.1.0.0/16 10.1.1.1 10 ospf 192.168.1.0/24 Direct 1 connected ``` **Troubleshooting Tip:** - If **default route (0.0.0.0/0)** is missing → internet won’t work - If OSPF routes are gone after upgrade → run `show ospf neighbor` --- # Manage, monitor, administer and operate Aruba solutions (Additional Content) ### **I. User Access and Session Auditing** #### **View Current Logged-In Users** ```shell show users ``` - Displays all active CLI/SSH sessions on the device. - Useful for **auditing**: checking for **unauthorized access**, stale sessions, or troubleshooting login issues. - Especially important in multi-admin environments. ### **II. Remote Management and Automation Enhancements** #### **1. REST API Authentication via Token** When using ArubaOS-CX REST APIs, it is strongly recommended to use **token-based authentication** rather than basic (plaintext) credentials. ##### **Example REST Login Request:** ```http POST /rest/v10.04/login HTTP/1.1 Host: Content-Type: application/json { "username": "admin", "password": "MySecret" } ``` - On success, the switch returns a session **token**. - Subsequent API calls must include this token in the `Cookie` or `X-Auth-Token` header. #### **2. Aruba NetEdit – Scheduled Configuration Backups** - While NetEdit does not use CLI commands to back up configurations, it **supports scheduled snapshots**. - This is ideal for **compliance, change control, and disaster recovery**. ### **III. Configuration Change Management** #### **Compare Configuration Checkpoints** ```shell show checkpoint diff ``` - Displays **line-by-line differences** between two saved configurations. - Crucial for auditing what was changed before/after a rollout or upgrade. ### **IV. Health Monitoring via Central and Local Tools** #### **SNMP Trap and Event History in Aruba Central** - Aruba Central offers a GUI-based **trap viewer** and **alert dashboard**. - You can filter events like: - **Interface flapping** - **High CPU utilization** - **Authentication failures** Although not CLI-based, this is **critical for operations teams** monitoring multiple sites. ### **V. Time and Event Synchronization** #### **1. Redundant NTP Configuration** ```shell ntp server 192.168.0.1 ntp server 192.168.0.2 ``` - Configure at least **two** NTP sources to avoid clock drift. - Ensures consistency across logs, alerts, and certificate validity. #### **2. Event-Handler Automation Extensions** Use **event-handler** not only for logging but to **trigger actions** such as: - Sending **SNMP traps** - Executing a **webhook** (HTTP POST to external tool) - Initiating a **custom script** (advanced automation) Example: ```shell event-handler uplink-loss event interface-down action snmp-trap "uplink failed" ``` ### **VI. Access Control and Authentication Troubleshooting** #### **Show 802.1X or MAC Authenticated Clients** ```shell show port-access clients ``` - Lists **authenticated devices**, their **MAC addresses**, **VLAN assignments**, and **roles**. - Helps verify whether clients were authenticated and provisioned as expected. - Useful in environments using **ClearPass** or similar RADIUS backends. ### **VII. Software and Flash Operations** #### **1. Verify Available Flash Memory** ```shell dir ``` - Ensures there is **enough space for firmware uploads** or config files. - Avoid firmware upgrade failures due to **insufficient flash**. #### **2. Validate Boot Image Configuration** ```shell show boot ``` - Confirms which image (primary or secondary) is **configured for the next boot**. - Should be verified **before reloading** to avoid booting into an old or corrupted image. ### **VIII. Admin Scripting and Automation** #### **Configuration Backup Automation Example (Linux Script)** Using shell scripts or Python, create automated tasks to **back up configs daily or weekly**: ##### **Shell Example (Linux Cron Job):** ```bash #!/bin/bash TFTP_SERVER=192.168.1.100 SWITCH_IP=10.1.1.1 DATE=$(date +%F) FILENAME="cx_backup_$DATE.cfg" expect << EOF spawn ssh admin@$SWITCH_IP expect "Password:" send "YourPassword\r" expect "#" send "copy startup-config tftp $TFTP_SERVER $FILENAME\r" expect "#" send "exit\r" EOF ``` - Schedule with `crontab -e` - Ensure TFTP server is reachable and authenticated properly. ---

Shopping cart

Subtotal:

Examination Introduction

Learning Method

Study Plan

Exam Center