ip ospf mtu-ignore

Bu yazımda, MTU, dot1.q tunneling ve kısa bir bölümde ospf konularına değinip sizlere bu 3 konunun birleşimi bir durumdan bahsetmek istedim. Öncelikle 3 farklı şekilde bulunan MTU komutlarının ne işlere yaradığından bahsetmekle başlamak doğru olacaktır.
1) İnterface config modunda MTU komuduyla hardware olarak interface’in MTU size’i belirlenir.
2) Interface config modundaki ip mtu komuduyla ise ip packet’nin belirlenen interface üzerindeki MTU size’ini belirler.
3) Son olarak yine interface config modunda mpls mtu komuduyla, o interface’deki mpls pakedinin size’ini belirler.

Bu konuyla ilgili ufak bir hatırlatma olarak ise, ip veya mpls mtu size belirlenirken hardware olarak belirlenen yada default olan mtu size’ına eşit ya da daha küçük değerler atanabilmektedir. Aksi takdirde aşağıdaki şekildeki gibi hata alınacaktır.

Setting the mpls mtu to xxxx on interface x/x, which is higher than the interface MTU
xxxx. This could lead to packet forwarding problems including packet drops.

You must set the MPLS MTU values equal to or lower than the interface MTU values.

802.1q tunneling hakkında kısa bir bilgilendirme yapmak gerekirse, layer 2 trafiğini tünellemekiçin kullanılan bir yöntemdir. Ayrıca defaultta bu tünelden CDP,VTP ve STP trafikleri akmaz, manuel olarak istenildiği zaman açılabilir. Ayrıca bizim bu konuyla ilgili asıl konumuz olan 802.1q frame yapısından kaynaklanan 4byte’lık metro tag’i ile birlikte sistem MTU boyutu en az 1504 olarak tanımlanmalıdır.

kaynak: Cisco.com

Ospf’de komşuluk stateleri kısaca bir hatırlayalım:

  • Down
  • Attempt – Used for manually configured neighbors on an NBMA link; unicast hellos sent to neighbor from which hellos have stopped being received
  • Init – Hello packet received from neighbor, but without the recipient’s router ID
  • 2-Way – Bi-directional communication has been established
  • Exstart – The DR and BDR have been elected, link-state exchange starting
  • Exchange – Exchange of database descriptor (DBD) packets
  • Loading – Exchange of link-state information
  • Full – Full adjacency established

Bu noktada, şöyle bir sorunla karşılaşılması olası ki o da şudur. Farzedelim ki ospf konuşan bir router’ınız var ve karşı tarafta yine osfp konuşan başka bir vendor L3 cihaz var. debug ip packet ve debug ip ospf adj debuglarımız açık ve aldığımız çıktılar aşağıdaki gibidir.

router-1# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.0.2      1   EXCHANGE/  -    00:00:36    10.0.0.2    Serial0.2
 router-2# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.0.1      1   EXSTART/  -     00:00:33    10.0.0.1    Serial0.1

Router 1 debug output:

***Router1 komşuluk başlatacak hello paketi gönderiyor fakat cevap almıyor. Etrafta komşu yoktur deyip komşuluğu down state alıyor.

00:03:53: OSPF: 10.0.0.2 address 10.0.0.2 on

Serial0.2 is dead

00:03:53: OSPF: 10.0.0.2 address 10.0.0.2 on

Serial0.2 is dead, state DOWN

Router 2 debug output:

Ospf process’i router2’de henüz başlamadı.

Router 1 debug output:

***Router1 hello pakedi gönderiyor.

00:03:53: IP: s=10.0.0.1 (local), d=224.0.0.5

(Serial0.2), len 64, sending broad/multicast, proto=89

00:04:03: IP: s=10.0.0.1 (local), d=224.0.0.5

(Serial0.2), Len 64, sending broad/multicast, proto=89

Router 2 debug output:

Ospf process’i router2’de hala başlamadı.

Router 2 debug output:

***Router2’de Ospf process’i başladı, ilk heyecanla o da hello paketini gönderiyor 🙂 Router LSA oluşmaya başladı.

00:17:44: IP: s=10.0.0.2 (local), d=224.0.0.5

(Serial0.1), Len 64, sending broad/multicast, proto=89

00:17:44: OSPF: Build router LSA for area 0,

router ID 10.0.0.2, seq 0x80000001

Router 1 debug output:

***Router1 hello pakedini aldı. Artık biraz daha yakınlaşma zamanı 🙂

00:04:04: IP: s=10.0.0.2 (Serial0.2), d=224.0.0.5,

Len 64, rcvd 0, proto=89

00:04:04: OSPF: Rcv hello from 10.0.0.2 area 0 from

Serial0.2 10.0.0.2

00:04:04: OSPF: End of hello processing

Router 1 debug output:

***Router1’de medeni bir şekilde Router2’nin Router-ID bilgisiyle hello paketini gönderdi.

00:04:13: IP: s=10.0.0.1 (local), d=224.0.0.5

(Serial0.2), Len 68, sending broad/multicast, proto=89

Router 2 debug output:

***Router2 gelen bu hello pakediyle beraber, bu helloların hayra alamet olmadığını düşünerek state’ini değiştirerek 2WAY konumuna aldı.

00:17:53: IP: s=10.0.0.1 (Serial0.1), d=224.0.0.5,

Len 68, rcvd 0, proto=89

00:17:53: OSPF: Rcv hello from 10.0.0.1 area 0 from

Serial0.1 10.0.0.1

00:17:53: OSPF: 2 Way Communication to 10.0.0.1 on

Serial0.1, state 2WAY

Router 2 debug output:

***Router2 databaselerini syncronize yapabilmek için bir ön hazırlı olarak 0x13FD sequence numarasıyla DBD paketini yollar.

00:17:53: OSPF: Send DBD to 10.0.0.1 on Serial0.1

seq 0x13FD opt 0x2 flag 0x7 Len 32

00:17:53: IP: s=10.0.0.2 (local), d=224.0.0.5

(Serial0.1), Len 52, sending broad/multicast, proto=89

00:17:53: OSPF: End of hello processing

Router 1 debug output:

***Router2’den gelen DBD paketini alır almaz, artık Router1’in de içinde birşeyler uyanmıştır ve o da altta kalmayarak statetini 2WAY olarak değiştirir.

00:04:13: IP: s=10.0.0.2 (Serial0.2), d=224.0.0.5,

Len 52, rcvd 0, proto=89

00:04:13: OSPF: Rcv DBD from 10.0.0.2 on Serial0.2

seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state INIT

00:04:13: OSPF: 2 Way Communication to 10.0.0.2 on

Serial0.2, state 2WAY

Router 1 debug output:

***Artık iş bir anlamda biraz daha karışıyor, baskın olanın rolünün belirlenmesine sıra geldi. Bunun belirlenebilmesi için de Router1, Router2’nin yaptığı şekilde DBD paketini Router2’ye yollar.(DBD paketini içindeki router-id listesi baz alınarak master-slave seçimi yapılır) Bu sayede uzlaşmaya varılacaktır. Ve bu anlaşma sonunda Router1 slave olarak devam edecektir.

00:04:13: OSPF: Send DBD to 10.0.0.2 on Serial0.2

seq 0xE44 opt 0x2 flag 0x7 Len 32

00:04:13: IP: s=10.0.0.1 (local), d=224.0.0.5

(Serial0.2), Len 52, sending broad/multicast, proto=89

00:04:13: OSPF: NBR Negotiation Done. We are the SLAVE

Router 2 debug output:

***Router2, Router1’den gelen DBD paketini incelerken büyük bir hayal kırıklığına uğramaktadır. Paketi en ince ayrıntısıyla incelerken MTU boyutlarının birbiriyle uyuşmadığını farkeder. Bu esnada state’ini çoktan Router1’in slave seçilmesiyle EXSTART olarak değiştirmiştir.

00:17:53: IP: s=10.0.0.1 (Serial0.1), d=224.0.0.5,

Len 52, rcvd 0, proto=89

00:17:53: OSPF: Rcv DBD from 10.0.0.1 on Serial0.1

seq 0xE44 opt 0x2 flag 0x7 Len 32 mtu 1500 state EXSTART

00:17:53: OSPF: Nbr 10.0.0.1 has larger interface MTU

Router 1 debug output:

***Buarada Router1 kendi DBD bilgilerini aynı sequence numarasıyla (0x13FD) Router2’ye göndermektedir.

00:04:13: OSPF: Send DBD to 10.0.0.2 on Serial0.2

seq 0x13FD opt 0x2 flag 0x2 Len 1472

00:04:13: IP: s=10.0.0.1 (local), d=224.0.0.5

(Serial0.2), Len 1492, sending broad/multicast, proto=89</p >

Router 2 debug output:

***Fakat Router2 hala hiç ACK alamamıştır.

RETRANSMIT

00:17:54: IP: s=10.0.0.2 (local), d=224.0.0.5

(Serial0.1), Len 68, sending broad/multicast, proto=89

00:18:03: OSPF: Send DBD to 10.0.0.1 on Serial0.1

seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF:

Retransmitting DBD to 10.0.0.1 on Serial0.1 [1]

Router1 inatla Router2’den aldığı DBD packetinin ACK’ini göndermek istemektedir.

00:04:13: IP: s=10.0.0.2 (Serial0.2), d=224.0.0.5,

Len 68, rcvd 0, proto=89

00:04:13: OSPF: Rcv hello from 10.0.0.2 area 0 from

Serial0.2 10.0.0.2

00:04:13: OSPF: End of hello processing

00:04:18: IP: s=10.0.0.2 (Serial0.2), d=224.0.0.5,

Len 52, rcvd 0, proto=89

00:04:18: OSPF: Rcv DBD from 10.0.0.2 on Serial0.2

seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE

00:04:18: OSPF: Send DBD to 10.0.0.2 on Serial0.2

seq 0x13FD opt 0x2 flag 0x2 Len 1472

00:04:18: IP: s=10.0.0.1 (local), d=224.0.0.5

(Serial0.2), Len 1492, sending broad/multicast, proto=89

00:04:23: IP: s=10.0.0.1 (local), d=224.0.0.5

(Serial0.2), Len 68, sending broad/multicast, proto=89

00:04:23: IP: s=10.0.0.2 (Serial0.2), d=224.0.0.5,

Len 52, rcvd 0, proto=89

00:04:23: OSPF: Rcv DBD from 10.0.0.2 on Serial0.2

seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE

Fakat Router 2 hala karşı taraftan bir ses alamamıştır. Çünkü Router1’in gönderdiği paket Router2’ye fazla gelmektedir(MTU size’ları eşit değildir). Router2, Router1’i gözünde çok büyükttüğünü düşünmektedir fakat yine de bir umut DBD pakedini karşı taraf hiç almamışçasına baştan sonsuza kadar göndermektedir.

0:17:58: IP: s=10.0.0.2 (local), d=224.0.0.5

(Serial0.1), Len 52, sending broad/multicast, proto=89

00:18:03: OSPF: Send DBD to 10.0.0.1 on Serial0.1

seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF:

Retransmitting DBD to 10.0.0.1 on Serial0.1 [2]

00:18:03: IP: s=10.0.0.2 (local), d=224.0.0.5

(Serial0.1), Len 52, sending broad/multicast, proto=89

00:18:03: IP: s=10.0.0.1 (Serial0.1), d=224.0.0.5,

Len 68, rcvd 0, proto=89

00:18:03: OSPF: Rcv hello from 10.0.0.1 area 0 from

Serial0.1 10.0.0.1

00:18:03: OSPF: End of hello processing

00:18:04: IP: s=10.0.0.2 (local), d=224.0.0.5

(Serial0.1), Len 68, sending broad/multicast,

proto=89

00:18:03: OSPF: Send DBD to 10.0.0.1 on Serial0.1

seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF:

Retransmitting DBD to 10.0.0.1 on Serial0.1 [3]

00:18:08: IP: s=10.0.0.2 (local), d=224.0.0.5

(Serial0.1), Len 52, sending broad/multicast, proto=89

Gerek farklı vendorlarda, gerekse farklı interface typelarında default MTU sizeları değişiklik göstermektedir. Bu da farklı vendorlar arasında kurulacak OSPF komşuluğunda oluşabilecek sorunlardan biri olarak MTU size’larının uyuşmaması (üstteki debug çıktılarından da gözüktüğü üzere) gösterilebilir. Aşağıdaki tabloda örnek olarak default MTU boyutları M5, M7i, M10, M10i, M20, and M40 Juniper Routerlar için listelenmiştir. Bildiğim kadarıyla Cisco’da defaultta tüm interfacelerde MTU size 1500’dür.

Buna çözüm olarak ise; Cisco IOS Software 12.01(3) ile gelen “ip ospf mtu-ignore” komutu gösterilmektedir. Bu sayede Ospf komşuluğu başlatılırken gerekli olan MTU size eşitliliği zorunluğundan kurtulmuş olacaksınız.

Router1(config-if)#interface fa 0/0

Router1(config-if)# ip ospf mtu-ignore

Bazı sorunları görmezden gelme her zaman bukadar kolay olmayabilir, keyfini çıkarın 🙂

Uygulamaların Bantgenişliğini Yönetmek – İnce Ayarlar

6 ay sonra yeniden

Bloğun arama kısmına ismimi yazdığımda en son yazımın 6 ay öncesinde olduğunu gördüm. Evet utandırıcı birşey olsa da işlerin yoğunluğundan yazamıyoruz tesellisi ile avutuyoruz kendimizi. İşler her zaman yoğun oldu ve olacak, önemli olan hayatımızdaki şeylerin önceliklerini belirlemek diyerek yazıya giriyorum, konu ile bağlantı kurarak 🙂 21. yüzyılda, günlük hayatta ve kısıtlı bantgenişliğimizde onca şeyin arasında bir önceliklendirme yapmak şart oldu.

Bu yazımda Akademik Bilişim 2012 UŞAK’ta da bantgenişliği yönetim tecrübelerimizi paylaşmak adına Gökhan ile birlikte hazırladığımız sunumun AGCIYIZcasını sizlerle olcak. AGCIYIZcadan kastım daha rahat, biraz daha samimi.

Sizinki kaç Mbit? Bizimki 1000 Mbit ama…

Malumunuz günlük mesaimizin bir bölümünü 1000 Mbps’ya varan bir internet erişimini binlerce kullanıcımıza en iyi şekilde sunmak için harcıyoruz. Bazıları bulmuşun 1 gigabit interneti kafan rahat diye düşünebilir. Aslına bakarsanız bu yazıda bunun tam tersi hakkında birşeyler yazacağım.

Gelecek farklı tepkileri önlemek adına söylemek isterim ki Türkiye’deki diğer tüm devlet Üniversite’leri gibi İTÜ’nün servis sağlayıcısı da ULAKNET. ULAKNET, erişim hizmetlerini üniversitelerden herhangi bir ücret almadan veriyor. Ankara, İstanbul ve İzmir’de POP noktaları var, bunların biri de İTÜ’de. Bu da ULAKNET’e bağlanmak için tek ihtiyacımız olan 25-30 dolarlık 20 metre fiber patch kablo olduğu anlamına geliyor. Yani ULAKNET’e erişmek için Türk Telekom’a ödenmesi gereken aylık binlerce liralık bir ücret yok.

Bakarsan bağ bakmazsan dağ olur!

 

Zamanın gençleri atasözlerinden değil facebook applicationlarından mesajları kapıyor, farmville fazlasıyla başlıktaki anafikri aşılamıştır diye düşünüyorum. İnternet içeriği dolayısı ile internet trafiği nereden nereye geldi. 2000’lerin başında internete bağlanırken tüm ev halkına haber veren dial-up ve metin/fotoğraf içeriği yerini Mbps internet bağlantılarına HD’sinden videolara bıraktı. Bundan 10 yıl kadar öncesinde standart internet kullanıcıları pek fazla trafik yaratmazken günümüzde standart internet kullanıcılarından korkmak gerek. Facebook/Youtube ve *dizi*.com müdavimleri bantgenişliğinizin tamamını kullanıyor olabilir. Bir de tüm indirdiklerini izleyemeye ömrü yetmeyecek olsa da Blu-ray’den vazgeçmeyen arşivciler de varsa tamamdır.

Son yıllara bir göz atarsak,

-Bundan 7-8 yıl öncesinde bantgenişliğinin büyük kısmını p2p uygulamaları kullanırken
-İlerleyen dönemde rapidshare’in başını çektiği direct download link (
ddl) siteleri öne çıktı
-Son yıllarda ise video(stream) önemli bir pay sahibi

Yazının başında bahsettiğim bantgenişliğini 12-13 bin aktif kullanıcının paylaştığını düşünürseniz gerekli önlemleri almadıkça kafanızın rahat olmasını bırakın kafanızın şikayetlerden şişmesi kaçınılmazdır.İşini severek en iyi şekilde yapmaya çalışan ağcılar olarak aldığımız gerekli önlemleri biraz açalım. Hiç bir zaman şu içeriği yasaklayalım, kim ne yapıyor izleyelimle işimiz olmaz. Amaç kısıtlı kaynakları herkese adil olarak paylaştırmak. Yani tutup da tüm bantgenişliğini kendisi kullanmak için her yola başvuran bir kullanıcıya karşı diğer kullanıcıların erişim haklarını korumak amaçlı dur demek gerekebiliyor.

Trafik Işıkları

Kimse trafik ışıklarını sevmez ama onlara mecburuz çünkü çarpışan arabalar sadece lunaparkta hoşumuza gider 🙂 Şaka bir yana internet trafiğinizi yönetmezseniz ciddi paket kayıpları, gecikmeler ve hassas uygulamalarınızda performans kayıpları ile karşı karşıya kalabilirsiniz. Hassas uygulamalar ve kritik trafiğiniz için karayollarında acil durumlarda kullanılması için ayrılan emniyet şeridi tarzı birşeye ihtiyacınız olabilir. Ama gelelim ki uyanık sürücüler sağolsunlar karayollarımızda emniyet şeritlerini özellikle ihtiyaç duyulan anlarda tıkarlar. Agresif uygulamalar(bittorrent, limewire, flashget vs.) karayollarında emniyet şeridini tıkayan uyanık sürücüler formunda paralel oturumlar açarak bantgenişliğini doldurabilirler. Facebook üzerinden ya da Youtube stream trafiğini de yabana atmamak gerek.

Bir şekilde birşeyler yapmalı ve kısıtlı, ortak kullanılan bir kaynak olan internet erişimini en verimli bir şekilde kullanıcılara paylaştırmalı. Aslına bakarsanız seneler boyunca pek çok şey denedik ve proxy cache gibi zamanında işimizi gören çözümler şimdilerde işe yaramaz hale geldi. En büyük nedeni internet kullanımının yaygınlaşması ile içeriğin akıl almayacak şekilde çeşitlenmesi. Ah o yıllar öncesindeki HIT oranlarını dersem eski proxy yöneticileri beni anlar 🙂 Birçoğu ise bizim gibi proxy kullanımını bırakmıştır bile. Bir de eskiden yönlendiricilerde 80. port için önceliklendirme yapılırdı. Bugün baktığımızda 80. portu kullanmayan uygulama bulmak zor. Bizim yönettiğimiz ağ için rahatlıkla söyleyebilirim ki tüm internet trafiğinin %90’ı 80. portu kullanıyor. Tabi bu trafiğin %90’ı HTTP trafiği anlamına gelmiyor 🙂 Merak edenler için en çok kullanılan uygulamalara gelirsek video streaming, kontrollü bir şekilde! p2p ve ddl, http şeklinde sıralanıyorlar. Kontrollü P2P ve ddl’i bantgenişliği politikalarında biraz daha açacağım.

Tecrübeler ve Öneriler

itü’de nerden nereye
100 – internet içeriği daha çok resim, 1-2 seneye heryer video olacak. p2p 1 numara, ddl yeni doğuyor.

kullanılan çözümler, proxy (squid) WCCP protokolü, content engine (100Mbps),

gündüz p2p kapalı, ipp2p iptables module olarak kesiyorduk, saat 07:00-22:00 arası taviz yok. Encrypted kaçmaya başladık, daha sonra protokol yapısı değişti ve ddl karşımıza çıktı. rapidshare, öncülerden 🙂
– yama çözüm bize yük, o zamanlar delikanlılık işte 2-3 gencaver olarak koca bir ordu karşısında savaşıyorduk, politikalarda yazan 3072MB geçemez kuralının uygulayıcısı olmaya çabalıyorduk, 1 hafta internet kapatma cezası. Kavga kıyamet, sınavım/ödevim var!
TEKNİK: Kullanıcıların netflow ve proxy kullandığımız zamanlarda webalizer kullanıyorduk.

Bantgenişliği yönetimi önerileri

Trafik analizi sonrasında kritik ağ trafiği için gerekli önlemler alınmalıdır.
Kullanım yoğunluğuna göre farklı zaman aralıkları için farklı politikalar belirlenmelidir.
p2p ve dll trafiği için toplam üst limit belirlenebilir.
p2p trafiği upload sınırı çok düşük tutulmalıdır.
Kütüphane okur bilgisayarları gibi kayn
ak arama amaçlı sistemler için izin verilen trafik dışındaki uygulamalara erişim kapatılabilir.

Yerleşke bağlantıları gibi kısıtlı bantgenişliğine sahip ağlar için;
Kurum içi kritik merkezi ağ servislerine öncelik tanımlanabilir.
Uzaktan eğitim, Kimlik denetimi vs.
Mesai saatlerinde p2p ve ddl kapatılabilir/üst limit belirlenebilir
Belirli uygulamalar için kota uygulaması ile yerleşke bantgenişliğinin kullanıcılar arasında adil paylaştırılması sağlanabilir.
Kullanıcı bazlı bantgenişliği sınırlaması yapılabilir.

Özet

Yüksek bantgenişliklerinde dahi bantgenişliği yönetimine ihtiyaç duyulmaktadır.

Yerleşkeler kısıtlı bantgenişliklerine sahip olduklarından, kritik trafiğin önceliklendirilmesi ve kullanıcı bazlı bantgenişliği sınırlaması yapılması uygun olacaktır.

Kısıtlı ağ kaynakları söz konusu ise kota uygulamaları adil bir paylaşım sağlayabilir.