IEOC - Internetwork Expert's Online Community

I think you are right, i had to do the same thing. Another way to make work is to add the Multicast BGP Neighborship between R4 and R6, so R4 will also get the RPF neighbor via MBGP. Don't know what is better, maby the static MRoute.

Seen the same problem.

Solved by Multicast BGP between R4 and R6. According to spesifications we should not use static routes, assumes this applies til static mroutes as well.

Task 6.3 now states "Configure a multicast BGP peering between R2 and R6".

What's weird now is that I cannot get R5 to source multicast packets from its loopback interface :)   I have PIM enabled on the loopback and everything.  R4 definitely sees the packets, but they are comfing from R5's E0/0 interface and not the loopback.

Same issue here, I resolved by changing the BGP distance for all routes to 1 under multicast af, before which the local tables had a preference. I changed to the following and the "sh ip rpf 20.1.5.5" shows via R2 not R4 as before the distance change. following this first and consecutive pings from R5 worked.

address-family ipv4 multicast
  neighbor 20.1.26.2 activate
  distance bgp 1 1 1
  no auto-summary
 exit-address-family
 !

SPRack1R6#sh ip rpf 20.1.5.5
RPF information for ? (20.1.5.5)
  RPF interface: FastEthernet0/1
  RPF neighbor: ? (20.1.26.2)
  RPF route/mask: 20.1.5.5/32
  RPF type: mbgp
  RPF recursion count: 0
  Doing distance-preferred lookups across tables

Forgot to add "sh ip rpf 20.1.5.5" before the change, which shows the RFP path from OSPF not MBGP

RPF information for ? (20.1.5.5)
  RPF interface: FastEthernet0/0
  RPF neighbor: ? (20.1.46.4)
  RPF route/mask: 20.1.5.5/32
  RPF type: unicast (ospf 1)         <------------------------------------------ NOT MBGP !
  RPF recursion count: 0
  Doing distance-preferred lookups across tables

If using MP-BGP for R2 with R6 and adding the 20.1.5.5 loop from R5, no mroute is needed in R6, BUT there is one needed in R2, since it will have an ip route to the loop of R5 via R1 and using the TE tunnel.

If the TE tunnel is up add an ip mroute in router 2 for 20.1.5.5 via s2/1 and one in R3 for 20.1.2.2

Static route is not needed. The key is to set distance 19 only for R3 loopback in task 3.5; so R6 and R3 control traffic will prefer R4 but R6 to R5 still goes through R2.

R6#sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     20.0.0.0/8 is variably subnetted, 9 subnets, 2 masks
C       20.1.26.2/32 is directly connected, Ethernet1/0
C       20.1.26.0/24 is directly connected, Ethernet1/0
C       20.1.6.6/32 is directly connected, Loopback0
B       20.1.5.5/32 [20/21] via 20.1.26.2, 00:08:04
O       20.1.4.4/32 [110/11] via 20.1.46.4, 01:19:31, Ethernet0/0
O E2    20.1.3.3/32 [19/1] via 20.1.46.4, 01:17:38, Ethernet0/0
B       20.1.2.2/32 [20/0] via 20.1.26.2, 00:08:04
B       20.1.1.1/32 [20/11] via 20.1.26.2, 00:08:04
C       20.1.46.0/24 is directly connected, Ethernet0/0
B    200.1.100.0/24 [20/21] via 20.1.26.2, 00:08:04
B    217.1.0.0/22 [20/0] via 20.1.26.2, 00:08:04

there are many solutions for this, yours is correct as well as the ip mroute, as long as they dont affect other tasks or use things that you should not.

I prefer the ip mroute so I dont affect any of the routing I have done.

shun:

Static route is not needed. The key is to set distance 19 only for R3 loopback in task 3.5; so R6 and R3 control traffic will prefer R4 but R6 to R5 still goes through R2.

I had the same thing, and hence didnt need mroute.