Multicast VPN TELCO környezetben. Papp Jenı, senior technikai tanácsadó CCIE#3871

Méret: px

Mutatás kezdődik a ... oldaltól:

Download "Multicast VPN TELCO környezetben. Papp Jenı, senior technikai tanácsadó CCIE#3871"

Erik Fazekas
8 évvel ezelőtt
Látták:

1 Multicast VPN TELCO környezetben Papp Jenı, senior technikai tanácsadó CCIE#3871

2 Tartalom Multicast VPN-ek Tesztfeladat a szolgáltatónál Ráadás: miért olvassunk RFC-ket? (esettanulmány)

3 Multicast alapfogalmak Üzenet egytıl soknak Sávszélesség és CPU takarítható meg vele Szolgáltatói piacbıvülés (mősorszórás IP-n) Speciális címekre küldött üzenetek (Class D) A fogadók mindig jelzik igényüket regisztrációs folyamat Mroute formája (*,G) vagy (S,G)

Speciális címekre küldött üzenetek (Class D) A fogadók mindig

4 Multicast alapfogalmak MRouting:egy- vagy kétirányú disztribúciós fa felépítése RPF ellenırzés Csomagtöbbszörözés

5 Multicast alapok PIM a core-ban IGMP a leaf protocol IGMP snooping/cgmp a L2/L3 határon

6 Source Tree, Dense Mode A fa gyökere a forrás A DM és az SSM használja Az SM átválthat erre Sok multicast vevı, domináns az mcast forgalom jelenléte (S,G) mroute bejegyzések Prune mechanizmus

7 Shared Tree, Sparse Mode Az EGYIRÁNYÚ fa gyökere a Rendezvous Point Az SM default fája Az RP-ig unicast, addig el KELL menni Kevés multicast vevı (*,G) mroute bejegyzések Periodikus PIM Join -ok RP felfedezés: static, auto-rp, bootstrap router, anycast RP, stb Multicast források S3 S2 IP Multicast hálózat RP Shared Tree (PIM SM) S1

bejegyzések Periodikus PIM Join -ok RP felfedezés: static, auto-rp, bootstrap

8 Kétirányú Shared Tree A fa mentén két irányban továbbítanak mcast forgalmat Nem kell átmennie az RP-n Optimálisabb routing Adók bárhol lehetnek Multicast források S3 S2 IP Multicast hálózat RP Bidirectional Tree (PIM BiDir) S1

Optimálisabb routing Adók bárhol lehetnek Multicast

9 Multicast szolgáltatói gerincen Elvárások: Transzparens: ne kelljen átkonfigurálni semmit Üzembiztos: szolgáltatói üzembiztonsági szint Olcsóbb: legyen értelme áttérni rá

10 Multicast szolgáltatói gerincen A Draft-rosen-vpn-mcast- 03.txt három megoldást kínál: Multicast Domain-ek Multicast Tunnel Interfaceekkel VPN-IP PIM, a (S,G)/(*,G) kiegészítése RD-el, és MPLS Multicast Label-ek használata a gerincen Multicast Domain PIM NBMA technikával, multipoint tunnelekkel a PE-k között, amelyen unicast a forgalom

VPN-IP PIM, a (S,G)/(*,G) kiegészítése RD-el, és MPLS Multicast Label-ek használata

11 Cisco MVPN: Multicast Domain A Cisco a Multicast Domain MTI megoldást választotta, mert: Az SP a gerincén (PE és P routerek) natív multicast routing ot konfigurál A multicast routing biztos és kiforrott technika (IOS 10.0-tól!) A másik kettı skálázhatósági korlátokba ütközik

natív multicast routing ot konfigurál A multicast routing biztos és

12 Szükséges hozzávalók RFC 2547 alapú MPLS VPN Core Natív multicast routing a P és a PE routereken (PIM-BiDir vagy PIM-SM) Multicast VRF-ek (MVRF) a PE routereken Multicast Domain-ek (MD-k) Multicast Tunnel Interface-ek (MTI) az MD és az MVRF közé Default Multicast Distribution Tree (MDT) Data MDT-s on demand

routereken Multicast Domain-ek (MD-k) Multicast Tunnel Interface-ek (MTI) az

13 MD és default MDT B ügyfél Default MDT A ügyfél A ügyfél Default MDT CE PE1 PE3 MVRF-ek CE PE2 MVRF-ek CE CE CE Multicast Tunnel Interface (MTI) CE MVRF-ek

14 Multicast Domain MVRF-ek halmaza, amelyek a szolgáltatói gerincen küldhetnek egymásnak multicast forgalmat A default MDT-jükön keresztül összekapcsolt MVRF-ek csoportja Az MVRF-et az MTI-k kapcsolják az MDT-hez

15 Data MDT

16 Cisco-javasolt protokollok A Core-ban: PIM-SSM javasolt (nincs RP) Source Discovery egy új BGP attribútummal vagy az MDT SAFI-val történik Default MDT: PIM BiDir a kézenfekvı, ha támogatott minden szereplı router platformon Data MDT: PIM-SM és PIM-SSM javasolt (SM egyszerőbb) A VPN-ben: az Ügyfél PIM módjához igazodunk RP lehet az Ügyfélnél, vagy a PE-routerben

támogatott minden szereplı router platformon Data MDT: PIM-SM és PIM-SSM javasolt (SM

17 Javasolt SSM címek a core-ban A default PIM-SSM a /8, ez nyilvános tartomány az interneten! Privát domain-ekben a /8 javasolt (RFC2365) A Cisco a /16-ot javasolja használni

18 SSM Source discovery a core-ban Közölni kell az MDT forrását a Core-ban Új BGP attribútum: BGP-MDT update extended community Formátuma <RD-type>:<megszokott RD> RD-type=2 az MDT esetén Példa: 2:1:1 Cisco proprietary, non-transitive attribútum

community Formátuma <RD-type>:<megszokott RD> RD-type=2 az

19 MDT SAFI formátum Szükség volt AS-ek közötti SSM Source Discovery-re 2004 aug: draft-nalawade-idr-mdt-safi-00.txt Új MBGP address-family: MDT SAFI MDT SAFI=MDT SubAddress Family Identifyer Formátuma: RD:IPv4 address, MDT group address (8+4+4 octets) Így az extcomm-t NLRI-ként tudjuk átvinni és manipulálni (route-map kulcsszó: match mdt-group) Migráció és visszafelé-kompatibilitás biztosított 12.0(29)S, 12.2(31)SB, 12.2(33)SRA1 és IOS XR 3.5-tıl

group address (8+4+4 octets) Így az extcomm-t NLRI-ként tudjuk átvinni és manipulálni (route-map kulcsszó:

20 A csomag útja Ügyfél multicast csomagja eljut a PE-hez a vrf-ben. Megkeressük, hogy a csomagot mely MDT-ben kell továbbítani. Ha kell, létre kell hozni a Data MDT-t és PIM DATA JOIN-nal a többi PE tudomására hozni. A C-packetet be kell csomagolni P-packetbe (Mcast tunneling). A P-network a global tábla Mroutingja alapján továbbítja és ha kell, replikálja a csomagot.

Ha kell, létre kell hozni a Data MDT-t és PIM DATA JOIN-nal a többi PE tudomására hozni.

21 A csomag útja RPF-check a gerincen a feladó PE-router forráscímére történik. A P-packet elér az egress PE routerig. Egress PE router leszedi a külsı csomagolást, és az mvrf-ben továbbítja a C-packetet megfelelı interfészein. RPF check-kel itt baj van módosítani kellett

22 A csomag útja

23 MVPN RPF check típusok PE routerbe C-interfészen érkezı C-csomagok: normál RPF check a VRF unicast routing tábla alapján P vagy PE routerbe P-interfészen érkezı P-csomagok: normál RPF check a globál unicast routing tábla alapján mvrf-be a MTI-n érkezı C-csomagok: ehhez az RPF módosítására volt szükség

24 Módosított RPF check A P-nework felıl az MTI-n esnek a mvrf-be a csomagok a C- forráscímmel A forráscím felé az MBGP vpnv4 prefixe mutat a P-networkön át vmelyik fizikai interfészen keresztül mvrf mroute entry: (S,G); Incoming IF, Outgoing IF list (olist) Incoming IF = MTI (Tunnel) Érdemes önálló RPF táblát elképzelni: source (unicast) címtartományt rendel össze a megengedett bejövı interfésszel (RPF Interface) RPF lookup erre a táblára történik Ebbe RPF interface-ként az mroute Incoming IF-t jegyezzük be, NEM pedig a szokásos unicast routing táblából nyert interfészt!

25 RPF check Az RPF tábla ellenırzése: PE2#show ip rpf vrf Narancs RPF information for S1 ( ) RPF interface: Tunnel0 RPF neighbor: PE1 ( ) RPF route/mask: /8 RPF type: unicast (bgp 100) RPF recursion count: 0 Doing distance-preferred lookups across tables

26 PIM szomszédságok P-networkön a globál táblában a P és a PE routerek között P-networkön a PE-k között a VRF-ben a MTI-ken keresztül C-networkön a VRF-ben a CE és a C között

27 Összegzés A Cisco a robusztus Multicast Domain megoldást implementálta. Az MVRF-ek az MDT-kkel összekapcsolva Multicast Domain-eket alkotnak. Külön PIM instance-ek a gerincen és az mvrf-en. Valójában Multicast VRF Lite, azaz MPLS tagging nincs

28 Tartalom Multicast VPN-ek Tesztfeladat a szolgáltatónál Ráadás: miért olvassunk RFC-ket? (esettanulmány)

29 Teszt az Invitelnél IPTV szolgáltatás átvitele Cisco 7600-as platformok10g gerincen IOS változatok tesztelése, javaslat Konvergencia és redundancia tesztek Stressz-teszt Egyéb szükséges feature-ök tesztje (MUX UNI) Mérési jegyzıkönyv készítése

30 Tesztkörnyezet IPTV server Loo / /32 TenGig 2/ /30 TenGig 3/ /30 Loo 1 VRF tv VRF tv Inest-p0 BGP /24 Multicast feed C7604-SYN (BGP65100 route reflector) TenGig 2/ /30 MPLS gerinc (OSPF) TenGig 3/ /30 C7609- CISCO /24 (DHCP) STB (set-top-box) BGP65100 TV-set TenGig 1/ /30 TenGig 1/ / /32 Loo 1 C7609- INVITEL

31 Tartalom Multicast VPN-ek Tesztfeladat a szolgáltatónál Ráadás: miért olvassunk RFC-ket? (esettanulmány)

32 A jelenség leírása Az Ügyfél a group címet használta IGMP snooping L2 optimalizálásra Cisco Catalyst 3560: mőködik Cisco Catalyst 6509: FLOODS! Téves következtetés: a Cat65k IGMP Snooping feature bugos, tehát nyissunk TAC SR-t a Cisconál!

33 A megoldás Címzési séma változtatás: használjuk pl a címet, és jól fog mőködni! Az ok három összetevıje: A fenntartott multicast IP címek hanyag ismerete (RFC) Az IP to MAC multicast cím leképzés módja A Cat3560 és a Cat6509 eltérı architektúrája

34 Fenntartott IP címek : helyi multicast címek, pl: : All Systems on this subnet : All Routers on this subnet : OSPF Routers : OSPF Designated Routers : DHCP Server/Relay Agent A Cisco ellenjavallja ezek egyéb célra való használatát.

35 Multicast IP to Ethernet IANA Ethernet címblokk: 00:10:5E:xx:xx:xx Az IP Multicast Ethernet címek a blokk alsó fele:00:10:5e:00:00:00-00:10:5e:7f:ff:ff Az alsó 23 bitünk a mozgástér Leképezési szabály: a mcast IP-cím utolsó 23 bitjét írjuk a mmac utolsó 23 bithelyére Pl: :10:5E:00:00:01 Dehát a 239:0.0.1 is ugyanerre képzıdik le!

36 Multicast IP to Ethernet

37 A Cat65k architektúra Route Processor: Control plane Switch Processor: forwarding IGMP Snoopingot a SP végzi KIVÉTEL a link local multicast címekre: amelyekre nem várunk IGMP membersip reportot nem kezeljük IGMP snoopinggal árasztjuk (flooding) A 3560-as más (egyszerőbb) architektúra, más kód, eltérı implementáció

38 Tanulság Érdemes az RFC-ket olvasni, és megfogadni GLOP addressing (RFC2770) egy megoldás Ebben az esetben a 3560-as volt rosszabb mőködéső

39 Köszönjük figyelmüket!

Hasonló dokumentumok

IP multicast routing napjainkban. Jákó András BME EISzK

IP multicast routing napjainkban Jákó András goya@eik.bme.hu BME EISzK Tartalomjegyzék IP multicast Multicast routing Interdomain kiegészítések A multicast routing jövője Networkshop 2001. IP multicast