From: Schulz, Dave (DSchulz@dpsciences.com)
Date: Sat Dec 31 2005 - 16:56:44 GMT-3
This is a great tool, Brian! Thanks for sharing it. I just got it running, I
didn't see a command to clear the profile....it appears that this is only
starts when you enable and clears when it is disabled. Also, if you use this
you'll probably want to turn off the debug ip routing, since you get the
following message every 5 seconds....
*Mar 3 23:07:05.398: Periodic IP routing statistics collection
*Mar 3 23:07:10.398: Periodic IP routing statistics collection
*Mar 3 23:07:15.398: Periodic IP routing statistics collection
Dave
-----Original Message-----
From: nobody@groupstudy.com
To: InderpalS@mindscapeit.com; nenad.pudar@gmail.com
Cc: Ajaz.Nawaz@bskyb.com; ccielab@groupstudy.com
Sent: 12/31/2005 2:18 PM
Subject: RE: mutual redistribution
Your routing tables should be stable when you are finished with the core
portion of the lab and should remain stable from that point forward.
You can use debugging to verify this or look into enabling the IP route
profile feature.
Here is a little information about the IP route profile feature if you
aren't familiar with it:
<Quote>
Introduction
The Route Table Profiling feature was developed to assist network
engineers in monitoring routing table fluctuations, which may be
the result of route flapping, network failure, or network service
restoration. This feature was added in CSCdi76662 to the 11.1CC
train of Cisco IOS.
Configuration
The Route Table Profiling feature is enabled globally. The
command is "ip route profile" in global configuration mode. This
feature can be disabled with the command "no ip route profile" in
global configuration mode.
Routing table change statistics can be viewed with the "show ip
route profile" command in exec mode.
</Quote>
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/
iprrp_r/ip2_i1g.htm#wp1086995
HTH,
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
bdennis@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 775-745-6404 (Outside the US and Canada)
-----Original Message-----
From: InderpalS@mindscapeit.com [mailto:InderpalS@mindscapeit.com]
Sent: Saturday, December 31, 2005 1:44 AM
To: Brian Dennis; nenad.pudar@gmail.com
Cc: Ajaz.Nawaz@bskyb.com; ccielab@groupstudy.com
Subject: RE: mutual redistribution
Do we need to ensure there are no routing loops if lab is not
specifically
asking for it?
Inder
-----Original Message-----
From: Brian Dennis [mailto:bdennis@internetworkexpert.com]
Sent: Saturday, December 31, 2005 9:49 AM
To: nenad pudar
Cc: Nawaz, Ajaz; ccielab@groupstudy.com
Subject: RE: mutual redistribution
Unless the lab specifically asks for redundancy or states to not have
suboptimal routing, then just do not about those issues. Many people
spend
unnecessary time on solving redundancy and/or suboptimal routing issues
when
the proctors are not going to even check for them.
The only time you normally would even consider redundancy without the
lab
specifically asking for it, is when you have an interface backing up
another
interface (i.e. ISDN).
HTH,
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
bdennis@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 775-745-6404 (Outside the US and Canada)
________________________________
From: nenad pudar [mailto:nenad.pudar@gmail.com]
Sent: Friday, December 30, 2005 8:28 PM
To: Brian Dennis
Cc: Nawaz, Ajaz; ccielab@groupstudy.com
Subject: Re: mutual redistribution
Hi Brian
Actually I have the question related to this
In the Internetork book and many other documents for this scenario and
similar ones (where the other routing protocol is RIP or EIGRP with
existing
external routes) preferred solution seems to be filtering using tags.
However this doe not provide the redundancy .
My question is if redundancy was not mentioned anywhere in lab
requirements
is it safe do filtering (match easier) and not to provide any redundancy
?
thanks
Nenad
On 12/30/05, Brian Dennis <bdennis@internetworkexpert.com> wrote:
If you know what problem could occur with this topology, if there even
is
one to begin with, you will quickly be able to determine the appropriate
solution. I'll give you two hints on how you can answer your own
question:
1) EIGRP has a higher administrative distance for external routes by
default
for a reason. What is that reason?
2) If there are not any external EIGRP routes in EIGRP before
redistribution
is done between EIGRP and OSPF, you will not need to do anything (tags,
AD,
distribute-list, etc). If you do have external EIGRP routes before
doing
redistribution or switched EIGRP with RIP, you
would then have an issue to resolve.
Remember that it's just as important to understand why you are doing a
certain configuration as much as it is to know how to do the
configuration
;-)
HTH,
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
bdennis@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 775-745-6404 (Outside the US and Canada)
-----Original Message-----
From: nobody@groupstudy.com [mailto: nobody@groupstudy.com
<mailto:nobody@groupstudy.com> ] On Behalf Of Nawaz, Ajaz
Sent: Friday, December 30, 2005 5:40 PM
To: ccielab@groupstudy.com
Subject: mutual redistribution
When mutually redistributing between eigrp and ospf at two separate
points
in the network, what the cleanest & simplest way for preventing imminent
route feedback?,
Having read the archives there's mixed opinions between the use of AD
and
Tags
Many thanks
Ajaz Nawaz
-----------------------------------------
Information in this email may be privileged, confidential and is
intended
exclusively for the addressee. The views expressed may not be official
policy, but the personal views of the originator. If you have received
it in
error, please notify the sender by return e-mail and delete it from your
system. You should not reproduce, distribute, store, retransmit, use or
disclose its contents to anyone. Please note we reserve the right to
monitor all e-mail communication through our internal and external
networks.
This archive was generated by hypermail 2.1.4 : Mon Jan 09 2006 - 07:07:52 GMT-3