Flow-Based Network Accounting with Linux

Total Page:16

File Type:pdf, Size:1020Kb

Flow-Based Network Accounting with Linux Flow-based network accounting with Linux Harald Welte netfilter core team / hmw-consulting.de / Astaro AG [email protected] Abstract Once a connection is evicted from the state ta- ble, its accounting relevant data is transferred to userspace to a special accounting daemon for Many networking scenarios require some form further processing, aggregation and finally stor- of network accounting that goes beyond some age in the accounting log/database. simple packet and byte counters as available from the ‘ifconfig’ output. When people want to do network accouting, the 1 Network accounting past and current Linux kernel didn’t provide them with any reasonable mechanism for doing Network accounting generally describes the so. process of counting and potentially summariz- ing metadata of network traffic. The kind of Network accounting can generally be done in metadata is largely dependant on the particular a number of different ways. The traditional application, but usually includes data such as way is to capture all packets by some userspace numbers of packets, numbers of bytes, source program. Capturing can be done via a num- and destination ip address. ber of mechanisms such as PF_PACKET sock- ets, mmap()ed PF_PACKET, ipt_ULOG, or There are many reasons for doing accounting ip_queue. This userspace program then ana- of networking traffic, among them lyzes the packets and aggregates the result into per-flow data structures. • transfer volume or bandwisth based billing • monitoring of network utilization, band- Whatever mechanism used, this scheme has a width distribution and link usage fundamental performance limitation, since all packets need to be copied and analyzed by a • research, such as distribution of traffic userspace process. among protocols, average packet size, . The author has implemented a different ap- proach, by which the accounting information is 2 Existing accounting solutions for stored in the in-kernel connection tracking table of the ip_conntrack stateful firewall state Linux machine. On all firewalls, that state table has to be kept anyways—the additional overhead in- There are a number of existing packages to do troduced by accounting is minimal. network accounting with Linux. The follow- • 265 • 266 • Flow-based network accounting with Linux ing subsections intend to give a short overview kernel message ring buffer. This mechanism about the most commonly used ones. is called ipt_LOG (or LOG target). Such messages are then further processed by klogd and syslogd, which put them into one or 2.1 nacctd multiple system log files. nacctd also known as net-acct is proba- As ipt_LOG was designed for logging policy bly the oldest known tool for network account- violations and not for accounting, its overhead ing under Linux (also works on other Unix- is significant. Every packet needs to be inter- like operating systems). The author of this pa- preted in-kernel, then printed in ASCII format per has used nacctd as an accounting tool to the kernel message ring buffer, then copied as early as 1995. It was originally developed from klogd to syslogd, and again copied into by Ulrich Callmeier, but apparently abandoned a text file. Even worse, most syslog installa- later on. The development seems to have con- tions are configured to write kernel log mes- tinued in multiple branches, one of them being sages synchronously to disk, avoiding the usual the netacct-mysql1 branch, currently at version write buffering of the block I/O layer and disk 0.79rc2. subsystem. Its principle of operation is to use an AF_ To sum up and anlyze the data, often custom PACKET socket via libpcap in order to cap- perl scripts are used. Those perl scripts have to ture copies of all packets on configurable net- parse the LOG lines, build up a table of flows, work interfaces. It then does TCP/IP header add the packet size fields and finally export the parsing on each packet. Summary information data in the desired format. Due to the inefficient such as port numbers, IP addresses, number of storage format, performance is again wasted at bytes are then stored in an internal table for analyzation time. aggregation of successive packets of the same flow. The table entries are evicted and stored in a human-readable ASCII file. Patches ex- 2.3 ipt_ULOG based (ulogd, ulog-acctd) ist for sending information directly into SQL databases, or saving data in machine-readable data format. The iptables ULOG target is a more effi- cient version of the LOG target described As a pcap-based solution, it suffers from the above. Instead of copying ascii messages via performance penalty of copying every full the kernel ring buffer, it can be configured to packet to userspace. As a packet-based solu- only copies the header of each packet, and tion, it suffers from the penalty of having to in- send those copies in large batches. A special terpret every single packet. userspace process, normally ulogd, receives those partial packet copies and does further in- terpretation. 2.2 ipt_LOG based ulogd2 is intended for logging of security vi- The Linux packet filtering subsystem iptables olations and thus resembles the functionality of offers a way to log policy violations via the LOG. it creates one logfile entry per packet. It 1http://netacct-mysql.gabrovo. 2http://gnumonks.org/projects/ com ulogd 2005 Linux Symposium • 267 supports logging in many formats, such as SQL 2.5 ipt_ACCOUNT (iptaccount) databases or PCAP format. ulog-acctd3 is a hybrid between ulogd ipt_ACCOUNT5 is a special-purpose iptables and nacctd. It replaces the nacctd libp- target developed by Intra2net AG and avail- cap/PF_PACKET based capture with the more able from the netfilter project patch-o-matic-ng efficient ULOG mechanism. repository. It requires kernel patching and is not included in the mainline kernel. Compared to ipt_LOG, ipt_ULOG reduces the amount of copied data and required ker- ipt_ACCOUNT keeps byte counters per IP nel/userspace context switches and thus im- address in a given subnet, up to a ‘/8’ net- proves performance. However, the whole work. Those counters can be read via a special mechanism is still intended for logging of se- iptaccount commandline tool. curity violations. Use for accounting is out of its design. Being limited to local network segments up to ‘/8’ size, and only having per-ip granularity are two limiteations that defeat ipt_ACCOUNT as 2.4 iptables based (ipac-ng) a generich accounting mechainism. It’s highly- optimized, but also special-purpose. Every packet filtering rule in the Linux packet filter (iptables, or even its predecessor 2.6 ntop (including PF_RING) ipchains) has two counters: number of packets and number of bytes matching this par- ticular rule. ntop6 is a network traffic probe to show network usage. It uses libpcap to cap- By carefully placing rules with no target (so- ture the packets, and then aggregates flows in called fallthrough) rules in the packetfilter rule- userspace. On a fundamental level it’s there- set, one can implement an accounting setup, fore similar to what nacctd does. i.e., one rule per customer. From the ntop project, there’s also nProbe, a A number of tools exist to parse the iptables network traffic probe that exports flow based in- command output and summarized the coun- formation in Cisco NETFLOW v5/v9 format. ters. The most commonly used package is It also contains support for the upcoming IETF ipac-ng4. It supports advanced features such IPFIX7 format. as storing accounting data in SQL databases. The approach works quite efficiently for small To increase performance of the probe, the au- PF_RING8 installations (i.e., small number of accounting thor (Luca Deri) has implemented , rules). Therefore, the accounting granularity a new zero-copy mmap()ed implementation for can only be very low. One counter for each 5http://www.intra2net.com/ single port number at any given ip address is opensource/ipt_account/ certainly not applicable. 6http://www.ntop.org/ntop.html 7IP Flow Information Export 3http://alioth.debian.org/ http://www.ietf.org/html.charters/ projects/pkg-ulog-acctd/ ipfix-charter.html 4http://sourceforge.net/ 8http://www.ntop.org/PF_RING. projects/ipac-ng/ html 268 • Flow-based network accounting with Linux packet capture. There is a libpcap compatibil- 3.1 ip_conntrack_acct ity layer on top, so any pcap-using application can benefit from PF_RING. ip_conntrack_acct is how the in-kernel ip_conntrack counters are called. There is PF_RING is a major performance improve- a set of four counters: numbers of packets and ment, please look at the documentation and the bytes for original and reply direction of a given paper published by Luca Deri. connection. However, ntop / nProbe / PF_RING are If you configure a recent (>= 2.6.9) kernel, all packet-based accounting solutions. Every it will prompt you for CONFIG_IP_NF_CT_ packet needs to be analyzed by some userspace ACCT. By enabling this configuration option, process—even if there is no copying involved. the per-connection counters will be added, and Due to PF_RING optimiziation, it is probably the accounting code will be compiled in. as efficient as this approach can get. However, there is still no efficient means of reading out those counters. They can be ac- cessed via cat /proc/net/ip_conntrack, but that’s 3 New ip_conntrack based ac- not a real solution. The kernel iterates over counting all connections and ASCII-formats the data. Also, it is a polling-based mechanism. If the The fundamental idea is to (ab)use the connec- polling interval is too short, connections might tion tracking subsystem of the Linux 2.4.x / get evicted from the state table before their fi- 2.6.x kernel for accounting purposes. There are nal counters are being read. If the interval is too several reasons why this is a good fit: small, performance will suffer.
Recommended publications
  • Ngenius Collector Appliance Scalable, High-Capacity Appliance for Collection of Cisco Netflow and Other Flow Data
    l DATA SHEET l nGenius Collector Appliance Scalable, High-Capacity Appliance for Collection of Cisco NetFlow and Other Flow Data Product Overview HIGHLIGHTS Deployed at key traffic aggregation locations, nGenius® Collectors extend the reach of the nGeniusONE® Service Assurance solution and are used primarily to generate flow‑based • Measure service responsiveness across statistics (metadata) in memory for specific traffic types. This NETSCOUT data source collects the network with up to 500 Cisco IP SLA metadata on IP SLA and IPPING protocols, flow data from NetFlow routers, link‑level statistics, synthetic transaction tests and utilization data from MIB‑II routers. • Scalable collection of up to 2 million Cisco NetFlow, IPFIX, Juniper J-Flow, Huawei® Listening passively on an Ethernet wire, nGenius Collectors examine specific traffic collected NetStream and sFlow flows per minute from flow‑enabled routers and switches (e.g., Cisco® NetFlow, Juniper® J-Flow, sFlow®, ® • Captures and stores Flow datagrams for NetStream ) and from IP SLA test results to generate a variety of statistics. In addition, Collectors historical deep-dive analysis can be configured to capture datagrams from Flow‑enabled routers and analyze them via datagram capture, which allows users to perform in‑depth capture and filtering. • Collects Flow data from up to 5,000 flow‑enabled router or switch interfaces Metrics from nGenius Collectors are retrieved through a managing nGenius for Flows Server per appliance for analysis, enabling display of utilization metrics, quality of service (QoS) breakdowns, and • Supports both IPv4 and IPv6 environments application breakdowns in nGenius for Flows and other tools in the nGeniusONE Service • Purpose-built hardware and virtual Assurance Solution.
    [Show full text]
  • Free and Open Source Software Is Not a “Free for All”: German Court Enforces GPL License Terms
    Free and Open Source Software Is Not A “Free For All”: German Court Enforces GPL License Terms The GNU General Public License, computer programs, and to guarantee version 2 (GPLv2) scores another the same rights to the recipients of court victory for the free and/or open works licensed under the GPLv2. source software (FOSS) community. Although the open-source movement The GPLv2 carries important has been active for nearly two conditions, however, most notably— decades, globally there are only and critical for its viability—that any a handful of cases in which a FOSS distribution of software licensed under license has been reviewed by — let the GPLv2 must be accompanied with alone receive the imprimatur of the “complete corresponding machine- enforceability from — a court. The readable source code” or “a written latest case hails from Germany and offer … to give any third party … a serves to underscore the importance complete machine-readable copy of of proper FOSS-license compliance the corresponding source code”. throughout the software development GPLv2, Sections 3(a) and 3(b). process and supply chain, including During a “Hacking for Compliance the obligation of distributors to Workshop” organized in Berlin in 2012 independently verify FOSS-license by the Free Software Foundation compliance representations from their Europe, the source code package for a suppliers. media player with GNU/Linux-based Welte v. Fantec firmware inside was found not to contain the source code for the Harald Welte, founder of gpl- iptables components. It was also violations.org (a non-profit discovered that the source code for organization aiming at the other device components was not the enforcement of GPL license terms), is same version used to compile the the owner of “netfilter/iptables” firmware’s binary code.
    [Show full text]
  • Open Source Software Notice
    OPEN SOURCE SOFTWARE NOTICE DCS Touch Display Software V2.00.XXX Schüco International KG Karolinenstraße 1-15 33609 Bielefeld OPEN SOURCE SOFTWARE NOTICE Seite 1 von 32 10000507685_02_EN OPEN SOURCE SOFTWARE NOTICE This document contains information about open source software for this product. The rights granted under open source software licenses are granted by the respective right holders. In the event of conflicts between SCHÜCO’S license conditions and the applicable open source licenses, the open source license conditions take precedence over SCHÜCO’S license conditions with regard to the respective open source software. You are allowed to modify SCHÜCO’S proprietary programs and to conduct reverse engineering for the purpose of debugging such modifications, to the extent such programs are linked to libraries licensed under the GNU Lesser General Public License. You are not allowed to distribute information resulting from such reverse engineering or to distribute the modified proprietary programs. The rightholders of the open source software require to refer to the following disclaimer, which shall apply with regard to those rightholders: Warranty Disclaimer THE OPEN SOURCE SOFTWARE IN THIS PRODUCT IS DISTRIBUTED ON AN "AS IS" BASIS AND IN THE HOPE THAT IT WILL BE USEFUL, BUT WITHOUT ANY WARRANTY OF ANY KIND, WITHOUT EVEN THE IMPLIED WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SEE THE APPLICABLE LICENSES FOR MORE DETAILS. OPEN SOURCE SOFTWARE NOTICE Seite 2 von 32 10000507685_02_EN Copyright Notices and License Texts (please see the source code for all details) Software: iptables Copyright notice: Copyright (C) 1989, 1991 Free Software Foundation, Inc. Copyright Google, Inc.
    [Show full text]
  • Beej's Guide to Unix IPC
    Beej's Guide to Unix IPC Brian “Beej Jorgensen” Hall [email protected] Version 1.1.3 December 1, 2015 Copyright © 2015 Brian “Beej Jorgensen” Hall This guide is written in XML using the vim editor on a Slackware Linux box loaded with GNU tools. The cover “art” and diagrams are produced with Inkscape. The XML is converted into HTML and XSL-FO by custom Python scripts. The XSL-FO output is then munged by Apache FOP to produce PDF documents, using Liberation fonts. The toolchain is composed of 100% Free and Open Source Software. Unless otherwise mutually agreed by the parties in writing, the author offers the work as-is and makes no representations or warranties of any kind concerning the work, express, implied, statutory or otherwise, including, without limitation, warranties of title, merchantibility, fitness for a particular purpose, noninfringement, or the absence of latent or other defects, accuracy, or the presence of absence of errors, whether or not discoverable. Except to the extent required by applicable law, in no event will the author be liable to you on any legal theory for any special, incidental, consequential, punitive or exemplary damages arising out of the use of the work, even if the author has been advised of the possibility of such damages. This document is freely distributable under the terms of the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License. See the Copyright and Distribution section for details. Copyright © 2015 Brian “Beej Jorgensen” Hall Contents 1. Intro................................................................................................................................................................1 1.1. Audience 1 1.2. Platform and Compiler 1 1.3.
    [Show full text]
  • Mmap and Dma
    CHAPTER THIRTEEN MMAP AND DMA This chapter delves into the area of Linux memory management, with an emphasis on techniques that are useful to the device driver writer. The material in this chap- ter is somewhat advanced, and not everybody will need a grasp of it. Nonetheless, many tasks can only be done through digging more deeply into the memory man- agement subsystem; it also provides an interesting look into how an important part of the kernel works. The material in this chapter is divided into three sections. The first covers the implementation of the mmap system call, which allows the mapping of device memory directly into a user process’s address space. We then cover the kernel kiobuf mechanism, which provides direct access to user memory from kernel space. The kiobuf system may be used to implement ‘‘raw I/O’’ for certain kinds of devices. The final section covers direct memory access (DMA) I/O operations, which essentially provide peripherals with direct access to system memory. Of course, all of these techniques requir e an understanding of how Linux memory management works, so we start with an overview of that subsystem. Memor y Management in Linux Rather than describing the theory of memory management in operating systems, this section tries to pinpoint the main features of the Linux implementation of the theory. Although you do not need to be a Linux virtual memory guru to imple- ment mmap, a basic overview of how things work is useful. What follows is a fairly lengthy description of the data structures used by the kernel to manage memory.
    [Show full text]
  • An Introduction to Linux IPC
    An introduction to Linux IPC Michael Kerrisk © 2013 linux.conf.au 2013 http://man7.org/ Canberra, Australia [email protected] 2013-01-30 http://lwn.net/ [email protected] man7 .org 1 Goal ● Limited time! ● Get a flavor of main IPC methods man7 .org 2 Me ● Programming on UNIX & Linux since 1987 ● Linux man-pages maintainer ● http://www.kernel.org/doc/man-pages/ ● Kernel + glibc API ● Author of: Further info: http://man7.org/tlpi/ man7 .org 3 You ● Can read a bit of C ● Have a passing familiarity with common syscalls ● fork(), open(), read(), write() man7 .org 4 There’s a lot of IPC ● Pipes ● Shared memory mappings ● FIFOs ● File vs Anonymous ● Cross-memory attach ● Pseudoterminals ● proc_vm_readv() / proc_vm_writev() ● Sockets ● Signals ● Stream vs Datagram (vs Seq. packet) ● Standard, Realtime ● UNIX vs Internet domain ● Eventfd ● POSIX message queues ● Futexes ● POSIX shared memory ● Record locks ● ● POSIX semaphores File locks ● ● Named, Unnamed Mutexes ● System V message queues ● Condition variables ● System V shared memory ● Barriers ● ● System V semaphores Read-write locks man7 .org 5 It helps to classify ● Pipes ● Shared memory mappings ● FIFOs ● File vs Anonymous ● Cross-memory attach ● Pseudoterminals ● proc_vm_readv() / proc_vm_writev() ● Sockets ● Signals ● Stream vs Datagram (vs Seq. packet) ● Standard, Realtime ● UNIX vs Internet domain ● Eventfd ● POSIX message queues ● Futexes ● POSIX shared memory ● Record locks ● ● POSIX semaphores File locks ● ● Named, Unnamed Mutexes ● System V message queues ● Condition variables ● System V shared memory ● Barriers ● ● System V semaphores Read-write locks man7 .org 6 It helps to classify ● Pipes ● Shared memory mappings ● FIFOs ● File vs Anonymous ● Cross-memoryn attach ● Pseudoterminals tio a ● proc_vm_readv() / proc_vm_writev() ● Sockets ic n ● Signals ● Stream vs Datagram (vs uSeq.
    [Show full text]
  • Netflow Traffic Analyzer Real-Time Network Utilization and Bandwidth Monitoring
    DATASHEET NetFlow Traffic Analyzer Real-Time Network Utilization and Bandwidth Monitoring An add-on to Network Performance Monitor (NPM), SolarWinds® NetFlow DOWNLOAD FREE TRIAL Traffic Analyzer (NTA) is a multi-vendor flow analysis tool designed to proactively reduce network downtime. NTA delivers actionable insights Fully Functional to help IT pros troubleshoot and optimize spend on bandwidth by better for 30 Days understanding the who, what, and where of traffic consumption. Solve practical operational infrastructure problems with actionable insights and save money with informed network investments. WHY CHOOSE NETFLOW TRAFFIC ANALYZER? • NTA collects and analyzes flow data from multiple vendors, including NetFlow v5 and v9, Juniper® J-Flow™, sFlow®, Huawei® NetStream™, and IPFIX. • NTA alerts you to changes in application traffic or if a device stops sending flow data. • NTA supports advanced application recognition with Cisco® NBAR2. • NTA shows pre- and post-policy CBQoS class maps, so you can optimize your CBQoS policies. • NTA can help you identify malicious or malformed traffic with port 0 monitoring. • NTA includes WLC network traffic analysis so you can see what’s using your wireless bandwidth. • NTA supplements Network Performance Monitor by helping to identify the cause of high bandwidth. Built on the Orion® Platform, NTA provides the ability to purchase and fully integrate with additional network monitoring modules (config management, WAN management, VoIP, device tracking, IP address management), as well as systems, storage, and virtualization management in a single web console. page 1 DATASHEET: NETFLOW TRAFFIC ANALYZER FEATURES New! VMware vSphere Distributed Switch (VDS) Support Comprehensive support for the VMware VDS, providing visibility within the switch fabric to your east-west VM traffic to help IT pros avoid service impacts when moving workloads.
    [Show full text]
  • Netflow Optimizer™
    NetFlow Optimizer™ Installation and Administration Guide Version 2.4.7 (Build 2.4.7.0.23) January 2017 © Copyright 2013-2017 NetFlow Logic Corporation. All rights reserved. Patents both issued and pending. Contents Overview ....................................................................................................................................................................... 3 How NetFlow Optimizer Works .................................................................................................................................. 3 How NFO Updater Works .......................................................................................................................................... 3 NetFlow Optimizer Installation Guide ......................................................................................................................... 4 Before You Install NFO ................................................................................................................................................ 4 Pre-Installation Checklist ........................................................................................................................................... 4 Minimum Requirements ............................................................................................................................................. 4 Supported Platforms .............................................................................................................................................. 4 Virtual Hardware
    [Show full text]
  • Netfilter's Connection Tracking System
    FILTERING POLICIES BASED UNIQUELY on packet header information are obsolete. PABLO NEIRA AYUSO These days, stateful firewalls provide advanced mechanisms to let sysadmins Netfilter’s and security experts define more intelli- gent policies. This article describes the connection implementation details of the connection tracking system tracking system provided by the Netfilter project and also presents the required Pablo Neira Ayuso has an M.S. in computer science background to understand it, such as an and has worked for several companies in the IT secu- rity industry, with a focus on open source solutions. understanding of the Netfilter framework. Nowadays he is a full-time teacher and researcher at the University of Seville. This article will be the perfect complement to understanding the subsystem that [email protected] enables the stateful firewall available in any recent Linux kernel. The Netfilter Framework The Netfilter project was founded by Paul “Rusty” Russell during the 2.3.x development series. At that time the existing firewalling tool for Linux had serious drawbacks that required a full rewrite. Rusty decided to start from scratch and create the Netfilter framework, which comprises a set of hooks over the Linux network protocol stack. With the hooks, you can register kernel modules that do some kind of network packet handling at different stages. Iptables, the popular firewalling tool for Linux, is commonly confused with the Netfilter framework itself. This is because iptables chains and hooks have the same names. But iptables is just a brick on top of the Netfilter framework. Fortunately, Rusty spent considerable time writ- ing documentation [1] that comes in handy for anyone willing to understand the framework, al- though at some point you will surely feel the need to get your hands dirty and look at the code to go further.
    [Show full text]
  • Table of Contents
    TABLE OF CONTENTS Chapter 1 Introduction ............................................................................................. 3 Chapter 2 Examples for FPGA ................................................................................. 4 2.1 Factory Default Code ................................................................................................................................. 4 2.2 Nios II Control for Programmable PLL/ Temperature/ Power/ 9-axis ....................................................... 6 2.3 Nios DDR4 SDRAM Test ........................................................................................................................ 12 2.4 RTL DDR4 SDRAM Test ......................................................................................................................... 14 2.5 USB Type-C DisplayPort Alternate Mode ............................................................................................... 15 2.6 USB Type-C FX3 Loopback .................................................................................................................... 17 2.7 HDMI TX and RX in 4K Resolution ........................................................................................................ 21 2.8 HDMI TX in 4K Resolution ..................................................................................................................... 26 2.9 Low Latency Ethernet 10G MAC Demo .................................................................................................. 29 2.10 Socket
    [Show full text]
  • Flow-Tools Tutorial
    Flow-tools Tutorial SANOG 6 Bhutan Agenda • Network flows • Cisco / Juniper implementation – NetFlow • Cisco / Juniper Configuration • flow-tools programs overview and examples from Abilene and Ohio- Gigapop Network Flows • Packets or frames that have a common attribute. • Creation and expiration policy – what conditions start and stop a flow. • Counters – packets,bytes,time. • Routing information – AS, network mask, interfaces. Network Flows • Unidirectional or bidirectional. • Bidirectional flows can contain other information such as round trip time, TCP behavior. • Application flows look past the headers to classify packets by their contents. • Aggregated flows – flows of flows. Unidirectional Flow with Source/Destination IP Key % telnet 10.0.0.2 10.0.0.1 login: 10.0.0.2 Active Flows Flow Source IP Destination IP 1 10.0.0.1 10.0.0.2 2 10.0.0.2 10.0.0.1 Unidirectional Flow with Source/Destination IP Key % telnet 10.0.0.2 % ping 10.0.0.2 login: 10.0.0.1 10.0.0.2 ICMP echo reply Active Flows Flow Source IP Destination IP 1 10.0.0.1 10.0.0.2 2 10.0.0.2 10.0.0.1 Unidirectional Flow with IP, Port,Protocol Key % telnet 10.0.0.2 % ping 10.0.0.2 login: 10.0.0.1 10.0.0.2 ICMP echo reply Active Flows Flow Source IP Destination IP prot srcPort dstPort 1 10.0.0.1 10.0.0.2 TCP 32000 23 2 10.0.0.2 10.0.0.1 TCP 23 32000 3 10.0.0.1 10.0.0.2 ICMP 0 0 4 10.0.0.2 10.0.0.1 ICMP 0 0 Bidirectional Flow with IP, Port,Protocol Key % telnet 10.0.0.2 % ping 10.0.0.2 login: 10.0.0.1 10.0.0.2 ICMP echo reply Active Flows Flow Source IP Destination IP prot srcPort
    [Show full text]
  • Brocade Vyatta Network OS Data Sheet
    DATA SHEET Brocade Vyatta Network OS HIGHLIGHTS A Network Operating System for the Way Forward • Offers a proven, modern network The Brocade® Vyatta® Network OS lays the foundation for a flexible, easy- operating system that accelerates the adoption of next-generation to-use, and high-performance network services architecture capable of architectures meeting current and future network demands. The operating system was • Creates an open, programmable built from the ground up to deliver robust network functionality that can environment to enhance be deployed virtually or as an appliance, and in concert with solutions differentiation, service quality, and from a large ecosystem of vendors, to address various Software-Defined competitiveness Networking (SDN) and Network Functions Virtualization (NFV) use cases. • Supports a broad ecosystem for With the Brocade Vyatta Network OS, organizations can bridge the gap optimal customization and service between traditional and new architectures, as well as leverage existing monetization investments and maximize operational efficiencies. Moreover, they can • Simplifies and automates network compose and deploy unique, new services that will drive differentiation functions to improve time to service, increase operational efficiency, and and strengthen competitiveness. reduce costs • Delivers breakthrough performance flexibility, performance, and operational and scale to meet the needs of any A Proven, Modern Operating efficiency, helping organizations create deployment System The Brocade Vyatta Network OS new service offerings and value. Since • Provides flexible deployment options separates the control and data planes in 2012, the benefits of this operating to support a wide variety of use cases software to fit seamlessly within modern system have been proven by the Brocade SDN and NFV environments.
    [Show full text]