لب عملی: پیکربندی NETCONF برای دسترسی برنامه‌نویسی‌شده به دستگاه

این لب عملی NETCONF را روی یک روتر فعال می‌کند و آن را از یک ایستگاه مدیریتی برای بازیابی پیکربندی اینترفیس به‌عنوان داده XML ساختاریافته استفاده می‌کند، و رویکرد برنامه‌نویسی مبتنی‌بر-مدل که مکمل مدیریت سنتی مبتنی‌بر-CLI است را نشان می‌دهد.

پیکربندی NETCONFمدل داده YANGبازیابی XML ساختاریافته

~3 min read · Updated Sep 26, 2026

هدف لب

فعال‌کردن NETCONF روی یک روتر، اتصال به آن از یک ایستگاه مدیریتی با استفاده از یک جلسه NETCONF مبتنی‌بر-SSH، بازیابی پیکربندی اینترفیس به‌عنوان XML ساختاریافته به‌جای خروجی متن CLI، و ایجاد یک تغییر پیکربندی از طریق NETCONF، و تأیید اینکه دقیقاً مانند یک تغییر مبتنی‌بر-CLI تأثیر می‌گذارد.

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

هر وظیفه پیکربندی در سراسر این کل مجموعه از CLI سنتی استفاده کرده، که خروجی متنی قابل‌خواندن-توسط-انسان اما نه به‌طور قابل‌اعتماد قابل‌تجزیه-توسط-ماشین تولید می‌کند. NETCONF همان پیکربندی زیربنایی را از طریق داده XML ساختاریافته و مدل‌شده-با-YANG آشکار می‌کند، و ابزارهای اتوماسیون را قادر می‌کند به‌طور برنامه‌نویسی‌شده با دستگاه تعامل کنند به‌جای screen-scraping خروجی CLI.

توپولوژی لب

R1 ---- Gi0/0: 192.168.255.1/24

ایستگاه مدیریتی: 192.168.255.100، در حال
اجرای یک ابزار کلاینت NETCONF

وظیفه ۱: فعال‌کردن NETCONF روی R1

سرویس NETCONF-روی-SSH را روی روتر فعال کن.

وظیفه ۲: تأیید گوش‌دادن NETCONF

تأیید کن زیرسیستم NETCONF فعال است و اتصالات را می‌پذیرد.

وظیفه ۳: برقراری یک جلسه NETCONF و بازیابی پیکربندی

از ایستگاه مدیریتی، از طریق NETCONF متصل شو و پیکربندی در حال اجرا برای یک اینترفیس خاص را به‌عنوان XML بازیابی کن.

وظیفه ۴: ایجاد یک تغییر پیکربندی از طریق NETCONF

با استفاده از یک عملیات edit-config در NETCONF، توصیف اینترفیس را تغییر بده.

وظیفه ۵: تأیید تأثیرگذاری تغییر از طریق CLI

با استفاده از CLI سنتی، تأیید کن توصیف واقعاً اعمال شده.

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

R1(config)# netconf-yang

R1# show netconf-yang status

netconf-yang admin state: Enabled
netconf-yang oper state: Enabled
netconf-yang ssh state: Enabled
-- تأیید می‌کند NETCONF فعال است و برای
-- اتصالات، معمولاً روی پورت 830، گوش می‌دهد

ManagementStation> ssh -p 830 [email protected] -s netconf

-- پس از تبادل hello استاندارد NETCONF،
-- فرستادن یک درخواست get-config برای
-- اینترفیس‌ها:


  
    
      
        GigabitEthernet0/0
        
        true
      
    
  

-- دقیقاً همان اطلاعات اینترفیسی که یک
-- "show running-config interface gi0/0"
-- نشان می‌داد، اما به‌عنوان XML ساختاریافته
-- که یک اسکریپت می‌تواند به‌طور قابل‌اعتماد
-- بدون regex یا text-scraping تجزیه کند

-- فرستادن یک RPC edit-config:


  
    
    
      
        
          GigabitEthernet0/0
          Configured via NETCONF
        
      
    
  



-- روتر تغییر را پذیرفت و اعمال کرد، تأیید‌شده
-- توسط پاسخ ساده 

R1# show running-config interface gigabitethernet0/0

interface GigabitEthernet0/0
 description Configured via NETCONF
 ip address 192.168.255.1 255.255.255.0
-- توصیف تنظیم‌شده از طریق NETCONF کاملاً
-- قابل‌مشاهده و مؤثر از طریق CLI سنتی است، و
-- تأیید می‌کند هر دو اینترفیس دقیقاً همان
-- پیکربندی زیربنایی را مدیریت می‌کنند

نکته کلیدی

NETCONF و CLI دو اینترفیس متفاوت برای همان پیکربندی زیربنایی یکسان روتر هستند — یک تغییر انجام‌شده از طریق یکی بلافاصله از طریق دیگری قابل‌مشاهده و مؤثر است، چون هیچ‌کدام یک فروشگاه پیکربندی جداگانه نیست — و خروجی XML ساختاریافته و مدل‌شده-با-YANG NETCONF به‌طور خاص چیزی است که اتوماسیون برنامه‌نویسی‌شده قابل‌اعتماد را عملی می‌کند، و جایگزین screen-scraping شکننده متن CLI که اسکریپت‌های اتوماسیون تاریخاً باید به آن تکیه می‌کردند می‌شود.

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