North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical 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 <[email protected]> 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: [email protected] > [mailto:[email protected]]On Behalf Of > John Fraizer > Sent: Sunday, August 26, 2001 12:57 AM > To: Jeff Cates > Cc: [email protected] > 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 > > > > > > [email protected] > > > > > > > > > > __________________________________________________ > > > 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/
|