لب عملی: استفاده از Ansible برای اتوماسیون دستگاه شبکه

این لب عملی یک playbook ساده Ansible از یک control node برای پیکربندی یک banner و تأیید اتصال در سراسر دو روتر هم‌زمان می‌نویسد، و اتوماسیون بدون-عامل و مبتنی‌بر-SSH را با اسکریپت‌نویسی Guestshell روی-خود-دستگاه پوشش‌داده‌شده در لب قبلی مقایسه می‌کند.

Playbook در Ansibleاتوماسیون بدون-عاملپیکربندی فایل Inventory

~4 min read · Updated Sep 26, 2026

هدف لب

راه‌اندازی یک فایل inventory در Ansible که دو روتر را فهرست می‌کند، نوشتن یک playbook که یک banner ورود یکسان را روی هر دو هم‌زمان پیکربندی می‌کند، اجرای آن از یک control node جداگانه، و تأیید اینکه تغییر به‌درستی روی هر دستگاه بدون نصب هیچ نرم‌افزار عامل روی خود روترها اعمال شد.

هدف لب (چرا مهم است)

Guestshell، پوشش‌داده‌شده در لب قبلی، اتوماسیون را محلی روی یک دستگاه واحد اجرا می‌کند. Ansible به‌جای آن از یک control node جداگانه اجرا می‌شود و بسیاری دستگاه را به‌طور هم‌زمان از طریق SSH استاندارد مدیریت می‌کند، بدون نیاز به هیچ عامل یا نرم‌افزار خاصی نصب‌شده روی دستگاه‌های مدیریت‌شده — یک مدل اتوماسیون اساساً متفاوت که برای اعمال همان تغییر در سراسر یک کل ناوگان دستگاه به‌طور سازگار مناسب است.

توپولوژی لب

Control Node Ansible ---- SSH ---- R1: 192.168.60.1
                          SSH ---- R2: 192.168.61.1

هر دو روتر از قبل دسترسی SSH پیکربندی‌شده با
یک نام‌کاربری/رمز عبور محلی دارند

وظیفه ۱: ساخت فایل Inventory در Ansible

یک فایل inventory که هر دو روتر را با جزئیات اتصالشان فهرست می‌کند بساز.

وظیفه ۲: نوشتن یک Playbook برای پیکربندی یک Banner

یک playbook با استفاده از ماژول ios_banner بنویس که یک banner ورود یکسان را روی هر دو دستگاه تنظیم کند.

وظیفه ۳: اجرای Playbook

playbook را در برابر inventory اجرا کن و فرآیند اتصال و پیکربندی برای هر دو روتر را مشاهده کن.

وظیفه ۴: تأیید Banner روی هر دو روتر

تأیید کن هر روتر اکنون banner پیکربندی‌شده را نشان می‌دهد.

وظیفه ۵: تأیید عدم‌نصب نرم‌افزار عامل

تأیید کن روترها هیچ نرم‌افزار خاصی فراتر از دسترسی SSH استاندارد برای کارکردن این اتوماسیون نیاز نداشتند.

راه‌حل و تأیید

# inventory.ini (روی control node)

[routers]
R1 ansible_host=192.168.60.1
R2 ansible_host=192.168.61.1

[routers:vars]
ansible_network_os=ios
ansible_user=netadmin
ansible_password=NetAdmin2026
ansible_connection=network_cli

# banner-playbook.yml

- name: Configure login banner on all routers
  hosts: routers
  gather_facts: no
  tasks:
    - name: Set banner
      ios_banner:
        banner: login
        text: |
          Authorized access only.
          Automated via Ansible.
        state: present

ControlNode$ ansible-playbook -i inventory.ini banner-playbook.yml

PLAY [Configure login banner on all routers] ***

TASK [Set banner] **************************
changed: [R1]
changed: [R2]

PLAY RECAP **********************************
R1  : ok=1  changed=1  unreachable=0  failed=0
R2  : ok=1  changed=1  unreachable=0  failed=0
-- هر دو روتر در یک اجرای playbook واحد، از
-- طریق SSH استاندارد، پیکربندی شدند -- Ansible
-- با استفاده از همان مکانیزم network_cli که
-- یک مهندس انسانی به‌طور تعاملی استفاده
-- می‌کرد متصل شد

R1# show running-config | begin banner

banner login ^C
Authorized access only.
Automated via Ansible.
^C

R2# show running-config | begin banner

banner login ^C
Authorized access only.
Automated via Ansible.
^C
-- banner یکسان روی هر دو دستگاه حاضر تأیید شد

R1# show processes | include ansible
-- (بدون خروجی -- هیچ‌چیز مرتبط با Ansible روی
--  خود روتر در حال اجرا نیست، چون Ansible
--  کاملاً از control node با استفاده از SSH
--  استاندارد عمل می‌کند، برخلاف رویکرد
--  کانتینر روی-خود-دستگاه Guestshell از لب قبلی)

نکته کلیدی

معماری بدون-عامل Ansible یعنی خود روترها نیازی به چیزی فراتر از دسترسی SSH‌ای که احتمالاً از‌قبل برای مدیریت معمولی پیکربندی کرده‌اند ندارند — همه منطق و اجرای اتوماسیون روی control node رخ می‌دهد، و دقیقاً همان‌طور که یک مدیر انسانی از طریق SSH متصل می‌شد به هر دستگاه متصل می‌شود، که اعمال پیکربندی سازگار در سراسر یک ناوگان بزرگ را بدون هیچ رد پای نرم‌افزاری خاصی روی دستگاه‌های مدیریت‌شده ساده می‌کند، در تضاد مستقیم با رویکرد Guestshell از اجرای کد محلی روی هر دستگاه منفرد.

Written & researched by Dr. Shahin Siami

Related Articles

لب عملی: چالش عیب‌یابی جامع نهایی CCNP (یکپارچگی BGP، DMVPN، و QoS)

این لب عملی یک شکست پیچیده چندلایه در سراسر یک توپولوژی یکپارچه BGP-روی-DMVPN ترکیب‌شده با علامت‌گذاری QoS ارائه می‌دهد، و نیازمند تشخیص سیستماتیک یک پیکربندی نادرست route reflector، یک شکست ثبت NHRP، و یک سیاست QoS نادرست‌اعمال‌شده که هم‌زمان روی همان شبکه تأثیر می‌گذارند است.

Continue

لب عملی: پیکربندی BGP روی DMVPN

این لب عملی iBGP را به‌عنوان پروتکل مسیریابی در سراسر همان توپولوژی hub-and-spoke DMVPN استفاده‌شده در دو لب قبلی اجرا می‌کند، hub را به‌عنوان یک route reflector BGP پیکربندی می‌کند طوری‌که spoke ها مسیرهای یکدیگر را بدون یک mesh کامل iBGP یاد بگیرند، و دو مفهوم قبلاً جداگانه را در یک طراحی یکپارچه ترکیب می‌کند.

Continue

لب عملی: پیکربندی OSPF روی DMVPN

این لب عملی OSPF را به‌عنوان پروتکل مسیریابی پویا در سراسر همان توپولوژی hub-and-spoke DMVPN اجرا می‌کند، و اینترفیس تونل را به‌عنوان یک نوع شبکه OSPF point-to-multipoint پیکربندی می‌کند تا الگوی همسایگی hub-and-spoke را به‌درستی بدون نیاز به انتخاب DR/BDR نوع شبکه broadcast مدیریت کند.

Continue

لب عملی: پیکربندی EIGRP روی DMVPN

این لب عملی EIGRP را به‌عنوان پروتکل مسیریابی پویا در سراسر توپولوژی hub-and-spoke DMVPN ساخته‌شده در لب‌های قبلی اجرا می‌کند، و تأیید می‌کند روابط همسایه به‌درستی در سراسر تونل چندنقطه‌ای شکل می‌گیرند و مسیرها بدون نیاز به پیکربندی ایستای هر-spoke روی hub منتشر می‌شوند.

Continue

لب عملی: پیکربندی احراز هویت MD5 در HSRP

این لب عملی احراز هویت MD5 را روی یک گروه HSRP پیکربندی می‌کند، و تأیید می‌کند دو روتر با رشته‌های احراز هویت منطبق یک رابطه active/standby معمولی تشکیل می‌دهند در حالی که یک روتر با رشته نامنطبق کاملاً از گروه مستثنی می‌شود.

Continue

لب عملی: پیکربندی امنیت DNS به‌سبک-Cisco Umbrella از طریق تغییرمسیر Forwarding DNS

این لب عملی یک روتر را برای رهگیری هر پرس‌وجوی DNS کلاینت و تغییرمسیر آن به‌سمت یک resolver DNS امنیت-محور با استفاده از رهگیری forwarding DNS پیکربندی می‌کند، و اعمال امنیت DNS تحویل‌شده-با-ابر را بدون نیاز به تغییرات پیکربندی به‌ازای-هر-کلاینت تقریب می‌زند.

Continue