Category: WAN

A while ago we published a guest blog post by Christoph Jaggi explaining the high-level security challenges of most SD-WAN solutions… but what about the low-level details?

Sergey Gordeychik dived deep into implementation details of SD-WAN security in his 35C3 talk (slides, video).

TL&DW: some of the SD-WAN boxes are as secure as $19.99 Chinese webcam you bought on eBay.

Christoph Jaggi, the author of Transport and Network Security Primer and Ethernet Encryption webinars published a high-level introductory article in Inside-IT online magazine describing security deficiencies of SD-WAN solutions based on the work he did analyzing them for a large multinational corporation.

As the topic might be interesting to a wider audience, I asked him to translate the article into English. Here it is…

Andy sent me this question:

I'm currently playing around with BGP & VXLANs and wondering: is there anything preventing from building a virtual IXP with VXLAN? This would be then a large layer 2 network - but why have nobody build this to now, or why do internet exchanges do not provide this?

There was at least one IXP that was running on top of VXLAN. I wanted to do a podcast about it with people who helped them build it in early 2015 but one of them got a gag order.

One of my readers sent me this question:

I'm in the process of researching SD-WAN solutions and have hit upon what I believe is a consistent deficiency across most of the current SD-WAN/SDx offerings. The standard "best practice" seems to be 60/180 BGP timers between the SD-WAN hub and the network core or WAN edge.

Needless to say, he wasn’t able to find BFD in these products either.

Does that matter? My reader thinks it does:

One of my friends sent me this design challenge:

Assume you’re migrating from another WAN transport technology to MPLS. The existing network has 3000 routes but the MPLS carrier is limiting you to 1000 routes. How could you solve this with MPLS?

Personally, I think MPLS is a red herring.

Another question from someone watching my Designing Active-Active and Disaster Recovery Data Centers webinar (you know, the one where I tell people how to avoid the world-spanning-layer-2 madness):

In the video about parallel application stacks (swimlanes) you mentioned that one of the options for using the R/W database in Datacenter A if the user traffic landed in Datacenter B in which the replica of the database is read-only was to redirect the user browser with the purpose that the follow up HTTP POST land in Datacenter A.

Here’s the diagram he’s referring to:

Michael Klose left an interesting remark on my Regional Internet Exits in Large DMVPN Deployment blog post saying…

Would BGP communities work? Each regional Internet Exit announce Default Route with a Region Community and all spokes only import default route for their specific region community.

That approach would definitely work. However, you have to decide where to move the complexity.

One of my readers was watching the Building Active-Active Data Centers webinar and sent me this question:

I’m wondering if you have additional info on how to address the ingress traffic flow issue? The egress is well explained but the ingress issue wasn’t as well explained.

There’s a reason for that: there’s no good answer.

Continuing the Do Enterprises Need VRFs discussion, let’s see which enterprise networks might need MPLS.

Do you need VRFs?

Read the previous blog post. If the answer is NO, you can stop reading. Otherwise, carry on.

One of my readers sent me a long of questions titled “Do enterprise customers REALLY need VRFs?”

The only answer I could give is “it depends” (it’s like asking “Do animals need wings?”), and here’s my attempt at building a decision tree:

You can use the decision tree to figure out whether you need VRFs in your data center or in your enterprise WAN.

One of my readers watched my TCP, HTTP and SPDY webinar and disagreed with my assertion that shaping sometimes works better than policing.

TL&DR summary: policing = dropping excess packets, shaping = delaying excess packets.

Here’s the picture he sent me (watch the video to get the context and read this article to get the background details):

One of my long-time regular readers sent me this question:

I was wondering if you have had any interest in putting together an SD-WAN overview/update similar to what you do with data center fabrics where you cover the different product offerings, differentiators, solution scorecard…

That would be a good idea. Unfortunately the SD-WAN vendors aren’t exactly helping.

Here are the outlines of an interesting ExpertExpress discussion:

• A global organization wanted to connect data centers across the globe with a new transport backbone.
• All the traffic has to be encrypted.

Should they buy L2VPN and use MACsec on it or L3VPN and use GETVPN on it (considering they already have large DMVPN deployments in each region)?

One of my ExpertExpress design discussions focused on WAN network design and the need for OSPF areas and summarization (the customer had random addressing and the engineers wondered whether it makes sense to renumber the network to get better summarization).

I was struggling with the question of whether we still need OSPF areas and summarization in 2016 for a long time. Here are my thoughts on the topic; please share yours in the comments.

Eluehike Chedu asked an interesting question after my explanation of why stretched ACI fabric (or alternatives, see below) is the least horrible way of stretching a subnet: What about OTV?

Time to go back to the basics. As Dinesh Dutt explained in our Routing on Hosts webinar, there are (at least) three reasons why people want to see stretched subnets: