Task 5.3 - ACLs forbidden by task

mikem

So I am not sure if this is the result of a recent edit, or has always been this way. I cannot find anyony else point it out, so i lean towards the former.

Task 5.3 explicitly states, as the last bullet point, "Do not use any access-lists to accomplish this"

The solution guide uses the "ip multicast boundary" command which references an ACL. The SG even calls out that restriction in its explanation, yet violats it. "The multicast filtering must be done without using any access-lists."

I am thinking maybe the restriction is supposed to be something like "You may not apply an ACL to the interface to accmplish this" or "you may not use the 'ip access-group' command to accomplish this"

I was stumped on this one because I could not figure out for the life of my how to classify a single multicast address without using any kind of ACL. 

Hari.sapkota

Mike,

You are right!

The updated workbook task asks not to apply an "access-group" into the interface, which does mean that you can use an access-list with the multicast specific command like "ip multicast boundary".

Good luck!

 

alaporte

Well 4 months later and the workbook/solution guide has still not been update.

I'm being to see a lack of attention to correcting mistakes in the labs.

--------------------------------------------------------------------------------------------------

Task 5.3 Solution

<span class="code-bold">R3:</span>
interface FastEthernet0/1
 ip multicast boundary 1
 ip igmp query-max-response-time 3
 ip igmp query-interval 5
!
access-list 1 deny 226.37.1.1
access-list 1 permit any

Task 5.3 Breakdown

The task requires tuning IGMP timers and setting up multicast traffic
filtering. The wording implies changing the periodic IGMP polling and
query maximum response timer. The multicast filtering must be done
without using any access-lists. An optimum solution would be to use a
filter that blocks both control and data plane traffic. The multicast
boundary blocks the data plane traffic for denied groups and also
inspects IGMP/PIM joins for the denied groups. This allows for effective
flooding reduction for the groups that should never be joined by a
given segment.

---------------------------------------------------------------------------------------------------------

Maybe someday someone will fix this.  Does anyone someone? If so please tell him to fix this.

Andy

mikem

I'm being to see a lack of attention to correcting mistakes in the labs.

Ha, yea a bit of an understatement here. I had started sending in the feedback on the online workbooks - but it took months before anyone repsonded. Now I have finally gotten a  few responses back that showed the individual responding did not understand the issue (an INE support staff i presume). So I pretty much just gave up on that. I still like INE alot, they have some great products - but it seems the post-"publishing" error correction is just not their cup of tea. Bit of a shame