Steven M. Jordan

Showing posts with label Routing. Show all posts

Summary

Folks get frustrated when Wi-Fi doesn't work with their iPhones and iPads. There are times when iPhones can't connect, frequently disconnect, or experience poor data rates.

The previous post examines six different wireless problems associated with iPhones and iPads: Standby settings; spectrum preference; legacy rates; encryption; and signal strength.

This post provides specific solutions that resolve iPhone Wi-Fi problems. It includes Juniper wireless controller (WLC) configuration examples. However, these recommendations generally apply to all wireless systems (e.g., Cisco, Aruba, etc.). These practices also apply to personal wireless systems at the home.

Recommendation 1: Influence Roaming.

iPhones prefer the 2.4GHz band due to differences in transmission and client imprecision. Both factors cause unnecessary roaming between dual bands on a single AP.

Best Practices:

Use 5GHz for most situations.

Disable 2.4Ghz radio; or implement band segregation that dedicates unique SSID per spectrum (e.g., Pub-2.4 and Pub-5GHz).

Dynamic auto power transmission (tx-power) does not influence single-AP roaming when bands are segregated by SSIDs. However, do consider how power impacts the long range of 802.11bg networks (e.g., sticky client syndrome). Far reaching 11bg signals also introduce security vulnerabilities. Long distance range is not always desirable.
Take precautions to limit dual-band roaming for situation where band segregation is not possible. Influence iPhone 5GHz preference via signal strength. Keep 2.4GHz RSSI 11dBs lower than the 5Ghz RSSI. Insufficient 5GHz coverage is the exception.
Load-Balancing is for high density user base situations. Disable load balancing if it’s not necessary. By all means, use load balancing for locations with heavy use. Make sure there are sufficient APs within the proximity of each client.

Recommendation 2: Controlling Data Rates/ Cell Size.

Nearby 802.11bg networks can decrease 2.4GHz channel throughput by 90% (another reason to tone down power levels). This is especially troublesome considering there are only three non-overlapping 2.4GHz channel, Legacy data rates may further reduce network throughput. 5GHz is the preferred band.

Best Practices:

Disable 1, 2, 5.5, and 11 Mbps rates for 802.11a, 802.11g, 802.11na, and 802.11ng. Set Mandatory and Beacon rates to 24Mbps on all bands except 801.11b.
Use RF detection rules to disable 802.11b clients –this requires Ringmaster.

Alternately, set the radio type to 11ng. This approach disables 802.11b and strictly uses transmit rates defined in the service profile.

Also consider disabling 802.11g by changing the 20MHz channel width to 40HMz. There are still a number of devices that use 802.11g –exercise with caution.
Only use WPA2 RSN (i.e., AES) encryption with CCMP ciphers –no TKIP!

Recommendation 3: Transmission Power Tuning.

APs in close proximity to other APs may transmit overlapping cells. Overlapping cells can cause excessive iPhone roaming.

Best Practices:

Conduct site-survey to determine best coverage. Use auto-power tuning in lieu of site-survey.
Reduce power transmission rates from each AP. Avoid overlapping signals at -70 dBm (i.e., iPhone roaming). Acceptable overlapping target is approximately -81 dBm.

802.11b (2.4GHz) has nearly twice the range of 802.11a (5GHz). Adjust radio power levels so that 5GHz RSSI is greater than the 2.4GHz RSSI. For example, set 2.4GHz to 4dBm; and set 5GHz to 12dBm.

Some folks recommend disabling auto-power tuning. However, auto-tuning is a good alternative to simply jacking-up power rates to maximum transmission. Estimating static transmit maximums should work fine as well.

Juniper WLC iPhone Optimization Commands:

These steps segregates dual-band radios by assigning unique SSIDs to each radio. N.B., We can't use the GUI for this advanced configuration.

Table 1. Dual-Band Segregation Example.
SSID	Radio1 (2.4GHz)	Radio2 (5GHz)
SSID1	Contoso_2.4GHz
SSID2		Contoso_5GHz

1. Create service profiles for 2.4GHz band.

 *WLC# set service-profile contoso_2.4 11n mode-ng enable 
 *WLC# set service-profile contoso_2.4 11n mode-na disable

2. Set 2.4GHz transmission rates.

We cannot disable 11b transmission rates here. We essentially disable 11b later on when we assign radio type (11n/g vs 11b) in the radio-profile. Ignore 802.11b transmission rates (for now) and set mandatory 802.11g rates.

set service-profile sp_contoso_2.4 transmit-rate 11a mandatory  24.0,36.0,48.0,54.0 disabled 6.0,9.0,12.0,18.0 beacon-rate 24.0 multicast-rate  AUTO

set service-profile sp_contoso_2.4 transmit-rate 11b mandatory 11.0 disabled  1.0,2.0,5.5 beacon-rate 11.0 multicast-rate AUTO

set service-profile sp_contoso_2.4 transmit-rate 11g mandatory  24.0,36.0,48.0,54.0 disabled 1.0,2.0,5.5,6.0,9.0,11.0,12.0,18.0 beacon-rate 24.0  multicast-rate AUTO

set service-profile sp_contoso_2.4 transmit-rate 11ng mandatory  24.0,36.0,48.0,54.0 disabled 1.0,2.0,5.5,6.0,9.0,11.0 beacon-rate 24.0  multicast-rate AUTO

Set 2.4 GHz 11n mode:

set service-profile sp_contoso_2.4 11n mode-ng required

set service-profile sp_contoso_5GHz 11n mode-na disable

3. Create 5GHz service profile.

Set 11n mode for 5Ghz profile:


set service-profile sp_contoso_5GHz 11n mode-na required

set service-profile sp_contoso_5GHz 11n mode-ng disable

Set 5Ghz transmissions.



set service-profile sp_contoso_5GHz transmit-rate 11a mandatory  24.0,36.0,48.0,54.0 disabled 6.0,9.0,12.0,18.0 beacon-rate 24.0 multicast-rate  AUTO

4. Create 5GHz Radio Profile


set radio-profile rp_contoso_5GHz rate-enforcement enable

set radio-profile rp_contoso_5GHz service-profile sp_contoso_5GHz

5. Create 2.4GHz Radio Profile


set radio-profile rp_contoso_2.4 rate-enforcement enable

set radio-profile rp_contoso_2.4 service-profile sp_contoso_2.4

set radio-profile rp_contoso_2.4 preamble-length short

6. Optionally set power for RF transmission.

Dedicating radios to SSIDs allows for relaxed power management -it's not entirely necessary. Consider auto-power tuning. It’s not as good as a site survey but it’s better than blasting tx-power at maximum output.


set radio-profile Shoreland_2.4 power-policy max-coverage

7. Assign radio profiles to specific APs/Radios.

We assign radio 1 with auto transmit power.


set ap 3 radio 1 radio-profile Shoreland_2.4 radiotype 11ng tx-power auto

8. Optionally set channel width to 40MHz to effectivly prevent legacy devices from connecting.


set radio-profile Shoreland_2.4 11n channel-width-na 40MHz

9. Assign service profile to APs' 5GHz radios.
set ap 3 radio 2 radio-profile Shoreland_Guest radiotype 11na tx-power auto 10. Assign other SSIDs as needed. Add CORP-802.1x to new radio-profile -otherwise it won't broadcast.

set radio-profile Shoreland_2.4 service-profile Shoreland_VLAN1_MF

set radio-profile Shoreland_Guest service-profile Shoreland_VLAN1_MF

Let's see if it works:

#reset ap 3



#sh ap status verbose



Radio 1 Type: 802.11ng(2x3), State: configure succeeded [Enabled]

Antenna type: INTERNAL

Operational channel: 6 (Auto) Operational power: 4

Load balance: disabled

RFID reports: Inactive

BSSID1: 00:26:3e:xx:xx:xx, SSID: Contoso 2.4GHz

Radio 2 Type: 802.11na(2x3), State: configure succeeded [Enabled]

Antenna type: INTERNAL

Operational channel: 165,-- (Auto) Operational power: 18

Load balance: disabled

RFID reports: Inactive

BSSID1: 00:26:3e:xx:xx:xx, SSID: Contoso 5.4

That’s It!
---------

Juniper Troubleshooting Commands:

Review session data on the wireless controllers. Check client roaming. Look for short connection durations; and roams between the 2.4GHz and 5GHz radios:

CONTROLLER# sh sessions network verbose


CONTROLLER# sh service-profile Public

CONTROLLER# sh ap status verbose

Things to look for:

Roaming history: Check for short connection durations; and roams between the 2.4GHz and 5GHz radios.
Confirm the device information: Device type, Last RSSI, last packet rate.

Roaming history:


Switch AP/Radio Association time Duration

--------------- ----------- ----------------- -------------------

10.10.10.2 2/1 03/11/16 16:11:20 00:04:10
10.10.10.2 2/2 03/11/16 16:10:10 00:01:10
10.10.10.2 2/1 03/11/16 16:02:27 00:07:43
10.10.10.2 2/2 03/11/16 15:52:33 00:09:54
10.10.10.2 2/1 03/11/16 15:39:17 00:13:16
10.10.10.2 2/2 03/11/16 15:33:22 00:05:55

The above example shows frequent roams between the same AP.

-Confirm the device information: Device type, Last RSSI, last packet rate.


Device type: iphone (AAA)

Radio type: 802.11ng

Last packet rate: 24.0 Mb/s

Last packet RSSI: -69 dBm

Review the service-profile:


*CONTROLLER# sh service-profile Shoreland_Guest



11n attributes

11n Mode (na): enabled

11n Mode (ng): enabled

Guard Interval: short

Frame aggregation mode: all

MSDU Max length: 4k

MPDU Max length: 64k

TxBF: disabled

Is the 2.4GHz band (i.e., 11ng) enabled?


Crypto

RSN-IE

Authentication: PSK

Encryption: RSN

Cipher: CCMP

Pre-shared-key: xxxxxxxxxxxxxxxxxxxxxxxxxx

Also, Check encryption and cipher setting. Does it use WPA or Robust Security Network (RSN)? Or both? N.B., in general, WPA uses Temporal Key Integrity Protocol (TKIP), and RSN uses Advanced Encryption Standard (AES) with the Counter Mode CBC MAC Protocol (CCMP) cipher.

Juniper recommends WPA2 (i.e., RSN) and CCMP. It does not recommend combinations of WPA, WPA2, TKIP, and CCMP. Authentication can either be pre-shared key or 802.1x. Use 802.1x for the corporate network and PSK for the Guest network.

Pay attention to the 802.11 settings as well.

References:

https://support.apple.com/en-us/HT202068

http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-2/b_Enterprise_Best_Practices_for_Apple_Devices_on_Cisco_Wireless_LAN.pdf

http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/iPhone_roam/b_iPhone-roaming.html

http://stackoverflow.com/questions/11759802/keep-wifi-connection-active-even-ipad-is-going-into-sleep-mode-locked-in-ios-5

https://discussions.apple.com/thread/4326932?start=45&tstart=0

https://discussions.apple.com/thread/2561028?start=45

http://kb.juniper.net/InfoCenter/index?page=content&id=KB20295&actp=search&viewlocale=en_US&searchid=1301446020120
http://www.greatwhitewifi.com/2015/07/12/fixing-hallway-fi-vol-1/
http://community.arubanetworks.com/t5/Controller-Based-WLANs/How-does-the-quot-beacon-rate-quot-profile-work/ta-p/179242
http://kb.juniper.net/InfoCenter/index?page=content&id=KB28153&actp=search&viewlocale=en_US&searchid=1373982600826
https://en.wikipedia.org/wiki/IPhone
http://www.juniper.net/documentation/en_US/network-director1.5/topics/concept/wireless-encryption-and-ciphers.html
http://blogs.cisco.com/wireless/wi-fi-taxes-digging-into-the-802-11b-penalty
http://www.cisco.com/c/en/us/td/docs/wireless/technology/apdeploy/8-0/Cisco_Aironet_3700AP.html
https://www.wireless.att.com/support_static_files/KB/KB3895.html
http://kb.juniper.net/InfoCenter/index?page=content&id=KB20248&actp=search&viewlocale=en_US&searchid=1456780940943
https://www.youtube.com/watch?v=tihSXW6Yg1M

http://kb.juniper.net/InfoCenter/index?page=content&id=KB20176&actp=search&viewlocale=en_US&searchid=1250122420527

https://www.juniper.net/techpubs/en_US/release-independent/wireless/information-products/topic-collections/wireless-lan/software/9.0/mss_config_90.pdf

Problem: JUNOS DNS-Proxy resolution does not work over the VPN.

Symptoms:

DNS name resolution only resolves external domain names (i.e. Internet).
SRX DNS proxy does not resolve internal/ local domains from DNS server on other side of the VPN..
Ping requests fail from the SRX (i.e., DNS-Proxy) to the remote VPN site.
For Example, SRX2 cannot ping any node behind SRX1 via VPN.
All ping requests from the SRX fail without specifying exit interface.
Ping request from nodes on either side of the VPN are successful. Routing and VPN work.

Topology: The DNS proxy and DNS server are on separate sides of the VPN.

SRX1 is at the data center. Its site hosts the primary domain controller (DC) and DNS servers.
SRX2 is at the branch office.
The SRX2 site does not have a local DC or DNS server. It uses a split-tunnel VPN and split-brain DNS proxy for internal and external name resolution

Solution: Assume routing, DNS-Proxy and firewall configurations are OK. The problem is with how the SRX chooses its default address. Specify the default address for s should fix the problem:


set system default-address-selection

Next, assign the loopback interface with a routed IP address.


set interface lo0 unti 0 family inet address

N.B., Planning to use the DNS proxy with an public DNS server (e.g., 8.8.8.8)? Don't forget to create a corresponding NAT statement:

[edit security nat]


 rule-set self-internet {

                from zone junos-host;

                to zone UNTRUST;

                rule RE-untrust {

                    match {
                        source-address 0.0.0.0/0;

                    }

                    then {

                        source-nat {

                            interface;

Reason: The DNS proxy service uses the SRX loopback interface (lo0) for its source address. The default lo0 addess is 127.0.0.1. Traffic isn't going to go far with that address! Everything works if you assign lo0 with an IP address from your default VLAN!

N.B., This fixes all other issues with ICMP, FTP, etc., across the SRX to VPN as well.

References:

https://www.juniper.net/documentation/en_US/junos13.1/topics/reference/configuration-statement/default-address-selection-edit-system.html

JUNOS Missing Interfaces!

Issue: The Juniper J2300 series router is missing all of its physical interfaces (e.g., fe01) after upgrading to JUNOS 9.3X.

Cause: JUNOS 9.3 uses expired default certificates on EEOL equipment. For example, the J2300 certificates uses a certificate with expiration of 3/24/2014.

Quick Fix: Change the date JUNOS system to a date before 3/24/2014:


set date 200403311010.10

Long-term Fix: Use shell script to disable the synchronization between the hardware clock and the software clock:

Disable NTP (if applicable).
root@hostname> deactivate system ntp
Set date back ~10 years in JUNOS.
root@hostname> set date 200403311010.10
The rc utility is a command script that automatically runs at boot-up or shutdown. Configure the following script to disable the synchronization between the system's hardware and software time:
root@host> start shell root% sysctl -w machdep.disable_rtc_set=1 root% touch /cf/etc/rc.custom root% chmod +x /cf/etc/rc.custom root% echo "sysctl -w machdep.disable_rtc_set=1" > /cf/etc/rc.custom root% cat /cf/etc/rc.custom
Reconfigure NTP or set time manually in JUNOS.
root@hostname> set date 201509151010.10

References:

Artifact: Demonstrate the value of ICT methodology.
By Steven Jordan on 11/26/2013.

Abstract: This document identifies a BGP routing problem that resulted in unstable peering relationships, routing instability, and excessive route flaps. The document also serves as an artifact to demonstrate the value of ICT methodology.

Background: Customers, all from the same organization, complained of poor web site usability. Symptoms of the problem were described as slow loading web pages, limited functionality, and an excessive delay of data enumeration. To be clear, the problem only affected this particular organization.

Solution: Troubleshooting, using ICT methodology, identified a problem at the customer's location. I sent the following email that outlined the resolution process:

Dear Kathy,

It was a pleasure speaking with you on the telephone. I wish it were under better circumstances. I am writing to outline the network problem that prevents staff at your location from connecting to our network.

My research indicates there may be a problem with your organization’s local Internet connection and related routing issues. There are two influencing factors:

1. Network tests sourced from your organization indicate packet loss; well before traffic reaches our servers. The problem may be sourced from your organization or from an upstream ISP.

· A ping test measured bits of data sent and received from your location to our hosted web site. We found approximately 25% of the data was dropped en route.

· A trace route documented the path the packet traveled across the Internet. We found there were over 10 separate network hops from your organization to our servers (not unusual). Each “hop” represents a different Internet Service Provider (ISP) router.

· A separate PING test to each hop indicated that 25% of the data was lost. We are reasonably certain that 25% of all data sent from your location is lost; from at least the CenturyLink/Quest hop. Our server farm is located several hops upstream from the Quest network.

2. There may be BGP routing problems with your organization's network. There were multiple BGP route announcements sourced from your network today.

The Internet uses a routing protocol called Boarder Gateway Protocol (BGP). Your organization uses BGP to host a single IP subnet with multiple ISPs. If the primary ISP is unavailable the network will failover to the secondary ISP, while still using the same IP subnet.

I determined there were hundreds of route updates and withdraws that continued up until 6/30/2013 at 3:21:PM PST. The following graph is a snap shot of the multiple paths to your organization’s network from external ISPs:

There were excessive route flaps and instability during this time-frame. I suspect there are still unintended BGP peering relationships to your organization’s network. Multiple inbound paths from different ISPs may cause data loss. I cannot provide further details because I am not familiar your organization’s private network. I can confirm that the problem is severe enough to interfere with our service. Unless the problem is resolved, your staff will begin to notice issues from other web sites as well.

Earlier today, I spoke with Bob from your IT department’s help desk. Bob was very helpful as he assisted with some of the network tests. It is my understanding that Bob planned to escalate the issue based on the ping and trace route tests. I also encourage you to forward this email to the appropriate network department to assist the escalation process. Re-announcing the BGP routes to upstream ISPs should resolve the network instability.

Please contact me with any questions. This issue is important to me and I will do whatever I can to help make our service accessible to your staff. Please call my cell phone any time this evening if I can be of assistance.

Sincerely,

Steven M. Jordan

Network Administrator

Fix iPhone Wi-Fi Problems: Part II

Summary

Recommendation 1: Influence Roaming.

Best Practices:

Recommendation 2: Controlling Data Rates/ Cell Size.

Best Practices:

Recommendation 3: Transmission Power Tuning.

Best Practices:

Juniper WLC iPhone Optimization Commands:

Juniper Troubleshooting Commands:

References:

Juniper SRX DNS Proxy Issues Over the VPN

JUNOS 9.3 Upgrade Causes Missing Interfaces

Juniper EEOL - End of Life and End of Support JUNOS versions

BGP Troubleshooting Artifact

Fortigate & S-Flow Config

Problem:

Solution:

My Instagram