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
Multicast források S2
Az SM default fája
IP Multicast hálózat
Az RP-ig unicast, addig el KELL menni
RP
S3
Kevés multicast vevı (*,G) mroute bejegyzések Periodikus „PIM Join”-ok RP felfedezés: static, auto-rp, bootstrap router, anycast RP, stb
S1
Shared Tree (PIM SM)
Kétirányú Shared Tree
Multicast források
A fa mentén két irányban továbbítanak mcast forgalmat
S2
IP Multicast hálózat
Nem kell átmennie az RP-n
RP
Optimálisabb routing Adók „bárhol” lehetnek
S1
S3
Bidirectional Tree (PIM BiDir)
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-mcast03.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 Default MDT 239.232.0.0 239.232.0.0
PE1
CE
PE3
MVRF-ek
MVRF-ek CE
PE2
CE
CE
Multicast Tunnel Interface (MTI)
CE
MVRF-ek
CE
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
:<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 Cforrá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
10.0.0.2/32
IPTV server
10.0.0.1/32
Loo 1
Lo o 1 TenGig 2/2 10.0.12.2/30
VRF tv
Inest-p0
Multicast feed
VRF tv
TenGig 3/2 10.0.12.1/30
10.68.129.1/24
BGP65100 C7604-SYN (BGP65100 route reflector)
TenGig 2/1 10.0.23.1/30
TenGig 3/1 10.0.13.1/30
MPLS gerinc (OSPF)
C7609CISCO
STB (set-top-box) 10.68.129.143/24
(DHCP)
P BG 1 65 00
TV-set
TenGig 1/3 10.0.23.2/30
o Lo 1
10.0.0.3/32
TenGig 1/1 10.0.13.2/30
C7609INVITEL
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!
