Category Archives: Cisco

Place Cisco 1720i Access Point into Autonomous mode

If you are like me you occasionally need to setup a single AP into a site either too small for a controller, or unwilling to pay the extra costs associated with one. Here are the steps required to change to Autonomous mode, as I believe that all of the x702i series are shipping in lightweight mode by default.

  1. Log into www.cisco.com
  2. Click “Support” at the top
  3. Click the “Downloads” tab
  4. Select the “Wireless” from the left hand pane”
  5. Select “Access Points”
  6. Select “Cisco 1700 Series Access Points”
  7. Select “Cisco Aironet 1702i Access Points”
  8. Click “Autonomous AP IOS Software”
  9. Ideally, you are looking for the highest number firmware revision that’s marked as MD, or GD. In some cases you’ll only see ED revisions, downloaded the highest revision number. Click the “Download” button, and agree to the terms of service.
  10. Connect a network cable from your PC to the AP.
  11. Start a TFTP server on your computer, and set your interface to 10.0.0.1 255.255.255.0.
  12. Open a Serial connection to the AP, after it finishes booting log in. [Default Password:Cisco ]
  13. Enter the following commands, pressing enter after each line:
    1. enable
    2. debug capwap console cli
    3. debug capwap client no-reload
    4. capwap ap ip address 10.0.0.2 255.255.255.0
    5. capwap ap ip default-gateway 10.0.0.1
    6. Archive download-sw /force /overwrite tftp://10.0.0.1/%File Name%.tar
  14. The AP will reboot automatically. After its finished the reboot, log back in and issue the following command:
    1. show version
  15. Verify the AP is now running the updated image, and that you have access to the full suite of commands.

NOTE: you’ll notice that you keep getting a capwap error while the AP is in lightweight mode, if you are having trouble entering these commands because of it, put them all into a notepade file, wait for the error to appear, and then quickly paste them all in at once.

Configuring Cisco 1702i Autonomous access point for use with Chromecast

Assuming you’d like to connect a client computer to your chromecast via the same WLAN on your Cisco AP, all you need to do is follow the below steps.

Assumptions:

  1. The Cisco AP is configured with only a single SSID, and that SSID happens to be associated with vlan 2.
  2. You are broadcasting the WLAN on both radios
  3. All the required configuration to support clients (SSID, Auth, etc) is already setup

Instructions:

  1. Login to your AP using the command line, issues a show run
  2. The output of your show run command should have some lines similar to what’s below:

!
interface Dot11Radio0.2
encapsulation dot1Q 2
no ip route-cache
bridge-group 2
bridge-group 2 subscriber-loop-control
bridge-group 2 spanning-disabled
bridge-group 2 block-unknown-source
no bridge-group 2 source-learning
no bridge-group 2 unicast-flooding
!
interface Dot11Radio1.2
encapsulation dot1Q 2
no ip route-cache
bridge-group 2
bridge-group 2 subscriber-loop-control
bridge-group 2 spanning-disabled
bridge-group 2 block-unknown-source
no bridge-group 2 source-learning
no bridge-group 2 unicast-flooding
!

So if our SSID is affiliated with vlan 2, we’ll need to issue a command to each of our sub interfaces using that vlan: Dot11Radio0.2 and Dot11Radio1.2

Enter the following commands:

  1. # config t
  2. (config)# interface Dot11Radio0.2
  3. (config-if)# no bridge-group 2 port-protected
  4. (config-if)# exit
  5. (config)# interface Dot11Radio1.2
  6. (config-if)# no bridge-group 2 port-protected
  7. (config-if)# exit

Now we’ll also need to globally stop IGMP snooping, we’ll enter this additional command from global config mode:

  1. # config t
  2. (config)# no ip igmp snooping
  3. (config-if)# exit

Lastly just save your config and test, you should now be able to connect to the chromecast from a wireless client connected to the same WLAN as the chromecast, or if you followed the previous post on configuring a sonicwall for use with a chromecast (located here), a wired client connected on another interface of your sonicwall.

 

Configuring Cisco Wireless LAN Controller for use with Chromecast

This post is mostly to compliment the post on configuring SonicWALL with Chromecast (found here) since it’s fairly easy, but never the less here we go:

Assuming your Chromecast is connected to the same Wireless LAN as your client, the only thing you need to do is Login to your WLC and enable multicast. Follow these steps:

  1. Load the WebUI of your Cisco Wireless Lan controller.
  2. Click Controller tab at the top
  3. Click Multicast in the left hand tab
  4. Check the box titled Enable Global Multicast Mode
  5. Click Apply in the top right of the page
  6. Click Save Configuration in the top right of the page

That’s it, you should now be able to see the chromecast from any wireless client connected to the same WLAN as the chromecast.

Configuring Failover between two Cisco ASAs

I had to setup my first Active Passive Cisco ASA pair this past week, it turns out it’s a little simpler than the documentation first makes it appear. Here is what you’ll need:

  • Two ASAs with the licensing necessary to enable Failover
  • Two IPs on each subnet the pair will be connected to (including a new subnet on the failover link between the units, this should be a subnet not in use anywhere else on the network)
  • A Crossover cable.

Let’s make some assumptions, first let’s say our Private IP subnet is 192.168.1.x/24, our failover subnet is 172.16.1.x/24, and our wan subnet is 1.1.1.x/24, just so we know what IPs we’ll use. Let’s also assume that we’re using Interface 0/0 for the WAN, and Interface 0/1 for the LAN, and interface 0/3 for the failover.

  1. Bring your first unit online, and assign the first IP on each subnet to the proper interfaces.
  2. Bring your second unit online, and assign the second IP on each subnet to the proper interfaces
  3. Connect one of the interfaces on the first unit to that same interface on the other unit using the crossover cable, assign IPs on this interface from the new subnet you created for failover traffic.
  4. Verify that each unit can ping the other on each interface (wan to wan, failover to failover, lan to lan)
  5. Once you’ve verified that each unit can communicate with the other it’s time to start entering commands.

With those subnets in mind let’s assign IPs:

Primary:

  • Lan: 192.168.1.1
  • Failover 172.16.1.1
  • Wan 1.1.1.1

Secondary:

  • Lan: 192.168.1.2
  • Failover 172.16.1.2
  • Wan 1.1.1.2

So here are the commands that we’re going to enter on our primary unit:

  1. Interface Ethernet0/0
  2. ip address 1.1.1.1 255.255.255.0 standby 1.1.1.2
  3. Interface Ethernet0/1
  4. ip address 192.168.1.1 255.255.255.0 standby 192.168.1.2
  5. failover lan unit primary
  6. failover lan interface Failover ethernet0/3
  7. failover link Failover Ethernet0/3
  8. Failover interface ip Failover 172.16.1.1 255.255.255.0 standby 172.16.1.2
  9. failover

Here are the commands that we’re going to enter on our secondary unit:

  1. Interface Ethernet0/0
  2. ip address 1.1.1.1 255.255.255.0 standby 1.1.1.2
  3. Interface Ethernet0/1
  4. ip address 192.168.1.1 255.255.255.0 standby 192.168.1.2
  5. failover lan unit standby
  6. failover lan interface Failover ethernet0/3
  7. failover link Failover Ethernet0/3
  8. Failover interface ip Failover 172.16.1.1 255.255.255.0 standby 172.16.1.2
  9. failover

You can then run a “show failover” on each unit to see which is active, and which is standby, and whether or not failover is working. You also can continue to connect to either unit using either the primary or secondary IP, they will both display the same hostname since their configs are being replicated, but you can use the “show failover” to remind yourself which unit you are on. Finally you’ll only want to make  and save changes from the primary unit, failover will take care of replicating them to the other unit.

Once you’ve verified that everything is working, run a “write mem” on each unit before you start testing.