DOCSLIB.ORG

Two Challenges of Software Networking: Name-Based

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

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 . 22 1.4.4 Challenges . 23 1.5 The SDN approach for an evolvable Network . 25 1.5.1 Architecture . 26 1.5.2 Implementation of SDN . 28 1.5.3 Features of SDN . 30 1.5.4 Challenges . 32 I Data Plane Enhancement 34 2 Introduction to the First Part 35 2.1 Design principles . 38 2.2 Design space . 39 2.3 Architecture . 40 2.4 Methodology and testbed . 41 ii 2.4.1 Methodology . 41 2.4.2 Test equipment . 42 2.4.3 Workload . 44 2.5 Contributions . 45 3 Forwarding module 46 3.1 Description . 47 3.2 Design space . 48 3.2.1 Related work . 48 3.2.2 Algorithm . 50 3.2.3 Data structure . 51 3.3 Forwarding module: design and implementation . 52 3.3.1 Prefix Bloom Filter . 52 3.3.2 Block Expansion . 55 3.3.3 Reducing the number of hashing operations . 56 3.3.4 Hash table design . 57 3.3.5 Caesar extensions . 58 3.3.6 Implementation . 59 3.4 Evaluation . 64 3.4.1 Experimental setting . 64 3.4.2 Performance evaluation . 69 3.4.3 Distributed Processing . 72 3.4.4 GPU Off-load . 73 3.5 Conclusion . 75 4 PIT module 76 4.1 Description . 77 4.2 Design space . 78 4.2.1 Related work . 78 4.2.2 Placement . 80 4.2.3 Data structure . 82 4.2.4 Timer support . 84 4.2.5 Loop detection . 85 4.2.6 Parallel access . 86 4.3 PIT: design and implementation . 87 4.3.1 PIT placement and packet walktrough . 87 4.3.2 Data structure . 88 4.3.3 PIT operations . 89 4.3.4 Timer support . 91 4.3.5 Loop detection with Bloom filter . 91 4.4 Evaluation . 93 4.4.1 Experimental setting . 93 4.4.2 Memory footprint . 95 4.4.3 Throughput without timer . 97 4.4.4 Throughput with timer . 98 4.5 Conclusion . 99 iii Table of symbols 101 II Network Verification 102 5 Introduction to the Second Part 103 5.1 Network Verification . 104 5.2 State of the art . 107 5.3 Contributions . 110 6 Forwarding rule verification through atom computation 112 6.1 Model . 113 6.1.1 Definitions . 114 6.1.2 Header Classes . 115 6.1.3 Set representation . 115 6.1.4 Representation of a collection of sets . 116 6.2 Atoms generated by a collection of sets . 117 6.2.1 Representing atoms by uncovered combinations . 117 6.2.2 Overlapping degree of a collection . 119 6.3 Incremental computation of atoms . 120 6.3.1 Computation of atoms generated by a collection of sets . 120 6.3.2 Application to forwarding loop detection . 127 6.4 Theoretical comparison with related work . 128 6.4.1 Related notion of weak completeness . 130 6.4.2 Lower bound for HSA / NetPlumber . 130 6.4.3 Lower bound for VeriFlow . 131 6.4.4 Linear fragmentation versus overlapping degree . 132 6.5 Conclusion . 133 Table of symbols 135 Conclusion 137 Glossary 142 Bibliography 143 iv Introduction Since the beginning, the Internet changed the lives of network users similarly to what the tele- phone invention did at the beginning of the 20th century. While Internet is affecting users’ habits, it is also increasingly being shaped by network users’ behavior (cf. Background Sec- tion 1.3, page 12). Several new services have been introduced during the past decades (i.e. file sharing, video streaming, cloud computing) to meet users’ expectation. The Internet is not any- more a simple network meant to connect nodes providing few websites access: this influences the network traffic pattern and the users’ network usage. As a consequence, although the Internet infrastructure provides a good best-effort service to exchange information in a point-to-point fashion, this is not the principal need that todays users requests. Current networks necessitate some major architectural changes in order to follow the upcoming requirements, but the expe- rience of the past decades shows that bringing new features to the existing infrastructure may be slow (a well known example is the IPv6 protocol, defined in the late Nineties and slowly spreading only in the last few years). In the current thesis work, we identify two main aspects of the Internet evolution: a “behavioral” aspect, which refers to a change occurred in the way users interact with the network, and a “structural” aspect, related to the evolution problem from an architectural point of view. The behavioral perspective states that there is a mis-match between the usage of the network and the actual functions it provides. While network devices implements the simple primitives of sending and receiving generic packets, users are really interested in different primitives, such as retrieving or consuming content. The structural perspective suggests that the problem of the slow evolution of the Internet infrastructure lies in its architectural design, that has been shown to be hardly upgradeable. On the one hand, to encounter the new network usage, the research community proposed the Named-data networking paradigm (NDN), which brings the content-based functionalities to network devices. On the other hand Software-defined networking (SDN) can be adopted to simplify the architectural evolution and shorten the upgrade-time thanks to its centralized software control plane, at the cost of a higher network complexity that can easily introduce some 1 Introduction 2 bugs. Both NDN and SDN are two novel paradigms which aim to innovate current network’s infrastructure, but despite sharing similar goals, they act at different levels. The rationale behind NDN comes from the observation of current Internet usage. Nowadays, users send emails, use chats and surf the Web no more than sharing multimedia files or watching YouTube videos. Modern Internet is in fact a content network, where users are interested in retrieving and consuming some.
Recommended publications
  • REDDIG II – Computer Networking Training

    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.
  • 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

    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.
  • A CAM-Based, High-Performance Classifier-Scheduler for a Video

    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.
  • Towards Loop-Free Forwarding of Anonymous Internet Datagrams That Enforce Provenance

    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.
  • Decentralized Modular Router Architectures

    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.
  • BGP-Default 108 Local 150000 1500 89395477 3845915191

    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:
  • UPC CUPS Overview Guide, Release 21.24

    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.
  • Contrail Architecture

    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 .................................................................................................................................................................................................
  • Network Control Plane Synthesis and Verification

    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.
  • High-Speed and Memory-Efficient Forwarding Engine for Future

    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.
  • An Expert Packet Walkthrough on the Mx Series 3D

    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.
  • Packet Journey Inside ASR 9000

    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.