• Remove the tunnel connecting R1 and R3. Configure R3 as the stub
multicast router with SW1 emulating a host on the stub segment.
---------------------------------------------------------
Stub multicast routing is useful in situations where you have small remote sites
connected to a centralized WAN cloud across low-bandwidth links that use lowend
routers. Such remote sites never perform any transit function, and may suffer
from resource starvation due to PIM DM’s flood-and-prune behavior, or PIM SM
RP announcements, RP cache growth and mroute state proliferation.
Look at the figure. Assume R5 is the central router and R3 is the stub remote
router with directly connected receivers. In the case where both routers are
running PIM DM, periodic flood-and-prune behavior has the capacity to
overwhelm the WAN link. If both routers were to run PIM SM, then R3 will have
to accept RP discovery messages, build its own RP cache and maintain states
for all multicast groups joined by local receivers, thus possibly over taxing a small
router’s resources.
Being a stub multicast router allows R3 to be exempted from PIM and IGMP
message processing. Instead of that, R3 is configured to forward all IGMP
messages received on its client-facing interface to R5. Thus, R3 never creates
any group states. The command to achieve this is ip igmp helper-address
<Upstream-IP>. As a result, R5 will track all IGMP states for any client on the
segment connected to R3.
Next, R3 is configured with PIM DM on both the uplink (Frame-Relay in our case)
and the client-facing interfaces. This will allow the router to flood ANY multicast
traffic received from upstream sources down to clients, this is based on default
PIM DM behavior, as there is no downstream router to prune the tree.
Finally, R5 is configured with PIM enabled on its downstream interface, but with a
special neighbor filter applied, to make sure the upstream and the downstream
routers never form a PIM adjacency. This allows the upstream router to flood
multicast traffic downstream, as IOS will not send a multicast packet out of non-
PIM interface. At the same time, the downstream router will not be able to prune
any group using PIM signaling. The command used to filter PIM neighbors is ip
pim neighbor-filter <ACL> where the standard ACL permits or denies
particular neighbors.
The net effect is that the upstream router (R5) builds a multicast distribution tree
on behalf of the downstream router (R3) by virtue of the IGMP proxy function
performed by the downstream router. At the same time, no excessive load is
being put on the stub router or the stub link, effectively saving bandwidth and
router resources. Essentially, R5 performs all multicast routing functions for R3,
and the latter is only used as a “dumb” packet forwarder.
R5:
no access-list 33
access-list 33 deny 155.1.0.3
access-list 33 permit any
!
interface Serial 0/0/0
ip pim sparse-mode
ip pim neighbor-filter 33
R3:
no interface Tunnel 1
!
interface FastEthernet0/0
ip igmp helper-address 155.1.0.5
ip pim dense-mode
!
interface Serial 1/0.1
ip pim dense-mode
We need to enable PIM DM on SW1’s interface connected to R3 to activate
multicast processing on this interface. A neighbor filter is used allow SW1 to
avoid becoming PIM neighbors with R3.
SW1:
ip multicast-routing distributed
!
access-list 7 deny any
!
interface FastEthernet 0/3
ip igmp join-group 239.1.1.7
ip pim dense-mode
ip pim neighbor-filter 7
Check that R5 sees the group 239.1.1.7 as directly connected on its Frame-
Relay interface. Next, ping the group from SW2.
Rack1R5#show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.1.1.7 Serial0/0 00:01:41 00:02:52 155.1.0.3
224.0.1.39 Loopback0 06:37:43 00:02:08 150.1.5.5
224.0.1.39 Serial0/0 06:37:43 00:02:54 155.1.0.5
224.0.1.39 Serial0/1 06:37:43 stopped 155.1.45.5
224.0.1.39 FastEthernet0/0 06:37:43 00:02:21 155.1.58.5
224.0.1.40 Serial0/0 00:02:01 00:02:54 155.1.0.3
224.0.1.40 Loopback0 1d01h 00:02:04 150.1.5.5
Rack1R5#
Rack1SW2#ping 239.1.1.7 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 239.1.1.7, timeout is 2 seconds:
.
Reply to request 1 from 155.1.37.7, 25 ms
Reply to request 2 from 155.1.37.7, 33 ms
Reply to request 3 from 155.1.37.7, 25 ms
Reply to request 4 from 155.1.37.7, 25 ms
Reply to request 5 from 155.1.37.7, 26 ms
Reply to request 6 from 155.1.37.7, 34 ms
Reply to request 7 from 155.1.37.7, 25 ms
Reply to request 8 from 155.1.37.7, 17 ms
Reply to request 9 from 155.1.37.7, 25 ms
Rack1SW2#
Check the multicast route states on R5 and R3. Notice that R5 uses sparsemode
SPT to forward traffic down to R3. In turn, R3 simply floods the traffic using
dense mode forwarding to the directly connected source.
Rack1R5#show ip mroute 239.1.1.7
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.7), 00:06:50/stopped, RP 150.1.8.8, flags: SJC
Incoming interface: FastEthernet0/0, RPF nbr 155.1.58.8
Outgoing interface list:
Serial0/0, 155.1.0.3, Forward/Sparse, 00:06:50/00:02:47
(155.1.108.8, 239.1.1.7), 00:00:16/00:02:44, flags: JT
Incoming interface: FastEthernet0/0, RPF nbr 155.1.58.8
Outgoing interface list:
Serial0/0, 155.1.0.3, Forward/Sparse, 00:00:16/00:02:47
(150.1.8.8, 239.1.1.7), 00:00:17/00:02:43, flags: JT
Incoming interface: FastEthernet0/0, RPF nbr 155.1.58.8
Outgoing interface list:
Serial0/0, 155.1.0.3, Forward/Sparse, 00:00:17/00:02:45
(155.1.58.8, 239.1.1.7), 00:00:17/00:02:43, flags: JT Incoming interface: FastEthernet0/0, RPF nbr 155.1.58.8
Outgoing interface list:
Serial0/0, 155.1.0.3, Forward/Sparse, 00:00:17/00:02:45
Rack1R5#
Rack1R3#show ip mroute 239.1.1.7
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.7), 00:12:25/stopped, RP 150.1.8.8, flags: SJC
Incoming interface: FastEthernet0/0, RPF nbr 155.1.37.7
Outgoing interface list:
Serial1/0.1, Forward/Dense, 00:12:25/00:00:00
(155.1.108.8, 239.1.1.7), 00:00:04/00:02:55, flags: JT
Incoming interface: FastEthernet0/0, RPF nbr 155.1.37.7
Outgoing interface list:
Serial1/0.1, Forward/Dense, 00:00:04/00:00:00, A
(150.1.8.8, 239.1.1.7), 00:00:05/00:02:54, flags: JT
Incoming interface: FastEthernet0/0, RPF nbr 155.1.37.7
Outgoing interface list:
Serial1/0.1, Forward/Dense, 00:00:05/00:00:00, A
(155.1.58.8, 239.1.1.7), 00:00:05/00:02:54, flags: JT Incoming interface: Serial1/0.1, RPF nbr 155.1.0.5
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 00:00:05/00:00:00
Rack1R3#
沒有留言:
張貼留言