Voice Engineers Will Rule the SDN World

Voice Engineers take a lot of crap.

 

There’s definitely a hierarchy to the world of network engineers and sometimes it looks a little like the following

 

NewImage

 

As a former Voice Engineer, I’ve definitely been the victim of this good natured jockeying for positioning. As a former voice engineer, I have to admit that I’ve even participated in the ribbing of my former voice peers.  Being a voice engineer is kinda like being the Rodney Dangerfield of the networking world.  ( You know the tag line )

I’ve even been told on more than one occasion that my CCIE “doesn’t count” because I did Voice. I’ve always taken it as the joke it is. I’ve got digits just like everyone else who’s ever passed a lab. But some people out there might not have the same thick skin I’ve developed over the years. ( Thick skin is something else Voice Engineers get. I think it’s all the exposure to end-users ). 

For the record, I have the upmost respect for voice engineers. It is one of the toughest gigs in networking. You have to have skills in so many areas, not to mention the constant human interaction that comes with the job. And we all know that not every network engineer handles constant human interaction well.

I spent some great twitter conversations reminiscing about the past and I realized that it just might be that voice engineers might just be the most well positioned to really make things happen in the new world. I think if we look at any past experience, there are skills which are transferable if you just look at them in the right way.  

There’s a lot of network engineers of all stripes and colours out there who are busy asking themselves the questions “ How do I make myself relevant in the new SDN world?”.   I think the first part of answering this question is to identify which of your current skills are transferable. Once you’ve got that figured out, you identify what’s missing and then hit the books. 

So here’s the list of why I think Voice engineers will have a great shot of making themselves quickly indispensable in the new world order.

Why Voice Engineer will rule the world

Experience with Controller-Based Networking

When explaining the concept of controller based networking, people always jump to the obvious analogy of wireless controllers with FIT APs. But it occurred to me last night that a potentially better example is the voice PBX.  Especially in a world where VMWare’s NSX is quickly becoming part of the conversation, the parallels become even stronger.  Voice is the original overlay.

Voice has it’s own addressing scheme (E.164) independent of the underlay infrastructure. There’s a centralized controller ( Callmanager ) who has completely knowledge of the state of every endpoint ( phone ) in the network.  As voice engineers, we’re so used to looking at symptoms of a problem with no direct linkages between the overlay and the underlay other than our knowledge. I believe this experience is going to come in very handy for those of us who chose to make the jump.

System-Level Thinking

Voice Engineers think in terms of the entire PBX as a system. There’s something just different about the approach of voice engineers as opposed to traditional R&S engineers. R&S guys have a great ability to focus in on the individual device they are working on. The are so used to living in a distributed state system that they can comfortably skip into the shoes of any device on the network and quickly analyze that particular devices perspective. As a voice engineer, having the ability to see things from the perspective of one particular voice gateway and analyze dial-patters is important, but been able to understand the entire system is what makes us fundamentally different. 

Operating System Skills

I have no idea how this happens. But I’ve actually seen REALLY good network guys who actually struggled to statically define an IP address on a Windows box. As a network management advocate now, I’ve seen the feet that a GUI can place in the eyes of a packet head one to many times to dismiss how valuable all the exposure to operating systems was. As a voice engineer, I had to work with Windows NT4 ( Callmanager 2.4 ), Windows 2000 ( Callmanager 3+), Linux ( Callmanager 5+), VXWORKS (3Com NBX), Linux ( 3Com VCX), not to mention all the client machines that I had to install the original Cisco Softphone ( oh! the pain!) the IP Communicator, or any of the other soft phone clients that have come along the ways. 

I’m comfortable on OS’s. And when I’m asked to install the HP VAN SDN on Ubuntu, or want to play with the OpenDayLight or NOX or Floodlight or any other controller out there right now. I’m not intimidated in the least. I wouldn’t call myself a Linux expert, but I’ll jump right in and figure it out. 

Programming skills

 

The CCIE Voice is one of the only ( THE only?) Lab which has ever forced candidates to do java programming. For those of you who’ve never done it, ACD programming in an IPCC environment is based on java beans. Digit translations are based on RegEx. And trouble shooting complex number translations through an entire dial patter with AAR turned on will force you into a boolean mindset whether you actually understand that term or not. 

 

People Skills

Voice Engineers have to interact with people. A lot. In fact we probably have to interact with people more than any other sub-genre in the networking profession. We have to learn various IT dialects to communicate with the legacy voice people. The hard-core network people. The “real” programmers who are going to do the complex ACD scripts for us. Not to mention the actual end-users who are experiencing difficulties with one-way audio or making a fax go through. ( Yes – People still use fax machines ). 

Strong communications skills and the ability to quickly shift vocabulary to effectively communicate between the different stockholders in an SDN environment is going to probably be one of the most important skills as the silos start to break down.

 

Strong Networking Skills

As much as people like to make fun of voice engineers, most of them have an unbelievable level of foundational networking. They may not be the strongest in BGP or MPLS, but in my experience they understand the basics of networking at a level that most of the other sub-genre’s don’t get to. You don’t ever want to get into an argument about QoS with a voice engineer. We understand spanning-tree like nobodies business. In fact, because of the complete lack of tolerance of RTP for any packet loss or delay, we have had to become really, really good at performance tuning the network to ensure that every packet arrives in order in less than 150ms ( G.114 standard people!). 

 

Wrapping it up

To be honest, I believe every network person who wants to is going to make it into the new world. I think that we spend so much time talking about whether or not that SDN is going to force people to become programers that we haven’t spent enough identifying what skills we already have that are going to serve us in the new world.

 

Do you believe that one of the other network sub-professions above are better equipped to move into the SDN world?  I challenge you to write the blog and make a better case. 

 

Comments, as always, encouraged and welcome!

 

@netmanchris

Advertisements

Things I learned as a voice engineer

 I have something to admit. I’m a recovering Voice Engineer. It’s been almost 10 years since my last installation. I occasionally experiment in the privacy of my home. But I’ve mostly broken the habit. It’s actually been so long that most of the people I work with have no idea that my CCIE is actually in Voice. I was actually one of the first 50 or so in the world which means I’ve been out of that world longer than most people have been in it. I try to stay current, but to be honest, my passion has moved to other things. 

 

For someone reason, Voice Engineers are viewed as the bottom feeders of the networking world. But I never seem to be surprised that some of the best networking people I know seem to have a solid voice background. Just to call out a few of the twitter personalities 

 

@networkingnerd – Yup. Tom used to be a voice engineer.

@amyengineer – Uh huh. Her too. She slips occasionally, but she’s getting better.

@treylayton  – CTO over at that little VCE company?  Before vBlocks and Netapp. He was one too.

and then tonight I just found out

@colinmcnamara has a great voice background from the early days as well. Yup. The DevOps/OpenStack/automation guy? He’s one too.

 

I’m not talking about the kind of voice engineers that we see today. One who reads one of the many Cisco Press purple books which are available. ( in my day they were teal darn it! ) Logs into a website which automatically puts together a complete Cisco Communication Manager Express ( #hursttoevenwritethat ) configuration based on your input into a webpage. People who think that SIP has always been here and that H.323 is a “legacy protocol”. 

I spent some time reminiscing about AS5300s, MCS 3800s, MGCP inconsistencies, importing hundreds of MAC addresses with a Bar code reader and various other shenanigans that we had to do at that point of the industry.   To be honest, it feels so good to know that we will never. ever. ever. have to do any of those things again.

But there were also some really great lessons I learned from that point in my career.

 

Be nice to everyone

I’m lucky that I’m Canadian and had my parents and country to thank for teaching me good manners. Unfortunately, I’ve seen this go very very wrong when I was paired with a sales person who didn’t have the same upbringing I did.

Situation:  We walk into a potential customer. He’s immediately rude to the receptionist and tells ( not asks ) here to let the CIO know we’re here and to go get him a coffee. Not even a please. I don’t think he called her honey or sweetie, but it was definitely implied. I was speechless and young enough to not step up and defend her. 

So the sale goes on. We get the buy in of the CIO, the CFO, the accountants ( they eventually became known as the IT department ), and basically nailed the sale. We had everyone’s buy in and the sale guy was looking forward to a big commission check.  Then we were marched back to the front of the office and sat down in front of the receptionist that he had offended from the moment he walked in the office.  She was shown the receptionist station phone and asked what she thought.  Anyone want to guess at how this turned out?

This just reinforced what mom and dad taught me. Be nice to everyone. It’s important. You never know when a lack of manners is going to come back to haunt you.

 

It’s all about getting from point A to point B. The rest is just details. 

 

For anyone who lived through the early days of Voice, you will all remember the media frenzy of the time telling everyone that the network team was going to absorb the comms team and that all the legacy voice people were going to lose their jobs. In fact, Cisco at the time was using the headcount reduction as one of the selling features.  This setup for a huge war between the Voice and Networking teams. Never a good thing. The legacy comms teams were afraid of this new technology. They didn’t understand what IP, TCP, CME, CCM, SRST, H.323, SIP, etc… meant. And they didn’t even know where to start.

There was one particular account where I was dropped into and all of the information sat in the head of the legacy comms guy who was running a multi-site Nortel network with some Option 11s and various norstars ( nortel key switch ) in a fairly complicated voice network. I was the 3rd or 4th person to get dropped in and I was warned about him. He was feeling threatened and had been intentionally difficult.  And rightly so. He was told that we were coming in to replace him and he had no path forward. 

I remember sitting down with Dave and I spent about 2 hours with him explaining routing in voice engineer terms. Routing in terms of dial plans, etc…  At the end of it he just looked at me and  shook his head and laughed.  Then he looked up and said “ That’s it?”

Apparently, the guys before me had never taken the time to explain any of what we were doing in terms that he could understand. Turns out the guy is a routing genius and understand the route summarization, advanced routing concepts, ACLs, and much much more. He was actually running a complicated voice network spanning 6 separate LATAs and doing Tail-End-Hop-Off ( TEHO ) while dealing with non-contiguous NSX codes.  

The network ops teams came to me a couple of days later and wanted to know what kind of magic I had pulled with Dave because they had never seen him more cooperative or helpful. Plus, he suddenly was a lot more interested in what they were doing and seemed to have gained 10 years of network knowledge overnight.

This project taught me that when you have a good conceptual model and you really understand it. The rest is just implementation details.  

 

Just because it’s a standard, doesn’t mean it’s a standard.

SOOOOOO many examples of this, but I think the first time I learned this was when SIP first came out. Wow. What a mess. Now we see non-standard implementations of protocols all the time. It’s sad that we’ve gotten to the point where we don’t even have outrage over it anymore. This brings me to the next lesson.

 

Trust but verify.

I worked a customer where we had ordered 2 PRIs ( ISDN Primary Rate interfaces ) for Voice service. We were clear that we HAD to have CallerID as part of the bundle. We received the sheet from the vendor ( Telco who doesn’t exist anymore ) who was actually subleasing the lines from another Telco.  It had all the regular line information on there. Protocol DMS 100, etc… So we spun up the line and we didn’t have CallerID.   Long Story short, the customer didn’t pay their bill for almost 2 years because the Telco could never get CallerID to work and every time we started getting somewhere, the account team changed and we had to start over from zero. 

One night during an outage window, just for giggles, we changed the protocol on our end from DMS 100 to NI1 or NI2. For those of you who don’t know, they are all pretty similar as ISDN protocols and the one thing which I remember is that the place where the incoming CallerID was stored was different among the three implementations.  The customer didn’t say a word to the vendor until for another few months. 🙂  

 

The application is what’s important. 

The most important thing I learned as a voice engineer is that the application is what’s important. Or more accurately, the value that the business derives from the application. In those days, if you said Callmanager had a minimum of features, it would have been an understatement.  I remember Lucent ( now Avaya ) competing against us with the “ We have 250+ features! You might need them! You’ll want to make sure that you have them!”.  The response was usually “Name 10 of those features”.   I’ve never had a customer get past 6 or 7.  Funny enough, I know see network vendors doing the same thing. 

All that really matters is If the product you’re pitching has the right features and you can align the to what the business is doing or wants to be doing.

 

 

Funny enough. I find myself having a lot of the same conversations know as our industry does another paradigm shift into the world of SDN, APIs, and Orchestration. Hopefully, I learned the lessons well enough the first time to not repeat them this time around. 

 

To all my other crusty old voice guys. Thanks for all the lessons you taught me. 

Cisco Phones on HP Comware Switches

I ran into this again last week and I thought it might be a good idea to put this in writing for people who have made the choice to move to HP switches and still want to use the Cisco UC&C platform.  This is the HP Comware platforms configuration, I hope to hit the lab and write up a ProVision configuration as well in the near future. This is ONE way of doing this. For anyone considering implementing this, or any other technology, please read the documentation and try and understand what you’re typing in. There are a couple of different ways to get this to work, this is just the one I prefer as it’s easy for legacy Cisco folk to understand what’s been done in the configuration.

 

Debunking the Myths

Cisco Phones need Cisco PoE

It’s true that Cisco was the first vendor to release Power Over Ethernet Switches. Inline power ( as it was called in those days ) was first released on the Cisco 3500XL switches back in the day. This was different and proprietary version of the 802.3af standard that we all know and love today. Fortunately for Cisco, and unfortunately for many customers, the second generation of Cisco Phones, the 7940/7960 era was only powered by Cisco’s Inline Power standard. They just wouldn’t come up with standards-based 802.3af power.

This means that many customers had no choice but to buy the Cisco switches to support the Cisco phones. You always had the option of buying a power brick per phone at a cost of about 60$ a piece. Management nightmare. I only saw one customer ever do that. ( twitch twitch… twitch twitch… ok. I’m ok now )

There are a LOT of customers who still have those device in their environments, So the question becomes:

Can I still use HP switches if I have old Cisco phones? Cisco told me that my Cisco phones don’t work on HP switches.

The answer is: Yes. They will absolutely work!   HP has done the work to get older phones to work on both the Comware and ProVision devices. This blog is Comware focused, but I’ll try to get back with a ProVision configuration soon!

Configuring your HP Comware Switch to deliver PoE to Cisco Phones

On a Comware based switch, the commands you’ll need to use to get this working are the following at the global level

[HP_E5500EI]poe legacy enable pse 4

At the port level, you may also have to enable PoE on the port

[HP_E5500EI-GigabitEthernet1/0/1]poe enable 


Cisco Phones need CDP to work

Once upon a time, CDP was the only neighbour discovery protocol in town. Cisco needed a way to push the voice vlan to their pre-standard phones, and CDP became the easiest way for them to do this. Most other vendors at this time were using specific DHCP options in a standards based environment. Then along came LLDP and LLDP-MED.  Other than the isolated cases where the customer still has the original second generation Cisco Phones in place, there is virtually no reason to be using CDP for the voice vlan today. LLDP works great and is supported by all the leading telephony vendors, including Cisco phones since around 2007. (You might need newer firmware on your phones.)

So the question is:

How do I setup my HP switch to send the right voice vlan to my cisco phone using LLDP? And what about my older phones? Are you telling me I have to buy all new phones to move to HP?

The answer: Yes, we can use lldp, and No, you don’t have to buy new phones. 

Especially in an era of Microsoft Lync, I’m starting to see more and more customers with a mobile work force who are starting to abandon the traditional handset mentality. Or in some cases, it’s even better for the business because employees are actually bringing in their own mobile devices and installing the Microsoft Lync client. Who would have thought we would ever be happy having to buy our own phones for work? 🙂

So on to the configuration, I’m going to do two configurations here and it will quickly become clear why.  For older Cisco CDP phones, HP Comware switches use the MAC Address  OUI (object unique identifier ) which is basically the first half of the MAC address that is assigned to a specific vendor.  What this means is that for some Cisco environments who have been buying phones over a few years, you could end up having to manage a TON of MAC addresses OUIs in your switch configurations. The first example will be the quick way, although arguably slightly less insecure, to assign Voice VLANs to legacy Cisco Phones.  Although arguably, if you’re concerned about security in your environment, I would recommend that you replace all your legacy Cisco phones anyways considering the ( Legacy Cisco Phones allowed a packet capture on the PC port to capture Voice VLAN traffic as well.  ) 

For those who really want to do this the “right way”, you’ll still need to run the undo commands and replace the single voice clan mac-address statement in this configuration snippet with the 128 lines included at the end of this blog. ( Anyone know why Cisco burned through so many? Seriously? That’s a LOT of OUIs! I’m SURE they could have handled this with a lot less!). 

 VLAN leaking issues.

The Environment

 

Screen Shot 2012 10 31 at 12 16 02 AM

As you can see this is a pretty simple environment. CCM in VLAN10 connected to a HP 5500EI switch. The phone is directly connected to the switch on interface gigabit 1/0/5 and the PC is plugged into the phone.  The Phone should be sending all Voice traffic tagged on VLAN 20 and the PC should be sending all traffic untagged on VLAN 30.

Any questions?

 

Configuring your HP Comware Switch to deliver the Voice VLAN to Cisco Phones

The following commands are all performed at the global level.

  • #The following commands are used to disable the factory mac-address OUIs.
  • undo voice vlan mac-address 0001-e300-0000
  • undo voice vlan mac-address 0003-6b00-0000
  • undo voice vlan mac-address 0004-0d00-0000
  • undo voice vlan mac-address 0060-b900-0000
  • undo voice vlan mac-address 00d0-1e00-0000
  • undo voice vlan mac-address 00e0-7500-0000
  • undo voice vlan mac-address 00e0-bb00-0000
  • #These command creates a couple of  mac-oui’s which will respond to any LLDP-MED or CDP capable phone plugs into the network. 
  • voice vlan mac-address 0000-0000-0000 mask ff00-0000-0000
  • voice vlan mac-address 8000-0000-0000 mask ff00-0000-0000
  • undo voice vlan security enable

 

note: We need the large “any oui” wildcards to support the number of non-contiguous and broad range of Cisco Prefixes. 

  • # You must Globally enable LLDP
  • lldp enable
  • # You must enable LLDP for CDP Compliance mode
  • lldp compliance cdp

 

As you can see above, instead of having hundreds of voice vlan mac-address… with all of the Cisco OUI  ( scroll to the bottom for a list of the different Cisco specific mac-address OUIs that my peers and I have collected over the years ),  you can instead put in a single statement that will allow you to send out the voice VLAN when any Cisco phone plugs into the network.

Now for the interface specific commands

 

  • interface GigabitEthernet1/0/5
  • port link-mode bridge    <–  Switchport, Could be a routed port, but that won’t work here.
  • port link-type trunk    <–  Turns the port into a dot1q trunk. You need this to carry a tagged VLAN across the wire
  • port trunk pvid vlan 30    <–  Tells the port that it’s untagged VLAN is 30.
  • undo port trunk permit vlan 1    <– Removes VLAN 1  from the trunk port. Not necessary for this to work.
  • port trunk permit vlan 20 30    <– Allows the trunk to carry traffic from both the designated Voice and the Data VLANs.  
  • undo voice vlan mode auto   <– Turns off voice clan auto mode. 
  • voice vlan 20 enable       <– Tells the switch to advertise dot1q VLAN 20 as the Voice VLAN via LLDP-MED and CDP on this port.
  • broadcast-suppression pps 3000
  • undo jumboframe enable
  • apply poe-profile index 1   <– This calls to a centrally defined PoE profile.
  • stp edged-port enable   <– similar to port fast in Cisco terms.
  • lldp compliance admin-status cdp txrx    <– Allows read/write of CDPv2 packets on this port.

 

 

The Right Way vs. Reality

 

As most of you already know, the real world is messy. There are very often tradeoffs in the world, mostly in the way of time. The method I showed above does indeed work, and it removes the operation burden of having to keep track of Cisco’s unique mac-address OUIs. Is it the most secure method in the world? Probably not, but security is always a tradeoff between how difficult it is to implement and operate and how important it is to secure the information asset in question. 

 

Most phone calls just aren’t that important to be honest. 

 

But… for those of you who really insist on doing this the “right way”, I’ve included this non exhaustive list of the unique mac-address OUIs that Cisco has put on their phone models over the years. This is something that my peers and I have put together over the years and hopefully it might help someone out there.  If anyone does have additional Cisco Phone OUIs that are not included in this list. Please post them in the comments and I would be happy to update them here! 

 

Hopefully someone will find this helpful. If you do notice that something has changed and this configuration doesn’t work for you; Please feel free to drop me a line and let me know. I’ll be happy to update my blog. I’d rather be wrong and someone tell me than just thinking I’m right. : )

 

@netmanchris

 

List of Cisco Phone Mac-address OUIs

  • voice vlan mac-address 0002-B900-0000
  • voice vlan mac-address 0003-6B00-0000
  • voice vlan mac-address 0003-E300-0000
  • voice vlan mac-address 0005-3200-0000
  • voice vlan mac-address 0005-9A00-0000
  • voice vlan mac-address 0005-9B00-0000
  • voice vlan mac-address 0006-D700-0000
  • voice vlan mac-address 0007-0E00-0000
  • voice vlan mac-address 0007-5000-0000
  • voice vlan mac-address 0008-2100-0000
  • voice vlan mac-address 000B-5F00-0000
  • voice vlan mac-address 000B-BE00-0000
  • voice vlan mac-address 000B-BF00-0000
  • voice vlan mac-address 000c-ce00-0000
  • voice vlan mac-address 000D-2900-0000
  • voice vlan mac-address 000D-6500-0000
  • voice vlan mac-address 000D-BC00-0000
  • voice vlan mac-address 000D-ED00-0000
  • voice vlan mac-address 000E-3800-0000
  • voice vlan mac-address 000E-8400-0000
  • voice vlan mac-address 000E-D700-0000
  • voice vlan mac-address 000F-2300-0000
  • voice vlan mac-address 000F-3400-0000
  • voice vlan mac-address 000F-8F00-0000
  • voice vlan mac-address 0011-2000-0000
  • voice vlan mac-address 0011-2100-0000
  • voice vlan mac-address 0011-5C00-0000
  • voice vlan mac-address 0011-9300-0000
  • voice vlan mac-address 0011-BB00-0000
  • voice vlan mac-address 0012-0000-0000
  • voice vlan mac-address 0012-7F00-0000
  • voice vlan mac-address 0013-1900-0000
  • voice vlan mac-address 0013-1A00-0000
  • voice vlan mac-address 0013-7F00-0000
  • voice vlan mac-address 0013-8000-0000
  • voice vlan mac-address 0013-C300-0000
  • voice vlan mac-address 0013-C400-0000
  • voice vlan mac-address 0014-1C00-0000
  • voice vlan mac-address 0014-6900-0000
  • voice vlan mac-address 0014-6A00-0000
  • voice vlan mac-address 0014-A900-0000
  • voice vlan mac-address 0014-F200-0000
  • voice vlan mac-address 0015-6200-0000
  • voice vlan mac-address 0015-2B00-0000
  • voice vlan mac-address 0015-F900-0000
  • voice vlan mac-address 0015-FA00-0000
  • voice vlan mac-address 0016-4600-0000
  • voice vlan mac-address 0016-4700-0000
  • voice vlan mac-address 0016-C800-0000
  • voice vlan mac-address 0017-0E00-0000
  • voice vlan mac-address 0017-5900-0000
  • voice vlan mac-address 0017-5A00-0000
  • voice vlan mac-address 0017-9400-0000
  • voice vlan mac-address 0017-9500-0000
  • voice vlan mac-address 0017-E000-0000
  • voice vlan mac-address 0018-1800-0000
  • voice vlan mac-address 0018-1900-0000
  • voice vlan mac-address 0018-1D00-0000
  • voice vlan mac-address 0018-7300-0000
  • voice vlan mac-address 0018-B900-0000
  • voice vlan mac-address 0018-BA00-0000
  • voice vlan mac-address 0019-0600-0000
  • voice vlan mac-address 0019-2F00-0000
  • voice vlan mac-address 0019-3000-0000
  • voice vlan mac-address 0019-AA00-0000
  • voice vlan mac-address 0019-E700-0000
  • voice vlan mac-address 0019-E800-0000
  • voice vlan mac-address 001A-2F00-0000
  • voice vlan mac-address 001A-6D00-0000
  • voice vlan mac-address 001A-A100-0000
  • voice vlan mac-address 001A-A200-0000
  • voice vlan mac-address 001B-0C00-0000
  • voice vlan mac-address 001B-2A00-0000
  • voice vlan mac-address 001B-5300-0000
  • voice vlan mac-address 001B-5400-0000
  • voice vlan mac-address 001B-D400-0000
  • voice vlan mac-address 001B-D500-0000
  • voice vlan mac-address 001C-5800-0000
  • voice vlan mac-address 001D-4500-0000
  • voice vlan mac-address 001D-A200-0000
  • voice vlan mac-address 001E-1300-0000
  • voice vlan mac-address 001E-4A00-0000
  • voice vlan mac-address 001E-7A00-0000
  • voice vlan mac-address 001E-F700-0000
  • voice vlan mac-address 001F-6C00-0000
  • voice vlan mac-address 001F-9E00-0000
  • voice vlan mac-address 0021-1B00-0000
  • voice vlan mac-address 0021-5500-0000
  • voice vlan mac-address 0021-A000-0000
  • voice vlan mac-address 0022-5500-0000
  • voice vlan mac-address 0022-9000-0000
  • voice vlan mac-address 0023-0400-0000
  • voice vlan mac-address 0023-5E00-0000
  • voice vlan mac-address 0023-EB00-0000
  • voice vlan mac-address 0024-9700-0000
  • voice vlan mac-address 0025-8400-0000
  • voice vlan mac-address 0026-0B00-0000
  • voice vlan mac-address 0026-9900-0000
  • voice vlan mac-address 0026-CB00-0000
  • voice vlan mac-address 0030-9400-0000
  • voice vlan mac-address 04C5-A400-0000
  • voice vlan mac-address 04FE-7F00-0000
  • voice vlan mac-address 0817-3500-0000
  • voice vlan mac-address 081F-F300-0000
  • voice vlan mac-address 108C-CF00-0000
  • voice vlan mac-address 18EF-6300-0000
  • voice vlan mac-address 1C17-D300-0000
  • voice vlan mac-address 2893-FE00-0000
  • voice vlan mac-address 3037-A600-0000
  • voice vlan mac-address 5475-D000-0000
  • voice vlan mac-address 58BC-2700-0000
  • voice vlan mac-address 6416-8D00-0000
  • voice vlan mac-address 68BD-AB00-0000
  • voice vlan mac-address 68EF-BD00-0000
  • voice vlan mac-address 6C50-4D00-0000
  • voice vlan mac-address 9CAF-CA00-0000
  • voice vlan mac-address A40C-C300-0000
  • voice vlan mac-address A8B1-D400-0000
  • voice vlan mac-address B414-8900-0000
  • voice vlan mac-address B4A4-E300-0000
  • voice vlan mac-address B8BE-BF00-0000
  • voice vlan mac-address D057-4C00-0000
  • voice vlan mac-address DC7B-9400-0000
  • voice vlan mac-address E804-6200-0000
  • voice vlan mac-address EC44-7600-0000
  • voice vlan mac-address ECC8-8200-0000
  • voice vlan mac-address F025-7200-0000
  • voice vlan mac-address FCFB-FB00-0000