Antonio Perez

User Tools

Site Tools

Trace:
cisco:switch:9500:cisco_catalyst_9500_series_manual

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
cisco:switch:9500:cisco_catalyst_9500_series_manual [2025/05/20 17:36] – aperezcisco:switch:9500:cisco_catalyst_9500_series_manual [2026/06/11 17:26] (current) – aperez
Line 7: Line 7:
  
 ---- ----
 +
 +  Switch#do show interfaces status
   Switch#show running-config interface Port-channel2   Switch#show running-config interface Port-channel2
   Switch#show interfaces status   Switch#show interfaces status
Line 835: Line 837:
 ---- ----
 ---- ----
 +====== Troubleshooting PVST Inconsistency between Cisco 9500 and Aruba 6400 ======
  
 +=== 🧭 Context ===
 +Connectivity issue between:
 +  * **Cisco Catalyst 9500** → IP: `172.20.28.37`
 +  * **Aruba 6400** → IP: `172.20.28.1`
 +Connected via: **Port-channel 2 (Po2)**
 +
 +=== ⚠️ Symptom on Cisco ===
 +Output from `show spanning-tree mst`:
 +  Po2 Root BKN*400 P2p Bound(PVST) *PVST_Inc
 +
 +**Meaning:**
 +  * ''BKN'' → Port is blocked (Broken)
 +  * ''*PVST_Inc'' → PVST Inconsistency (STP mismatch detected)
 +
 +Cisco is running **MST**, but receives BPDUs from **PVST+ or RSTP** on the peer → risk of loop → port auto-blocked.
 +
 +=== 🔍 Root Cause ===
 +Cisco MST expects MST BPDUs. If a non-MST BPDU (e.g., PVST+ or RSTP) is received:
 +  * Cisco sees it as a protocol mismatch.
 +  * The port is blocked to prevent potential Layer 2 loops.
 +
 +=== ✅ Solution: Switched to RSTP ===
 +
 +== On Cisco 9500 ==
 +<code bash>
 +conf t
 +spanning-tree mode rapid-pvst
 +end
 +write memory
 +</code>
 +
 +== On Aruba 6400 ==
 +<code bash>
 +conf t
 +spanning-tree mode rstp
 +write memory
 +</code>
 +
 +**Result:** Port moved to ''FWD'' (Forwarding) state. Connectivity restored.
 +
 +=== 🔧 Verification Commands on Cisco ===
 +^ Command ^ Description ^
 +| `show spanning-tree mst` | View STP mode, port roles, and state |
 +| `**show spanning-tree inconsistentports**` | **Detect ports blocked due to PVST_Inc** |
 +| `show spanning-tree detail` | STP root path and BPDU info |
 +| `show interfaces status` | Verify port operational state |
 +
 +=== 🛠️ Key Recommendations ===
 +  * Prefer **RSTP** for mixed-vendor environments.
 +  * If using **MST**:
 +    * Ensure identical:
 +      * `name`
 +      * `revision`
 +      * `VLAN-to-instance mapping`
 +  * Avoid mixing PVST and MST without boundary configuration.
 +  * Always verify port status using:
 +    * `**show spanning-tree inconsistentports**`
 +
 +
 +----
 +----
 +
 +
 +===== Comparison: Static VXLAN vs VXLAN EVPN =====
 +
 +The difference between **Static VXLAN** and **VXLAN EVPN (Ethernet VPN)** lies primarily in **how MAC–VTEP (VXLAN Tunnel Endpoint) mappings are learned and distributed**, and the **scalability** of the design. Here's a breakdown of key points:
 +
 +==== 🔁 Static VXLAN ====
 +
 +**📌 Definition:**  
 +VXLAN using manually defined tunnels (VTEP-to-VTEP), with no control plane. All forwarding information (MAC–VNI–VTEP bindings) is learned locally or manually configured.
 +
 +**🛠 Key Features:**
 +
 +^ Feature             ^ Static VXLAN                        ^
 +| Control Plane       | ❌ None                             |
 +| MAC Learning        | 🌐 Flooding-based                   |
 +| Configuration       | 🛠 Manual                           |
 +| Scalability         | 🔻 Limited                          |
 +| BUM Traffic Handling| 🌊 Multicast or static flooding     |
 +| Typical Use Case    | 🧪 Labs, small campuses             |
 +
 +----
 +
 +==== 🌐 VXLAN EVPN ====
 +
 +**📌 Definition:**  
 +VXLAN with a **BGP EVPN-based control plane**, which dynamically distributes MAC–VNI–VTEP bindings across VTEPs.
 +
 +**🛠 Key Features:**
 +
 +^ Feature             ^ VXLAN EVPN                         ^
 +| Control Plane       | ✅ BGP EVPN                        |
 +| MAC Learning        | 📡 Control-plane based (BGP)       |
 +| Configuration       | ⚙️ Dynamic and scalable             |
 +| Scalability         | 🔺 High                            |
 +| BUM Traffic Handling| 🚫 Minimized by control-plane      |
 +| Typical Use Case    | 🏢 Data centers, cloud, multi-site |
 +
 +----
 +
 +^ Summary             ^ Static VXLAN                        ^ VXLAN EVPN                            ^
 +| Control Plane       | ❌ Manual / flood-based            | ✅ Distributed via BGP EVPN           |
 +| MAC Distribution    | Locally flooded                   | Learned and advertised via BGP       |
 +| Scalability         | Low                               | High (multi-tenant, multi-site)      |
 +| Complexity          | Simple but static                 | Complex but automated                |
 +| Use Cases           | Simple links, PtP, lab networks   | Large-scale DCs, EVPN fabrics        |
 +
 +----
 +
 +===== VXLAN EVPN L2VPN – CONTROL PLANE (Cisco) =====
 +
 +==== ❓ What is EVPN L2VPN Control Plane? ====
 +
 +EVPN (Ethernet VPN) is a BGP-based control plane protocol that enables:
 +  * Dynamic distribution of MAC ↔ VNI ↔ VTEP bindings
 +  * Elimination of unnecessary BUM flooding
 +  * Improved scalability, mobility, and segmentation
 +
 +In Cisco platforms, EVPN functionality depends on hardware, software version (IOS-XE or NX-OS), and system roles.
 +
 +----
 +
 +==== ✅ Platforms that **Support EVPN Control Plane** ====
 +
 +^ Platform          ^ OS         ^ EVPN Control Plane Support ^ Notes                                  ^
 +| Nexus 9000       | NX-OS      | ✅ Yes                      | Full L2/L3 EVPN support via BGP         |
 +| Nexus 7000/7700  | NX-OS      | ✅ Yes (F3/M3 modules)      | EVPN requires supported linecards       |
 +| ASR 9000         | IOS XR     | ✅ Yes                      | Carrier-grade EVPN                      |
 +| Catalyst 9500X   | IOS-XE     | ✅ Yes                      | Requires SDM `vxlan-routing` template   |
 +| Catalyst 9600    | IOS-XE     | ✅ Yes                      | Requires advanced config                |
 +
 +----
 +
 +==== 🚫 Platforms with **Limited or No EVPN Support** ====
 +
 +^ Platform          ^ OS         ^ EVPN Control Plane Support ^ Notes                                  ^
 +| Catalyst 9500     | IOS-XE     | ❌ No                       | Only static VXLAN supported            |
 +| Catalyst 9400     | IOS-XE     | ❌ No                       | No EVPN                                |
 +| Catalyst 9300     | IOS-XE     | ❌ No                       | No VXLAN / EVPN support                |
 +| Catalyst 9200     | IOS-XE     | ❌ No                       | No VXLAN                               |
 +| Catalyst 3850     | IOS-XE     | ❌ No                       | VXLAN and EVPN not supported           |
 +
 +----
 +
 +==== ⚠️ EVPN Requirements on Catalyst Platforms (when applicable) ====
 +
 +  * Minimum IOS-XE version: **17.9.1**
 +  * Required licenses:
 +    * `network-advantage`
 +    * `dna-advantage`
 +  * SDM Template:
 +    * Must be set to `vxlan-routing` (not available on non-X models)
 +  * Configuration method:
 +    * `l2vpn evpn`, `vni`, `rd`, `route-target`, `bridge-domain`
 +
 +----
 +
 +==== 🧱 Alternative: Static VXLAN (No Control Plane) ====
 +
 +For platforms without EVPN, VXLAN can be deployed in **static mode**:
 +  * Define `interface nve1`
 +  * Assign `source-interface` (Loopback)
 +  * Configure `member vni XXXX`
 +  * Use `ingress-replication protocol static`
 +  * Add `peer-ip A.B.C.D` for each remote VTEP
 +
 +Requires manual mapping and tunnel definition between all VTEPs.
 +
 +----
 +
 +==== 📝 Useful Show Commands (Catalyst) ====
 +
 +Check software version:
 +  `show version`
 +
 +Check license status:
 +  `show license summary`
 +
 +Check SDM template:
 +  `show sdm prefer`
 +
 +----
 +
 +==== 📌 Typical Error When EVPN Not Supported ====
 +
 +Trying to configure:
 +  `l2vpn evpn`  
 +  `vni XXXX l2`  
 +  `rd auto`  
 +
 +Returns:
 +  `% Invalid input detected at '^' marker.`
 +
 +📌 This indicates the command is **not supported** in this platform or SDM template.
 +
 +----
 +
 +==== ✅ Recommendation ====
 +
 +To deploy EVPN-based VXLAN in Cisco networks:
 +  * Use **Nexus (e.g., 9300, 9500)** or **C9500X with `vxlan-routing`**
 +  * Confirm licensing and SDM support
 +  * Use **Static VXLAN** on Catalyst platforms without EVPN capability
 +
 +
 +
 +
 +
 +
 +----
 +
 +
 +===== VXLAN – Core Terminology and Nomenclature =====
 +
 +VXLAN (Virtual Extensible LAN) is a tunneling technology that enables Layer 2 overlay networks over Layer 3 IP infrastructures. Below is the essential terminology you need to master:
 +
 +----
 +
 +==== 🔑 1. VNI – VXLAN Network Identifier ====
 +
 +  * **Definition:** A 24-bit identifier that replaces the traditional VLAN ID.
 +  * **Range:** 0 to 16,777,215 (2^24 - 1)
 +  * **Purpose:** Uniquely identifies a VXLAN segment (like a VLAN but in overlay).
 +  * **Example:**  
 +    VLAN 700 → VNI 10700
 +
 +----
 +
 +==== 🔑 2. VTEP – VXLAN Tunnel Endpoint ====
 +
 +  * **Definition:** The device that encapsulates/decapsulates VXLAN traffic.
 +  * **Purpose:** Acts as the entry/exit point of VXLAN tunnels.
 +  * **Key Point:** Each VTEP has a loopback or logical IP (used as tunnel endpoint).
 +  * **Example:**  
 +    Cisco VTEP IP = `172.18.32.33`
 +
 +----
 +
 +==== 🔑 3. NVE – Network Virtualization Edge ====
 +
 +  * **Definition:** The logical interface that represents VXLAN capability.
 +  * **Command Example (IOS-XE):**
 +    ```bash
 +    interface nve1
 +     source-interface Loopback0
 +     member vni 10700
 +    ```
 +  * **Note:** In NX-OS, you must use `feature nv overlay`; in IOS-XE it’s implicit.
 +
 +----
 +
 +==== 🔑 4. Bridge Domain (BD) ====
 +
 +  * **Definition:** A broadcast domain, equivalent to a VLAN at the overlay level.
 +  * **In IOS-XE:** Binding is done via:
 +    ```bash
 +    l2 vni 10700 vlan 700
 +    ```
 +  * **In NX-OS:** It’s tied to a `bridge-domain` with its own config space.
 +
 +----
 +
 +==== 🔑 5. Ingress Replication ====
 +
 +  * **Purpose:** Defines how BUM (Broadcast, Unknown unicast, Multicast) traffic is replicated.
 +  * **Modes:**
 +    - `static`: manual peer definition
 +    - `multicast`: uses multicast groups in the underlay
 +
 +----
 +
 +==== 🔑 6. Underlay vs Overlay ====
 +
 +  * **Underlay:**
 +    - The physical IP network that connects VTEPs (e.g., `172.18.32.0/30`)
 +    - Uses IGP or static routing
 +  * **Overlay:**
 +    - The logical L2 network created by VXLAN
 +    - Carries tenant VLANs across routed core
 +
 +----
 +
 +==== 🔑 7. BUM – Broadcast, Unknown Unicast, Multicast ====
 +
 +  * **Definition:** Types of traffic replicated across all members in a segment.
 +  * **Handled in VXLAN by:**
 +    - Static `ingress-replication`
 +    - Multicast (if supported by underlay)
 +
 +----
 +
 +==== 🧾 Summary Table ====
 +
 +^ Element         ^ Description                                 ^ Example                    ^
 +| VLAN            | Traditional L2 segment                      | 700                        |
 +| VNI             | VXLAN segment identifier                    | 10700                     |
 +| VTEP (Local)    | Source tunnel endpoint                      | 172.18.32.33 (Cisco C9500)|
 +| VTEP (Remote)   | Destination tunnel endpoint                 | 172.18.32.34 (Aruba 6300) |
 +| NVE Interface   | VXLAN-capable logical interface             | `interface nve1`          |
 +| Underlay        | Physical routed IP network                  | `172.18.32.32/30`         |
 +| Overlay         | Virtual network over VXLAN                  | VNIs mapped to VLANs      |
 +
 +----
 +
 +==== ✅ VXLAN overlays  ====
 +
 +allow to:
 +  * Stretch VLANs across L3 boundaries
 +  * Enable mobility and segmentation
 +  * Scale beyond 4094 VLAN limit using 16 million VNIs
 +
 +----
 +----
 +
 +====== VXLAN Static Configuration – Cisco 9500 ⇄ Aruba 6300 ======
 +
 +=== 📘 Architecture Summary ===
 +
 +^ Parameter               ^ Cisco 9500 (C9500SP1)         ^ Aruba 6300M (6300SP2)         ^
 +| VTEP Loopback IP        | 172.22.32.1                    | 172.22.32.2                    |
 +| Transport IP            | 172.18.32.33 (To Aruba)        | 172.18.32.34 (To Cisco)        |
 +| Transport Interface     | Routed PtP /30 via TenG        | Routed PtP /30 via 1/1/12      |
 +| OSPF Area               | 0                              | 0                              |
 +| VXLAN Mode              | Static VXLAN                   | Static VXLAN                   |
 +| VXLAN Interface         | `nve1`                         | `vxlan 1`                      |
 +| VNIs                    | 10001, 10700–10732             | 10001, 10700–10732             |
 +| Inter-VXLAN Bridging    | Not applicable                 | `static-all` or `static-evpn`  |
 +
 +----
 +
 +=== 🚀 Cisco 9500 Configuration ===
 +
 +==== 🔹 1. VTEP Loopback ====
 +  interface Loopback0
 +   ip address 172.22.32.1 255.255.255.255
 +
 +==== 🔹 2. Transport Interface ====
 +  interface TenGigabitEthernet1/0/12
 +   description Link to Aruba 6300
 +   ip address 172.18.32.33 255.255.255.252
 +   no shutdown
 +
 +==== 🔹 3. OSPF ====
 +  router ospf 100
 +   router-id 1.1.1.1
 +   network 172.18.32.32 0.0.0.3 area 0
 +   network 172.22.32.1 0.0.0.0 area 0
 +
 +==== 🔹 4. Static Route ====
 +  ip route 172.22.32.2 255.255.255.255 172.18.32.34
 +
 +==== 🔹 5. NVE Interface ====
 +  interface nve1
 +   no shutdown
 +   source-interface Loopback0
 +   member vni 10001 ingress-replication 172.22.32.2
 +   member vni 10700 ingress-replication 172.22.32.2
 +   member vni 10712 ingress-replication 172.22.32.2
 +   member vni 10730 ingress-replication 172.22.32.2
 +   member vni 10732 ingress-replication 172.22.32.2
 +
 +==== 🔹 6. Bridge Domains ====
 +  bridge-domain 1
 +   member vni 10001
 +
 +  bridge-domain 700
 +   member vni 10700
 +
 +  bridge-domain 712
 +   member vni 10712
 +
 +  bridge-domain 730
 +   member vni 10730
 +
 +  bridge-domain 732
 +   member vni 10732
 +
 +----
 +
 +=== 🧩 Aruba 6300 Configuration ===
 +
 +==== 🔹 1. Loopback Interface ====
 +  interface loopback 0
 +   ip address 172.22.32.2/32
 +
 +==== 🔹 2. Transport Interface ====
 +  interface 1/1/12
 +   description Link to Cisco 9500
 +   ip address 172.18.32.34/30
 +   no shutdown
 +
 +==== 🔹 3. OSPF ====
 +  router ospf
 +   router-id 2.2.2.2
 +   area 0.0.0.0
 +     interface 1/1/12
 +     interface loopback 0
 +
 +==== 🔹 4. Static Route ====
 +  ip route 172.22.32.1/32 172.18.32.33
 +
 +==== 🔹 5. VXLAN Interface ====
 +  interface vxlan 1
 +   source 172.22.32.2
 +   inter-vxlan-bridging-mode static-all
 +
 +==== 🔹 6. VNI to VLAN Mapping ====
 +  vxlan vlan 1 vni 10001
 +   vxlan vtep 172.22.32.1
 +
 +  vxlan vlan 700 vni 10700
 +   vxlan vtep 172.22.32.1
 +
 +  vxlan vlan 712 vni 10712
 +   vxlan vtep 172.22.32.1
 +
 +  vxlan vlan 730 vni 10730
 +   vxlan vtep 172.22.32.1
 +
 +  vxlan vlan 732 vni 10732
 +   vxlan vtep 172.22.32.1
 +
 +----
 +
 +=== 🧪 Validation Commands ===
 +
 +==== 🔸 Cisco 9500 ====
 +  show nve interface nve1
 +  show nve vni summary
 +  show nve vni interface nve 1
 +  show nve peers
 +  ping 172.22.32.2 source 172.22.32.1
 +  show mac address-table vlan 712
 +
 +==== 🔸 Aruba 6300 ====
 +  show interface vxlan 1
 +  show interface vxlan vni vteps
 +  ping 172.22.32.1 source 172.22.32.2
 +  show mac-address-table vlan 712
 +
 +
 +
 +=== ✅ Notes ===
 +
 +  * The VXLAN tunnels use **static replication** for simplicity and full control.
 +  * Ensure **Loopback reachability** via static route or OSPF in both directions.
 +  * For production EVPN deployment, BGP configuration will be required.
 +
 +
 +
 +----
 +----
 +
 +{{ :aruba_networks:switch:6400:vxlan_cli_ap.pdf |}}
 +
 +{{pdfjs 46em >:aruba_networks:switch:6400:vxlan_cli_ap.pdf}}
 +
 +----
 +----
 +
 +
 +{{ :cisco:switch:9500:mtu_utm_switch_6400_9500.pdf |}}
 +
 +{{pdfjs 46em >:cisco:switch:9500:mtu_utm_switch_6400_9500.pdf}}
 +
 +
 +
 +----
 +----
 +
 +====== Cisco C9500 SUR — Timeout de SSH desde sitio remoto (MTU residual de VXLAN) ======
 +
 +**Fecha:** 2026-06-11
 +**Equipo:** C9500SP1 (LAG-17-C9500SP2) — 172.20.28.37 (SUR, sitio local)
 +**Estado:** Resuelto
 +
 +===== Síntoma =====
 +El SSH al switch funcionaba desde la LAN local del mismo sitio, pero daba timeout desde el sitio remoto de gestión (10.57.0.x). El ping ICMP y el SNMPv3 (snmpget) desde el sitio remoto funcionaban bien; solo fallaba el SSH (y el playbook de baseline de ASH, que usa SSH) con "Connection timed out". Aparentaba funcionar solo mientras había una sesión local activa.
 +
 +===== Causa raíz =====
 +Problema de MTU en el path, secuela del VXLAN removido:
 +  * El path WAN/VPN entre el sitio local y el sitio remoto tiene MTU menor a 1500 (ping con DF: 1400 pasa, 1500 falla con "MMMMM" = fragmentación necesaria con DF activo).
 +  * La SVI de gestión **Vlan1** había quedado con **MTU 9100 (jumbo)**, heredado de la configuración VXLAN.
 +  * Con ese MTU local jumbo, el switch enviaba segmentos TCP grandes hacia el sitio remoto (respetando el MSS anunciado por el cliente, 1460), y esos paquetes de ~1500 morían en el enlace de ~1400. ICMP/SNMP (paquetes chicos) pasaban; por eso solo se rompía el SSH/TCP.
 +  * También explica por qué solo este switch fallaba y no los demás del SUR: los otros tienen MTU normal en su interfaz de gestión.
 +
 +Un ''ip tcp mss 1360'' global por sí solo NO lo resolvió, porque solo limita el MSS que el switch //anuncia// (dirección cliente -> switch), no lo que el switch //envía// hacia el sitio remoto.
 +
 +===== Solución =====
 +Bajar el MTU de IP de la SVI de gestión para que quepa en el path. Es seguro: solo afecta el MTU de IP de Vlan1 (gestión), no el MTU L2, ni las interfaces físicas/uplinks, ni el tráfico de producción. No genera flap. Reversible con ''no ip mtu''.
 +
 +<code>
 +configure terminal
 +interface Vlan1
 + ip mtu 1400
 +end
 +write memory
 +</code>
 +
 +Limpieza opcional (el mss clamp global no era necesario y deja un warning de throughput):
 +<code>
 +configure terminal
 +no ip tcp mss 1360
 +end
 +write memory
 +</code>
 +
 +===== Validación =====
 +Desde el sitio remoto de gestión:
 +<code bash>
 +ssh admin@172.20.28.37
 +</code>
 +El SSH ahora conecta normal. El SNMPv3 ya estaba en su lugar:
 +<code bash>
 +snmpget -v3 -l authPriv -u ash-monitor -a SHA -A '<auth>' -x AES -X '<priv>' 172.20.28.37 1.3.6.1.2.1.1.5.0
 +# -> STRING: "C9500SP1.example.local"
 +</code>
 +
 +===== Comandos de diagnóstico (referencia) =====
 +<code>
 +! Confirmar el MTU del path (desde el switch)
 +ping 10.57.0.241 source Vlan1 size 1400 df-bit repeat 5   ! pasa
 +ping 10.57.0.241 source Vlan1 size 1500 df-bit repeat 5   ! falla (MMMMM)
 +
 +! Confirmar el MTU jumbo en la SVI de gestión
 +show interface Vlan1 | include MTU                        ! mostró MTU 9100
 +</code>
 +
 +===== Notas =====
 +  * Tras cualquier remoción futura de VXLAN en un switch, revisar el MTU de la SVI de gestión: el residuo jumbo causa exactamente este síntoma.
 +  * El playbook baseline de ASH usa SSH, así que esto también desbloquea LAG-17 en baseline_south.yml en la próxima corrida.
 +
 +----
 +----
cisco/switch/9500/cisco_catalyst_9500_series_manual.1747762610.txt.gz · Last modified: by aperez
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki