From: Godswill Oletu (oletu@inbox.lv)
Date: Sat Jul 15 2006 - 07:47:02 ART
David,
One your first question, I will surely want to create some sanity within my
IGP topology. No one might really care about suboptimal routes, but routing
loops have tendencies of creating havoks and can affect some results the
proctor might rely on to grade your lab.
You know that, things like 'traceroute' do not work well when there is a
loop, ping might not work all the time. So it is safer to use the
combination of Administrative distance & route tags to introduce some
sanity. It does not hurt to also seek the option of the proctor, but
remember that the proctor might not be the one to grade your lab, the
responsibility of creating a sane networking environment is solely on your
shoulder.
One the second question, it is a good question to ask the proctor. There
might also be some other indicators on prior tasks or subsequent tasks that
will point you one way or the other:
EG: Like in many of the commercial Labs that I have done, If a prior task or
a subsequent ask you to manipulate BGP on another router to look like an
output and they display the content of something like 'show ip bgp' of that
router, If your aggregate is not part of the routes displayed, then it might
be wise to filter your aggregate routes again chat with the proctor about
this. This is why one should make sure that current task does not conflict
or affect the results of previous or subsequent task.
If nothing else, I believe advertising the aggregate without any filtering
is just fine.
HTH.
Godswill Oletu
CCIE #16464
----- Original Message -----
From: "David Redfern (AU)" <David.Redfern@didata.com.au>
To: <ccielab@groupstudy.com>
Sent: Saturday, July 15, 2006 3:50 AM
Subject: Lab Best Practices
> To all,
>
>
> Just wondering what everyone would do in the below scenarios when in the
> lab. Question of Best Practice vs Lab requirements.
>
>
> Scenario one:
>
> You have 2 points of mutual redistribution between ospf and eigrp
> You have other external routes also coming into both protocols. (maybe
> from rip or loopbacks redistributed ect)
>
> Lab question askes you to configure redistribution between ospf and
> eigrp at the 2 points.(does not mention anything about optimal routing
> ect)
>
> Now in the above scenario the external eigrp routes from rip (admin
> 170) once redistributed into ospf (admin 110) at one of the 2 points
> will be chosen as the best path at the second point of redistribution,
> causing suboptimal routing.
> This can be resolved by tweaking the admin distances. There is also the
> possibility of routing loops forming if no method of route feedback
> prevention (such as filtering on tags) is used.
>
> If the question does not ask you to provide optimal routing or anything
> else should you
>
> A) Tweak the admin distances where necessary to provide optimal routing
> B) Don't do anything as you were not explicitely asked to do so and
> have thereform accomplished the requirements of the question.
> C) Ask the proctor
>
> In regards to the route feedback issue should you
>
> A) Use tag filtering to prevent routes redistributed from eigrp into
> ospf from having the potential to be advertised back into eigrp at the
> second point, and visa versa.
> B) Don't do anything as you were not asked to.
> C) Ask the proctor
>
>
>
>
>
> Scenario two:
>
> You are asked to advertise an aggregate bgp route of your internal
> address space to the backbone. This aggregate also is sent back to your
> internal network by default.
>
> Should you
>
> A) Filter the aggregate route from being sent back into your network
> B) Don't do anything as you were not asked to
> C) Ask the proctor
>
>
>
>
>
>
>
>
> Regards,
>
> David Redfern
>
>
****************************************************************************
*
> *
> - NOTICE FROM DIMENSION DATA AUSTRALIA
> This message is confidential, and may contain proprietary or legally
> privileged information. If you have received this email in error, please
> notify the sender and delete it immediately.
>
> Internet communications are not secure. You should scan this message and
any
> attachments for viruses. Under no circumstances do we accept liability
for
> any loss or damage which may result from your receipt of this message or
any
> attachments.
>
****************************************************************************
*
> *
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Tue Aug 01 2006 - 07:13:47 ART