Routing Protocols - Nyu

gascitytankΔίκτυα και Επικοινωνίες

28 Οκτ 2013 (πριν από 4 χρόνια και 11 μέρες)

78 εμφανίσεις

Internetworking Fundamentals

(Lecture #8)


Andres Rengifo

Copyright 2007

Routing Information Protocol
(RIPv1)



The Routing Information Protocol v1 (RIP v1) was one of
the first Distance Vector protocols developed to work on
the Internet during its early stages.




This routing protocol was used as the basis for many
other routing protocols that enhanced and optimized
RIP’s functionality. It is a protocol that is not scalable
and not very efficient on large enterprise entities.



Its convergence time is very long and can cause a
network to be out of reach for at least 5 minutes, which is
unacceptable in a production environment.

RIPv1 (Cont.)


How does a router know what networks or segments are located
around its infrastructure? The only way is for peer routers to send
updates to each other advertising what segments and networks are
directly connected to them.



These updates are passed along peer routers, which in turn pass
them to their peer, or neighbor routers until the entire topology is
covered. RIP v1 sends updates periodically (regular intervals) as
well as when there are changes on the topology. RIP v1 uses only
hop counts, as it only metric.



When a RIP router receives an update about a network that has
been added to the topology, the router updates its routing table and
increases the metric path value by one. The closest neighbor router
to that network will be considered as the next hop. RIP v1 only
understands the best route available on the network.

RIPv1 (Cont.)


RIP v1 updates are not incremental. This
means that when there is a change, additional
subnets advertised or some type of issue with
the network, the entire routing tables are
exchanged instead of just the route that
changed.



Link State protocols use incremental updates,
which make them more efficient routing
protocols.

RIPv1 (Cont.)


Since RIP v1 uses a Distance Vector Algorithm as its
main process, it suffers from counting to infinity issues.
In order to avoid this, RIP v1 prevents the routing loops
that counting to infinity creates by introducing a hop
count infinity value of 16.



This means that the network diameter or a network
packet can only traverse 15 routers or hops until it is
considered infinity. As a result, this makes RIP a non
-
scalable routing protocol that can only be used in small
venues. RIP also uses split horizon and hold down
mechanisms to prevent routing information

from creating
loops on the network.

RIPv1 (Cont.)


RIP v1 uses a set of timers (used for the hold down
mechanisms) which are the following:



Routing update timer: This timer is usually set to 30 seconds and
measures interval between periodic routing updates.



Route
-
timeout timer: This timer begins only when a route on a
routing table does not appear. The route is marked invalid but it
is retained in the table until the route is removed.



Route
-
flush timer: This timer is used to remove the invalid entry
off the routing table. The timer flushes out the invalid route.

RIPv1 (Cont.)


RIP v1 does not
support sub net
masks hence it is
considered a classful
routing protocol.



RIP v2 is an
enhancement to RIP
v1.

RIPv1 (Cont.)


The update timer is every 30 seconds. The route
-
timeout timer, which creates the
entry invalid, is 6 times the update timer or after 180 seconds. Hold down timer is
also 180 seconds and the route gets flushed after 240 seconds.



RA# show ip protocol


Routing Protocol is "rip"



Sending updates every 30 seconds, next due in 14 seconds



Invalid after 180 seconds; hold down 180, flushed after 240



Outgoing update filter list for all interfaces is not set



Incoming update filter list for all interfaces is not set



Redistributing: rip



Default version control: send version 1, receive any version



Interface Send Recv Key
-
chain



Loopback0 1 1 2



Loopback1 1 1 2



Serial0 1 1 2



Routing for Networks:



10.0.0.0



Routing Information Sources:



Gateway Distance Last Update



10.1.1.2 120 00:00:25



Distance: (default is 120)

RIPv1 (Cont.)


RIP updates are periodic as shown below from the point of view of both routers. Updates are done via broadcast address of 25
5.2
55.255.255.


RA#


RIP: received v1 update from 10.1.1.2 on Serial0


this is the IP address of RB interface



10.4.4.0 in 1 hop



10.3.3.0 in 1 hop


RIP: sending v1 update to 255.255.255.255 via Loopback0 (10.5.5.1)



Subnet 10.3.3.0, metric 2


this metric tells RA that there are two hops to this net



subnet 10.4.4.0, metric 2



subnet 10.1.1.0, metric 1



subnet 10.6.6.0, metric 1


10.5.5.0 net is not advertised to itself
-

Split Horizon


RIP: sending v1 update to 255.255.255.255 via Loopback1 (10.6.6.1)



subnet 10.3.3.0, metric 2



subnet 10.4.4.0, metric 2



subnet 10.1.1.0, metric 1



subnet 10.5.5.0, metric 1


RIP: sending v1 update to 255.255.255.255 via Serial0 (10.1.1.1)



subnet 10.6.6.0, metric 1



subnet 10.5.5.0, metric 1


RB#


RIP: received v1 update from 10.1.1.1 on Serial0


this is the IP address of RA interface



10.6.6.0 in 1 hop



10.5.5.0 in 1 hop


RIP: sending v1 update to 255.255.255.255 via Loopback0 (10.3.3.1)



subnet 10.5.5.0, metric 2



subnet 10.6.6.0, metric 2



subnet 10.1.1.0, metric 1



subnet 10.4.4.0, metric 1


RIP: sending v1 update to 255.255.255.255 via Loopback1 (10.4.4.1)



subnet 10.5.5.0, metric 2



subnet 10.6.6.0, metric 2



subnet 10.1.1.0, metric 1



subnet 10.3.3.0, metric 1


RIP: sending v1 update to 255.255.255.255 via Serial0 (10.1.1.2)



subnet 10.4.4.0, metric 1



subnet 10.3.3.0, metric 1

RIPv1 (Cont.)


If you look at the routing tables created after these updates are cached you will see
that every network directly or not directly connected is listed on the table. The
process also tells the router the next hop interface that needs to be used to reach that
particular network. The command, “show ip route” details the table.



RA# show ip route


Codes: C
-

connected, S
-

static, I
-

IGRP, R
-

RIP, M
-

mobile, B
-

BGP



D
-

EIGRP, EX
-

EIGRP external, O
-

OSPF, IA
-

OSPF inter area



E1
-

OSPF external type 1, E2
-

OSPF external type 2, E
-

EGP



i
-

IS
-
IS, L1
-

IS
-
IS level
-
1, L2
-

IS
-
IS level
-
2, *
-

candidate default



U
-

per
-
user static route


Gateway of last resort is not set



10.0.0.0/24 is sub netted, 5 subnets


R 10.3.3.0 [120/1] via 10.1.1.2, 00:00:04, Serial0

[120/1] = admin distance/1
hop


R 10.4.4.0 [120/1] via 10.1.1.2, 00:00:04, Serial0


C 10.1.1.0 is directly connected, Serial0


admin distance = 0


C 10.6.6.0 is directly connected, Loopback1


C 10.5.5.0 is directly connected, Loopback0

RIPv1 (Cont.)


The whole process from beginning to end (from the
network marked as possibly down) and route for
10.5.5.0/24 no longer available took 600 seconds or 180
+ 180 + 240 as specified by the protocol.



This is about 10 minutes of convergence for a network
that has only two routers connected via a high
-
speed line
and six networks. Imagine how long it would take for a
network that had many more routers.



It would be unacceptable in a production environment.
There are ways to manipulate the timers to reduce the
convergence time but this has to be done with a great
deal of care.

Interior Gateway Routing Protocol
(IGRP)


The Interior Gateway Routing Protocol (IGRP) is another
protocol based on Distance Vector algorithms. It is a
Cisco proprietary routing protocol. It is also a classful
routing protocol and can be thought of RIP on “steroids”.
IGRP is a more robust routing protocol and can be used
within an Autonomous System (AS). This routing
protocol is considered an Interior Gateway Protocol.



IGRP has more parameters taken into consideration with
respect to calculating its metrics. The five parameters in
question are bandwidth, delay, reliability, load, and MTU
size.

IGRP (Cont.)


The metric that IGRP uses is called a composite metric because it
includes all five parameters. These parameters are taken into
consideration when calculating the mathematics to provide a metric
for an IGRP router.



For example, reliability and load can take on values from 1 to 255;
bandwidth can take on different speed values from very low bandwidths
like 1200 bits per second (bps) to 10 Gbps while delay can take on
values from 1 to 224 measured in microseconds. The network
administrator can actually manipulate the metrics by changing the
values of these five parameters. These changes are sometimes
necessary to influence routing paths to be specifically selected but the
general rule is that the only values that should be manipulated are
bandwidth and delay statements. Cisco suggests leaving reliability,
load, and MTU size alone.

IGRP (Cont.)


Below is the actual formula that is used to calculate IGRP metrics on
a network. Routers that run this routing protocol will always use this
formula to calculate a metric to a specific network destination.



MetricIGRP = K1*BIGRP + {(K2* BIGRP)/ (256
-
L)} + K3*DIGRP +
K5/[R+K4]



Where BIGRP is the minimum bandwidth on the outgoing interfaces
towards the final destination scaled by 10,000,000 kbps or
10000000/Bmin. DIGRP is equal to the sum of delays from the
outgoing interfaces divided by 10. Constants are usually by default
equal to K1 = K3 = 1 and K2 = K4 = K5 = 0, which reduces the
formula to:



MetricIGRP = K1*BIGRP + K3*DIGRP

IGRP (Cont.)

IGRP (Cont.)


In order to calculate the metrics from RA to a network behind RB
(10.3.3.0/24), let us look at the path a packet will take to get from RA to
segment 10.3.3.0/24. Packet destined to 10.3.3.0 will route out interface
serial 0 of RA and enter RB on interface serial 0 and route out interface
Loop back 0 to 10.3.3.0/24 network. Taking into consideration only the
outbound parameters as specified by the protocol, you have:



RA

out Serial 0


in Serial 0

RB

out Loop back 0


10.3.3.0/24


Bandwidth of serial 0 on RA as shown below is 1544 Kbits.


Delay of serial 0 on RA as shown below is 20000 μsecs


Bandwidth of Loopback 0 on RB as shown below is 8000000 Kbits.


Delay of Loopback 0 on RB as shown below is 5000 μsecs.


Having this information, you can now calculate the metric from RA to destination
network 10.3.3.0/24 as follows:


MetricIGRP = K1*BIGRP + K3*DIGRP



MetricIGRP = 1*(10000000/1544 Kbps) + 25000 μsecs/10 = 6477 + 2500 =
8976.

IGRP (Cont.)


Now, from RA, issue command, “show ip route 10.3.3.0” and
compare to see if the mathematics make sense:


RA# show ip route 10.3.3.0


Routing entry for 10.3.3.0/24



Known via "igrp 1000", distance 100, metric 8976



Redistributing via igrp 1000



Advertised by igrp 1000 (self originated)



Last update from 10.1.1.2 on Serial0, 00:00:38 ago



Routing Descriptor Blocks:



* 10.1.1.2, from 10.1.1.2, 00:00:38 ago, via Serial0



Route metric is 8976, traffic share count is 1



Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit



Reliability 255/255, minimum MTU 1500 bytes



Loading 1/255, Hops 0

IGRP (Cont.)


RA# show ip route


Codes: C
-

connected, S
-

static, I
-

IGRP, R
-

RIP, M
-

mobile, B
-

BGP



D
-

EIGRP, EX
-

EIGRP external, O
-

OSPF, IA
-

OSPF inter area



E1
-

OSPF external type 1, E2
-

OSPF external type 2, E
-

EGP



i
-

IS
-
IS, L1
-

IS
-
IS level
-
1, L2
-

IS
-
IS level
-
2, *
-

candidate default



U
-

per
-
user static route


Gateway of last resort is not set



10.0.0.0/24 is sub netted, 5 subnets


C 10.5.5.0 is directly connected, Loopback0


I 10.3.3.0 [100/8976] via 10.1.1.2, 00:00:56, Serial0


admin dist=100, metric=8976


I 10.4.4.0 [100/8976] via 10.1.1.2, 00:00:56, Serial0


C 10.1.1.0 is directly connected, Serial0


C 10.6.6.0 is directly connected, Loopback1



IGRP gives the network much more flexibility and reliability by permitting multi
-
path routing. If
router RA connects via RB and RC and both connections have identical metrics, the routing
mechanism can actually forward packets on a destination based (round robin) process or on a
packet per packet process. The routing table will actually show two equal metrics to the same
destination.

IGRP (Cont.)


Below you can see the updates that are sent between routers in a periodic matter.


RA#


IGRP: sending update to 255.255.255.255 via Loopback0 (10.5.5.1)



subnet 10.3.3.0, metric=8976



subnet 10.4.4.0, metric=8976



subnet 10.1.1.0, metric=8476



subnet 10.6.6.0, metric=501


IGRP: sending update to 255.255.255.255 via Loopback1 (10.6.6.1)



subnet 10.5.5.0, metric=501



subnet 10.3.3.0, metric=8976



subnet 10.4.4.0, metric=8976



subnet 10.1.1.0, metric=8476


IGRP: sending update to 255.255.255.255 via Serial0 (10.1.1.1)



subnet 10.5.5.0, metric=501



subnet 10.6.6.0, metric=501


IGRP: received update from 10.1.1.2 on Serial0



subnet 10.4.4.0, metric 8976 (neighbor 501)



subnet 10.3.3.0, metric 8976 (neighbor 501)

IGRP (Cont.)


Now assume that network 10.5.5.0/24 goes down. This is what happens to the routing updates:



RB# show ip route 10.5.5.0


Routing entry for 10.5.5.0/24



Known via "igrp 1000", distance 100, metric 4294967295 (inaccessible)



Redistributing via igrp 1000



Advertised by igrp 1000 (self originated)



Last update from 10.1.1.1 on Serial0, 00:02:26 ago



Hold down timer expires in 135 secs



RB# show ip route 10.5.5.0


Routing entry for 10.5.5.0/24



Known via "igrp 1000", distance 100, metric 4294967295 (inaccessible)



Redistributing via igrp 1000



Advertised by igrp 1000 (self originated)



Last update from 10.1.1.1 on Serial0, 00:02:50 ago



Hold down timer expires in 111 secs



After some time,



RB#sh ip route 10.5.5.0


Routing entry for 10.5.5.0/24



Known via "igrp 1000", distance 100, metric 4294967295 (inaccessible)



Redistributing via igrp 1000



Advertised by igrp 1000 (self originated)



Last update from 10.1.1.1 on Serial0, 00:04:41 ago



Hold down timer expires in 0 secs

IGRP (Cont.)


Gateway of last resort is not set



10.0.0.0/8 is sub netted, 5 subnets


I 10.5.5.0/24 is possibly down,



routing via 10.1.1.1, Serial0


I 10.6.6.0 [100/8976] via 10.1.1.1, 00:00:34, Serial0


C 10.1.1.0 is directly connected, Serial0


C 10.4.4.0 is directly connected, Loopback1


C 10.3.3.0 is directly connected, Loopback0


After a while, 630 seconds, the route is flushed out of the routing tables. Convergence takes very long as well.


IGRP: sending update to 255.255.255.255 via Loopback0 (10.3.3.1)



subnet 10.6.6.0, metric=8976



subnet 10.1.1.0, metric=8476



subnet 10.4.4.0, metric=501


IGRP: sending update to 255.255.255.255 via Loopback1 (10.4.4.1)



subnet 10.6.6.0, metric=8976



subnet 10.1.1.0, metric=8476



subnet 10.3.3.0, metric=501



subnet 10.3.3.0, metric=501



subnet 10.4.4.0, metric=501





RB# show ip route 10.5.5.0


% Subnet not in table


If you check the router’s routing table, network 10.5.5.0 that was possibly down it will be no longer listed.


RB# show ip route


Codes: C
-

connected, S
-

static, I
-

IGRP, R
-

RIP, M
-

mobile, B
-

BGP



D
-

EIGRP, EX
-

EIGRP external, O
-

OSPF, IA
-

OSPF inter area



E1
-

OSPF external type 1, E2
-

OSPF external type 2, E
-

EGP



i
-

IS
-
IS, L1
-

IS
-
IS level
-
1, L2
-

IS
-
IS level
-
2, *
-

candidate default



U
-

per
-
user static route


Gateway of last resort is not set



10.0.0.0/8 is sub netted, 4 subnets


I 10.6.6.0 [100/8976] via 10.1.1.1, 00:00:29, Serial0


C 10.1.1.0 is directly connected, Serial0


C 10.4.4.0 is directly connected, Loopback1


C 10.3.3.0 is directly connected, Loopback0

Hot Standby Routing Protocol
(HSRP)



The Hot Standby Routing Protocol (HSRP)
protocol is a Cisco proprietary protocol. It
is meant to be a redundant routing
protocol that uses an active and standby
set of routers meant to provide users with
transparent connectivity to a network
should the active router have any issues.

HSRP (Cont.)

HSRP (Cont.)


Both of these routers connected to the same user
segment share one IP address (HSRP IP address) and
MAC address which is used by hosts as a default
gateway or next hop router. The virtual IP address and
MAC address is “tied” to the active router, which will act
as the next, hop router for the local users.



Both active and standby HSRP routers exchange “hello”
packets with each other including parameters such as
group number, priority, virtual IP address, etc between
each other. These hello packets once again use
multicast groups specific for HSRP to exchange this
information.

HSRP (Cont.)


A Group number is necessary as there can be
multiple routers on the same segment that
belong to different HSRP processes.



It is also used to determine which routers should
participate on that specific HSRP process.



Priority is necessary to determine which of the
two or more routers under the same group
number serving a specific segment should be
selected as the active router.

HSRP (Cont.)


An active router is selected when the priority of that router is higher than the
others under the same group number. Virtual IP addresses are the
addresses used to create the illusion to the users that there is only one
device acting as the next hop router.



Hello packets or keepalive packets are exchanged every three seconds.
During those three seconds, each router exchanges all the parameters
mentioned above. Should there be a problem with the active router, which
caused an update to be missed after three seconds, a second timer begins
where the HSRP process will wait at least three times the update timer, or
10 seconds before a standby router becomes the active one.



When this happens, the standby router begins to route traffic as it
recognizes itself to have a higher priority. The standby router starts
advertising to other HSRP routers under the same group number that it is
now the new “active” router, the virtual IP and MAC address “shift” over to
that router and connectivity continues.

HSRP (Cont.)


HSRP also has a way to detect other uplinks connected locally that can be
experiencing issues, which could prevent packets from leaving off towards
the network. If there is no issue with the local segment, packets are always
going to be routed to the active router. But if the active router has an uplink
(another interface connecting other networks) that goes down or has issues,
packets will not be able to route out towards the destination hence these
packets need to be able to re
-

route without having to afford a long down
time for the user.



Therefore, local interfaces where user segments attached can be configure
to keep track of how the uplinks of those routers towards the rest of the
network are behaving. If there are any issues detected where the active
router knows that the uplink to the next network is having problems, tracking
will instigate the updating between active and standby and will cause the
HSRP process to fail over towards the standby router. This means that
traffic gets re
-

routed to the standby router until the uplink on the active
router that was having problems or that was down is fixed. Tracking is
important as it provides the extra redundancy required for multiple user
segments.