DOCSLIB.ORG

Performance Evaluation of an Open-Source Multicast Router

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Performance Evaluation of an Open-Source Multicast Router MASTER’S THESIS Performance Evaluation of an Open-source Multicast Router Murad Ali Master of Science in Internetworking Submission date: June 2010 Industry Supervisor: Sven Storgärds Academic Examiners: Karl-Johan Grinnemo, Björn Pehrson The Royal Institute of Technology School of Information and Communication Technology TRITA-ICT-EX-2010:89 1 Abstract Open-source routing has gained momentum in the last few years due to expensive proprietary network hardware and software. People and organizations want more control on routing hardware and software. Inspired by the success of open-source software, and contributions by researchers and many volunteer developers across the globe, there are two open-source routing stacks in the market which are quite promising in terms of performance and features, namely Quagga and XORP. These routing daemons can run on many different hardware and operating systems, and are free to download and customize according to personal preference. Today, assembling a router from off-the-shelf hardware and open-source software is a matter of a few minute efforts. Nowadays, open-source software has become an integral part of many commercial network products. This thesis presents a performance evaluation study of an open-source multicast router. Open- source routing software is used to build a fully functional, high-performing open-source multicast router. The multicast router is running the XORP (pronounced as Zorp) routing software installed on the Debian Linux operating system. A testbed which consisted of three open-source routers was created, where different performance and operational tests were conducted. The tests mainly concerned the evaluation of the multicast routing functionality of an open-source router in a production-like environment where triple-play services were provided to the customers. Linux Differentiated Services were used to provide quality of service to three different traffic classes. Besides these tests, reliability, router management and interoperability with proprietary routers were also evaluated. 2 Sammanfattning Routing med öppen källkod har fått ett uppsving under de senaste åren, tack vare dyr proprietär hård- och mjukvara för nätverk. Folk och organisationer vill ha bättre kontroll över sin routing i både hård- och mjukvara. Inspirerat av framgångarna med öppen källkod, och med bidrag från forskare och andra frivilliga utvecklare över hela världen, har det kommit fram två lovande programvaror på marknaden vad gäller både prestanda och funktionalitet - Quagga och XORP. Dessa kan i stort sett köras på vilken hårdvara, och under vilket operativsystem som helst. De kan dessutom laddas ned fritt och konfigureras efter eget behag. Det är idag en fråga om några få minuters arbete att bygga en router utgående från hårdvara ” från hyllan” och öppen mjukvara. Det är vanligt förekommande att nätverksprodukter numera använder sig av öppen källkod. Denna avhandling presenterar en utvärderingsstudie av en öppen multicast router bygged på öppen kallkod en fullt fungerande och högpresterande multicast router. Multicast routern kör XORP (uttalas Zorp) som routingprogram och är installerat på en Debian Linux-distribution. En testuppsättning bestående av tre stycken routrar har riggats upp, där man undersöker olika prestanda och funktioner. Testerna inkluderar huvudsakligen utvärdering av multicast routing i en produktionslik miljö för Triple Play-tjänster. Differentiated Services i Linux används för att klassificera och kvalitetsgarantera tjänsterna i tre olika klasser. Förutom dessa tester, har även tillförlitlighet, administrativ hanterbarhet och kompatibilitet med proprietära routrar också utvärderats. 3 Acknowledgements This thesis work would not have been possible without valuable contributions from different people. I am heartily thankful to my industry supervisor, Sven Storgärds; CTO Borderlight AB, whose encouragement, guidance, and support from start to the end of thesis, enabled me to develop an understanding of the subject. Being an expert in the router’s field, Sven gave me insightful and valuable help during the complete thesis project. I owe my deepest gratitude to Prof. Björn Pehrson; the Royal Institute of Technology, for his support and motivation in my study of open-source routers. His guidance started with the CSD course project, and ended with this thesis around open-source multicast routers. Again, I am thankful for your assistance. Special gratitude and thanks to my examiner Associate Prof. Karl-Johan Grinnemo for his guidance and important feedback during my thesis report writing. I would like to give a big thanks to Sten Oscarsson, CEO; Borderlight AB, Uppsala for his support during my thesis in Borderlight. I admire Shobhana Benedicta Benjamin in TV department for her technical assistance during the project. I would like to say thanks to other members and colleagues in Borderlight AB for their help and support during my lab work in the company. Besides this, many thanks go to my friends in KTH and class fellows for their kind support during my study in the university. Last but not the least, I offer bundle of thanks to my parents, wife, brothers/sisters for their kind support and prayers during my master studies in Sweden. 4 Acronyms KTH Kungliga Tekniska Högskolan PIM-SM Protocol Independent Multicast Sparse Mode OSPF Open Shortest Path First version 2 BGP Border Gateway Protocol version 4 IGMP Internet Gateway Management Protocol RP Rendezvous Point IP Internet Protocol IPTV Internet Protocol Television XORP Extensible Open Router Platform PC Personal Computer HDTV High Definition Television RIP Routing Information Protocol STB Set top box HDTV High Definition Television SNMP Simple Network Management Protocol UTP Unshielded Twisted Pair POTS Plain Old Telephone System SIP Session Initiation Protocol CPU Central Processing Unit RAM Random Access Memory 5 List of figures Figure 1 : Throughput Lab Set Up ....................................................................................................... 19 Figure 2: Generic topology of the testbed .......................................................................................... 23 Figure 3: Basic topology setup ............................................................................................................ 25 Figure 4: RP selection using BSR mechanism .................................................................................... 27 Figure 5: Video streaming in testbed ................................................................................................ 28 Figure 6: Live TV streaming in testbed .............................................................................................. 30 6 Table of Contents CHAPTER 1 ............................................................................................................................................. 10 INTRODUCTION ....................................................................................................................................... 10 1.1 OPEN-SOURCE ROUTING ......................................................................................................... 10 1.2 MULTICAST ROUTING OVERVIEW ........................................................................................... 11 1.2.1 IP MULTICASTING........................................................................................................... 11 1.2.2 HISTORY OF IP MULTICAST ............................................................................................ 11 1.2.3 MULTICAST ROUTING PROTOCOLS .................................................................................. 12 1.3 RESEARCH OBJECTIVES ........................................................................................................... 13 1.4 RESEARCH MOTIVATION ......................................................................................................... 13 1.5 METHODOLOGY ...................................................................................................................... 13 1.6 THESIS OUTLINE ..................................................................................................................... 14 CHAPTER 2 ............................................................................................................................................. 15 THE XORP ROUTING PLATFORM AND THE PIM-SM PROTOCOL .............................................................. 15 2.1 XORP ROUTING PLATFORM .................................................................................................... 15 2.2 PIM SPARSE MODE ................................................................................................................. 15 2.3 IGMP ..................................................................................................................................... 16 CHAPTER 3 ............................................................................................................................................. 17 HIGH PERFORMING DEBIAN SERVER AND XORP INSTALLATION ON DEBIAN LINUX SERVER .................. 17 3.1 HIGH PERFORMING HARDWARE FOR DEBIAN LINUX SERVER ................................................... 17 3.2 INSTALLING XORP ON DEBIAN SEVER TO BUILD OPEN-SOURCE MULTICAST ROUTER .............. 17 3.2.1 INSTALLING XORP ON DEBIAN LINUX SERVER ............................................................... 17 3.2.2 RUNNING AND CONFIGURING XORP ..............................................................................
Load more

Recommended publications
  • A Comprehensive Study of Routing Protocols Performance with Topological Changes in the Networks Mohsin Masood Mohamed Abuhelala Prof
    A comprehensive study of Routing Protocols Performance with Topological Changes in the Networks Mohsin Masood Mohamed Abuhelala Prof. Ivan Glesk Electronics & Electrical Electronics & Electrical Electronics & Electrical Engineering Department Engineering Department Engineering Department University of Strathclyde University of Strathclyde University of Strathclyde Glasgow, Scotland, UK Glasgow, Scotland, UK Glasgow, Scotland, UK mohsin.masood mohamed.abuhelala ivan.glesk @strath.ac.uk @strath.ac.uk @strath.ac.uk ABSTRACT different topologies and compare routing protocols, but no In the modern communication networks, where increasing work has been considered about the changing user demands and advance applications become a functionality of these routing protocols with the topology challenging task for handling user traffic. Routing with real-time network limitations. such as topological protocols have got a significant role not only to route user change, network congestions, and so on. Hence without data across the network but also to reduce congestion with considering the topology with different network scenarios less complexity. Dynamic routing protocols such as one cannot fully understand and make right comparison OSPF, RIP and EIGRP were introduced to handle among any routing protocols. different networks with various traffic environments. Each This paper will give a comprehensive literature review of of these protocols has its own routing process which each routing protocol. Such as how each protocol (OSPF, makes it different and versatile from the other. The paper RIP or EIGRP) does convergence activity with any change will focus on presenting the routing process of each in the network. Two experiments are conducted that are protocol and will compare its performance with the other.
    [Show full text]
  • 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]
  • Hotspot Feature for Wi-Fi Clients with RADIUS User Authentication on Digi Transport
    Application Note 56 Hotspot feature for Wi-Fi clients with RADIUS User Authentication on Digi TransPort. Digi Support November 2015 1 Contents 1 Introduction ......................................................................................................................................... 4 1.1 Outline ......................................................................................................................................... 4 1.2 Assumptions ................................................................................................................................ 4 1.3 Corrections .................................................................................................................................. 4 2 Version .................................................................................................................................................5 3 Configuration .......................................................................................................................................5 3.1 Mobile Interface Configuration .....................................................................................................5 3.2 Ethernet Interface Configuration ................................................................................................. 6 3.2.1 ETH 0 Configuration ................................................................................................................. 6 3.2.2 ETH 12 Logical Interface Configuration ....................................................................................
    [Show full text]
  • "Mutually Controlled Routing with Independent Isps"
    Mutually Controlled Routing with Independent ISPs Ratul Mahajan David Wetherall Thomas Anderson Microsoft Research University of Washington University of Washington and Intel Research Abstract – We present , an Internet routing pro- Our intent is to develop an interdomain routing proto- Wiser tocol that enables ISPs to jointly control routing in a way col that addresses these problems at a more basic level. that produces efficient end-to-end paths even when they We aim to allow all ISPs to exert control over all routes act in their own interests. is a simple extension to as large a degree as possible, while still selecting end- Wiser of BGP, uses only existing peering contracts for mone- to-end paths that are of high quality. This is a difficult tary exchange, and can be incrementally deployed. Each problem and there are very few examples of effective me- ISP selects paths in a way that presents a compromise diation in networks, despite competitive interests having between its own considerations and those of other ISPs. long been identified as an important factor [8]. Done over many routes, this allows each ISP to improve While it is not a priori obvious that it is possible to its situation by its own optimization criteria compared to succeed at this goal, our earlier work on Nexit [28] sug- the use of BGP today. We evaluate using a router- gests that efficient paths are, in fact, a feasible outcome of Wiser level prototype and simulation on measured ISP topolo- routing across independent ISPs in realistic network set- gies. We find that, unlike Internet routing today, tings.
    [Show full text]
  • FRR - a New Quagga Fork with a More Open Development
    FRR - A new Quagga fork with a more open development Martin Winter [email protected] 1 What is FRR ? (for the not so technical People) ‣ Open Source (GPLv2+) Routing Stack ‣ Implements RIP, RIPng, OSPF (v2&v3), ISIS, BGP, PIM, LDP ‣ Fork of Quagga ‣ Works on Linux and most BSD based systems ‣ For use in many Clouds as virtual routers, white box vendors and network providers (full routing stack) 2 FRR - Why a new fork? Community Driven Faster Development Open Development Model 3 FRR - Who is behind the Fork? 4 FRR - What’s different? ‣ Methodical vetting of submissions ‣ More automated testing of contributions ‣ Github centered development ‣ Elected Maintainers & Steering Committee ‣ Common Assets held in trust by Linux Foundation 5 FRR – Current Status First stable version (2.0) – out very soon BGP Zebra LDP (new) ‣ Performance & Scale fixes ‣ MPLS Support IPv4/v6 for static ‣ RFC 5036 (LDP Specification) LSPs ‣ AddPath Support ‣ RFC 4447 (Pseudowire Setup and Maintenance using LDP) ‣ Remote-AS internal/external ‣ 32-bit route-tags Support ‣ RFC 4762 – (Virtual Private LAN ‣ Nexthop Tracking Service (VPLS) using LDP) ‣ BGP Hostname support ‣ RFC 5549 (unnumbered) Support ‣ RFC 6720 - The Generalized TTL ‣ Update Groups Security Mechanism (GTSM) for ‣ RFC 5549 (unnumbered) Support LDP ‣ Nexthop tracking ‣ RFC 7552 - Updates to LDP for OSPF V2/V3 IPv6 ‣ 32-bit route-tags ‣ OpenBSD Support restored Others Testing ‣ 32-but route-tags ‣ JSON Support ‣ Dejagnu unittests changed to pytest ‣ RFC 5549 (unnumbered) Support ‣ VRF Lite (Linux VRF device support) for BGP and Zebra ‣ Topology Tests 6 ‣ Snapcraft Packaging FRR - Links ‣ Website (very soon!) • http://www.frrouting.org ‣ Github • http://github.com/freerangerouting/frr.git ‣ Issue Tracker • https://github.com/freerangerouting/frr/issues ‣ New feature list, test results etc (until web is up) • https://github.com/freerangerouting/frr/wiki 7.
    [Show full text]
  • Multiple Internet Connections by Balancing Traffic and Managing Failover with Zeroshell
    Multiple Internet Connections by Balancing Traffic and Managing Failover With Zeroshell The purpose of this document is to describe the creation of a router to access a network that uses multiple Internet connections in order to balance the outgoing LAN demand and to obtain network access redundancy, managing fault situations for one or multiple lines. To reach our objective, we shall use the Net Balancer module by Zeroshell. Lastly, we shall examine the possibility of aggregation (Bonding) of VPN aimed at increasing the bandwidth for point-to-point connection between remote locations via the Internet. Is it really possible to increase the Internet connection bandwidth? The answer to this question is not, "yes, absolutely." It depends on what you mean by increasing the Internet connection bandwidth. In essence, the Net Balancer distributes requests originating from the LAN by round-robin (weighed) policy over multiple Internet gateways. In other words, if at a given point in time there is only one LAN user making only one TCP connection (e.g. he executes only one download from the web), his traffic will flow from a single gateway, thus it would not benefit from balanced connections. Instead, if the LAN is crowded with users, each executing multiple requests at the same time, as a whole, their connections will have access to a higher bandwidth, equal to the sum of the single-access bandwidths. We then conclude that a single connection may never have more bandwidth than what offered by a single link, while multiple simultaneous connections will, on average, altogether have access to a greater bandwidth, which will stretch to the sum of the bandwidths of all the Internet links being balanced.
    [Show full text]
  • Linksys E800 Router User Guide
    User Guide Linksys E800 Linksys E800 Contents Contents Product overview How to find your network on the Internet 14 How to clone a MAC address 15 Package contents 1 How to connect to your corporate office using a VPN 15 Features 1 Back view 2 How to optimize your router for gaming and voice 16 Bottom view 2 How to remotely change your router settings 17 How to enable Voice over IP on your network 18 Setting Up: Basics How to configure UPnP 19 How to create a home network 3 How to use a router as an access point 19 What is a network? 3 How to put your new router behind an existing router 21 How to set up a home network 3 To add your router to an existing router or gateway 21 Where to find more help 3 To share an Internet connection 21 To extend your network 23 How to set up your router 3 How to start Cisco Connect 4 How to expose a device to the Internet 23 How to improve your wireless connection speed 5 How to test your Internet connection speed 5 Improving Security How to connect devices to your network 6 How do I know if my network is secure? 25 How to connect a computer to your network 6 How to connect a printer 8 Network security following a manual setup 25 How to connect other devices 8 How to set up wireless security using Wi-Fi Protected Setup 26 How to change your router’s name and password 10 Wi-Fi Protected Setup activity light 26 Connecting a device using the Wi-Fi Protected Setup button 26 How to connect a device using its Wi-Fi Protected Setup PIN 27 How to connect a device using the router’s Wi-Fi Protected Setup PIN 27
    [Show full text]
  • Openflow: Enabling Innovation in Campus Networks
    OpenFlow: Enabling Innovation in Campus Networks Nick McKeown Tom Anderson Hari Balakrishnan Stanford University University of Washington MIT Guru Parulkar Larry Peterson Jennifer Rexford Stanford University Princeton University Princeton University Scott Shenker Jonathan Turner University of California, Washington University in Berkeley St. Louis This article is an editorial note submitted to CCR. It has NOT been peer reviewed. Authors take full responsibility for this article’s technical content. Comments can be posted through CCR Online. ABSTRACT to experiment with production traffic, which have created an This whitepaper proposes OpenFlow: a way for researchers exceedingly high barrier to entry for new ideas. Today, there to run experimental protocols in the networks they use ev- is almost no practical way to experiment with new network ery day. OpenFlow is based on an Ethernet switch, with protocols (e.g., new routing protocols, or alternatives to IP) an internal flow-table, and a standardized interface to add in sufficiently realistic settings (e.g., at scale carrying real and remove flow entries. Our goal is to encourage network- traffic) to gain the confidence needed for their widespread ing vendors to add OpenFlow to their switch products for deployment. The result is that most new ideas from the net- deployment in college campus backbones and wiring closets. working research community go untried and untested; hence We believe that OpenFlow is a pragmatic compromise: on the commonly held belief that the network infrastructure has one hand, it allows researchers to run experiments on hetero- “ossified”. geneous switches in a uniform way at line-rate and with high Having recognized the problem, the networking commu- port-density; while on the other hand, vendors do not need nity is hard at work developing programmable networks, to expose the internal workings of their switches.
    [Show full text]
  • Well-Known TCP Port Numbers Page 1 of 2
    Webopedia: Well-Known TCP Port Numbers Page 1 of 2 You are in the: Small Business Channel Jump to Website Enter a keyword... ...or choose a category. Go! choose one... Go! Home Term of the Day Well-Known TCP Port New Terms New Links Quick Reference Numbers Did You Know? Search Tool Tech Support In TCP/IP and UDP networks, a port is an endpoint to a logical connection and the way Webopedia Jobs a client program specifies a specific server program on a computer in a network. Some About Us ports have numbers that are preassigned to them by the IANA, and these are known as Link to Us well-known ports (specified in RFC 1700). Port numbers range from 0 to 65536, but Advertising only ports numbers 0 to 1024 are reserved for privileged services and designated as well-known ports. This list of well-known port numbers specifies the port used by the Compare Prices server process as its contact port. Port Number Description Submit a URL 1 TCP Port Service Multiplexer (TCPMUX) Request a Term Report an Error 5 Remote Job Entry (RJE) 7 ECHO 18 Message Send Protocol (MSP) 20 FTP -- Data 21 FTP -- Control Internet News 22 SSH Remote Login Protocol Internet Investing IT 23 Telnet Windows Technology Linux/Open Source 25 Simple Mail Transfer Protocol (SMTP) Developer Interactive Marketing 29 MSG ICP xSP Resources Small Business 37 Time Wireless Internet Downloads 42 Host Name Server (Nameserv) Internet Resources Internet Lists 43 WhoIs International EarthWeb 49 Login Host Protocol (Login) Career Resources 53 Domain Name System (DNS) Search internet.com Advertising
    [Show full text]
  • NBAR2 Standard Protocol Pack 1.0
    NBAR2 Standard Protocol Pack 1.0 Americas Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 527-0883 © 2013 Cisco Systems, Inc. All rights reserved. CONTENTS CHAPTER 1 Release Notes for NBAR2 Standard Protocol Pack 1.0 1 CHAPTER 2 BGP 3 BITTORRENT 6 CITRIX 7 DHCP 8 DIRECTCONNECT 9 DNS 10 EDONKEY 11 EGP 12 EIGRP 13 EXCHANGE 14 FASTTRACK 15 FINGER 16 FTP 17 GNUTELLA 18 GOPHER 19 GRE 20 H323 21 HTTP 22 ICMP 23 IMAP 24 IPINIP 25 IPV6-ICMP 26 IRC 27 KAZAA2 28 KERBEROS 29 L2TP 30 NBAR2 Standard Protocol Pack 1.0 iii Contents LDAP 31 MGCP 32 NETBIOS 33 NETSHOW 34 NFS 35 NNTP 36 NOTES 37 NTP 38 OSPF 39 POP3 40 PPTP 41 PRINTER 42 RIP 43 RTCP 44 RTP 45 RTSP 46 SAP 47 SECURE-FTP 48 SECURE-HTTP 49 SECURE-IMAP 50 SECURE-IRC 51 SECURE-LDAP 52 SECURE-NNTP 53 SECURE-POP3 54 SECURE-TELNET 55 SIP 56 SKINNY 57 SKYPE 58 SMTP 59 SNMP 60 SOCKS 61 SQLNET 62 SQLSERVER 63 SSH 64 STREAMWORK 65 NBAR2 Standard Protocol Pack 1.0 iv Contents SUNRPC 66 SYSLOG 67 TELNET 68 TFTP 69 VDOLIVE 70 WINMX 71 NBAR2 Standard Protocol Pack 1.0 v Contents NBAR2 Standard Protocol Pack 1.0 vi CHAPTER 1 Release Notes for NBAR2 Standard Protocol Pack 1.0 NBAR2 Standard Protocol Pack Overview The Network Based Application Recognition (NBAR2) Standard Protocol Pack 1.0 is provided as the base protocol pack with an unlicensed Cisco image on a device.
    [Show full text]
  • Secure Border Gateway Protocol (S-BGP) — Real World Performance and Deployment Issues
    Secure Border Gateway Protocol (S-BGP) — Real World Performance and Deployment Issues Stephen Kent, Charles Lynn, Joanne Mikkelson, and Karen Seo BBN Technologies Abstract configuration information, or routing databases may be The Border Gateway Protocol (BGP), which is used to modified or replaced illicitly via unauthorized access to distribute routing information between autonomous a router, or to a server from which router software is systems, is an important component of the Internet's downloaded, or via a spoofed distribution channel, etc. routing infrastructure. Secure BGP (S-BGP) addresses Such attacks could result in transmission of fictitious critical BGP vulnerabilities by providing a scalable BGP messages, modification or replay of valid means of verifying the authenticity and authorization of messages, or suppression of valid messages. If BGP control traffic. To facilitate widespread adoption, cryptographic keying material is used to secure BGP S-BGP must avoid introducing undue overhead control traffic, that too may be compromised. We have (processing, bandwidth, storage) and must be developed security enhancements to BGP that address incrementally deployable, i.e., interoperable with BGP. most of these vulnerabilities by providing a secure, To provide a proof of concept demonstration, we scalable system: Secure-BGP (S-BGP) [1,3]. Better developed a prototype implementation of S-BGP and physical, procedural and basic communication security deployed it in DARPA’s CAIRN testbed. Real Internet for BGP routers could address some of these attacks. BGP traffic was fed to the testbed routers via replay of a However, such measures would not counter any of the recorded BGP peering session with an ISP’s BGP many forms of attacks that compromise routers router.
    [Show full text]
  • Virtually Eliminating Router Bugs
    Virtually Eliminating Router Bugs Eric Keller∗ Minlan Yu∗ Matthew Caesar† Jennifer Rexford∗ ∗ Princeton University, Princeton, NJ, USA † UIUC, Urbana, IL, USA [email protected] {minlanyu, jrex}@cs.princeton.edu [email protected] ABSTRACT 1. INTRODUCTION Software bugs in routers lead to network outages, security The Internet is an extremely large and complicated dis- vulnerabilities, and other unexpected behavior. Rather than tributed system. Selecting routes involves computations across simply crashing the router, bugs can violate protocol se- millions of routers spread over vast distances, multiple rout- mantics, rendering traditional failure detection and recovery ing protocols, and highly customizable routing policies. Most techniques ineffective. Handling router bugs is an increas- of the complexity in Internet routing exists in protocols im- ingly important problem as new applications demand higher plemented as software running on routers. These routers availability, and networks become better at dealing with tra- typically run an operating system, and a collection of proto- ditional failures. In this paper, we tailor software and data col daemons which implement the various tasks associated diversity (SDD) to the unique properties of routing proto- with protocol operation. Like any complex software, routing cols, so as to avoid buggy behavior at run time. Our bug- software is prone to implementation errors, or bugs. tolerant router executes multiple diverse instances of routing software, and uses voting to determine the output to publish 1.1 Challenges in dealing with router bugs to the forwarding table, or to advertise to neighbors. We de- sign and implement a router hypervisor that makes this par- The fact that bugs can produce incorrect and unpredictable allelism transparent to other routers, handles fault detection behavior, coupled with the mission-critical nature of Inter- and booting of new router instances, and performs voting in net routers, can produce disastrous results.
    [Show full text]