- Test - lists.nanog.org

Policy Routing
by Jeff Cates 26 Aug '01

26 Aug '01

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(a)yahoo.com __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/

8 18

RE: Policy Routing
by Martin, Christian 26 Aug '01

26 Aug '01

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(a)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(a)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(a)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(a)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(a)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/ > > >

1 0

Re: Policy routing
by Hank Nussbacher 26 Aug '01

26 Aug '01

>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. We have found that at least one version of IOS (12.0(18)S) will policy route more than you expect. When running tests in our QA lab we found that this version with policy routing and dCEF would redirect packets NOT permitted in the acl. I suggest you check your netflow records to make sure that policy routing works correctly on your version. -Hank Nussbacher Consultant Wanwall Ltd. >Jeff > >catesjl9394(a)yahoo.com

1 0

Maimi Nap of the America's
by Vinny India 26 Aug '01

26 Aug '01

Does anyone have any experience with peering at this NAP, the doc's I read say I can connect to the NAP in three flavors ATM, POS, and Ethernet. But the technical side of the house tells me I must co-locate and can only connect via ethernet for peering. Also any way to find out who is currently peering today, their web page doesn't tell me much. I would also be curios to know if there is a peermaker type site or how elegant it is to setup peering with someone at this NAP. Thanks...

13 26

RE: CR2 question
by Smith, Rick 26 Aug '01

26 Aug '01

I'm actually seeing several thousand port 80 scans per hour ! Code Red Log Checker Beginning Time... 20:00:01 Ending Time: 21:00:00 Number of attacks... 3137 Number of unique addresses... 287 -----Original Message----- From: Todd Suiter To: nanog(a)merit.edu Sent: 8/25/01 4:34 PM Subject: CR2 question Folks, Its been almost a month, and my IDS is still picking up several hundred CodeRed 2 attacks a day. Is anyone else seeing this same level of continued activity of this worm? I personally am somewhat at a loss as to how to contact people who are affected, as automated broadcasts to people, in my opinion, are NOT the way to go. BUT, going through several hundred IPs, a day, and trying to find someone at those organizations to speak to is A LOT of work. Any ideas? Thanks! todd

1 0

CR2 question
by Todd Suiter 25 Aug '01

25 Aug '01

Folks, Its been almost a month, and my IDS is still picking up several hundred CodeRed 2 attacks a day. Is anyone else seeing this same level of continued activity of this worm? I personally am somewhat at a loss as to how to contact people who are affected, as automated broadcasts to people, in my opinion, are NOT the way to go. BUT, going through several hundred IPs, a day, and trying to find someone at those organizations to speak to is A LOT of work. Any ideas? Thanks! todd

1 0

Re: multi-homing fixes
by Larry Sheldon 25 Aug '01

25 Aug '01

> > Do you *really* want your DNS TTL set down in the same range as > > the time for a BGP route fall-over? > > Ever read RFC1123? > > It states: > 2.3 Applications on Multihomed hosts > > When the remote host is multihomed, the name-to-address > translation will return a list of alternative IP addresses. As > specified in Section 6.1.3.4, this list should be in order of > decreasing preference. Application protocol implementations > SHOULD be prepared to try multiple addresses from the list until > success is obtained. More specific requirements for SMTP are > given in Section 5.3.4. > > When the local host is multihomed, a UDP-based request/response > application SHOULD send the response with an IP source address > that is the same as the specific destination address of the UDP > request datagram. The "specific destination address" is defined > in the "IP Addressing" section of the companion RFC [INTRO:1]. > > Similarly, a server application that opens multiple TCP > connections to the same client SHOULD use the same local IP > address for all. > > Unfortunately, many programs have chosen not to do this. Well, yes. But I thought the thread was talking about multi-homed _networks_, which I take to be a different problem from multi-homed _hosts_. Am I in over my head again?

2 1

The Cidr Report
by CIDR Report 25 Aug '01

25 Aug '01

This is an auto-generated mail on Fri Aug 24 23:00:01 PDT 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 24Aug01 0) General Status Table History ------------- Date Prefixes 170801 102866 180801 102777 190801 102782 200801 102807 210801 102870 220801 102815 230801 103148 240801 103170 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 82.105.0.0/16 from AS3269 *** Bogus 82.105.128.0/17 from AS3269 AS Summary ---------- Number of ASes in routing system: 11439 Number of ASes announcing only one prefix: 6806 (3880 cidr, 2926 classful) Largest number of cidr routes: 843 announced by AS701 Largest number of classful routes: 1396 announced by AS701 1) Gains by aggregating at the origin AS level --- 24Aug01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1251 964 287 22.9% Telstra Pty Ltd AS701 1396 1184 212 15.2% UUNET Technologies, Inc. AS2551 797 636 161 20.2% ICG NetAhead, Inc AS4151 289 164 125 43.3% USDA AS4293 383 274 109 28.5% Cable & Wireless USA AS6595 168 60 108 64.3% DoD Education Activity Network As AS577 294 188 106 36.1% Bell Advanced Communications Inc. AS16473 177 74 103 58.2% Bell South AS705 243 144 99 40.7% UUNET Technologies, Inc. AS6429 199 103 96 48.2% AT&T Chile Internet S.A. AS7018 746 656 90 12.1% AT&T AS4755 215 128 87 40.5% Videsh Sanchar Nigam Ltd. Autonom AS7046 339 260 79 23.3% UUNET Technologies, Inc. AS13999 103 25 78 75.7% Mega Cable S.A. de C.V. AS4200 139 73 66 47.5% Apex Global Information Services, AS12302 95 30 65 68.4% MobiFon S.A. AS1239 462 398 64 13.9% Sprint AS724 218 155 63 28.9% DLA Systems Automation Center AS6471 123 61 62 50.4% ENTEL CHILE S.A. AS3464 149 91 58 38.9% Alabama SuperComputer Network AS16758 63 6 57 90.5% IKON Office Solutions AS703 309 254 55 17.8% UUNET Technologies, Inc. AS3908 332 277 55 16.6% Supernet, Inc. AS226 147 94 53 36.1% Los Nettos AS6413 65 13 52 80.0% Southern Online Systems, Inc. AS209 282 230 52 18.4% Qwest AS1 548 496 52 9.5% BBN Planet AS17561 113 62 51 45.1% Internet service provision to Wes AS855 145 95 50 34.5% Canadian Research Network AS852 214 164 50 23.4% Telus Advanced Communications For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Re: multi-homing fixes
by John Fraizer 24 Aug '01

24 Aug '01

On Fri, 24 Aug 2001 jlewis(a)lewis.org wrote: > On Thu, 23 Aug 2001, Brian Whalen wrote: > > > Well I remember seeing a message on groupstudy where somone from the tac > > came on and made a statement along the lines that a substantial quantity > > of cases they get are a result of non Cisco memory. > > Maybe there are people out there who regularly throw just any memory in > their Cisco and wonder why it's not recognized on boot up...but I can say > I've never called TAC for that...and generally if I call TAC, it's because > IOS is buggy. > It saw the memory. (Real cisco RSP4 memory, just in an RSP8) It booted. It was REAL flakey though. It didn't see anything in the Y bus on boot but, if you removed the card and put it back in, it would see it. Very funky. --- John Fraizer EnterZone, Inc

1 0

RE: multi-homing fixes
by Roeland Meyer 24 Aug '01

24 Aug '01

|> From: Adam Rothschild [mailto:asr@latency.net] |> Sent: Thursday, August 23, 2001 10:36 PM |> |> On Thu, Aug 23, 2001 at 03:23:24PM -0700, Roeland Meyer wrote: |> > At $99US for 512MB of PC133 RAM (the point is, RAM is disgustingly |> > cheap and getting cheaper), more RAM in the routers is a quick |> > answer. Router clusters are another answer, and faster CPUs are yet |> > another. |> |> Throwing more RAM and CPU into our routers (assuming for a |> moment that |> they're most certainly all Linux PC's running Zebra) is not the |> solution you're looking for; the problem of RIB processing still |> remains. |> |> Getting a forwarding table requires extracting data from the RIB, and |> this is the problem, because RIBs are very large and active, and are |> being accessed by lots of reading and writing processes. RIB |> processing is substantial, and is only getting worse. SMP systems and multi-ported RAM is a good enough stop-gap. If I didn't like non-deterministic systems, I might suggest Echelon technologies (hardware-based neural nets). |> > If the IETF is being at all effective, that should start now and |> > finish sometime next year, so that we can start the 5-year |> > technology roll-out cycle. |> |> Roeland, The IETF is eagerly awaiting your solution. Send code. See |> Tony Li's presentation at the Atlanta NANOG on why this solution of |> jamming RAM and CPU into boxes is not a long term viable answer: |> |> <http://www.nanog.org/mtg-0102/witt.html> I've read that and largely agree. The hardware approach was only meant to buy time, while the geniuses at the IETF find a better approach. What I don't agree on, and am amazed to see, the admission that they don't know at what point the convergeince problem becomes intractible. Or even, if it does... that sounds more like a fundimental lack of understanding of the algorithm itself. |> In short, state growth at each level must be constrained and must not |> outstrip Moore's law, and to be viable in an economic sense, it must |> lag behind Moore's law. In the mid-80's, I worked on an OCR problem, involving a add-on 80186 processor card. We used a brute-force solution. It as too slow on the 8 MHz CPU. Years later, with the advent of faster hardware, the product was released. It's funny that the market timing was just about perfect. It gave that company a huge head start, when the market turned hot. It is alright to target performance/capacity solutions expected to be present at the time of product release (about 5-years from now). In fact, that's about the only way I see the problem getting solved.

4 3