Explain full QoS pipeline in a switch

-
 
Explain full QoS pipeline in a switch

At ingress, packets are parsed, classified, optionally remarked, and policed using token bucket meters.
 Accepted packets are buffered and forwarded through the switch fabric. 
At egress, packets are placed into queues, scheduled using algorithms like strict priority or WRR, optionally shaped to enforce rate limits, and then transmitted.

Ingress Port
   ↓
Parser
   ↓
Classification (ACL / DSCP / VLAN / etc.)
   ↓
Remarking (optional)
   ↓
Policing (Token Bucket Meter)
   ↓
Ingress Buffer / VOQ Admission
   ↓
Switch Fabric
   ↓
Egress Queue
   ↓
Congestion Detection (Queue depth thresholds)
   ↓
Congestion Action:
   - ECN Marking
   - WRED Drop
   - PFC Trigger (if lossless class)
   ↓
Scheduling (SP / WRR / DWRR)
   ↓
Shaping (Token Bucket based)
   ↓
Transmit



Congestion marking such as ECN or WRED occurs at the egress stage based on queue depth thresholds. The packet is marked or dropped before scheduling and transmission, as congestion is detected at the output queue.


Comments

Post a Comment

Popular posts from this blog

gNMI_with_grafana on containerlabs

-
Image
  root@digi-oss:/home/labadmin/mohan/2jan26_grafana# cat sr_lab.clab.yml name: sr_lab topology:   nodes:     sr1 : {kind: nokia_srlinux, image: ghcr.io/nokia/srlinux:latest, startup-config: sr1.cfg}     sr2 : {kind: nokia_srlinux, image: ghcr.io/nokia/srlinux:latest, startup-config: sr2.cfg}     # gNMIc Collector     gnmic:       kind: linux       image: ghcr.io/openconfig/gnmic:latest       binds: [gnmic-config.yml:/app/gnmic-config.yml:ro]       cmd: "--config /app/gnmic-config.yml subscribe"     # Prometheus TSDB     prometheus:       kind: linux       image: prom/prometheus:latest       binds: [prometheus.yml:/etc/prometheus/prometheus.yml:ro]       ports: ["9090:9090"]     # Grafana Visualization     grafana:       kind: linux       image: grafa...
Read more

EVPN Route type-1 & type-4 in action

-
Image
 Route Type 1: Ethernet Auto-Discovery (A-D) A Type 1 route is advertised by a PE router on a per-Ethernet Segment Identifier (ESI) basis. It is triggered by the presence of a multihomed connection.  Purpose of Type 1 routes Aliasing:  In an all-active multihoming setup, a Type 1 route informs remote PE routers that an Ethernet segment is reachable via multiple PEs. This allows for load-balancing traffic to the same customer device over multiple paths. Fast convergence (Mass MAC Withdrawal):  If a local link to a multihomed customer device fails, the PE sends a withdrawal message for the Type 1 route. Remote PEs can then withdraw all MAC addresses associated with that Ethernet segment, instead of waiting for individual MAC withdrawals, which speeds up convergence. Split-horizon filtering:   The route carries an ESI label to prevent traffic loops in all-active mode. A PE router won't forward broadcast, unknown unicast, and multicast (BUM) traffic back to its sour...
Read more

Network Automation with ROBOT Framework

-
Image
  Folder-structure Scripts testcase_with_keywordsLibrary.robot *** Settings *** Documentation    Test Case With Keyword Resource         Resources/Keywords/common.robot Resource          Resources/Keywords/vxlanInstance.robot Test Setup        Open Connection Test Teardown    Close Connection *** Test Cases *** [Documentation] Step 1: Verify VXLAN Interface Status     VXLAN Interface Status [Documentation] Step 2: Verify VXLAN VNI to VLAN Mapping     VXLAN VNI to VLAN Mapping Resources/Keywords/common.robot *** Settings *** Documentation    Common Keyword Library Library          ../../Libraries/commonLib.py Variables        ../Variables/veosLeaf01.yaml *** Variables *** ${devType}         ${virtualBox}[vmType] ${ipAddr}          ${virtualBox}[vmManagement][hostIp] ${po...
Read more