|
Thread Index [isp-bgp] Re: MEDs from different ASes
the most common reason why i see people do that:
-> people who are lazy and can't get control of themselves with as path
and local pref attributes and igp cost (when did people realize they
should completely rely on MED to influence egress traffic ratio? :) )
i myself have used always-compare-med in a specific situation that
warrented such application due to a software bug that did not take igp cost
into consideration. this was on a remote pop with no ebgp peers, so needed
something to maintain hot potato routing when igp cost didn't work right
with bgp due to a bug.
-J
On Thu, May 20, 2004 at 07:10:29PM +0530, Tulip Rasputin wrote:
> Hi Jim,
>
> Thanks for the response. I think i wasnt very clear with my question. Too
> little coffee .. eh ?!?
>
> I am aware of how we can configure the boxes so that the MEDs are always
> compared, even across the ASes. What i wanted to know was, *why* would
> somebody ever want to do that?
>
> Regards,
> Rasputin
>
> ----- Original Message -----
> From: "James" <haesu@...>
> To: <isp-bgp@isp-bgp.com>
> Sent: Thursday, May 20, 2004 7:00 PM
> Subject: [isp-bgp] Re: MEDs from different ASes
>
>
> On Thu, May 20, 2004 at 12:08:37PM +0530, Tulip Rasputin wrote:
> > Hello,
> >
> > I am able to comprehend the concept of comparing MEDs for the routes that
> we
> > recieve from the same AS.
>
> yes, that's what a MED is for. it's designed to let you 'view' the
> "topology"
> of your peer's setup when peering at multi locations. this is the default
> behaviour, also as deterministic-med
>
>
> > What confuses me is when, would we really want to
> > compare MEDs across different ASes?
>
> conf t
> router bgp ASN
> bgp always-compare-med
>
>
> > MEDs can mean different things to
> > different operators, one could be reflecting the internal IGP costs in the
> > MED, the other could be doing something totally different. How and in what
> > scenario, will we want to compare MEDs across different ASes?
> >
> > Can anybody throw any light on this? Has anybody ever done that? And if
> yes,
> > then when?
>
> yes i have. honestly, i don't like doing it that way.
>
> >
> > One reason which i can think of at the top of my head is to avoid RFC 3345
> > oscillations. We may use always-compare-MED to prevent those. But then
> there
> > are many topological solutions that can help prevent those oscillations.
>
> always-compare-med compares MED between varying ASes. remember that if a
> path
> has smaller as path, it will still win (med comes after as path check)
>
> -J
>
>
> >
> > Thanks,
> > Rasputin
> >
> >
> >
> >
> > To unsubscribe via postal mail, please contact us at:
> > Jupitermedia Corp.
> > Attn: Discussion List Management
> > 475 Park Avenue South
> > New York, NY 10016
> >
> > Please include the email address which you have been contacted with.
>
> --
> James Jun TowardEX Technologies,
> Inc.
> Technical Lead Network Design, Consulting, IT
> Outsourcing
> james@... Boston-based Colocation & Bandwidth
> Services
> cell: 1(978)-394-2867 web: http://www.towardex.com , noc:
> www.twdx.net
>
>
> To unsubscribe via postal mail, please contact us at:
> Jupitermedia Corp.
> Attn: Discussion List Management
> 475 Park Avenue South
> New York, NY 10016
>
> Please include the email address which you have been contacted with.
>
>
>
>
> To unsubscribe via postal mail, please contact us at:
> Jupitermedia Corp.
> Attn: Discussion List Management
> 475 Park Avenue South
> New York, NY 10016
>
> Please include the email address which you have been contacted with.
--
James Jun TowardEX Technologies, Inc.
Technical Lead Network Design, Consulting, IT Outsourcing
james@... Boston-based Colocation & Bandwidth Services
cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
To unsubscribe via postal mail, please contact us at:
Jupitermedia Corp.
Attn: Discussion List Management
475 Park Avenue South
New York, NY 10016
Please include the email address which you have been contacted with.
Thread Index |
|
