20120202_CHT_TL_教育訓練 Day8

8/2/2019 20120202_CHT_TL_ Day8

1/68

2011 Juniper Networks, Inc. All rights reserved. | www.juniper.net

Day 8

Multicasting

Johnson Liu

[email protected] Feb. 2, 2012

8/2/2019 20120202_CHT_TL_ Day8

2/68


Introduction to Multicast

8/2/2019 20120202_CHT_TL_ Day8

3/68

2011 Juniper Networks, Inc. All rights reserved. www.juniper.net | 3

Address Types and Traffic Flows

Address types Unicast addresses: one to one

Broadcast addresses: one to all

Multicast addresses: one to many

Clients

Network

Multicast: A single data stream from the server is needed to reach all clients

Server

Single DataStream

Network devices replicate data stream towardinterested clients

8/2/2019 20120202_CHT_TL_ Day8

4/68


Multicast Advantages and Disadvantages

Advantages of multicast traffic: Increased efficiency for multicast sources

Single session needed instead of multiple unicast sessions

Increased bandwidth efficiency in the network

Effect depends on receiver distribution throughout the network

Allows traffic to unknown receivers

Disadvantages of multicast traffic:

Mostly UDP-based best-effort delivery

Network CoS is harder to achieve(EX:WRED)

Control plane for multicast state monitoring(EX:PIMNeighbor)

8/2/2019 20120202_CHT_TL_ Day8

5/68


Receivers

Network

Source

Components: Source: Originator of multicast IP packets

Multicast IP packet : An IP packet destined for a multicast groupaddress

Group address: An IP address in the range of(224.0.0.0~239.255.255.255)

Receivers: IP hosts interested in receiving data destined for aparticular group address (also called group members)

DR(Designated Router): Router closest to the source or receiver

multiple-access(ethernet) segment that forwards multicast IP packets

Multicast Components (1 of 2)

10.0.101.2

10.0.101.2 224.7.7.7 M-cast Data

SA DA

DR

UDP

8/2/2019 20120202_CHT_TL_ Day8

6/68


Components (contd.): Group membership protocol: Protocol used by receivers

to communicate group membership to the closestattached router

IGMP Multicast routing protocol: Protocol used between routers

in the network to build and maintain the multicastforwarding trees between sources and receivers

PIM and DVMRP

Multicast Components (2 of 2)

Receivers

Network

Source

GroupMembership

Protocol

Multicast RoutingProtocol

No special protocolneeded

8/2/2019 20120202_CHT_TL_ Day8

7/68 2011 Juniper Networks, Inc. All rights reserved. www.juniper.net | 7

Multicast Terminology (1 of 2)

Service models: Any-source multicast(ASM): Supports one-to-many and many-to-many applications

Source-specific multicast(SSM): Supports only one-to-many applications

Distribution modes: Dense mode:

Flood and prune

Prune signals no interest in receiving multicast traffic

Graft overrides previous prune messages Sparse mode:

Explicit subscriptions only

Join signals interest in receiving multicast traffic (subscribe)

Prune sent to unsubscribe from multicast traffic

8/2/2019 20120202_CHT_TL_ Day8


Multicast Terminology (2 of 2)

Distribution trees: Source tree or shortest-path tree(SPT)

Known source

(S, G) forwarding state

S : Source Address G : Group Address

Used in dense mode and in sparse mode

Shared tree or rendezvous point tree(RPT)

Unknown source

(*, G) forwarding state

* : Any Source

G : Group Address

Used only in sparse mode

8/2/2019 20120202_CHT_TL_ Day8


PIM Sparse ModeShared Tree and Source Tree

R2R1

R4

Source

192.168.100.10

R6

R5

RP10.1.1.1

R3

Shared RPT Tree

(*,G) State

Group: 224.7.7.7

Source: *

Source Tree

(S, G) State

Group: 224.7.7.7

Source: 192.168.100.10

Receiver224.7.7.7

8/2/2019 20120202_CHT_TL_ Day8


IP Multicast Addressing

IP multicast addressing (destination address only) Class D range: 224.0.0.0239.255.255.255 (224/4)

1 1 1 Multicast Group ID0

28 bits

0 1 2 3 31

8/2/2019 20120202_CHT_TL_ Day8


32 Bits

28 Bits

25 Bits 23 Bits

48 Bits

01-00-5e-7f-00-01

1110

5 BitsLost

Layer 2 Multicast Addressing

IP Multicast MAC Address Mapping

239.255.0.1

8/2/2019 20120202_CHT_TL_ Day8


0 0 0 0 00 0 0 11 1 10 0 00 000 0 0 00 0 0000 1 11 11 11 0 0000 000 0 00 00

0 1 0 0 5 E 0 A 0 8 0 5

IP Multicast-to-Ethernet Mapping Example

Not Used Low Order 23 bits mapped

10 111111 1 0 00 00 00 00 0 000 000 0 00 0 00 0

0000 58E A

Resulting Ethernet Multicast Address

(01-00-5E-00-00-00 ~ 01-00-5E-7F-FF-FF)

Class D Address: 224.10.8.5

8/2/2019 20120202_CHT_TL_ Day8

13/68


224.1.1.1224.129.1.1225.1.1.1225.129.1.1

.

.

.238.1.1.1238.129.1.1239.1.1.1239.129.1.1

0x0100.5E01.0101

1Multicast MAC Address(Ethernet)

32IP Multicast Addresses

Layer 2 Multicast Addressing

Be aware of the 32:1 address overlap

IP Multicast MAC Address Mapping

8/2/2019 20120202_CHT_TL_ Day8

14/68


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 IPaddress

Forwards traffic away from the source along the distribution tree

Forwards only traffic that passes RPF check

RPF(Reverse Path Forwarding): Prevents looped and duplicated multicast packets

Compares incoming interface of multicast packet with outgoingnext-hop interface of unicast route toward the source of thepacket

If interfaces are the same: passes the RPF check

8/2/2019 20120202_CHT_TL_ Day8

15/68


The RPF Check (1 of 2)

Source 1

192.168.100.10

Multicast Traffic

Packet from Source 1 arrives on correctinterface: forward out all outgoing interfaces.

R1

user@R1> show multicast rpf 192.168.100.10

Multicast RPF table: inet.0 , 16 entries

192.168.100.0/24

Protocol: OSPF

Interface: ge-0/0/4.125

Neighbor: 172.18.1.1

ge-0/0/4.125

172.18.1.1

RPF Table at R1

8/2/2019 20120202_CHT_TL_ Day8

16/68


user@R1> show multicast rpf 192.168.100.10Multicast RPF table: inet.0 , 16 entries

192.168.100.0/24

Protocol: OSPF

Interface: ge-0/0/4.125

Neighbor: 172.18.1.1

The RPF Check (2 of 2)Source 1

192.168.100.10

Packet from Source 1 arrives on wronginterface: RPF check fails, discard thepacket!

ge-0/0/4.125Packet

R1

172.18.1.1

RPF Table at R1

Multicast Traffic

ge-0/0/1.0

8/2/2019 20120202_CHT_TL_ Day8

17/68


Multicast forwarding terms: Incoming interface(IIF) or upstream interface Interface on which traffic is received that passes the RPF check

Interface to which PIM join messages are sent

Traffic that passes the RPF check can be forwarded If receiving router has knowledge of downstream receivers, the

router receives IGMP reports from directly connected receiversand also receives PIM join messages from neighbors withdownstream receivers

Outgoing interface list(OIL) or downstream interfaces Interfaces to which traffic must be forwarded down the

distribution tree

Multicast Forwarding Terms

8/2/2019 20120202_CHT_TL_ Day8

18/68


Internet Group Management Protocol

IGMP: Hosts send IGMP report message to signal interest in

receiving specific multicast traffic to their subnet routers

IGMP works between hosts and routers (Layer 3 device)

Three versions of IGMP: IGMP version 1 (RFC 1112)

ASM(Any-Source Multicast) mode

IGMP version 2 (RFC 2236)

Supports leave-group message that speed up convergence

ASM(Any-Source Multicast) mode

IGMP version 3 (RFC 3376)

Required for SSM(Source-Specific Multicast) mode but alsosupports ASM mode

8/2/2019 20120202_CHT_TL_ Day8

19/68


Multicast Groups and Routing

Group Membership Protocol

Multicast Routing Protocol

IGMP operates between receivers (hosts) androuters

IGMP is not a routing protocol

8/2/2019 20120202_CHT_TL_ Day8

20/68


IGMP Operation: Join Process

Report messages establish host membership for

particular multicast groups on a given network Reports are sent to the group address being reported

Reports inform local router that a host wants to receivetraffic associated with the specified multicast group

Report:

DA=224.10.1.1Group=224.10.1.1

Non-Querier

Host 1

Querier

8/2/2019 20120202_CHT_TL_ Day8

21/68


IGMP Query-Response Process

Query-response process:

1. Querier router sends general query to all-hosts multicast group(224.0.0.1)

2. Host 2 sends its report for group 224.10.1.1 first

3. Host 1 hears the response from Host 2 and suppresses its report

4. Host 3 sends its report for the group 224.20.1.1

Router A:Querier

Router B:Non-Querier

Host 1 Host 2 Host 3

3 Report224.10.1.1

Suppressed

2

Report

224.10.1.1

4

Report

224.20.1.1

1General

Query

8/2/2019 20120202_CHT_TL_ Day8

22/68


Process for leaving a group:

1. Host 2 sends leave message for 224.10.1.1 to the all-routers multicastgroup address (224.0.0.2)

2. Querier router sends group-specific query for 224.10.1.1

3. Group 224.10.1.1 times out if no IGMP reports are received within ~3seconds

IGMPv2 Group Leave

Router A(Querier)

Host 2 Host 31

Leave-group

Group=224.10.1.1

2Group-Specific

Query

Group=224.10.1.1

8/2/2019 20120202_CHT_TL_ Day8

23/68


Layer 2 Switches and Multicast

Layer 2 switches and multicast Layer 2 switches are often in use between routers and

hosts

By default, Layer 2 switches treat multicast traffic like

broadcast traffic, which results in forwarding to all ports Not an efficient use of bandwidth on ports without any receivers

IGMP snooping

IGMP snooping allows the Layer 2 switch to view IGMP

traffic between receivers and router Allows the Layer 2 switch to make more informed

decisions

Forwards multicast traffic only to ports where receivers are

located 224.0.0.0/8 address block is an exce tion, because it still

8/2/2019 20120202_CHT_TL_ Day8

24/68


IGMP Snooping

IGMP snooping IGMP snooping divides the ports into two categories:

Multicast-router interfaces:

IGMP query message received

Statically configured

Host-side interface: All other interfaces

Multicast forwarding as a result of IGMP snooping

IGMP packets are sent to the RE for snooping processing

Traffic for 224.0.0.0/8 destination address is flooded to all ports

except the incoming port

Remaining multicast traffic is sent to:

All multicast-router interfaces Host-side interfaces with hosts interested in receiving that

multicast group

IGMP Snooping: Standard Implementation

8/2/2019 20120202_CHT_TL_ Day8

25/68


IGMP Snooping: Standard Implementationand Proxy

IGMP snooping: standard implementation Standard IGMP snooping only checks received IGMP

packets; it does not generate any IGMP packets

Standard IGMP snooping does not result in a reduction of

IGMP reports sent to the router IGMP snooping: proxy

Allows the Layer 2 switch to act as a proxy to the routerand the hosts

Acts like a router toward the host-side interfaces Acts like a single receiver toward the multicast-router interfaces

Reduces the amount of IGMP reports sent to the actualrouter

8/2/2019 20120202_CHT_TL_ Day8

26/68


IGMP Version 1

IGMP version 1 operation: Hosts send report message to join

Hosts leave silently

Router stops forwarding to group after time-out

Defaults: (A * B) + (1 *C) = 260 seconds A = Robustness count = 2

B = IGMP Query Interval = 125 seconds

C = IGMP Query Response Interval = 10 seconds

No mechanism for querier election

Multicast routing protocol must provide election mechanism

8/2/2019 20120202_CHT_TL_ Day8

27/68


IGMP Version 2

IGMP version 2 operation: Hosts send report messages to join

Hosts sent leave-group messages

Routers send group-specific messages to check for

remaining receivers for that group Routers stop forwarding traffic for group if no response

Defaults: A * B = 2 seconds

A = Robustness count = 2

B = IGMP Last Member Query interval = 1 second Querier election within IGMP

Lowest IP address becomes IGMP querier

Non-querier router takes over in case querier fails

8/2/2019 20120202_CHT_TL_ Day8

28/68


IGMP Version 3

IGMP version 3 operation: Report message can include/exclude source information

Required for SSM mode of operation

Router A

Router C

Router B

Host 1 member of 224.10.1.1

Source=172.16.20.1

Group=224.10.1.1

Source=192.168.30.1

Group=224.10.1.1X

(Pruned)

IGMPv3 group-source report:

D: 224.0.0.22 (All IGMPv3routers)

Include 172.16.20.1, 224.10.1.1

Exclude 192.168.30.1,224.10.1.1

8/2/2019 20120202_CHT_TL_ Day8

29/68


Multicast Routing Protocols

8/2/2019 20120202_CHT_TL_ Day8

30/68


Overview of Multicast Routing Protocols

Functionality of multicast routing protocols: Perform RPF check on multicast traffic

Use existing unicast table or optionally, exchange own routinginformation

Set up multicast forwarding state in router per multicastgroup

IIF(Incoming InterFace) that passes RPF check

OIL(Outgoing Interface List) that indicates downstreamreceivers

Exchange multicast forwarding state with other routers

Use messaging to indicate willingness to receive traffic

Join

Prune

8/2/2019 20120202_CHT_TL_ Day8

31/68


Multicast RoutingDense Mode

Dense-mode protocols:

Assumes dense distribution of receivers

Implicit join model(push mode)

Flood and prune (Every 3 mins)

Initial flooding

IIF is the RPF interface back to the source

OIL are all other interfaces

Prune messages are sent to upstream routers in the followingcases:

Traffic is received on non-RPF interface No downstream receivers exist (OIL is empty)

Simple and efficient source-based trees (S,G) are built

Forwarding state is created in all routers in the network

Scalability issue

8/2/2019 20120202_CHT_TL_ Day8

32/68


Multicast RoutingSparse Mode (1 of 2)

Sparse mode protocols: Assumes sparse distribution of receivers

More realistic scenario for most networks

Explicit join model(pull mode)

Multicast traffic is forwarded only to routers that explicitlyrequest it

More complicated source discovery mechanism required

RP(Rendezvous Point) is required for source discovery in anysource multicast model(IGMPv1/IGMPv2)

Source-specific multicast does not require RP(IGMPv3)

Source discovery becomes an application issue

8/2/2019 20120202_CHT_TL_ Day8

33/68


Multicast RoutingSparse Mode ( 2 of 2)

Sparse mode protocols: Shared tree (*, G)

Initial forwarding state in routers assumes path throughRP(Rendezvous Point)

Potential suboptimal path between source and receivers

Source-based tree (S,G)

Router nearest to receiver learns about source when receivingtraffic

If source is known, the router can switch to shortest path

between source and receiver

Complex mechanism to build shared tree and source-based trees

Scalability is typically much better than dense-mode protocols

PIM Sparse Mode

8/2/2019 20120202_CHT_TL_ Day8

34/68


PIM Sparse ModeShared Tree and Source-Based Tree

R2

R1

R4

Source192.168.100.10

R6

R5

RP10.1.1.1

R3

Shared RPT Tree

(*,G) State

Group: 224.7.7.7Source: *

Source Tree

(S, G) State

Group: 224.7.7.7

Source: 192.168.100.10

Receiver224.7.7.7

8/2/2019 20120202_CHT_TL_ Day8

35/68


Multicast Routing ProtocolsDVMRP

DVMRP: First widely implemented multicast routing protocol

Used in original decommissioned Mbone backbone

Can use tunneling across unicast islands

Dense-mode implementation Specified in draft-ietf-idmr-dvmrp-v3-11 (expired April

2004)

Uses separate routing protocol to exchange routing

information used for the RPF check Distance-vector limitations(similar with RIP)

8/2/2019 20120202_CHT_TL_ Day8

36/68


Multicast Routing ProtocolsPIM

PIM: Protocol independent

Reuses the standard unicast routing table for RPF check

Implementation modes:

PIM dense mode (RFC 3973) PIM sparse mode (RFC 4601) : The most common practice

use-case for multicast deployments today

Versions:

Version 1: Encapsulates PIM messages in IGMP sent to224.0.0.2

Version 2: Encapsulates PIM messages in its own protocol

(number 103) sent to 224.0.0.13

8/2/2019 20120202_CHT_TL_ Day8

37/68


Multicast Routing ProtocolsPIM Dense Mode Protocol

8/2/2019 20120202_CHT_TL_ Day8

38/68


PIM Dense Mode Protocol Details

PIM dense mode uses the following message types Hello messages Maintain neighbors

Join/prune messages

Indicate interest in receiving traffic on interface Graft and graft-ack messages

Indicate renewed interest in receiving traffic on previouslypruned interfaces

Assert messages Elect designated forwarder on multi-access networks between

routers

8/2/2019 20120202_CHT_TL_ Day8

39/68


PIM Neighbor Discovery Process

PIM uses hello messages to discover neighbors PIM version 2 sends hello messages to 224.0.0.13 PIM version 1 sends hello messages (PIM queries) to 224.0.0.2

Neighbor information is stored after receiving PIM hello

Hold time determines time neighbor information is stored PIM uses hello messages to elect DR on multi-

access segments

DR is used only in PIM sparse mode

DR election based on highest priority(highest IP address is tiebreaker)

In IGMP version 1, the DR is also the IGMP querier

(IGMP version 1 does not have its own election

mechanism)

PIM Hello

PIM Dense Mode: Flooding Operation and

8/2/2019 20120202_CHT_TL_ Day8

40/68


PIM Dense Mode: Flooding Operation andState

Source192.168.100.10Initial Flood of Multicast Packets

1. All routers will receive at least one copy of the initialflow of traffic.

2. Each router performs an RPF check. Packets notpassing the RPF check are thrown away.

3. Packets passing the RPF check are replicated andflooded out of every other interface.

4. (S, G) state created on every router in the network.

Receiver

Receiver

Multicast Traffic

Even routers that have no

receivers maintain an(S,G) state for everysource and groupcombination.

(S, G) State for R1

Source: 192.168.100.10 Group:224.7.7.7

Incoming Interface(IIF): A

Outgoing Interface List(OIL): B,C,D

R1

A

B

CD

8/2/2019 20120202_CHT_TL_ Day8

41/68


PIM Dense Mode: Pruning Unwanted Traffic A router sends a prune

message upstream: If no attached receivers are

present

If a downstream PIM neighborexists and a prune message is

received from that neighbor

Source192.168.100.10

Receiver

Receiver

Prune Messages

Multicast Traffic

R1

A

B

CD

RPF check fail

No OILNo Receivers

PIM Dense Mode: Resulting State in All

8/2/2019 20120202_CHT_TL_ Day8

42/68


PIM Dense Mode: Resulting State in AllRouters

Flood and prune process

happens every 3 minutes (S,G) states expires after 3

minutes Flood/prune refreshes timer

Needed in the case of addinga receiver thatdid notpreviouslyexist

Source192.168.100.10

Receiver

Receiver

Multicast Traffic

(S, G) State for R2

Source: 192.168.100.10Group: 224.7.7.7

Incoming Interface: Null

Outgoing Interface List:Null

R1

R2A

B

C

D

(S, G) State for R1

Source: 192.168.100.10Group: 224.7.7.7

Incoming Interface: A

Outgoing Interface List: B,C

8/2/2019 20120202_CHT_TL_ Day8

43/68


PIM Dense Mode: Source-Based Tree(SPT)

A shortest-path multicast

forwarding tree is the finalresult of PIM dense mode

Source192.168.100.10

Receiver

Receiver

Multicast Traffic

R1

R2A

B

C

D

8/2/2019 20120202_CHT_TL_ Day8

44/68


PIM Pruning on Multi-Access Networks R2 sends prune message

towards upstream router

Upstream router(R1) can notstop sending traffic; otherwisereceivers(R3) would not receiveany traffic

Source192.168.100.10

Receiver

Receiver

Prune Messages

Multicast Traffic

R1

A

B

CD

R2

R1

R4

R3

8/2/2019 20120202_CHT_TL_ Day8

45/68


PIM Prune Delay on Multi-Access Networks The upstream router waits a

certain amount of time(2 seconds) to see whetherother routers(R3) override theprune message on that

interface

Source192.168.100.10

Receiver

Receiver

R1

A

B

CD

R2

JoinMessage

Multicast Traffic

Prune Message

R1

R4

R3

8/2/2019 20120202_CHT_TL_ Day8

46/68


PIM Dense Mode: Grafting Back onto the SPT

Router closest to new

interested receiver (R5learned from IGMP) sendsa graft message toward thesource

Source192.168.100.10

Receiver

Receiver R1

R2A

B

C

D

New Receiver

Graft Messages

Multicast Traffic

R5

Graft-Ack

R4R3

PIM Dense Mode: Forwarding on the New

8/2/2019 20120202_CHT_TL_ Day8

47/68


PIM Dense Mode: Forwarding on the NewSPT Branch

Because every routermaintains (S,G) state,every router knows the IPaddress of the source of

every active multicastgroup

Source192.168.100.10

Receiver

Receiver R1

R2A

B

C

D

New Receiver

Multicast Traffic

(S, G) State for R2

Source: 192.168.100.10Group: 224.7.7.7

Incoming Interface(IIF): A

Outgoing InterfaceList(OIL): B

A

B

R3

PIM A M h i ( f 2)

8/2/2019 20120202_CHT_TL_ Day8

48/68


PIM Assert Mechanism (1 of 2)

On multi-access networks, multiple routers

could forward traffic toward downstreamreceivers

Assert mechanism prevents duplication of multicasttraffic by electing a DF(Designated Forwarder)

Receiver

R1 R2

R3

(DF)

PIM A M h i (2 f 2)

8/2/2019 20120202_CHT_TL_ Day8

49/68


PIM Assert Mechanism (2 of 2) R1 and R2 send assert messages to each

other to determine who has best path to source Best preference

Metric of route towards source

Highest IP address

Result: R1 forwards traffic only on that interface

Downstream router R3 must take note of assert winner toknow where to send join/prune messages

Receiver

R1 R2

R3

Assert message forR2

Source: 192.168.100.10

Group: 224.7.7.7Metric Preference: 10

Metric: 20Assert message forR1

Source: 192.168.100.10Group: 224.7.7.7

Metric Preference: 10

Metric: 10

X

Multicast Traffic

Join Message

Prune Message

8/2/2019 20120202_CHT_TL_ Day8

50/68


Multicast Routing ProtocolsPIM Sparse Mode Protocol

8/2/2019 20120202_CHT_TL_ Day8

51/68


PIM Sparse Mode Protocol Details

PIM sparse mode uses the following message

types: Hello messages

Maintain neighbors

Elect DR on multi-access segments

Join/prune messages

Indicate interest in receiving traffic on interface

Assert messages

Elect DF on multi-access networks between routers

Register and register-stop messages

Signaling between source router and RP

Bootstrap and candidate-RP advertisements

Used by PIM version 2 if bootstrap mechanism is used

PIM Sparse Mode:

8/2/2019 20120202_CHT_TL_ Day8

52/68


pRendezvous Point Considerations

An RP(Rendezvous Point) is essential to PIMsparse mode functionality because it allowsmessages from the source and the receiver tomeet

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

PIM Sparse Mode:

8/2/2019 20120202_CHT_TL_ Day8

53/68


pRendezvous Point Discovery

PIM sparse mode has three ways of discoveringthe RP: Static RP

Auto-RP

BSR(Bootstrap Router) defined in RFC 5059

Multiple discovery options can be used at the sametime Preference is BSR > Auto-RP > Static

Anycast-RP can be used with each of thesediscovery mechanisms to improve redundancy Improves failover times significantly

PIM Sparse Mode: Receiver Join Operation

8/2/2019 20120202_CHT_TL_ Day8

54/68


PIM Sparse Mode: Receiver Join Operationand RPT State

Receiver224.7.7.7

R2

R1

R4

Source192.168.100.10

R6

R5

RP10.1.1.1

R3

(*, G) State

Group: 224.7.7.7

Source: *

RP: 10.1.1.1

Flags: sparse, rptree, wildcard

Upstream state: Join to RP

IGMP (*,G) Join

PIM (*,G) Join

DR

Shared RPT Tree

Or

Rendezvous PointTree(RPT)

PIM Sparse Mode: Register Message from

8/2/2019 20120202_CHT_TL_ Day8

55/68


Spa se ode eg ste essage oSource DR to RP(Unicast)

R2

R1

R4

Source192.168.100.10

R6

R5

RP10.1.1.1

R3

Multicast Traffic

Register Message Receiver224.7.7.7

DR

PIM Sparse Mode: RP Sets Up Source Tree

8/2/2019 20120202_CHT_TL_ Day8

56/68


p pToward DR

R2

R1

R4

Source192.168.100.10

R6

R5

RP10.1.1.1

R3

(S, G) State

Group: 224.7.7.7

Source: 192.168.100.10Flags: sparse, spt

Upstream State: Join to Source

Multicast Traffic

PIM (S,G) Join Receiver224.7.7.7

DR

PIM Sparse Mode: Register-Stop Message

8/2/2019 20120202_CHT_TL_ Day8

57/68


p g p gfrom RP to DR

R2

R1

R4

Source192.168.100.10

R6

R5

RP10.1.1.1

R3

Multicast Traffic

Register-Stop Message Receiver224.7.7.7

DR

PIM Sparse Mode: SPT Switchover (1 of 4)

8/2/2019 20120202_CHT_TL_ Day8

58/68



R2

R1

R4

Source192.168.100.10

R6

R5

RP10.1.1.1

R3

(*,G) State

Group: 224.7.7.7

Source: *

Flags: sparse, rptree,wildcard


(S, G) StateGroup: 224.7.7.7

Source: 192.168.100.10

Flags: sparse, spt

Upstream state: Join to

Source

Multicast Traffic

PIM (S,G) Join Receiver224.7.7.7

DR


8/2/2019 20120202_CHT_TL_ Day8

59/68



R2

R1

R4

Source192.168.100.10

R6

R5

RP10.1.1.1

R3

Multicast Traffic

Receiver224.7.7.7

DR


8/2/2019 20120202_CHT_TL_ Day8

60/68



Receiver

R2

R1

R4

Source192.168.100.10

R6

R5

RP10.1.1.1

R3

Multicast Traffic

PIM (S,G) Prune

DR


8/2/2019 20120202_CHT_TL_ Day8

61/68



R2

R1

R4

Source192.168.100.10

R6

R5

RP10.1.1.1

R3

(*,G) State

Group: 224.7.7.7

Source: *

Flags: sparse, rptree, wildcard


(S, G) StateGroup: 224.7.7.7

Source: 192.168.100.10

Flags: sparse, spt

Upstream state: Join to Source, Prune toRP

Multicast Traffic

(S, G) State

Group: 224.7.7.7

Source: 192.168.100.10Flags: sparse, spt

Upstream State: Prune toSource

Receiver224.7.7.7

DR

Source Tree

Or

Shortest PathTree(SPT)

PIM S M d A RP O i

8/2/2019 20120202_CHT_TL_ Day8

62/68


PIM Sparse Mode: Auto-RP Operation

Auto-RP allows dynamic discovery of RPs

Nonstandard proprietary solution

Supported by PIM version 1 and version 2

Allows backup RPs for failover but no load balancing

Uses multicast to distribute the RP related information Dense mode is typically used

Components of auto-RP:

Candidate RPs announce RP candidacy to 224.0.1.39(announce)

Mapping agent listens to candidate RP announcements, electsRP for each group (highest IP address), and announces RPwinners to 224.0.1.40 (discovery)

A RP RP El i P

8/2/2019 20120202_CHT_TL_ Day8

63/68


RP1 IP - Group 224/4

224.0.1.39

Auto-RP RP Election Process

Electing an RP using auto-RP

1. C-RPs periodically send Announce messages

Advertise their ability to be the RP for a particular grouprange

2. Mapping agent elects the RPs for the domain

3. Mapping agent sends Discovery messages

Specifies group to RP mappings

All Other PIM Routers(discovery)

Mapping Agent(mapping)

C-RPs(announce)

1C-RPIP

Group 224/4

SA DA

X

3224.0.1.40Mapping Agent

IP SA DA

RP Election:

1. Based on most specific group range

2. Highest IP address wins in a tie

2

PIM Sparse Mode: Bootstrap RouterO ti

8/2/2019 20120202_CHT_TL_ Day8

64/68


Operation

PIM version 2 includes BSR to discover RPs

Uses PIM version 2 messages to distribute information

Hop-by-hop forwarding of bootstrap message

Allows backup RPs for failover and load shares groupsbetween RPs

Components of BSR:

Candidate RPs announce RP candidacy using unicast to theBSR

Bootstrap router:

Elected based on priority (tiebreaker is highest IP address)

Receives candidate RP advertisements and determines theRP/group mapping

Includes results (RP-set) in bootstrap message

Bootstrap Router RP Election Process

8/2/2019 20120202_CHT_TL_ Day8

65/68


Empty C-RPSet

Bootstrap Router RP Election Process

Electing an RP using BSR

1. BSR sends BSR messages allowing other routers to learn BSRs

IP2. C-RPs send advertisements listing a group range

3. BSR collect C-RP advertisements and advertises the entire set toall PIM routers

4. Each PIM router elects an RP for a group range

All Other PIM RoutersBootstrap RouterC-RPs

1

3

224.0.0.13BSRIPSA DA

RP Election:1. Each router performs a hash over each of theC-RP addresses, group ranges, and masks

2. Lowest value of hash determines the electedRP for a given range

2 Group 224/4BSR IPC-RP IPSA DA

C-RP1:224/4, C-RP2:224/4, 224.0.0.13BSRIP

SA DA

4

PIM S M d B t t T i l

8/2/2019 20120202_CHT_TL_ Day8

66/68


PIM Sparse Mode: Bootstrap Terminology

BSR election:

Single BSR elected within PIM sparse-mode domain

Only BSR with highest priority keeps on flooding BSRmessages

Candidate-RP advertisements

BSR receives candidate-RP messages from all potentialRPs

RP-set formation

BSR selects a subset of the candidate-RPs to form theRP-set

RP-set flooding

Using bootstrap messages, the RP-set is forwarded to all

routers in the PIM sparse-mode domain

PIM S M d C fi ti B i

8/2/2019 20120202_CHT_TL_ Day8

67/68


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

8/2/2019 20120202_CHT_TL_ Day8

68/68

20120202_CHT_TL_教育訓練 Day8

Documents

Transcript of 20120202_CHT_TL_教育訓練 Day8