Archive

Archive for the ‘IPv6’ Category

IPv4 and IPv6 Netflow on Cat 6500 and Nexus 7k

January 29, 2015 2 comments

Netflow can be a handy tool to use on the network when you need to see information such as total number of flows/sec, bps per source/destination pair, and top talkers. It can also be used by service providers for usage based billing purposes or for help in mitigating DDoS attacks etc. etc. Here I will show you how to configure netflow on Cisco Nexus 7k and Catalyst 6500 based switches for both IPv4 and IPv6.

There are two main versions of netflow that I will talk about and what their differences are. The are V4 and V9 netflow. V4 has been around for a while and only supports IPv4. It is also a fixed format in that the info you can get from a V4 netflow record is all that you will ever get. There is no expandability built into V4 to allow it to support future data types.

Netflow V9 on the other hand supports both IPv4 and IPv6. It is also template based. This means you can customize the data being sent to your collectors. You can pick and chose which data fields you want to see. V9 is also extendable in that new data types can be added to the template as required in the future.

Lets get to the nuts and bolts of actually getting some netflow data off of our switches and into a collector so that we can search on it and visualize it if we so choose. For my examples below I will be using V9 as I like to collect both IPv4 and IPv6 statistics as I am running a dual stacked network.

Cat 6500 Config
Here is the basic config to get netflow v9 running and exporting flow data to your collector of choice:

mls netflow interface mls flow ip interface-full mls flow ipv6 interface-full mls aging long 300 mls aging normal 120 mls nde sender

 
Here is what is going on in the first few lines of config. We are enabling per VLAN flow data to be collected, setting both the IPv4 and IPv6 flow masks to interface-full. Setting the mask to this exports all netflow data captured. There are several flow masks you can configure, each one sending less and less data. Setting the MLS aging timers is a good idea to get a more accurate view of flows as netflow data is not sent for a flow until it has timed out. For long lived flows, this is 32 mins by default. Setting the long timer to 300 means that long lived flows will be timed out in the netflow cache every 5 minutes thus allowing the collection of data for that flow to happen much sooner. I have set the normal timers to 120 just to age out inactive flows a little quicker than the default of 300 (5 minutes). Finally we enable the export of netflow data.
 

ip flow-export source Vlan100 ip flow-export version 9 ip flow-export destination 10.10.10.10 9995

 
Here we are specifying netflow updates should be sourced from vlan 100, they are to be version 9 records, due to the fact I am exporting both IPv4 and IPv6 flows and my netflow collector is at 10.10.10.10 and listenign on port 9995.

Now we configure our interface to collect netflow data.
 

interface Vlan100 ip flow ingress

 
That is pretty much it. If you have tons of flows you could also set up sampled netflow. Where 1 out of every x packets are sampled for the netflow chache. This will improve CPU utilization on the switch and will be less flow data to have to store on the netflow collector as well.
 
 
Nexus 7k Config
Configuring netflow on a Nexus 7k is a bit different in that Nexus supports what is called Flexible Netflow. Here we configure netflow in a more modular approach. We configure Flow Records which state what data we want collected, Flow Exporters that specify where to send the flow data and what version of netflow to use and Flow Monitors which are placed on the interfaces where we wish to capture flow data. You can optionally specify a Flow Sampler which will do what its name implies. Capture sampled netflow data instead of looking at every packet.

Here I am configuring two separate flow records, one for IPv4 and one for IPv6 as you cannot have both IPv4 and IPv6 protocols in the same flow record. I am matching on specific keys and then collecting data based off of those keys.
 

flow record ipv4-netflow match ipv4 source address match ipv4 destination address match ip protocol match ip tos match transport source-port match transport destination-port collect routing source as collect routing destination as collect routing next-hop address ipv4 collect transport tcp flags collect counter bytes collect counter packets collect timestamp sys-uptime first collect timestamp sys-uptime last flow record ipv6-netflow match ip protocol match transport source-port match transport destination-port match ipv6 source address match ipv6 destination address collect routing source as collect routing destination as collect routing next-hop address ipv6 collect transport tcp flags collect counter bytes collect counter packets collect timestamp sys-uptime first collect timestamp sys-uptime last

 
Now lets create the flow exporter and flow monitors. Again you must create a seperate flow monitor for IPv4 and IPv6.
 

flow exporter flow-exporter destination 10.10.10.10 source loopback0 transport udp 9995 !This is the default value version 9 flow monitor ipv4-netflow-mon record ipv4-netflow exporter flow-exporter flow monitor ipv6-netflow-mon record ipv6-netflow exporter flow-exporter

 
Finally we configure the flow monitors on the interfaces we wish to obtain netflow data from:
 

interface Vlan300 ip flow monitor ipv4-netflow-mon input ipv6 flow monitor ipv6-netflow-mon input

That’s it! You can verify you are collecting flow data by issuing the following commands. On a 6500 the command is:

show mls netflow ip – Shows the flow cache table.
show mls netflow ipv6 – Shows the flow cache table for IPv6.
show mls nde – Shows netflow export info.

For the Nexus the verification commands are:

show hardware flow ip – Shows IPv4 flow info
show hardware flow ipv6 – Shows IPv6 flow info
show flow exporter – Shows flow export info

Advertisements
Categories: IPv6, netflow, nexus

My journey into the land of IPv6: Addressing

There has been much talk about needing to move to IPv6 for a while now. With the last IPv4 allocations being handed out, reality is now sinking in that moving forward, IPv6 will be the way we start addressing our networks. Yes, IPv4 will undoubtedly be around for a while as carriers use CGN to work around the limited address space they have, but moving forward, IPv6 will see more use.

I have had the good fortune to be able to turn up and test IPv6 on a new core network that sits alongside the current network. In this network I am running MPLS L3 VPNs so the actual core is IPv4 only due to LDP not having support for IPv6 currently but that has no impact on running IPv6 within each VRF. Running IPv6 within a L3 VPN will be for another blog post though. In the next few posts, I will talk about how we can easily get IPv6 up and running. Assuming the infrastructure supports it of course!  First stop, addressing.

Once you have recieved your prefix from ARIN (most likely a /48) what in the world are we supposed to do with it?  The most visible difference between IPv6 and IPv4 is the larger addresses: IPv4 addresses are 32 bits long and written in ‘dotted decimal’ format  i.e. 192.168.1.1. IPv6 uses 128 bit addresses, written in 8 groups of 16 bit blocks (words)  written in hex and separated by colons – i.e. 2620:0000:691:1001:0000:0000.000a:0001.

When writing addresses, within each block of 4 hex digits the leading zeroes may be omitted. In addition, once per address (and no more) a contiguous set of one or more blocks which are all 0000 may be replaced by a double colon. So the above address can be rewritten as: 2620:0:691:1001::a:1.

Netmasks are written in the same mask length format as IPv4, with /length after the address. For example, a /126 subnet has 126 bits of network address, leaving 2 bits for host addresses . The bottom address being the network anycast address, although this is not required. There is no top address for a directed broadcast).

When subnetting, always remember to subnet on nibble (every 4 bits ) boundaries so as not to have a subnet end in weird places,  i.e. having a subnet end on 2620:0:691:7:: and the host portion begin on 2620:0:691:8::

Also, unless you have special circumstances, always use /64’s as end host networks.  Not using /64 as your network will break things such as Neighbor discovery, privacy extensions etc. Click ipSpace.net has a good post on why using /64 networks is the way to go.

There are several different addressing methods for IPv6 as well:

Stateless Autoconfiguration (SLAAC)

In this scenario, a host will address itself based off of a network prefix learned from an advertising router via periodic router advertisements (RA’s). The host will append its MAC address (with FF:FE inserted in the middle) and this will form the 128 bit host address. This could be a security concern as the hosts MAC address is easily obtained from this address so most operating systems replace the MAC with a randomized unique identifier.

Lets talk about the RA for a second. If you only configure SLAAC on your router you aren’t manually specifying a DHCP pool with default gateway etc as with IPv4 for end hosts.  So how does your PC know how to send traffic off net? The RA specifies several different parameters to end hosts including:

  • IP prefix (or multiple prefixes)
  • Flags (such as used DHCP to obtain DNS info)
  • Default gateway

 

In this scenario, no config flags are set in the RA messages.  What about DNS?  This is either handled manually on each end host or you can do SLAAC with DHCPv6.

SLAAC with Stateless DHCPv6

In this scenario, the Other-Config-Flag is set in the RA to tell the host to use SLAAC to get an address and use DHCPv6 to obtain other parameters such as DNS.  The DHCPv6 server is stateless in that it does not keep track of what IPv6 address each end host has.

Stateful DHCPv6

In this scenario the Managed-Config-Flag is set in the RA and tells the end host to use DHCPv6 only to obtain an address, DNS etc.

Static Addressing

This option is really only useful for server farms etc where you don’t want to have these addresses randomly assigned.  This can be accomplished using the no-autoconfig flag enabled.  This sets the A bit to zero in RA’s so that autoconfig is not used by the end host to assign itself an address.

In my next post I’ll go over the configurations to make it work within a SLAAC and Stateless DHCPv6 environment.

Categories: IPv6