- Test - lists.nanog.org

net-co-op (was Re: who offers cheap (personal) 1U colo?)
by Janet Sullivan 18 Mar '04

18 Mar '04

Based on the response I've gotten off-list from people interested in sharing our resources & know-how with each other, I've just registered net-co-op.org. In the next couple of days I'll set up a mailing list and a basic web page. Once the mailing list is set up, I'll post another message to NANOG. On the net-co-op mailing list we can hash out a basic charter agreement and get to know each other. More to come... Janet

5 5

Request response
by srh＠merit.edu 18 Mar '04

18 Mar '04

7 6

RE: Sprint Help
by Michel Py 18 Mar '04

18 Mar '04

> Leo Bicknell wrote > Your problem is right here: > 14 urish-pitts-gw.centrepc.net (67.97.250.166) 100 msec * > 100 msec NT in many configs defaults to a TCP Window size > of 8k, other NT and Server 2000 default to 16k. This seems premature as a conclusion to me. If they don't have issues with Japan where the best RTT they can get is around 130ms I don't see why 100ms would be an issue. Michel.

2 1

Re: Personal Co-location Registry
by Paul Vixie 18 Mar '04

18 Mar '04

> > i've already removed one that was seen on ROKSO (23 listings). > > i don't consider the lists you gave to be credible, but if any > > of the entries in the personal colo registry show up on ROKSO or > > SBL or MAPS or SORBS, you can bet i'll remove them instantly. > ... > Even if the COLO space might be on a totally different netblock? yup. > I mean, people dont post the netblocks they host on, a lookup on the > IP they send mail from could be totally different. if i think that a colo/hosting operator is segregating their abusive customers from their nonabusive customers in order to make money from both while only having the bad ones show up on various blackhole lists, then i'm likely to refuse to do business with them, and when i ran a public blackhole list i was likely to put ALL of their netblocks on it. (ymmv.)

1 0

Sprint Help
by Joe Marr 18 Mar '04

18 Mar '04

I was wondering if the wonderful members of this list could provide their opinions regarding the traceroute below. I have contacted sprint several times regarding this issue and their noc keeps coming back with "no trouble found". Am I barking up the wrong up the wrong tree? I'm experiencing packetloss and large amounts of delay at hop 8. Both of my T providers say they cant do anything to help me. C:\>tracert 67.97.251.18 Tracing route to 67.97.251.18 over a maximum of 30 hops 1 <10 ms <10 ms <10 ms 192.168.1.75 2 16 ms 15 ms 16 ms host-64-179-34-81.pit.choiceone.net [64.179.34.8 1] 3 15 ms 16 ms 15 ms atm6-5-992-pitb-isp-cisco.choiceone.net [64.65.2 10.101] 4 31 ms 31 ms 16 ms chi-edge-09.inet.qwest.net [63.149.3.229] 5 31 ms 16 ms 31 ms chi-core-03.inet.qwest.net [205.171.20.125] 6 15 ms 32 ms 31 ms chi-brdr-03.inet.qwest.net [205.171.20.142] 7 16 ms 31 ms 31 ms 205.171.1.162 8 297 ms 375 ms 94 ms sl-bb20-chi-4-0.sprintlink.net [144.232.8.219] 9 47 ms 47 ms 47 ms sl-browing-20-0.sprintlink.net [144.223.241.22] 10 47 ms 46 ms 63 ms ge-2-1-0.a1.chcg.broadwing.net [216.140.15.17] 11 47 ms 63 ms 47 ms so-0-1-0.c1.gnwd.broadwing.net [216.140.14.97] 12 47 ms 62 ms 47 ms so-2-0-0.c1.wash.broadwing.net [216.140.16.22] 13 47 ms 62 ms 63 ms p0-0-0.a1.wash.broadwing.net [216.140.8.13] 14 47 ms 63 ms 62 ms p8-0-0.e0.wash.broadwing.net [216.140.8.34] 15 141 ms 125 ms 141 ms 67.97.250.166 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 * * * Request timed out. 30 * * * Request timed out. Trace complete. C:\> Joe Marr ( <mailto:joe.marr@intektechnologies.com> joe.marr(a)intektechnologies.com) Sr. Technology Consultant Intek Technologies Phone: 1.570.322.1915 www.intektechnologies.com

3 3

Customers squeezed as ISPs close in on viruses
by Sean Donelan 18 Mar '04

18 Mar '04

By Jim Hu Staff Writer, CNET News.com High-speed Internet service providers are increasingly putting their customers in the security hot seat, as they try to fight recent virus attacks that turn computers into spam factories. [...] Still, the question remains whether the techniques broadband ISPs are implementing are enough. Some say the onus is on ISPs, which should play a role in protecting their networks for the greater good of their subscribers and the Internet at large. Critics say ISPs should manage their networks to ensure that all users are safe. http://news.com.com/2100-1038_3-5174061.html

2 1

Re: Personal Co-location Registry
by Paul Vixie 18 Mar '04

18 Mar '04

i've already removed one that was seen on ROKSO (23 listings). i don't consider the lists you gave to be credible, but if any of the entries in the personal colo registry show up on ROKSO or SBL or MAPS or SORBS, you can bet i'll remove them instantly. re: > SPEWS: 7 > BLARS: 5 > FIVE-TEN-SG: 2 > BLIAB: 2 > DSBL: 1

2 1

Juniper "pepsi"
by Eric Kuhnke 18 Mar '04

18 Mar '04

I have heard rumors of a new low-end 1U Juniper router, aimed directly at replacing the 2600/3600 series. Supposedly its code name is "Pepsi"... Does anyone have more info on this? :-)

3 2

Spamhaus Exposed
by Susan Harris 18 Mar '04

18 Mar '04

Folks, let's end this thread and the renamed "US Extradition rights" follow-up. They're politics, not operations.

1 0

RE: Sprint Help
by Michel Py 18 Mar '04

18 Mar '04

> Joe Marr wrote: > the only thing I can find wrong is packetloss and > latency between hops 7 and 8. It has nothing to do with your issue. The very fact that the next hops do not exhibit the same problem shows that the router is processing packets fine. This is not uncommon, might be caused by our old friend the BGP scanner process which has a higher priority than ICMP. There is no relation between pinging the router and the router processing packets correctly. And although Sprint might want to address it at some point it is absolutely none of your business as long as the router keeps processing traffic which it does. The "loss" you are referring to is no loss at all it's likely rate-limiting. Lots of people do something along these: rate-limit output access-group 100 16000 1500 2000 conform-action transmit exceed-action drop access-list 100 remark ------------------- access-list 100 remark acl for rate-limit. access-list 100 remark =------------------ access-list 100 permit icmp any any access-list 100 remark What you care is end-to-end traffic anyway. If that router did not respond to pings at all it would still process traffic which is the only thing you should care about. > but how do I go about tracking down this issue? > None of their other offices have this problem. By hiring a professional. Comparing msec sniffer traces between the server, a site that works and the site that has problems would be a good beginning. Getting meaningful conclusions out of them requires a certain level of skill though; I hope you'll forgive my bluntness but if you can't analyze the fact that the traceroute is not the tool you need you are nowhere near where you need to be in order to look at sniffer deltas. Michel.

1 0