Tag Archives: cisco

Cisco WLAN Controller not passing traffic – resolved – but not sure why

I ran into a strange problem recently, a Cisco WLAN controller 5508 with 1142N APs (not sure the model and controller matter entirely as I found the fix on a support forum thread for a 4000 series) would allow clients to connect, get an IP address but NOT pass any traffic other than ICMP.  I thought maybe the problem was Windows firewall related but disabled it still appeared.  I thought maybe a driver problem but tried several revs of the driver, and it also happened with different model cards.  A temporary work around was to disable, then re-enable the wireless card.

DHCP is handled by a Windows 2008 server, not the access points or WLAN manager, and again – the client was actually DHCPing an address (as I type that I wonder if there is a problem with the DHCP server now, but it didn’t happen to wired clients or on a temporary access point we brought in…).  There was a thought it was a DHCP problem since ping worked, but I could not access network resources via IP which ruled DNS out.  Yet another test was to isolate the WLAN controller and APs on to a separate switch.  This also eliminated what appears to be a known problem with 2960 switches where APs cannot register with the controller (which wasn’t our problem but worth isolating anyways).  I also removed all but 1 of the APs, but the problem persisted.

Now had I listened to my own Troubleshooting 101 post, I would have opened a support ticket, but this particular company let the support lapse and did not want to renew it.  This also meant I did not have access to download the latest software for the controller or APs.  So for those wondering, thats why there was no all into Cisco TAC on this issue.

What lead me to the fix that ultimately “fixed” the problem was an error I found in the logs “APF−1−REGISTER_IPADD_ON_MSCB_FAILED: Could not RegisterIP Add on MSCB. MSCB still in init state.”  Now I am happy this is fixed, but I am not happy with what the “fix” was yet because I haven’t found good documentation that explains why this fixed our problem.  I had to enable DHCP Addr. Assignment in the advanced section of the WLAN config, according to the documentation from Cisco:

DHCP Addr. Assignment Required setting, which disallows client static IP addresses. If DHCP Addr. Assignment Required is selected, clients must obtain an IP address via DHCP. Any client with a static IP address is not be allowed on the network. The controller monitors DHCP traffic because it acts as a DHCP proxy for the clients.

Thats good and all, but my clients WERE DHCPing  addresses just fine and APs were broadcasting SSIDs just fine.  Oh and by the way this was all working swell through October, for several months actually, and just started to have problems in November.  If anyone has a better description/document that more deeply defines the DHCP Addr. Assignement Required option I would love to read it.


HA with UCSM Integrated Rack Mounts from UCSguru.com

Great overview of HA with Cisco UCS manager


Hi All
One of the founding members of the Cisco UCS Avengers , Fabricio Grimaldi (who also happens to be the Cat who first introduced me to Cisco UCS) came up with a great question.

“How does HA (Split Brain avoidance) work with UCS Manager integrated Rack Mounts when there is no Chassis and therefore no SEEPROM.”

Great question and one I had to admit I did not know the answer to.

Luckily another 2 Cisco UCS Avengers founding members were also CC’d in on the question Scott Hanson and Sean McGee and it was Sean who came back with the answer.

But before we get into the answer a quick recap on how this works in a B Series environment

B Series Split Brain

If you are ever in the unlikely scenario that both of your Fabric Interconnect cluster links fail (L1 and L2) the Active UCS Manager remains active but the standby…

View original post 630 more words

Cisco versus VMware – you guys are blowing this way out of proportion

There is 1.05 billion reasons why there are so many blog posts about this supposed battle, struggle, whatever you want to call it between Cisco and VMware ever since VMware’s acquisition of Nicera.  While I am sure there is some insider knowledge coming out in these blog posts, lets look at it from a calm, unbiased position.

Cisco and VMware are two separate companies, except from the perspective of their joint venture – VCE.  I am going to ignore VCE for the moment because the partnership still makes sense on so many levels, and what IT person wouldn’t kill for a vBlock of any size in their data center.  What VMware does with the technology acquired from Nicera will go a long way towards proving my point, or blowing it up.  Before the acquisition VMware still produced virtual switching software in the form of Virtual Standard Switches (VSS) and a Virtual Distributed Switch (VDS) that companies could, and do use.  Leveraging the Cisco Nexus 1000v was always an add on to VMware so if Nicera is simply used as an upgrade to the features and functionality in the native VMware VDS nothing changes.  If VMware makes/keeps Nicera as an add-on, some might say direct competition to the Nexus 1000v nothing changes.  Now before you skip to the end and rip me for that last sentence hear me out… who is using the Nexus 1000v?  My SWAG – companies who are heavily invested in Cisco network infrastructure.  Those companies will still have a major investment in physical Cisco infrastructure which does NOT get replaced by virtual switches.  Sure virtualization might be hurting the ToR (Top of Rack) switch market like the Nexus 2000 FEX’s or lower end switches like the 2900 or 3700 series but that is likely not a ton of revenue for Cisco anyway – yes its still lost revenue but it was lost with virtualization anyways and I suspect being made up nicely by Cisco UCS server/blade/accessory and licensing sales.  Now back to my original point, if you are a Cisco shop anyways are you really considering Nicera as a replacement for the 1000v?  My bet is no, at least not enough to make a difference at a few hundred dollars per socket.

Second point – Cisco and VMware have ALWAYS had to be platform/partner agnostic.  VMware was never going to shut out compatibility with HP, IBM or other brand servers just as Cisco, at least on the sever side was never going to shut out other hypervisors or operating systems such as OpenStack, Hyper-V, Xen, Windows, and *nix or even break compatibility with IEEE standards on the routing/switching side regardless of what was going on at VCE.  VMware would continue to work with other server vendors, even other storage vendors.  Do you see VMware (read EMC) blocking/breaking compatibility with HP, NetApp or other storage vendors?  No they are increasing the opportunities for new storage vendors to enter the market and build compatibility with VMware.  EMC and Vmware are also making it easier for server vendors to work with them in the form of VSPEX/reference architectures   Cisco’s release of an official OpenStack implementation is nothing more than supporting a rising platform in the cloud computing space.  Cisco supports Hyper-V and XEN, so why is it that OpenStack is any more of a challenge than Cisco’s public support of other hypervisors?  Did someone at Cisco get a kick out of thumbing their nose at someone from VMware they don’t like working with…yea probably but its not going to change the fact that VCE is a great partnership for all parties involved.  vBlock is the best of breed, unified data center technology with a single support vendor, single purchase vendor, and single maintenance renewal vendor.

Cisco ASA client IPSEC VPN not passing traffic

Recently I needed to  setup a new VPN to replace an aging Cisco VPN Concentrator, as part of the upgrade I also wanted to add redundancy to the firewall as there was only a single older ASA 5510 setup by the previous IT team.  I decided to setup a pair of Cisco ASA 5520′s with an IPSEC VPN for users which would authenticate against Microsoft Windows Network Policy Server (previously Internet Authentication Server or IAS).  The current firewall was working well with 2 point to point VPN’s already configured and the ACL’s setup properly.  Rather than re-invent the wheel, I decided to simply forklift the configuration onto the new ASA’s and swap them out.  When the two ASA’s arrived, I setup a basic configuration and applied a pretty standard VPN configuration that would support my needs and tested with a small group of volunteers – all went swimmingly until….

I went to apply the configuration to the current production ASA 5510 – again this wasn’t rocket science – an ACL here, aaa-server there and and a few policies later and it should have been working.  I emailed a few test users and asked them to connect and boom they were on the VPN – but wait!  They were not able to pass any network traffic to the protected network.  I knew the configuration worked fine since I had tested on the new ASAs.  I setup a capture on the ASA but was not seeing any traffic so I checked all the routes, made sure the correct networks appeared in the VPN client, still nothing  – not even a single hit on the capture.  The packet tracer showed all traffic being able to flow in both directions until phase 12, being dropped by an implicit deny.  After double checking our ACL’s over and over again I opened a ticket with Cisco TAC.  So what burned me?  A Dynamic Access Policy (DAP)!  The previous IT team had tried to configure a VPN on the ASA years before, but it never worked.  They had tried to use the ASDM to configure it and created this policy which was conflicting with my VPN configuration even though we hadn’t explicitly defined the group-policy to be used on our connection.  I removed the no nat ACL entry and traffic was able to pass as expected.

VMware View Mobile Secure Desktop Boot Camp Cisco VXI Smart Solutions

Not sure where this was hiding on the VMware community boot camp page a few weeks ago!