Category: WAN
Security Aspects of SD-WAN Solutions
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…
Could We Build an IXP on Top of VXLAN Infrastructure?
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.
Lack of Fast Convergence in SD-WAN Products
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:
Reducing the Number of Transported Routes
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.
Swimlanes, Read-Write Transactions and Session State
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:
Where Do You Want to Move the Complexity?
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.
Q&A: Ingress Traffic Flow in Multi-Data Center Deployments
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.
Do Enterprises Need MPLS?
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.
Do Enterprises Need VRFs?
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.
Policing or Shaping? It Depends
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):