Category: service providers

Video: Challenges of Managed SD-WAN Services

When I published a link to the Is MPLS/VPN Too Complex? blog post to LinkedIn, someone asked whether I’m skeptical about service provider SD-WAN services due to lack of skills, and Kristijan Taskovski quickly identified the root cause in his reply:

The argument of a lack of skill is only one that is perpetuated by businesses. It’s not perpetuated by engineers. People that are trained, honed, and knowledgeable are expensive. Expense is the number one enemy for a business.

That’s exactly why I think most managed SD-WAN services will be a dismal failure.

read more see 1 comments

SD-WAN: A Service Provider Perspective

A reader of my blog was “blessed” with hands-on experience with SD-WAN offered by large service providers. Based on that experience he sent me his views on whether that makes sense. Enjoy ;)


We all have less-than-stellar opinions on service providers and their offerings. It is well known that those services are expensive and usually lacking quality, experience, or simply, knowledge. This applies to regular MPLS/BGP techniques as to - currently, the new challenge - SD-WAN.

read more add comment

Who’s Pushing Layer-2 VPN Services?

Here’s another great point Tiziano Tofoni raised in his comment to my EVPN in small data center fabrics blog post:

I cannot understand the usefulness of L2 services. I think that the preference for L2 services has its origin in the enterprise world (pushed by well known $vendors) while ISPs tend to work at Layer 3 (L3) only, even if they are urged to offer L2 services by their customers.

Some (but not all) ISPs are really good at offering IP transport services with fixed endpoints. Some Service Providers are good at offering per-tenant IP routing services required by MPLS/VPN, but unfortunately many of them simply don’t have the skills needed to integrate with enterprise routing environments.

read more see 10 comments

Networking Is Infrastructure – Get Used to It

Jeff Sicuranza left a great comment to one of my blog posts:

Still basically the same old debate from 25 years ago that experienced Network Architects and Engineers understood during technology changes; "Do you architect your network around an application(s) or do you architect your application(s) around your network"

I would change that to “the same meaningless debate”. Networking is infrastructure; it’s time we grow up and get used to it.

read more see 5 comments

Don’t Use ULA Addresses in Service Provider Core

Dan sent me the following question:

I had another read of the ‘Building IPv6 Service Provider Networks’ material and can see the PE routers use site local ipv6 addressing. I’m about to build another small service provider setup and wondered: would you actually use site local for PE loopbacks etc, or would you use ULA or global addressing? I’m thinking ULA would be better from a security point of view?

TR&DR summary: Don’t do that.

read more add comment

Deutsche Telekom TeraStream: Designed for Simplicity

Almost a year ago rumors started circulating about a Deutsche Telekom pilot network utilizing some crazy new optic technology. In spring I’ve heard about them using NFV and Tail-f NCS for service provisioning … but it took a few more months till we got the first glimpses into their architecture.

TL&DR summary: Good design always beats bleeding-edge technologies

read more see 8 comments

MPLS/VPN Carrier’s Carrier – Myth or Reality?

Andrew is struggling with MPLS/VPN providers and sent me the following question:

Is "carriers carrier" a real service? I'm having a bit of an issue at the moment with too many MPLS providers […] Carrier’s carrier would be an answer to many of them, but none of the carriers admit to being able to do this, so I was wondering if it's simply that I'm speaking to the wrong people, or whether they really don't...

Short answer: I have yet to see this particular unicorn roaming the meadows of reality.

read more see 16 comments

Juniper MX Routers – all you ever wanted to know

During a recent ExpertExpress engagement I got an interesting question: “could we do per-customer policing and shaping on an MX-80 if we want to offer VPLS services and have Q-in-Q encapsulation on customer-facing links?” As I have preciously little Junos/MX knowledge, it was time for the classic “I’ll get back to you” reply and some heavy research.

You probably know how hard it is to find in-depth information on an unknown platform running unfamiliar software. Fortunately, Doug Hanks (@douglashanksjr) sent me a review copy of his new Juniper MX Series book a while ago. It was time for some serious reading.

read more see 4 comments

The best of RIPE65

Last week I had the privilege of attending RIPE65, meeting a bunch of extremely bright SP engineers, and listening to a few fantastic presentations (full meeting report @ RIPE65 web site).

I knew Geoff Huston would have a great presentation, but his QoS presentation was even better than I expected. I don’t necessarily agree with everything he said, but every vendor peddling QoS should be forced to listen to his explanation of the underlying problems and kludgy solutions first.

read more see 1 comments

The Difference between Metro Ethernet and Stretched Data Center Subnets

Every time I rant about large-scale bridging and stretched L2 subnets, someone inevitably points out that Carrier (or Metro) Ethernet works perfectly fine using the same technologies and principles.

I won’t spend any time on the “perfectly fine” part, but focus on the fundamental difference between the two: the use case.

read more see 6 comments

Do we need DHCPv6 Relay Redundancy?

Instead of drinking beer and lab-testing vodka during the PLNOG party I enjoyed DHCPv6 discussions with Tomasz Mrugalski, the “master-of-last-resort” for the ISC’s DHCPv6 server. I mentioned my favorite DHCPv6 relay problem (relay redundancy) and while we immediately agreed I’m right (from the academic perspective), he brought up an interesting question – is this really an operational problem?

read more see 3 comments

IPv6 End User Authentication on Metro Ethernet

One of the areas where IPv6 sorely lacks feature parity with IPv4 is user authentication and source IP spoofing prevention in large-scale Carrier Ethernet networks. Metro Ethernet switches from numerous vendors offer all the IPv4 features a service provider needs to build a secure and reliable access network where the users can’t intercept other users’ traffic or spoof source IP addresses, and where it’s always possible to identify the end customer from an IPv4 address – a mandatory requirement in many countries. Unfortunately, you won’t find most of these features in those few Metro Ethernet switches that support IPv6.

read more see 14 comments
Sidebar