February 2009 - Test - lists.nanog.org

issues with msn
by Carlos Alcantar 19 Feb '09

19 Feb '09

Hey guys any of you guys seeing some issues getting to msn on the west coast here? I seem to be having issues via level3 abovenet and Comcast. -carlos

1 0

Re: more AS prepend antics?
by Hank Nussbacher 19 Feb '09

19 Feb '09

At 08:06 PM 18-02-09 -0600, neal rauhauser wrote: > Why so many prepends from these folks? Cuz you set maxas=20? Just plain noise. -Hank >Feb 18 20:02:35.649 CST: %BGP-6-ASPATH: Long AS path 1785 1273 9035 1267 >41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 >41827 41827 41827 41827 41827 41827 41827 41827 41827 received from >209.253.101.9: More than configured MAXAS-LIMIT > >Feb 18 20:03:07.361 CST: %BGP-6-ASPATH: Long AS path 1785 2516 2516 2516 >2516 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 >17697 9597 9597 9597 9597 received from 209.253.101.9: More than configured >MAXAS-LIMIT > >Feb 18 20:04:07.849 CST: %BGP-6-ASPATH: Long AS path 1785 3549 8966 8961 >38193 38264 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 >45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 >45127 45127 45127 45127 45127 received from 209.253.101.9: More than >configured MAXAS-LIMIT > > >-- >mailto:Neal@layer3arts.com // >GoogleTalk: nrauhauser(a)gmail.com >IM: nealrauhauser

2 1

Re: Greedy routing
by Brighten Godfrey 19 Feb '09

19 Feb '09

> On Wed, 18 Feb 2009 22:12:02 GMT, Rod Beck said: >> http://www.physorg.com/news154093231.html > >> From the fine article: > > "In greedy routing, a node passes information to the neighboring > node that is > closest to the final destination in an abstract space called hidden > metric > space." > > Sounds suspiciously like "throw the packet at the router that's got > the shortest > AS path to the destination" doesn't it? You don't need to know the > entire > topology to know router X is 2 AS's closer to the dest than router > Y once > X and Y have been loaded with the "hidden metric space" known as a > BGP update ;) No, it's quite different from BGP. The high level point is that BGP needs to know a lot of information about the network in order to route, while greedy routing (when it works) requires very little state. To make it concrete: You're right that BGP doesn't need to know the entire topology, but it comes quite close, in terms of the total amount of information it has. To throw the packet at the router that's got the shortest AS path to the destination, you need to have information from every neighbor about every destination. A BGP router in general needs one FIB entry for every destination (IP prefix) in the Internet, i.e., about 300,000 entries, and in the RIB it has potentially 300K from every BGP neighbor.... potentially, millions of entries. In contrast, greedy routing would require probably less than a dozen entries for the average router. This is because the router only needs to know its own "identifier", and those of its immediate neighbors. The routing algorithm has some "distance function" dist (ID1, ID2). A packet comes with some destination identifier D, and the router compares the distance dist(N, D) for each neighbor N, and forwards the packet to the neighbor with smallest distance. For example, suppose you know the topology is a two-dimensional grid. Then the "identifier" is the router's (X,Y) coordinates and the distance function can be Euclidean distance. The main catch is of course that most networks don't have such nice regular structure like the grid. Essentially, greedy routing tries to "summarize" the structure of the network using a very small amount of information. And there are topologies whose pattern of links is "too complicated" (in a certain sense) for greedy routing to be able to summarize it. Therefore it is interesting when you find a network in which greedy routing works, especially if that network is vaguely realistic. The most well-known example is Jon Kleinberg's work on small world networks (http://tinyurl.com/dye7ub) which gives some theoretical backing to Milgram's "six degrees of separation" experiment from the 1960s (which basically used a kind of greedy routing). This physorg paper seems to be very much in the same style, showing that greedy routing works on an Internet-like graph. (Disclaimer: I have only read the above article, not the paper.) Of course there are plenty of reasons you would not use this in practice, e.g., it gives the router little control over routing policy, traffic engineering, etc. > I'm not sure this article is actually telling us anything we didn't > already > know. Now if there was a way to compute those distance metrics without > global knowledge - if there was only an algorithm that > only cared about what was "upstream" from a locally connected link > and whether > it was connected. Say, we could call it a link-state routing > protocol.... > > Now if they were able to actually develop a link-state protocol > that involved > *only* local adjacency announcements and not flooded announcements, > *that* > would be something... But what I see here is "if somebody > developed that, > we'd be able to route more efficiently". This is essentially what they are doing. The distance is computed based on only local knowledge, not global knowledge. Each router needs to know only local adjacencies. Caveat: I haven't read the paper and don't know how they assign the router identifiers, so I am answering only about greedy routing in general. ~Brighten Godfrey

1 0

more AS prepend antics?
by neal rauhauser 19 Feb '09

19 Feb '09

Why so many prepends from these folks? Feb 18 20:02:35.649 CST: %BGP-6-ASPATH: Long AS path 1785 1273 9035 1267 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 received from 209.253.101.9: More than configured MAXAS-LIMIT Feb 18 20:03:07.361 CST: %BGP-6-ASPATH: Long AS path 1785 2516 2516 2516 2516 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 9597 9597 9597 9597 received from 209.253.101.9: More than configured MAXAS-LIMIT Feb 18 20:04:07.849 CST: %BGP-6-ASPATH: Long AS path 1785 3549 8966 8961 38193 38264 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 received from 209.253.101.9: More than configured MAXAS-LIMIT -- mailto:Neal@layer3arts.com // GoogleTalk: nrauhauser(a)gmail.com IM: nealrauhauser

1 0

RE: McAfee/AT&T Issue
by Scott Weeks 18 Feb '09

18 Feb '09

--- mcalhoun(a)iodatacenters.com wrote: From: "Calhoun, Matthew" <mcalhoun(a)iodatacenters.com> While I agree with all of your assessments, this traceroute was being provided to illustrate where traffic *appears* to be stopping when we are seeing the issue. It's intermittent, so some times we can reach the destination hosts (via HTTP, HTTPS, etc.) and sometimes we can't. When we can reach the destination hosts (via HTTP), the traceroute completes When we can't reach the destination hosts (via HTTP), the traceroute won't complete and the last hop is the host that I indicated in my previous post (12.118.225.22) ------------------------------------------------- It may be best to use tcptraceroute when it is and when it isn't working. It may help you evaluate where the trouble is occurring more efficiently. scott

1 0

Cisco NOS
by Bryant Valencia 18 Feb '09

18 Feb '09

Has anybody hired Cisco for their NOS (Network Optimization Services)? I would like to hear about your experience (good or bad). I'm particularly interested in their CNC box. Bryant.

6 6

IP DSLAMs
by Church, Charles 17 Feb '09

17 Feb '09

All, Looking for a recommendation on DSLAMs to replace our unsupported Cisco 6015s. Requirements are: G.SHDSL 2 and 4 wire mode (CPEs are strictly Cisco 828, 878, and small cisco routers using WIC-1SHDSL and the V2/V3 of them) QOS would be nice, not a necessity SNMPv3 and SSHv2 support IPv6 support now or in a future upgrade Doesn't need to actually route, but if it can bridge one or more downstream CPEs into an ethernet dot1q VLAN on an uplink, that'll work Don't want ATM uplinks, ethernet only, dual uplinks preferred Looking for port density ranging from 15 to about 100 in a chassis Power can be DC, but AC is greatly preferred Off-list responses appreciated, since this is kind of OT. These are for large campus environments where some remote buildings are maybe a mile or two from a campus-owned telecom shack, with only copper connectivity to said building. No POTS is required over the DSL links, the copper pairs are dedicated. Thanks, Chuck

1 0

Capture problems with Intel quad cards?
by John A. Kilpatrick 17 Feb '09

17 Feb '09

Has anyone had problems with using current Intel quad ethernet cards for packet capture? As a proof-of-concept test we bought an Intel PWLA8494GT and hooked it up to some Network Critical taps. There was a very strange issue with corruption of the captured packets. The *only* issue (but it's a big one) is that the source IP on some captured packets is munged. As far as I can tell that's the *only* issue with the packet captures - no other data is corrupted. Oh, and to rule out other issues: 1. Corruption seen both when using network taps and when using a port span/mirror (so it's not the taps). 2. Corruption *not* seen using the on-board broadcom nics of the test host (so it's not the box). So I'm pretty sure we narrowed it down to the card. We tried the card in an indentical host and saw the same problems. I thought it might be a driver issue - I tried both gentoo and FreeBSD (not sure how different the drivers are) just to see if it mattered at all and it didn't. Much googling didn't show this to be a known issue - just wondering if anyone else has seen it? Other recommendations welcome - the next step is, I suppose, a broadcom-based PCI-X card. (I've got some old pizza boxes I'm trying to repurpose as network probes.) Thanks, John -- John A. Kilpatrick john(a)hypergeek.net Email| http://www.hypergeek.net/ john-page(a)hypergeek.net Text pages| ICQ: 19147504 remember: no obstacles/only challenges

5 5

Announcing GCTIP - New Forums for Internet Transparency, Performance, and ISP Issues
by Lauren Weinstein 17 Feb '09

17 Feb '09

Announcing GCTIP - New Forums for Internet Transparency, Performance, and ISP Issues http://lauren.vortex.com/archive/000506.html Greetings. I'm pleased to announce the availability of a new venue for discussion, reporting, analysis, information sharing, queries, and consumer assistance regarding Internet performance, transparency, and measurement, plus a wide range of topics associated with consumers and their interactions with Internet Service Providers (ISPs). Called GCTIP Forums: http://forums.gctip.org this project -- The "Global Coalition for Transparent Internet Performance" -- is the outgrowth of a network measurement workshop meeting sponsored by Vint Cerf and Google at their headquarters in June, 2008 for a number of academic network measurement researchers and other related parties. This is the same meeting that formed the genesis of the open platform M-Lab ("Measurement Lab") project that was recently announced ( http://www.measurementlab.net ). GCTIP was the original name for the mailing list that I maintained for that Google meeting and subsequent discussions (full disclosure: I helped to organize the agenda for the meeting and also attended). Unless we know what the performance of the Internet for any given users really is -- true bandwidth performance, traffic management, port blocking, server prohibitions, Terms of Service concerns, and a wide range of other parameters, it's impossible for anyone who uses Internet services to really know if they're getting what they're paying for, if their data is being handled appropriately in terms of privacy and security, and all manner of other crucial related issues. While transparency and related concerns do have impacts on "network neutrality" issues, neither GCTIP nor GCTIP Forums are oriented toward network neutrality discussions. The purpose of GCTIP Forums is to provide a free discussion environment to act as a clearinghouse for all stakeholders (technical, consumers, ISPs, government-related, etc.) to interact on the range of "network transparency" and associated topics. The focus is on collecting, analyzing, and disseminating reports relating to Internet measurement/test data -- plus associated concerns, discussions, etc., in manners that are most useful to the network community at large. There are many groups working in the network measurement area, but surprisingly little data sharing, coordination, or ongoing reporting in a form that is useful to most ordinary Internet consumers or other interested observers. An area of particular concern is helping to assure that measurement tests and perceived consumer problems with their ISPs aren't misinterpreted by users resulting in unfair or simply wrong accusations against those ISPs. I feel strongly that consumers need a place to go with these sorts of issues where the broader community and experts can help interpret what's really going on. Guilty firms should be exposed, but the innocent must not be inappropriately branded. All current GCTIP Forums topics can be viewed without signing up on the system. Simple registration is required to post new discussion threads and replies, but no non-administrative topics are currently pre-moderated (any reported materials confirmed to be inappropriate will be deleted promptly). GCTIP Forums exist to enable the exchange of relevant ideas, queries, data, and other information for anyone concerned about the Internet worldwide. The Forums are seeded with five top-level discussion topics to get things rolling, but suggestions for additional categories are welcome. New threads (e.g. discussions of particular measurement tools, measurement results, specific ISP issues and concerns, etc.) can be created by registered users, starting right now. Please note that I am running GCTIP on my own dime at this point. At such a time as any outside support funding becomes available for the project (which would be very much appreciated!) it will be publicly announced of course. Spread the word! This is your chance to help yourself and everyone else better understand what the Internet is <b>really</b> doing, and by extension, where it is going tomorrow. Thanks very much. Be seeing you ... at: http://forums.gctip.org ... --Lauren-- Lauren Weinstein lauren(a)vortex.com or lauren(a)pfir.org Tel: +1 (818) 225-2800 http://www.pfir.org/lauren Co-Founder, PFIR - People For Internet Responsibility - http://www.pfir.org Co-Founder, NNSquad - Network Neutrality Squad - http://www.nnsquad.org Founder, PRIVACY Forum - http://www.vortex.com Member, ACM Committee on Computers and Public Policy Lauren's Blog: http://lauren.vortex.com

1 0

Shadowserver - ASN & Netblock Alerting & Reporting Service
by Andre' M. DiMino 17 Feb '09

17 Feb '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Shadowserver Foundation is pleased to announce the formal rollout of our ASN/netblock alerting and reporting service. This reporting service is provided free-of-charge and is designed for ISPs, enterprises, hosting providers, and other organizations that directly own or control network space. It allows them to receive customized reports detailing detected malicious activity to assist in their detection and mitigation program. Shadowserver has been providing this service to many subscribers for over two years, and currently generate over 4000 reports nightly. Since the response to this service has been extremely positive from our consumer base, we now wish to make it more widely and openly available. The reporting service monitors and alerts the following activity: Detected Botnet Command and Control servers Infected systems (drones) DDoS attacks (source and victim) Scans Clickfraud Compromised hosts Proxies Spam relays Malicious software droppers and other related information. The Shadowserver Foundation filters data received from its worldwide sensor and monitoring networks and employs an analysis engine to classify the attacks. It then sorts this data according to ASN, netblock, and even Geolocation. Detected malicious activity on a subscriber's network is flagged accordingly and is included in daily summarization reports detailing the previous 24 hours of activity. Reports are only sent upon detection of malicious activity. These customized reports are made freely available to the responsible network operators as a subscription service. To request a free subscription to The Shadowserver Foundation's ASN/netblock reporting service, send an email from your organization's email account to admin(a)shadowserver.org Please provide the following information: Name Organization Networks of responsibility by ASN or CIDR Email address(es) of the report receipients Contact information for verification The Shadowserver Foundation is an all volunteer, non-profit, vendor-neutral organization that gathers, tracks, and reports on malicious software, botnet activity, and electronic fraud. It is the mission of the Shadowserver Foundation to improve the security of the Internet by raising awareness of the presence of compromised servers, malicious attackers, and the spread of malicious software. - -- Andre' M. Di Mino - SemperSecurus The Shadowserver Foundation http://www.shadowserver.org Skype: sempersecurus AIM: sempersecurus "Make sure that nobody pays back wrong for wrong, but always try to be kind to each other and to everyone else." 1 Thessalonians 5:15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmaQsEACgkQPJaIJoADD653DQCgkF4aRfxbpSh+IxBfGyrMqT3X eAYAnjfPpeA8ATZ//s1VUrim8DbZPO0C =oMJw -----END PGP SIGNATURE-----

1 0