Hi, all
I have a question regarding to redistribute IGR routes into BGP. Currently
both Cisco
and Juniper support it.
Here I don't understand what is the advantage of this redistribution?
Because BGP is
potentially injecting information into the IGP and then sending such
information back into BGP.
Could anybody provide more description regarding the advantage and the
disadvantage
of redistribuing IGP routes into BGP?
Do people use this in real life?
Thanks a lot,
Xingguo
I would much rather define my neighbors individually and control them that
way, and use either no sync or a hi metric null route to satisfy bgp's must
be in igp requirement.
Brian
How is BGP potentially injecting information into the IGP? The only way
that should be happening is if you are doing BGP -> IGP redistribution,
in which case I'd surely hope you aren't doing IGP -> BGP as well.
In my experience, most redistribution in either direction is used to
overcome design issues (such as two iBGP neighbors whose paths to each
other include a non-BGP-speaking router). I don't know that I would go
so far as to say there is absolutely no valid use for it, but I've
always seen it used strictly as a patch rather than as intended design.
The main advantage IMHO is getting something working immediately instead
of having to make design changes (when the boss wants it to work -now-),
though this certainly comes with a cost if the proper path is not
implemented shortly thereafter.
The primary disadvantages I see are:
1) Loss of information. Whether you go IGP -> BGP or vice versa, you lose
some of the specifics of routes. BGP and OSPF, for example, have different
attributes, many of which can't be mapped to a corresponding attribute in
either direction (AS-path is the most glaring example).
2) Risk of routing table pollution. More than one major ISP has had
network meltdowns of varying degrees due to redistribution mishaps.
Your policies and filters may seem to work fine, but you also may add
some routes in the future that will trip them up.
Again, I'm sure more than a few of us have used redistribution, but in
general I see it as being used in lieu of a proper solution rather than
being the proper solution itself.
-c
How is BGP potentially injecting information into the IGP? The only way
that should be happening is if you are doing BGP -> IGP redistribution,
in which case I'd surely hope you aren't doing IGP -> BGP as well.
you are an isp in a small country with half a dozen other isps. the biggest
isp in the country has half a dozed prefixes. you all meet at an exchange
point and each has an external international exit through an upstream.
you want to redistribute the bgp routes learned at the exchange point into
your dynamic igp so, when the ix is working, local traffic goes directly
there as opposed to tromboning through your default exit. one then also
wants to receive from one's upstream transit (or inject) a bgp default route
into one's igp,
and then one wants to inject one's internal routes into the bgp exports to
both the exchange and the upstream. if one's network is at all likely to
partition, that means one wants to redistribute one's igp into those two bgp
sessions, heavily acled of course.
randy
Even in a small country (perhaps a poor country), with old equipment, etc.
is this nowadays ever better than carrying it in iBGP?
Alex
you want to redistribute the bgp routes learned at the exchange point
into your dynamic igp so,Even in a small country (perhaps a poor country), with old equipment, etc.
is this nowadays ever better than carrying it in iBGP?
external ----- expensive ------ agggregation ------- exchange
transit link router point
> >
> >
some cust2
custs
if you don't, then traffic from cust2 to customers of exchange peers will
trombone across the expensive link.
randy
you want to redistribute the bgp routes learned at the exchange point
into your dynamic igp so,Even in a small country (perhaps a poor country), with old equipment, etc.
is this nowadays ever better than carrying it in iBGP?external ----- expensive ------ agggregation ------- exchange
transit link router point
> >
> >
some cust2
custsif you don't, then traffic from cust2 to customers of exchange peers will
trombone across the expensive link.
and back again, and back again, and ...
Randy Bush wrote (on Nov 03):
> if you don't, then traffic from cust2 to customers of exchange peers will
> trombone across the expensive link.and back again, and back again, and ...
Only if you're mad enough to try to run BGP across a network with
forwarding devices in the middle that don't.
Even a monetary argument for this weak. Routing decisions in a routing
domain need to be deterministic otherwise you risk the loops you mention.
In a small network you may be able to get away with it. I personally have
better things to worry about and I am sure most people do too.
IGP's rarely make the same decisions as EGP's. They don't have the same
data to base their decisions on.
Chris.
Randy,
you want to redistribute the bgp routes learned at the exchange point
into your dynamic igp so,Even in a small country (perhaps a poor country), with old equipment,
etc. is this nowadays ever better than carrying it in iBGP?external ----- expensive ------ agggregation ------- exchange
transit link router point
> >
some cust2
custsif you don't, then traffic from cust2 to customers of exchange peers will
trombone across the expensive link.and back again, and back again, and ...
Must be being very thick here.
Firstly I don't understand the trombone / routing loop issue
as if 'external transit' is the prefered exit from aggregation
router, it must have an external route itself, (rather than
hearing it from aggregation router) which means it must be
preferring external transit. So the 'problem' here would
be that traffic from cust2 trombones in the sense
of going via external transit, then hopping back over
some other link and off to the customer. It doesn't loop.
The alternate interpretation is that traffic from both
custs & custs 2 exits via the exchange point, which is
presumably undesirable in your application.
Secondly Presuming the effect that you want is
(say) to allow cust2 to get to exchange point peers directly,
but 'some custs' not to use expensive link to get there,
but to use external transit, then: Tag the routes on entry
from anywhere (external transit, custs, cust 2, exchage point)
with communities, and alter the localpref on the IBGP peering
across the expensive link, so only to the right of the link
are the exchange point routes localpreffed better than the
external transit. For a simple configuration (2 routers) you
can simplify this in the obvious manner. For a complex config
(i.e. multiple routers to the left and right), run confeds
(which minimizes the number of BGP sessions over expensive
link and is thus a good idea anyway) & apply your route map
to only the inter-confed BGP sessions. (*)
I am assuming that this is a BGP exchange point (I know
there are others), and there is a relatively normal
setup (loopback peerings, next hop self, etc.).
My point is that flexibility in terms of maintaining
finely grained traffic control whilst maintaining loop detection
seem to be rather better in BGP than your IGP du-jour. If
you make the IGP solution only slightly more complex
(put in 3 expensive links in a triangle) it becomes
hard to distinguish between customer routes and peer
routes, one of which (if remote) you probably
do want traversing expensive link(s), the other
you may not. Much nicer than using redist into
IGP, no?
(*)=there is very little you cannot do with confeds
that you would get from having multiple AS's; & we know
this problem could be solved (in an ugly manner) that
way.
Oh yes, I was assuming Randy wasn't suggesting /that/. Especially
now the memory to do it (remembering you just need customer and
peer routes) on /any/ platform is under $50.
Alex Bligh
Personal Capacity
this is getting far more complex than that point warrants.
someone said one should not distribute bgp into igp and igp into bgp.
i tried a simple example where
o there are few non-default routes but they are significant
o there are two routers that have external neighbors, at least one
of which must be an ebgp speaker and the other may be bgp or default
o and there is a third router *in the middle* to which a customer is
attached
the point is
o the router in the middle *must* do dynamic routing, or there will
be a routing loop
o for many reasons, it is likely the middle router will be an igp, not
bgp speaker
o hence very careful redistribution of ebgp to igp, and of igp to bgp
is useful
randy
Randy wrote:
o for many reasons, it is likely the middle router will be an igp, not
bgp speaker
o hence very careful redistribution of ebgp to igp, and of igp to bgp
is useful
IMHO it's much cleaner and easier to setup BGP on the router in the middle.
If it's able to carry the routes via IGP it will also be able to do it via
IBGP.
-- Arnold
IMHO it's much cleaner and easier to setup BGP on the router in the middle.
If it's able to carry the routes via IGP it will also be able to do it via
IBGP.
the middle is often a little pop with other non-bgp devices
i am sure lots of folk can come up with lots of absolutely brilliant ideas
how this could be done. but that's not the point, is it. <sigh>
randy