• No results found

IP multicast. Rui Valadas

N/A
N/A
Protected

Academic year: 2021

Share "IP multicast. Rui Valadas"

Copied!
65
0
0

Loading.... (view fulltext now)

Full text

(1)

IP multicast

(2)

Group communications

Receiver Receiver Receiver Sender Receiver Sender Sender Sender Receiver Sender Receiver Sender Receiver Unicast (1:1) Multicast (1:n)

(3)

Multicast communications

• Senders transmit using multicast addresses

• One multicast address defines a multicast group

• Receivers are pre-programmed to read specific multicast addresses

• Layer-2 multicast packets are flooded by switches

• Just like broadcast packets

• Flooded = retransmitted on all interfaces except the receiving one

• In networks of routers, an IP multicast routing protocol can be used

• Hosts indicate to their first-hop router their willingness to receive multicast

traffic on specific multicast group – they join the multicast group

• The network of routers uses a distribution tree, to route multicast packets from

multicast sender to multicast receivers

• Routers can retransmit a single incoming packet on several outgoing

interfaces

• Hosts can join and leave the multicast group dynamically, and routers can join

and leave the multicast tree

(4)

Multicast communications

H1

Host

programmed to receive 230.0.0.0

multiple access link

H2

Multicast traffic sent on IP multicast address 230.0.0.0

Host

programmed to receive 230.0.0.0

(5)

Multicast communications

R1 R2 R3 R4 R6 C D E A B F G R5 222.222.10.1/24 222.222.10.2/24 222.222.20.1/24 222.222.30.1/24 222.222.30.2/24 222.222.40.1/24 222.222.50.1/24

Hosts signal first-hop

router that want to join

multicast group

Routers implement

multicast routing

(6)

Server Receiver Receiver Receiver

Multicast versus

unicast routing

Unicast: Server sends one message for each receiver

Multicast: Server sends a single

Server

Receiver

(7)

IP multicast addressing

0 8 16 24 32

1 1 1 0

IP multicast addresses range from

224.0.0.0 to 239.255.255.255

(8)

IP multicast addressing

Address Usage

224.0.0.1 All Hosts

224.0.0.2 All Multicast Routers 224.0.0.3 Unassigned

224.0.0.4 DVMRP Routers 224.0.0.5 OSPF Routers

224.0.0.6 OSPF Designated Routers 224.0.0.7 ST Routers

224.0.0.8 ST Hosts 224.0.0.9 RIP2 Routers 224.0.0.10 IGRP Routers 224.0.0.11 Mobile-Agents

Some link-local IP multicast

addresses – not forwarded by IP

routers regardless of TTL value

(9)

IP multicast addressing

Address Usage

224.0.1.0 VMTP Managers Group

224.0.1.1 NTP – Network Time Protocol 224.0.1.2 SGI-Dogfight

… …

224.0.1.39 Cisco-RP-Announce 224.0.1.40 Cisco-RP-Discovery

… …

Some other reserved multicast

addresses – can be forwarded by

IP routers

(10)

Internet Group Management Protocol (IGMP)

• Protocol used to manage the group membership in subnets

• Three versions: IGMPv1, IGMPv2, IGMPv3

• IGMP operation

• Routers announce their presence periodically

• Only one router does it in each subnet

• Hosts may join and leave specific multicast groups at anytime

• Hosts answer to router announcements to maintain their group’s existence

(11)

IGMPv2 – message format

• Four types of messages

• Membership Query (Type = 0x11)

• Sent by routers to all-hosts multicast address (224.0.0.1) • General Query: Group Address field is all-zeros

• Group-Specific Query

• Version 1 Membership Report (Type = 0x12)

• Just for compatibility with IGMPv1

• Version 2 Membership Report (Type = 0x16)

• Leave Group (Type = 0x17)

• Max. Response Time field

• Used in the Report Suppression mechanism

Type

Group Address

Max. Response Time Checksum

(12)

IGMP – Query-Response process

R2

H1

R1

H3

H2

RE P O RT

wants to receive 230.0.0.0 wants to receive 230.0.0.0

1

2

3 4

sent to 224.0.0.1 (All Hosts multicast group)

Querier

(sends queries)

Non-Querier

(keeps quiet)

multiple access link

suppressed since H1 sent REPORT first

(13)

IGMP – Report Suppression mechanism

• Routers only need to know if a multicast group is active or not; they

don’t need to know who the members are or even the number of

members

• Suppression algorithm

• When host receives IGMP Membership Query, it starts a countdown timer

for each multicast group it has joined. Timer is initialized to random value

between 0 and maximum response interval (default 10 seconds)

• If timer expires, host multicasts IGMP Membership Report to the

corresponding multicast group

• If host hears an IGMP Membership Report sent by another host, it cancels

the corresponding timer and suppresses the sending of its IGMP

(14)

IGMP – Join process

R2

H1

R1

H3

member of 230.0.0.0 member of 230.0.0.0

Querier

(sends queries)

Non-Querier

(keeps quiet)

multiple access link

unsolicited report – sent immediatelly when

H2 wants to join

H2

RE P O RT

(15)

IGMP – Leave process

R2

H1

R1

H3

member of 230.0.0.0 wants to leave member of 230.0.0.0 2 1 4 sent to 230.0.0.0 (the specific group address)

Querier

(sends queries)

Non-Querier

(keeps quiet)

multiple access link

suppressed since H2 sent REPORT first sent to 224.0.0.2

(All Routers multicast group)

H2

RE P O RT member of 230.0.0.0 3

(16)

IGMP – Leave process

R2

H1 R1

H3 not currently member of

230.0.0.0 2 Querier (sends queries) Non-Querier (keeps quiet)

multiple access link

H2 L E A V E member of 230.0.0.0 wants to leave 1

not currently member of 230.0.0.0

3 no response from group 230.0.0.0

(17)

IGMP – Leave process

Last Host Query Response Interval = 1 s

Last Host Query Response Interval = 1 s

LEAVE

GROUP SPECIFIC QUERY

Leave latency < 3 seconds

GROUP SPECIFIC QUERY

(18)

IGMP – Querier election process

• When router starts, it sends General Query to 224.0.0.1 (All Hosts)

with a source IP address equal to interface address.

• When router receives General Query compares received source IP

address with its own interface address; the lowest IP address on

the subnet is elected the IGMP Querier.

• All non-querier routers start a timer that is reset whenever a

General Query message is received from the Querier; the default

timeout value is two times the Query Interval (250 seconds) . If the

Querier timer expires, the election process is run again.

(19)

Case study – Multicast configuration

PC1(config)#no ip routing PC1(config)#int f0/0

PC1(config-if)#ip address 222.222.50.100 255.255.255.0 PC1(config-if)#ip igmp join-group 230.0.0.0

PC1(config-if)#no shutdown R1(config)#ip multicast-routing R1(config)#int f0/0

R1(config-if)#ip address 222.222.50.1 255.255.255.0 R1(config-if)#ip pim-dense mode

R1(config-if)#no shutdown

R1#sh ip igmp groups

IGMP Connected Group Membership

Group Address Interface Uptime Expires Last Reporter Group Accounted

230.0.0.0 FastEthernet0/0 00:08:42 00:02:16 222.222.50.110 224.0.1.40 FastEthernet0/0 00:08:44 00:02:17 222.222.50.1

Cisco router configured as a PC

Cisco router configured to implement multicast

routing using PIM-DM

(20)

Case study – Multicast

connectivity

PC1#ping 230.0.0.0

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 230.0.0.0, timeout is 2 seconds:

Reply to request 0 from 222.222.50.110, 4 ms Reply to request 0 from 222.222.50.120, 60 ms Reply to request 0 from 222.222.50.130, 40 ms

(21)

Case study – IGMP

Query-Response

Queries sent every minute by Querier router only. One, and only one, of the PCs (selected randomly) replies immediately.

(22)

Case study – IGMP

Query-Response

(23)

Case study – IGMP Join

Report for 235.0.0.0 sent immediately after command at PC2, not in reply to Query (unsolicited report). Since PC2 is the only member of 235.0.0.0, it always reports this group.

R1#sh ip igmp groups

IGMP Connected Group Membership

Group Address Interface Uptime Expires Last Reporter Group Accounted 235.0.0.0 FastEthernet0/0 00:00:24 00:02:35 222.222.50.120

230.0.0.0 FastEthernet0/0 00:50:47 00:02:08 222.222.50.120 224.0.1.40 FastEthernet0/0 00:50:49 00:02:11 222.222.50.2

PC2(config)#int f0/0

(24)

R1#sh ip igmp groups

IGMP Connected Group Membership

Group Address Interface Uptime Expires Last Reporter Group Accounted 235.0.0.0 FastEthernet0/0 01:02:33 00:02:08 222.222.50.120

224.0.1.40 FastEthernet0/0 01:52:58 00:02:03 222.222.50.2

Case study – IGMP Leave

PC2(config)#int f0/0

(25)

Case study – IGMP Leave

Leave message

Group Specific Query message

Max Response Time is 1 second, to make sure that, if there is still someone

in the group, that someone will answer the Query before the Querier assumes

the group is empty.

Sent to specific group, and not to 0.0.0.0

(26)

Case study – IGMP Querier

election process

R1(config)#int f0/0

R1(config-if)#no ip pim dense-mode R1(config-if)#ip pim dense-mode

(27)

Multicast distribution trees

• Source trees

• Tree routed at the source spanning all receivers

• One tree per source

• Shared trees

• A single tree and a single root, called rendezvous point or core

• Bidirectional tree

• Tree branches can be crossed in both directions by multicast traffic

• Unidirectional tree

• Multicast traffic is sent first to the root and only then forwarded down the shared tree • Two methods for delivering traffic to the root

• Root joins tree routed at the source; used in PIM-DM

(28)

Source trees

(S,G)=(222.222.10.1,230.0.0.0)

R1 R2 R3 R4 R6 C D E A B F G R5 source for 230.0.0.0 222.222.10.1/24 222.222.10.2/24 222.222.20.1/24 222.222.30.1/24 222.222.30.2/24

(29)

Source trees

(S,G)=(222.222.10.1,230.0.0.0)

(S,G)=(222.222.40.1,230.0.0.0)

R1 R2 R3 R4 R6 C D E A B F G R5

source & receiver

for 230.0.0.0

receiver for

230.0.0.0

source& receiver for 230.0.0

(30)

Unidirectional shared trees

R1 R2 R3 R4 R6 C D E A B F G R5 receiver for 230.0.0.0 source for 230.0.0.0 shared root

(core or rendezvous point)

receiver for 230.0.0.0

222.222.10.1/24 222.222.10.2/24 222.222.20.1/24 222.222.30.1/24 222.222.30.2/24

(31)

Reverse Path Forwarding (RPF)

• A fundamental mechanism in multicast routing

• Relies on unicast routing

• Uses shortest path towards the multicast source

• Forwarding rules:

• Source starts by transmitting packet on all interfaces

• If a packet is received on the interface providing the shortest path to the

multicast source, transmit it on every other interface

• Otherwise, drop the packet

• Flooding is controlled, but packets are transmitted on many

interfaces that do not belong to the distribution tree

(32)

Reverse Path Forwarding (RPF)

A B C D E 10 10 10 40 10 30 10 10 10 10 10 10 A B C D E 10 10 10 40 10 30 10 10 10 10 10 10 A B C D E A B C A B C A B C 10 10 10 10

(33)

Reverse Path Forwarding (RPF)

A B C D E 10 10 10 40 10 30 10 10 10 10 10 10 A B C D E 10 10 10 40 10 30 10 10 10 10 10 10 10 10 10 10 A B C D E A B C D E A B C D E A B C D E

(34)

Reverse Path Forwarding (RPF)

A

B

C

D

E

10 10 10 30 10 30 10 10 10 10 10 10

source node

leaf nodes

branch

incoming interface outgoing interfaces

(35)

Flood-and-Prune

A B C D E A B C D E A B C D E PRU NE PRUNE PRUNE P R U N E A B C D E A B C D E A B C D E P R U N E P RU NE

(36)

Flood-and-Prune

A

B

C

D

E

incoming interface pruned interface forwarding interface

(37)

IP multicast routing table and forwarding

process

• Routing table indicates the outgoing interfaces (can be more than

one) for each IP multicast destination address.

• Every time a multicast packet arrives at a router an incoming interface

check is performed (also called RPF check):

• Router examines IP source address to determine if packet arrived on incoming

interface; if yes the packet is forwarded; if not the packet is discarded.

• One routing table entry for each multicast source.

(222.222.60.100, 230.0.0.0), 00:02:20/00:00:39, flags: T

Incoming interface: Vlan1, RPF nbr 222.222.30.1

Outgoing interface list:

FastEthernet0/0, Forward/Dense, 00:02:22/00:00:00

FastEthernet0/1, Prune/Dense, 00:02:22/00:00:00, A

Multicast routing table entry (example)

f0/0 f0/1 vlan1

(38)

Dynamic management of group membership

and distribution tree

A

B

C

D

E

Sr Rcv 1 Rcv 2 Rcv Rcv 5 Rcv 4 First-hop router

(39)

Dynamic management of group membership

and distribution tree

A

B

C

D

E

Sr Rcv 1 Rcv 2 Rcv 3 Rcv 5 Rcv 4 Leave group Prun e tree

A

B

C

D

E

Sr Rcv 1 Rcv 2 Rcv 3 Rcv 5 Rcv 4 step 1 step 2

(40)

Dynamic management of group membership

and distribution tree

A B C D E Sr Rcv 1 Rcv 2 Rcv 5 Rcv 4 Leave group A B C D E Sr Rcv 1 Rcv 2 Rcv 3 Rcv 5 Rcv 4 step 1 step 2 Rcv 3

(41)

Dynamic management of group membership

and distribution tree

A

B

C

D

E

Sr Rcv 1 Rcv 2 Rcv 5 Rcv 4

A

B

C

D

E

Sr Rcv 1 Rcv 2 Rcv 3 Rcv 5 Rcv 4 step 1 step 2 Rcv 3 Leave group

(42)

Dynamic management of group membership

and distribution tree

A

B

C

D

E

Sr Rcv 1 Rcv 2 Rcv 5 Rcv 4

A

B

C

D

E

Sr Rcv 1 Rcv 2 Rcv 3 Rcv 5 Rcv 4 Rcv 3 Leave group Prune tree Prune tree

(43)

Dynamic management of group membership

and distribution tree

A

B

C

D

E

Sr Rcv 1 Rcv 2 Rcv 5 Rcv 4 step 1 Rcv 3 Join group Join tree Join tree

A

B

C

D

E

Sr Rcv 1 Rcv 2 Rcv 3 Rcv 5 Rcv 4 step 2

 Receiver 4 joins group again; branches DE and EC join tree again; when Join

(44)

Multicast routing protocol categories

• Dense mode protocols

• DVRMP, PIM-DM

• Sparse mode protocols

• PIM-SM, CBT

• Link-state protocols

• MOSPF

(45)

Protocol Independent Multicast (PIM-DM)

• Protocol independent (uses unicast route table for RPF check)

• No separate multicast routing protocol

• Flood-and-prune behavior (3-minute cycle)

• Forwarding state is set up by the arrival of multicast data (data-driven)

• Classless (as long as classless unicast routing is in use)

• PIM-DM mechanisms

• Neighbor discovery

• Multicast forwarding

• Pruning

• Asserts

• Grafting

• State-Refresh

(46)

Case study – PIM-DM configuration

R4(config)#ip multicast-routing R4(config)#interface f0/0

R4(config-if)#ip address 222.222.40.4 255.255.255.0 R4(config-if)#ip pim dense-mode

R4(config-if)#no shutdown R4(config-if)#exit

R4(config)#interface f0/1

R4(config-if)#ip address 222.222.50.4 255.255.255.0 R4(config-if)#ip pim dense-mode

R4(config-if)#no shutdown R4(config-if)#exit

R4(config)#interface vlan1

R4(config-if)#ip address 222.222.30.4 255.255.255.0 R4(config-if)#ip pim dense-mode

R4(config-if)#no shutdown R4(config-if)#exit R4(config)#router ospf 1 R4(config-router)#network 222.222.30.0 0.0.0.255 area 0 R4(config-router)#network 222.222.40.0 0.0.0.255 area 0 R4(config-router)#network 222.222.50.0 0.0.0.255 area 0 PC1(config)#ip default-gateway 222.222.50.3

(47)

PIM-DM Neighbor discovery

• Used to discover and maintain

relationships with neighbors

• Every Hello period (default is

30s) routers send Hello

messages to All PIM Routers

multicast address (224.0.0.13)

on each of its multicast enabled

interfaces

• Hello message contains

Holdtime value (typically three

times the Hello period) telling

the receiver when to expire the

neighbor adjacency if no further

Hello messages received

R4 H1 R3 R2 R1 multicast source H2 H3 multicast receiver multicast receiver

H

e

ll

o

Hello

He

ll

o

(48)

Case study – PIM-DM

neighbor discovery

R4#show ip pim neighbor PIM Neighbor Table

Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, S - State Refresh Capable

(49)

PIM-DM Flood-and-Prune

• Uses Reverse Path Forwarding

principle

• There will be one tree per

multicast source

• Tree is created upon arrival of the

first data packet and has a

lifetime of 3 minutes

• A router can have only one

incoming interface

• When multiple entries back to the

source exist in the unicast routing

table, the entry with the highest

next hop IP address becomes the

incoming interface

R4

H1

R3

R2

R1

multicast source multicast receiver 10 10 10 10 Incoming interface Incoming interface Incoming interface Incoming interface multicast receiver 20 10 10 10

(50)

PIM-DM Flood-and-Prune

• Prune messages are sent

when traffic arrives on

non-RPF point-to-point interfaces

• … and in some other cases

too

R4

H1

R3

R2

R1

multicast source 10 10 10 10 Incoming interface Incoming interface Incoming interface Incoming interface 20 10 10 10

Prune

(51)

PIM-DM Flood-and-prune

• Forwarding through the (S,G)

tree – no waste of message

transmissions.

R4

R3

R2

R1

multicast source multicast receiver 10 10 10 10 Incoming interface Incoming interface Incoming interface Incoming interface multicast receiver 20 10 10 10 H1 (S,G) tree

(52)

PIM-DM Asserts

R4

H1

R3

1

multiple access link

R2

R1

multicast source 10 10 10 10 1 2 2 10 20 Incoming interface Incoming interface

(53)

PIM-DM Asserts

• If a router receives a multicast packet via an interface in the outgoing interface list

associated with a multicast source, an Assert message is sent out the interface to

resolve which router continues forwarding this traffic

R4

H1

R3

ASSERT with distance =110, metric=20 R3 wins! 1

multiple access link

R2

R1

multicast source 10 10 10 10 1 ASSERT with distance =110, metric=30 R4 looses! 2 2 10 20 Incoming interface Incoming interface

(54)

PIM-DM Pruning the

tree

• Removing branches from

the tree if no multicast

receivers can be reached

through them

R4

R3

P RU NE

R2

R1

multicast source 2 multicast receiver disconnected H2 PRUNE IG M P L E AV E 3 1 H1

(55)

PIM-DM Grafting

• Graft back previously

pruned branches so that

restarting the flow of

multicast traffic can be

accomplished with

minimum delay

• Grafting is similar to a

Join

R4

R3

G R A F T

R2

R1

multicast source 2 multicast receiver connected H2 G R A F T A C K GRAFT GRAFT ACK IG M P R E P O R T 3 4 5 1 H1

(56)

PIM-DM Prune override

• Router sends overriding

Join in response to Prune

sent by neighbor on same

multiple access link, if it

maintains interest in

receiving multicast traffic

• A 3 second prune delay

timer is started when a

prune message is received

on a multiple access link. If

no overriding Join is

received to cancel this

timer, the Prune takes

place when the timer

expires

R4

H1

R3

PRUNE override 3

multiple access link

R2

R1

multicast source 1 multicast receiver disconnected 2

(57)

Case study – PIM-DM

multicast forwarding

PC2#ping 230.0.0.0

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 230.0.0.0, timeout is 2 seconds:

Reply to request 0 from 222.222.60.100, 4 ms Reply to request 0 from 222.222.70.100, 180 ms Reply to request 0 from 222.222.50.100, 160 ms Reply to request 0 from 222.222.50.100, 140 ms PC2#ping 230.0.0.0

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 230.0.0.0, timeout is 2 seconds:

Reply to request 0 from 222.222.60.100, 4 ms Reply to request 0 from 222.222.70.100, 120 ms Reply to request 0 from 222.222.50.100, 80 ms

First ping from PC2 receives two responses from PC1 because the multicast distribution tree is not yet pruned. 10 10 10 10 10 10 10 10 1 1

(58)

Case study – PIM-DM

multicast forwarding

(222.222.60.100, 230.0.0.0), 00:01:40/00:01:22, flags: T Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0 Outgoing interface list:

FastEthernet0/1, Prune/Dense, 00:01:41/00:01:18 Vlan1, Forward/Dense, 00:01:41/00:00:00

(222.222.60.100, 230.0.0.0), 00:01:59/00:01:02, flags: PT Incoming interface: FastEthernet0/0, RPF nbr 222.222.20.1 Outgoing interface list:

FastEthernet0/1, Prune/Dense, 00:02:00/00:00:59 Multicast table of R4 Multicast table of R3 Multicast table of R2 Multicast table of R1 (222.222.60.100, 230.0.0.0), 00:00:06/00:02:53, flags: T Incoming interface: FastEthernet0/1, RPF nbr 222.222.40.4 Outgoing interface list:

FastEthernet0/0, Forward/Dense, 00:00:07/00:00:00 10 10 10 10 10 10 10 10 1 1

(59)

Case study – PIM-DM

multicast forwarding

R1

R2

R3

R4

PC 2

PC 3

PC 1

10 f0/0 f0/1 10 10 f0/0 f0/1 10 10 f0/0 f1/0 1 f0/1 10 f0/1 10 f1/0 1 20.1 20.2 30.4 30.2 40.2 40.4 50.3 50.4 60.1 70.2 60.100 70.100 50.100 10 f0/0

Multicast distribution tree

sourced at PC2

10 10 10 10 10 10 10 10 1 1

(60)

Case study – PIM-DM

multicast forwarding

(222.222.60.100, 230.0.0.0), 00:00:47/00:02:21, flags: T Incoming interface: Vlan1, RPF nbr 222.222.30.1

Outgoing interface list:

FastEthernet0/1, Prune/Dense, 00:00:48/00:02:11 FastEthernet0/0, Forward/Dense, 00:00:48/00:00:00

Multicast table of R4 Multicast table of R3

Multicast tables after sending ping from PC2 and from PC3 to 230.0.0.0 (all interface costs equal to 10, except on R4 where all interface costs equal to 20)

(222.222.60.100, 230.0.0.0), 00:01:04/00:02:10, flags: T Incoming interface: FastEthernet0/0, RPF nbr 222.222.20.1 Outgoing interface list:

FastEthernet0/1, Forward/Dense, 00:01:06/00:00:00, A (222.222.70.100, 230.0.0.0), 00:00:42/00:02:18, flags: PT

Incoming interface: FastEthernet0/1, RPF nbr 222.222.50.4 Outgoing interface list:

FastEthernet0/0, Prune/Dense, 00:00:42/00:02:18, A 10 10 10 20 20 10 10 10 10 20

(61)

Case study – PIM-DM

multicast forwarding

Two multicast distribution

trees, one sourced at PC2

and another at PC3

10 10 10 20 20 10 10 10 10 20

PC 2

PC 3

PC 1

10 f0/0 f0/1 10 20 f0/0 f0/1 10 10 f0/0 f1/0 20 f0/1 10 f0/1 20 f1/0 10 20.1 20.2 30.4 30.2 40.2 40.4 50.3 50.4 60.1 70.2 60.100 70.100 50.100 10 f0/0

R2

R4

R3

R1

(62)

Case study – PIM-DM

Asserts

 PIM messages observed in subnets 20, 30,

and 50, when sending ping 230.0.0.0 from

PC2 and all multicast routing tables empty

Request received on

Incoming interface of R3. No Assert sent. Prune sent because R3 is Assert looser on 222.222.50.0/24. On subnet 222.222.20.0/24 On subnet 222.222.30.0/24 1 1 10 10 10 10 10 10 10 10

(63)

Case study – PIM-DM

Asserts

 PIM messages observed in subnets 20, 30,

and 50, when sending ping 230.0.0.0 from

PC2 and all multicast routing tables empty

R3 sends Prune because it is in “Winner” state and received better Assert.

NOTE: The Assert state machine is One Request sent by R3 and another by R4.

Assert messages sent to elect the Assert winner. Assert messages sent to elect the Assert winner. On subnet 222.222.50.0/24 1 1 10 10 10 10 10 10 10 10

(64)

Case study – PIM-DM

Asserts

Assert message sent by R4

on 222.222.50.0/24

1 1 10 10 10 10 10 10 10 10

(65)

Bibliography

• “Developing IP Multicast Networks”, Beau Williamson, Cisco Press,

2000.

• “Multicast Communications”, Ralph Wittmann, Martina Zitterbart,

Morgan Kaufmann, 1999.

• “Internet Group Management Protocol, Version 3”, RFC 3376, B.

Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan, October

2002.

• “Protocol Independent Multicast - Sparse Mode (PIM-SM)”, RFC

4601, B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, August

2006.

• “Protocol Independent Multicast - Dense Mode (PIM-DM)”, RFC

3973, A. Adams, J. Nicholas, W. Siadak, January 2005.

References

Related documents

Replay Service Recovery Service Market Data Group Multicast Channel Multicast Source IP Address Multicast Address Port Virtual- IP Address Port Virtual- IP Address

While the Czech economy experienced a second year of mild recession in 2013, Factoring České spořitelny followed up a highly successful 2011 and 2012 by

This condition was then repeated with the order of viewpoint presentation reversed: the target face (250ms) was presented from one of three side viewpoints (5°, 10° and 20°) while

Although Gerhard writes in Concrete Music and Electronic Sound Composition that he approached ‘the electronic medium strictly as a sideline’ [2], the importance of this work and

1) Enable IGMP snooping. 2) Enable bridge multicast filtering. 3) Enable automatic learning of multicast router ports. Statically configure bridge filtering on a per-interface basis.

Easy deployment and a list of routing protocols are data, and the group members can be a router receives multicast group membership report message overhead to.. Out in pim join

O sistema utiliza como indica- dores de alimentos e bebidas marcadores de alimentação não saudável: consumo diário ou quase diário de refrigerante sem restrição

To display multicast group and router port information, click Configuration, IGMP Snooping, Multicast Entry Table.. The IGMP Multicast Router Information table