Policy Routing

John Fraizer nanog at Overkill.EnterZone.Net
Sun Aug 26 07:54:04 UTC 2001



Przemyslaw,

If I'm reading your post (between the lines) correctly, you intended to
say "if you send to company X full view over EBGP there is no technical 
reason *NOT* to forward packets over different AS path."  I may be wrong.

In any event, there IS a reason NOT to advertise full routes to a customer
that you're NOT going to honor (via the advertised AS path).  Although the
immediate nexthop to the customer is going to be your router, we're
talking about a BGP speaking customer.  If this was a static routed
customer, it would be much less of an issue.

With a BGP customer, one would think that either the customer is being
irresponsible to the routing table growth and speaking BGP as a
single-homed stub-AS, or (as I imagine in this situation) they're truely
multihomed.

In the multihomed case, if you're showing them full routes, the forwarding
path (AS path) should match what you're sending them in the NLRI.  Why?

Say the customer sees the following:

You send them an NLRI for 10.1.1.0/24 via 65530_65531_65532

Their other provider sends them an NLRI for 10.1.1.0/24 via
65535_65534_65533_65532.

Your route looks better to the customer and if they don't color it in some
way, it's going to win because the AS-PATH is shorter.

Now, we throw the policy-routing into the mix.

Although you're advertising the NLRI via 65530_65531_65532, you're forcing
their traffic to go via "NSP-A" and that AS path is actually
65534_65400_65451_65501_65530_65531_65532.

You advertised a path to them that looked better, they used it, they got a
MUCH worse route than what their other provider showed them in all
actuality because you're not sending the traffic via the route you're
advertising to them.

There is no way for the customer to tune this because they never know
which routes you're going to be lieing about.


---
John Fraizer
EnterZone, Inc



On Sun, 26 Aug 2001, Przemyslaw Karwasiecki 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/
> > >
> >
> 




More information about the NANOG mailing list