Multicast VPN TELCO környezetben Papp Jenı, senior technikai tanácsadó CCIE#3871
Tartalom Multicast VPN-ek Tesztfeladat a szolgáltatónál Ráadás: miért olvassunk RFC-ket? (esettanulmány)
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)
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
Multicast alapok PIM a core-ban IGMP a leaf protocol IGMP snooping/cgmp a L2/L3 határon
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
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
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
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á
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
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
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
MD és default MDT B ügyfél Default MDT 239.232.1.0 A ügyfél A ügyfél Default MDT 239.232.0.0 CE PE1 PE3 MVRF-ek CE PE2 MVRF-ek CE CE CE Multicast Tunnel Interface (MTI) CE MVRF-ek
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
Data MDT
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
Javasolt SSM címek a core-ban A default PIM-SSM a 232.0.0.0/8, ez nyilvános tartomány az interneten! Privát domain-ekben a 239.0.0.0/8 javasolt (RFC2365) A Cisco a 239.232.0.0/16-ot javasolja használni
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
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
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.
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
A csomag útja
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
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!
RPF check Az RPF tábla ellenırzése: PE2#show ip rpf vrf Narancs 3.3.3.3 RPF information for S1 (3.3.3.3) RPF interface: Tunnel0 RPF neighbor: PE1 (10.10.10.10) RPF route/mask: 3.0.0.0/8 RPF type: unicast (bgp 100) RPF recursion count: 0 Doing distance-preferred lookups across tables
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
Ö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
Tartalom Multicast VPN-ek Tesztfeladat a szolgáltatónál Ráadás: miért olvassunk RFC-ket? (esettanulmány)
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
Tesztkörnyezet IPTV server Loo 1 10.0.0.2/32 10.0.0.1/32 TenGig 2/2 10.0.12.2/30 TenGig 3/2 10.0.12.1/30 Loo 1 VRF tv VRF tv Inest-p0 BGP65100 10.68.129.1/24 Multicast feed C7604-SYN (BGP65100 route reflector) TenGig 2/1 10.0.23.1/30 MPLS gerinc (OSPF) TenGig 3/1 10.0.13.1/30 C7609- CISCO 10.68.129.143/24 (DHCP) STB (set-top-box) BGP65100 TV-set TenGig 1/3 10.0.23.2/30 TenGig 1/1 10.0.13.2/30 10.0.0.3/32 Loo 1 C7609- INVITEL
Tartalom Multicast VPN-ek Tesztfeladat a szolgáltatónál Ráadás: miért olvassunk RFC-ket? (esettanulmány)
A jelenség leírása Az Ügyfél a 239.0.0.1 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!
A megoldás Címzési séma változtatás: használjuk pl a 239.11.11.1 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
Fenntartott IP címek 224.0.0.0-224.0.0.255: helyi multicast címek, pl: 224.0.0.1: All Systems on this subnet 224.0.0.2: All Routers on this subnet 224.0.0.5: OSPF Routers 224.0.0.6: OSPF Designated Routers 224.0.0.12: DHCP Server/Relay Agent A Cisco ellenjavallja ezek egyéb célra való használatát.
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: 224.0.0.1 00:10:5E:00:00:01 Dehát a 239:0.0.1 is ugyanerre képzıdik le!
Multicast IP to Ethernet
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ó
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ő
Köszönjük figyelmüket!