html5-img
1 / 42

Inter-domain Multicast

Inter-domain Multicast. MBGP & Inter-domain SSM. MBGP. Multiprotocol extensions to BGP MBGP overview MBGP capability negotiation Multicast Reachability. MBGP Overview. MBGP: Multiprotocol BGP (aka multicast BGP in multicast networks)

hyman
Download Presentation

Inter-domain Multicast

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Inter-domainMulticast

  2. MBGP & Inter-domain SSM

  3. MBGP • Multiprotocol extensions to BGP • MBGP overview • MBGP capability negotiation • Multicast Reachability

  4. MBGP Overview • MBGP: Multiprotocol BGP(aka multicast BGP in multicast networks) • Makes it possible for multicast routing policies to differ from unicast routing policies • Defined in RFC 2283 (extensions to BGP) • Can carry different route types for different purposes • Unicast • Multicast • Both route types carried in same BGP session • Does not propagate multicast state information • Same path selection and validation rules • AS-Path, LocalPref, MED, …

  5. MBGP • Tag unicast prefixes as multicast source prefixes for intra-domain mcast routing protocols to do RPF checks. • WHY? Allows for inter-domain RPF checking where unicast and multicast paths are non-congruent. • DO I REALLY NEED IT? • YES, if: • ISP to ISP peering • Multiple-homed networks • NO, if: • You are single-homed

  6. New multiprotocol attributes • Network Layer Reachability Information (NLRI) • MP_REACH_NLRI and MP_UNREACH_NLRI • Address Family Information (AFI) = 1 (IPv4) • Sub-AFI = 1 (NLRI is used for unicast forwarding) • Sub-AFI = 2 (NLRI is used for multicast RPF check and MSDP peer-RPF check)

  7. MBGP — Capability Negotiation • BGP routers establish BGP sessions through the OPEN message • OPEN message contains optional parameters • BGP session is terminated if OPEN parameters are not recognised • New parameter: CAPABILITIES • Multiprotocol extension • Multiple routes for same destination • Configures router to negotiate either or both NLRI • If neighbor configures both or subset, common NLRI is used in both directions • If there is no match, notification is sent and peering doesn’t come up • If neighbor doesn’t include the capability parameters in open, session backs off and reopens with no capability parameters • Peering comes up in unicast-only mode

  8. RIB Groups and JUNOS • In JUNOS, a routing table is called a RIB (Routing Information Base) • Different RIBs are used for different functions • inet.0 - IPv4 unicast routes • inet.1 - IPv4 multicast forwarding cache (incoming/outgoing interface lists) • inet.2 - IPv4 multicast RPF table • inet.3 - MPLS next-hops for BGP resolution • inet.4 - MSDP SAs • inet6.0 - IPv6 unicast routes, etc. • RIB group configuration is very powerful, but not very intuitive • You can do anything if you can figure out how!

  9. Multicast RPF Table • By default, PIM and MSDP use inet.0 for RPF lookups • To use a dedicated RPF table • populate inet.2 • configure PIM and MSDP to use inet.2 • RPF table contains only unicast routes • Used for RPF checks for source or RP address • Never contains multicast groups!

  10. Create RIB Groups • Create RIB groups, and put in static, connected and OSPF routes routing-options { interface-routes { rib-group inet if-rib; } static { rib-group static-rib; } rib-groups { mcast-rpf-rib { import-rib inet.2; } if-rib { import-rib [ inet.0 inet.2 ]; } static-rib { import-rib [ inet.0 inet.2 ]; } ospf-rib { import-rib [ inet.0 inet.2 ]; } } } protocols { ospf { rib-group ospf-rib; } }

  11. MBGP • By default, any routes with SAFI=2 will be put into inet.2 • Just need to configure the BGP sessions to support multicast NLRI • Can be applied to all peers, or individual peers protocols { bgp { family inet { unicast; multicast; } } }

  12. PIM and MSDP • Finally, tell PIM and MSDP to use inet.2 when they do RPF checks protocols { msdp { rib-group inet mcast-rpf-rib; } pim { rib-group inet mcast-rpf-rib; } }

  13. Cisco IOS Multicast Reachability • Unicast forwarding never uses the AF=Multicast reachability topology • PIM uses both the AF=Unicast and the AF=Multicast topologies • Use show ip rpf to see what’s really going on • show ip mbgp lets you see some AF=Multicast routes

  14. Cisco IOS Multicast Reachability • Distance-preferred lookups (default) • Every route has an “administrative distance” • “Best match” is the route with the lowest administrative distance, regardless of Address Family • Longest-prefix match (hidden command option) • Top-level configuration: ip multicast longest-match • Best match is the most specific route in either the AF=Multicast or AF=Unicast tables. • Ties between AF=Multicast and AF=Unicast routes • Broken in favor of the AF=Multicast route

  15. Cisco IOS Multicast Reachability Example 1: • 140.221.201.0/24 AF=Multicast AD=20  Ethernet 0/0140.221.201.128/27 AF=Unicast AD=200  Ethernet 0/1 • Distance-Preferred Lookup of 140.221.201.129 • Administrative Distance of 20 dominates, so show ip rpf 140.221.201.129 will select Ethernet 0/0 • Longest-prefix Match Lookup of 140.221.201.129 • Longest prefix of /27 dominates, so show ip rpf 140.221.201.129 will select Ethernet 0/1

  16. Cisco IOS Multicast Reachability Example 2: • 140.221.201.0/24 AF=Multicast AD=200  Ethernet 0/0 140.221.201.0/24 AF=Unicast AD=200  Serial 0/0 • Ties are broken in favor of the AF=Multicast route • show ip rpf 140.221.201.161 will select Ethernet 0/0 Note that the default in IOS is to make the unicast AD and multicast AD equal, as in this example.

  17. MBGP — Summary • Solves part of inter-domain problem • Can exchange unicast prefixes for multicast RPF checks • Uses standard BGP configuration knobs • Permits separate unicast and multicast topologies if desired • Still must use PIM to: • Build distribution trees • Actually forward multicast traffic

  18. ssmping • A tool for testing multicast connectivity • www.venaas.no/multicast/ssmping/ • Developed by Stig Venaas (stig.venaas@uninett.no) • Behavior is a bit like normal ping • A server must run ssmpingd • A client can ping a server by sending unicast ssmping query • Server replies with both unicast and multicast ssmping replies • In this way a client can check that it receives SSM from the server • And also parameters like delay, number of router hops etc.

  19. How ssmping works Client Server User runs ssmping <S> Client joins S,G Clients sends unicast to S t t Server receives unicast ssmping query Responds with ssmping unicast reply and multicast reply to G Client receives replies and prints RTT and hops from server Client sends a new query every second

  20. Example output -bash-3.00$ ssmping -c 5 -4 ssmping.uninett.no ssmping joined (S,G) = (158.38.62.21,232.43.211.234) pinging S from 129.241.210.1 unicast from 158.38.62.21, seq=0 dist=15 time=72.874 ms unicast from 158.38.62.21, seq=1 dist=15 time=72.663 ms multicast from 158.38.62.21, seq=1 dist=9 time=76.502 ms unicast from 158.38.62.21, seq=2 dist=15 time=72.056 ms multicast from 158.38.62.21, seq=2 dist=9 time=73.556 ms unicast from 158.38.62.21, seq=3 dist=15 time=72.232 ms multicast from 158.38.62.21, seq=3 dist=9 time=73.579 ms unicast from 158.38.62.21, seq=4 dist=15 time=72.513 ms multicast from 158.38.62.21, seq=4 dist=9 time=73.256 ms --- 158.38.62.21 ssmping statistics --- 5 packets transmitted, time 5004 ms unicast: 5 packets received, 0% packet loss rtt min/avg/max/std-dev = 72.056/72.467/72.874/0.415 ms multicast: 4 packets received, 20% packet loss 0% loss since first multicast packet received (after 1077 ms) rtt min/avg/max/std-dev = 73.256/74.223/76.502/1.335 ms -bash-3.00$

  21. What does the output tell us? • 15 unicast hops from source, only 9 multicast, so tunneling likely • Multicast RTTs are larger and vary more • Difference in unicast and multicast RTT shows one way difference for unicast and multicast replies, since they are replies to the same request packet • Multicast tree not ready for 1st multicast reply, OK for 2nd after 1077ms • No unicast loss, no multicast loss after tree established

  22. Lab 4MBGP & Inter-domain SSM Time: Approx. 3 hours

  23. MSDP & Inter-domain ASM • A PIM domain is a network in which all routers use the same RP for any given multicast group. • Inter-domain SSM is easy. Because you know the IP address of the source, you can issue PIM joins that leave your PIM domain and travel hop by hop across as many PIM domains as necessary. • Inter-domain ASM requires another protocol: Multicast Source Discovery Protocol (MSDP). • Why? Because the receiver is restricted to sending only (*,G) joins to its RP. And its RP doesn’t know where the source is, because the source is registered to a different RP. MSDP is needed for the receiver's RP to find the (S,G). • Officially, MSDP is a temporary solution. We shall see.

  24. MSDP • MSDP sets up peering between RPs in different domains. • RFC 3618 • These MSDP Peer RPs pass Source Active (SA) messages for every (S,G) they know about. • The receiver’s RP thus knows about the source, and can implement a direct (S,G) Join from the RP to the source. • This sets up an SPT to the local RP. • Then the routing can switch over to a direct SPT to the receiver in the usual fashion.

  25. MSDP Operation — Flood & Join • Flood • SA (source active) packets periodically sent to MSDP peers indicating: • source address of active streams • group address of active streams • IP address of RP originating the SA • RPs only originate SAs for your sources within your domain • Join • Interested parties can send joins towards source (this creates inter-domain shortest path trees)

  26. MSDP Source Active Messages • Initial SA message sent when source DR first registers • May optionally encapsulate first data packet • Supports SAP / SDR • Should be treated as if it was a PIM register packet • Originating RP sends subsequent SA messages every 60 seconds, for as long as source remains active • Other MSDP peers don’t originate this SA but only forward it if received • SA messages must be cached on router • Recent change to Draft • Reduces join latency for new group members that might join • Prevents SA storm propagation

  27. RP RP RP RP RP r SA Join (*, 224.2.2.2) SA SA SA SA SA SA Message192.1.1.1, 224.2.2.2 s SA Message192.1.1.1, 224.2.2.2 Register 192.1.1.1, 224.2.2.2 MSDP Overview Domain E MSDP Peers SA Source ActiveMessages Domain C Domain B Domain D Domain A

  28. RP RP RP RP RP Multicast Traffic r Join (S, 224.2.2.2) Join (S, 224.2.2.2) Join (S, 224.2.2.2) s MSDP Overview Domain E MSDP Peers Domain C Domain B Domain D Domain A

  29. MSDP Peers (inter-domain case) • MSDP establishes a neighbor relationship between MSDP peers • Peers connect using TCP port 639 • Peers send keepalives every 60 secs (fixed) • Peer connection reset after 75 seconds if no MSDP packets or keepalives are received • MSDP peers must have knowledge of multicast topology. • May be an MBGP peer, a BGP peer or both • Required for peer-RPF checking of the RP address in the SA to prevent SA looping. Note that this is not the same thing as the multicast routing RPF check. • Exception: BGP is unnecessary when peering with only a single MSDP peer (default-peer)

  30. MSDP so far • Allows RPs to share information about which sources in their domains are active sending. • Interconnects RPs (MSDP Peers) between domains, using TCP connections to pass source active messages (SAs). • SAs are Peer-RPF checked before accepting or forwarding. • RPs may trigger (S,G) Joins on behalf of local receivers. • MSDP connections typically parallel MBGP connections. • Next: Peer-RPF checking in detail. This is complex.

  31. MSDP RPF Rules If any of the following tests pass, the SA is accepted. For any given (S,G), there can be one or more accepted SAs in the SA cache. • The MSDP peer sending the SA is the originating RP • The MSDP peer sending the SA is the eBGP next hop for the originating RP • The MSDP peer sending the SA is the iBGP advertiser for the originating RP • The MSDP peer sending the SA is in the same AS as the next hop for the originating RP • The MSDP peer sending the SA is statically configured to be the RPF peer

  32. Receiving SA Messages • RPF Check rule example cases • Case 1: Sending MSDP Peer = iMBGP peer • Case 2: Sending MSDP Peer = eMBGP peer • Is best path to RP via this MBGP peer? • Case 3: Sending MSDP Peer != BGP peer • Is the next AS in best path to RP = AS of the sending MSDP peer?

  33. RPF Check Example #1 SA decision on router B Group address Source address Peer address Originator 233.0.87.1 129.79.19.170 172.16.0.2 172.16.0.2 AS2 Yes. 1.) Is the MSDP peer == originating RP? 3.2 4.2 B 4.1 3.1 2.1 2.2 RP AS1 AS3 C A Source RPF Success! rp { local { address 172.16.0.2; MSDP SA MSDP/MBGP peering

  34. RPF Check Example #2 RPF Success! SA decision on router B Group address Source address Peer address Originator 233.0.87.1 129.79.19.170 172.16.3.1 172.16.0.2 AS2 No. 1.) Is the MSDP peer == originating RP? 2.) Is the MSDP peer == eBGP next hop for originating RP route? 3.2 Yes. 4.2 B MBGP Table router B A Destination Next hop AS path * 172.16.0.2/32 >172.16.3.1 1 i 4.1 3.1 2.2 2.1 RP AS1 AS3 C A Source rp { local { address 172.16.0.2; MSDP SA MSDP/MBGP peering

  35. RPF Check Example #3 RPF Success! rp { local { address 172.16.10.2; RP AS2 Source SA decision on router A 3.2 Group address Source address Peer address Originator 233.41.184.1 134.68.1.1 172.16.2.2 172.16.10.2 4.2 B No. 1.) Does the MSDP peer == originating RP? 2.) Does the MSDP peer == eBGP next hop for originating RP route? 4.1 3.1 No. 2.2 2.1 MBGP Table router A A Destination Next hop AS path * 172.16.10.2/32 >172.16.2.2 1 i AS1 C A 3.) Does the MSDP peer == iBGP/IGP advertiser for originating RP route? Yes. MBGP Table router A A Destination Next hop AS path * 172.16.10.2/32 >172.16.2.2 1 i MSDP SA MSDP/MBGP peering

  36. RPF Check Example #4 RPF Success! SA decision on router B Group address Source address Peer address Originator 233.0.87.1 129.79.19.170 172.16.3.1 172.16.0.2 AS2 No. 1.) Does the MSDP peer == originating RP? 2.) Does the MSDP peer == BGP next hop for originating RP route? No. 3.2 4.2 B MBGP Table router B A Destination Next hop AS path * 172.16.0.2/32 >172.16.4.1 1 i 3.1 4.1 3.) Does the MSDP peer == iBGP advertiser for originating RP route? 2.2 2.1 No. RP AS1 C A 4.) Is the MSDP peer in the same AS as the first AS in the best path for the originating RP route? Yes. Source MBGP Table router B A Destination Next hop AS path * 172.16.0.2/32 >172.16.4.1 1 i * 172.16.3.1/32 >172.16.4.1 1 i rp { local { address 172.16.0.2; MSDP SA MSDP/MBGP peering

  37. RPF Check Example #5 RPF Failure! SA decision on router B Group address Source address Peer address Originator 233.0.87.1 129.79.19.170 172.16.3.1 172.16.0.2 AS2 No. 1.) Does the MSDP peer == originating RP? 2.) Does the MSDP peer == eBGP next hop for originating RP route? No. 3.2 4.2 B MBGP Table router B A Destination Next hop AS path * 172.16.0.2/32 >172.16.4.1 3 1 i 4.1 3.1 3.) Does the MSDP peer == iBGP advertiser for originating RP route? 2.2 2.1 No. RP AS1 AS3 C A 4.) Is the MSDP peer in the same AS as the first AS in the best path for the originating RP route? No. MBGP Table router B A Destination Next hop AS path * 172.16.0.2/32 >172.16.4.1 3 1 i * 172.16.3.1/32 >172.16.4.1 1 i Source rp { local { address 172.16.0.2; MSDP SA MSDP/MBGP peering

  38. MSDP debug • To check why an MSDP SA is/isn’t accepted or not on a Cisco you can log your cache rejections: • ip msdp cache-rejected-sa <#entries to log> • sho ip msdp sa-cache [<group> <source>] rejected-SA detail read-only • To get more details on why an MSDP SA is/isn’t accepted turn on MSDP peer debugging. If you do this, watch out! Lots of messages will follow! It may kill your router. • See RFC 3618 for details.

  39. MSDP Application: Anycast-RP • MSDP used intra-domain to provide RP redundancy • Becoming best common practice for large networks • Specified in RFC 3446 • Allows deployment of multiple RPs within a domain (for the same group range) • Adding more RPs does not require changes to non-RP routers • Sources and receivers use closest RP, as determined by the IGP • RPs share information about sources via MSDP mesh group • Note: MSDP peering uses normal address, notAnycast-RP address

  40. MSDP Application: Anycast-RP • Rules are fairly simple • Have e-MSDP peers and i-MSDP peers, similar to BGP • If a mesh group member originates a SA message • Send to all i-MSDP peers and any e-MSDP peers • If a mesh group member receives a SA message from an i-MSDP peer • Send to any e-MSDP peers • Do NOT send to other i-MSDP peers • If a mesh group member received a SA message from an e-MSDP peer • Check RPF — if passes, then • Flood to all i-MSDP peers and any other e-MSDP peers.

  41. MSDP Anycast-RP RP1 lo0: 10.0.0.100 lo1: 10.0.0.1 Src Rec Rec RP2 lo0: 10.0.0.200 lo1: 10.0.0.1 Rec Rec Src Anycast RP address is 10.0.0.1 MSDP peering is between 10.0.0.100 and 10.0.0.200

  42. Anycast-RP RP1 lo0: 10.0.0.100 lo1: 10.0.0.1 Src Rec X Rec RP2 lo0: 10.0.0.200 lo1: 10.0.0.1 Rec Rec Src Anycast RP address is 10.0.0.1 MSDP peering is between 10.0.0.100 and 10.0.0.200

More Related