When should I start planning for an IPv6 deployment? – Article #2

In IPv6 Article 1 we explored the current rate of adoption globally for IPv6, and made the conclusion that yes, its real and will be mainstream within 4 years. This raises the obvious question of “when do I need to start planning?” & of course, the answer is “it depends”

  1. How big is your enterprise will determine how long an implementation may take – you can work backwards from there…
  2. Where do you need v6 initially – the edge, the core? there are several common deployment models that depend on your specific needs?
  3. What IPv6 services do you see yourself offering to your clients, or your own business?
  4. Do you have the base requirements in place i.e. addressing plans, IPv6 prefixes, V6 policies and standards?
  5. How complex is your environment – do you have dual ISP connectivity for example and will need a highly available provider independent address space to route?

The above are a few of the questions you will need to answer in the early stages of planning.

A good place to start is with point 4 – which is essentially proper planning. A lot of organisations sort of skip this step which of course will lead to a broken implementation and higher costs down the line. Some of the elements required here should be;

  1. Apply for your v6 prefix from your RIR, and your BGP ASN if you will need one (hint, get one)
  2. Design your v6 IP schema and address plan – sounds simple? its not…
  3. Update your IPV4 Security Policies to include this new Protocol. IPv6 schemas can be used to enforce policy on bit matching or this could be a good time to start considering your next-gen firewalling strategy, based on user authentication policy enforcement and move away from static and hard to scale / manage IP address based policies.
  4. Determine your v6 standards, and create a procurement checklist to ensure all new network devices can transport v6 as needed (think PIM-v6, OSPFv3 ,BGP address-families etc.)
  5. Plan for the network services that will need to be enabled as well, this will cover at least IPv6 DNS & DHCP services

If you cant tackle that yourself, as you probably wont have the skills yet – then go get yourself some consultancy to get you going – it will be worth the investment in the long run.

There’s a lot to cover to even go over the high level steps and considerations for your long term IPv6 deployment strategy – in the next article we will assume your planning is completed and take a look at how you can roll V6 out in a controlled manner.

 

Will IPv6 actually ever take off? – Article #1

I am going to write a series of articles on IPv6 in the coming months. The first will be to look at the adoption rates for IPv6 and ask the question – “is IPv6 actually ever going to take off?”

Following on from this post I will post some articles on timing and triggers and then some practical advice on how you would go about actually deploying IPv6 in your environment.

So, – who has adopted IPv6?

Not many people according to google, well the % of people actually using IPv6 to transfer data across the internet right now is 2.75% of total traffic load. But usage is growing faster now than ever before. 2013 saw an increase 1.5 times of the previous 5 years.

Google V6 Usage Stats

 

 

 

 

 

It  also matters what country you live in as well. The USA has a healthy take up rate and is leading the way, also use in France and Germany is growing fast.

v6countries

 

 

 

 

 

Cisco has a different view – if you hop on their V6 stats site @ http://6lab.cisco.com/stats/ you will see much different numbers being shown for rather different views. One in particular that is quite interesting is IPv6 prefixes being advertised.

This shows a similar pattern to usage in that North America and North Europe are leading the way, but a much heavier increase in % of prefixes comparing V6 to V4 route tables.V6prefixes

 

 

 

 

 

This tells us that although we might not be using V6 for transport today, it’s there ready and waiting advertising V6 networks in readiness for when we decide to make the switch.

So, the ISPs, North American and European countries are starting to enable their enterprise edge and ISP transit networks – so what about the rest of us? For the most part larger enterprises are looking at the business case, and deciding to sit on it for now. If anything the predominant action seems to be to apply for an IPv6 prefix, and maybe run a small IPv6 POC or Pilot.

Of course this would all change in flash if next time you called your ISP to move your home DSL or relocate your data centre internet carriage your ISP turned around and dished out V6 addressing instead of IPv4 as their allocation had been depleted  - but we are still a long way from that scenario yet. There is no question that the IPv4 address space is running out or has run out in some regions, but the local registries in region are still happily dishing out IPv4 space.

We can see from the graphic below, the IPv4 depletion rates brakes came on hard in late 2011, but this hasn’t stopped the strong downward trend. My best guess would be that you won’t get more than 3-4 years before the scenario above becomes a reality in some if not all of the regions.

IPv4 Depletion

 

 

 

 

 

 

 

So, to the original question “is IPv6 actually ever going to take off?” ….the answer is “yes, it will”. There are very few alternative high quality technology solutions that have as much existing investment & proven ability that can scale to address the explosion of internet enabled devices that will proliferate in the next decade.

However to reach critical mass to get a wholesale swing to an IPv6 first approach a much heavier v6 take up needs to occur globally and for that there needs to be a compelling reason or trigger event for businesses to consider a proactive investment in IPv6. I will discuss some of these in my next post.

 

 

 

 

Nexus 3000 Family – is it great low cost core switch?

I have generally shied away from recommending that businesses deploy a Nexus 3000 core in their data centres, one of the reasons has been around platform / feature support and the other around NX-OS release trains; for example-

The Nexus 3K is designed for low latency trading environments so that Cisco can compete with Arista and as such low latency is king. This means the advanced features (and maybe silicon, depending on the model) you get will not be as advanced as the traditional enterprise platforms i.e. N5K, N7K etc. Also features such as FCoE, OTV etc have never been road mapped for the N3K. Not surprisingly then the N3K also follows its own release train for NX-OS updates and patches.

That was enough to convince me that this switch should do what its good it and mainly be left in the environment is was designed for. Each time a customer asked me should they deploy this as a core switch my first reaction was “err, probably not”…until recently.

In this particular environment the requirements were fairly straightforward (they mostly are anyway) and could be summed up as;

  • We need 1 & 10G L2 switching on 96 ports at the core
  • We need an IGP and static routing, and a little policy overlaid on that IGP
  • We need high availability across the core, with load sharing & fault tolerance
  • We want to continue to use our existing management tools to manage the environment

In comes the N3K. Now the small set of requirements above are fairly generic, but could be a typical of a 1000 medium size businesses out there today. Given those requirements the final solution ended up looking like;

  • A pair of Nexus 48 port 1/10G switches in a vPC cluster
  • Peripherals connected in via vPC port channels split across boxes (FW’s, Blade, rack, Rtr’s)
  • HSRP, & EIGRP with static route redistribution and some smarts thrown in for fun
  • Standard management with SSH, NTP, SNMPv2, ACLs and role based access controls
  • Plenty of bandwidth with a 40G vPC peer-link between switches, and 20G north/south to the blade servers

In summary, if you don’t need the bells and whistles of advanced DC technology such as Unified Fabric, L2 Multi-pathing, & clever DCI stuff, and can live with a standard L2, L3 design and topology with a known (& constrained) port count capacity, then the N3K may be the switch for you.

Topology Overview

 

IP Local Area Mobility & IP network re-addressing

Cisco LAM enables a host to move to another subnet but keep its original IP address, and still be reachable across the network.

A router/layer 3 switch configured for LAM determines whether there are directly connected hosts that do not belong to the local IP subnet.

When this router sees traffic from a host that does not match the configured subnet, the router installs an ARP entry for the mobile host. The router then also installs a host route that points toward this interface.

The feature could be useful during a LAN refresh or DC relocation, when migrating from old IP ranges to new, if a device is overlooked but LAM is configured, that device will still be reachable even though it will be in the wrong IP subnet. Then the routers ARP cache can be inspected to see what ARP bindings exist, and the missed device can be re-configured.

to configure LAM.

int vlan 20
ip address 192.168.1.1 255.255.25.0
ip mobile arp

to add security (only permit allowed/known mobile host ranges)

int vlan 20
ip address 192.168.1.1 255.255.25.0
ip mobile arp access-group 1

access-list 1 permit 172.16.255.0 0.0.0.255

When using LAM, a router periodically checks to ensure that the mobile host is still there by querying it with ARP requests. This ensures that the redistributed route is still valid. The mobile host ARP keepalive times can be altered with the command:

ip mobile arp timers [keepalive minutes] [hold-time minutes]

The LAM default arp keepalive is 300 seconds with 900 seconds hold timer.

HP 1910 Switches – Intuitive Web Interface?? I think not

HP 1910 Series Switches

According to the specs on the 1910 the web interface is intuitive – which implies simple and easy to use. maybe it is if you have never logged on any other switch in your life…ever.

The 1910 isn’t a bad switch by the way, for the $$$ its actually a winner one you have figured out how to configure the thing. Having configured a few (hundred) switches in my time, inc many OS including ProVision, NX-OS, IOS, EOS, and Comware to name a few I have only been left frustrated and disappointed with two products before. The Cisco 500 series switch, and the HP 1910. Both of these had one thing in common, a slow and fairly annoying HTTP UI.

so, lets make life easy and get into the CLI config of the 1910 setup and config. Log into the console port with the default user admin, password “blank” and copy and paste the following commands to get into the CLI configuration shell.

_cmdline-mode on
Y
512900
system-view

now we can configure the switch from the CLI, using a familiar command set. in the CLI scrape below I am going to add some vlans and set Interface 1/0/1 as voice/data and 1/0/24 as a dot1q uplink.

#
vlan 1
description Default
vlan 7
description SwitchMgmt
vlan 64
description Native
vlan 34
description Voice
vlan 219
description Data
#
interface GigabitEthernet1/0/1
port link-type trunk
port trunk permit vlan 34 219
port trunk pvid vlan 219
undo voice vlan mode auto
voice vlan 34 enable
poe enable
undo port trunk permit vlan 1
#
interface GigabitEthernet1/0/24
port link-type trunk
port trunk permit vlan 7 34 64 219
port trunk pvid vlan 64
stp edged-port disable
undo port trunk permit vlan 1
undo poe enable
#
return
save
display saved

deploying configuration this way is sooo much easier. I get the positioning of these types of products but if the CLI is there already, why not expose it anyway for those that like to do things the easy way?

Cisco WebEx Meetings Server (CWMS) and Microsoft ADFS – Import Phone Numbers

In my latest CWMS deployment we have utilised SAML 2.0 and Microsoft ADFS services for user management. In your standard SAML integration;

  • Users attempting to access CWMS are authenticated via ADFS using their AD credentials
  • A CWMS account is automatically created based on the attributes that ADFS passes back to CWMS

The standard attributes are first name, last name and email address. In this case, we also wanted to populate the users CWMS profile with their telephone number.

To do this, two additional custom claim rules are required.

The first claim rule retrieves number from Active Directory:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => add(store = "Active Directory", types = ("PhoneHolder"), query = ";telephoneNumber;{0}", param = c.Value);

The second claim rule sends the telephone number to CWMS:

c:[Type == "PhoneHolder"] => issue(Type = "OPhoneLocal", Value = RegExReplace(c.Value, "\+61", ""));

In this case the numbers in Active Directory were stored in +E164 format (which we love, but CWMS does not); so there is a regex replace in there to remove the +61 on the way over to CWMS. This is easy at this point as there are only Australian numbers in the system. This would require some more work if it was an international system.

Fortunately ADFS can be configured with other attribute stores such as databases which could give you plenty more options about where to get attributes and what to send across to CWMS.

Testing Quality of Service (QoS) in IP Networks

Various tools exist to test you QoS configurations across your network, but most of these are costly and often tricky to set up.

If you have  a Cisco network there is a simple way to ensure your packet DSCP markings are being carried throughout the environment, just using your Cisco CLI.

The basic set up is this:

Create IP SLA probes destined towards an edge IP address with the IP packet TOS field set from a edge WAN router or L3 switch in the path you wish to measure QoS across.

This will send ICMP packets marked with DSCP across your network. Then you have  a few options as to how you validate the packets markings are carried through the network.

The simplest way to do this is to check the outbound queues on each device in path to see if the QoS queue counters are incrementing at the same rate you are sending your probes, but this can be a problem in a noisy environment.

Another way is to use the inbuilt packet capture feature built into Cisco IOS 12.4 and up. By setting a simple filter you can only capture the IP SLA probe packets, and then export these to Wireshark to check the packet DSCP is intact (or view the packets in the IOS CLI)

An example IP SLA TOS probe is shown below

  • rtr 1
  • type echo protocol ipIcmpEcho 10.1.1.1 source-ipaddr 10.2.1.1
  • request-data-size 200
  • tos 96
  • timeout 1000
  • frequency 10
  • hours-of-statistics-kept 12
  • rtr schedule 1 life 604800 start-time now

 

 

 

Spanning Tree & Virtual Port-Channels

There are a few basic things you should know when creating virtual port channels (vPC) using NX-OS considering the spanning-tree protocol (STP) in your Data Centre.

Enable STP as normal on all links. If a dual attached switch is non port-channel compliant then use STP & ensure only non vPC VLANs are used on the STP switch.

Always make the STP root bridge, vPC primary peer and HSRP active aligned across the chassis -  do not split or try to load-share VLANs using STP root & HSRP odd / even VLAN load sharing  as this may cause packet loss in certain scenarios.

STP is distributed; that is, the protocol continues running on both vPC peer devices. However, the configuration on the vPC peer device elected as the primary device controls the STP process for the vPC interfaces on the secondary vPC peer device

The 3 config lines below are recommended on all devices in the STP domain.

  1. spanning-tree mode rapid-pvst
  2. spanning-tree pathcost method long
  3. spanning-tree port type network default

vPC devices are managed independently and separate instances of network protocols exists on the vPC peers. During the vPC domain setup, a vPC peer is elected as primary. This peer will be responsible for running STP on all the vPC ports of the vPC domain. So logically, a vPC is a simple channel located on the primary vPC peer switch from the perspective of STP. The state of the vPC member ports located on the secondary peer is controlled remotely by the primary.

BPDUs can be exchanged on all the physical links belonging to a vPC. Note that some STP information about the vPCs is still available on the secondary vPC peer, but it is just replicated from the primary.