- Test - lists.nanog.org

Alternative in Web Hosting ?
by Gawie Marais (Home) 04 Nov '02

04 Nov '02

I know that this list would not quite cover my topic, but please excuse me... We are a small ISP company based in South Africa and I am looking at alternative ISP's in several other countries around the world to provide our clients with International hosting solutions for their customer base abroad. For the time being, I think we are looking at America & Europe. Could someone suggest alternative ISP's where we could host our client's existing web sites (as a mirror) ? Thank You, Gawie J Marais Technical Member inX - Internet eXchange SA Tel: +27 11 956 6935 Fax: +27 11 956 6851 Mail: gawie(a)inx.co.za Web: http://www.inx.co.za/

2 1

ISDN tip wanted
by Andre Chapuis 04 Nov '02

04 Nov '02

Hi, I'm trying to establish an ISDN call between Switzerland and New-York. The destination is in New-York, ISDN line provided by Verizon. The called is disconnected just after being set up (see NY-router log below), and the problem seems to be that Verizon switch does not understand the callref flag (0x01 and 0x81) correctly. The funny thing is that i have another router in NY, another ISDN line from Verizon, and i'm calling from the same number in CH and it works perfectly... Does anyone have a hint for me ? Thanks André Oct 31 14:23:56.350 MET: ISDN BR0/0: RX <- SETUP pd = 8 callref = 0x01 Oct 31 14:23:56.350 MET: Bearer Capability i = 0x8890 Oct 31 14:23:56.350 MET: Channel ID i = 0x89 Oct 31 14:23:56.350 MET: Signal i = 0x40 - Alerting on - pattern 0 Oct 31 14:23:56.350 MET: Calling Party Number i = 0x1183, '<calling number removed>' Oct 31 14:23:56.354 MET: Called Party Number i = 0xC1, '<called number removed>' Oct 31 14:23:56.354 MET: Locking Shift to Codeset 5 Oct 31 14:23:56.354 MET: Codeset 5 IE 0x2A i = 0x808B0B, '<calling number removed>', 0x800109800114800114800114 Oct 31 14:23:56.358 MET: ISDN BR0/0: Incoming call id = 0x9E, dsl 0 Oct 31 14:23:56.358 MET: ISDN BR0/0: received HOST_INCOMING_CALL call_id 0x9E Oct 31 14:23:56.358 MET: ISDN BR0/0: HOST_INCOMING_CALL: voice_answer_data = FALSE Oct 31 14:23:56.358 MET: ISDN BR0/0: Event: Received a DATA call from <calling number removed> on B1 at 64 Kb/s Oct 31 14:23:56.358 MET: ISDN BR0/0: RM returned call_type 0 resource type 0 Oct 31 14:23:56.362 MET: ISDN BR0/0: TX -> CALL_PROC pd = 8 callref = 0x81 Oct 31 14:23:56.362 MET: Channel ID i = 0x89 Oct 31 14:23:56.362 MET: ISDN BR0/0: isdn_send_connect(): msg 4, call id 0x9E, ces 1 bchan 0, call type DATA Oct 31 14:23:56.366 MET: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to up Oct 31 14:23:56.370 MET: %ISDN-6-CONNECT: Interface BRI0/0:1 is now connected to <calling number removed> Oct 31 14:23:56.462 MET: ISDN BR0/0: RX <- RELEASE_COMP pd = 8 callref = 0x01 Oct 31 14:23:56.462 MET: Cause i = 0x82D1 - Invalid call reference value Oct 31 14:23:56.466 MET: ISDN BR0/0: received HOST_DISCONNECT_ACK call_id 0x9E Oct 31 14:23:56.466 MET: ISDN BR0/0: HOST_DISCONNECT_ACK: call type is DATA Oct 31 14:23:56.466 MET: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to down Oct 31 14:23:56.666 MET: CC: dsl 0 No CCB Src->HOST cid 0x9E, ev 0x4 ces 1 Oct 31 14:23:56.666 MET: ISDN BR0/0: received HOST_QUERY_RESPONSE call_id 0x9E --------------------- Andre Chapuis IP+ Engineering Swisscom Ltd Genfergasse 14 3050 Bern +41 31 893 89 61 chapuis(a)ip-plus.net CCIE #6023 ----------------------

9 11

UUnet West Coast glitch?
by Steve Francis 03 Nov '02

03 Nov '02

We just saw RTT times to a bunch of sites (yale, ucsb, cisco, yahoo, mci) all go up to 3 second RTT with lots of loss. The one traceroute I did before it corrected itself showed long delays once traceroute entered UUnet - but could be the return path. (This was from an Internap colo site, so there is often assymetry.) I saw the same delays out of another TimeWarner connected site... Anyone else know what was going on? trace www.mci.com Translating "www.mci.com"...domain server (63.251.224.9) [OK] Type escape sequence to abort. Tracing the route to mci.com (199.249.20.30) 1 border5.fe5-3.expertcity-4.sfo.pnap.net (63.251.61.117) [AS 14743] 4 msec 0 msec 4 msec 2 core2.ge2-0-bbnet2.sfo.pnap.net (63.251.63.66) [AS 14743] 120 msec 0 msec 0 msec 3 gige4-0-233.ipcolo1.SanFrancisco1.Level3.net (63.211.143.17) [AS 3356] 4 mse c 8 msec * 4 gigabitethernet4-2.core2.SanFrancisco1.Level3.net (209.244.14.225) [AS 3356] 4 msec 4 msec * 5 100.ATM2-0.BR5.SAC1.ALTER.NET (166.90.50.134) [AS 3356] 2536 msec 2536 msec 2532 msec 6 0.so-2-1-0.XL1.SAC1.ALTER.NET (152.63.52.226) [AS 701] 2676 msec

2 1

Re: no ip forged-source-address
by Bob Martinez 03 Nov '02

03 Nov '02

Richard: >Just my $0.02, May not be enough money. You present a solution to an unclearly defined problem. Never fear, the IETF has a packet sampling working group now, but one vendor has RFC3176 sFlow today (yesterday). I've got sFlow running on 1GbE links today and I'm planning on a 10GbE upgrade next year with sFlow support for the core. Same product I bought 2 years ago. http://www.sflow.org/participants.htm List is growing. You can't make decisions about your network if you don't really know your network. An sFlow collector will give you accounting and monitoring to take any action you so desire to fix your problems in real time. Can't wait until this WG produces a standards based product though. IPFIX was started after sFlow. IPFIX is short of the mark for L2 networks. A very happy sFlow (www.ietf.org/rfc/rfc3176.txt) user... Bobby _________________________________________________________________ Internet access plans that fit your lifestyle -- join MSN. http://resourcecenter.msn.com/access/plans/default.asp

1 0

RE: Provider feedback Aleron=BAD!
by Tech Team1 03 Nov '02

03 Nov '02

David, We had a circuit through AGIS, who was bought by Telia, who was then bought by Aleron. Their billing practices were utterly terrible. Several months after Aleron aquired the network they informed us that we would now be billed an additional $250/month per /24 that we had with them! Since we had about 16 /24s (well utilized) this was going to effectively multiply our monthly bill by several hundred percent! When I called to clarify (ie. "You're telling me that we must pay almost $1 per month per IP address?!") they basically said "yup, take it or leave it." We left it.. They're still chasing us for the money that we supposedly owe them. The renumbering was hell, but we switched to UUnet. Slightly more expensive, but good service and no crazy extortion attempts! --Dan > > > I am considering using Aleron (http://www.aleron.com/network) as an > internet service provider and wondering if anyone has an opinion on > their network, service or it's support. > > You can contact me off-list if you like. > > David A. Lauer > Network Engineer > Tristar Communications > dalauer(a)tristarcorp.net > > > > >

4 4

FBI: US and Korea source of DNS attacks
by Sean Donelan 01 Nov '02

01 Nov '02

Looks like the Feds are making progress. http://www.idg.net/ic_961320_1794_9-10000.html "The distributed denial of service (DDOS) attacks against 13 of the Internet's core servers has been traced to computers in the U.S. and Korea, according to statements made by U.S. Federal Bureau of Investigation (FBI) director Robert Mueller."

1 0

Re: no ip forged-source-address
by Daniel Senie 01 Nov '02

01 Nov '02

At 10:44 AM 10/30/2002, variable(a)ednet.co.uk wrote: >Hi, > >I've been following the discussion on DDoS attacks over the last few weeks >and our network has also recently been the target of a sustained DDoS >attack. I'm not alone in believing that source address filters are the >simplest way to prevent the types of DDoS traffic that we have all been >seeing with increasing regularity. Reading the comments on this list have >lead me to believe that there is a lot of inertia involved in applying >what appears to me as very simple filters. > >As with the smurf attacks a few years ago, best practice documents and >RFC's don't appear to be effective. BCP 38 is quite explicit in the need for all networks to do their part. The document is quite effective provided there's cooperation. > I realise that configuring and >applying a source address filter is trivial, but not enough network admins >seem to be taking the time to lock this down. If the equipment had >sensible defaults (with the option to bypass them if required), then >perhaps this would be less of an issue. > >Therefore, would it be a reasonable suggestion to ask router vendors to >source address filtering in as an option[1] on the interface and then move >it to being the default setting[2] after a period of time? This appeared >to have some success with reducing the number of networks that forwarded >broadcast packets (as with "no ip directed-broadcast"). So you're suggesting the router vendors provide default configurations which the ISPs will overwrite with their current configurations anyway? Which interface would you filter on? If we're talking about a router at the customer premesis, the filters should be on the link to the ISP (the customer may well have more subnets internally). At the ISP end, doing the filtering you suggest would not work, since it'd permit only the IP addresses of the link between the customer and user. For dialups, such filtering can and should be done, and should be automatic in the NAS boxes. But the #1 question I have to ask you is, how are you going to have any more luck enforcing ingress filtering with what you propose, than what we have in the BCP on the subject? If the government or other large buyers require network-wide ingress filtering in any supplier they buy from (something I suggested to the folks at eBay, Schwab, etc. in our phone calls after the attacks a few years ago), or if there were legal incentive, there might be a chance ISPs would find a financial motive to implement BCP 38. As it is, there's no incentive, so the path of least resistance is to do nothing.

4 4

RE: ICANN Targets DDoS Attacks
by H. Michael Smith, Jr. 01 Nov '02

01 Nov '02

Source address verification at access layer and rate limiting icmp would be fine starts. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of fingers Sent: Tuesday, October 29, 2002 1:12 AM To: nanog(a)merit.edu Subject: Re: ICANN Targets DDoS Attacks > "Meanwhile, U.S. government security officials are discussing the > possibility of creating new regulations that would require federal > agencies to buy Internet service only from ISPs that have DDoS protection > on their networks, according to people familiar with the situation. Such > a decision could place economic pressure on the other ISPs to follow suit, > thereby improving Internet security." just how would an isp stamp themselves with the "DDoS protected" rubber stamp? I'm just curious as to what the next sales person is going to request as a product/service they're going to want to charge customers for. best practices like filtering != DDoS protection imho

10 14

The Cidr Report
by cidr-report＠potaroo.net 01 Nov '02

01 Nov '02

This report has been generated at Fri Nov 1 21:44:58 2002 AEST. The report analyses the BGP Routing Table of an AS4637 (Reach) router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/as4637 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 25-10-02 114752 82664 26-10-02 115193 82582 26-10-02 115135 82541 28-10-02 115001 82653 29-10-02 115335 82760 30-10-02 115374 82790 31-10-02 115340 82890 01-11-02 115442 82880 AS Summary 13957 Number of ASes in routing system 5465 Number of ASes announcing only one prefix 1748 Largest number of prefixes announced by an AS AS701 : ALTERNET-AS UUNET Technologies, Inc. 73146368 Largest address span announced by an AS (/32s) AS568 : SUMNET-AS DISO-UNRRA Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 01Nov02 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 115457 82891 32566 28.2% All ASes AS3908 1076 564 512 47.6% SUPERNETASBLK SuperNet, Inc. AS701 1748 1265 483 27.6% ALTERNET-AS UUNET Technologies, Inc. AS7843 782 330 452 57.8% ADELPHIA-AS Adelphia Corp. AS2828 487 112 375 77.0% XO-AS15 XO Communications AS6197 457 100 357 78.1% BATI-ATL BellSouth Network Solutions, Inc AS7018 1344 993 351 26.1% ATT-INTERNET4 AT&T WorldNet Services AS4323 516 181 335 64.9% TW-COMM Time Warner Communications, Inc. AS18566 337 4 333 98.8% COVAD Covad Communications AS1221 1196 873 323 27.0% ASN-TELSTRA Telstra Pty Ltd AS209 629 336 293 46.6% ASN-QWEST Qwest AS7046 585 299 286 48.9% UUNET-CUSTOMER UUNET Technologies, Inc. AS6347 354 82 272 76.8% DIAMOND SAVVIS Communications Corporation AS4355 388 127 261 67.3% ERMS-EARTHLNK EARTHLINK, INC AS4151 330 89 241 73.0% USDA-1 USDA AS705 441 202 239 54.2% ASN-ALTERNET UUNET Technologies, Inc. AS1239 887 662 225 25.4% SPRINTLINK Sprint AS6198 403 180 223 55.3% BATI-MIA BellSouth Network Solutions, Inc AS852 689 467 222 32.2% ASN852 Telus Advanced Communications AS1 655 437 218 33.3% GNTY-1 Genuity AS4814 233 15 218 93.6% CHINANET-BEIJING-AP China Telecom (Group)Beijing Telecom CompanyBeijing China AS7132 281 71 210 74.7% SBIS-AS Southwestern Bell Internet Services AS6140 263 65 198 75.3% IMPSAT-USA ImpSat USA, Inc. AS17557 320 122 198 61.9% PKTELECOM-AS-AP APNIC ASN block AS22927 216 20 196 90.7% AR-TEAR2-LACNIC TELEFONICA DE ARGENTINA AS6595 248 57 191 77.0% DODDSEUR DoD Education Activity Network Assistance Center AS17676 226 35 191 84.5% GIGAINFRA APNIC ASN block AS690 517 331 186 36.0% MERIT-AS-27 Merit Network Inc. AS4134 296 114 182 61.5% ERX-CHINALINK Data Communications Bureau AS2048 265 88 177 66.8% LANET-1 State of Louisiana AS2548 403 244 159 39.5% ICIX-MD-AS Business Internet, Inc. Total 16572 8465 8107 48.9% Top 30 total Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)lists.apnic.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0

RE: ISDN tip wanted
by Andre Chapuis 01 Nov '02

01 Nov '02

Hi Eric/All, Thanks for the various feedback. Actually the line is working now, although Verizon told me they did not change anything. They even told me the problem is: the line is not ISDN but POTS .... Anyway it's working and it reminds me the joke below Have a nice WE André --------------------------------------------------------------------- Theory: Nothing is working but everybody knows why Practice: Everything is working but nobody knows why Here we combine both: Nothing is working and nobody knows why --------------------------------------------------------------------- At 10:18 31.10.2002 -0600, Knudson, Eric wrote: >Andre, > >The call is being disconnected from the local switch because of an 'Invalid call reference value.' This would be the callref field in the various q931 messages. As you can see, the switch references this as '0x01,' while the router references it as '0x81.' It involves flipping a bit when we reference the same call that changes the value by 8 in hex. From the debugs, it looks like the router is doing the right thing, but the switch doesn't like the value. I'd ask the Verizon switch tech to identify what's wrong with that callref, or put your know good router onto this circuit to see if it exhibits the same behavior. > >Eric > > >-----Original Message----- >From: Andre Chapuis [mailto:chapuis@ip-plus.net] >Sent: Thursday, October 31, 2002 7:58 AM >To: nanog(a)nanog.org >Subject: ISDN tip wanted > > > >Hi, >I'm trying to establish an ISDN call between Switzerland and New-York. The destination is in New-York, ISDN line provided by Verizon. The called is disconnected just after being set up (see NY-router log below), and the problem seems to be that Verizon switch does not understand the callref flag (0x01 and 0x81) correctly. > >The funny thing is that i have another router in NY, another ISDN line from Verizon, and i'm calling from the same number in CH and it works perfectly... > >Does anyone have a hint for me ? >Thanks >André > >Oct 31 14:23:56.350 MET: ISDN BR0/0: RX <- SETUP pd = 8 callref = 0x01 >Oct 31 14:23:56.350 MET: Bearer Capability i = 0x8890 >Oct 31 14:23:56.350 MET: Channel ID i = 0x89 >Oct 31 14:23:56.350 MET: Signal i = 0x40 - Alerting on - pattern 0 >Oct 31 14:23:56.350 MET: Calling Party Number i = 0x1183, '<calling number removed>' >Oct 31 14:23:56.354 MET: Called Party Number i = 0xC1, '<called number removed>' >Oct 31 14:23:56.354 MET: Locking Shift to Codeset 5 >Oct 31 14:23:56.354 MET: Codeset 5 IE 0x2A i = 0x808B0B, '<calling number removed>', 0x800109800114800114800114 >Oct 31 14:23:56.358 MET: ISDN BR0/0: Incoming call id = 0x9E, dsl 0 >Oct 31 14:23:56.358 MET: ISDN BR0/0: received HOST_INCOMING_CALL call_id 0x9E >Oct 31 14:23:56.358 MET: ISDN BR0/0: HOST_INCOMING_CALL: voice_answer_data = FALSE >Oct 31 14:23:56.358 MET: ISDN BR0/0: Event: Received a DATA call from <calling number removed> on B1 at 64 Kb/s >Oct 31 14:23:56.358 MET: ISDN BR0/0: RM returned call_type 0 resource type 0 >Oct 31 14:23:56.362 MET: ISDN BR0/0: TX -> CALL_PROC pd = 8 callref = 0x81 >Oct 31 14:23:56.362 MET: Channel ID i = 0x89 >Oct 31 14:23:56.362 MET: ISDN BR0/0: isdn_send_connect(): msg 4, call id 0x9E, ces 1 bchan 0, call type DATA >Oct 31 14:23:56.366 MET: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to up >Oct 31 14:23:56.370 MET: %ISDN-6-CONNECT: Interface BRI0/0:1 is now connected to <calling number removed> >Oct 31 14:23:56.462 MET: ISDN BR0/0: RX <- RELEASE_COMP pd = 8 callref = 0x01 >Oct 31 14:23:56.462 MET: Cause i = 0x82D1 - Invalid call reference value >Oct 31 14:23:56.466 MET: ISDN BR0/0: received HOST_DISCONNECT_ACK call_id 0x9E >Oct 31 14:23:56.466 MET: ISDN BR0/0: HOST_DISCONNECT_ACK: call type is DATA >Oct 31 14:23:56.466 MET: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to down >Oct 31 14:23:56.666 MET: CC: dsl 0 No CCB Src->HOST cid 0x9E, ev 0x4 ces 1 >Oct 31 14:23:56.666 MET: ISDN BR0/0: received HOST_QUERY_RESPONSE call_id 0x9E > > >--------------------- >Andre Chapuis >IP+ Engineering >Swisscom Ltd >Genfergasse 14 >3050 Bern >+41 31 893 89 61 >chapuis(a)ip-plus.net >CCIE #6023 >---------------------- --------------------- Andre Chapuis IP+ Engineering Swisscom Ltd Genfergasse 14 3050 Bern +41 31 893 89 61 chapuis(a)ip-plus.net CCIE #6023 ----------------------

1 0