IRR ve AS-SET kayıtlarınızı neden güncel tutmalısınız?

BGP oturumu kurulduğunda karşı tarafın sizden hangi prefix’leri kabul edeceğine router karar vermez; o kararı çoğu zaman günler önce, Internet Routing Registry (IRR) kayıtlarınızdan otomatik üretilmiş bir filtre verir. Kayıtlarınız doğruysa bu süreç görünmezdir. Eksik ya da eskiyse, yeni bir prefix duyurduğunuzda bir kısım ağın size neden ulaşamadığını saatlerce aramanız gerekebilir.

IRR nedir, ne işe yarar?

IRR, hangi ağın hangi prefix’leri duyurmaya yetkili olduğunu ve ağlar arasındaki ilişkileri RPSL (Routing Policy Specification Language) formatında tutan veritabanlarının genel adıdır. RIPE, ARIN, APNIC gibi bölgesel kayıt kuruluşlarının veritabanları ve RADB gibi bağımsız veritabanları bu sistemin parçasıdır.

Upstream sağlayıcılar, IX route server’ları ve peering ortakları, komşularından gelen duyuruları filtrelemek için bu kayıtları kullanır. Bu yüzden IRR, pratikte bir “beyaz liste” işlevi görür.

route ve route6 nesneleri

En temel nesne, bir prefix’i onu duyuracak ASN ile eşleyen route (IPv4) ve route6 (IPv6) nesneleridir:

route:          203.0.113.0/24
descr:          Ornek Ag - sunucu blogu
origin:         AS64500
mnt-by:         ORNEK-MNT
source:         RIPE

route6:         2001:db8:4000::/48
descr:          Ornek Ag - IPv6
origin:         AS64500
mnt-by:         ORNEK-MNT
source:         RIPE

Dikkat edilmesi gereken noktalar:

• Duyurduğunuz her prefix için nesne olmalı. Elinizde 198.51.100.0/22 varsa ve trafik mühendisliği için iki ayrı /23 duyuruyorsanız, filtreleri tam eşleşmeyle üreten bir komşu yalnızca /22 nesnesi gördüğünde /23’leri reddeder. Duyurduğunuz her uzunluk için ayrı nesne oluşturmak en güvenli yoldur.
• Origin doğru olmalı. Bir prefix’i başka bir ASN’den (ör. DDoS koruma sağlayıcısının ağından) duyurmanız gerekiyorsa, o ASN için de ayrı bir route nesnesi gerekir.
• Eski nesneleri silin. Artık kullanmadığınız ya da başka bir ağa devrettiğiniz prefix’ler için bırakılan nesneler, başkasının filtresinde gereksiz izinler oluşturur.

Kendi kayıtlarınızı kontrol etmek için:

whois -h whois.ripe.net -- '-i origin AS64500'
whois -h whois.radb.net '!gAS64500'
whois -h whois.radb.net '!6AS64500'

İkinci ve üçüncü komutlar, IRR kaynaklarından AS64500 origin’li tüm IPv4 ve IPv6 prefix’lerini tek satırda listeler.

AS-SET: müşteri konisinin tanımı

Tek bir ASN’niz varsa ve sadece kendi prefix’lerinizi duyuruyorsanız, komşunuz filtresini doğrudan ASN’nizden üretebilir. Ancak kendi arkanızda başka ağlar (müşteriler, grup şirketleri, ikinci bir ASN) varsa, komşunuzun bunları da bilmesi gerekir. Bunun için as-set nesnesi kullanılır:

as-set:         AS64500:AS-ORNEK
descr:          Ornek Ag musteri konisi
members:        AS64500
members:        AS64501
members:        AS64502:AS-MUSTERILER
mnt-by:         ORNEK-MNT
source:         RIPE

AS-SET’ler iç içe olabilir: AS64502:AS-MUSTERILER açıldığında onun üyeleri de filtreye dahil olur. Bu güçlü bir özelliktir ama iki riski vardır:

• Aşırı geniş set: Bir müşterinizin AS-SET’i yanlışlıkla bir upstream’inin tamamını içeriyorsa, sizin setiniz de dolaylı olarak on binlerce prefix’e izin verir. Filtre anlamını yitirir, route leak’lere kapı açar.
• Eksik üye: Yeni bir müşteri eklendiğinde AS-SET güncellenmezse, onun prefix’leri sizin komşularınızda filtrelenir.

AS64500:AS-ORNEK biçimindeki hiyerarşik isimler, setin hangi ASN’nin sahipliğinde olduğunu açıkça gösterir ve isim çakışmalarını önler. Netlojik’in AS-SET’i de bu biçimdedir: AS202294:AS-NETLOJIK. AS-SET’inizi PeeringDB kaydınızda da güncel tutun; birçok ağ ve IX, filtre üretirken bu alanı referans alır.

bgpq4 ile filtre üretimi

Komşularınızın sizin kayıtlarınızdan ne ürettiğini görmenin en kolay yolu, aynı aracı kendiniz çalıştırmaktır. bgpq4 bu iş için yaygın olarak kullanılır.

IPv4 prefix-list (Cisco/Arista biçimi):

bgpq4 -4 -A -l ORNEK-V4 AS64500:AS-ORNEK

no ip prefix-list ORNEK-V4
ip prefix-list ORNEK-V4 permit 198.51.100.0/22 le 23
ip prefix-list ORNEK-V4 permit 203.0.113.0/24

Burada -A bitişik prefix’leri özetler; le 23 satırı, IRR’da hem /22 hem /23 nesneleri bulunduğu için ortaya çıkmıştır.

IPv6 ve Junos biçimi:

bgpq4 -6 -J -l ORNEK-V6 AS64500:AS-ORNEK

AS-path filtresi için:

bgpq4 -f 64500 -l ORNEK-ASPATH AS64500:AS-ORNEK

Sorgulanan kaynakları sınırlamak için -S RIPE,RADB gibi bir parametre de verebilirsiniz. Komşunuzun hangi kaynakları kullandığını bilmiyorsanız sorun; bazı ağlar yalnızca RIR veritabanlarına güvenir.

Yeni bir prefix duyurmadan önce bu komutu çalıştırıp prefix’in çıktıda göründüğünden emin olmak, basit ama çok işe yarayan bir alışkanlıktır.

Eksik bir route nesnesinin etkisi

Tipik senaryo şöyle gelişir: Yeni bir /24 alınır, router’da yapılandırılır ve duyurulur. Kendi ağınızdan test edildiğinde her şey çalışıyor gibi görünür. Ancak route nesnesi oluşturulmadığı için:

• Filtrelerini IRR’dan üreten upstream’ler prefix’i kabul etmez.
• IX route server’ları duyuruyu reddeder.
• Filtre yapmayan ya da gevşek filtre uygulayan yollar üzerinden prefix bazı ağlara yine ulaşır.

Sonuç, kısmi erişilebilirliktir: bazı kullanıcılar sorunsuz bağlanırken bazıları hiç bağlanamaz. Bu tablo, arızayı teşhis etmeyi zorlaştırır. Route nesnesini oluşturmak da tek başına çözüm değildir: çoğu ağ filtrelerini periyodik olarak, örneğin günde bir ya da birkaç kez yeniler. Yeni kaydın etkisini görmek için bu döngünün tamamlanmasını beklemeniz gerekebilir. Bu yüzden route nesnesini duyurudan önce, tercihen bir gün önceden oluşturun.

Duyurunun gerçekten nereden görülüp nereden görülmediğini anlamak için farklı ağlardaki looking glass’lardan show route çıktısına bakmak en hızlı yöntemdir.

IRR ve RPKI birlikte

RPKI ROA’ları, prefix-origin eşleşmesini kriptografik olarak imzalar ve birçok ağda route origin validation ile birlikte kullanılır. Ancak IRR’ın yerini tamamen almaz: AS-SET gibi ilişki bilgileri RPKI’da yoktur ve birçok filtre hâlâ IRR’dan üretilir. Pratik öneri, ikisini de tutarlı tutmaktır: her route nesnesinin bir ROA karşılığı olsun, her ROA’nın da bir route nesnesi.

Kontrol listesi

• Duyurulan her prefix ve uzunluk için route/route6 nesnesi var mı?
• Origin ASN’ler doğru mu, eski nesneler temizlendi mi?
• AS-SET yalnızca gerçekten arkanızda olan ağları içeriyor mu?
• PeeringDB’deki AS-SET alanı güncel mi?
• bgpq4 çıktısı beklediğiniz prefix listesini veriyor mu?
• ROA’lar route nesneleriyle uyumlu mu?

IRR kayıtları, bir kez doğru kurulduğunda çok az bakım gerektirir. Asıl önemli olan, prefix ve müşteri değişikliklerinde güncellemeyi yönlendirme değişikliğinin ayrılmaz bir adımı haline getirmektir.