Juniper Dynamic VPN and Pulse

There are couple of different types of VPN which can be configured with Juniper products. The MAG and SA products configure SSL VPNs and there are different ways of doing this but this quick post is just to mention Dynamic VPN using the SRX.

Dynamic VPN is an IPSec type VPN but it's not a site-to-site VPN it is a remote access VPN for endpoints. The client used is still Pulse.

The below document is a great reference for Dynamic VPN and Junos Pulse.

References:

[Dynamic VPN] Using Junos Pulse to connect Dynamic VPN client to SRX

http://kb.juniper.net/InfoCenter/index?page=content&id=KB17641

Webinar: C Series-UCSM Integration of C-Series Servers

Another Webinar to keep, this one about the Integration between C-Series servers and UCSM. I haven't seen it yet but here is the link to download the recording, Cisco CCO Login required:
WebEx recording: http://tools.cisco.com/pecx/login?URL=searchCourse%3FcourseId%3D00054025

Cisco StackPower Budgets and Info

So Cisco StackPower is a way of distributing power across a stack of C3750X and C3850 switches. The idea is that instead of each switch having multiple redundant PSUs you just need a couple and should a single PSU fail in the stack, if the switch wouldn't have enough power to maintain full operation it can draw unused power from other switches in the stack which have excess power.

Pretty cool but one thing to be aware of is each switches power budget. So although the datasheet for each switch states the power consumption of a switch this is not the amount a switch requires for operation and this is the power budget. For example C3750X-24 switches state that the power consumption at 100% load is 93.5W. You would then assume that a 350W power supply would be able to power 3 of these switches. This is not the case. A C3750X-24 switch actually has a power budget requirement of 190W, meaning you cannot power 2 switches with a single 350W power supply.

Stack power switch power budgets and further information can be found at the below reference:

References and Resources:

Cisco Stack Power White Paper
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps6406/white_paper_c11-578931.html

Cisco Flexconnect (Previously HREAP)

Cisco Flexconnect (which was previously known as HREAP) is a technology which allows access points (APs) to be deployed remotely from the controller but allow for distributed switching of local packets, which saves some traffic from being sent back down the CAPWAP tunnel, and over the WAN, back to the controller only to be sent back again to the AP to be switched. When using Flexconnect mode the AP actually terminates the CAPWAP tunnel rather than the WLC.

The opposite of Flexconnect is called local mode. And just to be confusing in Flexconnect mode the traffic is "locally switched", local to the AP. Where as in Local mode the traffic is centrally switched, centrally on the WLC.

In local mode there are 2 CAPWAP tunnels between the AP and WLC, one for data and one for management. In Flexconnect mode there is just one, for management, the data CAPWAP tunnel is terminated on the AP.

Flexconnect is supported on a number of different controllers, currently just the CUWN controllers (2500, 4400 [EOS] 5508, 7500, 8500). The unified access controllers (5760 Catalyst 3850) will get an upgrade at some point but do not currently support it and there is no date set. This is true as per 18/07/2013.

Flexconnect is the same regardless of the WLC, the 5508 implementation is the same as the 7500 implementation. A note on this is that the 7500 controller only supports Flexconnect mode, not local mode.

Guest networks function with the Flexconnect feature, the CAPWAP tunnel is terminated at the AP for corporate traffic that can be switched at the AP but guest traffic is tunnelled back to the controller and then onwards to the guest anchor controller as normal. See the reference link below regarding Flexconnect and auto anchor. This image, taken from that link, illustrates this well:

There are a number of limitations to Flexconnect, which I've listed below, which stops it replacing Local mode completely:

• L3 roaming is not possible with HREAP APs using locally switched WLAN.
• L2 roaming between two WLC(inter-controller) using locally switched WLAN with same mobility works only from 7.2.103.0.
• Data DTLS is unsupported for locally switched WLAN.
• Interface group is not supported however we can use AAA override.
• Mediastream feature won't work.
• Bandwidth contracts won't work for local switching.
• WGB can't connect to HREAP AP. (it may connect & work with central but doesn't work with local switching)
• All edge switches connecting to AP needs to be trunked to the core.
• HREAP AP doesn't join Multicast group. however it bridges the multicast packet to unicast for centrally switched WLAN.
• DHCP proxy by WLC is not possible. so we're exposing the DHCP server IP.
• ACLs needs to be configured & managed per AP for locally switched traffic or configure at your switch.
• CPU & interface ACL are NA for locally switched WLAN.
• RLDP may not work.
• AP group won't work for locally switched WLAN.
• Locally switched WLANs may optionally carry 802.1Q tagging to allow such WLANs to be segmented over the wired network at the Ethernet port of the access point.
• NAC out-of-band integration is supported only on WLANs configured for H REAP central switching. It is not supported for use on WLANs configured for H REAP local switching.
• External Web Authentication is not supported on local switching

References and Resources:
Flexconnect Feature Matrix
http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080b3690b.shtml

Flexconnect and AutoAnchor (Cisco Support Community)
https://supportforums.cisco.com/docs/DOC-24096

Local Mode vs Flexconnect (Cisco Learning Network)
https://learningnetwork.cisco.com/thread/51502

Cisco FabricPath - As I Understand It

Cisco FabricPath is a Layer 2 fabric technology, used between the access and aggregation in the data center, which is an alternative to using spanning tree or layer 2 "pods" separated by layer 3 boundaries. This image taken from the Cisco FabricPath whitepaper illustrates this well:

Data centers are different to many enterprise campuses in that they need to extend layer 2 connectivity across large portions of the data center, often to take advantage technologies such as moving virtual machines around the data center.

Without going too far under the hood and staying very conceptual at this stage FabricPath uses a control protocol on top of IS-IS to delivery scalable L2 connectivity without blocking links.

Instead of the classic "data center triangle" using vPC and 2 connections to each pods aggregation switch FabricPath has a single connection to each aggregation switch. Using the example above the bandwidth is the same (40Gbps) but aggregation switch failure only reduces this by 25% rather than 50%.

FabricPath uses ECMP (Equal Cost MultiPath) so that all  links are forwarding and the ports in a port channel is 16 and ECMP v1 supports 16 way ECMP, making the fabrics potential 2.56Tbps (16 ports x 16 way x 10Gbps = 2560Gbps) as illustrated in the next diagram, again taken from the Cisco FabricPath white paper:

 Some benefits of FabricPath include:

• Simpler configuration
• Scalable layer 2 connectivity
• Higher Bandwidth
• Better availability in failure scenarios

Resources:

This information was mainly taken from the Cisco FabricPath whitepaper but trimmed and reworded for my own reference:

Cisco FabricPath Whitepaper

http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9402/white_paper_c11-605488.html

Webinar: Cisco Simplifying IP/MPLS High Availability

I don't have much to say on this one sadly because I missed it, but here is the recording for reference

Here are the links to the recordings:
WebEx recording: http://tools.cisco.com/pecx/login?URL=searchCourse%3FcourseId%3D00053754
PDF: http://tools.cisco.com/pecx/login?URL=searchCourse%3FcourseId%3D00053739
MP4: http://tools.cisco.com/pecx/login?URL=searchCourse%3FcourseId%3D00053780

Cisco Guest Anchor WLC + Licensing

When deploying guest services in a Cisco WLAN you need to have an anchor WLC controller, which is located in the DMZ, which terminates the Ethernet over IP tunnels (EoIP) coming from the other campus controller, the foreign controller. EoIP is used in order to keep the guest traffic separate from the other enterprise traffic.

This image is taken from the Cisco Mobility design guide, link below, and illustrates the anchor controller functionality.

There is no additional licensing required to implement anchor controllers and no AP licenses are required, in fact you should purchased the appropriate controller with the least amount of AP licenses. This is because APs do not register to the anchor controller but rather to the foreign controller (the main WLC for the enterprise).

References:

Enterprise Mobility Design - Wireless Guest Access Services:

http://www.cisco.com/en/US/docs/solutions/Enterprise/Mobility/emob73dg/ch10GuAc.html

Cisco WLC HA Deployment modes & AP SSO

There are 2 (that I know of) ways to deploy Cisco WLANs with regards to High Availability (HA):
N+1
1:1
Hybrid

One quick note before I start is that the SSO here is AP SSO not Client SSO, so a voice call would still be dropped. There is sub second failover but the client is required to reinitialise. Client SSO should be coming in version 7.5 of code.

N+1
As described in my previous post about N+1 HA this deployment models allows a dedicated HA WLC to be installed with the purpose of backing up an environment. An example would be a single primary controller with all APs connected to it with a HA controller, located physically somewhere else, running with the sole purpose of picking up in the event of a primary WLC failure.

An important consideration with this model is that there is no AP SSO (Stateful Switch Over) meaning there is approximately a 45 second period of delay while the APs connect to the HA controller after the primary has failed.

It's worth noting here that if you want to use the HA controller (for example AIR-CT5760-HA-K9) you need to run code 7.4 or later. Code pre 7.4 requires the HA controller to have access point licenses to operate as a secondary or tertiary controller.

The HA controller picks up licenses from a failed primary controller. So whether there is a single primary controller or multiple primaries for different groups of APs the HA controller can back up a number of different WLC. Further to this point the HA controller can pick up APs from multiple failed primary controllers. A 5508 HA has a wireless AP capacity of the device maximum, which is 500. So if there are 2 primary 5508 controllers, each with 250 APs, if one fails the 250 APs will fail over to the HA controller, then should the other primary controller fail those access points can fail over to the HA controller as well to the maximum of 500. See the HA Q&A for details.

Previous post:
http://twhittle1.blogspot.co.uk/2013/05/cisco-wireless-n1-ha.html

1:1
1:1 HA redundancy describes 2 controllers, one as the active and one as the standby. These controllers are physically located next to each other because there is a redundancy port on each controller which must have a physical cable between them. The reason for this connection is in order to achieve the AP SSO there must be a very small latency when noticing the failed primary controller. Even though theoretically it is possible to have AP SSO work when the controllers are layer 2 adjacent, the only Cisco supported configuration is with a direct link in between the two controllers.

When using 1:1 HA the APs will see this as a single controller, in fact the APs will not notice a controller failing this is how the AP SSO is achieved.

Hybrid
The Hybrid method is a best of both worlds implementation because you have a primary controller with the hot standby physically connected and located together, as well as other controllers, secondary or tertiary in remote, geographically separate, locations so that should the HQ with primary WLC go down there are other controllers in different locations ready to step up.

Another way of implementing a hybrid deployment would be to have 2 sets of 2 WLC in geographically separate locations. In one location there is a primary with a hot standby and in the other a secondary controller with a hot standby. This way a single controller can fail in each location and retain the AP SSO. However is a whole site goes down and the primary has to fail over to the secondary then AP SSO will not be retained, failing over between primary and secondary controllers will always introduce downtime.

References:
High Availability (AP SSO) Deployment Guide:
http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080bd3504.shtml

High Availability Q&A:
http://www.cisco.com/en/US/prod/collateral/wireless/ps6302/ps8322/ps10315/qa_c67-714540_ps2706_Products_Q_and_A_Item.html

Cisco Voice Gateways with MS Lync

Cisco voice gateways can be used in a MS Lync environment. If local breakout to the PSTN is required then some kind of voice gateway is needed.

Cisco and Microsoft have an established history of cooperating across technologies to provide customers with innovative business solutions. From Cisco's standpoint we support voice gateways connected to anything that complies with the standards, including MS Lync. From MS's standpoint, I believe they do certification tests with vendors' equipment before they say they support it. 

As far as I know, deploying Cisco ISR G2 in integration with Microsoft Lync has no issues except for a couple of caveat which is Cisco does not support Microsoft proprietary codecs (ie RTAudio and RTVideo).

The below document is a good reference for an ISR voice gateway terminating a SIP trunk in a Lync enironment:

http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns728/ns833/1197443.pdf

Just an update to the above post, I've since found that there are companies, such as Sonus, who build Lync SBAs which are affectively SRST boxes which also have the voice gateway features, you specify the interfaces and they can build the device, I believe it's just a server with the appropriate cards, but this is certainly something worth bearing in mind.

Cisco Prime and IP Phones

Within Cisco Prime Infrastructure IP phones are not counted with regards to licensing. This is because Cisco Prime Infrastructure does not manage IP phones. Here is a link which details the devices which can be managed with Prime Infrastructure: http://www.cisco.com/en/US/products/ps12239/products_device_support_tables_list.html.

I am told there is a limited amount of management which can be done to IP phones within Prime infrastructure if you know what you are doing but for a comprehensive UC management solution see below:

In order to manage IP phones, you will need to have Cisco Prime Collaboration, which does count the IP phones for licenses. For more information regarding Prime Collaboration licensing, please refer to http://www.cisco.com/en/US/prod/collateral/netmgtsw/ps6491/ps12363/guide_c07-728239.html.

Cisco MSE and 3rd Party APs

Just a quick post...

At this time the MSE is compatible with only Cisco Access Points for wIPS and location tracking in addition to other key functions such as ClearAir which are specific to the Cisco APs. 

Cisco does have the Ability to manage 3^rd party APs with the MSE’s management front end under Prime Infrastructure, however the advanced features are specific to the Unified Cisco Wireless Solution.