Policy Routing

Sun Aug 26 05:54:27 UTC 2001

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 at 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 at merit.edu
> [mailto:owner-nanog at merit.edu]On Behalf Of
> John Fraizer
> Sent: Sunday, August 26, 2001 12:57 AM
> To: Jeff Cates
> Cc: nanog at 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 at 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/