Uncategorized
Measuring the impact of high wireless channel utilisation
I don’t know if anyone else has thought of this approach, but I discovered a nice way to assess the impact of a busy RF environment on a wireless stations ability to transmit a frame.
A brief bit of background information- an 802.11 station can only transmit a frame when the channel is not being used. Unfortunately there can be many reasons why a channel might be busy, for example another station transmitting, or a source of interference like a rogue AP, or a source of noise like a security motion detector. There are many tools for viewing how busy a channel is, such as examining radio channel utilization reported by APs, spectrum analysis using Cisco CleanAir or Metageek Channelyzer Pro, these provide good visualisations of utilisation.
Here’s the problem though- they don’t tell you the impact to a client station- how is the interference affecting a station trying to get air time to transmit its frame. Does it have to wait 100ms to send a frame, or 800ms, if the station is sending packets from a real-time application like Microsoft Lync, or Cisco IPT for example, waiting 800ms to get air time is not acceptable.
Here’s an example of a radio that is busy, as you can see the source of the high utilisation is interference, in this case due to a large number of rogue APs sending beacons at 1Mbit/sec using inefficient CCK modulation.
So, how are wireless stations being impacted by this? Using a wireless packet sniffer we can capture the beacons for the SSID that we want to analyse. Beacons are sent every 100ms by default, for each SSID. By looking at the delta time between the transmission of the beacons we can understand how long the AP needs to wait before getting air time.
Here’s a Wireshark display filter to capture beacons for a specific BSSID-
‘wlan.fc.type_subtype == 0x0008 && wlan.bssid == xx:xx:xx:xx:xx:xx’
Using the WireShark I/O graph we can see in the example below that the average delta between beacons is 100ms, the AP is able to get air time very easily.
Here’s another example where the RF is busy, there are very significant delays in sending beacons. At times there is a three second delay between transmission of beacons, it’s not hard to imagine the impact of this type of delay on an interactive application like voice, video or desktop sharing.
There are some caveats to this approach, for example beacons may be given lower priority to other packets, such as those marked with high priority 802.11e values. There may also be other factors that cause delay in transmission of beacons, such as utilisation of resources (CPU etc.) on the AP. It’s not a fool proof approach, but I find it is a fairly accurate way to understand the impact of high channel utilisation on a clients ability to transmit.
Another approach could be to use an IP SLA to measure deviation in latency to a client, but this may also measure other components of the network in the path to the destination.
Let me know your thoughts in the comments section.
Read Full Post | Make a Comment ( None so far )Wireshark Capture Vs Display Filters
Bit of background info:
Libpcap – API/C/C++ libarary used for packet capture at the link layer on *nix machines
Winpcap – Libpcap API ported to Windows machines for compatibility
Berkeley Packet Filter – format/syntax used for capture filtering withing TCPDump and Wireshark etc
TCP dump – network analyser created by Lawrence Berkeley National Laboratory
Wireshark – network analyser created by Gerald Combs (now Riverbed)
Wireshark uses the Berkeley Packet Filter format for capture filtering, as this is the format used by Libpcap and Winpcap libraries for capturing of packets at the NIC. It’s generally not possible to use BPF for display filters, however certain filters do overlap.
BPF filter ‘tcp port 25 and host 192.168.1.1’ is a valid capture filter, but will not function as a display filter.
Display filter ‘tcp.port==25 && ip.addr==192.168.1.140’ is the equivalent display filter.
Capture filter examples:
not host 192.168.1.2
tcp port 80
ether host d4:87:d8:14:2f:18
Custom profile capture filters are stored in C:\Users\%username%\AppData\Roaming\Wireshark\profiles\profilename\cfilters
Display filter examples
!ip.addr == 192.168.1.2 – find all packets where ip.addr is not 192.168.1.2
http.request.uri contains google.com – finds all packets where the URI (uniform resource identifier) contains google.com
eth.src[4:2] == f8:ee – find f8:ee in field eth.src, start looking from the 4th byte, for the next two bytes
It’s possible to capture packets using tshark (command line) by issuing tshark.exe -R “display filter here”.
Any field within the packet detail can be applied as a filter, for example you can right click on content type field within a HTTP packet and click copy > as filter, as you can apply or prepare as filter. http.content_type == “image/jpeg”.
A quick way to filter on a specific TCP flow/conversation is to use the TCP stream number, a unique ID assigned by wireshark to each TCP conversation. The stream ID can be found by examing the TCP header in packet details, field name “tcp.stream”.
Read Full Post | Make a Comment ( None so far )
Cisco 3750X Series Switch Notes
Some brief notes on Cisco’s 3750X series switches–
Power
IP Base (layer 3) switch models support power stacking, the ability for a switch to receive power from a neighbour if the direct power source fails. Up to four switches can be added in a single power stack. The switch by default comes with a single PSU that slots into the back of the chassis, a secondary power supply can be purchased if required, however if stack power is being used it offers minor advantage. RPS are supported on all models. PoE models can provide up to a full 30watts on all ports using PoE+.
Switch Performance
Switch fabric performance is 160Gbit/sec, stacking performance is 64Gbit/sec using the provided stackwise plus cables.
Scaleability
The 3750X series have an optional network module that can can provide the following upgrade options, note that by default there is no network module installed. This must be ordered as a separate part.
Network Module SFP/SFP+ configuration options:
2x 10Gbit/sec SFP+
or 1x 10Gbit/sec SFP+ and 2x 1Gbit/sec SFP
or 4x 1Gbit/sec SFP
Lightweight AP – DHCP Configuration
Just some findings on lightweight access points, and configuration of DHCP pools. DHCP is used to tell the LAPs what the wireless controller(s) ap-mgmt address is on boot up.
Option 60 is specified in a DHCP discover packet by lightweight APs requesting an IP address, it’s used to tell the server what type of device it is, for example a client may set option 60 to ‘Cisco AP c1140’.
The DHCP server can be configured to provide additional options in a DHCP offer packet, only to those client’s that need it. In this case, if option 60 is ‘Cisco AP c1140’, the server will return option 43, which has the address of the wlc ap-mgmt interface IP addresses in hex format.
! ip dhcp pool ap_manager network 128.58.172.128 255.255.255.224 default-router 128.58.172.129 dns-server 192.23.23.192 192.23.23.193 # Identifies type of device option 60 ascii "Cisco AP c1140" # Specifies IP of WLC controllers 192.168.10.5|192.168.10.20 option 43 hex f108c0a80a05c0a80a14 domain-name eur.slb.net lease 8 !
The hex value is made up as follows:
f1 = 0xf1 (type)
08= 0x8 (total number of octets in both IP addresses 2×4)
c0a80a05=192168105 (first IP)
c0a80a14=1921681020 (second IP)
It should be noted that there is a bug on 3750 switches running 12.2(46)SE which prevents option 60 from being specified. “% Invalid input detected at ‘^’ marker.” is returned because there is a space in the text ‘Cisco AP c1140’. To resolve this change to a different version of code.
Read Full Post | Make a Comment ( None so far )Making IP Helper (UDP forwarding) HSRP Aware
This scenario involves multiple gateway routers using first-hop redundancy protocols like HSRP. The routers are using IP helper commands to forward DHCP requests to a central server, however the server is receiving many DHCP requests from the same client, as shown below:
dhcpserver#sh log | i through relay *Mar 1 00:20:41.291: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d63 through relay 192.168.1.2 *Mar 1 00:20:43.819: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d63 through relay 192.168.1.3
It must be understood that DHCP discover packets are broadcast, and thus received and forwarded by all routers configured with IP helper addresses. To prevent all routers from forwarding the request, the solution is to only allow the active HSRP router to do this.
Below is overall topology:
Configuration for R1:
interface FastEthernet0/0 ip address 192.168.1.2 255.255.255.0 ip helper-address 10.1.1.1 redundancy HSRP-Data duplex auto speed auto standby 10 ip 192.168.1.1 standby 10 preempt standby 10 name HRSP-Data
Configuration for R2:
interface FastEthernet0/0 ip address 192.168.1.3 255.255.255.0 ip helper-address 10.1.1.1 redundancy HSRP-Data duplex auto speed auto stand 10 ip 192.168.1.1 standby 10 priority 90 standby 10 preempt standby 10 name HSRP-Data
By linking the IP helper command to HSRP ‘ip helper-address 10.1.1.1 redundancy HSRP-Data’ it is now able to track the HSRP state. The IP helper redundancy name must match the HSRP name, in this case ‘HSRP-Data’. Now when the DHCP client requests an IP configuration, it can be observed that only the active HSRP router replies:
dhcpserver#sh log | i through relay *Mar 1 00:20:41.291: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d63 through relay 192.168.1.2Read Full Post | Make a Comment ( None so far )
802.1Q (Q-In-Q) Tunnelling
Commonly used by service providers when providing L2 products, 802.1Q tunnel (aka Q-in-Q) can be used to allow multiple customers to trunk multiple VLANs over the service providers switched infrastructure. As a customer you can trunk your existing vlan numbering scheme, the VLAN tag you select is transparent to the service provider as they apply and use their own additional tag to identify you.
On receipt of a frame from the customer, the SP adds a second tag, in this case ’55’ , the ID must be unique for each customer. After potentially traversing multiple SP switches the second tag is removed on egress to the respective customer. Refer to this link to see a packet capture highlighting the two 802.1Q headers.
To configure, the first step is to increase the switch system MTU by 4 bytes in order to accomodate the additional tag:
system mtu 1504
Secondly, to avoid potential clashing of customer and provider native untagged vlans, enable tagging of the native vlan:
vlan tag dot1q native
Enable dot1q tunnel on the customer facing interface, and L2 protocol tunnelling
! interface FastEthernet0/16 description SWP | Customer 1 Site switchport access vlan 55 switchport mode dot1q-tunnel l2protocol-tunnel cdp l2protocol-tunnel stp l2protocol-tunnel vtp no cdp enable !
Interconnections between the providers switchs are configured as trunk links, in this case permitting VLAN 55 for customer 1.
Layer 2 protocol tunnel (not to be confused with L2 tunnelling protocol) has been activated on the interface. This feature provides the customer with transparency between their sites, they see their remote switches in CDP, VTP information can be propagated across their WAN along with STP information. It looks like the sites are directly connected, despite the providers switches being in the switching path.
As you can see below the CDP, VTP and STP information is fowarded over the providers infrastructure:
S1#show l2protocol-tunnel
Port Protocol Shutdown Drop Encapsulation Decapsulation Drop
Threshold Threshold Counter Counter Counter
---------- -------- --------- --------- ------------- ------------- -------------
Fa0/16 cdp ---- ---- 40 38 0
stp ---- ---- 5139 596 0
vtp ---- ---- 7 3 0
Read Full Post | Make a Comment ( None so far )
Disabling DHCP client default route
If you do not wish for your router to install the default route it receives when DHCP client is enabled on an interface, use the command below to raise the AD so it’s not entered into RIB. This is useful if you are using dynamic routing on a WAN interface, and want to use object tracking to detect lack of default routing.
! interface FastEthernet0/0 description WAN LINK bandwidth 1000000 ip dhcp client default-router distance 255 ip address dhcpRead Full Post | Make a Comment ( None so far )
Ethernet – Collisions
Interfaces operate at half-duplex when connected to a shared ethernet segment (collision domain).
When an inteface in half-duplex mode is receiving a frame, it may buffer a frame being transmitted at the same time. This will be displayed as a deferred frame when looking at the interface statistics.
Auto speed/duplex negotiation is the default, to deactivate it you can manually set speed/duplex. Speed must be set before duplex otherwise an error is displayed.
If auto-negotiation is disabled on one end, the Cisco switch will default to half duplex for 10/100M, and full duplex for 1G.
Read Full Post | Make a Comment ( None so far )Hostname X is not a legal LAT node name
Interesting error message occurred when changing host name on a Cisco router, 1841:
old-router-name-is-here(config)#hostname my-new-router-name-here % Hostname "MY-NEW-ROUTER- " is not a legal LAT node name, Using "CISCO_CADD00" my-new-router-(config)#
If the host name being configured is longer than sixteen characters the router will advise that it will use a new host name, however the configuration will still display the one that you intended to use.
Read Full Post | Make a Comment ( None so far )
Technical Notes 