Mathias Rosenthal - Fotolia

SN blogs: Can cloud-based routing do the trick?

This week, bloggers assess how Volta Networks is shifting to cloud-based routing, device identification, and IPv6 and VLAN interfaces.

Drew Conry-Murray, writing in Packet Pushers, examined the technology behind Volta Networks, a startup whose mission is to replace the traditional physical router. The company is moving to a cloud-based routing system. The router control plane communicates with a software agent installed on a white box device, with the ability to run Border Gateway Protocol or Open Shortest Path First in containers.

According to Conry-Murray, Volta's offering has three main elements: a cloud-based routing system, a routing agent and a white box switch geared for supporting multi-tenancy. Volta uses the Free Range Router as its routing protocol, Apache Mesos for orchestration and APIs to interact with Merchant silicon. The routing agent comes armed with policies to allow it to operate autonomously in the event of a loss of connection, and it has the ability to split a physical device into 250 virtual routers.

"Volta is one of many companies reimagining how traditional network hardware and software can be taken apart and stitched back together," Conry-Murray said. "These companies aren't just disrupting for the lulz [laughs]; their goals are to make networks more amenable to automation, to streamline code bases and decouple software development lifecycles from hardware development, to enable greater flexibility and programmability, and to more fully take advantage of merchant silicon."

Read more of Conry-Murray's thoughts on Volta Networks' cloud-based routing.

Managing a multiplicity of devices

Jon Oltsik, an analyst with Enterprise Strategy Group Inc., in Milford, Mass., assessed the soaring number of connected devices -- as many as 50 billion by 2020, according to some researchers -- and said he sees challenges for traditional processes and controls.

"Moving forward, everything on the internet must have a trustworthy identity," Oltsik said. In his view, connecting and identifying devices needs to move beyond Layer 2 and 3 protocols and basic passwords. Instead, the focus needs to be on the "Internet of Identities," a trend that Oltsik said he sees emerging in microsegmentation and software-defined perimeters.

To achieve device identification, Oltsik identifies strong authentication for internet-of-things devices and cloud oversight as fundamental. Better user behavioral analytics and software-defined networking technologies will also be needed, along with standards such as OpenID, FIDO, SAML or OAuth.

To achieve these goals, Oltsik said CIOs and companies must adopt a  comprehensive oversight strategy to oversee identity management.

Dig deeper into Oltsik's thoughts on device identification.

IPv6, link-local addresses and VLAN interfaces

Ivan Pepelnjak, writing in ipSpace, was asked by a reader why it's not possible to have different IPv6 link-local addresses (LLA) for every access port connected to a virtual LAN (VLAN) interface. According to Pepelnjak, there's actually nothing stopping an engineer from adopting this approach, although it would go against the usual method of bridging and routing with Layer 2 and Layer 3 switches. He added that a VLAN interface -- and any Layer 3 interface -- should have a unique MAC address. For a Layer 2 and 3 switch, a unique MAC address is needed for each physical interface.

Pepelnjak said, theoretically, a VLAN interface can reuse a MAC address from a physical interface. But, he added, ordinarily, this implementation detail doesn't matter, because MAC addresses need to be unique to a single Layer 2 domain. An IPv6 interface is usually assigned only one LLA; therefore, the VLAN interface only gets a single LLA.

"Physical access ports connected to a VLAN instance are not L3 ports, and thus don't get a L3 address. Quite often they don't even need a L2 address," Pepelnjak said. "Interestingly ... it looks like some vendors decided to move in the opposite direction: they use the same IPv6 LLA on all IPv6 interfaces present in a network device. Yet again, that shouldn't be a problem (after all, LLAs are supposed to be unique only within a single L2 domain) until you're forced to connect two IPv6 interfaces back-to-back to implement whatever design not supported by the underlying hardware," he added.

Explore more of Pepelnjak's thoughts on IPv6 and VLAN interfaces.

Next Steps

Distinguishing between ACI and SDN

Best design for IoT device iteration

How to use an interface identifier with IPv6

Dig Deeper on Network infrastructure