LINGKUNGAN PRAKTEK ROUTING

Author:

1. Sabriansyah R. Akbar, S.T., M.Eng., Ph.D

2. Achmad Basuki, S.T., M.MG., Ph.D

WINDOWS SUBSYSTEM FOR LINUX (WSL)

Para pengguna system operasi Windows seringkali dibuat rumit ketika dihadapkan pada lingkungan
aplikasi yang diwajibkan bekerja pada system operasi Linux. Secara umum, banyak pengguna yang
memanfaatkan teknologi virtualisasi untuk melakukan instalasi system operasi linux didalam sebuah OS
windows. Kelemahan memanfaatkan teknologi virtualisasi adalah adanya kelebihan penggunaan sumber daya
meskipun penggunaan aplikasi hanya membutuhkan konsumsi sumber daya yang sedikit.

Untuk menyiasati permasalahan tersebut, muncul teknologi Windows Subsystem for Linux yang dapat
menjalankan aplikasi-aplikasi binaries yang ada pada linux.

INSTALASI WSL

Instalasi WSL pada Windows dapat dilakukan via aplikasi power shell dengan mengetikkan perintah dibawah
ini. (Pastikan Internet Windows anda terhubung)

Gambar 1 Instalasi WSL melalui Windows PowerShell

Setelah WSL terinstall, kita dapat melakukan verifikasi dengan perintah:

wsl -l -v

Gambar 2 menunjukkan system operasi Ubuntu yang sudah terinstall didalam environment WSL. Jika distro
belum diinstall, maka isi perintah diatas hanya akan menampilkan entry yang kosong.
 Gambar 2. Hasil perintah wsl -l -v

INSTALASI DISTRO

Untuk melakukan instalasi distro, perintah yang digunakan adalah:

wsl --install -d <nama distro>

Contoh:

wsl --install ubuntu

wsl --install debian

Note: Untuk lingkungan kerja selanjutnya, kita akan menggunakan Ubuntu.

Gambar 3 Tampilan Setelah Kedua Distro Terinstall

PERUBAHAN VERSI WSL

WSL memiliki versi 1 dan 2 dengan fitur yang berbeda (WSL version 2 lebih lengkap). Secara default, WSL akan
melakukan instalasi versi 1, dan kita perlu untuk melakukan perubahan ke versi 2 dengan mengeksekusi
perintah dibawah ini:

wsl --set-default-version 2

MENJALANKAN DISTRO DI WSL

Setelah distro terinstall, kita dapat menjalankan distro tersebut dengan perintah:

wsl -d ubuntu

Gambar 4 Menjalankan Distro

 LINGKUNGAN PRAKTEK ROUTING
Author:

1. Sabriansyah R. Akbar, S.T., M.Eng., Ph.D

2. Achmad Basuki, S.T., M.MG., Ph.D

DOCKER DAN GIT

Untuk membangun topologi pada network, kita dapat memanfaatkan Docker yang dibangun dengan
teknologi container. Container (Error! Reference source not found.) adalah sebuah perangkat lunak, yang
membungkus perangkat lunak beserta dependencies-nya. Dibandingkan teknologi sebelumnya memanfaatkan
Virtual Machine (VM), teknologi container lebih ringan dan fleksibel, dalam mengelola bundling aplikasi dan
juga lingkungan pendukungnya. Salah satu aplikasi popular yang berbasis teknologi container adalah docker.

INSTALASI DOCKER

Sebelumnya, kita telah mempersiapkan Windows Sub System for Linux (WSL) yang akan digunakan sebagai
media untuk menginstall docker. Melalui Windows Power Shell, kita dapat masuk ke lingkungan WSL Ubuntu
dengan mengetikkan perintah dibawah ini:

wsl -d ubuntu

Gambar 0—1 Menjalankan Distro

Alternatif lain, kita bisa mengetikkan wsl dalam search windows, dan menjalankan wsl dari hasil search
windows. Gambar 0—1 menunjukkan bahwa kita telah masuk ke lingkungan WSL dengan distro Ubuntu.
Selanjutnya, kita akan melakukan instalasi docker via Internet melalui Ubuntu Advance Packing Tool (APT)
dengan perintah dibawah ini:

sudo apt-get install docker

Setelah proses instalasi selesai, pastikan bahwa daemon docker telah dijalankan dengan perintah:

sudo /etc/init.d/docker start

Ketikkan perintah dibawah ini untuk memastikan bahwa daemon docker telah aktif.

sudo docker run hello-world

Pada proses ini, Docker akan mengunduh image sebuah system dan aplikasi untuk menjalankan hello world.
Hasil eksekusi perintah diatas dapat dilihat pada Gambar 0—2, dimana gambar tersebut menunjukkan bahwa
proses instalasi, daemon docker, telah berjalan dan siap untuk dioperasikan.

Gambar 0—2 Hasil Eksekusi Hello Word Docker

CLONE REPOSITORY

Dari sini, kita akan mempersiapkan lingkungan jaringan yang akan kita kerjakan dengan mendownload dari
sebuah repository git. Dari: https://github.com/bhawiyuga/idren-workshop-2021/tree/main/routing Kita akan
menempatkan clone pada home direktori.
 sudo git clone https://github.com/bhawiyuga/idren-workshop-2021/tree/main/routing

Setelah proses git clone selesai, kita akan menjumpai folder “routing”. Isi dari folder tersebut adalah:

DOCKER-COMPOSE.YML
Pada docker container, terdapaat tool dengan nama compose yang digunakan untuk mendefinisikan dan
menjalankan satu atau lebih container. Dengan menggunakan compose kita dapat menggunakan file YAML
(umumnya menggunakan extension .yml) untuk melakukan konfigurasi pada sistem operasi dan juga layanan
yang terdapat pada container. Contoh file YAML ditunjukkan pada file yang ada di dalam folder routing. Kita
dapat melihat isi dari file docker-compose.yml yang ditunjukkan bagian awal adalah seperti dibawah ini.

version: '2.4' // Version ‘2.4’ menunjukkan versi jenis file format YAML
services: //mendefinisikan layanan
BR01: //nama hostname pada OS pertama
image: frrouting/frr:latest // jenis image yang digunakan menggunakan frrouting
hostname: BR01 //melakukan konfigurasi hostname
container_name: BR01 //melakukan konfigurasi container
sysctls: //melakukan konfigurasi pada sysctl linux
net.ipv6.conf.all.disable_ipv6: 0
net.ipv6.conf.all.forwarding: 1 // mengaktifkan routing ipv6
net.ipv4.ip_forward: 1 //mengaktifkan routing ipv4
privileged: true
volumes:
- ./config/BR01:/etc/frr //melakukan kopi konfigurasi dari folder config/BR01 → /etc/frr
- ./daemons:/etc/frr/daemons
- ./hosts:/etc/hosts
networks : //bagian konfigurasi network
interas0: //memberikan konfigurasi interface network dengan nama interface interas0
ipv4_address: "10.255.120.253" //konfigurasi IPv4
ipv6_address: "fc00:10:10:120::253" //konfigurasi IPv6
interas1:
ipv4_address: "10.255.100.254"
ipv6_address: "fc00:10:10:100::254"
router1:
ipv4_address: "10.255.0.14"
ipv6_address: "fc00:10:10::14"
router2:
ipv4_address: "10.255.0.22"
 ipv6_address: "fc00:10:10:20::22"

Disini BR0 adalah salah satu host yang akan kita buat menjadi sebuah router. Jika kita-amati di file docker-
compose.yml kita melihat banyak terdapat konfigurasi untuk host yang lain. Yaitu: BR0, BR1, BR2, BR3, R1, R2,
R3, R4, R5, R6, C1, C2, C5, C6, C9, C10.

FOLDER CONFIG
Didalam folder routing juga terdapat folder CONFIG yang digunakan untuk menyimpan konfigurasi yang akan
dieksekusi pada file docker-compose.yml. Folder tersebut berisi file konfigurasi untuk tiap-tiap hostname yang
dijadikan router maupun klien. Secara default isi dari masing-masing folder host dalam folder config ini masih
kosong.

ARCHIEVED FILE .TAR.GZ

File tersebut merupakan archieved file dari file untuk konfigurasi yang terdapat pada folder routing/config. file
archieved ini terdiri dari 3 buah files skenario yaitu:

1. mf-ospf-singlearea.tar.gz → file konfigurasi untuk scenario OSPF-single area

2. mf-ospf-multiarea.tar.gz → file konfigurasi untuk scenario OSPF-Multi area
3. mf-ebgp_ospf.tar.gz → file konfigurasi untuk scenario OSPF-BGP

Apabila proses ekstraksi dilakukan untuk salah satu dari 3 file diatas, maka folder routing/config akan tertimpa
sesuai dengan scenario yang diinginkan.

MENJALANKAN CONTAINER UNTUK SKENARIO OSPF-SINGLE AREA

Modul ini akan membahas bagaimana kita melakukan konfigurasi routing OSPF-single area. Oleh karena itu
Langkah awal adalah dengan melakukan ekstraksi file pada file archived mf-ospf-singlearea.tar.gz

Sudo tar -xvf mf-ospf-singlearea.tar.gz

Perintah diatas akan menimpa folder routing/config sesuai dengan scenario OSPF-Single area yang akan kita
lakukan. Setelah ekstraksi folde config, kita dapat mulai mengaktifkan container dengan perintah:

Sudo docker-compose up -d
Gambar 0—3 Hasil Eksekusi Docker-Compose Up
 TOPOLOGI DAN AREA OSPF
Author:

1. Sabriansyah R. Akbar, S.T., M.Eng., Ph.D

2. Achmad Basuki, S.T., M.MG., Ph.D

TOPOLOGI

Pada Section kali ini, kita akan mempelajari topologi jaringan yang telah kita bentuk di lingkungan container
pada section sebelumnya..

Gambar 1 Topologi Jaringan

Gambar 1 menunjukkan Topologi OSPF Single Area yang menjadi lingkungan praktik untuk single area routing.
Dalam topologi tersebut terdapat beberapa router yang terdiri dari:

1. BR01, BR02, BR03, R1, R2, R3, R4, R5 (8 buah router).

2. Terdapat client/hosts dengan nama C1, C2, C5,C6,C9,C10 (6 klien)
Untuk melihat konfigurasi alamat IP address pada masing-masing kita dapat masuk ke salah satu router atau
client dengan cara sebgai berikut:

Pertama-tama, kita aktifkan lingkungan container dengan mengetikkan perintah dibawah ini:

sudo /etc/init.d/docker start

kita dapat mulai mengaktifkan container yang terleletak di direktori home anda masing-masing dengan perintah:

sudo docker-compose up -d

Contoh, untuk masuk ke client 1 (C1) , kita dapat memberikan perintah:

sudo docker exec -it C1 sh

Atau sudo docker exec -it C1 sh -c “ip addr”

Perintah ini akan membawa kita ke shell router C1. Dan pada shell tersebut kita dapat memberikan perintah
yang terdapat pada linux. Sebagai contoh kita akan memberikan perintah untuk melihat alamat IP address
yang terdapat pada C1. Kita dapat memberikan perintah:

#ip addr

Gambar 2 Perintah IP addr

Hasil perintah IP addr menunjukkan bahwa client 1 (C1) memiliki alamat IP address yang terletak pada
interface eth0@if39 dengan konfigurasi alamat IP 10.255.1.2/24.

Selanjutnya kita dapat melihat informasi routing atau routing table pada C1 dengan perintah:

#ip route show

Atau sudo docker exec -it C1 sh -c “ip route show”

 Gambar 3. Perintah IP route Show

Gambar 3 menunjukkan hasil perintah “ip route show” yang menunjukkan informasi bahwa saat ini, hanya
terdapat satu alamat network 10.255.1.0/24 dan tidak terdapat alamat network yang lain. Alamat network yang
terletak pada routing table milik C1 terbentuk secara otomatis saat pemberian alamat IP.Hal ini
menginformasikan bahwa saat ini C1 hanya dapat menghubungi host yang terletak pada alamat network yang
sama yaitu 10.255.1.0/24. Apabila kita perhatikan topologi Gambar 1, kita dapat melihat Router 1(R1) memiliki
salah satu interface dengan alamat 10.255.1.254. Kita dapat melakukan tes koneksi dengan memberikan
perintah:

#ping 10.255.1.254

Atau sudo docker exec -it C1 sh -c “ping 10.255.1.254”

Gambar 4. Perintah Ping

Gambar 4 menunjukkan hasil perintah ping, yang menginformasikan bahwa Client 1(C1) dengan router 1(R1)
telah terhubung,. Kita dapat menggunakan perintah “exit” untuk keluar dari shell C1.

Untuk memasuki router 1 (R1) kita dapat masuk dengan perintah:

sudo docker exec -it R1 bash

Atau sudo docker exec -it R1 bash -c “ip addr”

Selanjutnya dengan perintah “ip addr” kita bisa mendapatkan perintah IP yang terdapat pada Router 1 (R1)
sepertii yang ditunjukkan pada:
 Gambar 5 Perintah IP addr pada Router 1(R1)

Gambar 5 menunjukkan bahwa R1 memiliki beberapa alamat IP sebagai berikut:

Tabel 1. Tabel Alamat IP Router 1 (R1)

Interface IP address Alamat Network/Subnet Keterangan

eth0@if29 10.255.1.254/24 10.255.1.254/24 Terhubung ke C1

eth1@if57 10.255.0.10/29 10.255.0.8/29 Terhubung ke BR1

eth2@if75 10.255.0.2/29 10.255.0.0/29 Terhubung ke R2

AREA PADA OSPF

Seperti pada Gambar 1, konfigurasi router OSPF, seluruh router wajib terhubung ke area/domain yang sama.
Pada kasus OSPF-single area ini, seluruh area berada diwilayah area 0. Area 0 pada konfigurasi ospf umum
biasa disebut dengan backbone area.Pada topologi yang ditunjukkan kita akan membuat agar seluruh hosts
dan router dapat terhubung satu dengan yang lain. Untuk itu diperlukan penyebaran informasi
jaringan/subnet yang ada pada masing-masing router ke seluruh router lain. Istilah ini disebut juga dengan
advertise.Untuk melakukan advertise alamat jaringan kita akan menggunakan protocol routing OSPF yang
merupakan salah satu protocol routing dinamis sehingga penyebaran informasi dilakukan antar router secara
otomatis.Protokol routing OSPF bekerja dengan mekanisme link-state. Konfigurasi routing OSPF akan dilakukan
di setiap router yang ada pada topologi dengan batasan untuk saat ini, seluruh router tergabung hanya pada
area 0 atau backbone area.
 KONFIGURASI ROUTING OSPF SINGLE
AREA
Author:

1. Sabriansyah R. Akbar, S.T., M.Eng., Ph.D

2. Achmad Basuki, S.T., M.MG., Ph.D

AREA

Gambar 1 Topologi Jaringan

Seperti pada Gambar 1, konfigurasi router OSPF, seluruh router wajib terhubung ke area/domain yang sama.
Pada kasus OSPF-single area ini, seluruh area berada diwilayah area 0. Area 0 pada konfigurasi ospf umum biasa
disebut dengan backbone area. Pada topologi yang ditunjukkan kita akan membuat agar seluruh hosts dan
router dapat terhubung satu dengan yang lain. Untuk itu diperlukan penyebaran informasi jaringan/subnet yang
ada pada masing-masing router ke seluruh router lain. Istilah ini disebut juga dengan advertise.Untuk melakukan
advertise alamat jaringan kita akan menggunakan protocol routing OSPF yang merupakan salah satu protocol
routing dinamis sehingga penyebaran informasi dilakukan antar router secara otomatis.Protokol routing OSPF
bekerja dengan mekanisme link-state. Konfigurasi routing OSPF akan dilakukan di setiap router yang ada pada
topologi dengan batasan untuk saat ini, seluruh router tergabung hanya pada area 0 atau backbone area.

Dikarenakan seluruh router terletak pada satu area yang sama, maka router dapat dikonfigurasi secara umum
dengan memperhatikan hal-hal sebagai berikut:

1. Masing-masing router memiliki interface yang terhubung ke host atau router yang lain.
2. Masing-masing router diperlukan untuk meng-advertise masing-masing alamat network yang ingin
dihubungkan ke topologi.
3. Masing-masing router/host diperlukan untuk menambahkan default gateway

PEMAHAMAN TERKAIT JENIS ROUTER OSPF (DR DAN BDR)

Pertukaran informasi update antar router dilkaukan pada sebuah Broadcast Multiaccess Network (BMA).
Masing-masing router saling bertukar informasi routing dapat mengakibatkan flood yang mengakibatkan
sumber daya router dan jaringan terbebani. Oleh karena itu pada implementasi OSPF, terdapat istilah
Designated Router (DR) dan Backup Designated Router untuk mengantisipasi permasalahan tersebut. Router
dengan konfigurasi prioritas tertinggi akan menjadi DR. Apabila terdapat kesamaan prioritas, maka Router-ID
tertinggi akan menjadi DR.Seluruh router akan memberikan informasi update ke DR dan BDR. Designated Router
(DR): Router yang bertugas untuk menerima update informasi dan menyebarkannya ke seluruh router non-DR
dan non-BDR. Backup Designated Router (BDR): bertugas sebagai backup dari DR.

Adapun contoh untuk masing-masing konfigurasi router dapat dilakukan seperti halnya sebagai berikut:

MENGKATIKFAN DOCKER

sudo /etc/init.d/docker start

kita dapat mulai mengaktifkan container yang terleletak di direktori home anda masing-masing dengan perintah:

sudo docker-compose up -d

CONTOH KONFIGURASI: ROUTER R1

Contoh, untuk masuk ke R1, kita dapat memberikan perintah:

sudo docker exec -it R1 sh

Perintah ini akan membawa kita ke shell router R1.kita dapat melihat konfigurasi router R1 dengan perintah:

#Ip addr
Gambar 2 menunjukkan daftar IP address yang terdapat pada R1 dengan spesifikasi sebagai berikut:

Interface IP address Alamat Keterangan

Network/Subnet

Eth0@if63 10.255.1.254/24 10.255.1.0/24 Terhubung ke C1

eth1@if87 10.255.0.10/29 10.255.0.8/29 Terhubung ke BR1

eth2@if45 10.255.0.2/29 10.255.0.0/29 Terhubung ke R2

Gambar 2 IP address pada Router R1

Maka konfigurasi router ospf pada R1 dapat dilakukan dengan konfigurasi dibawah ini:

sudo docker exec -it R1 vtysh

R1#configure terminal
R1(config)#router ospf
R1(config-router)#ospf router-id 10.255.1.1
R1(config-router)#network 10.255.0.0/29 area 0
R1(config-router)#network 10.255.0.8/29 area 0
R1(config-router)#network 10.255.1.0/24 area 0
 R1(config-router)#exit
R1(config)#write
Untuk melakukan verifikasi konfigurasi ketikkan perintah dibawah ini.

sudo docker exec -it R1 vtysh -c "sh run"

CONTOH KONFIGURASI: ROUTER BR3

Untuk masuk ke BR3, kita dapat memberikan perintah:

sudo docker exec -it BR03 bash

Perintah ini akan membawa kita ke shell router BR3. Kita dapat melihat konfigurasi router BR3 dengan
perintah:

#Ip addr
 Gambar 3 ip addr BR03

Gambar 3 menunjukkan daftar IP address yang terdapat pada BR03 dengan spesifikasi sebagai berikut:

Interface IP address Alamat Keterangan

Network/Subnet

Eth0@if141 10.255.100.253 10.255.100.0/24 Terhubung ke BR01

Eth1@if151 10.255.200.253 10.255.200.0/24 Terhubung ke BR02

Eth2@if167 10.255.8.14 10.255.8.8/29 Terhubung ke R5

Eth3@if177 10.255.8.22 10.255.8.16/29 Terhubung ke R6

Maka konfigurasi router ospf pada R1 dapat dilakukan dengan konfigurasi dibawah ini:

sudo docker exec -it BR03 vtysh

 R1#configure terminal
R1(config)#router ospf
R1(config-router)# ospf router-id 10.255.0.3
R1(config-router)# network 10.255.8.8/29 area 0
R1(config-router)# network 10.255.100.0/24 area 0
R1(config-router)# network 10.255.200.0/24 area 0
R1(config-router)#exit
R1(config)#write
Untuk melakukan verifikasi konfigurasi

sudo docker exec -it BR03 vtysh -c "sh run"

TES KONEKSI

Lakukan hal diatas untuk semua Router, dan kemudian tes koneksi dengan perintah ping.

Contoh dari BR03:

sudo docker exec -it BR03 bash

bash-5.1# ping 10.255.10.254

Hasil yang benar akan mendapati reply dari host C10 seperti halnya dibawah ini:

PING 10.255.10.254 (10.255.10.254): 56 data bytes

64 bytes from 10.255.10.254: seq=0 ttl=64 time=0.077 ms

64 bytes from 10.255.10.254: seq=1 ttl=64 time=0.050 ms

 VERIFIKASI ROUTING OSPF SINGLE AREA
Author:

1. Sabriansyah R. Akbar, S.T., M.Eng., Ph.D

2. Achmad Basuki, S.T., M.MG., Ph.D

AREA

Gambar 1 Topologi Jaringan

Pada section kali ini kita akan mempelajari perintah-perintah untuk melakukan verifikasi routing OSPF single
area yang telah kita lakukan di section sebelumnya.

ROUTING TABEL

Untuk melihat table routing yang terdapat pada masing-masing router (contoh pada BR03) di Error! Reference
source not found., kita dapat menjalankan perintah dibawah ini.

sudo docker exec -it BR03 vtysh -c “show ip route”

Hasil eksekusi ditunjukkan seperti dibawah ini:

Codes: K - kernel route, C - connected, S - static, R - RIP,

O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,

T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,

f - OpenFabric,

> - selected route, * - FIB route, q - queued, r - rejected, b - backup

t - trapped, o - offload failure

O>* 10.255.0.0/29 [110/30] via 10.255.100.254, eth0, weight 1, 02:37:18

O>* 10.255.0.8/29 [110/20] via 10.255.100.254, eth0, weight 1, 02:37:23

O>* 10.255.0.16/29 [110/20] via 10.255.100.254, eth0, weight 1, 02:37:23

O>* 10.255.1.0/24 [110/30] via 10.255.100.254, eth0, weight 1, 02:37:13

O>* 10.255.2.0/24 [110/30] via 10.255.100.254, eth0, weight 1, 02:37:18

O>* 10.255.4.0/29 [110/30] via 10.255.200.254, eth1, weight 1, 02:37:18

O>* 10.255.4.8/29 [110/20] via 10.255.200.254, eth1, weight 1, 02:37:23

O>* 10.255.4.16/29 [110/20] via 10.255.200.254, eth1, weight 1, 02:37:23

O>* 10.255.5.0/24 [110/30] via 10.255.200.254, eth1, weight 1, 02:37:17

O>* 10.255.6.0/24 [110/30] via 10.255.200.254, eth1, weight 1, 02:37:18

O>* 10.255.8.0/29 [110/20] via 10.255.8.10, eth2, weight 1, 02:37:13

* via 10.255.8.18, eth3, weight 1, 02:37:13

O 10.255.8.8/29 [110/10] is directly connected, eth2, weight 1, 02:37:28

C>* 10.255.8.8/29 is directly connected, eth2, 02:38:13

O 10.255.8.16/29 [110/10] is directly connected, eth3, weight 1, 02:38:12

C>* 10.255.8.16/29 is directly connected, eth3, 02:38:13

O>* 10.255.9.0/24 [110/20] via 10.255.8.10, eth2, weight 1, 02:37:23

O>* 10.255.10.0/24 [110/20] via 10.255.8.18, eth3, weight 1, 02:37:13

O 10.255.100.0/24 [110/10] is directly connected, eth0, weight 1, 02:38:12

C>* 10.255.100.0/24 is directly connected, eth0, 02:38:13

O>* 10.255.120.0/24 [110/20] via 10.255.100.254, eth0, weight 1, 02:37:17

* via 10.255.200.254, eth1, weight 1, 02:37:17

 O 10.255.200.0/24 [110/10] is directly connected, eth1, weight 1, 02:38:12

C>* 10.255.200.0/24 is directly connected, eth1, 02:38:13

Pada baris yang bercetak tebal kita dapat melihat bahwa protkol routing OSPF telah dijalankan dengan baik.
Contoh cara membaca baris diatas adalah sebagai berikut:

O>* 10.255.8.0/29 [110/20] via 10.255.8.10, eth2, weight 1, 02:37:13

* via 10.255.8.18, eth3, weight 1, 02:37:13

Perintah diatas menunjukkan bahwa terdapat jalur alamat network 10.255.8.0/29, dimana jalur tersebut di
advertise oleh 10.255.8.10 di interface eth2 (Router R5) dan 10.255.8.18 di interface eth3 10.255.8.18 (Router
R6). Angka [110/20] menunjukkan administrative distance dari OSPF (110) dan default metric (20). Angka (20)
menunjukkan hop dari BR03 menuju 10.255.8.0/29 adalah dua hop (1 hop bermetric 10). Angka weight 1
menunjukkan konfigurasi default weight. Kita dapat merubah nilai weight apabila kita menginginkan untuk
memanipulasi jalur route yang terbentuk dari default protkol routing OSPF.

MELIHAT INFORMASI OSPF

Untuk melihat informasi proses yang berjalan. Router ID, informasi area, dan informasi LSA kita dapat
mengeksekusi perintah dibawah ini:

sudo docker exec -it BR03 vtysh -c “show ip ospf”

Hasil eksekusi perintah diatas dapat dilihat pada table dibawah ini:

OSPF Routing Process, Router ID: 10.255.0.3

Supports only single TOS (TOS0) routes
This implementation conforms to RFC2328
RFC1583Compatibility flag is disabled
OpaqueCapability flag is disabled
Initial SPF scheduling delay 0 millisec(s)
Minimum hold time between consecutive SPFs 50 millisec(s)
Maximum hold time between consecutive SPFs 5000 millisec(s)
Hold time multiplier is currently 2
SPF algorithm last executed 2h51m48s ago
Last SPF duration 241 usecs
SPF timer is inactive
LSA minimum interval 5000 msecs
LSA minimum arrival 1000 msecs
Write Multiplier set to 20
Refresh timer 10 secs
Maximum multiple paths(ECMP) supported 64
Number of external LSA 0. Checksum Sum 0x00000000
Number of opaque AS LSA 0. Checksum Sum 0x00000000
Number of areas attached to this router: 1
 Area ID: 0.0.0.0 (Backbone)
Number of interfaces in this area: Total: 4, Active: 4
Number of fully adjacent neighbors in this area: 4
Area has no authentication
SPF algorithm executed 14 times
Number of LSA 21
Number of router LSA 9. Checksum Sum 0x0003807a
Number of network LSA 12. Checksum Sum 0x00053b3e
Number of summary LSA 0. Checksum Sum 0x00000000
Number of ASBR summary LSA 0. Checksum Sum 0x00000000
Number of NSSA LSA 0. Checksum Sum 0x00000000
Number of opaque link LSA 0. Checksum Sum 0x00000000
Number of opaque area LSA 0. Checksum Sum 0x00000000

MELIHAT INFORMASI OSPF NEIGHBOR

Untuk melihat informasi jumlah router yang ada pada jaringan dan neighbor ID kita dapat mengeksekusi
perintah ini

sudo docker exec -it BR03 vtysh -c “show ip ospf neighbor”

Hasil eksekusi perintah diatas dapat dilihat pada table dibawah ini:

Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL

10.255.0.1 1 Full/Backup 37.910s 10.255.100.254 eth0:10.255.100.253 0 0 0

10.255.0.2 1 Full/Backup 37.910s 10.255.200.254 eth1:10.255.200.253 0 0 0

10.255.9.1 1 Full/DR 31.586s 10.255.8.10 eth2:10.255.8.14 0 0 0

10.255.10.1 1 Full/DR 31.586s 10.255.8.18 eth3:10.255.8.22 0 0 0

Informasi diatas menunjukkan status neighbor ID (bukan IP), kondisi jalur, dan jenis router yang ada..
Chapter 5
Network Layer:
Control Plane
A note on the use of these PowerPoint slides:
We’re making these slides freely available to all (faculty, students,
readers). They’re in PowerPoint form so you see the animations; and
can add, modify, and delete slides (including this one) and slide content
to suit your needs. They obviously represent a lot of work on our part.
In return for use, we only ask the following:
▪ If you use these slides (e.g., in a class) that you mention their
source (after all, we’d like people to use our book!)
▪ If you post any slides on a www site, that you note that they are
adapted from (or perhaps identical to) our slides, and note our
copyright of this material.
Computer Networking: A
For a revision history, see the slide note for this page.
Top-Down Approach
Thanks and enjoy! JFK/KWR 8th edition
All material copyright 1996-2020
Jim Kurose, Keith Ross
J.F Kurose and K.W. Ross, All Rights Reserved Pearson, 2020
Network layer control plane: our goals
▪understand principles ▪ instantiation, implementation
behind network control in the Internet:
plane: • OSPF, BGP
• traditional routing algorithms • OpenFlow, ODL and ONOS
• SDN controllers controllers
• network management, • Internet Control Message
configuration Protocol: ICMP
• SNMP, YANG/NETCONF

Network Layer: 5-2

 Network layer: “control plane” roadmap
▪ introduction
▪ routing protocols
▪ link state
▪ distance vector
▪ intra-ISP routing: OSPF
▪ routing among ISPs: BGP
▪ network management,
▪ SDN control plane configuration
▪ Internet Control Message • SNMP
Protocol • NETCONF/YANG

Network Layer: 5-3

Network-layer functions
▪ forwarding: move packets from router’s
input to appropriate router output
data plane
▪ routing: determine route taken by
packets from source to destination
control plane

Two approaches to structuring network control plane:

▪ per-router control (traditional)
▪ logically centralized control (software defined networking)

Network Layer: 5-4

Per-router control plane
Individual routing algorithm components in each and every
router interact in the control plane

Routing
Algorithm
control
plane

data
plane

values in arriving
packet header
0111 1
2
3

Network Layer: 5-5

Software-Defined Networking (SDN) control plane
Remote controller computes, installs forwarding tables in routers

Remote Controller

control
plane

data
plane

CA
CA CA CA CA
values in arriving
packet header

0111 1
2
3

Network Layer: 5-6

 Network layer: “control plane” roadmap
▪ introduction
▪ routing protocols
▪ link state
▪ distance vector
▪ intra-ISP routing: OSPF
▪ routing among ISPs: BGP ▪ network management,
▪ SDN control plane configuration
▪ Internet Control Message • SNMP
Protocol • NETCONF/YANG

Network Layer: 5-7

Routing protocols mobile network
national or global ISP
Routing protocol goal: determine
“good” paths (equivalently, routes),
from sending hosts to receiving host, application
transport

through network of routers network

link
physical

▪ path: sequence of routers packets network

link
physical
network
link
physical

traverse from given initial source host

to final destination host network
link
physical
network
link

▪ “good”: least “cost”, “fastest”, “least

physical network
link datacenter
physical network

congested”
▪ routing: a “top-10” networking
application
transport
network
challenge! enterprise
network
link
physical

Network Layer: 5-8

Graph abstraction: link costs
5
ca,b: cost of direct link connecting a and b
v 3 w e.g., cw,z = 5, cu,z = ∞
2 5
u 2 1 z
3 cost defined by network operator:
1 2
x y could always be 1, or inversely related
1
to bandwidth, or inversely related to
congestion
graph: G = (N,E)
N: set of routers = { u, v, w, x, y, z }
E: set of links ={ (u,v), (u,x), (v,x), (v,w), (x,w), (x,y), (w,y), (w,z), (y,z) }

Network Layer: 5-9

 Routing algorithm classification
global: all routers have complete
topology, link cost info
• “link state” algorithms
How fast
dynamic: routes change
do routes static: routes change more quickly
change? slowly over time • periodic updates or in
response to link cost
changes
decentralized: iterative process of
computation, exchange of info with neighbors
• routers initially only know link costs to
attached neighbors
• “distance vector” algorithms
global or decentralized information? Network Layer: 5-10
 Network layer: “control plane” roadmap
▪ introduction
▪ routing protocols
▪ link state
▪ distance vector
▪ intra-ISP routing: OSPF
▪ routing among ISPs: BGP ▪ network management,
▪ SDN control plane configuration
▪ Internet Control Message • SNMP
Protocol • NETCONF/YANG

Network Layer: 5-11

Dijkstra’s link-state routing algorithm
▪ centralized: network topology, link
costs known to all nodes
• accomplished via “link state
broadcast”
• all nodes have same info
▪ computes least cost paths from one
node (“source”) to all other nodes
• gives forwarding table for that node
▪ iterative: after k iterations, know
least cost path to k destinations
notation
▪ cx,y: direct link cost from
node x to y; = ∞ if not direct
neighbors
▪ D(v): current estimate of cost
of least-cost-path from source
to destination v
▪ p(v): predecessor node along
path from source to v
▪ N': set of nodes whose least-
cost-path definitively known
Network Layer: 5-12
Dijkstra’s link-state routing algorithm
1 Initialization:
2 N' = {u} /* compute least cost path from u to all other nodes */
3 for all nodes v
4 if v adjacent to u /* u initially knows direct-path-cost only to direct neighbors */
5 then D(v) = cu,v /* but may not be minimum cost! */
6 else D(v) = ∞
7
8 Loop
9 find w not in N' such that D(w) is a minimum
10 add w to N'
11 update D(v) for all v adjacent to w and not in N' :
12 D(v) = min ( D(v), D(w) + cw,v )
13 /* new least-path-cost to v is either old least-cost-path to v or known
14 least-cost-path to w plus direct-cost from w to v */
15 until all nodes in N'
Network Layer: 5-13
Dijkstra’s algorithm: an example
v w x y z
Step N' D(v),p(v) D(w),p(w) D(x),p(x) D(y),p(y) D(z),p(z)
0 u 2,u 5,u 1,u ∞ ∞
1 ux 2,u 4,x 2,x ∞
2 uxy 2,u 3,y 4,y
3 uxyv 3,y 4,y
4 uxyvw 4,y
5 uxyvwz
Initialization (step 0): For all a: if a adjacent to then D(a) = cu,a
5
3
find a not in N' such that D(a) is a minimum
v w 5 add a to N'
2
u 2 1 z update D(b) for all b adjacent to a and not in N' :
3 D(b) = min ( D(b), D(a) + ca,b )
1 2
x 1
y

Network Layer: 5-14

 Dijkstra’s algorithm: an example
5

v 3 w
2 5
u 2 1 z
3
1 2
x 1
y

resulting least-cost-path tree from u: resulting forwarding table in u:

destination outgoing link
v w
v (u,v) route from u to v directly
u z x (u,x)
y (u,x) route from u to all
x y w (u,x) other destinations
x (u,x) via x
Network Layer: 5-15
 Dijkstra’s algorithm: another example
v w x y z
D(v), D(w), D(x), D(y), D(z), x
9
Step N' p(v) p(w) p(x) p(y) p(z)

0 u 7,u 3,u 5,u ∞ ∞ 5 7

4
1 uw 6,w 5,u 11,w ∞ 8
2 uwx 6,w 11,w 14,x 3 w z
u y
2
3 uwxv 10,v 14,x
3
4 uwxvy 12,y 7 4

5 uwxvyz v

notes:
▪ construct least-cost-path tree by tracing predecessor nodes
▪ ties can exist (can be broken arbitrarily)
Network Layer: 5-16
Dijkstra’s algorithm: discussion
algorithm complexity: n nodes
▪ each of n iteration: need to check all nodes, w, not in N
▪ n(n+1)/2 comparisons: O(n2) complexity
▪ more efficient implementations possible: O(nlogn)
message complexity:
▪ each router must broadcast its link state information to other n routers
▪ efficient (and interesting!) broadcast algorithms: O(n) link crossings to disseminate a
broadcast message from one source
▪ each router’s message crosses O(n) links: overall message complexity: O(n2)

Network Layer: 5-17

 Dijkstra’s algorithm: oscillations possible
▪ when link costs depend on traffic volume, route oscillations possible
▪ sample scenario:
• routing to destination a, traffic entering at d, c, e with rates 1, e (<1), 1
• link costs are directional, and volume-dependent

a 2+e
a a 2+e a
1 1+e 0 0 2+e 0
d b d 1+e 1 b d 0 0
b d 1+e 1 b
0 0
e 1 0 1 1 1 0
1 0
c c 0 1 c 1+e 1 0 1
1 c
e e e
e

given these costs, given these costs, given these costs,

initially find new routing…. find new routing…. find new routing….
resulting in new costs resulting in new costs resulting in new costs

Network Layer: 5-18

 Network layer: “control plane” roadmap
▪ introduction
▪ routing protocols
▪ link state
▪ distance vector
▪ intra-ISP routing: OSPF
▪ routing among ISPs: BGP ▪ network management,
▪ SDN control plane configuration
▪ Internet Control Message • SNMP
Protocol • NETCONF/YANG

Network Layer: 5-19

Distance vector algorithm
Based on Bellman-Ford (BF) equation (dynamic programming):
Bellman-Ford equation

Let Dx(y): cost of least-cost path from x to y.

Then:
Dx(y) = minv { cx,v + Dv(y) }

v’s estimated least-cost-path cost to y

min taken over all neighbors v of x direct cost of link from x to v
Network Layer: 5-20
Bellman-Ford Example
Suppose that u’s neighboring nodes, x,v,w, know that for destination z:
Dv(z) = 5 Dw(z) = 3 Bellman-Ford equation says:
5
Du(z) = min { cu,v + Dv(z),
3 w
v 5 cu,x + Dx(z),
2
u 2 1 z cu,w + Dw(z) }
3
1 2
= min {2 + 5,
x 1
y 1 + 3,
5 + 3} = 4
Dx(z) = 3
node achieving minimum (x) is
next hop on estimated least-
cost path to destination (z)
Network Layer: 5-21
Distance vector algorithm
key idea:
▪ from time-to-time, each node sends its own distance vector estimate
to neighbors
▪ when x receives new DV estimate from any neighbor, it updates its
own DV using B-F equation:
Dx(y) ← minv{cx,v + Dv(y)} for each node y ∊ N

▪ under minor, natural conditions, the estimate Dx(y) converge to the

actual least cost dx(y)

Network Layer: 5-22

Distance vector algorithm:
each node:
wait for (change in local link
cost or msg from neighbor)
recompute DV estimates using
DV received from neighbor
if DV to any destination has
changed, notify neighbors
iterative, asynchronous: each local
iteration caused by:
▪ local link cost change
▪ DV update message from neighbor
distributed, self-stopping: each
node notifies neighbors only when
its DV changes
▪ neighbors then notify their
neighbors – only if necessary
▪ no notification received, no
actions taken!
Network Layer: 5-23
 Distance vector: example
DV in a:
Da(a)=0
Da(b) = 8
Da(c) = ∞ a b c
Da(d) = 1 8 1
Da(e) = ∞
t=0 Da(f) = ∞
1 1
Da(g) = ∞
Da(h) = ∞
▪ All nodes have
Da(i) = ∞
distance estimates
to nearest A few asymmetries:
d e f ▪ missing link
neighbors (only) 1 1
▪ larger cost
▪ All nodes send
their local
distance vector to 1 1 1
their neighbors

g h i
1 1

Network Layer: 5-24

 Distance vector example: iteration

a b c
8 1

t=1 1 1
All nodes:
▪ receive distance
vectors from
neighbors d e f
▪ compute their new 1 1
local distance
vector
▪ send their new 1 1 1
local distance
vector to neighbors

g h i
1 1

Network Layer: 5-25

 Distance vector example: iteration

a
compute compute
b compute
c
8 1

t=1 1 1
All nodes:
▪ receive distance
vectors from
neighbors d
compute compute
e compute
f
▪ compute their new 1 1
local distance
vector
▪ send their new 1 1 1
local distance
vector to neighbors

g
compute h
compute compute
i
1 1

Network Layer: 5-26

 Distance vector example: iteration

a b c
8 1

t=1 1 1
All nodes:
▪ receive distance
vectors from
neighbors d e f
▪ compute their new 1 1
local distance
vector
▪ send their new 1 1 1
local distance
vector to neighbors

g h i
1 1

Network Layer: 5-27

 Distance vector example: iteration

a b c
8 1

t=2 1 1
All nodes:
▪ receive distance
vectors from
neighbors d e f
▪ compute their new 1 1
local distance
vector
▪ send their new 1 1 1
local distance
vector to neighbors

g h i
1 1

Network Layer: 5-28

 Distance vector example: iteration

compute
a compute
b compute
c
2 1

t=2 1 1
All nodes:
▪ receive distance
vectors from
neighbors compute
d compute
e compute
f
▪ compute their new 1 1
local distance
vector
▪ send their new 1 1 1
local distance
vector to neighbors

g
compute compute
h compute
i
8 1

Network Layer: 5-29

 Distance vector example: iteration

a b c
8 1

t=2 1 1
All nodes:
▪ receive distance
vectors from
neighbors d e f
▪ compute their new 1 1
local distance
vector
▪ send their new 1 1 1
local distance
vector to neighbors

g h i
1 1

Network Layer: 5-30

Distance vector example: iteration

…. and so on

Let’s next take a look at the iterative computations at nodes

Network Layer: 5-31

 DV in b: DV in c:
Distance vector example: computation Db(a) = 8 Db(f) = ∞ Dc(a) = ∞
Db(c) = 1 Db(g) = ∞ Dc(b) = 1
Db(d) = ∞ Db(h) = ∞ Dc(c) = 0
DV in a: Dc(d) = ∞
Db(e) = 1 Db(i) = ∞
Da(a)=0
Dc(e) = ∞
Da(b) = 8
Dc(f) = ∞
Da(c) = ∞ a b c Dc(g) = ∞
Da(d) = 1 8 1
Dc(h) = ∞
Da(e) = ∞
Dc(i) = ∞
t=1 Da(f) = ∞
1 1
Da(g) = ∞
▪ b receives DVs Da(h) = ∞ DV in e:
from a, c, e Da(i) = ∞ De(a) = ∞
De(b) = 1
d e f De(c) = ∞
1 1 De(d) = 1
De(e) = 0
De(f) = 1
1 1 1 De(g) = ∞
De(h) = 1
De(i) = ∞

g h i
1 1

Network Layer: 5-32

 DV in b: DV in c:
Distance vector example: computation Db(a) = 8 Db(f) = ∞ Dc(a) = ∞
Db(c) = 1 Db(g) = ∞ Dc(b) = 1
Db(d) = ∞ Db(h) = ∞ Dc(c) = 0
DV in a: Dc(d) = ∞
Db(e) = 1 Db(i) = ∞
Da(a)=0
Dc(e) = ∞
Da(b) = 8
Dc(f) = ∞
Da(c) = ∞ a b c Dc(g) = ∞
Da(d) = 1 8 compute 1
Dc(h) = ∞
Da(e) = ∞
Dc(i) = ∞
t=1 Da(f) = ∞
1 1
Da(g) = ∞
▪ b receives DVs Da(h) = ∞ DV in e:
from a, c, e, Da(i) = ∞ De(a) = ∞
computes: e
De(b) = 1
d e f De(c) = ∞
1
Db(a) = min{cb,a+Da(a), cb,c +Dc(a), cb,e+De(a)} = min{8,∞,∞} =8 1 De(d) = 1
Db(c) = min{cb,a+Da(c), cb,c +Dc(c), c b,e +De(c)} = min{∞,1,∞} = 1 De(e) = 0
Db(d) = min{cb,a+Da(d), cb,c +Dc(d), c b,e +De(d)} = min{9,2,∞} = 2 De(f) = 1
1 1 1 De(g) = ∞
Db(e) = min{cb,a+Da(e), cb,c +Dc(e), c b,e +De(e)} = min{∞,∞,1} = 1
De(h) = 1
Db(f) = min{cb,a+Da(f), cb,c +Dc(f), c b,e +De(f)} = min{∞,∞,2} = 2
DV in b:
De(i) = ∞
Db(g) = min{cb,a+Da(g), cb,c +Dc(g), c b,e+De(g)} = min{∞, ∞, ∞} = ∞ Db(a) = 8 Db(f) =2
g h D (c) = 1 Db(g)
i =∞
1 ∞, 2} = 2
Db(h) = min{cb,a+Da(h), cb,c +Dc(h), c b,e+De(h)} = min{∞, 1Db(d) = 2 Db(h) = 2
b
Db(i) = min{cb,a+Da(i), cb,c +Dc(i), c b,e+De(i)} = min{∞, ∞, ∞} = ∞ Db(e) = 1 Db(i) = ∞
Network Layer: 5-33
 DV in b: DV in c:
Distance vector example: computation Db(a) = 8 Db(f) = ∞ Dc(a) = ∞
Db(c) = 1 Db(g) = ∞ Dc(b) = 1
Db(d) = ∞ Db(h) = ∞ Dc(c) = 0
DV in a: Dc(d) = ∞
Db(e) = 1 Db(i) = ∞
Da(a)=0
Dc(e) = ∞
Da(b) = 8
Dc(f) = ∞
Da(c) = ∞ a b c Dc(g) = ∞
Da(d) = 1 8 1
Dc(h) = ∞
Da(e) = ∞
Dc(i) = ∞
t=1 Da(f) = ∞
1 1
Da(g) = ∞
▪ c receives DVs Da(h) = ∞ DV in e:
from b Da(i) = ∞ De(a) = ∞
De(b) = 1
d e f De(c) = ∞
1 1 De(d) = 1
De(e) = 0
De(f) = 1
1 1 1 De(g) = ∞
De(h) = 1
De(i) = ∞

g h i
1 1

Network Layer: 5-34

 DV in b: DV in c:
Distance vector example: computation Db(a) = 8 Db(f) = ∞ Dc(a) = ∞
Db(c) = 1 Db(g) = ∞ Dc(b) = 1
Db(d) = ∞ Db(h) = ∞ Dc(c) = 0
Db(e) = 1 Db(i) = ∞ Dc(d) = ∞
Dc(e) = ∞
Dc(f) = ∞
a b c
compute Dc(g) = ∞
8 1
Dc(h) = ∞
Dc(i) = ∞
t=1 1 1
▪ c receives DVs
from b computes:

d b(a}} = 1 + 8 = 9
Dc(a) = min{cc,b+D e f
DV in c:
Dc(b) = min{cc,b+Db(b)} = 1 + 0 = 1
Dc(a) = 9
Dc(d) = min{cc,b+Db(d)} = 1+ ∞ = ∞ Dc(b) = 1
Dc(e) = min{cc,b+Db(e)} = 1 + 1 = 2 Dc(c) = 0
Dc(d) = 2
Dc(f) = min{cc,b+Db(f)} = 1+ ∞ = ∞
Dc(e) = ∞
Dc(g) = min{cc,b+Db(g)} = 1+ ∞ = ∞ * Check out the online interactive
Dc(f) = ∞ exercises for more examples:
Dc(h) = min{cbc,bg+Db(h)} = 1+ ∞ = ∞ h Dc(g) = ∞ i http://gaia.cs.umass.edu/kurose_ross/interactive/
Dc(i) = min{cc,b+Db(i)} = 1+ ∞ = ∞ Dc(h) = ∞
Dc(i) = ∞
Network Layer: 5-35
 DV in b:
Distance vector example: computation Db(a) = 8 Db(f) = ∞
Db(c) = 1 Db(g) = ∞
Db(d) = ∞ Db(h) = ∞ DV in e:
DV in d: Db(e) = 1 Db(i) = ∞
De(a) = ∞
Dc(a) = 1 De(b) = 1
Dc(b) = ∞ a De(c) = ∞
b c
Dc(c) = ∞ 8 1 De(d) = 1
Dc(d) = 0 De(e) = 0
t=1 Dc(e) = 1
Dc(f) = ∞ 1
Q: what is new DV computed in e at
1t=1?
De(f) = 1
De(g) = ∞
▪ e receives DVs Dc(g) = 1 De(h) = 1
from b, d, f, h Dc(h) = ∞ De(i) = ∞
Dc(i) = ∞
d compute
e f DV in f:
DV in h: 1 1
Dc(a) = ∞
Dc(a) = ∞ Dc(b) = ∞
Dc(b) = ∞ Dc(c) = ∞
Dc(c) = ∞ 1 1 1 Dc(d) = ∞
Dc(d) = ∞ Dc(e) = 1
Dc(e) = 1 Dc(f) = 0
Dc(f) = ∞ Dc(g) = ∞
Dc(g) = 1 g h i Dc(h) = ∞
1 1
Dc(h) = 0 Dc(i) = 1
Dc(i) = 1 Network Layer: 5-36
Distance vector: state information diffusion
Iterative communication, computation steps diffuses information through network:
t=0 c’s state at t=0 is at c only
a b c
8 1
c’s state at t=0 has propagated to b, and
t=1 may influence distance vector computations
up to 1 hop away, i.e., at b 1 1 t=1
t=2
c’s state at t=0 may now influence distance
t=2 vector computations up to 2 hops away, i.e.,
d e f
at b and now at a, e as well 1 1
c’s state at t=0 may influence distance vector
t=3 computations up to 3 hops away, i.e., at b,a,e
1 1 1 t=3
and now at c,f,h as well
c’s state at t=0 may influence distance vector
t=4 computations up to 4 hops away, i.e., at b,a,e, g i
1
h 1
c, f, h and now at g,i as well t=4
 Distance vector: link cost changes
1
link cost changes: y
4 1
▪ node detects local link cost change x z
50
▪ updates routing info, recalculates local DV
▪ if DV changes, notify neighbors

t0 : y detects link-cost change, updates its DV, informs its neighbors.

“good news t1 : z receives update from y, updates its table, computes new least
travels fast” cost to x , sends its neighbors its DV.
t2 : y receives z’s update, updates its distance table. y’s least costs
do not change, so y does not send a message to z.

Network Layer: 5-38

Distance vector: link cost changes
60
link cost changes: y
4 1
▪ node detects local link cost change x z
50
▪ “bad news travels slow” – count-to-infinity
•problem:
y sees direct link to x has new cost 60, but z has said it has a path at cost of 5. So
y computes “my new cost to x will be 6, via z); notifies z of new cost of 6 to x.
• z learns that path to x via y has new cost 6, so z computes “my new cost to
x will be 7 via y), notifies y of new cost of 7 to x.
• y learns that path to x via z has new cost 7, so y computes “my new cost to
x will be 8 via y), notifies z of new cost of 8 to x.
• z learns that path to x via y has new cost 8, so z computes “my new cost to
x will be 9 via y), notifies y of new cost of 9 to x.
…
▪ see text for solutions. Distributed algorithms are tricky!
Network Layer: 5-39
Comparison of LS and DV algorithms
message complexity
LS: n routers, O(n2) messages sent
DV: exchange between neighbors;
convergence time varies
speed of convergence
LS: O(n2) algorithm, O(n2) messages
• may have oscillations
DV: convergence time varies
• may have routing loops
• count-to-infinity problem
robustness: what happens if router
malfunctions, or is compromised?
LS:
• router can advertise incorrect link cost
• each router computes only its own
table
DV:
• DV router can advertise incorrect path
cost (“I have a really low cost path to
everywhere”): black-holing
• each router’s table used by others:
error propagate thru network
Network Layer: 5-40
 Network layer: “control plane” roadmap
▪ introduction
▪ routing protocols
▪ intra-ISP routing: OSPF
▪ routing among ISPs: BGP
▪ SDN control plane
▪ Internet Control Message ▪ network management,
Protocol configuration
• SNMP
• NETCONF/YANG

Network Layer: 5-41

Making routing scalable
our routing study thus far - idealized
▪ all routers identical
▪ network “flat”
… not true in practice
scale: billions of destinations: administrative autonomy:
▪ can’t store all destinations in ▪ Internet: a network of networks
routing tables! ▪ each network admin may want to
▪ routing table exchange would control routing in its own network
swamp links!

Network Layer: 5-42

Internet approach to scalable routing
aggregate routers into regions known as “autonomous
systems” (AS) (a.k.a. “domains”)

intra-AS (aka “intra-domain”): inter-AS (aka “inter-domain”):

routing among within same AS routing among AS’es
(“network”) ▪ gateways perform inter-domain
▪ all routers in AS must run same intra- routing (as well as intra-domain
domain protocol routing)
▪ routers in different AS can run different
intra-domain routing protocols
▪ gateway router: at “edge” of its own AS,
has link(s) to router(s) in other AS’es
Network Layer: 5-43
Interconnected ASes
forwarding table configured by intra-
and inter-AS routing algorithms
Intra-AS Inter-AS
Routing Routing ▪ intra-AS routing determine entries for
forwarding destinations within AS
table
▪ inter-AS & intra-AS determine entries
for external destinations

intra-AS
3c
routing3a inter-AS routing intra-AS
2c
3b 2a routing
2b
1c
intra-AS
AS3
1a routing 1b AS2
1d
AS1

Network Layer: 5-44

 Inter-AS routing: a role in intradomain forwarding
▪ suppose router in AS1 receives AS1 inter-domain routing must:
datagram destined outside of AS1: 1. learn which destinations reachable
• router should forward packet to through AS2, which through AS3
gateway router in AS1, but which 2. propagate this reachability info to all
one? routers in AS1

3c
3a other
2c networks
3b 2a
2b
1c
AS3
other 1a 1b AS2
networks
1d
AS1

Network Layer: 5-45

Inter-AS routing: routing within an AS
most common intra-AS routing protocols:
▪ RIP: Routing Information Protocol [RFC 1723]
• classic DV: DVs exchanged every 30 secs
• no longer widely used
▪ EIGRP: Enhanced Interior Gateway Routing Protocol
• DV based
• formerly Cisco-proprietary for decades (became open in 2013 [RFC 7868])
▪ OSPF: Open Shortest Path First [RFC 2328]
• link-state routing
• IS-IS protocol (ISO standard, not RFC standard) essentially same as OSPF

Network Layer: 5-46

OSPF (Open Shortest Path First) routing
▪ “open”: publicly available
▪ classic link-state
• each router floods OSPF link-state advertisements (directly over IP
rather than using TCP/UDP) to all other routers in entire AS
• multiple link costs metrics possible: bandwidth, delay
• each router has full topology, uses Dijkstra’s algorithm to compute
forwarding table
▪ security: all OSPF messages authenticated (to prevent malicious
intrusion)

Network Layer: 5-47

 Hierarchical OSPF
▪ two-level hierarchy: local area, backbone.
• link-state advertisements flooded only in area, or backbone
• each node has detailed area topology; only knows direction to reach
other destinations
area border routers: boundary router:
“summarize” distances to connects to other ASes
backbone
destinations in own area, backbone router:
advertise in backbone runs OSPF limited
to backbone
local routers:
• flood LS in area only area 3
• compute routing within
area
internal
• forward packets to outside routers
area 1
via area border router
area 2 Network Layer: 5-48
 Network layer: “control plane” roadmap
▪ introduction
▪ routing protocols
▪ intra-ISP routing: OSPF
▪ routing among ISPs: BGP
▪ SDN control plane
▪ Internet Control Message ▪ network management,
Protocol configuration
• SNMP
• NETCONF/YANG

Network Layer: 5-49

Internet inter-AS routing: BGP
▪ BGP (Border Gateway Protocol): the de facto inter-domain routing
protocol
• “glue that holds the Internet together”
▪ allows subnet to advertise its existence, and the destinations it can
reach, to rest of Internet: “I am here, here is who I can reach, and how”
▪ BGP provides each AS a means to:
• eBGP: obtain subnet reachability information from neighboring ASes
• iBGP: propagate reachability information to all AS-internal routers.
• determine “good” routes to other networks based on reachability information
and policy

Network Layer: 5-50

eBGP, iBGP connections
2b

2a ∂
2c
1b 3b
2d
1a 1c ∂
3a 3c
AS 2
1d 3d

AS 1 eBGP connectivity AS 3
logical iBGP connectivity

1c gateway routers run both eBGP and iBGP protocols

Network Layer: 5-51

BGP basics
▪ BGP session: two BGP routers (“peers”) exchange BGP messages over
semi-permanent TCP connection:
• advertising paths to different destination network prefixes (BGP is a “path
vector” protocol)
▪ when AS3 gateway 3a advertises path AS3,X to AS2 gateway 2c:
• AS3 promises to AS2 it will forward datagrams towards X
AS 3 3b
AS 1 1b 3a 3c
1a 1c AS 2 3d
2b
1d BGP advertisement:
2a 2c X
AS3, X
2d
Network Layer: 5-52
Path attributes and BGP routes
▪ BGP advertised route: prefix + attributes
• prefix: destination being advertised
• two important attributes:
• AS-PATH: list of ASes through which prefix advertisement has passed
• NEXT-HOP: indicates specific internal-AS router to next-hop AS
▪ policy-based routing:
• gateway receiving route advertisement uses import policy to
accept/decline path (e.g., never route through AS Y).
• AS policy also determines whether to advertise path to other other
neighboring ASes

Network Layer: 5-53

BGP path advertisement
AS 3 3b
AS 1 1b 3a 3c
1a 1c AS 2 3d X
2b
1d AS3, X
AS2,AS3,X 2a 2c

2d

▪ AS2 router 2c receives path advertisement AS3,X (via eBGP) from AS3 router 3a
▪ based on AS2 policy, AS2 router 2c accepts path AS3,X, propagates (via iBGP) to all
AS2 routers
▪ based on AS2 policy, AS2 router 2a advertises (via eBGP) path AS2, AS3, X to
AS1 router 1c
Network Layer: 5-54
BGP path advertisement (more)
AS 3 3b
AS 1 1b AS3,X 3a 3c
AS3,X
AS3,X
1a 1c AS 2 3d X
2b
AS3,X
1d AS3, X
AS2,AS3,X 2a 2c

2d

gateway router may learn about multiple paths to destination:

▪ AS1 gateway router 1c learns path AS2,AS3,X from 2a
▪ AS1 gateway router 1c learns path AS3,X from 3a
▪ based on policy, AS1 gateway router 1c chooses path AS3,X and advertises path
within AS1 via iBGP
Network Layer: 5-55
BGP messages
▪ BGP messages exchanged between peers over TCP connection
▪ BGP messages:
• OPEN: opens TCP connection to remote BGP peer and authenticates
sending BGP peer
• UPDATE: advertises new path (or withdraws old)
• KEEPALIVE: keeps connection alive in absence of UPDATES; also ACKs
OPEN request
• NOTIFICATION: reports errors in previous msg; also used to close
connection

Network Layer: 5-56

 BGP path advertisement
AS 3 3b
AS 1 1b AS3,X 3a 3c
AS3,X
1
AS3,X
1a 1c AS 2 3d X
2 2b
local link AS3,X
2 1 AS3, X
interfaces 1d
at 1a, 1d AS2,AS3,X 2a 2c

2d

dest interface ▪ recall: 1a, 1b, 1d learn via iBGP from 1c: “path to X goes through 1c”
… …
1c 1 ▪ at 1d: OSPF intra-domain routing: to get to 1c, use interface 1
X 1 ▪ at 1d: to get to X, use interface 1
… …

Network Layer: 5-57

 BGP path advertisement
AS 3 3b
AS 1 1b 3a 3c
1
1a 1c AS 2 3d X
2 2b
1d
2a 2c

2d

dest interface
… … ▪ recall: 1a, 1b, 1d learn via iBGP from 1c: “path to X goes through 1c”
1c 2
▪ at 1d: OSPF intra-domain routing: to get to 1c, use interface 1
X 2
… … ▪ at 1d: to get to X, use interface 1
▪ at 1a: OSPF intra-domain routing: to get to 1c, use interface 2
▪ at 1a: to get to X, use interface 2
Network Layer: 5-58
Why different Intra-, Inter-AS routing ?
policy:
▪ inter-AS: admin wants control over how its traffic routed, who
routes through its network
▪ intra-AS: single admin, so policy less of an issue
scale:
▪ hierarchical routing saves table size, reduced update traffic
performance:
▪ intra-AS: can focus on performance
▪ inter-AS: policy dominates over performance

Network Layer: 5-59

Hot potato routing
AS 3 3b
AS 1 1b 3a 3c
1a 1c AS 2 3d X
2b 112
1d AS1,AS3,X AS3,X
2a 2c
201 263

2d
OSPF link weights

▪ 2d learns (via iBGP) it can route to X via 2a or 2c

▪ hot potato routing: choose local gateway that has least intra-domain
cost (e.g., 2d chooses 2a, even though more AS hops to X): don’t worry
about inter-domain cost!
Network Layer: 5-60
 BGP: achieving policy via advertisements
A,w
B provider
x network
w A legend:
A,w C y customer
network:

ISP only wants to route traffic to/from its customer networks (does not want
to carry transit traffic between other ISPs – a typical “real world” policy)
▪ A advertises path Aw to B and to C
▪ B chooses not to advertise BAw to C!
▪ B gets no “revenue” for routing CBAw, since none of C, A, w are B’s customers
▪ C does not learn about CBAw path
▪ C will route CAw (not using B) to get to w
Network Layer: 5-61
 BGP: achieving policy via advertisements (more)
B provider
x network
w A legend:
C y customer
network:

ISP only wants to route traffic to/from its customer networks (does not want
to carry transit traffic between other ISPs – a typical “real world” policy)
▪ A,B,C are provider networks
▪ x,w,y are customer (of provider networks)
▪ x is dual-homed: attached to two networks
▪ policy to enforce: x does not want to route from B to C via x
▪ .. so x will not advertise to B a route to C
Network Layer: 5-62
BGP route selection
▪ router may learn about more than one route to destination
AS, selects route based on:
1. local preference value attribute: policy decision
2. shortest AS-PATH
3. closest NEXT-HOP router: hot potato routing
4. additional criteria

Network Layer: 5-63

 Network layer: “control plane” roadmap
▪ introduction
▪ routing protocols
▪ intra-ISP routing: OSPF
▪ routing among ISPs: BGP
▪ SDN control plane
▪ Internet Control Message ▪ network management,
Protocol configuration
• SNMP
• NETCONF/YANG

Network Layer: 5-64

Software defined networking (SDN)
▪ Internet network layer: historically implemented via
distributed, per-router control approach:
• monolithic router contains switching hardware, runs proprietary
implementation of Internet standard protocols (IP, RIP, IS-IS, OSPF,
BGP) in proprietary router OS (e.g., Cisco IOS)
• different “middleboxes” for different network layer functions:
firewalls, load balancers, NAT boxes, ..
▪ ~2005: renewed interest in rethinking network control plane

Network Layer: 5-65

Per-router control plane
Individual routing algorithm components in each and every router
interact in the control plane to computer forwarding tables

Routing
Algorithm
control
plane

data
plane

values in arriving
packet header
0111 1
2
3

Network Layer: 4-66

Software-Defined Networking (SDN) control plane
Remote controller computes, installs forwarding tables in routers

Remote Controller

control
plane

data
plane

CA
CA CA CA CA
values in arriving
packet header

0111 1
2
3

Network Layer: 4-67

Software defined networking (SDN)
Why a logically centralized control plane?
▪ easier network management: avoid router misconfigurations,
greater flexibility of traffic flows
▪ table-based forwarding (recall OpenFlow API) allows
“programming” routers
• centralized “programming” easier: compute tables centrally and distribute
• distributed “programming” more difficult: compute tables as result of
distributed algorithm (protocol) implemented in each-and-every router
▪ open (non-proprietary) implementation of control plane
• foster innovation: let 1000 flowers bloom

Network Layer: 5-68

 SDN analogy: mainframe to PC revolution
Ap Ap Ap Ap Ap Ap Ap Ap Ap Ap
App
Specialized p p p p p p p p p p
Applications Open Interface

Specialized
Operating or or
System
Windows Linux MAC OS
Specialized Open Interface
Hardware
Microprocessor

Vertically integrated Horizontal

Closed, proprietary Open interfaces
Slow innovation Rapid innovation
Small industry Huge industry
* Slide courtesy: N. McKeown Network Layer: 5-69
Traffic engineering: difficult with traditional routing
5
3
2 v w 5

u 2 1
3 z
1
2
x 1 y

Q: what if network operator wants u-to-z traffic to flow along

uvwz, rather than uxyz?
A: need to re-define link weights so traffic routing algorithm
computes routes accordingly (or need a new routing algorithm)!
link weights are only control “knobs”: not much control!
Network Layer: 5-70
Traffic engineering: difficult with traditional routing
5
3
2 v w 5

u 2 1
3 z
1
2
x 1 y

Q: what if network operator wants to split u-to-z

traffic along uvwz and uxyz (load balancing)?
A: can’t do it (or need a new routing algorithm)

Network Layer: 5-71

Traffic engineering: difficult with traditional routing
5
3
2 v w 5

u 2 1
3 z
1
2
x 1 y

Q: what if w wants to route blue and red traffic differently from w to z?

A: can’t do it (with destination-based forwarding, and LS, DV routing)
We learned in Chapter 4 that generalized forwarding and SDN can
be used to achieve any routing desired
Network Layer: 5-72
 Software defined networking (SDN)
4. programmable routing
access
control
… load
balance
3. controlplane functions
external to data-plane
control switches
applications Remote Controller

control
plane

data
plane

CA 2. control, data
CA CA CA CA
plane separation

1: generalized “flow-based”
forwarding (e.g., OpenFlow)
Network Layer: 5-73
Software defined networking (SDN)
network-control applications
Data-plane switches: …
routing
▪ fast, simple, commodity switches load
access
implementing generalized data-plane control balance
forwarding (Section 4.4) in hardware control
plane
▪ flow (forwarding) table computed, northbound API

installed under controller supervision SDN Controller

▪ API for table-based switch control (network operating system)

(e.g., OpenFlow)
southbound API
• defines what is controllable, what is not
▪ protocol for communicating with data
plane
controller (e.g., OpenFlow)
SDN-controlled switches
Network Layer: 5-74
Software defined networking (SDN)
network-control applications
SDN controller (network OS): …
routing
▪ maintain network state access load
information control balance

▪ interacts with network control northbound API

control
plane
applications “above” via
northbound API SDN Controller
(network operating system)
▪ interacts with network switches
“below” via southbound API southbound API

▪ implemented as distributed system data

for performance, scalability, fault- plane

tolerance, robustness
SDN-controlled switches
Network Layer: 5-75
Software defined networking (SDN)
network-control applications
network-control apps: …
routing
▪ “brains” of control: access load
implement control functions control balance

using lower-level services, API northbound API

control
plane
provided by SDN controller
SDN Controller
▪ unbundled: can be provided by (network operating system)
3rd party: distinct from routing
vendor, or SDN controller southbound API

data
plane

SDN-controlled switches
Network Layer: 5-76
Components of SDN controller
routing access load
control balance

interface layer to network Interface, abstractions for network control apps

control apps: abstractions API network

graph
RESTful
API
… intent

network-wide state statistics … flow tables

SDN
management : state of
networks links, switches,
Network-wide distributed, robust state management
controller
services: a distributed database Link-state info host info … switch info

communication: communicate OpenFlow … SNMP

between SDN controller and Communication to/from controlled devices
controlled switches

Network Layer: 5-77

OpenFlow protocol
▪ operates between controller, switch OpenFlow Controller
▪ TCP used to exchange messages
• optional encryption
▪ three classes of OpenFlow messages:
• controller-to-switch
• asynchronous (switch to controller)
• symmetric (misc.)
▪ distinct from OpenFlow API
• API used to specify generalized
forwarding actions

Network Layer: 5-78

OpenFlow: controller-to-switch messages
Key controller-to-switch messages OpenFlow Controller
▪ features: controller queries switch
features, switch replies
▪ configure: controller queries/sets
switch configuration parameters
▪ modify-state: add, delete, modify flow
entries in the OpenFlow tables
▪ packet-out: controller can send this
packet out of specific switch port

Network Layer: 5-79

OpenFlow: switch-to-controller messages
Key switch-to-controller messages OpenFlow Controller
▪ packet-in: transfer packet (and its
control) to controller. See packet-out
message from controller
▪ flow-removed: flow table entry deleted
at switch
▪ port status: inform controller of a
change on a port.

Fortunately, network operators don’t “program” switches by creating/sending

OpenFlow messages directly. Instead use higher-level abstraction at controller
Network Layer: 5-80
SDN: control/data plane interaction example
Dijkstra’s link-state
routing 1 S1, experiencing link failure uses
4 OpenFlow port status message to
network
graph
RESTful
API
… intent notify controller

statistics
3 … flow tables
2 SDN controller receives OpenFlow
message, updates link status info
Link-state info host info … switch info
2 3 Dijkstra’s routing algorithm
OpenFlow
… SNMP
application has previously registered
to be called when ever link status
changes. It is called.
1
4 Dijkstra’s routing algorithm
s2 access network graph info, link
s1
s4 state info in controller, computes
s3 new routes
Network Layer: 5-81
SDN: control/data plane interaction example
Dijkstra’s link-state
routing

4 5
network
graph
RESTful
API
… intent 5 link state routing app interacts
3 … with flow-table-computation
statistics flow tables component in SDN controller,
Link-state info host info … switch info
which computes new flow tables
2 needed
OpenFlow
… SNMP
6 controller uses OpenFlow to
install new tables in switches
1 that need updating
s2
s1
s4
s3
Network Layer: 5-82
OpenDaylight (ODL) controller
Traffic
Engineering Firewalling Load Balancing … Network Orchestrations and Applications
Northbound API

REST/RESTCONF/NETCONF APIs

Enhanced Basic Network Functions

Services
Topology Switch Stats
AAA … processing mgr. mgr.
Forwarding Host
… rules mgr. Tracker
Service Abstraction Layer:
config. and
operational data messaging Service Abstraction ▪ interconnects internal,
store Layer (SAL) external applications
… Southbound API and services
OpenFlow NETCONF SNMP OVSDB

Network Layer: 5-83

ONOS controller
Traffic
Engineering Firewalling Load Balancing … Network Applications

northbound
Northbound API
▪ control apps separate
REST API Intent abstractions, from controller
protocols
▪ intent framework: high-
hosts paths flow rules topology
level specification of
service: what rather
devices links statistics
ONOS than how
distributed
core ▪ considerable emphasis
on distributed core:
device link host flow packet southbound
abstractions, service reliability,
OpenFlow Netconf OVSDB protocols replication performance
Southbound API scaling

Network Layer: 5-84

SDN: selected challenges
▪ hardening the control plane: dependable, reliable, performance-
scalable, secure distributed system
• robustness to failures: leverage strong theory of reliable distributed
system for control plane
• dependability, security: “baked in” from day one?
▪ networks, protocols meeting mission-specific requirements
• e.g., real-time, ultra-reliable, ultra-secure
▪ Internet-scaling: beyond a single AS
▪ SDN critical in 5G cellular networks

Network Layer: 5-85

SDN and the future of traditional network protocols
▪ SDN-computed versus router-computer forwarding tables:
• just one example of logically-centralized-computed versus protocol
computed
▪ one could imagine SDN-computed congestion control:
• controller sets sender rates based on router-reported (to
controller) congestion levels

How will implementation of

network functionality (SDN
versus protocols) evolve?
Network Layer: 5-86
 Network layer: “control plane” roadmap
▪ introduction
▪ routing protocols
▪ intra-ISP routing: OSPF
▪ routing among ISPs: BGP
▪ SDN control plane
▪ Internet Control Message ▪ network management,
Protocol configuration
• SNMP
• NETCONF/YANG

Network Layer: 5-87

ICMP: internet control message protocol
▪ used by hosts and routers to
Type Code description
communicate network-level 0 0 echo reply (ping)
information 3 0 dest. network unreachable
3 1 dest host unreachable
• error reporting: unreachable host, 3 2 dest protocol unreachable
network, port, protocol 3 3 dest port unreachable
• echo request/reply (used by ping) 3 6 dest network unknown
3 7 dest host unknown
▪ network-layer “above” IP: 4 0 source quench (congestion
control - not used)
• ICMP messages carried in IP
8 0 echo request (ping)
datagrams 9 0 route advertisement
▪ ICMP message: type, code plus 10
11
0
0
router discovery
TTL expired
first 8 bytes of IP datagram causing 12 0 bad IP header
error
Network Layer: 4-88
Traceroute and ICMP
3 probes 3 probes

3 probes

▪ source sends sets of UDP segments to

stopping criteria:
destination
▪ UDP segment eventually
• 1st set has TTL =1, 2nd set has TTL=2, etc. arrives at destination host
▪ datagram in nth set arrives to nth router: ▪ destination returns ICMP
• router discards datagram and sends source “port unreachable”
ICMP message (type 11, code 0) message (type 3, code 3)
• ICMP message possibly includes name of ▪ source stops
router & IP address
▪ when ICMP message arrives at source: record RTTs
Network Layer: 4-89
 Network layer: “control plane” roadmap
▪ introduction
▪ routing protocols
▪ intra-ISP routing: OSPF
▪ routing among ISPs: BGP
▪ SDN control plane
▪ Internet Control Message
Protocol ▪ network management,
configuration
• SNMP
• NETCONF/YANG
Network Layer: 5-90
What is network management?
▪ autonomous systems (aka “network”): 1000s of interacting
hardware/software components
▪ other complex systems requiring monitoring, configuration,
control:
• jet airplane, nuclear power plant, others?

"Network management includes the deployment, integration

and coordination of the hardware, software, and human
elements to monitor, test, poll, configure, analyze, evaluate,
and control the network and element resources to meet the
real-time, operational performance, and Quality of Service
requirements at a reasonable cost."

Network Layer: 5-91

 Components of network management
Managed device:
Managing server: agent data equipment with manageable,
application, typically managing configurable hardware,
with network server/controller software components
managers (humans) in data managed device
the loop Data: device “state”
agent data configuration data,
Network agent data
operational data,
management managed device device statistics
protocol: used by managed device
managing server to query,
agent data
configure, manage device;
used by devices to inform agent data

managing server of data, managed device

events. managed device

Network Layer: 5-92

Network operator approaches to management
CLI (Command Line Interface)
• operator issues (types, scripts) direct to agent data
individual devices (e.g., vis ssh) managing
server/controller
SNMP/MIB data managed device

• operator queries/sets devices data

(MIB) using Simple Network agent data
Management Protocol (SNMP)
agent data
managed device
NETCONF/YANG managed device
• more abstract, network-wide, holistic
• emphasis on multi-device configuration agent data

management. agent data

• YANG: data modeling language managed device
• NETCONF: communicate YANG-compatible managed device

actions/data to/from/among remote devices

Network Layer: 5-93
SNMP protocol
Two ways to convey MIB info, commands:

managing data managing data

server/controller server/controller

request

response trap message

agent data agent data

managed device managed device

request/response mode trap mode

Network Layer: 5-94
SNMP protocol: message types

Message type Function

GetRequest manager-to-agent: “get me data”
GetNextRequest (data instance, next data in list,
GetBulkRequest block of data).

SetRequest manager-to-agent: set MIB value

Response Agent-to-manager: value, response

to Request
Trap Agent-to-manager: inform manager
of exceptional event

Network Layer: 5-95

SNMP protocol: message formats
Get/set header Variables to get/set
PDU Error
Request Error
message types 0-3 type Status Name Value Name Value ….
ID Index
(0-3) (0-5)

Trap header Trap info

PDU Trap
message type 4 type Enterprise Agent Type
Specific Time
Name Value ….
Addr code stamp
4 (0-7)

SNMP PDU

Network Layer: 5-96

SNMP: Management Information Base (MIB)
▪ managed device’s operational (and some configuration) data agent data

▪ gathered into device MIB module

• 400 MIB modules defined in RFC’s; many more vendor-specific MIBs
▪ Structure of Management Information (SMI): data definition language
▪ example MIB variables for UDP protocol:
Object ID Name Type Comments
1.3.6.1.2.1.7.1 UDPInDatagrams 32-bit counter total # datagrams delivered
1.3.6.1.2.1.7.2 UDPNoPorts 32-bit counter # undeliverable datagrams (no application at port)
1.3.6.1.2.1.7.3 UDInErrors 32-bit counter # undeliverable datagrams (all other reasons)
1.3.6.1.2.1.7.4 UDPOutDatagrams 32-bit counter total # datagrams sent
1.3.6.1.2.1.7.5 udpTable SEQUENCE one entry for each port currently in use

Network Layer: 5-97

NETCONF overview
▪ goal: actively manage/configure devices network-wide
▪ operates between managing server and managed network devices
• actions: retrieve, set, modify, activate configurations
• atomic-commit actions over multiple devices
• query operational data and statistics
• subscribe to notifications from devices
▪ remote procedure call (RPC) paradigm
• NETCONF protocol messages encoded in XML
• exchanged over secure, reliable transport (e.g., TLS) protocol

Network Layer: 5-98

NETCONF initialization, exchange, close
managing agent data
server/controller Session initiation,
capabilities exchange: <hello>
data

…
<rpc>
<rpc-reply>

…
…
<rpc>
<rpc-reply>

…
…
<notification>
…

…
<rpc>
<rpc-reply>
…

…
Session close: <close-session>
Network Layer: 5-99
Selected NETCONF Operations
NETCONF Operation Description
<get-config> Retrieve all or part of a given configuration. A device may have multiple
configurations.
<get> Retrieve all or part of both configuration state and operational state data.
<edit-config> Change specified (possibly running) configuration at managed device.
Managed device <rpc-reply> contains <ok> or <rpcerror> with rollback.
<lock>, <unlock> Lock (unlock) configuration datastore at managed device (to lock out
NETCONF, SNMP, or CLIs commands from other sources).
<create-subscription>, Enable event notification subscription from managed device
<notification>

Network Layer: 5-100

Sample NETCONF RPC message
note message id

change a configuration

change the running configuration

change MTU of Ethernet 0/0 interface to 1500

Network Layer: 5-101

YANG
▪ data modeling language used to specify managing data
server/controller
structure, syntax, semantics of
NETCONF network management data
NETCONF RPC message
• built-in data types, like SMI
<edit-config>
▪ XML document describing device, YANG-generated XML
</edit-config> YANG
capabilities can be generated from generated
YANG description
▪ can express constraints among data that
must be satisfied by a valid NETCONF agent data
configuration
• ensure NETCONF configurations satisfy
correctness, consistency constraints
Network Layer: 5-102
Network layer: Summary
we’ve learned a lot!
▪ approaches to network control plane
• per-router control (traditional)
• logically centralized control (software defined networking)
▪ traditional routing algorithms
• implementation in Internet: OSPF , BGP
▪ SDN controllers
• implementation in practice: ODL, ONOS
▪ Internet Control Message Protocol
▪ network management
next stop: link layer!
Network Layer: 5-103
Network layer, control plane: Done!
▪ introduction
▪ routing protocols
▪ link state
▪ distance vector
▪ intra-ISP routing: OSPF
▪ routing among ISPs: BGP
▪ network management,
▪ SDN control plane configuration
▪ Internet Control Message • SNMP
Protocol • NETCONF/YANG

Network Layer: 5-104

Additional Chapter 5 slides

Network Layer: 5-105

Distance vector: another example
cost to cost to
Dx() x y z x y z
x 0 2 7 x 0 2 3

from
from

y ∞∞ ∞ y 2 0 1 Dx(z) = min{cx,y+ Dy(z), cx,z+ Dz(z)}

z ∞∞ ∞ z 7 1 0
= min{2+1 , 7+0} = 3

cost to y
Dy() x y z 2 1
Dx(y) = min{cx,y + Dy(y), cx,z+ Dz(y)}
x ∞ ∞ ∞ = min{2+0 , 7+1} = 2 x z
7
from

y 2 0 1
z ∞∞ ∞

cost to
Dz() x y z
x ∞∞ ∞
from

y ∞∞ ∞
z 7 1 0
time Network Layer: 5-106
Distance vector: another example
cost to cost to cost to
Dx() x y z x y z x y z
x 0 2 7 x 0 2 3 x 0 2 3

from
from

y ∞∞ ∞ y 2 0 1

from
y 2 0 1
z ∞∞ ∞ z 7 1 0 z 3 1 0

cost to cost to cost to y

Dy() x y z x y z x y z 2 1
x ∞ ∞ ∞ x 0 2 7 x 0 2 3
x z
7
from

from
y 2 0 1 y 2 0 1

from
y 2 0 1
z ∞∞ ∞ z 7 1 0 z 3 1 0

cost to cost to cost to

Dz() x y z x y z x y z

x ∞∞ ∞ x 0 2 7 x 0 2 3
from

from
y 2 0 1 y 2 0 1
from

y ∞∞ ∞
z 7 1 0 z 3 1 0 z 3 1 0
time Network Layer: 5-107