Tag: Cisco

blacklist_secint_eventsLast week I had a situation where an external client was reporting a complete inability to access any of our internet-accessible resources. If they changed IPs, though, they were fine. Considering it was over the Labor Day weekend, that we hadn’t changed *anything*, and that only this one client was having the problem, it seemed clear that the cause wasn’t on my side. They were small with outsourced IT, though, so pointing the finger back didn’t help much.

The fly in the ointment even for pointing at a cause was also that I didn’t have any logs of their traffic getting dropped. Normally I can search for initiating IPs or zoom into a small time window and find connections. Not this time. That left me with my own mental loophole of doubt about whether I actually did have an issue on my end.

So I opened a case with Cisco TAC, gave them the troubleshoot file dumps and asked for analysis. They stumbled some because I wasn’t able to attempt a reproduction on demand, since I didn’t have access to the client’s network to try things. TAC tried disabling some completely unrelated Snort rules, which did nothing (as expected). Eventually, I added a temporary explicit trust rule on their traffic so that they could regain access while we dug deeper. Once allowed, the connections were visible in FireSight Management Center (Defense Center) > Analysis > Connections > Events.

A couple days later, TAC returned with the root cause. The Sourcefire Security Intelligence Feed for Malware was blocking the client’s IP. That would have been really great to know on day 1, so I could have asked the client’s IT to address it. Of course, when I did give that root cause back to their IT, they responded that they knew about being blacklisted two days before reporting access issues to our network. Did they mention that at all? Nope. Where’s the love, people?

Networking Security Technology

When I wrote the “Doing It Again” posts about XtremIO and Pure Storage, I didn’t actually think I would get that chance. EMC’s concessions around our initial XtremIO purchase seemed like our next site replacement would be a foregone conclusion. However, when the chips were counted, the hand went to another player: Pure Storage.

pure_boxesLast Friday, the Pure hardware arrived. Unpacking and racking was simple–no cage nuts needed, and the only necessary tool (screwdriver) is included in the “Open Me First” box. The same instructions that I respected during our 2013 POC led the way. I recall back then that QA on their readability was the CEO’s 12-year-old son. If he could follow them, they were customer-ready. Unconventional but effective.

This morning, the Pure SE (@purebp) and I finished the cabling and boot-up config. Three IP addresses, two copper switch ports, and four FC interfaces. The longest part was my perfectionistic cable runs. What can I say? The only spaghetti I like is the edible Italian kind. Fiber and copper should be neat and clean.

Storage Technology Virtualization

firesightsplashI started to title this a “Review” of the Cisco ASA with FirePOWER, but my objective is to highlight a few limitations of the integrated solution so that potential customers understand the product. It may turn out to be a review after all, but that’s the focus.

Let’s set some product context. Cisco completed its acquisition of Sourcefire on October 7, 2013, and its initial integration into the Cisco Security family on November 10, 2014. That makes this union very fresh–think of Cisco FirePOWER as newlyweds. They’re starting to share the same roof, but carry a lot of individuality and his/her domain around with them.

Next, let’s zoom in on the word, “Services”, or as you may see elsewhere, “Module”. Sourcefire makes a number of standalone, independent intrusion prevention system and application firewall appliances (i.e. 7000 series, 8000 series). When Cisco and Sourcefire united, they introduced the ability to put a dependent Sourcefire module into the Cisco ASA 5500-x next-generation firewall family. One Cisco partner described it as functioning like a virtual machine within the ASA (of sorts). Summation: it needs the host (ASA) to survive.

This “Module” should actually be packaged and marketed as a “Starter Kit” or an entry-level, feature-limited offering (with no building-block upgrade path; it’s a hardware ceiling). And perhaps it is by some Cisco VARs, but it’s new, so I think many are still coming up to speed with what it brings to the table.

To justify my above assertion, I’ll highlight four characteristics that have affected or disappointed me in my deployment, and that have motivated a new set of quotes to move to the hardware/standalone solution.

Networking Security Technology

Addressing. Routing. DHCP. EIGRP. HSRP. Mobility. After consuming Cisco’s 706-page IOS IPv6 Configuration Guide, these are just a few of the areas we’re processing as the deployment plan starts coming…

Networking Technology

Are you familiar with VCE? If not, add it to your IT acronym dictionary, but it’ll be something you hear more about in the future if virtualization, shared storage, converged networks, and/or server infrastructure are in your purview. VCE stands for “Virtual Computing Environment” and is a consortium of Cisco, EMC, VMware, and Intel (funny…if you take three of those initials, you get V-C-E). The goal and objective, which they seem to be realizing, is to deliver a “datacenter in a box” (or multiple boxes, if your environment is large), and in a lot of ways, I think they have something going…

The highlights for quick consumption:

  • a VCE Vblock is an encapsulated, manufactured product (SAN, servers, network fully assembled at the VCE factory)
  • a Vblock solution is designed to be sized to your environment based on profiling of 200,000+ virtual environments
  • one of the top VCE marketed advantages is a single support contact and services center for all components (no more finger pointing)
  • because a Vblock follows “recipes” for performance needs and profiles, upgrades also come/require fixed increments
  • Cisco UCS blade increments are in “packs” of four (4) blades; EMC disks come in five (5) RAID group “packs”
  • Vblock-0 is good for 300-800 VMs; Vblock-1 is for 800-3000 VMs; Vblock-2 supports 3000-6000 VMs
  • when crossing the VM threshold for a Vblock size, Vblocks can be aggregated

Those are the general facts. So what does all that mean for interested organizations? Is it a good fit for you? Here are some takeaways I drew from the points above as well as the rest of the briefing by our VCE, EMC, and Cisco reps…

Storage Technology Virtualization

We recently performed some upgrade our Cisco MDS 9509 and thought we’d share the steps with you. You’re welcome to hop on Cisco.com as well and grab the user guide, but if you’re running a 9500 with redundant Sup-2’s, this should be all you need to hop between SAN-OS 3.x versions and all the way up to NX-OS 5.x…

Networking Technology

If you’re running a VMware vSphere cluster on a two-tier (or greater) Cisco network, you might be in a situation like I was. You see, we built in redundancy when we planned our core and access switches, but the design had one significant flaw (see the simplified diagram to the right). Pretend all of those lines are redundant paths. Looks good so far, right? If CoreA goes down, ESX(i) can still send traffic up through AccessB to CoreB. The reverse applies if -B is down, and likewise for either of the Access- switches.

The catch comes for VMs on ESX(i) when one of the Core- switches goes down. ESX(i) balances VMs across the ports in the Virtual Machine port group(s). If a port goes down, it will smartly move the VM(s) to another port that is up. If an “upstream” hop like CoreB goes down, though, ESX(i) doesn’t know about that event, so it keeps its VMs in place, oblivious to the fact that the VMs on AccessB ports are as good as dead to the world. [Enter Link-State Tracking]

Networking Technology Virtualization