1. No category

T-110.4100 Tietokoneverkot: Reititys autonomisten järjestelmien
välillä, ryhmälähetyksen reititys
Teemu Kiviniemi
Funet-verkko
CSC – Tieteen tietotekniikan keskus Oy
Luento pohjautuu Sanna Suorannan aiempaan materiaaliin.
14.2.2012
Luennon sisältö
Autonomiset järjestelmät ja niiden väliset yhteydet
BGP
– iBGP, eBGP, toiminta IGP:n kanssa
– BGP:n turvallisuus
– Multiprotocol BGP (MBGP)
Ryhmälähetys
– osoitteet
– IGMP, MLD
– Reititysprotokollat
DVMRP, CBT, MOSPF, PIM
– AS:ien välinen ryhmälähetys
2
Funet
Suomen
korkeakoulujen ja
tutkimuksen
tietoverkko
Yli 80 organisaatiota
– Yliopistoja
– Ammattikorkeakouluja
– Tutkimuslaitoksia
Noin 350 000
käyttäjää
3
Internetin rakenne
AS2
R
R
R
R
R
R
R
R
R
AS1
R
R
R
R
AS4
AS3
R
R
Internet koostuu itsenäisistä verkoista, autonomisista
järjestelmistä: autonomous systems (AS).
4
Autonominen järjestelmä
(Autonomous System, AS)
Autonomiset järjestelmät ovat itsenäisiä
verkkoja, joilla on oma hallittu reitityssäännöstö.
– Muiden AS:ien näkökulmasta AS on sisäisesti
yhtenäinen verkko.
– AS:ien välillä käytetään reititykseen BGP-4:ää
(Border Gateway Protocol).
Jokaisella AS:llä on uniikki 32-bittinen tunniste.
– Alun perin AS-numerot olivat 16-bittisiä. 32-bit ASnumerolaajennus BGP:hen tuli RFC 4893:ssa.
– Verkossa on edelleen laitteita jotka tukevat vain 16-bit
AS-numeroita.
– Myönnettyjä AS-numeroita on noin 58000.
5
Miksi AS:ien välinen ja AS:n sisäinen
reititys tehdään erikseen?
Internet on liian iso yhdelle reititysprotokollalle
– Kaikki reitittimet eivät ole samassa verkossa, joten ne
eivät voi kommunikoida suoraan keskenään.
– AS:n sisäistä topologiaa ei tarvitse levittää koko
Internetiin. Yhteenveto AS:n verkoista ja Internetin
AS-poluista riittää. AS:n sisäinen rakenne
huomioidaan IGP:ssä.
AS:illä on omat hallinnolliset linjauksensa
– Aina ei käytetä lyhintä reittiä vaan esim. halvimman
sopimuskumppanin tarjoamaa verkkoyhteyttä.
– BGP-politiikkojen avulla voidaan valita käyttöön
muitakin kuin lyhimpiä reittejä. Myös mainostettavat
verkot voidaan rajata.
6
Erilaisia AS:ia
7
Transit vs. peeraus
Transit
– Alemman kerroksen
operaattori (tier-[n+1]) tai stubAS maksaa transitoperaattorille (tier-n) Internetliikennöinnistä.
– Transit-operaattori mainostaa
BGP:llä täyden Internettaulun.
– Pienempi operaattori
mainostaa omat verkot ja
omien asiakkaiden verkot.
Peeraus
– Tyypillisesti rahaa ei vaihdeta.
– Kahden tier-n –operaattorin tai
stub-AS:n välillä.
– Molemmat mainostavat
BGP:llä toisilleen omat ja
asiakkaittensa verkot.
– Operaattoreiden välinen
liikenne ei tarvitse kulkea enää
transitin kautta.
– Julkinen peeraus:
yhdysliikennepisteessä (IXP):
esim. FICIX, TREX, AMS-IX
– Privaattipeeraus: suora yhteys
operaattoreiden välillä.
8
BGP
9
Border Gateway Protocol 4
(BGP-4, RFC 4271)
Välittää reittejä verkkojen saavutettavuustietona
(Network Layer Reachability Information, NLRI)
– NLRI:stä kerrotaan AS-polku, jota kautta
saavutettavuustieto on saatu: polkuvektori.
AS-polulle voi olla määritelty myös attribuutteja.
AS-polkutiedon avulla voidaan välttää reitityssilmukat.
– Reittien tarkkaa metriikkaa ei ole tiedossa, vain ASpolku jota kautta reitti on vastaanotettu.
– BGP:llä mainostetaan yleensä vain sellaisia reittejä
joita mainostava reititin käyttää itse.
BGP käyttää TCP:tä portissa 179.
10
BGP-protokollan viestit
OPEN (Type = 1)
– Ensimmäinen BGP-sessiossa lähetettävä viesti. Sisältää mm. AS-numeron,
BGP-tunnisteen (Identifier), tuetut BGP-lisäominaisuudet, ym.
– Jos naapurit avaavat TCP-yhteydet yhtä aikaa, se yhteys katkaistaan jonka avasi
reititin jolla on pienempi BGP Identifier.
UPDATE (Type = 2)
– Viesti jossa välitetään mainostettavat reitit NLRI-tietueina. Viestillä voidaan myös
vetää pois aiempia mainostuksia (WITHDRAW).
KEEPALIVE (Type = 3)
– Lähetetään aika-ajoin jotta varmistetaan että naapurireititin on edelleen
hengissä. Viestillä kuitataan myös vastaanotettu ja hyväksytty OPEN-viesti.
NOTIFICATION (Type = 4)
– Viesti jolla lähetetään virheilmoitus naapurireitittimelle. NOTIFICATION-viestin
jälkeen BGP-sessio suljetaan.
ROUTE-REFRESH (Type = 5): laajennus, RFC 2918
– Viesti jolla pyydetään naapuria mainostamaan kaikki reititit uudelleen UPDATEviesteillä.
11
BGP-viestin otsikko
0
8
16
24
31
Marker
Length
Type
Marker: käytetään synkronointiin: viestin alku
– Käytettiin aiemmin myös autentikointiin, RFC 4271:n myötä ei enää.
Length: BGP-viestin pituus tavuina, ml. otsikot.
– Viestin maksimipituus on 4096 tavua.
Type: BGP-viestin tyyppi
12
BGP OPEN-viesti (Type = 1)
0
8
16
24
31
Version = 4
My autonomous system
Hold Time
BGP Identifier
Opt Parm Len
Optional Parameters (variable)
13
BGP OPEN-viesti (2)
My autonomous system: AS-numero (16-bit)
– 32-bit AS-numero välitetään optioissa.
Hold Time: aika sekunteina jonka jälkeen BGP-sessio katkaistaan
jos naapurilta ei ole vastaanotettu yhtään viestiä
– Käyttöön valitaan pienempi naapureiden Hold Time-arvoista.
– Minimiarvo on 3 sek.
BGP Identifier: tunniste jota reititin käyttää kaikissa BGPsessioissaan: yksi sen IP-osoitteista
Opt Parm Len + Optional Parameters: valinnaiset optiot. Esimerkiksi
tuetut BGP:n lisäominaisuudet (Capabilities, RFC 5492):
– RFC 2918: Route Refresh
– RFC 4893: 32-bittiset AS-numerot
– RFC 4760: multiprotocol-laajennus (mm. IPv6)
14
BGP UPDATE-viesti (Type = 2)
0
8
Withdrawn Routes Length
16
24
Withdrawn Routes
(variable)
Total Path Attribute Length
Path Attributes
(variable)
Network Layer Reachability Information
(variable)
Lähetetään kun BGP-yhteys on avattu tai kun verkon
tila muuttuu.
Viesti sisältää joko sekä poistuneita (withdrawn) reittejä
että uusia reittejä, tai vain jompia kumpia.
Yhdessä UPDATE-viestissä mainostettavien uusien
reittien polun attribuutit on oltava samat.
31
15
BGP UPDATE-viesti (2)
Poistuneet (withdrawn) reitit ja uudet reitit (NLRI)
kuvataan pareina:
Length Prefix (variable)
– Length: prefiksin pituus bitteinä (1 tavu)
– Prefix: itse prefiksi, joka on lopusta jatkettu
lähimmälle tavurajalle
NLRI-osion koko lasketaan vähentämällä
UPDATE-viestin kokonaispituudesta aiemmin
esiintyneet kentät.
16
BGP UPDATE - Polkuattribuutit
0
OTPE
16
8
31
24
0000 Attr. Type Code Attr. Data Length1 (…Length2)
Attribute Data
UPDATE-viestissä mainostettavien uusien reittien polkuattribuutit.
– Sisältää lisätietoa mainostettavista reiteistä.
Polkuattribuutit jakautuvat neljään eri kategoriaan
– Tunnetut (well-known) attribuutit: pakolliset (mandatory) ja harkinnanvaraiset
(discretionary)
– Valinnaiset (optional) attribuutit: transitiiviset ja ei-transitiiviset
OTPE-flagit:
– (O)ptional: 1 = valinnainen, 0 = tunnettu
– (T)ransitive: 1 = transitiivinen, 0 = ei-transitiivinen
– (P)artial: 1 = partial, 0 = complete: jos 1, jokin polulla olevista reitittimistä ei ole
ymmärtänyt valinnaista transitiivistä attribuuttia.
– (E)xtended length: Attr Data Length-kentän pituus. 1 => 2 tavua, 0 => 1 tavu
17
BGP - Polkuattribuutit (2)
1 = ORIGIN (tunnettu, pakollinen)
– reitin lähde
– 0 = IGP, 1 = EGP (RFC 904), 2 = INCOMPLETE (jokin muu
lähde)
2 = AS_PATH (tunnettu, pakollinen)
– reitin AS-polku <tyyppi, pituus, arvo> -tripletteinä
tyyppi 1 = järjestämätön ja 2 = järjestetty lista AS:ista
pituus = AS:ien lukumäärä
arvo = AS:t
3 = NEXT_HOP (tunnettu, pakollinen)
– Sen reitittimen IP johon NLRI:ssä määriteltyihin verkkoihin
kohdistuva liikenne tulisi välittää
18
BGP - Polkuattribuutit (3)
4 = MULTI_EXIT_DISC (valinnainen, ei-transitiivinen)
– MED-arvo: metriikka jonka avulla voidaan iBGP:ssä erotella
muuten samanarvoiset reitit AS:n ulkopuolelle.
– MED-arvoja käytetään vertaillessa reittejä jotka on vastaanotettu
samasta AS:stä.
– Jos MED-arvoa ei ole määritelty, reitillä on paras mahdollinen
metriikka.
5 = LOCAL_PREF (tunnettu, pakollinen iBGP:ssä)
– AS:n sisällä reiteille valittu paikallinen preferenssi.
– Paikallinen preferenssi ohittaa esimerkiksi AS-polun pituuden
tarkastelun, joten paikallisessa politiikassa voidaan käyttää ASpolultaan pidempiä, mutta muilla tavoin parempia reittejä
(esimerkiksi halvempi transit-sopimus).
19
BGP - Polkuattribuutit (4)
Useiden reittien tiedoista voidaan yhdistää (aggregate)
yksi reitti. Yhdistäminen vähentää BGP:ssä välitettävän
tiedon määrää.
Reittien yhdistämiseen liittyvät attribuutit:
– 6 = ATOMIC_AGGREGATE (tunnettu, harkinnanvarainen)
Attribuuttia käytetään jos reittejä on yhdistetty niin, että
yhdistetyllä AS-polulla ei mainittu ole kaikkia alkuperäisten
reittien AS-poluilla listattuja AS:iä.
– 7 = AGGREGATOR (valinnainen, transitiivinen)
Reittejä yhdistäneen reitittimen AS-numero ja IP-osoite
20
BGP NOTIFICATION-viesti (Type = 3)
0
16
8
Error Code
Error subcode
24
Data (variable)
31
Virheistä ilmoittaminen BGP-naapurille. Viestin
lähettämisen jälkeen BGP-sessio katkaistaan.
Error Code
Symbolic Name
1
Message Header Error
2
OPEN Message Error
3
UPDATE Message Error
4
Hold Timer Expired
5
Finite State Machine Error
6
Cease
21
BGP KEEPALIVE-viesti (Type = 4)
Viesti lähetetään jotta BGP-naapuri tietää että
paikallinen reititin on edelleen elossa.
Viesti lähetetään jos edellisestä lähetetystä
BGP-viestistä on kulunut tarpeeksi.
– RFC 4271 suositus: 1/3 * Hold Time
– Jos Hold Time on 0, KEEPALIVE-viestejä ei lähetetä.
– Korkeintaan yksi KEEPALIVE-viesti/sek.
KEEPALIVE-viesti ei sisällä tietoa reiteistä.
– BGP lähettää NLRI-reittitietoja vain kun niissä on
tapahtunut muutoksia.
22
BGP:n reititystaulut
(Routing Information Base, RIB)
BGP kerää reittitietoa kolmeen erilaiseen tietokantaan.
– Periaatteellisella tasolla. Käytännön toteutus voi olla toisenlainen.
Adj-RIBs-In
– Muilta reitittimiltä UPDATE-viesteissä vastaanotettu reititystieto sellaisenaan.
Loc-RIB
– Reitit jotka on paikallisesti määriteltyjen politiikkojen perusteella tuotu Adj-RIBsIn-taulusta.
– Sisältää paikallisesti käytetyt BGP-reitit.
Kaikkia reittejä ei välttämättä silti käytetä, eli kaikki reitit eivät aina ole aktiivisia reitittimen
reittitaulussa. Esim. IGP-reittejä tai paikallisesti konfiguroituja staattisia reittejä suositaan usein
parhaiden BGP-reittien sijaan.
Adj-RIBs-Out
– Reitit jotka on paikallisesti määriteltyjen politiikkojen perusteella valittu
mainostettaviksi BGP-naapureille UPDATE-viesteillä.
23
BGP - reitin valinta
Ennakkovaatimukset:
– Reitin Next Hop-osoitteeseen on oltava toimiva reitti.
– AS_PATH ei saa sisältää silmukoita.
Valintakriteerit, järjestyksessä (eniten merkitsevä ensin):
– Tarkin reitti: suurempi prefiksin pituus on parempi
– LOCAL_PREF: AS:n sisällä valittu paikallinen preferenssi: korkeampi preferenssi
on parempi
– AS-polun pituus: lyhyempi polku on parempi
– ORIGIN-attribuutin arvo: IGP > EGP > INCOMPLETE
– MULTI_EXIT_DISC: reitin MED-metriikka: pienempi metriikka on parempi
– Suositaan eBGP:stä saatua reittiä iBGP-reittien sijaan.
– IGP-metriikka reitin Next Hop-osoitteeseen: pienempi on parempi
– Reitin mainostaneen reitittimen BGP Identifier: valitaan pienin
– BGP-naapurin IP-osoite: valitaan pienin.
24
BGP - Communities Attribute
(RFC 1997 ja RFC 4360)
BGP Community-attribuuttien avulla AS voi leimata ja ryhmitellä
reittejä haluamallaan tavalla esimerkiksi vastaanotettaessa reittejä
AS:n ulkopuolelta.
– Community-attribuuttien avulla reittejä voidaan käsitellä muilla AS:n BGPreitittimillä toisistaan poikkeavalla tavalla.
– Community-arvot, ja se, mitä arvoilla tehdään on paikallisen ylläpidon
päätettävissä.
Muutamia tunnettuja Community-arvoja:
– NO_EXPORT: reittiä ei mainosteta BGP-konfederaation ulkopuolelle
– NO_ADVERTISE: reittiä ei mainosteta BGP-naapureille
– NO_EXPORT_SUBCONFED: reittiä ei mainosteta AS:n ulkopuolelle
Community-attribuutit ovat 32-bittisiä arvoja, joista ensimmäiset 16
bittiä sisältää AS-numeron (RFC 1997).
Extended Community-attribuutit voivat perustua 16-bittisen ASnumeron lisäksi IPv4-osoitteeseen tai IANA:n varauksiin (RFC
4360).
25
Internal BGP (iBGP)
AS:n reunareitittimet keskustelevat keskenään AS:n sisäisellä
iBGP:llä.
– AS:n pitää antaa itsestään ulos konsistentti kuva.
Kaikkien AS-reunareitittimien on muodostettava iBGP-sessio
kaikkien muiden reunareitittimien kanssa (full mesh)
– RFC 4456 määrittelee Route Reflection-ominaisuuden.
Kaikki verkon reitittimet muodostavat iBGP-sessiot vain BGPreflektoreina toimiviin reitittimiin (vrt. OSPF transit-verkon
Designated Router)
Kaikki reittitieto leviää kaikille verkon reitittimille
reflektoreiden kautta.
26
iBGP (Full Mesh)
IGP
27
iBGP (Route Reflector)
28
BGP-naapuruuksien muodostamiseen
käytettävät IP-osoitteet
iBGP-sessiot muodostetaan yleensä reitittimien
loopback-osoitteiden välille.
– Paras reitti muiden reititinten loopbackeihin saadaan
IGP:llä.
– iBGP-sessioiden ei pitäisi katketa koskaan.
eBGP-sessiot muodostetaan yleensä sen
linkkiverkon linkkiosoitteiden välille, jonka yli
liikennettä vaihdetaan.
– eBGP-naapuruus katkeaa heti kun toiseen AS:ään
yhdistävä verkkolinkki katkeaa. Tällöin toiselta AS:lta
vastaanotetut reitit poistetaan käytöstä.
29
Linkkiverkot ja loopbackit
30
IGP:n ja iBGP:n yhteistoiminta
IGP:ssä reitititettävien reittien määrää kannattaa suuremmissa
verkoissa pyrkiä minimoimaan.
– IGP:n reittilaskenta nopeutuu, kun reittejä on vähemmän.
Riittää että IGP:ssä mainostetaan:
– reititinten loopbackit iBGP-sessioiden muodostamiseen
– BGP-reittien Next Hop-osoitteet
Kaikki loput reitit voidaan mainostaa iBGP:llä.
Mahdollinen työnjako korkealla tasolla:
– IGP:llä reititetään välttämättömät reitit iBGP-sessioiden
muodostamiseen (loopback-osoitteet).
– iBGP:llä kerrotaan mitä verkkoja reitittimen takaa on
saavutettavissa ja reittien Next Hopit.
– IGP:llä kerrotaan miten kuhunkin reitittimeen (BGP Next Hop)
voidaan liikennöidä.
31
Multiprotocol Extension for BGP-4
(RFC 4760)
Alun perin BGP tuki vain IPv4:ää.
Multiprotocol-laajennus mahdollistaa myös
muiden kuin IPv4-reittien mainostamisen:
Address Family Identifier (AFI)
– Esim. IPv6
Yhden osoiteperheen sisällä voidaan välittää
myös erilliset multicast-saavutettavuustiedot
– Subsequent Address Family Identifier (SAFI)
BGP OPEN-viestin Capability-tiedoissa
kerrotaan mitä AFI/SAFI-yhdistelmiä reititin
tukee.
32
MBGP - uudet attribuutit
Valinnaisia ei-transitiivisia attribuutteja
– MBGP:tä osaamaton reititin jättää attribuutit
huomioimatta.
Reittien mainostus ja reittien poistuminen tehdään uusilla
polkuattribuuteilla.
– Multiprotocol Reachable NLRI (MP_REACH_NLRI)
Uusien ja muuttuneiden reittien mainostaminen.
– Multiprotocol Unreachable NLRI
(MP_UNREACH_NLRI)
Poistuneiden reittien tiedot.
– Molemmissa attribuuteissa kerrotaan AFI ja SAFI, jota
päivitys koskee.
33
BGP ja turvallisuus
BGP:tä vastaan voidaan hyökätä useilla eri keinoilla.
Man in the middle: hyökkääjä mainostaa BGP:llä verkkoja jotka
kuuluvat jollekin muulle.
– Liikenne ohjautuu hyökkääjälle. Hyökkääjä voi edelleenohjata liikenteen
lopulliseen kohde-AS:ään.
– BGP-naapuruuksissa tulisi varmistaa että naapuri-AS mainostaa vain sellaisia
verkkoja jotka kuuluvat naapuri-AS:lle ja sen asiakkaille.
– 2008: Youtube oli saavuttamattomissa väärien BGP-mainostusten vuoksi.
Palvelunestohyökkäys: jos BGP-sessio reititinten välillä katkeaa,
kyseisen BGP-session yli vaihdetut reitit poistuvat käytöstä
– BGP-liikenne priorisoidaan reitittimissä normaalisti muuta liikennettä
tärkeämmäksi.
– TCP-autentikoinnin avulla (RFC 5925) yhteyden resetointi TCPsekvenssinumeroita voidaan estää.
34
Reittimainostusten turvallisuus
Millä AS:lla on oikeus mainostaa BGP:llä
verkkoa X?
– Tarvitaan jonkinlainen tapa sitoa verkkoprefiksit ASnumeroihin.
Mitä kautta AS:ään Y voidaan liikennöidä?
– Tarvitaan jonkinlainen tapa jolla voidaan varmistua
AS-polun tiedon oikeellisuudesta.
Secure Inter-Domain Routing (SIDR)-työryhmä
IETF:ssä on kehittämässä ratkaisuja.
35
Route Origin Authorization
(ROA, RFC 6483)
Kun IP-osoitteita ja AS-numeroita jaetaan (IANA, RIR:t, LIR:t),
omistusoikeus (delegointi) julkaistaan digitaalisesti allekirjoitettuna.
– Sertifikaattihierarkia noudattaa samaa hierarkiaa kuin IP-osoitteiden ja
AS-numeroinen jakaminen muutenkin.
IP-prefiksin omistaja voi delegoida omistusoikeutta eteenpäin, tai kertoa
mitkä AS:t saavat mainostaa kyseistä prefiksiä.
Allekirjoitukset julkaistaan hajautetussa Resource Public Key Infrastructure
–tietokannassa (RPKI)
Allekirjoitukset voidaan hakea RPKI-tietokannasta paikalliseen välimuistiin,
josta AS:n BGP-reitittimet käyvät hakemassa tietoja joiden avulla voidaan
varmistaa reittien lähteet.
– Välimuistin ja reitittimien välille on oma protokolla: RPKI/Router Protocol
(draft-ietf-sidr-rpki-rtr).
– BGP-reititin voi käsitellä allekirjoitettua tietoa paikallisten politiikkojen
avulla.
Voidaan asettaa esimerkiksi local preference.
36
BGPSEC (draft-ietf-sidr-bgpsec)
RPKI-tietokantaan lisätään sertifikaatti, jossa on
AS:n BGP-reitittimien käyttämä julkinen avain.
– Avaimella allekirjoitetaan BGP:hen mainostettujen
reittien AS-polku.
Kun reititin AS:sta X mainostaa reitin AS:ään Y,
reititin luo BGP-attribuutin ”reitti mainostettiin
AS:stä X AS:lle Y”, ja allekirjoittaa sen AS X:n
avaimella.
– Sama toistuu AS:ssä Y mainostettaessa AS:lle Z
– Attribuutin avulla reitittimet voivat tarkistaa AS-polun
aitouden.
37
RYHMÄLÄHETYS
38
Ryhmälähetys (multicast, monilähetys)
Liikenne jota lähetetään ryhmälle vastaanottajia
– Vastaanottajat voivat olla eri puolilla verkkoa.
– Verkko huolehtii viestin monistamisesta ja
kuljettamisesta kaikille ryhmään liittyneille
vastaanottajille.
Multicast-ryhmiin voi liittyä ja niistä voi poistua
dynaamisesti.
– Muutokset vaikuttavat kyseisen ryhmän reititykseen.
Ryhmälähetys on tehokas tapa viestiä
suuremmalle vastaanottajajoukolle.
39
Ryhmälähetys Internetissä
Ryhmälähetys toimii kattavasti akateemisissa
verkoissa, kuten Funetissa.
– Mbone, M6bone
Kaupallisten operaattoreiden välillä
ryhmälähetyksen välittäminen ei ole kovin
yleistä.
– Operaattorit käyttävät ryhmälähetystä kuitenkin
omien IPTV-palveluiden toteuttamiseen oman verkon
sisällä.
40
Esimerkkejä ryhmälähetyksen käytöstä
IPTV
Muu video- ja audiostreamaus
Pörssi-informaation jakaminen
Linkin paikallinen käyttö, mm.
– Reititysprotokollat
– IPv6: reitittimien ja naapureiden löytäminen
41
Ryhmälähetysosoitteet
Ryhmälähetysosoite toimii ryhmän tunnisteena
– Ei kerro, missä ryhmän jäsenet sijaitsevat.
Kuka tahansa voi lähettää paketteja
ryhmäosoitteeseen.
On sekä pysyviä (well-known) että vapaasti
käytettäviä ryhmäosoitteita.
– IANA allokoi pysyvät.
Osa ryhmäosoitteista on varattu liikennöintiin
paikallisella linkillä. Liikenne ei leviä linkin
ulkopuolelle.
42
Ryhmälähetyksen kaksi eri palvelumallia
Any-Source Multicast (ASM): lähderiippumaton
ryhmälähetys
– Pelkästään ryhmäosoite (*, G) toimii ryhmän
tunnisteena.
– Verkko tietää lähteet ja huolehtii siitä että kaikkien
lähteiden paketit kulkevat vastaanottajille.
Source-Specific Multicast (SSM):
lähdekohtainen ryhmälähetys (RFC 4607)
– SSM-kanavan tunnisteena toimii lähettäjän IP-osoite
ja SSM-ryhmäosoite (S,G)
– Vastaanottaja on tiedettävä lähettäjän IP etukäteen.
43
IPv4-ryhmälähetysosoitteet
0
1110
31
Group Identification
224.0.0.0/4, eli 224.0.0.0 - 239.255.255.255
Vapaasti käytettäviä:
– 233.0.0.0/8: RFC 3180: GLOP Addressing: 16-bit
AS-numeroon perustuva osoitteiden jaottelu.
– 234.0.0.0/8: RFC 6034: IP-prefiksiin perustuva
osoitteiden jaottelu.
– 239.0.0.0/8: organisaation sisäiseen käyttöön
Sovelluskehittäjät voivat varata ryhmäosoitteita
IANA:lta.
44
IPv4-ryhmälähetysosoitteet (2)
Paikallisen linkin protokollaliikennöintiin:
224.0.0.0/24
– Liikennettä ei välitetä ulos linkiltä.
– Esim. OSPF 224.0.0.5
Session Announcement Protocol (RFC 2974):
224.2.0.0/16
– Ryhmälähetyssessioden julkaisemiseen
Esim. videokonferenssit, audio- ja videolähetykset
Source-Specific Multicast (SSM): 232.0.0.0/8
45
IPv6-ryhmälähetysosoitteet (RFC 4291)
0
8
16
11111111 0RPT scope
128
group ID
Scope rajoittaa viestin leviämistä verkkoon
– 1 = Interface-Local, 2 = Link-Local
– 4 = Admin-Local, 5 = Site-Local,
– 8 = Organization-Local, e = Global
R (RFC 3956): Embedded-RP
P (RFC 3306): Unicast-prefixiin perustuva
ryhmäosoitteiden allokointi
T: 0 = IANA:n allokoima, 1= dynaamisesti varattu
46
IPv6-ryhmälähetysosoitteet (2)
Link-Local: ff02::/16
– Ei leviä paikalliselta linkiltä
– esim. OSPFv3: ff02::5
Source-Specific Multicast: ff3x::/32
– Käytetään SSM-kanavien ryhmäosoitteina
Embedded-RP: ff7x::/16
– Ryhmäosoitteet joihin on määritelty RP-reitittimen
osoite.
47
Ryhmälähetys yhdellä linkillä:
lähettäjän näkökulma
Ryhmälähetysosoitteeseen lähetetty IP-paketti kehystetään
linkkikerroksen kehykseen.
– Jos linkkikerros tukee ryhmälähetystä, käytetään
linkkikerroksen ryhmälähetysosoitteita linkkikerroksen
kohdeosoitteena. Linkkikerroksen kohdeosoite voidaan valita
IP-ryhmäosoitteen perusteella (esim. RFC 2464)
– Muuten käytetään yleislähetystä (broadcast).
Jos ryhmälähetys ei ole kohdistettu vain linkille (link-local),
verkkoa palveleva reititin välittää ryhmälähetyksen eteenpäin
muualle verkkoon.
Samalla linkillä olevat vastaanottajat näkevät ryhmälähetyksen
suoraan.
48
Ryhmälähetys yhdellä linkillä:
vastaanottajan näkökulma
Kun sovellus sitä pyytää, laite liittyy haluttuun multicastryhmään.
Ryhmään liittyminen, siitä poistuminen tehdään IGMP:n
(IPv4) tai MLD:n (IPv6) avulla.
– Jos linkkikerros tukee ryhmälähetystä, laite alkaa
kuuntelemaan myös IP-ryhmälähetysosoitetta
vastaavaa linkkikerroksen ryhmälähetysosoitetta.
– Muuten kuunnellaan linkkikerroksen
yleislähetysosoitetta (broadcast).
Haluttuun ryhmälähetysosoitteeseen saapuneet paketit
välitetään sovellukselle.
49
Internet Group Management Protocol
IGMPv3 (RFC 3376)
Käytetään IPv4-verkossa multicast-ryhmiin
liittymiseen.
IGMP on oma protokolla IP:n päällä.
IGMP-viestit lähetetään ryhmälähetyksellä.
IGMP-viestit eivät koskaan leviä linkin
ulkopuolelle.
50
IGMPv3 - Viestityypit
Version 3 Membership Report
– viesti jonka avulla laite ilmoittaa mihin ryhmiin se
kuuluu
Membership Query
– viesti jonka avulla verkon laite (yleensä reititin) pyytää
ryhmien jäseniä lähettämään Membership Reportviestin.
Lisäksi, vanhojen IGMP-versioiden viestit:
– Version 1 Membership Report, Version 2 Membership
Report, Version 2 Leave Group
51
IGMP – versioiden olennaisimmat erot
IGMPv1 – alkuperäinen versio
– Ryhmästä ei voinut poistua – poistuminen vaati sen että
(softa)tila reitittimestä vanheni.
IGMPv2
– Uutena ominaisuutena tuki ryhmistä poistumiselle.
– Laajimmin tuettu
IGMPv3
– Mahdollisuus lähteiden suodattamiseen
Lähteiden suodattamisen myötä tukee Source-Specific Multicastia (SSM)
Kaikki IGMP-versiot ovat taaksepäin yhteensopivia: jos
verkossa näkyy vanhan IGMP-version viestejä, laitteet
käyttävät IGMP:n vanhaa versiota.
– Ongelmallista SSM:lle.
52
Reitittimen tehtävä ryhmien hallinnassa
Linkillä voi olla useampi ryhmälähetysreititin.
Se reititin, jolla on pienin IP-osoite valitaan
kyselijäksi (querier).
– Kyselijä valitaan jokaisella linkillä erikseen.
– Kyselijä vastaa Membership Query-viestien
lähettämisestä verkkoon.
– Jos linkillä näkyy Membership Query-viesti
reitittimeltä jolla on pienempi IP-osoite, kyselijä
vaihtuu.
Kaikki linkin IGMP:tä tukevat reitittimet pitävät
kirjaa linkillä olevista vastaanottajista.
53
IGMPv3 Membership Query
0
8
16
31
Type =0x11 Max Resp Code
Checksum
Group Address
Resv S QRV
QQIC
Number of Sources (N)
Source Address [1]
...
Source Address [N]
IP-paketin TTL=1, Router Alert-optio on päällä
General Query: kohdeosoitteena 224.0.0.1 (kaikki
laitteet)
Group-Specific Query ja Group-and-Source-Specific
Query: kohdeosoitteena ryhmän osoite
54
IGMPv3 Membership Query (2)
Olennaisimmat otsikon kentät:
– Max Resp Code: kuinka nopeasti kyselyyn on
vastattava
– Group Address: ryhmä jonka tietoja pyydetään
0.0.0.0 = kaikki ryhmät, General Query
– Number of Sources (N): viestissä listattujen lähteiden
lukumäärä
käytetään kun halutaan rajata kyselyä lähteiden mukaan
(Group-and-Source-Specific Query)
55
IGMPv3 Membership Report
0
16
31
Type=0x22
Reserved
Checksum
Reserved
# of Group Records (M)
Group Record [1]
…
Group Record [M]
Laite voi kertoa kaikki kuuntelemansa ryhmät
yhdellä viestillä
Raportin otsikko kertoo kuinka monta
ryhmäraporttitietuetta viesti sisältää.
56
IGMPv3 Group Record
0
8
16
31
Record Type Aux Data Len
Number of Sources (N)
Multicast Address
Source Address [1]
...
Source Address [N]
Auxiliary Data
57
IGMPv3 Group Record (2)
Record Type:
– MODE_IS_INCLUDE ja MODE_IS_EXCLUDE
Kerrotaan vastaanottotila ja halutut tai hylättävät lähteet
– INCLUDE: halutaan lähetys vain mainituista lähteistä
– EXCLUDE: halutaan lähetys kaikista paitsi mainituista lähteistä
– CHANGE_TO_INCLUDE_MODE ja
CHANGE_TO_EXCLUDE_MODE
Vastaanottotilan vaihtaminen.
– ALLOW_NEW_SOURCES ja
BLOCK_NEW_SOURCES
Uusien lähteiden vastaanottaminen tai vastaanoton
lopettaminen.
58
Multicast Listener Discovery v2
(MLDv2, RFC 3810)
IGMP:tä vastaava ryhmien hallintaprotokolla
IPv6:lle.
MLDv2 vastaa IGMPv3:a. MLDv1 vastaa
IGMPv2:ta.
– Muutettu IPv6:ta varten.
MLD ei ole kokonaan erillinen protokolla IP:n
päällä kuten IGMP, vaan MLD-viestit välitetään
ICMPv6-viestien sisällä
– MLD on ICMPv6:n aliprotokolla
59
RYHMÄLÄHETYKSEN
REITITTÄMINEN
60
Yksinkertainen tapa
ryhmälähetyksen reitittämiseen:
Reverse Path Forwarding
Käytetään hyväksi lähettäjän osoitetta ja unicast-reititystaulua.
– Jos paketti saapuu lähettäjän osoitteen osoittamasta suunnasta,
se lähetetään kaikille muille linkeille.
Typistävä versio (Truncated Reverse Path Broadcasting, TRPB)
– Kuten edellä, mutta lähetetään paketti vain sellaisille
reunalinkeille joissa on kyseisen ryhmän vastaanottajia.
– Jokaiselta linkiltä valitaan linkkiä palveleva reititin.
Reverse Path Multicasting (RPM)
– Kuten edellä, mutta tarpeettomat ryhmälähetykset karsitaan
(Prune) myös reititinten välisiltä linkeiltä. Reitittimet ilmoittavat
toisilleen jos ryhmää ei tarvita.
61
Kaksi tapaa luoda ryhmälähetyspuu
Datalähtöinen (data-driven)
– Ryhmälähetys välitetään
aluksi kaikille linkeille.
– Välitys linkille lopetetaan kun
saadaan tieto ettei kyseistä
ryhmää tarvita sillä linkillä.
Tarvelähtöinen (demanddriven)
– Ryhmälähetys välitetään vain
sellaisille linkeille joilla
tiedetään olevan ryhmään
kuuluvia vastaanottajia.
62
Distance Vector Multicast Routing
Protocol (DVMRP, RFC 1075)
Pohjautuu RIP-protokollaan.
– IGP-protokolla, soveltuu vain AS:n sisäiseen käyttöön.
Reitit lähteisiin välitetään samalla tavalla kuin RIP.
Multicast-reititykseen käytetään Truncated Reverse Path
Broadcasting-algoritmia.
– Datalähtöinen
Aiheuttaa turhaa liikennettä verkossa jossa vastaanottajia on harvassa.
Käyttää IGMP:tä viestintään muiden reitittimien kanssa
– Uusi IGMP-viestityyppi.
63
Core Based Trees
(CBT, RFC 2189)
Tarvelähtöinen reititysprotokolla
Verkossa on core-reititin jokaiselle ryhmälle.
– Core-reitittimessä lähettäjät ja vastaanottajat kohtaavat.
Reitittimet lähettävät ryhmälähetykset tunneloituna corereitittimelle.
Kun ryhmään liitytään, liittymispyyntö välitetään askel
askeleelta kohti core-reititintä.
– Jatketaan kunnes saavutetaan core-reititin, tai reititin joka on jo
liittynyt haluttuun ryhmään.
– Kun välityspuu tai core-reititin on saavutettu, lähetetään kuittaus.
64
Multicast OSPF (MOSPF, RFC 1584)
OSPFv2:n laajennus ryhmälähetystä varten.
Käyttää tarvelähtöistä reititystapaa.
Ryhmän vastaanottajat mainostetaan verkkoon LSAtietueilla.
Lähettäjän päässä oleva reititin laskee lyhimmän reitin
jokaiseen ryhmän vastaanottajaan.
– Laskettu tieto talletetaan välimuistiin seuraavia
paketteja varten.
Paketit välitetään lyhimpää puuta vastaanottajille.
65
Protocol Independent Multicast (PIM)
PIM Dense Mode (PIM-DM, RFC 3973)
– Tarkoitettu verkkoon, jossa paljon (tiheästi)
vastaanottajia.
– Käytetään datalähtöistä reititystapaa.
PIM Sparse Mode (PIM-SM, RFC 4601)
– Tarkoitettu verkkoon, jossa vastaanottajia on
harvassa.
– Käytetään tarvelähtöistä reititystapaa.
Tukee sekä IPv4:ää että IPv6:tta.
66
PIM – reititystaulu
PIM käyttää olemassa olevaa unicastreititystaulua verkkojen sijainnin selvittämiseen.
– Mitä kautta on lyhin reitti IP-osoitteeseen X?
PIM voi käyttää myös erillistä reittitaulua, jossa
on ryhmälähetystä tukevan verkon unicast-reitit.
– Kaikki osat verkosta eivät välttämättä tue
ryhmälähetystä.
MBGP:ssä ryhmälähetystä tukevan verkon
saavutettavuustiedot kuljetetaan erikseen
SAFI=2 –reitteinä.
67
PIM - erityiset reitittimet
Rendezvous Point (RP)
– PIM-reititin, jonne ASM-ryhmään kohdistuva liikenne
lähetetään, ja jonka kautta ryhmään liitytään
– vrt. Core Based Trees
Designated Router (DR)
– Linkkiä palveleva PIM-reititin.
– DR huolehtii ryhmälähetyksen välittämisestä linkiltä
RP:lle, ja ryhmälähetyksen välittämisestä muualta
verkosta linkille.
– DR valitaan jokaiselle linkille erikseen.
68
PIM – RP-puu
69
PIM Register-Stop
70
Tilanne Register-Stop-viestin jälkeen
71
PIM Shortest Path Tree
72
PIM – lähdekohtainen ryhmälähetys
(SSM)
Lähdekohtaisessa ryhmälähetyksessä lähettäjä
on oltava vastaanottajan tiedossa.
Etuja:
– RP:tä ei tarvita.
– Vastaanottajan Designated Router voi tehdä (S,G)
Joinin suoraan lähettäjälle.
SSM on yksinkertaisin ryhmälähetysmenetelmä.
– Myös AS:ien välillä
Haasteena IGMPv3- ja MLDv2-tuen puute.
73
Autonomisten järjestelmien välinen
ASM-reititys
Tyypillisesti jokaisessa AS:ssä on oma PIM RP.
– RP tietää kaikki AS:n lähteet.
Tarvitaan menetelmä jonka avulla saadaan
selville muissa AS:issa olevat lähteet.
74
Multicast Source Discovery Protocol
(MSDP, RFC 3618)
Protokolla aktiivisten multicast-lähteiden mainostamiseen PIM
RP:iden välillä.
RP:t välittävät Source Active-viestejä (SA) aktiivisista lähteistä.
– SA-viestit välitetään AS:ien välillä kaikkialle Internetiin.
– Viestien sisältö:
Lähteen IP-osoite S
Ryhmäosoite G
RP:n IP-osoite
RP voi tehdä (S,G) Joinin halutun ryhmän AS:n ulkopuolisiin
lähteisiin.
MSDP toimii TCP:n yli portissa 639.
MSDP on toteutettu vain IPv4:lle.
75
Embedded-RP
(RFC 3956)
Menetelmä jonka avulla ASM saadaan
toimimaan AS:ien välillä IPv6-verkossa.
Sen sijaan että jaetaan tietoa aktiivisista
lähteistä RP:iden välillä, käytetään tietylle
ryhmäosoitteelle samaa RP:tä globaalisti.
RP:n IP-osoite on upotettu ryhmäosoitteeseen
– Esim: ff7e:140:2001:db8:ab:cd::1
40 on prefiksin pituus heksana (64)
RP:n osoite: 2001:db8:ab:cd::1
76
RP:n kahdentaminen
Kaikki ASM-ryhmälähetys riippuu RP:n toiminnasta.
AS:n sisällä RP voidaan kahdentaa anycast-reitityksen avulla.
Verkkoon asennetaan kaksi RP:tä. Molemmilla on uniikin IP-osoitteen
lisäksi anycast-osoite, joka mainostetaan verkkoon.
–
–
DR:iin konfiguroidaan RP:ksi anycast-osoite.
DR:t käyttävät aina verkossa lähempänä olevaa RP:tä.
Anycast RP mechanism using PIM and MSDP (RFC 3446)
–
–
PIM RP:iden välille muodostetaan MSDP-sessio, jonka kautta RP:t jakavat tietoa aktiivisista
lähteistä.
Tukee vain IPv4:ää.
Anycast-RP Using PIM (RFC 4610)
–
–
RP:t välittävät vastaanottamansa PIM Register-viestit myös toiselle RP:lle
Toimii myös IPv6:lla.
Molemmissa vaihtoehdoissa molemmilla RP:illä on sama tieto lähteistä.
Kun toinen RP:istä hajoaa, jäljelle jää vain toinen anycast-reitti, ja liikenne
ohjautuu kaikkialta verkosta toimivaan RP:hen.
77
DVMRP vs. PIM-SM
Rakentaa itse unicastreititystaulun.
– Kärsii samoista ongelmista
kuin RIP.
IGP-protokolla AS:n
sisäiseen käyttöön.
Datalähtöinen reititystapa
Ei juurikaan enää
käytössä.
Käyttää muiden
reititysprotokollien
rakentamaa reititystaulua.
Voidaan käyttää sekä
AS:n sisällä että AS:ien
välillä.
Tarvelähtöinen
reititystapa
Laajasti käytössä.
Kehitetään aktiivisesti
IETF:n PIM-työryhmässä
78
Lähteet
Deering, S. "Multicast Routing in Internetwork and Extended LANs", SIGCOMM Summer 1988
Proceedings, August 1988.
RFC 1075 Distance Vector Multicast Routing Protocol, 1988
RFC 1584 Multicast Extensions to OSPF, 1994
RFC 1585 MOSPF: Analysis and Experience, 1994
RFC 1773 Experience with the BGP-4 protocol, 1995
RFC 1774 BGP-4 Protocol Analysis, 1995
RFC 1997 BGP Communities Attribute, 1996
RFC 2113 IP Router Alert Option, 1997
RFC 2189 Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification, 1997
RFC 2201 Core Based Trees (CBT) Multicast Routing Architecture, 1997
RFC 2918 Route Refresh Capability for BGP-4, 2000
RFC 2974 Session Announcement Protocol, 2000
RFC 3180 GLOP Addressing in 233/8, 2001
RFC 3376 Internet Group Management Protocol, Version 3, 2002
RFC 3446 Anycast Rendezvous Point (RP) mechanism using Protocol Independent Multicast
(PIM) and Multicast Source Discovery Protocol (MSDP), 2003
RFC 3618 Multicast Source Discovery Protocol (MSDP), 2003
79
Lähteet (2)
RFC 3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6, 2004
RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address
RFC 3973 Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification
(Revised), 2005
RFC 4271 A Border Gateway Protocol 4 (BGP-4), 2006
RFC 4272 BGP Security Vulnerabilities Analysis, 2006
RFC 4291 IP Version 6 Addressing Architecture, 2006 RFC 4360 BGP Extended Communities
Attribute, 2006
RFC 4456 BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP), 2006
RFC 4601 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised), 2006
RFC 4604 Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener
Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast, 2006
RFC 4607 Source-Specific Multicast for IP, 2006
RFC 4760 Multiprotocol Extensions for BGP-4, 2007
RFC 4893 BGP Support for Four-octet AS Number Space, 2007
RFC 5059 Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM), 2008
RFC 5065 Autonomous System Confederations for BGP, 2007
80
Lähteet (3)
RFC 5396 Textual Representation of Autonomous System (AS) Numbers, 2008
RFC 5492 Capabilities Advertisement with BGP-4, 2009
RFC 5519 Multicast Group Membership Discovery MIB, 2009
RFC 5757 Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey,
2010
RFC 5771 IANA Guidelines for IPv4 Multicast Address Assignments, 2010
RFC 5796 Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode
(PIM-SM) Link-Local Messages, 2010
RFC 5925 The TCP Authentication Option, 2010
RFC 6034 Unicast-Prefix-Based IPv4 Multicast Addresses, 2010
RFC 6085 Address Mapping of IPv6 Multicast Packets on Ethernet, 2011
RFC 6480 An Infrastructure to Support Secure Internet Routing, 2012
RFC 6483 Validation of Route Origination Using the Resource Certificate Public Key Infrastructure
(PKI) and Route Origin Authorizations (ROAs), 2012
draft-ietf-sidr-rpki-rtr The RPKI/Router Protocol, 2012
How Pakistan knocked Youtube offline (and how to make sure it never happens again),
http://news.cnet.com/8301-10784_3-9878655-7.html
32-bit Autonomous System Number Report, http://www.potaroo.net/tools/asn32/
81