Statik Route Nedir? Default Route ve Yedek Yol Yapılandırma

Bir router’ın rotaları nasıl seçtiği, AD ve en uzun önek eşleşmesi Router Nasıl Karar Verir? yazısında anlatıldı. Bu yazı uygulamaya geçiyor: kampüste hangi statik rotanın hangi cihazda neden gerektiği, nasıl yazıldığı ve birincil internet bağlantısı gidince yedek yolun ne zaman devreye girip ne zaman girmediği.

Topoloji sitenin kampüs planı: core 10.0.254.1, firewall iç arayüzü 10.0.254.2, birincil ISP bağlantısı 203.0.113.0/30. Bu yazı için firewall’a 198.51.100.0/30 üzerinden bir yedek ISP eklendi. İki ISP ağı da RFC 5737’nin belge (TEST-NET) aralıklarıdır. Yapılandırma örnekleri resmî belgelerdeki sözdizimine göre yazıldı; laboratuvarda denenmedi. Çıktılar temsilîdir.

Default gateway mı, default route mu?

İki kavram aynı işi farklı yerlerde yapar: “bilmediğim hedefleri kime göndereyim?”

İstemcide default gateway: Bilgisayar, kendi ağı dışındaki her hedef için paketi gateway’e verir. Bu karar MAC, IP, ARP ve Default Gateway yazısında anlatıldı.
L2 switch’in yönetim adresi: Routing yapmayan bir switch’in de yönetim trafiği için bir gateway’e ihtiyacı vardır. Cisco bu iş için ip default-gateway komutunu yalnızca IP routing kapalıyken kullanmayı söyler. Catalyst 9200 IOS XE 17.9 kılavuzu bu yöntemle gateway’in düştüğünü anlamanın bir yolu olmadığını da belirtir. Huawei’de yönetim için ip route-static ile bir rota yazılır. CloudEngine S16700 V600R023C00 belgesine göre yönetim arayüzü varsayılan olarak _management_vpn_ adlı ayrı bir VPN instance’ında olabilir; o zaman rota da o instance içinde tanımlanır. Yönetim rotası, kullanıcı trafiğinin rotasıyla aynı tabloda olmayabilir.
L3 cihazda default route: Routing yapan cihazda bu iş routing tablosundaki 0.0.0.0/0 rotasıdır. Cisco buna “gateway of last resort” der ve ip route 0.0.0.0 0.0.0.0 için IP routing’in açık olmasını şart koşar.

Kampüste hangi rota, hangi cihazda?

VLAN 20 ve VLAN 30 core’da SVI olarak tanımlı olduğu için core bu ağları zaten bilir; connected rotalar için statik rota yazılmaz. Statik rotalar, cihazın kendiliğinden bilemeyeceği yerler içindir:

Statik rotalar, cihazın kendiliğinden bilemeyeceği yerler içindir: core dışarıyı, firewall kampüse dönüşü bilmez.

Core’da 0.0.0.0/0 → 10.0.254.2: Kampüs dışındaki her hedef firewall’a gider.
Core’da 10.0.0.0/16 → Null0: Kullanılmayan kampüs adreslerine giden paketler atılır. Neden gerektiği routing tablosu yazısında anlatıldı.
Firewall’da 10.0.0.0/16 → 10.0.254.1: Dönüş rotası. Firewall kampüs ağlarını bilmez; bu rota olmazsa internetten gelen yanıtları core’a değil, kendi default rotasına gönderir.
Firewall’da 0.0.0.0/0 → 203.0.113.2: Birincil ISP.

ISP tarafındaki rotalar ISP’nin yönetimindedir. Bu yazıdaki varsayım, kampüs adreslerinin firewall’da NAT ile 203.0.113.1’e çevrildiğidir; bu durumda ISP’nin kampüsün özel ağlarını bilmesi gerekmez.

Next-hop, çıkış arayüzü ya da ikisi

Bir statik rota üç biçimde yazılabilir ve üreticiler bu biçimlere aynı davranmaz.

Yalnızca next-hop IP: En yaygın biçim. Cisco’ya göre statik rotalar recursive’dir: next-hop’a giden herhangi bir rota olduğu sürece statik rota tabloda kalır. Cisco’nun örneğinde arayüz kapatıldığında bile next-hop başka bir rota üzerinden çözüldüğü için rota tabloda kaldı ve yedek rota hiç kurulmadı.
Yalnızca çıkış arayüzü: Seri hat gibi noktadan noktaya bağlantılarda yeterlidir. Ethernet’te sorun çıkarır. Cisco, ip route 0.0.0.0 0.0.0.0 Ethernet0 gibi bir rotada router’ın aralıktaki her hedefi doğrudan bağlı saydığını yazar: her hedef için ARP yapar. Bu yüksek işlemci kullanımına, çok büyük bir ARP önbelleğine ve bellek tahsis hatalarına yol açabilir. Huawei de Ethernet gibi broadcast arayüzlerde next-hop belirtilmesini ister.
İkisi birlikte: Cisco statik rotalarda çıkış arayüzünün ve next-hop’un birlikte belirtilmesini önerir. AOS-CX belgesi next-hop ya da arayüz yazılabileceğini söyler ama Ethernet’te yalnızca arayüz kullanımına ilişkin bir not içermez. FortiOS’ta gateway ve device ayrı alanlardır.

Yapılandırma: dört üreticide kısa örnek

Core’daki iki rota üç switch platformunda, firewall’daki iki rota FortiOS’ta. Örneklerde core’un firewall’a bakan arayüzü, routing tablosu yazısındaki gibi VLAN 254 SVI’sidir.

Cisco IOS XE (Catalyst 9000, core):

ip route 0.0.0.0 0.0.0.0 Vlan254 10.0.254.2
ip route 10.0.0.0 255.255.0.0 Null0

Huawei VRP (S5700/S6700 V200R023C10, core):

ip route-static 0.0.0.0 0 10.0.254.2
ip route-static 10.0.0.0 16 NULL 0

HPE Aruba AOS-CX 10.15 (6300, 6400, 8100, 83xx, 9300, 10000, core): nullroute paketi sessizce atar; reject ise atıp ICMP hata mesajı gönderir.

ip route 0.0.0.0/0 10.0.254.2
ip route 10.0.0.0/16 nullroute

FortiOS 7.6 (firewall): Arayüz adları örnektir.

config router static
    edit 1
        set dst 10.0.0.0 255.255.0.0
        set gateway 10.0.254.1
        set device "port1"
    next
    edit 2
        set dst 0.0.0.0 0.0.0.0
        set gateway 203.0.113.2
        set device "wan1"
    next
end

Rotanın tabloya girip girmediği Cisco’da show ip route static, Huawei’de display ip routing-table protocol static, FortiOS’ta get router info routing-table static, AOS-CX’te show ip route ile görülür. Yapılandırmada olan bir rotanın tabloda olmaması, daha düşük AD’li bir kaynağın aynı öneği vermesi ya da next-hop’un çözülememesi demektir. Tabloyu okumak routing tablosu yazısında anlatıldı.

Yedek yol: floating static

Firewall’a yedek ISP için ikinci bir default rota eklenir, ama daha yüksek AD ile. Aynı önek için düşük AD kazandığından birincil rota tablodayken yedek kurulmaz. Birincil tablodan çıktığında yedek kurulur. Tabloda “yüzen” bu rotaya floating static denir. FortiOS’ta örneğin birincil distance 10, yedek distance 20 ile yazılır; Huawei’de aynı fikir preference ile, Cisco ve AOS-CX’te AD ile uygulanır.

Bu tasarım iki farklı arızada farklı davranır:

Floating static fiziksel kopmayı kendiliğinden yakalar, ISP'nin ötesindeki kopmayı ise ancak uzak bir hedefi yoklayan izleme ile yakalar.

Fiziksel bağlantı kaybı: ISP’ye giden arayüz düşer. Arayüzün connected ağı tablodan çıkar, next-hop 203.0.113.2 çözülemez ve birincil rota kalkar. Yedek rota kurulur. Cisco’nun uyarısı burada önemlidir: next-hop başka bir rota üzerinden çözülebiliyorsa birincil rota tabloda kalabilir. Bu yüzden ISP rotalarında çıkış arayüzü ile next-hop’un birlikte yazılması önerilir.
Arayüz ayakta, upstream kopuk: ISP’nin ötesinde bir arıza var ama firewall’un arayüzü ve hatta ISP’nin kenar router’ı ayakta. Router’ın gördüğü hiçbir şey değişmediği için birincil rota tabloda kalır, yedek hiç devreye girmez ve internet erişimi kesilir. Floating static tek başına bu durumu fark edemez.

Next-hop erişilebilirliğini izlemek

İkinci arızayı yakalamak için cihazın bir hedefi düzenli olarak yoklaması ve sonuç olumsuzsa birincil rotayı tablodan kaldırması gerekir. Cisco ve Huawei örnekleri, firewall’un rolünü bir router’ın üstlendiği durumu gösterir; adresler aynıdır.

Cisco IOS XE, IP SLA ve Track: Cisco’nun 200785 numaralı belgesindeki yapı şöyledir:
```
ip sla 1
 icmp-echo 192.0.2.10 source-ip 203.0.113.1
ip sla schedule 1 life forever start-time now
track 8 ip sla 1 reachability
ip route 0.0.0.0 0.0.0.0 203.0.113.2 track 8
ip route 0.0.0.0 0.0.0.0 198.51.100.2 10
```
Cisco’nun örneği ISP’nin next-hop adresini yoklar. Bu, yalnızca o komşuya kadar olan yolu sınar. Burada yoklanan 192.0.2.10, ISP’nin ötesinde, temsilî bir dış hedeftir. Track düşünce izlenen rota kalkar ve yedek kurulur. Cisco’nun IP SLA komut başvurusuna göre source-ip yoklamanın kaynak adresini belirler; paketin birincil ISP’den çıkacağını tek başına garanti etmez. 192.0.2.10’a giden rota ve çıkış yolu ayrıca doğrulanmalıdır. Yoksa birincil rota kalkınca yoklama yedek yoldan başarılı olabilir ve birincil rota, upstream hâlâ kopukken geri dönebilir.
Huawei VRP, NQA ya da BFD: V200R023C10’da bir ICMP NQA test örneği statik rotaya track nqa ile bağlanır. NQA’nın hedef adresi, bağlı statik rotanın hedef adresiyle aynı olamaz. frequency verilmezse test yalnızca bir kez çalışır; sürekli izleme için bir aralık gerekir. quit ile sistem görünümüne dönülür; rotalar orada yazılır.
```
system-view
nqa test-instance admin isp1
 test-type icmp
 destination-address ipv4 192.0.2.10
 frequency <aralık>
 start now
 quit
ip route-static 0.0.0.0 0 203.0.113.2 track nqa admin isp1
ip route-static 0.0.0.0 0 198.51.100.2 preference 70
```
BFD ile izleme (track bfd-session) belgede yalnızca listelenen modellerde desteklenir (S5735-S, S6730-H gibi) ve BFD oturumu ile statik rotanın aynı bağlantıda olması gerekir.
FortiOS, link monitor: Link monitor, bir “detect server”ı ping, TCP echo, UDP echo, HTTP ya da TWAMP ile yoklar. Fortinet bu sunucunun genellikle birkaç atlama ötede, kararlı bir sunucu olmasını önerir. Yoklama başarısız olunca o arayüz ve gateway’e bağlı rotalar tablodan kaldırılır. 7.0’dan beri yalnızca route ile belirtilen rotalar kaldırılabilir.
```
config system link-monitor
    edit "isp1"
        set srcintf "wan1"
        set server "192.0.2.10"
        set gateway-ip 203.0.113.2
    next
end
```
AOS-CX 10.15, statik rota için BFD: Rotaya bfd eklenir (ip route 0.0.0.0/0 10.0.254.2 bfd) ve BFD önce bfd komutuyla genel olarak açılır. Belgede listelenen platformlar 6300 (S3L75A, S3L76A ve S3L77A hariç), 6400, 8100, 8325, 8325H, 8325P, 8360, 9300, 9300S ve 10000’dir. Bu örnek core’un firewall’a giden default rotası içindir.

BFD ile uzak hedef yoklaması aynı şey değildir. BFD iki sistem arasında kurulan bir oturumdur ve iki ucun da BFD çalıştırması gerekir. RFC 5880 BFD’yi doğrudan bağlantılarla sınırlamaz; çok atlamalı yolları da sayar, ayrıntısı RFC 5883’tedir. Bu yazıdaki AOS-CX örneği ise doğrudan bağlı komşu için tek atlamalı bir oturumdur ve yalnızca o komşuya kadar olan yolu gösterir. Oturumun ayakta olması, ISP’nin ötesindeki internet hizmetlerinin sağlıklı olduğunu garanti etmez. İnternet erişimini izlemek için ISP’nin ötesindeki bir hedefi yoklayan IP SLA, NQA ya da link monitor gerekir. Hangi hedefin yoklanacağı ve yoklamanın birincil yoldan çıktığı ayrıca planlanmalıdır. Cisco örneği source-ip, FortiOS örneği srcintf ve gateway-ip kullanır.

Tasarım notu: Yedek ISP’ye geçiş yalnızca rotayı değiştirir. NAT kurallarının yedek ISP adresi için de tanımlı olması gerekir; Cisco’nun belgesi bunun için ayrı NAT kuralları gösterir. Güvenlik politikalarının yedek arayüzü kapsaması gerekir. Dış adres değiştiği için mevcut TCP oturumlarının kesintisiz sürmesi beklenmemelidir. Durumlu firewall’da oturumların nasıl tutulduğu Stateful Firewall ve Zone Tabanlı Politika yazısında.

Kendinizi deneyin

Alıştırma 1: Core’a yeni bir bina için VLAN 70 eklendi: SVI 10.1.70.1/24, ağ 10.1.70.0/24 core’da doğrudan bağlı. Firewall’da NAT ve güvenlik politikalarının bu ağı kapsadığını varsayın. VLAN 70’teki istemciler internete çıkamıyor; diğer VLAN’lar sorunsuz. Hangi rota, hangi cihazda eksik?

Cevap ve açıklama

Core’da eksik rota yok. 10.1.70.0/24 connected rotadır. İnternete giden trafik core’un default rotasıyla firewall’a gider.
Core’daki Null0 rotası bu ağı kapsamaz. 10.0.0.0/16, 10.0.0.0 ile 10.0.255.255 arasını kapsar. 10.1.70.0’ın ikinci okteti 1 olduğu için /16’nın dışındadır. Core’da 10.1.70.0/24 connected ve daha uzun bir önek olduğu için de bu VLAN’a giden paketler zaten connected rotayı kullanır.
Eksik olan firewall’un dönüş rotasıdır. Firewall’ın 10.0.0.0/16 rotası 10.1.70.0/24’ü kapsamaz. Firewall bu ağı bilmediği için ona giden yanıtları core’a değil, kendi default rotasıyla ISP’ye gönderir.
FortiGate’te durum daha erken görünür: FortiOS’un varsayılan RPF kontrolü, paketin geldiği arayüzden kaynağa dönen en az bir rota arar. Rota yoksa paket daha ilk adımda düşürülür.
Çözüm: Firewall’da 10.1.70.0/24 → 10.0.254.1. Bina ilerde büyüyecekse 10.1.0.0/16 gibi bir özet de yazılabilir. O durumda core’a 10.1.0.0/16 için ayrı bir Null0 rotası eklemek, routing tablosu yazısındaki döngü riskini bu blok için de kapatır.

Alıştırma 2: Firewall’da birincil default rota 203.0.113.2’ye, yedek default rota daha yüksek AD ile 198.51.100.2’ye yazılmış. İzleme yapılandırılmamış. Birincil ISP’nin modemi ve firewall’un wan1 arayüzü ayakta, 203.0.113.2’ye ping de yanıt veriyor; ama internete erişim yok. Yedek rota neden devreye girmez, hangi izleme yöntemi bu durumu yakalar?