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.
""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=91487&t=91342
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
