This week I spent a tone of time working on my HOMELAN with a couple of goals in mind.
- I needed to road-test my employer’s “Agile Connect” SD-WAN product which is based on Nokia Nuage Network’s VNS SD-WAN offering and had to carve off a new VLAN to plug the NSG-E into.
and
- I wanted to ensure my HOMELAN was completely v6-ified once again following several months using Google Wifi without my hosts having native v6.
Connecting my NSG
There are a couple of us in BT Ireland that have been given the task of road-testing the NSGs and indeed our service wrap for this technology which has a product name of “Agile Connect”. The intention is that we have active familiarity with the technology when we are doing customer engagement and can demonstrate our orchestration and reporting portal with ease and comfort.
It’s just another SD-WAN overlay product at the end of the day, but this one is embedded in BT’s core network with the use of what Nokia call UBRs or Underlay Border Routers. Here’s a quick mini diagram from their site giving a sense of what they are;
Generally speaking, BT’s corporate customers task BT with providing them a “managed delivery” of things like MPLS services and that’s true of most large Telco’s I guess. Whereas with SD-WAN offerings obviously you need to be doing what the “hip and cool” vendors can do and that’s ZTP and self-install services. Here’s what’s involved from a ZTP / self-install for BT’s Agile Connect.
- You get the box delivered to your premises directly (clearly)
- You get a little 2 pager with “fool proof” pictures and instructions on how to connect it all up. (at this point BT will have already pre-provisioned the device for the circumstance of the install obviously)
- You provision your device over securely over TLS and allow it to connect to the rest of your overlay network.
All that’s required of me (as the customer) is to provide a WAN link which has connectivity to the public internet. That could be via a direct public internet connection or indeed via a learnt default route from within a L3VPN network such an MPLS based Enterprise WAN network. In my case, it’s stuck behind my HOMELAN broadband connection on a separate NAT’d VLAN.
The installation and provision of the NSG is super easy to be fair and it’s not something that should be considered in any way daunting. The API we’re using to interface into the VSD and VSC (our My Account Portal could be perceived to be clunky though. However you have to bear in mind the relatively complex tasks you are needing to do with SD-WAN connection configuration. For example, you need to determine if you need some logical separation in your WAN ala Multi-VRF configurations in traditional MPLS underlay networks.
For us the litmus test is getting remote LAN to remote LAN communication up and working. For me, as my NAT’d WAN connection on my NSG device is behind not only a router but a firewall, it’s not quite as straightforward for me as it should probably be for others.
The traffic that flows across this (and any Agile Connect) SD-WAN network overlay has a VxLAN over TLS data plane format. I expect to get some time over the weekend to time down why this didn’t come up first time but I have already spotted some clues in my firewall logs.
Return of the IPv6
Many months ago, I changed my old Cisco Aironet AP out for a Google Wifi Puck style Smart AP on my HOMELAN. As far as Wifi is concerned it has greatly improved Wifi experience in my house. I have some pretty tetchy “customers” if there’s a problem with Wifi on the network and so complaints have been few and far between which is a win as far as I’m concerned. An unforeseen outcome of this installation however is the fact that GWF doesn’t play all that nicely with v6 when you sit it down stream of a PPPoE connection behind a router/switch/etc. It requires a v6 PREFIX to be allocated to it and not a v6 Address via SLAAC or something similar. To that end, in order to try and ensure any clients behind GWF get a Global Unicast IPv6 address, a device upstream of GWF must run as DHCPv6 Server and allocate it a PREFIX (ala prefix delegation).
This was a whole heap of fudging that I was prepared to try for a bit, but then gave up on, so when I was requiring a change on my HOMELAN to facilitate the Nuage deployment, I thought it was only right and proper to get my native IPv6 working fully again.
I’m happy to report that this has now been achieved and my clients are all getting a score of 19 out of 20 against IPv6-test.com for instance as per below;
This was achieved in the main by placing my GWF device into “bridge mode”. This essentially renders it a dumb AP as was the predecessor Aironet AP on my HOMELAN. My firewall is happy, my router is doing my DHCP and SLAAC and I’ve tested inbound SSH to clients via IPv4 and IPv6. Happy with that result and it far outweighs and lost functionality in changing the GWF from standard to BRIDGE mode.
Now to deploy some test traffic onto our SD-WAN test network.