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