RE: Policy Routing

["Przemyslaw Karwasiecki" <karwas () ifxcorp com>]

Jeff,

Please let me understand it a little bit more:

If this OC12 path is so good, why you will simply
not modify your LOCAL_PREF in such way that ALL your
traffic will go over this link?

In such way you will simply send to your customer
your BGP routing table and everything will be simple:
What you have in your routing table will be what your
customer will receive from you and (more importantly)
it will also represent how you are really forwarding 
packets.


Przemek


-----Original Message-----
From: owner-nanog () merit edu [mailto:owner-nanog () merit edu]On Behalf Of
Jeff Cates
Sent: Sunday, August 26, 2001 1:54 AM
To: John Fraizer; Travis Pugh; Jeff Cates
Cc: nanog () merit edu
Subject: RE: Policy Routing



For the record, this "cheap path" is an OC-12 to a
well connected Tier 1 provider that we got a
"sweatheart" deal on, and, it's only 2 percent
utilized.

Again, I want to emphasize that I wholeheartedly agree
with those who have commented on the concept of full
disclosure in a scenario such as this. I'm just
looking for technical opinions on how this can be
accomplished most effectively.

--Jeff

--- Przemyslaw Karwasiecki <karwas () ifxcorp com> wrote:
> John,
>
> First: I agree with you at your main point 110% so
> my other
>        comment is strictly technical in nature.
>
> Second: Correct me if I am wrong, but I believe that
> if you send
>         to company X full view over EBGP there is no
> technical
>         reason to forward packets over different AS
> path.
>         After all, you are advertising reachability
> via NEXT_HOP,
>         which will be your border router.
>
> Before you flame me, please let me reiterate that I
> agree with you
> on the main point, that making a false/misleading
> AS_PATH advertisements
> is bad. But I am just curious if it would work
> provided that you are
> able to forward packets based on some 'coloring'
> scheme,
> so please consider my comment more as a question
> then questioning :-)
>
> Thanks,
>
> Przemek.
>
>
> -----Original Message-----
> From: owner-nanog () merit edu
> [mailto:owner-nanog () merit edu]On Behalf Of
> John Fraizer
> Sent: Sunday, August 26, 2001 12:57 AM
> To: Jeff Cates
> Cc: nanog () merit edu
> Subject: Re: Policy Routing
>
>
>
>
> Replying to my own post with a bit more. (Forgive
> me!)
>
> Rereading your post, one would believe that since
> "Company X" is a BGP
> customer of yours, you're going to be sending them a
> full view.  Unless
> there is a knob that I'm not familiar with, that
> means that you're going
> to be sending them the _BEST_ routes that you see in
> your core and not
> just those from "NSP A" to which you are proposing
> to policy-route all of
> "Customer X's" traffic.  If this is indeed the case,
> I would think that
> policy-routing the customers traffic destined for
> "prefix Y" via a
> path other than the path listed in the NLRI you're
> sending "Customer X" on
> their BGP feed is outright fraud.
>
> Again, this is in the absence of full disclosure and
> it is my (non
> esquire) opinion.
>
>
> ---
> John Fraizer
> EnterZone, Inc
>
>
> On Sun, 26 Aug 2001, John Fraizer wrote:
>
> > I would be very upset if I were "Company X" and I
> found out that you were
> > policy-routing my traffic to the "cheap"
> connection vs the best
> > connection.
> >
> > Is it just me or do others on the list believe
> that in the absence of full
> > disclosure this would be shady at best?
> >
> >
> > ---
> > John Fraizer
> > EnterZone, Inc
> >
> >
> > On Sat, 25 Aug 2001, Jeff Cates wrote:
> >
> > > Hello,
> > >
> > > I am a network engineer at a regional southeast
> USA
> > > NSP. I am looking for some recommendations
> concerning
> > > a scenario that has been presented to me.
> > >
> > > My company is attempting to obtain company X's
> > > Internet transit traffic, which will be  BGP-4
> peering
> > > over either a T-3 or OC-3. Due to financial
> reasons,
> > > my upper management has proposed that I route
> company
> > > X's Internet traffic via a specific NSP that we
> peer
> > > with, we'll call them NSP-A. Apparently, NSP-A
> has a
> > > substantially cheaper rate than our other
> upstrem
> > > providers and it is anticipated that this
> customer
> > > will be sending a full T3 or OC-3's worth of
> traffic
> > > to us.
> > >
> > > Redirecting inbound traffic to company X via
> NSP-A can
> > > be accomplished very easily through use of AS
> path
> > > prepending, however, coming up with a solution
> for
> > > egress traffic from company X to NSP-A, via our
> AS,
> > > has proven a bit more challenging :-).
> > >
> > > The only feasible solution that I've been able
> to come
> > > up with is to stick customer X directly on the
> router
> > > that peers with NSP-A and employ the use of
> policy
> > > routing, which would enable me to set the next
> hop for
> > > company X's traffic to the peering address on
> NSP-A.
> > > Our NSP-A peering router is a Cisco 12016,
> running IOS
> > > 12.0(16)S2 and it has 256MB of DRAM.
> > >
> > > Additionally, it is configured with NetFlow and
> dCEF
> > > switching.
> > >
> > > I've never employed policy routing in this type
> of
> > > environment and I am concerned about the
> overhead that
> > > it might place on the router or on the traffic
> > > traversing the interface.
> > >
> > > I've also thought about MPLS TE, however, our
> core
> > > backbone does not run MPLS and even if we did, I
> > > believe I would still have to policy route the
> traffic
> > > to NSP-A once the MPLS label was popped off the
> last
> > > router in the path in transit to the NSP-A
> peering
> > > router.
> > >
> > > Any ideas or comments would be greatly
> appreciated.
> > > Thanks in advance,
> > >
> > > Jeff
> > >
> > > catesjl9394 () yahoo com
> __________________________________________________
> > > Do You Yahoo!?
> > > Make international calls for as low as
> $.04/minute with Yahoo! Messenger
> > > http://phonecard.yahoo.com/



__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/