پیکربندی و بررسی Trunk در Cisco IOS

پیش‌نیازهای Configuration

قبل از ورود به CLI، دو سمت Link و VLANهای موردنیاز را مشخص کن. اگر Uplink بین SW1 و SW2 باید VLANهای ۱۰،۲۰،۳۰ و Management VLAN 99 را حمل کند، این اطلاعات باید در Change Plan نوشته شود. همچنین بدان از کدام Interface برای مدیریت Switch استفاده می‌کنی؛ حذف ناخواسته Management VLAN از Allowed List می‌تواند Session مدیریتی را قطع کند.

SW1 Gi1/0/24 <-> SW2 Gi1/0/24
Native VLAN: 999
Allowed VLANs: 10,20,30,99
Management VLAN: 99
Rollback: restore previous trunk allowed list

همیشه قبل از تغییر خروجی فعلی را ذخیره کن. show running-config interface، show interfaces trunk و show vlan brief Baseline خوبی می‌دهند. اگر بعد از Change مشکلی ایجاد شد، می‌دانی چه چیزی تغییر کرده است.

show running-config interface Gi1/0/24
show interfaces Gi1/0/24 switchport
show interfaces trunk
show vlan brief

Change روی Uplink از Change روی Access Port پرریسک‌تر است چون یک اشتباه می‌تواند چند VLAN و تعداد زیادی کاربر را هم‌زمان قطع کند. قبل از تغییر باید Scope، مسیر مدیریت، Maintenance Window و Rollback را مشخص کنی. اگر SSH تو از همان Management VLAN عبور می‌کند که قصد تغییر Allowed List آن را داری، احتمال Lockout واقعی است. داشتن Console یا Out-of-Band Management ریسک را کم می‌کند. در نبود آن‌ها می‌توان از Reload in X به‌عنوان Safety Mechanism در بعضی سناریوها استفاده کرد، ولی این روش نیز باید با سیاست سازمان و آگاهی از اثر Restart برنامه‌ریزی شود و جایگزین Change Plan نیست.

ساخت Trunk استاتیک

در بسیاری از شبکه‌های سازمانی، Trunk استاتیک خواناتر و قابل پیش‌بینی‌تر از Negotiation پویا است. روی Catalystهای رایج IOS XE، switchport mode trunk Port را در حالت Trunk قرار می‌دهد. برخی Platformهای قدیمی‌تر ممکن است دستور انتخاب Encapsulation نیز داشته باشند، اما روی بسیاری از Catalystهای جدید 802.1Q تنها گزینه است و دستور switchport trunk encapsulation dot1q وجود ندارد.

SW1(config)# interface GigabitEthernet1/0/24
SW1(config-if)# description UPLINK_TO_SW2_Gi1/0/24
SW1(config-if)# switchport
SW1(config-if)# switchport mode trunk
SW1(config-if)# switchport trunk native vlan 999
SW1(config-if)# switchport trunk allowed vlan 10,20,30,99
SW1(config-if)# no shutdown

description بخشی از Function نیست اما در Operations بسیار ارزشمند است. switchport Interface را Layer 2 نگه می‌دارد، mode trunk نقش Port را مشخص می‌کند، native vlan VLAN بدون Tag معمول را تعیین می‌کند و allowed vlan دامنه VLANهای مجاز را محدود می‌سازد.

دستور switchport mode trunk وضعیت Administrative را صریح می‌کند، اما صحت End-to-End وابسته به سمت مقابل است. اگر SW1 trunk و SW2 access باشد، Link ممکن است Up باشد و حتی بخشی از Traffic غیرمنتظره عبور کند، اما Design ناسازگار است. بنابراین Configuration یک سمت را هرگز به‌تنهایی «تمام‌شده» حساب نکن. Description را نیز دوطرفه بنویس؛ مثلاً TO-SW2-Gi1/0/24. این کار در Rack و Remote Troubleshooting کمک می‌کند Peer را سریع پیدا کنی و اشتباه روی Uplink مشابه را کاهش می‌دهد.

مدیریت Allowed VLAN

دستور switchport trunk allowed vlan جایگزین Allowed List فعلی می‌شود. این رفتار یکی از خطاهای خطرناک عملیاتی است. اگر روی Portی که اکنون ۱۰,۲۰,۳۰,۹۹ را حمل می‌کند دستور switchport trunk allowed vlan 40 را بزنی، نتیجه فقط VLAN 40 است؛ VLANهای قبلی حذف می‌شوند. برای افزودن یا حذف تدریجی از add و remove استفاده کن.

! Replace the list
switchport trunk allowed vlan 10,20,30,99

! Add VLAN 40 without deleting current list
switchport trunk allowed vlan add 40

! Remove VLAN 20
switchport trunk allowed vlan remove 20

در Changeهای Remote این تفاوت حیاتی است. اگر Management VLAN را ناخواسته حذف کنی ممکن است Session SSH قطع شود. قبل از Commit ذهنی، همیشه Command را با Current State مقایسه کن.

Allowed VLAN List یک Policy است. Replace، add و remove باید آگاهانه استفاده شوند. همچنین واژه all به معنی همه VLANهای قابل Trunk روی Platform است و استفاده از آن باید Design-driven باشد. در بعضی سازمان‌ها VLANهای User فقط تا Access Layer لازم‌اند و VLANهای دیگر نباید به همه Access Switchها گسترش یابند. Pruning منطقی Broadcast Domainها را کوچک‌تر نگه می‌دارد و Blast Radius Configuration را کم می‌کند. با این حال اگر Listها بیش از حد پیچیده و بدون Documentation باشند، احتمال Missing VLAN بالا می‌رود؛ بنابراین امنیت و سادگی عملیاتی باید با هم طراحی شوند.

Verification بعد از Configuration

اول show interfaces trunk را ببین. Port باید Status برابر trunking داشته باشد و Native VLAN و Allowed List با Design تطابق داشته باشند. سپس show interfaces Gi1/0/24 switchport را برای Administrative/Operational Mode و جزئیات Port بررسی کن. بعد show vlan brief وجود VLANهای مورد انتظار را تأیید می‌کند.

SW1# show interfaces trunk
Port        Mode  Encapsulation  Status    Native vlan
Gi1/0/24    on    802.1q         trunking  999

Port        Vlans allowed on trunk
Gi1/0/24    10,20,30,99

Port        Vlans allowed and active in management domain
Gi1/0/24    10,20,30,99

عبارت allowed and active کمک می‌کند تفاوت بین Config و Data Plane را ببینی. ممکن است VLAN در Allowed List باشد اما اصلاً در VLAN Database محلی وجود نداشته باشد. در این حالت صرف وجود عدد در Allowed List کافی نیست.

SW1# show vlan brief
VLAN Name                             Status    Ports
10   FINANCE                          active
20   SALES                            active
30   SERVERS                          active
99   MGMT                             active
999  NATIVE                           active

Verification را با Expected Result انجام بده. قبل از Command بنویس انتظار داری چه ببینی: Po1 یا Gi1/0/24 باید trunking باشد، Native برابر ۹۹۹، Allowed برابر ۱۰,۲۰,۳۰,۹۹ و VLAN 99 Active. اگر فقط Output را نگاه کنی بدون Expected State، ممکن است Configuration اشتباه ولی آشنا را درست فرض کنی. این روش در Change Review بسیار مهم است؛ همکار می‌تواند Design را با Actual Output مقایسه کند. همچنین running-config فقط Intent را نشان می‌دهد، در حالی که show interfaceها Operational State را نشان می‌دهند؛ هر دو لازم‌اند.

Validation انتها به انتها

Verification فقط بررسی Config نیست. بعد از اینکه Output درست شد، Traffic واقعی را نیز تست کن. برای هر VLAN حداقل یک مسیر End-to-End انتخاب کن. اگر VLAN 10 و ۲۰ باید بین Switchها عبور کنند، Ping یا تست سرویس از Endpointهای همان VLAN روی دو سمت انجام بده. سپس MAC Table را بررسی کن تا ببینی MAC سمت مقابل روی Trunk یاد گرفته شده است.

show mac address-table vlan 10
show mac address-table vlan 20
show interfaces counters errors

اگر Trunk Config درست است اما MAC سمت مقابل دیده نمی‌شود، Scope را به سمت Link دیگر، STP، Endpoint یا Topology گسترش بده. هر Test باید چیزی را ثابت کند. show interfaces trunk وجود Trunk را ثابت می‌کند؛ Ping موفق Reachability را؛ MAC Learning وجود Layer 2 Traffic از سمت مقابل را.

بعد از Validation فنی، Application Test نیز انجام بده. Ping Gateway برای VLAN 20 ممکن است موفق باشد ولی سرویس CRM روی Server همان VLAN یا مسیر دیگر مشکل داشته باشد. Change Acceptance باید بر اساس چیزی باشد که قرار بود Change بهبود دهد. برای Uplink جدید می‌توان حداقل یک Endpoint در هر VLAN حیاتی، Management Reachability، Voice Registration یا DHCP و Error Counter را بررسی کرد. اگر فقط یک Ping موفق ثبت کنی، بخش بزرگی از Service Path هنوز آزمایش نشده است.