Booches.nl

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:

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.

Cisco Firewall Design and Deployment

The session about firewall design and deployment didn’t reveal a lot of new things about the Cisco ASA appliance or FWSM module. The only new thing for me was the possibility to configure a redundant interface for a Cisco ASA appliance. The screen shot below shows the cabling scheme for an implementation with and without interface redundancy.

This interface redundancy makes it possible to connect a ASA to two different physical switches. When the active switch would crash, the second switch would become the active switch.

Important here is to notice that this configuration doesn’t provide load-balancing across two links. The configuration is only for link redundancy.

To configure interface redundancy you can use the configuration snippet shown below.

interface Redundant1
  member-interface GigabitEthernet0/2
  member-interface GigabitEthernet0/1
  no nameif
  no security-level

  no ip address
!
interface Redundant1.4
  vlan 4
  nameif inside
  security-level 100
  ip address 172.16.10.1 255.255.255.0
!
interface Redundant1.10

  vlan 10
  nameif outside
  security-level 0
  ip address 172.16.50.10 255.255.255.0

The configuration of interface redundancy has some caveats as listed below:

• Firewalls have to be configured in Active/Standby mode. No load-balancing or link aggregation is supported;
• Interface redundancy is available on Cisco ASA 5510 and above. The ASA 5505 already has a build in switch and FWSM doesn’t have any physical interfaces;
• Subinterfaces (IEEE 802.1Q) need to be configured on top of the logic redundant interface;

During the session the different modes for the firewalls have been discussed. Normally we only use the Routed Mode, but there are more modes like described below:

• Routed mode: traditional mode of the firewall. Two or more interfaces that separate two or more layer 3 domains;
• Transparent mode: the firewall acts as a bridge and functions mostly at layer 2 of the OSI model (this functions is often used for filtering traffic between two routers who, for example, exchange routing information through a dynamic routing protocol);
• Multi-context: one physical firewall is divided in more virtual firewalls;
• Mixed mode: using routed and transparent firewalls in a virtual environment (NOTE: mixed mode is only supported in FWSM today);

Firewall virtualization using multiple context has some caveats. We, Ictivity consultants, already noticed these caveats during firewall implementations. Firewall virtualization has the following caveats:

• No support for VPN services;
• No support for dynamic routing protocols;
• No way to configure the sharing of CPU usage between contexts;
• No support for multicast routing (multicast bridging is supported);

Especially not supporting VPN services (site-to-site VPN, remote access VPN and SSL VPN) is mostly the most used reason for not using multiple context implementation for the firewall.