Building a Router
•Transferir como PPTX, PDF•
4 gostaram•20,416 visualizações
Start building your own routers on bare-metal hardware using our "Full-Stack" light-weight routing and messaging toolkits
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Building a Router
Semelhante a Building a Router (20)
Último
Último (20)
Building a Router
- 1. Building a Router Hannes Gredler hannes@rtbrick.com Pravin S Bhandarkar pravin@rtbrick.com
- 2. RtBrick positioning Hyper Scale Routing Protocols Bare Metal hardware Full API programmability
- 3. Mission & Vision: Interwork Applications & Network Southbound API Forwarding State, Policy Northbound API Telemetry, Topology Data
- 4. Our view of the network: HYBRID Controller: Southbound API Routing Protocols: IGP, BGP, SR
- 5. • Our Toolkits (=Bricks) are enabler for DevOps models • Accelerated Adoption, rather than building software from scratch • Our Toolkits (=Bricks) are purpose-build for: • Flexibility • Speed of deployment • Eliminate the “old” Network paradigm • No closed-systems, no curated release model • Fast Forward IETF Network Apps (BGP, IS-IS, Segment- Routing …) • Create your own Network Apps by your needs • Or let us customize the Applications for you • Open Source Network Test environment • Leverage our work for acceptance testing RtBrick = acceleration for building network devices
- 6. What Problem does RtBrick solve ? Time to Revenue (TTR) O(months) Development SQA-Test Acceptance- Test Deploy Vendor Service Provider Dev Test Deploy Time to Revenue (TTR) O(days) Vendor & Service Provider
- 8. 1. Database centric / Distributed Data Store bds://local/bgp.neighbor bds://local/isis.a dj bds://local/isis.lsdb.l2 bds://217.160.181.216/bgp.rib-in PUBSUB
- 9. 2. Modular Code IS-IS BGP RSVP LDP Netflow Sflow OSPF Trill STP PIM L3VPN L2VPN Core infra (BDS, IPC, DPKG) IS-IS NetflowSRBGP SR Statically Compiled Monolithic NOS Dynamic Loaded Library Modular NOS
- 10. 3. Open Test, Pull
- 11. 3. Open Test, Push
- 12. 4. Open Hardware / White Boxes • Economy of scale will ultimately render custom-ASICs obsolete • Cost/Bit favorable on Merchant Silicon • FY2016 systems shipping: • 3TBit/s, > 128K FIB entries • 800 Gbit/s, > Full Tables, Large Buffers, MPLS, indirection • Feature Gap gets closed • Cannibalizing Edge Router Business … • RtBrick “Full Stack” makes no Hardware assumptions • Unbounded Configuration Possibilities: • Single Switch, Cluster of Switches, Co-located x86 Rack Servers …. • Large FIBs, Small FIBs, SW-based forwarders & Combos thereof
- 14. • Control plane server • 24 Core Dual Socket Intel XEON 3.3 Ghz • 256 GB RAM • 512 GB SSD for Snapshots for “antifragile” daemon restart • 2 Port 10 GBit/s (Intel XL710) DPDK compatible NIC card SYSTEM LAYOUT 1RU Server LXC M N2N1 etc isis bgp isis bgp. ipv4 bgp. ipv6 fwd conf policy
- 16. PEERING ROUTER
- 17. FWDD PLUGIN ARCHITECTURE Brick daemon "fwdd" on NPU VPP REST APIbackstore CLI Tomahawk Jericho Netlink Brick daemon "fwdd" on Server VPP REST APIbackstore CLI Tomahawk Jericho Netlink
- 18. FORWARDING CAPABILITIES • Forward transit traffic from the NPU • Import / Export ACLs • Punt host path traffic using GRE/MPLS from NPU to server • Dynamic Control Plane Protection on NPU for host traffic • Data plane policies installed on the NPU for transit traffic via firewall filters • Fwdd on NPU-CPU to have: • VPP based software forwarder to interface with backstore • Chipset specific plug-in that programs the ASIC • Bypass NPU-CPU processor for packet processing
- 20. • Three Levels of Routing • BGP (eBGP, iBGP) • IGP (IS-IS) • Fabric Discovery Protocol (=Multi Instance IS-IS, Instance-ID 0xfabd) • Use multi-level route resolution to tie it all together • Three Levels of Forwarding • Inter-domain: IPv4 / IPV6 / MPLS • Intra-domain: MPLS (Segment Routing) • Intra-Fabric: MPLS Segment Routing RECURSIVE ARCHITECTURE
- 22. System Architecture Super Spine router
- 23. LXC Control Board LXC fwd 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 M M N2N1 etc etc isis bgp isis bgp. ipv4 bgp. ipv6 sample fwd conf policy LXC fwd 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 M etc sample LXC fwd 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 M etc sample LXC fwd 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 M etc sample LXC fwd 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 M etc sample LXC fwd 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 M etc sample LXC fwd 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 M etc sample LXC fwd 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 M etc sample • Embedded Control Board • Control Plane hosting control plane, user interface & Policy • Multi linecard switch • OCP 800 (26 Tbit/s) • OCP 1600 (52 Tbits/s) • Linux container (LXC) containing etc, sample, fwd • Fwd: chipset specific adaptation Tomahawk SPINE ROUTER
- 25. • Consumer / Developer License • Consumer: Access to package binaries • Developer: Access to Protocol (BGP, OSPF) code • Full-Stack Developer: Access to Protocol and Infrastructure code • Annual / Perpetual License • Per Node / Enterprise (All you can eat) license • Pay as you grow, vs. one off • Maintenance & Support PROPOSED LICENCING OPTIONS
- 26. WE’LL BE ANSWERING QUESTIONS NOW Q A& THANK YOU FOR YOUR TIME Q & A SESSION
Notas do Editor
- Dear <name>, thanks for giving me the opportunity to present my my upcoming venture called ‘rtbrick’. As the name ‘brick’ implies we want to build a modular, scalable routing software targeted to a disintegrated network market.
- Our mission & vision is to make Application and Networking integration seamless. Up to today it is hardly possible to set a massive amount of networking state from an application. If an Application wants to influence forwarding state or a routing policy one has to go through detours of vendor proprietary command line and scripting interfaces. Too often those proprietary interfaces have upper boundaries on the amount of transactions they can process. – Depending on the vendor and OS being used this can vary from one transaction every 10 seconds to a few 10s of transactions per second. The bottleneck also applies to export of telemetry data like link utilization, delay measurements - using the SNMP and netconf vehicles only a few 10s to 100s of state information may get extracted. This clearly does not work if you want to implement fast feedback loops between applications and the network.
- Our view of the network is that it has to be a hybrid across all layers (overlay and underlay). It is the combination of dynamic routing-protocols and Controller information which make networks manageable and resilient. Dynamic Routing Protocols are a good tool for discovering the topology and bootstrapping the internal network. For the time being, Internet Routing will rely on BGP4 and extensions.
- Companies like Google, FB, Netflix have demonstrated the clear value of DevOps as an organizational model. It improves time-to-revenue in every possible angle. However, many SPs are yet undecided if they want to build up software development expertise due to the perceived high entry cost Hence our core offering is to reduce the cost of running a DEVOPS model - the toolkits that we provide allows rapid feature introduction from development down to an integrated test environment.
- The inherent promise of DEVOPS is to reduce the Time-to-revenue of new network functionality which is today order of months Using our system new network functionality can be developed, tested and rolled-out in a a few days
- Our Offering is build around 4 Principles
- The core of the system is a distributed data store which holds every state in the system. Irrespective if it is interface information, IS-IS adjacencies, BGP RIBs or forwarding tables – every state is stored in the back store. Brick Data Store (BDS) it is a model-driven indexing and data replication vehicle. BDS has been designed for speed and consistency – data insertion can progress as fast as 1M updates per second per CPU core. The back store is configured by defining tables, objects and its attributes akin to a SQL server using a json config file. The back store also allows to quickly locate who is the originator of a an object and generate local replicas of that data for local (in-situ) processing. BDS is fully horizontal scalable, so if there are large tables (like for example RIB-ins) then it can shard the workload across a set of worker processes) all of the shard-ing can happen without changing a single-line of code The database centric design allows us to do all the cool-HA things, like doing live-software upgrades, restart of components without loss of service, etc. – Furthermore this design paradigm greatly minimizes the amount of boiler-plate code that one has to do to develop new networking code.
- Before coming to conclusions about what is broken in the Industries’ prevailing software delivery model, one first has to analyze how software is built, extended, and maintained over time. Assume Vendor A has a working, scalable implementation of a piece of networking software; let’s say a routing protocol. Over time, Service Provider customers, come up with all sorts of enhancement requests; some more useful than others. Usually, the enhancement request gets prototyped first, validated, and then merged back into the main line code. The fundamental problem here, is that it is not possible to de-feature certain functionality once merged. It is not possible to custom-tailor what the customer wants. There is no package manager that allows you to mix and match packages. There is no component that allows you to uninstall certain packages that you do not need. Just ask your networking vendor for the following tailor-made software release: IS-IS, BGP for IPv4 and IPv6, no OSPF. no LDP, no RSVP Not possible? - Reason it is not possible is because things have been constructed as a monolithic system, mostly by just compiling a new feature. Most often, a given feature is intimately linked to the underlying infrastructure (like an in-memory database, or some event queue processor), and, removing it out of the code base, may get to an effort as large as originally developing the feature. In most cases there is no dedication on how to clean things up later. Every added feature will make future feature additions harder. If you just make the number of supported software features large enough, you can extrapolate, that at some point, this will become unmaintainable. At RtBrick we have a small core and all functionality is added using the Debian package manager, All of our App source code get published on GitHub such that App developers can have a look at it.
- An old saying in the SW industry is: show me your testing and integration code and I’ll show you the quality of your code. As such any open-source effort that comes without the accompanying test-environment is futile. At RtBrick we’ll share the test and integration framework together with our devops customers. They way it works is at follows – first a real world network topology, configuration and interface names gets pulled from the live network into a model. Based on that synthesized network model the to-be-rolled-out code gets unit and integrations tested.
- If there is no nuclear blowout, then the code finally gets deployed using the fleet manager. Our Devops customers are encouraged to publish their test-cases on Github, such that we can leverage the network effect in testing and rapidly harden the quality of the shared code.