Towards Loop-Free Forwarding of Anonymous Internet Datagrams That Enforce Provenance

Total Page:16

File Type:pdf, Size:1020Kb

Towards Loop-Free Forwarding of Anonymous Internet Datagrams That Enforce Provenance Towards Loop-Free Forwarding of Anonymous Internet Datagrams that Enforce Provenance J.J. Garcia-Luna-Aceves1;2 1Department of Computer Engineering, University of California, Santa Cruz, CA 95064 2Palo Alto Research Center, Palo Alto, CA 94304 Email: [email protected] Abstract—The way in which addressing and forwarding are Internet datagram specifies the source address of the datagram implemented in the Internet constitutes one of its biggest privacy independently of any forwarding mechanism and end nodes and security challenges. The fact that source addresses in Internet are allowed to specify IP source addresses. datagrams cannot be trusted makes the IP Internet inherently vulnerable to DoS and DDoS attacks. The Internet forwarding Because of the algorithms used to assign IP addresses to plane is open to attacks to the privacy of datagram sources, be- entities and write source addresses into Internet datagrams, cause source addresses in Internet datagrams have global scope. the source address of an Internet datagram fails to convey The fact an Internet datagrams are forwarded based solely on the its provenance correctly. The recipient of an Internet data- destination addresses stated in datagram headers and the next gram is unable to authenticate the claimed IP address of the hops stored in the forwarding information bases (FIB) of relaying routers allows Internet datagrams to traverse loops, which wastes source of the datagram based solely on the basic operation resources and leaves the Internet open to further attacks. We of the forwarding plane of the IP Internet. The receivers of introduce PEAR (Provenance Enforcement through Addressing Internet datagrams are forced to use additional mechanisms and Routing), a new approach for addressing and forwarding and information to cope with the fact that a source address of Internet datagrams that enables anonymous forwarding of need not denote the valid provenance of an Internet datagram. Internet datagrams, eliminates many of the existing DDoS attacks on the IP Internet, and prevents Internet datagrams from looping, Furthermore, these mechanisms are far more complex than even in the presence of routing-table loops. the simple mechanism used by sources of Internet datagrams to state the origins of datagrams. In addition, IP addresses are globally unique and assigned on a long-term basis, which I. INTRODUCTION makes it easier for attackers to plan and mount attacks. This One of the biggest challenges facing the future of the constitutes a major vulnerability to DDoS attacks in the current Internet is that its vulnerabilities to DoS and DDoS attacks are Internet architecture. inherent in the algorithms used in the Internet to: (a) assign In addition to the above, a router forwards an Internet addresses to hosts, routers, and devices; (b) include source datagram to its next hop based solely on the destination addresses in Internet datagrams; (c) map addresses to routes; address stated in the datagram and the next hop listed in (d) bind names to locations in the Internet; and (e) forward its forwarding information base (FIB). This is a problem in Internet datagrams. the presence of routing-table loops, because it is possible for In theory, the goal of assigning Internet Protocol (IP) ad- Internet datagrams to traverse loops. The only approach used dresses to entities and including the source and destination IP today is to include a time-to-live (TTL) field in the datagram address in each datagram is to have system-friendly identifiers header that is decremented at each hop of the path traversed that: state the origin and destination of Internet datagrams by the datagram, and to drop an Internet datagram after the based on topological locations where content, services, or TTL value reaches zero. arXiv:1612.05998v1 [cs.NI] 18 Dec 2016 devices are made available; and can be matched efficiently The contribution of this paper is to present a set of algo- against stored information by routers and end systems. How- rithms that we call PEAR (Provenance Enforcement through ever, an IP address simply denotes the point of attachment Addressing and Routing), and which prevent Internet data- of a host or router to a network with a given IP address grams from traversing forwarding loops, makes the identity of range, without any topological information other than the the origin of an Internet datagram anonymous to the rest of the aggregation of IP addresses. Furthermore, IP addresses are Internet, and enforces the provenance of an Internet datagram. assigned to entities independently of the establishment of Section II summarizes current defenses against DDoS flood- routes to services, content, devices, groups, or any entity in ing attacks. The main objective of this review of prior work is general. As a result, routing protocols (e.g., OSPF, BGP) and to point out that defending against large DDoS flooding attacks directory services (e.g., DNS) map names used to denote is virtually impossible without changing the basic algorithms entities (e.g., domain names) to names that denote points of used for the allocation of addresses to Internet datagrams, attachment to networks (IP addresses). In addition to this, the mapping of addresses to routes and connections, and the Internet surrenders any control of the allocation of source the protection of information carried in Internet datagrams. IP addresses to Internet datagrams, because the origin of an Currently, attackers spend far less energy and time mounting attacks than their targets spend defending against them. in an attempt to detect flow anomalies. The key limitation Section III introduces a simple approach to ensure that of defense approaches based on detection is that they must Internet datagrams never loop, even when routing tables con- rely on a number of assumptions regarding the behavior of tain long-term or short-term routing-table loops. The approach legitimate users, and attackers can adopt countermeasures to operates by having the FIB entry for an address prefix state evade detection. Some DoS attacks can be detected, given that the next hop and the hop-count distance to the prefix, and only a few computer systems are attackers and compromised by using the TTL filed of a datagram to enforce an ordering system must behave differently than benign users to exhaust constraint ensuring that a router can forward a datagram only the resources of their targets. However, the problem is far more to a next hop that is strictly closer to the intended destination. difficult for DDoS attacks, which involve many compromised Section IV introduces a receiver-initiated address allocation hosts that can mimic legitimate users and need not change the algorithm, a simple address swapping function, and an on- normal pattern of protocol traffic to be effective. demand routing algorithm operating in the data plane, which Prior approaches for the identification of attack sources together ensure that the origins of Internet datagrams remain have focused on tracing the origins of attacks by explicit anonymous to any routers processing the datagram, and that signaling or marking datagrams with the paths they traverse anonymous sources of datagrams can receive traffic from (e.g., [9], [31], [33], [34], [35], [41], [42]). Some path mark- public destinations over the reverse paths traveled by their ing techniques have also been combined with filtering. The anonymous datagrams. main limitations of these approaches include that: it may be difficult to infer the attack paths in large DDoS attacks; some II. CURRENT DEFENSES AGAINST DDOSATTACKS approaches can consume considerable storage, processing, and The methods used to launch DDoS attacks today consist communication overhead; some path markings are not entirely of: (a) sending malformed packets to the victims to confuse unique; and tracebacks and markings become useful only after protocols or applications; (b) disrupting the connectivity of the attacks have consumed network resources and have reached legitimate users by exhausting bandwidth, router processing their targets. Similarly, prior approaches aimed at filtering capacity, or network resources; and (c) disrupting services Internet datagrams with spoofed IP addresses are only partially to legitimate users by exhausting the resources of servers effective, because they change router behavior to enact filtering (sockets, CPU, memory, or I/O bandwidth). We address DDoS without changing the way in which IP source addresses are flooding attacks aimed at disrupting the connectivity and assigned to Internet datagrams [5], [13], [18], [22], [25], [28], services offered to legitimate users. Four types of defenses or the fact that datagram forwarding is independent of the against these attacks have been proposed to date [3], [12], distances to address prefixes stated in routing tables. [26], [30], [37]: Attack prevention, which aims at stopping Approaches that introduce additional information to denote attacks before they reach their targets; attack detection, which the provenance of a datagram are difficult to implement and attempts to identify the existence of attacks when they occur; cannot be deployed at Internet scale, because they require attack source identification, which tries to locate the source public key infrastructure (PKI) support. For example, HIP [27] of the attack independently of the information contained in requires a PKI that is globally deployed to prevent attackers packets used in the attack; and attack reaction, which aims at from simply minting unlimited numbers of host identifiers eliminating or minimizing the impact of attacks. used in HIP. AIP [4] on the other hand assumes a flat The attack prevention approaches proposed to date focus on addressing space that cannot be applied at Internet scale, is routers filtering IP datagrams with spoofed source IP addresses vulnerable to malicious hosts creating unlimited numbers of (e.g., [5], [13], [18], [22], [25], [28]), or routers adding prove- EIDs, and does not offer an efficient way to recovering from nance information to IP datagrams The limitations of existing compromised private keys corresponding to the AIP addresses packet-filtering approaches are that: (a) existing filters provide of hosts or accountability domains.
Recommended publications
  • REDDIG II – Computer Networking Training
    REDDIG II – Computer Networking Training JM SANCHEZ / PH RASSAT - 20/06/2012 IP Addressing and Subnetting Invierno 2011 | Capacitacion en fabrica - CORPAC IP Addressing and Subnetting IP Addresses An IP address is an address used to uniquely identify a device on an IP network. The address is made up of 32 binary bits which can be divisible into a network portion and host portion with the help of a subnet mask. 32 binary bits are broken into four octets (1 octet = 8 bits) Dotted decimal format (for example, 172.16.254.1) REDDIG II | Network Course | Module 2 | 3 IP Addressing and Subnetting Binary and Decimal Conversion REDDIG II | Network Course | Module 2 | 4 IP Addressing and Subnetting IP Address Classes • IP classes are used to assist in assigning IP addresses to networks with different size requirements. • Classful addressing: REDDIG II | Network Course | Module 2 | 5 IP Addressing and Subnetting Private Address Range • Private IP addresses provide an entirely separate set of addresses that still allow access on a network but without taking up a public IP address space. • Private addresses are not allowed to be routed out to the Internet, so devices using private addresses cannot communicate directly with devices on the Internet. REDDIG II | Network Course | Module 2 | 6 IP Addressing and Subnetting Network Masks • Distinguishes which portion of the address identifies the network and which portion of the address identifies the node. • Default masks: Class A: 255.0.0.0 Class B: 255.255.0.0 Class C: 255.255.255.0 • Once you have the address and the mask represented in binary, then identification of the network and host ID is easier.
    [Show full text]
  • A Survey on Data Plane Programming with P4: Fundamentals, Advances, and Applied Research
    A Survey on Data Plane Programming with P4: Fundamentals, Advances, and Applied Research Frederik Hausera, Marco Häberlea, Daniel Merlinga, Steffen Lindnera, Vladimir Gurevichb, Florian Zeigerc, Reinhard Frankc, Michael Mentha aUniversity of Tuebingen, Department of Computer Science, Chair of Communication Networks, Tuebingen, Germany bIntel, Barefoot Division (BXD), United States of America cSiemens AG, Corporate Technology, Munich, Germany Abstract Programmable data planes allow users to define their own data plane algorithms for network devices including appropriate data plane application programming interfaces (APIs) which may be leveraged by user-defined software-defined net- working (SDN) control. This offers great flexibility for network customization, be it for specialized, commercial appliances, e.g., in 5G or data center networks, or for rapid prototyping in industrial and academic research. Programming protocol-independent packet processors (P4) has emerged as the currently most widespread abstraction, programming language, and concept for data plane pro- gramming. It is developed and standardized by an open community, and it is supported by various software and hardware platforms. In the first part of this paper we give a tutorial of data plane programming models, the P4 programming language, architectures, compilers, targets, and data plane APIs. We also consider research efforts to advance P4 technology. In the second part, we categorize a large body of literature of P4-based applied research into different research domains, summarize the contributions of these papers, and extract prototypes, target platforms, and source code availability. For each research domain, we analyze how the reviewed works benefit from P4’s core features. Finally, we discuss potential next steps based on our findings.
    [Show full text]
  • A CAM-Based, High-Performance Classifier-Scheduler for a Video
    A CAM-BASED, HIGH-PERFORMA NCE CLASSIFIER-SCHEDULER FOR A VIDEO NETWORK PROCESSOR Srivamsi Tarigopula Thesis Prepared for the Degree of MASTER OF SCIENCE UNIVERSITY OF NORTH TEXAS May 2008 APPROVED: Saraju P. Mohanty, Major Professor Elias Kougianos, Committee Member Murali Varanasi, Committee Member Krishna Kavi, Chair of the Department of Computer Science and Engineering Oscar Garcia, Dean of the College of Engineering Sandra L. Terrell, Dean of the Robert B. Tarigopula, Srivamsi. A CAM-based, high-performance classifier-scheduler for a video network processor. Master of Science (Computer Engineering), May 2007, 82 pp., 3 tables, 24 figures, references, 67 titles. Classification and scheduling are key functionalities of a network processor. Network processors are equipped with application specific integrated circuits (ASIC), so that as IP (Internet Protocol) packets arrive, they can be processed directly without using the central processing unit. A new network processor is proposed called the video network processor (VNP) for real time broadcasting of video streams for IP television (IPTV). This thesis explores the challenge in designing a combined classification and scheduling module for a VNP. I propose and design the classifier-scheduler module which will classify and schedule data for VNP. The proposed module discriminates between IP packets and video packets. The video packets are further processed for digital rights management (DRM). IP packets which carry regular traffic will traverse without any modification. Basic architecture of VNP and architecture of classifier- scheduler module based on content addressable memory (CAM) and random access memory (RAM) has been proposed. The module has been designed and simulated in Xilinx 9.1i; is built in ISE simulator with a throughput of 1.79 Mbps and a maximum working frequency of 111.89 MHz at a power dissipation of 33.6mW.
    [Show full text]
  • Decentralized Modular Router Architectures
    DECENTRALIZED MODULAR ROUTER ARCHITECTURES Doctoral Thesis Markus Hidell Laboratory for Communication Networks School of Electrical Engineering KTH, Royal Institute of Technology Stockholm 2006 Decentralized Modular Router Architectures A dissertation submitted to the Royal Institute of Technology (KTH) in partial fulfillment of the requirements for the Doctor of Philosophy degree. Akademisk avhandling som med tillstånd av Kungliga Tekniska Högskolan framlägges till offentlig granskning för avläggande av teknologie doktorsexamen fredagen den 22 september 2006 i Salongen, KTHB, KTH, Stockholm. © Markus Hidell, 2006 Royal Institute of Technology (KTH) School of Electrical Engineering Laboratory for Communication Networks SE-100 44 Stockholm Sweden TRITA-EE 2006:036 ISSN 1653-5146 ISRN KTH/EE—06/036—SE ISBN 91-7178-424-1 Printed by Universitetsservice US-AB, Stockholm 2006 ABSTRACT The Internet grows extremely fast in terms of number of users and traffic volume, as well as in the number of services that must be supported. This development results in new requirements on routers—the main building blocks of the Internet. Existing router designs suffer from architectural limitations that make it difficult to meet future requirements, and the purpose of this thesis is to explore new ways of building routers. We take the approach to investigate distributed and modular router designs, where routers are composed of multiple modules that can be mapped onto different processing elements. The modules communicate through open well-defined interfaces over an internal network. Our overall hypothesis is that such a combination of modularization and decentralization is a promising way to improve scalability, flexibility, and robustness of Internet routers—properties that will be critical for new generations of routers.
    [Show full text]
  • BGP-Default 108 Local 150000 1500 89395477 3845915191
    Packet Journey Inside ASR 9000 Mike Mikhail, Solutions Architect [email protected] BRKARC-2017 Cisco Spark Questions? Use Cisco Spark to chat with the speaker after the session How 1. Find this session in the Cisco Live Mobile App 2. Click “Join the Discussion” 3. Install Spark or go directly to the space 4. Enter messages/questions in the space Cisco Spark spaces will be cs.co/clus17/#BRKARC-2017 available until July 3, 2017. © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public Abstract • System architecture overview: Control & forwarding paths • Control and exception traffic: Internal handling, forwarding, and security • Transit frame forwarding: L3/L2 unicast/multicast forwarding/replication • MPLS forwarding: Forwarding and L3/L2 service operation in hardware • Troubleshooting: Counters, drops, and packet/frame capture Acknowledgement • Content • Jeff Byzek, Technical Marketing Engineer • Gawel Mikolajczyk, Technical Solutions Architect • David Pothier, Enterprise Architect • Xander Thuijs, Principal Engineer • Mei Zhang, Technical Leader • Review • David Pothier, Enterprise Architect • Matt Breneisen, Solutions Integration Architect • Neel Shah • Xander Thuijs, Principal Engineer BRKARC-2017 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 5 Agenda • System architecture overview: Control & forwarding paths • Control and exception traffic: Internal forwarding, and security • Transit frame forwarding: L3/L2 unicast/multicast in hardware • MPLS operation: Forwarding & service in hardware • Troubleshooting:
    [Show full text]
  • Two Challenges of Software Networking: Name-Based
    Two challenges of software networking : name-based forwarding and table verification Leonardo Linguaglossa To cite this version: Leonardo Linguaglossa. Two challenges of software networking : name-based forwarding and table verification. Networking and Internet Architecture [cs.NI]. Université Sorbonne Paris Cité, 2016. English. NNT : 2016USPCC306. tel-02053721 HAL Id: tel-02053721 https://tel.archives-ouvertes.fr/tel-02053721 Submitted on 1 Mar 2019 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Acknowledgements I would like to express to: everyone: many thanks. • i Contents Acknowledgements i Introduction 1 1 Background 5 1.1 Telecommunication Networks . 5 1.1.1 Circuit switching and packet switching . 6 1.1.2 Computer Networks . 8 1.2 The Internet . 8 1.2.1 The TCP/IP Protocol Stack . 9 1.2.2 Data Plane and Control Plane . 11 1.3 The evolution of the Internet . 12 1.3.1 The behavioral issue . 12 1.3.2 The architectural issue . 13 1.4 Enhancing the Data Plane with ICN . 15 1.4.1 Architecture of NDN . 15 1.4.2 Features of ICN and NDN . 20 1.4.3 Implementation of ICN .
    [Show full text]
  • UPC CUPS Overview Guide, Release 21.24
    Ultra Packet Core CUPS Overview Guide, Release 21.24 First Published: 2021-07-13 Last Modified: 2021-09-21 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 THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
    [Show full text]
  • Contrail Architecture
    White Paper Contrail Architecture 1 Contrail Architecture White Paper Table of Contents Executive Summary ........................................................................................................................................................................................................4 Introduction ........................................................................................................................................................................................................................4 Overview of Contrail .......................................................................................................................................................................................................4 Use Cases ....................................................................................................................................................................................................................4 Contrail SDN Controller and the vRouter ........................................................................................................................................................ 5 Virtual Networks........................................................................................................................................................................................................ 5 Overlay Networking .................................................................................................................................................................................................
    [Show full text]
  • Network Control Plane Synthesis and Verification
    NETWORK CONTROL PLANE SYNTHESIS AND VERIFICATION RYAN ANDREW BECKETT ADISSERTATION PRESENTED TO THE FACULTY OF PRINCETON UNIVERSITY IN CANDIDACY FOR THE DEGREE OF DOCTOR OF PHILOSOPHY RECOMMENDED FOR ACCEPTANCE BY THE DEPARTMENT OF COMPUTER SCIENCE ADVISER:DAVID WALKER SEPTEMBER 2018 © Copyright by Ryan Andrew Beckett, 2018. All rights reserved. Abstract Computer networks have become an integral part of modern infrastructure, and as the world con- tinues to become increasingly interconnected and more devices come online, the importance of networks will only continue to grow. A critical component of networks is a process called routing, whereby the network determines how to move data from point A to point B as changes occur dy- namically (e.g., when new devices connect or equipment fails). Routing is traditionally achieved through the manual configuration of one or more distributed protocols that exchange messages about available routes to different destinations. Manual configuration lets a network operator tune various low-level protocol parameters to accommodate the different economic-, performance-, and robustness-related objectives that they may have for the network. Unfortunately, the low-level na- ture of existing configuration primitives and the scale of modern networks makes it difficult for humans to predict the impact of configuration on all possible runtime behaviors of the network, often resulting in configuration bugs. This dissertation develops two complementary techniques for proactively finding and prevent- ing bugs in configurations. The first technique is verification. Given a collection of router config- urations and a high-level specification of what the network should do (e.g., certain devices should be reachable), verification aims to ensure that the configurations implement this high-level specifi- cation correctly for all possible network behaviors.
    [Show full text]
  • High-Speed and Memory-Efficient Forwarding Engine for Future
    Caesar: High-Speed and Memory-Efficient Forwarding Engine for Future Internet Architecture ? ? Mehrdad Moradi† Feng Qian ‡ Qiang Xu⇥ Z. Morley Mao† Darrell Bethea Michael K. Reiter ? University of Michigan† Indiana University ‡ NEC Labs⇥ University of North Carolina ABSTRACT tion feature enables improved mobility support and multi- In response to the critical challenges of the current Internet homing. The cryptographic aspect facilitates authentication architecture and its protocols, a set of so-called clean slate and authorization of control and data messages. However, designs has been proposed. Common among them is an on the down side, both features require addresses to be in- addressing scheme that separates location and identity with herently long and thus take up significant memory space due self-certifying, flat and non-aggregatable address components. to a lack of hierarchical structure to support aggregation. Each component is long, reaching a few kilobits, and would For instance, in the design of MobilityFirst [9], each address consume an amount of fast memory in data plane devices component can be a few kilobits in size. Not surprisingly, it is (e.g., routers) that is far beyond existing capacities. To expected to have forwarding tables on the order of gigabytes address this challenge, we present Caesar,ahigh-speedand in future Internet architecture designs [21]. Such addressing length-agnostic forwarding engine for future border routers, schemes make the design and implementation of high-speed performing most of the lookups within three fast memory border routers challenging as detailed below. accesses. First, memory provisioning becomes more difficult com- To compress forwarding states, Caesar constructs scalable pared to existing network elements.
    [Show full text]
  • An Expert Packet Walkthrough on the Mx Series 3D
    THIS WEEK: AN EXPERT PACKET WALKTHROUGH ON THE MX SERIES 3D This Week: An Expert Packet Walkthrough on the MX Series 3D provides the curious engineer THIS WEEK: Junos® Networking Technologies with a global view of the short life (a few milliseconds) of packets inside the Juniper Networks MX Series 3D routers. Though their life inside the router may be short, the packets are pro- cessed by an amazing ecosystem of next-generation technology. Written by an independent network troubleshooting expert, this walkthrough is unlike AN EXPERT PACKET WALKTHROUGH ON THE MX SERIES 3D THIS WEEK: AN EXPERT PACKET any other. You’ll learn advanced troubleshooting techniques, and how different traffic flows are managed, not to mention witnessing a Junos CLI performance that will have WALKTHROUGH ON THE you texting yourself various show commands. This book is a testament to one of the most powerful and versatile machines on the MX SERIES 3D planet and the many engineers who created it. Sit back and enjoy a network engineering book as you travel inside the MX Series 3D. “This book is like a high-tech travel guide into the heart and soul of the MX Series 3D. David Roy is going where few people have gone and the troubleshooting discoveries he makes will amaze you. If you use the MX Series 3D, you have to read this book.” Kannan Kothandaraman, Juniper Networks Vice President Product Line Management, Junos Software and MX Edge Routing LEARN SOMETHING NEW ABOUT THE MX SERIES THIS WEEK: Understand the life of unicast, host, and multicast packets in the MX Series 3D hardware.
    [Show full text]
  • Packet Journey Inside ASR 9000
    #CLUS Packet Journey Inside ASR 9000 Mike Mikhail, Solutions Arch [email protected] BRKARC-2017 #CLUS Acknowledgement • Content • Jeff Byzek, Technical Marketing Engineer • Gawel Mikolajczyk, Technical Solutions Architect • David Pothier, Enterprise Architect • Xander Thuijs, Principal Engineer • Mei Zhang, Technical Leader • Review • David Pothier, Enterprise Architect • Matt Breneisen, Solutions Integration Architect • Neel Shah • Xander Thuijs, Principal Engineer #CLUS BRKARC-2017 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 3 #CLUS © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public Cisco Webex Teams Questions? Use Cisco Webex Teams (formerly Cisco Spark) to chat with the speaker after the session How 1 Find this session in the Cisco Events App 2 Click “Join the Discussion” 3 Install Webex Teams or go directly to the team space 4 Enter messages/questions in the team space Webex Teams will be moderated cs.co/ciscolivebot#BRKARC-2017 by the speaker until June 18, 2018. #CLUS © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 5 Agenda System architecture overview: Control & forwarding paths Control and exception traffic: Internal forwarding, and security Transit frame forwarding: L3/L2 unicast/multicast in hardware MPLS operation: Forwarding & service labels in hardware Troubleshooting: Counters, discards, and packet/frame capture #CLUS BRKARC-2017 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 6 Introduction • About me • Mike Mikhail, Solutions Architect, [email protected] • Available at “Meet the Engineer” for 1:1 discussions • Interests: SP platforms, SP technologies, QoS, SDN, NFV • ASR 9000 today • Very popular SP/WAN edge router • High bandwidth Ethernet services platform • Hw forwarding, high density: ~1B pps per LC, >1Tbps/slot • Distributed processing and distributed forwarding • Continued dev, busy roadmap, a wealth of new features David #CLUS BRKARC-2017 © 2018 Cisco and/or its affiliates.
    [Show full text]