Why Is Every SDN Vendor Bashing the Networking Engineers?
This blog post was written almost two years ago (and sat half-forgotten in a Word file somewhere in my Dropbox), but as it seems not much has changed in the meantime, it’s time to publish it anyway.
I was listening to the fantastic SDN Trinity podcast while biking around Slovenian hills and almost fell off the bike while furiously nodding to a statement along the lines of “I hate how every SDN vendor loves to bash networking engineers.”
Read more ...Poland’s Poznań Science and Technology Park Upgrades Its Infrastructure-as-a-Service Model with VMware NSX
Poznań Science and Technology Park—known in Polish as Poznańskiego Parku Naukowo-Technologicznego, or PPNT—supports the incubation of start-ups and technology companies in Poland through co-operation with science, business, and technology enterprises. Its facilities and services include laboratories, office space, and specialized research equipment, as well as IT infrastructure services like server colocation and hosting, system monitoring servers, storage space, and data transmission infrastructure leasing.
To build a virtual, multi-tenant, private infrastructure-as-a-service cloud, on a flexible billing schedule, for its demanding customers, PPNT opted for an integrated solution that included VMware vSphere, VMware vCloud Director, and VMware NSX. The business benefits became clear immediately. PPNT’s new, high-performance environment enabled robust management capabilities, and guaranteed security and fault-tolerant access. Plus, resource provisioning time was reduced from days to seconds.
Says manager of the PPNT DataCenter Tomasz Łukaszewicz: “VMware NSX, the network virtualization platform for the Software-Defined Data Center, enables our customers to create, save, delete, and restore virtual networks on demand, without reconfiguring the physical network. It also provides a better security model.”
Read the complete case study
The post Poland’s Poznań Science and Technology Park Upgrades Its Infrastructure-as-a-Service Model with VMware NSX appeared first on The Network Virtualization Blog.
Firepower Threat Defense — DNS Sinkholing
A few days ago I wrote an article that described Firepower DNS Policies. One item that probably warrants a little more discussion is DNS Sinkholing. Although the title of this article indicates Firepower Threat Defense, this will also work with Firepower and Firepower Services.
For this article, I would like to first share some of the challenges around getting security intelligence visibility from DNS requests. A typical enterprise environment will have an internal DNS server. So even though we know we can return “Domain Not Found” with an FTD DNS policy, that might not give us the visibility necessary to remediate a problem.
So if the host in the diagram below makes a DNS request for bad.site.com, what happens? Basically that request is sent to the DNS Resolver. The DNS Resolver will look to the Root Hints and eventually get the request to an Internet based DNS server that has the appropriate domain ownership. The problem with this is that the only request seen by the Firewall (FTD in our example) is the one made by the DNS Resolver. The problem here is that there is no way the Firewall can tell which host needs to be scrubbed by Continue reading
SK Telecom & KPN Deploy Nationwide LoRa IoT Networks
LoRa networks will likely co-exist, not compete, with cellular IoT.
Testing the EIGRP Feasibility Condition (FC)
Last night I was going through some CCIE Routing and Switching VOD’s and found a statement I found interesting. Beyond the fact that I thought the content was far below the expert level (which is fine because a refresher or level-set is typically helpful), I believed it to be incorrect. The statement that was made is as follows:
“A neighbor meets the feasibility condition if the reported distance by the neighbor is the same as or smaller than the feasible distance of the router”
So what are my issues with this statement? First, I thought “feasible distance of the router” is ambiguous and could be assumed to be the advertised distance or the reported distance which is basically the feasible distance of the neighboring router. However, that was not my main problem with the statement. My main concern with this statement is that I have always learned that the feasibility condition is only met if the reported distance (RD) is strictly less than the feasible distance of the local route. So I set out to determine if I had a correct understanding or if the Feasibility Condition (FC) could really be met with a RD equal to the FD.
To test my theory, Continue reading
Telefónica Chooses Cisco’s Network Services Orchestrator
Cisco’s orchestrator uses YANG modeling from Tail-f.
Worth Reading: Little bits of security
The post Worth Reading: Little bits of security appeared first on 'net work.