Networks

ArchLinux has a reference page on a software access point. At the bottom, it references that a non-00 country code is required along with the installation of CRDA (Central Regulatory Domain Agent) for wireless networks is required to run in the 5g range, due to the fact that radars and such need to be detected and non-interfered with. That page also describes a mechanism for a wifi device to be both a client and access-point.

• Debian WiFi
• Intel Wireless WiFi Link, Wireless-N, Advanced-N, Ultimate-N devices for debian
• RTL8192CU and RTL8188CUS in Station and AP mode at the same time
• Debian access point with Hostapd and RTL8188CUS/RTL8192CU
• Raspberry Pi Into a WiFi Hotspot with Edimax Nano USB EW-7811Un (RTL8188CUS chipset)
• List of Wi-Fi Device IDs in Linux
• aircrack-ng
• Beginners guide to a custom 802.11ac setup: lots of good tricks using "COMPEX WLE900V5-23 miniPCIe module, AR9880, 802.11ac, 3*3MIMO"
• About hostapd
• Turn any computer into a wireless access point with Hostapd
• hostapd: IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator

• command: iw list - to show capabilities of hardware
• command: iw wlan0 info
• command: iw wlan0 link
• command: iw wlan0 station dump
• command: iw reg set {00|BM|US|CA} - set appropriate country code for operating mode
• command: iw get get - to see results
• command: lsusb - to show usb devices command: lspci: - to show pci devices
• command: lspci -vv -s 6e:00.0 - show particular pci device (change the id)
• command: nmcli - network manager command line more info
• command: cat /proc/net/wireless
• command: iwevent
• command: iwgetid
• command: iwconfig - ancient tool

• FreeWTP -- An Open Source CAPWAP WTP : not sure what it does

• OpenFlow Header Files
• Revised OpenFlow Library (ROFL) - this looked like an excellent library, but I have problems trying to make the controller and the ethswitchd examples function with out crashing or not reacting as expected. And it uses and integrates it's own packet send/receive functions.
• libtins - packet crafting and sniffing. It would be interesting if the crafting portion was removed from the send/receive portion, which make a good open flow packet encoder/decoder.
• boost graph - max flow/min cut algorithms
• min cost max flow with negative weights
• amedama's github for open flow, with graph code
• runos - another controller, but with lots of other bits added
• logcabin - Raft protocol library
• OpenFlow 1.4.1 spec
• OpenFlow 1.5.1 spec
• beehive - Distributed SDN controller built on top of beehive. Open flow packet definitions base upon:
• Packet - "protocol buffer" for network protocol

Know of any c++ based packet serializers, coders/decoders, to process/build open flow packets?

Raft:

• consensus explained
• raft consensus algorithm

SDN Papers:

• Automatic belief network modeling via policy inference for SDN fault localisation: Springer Open Access paper on - Modeling via Policy Inference (called MPI) is a highly scalable, effective and flexible modeling approach to tackle fault localization challenges in a highly dynamic and agile SDN network.

Other openflow stuff:

• OpenFlow controller programming framework that provides everything needed to create OpenFlow controllers in Ruby
• Case Study with OpenWifi
• OpenFlow 1.3 for OpenWRT

Other not relevant C++ oriented stuff encountered:

• RapidJSON
• optitrack - natural point motion capture streaming library
• NatNet - the SDK
• NetworKit - social graph analysis
• list of cpp libraries
• Erasure Coding for storage devices with a paper
• mFAST - A FAST (FIX Adapted for STreaming) encoder/decoder)

To cut a short story even shorter, in the end I selected Digital Ocean's NetBox IP address management (IPAM) and data center infrastructure management (DCIM) tool. It uses PostgreSQL as it's backing database, which in my mind, was a significant deciding factor for me as it has built in field types to support both IPv4 and IPv6 style ip addresses and CIDRs. MySQL/MariaDB does not have that capability natively. Performing subnet/supernet queries in PostgreSQL is a great way to look for address and subnets easily and efficiently without resorting to third party libraries.

For the longer version of the story, here are some other IPAM tools I encountered in my travels:

• RackTables: a datacenter asset management system seeming to rely on MySQL. But it does seem to be more detail oriented to identifying and locating gear in racks.
• Netdot: NETwork Documentation Tool, a Perl based tool which, as a strength, can perform network scans with CDP/LLDP, switch forwarding tables, and router tables to build it's relationship database. I think it can use either MySQL or PostgreSQL. But I'm not sure if it is maintained much, because as of this date, the last release was 2014/08/12. There is a repository with some updates as of 2016/06/16.
• HaCi is an IP Address / Network Administration Tool with IPv6 support. This seems to be strictly an IP Address manager, with the last indicated revision of 2015/03/04.
• OpenNetAdmin provides a database managed inventory of an IP network. Unique to this product is a command line interface. Also unique, is the ability for tracking DNS records. It does have contexts to allow over-lapping addresses (a multi-tenant situation). But it seems to be oriented more towards MySQL. The features page lists other abilities. It looks featureful, however, the last git commit is listed as 2016/03/16.
• Not quite related, but here for the fact I encountered it: NetHead -- IP Allocation Tool is based on the original RIPE registry software.
• Wikiwand has a larger table oriented listing of IP Address Management tools, both commercial as well as open source, with an indication of databases solutions supported.
• nipap is a "sleek, intuitive and powerful IP address management system built to handle large amounts of IP addresses". Written in Python, using PostgreSQL for a data store, and supports IPv6. So a CLI is not unique thing, as nipap has one as well. VRF management is included.
• phpipam is one of the first IPAM solutions I heard about, but was one of the later ones to build in IPv6 capability. It has matured considerably, and is actively maintained.
• NOC Project is interesting as it knows about QinQ style networks. But it doesn't look like it is currently maintained.
• GestióIP is another address manager, but it doesn't seem to have recent activity either. And no special feature which stands out.
• NetMagis supports IPv4 and IPv6, generates DNS zone files, has an LDAP privilege system, can generate network maps, and has some sort of traffic map capability. The most recent github commit is about five months ago.

In looking for open source routing and open flow solutions, I came across Brian Linkletter's site called Open-Source Routing and Network Simulation. I never realised that there were so many network simulators out there. His site specializes in evaluating many of them.

Two reviews stand out. The first is DNS and BIND demonstration using the Cloonix network emulator which provides a mechanism for experimenting with the DNS protocol and the various open-source implementations of DNS including BIND.

The second interesting network emulator is the OFNet SDN network emulator. it comes prepackaged as an .ova file. The article indicates that it comes with the Floodlight and Beacon controllers. I wonder if Ryu could be used? Anyway, based upon the article, the emulator has visual tools for watching OpenFlow messages, evaluating topologies, and show traffic patterns. Further into the article, the author installs OpenDaylight, so it does look like other controllers can be trialled.

It’s usually best to leverage some sort of “smart” DNS to handle CNAME distribution, giving you the ability to weight your CNAME distribution vs. only using one CDN all the time, or prefer different CDNs in various global regions. I’ve had decent experience with Dyn here, but Route53 has all the features you’d want as well. If possible, write tooling towards your DNS provider’s API to automate your failovers.

Weight your distribution such that you never have one CDN turned off completely; you’ll want a small trickle of user traffic hitting every CDN so that the caches won’t be cold when you switch over to it.

Make sure you have a distributed metrics service (ThousandEyes, WebMetrics, et al) testing your CDNs individually as well as the external hostname.

Stay away from HTML- or Header-munging features when possible; stick with feature sets that are common (and implementable in similar ways) across your providers. (Similar advice goes for multi-vendor *anything*, TBH)

Some folks just let Cedexis do the work: www.cedexis.com

From the Linux NetDev List:

Running VXLANs over IPv6 link-local addresses allows to use them as a drop-in replacement for VLANs, avoiding to allocate additional outer IP addresses to run the VXLAN over.

The first patch is basically a bugfix, not allowing to use link-local addresses without specifying an interface; it doesn't seem important enough for net/stable though (and without the second patch, allowing to specify link-local addresses at all does not result in a working configuration anyways). The second patch then actually makes VXLAN over link-local IPv6 work by passing interface indices at the right places.

The final patch lifts the limitation of not allowing multiple VXLANs with the same VNI and port, as long as link-local IPv6 addresses are used and different interfaces are specified. Again, this brings VXLAN a bit closer to VLANs feature-wise.

ip needs some additional examples, ... from the netdev mailing list:

excellent opportunity for an aspiring writer / user to make a contribution to improve iproute2

git clone
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git
cd iproute2
--make changes--
commit, send to netdev.

From the ova-dev mailing list:

OVN will generate the IPv6 address for a logical port if requested using the IPv6 prefix and the MAC address (as IEEE EUI64 identifier). To generate the IPv6 address, CMS should define the IPv6 prefix in the 'Logical_switch.other_config:ipv6_prefix' column.

If the CMS wants to make use of ovn ipam it can now provide a list of IPv4 addresses and a range of IPv4 addresses which will be excluded from the dynamic address assignment. To support this, a new option 'exclude_ips' is added in the Logical_switch.other_config column.

Eg. ovn-nbctl set Logical_switch sw0
other_config:exclude_ips="10.0.0.2 10.0.0.30..10.0.0.40"

The present code, uses hash maps to store the assigned IP addresses. In order to support this option, this patch has refactored the IPAM assignment. It now uses a bitmap to manage the IP assignment with each bit in the bitmap representing an IPv4 address.

This patch also clears the 'Logical_switch_port.dynamic_addresses' if the CMS has cleared 'dynamic' address assignment request.

From the ipv6 mailing list:

Can anyone tell how will a DHCPv6 subscriber learn about the default gateway it has to contact for the subscriber traffic?

A DHCPv6 subscriber is supposed to learn about default gateway from Router Advertisement.

You need to read RFC4861 to understand the relevant details of RA.

Also, can you point me to the document where it is mentioned that a DHCPv6 subscriber has to use RS-RA for resolving gateway address?

Section 7.2.2 of RFC6434 explains this (but the wording could be clearer, perhaps). The basic point is that RFC4861 is effectively mandatory and DHCPv6 is optional.

From the cisco-nsp mailing list.

troubleshooting routing issues on paths external to our network that lead to blackholing of specific 5-tuple combinations here, very likely due to ECMP/Bundling issues (we are link is up/up and used for load-balancing, but cannot actually transmit or receive traffic, therefor dropping those packets on the floor).

Now, this happened a few times over the years, and I am wondering if you guys have any suggestions or tools that you use in those cases, other than tcpdump'ing at both ends, generating thousands of 5-tuple combinations and then analyzing them in wireshark.

Many people on this list are probably doing this already but with hardware devices like Ixia testers. You can use the control software for them to generate different flows in a pragmatic fashion. We haven’t the budget for them I’m afraid but I think we can test all we want with these pieces of software below.

You can check out Cisco’s TRex (https://trex-tgn.cisco.com/) or MoonGen (https://trex-tgn.cisco.com/). Both are built on DPDK so you need to install that as a prerequisite. These will let you generate large numbers of flows in a scriptable fashion and record the results.

I haven’t had time (story of my life!) but ideally I want to set up a new test server in our lab an get either/both of these installed so that each time we test a new device we can generate a range of traffic/flows to test the device forwards as desired, to test load balancing and hashing, testing ACLs, QoS etc.

At the minute we have a couple of low end devices and make do with the following open source tools to generate single packets or single flows for just basic speed testing or testing that traffic drops into a specific queue, matches an ACL etc:

• Generating single customer packets: http://ostinato.org/ and http://packeth.sourceforge.net/packeth/Home.html
• Layer 2 Ethernet/MPLS: https://github.com/jwbensley/Etherate
• Layer3/4 IP/TCP/UDP: https://github.com/esnet/iperf Layer 2/3/4: http://pktgen.readthedocs.io/en/latest/
• Specifically for testing ECMP have a look at this (I haven’t had a chance to play with it personally yet): https://github.com/facebook/UdpPinger

Also, after obtaining a list of affected and unaffected 5-tuples, any particular easy way to find out how this is getting hashed, so that we could find the likely number of bundle members (this could be very useful multiple interconnection and parties are involved).

You are probably going to need to dig into vendor specifics; what vendors are in play and the configs deployed (what load balancing / hashing options/knobs have been configured), then look at the hardware documentation with regards to what is supported by the hardware, does that match what is configured? If you test it empirically does it add up? The vendor documentation should say how the load-balancing is done.

You can roughly work out the hashing mechanism by say sending a fake flow from 10.0.0.1 to 10.0.0.2, proto TCP, src port 1, dst port 1. Then just increment one field by one, dst port == 2, then dst == 3 etc. Look as the traffic moves between links. If you keep incrementing you can brute force you way through an eventually you might see the same pattern of hashing results emerge.

Also some boxes have a command to test the hashing, example from a Cisco 4500X:

#show platform software etherchannel port-channel 1 map l4-port 1.1.1.1 100 2.2.2.2 200 | i is Te Map port for l4-port 1.1.1.1:100, 2.2.2.2:200 is Te1/1/16(Po1)

Another entry from the mailing list:

I'm looking at the "paris traceroute" toolsset right now, that looks like it could be the right tool for the job: lib paris trace route: aware of the multiple paths and can report on any single one of them accurately, as well as on all of them.

In trying to look for best practices for connecting various sorts of devices to a network, there are any number of combinations of portfast, bpduguard, and bpdufilter from which to choose.

Bpduguard checks for bpdu's entering the network when none are expected: a layer three device is normally connected, but then someone swaps in a switch which may create a loop connection.

Bpdufilter prevents bpdu's from exiting the network. This is used when someone the other side is looking for bpdu's, and you don't want them to see any, because you are certain not to create a loop.

What I want is to be able to bring up a port fast, and not have to go through the spanning-tree negotiation sequence, but I also want the protection that spanning-tree can offer, should strange configurations come into play.

The following table represents some scenarios with global bpduguard, global bpdufilter, interface level bpduguard, and interface level bpdufilter, all with portfast in place. This is a simple test on two adjacent ports on a switch with a cross over cable between the two ports.

The final combination we came up with is to have global 'spanning-tree bpduguard' with interface local 'spanning-tree portfast'.

With 'spanning-tree bpduguard' at the interface level, the interface continuously generates bpdus. With 'spanning-tree bpduguard' at the global level, and not at the interface level, is that when the interface comes up, bpdus are generated for 20 seconds, then are no more are generated. This allows the interface to be checked for loops during the up transition, and then no more checks are needed as the interface is deemed to be good layer three interface for the duration.

For these 'spanning-tree portfast' ports, I have started to apply 'spanning-tree rootguard' as a matter of course.

Eric Leahy has a good reference for BPDU Guard, BPDU Filter, Root Guard, Loop Guard & UDLD settings.

• ONF Technical Library: with technical specifications for the various versions of OpenFlow. Follow the 'SDN Resources' button on the upper right for more resources.
• Skydive: open source real-time network topology and protocols analyzer. It aims to provide a comprehensive way of understanding what is happening in the network infrastructure. Skydive is SDN-agnostic but provides SDN drivers in order to enhance the topology and flows informations.
• Faucet: OpenFlow controller for a layer 2 switch based on Waikato University's Valve. It handles MAC learning and supports VLANs and ACLs. It is developed as an application for the Ryu OpenFlow Controller . Examples make use of the Northbound Networks Zodiac FX OpenFlow Switch at $AUD 99. It doesn't do much, if anything with encapsulations (like MPLS or VXLAN or GENEVE) -- various references indicate 'on the to-do list'. Also, in the main faucet github page, they mentioned that Table-Type-Patterns weren't used, which I am starting to think are important for larger, more complicated configurations.
• Inside OpenFlow: is dedicated to providing a broad array of code examples showing how networking task are implemented with OpenFlow technology.
• ATOM: hackable open source text editor, useful for Python coding, has auto-completion
• Postman: Create and send any HTTP request using the awesome Postman request builder. Write your own test cases to validate response data, response times, and more! Good for testing and working with REST interfaces.
• The Benefits of Multiple Flow Tables and TTPs where VRFs and VLAN defined by OpenFlow multiple tables are described.
• Allied Telesis x510 and x930 series openflow capable switches.
• NoviFlow switches
• Netronome PCIe cards with off-load: Agilio CX cards
• Colfax Direct: HPC and Data Center Gear
• OpenNFP: collaborative research in the area of network function processing in server networking hardware

A very detailed and useful paper: Sofware-Defined Networking: A Comprehensive Survey

t has taken a while, but I think I understand how some flavours of SDN work.

In CiscoLand, at the hardware level, CEF is a flow based forwarding mechanism. All the higher layer routing protocols like bgp, ospf, rip, etc, are used to build that flow table. I think Cisco's ACI is designed to manipulate those flow tables directly through some set of off-box oob controllers. These flows are monitored through Netflow, sFlow, OpenFlow telemetry commands, and the like. So flows are integral to how networks work. How they are controlled is the question.

I used to be of the mentality that this central control created points of failure in the network. But if boxes can maintain state during a controller failure or outage, then it isn't so bad. In addition, many initial talking points mention that flow tables needed to be dynamically populated, which requires punting packets to the controller, which really slows things down.

But many networks have a reasonably static topology. This enables flow bundles to be pre-populated and thus hardware forwarding can be used for the majority of the traffic, if the flow rules are general enough. From a high level perspective, then the issues arise when network failures occur. How does the network heal itself around those failures points? Some answers I am still looking into.

In the open source world, Linux, in the kernel forwarding plane, also maintains a flow table. sFlow can be used to monitor flows. There are netflow add-ons to monitor those flows. Static routes and things like Quagga are used to define the rules for how flows are setup.

So, enters the concept of OpenFlow, which is a set of rules used to manage those flow tables directly. Either locally, or through some off-box controller. (I have been looking into Ryu at the moment).

When using layer 3 network protocols like bgp, et.al., the flow rules are typically defined based upon destination ip address.

With OpenFlow, flows can be specified on a number of different combinations of addresses, ports, mac addresses, encapsulations, ...

Now take that concept, and make the realization that you can create a distributed firewall, because the network itself can provide firewall and associated security features. Rather than creating flow rules based upon destination address, ... with the added granularity, flow rules can be specified that only specific types of traffic (eg port 80, or esp, or ...) go through various parts of the network, and traffic not matching those flow rules go somewhere else, say like a honey-pot or something.

And with various forms of encapsulation from edge to edge, various forms of vrf/vpn/segmentation are inherently supplied.

So, it is conceivable that the central points of congestion like big central firewalls can be eliminated, and the security and privacy can be distributed throughout the network. Kind of like MPLS/VPLS on steroids.

From the open source perspective, I have just started going through the examples for OpenVSwitch (OVS) and its companion product Open Virtual Networking OVN at Spinhirne's Blog . The examples show some single points of failures, but I think I know how to make those better. It is looking promising based upon what I've seen so far, but have more under-the-hood looking to do.

My previous blog article build the guests in a VirtualBox environment. This blog article shows the configuration for testing. Continue reading "Dustin Spinhirne's OVN Tutorial: Test..." »

This draft from the IETF based upon work from Cisco, Juniper, and Google is titled Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution.

Quoting from the lead in section:

Connecting an enterprise site to multiple ISPs using provider- assigned addresses is difficult without the use of some form of Network Address Translation (NAT). Much has been written on this topic over the last 10 to 15 years, but it still remains a problem without a clearly defined or widely implemented solution. Any multihoming solution without NAT requires hosts at the site to have addresses from each ISP and to select the egress ISP by selecting a source address for outgoing packets. It also requires routers at the site to take into account those source addresses when forwarding packets out towards the ISPs.

This document attempts to define a complete solution to this problem. It covers the behavior of routers to forward traffic taking into account source address, and it covers the behavior of host to select appropriate source addresses. It also covers any possible role that routers might play in providing information to hosts to help them select appropriate source addresses. In the process of exploring potential solutions, this documents also makes explicit requirements for how the solution would be expected to behave from the perspective of an enterprise site network administrator.

Some interesting quotes:

"It is not reasonable to expect an enterprise network operator to change the routing topology of the site in order to deploy IPv6."

"Mechanisms have been proposed to allow hosts to choose the source address for packets in a fine grained manner. We will discuss these proposals in Section 4. However, interacting with host operating systems in some manner to ensure a particular source address is chosen for a particular destination prefix is not what an enterprise network administrator would expect to have to do to implement this routing policy."

"With IPv4, this problem is commonly solved by using [RFC1918] private address space within the multi-homed site and Network Address Translation (NAT) or Network Address/Port Translation (NAPT) on the uplinks to the ISPs. However, one of the goals of IPv6 is to eliminate the need for and the use of NAT or NAPT. Therefore, requiring the use of NAT or NAPT for an enterprise site to multihome with provider-assigned addresses is not an attractive solution."