From: Ben-Shalom, Omer (omer.ben-shalom@xxxxxxxxx)
Date: Tue Nov 27 2001 - 11:53:48 GMT-3
Sometimes you don't need them and sometimes you do.
The question to ask is what is faster (in the lab time counts for almost
anything):
* Not do the filtering and deal with the consequences if and when they
appear
* Automatically apply the filters.
I am not 100% decided on this as well but in general for the distrib between
flsm and vlsm I do take this measure.
I personally like the use of tags to deal with this in a generic way IE:
route-map XtoY deny 10
match tag 1
route-map XtoY permit 20
set tag 2
route-map YtoX deny 10
match tag 2
route-map YtoX permit 20
set tag 1
I apply the first to the redist from X to Y and the other to the redist from
Y to X, no route feedback is now possible both ways (if you are consistent
on this even multiple redist from the same X to the same Y are taken care
of).
This of course only works for X,Y that both supports tags.
when a protocol does not support tags (IE is flsm) I can still guard one way
(not redist back to flsm the routes from the flsm) and in this case the
worry is about the feedback from vlsm back into vlsm, this is mainly a
problem if the priority of the routes being fed back is higher.
For RIP the admin is higher so route feedback back into vlsm from RIP
usually is OK (watch the ISDN lines though)
For IGRP I tend to set the distance to 117 so it is also less favorable
In those cases I just use
route-map FtoV permit 10
set tag 3
route-map VtoF deny 10
match tag 3
route-map VtoF permit 20
and apply the first to the redist from the flsm to the vlsm and the second
to the redistribution from the vlsm (that supports tags) into flsm, that way
there is not route feedback to the flsm
If the feedback into vlsm of the vlsm own routes is still a problem (ISDN
cases mainly with OSPF demand circuit) only then do I use distrib lists.
Let me know what you think of this.
Thanks
Omer.
-----Original Message-----
From: Dennis #6 [mailto:vacant@home.com]
Sent: Tue, November 27, 2001 1:41 PM
To: CCIE Groupstudy
Subject: RE: flsm to vlsm
Thanks for your thoughts Hansang. While I haven't taken the exam I agree
with you that there are engineering standards and I would imagine that
applying these standards will not be penalized in the exam. So my strategy
will be to apply engineering standards and good design principles where ever
possible.
Dennis
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Hansang Bae
Sent: Tuesday, November 27, 2001 2:08 AM
To: ccielab@groupstudy.com
Subject: RE: flsm to vlsm
At 02:26 PM 11/27/2001 +1100, Albert Lu wrote:
>[snip]
>I'm pondering this question as well, as I see from examples in Doyle that
>redistribution between IGPs should be done carefully, so filtering via
>route-maps or distribute-list is required. That means you have to use
>route-maps and distribute-lists for all routers that are doing
>redistribution between two protocols. But Heck!!! I've seen examples that
>don't use filtering, and it still works!!
>My thoughts are that the filtering is there for precautionary measures,
just
>in case routes do feed back into the routing protocol it originated from.
>There's also the admin distance that has to be taken into account of.
>If anyone has any suggestions of the proper way of doing this, please let
me
>know
Folks,
While I understand that people are fretting about the smallest detail of
the lab (e.g. what's consider superfluous command...) there are some
definite engineering standards that should be used in the real world. One
of these is "if you redistribute, you need to route-map/distribute-list
what your redistributing." If you don't... sooner or later, you'll
experience rolling blackouts. Just about every book on IGP has examples
of route feedback causing temporary/rolling blackouts. This won't happen
every single time as it's a function of topology and routing protocols in
use. But sooner or later, you will be bitten by this.
So you should ALWAYS use route-maps (I prefer them to distribute-lists) to
control redistribution.
hsb
This archive was generated by hypermail 2.1.4 : Fri Jun 21 2002 - 06:45:23 GMT-3