Comments on equipment

[Brian Bergin]

Vendors have struggled for years to come up with standard settings for equipment that will likley be added to existing infrastructure.  Cisco, however, doesn't seem to want to play nice, even with its own equipment.  First, for most small businesses they're likely to be on 192.168.1.0/24 not 192.168.10.0/24. WAP4410N comes on a respectible 192.168.1.245 which is likely to be accessible from an SMB desktop or server (though could easily be stepped on if another device, say another Cisco WAP, were already installed).  The ESW, on the other hand, comes on a 192.168.10.2 IP, unlikely to be accessible by many SMBs with an existing network.

The question begs why would these products not come out in DHCP mode?  The simple solution here is to default boot in DHCP mode and if a DHCP server is found ask for an IP.  If one is given then use that one.  If one cannot be obtained default back to a more logical IP in a typical SMB office.  When Cisco's small business line was Linksys all their products came out on 192.168.1.0/24, now we have a mix and that mix is just crazy.  It makes for field support nightmares when you drop ship a device to a customer to replace a dead one.

Now, yes, Thunderbolt should help with this, but that's assuming Thunderbolt can see devices on a subnet off the LAN?  What's going to happen if an ESW dies, a customer obtains a new one that comes on 192.168.10.2 and the customer LAN is on 192.168.1.0/24?  Will Thunderbolt see the new switch and configure it?

In the end, IMHO, every single Cisco SMB device needs to come with DHCP enabled and a backup static IP on 192.168.1.0/24. At the very least they all need to come on the same subnet so if Cisco is going to insist on 192.168.10.0/24 for some of its devices they all need to be on 192.168.10.0/24.

Brian

[Marcos Hernandez]

Brian,

I am sure some of my teammates will also add to this. I will also bring this up with our Product Management team so they can provide some answers and hopefully address your concerns (very valid ones, by the way).

What I wanted to say is with regards to the WAP4410 and how Thunderbolt abstracts or eliminates some of these inconsistencies in our default settings. Currently, the Thunderbolt Appliance (TBA) discovers the WAP4410N on its default static IP on the same LAN segment (192.168.1.245) and then proceeds to change it to DHCP. We still need to work and fix some concurrence cases (multiple AP's on the same segment), etc. but the idea is that you, as the partner deploying this, will never notice problems like the one you mentioned.

Yes, we need to normalize our defaults, but for now, we are trying to hide the complexity by automating certain functions on the products for which we claim support.

Thanks for your feedback. Keep it coming.

Marcos

[afullfor]

Just want to add some technical specifics.

The WAP4410N when delivered with current firmware already defaults to using DHCP with announcements via Zeroconf (Bonjour) so you can find the device on whatever DHCP address it is issued.

The problem is that the hardware we are delivering for the trial is shipping from the factory with an earlier version of the firmware, and this firmware exhibits the default static IP behavior.  The Thunderbolt appliance specifically looks for the static IP (creating a separate subnet to do so if necessary) and when it finds a WAP4410N will offer the option to upgrade it to the latest firmware with a factory reset on the Portal topology page.  Once running on the latest firmware, the factory reset causes the new default behavior and the device starts to use DHCP.  One warning, the device also defaults to create a single open SSID, so once the firmware is updated, you should immediately configure the device appropriately.

In a scenario where you are deploying multiple WAP4410Ns at a site, it should work to plug one in, have it discovered, use TB to upgrade the firmware, and then plug the next one in and repeat.

We hope to use the same approach to handle other hardware which exhibits this older behavior as we move forward and support additional devices.

In the case of the ESW500, these should all start up using DHCP.  However, they do exhibit an unusual behavior of advertising their static default at first (192.168.10.2) and only after DHCP has resolved do they start advertising the new address.  Some Bonjour browsers do not see the IP update for quite some time, so I expect this is what you have encountered.  The TB Portal does rapid re-resolution specifically to work around this issue with the ESW so you should see the DHCP address on the TB topology page fairly promptly, even if it does not show up in your Bonjour browser.

[Brian Bergin]

I have to say Cisco SMB's division's insistence on "factory resets" is the most annoying and unacceptable thing I run into on a regular basis.  Imagine if you will telling a Fortune 500 company upgrading an ASA from one build to another that they have to factory reset and then reload every setting.  Let's ask a few ASA admins how long they'd continue to use ASA's if this were the case.

I had to reload 3 pages of ACLs on an RV082 becuase the upgrade from v1.3 to v2.0 showed the ACLs but none of them worked.  That was a day long job.  Who pays for that?  The customer and when the customer is paying for labour they shouldn't have to pay for they're not happy.  Thunderbolt needs to find a way to restore settings, ACLs, WPA keys, etc... when updating firmware or it will be all but useless.

Brian

[Brian Bergin]

I have to say I'm not excited by the statement that Thunderbolt discovers the WAP on it's static then changes it to DHCP.  Why would you discover the 4410N on its static IP then change it to DHCP?  Why would anyone want to run what is essentially a server device on a DHCP IP?  It'd be like running an IP printer on DHCP.  Routers, switches, print servers, and actual data servers should always be on static IP addresses.  If your DHCP server fails your your critical infrastructure still functions allowing you to enter a static IP on a PC to troubleshoot problems.  If your critical infrastructure is on DHCP too, then if a DHCP server fails you have zero access to the LAN.

I strongly urge Cisco to not do this.  Static IPs that do not conflict and that are on the current subnet should NEVER be modified without direct administrator intervention and explicit permission.

Brian

[afullfor]

What actually happens is that the system offers you the option of upgrading the firmware with a factory reset for any WAP4410N it is found on the IP 192.168.1.245.  This is certainly not an automatic operation or we'd be potentially reconfiguring working equipment.  The intent is to handle just the initial installation of these devices when they are on the delivery load.  In this case a factory reset is simply changing the factory state of the down-rev firmware to the factory state of the current firmware, where DHCP is the default.

The firmware+factory reset is offered only for WAP4410N when it is on 192.168.1.245 with down-rev firmware.  This makes installation of these devices into a 192.168.1.0/24 LAN a little easier because it handles the firmware upgrade and allows dealing with multiple units with relative ease.  The installation on any other LAN configuration is much easier because you don't have to reconfigure a laptop to join 192.168.1.0/24 just to get access to the WAP4410N.

For WAP4410Ns already deployed in a 192.168.1.0/24 LAN that have been left on their default static IP, you can simply upgrade them manually, avoid any need for a factory reset, and still get the other benefits of TB management like monitoring, backup, restore, and future firmware upgrades.

[Brian Bergin]

Understood.  One of our test sites is on 192.168.0.0/24 (not our choice) so I'll see how it handles it and report back if anything happens that would impact normal use.

[aaronbooker]

I have to say - that we prefer a standard (whatever you choose - stick with it) - but we encourage our clients not to use 192.168.x.x because then they tend to have issues connecting to their office from home via VPN.

Sounds to me from the product guys - that the trial has a plan - sounds pretty workable to me.

Thanks for making this trial available to us.

Aaron

[Brian Bergin]

Agreed.  Pick a standard and stick with it.  Perhaps 192.168.1.0/24 for business products and 192.168.2.0/24 for Linksys consumer products.  Also, every device should come out in DHCP mode, meaning if a DHCP server is available ask for an address, if not have a "fall back" static IP.  That way you don't have to mess with a local PC when the device to be used doesn't come on a "friendly" IP (and you avoid stepping on an existing device too).

[dcorley]

A note on "platform" implementation so there's some context behind out-of-synch defaults with "SMB" products. Not an excuse, just an explanation as a base to let you know from where we're (SBTG) proceeding to lend sanity to device addressing and other defaults.

Even now, Cisco sells almost any product into SMB/commercial markets. If an SMB wants a GSR router or a UCS blade server, account teams will find a way to sell it through appropriate channels. To lend some sanity to the product development process for small business, Cisco created the Small Bus Tech Group (SBTG) about eighteen months ago. It focuses on 1-100 user small business networking and communication products. The creation of this group was a mashing together of three existing (at the time) small business product categories - those built by Cisco's Access Routing Technoliogy Group (a couple routers, the UC5XX, a switch or two, a wireless AP or two, and a security apliance or two. The second source of products was the former Linksys small business team (COBO) with a product portfolio of about 250 small business SKUs built using multiple ODMs to design and manufactire hardware and software. These Linksys products included routers, switches, surveillance cameras, net attached storage, wireless NIC cards, the Linksys SPA IP-PBX, SPA phones, security appliances and several products with multiple technologies mashed into one physical package. The third source of SBTG products was (and is) Cisco "classic" products - such as IADs like the 18XX series. These three internal groups products were supplemented by other groups' products ... notably the CP-79XX series IP phones. Development of these platforms has not been from a uniform source or process. Part of the reason for the formation of SBTG was to unify the product strategy as well as the development process to ultimately provide a consistent user experience. While a significant challenge, that consistency of user experience across all of SBTG platforms is the objective. As you can imagine, we'll not be able to fully address applying this consistency to "legacy" products. And the process for unifyig the UE consistency is a bit like herding cats. Among the first things we're tackling, as Marc described above, is a consistent advertisement/discovery implementation across future products.Within this first project, consistency of IP addressing schemes is being addressed.

There's only so much of this elephant that we can eat... we'll not be able to create, nor do you want us to spend time crating a unified user experience across all Cisco products. ASA55XX, a non-SBTG product, comes to mind as one of these, although we understand the argument about its utility in the small business space. We'll herd brown cats (SBTG's products) first,...then look to what it takes to herd others relevant to the SB market.

With your help and patience, we'll get there on platform user experience consistency. In parallel, projects like Thunderbolt are intended to provide a solutions management tool such that the eventual combination of consistent platform UE and solution automation yield partners like yourselves a better and more predictable business model.

Dave

[Brian Bergin]

I completely understand which is why they were really just comments, thinking out loud.  What Cisco really needs to do is cut about 90% of its Small Biz products out & get more competitive on pricing.  Too many SKUs in the market place confuse VARs and end users and when one can buy a 48 port managed gigabit switch from Dell for <$500 and a similar product from Cisco is more than double that it's hard to land that sale.  Thunderbolt will help a lot, but I'm not sure I can convince my customers that a TBA monitoring their LAN is justification for 2x pricing.  We rely 99% on Cisco firewalls/routers for SMBs, but on other fronts, Cisco has a lot to learn about the SMB market.

[Marc Bresniker]

Hi Brian, very valid feedback. We need to get consistency in our product platforms when in comes to portfolio default attributes. A project like Thunderbolt is providing us an opportunity to work with the platform teams to modify the default configs, behaviors, settings, etc. so we can implement a common discovery, management, and reporting methodology without each platform requiring a unique approach. It is not there today.

Our team in Cisco is driving this platform level set of requirements and we can point to the objectives and experience in Thunderbolt as the incentive. Convincing a product manager to add features to a platform for the common good of a portfolio is not an easy thing, but I think seeing the end result in something like Thunderbolt will make that a more successful endeavor.

As we progress in the Trial and being to implement partner feedback, we will come back to this team to validate the approach.

-Marc