Are you referring the real exam or this specific lab (vol.2 Lab13)?
In the real exam it would for sure depend of each task/section requirement if it allows or not the use of static mroute and for that you need to read carefully the task requirement, maybe you'll be breaking rules when a task requires multicast RPF to work but by not using static mroute and making it working by manipulating your IGP or so.
Don't think that your proctor will give proper reply during the exam time, you should understand the key points of whether static multicast routing is allowed or not!!!
Response from the proctor can vary - clarifying something that is not explicitly stated in the lab document should be OK, but a question such as: "How can I make this work?" is likely to result in an answer like "Go figure it out."
You mean that we cannot even clarify task restriction with Proctor???
This would be my conclusion too - although I have seen an explicit prohibition, I wouldn't necessarily trust the lack of prohibition as permission to use "ip mroute" when "static routes" are probably prohibited in the overall "do's and don't's".
My conclusion, in the lab exam, we should get a clear information whether mroute is permitted or not.
Without enabling "ip load-sharing per-packet" on R3's frame relay interfaces, there wouldn't be any loadbalancing because of CEF's default flow based load balancing behaviour.
During SG's verification, multicast fast switching was disabled on the ingress interface, that's why the debug showed it is working well. With fast switching enabled, R3 is not load balancing the tunnel's traffic.
Comments
Hi Amacia,
Are you referring the real exam or this specific lab (vol.2 Lab13)?
In the real exam it would for sure depend of each task/section requirement if it allows or not the use of static mroute and for that you need to read carefully the task requirement, maybe you'll be breaking rules when a task requires multicast RPF to work but by not using static mroute and making it working by manipulating your IGP or so.
Here is more about static mroute:
http://blog.ine.com/2011/07/31/understanding-static-multicast-routes/
And don't forget to clarify with Proctor. Learn how to ask the question [:#]
Thanks for your replies,
Yes, I'm referring to the real exam.
I think the question should explicity allow for a static mroute. In the real exam I would ask the proctor in the case.
Hello Amacia,
Don't think that your proctor will give proper reply during the exam time, you should understand the key points of whether static multicast routing is allowed or not!!!
HAPPY STUDY
[:D]
You mean that we cannot even clarify task restriction with Proctor??? [:#]
amacia,
I have seen 3 different versions of the V.2 Lab Exam - in at least one version, it was explicitly stated that static mroute was not permitted.
If it is not explicitly stated, the proctor should be able to clarify.
As nnn stated, response from the proctor can vary - clarification is within their role, giving you ideas to solve problems is not.
Good Luck!
Not always and not with every proctor!!! It really really depends!!
HAPPY STUDY
[:D]
Alexander,
Response from the proctor can vary - clarifying something that is not explicitly stated in the lab document should be OK, but a question such as: "How can I make this work?" is likely to result in an answer like "Go figure it out."
see related post and comments by Brian and scott
http://ieoc.com/forums/t/17084.aspx
My conclusion, in the lab exam, we should get a clear information whether mroute is permitted or not.
Thanks for sharing.
I agree with you Alex!!
HAPPY STUDY
[:D]
This would be my conclusion too - although I have seen an explicit prohibition, I wouldn't necessarily trust the lack of prohibition as permission to use "ip mroute" when "static routes" are probably prohibited in the overall "do's and don't's".
I have something different about this task:
Without enabling "ip load-sharing per-packet" on R3's frame relay interfaces, there wouldn't be any loadbalancing because of CEF's default flow based load balancing behaviour.
During SG's verification, multicast fast switching was disabled on the ingress interface, that's why the debug showed it is working well. With fast switching enabled, R3 is not load balancing the tunnel's traffic.
regards,