From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Mon Mar 15 2004 - 12:22:29 GMT-3
At 4:16 AM -0500 3/15/04, juraj.markotic@combis.hr wrote:
>Hi group,
>I have been having problem with some scenarios having mutual
>redistribution when loops and suboptimal routing occurs. I know
>there are lot of ways of doing this, some specific to some
>situations, but I tried to approach this problem as general as I
>can, no matter which two routing protocols are in game.
First, let me say this is a really excellent post. It very nicely
reviews the problems, and I only want to elaborate on it. I'm in the
midst of writing some practice scenarios for redistribution, and,
even though I'm steeped fairly deeply in the problem, you phrased
some things very nicely.
>Tools to battle loops:
>
>**** Tags
>They don't solve suboptimal routing (at least on one of borde
>routers) and they pretty much break redundancy: if one domain (ie.
>ospf) is split in two parts, they will not be able to communicate
>over eigrp domain, because routes are filtered so no ospf routes are
>sent back to ospf domain. And also, tags are not supported in RIP1
>and IS-IS (at least in 12.2 ?). So I don't see tags as some general
>solution for handling loops. Am I Wrong ?
As an aside, in real-world networks, suboptimal routing is just not
as much a problem as it may appear to be in classes. There are many
cases, especially in service providers, where there are good
operational reasons for preferring the simplicity of a method that
may result in suboptimal routing -- the general formulation of this
approach is "hot potato" vs. "cold potato", also called "closest
exit" versus "best exit" routing. Suboptimal routing, especially in
things like OSPF summarization, may lead to more stable networks, and
stability is often more operationally important than absolute best
routing. Finally, the topology, rather than metrics, often is the
thing that determines real-world routing.
You are correct that you can't use tags for all protocols. Tag
support is just now entering ISIS. RIPv1, as you point out, does not
support them. While RIPv1 is officially considered obsolete by the
IETF, it certainly is out there is many legacy systems. I'd consider
it quite likely that you'd see RIPv1 as part of a CCIE lab
redistribution scenario, simply because it creates so many challenges
that you'll actually see with legacy networks.
One thing worth adding is that the abstract function of a tag is very
much like the abstract function of BGP communities. Communiites, and
BGP tools for using them, are more powerful. I know I had a little
trouble understanding IGP tags until I started thinking of them as
simple communities -- other people may find this approach useful.
To abstract both, remember that both a community and a tag provides a
means of speaking of a group (which just could have one member) of
routes.
>
>**** Diffenetiating between internal and external routes
>Only OSPF and EIGRP support differentiation between external and
>internal routes. EIGRP already has higher AD for external routes so
>it is pretty much loop free. So i need to do this on OSPF side and
>both domains will favor internal routes that those received thru
>redistribution (including his own routes that got back on the other
>point). So, no loops are possible here. But, only supported in
>combination ospf/eigrp, problem still exists if we use Rip/isis
>combination or something similar that can't set higher AD for
>external redistributed routes.
Again, quite true. It's also worth mentioning that OSPF and EIGRP
generally will not re-export a route they learned externally. The
motivation for this is loop prevention. Incidentally, the reason
OSPF prefers intra-area to inter-area to external is also loop
prevention.
>
>**** changing distance for specific routes only
>Good thing would be if I could change distance for all routes
>received from one specific neighbor. Well, this works for rip, eigrp
>protocols with statement
>distance 99 10.1.1.1 0.0.0.0
>and all routes received from 10.1.1.1 neighbor now have AD 199.
>But this just doesn't work for ospf and isis, because router-id for
>ospf route is router-id that originated the route, not the ruter
>that sent route to his own neighbor. Meaning, if i receive couple of
>ospf routes from my neighbor , it is possible that all routes have
>different router-id of routers that injected route in domain,
>meaning the only way I could catch them all is to use statement
>0.0.0.0, but if I do that, than I merely changed distance for all
>ospf routes received from all neighbors, not from some specific
>neighbor.
>Well that is problem only with isis and ospf. Right ?
>
>So the last solution I see is to change distance for domain specific
>routes, no matter what neighbor received from. But that is
>administratively daunting task because I have to maintain routes
>from one domain.
>For example, if I have OSPF and ISIS domain and I do double
>redistribution on 2 points I will get loop because one router will
>route to all his own isis routes trhu ospf domain (because routes
>that he received from ospf have lower AD).
For the lab, you are probably right that this is the most general
method. It is somewhat labor-intensive, and, without automated tools,
might be too cumbersome in real operations. In the lab, the
additional amount of coding does take valuable time.
I would add
**** explicit filters for certain routes, implemented either with
distribute-lists or route map ip match. These are the most
labor-intesive of all, but you should be aware of them in case the
lab scenario calls for them. They are also extremely
straightforward, and sometimes the fastest way to deal with just a
few redistributed routes.
**** hierarchical redistribution. While this is something you rarely
will be allowed to use in the lab, it's probably the most common
means of redistribution in the real world. In hierarchical
redistribution, the (generally) less intelligent protocol (e.g., RIP)
advertises all of its routes to the more capable protocol (e.g.,
OSPF). The more capable protocol sends only the default to the less
capable.
You do have to make sure the less-capable protocol doesn't export a
default route to the more-capable, which could form loops. Sometimes,
it is necessary to have different defaults in the less-capable and
more-capable domains. I've run into this most often after a merger
or reorganization, where the less-capable domain already has Internet
connectivity, and just wants to know about intra-enterprise (external
to it) routes to optimize routing to internal destinations.
>So on both border routers I could set filter that sets AD for all
>isis originated routes to have lower AD than routes received trhu
>ospf. Of course I need to have acl that define isis nets.
>For example, config of both border routers should be:
>router isis
> distance 109 0.0.0.0 255.255.255.255 ISIS_NETS
>! networks that are in ISIS domain
>ip access-list standard ISIS_NETS
> permit 150.1.16.0 0.0.0.255
> permit 150.1.56.0 0.0.0.255
> ...
>Now, both border routers will always favor those routes received
>from isis neigbhor, and not the same routes received from ospf
>domain. I have redundancy, no loops and no suboptimal routing here.
>
>Question in the end: do you thing this method is OK and is it
>general enough so I could use it on lab in any situation ? Biggest
>drawback is that I have to maintain networks in acl, and that become
>administrative task whenever new network is introduced in domain. Do
>you think I could lose point for this on exam ?
>Do you have some opservations, recommendations ?
>And most of all, do you see some wrong interpretations about
>redistribution, that I wrote about other methods ?
For the time-critical lab, I'd probably recommend using the
internal/external distinction whenever you can, due to speed and
simplicity. Changing distances and/or explicit route filtering by
prefix is your next best step. Tags, in general, are thing to use
only when the problem requires it, or perhaps where you want to
coordinate very closely with BGP.
This archive was generated by hypermail 2.1.4 : Thu Apr 01 2004 - 08:15:27 GMT-3