7207440349

Protokół RIPvl

(FD necwoRKeRS

Protokół RIPvl

Trasa przestaje być używana do transmisji danych i zostaje usunięta z tablicy routingu

Działanie liczników protokołu RIP

Ostatnia

informacja o sieci przed dłuższą

awarią. -^

(FD necwoRKeRS

R3# show ip protocols | include 30|180

Scnding updates cvcry 30 scconds, ncxt duc in 28 scconds Invalid aftcr 180 scconds, hołd down 180, flushcd after 240 R3#

Tras zostaje oznaczona w tablicy routingu jako „possibły down”, ale nadal używana jest do transmisji danych. ■

Działanie liczników protokołu RIP

180 sekund    60 sekund

UPDATE - zegar aktualizacji (domyślnie 30 sekund): definiuje co ile router wysyła informacje RIP.

INVALID - zegar unieważniania (domyślnie 180 sekund): resetowany po każdym otrzymaniu informacji o sieci, jeżeli w czasie tym nie otrzymamy kolejnej aktualizacji dla danej trasy, to jest ona oznacza jako „possibly down" i uruchamiany jest licznik HOŁD DOWN.

HOŁD DOWN - zegar wstrzymania (domyślnie 180 sekund): uruchamiany, gdy sieć stanie się niedostępna, czas w którym router nie akceptuje informacji o tej sieci, router ogłasza tą sieć z metryką 16 na wszystkich interfejsach.

FLUSH - zegar usuwania tras (domyślnie 240 sekund):

resetowany po każdym otrzymaniu informacji o sieci, stąd jest to domyślnie INVALID + 60 sekund,

po tym czasie sieć zostaje całkiem usunięta z tablicy routingu.

Protokół RIPv2

INVALID

Po usunięciu trasy z tablicy routingu, router ponownie będzie akceptował każdą wysiana do niego trasę do tej sieci.

Po około 180 sekundach trasa zostaje oznaczona jako Jnoccessible", ole nodal jest używana do routingu pakietów.

INVALID około 180 sekund

240 sekund

FLUSH

FLUSH około 240 sekund

Czas od ostatniego otrzymania    60 sekund

informacji o trasie.    *

Licznik INVALIDI FLUSH startuje w tym samym czasie.

UWAGA

W niektórych starszych wersjach Cisco IOS router może w czasie HOŁD DOWN akceptować tylko trasy lepsze lub takie same. Nie akceptuje tras gorszych.

Nie akceptujemy informacji o tej sieci i ogłaszamy z metrykę 16.

180 sekund | HOŁD DOWN

Gdy sieć zostanie usunięta z tablicy routingu, to też przestaje być dla niej liczony HOLO DOWN.

© 2016 networkers.pl Sp. z o.o. Ali rights reserved.

Po otrzymaniu informacji o sieci, wszystko zaczyna się od początku.

(N) necwoRKeRS

UWAGA

W niektórych starszych wersjach Cisco IOS router może w czasie HOŁD DOWN akceptować tylko trasy lepsze lub takie same. Nie akceptuje tros gorszych.

Razem z usunięciem trasy przestaje być liczony dla Sieci licznik HOŁD DOWN. Dzięki temu, kolejna aktualizacja o sieci zostaje    —Z.

zaakceptowana. -

HOŁD DOWN około 60 sekund

Informacjc o sieci znowu przychodzą. -

Działa dla tej sieci licznik HOŁD DOWN, stąd RIP nie akceptuje informacji (return tode 181

Trasa została dodana do tablicy routingu.

•Aug 5 12:24:26.686: RT: updating rip 192.168.2.0/24 (0x0)    :

via 192.168.23.2 GiO/0/0    0 1048578

R3# show ip route 192.168.2.0

Routing entry for 192.168.2.0/24

Known via "rip“, distance 120, metric 1 Redistributing via rip

Last update from 192.168.23.2 on GigabitEthernetO/O/O, 00:03:06 ago Routing Descriptor Blocks:

* 192.168.23.2, from 192.168.23.2,[00:03:06 ago,jvia GigabitEthernetO/0/0 Route metric is 1, traffic share count is 1

R3#

•Aug 5 12:27:35.560: RT: delete route to 192.168.2.0 via 192.168.23.2, rip metric (120/1) •Aug 5 12:27:35.560: RT: no routes to 192.168.2.0, entering holddown R3# show ip route 192.168.2.0 Routing entry for 192.168.2.0/24

Known via “rip”, distance 120, metric 4294967295 |(inaccessible)!

Redistributing via rip

Last update from 192.168.23.2 on GigabitEthcrnctO/O/O. 00:03:14 ago Iłłold down timer expires in 174 secs|

R3#

•Aug 5 12:28:18.267: RT: updating rip 192.168.2.0/24 (0x0)    :

via 192.168.23.2 GiO/0/0    0 1048578

•Aug 5 12:28:18.268: RT: rib update return codę: 18 R3#

R3# show ip route 192.168.2.0

Routing entry for 192.168.2.0/24

Known via "rip”, distance 120, metric 4294967295 [(inaccessible)

Redistributing via rip

Last update from 192.168.23.2 on GigabitEthernetO/O/O. 00:03:59 ago Hołd down timer expires in 129 secs|

R3#

•Aug 5 12:28:35.561: RT: delete network route to 192.168.2.0/24 •Aug 5 12:28:46.946: RT: updating rip 192.168.2.0/24 (0x0)    :

via 192.168.23.2 GiO/0/0    0 1048578

•Aug 5 12:28:46.946: RT: add 192.168.2.0/24 via 192.168.23.2, rip metric (120/1)

Protokół RIPvl

RIPvl - obsługa sieci nieciągłych i automatyczna sumaryzacja

Na granicach sieci głównych protokół RIP dokonuje automatycznej sumaryzacji podsieci do adresu sieci, jaki wynika z klasy adresowej. W związku z tym, obsługa podsieci w RIP zamyka się do obszaru sieci głównej (klasowej), który musi być ciągły. Klasowe protokoły routingu nie wspierają sieci nieciągłych, czyli przedzielenia inną siecią.

Rozsyłanie informacji na granicy sieci głównych jest zawsze klasowe.

W przypadku podziału sieci głównej na podsieci wymagane jest stosowanie FLSM.

| Klasa |    1 oktet | Bity sieci/hosta |

|    A    |    000-127    |    N.H.H.H    |

|    B    I    128-191    I    N.H.H.H    |

|    C    I    192-22)    I    N.H.H.H    I

(FD necwoRKeRS

R2 ROUTING TABLE
Network	Next-Hop	Metric
10.0.12.0/24	£0/0	0
172.16.23.0/24	E0/1	0
172.16.2.0/24	E0/2	0
172.16.20.0/26	EO/3	0
172.16.3.0/24	172.16.23.3	1
192.168.1.0/24	10.0.12.1	1
192.168.1.0/24	172.16.23.3	1
192.168.2.0/24	10.0.12.1	1

© 2016 networkers.pl Sp. z o.o. Ali rights reserved.

Router R2 będzie równoważył obciążenie do sieci 192.168.1.0/24. Dochodzi do sumaryzacji i router R2 z dwóch stron otrzymuje informację o sieci 192.168.1.0/24.

W omawianym przypadku zakładamy, że włączony jest dzielony horyzont.

Warto zwrócić uwagę na to, jakie informacje router R2 wysyła przez jakie interfejsy oraz na zawartość jego tablicy routingu.

R3 ROUTING TA81E			172.16.2.0/24
Network	Next-Hop	Metric	Network Hops
172.16.3.0/24	E0/0	0	10.0.0.0 1
172.16.23.0/24	E0/1		192.168.1.0 2
192.168.1.64/26	E0/2	0	192.168.2.0 2
172.16.2.0/24	172.16.23.2	1	172.16.3.0 2
10.0.0.0/8	172.16.23.2	1	172.16.23.0 1
192.168.2.0/24	172.16.23.2	2

192.168.2.0/26

EO/2

© 2016 networkers.pl Sp. z o.o. Ali rights reserved.

Rl ROUTING TABLE
Network	Next-Hop	Metric
10.0.12.0/24	E0/0	0
192.168.1.0/26	E0/1	0
192.168.2.0/26	E0/2	0
172.16.0.0/16	10.0.12.2	1

Propagacja trasy domyślnej w RIPvl i RIPv2

Istnieje możliwość przesyłania trasy domyślnej w protokole RIP. Trasa ta musi istnieje w tablicy routingu routera, na którym włącza się jej propagacje.

Router(config)# ip route 0.0.0.0 0.0.0.0 NEXT-HOP Router(config-router)# default-information originate

Trasa domyślne przesyłana jest jako adres sieci O.O.O.O.

RIP: rccciycd vl update tron 172.16.23.2 on CigabitEthernetO/O/1 IO.O.O.O in 1 hops |

RIP: sending vl update to 2SS.2SS.2SS.2SS vla GigebUEthernetO/O/O (172.16.3.1) Rlg: b.uild update Wrięs I subr.ct O.O.O.O nctric 2 1

subnet 173.14.53.0 netric 1

RFC1058: „The RIP packo? formats do not distinguish among various types of address. Fields that are labeled "address" can contain any of the following:

host address subnet number network number 0, indicating a default route"

R2(config)# ip route O.O.O.O O.O.O.O 198.51.100.1 R2(config)# router rip R2(config-router)# nctwork 172.16.0.0 R2(config-router)# default-information ? originate Distribute a default route

R2(config-router)# default-information originate

Protokół RIPv2

R2# show ip route | bogiń Gateway

Gateway of last resort is 198.51.100.1 to nctwork O.O.O.O

S* 0.0.0.0/0 (1/0] via 198.51.100.1

172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks R    172.16.3.0/24 (120/11 via 172.16.23.3, 00:00:23, GigabitEthernetO/O/l

C    172.16.23.0/24 is directly connected, GigabitEthcrnctO/0/1

L    172.16.23.2/32 is directly connccted, GigabitEthcrnct0/0/l

198.51.100.0/24 is variably subnetted, 2 subnets, 2 masks C    198.51.100.0/24 is directly connected, GigabitEthernetO/0/0

Ł    198.51.100.2/32 is directly connected, GigabitEthernetO/0/0

R2#

necwoRKeRS

Protokół RIPv2

R3# show ip route | begin Gateway

Gateway of last resort is 172.16.23.2 to nctwork O.O.O.O

R* 0.0.0.0/0 (120/1] via 172.16.23.2, 00:00:10, GigabitEthernetO/0/1 172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks C    172.16.3.0/24 is directly connected, GigabitEthernetO/0/0

L    172.16.3.1/32 is directly connected, GigabitEthcrnctO/0/0

C    172.16.23.0/24 is directly connected, GigabitEthernet0/0/l

L    172.16.23.3/32 is directly connected, GigabitEthernet0/0/l

R3#

E0/0 172.16.3.0/24

SIEĆ WEWNĘTRZNA

ŚWIAT

networks we build

WORK

RIPv2 obsługuje sieci nieciągłe

Na granicy dwóch różnych sieci klasowych protokół RIPv2 dokonuje automatycznej sumaryzacji do adresu klasowego.

R2# traccroutc 192.168.0.34 numeric

Type escape sequence to abort.

Tracing the route to 192.168.0.34

VRF info: (vrf in name/id, vrf out name/id)

1    10.0.0.1 0 mscc 1 mscc 0 mscc

2    192.168.0.34 1 msec 1 msec 1 msec

R2# traceroute 192.168.0.128 numeric ttl 1 4 Type escape sequence to abort.

Tracing the route to 192.168.0.128

VRF info: (vrf in name/id, vrf out name/id)

1    10.0.0.1    1    msec    0    msec    1    msec

2    10.0.0.2    1    msec    1    msec    1    msec

3    10.0.0.1    0    msec    0    msec    1    msec

4    10.0.0.2    1    mscc    1    mscc    1    mscc

R2#

_(FD necwoRKeRS

•Aug 10 05:54:07: RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0/0/l (192.168.0.33)

•Aug 10 05:54:07: RIP: build update entries •Aug 10 05:54:07:    10.0.0.0/8 via O.O.O.O, metric 1, tag 0

•Aug 10 05:54:07:    192.168.0.0/24 via O.O.O.O, metric 2, tag 0

•Aug 10 05:54:22: RIP: sending v2 update to 224.0.0.9 via GigabitEthernetO/0/0

(10.0.0.1)

•Aug 10 05:54:22: RIP: build update entries

•Aug 10 05:54:22:    192.168.0.0/24 via O.O.O.O, metric 1, tag 0

Rl# show ip inter brief | exclude unassigned Interface    IP-Address    OK?    Method    Status

GigabitEthcrnctO/O/O    10.0.0.1    YES    manuał    up

GigabitEthernet0/0/l    192.168.0.33    YES    manuał    up

Rl# show ip route | begin Gateway Gateway of last resort is not set

10.0. 0.0/8 is variably subnetted, 2 subnets, 2 masks

C    10.0.0.0/30 is directly connected, GigabitEthernetO/0/0

L    10.0.0.1/32 is directly connected, GigabitEthernetO/0/0

192.168.0. 0/24 is variably subnetted, 3 subnets, 3 masks

R    192.168.0.0/24 (120/1) via 10.0.0.2, 00:00:15, GigabitEthcrnetO/0/0

C    192.168.0.32/27 is directly connected, GigabitEthernet0/0/l

L    192.168.0.33/32 is directly connected, GigabitEthernet0/0/l

Rl#

Protocol

up

up

© 2016 networkers.pl Sp. z o.o. Ali rights reserved.

© 2016 networkers.pl Sp. z o.o. Ali rights reseryed.

(FD necwoRKeRS

Protokół RIPv2

(FD necwoRKeRS

Warto zastanowić się nad tym, co by było, gdyby pomiędzy Rl i R2 był jeszcze jeden router i połączenie w adresacji należącej do sied 10.0.0.4/30.

Domyślnie dojdzie do takiego samego efektu, jak w przypadku zastosowania RIPvl.

W RIPv2 mamy możliwoić zmiany takiego zachowania, tak aby sieć działała prawidłowo.

Protokół RIPv2

| *Aug 11 12:33:41.331: RIP: ignored v2 packet from 10.0.23.2 (invalid authentication)

Diagnoza problemów z uwierzytelnieniem

Do diagnozy problemów z uwierzytelnieniem w protokole RIPv2 najlepiej posłużyć się debugiem:

Router# (no) debug ip rip

Niezgodność trybu uwierzytelnienia lub został on ustawiony tylko z jednej strony.

Tryb Keyed MD5, ale nie zgadza się wartość lub ID klucza.

Tryb Keyed MD5 o zgodnej konfiguracji.

Tryb Plain Text o zgodnej konfiguracji.

Tryb Plain Text, ale nie zgadza się wartość klucza.

Dodatkowo pomocne mogą być poleceia:

Router# show key Chain Router# show ip protocols

•Aug 11 12:35:35.515: RIP: received packet with MD5 authentication

•Aug 11 12:35:35.515: RIP: ignored v2 packet from 10.0.23.2 (invalid authentication)

•Aug 11 12:36:31.784: RIP: received packet with MD5 authentication

•Aug 11 12:36:31.784: RIP: reccivcd v2 update from 10.0.23.2 on GigabitEthcrnctO/O/O

•Aug 11 12:36:31.784:    10.0.2.0/24 via O.O.O.O in 1 hops

•Aug 11 12:38:45.845: RIP: received packet with text authentication ClscOClscO •Aug 11 12:38:45.845: RIP: received v2 update from 10.0.23.2 on GigabitEthernetO/0/0 •Aug 11 12:38:45.845:    10.0.2.0/24 via O.O.O.O in 1 hops

•Aug 11 12:40:10.323: RIP: rcccivcd packet with tcxt authentication ClscOClscO-123 •Aug 11 12:40:10.323: RIP: ignored v2 packet from 10.0.23.2 (invalid authentication)

R3# show key Chain

Key-chain RIP-KEY-CHAIN:

key 1 — text 'ClscOClscO"

accept lifetime (always valid) - (always valid) |valid now] send lifetime (always valid) - (always valid) [valid now) R3# show ip protocols | include Interface|GigabitEthernet

Interface    Send Recv Triggered RIP

GigabitEthernetO/0/0    22    No

GigabitEthernet0/0/l    22    No

R3#

Key-chain

RIP-KEY-CHAIN

nonę

Uwierzytelnienie w RIPv2 - RFC 2453/RFC 4822

Atakujący, wysyłając sfałszowane aktualizacje protokołu routingu może wprowadzić nieprawidłowy wpis do tablicy routingu i doprowadzić do: przekierowania ruchu na siebie (MiTM, omijanie ACL), unieruchomienia usług (DoS, pętle routingu, odrzucanie pakietów).

W implementacji Cisco Systems protokołu RIPv2 istnieje możliwość skonfigurowania uwierzytelnienia komunikatów za pomocą:

Plain Text (Type=0x0002) - otwartego tekstu,

Keyed MD5 (Type=0x0003) - hash z MD5 klucza i danych routingu.

W Keyed MD5 musi się zgadzać wartość klucza i ID klucza.

W Plain Text musi się zgadzać tylko wartość klucza.

Istnieje możliwość konfiguracji wielu kluczy o czasowej ważności.

O ile dokumnety RFC opisują także wykorzystanie HMAC-SHA, to nie jest nam znana jego implementacja u żadnego z producentów.

„At present, the following values aro possible: KEYED-MD5, HHAC-SHA-1, HMAC-SHA-256, HHAC-SHA-384, and HMAC-SHA-512.' - RFC 4822

O    1    2    3 3

01234567890123456789012345678901

Command (1) | Version (1)	-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-H unused
OkFFFF	| Authentication Type (2)
Authentication (16)
0 1 012345678901234!	2 3 56789012345678901
Conmand (1) | Version (1)	Routing Domain (2)
OxFFFP	| Authentication Type-0x0003
RIPv2 Packet Length	| Key ID | Auth Data Len
Sequence Number	(non-deereasing)
reserved	must be zero
reservcd	must be zero
(RIPv2 Packet Length - 24) bytes of Data
OkFFFF	| 0x0001
' Authentication Data (var. length; 16 bytes with Keyed MD5) t

Listy offsetowe i sterowanie ruchem

Protokół RIP umożliwia sterowanie ruchem na wielu ścieżkach, poprzez zastosowanie list offsetowych.

Służą one do zwiększania metryki odbieranych/wysyłanych tras.

Router(config-router)# offset ACL <in|out) OFFSET (INTERFACE]

ACL - określa dla jakich sieci należy zwiększyć metrykę (gdy jest 0, to metryka zwiększana jest dla wszystkich sieci), in | out - metryka zostanie zwiększana odpowiednio dla tras odbieranych lub wysyłanych,

OFFSET - wartość o jaką zostanie powiększona metryka wskazanych przez ACL tras,

INTERFACE - (opcjonalne) - lista offsetowa może działać globalnie lub być przypięta do wskazanego interfejsu.

Jeżeli dla danej sieci istnieje lista offsetowa interfejsu, to dla tej sieci globalna nie jest już przetwarzana. Lista na interfejsie ma priorytet nad listą globalną.

Można zdefiniować tylko jedną listę offsetową dla danego kierunku globalnie i per interfejs.

(FD necwoRKeRS

R3(config-router)# do show ip route | i 10.0.2.0

R    10.0.2.0/24 (120/1] via 10.0.23.2, 00:00:26, GigabitEthernetO/0/0

R3(config-router)# do show ip protocols | i routes R3(config-router)# offset ?

<0-99>    Access list of networks to apply offset (0 selects all networks)

<1300-1999> Access list of networks to apply offset (expanded rangę)

WORD    Access-list name

R3(config-router)# offset O ?

in Perform offset on incoming updates out Perform offset on outgoing updates

R3(config-router)# offset 0 in ?

<0-16> Offset

R3(config-router)# offset O in 5 GigabitEthernet 0/0/0 R3(config-router)# do show ip route | i 10.0.2.0

R    10.0.2.0/24 (120/1) via 10.0.23.2, 00:00:18, GigabitEthernetO/0/0

R3(config-router)# do show ip protocols | i routes

Incoming routes in GigabitEthernetO/0/0 will have 5 added to metric R3(config-router)# do show ip route | i 10.0.2.0

R    10.0.2.0/24 (120/6) via 10.0.23.2, 00:00:04, GigabitEthernetO/0/0

R3(conf ig-router)#

© 2016 networkers.pl Sp. z o.o. All rights reserved.

© 2016 networkers.pl Sp. z o.o. Ali rights reserved.

© 2016 networkers.pl Sp. z o.o. All rights reserved.

10.0.1.0/24