• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
site logo
  • About
    • Approach
    • Partnerships
    • Mission
    • Leadership
    • Awards
    • Arraya Cares
  • Solutions
    • Solutions

    • Hybrid Infrastructure
      • Hyperconverged
      • Infrastructure as a Service
      • Servers, Storage, and Virtualization
      • Data Protection
      • Disaster Recovery & Business Continuity
    • Apps & Data
      • AI
      • Automation
      • Customizations
      • Visualizations & Integrations
      • Migrations
    • Network
      • Enterprise Networks
      • Wireless Connectivity
      • Cloud Networking Solutions
      • IoT
    • Cybersecurity
      • Endpoint
      • Network
      • Cloud
      • Application
    • Modern Workplace
      • Microsoft Licensing
      • Productivity & Collaboration
      • Modern Endpoint Deployment & Management
      • Microsoft Compliance & Risk
      • Backup
      • Cloud
  • Services
    • Services

    • Managed Services
      • Service Desk
      • Outsourced IT
      • Managed Security
      • Managed NOC
      • Arraya Adaptive Management for Microsoft Technologies
      • ADEPT: Arraya's White Label Program
    • Advisory Services
      • Assessments
      • Strategy
      • vCTO
      • vCISO
      • Enterprise Architecture
    • Staffing
      • Infrastructure Engineering
      • Security & Compliance
      • Application & Software
    • Professional Services
      • Project Management 
      • Systems Integration 
      • Mergers & Acquisitions
      • Knowledge & Skills Transfer 
  • Industries
    • Education
    • Finance
    • Healthcare
    • Legal
    • Manufacturing
    • Software and Services
  • Insights
    • News
    • Blog
    • Events
    • Videos
    • Case studies
  • Careers
  • CSP Login
search icon
Contact Us

Arraya Insights

December 28, 2018 by Arraya Insights

This is the fourth post in an ongoing, deep dive series into the subject of segmentation. Each post will be written by a member of Arraya’s technical or tactical teams, Cisco ISE use cases focusing on a specific piece of this extremely broad, highly transformational, topic. 

In this week’s post on segmentation, we will cover Cisco’s Identity Services Engine (ISE) and how we’ve used it in different scenarios to provide optimal network access control for our customers. The majority of use cases here will be with wireless access but this also applies to wired or VPN access. We will discuss leveraging the AAA override features available and why some may be better than others for different business needs.

As wireless continues to grow to be the main access method for network users, the shortcomings of the available frequency spectrum we have to work with have been realized. Wireless engineers must be as efficient as possible with that spectrum in order to get the best performance out of the network. One way to really limit the performance of a WLAN is to flood the air with unnecessary management traffic. Having too many SSIDs in a busy network will absolutely do this. The best-practice recommendation from most vendors is that no more than three or four SSIDs should be served by a given Access Point in a typical deployment. If you consider High Density environments such as sports stadiums, the recommendation is one or two at the most.

So, here is the problem. We know we can’t have everyone on the same network. We need to have segmentation for the different user roles. In the past, the only thing we could do was create a unique SSID for each security segment, causing SSID sprawl and crippling our network. What’s the solution? AAA-override.

Let’s consider a common network device and user base of employees and contractors with restricted access, employees that require full network access, IOT/ medical/ warehouse/ POS/ devices that require segmentation, guests, etc. The employees could be using personal devices or corporate-issued devices. Some of the network devices might not support 802.1x and would require a pre-shared key for authentication and encryption.

With Cisco ISE, we can handle all of that with only three SSIDs!

1) Open SSID with no encryption or credentials required for access – for the guests and visitors. Note – when WPA3 becomes the norm we can add encryption to an open network.

2) PSK SSID for the devices that don’t support dot1x. This could include Identity-based PSK which allows you to have separate keys configured on different groups of devices.

3) 802.1x SSID for everyone else which will likely be the majority of your client base.

Diving deeper into Cisco ISE use cases

How does it work? The wireless AP or controller is configured to authenticate users against a RADIUS server, such as the one included with Cisco ISE. ISE evaluates the specifics for each authentication, and based on the policy you define, it tells the wireless network how to segment that user. Simple!

Here are a few of the use cases that leverage this feature. ISE considers the specifics of the client authentication, such as:

  • Authentication credentials. This could refer to a user/password combo OR digital certificates. It looks up attributes of the user in a directory database such as Microsoft Active Directory or the internal database.
  • Device type. ISE profiles the device based on information it learns from the authentication itself or various probes you configure to feed it more info.
  • Location, such as the AP, switch, floor or building where the client is located or whether it is a remote VPN session.
  • Posture, which is the state of the client device as defined in a posture policy and reported by the client. This may include antivirus, OS patches, stored files, and more. This requires the AnyConnect client.
  • MDM registration and compliance status.
  • Time of day, SSID, and more less-common attributes.

After evaluating these attributes ISE can issue the AAA override or other NAC element:

  1. VLAN override. The client is placed on the specified VLAN, regardless of which VLAN is the SSID’s or port’s default. This works well in office environments with smartphones, tablets and laptops because these devices pick up on the fact that they need to get a new IP address right away.
  2. ACL override. The VLAN stays the same, but the specified ACL gets added to the client session. This may prove to be more seamless as DHCP address assignment does not need to re-occur.
  3. QOS override. Change the Quality of Service profile for user sessions to prioritize traffic.
  4. AVC override. Change the AVC profile for the session to allow or deny different applications to be used by the client.
  5. URL-redirect. Used to direct a user to a portal, for BYOD or guest onboarding for example.
  6. Trustsec SGT. A Security Group Tag gets applied to the session. We’ve used this in residential wireless deployments where a family of devices connect to the same SSID but require isolation from other groups of devices.
  7. Deny all access. Although not AAA override, it bears mentioning here.

By now you’re probably thinking about how you could leverage Cisco ISE in your environment to achieve the desired segmentation as efficiently and easily as possible. If so, please reach out to us! We’d be glad to help you realize the potential of Cisco ISE.

To learn more about segmentation and its role in today’s IT landscape, reach out to our team of experts by visiting: https://www.arrayasolutions.com//contact-us/.  

December 27, 2018 by Arraya Insights

Arraya Insights Radio

Episode 12:  Cloud & Security: Are They Opposites or a Perfect Match?

On this episode of Arraya Insights Radio, our team looks to answer one of the most pressing questions facing organizations today: Is the cloud safe? In order to help us break down this complex issue, we welcome two special guests – Chuck Keissling (Manager, Cloud and Workspace Practice) and Joe Davolos (Security Solutions Architect).

Host: Thomas York (Senior Director, IT Operations)

Guests: Chuck Keissling (Manager, Cloud and Workspace Practice) and Joe Davolos (Security Solutions Architect)

Further Reading:

  • How You Can Steer Your Cloud Migration onto the ‘FastTrack,’ by Arraya Insights
  • Cloud Spend Set to Rise, But Who’s Guiding the Way?, by Arraya Insights
  • Overview: VMware Cloud on AWS – Is It Worth The Hype?, by Arraya Insights
  • Cisco Threat Grid: Keeping Malware Defense On-Prem, by Arraya Insights
  • Microsoft Ignite 2018 Recap: 4 Must-Hear Announcements, by Arraya Insights

Theme Music: “I Don’t Remember (Yesterday)” by Hygh Risque

December 21, 2018 by Arraya Insights

Is VMware Cloud on AWS really worth the hype? We posed this question to members of our Data Center team in a recent post. In response, they rattled off four of thevmware cloud on aws disaster recovery solution’s most valuable use cases. However, they cautioned us that our initial question was too broad and its answers too complex to cover in a single post. So, over the course of four posts, we plan to look at each of the different VMware Cloud on AWS capabilities our team highlighted and find out more about who could benefit and how.

Kicking off this series is a topic that, to be honest, most prefer to think about only when necessary. Despite that fact, disaster recovery should absolutely be kept front-of-mind by all technology teams. It’s also an area where VMware Cloud on AWS can have an impact with the help of VMware Site Recovery, a bolt-on disaster recovery as-a-service (DRaaS) solution. Let’s take a look at five reasons why technologists hate talking disaster recovery – and how the pairing of VMware Site Recovery and VMware Cloud on AWS makes those conversations more appealing.

5 DR pain points alleviated by VMware Cloud on AWS

Reason #1: It’s expensive.

It’s true, disaster recovery can be costly. After all, think of the one-time, CapEx investments needed to do it right. Neither the technologies needed to provision a secondary, backup data center nor the physical space needed to house it come cheap. These expenses are not a concern with cloud-based solutions such as VMware Site Recovery. In the case of VMware Site Recovery, the technologies that enable recovery belong to VMware. The responsibility for housing those technologies falls on VMware. Organizations simply reap the benefits and the peace of mind that comes from knowing their data will be safe even in a worst case scenario.

Reason #2: It’s REALLY expensive.

Disaster recovery’s price tag doesn’t simply include CapEx costs. Instead, there are also OpEx investments to consider. Recurring costs associated with supporting a backup data center run the gamut from staffing to cooling and everything in between. Cloud solutions such as VMware Site Recovery aren’t immune to OpEx, however, the associated costs are more streamlined. It requires minimal additional on-staff expertise to support these solutions, while any expenses associated with power or maintaining the technologies themselves, again, fall to the owner: VMware.

Reason #3: There’s no way to get it just right.

With traditional approaches to disaster recovery, businesses can easily end up with far more – or far less – than they need. Anticipating future growth necessitates investing in a greater amount of resources upfront and hoping that growth materializes. Or, they can invest in only what is needed and run the risk of not being able to keep up later on. With VMware Site Recovery, organizations pay only for the disaster recovery resources they use. Pricing is structured on an on-demand, per VM format and bills are sent monthly. This allows organizations to set their disaster recovery at the right level for them and adjust on the fly.

Reason #4: Recovery is extremely complex.

Returning a technology environment back to a state of normalcy after a catastrophe is a tricky process. It requires multiple, most often manual, steps, all of which are open to human error. This risk is exacerbated by the fact that disaster recovery strategies are rarely tested all the way through. Solutions such as VMware Site Recovery simplify the recovery process. It uses intelligent automation to streamline failover and failback capabilities down to a single click each. Additionally, VMware Site Recovery leverages HTML5 and an interface based on that of VMware Site Recovery Manager (the company’s onsite disaster recovery solution) to deliver a familiar, user-friendly, experience.              

Reason #5: Testing is too disruptive (but without it there’s no visibility).   

For traditional disaster recovery solutions, the best case scenario is they are tested once a year. Without more regular testing, those solutions can only inspire so much confidence as there is minimal to no visibility into the health and well being of the process otherwise. The reason for this lack of testing is straightforward enough: it can be expensive and disruptive. VMware Site Recovery promises non-disruptive testing so organizations can test whenever they want without interrupting their mission critical systems. With increased routine testing, should a real emergency occur, businesses will know VMware Site Recovery will function as expected.

Next Steps: Reliable disaster recovery with VMware Cloud on AWS

Before we wrap this up, there are a few additional points about VMware Site Recovery worth mentioning. To start, the solution is backwards compatible. This means it can work seamlessly with all vSphere 6.0 versions dating back to Update 3. Also, above we mentioned how VMware Site Recovery is a bolt-on service for VMware Cloud on AWS. Another such service is vSAN Stretched Clusters. Admins can use this to stretch backups across three AWS availability zones. In the unlikely event an entire availability zone goes out, organizations will still be able to access their data and function normally by way of a secondary location.

Want to learn more about VMware Site Recovery and vSAN Stretched Clusters? What about VMware Cloud on AWS? Don’t wait for our next blog. Instead, start a conversation with our Data Center team today. You can do so by visiting: https://www.arrayasolutions.com//contact-us/.

As always, feel free to leave us a comment on this or any of our blogs through social media. Arraya can be found on LinkedIn, Twitter, and Facebook. Let us know what you think, then follow us to stay up to date on our industry insights and unique IT learning opportunities.

December 20, 2018 by Arraya Insights

Technology grabbed its share of headlines during 2018. Some of those were positive. We saw the rise of a number of tools and solutions designed to make lives easier and workdays more productive. Of course, some of those headlines were decidedly negative. For too much of the year, ransomware, data breaches and privacy violations dominated conversations. We sat down with members of Arraya’s leadership team to get their thoughts on the technology topics and trends that most defined 2018 for them. Check out the video below for their thoughts.

 

December 18, 2018 by Arraya Insights

This is the third post in a weekly, ongoing, deep dive into the subject of segmentation. Additionally, it is part two of a post exploring the ins and outs of ACI and NSX. Each post in the overarching segmentation series will be written by a member of Arraya’s technical or tactical teams, focusing on a specific piece of this extremely broad, highly transformational, topic. 

Why ACI and/or NSX?

A common question is why run ACI? If multi-tenancy is not a requirement in the physical or virtual network, the value proposition for ACI can be limited. NSX provides an extremely similar IP mobility and conjoined security feature set but at a lower layer of the data center. NSX VXLAN overlay operates within the virtual environment only. It provides VXLAN to VLAN mapping access to legacy physical systems in the network. NSX extracts the network packet filtering, forwarding decisions, and layers 4 through 7 services into three virtual appliances or subsystems for the data, control, and management planes.

The primary physical difference between ACI and NSX is that NSX maintains the VTEPS as VMKernel ports that belong to the ESXi hosts that have virtual wires or virtual switches. These are VXLAN networks. As before, the VXLAN VTEPS still provide layer 2 over layer 3 transport, but now the NSX is managing BGP and BUM traffic handling. NSX does however offer a few different options for BUM traffic handling: Multicast / Unicast / Hybrid. Straight multicast floods network switches looking for every host with a VTEP and looking for a response. This is fine for extremely small environments with predominately-dedicated TOR switches for the virtual environment. Unicast sends a unique broadcast copy to each VTEP within the same broadcast domain and a single broadcast message to a single host in other broadcast domains which then replicate the broadcast to the additional hosts in that broadcast domain. This eliminates sending excessive broadcast through the physical network and routed interfaces.

Hybrid mode offers the most intelligent BUM handling if there are a larger number of VXLANs configured with highly segregated applications or virtual machines. Hybrid assumes that IGMP snooping is enabled on all the upstream physical switches from the virtual infrastructure and IGMP querying is enabled on the router between the broadcast domains that provide transport on the physical network between the hosts running the virtual infrastructure. The VTEPS is a hybrid, creating multicast groups for the VNIs for which they participate. A broadcast packet in the same broadcast domain is then published to the participating members that host the destination VNI for the broadcast message. For other broadcast domains, a unicast pack with the replication flag is again sent to a single host. The host then forwards the broadcast to the multicast group participating with common destination VNIs.

Once again, the power of VXLAN overlay with NSX is that workload mobility can be anywhere in the data center. It can also be in remote location as long as hosts are attached to a physical network that can route to all other hosts on the physical network with a minimal network engineering investment.

Figure 3: https://www.cisco.com/c/dam/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-740124.docx/_jcr_content/renditions/white-paper-c11-740124_25.jpg

Both solutions offer VXLAN layer 2 over layer 3 network tunneling with programmable security policies and a suite of L4 through L7 services found in almost every network. Both solutions stand on their own as powerful tools in the right use cases. NSX on its own has the advantage of creating multi-site layer 2 adjacency with limited disruption to the existing physical network. With security policies being enforced at the VM network interface and network segmentation remaining in the VMware environment, there is reduced trombone effects or hair-pinning in the virtual landscape. This does come at a cost however, especially when utilizing the Edge Services Gateways (ESG) to forward outside of a large virtual environment with multiple vCenters. The ESGs are virtual machines of which there can be up to eight.  Just like any edge router, this requires significant processing power for route decisions, iBGP convergence, entropy calculations, etc.  This workload can heavily affect the virtual host (ESXi) environment. In addition, ESGs placed in a shared ESXi cluster with multi-tenant application workloads could cause tenant resource constraints and overlap that cannot be managed without far reaching implications for the virtual environment as a whole.  For these reasons, VMware recommends creating a completely separate Edge Services Cluster in the ACI fabric to host the ESGs with direct connection to border leaf switches in the ACI or other network fabric. This dramatically increases the cost of an NSX implementation as it introduces physical network uplinks, compute and storage hardware requirements for the NSX L3 forwarding and layer 2 bridging.

ACI and NSX: Together at last

There are two major schools of thought for best practices regarding implementing ACI and NSX together. The table below showcases these architectures as defined by Cisco [2]. VMware is a large proponent of option 2, which leverages ACI as an underlay only. NSX performs and manages the VXLAN traffic within its environment and the outcome is VXLAN encapsulated VXLAN network.

Option 1. Running NSX-V security and virtual services with a Cisco ACI integrated overlay: In this model, Cisco ACI provides overlay capability and distributed networking, while NSX is used for distributed firewalling and other services, such as load balancing, provided by NSX Edge Services Gateway (ESG).
Option 2. Running NSX overlay as an application: In this deployment model, the NSX overlay is used to provide connectivity between vSphere virtual machines, and the Cisco APIC manages the underlying networking, as it does for vMotion, IP Storage, or Fault Tolerance.

Figure 4 : https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-740124.html#_Toc520418119

Option 1 is Cisco’s preferred design strategy and for some good reasoning. Cisco has created multiple hypervisor and virtual management plugins.  The APIC can be linked to VCenter and use VMware REST APIs to configure the VMware distributed switch. This integration provides unique and powerful consolidation of management for a VXLAN network providing any IP anywhere capabilities. The physical ACI hardware is completely responsible for all VXLAN traffic and the complexities there with significantly more robust BUM handling mechanisms. ACI can manage the entire data center network and VMware from a common control point providing consolidated application flow control services and detailed network monitoring for every device on the network. The VMware management extensibility of ACI also allows the virtual administrators to configure networking for the virtual environment without having to involve or rely on network administrators. The other major advantage is the complete removal of the requirement for a dedicated Edge Services Cluster. The NSX controllers and manager can live freely within the existing ESXi host environment. They can offload the greater majority of their workloads directly to the VM network interfaces, host uplinks, or perform simple load balancing and app firewall services.

There are drawbacks to implementing NSX for services only and relying on ACI for underlay and overlay capabilities. Doing so removes the ability of NSX to natively leverage VXLAN and move workloads to alternate sites using layer 2 tunneling. ACI would then be solely responsible for managing the VTEPS within the data center and a multi-site configuration requires multi-site ACI or manual native VXLAN configuration. This is an expensive commitment both in terms of management and cost.

Unless multi-tenancy and higher than usual level security requirements are required, a joint ACI and NSX implementation is not a likely best-fit solution. If business objectives mandate or warrant multi-tenancy, stringent segmentation, and high security compliance the higher cost implication for multi-site ACI and more robust third party hardware appliances for layer 4 – layer 7 services without the need for NSX would be the most appropriate solution.

For medium sized organizations with mostly virtualized environments, NSX on its own offers the highest return on investment. This is provided that multiple sites exist and the business requires high uptime requirements. The organization can benefit from VXLAN’s layer 2 mobility features to streamline disaster recovery, simplify failover procedures and leverage the full set of NSX security features. While the BUM traffic handling is not as robust as within ACI, with the ubiquity of 10 GB and above Ethernet, VXLAN’s usage of UDP frame check sequence (FCS) for error checking, and the NSX adoption of intelligent hybrid multicast/unicast replication the concerns of entropy effects on a growing network are negligible.

In the case of a large organization with significantly mixed physical and virtual workloads, NSX still provides all the previously defined value. However, creating a robust management or Edge Service Cluster as recommended by VMware is advisable. Significant forwarding or bridging between VLAN and VXLAN networks requires robust processing power. Also, it could, if several ESGs are deployed, negatively influence ESXi host performance if shared with business application workloads.

Summarizing when to use what

The following table summarizes the best-fit use cases and sample decision criteria used to determine if ACI, NSX, or both bring the most value:

Use Case ACI NSX
Large multi-tenant networks or data center hosting facilities with multi-site failover and high uptime requirements

-Funds for and experience with hardware load balancers

-Managing multiple VRFs

-Have higher change rate volumes of physical and virtual workloads

-Single tenants serviced within a data center can fit within the 500 EPG maximum

(x)

ACI Multi-Site

Large multi-tenant networks or data center hosting facilities with multi-site failover and high uptime requirements

-VMware based IaaS automation Services

-Enablement for virtual administrators to manage virtual networking with seamless no hands physical network integration

-Funds for and experience with hardware load balancers

-Seeking additional programmability within the virtual environment for security policies and load balancing services

-Managing multiple VRFs

-Have higher change rate volumes of physical and virtual workloads

-Single tenants serviced within a data center can fit within the 500 EPG maximum

(x)

ACI Multi-Site

(x)

NSX as a services only overlay

Large enterprise networks with multi-site failover and high uptime requirements

-No experience with or funds for hardware load balancers

-Seeking to adopt a network segmentation and advanced security posture

-Highly virtualized environment with high change rate

-Plans for reducing physical workloads or steady trends

-Robust data center networks

-Ability to adopt IGMP querying on routers

-Ability to adopt IGMP snooping on TOR switches

(x)
Small and Medium sized corporations with multi-site or cloud failover capabilities and high uptime requirements

-No experience with or funds for hardware load balancers

-Highly virtualized environment with high change rate

-Seeking to adopt network segmentation and an advanced security posture

-Searching for Layer 2 stretching methodology without adapting the physical network

-Plans for reducing physical workloads or steady trends

-Ability to adopt IGMP querying on routers

-Ability to adopt IGMP snooping on TOR or leaf switches

(x)
Medium sized corporations with multi-tenant security, segmentation, and multi-site failover requirements with high uptime requirements

-Existing multi-tenant infrastructure

-Greenfield data center project in roadmap

-Limited interest in updating the existing infrastructure

-Existing NSX customer

-Plans to increase physical workloads and want datacenter design flexibility for growth

(x)

ACI single site underlay

(x)

NSX Overlay

To learn more about segmentation and its role in today’s IT landscape, reach out to our team of experts today. Visit: https://www.arrayasolutions.com//contact-us/.  

December 12, 2018 by Arraya Insights

This is the second post in a weekly, ongoing, deep dive into the subject of segmentation. It is also part one of a two-part look at ACI and NSX. Each post in the overarching series on segmentation will be written by a member of Arraya’s technical or tactical teams, focusing on a specific piece of this extremely broad, highly transformational, topic. 

Network virtualization is massively disrupting modern data center methodologies. The two major market penetrators are Cisco’s Application Centric Infrastructure (ACI) and VMware’s NSX.  Both solutions offer programmable network policy management, inter-site layer 2 workload mobility, and support for physical and virtual workloads. Given the large number of similarities between the two products, it is important to understand some specifics of each technology and understand how their respective designs achieve their marketed value propositions. According to VMware, it is common to implement the technologies in tandem. Each vendor has specific recommendations and guidance for these architectures but their views are somewhat different. It is critical for architects, engineers, and technical business leaders to understand the implications, benefits, and risks when making decisions on implementing these network overlay and underlay designs to achieve a secure and scalable modern data center.

Diving deep in ACI

Cisco ACI is a controller-based physical network underlay and software overlay. Cisco defines their methodology as an integrated overlay approach meaning it includes hardware and software. ACI hardware includes the Cisco Nexus 9000 family and a proprietary Application Policy Infrastructure Controller (APIC) for unified management, policy distribution, and control plane.

Figure 1: https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-737909.html#_Toc524725544

The ACI fabric construct is a spine leaf architecture with a three server APIC cluster redundantly attached to the network fabric. Regardless of application or the compute medium (either physical or virtual), ACI pushes all network policies and distributed default gateways (Pervasive Gateway) down to the leaf switches enabling forwarding and filtering decisions at the switch. This is the enabling factor that allows for any workload or any IP address to live anywhere in an ACI data center leveraging simplified and optimized Virtual Extensible LAN (VXLAN). This conjoined IP and security mobility contribute a large portion of the ACI value proposition to modern data centers.

Additionally, as a VXLAN integrated management platform that supports active-active equal cost multi-pathing (ECMP), ACI removes spanning tree loop (STP) prevention. ECMP and the security policy strategy of ACI are major factors in return on investment and total cost of ownership. ECMP removes idle network links waiting for potential failures in the ACI fabric and costly, partially used, link aggregations for throughput. The security methodologies apply traffic security within the fabric at the leaf and spine switches across layer 2 and 3, limiting the amount of network hair-pinning in the data center.

Exploring how else ACI can impact modern organizations

Figure 2: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/aci-fundamentals/b_ACI-Fundamentals/b_ACI-Fundamentals_chapter_010001.html#concept_5FE260BAAC514DB58AD6E70B3A3959A4

As we continue to deconstruct ACI, let us review the network and application policy constructs. ACI has a hierarchical policy construct matrix with a multi-tenant design as its primary focus. At the core of its traffic control policies, ACI leverages Endpoint Groups (EPG). It does so to group similar workloads and apply application policies or communication policies. The individual communication policies between EPGs are called Contracts. Contracts dictate which communication ports are allowed between EPGs and even individual servers or virtual machines within different EPGs. This is how ACI achieves micro-segmentation. EPGs can be further grouped into an Application Network Profile (ANP). The ANP construct enables quick duplication of application communication policies. For example, an application that has multiple environments used for development and testing. Admins can quickly clone APNs and add servers to new or existing EPGs. These will inherit all of the same communication/security policies.  This is a powerful tool for securing and managing common network requirements for VMware environments.

vMotion, IP storage, VSAN replication, Fault Tolerance, and others can all be grouped into EGPs across hypervisor clusters for inter and intra-cluster communications but segmented from one another. This offers a more stringent security posture in a highly regulated or multi-tenant environment.

VXLAN overlay is at the heart of the modern data center’s adoption of network virtualization. It is the latest methodology to achieve IP mobility at any scale. This mobility opens up opportunities for workload resiliency regardless of physical distances. Not to say that latency has lost its grasp on network capabilities. Active-Active workloads with layer 2 adjacency still require no more than 150ms round trip time (RTT). Yet, the stretched layer 2 abilities even for crash consistent recovery is something previously difficult to manage to the point of being a barrier to entry.

Adding BUM traffic into the conversation

ACI does offer operational simplicity to VXLAN and security management efficiencies in a single console. However, there are still plenty of net new route types and protocol extractions inherent to ACI unfamiliar to most engineers. Familiarity with said technologies is important for troubleshooting and management at scale. For example, initial releases of native VXLAN use tunnel endpoint (VTEPS) on layer 2 networks to create layer 2 over layer 3 tunnels. Like any layer 2 technology, VTEPS rely on MAC learning and therefore broadcast flooding within a broadcast domain. This represented a huge step backward from 802.1q broadcast domain efficiencies. While there were multiple steps to the journey, let us jump to where we have landed today. Currently we have a combination of special handling for Broadcast, Unknown Unicast, and Multicast traffic (BUM traffic) multi-protocol Boarder Gateway Protocol (mBGP) and Ethernet VPN (EVPN).

Let’s consider BUM traffic handling. To achieve layer 2 mobility over a layer 3 network, managing MAC address learning is essential. Data plane challenges regarding increased broadcast traffic and un-scalable MAC tables remain. Multicast control plane mechanisms offer a distinct advantage for optimization and scalability. Each VXLAN, much like a VLAN, has its own unique ID. A virtual network identifier (VNI). At the spine switches a multicast group is created and participating VNIs associated to the multicast group. mBGP then stores ARP entries at the VTEPs about the hosts belonging to each VNI. This is a complex setup but highly scalable for large multi-site VXLAN implementation. Good news, the ACI APIC controllers handle IGMP and multicast group membership in the spine and leafs. This provides a single learning platform for the data center. Now this complexity returns when attempting to establish multi-site VXLAN deployments if ACI does not exist in both locations. Multiprotocol iBGP / eBGP peers and route reflectors along with Ethernet VPN (EVPN) peering, PIM multicast groups all need be configured manually on the physical network at the non-ACI location. If ACI exists in both locations (Cisco offers ACI Multi-Site), special inter-data center controllers programmatically define and learn about remote sites. This helps span VXLAN awareness and maintain the ease of VXLAN management.

David Mahoney’s post on ACI and NSX will continue next week. In part two of his post, he with a look at NSX and how it works together with ACI. To learn more about segmentation and its role in today’s IT landscape, reach out to our team of experts by visiting: https://www.arrayasolutions.com//contact-us/. 

December 11, 2018 by Arraya Insights

Back in March, Cisco announced its entry into the world of headsets and over the last few months, that news has finally begun tocicso headsets faq take a more tangible form. Cisco’s first headsets, the 530 Series, were followed by the 560 Series Single Dock in September, the 520 Series in October and, most recently, the 560 Series Multi Dock in November. Given the increasingly important role headsets play in the modern workplace, as offices become more open and users more mobile, we sat down with our collaboration team to make sense of Cisco’s newest product line.

First things first: Why Cisco headsets?

To begin with, we wanted to answer the question: Why go with a Cisco headset? After all, there was no shortage of vendors in the space even before Cisco arrived. There are two points of view to consider when answering this question. The first is that of the end user. These folks want audio quality, comfort, and flexibility. That last item refers to a headset’s ability to work across multiple devices and needs. Cisco headsets check all of those boxes.

The other point of view we need to consider is that of the IT admin. The folks supporting these new solutions in the field have their own wish lists. Right near the top of those lists is ease of management. Cisco headsets deliver this by way of compatibility with Cisco’s Unified Communications Manager. This allows admins to push upgrades, check device health and more all from the same tool many are already using to maintain and support their communication environment. Simplicity is another line that appears high on admin wish lists. Cisco headsets foster that by providing a single vendor environment. Compatibility between modern IP phones and headsets is easily achieved. Should something go wrong, there’s no need to bounce between vendors as they play the blame game. Instead, admins can go directly to a single source to sort out the issue.

On board with Cisco as a headset provider? As mentioned above, the company has churned out multiple headset offerings in a relatively short period of time. This can lead to some confusion as to which of these 500-somethings makes the most sense for a given use case. Good news: Our Communication & Collaboration team had some thoughts on this topic as well.

OK, but which Cisco headset is right for me?

Let’s start where Cisco did, with the 530 Series. Cisco built these headsets with the Contact Center in mind, imbuing them with:

  • Excellent ambient noise filtration to mask some of the distractions often associated with life in the Contact Center
  • A Quick Disconnect cable which allows agents to get up and get moving without removing their headset
  • Full compatibility with Cisco IP phones plus a USB adaptor version that enables further connectivity
  • An in-call indicator located squarely on the device to let others know when an agent is engaged

Cisco’s next headset release was the 560 Series Single dock back in September. This device is more multi-purpose than its predecessor, adaptable to both office and Contact Center settings. Here’s what else is worth knowing about the 560 Series:

  • It’s wireless so users can move around as needed while they work through their daily to-do lists
  • Security isn’t sacrificed as the 560 Series achieves the Digital Enhanced Cordless Telecommunications (DECT) highest security standard (128 Bit – Step C)
  • On-ear controls allow users to take greater control over their call experience while an on-device indicator shows when users are on a call
  • It comes with a single source DECT base able to support USB devices

The next Cisco headset series to hit the market was the 520 Series. Office life definitely plays to this wired device’s strengths. Additionally:

  • The 520 Series adds to the range of compatible devices by including both a standard 3.5mm connector as well as a USB adaptor
  • Like its predecessors, this headset includes and on-ear busy indicator
  • It includes noise reduction capabilities ready to withstand even the most open of open office layouts

Finally, the most recent release in Cisco’s headset line was the 560 Series Multi Dock. This wireless iteration expands on the capabilities of the earlier entry into the 560 Series. It features a multibase station able to support up to four audio sources, e.g., two Bluetooth devices + two USBs or one USB and one RJ11. Additionally, it allows users to answer from any source with a single button and easy source changeovers.

Next steps: Determine which Cisco headset is right for you

Ready to learn more about these or any of the other solutions included in Cisco’s collaboration tool kit? Arraya’s team is here to help. Our experts have decades of experience working hands-on with leading collaboration technology and they can help you identify the devices and solutions that best fit your organization’s needs. Get the conversation started today by visiting: https://www.arrayasolutions.com//contact-us/.

We want to hear from you! Leave us your comments on this or any of our blog posts via social media. Arraya is on LinkedIn, Twitter, and Facebook. After you’ve shared your two cents, follow us to stay up to date on our industry insights and exclusive learning opportunities.

December 10, 2018 by Arraya Insights

Over the next few weeks and months, a number of key Dell EMC solutions will reach their end of service life (EOSL) dates or seedell emc end of life end of support extended EOSL support run out. For those waist-deep in the 2019 budgeting process, now is the time to prepare for life after these solutions. Otherwise, organizations will have to enter the new year facing the very real dangers of pressing ahead with unsupported Dell EMC technology in their data centers.

First, let’s go over some of those solutions approaching the end of extended support. Once this date hits, Dell EMC will no longer provide patches or any other type of support. For those currently leveraging these solutions, the recommended course of action is to upgrade to more modern – and still supported technologies:

  • Avamar Data Store 1.0
    • EOSL (Extended Support): 11/30/18
  • Avamar Data Store Gen2
    • EOSL (Extended Support): 12/31/18
  • Connectrix – Brocade
    • Version: DS-220B, DS-4900B, DS-5000B
    • EOSL (Extended Support): 1/31/19
  • Data Domain
    • Version: DD580
    • EOSL (Extended Support): 12/31/18
  • RecoverPoint
    • Version: Gen3
    • EOSL (Extended Support): 2/28/19
  • CLARiiON CX3
    • Versions: CX3-10C, CX3-10DC, CX3-20, CX3-20C, CX3-20F, CX3-20FDC, CX3-40, CX3-40C, CX3-40F, CX3-40FDC, CX3-CX3-80
      • EOSL (Extended Support): 3/31/19

Still sporting an extended support option: Dell EMC Isilon, Data Domain

The following solutions are nearing their original EOSL dates. For these technologies, upgrading is still the best option as doing so means a host of new, more modern features. It also puts the most time between organizations and having to worry about budgeting for upgrades, refreshes, etc. However, if a full-fledged upgrade isn’t in the cards, organizations would be wise to invest in Dell EMC’s extended support option. This service adds a few additional years of support and maintenance to legacy technology. Here’s a look at the technologies going EOSL that have an extended support option:

  • Connectrix – Cisco
    • Versions: MDS-9124, MDS-9124-0D, MDS-9124-4GSW, MDS-9124-8, MDS-9124-8D, MDS-9124-PWR
    • EOSL (Original): 1/31/19
    • EOSL (Extended Support): 1/31/23
  • Isilon
    • Versions: S200-100GB SSD, X200-500GB SATA, X400-100GB SSD
    • EOSL (Original): 12/31/18
    • EOSL (Extended Support): 12/31/23
  • Data Domain
    • Version: DD620
    • EOSL (Original): 12/31/19
    • EOSL (Extended Support): 12/31/24
  • Data Domain
    • Versions: DD640, DD670, DD860, DD890
    • EOSL (Original): 3/31/19
    • EOSL (Extended Support): 3/31/24
  • VNX1
    • Versions: VNX5500 (Block, File, & Unified), VNX5700 (Block, File, & Unified), VNX7500 (Block, File, & Unified), VNX7500, VNX5700, VNX5500 Upgrades
    • EOSL (Original): 12/31/19
    • EOSL (Extended Support): 12/31/24
  • VNX1
    • Versions: VNX5100 (Block only), VNX5150 (Block only), VNX5300 (Block), VNX5300 (File & Unified), VNX5300, VNX5100 Upgrades
    • EOSL (Original): 12/31/20
    • EOSL (Extended Support): 12/31/25

Next steps: Supporting your organization’s ideal modern data center

Can any of the above Dell EMC technologies currently be found in your organization’s data center? Are you interested in learning more about the modernization options you have available to you? Arraya’s Data Center team is here to help. Our team of experts can work with you to assess the present state of your technology environment and help you plan and execute an update that addresses your unique needs. Get the conversation started with our team today by visiting: https://www.arrayasolutions.com//contact-us/.

As always, you can comment on this or any of our blogs through social media. Arraya can be found on LinkedIn, Twitter, and Facebook. After you’ve shared your thoughts, follow us to stay updated on our industry insights and unique learning opportunities.

 

December 7, 2018 by Arraya Insights

Cisco shops take note: the tech leader recently announced a trio of high impact and above vulnerabilities affecting some of its cisco vulnerabilitiesmore popular solutions. As is the case with any vulnerability, organizations leveraging these technologies should take immediate action in order to mitigate possible exposures. Otherwise, they risk leaving themselves at the mercy of opportunistic cyber criminals. Let’s take a look at each of these vulnerabilities, and what can be done about them, with insight from Arraya’s Network and Security team.

Critical Vulnerability: Privileged access on Cisco Switches

A default setting on a variety of switch offerings from Cisco’s Small Business, Smart, and Managed lines could allow an unauthorized user to gain admin rights on the device. These switches come configured with an admin-level (level 15) default account. This profile comes into play during the initial login and it can’t be deleted from the device. However, it will go dormant as long as additional level 15 admin accounts are configured on the switch.

Security researchers noticed that in the event all level 15 admin accounts are removed from a switch, this default profile reactivates. On top of that, it does so quietly, leaving admins in the dark about this potential liability. As a result, should an attacker gain access to this account, he or she would have full run of the switch.

To remediate this, admins must ensure there is at least one level 15 account spun up on any potentially affected device. If such an account doesn’t exist, they must take steps to spin one up ASAP. Furthermore, strong passwords are must for any account but especially for accounts with this level of authority.

Affected devices include:

  • Cisco Small Business 200 Series Smart Switches
  • Cisco Small Business 300 Series Managed Switches
  • Cisco Small Business 500 Series Stackable Managed Switches
  • Cisco 250 Series Smart Switches
  • Cisco 350 Series Managed Switches
  • Cisco 350X Series Stackable Managed Switches
  • Cisco 550X Series Stackable Managed Switches

High Impact Vulnerability #1: ASA/FTD-based DoS attacks

An error in the Session Initiation Protocol (SIP) inspection engine employed by Cisco’s ASA and Firepower Threat Defense could leave both tools vulnerable to a denial of service (DoS) attack. The SIP inspection engine is automatically enabled on each solution, but it can struggle to process SIP traffic efficiently. By virtue of this, a savvy-attacker could simply overwhelm these solutions with traffic, knocking them offline.

Cisco has released not one but four separate mitigation strategies for dealing with this vulnerability. For example, they could disable SIP inspection. Admins could also block suspicious hosts, filter possibly malicious addresses, or impose a rate limit on SIP traffic.

Affected devices include:

  • 3000 Series Industrial Security Appliance (ISA)
  • ASA 5500-X Series Next-Generation Firewalls
  • ASA Services Module for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers
  • Adaptive Security Virtual Appliance (ASAv)
  • Firepower 2100 Series Security Appliance
  • Firepower 4100 Series Security Appliance
  • Firepower 9300 ASA Security Module
  • FTD Virtual (FTDv)

High Impact Vulnerability #2: Meraki privilege escalation

A weak point in Meraki’s local status page could inadvertently let attackers gain high-level access privileges to affected devices. Consequently, by using this newfound administrative might, attackers could gain a tactical foothold into an organization’s network or access and modify the device’s configuration data. Further worsening the matter is the fact that, on all affected devices, this local status page is automatically provisioned.

As of press time, there is no workaround that will allow organizations to stay safe while continuing to use Meraki’s local status page. Instead, admins are encouraged to disable this page should their organizational needs and obligations allow it. One note of caution: doing so can result in a loss of additional functionality.

Here’s a list of the Meraki devices impacted:

  • MR devices
  • MS devices
  • MX devices (includes physical devices and the vMX100 virtual appliance)
  • Z1 and Z3 devices

Next steps: Protecting your Cisco environment against vulnerabilities

Does your organization leverage any of the above solutions? Arraya’s Network and Security team can work with you to mitigate each of the above risks and identify any additional trouble spots. Arraya’s team has the knowledge and experience needed to help organizations of all shapes and sizes plan, protect, and prevail against today’s evolving threat landscape. Reach out to our team now by visiting: https://www.arrayasolutions.com//contact-us/.

As always, let us know what you think of this post! Leave us any comments or questions on our social media pages. We can be found on LinkedIn, Twitter, and Facebook. Then, follow us so you can keep up with our take on industry news and access our exclusive learning opportunities.

 

December 6, 2018 by Arraya Insights

Last week, buried predictably on a Friday, Marriott revealed it – and, by extension, its guests, had been the victim ofmarriott starwood data breach a truly massive data breach. All told, the hospitality giant believes attackers gained access to data on some 500 million guests who stayed at its Starwood properties over the past four years. For roughly 327 million of those guests, the data may include name, address, birthday, and even passport number. If that wasn’t enough bad news, Marriot representatives couldn’t fully guarantee that payment card data survived the intrusion untouched.

Multibillion dollar lawsuits have already begun piling up in response to the breach. Additionally, the company has promised to cover the costs incurred by those in need of a replacement passport. There’s also a $900 million fine potentially on the horizon thanks to Europe’s GDPR law.

As Marriott, regulators, and customers all seek to nail down what comes next, let’s take a look at what went wrong before (and after) the data breach and how that led us to this point.

6 takeaways from Marriott’s data breach

Lesson #1: Hunt for red flags. It used to be enough to watch for red flags, but not anymore. Assuming data is safe until it is demonstrated otherwise enables these year-plus breaches to continue happening. Instead, organizations must take a proactive approach when it comes to monitoring their network for malicious activity. They should invest in a security information and event management (SIEM) solution and tie as much of their IT environment as they can to it. From there, Tom Clerici, Arraya’s Cyber Security Director, suggests taking the time to “set the logging correctly on devices and create alerts for suspicious activity. Follow all this up with weekly meetings to review activity for anomalies.”

Lesson #2: Don’t get fooled again (and again). Cyber security incidents happen, but that doesn’t mean they should happen over and over again. However, Starwood has a rather long and sordid cyber security track record. Just days after its acquisition by Marriott in 2015, Starwood disclosed a year-plus data breach. Security researchers who’ve dug deeper into Starwood’s history claim to have found unpatched website vulnerabilities, easily-guessed passwords, and more. Not every organization is lucky enough to survive a serious cyber security incident. Those who do, must elevate their game so as to not tempt fate.

Lesson #3: There’s still a place for traditional security measures. After a public data breach, observers and victims alike often make a big deal about the latest tools. And these cutting edge solutions absolutely have a place on any network. After all, traditional tools like firewalls can’t stand up to advanced, file-less attacks. More modern tools like next-generation antivirus (NGAV) can. Those traditional methods still have a role to play, however. The idea should be to build a security environment that is both forward-looking and grounded in the here and now.

Lesson #4: Good cyber security isn’t just about the tools. It may sound hokey, but cyber security is all about the people. Organizations need to spend time training employees on cyber security fundamentals – and putting policies and governance in place to support those efforts. It’s not solely up to a security analyst to spot phishing emails or to know to avoid plugging strange USB devices into their computers. These lessons and more should go out to the entire team, making it clear that keeping the business safe is everyone’s responsibility.

Lesson #5: Don’t make things worse. A data breach is bad enough on its own without the response inadvertently making things worse. Last year, Equifax bungled the response to its own catastrophic data breach by setting up an incident response site separate from its normal web domain. This confused everyone from victims to the company’s own social media team. The latter even tweeted out the wrong link, which could have put even more people at risk. Marriott, it would seem, has not learned from Equifax’s own failings. In response to this breach, the hotel giant sent out an email, also removed from its typical domain, alerting customers of the incident. The message was deemed “easily spoofable,” by TechCrunch and lacked all the things one would look for in a legitimate message. In short, the message itself was a security incident waiting to happen.

Lesson #6: Incidents lead to regulation … or at least calls for it. The dust hasn’t even fully settled on the Marriott/Starwood data breach, but the drumbeat for repercussions has already started on Capitol Hill. For example: the idea that Marriott foot the bill for replacing affected passports apparently originated from Senate Minority Leader Chuck Schumer (D-NY). Meanwhile, Sen. Edward Markley (D-MA) called the breach a “black cloud hanging over the United States’ bright economic future.” It’s up in the air as to whether this government unrest translates into meaningful action, yet, the prospect will likely loom large on the horizon for some time to come.

Next Steps: Put these cyber security lessons to work

A knowledgeable and experienced CISO can easily address and streamline all of the above points. This expertise can be difficult and expensive to find and retain. That’s where Arraya Solutions can step in. Through our vCISO service, we partner with organizations of all specialties to put the tools and resources in place to keep data safe.

Get the conversation started with Arraya’s Cyber Security experts today by visiting https://www.arrayasolutions.com//contact-us/.

Also: We want to hear from you! Leave us a comment on this or any of our blogs through social media. We can be found on LinkedIn, Twitter, and Facebook. Once you’ve shared your take, follow us to stay updated on our industry insights and learning opportunities.

Primary Sidebar

Back to Top
Arraya Solutions logo

We combine technological expertise and personal service to educate and empower our customers to solve their individual IT challenges.

518 Township Line Road
Suite 250, Blue Bell, PA 19422

p: (866) 229-6234     f: (610) 684-8655
e: info@arrayasolutions.com

  • Careers
  • Privacy Policy
  • Contact Us

© 2025 Arraya Solutions. All rights reserved.

Facebook Twitter YouTube LinkedIn
Manage Cookie Consent
We use cookies to enhance your experience. By selecting “Accept,” you agree to our cookie policy.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Manage options Manage services Manage {vendor_count} vendors Read more about these purposes
View preferences
{title} {title} {title}