Virtually Eliminating Router Bugs
|
|
|
- Charla Black
- 5 years ago
- Views:
Transcription
1 Virtually Eliminating Router Bugs Eric Keller, Minlan Yu, Matt Caesar, Jennifer Rexford Princeton University, UIUC NANOG 46: Philadelphia, PA
2 Dealing with router bugs Internet s complexity implemented in software running on routers Complexity leads to bugs String of high profile vulnerabilities, outages 2
3 Feb. 16, 2009: SuproNet Announced a single prefix to a single provider huge increase in the global rate of updates 10x increase in global instability for an hour 1 misconfiguration tickled 2 bugs (2 vendors) Source: Renesys Misconfiguration: as-path prepend Did not filter AS path Prepending After: len > 255 AS47878 MikroTik bug: no-range check prepended 252 times AS29113 Cisco bug: Long AS paths Notification 3
4 Challenges of router bugs Bugs different from traditional failures Violate protocol, cause cascading outages, need to wait for vendor to repair, some exploitable by attackers Problem is getting worse Increasing demands on routing, vendors allowing 3rd party development, other sources of outage becoming less common 4
5 Building bug-tolerant routers Our approach: run multiple, diverse instances of router software in parallel Instances vote on FIB contents, update messages sent to peers 5
6 Bug-tolerant Router Architecture Protocol daemon Protocol daemon Protocol daemon RIB RIB RIB Hypervisor REPLICA MANAGER FIB VOTER UPDATE VOTER IF 1 IF 2 FIB Hypervisor: Distributes received messages Votes on updates (to FIB or to peer) Maintains replicas (hiding churn) 6
7 Bug-tolerant Router Architecture Protocol daemon Protocol daemon Protocol daemon Update /8 RIB REPLICA MANAGER RIB FIB VOTER RIB UPDATE VOTER Hypervisor IF 1 IF 2 FIB Hypervisor: Distributes received messages Votes on updates (to FIB or to peer) Maintains replicas (hiding churn) 7
8 Bug-tolerant Router Architecture Protocol daemon Protocol daemon Protocol daemon Update /8 RIB REPLICA MANAGER RIB FIB VOTER RIB UPDATE VOTER Hypervisor IF 1 IF 2 FIB /8 IF 2 Hypervisor: Distributes received messages Votes on updates (to FIB or to peer) Maintains replicas (hiding churn) 8
9 Bug-tolerant Router Architecture Protocol daemon Protocol daemon Protocol daemon Update /8 RIB REPLICA MANAGER RIB FIB VOTER RIB UPDATE VOTER Hypervisor IF 1 IF 2 FIB /8 IF 2 Hypervisor: Distributes received messages Votes on updates (to FIB or to peer) Maintains replicas (hiding churn) 9
10 Voting Algorithms Wait-for-consensus: handling transience Output when a majority of instances agree Master-Slave: speeding reaction time Output Master s answer Slaves used for detection Switch to slave on buggy behavior Continuous Majority: hybrid Voting rerun when any instance sends an update 10
11 We did this in the 1970s Yes, it s an old idea applied to routing new opportunities: e.g., small dependence on past, ability to correct mistakes new challenges: e.g., transient behavior may legitimately differ, need fast reaction time Plus, it s not just N-version programming Can also diversify execution environment 11
12 Achieving Diversity If not N-version programming Where does diversity come from? Type of diversity Examples Execution Environment Operating system, memory layout Software Diversity Version (0.98 vs 0.99), implementation (Quagga vs XORP) Data Diversity Configuration, timing of updates/connections Next: How effective are these? 12
13 Achieving Diversity General Diversity (e.g., OS, mem space layout) Not studied here Data Diversity Taxonomized XORP and Quagga bug database Diversity Mechanism Timing/order of messages 39% Configuration Timing/order of connections 12% Bugs avoided (est.) 25% (avoided), 54% (less severe) Selected two from each to reproduce and avoid 13
14 Achieving Diversity Software Diversity Version: static analysis Overlap decreases quickly between versions Only 25% overlap in Quagga and % of bugs in Quagga not in Implementation: small verification Picked 10 from XORP, 10 from Quagga Setup test to trigger bug None were present in other implementation 14
15 Feb 16, 2009: SuproNet Recall: 1 misconfig tickled 2 bugs Bug 1: MikroTik range-check bug version diversity (fixed in latest version) Bug 2: Cisco long AS path bug configuration diversity (an alternate configuration avoids bug) 15
16 Is voting really necessary? Voting adds code (which adds bugs) But, it s relatively simple (functionality and lines of code) Simpler, means easier to verify with static analysis We already have a standby Let s see how many bugs cause crashes x 16
17 Categorizing Faults in Bugzilla DBs Fault (occurrence freq*) Symptom Crash/hang (41%) Add incorrect Link Attr (11%) Prevent Link Startup / Delete existing link (5%) Use wrong link (6%) Add non-existent route (9%) Delete existent route (10%) Fail to advertise route (11%) Incorrect policy (6%) Incorrect logging (1%) Signal sent, non-participation in vote Incorrect during vote Socket error, non-participation, only instance to withdraw Only participant, non-participation, or incorrect in a FIB update Only instance to advertise Only instance to withdraw Non-participation in update Incorrect attr, only instance to advertise or withdraw Not handled * XORP and Quagga bugzilla databases 17
18 Is voting really necessary? Voting adds code (which adds bugs) But, it s relatively simple (functionality and lines of code) Simpler, means easier to verify with static analysis We already have a standby Only 41% cause crash/hang Rest are byzantine 18
19 Is this even possible? Routers already at high CPU utilization Use a better processor (small part of cost) Ride multi-core trend Utilize existing physical redundancy Standby route processor and routers Run instances in background Used to check, not active in each update 19
20 Diverse Replication It is effective Both software and data diversity are effective It is necessary Only 41% of bugs cause a crash/hang Rest cause byzantine faults It is possible Use better (multi-core) CPUs Run in background Existing redundancy 20
21 Prototype Based on Linux with open source routing software (XORP and Quagga) Details can be read about in our paper No router software modification Detect and recover from faults Low complexity 21
22 Other Deployment Scenarios Server-based read-only operation Routers run on server to cross-check Migrate router process upon fault Network-wide deployment Parallel networks instead of parallel instances (enables protocol diversity) Process-level deployment Reduce overhead by sharing RIB 22
23 Conclusions Our design has several benefits First step in building bug-tolerant networks Diverse replication both viable and effective Prototype shows improved robustness to bugs with tolerable additional delay Next step? Looking for a place to deploy anyone? Automate diversity mechanisms 23
24 Questions Read more at: 24
Refactoring Router Software to Minimize Disruption Eric Keller Advisor: Jennifer Rexford
Refactoring Router Software to Minimize Disruption Eric Keller Advisor: Jennifer Rexford Princeton University Final Public Oral - 8/26/2011 User s Perspective of The Internet Documents Videos Photos 2
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 ekeller@princeton.edu {minlanyu, jrex}@cs.princeton.edu
Distributed Systems COMP 212. Lecture 19 Othon Michail
Distributed Systems COMP 212 Lecture 19 Othon Michail Fault Tolerance 2/31 What is a Distributed System? 3/31 Distributed vs Single-machine Systems A key difference: partial failures One component fails
Paxos applied Distributed System. Gang Wu. Spring,2018
Distributed System Gang Wu Spring,2018 Lecture4:Failure& Fault-tolerant Failure is the defining difference between distributed and local programming, so you have to design distributed systems with the
Basic vs. Reliable Multicast
Basic vs. Reliable Multicast Basic multicast does not consider process crashes. Reliable multicast does. So far, we considered the basic versions of ordered multicasts. What about the reliable versions?
Today: Fault Tolerance
Today: Fault Tolerance Agreement in presence of faults Two army problem Byzantine generals problem Reliable communication Distributed commit Two phase commit Three phase commit Paxos Failure recovery Checkpointing
Fault Tolerance. Distributed Systems IT332
Fault Tolerance Distributed Systems IT332 2 Outline Introduction to fault tolerance Reliable Client Server Communication Distributed commit Failure recovery 3 Failures, Due to What? A system is said to
Distributed Systems Fault Tolerance
Distributed Systems Fault Tolerance [] Fault Tolerance. Basic concepts - terminology. Process resilience groups and failure masking 3. Reliable communication reliable client-server communication reliable
A Technique for Reducing BGP Update Announcements through Path Exploration Damping
A Technique for Reducing BGP Update Announcements through Path Exploration Damping Geoff Huston, Mattia Rossi, Grenville Armitage mrossi@swin.edu.au Centre for Advanced Internet Architectures (CAIA) Swinburne
Implementation Issues. Remote-Write Protocols
Implementation Issues Two techniques to implement consistency models Primary-based protocols Assume a primary replica for each data item Primary responsible for coordinating all writes Replicated write
Today: Fault Tolerance. Fault Tolerance
Today: Fault Tolerance Agreement in presence of faults Two army problem Byzantine generals problem Reliable communication Distributed commit Two phase commit Three phase commit Paxos Failure recovery Checkpointing
A Measurement Study of BGP Misconfiguration
A Measurement Study of BGP Misconfiguration Ratul Mahajan, David Wetherall, and Tom Anderson University of Washington Motivation Routing protocols are robust against failures Meaning fail-stop link and
Last Class:Consistency Semantics. Today: More on Consistency
Last Class:Consistency Semantics Consistency models Data-centric consistency models Client-centric consistency models Eventual Consistency and epidemic protocols Lecture 16, page 1 Today: More on Consistency
Today: Fault Tolerance. Replica Management
Today: Fault Tolerance Failure models Agreement in presence of faults Two army problem Byzantine generals problem Reliable communication Distributed commit Two phase commit Three phase commit Failure recovery
Byzantine Fault Tolerance
Byzantine Fault Tolerance CS6450: Distributed Systems Lecture 10 Ryan Stutsman Material taken/derived from Princeton COS-418 materials created by Michael Freedman and Kyle Jamieson at Princeton University.
Software Defined Networking
Software Defined Networking Jennifer Rexford COS 461: Computer Networks Lectures: MW 10-10:50am in Architecture N101 http://www.cs.princeton.edu/courses/archive/spr12/cos461/ The Internet: A Remarkable
Distributed Systems. Fault Tolerance. Paul Krzyzanowski
Distributed Systems Fault Tolerance Paul Krzyzanowski Except as otherwise noted, the content of this presentation is licensed under the Creative Commons Attribution 2.5 License. Faults Deviation from expected
Module 8 Fault Tolerance CS655! 8-1!
Module 8 Fault Tolerance CS655! 8-1! Module 8 - Fault Tolerance CS655! 8-2! Dependability Reliability! A measure of success with which a system conforms to some authoritative specification of its behavior.!
Byzantine Fault Tolerance
Byzantine Fault Tolerance CS 240: Computing Systems and Concurrency Lecture 11 Marco Canini Credits: Michael Freedman and Kyle Jamieson developed much of the original material. So far: Fail-stop failures
BGP Anomaly Detection. Bahaa Al-Musawi PhD candidate Supervisors: Dr. Philip Branch and Prof. Grenville Armitage.
BGP Anomaly Detection Bahaa Al-Musawi PhD candidate Supervisors: Dr. Philip Branch and Prof. Grenville Armitage balmusawi@swin.edu.au Centre for Advanced Internet Architectures (CAIA) Swinburne University
Examination. ANSWERS IP routning på Internet och andra sammansatta nät, DD2491 IP routing in the Internet and other complex networks, DD2491
Examination ANSWERS IP routning på Internet och andra sammansatta nät, DD2491 IP routing in the Internet and other complex networks, DD2491 Date: October 21st 2008 10:00 13:00 a) No help material is allowed
Sweet Little Lies: Fake Topologies for Flexible Routing
Sweet Little Lies: Fake Topologies for Flexible Routing Stefano Vissicchio University of Louvain HotNets 27th October 2014 Joint work with Laurent Vanbever (Princeton) and Jennifer Rexford (Princeton)
Parallel DBs. April 25, 2017
Parallel DBs April 25, 2017 1 Sending Hints Rk B Si Strategy 3: Bloom Filters Node 1 Node 2 2 Sending Hints Rk B Si Strategy 3: Bloom Filters Node 1 with
Parallel Data Types of Parallelism Replication (Multiple copies of the same data) Better throughput for read-only computations Data safety Partitionin
Parallel Data Types of Parallelism Replication (Multiple copies of the same data) Better throughput for read-only computations Data safety Partitioning (Different data at different sites More space Better
R e d u n d a n c y w i t h L i n u x. Kim Hawtin University of Adelaide
Supporting a large network? Less is more! Provide redundancy with Linux; Anycast DNS, Fail-over DHCP, Peering NTP Kim Hawtin University of Adelaide O b j e c t i v e s Why do we need redundancy? The start
Preventing the unnecessary propagation of BGP withdraws
Preventing the unnecessary propagation of BGP withdraws V. Van den Schrieck, P. François, C. Pelsser, O.Bonaventure http://inl.info.ucl.ac.be Networking 2009, May 13th Agenda Introduction Presentation
Replication in Distributed Systems
Replication in Distributed Systems Replication Basics Multiple copies of data kept in different nodes A set of replicas holding copies of a data Nodes can be physically very close or distributed all over
CSE 5306 Distributed Systems
CSE 5306 Distributed Systems Fault Tolerance Jia Rao http://ranger.uta.edu/~jrao/ 1 Failure in Distributed Systems Partial failure Happens when one component of a distributed system fails Often leaves
Today: Fault Tolerance. Failure Masking by Redundancy
Today: Fault Tolerance Agreement in presence of faults Two army problem Byzantine generals problem Reliable communication Distributed commit Two phase commit Three phase commit Failure recovery Checkpointing
CSE 5306 Distributed Systems. Fault Tolerance
CSE 5306 Distributed Systems Fault Tolerance 1 Failure in Distributed Systems Partial failure happens when one component of a distributed system fails often leaves other components unaffected A failure
VMware vsphere Clusters in Security Zones
SOLUTION OVERVIEW VMware vsan VMware vsphere Clusters in Security Zones A security zone, also referred to as a DMZ," is a sub-network that is designed to provide tightly controlled connectivity to an organization
TSW Reliability and Fault Tolerance
TSW Reliability and Fault Tolerance Alexandre David 1.2.05 Credits: some slides by Alan Burns & Andy Wellings. Aims Understand the factors which affect the reliability of a system. Introduce how software
Lecture outline. Internet Routing Security Issues. Previous lecture: Effect of MinRouteAdver Timer. Recap of previous lecture
Lecture outline Internet Routing Security Issues Z. Morley Mao Lecture 3 Jan 14, 2003 Recap of last lecture, any questions? Existing routing security mechanisms - SBGP General threats to routing protocols
BGP Scaling Techniques
BGP Scaling Techniques ISP Workshops These materials are licensed under the Creative Commons Attribution-NonCommercial 4.0 International license (http://creativecommons.org/licenses/by-nc/4.0/) Last updated
FAULT TOLERANCE. Fault Tolerant Systems. Faults Faults (cont d)
Distributed Systems Fö 9/10-1 Distributed Systems Fö 9/10-2 FAULT TOLERANCE 1. Fault Tolerant Systems 2. Faults and Fault Models. Redundancy 4. Time Redundancy and Backward Recovery. Hardware Redundancy
A Hardware-Assisted Virtualization Based Approach on How to Protect the Kernel Space from Malicious Actions
A Hardware-Assisted Virtualization Based Approach on How to Protect the Kernel Space from Malicious Actions Eric Lacombe 1 Ph.D Supervisors: Yves Deswarte and Vincent Nicomette 1 eric.lacombe@security-labs.org
vsan Security Zone Deployment First Published On: Last Updated On:
First Published On: 06-14-2017 Last Updated On: 11-20-2017 1 1. vsan Security Zone Deployment 1.1.Solution Overview Table of Contents 2 1. vsan Security Zone Deployment 3 1.1 Solution Overview VMware vsphere
Enterprise X-Architecture 5th Generation And VMware Virtualization Solutions
Steve Sue VMware PSE June-8 th -2010 Enterprise X-Architecture 5th Generation And VMware Virtualization Solutions 2010 IBM Corporation Virtualization Spending Priority Goldman Sachs 2010 Key Tech Trends
Running A Highly Scaled Registry DNS Platform. ICANN 55 Tech Day Anycast Panel Chris Griffiths -
ICANN 55 Tech Day Anycast Panel Chris Griffiths - chris.griffiths@nominet.uk 1 About Nominet WE ARE AN INTERNATIONAL INTERNET COMPANY DELIVERING PUBLIC BENEFIT As an operator of one of the largest Registries
Viewstamped Replication to Practical Byzantine Fault Tolerance. Pradipta De
Viewstamped Replication to Practical Byzantine Fault Tolerance Pradipta De pradipta.de@sunykorea.ac.kr ViewStamped Replication: Basics What does VR solve? VR supports replicated service Abstraction is
Basic concepts in fault tolerance Masking failure by redundancy Process resilience Reliable communication. Distributed commit.
Basic concepts in fault tolerance Masking failure by redundancy Process resilience Reliable communication One-one communication One-many communication Distributed commit Two phase commit Failure recovery
Internet Exchanges : Do we need a new Route Server?
Internet Exchanges : Do we need a new Route Server? Euro-IX 24 16th/18th of March 2014 Thomas Mangin Exa Networks/IXLeeds/LINX Whatever a speaker is missing in depth he will compensate for in length Montesquieu
Failure models. Byzantine Fault Tolerance. What can go wrong? Paxos is fail-stop tolerant. BFT model. BFT replication 5/25/18
Failure models Byzantine Fault Tolerance Fail-stop: nodes either execute the protocol correctly or just stop Byzantine failures: nodes can behave in any arbitrary way Send illegal messages, try to trick
Improving DNS Security and Resiliency. Carlos Vicente Network Startup Resource Center
Improving DNS Security and Resiliency Carlos Vicente Network Startup Resource Center Threats to DNS Server crashes Server compromise Denial of service attacks Amplification attacks Cache poisoning Targeted
BGP Route Stability. Alexander Asimov Highload Lab
BGP Route Stability Alexander Asimov Highload Lab Research history 9-2010 study of BGP convergence process: Imitation testbed (BGPC + PRIME); BGP convergence time equations; Experiments
Practical Byzantine Fault Tolerance Consensus and A Simple Distributed Ledger Application Hao Xu Muyun Chen Xin Li
Practical Byzantine Fault Tolerance Consensus and A Simple Distributed Ledger Application Hao Xu Muyun Chen Xin Li Abstract Along with cryptocurrencies become a great success known to the world, how to
Overlay Networks. Behnam Momeni Computer Engineering Department Sharif University of Technology
CE443 Computer Networks Overlay Networks Behnam Momeni Computer Engineering Department Sharif University of Technology Acknowledgments: Lecture slides are from Computer networks course thought by Jennifer
Huawei OceanStor ReplicationDirector Software Technical White Paper HUAWEI TECHNOLOGIES CO., LTD. Issue 01. Date
Huawei OceanStor Software Issue 01 Date 2015-01-17 HUAWEI TECHNOLOGIES CO., LTD. 2015. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without
CS4450. Computer Networks: Architecture and Protocols. Lecture 15 BGP. Spring 2018 Rachit Agarwal
CS4450 Computer Networks: Architecture and Protocols Lecture 15 BGP Spring 2018 Rachit Agarwal Autonomous System (AS) or Domain Region of a network under a single administrative entity Border Routers Interior
What s New in VMware vsphere Availability
What s New in VMware vsphere 5.0 - Availability Technical WHITE PAPER v 1.0/Updated June 2011 Table of Contents Introduction.... 3 Management Availability.... 3 Manageability.... 3 Usability.... 4 Application
Fault Tolerance. Basic Concepts
COP 6611 Advanced Operating System Fault Tolerance Chi Zhang czhang@cs.fiu.edu Dependability Includes Availability Run time / total time Basic Concepts Reliability The length of uninterrupted run time
Module 8 - Fault Tolerance
Module 8 - Fault Tolerance Dependability Reliability A measure of success with which a system conforms to some authoritative specification of its behavior. Probability that the system has not experienced
MANRS. Mutually Agreed Norms for Routing Security. Aftab Siddiqui
MANRS Mutually Agreed Norms for Routing Security Aftab Siddiqui siddiqui@isoc.org The Problem A Routing Security Overview 2 Routing Incidents are Increasing In 2017 alone, 14,000 routing outages or attacks
FAULT TOLERANT SYSTEMS
FAULT TOLERANT SYSTEMS http://www.ecs.umass.edu/ece/koren/faulttolerantsystems Part 3 - Resilient Structures Chapter 2 HW Fault Tolerance Part.3.1 M-of-N Systems An M-of-N system consists of N identical
Distributed Route Aggregation (DRAGON)
Distributed Route Aggregation on the GlObal Network (DRAGON) João Luís Sobrinho 1 Laurent Vanbever 2, Franck Le 3, Jennifer Rexford 4 ACM CoNEXT 2014, Sydney 1 Instituto de Telecomunicações, 1 IST Universidade
Redundancy in fault tolerant computing. D. P. Siewiorek R.S. Swarz, Reliable Computer Systems, Prentice Hall, 1992
Redundancy in fault tolerant computing D. P. Siewiorek R.S. Swarz, Reliable Computer Systems, Prentice Hall, 1992 1 Redundancy Fault tolerance computing is based on redundancy HARDWARE REDUNDANCY Physical
NaMeX Route Server HOWTO
NaMeX Route Server HOWTO June 24, 2010 1 Service overview Route servers (RS) are a value-added service that can be offered by IXPs. Actually, the availability of a RS within an IXP is becoming more and
COCONUT: Seamless Scale-out of Network Elements
COCONUT: Seamless Scale-out of Network Elements Soudeh Ghorbani P. Brighten Godfrey University of Illinois at Urbana-Champaign Simple abstractions Firewall Loadbalancer Router Network operating system
Configuring StackWise Virtual
Finding Feature Information, page 1 Restrictions for Cisco StackWise Virtual, page 1 Prerequisites for Cisco StackWise Virtual, page 2 Information About Cisco Stackwise Virtual, page 2 Cisco StackWise
BGP Security. Kevin s Attic for Security Research
Kevin s Attic for Security Research kevinkoo001@gmail.com Table 1. BGP Operation (1): Concept & Topology 2. BGP Operation (2): Message Exchange, Format and Path Decision Algorithm 3. Potential Attacks
Fault Tolerance. Distributed Systems. September 2002
Fault Tolerance Distributed Systems September 2002 Basics A component provides services to clients. To provide services, the component may require the services from other components a component may depend
Availability, Reliability, and Fault Tolerance
Availability, Reliability, and Fault Tolerance Guest Lecture for Software Systems Security Tim Wood Professor Tim Wood - The George Washington University Distributed Systems have Problems Hardware breaks
Mutually Agreed Norms for Routing Security NAME
Mutually Agreed Norms for Routing Security NAME EMAIL The Problem A Routing Security Overview 2 Routing Incidents are Increasing In 2017 alone, 14,000 routing outages or attacks such as hijacking, leaks,
Process groups and message ordering
Process groups and message ordering If processes belong to groups, certain algorithms can be used that depend on group properties membership create ( name ), kill ( name ) join ( name, process ), leave
Distributed Data Infrastructures, Fall 2017, Chapter 2. Jussi Kangasharju
Distributed Data Infrastructures, Fall 2017, Chapter 2 Jussi Kangasharju Chapter Outline Warehouse-scale computing overview Workloads and software infrastructure Failures and repairs Note: Term Warehouse-scale
FAQ. Version: Copyright ImageStream Internet Solutions, Inc., All rights Reserved.
Version: 3434 Copyright 2007-2010 ImageStream Internet Solutions, Inc., All rights Reserved. Table of Contents BGP/FAQ...1 What is BGP?...1 What implementation of BGP do ImageStream routers use?...1 What
Fault Tolerance Part I. CS403/534 Distributed Systems Erkay Savas Sabanci University
Fault Tolerance Part I CS403/534 Distributed Systems Erkay Savas Sabanci University 1 Overview Basic concepts Process resilience Reliable client-server communication Reliable group communication Distributed
Dynamics of Hot-Potato Routing in IP Networks
Dynamics of Hot-Potato Routing in IP Networks Jennifer Rexford AT&T Labs Research http://www.research.att.com/~jrex Joint work with Renata Teixeira (UCSD), Aman Shaikh (AT&T), and Timothy Griffin (Intel)
CS October 2017
Atomic Transactions Transaction An operation composed of a number of discrete steps. Distributed Systems 11. Distributed Commit Protocols All the steps must be completed for the transaction to be committed.
Distributed Systems. 09. State Machine Replication & Virtual Synchrony. Paul Krzyzanowski. Rutgers University. Fall Paul Krzyzanowski
Distributed Systems 09. State Machine Replication & Virtual Synchrony Paul Krzyzanowski Rutgers University Fall 2016 1 State machine replication 2 State machine replication We want high scalability and
CS 4226: Internet Architecture
Software Defined Networking Richard T. B. Ma School of Computing National University of Singapore Material from: Scott Shenker (UC Berkeley), Nick McKeown (Stanford), Jennifer Rexford (Princeton) CS 4226:
Eventual Consistency. Eventual Consistency
Eventual Consistency Many systems: one or few processes perform updates How frequently should these updates be made available to other read-only processes? Examples: DNS: single naming authority per domain
CSE 544 Principles of Database Management Systems. Alvin Cheung Fall 2015 Lecture 14 Distributed Transactions
CSE 544 Principles of Database Management Systems Alvin Cheung Fall 2015 Lecture 14 Distributed Transactions Transactions Main issues: Concurrency control Recovery from failures 2 Distributed Transactions
Recovering from a Crash. Three-Phase Commit
Recovering from a Crash If INIT : abort locally and inform coordinator If Ready, contact another process Q and examine Q s state Lecture 18, page 23 Three-Phase Commit Two phase commit: problem if coordinator
Fault Tolerance Dealing with an imperfect world
Fault Tolerance Dealing with an imperfect world Paul Krzyzanowski Rutgers University September 14, 2012 1 Introduction If we look at the words fault and tolerance, we can define the fault as a malfunction
Consensus and related problems
Consensus and related problems Today l Consensus l Google s Chubby l Paxos for Chubby Consensus and failures How to make process agree on a value after one or more have proposed what the value should be?
Distributed Systems
15-440 Distributed Systems 11 - Fault Tolerance, Logging and Recovery Tuesday, Oct 2 nd, 2018 Logistics Updates P1 Part A checkpoint Part A due: Saturday 10/6 (6-week drop deadline 10/8) *Please WORK hard
Performance Evaluation of The QUAGGA Router
Performance Evaluation of The QUAGGA Router Vincent Omollo, Dr. K. Langat, Dr. S. Musyoki, P. Nyakomita, P. Otieno Department of Telecommunication and Information Engineering, Jomo Kenyatta University
Dynamic Routing: Exploiting HiperSockets and Real Network Devices
Dynamic Routing: Exploiting s and Real Network Devices Session 8447 Jay Brenneman rjbrenn@us.ibm.com Exploiting s and Real Network Devices Session 8447 Trademarks The following are trademarks of the International
RTRlib. An Open-Source Library in C for RPKI-based Prefix Origin Validation. Matthias Wählisch, Fabian Holler, Thomas C. Schmidt, Jochen H.
RTRlib An Open-Source Library in C for RPKI-based Prefix Origin Validation Matthias Wählisch, Fabian Holler, Thomas C. Schmidt, Jochen H. Schiller m.waehlisch@fu-berlin.de schmidt@informatik.haw-hamburg.de
Distributed Systems COMP 212. Revision 2 Othon Michail
Distributed Systems COMP 212 Revision 2 Othon Michail Synchronisation 2/55 How would Lamport s algorithm synchronise the clocks in the following scenario? 3/55 How would Lamport s algorithm synchronise
Towards Recoverable Hybrid Byzantine Consensus
Towards Recoverable Hybrid Byzantine Consensus Hans P. Reiser 1, Rüdiger Kapitza 2 1 University of Lisboa, Portugal 2 University of Erlangen-Nürnberg, Germany September 22, 2009 Overview 1 Background Why?
Distributed Systems 24. Fault Tolerance
Distributed Systems 24. Fault Tolerance Paul Krzyzanowski pxk@cs.rutgers.edu 1 Faults Deviation from expected behavior Due to a variety of factors: Hardware failure Software bugs Operator errors Network
Fault Tolerance. Distributed Software Systems. Definitions
Fault Tolerance Distributed Software Systems Definitions Availability: probability the system operates correctly at any given moment Reliability: ability to run correctly for a long interval of time Safety:
IPv6 Module 4 OSPF to IS-IS for IPv6
IPv6 Module 4 OSPF to IS-IS for IPv6 Objective: To migrate the OSPF version of Module 1 (running IPv4) to using IS-IS as part of an IPv6 migration strategy. OSPF will be completely removed once the migration
RFC2547 Convergence Characterization and Optimization
RFC2547 Convergence Characterization and Optimization Clarence Filsfils cf@cisco.com Session Number 1 RFC2547 Convergence - Requirement 90%: Typical requirement:
Data Consistency and Blockchain. Bei Chun Zhou (BlockChainZ)
Data Consistency and Blockchain Bei Chun Zhou (BlockChainZ) beichunz@cn.ibm.com 1 Data Consistency Point-in-time consistency Transaction consistency Application consistency 2 Strong Consistency ACID Atomicity.
Avi Freedman Chief Network Scientist, Akamai Chief Network Architect, FastNet
Avi Freedman Chief Network Scientist, Akamai Chief Network Architect, FastNet Do we spend enough energy worrying about security, vs. scalability and reliability? Proposing some thought topics; lab and
Cisco 4000 Series Integrated Services Routers: Architecture for Branch-Office Agility
White Paper Cisco 4000 Series Integrated Services Routers: Architecture for Branch-Office Agility The Cisco 4000 Series Integrated Services Routers (ISRs) are designed for distributed organizations with
UNDERSTANDING CONVERGENCE IN MPLS VPN NETWORKS. Mukhtiar A. Shaikh Moiz Moizuddin
UNDERSTANDING CONVERGENCE IN MPLS VPN NETWORKS Mukhtiar A. Shaikh (mshaikh@cisco.com) Moiz Moizuddin (mmoizudd@cisco.com) 1 Agenda Introduction Convergence Definition Expected (Theoretical) Convergence
DDoS made easy. IP reflection attacks for fun and profit. Gert Döring, SpaceNet AG, München. DECIX/ECO security event,
DDoS made easy IP reflection attacks for fun and profit Gert Döring, SpaceNet AG, München DECIX/ECO security event, 04.12.14, Frankfurt Agenda what are IP reflection attacks? why are they so effective
The Curious Incident of 7 Nov 2011
The Curious Incident of 7 Nov 2011 James Cowie Andrew Hobgood Rajeev Meharwal APRICOT 2012, New Delhi Presentation Overview Remembering November 7th 2011 1. Initial event review: what it wasn t 2. Impairment
Basic Concepts. Network Management. Spring Bahador Bakhshi CE & IT Department, Amirkabir University of Technology
Basic Concepts Network Management Spring 2018 Bahador Bakhshi CE & IT Department, Amirkabir University of Technology This presentation is based on the slides listed in references. Outline Introduction:
Understanding BGP Miscounfiguration
Understanding Archana P Student of Department of Electrical & Computer Engineering Missouri University of Science and Technology appgqb@mst.edu 16 Feb 2017 Introduction Background Misconfiguration Outline
Designing and Evaluating a Distributed Computing Language Runtime. Christopher Meiklejohn Université catholique de Louvain, Belgium
Designing and Evaluating a Distributed Computing Language Runtime Christopher Meiklejohn (@cmeik) Université catholique de Louvain, Belgium R A R B R A set() R B R A set() set(2) 2 R B set(3) 3 set() set(2)
Consensus in Distributed Systems. Jeff Chase Duke University
Consensus in Distributed Systems Jeff Chase Duke University Consensus P 1 P 1 v 1 d 1 Unreliable multicast P 2 P 3 Consensus algorithm P 2 P 3 v 2 Step 1 Propose. v 3 d 2 Step 2 Decide. d 3 Generalizes
CSCD 433/533 Network Programming Fall Lecture 14 Global Address Space Autonomous Systems, BGP Protocol Routing
CSCD 433/533 Network Programming Fall 2012 Lecture 14 Global Address Space Autonomous Systems, BGP Protocol Routing 1 Topics Interdomain Routing BGP Interdomain Routing Benefits vs. Link State Routing
Routing Security DDoS and Route Hijacks. Merike Kaeo CEO, Double Shot Security
Routing Security DDoS and Route Hijacks Merike Kaeo CEO, Double Shot Security merike@doubleshotsecurity.com DISCUSSION POINTS Understanding The Growing Complexity DDoS Attack Trends Packet Filters and
Floodless in SEATTLE: A Scalable Ethernet Architecture for Large Enterprises
Floodless in SEATTLE: A Scalable Ethernet Architecture for Large Enterprises Full paper available at http://www.cs.princeton.edu/~chkim Changhoon Kim, Matthew Caesar, and Jennifer Rexford Outline of Today