1 / 28

Multicast Implementation

Multicast Implementation. Multicast Forwarding Overview. Multicast forwarding overview: Unicast forwarding bases decisions on destination IP address Forwards traffic to the next hop of the best route Multicast forwarding bases decisions on source IP address

larrybrothers
Download Presentation

Multicast Implementation

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. Multicast Implementation

  2. Multicast Forwarding Overview • Multicast forwarding overview: • Unicast forwarding bases decisions on destination IP address • Forwards traffic to the next hop of the best route • Multicast forwarding bases decisions on source IP address • Forwards traffic away from the source along the distribution tree • Forwards only traffic that passes RPF check • RPF: • Prevents looped and duplicated multicast packets • Compares incoming interface of multicast packet with outgoing next-hop interface of unicast route toward the source of the packet • If interfaces are the same: passes the RPF check • If interfaces are different: fails the RPF check

  3. Multicast Forwarding Terms • Multicast forwarding terms: • Incoming interface or upstream interface • Interface on which traffic is received that passes the RPF check • Interface to which PIM join messages are sent • Outgoing interface list or downstream interfaces • Interfaces to which traffic must be forwarded down the distribution tree • Forwarding decision is cached in the inet.1 table

  4. Multicast Routing Tables • Multicast routing tables: • inet.0 • Default table used for RPF check lookups • inet.1 • Forwarding cache for successful RPF-checked traffic • inet.2 • Alternate table for RPF check lookups • Multicast topology independent from unicast topology • Use of RIB groups required

  5. PIM Sparse Mode Overview (1 of 2) • Sparse mode: • Assumes sparse distribution of receivers • More realistic scenario for most networks • Explicit join model • Multicast traffic is forwarded only to routers that explicitlyrequest it • More complicated source discovery mechanism required • RP is required for source discovery in any source multicast model • Source-specific multicast does not require RP • Source discovery becomes an application issue

  6. PIM Sparse Mode Overview (2 of 2) • Sparse mode: • Shared tree (*, G) • Initial forwarding state in routers assumes path through RP • Potential suboptimal path between source and receivers • Source-based tree (S,G) • Router nearest to receiver learns about source when receiving traffic • If source is known, the router can switch to shortest path between source and receiver

  7. PIM Sparse Mode: RP Considerations • An RP is essential to PIM sparse mode functionality because it allows messages from the source and the receiver to meet • Placement of RP • Prevent suboptimal routing across SPT • Redundancy of RP • Per specific multicast group only 1 RP can be used (different groups can use different RPs) • Failover options dependent on RP discovery mechanism • Tunnel service capabilities required on RP and source DR • Might require additional hardware on some Junos platforms • If source DR is also RP, then no tunneling required

  8. PIM Sparse Mode: RP Discovery • PIM sparse mode has three ways of discovering the RP: • Static RP • Easiest but by default, no failover • Auto-RP • BSR defined in RFC 5059 • Multiple discovery options can be used at the same time • Preference is BSR over auto-RP over static • Anycast-RP can be used with each of these discovery mechanisms to improve redundancy • Improves failover times significantly

  9. PIM Sparse Mode: Configuration Basics • PIM sparse mode configuration is very dependent on the RP discovery mechanism in use • RP mechanism determines interface mode: • Static RP: sparse mode • Auto-RP: sparse-dense mode • BSR: sparse mode • RP-specific configuration items • Auto-RP: • Mapping agent and candidate RPs • Dense flooding for 224.0.1.39 / 224.0.1.40 • BSR: • Bootstrap router and candidate RPs • Works with PIM version 2 only

  10. PIM Sparse Mode: Tunneling Requirements • Both RP and the source DR need tunneling capabilities to send and receive register messages • Not needed if the source DR = RP • Tunneling capabilities are platform dependent and additional hardware might be needed • MX Series line cards can be configured to provide tunneling capabilities

  11. PIM Sparse Mode: Optional Configuration • Shortest-path tree cutover control • Policy applied on the last hop router so that only the RPT is used • PIM join load balancing • Normally if multiple equal-cost paths towards the source exist, only one will pass the RPF check • For PIM sparse mode, load sharing can be enabled so that all equal-cost links can be used on an (S,G) by (S,G) basis

  12. MSDP Overview • Communicates information about active sources between RPs • Interdomain RPs • Intradomain RPs • Anycast-RP uses MSDP to improve failover time • Typically runs on PIM sparse mode RP routers • RP learns about the source and establishes a source tree towards the source if it has any receivers for this group • When traffic arrives at the receiver router, it establishes its own source tree back to the source • MSDP sets up peer relationships using TCP • Exchange SA messages

  13. MSDP Operation • MSDP peer states: • Disabled: Peer is not configured • Inactive: Peer is configured but not listening or connecting • Connect : Active peer attempts to initiate TCP session • Listen: Passive peer is configured and listening on port 639 • Established: TCP session is established • SA message flooding: • SA message is sent when the source registers with the RP • If the source is still active, the RP will resend the SA message every 60 seconds • SA messages are cached on receiving peers (inet.4)

  14. MSDP Source-Active Peer-RPF Overview • MSDP floods SA messages to all peers except the peer from which it received it • Duplicate messages might be received from peers • Peer-RPF check is performed to minimize unnecessary flooding of SA messages • Originating RP inside the SA message is basis of RPF check • RPF peer must be the same as the router that the SA message is from • Multiple peer-RPF rules • First match determines the RPF peer • Only if peer-RPF check is successful, are SA messages accepted and forwarded to other peers

  15. MSDP Peer-RPF Check Rules • Peer-RPF succeeds if: • Originating RP is an MSDP peer of local router, the originating RP is the sending MSDP peer • SA message is received from non-originating RP when: • Advertising MSDP peer is BGP next hop for originating RP • Adverting MSDP peer’s IGP next hop is the same as the next-hop to the originator RP • Advertising MSDP peer belongs to last AS listed in the BGP route path towards the originating RP • Peer-RPF check is not performed if: • SA message is received from MSDP peer in mesh group • SA message is received from default MSDP peer

  16. Anycast-RP Overview (1 of 2) • PIM sparse mode allows only a single RP per group • Limits redundancy options for RP • Failover time is typically high • Load sharing can be performed only between groups • Anycast-RP enables multiple RPs per group • Multiple RPs share an identical IP address (anycast address) • Sources and receivers use the closest RP determined by unicast routing table • Redundancy is significantly better • Failover time is only dependent on IGP convergence • Load sharing within a group is now possible

  17. Anycast-RP Overview (2 of 2) • Source and receiver can connect to different RPs for the same multicast group • Enables load sharing within a specific group • Need for additional solution to let source and receiver meet • MSDP: Supports only IPv4 • PIM: Supports both IPv4 and IPv6

  18. Basic Anycast-RP Configuration • Create the unique host address by configuring a unique IP address on the loopback interface • Set the primary address flag • Beware of router ID issues for OSPF, BGP, etc. • Use the router-id command in [edit routing-options] to be sure • Configure the non-unique unicast address used for anycast-RP on the loopback interface • Assign this address as the local RP within PIM on the RP routers • Non-RP routers can learn the anycast-RP information using any discovery mechanism (typically static RP)

  19. Task and Topology Rec1 R1 S1 R3 .37 .21 .6 • Task • R1 and R3 are RPs for the PIM domain, and the RPs must support load balancing for a given group. The RPs must also support IPv6 for future implementation. Rec2 must always use the RPT, inet.0 cannot be altered, and RIB groups cannot be used to accomplish this task. ge-0/0/2 ge-0/0/4 ge-0/0/1 ge-0/0/4 .2 .5 .18 ge-0/0/1 ge-0/0/5 ge-0/0/2 ge-0/0/3 Rec2 .1 .17 .13 ge-0/0/1 ge-0/0/4 ge-0/0/6 .57 .14 R4 R2

  20. What Now? • What are the required components? • PIM sparse mode • The RPs must load balance the same group • Is PIM anycast-RP required? Yes • Can MSDP be used for this task? No • How can you make joins from Rec2 always use the shared tree and not cutover to the source tree, without altering inet.0? • Will altering inet.2 work? Yes, but you are not allowed to use RIB groups • Create a policy to not allow the SPT cutover to take place • Where is the policy applied? R2

  21. Task Completion (1 of 3) • Configure PIM sparse mode on all routers lab@R2> show configuration protocols pim rp { static { address 172.27.255.11; } } interface all; interface ge-0/0/0.0 { disable; } lab@R4> show configuration protocols pim rp { static { address 172.27.255.11; } } interface all; interface ge-0/0/0.0 { disable; }

  22. Task Completion (2 of 3) • Configuring PIM anycast-RP • Make sure to configure a non-unique secondary lo0 address lab@R3> show configuration interfaces lo0 unit 0 { family inet { address 172.27.255.3/32 { primary; } address 172.27.255.11/32; } } lab@R3> show configuration protocols pim rp { local { family inet { address 172.27.255.11; anycast-pim { rp-set { address 172.27.255.1; } local-address 172.27.255.3; } } } } …

  23. Task Completion (3 of 3) • Create a policy to not allow the SPT cutover on R2 lab@R2> show configuration policy-options policy-statement rpt-only term 1 { from { route-filter 224.1.1.1/32 exact; source-address-filter 172.27.0.38/32 exact; } then accept; } term 2 { then reject; } lab@R2> show configuration protocols pim spt-threshold { infinity rpt-only; } rp { static { address 172.27.255.11; } } interface all; interface ge-0/0/0.0 { disable; }

  24. Task Verification (1 of 4) • Verify PIM neighborship lab@R3> show pim neighbors Instance: PIM.master B = Bidirectional Capable, G = Generation Identifier, H = Hello Option Holdtime, L = Hello Option LAN Prune Delay, P = Hello Option DR Priority Interface IP V Mode Option Uptime Neighbor addr ge-0/0/1.0 4 2 HPLG 01:04:18 172.27.0.1 ge-0/0/4.0 4 2 HPLG 01:04:18 172.27.0.6 lab@R4> show pim neighbors Instance: PIM.master B = Bidirectional Capable, G = Generation Identifier, H = Hello Option Holdtime, L = Hello Option LAN Prune Delay, P = Hello Option DR Priority Interface IP V Mode Option Uptime Neighbor addr ge-0/0/3.0 4 2 HPLG 3d 23:00:19 172.27.0.2 ge-0/0/6.0 4 2 HPLG 3d 23:00:11 172.27.0.13

  25. Task Verification (2 of 4) • Verify PIM anycast-RP configuration • Make sure both RPs will support the same group range lab@R1> show pim rps extensive Instance: PIM.master Address family INET RP: 172.27.255.11 Learned via: static configuration Time Active: 00:16:17 Holdtime: 0 Device Index: 130 Subunit: 32769 Interface: ppd0.32769 Group Ranges: 224.0.0.0/4 Register State for RP: Group Source FirstHop RP Address State Timeout 224.1.1.1 172.27.0.38 172.27.255.3 172.27.255.11 Receive 132 Anycast PIM rpset: 172.27.255.3 Anycast PIM local address used: 172.27.255.1 Address family INET6

  26. Task Verification (3 of 4) • Verify the policy is not allowing SPT cutover • Only *,G is seen on R2 lab@R2> show pim join extensive Instance: PIM.master Family: INET R = Rendezvous Point Tree, S = Sparse, W = Wildcard Group: 224.1.1.1 Source: * RP: 172.27.255.11 Flags: sparse,rptree,wildcard Upstream interface: ge-0/0/2.0 Upstream neighbor: 172.27.0.18 Upstream state: Join to RP Downstream neighbors: Interface: ge-0/0/4.0 172.27.0.58 State: Join Flags: SRW Timeout: 204 Instance: PIM.master Family: INET6 R = Rendezvous Point Tree, S = Sparse, W = Wildcard

  27. Task Verification (4 of 4) • Multicast traffic is flowing towards Rec2 lab@R2> show multicast usage Group Sources Packets Bytes 224.1.1.1 1 85 7140 Prefix /len Groups Packets Bytes 172.27.0.38 /32 1 85 7140 lab@R2> show multicast route extensive Family: INET Group: 224.1.1.1 Source: 172.27.0.38/32 Upstream interface: ge-0/0/2.0 Downstream interface list: ge-0/0/4.0 Session description: ST Multicast Groups Statistics: 10 kbps, 120 pps, 2929 packets Next-hop ID: 262142 Upstream protocol: PIM Route state: Active Forwarding state: Forwarding Cache lifetime/timeout: 360 seconds Wrong incoming interface notifications: 0 Family: INET6

More Related