Network Topology\Setup

[MrPrince1979]

Hi,

I’m trying to install a UC320 in to an environment that already has key services already setup. I need the UC320 to handle VOIP/Analogue traffic only. Customer requirements are:

• UC320 is not to provide DNS/DHCP on any network.
  
• Customer already has multiple data VLANs and doesn’t want to use vlan 1.
  
• Customer already has a voice VLAN (ID 201) and doesn’t want to use VLAN 100, that vlan is doing something else.
  
• Customer wants sets connected to ports on their 3560 switches (for POE) in access mode (VLAN 201). PCs are not to be connected to the back of sets.
  

Essentially I’m looking to create a routed port on the UC320, LAN side only, that would use an IP in VLAN 201 with the right mask and GW that fits the customer’s existing switching/routing environment. E.G. the GW for VLAN 201 is virtual setup using HSRP.

Any advice with this kind of setup or possible workarounds? I’m not in a position to suggest that my customer redesign his network to fit this device.

Thanks very much for looking.

[nalbert]

Oliver,

This is a perfect customer for a UC540 install. I suggest you pull out the UC320 and put a UC540 in. The UC540 will do exactly what you want. The UC320 is for simple deployments, you may be trying to fit a square peg in a round hole.

[MrPrince1979]

I was hoping someone wasn't going to say that... :-( Is there anythign i might try to get the 320 to work?

Thanks.

[nickhesson]

is the understatement of the year.  Who uses VLAN 1 anymore?  We need away to change the VLAN ID's for DATA and Voice on these UC320's!  Did I miss something on Cisco's website or documentation?  Telling us we can NOT change the VLAN ID's for both vlans on these UC320s?

I get the UC320 is geared around SMALL business setup, but there is no way of knowing that from a mid-size business to stay away from these devices for your smallest remote offices.  For something as simple as setting VLAN ID's?

Please someone throw us a bone.

Thanks for your time and help,

Nick

[Christopher Edgeworth]

Hi Nick and Oliver,

Can you please help provide a use case when the customer REQUIRES the voice VLAN to be something other than VLAN 100 and a native VLAN other than 1 in an office with 24 or fewer phones?

In these deployments is the UC320W the only router in the network or are there other routers?

Thanks,

Chris

[danplacek]

Chris,

Just to clarify, it has always been my understanding that Cisco itself absolutely recommends against using VLAN 1 for security reasons.

Is that not the case? Or do you feel that that does not apply to small offices?

Thanks.

ex: http://www.cisco.com/warp/public/cc/pd/si/casi/ca6000/prodlit/vlnwp_wp.htm#wp39009

[nickhesson]

In my case we are using ASA 5510's at these sites as well to support VPNs.  It's best practice not to use VLAN 1, which we have security guidelines that state this.  But it's not a question as to WHY?  But as WHY NOT?  Its to easy to allow customers that know how, set the VLAN ID's for both Voice and Data.  Create a advance button, and let us go to town.  Because again, I can't think of any good reasons why Cisco would WANT to prevent the VLAN ID from changing. 

Nick

[David Harper]

I think it's worth remembering that the context where that security guideline is being applied is rather different to that of the customer at which the UC300 is targeted.  That particular guideline goes hand in hand with the recommendation that a separate VLAN be used for infrastructure management purposes and that this VLAN is protected from access by devices in the other VLAN(s).  The UC300 is targeted at customer who typically had a single flat network prior to the arrival of the UC300 and it is hard enough getting a voice VLAN created, let alone a management VLAN with restricted access.  As such, the use of VLANs 1 and 100 as a default minimises the amount of configuration required, in particular when using some of the older switches that also default to those VLAN IDs.

Now, this doesn't mean that you don't have a valid issue.  For whatever reason, some customers have been set up previously with different VLAN IDs and it would be easier if you could just change the VLAN ID on the UC300.  So it is a legitimate feature request.  But in terms of where it fits on the priority list, we have to focus on where we see the most frequent requests, and so far for me at least, this particular requirement is a relatively infrequent one.  Now I'm not part of the product team and don't control the roadmap, but based on what the partners I deal with are asking for, there are quite a few features that they would prefer to see before this one.  I'm confident that this will be added to the list of feature requirements - though if I am not mistaken, it is there already - but I doubt it will happen in the very near term.  As I said, there are a bunch of features we get a whole lot more requests for that will need to come first.

Now I realise that's probably not the answer you wanted to hear, and it's also possible that Chris may have a better one for you, but I thought it was important to try and address the question in a broader context.

Cheers,

Dave.

[nickhesson]

Thanks for the reply.  Without this turning into a back and forth conversation of what the purpose of a UC320 has in this world.  Here are my points:

• If Cisco believes that these units are being installed by non technical people, they are way off base.  Point is anyone that is purchasing these devices, know about vlans, and voice vlans for that matter.  Let's not kid ourselves, your not installing VoIP systems without the know how of vlans. 
• With the above statement being true, why prevent the customer from changing the VLAN ID's?  I don't know the actual percentage, but I'm sure over 80% of these units are being purchase with a POE switch.  Just adding to the statement above.  The party that is installing these units will know about the use of Vlans. 
• Let's just say that I'm full of what makes the grass grow green on the above statements.  Then Cisco should make this very clear in there pre-sales documentation.  That the VLAN ID's are 1 and 100 and can not be changed.  Give us engineers the information needed to purchase something else.
• Regardless as to a roadmap and list of feature requests for the UC320.  To make this change in the software would be easy to complete.

Again, above it all.  Why keep us from changing the VLAN ID's in the first place?

Again, thanks for the time and help,

Nick

[MrPrince1979]

In my opinion Cisco has slightly missed the mark with the 320 because of the term “Small Business”, pigeonholing it when it could make the design/appeal much broader and attractive to existing setups.

I look after a few small businesses, some are small due to their footprint, product portfolio or business plan, others are smaller simply because of staff size. The particular business I was installing the 320 in (see OP) was technical in nature and considered small because they have a smallish number of employees at that particular location, with under less than the 320 can handle. The pre-existing network at that firm is fairly complicated due to the type of work they are involved in. Virtualization, VLAN segmentation and security policies are tightly controlled. The 320 was due to go in simply to replace their aging analogue telephony setup.

I wasn’t expecting to bend & twist my customer’s network in order to accommodate one device. The 320 should be flexible enough to fit both new & existing installations. I understand that devices higher up the UC portfolio would have served better, but that starts to seriously diminish my client’s appetite due to rising costs especially since the more expensive models don’t offer anything more than my client originally wanted with/in the 320.

I now have that 320 in my lab back at work. After configuring it and messing around much more I can see how Cisco is trying to play this and I do think overall the 320 is a good device, it’s just that it seems to be missing some key elements to make it a great/killer device. I have some other issues too, but I’ll open a separate thread for those. Please don’t assume that small businesses simply use un-managed switches with the router their ISP gave them and that the 320 is goign to all things to all men.

On a final note flash isn’t great but thank God Cisco didn’t use Java. Better yet give us a CLI.

Cheers.

[Alberto Montilla]

Hi Oliver;

Thanks for your feedback. The UC320W can also support greyfield deployment. Have you read the Smartdesign for greyfield? It provides indications on it setup.

Regards
Alberto

[jkurkjianctg]

All:

I am little late on this post but I have read the guides Alberto mentions (as well as the SRND's for most of the full blown UC product line) and I agree with Nick & Oliver on all of their points100%. I am more than a bit frustrated at the inflexibility of the UC320.

Since Cisco put their logo and stamp of approval on this product yet goes against its own "best practices" recommendations on VLAN assignment by forcing data onto VLAN 1 is a real head scratcher - the list goes on & on but I won't rehash what has already been said.

Initally I thought the unit was a good idea but the more I see (or more importantly DON'T see) on it's capabilities, the less likely I would be to recommend this to ANY customer moving forward.

John

[Daniel Griego]

I agree, I already had my client set up with separate Vlans as I have made not using Vlan 1 a best practice for my network deployments. I was a little disappointed when one of my first planned configuration tasks was to move off of Vlan 1 and wasn't able to do it on the uc320w.

-Drgrieg

[Roman Rodichev]

This thread is funny.

[Jack Germanos]

This thread is gold! VLAN 1 lol

Sent from Cisco Technical Support iPhone App