Connecting the world…

mode

Aruba RAP in bridge mode with remote access

The Aruba Networks Remote Access Points is a nice feature for branch offices or home workers. I use a RAP5WN at home and I configured different SSID’s on the RAP. The SSID’s are in tunnel mode, split-tunnel mode or bridge mode. The bridge mode connections are for my home devices, like my girls iPad and iPhone.

The RAP5WN has four 10/100 FastEthernet ports. I configured wired ap profiles for these ports and they are also configured in bridge mode. All devices in bridge mode receive an IP address from my local internet router (ADSL) and this works without any problems. Devices in bridge mode can directly communicate with each other.

My local internet router has some port forwarding rules configured so I can access the server from the internet. After using the Aruba RAP and physically moving the server from the local router to the Aruba RAP, I couldn’t access the server anymore. I did some more testing and noticed that I couldn’t connect to any device behind the RAP, when I tried to connect to the devices through the uplink port of the RAP.

I checked the configuration of the RAP and especially the wired AP profiles. I couldn’t find any related configuration parameters to change this behavior. Eventually I found the solution within the AP system profile. The setting Session ACL solved my problem. The explanation for the setting is: Session ACL applied on uplink of a remote AP. By default the session acl parameter is configured as ap-uplink-acl. This acl contains the following entries:

ip access-list session ap-uplink-acl
any any udp 68  permit
any any svc-icmp  permit
any host 224.0.0.251 udp 5353  permit

I changed this setting to the session acl allowall to permit all traffic on the uplink interface.

ap system-profile “custom-ap-system-profile”
session-acl “allowall”
!
ap-group “home-rap-group”
ap-system-profile “custom-ap-system-profile”

I was able to connect remotely to the server after applying the session acl allowall to the AP system profile, which is connect to the correct AP Group. Problem solved!!

AutoQos error while generating commands

First of all, the post isn’t about explaining QoS. Configuring AutoQos on Cisco switches should be very easy. At least, that is what all the Cisco documentation tells you. I always thought that the statements about configuration AutoQos were true, but a few days ago I would disagree.

I was configuring multiple switches, Cisco Catalyst 2960-24PC-L switches to be more precise. The switches are configured with a default template, which is generated according the needs of the customer. I uploaded the most recent software into the switches, which is 12.2(55)SE. The customer is going to use an Avaya IP telephony environment, so I tried to apply the appropriate AutoQos command to an interface. After applying the command, I received the following error:

AutoQoS Error while generating commands on Gi0/2

The switches didn’t have any QoS configuration before applying the command. Searching multiple forums didn’t gave me a valid solution. I did my own research and found an incompatibility with the configuration mode exclusion command, like shown below:

configuration mode exclusive auto expire 500 lock-show config-wait 5 retry-wait 5

I removed the configuration mode exclusion command and the AutoQos commands can be implemented without errors. I tried to find why it isn’t possible to apply the AutoQos commands while the configuration mode exclusive command is enabled.

I guess the problem is that the configuration mode exclusive commands prevents other users or the auto-generation of commands to be executed. When applying the AutoQos commands, the commands are executed by the router / switch and not by the user who locked the cli.

Cisco Aironet: multiple SSID’s

I have been playing with some Cisco Aironet’s today. Configuration is quite simple and straightforward, but maybe not for everyone:

  • Broadcast two SSID’s, unsecure and secure
  • Authentication via WPA version 2 pre-shared key
  • Management IP adres in management VLAN

You are maybe thinking: “stand-alone access points, why no WLAN controller?” I agree, but be honest. Would you use a WLAN controller for less then 5 access points?

The snippet below shows the most important configuration for such a scenario.

dot11 mbssid
dot11 vlan-name secure vlan 11
dot11 vlan-name default vlan 1
dot11 vlan-name unsecure vlan 13
dot11 vlan-name management vlan 10
!
dot11 ssid unsecure
vlan 13
authentication open
authentication key-management wpa version 2
mbssid guest-mode
wpa-psk ascii <wpa pre-shared key>
!
dot11 ssid secure
vlan 11
authentication open
authentication key-management wpa version 2
mbssid guest-mode
wpa-psk ascii <wpa pre-shared key>
!
bridge irb
!
interface Dot11Radio0
no ip address
no ip route-cache
!
encryption vlan 13 mode ciphers aes-ccm tkip
!
encryption mode ciphers aes-ccm tkip
!
encryption vlan 11 mode ciphers aes-ccm tkip
!
ssid unsecure
!
ssid secure
!
speed  basic-1.0 basic-11.0 basic-54.0
channel 2412
station-role root
!
interface Dot11Radio0.11
encapsulation dot1Q 11
no ip unreachables
no ip proxy-arp
no ip route-cache
no cdp enable
bridge-group 11
bridge-group 11 block-unknown-source
no bridge-group 11 source-learning
no bridge-group 11 unicast-flooding
bridge-group 11 spanning-disabled
!
interface Dot11Radio0.13
encapsulation dot1Q 13
ip access-group internet-only in
no ip unreachables
no ip proxy-arp
no ip route-cache
no cdp enable
bridge-group 13
bridge-group 13 subscriber-loop-control
bridge-group 13 block-unknown-source
no bridge-group 13 source-learning
no bridge-group 13 unicast-flooding
bridge-group 13 spanning-disabled
!
interface FastEthernet0
no ip address
no ip route-cache
duplex auto
speed auto
!
interface FastEthernet0.10
encapsulation dot1Q 10 native
no ip unreachables
no ip route-cache
no cdp enable
bridge-group 10
no bridge-group 10 source-learning
bridge-group 10 spanning-disabled
!
interface FastEthernet0.11
encapsulation dot1Q 11
no ip unreachables
no ip route-cache
no cdp enable
bridge-group 11
no bridge-group 11 source-learning
bridge-group 11 spanning-disabled
!
interface FastEthernet0.13
encapsulation dot1Q 13
no ip unreachables
no ip route-cache
no cdp enable
bridge-group 13
no bridge-group 13 source-learning
bridge-group 13 spanning-disabled
!
interface BVI10
ip address 10.1.1.200 255.255.255.0
no ip route-cache
!
ip default-gateway 10.1.1.1
!
bridge 1 route ip

I hope this helps when you are configuring a Cisco Aironet with multiple SSID support.

Fiber optics and UDLD

UDLD (Unidirectional Link Detection) is a protocol to help prevent forwarding loops in switched networks. A fiber cable is build from two separate fibers (transmit and receive), where one of the two fiber could fail, which would result in a switch port not able to receive or send traffic. This scenario could result in some serious problems.

The Problem

Spanning-Tree Protocol (STP) resolves redundant physical topology into a loop-free, tree-like forwarding topology. This is done by blocking one or more ports. By blocking one or more ports, there are no loops in the forwarding topology. STP relies in its operation on reception and transmission of the Bridge Protocol Data Units (BPDUs). If the STP process that runs on the switch with a blocking port stops receiving BPDUs from its upstream (designated) switch on the port, STP eventually ages out the STP information for the port and moves it to the forwarding state. This creates a forwarding loop or STP loop.

Check the following two pictures:

STP-A STP-B

The left pictures shows a regular layer 2 network, where switch B is the designated switch for the B-C segment. Switch C on the B-C link is in blocking state. In the right picture switch C’s Tx is broken, switch C doesn’t receive and BPDU packets from switch B anymore and ages the information received with the last BPDU. Once the STP information is aged out on the port, that port transitions from the blocking state to the listening, learning and eventually to the forwarding STP state. This creates a forwarding loop, as there is no blocking port in the triangle A-B-C. Packets cycle along the path (B still receives packets from C) taking additional bandwidth until the links are completely filled up. This brings the network down.

UDLD explained

UDLD is a Layer 2 (L2) protocol that works with the Layer 1 (L1) mechanisms to determine the physical status of a link. At Layer 1, auto-negotiation takes care of physical signaling and fault detection. UDLD performs tasks that auto-negotiation cannot perform, such as detecting the identities of neighbors and shutting down misconnected ports. When you enable both auto-negotiation and UDLD, Layer 1 and Layer 2 detections work together to prevent physical and logical unidirectional connections and the malfunctioning of other protocols.

UDLD works by exchanging protocol packets between the neighboring devices. In order for UDLD to work, both devices on the link must support UDLD and have it enabled on respective ports.

Each switch port configured for UDLD sends UDLD protocol packets that contain the port’s own device/port ID, and the neighbor’s device/port IDs seen by UDLD on that port. Neighboring ports should see their own device/port ID (echo) in the packets received from the other side.

If the port does not see its own device/port ID in the incoming UDLD packets for a specific duration of time, the link is considered unidirectional. Once the unidirectional link is detected by UDLD, the respective port is disabled and this message is printed on the console and the logging:

UDLD-3-DISABLE: Unidirectional link detected on port 1/2. Port disabled

UDLD can operate in two modes:

  1. Normal: if the link state of the port was determined to be bi-directional and the UDLD information times out, no action is taken by UDLD. The port state for UDLD is marked as undetermined. The port behaves according to its STP state.
  2. Aggressive: if the link state of the port is determined to be bi-directional and the UDLD information times out while the link on the port is still up, UDLD tries to re-establish the state of the port. If not successful, the port is put into the errdisable state.

Depending on the fiber uplink (type of cable, length of the cable, age of backbone and more) I use UDLD aggressive mode. Aggressive mode will put the port in errdisable, but in my opinion it is better to loose some switches then flooding the complete layer 2 network and disturbing even more users.

Configuration Mode Locking

While browsing some networking related blogs, so stumbled on a nice new feature in Cisco IOS on 6200networks.com. The feature prevents multiple users from changing the configuration of a network component simultaneous. This feature, configuration mode locking, is available in two different modes:

  1. Automatic – the session is locked, when you log in to the component;
  2. Manual – you can decide when to lock the configuration session;

Looking at the IOS commands, configuring configuration locked is very simple. Let’s check out the available options:

SW01#conf t

SW01(config)#configuration mode exclusive [auto | manual]

When using the keyword auto the session is automatically locked as soon as you log in to the specific network component. When using the keyword manual, you can decide when to lock the session. The lock the session manually, you use the following command:

SW01#configure terminal lock

SW01#

Configuration mode locked exclusively. The lock will be cleared once you exit out of configuration mode using end/exit

The status of configuration locking can be viewed with the command:

SW01#show configuration lock

Parser Configure Lock
———————
Owner PID        : 261
User             : booches
TTY              : 1
Type             : EXCLUSIVE
State            : LOCKED
Class            : EXPOSED
Count            : 1
Pending Requests : 0
User debug info  : configure terminal lock

This feature is very useful in environments where multiple system engineers could log in and configure the same network component.