Open-Networking

 

   Jinja2 --- Quick Summary  {% for %} → start loop {% endfor %} → end loop  {{ }} → print value  loop.last → avoid last comma

YAML = data structure Ansible = loops + conditions + variables   Ansible Playbook YAML keywords 1.Most Important Keywords name hosts tasks vars roles 2.Modules (Core Workhorses) shell  command debug copy - local to remote (only) fetch - remote to local template 3.Conditions & Control when loop loop_control register 4.Task Behavior Control changed_when failed_when ignore_errors become 5.tags 6.Facts & Host Info inventory_hostname hostvars 7.blocks ##ansible basics Ansible automates tasks on remote machines using SSH + YAML playbooks Role = reusable bundle of tasks, templates, variables, and handlers for a specific function ## frequently used ansible modules  - template: generate config - command: apply config - command: save config - debug: verify root@digi-oss:/home/labadmin# cat inventory.ini [bb] server1 ansible_host=172.27.64.115 ansible_user=labadmin server2 ansible_host=172.27.64.116 ansible_user=labadmin server3 ansible_host=172.27.64.117 ansible_use...

  1.SONiC Architecture - Layers Layer                What it does           Speed           Analogy 1.User Space        Logic, protocols   Slow              Brain 2.Kernel Space        OS networking           Medium        Nervous system 3.Hardware        Packet forwarding   Very fast        Muscles Big Picture User Space  →     Kernel Space  →  Hardware (SONiC apps)      (Linux OS)            (ASIC) a. User Space (SONiC Layer) - This is where SONiC containers + daemons run Includes: swss → orchagent, vlanmgrd, etc. bgp → bgpd, zebra teamd, lldp, snmp Redis (database container) Role: Process configs Run routing protocols Decide what...

  SONiC's architecture is built around one central idea: Redis as the system bus . Every daemon — whether it handles routing, port management, or ASIC programming — communicates exclusively by reading from and writing to Redis databases. No daemon calls another daemon directly. This makes the system modular, debuggable, and loosely coupled. Let's start with the big picture — how the layers stack from user CLI down to the ASIC. The data flows strictly top-down: CLI writes to CONFIG_DB → *mgrd daemons pick it up and write to APPL_DB → orchagent translates to SAI objects and writes to ASIC_DB → syncd reads ASIC_DB and programs the hardware. Now let's look at each daemon layer in detail. The *mgrd daemons — config translators These daemons live in the swss Docker container. They watch CONFIG_DB for changes and translate configuration into kernel/application state, also publishing to APPL_DB. swss container — switch state service Daemon     What it does    ...