RE: BGP Question Concerning MED attribute

From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Wed Sep 10 2003 - 18:53:53 GMT-3


At 5:36 PM -0400 9/10/03, Nordhoff, Michael G. (US - Hermitage) wrote:
>Thanks for the clarification. The intent is to minimize the potential for
>asymmetrical routing that will most likely occur when the 2 ISPs I will be
>peering with connect to the same peering points beyond their AS's. For
>example, I peer with Provider A and Provider B. Provider A and Provider B
>both peer with Provider C. My intent was to ultimately influence the path
>Provider C takes back to me. Perhaps it was a good idea but not easily
>implemented...
>
>Thanks again for the feedback...
>
>- MN

Even if you could send MEDs, the ISP isn't required to use them. The
reality is that particular routing inside an ISP will only happen if
you have a business agreement to do so. The way to signal traffic
under such an agreement is with a mutually-agreed-to community.

>
>-----Original Message-----
>From: Rob Laidlaw [mailto:laidlaw@consecro.com]
>Sent: Wednesday, September 10, 2003 4:11 PM
>To: Nordhoff, Michael G. (US - Hermitage); ccielab@groupstudy.com
>Subject: Re: BGP Question Concerning MED attribute
>
>Routing TCP/IP vol.2, page 246.
>
> "When a BGP speaker learns a route from a peer, it can pass the route's
>MED to any IBGP peers, but not to EBGP peers. As a result, the MED has
>relevance only between neighboring autonomous systems."
>
>I don't believe there is anything you can do to pass this attribute. Why do
>you want to pass this information? Its function is to allow a customer with
>multiple connection to the same provider to pick their entry point. If BGP
>passed this info to the ISP's external neighbors, then the customer would be
>able to choose paths in the ISP's network rathern then the ISP.
>
>Rob
>
>----- Original Message -----
>From: "Nordhoff, Michael G. (US - Hermitage)" <mnordhoff@deloitte.com>
>To: <ccielab@groupstudy.com>
>Sent: Wednesday, September 10, 2003 3:39 PM
>Subject: BGP Question Concerning MED attribute
>
>
>> A quick question concerning the BGP MED attribute...
>>
>>
>>
>> Is it normal behavior for a BGP peer to NOT pass along MED information for
>> prefixes learned from BGP peers in different AS's? My scenario is this...
>> R1 is attached to R2. R3 is attached to R4. R2 and R4 are attached to
>R5.
>> R1 advertises a prefix to R2 via EBGP as does R3 to R4. R2 and R4 then
>> advertise these prefixes to R5 via EBGP. The MED attributes added by R1
>and
>> R3 are received by R2 and R4, respectively. However, these MEDs are not
>> being passed along to R5. What is the reason for this behavior and what
>can
>> be done to circumvent it?
>>
>>
>>
>> Thanks in advance!
>>
>>
>>
>> Mike Nordhoff - CCNP,CCDP
>>
>> Deloitte & Touche, National WAN Services
>>
>>
>>
>> This message (including any attachments) contains confidential information
>> intended for a specific individual and purpose, and is protected by law.
>If
>> you are not the intended recipient, you should delete this message. Any
>> disclosure, copying, or distribution of this message, or the taking of any
>> action based on it, is strictly prohibited.
>>
>>
>> _______________________________________________________________________
>> You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
>>
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>This message (including any attachments) contains confidential information
>intended for a specific individual and purpose, and is protected by law. If
>you are not the intended recipient, you should delete this message. Any
>disclosure, copying, or distribution of this message, or the taking of any
>action based on it, is strictly prohibited.
>
>
>_______________________________________________________________________
>You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
>
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html



This archive was generated by hypermail 2.1.4 : Wed Oct 01 2003 - 07:24:26 GMT-3