Cumulus Networks published a new case study about my work with them on my recent datacenter network rebuild using Cumulus Linux on Dell Open Networking switches and about how we have used Cumulus NetQ as fabric validation system.
Cumulus also published a press release a few weeks ago with one of my quotes about NetQ I made when we were working on the case study.
“With NetQ, we can run small check commands and see what really is going on in our network,” said Bernd Malmqvist, Tech Lead Systems Operations at SmartGames Technologies. “The benefits to us are early alerting and validating the entire state of the fabric. Monitoring is one thing, but with NetQ, the knowledge is instant. NetQ is really unique; it’s a tool that tells us exactly what is wrong in our environment, and the insight to know where an issue is stemming from.”
After VMware invited me to speak on the Customer Panel at last year’s VMworld 2017 in Barcelona, VMware came back to me again and asked if they could write a case study about the VMware NSX deployment I have done at my company.
This is my first case study and it’s nice that VMware thought the story was worth sharing. Have a look and read the case study here:
VMware invited me to be a speaker at a customer panel about VMware NSX at VMworld Europe 2017. I am exited to get the opportunity and share my experience together with other customers in deploying and running VMware NSX in modern datacenter environments.
Here the session information and schedule:
“In this session, a number of VMware NSX customers will discuss how NSX has been used in their environments, specifically focusing on how their organisation has benefited from security, automation, and application continuity-related projects.”
Something a bit different now from what I posting normally, this time about common DNS errors.
One of colleagues tried to configure basic DNS load balancing over two web platforms but instead of using two A records he were using one A record and one CNAME. Ones that was configured the problems started because some DNS server (google DNS cache) were only replying with the IP of the configured CNAME, other DNS servers from service providers were replying with nothing.
Bind per default would only add the CNAME into the configuration and ignore all other records but my colleague were using TinyDNS so I cannot say if TinyDNS load the configuration with both CNAME and A records. But the main reason of the problems was that the DNS configuration got inconsistent and the RFC for common DNS errors explained it very clearly:
A CNAME record is not allowed to coexist with any other data. In other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you can't also have an MX record for suzy.podunk.edu, or an A record, or even a TXT record.