RedMAX Troubleshooting Guide

8/20/2019 RedMAX Troubleshooting Guide

1/14

RedMAX Troubleshooting Guide 2006/07/28 – Ver.1, Rev.0Proprietary Redline Communications © 2006

RedMAX Troubleshooting Guide

Redline Communications Inc.

Partner Services Department

Prepared For Redline Certified Partners

Document No: O2.1.1

Subject To Change Without Not ice


2/14


-2-

Copyright Information All rights reserved ©2006. The information in this document is proprietary to Redline Communications Inc. Thisdocument may not in whole or in part be copied, reproduced, or reduced to any medium without prior consent, inwriting, from Redline Communications Incorporated.

Contact Information: Redline Communications Inc.

302 Town Center Blvd.

Markham, ON

Canada L3R 0E8

Web site: http://www.redlinecommunications.com

Sales Inquiries:

North AmericanToll-free

International

[email protected]

[email protected]

Support:

Email

Telephone

[email protected]

Contact your Redline Distributor

Document File Name: O2.1.1 RedMAX Troubleshooting Guide-Ver1-Rev0.doc

DisclaimerThe statements, configurations, technical data, and recommendations in this document are believed to be

accurate and reliable, but are presented without express or implied warranty. Additionally, Redline makes norepresentations or warranties, either expressed or implied, regarding the contents of this product. Redline

Communications shall not be liable for any misuse regarding this product. The information in this document issubject to change without notice.


3/14


-3-

Revision History

Date Version Revision Author Note2006/07/28 1 0 A.S. First Released Version.

Document Owners/Editors.Redline Communications Inc.

Partner Services

Copyright © 2006 Redline Communications Inc.


4/14


-4-

Contents

1 INTRODUCTION .............................................................................................................................................................................5

2 REQUIRED INFORMATION FOR TROUBLESHOOTING.............................................................................................5

3 TROUBLESHOOTING TOOLS...................................................................................................................................................5

3.1 I NTERNAL TOOLS.........................................................................................................................................................................5 3.1.1 System Event Log................................................................................................................................................................5 3.1.2 Statistic Screens..................................................................................................................................................................6

3.2 EXTERNAL TOOLS........................................................................................................................................................................6 3.2.1 Ping.......................................................................................................................................................................................6

3.3 NETWORK S NIFFERS....................................................................................................................................................................7 3.3.1 The rfMonitor Application................................................................................................................................................7

4 TROUBLESHOOTING BOOT ISSUES .....................................................................................................................................7

4.1 DEVICE DOESN’T POWER -UP......................................................................................................................................................7 4.2 DEVICE OCCASIONALLY R EBOOTS............................................................................................................................................8 4.3 THE AN-100U’S FAULT LED IS BLINKING..............................................................................................................................8

5 TROUBLESHOOTING ETHERNET .........................................................................................................................................8

5.1 CROSS-OVER VS. STRAIGHT -THROUGH.....................................................................................................................................9 5.2 CANNOT ESTABLISH A CONNECTION TO THE MANAGEMENT PORT .....................................................................................9 5.3 DUPLEX MISMATCH.....................................................................................................................................................................9

6 TROUBLESHOOTING MANAGEMENT ................................................................................................................................9

6.1 AN-100U SERIAL COMMUNICATION ISSUES...........................................................................................................................9 6.2 AN-100U IP COMMUNICATION ISSUES..................................................................................................................................10 6.3 SU-O IP COMMUNICATION ISSUES..........................................................................................................................................10 6.4 SOFTWARE UPGRADE ISSUES ...................................................................................................................................................11

6.5 HIGH SMC LATENCY ................................................................................................................................................................11 7 TROUBLESHOOTING WIRELESS LINK ISSUES ...........................................................................................................11

7.1 CANNOT ESTABLISH A LINK .....................................................................................................................................................11 7.2 LINK OPTIMIZATION AND R EFERENCE RSSI..........................................................................................................................12 7.3 SU-O DE-REGISTRATION..........................................................................................................................................................12

8 TROUBLESHOOTING DATA THROUGHPUT .................................................................................................................13

8.1 FIRST STEPS TO TROUBLESHOOTING DATA SERVICES.........................................................................................................13 8.2 A COMMON CLASSIFIER EXAMPLE..........................................................................................................................................13 8.3 WHAT IF YOU DON’T /CAN’T K NOW THE HOSTS’ MAC ADDRESS(ES)? ..........................................................................14

8.3.1 Point-to-Point Pass-through Mode .............................................................................................................................. 14


5/14


-5-

1 IntroductionThe primary purpose of this document is to help the Redline Certified Partner in resolving issues that they

may encounter while using the RedMax equipment. This document assumes a bottom-up approach to

problem-solving. That is to say that the troubleshooting sections are organized with basic hardware andbooting issues first, followed by issues concerning Ethernet and serial communications, management

connectivity, wireless link establishment and finally, data flow.

Note: This document is not a manual. It assumes a pre-existing familiarity with the RedMax system, as

well as Ethernet and IP connectivity.

2 Required Information for TroubleshootingThe first step in the troubleshooting process is to gather all of the necessary information. This includes,but is not limited to, the following:

• Network diagram: A network diagram will usually consist of multiple drawings. First, the

diagram must show the physical connections between network devices. The make and themodel of every device have to be listed. LAN and WAN protocols used for communication haveto be listed. On a potentially separate diagram logical connections have to be listed. Every

network interface of every manageable has to be defined. The user data and managementpaths have to be clearly defined with appropriate VLAN-s and IP subnets listed.

• Device Configuration: This should include both hardware and software configuration of every

RedMax device, as well as any device either physically or logically connected to it. Manynetworking devices make provisions for saving the configuration file to text format. If that is notan option, screen captures are necessary. Make sure to include the currently active software

version.

3 Troubleshooting Tools

This section discusses each of the troubleshooting tools available for use during RedMax troubleshooting.The RedMax system has some tools built into its interfaces; these will be covered first. There are also anumber of external tools available, which will also be discussed.

3.1 Internal Tools

3.1.1 System Event Log

System events for both the AN-100U and SU-O are captured in an event log. The eventlog for both devices can be accessed via the CLI by entering the command “showeventLog” from the root menu. It is likely that the event log is longer than a single terminal

window, and possibly longer than your client’s buffer. In order to view the whole log, usethe command “show eventLog paged”. This will display the event log one page at a time.

The AN-100U also has the option of clicking the “Event Log” link in its GUI.

Both devices order their event log chronologically with the most recent event first in thelist. Each event is time stamped with either the system time, or a time of day obtained

from a time server if it has been configured to do so. It is important to note that the AN-100U supports only SNTP (RFC-2030), while the SU-O supports only ToD (RFC-868).

Neither device stores its event log in non-volatile memory, meaning that all informationwill be lost when the unit reboots. If you plan on rebooting, or otherwise interrupting powerto your device, make sure to capture the event logs before doing so.


6/14


-6-

3.1.2 Statistic Screens

Both the AN-100U and the SU-O provide various screens showing wireless, Ethernet, and

service flow performance. Statistical information on the SU-O can be found in the CLI’sMonitor screen (accessed by simply typing “monitor” from the root menu. The same menu

is available via the AN-100U’s CLI, but most of the AN-100U’s crucial information is moreeasily accessed via the GUI using the “SS Info” and “Status” menus.

Usage of these screens will be dealt with specifically in their own sections.

3.2 External Tools

3.2.1 Ping

The most basic tool available for troubleshooting networks is the ping utility. This littleapplication should be well known to every network engineer. There are a few parameters

that are of specific import during RedMax troubleshooting. This discussion applies to pingas implemented on Windows platforms. For other operating systems some details mightdiffer slightly.

To use the ping utility, from the Windows command line type:

ping 192.168.101.3

The expected output should resemble the following:

Reply from 192.168.101.3: bytes=32 time=3ms TTL=30

Reply from 192.168.101.3: bytes=32 time=3ms TTL=30Reply from 192.168.101.3: bytes=32 time=3ms TTL=30Reply from 192.168.101.3: bytes=32 time=3ms TTL=30

Ping statistics for 192.168.101.3:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:

Minimum = 3ms, Maximum = 3ms, Average = 3ms

By default, four pings are sent, with a spacing of approximately 1 second (The next echorequest will be sent 1 second after the previous echo request). The timeout for each

request depends on the version of Windows (for XP it is 4 seconds).

The default ping size is 32 bytes. This is the size of the data field in the ICMP packet – it

is not the size of the entire packet. When we add 8 Bytes of ICMP overhead, 20 Bytes ofIP overhead and 18 Bytes of Ethernet overhead, we get an Ethernet frame size (for adefault ping) is actually 78 Bytes. If one wants to test how ping works with the maximum

Ethernet frame size, then specify “–l 1472” (1472 Bytes of ping “data” maps to 1518 BytesEthernet packet). If the specified size is larger than 1472 bytes, the PC will send morethan one IP packet – it will send fragments that will be reassembled at the destination. If

everything is OK, a packet (or packets) of the same size will be sent back.The maximum value one can enter for the ping size is 65500. With 8 Bytes of ICMPheader, this makes the 65508 Bytes of IP payload. IP will fragment this into 45 packets.

So for the “maximum ping” to succeed, 45 Ethernet packets of maximum size (actually 44packets will be 1518 Bytes, the last one will be 426 Bytes long) have to be successfullytransmitted, and then in response, an additional 45 packets have to be successfully

received. Also note that although pings are sent with a spacing of approximately 1second, fragmentation is under control of the TCP/IP stack, and all the 45 packets will be


7/14


-7-

sent at line rate of the network card, which in some cases could cause pings to dropsimply because buffers across the network have gotten too full.

3.3 Network Sniffers

Sometimes while troubleshooting it helps to see exactly what packets are sent from certain

device, what is received, etc. Software (and hardware) tools that allow you to do this are callednetwork sniffers. There are a couple of them available on the market. One very popular softwaresniffer is Ethereal. Ethereal is an open-source application that has a large following and almost all

the features of more expensive tools. Some of the better-known commercial sniffers are NetworkGeneral’s Sniffer and WildPackets Etherpeek. Usage of each of these tools is beyond the scopeof this document.

3.3.1 The rfMonitor Application

The rfMonitor is an application developed by the Redline Technical Services department

used for monitoring the wireless performance over time. It monitors the RSSI and CINR at

set intervals (500ms ~ 10s) and graphs the results visually. The results can be saved aseither an image, or as a .csv file for use in any spreadsheet program.

The latest public version can be found on Redline’s partner website.

4 Troubleshooting Boot IssuesThis section deals with various hardware and software issues which may affect the booting of the RedMaxsystem.

4.1 Device Doesn’t Power-up

The first step in troubleshooting power-up issues is to inspect the power source. In general, thefollowing considerations must be made:

• If the unit has an A/C power supply, you should check the power cord and the powerbar or outlet that the power cord is connected to. To verify the power cord, try using one

you know is working. To verify the power bar or the outlet, try using a different device(your laptop for example) on the same power bar port AN-100 was initially connectedto.

• If the unit is D/C, then there is no power switch. Once the D/C connector is plugged in,and power is available, the device will start booting immediately. If a D/C powereddevice doesn’t work, the first step is to check the power cord, using a similar procedure

as for A/C power cords. A common issue with D/C power is that the black and blue linesare connected incorrectly to the power source. This results in a reversal of polarity. Inthis case unit will not power on, but hopefully (in the case of RedMax equipment) a

diode protection circuit built into the power sub-system should prevent permanentdamage. In the case of the AN-100U, to properly connect these wires to the powersource, one has to understand that the D/C power input is floating, which allows for

positive, negative or floating power connections. So when connected to a D/C powersupply providing negative D/C voltage, the black cable should be connected to thepower return, and the blue cable to the negative voltage. When connected to a D/C

power supply providing positive D/C power, the black cable should be connected to thepositive voltage, and the blue cable to the power return. In other words, black cableshould always be connected to a point of the higher potential. If the D/C power cord is

properly connected to the power source, and the unit still doesn’t come up, verify the


8/14


-8-

maximum amount of current power source is capable of providing. The AN-100U candraw up to 4A of rush-in current (current required in the first half of second since the

unit is first powered on). Rush-in current depends on the voltage provided by the powersource – the higher the voltage, the lower rush-in current required.

• The AN-100U (both A/C and D/C versions) has a fuse in each of its power supplies

which is to protect the system from current overloads. After having verified that the

power supply is connected properly, and is being supplied with the appropriate voltageand current, verify that the fuses, and replace them if necessary.

• Verify that the AN-100U IDU is connected to the correct connector on the ODU. Both IF

and RF ports of the AN-100U radio are female N-type, so it is very easy to mix them. Ifyou connect the RF port to the IDU, the IDU will not power up. There is a component(the transmission line) at the entrance of the RF port that, among other things, protects

the radio from a surge of power. When the IDU is connected to the RF port, thistransmission line acts as a short, causing the IDU power supply to get enter its ownprotected mode, as 24 V power supply is essentially connected to ground.

• For the SU-O, verify that the SU-O is connected to the “Power & Data Out” port of theindoor power injector, and that the local network device is connected to the “Data In”port.

4.2 Device Occasionally Reboots

The most likely causes for occasional reboot are hardware defects, problems with an external

power source, or a software bug. In this case troubleshooting is harder as the reboots areessentially random. First, check the event log (as detailed in section 3.1.1), and look for anyunusual messages such as “P1 Watchdog reset). Obviously, capture any messages you find.

Start capturing the CLI output on the serial port (or a Telnet session, in SU-O’s case) in case thedevice reboots again. It’s possible that the device will provide a reason for the reboot during theboot sequence. In addition, possible external causes should be investigated, such as the quality

of the external power source. If the system reboots without providing an error message, youshould try swapping out one component at the time in order to isolate the cause.

4.3 The AN-100U’s Fault LED is Blinking

This generally means that one of the power supplies is faulty or not connected properly. Checkthe event log to determine which of the power supplies is the problematic one. Follow the steps in

section 4.1.1 to ensure that the cables are connected properly. The power supplies are NOT hot-swappable, nor are they user serviceable. If it turns out that one of them is faulty, the entire AN-100U must be returned to Redline for repair/replacement.

5 Troubleshooting EthernetThe AN-100U has two Ethernet ports: Data and Management. All user data traffic passes across the Data

port. Depending on the configuration, management of the AN-100U and its connected SU-Os can be done

via either the Data port, or the Management port. It is not possible to enable both at the same time. If the AN-100U is configured for integrated management, then management will be done inline via the Data

port. If the AN-100U is configured for separated management, then management will be done out of bandvia the Management port. It is important to note that traffic destined for the management interface of anyconnected SU-O’s is considered “management” traffic, and must be sent across the appropriate

connection.


9/14


-9-

5.1 Cross-over vs. Straight-through

Assuming that the quality of the cable is Category 5 or better, it does not matter what type of

cable is used with the AN-100U -- it supports auto-sensing of cable polarity. The SU-O requires astraight-through cable if it is being connected to a switch/hub, and a cross-over if it is being

connected directly to a PC. Please note that an appropriate weatherproof Power over Ethernetcable must be used to connect the SU-O to its power injector, located indoors. A standardCategory 5 Ethernet cable can be used to connect the power injector to the network device.

5.2 Cannot Establish a Connection to the Management Port

If the appropriate cables are used, and a connection to the AN-100U’s management port still isn’testablished, it is likely that the AN-100U is configured for Integrated management. When

configured in this way, the AN-100U completely disables the Management port. Configure the AN-100U for separated management, which will enable an Ethernet connection with the managementport.

5.3 Duplex MismatchEthernet devices with different speeds can exist on the same physical network. Auto-negotiation

is a protocol that allows two devices to agree on the highest possible speed that both devicessupport. Both devices advertise all the (speed, duplex) combinations they support and the highestcommon one is selected.

This protocol only works if both ends support auto-negotiation. If only one end supports it, and theother one is with fixed configuration, the auto-end will recognize the speed of the remote end, butit will not be able to recognize whether remote end operates in half or full duplex mode. It will,

according to standard, ALWAYS assume half duplex mode. A typical error is to configure one side of the link for full duplex, and the other one for auto-negotiation. This combination will result in a duplex mismatch, which causes a lot of collisions and

bad frames. The link will work, but the end-user will experience erratic behavior, especially if thetraffic is delay-sensitive.

When collisions happen, the end-station that is in half-duplex mode will detect it, send the“jamming signal”, discard the received frame, and prepare its own packet for retransmission. Theproblem is that end-station that is in full -duplex mode ignores the jamming signal, so the packet itwas sending is lost for good.

Therefore, in the case of a duplex mismatch, one can expect to see many collisions reported onthe half-duplex side, and a lot of received error frames on the full-duplex side.

6 Troubleshooting ManagementEstablishing a connection to the management interface of the RedMax system is essential; Without theability to configure it, the RedMax system is useless. Management of the AN-100U is done primarily via

the HTTP GUI, though Telnet, Serial, and SNMP connectivity is also available. Configuration of the SU-O

is available only via Telnet.

6.1 AN-100U Serial Communication Issues

The AN-100U uses a DB-9 male connector. Its port is DTE, so in order to connect it to your PC(which also has a DTE serial port) a RS-232 crossover cable (also known as null-modem cable) is

required. In order to establish serial communication with the AN-100U, the serial port on your PCshould be configured to a baud rate of 57,600 bps, 8 Data bits, no Parity, 1 Stop bit, and no flowcontrol. The terminal application you are using should emulate a VT-100 terminal.


10/14


-10-

6.2 AN-100U IP Communication Issues

In this case, the AN-100U boots properly, though connectivity via IP to either the GUI, Telnet, or

SNMP interfaces are not possible. Note that it is assumed that either your PC is connecteddirectly to the Ethernet port of the RedMax device in question, or that you have properly

configured the routing necessary to establish communication across your network. A basic pingtest will verify IP connectivity. Verify that there aren’t any routers between the PC and the AN-100U which may filter ICMP/HTTP traffic.

§ Log into the Serial interface (as detailed in section 6.1) and verify that the IP address

configured for the AN-100U’s management interface is reachable from your PC’s subnet.You can check the IP address of both the AN-100U and the SU-O by typing “showipAddress” into the root menu of the CLI. A detailed explanation of IP addressing is

beyond the scope of this document.§ Verify that the PC is connected to the appropriate Ethernet port on the AN-100U. If

configured for integrated management, connect to the Data port. If configured for

separated management, connect to the Management port.§ The AN-100U was intentionally designed not to be manageable from behind on of its

registered SU-O’s. If connected downstream of the AN-100U, it will be necessary to either

move the PC in question upstream, or install a router upstream of the AN-100U which willbe able to route the management traffic back down to the AN-100U.

6.3 SU-O IP Communication Issues

It is extremely important to note that the SU-O has 3 available IP addresses. The first is therescue IP address. It is always available, and is non-configurable. That address is 192.168.101.1.

Secondly, it has a user configurable local IP address. This address is only available whenconnected directly to the SU-O, and is defaulted to 192.168.101.2. Lastly, the SU-O is capable ofremote management over the wireless link. This address is assigned by an upstream DHCP

server, and has no default.

It is crucial that each one of these 3 IP addresses be in a different subnet. If they are in the same

subnet, there is the chance that the SU-O may be unable to determine which interface to send apacket across, and make the wrong decision. This could cause many problems, such asDHCP/ToD timeout, or loss of remote management connectivity.

If local connectivity is not possible, verify the following:§ Attempt to ping the local IP address. Verify that the PC’s IP address is in the same subnet

as the SU-O’s.§ Configure your PC with an IP address in the 192.168.101.0/24 subnet (i.e.

192.168.101.10). Attempt both telnet and ping communication. If this works, it is likely that

there is a mis-configuration of the local IP address. Verify its configuration via the “showipAddress” command.

If remote connectivity is not possible, verify the following:§ In order to manage the SU-O remotely across the wireless link, it must be configured as a

“managed SS”. Doing this will require the installation of a DHCP server and a ToD server,

as specified in the 802.16-2004 standard.§ If the SU-O is configured for remote management, then it requires a valid response from

both a DHCP server, and a ToD server specified in the DHCP lease it received. If one or

the other are not received properly, the SU-O will not complete network entry. Log into theSU-O locally and verify whether remote management is enabled by typing “showmanagedSS” from the root menu.

§ Verify that the SU-O has properly received its DHCP lease, and ToD response bychecking the event log. The appropriate message (i.e. DHCP timeout) will be entered intothe log if this is the case.


11/14


-11-

§ Check the SS Info page of the AN-100U to see if the SU-O has an IP address listed underthe appropriate column.

6.4 Software Upgrade Issues

Both the AN-100U and the SU-O make use of the FTP protocol for software upgrades. The AN-

100U allows the user to specify the username and password to be used. The SU-O assumes adefault username of “target”, and a default password of “secret”. If the file transfer process isfailing, verify the following:

§ Verify the IP address of the FTP server entered.§ Verify that the FTP server is running and active.§ Verify that the binary upgrade file is located in the home directory of the user specified.

§ Verify that the extension (.bin) is specified.§ Obtain a new copy of the binary installation file. It’s possible that it has been corrupted

somewhere between obtaining the file from Redline, and loading the file onto the FTP

server.§ Verify that the proper file is being loaded onto the proper device. AN-100U files have the

prefix “IBU_”, while SU-O files have the prefix “SUO_”.

6.5 High SMC Latency

SMC stands for Secondary Management Channel, and refers to the connection that traffic

destined for the management processor of the SU-O uses. Telnet sessions, FTP sessions andICMP packets destined for SU-O’s use this connection. This connection is restricted by the AN-100U to 16kbps, and is considered very low priority by the scheduler. Thus, this channel is an

extremely poor indication of wireless latency.

7 Troubleshooting Wireless Link IssuesThis section covers common configuration issues in establishing a wireless link between an AN-100U andan SU-O. Field deployment issues such as antenna alignment are beyond the scope of this document.

7.1 Cannot Establish a Link

There are many possible reasons for a failure to establish a wireless link. This section lists anumber of the common problems.

§ Configuration Mismatch: There are a number of RF parameters on both the AN-100U

and SU-O which must match in order to establish a wireless link. These parameters arethe RF Channel, the RF Channel Size, and the Guard Interval. Please see theappropriate manual for instructions on configuring each of these parameters.

§ AN-100U Tx Power: The Tx power of the AN-100U is statically set. If the power is set toohigh or too low, it’s possible that the SU-O’s RSSI is either too high or too low to obtainthe CINR required for a wireless link. The expected RSSI for a particular SU-O can be

calculated by the following formula:

RSSISS = TXSC + GA-SC + GA-SS – PL

G A-SC is dependant on the gain of the antenna connected to the AN-100U. The gain of theSU-O’s antenna (G A-SS) is 13.5dBm. Pathloss can be calculated by the following formula,assuming that the system is operating in the 3.5GHz spectrum. PL = 103.2 + 20logD[km].

Verify the RFRSSI shown on the monitor screen of the SU-O. It should be above -89dBm.If it is not, the Tx power of the AN-100U should be increased. If it is above -50dBm, it maybe that the RSSI is too strong for the SU-O, so the Tx power of the AN-100U should be

reduced.


12/14


-12-

§ Cell Range: The AN-100U specifies a maximum distance beyond which SU-O’s will beunable to register. Verify that this distance is larger than the distance between the AN-

100U and the SU-O. If not, increase this value. The maximum value is 20km. § Reference RSSI: This is an important value, and will be discussed in depth below in

section 7.2

7.2 Link Optimization and Reference RSSI

Aside from field characteristics such as antenna alignment and positioning, the primary method of

optimizing a sector’s wireless performance is by adjusting the AN-100U’s Reference RSSI. This isan increasingly tricky parameter to set properly as the number of SU-O’s per sector increases. Itis vital to have a good understanding of this parameter; It has both an immediately obvious effect,

as well as a subtle yet equally important effect.

The obvious effect is on the Tx power of the SU-O, and therefore the uplink RSSI of that particular

SU-O. Assuming that the AN-100U is configured with Tx Power Control enabled (highlyrecommended), then the Tx power of each SU-O in the sector will be controlled such that theRSSI as measured by the AN-100U will be as close as possible to the reference RSSI. I say “as

close as possible” because, in the case of SU-O’s with a high amount of pathloss along their link,it is possible for the SU-O to have reached its maximum Tx power and still be lower than thereference RSSI. This is a situation which should be avoided if possible.

The less-obvious effect of this parameter is, in fact, the reason that it’s so important. Thisparameter directly controls the amplification along the AN-100U’s IF cable. Since the A N-100U

does not support AGC, it cannot adapt its IF gain for each SU-O. That means that a single gainhas to apply to all SU-O’s. The gain as received at the Phy (the device in the IDU which performsthe actual decoding of the OFDM signal) must be as close to -12dBfs, as possible. The Reference

RSSI configured in the Wireless Interface page specifies the target RSSI for all SU-O’s, whichmeans that the AN-100U can calculate what the IF gain must be in order to achieve -18dBfs.

For example:

The AN-100U’s Reference RSSI is set to -63dBm. Due the pathloss, the SU-O can only achievean uplink RSSI of -80dBm even when transmitting at its maximum power of 20dBm. A configured

reference RSSI of -63dBm means that the IF gain is 51dB, thus our PHY RSSI is only -80 + 51 = -29dBfs. This is way too weak a signal for the PHY. If the reference RSSI were changed to -80dBm, the IF gain would now be 68dB, thus our PHY RSSI would now be -80 + 68 = -12dBfs.

Thus, by decreasing the reference RSSI, we increase the IF gain. Unfortunately, in doing so wealso increase the receive noise, so although we improve the RSSI, and thus the CINR of the link,the signal quality will not be such that we can achieve 64QAM3/4; It will simply be better than it

would have been had we left a 20dB difference between the reference RSSI and the SU-O’s bestachievable uplink RSSI.

The complication arises when you have a large number of SU-O’s, some with low pathloss, andsome with relatively high pathloss. If you set the reference RSSI to accommodate only those SU-

O’s with low pathloss, then those with high pathloss may not establish a link at all. However, if youconfigure the reference RSSI to accommodate those SU-O’s with a high pathloss, then those withlow pathloss will have their performance severely impacted. The recommended value is to set thereference RSSI to the mean average of the best RSSI of all of the SU-O’s in the sector.

7.3 SU-O De-registration

When an SU-O de-registers, two pieces of information will be logged to assist in diagnosis. Firstly,

in the SU-O’s event log, a message and timestamp detailing the cause of de-registration will beentered. Search through the SU-O’s log and look for messages like “DHCP Timeout”, or “DL Map


13/14


-13-

lost”. The second piece of information is located in the AN-100U’s event log. This messagecontains a timestamp, the SU-O’s MAC Address, and a reason in brackets. The reason can be

either “re-ranging”, or “rngRetries”. “rngRetries” means that the ranging process failed, andwireless troubleshooting steps detailed in sections 7.1 and 7.2 should be taken. “Re-ranging” isslightly more interesting.

A reason code of “re-ranging” literally means that the subscriber station initiated network entrywhile the AN-100U believed it was still connected. Keep in mind that the only method the AN-100U has to determine whether an SU-O is still connected is by receiving some traffic from it. If

there is no network traffic, the only data sent by the SU-O is a periodic range, which occurs every25 seconds. Thus, it can take up to 25 seconds for the AN-100U to detect that an SU-O has goneoffline. During this potential 25 seconds, it is entirely possible for the SU-O to attempt to register

again. If it is successful, this will cause a “Re-ranging” message.

The SU-O can disconnect for a number of reasons. Unstable link conditions are a frequent cause,

as are problems with the SU-O’s power source. Perhaps less obvious is the fact that if remotemanagement is enabled, the SU-O requires communication with a DHCP server and a ToD (RFC-868) server in order to operate. If it is not able to connect to both a DHCP server, and the ToD

server specified in the lease it obtained, within 2 minutes it will reset and attempt again. If you areseeing Re-Ranging messages in your A N-100U’s event log at approximately 2 minute intervals, itis very likely that you have a problem with either your DHCP or ToD server. Try disabling remote

management temporarily to see if the de-registrations stop.

8 Troubleshooting Data Throughput All units boot properly, Ethernet and IP connectivity are confirmed, and the wireless link looks good. Yetthere are still issues passing data traffic. Why? Usually, it’s caused by an issue with either the Service

Class, Service Flow, or Classifier configuration.

Note: As mentioned in the introduction to this document, this is not intended to be used as a system

manual. A step-by-step discussion of the configuration of data services is beyond the scope of thisdocument. For details on service configuration, please see the respective device’s user manual. Thissection is intended only as a summary of common configuration pitfalls.

8.1 First Steps to Troubleshooting Data Services

This section lists a number of quick steps to ensure that you have properly configured your data

services.§ Check the Service Flow menu on the AN-100U to ensure that all of your Service Flows

are in Active state. If they are “Authorized”, then it’s likely that you have not configured

any valid classifiers. Service flows do not become active until there are classifiersassociated with them.

§ See section 7.3 for another common cause of service flows remaining in authorized state.

§

Verify that any created classifiers are also active. If there is a conflict with another pre-existing classifier, then they will have a status of “rejected”. Check the event log of the AN-100U for a classif ication conflict error message.

8.2 A Common Classifier Example

People generally do not have problems with configuration of Service Classes or Service Flows; A

Class defines a QoS template which is then used by Service Flows to define a “pipe” between aSU-O and an AN-100U. People often have difficulty creating appropriate service flows because itrequires a knowledge of a layer of network that most people aren’t exposed to. In the following


14/14


-14-

example, there is a PC connected directly to an SU-O, and a router connected directly to the AN-100U. In our example, it doesn’t matter what is beyond the router upstream, since classification

will be done on Layer 2.

For simplicity’s sake, there is only 1 Service class, and it is defined as a 1Mbps Best Effort class

called “Class1”. There are 2 Service Flows (1 in each direction). SF1 is a downstream flow, andSF2 is an upstream flow. Classifiers are identified by a “dotted” notation, where the first number isthe number of the service flow, and the second number is the number of the classifier. Thus, thefirst classifier associated with SF1 is identified as 1.1, and the first classifier associated with SF2

is 2.1.

For our example, we will be classifying based on the MAC address of the PC behind the SU-O.

You can find the MAC address by entering the Windows CLI, and typing “ipconfig /all”. InWindows, it’s called the “Physical Address”. For the purposes of our example, let’s assume thatthe Physical Address of the PC behind the SU-O is 00-0D-60-FC-B7-7A. SF1 is a downstream

service flow. Thus, we want to classify based on packets heading TOWARDS the PC. Ourclassifier 1.1 would therefore have a destination MAC address of 00:0D:60:FC:B7:7A, and a maskof FF:FF:FF:FF:FF:FF. Since SF2 is an upstream service flow, then we want to classify based on

packets heading AWAY from the PC, thus classifier 2.1 would have a source MAC address of00:0D:60:FC:B7:7A (same mask!).

That’s all there is to it.

8.3 What If You Don’t/Can’t Know The Hosts’ MAC Address(es)?

The above example is a good example assuming you know the MAC address of any devicesbehind the SU-O. If you don’t then there are two options.

1. You can classify based on the MAC address of the router. Classifier 1.1 in the aboveexample (the downlink SF) would have a SOURCE MAC address equal to that of therouter. Classifier 2.1 would have a DESTINATION MAC address equal to that of the

router. In this way it doesn’t matter which downstream host the traffic is originating from,

as long as it’s all heading to the same router/server. Unfortunately, this doesn’t workwell with multiple subscribers, since the AN-100U needs to have a way to uniquely

assign downstream traffic to each SF. If you’re classifying based on upstream source,and it’s all coming from the same source, the AN-100U has to “guess”, and that’s neverideal.

2. If you have multiple SU-O’s, and unknown hosts behind them, then you need to enableVLAN tagging on the SU-O (ethTag in the SU-O’s CLI). This feature causes the SU-Oto insert a VLAN tag onto each incoming upstream packet, and strip that same tag from

every downstream outgoing packet. On the A N-100U, you could classify based on thispacket in the downstream, thereby uniquely identifying traffic destined to each SU-O.Classification in the upstream can be done with a simple “wildcard” classifier where the

MAC destination is 00:00:00:00:00:00 with a mask of 00:00:00:00:00:00. The onlydrawback to this solution is that it requires that your network have VLAN support

upstream of the AN-100U.

8.3.1 Point-to-Point Pass-through Mode

The RedMax system does not have a Pass-through mode option available. It is designed

to be an access system with many registered subscribers operating simultaneously. Inthis scenario, a point-to-point pass-through mode does not make any sense. The closestconfiguration available is the configuration using SU-O VLAN tagging, as detailed in

section 8.3, though this would require some external hardware to strip and add tagsappropriately upstream of the AN-100U.

RedMAX Troubleshooting Guide

Documents