Altın Konu Spanning Tree'ye neden ihtiyacımız var?

Nizam-ı Alem · 15 Mar 2026

Bu sorunun kısa cevabı şudur: Ethernet, Ethernet döngüleri (katman-2 döngüleri veya yayın fırtınaları olarak da adlandırılır) nedeniyle yedekli topolojilerde çalışmaz. Yedekli bağlantılara sahip LAN'ı döngüsüz bir topolojiye dönüştüren bir teknoloji olmadan, BUM (yayın, bilinmeyen tek noktaya yayın ve çok noktaya yayın) çerçeveleri, bir bağlantı veya cihaz arızalanana kadar süresiz olarak döngüye girer. Bu, anahtarların BUM çerçevelerini yayma şeklinden kaynaklanır.

ÖNEMLİ: Ethernet, birbirine bağlı anahtarların üçgeni gibi döngülü anahtarlamalı topolojilerde çalışmaz. Topolojiyi döngüsüz hale getiren bir teknik kullanılmalıdır (örneğin Spanning Tree).

Anahtarlar ve BUM çerçeveleri
Bir anahtar bir çerçeve aldığında, hedef MAC adresini MAC tablosuyla karşılaştırır ve eşleşen bir giriş yoksa, çerçeveyi gelen arayüz hariç tüm arayüzlerden iletir. Bu işleme "yayılma" (flooding) denir ve hedef MAC adresi bilinmeyen çerçeveye "bilinmeyen tek noktaya yayın" (unknown unicast) denir.

Buradaki temel fikir şudur: Bir çerçeveyi tam olarak nereye ileteceğinizi bilmiyorsanız, her yere gönderin ve alıcı sonunda onu alacaktır. Ayrıca alıcının yanıt vermesi de muhtemeldir, bu nedenle anahtar her iki düğümün MAC adreslerini öğrenecek ve gelecekteki iletme işlemine bilinen tek noktaya yayın (known-unicast) olarak devam edecektir (çerçeveleri yaymadan).

Anahtarlar ayrıca iki başka çerçeve türünü de yayar:

yayın (broadcast) - Ethernet yayın adresine (FF-FF-FF-FF-FF-FF) yönlendirilmiş olanlar;
çoklu yayın (multicast) - '1110' bitleriyle başlayan MAC adresine yönlendirilmiş olanlar.

Şekil 1, PC1'in tek bir yayın çerçevesi gönderdiği bir örneği göstermektedir. Hedef MAC adresine dayanarak, 1 numaralı anahtar bunun bir yayın olduğunu bilir ve bu nedenle, gelen port hariç tüm portlarından bir kopyasını gönderir. Böylece çerçevenin bir kopyası SW2 ve SW3'e gider ve onlar da aynı mantığı uygular. Sonuç olarak, bu yayın alanındaki her düğüm bu paketin bir kopyasını alır.

Yukarıdaki LAN topolojisinde her şey yolunda çalışıyor, ancak bir arıza durumunda yedeklilik yok. SW2 ve S3 arasına yedek bir bağlantı eklersek ne olacağını görelim.

Ethernet Döngüleri (Yayın Fırtınaları)
Şekil 2'de gösterilen gibi döngülü bir anahtarlama topolojisi varsa ve Spanning-Tree çalışmıyorsa, üç ana sorun ortaya çıkar:

Sorun 1 - Tek bir döngüsel çerçeve bile yayın fırtınasına neden olur.
Bu, bir BUM (yayın, bilinmeyen tek noktaya yayın ve çok noktaya yayın) çerçevesinin anahtarlar arasında süresiz olarak döngü yapmasıyla olur. Bir yayın fırtınası, bir bağlantı aşırı doygun hale gelene ve arızalanana veya yüksek CPU kullanımı nedeniyle bir anahtar çökene kadar devam eder. Bu kavramı görselleştirmenize yardımcı olmak için, şekil 2'de gösterilen animasyonu oluşturduk. Tüm port LED'lerinin çok hızlı bir şekilde, genellikle eş zamanlı olarak yanıp söndüğünü ve anahtarların çok yüksek bir CPU kullanımında çalıştığını unutmayın. Bir şey arızalanıp döngüyü kırana kadar işlem devam edecektir.

Ethernet mantığı, anahtarlara gelen arayüz hariç tüm portlarda BUM çerçevelerini yaymalarını söyler. Şekil 2'de gösterilen örneğimize bu mantığı uygularsak, neler olduğunu görelim:

SW1, SW1-SW2 bağlantısında bir yayın çerçevesi alır, gelen arayüz (SW1-SW2 bağlantısı) hariç tüm portlarından (SW3 ve PC1'e) bir kopyasını gönderir;

SW3 yayın çerçevesini alır ve aynı mantığı uygular. Çerçevenin geldiği port hariç tüm portlarından bir kopyasını gönderir. Yani yayını SW2 ve PC3'e gönderir.

SW2 çerçeveyi alır, gelen bağlantı SW3-SW2 hariç tüm portlarından bir kopyasını gönderir. Yani yayını SW1 ve PC2'ye gönderir.

Ve işlem tekrarlanır ve sonsuza kadar devam eder.

Ayrıca, aynı döngünün ters yönde de gerçekleştiğine dikkat edin.

Problem 2 - Fırtına, MAC tablosu kararsızlığı adı verilen başka bir probleme neden olur.

MAC öğrenme sürecini hatırlarsak, bir anahtar bir çerçeve aldığında, kaynak adres ve gelen port için MAC adres tablosuna bir giriş oluşturur. Ancak yayın fırtınası durumunda, aynı çerçevenin birden fazla kopyası döngü halinde dolaşır ve anahtar bunu birden fazla arayüzde alır. Ancak tek bir MAC adresi yalnızca bir arayüze bağlanabilir. Bu nedenle anahtar, kaynak MAC adresi için girişi sürekli olarak farklı bir arayüzle yeniden yazar ve bu da kararsızlığa neden olur.

Aşağıdaki çıktıda, bir döngü mevcutken, bir anahtarın MAC adres tablosunu her kontrol ettiğimizde, vurgulanan MAC adresinin farklı bir porta bağlı olduğunu görebilirsiniz.

[CODE title="sw"]SW1#show mac address-table
Mac Address Table
-------------------------------------------

Vlan Mac Address Type Ports
---- ----------- -------- -----

1 0002.171d.6702 DYNAMIC Fa0/2
1 000b.be01.b603 DYNAMIC Fa0/3
1 00d0.979a.eb83 DYNAMIC Fa0/3

SW1#show mac address-table
Mac Address Table
-------------------------------------------

Vlan Mac Address Type Ports
---- ----------- -------- -----

1 0002.171d.6702 DYNAMIC Fa0/2
1 000b.be01.b603 DYNAMIC Fa0/3
1 00d0.979a.eb83 DYNAMIC Fa0/2

SW1#show mac address-table
Mac Address Table
-------------------------------------------

Vlan Mac Address Type Ports
---- ----------- -------- -----

1 0002.171d.6702 DYNAMIC Fa0/2
1 000b.be01.b603 DYNAMIC Fa0/3
1 00d0.979a.eb83 DYNAMIC Fa0/3[/CODE]

Problem 3 - Uç cihazlar aynı çerçevenin birden fazla kopyasını alıyor.
Bir döngü durumunda ortaya çıkan son sorun, yayın fırtınası aktifken uç istemcilerin döngüsel çerçevelerin birden fazla kopyasını tekrar tekrar almasıdır. Sonuç olarak, uç istemciler yüksek CPU kullanımı yaşayabilir ve kritik uygulamalar kaynak yetersizliğinden dolayı başarısız olabilir.

Örneğin PC1'e bakarsanız, aynı çerçevenin birden fazla kopyasını aldığını görebilirsiniz (siyah nokta tek bir yayın çerçevesini temsil eder). Örneğin, bu bir ARP çerçevesi ise, PC1 bunların her birini açar ve işler, bu da yüksek CPU kullanımına yol açabilir.

Özet
Ağ mühendislerinin Ethernet'in döngülü anahtarlamalı topolojilerde çalışmadığını anlamaları önemlidir. Bu nedenle, döngü topolojisini döngüsüz bir topolojiye dönüştürebilecek bir protokole ihtiyacımız var.