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/
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/
John, I appreciate your opinion, however I would like to keep the responses to my question on a pure technical level. I can assure you that there will be full disclosure if this solution is implemented. Thanks for your response :-) --Jeff --- John Fraizer <nanog@Overkill.EnterZone.Net> 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
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 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
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
USA peering peer traffic that 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/
From: "John Fraizer" Subject: Re: Policy Routing
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?
I had the exact same thing proposed to me at one point or another in a different life, and refused outright. If the salespeople in question are like most, they've already hyped the quality of whatever transit circuits the SP in question has ... even if it hasn't been specifically mentioned, piping a given customer's traffic out your cheapest transit point is something I'd consider ethically questionable. I'm sure the customer won't appreciate it either. -travis
--- John Fraizer EnterZone, Inc
On Sun, 26 Aug 2001, Travis Pugh 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.
I had the exact same thing proposed to me at one point or another in a different life, and refused outright. If the salespeople in question are like most, they've already hyped the quality of whatever transit circuits the SP in question has ... even if it hasn't been specifically mentioned, piping a given customer's traffic out your cheapest transit point is something I'd consider ethically questionable. I'm sure the customer won't appreciate it either.
I've had the same sort of thing proposed. If the customer knows in advance that you're going to send all their traffic through your cheapest peer/transit path available, what's the problem? They get what they pay for...and for this sort of service, they'd obviously be paying noticably less than best path routed customers. I haven't actually set one of these up yet, but I don't see why they'd need to be directly on the router to peer-A...unless you're figuring the policy routing overhead will be substantially lower if you're applying on their interface rather than a generic interface (with additional traffic) on the peer-A connected router. -- ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
----- Original Message ----- From: <jlewis@lewis.org> Subject: Re: Policy Routing
I've had the same sort of thing proposed. If the customer knows in advance that you're going to send all their traffic through your cheapest peer/transit path available, what's the problem? They get what they pay for...and for this sort of service, they'd obviously be paying noticably less than best path routed customers.
full disclosure, no problem. I've never personally seen a sales rep go in and disclose something like this, and the original message was worded in such a way ("[my] upper management has proposed that I route company X's Internet traffic via a specific NSP ..") that did not indicate the customer had any idea what was being proposed. -travis
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/
On Sun, 26 Aug 2001, John Fraizer wrote:
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.
Suppose you apply an output route-map on their BGP session that prepends the heck out of paths where peer-A isn't your next as-hop? That way, you're giving them full routes and making it clear via BGP that if they have another path via another provider for non peer-A routes, the other will be better. -- ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Jon, Unless I am misunderstand how BGP (and routing at all) works something very seriously wrong with your suggestion. Your border router will advertise to a customer only best and active routes. You cannot advertise to BGP peer two routes to the same destination. So modifying AS_PATH will not work, because you will send to Customer X only best selected route from your border router. The only way to advertise suboptimal route would be to have it selected as 'best' on your border router. Of course, technically, you can advertise one thing (AS_PATH via NSP A) , and forward it to a different destination (NSP el'cheapo), but this is another story. Please correct me if I am wrong -- it is 1:40 am and I had a long day... Thanks, Przemek -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of jlewis@lewis.org Sent: Sunday, August 26, 2001 1:27 AM To: John Fraizer Cc: Jeff Cates; nanog@merit.edu Subject: Re: Policy Routing On Sun, 26 Aug 2001, John Fraizer wrote:
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.
Suppose you apply an output route-map on their BGP session that prepends the heck out of paths where peer-A isn't your next as-hop? That way, you're giving them full routes and making it clear via BGP that if they have another path via another provider for non peer-A routes, the other will be better. -- ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Sun, 26 Aug 2001, Przemyslaw Karwasiecki wrote:
Unless I am misunderstand how BGP (and routing at all) works something very seriously wrong with your suggestion.
Yeah...I should have put a few more seconds thought into that reply :)
Your border router will advertise to a customer only best and active routes. You cannot advertise to BGP peer two routes to the same destination. So modifying AS_PATH will not work, because you will send to Customer X only best selected route from your border router.
This would basically tell the customer "don't send us traffic" since assuming the cheapest path isn't the best path, the majority of routes you send the customer would be non-cheapest peer paths with lots of prepending. Just doing simple policy routing based on the customer's source address to a next-hop of the cheap peer could cause all sorts of problems as well. What if the cheap peer doesn't even have routes to the destination? i.e. the C&W/PSI peering issue a few months ago. Say C&W is your cheap peer and you send customer-X traffic to C&W desined for PSI. C&W can't deliver it and just drops it. Sucks to be customer-X. It looks like this problem is much easier to solve for incoming traffic than for outgoing. -- ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
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/
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/
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
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/
On Sun, 26 Aug 2001 02:09:26 EDT, Przemyslaw Karwasiecki said:
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?
I'll bet a small pizza that he's got an OC12 of capacity, an OC12 customer, and doesn't want the OTHER 6 OC12's worth of customers going that way... Aint traffic engineering wonderful? ;)
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/
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.
then you posted to the wrong mailing list. as you have discovered, this list is mostly used to air engineers' social, legal, and business opinions. try a technical/ops list, such as <your-router-vendor>-nsp@puck.nether.net, e.g. juniper-nsp@puck.nether.net or cisco-nsp@puck.nether.net. btw, may i presume you are trying to steer predominantly outbound traffic? inbound can be steered by only announcing the customer's routes to the desired provider, though that provides weaker redundancy. sadly, bgp offers poor knobs for this, asn prepending is popular, albeit grotty. randy
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@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/
I don't see any policy routing in this example. ou don't need polic routing if you want to direct ALL traffic by one provider or if you want to have preferences affected ALL traffic. You need polit routing if, for example, you have two providers, ISP-A and ISP-B, and two customers, C-A and C-B, and (by any reasons) want C-A to work b NSP-A and C-B to work by NSP-B (for IN and OUT traffic). Else, it's quite enougph to configure localpreferences and metrics. ----- Original Message ----- From: "John Fraizer" <nanog@Overkill.EnterZone.Net> To: "Jeff Cates" <catesjl9394@yahoo.com> Cc: <nanog@merit.edu> Sent: Saturday, August 25, 2001 9:56 PM 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/
On Sun, 26 Aug 2001 00:39:40 EDT, John Fraizer said:
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.
Given that there wasn't any indication that the "cheap" connection was any less usable/reliable, I'd *expect* that the provider I was signing up with would (as a sheer business matter) attempt to maximize the difference between what I was paying and what transit was costing, and as a result route me through th cheapest provider that met my SLA. If I was a clever customer, I'd either phrase my SLA if I cared which transit got used, or try to negotiate that some of the savings be passed along to me ;) /Valdis
participants (8)
-
Alexei Roudnev -
Jeff Cates -
jlewis＠lewis.org -
John Fraizer -
Przemyslaw Karwasiecki -
Randy Bush -
Travis Pugh -
Valdis.Kletnieks＠vt.edu