July 2008 - NANOG - lists.nanog.org

Real person @ Speakeasy Abuse
by Tomas L. Byrnes 18 Jul '08

18 Jul '08

Please contact me off-list. Tomas L. Byrnes ByrneIT Phone (it will find me): 760.444.4727 Text Message: 7604023999(a)messaging.sprintpcs.com <mailto:7604023999@messaging.sprintpcs.com> e-mail: tomb(a)byrneit.net <mailto:tomb@byrneit.net> IM: MSN Messenger tomb(a)byrneit.net <mailto:tomb@byrneit.net> Skype: zwithapggb CONFIDENTIALITY NOTE: The information transmitted in this e-mail message is intended to be confidential and for the use of only the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that you are in possession of privileged information, also, you are hereby notified that any retention, dissemination, distribution or copy of this e-mail message is strictly prohibited. If you have received this e-mail in error, immediately notify us via return e-mail at the address above, & discard, remove, delete, & destroy any trace of it.

1 0

RE: Comcast issues anyone?
by Smith, Courtney 18 Jul '08

18 Jul '08

This issue has been resolved. Global Crossing corrected routing error in their network. Thank you for your patience. Courtney Smith Backbone Service Desk Comcast National Engineering & Technical Operations -----Original Message----- From: National Network Desk Sent: Thursday, July 17, 2008 11:20 PM To: 'nanog(a)nanog.org' Subject: RE: Comcast issues anyone? This issue has been resolved. Global Crossing corrected routing error in their network. Thank you for your patience. Courtney Smith Backbone Service Desk Comcast National Engineering & Technical Operations

1 0

Comcast issues anyone?
by Logan Rawlins 18 Jul '08

18 Jul '08

I have various customers complaining of comcast issues and from traces i've seen so far it looks to be isolated to comcast or their handoff to someone. Anyone else having these issues and can a comcast network engineer please contact me off list if possible thanks. Tracing route to [64.38.193.22] over a maximum of 30 hops: 1 15 ms 18 ms 17 ms 192.168.1.1 2 * * * Request timed out. 3 17 ms 9 ms 27 ms ge-1-7- ur01.seattle.wa.seattle.comcast.net [68.8 6.99.65] 4 11 ms 11 ms 23 ms te-8-4- ar01.burien.wa.seattle.comcast.net [68.86 .96.189] 5 17 ms 15 ms 21 ms 68.86.90.222 6 14 ms 31 ms 17 ms 68.86.90.221 7 28 ms 27 ms 46 ms pos-0-6-0-0- cr01.sacramento.ca.ibone.comcast.net [68.86.85.197] 8 32 ms 47 ms 42 ms pos-0-7-0-0- cr01.sacramento.ca.ibone.comcast.net [68.86.85.181] 9 40 ms * 48 ms te-1-1- pr01.11greatoaks.ca.ibone.comcast.net [68 .86.84.126] 10 109 ms 54 ms 154 ms 68.86.88.250 11 * * * Request timed out. 12 * * * Request timed out. 13 * * * Request timed out. 14 * * * Request timed out. -Logan

1 1

Re: Avg. Packet Size - Again?
by Scott Weeks 17 Jul '08

17 Jul '08

--- fred(a)cisco.com wrote: CAIDA has been doing a lot of that, at least in the past. Last I asked them, which was quite a while back, they said that O(35%) of traffic ----------------------------------------- On Production networks? And if so, what type? Eyeball networks? Content networks? etc. over long time periods. scott

1 0

Analysing traces for performance bottlenecks
by Sam Stickland 17 Jul '08

17 Jul '08

Hi, Are there any packages (or Wireshark options that I've missed) that can follow a TCP stream and determine the limiting factor on throughput. E.g Latency, packet loss, out of sequence packets, window size, or even just the senders rate onto the wire. I know how to analyse a trace by hand for performance issues, but it's relatively time consuming. Googling for variations on "Analyse TCP stream limit throughput" didn't find anything. Sam

8 9

AUTO: Robbie Woodley is out of the office (returning Mon 07/21/2008)
by Robbie_Woodley＠uttyler.edu 17 Jul '08

17 Jul '08

I am out of the office from Tue 07/15/2008 until Mon 07/21/2008. If you need immediate assistance please contact Tim Crouch at ext 7476 or Chris Green at ext 7190. Note: This is an automated response to your message RE: Managed, cheap, DC power switches sent on 7/17/2008 8:58:08 AM. This is the only notification you will receive while this person is away.

3 2

Announcement : publicly available LISP and shim6 implementations
by Olivier Bonaventure 16 Jul '08

16 Jul '08

Hello, During the last years, there have been many discussions about the scalability of the Internet architecture notably within the IRTF RRG. With IPv6, thanks to its huge addressing space, it is possible to design protocols and mechanisms that are more scalable and more powerful than with IPv4. A typical example is the multihoming problem. This problem occurs when a site is attached to several Internet Service providers. With IPv4, the classical solution is for the site to obtain one IPv4 prefix and advertise it by using BGP. This solution works and traffic engineering is possible, but unfortunately, it contributes to a significant growth of the BGP routing tables in the global Internet. With IPv6, the IETF decided to focus on a host-based technique. Basically, when a site is attached to n providers, each of its hosts will receive n different IPv6 addresses. This reduces the size of the BGP routing tables by avoiding to advertise the IPv6 prefixes used by the stub domains and provide many additional benefits in terms of path diversity or performance. Now that the shim6 standardization is being finalized by the IETF, it is time to validate this approach experimentally in the IPv6 Internet. Sebastien Barré has developed the first publicly available implementation of the shim6 IPv6 host-based multihoming on the Linux kernel. LinShim6 is available form http://inl.info.ucl.ac.be Other approaches to better scale the Internet architecture are being discussed, notably within the Routing Research Group of the Internet Research Task Force. Several of these approaches rely on separating the two roles of IP addresses: the locator role and the identifier role. In today's IPv4 Internet, IPv4 addresses are used both to indicate the location in the Internet topology of a host (the locator role) and to terminate the transport flows on end-hosts (the identifier role). This means that it is difficult to change the IP address of a host without disrupting transport flows. The techniques that separate identifiers from locators take a different approach. First, an identifier is attached to each end-host. This identifier is used to terminate the transport flows. Second, each identifier may be reachable through multiple locators and a mapping mechanism is used to map an identifier (or a set of identifiers) onto a set of locators. This improves the scalability of the routing system as only the locators need to be distributed by BGP provided, of course, that the mapping system remains scalable. Furthermore, separating identifiers and locators has several additional benefits in terms of path diversity and performance. Some approaches propose to attach locators to hosts while other prefer to attach locators only to routers. The latter approach is the solution chosen by the proponents of the Locator/Identifier Separation Protocol (LISP). LISP is a router-based solution to solve the scaling problems of the Internet architecture that is currently being developed by Cisco. There are still many open questions concerning notably the mapping between identifiers and locators. To allow researchers and network operators to experiment with LISP, the IP Networking Lab of UCLouvain releases OpenLISP. OpenLISP is the first publicly available implementation of LISP on the FreeBSD kernel. OpenLISP was designed and implemented by Luigi Iannone. You can find more details about OpenLISP from http://inl.info.ucl.ac.be Best regards, Olivier Bonaventure

1 0

Data about IPv6 fragmentation
by Fernando Gont 16 Jul '08

16 Jul '08

Hello folks, Is anybody aware of any papers with real-world data about IPv6 fragmentation? I'd be interested in something along the lines of: Shannon, C., Moore, D., and Claffy, K.C. 2001. Characteristics of Fragmented IP Traffic on Internet Links. (but that focuses on IPv6 fragmentation, rather than v4 fragmentation). Thanks! Kind regards, -- Fernando Gont e-mail: fernando(a)gont.com.ar || fgont(a)acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

1 0

Enterprise VoIP Survey
by nanog＠ryburn.org 16 Jul '08

16 Jul '08

Hello Everyone, I am doing a research project on VoIP deployment feasibility for a graduate degree. I am looking for people who have been involved with Enterprise level VoIP deployments that would be willing to fill out a short 10-15 question survey. Ideally I would like people who were involved in both the technical and financial aspects of the project. The survey will ask about costs and budgets but you do not need to provide the company who deployed the solution so all answers will be kept anonymous. If you are interested in participating in the survey, please unicast me and I will send you a copy of the survey. Thanks in advance for you help, -Justin

2 1

Transit providers in Sri Lanka
by Skeeve Stevens 16 Jul '08

16 Jul '08

Greetings all, We've been asked to look at building an ISP in Sri Lanka and I wanted to know if anyone had any of the following: - Transit providers in Colombo - Types of handoff's common in this location (Ethernet, ATM, etc) - Expected US$/mb of flat-rate traffic - Datacentres in Sri Lanka - secure and protected Thanking you in advance for your advice. -- Skeeve Stevens, Managing Director eintellego Pty Ltd - The ISP Specialists skeeve(a)eintellego.net / www.eintellego.net Phone: (+612) 8197 2760, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve -- NOC, NOC, who's there?

1 0