A network geek pilgrimage – Networking Field Day 14

What is Networking Field Day?

Networking Field Day 14 or #NFD14 is almost upon us! I am heading to sunny San Jose, California to drink from the fire hose of data – the heavens will part and rain down golden non-fragmented packets of information and insight.

If you’re not familiar with Networking Field Day, which is part of Tech Field Day hosted by Gestalt IT, you can go here to get a full overview.

The Delegates

Networking Field Day is rare opportunity for individuals (delegates) that are engaged in the practice of network engineering/architecture to come together and interact not only with the vendors who are presenting but also fellow delegates.

While some of the delegates have attended previous Tech Field Day events, others, like myself are first timers and will be taking in the vast array of technical content as fast as our buffers permit.

The delegates comprise a group of like-minded and yet diverse networkers that are heavily invested in the community of network engineers and IT.

It’s truly a privilege to be be invited to NFD14 and I count myself fortunate to be in the company of some incredibly sharp practitioners of IP networking – a special and very sincere thanks to Tom Hollingsworth (@networkingnerd)   for inviting me!

The Format

NFD14 sets the pace with scheduled vendor presentations on products and solutions that form a large part of the three day event. Time is also allocated to podcasts to foster some free-form discussion about the presentations.

Beyond that, it is an overall forum for the exchange of ideas, opinions, some healthy debate about technology and the opportunity to learn from some of the smartest people in the business. What makes the event even more exciting is that it is live streamed for all 3 days and encourages participation from those watching remotely by sending questions in via twitter or other social media.

And if all of that weren’t enough – an added bonus – certain vendor presenters like Big Switch, Riverbed and Juniper will host us at their corporate headquarters.

The Presenting Sponsors 

Here is the list of network vendors that we will interact with during NFD14. Drew Conry-Murray (@Drew_CM) of the Packet Pushers (who is also one of the delegates) has written a great overview of the vendors and a summary of what they do here.

Meat and Potatoes – The Tech – Part 1

Describing this event as a network geek pilgrimage is accurate but might even be an understatement as most of the delegates, like myself eat, sleep and breathe this stuff.

I mentioned on twitter a few days ago that when I was a kid, I wanted to go to Space Camp. But now as an adult, I want to go to Network Camp in the form of NFD14 (and I still want to go to Space Camp) What I am most looking forward to is the nerdy deep dives into the black hole of design, protocols, future technology, SDN and the like.

There are a number of topics that are likely to be heavily discussed at NFD14 starting with SDWAN. In order to keep this article to reasonable length, i’ll be covering thoughts on Analytics, Automation and Switching (whitebox and programmable) in a second post.


When everyone got tired of saying the word “Cloud”, SDWAN stepped in to save the day as it seems to be all the rage these days.  And with good reason – SDWAN has started us down the road to solving problems we have coped with for too long – things like the inability to use all of the bandwidth available to an organization or use cheaper off-the-shelf Internet connections to offset or complement more expensive MPLS transport.

The presenting vendors that will be at NFD14 with SDWAN solutions include Silver Peak and Riverbed. Juniper also touts an SDWAN solution, but they have a vast portfolio of solutions, so it’s not totally clear if Juniper will talk about SDWAN.

How does it work?

While I get what SDWAN does at a high level with overlays and dynamic policies that help to provide a mesh of connectivity, I still don’t have a good feel for what’s under the hood and would like to understand the deeper mechanics of how SDWAN works and the differences between vendors in the underlying technology.

Use cases I’m interested in

SDWAN presents a number of possibilities for the work I am engaged in. The most obvious use case is that of a large enterprise with a vast array of circuits and remote sites and that solution is fairly well documented and covered. However, SDWAN also interests me for more non-traditional applications like that of a Wireless ISP or WISP.

WISPs rely on Point-to-Point RF commercial RF links and backhauls to connect towers together. Like most ISPs, the trifecta of MPLS/BGP/OSPF is commonly found to manage the routing in this environment.

SDWAN deployment in WISPs?

But unlike most ISPs, you can’t put 100 gig transport link up on an RF tower just yet, so the speeds are more in the realm of anywhere between 100 Mbps and 1 gig. The technology does exist to go beyond 10 gig in RF but it’s insanely expensive and with a limited range.

One of the challenges that SDWAN has the potential to solve is the disparity between the speed of the links and even the fact that capacity of an RF link is an elastic value – it can be 900 Mbps one minute and drop the modulation to 700 Mbps during a lightning storm.

This is an almost impossible problem to solve with traditional routing protocols and seems well suited to the world of SDWAN.

The lower speeds in RF transport allow for the possibility of an SDWAN overlay at key tower aggregation points to more effectively use bandwidth and set SLAs for QoS.  Although we have made great strides in WISP design like the OSPF transit fabric to better utilize unequal links, there still isn’t an application aware control plane. It would be very interesting to mix the OSPF transit fabric with SDWAN and see if they can co-exist.

Riverbed is more Enterprise focused in its solution and I work with Riverbed frequently for Enterprise clients, so I’m very interested in how the SteelConnect product meshes with the SteelHead WAN optimization platforms.

Silver Peak and Juniper both have service provider portfolios, so i’ll be interested to see the differences in what SDWAN means for both the Enterprise and ISPs.

Overall, SDWAN represents a drastic paradigm shift in WAN connectivity and I count myself fortunate to have the opportunity to spend several days looking at the nuts and bolts of what makes the SDWAN magic happen.

Stay tuned for Part 2 – Analytics, Automation/Orchestration and White Box/Programmable Switching!

Be sure to follow me on twitter @stubarea51 and look for the #NFD14 hashtag over the next few days. Please feel free to send me any questions you have for the vendors or the group in general!


Read More

MikroTik RouterOS new feature – Loop Protect


‘Loop Protect’ – New feature in 6.37rc24

Long-time MikroTik users have been after better loop prevention mechanisms for quite a while now. Rapid STP within bridges was the only feature available up until Fall of 2016 and now MikroTik has released Rapid Spanning Tree in hardware for switched ports as well as a new Loop Protect feature that seems to serve the same function as Cisco’s Loop Guard but not utilize spanning tree to detect the loop. MikroTik’s version compares the source MAC of the loop protect frame with the MAC of the interface it is received on and if they match, it will disable the port until the timer expires and check again for the existence of a loop.

This feature was introduced in 6.37rc24 on August 31st, 2016.



Use cases for ‘Loop Protect’

Loop protect seems to be designed more as an edge port protocol since it physically disables the port upon detection of a loop, whereas STP will leave the port physically active but logically block traffic on that path.  Some potential use cases for enabling this feature could include:

  • Edge port on a MikroTik device facing the end subscriber equipment – this would cut down on loops (and outages) that feed back into the ISP because of subscribers plugging in “dumb” switches, hubs or bridged routers.
  • Edge port for an Enterprise or SMB user device to prevent loops causing a larger outage from unauthorized switches/hubs that have been plugged in on the edge port.
  • Data Center edge port for servers, routers or other devices that shouldn’t create a loop but still have the capacity to do so. An example would be a mis-configured vSwitch in a hypervisor.
  • Downstream switch connected to a router or switch that doesn’t have a physical topology that will allow a loop in normal operation, however, a cable plugged into two ports on the same switch or a down stream switch could still send a broadcast storm towards the port.

‘Loop Protect’ in the StubArea51 test lab

Below is an example lab we built to test the Loop protect feature. The idea was to intentionally create a loop between two Cisco 3750 switches that would propagate looped frames and broadcasts towards the ethernet port on a MikroTik CRS125 with Loop Protect enabled.

Click on the image for a larger version


Enabling the ‘Loop Protect’ feature in WinBox

By default, the feature is disabled. To enable it, you select the interface to enable it on –> navigate to the ‘Loop Protect’ tab –> select the first drop down menu and set it to on (some versions of 6.37 have a bug that show more than the three available settings of default,on and off). You can also adjust the ‘Send Interval’ which controls how frequently Loop Protect frames are sent out of the interface. There is a ‘Disable Time’ value that can be set which starts counting down as soon as a loop is detected and will bring the interface back online after the timer is expired and check again for the existence of a loop. This interface will cycle through disabling the interface and the disable timer so long as a loop is present.


Detecting a loop with ‘Loop Protect’ enabled 

In the hardware lab above, we connected a second cable between two Cisco 3750 switches with spanning tree turned off and ‘Loop Protect’ detected the loop almost immediately as indicated by the message in red at the bottom of the picture below. The status has now been changed to disabled until the loop clears and the disable timer expires.

LoopProtect-Enabled with a loop detected

‘Loop Protect’ in the log

Like all good features, ‘Loop Protect” will add status messages to the log which show the following as the loop is detected and then cleared. If you send your log messages to an external syslog server, then you can create alerts to let you know when a port has gone down due to a loop.

  • 11:17:08 – Loop is detected
  • 11:17:08 – ether1 goes into disabled state
  • 11:22:11 – The loop is cleared by the disable timer expiring (after unplugging the rogue cable between switches)


Read More