- Test - lists.nanog.org

Re: C&W Peering
by Patrick W. Gilmore 04 Jun '01

04 Jun '01

At 05:44 PM 6/4/2001 -0400, Travis Pugh wrote: >route-views.oregon-ix.net concurs: > >route-views.oregon-ix.net>sh ip bgp regex ^3561_174_ > >route-views.oregon-ix.net> Yes, but if one or the other has backup peering, it would not look like that. It would look like _3561_.*_174_ or _174_.*_3561_ - prolly the former since AS3561 gives route-views a feed, but AS714 does not. Looking in route-views for those two patterns, I see only a few routes under 3561.*_174_, probably leakage. There are no routes of the form _174_.*_3561_. Since route-views does have a feed from AS3561, I would say it is official. Cable and Wireless cannot reach PSI.net. Congratulations ladies & gentlemen. The first intentional, prolonged, significant (for some values of "significant" :) outage on the Internet. And we were all here to see it.... Wow, in the same week MAE-East dies. Sad time for the 'Net. :(( >-travis -- TTFN, patrick

5 5

Traceloop between PSI and C&W
by Steve Schaefer 04 Jun '01

04 Jun '01

Here's a quick link so that anyone can check to see actual traces between C&W and PSI. When (if?) they find each other again, you'll be able to see the actual routes (in both directions): http://www.traceloop.com/cgi-bin/traceloop.cgi?sid=fnryumci&dn=AS3561.a1 This is a special link -- you'll have to log out and log in if you want to use the normal service. Every Traceloop is being done by the same two test points, so there could be some blocking when this post first hits... Hope that helps. Steve Schaefer Dashbit - The Leader In Internet Topology www.dashbit.com www.traceloop.com

1 0

Re: C&W Peering
by Kevin Loch 04 Jun '01

04 Jun '01

This is sure to create a number of "big pipe orphans". I wonder if this will create a surge in multihoming attempts? How could you discourage that now? Unlike the recent DSL disasters, you can't just say "buy a T1 if you want reliable service". Even if you are not a PSI customer, it would be foolish not to multihome now. Did C&W consider the route table effects of this new routing policy? KL "Patrick W. Gilmore" wrote: > > At 05:44 PM 6/4/2001 -0400, Travis Pugh wrote: > > >route-views.oregon-ix.net concurs: > > > >route-views.oregon-ix.net>sh ip bgp regex ^3561_174_ > > > >route-views.oregon-ix.net> > > Yes, but if one or the other has backup peering, it would not look like > that. It would look like _3561_.*_174_ or _174_.*_3561_ - prolly the > former since AS3561 gives route-views a feed, but AS714 does not. > > Looking in route-views for those two patterns, I see only a few routes > under 3561.*_174_, probably leakage. There are no routes of the form > _174_.*_3561_. > > Since route-views does have a feed from AS3561, I would say it is > official. Cable and Wireless cannot reach PSI.net. > > Congratulations ladies & gentlemen. The first intentional, prolonged, > significant (for some values of "significant" :) outage on the > Internet. And we were all here to see it.... > > Wow, in the same week MAE-East dies. Sad time for the 'Net. :(( > > >-travis > > -- > TTFN, > patrick

3 2

Re: C&W Peering
by Sean Donelan 04 Jun '01

04 Jun '01

On Mon, 04 June 2001, Simon Lockhart wrote: > Well, I assumed PSI and/or C&W would have had some backup transit, if they > were going to play that game, but... > By defintion a "tier 1" provider does not have any transit, backup or otherwise. If tier 1 providers terminate peering, there are no alternate routes between them. However, customers who are multihomed may be able to reach both of them. Likewise customers of other peers can reach both of them. But customers exclusively connected to one or the other battling peer can't reach customers exclusively attached to the other. Its been a while since we've had a real "tier 1" peering battle. Last time ANS lasted a couple of weeks before they caved in and joined the CIX after the CIX filtered out non-member routes.

1 0

Re: 95th Percentile again (was RE: C&W Peering Problem?)
by Richard A. Steenbergen 04 Jun '01

04 Jun '01

On Sun, Jun 03, 2001 at 10:48:11PM -0400, Jim Mercer wrote: > > On Sun, Jun 03, 2001 at 01:34:08PM -0400, Alex Rubenstein wrote: > > > most of my customers are ethernet connected, and some customers share > > > an interface. i got into this before it was cheap to do 802.11q > > > switching, so my billing system needed to deal with multiple customers > > > on a single ethernet. > > > > Thats irrelevant; look at the counters on the customers switch-port. > > Doesn't matter what VLAN (or none) they are on. > > ah, well, again, i was using multiport bsd implementations, not > switches. > > as it stands, i'm fairly content using the cache flow from the > cisco's. > > one day, i might actually install a full 802.11q compliant switching > framework, but, well, not today. Come on, even D-Link is making switches with 802.1q... http://www.dlink.com/products/switches/des6000/ Go search your couch for loose change. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

Next NANOG meeting
by Susan Harris 04 Jun '01

04 Jun '01

Hi everyone - I'm pleased to announce that the next NANOG meeting will be held October 21-23 in Oakland CA, and will be hosted by Cisco. You'll find more information in the NANOG23 Call for Presentations: http://www.nanog.org/mtg-0110/call23.html http://www.nanog.org/mtg-0110/call23.pdf Registration begins in early August. See you this fall! --Susan Harris

1 0

95th Percentile again (was RE: C&W Peering Problem?)
by Richard A. Steenbergen 04 Jun '01

04 Jun '01

On Sat, Jun 02, 2001 at 05:19:16PM -0500, Albert Meyer wrote: > > I almost got caught by this one a few months ago. I was fixing to sign > a contract with Exodus for a 100bT circuit when I noticed some > funny-looking language and asked some probing questions, and then > realized that I had to double their quoted rates before comparing them > to everyone else. This moved them from the front of the pack back to > UU-land. > > UUNet is another story. They not only charge significantly more than > everyone else, but they calculate 95th percentile on the higher of > incoming and outgoing rather than the average. When I asked my > salesperson why she couldn't give me a competitive rate, she said > "Because we're UUNet." She seemed pretty taken aback when I explained Exodus is the worst on billing bit for bit. The way I read the Exodus 95th percentile document (though I still havn't gotten it confirmed by a person who actually knew what they were talking about), they bill for the MAXIMIUM 95th percentile, on both inbound AND outbound. UUNet bills for the MAXIMIUM 95th percentile on inbound OR outbound, whichever is higher, as does AboveNet, and probably the majority of networks trying to be like UUNet. But a significant portion of other networks will bill for the AVERAGE under the 95th percentile. I think the MAXIMIUM is unclear to a lot of people, especially the sales people if you try to get a straight answer out of them. When most people refer to the UUNet "95th percentile", this is what they mean. You take traffic samples, line them up in order, lop off the top 5%, and whatever the number is for the sample right under that is what gets multiplied by the cost per mbit. This means that if you push 1Mbps for 25 days and 10Mbps for 5 days you will pay 10 * $$$ per mbit. Average means you will pay 2.5 * $$$ per mbit (((1 * 25) + (10 * 5)) / 30), obviously a major difference. A LOT of sales people are misleading or utterly clueless about this, and a lot of providers actually WILL bill you for the AVERAGE under the 95th percentile (though if you think about it the 95th percentile makes little sense if you average it, it was designed to extract the maximium amount of money while not making people utterly afraid to burst higher). Moral of the story, check for those words "AND" vs "OR", and "MAXIMIUM" vs "AVERAGE", ask for their boss and check it again, and then get it in writing. :P -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

18 55

RE: engineering --> ddos and flooding
by Matt Zito 04 Jun '01

04 Jun '01

> -----Original Message----- > From: Richard A. Steenbergen [mailto:ras@e-gerbil.net] > Sent: Monday, June 04, 2001 3:09 PM > To: Matt Zito > Cc: Paul Johnson; nanog(a)merit.edu > Subject: RE: engineering --> ddos and flooding > > Rate-limiting ICMP is not so difficult - rate-limiting SYNs is > > basically useless. Syn floods work not because the amount > of traffic > > they do, but because they fill up state tables or make them so > > horribly inefficient as to make the box cease responding on > that port. > > Given that, say, a linux box has a default queue depth of 128, I can > > send 128 spoofed SYNs at a rate of one a second, and in two minutes > > that box will stop responding. The larger you make the queue, the > > longer it will stand up to a slow SYN attack, but the more > costly each > > incoming SYN and SYN+ACK becomes, as the data structures become more > > and more unwieldy. > > Wrong, and very much out of date. > > I didn't write all this down to waste my breath... > > http://www.e-gerbil.net/ras/projects/dos/dos.txt > Well, what I said is inaccurate for SOME operating systems. A default linux box today still has a 128-syn queue. Unless you enable syn cookies, you're screwed - I haven't checked BSD or Solaris for slow-syn behavior recently. Syn cookies also aren't a magic bullet - you lose TCP options that some people really want/need. And rate-limiting SYN is still a bad idea - if you rate-limit to a certain bandwidth, either your server will not be able to handle the incoming syns and will stop responding, or legitimate incoming traffic will hit the floor because the queue on the router is full (or approaching full and RED is invoked) and legitimate incoming requests will be dropped. This might be okay for places where one server performs many functions - i.e. the box is still available on other ports, but in larger infrastructures, a box generally has one purpose, and if its purposed port is down, the box might as well be turned off. So, I prefer solutions that negotiate the connection before passing it back to the host - like (insert basically any firewall product here). Some do it better than others, of course - the netscreen 100, 500, and 1000 seem much better than anything else the field has to offer. Thanks, Matt

2 1

C&W Peering
by Moe Allen 04 Jun '01

04 Jun '01

Affective this morning Cable & Wireless started de-peering with PSINET. More when I receive a reply from: peering.admin(a)cwusa.com Morris Allen VidcomNet, Inc.

1 0

Re: engineering --> ddos and flooding
by Paul Johnson 04 Jun '01

04 Jun '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry but IMESHO null routing a /32 during a DoS attacck doesn't exactly strike me as engineering. It is more like dealing with the attack in real-time. To mean engineering would mean desinging networks to be resistant to DDoS and flooding in the first plsce. To that end no NSP should ever allow spoofed IP addresses outside of their network. (not just RFC 1918 addresses but valid IPs that don't belong to that NSP) e.e if I'm have a circut from C&W nd I try to spoof a packet eith a source address of 216.35.172.135 it should be dropped as close to the edge of C&W's network as possible. note on RFC 1918 addresses: These should never get past customer edge routers IMESHO. Two NSPs should rate limit DoS traffic (ICMP & SYNs) within their networks in such a way that it can never DoS a T-1 (or E-1 if you are not in the US). [note: I'm not sure if ciso's are up for this workload since I primarily work with Juniper.] Three NSPs should lock down their gear so it can't be used for DoS amplification. I mean a clueless customer getting burned is one thing but we should expect & demand more from NSPs. [note: my primary responsiblity in life is security not networking.I know just enough networking to be dangerous and annoying to our Networking dept. :-) ] On Mon, 4 Jun 2001, Geoff Zinderdine wrote: > > Assuming not adding the extra connection, this means that upstream > > prefix filtering, so that one can't mistakenly inject 255 /24s > > rather than a single /16, would go out the window. Now think about > > /32s and what the routing tables will start to look like. Now > > onsider that the upstream would also want to send to its upstream > > Tier-1 the NULLROUTE /32 as well so that his bandwidth is not eaten > > up as well and we have asituation whereby routing table size will > > triple in size every year. > > This is a stop gap measure for customer networks. Those null routed > /32s are not meant to be permanently advertised, they are meant to > free the customer's pipe from smurf/fraggle until the SP can do > something about it. What would be the point of permanently > blackholing a host on your network? One more problem...what if your mail/web server is the target of the attack you have just taken that resource effectively off-line. No need to continue the DoS you've done the work of the attacker. > I would imagine that most tier 1's are going to filter anything longer > than a /24 whether you advertise it or not. The question isn't about > route table size, it is whether your SP will go the extra mile to give > you a proactive option to deal with attack and has someone clueful to > implement it that will take responsibility for it (not that it is > hard). > > This is a very limited measure that only helps in a very particular > situation for a small subset of customer networks. I think it is a > very useful tool for that particular situation... it is not meant as a > principle that SP networks should apply to their upstream as well. Paul Johnson Ratoath, Co. Meath Republic of Ireland - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: pgpenvelope - http://www.uiuc.edu/ph/www/ftobin/resources.html iD8DBQE7G7QUEn8vUhkIGTURAuuFAJ0Ub5lBQWG4r/WisSOTaOPNPm0/nACg8fY3 qcEayLo0vyDGlVDSFbWMKlE= =K9Xz - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: pgpenvelope - http://www.uiuc.edu/ph/www/ftobin/resources.html iD8DBQE7G7VeEn8vUhkIGTURAkd3AJ48V+C40i0noy+kij4xi470yly6WwCfT1UX o9Eq24paIFAJsSAU7JvuqNw= =D2SE -----END PGP SIGNATURE-----

4 3