Posts Tagged Hp
Every once in awhile someone reaches out to me wondering if the older HP Provision switch they have is OF capable or should they just through it in the garbage.
One of the easiest way to decide on blog post is “If you’ve been asked the same question more than three times…”.
EDIT: These switches can all run OpenFlow1.3. Table sizes vary per model. Check the release notes and product documentation for specifics around what of the optional OF1.3 spec is covered. (hint: None of these switches support MPLS )
Getting OpenFlow Code
So pretty much all of these switches have the HP warranty, which means you should be able to get code for all of them from the HP support website. Easiest way is to go to http://www.hp.com/networking/support and should be good to go. It may be that all of these switches are covered under the warranty, but I didn’t verify, so I’ll leave that you to. :)
So I was working on the new HP BYOD Solution in my lab and I just didn’t have enough wireless devices to really make it interesting. So I decided to look for other devices in my house which I could connect to the HPN BYOD Controlled MSM controller-based wireless networks.
I did find a Nintendo Wii, but we don’t have fingerprints in IMC to properly identify the Nintendo Wii. I guess Nintendo didn’t make the cut. ( They don’t even support WPA2 Enterprise!!! )
Anyways, the great thing about HP’s new BYOD solution, based on IMC and UAM, is the ability for operators to extend the default fingerprints to devices beyond what was shipped with the product. Although the process does require some knowledge of wireshark, it’s nothing that a little google-technician skills can’t get you through. The adding of fingerprints was super easy.
Creating the foundation
So before we actually get to creating the fingerprints, we need to create the custom vendor, endpoint type, and OS type that we’re going to assign to the DHCP and HTTP fingerprints we are going to create. If you’re doing this for a new smart phone, like the blackberry 10, you’ll probably be able to skip this step as RIM is already listed as a vendor. As you can imagine, Nintendo wasn’t
So let’s look at what the process looks like.
As you can imagine, there’s no default vendor category for Nintendo, so I’m going to go into the Service>>User Access Manager>> Endpoint Identification Management>>Vendor screen and add a new vendor
Add Endpoint Type
IMC ships with a bunch of endpoint types by default to cover all the normal devices you would see in a business environment. I don’t see that many Wii’s in offices these days though, so we’ll have to create this one too.
Add OS type
Again, No love for Nintendo in the OS department. Let’s add that too.
Creating the fingerprints
For those of you who don’t know, IMC uses digital fingerprints to be able to identify devices accessing the network. We use a combination of characteristics that are mostly unique to one specific type of device to be able to make an educated decision on the model, operating system, and type of the endpoint accessing the network. The three types of fingerprints we can use are
DHCP Fingerprint – In this option IMC uses the options requested in the DHCP client option 55 field to identify the device requesting an address. The specific sequence and number of options are considered to be unique to that specific operating system. ie. All Nintendo Wii machines should request the same values in the same order in the option 55 field of the DHCP request packet. This is considered to be the most reliable of the fingerprinting techniques.
HTTP User-Agent – In this option IMC uses the User-agent portion of the HTTP request headers sent to the BYOD web server to be able to identify the device requesting the webpage. As most browsers will identify themselves through the use of HTTP User-Agent, this is a still a good method for making an educated decision.
MAC Address – In this option IMC uses the MAC address, obtained through the RADIUS server, to identify the vendor based on the MAC address OUI. This is considered to be the weakest form of fingerprinting, but necessary as some devices do not use a unique DHCP signature, nor a web browser. An example of this might be an IP Telephone or Printer.
So let’s get started here and setup our first fingerprint.
Capture the DHCP fingerprint
This is where the nerdiness starts. I have a Windows Active Directory Server that is serving up addresses for the network that my Wii connects to. So I just installed wireshark on the domain controller and start capturing packets.
note: I use the filter bootp.option.type == 53 which will get allow me to see just the DHCP traffic. Cuts down on the packets I need to look through.
I turn on my Nintendo Wii and wait a few seconds for it to try and connect to the network
Now that I’ve got the packet, I need to look a little closer for the Option 55 information. INSERT SOME INFO ON OPTION 55 FROM WIKI
You can see in the packet capture above that the option 55 parameters list has a length of 6, and the values are 1,3,6,15,28, and 33.
Creating the DHCP Fingerprint
So now we go back to the IMC console and navigate to Service>>User Access Manager>> Endpoint Identification Management>> DHCP Character Identification Configuration
click the add button and input the values above
Now that we’ve got the DHCP Fingerprint, let’s go after the HTTP Fingerprint.
Capturing the HTTP User-Agent Fingerprint
This time, I”m running a packet trace from wireshark loaded on my IMC machine ( this is handy for a whole bunch of reasons) I use the Internet Channel on my Wii and attempt to login to the IMC server. Now I check Wireshark again, this time using HTTP as the filter. I could also add the filter for the specific host 10.101.0.116, but in this case it’s just as easy to resort by the source server and get to the right packet.
There it is… “Nintendo Wii”.
Now that I’ve got the HTTP User Agent Signature, I can now go back to IMC and add that in as well.
Creating the HTTP User-Agent Fingerprint
Putting it all together
So, we created the DHCP Character Identification as well as the HTTP User Agent Feature Identification. Now we’re going to connect the wii to the BYOD-enabled wireless network and see what the test this out and see what our work has gotten us.
Fingerprinting Successful. As you can see, the Nintendo Wii was identified by the DHCP client identifier and has been successfully registered in the endpoint MAC address management list in UAM.
The one step other step which I did skip here was adding a MAC address finger print to identify devices which would allow you to identify the device by it’s MAC address. To be honest, that doesn’t require a packet trace, so I skipped that step. What fun is something that doesn’t require a packet trace?
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
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!).
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.
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. : )
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
So we’ve had some ambitious little engineers with too much caffeine and some new toys to play with.
For those of you who are interested, I’m going to post the source over to
which is the new IMC forum site that @neelixx setup. This code was not created by a professional code, but at least it’s a proof of concept of what you can do with a little bit of time and some knowledge.
P.S. If you don’t have a QR code reader on your phone yet, and you didn’t just click on the image…. that’s www.netopscommunity.net
The DML is really nothing more than a software library. Ideally, this should be tied directly into your element management system so that you can define the baseline software image, deploy the image out to the appropriate devices, and audit the network to ensure that all of the devices are inline with your golden software definitions.
As I laid out in the last post, standardization is there to make your lives easier. But it takes a lot of commitment, especially if your network has gone through significant “organic growth”. Making the choice to commit to good configuration management hygene is sort of like committing to going to the gym or commiting to eat healthier.
Just like going to the gym, the first thing you need to do is figure out your current software state. Hopefully, your NMS software will have the ability to discover and audit the software running on the devices in your network and report against a known good state.
Audit the Current State of the Network
If you don’t have an NCCM tool in place with these features, you may end up writing scripts, or worse case, loging into your devices manually and noting the software version in an excel spreadsheet. Once you have a handle on what’s out there, the next step is chosing what version of code you need to be running.
Choosing your Software Version
So now that you’ve figured out that your devices are all over the place, it’s time to figure out what version of software you actually want to be running. Whether you are running Comware, IOS, NXOS, Junos, FTOS, or some other OS that I haven’t mentioned, the guidelines are pretty much the same.
Wash, Rinse and Repeat.
What about the exceptions?
I was going to try to sugar coat this, but I’ll just come out and say it. Cisco has licensing for many of their platforms, this can create situations where you can’t actually get on a common code version without incurring additional CAPEX costs associated with buying the licenses and OPEX to deal with the SMARTNet’. Or potentially, you can get into the situation where the features you’re looking for are mutually exclusive in two different IOS images for your routers. Or you’re running Cisco Callmanager and your gateways require the Voice image and your regular WAN routers another image.
In any event, my recommendation is still the same. Find the fewest possible combinations of software for the hardware platforms in your network and stick to them unless there is a REALLY good reason to change.
Check out this video of the basic NCCM features in HP’s Intelligent Management Center to help you navigate through your software baseline woes.
Anything I missed here? Feel free to post in the comments below.
WARNING – MIDNIGHT POST. I’ll come back and fix this in a couple of days, but it’s been banging around in my head and I needed to get it out.
So I’m going to get a little controversial here. I’m actually hoping to have my thought process attacked on this one. Hopefully, not personally attacked, but I guess that’s the danger of blogging.
Open Disclosure: I don’t work for Cisco. I guess that’s why I can write this piece and think this through as I’ve got nothing to lose here. I’m sure someone will point and say “Hey! HP GUY!” but I truly don’t feel that whom I work for is going to change the power of this argument. But because some people get wrapped around those things, I wanted to state that loud and clearly. I am an HP employee. This blog is purely my own thoughts and musings and i no way represents that of my employer in any way shape or form. :)
So I was at HP discover last week and had a chance to catch up with a TON of customers and partners, as well as have some great conversations with the independent bloggers. To be honest, those are my favorite, because they are the last people to drink the koolaid.If you are trying to convince them of anything, you better have a well constructed argument and proof to support it.
So the other topic on everyone’s minds was of course BYOD. Bring Your own Device. Other than Openflow and SDN, I think this is one of the most talked about waves that’s hitting our industry right now. Of course we had the usual discussions about access control, DHCP finger printing, user-agent finger printing, dot1x , web portal, etc… but we also got into some VERY interesting discussions about the greater implications of BYOD.
Now keep in mind, I’m an old voice guy too. My voice books are so old, they’re actually blue, and not that snazzy purple color that you kids use to color coordinate your bookshelves. I know what the SEP in the Callmanagler stands for, and I remember CCM when it shipped on CDs. ( yes, it actually did kids ).
So in some ways, I feel like I’m watching my past wash away when I type the following words.
Voice is dead.
Now it might be a few years before everyone realizes it, but there are a lot of forces going on in our industry right now and they seem to all be pointing to a place where handsets are obsolete.
The argument goes something like this
1) BYOD is here and it’s not going away.
2) If BYOD is here, then employees are probably teleworking and using their cel phones.
3) If customers are teleworking and using their cel phones, they don’t need desk phones.
4) If customers don’t need desk phones…. they don’t need desk phones.
The implications of this really started to hit me and I did a self check and realized, I don’t remember the last time I used a “normal” handset. I work out of a home office. I use a cel phone with unlimited calling.
Not to mention the fact that HP has hooked us up with Microsoft Lync, which means plugin the headset and escalate that IM call to voice or video whenever I need it. and NO handset involved. Oh.. and the Lync client for the iPhone was released too.
The last time I looked, this was an approx $1-2B business for Cisco, so I’m fairly sure they don’t want anyone to realize that investing in new handsets is probably not the wisest move right now. This is a Billion dollar market that they are going to have to replace with something else, or continue to milk it for as long as they can.
Now to be honest, there’s always the Call Center argument which I’ll try and stop right now. Call Centers are not going away. There’s always going to be a business need. Voicemail systems? They might just become part of the cloud, I don’t know. But traditional handset deployments? I think maybe people just haven’t realized they have been throwing money away.
On with the rambling midnight logic!
The extension to this logic is that if we’re done with handsets, then
why do we need all this POE everywhere?
To be honest, I think the only phone that every used anywhere close to the 15.4 watts of 802.3af was the Cisco 7970 series. Most other phones used 2-3 watts, maybe up to 7 with a speaker phone on. So the whole ” I need all 24 ports running full 802.3af class 3 devices at the same time ” is a something that never actually happened ( or at least I’ve never seen it ).
Now we’re seeing RFP disqualifiers requiring 740 watts per switch ( full 15 watts on all 48 ports ), and I’m sure we will soon be seeing new models coming out with 1,440 watts of POE+ power!!! ( 30 watts per port on a 48 port switch ).
Now POE is an enabling tool, we still need it for access points at the least, but other than that? I can’t name one practical business tool that runs on POE right now that would not qualify as a corner case.
And I don’t see anyone plugging in 24 or 48 access points into the same switch.
I would love a sanity check here guys. Is it just me? I’m making an informed prediction throw a crystal ball. Feel free to let me know if my ball’s broken. :)