07 Rip

IT 605
Computer Networks
Routing Protocols
Prof . Anirudha Sahoo

KReSIT
IIT Bombay
Prof . Aniruddha sahoo, KReSIT, IIT Bombay Routing Protocols 7.1

Routing table structure (on
a host)
• Fields: destination, gateway, flags…
• Destination: can be a host address or

a network address. If the ‘H’ flag is set,
it is the host address
• Gateway: router/next hop IP address.

Sample routing table (on a
host)
Routing table at D
Destination Gateway Flags Refcnt Use Interface
140.252.13.65 140.252.13.35 UGH 0 0 eth0
127.0.0.1 127.0.0.1 UH 1 0 lo0
default 140.252.13.33 UG 0 0 eth0
SLIP
A .13.65 .13.66 B C D
.13.35 .13.33 .13.34
Ethernet 140.252.13
Routing table structure (on
a host)
• Flags
– U: route is up
– G: route is to a gateway. If flag is
not set, the destination is directly
connected
– H: route is to a host (complete host
address). If flag is not set, route is
to a network
• G flag differentiates between an
indirect route and a direct route
IP Forwarding table at a
router (with subnetting)
Subnet Subnet Next hop
number mask
128.96.34 255.255.2 Intf 0
.0 55.128
128.96.34 255.255.2 Intf 1
.128 55.128
128.96.33 255.255.2 R2
.0 55.0

IP Forwarding at a router
(with subnetting)
D = destination IP address
for each forwarding table entry
(subnetNumber, subnetMask, NextHop)
D1 = subnetMask & D
if (D1 == subnetNumber)
if (NextHop is directly connected)
deliver directly to the destination
else
deliver datagram to NextHop
router
endif
end for
IP Forwarding table at a
router (with CIDR)
NetMask/le Next hop
ngth
171.69.0.0 R1
/16
171.69.10. R2
0/24
C4.50.0.0/ R3
12

IP Forwarding at a router (with
CIDR)
Send the packet to the NextHop with
longest match
Example:
A packet with destination
171.69.10.5 comes, both entries 1
and 2 matches. But entry 2 is the
longest match, so it should be sent to
R2

Getting a datagram from
source to dest.
Dest. Net. next router Nhops

223.1.1 1
223.1.2 223.1.1.4 2
IP datagram: 223.1.3 223.1.1.4 2
misc source dest
data
fields IP addr IP addr A 223.1.1.1
• datagram remains 223.1.2.1

223.1.1.2
unchanged, as it 223.1.1.4 223.1.2.9
travels source to B
223.1.2.2
destination 223.1.1.3 223.1.3.27 E
• addr fields of 223.1.3.1 223.1.3.2
interest here
From Jim Kurose’s
Prof . Aniruddha sahoo, KReSIT, IIT Bombayslides
Routing Protocols 7.9
source to dest.
forwarding table
misc Dest. Net. next router Nhops
fields 223.1.1.1 223.1.1.3
data in A
223.1.1 1
223.1.2 223.1.1.4 2
Starting at A, send IP 223.1.3 223.1.1.4 2
datagram addressed
to B: A 223.1.1.1
• look up net. address of 223.1.1.2

223.1.2.1
B in forwarding table 223.1.1.4 223.1.2.9

• find B is on same net. as B 223.1.2.2
A 223.1.1.3 223.1.3.27 E
• link layer will send 223.1.3.1 223.1.3.2
datagram directly to B
inside link-layer frame
– B and A areFromdirectly
Jim Kurose’s slides
connected
source to forwarding
dest. table
misc Dest. Net. next router Nhops
fields 223.1.1.1 223.1.2.2
data in A
223.1.1 1
223.1.2 223.1.1.4 2
Starting at A, dest. E: 223.1.3 223.1.1.4 2
• look up network
address of E in A 223.1.1.1
forwarding table 223.1.2.1
223.1.1.2
• E on different network 223.1.1.4 223.1.2.9
– A, E not directly B
223.1.2.2
attached 223.1.1.3 223.1.3.27 E
• routing table: next hop 223.1.3.1 223.1.3.2
router to E is 223.1.1.4
• link layer sends
datagram to router From Jim Kurose’s slides
Prof .223.1.1.4
Aniruddha sahoo, inside
KReSIT, IIT link-
Bombay Routing Protocols 7.11
layer frame
misc
source to dest.
data Dest. Net router Nhops interface
fields 223.1.1.1 223.1.2.2
223.1.1 - 1 223.1.1.4
223.1.2 - 1 223.1.2.9
Arriving at 223.1.4, 223.1.3 - 1 223.1.3.27
destined for
223.1.2.2 A 223.1.1.1
• look up network 223.1.1.2

223.1.2.1
address of E in router’s 223.1.1.4 223.1.2.9

forwarding table B
223.1.2.2
• E on same network as 223.1.1.3 223.1.3.27 E
router’s interface 223.1.3.1 223.1.3.2
223.1.2.9
– router, E directly
attached
From Jim Kurose’s slides
•
Proflink layer
. Aniruddha sahoo,sends
KReSIT, IIT Bombay Routing Protocols 7.12
datagram to 223.1.2.2
Routing in packet networks
• Data packet are required to be routed

from source to destination in a packet
switched network.
• Each node in the network requires “routing
table” for packet routing
• Routing tables are created by routing
protocol
Any routing protocol must communicate

global topology information to each
routing element to allow it to make local
routing decision.
• Routing protocol updates routing table
Routing protocol
•
requirements
Minimizing route table space
– Node memory related issue
• Minimizing control message
– Overhead in bandwidth
• Robustness
– Retain its correctness in dynamic situation.
Should be free of loops, black holes.
• Using optimal paths (optimality)
– Choosing the best path ( in terms of some
metrics)
• Stability
– Free of oscillations
• Fairness
– Should take the complete topology while
computing the path
• Prof
Efficiency
. Aniruddha sahoo, KReSIT, IIT Bombay Routing Protocols 7.14
–
Design Choices
• Centralized versus Distributed routing
– Centralized: one node collects information
and then installs the routing information in
all nodes
– Distributed: all nodes co operate to form
the rooting table
• Source based versus hop by hop
– Source routing: data packet contains the
hop list
• Dynamic Source Routing ( DSR in ad hoc
networks)
– Hop by hop: Each hop takes decision based
on its routing table about the next hop
( Distance vector routing
• Stochastic versus deterministic

Design Choices
• Single versus multiple path
– Router can use multiple paths for a
single destination
• Alternate path used when primary
path is down
• State dependent versus state
independent
– Routing dependent on the current
network state (e.g. link utilization)
– Static routing or state independent:
does not change with network state
change.
Distance Vector Routing
• Network Environment
– links and routers unreliable
– alternative paths scarce
– traffic patterns can change rapidly
• Two fundamental routing protocol in
packet switched network is Distance
Vector and Link State
Assumptions about the router:

• Knows address of each neighbor
• Knows cost of reaching each
Basic idea
• Node tells its neighbors its best idea
of distance to every other node in the
network
• Node receives these distance vectors
from its neighbors
• Updates its notion of best path to
each destination, and the next hop for
this destination

Basic idea
– Distance Table at each node contains
• best known ( at any point of time)
distance to each destination from the
node
– Routers exchange information
periodically of known distance metric
• Could be delay, queue length
– Triggered updates
– 1) whenever a link fails
– 2) Whenever a routing table entry changes

Example

Distance Vector Routing Algorithm
features
iterative:
• continues until no nodes exchange
info.
• self-terminating: no “signal” to
stop
asynchronous:
• nodes need not exchange
info/iterate in lock step.
distributed:
• each node communicates only
with directly-attached neighbors
Why does it work
• Each node knows its true cost to its
neighbors
• This information is spread to its
neighbors the first time it sends out
its distance vector
• Each subsequent dissemination
spreads the truth one hop
• Eventually, it is incorporated into
routing table everywhere in the
network
• Proof: Bellman andRouting
Prof . Aniruddha sahoo, KReSIT, IIT Bombay
Ford,
Protocols
1957 7.22
Problems with distance
• Count to infinity vector
• BC link goes down
• Before B could send this to
A,
• B receives update from A
which says (A,C),2
• B updates its table with
(B,C) 3
• On next update beacon B
send this to A. A updates its
distance to C as (A,C), 4, B
– This instability in the routing
table can can cause problem
until distance value reaches
to very high number
vector
– During this instable period, packets
may wander in loop, without ever
reaching to destination
– In case shortest path metric is hop
count, infinity can be set to MAX_HOP
+1. If the metrics is delay, the value
of infinity is difficult to know.
– Time required to reach upto infinity
depends on the exchange rate

vector
• Count to infinity problem:
– Some partial solution exists
– Split horizon with Poison reverse ( used in RIP)
• poison reverse: when a link goes down, in the next
update the route would contain infinity as the metric:
poison the route.
• Reasons for the count to infinity problem
– Asynchronous messaging
– History of updation is not considered
– In the previous example B does not know that the
path to C via A is through itself.

vector
• In Split Horizon:
– A router does not advertise the routing
information for a destination on the link
through which it acquired the information
– In last example: A never advertises routing
entry for C to B
– In RIP, an infinite distance is sent.
• Unfortunately, this works only in situation
where two adjacent routers in loop. Does
not work for 3 or higher no nodes forming
a loop.

• vector
Split Horizon does not work for 3 ( or more) way
counting
• Initially:
• At A: (A,D) 2, C A 1 B
• At B: (B,D) 2, C
• At C: (C,D) 1, D 1 1
• C-D goes down C
• C informs A with (C,D) inf
1
– -> (A,D) , inf D
• Before C could inform B, B updates A with (B,D) 2
– A changes to At A: (A,D) 3, B
• Next, A updates C with (A,D) 3
• C changes to C: (C,D) 4, A
• Next , C updates B with (C,D) 4
– B changes from [(B,D) 2, Protocols
C] to [(B,D) 5, C]7.27
Routing
vector
• Other approaches exist:
•Path vector
– DV carries path to reach each destination
•Triggered updates
– exchange routes on change, instead of on timer
– faster count up to infinity
•More complicated
– source tracing
» Distance vector carries the node
immediately preceding the destination

Source tracing
1 2 4
d n Prece
3 5 6
est ext ding
PATH = 1,2,4,5,6 1 - node
-
2 2 1
Get the same information
3 3 1
as path vector but with very
little additional space
4 2 2
5 2 4
6 2 5

RIP
• Distance vector algorithm
– Built on Distance vector routing
– Simple, suitable for small networks
• Distance metric: # of hops (max = 15
hops)
– poison reverse used to prevent ping-
pong loops (infinite distance = 16
hops)
• Distance vectors: exchanged every 30 sec
via Response Message (also called
advertisement)
• Each advertisement: route to up to 25
destination nets
RIP
z
w x y
A D B
C
Destination Network Next Router Num. of hops to dest.
w A 2
y B 2
z B 7
x -- 1
…. …. ....
Routing table in D
RIP: Link Failure and
Recovery
If no advertisement heard after 180 sec -->
neighbor/link declared dead
– routes via neighbor invalidated
– new advertisements sent to
neighbors
– neighbors in turn send out new
advertisements (if tables changed)
– link failure info propagates to entire
net
– poison reverse used
to prevent ping-7.32
Routing Protocols
pong loops (infinite distance = 16
RIP Table processing - 1
• RIP routing tables managed by
application-level process called routed
(daemon)
• advertisements sent in UDP packets (port
no 520) , periodically repeated

RIP Table processing - 2
Router: some-router.ac.in
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
127.0.0.1 127.0.0.1 UH 0 26492 lo0
192.168.2. 192.168.2.5 U 2 13 fa0
193.55.114. 193.55.114.6 U 3 58503 le0
192.168.3. 192.168.3.5 U 2 25 qaa0
224.0.0.0 193.55.114.6 U 3 0 le0
default 193.55.114.129 UG 0 143454
Three attached class C networks (LANs)

Router only knows routes to attached LANs
Default router used to “go up”
Route multicast address: 224.0.0.0
Loopback interface (for debugging)

Timers in RIP
• 3 different timer to support its
operation
– Periodic update timer (30 sec)
• Issues avoid synchronized update, can
overwhelm network
• Update randomized between 25 to 30
secs
– ( Sally Floyd, Van Jacobson, “Synchronization of periodic
routing update message” Computer Communication
Review 1993
– Invalid timer (180 sec)
• If for any routing entry, update is not
Prof . Aniruddha received
sahoo, KReSIT, IIT for
Bombay180 Routing
sec,Protocols
route is 7.35
Timers in RIP
– Garbage collection timer (120 sec)
• An invalid route in marked, not
immediately deleted.
• For next 120 secs the router advertise
this route to live neighbors with
distance infinity. This helps other
router purge entry for invalidated
route faster.
• This goes on for 120 secs, and after
that the routing entry is deleted.

RIP References
• RIPv1 defined in RFC 1058
• RIPv2 defined in RFC 1388
– uses IP multicasting (224.0.0.9);
VLSM etc

07 Rip

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

07 Rip

Hochgeladen von

Copyright:

Verfügbare Formate

IT 605

Prof . Anirudha Sahoo

Prof . Aniruddha sahoo, KReSIT, IIT Bombay Routing Protocols 7.1

• Fields: destination, gateway, flags…

• Destination: can be a host address or

• Gateway: router/next hop IP address.

Prof . Aniruddha sahoo, KReSIT, IIT Bombay Routing Protocols 7.2

Prof . Aniruddha sahoo, KReSIT, IIT Bombay Routing Protocols 7.5

Prof . Aniruddha sahoo, KReSIT, IIT Bombay Routing Protocols 7.7

Prof . Aniruddha sahoo, KReSIT, IIT Bombay Routing Protocols 7.8

Dest. Net. next router Nhops

• datagram remains 223.1.2.1

• look up net. address of 223.1.1.2

B in forwarding table 223.1.1.4 223.1.2.9

• link layer will send 223.1.3.1 223.1.3.2

• routing table: next hop 223.1.3.1 223.1.3.2

• look up network 223.1.1.2

address of E in router’s 223.1.1.4 223.1.2.9

• Data packet are required to be routed

Any routing protocol must communicate

• Stochastic versus deterministic

Assumptions about the router:

Prof . Aniruddha sahoo, KReSIT, IIT Bombay Routing Protocols 7.18

Prof . Aniruddha sahoo, KReSIT, IIT Bombay Routing Protocols 7.19

Prof . Aniruddha sahoo, KReSIT, IIT Bombay Routing Protocols 7.20

Prof . Aniruddha sahoo, KReSIT, IIT Bombay Routing Protocols 7.24

Prof . Aniruddha sahoo, KReSIT, IIT Bombay Routing Protocols 7.25

Prof . Aniruddha sahoo, KReSIT, IIT Bombay Routing Protocols 7.26

Prof . Aniruddha sahoo, KReSIT, IIT Bombay Routing Protocols 7.28

Prof . Aniruddha sahoo, KReSIT, IIT Bombay Routing Protocols 7.29

Prof . Aniruddha sahoo, KReSIT, IIT Bombay Routing Protocols 7.33

Three attached class C networks (LANs)

Prof . Aniruddha sahoo, KReSIT, IIT Bombay Routing Protocols 7.34

Prof . Aniruddha sahoo, KReSIT, IIT Bombay Routing Protocols 7.36

Prof . Aniruddha sahoo, KReSIT, IIT Bombay Routing Protocols 7.37

Das könnte Ihnen auch gefallen