Spare a Little Change? Towards a 5-Nines Internet in 250 Lines of Code

Total Page:16

File Type:pdf, Size:1020Kb

Spare a Little Change? Towards a 5-Nines Internet in 250 Lines of Code Spare a Little Change? Towards a -Nines Internet in Lines of Code Mukesh Agrawal CMU-CS-- May School of Computer Science Carnegie Mellon University Pittsburgh, PA Thesis Committee: David G. Andersen Bruce M. Maggs, Duke University Srinivasan Seshan, Chair Hui Zhang Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy. Copyright © Mukesh Agrawal This research was sponsored by the National Science Foundation under grant numbers CNS-, ANI-, and ANI-; the Air Force Research Laboratory under grant number F---; the Pittsburgh Digital Greenhouse; and AT&T. The views and conclusions contained in this document are those of the author and should not be interpreted as representing the official policies, either expressed or implied, of any sponsoring institution, the U.S. government or any other entity. Keywords: Internet reliability, BGP performance, Quagga This document includes excerpts of the source code for the Linux operating system kernel, and the Quagga routing software suite. These programs are copyrighted by their authors; excerpts are reproduced here solely for scholarly purposes. To my parents मेरे सब उपलिध आप का योछावर पर हआु and नानाजी और नानीजी को दनयाु म कतना दूर लेकन दल म हमेशा पास iii iv Abstract From its beginnings as a single link between two research institutions in , the Internet has grown in size and scope, to become a global internetwork connecting over million computers, and . billion users. No longer a niche facility for scientific col- laboration, the Internet now touches the lives of the world’s population, irrespective of their occupation or geography. It is used by people the world over, to pay bills, read the news, listen to music, watch videos, telephone or video-conference friends and family, and much more. The Internet is the premier communications network of our age. Unfortunately, however, there are some respects in which the Internet lags the net- works it replaces. In particular, with respect to reliability, the Internet falls far short of the Public Switched Telephone Network which proceeded it. Whereas the PSTN sought, and often delivered the vaunted “five nines” of reliability, the Internet strug- gles to compete. As for the cause of this reliability shortfall, available evidence indicates that much of the shortfall is due to the unreliability of IP routers themselves. Given the importance of a reliable Internet to contemporary society, vendors and researchers have proposed a number of solutions to either improve the reliability of individual IP routers, or to make networks more resilient to the unavailability of a single router. While having some promise, these existing solutions face significant obstacles to widespread deployment. Thus, in this dissertation, we endeavor to find or construct a practical, readily deployable, method for mitigating the outages caused by IP routers. To achieve our goal, we take inspiration from previous proposals, which advocated the use of link migration. These proposals improve network resilience, by moving links away from a failed (or failing) router, to an in-service router. To understand the con- straints of a practical solution, and resolve the limitations of previous proposals, we conduct extensive experimentation, and study source code and protocol specifications. Using the insights produced by these studies, we construct a practical, readily deploy- able migration solution with sub-second outage times. v vi Acknowledgments This dissertation could not, and would not, have come to pass, but for for the abundant help, guid- ance, and support I have been so fortunate to receive over the past several years. And so, it brings me much joy to finally have the ideal occasion to give thanks, to the many who helped me along the way. I offer my sincere thanks to all those that follow, and my humble apologies to those who I might, quite regrettably, neglect to mention. Apart from myself, I suspect no one has invested more time in the work leading to this disser- tation than my thesis advisor, Srini Seshan. He has shared his time generously for the past nine years. For that alone, I am deeply indebted. In addition, Srini has made the effort, time and again, to find problems that matched my interests and skills. For that, as well, I am truly grateful. Srini has always set high expectations. Indeed, some goals seemed simply unattainable at the outset. But such goals were set with the understanding that, if they were truly impossible, an explanation of why they were so would suffice. It is an approach that is simultaneously idealistic, and pragmatic. And it is has served me well — both in research, and beyond. Perhaps, then, the best way to understand limits is to push them… There are many factors that contribute to research success, some more obvious than others. Perhaps one of the most under-appreciated is a solid methodology. Thus, for the successes I have had, I must thank those who helped develop my approach to research. In addition to my research advisors, these include teachers and colleagues, from primary school through grad school. For contributing to my research methods, I thank specifically: Juanita Mitchell, who empha- sized the importance of meticulousness in her science class; Doug Collar, whose insisted on good note-taking in his literature class; Bianca Schroeder, who taught me how to tease insights from in- timidatingly large log files; David Nagle, who advised me to work every day, and to work neither too little, nor too much; and Sean Rhea, who taught me that when stuck, it is better to take a walk than to bang one’s head against the proverbial wall. As many before me, I had no small amount of doubt during graduate school. For helping me through those doubting moments, I thank Michael Abesamis, Luis von Ahn, Aditya Akella, Rajesh Balan, Nikhil Bansal, Ashwin Bharambe, Sharon Burks, Shuchi Chawla, Beatrice Chen, Urs Hengartner, John Langford, Kate Larson, Bruce Maggs, Amit Manjhi, Mahim Mishra, David Nagle, Suman Nath, Yamuna Raju, Bianca Schroeder, Srini Seshan, Maverick Woo, and Jeannette Wing. I thank especially Rajesh Balan, Amit Manjhi, Suman Nath, and Srini Seshan for their kind and sustained encouragement to complete my dissertation. The Computer Science Department at Carnegie Mellon is an amazing place to study, and con- duct research. Beyond the caliber of research talent, and the first-rate facilities, lurk two less well- known, but no less important, treasures. These are the administrative staff, and, the not entirely unrelated department culture. Sharon Burks, Deborah Cavlovich, Catherine Copetas, Tracy Far- bacher, Barbara Grandillo, Karen Lindenfelser, Angela Miller, and others took care of administra- tive matters, so that I never had to. vii When I returned to Pittsburgh in the Spring of , Deb even had the foresight to find me an office literally two doors down from my advisor, so that I could easily drop in with quick ques- tions. That Deb foresaw what I would need, when I myself had not, is truly remarkable, and quite appreciated. I also thank Catherine and Karen taking the time to welcome me back during that Spring, despite my having been out of touch for so long. The administrative staff takes the lead in creating a culture that values students not just as stu- dents, but as people with interests and needs beyond those of classwork or research. The students themselves build on this foundation, to provide a welcoming, supportive, and fun-loving social en- vironment. In particular, the members of D/5 volunteer their time to organize non-work events, to help balance the lives of their fellow students. Thank you to Chris Colohan, Francisco Pereira, Patrick Riley, Ted Wong, Martin Zinkevich, and many others. While this work owes much to my time, and my mentors, at Carnegie Mellon, I would be remiss not to mention my mentors from before Carnegie Mellon, and from summers away from Carnegie Mellon. From my time as a graduate student at the University of Michigan, I thank Farnam Jaha- nian, Rob Malan, and Brian Noble. Farnam gave me my start in research, and he, along with Rob, and Brian, encouraged me to continue towards the doctoral degree. From my summers at IBM Research, I thank Dilip Kandlur, Anees Shaikh, and Dinesh Verma. And from my time at AT&T Labs, I thank Bobbi Bailey, Albert Greenberg, Charles Kalmanek, and Jennifer Yates. My work has, I believe, an unusually large empirical component. While that is my natural tendency, it took others to help me appreciate its value. Farnam and Anees appreciated my exper- imental skills long before I could do so myself. Max Poletto, my first manager at Meraki, allowed me to pursue a similar approach in my development work there. It was my first opportunity to ex- periment with, and then apply experimental insights to improve, a production. Successes in those endeavors led me to trully believe in, and fully embrace, the value of experimental work. Thank you, Farnam, Anees, and Max. The results presented herein come from no fewer than one hundred experiments, of at least ten trials each, conducted between March and Novemeber of . For the laboratory that made these experiments possible, I thank the late Jay Lepreau, and the dedicated, talented, and visionary team at the Utah Network Testbed. Their work, and their vision, has dramatically expanded the limits of what is possible in empirical Computer Science. I hope that my work here has, in its own small way, demonstrated the power and value of their vision. Good work cannot be appreciated without good presentation. So I thank those who have im- proved my presentation skills immeasurably over the past many years. I thank Mor Harchol-Balter, my first advisor at Carnegie Mellon, for emphasizing the importance of easy to read, visually ap- pealing graphics.
Recommended publications
  • ECE 435 – Network Engineering Lecture 15
    ECE 435 { Network Engineering Lecture 15 Vince Weaver http://web.eece.maine.edu/~vweaver [email protected] 25 March 2021 Announcements • Note, this lecture has no video recorded due to problems with UMaine zoom authentication at class start time • HW#6 graded • Don't forget HW#7 • Project Topics due 1 RFC791 Post-it-Note Internet Protocol Datagram RFC791 Source Destination If other than version 4, Version attach form RFC 2460. Type of Service Precedence high reliability Routine Fragmentation Offset high throughput Priority Transport layer use only low delay Immediate Flash more to follow Protocol Flash Override do not fragment CRITIC/ECP this bit intentionally left blank TCP Internetwork Control UDP Network Control Other _________ Identifier _______________________ Length Header Length Data Print legibly and press hard. You are making up to 255 copies. _________________________________________________ _________________________________________________ _________________________________________________ Time to Live Options _________________________________________________ Do not write _________________________________________________ in this space. _________________________________________________ _________________________________________________ Header Checksum _________________________________________________ _________________________________________________ for more info, check IPv4 specifications at http://www.ietf.org/rfc/rfc0791.txt 2 HW#6 Review • Header: 0x000e: 4500 = version(4), header length(5)=20 bytes ToS=0 0x0010: 0038 = packet length (56 bytes) 0x0012: 572a = identifier 0x0014: 4000 = fragment 0100 0000 0000 0000 = do not fragment, offset 0 0x0016: 40 = TTL = 64 0x0017: 06 = Upper layer protocol (6=TCP) 0x0018: 69cc = checksum 0x001a: c0a80833 = source IP 192.168.8.51 0x001e: 826f2e7f = dest IP 130.111.46.127 • Valid IPs 3 ◦ 123.267.67.44 = N ◦ 8.8.8.8 = Y ◦ 3232237569 = 192.168.8.1 ◦ 0xc0a80801 = 192.168.8.1 • A class-A allocation is roughly 224=232 which is 0.39% • 192.168.13.0/24.
    [Show full text]
  • Směrovací Démon BIRD
    Směrovací démon BIRD CZ.NIC z. s. p. o. Ondřej Filip / [email protected] 8. 6. 2010 – IT10 1 Směrování a forwarding ● Router - zařízení připojené k více sítím ● Umí přeposlat „cizí“ zprávu - forwarding ● Cestu pozná podle směrovací (routovací) tabulky ● Sestavování routovací tabulky – routing – Statické – Dynamické ● Interní - uvnitř AS rychlé, důvěřivé, přesné – RIP, OSPF ● Externí (mezi AS, pomalé, filtering, přibližné – pouze BGP 2 Rozdělení směrovacích protokolů AS 2 RIP BGP AS 1 OSPF BGP BGP AS 3 3 static Směrovací démon ● Na Linuxu (a ostatních UNIXech) – uživatelská aplikace mimo jádro, forwarding v jádře ● Obvykle implementuje více směrovacích protokolů ● Směrovací politika - filtrování ● Quagga (Zebra) – Cisco syntax http://www.quagga.net ● OpenBGPd - http://www.openbgpd.org ● GateD – zastaralý, ne volná licence ● BIRD 4 Historie projektu ● Start projektu v roce 1999 ● Seminární projekt – MFF UK Praha ● Projekt uspán ● Drobné probuzeni v letech 2003 a 2006 (CESNET) ● Plně obnoveno na přelomu 2008/2009 v rámci Laboratoří CZ.NIC - http://labs.nic.cz 5 Cíle projektu ● Opensource směrovací démon – alternativa k tehdejšímu démonu Quagga/Zebra (GateD) ● Rychlý a efektivní ● Portabilní, modulární ● Podpora současných směrovacích protokolů ● IPv6 a IPv4 v jednom zdrojovém kódu (dvojí překlad) ● Snadná konfigurace a rekonfigurace (!) ● Silný filtrovací jazyk 6 Vlastnosti ● Portabilní – Linux, FreeBSD, NetBSD, OpenBSD ● Podpora IPv4 i IPv6 ● Static, RIP, OSPF, BGP - Route reflektor, Směrovací server (Route server) ASN32 (ASPLAIN), MD5
    [Show full text]
  • BIRD's Flight from Lisbon to Prague
    BIRD's flight from Lisbon to Prague CZ.NIC Ondrej Filip / [email protected] With help of Wolfgang Hennerbichler May 6, 2009 – RIPE 60 / Prague 1 Features ● GPL implementation of RIP, BGP, OSPF ● BGP – ASN32, MD5, route server, ... ● IPv4, IPv6 ● Highly flexible – Multiple routing tables - RIBs (internal and also synchronization with OS) ● Protocol PIPE - multiple routers, route reflectors ● Powerful configuration & filtering language ● Automatic reconfiguration ● Currently developed by CZ.NIC Labs 2 Design 3 Filters example define myas = 47200; function bgp_out(int peeras) { if ! (source = RTS_BGP ) then return false; if (0,peeras) ~ bgp_community then return false; if (myas,peeras) ~ bgp_community then return true; if (0, myas) ~ bgp_community then return false; return true; } protocol bgp R25192x1 { local as myas; neighbor 194.50.100.13 as 25192; import where bgp_in(25192); export where bgp_out(25192); rs client; } 4 Filters example function avoid_martians() prefix set martians; { martians = [ 169.254.0.0/16+, 172.16.0.0/12+, 192.168.0.0/16+, 10.0.0.0/8+, 224.0.0.0/4+, 240.0.0.0/4+, 0.0.0.0/32-, 0.0.0.0/0{25,32}, 0.0.0.0/0{0,7} ]; # Avoid RFC1918 networks if net ~ martians then return false; return true; } 5 define myas = 47200; function bgp_out(int peeras) { if ! (source = RTS_BGP ) then return false; if (0,peeras) ~ bgp_community then return false; if (myas,peeras) ~ bgp_community then return true; if (0, myas) ~ bgp_community then return false; return true; } protocol bgp R25192x1 { local as myas; neighbor 194.50.100.13 as 25192;
    [Show full text]
  • Laboratory 2 ARP; Zebra Routing Daemon Part1. Introduction
    Facultatea de Electronică şi Telecomunicaţii Communications Network Laboratory 1 Laboratory 2 ARP; Zebra routing daemon Part1. Introduction ARP Address Resolution Protocol, ARP, is used by a system, which wants to send data an IP address on the local network, and it doesn’t know the destination MAC address. Systems keep an ARP look-up table where they store information about the association between the IP and MAC addresses. If the MAC address is not in the ARP table, then ARP protocol is used it knowing the destination IP addresss. ARP operation for communications inside the local network: • System checks its ARP table for the MAC address associated with the IP address. • If the MAC address is not in the ARP table, an ARP request is broadcasted in the local network, requesting the MAC address for the specified IP address. • The machine with the requested IP address will reply with an ARP packet containing its MAC address. • Thepacket is sent to the learned MAC address. ARP operation for communication between hosts located in different networks • System determines that the IP address does not belong to the local network and decides to send the packet to the gateway. It has to determine the MAC address of the gateway. • It broadcast an ARP request asking for the MAC address of the IP address belonging to the gateway. It knows the gateway’s IP address from the static route specifying the default gateway. • The gateway will reply with its MAC address. • The packet is sent to the gateway. • The gateway will be in charge with sending the packet to the next hop towards the destination.
    [Show full text]
  • Kratka Povijest Unixa Od Unicsa Do Freebsda I Linuxa
    Kratka povijest UNIXa Od UNICSa do FreeBSDa i Linuxa 1 Autor: Hrvoje Horvat Naslov: Kratka povijest UNIXa - Od UNICSa do FreeBSDa i Linuxa Licenca i prava korištenja: Svi imaju pravo koristiti, mijenjati, kopirati i štampati (printati) knjigu, prema pravilima GNU GPL licence. Mjesto i godina izdavanja: Osijek, 2017 ISBN: 978-953-59438-0-8 (PDF-online) URL publikacije (PDF): https://www.opensource-osijek.org/knjige/Kratka povijest UNIXa - Od UNICSa do FreeBSDa i Linuxa.pdf ISBN: 978-953- 59438-1- 5 (HTML-online) DokuWiki URL (HTML): https://www.opensource-osijek.org/dokuwiki/wiki:knjige:kratka-povijest- unixa Verzija publikacije : 1.0 Nakalada : Vlastita naklada Uz pravo svakoga na vlastito štampanje (printanje), prema pravilima GNU GPL licence. Ova knjiga je napisana unutar inicijative Open Source Osijek: https://www.opensource-osijek.org Inicijativa Open Source Osijek je član udruge Osijek Software City: http://softwarecity.hr/ UNIX je registrirano i zaštićeno ime od strane tvrtke X/Open (Open Group). FreeBSD i FreeBSD logo su registrirani i zaštićeni od strane FreeBSD Foundation. Imena i logo : Apple, Mac, Macintosh, iOS i Mac OS su registrirani i zaštićeni od strane tvrtke Apple Computer. Ime i logo IBM i AIX su registrirani i zaštićeni od strane tvrtke International Business Machines Corporation. IEEE, POSIX i 802 registrirani i zaštićeni od strane instituta Institute of Electrical and Electronics Engineers. Ime Linux je registrirano i zaštićeno od strane Linusa Torvaldsa u Sjedinjenim Američkim Državama. Ime i logo : Sun, Sun Microsystems, SunOS, Solaris i Java su registrirani i zaštićeni od strane tvrtke Sun Microsystems, sada u vlasništvu tvrtke Oracle. Ime i logo Oracle su u vlasništvu tvrtke Oracle.
    [Show full text]
  • Free, Functional, and Secure
    Free, Functional, and Secure Dante Catalfamo What is OpenBSD? Not Linux? ● Unix-like ● Similar layout ● Similar tools ● POSIX ● NOT the same History ● Originated at AT&T, who were unable to compete in the industry (1970s) ● Given to Universities for educational purposes ● Universities improved the code under the BSD license The License The license: ● Retain the copyright notice ● No warranty ● Don’t use the author's name to promote the product History Cont’d ● After 15 years, the partnership ended ● Almost the entire OS had been rewritten ● The university released the (now mostly BSD licensed) code for free History Cont’d ● AT&T launching Unix System Labories (USL) ● Sued UC Berkeley ● Berkeley fought back, claiming the code didn’t belong to AT&T ● 2 year lawsuit ● AT&T lost, and was found guilty of violating the BSD license History Cont’d ● BSD4.4-Lite released ● The only operating system ever released incomplete ● This became the base of FreeBSD and NetBSD, and eventually OpenBSD and MacOS History Cont’d ● Theo DeRaadt ○ Originally a NetBSD developer ○ Forked NetBSD into OpenBSD after disagreement the direction of the project *fork* Innovations W^X ● Pioneered by the OpenBSD project in 3.3 in 2002, strictly enforced in 6.0 ● Memory can either be write or execute, but but both (XOR) ● Similar to PaX Linux kernel extension (developed later) AnonCVS ● First project with a public source tree featuring version control (1995) ● Now an extremely popular model of software development anonymous anonymous anonymous anonymous anonymous IPSec ● First free operating system to implement an IPSec VPN stack Privilege Separation ● First implemented in 3.2 ● Split a program into processes performing different sub-functions ● Now used in almost all privileged programs in OpenBSD like httpd, bgpd, dhcpd, syslog, sndio, etc.
    [Show full text]
  • Irscp.Phase2.Pdf
    Wresting Control from BGP: Scalable Fine-grained Route Control ¡ ¡ ¡ Patrick Verkaik , Dan Pei , Tom Scholl , Aman Shaikh , ¡ Alex C. Snoeren , and Jacobus E. van der Merwe ¡ University of California, San Diego AT&T Labs Abstract Internet paths can often provide improved performance characteristics [1, 2, 20], suggesting the potential bene- Today's Internet users and applications are placing in- fit of making routing aware of network conditions [11]. creased demands on Internet service providers to deliver Additionally, today's operators are often required to re- fine-grained, flexible route control. To assist network op- strict the any-to-any connectivity model of the Internet erators in addressing this challenge we present an Intelli- to deal with unwanted traffic in the form of DDoS at- gent Route Service Control Point (IRSCP), a route con- tacks. Responses can take the form of black-holing traf- trol architecture that allows a network operator to flexibly fic, redirecting it to “scrubbing complexes”, or even more control routing between the traffic ingresses and egresses sophisticated differentiation of unwanted traffic based on of an ISP's network without modifying existing routers. network intelligence [24]. Finally, in some cases the de- In essence, IRSCP subsumes the control plane of an ISP's fault BGP decision process is simply at odds with provider network by replacing the distributed BGP decision pro- and/or customer goals. For example, using IGP cost as cess of each router in the network with a more flexi- a tie breaker in the decision process can lead to unbal- ble, logically centralized route computation.
    [Show full text]
  • Zebra 2.0 and Lagopus: Newly-Designed Routing Stack On
    Zebra 2.0 and Lagopus: newly-designed routing stack on high-performance packet forwarder Kunihiro Ishiguro∗, Yoshihiro Nakajimay, Masaru Okiz, Hirokazu Takahashiy ∗ Hash-Set, Tokyo, Japan y Nippon Telegraph and Telephone Corporation, Tokyo, Japan z Internet Initiative Japan Inc, Tokyo, Japan e-mail: [email protected], [email protected], [email protected], [email protected] Abstract First GNU Zebra architecture and its issues Zebra 2.0 is the new version of open source networking When we designed the first GNU Zebra, the biggest ambition software which is implemented from scratch. Zebra 2.0 was to make multi-process networking software work. The is designed to supports BGP/OSPF/LDP/RSVP-TE and co- first GNU Zebra is made from a collection of several dae- working with Lagopus as fast packet forwarder with Open- mons that work together to build the routing table. There may Flow API. In this new version of Zebra, it adapts new archi- be several protocol-specific routing daemons and Zebra’s ker- tecture which is mixture of thread model and task completion nel routing manager. Figure 1 shows the architecture of the model to achieve maximum scalability with multi-core CPUs. first GNU Zebra. RIB (Routing Information Base) / FIB (For- Zebra has separate independent configuration manager that warding Information Base) and the interface manager are sep- supports commit/rollback and validation functionality. The configuration manager understand YANG based configuration arated into an isolated process called ’zebra’. All of protocol model so we can easily add a new configuration written in handling is also separated to it’s own process such as ’ripd’, YANG.
    [Show full text]
  • Beyond the Best: Real-Time Non-Invasive Collection of BGP Messages
    Beyond the Best: Real-Time Non-Invasive Collection of BGP Messages Stefano Vissicchio Luca Cittadini Maurizio Pizzonia Luca Vergantini Valerio Mezzapesa Maria Luisa Papagni Dipartimento di Informatica e Automazione, Universita` degli Studi Roma Tre, Rome, Italy fvissicch,ratm,pizzonia,verganti,mezzapes,[email protected] Abstract Despite such a rich set of potential applications, cur- Interdomain routing in the Internet has a large impact rent BGP monitoring practices are quite limited: very of- on network traffic and related economic issues. For this ten, they employ open source BGP daemon implementa- reason, BGP monitoring attracts both academic and in- tions to establish extra BGP peerings with border routers. dustrial research interest. The most common solution for The daemon acts as a route collector, in the sense that collecting BGP routing data is to establish BGP peerings it collects information received via those extra peerings, between border routers and a route collector. dumps it in some format, and stores it for future analy- The downside of this approach is that it only allows ses. For example, this is the approach adopted by Route- us to trace changes of routes selected as best by routers: Views [20] to collect BGP data for the Internet commu- this drawback hinders a wide range of analyses that need nity. Such a practice has two major drawbacks: (i) it is access to all BGP messages received by border routers. only able to collect those routes that have been selected In this paper, we present an effective technique en- as best by the routers that peer with the collector; and abling fast, non-invasive and scalable collection of all (ii) it is only able to collect BGP messages after ingress BGP messages received by border routers.
    [Show full text]
  • Open Source Software for Routing a Look at the Status of Open Source Software for Routing
    APNIC 34 Open Source Software for Routing A look at the status of Open Source Software for Routing Martin Winter OpenSourceRouting.org 1 Who is OpenSourceRouting Quick Overview of what we do and who we are www.opensourcerouting.org ‣ Started late summer 2011 ‣ Focus on improving Quagga ‣ Funded by Companies who like an Open Source Alternative ‣ Non-Profit Organization • Part of ISC (Internet System Consortium) 2 Important reminder: Quagga/Bird/… are not complete routers. They are only the Route Engine. You still need a forwarding plane 3 Why look at Open Source for routing, Why now? Reasons for Open Source Software in Routing 1 Popular Open Source Software Overview of Bird, Quagga, OpenBGPd, Xorp 2 Current Status of Quagga Details on where to consider Quagga, where to avoid it 3 What Open Source Routing is doing What we (OpenSourceRouting.org) do on Quagga 4 How you can help Open Source needs your help. And it will help you. 5 4 Reasons why the time is NOW A few reasons to at least start thinking about Open Source Could be much cheaper. You don’t need all the Money features and all the specialized hardware everywhere. All the current buzzwords. And most of it started SDN, with Open Source – and is designed for it. Does Cloud, .. your vendor provide you with the features for new requirements in time? Your Missing a feature? Need a special feature to distinguish from the competition? You have access Features to the source code. Not just one company is setting the schedule on Support what the fix and when you get the software fix.
    [Show full text]
  • Pipenightdreams Osgcal-Doc Mumudvb Mpg123-Alsa Tbb
    pipenightdreams osgcal-doc mumudvb mpg123-alsa tbb-examples libgammu4-dbg gcc-4.1-doc snort-rules-default davical cutmp3 libevolution5.0-cil aspell-am python-gobject-doc openoffice.org-l10n-mn libc6-xen xserver-xorg trophy-data t38modem pioneers-console libnb-platform10-java libgtkglext1-ruby libboost-wave1.39-dev drgenius bfbtester libchromexvmcpro1 isdnutils-xtools ubuntuone-client openoffice.org2-math openoffice.org-l10n-lt lsb-cxx-ia32 kdeartwork-emoticons-kde4 wmpuzzle trafshow python-plplot lx-gdb link-monitor-applet libscm-dev liblog-agent-logger-perl libccrtp-doc libclass-throwable-perl kde-i18n-csb jack-jconv hamradio-menus coinor-libvol-doc msx-emulator bitbake nabi language-pack-gnome-zh libpaperg popularity-contest xracer-tools xfont-nexus opendrim-lmp-baseserver libvorbisfile-ruby liblinebreak-doc libgfcui-2.0-0c2a-dbg libblacs-mpi-dev dict-freedict-spa-eng blender-ogrexml aspell-da x11-apps openoffice.org-l10n-lv openoffice.org-l10n-nl pnmtopng libodbcinstq1 libhsqldb-java-doc libmono-addins-gui0.2-cil sg3-utils linux-backports-modules-alsa-2.6.31-19-generic yorick-yeti-gsl python-pymssql plasma-widget-cpuload mcpp gpsim-lcd cl-csv libhtml-clean-perl asterisk-dbg apt-dater-dbg libgnome-mag1-dev language-pack-gnome-yo python-crypto svn-autoreleasedeb sugar-terminal-activity mii-diag maria-doc libplexus-component-api-java-doc libhugs-hgl-bundled libchipcard-libgwenhywfar47-plugins libghc6-random-dev freefem3d ezmlm cakephp-scripts aspell-ar ara-byte not+sparc openoffice.org-l10n-nn linux-backports-modules-karmic-generic-pae
    [Show full text]
  • Protecting Routing with RPKI Mark Kosters, ARIN CTO
    Protecting Routing with RPKI Mark Kosters, ARIN CTO @TeamARIN Agenda •Routing, a short •Using ARIN’s RPKI primer components •Operational routing •RPKI Statistics challenges •IRR Status •Do we have a solution? @TeamARIN 1 Core Internet Functions: Routing & DNS •The Internet relies on two critical resources • DNS: Translates domain names to IP addresses and IP addresses to domain names • Routing: Tells us how to get to an IP address •These critical resources are not secure •DNSSEC and RPKI secure these critical resources @TeamARIN 2 Routing – A Primer @TeamARIN 3 Routing Architecture •The Internet uses a two level routing hierarchy: • Interior Gateway (Routing) Protocol - IGP • Exterior Gateway (Routing) Protocol - EGP @TeamARIN 4 Routing Architecture - IGP • Interior Routing Protocols, used by each network to determine how to reach all destinations that lie within the network • Interior Routing protocols maintain the current topology of the network @TeamARIN 5 Routing Architecture - EGP • Exterior Routing Protocol, used to link each component network together into a single whole • Exterior protocols assume that each network is fully interconnected internally @TeamARIN 6 Exterior Routing: BGP •BGP is a large set of bilateral (1:1) routing sessions • A tells B all the destinations (prefixes) that A is capable of reaching • B tells A all the destinations that B is capable of reaching 10.0.0.0/24 192.2.200.0/24 10.1.0.0/16 10.2.0.0/18 A B @TeamARIN 7 Operational Routing Challenges @TeamARIN 8 Focus on Interconnections • Started out as informal
    [Show full text]