Showing results for 
Search instead for 
Did you mean: 

Cisco has historically advocated separate data and audio/video VLANs. This is a great best practice as it enables Access Control Lists (ACLs) to be easily added at the Layer 3 boundary to control both signalling and media traffic. This has worked well for many years, but unfortunately the proliferation of mobile soft clients, such as Jabber, has somewhat broken the traditional design guidance. Whether it’s due to Jabber deployed on laptops using the wired infrastructure, or on smart phones over wireless, the topological demarcation between the data and collaboration environments has disappeared. This can make it very complex to use traditional VLANs to secure access to core collaboration services; as Jabber enabled devices can roam the Enterprise and often share the same VLAN with non-Jabber enabled data devices.

From a security perspective this creates a problem, which the traditional VLAN approach doesn’t really provide a good answer for. What is really needed for modern security conscious collaboration deployments is a dynamic policy based enforcement solution. Hence, it’s a good thing that Cisco Security Technology Group invented TrustSec!

For the uninitiated TrustSec is Cisco’s software defined segmentation technology embedded into its network infrastructure equipment. TrustSec uses contextual data about whom and what is accessing the network, and enables role based access using Security Group Tags (SGT) to segment the infrastructure. To learn more about TrustSec please click here.

The rest of this Blog discusses a recent Proof of Concept that was put together to demonstrate to partners and customers how a Cisco Collaboration deployment could be integrated into an Enterprise’s TrustSec implementation. The following diagram shows simplified lab topology with the associated functional components.

Figure 1 – TrustSec POC Lab Topology


Note: Everything described below for Phones is equally applicable to dedicated Personal or Room based Video Systems.

One of the advantages of TrustSec is that it allows an organisation to map out their policies for device to device, or device to service communication, and then implement these by the allocation of SGTs to ensure the infrastructure is correctly segmented.

As can be seen from the above diagram each element of the collaboration deployment was assigned a different SGT. In the case of the endpoints, Jabber (Emp_Mgd_Assets – SGT20) and Phones (UC_Endpoints – SGT21), the SGTs were allocated upon a successful 802.1x authentication. The core devices (UC_Servers – SGT50) and the Cisco Unified Border Element (UC_Supp_Services – SGT51) received their SGTs based upon static IP address mapping. In a real world scenario additional SGTs might be used due to factors such as topology and availability of additional collaboration services. A key strength of TrustSec is its design flexibility.

The basic lab set up only allowed media traffic to pass between the collaboration endpoints and signalling only from the endpoints to the core (Unified CM/IMP) servers. Where appropriate, access was also granted to LDAP and DNS services. The general lab policy was to not allow anything other than collaboration media streams between any access layer endpoints. A summary of the permitted traffic flows is shown below:

Figure 2 – Collaboration Traffic Matrix


At the time of writing, the specific signalling and media ports permitted were obtained from the latest, Unified CM and Jabber port guides.

From a Security perspective, large unsegmented networks are a significant risk. Segmentation helps limit lateral movement in the event of a successful attack and shows compliance with regulatory and audit requirements. Hence, given the requirements for peer to peer and client/server Security Group Access Control Lists (SGACLs) the Nexus 7K, Catalyst 4500 and the Catalyst 3650 switches were enabled as TrustSec enforcement points. This not only allowed for segmentation policies to be created and enabled between the Branch/HQ and the Datacentre (DC), but also within VLANs at the access layer. This is important because in Figure 1 the Jabber enabled Employee Managed Assets share the same VLAN as BYOD Contractor laptops that don’t have Jabber deployed on them. This did not create a segmentation problem because the BYOD Contractor devices were issued with different SGTs. The downloaded policy from the ISE ensured that the Contractors had no access to the core UC Servers in the DC, were isolated from the Phones in the Voice VLAN and also segmented from the Jabber clients that shared the same network.

In keeping with traditional best practice the POC phones were allocated their own Voice VLANs, and as mentioned previously, 802.1x authentication was used to allocate the appropriate SGT. This is undoubtedly the most secure approach but it is also possible to statically map Voice VLANS to a SGT, if for any reason, an organisation was unable to implement Network Access Control (NAC) for either phones or video endpoints.

In the lab the UC Supplementary Services (SGT=51) category was represented by a Cisco Unified Border Element Session Border Controller (SBC). In reality additional supplementary services could be provided by other types of devices such as MCUs and DSP farms. These could either be distributed across the infrastructure or centralised in datacentres depending on the system design. In the POC it was decided to give supplementary devices, such as Cisco Unified Border Element, their own Security Tag so that their individual signalling requirements to and from the core collaboration servers could be appropriately locked down.

Figure 3 – Looking at the Bigger Picture


Figure 3 shows the addition of three different classes of data application servers. The Collaboration SGACLs, with their implicit deny statements ensured that Phones and Jabber devices could not access these servers.  Even though a Jabber client shared the same VLAN with a BYOD Contractor laptop that had been granted permission to connect the application server types; TrustSec policies enforced the correct segmentation.

Part 2 of this Blog will provide the configuration details associated with the lab, including 802.1x settings, details on the ISE TrustSec deployment and the SGACLs used for the Collaboration signalling and media. In the meantime if anyone has any questions or comments, please feel free to post them.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers