Cisco Live was recently concluded in Orlando, Florida where Cisco announced the new top-end Nexus 7700 switches with new ASICS which is capable of working up to 100 Gb/ sec speed. The new 7700 line will come in two versions: a 10-slot 7710 and an 18-slot 7718. Cisco says the chassis will be available in July
Cisco says it has more than 40,000 Nexus 7000 chassis in the field. Now it has two more switches to add to the 7000 family with the Nexus 7700 line. The 7700 has a maximum throughput of 83 Tbps, and a single system can have up to 384 40-GigE ports or 192 100-GigE ports. As with other switches in the 7000 line, the 7700s will include dual redundant supervisor modules to enable software upgrades without losing packets.
The Cisco Nexus 7700 10-slot switch is scalable up to 42 terabits per second (Tbps), whereas the Cisco Nexus 7700 18-Clot Switch cab scale up to 83 terabits per seconds. Both switches are designed to offer high availability, exceptional performance, and high density 40 and 100 Gigabit Ethernet (GE) and front-to-back air flow. That makes it ideal for high performance data center access, aggregation, core, and Unified Fabric deployments.
Looks like Cisco is trying to refresh its product line in competition with other Switch manufacturing vendors.
In my previous post we saw how to overcome the Cisco NAC restrictions for the Windows Deployment Services Server, as we progressed and started implementing the solution in our production environment we discovered various challenges.
In our production network we are applying various kinds of Layer 2 security at Cisco Access Layer Switches. One of the applied layer 2 security policy is IP Source guard.
IP Source Guard provides source IP address filtering on a Layer 2 port to prevent a malicious host from impersonating a legitimate host by assuming the legitimate host’s IP address. The feature uses dynamic DHCP snooping and static IP source binding to match IP addresses to hosts on untrusted Layer 2 access ports.
Initially, all IP traffic on the protected port is blocked except for DHCP packets. After a client receives an IP address from the DHCP server, or after static IP source binding is configured by the administrator, all traffic with that IP source address is permitted from that client. Traffic from other hosts is denied. This filtering limits a host’s ability to attack the network by claiming a neighbor host’s IP address. IP Source Guard is a port-based feature that automatically creates an implicit port access control list (PACL).
In all our access switches IP Source Guard is enabled by as shown below
When we enable IP source guard, the Windows Deployment Services Server failed to install Windows 7 over the network. Upon troubleshooting we discovered that there is a bug CSCts44728 per which IP Source Guard stops PXE boot, you can find more info about it here
This bug is available in 12.2(55) SE3 IOS version, however its fixed in 12.2(55) SE5 and in 15.0(2)SE IOS versions.
In order to deploy Windows 7 over the PXE using Windows Deployment Services Server we were forced to disable the IP Source Guard feature by using the Cisco IOS command “no ip verify source”.
The only way enable Ip soruce guard is to upgrade the IOS of the switch from 12.2(55) SE3 to 12.2(55)SE5 or later.
How to integrate Windows Deployment Services Server with a typical Cisco Networking devices – Series 3
Let’s continue to with rest of the steps to allow Windows Deployment Services Server through a Cisco NAC.
Click Add Polices
Add the IP address of Windows Deployment Services Server along with the UDP ports required
The Windows Deployment Server needs the following UDP ports to be opened from unauthenticated role (Untrusted -> Trusted role)
The IP address of Windows Deployment Services Server in our case 10.204.27.49
The UDP ports required for any Windows Deployment Services Server is as follows
Then click update policy
Create one more policy for the TCP ports required for Windows Deployment Services Server
The Windows Deployment Server needs the following TCP ports to be opened from unauthenticated role (Untrusted -> Trusted role)
The IP address of Windows Deployment Services Server in our case 10.204.27.49
The TCP ports required for any Windows Deployment Services Server is as follows
Then click update policy.
By following these steps we could deploy Windows 7 using Windows Deployment Services Server even when the workstation is connected in untrusted role in the Cisco NAC
How to integrate Windows Deployment Services Server with a typical Cisco Networking devices – Series 2
In series 1 we discussed how to integrate Windows Deployment Services Server with a typical Cisco Networking devices. We dealt with the configuration at the distribution layer switches, yes by adding ip-helper address the issue was resolved. When we tried the same setup in our live environment which consists of Cisco NAC we faced the problem. Obliviously without NAC client and posture assessment the NAC CAS server won’t allow the client as a trusted client.
The only way is to allow access for a Client PC from untrusted mode to access Windows Deployment Service server. This can be done by creating policy for user management in Cisco CAM device as show below
Login to CAM Device
Click – User management
Select unauthenticated roles
I will continue the reset of the steps in next post.
Couple of days back I received an email from Microsoft with a subject “TechNet Subscriptions retirement” and following are its contents.
“As IT trends and business dynamics have evolved, so has Microsoft’s set of offerings for IT professionals who are looking to learn, evaluate and deploy Microsoft technologies and services. In recent years, we have seen a usage shift from paid to free evaluation experiences and resources. As a result, Microsoft has decided to retire the TechNet Subscriptions service and will discontinue sales on August 31, 2013.”
I was shocked with the decision taken by Microsoft, is it a right decision? The question now arises is how are they going to provide testing environments for small time developers? Usually 90-180 day evaluation won’t give much flexibility. Well time will tell how it’s going to impact the IT professionals. Currently most of the IT professionals are not happy with this move of Microsoft.
Though Microsoft are reassuring the IT professionals with the following message
“Subscribers with active accounts may continue to access program benefits until their current subscription period concludes.
We are committed to helping customers through this transition phase and will remain focused on providing IT professionals with free access to a broad set of TechNet assets that support the needs of IT professionals around the world.
Improved Free Offerings for IT Professionals Include:
- TechNet Evaluation Center: Free evaluation software with no feature limits, available for 30-180 days. Includes rich evaluation resources and TechNet Virtual Labs, which enable you to evaluate software without the need to install bits locally.
- Microsoft Virtual Academy: Free online learning site, with over 200 expert-led technical training courses across more than 15 Microsoft technologies with more added weekly.
- TechNet Forums: Free online forums where IT professionals can ask technical questions and receive rapid responses from members of the community.
Please note, MSDN Subscriptions provide a paid set of offerings that are also available for those who require access to evaluation software beyond what the above free offerings provide.”
I strongly believe that Microsoft could have reduced the type of services they were offering through TechNet subscriptions rather than stopping it completely.
How to integrate Windows Deployment Services Server with a typical Cisco Networking devices – Series 1
Recently we tried to deploy Windows Deployment Services Server in our environment, to enable the deployment of Windows operating systems over the network for our workstations, so that our technical support team do not have to install each operating system directly from a CD or DVD.
Our Windows Deployment Services Server was connected to Cisco Nexus 5000 Series Switch as shown in the below layout. We do have a redundant network devices at each layer but to make things easier I have removed them.
When our Systems Team tried to deploy the service in one of the work station connected to Cisco 3750 E Series Access Switch it failed. Our Cisco 3750 E access switch is connected to Cisco 6506 E Switch through a trunk port and the connectivity between the Distribution Switch and Core Nexus 7010 Switch is a layer three link. All our edge VLANS are created in the distribution switch.
The workstation can ping the Windows Deployment Services Server, but the installation of Windows 7 Operating System failed over the network. Upon troubleshooting we figured out that an IP helper address should be configured in the VLAN in the Cisco 6506 E Distribution switch. Once we configured the IP helper address as shown below the problem was solved.
ITKE01(config)#interface vlan 300
ITKE01 (config-if)#ip helper-address 10.204.27.49
However the same scenario behind the Cisco NAC Servers failed, in the upcoming post I will let you know how to over come this problem.
When it comes to Cisco’s networking products, the default operating system comes into our mind is Cisco IOS, a very popular OS among the networking professionals, however, when it comes to Cisco Email Security Appliance (ESA),better known as Cisco IronPort appliances the OS changes.
The Cisco IronPort Appliances are geared and operated by powerful collections of software’s better known as AsyncOS. The AsyncOS is a collection of base operating system (OS), device drivers, memory management, process scheduling, and all the application and scanning software. Few unique features of AsyncOS are its high performance and security.
The AsyscOS fundamentals are built on FreeBSD, low-level components are written in C programing language. However, most of the application software and the entire management interface is written in Python and use a coroutine-based model called shrapnel.
AsysncOS versions are referred as the Major.Minor.Point-Build number format as shown below.
One interesting fact about the AsyncOS software builds is. It is complete and self-contained. When an AsyncOS is upgraded from, one version to another, the entire build image is upgraded rather than individual upgrade component.
When it comes to Email Security, no other product is as powerful as Cisco IronPort. Therefore, we opted Cisco IronPort C370 as our email security gateway. Since its inception into our network, I am searching for a great reference and study guide for the Cisco IronPort products.
At the beginning, I was depending more or less on Cisco Web Site resources, which are great. However, the moment I discovered that Chris Porter is writing a book with a title “Email Security with Cisco Iron Port” I was excited. Immediately I contacted Jamie Adams at Cisco Press, as usual she arranged a copy of book for me for a review and reference.
The title “Email Security with Cisco IronPort” is tailored made for those professionals who have a good understanding of basic networking concepts. The author Chris Porter did an amazing job especially with the Introduction part. I really loved it, be it the overview or history of AsyncOS versions. I think the author is quite smart in addressing his readers, be they are beginners or experts of the subject. He knows how to keep them intact.
The title “Email Security with Cisco IronPort” consists of 15 chapters covering the concepts like ESA products, the WEB user interface, Command Line interface in IronPort, and much more in detail and in simple language.
The main highlight of “Email Security with Cisco IronPort” book is the configurations recommended by Chris Porter.
After reading this title, it really enriched my knowledge and made my quite competent in managing Cisco IronPort devices, I would definitely recommend this title to all those professionals who are keen to know more about Email Security with Cisco IronPort devices.
Currently, we are testing some of the network and application monitoring solutions, so that we can go with a product, which serves our needs. We approached many vendors and got a good response from them, and some even offered to do a proof of concept. Which we opted happily, and in fact it helped us to take some strategic decisions, which were in the interest of the Organisation.
During this journey what we observed is that some vendors were reluctant to provide a proof of concept, and they tried to convince us they are in the in the magic quadrant of Gartner in that particular field, by doing, so they lost the opportunity with us. My question here is, it right to choose a product or solution just because it is in a magic quadrant of Gartner? Your feedback and comments are helpful.
What is the error “Signature Auto Update Fails with Error HTTP connection failed [1, 110] “ in Cisco IPS sensors?
Recently, I configured our Cisco IPS Sensors modules SSM-40 installed in the Cisco ASA 5540 and Cisco IPS 4270 sensor to auto update the signature behind our Blue Coat Proxy SG, upon configuration, I discovered that the auto updates failed. When I tried to know status by using Cisco IOS command.
“show statistics host” I discovered the auto updates failed, and the command was giving the following errors
IPS#show statistics host
Auto Update Statistics
lastDirectoryReadAttempt = 19:31:09 CST Thu May 9 2013
= Read directory: https://22.214.171.124//cgi-bin/front.x/ida/locator/locator.pl
= Error: AutoUpdate exception: HTTP connection failed [1,110] <–
lastDownloadAttempt = 19:08:10 CST Thu May 9 2013
lastInstallAttempt = 19:08:44 CST Thu May 9 2013
nextAttempt = 19:35:00 CST Thu May 9 2013
These errors generally observed in IPS sensors running 7.0(7) and 7.0(8) due to a bug “CSCub08230”. In order to overcome this problem available work around is either to download the signature update package manually from Cisco.com and apply the updates manually to the IPS sensors or to upgrade the Cisco IPS sensors to latest update of 7.2.
The strange thing is that the IPS Sensors were communicating with the Cisco Servers they could be able to connect bypass the proxy servers as shown in my below capture.
However, they failed to update signature simply because the initial connection to the locator service is performed using the HTTPS connection, and the once sensor is authenticated by the digital certificate provided by the server. The connection is switched over to HTTP for the auto-update process. This changer over from HTTPS to HTTP is failing due to the bug “CSCub08230”
Hence, temporarily I was forced to revert my configuration and allow IPS sensors to communicate directly with Cisco servers bypassing our bluecoat proxy server.