Tuesday, August 5, 2008
Saturday, August 2, 2008
The Website is Down
I know that no one reads my blog, and those that might stumble upon this site probably already know what I'm talking about, but I just learned about a great video called The Website is Down
I give it 5 stars for making me, and my co-workers, laugh everytime we watch it.
Basically, the movie is IT helpdesk related. Just watch and enjoy...
I give it 5 stars for making me, and my co-workers, laugh everytime we watch it.
Basically, the movie is IT helpdesk related. Just watch and enjoy...
Cisco Wireless Guest Access
It has come to my attention that with my previous post about wired guest access, I might as well clarify a little about Cisco's wireless guest access.
Cisco's wireless controllers have the ability to "anchor" wlans to a specific controller. I'm think from a Route/Switch perspective there is some benefit to this when it comes to roaming users.
Anyhow, I personally think that by complete accident, Cisco discovered this anchoring feature could be used to provide guest access. After all, it is rather ingeneous. If you already have the ability to anchor a client to a specific controller, what happens when you anchor a client to a controller that is out in a DMZ? Secured guest access, thats what.
Basically, by anchoring a specific wlan to the DMZ controller, you've effectively locked your "guest" users out of your network why still using the trusted infrastructure.
The next step now is with wired guest access. As I mentioned in the previous post, you can create a "guest lan" and anchor it the dmz controller as well. It is the exact same concept, except the guest lan picks up traffic on a specific VLAN whereas wireless guest access picks up traffic from a specific wlan.
Cisco's wireless controllers have the ability to "anchor" wlans to a specific controller. I'm think from a Route/Switch perspective there is some benefit to this when it comes to roaming users.
Anyhow, I personally think that by complete accident, Cisco discovered this anchoring feature could be used to provide guest access. After all, it is rather ingeneous. If you already have the ability to anchor a client to a specific controller, what happens when you anchor a client to a controller that is out in a DMZ? Secured guest access, thats what.
Basically, by anchoring a specific wlan to the DMZ controller, you've effectively locked your "guest" users out of your network why still using the trusted infrastructure.
The next step now is with wired guest access. As I mentioned in the previous post, you can create a "guest lan" and anchor it the dmz controller as well. It is the exact same concept, except the guest lan picks up traffic on a specific VLAN whereas wireless guest access picks up traffic from a specific wlan.
Cisco Wireless - Guest Access from different controller versions
Below you will find a proposed design on how to use Guest Access on Cisco Wireless Controllers with different software revisions.
Why might you have different controllers on different software? The answer is quite simple, Cisco doesn't support the 1000 series access points in 5.x and the mesh features have thier own code right now only in 4.1.
When using wireless guest access based on Anchoring to a DMZ controller, all controllers need to be in the same software version and revision (4.1, 4.2, etc..).
So, if you wanted to take advantage of different features in 5.x, you would either need a different DMZ controller for anchoring or you would have to come up with some other method to anchor your old controller software to the new one.
Version 5.x has this fantastic feature where you can do the Guest Access over a wired connection. Check out this document from Cisco about sample confguration if interested. Anyhow, this feature basically allows you to configure a controller in 5.x code to take traffic on a Layer 2 vlan and anchor it to a controller. This is basically just how wireless guest access works.
So here is what I think would work great:
All of the 1000 series access points and mesh access points can be on a controller with the mesh code (4.1.XXX). The other internal controller and the dmz controller can be upgraded to 5.X.
With this done, you should be able to simply break the anchor to the dmz from the mesh controller and dump the traffic out onto a specified vlan.
In theory, the 5.X controller would be anchoring that vlan to the DMZ and there you have it.
Now you've got wireless access as usual from all controllers, but your guest access on the mesh controller anchors to the internal controller (as a wired connection) and is then picked up and sent to the DMZ.
This all sounds good to me. Any thoughts?
Why might you have different controllers on different software? The answer is quite simple, Cisco doesn't support the 1000 series access points in 5.x and the mesh features have thier own code right now only in 4.1.
When using wireless guest access based on Anchoring to a DMZ controller, all controllers need to be in the same software version and revision (4.1, 4.2, etc..).
So, if you wanted to take advantage of different features in 5.x, you would either need a different DMZ controller for anchoring or you would have to come up with some other method to anchor your old controller software to the new one.
Version 5.x has this fantastic feature where you can do the Guest Access over a wired connection. Check out this document from Cisco about sample confguration if interested. Anyhow, this feature basically allows you to configure a controller in 5.x code to take traffic on a Layer 2 vlan and anchor it to a controller. This is basically just how wireless guest access works.
So here is what I think would work great:
All of the 1000 series access points and mesh access points can be on a controller with the mesh code (4.1.XXX). The other internal controller and the dmz controller can be upgraded to 5.X.
With this done, you should be able to simply break the anchor to the dmz from the mesh controller and dump the traffic out onto a specified vlan.
In theory, the 5.X controller would be anchoring that vlan to the DMZ and there you have it.
Now you've got wireless access as usual from all controllers, but your guest access on the mesh controller anchors to the internal controller (as a wired connection) and is then picked up and sent to the DMZ.
This all sounds good to me. Any thoughts?
Wednesday, July 9, 2008
1522 Mesh - Using the ethernet port - FIXED
When I got my 1522 to finally associate to the 1242 that I converted into Enterprise Wireless Mesh, I was no longer able to use the Ethernet port for network access. Basically, the device knew it was a Mesh AP and not a Root AP and apparently turned its network port off...
Long story short, the fix was actually more simple than I expected.
By taking down the 1242 Mesh, my 1522 no longer had a Mesh path to the network. After rebooting the 1522 with the 1242 down, the network port finally came active as the 1522 searched for the network. Of course there was no network path back to the controller so the AP really didn't do anything.
Anyhow, after turning my 1242 back on (and several reboots later) the 1522 finally registered back to the Enterprise Mesh Network with a functional network port for bridging.
Upon further research, I learned where I went wrong:
The recommended installation for a 1522 is to always attach it to the network to find the controller first. Once attached to the network, the 1522 then can be converted to MeshAP (instead of RootAP) and will attempt to associate to another Mesh AP. By doing this, the MeshAP 1522 keeps the network port active and therefor the system never thinks it needs to disable the port.
Long story short, the fix was actually more simple than I expected.
By taking down the 1242 Mesh, my 1522 no longer had a Mesh path to the network. After rebooting the 1522 with the 1242 down, the network port finally came active as the 1522 searched for the network. Of course there was no network path back to the controller so the AP really didn't do anything.
Anyhow, after turning my 1242 back on (and several reboots later) the 1522 finally registered back to the Enterprise Mesh Network with a functional network port for bridging.
Upon further research, I learned where I went wrong:
The recommended installation for a 1522 is to always attach it to the network to find the controller first. Once attached to the network, the 1522 then can be converted to MeshAP (instead of RootAP) and will attempt to associate to another Mesh AP. By doing this, the MeshAP 1522 keeps the network port active and therefor the system never thinks it needs to disable the port.
Monday, June 30, 2008
Cisco Enterprise Wireless Mesh
So I finally tested out the "Enterprise Wireless Mesh" by converting a 1242 into a Mesh Access Point. It wasn't too difficult but there were a few catches:
For starters, you obviously must have a 1242 registered to a controller that supports enterprise mesh. Currently 4.1.192.22M (Mesh)is the recomended version.
After the AP is registered, make note of both MAC Addresses, which is obtained from the details of the registered AP.
By changing the AP mode to Bridge, the AP will reboot with the Mesh code.
And there you have it, a Mesh 1242....
But not so fast. If you have any experience with the outdoor Mesh AP's, you know you have to add the mac address to the mac-filter on the controllers (Security > AAA > Mac filtering). You need to do this with the 1242 else the mesh AP, even though it is wired, will not associate with the controller. Specifically, you need to add the Base Radio Mac.
There you go, AP should register again and be able to support other MESH access points.
I had a few problems getting a 1522 to register, but I didn't change anything. It just started working about the time I had finally given up hope.
Now I have an issue using the 1522 Power Injector network in port as a link to a remote client. More on this when I fix it.
For starters, you obviously must have a 1242 registered to a controller that supports enterprise mesh. Currently 4.1.192.22M (Mesh)is the recomended version.
After the AP is registered, make note of both MAC Addresses, which is obtained from the details of the registered AP.
By changing the AP mode to Bridge, the AP will reboot with the Mesh code.
And there you have it, a Mesh 1242....
But not so fast. If you have any experience with the outdoor Mesh AP's, you know you have to add the mac address to the mac-filter on the controllers (Security > AAA > Mac filtering). You need to do this with the 1242 else the mesh AP, even though it is wired, will not associate with the controller. Specifically, you need to add the Base Radio Mac.
There you go, AP should register again and be able to support other MESH access points.
I had a few problems getting a 1522 to register, but I didn't change anything. It just started working about the time I had finally given up hope.
Now I have an issue using the 1522 Power Injector network in port as a link to a remote client. More on this when I fix it.
Thursday, June 26, 2008
"CCNA Security/Voice/Wireless"
Cisco has finally created
Three new associate tracks
CCNA Security and Voice
Also the Wireless Cisco lacks
The best thing about this Cert
Is only the one exam to take
So specialize your career
A new title you can make
To get the Professional level
After getting the new CCNA
You still have up to 5 more exams
But these will pave the way
If it is Wireless you pursue
There may soon be a CCWP
And rumor even has it
Of a Wireless CCIE
Three new associate tracks
CCNA Security and Voice
Also the Wireless Cisco lacks
The best thing about this Cert
Is only the one exam to take
So specialize your career
A new title you can make
To get the Professional level
After getting the new CCNA
You still have up to 5 more exams
But these will pave the way
If it is Wireless you pursue
There may soon be a CCWP
And rumor even has it
Of a Wireless CCIE
Wednesday, June 25, 2008
Unofficially Confirmed - Wireless CCIE
So I've been doing some research relating to the CCNA Wireless and I stumbled on this article at Internetwork Expert - CCIE Blog.
They go on to say:
"After speaking with multiple Cisco employees within the wireless group, the Wireless CCIE has been confirmed. Beta candidate registration should begin this fall, along with a blueprint release. Beginning early 2009 the Wireless CCIE beta testing will begin! As of now, topics of the test are expected to cover all aspects of wireless from design through implementation including the implications of security, routing and switching and voice technologies. Check back often for any additional information!"
So there you have it. Looks like there really is going to be a CCIE Wireless afterall.
They go on to say:
"After speaking with multiple Cisco employees within the wireless group, the Wireless CCIE has been confirmed. Beta candidate registration should begin this fall, along with a blueprint release. Beginning early 2009 the Wireless CCIE beta testing will begin! As of now, topics of the test are expected to cover all aspects of wireless from design through implementation including the implications of security, routing and switching and voice technologies. Check back often for any additional information!"
So there you have it. Looks like there really is going to be a CCIE Wireless afterall.
More on the new CCNA Certifications
Do you think that the new CCNA certifications are a sign of what is to come? Will the CCNA Voice soon be the prerequisite to a CCVP? CCNA Security for the CCSP?
What about Wireless? Cisco has no formal career certification for Wireless. The last word I received on this topic was that Wireless is incorporated in the CCNP Track. However, if Cisco is able to create an independent associate level certification for wireless, do you think that a CCWP may be on the way? Or even a CCIE - Wireless?
Everything I read is that Wireless is going to become more important as the years go on. Don't you think that if Voice/Security/Service Provider can all have Professional Level tracks, then Wireless deserves one too? Storage Networking even has its own CCIE Track. The wireless product line and feature set that Cisco has to offer is more than enough to warrant a professional level certification.
Wouldn't it make sense for Wireless to be valued as an independent skill. Hopefully this CCNA Wireless certification is the first step in right direction.
What about Wireless? Cisco has no formal career certification for Wireless. The last word I received on this topic was that Wireless is incorporated in the CCNP Track. However, if Cisco is able to create an independent associate level certification for wireless, do you think that a CCWP may be on the way? Or even a CCIE - Wireless?
Everything I read is that Wireless is going to become more important as the years go on. Don't you think that if Voice/Security/Service Provider can all have Professional Level tracks, then Wireless deserves one too? Storage Networking even has its own CCIE Track. The wireless product line and feature set that Cisco has to offer is more than enough to warrant a professional level certification.
Wouldn't it make sense for Wireless to be valued as an independent skill. Hopefully this CCNA Wireless certification is the first step in right direction.
Supplemental CCNA Certifications
So it has come to my attention that Cisco has released three new certifications as a supplement to an active CCNA. The certifications and related information is linked below:
CCNA Security
Course: IINS - Implementing Cisco IOS Network Security
Exam: IINS 640-553
CCNA Voice
Course: IIUC - Implementing Cisco IOS Unified Communication
Exam: IIUC 640-460
CCNA Wireless
Course: IUWNE - Implementing Cisco Unified Wireless Networking Essentials
Exam: IUWNE 640-721
CCNA Security
Course: IINS - Implementing Cisco IOS Network Security
Exam: IINS 640-553
CCNA Voice
Course: IIUC - Implementing Cisco IOS Unified Communication
Exam: IIUC 640-460
CCNA Wireless
Course: IUWNE - Implementing Cisco Unified Wireless Networking Essentials
Exam: IUWNE 640-721
Subscribe to:
Posts (Atom)
