OpenOSPFD kasutamine operatsioonisüsteemiga OpenBSD - Redigeerimiste ajalugu

Imre: /* Märkused */

2023-12-09T13:33:12Z

Märkused

←Vanem redaktsioon		Redaktsioon: 9. detsember 2023, kell 16:33
551. rida:		551. rida:

	pass quick on $if_ext proto ospf		pass quick on $if_ext proto ospf
		+
		+	===2023 sügis tähelepanekud===
		+
		+	Tundub, et kahe saidi vahel liikluse loksutamiseks ospf väga hästi ei sobi põhjusel, et ta töötab nö linkidega. Nt kui saidi tulemüüris on sisemine subnet avalik.subnet.ip.aadress/24, siis ei ole võimalik redistributega ip aadressi täpsusega. Mis iseenesest võimalik et kui nt on tulemüüris sellised võrguliidesed
		+
		+	<pre>
		+	obsd-fg-adala# cat /etc/hostname.vio{2,3,4,5}
		+	inet 192.168.65.2/29
		+	inet 192.168.65.10/29
		+	inet 192.168.65.18/29
		+	inet 192.168.65.26/29
		+	</pre>
		+
		+	siis nö kanooniline ospfd.conf redistribute oleks
		+
		+	<pre>
		+	..
		+	redistribute 192.168.65.0/29 set { metric 10 }
		+	redistribute 192.168.65.8/29 set { metric 10 }
		+	redistribute 192.168.66.16/29 set { metric 10 }
		+	redistribute 192.168.65.24/29 set { metric 10 }
		+	...
		+	</pre>
		+
		+	kuid samaväärne oleks öelda
		+
		+	<pre>
		+	..
		+	redistribute 192.168.65.0/27 set { metric 10 }
		+	...
		+	</pre>
		+
		+	See väljendab siiski asjaolu, et primaarselt juhindub ospf tulemüüris seadistatud võrguliidestest ja mitte redistribute direktiivist. St mis ei tööta oleks
		+
		+	<pre>
		+	..
		+	redistribute 192.168.65.2/32 set { metric 10 }
		+	redistribute 192.168.65.10/32 set { metric 10 }
		+	...
		+	</pre>

	===Kasulikud lisamaterjalid===		===Kasulikud lisamaterjalid===

Imre: /* Järjestikuliselt ühendatud arvutite ruuting */

2023-12-09T11:30:09Z

Järjestikuliselt ühendatud arvutite ruuting

←Vanem redaktsioon		Redaktsioon: 9. detsember 2023, kell 14:30
94. rida:		94. rida:

	ospfd protsess ei kuula nö tavalisel soketil (tcp/udp/jne), aga nn raw soketil, see paistab openbsd operatsioonisüsteemis sedasi		ospfd protsess ei kuula nö tavalisel soketil (tcp/udp/jne), aga nn raw soketil, see paistab openbsd operatsioonisüsteemis sedasi
		+
		+	* ei ole asjakohane kõneleda portidest nagu tcp ja udp puhul
		+	* ospf puhul peab kahe osalise vaheline liiklus toimuma nö tavalise sama ethernet võrgu piires (st üks ots ei saa olla teist mitu ruuting hop'i eemal)

	<pre>		<pre>

Imre – 9. detsember 2023, kell 11:28

2023-12-09T11:28:14Z

←Vanem redaktsioon		Redaktsioon: 9. detsember 2023, kell 14:28
92. rida:		92. rida:

	# ospfctl show rib		# ospfctl show rib
		+
		+	ospfd protsess ei kuula nö tavalisel soketil (tcp/udp/jne), aga nn raw soketil, see paistab openbsd operatsioonisüsteemis sedasi
		+
		+	<pre>
		+	obsd-router# netstat -n -a -p ip
		+	Active Internet connections (including servers)
		+	Proto Recv-Q Send-Q Local Address Foreign Address IP-Proto
		+	ip 0 0 . . 89
		+
		+	obsd-router# grep 89 /etc/protocols
		+	ospf 89 OSPFIGP # Open Shortest Path First IGP
		+	</pre>
		+
		+	Ning võrguliikluse tcpdump väljundis, st tegu on omaette protokolliga mitte nt udp protokolliga (tundub, et ospf liiklusele on iseloomulik multicast aadressi 224.0.0.5 kasutamine)
		+
		+	<pre>
		+	obsd-fg-adala# tcpdump -nei vio1 proto ospf
		+	tcpdump: listening on vio1, link-type EN10MB
		+	13:27:34.032370 bc:24:11:6a:65:3b 01:00:5e:00:00:05 0800 82: 10.22.48.1 > 224.0.0.5: OSPFv2-hello 48: rtrid 10.10.42.1 backbone dr 10.22.48.1 bdr 10.22.48.250 [tos 0xc0] [ttl 1]
		+	13:27:34.451198 bc:24:11:60:52:cd 01:00:5e:00:00:05 0800 82: 10.22.48.250 > 224.0.0.5: OSPFv2-hello 48: rtrid 10.22.48.250 backbone dr 10.22.48.1 bdr 10.22.48.250 [tos 0xc0] [ttl 1]
		+	13:27:44.042350 bc:24:11:6a:65:3b 01:00:5e:00:00:05 0800 82: 10.22.48.1 > 224.0.0.5: OSPFv2-hello 48: rtrid 10.10.42.1 backbone dr 10.22.48.1 bdr 10.22.48.250 [tos 0xc0] [ttl 1]
		+	13:27:44.461198 bc:24:11:60:52:cd 01:00:5e:00:00:05 0800 82: 10.22.48.250 > 224.0.0.5: OSPFv2-hello 48: rtrid 10.22.48.250 backbone dr 10.22.48.1 bdr 10.22.48.250 [tos 0xc0] [ttl 1]
		+	13:27:45.592549 bc:24:11:6a:65:3b 01:00:5e:00:00:05 0800 130: 10.22.48.1 > 224.0.0.5: OSPFv2-ls_upd 96: rtrid 10.10.42.1 backbone [tos 0xc0] [ttl 1]
		+	13:27:47.601206 bc:24:11:60:52:cd 01:00:5e:00:00:05 0800 98: 10.22.48.250 > 224.0.0.5: OSPFv2-ls_ack 64: rtrid 10.22.48.250 backbone [tos 0xc0] [ttl 1]
		+	13:27:50.612070 bc:24:11:6a:65:3b 01:00:5e:00:00:05 0800 142: 10.22.48.1 > 224.0.0.5: OSPFv2-ls_upd 108: rtrid 10.10.42.1 backbone [tos 0xc0] [ttl 1]
		+	13:27:52.609646 bc:24:11:6a:65:3b bc:24:11:60:52:cd 0800 142: 10.22.48.1 > 10.22.48.250: OSPFv2-ls_upd 108: rtrid 10.10.42.1 backbone [tos 0xc0] [ttl 1]
		+	13:27:52.609820 bc:24:11:60:52:cd bc:24:11:6a:65:3b 0800 78: 10.22.48.250 > 10.22.48.1: OSPFv2-ls_ack 44: rtrid 10.22.48.250 backbone [tos 0xc0] [ttl 1]
		+	13:27:52.609821 bc:24:11:60:52:cd bc:24:11:6a:65:3b 0800 78: 10.22.48.250 > 10.22.48.1: OSPFv2-ls_ack 44: rtrid 10.22.48.250 backbone [tos 0xc0] [ttl 1]
		+	13:27:52.621156 bc:24:11:60:52:cd 01:00:5e:00:00:05 0800 98: 10.22.48.250 > 224.0.0.5: OSPFv2-ls_ack 64: rtrid 10.22.48.250 backbone [tos 0xc0] [ttl 1]
		+	...
		+	</pre>

	===Kahe võrgusõlme omavahel ühendamine kasutades dubleeritud ühendusi===		===Kahe võrgusõlme omavahel ühendamine kasutades dubleeritud ühendusi===

Imre: Uus lehekülg: '===Sissejuhatus=== Internet koosneb võrkude haldajatele usaldatud suurtest võrkudest, mida nimetatakse autonoomseteks süsteemideks (AS - Autonomous System). Üheks oluliseks ülesandeks nende võrkude pidamisel on ruutingute haldamine, reeglina räägitakse võrkude vahel EGP protokolli ja võrgude sees IGP protokolli. * EGP (Exterior Gateway Protocol) - nt BGP4 (Border Gateway Protocol) protokoll ja implementatsioon OpenBGPD; BGP4 on 2009 aastal praktiliselt ainus lev...'

2023-10-15T16:14:01Z

Uus lehekülg: '===Sissejuhatus=== Internet koosneb võrkude haldajatele usaldatud suurtest võrkudest, mida nimetatakse autonoomseteks süsteemideks (AS - Autonomous System). Üheks oluliseks ülesandeks nende võrkude pidamisel on ruutingute haldamine, reeglina räägitakse võrkude vahel EGP protokolli ja võrgude sees IGP protokolli. * EGP (Exterior Gateway Protocol) - nt BGP4 (Border Gateway Protocol) protokoll ja implementatsioon OpenBGPD; BGP4 on 2009 aastal praktiliselt ainus lev...'

Uus lehekülg

===Sissejuhatus===

Internet koosneb võrkude haldajatele usaldatud suurtest võrkudest, mida nimetatakse autonoomseteks süsteemideks (AS - Autonomous System). Üheks oluliseks ülesandeks nende võrkude pidamisel on ruutingute haldamine, reeglina räägitakse võrkude vahel EGP protokolli ja võrgude sees IGP protokolli.

* EGP (Exterior Gateway Protocol) - nt BGP4 (Border Gateway Protocol) protokoll ja implementatsioon OpenBGPD; BGP4 on 2009 aastal praktiliselt ainus levinud EGP
* IGP (Interior Gateway Protocol) - nt OSPF (Open Shortest Path First) protokoll ja impementatsioon OpenOSPFD; OSPF on 2009 aastal tõenäoliselt kõige levinum IGP; lisaks on palju kasutusel IS-IS (Intermediate System to Intermediate System) ja EIGRP (Enhanced Interior Gateway Routing Protocol), vähem RIP (Routing Information Protocol)

===OSPF protokoll===

Internet on jagatud haldusaladeks, iga haldusala haldab tavaliselt ISP või muu organisatsioon ning ühte sellist ala nimetatakse Autonomous System (AS)

AS5050 AS5051

AS5052

Tavaliselt arvutatakse ruutinguid IGP (Interior Gateway Protocol) protokollide perekonda kuuluva protokolli abil (nt OSPF) ASi sees ning ASide vahel EGP (Exterior Gateway Protocol) perekonna protokollidega (reeglina BGP4 protokolliga). Reeglina kasutab AS ühte või enamat nö mõistliku suurusega aadressruumi osa. Näiteks aadressil http://www.radb.net/ asub Routing Assets Database, mille abil saab küsida, millisele organisatsioonile usaldatud aadressruumi kuulub mingi konkreetne ip aadress.

OSPF (Open Shortest Path First) protokoll on IGP protokollide perekonda kuuluv ruutinguprotokoll. Käesolevas tekstis esitatud kasutusjuhtum on suhteliselt erandlik, kuid igati väärikas ja praktiline juhtum, mis sobib ruutinguprotokolliga tutvuse tegemiseks, kusjuures piisab kui on kasutada nö tavaline PC arvuti.

OpenOSPFD on porditud ka FreeBSD'le, asub see portsude all net/openospfd harus. Allolev
konfiguatsioon peaks samuti olema pea täielikult FreeBSD ühilduv. Meeles tuleb ainult pidada, et konfiguratsioonifailid asuvad /usr/local/etc.

===Akronüümid===

* LSA - link-state advertisements
* FIB - Forwarding Information Base
* RIB - Routing Information Base
* DR, BDR - Designated Router, Backup Designated Router

===Järjestikuliselt ühendatud arvutite ruuting===

Olgu ülesandeks korraldada selliselt järjestikuliselt ühendatud arvutite ruuting

____ em0 ____ em0 ____ em0 ____ em0 ____
| | vlan12 | | vlan23 | | vlan34 | | vlan45 | |
| R1 |------------| R2 |------------| R3 |------------| R4 |------------| R5 |
|____| |____| |____| |____| |____|
em1 em1 em1 em0

kus vlan12

* R1 em0 - 10.12.1.1
* R2 em1 - 10.12.1.254

vlan23

* R2 em0 - 10.23.1.1
* R3 em1 - 10.23.1.254

vlan34

* R3 em0 - 10.34.1.1
* R4 em1 - 10.34.1.254

vlan45

* R4 em0 - 10.45.1.1
* R5 em0 - 10.45.1.254

Selle asemel, et igas arvutis seadistada üsna mitu staatilist ruutingut saab OSPF tarkvara kasutades ruutingud korda oluliselt lihtsama vaevaga, lisaks kui mõne arvuti võrguseadistused muutuvad, OSPF korrigeerib vajalikud ruutingud kõigi arvutite ruutingutabelites automaatselt.

Arvutites tuleb käivitada ospfd selliste seadistustega

* R1 ja R5

redistribute connected

area 0.0.0.0 {
interface em0 {
}
}

* R2, R3 ja R4

redistribute connected

area 0.0.0.0 {
interface em0 {
}
interface em1 {
}
}

Seejärel tuleb igas arvutis käivitada ospfd programm, nt öeldes

# ospfd -vd

ning veenduda route -n show -inet käsuga, et asjakohased ruutingutabeli sissekanded on olemas.

Lisaks on abiks programm ospfctl, nt

# ospfctl show rib

===Kahe võrgusõlme omavahel ühendamine kasutades dubleeritud ühendusi===

Olgu eesmärgiks kahe lokatsiooni 192.168.17.0/24 ja 192.168.14.0/24 võrkude vahel moodustada kahe füüsilise andmeside ühenduse abil redundantne ühendus

* igal ajahetkel käib andmevahetus üle ühe või teise lingi
* kui üks link rikneb, arvutavad ruuterid automaatselt ruutingutabelid ümber ja andmevahetus jätkub üle teise lingi

Kusjuures antud juhtumi katsetus on viidud läbi VMware Server v. 2 platvormil töötavate virtuaalsete arvutitega.

___ | | ___
| |------ 192.168.15.253 192.168.15.254 ------| |
|___| | ____ em1 em1 ____ | |___|
| | |------ 1 Gbit/s -----| | |
192.168.17.17 --------| R1 | | R2 |--------- 192.168.14.14
___ | em0 | | | | em0 | ___
| |------ |____|------ 10 Mbit/s -----|____| ------| |
|___| | em2 em2 | |___|
| 192.168.16.253 192.168.16.254 |
| |
Harukontor Peakontor

kus

* vasakpoolse subneti arvutide vaikelüüsiks on 192.168.17.17
* parempoolse subneti arvutite vaikelüüsiks on 192.168.14.14
* R1 ruuteris on võrgu 192.168.14.0/24 vaikelüüsiks tavaliselt 192.168.15.254
* R2 ruuteris on võrgu 192.168.17.0/24 vaikelüüsiks tavaliselt 192.168.15.253

Sarnast tulemuse saab üldiselt saavutada kahel moel

* redundantsus moodustatakse etherneti kihis - võrguseadmete nn trunking; tavaliselt on sellisel juhtumil füüsiline otspunktide kaugus piiratud nö kaabli pikkusega, kuni mõned sajad meetrid
* redundantsus moodustatakse ip kihis - kasutatakse ruutinguprotokolle, nagu nt antud juhtumil ospf; iseenesest ei ole otspunktide vahekaugus praktiliselt piiratud

Enne OpenOSPFD tarkvara seadistamist tuleb ruuterite võrguseadmed seadistada. Seejärel moodustada kummaski arvutis sellise sisuga /etc/ospfd.conf seadistusfailid.

====Ruuteri seadistamine harukontoris====

/etc/ospfd.conf sisu võiks olla nt selline

router-id 192.168.17.17
redistribute connected

# areas
area 0.0.0.0 {
interface em1 { metric 100 }
interface em2 { metric 10 }
}

====Ruuteri seadistamine peakontoris====

/etc/ospfd.conf sisu võiks olla nt selline

router-id 192.168.14.14
redistribute connected

# areas
area 0.0.0.0 {
interface em1 { metric 100 }
interface em2 { metric 10 }
}

====OpenSPFD käivitamine====

OpenSPFD käivitamiseks nn foregroundis ja verbaalses režiimis sobib öelda kummaski ruuteris

# ospfd -dv

Tavalise st deemonina käivitamiseks käsurealt jätta võtmed ära

# ospfd

Selleks, et OpenSPFD käivituks arvuti alglaadimisel peab /etc/rc.conf.local failis sisalduma rida

ospfd_flags=""

====Haldamine====

OpenOSPFD haldamine toimub utiliidiga ospfctl, nt sedasi saab küsida ruuteri seadmeid

# ospfctl show int
Interface Address State HelloTimer Linkstate Uptime nc ac
em2 192.168.16.254/24 DR 00:00:08 active 00:00:06 1 1
em1 192.168.15.254/24 DR 00:00:08 active 13:27:30 1 1

====Tulemuse kontroll====

Püstitatud eesmärgi täitmise kontrollimiseks sobib peab saama katkestada ühe kanali ja ühendus peab jääma tööle; ning peale katkestatud kanali tagasiühendamist (ning andes minutike aega ruutingute stabiliseerumiseks) katkestades teise kanali peab ühendus jällegi jääma otspunktide vahel käima. Ühe kanali katkestuse korral võiks paista selline naabrus

# ospfctl show nei
ID Pri State DeadTime Address Iface Uptime
0.0.0.1 1 FULL/BCKUP 00:00:39 192.168.16.253 em2 00:01:31
0.0.0.1 1 DOWN/DOWN 00:00:09 192.168.15.253 em1 -

===Võrgu ühendamine teenusepakkujaga kahe ühenduspunkti kaudu===

Eesmärgiks on teenuseid pakkuv võrgusegment ühendada ühe ja sama teenusepakkuja võrguga kahe punkti kaudu, kusjuures ühenduspunktides kasutatakse erinevaid ip aadresse.
_____
| | smtp client
|_____|
| 172.3.1.31
| -> 172.16.0.13:25
------------|----------|--
|

internet

|
__|__ em2 172.31.1.254
| |
10.0.21.190/24 em0 | R5 | em1 10.0.22.190/24
,------------------|_____|-------------------,
| |
10.0.21.254/24 em1 __|__ __|__ em1 10.0.22.254/24
| | | |
| R1 | ISP | R2 |
|_____| |_____|
192.168.111.161/29 em0 | | em0 192.168.111.113/29
| |
| |
| |
192.168.111.162/29 em0 __|__ TEENUSED __|__ em0 192.168.111.114/29
(172.16.0.13:25 -> | | | | (172.16.0.13:25 ->
10.0.13.13:25) | R3 | em2 10.0.222.1 10.0.222.2 em2 | R4 | 10.0.13.13:25)
|_____|--------------------------------------|_____|
10.0.13.11/24 em1 | | em3 172.16.0.11/24 172.16.0.12/24 em3 | | em1 10.0.13.12/24
| | | |
| | | |
| | carp16 172.16.0.1/24 | |
| '------------------------------------------' |
| |
| |
| |
| carp13 10.0.13.1/24 |
--------|--|----------------------------------------------|------------
| subnet of serveris
__|__ 10.0.13.13/24
| |
|_____| stmp server

kus

* R5 - teenusepakkuja nö sisemine ruuter ja selle taha jääb avalik internet
* R1, R2 - kõnealuste ühenduspunktide teenusepakkuja poolsed ruuterid
* R3, R4 - vastavad teenuseid pakkuva võrgusegmendi poolsed ruuterid
* 192.168.111.160/29 ja 192.168.111.112/29 avalike aadressidega võrke kasutatakse ainult ruutimiseks, nende võrkude ip aadressid ei ole pakutavate teenustega seotud
* teenuseid pakutakse seoses 172.16.0.0/24 võrgu avalike aadressidega, NAT teisenduste abil jõuab liiklus privaatse aadressiga serverini
* teenust pakkuvad serverid kasutavad privaatseid 10.0.13.0/24 võrgu aadresse
* võrgusegmendi arvutite vaikelüüsi aadress 10.0.13.1 on seostatud carp13 võrguseadmega, mida saavad tulemüürid käest kätte anda
* teenusega seotud avalikule ip aadressile saadatud liiklus saadetakse edasi privaatse aadressiga serverile kasutades tulemüürides aadressteisendusi
* üle tulemüüride em2 seadmete käiva otseühenduse käib pfsync liiklus
* CARP seade on seadistatud selliselt

R3 # cat /etc/hostname.carp13
inet 10.0.13.1 255.255.255.0 10.0.13.255 advskew 80 vhid 13 carpdev em1 pass password13

R4 # cat /etc/hostname.carp13
inet 10.0.13.1 255.255.255.0 10.0.13.255 advskew 120 vhid 13 carpdev em1 pass password13

* teenustega seotud avalike aadresside võrgust on seadistatud tulemüüris nö fiktiivne carp seade (üle füüsiliselt töötava võrgu, et carp failover tegelikult ka toimiks)

R3 # cat /etc/hostname.carp16
inet 172.16.0.1 255.255.255.0 172.16.0.255 advskew 80 vhid 16 carpdev em3 pass password16

R4 # cat /etc/hostname.carp16
inet 172.16.0.1 255.255.255.0 172.16.0.255 advskew 120 vhid 16 carpdev em3 pass password16

Kõigis ruuterites on kasutusel OpenBSD operatsioonisüsteem ning OpenOSPFD ruutingutarkvara, kasutatud on selliseid /etc/ospfd.conf seadistusfaile

* R5:

router-id 172.31.1.254
redistribute connected
redistribute default

# areas
area 0.0.0.0 {
interface em0 { metric 10 }
interface em1 { metric 20 }
}

* R1:

router-id 192.168.111.161
redistribute connected
redistribute default

# areas
area 0.0.0.0 {
interface em0 { metric 10 }
interface em1 { metric 10 }
}

* R2

router-id 192.168.111.113
redistribute connected
redistribute default

# areas
area 0.0.0.0 {
interface em0 { metric 20 }
interface em1 { metric 20 }
}

* R3

router-id 192.168.111.162
redistribute 172.16.0.0/24 set { metric 10 }

# areas
area 0.0.0.0 {
interface em0 { metric 10 }
interface em2 { metric 30 }
interface carp16
demote carp 50
}

* R4

router-id 192.168.111.114
redistribute 172.16.0.0/24 set { metric 20 }

# areas
area 0.0.0.0 {
interface em0 { metric 20 }
interface em2 { metric 30 }
interface carp16
demote carp 50
}

kusjuures redistribute parameetri kohta kehtivad sellised tähelepanekud

* redistribute vaikeväärtus (st kui parameetrit pole seadistusfailis üldse kasutatud) - jagatakse area kirjelduses kasutatud interface'dega seotud võrkude ruutinguid
* redistribute connected - jagatakse välja kõige võrguseadmetega seotud ruutinguid
* redistribute 172.16.0.0/24 - jagatakse välja 10.0.11.0/24 staatiliselt ruutingutabelisse seadistatud võrku
* no redistribute 10.0.13.0/24 - ei jagata 10.0.13.0/24 võrku
* redistibute default - antakse ümbruse töötavatele ospf deemonitele teada, et nad kasutaksid kõnealust arvutit vaikelüüsina (vastavalt seda seadet, mis kõnealusest arvutist nende poole jääb)
* demote carp 50 - kui ükski ospf naaber ei ole aktiivne, siis suurendatakse carp'i demote väärtust 50 võrra, st praktiliselt toimub carp failover

Redistribute abil ei saa jagada välja ruutingut, mida ei ole kõnealuses arvutis olemas (kas siis seoses mõne seadmega või staatiliselt seadistatune).

Nt olgu arvuti ühendatud nelja võrgukaardiga sellistesse võrkudesse

* em0 - 192.168.10.0/24
* em1 - 10.0.11.0/24
* em2 - 10.0.12.0/24
* em3 - 10.0.13.0/24

siis seadistusfail

no redistribute 192.168.10.0/24
redistribute connected

# areas
area 0.0.0.0 {
interface em1 { metric 10 }
interface em2 { metric 20 }
}

korraldab, et

* ei jagata välja 192.168.10.0/24 võrgu ruutingut
* jagatakse välja kõigi võrkude ruutinguid mis on arvutiga ühendatud
* ruutinguid jagatakse edasi üle em1 ja em2 võrkude (st suheldes sinna ühendatud muude ospf deemonitega)

====OSPF ja CARP====

OSPF ja CARP koos kasutamisel tuleb tähele panna, et

* ruuter saadab OSPF liiklust välja ainult siis, kui CARP seade on master olekus; kusjuures sellel CARP seadmel peab olema aadress sellest võrgust, mille ruutimist OSPF abil juhitakse, sel põhjusel on em3 seadmed seadistatud nö fiktiivse tähendusega 172.16.0.0/24 võrku.
* kuigi ainult carp master tekitab ospf liiklust on kasutatud vasakul ja paremal pool erinevaid metric väärtusi
* kui parasjagu aktiivse tulemüüri (R4) välisel ühendusel juhtub midagi OSPFiga (nt öelda R4 tulemüüril ifconfig em0 down), siis OSPF lülitab liikluse ümber R3 peale, kuid CARP seadme masterit automaatselt ümber ei paigutata. Antud juhul on kasutatud kahe tulemüüri vahel otseühendust (R3 ja R4 ruuterite em2 seadmete vahel) ning seejuures leiab aset asümmeetriline ruuting, st teenuse serverist väljuvad paketid mööda teed

server -> R4 -> R3 -> R1 -> R5 -> internet

ja teenuse serverisse saabuvad paketid

internet -> R5 -> R1 -> R3 -> server

Alternatiiviks otseühendusele kahe ruuteri vahel oleks kasutada programmi ifstated võimalusi carp masteri lülitamiseks.

====OSPF ja PF====

Paketifiltri kasutamine sellise OSPF lahendusega tulemüüride juures osutub mõne sobiva asjaolu tõttu praktiliselt lihtsamaks kui võiks esmapilgul eeldada. Allpool on esitatud kogu skeemist ainult tulemüürid ja server

192.168.111.162/29 em0 __|__ TEENUSED __|__ em0 192.168.111.114/28
| | | |
| R3 | 10.0.222.2 em2 | R4 |
|_____|----------------------|_____|
10.0.13.11/24 em1 | em2 10.0.222.1 | em1 10.0.13.12/24
| |
| |
| carp13 10.0.13.1/24 |
--------|---|----------------------------|------------
| subnet of serveris
__|__ 10.0.13.13/24
| | (192.168.110.13:25 -> 10.0.13.13:25)
|_____| stmp server

Nt võiks sobida kasutada kummaski tulemüüris sellist paketifiltri äärmiselt lubavat reeglistikku

# MACROS
tcpopts="flags S/SA modulate state"
synopts="flags S/SAFR synproxy state"
udpopts="keep state"
icmp_types="echoreq"

if_ext="em1"
if_int="em2"
if_direct="em3"

# OPTIONS
set state-defaults pflow
set limit states 20000
set limit src-nodes 15000
set block-policy drop
set loginterface $if_ext
set skip on lo0

# FILTERS
block in log on $if_ext label "ESext vaikimisi"
block out log on $if_ext label "EVext vaikimisi"

block in log on $if_int label "ESint vaikimisi"
block out log on $if_int label "EVint vaikimisi"

block in log on $if_direct label "ESdirect vaikimisi"
block out log on $if_direct label "EVdirect vaikimisi"

# carp, ospf ja pfsync liiklus

pass quick on $if_int proto carp
pass quick on $if_ext proto ospf
pass quick on $if_direct proto ospf
pass quick on $if_direct proto pfsync

# lubada siltidega kogu ipv4 liiklust

pass in quick on $if_int inet tag TO_EXT
pass out quick on $if_ext tagged TO_EXT

pass in quick on $if_ext inet tag TO_INT
pass out quick on $if_int tagged TO_INT

ning sellise seadistusega pfsync0 seadmeid

R3 # cat /etc/hostname.pfsync0
up syncdev em3 syncpeer 10.0.222.2

R4 # cat /etc/hostname.pfsync0
up syncdev em3 syncpeer 10.0.222.1

Kui tekib eelmises ospf + carp punktis kirjeldatud asümmeetriline liiklus, siis ka see läbib paketifiltri, isegi vaatamata asjaolule, et ilmutatult ei ole üle em3 võrguseadme lubatud muud peale ospf ja pfsync liikluse. Andmevahetus toimub järgmistel põhjustel

* paketifiltri olekuid sünkroniseeritakse kahe tulemüüri vahel (tundub, et master -> slave ja slave -> master)
* vaikimisi kontrollitakse olekuid nö state-policy = floating tingimustes, mis tähendab muuhulgas, et paketifilter kontrollib vastuspakette vaatamata, milliselt võrguseadmelt need sisenevad, kusjuures antud juhul sisenevad nad isegi teisest arvutist

Selleks, et saaks serverist pöörduda interneti suunas asümmeetrilise ruutingu tingimustes tuleks lisada veel üks reegel, st nö EXT siltidega sektsioon oleks siis selline

pass in quick on $if_int inet tag TO_EXT
pass out quick on $if_ext tagged TO_EXT
pass out quick on $if_direct tagged TO_EXT

Peab siiski märkima, et asümmeetrilisel juhul on liiklus just ühenduste tekkimisel pisikese viivitusega, tõenäoliselt seetõttu, et olekud peavad kahe tulemüüri vahel propageeruma nö reaalajas.

====ospfctl utiliidi kasutamine====

* ospfctl show int väljund näitab ruuteri omadusi erinevate seadmetega seotud võrkudes, nt kas ta on DR ja BCKUP andmebaasiks neindes ehternetides. Nt ühe subneti ühes osalises öeldes

yks # ospfctl show int
Interface Address State HelloTimer Linkstate Uptime nc ac
...
em3 10.0.222.2/24 BCKUP 00:00:01 active 02:04:30 1 1
em1 192.168.111.114/29 DR 00:00:01 active 02:04:30 1 1

ja teises

teine # ospfctl show int
Interface Address State HelloTimer Linkstate Uptime nc ac
..
em3 10.0.222.1/24 DR 00:00:04 active 01:49:37 1 1
em1 192.168.111.162/29 DR 00:00:02 active 01:49:37 1 1

kust on näha, et üks ruuter on 10.0.222.0/24 võrgus DR ja teine tema BCKUP.

* ospfctl show nei väljund näitab ruuteri naabrite omadusi erinevate seadmetega seotud võrkudes. Nt eelmise punkti 'yks' (id 192.168.111.114) ruuteri kohta tema 192.168.111.162/29 võrgu suhtes võiks öelda tolles võrgus olev naaber nii

naaber # ospfctl show nei
ID Pri State DeadTime Address Iface Uptime
..
192.168.111.114 1 FULL/DR 00:00:30 192.168.111.114 em1 01:42:46

ning tema 10.0.222.2/24 võrgus oleva rolli kohta võiks vastava võrgu naaber öelda nii

# ospfctl show nei
ID Pri State DeadTime Address Iface Uptime
..
192.168.111.114 1 FULL/BCKUP 00:00:31 10.0.222.2 em3 02:11:17

St ruuteri arvamus enda DR või BCKUP oleku kohta kapib naaberite arvmausega, FULL tähistab asjaolu, et ruutingute andmebaas on täielik.

===Märkused===

* Kui sama võrk on näha mõnes ruuteris sama metric väärtusega, nt

# ospfctl show rib
Destination Nexthop Path Type Type Cost Uptime
192.168.110.128/25 10.0.22.254 Type 1 ext Network 30 00:03:01
192.168.110.128/25 10.0.21.254 Type 1 ext Network 30 00:02:56

siis on ruutingutabelis kaks sissekannet.

* OSPF liiklus paistab võrgus selline, st pakette saadetakse multicast mac ja ip aadressidele

# tcpdump -nei em1 proto ospf
22:30:23.867538 00:0c:29:e7:4c:4e 01:00:5e:00:00:05 0800 82: 192.168.111.161 > 224.0.0.5: \
OSPFv2-hello 48: backbone dr 192.168.111.162 bdr 192.168.111.161 [tos 0xc0] [ttl 1]
22:30:23.867641 00:0c:29:ec:33:48 01:00:5e:00:00:05 0800 82: 192.168.111.162 > 224.0.0.5: \
OSPFv2-hello 48: backbone dr 192.168.111.162 bdr 192.168.111.161 [tos 0xc0] [ttl 1]

* OSPF liiklust saab lubada nt sellise paketifiltri reegliga

pass quick on $if_ext proto ospf

===Kasulikud lisamaterjalid===

* http://www.openbsd.org/papers/linuxtag06-network.pdf
* http://kuutorvaja.eenet.ee/wiki/Quagga_kasutamine_Debianiga
* [[:OpenBGPD kasutamine OpenBSDga]]