August 2001 - Test - lists.nanog.org

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

28 Aug '01

1 0

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

27 Aug '01

|> From: Steve Noble [mailto:snoble@sonn.com] |> Sent: Friday, August 24, 2001 5:16 PM |> |> On Fri, Aug 24, 2001 at 04:51:15PM -0700, Randy Bush wrote: |> > > Now on the other hand by saying "and if it's smaller |> then a /20 you will |> > > be filtered" you cause undue pressure on people to |> "spin" their designs in |> > > ways to show that they can use a /20 and get the |> allocation from ARIN |> > > directly. |> > |> > you mean not use nat? should i be broken-hearted? |> |> NAT?!? You are obviously not understanding the point I was |> attempting |> to make. |> |> The point was that companies may not need more then a /24 to |> put their |> entire site on, yet may be pushed to say they have more in order to |> acquire a /20 from ARIN, just to be globally visable. and randy's point is that the easiest way to do that, without lying through your teeth, is to *not* use NAT, thereby increasing your visible foot-print by the size of your NAT'd space. |> If you were in a position where you did NOT have your own |> previously allocated |> swamp/b/a space, you wanted to multihome to a few different providers |> in such a way that you were globally reachable no matter who |> went offline |> and you only needed a /24 or less, what would you do? Avoid *any* technology that makes more efficient use of my address space. Then I'd generate additional redundant services (legitimate and opertional, just not used much) to fatten up the foot-print. About 25 Linux boxen, implemented on BookPCs, ought to do the trick for a /19. Personally, I have yet to be pushed to such a solution, but I've thought about it and I'm not the only one. If the rules are set such that I have to do something like that, or fold the company, I would do it in a heart-beat. There is a limit to what I will sacrifice on the alter of "community spirit".

3 2

RE: RouteScience?
by John Leddy 27 Aug '01

27 Aug '01

Peter, It has been a few days, but I did want to respond to your last post. The initial PathControl product is designed to address the egress decisions of a multihomed enterprise. Many of the first product features were driven by this set of customer configurations. The NO_EXPORT attribute is an example of something that can be done in many enterprises but will not be possible in most ISP applications. The goal was to do everything possible to make it unlikely that bad configurations could leak our performance routes. We are in discussion with ISPs who wish to deploy this technology in their own networks. The constraints in that environment are rather different, and we are addressing features to deal with the added complexities of peering, downstream AS's, national/international geographies, internal link congestion, etc. We look forward to being able to discuss our ISP release on this list, once that time comes. We will be publishing more technical information about the product over time. John Leddy RouteScience > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Peter Francis > Sent: Thursday, August 23, 2001 1:53 PM > To: Sean Finn > Cc: nanog(a)merit.edu > Subject: Re: Routescience? > > > > >Christoper, > > > > no, the PathControl device does *not* adjust outgoing > >advertisements in any way; all prefixes that we repeat > >carry the NO_EXPORT attribute. > > And if the ISP using your box has downstream BGP customers in > different ASes? > > The NO_EXPORT tag really serves no purpose here because any ISP > that would be avertising your bozxes routes to its upstreams > already has a much bigger problem. > > The NO_EXPORT tag just makes it more complicated to get the > "better paths" to the ISPs BGP customers. > > Adding unnecessary locks just to make something sound "safe" is > usually a surefire way cause a disaster when a slightly-clued > person clears the tag to get the routes to downstreams and > suddenly discovers they are announcing your boxes routes to the world. > > Do you guys have a white paper on all this? > > Peter > > > > >cheers -- Sean > > > > > >"Christopher A. Woodfield" wrote: > >> > >> Can/will the box adjust inbound route selection via the use of > prepending > >> and/or provider communities? > >> > >> -C > >> > >> > Once more, we do not cause the stub AS's own advertisement > of themselves > >> > to change. We specifically avoid touching locally > originated prefixes. > >> > If the ISP is currently accepting any of the routes PathControl is > >> > designed to change, then the AS is not stub, it's transit. Hopefully > >> > this clarifies an important issue. > >> > > >> > (Referring back to Paul Vixie's point, we have found that careful > >> > optimization of a single outbound step has very substantial > payoffs in > >> > terms of the end to end, bidirectional performance. The > figures quoted > >> > on our web page and in the press release refer to this: end to end > >> > application speedup caused solely by outbound route selection!) > >> > > >> > Mike > >> > >> -- > >> --------------------------- > >> Christopher A. Woodfield rekoil(a)semihuman.com > >> > >> PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B

1 0

DNS Parser
by Deepak Jain 27 Aug '01

27 Aug '01

Since IP allocations have been such a hot topic lately, I thought I'd ask this -- Does anyone know of a simple script that will go through a list of BIND primary files, or more and output a list of output like this: secondlevel.domain --> address thirdlevel.secondlevel.domain --> address and so on for several thousand domain files. We acquired a company that never kept their reverses up to date and need a simple way of building them to keep track of their IP utilizations. There is probably one written in perl out there somewhere, I'd appreciate a pointer. Thanks, Deepak Jain AiNET

3 2

Re: multi-homing fixes
by Marshall Eubanks 27 Aug '01

27 Aug '01

> >On Fri, Aug 24, 2001 at 03:11:39PM -0700, Randy Bush wrote: >> please look at slides 11 and 15 of >> >> <http://psg.com/~randy/010809.ptomaine.pdf> >> >> the /24s of small multihomers is half the routing table (see geoff's data) >> and is growing radially (if you are silly enough not to filter that stuff). > >Does anyone have a graph of the number of allocated AS numbers? I >ask because in a perfect world each AS would originate 1 prefix >only, as they got enough address space in their first alloaction >to service them forever. In that case growth of the AS table would >be the growth of the routing table. There are a number of such plots - we have one at http://www.multicasttech.com/status/asn.plot.gif - see http://www.multicasttech.com/status/ for explanation - and there are ones at Telstra -see http://www.telstra.net/gih/papers/ipj/4-1-bgp.pdf and http://www.telstra.net/ops/bgp/pc3/bgp-as-count.html By all indications, the growth in both active AS and BGP prefixes has slowed since the market collapse. There are currently ~ 11,000 active AS and ~ 104,000 prefixes, so each ASN has on average about 9 and 1/2 prefix blocks. Regards Marshall Eubanks > >The real world would never work like that of course, but it is an >absolute lower bound on the table size, I think. I do believe we >can get much closer to this world with address space sizes like >those available in IPv6, however it's not clear to me that people >are really trying to think that way. > >-- >Leo Bicknell - bicknell(a)ufp.org >Systems Engineer - Internetworking Engineer - CCIE 3440 >Read TMBG List - tmbg-list-request(a)tmbg.org, www.tmbg.org > > Marshall Eubanks tme(a)21rst-century.com

2 1

RE: CR2 question
by Joe Blanchard 27 Aug '01

27 Aug '01

Todd, Same here. Doesn't look like the 20th cut off date applies. As I stated before, perhaps a default.ida file with an advertisement would at least generate revnue? lol.. such is life. -Joe -----Original Message----- From: Todd Suiter [mailto:todd@s4r.com] Sent: Saturday, August 25, 2001 1:34 PM To: nanog(a)merit.edu 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

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