At 9:01 PM +0000 8/4/04, neteng wrote:
>All -
>
>Thanks for the great information. I talked with SBC and since the DSL local
>POP is in the same city as our DS-3 connection they will not re-route the
>traffic to Chicago to peer to AT&T. I'm out of luck (actually my boss is
>:-)) Thanks for all the replies.
The interesting thing will be whether you can get your boss to
understand why SBC was unwilling to do so. Understanding such
business factors for service providers is a tremendous step forward
in learning to make effective commercial use of the Internet.
>
>
>""Howard C. Berkowitz"" wrote in message
>news:200408042017.i74KHupC016757@xxxxxxxxxxxxxxxxx
>> At 3:46 AM +0000 8/4/04, Peter van Oene wrote:
>> >At 12:49 PM 8/3/2004, neteng wrote:
>> >>I talked with some others that know BGP better than I do and they
>thought
>> it
>> >>might be achievable using MED. Any ideas on this from the BGP experts?
>> >>
>> >> The multi-exit discriminator (MED) attribute is a hint to external
>> >>neighbors about the preferred path into an AS when there are multiple
>entry
>> >>points into the AS. A lower MED value is preferred over a higher MED
>value.
>> >>The default value of the MED attribute is 0.
>> >
>> >It is equally common, or more so, and safer in my opinion, to use
>> >communities set by customers to influence the local pref used by the
>> provider.
>>
>> I agree completely, Peter, that communities are by far the best way
>> to do this. They are easier to maintain, and if the SP decides to
>> change the way it influences its BGP selection algorithm, the
>> mechanics of that change are hidden from customers.
>>
>> As you well know, however, the presence of a mechanism doesn't mean a
>> service provider is willing at all to implement a policy variation,
>> or will do it only for special fees. Any time a customer requests
>> something that might steer traffic away from the ISP, and thus reduce
>> its potential revenue, the customer had better have a good financial
>> argument ready on why the carrier should do what is wanted.
>>
>> This layer 8 or so negotiation is apt to be more challenging than the
>> actual routing protocol. From a pure routing standpoint, it also can
>> be quite challenging to define the semantics of the community. My
>> usual preference is to write the policy effects at least informally
>> in RPSL and check out the logic at that level of abstraction. I use
>> that method -- RPSL before BGP -- in my books.
>>
>> Incidentally, there is a freeware tool, RtConfig, which will take
>> RPSL policy statements and generate the majority of IOS configuration
>> statements needed to implement it. There were variants for
>> Wellfleet/Bay/Nortel, GateD, and RSD as well, although the Cisco
>> version is best maintained. Is there a JunOS version of RtConfig? It
> > probably wouldn't be hugely different from the GateD version.
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=91489&t=91342
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
