• Enable multicast routing on R1 and configure PIM sparse-dense mode on the Fast Ethernet interface of R1.
• Configure PIM sparse-dense mode on the connection between R1 and
R5.
• Use the same RP assignment that was configured on the other routers.
• Ensure R1 is always elected via PIM to flood traffic onto the shared VLAN 146 segment.
-----------------------------------------------------------
If multiple multicast routers share a single segment, then all of them could flood this segment with the same multicast traffic.
upstream neighbors, they will both send it to R6. From R6’s point of view, both
flows are the same with respect to RPF validation. Thus, traffic duplication
occurs.
In order to avoid this situation, only one router is allowed to flood traffic on the
shared segment. When a router detects that someone is sending traffic for the
same source IP/destination group on the segment, where it has an active (S,G)
state for the same group/source, it immediately originates a PIM Assert
message. This message contains the source IP, the group and the path cost to
the source. The path cost is a touple (AD, Metric), where AD is the administrative
distance of the routing protocol used to look up the source IP, and Metric is that
same protocol’s metric to reach the source. The router with the best (lowest) AD
value on the segment wins the assertion. If the ADs are equal, then metric is
used as tie-breaker. If both the AD and the metric are the same, the router with
the highest IP address wins. If another router on the segment receives the Assert
message and determines that it loses the assertion, it will remove the (S,G) state
on its interface and stop flooding traffic. However, if it sees itself as the winner, it
will emit a superior PIM Assert message to inform the other router that it should
stop flooding the traffic for this (S,G) pair.
Note that the PIM Assert procedure might be dangerous on NBMA interfaces.
PIM will treat those interfaces as fully broadcast capable networks, even though
not all nodes are capable of hearing each-other’s broadcast messages. Imagine
a hub-and-spoke Frame-Relay topology. If both the hub and the spoke start
flooding the segment with the same multicast traffic, PIM Assert will occur. If for
some reason the spoke should win, then the hub will stop sending its multicast
traffic. However, all traffic coming from the spoke to the hub is NOT relayed back
to the other spokes sharing the same segment, based on the RPF rule. Thus, all
other spokes will effectively stop receiving the multicast traffic. To avoid this
situation, either use PIM NBMA mode (described in a separate task) or make
sure that the hub always wins the PIM Assert procedure.
In our scenario, R1 and R4 run different IGPs. This is not a well-designed
multicast solution, as you may want all routers to be under the same IGP. In our
case, under normal circumstances R4 would be the assert winner as EIGRP has
a better AD (90) than OSPF (110). However, by adjusting the AD of OSPF on
R1, we artificially make R1 the assert winner on the shared segment.
-----------------------------------------------------------
R1:
access-list 10 permit 224.0.0.0 0.255.255.255
!
ip multicast-routing
ip pim rp-address 150.1.5.5 10
!
interface FastEthernet0/0
ip pim sparse-dense-mode
!
interface Serial 0/0.1
ip pim sparse-dense-mode
!
router ospf 1
distance 80
R5:
interface Serial 0/0/0
ip pim sparse-dense-mode
-----------------------------------------------------------
Join the group 239.6.6.6 on R6 and ping this IP address from SW4. The group
will use simple dense-mode forwarding, and R1 will be elected as the assert
winner on the VLAN 146 segment. Please note that we receive two responses for
the first ping. This is due to the fact that both R1 and R4 initially try to source the
traffic to R6. The PIM Assert Process stops this parallel forwarding of traffic when
one router becomes the PIM Forwarder. In this case we “rigged” the election by
assigning a better Administrative Distance to OSPF on R1.
R6:
interface FastEthernet 0/0.146
ip igmp join-group 239.6.6.6
Rack1SW4#ping 239.6.6.6 repeat 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 239.6.6.6, timeout is 2 seconds:
Reply to request 0 from 155.8.146.6, 36 ms
Reply to request 0 from 155.8.146.6, 76 ms
Reply to request 1 from 155.8.146.6, 72 ms
Reply to request 2 from 155.8.146.6, 72 ms
Reply to request 3 from 155.8.146.6, 72 ms
Reply to request 4 from 155.8.146.6, 72 ms
The mroute entry on R1 is marked with an “A” flag, which means “Assert Winner”.
Rack1R1#show ip mroute 239.6.6.6
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.6.6.6), 00:02:59/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/0.1, Forward/Sparse-Dense, 00:03:01/00:00:00
FastEthernet0/0, Forward/Sparse-Dense, 00:03:01/00:00:00
(155.1.108.10, 239.6.6.6), 00:03:01/00:00:08, flags: T
Incoming interface: Serial0/0.1, RPF nbr 155.1.0.5
Outgoing interface list:
FastEthernet0/0, Forward/Sparse-Dense, 00:03:01/00:00:00, A
Rack1R4#show ip mroute 239.6.6.6
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.6.6.6), 00:01:29/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/1, Forward/Sparse-Dense, 00:01:29/00:00:00
FastEthernet0/1, Forward/Sparse-Dense, 00:01:29/00:00:00
(155.1.108.10, 239.6.6.6), 00:01:29/00:02:44, flags: PT
Incoming interface: Serial0/1, RPF nbr 155.1.45.5
Outgoing interface list:
FastEthernet0/1, Prune/Sparse-Dense, 00:00:18/00:02:41
If you were to enable the following debugging on R1 before sending pings from
SW4, you can catch the PIM Assert message exchange between R1 and R4.
Notice that R1 wins due to the better AD.
Rack1R1#debug ip pim
PIM(0): Received v2 Assert on FastEthernet0/0 from 155.1.146.4
PIM(0): Assert metric to source 155.1.108.10 is [90/2174976]
PIM(0): We win, our metric [80/20]
PIM(0): (155.1.108.10/32, 239.6.6.6) oif FastEthernet0/0 in Forward
state
<snip>
What happens if the Assert Winner stops working? Well, unfortunately, the
Assert “Loser” has no way of knowing the Assert “Winner” has failed and will wait
three (3) minutes before timing out its pruned interface. Thus we face a worst
case scenario of loss of traffic for three (3) minutes should the PIM Assert winner
go down right after winning the election.
沒有留言:
張貼留言