There seems to be a problem with the solution as R5 cannot register with the RP at R6 due to RPF failure.
Adding the following seems to fix the issue:
ipv6 route fc00:1:0:4::/64 Serial 0/1/0 multicast
After some debug, i noticed that i had to add static routes for R6 loopback, do you have an idea?
Based on the recent version of multicast WB I had to add these two static multicast routes on R5 to be able to receive traffic sourced from R1:
ipv6 route FC00:1:0:4::/64 Serial1/1 multicast
# this one not in solutions guideipv6 route FC00:1:0:6::/64 Serial1/1 multicast
There are 2 paths to R6 from R5 - via R4 and via R1. The one via R1 is picked up first (probably) and then RPF check fails. So manual malticast route
forcing RPF check against path via R4 is necessary.
Rack1R5#sh ipv6 route 2001:1:0:146:20D:65FF:FE55:AB00IPv6 Routing Table - 29 entriesCodes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route, M - MIPv6 I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 D - EIGRP, EX - EIGRP externalD 2001:1:0:146::/64 [90/514560] via FE80::4, Serial1/0 via FE80::219:E7FF:FED9:24C0, Serial1/1
I was curious about your comments regarding this and some other labs in this chapter because a few days ago I did the IPv6 workbook with no difficulties (other than ones I created). So today I fired up the rack and ran the workbook from lab 1 to 28 and again I didn't have any issues, or run into any necessity to employ static routes beyond those mentioned in the documentation in order satisfy the verification stages outlined in the documentation.
Are you using Gradedlabs equipment?
I would agree with Tom because on R5 when doing show ipv6 mroute I get the following
(*, FF08::8), 02:19:49/never, RP FC00:1:0:6::6, flags: SCLJ
Incoming interface: Serial0/0
RPF nbr: FE80::C000:7FF:FE5B:0
Immediate Outgoing interface list:
FastEthernet0/0, Forward, 02:19:49/never
Serial0/0 is the Frame-Relay interface and we dont run PIM here. So after adding the route to FC00:1:0:6::6 through Serial0/1 I am amble to ping.
I am using the GNS3 topology from Volume 2.
I had the same result as tommoser.
Before configuring the static mroute (R5: "ipv6 route FC00:1:0:6::/64 Serial0/1/0 multicast") R5's RPF interface for fc00:1:0:6::6 was Serial0/0/0. Since R1 was sending traffic to ff08::8 out Fa0/0 it would never get there as R4 would drop it. (R4 did not have the *,G entry until the static route was added on R5).
Rack1R5#sh ipv6 mroute(*, FF08::8), 00:02:09/never, RP FC00:1:0:6::6, flags: SCLJ Incoming interface: Serial0/0/0 RPF nbr: FE80::4 Immediate Outgoing interface list: FastEthernet0/0, Forward, 00:02:09/never
Rack1R5# sh ipv6 mroute(*, FF08::8), 00:11:50/never, RP FC00:1:0:6::6, flags: SCLJ Incoming interface: Serial0/1/0 RPF nbr: FE80::207:EFF:FE59:8146 Immediate Outgoing interface list: FastEthernet0/0, Forward, 00:11:50/never
I have the same issue.
As R5 is having multipath to reach R4's loopback and R6's loopback (int s0/0/0 and int s0/1/0).
R5's RPF interface to R4's loopback and R6's loopback are different.
I believe the RPF interface selection for IPv6 is different from IPv4 if there is multipath to reach the RP/Source. As far as I know, in IPv4, PIM router take the interface with highest next-hop address, but in IPv6 according to Cisco's article :
"IPv6 RPF check always considers all possible paths in the RPF interface selection and performs a hash function using the last 32 bits of the source address and the last 32 bits of the next-hop address to calculate the next-hop priority. The interface with the highest priority next-hop is selected as the RPF interface. This design decision is compliant with RFC2991, which does not suggest/support the selection of just one link from a set of equal cost paths. The check for a PIM neighbor on the RPF interface is not performed."
So INE, I think the confusion being raised is that the workbook considers/assumes only s0/0/0 of R5 which will be selected as the RPF interface to reach both R6's loopback and R4's loopback. In fact, from R5 the RPF interface to R6's loopback is s0/0/0, thus we need to add the static multicast route to change it.
And one more thing is that the same section says "R3 should be able to ping the multicast group joined by R5". I don't see any verification of of this ping from R3 and R3 is not even one of the router mentioned in the verification testing . Anyway, I tested it and couldn't ping, currently trying to figure out.....
I encountered many problems with this lab just like people mentioned. I think INE should revisit this lab. Maybe the best thing is to show the routing table that graded labs have so we all can compare and make sure that there isn't a significant difference.
I agree with everyone here. The SG is missing astatic routes, one for R4 and the other for R6. Also the task is asking "R3 should be able to ping the multicast group joined by R5." Howerver R3's interfaces S1/2 and S1/0 are not running ipv6 addresses, so should this tast state R1 or R5 instead of R3? or add ipv6 enable on S1/2 with R1? clearly the SG is lacking this verification as well, this was frustrating to get R3 to ping to R5, PLEASE INE REVISIT this task and do a better job of verification!!
Guys, I am able to work through the workbook without any problem. Let us take a walkthrough from task 9.25 because what you configure in previous task (i.e. Task 9.25) also hampers the reachability in current task (i.e. Task 9.26). I am specifically talking about disabling PIM on interfaces and mld filter. I will strictly adhere to the task requirements in the below mentioned solutions. So Let's begin....
Caution: 1) Don't configure "no ipv6 pim" on R5's Serial 0/0/0 interface because the task only says to ensure that PIM does not run on the frame-relay link between R4 and R5. So disabling PIM on R4's frame-relay link will do it. If you disable PIM on R5's Serial 0/0/0 interface then R5 can't make neighborship with R1 and R3 also on the Frame-relay link.
Caution: 2) Since the task never asked us to disable pim on the serial link between R1 and R3. So, why bother doing it. Here I digress from the Solution Guide which doesn't stick to the task as required.
Caution: 3) The task requirement clearly asks us to limit the maximum number of multicast states on the interface towards Sw2 to 10. So why not do it. Let's configure it.
Correct Solution:(Perfectly Working)
int Serial 0/0/0no ipv6 pimexit
R5 ("Y" below in the solution is to confirm to set the mld limit to 10, because when you paste the below configs directly onto the router, it will ask for the confirmation.)
int fa 0/0ipv6 mld join-group FF08::8ipv6 mld access-group SOMITipv6 mld limit 10Yipv6 mld query-interval 10exit
ipv6 access-list SOMIT permit ipv6 any FF08::/64exit
Now let's move to Task 9.26
Caution: 1) There is a typo. The task should be stating "R1 should be able to ping the multicast group joined by R5".
Correct Solution : (Working Perfectly)
ipv6 route FC00:1:0:4::/64 fastEthernet 0/0 FE80::216:46FF:FEC6:F241 multicast
ipv6 pim bsr candidate rp FC00:1:0:6::6 priority 100
ipv6 pim bsr candidate bsr FC00:1:0:4::4 priority 100
Now let's move on to Task 9.27....
Caution: 1) The second task should be "Configure R5 to join the group FF76:0640:2001:CC1E::8 on its VLAN 58 interface. Also update the previously configured filter on R5 to allow this group. " Because if you dont' allow this group in the mld filter configured, then there is no way your ping will get through.
Caution: 2) Note that you have to tell R6 that it's the RP, otherwise Embedded RP will not work. To get a clear picture, check out the blog from Keith Barker at http://blog.ine.com/2010/03/28/embedded-rp-ipv6-multicast-tips-and-tricks-part-3/
Correct Solution:(Working Perfectly)
no ipv6 pim bsr candidate rp FC00:1:0:6::6 priority 100
ipv6 pim rp-address 2001:CC1E::6
int Loopback 300ipv6 address 2001:CC1E::6/128ipv6 rip RIPNG enableipv6 eigrp 100exit
int fa 0/0ipv6 mld join-group FF76:0640:2001:CC1E::8exit
no ipv6 access-list SOMIT
ipv6 access-list SOMIT permit ipv6 any FF08::/64permit ipv6 any FF76:0640:2001:CC1E::8/128exit
I hope it helps.
Seems this task needs a bit updating. It should say R1 instead of R3?
However I'm interested why we can't ping R5 VL58 from R3? Also the show ipv6 mroute does not seem to show as much as the IPv4 equivalent. Show ipv6 mroute on R3 shows nothing, not even a (*, G).
Also how can we make sure that the router has selected a RP. Show ipv6 pim bsr election shows the BSR information. Also the show ipv6 pim range-list shows all the multicast ranges.
Is this enough to verify RP selection, shouldn't the show ipv6 pim bs rp-cache show anything. Also why can't I see anything in the mroute? If I source ping from R3 then shouldn't I see a (*, G) state?
As Tommoser says you have to add the route to R6 to get the pings to work
ipv6 route FC00:1:0:6::/64 Serial1/1 multicast
before I added this command pings would not work from R1 or R6 now they work from both. I am really suprised the workbook has not been updated with this.
Thanks for the solution guys. I spent quite a bit of time trying to get this to work.
I would send in the corrections, but it seems all of this has already been documented on the forum.
1. ping is from R1 (not R3)
2. needs a second static mroute on R5 to point out the P2P (s0/1) .... towards R6 (the RP). The SG shows this for the BSR (R4), but not for the RP (R6). Reason is that in the previous exercises, we were asked not to allow PIM between R4,R5 on the frame-relay.
You guys on the forum are GOLD. All of your previous hard work getting to the correct solutions is much appreciated. IMO, this forum is crucial for the workbook studies. THANKS!
Hi All - I ran into the same issue. However, I was able to reach the results by ultimatley bouncing the frame relay interface on R5.
I had tried to resolve by resetting the frame relay interface on R1 but there was no change. I could ping ff08::8 from the R1_"frame relay int" but not from f0/0.
I also cleared rip on R1, R4 and R6 but forgot to on R5. As soon as I bounced my frame relay interface on R5, my sh ipv mrou was accurate, pointing out the serial to R4 and I was able to ping ff08::8 from f0/0 on R1.
In addition to my previous post, after bouncing the frame relay interface on R5, pinging ff08::8 from R1_f0/0 is short lived and not permanent. After routing is fully reconverged, I could no longer ping as mentioned UNLESS the static route posted by tommoser on R5 is configured.
Please check for the end to end unicast route rechability & check again for multicast specific commands. The initial ping doesn't mean that the multicast routing is fine.
Please post the configuration.