January 2009 - Test - lists.nanog.org

Cogent Haiku v2.0
by neal rauhauser 14 Jan '09

14 Jan '09

Cogent makes a mess My phone rings and rings Unfornicate this!

21 30

Re: Which is more efficient?
by Josh Potter 14 Jan '09

14 Jan '09

What type of traffic are you looking at sending? As Scott said smaller payloads that need to be sent quickly work out well in fixed cells but larger payloads would be better off in variable sized packets. Also are you looking at simple data transmission rates or are you wanting to factor in hardware load, backplane load, cpu efficiency etc? On Wed, Jan 14, 2009 at 4:59 PM, Scott Berkman <scott.berkman(a)reignmaker.net > wrote: > Packets can have a max size as well based on the path MTU, such as 1500 > bytes in an Ethernet (10/100) link. I think there are a lot of other > variables here such as are you billed per data unit, bandwidth and control > factors on the links, and what type of data is being sent. > > If your data can always fit in a smaller N-byte cell, that can be quite > efficient since you have minimal overhead or wasted space and all the > benefits of the fixed length data unit from a processing standpoint. > > If you are constantly fragmenting and then having to reassemble data due > to the small cell size, you would be better off with a variable length > packet, especially when bandwidth is less in demand than processing power. > > -Scott > > -----Original Message----- > From: Murphy, Jay, DOH [mailto:Jay.Murphy@state.nm.us] > Sent: Wednesday, January 14, 2009 3:56 PM > To: nanog(a)nanog.org > Subject: Which is more efficient? > > > All, > > In your humble opinion, which transmission method is more efficient, > packet or cell? Granted a cell is a fixed length packet and an IP packet > is variable length....would this necessarily only relate to a specific > protocol, namely, cell in ATM, and IP in Ethernet or other types of > domains....feedback highly welcomed. Trying to make a decision on the > transport mode for cost, delay, jitter, ROI, etcetera. > > > Jay Murphy > IP Network Specialist > NM Department of Health > ITSD - IP Network Operations > Santa Fé, New México 87502 > Bus. Ph.: 505.827.2851 > > "We move the information that moves your world." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Confidentiality Notice: This e-mail, including all attachments is for the > sole use of the intended recipient(s) and may contain confidential and > privileged information. Any unauthorized review, use, disclosure or > distribution is prohibited unless specifically provided under the New > Mexico Inspection of Public Records Act. If you are not the intended > recipient, please contact the sender and destroy all copies of this > message. -- This email has been scanned by the Sybari - Antigen Email > System. > > > > > -- Josh Potter

1 0

Anyone notice strange announcements for 174.128.31.0/24
by Michienne Dixon 14 Jan '09

14 Jan '09

I'm not entirely certain what is going on but has anyone noticed some strange announcements for 174.128.31.0/24? I received a hijack notice that my AS (AS11708) was announcing the above IP range. I verified that I was not when I started noticing some strange announcements for that range. Around 10 Am CST AS11911 was announcing it (AS_PATH: 1239 2914 3130 11911) then around 11:30 AM CST I observed AS12083 announcing it (AS_PATH: 1239 2914 3130 12083). Interestingly enough, ARIN indicates this is a part of range they have assigned for reachability testing. http://ws.arin.net/whois/?queryinput=174.128.31.0 This was from this AM around 10 AM CST: telnet@MLX4AP3#sho ip bgp route 174.128.31.0/24 Number of BGP Routes matching display condition : 1 Prefix Next Hop Metric LocPrf Weight Status 1 174.128.31.0/24 160.81.151.109 88 200 100 BE AS_PATH: 1239 2914 3130 11911 Last update to IP routing table: 2h24m33s, 1 path(s) installed: This was from this AM around 11:30 AM CST: Number of BGP Routes matching display condition : 1 Prefix Next Hop Metric LocPrf Weight Status 1 174.128.31.0/24 160.81.151.109 88 200 100 BE AS_PATH: 1239 2914 3130 12083 Last update to IP routing table: 0h0m43s, 1 path(s) installed: - Michienne Dixon liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990

30 67

flattengraph.pl
by Gregory Edigarov 14 Jan '09

14 Jan '09

Hello, I have some problems with peaks on my mrtg, therefore I went to list archives on mrtg,org, and saw what's available. Then I found out that there is some script called flattengraph.pl, which I believe could help me with the situation. However this program is not available anymore and I cannot find and download it anywhere. So if some good soul will give me a link, or send me the file, I will be really grateful. Thanks a lot in advance. -- With best regards, Gregory Edigarov

3 4

Re: Approach to allocating netblocks
by Aidan Whyte 14 Jan '09

14 Jan '09

I guess it might depend on the general profile of your customers' requirements, but I'd imagine that non-contiguous blocks will be far more efficient in the long run, with the added benefit of no need for customers to pursue a renumbering plan every N years which should nearly always be avoided in any case imho. Obviously, the smaller the average block size the less efficient it becomes. If the customers are honest in their expected future ip address requirements it shouldn't be that often that they'll need more address space in any case. Aidan 2009/1/14 Frank Bulk <frnkblk(a)iname.com>: > Secondary IPs, additional documentation and confusion, and less efficient > use of address space, are just a few negatives of assigning more netblocks. > > Frank > > -----Original Message----- > From: Aidan Whyte [mailto:aidanwhyte@gmail.com] > Sent: Wednesday, January 14, 2009 10:35 AM > To: frnkblk(a)iname.com > Subject: Re: Approach to allocating netblocks > > Perhaps I'm missing something, but I've never seen much of a problem > with non-contiguous blocks for customer address space expansion..

1 0

orphan kit?
by bmanning＠vacation.karoshi.com 14 Jan '09

14 Jan '09

Nortel board of directors vote to file bankruptcy http://www.nortel.com/corporate/restructuring.html

1 0

Are you getting Spam from Crossfire Media?
by JC Dill 14 Jan '09

14 Jan '09

4 weeks ago I started getting weekly spam from Carl(a)crossfiremedia.com. I have been "subscribed" to this newsletter. Today's spam subject line is "Get to 4GWE and Participate in the Wireless Future, We'll help pay your way..." The address used is an address I used on NANOG some years back - I haven't used it in quite a while but still get an occasional private email from someone who has that address in their address book so the address is still active. Because there's a remote chance that some time long ago I "subscribed" to some message board and hidden in the message board settings is a pre-checked option (which I overlooked) to receive email from "partners", I privately emailed several friends in the IT/Security fields asking if they were getting this spam. The one friend who is also getting this spam is also someone who occasionally posts to NANOG, and who also has no idea why he was "subscribed" to this spam. Because of this coincidence, I think the spammer may have scarfed email addresses of people who posted to NANOG and added them to the "targeted" mailing list / spam list. I'm curious to know if other NANOG subscribers have started receiving spam from this person. I also found 2 sites that have web interfaces to their NANOG archives where they are not obscuring email addresses and who leaked posting addresses onto the web: http://www.google.com/search?q=lists05%40equinephotoart.com+nanog Is there someone at NANOG who can ask these sites to remove these archives, or at least purge/munge email addresses? Please reply via private email. Thanks! jc

8 10

Trouble reaching plaxo.com?
by S. Ryan 14 Jan '09

14 Jan '09

Anyone else having trouble reaching plaxo.com? Nothing urgent. I can't seem to get there via Level 3 or via 360 Networks. Both die around here: 10 23 ms 21 ms 23 ms te3-2-928.core1.mpt.layer42.net [69.36.239.137] Here is a traceroute from 360: [id:~]$ traceroute 204.15.240.72 traceroute to 204.15.240.72 (204.15.240.72), 64 hops max, 44 byte packets 1 unused (x) 1.114 ms 1.258 ms 1.100 ms 2 core1-e3-1 (x) 0.882 ms 0.920 ms 0.943 ms 3 66.62.136.85 (66.62.136.85) 10.859 ms 10.284 ms 10.291 ms 4 pdx1-core-02.360.net (66.62.4.130) 12.702 ms 11.984 ms 11.078 ms 5 lax1-core-01.360.net (66.62.3.68) 33.333 ms 35.922 ms 34.513 ms 6 lax1-edge-01.360.net (66.62.5.131) 33.728 ms 33.910 ms 33.403 ms 7 laiix.layer42.net (198.32.146.22) 62.471 ms 36.545 ms 51.932 ms 8 g6-21-103.core2.eqx.layer42.net (69.36.239.105) 44.008 ms 43.264 ms 43.218 ms 9 te3-2-928.core1.mpt.layer42.net (69.36.239.137) 43.943 ms 44.153 ms 50.836 ms Thanks for any insight, Steve

8 7

QWEST IP NOC Help Needed
by James Laszko 14 Jan '09

14 Jan '09

We have just received notice that an old allocation from QWEST that was provided to our company in the early 2000's has been redirected from our current connectivity company. We had procured the homing of our IP space to our existing provider, but they recently terminated their relationship with QWEST. QWEST has since started announcing our address space, blackholing us. We've got a tremendous amount of customers and legacy equipment in that space and need someone from QWEST to please contact us to try and resolve this issue. The netblock in question is 65.126.208.0/22 Can a QWEST IP NOC Supervisor or someone else who can help me please contact me ASAP? Thank you, James Laszko Pipeline Communications james(a)pcipros.com 951-541-9688 x 1030 760-807-5129 cell

2 1

Lastweek Reminder: CFP - NetWare 2009 [SENSORCOMM, SECURWARE, DEPEND, AFIN, MESH] / Athens-Vouliagmeni]
by Jaime Lloret Mauri 13 Jan '09

13 Jan '09

INVITATION Please consider to contribute and encourage your team members and fellow scientists to contribute to the following federated events. Thanks for forwarding the information on this Call for Submissions to those potentially interested to submit. ===== Call for Submissions ======= NetWare 2009, June 18-23, 2009 - Athens/Vouliagmeni, Greece see: http://www.iaria.org/conferences2009/NetWare09.html NetWare 2009 is a federated event focusing on advances topics concerning the areas of sensors, security, mesh, dependability and future Internet. NetWare 2009 continues the tradition of well-established conferences SENSORCOMM, SECURWARE, MESH and DEPEND and adds new trends on advances in Future Internet (AFIN). Submission (full paper) deadline: January 20, 2009. Submissions must be electronically done using the �Submit a Paper� button on the entry page of each conference. For details on the each conference's topics, see the individual Call for Papers for each conference. Unpublished high quality contributions in terms of Regular papers and Forum posters are welcome. Workshop proposals and Panel proposals on challenging topics are encouraged. Extended versions of selected papers will be published in IARIA on-line Journals (http://www.iariajournals.org) and in Special issues of different journals mentioned on the entry page of each conference. Submissions will be peer-reviewed, published by IEEE Computer Society Press, posted in IEEE Digital Library, and indexed via all the IEEE indexing agreements. All tracks/topics are open to both research and industry contributions. >> SENSORCOMM 2009, The Third International Conference on Sensor Technologies and Applications http://www.iaria.org/conferences2009/SENSORCOMM09.html >> SECURWARE 2009, The Third International Conference on Emerging Security Information, Systems and Technologies http://www.iaria.org/conferences2009/SECURWARE09.html >> AFIN 2009, The First International Conference on Advances in Future Internet http://www.iaria.org/conferences2009/AFIN09.html >> DEPEND 2009, The Second International Conference on Dependability http://www.iaria.org/conferences2009/DEPEND09.html >> MESH 2009, The Second International Conference on Advances in Mesh Networks http://www.iaria.org/conferences2009/MESH09.html -------------------------------- IARIA Publicity Board

1 0