EIGRP Authentication

Merhabalar. Sizlere bu yazımda, Cisco’nun gözde dinamik routing protokolü olan EIGRP için kimlik doğrulama mekanizmasından ve konfigürasyonundan bahsedeceğim.

EIGRP kimlik doğrulamasında bilinmesi gereken iki temel nokta bulunmakta. Bunlardan ilki, kimlik doğrulamanın, EIGRP komşuluğu kurulmuş olan her link ve otonom sistem (AS) için ayrı ayrı ayarlandığıdır. Yani router üzerinde bir AS için komşuluk oluşturulan interface’lerin her birinde ayrı kimlik doğrulama kuralları belirtilebildiği gibi, bir interface’te de dâhil olunan networkün katıldığı her AS için ayrı ayarlama yapılır. İkinci ve en önemli nokta ise EIGRP kimlik doğrulamasının zamana bağlı bir sistem olduğunun unutulmamasıdır. Bu konunun öneminden yazının ilerleyen kısmında bahsedeceğim.

Okumaya devam et “EIGRP Authentication”

Generic Routing Encapsulation

Merhaba,
Yazımda GRE (Generic Routing Encapsulation) protokolünün çalışma şeklinden, faydalarından ve konfigürasyonundan bahsedeceğim. Bu yazının benim için bir ilk olmasından dolayı yaşadığım heyecan ve tecrübesizlik umarım yazıma da yansımaz 🙂

GRE bir kapsülleme protokolü olarak çalışır. GRE, üzerine IP başlığı eklenip IP paketi haline gelmiş veriyi kapsüller ve üzerine yeni bir IP başlığı ekler. Yeni eklenen IP başlığında ise paketin gideceği hedefin IP adresi bulunmaz. Onun yerine GRE tünelinin uç IP adresleri bulunur. Üçüncü katmanda çalışan cihazlar bu paketi yönlendirirken kapsülün dışındaki Okumaya devam et “Generic Routing Encapsulation”

EIGRP-1

EIGRP, Cisco tarafından IGRP protokolünün yetersiz kalmaya başlamasıyla geliştirilmiştir. Tamamı Cisco cihazlardan oluşan topolojilerde çok verimli olarak kullanılabilir. Bu protokol aynı anda Uzaklık Vektörü ve Hat Durumu protokollerinin özelliklerine sahip olduğu için Hybrid (Melez) olarak da adlandırılmaktadır. Okumaya devam et “EIGRP-1”

IOS Caching Name Server & DNS Spoofing

Merhaba,

Cisco router’lar istemcilere, DNS sunucularından öğrendikleri içerikleri önbelleğe alarak hizmet verebilirler. Bu özellik Caching Name Server olarak geçer. Biraz açıklayacak olursak:

Bilindiği gibi bir istemci ulaşmak istediği network ismine paket göndereceğinde önce yollayacağı network ismine ait network adresini öğrenmelidir. Bunu öğrenmek için DNS sunucularına başvurur. DNS sunucuları bahsettiğimiz network adreslerini ve network isimlerinin eşleşmesinden oluşan listeyi bulunduran sunuculardır. İstemci bu sunuculardan aldığı bilgiye göre paketinin hedef adresini belirlemiş olur.
Okumaya devam et “IOS Caching Name Server & DNS Spoofing”

VRRP (Virtual Router Redundancy Protocol)

Merhabalar, bu yazımda router yedeklilik protokollerinden VRRP’yi anlatmaya ve örnek bir topoloji üzerinde temel VRRP komutlarını kullanarak yedekli bir yapının nasıl oluşturulabileceğini göstermeye çalışacağım. Öncelikle VRRP’yi ve özelliklerini kısaca açıklamakta fayda var.

VRRP, IEEE standardında bir yönlendirici yedekliliği protokolüdür. VRRP, HSRP (Hot Standby Router Protocol)’ de olduğu gibi birden çok yönlendirici (router)’nin tek bir sanal yönlendirici (virtual router) gibi davranmasına imkan sağlar. Okumaya devam et “VRRP (Virtual Router Redundancy Protocol)”

BGP Aggregation (Summary-Only, Suppress-Map, Unsuppress-Map, AS-Set)

Uzun zaman oldu yazmayalı. İş güç derken yazmaya fırsat bulamadım, ama Ağcıyız’ın
yıldönümüne yetiştirebildim 🙂  Bu yazıda BGP Aggregation nasıl yapılır, ne gibi özellikleri vardır, nasıl farklılaştırılabilir bunlardan bahsedeceğim.

Aggregation toplama,bütünleme anlamına gelir. Dolayısıyla BGP Aggregation da networklerin özetlenmesi diyebiliriz. IGP protokollerinden bildiğimiz summary işlemidir aslına bakılırsa. Aggregation konusunu aşağıda çizdiğim basit iBGP
topolojisi üzerinden Okumaya devam et “BGP Aggregation (Summary-Only, Suppress-Map, Unsuppress-Map, AS-Set)”

RIP v1, v2 ve Offset-list

Merhaba, bu yazımda sizlere dinamik routing protokolü olan RIPv1 ve RIPv2 arasındaki farkları anlatmaya çalışacağım ve offset-list kavramına değineceğim. Routing, router’ın gelen paketleri belirli algoritma hesapları ile en iyi yolu bularak yönlendirmesi işlemidir. İki çeşit routing vardır: Static routing ve Dinamik routing. Static routing elle yapılan routing’dir ve ip route komutu ile yapılır. Dinamik routing ise protokoller vasıtasıyla yapılır. Dinamik routing protokolleri iki çeşittir: Link State Routing ve Distance Vector Routing protokolleri. RIP bir distance vector routing protokolüdür. Distance vector (Bellman-Ford) algoritması kullanır.

RIP metric olarak hop sayısını kullanan bir distance vector protokolüdür. 2 versiyon olarak geliştirilmiştir. UDP 520 numaralı portu kullanır ve administrative distance ı 120’dir. Maksimum hop sayısı 15’tir. RIP kullanan router’lar tüm topolojiyi bilmezler. Okumaya devam et “RIP v1, v2 ve Offset-list”

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 🙂

Wild Card Mask

Merhaba

Router’larla biraz uğraşan herkes Wild Card Mask terimini duymuştur. Dinamik routing’de ve access-list’lerde Subnet Mask’e benzer bir kullanımla karşımıza çıkar. İlk bakışta Subnet Mask varken niye böyle başka bir tanıma ihtiyaç duyulmuş diye düşünülebilir. Gerçekten de matematiksel olarak tatminkar bir açıklamasını ben de bulamadım 🙂 Ama Wild Card Mask kullandığımız konfigürasyonlarda ardışık olmayan alt ağları ve istemcileri tek bir satırda ifade edebilme gibi bir yeteneğe sahip oluyoruz. Bu mekanizmayı anlamak için bu yazıda Wild Card Mask’in ne anlama geldiğini daha detaylı inceleyip çeşitli örnekler vereceğim.
Okumaya devam et “Wild Card Mask”