Jeff, Does the router with the OC-12 have other eBGP sessions? Also, is the customer a BGP customer? Everyone keeps talking about their feed, but I haven't seen you mention BGP with the customer. Anyway, if you can connect the OC-12 and the customer to the same router, then outbound traffic vectoring is quite easily accomplished with BGP alone. Simply increase the weight attribute of all routes from this OC-12 peering. Or, set the LPREF high on the ebgp session and a lower LPREF on all iBGP sessions. Or, set the LPREF the same throughout the AS and rely on administrative distance and igp cost to force traffic out the OC-12. If you want return traffic to flow back across this link, then depreference the route(s) upstream using communities (most NSPs support the provider backup setting, usually <ASN>:70), which, assuming your upstreams are well connected and exchanging routes, will redirect all or most of the traffic across the OC-12. Or, you can use the good old AS-PATH padding, which is a little less deterministic, but won't bounce traffic around too much across your upstreams mutual peering connections. This is quite common among the RBOCs, actually, because of regulation and anti-slamming and other silly things. A second note of caution: Using route depreferencing vs AS-PATH padding may cause certain peering connections between your upstreams to become quite saturated, particularly at OC-12 speeds. However, it will force all, or under certain policies, nearly all of the return traffic to a set of NLRI across the circuit you choose, as long as your upstreams are well connected to one another, allow customer depreferencing through communities, and treat peer routes as worse than customer routes, but better than customer backup routes. regards, -chris (speaking on my own behalf using my own views)
-----Original Message----- From: John Fraizer [mailto:nanog@Overkill.EnterZone.Net] Sent: Sunday, August 26, 2001 3:58 AM To: Jeff Cates Cc: Travis Pugh; nanog@merit.edu Subject: RE: Policy Routing
If the OC-12 connection is via a well connected provider and it's that much less expensive than your other providers, and it's seeing that little traffic, I would suggest a MUCH simpler alternative: Tune your route-maps to pref more traffic towards that provider OVERALL. That way, you'll save money on ALL of your customers and not just this one special case. ;)
--- John Fraizer EnterZone, Inc
On Sat, 25 Aug 2001, Jeff Cates wrote:
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
policy-routing my traffic to the "cheap" connection vs the best connection.
Is it just me or do others on the list believe
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
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
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
to us.
Redirecting inbound traffic to company X via NSP-A can be accomplished very easily through use of AS
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
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
to NSP-A once the MPLS label was popped off the last router in the path in transit to the NSP-A
found out that you were that in the absence of full peering peer traffic path policy traffic 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/