Home

EIGRP Metrics (In-Depth about metric calculation in EIGRP)

Leave a comment

EIGRP punya 4 metric (ya, lo ga sala baca)

Bandwidth, Delay, Reliability, dan Load

Metric ke-5 disebut MTU (maximum transmission unit) yang TIDAK DIKALKULASIKAN SAMA SEKALI

Trus gunanya apa?? Ini untuk ngecek seberapa besar paket EIGRP yang bisa dikirim TANPA harus di-fragment disebuah interface (the concept of MTU)

================================

Kali ini kita pake gambar diatas

Untuk bisa adjacency di EIGRP, salah satu factor-nya adalah K-Values (itu tuh…K1 K2 K3 K4 K5), jika di masing2 router beda K-Values nya maka adjacency tidak akan terbentuk

Contoh diatas: R1 (1 0 1 0 0) dan R2 yang berbeda (1 0 1 0 1)

K-Value digunakan untuk kalkulasi metric modifier, yang utama dikalkulasikan adalah bandwidth dan delay

Nah, sekarang kita liat K-Values

K1 = Bandwidth Modifier
K2 = Load Modifier
K3 = Delay Modifier
K4 = Reliability Modifier
K5 = Additional Reliability Modifier

What ?!? K5 bukan MTU
?!? bukan (according Scott Morris and other CCIE’s)

1 = diitung, 0 = ga diitung…artinya hanya K-Value tertentu aja yang di kalkulasikan (liat deh…yang angka “1” Cuma K1-bandwidth dan K3-delay)

Jadi ga penting metric value nya buat adjaceny…yang penting CARA NGITUNG metric nya yang harus sama

Analoginya kek gini:

ga penting lo kerumah gw pake kuda, pake jet, ato pake motor (analogi metric value), yang penting lo MANUSIA, masih ngetok pintu rumah gw dulu (hello packet with same K-value)…wkwkw sory, ga temenan ama MALING apalagi SETAN !!

Another mention:

Pas lo input “metric weight [tos]” pasti ada yang namanya…apaan ini tos?!?

*engga ah man…gw ga nanya…..

ToS (Type of Service, QoS Related Field) = default 0 (dan hanya bisa 0), artinya disini EIGRP (dan OSPF) ga support skala prioritas ToS (semakin tinggi angkanya…packet nya semakin di prioritaskan)

ToS ini ga di-include dalam metric calculation, trus kenapa ada disini?! Beberapa orang memang menyarankan agar routing protocol ada ToS nya, mungkin buat future use (mungkin)

=======================================

How they calculate it (the metric) ?!?

According to default K-Value…wait…bahasa Indonesia lagi dah…

Yang diitung hanya bandwidth dan delay
only, let’s see the formula

Metric = 256*((K1*Bw) + (K2*Bw)/(256-Load) + (K3*Delay)*(K5/(Reliability + K4)))

Pusing?! sama…gw juga…wkwkwk

Klo metric value nya sama dengan “1 0 1 0 0”

Berarti K1 & K3 sama dengan 1 sedangkan K2,K4, dan K5 sama dengan 0 (liat yang digaris bawah)…

berdasarkan rumus matematika klo Nol(0) dikali APAPUN tetep aja NOL…so, yang kepake memang bandwidth dan delay aja

Kenapa bisa dapet 156160??

R1 jalan ke 2.2.2.2 (ip loopback R2) itu lewat 2 interface…pertama fastEthernet ke R2…kedua ya loopbacknya R2

EIGRP milih bandwidth yang paling kecil
diantara link yang dilewati oleh R1 ke 2.2.2.2 (yang ada di R2)

Nah…yang paling kecil adalah fa0/0 yang kearas R2

Rumus bandwidth = (10^7/the lowest bandwidth in kbps)*256 = (10000000/100000)*256 = 25600

Sedangkan delay…masing2 delay interface akan dijumlahkan semua lalu dibagi 10(*256)

(FastEthernet delay R1 dan R2 + loopback delay R2)/10*256 = (100+5000)/10*256 = 130560

Rumus delay = (n+n+n+n)/10*256…where “n” is delay, “n” counts depends on how much interface the packet travels

Metric = bandwidth + delay = 256000 + 153600 = 156160

Kesimpulannya adalah…(pake router laen dah…)

Trus gimana dengan Load dan Reliability…dulu ini value memang diciptakan untuk IGRP (protocol sebelum EIGRP)

Untuk memudahkan integrasi IGRP ke EIGRP….jadi, mending ga usa dibahas *ngeles* wkwkwk

OSPF “too many retransmissions”

1 Comment

Ada kasus menarik ketika gw mencoba implementasi OSPF routing di Multilayer Switch (SW3560 & SW3550)

Awalnya memang ada tulisan OSPF “LOADING to FULL

Tapi setelah beberapa detik jadi kek gini:

Ada kata2 “EXSTART to DOWN, Neighbor Down: Too many retransmissions

Jadi itu 2 multilayer switch gak mau saling adjacency/ga mau jadi neighbor (statusnya ketika show ip ospf neighbor selalu exstart…trus down)

Setelah tak ubek2 ternyata:

Ketika 2 buah neighbor yang memakai OSPF saling tuker (exchange) OSPF DBD (database description), mereka juga ngirim MTU (maximum transmission unit) masing2 (informasi MTU nya ada di DBD packet)…

Nah…value dari MTU ini HARUS MATCH ketika OSPF exchange states, klo tidak sama…akibatnya ya kayak diatas itu

=======================

Kenapa bisa begitu (harus match…)??

Kalau sebuah device ngirim JUMBO FRAME (yang MTU nya bisa lebih dari 1500, biasanya GigabitEthernet interface) sedangkan device penerima tidak support itu JUMBO FRAME (MTU max. 1500), maka itu frame akan di drop

Secara teori…MTU ga match ga masalah…yang jadi masalah klo kebesaran…

The outgoing packets, including OSPF packets cannot have a bigger size than the interface MTU” RFC 2328

kenapa MTU ini harus match?? karena untuk optimasi OSPF itu sendiri…

karena default behavior OSPF itu kira2 seperti ini:

ketika sebuah router “kenalan” dengan tetangganya…dia akan ngasih tau tetangganya tentang informasi teman2/tetangga2 yang dipunyain router itu…celakanya, biasanya SEMUANYA dikasih tau (ibarat kata…OSPF itu kek ibu2…klo dikasi kesempatan ngomong…nyerocos terus ga udah2, gossip sana-gosip ini tentang tetangga2nya)…inilah yang bisa menyebabkan “excessive flooding”

=======================

Solusinya…

Pertama…”ip ospf mtu-ignore” di interface yang bersangkutan

Ini artinya kita ignore MTU exchange…untuk LAB sih ok2 aja, soalnya ignore/cuekin MTU…bukan NYELESEIN MASALAH (tetep aja kirim MTU jumbo-jumbo ga jelas)

Kedua…”system mtu routing [value MTU]” di global config

Samain MTU…tapi sebelumnya cek dulu pake “show system mtu” di kedua belah pihak, yang mana yang ngaco

Ini nih biang recok…ada switch yang MTU nya 1512 (yang normalnya 1500, ternyata setelah gw selidiki SW3550 memang Cuma bisa nerima 1500 MTU, switch lama sih emang)

 

REFERENCE:

RFC 2328

BRIAN McGAHAN

Older Entries Newer Entries