NANOG 23 Agenda

This tutorial addresses the building blocks of IP routing protocol scalability (hierarchy, redundancy, and addressing and summarization) along with protocol-specific issues. BGP, ISIS and OSPF configurations and parameters are explored. The examples presented include a set of protocol-specific \"best practices.\" <BR><BR> Intended Audience: Network operators and engineers with IP routing experience. Knowledge of the protocols covered is expected. <BR><BR> Tutorial Outline <BR><BR> Introduction<BR> - Scope of the Presentation<BR> - Agenda <BR><BR> <STRONG>Scalability Building Blocks</STRONG><BR> Relationship to Convergence and Stability<BR> Impact/Use of Hierarchy/Redundancy/Addressing and Summarization <BR> Hierarchy<BR> - Why is hierarchy important?<BR> - Brief overview of service placement (per layer. <BR><BR> Redundancy - When is redundancy too much?<BR> - IGP Flooding <BR><BR> Addressing and Summarization<BR> -Aggregation Methods per protocol <BR><BR> <STRONG>ISIS Scalability</STRONG> <BR><BR> Hierarchy in ISIS<BR> - L or L-only networks<BR> - Use and limitations of Hierarchical Networks<BR> - Route Leaking <BR><BR> Detection and Propagation of Changes - Fast Hellos<BR> - LSP Generation<BR> - SPF Runs<BR> - Exponential Backoff<BR> <BR><BR> Other tips...<BR> - Overload bit <BR><BR> <STRONG>OSPF Scalability</STRONG> <BR><BR> Hierarchy - Area types and flow of routing information<BR> - LSA Filtering <BR><BR> Detection and Propagation of Changes<BR> - Fast Hellos<BR> - LSP Generation<BR> - SPF Runs<BR> - Exponential Backoff <BR><BR> Other tips...<BR> - Overload bit <BR><BR> <STRONG>OSPF Scalability</STRONG> <BR><BR> Hierarchy - Area types and flow of routing information<BR> - LSA Filtering <BR><BR> Detection and propagation of changes<BR> - Fast Hellos<BR> - LSA Generation<BR> - SPF Runs<BR> - Exponential Backoff <BR><BR> Other tips...<BR> - Stub router advertisement <BR><BR> <STRONG>BGP Scalability</STRONG> <BR><BR> iBGP Full Mesh<BR> - Route Propagation Requirements <BR><BR> Peer-Groups<BR> - Configuration Grouping and UPDATE Generation <BR><BR> Route Reflectors<BR> - Deployment (Hierarchy) <BR><BR> Confederations<BR> - Deployment<BR> - Interaction with IGPs <BR><BR> Detection and Propagation of Changes - minAdvertisementTimer<BR> - NEXT_HOP Reachability<BR> - 4.5.3 Route Dampening <BR><BR> Summary and Conclusions

This tutorial introduces service providers to some of the features available in BGP to aid multihoming to the Internet. After an explanation of multihoming and the principles being followed in this tutorial, several examples involving different scenarios will be given. This includes the options available when multihoming to the same ISP (including RFC2270) and to different upstreams. Configurations for modifying inbound and outbound traffic flows are covered. The tutorial concludes with a case study, and an examination of the use of BGP communities by several ISPs.

Using details gathered from both small and larage providers in New York, the rest of the USA, and overseas, Donelan discusses the events and aftermath of September 11 from an operators\' point of view.

This presentation takes a real-world look at DoS attacks, concentrating on those launched in relation to Internet Relay Chat (IRC). We will cover the psychology of those who launch DoS attacks, the tools and methods they use, and our successes with tracking and prosecution of these individuals. Additionally, we will cover our tried-and-tested methods of observing, tracking, and defending against these attacks. Finally, we will focus on the effects of these attacks on nearby machines and network infrastructure.

The goal of this presentation will be to introduce NOBAD, the Network Oriented Basic Anomaly Detection Infrastructure. NOBAD, a volunteer effort, aims to provide a means of distributed network performance and anomaly measurements to quickly detect network problems. These could include line saturation or CPU spikes, which might be signs of denial of service attacks or technical problems. NOBAD consists of a number of sensors deployed throughout the network and a smaller number (where \'number\' is an arbitrary amount from one to n) of so-called aggregators to collect data and react accordingly.<BR> <BR> NOBAD is currently in use at a large network infrastructure provider and has been tested in governmental environments as well. Its distributed nature and the openness of its code and underlying mechanisms and protocols provide the needed vendor independence for homogenous networks. This presentation will focus on both technical background and possible use cases.<BR> <BR> NOBAD, as a volunteer effort, is available as Open Source and can be used under the terms of the \'BSD Public License,\' which permits inclusion in commercial products. A stable release is planned for the weekend prior to NANOG 23.<BR> <BR> The technical background section of the talk will include details of sensor and aggregator implementation, and will address current problems with homogenous networks.<BR> <BR> The use case presentation will cover current implementations, advantages of NOBAD compared to static log file analyzers such as swatch, and a view into the future of distributed anomaly detection.

This presentation describes a network service model for high-speed Metropolitan Area Network (MAN) service providers to deliver economical services between cities. It utilizes a distance-insensitive IP NSP as a WAN partner for inter-city services, simplifies MAN operation, and improves the scalability of a traditional standard overlay model by allowing the MAN provider to peer with the NSP for both Internet transit and inter-city MAN services (e.g., transparent LAN services.)<BR> <BR> This network service model allows an NSP to offer hierarchical MPLS services to downstream providers, while providing scalability and automation for both the NSP and MAN provider. While this presentation refers to a solution for MAN providers, any downstream provider that needs hierarchical MPLS services from an NSP can use this service.

Now more than ever, Internet Service Providers are focusing on ways to increase the resiliency of their networks and, if at all possible, reduce their operating costs at the same time. Past research (Peering Decision Tree, presented at NANOG 19, and A Business Case for Peering) demonstrates the economic tradeoffs of peering and highlight the simple but challenging first step: How to know who to talk with at an ISP to get peering set up?<BR> <BR> This Peering BOF focuses on this first step using \"Peering Personals.\" We solicit Peering Coordinators (before the meeting), asking them to characterize their networks and peering policies in general ways (\"content heavy\" or \"access (eyeball) -heavy,\" \"Multiple Points Required\" or \"Will Peer anywhere,\" \"Peering with Content OK,\" etc.). From the answers we will select a set of ISP Peering Coordinators to present a 2-3 minute description their network, what they look for in a peer, etc., allowing the audience to put a face with the name of the ISP. At the end of the Peering BOF, Peering Coordinators will have time to speak with Peering Coordinators of ISPs they seek to interconnect with. The expectation is that these interactions will lead to the Peering Negotiations stage, the first step towards a more fully meshed and therefore resilient Internet.<BR> <BR> At the first NANOG Peering BOF I volunteered to maintain a Peering Contact Database (as an Excel Spreadsheet) that I e-mail out about every six weeks to participating Peering Coordinators. If you are a Peering Coordinator and would like to be listed in the PCD and get a copy of the PCD, send a note to [email protected] with Subject: PCD. I maintain this as a community service and is completely separate from my role at Equinix.<BR> <BR> ------<BR> <BR> NOTES:<BR> <BR> Date: Mon, 29 Oct 2001 10:03:33 -0800<BR> From: William B. Norton <BR> Subject: Peering BOF IV Meeting Notes<BR> <BR> Hi all -<BR> <BR> Here are my notes from the Peering BOF IV - NANOG 23.<BR> <BR> We started at 7:30 PM Monday evening with the intention of pulling the <BR> peering community together through introductions. We had about 20 Peering <BR> Coordinators step up to the mike, introduce themselves, say a word or two <BR> about their network, peering policy and what they are looking for in a peer <BR> network. This allowed the audience to put a face to a name for <BR> conversations afterwards. Another 10 that didn\'t pre-register for this <BR> stepped up and chimed in as well. From about 8:30 til almost 10PM the <BR> community stuck around to talk and I\'m told that *dozens* of peering <BR> sessions (Yahoo!, Akamai, Carrier1, SBC, etc.) will be set up as a result. <BR> Highly successful NANOG for this segment of the population.<BR> <BR> Several folks asked for a list of those who stood up to talk about their <BR> peering policy, and here is what I have:<BR> <BR> BBC Internet<BR> Simon Lockhart<BR> [email protected]<BR> <BR> Digital Island<BR> Mitchell Rose<BR> [email protected]<BR> <BR> DoubleClick<BR> Alex Ng<BR> [email protected]<BR> <BR> TELUS<BR> Clinton Work <BR> [email protected]<BR> <BR> France Telecom/Open Transit<BR> Vincent Gillet<BR> [email protected]<BR> <BR> Globix<BR> Steven J. Schecter<BR> [email protected]<BR> <BR> WINFirst<BR> Hansel Lee<BR> [email protected]<BR> <BR> 4CNet<BR> Brian Court<BR> [email protected]<BR> <BR> Akamai<BR> Rachel Warren <BR> [email protected] <BR> <BR> Patrick Gilmore <BR> [email protected]<BR> <BR> Hostcentric <BR> Charlene Wang<BR> [email protected]<BR> <BR> Japan Telecom<BR> Seiji Kuroda<BR> [email protected]<BR> <BR> Adelphia<BR> Joe Klein<BR> [email protected]<BR> <BR> Earthlink<BR> Jeb Linton/Josh Fleishman<BR> <BR> Yahoo!<BR> Jeffrey Papen<BR> [email protected]<BR> <BR> SBC<BR> Ren Nowlin <BR> [email protected]<BR> <BR> Carrier1<BR> Eric Troyer<BR> [email protected]<BR> <BR> ESNet<BR> Joe Metzger<BR> [email protected]<BR> <BR> Velocita<BR> Brian Dickson<BR> [email protected]<BR> <BR> I want to thank these folks for volunteering to share their info and hopefully this led to some sessions coming up. <BR> <BR> Speaking of which, if Peering Coordinators would like to participate in the Peering Contact Database and receive a copy once a month or so of the Peering Contact Database, send e-mail to [email protected] and I\'ll return the template to fill out. So far we have about 150 Peering Coordinators listed.<BR> <BR> Several suggestions were made for the next time:<BR> <BR> - Include a \"Peering Contracts Required\" icon and<BR> <BR> - \"Make it easy for folks to step up later along with Icons\" and<BR> <BR> - \"Include e-mail addresses\"<BR> <BR> We\'re going to try and factor in these suggestions for the Peering Personals at the next Gigabit Peering Forum which is held Dec 3rd in San Jose. If you are a Peering Coordinator and would like an invite to this let <BR> me know.<BR> <BR> For those who could not attend due to travel restrictions or whatever I\'d be happy to e-mail the slides with the peering icons and ISP names etc.<BR> <BR> Hope this helped -<BR> <BR> Bill

The use of the whois protocol to provide a look-up service for Internet infrastructure information is showing its age. Operators are experiencing increased demands for information through the whois service. From the needs of privacy, law enforcement, intellectual property rights, and referrals, new demands are being asked of this service. VeriSign is in the process of gathering requirements from the various whois user communities. Mark will present the process through which VeriSign is gathering these requirements, and the generalities of what is currently known about them.<BR> <BR> In addition, VeriSign has been working on efforts to shift this look-up service away from whois to other, more capable protocols. Andrew will present VeriSign\'s two projects looking at replacing this service with a protocol other than whois: 1) VeriSign is piloting a project to replace whois with LDAP, and 2) a proposed XML-based directory protocol that mirrors much of the effort going into EPP (Extensible Provisioning Protocol).

We will present our analysis of the surprisingly strong impact of recent Microsoft worms (such as Code Red II and Nimda) on the stability of the global routing system. Analysis of the on-line BGP message archives from the RIPE-NCC Routing Information Service, and of the worm scanning and infection spread datasets shows strong correlations between worm propagation periods and very long-lasting BGP \"update storms.\" <BR><BR> We will also discuss preliminary results concerning the populations of unstable routes, unreachable networks, and the mechanisms by which the worm traffic may be destabilizing the BGP routing system. <BR><BR> See: <BR><BR> <A HREF=\"http://www.renesys.com/tech/presentations/\">http://www.renesys.com/tech/presentations/</A>

In this talk, we explore the degree to which commercial strategies, peering disputes, network failures, misconfiguration, and occasionally, malicious intent, lead to a partitioning of Internet topology. Specifically, we present a three-year study of the differences in Internet provider reachability. We focus on \"dark address space,\" or the range of topology accessible from one provider, but unreachable via one or more competitor networks. We present active and passive measurements of these differences on time scales ranging from several seconds to multiple months.

While it is well-known that BGP is vulnerable to simple, accidental misconfigurations that can cause widespread loss of connectivity, most of the evidence is anecdotal. Routing configuration errors have received less attention than more popular threats to connectivity, such as denial-of-service, and CAIDA\'s BGP analyses and Merit\'s IPMA project provide some of the only data available.<BR> <BR> We present initial results of a new study of BGP configuration errors based on publicly available routing table snapshots and looking glasses. We quantify the kind and extent of configuration errors, as well as their impact on backbone connectivity. In this talk, we focus on announcements with incorrect origin AS and partial connectivity.<BR> <BR> We find that there are a significant number of questionable routing announcements, but the majority of these have only a slight impact on connectivity. Of the roughly 2% of the prefixes per day that are not announced with consistent origins, O(100) prefixes are subject to AS-path stripping and potential address space hijacks, while the other fluctuations are more benign. We also analyze partially connected address space (that is reachable only from some parts of the Internet) to expose route filtering and damping practices that are limiting connectivity. We find that 1-2% of the address space exists in a persistently partially reachable state at any given time.

Service providers have expressed a need for a simple, standard method of building tools for network management and provisioning. The Extensible Markup Language (XML) provides a straighforward means by which these needs can be met. Using standard tools, XML can be easily parsed, stored, retrieved, debugged, and documented. XML\'s ASCII encoding lends itself well to scripting and provisioning (it\'s easy to write, and easy to debug), and its ability to provide forward and backward compatibility makes it a robust choice for building network management tools.<BR> <BR> This talk will include a very brief introduction to XML, a description of areas of network management to which XML is applicable, and examples of using XML and XML-based tools to wrangle operational and configuration data from a network.

The security of a network infrastructure, particularly an extensive one, relies on the proper management of the network address space, routes, and external connections. If network managers don\'t know what they have, how it\'s connected, and what else it\'s connected to, they can\'t know if it is secure. The Internet Mapping Project, started by Bill Cheswick at Bell Labs, has been collecting intriguing topological information about the Internet since August of 1998. In the last year, this technology has been applied to large corporate intranets and ISPs with equally illuminating results.<BR> <BR> The presentation introduces the analysis and interpretation of such maps and what can be determined from such analysis. The larger the network, the more useful we find this analysis to be for identifying single points of failure, address squatting (the use of another organization\'s address space within one\'s own network), legacy connections to divested networks or former business partners, and outright security violations. Real-world anonymized examples will be part of the presentation.