Recent DDoS reports against a major DNS provider have brought to light weaknesses when too much dependency is put on sole providers of cloud services. What became even more apparent — and shocking to say the least — was the level of dependency major Internet content providers such as Twitter and NetFlix, to name a couple of them, placed on these SaaS and IaaS providers without sufficient redundancy. Expecting major cloud services to not fail on the assumption that they are too big to fail and should have adequate high availability in place to prevent catastrophic failure begged for trouble. Just as in real life, clouds form, drift along, then evaporate, so should our expectations be with cloud providers.
Home > Blog
Broadcasting news, tips, and troubleshooting on networking technologies.
Google’s DNS registration of .PROD through its Charleston Road Registry has caused some name resolution issues internally when using non fully qualified domain names (non-FQDNs). For those of us who have DNS search suffix lists that attempt to resolve shorter names in a PROD domain by appending an example.com suffix to yield .prod.example.com, you may see now unexpected answers in DNS.
Any names being resolved that end in “.prod” with “example.com” in your search list no longer works. Since .prod is now a valid gTLD (generic top-level domain), DNS is attempting to resolve this through Google’s registry.
All ip helper-address lines configured in your VLAN take the DHCP broadcast from the client, add the router’s (gateway) address into the UDP packet, then unicasts to the DHCP servers. [I’m sure the packet rewrite is only done once, then a copy sent to each DHCP server.] All the listed servers configured receive the DHCPDiscover packet by the router relay.
The redundancy of your DHCP servers not only depends on your OS, but the specific version! For Windows, your options range from a true split-scope in Windows 2008 R2 to active-failover redundancy in Windows 2012. For not-so-robust DHCP servers (i.e., Windows 2003), you can manually configure a split-scope. Common recommendation is the 80/20 rule with 80% of the leases configured on what you (and you alone) consider your primary DHCP server and 20% on the secondary. Exclusions get added to each DHCP server as they have overlapping scopes.
In order of preference/priority, what factors do you consider in driving an upgrade (or downgrade) with Cisco IOS? If no compelling factors exist, how long would you allow a particular version of IOS to stay running? I’ve seen some switches with uptimes > 5 years. And when upgrading, how is the specific IOS release identified as the upgrade target?
In order of preference/priority, best practice tends to dictate an upgrade based on these factors:
- Vulnerabilities, vulnerabilities, vulnerabilities!
- Attaining new features not currently available— new cards/modules have a “first sup
- Migrating away from retired release trains
- Matching versions on more recently deployed and similar hardware
Comments will be moderated. Non-networking, commercialized, or spam topics will be punted at the discretion of the moderator.