Exporting NetFlow from Linux to a collector over IPv6

There is another project out there in the ether that I have a hand in providing input for. One of the features that I felt was necessary for it is exporting NetFlow information from traffic the Linux machine handled, to a collector. This is dual-stack traffic, but I have the collector listening on IPv6.

Firstly, I needed something that would gather and export the data, so I found softflowd. My ubuntu server had it in the repo, so a quick apt install got it onto the machine easily enough. You need to edit /etc/default/softflowd and set what interface(s) you want it capturing & generating flow data from, and what options to feed to the daemon, like what server:port to export that data to:

INTERFACE="eth#"
OPTIONS="-v 9 -n [x:x:x:x::x]:9995"

Fill in the correct interface name you want to gather data from. The -v 9 option tells it to use Netflow v9, which has IPv6 support. The -n option is used for specifying the collector machine’s IP and port, so fill in for the correct IPv6 address of that collector. And that is the format for specifying an IPv6 host running a collector, like nfcapd. Then you can fire up the softflowd daemon, and you should start getting data sent to the collector:

Date flow start          Duration Proto                             Src IP Addr:Port                                 Dst IP Addr:Port   Packets    Bytes Flows
2015-02-13 23:18:13.316     0.001 UDP                              72.52.116.23:53    ->                            72.52.116.26:41933        1      213     1
2015-02-13 23:18:13.316     0.001 UDP                              72.52.116.26:41933 ->                            72.52.116.23:53           1       55     1
2015-02-13 23:15:17.715   180.139 ICMP6                         2001:470:1:9::1.0     ->                      2001:470:1:9::6666.0.0          4      288     1
2015-02-13 23:15:17.715   180.139 ICMP6                      2001:470:1:9::6666.0     ->                         2001:470:1:9::1.0.0          4      256     1
Summary: total flows: 75, total bytes: 291951, total packets: 1559, avg bps: 10006, avg pps: 6, avg bpp: 187
Time window: 2015-02-13 23:15:05 - 2015-02-13 23:18:58
Total flows processed: 75, Blocks skipped: 0, Bytes read: 5300
Sys: 0.008s flows/second: 9149.7     Wall: 0.006s flows/second: 12209.0

IPv6 in my streaming media? More likely than you think!

Not that I go out of my way to endorse one project/product over another, there is one that I have recently fallen in love with for streaming my media. Especially when it can use IPv6! So I needed a cross-platform solution for my streaming media needs. I was originally using XBMC, but only had it tied into the TV. I use several other computers and devices, in other locations outside of the house. So I read up on Plex. Got it installed with little to no effort, and could readily access my content where ever I was. I even tested this on my last trip to London, UK and was able to get a decent 1.2mbit/s stream from my house. Only issue was that it wasn’t using IPv6 in the app or accessing via plex.tv (server on that site only comes up with an IPv4 address).

So poking around I discovered 2 things: 1) I could access the Plex server directly at the IP/hostname of the server, and 2) there was a checkbox to enable IPv6!!

plex-ipv6

Simply browse to your Plex server, click on the settings icon (screwdriver + wrench), select Server, click on Networking and then “Show Advanced”. You’ll see the checkbox at the top, click it and save settings. Now you should be good to go! You can either access the server directly using the literal address inside []:32000:/web/ or the hostname:32000/web/

I still need to check if apps on Android are accessing over IPv6 or not, but for now I know a browser directly connecting to the Plex server does. A quick netstat shows us it is listening:

~# netstat -tnlp | grep -i plex
tcp 0 0 0.0.0.0:32469 0.0.0.0:* LISTEN 17642/Plex DLNA Ser
tcp 0 0 0.0.0.0:51107 0.0.0.0:* LISTEN 17606/Plex Plug-in
tcp 0 0 0.0.0.0:1541 0.0.0.0:* LISTEN 17642/Plex DLNA Ser
tcp6 0 0 :::32400 :::* LISTEN 17597/Plex Media Se
tcp6 0 0 :::32401 :::* LISTEN 17597/Plex Media Se

IPv6 with A10 Load Balancers

So I got to do some honest IPv6 related work at the job the last 2 weeks. One task was to verify we had IPv6 working on the load balancers to hosts behind it. I was a bit wary of the state of IPv6 security on these A10 LBs, so I opted to keep the globally routed IPv6 space on the LB’s uplink interface, and the VIPs. And behind the scenes, use ULA.

Step 1: I generated a /48 of ULA for the location, and assigned a /64 for use on the VLAN that the inside interface of the LB sits on with the servers themselves.

Step 2: Configure ::1/64 on the LB inside vlan interface, and ::2/64 on a server, and verified that they could reach each other.

Step 3: I installed lighttpd on the server and configured it to listen on the ULA address.

Step 4: From my ARIN allocation, I have a /64 reserved for configuring /126s on device links to the router, so I configured it on the LB’s dedicated interface on the router. Using ::1/126 on the router; ::2/126 on the LB’s interface; ::3/126 as the VIP.

Step 5: Create on the LB an “IPv6 NAT Pool”, which is really a set of IPs that will act as source IP when talking to the webserver from the LB. I used ::3 through ::ff/64 of the same ULA space. The A10 LB only allows you to create a pool of 1000 IPs, so keep that in mind.

Step 6: Next you create the “Server” entry which is a description referencing an IPv6 address, in this case the ULA address of the web server. You also specify what IP services it will host that the LB can healthcheck, so I only set TCP 80.

Step 7: Then a “Service Group” needs to be created, and this is where you set what kind of LB algorithm and which servers will be used.

Step 8: Now a “Virtual Service” is defined that will tie in what service is forwarded to servers behind the LB, in this case HTTP on port 80, as well as what “NAT Pool” to use.

Step 9: Finally we create the “Virtual Server” (or VIP) with what globally routed IPv6 address you want to use, and what host/service will be used internally.

Now the above is just for getting IPv6 working through the unit. You can obviously attain dual-stack status by doing the same using IPv4. As well as actual load balancing when creating multiple “Server” entries and adding them to the “Service Group”.

Comcast filtering SMTP (TCP 25) for IPv6, but 587 still works!

Noticed this weekend that I couldn’t respond to emails on my personal hosted domains. I thought at first first they changed my PD prefix, but it was up to date in Postfix. Tried submission port and it worked just fine. So looks like Comcast finally caught up with “feature parity” in disallowing outbound SMTP connections on TCP 25.

My first received spam delivered over IPv6!

Not certain how much this actually counts as “Spam over IPV6” though. It was only the last bit of delivery to my account where IPv6 was involved. It still originated from IPv4.

 
Received from relay-6.dlfw.twtelecom.net ([2001:4870:6082:1::72]) by he.net for ; Tue, 13 Nov 2012 11:57:38 -0800

Received from localhost (unknown [127.0.0.1]) by relay-6.dlfw.twtelecom.net (Postfix) with ESMTP id 223346021E; Tue, 13 Nov 2012 12:47:42 -0700 (MST)

Received from relay-6.dlfw.twtelecom.net ([127.0.0.1]) by localhost (relay-6.dlfw.twtelecom.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMxIEAmBj2TU; Tue, 13 Nov 2012 12:47:42 -0700 (MST)

Received from aol.com (unknown [209.234.184.51]) by relay-6.dlfw.twtelecom.net (Postfix) with SMTP id D73BD60094; Tue, 13 Nov 2012 12:47:32 -0700 (MST)

IPv6 and flows (using nfsen)

This will be about already having nfsen/nfdump configured, and are looking to just make a flow profile to graph IPv6 traffic from your routers. If you are looking to get nfsen iniitially configured, definitely follow their instructions on their site.

Say you have an sFlow capable router like…picking one totally not at random…..a Brocade XMR or MLX(e), and you want some basic flow data, especially IPv6. Depending on how many routers you are going to collect flow data from, will determine how beefy of a machine you will need. I know that at $lastjob, it was a hefty CPU (and definitely more than 1), tons of RAM, and hardware RAID. Right now, I’m using dual quad-core Xeon, tons of RAM and a small hardware RAID, but this machine serves many purposes. Right now I’m also only polling 4 MLX routers.

Go ahead and access your nfsen website, and on the Profiles pulldown, select “New Profile …”. In the creation dialog, give the profile whatever title you like; I went with the generic title of “IPv6”. If you want to add it to a group or make one for it, do as you please. I left that alone so I’d have it as a readily available profile to view. Select all the sources, or at least the ones you KNOW have IPv6 configured on as well as possible traffic (hosts, peers, transits, etc.). In the filter option, simply put: inet6

Save the profile, wait a while for data to get newly collected, and your graphs should start populating with delicious IPv6 flow information.

Basic BGP configuration for IPv6

So you have your ASN and just got your PI (Provider-Independent Address Allocation) straight from an RIR, or perhaps a LoA (Letter of Authority) to announce some PA (Provider-Assigned Address Allocation) space from your ISP. You’ll need to start getting that announced out there to your peers, customers and transits. So lets use some documentation prefixes and ASNs and sort out a basic working config. I’ll base the examples on my experience with Brocade NetIron software on XMRs, which can translate over to Quagga or Cisco IOS with a few tweaks.

Assuming you are familiar with BGP4+ with IPv4, IPv6 is not so different or any more complex when getting started. Lets start off with some numbers:

Upstream ISP ASN: 64500
Your ASN: 64501
Specific /126 configured on interfaces out of allocated /64: 2001:db8:0:1::/126
PA allocation to announce: 2001:db8:1234::/48

Start off with making certain that you’ve configured IPv6 on your upstream facing interface, and they’ve configured your side, and you can ping each other over the link. The upstream provider’s configuration can be done as so:

isp#conf t
isp#(config)ipv6 prefix-list as64501-ipv6-filter seq 1 permit 2001:db8:1234::/48
isp#(config)router bgp
isp#(config-bgp)nei 2001:db8:0:1::2 remote-as 64501
isp#(config-bgp)nei 2001:db8:0:1::2 desc Customer_Name
isp#(config-bgp)no nei 2001:db8:0:1::2 activate
isp#(config-bgp)add ipv6 uni
isp#(config-bgp-af)nei 2001:db8:0:1::2 activate
isp#(config-bgp-af)nei 2001:db8:0:1::2 filter-list as64501-ipv6-filter in
isp#(config-bgp-af)exit
isp#wr mem

So the breakdown of these steps is:

  • enter configuration mode on router
  • build a filter to restrict what the customer (you) are allowed to announce (seq optional but required for multiple entries in list)
  • enter BGP configuration mode
  • create a specific session using target/destination IPv6 address and ASN of customer
  • optionally add a description of the session perhaps to track who it is more clearly
  • you don’t want IPv4 routes going out or coming in over the session, IPv6 routes only
  • change address-family for IPv6 specific BGP settings
  • activate sending and learning IPv6 routes over the session
  • apply the filter for accepting INBOUND routes from you/customer
  • exit & then write out the config

On the customer side it is similar but not exact:

you#conf t
you#(config)ipv6 prefix-list outbound-ipv6-filter seq 1 permit 2001:db8:1234::/48
you#(config)router bgp
you#(config-bgp)nei 2001:db8:0:1::1 remote-as 64500
you#(config-bgp)nei 2001:db8:0:1::1 desc ISP_Name
you#(config-bgp)no nei 2001:db8:0:1::1 activate
you#(config-bgp)add ipv6 uni
you#(config-bgp-af)network 2001:db8:1234::/48
you#(config-bgp-af)nei 2001:db8:0:1::1 activate
you#(config-bgp-af)nei 2001:db8:0:1::1 filter-list outbound-ipv6-filter out
you#(config-bgp-af)exit
you#wr mem

The differences being:
1) outbound filter list on your session to the ISP
2) network statement for the allocation to be announced by BGP

You’ll also need some sort of anchor route so BGP knows to announce the route. This can be either a local null-route or static-route for the covering prefix, or an IP out of the prefix configured on an interface. So once BGP is configured, and establishes between both routers, the ISP side should see something similar to:

isp#sh ipv6 bgp nei 2001:db8:0:1::2 routes
       There are 1 accepted routes from neighbor 2001:db8:0:1::2
Searching for matching routes, use ^C to quit...
Status A:AGGREGATE B:BEST b:NOT-INSTALLED-BEST C:CONFED_EBGP D:DAMPED
       E:EBGP H:HISTORY I:IBGP L:LOCAL M:MULTIPATH m:NOT-INSTALLED-MULTIPATH
       S:SUPPRESSED F:FILTERED s:STALE
       Prefix             Next Hop        Metric     LocPrf     Weight  Status
1      2001:db8:1234::/48  2001:db8:0:1::2
                                          1          140        0       E
         AS_PATH: 64501

And that should be it. You can obviously play around with peer-groups, route-maps, etc. Communities should work as long as your ISP offers them, so be sure to ask. Ideally there is at least a blackhole community in place. That should allow you to announce a specific range or IP that you want to have null-routed upstream in cases of abuse or attacks. That filter could look like either of the following, depending on how specific they allow you to announce:

ipv6 prefix-list as64501-ipv6-filter seq 1 permit 2001:db8:1234::/48 le 64

or

ipv6 prefix-list as64501-ipv6-filter seq 1 permit 2001:db8:1234::/48 le 128

With the obvious requirement that the BGP sessions would need to be configured as blackhole community enabled on both sides.

Dovecot v2.x

OSS projects and authors are just making it too easy to enable IPv6! Not that this is a bad thing mind you, because it means there is even less reason to NOT have your services available on IPv6. We’ll take a speedy look at configuring Dovecot.

dovecot.conf
#listen = *, ::
This line lets you configure what addresses Dovecot will listen on.
* = All IPv4
:: = All IPv6
If you have specific IPs you only want Dovecot listening on, you would specify a listen = line with comma delimited addresses for those IPs. By default Dovecot will listen on all available IPs configured on the server, as will the services you’ve decided to provide (POP3, POP3S, IMAP, IMAPS, etc.).

IPMI over IPv6

One of the great server technologies for Out-of-band management is IPMI (Intelligent Platform Management Interface),Ā  and more importantly version 2.0. This version allows for a true IP/KVM experience for the user to manage their server remotely. My preferred server hardware is from Supermicro for cost and features. For this example of IPMI available on IPv6, I’ll use their X7SPA-HF Atom based server board using the ATEN IPMI chipset.

Let me start by saying this IPv6 implementation is far from perfect, but who to blame: ATEN or Supermicro? First, you cannot configure IPv6 in the BIOS menu at all. You’ll need to configure it via the web software after you can reach it over IPv4. So log in and select Network under the Configuration menu.

So on this page, you’ll see all the network configuration options, most importantly IPv6. This implementation appears to support configuration either using SLAAC (autoconfiguration) or DHCPv6. You can also add a static IPV6 address. HOWEVER: you cannot manually configure an IPv6 default gateway/router. This means you are relying on the availability of Router Advertisements on the network to autoconfigure the gateway/router address.

So that is pretty much it. Not terribly hard to get up and running on IPv6, but could be done a little bit better in my opinion. It would be nice to see IPv6 configuration at the BIOS level.

IPv6 Toys: Axis Cameras

Probably one of my favorite IPv6 enabled devices are the cameras made by Axis. On many of their newer models, IPv6 support is now in the RTSP software they use, so you aren’t limited to watching just their MJPEG streams over IPv6. This will be a super simple walk-through for enabling IPv6 on the cameras, and even setting a static IPv6 address.

First and foremost, make certain your camera is running the latest firmware. If not, upgrade before changing any settings. So lets log into your camera. I’m using a M1011, but the menus we’ll use and options we’ll set were similar if not exactly the same for my 215PTZ and 210. Under Basic Setup select the TCP/IP submenu, which should look like the following:

On this page, You should see a check-box for enabling IPv6. Selecting this and saving the setting both enables IPv6 as well as auto-configuration if that is available on your network.

If you want to set a specific static IPv6 address, you need to go into the more detailed configuration settings area. Under the System Options menu, you’ll find the Advanced sub-menu. Select Plain Config as shown below:

After entering the Plain Config, it will be a very minimalist page, and there will be a pulldown menu. Select Network and proceed to view the settings. Scroll down to the section covering the network interface. For just a static IP configuration, uncheck “Accept IPv6 router advertisements” and set DHCPv6 to “off”. Make certain that “IPv6 Enabled” is checked off šŸ˜‰ In the network interface manual setting section, you can set your static IPv6 address as well as its default IPv6 gateway. Save the settings and the system will be available on that static IPv6 address.

Once back out into the standard menu system, you can verify your network settingsĀ  under the TCP/IP settings sub-menu and clicking on the “View” button to bring up current settings:

So doing this static IPv6 configuration, I have two cameras online: