This post is a response to Greg Ferro’s recent Basics
posts on (Content Addressable Memory) CAM tables. As this is a response post, you can assume that I don’t agree entirely with all of his definitions. Alternatively, perhaps I am totally wrong and I need to go back and relearn how CAM works. Either way, Greg loves a good spar, so maybe together with our readers we can determine the truth in an understandable format for the betterment of everybody who isn’t a hardcore digital electronics engineer.
Before continuing, I’d recommend should go reading these posts as context, since they are the basis for this post:
Basics: What is Content Addressable Memory (CAM) ?
Basics: What is Binary CAM (BCAM) ?
Basics: What is Ternary Content Address Memory (TCAM) ?
I’ll now address my concerns post by post below.
A CAM cell in the chip actually consists of two SRAM cells. SRAM requires requires extensive silicon gates to implement that require a lot of power per gate for fast switching. In a chip, power consumption generates heat and leads to limits on thermal dissipation by the limited footprint of a chip. This is a key factor on the Continue reading
Containers are hot, but container security is still in its early stages.
New startups have burst onto the scene, promising to shake up networking and storage.
Infrastructure standardization is key to achieving the cost benefits of SDN.
Yes, it's possible to check every possible data flow. Kind of.
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 ...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.”
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.
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