Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

How WAN Design Is Changing: Page 2 of 2

 

Metro Ethernet

One other WAN alternative is Metro Ethernet. Generally, this is used as a single WAN interconnecting all sites, rather than using Ethernet Virtual Circuits (via VLAN tagging) for site-to-site circuit-like connections.

When using Metro Ethernet, we recommend attaching all sites via Layer 3 routers or switches, since large Spanning Tree domains are a Really Bad Idea. If you attach via L3 switches (very tempting, cost saving), bear in mind you cannot do traffic shaping to sub-line rate contractual speeds. If you do that and your Metro Ethernet provider does policing, don’t expect good VoIP and video quality. The alternative is to spend more, and use routers to connect. That enables you to shape to near-end or far-end access speed.

One caveat: Routers attached to a single VLAN causes a mesh of routing adjacencies. This is not great (many routing neighbors), and you’ll want to watch the scaling. OSPF and IS-IS can be tweaked to be less chatty. Regionalizing such meshes might be a good idea, for scalability.

A NEWS design

One regionalization approach is what I’ll call the NEWS approach (North, East, West, South). Here’s a version of that, where there is decentralized internet and the diagram shows DMVPN or possibly SD-WAN access to a colo-based corporate backbone and corporate data centers and perhaps firewalled corporate cloud-based applications (not shown). That begs the question of why not secure corporate apps by shifting to a SaaS model with a focus on individual access controls rather than a secured perimeter? (YABT: Yet Another Blog Topic.)

 

One might do this sort of thing for geo-diversity. It also would make the corporate backbone independent of datacenters, useful if the datacenters/locations might be subject to change.

How to make this work with IWAN’s PfRv3 is not immediately clear, therefore left as a thought exercise for the reader.

Other notes

Per The Death of Transit? by Geoff Huston, cloud data center-centric backbones are rapidly becoming the biggest, lowest latency connections out there. On the other hand, you may well face costs for cloud-to-cloud data export.

Equinix touts their neutrality as to external connectivity: They have no backbone per se, but connect well to high-speed MPLS and other WAN providers, or to cloud providers. A regional Equinix colo strategy thus gets you “close” to some big pipes. See also “Equinix Performance Hub.”

Office 365 does geo-location of cached content based on DNS recursion and how the DNS recursion traffic gets to the internet. I see that as mostly being a question of where you put your DNS recursion in relation to your internet egress points. External-facing DNS in colo facilities (around the world!) is one possibility. This is a possible topic to revisit in detail at another time (blog).

A somewhat different topic is providing good customer experience for a retail or banking application, etc. There’s a case to be made that you want your website hosting location(s) to be directly connected to the ISPs serving your customer base, “getting ‘close’ to your customer.”

This article orginally appeared on the NetCraftsmen blog.