Campus → VLANs + STP + 802.1X + HSRP + OSPF Branch → IPSec + SD-WAN + BGP + simple VLANs  Enterprise → BGP + MPLS + SD-WAN OMP + IPSec + OSPF  DC → eBGP (underlay) + VXLAN + EVPN (overlay) SP → IS-IS + BGP (full table) + MPLS + SR-MPLS/SRv6 + EVPN L2VPN + L3VPN 

    5 points you can understand why using ECN and PFC Together to Build Lossless Ethernet Networks in AI infrastructure:   1- Both ECN and PFC by themselves can manage congestion very well. By working together, they can be even more effective. 2- ECN can react first to mitigate congestion. If ECN does not react fast enough and buffer utilization continues to build up, PFC behaves as a fail-safe and prevents traffic drops. This is the most efficient way to manage congestion and build lossless Ethernet networks. 3-This collaborative process between PFC and ECN where they managed congestion together is called Data Center Quantized Congestion Notification (DCQCN) and is developed for RoCE networks. 4- By working together, PFC and ECN provide efficient end-to-end congestion management. When the system is experiencing minor congestion where buffer usage is moderate, WRED with ECN manages the congestion seamlessly. 5- For both WRED and ECN to work as described, yo...

  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 ...

  BGP “BGP Communities – Customer Guide” What Is Common vs Optional Feature Common Blackhole ✅ Almost universal Local-pref TE ✅ Very common ISP prepend ✅ Common No-export ✅ Universal Graceful shutdown ⚠️ Increasing Geo-based control ⚠️ Large ISPs Customer MED control ❌ Rare Prefix tag -   used to avoid re-distribution loops while doing mutual re-distribution IP SLA -  track service availability (like ping to 8.8.8.8) and switch to other route. this is applied on static route also if we have 2 ISPs and if we want auto switch-over OSPF safe Drain -  use max-metric router-lsa BGP safe drain -  1.Advertise a high MED value: router bgp 65101 max-med administrative 10000 2.Use the BGP community GRACEFUL_SHUTDOWN (RFC8326): router bgp 65101 graceful-shutdown BFD Enterprise dual ISP 1️⃣ IP SLA triggers 2️⃣ Local-pref drop 3️⃣ Default route withdrawn 4️⃣ Neighbor shutdown if needed DC leaf / border maintenance 1️⃣ OSPF max-metric 2️⃣ BGP graceful-shutdown commu...

 #Scenario (single LAN) Router R1 Host H1 Ethernet LAN Step#0 Power on / link up H1 comes up on the Ethernet link. No IPv6 address yet. Step#1 Host creates its link-local address Prefix (fixed): fe80::/64 Interface ID (modern – random): a1b2:33ff:fe44:5566 Link-local address: fe80::a1b2:33ff:fe44:5566 note:-Every IPv6 interface MUST have a link-local Step#2 Host runs DAD (uses multicast + MAC) Solicited-node multicast for its own address Last 24 bits of link-local: 44:5566 Solicited-node multicast IPv6: ff02::1:ff44:5566  -- 24bit form above Multicast MAC: 33:33:ff:44:55:66 - 32 bit from above H1 sends Neighbor Solicitation: Src IPv6: :: Dst IPv6: ff02::1:ff44:5566 Dst MAC: 33:33:ff:44:55:66 No reply → link-local is valid  Step#3 Router sends Router Advertisement (RA) Client can initiate RS (router solicitation - FF02::2   ) Router’s link-local: fe80::1 Router sends RA to: IPv6 multicast ff02::1    (all-nodes) Ethernet multicast MAC: 33:33:00:00:00:01...

  ADD-PATH vs MULTIPATH — Very Important Difference Feature ADD-PATH Multipath Purpose Allow RR to send multiple paths Allow router to install multiple paths Where it works Between BGP peers Inside router’s RIB/FIB Required for ECMP? Yes, in iBGP with RR Yes, for actual load balancing When used EVPN fabrics, iBGP All BGP deployments Key idea: ADD-PATH allows multiple paths to be advertised. Multipath allows multiple paths to be installed. You usually enable BOTH in EVPN/VXLAN.

 

 | Policy Tool      | Used For                 | | ---------------- | ------------------------ | | Prefix-list      | Fast prefix filtering    | | Route-map        | Conditional policy logic | | ACL              | Legacy filtering         | | BGP Community    | Route tagging            | | AS-Path filter   | Loop & transit control   | | Route tag        | Redistribution safety    | | PBR              | Traffic steering         | | Distribute-list  | Basic filtering          | | Policy-statement | Modern policy framework  | | RPKI             | Route security           | ...

  RD- VTEP-IP:EVI instance ID RT- ASNNUMVER: VNI-ID Ex: for vlan based EVPN model VRF  VLAN  VNI    RD RT VRF-1    10     10100 10.1.1.11:10100    65001:10100 VRF-1 20 10200   10.1.1.11:10200 65001:10200 VRF-1 30 10300 10.1.1.11:10300 65001:10300 VRF-2 40 10400 10.1.1.11:10400 65001:10400 VRF-2 50 10500 10.1.1.11:10500 65001:10500 VRF-2 60 10600 10.1.1.11:10600 65001:10600

  Case-1: Traffic Egress from dual homed end-host  1.It may land on DF or non-DF based on hashing algorithm 2. For traffic from end-host to EVPN core DF,non-DF will not play any role 3. in case BUM lands on Leaf-1 it should flood to all the VTEPs participating on that vlan(vlan-10 in this case) 4.It may use head-end replication or underlay multicast (PIM) 5.all other VTEPS receive the BUM traffic (including Leaf-2 in this case) 6.reason for Leaf-2 to receive this - there should be other hosts on the same vlan (host-2) 7.now leaf-2 apply split-horizon rule. check the source VTEP ip and get to know its part of same ESI. and it wont forward to ESI-10 interface 8.But it can still forward to Host-2 Case-2: Traffic Ingress for dual-home server 1.Host-3 sends BUM traffic 2.Either head-end replication or underlay multicast 3.only DF will forward to the ESI segment 

  Transport-level keepalive NETCONF over SSH (most common)  Uses SSH keepalive NETCONF over TLS  Uses TLS keepalive / TCP keepalive NETCONF over TCP  Relies on TCP keepalive Application-level “soft keepalive” (common practice)**Although not mandated, many clients periodically send lightweight RPCs : Hello-Message Exchange 'Capabilities' base:1.0 base:1.1 candidate -Enables candidate → commit workflow, Safer than editing running directly writable-running -Allows editing running directly confirmed-commit   - Auto-rollback if device becomes unreachable rollback-on-error  - Roll back changes if any error occurs in <edit-config> lock  -Prevents concurrent config edits xpath  - Filtering & Query Critical for large YANG models notification - Enables event subscriptions validate - Validate config before commit 1️.Standard NETCONF Datastores (RFC 6241) These are the core datastores defined by NETCONF. 🔹 running Active configura...

 root@ems203-m1:/home/labadmin# kubectl get pods -A -o wide | grep suse ems               edgecloud-suse-adapter-58f584bbd7-h96nf                           1/1     Running     0             27m   10.233.67.198    ems203-w1   <none>           <none> ems               edgecloud-suse-adapter-58f584bbd7-q9p52                           1/1     Running     0             28m   10.233.98.86     ems203-w7   <none>           <none> ems               edgecloud-sus...