Multipoint LDP (mldp)

Transkript

1 Multipoint LDP (mldp) Bc. Pavel Rath (rat0009), Bc. Dalibor Zegzulka (zeg0008) Abstrakt: Popis a princip technologie Multipoint LDP, včetně postupu vysignalizování cesty a vytvoření P2MP cest a MP2MP cest. Popsané možnosti využití této technologie a ukázková topologie s popisem konfigurace zahrnující P, PE a CE směrovače. Klíčová slova: Multipoint LDP, MPLS, LDP, LSP, multicast, Cisco. 1 Úvod Popis mldp Princip mldp Výhody a využití Ukázková topologie Použitá zařízení Popis topologie Fyzické zapojení Konfigurace na zařízeních s Cisco IOS XR Základní konfigurace Konfigurace směrování Konfigurace MPLS Konfigurace multicastu Ověření funkčnosti Ukázka konfigurace na zařízeních s Cisco IOS Základní konfigurace a směrování Konfigurace MPLS Konfigurace multicastu Ověření konfigurace Závěr Použitá literatura...14 prosinec /14

2 1 Úvod 1.1 Popis mldp Zkratka mldp znamená Multipoint Label Distribution Protocol, někdy bývá technologie označována také jako Multicast Label Distribution Protocol. Tato technologie je popsána v RFC 6388 (Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths) z roku Jedná se tedy o rozšíření protokolu LDP, který je popsán v RFC 5036 (LDP Specification). Klasický protokol LDP slouží k vysignalizování cesty (tzv. Label Switched Path) pro provoz v sítí s MPLS. Protokol LDP umožňuje vytvořit point-to-point (P2P) a multipoint-to-point (MP2P) cesty. Protokol mldp potom rozšiřuje funkčnost o možnost vytvoření cest, které jsou point-to-multipoint (P2MP) a multipoint-tomultipoint (MP2MP). Dohromady jsou tyto dvě možnosti někdy označované taky jako multipoint LSPs. [1] 1.2 Princip mldp Oproti prokolu LDP, kde se při signalizaci používá pouze Label, se zde využívá navíc ještě tzv. FEC Element. FEC znamená Forwarfing Equivalence Class a jedná se vlastně o jednoznačný identifikátor pro daný záznam. FEC Element se skládá ze tří částí: typ stromu (P2MP nebo MP2MP), adresa roota (typicky IP adresa) a Opaque encoding, což je hodnota s proměnlivou délkou a obsahuje data, která využívají pouze aplikace běžící nad mldp, samotné mldp nezajímá, co je v daném poli uložené. [2] Cesta typu point-to-multipoint je pouze jednosměrná (umožňuje komunikaci pouze od roota k listům v daném stromu), naproti tomu cesty typu multipoint-to-multipoint umožňuji komunikaci i v opačném směru. Signalizace cesty začíná od listů stromu, kde jsou připojení příjemci, proto je signalizace také označována jako Receiver driven. Na Obrázku 1 je vidět signalizace cesty u P2MP LSP. Řekněme, že se jako první přípojí směrovač East a pošle směrovači Central informaci, že se za Labelem 23 nachází příjemce pro danou skupinu s FEC Elementem, ve kterém je uvedena adresa roota , typ stromu P2MP a hodnota Opaque. Signalizace potom pokračuje od směrovače Central směrem k rootovi. Když se připojí druhý příjemce za směrovačem West, tak směrovač West opět pošle informaci směrovači Central. Ten si přidá záznam do své databáze, ale už neposílá informace směrem dále k rootovi, protože tímhle směrem už vyslal informace pro danou skupinu. Směrovač Central potom při provozu daný rámec od roota duplikuje jak na směrovač West, tak na směrovač East. [2] Obrázek 1: sestavení P2MP LSP [2] prosinec /14

3 Cesta typu multipoint-to-multipoint je obousměrná a rozlišujeme tady tzv. Downstream Path a Upstream Path. Downstrem Path funguje vlastně jako P2MP LSP a Upstream Path je jako P2P LSP, ale navíc dědí Labely z Downstream Path. Na Obrázku 2 je ukázka signalizace dané cesty. Ve FEC Elementu máme nyní uveden jako typ stromu buď MP2MP down nebo MP2MP up. Řekněme, že jako první začne signalizovat opět směrovač East, vše probíhá stejně jako u P2MP, ale když signalizace dosáhne roota, tak ten zjistí z FEC Elementu, že má vysignalizovat cestu i opačným směrem (na obrázku je označeno zeleně). Po připojení směrovače West jde infromace opět směrovači Central, který stejně jako u P2MP už neposílá informaci k rootovi, protože tam je Label již přiřazen a nyní právě směrovač Central pošle zpět informaci pro Upstream Path, protože směrovač Central již zná cestu od roota (Label 30). [2] Obrázek 2: sestavení MP2MP LSP [2] 1.3 Výhody a využití Protokol mldp nám umožňuje sestavit Multipoint LSP a díky tomu můžeme provozovat v core části sítě multicasty přímo pomocí MPLS. Nepotřebujeme tedy mít v této částo sítě protokol PIM a žádné multicastové směrování. Výhodou používání Multipoint LSPs je také to, že můžeme potom využít některých jejich vlastností, jako je např. Fast Reroute. [2] K celkové funkčnosti multicastů v síti, kde na straně zákazníka běží protokol PIM a v core části sítě u poskytovatele běží MPLS s mldp je potřeba tyto protokoly provázat. Jedním způsobem je tzv. In-band Signaling, kde hraniční zařízení překládá zprávy JOIN od protokolu PIM do mldp FEC Elementu. Druhou možností je potom Out-of-band Signaling, kde se toto propojení musí nastavit ručně. Protokol mldp lze potom použít i při vytváření Multicast VPN. [3] 2 Ukázková topologie 2.1 Použitá zařízení Core vrstva dané topologie je realizována pomocí pěti virtuálních směrovačů Cisco s demoverzí IOS XR Zákaznická část topologie je realizována na třech směrovačích Cisco 2901 s verzí IOS 15.3.(2). prosinec /14

4 2.2 Popis topologie Pro náš demonstrační příklad jsme zvolili topologii, která je na Obrázku 3. Bude se jednat o metodu tzv. In-band Signaling. Tato topologie obsahuje v části core dva P směrovače a tři PE směrovače. Na straně zákazníka jsou potom dva směrovače CE v roli příjemců a jeden CE směrovač v roli zdroje multicastového provozu. Mezi P směrovači je dále zapojen rozbočovač pro umožnění odchycení provozu a ověření funkčnosti. V core části sítě běží protokoly OSPF, MPLS, LDP a mldp. Mezi směrovačemi PE a CE běží protokol EIGRP a PIM, na PE směrovačích potom dochází k redistribuci z EIGRP do OSPF. Z pohledu protokolu mldp bude jako root vystupovat směrovač PE2. Obrázek 3: ukázková topologie 2.3 Fyzické zapojení V core části sítě jsou veškeré P a PE směrovače realizovány pomocí virtuálních směrovačů s IOS XR. Na jednom fyzickém stroji byly hostovány 4 virtuální směrovače, jejichž propojení je na Obrázku 4. prosinec /14

5 Obrázek 4: propojení virtuálních směrovačů [5] Dohromady jsme použili dva tyto fyzické stroje s virtuálními směrovači. Pro propojení těchto strojů mezi sebou a propojení mezi těmito stroji a fyzickými směrovači, které byly použity jako CE směrovače, bylo využito přepínače a VLAN. Celkové fyzické zapojení je na Obrázku 5. Obrázek 5: fyzické zapojení prosinec /14

6 3 Konfigurace na zařízeních s Cisco IOS XR 3.1 Základní konfigurace Na všech zařízeních jsme podle schématu na Obrázku 4 provedli základní konfiguraci IP adres. Ukázka konfigurace IP adres na směrovačích s IOS XR: RP/0/0/CPU0:PE1(config)#interface g0/0/0/1 RP/0/0/CPU0:PE1(config-if)#ipv4 address RP/0/0/CPU0:PE1(config-if)#no shutdown Aby se jakékoliv provedené konfigurační změny na platformě IOS XR projevily, je potřeba je potvrdit příkazem commit. V rámci základní konfigurace byl nakonfigurován ještě přepínač, který nám umožňuje propojit jednotlivé virtuální stroje mezi sebou a mezi fyzickými prvky. Na přepínači byly pouze nastaveny příslušné porty jako trunk, resp. jako access porty v daných VLAN přesně podle schématu na Obrázku Konfigurace směrování Jako další krok bylo nastaveno směrování. Jak bylo popsáno výše, v části core běží směrovací protokol OSPF a mezi jednotlivými směrovači PE a CE běží EIGRP. Ukázka konfigurace směrovacího protokolu OSPF na směrovačích s IOS XR: RP/0/0/CPU0:P1(config)#router ospf 1 RP/0/0/CPU0:P1(config-ospf)#area 0 RP/0/0/CPU0:P1(config-ospf-ar)#interface GigabitEthernet0/0/0/0 RP/0/0/CPU0:P1(config-ospf-ar)#interface GigabitEthernet0/0/0/2 RP/0/0/CPU0:P1(config-ospf-ar)#interface GigabitEthernet0/0/0/3 Ukázka konfigurace EIGRP na IOS XR: (config)#router eigrp 1 (config-eigrp)#address-family ipv4 (config-eigrp-af)#interface GigabitEthernet0/0/0/3 Dále je ještě potřeba provést na směrovačích PE redistribuci EIGRP do OSPF: (config-ospf)#redistribute eigrp 1 Jako poslední krok u směrování je potřeba nastavit na směrovačích CE výchozí cestu směrem k PE směrovači: CE1(config)#ip route CE2(config)#ip route CE3(config)#ip route Konfigurace MPLS V core části sítě běží protokol MPLS. Při jeho konfiguraci můžeme buď ručně vyjmenovat rozhraní, na kterých má běžet nebo můžeme využít tzv. auto-configu pod směrovacím protokolem. Dále je potřeba nastavit také router ID, bez kterého protokol nebude fungovat. Ukázka konfigurace: (config)#router ospf 1 (config-ospf)#mpls ldp auto-config (config)#mpls ldp (config-ldp)#router-id prosinec /14

7 3.4 Konfigurace multicastu Jako první jsme nastavili protokol PIM mezi CE a PE směrovači. Na CE směrovačích vypadala konfigurace takto: (config)#ip multicast-routing (config)#interface GigabitEthernet0/0 (config-if)#ip pim dense-mode Na směrovačích PE s IOS XR byla konfigurace: (config)#multicast-routing (config-mcast)#address-family ipv4 (config-mcast-default-ipv4)#interface GigabitEthernet0/0/0/3 enable (config)#router pim (config-pim)#address-family ipv4 (config-pim-default-ipv4)#interface GigabitEthernet0/0/0/3 (config-pim-ipv4-if)#enable Na směrovačích CE1 a CE3 bylo dále nastaveno IGMP, kde zdrojovou adresou je adresa na rozhraní Loopback 0 od směrovače CE2: CE1(config)#interface Loopback 0 CE1(config-if)#ip join-group source CE3(config)#interface Loopback 0 CE3(config-if)#ip join-group source Posledním krokem je zapnutí samotného mldp v core části sítě. To je potřeba nastavit na všech P a PE směrovačích: (config)#mpls ldp (config-ldp)#mldp (config-ldp-mldp)#address-family ipv4 4 Ověření funkčnosti Při ověřování funkčnosti jsme postupovali postupnými kroky. Jako první jsme ověřili, zda funguje unicastové směrování mezi koncovými sítěmi pomocí pingu: CE2#ping source loopback 0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds: Packet sent with a source address of !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/20/88 ms Ping jsme odchytili i pomocí programu Wireshark a zjistili, že provoz jde opravdu přes MPLS: prosinec /14

8 Obrázek 6: ping mezi koncovými sítěmi Na P1 směrovači jsme nahlédli do forwarding tabulky od MPLS: RP/0/0/CPU0:P1#show mpls ldp forwarding Prefix Label Label(s) Outgoing Next Hop Flags In Out Interface G S R / ImpNull Gi0/0/0/ / ImpNull Gi0/0/0/ / Gi0/0/0/ / ImpNull Gi0/0/0/ / Gi0/0/0/ / Gi0/0/0/ / Gi0/0/0/ Dále jsme ověřili sousedské vazby v protokolu PIM mezi směrovači CE a PE: CE2#show ip pim neighbor PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, P - Proxy Capable, S - State Refresh Capable, G - GenID Capable Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode GigabitEthernet0/0 00:18:12/00:01:29 v2 1 / P G RP/0/0/CPU0:PE2#show pim neighbor PIM neighbors in VRF default Flag: B - Bidir capable, P - Proxy capable, DR - Designated Router, E - ECMP Redirect capable * indicates the neighbor created for this router Neighbor Interface Uptime Expires DR pri Flags Address * GigabitEthernet0/0/0/3 00:19:35 00:01:39 1 B P E GigabitEthernet0/0/0/3 00:19:33 00:01:20 1 (DR) P Z ukázaných výpisu lze vidět, že zatím vše funguje podle předpokladů. Nyní jsme ověřovali, zda běží protokol mldp: prosinec /14

9 RP/0/0/CPU0:P1#show mpls mldp status mldp statistics Process status : Active, Running and Ready Multipath upstream : Enabled Multipath downstream : Enabled Logging notifications : Disabled Database count : 0 Label release scan in : never LSM ID scan in : never RIB connection status : Connected RIB connection open : Yes TE Intact : Disabled Active RIB table : default/ipv4/unicast Table Name AFI SAFI RIB converged Table ID Table Name AFI SAFI RIB converged Table ID : default : IPv4 : Unicast : Yes : E : default : IPv4 : Multicast : Yes : E Z výpisu lze vidět, že mldp běží. Při zapnutí protokolu mldp jsme měli spuštěný Wireshark, kde jsme odchytili Label Request Message od tohoto protokolu: prosinec /14 Obrázek 7: zachycený Label Request Message

10 Dále jsme ověřovali sousedské vazby protokolu mldp: RP/0/0/CPU0:P1#show mpls mldp neighbors mldp neighbor database MLDP peer ID : :0, uptime 00:21:13 Up, Capabilities : Typed Wildcard FEC, P2MP, MP2MP Target Adj : No Upstream count : 0 Branch count : 0 Label map timer : never Policy filter in : None Path count : 1 Path(s) : GigabitEthernet0/0/0/2 No LDP Adj list : GigabitEthernet0/0/0/2 Peer addr list : : MLDP peer ID : :0, uptime 00:21:01 Up, Capabilities : Typed Wildcard FEC, P2MP, MP2MP Target Adj : No Upstream count : 0 Branch count : 0 Label map timer : never Policy filter in : None Path count : 1 Path(s) : GigabitEthernet0/0/0/3 No LDP Adj list : GigabitEthernet0/0/0/3 Peer addr list : : MLDP peer ID : :0, uptime 00:21:09 Up, Capabilities : Typed Wildcard FEC, P2MP, MP2MP Target Adj : No Upstream count : 0 Branch count : 0 Label map timer : never Policy filter in : None Path count : 1 Path(s) : GigabitEthernet0/0/0/0 No LDP Adj list : GigabitEthernet0/0/0/0 Peer addr list : : Z výpisu lze vidět, že sousedské vazby v protokolu mldp jsou navázány. Dalším krokem při ověření tedy bylo zobrazení mldp databáze, kde jsme očekávali záznam pro roota: RP/0/0/CPU0:P1#show mpls mldp database No entries in the table to display Z výpisu jsme zjistili, že databáze je prázdná. Zkusili jsme další příkaz pro ověření, že proces běží: RP/0/0/CPU0:P1#show mpls mldp database standby mldp is not running ( ) Zde jsme se dozvěděli, že mldp neběží, i když příkaz show mpls mldp status vypisuje, že je proces aktivní a běží. Nakonec jsme zkusili ještě jeden ověřovací příkaz: prosinec /14

11 RP/0/0/CPU0:P1#show mpls mldp status standby Could not get sysdb_item_get A ten nám vrátil systémovou chybu. Celkovou komunikaci jsme chtěli ověřit pomocí pingu ze směrovače CE2: CE2#ping source loopback 0 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to , timeout is 2 seconds: Packet sent with a source address of Tento ping samozřejmě neprošel, protože mldp databáze je prázdná. Na základě předchozích výpisů jsme došli k závěru, že protokol mldp není na dané demoverzi IOS XR funkční nebo je funkční jen z části, o čemž nás přesvědčily hlavně výpisy show mpls mldp status a show mpls mldp status standby, kde jeden výpis tvrdí, že mldp běží a druhý, že neběží. 5 Ukázka konfigurace na zařízeních s Cisco IOS 5.1 Základní konfigurace a směrování Na všech směrovačích je potřeba nastavit příslušné IP adresy a rozhraní zapnout. V core části se na všech rozhraních zapne směrovací protokol OSPF a mezi směrovači PE a CE se zapne směrovací protokol EIGRP. Na směrovačích PE je potřeba nastavit redistribuci z EIGRP do OSPF pomocí příkazů: (config)#router ospf 1 (config-router)#redistribute eigrp 1 Dále je potřeba nastavit na směrovačích CE výchozí cestu směrem k PE směrovači: CE1(config)#ip route CE2(config)#ip route CE3(config)#ip route Konfigurace MPLS Na všech směrovačích v core části je potřeba globálně zapnout MPLS: (config)#mpls label protocol ldp (config)#mpls ldp A poté na jednotlivých rozhraních v core části nastavit MPLS (odpovídá rozhraním, kde běží OSPF): (config-if)#mpls ip 5.3 Konfigurace multicastu Mezi směrovači PE a CE musí běžet protokol PIM. Nejdříve globálně povolíme multicast: (config)#ip multicast-routing A dále na příslušném rozhraní směrem k sousedícímu PE nebo CE směrovači nastavíme: (config-if)#ip pim dense-mode prosinec /14

12 Na směrovačích CE1 a CE3 je nutno nastavit IGMP se zdrojovou adresou od rozhraní Loopback 0 směrovače CE2: CE1(config)#interface Loopback 0 CE1(config-if)#ip join-group source CE3(config)#interface Loopback 0 CE3(config-if)#ip join-group source Nyní už zbývá pouze zapnout protokol mldp v core části sítě: (config)#ip multicast mpls mldp Případně si ještě můžeme zapnout logování zpráv od tohoto protokolu: (config)#mpls mldp logging notifications 5.4 Ověření konfigurace Při ověřování funkčnosti lze postupovat stejnými kroky jako u naší ukázkové topologie realizované na IOS XR. První je potřeba ověřit směrování mezi koncovými sítěmi: CE2#ping source loopback 0 Funkčnost MPLS lze ověřit pomocí náhledu do forwarding tabulky: P1#show mpls forwarding-table Navázané sousedské vazby protokolu PIM lze ověřit pomocí: CE2#show ip pim neighbor Funkčnost protokolu mldp lze ověřit pomocí následujících příkazů: #show mpls mldp interface #show mpls mldp neighbors #show mpls mldp status #show mpls mldp database prosinec /14

13 6 Závěr V tomto projektu bylo popsáno rozšíření protokolu LDP pro podporu multicastu v core části sítě. Byl vysvětlen princip tohoto mldp protokolu. Dále byl popsán postup jak se spojení navazuje, a to jak v topologii typu point-to-multipoint, tak v topologii multipoint-to-multipoint. Nakonec byla navržena, zapojena a nakonfigurována ukázková topologie s využitím protokolu mldp na směrovačích s platformou IOS XR. Pro otestování funkčnosti na platformě IOS, jsme bohužel neměli k dispozici příslušné zařízení s verzí IOS, která by tento protokol podporovala, a proto byla konfigurace pouze sepsána. Přes veškerou snahu se nám bohužel nepodařilo multicast za pomocí mldp rozchodit. To přisuzujeme omezení demoverze platformy IOS XR, na které konfigurace proběhla. Každopádně se jedná o poměrně novou technologii, která podle nás bude mít v praxi časem využití. prosinec /14

14 7 Použitá literatura [1] RFC 6388 [online]. Dostupné z: [2] Cisco Live! Session BRKIPM-3111 Multipoint LDP (2013 London) [online]. Dostupné z: [3] Using MPLS and M-LDP Signaling for Multicast VPNs [online]. Dostupné z: [4] Cisco Live! Session LTRIPM-3314 Advanced-Multipoint LDP (2014 Milan) [online]. Dostupné z: [5] Zapojení IOS XR [online]. Dostupné z: prosinec /14