From: Ben-Shalom, Omer (omer.ben-shalom@xxxxxxxxx)
Date: Wed Nov 14 2001 - 07:22:13 GMT-3
My point was not to just use admin distance.
The thing is that the dangerous part is always the redist from the route
protocol with the lower admin distance to the higher (or distributing longer
prefixes) which results in address space 'high jacking'.
Since tagging does not exist in IGRP it seems to me that by making it less
desirable (IE increase the admin distance) I shift the problem to not
distributing IGRP routes back to IGRP and since OSPF does support tags I can
easily tag the incoming prefixes and not distrib them back, I can leave out
the other side as I don't really care about IGRP distributing OSPF routes
back to OSPF as now they are less desirable.
Moreover, IGRP tends to summarize automatically resulting in shorter rather
then longer prefixes.
Is this any clearer ?
Sounds correct ?
Omer.
-----Original Message-----
From: arnaud.huret@bnpparibas.com [mailto:arnaud.huret@bnpparibas.com]
Sent: Mon, November 12, 2001 1:23 PM
To: omer.ben-shalom@intel.com
Cc: ccielab@groupstudy.com
Subject: Rif. : Idea on easy safe redistribution - lookingfor opinions
Route feedback can be a problem even with higher administrative distance.
I had this interesting case when advertising a summary supernet in ospf on
some ABRs (let's say area 1) and learning from another side of the network
, a subnet part of this supernet ,redistributed from eigrp.
So on my ospf backbone the preferred route was the external one originated
from eigrp redistribution and not the supernet, which is normal.
This had tricky implications : I had some routes learnt from bgp
redistributed in ospf in my area 1, with a forward address on this subnet.
OSPF states that if you learn external routes with a forward address part
of an external network, the destination is in the topology table but is not
installed in the routing table.
So : the bgp routes were installed in the routing table in area 1 but not
on other areas .
I'm not sure I was clear (can develop deeper if you want).
The point is : always use filtering (tag if between ospf and eigrp,
distribute-list if igrp, route-map, filter-list etc otherwise), don't rely
on administrative distance.
Internet
omer.ben-shalom@intel.com@groupstudy.com - 10/11/2001 20:35
Veuillez ripondre ` omer.ben-shalom@intel.com
Envoyi par : nobody@groupstudy.com
Pour : ccielab
cc :
ccc :
Objet : Idea on easy safe redistribution - looking for opinions
Most protocols support route tags which are very useful in creating filters
to stop route feedback in a way that is self maintaining unlike specific
route maps or distribute lists which include specific routes.
Still - when distributing into a protocol that does not support tags (I
believe IGRP is one) you cannot then use a tag to limit routes coming back.
Route feedback is not really a problem when a source with a higher
administrative distance is feeding into one with lower distance as the
routes are less preferred but can be a real problem when fed from a lower
admin distance (more preferred) source to a higher admin distance (less
preferred) source.
Following this logic If I change IGRP admin distance to, say 117 to place
before RIP but after all the protocols that support route tags and then use
a route map to tag routes from IGRP to (say) OSPF and another route map to
block this tag redistributing back to IGRP am I all done with regard to the
mutual redistribution ? (I assume I can in general now ignore the feedback
from IGRP to OSPF on the grounds that OSPF routes are preferred due to the
admin distance change).
If there are no major holes you see in this then this is a few lines of
route-maps that do not need to be changed at any time in the lab and still
solve the feedback issue.
I am interested in any comments, especially if you find a problem.
PS - I can think of one problem myself and that is an ISDN on demand
circuit, even just getting a type 5 LSA for the link into the OSPF process
can keep the line up indefinitely but then I can live with filtering this
one specific route as well.
Thanks
Omer.
.
This message and any attachments (the "message") is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
---------------------------------------------
Ce message et toutes les pieces jointes (ci-apres le
"message") sont etablis a l'intention exclusive de ses
destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion
ou toute publication, totale ou partielle, est interdite, sauf
autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce
message, dans l'hypothese ou il aurait ete modifie.
This archive was generated by hypermail 2.1.4 : Fri Jun 21 2002 - 06:45:15 GMT-3