# Adam Spera — Full Content
> This documentation site is a working collection of technical notes, study materials, and configuration references compiled while studying for the CCIE Enterprise Infrastructure certification.
Source: https://adamspera.dev
---
# Routing
## Reliable Static Routes
URL: https://adamspera.dev/routing/reliable-static-routes/
## Overview
Reliable static routing combines traditional static routes with IP SLA tracking to provide automatic failover when paths become unavailable. While standard static routes remain in the routing table regardless of next-hop reachability, reliable static routes are dynamically removed when the tracked object fails.
**Standard Static Route:** Always present in routing table, even if next-hop is unreachable **Reliable Static Route:** Automatically removed from routing table when tracking fails
This provides the simplicity of static routing with automatic failover capabilities similar to dynamic routing protocols.
## How Reliable Static Routing Works
The process involves three components working together:
1. **IP SLA Operation:** Monitors reachability to a target (typically ICMP echo)
2. **Tracking Object:** Links IP SLA results to routing decisions
3. **Static Route:** References the tracking object for conditional installation
**Operation Flow:**
- IP SLA continuously monitors target reachability
- Tracking object reflects IP SLA state (up/down)
- Static route is installed only when tracking object is up
- Route automatically removed when tracking object goes down
## Basic Configuration
```
ip sla 1
icmp-echo 203.0.113.1 source-interface GigabitEthernet0/1
frequency 5
timeout 3000
threshold 2000
ip sla schedule 1 life forever start-time now
track 1 ip sla 1 reachability
delay down 1 up 5
ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 1
ip route 0.0.0.0 0.0.0.0 198.51.100.1 10
```
**Configuration Breakdown:**
**IP SLA Operation**
- `icmp-echo 203.0.113.1` - Target to monitor (typically ISP gateway)
- `source-interface` - Ensures ICMP originates from correct interface
- `frequency 5` - Test every 5 seconds
- `timeout 3000` - Wait 3 seconds for response
- `threshold 2000` - Consider response slow if over 2 seconds *does not do anything*
**Tracking Object**
- `track 1 ip sla 1 reachability` - Links tracking to SLA operation
- `delay down 1` - Wait 1 second before declaring down
- `delay up 5` - Wait 5 seconds before declaring up
**Static Routes:**
- Primary route with `track 1` - Removed when tracking fails
- Backup route with AD 10 - Takes over when primary removed
### Administrative Distance
Use consistent AD values to ensure predictable failover:
- Tracked routes: Default AD (1)
- Primary backup: AD 5-10
- Emergency backup: AD 15-20
## Verification Commands
```
show ip sla statistics
show ip sla configuration
show track
show track brief
show ip route track-table
show ip route static
debug ip routing
debug track
```
## Policy Based Routing (PBR)
URL: https://adamspera.dev/routing/policy-based-routing-pbr/
## Overview
Policy-Based Routing (PBR) allows forwarding decisions to be based on criteria other than destination IP address. While normal IP routing uses destination-based forwarding with longest match lookup, PBR enables routing decisions based on source, destination, protocol type, or incoming interface.
**Normal IP Routing**
- Find the longest match to destination in routing table
- Route the packet towards the next-hop
**Policy-Based Routing**
- Route based on defined policies and criteria
- Override normal routing table decisions when policies match
## How PBR Works
PBR uses route-maps to define traffic criteria and actions:
**Route-Map Logic**
- **Permit:** Apply policy routing to matching traffic
- **Deny:** Use normal destination-based forwarding for matching traffic
**Traffic Criteria:** Most commonly matched using access lists, but can also match on:
- Packet length
- Source interface
- Destination interface
## Interface Application
PBR should be applied on the **ingress interface** where the intended traffic is being received. This allows the router to make policy decisions before normal routing table lookup occurs.
**Why Ingress Application:**
- PBR processes packets as they enter an interface
- Allows policy decisions before normal routing table lookup
- More efficient than applying on multiple egress interfaces
- Catches traffic at the entry point for consistent policy enforcement
## Configuration Example
```
ip access-list extended ICMP_TRAFFIC
permit icmp 192.168.1.0 0.0.0.255 host 8.8.8.8
route-map PBR-ICMP permit 10
match ip address ICMP_TRAFFIC
set ip next-hop 10.0.0.6
route-map PBR-ICMP permit 20
! Deny statement - all other traffic uses normal routing
interface Ethernet0/0
description LAN-Interface-Ingress
ip policy route-map PBR-ICMP
```
**Configuration Breakdown:**
- **Access List:** Defines ICMP traffic from 192.168.1.0/24 to 8.8.8.8
- **Route-Map Permit 10:** Matches the ACL and sets specific next-hop
- **Route-Map Permit 20:** Empty permit acts as deny - normal routing for other traffic
- **Interface Application:** Applied to ingress interface where LAN traffic enters
## Optional Default Next-Hop
The `set ip default next-hop` command modifies PBR behavior to check the routing table first before applying the policy route:
- **Standard PBR:** `set ip next-hop` - Forces traffic through specified next-hop regardless of routing table
- **Default PBR:** `set ip default next-hop` - Uses routing table first, only applies PBR if no route exists
```
route-map PBR-DEFAULT permit 10
match ip address BACKUP_TRAFFIC
set ip default next-hop 10.0.0.100
```
**How Default Next-Hop Works**
1. Router checks routing table for destination
2. If route exists in RIB, uses normal routing
3. If no route exists in RIB, uses PBR next-hop
4. Provides backup routing when normal paths fail
## Local PBR
For router-generated traffic (such as management, SNMP, or syslog), use local PBR:
```
ip local policy route-map PBR-LOCAL
```
This applies PBR to traffic originated by the router itself rather than transit traffic.
## Verification Commands
```
show ip policy
show route-map
show ip local policy
debug ip policy
show ip route policy
```
## OSPF (Open Shortest Path First)
URL: https://adamspera.dev/routing/ospf-open-shortest-path-first/
# Overview
OSPF (Open Shortest Path First) is a link-state IGP used to distribute routing information within a single autonomous system (AS).
OSPF uses a series of message types including Hello, Update, and Acks. The payload of these messages are called LSAs (Link-State Advertisements). These LSAs have multiple types, each of which provide different information according to their type, but almost always related to network routes. *For example, one LSA may simply tell other routers what networks it has reachability to, while another may be telling other routers on a broadcast segment that it is there.*
OSPF uses Dijkstra's Shortest Path First (SPF) algorithm to calculate the best path to every destination, considering the main metric which is the summation of all egress interface's Cost, being a manually configured reference bandwidth divided by the interfaces actual bandwidth.
# About This Document
This document is designed to be read top down as a full OSPF lesson. The reader is walked from the world view (areas, roles), into how routers cooperate (adjacency, LSDB), then into how routes are chosen (SPF), then into operational topics (stubs, virtual links, authentication, configuration).
OSPFv3 is covered after OSPFv2. All previous info is based on OSPFv2.
The full **OSPF wire format** (packet header, packet types, byte layouts) is provided at the end of this document as a reference appendix. It is not required for conceptual understanding.
> This document uses the ABNF Specification (RFC 5234) to define protocol structures. The syntax for a repeating field uses an asterisk (\*) meaning "zero or more".
---
# The OSPF Hierarchy
## Why OSPF Has Areas
A single OSPF area is bounded by its LSDB, every router in the area must hold an identical copy. As the area grows, three pressures appear:
1. **LSDB size** scales with the number of links and routers.
2. **SPF runtime** scales worse than linearly with LSDB size.
3. **Flooding domain** grows, meaning any link flap is felt by every router in the area.
OSPF solves this with **hierarchy**: split the AS into smaller areas connected by a central backbone. Each area runs SPF locally, while inter-area routes are summarized at the boundary.
## Area 0 (Backbone)
Every OSPF AS has a single **backbone area** identified as **Area 0** (or `0.0.0.0` in dotted-decimal). All non-backbone areas must connect to Area 0, either directly or through a virtual link.
This rule prevents routing loops by forcing all inter-area traffic to transit the backbone.
## Router Roles
### Internal Router
- All OSPF-enabled interfaces sit in a single non-backbone area.
- Originates only Router-LSAs (Type 1) into its area.
### Backbone Router
- At least one OSPF-enabled interface in Area 0.
- May also be an ABR if it has interfaces in non-backbone areas.
### Area Border Router (ABR)
- Sits between Area 0 and one or more non-backbone areas.
- Maintains a **separate LSDB per area** it touches. *Be careful, this can overburden the router if it touches many areas*.
- Originates **Type 3 Summary-LSAs** into adjacent areas to describe inter-area destinations.
- Sets the **B bit** in its Router-LSA.
### Autonomous System Boundary Router (ASBR)
- Redistributes routes from outside OSPF (other routing protocols, static routes, `default-information originate`) into OSPF.
- Originates **Type 5 AS-External-LSAs** *(or Type 7 inside an NSSA)*.
- Sets the **E bit** in its Router-LSA.
*A single router can play multiple roles simultaneously. For example, a backbone router that is also an ABR and an ASBR.*
## Route Types
Each route in the OSPF routing table is tagged by how it entered the LSDB:
```
Code Description Origin
______________________________________________________________
O Intra-area Router/Network-LSA
O IA Inter-area Type 3 Summary-LSA
O E1 External Type 1 (metric increases) Type 5
O E2 External Type 2 (metric fixed) Type 5 (DEFAULT)
O N1 NSSA External Type 1 Type 7
O N2 NSSA External Type 2 Type 7
```
*Ranking and tie-breaking for these route types is covered in the SPF Calculation section.*
---
# Router-ID Selection
The `router-id [ip]` command uniquely identifies a router within an OSPF process. The Router-ID is in IPv4 format but does not need to be reachable, it is just an identifier.
The Router-ID is selected based on:
1. Manually configured with `router-id`.
2. Highest IP address on an active loopback interface.
3. Highest IP address on an active physical interface.
```
router ospf 1
router-id 1.1.1.1
```
The Router-ID is selected **once** when the OSPF process starts and is not re-evaluated automatically when interfaces change. To force re-selection, use `clear ip ospf process`.
Router-IDs **must be unique** across the OSPF AS. Duplicate Router-IDs cause adjacency formation failures, LSDB corruption, and routing loops.
*Loopback interfaces are preferred over physical interfaces because they are always up unless explicitly shut down. This makes the Router-ID stable across physical link failures.*
---
# Network Types
The OSPF network type, set per interface, governs three things:
1. Whether a DR/BDR is elected on the segment.
2. Default Hello and Dead timer values.
3. How the segment is represented in LSAs (specifically, whether a Network-LSA is generated).
The `ip ospf network [broadcast | point-to-point | non-broadcast | point-to-multipoint | point-to-multipoint non-broadcast]` command sets the OSPF network type on an interface. *Loopback type is automatic on loopback interfaces.*
## Broadcast
- Default on Ethernet *(GigabitEthernet, FastEthernet, TenGigabitEthernet, etc)*.
- Elects DR/BDR.
- Hellos sent via **Multicast 224.0.0.5**.
- **Hello** timer: **10 seconds** / **Dead** timer: **40 seconds**.
- Segment is described in the LSDB by a Network-LSA (Type 2) originated by the DR.
## Point-to-Point
- Default on HDLC, PPP, GRE tunnels, and sub-interfaces.
- No DR/BDR (only two routers on the link).
- Hellos sent via **Multicast 224.0.0.5**.
- **Hello** timer: **10 seconds** / **Dead** timer: **40 seconds**.
- Both routers go directly to FULL with each other.
## Non-Broadcast (NBMA)
- Default on Frame Relay and ATM main interfaces.
- Elects DR/BDR.
- Hellos sent via **Unicast** *(neighbors must be manually defined)*.
- **Hello** timer: **30 seconds** / **Dead** timer: **120 seconds**.
## Point-to-Multipoint
- No DR/BDR.
- Treats the segment as a collection of point-to-point links from each spoke to the hub.
- Hellos sent via **Multicast 224.0.0.5**.
- **Hello** timer: **30 seconds** / **Dead** timer: **120 seconds**.
## Point-to-Multipoint Non-Broadcast
- No DR/BDR.
- Manual neighbor configuration with Unicast Hellos.
- Useful on DMVPN phase 1/2 deployments.
## Loopback
- Always advertised as a /32 host route regardless of the interface's actual mask.
- Never forms adjacencies (no Hellos are sent on loopbacks).
---
# Adjacency Process
When you connect two OSPF routers, they transition through these eight distinct states sequentially:
1. Down
2. Attempt *(NBMA networks only)*
3. Init
4. 2-Way
5. Exstart
6. Exchange
7. Loading
8. Full
![[Jeremy's IT Lab's Adjacency Screenshot.png]]
![[Screenshot 2026-04-23 at 8.39.44 AM.png]]
![[Screenshot 2026-04-23 at 8.42.53 AM.png]]
![[Screenshot 2026-04-23 at 8.44.01 AM.png]]
```
ROUTER A STATE ROUTER B STATE
============== ==============
[ DOWN ] [ DOWN ]
| |
|--- (Hello: My ID is 1.1.1.1) ------------------------------->|
| Neighbors Seen: [None] |
| V
[ DOWN ] [ INIT ]
| |
|<-- (Hello: My ID is 2.2.2.2) --------------------------------|
| Neighbors Seen: 1.1.1.1 |
V |
[ 2-WAY ] |
| |
| |
|--- (Hello: My ID is 1.1.1.1) ------------------------------->|
| Neighbors Seen: 2.2.2.2 |
| V
[ 2-WAY ] [ 2-WAY ]
[ EXSTART ] [ EXSTART ]
| |
|----- (DBD: Seq=100, I'm Master, More=1) -------------------->|
|<---- (DBD: Seq=500, I'm Master, More=1) ---------------------|
| (I have higher Router ID!) |
| (A surrenders, assumes B as Master) |
| |
V V
[ EXCHANGE ] [ EXCHANGE ]
| |
|--- (DBD: Seq=500, I'm Slave, [LSA Headers A], More=1) ------>|
| (A sends its summary list) |
| |
|<-- (DBD: Seq=501, I'm Master, [LSA Headers B], More=0) ------|
| (B sends its summary list) |
| |
|--- (DBD: Seq=501, I'm Slave, Empty DBD, More=0) ------------>|
| (A acknowledges B's final packet, aka More=0) |
| |
V V
[ LOADING ] [ LOADING ]
| |
|--- (LSR: "Send me full info for LSA X") -------------------->|
| |
|<-- (LSU: [Full LSA X Data Body Payload]) --------------------|
| (B sends the missing cargo) |
| |
|--- (LSAck: "Got LSA X, thank you") ------------------------->|
| |
V V
[ FULL ] [ FULL ]
```
## Neighbor Requirements
For two routers to progress from Down through to FULL, the following parameters must match between them:
1. **Area ID**.
2. **Subnet mask** *(on multi-access segments only, point-to-point links ignore the mask)*.
3. **Hello and Dead timer** values.
4. **Authentication** type and key.
5. **Stub area flag** in Hello Options.
6. **MTU** *(compared during the DBD exchange, not from Hellos)*.
A mismatch on any of the above will prevent the adjacency from progressing past whichever stage validates that parameter.
### Timer Configuration
The `ip ospf hello-interval [seconds]` command sets the time between Hello packets on an interface.
The `ip ospf dead-interval [seconds]` command sets how long a router waits before declaring a silent neighbor down. *Cisco's default Dead = 4 × Hello.*
```
interface GigabitEthernet0/0
ip ospf hello-interval 5
ip ospf dead-interval 20
```
The `ip ospf dead-interval minimal hello-multiplier [3-20]` command enables sub-second Hellos, where the Dead interval stays at 1 second and Hellos are sent at `1/multiplier` second intervals.
### MTU Mismatch Workaround
If two routers have different interface MTUs, the DBD exchange will hang in the **Exstart** or **Exchange** state.
The `ip ospf mtu-ignore` command tells the router to skip the MTU check during DBD negotiation. *Use this only when you cannot fix the MTU mismatch at the source.*
```
interface GigabitEthernet0/0
ip ospf mtu-ignore
```
## DR/BDR Election
On multi-access segments (broadcast, NBMA) with N routers, full-mesh adjacencies would require N(N-1)/2 LSDB exchanges. The DR/BDR mechanism collapses this into a hub-and-spoke: every router only forms a FULL adjacency with the DR and BDR, and the DR is responsible for originating the Network-LSA (Type 2) that describes the segment.
Routers that are neither DR nor BDR on a segment are called **DROther** routers. DROther-to-DROther neighbor relationships stop at the **2-Way** state, they see each other in Hellos but never synchronize LSDBs directly.
### Multicast Addresses
- **224.0.0.5** *(AllSPFRouters)*: used by DR/BDR to send LSU and LSAck packets to every router on the segment.
- **224.0.0.6** *(AllDRouters)*: used by DROther routers to send LSU and LSAck packets to only the DR and BDR.
### Election Rules
1. **Highest OSPF interface priority** *(range 0-255, default 1)*.
2. **Highest OSPF Router-ID** as the tiebreaker.
A priority of **0** makes a router ineligible to ever become DR or BDR on that segment.
The `ip ospf priority [0-255]` command sets the OSPF interface priority. This is the primary lever for influencing DR/BDR placement.
```
interface GigabitEthernet0/0
ip ospf priority 100
```
### Non-Preemption
DR/BDR roles are **non-preemptive**. Once elected, a DR/BDR keeps its role until the OSPF process resets or the router goes down, even if a higher-priority router joins the segment later.
When the DR fails:
1. The **BDR is promoted to DR** automatically.
2. A new BDR is elected from the remaining DROthers using the standard rules.
> To force a re-election (for example, after raising a priority), use `clear ip ospf process` on the routers involved.
### Adjacency State on a Broadcast Segment
```
Neighbor Pair Final State
__________________________________
DR <-> BDR FULL
DR <-> DROther FULL
BDR <-> DROther FULL
DROther <-> DROther 2-Way
```
This is why the Adjacency Process state diagram above shows two routers progressing cleanly to FULL, it depicts a Point-to-Point segment. On a broadcast segment, only adjacencies that involve the DR or BDR reach FULL.
### Terminology
- A **neighbor** is any router that has reached the **2-Way** state.
- An **adjacency** is a neighbor that has reached the **FULL** state.
*These terms are commonly used interchangeably in casual writing, but the distinction matters during troubleshooting.*
---
# LSAs & The LSDB
## LSA Header
All LSAs (Link State Advertisements) begin with a common 20 byte header. This header contains enough information to uniquely identify the LSA (LS type, Link State ID, and Advertising Router). Multiple instances of the LSA may exist in the routing domain at the same time. It is then necessary to determine which instance is more recent. This is accomplished by examining the LS age, LS sequence number and LS checksum fields that are also contained in the LSA header.
```
OSPF LSA Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...header + message... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age | Options | LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```
LS Age
- The time in seconds since the LSA was originated.
Options
- The optional capabilities supported by the described portion of the routing domain.
LS Type
- The type of the contained LSA.
- Each LSA type has a separate advertisement body/payload format.
```
LS Type Description
___________________________________
1 Router-LSAs
2 Network-LSAs
3 Summary-LSAs (IP Network)
4 Summary-LSAs (ASBR Location)
5 AS-external-LSAs
```
Link State ID
- This field identifies the portion of the environment that is being described by the LSA.
- The contents of this field **depend on the LSA's LS type**.
- For example, in Network-LSAs (2) the Link State ID is set to the IP interface address of the network's Designated Router (from which the Network Address can be derived).
Advertising Router
- The Router ID of the router that originated the LSA.
- For example, in Network-LSAs (2) this field is equal to the Router ID of the network's Designated Router.
LS Sequence Number
- Detects old or duplicate LSAs.
- Successive instances of an LSA are given successive LS sequence numbers.
LS Checksum
- The checksum (Fletcher) of the complete contents of the LSA, including the LSA header but excluding the LS age field.
- Why exclude the LSA Age field? Because the age constantly changes as the packet moves from router to router, the checksum would break if it included those 2 bytes.
Length
- The length in bytes of the LSA (including the 20-byte header).
- This tells the receiving router how long the entire LSA is.
---
## LSA Types
There are 5 types of LSAs, each beginning with a 20-byte LSA header, followed by the specific type's body/payload.
### Router-LSAs
Each router in an area originates a router-LSA.
The LSA describes the state and cost of the router's links (i.e., interfaces) to the area. All of the router's links to the area must be described in a single router-LSA.
```
OSPF Router-LSA
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...ospf_header + message + lsa_header... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |V|E|B| 0 | # Links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | # TOS | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| * above 3 fields |
```
In Router-LSAs, the Link State ID field in the OSPF Packet Header is set to the router's OSPF Router ID.
Router-LSAs are flooded throughout a single area only.
Bit V
- When set, the router is an endpoint of one or more fully adjacent virtual links having the described area as Transit area (V is for virtual link endpoint).
Bit E
- When set, the router is an AS boundary router (E is for external).
Bit B
- When set, the router is an area border router (B is for border).
\# Links
- The number of router links described in this LSA.
- This must be the total collection of router links (i.e., interfaces) to the area.
The following fields are used to describe each router link (i.e., interface).
Each router link is typed (see the below Type field).
The Type field indicates the kind of link being described. It may be a link to a transit network, to another router or to a stub network. The values of all the other fields describing a router link depend on the link's Type.
Type
- A quick description of the router link.
- One of the following.
- Note that host routes are classified as links to stub networks with network mask of 0xffffffff.
```
Type Description
__________________________________________________
1 Point-to-point connection to another router
2 Connection to a transit network
3 Connection to a stub network
4 Virtual link
```
Link ID
- Value depends on the link's Type.
- Identifies the object that this router link connects to.
- When connecting to an object that also originates an LSA (i.e., another router or a transit network) the Link ID is equal to the neighboring LSA's Link State ID. This provides the key for looking up the neighboring LSA in the link state database during the routing table calculation.
```
Type Link ID
______________________________________
1 Neighboring router's Router ID
2 IP address of Designated Router
3 IP network/subnet number
4 Neighboring router's Router ID
```
Link Data
- Value again depends on the link's Type field.
- For connections to stub networks, Link Data specifies the network's IP address mask.
- For unnumbered point-to-point connections, it specifies the interface's MIB-II ifIndex value. For the other link types it specifies the router interface's IP address. This latter piece of information is needed during the routing table build process, when calculating the IP address of the next hop.
\# TOS
- The number of different TOS metrics given for this link, not counting the required link metric.
Metric
- The cost of using this router link.
Additional TOS-specific information may also be included, for backward compatibility with previous versions of the OSPF specification.
### Network-LSAs
A Network-LSA is originated for each broadcast and NBMA network in the area which supports two or more routers. The Network-LSA is originated by the network's Designated Router. The LSA describes all routers attached to the network, including the Designated Router itself. The LSA's Link State ID field lists the IP interface address of the Designated Router.
```
OSPF Network-LSA
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...ospf_header + message + lsa_header... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| * Attached Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```
Network Mask
- The IP address subnet mask for the network.
- **Remember: the Link State ID field in the LSA Header is the network address.**
Attached Router
- The Router IDs of each of the routers attached to the network.
- Repeated as a list for every Attached Router.
### Summary-LSAs
These LSAs are originated by area border routers. Summary-LSAs describe inter-area destinations.
Type 3 summary-LSAs are used when the destination is an IP network. In this case the LSA's Link State ID field is an IP network number (if necessary, the Link State ID can also have one or more of the network's "host" bits set.
When the destination is an AS boundary router, a Type 4 summary-LSA is used, and the Link State ID field is the AS boundary router's OSPF Router ID.
Other than the difference in the Link State ID field, the format of Type 3 and 4 summary-LSAs is identical.
```
OSPF Summary-LSA
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...ospf_header + message + lsa_header... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| * above 2 fields |
```
*For stub areas, Type 3 Summary-LSAs can also be used to describe a (per-area) default route. Default summary routes are used in stub areas instead of flooding a complete set of external routes. When describing a default summary route, the summary-LSA's Link State ID is always set to DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0.*
Network Mask
- For Type 3 Summary-LSAs, this indicates the destination network's IP address subnet mask.
- This field is not meaningful and must be zero for Type 4 summary-LSAs.
Metric
- The cost of this route.
- Expressed in the same units as the interface costs in the router-LSAs.
### AS-External-LSAs
These LSAs are originated by AS boundary routers, and describe destinations external to the AS.
AS-external-LSAs usually describe a particular external destination.
AS-external-LSAs are also used to describe a default route. When describing a default route, the Link State ID is always set to DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0.
```
OSPF AS-External-LSAs
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...ospf_header + message + lsa_header... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```
Network Mask
- The IP address mask for the advertised destination.
Bit E
- The type of external metric.
- If bit E is set, the metric specified is a Type 2 external metric.
- If bit E is set to zero, the specified metric is a Type 1 external metric.
Metric
- The cost of this route.
- Interpretation depends on the external type indication (bit E above).
Forwarding Address
- Data traffic for the advertised destination will be forwarded to this address.
External Route Tag
- A 32-bit field attached to each external route.
- This is not used by the OSPF protocol itself.
---
## LSA Lifecycle
Each LSA is **refreshed every 30 minutes** by its originator. The MaxAge timer is **60 minutes**. An LSA that is not refreshed before MaxAge is flushed from the LSDB and SPF re-runs without it.
---
# SPF Calculation
OSPF's metric is **cost**, a 16-bit value carried in the `Metric` field of Router-LSAs and Summary-LSAs.
## Interface Cost
```
interface_cost = reference_bandwidth / interface_bandwidth
```
- **Default reference bandwidth:** 100,000 Kbps (100 Mbps).
- **Minimum cost:** 1. Anything that would round below 1 is clamped to 1.
- **Loopback cost:** always 1.
*By default, every interface at 100 Mbps and above gets the same cost of 1, which is almost never what you want in a modern network.*
The OSPF Cost to a destination is the sum of the cost of every **egress interface** along the path.
> Bandwidth, like Delay, is used only for metric calculation. It does not affect data plane forwarding.
## Changing Cost
Three knobs, in increasing order of specificity:
The `auto-cost reference-bandwidth [mbps]` command changes the reference bandwidth for the entire OSPF process.
```
router ospf 1
auto-cost reference-bandwidth 100000
```
The `bandwidth [kbps]` interface command changes the interface's reported bandwidth, which feeds the cost formula.
The `ip ospf cost [cost]` interface command overrides cost entirely on a single interface, ignoring the formula.
```
interface GigabitEthernet0/0
ip ospf cost 10
```
> Configure the reference bandwidth higher than your fastest link, 100× the fastest is a common rule of thumb. Set this consistently across every router in the AS, since mismatched reference bandwidths produce asymmetric routing.
## Running SPF
Every router roots the SPF tree at **its own Router-LSA** and walks the graph built from the LSDB, summing the cost of egress interfaces along each path. Because every router in the area holds an identical LSDB, every router computes the same shortest-path tree from its own perspective.
The three main steps to determine the best path:
1. Become neighbors with other routers connected to the same segment.
2. Exchange LSAs with neighboring routers until the LSDB is synchronized.
3. Run SPF against the LSDB and install the best route to each destination in the routing table.
## Route Preference
When multiple LSAs describe the same destination, OSPF prefers them in this order, regardless of metric:
1. Intra-area (**O**).
2. Inter-area (**O IA**).
3. External Type 1 (**O E1**): external cost **plus** internal cost to the ASBR.
4. External Type 2 (**O E2**): external cost only. *This is the default for redistributed routes.*
5. NSSA Type 1 / 2 (**O N1** / **O N2**): same logic as E1/E2 but for Type 7 LSAs.
*Only after this preference order is applied does SPF break ties on accumulated cost.*
## ECMP
OSPF supports **Equal-Cost Multipath** load balancing over up to 4 paths by default.
The `maximum-paths [1-32]` command sets the maximum number of equal-cost routes OSPF can install for any single destination.
```
router ospf 1
maximum-paths 4
```
## Administrative Distance
OSPF's default Administrative Distance is **110**.
The `distance [1-255]` command changes the AD for the OSPF process.
```
router ospf 1
distance 110
```
---
# Stub Areas Types
OSPF defines four stub variants. Each progressively restricts which LSA types are allowed into the area, trading external route granularity for a smaller LSDB and faster SPF.
Each variant is defined by which LSA types it admits, and whether the ABR auto-injects a default route into the area:
```
Type 3 Type 5 Type 7 Default Route from ABR
__________________________________________________________________________
Normal Area YES YES no (none auto)
Stub YES no no Yes (auto)
Totally Stubby no no no Yes (auto)
NSSA YES no YES no (needs explicit cmd)
Totally NSSA no no YES Yes (auto)
```
## Stub
A Stub area **blocks Type 5 LSAs** from entering. *Type 4 LSAs are blocked as a side effect, since Type 4s only exist to locate ASBRs and the area no longer carries any Type 5s.*
This solves the case where an area has no need to know about external routes individually. The ABR injects a default route so the area can still reach external destinations through it.
The `area [id] stub` command must be configured on **every router** inside the stub area, not just the ABR.
```
router ospf 1
area 10 stub
```
> *Default routes injected via `default-information originate` from elsewhere in the AS are still received by the stub area, despite being carried as Type 5 in the rest of the AS. The ABR re-injects the default as a Type 3 into the stub.*
## Totally Stubby
The **Totally** modifier extends Stub to also block **Type 3 LSAs**. The area is left with only its own intra-area Type 1 routes plus the ABR-injected default route.
Because Type 3 LSAs are only originated by ABRs, the `no-summary` flag only needs to be set on the ABR, where internal routers cannot generate Type 3s and so cannot be the source of any to block.
ABR configuration:
```
router ospf 1
area 10 stub no-summary
```
Internal router configuration:
```
router ospf 1
area 10 stub
```
> *As with plain Stub, default routes propagated via `default-information originate` from elsewhere in the AS are still received.*
## Not-So-Stubby Area (NSSA)
A Not-So-Stubby Area covers the edge case where you want an ASBR to live **inside** a stub area. NSSA still blocks Type 5 from entering at the ABR, but a router inside the area that needs to redistribute external routes originates them as **Type 7 LSAs** instead of Type 5. The ABR then translates Type 7 into Type 5 at the area boundary so the rest of the AS sees the routes normally.
Because the trigger for "use Type 7 instead of Type 5" lives on the inside ASBR itself, the `area [id] nssa` command must be configured on **every router** in the area, same as a regular Stub.
```
router ospf 1
area 10 nssa
```
### Default Route Caveat
> *Unlike Stub and Totally Stubby, an NSSA's ABR does **not** auto-inject a default route, and **does not** forward default routes originated via `default-information originate` from elsewhere in the AS.*
To make the ABR advertise a default route into the NSSA, add `default-information-originate` to the NSSA command on the ABR:
```
router ospf 1
area 10 nssa default-information-originate
```
## Totally NSSA
Totally NSSA combines NSSA's Type 7 support with the Totally modifier's Type 3 blocking. As with Totally Stubby, the `no-summary` flag is only set on the ABR.
ABR configuration:
```
router ospf 1
area 10 nssa no-summary
```
Internal router configuration:
```
router ospf 1
area 10 nssa
```
> *Unlike plain NSSA, Totally NSSA does **not** suffer from the default-route caveat. The ABR auto injects a default route just as it would in a Totally Stubby area.*
---
# Virtual Links
A virtual link extends Area 0 through a non-backbone **transit area** to either:
1. Attach an orphan area that has no physical connection to the backbone.
2. Repair a partitioned backbone.
The virtual link is treated as a point-to-point link inside Area 0, even though the underlying transport runs across the transit area's LSDB.
## Restrictions
- The transit area **cannot** be a stub of any flavor *(Stub, Totally Stub, NSSA, Totally NSSA)*. Stub areas block the LSA types that virtual links depend on.
- Must be configured on **both ABRs**, each pointing at the other's Router-ID.
## Configuration
The `area [transit-id] virtual-link [remote-router-id]` command builds the virtual link. Both ends must agree on the transit area.
On ABR1, targeting Router-ID 3.3.3.3 at the other end of the transit area:
```
router ospf 1
area 1 virtual-link 3.3.3.3
```
On ABR2, targeting Router-ID 7.7.7.7:
```
router ospf 1
area 1 virtual-link 7.7.7.7
```
*Once the virtual link is up, the two ABRs will form an OSPF adjacency over it that appears in `show ip ospf neighbor` as if it were a physical neighbor.*
---
# Authentication
OSPF authentication operates per the `AuType` field in the OSPF Packet Header.
*See the Wire-Level Reference at the end of this document for the OSPF header format.*
## Type 0: Null (Default)
No authentication.
The 64-bit Authentication field in the OSPF header is unused.
## Type 1: Simple Password
Plain-text password, **maximum 8 characters**.
*Passwords shorter than 8 characters are right-padded with null bytes to fill the 64-bit Authentication field.*
> Vulnerable to anyone capturing OSPF packets on the wire.
> Use only in lab or transient deployments.
Configuration per interface:
```
interface GigabitEthernet0/0
ip ospf authentication
ip ospf authentication-key MySecret
```
Configuration per area *(applies to every interface in the area)*:
```
router ospf 1
area 0 authentication
```
## Type 2: Cryptographic
Sends a digest of the password + packet, not the password itself. Has two flavors.
### Legacy MD5
- MD5 only.
- Automatic key rollover: when migrating to a new key, the router sends one OSPF message per active key (including the youngest) until neighbors switch to the youngest key too.
```
interface GigabitEthernet0/0
ip ospf message-digest-key 1 md5 MySecret
router ospf 1
area 0 authentication message-digest
```
### Keychain (Modern)
- Supports MD5, HMAC-SHA1, HMAC-SHA-256, HMAC-SHA-512.
- Single command per interface. No area-level authentication command required.
```
key chain OSPF-KEYS
key 1
key-string MySecret
cryptographic-algorithm hmac-sha-256
interface GigabitEthernet0/0
ip ospf authentication key-chain OSPF-KEYS
```
*The keychain version replaces both interface-level commands and the area-level command with a single per-interface command.*
---
# Configuration
## Process ID
The OSPF process ID is **locally significant**.
Routers do not need to match process IDs to form adjacencies.
```
router ospf 1
```
*The `1` is local to this router. Another router on the same segment could run `router ospf 99` and still form an adjacency.*
## Enabling OSPF on Interfaces
There are two methods to enable OSPF on an interface:
### Method 1: Network Statement
```
router ospf 1
network 10.0.12.0 0.0.0.3 area 0
```
The `network [address] [wildcard] area [id]` command enables OSPF on every interface whose IP falls inside the wildcard range and assigns those interfaces to the specified area.
> The second argument is a **wildcard mask** (0s match, 1s ignore), not a subnet mask. `0.0.0.3` matches a /30.
### Method 2: Per-Interface
```
interface GigabitEthernet0/0
ip ospf 1 area 0
```
The `ip ospf [process-id] area [id]` command enables OSPF directly on the interface and skips the network statement entirely. This is preferred for explicit, non-overlapping configurations.
## Default Route Origination
```
ip route 0.0.0.0 0.0.0.0 203.0.113.2
router ospf 1
default-information originate
```
The `default-information originate` command advertises a default route via OSPF.
*The router automatically becomes an ASBR.*
Append `always` to advertise the default route even when the local `0.0.0.0/0` route is down:
```
router ospf 1
default-information originate always
```
## Passive Interfaces
The `passive-interface [interface]` command suppresses Hellos on an interface while still advertising the interface's subnet into OSPF. *Used for host-only LAN interfaces like DFGWs where no OSPF neighbors are reachable.*
```
router ospf 1
passive-interface GigabitEthernet0/1
```
## ABR Example
A complete minimal config for a single ABR sitting between Area 0 and Area 1:
```
router ospf 1
router-id 1.1.1.1
auto-cost reference-bandwidth 100000
maximum-paths 4
network 10.0.0.0 0.0.0.255 area 0
network 10.0.1.0 0.0.0.255 area 1
passive-interface GigabitEthernet0/2
```
---
# Packet Structure
## Overview
This appendix documents the OSPF wire format: the standard OSPF Packet Header and the five OSPF Packet Types. *For the LSA wire format (LSA Header and the five LSA Types), see the LSAs & The LSDB section earlier in the document.*
The following graphic describes how a full OSPF Packet can be formatted (this example uses a Link State Update packet that contains LSAs):
```
+-------------------------------------------------------------------------------+
| 1. THE ETHERNET FRAME (Layer 2 - Outer Envelope) |
| Source MAC: 00:11:22:AA:BB:CC (Sending Router's Interface) |
| Destination MAC: 01:00:5E:00:00:05 (Multicast MAC for All OSPF Routers) |
| EtherType: 0x0800 (IPv4) |
| |
| +---------------------------------------------------------------------------+|
| | 2. THE IP PACKET (Layer 3 - Inner Envelope) ||
| | Source IP: 192.168.1.1 (Sending Router's Interface IP) ||
| | Destination IP: 224.0.0.5 (AllSPFRouters Multicast IP) ||
| | Protocol ID: 89 (OSPF Direct Transport) ||
| | ||
| | +---------------------------------------------------------------------+ ||
| | | OSPF PACKET STREAM (Sequential Bytes) | ||
| | | | ||
| | | 3. THE OSPF HEADER (24-Bytes Fixed) | ||
| | | Sending Router ID: 1.1.1.1 | Area ID: 0.0.0.0 | ||
| | | Message Type: 4 (LSU Packet) | ||
| | | | ||
| | | 4. THE LSU PAYLOAD METADATA (4-Bytes Counter) | ||
| | | Manifest Counter: "This payload holds [1] LSA update." | ||
| | | | ||
| | | 5. LSA HEADER (20-Bytes Fixed metadata) | ||
| | | LSA Type: 1 (Router LSA) | ||
| | | Link State ID / Adv Router: 1.1.1.1 | ||
| | | Sequence Number: 0x80000003 (Version control) | ||
| | | | ||
| | | 6. LSA DATA BODY (The Actual Map Cargo - Variable Length) | ||
| | | - Link #1: Subnet 10.10.10.0/24 (Cost: 10) | ||
| | | - Link #2: Subnet 172.16.1.0/24 (Cost: 1) | ||
| | +---------------------------------------------------------------------+ ||
| +---------------------------------------------------------------------------+|
+-------------------------------------------------------------------------------+
```
---
## Packet Header
Every OSPF packet starts with a standard 24 byte header.
This header contains all the information necessary to determine whether the packet should be accepted for further processing.
```
OSPF Packet Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...payload... |
```
Version #
- The OSPF version number.
- This will either be 2 or 3 depending on the OSPF version.
Type
- The OSPF packet types are as follows.
- This defines what the receiving router should expect the body to be.
```
Type Description
________________________________
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State Acknowledgment
```
Packet Length
- The length of the OSPF protocol packet in bytes, including the standard OSPF header.
- This tells the receiving router how long the entire OSPF packet is.
Router ID
- The Router-ID of the packet's source (the router that is generating this packet).
Area ID
- A 32 bit number identifying the area that this packet belongs to.
- All OSPF packets are associated with a single area.
- Packets traveling over a virtual link are labelled with the backbone Area ID of 0.0.0.0.
Checksum
- The standard IP checksum of the entire contents of the packet, starting with the OSPF packet header but excluding the 64-bit authentication field.
AuType
- Identifies the authentication procedure to be used for the packet.
```
AuType Description
___________________________________________
0 Null authentication (none)
1 Simple password (plain text)
2 Cryptographic authentication (MD5/SHA)
```
Authentication
- A 64-bit field for use by the authentication scheme.
- This field contains the actual authentication body.
- *If the AuType is 1 and the body is less than 8 chars, the remainder of the field is padded with null bytes.*
---
## Packet Types
As determined by the OSPF Header "Type" field, there are multiple different message types that can be leveraged by OSPF for communication.
This part of the OSPF Packet follows the Authentication field in the OSPF Header, aka, is the payload.
### Hello
All routers connected to a common network must agree on certain parameters (Network mask, HelloInterval and RouterDeadInterval). These parameters are included in Hello packets, so that differences can inhibit the forming of neighbor relationships.
These packets are sent periodically on all interfaces (including virtual links) in order to establish and maintain neighbor relationships:
**Fast Mode**
`BROADCAST` (Default on Ethernet/FastEthernet/GigabitEthernet) &
`POINT_TO_POINT` (Default on HDLC, PPP, and GRE Tunnels):
- **Hello:** 10 seconds
- **Dead:** 40 seconds
**Slow Mode**
`NON_BROADCAST / NBMA` (Default on Frame Relay and ATM main interfaces) &
`POINT_TO_MULTIPOINT NON_BROADCAST` (DMVPN):
- **Hello:** 30 seconds
- **Dead:** 120 seconds
```
OSPF Hello Packet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...header... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | Options | Rtr Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RouterDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| * Neighbor Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```
Network Mask
- The network mask associated with this interface.
- For two OSPFv2 routers to form a neighbor adjacency on a multi-access network (like an Ethernet broadcast network or an NBMA network), their subnet masks must match exactly.
- *Example: 255.255.255.0*
Options
- Acts as a set of feature flags, allowing a router to advertise its optional capabilities to its neighbors before they exchange routing databases.
- Notably used during Stub/NSSA operations.
HelloInterval
- The number os seconds between this router's Hello packets.
Rtr Pri
- This router's Router Priority.
- Used in (Backup) Designated Router election.
RouterDeadInterval
- The number of seconds before declaring a silent router down.
Designated Router
- The identity of the Designated Router for this network, in the view of the sending router. The Designated Router is identified here by its IP interface address on the network.
- Set to 0.0.0.0 if there is no Designated Router for the segment.
Backup Designated Router
- The identity of the Backup Designated Router for this network, in the view of the sending router. The Backup Designated Router is identified here by its IP interface address on the network.
- Set to 0.0.0.0 if there is no Backup Designated Router.
Neighbor
- The Router IDs of each router from whom valid Hello packets have been seen within the RouterDeadInterval amount of seconds on the network.
- This field is repeated for every known neighbor as indicated by the () in the structure.
### Database Description (DBD)
These packets are exchanged when an adjacency is being initialized.
They describe the contents of the link-state database by showing the LSA headers of each.
> The format of the Database Description packet is very similar to both the Link State Request and Link State Acknowledgment packets. The main part of all three is a list of items, each item describing a piece of the link-state database.
Multiple packets may be used to describe the database. For this purpose a poll-response procedure is used. One of the routers is designated to be the master, the other the slave. The master sends Database Description packets (polls) which are acknowledged by Database Description packets sent by the slave (responses). The responses are linked to the polls via the packets' DD sequence numbers.
```
OSPF Database Description Packet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...header... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface MTU | Options |0|0|0|0|0|I|M|MS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DD sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- * an LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```
Interface MTU
- The size in bytes of the largest IP datagram that can be sent out the associated interface, without fragmentation.
- *Interface MTU should be set to 0 in Database Description packets sent over virtual links.*
Options
- Same as in the OSPF Packet Header.
- Yes, it is redundant.
A series of 5 zeros (0).
I-Bit
- The Init bit.
- When set to 1, this packet is the first in the sequence of Database Description Packets.
M-Bit
- The More bit.
- When set to 1, it indicates that more Database Description Packets are to follow.
MS-Bit
- The Master/Slave bit.
- When set to 1, it indicates that the router is the master during the Database Exchange process. Otherwise, the router is the slave.
DD Sequence Number
- Used to sequence the collection of Database Description Packets.
- The initial value (indicated by the Init bit being set) should be unique. The DD sequence number then increments until the complete database description has been sent.
The rest of the packet consists of a (possibly partial (think stub, etc)) list of the link-state database's pieces. Each LSA in the database is described by its LSA header.
### Link State Request (LSR)
After exchanging Database Description packets with a neighboring router, a router may find that parts of its link-state database are out-of-date. The Link State Request packet is used to request the pieces of the neighbor's database that are more up-to-date. Multiple Link State Request packets may need to be used.
A router that sends a Link State Request packet has in mind the precise instance of the database pieces it is requesting. Each instance is defined by its LS sequence number, LS checksum, and LS age, although these fields are not specified in the Link State Request Packet itself.
```
OSPF Link State Request Packet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...header... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| * above 3 fields |
```
Each LSA requested is specified by its LS type, Link State ID, and Advertising Router. This uniquely identifies the LSA, but not its instance. Link State Request packets are understood to be requests for the most recent instance (whatever that might be).
### Link State Update (LSU)
These packets implement the flooding of LSAs.
Each Link State Update packet carries a collection of LSAs one hop further from their origin.
Several LSAs may be included in a single packet.
Link State Update packets are multicast on physical networks that support multicast/broadcast. In order to make the flooding procedure reliable, flooded LSAs are acknowledged in Link State Acknowledgment packets. *If retransmission of certain LSAs is necessary, the retransmitted LSAs are always sent directly to the neighbor.*
```
OSPF Link State Update Packet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...header... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # LSAs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- +-+
| * LSAs |
+- +-+
| ... |
```
\# LSAs
- The number of LSAs included in this update.
The body of the Link State Update packet consists of a list of LSAs (header + body/payload).
The length of each LSA type is different, so no end is outlined in the above structure.
### Link State Acknowledgement (LSAck)
To make the flooding of LSAs reliable, flooded LSAs are explicitly acknowledged. This acknowledgment is accomplished through the sending and receiving of Link State Acknowledgment packets.
Multiple LSAs can be acknowledged in a single Link State Acknowledgment packet.
Depending on the state of the sending interface and the sender of the corresponding Link State Update packet, a Link State Acknowledgment packet is sent either to the multicast address AllSPFRouters, to the multicast address AllDRouters, or as a unicast.
The format of this packet is similar to that of the Database Description packet. The body of both packets is simply a list of LSA headers.
```
OSPF Link State Acknowledgement Packet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...header... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- * an LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```
Each acknowledged LSA is described by its LSA header, as it contains all the information required to uniquely identify both the LSA and the LSA's current instance.
## EIGRP (Enhanced Interior Gateway Routing Protocol)
URL: https://adamspera.dev/routing/eigrp-enhanced-interior-gateway-routing-protocol/
# Protocol Structure
Protocol number 88.
Lives inside the payload of the Layer 3 IP field.
- *UPDATE: make my own diagram and explain better where it is and apacket structure*
![[Pasted image 20260414090437.png]]
![[Pasted image 20260414090446.png]]
# Neighborship
For a neighborship to be formed, the following must match between routers:
1. Must have the same **AS number**
2. Must have the same **K values**
3. Must have the same **authentication**
# Messages
**RTP (Reliable Transport Protocol)** is a built in message handing system to reliably deliver messages to their destinations.
- Can be modified on a per message basis to:
- Require an ACK response
- Not require an ACK response
- Used for...
- All message types!
- Hello and ACK packets DO NOT require an ACK message.
- Update, Query, and Reply DO require an ACK message
- *NOTE: This is not an actual transport mechanism like at layer 4. This is built in logic on routers for EIGRP such that it can be used to handle the EIGRP messages per Cisco's standards.*
**EIGRP Hello** (opcode 5) messages are sent via **Multicast 224.0.0.10** and use the following timers:
- **Hello** timer: **5** seconds
- **Hold** timer: **3x** hello timer (15 seconds)
**EIGRP Update** (opcode 1) messages are sent **Unicast** to neighbors when:
- When a new neighbor is discovered, the EIGRP topology is exchanged
- Partial updates are sent immediately upon topology changes like:
- Link failure
- Metric change
- New networks
**EIGRP Query** (opcode 3) messages are sent via...
- By default, queries are sent over **Multicast** 224.0.0.10.
- If a known neighbor does not respond, it will **Unicast** it to the neighbor to confirm.
- Sent when...
- Router looses its successor for a route, and has no feasible successors (aka must be recomputed by DUAL). The route then changes from Passive to Active state.
**EIGRP Reply** (opcode 4) messages are sent via **Unicast** in response to a **Query** message with the requested information.
# Classic vs Named
The primary difference between EIGRP Classic and Named mode is that Classic mode uses a fragmented configuration spread across global and interface modes, while Named mode consolidates all EIGRP settings into a single, hierarchical structure.
## Classic Mode
Uses 32-bit metrics.
```
interface GigabitEthernet0/0
ip address 192.168.1.1 255.255.255.0
ip hello-interval eigrp 1 2
ip hold-time eigrp 1 6
router eigrp 1
router-id 1.1.1.1
passive-interface GigabitEthernet0/0
network 192.168.1.0 0.0.0.255
bfd all-interfaces
no bfd interface GigabitEthernet0/0
```
The `ip hello-interval eigrp [as] [seconds]` and `ip hold-time eigrp [as] [seconds]` commands are used on an interface config level to change the timers for a specific autonomous-system.
The `router-id [ip]` command uniquely identifies a router within an EIGRP autonomous system. This ID is selected based on:
1. Manually configured.
2. Highest IP address on an active loopback interface.
3. Highest IP address on an active physical interface.
The `network [network] [wildcard]` command does the following:
- Enables EIGRP on interfaces that match the subnet.
- Therefor will advertise this subnet to neighbors.
The `passive-interface [interface]` command is used to target an interface that already has EIGRP enabled, but specifically makes it so that the interface does not participate in EIGRP in any messaging capacity. *This is used for host-only LAN interfaces like DFGWs when no EIGRP neighbors are reachable via that LAN*.
The `bfd all-interfaces` and `bfd interface [interface]` commands can be used to enable BFD for EIGRP on all or target interfaces.
You can migrate a Classic Mode configuration to Named Mode with:
```
router eigrp 1
eigrp upgrade-cli [name]
```
## Named Mode
Uses 64-bit metrics.
```
router eigrp NAME
address-family ipv4 unicast autonomous-system 1
eigrp router-id 1.1.1.1
network 192.168.1.0 0.0.0.255
af-interface default
hello-interval 2
hold-time 6
bfd
af-interface GigabitEthernet0/0
passive-interface
exit-address-family
```
The `eigrp router-id [ip]` command functions the same as in Classic mode, just slightly different syntax, with needing `eigrp` added to the front of it.
The `network [network] [wildcard]` command functions the same as in Classic mode.
The `hello-interval [seconds]` and `hold-time [seconds]` commands functions the same as in Classic mode, but are applied differently. Due to the hierarchical structure of Named mode, you can apply them under any `af-interface` whether that be default of targeted.
The `bfd` command functions the same as in Classic mode, but is applied differently. Due to the hierarchical structure of Named mode, you can apply it under any `af-interface` whether that be default of targeted.
The `passive-interface [interface]` command functions the same as in Classic mode, but is applied differently. Due to the hierarchical structure of Named mode, you can apply it under any `af-interface` whether that be default of targeted.
# Metric Calculations
## What is Delay (DLY)
This value is purely an administrative value, and DOES NOT have any affect on the interface it is configured on. The point of this value is for manual influence over path selection and metric calculation in EIGRP, IS-IS, and SR-TE.
Delay is measured in microseconds (usec).
See the below snippet of `show interface GigabitEthernet1` to see the delay value:
```
R1# show interface GigabitEthernet1
GigabitEthernet1 is up, line protocol is up
Hardware is vNIC, address is 5254.00be.f048 (bia 5254.00be.f048)
Internet address is 10.0.2.1/24
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
```
When configuring Delay on an interface, you have to configure it in *tens of microseconds*, so if you wanted a delay of 10 (default on 1g interfaces) you would configure `delay 1` on the interface:
```
R1(config)# interface GigabitEthernet1
R1(config-if)# delay 1
R1# show interface GigabitEthernet1 | include DLY
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
R1# show running-config interface GigabitEthernet1
interface GigabitEthernet1
delay 1
```
*Notice: The value in the running-config is the same as the user configures.*
## What is Bandwidth (BW)
In general networking, bandwidth is the maximum rate at which data can be transferred over a specific path or interface.
See the below snippet of `show interface GigabitEthernet1` to see the bandwidth value:
```
R1# show interface GigabitEthernet1
GigabitEthernet1 is up, line protocol is up
Hardware is vNIC, address is 5254.00be.f048 (bia 5254.00be.f048)
Internet address is 10.0.2.1/24
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
```
## Computing BW and DLY for EIGRP
When considering BW and DLY in EIGRP, you look at the **cumulative delay from ingress** and the **minimum bandwidth** along the entire path to the destination network.
For calculating Delay:
1. Find the destination route on your topology.
2. Identify every ingress interface in the path of EIGRP-enabled interfaces from the destination route (not including the interface with the IP address on it) to the router.
1. Find it's DLY value with the `show interface [interface]` command.
3. Add all of the DLY values together.
For calculating Bandwidth:
1. Identify every interface (ingress and egress) in the path of EIGRP-enabled interfaces from the destination route to the router.
2. Find the lowest BW value with the `show interface [interface]` command in Kbps.
*NOTE: Further computing will happen to these values before getting put into the formula, depending which one is used later on, but none relate to the topology.*
## What are the rest?
TODO
## K Values
In EIGRP, K values are weighting constants (multipliers) used in the composite metric formula to determine how much importance to give to different interface attributes like bandwidth, delay, load, and reliability. They act like "knobs" that can enable, disable, or scale specific components of the routing calculation.
These K variables have two kind of associated functions:
1. On/Off Logic
2. Corresponding Path Attribute
### On/Off Logic
Each K value can be set to either 0 or 1.
- If it is set to **0**, the Corresponding Path Attribute will **NOT** be used in the composite metric formula, by multiplying it by 0.
- If it is set to **1**, the Corresponding Path Attribute **WILL** be used in the composite metric formula, by multiplying it by 1.
This essentially makes it so that you can enable or disable Corresponding Path Attributes.
By default, only K1 and K3 are enabled (1).
Meaning only BW and DLY are used in the composite metric formula.
**Configuring On/Off Status**
The `metric weights [TOS] [K1] [K2] [K3] [K4] [K5]` command is used to customize the K-values On/Off status. The K1 and K3 values are 1 by default.
*NOTE: The TOS field must always be set to 0.*
```Classic
router eigrp 1
metric weights 0 1 0 1 0 1
```
```Named
router eigrp NAMED
address-family ipv4 unicast autonomous-system 1
metric weights 0 1 0 1 0 1
```
*NOTE: For a neighborship to form, the K values have to have the same K values enabled.*
### Corresponding Path Attributes
Each K value ALSO corresponds to a specific path attribute, where if On/Off will enable or disable the following:
- **K1**: Bandwidth (BW)
- **K2**: Load
- **K3**: Delay (DLY)
- **K4**: Reliability
- **K5**: Reliability scaling
- **K6**: Extended attributes (wide metric only)
These are the values that will be multiplied by either 0 or 1 depending on their On/Off status, described in the above section.
## Composite Metric Formula
### Classic Metric
Before plugging any values into the **EIGRP Classic Metric Formula**, we need to first scale the BW and DLY values such that the formula will not break due to edge cases. *Note that the router will perform this scaling automatically.*
1. Scaled BW: `10,000,000 / BW`
2. Scaled DLY: `DLY / 10`
Now that we have scaled BW and DLY, moving forward when talking about BW or DLY it means the post-scaled version.
The following are the EIGRP Classic Metric Formulas:
$$ \text{Metric} = 256 \times \left( K_1 \cdot \text{BW} + \frac{K_2 \cdot \text{BW}}{256 - \text{Load}} + K_3 \cdot \text{Delay} \right) \times \left( \frac{K_5}{K_4 + \text{Reliability}} \right) $$
EIGRP Classic Metric Formula
$$ \text{Metric} = 256 \times \left( K_1 \cdot \frac{10^7}{\text{BW}} + \frac{K_2 \cdot \frac{10^7}{\text{BW}}}{256 - \text{Load}} + K_3 \cdot \frac{\text{DLY}}{10} \right) \times \left( \frac{K_5}{K_4 + \text{Reliability}} \right) $$
EIGRP Classic Metric Formula w/ Scaling Inline
By default the K1 and K3 values are the only ones in an On state with the value of 1.
The following is what the EIGRP Classic Metric Formula equals with the default K values applies:
$$ \text{Metric} = 256 \times \left( \text{BW} + \text{Delay} \right) $$
EIGRP Classic Metric Formula w/ Default K Values Equivalence
$$ \text{Metric} = 256 \times \left( \frac{10,000,000}{\text{BW}} + \frac{\text{DLY}}{10} \right) $$
EIGRP Classic Metric Formula w/ Default K Values Equivalence w/ Scaling Inline
### Wide Metric
The Wide Metric (used in EIGRP Named Mode) introduces a 64-bit calculation to support interfaces faster than 1Gbps.
**Summary**
What is different from Classic Metric?
- The final multiplier of `256` is now `65,536`
- When scaling DLY, it's now `DLY / 1,000,000`
- Terminology changes:
- **BW** becomes **Throughput**
- **Delay** becomes **Latency**
- New K Value: K6 which is `0` by default.
- The final composite metric calculated is `/ 128` for the RIB to fit it.
$$ \text{Metric} = 65,536 \times \left( K_1 \cdot \text{Throughput} + \frac{K_2 \cdot \text{BW}}{256 - \text{Load}} + K_3 \cdot \text{Latency} + {K_6} \cdot \text{Extended} \right) \times \left( \frac{K_5}{K_4 + \text{Reliability}} \right) $$
EIGRP Wide Metric Formula
$$ \text{Metric} = 65,536 \times \left( K_1 \cdot \frac{10^7}{\text{Throughput}} + \frac{K_2 \cdot \frac{10^7}{\text{Throughput}}}{256 - \text{Load}} + K_3 \cdot \frac{\text{Latency}}{1,000,000} + K_6 \cdot \text{Extended} \right) \times \left( \frac{K_5}{K_4 + \text{Reliability}} \right) $$ EIGRP Wide Metric Formula w/ Scaling Inline
By default the K1 and K3 values are the only ones in an On state with the value of 1. The new K6 value defaults to 0. The following is what the EIGRP Wide Metric Formula equals with the default K values applied:
$$ \text{Metric} = 65,536 \times \left( \text{Throughput} + \text{Latency} \right) $$
EIGRP Wide Metric Formula w/ Default K Values Equivalence
$$ \text{Metric} = 65,536 \times \left( \frac{10,000,000}{\text{Throughput}} + \frac{\text{Latency}}{1,000,000} \right) $$
EIGRP Wide Metric Formula w/ Default K Values Equivalence w/ Scaling Inline
When using Wide mode, the final result is too long for the RIB, so before adding it it will `Metric / 128`, but will use the original for all EIGRP processes. That's the default, but the `metric rib-scale` command allows values from 1 to 255 INE, and sometimes the default of 128 isn't enough for very large metrics, causing routes to show as "FD is Infinity" in the topology table.
# Topology Concepts
## Computed Distance
Computed Distance (CD) is the full, high-precision metric the router calculates for a specific path. It is the sum of the Reported Distance (RD) (what the neighbor told you) plus the link cost to reach that neighbor.
If you look at `show ip eigrp topology`, you will see the large, uncompressed Computed Distance (CD).
## Reported Distance
The Reported Distance (RD) is the total metric to a destination network as calculated and advertised by a neighboring router.
For example: If my neighbor tells me it's Computed Distance (CD) is 36,000, then it's Reported Distance (RD) is that amount.
## Feasible Distance
Feasible Distance (FD) is a single value that represents the lowest known metric to a destination network since the last time the route was stable.
- **Neighbor B** tells you: _"It costs me **10** to get to Z."_
- The **Reported Distance** is **10**.
- **You** know the link to Neighbor B costs **5**.
- Your **Computed Distance** through B is **15** (10+5)
- If **15** is the best path you've found so far, your **Feasible Distance** becomes **15**.
In summary, the Reported Distance (RD) is the neighbors claimed Computed Distance (CD), wheres Feasible Distance (FD) is that plus you then Compute it, then if it's the best metric you have for that route, then it is a Feasible Distance (FD).
## Feasibility Condition
The EIGRP Feasibility Condition (FC) is a loop-prevention mechanism stating that a backup route (Feasible Successor) is valid only if its Reported Distance (RD) is strictly less than the current Feasible Distance (FD) of the best path (Successor).
If the Feasibility Condition is met, the route will be added to the EIGRP Topology as a Feasible Successor. The formula is as follows:
$$ \text{Reported Distance (RD} < \text{Feasible Distance (FD)} $$
EIGRP Feasibility Condition Formula
## Successor
The Successor is the neighboring router currently used for packet forwarding because it provides the least-cost path to the destination. This path has the lowest Computed Distance (CD).
## Feasible Successor
A Feasible Successor is a neighbor that acts as a pre-qualified backup route to the Successor route. Because it has already passed the Feasibility Condition, the local router knows for a mathematical certainty that this neighbor provides a loop-free path to the destination.
The primary reason for having a Feasible Successor is **Fast Convergence**.
- **Without an FS:** If the primary route (Successor) fails, the router must enter **Active state** and send QUIRY messages to all neighbors to find a new path.
- **With an FS:** If the primary route fails, the router instantly promotes the Feasible Successor to the Routing Table (RIB). The route stays **Passive**, and there is virtually zero downtime.
## What if there is no Feasible Successor?
If the primary route (**Successor**) fails and there is **no Feasible Successor** in the topology table, EIGRP cannot perform an instant cutover. Because it cannot mathematically guarantee a loop-free backup, the router must perform a formal recalculation.
### 1. Transition to "Active" State
The route transitions from a **Passive (P)** state (stable) to an **Active (A)** state. In the `show ip eigrp topology` output, you will see an **"A"** next to the route, indicating that the router is actively searching for a new path.
### 2. The Query Process
The router sends **QUERY Packets** to all its neighbors on all interfaces (except the one the failed route came from).
- **The Question:** "I lost my path to Network X. Do you have a loop-free path to it?"
- **Propagation:** If those neighbors don't have a path, they likewise go "Active" and send queries to _their_ neighbors. This ripple effect continues until the edge of the EIGRP autonomous system is reached or a router with a valid path is found.
### 3. The Reply and Convergence
Neighbors respond with **Reply Packets**.
- If a neighbor has a path, it sends the metric details (sends CD which is read as the RD).
- If a neighbor has no path, it sends an "Infinity" metric.
- **The Wait:** The original router must wait for a Reply from **every single neighbor** it queried before it can pick a new Successor and move the route back to a Passive state.
### 4. Potentially: Stuck In Active (SIA)
If a neighbor fails to respond to a Query (due to a congested link, high CPU, or a complex topology), the route becomes **Stuck In Active (SIA)**.
- By default, if a Reply isn't received within **3 minutes**, the router will kill the adjacency with the non-responsive neighbor.
*NOTE: Routers that receive a QUERY will only respond when they hear back from their own generated QUERY messages sent out.*
#### SIA Messages
If a router doesn't have a Feasible Successor, it must ask its neighbors for a path. To prevent a "waiting chain" from lasting forever or causing neighbors to crash, EIGRP uses **SIA messages** as a status check.
##### 1. The SIA Timer
When a router sends a Query, it starts a **3-minute timer** (Active Timer). If it doesn't get a response by the time this timer expires, the router assumes the neighbor is dead and kills the adjacency, which can cause unnecessary network instability.
##### 2. SIA-Query & SIA-Reply
To avoid dropping healthy neighbors that are simply waiting on _their_ own downstream queries, Cisco introduced two specific packets:
- **SIA-Query:** Sent when the Active timer is **halfway through (90 seconds)**. It essentially asks the neighbor: _"I’m still waiting for a reply, are you still working on it, or have you failed?"
- **SIA-Reply:** The neighbor responds with this to say: _"I am still alive and still searching, but I am waiting on responses from my own neighbors."_
# Authentication
EIGRP Classic mode uses MD5 keychain for authentication.
- Interface-level
EIGRP Named mode uses MD5 Keychain or SHA-256 String for authentication.
- Af-interface level
```CLASSIC
interface GigabitEthernet1
ip authentication mode eigrp 1 md5
ip authentication key-chain eigrp 1 MYCHAIN
```
```NAMED
key chain MYCHAIN
key 1
key-string CISCO
router eigrp TEST1
address-family ipv4 unicast autonomous-system 1
af-interface GigabitEthernet1
authentication mode md5
authentication key-chain MYCHAIN
```
```NAMED
router eigrp TEST1
address-family ipv4 unicast autonomous-system 1
af-interface GigabitEthernet1
authentication mode hmac-sha-256 CISCO
```
## Summarization
TODO: Add how the metric is made.
## Auto-Summary
This is a feature where a router automatically summarizes subnets to their classful network boundary (Class A, B, or C) before advertising them across different major network interfaces.
Behavior: When a router with subnets in one major network (e.g., 10.1.1.0/24) sends updates to another major network (e.g., 162.16.0.0/16), it advertises only the classful network (10.0.0.0/8) instead of the individual subnet.
```Classic
router eigrp 100
auto-summary
```
```Named
router eigrp NAMED
address-family ipv4 unicast autonomous-system 1
auto-summary
```
It is highly recommended to disable this feature if on by default. You can verify if it is enabled with the `show ip protocols` command.
### Manual Summary
```Classic
interface GigabitEthernet1
ip summary-address eigrp 1 10.1.0.0 255.255.0.0
```
```
router eigrp NAMED
address-family ipv4 unicast autonomous-system 1
af-interface GigabitEthernet1
summary-address 10.1.0.0 255.255.0.0
```
#### Null0 Route
When you configure a manual summary, EIGRP automatically creates a route to **Null0** for that summary network on the local router.
- **Purpose:** This prevents routing loops. If the router receives a packet for a specific subnet that it has summarized but no longer possesses in its routing table, the Null0 route ensures the packet is discarded (dropped) rather than sent to a default route and potentially looped back.
- **Administrative Distance:** The summary route to Null0 is assigned a default **Administrative Distance (AD) of 5**.
## Route Leaking (Leak-Map)
### Prefix-List and Route-Map
```
ip prefix-list LEAK_THESE permit 10.1.1.0/24
!
route-map MY_LEAK_MAP permit 10
match ip address prefix-list LEAK_THESE
```
### Applying with Summarization
This enabled the router to share a specific prefix route in addition to the summarization. Think 10.1.1.0/24 and 10.1.0.0/8 both being sent to the neighbor now.
```Classic
interface GigabitEthernet1
ip summary-address eigrp 1 10.1.0.0 255.255.0.0 leak-map MY_LEAK_MAP
```
```Named
router eigrp NAMED
address-family ipv4 unicast autonomous-system 1
af-interface GigabitEthernet1
summary-address 10.1.0.0 255.255.0.0 leak-map MY_LEAK_MAP
```
### Applying with Stub
A stub router normally refuses to share routes it learned from other neighbors (it won't act as a transit). If there is a route behind the stub that isn't directly "connected" but still needs to be shared, you use the `eigrp stub leak-map` command.
```Classic
router eigrp 1
eigrp stub leak-map MY_LEAK_MAP
```
```Named
router eigrp NAMED
address-family ipv4 unicast autonomous-system 1
eigrp stub leak-map MY_LEAK_MAP
```
## Route Filtering
Route filtering in EIGRP is primarily managed using **distribute-lists**. These lists act as a gatekeeper, deciding which routing updates are accepted (inbound) or advertised (outbound).
You can define your filter using three main tools, depending on how specific you need to be:
- **Standard ACLs:** Simple filtering based on the network number only.
- **Prefix Lists:** Preferred for most scenarios as they match both the network address and the specific subnet mask length.
- **Route Maps:** Used for complex filtering where you might also want to match metrics, tags, or source protocols.
> WARNING: If you use an ACL or Prefix-List there is an implicit deny at the end! You MUST permit all at the end. If not all routes besides what you explicitly permit will not be advertised.
```Classic
router eigrp 1
distribute-list prefix MY_FILTER in GigabitEthernet1
```
```
router eigrp NAMED
address-family ipv4 unicast autonomous-system 1
topology base
distribute-list prefix MY_FILTER in GigabitEthernet1
```
### Example: Standard ACL
In this example, the standard ACL is blocking the `192.168.1.0/24` route (auto-scoped to classful boundary by the ACL), and is applied in the `in` direction, meaning it will think to itself "If anyone tries to advertise 192.168.1.0/24 to me, then I will ignore it."
```
access-list 10 deny 192.168.1.0
access-list 10 permit any
router eigrp 100
distribute-list 10 in
```
### Example: Prefix-List
Best for matching both the network and the specific subnet mask length.
In this example, our goal is to block exactly 172.16.10.0/24 but allow others (like 172.16.10.0/25).
```
ip prefix-list FILTER_LIST deny 172.16.10.0/24
ip prefix-list FILTER_LIST permit 0.0.0.0/0 le 32
router eigrp NAMED
address-family ipv4 unicast autonomous-system 1
topology base
distribute-list prefix FILTER_LIST in
```
## Stub
An EIGRP stub is a router that informs its neighbors not to send it any query packets for lost routes. This is typically used in hub-and-spoke topologies where spoke routers (branches) have only one way out (the hub).
You can fine-tune what a stub router advertises using specific keywords with the `eigrp stub` command:
- **`connected`**: Advertises only directly connected networks.
- **`summary`**: Advertises only summary routes.
- **`static`**: Advertises static routes (must also be redistributed).
- **`redistributed`**: Advertises routes from other protocols.
- **`receive-only`**: Prevents the router from advertising _any_ routes; it only receives updates.
- **`leak-map`**: Allows specific routes to be "leaked" (advertised) even if they would normally be suppressed by other stub rules.
The default settings are `connected` and `summary`.
```Classic
router eigrp 1
network 10.1.1.0 0.0.0.255
eigrp stub connected summary
```
```Named
router eigrp NAMED
address-family ipv4 unicast autonomous-system 1
network 10.1.1.0 0.0.0.255
topology base
eigrp stub connected summary
```
---
# Switching
## CDP & LLDP
URL: https://adamspera.dev/switching/cdp--lldp/
## Cisco Discovery Protocol (CDP)
**CDP** is a Layer 2, media- and protocol-independent protocol used by Cisco devices to advertise and discover directly connected neighbors. It operates over interfaces that support **SNAP headers** and is **enabled by default** on most Cisco platforms.
### Key Points
- Devices send **CDP advertisements** every **60 seconds** to the **multicast MAC address** `01:00:0C:CC:CC:CC`.
- Each advertisement includes a **Time-To-Live (TTL)** value, indicating how long the information should be retained.
- CDP **never forwards** packets beyond the local segment.
- CDP supports TLVs (Type-Length-Value structures) to carry various device information.
- CDP is Cisco proprietary. Use **LLDP** for multi-vendor environments.
## CDP Configuration
```none
! Enable CDP globally
cdp run
! Disable CDP on a specific interface
interface Ethernet1/1
no cdp enable
! Adjust advertisement interval and hold time (in seconds)
cdp timer 5
cdp holdtime 10
! Disable version 2 advertisement extensions
no cdp advertise-v2
! Define a TLV filter group (use '?' to view available TLVs)
cdp tlv-list GROUP_1
?
! Apply TLV filter to restrict CDP advertisements
cdp filter-tlv-list GROUP_1
! Apply TLV filter to a specific interface
interface Ethernet1/1
cdp filter-tlv-list GROUP_1
```
---
## Link Layer Discovery Protocol (LLDP)
**LLDP** is the **IEEE standard (802.1AB)** for Layer 2 device discovery. It functions similarly to CDP but is supported across **multi-vendor** environments. It also uses TLVs for information exchange.
### Key Points
- LLDP is not enabled by default on some platforms — you must enable it globally and per interface.
- LLDP advertisements include a TTL and are **multicast** locally on each supported interface.
- LLDP supports selective TLV advertisement using `tlv-select`.
## LLDP Configuration
```none
! Enable LLDP globally
lldp run
! Disable LLDP on a specific interface
interface Ethernet1/1
no lldp enable
! Adjust advertisement interval and hold time (in seconds)
lldp timer 5
lldp holdtime 10
! View or restrict TLVs from being advertised
no lldp tlv-select ?
! Disable specific TLVs on an interface
interface Ethernet1/1
no lldp tlv-select ?
```
## L2 & L3 Maximum Transmissible Unit (MTU)
URL: https://adamspera.dev/switching/l2--l3-maximum-transmissible-unit-mtu/
When talking about L2 MTU (maximum transmissible unit), we are talking about how all frames have to be within that limit. Wheras with L3 MTU, we are talking about the entire L3 packet.
- For example if the L2 MTU is 1500B then a frame with >1500B will be dropped.
- For example if the L3 MTU is 1500B then a packet with >1500B will be fragmented.
The default L2 & L3 MTU MTU is 1500B for most Cisco platforms, but can be increased to usually around >= 9000B.
## Two Types of MTU
**L2** MTU focuses on *frames* coming into a L2 device, determining if it hits the L2 MTU threshold, then **drops** it if it does.
**L3** MTU focuses on *packets* coming into a L2 device, determining if it hits the L3 MTU threshold, then **fragments** it if it does.
## Use Cases
### L2 Example
The ethernet spec allows for a 14B header, a 1500B payload, then 4B for the CRC header. Keep in mind a bonus 4B for 802.1Q if added.
Lets take a frame like this:
| Header | 802.1Q | Payload | CRC Trailer |
| -------- | ------- | ---------- | ----------- |
| 14 Bytes | 4 Bytes | 1500 Bytes | 4 Bytes |
--> **L2 MTU applies ONLY to the PAYLOAD** <--
In this situation, all these *frames* would be allowed, but if the L2 MTU was shorted to 1000 Bytes, then the frame would be dropped.
## L3 Example
Take this example standard packet for us to use as a starting point:
| Layer | Component | Size (Bytes) |
| ----------------- | ------------------ | ----------------------------- |
| Layer 2 | Ethernet Header | 14 |
| Layer 3 | IPv4 Header | 20 |
| Layer 4 | TCP/UDP Header | 20 |
| Layer 7 | App Data (Payload) | 1460 |
| Layer 2 | CRC Trailer | 4 |
| **Total on wire** | ---> | **1518 bytes** (without VLAN) |
--> **L3 MTU applies ONLY to the IP Packet (IP + TCP/UDP + data)** <--
The **default L3 MTU of 1500 bytes** *fits within* the **L2 MTU of 1500 bytes** because:
- L2 payload = **entire L3 packet**
- So 1500 bytes of IP packet (including IP + TCP/UDP + data) fits **exactly** within Ethernet's 1500-byte payload field
## Configurations
**Switch Command Reference**
```
(config)# system mtu [bytes]
# show system mtu
```
**Router Command Reference**
```
interface Ethernet1/1
mtu [bytes]
ip mtu [bytes]
ping [ipaddress] size [bytes] {df-bit}
```
Note that L3 MTU (ip mtu) will default to matching the L2 MTU configuration, and will not show up in the show interface command.
## L2 Protection Features
URL: https://adamspera.dev/switching/l2-protection-features/
## Err-Disable Status
Cisco devices offer a built-in protection mechanism on interfaces called the Err-disable status. An interface that goes into err-disable is effectively shutdown, allowing no traffic to enter or exit, with the intent of protecting the network from whatever triggered the response.
Err-disable is a special state that can be applied to an interface by other processes. Commonly you will see ports get entered into err-disabled mode from STP BDU Guard, UDLD, Flapping, or Etherchannel Misconfig ([[STP Optional Features]]).
To clear this Err-disable state, you must enter an interface configuration mode, then run `shutdown ; no shutdown` to restore the interface.
```
errdisable detect cause [...]
errdisable recovery cause [...]
errdisable recovery interval [timer]
```
> Default errdisable recovery time is 300 seconds.
https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/69980-errdisable-recovery.html
## Storm Control
Storm Control is able to protect a network interface from receiving too much traffic relative to other traffic types.
Storm Control can limit the following types of traffic:
- **Unicast**
- **Broadcast**
- **Multicast**
- **Unknown Unicast**
You can configure Storm Control for the following metrics:
- **Percentage**
- **Megabits per second**
- **Packets per second**
Thresholds are what is used to determine how Storm Control should behave, aka start taking action or stop taking action. There are two types of thresholds, Rising and Falling.
- **Rising Threshold**: when traffic reaches the configured metric for this value (for example, if Unicast at 500 Mbps is reached) it will start taking the configured action.
- **Falling Threshold**: when traffic already has hit the Rising Threshold, action will be taken UNTIL the event falls below this configured metric.
The following actions can be taken when Storm Control is triggered:
- **"None"** -- default --> will FILTER (**Drop** Excess)
- **Shutdown** -- configurable --> will **Err-disable** (does not have to worry about Falling Threshold)
- **Trap** --configurable --> will send an **SNMP trap** (does not have to worry about Falling Threshold)
```
interface Ethernet1/1
storm-control [broadcast|unicast|multicast|unknown-unicast] level {bps|pps} [rising-level] {falling-level}
interface Etherent1/1
storm-control action [shutdown|trap]
```
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/16-12/configuration_guide/sec/b_1612_sec_9500_cg/configuring_port_based_traffic_control.html
## Etherchannel Misconfig
This feature only applies to port-channels that are using the "on" mode.
Unlike LACP, configuration mismatch protection is not enabled, so Spanning-Tree can help out.
Normally, if a port-channel is configured correctly, only one STP BPDU [[Spanning Tree Protocol (STP)]] will be expected. With Etherchannel Misconfig enabled, when spanning-tree hears that there is a BPDU getting received on a port-channel that is expecting only one, but is getting multiple, this feature gets triggered.
When triggered, Etherchannel Misconfig will place all the port-channel interfaces into Err-disabled mode.
This feature is enabled by default!
```
spanning-tree etherchannel guard misconfig
```
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9600/software/release/17-3/configuration_guide/lyr2/b_173_lyr2_9600_cg/configuring_etherchannels.html
## Link Aggregation Control Protocol (LACP)
URL: https://adamspera.dev/switching/link-aggregation-control-protocol-lacp/
## Overview
Link Aggregation Control Protocol (LACP) is a protocol that allows multiple physical links to be bundled into one logical link. LACP allows a network device to negotiate an automatic bundling of links by sending LACP packets to the peer (directly connected device that also implements LACP).
LACP is defined by the IEEE in the **802.3ad & 802.1AX** standards.
![[EtherChannelCisco.png]]
## LACP Redundancy
LACP redundancy can be controlled via max-bundle and min-link configuration options. These configurations should be considered in any Etherchannel/LACP configuration.
### Max Bundle Size
The following command allows only that number of links to be in an active state, while the extras will go into hot-standby mode.
```
interface port-channel 12
lacp max-bundle [1-15]
```
**In summary: if the port-channel has 8 links, and max-bundle = 4, then only 4 links will be active.**
### Minimum Bundle Links
If you want to set a minimum number of links for the port-channel to be active, you can use the following command to set that threshold.
```
interface port-channel 13
port-channel min-links [2-16]
```
**In summary: if the port-channel has less active links than the minimum-links configured, then port-channel will be shutdown.**
## Hot Standby
**LACP can support up to 8 active connections, with up to 16 total links**. The non-active link will be in hot-standby mode.
When a link in active mode goes down, another link in hot-standby mode will automatically fill in the active role based on its link-priority.
## LACP Priorities
> Note that for most Layer 2 protocols, including LACP, lower priorities wins the election.
### Master Election
LACP requires decision making when it comes to activating links, and that decision making falls on the LACP master device.
When the port-channel is formed, the **LACP System ID** is compared. This value is composed of the following:
- LACP Priority : System MAC
The default LACP Priority is 32768, with the range being 0-65535, with no restrictions on increments.
```
(config)# lacp system-priority [0-65535]
```
### Active Link Election
When a port-channel is formed, the LACP Port ID is compared. This value is comprised of the following:
- Port Priority : Port #
The default Port Priority is 32768, with the range being 0-65535, with no restrictions on increments.
```
interface Ethernet1/1
lacp port-priority [0-65535]
```
## LACP Signaling
LACP sends messages called LACPDUs to multicast 0180.C200.002 for messaging.
These messages are sent at two speeds (configured per interface):
- **Normal: 30 seconds** (default)
- **Fast: 1 second**
A failure is determined after 3x missed LACPDUs. This means that it will take the following amount of time to detect a failed link per speed:
- Normal: 90 seconds
- Fast: 3 seconds
```
interface Ethernet1/1
lacp rate [normal | fast]
```
> Note that this configuration is a REQUEST, meaning that if this is configured on SW1, then SW2 will start sending fast mode.
By default active links default to Slow / Normal mode, but Hot-Standby links operate at Fast rate.
- **Active: Normal**
- **Hot-Standby: Fast**
## Load Balancing
It's easy to think that a bundle of four 1Gbps links would provide a single 4Gbps connection with each link being perfectly balanced. However, load-balancing brings complexities that can create **polarization**, meaning that one link is more loaded than the rest.
### Flow Parameters
A flow is a series of packets that have the same details of the following:
- Source / Destination MAC
- Source / Destination IP
- Source / Destination Port
### Hash Allocation
When a frame needs to be sent onto an Etherchannel, the network device needs to pick a member link for the transmission.
To determine the link, configured sets of flow parameters are passed into a hash, which outputs the **result of 0-7**. This output is used to determine which port-channel links to send the traffic over.
Given the below table as an example, its easy to see why it is highly recommended to use powers of 2 for the number of links in a port-channel.
| Hash # | Hash # | Link Interfaces |
| ------ | ------ | --------------- |
| 4 | 0 | Eth1/1 |
| 5 | 1 | Eth1/2 |
| 6 | 2 | Eth1/3 |
| 7 | 3 | Eth1/4 |
Below is an example of a port-channel hash allocation that does not follow the recommended number of port-channel links:
| Hash # | Hash # | Link Interfaces |
| ------ | ------ | --------------- |
| 6 | 0 | Eth1/1 |
| 7 | 1 | Eth1/2 |
| | 2 | Eth1/3 |
| | 3 | Eth1/4 |
| | 4 | Eth1/5 |
| | 5 | Eth1/6 |
Here we can see that the allocation is imbalanced, causing flows to get hashed unevenly to certain links over others solely based off of the hash allocation.
> Based on this, the optimal number of links to use for port-channel links is 2, 4, or 8.
### Types of Hash Inputs
Now to determine which member link is chosen per each flow, you can configure what set of flow parameters are entered in.
**The default on Cisco devices is SRC-MAC, leading to polarization issues.**
For example, reference the below topology to see how using the default SRC-MAC load balancing method can create some issues:
![[PC Load Balancing SRC-MAC Issues.png]]
This is because from an End Hosts to DFGW perspective, there are lots of SRC-MAC addresses, causing even traffic distribution. BUT from the other perspective of DFGW to End Hosts, all the returning traffic is the same SRC-MAC addresses, causing polarization of all return traffic going on the same link.
To combat this, the load balancing method can be tuned to be optimal for your topology.
For most consistent and easy configuration, SRC-DST-MAC is the go-to for most campus switches.
```
(config)# port-channel load-balance [dst-ip, dst-mac, src-ip, src-mac, ...]
```
## MAC Address Table
URL: https://adamspera.dev/switching/mac-address-table/
The MAC address table contains address information that the device uses to forward traffic between ports. All MAC addresses in the address table are associated with one or more ports. The address table includes these types of addresses:
- **Dynamic** address: A source MAC address that the device learns and then ages when it is not in use.
- **Static** address: A manually entered unicast address that does not age and that is not lost when the device resets.
The address table lists the destination MAC address, the associated VLAN ID, and port number associated with the address and the type (static or dynamic).
## Aging Time
The **aging-time** for an entry is the amount of seconds that the entry is valid for, when it expires it will be dropped from the MAC address table.
The default **aging-time** is **300 seconds** which is 5 minutes.
Changing the **aging-time** with the `mac address-table aging-time [seconds] vlan [vlan]` command to a value of 0 seconds will disable MAC address aging-time all together for that VLAN. Note that it is recommended that you disable MAC address learning only in VLANs with two ports. If you disable MAC address learning on a VLAN with more than two ports, every packet entering the switch is flooded in that VLAN domain.
## Configurations
```
interface Ethernet1/1
mac-address [address]
mac address-table aging-time [seconds] vlan [vlan]
mac address-table static [address] vlan [vlan] interface [interface]
no mac address-table learning vlan [vlan]
mac address-table static [address] vlan [vlan] drop
clear mac address-table dynamic [vlan|interface|address]
```
The `drop` command enables **unicast MAC address filtering** and configure the device to drop a packet with the specified source or destination unicast static address.
## Multiple Spanning-Tree (MST)
URL: https://adamspera.dev/switching/multiple-spanning-tree-mst/
The most fundamental difference between **Multiple Spanning Tree (MST)** and **Common Spanning Tree Protocols (CSTP)** like 802.1D [[Spanning Tree Protocol (STP)]] or 802.1w [[Rapid Spanning-Tree Protocol (RSTP)]] is that **MST allows multiple VLANs to share a single spanning-tree instance**. This reduces resource usage and allows support beyond the traditional **128-instance limit** of PVST+.
## Introduction to MST
An **MST Instance (MSTI)** represents one logical spanning-tree topology — including root election, port roles, path costs, etc.
You can map **VLANs to MSTIs**, so instead of running one STP instance per VLAN (as with PVST+), MST allows you to group VLANs and run fewer STP processes overall.
> MST supports up to **66 MSTIs** per region.
When MST is enabled (`spanning-tree mode mst`), **all VLANs default to MSTI 0 (the IST)** until explicitly assigned to another instance.
> MST uses **long path cost** values by default.
---
### BPDU Flow in MST
Although MST uses **802.1w (RSTP)** [[Rapid Spanning-Tree Protocol (RSTP)]] internally, the **BPDU format** differs:
- In traditional STP/PVST+, a **BPDU is sent per VLAN** out a trunk.
- In MST, a **single untagged BPDU is sent per interface**, and it includes data for **all MSTIs** on that trunk.
---
## Basic MST Configuration
```none
spanning-tree mode mst
spanning-tree mst configuration
name CCIE
revision 1
instance 10 vlan 1-5
instance 20 vlan 6-10
exit
spanning-tree mst 10 priority 4094
spanning-tree mst hello-time 2
spanning-tree mst forward-time 15
spanning-tree mst max-age 20
interface Ethernet1/1
spanning-tree mst 10 cost 100000
```
> ⚠️ MST configuration changes take effect **only after exiting** `spanning-tree mst configuration` mode.
- Timers apply **globally** to all MST instances.
---
## MST Regions and Attributes
Each MST **region** is defined by three **region attributes**:
- **Name**
- **Revision number**
- **VLAN-to-Instance mappings**
These are hashed into a **digest**, which is carried in BPDUs. Devices with matching digests are considered in the same MST region.
> MST regions enable hierarchical STP domains. Different MST or CST domains are treated as **external** to one another.
When a BPDU is received from a device in a **different region**, the port becomes a **boundary port**.
---
## MST and STP Compatibility
### MST + CST (802.1D or 802.1w)
CST (Common Spanning Tree) is the term for legacy STP modes with a **single spanning-tree instance**.
MST is backward-compatible with CST via **MST Instance 0 (MST0)**, also called the **IST (Internal Spanning Tree)**.
- MST0 **represents the whole region** to external CST domains.
- MST sends **MST0 BPDUs** out boundary ports to communicate as if it were a single CST switch.
This design lets MST plug into an RSTP/PVST+ domain **without breaking topology**.
> MST0 = IST (Industry term), MST0 (Cisco term)
#### Master Ports in MST
If a **superior BPDU** is received on a **boundary root port**, that port becomes a **Master Port**. All other MSTIs are forced to **forward** on that port to maintain loop-free convergence.
---
### MST vs PVST+/Rapid-PVST+
Since PVST+ runs **one STP per VLAN**, and MST uses **shared topologies per instance**, the topologies don't align directly.
To ensure compatibility, MST uses a feature called **PVST Simulation**, which:
- Sends one **BPDU per VLAN** with **IST (MST0)** information.
- Can be enabled **globally or per-interface**.
```none
spanning-tree mst simulate pvst global
interface Ethernet1/1
spanning-tree mst simulate pvst
```
> If **PVST simulation is disabled** and a BPDU is received on that interface, it will enter the **STP-inconsistent (blocking)** state.
---
## PVST+ Compatibility Caveat
An MST boundary port will enter **STP_Inconsistent** if:
- The boundary port is **designated** and receives a **superior BPDU** from PVST+.
- The boundary port is **root** and receives an **inferior BPDU** compared to **VLAN 1**.
This commonly happens when **VLAN root priorities differ** slightly.
> Best practice: ensure **VLAN 1 has the lowest priority** in PVST+ to avoid STP inconsistency on MST boundaries.
### Correct PVST+ Interop Configuration
Ensure MST0 connects to a PVST+ domain where:
- **All PVST VLAN roots have higher priority values than VLAN 1.**
- MST0 ports receive **superior BPDUs only from VLAN 1**.
Example:
```none
MST-IST# show running-config interface g0/0
interface GigabitEthernet0/0
switchport trunk allowed vlan 1-5
switchport trunk encapsulation dot1q
switchport trunk native vlan 100
switchport mode trunk
switchport nonegotiate
negotiation auto
RSTP-1-5# show running-config interface g0/0
interface GigabitEthernet0/0
switchport trunk allowed vlan 1-5
switchport trunk encapsulation dot1q
switchport trunk native vlan 100
switchport mode trunk
switchport nonegotiate
negotiation auto
```
```none
MST-IST# show spanning-tree bridge
Hello Max Fwd
MST Instance Bridge ID Time Age Dly Protocol
---------------- --------------------------------- ----- --- --- --------
MST0 32768 (32768, 0) 5254.008d.40a5 2 20 15 mstp
RSTP-1-5# show spanning-tree bridge
Hello Max Fwd
VLAN Bridge ID Time Age Dly Protocol
---------------- --------------------------------- ----- --- --- --------
VLAN0001 4097 ( 4096, 1) 5254.00a8.57cd 2 20 15 rstp
VLAN0002 2 ( 0, 2) 5254.00a8.57cd 2 20 15 rstp
VLAN0003 3 ( 0, 3) 5254.00a8.57cd 2 20 15 rstp
VLAN0004 4 ( 0, 4) 5254.00a8.57cd 2 20 15 rstp
VLAN0005 5 ( 0, 5) 5254.00a8.57cd 2 20 15 rstp
```
[CBT Nuggets - STP Compatibility Tutorial](https://learn.adept.at/cbtnuggets/layer-2-ccie-training-vlan-etherchannel-stp-tutorial/skill/configure-stp-compatibility#component-9d7c5)
## Rapid Spanning-Tree Protocol (RSTP)
URL: https://adamspera.dev/switching/rapid-spanning-tree-protocol-rstp/
802.1w Rapid Spanning-Tree (RSTP or RST) is an evolution of the original 802.1D [[Spanning Tree Protocol (STP)]] which aims to modernize the protocol by speeding up convergence to be nearly instantaneous. However, RSTP accomplishes this without changing any of the timers in the environment.
```
(config)# spanning-tree mode rapid-pvst
```
>When using RSTP, switches will self-generate BPDUs, rather than waiting for a superior BPDU from upstream to forward it. These generations occur every time the hello timer is reached, or immediately on reception of a superior BPDU.
## Negotiations
When a link comes online in RSTP, it is entered into a SYNC state.
The process of a SYNC state is as follows:
1. Link comes online.
2. BPDUs are sent to each-other (one is superior).
3. After this transaction, one device knows it has the superior BPDU.
4. The superior switch then sends another BPDU with the **Proposal flag**.
5. When the other switch receives this **Proposal flag**, it responds by sending a BPDU upstream with an **Acceptance flag**.
6. Both ports have now completed the SYNC process and transition directly to their intended state, skipping the Learning state.
This negotiation process works because RSTP assumes all links are point-to-point by default. The following command will specify for a link that there is a hub in between:
```
(config-if)# spanning-tree link-type shared
```
Links that are of type shared operate as if it were a normal 802.1D link, waiting for timers to establish its port state. (Although note that in RSTP the port states are different!)
### New Root Bridge
When a Superior BPDU in a new location, that signals that the topology has changed.
The following steps occur in this scenario:
1. A converged switch receives a superior BPDU with the **Proposal** flag.
2. The switch transitions all ports to a **Discarding** or BLK state.
3. All interfaces on the switch then enter the SYNC state.
> The end of this process triggers the start of this process on downstream devices!
### Indirect Failures
In RSTP, if a BPDU is missed for 3 hello times, then the BPDU is expired. By default, this is 6 seconds, rather than how it would be 20 seconds in 802.1D spanning-tree.
Max Age is still used for when a interface is a Shared link type.
## BPDUv2 Format
To support these new link states and the SYNC process, RSTP utilizes a new kind of BPDU standard: **BPDUv2** which supports the following:
- New Flag: Proposal
- New Flag: Acceptance
- Port States
- Incompatible with 802.1D
## Port States
There are only three port states in RSTP that correspond to the three possible operational states. The 802.1D disabled, blocking, and listening states are merged into a unique 802.1w discarding state.
| STP Port State | RSTP Port State | Is Port Included in Active Topology? | Is Port Learning MAC Addresses? |
| -------------- | --------------- | ------------------------------------ | ------------------------------- |
| Disabled | Discarding | No | No |
| Blocking | Discarding | No | No |
| Listening | Discarding | Yes | No |
| Learning | Learning | Yes | Yes |
| Forwarding | Forwarding | Yes | Yes |
In summary, the 802.1w RSTP process uses the following states:
- Discarding
- Learning
- Forwarding
> The new Learning state will use the forward-time as its timer. This means that ports in the Learning state will last for 15 seconds by default before transitioning to Forwarding/Discarding.
### Alternate and Backup Ports
These two port roles correspond to the blocking state of 802.1D. A blocked port is defined as not being the designated or root port. A blocked port receives a more useful BPDU than the one it sends out on its segment. Remember that a port needs to receive BPDUs in order to stay blocked. RSTP introduces these two roles for this purpose.
An alternate port receives more useful BPDUs from another bridge and is a port blocked. This is shown in this diagram:
![[AlternatePort.png]]
A backup port receives more useful BPDUs from the same bridge it is on and is a port blocked. This is shown in this diagram:
![[_images/BackupPort.png]]
## Topology Change Notifications
When a port state change via a Blocked port transitioning to a Forwarding state, a topology change is triggered.
The following process occurs when a topology change is triggered:
1. A **non-edge** port state changes from **BLK -> FWD**.
2. The detecting bridge **flushes its MAC address table** except on the interface that received the TCN.
3. For **twice the hello-timer**, the detecting bridge generates **Configuration BPDUs** with the **TNC bit set**, out all interfaces.
When a neighboring bridge receives the TCN notification, it begins the process from step 2.
## Resources
Cisco Whitepaper: https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/24062-146.html
## Spanning Tree Protocol (STP)
URL: https://adamspera.dev/switching/spanning-tree-protocol-stp/
For an intro to 802.1D Spanning-Tree, checkout [CertBros Explanation](https://www.youtube.com/watch?v=japdEY1UKe4&t=218s) for an excellent conceptual start.
> Remember, like most Layer 2 protocols, **LOWER** values are better!
Keep in mind that 802.1D Spanning-Tree is only ever implemented on modern network switches using PVST+. This enhancements allows a spanning-tree instance to run per VLAN. This means that each VLAN has its own spanning-tree process and topology-- but devices can only handle up to 128 instances.
Most of this document is focused on PVST+ spanning-tree operation, with a section for Rapid-PVST+ for [[Rapid Spanning-Tree Protocol (RSTP)]] operations at the end. A separate document will be made for [[Multiple Spanning-Tree (MST)]].
### BPDUs and Costs
BPDUs are special Layer 2 messages forwarded by switches downstream to share STP information. These messages are used to:
- Elect the **Root Bridge**
- Determine the **best path** to the Root
- Prevent **loops** by defining port roles
There are two main types:
| Type | Description |
| -------------------------------------- | --------------------------------------------------- |
| **Configuration** | Used in standard STP for root election and updates. |
| **Topology Change Notification (TCN)** | Alerts the network of a topology change. |
The "best path" is what is called a Path Cost, or a **Root Cost**.
1. Each switch **adds its the receiving ports cost** to the cost received in a BPDU.
1. For example, if a non-root switch receives a BPDU from the root bridge with a cost of 0, it will then look at the received interfaces bandwidth, and add that equivalency value to the root cost when forwarding it downstream.
2. It then **forwards** the BPDU with the **updated root cost** to other switches.
3. Each switch uses this info to:
- Choose the **Root Port** (best path to Root Bridge)
- Elect **Designated Ports** on each segment
**Port Cost** is a numerical value assigned to each interface based on its **bandwidth**, used by STP to select the *lowest-cost path to the Root Bridge*.
There are **two path cost calculation methods**:
| Link Bandwidth | (Short) Cost | (Long) Cost |
| -------------- | ------------ | ----------- |
| 10 Mbps | 100 | 2,000,000 |
| 100 Mbps | 19 | 200,000 |
| 1 Gbps | 4 | 20,000 |
| 10 Gbps | 2 | 2,000 |
| 100 Gbps | N/A | 200 |
| 1 Tbps | N/A | 20 |
### Configuring Costs
Use the following configuration to use the Long port costs:
```
spanning-tree pathcost method long
```
Use the following configuration to custom configure a port cost for an interface:
```
spanning-tree cost <1-200000000>
spanning-tree vlan 1 cost <1-200000000>
```
**Note**: if you do not specify which VLAN, it will apply to all VLANs on that interface.
## Root Bridge Election
Devices running STP will first negotiate and determine who the Root Bridge is in the network. To do this, they perform the following steps:
1. **All switches assume they are the Root Bridge** initially. Each switch sends out BPDUs containing its own **Bridge ID** (`Bridge Priority (default is 32768) + VLAN ID + ":" + MAC Address`).
2. As switches receive BPDUs from other switches, they compare them to their **current best-known BPDU** (themselves if first received). If a switch receives a superior BPDU (one with a lower Bridge ID), it stops claiming to be root and **forwards that superior BPDU** instead. *Note that when forwarding it alters values like root costs etc.*
3. Eventually, all switches agree on the same root bridge, the switch with the **lowest Bridge ID**.
For example, in the following topology, SW2 has the **lowest MAC address**, which is appended to the Bridge Priority, so it becomes the **Root Bridge**.
| Switch | Priority | MAC Address | Bridge ID |
| ------ | -------- | ----------------- | ---------------------------- |
| SW1 | 32768 | 00:11:22:33:44:03 | 32768.00:11:22:33:44:03 |
| SW2 | 32768 | 00:11:22:33:44:01 | 32768.00:11:22:33:44:01 ← 🏆 |
| SW3 | 32768 | 00:11:22:33:44:02 | 32768.00:11:22:33:44:02 |
### Configuring the Root Bridge
Spanning-tree priority values can only be configured in **increments of 4096**. Making its configurable range to be `0-61440`.
```
(config)#spanning-tree vlan 1 priority ?
% Bridge Priority must be in increments of 4096.
% Allowed values are:
0 4096 8192 12288 16384 20480 24576 28672
32768 36864 40960 45056 49152 53248 57344 61440
```
There are three ways to configure a devices spanning-tree priority:
```
(config)# spanning-tree vlan 1 priority 4096
(config)# spanning-tree vlan 1 root primary
(config)# spanning-tree vlan 1 root secondary
```
The command that uses `root primary` will take the current **known Root Bridge's priority**, and set its *own* priority to TWO intervals less than, so: `mypriority - 8192`.
The command that uses `root secondary` will take the current **known Root Bridge's priority**, and set its *own* priority to ONE intervals less than, so: `mypiority - 4096`.
## Port Elections
All ports on the **Root Bridge** are **Designated** ports (forwarding state).
Each remaining switch will select ONE of its interfaces to be its **Root Port** (forwarding state).
### Selection: Root Ports
The **Root Port Selection** process is as follows:
1. Lowest **Root Cost**
- *BUT* what if they have the same *Root Cost*?
2. Lowest neighbor **Bridge ID**
- *BUT* what if they have the the *Bridge ID* (two ports to the same switch)?
3. Lowest neighbor **Port ID**
- The Port ID is a value assigned to all ports, with a numerical value per port as the decimal: `Port Priority (128) + "." + Port Number`.
### Selection: Blocking Ports
Each remaining collision domain will select ONE interface to be a **Designated Port** (forwarding state). The other port in the collision domain will be Blocking (**non-designated).
The **Blocking Selection** process is as follows:
1. **LOCAL** interface with **lowest Root Cost** - becomes **Designated** and the neighbor **Blocks**.
- *BUT* what if its a tie?
2. **LOCAL** switch with the **lowest Bridge ID** - becomes **Designated** and the neighbor **Blocks**.
Below is an excellent example of this election process from [Jeremy's IT Lab - Part 1](https://www.youtube.com/watch?v=j-bK-EFt9cY&t=699s) (30 minutes in).
![[JeremySTP-P1.png]]
## Understanding Timers
The general flow of an 802.1D STP environment in terms of timers is as follows:
1. **Failure Occurs**
2. **Max Age (20s)** — Wait to detect failure.
3. **Forward Delay (15s)** — Listening...
4. **Forward Delay (15s)** — Learning...
5. **Port becomes Forwarding**
| Timer | Default | Used By |
| ------------- | ---------- | -------------------- |
| Hello | 2 seconds | Root Bridge |
| Forward Delay | 15 seconds | All Bridges |
| Max Age | 20 seconds | All Non-Root Bridges |
```
! STP & RSTP
(config)# spanning-tree vlan 1 hello-time <1-10>
(config)# spanning-tree vlan 1 max-age <6-40>
(config)# spanning-tree vlan 1 forward-time <4-30>
! RSTP
(config)# spanning-tree mode rapid-pvst
(config)# interface Ethernet1/1
(config-if)# spanning-tree link-type point-to-point
```
## Resources
[CertBros Explanation](https://www.youtube.com/watch?v=japdEY1UKe4&t=218s)
[CBT Micro-Nugget](https://www.youtube.com/watch?v=mxCPdB7aWtY)
[Jeremy's IT Lab - Part 1](https://www.youtube.com/watch?v=j-bK-EFt9cY&t=699s)
[Jeremy's IT Lab - Part 2](https://www.youtube.com/watch?v=nWpldCc8msY&t=2280s)
[Jeremy's IT Lab - Algorithm](https://www.youtube.com/watch?v=FcrTb43AkhI)
[Jeremy's IT Lab - Analyzing](https://www.youtube.com/watch?v=Ev9gy7B5hx0&t=17s)
[CBT Nuggets - CCIE L2](https://learn.adept.at/cbtnuggets/layer-2-ccie-training-vlan-etherchannel-stp-tutorial)
[Cisco Press STP Whitepaper](https://www.ciscopress.com/articles/article.asp?p=2832407&seqNum=4)
[INE Course - Switched Campus](https://my.ine.com/Networking/courses/3473abc7/switched-campus)
[Kevin Wallace - Deep Dive](https://www.youtube.com/watch?v=XoLPGH4awKc)
## STP Optional Features
URL: https://adamspera.dev/switching/stp-optional-features/
## Topology Protection Features
### PortFast
**PortFast** is an optional [[Spanning Tree Protocol (STP)]] feature that lets access ports bypass the usual STP states (Listening → Learning → Forwarding) and immediately enter the **Forwarding** state. This is ideal for ports that connect directly to end devices (like PCs or printers), where there’s no risk of loops.
> NOTE: When a Portfast enabled port receives a BPDU, it operates as a normal STP port, without Portfast.
Use the following commands to enable PortFast on a specified interface:
```
(config)# interface FastEthernet0/1
(config-if)# spanning-tree portfast
```
> ⚠️ Use only on access ports connected to end devices.
Use the following command to configure PortFast for **all access ports** on the switch:
```
(config)# spanning-tree portfast default
```
In some cases (like connecting to servers that use trunking), you may want to enable PortFast on a **trunk port**:
```
(config)# interface GigabitEthernet0/1
(config-if)# switchport mode trunk
(config-if)# spanning-tree portfast trunk
```
### BPDU Guard
BPDU Guard **shuts down** a port **immediately** if it **receives a BPDU**.
If a PortFast-enabled port (which is supposed to connect to a host, not another switch) sees a BPDU, something is wrong, likely:
- Someone connected a switch or hub to the port
- Someone bridged two ports using a cable
- A misconfiguration exists in your topology
Instead of allowing a potential loop, BPDU Guard will **err-disable** the port as a precaution.
Use the following commands to configure BPDU Guard on a specified interface:
```
(config)# interface FastEthernet0/1
(config-if)# spanning-tree bpduguard enable
```
Use the following commands to configure BPDU Guard globally on **all PortFast-enabled interfaces**:
```
(config)# spanning-tree portfast bpduguard default
```
OPTIONAL: Use the following commands to setup auto recovery from errdiable for BPDU Guard:
```
(config)# errdisable recovery cause bpduguard
(config)# errdisable recovery interval 30
```
### Root Guard
When you place Root Guard on a port, you're saying:
> “I trust the current Root Bridge — I don’t want anything **on this port** trying to become root.”
If a switch connected to that port starts sending **superior BPDUs** (with a lower Bridge ID), the port is **put into Root-Inconsistent (broken)** state. Note that this port will recover automatically when superior BPDUs are no longer being received.
Root Guard is ideally used for:
- Downlinks (ports facing down at other switches (uplinks from their perspective))
- Designated Ports (downstream ports)
Use the following commands to configure Root Guard on a specified interface:
```
(config)# interface GigabitEthernet0/1
(config-if)# spanning-tree guard root
```
### BPDU Filter
There are **two modes** depending on how you configure it:
BPDU filter can be configured **globally** or on the **interface** **level,** and there’s a difference:
- **Global** (soft): Outbound BPDUs are filtered (not sent) on Portfast interfaces. Due to the global configuration mode (soft) it only applies to Portfast. Since BPDU FIlter soft mode still receives BPDUs, this will cause Portfast to disable itself and BPDU Filter, returning to default STP operation.
- **Interface** (hard): Outbound & Inbound BPDUs are filtered (not sent or received). This essentially disables spanning-tree. This type of BPDU Filter is highly dangerous.
1. **Global BPDU Filter (Soft Mode)**
```
(config)# spanning-tree portfast bpdufilter default
```
2. **Per-Interface BPDU Filter (Hard Mode)**
```
(config)# interface FastEthernet0/1
(config-if)# spanning-tree bpdufilter enable
```
## Loop Protection Mechanisms
### UDLD
**Unidirectional Link Detection** is a mechanism for detecting duplex failures on links, commonly found on fiber cables. From a layer 1 perspective, fiber consists of a pair of strands, one for transmit, and one for receive. If one of these is broken, spanning-tree can get confused.
> This feature is Cisco proprietary.
UDLD must be configured on both sides of the link to operate.
This is because UDLD uses an echo mechanism, where it will send a message across the link, then the receiving devices takes it and throws it back to the sender. UDLD must be enabled on both sides for this operation can occur.
**Timers**
- Sends echo messages every **15 seconds by default**.
- The **holdtime is 3 times** the message time by default.
This totals to detecting an issue in 45 seconds.
UDLD has two modes of operation:
- **Normal**
- Detect the issue.
- Places the port into an "**undetermined**" state, continuing to forward traffic.
- **Aggressive**
- Detect the issue.
- Sends 1 echo per second for 8 seconds.
- Place the port into an **errdisabled** state, continuing to forward traffic.
To enable UDLD globally on all interfaces, use the following command:
```
(config) udld [enable | aggressive]
```
> Note that when you enable Aggressive mode globally, it only applies to Fiber interfaces.
To enable UDLD on an interface specifically, use the following command:
```
(config-if) udld port {aggressive}
```
To configure UDLDs custom recovery mechanism, use the following commands:
```
(config) udld recovery
(config) udld recovery interval [seconds]
```
### Loop Guard
While UDLD detects physical layer 1 issues, what if there is no layer 1 issue, but we are still seeing duplex issues (software issues)?
Normally, if a switch stops receiving BPDUs on a **blocking port**, it will wait the max age timer, then move to forwarding eventually, even if the link is still functional, but for some reason, is not getting BPDUs.
When an interface configured with **Loop Guard** is in a Blocking state stops receiving BPDUs, it will move the blocking port to a **loop-inconsistent** state instead of unblocking, until BPDUs are getting received again on the interface.
> Loop Guard is typically applied on ** Root & Alternate (Blocking)** ports.
> Loop Guard is **ignored** on designated (forwarding) ports.
Use the following commands to configure Loop guard on a specified interface:
```
(config)# interface GigabitEthernet0/2
(config-if)# spanning-tree guard loop
```
Use the following commands to configure Loop Guard **globally for all interfaces**:
```
(config)# spanning-tree loopguard default
```
### Bridge Assurance
This process actually changes how STP works, in that it will have a switch send its BPDUs upstream as well. This means that unlike in normal STP operation, inferior BPDUs will be flowing upstream in a point-to-point fashion (not getting flooded).
Interfaces with Bridge Assurance enabled (should only be point-to-point links between switches) will enter a nerrdisable state if BPDUs are no longer being received.
>Bridge Assurance is only supported on Rapid PVST+ [[Rapid Spanning-Tree Protocol (RSTP)]] and MST [[Multiple Spanning-Tree (MST)]].
```
(config)# spanning-tree mode [rapid-pvst | mst]
(config)# spanning-tree bridge assurance
! The above command enables Bridge Assurance on the bridge.
(config)# interface Ethernet1/1
(config-if)# spanning-tree portfast type network
```
## Resources
[Jeremy's IT Lab - Part 2](https://www.youtube.com/watch?v=nWpldCc8msY&t=2280s)
[Cisco Press STP Whitepaper](https://www.ciscopress.com/articles/article.asp?p=2832407&seqNum=4)
[INE Course - Switched Campus](https://my.ine.com/Networking/courses/3473abc7/switched-campus)
## Virtual LAN (VLAN)
URL: https://adamspera.dev/switching/virtual-lan-vlan/
## VLAN Creation
When you create a VLAN, it gets added to either:
- the **VLAN database** (`vlan.dat` in bootflash)
- or the **running-config** (for extended VLANs)
### Normal VLANs (1–1005)
- Stored in `vlan.dat`
- Not saved in `running-config`
- Persist through reload if `vlan.dat` is present
### Extended VLANs (1006–4094)
- Stored in `running-config`
- Saved to **NVRAM** on `write mem`
- Used for **internal VLANs**, routed ports, etc.
```none
(config)# vlan 10
```
### What Happens Internally?
When a VLAN is created, the switch instantiates:
- A [[Spanning Tree Protocol (STP)]] instance.
- An entry in the [[MAC Address Table]].
You can verify with:
```none
show spanning-tree vlan 10
show mac address-table vlan 10
```
---
## Access vs Trunk Ports
### Access Ports
```none
interface FastEthernet1/0/2
switchport mode access
switchport access vlan 30
```
- Forwards only VLAN 30
- Drops all tagged traffic (except [[CDP & LLDP]])
- Can use voice VLAN if configured
### Trunk Ports
```none
interface GigabitEthernet1/0/24
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk native vlan 99
switchport trunk allowed vlan 1-50
```
- Carries **multiple VLANs**
- Tags all VLANs **except** the **native VLAN** (in this case, 99)
- When untagged traffic is received on a trunk port, it is considered to be a part of the native VLAN (defaults to 1).
- Ideal for switch uplinks and routed links
**Tune trunks with the following:**
```
interface GigabitEthernet1/0/24
switchport trunk allowed vlan allowed 1-50
switchport trunk allowed vlan remove 1-5
switchport trunk allowed vlan add 1-5
```
---
## Internal VLANs
If you apply `no switchport` on a Layer 2 interface, the switch **allocates an internal VLAN** behind the scenes. This is required to bind Layer 3 interfaces to the switching backend.
```none
interface Ethernet1/1
no switchport
```
This **allocates a VLAN** from the **extended range (1006–4094)**.
By default, internal VLANs are assigned **in ascending order** starting at **1006**, but you can reverse it:
```none
vlan internal allocation policy descending
```
**Verify with:**
```none
show running-config | include internal
show vlan internal usage
VLAN Usage
---- --------------------
1006 GigabitEthernet0/0
4094 GigabitEthernet0/1
```
> Note: In this example, `descending` mode was applied after some internal VLANs were already allocated, which is why you see both high and low VLANs being used.
---
## Voice VLANs
Voice VLANs help IP phones (like Cisco VoIP phones) get placed into the correct VLAN using **CDP** advertisements. These phones often have built-in switches, allowing a PC to daisy-chain through them.
There are multiple ways to design this, depending on how **voice and data** traffic should behave.
### Option 1: Voice and Data on Same VLAN
```none
interface FastEthernet1/0/1
switchport mode access
switchport access vlan 10
```
Everything (PC + phone) goes on VLAN 10 — no voice isolation or QoS differentiation.
---
### Option 2: Separate Voice and Data VLANs
```none
interface FastEthernet1/0/1
switchport mode access
switchport access vlan 10
switchport voice vlan 20
```
- PC is untagged on VLAN 10
- Phone tags voice frames as VLAN 20
Clean separation, better for QoS and security.
---
### Option 3: Same VLAN, But QoS via Dot1p
Let’s say you want PC and phone on the same VLAN but **still prioritize voice** traffic.
```none
interface FastEthernet1/0/1
switchport mode access
switchport access vlan 10
switchport voice vlan dot1p
```
In this case:
- PC sends **untagged** frames on VLAN 10
- Phone sends **tagged frames** with VLAN ID **0**, but with CoS = 5
- Switch reclassifies VLAN 0 → VLAN 10 internally, but **preserves QoS**
---
## Commands Reference
| Action | Command |
| ---------------------------------- | --------------------------------------------------------- |
| Create VLAN | `vlan [ID]` |
| Assign VLAN to Access Port | `switchport access vlan [ID]` |
| Enable Voice VLAN | `switchport voice vlan [ID]` |
| Enable Dot1p Voice | `switchport voice vlan dot1p` |
| Set Internal VLAN Allocation Order | `vlan internal allocation policy [ascending\|descending]` |
| Make Port Routed | `no switchport` |
| Show Internal VLAN Usage | `show vlan internal usage` |
| Show VLAN Config | `show vlan brief` |
## Virtual Port Channels (vPC)
URL: https://adamspera.dev/switching/virtual-port-channels-vpc/
## Overview
Two Cisco Nexus switches utilizing vPC appear as a single logical Layer 2 switch to other downstream network devices. Despite this, the two switches continue to be separately managed entities with distinct management and control planes.
Benefits of vPC includes:
- Enables utilization of port channel spanning two upstream devices
- Removes STP ports
- Establishes a topology free of loops
- Utilizes the full uplink bandwidth available
- Ensures quick convergence in case of link or device failure
- Offers resilience at the link level
- Contributes to high availability
## Components
![[vPCTopologyExplination.png]]
**vPC**: Allows a downstream device to connect to two vPC peers as if they were a single switch, using either a static or LACP-negotiated port channel. vPC is a multi chassis EtherChannel (MEC) technology.
**vPC Peers**: In vPC architecture, two Cisco Nexus switches form a duo, functioning together as one logical switch.
**vPC Peer Link**: Essential for vPC operation, this link connects two vPC switches, simulating a single control plane. It forwards specific protocol packets, synchronizes MAC tables and IGMP entries, handles multicast and orphaned port traffic, and carries HSRP packets in Layer 3 switches.
**vPC Peer Keepalive Link**: A logical, often out-of-band link, this serves as a secondary test to verify remote peer functionality in vPCs. It transmits only operational status IP packets and helps determine peer status when the main link fails.
**vPC Domain**: This encompasses the vPC peers, keepalive and peer links, and all connected port channels. Each vPC domain is uniquely identified by a numerical ID, and only one ID is permitted per device.
**vPC Member Port**: A port on a vPC peer, part of a configured vPC.
**Orphan Device**: A device connected to a vPC domain using regular links instead of a vPC.
**Orphan Port**: A port connected to an orphan device, or a vPC port connected to only one vPC peer, usually due to a lost connection on the other peer.
**Cisco Fabric Services (CFS)**: This protocol enables fast, reliable configuration messaging and synchronization between vPC peers. It ensures MAC addresses and other data are consistent across both switches, operates over the peer link without user configuration, and incorporates modified spanning tree to maintain continuous operation.
Cisco Fabric Services (CFS) performs the following operations, as the primary control plane functions over the vPC Peer Link:
- Aligns MAC address table entries
- Aligns entries of the Internet Group Management Protocol (IGMP) snooping
- Shares crucial configuration details to maintain configuration uniformity between the vPC peer switches
- Monitors the vPC status on the peer
- Aligns ARP tables (applicable for Layer 3 vPC peers)
> Traffic sent over the vPC Peer Link is tagged with a special header, telling its peer NOT to forward it out of any of its vPC ports.
## Configurations
Configuring a vPC setup includes the following steps:
1. Activate the vPC feature.
2. Establish a vPC domain and enter into vpc-domain mode.
3. Set up the vPC peer keepalive link between switches.
(Optional) Set the system priority.
(Optional) Define the vPC role priority.
4. Establish the vPC peer link.
5. Transition the PortChannel to vPC.
![[vPCTopologyCML.png]]
```
# N9-1
!
feature vpc
!
vpc domain 100
peer-keepalive destination 1.1.1.2 source 1.1.1.1 vrf Management
!
interface Mgmt0
description vPC Keepalive
ip address 1.1.1.1/24
!
interface Ethernet1/1
description vPC Peer-Link Member
switchport mode trunk
channel-group 1 mode on
!
interface Ethernet1/2
description vPC Peer-Link Member
switchport mode trunk
channel-group 1 mode on
!
interface Ethernet1/3
description vPC Channel Member
switchport mode trunk
channel-group 10 mode active
!
interface port-channel 1
description Peer-Link Interfaces
vpc peer-link
!
interface port-channel 10
description vPC Channel
vpc 10
```
```
# N9-2
!
feature vpc
!
vpc domain 100
peer-keepalive destination 1.1.1.1 source 1.1.1.2 vrf Management
!
interface Mgmt0
description vPC Keepalive
ip address 1.1.1.2/24
!
interface Ethernet1/1
description vPC Peer-Link Member
switchport mode trunk
channel-group 1 mode on
!
interface Ethernet1/2
description vPC Peer-Link Member
switchport mode trunk
channel-group 1 mode on
!
interface Ethernet1/3
description vPC Channel Member
switchport mode trunk
channel-group 10 mode active
!
interface port-channel 1
description Peer-Link Interfaces
vpc peer-link
!
interface port-channel 10
description vPC Channel
vpc 10
```
The vPC domain ID is a numerical value between 1 and 1000 that identifies the vPC switch duo. (The code snippet uses 10)
Port channel 2, which connects to the downstream device, is transitioned to vPC mode. This port channel must be linked to the port channel on the other vPC switch by assigning the same vPC number to its port channel interface. The vPC port number, unique within the vPC domain, must be the same on both peer switches.
## vPC Guidelines
A vPC peer link should be composed of Ethernet ports with a minimum interface speed of 10 Gbps. It's advisable to utilize a minimum of two 10-Gigabit Ethernet ports in dedicated mode, spread across two distinct I/O modules.
The vPC keepalive heartbeat should not go across the vPC peer link.
A vPC domain comprises a pair of switches recognized by a common vPC domain ID. It's not possible to incorporate more than two switches or VDCs into a vPC domain.
## Additional Features
### vPC Peer-Gateway
The vPC Peer-Gateway enhancement permits a vPC peer device to function as the active gateway for packets directed to the router MAC of the other peer device. This feature facilitates local forwarding of packets, aimed at the other peer device, without requiring to traverse the vPC peer link.
The Peer-Gateway feature enables vPC to interoperate with certain network-attached storage (NAS) devices or load balancers. These devices may possess optimization features that allow them to bypass a typical default gateway ARP request.
![[vPCTopologyLogical.png]]
In the diagram, PEER-A serves as the default gateway in VLAN10. However, due to NAS's non-standard packet forwarding, it might use PEER-B's MAC2 as the destination MAC address to reach the IP gateway. The ACC-A switch receives this packet, hashes it, and decides to forward it through the port towards PEER-A. With peer-gateway enabled, PEER-A will normally route the packets and will not send them over the vPC peer link.
When the vPC peer-gateway functionality is enabled, each vPC peer device locally duplicates the MAC address of the interface VLAN defined on the other vPC peer device with the G flag (Gateway flag). In the diagram, PEER-A will program MAC2 (the MAC address of interface VLAN 10) in its MAC table and set the G flag for this MAC address. PEER-B will do the same for MAC1.
```
vpc domain 10
peer-gateway
```
> Configure both vPC peer devices with this command.
### vPC Peer-Switch
The vPC peer-switch functionality enables a pair of vPC peer devices to present themselves as a single STP root in the Layer 2 topology (they share the same bridge ID). To become operational, the vPC peer-switch must be configured on both vPC peer devices using the peer-switch command.
![[vPCTopologyPeerSwitch.png]]
```
vpc domain 10
peer-switch
```
The primary benefit of the vPC peer-switch feature is its enhancement of convergence time during vPC primary peer device failure/recovery. These up/down events don't trigger any STP recalculations, thus reducing traffic disruption to sub second values.
This feature also streamlines the STP configuration by removing the necessity to pin the STP root to the vPC primary switch.
### vPC Auto-Recovery
The primary benefit of the vPC peer-switch feature is its enhancement of convergence time during vPC primary peer device failure/recovery. These up/down events don't trigger any STP recalculations, thus reducing traffic disruption to sub second values.
This feature also streamlines the STP configuration by removing the necessity to pin the STP root to the vPC primary switch.
```
vpc domain 10
auto-recovery reload-delay 60
```
---
# Services
## Conditional Debugger
URL: https://adamspera.dev/services/conditional-debugger/
**Conditional debugging** is used to filter debug output so you only see messages related to a specific interface, IP address, MAC address, VLAN, or other criteria. This is extremely useful on busy routers where full debug output would overwhelm the console or terminal buffer.
Instead of enabling all debug output for a protocol, you can **limit output to just what you care about**.
## Example Use Case
### Problem
If you enable `debug ip rip`, the router shows RIP updates on **all** interfaces.
```none
R1#debug ip rip
RIP protocol debugging is on
```
Example output:
```none
RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (192.168.12.1)
RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (192.168.13.1)
```
### Add a Debug Condition
You can limit debug output to only a specific interface:
```none
debug condition interface FastEthernet 0/0
```
Now, only RIP messages from Fa0/0 will show up:
```none
RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (192.168.12.1)
```
## Debug Condition Matching Logic
Each `debug condition` adds to the filter, they are **additive** not logical `and` or `or`.
For example:
```none
debug condition interface FastEthernet0/0
debug condition interface FastEthernet0/1
```
This will show debug output **from either** Fa0/0 **or** Fa0/1 — **not just packets matching both**.
> Think of debug conditions like **permit rules in an ACL**: if it matches **any** condition, it is shown.
You can check the current debug statements with:
```
show debug condition
```
## Removing a Debug Condition
To remove a specific condition:
```none
undebug condition interface FastEthernet0/0
```
You'll get a warning that removing debug conditions may expose you to high-volume debug output:
```none
Removing all conditions may cause a flood of debugging messages...
Proceed with removal? [yes/no]: yes
```
## Console, VTY, AUX, SSH, & SCP
URL: https://adamspera.dev/services/console-vty-aux-ssh--scp/
## Console
The **console line** is the physical access method via the device's console port. There is **only one** console line (`line console 0`).
#### Basic Authentication
```none
line console 0
password cisco
login
```
- The `login` command tells the router to prompt for the password configured with `password`.
- If `login` is not specified, **no authentication** will be enforced on console access.
#### Local Authentication
```none
username admin password cisco
line console 0
login local
```
- `login local` uses credentials from locally configured users.
- Users must enter both a **username** and **password** to gain access.
## VTY Lines
VTY lines are **virtual teletype** lines used for remote access.
- VTY line numbers typically range from 0 to 15.
- This means **up to 16 users** can connect simultaneously.
```
line vty 0 15
login local
transport input { any | ssh | telnet | none }
exec-timeout {minutes} {seconds}
absolute-timeout {minutes}
logout-warning {seconds}
```
- `login local` - uses will need to sign in with a locally confused user
- `transport input <>` - defined what protocols are allowed to use those lines
- `exec-timeout <> <>` - defines how long to wait before disconnecting inactive sessions
- `absolute-timeout <>` - defined at what time the line will be forcibly closed
- `logout-warning <>` - defined at what time a logout warning is issuesd
## AUX
Usage of the auxiliary port via a cable modem is a legacy use case and technology, and should be disabled for access.
```
line aux 0
no exec
```
## SSH
```none
hostname R1
ip domain-name adamspera.dev
crypto key generate rsa modulus 2048
ip ssh version 2
username admin password cisco
line vty 0 15
login local
transport input ssh
```
- `transport input ssh` allows only SSH (not Telnet).
- `crypto key generate rsa` is required to enable SSH.
- `ip ssh version 2` since IOS devices run both 1 & 2, this command stops v1.
## SCP Server
SCP is a file sharing protocol that runs over SSH, and requires AAA new-model.
The following configuration example shows how you can setup a network device to be an SCP server:
```none
aaa new-model
aaa authentication login default local
aaa authorization exec default local
username admin secret cisco
hostname MyRouter
ip domain-name adamspera.dev
crypto key generate rsa modulus 2048
ip ssh version 2
line vty 0
transport input ssh
login authentication default
ip scp server enable
```
## IOS Login Enhancements
Helps protect against **brute-force attacks**.
```plaintext
login block-for 60 attempts 3 within 10
```
> This means: If 3 failed attempts occur **within 10 seconds**, block logins **for 60 seconds**.
## Datapath Packet-Trace & FIA-Trace
URL: https://adamspera.dev/services/datapath-packet-trace--fia-trace/
The **Packet-Trace** feature provides insight into how packets are processed through the hardware and software data paths on Cisco platforms. It is a powerful diagnostic tool that can be used in production environments without severely impacting performance.
Packet Trace allows inspection of packet handling using three levels of granularity:
## Packet-Trace Levels
| Level | Description |
|-------------|-------------|
| **Accounting** | Lightweight and runs continuously. Provides a **count of packets** entering and leaving the network processor. Minimal impact on performance. |
| **Summary** | Tracks **input/output interfaces**, packet state, and whether it was **punted, dropped, or injected**. Higher resource usage than accounting. Useful for identifying problem interfaces. |
| **Path data** | Provides the **highest level of detail**, including timestamps, debug IDs, and feature-specific processing data. Optional enhancements include **packet-copy** and **Feature Invocation Array (FIA)** tracing. Highest performance impact and should be used with care. |
> Note: Path data collection is resource intensive. Use sparingly in live environments where performance is critical.
## Guidelines and Memory Considerations
- Use **ingress condition filters** to limit scope and avoid performance degradation.
- Packet trace consumes **data-plane memory**. The memory usage is estimated by:
```
memory required = statistics_overhead + number_of_packets * (summary_size + data_size + packet_copy_size)
```
## Configuration Steps
### Creating a Path Trace
```
c8000v-0# debug platform packet-trace ?
copy Copy packet data
drop Trace drops only
inject Trace injects only
packet Packet count
punt Trace punts only
statistics enable packet trace statistics
```
```
debug platform packet-trace packets 2048 fia-trace circular
```
> You can enable multiple types of data being collected, as seen above.
### Apply Match Conditions
You can limit the packet trace to specific interfaces or traffic flows.
**Example: Match on ingress interface**
```ios
debug platform condition interface g0/0/0 ingress
```
**Example: Match on source IP**
```ios
debug platform condition ipv4 192.168.1.1 ingress
```
> Combine multiple conditions to narrow down further.
### Start and Stop Packet Trace
```ios
debug platform condition start
...
debug platform condition stop
```
### View Packet Trace Data
```ios
show platform packet-trace configuration
show platform packet-trace statistics
show platform packet-trace summary
show platform packet-trace packet all
```
### Clear All Conditions
```ios
clear platform condition all
clear platform packet-trace configuration
```
## Example Workflow
```ios
debug platform packet-trace packets 100 fia-trace circular
debug platform packet-trace statistics
debug platform condition interface GigabitEthernet0/0/0 egress
show platform packet-trace configuration
show platform condition
debug platform condition start
...generate test traffic...
debug platform condition stop
show platform packet-trace summary
show platform packet-trace statistics
show platform packet-trace packet #
...cleanup when done...
clear platform condition all
clear platform packet-trace configuration
```
## Reference
[Cisco Packet Trace Configuration Guide](https://www.cisco.com/c/en/us/td/docs/routers/asr1000/software/configuration/xe-17/asr1000-sw-config-xe-17/packet_trace.html)
## Dynamic Host Configuration Protocol (DHCP)
URL: https://adamspera.dev/services/dynamic-host-configuration-protocol-dhcp/
DHCP is a critical network service that automates the assignment of IP addresses and other network configuration parameters to hosts. It eliminates the need for manual IP address configuration, especially in large, dynamic networks.
Without DHCP, every device would need to be manually configured with:
- An IP address
- Subnet mask
- Default gateway
- DNS server(s)
## DHCP Process (DORA)
DHCP operates using a four-step process commonly referred to as **DORA**:
1. **Discover** – Client broadcasts to locate available DHCP servers.
2. **Offer** – Server responds with an available IP address and configuration options.
3. **Request** – Client requests to lease the offered IP address.
4. **Acknowledgment** – Server acknowledges and finalizes the lease.
This is all handled using **broadcast and unicast** messages over **UDP port 67 (server)** and **68 (client)**.
## DHCP Roles
- **DHCP Server**: Allocates IP addresses from a defined pool and tracks active leases
- **DHCP Client**: Dynamically requests IP configuration
- **DHCP Relay Agent**: Forwards DHCP packets between clients and servers across different subnets
DHCP is a **Layer 7 (application layer)** protocol but relies heavily on **Layer 2 and 3 broadcast behavior**, which is why relay agents (e.g., `ip helper-address`) are often required in routed environments.
## DHCP Configurations
#### Basic Server Configuration
```none
service dhcp
ip dhcp excluded-address 192.168.1.1 192.168.1.10
ip dhcp pool USERS
network 192.168.1.0 255.255.255.0
default-router 192.168.1.1
dns-server 8.8.8.8 1.1.1.1
lease 7
```
- `excluded-address` prevents those IPs from being assigned
- `default-router` sets the gateway for clients
- `lease` defines the number of days (or optionally hours and minutes)
#### Basic Client Configuration
```none
interface GigabitEthernet0/0
ip address dhcp
```
#### Manual Binding on Server
```
debug ip dhcp server packet
```
Then copy the client-identifier that is outputted when a DHCP message is received.
Some devices use the MAC address by default though, including Ubuntu or Linux.
```
ip dhcp pool STATIC1
host 192.168.1.10 255.255.255.0
client-identifier [...]
```
> The client identifier can be found by running `debug dhcp detail` on the end host, then wait for it to generate a DHCP Discovery message. Then copy and paste the client-identifier. **If the client ID in the running-config is not even 4 char between periods, add leading zeros.**
## DHCP Relay (Forwarding)
If the DHCP server is on a different subnet, configure a **DHCP relay agent** using:
```none
interface Vlan10
ip helper-address 192.168.100.10
```
This command causes the router to:
- Convert DHCP broadcasts to unicasts
- Forward them to the server IP
- Translate replies back to the requesting client
> Specifying a VRF in an DHCP pool only works, if the helper address also points to that same VRF locally configured & directly connected.
## DHCP Option Codes
DHCP options are used to send **additional information** to the client beyond just an IP address.
### Option Configurations
```none
ip dhcp pool USERS
option [option-number] [hex | ascii] [value]
```
#### Common DHCP Options
| Option | Purpose | Example |
| ------ | ------------------------------------------- | ------------------------------------------ |
| 1 | Subnet Mask | Auto-included |
| 3 | Default Gateway | `default-router` |
| 6 | DNS Servers | `dns-server` |
| 15 | Domain Name | `domain-name example.com` |
| 66 | TFTP Server Name (VoIP, PXE boot) | `option 66 ascii tftp-server.local` |
| 67 | Bootfile Name (PXE boot image) | `option 67 ascii pxelinux.0` |
| 82 | Relay Agent Info (inserted by switch/relay) | Controlled via `ip dhcp relay information` |
> Options 66 and 67 are frequently tested in **PXE boot**, **IP phone**, and **controller-based** environments.
---
## Troubleshooting
```none
show ip dhcp binding
show ip dhcp pool
debug ip dhcp server events
debug ip dhcp server packet
```
These are useful for checking which clients have active leases, what pools exist, and whether DHCP messages are being exchanged.
## Embedded Packet Capture (EPC)
URL: https://adamspera.dev/services/embedded-packet-capture-epc/
**Cisco Embedded Packet Capture (EPC)** is a built-in IOS-XE feature that lets routers capture live traffic passing through their interfaces. It's especially useful for debugging and protocol analysis without requiring external devices or taps.
> Captures are stored in **DRAM** and are **cleared on reload** unless exported.
## Use Cases
- Troubleshooting NAT, routing, or ACL behavior
- Capturing malformed packets
- Verifying protocol behavior (DHCP, HSRP, etc.)
- Capturing traffic during flaps or intermittent failures
## Capture Workflow
1. **Create a capture buffer**
2. **(Optional)** Apply a filter using an ACL
3. **Create a capture point** (interface + direction)
5. **Start the capture**
6. **Stop and view/export the capture**
## Step 1: Create a Capture Buffer
```ios
monitor capture MYCAP buffer circular size 100
```
- `size`: Total buffer size in MB
- `circular`: Continues capturing and overwrites oldest data
- Use `linear` instead of `circular` if you want capturing to stop when the buffer is full
## Step 2: Filter with Match or ACL
```ios
ip access-list extended PACKET_FILTER
permit ip host 192.168.12.1 host 192.168.23.3
monitor capture MYCAP access-list PACKET_FILTER
...or...
monitor capture MYCAP match any
```
## Step 3: Create a Capture Point
```ios
monitor capture MYCAP interface FastEthernet0/1 both
```
- `both`: Capture ingress and egress
- Other options: `in`, `out`
## Step 4: Start and Stop the Capture
```ios
monitor capture MYCAP start
...
monitor capture MYCAP stop
```
## Step 5: View or Export
View packets directly on the router:
```ios
show monitor capture MYCAP buffer
show monitor capture MYCAP buffer brief
show monitor capture MYCAP buffer dump
```
Export to a TFTP server for Wireshark analysis:
```ios
monitor capture MYCAP export tftp://10.100.2.120/capture.pcap
```
## Optional Combination
```
monitor capture MYCAP buffer size 100 circular interface G1 both match any start
```
## Notes
- EPC captures are **volatile**; they are lost on reload.
- **Only one capture per interface/direction** is supported at a time.
- You must have **CEF enabled** on the target interfaces.
- Capture can be done using L2, IP, or ACL filters.
## Reference
[Embedded Packet Capture Whitepaper](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/epc/configuration/xe-17/epc-xe-17-book/nm-packet-capture-xe.html)
## First Hop Redundancy Protocols (FHRPs)
URL: https://adamspera.dev/services/first-hop-redundancy-protocols-fhrps/
This document outlines a collection of **First Hop Redundancy Protocols (FHRPs)** designed to provide seamless default gateway failover for end hosts. These protocols operate by sharing a **virtual IP and MAC address** between routers on the same subnet. With the aid of **gratuitous ARP**, failover occurs quickly and transparently to clients.
---
## FHRP Comparison Table
| Feature | HSRP | VRRP |
| ------------------- | ---------------------------- | ---------------------------- |
| Standard | Cisco proprietary / RFC 2281 | Industry standard / RFC 3768 |
| Terminology | Active / Standby | Master / Backup |
| Priority Range | 0–255 (default: 100) | 0–255 (default: 100) |
| Preemption | Optional | Enabled by default |
| Timers (hello/hold) | 3s / 10s (default) | 1s / 3s (default) |
| Multicast Group | 224.0.0.2 | 224.0.0.18 |
| Transport | UDP port 1985 | IP Protocol 112 |
| Authentication | Clear Text / MD5 | Clear Text / MD5 |
| Virtual MAC | `0000.0c07.acXX` | `0000.5E00.01XX` |
---
## HSRP (Hot Standby Router Protocol)
- **Cisco proprietary**, also documented in RFC 2281.
- Uses **active/standby** roles.
- The router with the highest priority becomes **active**. In the event of a tie, the router with the highest IP address wins.
- **Preemption** must be manually enabled.
- Operates using **UDP multicast** to `224.0.0.2`, port `1985`.
- Virtual MAC format: `0000.0c07.acXX` (where `XX` = group ID in hex).
- Supports **Clear Text** and **MD5** authentication.
### Basic HSRP Configuration
```
interface Ethernet1/1
ip address 192.168.1.10 255.255.255.0
standby 0 ip 192.168.1.1
standby 0 priority 110
standby 0 preempt
standby 0 timers 5 15
```
> `standby 0 timers 5 15`: 5s hello, 15s hold time.
### HSRP Additional Configs
**Delays and BFD**
```
interface Ethernet1/1
standby 0 preempt delay minimum 10
standby delay minimum 30 reload 60
bfd interval 250 min_rx 250 multiplier 4
```
> `standby delay minimum 30 reload 60` configures the delay period before the initialization of HSRP groups, where `minimum` is after a link comes up, and `reload` is after a device reboot.
> `standby 1 preempt delay minimum 380` determines the amount of seconds a group will wait before initiating preemption. Default is immediately.
**Basic Tracking**
[[IP Service Level Agreement (SLA) & Enhanced Object Tracking (EOT)]]
```
track 100 interface GigabitEthernet 0/0/0 { line-protocol | ip routing }
interface Ethernet1/1
standby 0 track 100 [ decrement 20 | shutdown ]
```
### HSRP Authentication
**MD5 key-chain:**
```
key chain HSRP1
key 1
key-string cisco1234
interface Ethernet1/1
standby 0 authentication md5 key-chain HSRP1
```
**MD5 key-chain:**
```
interface Ethernet1/1
standby 0 authentication md5 key-string HSRP1
```
**Plain-text authentication:**
```
interface Ethernet1/1
standby 0 authentication text cisco1234
```
### HSRP with Object Tracking
[[IP Service Level Agreement (SLA) & Enhanced Object Tracking (EOT)]]
```
ip sla 1
icmp-echo 10.0.0.1
ip sla schedule 1 start-time now life forever
track 1 ip sla 1
interface Ethernet1/1
standby 0 track 1 decrement 255
```
---
### HSRPv2 Enhancements
- Supports **more groups per interface**.
- Uses dedicated multicast address: `224.0.0.102`.
- Supports **IPv6**.
```
interface Ethernet1/1
standby version 2
```
---
## VRRP (Virtual Router Redundancy Protocol)
- Defined in **RFC 3768**, vendor-neutral standard.
- Uses **master/backup** roles.
- Priority-based master election:
- Higher priority wins; tie-breaker = highest IP address.
- **Preemptive** behavior is **enabled by default**.
- Uses **IP protocol 112** over multicast `224.0.0.18`.
- Virtual MAC: `0000.5E00.01XX` (where `XX` = group ID in hex).
- Supports **Clear Text** and **MD5** authentication.
> Most configurations copy over from HSR, but with `vrrp` instead of `standby`.
### Priority Behavior
- Valid priority range: **1–254**
- Default: **100**
**255 is reserved** for a special case:
If a router is configured with the **interface IP address as the virtual IP (VIP)**, it **must always be the master**. In this case, VRRP **automatically sets the priority to 255**, and no other router is allowed to override it, not even with a higher manual priority.
This makes sense, because that router is **literally** the owner of the IP and can't have another box claim it.
| Priority Value | Meaning |
| -------------- | ------------------------------------------------------- |
| 1–254 | Normal configured range (higher wins) |
| 255 | **Reserved** — used when a router owns the VIP directly |
| 0 | Resign — causes the router to stop being master |
### Basic VRRP Configuration
```
interface Ethernet1/1
ip address 192.168.1.10 255.255.255.0
vrrp 1 ip 192.168.1.1
vrrp 1 priority 110
vrrp 1 preempt
```
### VRRP-Specific Timer Configuration
```
interface Ethernet1/1
vrrp 1 timers advertise 3
vrrp 1 timers learn
```
---
### VRRPv3 Enhancements
- Adds **IPv6 support** and protocol extensibility.
- Enable globally with:
```bash
fhrp version vrrp v3
```
## Flexible Netflow
URL: https://adamspera.dev/services/flexible-netflow/
NetFlow provides statistics on packets flowing through the router. It is primarily used for:
- Network and application monitoring
- Capacity planning
- Security analysis
- Traffic accounting
## Setup Overview
1. **Create a flow record** – defines the fields to match and collect
2. **Configure a flow exporter** – specifies where to send flow data (e.g., collector IP/port)
3. **Create a flow monitor** – ties the flow record and exporter together
4. **Apply flow monitor to interface** – on ingress or egress
5. **Verify locally** using `show flow monitor NAME cache`
## Configuration
#### 1. Create Flow Record
```
flow record v4_r1
match ipv4 protocol
match ipv4 source address
match ipv4 destination address
match transport source-port
match transport destination-port
collect counter bytes long
collect counter packets long
```
#### 2. Configure Flow Exporter
```
flow exporter EXPORTER-1
destination 10.100.2.120 [ vrf ... ]
transport udp 2055
```
#### 3. Create Flow Monitor and Bind Record
```
flow monitor FLOW-MONITOR-1
record v4_r1
exporter EXPORTER-1
cache timeout active 60
cache timeout inactive 10
```
> `cache timeout active` -> This means **every 60 seconds**, the router exports ongoing flows.
> `cache timeout inactive` -> So if no more packets come through that flow in 15 seconds, it will export.
#### 4. Apply to Interface
```
interface Ethernet1/1
ip flow monitor FLOW-MONITOR-1 { input | output }
```
#### 5. Verify Cache Locally
```
show flow monitor FLOW-MONITOR-1 cache format table
```
## Sampler
Flow samplers are created as separate components in a router’s configuration. Flow samplers are used to reduce the load on the device that is running Flexible NetFlow by limiting the number of packets that are selected for analysis.
Flow sampling exchanges monitoring accuracy for router performance. When you apply a sampler to a flow monitor, the overhead load on the router of running the flow monitor is reduced because the number of packets that the flow monitor must analyze is reduced. The reduction in the number of packets that are analyzed by the flow monitor causes a corresponding reduction in the accuracy of the information stored in the flow monitor’s cache.
Samplers are combined with flow monitors when they are applied to an interface with the ip flow monitor command.
```
sampler SAMPLER-1
mode random 1 out-of { window-size }
interface Ethernet1/1
ip flow monitor FLOW-MONITOR-1 sampler SAMPLER-1 input
```
```
show sampler SAMPLER-1
```
## Netflow Collector on Ubuntu
```
# Clone and build the container
git clone https://github.com/arktronic/docker-quick-elastic-netflow.git && \
cd docker-quick-elastic-netflow && \
./_build.sh && \
# Run the stack (Elasticsearch + Kibana + Filebeat NetFlow)
docker run \
--init \
--name quickelasticnetflow \
-p 5601:5601 \
-p 2055:2055/udp \
-d localhost/arktronic/quick-elastic-netflow:latest
```
Then go to Discover, then filter by `filebreat-*` to see the Netflows collected.
## IP Service Level Agreement (SLA) & Enhanced Object Tracking (EOT)
URL: https://adamspera.dev/services/ip-service-level-agreement-sla--enhanced-object-tracking-eot/
Cisco routers can dynamically react to changing network conditions using **IP SLA** and **Object Tracking**. These features are often used to influence **HSRP priorities**, **static routes**, or **routing protocol failover**.
## Basic Object Tracking
### Interface State Tracking
This monitors whether an interface is up at **Layer 1 (line-protocol)** or **Layer 3 (IP routing)**.
```none
track 100 interface GigabitEthernet0/0/0 line-protocol
```
**Use Case:** HSRP will **decrement priority** if the interface goes down.
```none
standby 1 track 100 decrement 10
```
If this tracked interface goes down, the HSRP group will reduce its priority, which may cause it to lose active status — allowing the standby router to take over.
### IP Routing Capability Tracking
This tracks if the interface has a working **IP routing path**, not just a physical link.
```none
track 101 interface GigabitEthernet0/0/0 ip routing
```
**Use Case:** Interface might be physically up, but not routing (e.g., downstream device failure). HSRP can still react based on IP reachability.
### Static Route Reachability Tracking
This tracks the presence of a route in the RIB (routing table).
```none
track 110 ip route 10.10.10.0/24 reachability
```
**Use Case:** If a static route disappears, HSRP will reduce priority, or a tracked static route will be withdrawn entirely.
## IP SLA Integration with Tracking
**IP SLA** generates synthetic probes (ping, TCP, UDP) to verify real-time availability of a remote destination.
### Example: ICMP Echo with Static Route Tracking
```none
ip sla 1
icmp-echo 8.8.8.8 source-ip 10.100.2.59
frequency 5
timeout 6000
ip sla schedule 1 start-time now life forever
```
Tie to tracking:
```none
track 1 ip sla 1
ip route 0.0.0.0 0.0.0.0 10.100.2.1 track 1
```
**Use Case:** If the router cannot reach 8.8.8.8, the static route to 10.100.2.1 is removed — preventing black-hole routing and enabling failover to a backup path.
### Example: TCP/UDP Port Availability Between Routers
#### R2 – Initiator
```none
ip sla 2
tcp-connect 10.100.1.1 80 source-ip 192.168.1.25 control disable
ip sla schedule 2 start-time now life forever
```
```none
ip sla 3
udp-connect 10.100.1.1 80 source-ip 192.168.1.25 control disable
ip sla schedule 3 start-time now life forever
```
#### R1 – Responder
```none
ip sla responder tcp-connect ip 10.100.2.1 port 80
ip sla responder udp-echo ip 10.100.2.1 port 80
```
**Use Case:** Track port-level availability of a remote server (e.g., web service). If the service fails, you can withdraw routes or reduce HSRP priority.
## Enhanced Object Tracking (Track Lists)
Track lists allow evaluating multiple objects together, providing more robust failure logic.
### Boolean Tracking (AND, OR, NOT)
```none
track 10 list boolean and
object 1
object 2 not
delay up 10 down 20
```
**Use Case with HSRP:**
```none
standby 1 track 10 decrement 20
```
HSRP priority is reduced only if **object 1 is down and object 2 is up**. This allows refined failover logic — e.g., only fail if a primary path fails but a backup stays up.
### Threshold Tracking – Weight
Objects contribute weighted values. The combined weight is compared against thresholds.
```none
track 20 list threshold weight
object 1 weight 60
object 2 weight 40
threshold weight up 70 down 30
delay up 5 down 10
```
**Use Case with Static Route:**
```none
ip route 0.0.0.0 0.0.0.0 10.100.2.1 track 20
```
- Route remains up if total object weight is ≥ 70
- Route is withdrawn if total drops below 30
This provides a **graded failover** strategy — useful when monitoring different link types (e.g., MPLS and Broadband).
### Threshold Tracking – Percentage
Objects are equally weighted; the logic uses percentage of **how many are up**.
```none
track 30 list threshold percentage
object 1
object 2
object 3
threshold percentage up 100 down 50
delay up 5 down 5
```
**Use Case with HSRP:**
```none
standby 1 track 30 decrement 15
```
- HSRP priority is reduced if fewer than 50% of monitored services are up
- All must be up to restore full status
## HSRP Application – Complete Examples
### Interface-Based HSRP Failover
```none
track 100 interface GigabitEthernet1/0/0 ip routing
interface GigabitEthernet0/0/0
ip address 10.1.0.21 255.255.0.0
standby 1 preempt
standby 1 ip 10.1.0.1
standby 1 priority 110
standby 1 track 100 decrement 10
```
**Use Case:** Fail HSRP over if routing is lost on the upstream interface.
### Route-Based HSRP Failover
```none
track 100 ip route 10.2.2.0/24 reachability
interface GigabitEthernet0/0/0
ip address 10.1.1.21 255.255.255.0
standby 1 preempt
standby 1 ip 10.1.1.1
standby 1 priority 110
standby 1 track 100 decrement 10
```
**Use Case:** Fail HSRP if a **remote site route** is lost due to upstream failure — even if local interfaces are still up.
## Maps and Lists in IOS-XE
URL: https://adamspera.dev/services/maps-and-lists-in-ios-xe/
## Overview
Cisco IOS-XE uses several different configuration structures to deploy dynamic configurations. These structures act as logical functions that evaluate traffic and return values used by other network features. Understanding how these structures work logically helps you design more effective network policies.
| Object | Purpose |
| ----------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| Access-List | Identify traffic based on first match, then return true or false. |
| Route-Map | Matches based on an ACL then sets an L3 setting like for PBR, BGP Policy, or Redistribution. |
| Class-Map | Classification structures that return true or false based on all or any conditions defined, which can be of types ACL, DSCP, CoS, NBAR2, etc. |
| Access-Map | Functions like a class-map but includes actions forward or drop, for use with VACLs. |
| Policy-Map | Takes action on traffic defined by class-maps. Most commonly used for QoS. |
## Access List
Access lists are essentially functions that take in a packet and return a true or false value (permit or deny) based on a set of conditions.
#### Creating an Access List
```
ip access-list extended TELNET
permit tcp 192.168.1.0 0.0.0.255 any eq 23
```
This access list permits TCP traffic from the 192.168.1.0/24 network to any destination on port 23 (Telnet). All other traffic is implicitly denied.
#### Applying to an Interface
```
interface GigabitEthernet1/1
ip access-group TELNET in
```
Traffic that receives "PERMIT" is forwarded normally. Traffic that receives "DENY" is dropped.
> **Important:** When applied directly to interfaces, ACLs serve to forward or drop traffic. However, ACLs are also used by other features (route-maps, class-maps, NAT, etc.) where they simply return PERMIT or DENY as input for additional logic. The ACL itself doesn't forward or drop traffic in these cases - it just provides a match result.
## Route Map
Route-maps are structures that combine matching criteria with actions. Unlike ACLs which simply return permit or deny, route-maps evaluate conditions and then perform specific actions on matching traffic or routes.
#### Route-Map for PBR
```
ip access-list extended VOICE-TRAFFIC
permit udp any any range 16384 32767
route-map PBR-EXAMPLE permit 10
match ip address VOICE-TRAFFIC
set ip next-hop 10.1.1.1
route-map PBR-EXAMPLE permit 20
interface GigabitEthernet0/1
ip policy route-map PBR
```
#### Route-Map for BGP Policy
```
route-map BGP-IN permit 10
match ip address prefix-list CUSTOMERS
set local-preference 200
router bgp 65000
neighbor 10.1.1.1 route-map BGP-IN in
```
#### Route-Map for BGP Route Redistribution
```
route-map REDIST-OSPF permit 10
match ip address prefix-list INTERNAL
set metric 100
router bgp 65000
redistribute ospf 1 route-map REDIST-OSPF
```
## Class Map
Class-maps are classification structures that identify and group traffic based on specific criteria. Unlike ACLs which return permit or deny based on the first matching criteria, class-maps return "matches this class" or "does not match this class" for use by policy-maps.
When on the CLI, you'll notice there are multiple options to match against:
```
Router(config)#class-map CLI_CLASS
Router(config-cmap)#?
Class-map configuration commands:
description Class-Map description
exit Exit from class-map configuration mode
match classification criteria
no Negate or set default values of a command
Router(config-cmap)#match ?
access-group Access group
any Any packets
class-map Class map
cos IEEE 802.1Q/ISL class of service/user priority values
dscp Match DSCP in IPv4 and IPv6 packets
precedence Match Precedence in IPv4 and IPv6 packets
protocol Protocol
vlan VLANs to match
...
```
> Note that class-maps can be configured two ways, `match-all` or `match-any`, which correlate to Boolean logic operators. In the above example, the access-map will return `true` if the traffic is either Telnet or SSH.
#### Class-Map using ACLs
```
ip access-list extended TELNET
permit tcp any any eq 23
ip access-list extended SSH
permit tcp any any eq 22
class-map match-any CLI_CLASS
match access-group name TELNET
match access-group name SSH
```
#### Class-Map using DSCP/CoS
```
class-map match-all VOICE_CLASS
match dscp ef
match cos 5
```
#### Class-Map using Protocol (NBAR2)
```
class-map match-all COLLABORATION_CLASS
match protocol webex
match protocol ms-teams
```
> **Important:** Class-maps cannot be applied to interfaces or protocols directly, rather they have to be used with a policy-map.
#### Access-Maps for VLANs
Access-Maps are special subsets of Class-Maps where they can be assigned an action.
```
vlan access-map DROP_TELNET 10
match ip address TELNET
action drop log
vlan access-map DROP_TELNET 20
action forward
vlan filter DROP_TELNET vlan-list 10
```
This behavior is contrary to the normal function of Class-maps, but I have placed it here since the syntax matches that of Class-Maps.
## Policy Map
Policy-maps define actions to take on traffic classified by class-maps. While class-maps identify traffic, policy-maps specify what to do with that traffic. Policy-maps are the action engine of the Modular QoS CLI (MQC) framework.
#### Creating a Policy-Map
```
class-map VOICE
match dscp ef
class-map VIDEO
match dscp af41
policy-map QOS-POLICY
class VOICE
priority percent 20
police rate 512000
conform-action transmit
exceed-action drop
class VIDEO
bandwidth remaining percent 40
class class-default
bandwidth remaining percent 60
random-detect dscp-based
```
#### Policy-Map Actions
Policy-maps can apply various actions depending on the context:
**QoS Actions:**
- `priority` - Priority queueing (LLQ)
- `bandwidth` - Guarantee minimum bandwidth
- `police` - Rate limiting
- `set` - Mark or remark traffic
- `shape` - Traffic shaping
- `random-detect` - WRED configuration
#### Applying a Policy-Map
```
interface GigabitEthernet0/1
service-policy output QOS-POLICY
```
1. Packet arrives on GigabitEthernet0/1
2. Evaluated against VOICE class-map (DSCP EF?)
1. If match: Apply priority queueing and policing
3. If no match, evaluate against VIDEO class-map (DSCP AF41?)
1. If match: Apply bandwidth allocation
4. If no match, traffic goes to class-default
1. Apply default bandwidth allocation
## Network Address Translation (NAT)
URL: https://adamspera.dev/services/network-address-translation-nat/
## Overview
NAT rewrites IP addresses in a packet to allow private networks to communicate with public or overlapping networks. It’s commonly used to:
- **Hide private IP addresses** behind a public IP
- **Resolve overlapping subnets**
- **Enable internet access** for internal hosts
- **Redirect traffic** to internal services using destination NAT
#### Source NAT
- Rewrites the **source IP address**
- Most common NAT type
- Used for outbound traffic (e.g., internet, inter-VRF)
#### Port Address Translation (PAT)
- A form of NAT that rewrites both IP and **port number**
- Allows **many internal hosts** to share a **single public IP**
- Enabled by the keyword `overload`
- Most commonly used NAT type in production networks
---
## Types of NAT
- **Static NAT / PAT** – Fixed one-to-one IP or IP+Port mapping
- **Dynamic NAT / PAT** – Allocated from a pool or interface dynamically as traffic flows
- **Policy NAT / PAT** – NAT applied only to traffic matching an access list (ACL)
- **VRF-aware NAT / PAT** – NAT with multi-VRF awareness
- **VASI NAT** – Uses virtual interfaces for inter-VRF translation (IOS XE advanced use)
---
## Configurations
```none
interface Ethernet1
ip address 10.0.0.1 255.255.255.252
ip nat outside
interface Ethernet2
ip address 192.168.1.1 255.255.255.0
ip nat inside
```
---
### NAT
**Static NAT**
```none
(config)# ip nat inside source static 192.168.1.10 10.0.0.1
```
Maps internal host `192.168.1.10` to outside IP `10.0.0.1` permanently (1:1 mapping).
```none
(config)# ip nat inside source static 192.168.1.10 interface Ethernet1
```
Maps internal host `192.168.1.10` to the **outside interface IP** (dynamic public IP scenario).
**Dynamic NAT**
```none
(config)# access-list 1 permit any
(config)# ip nat inside source list 1 interface Ethernet1
```
Dynamically translates IPs that match ACL 1 to the IP address of Ethernet1.
- Only one translation is allowed at a time unless PAT (`overload`) is used.
---
### PAT
```none
(config)# access-list 1 permit any
(config)# ip nat inside source list 1 interface Ethernet1 overload
```
Applies PAT to any internal IP, allowing multiple internal hosts to share the IP of Ethernet1 using port translation.
---
### Policy
**NAT & PAT (Policy-based using ACL)**
```none
(config)# access-list 100 permit tcp any any eq 80
(config)# ip nat inside source list 100 interface Ethernet1
(config)# ip nat inside source list 100 interface Ethernet1 overload
```
- Translates only **HTTP (TCP port 80)** traffic that matches ACL 100.
- Without `overload`: Dynamic Policy NAT (1:1)
- With `overload`: Dynamic Policy PAT (many-to-one with port translation)
---
### Port Forwarding
```none
ip nat inside source static tcp 192.168.1.10 23 10.0.0.1 12345
or
ip nat inside source static tcp 192.168.1.10 23 interface Eth1 12345
```
Maps internal **port 23** on `192.168.1.10` to **port 12345** on `10.0.0.1`.
- Commonly used for port forwarding scenarios (e.g., external SSH/RDP access).
## Network Time Protocol (NTP)
URL: https://adamspera.dev/services/network-time-protocol-ntp/
Synchronizing time across network devices is a **critical service**. While it might not seem important at first glance, many key network functions rely on **accurate clocks**, including:
- Time-based **ACLs**
- Expiring **passwords** and **certificates**
- **Key exchange validation** for VPNs and secure tunnels
- Accurate **log timestamps** for troubleshooting and correlation
> **NTP uses UDP port 123**
NTP works on a **hierarchical model** called the **Stratum model**, which defines the "distance" a device is from the **reference clock** (usually an atomic or GPS clock).
- **Stratum 0**: Reference clock (atomic, GPS, etc.)
- **Stratum 1**: Directly connected to Stratum 0
- **Stratum 2+**: Syncs to a device at a lower stratum
Each hop **away from the atomic clock** increases the stratum level.
## NTP Roles
Devices can participate in NTP in one of several roles:
#### NTP Client
- Syncs time from a specified server
#### NTP Server
- Provides time to other clients or peers
- Use `ntp master` if you're making a router or switch act as an authoritative clock source
#### NTP Peer
- Two devices at the **same stratum** can peer
- Helps provide **redundancy** and **resilience**
- If both peers lose connection to their stratum-lower server, they can **stay in sync with each other**
> NTP Peering is great for maintaining consistent time across a zone when the upstream clock source is temporarily unreachable.
## NTP Configuration
```none
! Configure as a time source (typically on the "server" side)
ntp master [stratum]
! Configure as an NTP client
ntp server [ipaddress]
! Peer with another device (must be same stratum)
ntp peer [ipaddress]
! Enable NTP authentication & Define authentication key
ntp authenticate
ntp authentication-key [number] md5 [key-string]
ntp trusted-key [number]
ntp server [address] key [number]
```
```none
show ntp status ! View current sync status and stratum
show ntp associations ! View peers/servers and their reachability
```
## Precision Time Protocol (PTP)
While NTP provides reasonable time synchronization (typically accurate within milliseconds), the Precision Time Protocol (PTP) is designed for applications that require **much higher precision**, often in the **sub-microsecond** range.
PTP is defined in **IEEE 1588** and is commonly used in environments such as:
- Industrial automation
- Telecommunications (e.g., mobile backhaul, 5G)
- Financial trading systems
- Power distribution networks
| Feature | NTP | PTP |
|--------------------|-------------------------------|-------------------------------|
| Accuracy | Milliseconds | Sub-microseconds |
| Transport Protocol | UDP (port 123) | UDP (port 319/320) or Ethernet |
| Hardware Support | Optional | Typically hardware-assisted |
| Use Case | General network devices | Precision-critical systems |
## Quality of Service (QoS)
URL: https://adamspera.dev/services/quality-of-service-qos/
Classification can be done through:
- Layer 2
- CoS
- Layer 3
- ACL
- IP Addresses
- Subnets
- TCP & UDP
- IP Precedence
- DSCP
- Layer >=4
- NBAR
- DPI
NBAR (Network Based Aplication Recognition) does deep packet inspecion to look beyond L3 and L4
CoS -> in 802.1Q tag
ToS -> in the L3 payload header
PCP
0 - best effort (default)
1
2
3 - critical applications (voip uses this for making calls)
4 - video
5 - voice (voip active calls)
6 - internetwork control
7 - network control
Since the CoS (PCP) header is in an 802.1q header, it can only be applied if teh traffic already has an 802.1q header. For example, VOIP devices will add the voice vlan 802.1q tag to its voip traffic with CoS already.
IP Precedence is legacy, and only uses the left 3 bits of the 8 bit field, which is why DSCP uses all but the last two bits (used for other stuff). *Learning the IP Precedence rankings are not needed. Is mostly the same as CoS (PCP).*
DSCP (Differentiated Services Code Point) is a industry agreed uppon set of markings.
- Default Forwarding (DF) - best effort traffic (default)
- Expedited Forwarding (EF) - low loss/latency/jitter traffic (usually voice)
- Assured Forwarding (AF) - A set of 12 standard values, with the goal of making choosing a DSCP value easier.
- Class Selector (CS) - A set of 8 standard values, which line up with the 8 IP Precedence backwards compatible values.
## DF / EF
- DF is used for best effort traffic
- The DSCP marking for DF is 0 (000000xx)
- EF is used for traffic tha requires low loww/latency/jitter.
- The DSCP marking for EF is 46 (101110xx).
## AF
These are juts standardized ways for you to use easy values, and they provide an easy to understand order.
**When you configure AF to classify, it is just a macro that translates to a DSCP value**.
The first 3 bits is the Class, then the 4th and 5th bits are the Drop Precedence.
Higher Class is better.
Lower Drop Prcedence is better.
![[QoS AF Rankings.png]]
You can calculate the DSCP based on the total binary, without splitting it up.
![[QoS AF Calulations.png]]
To quickly calculate the DSCP number from the AF number: `8X + 2Y` where X is the first digit and Y is the second digit.
## CS
Is a set of 8 standard DSCP values, which just so happen to line up with IP Precedence compatibility because the 4th and 5th digit is 0, therefor backwards compatible.
![[QoS CS Calulations.png]]
## RFC 3954 Reccomdendations
- Voice: EF
- Interactice video: AF4x
- Streaming video: AF3x
- High priority data: AF2x
- Best effort: DF
## Scheduling
This is done when you multiple queues, hwo do we determine which one gets to go first?
- First In First Out (FIFO)
- Priority Queueing (PQ)
- Makes 4 queues each with a different priority.
- Nonflexible.
- Round Robin (FQ)
- Taken equally from each queue.
- Weighted Round Robin (WFQ) / HQF (Hierarchical Queuing Framework)
- Sets each queue to have a priority which will take precedence over lower priorities.
- CBWFQ (Class-Based Weighted Fair Queueing)
- Designate a certain amount of link bandwidth assured per queue.
- Uses the Weighted Round Robin system with it, so it also has priorities for the weights.
LLQ (Low Latency Queueing)
- Designates one or more queue as strict priority queues.
- The scheduler will ALWAYS take the traffic from this queue if it has traffic, no matter what.
- Warning: this could starve the other queues while they wait for LLQ queue.
## Shaping and Policing
Shaping buffers the traffic in a queue, which basically sets the link bandwidth to lower.
Policing will drop excess traffic.
Think an ISP that has a 1g line to your house, but you only pay for 200mb. The ISP router will police at 200mb, and your home router will shape at 200mb so that your queueing and scheduler will do its calculations based on the shaped bandwidth.
# Configurations
### Classification
```
ip access-list extended PERMIT_ICMP
permit icmp any any
class-map ICMP
match access-group name PERMIT_ICMP
```
### Action
```
policy-map POLICE_ICMP
class ICMP
police 8000
confrom-action transmit
exceed-action drop
```
### Applying to an Interface
```
interface g0/0
service-policy input POLICE_ICMP
```
# Congestion Management
**FIFO**
SImpliest and easiest to implement
- only paramater is queue depth
Configuration
- Disable previous queueing strategy (default)
- Define queue depth
- `hold-queue out { num }`
Typically used as part of other soltuions like CBWFQ/HQF
**Fair Queuing**
Also knows as max-min scheduling
Services multiple requests for a shared resource
1. Share resources equally
2. Take excessive amounts
3. Share excess equally among unsatisfied requests
**Weighted Fair Queueing**
Max-min scheduling, but not equal.
- Allocate bandwidth per flow proportional to the weight.
Flow is defined dynamically
- Src/Dst IP + Src/Dst Port + ToS Byte
- Weight is IP Precedence + 1
`fair-queue`
**CBWFQ/HQF**
Allows for defining of custom flows
- Class definition using MQC syntax
- Bandwidth keyword defined class's "weight"
Bandwidth is shared proportionally to its weight
- Relative sharing, not absolute reservation
Every queue in CBWFQ/HQF is FIFO
- Includes class-default
- always has 1% of int BW
- Buffer-limit with queue-limit command
- global buffer limit with `hold-queue out`
- Can be turned into Fair Queue
- command `fair-queue { num of flows }`
- All flows are equal, no weighing
- Queue limit per flow is 1/4*queue-limit
# Congestion Avoidance
Tail drop is the default method for all queues.
- Leads to TCP Synchronization
RED is a congestion avoidance technique
- selectively drops flows from the queue before the buffer is 100% full
- goal is to send individual senders into slow start
- result is more even traffic patterns
WRED adds weighting to drop the algorithm
- packets with higher weight are less likely to be dropped
WRED tracks average queue depth
- smoothend based on weight factory
- avg=(old_avg*(1-1/2^n))+(q_size\*1/2^n)
- Drop packets based on Mark Probability Denominator
- Probability = 1/Mark_Probability_Denominiator
- Drop probability increases as queue depth increases
- If queue depth exceeds maximum, tail drop occurs
- Configured in queues as `random-detect`.
![[QoS WRED Drop Thresholds.png]]
In the above example, if the traffic is QoS 0, it will not start using the algorithm until the queue is at the minimum threshold (bandwidth is configured to 50% in the example so the max is 40, so once that is reached it will be the max WRED rate).
# Shaping
```
ip access-list extended ICMP
permit icmp any any
class-map IMCP
match access-group ICMP
policy-map SHAPE
class ICMP
shape average 1000
interface Gig0/0
service-policy output SHAPE
```
```
class-map VOIP
match protocol rtp
class-map SQL
match protocol sqlserver
policy-map INNER_POLICY
class VOIP
priority 1000
class SQL
bandwidth percent 50
policy-map OUTER_POLICY
class class-default
shape average 5000000
service-policy INNER_POLICY
interface Gig0/0
service-policy output OUTER_POLICY
```
# Policing
Used to meter a packet flow rate.
Normally an ingress operation (e.g. PE ingress from CE)
- Marks packets that exceed the metered rate
- Drop is the mark action
Applying to MQC
- Three actions (colors): conform, exceed, violate
Shaping is done on egress
Policing is done ingress
Parameters should match
- Shaping is set to match policing
- Policing should usually be the same or higher.
```
policy-map POLICER
class ICMP
police cir 8000
```
## Simple Network Management Protocol (SNMP)
URL: https://adamspera.dev/services/simple-network-management-protocol-snmp/
## Overview
SNMP (Simple Network Management Protocol) is an application-layer protocol used to monitor and manage network devices. It consists of:
- **SNMP Manager** – Often part of an NMS (e.g., Cisco Prime)
- **SNMP Agent** – Resides on the switch/router
- **MIB (Management Information Base)** – Database of manageable objects
## Versions & Operations
| Operation | Description |
|------------------|-----------------------------------------------------------------------------|
| `get-request` | Retrieves a value from a specific variable |
| `get-next-request`| Retrieves a value from the next variable in a table |
| `get-bulk-request`| Retrieves large blocks of data (SNMPv2c+) |
| `get-response` | Response to `get`, `next`, or `set` requests |
| `set-request` | Stores a value in a specific variable |
| `trap` | Unsolicited message to alert manager of an event |
### SNMPv2c
- Uses a shared **community string** for access
- **No encryption/authentication**; plaintext data
- Basic read-only or read-write access control
- Simple to configure, widely supported
- Vulnerable to spoofing and interception
- Suitable for lab or internal environments
- Limited granularity (no user-specific views)
### SNMPv3
- Uses **User-based Security Model (USM)** with usernames/passwords
- Supports:
- **Authentication**: MD5, SHA
- **Encryption**: DES, AES (128/192/256), 3DES
- Encrypts/authenticates traffic; secure against tampering/replay
- Complex to configure, but allows fine-grained access
- Can define views to restrict access to specific MIBs
- Recommended for production, public, and regulated networks
### SNMP Community String (v1/v2c)
- **RO (Read-Only)** – View only MIB data
- **RW (Read-Write)** – Modify MIB data
- Can restrict by:
- IP access list
- MIB view
- Permission level
**Note:** Avoid `@` symbol in strings due to context delimiter.
## SNMP Notifications
**Traps vs Informs**
| Trap | Inform |
| -------------- | ----------------------------------- |
| Unacknowledged | Acknowledged by manager |
| Sent once | Retransmitted until response |
| Lower overhead | More reliable, higher resource cost |
Use **traps** for low-priority alerts, **informs** when reliability matters.
Use `snmp-server host` to define trap receiver and enable notification types:
**Examples:**
- `snmp-server enable traps snmp`
- `snmp-server enable traps port-security`
- `snmp-server enable traps port-security trap-rate 10`
| Notification Type | Description |
|--------------------|---------------------------------------------------------------|
| `bgp` | BGP state changes |
| `bridge` | STP bridge changes |
| `cluster` | Cluster configuration changes |
| `config` | SNMP config changes |
| `copy-config` | Copy config changes |
| `cpu threshold` | CPU usage threshold |
| `envmon` | Environmental (fan, temp, etc.) |
| `flash` | Flash insertion/removal in stack |
| `fru-ctrl` | FRU (e.g., switch insert/remove) |
| `hsrp`, `ospf`, etc.| Protocol-specific changes |
| `mac-notification` | MAC address movement |
| `port-security` | Port security alerts |
| `snmp` | SNMP-specific traps (auth, cold/warm start, link up/down) |
| `storm-control` | Excessive traffic alerts |
| `syslog`, `tty` | Syslog or TCP connection traps |
| `vlancreate`, etc. | VLAN operations (create/delete/membership) |
| `vtp` | VTP changes |
# Configuration
## SNMPv2c
SNMPv2 must be configured with noAuthNoPriv, which is why an access-list to allow ONLY the NMS is highly suggested.
```
snmp-server enable traps [...]
snmp-server contact [...]
snmp-server location [...]
access-list 10 permit 192.168.100.10
snmp-server community LAB [ro|rw] [access-list]
snmp-server host 192.168.100.10 traps version 2c LAB
```
## SNMPv3
SNMPv3 can be configured with 2 modes:
- authNoPriv
- **`auth`**
- Authentication but no encryption
- authPriv
- **`priv`**
- Authentication and encryption
```
snmp-server enable traps [TRAP]
snmp-server group [GROUP] v3 [ noauth | auth | priv ] [ read | write ] [VIEW]
snmp-server user [USER] [GROUP] v3 auth [ md5 | sha ] [PASSWORD] priv [ 3des | des | aes {128|192|256} ] [PASSWORD]
snmp-server host [IPADDRESS]] [ traps | informs ] version 3 [ noauth | auth | priv ] [USER]
```
> **NOTE:** After a SNMP user is configured, it is NOT added to the running-config. To verify and view configured SNMP users, use the `show snmp user` command.
**Full SNMPv3 configuration example:**
```
snmp-server enable traps syslog
snmp-server group ADMINS v3 priv read VIEW1
snmp-server user Adam ADMINS v3 auth sha C1sco12345! priv aes 128 cisco.123
snmp-server host 192.168.1.10 version 3 priv Adam
```
```
IOSvL2# show snmp user
User name: Adam
Engine ID: 800000090300525400A92A70
storage-type: nonvolatile active
Authentication Protocol: SHA
Privacy Protocol: AES128
Group-name: ADMINS
```
Here is a file capture of a trap, use the following details to decrypt it in Wireshark:
- Engine ID: *blank*
- Username: *Adam*
- Authentication Model: *SHA1*
- Password: *C1sco12345!*
- Privacy Protocol: *AES*
- Privacy Password: *cisco.123*
![[SNMPv3 PCAP.pcap]]
## SPAN, RSPAN, & ERSPAN
URL: https://adamspera.dev/services/span-rspan--erspan/
## SPAN (Switched Port Analyzer)
SPAN is a Cisco feature used for traffic mirroring. It copies Layer 2 packets from source interfaces or VLANs and forwards them to a destination port for analysis—commonly by a packet sniffer or analyzer tool.
SPAN is commonly used for:
- Troubleshooting network issues
- Packet capture for security analysis
- Application or performance monitoring
There are two types of SPAN:
- Local SPAN – source and destination are on the same switch
- Remote SPAN (RSPAN) – source and destination can be on different switches, using a special RSPAN VLAN
### Local SPAN
Local SPAN mirrors traffic within the same device (or stack).
#### Configuration
Define the source interface or VLAN, and then specify the destination interface:
```
monitor session 1 source interface GigabitEthernet1/0/1 [both | rx | tx]
monitor session 1 source vlan 10
monitor session 1 destination interface GigabitEthernet1/0/10
```
## Remote SPAN (RSPAN)
RSPAN allows traffic from a source port or VLAN on one switch to be mirrored to a destination port on another switch using a remote-span VLAN.
## Configurations
#### Step 1: Configure the RSPAN VLAN
All switches along the path must be aware of this VLAN and mark it as a `remote-span`.
```
vlan 100
remote-span
```
#### Step 2: Configure the Source Session
```
monitor session 1 source interface GigabitEthernet1/0/1
monitor session 1 destination remote vlan 100
```
This mirrors traffic to the remote-span VLAN.
#### Step 3: Configure the Destination Session
On the remote switch where the destination port exists:
```
monitor session 2 source remote vlan 100
monitor session 2 destination interface GigabitEthernet1/0/24
```
## SPAN Additional Configs
### VLAN Filtering (SPAN Source Filter)
Use this to limit traffic mirrored from a trunk port or VLAN source:
```
monitor session 1 filter vlan 10
```
Only traffic in VLAN 10 is mirrored.
### IP/MAC/IPv6 Filtering (FSPAN/FRSPAN)
Used for fine-grained traffic selection:
```
monitor session 1 filter ip access-group 101
```
The access-list can match specific source/destination IPs or MACs.
### Destination Encapsulation
The destination interface can replicate the encapsulation of the source:
```
monitor session 1 destination interface GigabitEthernet1/0/10 encapsulation replicate
```
- Mirrored packets **retain their 802.1Q tags**.
- Your analyzer sees whether a packet came from VLAN 10 or 20.
Or configure how inbound (ingress) packets are handled:
```
monitor session 1 destination interface GigabitEthernet1/0/10 ingress vlan 6
monitor session 1 destination interface GigabitEthernet1/0/10 ingress dot1q vlan 6
```
| Command Variant | Accepts Tagged? | Accepts Untagged? | Untagged VLAN Assignment |
| -------------------------------------- | --------------- | ----------------- | ------------------------ |
| `ingress dot1q vlan 6` | Yes | Yes | 6 |
| `ingress vlan 6`
`untagged vlan 6` | No | Yes | 6 |
## Encapsulated Remote SPAN (ERSPAN)
**ERSPAN** extends RSPAN by encapsulating mirrored traffic in **GRE** packets and sending it across **Layer 3 networks**. This allows packet monitoring **across IP networks**, not just within L2 broadcast domains.
Unlike SPAN or RSPAN, ERSPAN requires a **source IP**, **destination IP**, and **ERSPAN session ID**.
### Use Cases
- Monitor traffic from branch routers to a centralized data center.
- Capture traffic from remote devices across routed paths.
- Integrate with cloud-based or virtualized traffic analyzers.
### Configuration on IOS-XE
> The source router must have a route to the `ip address` aka the collector.
Guide from [Network Lessons](https://networklessons.com/system-management/erspan).
![[ERSPAN-TopologyNetworkLessons.png]]
#### Define the Source Session
```
! R1
monitor session 1 type erspan-source
no shutdown
source interface GigabitEthernet 2
destination
erspan-id 100
ip address 172.16.12.2
origin ip address 172.16.12.1
```
- `source interface`: Interface you want to mirror.
- `erspan-id`: Unique identifier for the ERSPAN session.
- `ip address`: IP of the **ERSPAN destination** (collector, eg. Wireshark host).
- `origin ip`: exit IP of the **ERSPAN source** (this device).
> The router will encapsulate mirrored packets in GRE with ERSPAN headers and send them to the collector.
#### Define the Destination Session
```
! R2
monitor session 1 type erspan-destination
no shutdown
destination interface GigabitEthernet 2
source
erspan-id 100
ip address 172.16.12.2
```
> The IP address entered must be matching the IP configured in the source session, pointing to the Wireshark or collector host.
## Verification
```
show monitor session 1
```
## Reference
[Cisco SPAN/RSPAN Whitepaper](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9400/software/release/17-3/configuration_guide/nmgmt/b_173_nmgmt_9400_cg/configuring_span_and_rspan.html)
## System Logging
URL: https://adamspera.dev/services/system-logging/
Cisco IOS provides flexible logging mechanisms to monitor, store, and export system messages. These messages can assist with troubleshooting, alerting, and change tracking.
## Local Logging Outputs
### Console Logging
```none
logging console
```
- Displays log messages to the **console terminal** (when physically connected).
- Enabled by default at level 7.
- Can be **rate-limited** by terminal settings.
### Monitor Logging (vty)
```none
logging monitor [level]
```
- Sends log messages to **vty (Telnet/SSH)** sessions.
- Use with `terminal monitor` inside the vty session to display logs.
- Log level can be specified (0–7):
| Level | Name | Description |
|-------|----------|-------------------------|
| 0 | emergencies | System is unusable |
| 1 | alerts | Immediate action needed |
| 2 | critical | Critical conditions |
| 3 | errors | Error conditions |
| 4 | warnings | Warning conditions |
| 5 | notifications | Normal but significant events |
| 6 | informational | Informational messages |
| 7 | debugging | Debug-level messages |
### Buffered Logging
```none
logging buffered [0-7]
```
- Stores log messages in **RAM** (viewed via `show log`).
- Size default is 4096 bytes; you can increase it for deeper history.
- Not persistent across reboots.
> Use `show logging` or `show log` to view buffered logs.
---
## External Logging (Syslog)
```none
logging host
logging trap
```
- Sends logs to an **external syslog server**.
- `logging trap` controls what severity level messages are sent.
## Timestamps
Timestamps provide time context for each log entry.
```none
service timestamps debug datetime msec
service timestamps log datetime msec
```
- Applies to **debug** and **log** messages.
- `msec` adds **millisecond precision**.
## Configuration Changes
Change notification is a nice feature on Cisco IOS devices that lets you keep track of the changes that have been made to your configuration. It can even track the user who made these changes and it can send this information to a syslog server.
To enable configuration change logging use the following:
```
R1(config)# archive
R1(config-archive)# log config
R1(config-archive-log-cfg)# logging enable
```
By default, devices will store the past 100, but this can be increased with:
```
R1(config-archive-log-cfg)# logging size 5000
```
For exporting these changes as syslog, use the following:
```
R1(config-archive-log-cfg)# notify syslog
```
If you do not want any credentials being logged in these logs, use teh follwoing:
```
R1(config-archive-log-cfg)# hidekeys
```
### Verifications
```
R1# show archive log config all
idx sess user@line Logged command
1 1 console@console | logging enable
2 1 console@console | logging size 5000
3 1 console@console | notify syslog
4 1 console@console | hidekeys
5 1 console@console | interface g 0
6 1 console@console | shutdown
7 1 console@console | no shutdown
```
```
R1# show archive log config all provisioning
archive
log config
logging enable
logging size 5000
notify syslog
hidekeys
interface g 0/0
shutdown
no shutdown
```
## VRF-Aware NAT & VASI
URL: https://adamspera.dev/services/vrf-aware-nat--vasi/
## VRF-Aware NAT
**VRF-Aware NAT** is used to allow traffic from a VRF (usually a customer or internal VRF) to be translated **before** it enters the global routing table.
Why? Because:
- Traffic leaving a VRF **must be NATed first**, or else the global routing table won’t know how to route it (since VRF routes are isolated).
- When return traffic comes back, the NAT process reverses the translation **before** it re-enters the VRF — so it doesn’t get dropped in the global VRF due to a missing route.
This creates a clean edge between the **VRF** and the **global routing table**, using NAT as a handoff between them.
> This NAT method **requires** the configuration of a route that points to an IP address that is not locally on itself. For NATing between VRFs without this limitation, use VASI if on IOS-XE.
### Key Concepts
- The **VRF has no direct routing knowledge** of global, and vice versa.
- A static route using the `global` keyword allows VRF traffic to **exit** toward the global next-hop.
- NAT ensures return traffic is **translated back into the originating VRF** before routing decisions are made globally (dropping the traffic).
### Configurations
```none
interface GigabitEthernet0/0
description To-WAN
ip address 10.0.0.2 255.255.255.252
ip nat outside
interface GigabitEthernet0/1
description To-LAN
ip address 192.168.1.1 255.255.255.0
vrf forwarding INSIDE
ip nat inside
```
```none
vrf definition INSIDE
rd 1:1
address-family ipv4
```
```none
ip route 0.0.0.0 0.0.0.0 10.0.0.1
ip route vrf INSIDE 0.0.0.0 0.0.0.0 10.0.0.1 global
```
> The `global` keyword enables traffic from the VRF to exit into the global space, assuming NAT occurs before it crosses the boundary. Without the following NAT configs, a ping could get out, but could not return, since you cannot have a route from Global pointing to a VRF.
```none
access-list 1 permit 192.168.1.0 0.0.0.255
ip nat inside source list 1 interface g0/0 vrf INSIDE overload
```
Explanation:
- Traffic from `192.168.1.0/24` (inside the VRF) gets **NATed** using the **outside interface IP** (`g0/0`).
- NAT happens **within the context of the `INSIDE` VRF**, ensuring translation occurs BEFORE hitting the global routing table.
- Return traffic from the WAN will be translated **back into the VRF** BEFORE forwarding decisions are made by the Global VRF.
## VRF-Aware Software Infrastructure (VASI)
[VASI Cisco IOS-XE Whitepaper](https://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/200255-Configure-VRF-Aware-Software-Infrastruct.html)
On **Cisco IOS XE**, classical inter-VRF NAT is **not directly supported**. To perform NAT between VRFs, Cisco introduced **VASI**: *VRF-Aware Software Infrastructure*.
### What is VASI?
VASI is a technique that enables **inter-VRF NAT** by creating **VASI interface pairs**:
- Each **VASI interface** is tied to a **different VRF**
- One is used as the **inside NAT** interface, the other as **outside**
- Packets are routed between them just like physical interfaces
- Example interface names: `vasileft1`, `vasiright1`
VASI interfaces act as **loopback-style virtual links**, switching packets between two VRFs at Layer 3.
> VASI is the supported method to implement inter-VRF NAT on IOS XE.
### Configuration
In this example, we are NATing from **VRF_LEFT** to **VRF_RIGHT** only.
![[VASI-CML.png]]
#### **NAT on `vasiright`**
**Typical use case.**
Most common scenario: the WAN or upstream-facing interface is part of **VRF_RIGHT**.
- **Vasiright1** (in VRF_RIGHT) is the **NAT inside**
- **GigabitEthernet2** (WAN-facing) is the **NAT outside**
```none
interface GigabitEthernet1
vrf forwarding VRF_LEFT
ip address 192.168.1.2 255.255.255.0
interface GigabitEthernet2
vrf forwarding VRF_RIGHT
ip address 172.16.1.2 255.255.255.0
ip nat outside
```
```
vrf definition VRF_LEFT
rd 1:1
address-family ipv4
vrf definition VRF_RIGHT
rd 2:2
address-family ipv4
```
```
interface vasileft1
vrf forwarding VRF_LEFT
ip address 10.1.1.1 255.255.255.252
interface vasiright1
vrf forwarding VRF_RIGHT
ip address 10.1.1.2 255.255.255.252
ip nat inside
```
```
access-list 1 permit any
ip route vrf VRF_LEFT 172.16.0.0 255.255.0.0 vasileft1 10.1.1.2
ip route vrf VRF_RIGHT 192.168.0.0 255.255.0.0 vasiright1 10.1.1.1
ip nat inside source list 1 interface GigabitEthernet2 vrf VRF_RIGHT overload
```
#### **NAT on `vasileft`**
In some designs, NAT is done **entirely within VRF_LEFT**, before sending traffic into VRF_RIGHT.
- **GigabitEthernet1** (LAN-facing) is the **NAT inside**
- **Vasileft1** (link to VRF_RIGHT) is the **NAT outside**
```none
interface GigabitEthernet1
vrf forwarding VRF_LEFT
ip address 192.168.1.2 255.255.255.0
ip nat inside
interface GigabitEthernet2
vrf forwarding VRF_RIGHT
ip address 172.16.1.2 255.255.255.0
interface vasileft1
vrf forwarding VRF_LEFT
ip address 10.1.1.1 255.255.255.252
ip nat outside
interface vasiright1
vrf forwarding VRF_RIGHT
ip address 10.1.1.2 255.255.255.252
access-list 1 permit any
ip route vrf VRF_LEFT 172.16.0.0 255.255.0.0 vasileft1 10.1.1.2
ip route vrf VRF_RIGHT 192.168.0.0 255.255.0.0 vasiright1 10.1.1.1
ip nat inside source list 1 interface vasileft1 vrf VRF_LEFT overload
```
---
# Security
## Access-Control Lists (ACLs)
URL: https://adamspera.dev/security/access-control-lists-acls/
## Overview
Access Control Lists (ACLs) filter traffic based on configured criteria. They process entries top-down and stop at the first match. An implicit "deny all" exists at the end of every ACL.
#### Numbered vs Named
- Numbered ACLs use numbers for identification
- Named ACLs use descriptive names and allow line editing
#### Standard vs Extended
- Standard ACLs filter on source IP only (1-99, 1300-1999)
- Extended ACLs filter on source, destination, protocol, and ports (100-199, 2000-2699)
Place standard ACLs close to destination, extended ACLs close to source.
## Standard ACLs
Standard ACLs examine source IP addresses using wildcard masks. Use `host` for exact matches and `any` for all addresses.
#### Numbered Standard ACLs
```
access-list 10 permit 192.168.1.0 0.0.0.255
access-list 10 permit host 10.1.1.1
access-list 10 deny any
interface GigabitEthernet0/1
ip access-group 10 in
```
#### Named Standard ACLs
```
ip access-list standard BRANCH_OFFICE
permit 192.168.1.0 0.0.0.255
permit host 10.1.1.1
deny any
interface GigabitEthernet0/1
ip access-group BRANCH_OFFICE out
```
**Editing**
```
ip access-list standard BRANCH_OFFICE
15 permit 10.1.1.0 0.0.0.255
no permit host 10.1.1.1
```
## Extended ACLs
Extended ACLs filter on source IP, destination IP, protocol, and ports. Use `eq`, `gt`, `lt`, or `range` for port specifications.
#### Numbered Extended ACLs
```
access-list 101 permit tcp 192.168.1.0 0.0.0.255 any eq 80
access-list 101 permit tcp 192.168.1.0 0.0.0.255 any eq 443
access-list 101 permit udp any any eq 53
access-list 101 deny ip any any
interface GigabitEthernet0/0
ip access-group 101 in
```
#### Named Extended ACLs
```
ip access-list extended WEB_TRAFFIC
10 permit tcp 192.168.1.0 0.0.0.255 any eq 80
20 permit tcp 192.168.1.0 0.0.0.255 any eq 443
30 permit udp any any eq 53
40 deny ip any any log
interface GigabitEthernet0/2
ip access-group WEB_TRAFFIC in
```
**Common Examples**
```
ip access-list extended SECURITY_POLICY
permit tcp any any eq 22
permit icmp any any
deny tcp any any eq 23
permit tcp any any established
deny ip any any log
```
**Verification**
```
show access-lists
show ip interface GigabitEthernet0/1
```
## Authentication, Authorization, and Accounting (AAA)
URL: https://adamspera.dev/security/authentication-authorization-and-accounting-aaa/
RADIUS and TACACS+ servers can be configured on Cisco IOS XE for centralized authentication and authorization.
## Old vs New Login Models
#### Old Model
- Uses **line-level** or **username-level** authentication and authorization.
- Simple, but lacks flexibility.
- No centralized control.
#### New Model
- Enables full **AAA (Authentication, Authorization, Accounting)** framework.
- Allows custom **method lists**.
- AAA method lists can be applied to different access technologies like:
- Console, VTY, PPP, etc.
## Authentication Protocols
#### TACACS+
- Cisco proprietary.
- Used for device admin access.
- Supports:
- Per-command authorization
- Per-command accounting
- Encrypts entire payload.
- **Uses port TCP 49**
#### RADIUS
- Open standard (RFC).
- Used for end-user authentication, e.g., VPN.
- Encrypts only the password field.
- Does not support per-command authorization/accounting.
- Uses the following ports:
- Ciscos Implementation
- **UDP 1645**: Authentication & Authorization
- **UDP 1646**: Accounting
- Industry Standard
- **UDP 1812**: Authentication & Authorization
- **UDP 1813**: Accounting
> **Best Practice:** Always configure **local fallback** in case external servers are unreachable.
## Local Login with AAA
```plaintext
aaa new-model
username admin password cisco
enable secret cisco123
aaa authentication login default local
aaa authentication enable default enable
aaa authorization exec default local
line vty 0 4
login authentication default
```
## RADIUS Example
```plaintext
aaa new-model
radius server RAD-SERVER-1
address ipv4 192.100.3.51 auth-port 1645 acct-port 1646
key cisco1
radius server RAD-SERVER-2
address ipv4 192.100.3.52 auth-port 1645 acct-port 1646
key cisco2
aaa group server radius RAD-GROUP
server name RAD-SERVER-1
server name RAD-SERVER-2
ip vrf forwarding Mgmt-vrf
aaa authentication login RADIUS-LIST group RAD-GROUP
aaa authentication enable default group RAD-GROUP
aaa authorization exec RADIUS-LIST group RAD-GROUP
line vty 0 4
login authentication RADIUS-LIST
```
> Note that the order in which the `server name <>` commands are issues to the group dictates the failover order. This being that, the first one added will have highest priority. In the running-config, the first one in the group, will be tried first.
## TACACS Example
```
aaa new-model
tacacs server TAC-SERVER-1
address ipv4 172.16.2.78
key cisco1
tacacs server TAC-SERVER-2
address ipv4 172.16.2.79
key cisco2
aaa group server tacacs TAC-GROUP
server name TAC-SERVER-1
server name TAC-SERVER-2
ip vrf forwarding Mgmt-vrf
aaa authentication login TACACS-LIST group TAC-GROUP
aaa authentication enable default group TAC-GROUP
aaa authorization exec TACACS-LIST group TAC-GROUP
line vty 0 4
login authentication TACACS-LIST
```
> Note that the order in which the `server name <>` commands are issues to the group dictates the failover order. This being that, the first one added will have highest priority. In the running-config, the first one in the group, will be tried first.
## Default AAA List
The specified default method will be applied to all lines (cty, vty, aux, etc.) but notably does NOT apply to the console.
```
...
aaa authentication login default group TAC-GROUP local
line vty 0 4
login authentication default
```
To apply a specific list to a line use the explicit config with:
```
...
line vty 0 4
login authentication TACACS-LIST
```
> If you want to have AAA apply to the console port, use the following command`aaa authorization console`.
## Command Auth & Accounting
Enable this whole section by issuing:
```
aaa authorization config-commands
```
Setup command authorization with the following:
```
aaa authorization commands {priv} { default | list-name } ... if-authenticated
aaa authorization commands 0 default group TAC-GROUP if-authenticated
aaa authorization commands 1 default group TAC-GROUP if-authenticated
aaa authorization commands 15 default group TAC-GROUP if-authenticated
```
> The command `if-authenticated` allows users to input commands even if a AAA server is offline. This is because with command authorization, if an AAA server cannot be reached, the user will not be able to enter any commands. **The `if-authenticated` command allows them to enter commands without a reachable AAA server, IF the user is already signed-into the device.**
> The command `if-authenticated` can be `local` instead. This works the same, but instead of checking if the user is already logged in, it checks the current users credentials against the local username and password database.
## Login Cosmetics
```
Device> enable
Device# configure terminal
Device(config)# aaa new-model
Device(config)# aaa authentication banner *Unauthorized Access Prohibited*
Device(config)# aaa authentication fail-message *Failed login. Try again.*
Device(config)# aaa authentication login default group radius
```
This configuration displays the following login banner:
```
Unauthorized Access Prohibited
Username:
```
The following example shows how to configure a failed-login banner that is displayed when a user tries to log in to the system and fails, (in this case, the phrase “Failed login. Try again”). The asterisk (*) is used as the delimiting character. RADIUS is specified as the default login authentication method.
This configuration displays the following login and failed-login banner:
```
Unauthorized Access Prohibited
Username:
Password:
Failed login. Try again.
```
## Control Plane Policing (CoPP)
URL: https://adamspera.dev/security/control-plane-policing-copp/
Control Plane Policing (CoPP) is a security mechanism used to protect the **CPU** of a network device by filtering or rate-limiting traffic that is destined **to** the control plane. This includes routing updates, management traffic, and protocols like BGP, OSPF, SSH, etc.
## Implementation Flow
1. Create an **ACL** to match traffic
2. Reference it in a **class-map**
3. Define behavior in a **policy-map**
4. Apply the policy to the **control-plane**
## Example: Drop ICMP to Control Plane
```plaintext
ip access-list extended ICMP
permit icmp any any
class-map match-all ICMP
match access-group name ICMP
policy-map COPP_POLICY
class ICMP
drop
control-plane
service-policy input COPP_POLICY
```
This will **drop all ICMP traffic** destined to the control plane, protecting the CPU.
## Example: Rate Limit ICMP
```plaintext
policy-map COPP_POLICY
class ICMP
police 8000
conform-action transmit
exceed-action drop
```
- Limits ICMP to **8000 bps**.
- Conforming packets are **forwarded**, excessive packets are **dropped**.
## Verification
```plaintext
show policy-map control-plane
```
- View counters and hits on CoPP classes.
- Helps confirm traffic is being policed or dropped.
## Notes
- **Control plane policing** only affects **traffic to the device**, not through it.
- Not all match types are supported under `class-map` for CoPP.
## DHCP Snooping & Option 82
URL: https://adamspera.dev/security/dhcp-snooping--option-82/
## Overview
DHCP snooping prevents DHCP server spoofing and exhaustion attacks by controlling which ports can respond to DHCP requests. It maintains a binding table that tracks IP-to-MAC-to-port relationships for security enforcement.
**Key Functions**
- Only trusted ports may respond to DHCP discover messages
- Maintains IP, MAC, and port bindings for verification
- Inspects DHCP messages on untrusted ports
All ports are untrusted by default. Uplinks and DHCP server ports should be configured as trusted so messages are not inspected.
## Basic Configuration
```
ip dhcp snooping
ip dhcp snooping vlan 1
interface Ethernet1/1
description To-DHCP-Server
ip dhcp snooping trust
```
**Note:** Always trust the port connected to your DHCP server. In multi-switch scenarios, also trust the uplink side of trunk links between switches.
## DHCP Message Inspection
When DHCP messages arrive on untrusted ports, the switch inspects them according to these rules:
**Server Messages (OFFER, ACK, NACK)**
- Always dropped on untrusted ports
**Client Messages**
- **DISCOVER/REQUEST:** Source MAC must match the DHCP message CHADDR field
- **RELEASE/DECLINE:** Source IP and interface must match the snooping binding table entry
- **Any message with Option 82:** Dropped
## Binding Table
The DHCP snooping binding table records successful DHCP assignments including IP address, MAC address, interface, and lease time. This information is used to verify RELEASE and DECLINE messages from clients.
```
show ip dhcp snooping binding
```
The binding table ensures that only the legitimate client that received an IP address can send RELEASE or DECLINE messages for that address.
## Rate Limiting
DHCP snooping can rate-limit DHCP messages per interface. If the rate limit is exceeded, the port enters error-disabled state.
```
interface Ethernet1/2
ip dhcp snooping limit rate 10
errdisable recovery cause dhcp-rate-limit
```
This limits the interface to 10 DHCP messages per second. Configure rate limiting on client-facing ports to prevent DHCP exhaustion attacks.
## DHCP Option 82
DHCP Option 82 (relay agent information option) provides additional information about where the DHCP message was received. DHCP relay agents typically add this option when forwarding messages to remote DHCP servers.
> **Default Behavior:** With DHCP snooping enabled, the switch automatically adds Option 82 to messages from untrusted ports, even when not acting as a DHCP relay agent.
**Common Issues**
- Upstream trunk trusted ports will drop messages with Option 82
- DHCP servers will reject messages with Option 82 that weren't added by actual relay agents
### Disabling Insertion
```
no ip dhcp snooping information option
```
Use this command when Option 82 insertion causes issues with your DHCP server or upstream devices.
## Verification
```
show ip dhcp snooping
show ip dhcp snooping binding
show ip dhcp snooping database
show errdisable recovery
```
## Dynamic ARP Inspection (DAI)
URL: https://adamspera.dev/security/dynamic-arp-inspection-dai/
## Overview
Dynamic ARP Inspection (DAI) prevents ARP poisoning attacks by inspecting ARP requests and responses on untrusted ports. It validates ARP messages against the DHCP snooping binding table to ensure legitimate IP-to-MAC mappings.
For more info on DHCP Snooping, visit [[DHCP Snooping & Option 82]].
**Key Functions**
- Filters ARP messages received on untrusted ports
- Validates sender MAC and IP fields against DHCP snooping binding table
- Drops ARP messages without matching binding table entries
All ports are untrusted by default. Interfaces connected to switches or routers should be trusted, while end host ports should remain untrusted.
## Basic Configuration
```
ip arp inspection vlan 1
interface Ethernet1/1
description To-Another-Switch
ip arp inspection trust
```
**Note:** DHCP snooping must be enabled for DAI to function, as it relies on the DHCP snooping binding table for validation.
## How DAI Works
DAI inspects ARP messages on untrusted ports by checking the DHCP snooping binding table, which contains:
- IP address
- MAC address
- Interface
- VLAN
- Lease time
**Validation Process:**
- **Match found:** ARP message forwarded normally
- **No match found:** ARP message dropped
- **Trusted ports:** No inspection performed
## ARP Access Lists
Use ARP ACLs when DHCP snooping is not available or when hosts use static IP assignments.
```
arp access-list ARP-ACL-1
permit ip host 192.168.1.100 mac host 0001.0002.0003
permit ip host 192.168.1.101 mac host 0001.0002.0004
ip arp inspection filter ARP-ACL-1 vlan 1
```
ARP ACLs provide an alternative validation method for environments without DHCP.
## Rate Limiting
**Default behavior:** DAI rate limiting is enabled by default on untrusted ports with a limit of 15 packets per second. This differs from DHCP snooping, where rate limiting is disabled by default.
### Configuring Rate Limits
```
interface Ethernet1/2
ip arp inspection limit rate 25
errdisable recovery cause arp-inspection
errdisable recovery interval 300
```
### Burst Interval Configuration
```
interface Ethernet1/2
ip arp inspection limit rate 25 burst interval 2
```
This allows 25 ARP messages per 2 seconds before placing the interface into error-disabled state.
## Additional Validation Checks
Enable additional validation checks on untrusted ports for enhanced security:
```
ip arp inspection validate dst-mac src-mac ip
```
**Validation Options:**
- **src-mac:** Checks ARP body source MAC against Ethernet header source MAC
- **dst-mac:** Checks ARP body destination MAC against Ethernet header destination MAC
- **ip:** Validates IP addresses (no 0.0.0.0, 255.255.255.255, or multicast addresses)
**Important:** All specified validations must pass for ARP messages to be forwarded. None are enabled by default.
### Individual Validation Commands
```
ip arp inspection validate src-mac
ip arp inspection validate dst-mac
ip arp inspection validate ip
```
Note that when configured like this, the newer command will override the last two or previous.
## Logging
```
ip arp inspection vlan 1 logging acl-match matchlog
ip arp inspection vlan 1 logging dhcp-bindings all
```
## Verification
```
show ip arp inspection
show ip arp inspection interfaces
show ip arp inspection vlan 1
show ip arp inspection statistics
```
## IP Source Guard
URL: https://adamspera.dev/security/ip-source-guard/
## Overview
IP Source Guard prevents IP address spoofing by dynamically filtering IP addresses on switch ports. It uses the DHCP snooping binding table to validate that hosts are using their legitimately assigned IP addresses.
**Key Functions:**
- Filters IP traffic based on DHCP snooping binding table
- Prevents hosts from using unauthorized IP addresses
- Can optionally validate MAC addresses when combined with port security
## Basic IP Address Filtering
```
ip dhcp snooping
ip dhcp snooping vlan 1
interface Ethernet1/2
description Client-Port
ip verify source
```
**Note:** DHCP snooping must be enabled as IP Source Guard relies on the DHCP snooping binding table for validation.
## Manual (without DHCP snooping)
```
(config)# ip source binding aa.bb.cc.dd.ee.ff vlan 10 192.168.1.10 interface g0/0
```
## How IP Source Guard Works
IP Source Guard creates dynamic access control entries based on the DHCP snooping binding table. Only traffic from IP addresses that match binding table entries is permitted on the interface.
**Validation Process:**
- Checks source IP of incoming packets
- Compares against DHCP snooping binding table entries
- Permits matching traffic, drops non-matching traffic
## IP and MAC Address Filtering
For enhanced security, combine IP Source Guard with port security to validate both IP and MAC addresses:
```
interface Ethernet1/2
description Client-Port
switchport port-security
ip verify source port-security
```
**Requirements:**
- Port security must be enabled on the interface
- Both IP and MAC addresses are validated against binding table
## Verification
```
show ip verify source
show ip dhcp snooping binding
```
## Local Privilege & Role-Based Access Control (RBAC)
URL: https://adamspera.dev/security/local-privilege--role-based-access-control-rbac/
These features are for limiting what users can do when logged in.
## Local Privilege Levels
Uses **privilege levels** to control command access:
#### Level 0
Includes the **disable**, **enable**, **exit**, **help**, and **logout** commands.
#### Level 1
Also known as **User EXEC** mode. The command prompt in this mode includes a greater than sign (R1>). From this mode it is not possible to make configuration changes; in other words, the command **configure terminal** is not available.
#### Levels 2 - 14
These additional privilege levels ranging from 2 to 14 can be configured to provide customized access. The configuration mode command `privilege {mode} level {level} {command}` is used to change or set a privilege level for a command to any of the levels.
The following configuration shows where the user `aspera` is created with the type 9 (scrypt) password of `cisco`. This user is set to be placed into privilege level 5 upon login, and is only able to enter interfaces, shut it down, unshut it, and apply an IP address to it, then save the configs, as defined in privilege level 15.
```
username aspera privilege 5 algorithm-type scrypt secret cisco
privilege exec level 5 configure terminal
privilege exec level 5 copy running-config startup-config
privilege configure level 5 interface
privilege interface level 5 shutdown
privilege interface level 5 no shutdown
privilege interface level 5 ip address
```
```
R1# show running-config
!
username aspera privilege 5 secret 9 $9$FkX9u0j...
!
privilege interface level 5 shutdown
privilege interface level 5 ip address
privilege interface level 5 ip
privilege interface level 5 no shutdown
privilege interface level 5 no ip address
privilege interface level 5 no ip
privilege interface level 5 no
privilege configure level 5 interface
privilege exec level 5 copy running-config startup-config
privilege exec level 5 copy running-config
privilege exec level 5 copy
privilege exec level 5 configure terminal
privilege exec level 5 configure
```
> Note that when you set a privilege level for a multi word command like `no shutdown` each word in the command gets its own privilege level, since the full string cannot be executed without also executing each individual word.
#### Level 15
Also known as **Privileged EXEC** mode. This is the highest privilege level, where **all commands are available**. The command prompt in this mode includes a hash sign (R1#).
## Role-Based Access Control (RBAC)
More granular than privilege levels.
- **Roles = Views**
- Views define command access
- Can be **enabled manually** or **assigned to users**
- Requires **AAA enabled**
### Parsers & Views
```plaintext
parser view FIRST inclusive
secret firstpass
command exec exclude show version
command exec exclude show all ip
command exec exclude configure terminal
parser view SECOND
secret secondpass
command exec include show version
command exec include show all ip
command exec include-exclusive configure terminal
```
> `inclusive` views deny by default, and only allow included commands.
> `exclusive` views allow by default, and only deny explicitly excluded commands.
> `include-exclusive` means this command can **only belong to this view**.
### Assigning Views to Users
```plaintext
username admin view SECOND password cisco
aaa authentication login default local
aaa authorization exec default local
```
Note that users can switch views while logged in with the `enable view [view-name]` command, and will have to enter the views specific password.
## Port & VLAN Access-Control Lists (PACLs & VACLs)
URL: https://adamspera.dev/security/port--vlan-access-control-lists-pacls--vacls/
## PACL
Port Access-Control Lists are the same as RACLs (Router Access-Control Lists), just they are applied to a `switchport`. See the below example of a PACL:
```
interface Ethernet1/1
ip access-group 100 in
```
What is the difference then? **PACLs can filter MAC addresses.**
> PACLs will only affect traffic in the INBOUND direction, despite how configured.
## VACL
VACL is a feature that allows access-control filtering to be applied **across an entire VLAN**, including:
- Traffic between ports in the same VLAN (even if not routed)
- Trunk ports
- Access ports
- SVI (Switched Virtual Interface)
Unlike standard port ACLs or router ACLs, **VACLs inspect all traffic within a VLAN**, regardless of L2/L3 boundaries.
> Best Practice: **Avoid relying on implicit deny** in VACLs. Explicitly forward all non-matched traffic using a separate sequence to avoid unintentionally dropping critical traffic.
### Step 1: Create an Extended ACL
The ACL defines the **target traffic** to match. In this example, we target **Telnet** traffic (TCP port 23).
```plaintext
ip access-list extended TELNET
10 permit tcp any any eq telnet
```
> Note: In the context of a VACL, the ACL's **permitted** traffic is the traffic that will be acted upon by the access-map. Denied traffic is ignored.
### Step 2: Create a VLAN Access Map
VLAN access-maps act like policy maps. They take actions (e.g. drop or forward) based on access-list matches.
```plaintext
vlan access-map DROP_TELNET 10
match ip address TELNET
action drop log
vlan access-map DROP_TELNET 20
action forward
```
Explanation:
- **Sequence 10**: Matches the `TELNET` ACL and drops matching traffic.
- **Sequence 20**: Forwards all other traffic.
### Step 3: Apply the Access Map
Apply the VLAN access-map to one or more VLANs:
```plaintext
vlan filter DROP_TELNET vlan-list 10
```
This enables the access-map on VLAN 10.
### Verifying VACLs
```plaintext
show vlan access-map
show vlan filter
```
## Port Security
URL: https://adamspera.dev/security/port-security/
## Overview
Port security allows you to control which source MAC addresses are permitted to enter on switch ports. When an unauthorized source MAC address enters the port, an action will be taken. By default, the port will be placed into an error-disabled state.
When you enable port security, it will by default only allow one MAC address. If you don't configure it manually, it will allow the first MAC address received and use that as the authorized address. However, you can change the number of allowed addresses.
For example, with an IP phone scenario where you expect both a phone and PC, you would set the MAC limit to 2. In this scenario, if you do not configure them manually, the first 2 MAC addresses detected will be added to the allowed list.
## Basic Configuration
```
interface Ethernet1/1
switchport mode { access | trunk }
switchport port-security
switchport port-security maximum { number }
```
The above configuration block enables the **default port-security settings** for the interface, which includes:
- Allows up to 1 MAC address
- Uses the first received MAC address as the allowed MAC
## Verification
To verify the status of port-security on an interface, use the following verification command:
```
SW1# show port-security interface Ethernet0/1
Port Security : Enabled
Port Status : Secure-up
Violation Mode : Shutdown
Aging Time : 0 mins
Aging Type : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses : 1
Total MAC Addresses : 0
Configured MAC Addresses : 0
Sticky MAC Addresses : 0
Last Source Address:Vlan : 0000.0000.0000:0
Security Violation Count : 0
```
After connecting an end host and sending a ping, you can see that the output has changed to record the MAC address and increase the total MAC address count:
```
SW1# show port-security interface Ethernet0/1
Port Security : Enabled
Port Status : Secure-up
Violation Mode : Shutdown
Aging Time : 0 mins
Aging Type : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses : 1
Total MAC Addresses : 1 <---------
Configured MAC Addresses : 0
Sticky MAC Addresses : 0
Last Source Address:Vlan : 000a.000a.000a:1 <---------
Security Violation Count : 0
```
To test the shutdown functionality, if you change the MAC address on the router and send another ping, you'll see the following output:
```
%PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 000d.000d.000d on port Ethernet0/1.
%PM-4-ERR_DISABLE: psecure-violation error detected on Et0/1, putting Et0/1 in err-disable state
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to down
SW1# show port-security interface Ethernet0/1
Port Security : Enabled
Port Status : Secure-shutdown
Violation Mode : Shutdown
Aging Time : 0 mins
Aging Type : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses : 1
Total MAC Addresses : 0
Configured MAC Addresses : 0
Sticky MAC Addresses : 0
Last Source Address:Vlan : 000d.000d.000d:1 <---------
Security Violation Count : 1 <---------
SW1# show interface Ethernet0/1 status
Port Status Vlan
Ethernet0/1 err-disabled 1
```
> **Note:** After the port is shut down, the initially learned MAC address is cleared. This means that after an error occurs and the port is shut down, a new MAC can be learned again once the port is re-enabled.
## Re-enabling a Disabled Port
To re-enable the port, you can use one of the following methods:
**Manual Reset:**
```
interface Ethernet0/1
shutdown
no shutdown
```
**Automatic Recovery:**
```
errdisable recovery cause psecure-violation
errdisable recovery interval 300
```
## Violation Modes
There are three different violation modes that determine what the switch will do if an unauthorized frame enters an interface configured with port security:
### Shutdown
- Default mode.
- Effectively shuts down the interface by placing it into an error-disabled state
- Generates syslog and SNMP messages on initial disable
- Violation counter is set to 1 when the interface is disabled and returns to 0 after being re-enabled
### Restrict
- Switch discards traffic from unauthorized MACs but does not disable the interface
- Generates syslog and SNMP messages every time a frame from an unauthorized MAC is detected
- Violation counter is incremented by 1 for each unauthorized frame
### Protect
- Switch discards traffic from unauthorized MACs but does not disable the interface
- Does NOT generate syslog or SNMP traffic
- Does NOT increment the violation counter
### Configuring Violation Modes
```
switchport port-security
switchport port-security mac-address 000a.000a.000a
switchport port-security violation { restrict | protect }
```
## Secure MAC Address Aging
By default, secure MAC addresses will not "age out" (aging time of 0).
```
switchport port-security aging-time {minutes}
```
#### Absolute
- Default mode.
- After the secure MAC address is learned, the aging timer starts and the MAC is removed after it expires, even if it continues receiving frames from that source MAC
- After it ages out, it can be re-learned
#### Inactivity
- After the secure MAC address is learned, the aging timer starts, but every time traffic from that MAC is received, the timer is reset
#### Configuring Aging Types
```
switchport port-security aging type { absolute | inactivity }
```
> **Note:** By default, only dynamically learned addresses will age out. Manual entries are not aged out by default. If you want manually configured secure MACs to time out, you can use the `switchport port-security aging static` command to enable that behavior.
## Sticky Secure MAC Addresses
To enable sticky secure MAC addresses, use the following command:
```
switchport port-security mac-address sticky
```
When enabled, all existing and new dynamically learned secure MAC addresses will be added to the running configuration as `switchport port-security mac-address sticky {mac}` entries.
> **Important:** These sticky MAC addresses will **NEVER** age out, even with the `switchport port-security aging static` command. However, since they are added to the running configuration, they will be lost on reload if not saved to the startup configuration.
## Unicast Reverse Path Forwarding (uRPF)
URL: https://adamspera.dev/security/unicast-reverse-path-forwarding-urpf/
Normally when your router receives unicast IP packets, it only cares about one thing:
> What is the destination IP address of this IP packet so I can forward it?
If the IP packet has to be routed it will check the routing table for the destination IP address, select the correct interface and it will be forwarded. Your router really doesn’t care about source IP addresses as it’s not important for forwarding decisions.
Because the router doesn’t check the source IP address it is possible for attackers to spoof the source IP address and send packets that normally might have been dropped by the firewall or an access-list.
## Overview
uRPF is a security feature that prevents these spoofing attacks. Whenever your router receives an IP packet it will check if it has a **matching entry in the routing table for the source IP address**. If it doesn’t match, the packet will be discarded. uRPF has two modes:
- **Strict mode**
- **Loose mode**
## Strict Mode
Strict mode means that that router will perform **two checks** for all incoming packets on a certain interface:
- Do I have a matching entry for the source in the **routing table**?
- Do I use the **same interface to reach this source** as where I received this packet?
When the incoming IP packets **pass both checks**, it will be permitted. Otherwise, it will be dropped. This is perfectly fine for IGP routing protocols since they use the shortest path to the source of IP packets. The interface that you use to reach the source will be the same as the interface where you will receive the packets on.
```
ip cef distributed
interface Ethernet1/1
ip verify unicast source reachable-viw rx
```
## Loose Mode
Loose mode means that the router will perform only a **single check** when it receives an IP packet on an interface:
- Do I have a matching entry for the source in the **routing table**?
When it passed this check, the packet is permitted. Whether we use this interface to reach the source or not doesn’t matter. Loose mode is useful when you are connected to more than one ISP, and you use **asymmetric routing**. The only exception is the null0 interface, if you have any sources with the null0 interface as the outgoing interface, then the packets will be dropped.
```
ip cef distributed
interface Ethernet1/1
ip verify unicast source reachable-viw any
```
## Users & Passwords on IOS
URL: https://adamspera.dev/security/users--passwords-on-ios/
#### Types of Encryption
- Type 0 - plaintext
- `username <> password <>`
- Type 5 - MD5
- `username <> secret <>`
- Type 7 - Vigenere
- `service password-encryption`
- Type 8 - PBKDF2 with SHA-256
- `username <> alrgorithm-type sha256 secret <>`
- Type 9 - SCRPYPT
- `username <> alrgorithm-type scrypt secret <>`
> Type 7 is only used with the `service password-encryption` feature, which can be easily cracked. This is only used for preventing over the shoulder looks, see the below example:
```
show running-config
> username admin password cisco
(config)# service password-encryption
show running-config
> username admin password 7 01100F175804
```
#### Creating a User
```
! Type 0
username {username} password {password}
! Type 5
username {username} secret {password}
! Type 8 or 9
username {username} algorithm-type { sha256 | scrypt } secret {password}
```
#### Enable Passwords
Enable password are a tool for administrators to increase their privileges to the maximum, which is privilege level 15, which has all access to the device.
```none
enable password <>
```
- Stored in **cleartext** unless encrypted with `service password-encryption` (Level 7).
- Not recommended for modern deployments, as it can be cracked easily.
```none
enable secret <>
```
```
show running-config
> username admin secret 5 $9$YeaXVbtVOzNIa
```
- Encrypted using **MD5** by default (level 5).
- Overrides `enable password` if both are configured.
This password can be used by admins by issuing the `enable` command from User EXEC mode. Mor einfo on these privilege levels in [[Local Privilege & Role-Based Access Control (RBAC)]].
---
# Nexus Dashboard
## Basics of VXLAN EVPN in NDFC
URL: https://adamspera.dev/nexus-dashboard/basics-of-vxlan-evpn-in-ndfc/
## About This Document
This document serves as a guide for basic configuration of the Data Center VXLAN EVPN fabric type in Nexus Dashboard Fabric Controller (NDFC).
**Prerequisites**:
- Nexus Dashboard (ND) node with the NDFC deployment mode.
- [[Installing ND v3.2.x on ESXI]]
- CML or EVE-NG running at-least 3-4 Nexus 9000v switches.
- Mgmt0 interfaces of N9Kv devices must be reachable via NDFCs Mgmt or Fabric interfaces.
- Switches discovered and added to a fabric of type Data Center VXLAN EVPN.
- [[Getting Started with NDFC]]
- Switches with roles assigned as at-least 2 Leafs and 2 Spines.
- [[Getting Started with NDFC]]
This guide uses version **Nexus Dashboard 3.2(1i)** and the latest NDFC version.
**Instructions will be indicated bellow the associated screenshot.**
### Environment
![[Basic VXLAN EVPN DNFC Details.png]]
### Objective
The goal of this guide is to configure an NDFC Fabric of type Data Center VXLAN EVPN to have 2 VLANs using VXLAN EVPN, with Multicast and Anycast Gateways.
- "Crossing Boundaries" (VLAN 10) - 192.51.100.0/24
- "Integrated Experiences" (VLAN 20) - 203.0.113.0/24
By the end of this guide, hosts will be connected to port "Ethernet 1/3" on all leafs, and with the following network allocation:
- Host-1 <> N9Kv-4 (VLAN 10)
- Host-2 <> N9Kv-5 (VLAN 20)
- Host-3 <> N9Kv-6 (VLAN 10)
- Host-4 <> N9Kv-7 (VLAN 20)
These hosts within the same subnet should be able to ping eachother without the use of Anycast Gateways, then should be able to use the Anycast Gateways for inter-vlan routing, to ping hosts in other subnets.
## Method of Procedure
0. **Prerequisites**
To get started, make sure that the Ethernet1/3 interfaces are in the `no shutdown` state. Then connect the hosts, and ensure that the port state becomes `up`.
2. **Interface Groups**
First we are going to create two Interface Groups, each of which will act as Access Ports for their associated VLANs.
2. **Fabric VRF**
Then as a prerequisite to creating the Networks, we start by creating our Fabric VRF which will contain all the in-band fabric VXLAN traffic networks.
3. **Networks**
Lastly we can create the networks (VLANs), assign the VLAN IDs, VNIDs, VRF, Anycast Gateway addresses, and names. Then once created, they can be Attached to the relevant leafs, associating them to the Interface Groups.
## Prerequisites
*Connect end hosts to the Ethernet1/3 interface of each leaf on CML or EVE-NG.*
> For this demo, IOSv routers will be used as hosts, for the ease of configuration.
Navigate to the Fabric you will be working in via **Manage > Fabrics > \[FABRIC] > Interfaces**.
![[ND NDFC Basics Interfaces Up.png]]
Click into the "**Filter by attributes**" search bar, then enter the query `Interface == Ethernet1/3` to search for all interfaces with the name "Ethernet1/3".
Ensure that the relevant switches have that interface as `Up` and `Up`, meaning that the host is successfully connected to the interface.
![[ND NDFC Basics Down No Shut.png]]
*In the above example, the port is `Admin Status = Up` so performing `no shut` will have no affect.*
If the interfaces are in an `Admin Status = Down` then you must select that interface via the **checkbox**, then select the **Actions** drop-down, then choose "**No Shutdown**", then **Deploy**.
If the interfaces are in an `Oper. Status = Down` and `Admin Status = Up` then something is wrong with your end host setup, as the interface is ready to come up.
## Interface Groups
> An interface group consists of multiple interfaces with the same attributes. You can create an interface group that allows grouping of host-facing interfaces at a fabric-level. Specifically, you can create an interface group for physical Ethernet interfaces, Layer 2 port-channels, and VPCs.
### Creating the Groups
Navigate to the **Interface Groups** tab of the Fabric screen via **Fabric > Interface Groups**.
![[ND NDFC Basics Create Interface Group 1.png]]
Select from the **Actions** drop-down on the table the "**Create interface group**" option.
![[ND NDFC Basics Create Interface Group 2.png]]
Here since these ports need to act as Access Ports, and policy templates for access ports are not supported, using the Native VLAN on a trunk port will serve the same purpose.
When done customizing the interface settings, click the "**Create**" button at the bottom right.
![[ND NDFC Basics Created Interface Groups.png]]
**Repeat this step for both networks specified.**
### Adding Member Interfaces
Navigate to the **Interfaces** tab of the Fabric screen via **Fabric > Interfaces**.
Click into the "**Filter by attributes**" search bar, then enter the query `Interface == Ethernet1/3` to search for all interfaces with the name "Ethernet1/3".
![[ND NDFC Basics Add To Interface Group 1.png]]
Select the **checkboxes** next to the **interfaces** you what to add to the **Interface Group** per network.
Then select the **Actions** drop-down on the table, then hover over **More**, then select the "**Add to Interface Group**" option.
![[ND NDFC Basics Add To Interface Group 2.png]]
Select which **Interface Group** you want the interfaces to be members of, then click the "**Save**" button at the bottom right.
**Repeat this step for both sets of interfaces specified.**
![[ND NDFC Basics Verify Interface Groups Members.png]]
You can verify that the interfaces are now members of the associated Interface Groups by navigating back to the Interface Groups tab, then viewing the Interfaces column.
## Fabric VRF
> When creating a Network (next section), one of the requirements is to specify a non-default VRF, so users are to create a Fabric VRF for VXLAN traffic.
Navigate to the **Interfaces** tab of the Fabric screen via **Fabric > Interfaces**.
![[ND NDFC Basics Create Fabric VRF.png]]
Select the **Actions** drop-down at the top right of the table, then select the "**Create**" option.
![[ND NDFC Basics Create VRF Details.png]]
Now enter the VRF name in the "**VRF Name**" field, then make sure to leave the VLAN ID field empty.
When done, click the "**Create**" button at the bottom right.
## Networks
Navigate to the **Networks** tab of the Fabric screen via **Fabric > Networks**.
![[ND NDFC Basics Create Network 1.png]]
Select from the top right table **Action** drop-down the "**Create**" option.
### Layer 2 Only
> Per the requirements in the Objectives section, hosts must be able to ping eachother without an Anycast Gateway, so for now, we will be configuring a "Layer 2 only" network, until next step.
![[ND NDFC Basics Create Network L2.png]]
Enter the following information in the fields:
- **Network Name**: display name of this object
- **Layer 2 only**: enabled
- **Network ID**: same as VLAN ID
- **VLAN ID**: required VLAN ID
- **General Parameters > VLAN Name**: name of the VLAN
> *Notice that with the "**Layer 2 only**" field selected, the **VRF** field is no longer required. This means that even if you enter **Anycast Gateway** information, it will not function.*
When complete, click the "**Create**" button at the bottom right.
**Repeat this step for both VLANs needed.**
### Attaching Networks
Navigate to the **Networks** tab of the Fabric screen via **Fabric > Networks**.
![[ND NDFC Basics Attach Network To Interface Group 1.png]]
Select the **Actions** drop-down from the top right of the table, and select the "**Add to Interface Group**" option.
Then select the **Interface Group** applicable, then click the "**Save**" button at the bottom right.
![[ND NDFC Basics Attaching Networks To Interface Groups 2.png]]
#### Deploying Changes
Select the **Actions** drop-down at the very top bar of the Fabric Screen and select "**Recalculate and Deploy**". Go through the process of deploying these changes. For instruction on this, reference [[Getting Started with NDFC]].
For the demo environment, the **Pending Config** is as follows for N9Kv-6:
```
interface ethernet1/3
switchport
switchport mode trunk
mtu 9216
spanning-tree bpduguard enable
spanning-tree port type edge trunk
switchport trunk native vlan 10
no shutdown
switchport trunk allowed vlan 10
vlan 10
vn-segment 10
name Crossing_Boundaries
configure terminal
interface nve1
member vni 10
mcast-group 239.1.1.1
evpn
vni 10 l2
rd auto
route-target import auto
route-target export auto
configure terminal
```
*From this output, you can see that the interface will be functioning as a sudo-access port on the correct VLAN, the VLAN is being propagated into VXLAN via Multicast, and the NVE is being advertised.*
#### Testing with Hosts
Log onto each host and assign the following IP Addresses:
- **Host-1**: 192.51.100.10/24
- **Host-2**: 203.0.113.10/24
- **Host-3**: 192.51.100.20/24
- **Host-4**: 203.0.113.20/24
If you are using IOSv routers like in this demo environment, you can use the following commands to configure the hosts:
```
enable
configure terminal
hostname Host-1
interface GigabitEthernet 0/0
ip address 192.51.100.10 255.255.255.0
no shutdown
ip route 0.0.0.0 0.0.0.0 192.51.100.1
```
*Note that the default route will not work, or need to be used until Layer 3 Network testing.*
Now test the fabrics configuration by attempting to ping between Host-1 and Host-3:
```
Host-1# ping 192.51.100.20
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.51.100.20, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/6/10 ms
```
### Layer 3 Mode
> Per the requirements in the Objectives section, hosts must be able to ping hosts in other subnets using an Anycast Gateway, so now that we have tested Layer 2 configs, we will be configuring a non-"Layer 2 only" network now.
Navigate to the **Networks** tab of the Fabric screen via **Fabric > Networks**.
![[ND NDFC Basics Post Push Networks.png]]
Check the **checkbox** next to a network, then select the **Actions** drop-down from the top right of the table, then select the "**Edit**" option.
![[ND NDFC Basics Layer 2 Network Creation.png]]
Uncheck the "**Layer 2 only**" field, then select the "**VRF Name**" as the one configured in previous steps.
Now enter the associated networks Anycast Gateway IP address in the "**IPv4 Gateway/NetMask**" field.
When complete, click the "**Save**" button at the bottom right.
#### Deploying Changes
![[ND NDFC Basics L3 New Network Deployment.png]]
*Excuse the typo in the IPv4 Gateway for VLAN 20, it should be 203.0.113.1/24.*
Now that the networks are Layer 3, have their Anycast Gateways assigned, select the **Actions** drop-down at the very top bar of the Fabric Screen and select "**Recalculate and Deploy**". Go through the process of deploying these changes. For instruction on this, reference [[Getting Started with NDFC]].
#### Testing with Hosts
Now test the fabrics configuration by attempting to ping between Host-1 and its DFGW:
```
Host-1# ping 192.51.100.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.51.100.20, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/6/10 ms
!
Host-1#ping 203.0.113.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 203.0.113.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/4/6 ms
```
Here we can see that Host-1 is now able to not only ping other devices on its subnet, but use its default gateway to contact devices in other subnets.
This concludes the guide.
## External Connectivity with eBGP in NDFC
URL: https://adamspera.dev/nexus-dashboard/external-connectivity-with-ebgp-in-ndfc/
## About This Document
This document serves as a guide for configuring Data Center VXLAN EVPN fabric types in Nexus Dashboard Fabric Controller (NDFC) to use external connectivity via eBGP.
### Prerequisites
- NDFC Fabric running Data Center VXLAN EVPN
- [[Basics of VXLAN EVPN in NDFC]]
- CML or EVE-NG topology from ^ but with a Catalyst 8000v connected to the borders.
This guide uses version **Nexus Dashboard 3.2(2m)** and the latest NDFC version.
This guide is meant for use after reading the following:
- [[Installing ND v3.2.x on ESXI]]
- [[Getting Started with NDFC]]
- [[Basics of VXLAN EVPN in NDFC]]
This guide will breeze over some common topics like how to Recalculate and Deploy.
**Instructions will be indicated bellow the associated screenshot.**
### Environment
![[NDFC eBGP CML Topology.png]]
This guide will use the hosts from [[Basics of VXLAN EVPN in NDFC]], which are IOSv routers connected to interfaces Ethernet1/3 on all leafs.
- Host-1 <> N9Kv-4 (VLAN 10)
- Host-2 <> N9Kv-5 (VLAN 20)
- Host-3 <> N9Kv-6 (VLAN 10)
- Host-4 <> N9Kv-7 (VLAN 20)
- "Crossing Boundaries" (VLAN 10) - 192.51.100.0/24
- "Integrated Experiences" (VLAN 20) - 203.0.113.0/24
### Upstream
For the Catalyst 8000v configuration, the following is what is used in this guide:
```
interface GigabitEthernet1
ip address 10.0.0.2 255.255.255.252
ip nat outside
interface GigabitEthernet2
ip address 10.1.0.1 255.255.255.252
ip nat inside
interface GigabitEthernet3
ip address 10.1.0.5 255.255.255.252
ip nat inside
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
access-list 1 permit any
!
ip nat inside source list 1 interface G1 overload
!
router bgp 15000
bgp log-neighbor-changes
neighbor 10.1.0.2 remote-as 60000
neighbor 10.1.0.6 remote-as 60000
address-family ipv4
network 1.1.1.1 mask 255.255.255.255
network 10.0.0.0 mask 255.255.255.252
neighbor 10.1.0.2 activate
neighbor 10.1.0.6 activate
exit-address-family
!
ip route 0.0.0.0 0.0.0.0 10.0.0.1
```
## Objective
The objective of this guide is to configure eBGP for external connectivity in a Data Center VXLAN EVPN fabric with NDFC.
By the end of this guide hosts should be able to ping the Catalyst 8000v's loopback IP address to verify the external connectivity.
- Host-1 (192.51.100.10) <--ICMP--> C8000-v1 (1.1.1.1)
Then as a bonus, configure BGP on the Border LEafs to advertise its default route to 1.1.1.1 as the gateway of last resort, for all FABRIC VRF endpoints (NVIs).
## Routed Interfaces
Before jumping into BGP configurations, the Border Leaf interfaces that connect to the Catalyst 8000v will need IP addresses and a VRF assignment.
![[NDFC eBGP Edit Routed Ints.png]]
Navigate to the Interfaces tab, then select the two **Border Leafs**, then select **Edit** from the Actions drop-down.
![[NDFC eBGP Routed Int Edit 2.png]]
From this Edit screen, perform the following:
- Assign the interface to the "FABRIC" VRF (created in [[Basics of VXLAN EVPN in NDFC]])
- Enter an Interface IP which will be used for the source of the neighborship.
- Enter the subnet mask for the IP.
**Repeat this step for the next interface as well, with the details changing for that link.**
## VRF Attachment
As you may recall, the VRF "FABRIC" which is used for host networks in our fabric, will not have been pushed to the borders, as it does not need an NVI.
You can see this is an issue by searching for "Interface == Ethernet1/1" on the Interfaces tab.
![[NDFC eBGP VRF Unusable.png]]
Here we can see that the interfaces are down due to "VRF Unusable".
To solve this, navigate to the **VRFs** tab, then select **FABRIC**, then click **Multi-Attach**.
![[NDFC eBGP Select Borders VRF.png]]
Select both **Borders** to have the VRF attached to, then select **Next**.
![[NDFC eBGP Summary Deployment Model.png]]
Keep the recommended option: "**Proceed to Full Switch Deploy**" then select **Save**.
Then select **Deploy All** to deploy the pending changes.
**Verifications**
If you want to test these configurations so far, log into the Catalyst 8000v, then perform the following:
```
C8000v-1# ping 10.1.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
```
If you can ping the IP address on the N9K interfaces, then you are good to move on!
## eBGP Policy
![[NDFC eBGP Add Policy.png]]
Navigate to the **Policies** tab, then select the **Actions** drop-down, then click **Add Policy**.
Then select the first **Border Leaf** switch.
![[NDFC eBGP VRF-Lite Policy.png]]
Enter the following information:
- Template: "External_VRF_Lite_eBGP"
- Local ASN The local devices AS number.
- VRF Name: Same name as used for VXLAN Fabrics
- Neighbor ASN: The AS of the remote system (c8000v)
- Neighbor IPv4 Address: The IP address of the connected link on the N9K.
When complete, select the **Save** button at the bottom right.
**Repeat for the other Border Leaf, but change the info for that link.**
![[NDFC eBGP Policy Preview.png]]
Once complete, Recalculate and Deploy to view the new configs. When the configs look as they should, deploy the changes.
## Verifications
Now that we've configured the Routed Interfaces, attached the VRF, and setup the External BGP Policy, we can test if the routes are getting advertised as expected.
Log onto the Catalyst 8000v, then run `show ip route bgp` to view all the routes being learned via BGP.
```
C8000v-1# show ip route bgp
Gateway of last resort is 10.0.0.1 to network 0.0.0.0
192.51.100.0/24 is variably subnetted, 2 subnets, 2 masks
B 192.51.100.0/24 [20/0] via 10.1.0.6, 00:00:07
B 192.51.100.10/32 [20/0] via 10.1.0.6, 00:00:07
B 203.0.113.0/24 [20/0] via 10.1.0.6, 00:00:07
```
Here we can see that it is learning the routes!
Let's now test with a host, specifically Host-1:
```
Host-1# ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/17 ms
```
Great, we can see that hosts connected to our fabric can ping externally.
Unfortunately, when trying to ping out to the internet (connected via the ISP router), we are not seeing reachability.
```
Host-1# ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
```
This behavior is due to the FABRIC VRF not having a default route configured.
Lets configure a default route, then have BGP propagate it through the network.
## Static Default Route
Navigate to the **Policies** tab, then create a **New Policy**.
Select the "**static_route_v4_v6**" template.
![[NDFC eBGP Static Route 1.png]]
After entering a description, select **Add** from the **Actions** drop-down.
![[NDFC eBGP Static Route 2.png]]
Enter in the following information, given the requirements:
- IP Version
- IPv4 Prefix/Mask
- Next Hop Address
- Next Hop VRF
Click the **Save** button at the bottom right.
Then select **Save** at the bottom right of the Policy screen.
Deploy the new configurations, and preview the changes:
```
vrf context fabric
ip route 0.0.0.0/0 1.1.1.1
```
Here we can see that the default route is going to be added as planned.
### Verifications
Now to test this part of the configuration, log onto a Border lEaf and attempt to ping `8.8.8.8` from the FABRIC VRF.
```
N9Kv-0# ping 8.8.8.8 vrf FABRIC
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=116 time=12.637 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=11.734 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=12.012 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=11.922 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=116 time=12.025 ms
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 11.734/12.066/12.637 ms
N9Kv-0# sh ip route 0.0.0.0 vrf FABRIC
0.0.0.0/0, ubest/mbest: 1/0
*via 1.1.1.1, [1/0], 00:01:07, static
```
From the output above you can see that the Border Leafs can ping `8.8.8.8` when the ICMP packets are sourced from a local interface.
Though this will only work on the Border Leafs, since that policy was only for the Borders.
## BGP Prefix Advertisement
Currently, the issue is that other devices in the fabric like the Leafs, do not have the default gateway route that the borders do. To solve this, we will use BGP to advertise the `0.0.0.0/0` network to all other switches.
Navigate to the **Policy** screen, then create a new policy with the "**bgp_vrf_network**" template for both **Border Leafs**.
![[NDFC eBGP 0.0.0.0 Advertise.png]]
Enter the following information:
- BGP AS #
- VRF Name
- IP Prefix to Advertise
Once complete, Deploy the changes, and preview the changes:
```
router bgp 60000
vrf fabric
address-family ipv4 unicast
network 0.0.0.0/0
```
### Verifications
Now time to test, attempt to ping `8.8.8.8` from one of the fabric hosts.
```
Host-1# ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/12/15 ms
```
Great! We have achieved all goals of this guide.
But...
With this configuration, there is a potential issue, since our fabrics BGP is adverttizing `0.0.0.0/0`, the Catalyst 8000v will get it too. This means that if the default route on it goes out, it will forward all traffic to itself!
To demonstrate this issue, view the following demo:
```
C8000v-1#show ip route
Gateway of last resort is 10.0.0.1 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 10.0.0.1
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
C 10.0.0.0/30 is directly connected, GigabitEthernet1
L 10.0.0.2/32 is directly connected, GigabitEthernet1
C 10.1.0.0/30 is directly connected, GigabitEthernet2
L 10.1.0.1/32 is directly connected, GigabitEthernet2
C 10.1.0.4/30 is directly connected, GigabitEthernet3
L 10.1.0.5/32 is directly connected, GigabitEthernet3
192.51.100.0/24 is variably subnetted, 2 subnets, 2 masks
B 192.51.100.0/24 [20/0] via 10.1.0.6, 00:30:32
B 192.51.100.10/32 [20/0] via 10.1.0.6, 00:30:32
B 203.0.113.0/24 [20/0] via 10.1.0.6, 00:30:32
C8000v-1#show run | section route
router ospf 1
router-id 1.1.1.1
network 172.16.1.0 0.0.0.255 area 0
router bgp 15000
bgp log-neighbor-changes
neighbor 10.1.0.2 remote-as 60000
neighbor 10.1.0.6 remote-as 60000
!
address-family ipv4
network 1.1.1.1 mask 255.255.255.255
network 10.0.0.0 mask 255.255.255.252
neighbor 10.1.0.2 activate
neighbor 10.1.0.6 activate
exit-address-family
ip route 0.0.0.0 0.0.0.0 10.0.0.1
```
Above is the normal configuration, which works, but what if the static route gets taken away...
```
C8000v-1#configure terminal
C8000v-1(config)#no ip route 0.0.0.0 0.0.0.0 10.0.0.1
C8000v-1(config)#end
C8000v-1#show ip route
Gateway of last resort is 10.1.0.2 to network 0.0.0.0
B* 0.0.0.0/0 [20/0] via 10.1.0.2, 00:00:04
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
C 10.0.0.0/30 is directly connected, GigabitEthernet1
L 10.0.0.2/32 is directly connected, GigabitEthernet1
C 10.1.0.0/30 is directly connected, GigabitEthernet2
L 10.1.0.1/32 is directly connected, GigabitEthernet2
C 10.1.0.4/30 is directly connected, GigabitEthernet3
L 10.1.0.5/32 is directly connected, GigabitEthernet3
192.51.100.0/24 is variably subnetted, 2 subnets, 2 masks
B 192.51.100.0/24 [20/0] via 10.1.0.6, 00:30:51
B 192.51.100.10/32 [20/0] via 10.1.0.6, 00:30:51
B 203.0.113.0/24 [20/0] via 10.1.0.6, 00:30:51
```
Here we can see that without the static route, BGP is taking over as the default route, causing traffic to black hole at the C8000v.
Let's setup some policy to block the advertisement of this route to the C800v.
## Route Filtering
The following steps get into some advanced routing, so the details will be brief.
### Prefix List
Create a new **Policy** for both **Border Leafs**.
Select the "**ipv4_prefix_list**" template.
Name the prefix list `DENY_DEFAULT`.
Add the following entires to block `0.0.0.0/0` but permit all other routes.
|Seq|Prefix|Action|Min Len|Max Len|
|---|---|---|---|---|
|5|`0.0.0.0/0`|`deny`|_(blank)_|_(blank)_|
|10|`0.0.0.0/1`|`permit`|`2`|`32`|
|20|`128.0.0.0/1`|`permit`|`2`|`32`|
Click the **Save** button at the bottom right to save.
### Route Map
Create a new **Policy** for both **Border Leafs**.
Select the "**route_map_match**" template.
Name the route map `block-default-out`.
Enter the following information:
- Route Map Action: `permit`
- Route Map Sequence Number: `10`
- ACL/Prefix-List Name: `DENY_DEFAULT`
- Match Route Using Prefix-List: `YES`
Click the **Save** button at the bottom right to save.
### Apply to BGP
Create a new **Policy** for EACH OF the **Border Leafs**.
Select the "**bgp_neighbor_route_map**" template.
Enter the corresponding info for each Border Leaf:
- BGP AS: `60000`
- VRF Name: `FABRIC`
- Route Map Name: `block-default-out`
- Route Map Direction: `out`
Click the **Save** button at the bottom right to save.
Then when complete, deploy and preview the changes.
## Verifications
As one last final test, lets confirm that the route `0.0.0.0/0` is NOT being advertised to the Catalyst 8000v...
```
C8000v-1# show ip route
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
C 10.0.0.0/30 is directly connected, GigabitEthernet1
L 10.0.0.2/32 is directly connected, GigabitEthernet1
C 10.1.0.0/30 is directly connected, GigabitEthernet2
L 10.1.0.1/32 is directly connected, GigabitEthernet2
C 10.1.0.4/30 is directly connected, GigabitEthernet3
L 10.1.0.5/32 is directly connected, GigabitEthernet3
192.51.100.0/24 is variably subnetted, 2 subnets, 2 masks
B 192.51.100.0/24 [20/0] via 10.1.0.2, 00:01:30
B 192.51.100.10/32 [20/0] via 10.1.0.2, 00:01:30
B 203.0.113.0/24 [20/0] via 10.1.0.2, 00:01:30
```
Success! We are now seeing that BGP is no longer advertising the default route to the C8000v.
Now lets throw the normal static default route back on the Ctalayst 8000v, then do one last ping test...
```
Host-1# ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/15/23 ms
```
Amazing, everything is working as expected.
This concludes the guide.
## Getting Started with NDFC
URL: https://adamspera.dev/nexus-dashboard/getting-started-with-ndfc/
## About This Document
This document serves as a guide for getting started with Nexus Dashboard Fabric Controller (NDFC).
**Prerequisites**:
- Nexus Dashboard (ND) node with the NDFC deployment mode.
- [[Installing ND v3.2.x on ESXI]]
- CML or EVE-NG running at-least 3-4 Nexus 9000v switches.
- Mgmt0 interfaces of N9Kv devices must be reachable via NDFCs Mgmt or Fabric interfaces.
This guide uses version **Nexus Dashboard 3.2(1i)** and the latest NDFC version.
**Instructions will be indicated bellow the associated screenshot.**
## Document Overview
This document will cover the following topics:
- Navigating to the NDFC view.
- Configuring key system settings.
- Setting up default device credentials.
- Creating an NDFC fabric.
- Explaining different fabric types.
- Discovering switches and inventory.
- Assigning device roles and caveats.
- Deploying changes.
- Using the topology.
## Launching NDFC
Browse to the Nexus Dashboard GUI via `https://`.
![[ND Deployment Selection DropDown.png]]
At the top of the Dashboard, **select the drop down** next to the Nexus Dashboard text.
Then select **Fabric Controller** as the view.
## System Settings
![[ND Navigate System Settings.png]]
Rather than jumping straight into **Service Setup** via the **Journey View**, navigate to the **Admin > System Settings** tab.
### LAN Device Connectivity
![[ND Settings LAN Management Interface.png]]
Navigate to the **Admin** sub-tab, and change the **LAN Device Management Connectivity** setting which interface you want to communicate with switches/devices with.
> Reference the [[Installing ND v3.2.x on ESXI]] MOP to learn about initial configuration of these networks.
For this demo enviorment, the Nexus Dashboard **Fabric Interface** (Data) is connected to the subnet that N9Kv devices share, so I will be setting this to Data.
Once or if changes, click the "**Save**" button at the bottom right.
### Services Setup
This step can be completed via Journey View > Services Setup, or here in settings under **Feature Management**.
![[ND Feature Management.png]]
Here you must select what Feature / Operational Mode that NDFC will run.
#### Fabric Discovery
This feature focuses exclusively on LAN Monitoring.
This includes adding switches and devices via discovery, viewing the topology, and running show commands.
This mode **CANNOT** perform exec commands or perform any configuration changes.
#### Fabric Controller
This feature is the standard NDFC mode.
This includes all core functionality of a Network Manager that is expected:
- Inventory & Discovery
- Topology View
- Show Commands
- Exec Commands
- Automated Configuration Templating
- Deployments
> Note that the above features of Fabric Controller mode are what is considered the "**Fabric Builder**" sub-feature, which is enabled by default when selecting this mode.
This mode also includes many optional sub features:
![[ND Feature Management Sub Features.png]]
For getting started, it is recommended to start with just **Fabric Builder**. Then once comfortable, explore into Change Control, Endpoint Locator, etc.
Once decided, click the "**Save**" button at the bottom right to enable.
![[ND Feature Management Loading.png]]
Then **wait** for the process to finish initializing, then **refresh** to see the new feature set options in the side-bar.
## Switch Credentials
This part of the process will set default device credentials, so that devices without explicit authentication details can fallback to a standard set of credentials.
Navigate to **Admin > Switch Credentials** via the side-bar.
![[ND Switch Credentials 1.png]]
Click the "**Set**" button at the top to start configuring.
![[ND Switch Credentials 2.png]]
Enter the username and default password for the locally configured users on your switches.
This would be the same credentials as configured on your Nexus 9000v switches like:
```
(config)# username admin password cisco role network-administrator
```
Once the details are entered, click the "**Save**" button at the bottom right.
## Creating Fabrics
Now for the fun part, making your first fabric!
Fabrics are **logical containers** with switches such as Nexus 9000, 7000, Catalyst 9000, 3rd party devices and more.
Navigate to the **Manage > Fabrics** tab of the side-bar.
![[ND Fabrics Create New.png]]
Select the "**Actions**" drop-down and select "**Create Fabric**".
### Naming the Fabric
![[ND Fabric Naming.png]]
Enter the name of your fabric in the "**Fabric Name**" field.
*Note that the name of the fabric must be unique across all ND clusters.*
Once done, click the "**Choose Fabric**" button below the field.
### Choosing Fabric Types
Each Fabric has a **Type** which is used to generate consistent coordinated configuration for each switch in the Fabric.
![[ND Select Fabric Type.png]]
Here you will select a **Fabric Type** for the fabric, which is built off of a base template.
The most common Types are as follows:
| Fabric Type | Explanation |
| ---------------------- | ---------------------------------------------------------------------------------------------------- |
| Data Center VXLAN EVPN | Fabric for a VXLAN EVPN deployment with Nexus 9000 and 3000 switches. |
| Enhanced Classic LAN | Fabric for a fully automated 3-tier Classic LAN deployment with Nexus 9000 and 7000 switches. (beta) |
| IPFM | Fabric for a fully automated deployment of IP Fabric for Media Network with Nexus 9000 switches. |
| Others | Including BGP Fabric, Routed Fabric and more. |
> For most deployments of NDFC, the fabric type "**Data Center VXLAN EVPN**" is used.
Once a type is select, click the "**Select**" button below the selections.
### Customize Template
Based on your type selection, you can now edit and customize that template to meet your fabrics needs and specifications.
![[ND Customize Fabric Type.png]]
Here you will have to fill in all required fields.
For example, you have to enter the fabrics autonomous system number.
Once you have customized it, click the "**Save**" button at the bottom right.
## Switch Discovery
Once you have created a fabric, **double-click the name** of the fabric to enter the fabric view.
![[ND Fabric Dashboard.png]]
From this sub-page you can customize and configure your fabric.
To get started, you have to add switches to your inventory.
Click on the "**Switches**" tab, then select "**Add Switches**" from the "**Actions**" drop-down.
![[ND Add Switches.png]]
From this sub-screen you can enter some key information:
**Seed IP** specifies the IP address that NDFC will use to start discovering devices on. You can specify a single IP address or multiple for a more precise discovery, then NDFC will log in via **SSH** to the addresses, to collect information.
If you only specify a few select devices, NDFC will use **CDP** to discover other switches, and use the **Management Address TLV** to also attempt to SSH into those devices and continue the process.
> Devices must be enabled with SSH and reachable via OOB to be added to NDFC.
*Note: Unchecking the "**Presave Config**" option will perform a `write erase` without removing the boot or OOB configurations.*
When the details entered are completed, click the "**Discovery Switches**" button at the bottom right to begin discovery.
![[ND Switch Discovery 2.png]]
Once it has discovered all the switches you would like to add, select them with the checkboxes on the left of the table, then click "**Add Switches**" at the bottom right.
Then **wait** for the devices to be added to the fabric.
*Note that this does not push config (unless you selected an option in the type template), but adds it to NDFCs calculations.*
![[ND Switch Inventory Discovered.png]]
Once all the devices have cleared config and reloaded (if applicable), they will come up as "**Normal**", and "**Ok**" in the **Switches** tab.
## Device Roles
NDFC uses manually assigned roles to determine what configs should be applied to which devices. This comes in handy, as alot of the policy administrators deploy via NDFC is loosely binded to devices or interfaces, as NDFC handles all the granular work for you.
> Configurations are not pushed until the first "Recalculate & Deploy" is performed.
> **DO NOT run "Recalculate & Deploy" until you have set the device roles in this step.**
![[ND Switches Set Role 1.png]]
To assign certain devices to roles, select like devices with the **checkbox** on the left side of the table, then select the **Actions** drop-down, and select the "**Set Role**" option.
![[ND Device Set Role 2.png]]
From the **Select Role** model, **select which role** you would like the device to be, then click the "**Select**" button at the bottom right.
Perform this assignment for all applicable devices in your fabric.
*Note: The default role is Leaf.*
**Before moving on:** Be aware that once you perform a "Recalculate and Deploy" your ability to re-assign roles becomes limited! The following are permitted transitions after initial assignment.
The following shifts are allowed for the switch role:
- Leaf to Border
- Border to Leaf
- Leaf to Border Gateway
- Border Gateway to Leaf
- Border to Border Gateway
- Border Gateway to Border
- Spine to Border Spine
- Border Spine to Spine
- Spine to Border Gateway Spine
- Border Gateway Spine to Spine
- Border Spine to Border Gateway Spine
- Border Gateway Spine to Border Spine
## Recalculate and Deploy
This feature is how NDFC converges its understanding of the fabric, and determines the policy to apply to devices via configuration.
**This is a destructive action, which will write to the configuration of devices.**
![[ND Recalc and Deploy 1.png]]
To perform a **Recalculate and Deploy**, select the "**Actions**" drop-down at the very top bar of the NDFC Fabric screen.
![[ND Recalculating Loading.png]]
Then **wait** for NDFC to compile changes and prepare the configurations.
If a configuration is invalid according to its policies, it will notify you at this point.
![[ND Config Preview 1.png]]
From the config preview screen, you can **click** on the **Pending Config** lines to see exactly what configurations are going to be pushed.
When you are sure you want to deploy the changes, select the "**Deploy All**" button at to begin the configuration deployment.
![[ND Deployment In Progress.png]]
Then **wait** for the configurations to be deployed.
When completed you can select "**Close**" at the bottom right.
## Topology
Topology allows you to visualize your fabrics, switches, connected end-points and links between them, enabling you to quickly identify faults in your network.
Navigate out of the NDFC Fabric screen by clicking the "**X**" at the top right corner.
Then navigate to **Overview > Topology** via the main NDFC screen.
From there, **double-click the Fabric** you want to view.
![[ND NDFC Topology View.png]]
**Double Click**: Drill-down into specific elements.
**Right Click**: Assign switch roles, set VPC pairs, view details and more.
This concludes the guide.
## Installing ND v3.2.x on ESXI
URL: https://adamspera.dev/nexus-dashboard/installing-nd-v32x-on-esxi/
## About This Document
This document serves as a Method of Procedure (MoP) for installing and setting up a Nexus Dashboard node, with optional multi-node clustering instructions.
This guide targets the Unified image for **Nexus Dashboard 3.2(1i)** on **ESXi 8.0.3**.
> *The "Unified" image refers to the consolidated Nexus Dashboard platform (3.1+), where the App Store has been deprecated. In Unified images, instead of downloading separate images for NDFC, NDO, or NDI, these services can now be enabled from the Unified image itself, pulling the image for the specific service from the cloud for you.*
## Hosting Requirements
When deploying ND on ESXi or vCenter, you can choose between two types of nodes:
- **Data Node**: higher system requirements designed for specific services that require the additional resources.
- **App Node**: smaller resource footprint that can be used for most services.
This document will be deploying the **App Node** due to its lesser system requirements while also meeting future needs (NDFC deployment).
| Data Node | App Node |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| - VMware ESXi 7.0, 7.0.1-3, 8.0, 8.0.2
- VMware vCenter 7.0.1-3, 8.0, 8.0.2 if deploying using vCenter
Each VM requires the following:
- **32 vCPUs** with physical reservation of at least 12,000 MHz.
- **128GB of RAM** with physical reservation.
- **3TB SSD** storage for the data volume and an additional **50GB** for the system volume.
The SSD must be attached to the data store directly or in JBOD mode if using a RAID Host Bus Adapter (HBA).
The SSDs must be optimized for Mixed Use/Application (not Read-Optimized):
- 4K Random Read IOPS: 93000
- 4K Random Write IOPS: 31000 | - VMware ESXi 7.0, 7.0.1-3, 8.0, 8.0.2
- VMware vCenter 7.0.1-3, 8.0, 8.0.2 if deploying using vCenter
Each VM requires the following:
- **16 vCPUs** with physical reservation of at least 12,000 MHz.
- **64GB of RAM** with physical reservation.
- **500GB HDD or SSD** storage for the data volume and an additional **50GB** for the system volume.
*Note*: If you are deploying ND to for NDI past version ND 3.0(1i), you must increase the default disk of 500GB to 1536GB. |
For more details on ESXi / VM requirements, reference [Cisco Nexus Dashboard and Services Deployment and Upgrade Guide, Release 3.2.x](https://www.cisco.com/c/en/us/td/docs/dcn/nd/3x/deployment/cisco-nexus-dashboard-and-services-deployment-guide-321/nd-deploy-vmware.html)
## Creating the VM
The following section will walkthrough the process of installing Nexus Dashboard in ESXi.
For more details, reference the official Cisco documentation at [Cisco Nexus Dashboard and Services Deployment and Upgrade Guide, Release 3.2.x | Deploying Nexus Dashboard Directly in VMware ESXi](https://www.cisco.com/c/en/us/td/docs/dcn/nd/3x/deployment/cisco-nexus-dashboard-and-services-deployment-guide-321/nd-deploy-vmware.html#task_yvm_y5z_2qb).
**Instructions will be indicated bellow the associated screenshot.**
### Downloading the ND Image
Browse to the [Cisco Software Download](https://software.cisco.com/download/home/286327743/type/286328258/) page, and navigate to "**Nexus Dashboard**" images.
From there, download the "**nd-dk9.3.2.1i.ova**" image to your local computer.
> The syntax of Nexus Dashboard images is: `nd-ndk9..ova`
### Navigate to the VM Tab
Log in to your ESXi Dashboard.
Navigate to the "**Virtual Machines**" tab on the left side-bar.
### Create the VM
![[ESXi VM Tab.png]]
Click the "**Create / Register VM**" button at the to left of the main table.
### Select OVA Deployment
![[ESXi OVA Selection.png]]
Then select the "**Deploy a virtual machine from an OVF or OVA file**" option.
Then click the "**NEXT**" button at the bottom right.
### Name & Upload the OVA
![[ESXi Name & OVA Upload.png]]
Enter the **name** of your VM in the name field.
*This document will cover clustering, so the names will be numbered.*
Click into the "**Click to select files or drag/drop**" field to upload the OVA file.
Then click the "**NEXT**" button at the bottom right.
### Select ESXi Datastore
![[ESXi Datastore Selection.png]]
Select which Datastore you want to use for your ND node.
> Remember that the **App Node** deployment storage requirements are as follows: `500GB HDD or SSD storage for the data volume and an additional 50GB for the system volume.`
Then click the "**NEXT**" button at the bottom right.
### Customize the Deployment
![[ESXi Deployment Customization.png]]
From this screen you can select 4 key options which do the following:
| Option | Guidance |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Network mappings | ND nodes have 2 network interfaces, "**mgmt0**" and "**fabric0**".
*Mgmt0 is used for fabric discovery by default but **CAN** be changed to Fabric0.*
The **mgmt0** interface is used to host the user interface of ND (https). |
| Deployment type | Select either "**Data**" or "**App**", explained in the above section. |
| Disk provisioning | Select either "Thin" or "Thick", but **Thick** is advised. |
> For this MOPs environment, the network, *Infrastructure (10)* is used exclusively for OOB management plane traffic (ESXi gui, ND gui, ISE gui) (non-destructive), whereas *Lab Out-of-Band (20)* is used for connecting lab devices' mgmt0 interfaces, acting as a sudo in-band out-of-band network, that can be destructive, as NDFC will interact with them.
Uncheck the "**Power on automatically**" field, so that the **vApp & vmdk** can have time to download, and the VM does not power up unexpectedly.
Then click the "**NEXT**" button at the bottom right.
### Confirm VM Specs
Once all the details look correct, click the "**FINISH**" button at the bottom right.
### VApp & VMDK Download
Now that the VM is created, this will trigger the VM to automatically pull the **VApp & VMDK**, which can be viewed in the "**Recent Tasks**" tab at the bottom of the ESXi Dashboard.
> Make sure to keep your ESXi session active while these files get pulled from the uploaded OVA to ensure a reliable upload.
Once the **Recent Tasks** for the VApp & VMDK say "**Completed Successfully**", you can proceed to power on the VM.
## First-Boot Setup
Once the VM is up and running, click on the ESXi console viewer to see the console output.
You will be prompted to run the first-time setup utility:
```
[ OK ] Started atomix-boot-setup.
Starting Initial cloud-init job (pre-networking)...
Starting logrotate...
Starting logwatch...
Starting keyhole...
[ OK ] Started keyhole.
[ OK ] Started logrotate.
[ OK ] Started logwatch.
Press any key to run first-boot setup on this console...
```
Click the `enter` key.
```
Admin Password:
Reenter Admin Password:
```
Then confirm the `admin` password.
> This password will be used for the `rescue-user` SSH login as well as the initial GUI password.
```
Management Network:
IP Address/Mask: 203.0.113.20/24
Gateway: 203.0.113.1
```
Enter the management network information.
```
Is this the cluster leader?: y
```
For the first node only, designate it as the "Cluster Leader".
> You will log into the cluster leader node to finish configuration and complete cluster creation.
```
Please review the config
Management network:
Gateway: 203.0.113.1
IP Address/Mask: 203.0.113.20/24
Cluster leader: no
Re-enter config? (y/N): N
```
You will be asked if you want to change the entered information. If all the fields are correct, choose `N` to proceed. If you want to change any of the entered information, enter `y` to re-start the basic configuration script.
**At this point, if you are spinning up a cluster of ND nodes, you should get all nodes to this point. NOTE: All nodes need the same admin password, and only one can be the leader.**
Once indicated from the console that the setup is complete, it will prove the URL to get to the GUI: `https://`
## Cluster Bringup
The rest of the configuration workflow takes place from one of the node's GUI. You can choose any one of the nodes you deployed to begin the bootstrap process and you do not need to log in to or configure the other two nodes directly.
![[ND Initial Login Screen.png]]
Enter the password you provided during the *First-Boot Setup* step and click **Login**.
### Configuration
![[Cluster Bringup Config 1.png]]
![[Cluster Bringup Config 2.png]]
The first section "Configuration" allows the user to configure key node details.
| Section | Guidance |
| ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Nexus Dashboard Cluster Name | This will be the name of your ND cluster.
The name should be unique across all clusters, if applicable. |
| DNS | Provide one or many IP addresses for the following:
- DNS Provider
- DNS Search Domain |
| NTP | Provide one or many IP addresses for the nodes NTP servers.
**Ensure that you enter multiple from various providers.
ND will loose functionality if it's NTP servers are lost.** |
| Proxy | If you have an HTTP/HTTPS proxy, configure it here.
**If you are not using a proxy, you have to select Skip Proxy**. |
| Advances Settings | More below. |
For the **Advanced Settings**:
- The application overlay network defines the address space used by the application's services running in the Nexus Dashboard. The field is pre-populated with the default `172.17.0.1/16` value.
- The services network is an internal network used by the Nexus Dashboard and its processes. The field is pre-populated with the default `100.80.0.0/16` value.
- **Make sure that these do not collide with your existing infra networks.**
Once complete, click the "**Next**" button at the bottom right.
### Node Details
![[Node Details 1.png]]
![[Node Details 2.png]]
Enter the name of the local node in the **Name** field.
*Note that this must be unique within the cluster.*
You have already defined the **Management network** and IP address for the node into which you are currently logged in during the initial node configuration in earlier steps, but you must also provide the **Data network** information for the node before you can proceed with adding the other nodes and creating the cluster.
For this MOP, the **Data network** will be `172.16.1.0/24`, as this network will later be configured to discover switches, which also live on that network.
> If you are clustering nodes, log into the main node GUI, then add more nodes in this section. Note that the **Type** field should be the same across all nodes in your cluster (use **Primary** for a single node or cluster setup). If you are setting up a cluster that will be added to multi-clustering, you can set it to **Secondary** or **Standby**.
Once complete, click the "**Next**" button at the bottom right.
### Deployment Mode
![[ND Deployment Mode P1.png]]
![[ND Deployment Mode P2.png]]
Select which **Deployment Modes** you intend to run on this ND node.
*Note that the Deployment Mode for all nodes within a cluster must match.*
Depending on the number of nodes in the cluster, some services or cohosting scenarios may not be supported.
The deployment mode cannot be changed after the cluster is deployed, so you must ensure that you have completed all service-specific prerequisites are met.
> If you chose a deployment mode that includes *Fabric Controller* or *Insights*, click **Add Persistent Service IPs/Pools** to provide one or more persistent IPs required by Insights or Fabric Controller services. These IPs will be used for various sub-servcies within these programs.
> Some of these services include "cisco-ndfc-dcnm-syslog-trap-data" or "cisco-ndfc-dcnm-poap-data-http-ssh" which are sub services that clients will target.
Once complete, click the "**Next**" button at the bottom right.
### Summary & Bootstrap
In the Summary screen, review and verify the configuration information, click **Save**, and click **Continue** to confirm the correct deployment mode and proceed with building the cluster.
![[ND Cluster Bringup Bootstrapping 1.png]]
It may take up to 30 minutes for the cluster to form and all the services to start. When cluster configuration is complete, the page will reload to the Nexus Dashboard GUI.
> Note that the GUI may log out or refresh multiple times throughout the bootstrapping process.
## Wrap Up
![[ND Node Health.png]]
Once the bootstrapping process completes, you should see in the **Manage > Nodes** tab that the node is **Healthy**, and all other nodes (if clustered) are also present and Healthy.
This concludes the MOP.
For next steps, check out [[Getting Started with NDFC]].
## Upgrading Nexus Dashboard
URL: https://adamspera.dev/nexus-dashboard/upgrading-nexus-dashboard/
## About This Document
This document serves as a Method of Procedure (MoP) for performing a software / version upgrade for Nexus Dashboard.
This guide targets the upgrade path of **3.2(1i)** to **3.2(2m)**.
| Starting Version | Ending Version |
| ---------------------------------------------- | ------------------------------------------------- |
| Nexus Dashboard 3.2(1i)
*nd-dk9-3.2.1i.ova* | Nexus Dashboard 3.2(2m)
*nd-k9.3.2.2m.ova*
|
> **Warning**: If you are upgrading from <= 3.1(x), you will not be able to add or remove services after upgrading to this release without redeploying the cluster. If you were planning to add or remove services in your cluster, it is recommended to do so before upgrading to release 3.2(x).
> **Warning**: For this target version, you must be running Nexus Dashboard release 3.0(1) or later to upgrade directly to release 3.2(x). If you are running an earlier version of Nexus Dashboard, it is reccomended to first upgrade to release 3.0(1) as described in the respective [deployment guide](https://www.cisco.com/c/en/us/support/data-center-analytics/nexus-dashboard/products-installation-guides-list.html).
## Downloading the ND Image
Browse to the [Cisco Software Download](https://software.cisco.com/download/home/286327743/type/286328258/) page, and navigate to "**Nexus Dashboard**" images.
From there, download the "**nd-dk9.3.2.2m.iso**" image to your local computer.
> The syntax of Nexus Dashboard images is: `nd-ndk9..iso`
> **Note**: Since this is not a greenfield deployment, the **ISO** image is needed, rather than an OVA.
## Prepare for Upgrading
Browse to the Nexus Dashboard GUI via `https://`.
Sign in with an `Administartor` role account.
![[ND Upgrade Services.png]]
Ensure that you are viewing the Nexus Dashboard view. This is called "**Admin Console**" from the top service selector drop-down.
From this main ND navigation menu, **Operate > Services**.
![[ND Upgrade Disable Service.png]]
Select each of the select services by clicking the **three dots** to right the of the service.
Then select "**Disable**" and select "**Confirm**" in the popup.
> Ensure that before upgrading, all services are disabled. If the services say "**Pending Disable**" then **wait** before proceeding, until it displays "**Disabled**".
## Uploading Images
![[ND Upgrade Navigate To Software.png]]
From this main ND navigation menu, **Manage > Software Management**.
![[ND Upgrade Software Management 1.png]]
From the Software Management screen, click the "**Add Image**" button at the top right.
> It is recommended to delete any old images before upgrading.
![[ND Upgrade Local Warning.png]]
*For this MOP, the files will be uploaded locally. To assist in this process, per the recommendation popup, the session timeout will be set to 3600 seconds, just incase.*
Click the "**Browse**" button to select a the **ISO** file from your local device.
Then select "**Add**" at the bottom right to begin the upload.
![[ND Upgrade Image Upload.png]]
Due to the large size of Nexus Dashboard images, this upload can take some time.
## Installing the Upgrade
Close the upload popup to return to the main **Software Management** screen.
![[ND Upgrade Downloaded.png]]
Once fully uploaded, select the "Install" button next to the target image.
![[ND Upgrade Confirm Popup.png]]
When the popup asks to confirm, select the "OK" button to proceed.
![[ND Upgrade Superseded.png]]
Now the upgrade has started!
You may be disconnected multiple times over the course of the update.
> Upgrades can take up to multiple hours.
![[ND Upgrade Upgraded.png]]
Once complete, you can see that the version has upgraded!
This concludes the MOP.