Task 5.1
5. Multicast
Some of the multicast settings have been pre-configured for you. You need to
discover the active multicast topology using the show commands.
5.1 PIM Filtering
- A media server located on VLAN 32 will be streaming a video feed to
clients located on VLAN 5.
- The network administrator has requested that the Frame Relay connection
between R1 and R5 be used as sparingly as possible for multicast traffic.
- To help avoid excess multicast flooding and pruning behavior over this
Frame Relay connection, R1 should not allow R5 to become a PIM
neighbor. However, R5 should still allow clients on VLAN 5 to receive
multicast traffic for this group.
- Configure your network to support this arrangement.
This task was a tough one for me.
I could get the solution as perscribed in the solution guide
but it would not vlaidate.
We were to discover the MPLS topology but not change the topology.
R2 S0/0 did not have PIM enabled so RPF path needed to go from r3 to r1
through subnet 191.1.13.0. This took a while to figure out that an OSPF
virtual link was required for area 13 so the routing went from r3 -> r1 ->r5
so it followed the PIM interface path. Also adjusted an ospf cost value.
Config
R1
router ospf 1
area 13 virtual-link 150.1.3.3
R3
router ospf 1
area 13 virtual-link 150.1.1.1
Path
Rack1R3#trace 191.1.5.5
1 191.1.13.1 16 msec 16 msec 16 msec
2 191.1.125.5 40 msec * 40 msec
Rack1R3#
Rack1R5#trace 192.10.1.3
1 191.1.125.1 28 msec 28 msec 28 msec
2 191.1.13.3 40 msec * 40 msec
Rack1R5#
Now the route and the PIM interface path match.
The validation still fails.
The client is Vlan 5 so R5 int f0/0 must do the join.
interface FastEthernet0/0
ip address 191.1.5.5 255.255.255.0
ip pim dense-mode
ip igmp helper-address 191.1.125.1
ip igmp join-group 225.5.5.5
The server is Vlan 32 so the ping needs to originate from R3 int F0/0.
Rack1R3#ping 225.5.5.5 source f0/0 r 99
Type escape sequence to abort.
Sending 99, 100-byte ICMP Echos to 225.5.5.5, timeout is 2 seconds:
Packet sent with a source address of 192.10.1.3
Reply to request 0 from 191.1.125.5, 109 ms...........
Rack1R3#
The first ping after "clear mr *" works and all others fail.
The ping from r1 is sucessful:
Rack1R1#ping 225.5.5.5 r 99
Type escape sequence to abort.
Sending 99, 100-byte ICMP Echos to 225.5.5.5, timeout is 2 seconds:
Reply to request 0 from 191.1.125.5, 116 ms
Reply to request 1 from 191.1.125.5, 124 ms
Reply to request 2 from 191.1.125.5, 124 ms
Reply to request 3 from 191.1.125.5, 124 ms
Reply to request 4 from 191.1.125.5, 125 ms
Reply to request 5 from 191.1.125.5, 128 ms
Reply to request 6 from 191.1.125.5, 128 ms
Rack1R1#
So there is something with PIM dense mode and the frame configuration
that is not happy. I even tried ip pim NBMA which i know should not be used with dense mode but it did help so I turned it off.
In an attempt to debug the problem I did a "no ip mroute-cache" on R1 s0/0.
Rack1R1(config)# interface Serial0/0
Rack1R1(config-if)#no ip mroute-cache
Now everything is validating.
Rack1R3#ping 225.5.5.5 source f0/0 r 99
Type escape sequence to abort.
Sending 99, 100-byte ICMP Echos to 225.5.5.5, timeout is 2 seconds:
Packet sent with a source address of 192.10.1.3
Reply to request 0 from 191.1.125.5, 108 ms
Reply to request 1 from 191.1.125.5, 105 ms
Reply to request 2 from 191.1.125.5, 104 ms
Reply to request 3 from 191.1.125.5, 104 ms
Reply to request 4 from 191.1.125.5, 104 ms
Reply to request 5 from 191.1.125.5, 104 ms
Reply to request 6 from 191.1.125.5, 104 ms
Reply to request 7 from 191.1.125.5, 104 ms
Reply to request 8 from 191.1.125.5, 105 ms
Rack1R3#
So to get multicast dense mode to work with this frame-relay configuration
requires the following commands:
Rack1R1(config)# interface Serial0/0
Rack1R1(config-if)#no ip mroute-cache
I am running real routers and switches with the perscribed IOS.
I dont like turning off mroute-cache so
if anyone has found another way to get this task to
validate, I welcome a response.